Over the weekend I managed to get the Time & Money project repository migrated over to Subversion. It was a fun one because the modules needed to be rearranged into the directory structure that the team had worked out. I kept a log of my steps with the goal of turning that into a how-to that may be of help to other Sourceforge projects that have yet to migrate from CVS. I just need the time to make it more of a cogent how to and less of a stream-of-consciousness ramble.
So tonight I finally received the PayPal info to get registration set up for AJUG's Open Space event "The Practice of Java in Atlanta". I am looking forward to facilitating this event; the rich pool of Java talent in Atlanta should make for a passionate, dynamic group to hold conversations about Java and where it's going. If you're going to be in town, I can assure you that the $75 (US) will be worthwhile.
The last day of the Roundup was a lively one; perhaps the most lively in terms of sessions. Two of the talks I attended were centered around the possible forking of Java and Java Applet deployment in view of whether or not it's too late for rich Internet applications implemented in Java. It was a fun morning; I highly recommend the audio for these two sessions.
It was intriguing to listen to the postulations and concerns of participants over the possibility of Java forking. The majority of them are not participants in Free/Open Source Software; they would fall mostly into the majority category of consuming F/OSS, which explains many of their concerns. I pointed out that forks of significant projects are very costly, and must have their own community with a very good reason for undertaking such an arduous effort. In my view, the governance of Java as F/OSS will be what determines whether or not if forks. I believe some long-standing F/OSS projects' histories bear that out, based on what I have heard and read of Emacs, mutt, and similar projects. I think the parallel existence of the Java Community Process and open-sourced Java is going to be an interesting sociological experiment over the next years; personally I don't think they will coexist that well for that long.
In the discussion on Applets, we got into the issue of Swing's lack of a viable component model. One participant postulated that Swing was just fine when you "have experts who know what they're doing", and that (plus the 2 awesome 16oz. caffe americanos I had from Camp4 Coffee) prompted me to express the following view which I now share publicly before the rest of the world:
With all due respect to my fellow conference attendee, my view is that this "when you have experts" sentiment is a key reason why Java has only gone as far as it has. The bearded road apples (props to Scott Adams for that term) who insist on building their own everything have labored under a severe misapprehension. This particular air of condescension is what irks me the most within the Java community. It is that same spirit that disparages meaningful, productive suggestions as "syntactic sugar"; I hate that. Let's apply that reasoning to another area of everyone's everyday life.
Toilet paper is syntactic sugar. There's already an adequately functioning alternative for that given task, namely one's hand. So why not use that? It works, doesn't it? Yes, but I find the "syntactic sugar" of toilet paper to have a compelling "value proposition" (props to Joe Nuxoll for reinfecting my mind with that term ;-) ).
I don't want to wipe with my hand, and I don't want to use Java as my language for rich Internet apps, web applications, or anything else that is not heavy lifting to which the Java language is well-suited, which seems to be an ever-dwindling category of problem domains. The fruition of the dynamic has arrived; embrace it, you'll be glad you did.
It's been a great week; another wonderful Open Space event. Thanks, Bruce. Thanks, Java Posse. See you next year I hope.
We added lightning talks to the event, and it's been an excellent addition. From the highly-technical to non-Java-related, these were a blast. I missed the first ones, but this second night was a blast. Joe Nuxoll gave a pretty cool one on racing, specifically the topic of load distribution. I'd like to try some of it out, but not on the actual road. Joe's actually really into racing, and I enjoyed his passion for it as well as the information he shared. Joe Neely of FedEx gave a cool typography talk, and James Ward showed some cool Flex apps.
The day's talks were good as well, but I am not recalling the particular topics I wished to write about.
Skiing continues to be great; did my first jumps and some more mogul black diamond runs today.
One question I have had for practicioners who work in Java "off-the-server" is whether or not they really layer their application architecture for their applications. You hear people throw that use case around for lightweight, POJO-based frameworks like Spring and Hibernate, but I always wondered whether or not that really happens.
If the response to that talk is any indication, the answer appears to be a sound "no". The five or so people that showed up all worked primarily on server-side stuff, and none of them cited any layering of this type within applications authored by their organizations. At a conference about Java off the server, that surprised me.
Overall another great day both at the conference and on the slopes.
The Java Posse Roundup 2007 in Crested Butte, Colorado has the central theme of "Java off the server". Given that topic, why (besides the skiing) would I haul out to Crested Butte for this meeting? In short, I am here because I know what Open Space events organized by Bruce Eckel are like and I know there'll be plenty of topics that are not strictly "off the server". The first day already made good on that prospect. Heck, Python and Domain-Driven Design came up within the first topic I attended.
The initial conversation I participated in was related to the role of dynamic languages on the Java Virtual Machine (JVM) and their integration with Java even in their native implementations. Most folks seemed to agree that the JVM holds much promise as a platform with mature threading and stability for dynamic languages whose C implementations suffered in those areas.
As an Open Space veteran, a meta-topic for me is watching folks who seem to be unsure about whether or not we'll get anything done with this meeting format. I look forward to hearing their impressions at the end.
Skiing this week is excellent! Good snow, not too crowded, good weather; this will be a great time.
I wrote earlier about the apparent embrace of Domain-Driven Design (DDD) within the Interface21 team, the group behind the excellent Spring framework for Java applications. I have been thinking about why it is that Spring in particular would lend itself to the application of DDD.
I first expressed this during the review of the DDD track last Wednesday for the start of the conference. The escape from the productivity hit we all took with Java EE when Spring first began to be known was a big deal. The ability to have an layered, n-tier application that was testable out of the application container, with the ability to wire up a bean container's contents via a straightforward XML syntax breathed new life into many a tired J2EE web application. Lines and lines of tiresome boilerplate code for DAOs were replaced with clean, small implementations that extended the appropriate Spring template. The effectiveness of our domain models were about the furthest thing from our minds. Why didn't we immediately address domain modeling as soon as we had our sea legs with Spring?
I would say it's analogous to not being that concerned about what clothes you are wearing when you are starving to death. Remember Maslow's hierarchy of need from basic psychology in college? Few people whose physiological and safety need are not being met care that much about self-actualization. There are enough shops using Spring for there to have been two consecutive conferences dedicated to the technology. Spring is ubiquitious; that was the thrust of Rod Johnson's keynote today. It has proven itself as a productive, viable foundation of enterprise Java applications the world over. Given that foundation, there exists the capacity to ask, "how can we now move to the next level of applying Spring in the best manner possible?" Domain-driven design answers that question.
Domain-Driven Design is not easy, and many, if not most, technologies actually impede the application of DDD. This is where Spring stands out among the raft of framework options. It has always had the intent of staying out of one's way rather than attempt to infuse all of your code with its own prescriptive dogma (insert JSR of choice here). Spring stays out of your way, enabling the necessary insulation of your domain model. Since it is also Open Source software, there's no need to bolster a revenue model by implementing any such ugliness in an attempt to ensure vendor lock-in. The Interface21 group is freed of that burden throughy their choice of Open Source, they are freed to pursue excellence in the code unfettered by a need to drive sales of the software. Since they depend on revenues through services, they are driven to make the best framework possible that will be of sufficient utility for more people to need training and consultation they provide. The model seems quite sustainable, and I wish them the best.
It seems ages since I last wrote. There've been wisps of motivation here and there, but mostly from odd topics or observations. A few things have contributed to that.
My enthusiasm about software development ebbs and flows. At a visceral level, I love the craft. The creative aspects balanced with architectural principles can be fascinating, and are almost always challenging for any problem domain beyond the trivial. However, the forces that wish to subvert and pervert the craft into a means of capital gain sap my energy. At times it's downright depressing.
It's not that I am against earning money by developing software or helping others develop it; by no means. That's certainly how I provide for my family. The thing that totally turns me off is the agenda of most vendors and a certain contingent of programmers to portray software development as a deterministic, engineering process that is easily commoditizable -- if only you buy product X or employ heavyweight, tool-centric methodology Y. That lie has held sway over most of the industry for far too long, at the expense of the craft and all who participate in both the creation and use of software.
Another thing that has robbed me of enthusiasm for close to a year now was an emotionally demanding contract with a challenging client. I had to spend many hours dealing with the effects of the engineering/commoditization myths and the unrealistic expectations and unproductive results they yield on projects. Grinding against that kind of friction left me with precious little emotional energy, and I wasn't willing to spend that on writing and leave my family with even more of a withdrawn shell of a husband/father.
There have been a few things lately that have been a refreshing/renewing force in my software development enthusiasm. The first has been the practice of Domain-Driven Design (DDD). The frank attitudes about the rigors of good software development that best serves the stakeholders with flexible, extendible systems is so refreshing. An acknowledgement of development as primarily a creative process and less significantly an engineering process is a welcome message for me. I have begun collaborating with Eric Evans, author of Domain-Driven Design: Tackling Complexity in the Heart of Software and the person who first crystallized the concept of DDD as a practice. It's certainly been invigorating and I am being challenged to develop my domain modeling and design skills to higher levels.
The practice of DDD in and of itself is great, but enthusiasm for a practice without a community of fellow enthusiasts/practicioners falls mostly to the realm of wistful "shoulds" and "oughts". I am starting to see others, practicioners of the craft whose perspective I respect, also warm to DDD. Their reasons seem sound; they aren't attempting to accrete another buzzword to their repository. For some it even comes at the expense of having to point out flaws in their own past approaches (or those of their employers) to software development. It is my hope that their candor will be rewarded and not punished.
I write this from the hotel lobby of the Westin Diplomat in Hollywood, Florida. It is the day before The Spring Experience, which is the first conference I have seen with an entire track dedicated to DDD. Eric and I attended the DDD track get-together last night with the Interface21 guys, and I am greatly encourage to see how the Spring Framework project has embraced DDD. It seems a natural fit, but more on that in a separate post.
Having spent the better part of two days provisioning my new MacBook Pro's OS X, Debian, and Windows XP instances, I am keenly aware of how much the Debian distribution's package management system and its volume of packages have spoiled me. In that two days, the amount of time required to provision Debian was negligible, even though it is configured to completely match my Lifebook's Debian Sid instance. In fact, the sum total of time to set up Debian, including every application I use, was about 45 minutes of my involvement. Those who know Debian (and Ubuntu, Linspire, Xandros, Mepis, or any other Debian derivative) are coolly nodding their heads, while others are probably thinking I am a lying, biased Linux zealot.
It's no lie; here are the steps I had to take:
- Run the Debian Installer business card image and perform a stock Sid installation, choosing Desktop and Standard System options in the task selection step. If you weren't wanting to run Sid, the netinstall image would be fine as well.
- Generate a package list on the current Debian installation via
# dpkg --get-selections > dpkg-selections.txt
- Copy the package list file to the new installation; I have copied it to my home directory in this example.
- Set the package selections for the new installation via
# dpkg --set-selections < ~/dpkg-selections.txt
- Run aptitude or synaptic and choose the install action, then go do something else. Thousands, literally thousands of software packages are being installed for you. Everything from your email client to your office suite to your software development tools are being pulled down from package mirrors. In my case, this was over 850MB of compressed package files.
- After the package download, answer any configuration questions aptitude (or synaptic) poses.
- Copy your /home directory contents to the new installation.
Compare that to what it takes with either Mac OS X or Windows XP to get all of your applications installed and configured. Even if you don't know a thing about Linux or even the more technical side of those operating systems, you can tell from the brevity of that set of steps that the Debian setup is remarkably simple.
Now, some will already be keying in their comment posts with exclamations of "Hey! There's DarwinPorts/Fink/Cygwin!" Yeah, each of those is a nice start; however, they pale in comparison. Fink at least has the robust apt/dpkg foundation, but even it has a relatively meager package selection. I am sure I'll be writing more on life with Fink and DarwinPorts in the near future.
I still don't have half the stuff installed on XP that I plan to use. I get tired just thinking about the installs. 8^)
An updated java-package will hit unstable in the next mirror pulse. Apologies to all for the delay; my discretionary time and that of my sponsors has been rather sparse for some time now. There are at least 9 bug reports addressed in the release. All users who have a JRE or JDK packaged by a previous version of java-package are encouraged to first remove their existing packages and then install an updated one generated by 0.28. Again, sorry for my low level of productivity for Debian, but paying my bills and being a new dad has been quite taxing (albeit rewarding) the past nine months.