What's That Noise?! [Ian Kallen's Weblog]

All | LAMP | Music | Java | Ruby | The Agilist | Musings | Commute | Ball
Main | Next month (May 2006) »

20060425 Tuesday April 25, 2006

GData and Goofles

Since Niall mentioned GData, I've been meaning to look into it further. Today Otis mentioned that one of the Apache/Summer of Code projects proposed is a lucene-based GData server implementation.

I took a look at the docs and realized that this is actually a really old spec, as old as the epoch as a matter of fact. Check it out:

But seriously folks, the G-man and his crue have done a fine job providing client implementations (as long as your not waiting on Ruby or one of the P-languages, no perl, python or php yet). Even a nice set of examples for the Java implementation. Thanks, G!

               

( Apr 25 2006, 08:17:45 PM PDT ) Permalink


20060424 Monday April 24, 2006

AJP13 for Ruby on Rails!

A few months ago, I mused that we should be able to abandon FastCGI (with extreme prejudice) and use AJP13 with Ruby on Rails instead. Well, unbeknownst to me at the time, someone was hatching just such a plot, the Ruby/AJP Project! I'd heard last month that David Andersen was tinkering on installing it... well, he not only got it online but he blogged how he did it. Take a look at his compile time and run time configuration details using Apache 2.2's native AJP13 protocol plugin for mod_proxy (i.e. no mod_jk, good riddance), it's really cool! Way to go, David!

           

( Apr 24 2006, 08:48:30 PM PDT ) Permalink


20060421 Friday April 21, 2006

The Hard Work of Making Java Easy

The Java backlash that began a few years ago was mostly a J2EE backlash, not against the Java language per se. Too many people took the blueprints too seriously, too literally or just too damned religiously. Too many applications that didn't need EJBs were using them, letting the container manage low level application plumbing invited slow and buggy behaviors that were painful to debug. The backlash has made a lot Perl/Python/PHP enthusiasts express self-righteous vindication and have helped morph the J2EE backlash into a broader Java backlash. Geez, even IBM is getting all spun up on PHP, whodathunk? But I think the dismissal of Java is premature. None of the P languages or Java are without hazards. These days a lot of developers are over the blueprint kool-aid and are standardizing on a simplified and productive stack:

However, there is still a rapid development gap. I've heard Java called a "high ceremony" language. Where you can often prototype a lot of functionality in a modest amount of code with the P languages, you end up writing a lot more code to do the same things in Java. On the other hand, the run time errors, sorcerers and hackers adherent to the P languages are at least as guilty of the same brand of excessive zealotry as the blueprint adherents. The practical heresy demands recognizing that you can get it really wrong in just about any programming language. As far as the high ceremony, Java and J2EE are guilty as charged. As if to punish Sun, the developer community has innovated just fine without advance posturing within Sun's prescribed processes (the good news there: many within Sun seem to realize that they can't carry on as a cathedral and, in fact, are embracing the bazaar, bravo!). Spring and Hibernate each offer a degree of code simplification but require a bit of XML-hell. Even though the XML is way simpler to maintain than say, struts-config.xml and EJB deployment descriptors, you've reduced your compile-time safety code maintenance but increased your runtime hazards with more XML. Xdoclet or JSR-175 annotations can simplify a lot of the XML configulation required for Struts and Hibernate but then you might end up in another kind of hell: annotation hell. Choose your hell well!

To really bring rapid development and prototyping to a Java environment, there a lot options to look at such as dynamic JVM languages:

Jython
By most accounts, a mature but quirky Python for the JVM
JRuby
An immature but progressing Ruby for the JVM
Groovy
A failed experiment or work in progress, depending on who you talk to
Ruby on Rails doesn't run on JRuby (supposedly, it's coming). Grails (the artist formerly known as Groovy on Rails) is on v0.1, I'm not holding my breath. What about getting the simple life "convention-over-configuration" in Java? You get some of it simply by using Maven; organize your code to the Maven convention and compiling, testing and packaging your application just works. Eclipse provides so much developer support for Java already, using Maven and Eclipse together is great way to keep a lot of the high ceremony out of your way. But for application development, there are a few rails-alike frameworks for Java that I'm still interested in trying: rife and trails.

I expect in the months ahead to be writing applications with plugin support and that the big win for the dynamic JVM languages for me will be in easing the rapid development of plugins. In other words, I probably wouldn't write an end to end application with them but given a set of interfaces for extension points that can be automatically tested, writing the extensions in JRuby or Groovy sounds compelling.

I actually haven't had time and opportunity to substantially try half the things I've mentioned thus far. Surveying the number of tools, languages and frameworks it's clear that there are a lot of things to consider and that a lot people are concerned with (and working hard on) bringing the down the high ceremony of Java. I'll still be using P languages in the future, too. Down the road, I suspect virtual machines (JVM? parrot? mono/CLR?) will make a lot of these issues fade away and the questions at hand will be around when to use closures and when to use objects, when to annotate and when to externally declare, when to explicitly type or auto-type and so forth. The languages will be incidental as they support shared constructs and virtual machines.

                   

( Apr 21 2006, 09:03:42 PM PDT ) Permalink