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.

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".