Eitan Suez's Blog

May 2005 Archives

Getting to know each other

I've been pleansantly surprised to discover how strong of a bond my JUG affiliation has turned out to be. I have to refrain from the desire to call our community a clan. :-) I feel fortunate to have had the chance to visit various JUG communities in the USA, thanks to my participation in the 'No Fluff Just Stuff' conferences this year.

Being a member of the java.net JUGs community has been fun, though a fairly passive experience. That is, until now. I'm glad to now have an active role with the java.net JUGs community as one of its leaders. I recently discussed an idea with Bruno Souza (long time java.net JUGs community leader) and I sincerely hope that you'll find this to be a good idea for our community: JUG Profiles.

The idea is simple: let's get to know each other! The physical distances between JUGs are great and they're sometimes hard to overcome. One of my goals for the next year is to periodically feature a Java Users Group on the JUGs community web site.

And so I'm proud to announce that our first interview is now published: a JUG Profile with JUG.RU (JUG.RU is based in St. Petersburg, Russia). I'd like to thank Yakov Sirotkin (who coordinates the JUG.RU meetings) for volunteering to do this virtual interview with us.

Come check out the JUGs community web site and let us know whether you'd like to share some of your local JUG experiences with the JUG world at large.

from "an nfjs weekend in denver" to "the hyperlinks of the mind"

i'm sitting at the terminal of the denver airport, another nfjs weekend behind me. as usual, i'm never let down by these conferences. i get a boost of energy from standing in front of and interacting with my peers. it's fun to hang around people who can understand you when you speak. this reminds me of three things:
1. a lunch meeting in dallas with my good friend glenn vanderburg and my brother (a non-programmer). glenn and i abused our time together to talk about coding. my brother made me laugh afterwards when he told me he didn't understand a word of the gibberish that glenn and i were exchanging with each other.
2. i've always been able to talk to my wife about programming, even though she's not a programmer. i don't take for granted the fact that i'm able to do that
3. i recall something that ted neward has said before, as advice to all of us programmers: "pair program with your spouse." i've been meaning to try this out though for some reason up until now i've forgotten to follow through. actually, my daughter is turning six this july. she's getting good with the piano and like all fathers, i'm so proud of her. the time is approaching for her to become fluent in typing on the keyboard..and more importantly..for me to start pair-programming with her.

it's funny how thoughts tend to wander so far from their original intent. following the hyperlinks of the mind..that's what i like to call it!

"the rate of change" exemplified with gmail

so the world's getting smaller and time's being squeezed, and we all feel like we're a few hundred internet years' old. things don't seem to let up either. the topic of this blog entry is the amazingly short amount of time it took for google mail to become the new defacto email client for the world. only yesterday everyone was using yahoo. now the new game is gmail. forget 'around the world in 80 days' (or in 48 hours). gmail hasn't even had time to get out of beta!

realizations come to us often when we least expect them. and so this one was no exception. i'd just finished giving a talk to the boulder users' group (a few weeks ago). one of the attendees told me his email address for me to jot down in my text editor (or address book, i forget). and started: "it's [username]@gmail.com." and then he quickly realized he'd made a mistake and corrected himself: "..oops, sorry i meant [username]@yahoo.com." the more i thought about this incident, the more i was amused about it. that's it: yahoo mail has been supplanted by gmail and it feels like it was only yesterday when the world of email ran on yahoo. it's interesting to see how there's nothing like a little (or a lot of) competitive pressure to get a company to change. the entire yahoo site's gone through an overhaul recently. the old serif font family has finally been replaced with the more modern-looking sans-serif and the site is sprinkled with nice fresh shades of spring.

the world is changing more rapidly than ever. i wonder..will change still excite me as i get older?

o/x mapping's the word

one of the talks i give on the nfjs symposium is "xml data binding with [dennis sosnoski's most excellent] jibx." well, i've come to the conclusion that i'm tired of repeatedly saying 'xml data binding.' it's a mouthful, it takes too long, and it doesn't help much when i try to relate xml data binding to database data binding.. i mean: o/r mapping. so i've just decided that o/x mapping's the word. for one, it's easier to say; conceptually it's a "raprochement" to o/r mapping, and the bottom line is that it feels better (at least at the moment, though i think it's gonna stick).

what do you think? are you tired of the term 'xml data binding'?

well, there it is: a new term for an old friend: o/x mapping.

there's nothing like a little pressure to help me learn something new..

i've been procrastinating learning IDEA for weeks now. the truth is i didn't really have any pressure to. i've been using eclipse 3 since 3 was in M2 i think and that environment was cozy and familiar and productive. well now that i've upgraded my mac to "tiger" and that for some strange reason eclipse is basically hosed..the pressure finally arrived. all the talks i give at nfjs conferences have a strong hands-on component and i perform almost all of these hands-on coding sessions in eclipse. so i quickly gave myself a crash course in IDEA and netbeans and it was a great learning experience.

i now have a really good feel for the state of most major java IDEs: netbeans 4.1 which just came out, intellij IDEA 4.5, and eclipse 3.0. i've been wanting to try the ant features in netbeans for a while. i have to take my hat off to the netbeans folks. this IDE has gone through many enhancements since i last used it. i have to admit it: it's quite snappy and the environment felt very natural. but i also have to admit that there were a few small kinks that finally swayed my decision to go with intellij in the end. the file templates feature in intellij is pretty awesome. it's really hard to say that one IDE is better than another. they each have their strengths and they're each evolving quite nicely. i'm kind of excited about what IDEA 5 will look like.

my main impressions however are that swing apps are faster than swt apps. that swt apps on macosx have problems. and that it's a real shame that macos does not pass through the command-space shortcut to java applications! i'm big on shortcuts, and very particular about which shortcuts i use. i try to use the same (or very similar) key mappings across all my editors.

it's never easy to break old habits and form new ones. habits are the cornerstone to productive use of computer applications. well, i can now finally check off 'learn IDEA' from my to-do list. wish me luck this weekend. :-)

business applications development: piecing the puzzle

extreme programming tells us:
don't waste your time building features that you don't even know yet you're going to need

that's so true and many of us have in the past been bit by this tendency to try to
forecast a need.

however, i find that one can look at software application development in general and come
up with a list of infrastructural tasks that are performed repeatedly and menially each
time.

that is, that there is room for improving the general productivity of software developers.

more specifically, if we look at the class of applications known as business applications,
we will find that irrespective of the domain model, support for the following basic features will
always be needed:

1 persistence
the basic ability to store and restore objects from a persistence store
2 object lifecycle management:
creating, viewing, editing, and deleting objects
3 validation
ties in to object creation: what consitutes a valid entry for an object:
which fields are required, what is the set of valid values for a field,
etc..
4 defaults
prototype objects for types
5 search / query
the ability to perform searches / queries against a large repository of objects
6 reporting
for a search, the ability to customize what specific fields to return, in what
order, and how to dress it up for printing (or producing pdfs)
7 authorization
who is allowed to view, edit, create, and delete objects
8 calendaring / scheduling
for objects that are 'schedulable', the ability to view these objects in some
sort of calendar layout, and the ability to perform scheduling activities on
them (change time, date, duration, etc..)

i haven't bothered to make the above list complete. other services should be
on that list (remoting, other aspects of security, transactions, registries,
directories, and in general: guis, and state management, internationalization,
localization).

irrespective of the object model in question, these services are going to be required.
i think this idea is the basis for j2ee:
the notion that there exists a list of services that some kind of container or framework
can supply that should not be reinvented each time.

i've heard gavin king rightly complain that [in some respect] the vision for j2ee has
not been realized to its potential in that the list of services has not really grown beyond
the original set:
security, transaction, jndi/lookup, remote connectivity, persistence, authorization,
application management

my contention is that there can/should exist [in the ideal] a container for running business
applications that provides support for all these services [1-8 above] and more.

i can imagine an ecosystem where service providers with expertise in specific [shall
we call them..] aspects of business application development can plug in alternative implementations
for services into the business application container.

here's an example of something that has always disturbed me:
the fact that a software developer has to make a choice whether the gui for their
software application should run inside a web browser or whether it should be implemented
using a different toolkit such as swing.

again, i can imagine a business application server/container that gives you the choice.
just like persistence, the ui is orthogonal to the business domain. so the basic idea
is that the developer concern himself/herself only with supplying the business domain
in question: the implementation of the object model.

the end result should be an app whose objects can be created, edited, viewed,
browsed, searched, reported upon, and much more.

i can think of two frameworks that, at first glance, one might think: "there cannot
possibly exist another pair of frameworks that are as far removed from one another, that
are as polarized from one another." these two frameworks/containers are:
j2ee
nakedobjects

yet i've come to realize that these two frameworks have much more in common than
first meets the eye: they both attempt to provide a framework or container
that generically solves certain aspects of business application development.

the difference lies in the choice of services that each has decided to support.
j2ee makes security and transactions generic. nakedobjects makes the ui generic.
there actually is an overlap: they each address (or try to address) the problem of
generically persisting objects.

in the meantime we saw o/rm vendors solve that problem properly. yet there'd been an
"impedance mismatch" between the o/rm solutions and the container designs.
the o/rm solutions could not be plugged in to a j2ee or nakedobjects container with ease.
this is in my mind what ejb3 solves: the mating of the right o/rm solutions with a
generic business application server/container. or the formal separation of these
two concerns: the container and the persistence manager.

robin roos (of jdo fame) has recently made a number of postings to the nakedobjects
mailing list. one of his messages dealt with the issue of being able to plug in
a jdo-based persistence mechanism into nakedobjects.

so, the vendor that builds the container should not be the vendor that provides
the service. well, they can be, but we should recognize that the two require
expertise in different domains.

what i want to see is more of a "unified field theory" for business application containers
and services, so to speak. a generic blueprint for plugging in services into a completely
specified container, including services that have not even been thought of or
identified today.

let's talk about Ruby On Rails (RoR). It fascinates me how all of these disparate
discussions and disparate solutions are all part of one large problem. sometimes
it's hard to see. i am no RoR expert. in fact i'll admit it: i have only skimmed
the RoR web site thus far.

i believe that the success of RoR stems directly from the fact that it exploits
the redundancies that exist today across the development of business applications:
the fact that developers today manually do things that a container could do for
them, for free:

1 persistence
the basic ability to store and restore objects from a persistence store
2 object lifecycle management:
creating, viewing, editing, and deleting objects

and more. RoR delivers on that. and it makes developers much more agile.

if i understand it correctly, many of RoR's design ideas were inspired by the
NakedObjects (NO) framework.

so my forecast is that such an ecosystem will come to be. RoR so far looks
like the one leading the race.

tales from colorado jug visits..

in april, i had the pleasure of being invited to speak to the denver and boulder java users groups (colorado). being active in my local jug in austin (texas), the experience was a familiar one. to put it plainly: it was a blast.

for the last three to four years i've been a regular attendee of my jug. that last tuesday of the month when the jug meets has come to be known in my household as my 'night out.' for me it's true fun and recreation. i enjoy getting together with other programmers and talking about code, and the practice of coding.

being at other jugs has started to feel like visiting extended members of a large family.

i found the denver jug (djug) to be a very well organized and energetic group. the meeting was in a beautiful auditorium in the middle of downtown denver. the djug is composed of seasoned professionals who really know their stuff, who are on top of their game, and who really enjoy what they do. they hold two back-to-back full-length talks at each meeting! my austin jug also holds two talks but the first is a short talk (we call it our technotizer). scott davis gave the first talk. i can't tell you how much i learned from him. i particularly enjoyed hanging out afterwards at a nearby brewery. it gave us a chance to sit and talk and get to know each other. that evening left me full of admiration for the djug and its members, and with a few ideas for jug practices that we might consider adopting in austin.

i can't stress the importance of communicating with other programmers. if we really care about our craft, we can learn so much from each other. that's something i personally always try to work on.

speaking to the boulder audience was equally enjoyable. the setting was completely different: an academic setting in a typical university lecture room, complete with blackboard and chalk! (though i didn't really avail myself to it). we even had to switch rooms in the middle of one of my talks (there was a mixup in room reservation, given that many groups try to meet on campus after hours). although at that moment i didn't think it was very much fun, in hindsight it was perfect: it just added to the sense of being at a university. again, the calibre of my audience was very high, so much so that my talks often feel more like peer-to-peer discussions at times. there's always a thing or two i learn from some of my attendees, and that keeps things fun and interesting for me.

You can check out the denver jug's web site at: http://www.denverjug.org/
The boulder JUG's home is hosted on JUGCentral.com

reflections on hibernate..

i've been meaning to write about my impressions/experiences with hibernate for a while now. for some reason i've been putting it off..until now. i've been using hibernate for maybe a little over year. i'm still using the latest 2.x implementation (i haven't yet had/taken the time to migrate to v3.x). in reflecting about hibernate over this period of time, a number of its characteristics have really struck me, impressed me:

- i find the hibernate api does an excellent job of making sure that the concerns of the api do not leak into the client application. the primary authors of hibernate (gavin king, christian bauer) stress this important issue in their book. i believe they were really true to their word with respect to hibernate.

- o/rm apis by definition are a layer on top of the database's own interface; they act as a buffer and decoupling layer between your code and the database. sql is one of those staple technologies that would never go away because very few o/rm apis were able to successfully supplant it. i find that hibernate has been able to do just that: with hql and its other mechanisms of querying a database (e.g. the criteria api), hibernate has successfully taken root and i believe is on its way to supplanting sql.

- i also find hibernate to be true to the mantra of keeping simple things simple and making more difficult things possible. that is, for most things hibernate mapping files work very well. however, if you have more complex situations, there's usually a way for you to plug that behaviour in to hibernate via its various interfaces. the examples that i've used, that come to mind at the moment are these interfaces: UserType, CompositeUserType, and PropertyAccessor.

i realize that such features have become more the norm than the exception these days, but not only do these extension points (and others) exist, but i've found them to work well in practice.

there are other features in hibernate that i've resorted to as i wanted to model more complex or special relationships and each time i've been pleasantly suprised that i was able to make things work the way that i expected them to. Here are some examples:

- although it's discouraged, I find "any" type mappings wonderful, and the same goes for many-to-any type relationships. that's what i use to model relationships betweeen types that don't follow an inheritance model, but rather an interface model.

- I also leverage hibernate Components extensively for modeling composite/aggregate types and have had good success with it

- I have been able to leverage the criteria api to the max. from the hibernate documentation i infer that there are two camps when it comes to a preferred query api. quoting the character 'tuco' from the film 'the good the bad and the ugly': "there are two kinds of people in this world my friend, those who like hql and those who use the criteria api." :-) anyhow, what _i_ particularly like about the criteria api is the fact that it has a one-to-one mapping/correspondence with the way one would model a query in a gui. i am _very_ "big" on having (or being close to the ideal of) a one-to-one mapping between guis and their underlying object model.

so, in a system that i'm currently developing i have generic query gui capabilities built right on top of the criteria api and it works like a charm: against any of the types in my business model.

many folks in the hibernate community were waiting for projection features which were delivered with v3. this is one of the main reasons that i will eventually upgrade to v3. for now i'm pretty happy with an unofficial patch to 2.x that gives me a simple but essential feature: Criteria.count()

so i really want to give kudos to the people behind hibernate who imho have produced a really terrific o/rm solution. i haven't even brought up caching or the myriad of hibernate tools or the fact that concerns such as sql dialects are becoming a thing of the past thanks to products such as hibernate.

i'd also like to touch on is hibernate, the open-source project. there are many open source projects out there.. and in terms of their success they span the whole spectrum: from entirely obscure to wildfire adoption. very few have had wildfire adoption and hibernate is one of those few projects. there's a tremendous community behind hibernate. being able to make that succeed is not easy. it's too hard to try to explain what secret ingredients go into making a successful project and the hibernate project web site discusses what they think the right recipe was for them (see why is this project successful). i'm not going to say that hibernate is necessarily a model example to follow. it's a fairly difficult and complex question to analyze: what makes a project successful? oftentimes the reason is that the project tackles a serious and very common problem that 99% of us have. so, a terrific solution to something that is not so much of a problem will likely never reach wildfire adoption. nevertheless i agree that it never hurts to do the things the hibernate project team does: reply to questions on the mailing list, listen to your users, fix bugs quickly, have excellent supporting documentation, web site, wikis, forums, and much more.

lastly, it is not my intention in this blog entry to even have an opinion on the whole debate regarding jdo vs hibernate vs other orms. i simply am discussing an api that i happen to have picked and used and have gained experience with.

i'd be curious to hear how your experiences with hibernate compare to mine. thanks.

"Grazie Signore" Moments..

One movie that made a strong impression on me was the classic "Amadeus." Salieri, one of the main characters and a contemporary of Mozart, is often depicted (like most of us mere mortals are) as someone who can compose music but is nowhere near as quick or talented as Mozart.

There's a specific scene where Salieri is composing music, one small step at a time (one note at a time!) and derives great satisfaction from the task. He then pauses to thank the lord (in his native [Italian] tongue) for having given him his musical talents and the opportunity to practice music composition: "Grazie Signore."

I can't tell you how many times I find myself in such a situation. Every day we code. The going [for me] can be slow but things do move forward and progress. Every so often I pause and admire a new feature I've added to a system I'm working on and get a terrific feeling of satisfaction, just like Salieri did in Amadeus.

Dave Thomas (the Pragmatic Programmer) is right: many trades have much in common: composing music and writing software for example. Dave often talks about 'the art in programming' and I agree with him wholeheartedly: there's art in programming and there's also a certain dose of engineering in art.

a java programmer's first impressions of the macosx v10.4 upgrade..

~ 12 hours ago i upgraded to macosx v10.4. here are my first impressions..

terminal/shell i/o is faster

eclipse editor is faster
eclipse command completion mysteriously works now.
i mean, it worked before but half the time it would complete something entirely erroneous; not anymore! (that used to be the most annoying thing for me. i didn't expect the upgrade to fix that. i can't tell you how happy this makes me)

the eclipse improvements must be due to improvements in the underlying carbon api implementation. still no ability to navigate treeviews from the keyboard alphabetically though (that is, you can navigate a tree using the keyboard arrow keys, but not by typing the first letter of an entry).

swing apps: i had to stop using the jgoodies "looks" look and feel. when using it, invoking menus and popup menus throws a nullpointerexception. i'm still using a 1.4.2 flavor. i'm not going to waste any time at the moment to try to figure out what's causing this.

i've upgraded fink but i'll have to wait a few weeks until i can restore my fink apps (gnucash primarily)

i turned off spotlight. for some reason i didn't feel like waiting the estimated 22 hours for the indexing of my disk to take place. i realize the estimates are often wrong and that the indexing may in the end take much less time. but it tortures me to have to listen to that foresaken powerbook g4 fan blowing hot air out of the innards of my laptop, trying to chug through the necessary computations. it's not like i've needed to find stuff on my disk anyway. i also had to disable the 'command-space' shortcut that spotlight hijacked away from me.

bummed about the whole java 5 no-show on osx. i've been really torn about which way i should go with my next laptop (another osx laptop or linux). my 1ghz tibook is getting old.

i almost fell into the common trap of getting the impression that very few things have changed simply because the desktop's look hasn't changed that much. one (me included) should not forget that many improvements are not necessarily visible from the perspective of the end user running guis.

dashboard is cute but i wish it got less exposure. what's the big deal anyway? i turned it off for now.

i still plan to migrate to intellij. migrating ides for me is a big deal. it's almost like switching operating systems. in order to be productive in an environment you really need to know that environment. many keyboard shortcuts are different. trying to change the keyboard mapping is not that simple either. you end up trampling over other mappings and then rethinking things. so i realize it's going to take me a while.

mail.app: it sure would be nice to be able to perform a search based on more than a single criterion! yes, i can create a 'smart folder' in which case i get this dialog where i can specify as many criteria as i wish. but why on earth can't i do it for transient/non-stored queries??? (i mean, directly from the main window?).

well, that's it for now. overall (and so far), i'm happy to have 10.4. to have eclipse run even a tiny bit faster is a godsend. the system is stable. the upgrade was flawless. i'm really impressed there. all my daemons kept running. postgres, apache, etc.. upgrading is a big deal and correct timing is very important (e.g. i have to do without certain fink apps for a few weeks). so thank you apple for a mostly positive experience, for not breaking anything really important to me, and for improving the carbon layer.

This work is licensed under a Creative Commons License.