"Conference 2.0"

After nearly half a week at the conference (even though it is only "day one", it's the same old story: Sessions I'm interested in that are scheduled at the same, interspersed with long stretches of time where there is nothing much of interest.

Not that I should complain too much about that. As a blogger, the down time gives me time to file my stories and recharge the batteries in my laptop. But I know I'm not getting as much out of conference as I could be getting.

At the same time, I'm getting a lot of exercise as I walk from one end of the venue to the next for one session, only to walk all the way back for the next. (Again, I shouldn't complain. I can use the exercise. But I'm not about to let a little thing like that stop me!)

It seems to me that it's time for a "Conference 2.0" format. After all, Web 2.0 is all about customizing your web experience. Why not have the same thing for the conference?

Right now, there is an online schedule-builder that lets you select the sessions you want to go to and then print out your itinerary. That's terrific. But let's take things one step further. How about a system where you go the web site and select /all/ the things you're interested in (maybe with priorities of 1, 2 and 3 for things you're highly interested in, somewhat interested in, and "possibly" interested in.

A week before the conference, the numbers from all the attendees could be crunched--maybe by one of those massively parallel machines that Sun builds, and a schedule could be created that minimizes both scheduling conflicts and distance between sessions!

After all, I really don't care whether a session I want to go is at 10 in the morning or 3 in the afternoon. I just need to know where to go and when to be there when I show up.

We do have the technology, after all. Wouldn't that be cool?

JRuby Notes

Interesting stuff from multiple sessions.

From a panel on JRuby introduced by Tim Bray and moderated by Mark Driver, including Tom Enebo, David Koontz, Rich Manalang, Sarah Mei, and Charles Nutter:

• Rails is the killer app for JRuby right now, given its ability to scale. The JVM provides native threads, performance optimizations, and the results of years of effort that have gone into debugging and optimizing garbage collection so that things "just work", for the most part--and they work pretty much the same no matter what platform you're running on.
• There is even a Glassfish gem for JRuby. Glassfish is a server for Java apps that JRuby can take advantage of, and the gem makes it easy to install and use. So the JRuby community may begin moving away from Mongrel (the Ruby standard for scaling a Rails app).
• But the next wave of killer apps may well come from metaprogramming Rubyists who provide easy-to-use languages that wrap Java's extensive libraries. Those libraries provide a ton of raw power. Ruby provides a way to make the simple things really and truly simple.
• Many good Ruby libraries are platform-specific, which fragments the programming space, but the JVM is a unifying framework. For example, Swing is a cross-platform library that mostly just works. It has no real equivalent in the Ruby world. A Ruby DSL that wraps it can create new syntax and have huge potential. Similarly for other libraries.
• In fact, there are already several Swing-library wrappers for JRuby, including Cheri, Profligacy, and MonkeyBars.
• Ruby also makes a great way to try out a Java library and see how it works. There's no setup work to do. You just call into it.

Some differences between Ruby and Java:

• Ruby is more flexible and easier to write, but that can make it harder to maintain. But when you consider that Java is, in effect, providing the platform that JRuby runs on--one that manages the threads, does the garbage collection, and various I/O channels-- then Java makes sense for that. You want the platform to be robust and solid. But you want your development language to be elegant let you do more with less work--which equates to having more fun.
• Deployment is more of a problem with Ruby. The process is not as well worked out as it has been in Java land.
• Ruby tools are generally not as mature as those for Java. And Java's strict types genrally let the tools do more for you. (But NetBeans is doing such a good job in that area that developers are leaving their text editors.)
• The test-first mantra is part of Ruby culture, because you can write your test and watch it fail before creating any of the source code to make it succeed. In Java, you can't even compile your test until the interfaces and classes have been constructed. So while the idea of test-first coding is admired, it doesn't tend to happen as much in Java.

From the Charlie Nutter and Tom Enebo's JRuby session:

• The "Processing" library lets you do lots of pretty graphics in few lines of code. One demo showed glowing globes sailing around the screen, moving away from another and then flocking together. The whole thing took 800 lines of code.
• Ruby on Rails books are are outselling Perl books, these days.
• In Rails, there tends to be less code in the whole app than there are in the configuration files for a Java server app.
• The ActiveResource library in Rails takes care of exposing them in a RESTful way (i.e. using http protocols for get, put, etc.)
• The ActiveSupport library has become indispensible for Rails developers. It provides Unicode, json (property-style data marshalling), and a variety of helpers.

From a JRuby on Rails lab:

• Prototype and Script.actulo.us are two libraries that let you code a little Ruby and deliver many lines of Javascript.
• You get both of them when you include the javascript libraries in Rails.
• Prototype transmit XML to and from the server. A Rails form will look the same, but the client is doing more locally.
• Script.aculo.us creates nice effects with minimal code. For example, giving a pale yellow background to a whole block of text is as simple as specifying ":highlight".