Posted by Curt Hibbs Wed, 22 Feb 2006 17:14:00 GMT
Yes, yes, yes! That’s all I’ve got to say about Martin Fowler’s post about encapsulation.
For me, the point of encapsulation isn’t really about hiding the data, but in hiding design decisions, particularly in areas where those decisions may have to change.
Posted by Curt Hibbs Mon, 13 Feb 2006 19:35:00 GMT
More and more I get the feeling that we are seeing the beginnings of a revolution in the way software is developed and deployed.
In the (very) old days we had applications running big mainframe computers with the user interface either being a stack of punched cards (batch programs) or some sort of dumb terminal connected to the mainframe.
With the advent of PCs computer applications quickly moved to the desktop (even though early PCs didn’t have a desktop) because it gave the user more control and, most importantly, it gave the user more responsive and interactive applications. The mainframes hung on as long as they could with client/server applications but, in the end, they just couldn’t compete with the desktop.
The move to desktop applications brought with it some new problems that required changes in the way software was developed and deployed. These mostly had to do with things we now consider to be rather mundane: how to keep track software versions; how to push new versions (or bug fix patches) out to user; how to deal with multiple, (possibly) incompatible releases out in the field; how to plan and market new releases; etc.
The next big change was caused by the Internet. While the major benefit to the user was the connectivity – the application and its data is available anywhere, any time; and applications can talk to each other and cooperate for the user’s benefit – it also returned us to some of the benefits of the old mainframe and client/server applications. New software versions are deployed to a central server and immediately available to everyone without them having to do anything.
Of course, the move to the Internet also brought with it some problems. The biggest one, from the user’s point of view, was that those nice, responsive desktop applications had turned into slow, clunky, page forms—every application became a series of form pages instead of a series of intuitive interactions. The user also lost control of their data, but most user’s didn’t mind or care (until, that is, the provider of their application went out of business and took the user’s data with them).
We are now in the beginnings of the next big change. Internet applications are increasingly enabling interconnectedness through public APIs, allowing new applications to be built on top of them and/or aggregating the services of other web applications. They are also starting to use AJAX techniques to regain some of the interactiveness of desktop applications. Collectively, these (and other) factors having been loosely termed Web 2.0.
That’s the public side of the Web 2.0 revolution. The part you don’t see (or hear much about) is how this Web 2.0 revolution is affecting the way software is being developed. It turns out that this is just as much a revolution as Web 2.0, itself. Marc Hedlund, from O’Reilly, recently laid out his accumulated observations on this new Web Development 2.0 revolution. This is very interesting stuff, and I get the nagging feeling that this is just the beginning.
Software isn’t written for Web 2.0 companies the way it was during the bubble, nor is it written the way traditional, shipped software was. New ideas about Web applications seem to necessitate new ways of making those applications. Below is my current catalog of observations.
As Dion Hinchcliffe said, “Compelling stuff but scary for us used to the old ways of things.”
Posted by Curt Hibbs Wed, 04 Jan 2006 08:00:00 GMT
Reginald Braithwaite has posted some remarkably insightful comments that puts the choice of programming languages in a new light. His basic thesis is that its not really about features at all. Its really about signal-to-noise ratio—expressing more idioms in fewer bits.
I believe that programming is an idiomatic activity. We learn idioms and then apply a kind of pattern-matching to recognise problems that can be solved with an idiom we already know. Some idioms are easier to express than others in each programming language.
Sure, all languages are Turing Complete and therefore equivalent in theory, but in practice you might find that the only way to express an idiom from Language A in Language B is to write a A->B compiler or interpreter in B.
So let’s talk about idioms instead of so-called features like syntax. What does it mean for one language to be “higher level” than another? To have a “higher level of abstraction”? My own interpretation is simple:
One language is higher-level than another if it expresses more idioms in fewer bits than the other language. Or fewer lines of code. Or fewer symbols. There’s a really simple language idiom for this: Programs in a higher-level language have a high signal to noise ratio.
Don’t miss the part about meta-programming.
Posted by Curt Hibbs Mon, 12 Dec 2005 08:00:00 GMT
Stuart Halloway just beamed back a report from the next century—a historical account of how XML killed Java.
Its too short for me to quote, but its a good read. So, go take a look!
Posted by Curt Hibbs Tue, 22 Nov 2005 08:00:00 GMT
I admit that’s a deliberately inflammatory title. I’m not really crusading against EJBs, Instead, I’m crusading for agile development and higher developer productivity. It just so happens that EJBs are the perfect poster-child to be this world view’s Anti-Christ.
So, with that introduction I’d like to point you to this post
by -Justin Gehtland- Stuart Halloway which makes a very entertaining analogy to show what is wrong with EJBs.
We do a bad job of building Enterprise software, primarily because we don’t even know what “Enterprise” means. Today we will lay out six facets of Enterprise development. In subsequent posts we will evaluate each facet in more detail, working toward a shared notion of “Enterprise” that just might make projects more successful.
Posted by Curt Hibbs Mon, 07 Nov 2005 08:00:00 GMT
Martin Fowler recently posted a nice little essay demonstrating the difference between two schools of thought on designing programming APIs: humane and minimalist. In this essay, the humane interface (as exemplified by Ruby) is contrasted with the minimalist interface (as exemplified by Java).
This is a very interested read, and really captures the heart of the Ruby philosophy.
It also made me wonder if Python falls in to the minimalist category with their philosophy of “there’s only one way to do something”. I’ve never used Python myself, so I’d appreciate hearing from current or former Python developers on this.
Humane interfaces do more work so that clients don’t have to. In particular the human users of the API need things so that their common tasks are easy to do – both for reading and writing.
There are good arguments on both sides. Personally I lean to the Humane Interface approach, although I do think it’s harder.
Posted by Curt Hibbs Tue, 25 Oct 2005 07:00:00 GMT
There has been a lot of buzz lately about how modern technologies are opening up long tail markets that were previously unprofitable to serve. At the Fifth International Ruby Conference, one of the most interesting sessions was Nathaniel Talbott’s talk about ‘long tail’ opportunities in software development.
His main point was that as things like Ruby on Rails continue to reduce the cost of developing software applications, it becomes more and more feasible to write specific, tailored applications for very small markets (like a couple dozen people). I think he’s right. New, high-productivity technologies will, in fact, make it economical to develop software for smaller markets.
However, in our rush to embrace the long tail, we may be overlooking an even longer tail—the longest tail of them all. Chad Fowler hit on this in his post Is the Long Tail wagging the dog?. Many problems (most problems?) are so far out on the long tail that user couldn’t justify even talking to a software developer (or more likely, wouldn’t even think about it). The ‘Longest Tail’ is about enabling the user to provide his own solution.
Excel spreadsheets do this. Quick, spur-of-the-moment applications are possible with a spreadsheet. You don’t need to find a developer, you don’t need to plan or describe your needs, you don’t need to spend any money, you just need to do it. If what you did stops being good enough, you can fix it. Not only do you own the data, you own the solution as well!
Of course a spreadsheet can’t do everything. For its niche, though, its very good and it totally enables the user. Apple Computer’s HyperCard did the same thing for a wider class of software solutions.
To serve the Longest Tail, we need software than enables users to create their own solutions. Chad Fowler pointed out a new web application, Dabble, that aims to do this. I haven’t tried it yet, but I can’t wait to do so.
Posted by Curt Hibbs Tue, 18 Oct 2005 07:00:00 GMT
Kevin Barnes has posted an excellent story on the current state of IT outsourcing in India. This is an inside view from living in Bangalore and is a must read if you are interested in this topic.
Posted by Curt Hibbs Thu, 29 Sep 2005 07:00:00 GMT
IBM just released a major update to its Reflexive User Interface Builder for constructing and rendering graphical user interfaces (GUIs) for AWT, Swing, and SWT. What caught my eye was that it makes use of Aspect Oriented Programming (AOP):
Version 1.2 includes four Eclipse plug-ins that fully integrate RIB into the Eclipse environment. RIB also has introduced aspect-oriented programming techniques in order to automatically and non-invasively validate Java GUI-based applications, including JVM-based executables such as the Eclipse workbench itself.
You’ll have to dig into their white paper to understand what they mean by GUI validation (its not testing), but it made me wonder if this technique could also be used for GUI testing GUIs—something that has always been difficult.
Its something to think about…
Posted by Curt Hibbs Tue, 20 Sep 2005 07:00:00 GMT
Like most everything in life, conventional wisdom is a double-edged sword that has both good and bad sides. On the plus side its a great time saver, helping us to avoid making the same mistakes over and over. On the negative side it can stifle creativity and innovation.
True wisdom, on the other hand, is the ability to decide when a piece of conventional wisdom applies, and when it does not. I’m always interested in the kind of knowledge and experience that lets me increase my quota of true wisdom.
So, it is in this spirit that I recommend Kevin Barne’s little piece titled Three reasons to reinvent the wheel.
I get so tired of the worn out expression, “let’s not re-invent the wheel.” It’s used as a conversation stopper to inform you that you are straying from the well worn path of software sanity. There is no mention that this well worn path now employs nearly two million people to write what are essentially the same CRUD applications that were written on mainframes in the 1970s. It is a statement that life is good and you should rejoin the flower people on the primrose path to happiness. So, here is my answer, the three reasons you should reinvent the wheel.
His three reasons are:
Go read his posting for the details.
Older posts: 1 2
