Long Rails Stack Trace

I was looking at the RailsConf schedule, and saw the Rails web app that runs it fail with this longish stack trace. A few Rubyists sitting nearby commented that the application was not well configured, that usually Rails apps are configured in deployment to store such traces to a log, rather than spit them at the user. Their mistake is my gain though, as it provided fodder for this post.

This stack trace is considerably shorter than a typical Java web app stack trace. But it is not so good either, and it is an ominous sign that excessive complexity is making its way in to Rails.

How To Do Deployment (Dave Thomas RailsConf Keynote)

I just attended Dave Thomas’s keynote at RailsConf. He had many interesting things to say, most notably that 60%+ of his Java-centric conference-circuit friends, mostly people who have written books on Java, speak regularly on Java, and have lots of experience as Java “architects”, are now making a living with Ruby / Rails.

Dave talked about 3 key areas where Rails should improve. The one I want to focus on is deployment. Rails has Capistrano, a slick tools for deployment automation. Capistrano is great, but it misses the boat in one key way: it is push-based. It assumes a world where the developer sets up, controls, and performs deployment to production servers. That is of course the case at the start of a small operation, but it doesn’t scale; in large organization, or even in small growing ones, sooner or later there is staff dedicated to production deployment and monitoring, separate from development.

One way, to me right way, to handle deployment is push / pull:

For the “push”, a developer uploads a new version to a storage site somewhere. It travels in the form of an archive file (ZIP, tgz, whatever) which contains all of the needed artifacts, as well as metadata about the required libraries, pre- and post-install steps, etc. for the new version. It has a unique name; it lands at a URL. Normal, off the shelf technology (FTP, web servers, etc.) can be used to serve and secure this storage, implement policies about who can upload new versions, etc. This upload happens with some simple one-line command (or as part of an auto-build); it does not actually put a new version in production, but only makes it available for pulling.

Then, on a production machine, someone with software installation rights on that machine (administrated by the normal tools – not by any special feature of the deployment mechanism) runs a command (something like “deploy staging http://ourserver/project1/project1-build-3453.tgz”) which downloads the new build, runs various sanity checks, deploys it to a staging area, and makes it available to try out. Once the staging is verified, a similar command brings it in to live production. These builds refer as needed to configuration data on the deployment machines (such as production DB access credentials); the build archives are generic, not specific to any particular production machine.

The main idea behind this is that each person has the rights they need for the work they need to do, and these rights don’t need any special help or support from the deployment mechanism. Developers don’t need any special rights on deployment machines, nor to deployers need any special rights on development machine

I wrote this in the context of a Rails / Ruby talk, but it’s at least as relevant in Java and Delphi world; in fact at Oasis Digital we need something like this on a Java project and a Delphi project right now.

Pure Ruby Sparklines – No RMagick ImageMagick

This Pure Ruby Sparklines implementation got my attention – unlike other Ruby graphics packages, it does not need RMagick, and thus not ImageMagick, sparing the installer considerable effort and misery. The source of that misery is the long list of dependencies; now of course a great positive of the open source world is that tools can readily build on each other – but this comes with a cost of unexpected complexity in getting things to compile and install. We had a project here delayed by a couple of weeks of working through issues in getting it all to work on shared hosting account. I never did get it working with Ruby 1.8.4 on Windows, I reverted back to 1.8.2 for now.

With a “Pure Ruby” implementation, you copy the .rb files over and it works. I wonder if “Pure Ruby” will become a marketing point like “Pure Java”.

Lest anyone accuse me of unwarranted Ruby fanhood, I’ll point this out: with Ruby it is necessary to find or what code for graphic drawing. With Java, it is in the box, in the form of the excellent Java2D feature set. Ruby is way behind in the area.

Going to RailsConf. Be wary of software religion.

I’m going to RailsConf 2006 in Chicago next month:

The interesting thing about this is that I signed up before I knew how popular it would be – it sold out in a few days, so the pent-up demand must have been remarkable. More remarkable is that it sold out long before the full list of speakers and talks was released (or even existed). Me and 500 other people didn’t even need to know what/who would be there, to decide to go. For me, that is because I have a project going that uses Rails, and I generally enjoy software conferences, and this one is close.

But maybe there is more. Is Ruby+Rails a fad? A cult? I nearly always enjoy the Ruby on Rails Podcast, but its intro music proudly and bizarrely claims that “we’re building a religion”.

I don’t know who “we” are, but I’m not on board with that.

The Rails aren’t so smooth if you want some [Image]Magic[k]

We started some work recently with the much-hyped Ruby / Rails combination. For the most part, it’s lived up to the hype; going down it’s ‘happy path’ has been far more productive than work with some other web app frameworks and languages. But today I hit several sources of Ruby / Rails pain in a row, and it seems worth writing about them, perhaps to save the next fellow from the same.

The nexus of the pain is RMagick, which, once working, is a great set of tools for drawing graphics in Ruby. My partner on this project had some trouble getting the numerous dependencies in place on Linux and/or MacOS; he thought it would go much easier on Windows, since there are far fewer dependencies.

Indeed, it should have been easy. I went over to the RMagick download site and grabbed the latest and greatest almost-ready Windows Gem, version 1.10.1. Its instructions said I needed Ruby 1.8.4, so I remove my old 1.8.2 and grabbed Curt‘s One-click ruby installer. It is a release candidate (“184-16 release candidate 1”), but Curt said the other night that the installed software is ready to go, he’s only working out a few installer issues.

All good… except now nothing worked at all. Lots of errors like “./script/../config/../app/views/admin/signin_form.rhtml:3: Invalid char `\360′ in expression” and “./script/../config/../app/views/layouts/login.rhtml:2: parse error, unexpected $, expecting kEND”. After considerable searchings I found clues and then the answer. The RMagic docs led me astray – by ignoring them and going back to 1.8.2, it all works again… for small values of “all”… because 1.8.2 doesn’t include Rake, Rails 1.1 prefers 1.8.4, etc.  It appears, if I understand the various posts correctly, that RMagick breaks Ruby by changing a method on String. This is a rather unfortunate, surprising, and in my judgement, bad thing for such a library to do; I can’t imagine offhand why RMagick should do anything at all until invoked. At minimum I’d hope to be able to trust an image manipulation library to not touch, much less break, the String class 🙂

That’s enough digging for now; hopefully when I return to this, the issues will be worked out, there will be matching, current, compatible versions of all these parts, and things will run smoothly along the “rails” as usual.

Ruby OpenGL, Kororaa Xgl

Last night at StlRuby.org the question came up of how to contruct GUIs with Ruby. I mentioned that I think there is a lot to be gained by using the high performance graphics hardware APIs, which are mostly used for games, in business applications. This of course is not all that remarkable, since Java Swing has used DirectX for drawing for the last several years, and Windows “Vista” will use it for most of Windows itself. I’ll discuss this idea more in a later post; I’m investigating it here for a couple of Oasis Digital projects. On my list of tools to experiment with is Ruby + OpenGL; there is a RubyGarden page about it and another page here, unfortunately in Japanese. I found a ruby-talk post which indicates that it works quite well.

John McClenning pointed out Kororaa Xgl, a project which modified an X server to draw with the OpenGL API; there is a LiveCD of the Kororaa Linux distribution for trying this out. I’m downloading it now the torrent. Novell is also a sponsor of this effort.

(A plug: uTorrent is the best BitTorrent client I’ve seen so far: it is small, clean, featureful, usable, robust, ad-free, and free.)