Friday, November 16, 2007

Google's view of UI development: do it in Java

I have enjoyed building a few AJAX prototypes using GWT and now I am just now starting to look at Google's Android SDK - also built on Java technology.

I have done a couple of consulting jobs using the Java ME platform, and I would guess that eventually I will do something (professionally) with Android - what is not to like about an open cellphone platform built on Linux and programmable with Java :-)

Friday, November 02, 2007

Quality Open Source: Squeak 3.9 final and new Seaside 2.8

I don't use Smalltalk professionally but I wanted to try the new Seaside 2.8 release. I did a fresh Squeak 3.9 final installation on my MacBook running Leopard. Installing Seaside was as simple as starting the SqueakMap package loader, doing an upgrade to all installed packages, then do a Seaside install answering yes to all optional package offerings. Everything 'just works' and has a very polished feel to it - important when I am giving up an evening or two to play with something very cool.

One very important aspect of this "feeling of quality" is an active community that maintains a central package web site - good examples are SqueakMap (Squeak), Gems (Ruby), and CPAN (yuck, Perl :-) Having a central package repository is more than just a time saver: time spent dealing with too many installation and configuration options disrupts what I would call problem solving mode or thinking. I used to take great pleasure in staying on top of most J2EE technologies, but I got over that :-)

The way that Seaside gets around stateless HTTP issues is very cool but I suspect that the future of rich client applications may be something like Adobe AIR. For my work, I am happy enough for now just using Rails and AJAX. I have also experimented a lot with Dojo and Lisp on the back end and a little with OpenLazlo. The question to ask is how much "rich client" support do you need for a web portal - applications like GMail show how much can be done with Javascript/HTML/CSS.

Software development: smaller is better

Small is better at all levels of software development: Small projects have lower failure rates than larger projects. Smaller classes are easier to understand and use. Small functions and methods are easier to write, understand, test, and reuse.

I think that the first point is the most interesting. It is difficult to get requirements right and reducing the size of projects by breaking them up reduces risks involved with poor understanding of requirements. To use web applications as an example, by implementing a minimal system that still provides useful functionality, we learn early on what are the most important requirements. We also keep team size small - more efficiency and less risk. We also get something useful to users developed faster.

I think that ego is the negative force that fights against the goodness of small and focused projects. At the customer level, they often want all of their ideas implemented sooner rather than later instead of setting priorities. At the developer level, they may want to push technology choice over satisfying users' needs in a timely and inexpensive way.

While frameworks certainly save development time they also add their own kind of complexity in the form of steep learning curves, selection, and maintenance to upgrade to newer versions.

In many cases I think that a better way to simplify systems is to extend programming metaphors to support application development a higher level. Two very good examples of this are Google's GFS distributed file system and their map reduce libraries. These tools change they way developers think because they do not need to worry so much about scaling their applications. Another good example is Ruby's ActiveRecord: it changes the way I think about persistence and Rails migrations are now my favorite "modeling language" for specifying class definitions even though I am really defining database schema. I argue that the combined notation of using Rails migrations and adding has_many, one_of, etc. calls in ActiveRecord classes captures the useful information in UML class diagrams in a very terse, easy to write, easy to understand, and easy to maintain executable notation. (BTW, the only type of UML diagram that I still use frequently is sequence diagrams.)