Results tagged “opinion” from manAmplified
Recently Jnan Dash of Foldera made a great comment regarding persistence. He said there are two ways to park your car. The first is to disassemble it and store it on a shelf, then reassemble it when you need it again. Or just put it somewhere fully assembled.
Living in the bay area, I tend to get introduced to founders and executives of various startups around the area. Usually the only context to the introduction is a comment by the introducer than we should meet and talk. Sometimes these meetings are great, but usually they are awkward. Besides my being socially inept, the person I'm meeting usually thinks I want something from them, like a job.
I'm currently working through a handful of requirements that will close the feature gap between an older content management system and a newer one. Both have been developed in-house. The first being MS based and is loosely a content management system, the second Java/XML/XSL based, and really a content management system. One thing I'm fighting is keeping the old process wrapped around the old system from leaking and staining the new system.
Besides a handful of interesting talks, mostly by Google employees, OSCON just didn't have the energy I found at SXSW Interactive this year. With the steep registration price, most of the interesting people were excluded, leaving mostly corporate sponsored techies in attendance. Also annoyingly, time slots either had many interesting talks simultaneously, or none. I didn't get a sense that the sessions I missed were recorded. Sadly, the one I would choose to attend nearly always turned out to be lame.
I recently commented to someone that their software was a solution looking for a problem. This comment is a statement of risk, not a statement of value. Necessity is not the mother of invention, this is mostly a misconception. But if I had said the only innovative aspect of his software made it the lowest common denominator across competing solutions by design, it would be a statement about value.
Getting a little tired of seeing comparisons of a functional Ruby abstraction compared directly to a low level language X abstraction. I just recent sat through a few slides where CORBA was compared to a new Ruby distributed interface abstraction without showing the inner workings of the Ruby abstraction. I bet given the same use case I could beat their 3 lines of Ruby code with one in Java.
After a number of presentations and pitches over the years, I think I've concluded that unintended emergent properties of a system are uninteresting. And by far, rarely are justification for the system since it was never the systems intention. This is different from systems that intend to render emergent properties, like DNA.
Poincare made a statement about mathematics that strikes me as true for computer science. To paraphrase:
Mathematics must always move in two directions, that of critical self-reflection and towards the study of nature. The Hilbert Challenge
Developers need to recognize that the Facade Pattern is intended to hide complexity, not to justify it. Not needing a Facade is better than using one. If you can do away with the complexity without hiding it behind the Facade, you are better off.
Well, I like them alot. These are things that I use daily, or am damn glad I have when I need them.
Had a recent conversation with a Palo Alto stealth-mode startup member. Seems they want a flat organizational structure and thusly have hired 4 architects. I've had difficulty interesting developers in positions here unless they are offered an Architect title, even though they don't have more than 5 years professional experience.
Business Process Management (BPM) is simply the modeling, execution, measurement, and subsequent improvement of business processes. Most pure-play BPM vendors offer tools to support all of the above. But it must be recognized that each of those pieces are an industry all their own, and to accept that a company has solved all of them sufficiently and now offer a suite of integrated tools, should be considered critically.
Our new offices are rife with small issues like the A/C working randomly or inconsistently. In response, many people believe it is to their benefit to set the thermostat (t-stat) to the lowest setting since there is no obvious means to tell if the A/C just isn't working.
I've spent a portion of the last year or so looking at executable process applications built through visual modeling of activities and participants. Many of these applications can by styled as either workflow, BPM, or just service orchestration.
When writing or presenting, the best practice is to target an audience with a sixth grade education. But when pursuing group consensus on an integration standard between organizations, do you target a "MS Windows level of education" for the result to be successful? Or is there some other way to denote technology sophistication and experience among IT professionals?
This blog entry has inspired me to make a few notes to work out some ideas through this rather meandering essay.
In very simple terms (read convenient simplification, see below), a queue is a serialized list of pending requests. And it is typically used to broker/filter/throttle requests to a naturally concurrent system behind it. What's interesting is that systems are typically compositions of other naturally concurrent (sub)systems. Turtles all the way down, if you will...
Just returned from what I thought was intended to be a discussion over patterns and best practices within an ESB deployment, likely sourced with examples from this new book, since the meeting was hosted by its author. Sadly it proved to be ESB "as" a best practice, where they handed out copies of the book, leaving the interesting discussion as homework.
Now after overcoming a number of mental hurdles regarding XML, including the lack of type safety and tool maturity, I'm still stuck with the aweful syntax. This is further aggravated by the reality of both data centric XML instances and manipulative or executable centric XML instances.
In the book "Wisdom of Crowds", the author (James Surowiecki) describes the observation that a group of sufficiently independent individuals are better decision makers (are more accurate) than the individual (or even the expert). If you aggregate a collection of independent opinions/answers, the 'local knowledge' of each individual (whether they be wrong or right) improves the performance of the group. If the individuals are not independent, that is they communicate with one another and share knowledge, you risk that influence leading the group astray.
In response to 'test driven development', I propose 'stress driven architecture'.
In an interview, Victoria Livschitz touches on a problem that has been bothering me for some time. Notably, "The sequence of the routine itself -- what comes before what under what conditions based on what causality -- simply has no meaningful representation in OO, because OO has no concept of sequencing, or state, or cause."