Posted by Eitan
Wed, 19 Aug 2009 19:05:00 GMT
I remember around 2001 I was working on the user interface for a project (which I later open-sourced) for browsing javadocs that had been stuffed into a relational database. The UI was very advanced for its time, employing css, javascript and "dhtml" (as it was called in those days). I was quite satisfied with the end result, with one exception. The ui looked great. Most pages (for example a page presenting information about a class) were laid out as a tabbed pane. Most of the tabs were prepopulated with information from a single http query. But the last tab actually required a trip back to the server. It's a problem that bothered me, but that I didn't pursue a solution for. Had I done precisely that, I would have come to the conclusion that I needed an AJAX call, and would have likely started using and exploiting AJAX in user interfaces perhaps as early as 2001-2002. Instead, I just watched the phenomenon happen a few years later.
Separately, I recall when speaking on the NFJS conference circuit, developing a talk on CSS. At the time the state of things was not so rosy. This was before the days of the javascript frameworks. As I developed my materials, I'd created a site that I called the "CSS repertoire," (see http://u2d.com/css/ ) that exposed my thoughts and various UI design patterns that I'd collected. Most of those lessons I'd learned as early as 2001. In some of the essays on that site, I complained that the power of CSS selectors should be accessible from javascript, and should not be strictly the domain of styling; that it had broader applicability, and that it was a focal issue that needed to be addressed. I had little hope that the standards makers and browser makers would react to this need in a timely fashion (they have yet to do so), and believed that this gap should be filled by them. Again, rather than tackle the problem, I sat back and watched how others addressed this problem directly in javascript frameworks such as jquery, which today fill that gap.
What's the moral of the story, perhaps besides the fact that I'm a lazy bastard? Well, I think I can draw a number of related points here:
- innovation comes out of tackling the problems one confronts when one comes up against an obstacle,
something that the current technology does not address; these may be "last-mile" problems, not essential to the success of the project at hand;
- one must be involved actively in projects and building the systems of today. it is out of this work that today's problems are identified, and present a path for building the technologies of tomorrow;
- don't leave well-enough alone: one must have that sort of mind that's obsessed with perfection: "Yes, the system works well enough, but observe this flaw here. Why is this solution not satisfactory? What's the root problem? Why don't we have a solution for it? What's the required solution?" and finally.."Let's go for it!"
As a related example, I recall watching the now famous google wave video that came out of the google i/o conference 2009. This innovation precisely came out of this tenet of "don't leave well-enough alone." GMail is great. But they realized that it could be done better. They identified aspects of GMail such as modeling discussion threads, and asked themselves some very important questions, but mainly: "Can it be done better? Is there a simpler or more elegant solution?" etc.. And what they came up with and presented at google i/o did not disappoint.
I believe that there still remain many stones that have not been "turned over," so to speak; many opportunities for improving the state of the art in business applications development. What will I or you do differently this time to not become just a witness to the phenomenon, but to play an active role in making it happen?
Posted in Programming | no comments
Posted by Eitan
Thu, 15 Mar 2007 03:36:00 GMT
Thought I'd share this adorable picture of my little one..
no comments
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
Thu, 18 May 2006 01:16:00 GMT
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.
no comments
Posted by Eitan
Wed, 17 May 2006 23:45:00 GMT
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! >>> 
no comments
Posted by Eitan
Tue, 02 May 2006 14:36:00 GMT
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.
no comments
Posted by Eitan
Mon, 01 May 2006 18:44:00 GMT
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.
Posted in Programming | no comments
Posted by Eitan
Mon, 01 May 2006 18:14:00 GMT
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.
Posted in Programming | no comments
Posted by Eitan
Mon, 01 May 2006 12:21:00 GMT
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.
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
