Eitan Suez's Home: Category jMatter

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

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?

Movies!

Eitan — Fri, 07 Apr 2006 08:26:00 -0500

Yesterday I stumbled across a most excellent utility: vnc2swf. It uses vnc to record desktop sessions as a swf movie. Pretty nifty.

So I played around with this a little and put together a really rough cut of a session with a jMatter demo application that I built a year ago in 3-4 hours' time: the NFJS Manager.

Check it out!

Recent jMatter Enhancements

Eitan — Fri, 07 Apr 2006 08:19:00 -0500

I strongly believe that the shear amount of features I have put in to jMatter is impressive. That sounds really corny coming from me.

But think about it. Take the naked objects framework as a comparison. They do a monumental thing by providing a user interface for your model objects. jMatter adds polymorphic support, search support, wizards, hibernate persistence, calendaring, validation, more data types, commands on value objects, persisted queries (smart lists), and more.

What I find interesting is that the number of ideas for features that I have is still as abundant today as it was a year ago.

Most recently, I added the ability to perform associations in place, via a new little widget that dynamically searches for objects of the matching type. Say, you're building a little flight planning application and you're defining a new trip from LAX to DEN. As you type the airport id, jMatter will perform a dynamic lookup. You just type "LA" and the handful of matching results are there for you to pick from. Press 'enter' and the association is made.

I also went ahead and made all listings' searches dynamic. I also recently licensed and integrated JExplose, a wonderful little expose-like utility for Swing.

I am discovering that changing one's mindset to embrace what is now termed "the naked objects architectural pattern" unleashes a new wave of ideas and creativity. Will the world catch on to this?

Anyhow, that's the update. Things are looking really good.

Data on jMatter

Eitan — Tue, 04 Apr 2006 09:49:00 -0500

Approximately a month ago, I contracted to perform a small software project using the jMatter framework.

I completed the project in a little under two weeks. The original estimate for doing this project without jMatter was in the order of two months. More specifically, the original estimate was 350 hours of development time, whereas I took 70 hours, using jMatter.

So, regarding the value proposition of jMatter: the license fee is $500 per year, and that's per developer. i.e. there are no deployment or royalty fees.

On a single project of the type I completed, the savings of 280 hours of development time, even at a modest rate of $65 per hour represent close to $20,000. That's 40 times the licensing fee, recouped in two weeks' time. Not bad.

Assuming you do twelve such projects in a work year, you're cashing in 500 times the licensing fee per year.

So, is jMatter a good value proposition?

jMatter is Here

Eitan — Fri, 17 Feb 2006 07:59:00 -0600

It's no secret that I have for a while now been a great fan of the NakedObjects framework.

Here are a few blog entries where I express opinions on software and software development that are congruent with its philosophy:

All the while I was slowly thinking about, slowly developing a system of my own, one that would embody my shaped, personal opinions on software development. I have built myself a chainsaw. A system with a user interface that is consistent.

This system now has a name: jMatter. It has a url, with documentation, screenshots, and more.

Rather than flaunt all of the goodies and features I put into this chainsaw, I would instead like to invite you to take a look. Follow the above link, read Chapter 1 (a total of four pages), and let me know what you think.

Sincerely,
  Eitan Suez

JMatter: Open For Business

Eitan — Fri, 27 Jan 2006 12:38:00 -0600

For a while now I have been developing a software application framework very close to my heart.

At last, this project is now a product, and will soon be available for licensing. I invite you to take a closer look at JMatter here.