UptoData, Inc.

An addition to the ubuntu family..

Eitan — Wed, 14 Mar 2007 22:36:00 -0500

Thought I'd share this adorable picture of my little one..

Desktop Matters: March 8-9!

Eitan — Thu, 01 Feb 2007 09:27:00 -0600

I'm excited about the upcoming Desktop Matters conference. The last couple of years have seen many topic-focused conferences, including ones on AJAX, Web2.0, and Rails.

And so it's time we've had a conference focus on Java Swing and related Desktop Client technologies.

I'm grateful to Jay Zimmerman and Ben Galbraith for making this event happen.

And.. I can't wait for the chance to speak on the project that is dearest to my heart: JMatter. I hope to see you there.

/ Eitan

gwt: initial [raw] thoughts..

Eitan — Wed, 17 May 2006 20:16:00 -0500

so google finally shows its cards. they've recently announced gwt: the google web toolkit.

before i get going let me first say that i think it is wonderfully cool for a company like google to work out and develop a solution for the web stack, and then to turn around and open source it; i.e. to make it freely available for anyone to use.

ok, let's get going.

i find gwt very interesting, to say the least.

[a] it's simple. i was able to read their documentation and understand how to go about building web apps with gwt in very little time. +1.

i really think it's too early for many of us to realize exactly what gwt brings to the table and what implications this is going to have on the way we build web apps.

[b] i'm pleasantly surprised to see this solution leverage java.

i'm also surprised to see a solution that provides a way to build ajax applications without getting one's hands dirty with html and javascript. it's somewhat ominous. what does this say about the future of writing web apps?

implications? here's a quick brainstorm:

the end of markup? is the swing metaphor for putting together an app winning over the markup metaphor?
validates the approach of frameworks such as echo

here's a bigger one:

what does this do to struts and the other umpteen mvc java web frameworks out there? is gwt the death of the mvc java web framework era?

what does this do to spring?

observations?

it's nice to see that some of the great features introduced by RoR are being used / adopted by other frameworks. i'm referring to gwt's scripts projectCreator and applicationCreator

i think gwt is terribly cool. its introduction is a terrific step forward.

stop for a moment and contrast the approach taken by google vs, for example, yui by yahoo. yui is very good. it doesn't attempt to tackle the whole ball of wax. it does ajax and has really no dependencies on any other parts of the stack.

google's solution is a much much much more involved one. they build a java to javascript compiler (!!!) to make this work. they've got a customized mozilla web browser for testing this thing. yet, the solution remains simple, from the point of view of the developer who has to construct a web app.

what a testament to css: of all the technologies that gwt swallows, css remains intact.

the introduction of gwt is the first step.

here's what i think the next step should be:

provide a rich set/variety of widgets
ensure that the mechanism for writing widgets for gwt is as simple as it can be, and standard. urge the community to contribute widgets, panels, and more. gwt can quickly grow into an ecosystem; its own platform.

i also have my ideas on subsequent steps but i'll reserve those for another time.

NFJS Anthology '06

Eitan — Wed, 17 May 2006 18:45:00 -0500

Pre-ordering for The NFJS Anthology has begun!

This title is unique in a number of ways. For one, roughly a dozen of us have contributed to its creation. The various authors have something special in common: we're all speakers on the terrific "No Fluff Just Stuff" series of conferences on Java and related technologies. We're also all coders, practicioners of our trade.

In another respect, this book is unique in that the articles it contains reflect in book form the flavor of the NFJS symposia.

Check it out! >>>

Thought Catalysis

Eitan — Tue, 02 May 2006 09:36:00 -0500

Recently some new ideas have come to me out of activities that I did not expect would generate any. In this blog entry I'd like to enumerate sources or catalysts for ideas, for generating thoughts.

Revisiting things you already know: you will likely see them from a new point of view. This will usually happen because time has passed. You've changed, you're not exactly the same person you were when you originally studied the material. That's what happened to me as I prepared to give my set of talks at NFJS last weekend.
Attend talks given by others. It's very likely that the same topic will be presented from a different angle, a different point of view.
Get together with other developers. A NFJS conference might do the trick. JavaOne is coming up. Maybe your local JUG meeting.
Even if a topic is not related to the work that you're currently doing, you might be surprised to find once in a while that a situation is discussed that is analogous to yours, albeit in a different domain, a different context.
Provoke thoughts in others. That has the tendency to amplify the thought process. You might not be prepared for an avalanche of feedback, ideas triggered by your original provocation. That happened to me recently after I demo'd some software I was working on to a couple of friends / colleagues.
A few friends recently decided to get together for Friday lunch meetings. It's been a great opportunity to discuss what each of us are working on, articles or books we came across that grabbed our attention or interest. We always have more to talk about than time available, which is a positive sign.

MVC without leaks implies generic VC

Eitan — Mon, 01 May 2006 13:44:00 -0500

How many times have we heard or preached (or both) the important lesson of not having our business logic "leak" into the client tier. Each time we hear it, we nod our heads and say "how true," and get serious for a moment.

The idea of logic leaks applies to other aspects of development, not just the client tier. For example, the Hibernate project is very concerned about not leaking persistence issues to other application tiers.

As I was thinking about this notion of business logic leakage, a very interesting thought came to me. Say for example that we define a business object, maybe a Customer. Furthermore, let's say we define a number of fields on this object: name, date of birth, etc.. The minute we put down in our text editor the lines:

<caption>Name:</caption>
<input type="text" name="name" />

..is the minute we've crossed the line; we have violated the DRY principle. We have just leaked business logic into our view. From now on, if we rename the field, we must do it in two places: in the model and in the view.

Now, imagine being in the process of developing an application consisting of a dozen business objects, each with a half dozen fields. Model changes are going to occur. They're going to imply making changes in more than one place.

Given this, it's no wonder that resistance to change grows as a project gets larger. Yet business change is inevitable. People talk about the high cost of building software. It's no wonder the cost is high if we have to manually make each change twice. Not only is it more work but also error-prone. The essence of DRY is eliminating that duplication.

So, having provided a context, I can finally describe this small epiphany I have had in a short sentence:

*If we're going to have a model-view-controller system without business logic leaking into the view, then we must construct generic views and controllers.*

What does that mean? Take for example, the CRUD scaffold generators in Rails. The code duplication is still there but at least the duplication is automated. Admittedly not bad for a first pass.

The other interesting tidbit that sort of "falls out" of this small thought exercise is:

GUI is plumbing

I've been saying this for a couple of years now but it is still my hope that some day everyone will have good GUI plumbing for their software applications.

Stoked: Not Just for Surfers Anymore

Eitan — Mon, 01 May 2006 13:14:00 -0500

I sometimes enjoy describing feelings a software developer might experience, at certain moments during development. For example, a while back I blogged about "Grazie Signore" moments.

This past weekend I attended the Northern Virginia Software Symposium and was fortunate to have a little time to spend with my NFJS comrades. A most vivid comment that Justin Gehtland made during one discussion was how stoked he was about this software we were discussing.

It occurred to me on the plane ride back to Austin that the term "stoked" is normally used to describe the feeling one gets when surfing. Perhaps it's also applied in the context of extreme-sports related activity.

To my wonder, the term could be applied, and very aptly so, to moments that we, geek software developers, have in our work. That feeling arises when we do something that we think is extremely cool, that perhaps hasn't really been done in that particular way. For example, I sensed that feeling when reading a weblog I came across on java.net a while back, having to do with a very cool idea that occurred to one of the Wicket Framework developers. See Wicket + Swing == hmmm...interesting....

I believe that this feeling is the driving force behind the hordes of us out there, of any age, who spend their spare time coding, pursuing the creation of something that, to them, is so incredibly cool. So, just like surfers can't stop surfing and continually strive to be in that most special state of being stoked, so do software developers.

The TelePhone is Dead! Long live the TelePhone!

Eitan — Mon, 01 May 2006 07:21:00 -0500

I just recently found out about NetGear's announcement of their new Skype Phone product.

The migration path from the phone network to the ubiquitous internet has never been made more clear than by the introduction of this product.

How marvelous it is when 2+2 stares us in the face and yet we can't solve the puzzle...until something like NetGear's prodcut comes along and everything suddenly becomes clear: the veil is removed.

I wonder how many of us will be walking around with Skype Phones in place of our current cell phones a year from now? Two years from now? As time goes by and as time is shrunk, the adoption of / migration to this new technology is sure to take less time than past migration have.

Very cool.

A better way to Build Business Software Applications

Eitan — Wed, 19 Apr 2006 12:00:00 -0500

Each time I look at the task of constructing a business software application, I see tremendous repetition. Each application has many facets, most of them are generic. Yet each time we appear to rebuild each facet from scratch. For example, we construct new authentication screens. We build an object model for our domain. We must construct mechanisms for browsing and searching objects, mechanisms for creating new objects, for viewing objects, for editing and deleting objects: the CRUD (Create, Read, Update, Delete) operations. Let's also not forget validation.

Oftentimes, we deal with scheduling activities and must develop or integrate calendars into our software applications. Inevitably, our customers will require a mechanism to produce reports. We will also supplement our user interfaces with wizards, by walking a user through a series of steps. We need to persist our objects to databases, we need an authorization mechanism. We need audit mechanisms to find out when information was edited, by who.

Many of these tasks are generic, orthogonal to the problem domain. Must we keep on constructing new implementations each time we start on a new project? Is it even feasible to produce implementations of these concerns (e.g. authentication, authorization, CRUD, a user interface, searching, reporting, wizards, etc..) that are completely decoupled from the business domain in question? Can we even entertain the thought?

To me, the NakedObjects framework is a proof of concept. It demonstrates that it is indeed feasible to implement many of the various concerns of application development generically. Usually the tradeoff is adherence to certain framework conventions, though others have shown that many of these conventions are not absolutely necessary.

Look at the scaffolding generators in Ruby on Rails. Trails is another project that embodies these same ideas. The idea is basically that a domain model can be constructed that is to a large extent ignorant of the context it runs in. This sounds like the Spring Framework and Dependency Injection. But it goes well beyond injecting transactional rules or turning JNDI on its head. Indeed, a long time NakedObjects proponent, Dan Haywood, is working on his own framework (see Essential), and is leveraging the Spring Framework for it. The Naked Objects folks have recently coined the term "The Naked Objects Architectural Pattern" to categorize frameworks that adhere to their architecture concepts and ideas.

In Ruby, one uses the piece of metadata :attr_reader to tag fields that one wants to expose with getter methods. In NakedObjects, there's a fieldOrder piece of metadata to relate how fields should be laid out on a form in a user interface. It is specified in a manner analogous to Ruby's :attr_reader. This manner of specifying metadata is also in line with the DRY (Don't Repeat Yourself) principles given to us by the pragmatic programmers. It expresses our intent succintly and without duplication.

Let's set aside the "can it be done" question for a moment and envision the rewards. What do we have to gain as an industry if we manage to develop a system that provides generic implementations for these generic aspects of business application development?

Imagine an ecosystem, similar to Eclipse, but not for tooling. Instead, this ecosystem would be a runtime infrastructure ecosystem, where providers supply competing implementations of these various concerns (this is what Rails is evolving towards by the way).

developers would spend the vast majority of their time directly addressing customers' problems
conversely, very little time would be spent building software infrastructure
software infrastructure would become standardized
development time and cost would decrease dramatically
infrastructure components would be of higher quality
the size of the code that pertains directly to a specific project would shrink dramatically
our abilitly to read, understand, and extend other people's code would likewise improve
we would have true decoupling of concerns
the developer would simply plug in their object model (the data and behaviours) into a an infrastructure that would supply everything else
we'd be able to pick which aspects we want to include in our application at deployment time (the true, original vision of J2EE by the way)
our applications would inherit new features when infrastructure upgrades came along, without even altering a single line of code in our applications

I'm not even mentioning the benefits to developer-customer relations, the closer mapping between a user interface and its object model with direct benefits to customers' understanding of the logic behind a business application (hence the term "Naked Object").

Aside

Many people have been saying "Move over Java, Ruby is the new language in town." I do agree to some of the arguments but not all of them. How much of this is a language issue? I do admit that maybe implementing such a system is easier and simpler in Ruby. But that does not mean that it cannot be done in Java. Java has reflection. Java does not have mixins. Java has AOP. So there are tradeoffs. I suppose if you really want to do it from scratch, Ruby might be a better choice, from a certain point of view. If you're building a rich client that needs to run cross-platform with a minimum of fuss, I'd say that Java is the better choice. Smalltalk could be just as good a choice, perhaps a better one. Paul Graham says it's LISP and I know he's got some very good reasons.

My contention is that the debate has been focusing disproportionately on the language as the root enabler of frameworks such as Rails. The ecosystem I dream of can be constructed in Java. We would reap serious savings in development time, development cost, similar to the time and cost savings that are being boasted about by the Rails community.

I have developed my own framework that embodies these ideas. At this time, this framework addresses only workgroup business applications. It does not tackle the important issue of transport. I have recently employed this framework to construct a small solution for a customer. The numbers are in line with my expectations. On this particular job, I spent under two weeks implementing the solution when the original estimate had been in the order of two months. So how much does this have to do with language?

Virtues of Window Managers

Eitan — Fri, 07 Apr 2006 12:46:00 -0500

I have been using linux on the desktop for about a year now. I do love it.

Like most people, I do have a penchant for a great desktop and lots of critical opinions about what makes a good desktop.

I must admit recalling using windows with joy a decade ago and how productive I could be in that environment (windows 3.1, windows 95).

The two virtues I look for in a good window manager are:

performance
stays out of your way, allowing you to be productive

ok, now that I think of it: keyboard accessibility is also very important to me.

As I try to rate Gnome and KDE against these qualities, I find that Gnome has had less than perfect performance but has done a good job staying out of your way. I also rank it highly on keyboard accessibility.

With KDE the opposite seems to be true: the performance is great, but I found myself continually futzing with it, being distracted from the work I actually needed to do.

So I have been a Gnome user, and a happy one at that. I'm also looking forward to Gnome 2.14 and Dapper Drake, which will improve the performance of the window manager.

I'm also looking forward to a year from now where Core Duo notebook prices will be lower, and the improved performance that will come with it.

I suppose I should also say a word about the MacOS. It stays out of your way nicely and it's fast. The problem is that it ran on hardware that was slower than a snail (the G4). They fooled a lot of people into thinking the G4 was a fast processor. Anyhow I digress and Apple is not what this blog entry is about.

So I am writing this as I download Xubuntu: Ubuntu + Xfce window manager. I don't know why I overlooked Xfce before. I just checked out the screenshots and the movies and it appears to be what I have been looking for all these years. The price of ignorance is indeed high. I hope in a future blog to recount how things go between me and Xfce.