Posted by Eitan
Thu, 01 Feb 2007 15:27:00 GMT
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
Posted in Java, Announcements, jMatter | no comments
Posted by Eitan
Wed, 19 Apr 2006 17:00:00 GMT
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?
Posted in Java, jMatter | no comments
Posted by Eitan
Fri, 07 Apr 2006 13:26:00 GMT
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!
Posted in jMatter, Java | no comments
Posted by Eitan
Fri, 07 Apr 2006 13:19:00 GMT
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.
Posted in jMatter, Java | no comments
Posted by Eitan
Tue, 04 Apr 2006 14:49:00 GMT
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?
Posted in Java, jMatter | no comments
Posted by Eitan
Thu, 16 Mar 2006 04:10:00 GMT
Like many others, I recently read Graham Hamilton's AOP: Madness and Sanity
For some reason though, the rebuttal won't leave my mind. Maybe I can get this off my chest with a small blog entry.
OOP has inheritance. Inheritance I'm coming to think is a form of AOP. You can subclass an existing class, override a method, and voila, you can have around() advice for free:
public void overriden()
{
before();
super.overridden();
after();
}
Also, inheritance has already done to OOP what Graham fears will happen to programs when people start using AOP: make them confused. Many times as we read OO code, we wonder why our application is behaving in a certain way. Oftentimes we discover that we overlooked the fact that an inherited class overrode the behaviour we expected to be invoked. Or sometimes we expect to find a method or field in a class, and then say "ah, of course; it's not here because it must be declared in a superclass."
IDEs and Javadocs help us with our confusion by telling us: "this is the list of classes that extend this one," or "here is the inheritance hierarchy for this class," and so on.
So with AOP things need not be any more confusing or any different. Soon we'll be able to easily ask similar questions: "show me a list of all classes that advise this method or class," for example.
I guess what I'm trying to say is that AOP need not be looked at as something so foreign to the way we already program. Instead I like to think of it as a fairly natural extension of something we already do. We just have more flexibility in terms of how we go about solving problems, modeling things, keeping things more refactored. That's what AOP gives us. No code duplication: going from somewhat DRY to really DRY.
Posted in Java | no comments
Posted by Eitan
Fri, 17 Feb 2006 13:59:00 GMT
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
Posted in Java, jMatter | no comments
Posted by Eitan
Tue, 31 Jan 2006 13:43:00 GMT
One must applaud Bob Lee for saying what many of us never dared to: I don't get Spring. I think many of us for a long time did not grok Spring either but were afraid to say it. Everything has a reason to exist and Spring is no exception.
I believe today I grok Spring a little better than before, but I'm not sure. Below is a snapshot of my continously morphing hypothesis, as it stands today, on January 31 2006.
Spring solves a number of issues that derive from a not-as-natively-implemented feature of the Java language: closures. In smalltalk, ruby, and JavaScript, treating a method as an object is a much more common thing. And thus using a method as an object is much more commonplace. So things such as Spring's *Template classes are altogether unnecessary unless you're working in Java.
One of the end results of applying Spring to a project is a combination of Java and XML. You inevitably end up with two languages instead of one. Interestingly, this aspect of Spring is directly related to a blog I wrote recently (two weeks ago, to be exact): Skip the Compile.
There are concerns in Java that don't exist in other languages. One of them is the compile step. Removing that issue leads to Internal Domain Specific Languages, the very solution to the Java+XML conundrum.
So by attempting to grok Spring, I am coming to the conclusion that Spring is an artifact that attempts to make some of the pain of working with Java go away. It does a pretty good job in some respects (I consider the fact that we still have a bunch of XML a down-side). But when we look at other languages, specifically at Smalltalk, we see a much more elegant solution: these problems simply don't exist. Everything is written in-band. I advocate that it should be.
Posted in Programming, Java | no comments
Posted by eitan
Fri, 20 Jan 2006 23:05:26 GMT
As I was coding today, I started thinking to myself "I like IntelliJ IDEA."
I've been using this IDE for almost a year now. I recall what forced me to finally seriously use IDEA: I had been using Eclipse on MacOSX (don't!) when it finally died after Apple introduced Tiger. Man that feels like a long time ago. I am sooo at home on Ubuntu these days it's not even funny. Anyhow, Eclipse really rocks on Ubuntu. Netbeans does too. Still, IDEA is my preferred tool. I'm still not using it to the max but I really like the performance of IDEA on Java 5 on Ubuntu on my Medion laptop (Pentium M 730 I believe), the feel of things.
Anyone know of a good way to integrate XDoclet with IDEA? The question may be premature.
I just checked out JetBrains' web site and noticed they received the "Best IDE" award from the JDJ for 2005. Congratulations guys! Keep it up.
Posted in Programming, Java | no comments
Posted by eitan
Tue, 17 Jan 2006 23:28:33 GMT
I'm about to check out TestNG for the first time. I have the documentation printed in front of me and hope to take it for a spin shortly. So I read the TestNG web site's front page. I followed the three links from the front page to three blog entries by Cedric Beust that essentially describe issues he has with JUnit. Cedric's arguments are not convincing.
Here's is my understanding, let me know if I'm wrong:
One of the principal ideas in JUnit is to use the Method as as an analog to a generic block of code: in this case, a test. A method is a test. Don't think of a method as a method. Think of it as a test. Cedric is confused, and rightly so: JUnit test classes are not really classes in the way they were meant to be used by the language designers. He is confused that the class constructor is invoked once for every test that is run. That is, once per method. This is contrary to everything we've ever been taught about OO. Why is this so? Well, it's very simple. Imagine having to write a new class for every single test we wanted to run. It's tedious. It's overkill. The 1-1 mapping of method to test is much nicer. Furthermore, related tests can easily be grouped together in a class. JUnit does its magic behind the scenes, it uses reflection to introspect matching test methods and, in a sense, instruments them for testing. It invokes each in a specific context that ensures isolation from other tests, etc..
What I'm interested in though is in a generalization of JUnit. Grasping the essence of the pattern that JUnit employs is most important. The idea that one could, in general write a class with a bunch of methods and, separately, write a harness that does something else with each method, in a similar way, but where one can customize the context in which the block of code is run.
Take for example, the simple desire or need for someone to learn Hibernate. There's a lot of setup and tearndown that goes along with running all kinds of "tests" to learn the Hibernate API: obtaining a session, beginning a transaction, running the "test", commiting the transaction and "closing" the session. With a generalization of JUnit I would write tests that could be run in a slightly different context where each test method is called in a context that repeatedly does the mundane: opens the session, begins the transaction, calls the block of code, commits the transaction, closes the session, and on to the next test.
Then you can use some kind of flexible runner application to pick which tests you'd like to run. Actually, that's one of the features of IntelliJ IDEA that I really love: the ability to run a single test directly from the IDE, without having to fuss with ant or setting anything up.
What I'm wondering at the moment is whether that "Generalization of JUnit" I'm seeking (though it might be actually trivial to write) is not called "The Spring Framework." Spring employs this pattern over and over again in all kinds of circumstances. What I don't know at the moment is whether one can customize it. This pattern actually is native to smalltalk and ruby (and requires no "framework" to enable). That explains why Kent Beck used it when he wrote JUnit.
Posted in Programming, Java | no comments
