MysteryCoder

Why it's the late Cretaceous for server side MVC frameworks

2011-07-10T17:18:00.000-07:00

We're at an inflection point with web application development. I've been developing web applications for 15+ years, and it seems like we're at a familiar place. The last time I remember being here was in the late 90s when the first server side MVC frameworks started becoming popular. Up til that point, most of the web applications were big lumps of code that handled a request and returned some html. For the most part, apps glommed together strings of html and sent back. Next we got to html with embedded code, and that was an improvement but still things were a mass. We had no concept of separation of concerns, no good way to organize our code. SQL was spread willy nilly amongst the angle brackets. It was baaaaad.

And then someone had the idea to apply the Model View Controller pattern to web development. Frameworks to do so abounded. I wrote my own, and then abandoned it when the world standardized on Struts, which was, at the time, A Good Thing. Web browsers in this era were fairly dumb, so it was clear where the code need to be for such a framework: on the server. The interaction with web browsers was strictly limited to a request/response cycle.

Over the past 10 years or so, the basic idea of a server side MVC framework has remained the predominant way to develop web applications. Variations such as component oriented frameworks like Tapestry and WebObjects have emerged, but the core idea of a server side framework that handles requests and returns responses and manages the UI and navigation for the application remains pretty much unchanged. If you look at Struts from 2000, you easily recognize many of the same pieces as you will find in ruby on rails of 2011. This for a good reason: server side MVC has been a great way to develop web applications for most of this time.

In the last few years, I've felt this start to shift. Web application UIs have gotten more interactive, dynamic, and sophisticated. The limitation of the request/response cycle during an application has started to feel positively archaic. Having to reload the whole page to see what happened when I attempt to perform an action just isn't cutting it when so many apps have proved we can do better. Server side frameworks have done their best to adapt and allow for richer UIs. But as clients get richer, it becomes clear that a lot more UI logic has to be on the client. Eventually it becomes unclear where to put what. Our clean separation of concerns begins to break down. We are back to a mess.

I'm going to suggest that it's time to do something radical: Let's stop.

Server side MVC frameworks have served us nobly, and we should thank them for their years of service. But it's time to move on. We need to embrace a different architecture for web application development. UI logic needs to be on the client. Communication with back end services and persistence stores can take place via RESTful HTTP calls with JSON payloads. Server side code doesn't go away, but it assumes a new place with more limited responsibilities.

This is a big change. A lot of our skills as web developers will need to be updated or replaced. But the ecosystem for building these kinds of application is booming. Many of the things that made developing applications in this manner painful a few years ago are dramatically different. Unit testing tools like Jasmine abound. A better javascript syntax thanks to coffeescript makes our code much more enjoyable to write. And frameworks like Backbone.js give us a clear separation of concerns while we build applications in this new way.

As I've started developing apps this way, I've been really excited by the results. The frustrations and foreboding sense of "this doesn't feel right" I found developing rich client apps with server side MVC is completely gone. It definitely took some time to change over, but I wouldn't go back.

There's a lot to learn though. To give you a jump start we've put together a two day training class so that you can jump in and be productive immediately. We hope that you'll join us in Cincinnati on September 8th and 9th.

Managing coffeescript/js dependencies with the Rails 3.1 asset pipeline

2011-05-30T09:31:00.000-07:00

We've been using and loving coffeescript and backbone on my current project. In the last couple days we've upgraded our project to rails 3.1rc1 and been able to take advantage of the new asset pipeline therein. This feature elegantly solves some super annoying problems we've had with managing dependencies in our app, but is not yet well documented. I thought I'd take a few minutes and share what I've learned.

Where the assets live

Before rails 3.1, we'd lump all our javascript and stylesheets in the "junk drawer" that is public. No more. Now they can go in 3 different dirs depending on their purpose:

app/assets for things that our your application code
lib/assets for shared-ish things (not sure I grok what I'd put here yet)
vendor/assets to put things that your app uses but is provided by others

These directories are magically put on the asset pipeline for you. In your views, you can reference things in any of these directories under the prefix /assets, eg. if foo.js was in app/assets (or lib or vendor) you would refer to it as /assets/foo.js. The rails helpers such as javascript_include_tag will do this for you.

So this gives places to put stuff, which is nice, but only the beginning. The killer features (for me) are the ability to package assets and manage dependencies. To see how this works, take a look the app/assets/application.js file you get when generate a new rails 3.1 app.

Nothing but comments, weird huh. That's because this is what we're calling a "manifest file" which is basically just a file that requires in other files. When you include /assets/application.js at runtime, rails will package all the files you required and concatenate (and optionally minimize) them. Let's look at those last 3 lines, as there's magic in them thar comments. The first 2 require in jquery and jquery_ujs. It seems like this must mean that there are jquery.js and jquery_ujs.js files somewhere in one of the assets directories, but this isn't so. That's because gems can contribute to the asset pipeline as well. More on this later. The last line says to include all files in this directory or subdirectories as well. In our apps so far we find it nice to have 2 such manifest files, vendor/assets/javascripts/vendor.js and app/assets/javascripts/application.js. Not sure I can call this "best practice" or not yet, just that it seems nice to us so far.

It's also worth pointing out that files that need to processed (eg coffeescript and sass) will be handled automatically as well. Simply drop a file named whatever.coffee into the /app/assets directory and it will be compiled and included into application.js

Where this all gets more interesting to me is where we have files in the application that depend on each other. Files that are required can have requires of their own. The example I have in my app is coffeescript class inheritance. Imagine a couple classes like so:

When you're building apps with a lot of front end code, it's to be able to organize code with each class in it's own file. But this means you have to make sure to have the script that brings in fruit before apple. With the ability to require in rails 3.1, this problem is nicely solved for us. If we add a require statement to apple.coffee like so, the asset pipeline will take care of making sure things are in the correct order:

This is a huge win for me, as before this I was naming files with numbers such as 1_fruit.coffee to get around this problem. Yuck.

I mentioned earlier that I'd talk about assets living in gems. This is a feature that allows you to take front end code and easily share it between multiple projects. In my next post I'll talk about my experience building a rails 3.1 asset containing gem.

2 easy things you can screw up in backbone

2011-05-15T13:02:00.000-07:00

First off let's be clear. Backbone is awesome. It's totally changed the way I develop web applications for the better. Before backbone, working on javascript code for a rich client web app was a miserable experience. With backbone (and coffeescript) I'm now enjoyably writing code I can be proud of. But because we are now developing our apps in a new way, we've found new ways to mess things up ;) Here are a couple ways we found that could save you some hours of frustration if you avoid doing them.

Don't have multiple views using the same element

This one I did early on in my backbone days the first time I had one view that created another view. Imagine some code like the following:

Seems ok at first. When we click a button in FooView it creates a BarView giving it an element and telling it to render. The problem happens the second time the button gets clicked. At that point you have 2 instances of BarView which each use the same element. And if those BarViews are listening to events on (or within) said element, mayhem ensues. I've found it to work out better to write the code like so:

In this version the BarView is created during the render method, right after his element has been created presumably. Then the BarView instance is displayed when needed. I've found this to be a good rule of thumb: backbone view objects should have the same life cycle as their elements. They should be created when their elements are created and destroyed when they are removed.

Beware model defaults that initialize complex attributes

The second gotcha I've run into cost us a good few hours today actually. Backbone models have a nice feature for allowing default attributes. It's a handy feature, but by using it to initialize array or object properties we found it caused a subtle (to us) but pretty terrible bug. In our model we had code like so:

The problem here is what happens when you create a second Foo. Turns out backbone does a shallow clone of defaults, which means the same array object in memory is used for both. This spec describes the problem nicely:

Turns out there is a pretty easy fix for this too. Defaults don't have to be an object literal, they can also be a function and backbone will be smart enough to invoke it to build the model's attributes. In coffeescript, this fix is exactly 2 characters:

Hopefully these two tips will save you some frustration as you dig deeper into backbone. In a future post I'll share some of the code we've refactored out of our app that we feel like is generally useful for other backbone + coffeescript + rails apps.

CoffeeScript + Backbone.js + Rails = Superfantasticalness

2011-03-13T20:05:00.000-07:00

Lately I've been working on application by writing the front end in CoffeeScript using Backbone.js and the back end in Rails. A few people have asked me about it and so I thought I'd share my experience so far.

Backbone.js

I've been looking for a front end javascript framework for quite awhile, ever since I realized that server side MVC frameworks were probably coming to the end of their time in the sun. I've even tried several aborted attempts to write one. I've spent good amounts of time playing around with both Sproutcore and JavascriptMVC, but when I picked up Backbone.js I didn't want to put it down again. I don't really want to spend the time right now to delve into critiques of the other two, so I'm going to focus on what I like about Backbone.js

For me, the big attraction of Backbone is there's so little to it. Earlier in my career, I was enamored by frameworks and tools that did "everything I would ever need". The idea of learning one environment where I could do everything was appealing. I was attracted by neato whiz bang features even I didn't need them just yet. But as I've grown older and more curmudgeonly, I now prefer tools that just barely do what I need and then stay out of the way. In my mind pivotal tracker is such a tool. Backbone.js feels like this too. It provides a nice structure for the code of a rich client web MVC application. It allows me to continue to use html, css, and jquery without insisting that I give up one of these or do all my design and layout in javascript. I prefer to work a designer who can create visually appealing UI in html/css, so frameworks that don't accomodate this workflow are a non-starter for me.

I don't intend this to be a Backbone.js guide, the excellent documentation is where to go for that. But I'll briefly touch on my experience with the different pieces I've used thus far.

Views

The first Backbone code I wrote was a view. I had started building my app in the usual (for me) way of just adding a some jquery to make my client side UI more dynamic. But this time, when it started to get unmanagable as it always does, I refactored it into a Backbone View. This is just a "class" that extends from Backbone.View. The only thing this does for you is allow you to specify an element that the view contains, and a set of events scoped within this element that bind to functions of your view. But it turns out this feels just right for organizing my code. In my case I ended with a tree view component that uses jstree to do a lot of the heavy lifting. Later on, I actually extracted it into a superclass and reused it on a couple other pages. Over time I've found that my view classes tend to end up as nicely reusable components.

Interestingly, backbone views don't mandate any particular choice for producing the html. After some experimentation, we came up with a convention we like on our project. Each of our views generally has a template file, we're using mustache right now so the files are named things like foo_view.mustache.html. Originally we were just embedding our templates into our rails views as hidden divs or in script tags. But we found ourselves repeating the same markup in our jquery-jasmine fixtures, and this made us sad so we searched for a better way. We settled on having templates in a separate file, and then wrote a rails helper method that renders the views template on the page. We also wrote a jasmine jquery method that loads the template into a fixture so we can use them in our specs as well. Here's what that code looks like, if anyone else wants it:

There are a couple of other things worth passing along we've learned working with Backbone views. The first is that you really want to have your view's element have the same lifespan as your view object. I ran into this issue by creating new view objects inside the listener method of another view. There's nothing inherently wrong with this (that I know of), but in my case the element for the view I was creating already existed. The net effect was that if if the listener method that created the view was called multiple times you could end up with a multiple views listening to events on the same DOM element. This caused no end of confusion. It was a much better idea to create the view once and just reuse-it as needed with different models (as necessary).

The other idea I feel like we're learning is how to communicate between models and views. We regularly have views talk directly to models, getting and setting properties, telling models to persist themselves, etc. But when it comes time for models to communicate with views, it really feels right to use the Backbone event framework. There are a set of nice built in events on models, and it is trivial to add your own. It's worked out well for models to trigger events when interesting things happen and let the views listen to them and do what they will. So our best practice is shaping up that views can interact with models, including listening to events from them, but models should never talk to views directly. It would probably seem obvious to do it this way for anyone coming from rails-land, but I thought it might be worth mentioning anyways.

Models

Backbone.js models know how to speak json to a restful back end out with little to no coding required. This ended up being a pretty big selling point for me, as it made it trivially to integrate Backbone with my rails app and it pretty much Just Worked. The only gotcha here is that rails would prefer to have the attributes for a model be grouped into a name parameter, but telling backbone to do this as as trivial as the following code:

I guess the biggest difference working with Backbone models than Rails models is that everything is asynchronous. Calling a fetch (think find in rails) or a save in backbone means you also have to specify a function to invoke on success or failure, or listen to an event. This would seem to add up to a lot of extra code, were it not for...

Coffeescript

I've been searching for Coffeescript without realizing it for many years. I've been treating javascript as a first class language for a few years, test driving, trying to use clearly communicative object oriented design, etc. This has made the experience of writing javascript immensely more satisfying, and I hope, helped me produce higher quality code. But it's always chafed a bit. I didn't get to choose javascript. There's a lot of syntax is in it that I don't like, and feels noisier than I wish it was. I spent a good amount of time looking for solutions to let me use a language of my choosing in the browser, but in the end they've all fallen short.

Until now. Coffeescript is a lovely language that compiles into readable, debuggable, javascript. It's documentation is fantastic and it's source code is beautifully documented. The most annoying bits of javascript go away, and the coffescript code I've written is so much cleaner and less noisy it's been a joy to use. I'm finding it difficult to convey how big a deal coffeescript is. Someone smart I know responded to coffeescript allegedly by saying "But isn't it just nicer syntax?". Yes it is! And it turns out this is incredibly valuable and important. I chose ruby because I can express my intent, in elegant, readable code. Coffeescript feels the same way to me. But I can use Coffeescript in all the places I would have had to use javascript before. It's been huge to me. I'm pretty much at the point where I'll go back to writing javascript when you pry Coffeescript from out of my hands.

Though I dig backbone a lot, it's still possible one of the other frameworks might mature into something awesome and be the way to go. Coffeescript, on the other hand, doesn't appear to have anything close.

Highlights of rubyconf

2010-11-18T16:52:00.000-08:00

So here is my rubyconf recap, in no particular order:

As always, I enjoyed tenderloves presentation. He's always hilarious, and this year was no exception. This year he really hit the technical material hard and did an excellent job. It was all about the performance tuning and eventual rewrite of Arel. It was a practical deep dive into how to improve the performance of your ruby code. Awesome stuff, definitely worth catching on confreaks.

I was also inspired by DHH's talk. He was basically talk about why he loved ruby. I really liked his thoughts about rejecting the "best tool for the job" idea as if we choose a programming language based on a feature matrix. For me it was the same: ruby code made me happy. What got me inspired though, is that I feel a lot of the same kind of almost giddy happiness about my coffeescript code.

So I've spent time trying to learn write the best javascript I can. It's certainly got some nice features and is not as terrible as people make it out to be. I can write code that I'm pleased with, and gets the job done. But the fact is, I didn't choose the language, the browsers did. With coffeescript on the other hand, all the most annoying things about javascript are just gone. The code I've written (not enough yet, mind you) comes out just so sparse, elegant, and communicative that it makes me feel all warm and fuzzy. It really is much like how I first felt (and still feel) about ruby.

I gave a very lame 3 minute lightning talk on coffeescript on Sunday, and got to talk to a few other people that seem as excited about it as I am. It also felt very reassuring to talk to DHH and one of the other 37 signals guys, Sam Stephenson, about their use of it and how impressed we both are with backbone.js as well. It's still early time here but I can't wait to see how things develop. It's exciting.

Another session I really enjoyed was the redcar session. I was already geeked about redcar before, but after seeing Dan crank out a plugin live in a few minutes I got excited and have been coding on it ever since in my spare hacking moments. I managed to fix a bug (turns out it only happened because I was a version of date with Safari) and then coded up a plugin for the feature I wanted the most, running a single test by name based on where the cursor is. It only talk an hour or two while waiting for a flight. I don't think I've ever had an editor where coding in it was actually FUN. It's quite empowering. There's still lots and lots to do. Hope I can keep finding some spare to time to hack. It's also worth noting that I've been productively using redcar for real coding for all of this week. Rubymine, I loved you for a time, but in the end the performance woes made you too frustrating. Best wishes and fond regards, we wrote some lovely codes together.

And of course, the Polite Programmers session. There were definitely some issues. The banter back and forth didn't seem to work as well as I hoped. Jim left me my openings, I just got nervous and had trouble coming up with natural sounding responses. But we got lots of positive reviews, and it's always a privilege to present and learn from Jim. Ed did a fine job as Mr. Manners as well, what with his inimitable cultured accent and all :)

Can't wait for next year!

JSpec tests running in CI

2010-07-14T14:08:00.000-07:00

A lot of people, myself included, have been TDDing our javascript for awhile but it seems like it's still fairly rare for the tests to be run in the CI build. I've taken some time today to get our existing suite of JSpec tests to run in our CI server (Hudson in our case) and thought I would share what I did. My general approach should be useful regardless of which CI server you are using.

It's actually fairly simple: I'm using the capybara selenium driver to run the JSpec tests and grab the results from the DOM when they finish. Here's the testcase:

I define an array of all my jspec tests, loop over them, munge them into a legal test method name and define a method that delegates to run_jspec. run_spec opens a file url (had to go underneath capy here so its a little icky) and then waits for the .failures div to appear. It should be noted that capybara will wait for an element to appear when you call page.has_css?

From here, running it under CI is trivial. In fact I didn't have to do anything at all, the tests was found by rake test:integrations and ran (and passed!) in the next build. Most of the heavy lifting is done by capybara and selenium-webdriver.

Obviously there is a lot that could be done to improve this code. I could grab the jspec file from a FileList, and grab some better failure messages from the DOM. I could also probably write a custom JSpec formatter to make this easier on myself even. I'm thinking if there is interest I could finish this up and turn it into a gem. Please comment if you'd use such a thing.

Also, one more thing you will need is the JSpec runner file that can run a single test. I did that like so:

Enjoy!

Why don't I pair more?

2009-01-31T08:54:00.000-08:00

I've been watching a video of the hashrocket guys just now that Corey Haines twittered about. I've been amazed and inspired by Corey's pair programming tour: talk about turning lemons into lemonade. What an awesome idea. I've paired with Corey on some open source stuff at conferences, so I naturally wanted to get in on his tour. As a result I had the good fortune to have Corey stay with me on his tour. Unfortunately the timing of his stop happened on a day I had to spend dealing with client issues and didn't get to spend time pairing with him. And this leads into my topic: Why don't I pair more?

This isn't another post about why pair programming doesn't work, isn't a good idea, or any other such nonsense. I'm a true believer in pair programming. I've been sold on the concept since I first read about it in the first edition of Kent Beck's Extreme Programming late in the prior millenium. I've experienced pair programming and so I know the benefits first hand:

It consistently produces the best code, the code I'm proudest of in my entire career. And not a little prouder of. I mean, like, an order of magnitude more proud of.
I'm operating at about twice the velocity I would normally, which is a rush, and incidentally, means there is no negative effect on team velocity. I've actually measured this on a real project.
I learn way more
I enjoy my job way more

And on an on. But that's not what I actually want to talk about. This post is a way for me to put down in writing the reasons that I don't pair nearly as much as I want to. I'm doing this chiefly as an exercise so I can better understand the issues and change them. If it helps someone else, hey, that's pure bonus. The first few are about me. Which is good news, because it means I can change them.

Part of me is afraid to
I'll just go ahead and lead with this one since it's the hardest to talk about. I really like how the hashrocket guy put it: "Pairing is a burning crucible". Heat reveals impurities and exposes the true nature of things. If I'm having a self-doubting, insecure kind of day, I might not want this. Intellectually I'm totally convinced this is BS and the benefits far outweigh the minor pain of revealing what's obvious to everyone: I don't know everything. I like to think this reason is not a major factor preventing me from pairing, but in the interest of self-disclosure I'm putting it out there.
But I might not get my stuff done
This one is a bit more insidious, but like the prior reason begins with self-centered fear. If I pair on your task, I might not get mine done. And conversely if you help me you might not get yours done. There are at least two ways to address this. The first is to get over it: I believe that the software I produce will be way better if I pair. And obviously producing better software is what's best for me and whoever I work for. I have to be clear on this and act on it, which in my experience is not always easy. And of course the other members of my team do as well.
The other way to fix this is organizationally: don't assign tasks to individuals. I've been in situations where this was out of my control. Some clients like having a single "go to" person for a given feature or issue. But this doesn't have to stop pair programming if the team doesn't let it.
Inertia
This one is a little more nebulous but I don't think it's less real. Sometimes I don't pair because I don't put forth enough effort to find someone to pair with. Other times I might be "in the middle of something". Either of these fall into the same general category of inertia: an object at rest (me, by myself, in front of my computer) tends to stay at rest.

The next few are harder to change, because they are about other people. Obviously I can't pair program if no one will pair with me. And no matter how much I would like to and am sure I know what's best for them, I can't actually control other people. But I'm going to list these issues anyways in the hopes that solutions will become clearer if we understand the problems.

Odd number of people on your team
This is so obvious an issue it seems silly to put down, but I've seen it make a big impact. I know the song says "One is the loneliest number" but three is also not very good. What tends to happen is pairing becomes awkward as one gal or guy is left out and sometimes leads to little or no pairing at all. I suppose you could address this by making a pair your smallest unit of staffing a project. But it's also true that even if you have 3 people on your team you could still pair 2/3 of the time if you are intentional about it.
Distributed team
Remote pair programming is a whole nother topic and I have some experience with it that perhaps I'll share in another post. Suffice to say: it's not as good as pairing in person, but better than not pairing at all. Because there are some technical details to work out and do, there is that much more barrier to overcome and it requires even more sustained effort to keep up.
They won't let me
This is supposed to be the elephant in the room: management won't let me pair program. My thinking is that this one is mostly a myth. I've worked in a lot of places, some of them quite draconian. The truth however is that pair programming can start so innocuously that it's hard to have a mandate against it. Imagine management saying: you're not allowed to help other people. Even the pointiest of pointy haired bosses would see how stupid that is. I'm sure someone will comment that "No, that really does happen". Fine. I just don't think it's all that common. Most people, in my experience, actually do want to be useful and contribute something positive. They just may (wildly) disagree about how best to do so.
They code in X and X sucks
This one requires compromise, but can be a a positive sometimes if you let it. My first ruby project I got to pair with my friend Jim, a dedicated emacs guy. As a result I had to learn emacs, something which I probably wouldn't have decided to do if I hadn't see what a productive environment it is first hand. There are other times where I pair with someone and they use something and even after trying it I still think it sucks. In that situation I try to get them to always pair on my machine. Err, I mean, switch back and forth between each others machines in the interest of fairness ;)
No one wants to pair (except me)
Alas, this has been the hardest to solve. You can be fortunate enough to work for (or start) a company that mandates pair programming. Or else you can attempt to influence people. My only advice, based on experience, is that less is more. Don't talk about pair programming at all, just offer to help people. And then ask for help when you're stuck. I've sadly tried the approach of trying to convert people to pair programming, unit testing, or any other number of quite good ideas by incessantly talking to people about them. Don't do this.

Announcing Edit Me: a teeny weeny CMS plugin for Rails

2009-01-15T19:50:00.000-08:00

I've been working for awhile on Rails plugin that makes it easy for users to edit their own content. I started it to scratch an itch I've had for a long time. The problem I have with most CMS systems is that they want run your whole site. Sometimes this is ok, but a lot of times you have a rails app where you have pieces of it that it would be nice to to let your client edit for example. For those cases, the edit_me plugin is your friend.

The idea is pretty simple: when in editing mode, edit_me gives you an edit icon next to the content produced by rhtml and html.erb files (you can configure which files you want to be editable). Click the edit icon and up pops an editor (using wymeditor). Save your changes and the page reloads with your changes. Edit me assumes you're using git (why wouldn't you?) and lets your roll back your changes in the History tab of the editor.

To check it out, head on over to http://github.com/superchris/edit_me/tree/master and follow the instructions in the README.

"Fun" with Hook Methods in Ruby

2008-10-18T19:45:00.000-07:00

I've been wrestling with what turned out to be a rather interesting issue involving ruby hook methods. I don't yet have a solution to the problem but perhaps the activity of describing the problem in writing will illuminate a solution. Hook methods in ruby are callback methods you can implement in your code to get notified at interesting points in the lifecycle of a ruby object. The one which caused trouble in my case is inherited. By implementing the inherited method in a class you can get called back when another class inherits from it. It's quite useful when you want to do something like record each descendant of a given class, for example.

I ran into an issue with inherited while trying to understand a very strange behaviour in my IDE of choice, NetBeans. When running my rails test cases from NetBeans, I noticed they were not transactional, but when run on the command line they were. After sending a flame-o-gram which I will soon need to retract to the nb ruby mailing list, I decided to poke around in their code. I finally narrowed the problem down to their testrunner code.

In the newest version of NetBeans they have added a nicer ruby testrunner. In order to provide some features this new testrunner keeps track of all descendants of Test::Unit::TestCase. It does this, by, you guessed it, using the inherited method. When I delved into this code the first problem I saw was pretty obvious. The author had violated what I will now credit my friend Jim by referring to as Weirich's Hook Method Implementation Commandment:

Thou Shalt Always Delegate to the Previous Implementation

The reason this is important is that when you implement a hook method, you can easily step on someone else who had implemented it for another reason. Using the rails alias_method_chain will normally take care of this for you, but because this code loads before rails they didn't have that option and had not done the right thing and delegated explicitly.

And sure enough, I noticed that when I commented out the inherited method in the testrunner my tests became transactional. I figured at this point I had it licked. I went ahead and changed the NB testrunner code to delegate correctly and tried again. Sadly, it had no affect on the transactional issue. Much head scratching ensued. After many hours of investigation, I finally tracked down the real problem. I noticed that the use_transactional_fixtures class attribute of Test::Unit::TestCase was not being set. This led me to investigate how class_inheritable_attributes works in rails. Eventually I was able to put together a failing test case which expresses the problem. Here it is:


require File.dirname(__FILE__) + '/inheritable_accessor'
require File.dirname(__FILE__) + '/../test_helper'

class A
  class_inheritable_accessor :foo
  self.foo = "bar"
end

class B < A

end

class InheritableAttributesTest < Test::Unit::TestCase

  def test_foo
    assert_equal "bar", B.foo
  end
end

And here what's in inheritable_accessor.rb:


class A
  class << self
    alias_method :a_old_inherited, :inherited
    
    def inherited(base)
      puts "A inherited"
      a_old_inherited(base)
    end
  end
end

To try this at home, simply make a new rails project and drop these two files into your test/units directory. It should fail. But why? The inherited method does delegates to the previous implementation correctly, right? Now try switching the order of those two require statements. Poof, it passes.

Turns out the problem happens because of how class_inheritable_accessor is implemented. As you probably have guessed, it uses inherited. And yes, it does correctly delegate to the previous implementation. But it's where its implemented that is the problem: in order to let all classes be able to use this method, it's implemented on Class. However, there is an unfortunate side effect to this decision: it breaks for any class loaded before this code which itself defines inherited. In our example, the A class defines the inherited method before the rails code is loaded. But since the A class extends the Class class it's definition of inherited overrides the version rails adds to Class. The net outcome is that for the A class, and any class loaded before rails that defines inherited, class_inheritable_accessor is broken.

What's the right way to fix this? I'm not honestly sure. It could be that in order to do something like this which effectively adds a feature to the language, you need to be loaded first. On the flip side, it could be considered a bug that class_inheritable_accessor is broken in cases like this. Well, I had hoped that by the time I got this point in the post a clear solution would emerge. I suppose I'll have to leave it, as they say, as an exercise for the reader :)

Update: I was about to post this, and I went to grab some dinner and finally realized the solution: A still does not entirely obey Weirich's law. It correctly delegates to a previous implementation in the same class, but not to the superclass. A call to super at the end of the inherited method causes the test to pass. Adding the super call to the NB test runner code also causes my tests to be transactional again. Yay!

Ruby in the browser at Rubyconf

2008-09-13T10:17:00.000-07:00

Just got the news this week that my submission on ruby in the browser, has been accepted for Rubyconf. This looks like an awesome conference and I am really psyched to be included. It is also inspiring me to do some more work on rubyjs_on_rails and try to finish up an activeresource client. I'll be hacking on that in whatever free time I have available this weekend.

I'm also thrilled that I get to be part of another dialogue session with Joe O'Brien and Jim Weirich. This session will be a similar format to our railsconf dialogue which seemed to go over pretty well. It's always a ton of fun to collaborate with these two phenomenal guys.

rubyjs_on_rails hackfest at erubycon

2008-08-25T21:30:00.000-07:00

I had a really fun time hacking on rubyjs at eRubycon. It's amazing how much more fun and productive it is to hack with someone else than by yourself. Thanks to Corey Haines for staying up late at the hotel being my hacking buddy. As a result, we now have what will be the beginning of an ActiveResource client for rubyjs_on_rails. I generated a simple scaffold resource example called Customer with a few fields. I then created a Customer class in the view and started getting it to speak restfully with rails. Here's the result:


require 'dom_element'
require 'json'
require 'rwt/HTTPRequest'

class Customer
  
  
  attr_accessor :attributes
  
  def initialize(attrs)
    @attributes = attrs
  end
  
  def method_missing(method, *args)
    if method =~ /(.*)=$/
      attributes[$1] = args[0]
    elsif attributes[method]
      attributes[method]
    else
      super
    end
  end
  
  def self.main
    @name = DOMElement.find("name")
    @address = DOMElement.find("address")
    find_button = DOMElement.find("choose_customer_button")
    save_button = DOMElement.find("save_button")
    customer_id_text = DOMElement.find("customer_id")
    
    find_button.observe("click") do |event|
      Customer.find(customer_id_text["value"]) do |customer|
        @name["value"] = customer.name
        @address["value"] = customer.address
        @customer = customer
      end
    end
    
    save_button.observe("click") do |event|
      @customer.name = @name["value"]
      @customer.address = @address["value"]
      @customer.save
    end
    
    rescue StandardError => ex
      puts ex
  end
  
  def self.find(id)
    HTTPRequest.asyncGet "/customers/#{id}.json" do |json|
      hash = JSON.load(json)
      yield Customer.new(hash["customer"])
    end    
  end
  
  def save
    request_json = {:customer => attributes}.to_json
    HTTPRequest.asyncImpl "/customers/#{id}.json", "PUT", request_json, "application/json" do |json|
      self.attributes = JSON.load(json)
    end
  end
  
  def to_json
    attributes.to_json
  end
end

The first part I did was find. I've had that done for a couple weeks. This was super easy because rubyjs and rails support json so easily. The only odd bit is that it takes a block instead of returning a result. This is because the find call does an ajax request, and the a in ajax stands for.. you guessed it, asynchronous. Passing a block in makes it nice and simple to handle the result easily though.

The part I got working at rubycon was the save. This proved to be much easier than I thought it would be as well due to rails now supporting json updates natively. The controller code doesn't even need to be aware that the parameters are coming in as json, you can access param[:customer] the same as you would if it was coming from a normal form submission. I had to be sure and specify it was a PUT request when I sent it in, which I didn't realize was as straightforward to do as it is. I monkeyed around with a _method param and all sorts of stuff before realizing I could just tell the HTTPRequest object what kind of request I wanted to make. Duh.

Though this is a specific example right now, I think a large portion of this code should be easy to extract out into an ActiveResouce client base class. I haven't had any more time to hack on this since erubycon, sadly, but this is what I'll be focusing on when next I do. Also, I just now put up a new repo on github to hold this and any other rubyjs_on_rails example code: git://github.com/superchris/rubyjs_rails_example.git. Enjoy!

Announcing rubyjs_on_rails: ARAX sans silverlight

2008-07-09T20:19:00.000-07:00

So maybe you're like me: sure javascript is nice and all but you really like ruby better. And as we move toward richer web apps, there are times it sure would be nice to write some of the client side code in ruby. Along comes M$ with their sexy silverlight DLR magic to make it happen. But you're suspicious: it requires a browser plugin, and can you really trust that it will be there on all the platforms you want to support. Sure, maybe M$ has learned how to play nice and it will be different this time. Maybe.

Well, you can quit holding your breath and exhale, girls and boys. You can write ruby code that runs in the browser right now. Today. No plugin or nuthin. So here's how. First, you'll need my forked version of the rubyjs ruby to javascript compiler. It's a little like GWT for you Java folk. Get it here. Sorry, until githubs gem building process decides to show me some love you'll need to download and install it locally with:


gem install --local rubyjs-0.8.1.gem

Next, you take standard rails app and install my superfantastic* rubyjs_on_rails plugin like so:


script/plugin install git://github.com/superchris/rubyjs_on_rails.git

So what did you get? Well, basically, one measly helper method. Sad, huh. Hey! Don't judge me! Cool your jets and let's see what it does already. First make a rails controller with a single action. Any old action will do, but let's imagine it's called hello. Go find hello.html.erb and put a single button button that doesn't do anything in it like so:


<input type="button" id="button" value="Say Hello">

Now let's write some ruby code to respond to the button click. Make a file called hello.rb in the same directory as your view and put this in it:


require 'dom_element'

class Hello
 def self.main
   button = DOMElement.find("button")
   button.observe("click") { puts "Hello from rubyjs!"}
 end
end

DOMElement is a class provided by the rubyjs gem that makes it easy to, surprise surprise, work with dom elements. In our case we just use it to grab hold of our button and observe the click event with a block of ruby code. Kind of cool I think.

But how to get this code into the brower? You remember earlier when I said all this plugin gives you is one measly helper method and you were all "Meh. I am sooo not impressed." Well now let's see it in action. Add this to your view right below the the button:


<%= rubyjs "Hello", "main" %>

Now hit this action in your browser. Click the button and you'll see your ruby block fire. The rubyjs helper method goes and finds hello.rb, compiles into javascript, and outputs a script tag to serve it up. The arguments to it are the class name and and a class method to invoke. It needs to be a class method; As this is the entry point to the code there is no instance yet to invoke methods on.

So that's it. Ruby running in the browser. You're welcome.

*Your superfasticalness may vary. No actual superfantasticness is either expressed nor implied by this blog post

eRubyCon: Be There!

2008-07-03T13:44:00.000-07:00

Just a quick little post to get the word out to my readers about eRubyCon in Columbus, OH Aug. 15-17th. It's shaping up to be an awesome conference. And the early bird rate makes it the best conference deal I've ever heard of. Heck, even the post early bird rate makes it the best conference deal I've ever heard of. So register already. You know you wanna.

Write your javascript in ruby with rubyjs

2008-06-04T09:17:00.000-07:00

I was inspired by Nathaniel Talbott's awesome railsconf talk to do some hacking. I had a lot of fun, and I think I came up with something worth sharing, so here it is. My willing victim was rubyjs, Michael Neumann's excellent little project I mentioned in an earlier post. If you want to play along at home, the first thing you'll need to do is fetch my code like so:

git clone git://github.com/superchris/rubyjs.git

There are some things in my repo that haven't made it into the gem version of rubyjs yet. My hack was a little "port" of the hangman example from Tapestry. It's there in examples/hangman. You can try it here. Or if you're so inclined, you can build it your dang self by running:


rake "examples/hangman/hangman.js"

This command uses a rake rule to run the rubyjs compiler which compiles hangman.rb to hangman.js.

So let's see some code how about, hmm?


class DOMElement
  def initialize(element)
    @dom_element = element
  end
  
  def observe(event, &block)
    element = @dom_element
    `
      if (#<element>.addEventListener) {
        #<element>.addEventListener(#<event>, #<block>, false);
      } else {
        #<element>.attachEvent("on" + #<event>, #<block>);
      }
    `
    nil
  end  
  
  def [](attribute)
    element = @dom_element
    `return #<element>[#<attribute>]`
  end
  
  def []=(attr, value)
    element = @dom_element
    `#<element>[#<attr>] = #<value>;`
    nil
  end
  
  def self.find_js_element(element)
    `return document.getElementById(#<element>);`
  end
  

  def self.find(element)
    dom_element = self.find_js_element(element)
    DOMElement.new(dom_element)
  end
  
  #
  # Gets an HTML representation (as String) of an element's children.
  #
  # elem::   the element whose HTML is to be retrieved
  # return:: the HTML representation of the element's children
  #
  def inner_html 
    elem = @dom_element
    `
    var ret = #<elem>.innerHTML;
    return (ret == null) ? #<nil> : ret;`
  end

  #
  # Sets the HTML contained within an element.
  #
  # elem:: the element whose inner HTML is to be set
  # html:: the new html
  #
  def inner_html=(html) 
    elem = @dom_element
    `
    #<elem>.innerHTML = #<html>;
    return #<nil>;`
  end
  
end

The first class you see here is DOMElement. This gives some basic dom manipulation abilities in a ruby friendly way. I got this working by looking at the work Michael had done on porting GWT to ruby and extracting the bit I wanted and "rubifying" it a little. Basically, you can find elements by id, observe events with ruby blocks, and get/set attributes and inner html. Pretty simple, but has what I need. I should probably extract this into a separate file in rubyjs in case other people want it. You can also see lots of examples of how rubyjs and javascript talk to each other here.

Then it's on to the hangman code. First it's worth looking at the html so you can see what dom elements the code refers to:

And finally here's the hangman class:


class Hangman
  
  attr_accessor :word, :letters, :misses
  
  MAX_MISSES = 6
  
  def initialize
    @word = "snail"
    @letters = @word.split ""
    @guessed_letters = {}
    @letters.each { |letter| @guessed_letters[letter] = false }
    @misses = 0
    @scaffold_div = DOMElement.find("scaffold_div")
    @letters_div = DOMElement.find("letters")
    @guess_input = DOMElement.find("letter")
    @guess_button = DOMElement.find("guess")
    @guess_button.observe("click") do 
      guess(@guess_input["value"])
    end
    @letters_div.inner_html = display_word    
  end
  
  def display_word
    letters.collect do |letter|
      @guessed_letters[letter] ? letter : "_"
    end.join
  end
  
  def guess(letter)
    if letters.include?(letter)
      @guessed_letters[letter] = true
      @letters_div.inner_html = display_word
      puts "You win!" if won? 
    else
      @misses += 1
      @scaffold_div.inner_html = "<img src='scaffold-#{@misses}.png' />"
      if lost? 
        puts "You lost!" 
        @guess_button["disabled"] = true
      end
    end
    @guess_input["value"] = ""
  end
  
  def lost?
    @misses >= 6
  end
  
  def won?
    @guessed_letters.values.each do |guessed|
      return false unless guessed
    end
    return true
  end

  def self.main
    hangman = Hangman.new
  rescue StandardError => ex
    puts ex
  end
end

First you see the initialize method. Here is where we lookup our DOM elements, setup a Hash of which letters are guessed yet, and bind a block to the click event of our guess_button. Next comes the display_word method, which displays each letter or a blank if it's not been guessed.

The meat of the matter is in guess_letter, which is pretty simple. If the letter guessed is in the word we mark it, redisplay the word with the guessed letter and check if the user has won. If not, we update our miss count, display the right image, and check to see if the user lost. Won? and lost? are both trivial and not worth talking about.

Well, I had a lot of fun hacking on this. I think rubyjs has a good chance to be really useful as well as fun. It needs some love, certainly, but one of the things I did was start of woefully inadequate port of miniunit I'm calling microunit. It's in rubyjs/lib. This should make it easier and, I think, funner, to flesh out the core library for rubyjs.

For next steps I may expand on this example some. I'm thinking it would be a blast to tie to a Rails backend that gives me random words (right now it is always the same word :( ) or stores scores or some such foolishness. I could use this as an excuse to build an ActiveResource client for rubyjs and maybe a rubyjs on rails plugin.

If anyone cares about this, drop me a comment and let me know. Or if you think it's utterly stupid, tell me why. I promise to read all your comments and do whatever I feel like doing anyways :)

Back from Railsconf 2008

2008-06-03T09:13:00.000-07:00

Wow, that was fun. Here's a quick recap of my personal highlights of Railsconf 2008.

Our Modelling Dialogue session

So I'm self-centered, but this was the talk I had the most concern about since I was in it. To be honest I had no idea how this was going to be received, so I was relieved and excited by the great response. I had this vision of all our laugh lines receiving the dead silence, crickets chirping response. But gratefully this was not the case. Jim Weirich has a great recap and lists the books we recommend on his blog. The feedback was so positive that we're already cooking up ideas for other talks in this format. To all those who came up and said something to us about our session: Thanks a ton! You have no idea what a help it is to hear from audience members about how it worked or didn't work for them. In short, there's nothing like going out on a limb and having it not break :) Major kudos to Jim and Joe for the idea for this one and for doing a great job pulling it off.

Nathaniel Talbott's hacking session

This was for me the most inspiring session. In a nutshell: hacking is good for you. If it's not fun it's not hacking. Being useful is not the point, enjoying yourself is. It inspired me to hack on rubyjs some more. I had a great time, and managed to come up with something worth sharing I think (tho as I said this was not the point, just a happy accident). More to come.

DHH Keynote

I actually enjoyed this quite a bit. Some of his points I really appreciated: he called BS on the whole IMO messed up american work culture idea that working more and sleeping less makes you supercoderdude. This is total crap, makes us less effective, and it's high time someone said so. Sleep more, and find some hobbies that don't involve computers. Get a life in other words. Great stuff.

Alternative Ruby impls

There was a lot of talk at the conference about non-MRI Ruby interpreters running Rails. I went to the IronRuby session. They run Rails and showed a simple scaffold example working. But I was most impressed by their silverlight demo of ruby running in the browser. Of course, only works in windows and maybe OSX. Allegedly moonlight will catch up. I'd love to really believe MS on that, but I'll believe it when I see it.

I didn't see the Rubinius talk but the did show it running Rails in a keynote. Boy is it slow, but if they can get performance up to snuff it sure is cool to have ruby in ruby.

Maglev IMO got a ton of unwarranted buzz. The part Avi did was cool, but the next part with the gemstone guy ruined it. They are nowhere close to running rails, and the sales guy was casting these sneaky sideways slams of other impls and selling a lot of vaporware. The perf numbers are impressive, but I totally agree with Charles that they mean nothing until they implement all of Ruby. Overall, I thought it kind of FUDDY, and I was quite saddened that the community just went along with it hook line and sinker.

JRuby was there, and had some good talks but since they've been running rails for a long while this wasn't really news and didn't get so much attention. I really like the JRuby rack stuff a lot tho, it opens even more doors. And I had at least one awesome hallway conversation about some big companies adopting JRuby and doing interesting stuff.

The best motivational poster ever

2008-05-01T12:19:00.000-07:00

Credit to Jim Weirich for this one :)

Ruby in the browser: a crazy idea whose time has come

2008-04-29T11:00:00.000-07:00

This point of this blog post is first, to explain why I think the seemingly nutty idea having ruby execute in the web browser is actually a good one, and second, to show how you can actually do it. Today. It might be a little long, but bear with me.

I've been spending a lot of my free time over the past few months with various different approaches for getting ruby to work inside the web browser. The obvious question would be: Why? Let me start by stating this unequivocally: I do not hate Javascript. I've more than once argued that we as programmers have given not javascript nearly the respect that it deserves. In fact, it was only through treating javascript with respect that I arrived at the conclusions that brought me here.

A few months ago I was working on a project where we needed to move some reasonably complex business logic from the server to the client. The requirements were such that we just couldn't call the logic on the server and have the application behave as desired. I decided to try to use it as an excuse to improve my javascript skills. I used the object oriented features of Prototype, and some visual effects and the unit testing framework of Scriptaculous. To the best of my ability, I tried to approach it my javascript the same way I would any of my "main" development languages. I wrote the code using test driven development and attempted to make it as clearly communicative as possible. And you know what? I actually enjoyed it quite a bit. I was pleased with the code and the users seemed to like the result. I came away with a greatly improved opinion of javascript.

But something I observed bothered me: I ended up creating exactly the same classes in javascript as I had in server side language (in this case Java). This really shouldn't be surprising, since I used test driven design on the server side java code and the client side javascript code it only makes sense it would lead to a similar outcome. But duplicate code has always been (for me) the number one code smell that indicates a need to refactor. As far as I can tell, in order to get rid of this kind of duplicate code I need to develop my core business logic in a language which can execute on both the client (web browser) and the server. I mentioned earlier that I don't think javascript is a bad language, it's not very common for server side development right now and not my first choice. Currently my favorite language for server side code is ruby. If only ruby could execute in the browser. Pure fantasy, right? Believe it or not, there are actually at least 3 possible ways to do it.

JRuby

First up in my explorations was JRuby. Quite a while back there was an experiment by Dion Almaer to a JRuby applet to execute ruby code in the web page. While this was a nifty experiment when I tried to push this idea further I hit one brick wall after another. The first is that the current JRuby implementation does a lot of things that require additional privileges which means a signed applet. The second which proved more formidable is that javascript code can't call privileged java code at all. This meant that having javascript interact with my ruby code was out. Not good. Though JRuby is near and dear to my heart, this limitation, along with the potential barrier to entry of requiring the Java plugin seemed to make this not a promising solution for what I'm trying to do.

HotRuby

So I gave up on the idea for awhile, until I recently came across HotRuby. HotRuby is a Ruby VM written in javascript. It's a fascinating idea, and it actually works. Under the covers it's really a javascript interpreter for the YARV instruction set. It requires Ruby 1.9 since it depends on YARV. There is a script which dumps out the YARV instructions for a Ruby file in json format. In the browser you include the HotRuby javscript which creates a HotRuby javascript object which executes the jsonified YARV instructions. I installed 1.9 on my machine and checked out the HotRuby code from SVN. In a few hours of playing around, I was able to get it talking with prototype.js and had a simple example where i assigned a ruby block to an onclick event of a button. Although the project seems fairly experimental at this point, it shows great promise. In fact, I was getting ready to blog about it when I came across:

Rubyjs

Rubyjs is a ruby compiler that outputs javascript. It requires only Ruby 1.8.6 and installs as a gem which made it easy to get up and running with. Be aware, Ruby 1.8.5 will not work with it, which meant I had to upgrade. Rubyjs leverages another gem, ParseTree, which parses ruby code intos-expressions, which are kind of like a syntax tree. Rubyjs then emits javascript based on these. A bit more complex but seems to work well and can support more of Ruby than HotRuby can so far.

So far Rubyjs seems to be the most viable solution to me. And if you've made it this far into the post, you deserve to be rewarded with some code. To get running is easy, just gem install rubyjs. This will give you a rubyjs command which will take your ruby code and output javascript for it. Rubyjs comes with a few examples but none which really did what I was interested in doing. I wanted to show a simple block of ruby code listening to a button's onclick event. It took a bit of delving into the rubyjs code to figure out how to do it but I think the resulting code came out to be fairly understandable. Here it is:


class DOM
def self.find(element)
  `return document.getElementById(#<element>);`
end
end

class Button
def initialize(js_element)
  @js_element = js_element
end

def onclick(&block)
  element = @js_element
  `
    if (#<element>.addEventListener) {
      #<element>.addEventListener("click", #<block>, false);
    } else {
      #<element>.attachEvent("onclick", #<block>);
    }
  `
end
end

class Main
def self.main
  button = Button.new(DOM.find("button"))
  button.onclick { puts "clicked!"}
end
end

I create a simple DOM class to help me find an element by id. This shows how you talk to javascript code in rubyjs: by enclosing your javascript code in backticks. Rubyjs does automatically maps javascript objects to ruby and vice versa. I'm not going to delve into the nitty gritty of this too much, I'll do so in a later post.

The more interesting class here is Button. A Button instance gets pass in a DOM element in initialize and instances of button have a single method onclick which receives a block. As you would expect, this allows you to set the onclick handler of a button using a ruby block. The code in the onclick method of Button is also interesting: it shows how you can pass ruby objects into javascript (the javascript code I ripped of from Prototype to do cross browser event observing). Rubyjs will interpolate the javascript code in backticks and replace # type declarations with local variables converting the ruby objects to javascript as appropriate. What this means here is rubyjs is transforming our block into a javascript function for us. Pretty cool, eh?

To see this action, we'll need to compile this ruby code to javascript. The command to do it:


rubyjs button.rb -m Main -d -o button.js

The options tell rubyjs to compile button.rb to button.js. Rubyjs also needs an entry point, which is what -m Main is about. It expects Main to define a class method called Main. Very javaesque, but this is a minor gripe. You can see this code in action here.

There's a lot more to talk about with rubyjs, and I plan this to be the first in a series of posts about it. As part of the project there is also the beginning of a port of GWT to ruby. Altho the code is a bit to javaesque for my tastes so far (as you might expect for a direct port), the idea is very interesting. Let me also issue a giant thank you to Michael Neumann for writing rubyjs and for being incredibly helpful and responsive while I was experimenting. When I asked a question he posted a new version of the gem to address my concern within a few hours. Impressive.

I'm presenting at RailsConf

2008-04-26T10:18:00.001-07:00

Long overdue to blog about this, as I found out a few weeks ago now. Amazing but true: I'm speaking at Railsconf. I got invited to participate in a very non-conventional presentation with Joe O'Brien and Jim Weirich, two guys I respect enormously. We're presenting a dialogue between several developers on modeling. It's actually proving very challenging to write, as coming up with enough things for the characters to say in 50 minutes is a lot of text. But what an opportunity. All in all, the prospect of sharing the stage with Jim and Joe has me feeling a little like this.

JRuby at TSSJS

2008-03-09T20:10:00.000-07:00

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.

2008-02-03T13:57:00.000-08:00

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

2007-11-24T18:35:00.000-08:00

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

2007-11-10T18:07:00.000-08:00

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

2007-10-24T20:44:00.000-07:00

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:

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.
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.
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.
Grab a copy of NetBeans daily builds ruby ide from here: http://deadlock.netbeans.org/hudson/job/ruby/
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.
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

2007-10-21T14:09:00.000-07:00

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

2007-08-08T09:40:00.000-07:00

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

:)

Spring Rails Plugin 0.1

2007-08-02T17:53:00.000-07:00

Well, I finally checked in my code for a Spring Rails plugin. Consider it pre-alpha at this point. It's unit tested, and I made a simple example app to prove that it works. But that's about it. So if you find it useful, try it out and let me know so I can decide where to go with it next.

To install the plugin:

script/plugin install svn://rubyforge.org/var/svn/jruby-extras/trunk/rails-integration/plugins/spring

You'll need to get a basic Rails application working with the goldspike plugin in order for the Spring plugin to be of use. Currently it loads the Spring ApplicationContext by getting it from the ServletContext (which assumes you are using the Spring context listener to put it there). So if you're not running Rails in a servlet engine it doesn't work. If there is real interest in having the plugin be able to get an app context from somewhere else I'll look at supporting that down the road.

For an example of how to use it in a controller, see my previous post.

Why you shouldn't use it

If you're a Java programmer new to (J)Ruby and are thinking: "Awesome, I'll use Spring in all my Rails apps because Spring is awesome!" you need to hold up a second. Spring is awesome -- when you are developing Java applications. But in Ruby, dependency injection turns out to be unnecessary a whole lot of the time. This is because the Ruby language allows you to change things in a more straightforward way. And even if there were cases where you needed DI in Ruby there are probably better choices. I see the Spring plugin being useful where you have existing J2EE code wired together with Spring and want to front end it in JRuby on Rails. So use this plugin if you need it, but if you don't, then don't.

Don't take my word for DI and Ruby, my friend Jim had this blog post about it after our IM conversation. See the comments where other Ruby heavyweights weigh in on the subject.

eRubyCon was awesome

2007-07-28T09:52:00.000-07:00

Just wanted to get in a blog, albeit a week and a half late, about eRubyCon. It was an awesome conference; I felt honored being involved as a speaker doing a presentation on JRuby. Being among such incredible speakers as Jim Weirich, Glen Vandenburg, Stuart Holloway, and many others made me a little like the scene in Wayne's World where Wayne and Garth meet Alice Cooper: I'm not worthy!

As far as I know, this is the first conference specifically devoted to Ruby in the Enterprise. If all you've gotten is the 30 second soundbytes about Ruby and Rails this may sound like an oxymoron, but it's not. The other speakers, particularly Glen in his "Enterprise Schmenterprise" keynote made this point eloquently. Ruby, because of it's excellence at producing easily understood and therefore much more maintainable code, is the perfect language to develop the kind of applications thought of as "enterprisey". Glen: "Enterprises aren't ready for Ruby, they're desperate for it".

Stuart made a point in his blog about this too. His series on Ruby vs Java myths made the point that Ruby is actually better for large applications than for small ones. Definitely worth a read.

Finally a big Thanks! to Joe at Edgecase for putting this together. Joe, I know it was a lot of effort time and finance wise but I hope the community can grow enough to make this a viable yearly conference: the word about Ruby really needs to get out in the enterprise development area. For their sake and ours.

include Spring

2007-06-21T08:36:00.000-07:00

I've gotten a little farther with my JRuby on Rails Spring integration code. I think I have what may make the beginning of a Spring plugin for JRuby on Rails. Here's the code for the Spring module. This is my first foray into metaprogramming in Ruby, I'd welcome any feedback.

# spring.rb
# June 20, 2007
#


module Spring
  include Java
  import javax.servlet.ServletContext
  import org.springframework.web.context.WebApplicationContext
  import org.springframework.web.context.support.WebApplicationContextUtils
  
  def spring_bean (bean)
    class_eval "def #{bean.to_s}; application_context.get_bean(\"#{bean.to_s}\"); end;" 
  end
  
  # dunno if there is a better way to do this.  I need the spring_bean method
  # to become a class method on the includee, but application_context needs to be
  # a normal instance method
  def self.append_features(includee)
    includee.extend(Spring)
    includee.class_eval do
      def application_context
        WebApplicationContextUtils.getWebApplicationContext($servlet_context)
      end      
    end
  end
end

This gives you a handy spring_bean method in any class where you've included Spring. The spring_bean method will then dynamically add an accessor to the class you use it in. This is what it looks like in a controller:

class TestSpringController < ApplicationController
 include Spring
 spring_bean :descriptor1
 def showcontext  
   render_text descriptor1.displayName
 end

end

Obviously to have this working you need several things. You need to have the goldspike plugin (from SVN trunk as per my earlier post). You also need to have Spring and its dependent jars in your WEB-INF/lib. I just copied em in for playing around purposes, with a little tweaking of my conf/war.rb file I could probably make goldspike fetch them. And lastly, it assumes you have an applicationContext.xml in WEB-INF, and that you have the Spring ContextLoaderListener declared in your web.xml.

Wow, that's a lot of trouble, why the heck would I want to do all that? What's this all for anyways? First of all, if you need this you probably don't need to ask, you know who you are. No, I'm not even trying to suggest using Spring for greenfield JRuby on Rails applications. But if you need to do heavy Java integration or you have an existing Spring application you want to front end in Rails, this kind of thing could end up being quite handy. This is my situation: I have a pretty large Spring/Hibernate/Tapestry app and I'd like to make moving to JRuby on Rails a viable option. Rather than replace everything whole hog, I'd like to be able to leverage working Spring services easily from Rails. As you can see, doing this should be a piece of cake.

Spring + JRuby on Rails

2007-06-18T00:12:00.000-07:00

I've only been threatening to do this for a year, but I finally added the necessary stuff to have JRuby on Rails talking to Spring. There's a lot more to come here, but this controller code demonstrates being able to get ahold of a Spring WebApplicationContext in a Ruby on Rails controller.


class TestservletController < ApplicationController
  include Java
  import javax.servlet.ServletContext
  import org.springframework.web.context.WebApplicationContext
  import org.springframework.web.context.support.WebApplicationContextUtils
  
  def showcontext
    app_context = WebApplicationContextUtils.getWebApplicationContext($servlet_context)
    render_text app_context.display_name
  end
end

In order for this to work, you'll have to use the very latest goldspike-snapshot plugin from SVN trunk. I just checked in the code to expose $servlet_context earlier today. Obviously this code will only work using a servlet container, and you'll need to have Spring and necessary deps in WEB-INF/lib and have the Spring context loader listener in your web.xml. From here, my next step is some metaprogramming to allow you to add spring bean accessors into your controllers.

API unickifying with JRuby

2007-04-22T23:30:00.000-07:00

So I've been putting together some code examples for RubyCodeCamp in Columbus in a couple weeks. Quite awhile back I ran into a situation where I wanted to read an Excel spreadsheet from Ruby. At the time, there was no good way to do it in Ruby (MRI) and so I used Java and the nifty POI library. I thought this might be make for a nice example in JRuby. So I fired up jirb and started coding. In a few minutes I was reading data from a spreadsheet:



require 'java'

require '/home/ccnelson/java/poi/poi-2.5.1-final-20040804.jar'

include_class 'org.apache.poi.poifs.filesystem.POIFSFileSystem'

include_class 'org.apache.poi.hssf.usermodel.HSSFWorkbook'
include_class 'org.jruby.util.IOInputStream'

File.open("/home/ccnelson/documents/Invoice15.xls") do |f|
workbook = HSSFWorkbook.new(IOInputStream.new(f))
puts "cell 0,0: #{workbook.getSheetAt(0).getRow(0).getCell(0).getStringCellValue}"

end

There's some nice stuff going on. I really like being able to just include a jar and start using it. Still, using the POI API in Ruby looks rather icky -- (actually, it started even worse than this, but Charles Nutter was on #jruby and was kind enough to tell me about IOInputStream). After looking at this code for a minute I started thinking and it came to me: "Hey this is Ruby. We can do anything we want!"

I started with that ugly getStringCellValue at the end. It would be nice if we could give cell a to_s and do away with that. Well, guess what, since this is Ruby, I can just open HSSFCell and do it:



require 'java'

require '/home/ccnelson/java/poi/poi-2.5.1-final-20040804.jar'

include_class 'org.apache.poi.poifs.filesystem.POIFSFileSystem'
include_class 'org.apache.poi.hssf.usermodel.HSSFWorkbook'
include_class 'org.jruby.util.IOInputStream'

include_class 'org.apache.poi.hssf.usermodel.HSSFCell'

class HSSFCell
def to_s
getStringCellValue
end
end

File.open("/home/ccnelson/documents/Invoice15.xls") do |f|
workbook = HSSFWorkbook.new(IOInputStream.new(f))
puts "cell 0,0: #{workbook.getSheetAt(0).getRow(0).getCell(0)}"

end

Cool! Even though HSSFCell is a java class, because I am using it from JRuby I can open it up and stick methods on it. This got me excited. What do I really want this API to look like? I think I'd really rather be able to access my spreadsheet cells using a simple 2 dimenional array. I mean, that's really what they are for my purposes. And guess what? In Ruby, the [] operator, like everything else in Ruby, is just a method. And if it's just a method, well I can abuse... err.. bend it to my own nefarious purposes. Bwah ha ha hah ha hah ha ha..

Oops, got a little carried away there. Ruby coding will do that sometimes. Back to the task at hand:



require 'java'

require '/home/ccnelson/java/poi/poi-2.5.1-final-20040804.jar'

include_class 'org.apache.poi.poifs.filesystem.POIFSFileSystem'
include_class 'org.apache.poi.hssf.usermodel.HSSFWorkbook'
include_class 'org.jruby.util.IOInputStream'

include_class 'org.apache.poi.hssf.usermodel.HSSFCell'

include_class 'org.apache.poi.hssf.usermodel.HSSFRow'
include_class 'org.apache.poi.hssf.usermodel.HSSFSheet'

class HSSFCell
def to_s
getStringCellValue
end

end

class HSSFSheet
def [] (index)
getRow index
end
end

class HSSFRow

def [] (index)
getCell index
end
end
File.open("/home/ccnelson/documents/Invoice15.xls") do |f|
workbook = HSSFWorkbook.new(IOInputStream.new(f))
spreadsheet = workbook.getSheetAt(0)
puts "cell 0,0: #{spreadsheet[0][0]}"

end

Nice! This for me is one of the killer features of JRuby. A lot of scripting languages will let you access the Java APIs in a more light weight language. But because of the features of the Ruby language, it becomes so easy to modify APIs to suit your needs, desires, and insane urges.

Welcome to my new blog

2007-04-22T10:18:00.001-07:00

I was getting kind of tired of JRoller, so I decided to move. Welcome to my new digs!



class InventoryController
end