JRuby at TSSJS

Just a quick post to say I'll be presenting on JRuby at TSSJS. The JRuby core team is all at Scotland on Rails I presume, so I'll be doing my level best to represent. Drop me a line if you're going to be there.

Rails "components": I do not think that word means what you think it means.

Right now I have 2 gigs. One is a java gig where I am working on an application I helped develop about two years ago using Tapestry. The other is a Rails gig. This has given me a good opportunity to compare and contrast the two. So far my experience is that I love the Ruby language and don't want to go back to doing Java except when/if I need to to pay the bills. But Rails I'm not as sold on. Mind you I'm not here to bash on Rails, there are some great things there and other people have done a fine job of praising them. But there are some things I definitely miss from Tapestry, and the most significant one is components.

Now when I say components I don't mean that abomination they stuck in Rails and then deprecated. I mean "real" components in the style of WebObjects, Tapestry, and other frameworks in that lineage. To qualify as "real" components in my mind means 3 things:

1. Reusable view and controller logic.
This is the easiest and this is I think what the deprecated Rails components thing was attempting to address. I've seen several other attempts to do this in Rails with varying degrees of success. I think the Presenter pattern being bandied about is essentially another attempt to have this same aspect of "componenty-ness".

2. Composability.
Components should be able to be composed out of other components. I haven's seen something in Rails that did this well yet. It could be out there, but if it is I haven't seen it. And this is also where it gets a little controversial. From what I've seen, DHH and rails core seems to believe that "high level" component reuse is either not possible or worthwhile. Having seen it absolutely work and work well in Tapestry I have to respectfully disagree. The Tapestry Palette and Table components are both "high-level" and reusable on multiple projects to great affect. However even the discussion around component reuse seemed to me to be framed incorrectly, as it seemed focused on components being reused between applications. This is certainly possible, but I find much greater levels of component reuse within an application.

3. Binding.
This to me seems to be the most neglected feature of components, but in my mind is perhaps the most important. This is simply the ability to say something like "the value property of this text field is bound to @person.name". This should result in me being able to access @person with the name already set. I shouldn't have to touch the params hash at all. This would get rid of what I see as an imporant non-dry part of Rails. For example, why should I have to say in my view:

text_field "person", "name"

And then in my controller:

@person = Person.new(params[:person])

With binding I wouldn't have to.

The other place binding comes into play in component frameworks is events. Not only properties support binding, but events do as well. For example, a Button component could have a block bound to the "onlick" property. The framework then manages and abstracts away all the details of HTTP, etc.

I guess that's really what I miss: with a good component framework (and not all of them are) I feel like I am working at a higher level of abstraction. When building reasonably sophisticated web applications, I really miss that. With simple web sites, I don't so much.

So where am I going with all this? Well, I've been thinking about these ideas a lot since I started doing Rails and talking about them with my pairmate. Recently the ruby-component-web-frameworks Google group has been getting active again so I thought I'd blog about my ideas. I've started doing a little code experiment to see how it might look to implement some of these ideas as a Rails plugin. It seems not too difficult so far; it never ceases to amaze me how much I can say in so little Ruby code. When we have an SVN repo setup I'll share what I have but it's just an architecture spike right now.

Making our RESTful grid editable

In my last post, I showed you how to hook up the new dojo grid component to a RESTful resource in Rails. Now we're ready to make it editable. I promise this will be a shorter post than last time. The key piece is making a new model object to handle our edits. The dojo grid already provides the key pieces to make editing happen; we just need to provide a way to pass the edited values into our Jester-made object to send them along to our application. The way we do this is by creating our own model class which extends dojox.grid.data.Objects. Then we create an instance of this class. This is what the code looks like:

    dojo.declare("MyModel", dojox.grid.data.Objects, {
      beginModifyRow : function() {},
      endModifyRow : function() {} ,
      setDatum: function(inDatum, inRowIndex, inColIndex)
      {
        this.data[inRowIndex][this.fields.get(inColIndex).key] = inDatum;
        this.data[inRowIndex].save();
        this.datumChange(inDatum, inRowIndex, inColIndex);
      }
    });

    var model = new MyModel([{key: "make"}, {key: "year"}], cars);  

I'm definitely doing some hackery to make it simpler for myself here. The beginModifyRow and endModifyRow are dojo methods that get called at the beginning and end of editing a cell. In the normal dojo implementation these methods make a copy of the object being edited so it can be restored if a user cancels the edit. In a final version of this code we would want to clone our Car object when we start an edit, but we're just not worrying about it yet.

The code which actually handles the edit is in the setDatum method. It get's called with 3 arguments, the new value to set, the row index, and the column index. We have an array of cars to which makes it easy to lookup the right row, but how do we know which field is in which column? Well, dojo holds that information for us in the fields property of our model. The fields property provides a method to get a field object by index, and this field object has a key property which is the name of the property of car that lives in this column. This allows us to set the right property of car. Saving our changes back is a snap thanks to Jester. We call save on our car object and we are done.

Finally, we need to make some changes to our structure object to tell it which cells we want to be editable. We'll use dojo's simplest built in editor and make both cells editable. Here's how we do it:

 var structure = [ {
    rows: [[
         {name: 'Make', editor: dojox.grid.editors.Input},
         {name: 'Year', editor: dojox.grid.editors.Input}
    ]]
 } ];

So this is it. We now have an editable dojo grid saving changes by making REST calls into our Rails app.

Using a JS component framework like Dojo (or ext, mootools, etc, etc) in combination with Jester seems like it opens up a new way to approach web application development. I might expound on this in another post.

Dojo Grid + Jester + Rails = RESTful grid goodness

I've been experimenting with Javascript component frameworks lately, and that let me to look at Dojo. With their 1.0 release, they have added what looks to be a very powerful Grid component. I thought it would be fun to see how easy it is to get it talking with Rails. It proved to be not much code at all, and I think, kind of nifty. Here's how to do it.

Create a Rails app with a RESTful service

Not gonna go thru how to make a rails app, I'll assume you know that already. I created a little RESTful service with the scaffold generator something like this:

script/generate scaffold_resource Car make:string year:integer

Install Jester

When I found Jester it was one of those Open Source Moments for me. You know, the ones where you think: "Hey, wouldn't it be cool if you could..." and then Google and find out someone has already done it. Jester is basically ActiveResource in Javascript. The result makes so ridiculously easy to talk to RESTful services it's not even funny. I installed by unzipping the script and dropping jester.js in public/javascripts in my Rails app.

Install Dojo 1.0

Go get it, unzip it, drop it into public/javascripts. Nuff said

Write the code

And now for the fun part :) We'll start with a simple grid that pulls in data by making a RESTful call to our Rails app using Jester. Later on we'll enhance it to make it editable. First thing you need to know about Dojo is that it is CSS driven. This is definitely a good thing IMO, but it does mean you have to include the right CSS or it won't work at all, trust me ;) So make you sure you include the Dojo Grid CSS like so:

 5     <style type="text/css">
 6       @import "/javascripts/dojo-release-1.0.0/dijit/themes/tundra/tundra.css";
 7       @import "/javascripts/dojo-release-1.0.0/dojox/grid/_grid/Grid.css";
 8       @import "/javascripts/dojo-release-1.0.0/dojox/grid/_grid/tundraGrid.css";
 9  
10     </style>

Next, we'll need to include Jester and Dojo:

12     <%= javascript_include_tag :defaults %>
13     <%= javascript_include_tag "jester" %>
14     <script type="text/javascript"
15             src="/javascripts/dojo-release-1.0.0/dojo/dojo.js"
16             djConfig="parseOnLoad: true"></script>

Including Jester is just a matter of including using the standard javascript_include_tag helper, but dojo is a little wierd. You'll notice the djConfig attribute for starters. How does this even work? djConfig is not even a valid attribute for a script tag, right? As best I understand it, and someone please jump in if I'm wrong, dojo has a parser of it's own that comes along after your page load sand does things to it. This let's you add dojo components to your page "declaratively", or in html, instead of have to use so much javascript. Kind of interesting.

Now let's look at the script block that sets up the objects our grid will need:

18     <script type="text/javascript">
19     dojo.require("dojo.parser");
20     dojo.require("dojox.grid.Grid");
21     dojo.require("dojox.grid._data.model");
22
23     Resource.model("Car");
24     cars = Car.find("all");
25
26     var model = new dojox.grid.data.Objects([{key: "make"}, {key: "year"}], cars);
27
28     var structure = [ {
29        rows: [[
30             {name: 'Make'},
31             {name: 'Year'}
32        ]]
33     } ];
34
35
36     </script>

The first thing you'll notice is those dojo.require statements. These are how you tell dojo to go get all of the pieces it needs. Dojo is broken down into lots of individual javascript files, and while you could just include them all in script tags, that would be kind of a pain. dojo.require basically says "go get this piece and all of it's dependencies". It makes it easier to use some of dojo and not all of dojo as well.

Next we see Jester in action. Kind of puts dojo to shame from an ease of use standpoint, doesn't it? You tell Jester which model you want, and it makes a javascript class for you. We then call find all and it gives us back an array javascript proxy objects with the fields and methods you would expect. Like I said, ridiculously easy. There are options to have it do find (and save) asynchronously as well, which you would probably want to use for a real application.

Next we setup some objects our dojo grid needs. The first is a model, it tells dojo where to get it's data from. We're able to use of the built in types of models, dojo.grid.data.Objects. This kind of model will display an array of Javascript objects, which, conveniently enough, is exactly what we got back from the call to find. We have to give it a little more information, though, namely what properties to display in which columns of our grid. This is what we're doing in the first argument to the constructor. The second argument is our array of cars we got back from the call to Car.find("all").

Finally, we have an object that tells how we want our grid organized. I have to say this seems a lot more complicated than I'd like. It seems to me sometimes dojo is more focused on making the hard things possible than making the simple things simple. So I'm not even going to try to cover all the details of the structure object here, but briefly dojo grid structures consist of an array of views which have an array of rows which have an array of subrows. Phew. I think it would be possible to come up with a simpler structure object for simpler cases, but that would require more dojo-fu than I have yet.

At last, we're ready to put in the html for our grid. Here it is:

42   <div id="grid" dojoType="dojox.Grid"

43        model="model" structure="structure"
44        autoWidth="true" autoHeight="true">

45   </div>

Not much to it is there. Notice how we can set properties of our grid with html attributes. This is what the dojo parser does for us, as I understand it. Here we're passing in the model and structure we created in our script block.

So this is all that's required to use the dojo grid component and have it pull data from a REST service implemented in Rails. In my next post I'll show you how to have it be editable and save it's data using thru REST as well. It's easier than you might think.

Debugging a JRuby on Rails app with jruby-debug and NetBeans

We've been working on the java port of ruby-debug for awhile and it's getting perilously close to usable. And with the latest builds of NetBeans, you can actually use the NB ruby debugger with it. If you're very brave, you can try it for your yourself. Be warned, it's still a work in progress, but here's how to get started:

1. Check out jruby from trunk and build it. You'll need java and ant, but if you're interested in jruby chances are good you have those already. It's super easy to build, check it out from http://svn.codehaus.org/jruby/trunk and do ant dist and you're good to go.
   
2. Check out jruby-debug from http://debug-commons.rubyforge.org/svn/jruby-debug/trunk. In this directory, do rake install_gem. This will compile and build a jruby version ruby-debug-base, which ruby-debug (command line rdebug debugger) and ruby-debug-ide (which NetBeans and Eclipse use) both depend on.
3. Check out ruby-debug-ide from http://debug-commons.rubyforge.org/svn/trunk/ruby-debug-ide. Then do a rake gem to build the gem and gem install pkg/ruby-debug-ide-0.1.8.gem to install it.
   
4. Grab a copy of NetBeans daily builds ruby ide from here: http://deadlock.netbeans.org/hudson/job/ruby/
5. Fire up NetBeans like with some extra command line switches: ./netbeans -J-Dorg.netbeans.modules.ruby.debugger.force.rdebug=true -J-Dorg.netbeans.modules.ruby.debugger.fast.not.required=true
   The first tells NetBeans to always use the fast debugger even tho the classic debugger is what appears selected in the UI. The second tells NB to ignore the fact that the classic debugger is selected and allow us to debug a rails app anways. These flags were just added to allow us to play with jruby-debug in NetBeans for now, they won't be necessary once jruby-debug matures a little and full support for it comes into NB.
6. In NetBeans Tools | Options be sure and have your ruby interpreter pointing at the jruby you built from trunk in Step 1.

You should now be able to debug Ruby and ROR apps using the fast ruby debugger inside of jruby. Like I said, this is all very experimental. All these steps will go away in the next few weeks or months and jruby-debug, jruby, NetBeans, ruby-debug-ide do releases.

Things which seem to work ok:

• setting breakpoints
• looking at variables (global and local)
• watches

A little flaky (tho it may already be fixed by the time you read this):

• Stepping over some code in Rails
• Stepping out of a method

Finally, big time kudos to Martin for kicking this whole thing off and Peter for knocking out bugs and implementing more features every hour just about. It's definitely looking close now.

Avoiding Helpful Tools Considered Stupid

Rarely does a blog post get me all fired up like Giles Bowketts here. As part of the team working on improving debugging support for JRuby, it probably struck a particularly personal chord. Nothing like having your hard work publicly ridiculed to get you exicted. I might have ignored it, and maybe I probably should, but the post contains some truly exceptional BS that needs to be addressed.

First off, it claims to inspired by a good friend of mine. So Giles, to quote from that famous vice presedential debate: I know Jim Weirich, and you sir, are no Jim Weirich! Ok, so maybe Giles didn't actually claim to be Jim Weirich, but the fact that he even attributed Jim in any way while spouting such blatent poppycock just shouldn't be.

As part of my job I have the incredible good fortune to pair with Jim on a Rails project. At the risk of pointing out what should be obvious, we do write test cases. And, it's true, when we first started working together, we did not use a debugger. Most of the time, we didn't need one. But every so often, we would have a situation where we couldn't understand what some code was doing. More embarrassing still, sometimes it was even code that we wrote.

So, when confronted with such a situation, when we couldn't think of any more test cases to write, we would add statements like this to our code "puts DBG: #{some_value_we_want_to_see}". Wow, perty high tech, eh? And it worked. We could always solve our problem this way. Jim even had a little rake task that would comb thru the code to find DBG: in our code so we could easily remove these when we were done.

Then one day I got tired of us typing DBG: in our code and I said something like "Let's try using rdebug". And guess what: rdebug was often handier than adding puts statements to our code. We could inspect all kinds of stuff. Sometimes it helped us learn more about how Rails works, especially when it did things that were, umm, a little unexpected. It was a good thing. So much so, in fact, Jim spent some time working on getting it working better with emacs so it was even easier to use.

And, hard to believe tho it may be, it did not cause us to write less test cases. Every time we learned something while debugging, we could go back and write a test case which documented our learning. In the end it helped us to write more and better test cases because we were actively trying to do so.

So it should be obvious, but since it didn't seem to be I'll state it: debuggers are tools. Like any tool, if it helps you do your work better, you might want to use it. If it doesn't you probably shouldn't. Using a tool does not lead to bad habits, bad habits lead to using a tool incorrectly. And it's worth pointing out, the technique of classifying a technology or tool as bad because it can be used incorrectly is exactly the argument that I hear made against metaprogramming and run time type checking. Kind of ironic.

Geeky Fatherhood Moment

Some dads live for moments like when their son can beat them at basketball or throw a touchdown pass at a high school football game. Since my family seems to share my, ahem, lack of athletic prowess, I mostly get my "dad pride" fixes in different ways. For example, today my 10 yr old son asked me a question that nearly brought a tear to his old man's eye:

"Dad is there a job you can have when you grow up where you use Gimp?"

:)