Jun 03 2006


PNG, IE and Rails

One of the biggest complaints about IE these days is a lack of support for the full PNG spec, especially the part that covers alpha transparency. Microsoft has said, numerous times, that the lack of support stems from the fact that the alpha transparency portion of the spec is "optional", and that making IE support it is too expensive. Mind you, there is a collection of well-known workarounds involving JavaScript and IE filters, but, well, there you go.

We've been using Ruby on Rails for our development efforts for a while now, including for our website. We recently added some PNG graphics, utilizing semi-transparent shadows, which looked great on Firefox/Safari. On IE, however, we know they would look terrible. So we added one of the publicly available scripts that fix the problem. There was only one issue: it didn't work. At all.

After putzing around with different versions of the PNG fix script, and having none of them work, I finally started debugging. The scripts were being called, but never finding any PNG images to modify. So, it finally became apparent: the script I was using was looking for any IMG tag whose "src" property ended in ".PNG". Well, we use Rails. And Rails, by default, appends a randomized number to the end of URLs to defeat IE's URL-based caching mechanism. This means that none of our images ever matched the PNG script's test.

The solution was simple. Change:

if (imgName.substring(imgName.length-3, imgName.length) == "PNG")



and suddenly everything works.

An example of the law of unintended consequences (appending randomized numbers to every URL breaking a fix for non-transparent images) crashing into the law of unanticipated difference (don't ALL image "src" attributes end in .png, .gif or .jpg?) Like a Reese's Peanut Butter Cup of Doom.

Jun 02 2006


How much "object model tax" are you paying?

Programming languages usually have an object model. Programmers tend to think in the object model of one or more languages they prefer, and sometimes have trouble switching mental models. The difficulty of switching models is one reason why frameworks such as the Google Web Toolkit exist -- they let programmers work with a mental model they are used to (in this case Java) and generate code using a different, less familiar model (in this case JavaScript).

Programmers spend a lot of time arguing about which mental model is best. I think this question is unanswerable in the general case, but I want to propose a new way of thinking about it: the object model tax. The object model tax is the drag that an object model introduces to some other layer of your architecture. This drag can take the form of:

  • missing features (we can't build that using our model)
  • programmer confusion (misunderstandings of the object model that lead to trouble in higher layers)
  • bugs (things that do not work as expected because of quirks in the underlying model)

The object model tax is very annoying because it bites you again and again. If there is something about your object model that causes problems, these problem may occur again and again in different tiers of your enterprise application. Also, the object model tax, when it is noticed at all, is usually seen as a defect of the higher layer where it manifests. (For example, programmers report a problem with an MVC framework that stems from an underlying language issue.)

To make this specific, I spent an hour this morning reading through the FAQs for two technologies we use at Relevance: the Hibernate FAQ (several pages linked from here) and the Rails FAQ. I was looking for evidence of the "object model tax" -- Hibernate problems that were really Java problems, and Rails problems that were really Ruby problems. Here's what I found:

  • The Hibernate FAQ dealt with five issues that were problems with the Java object model, and four more issues that were partially object model issues, or exacerbated by them.
  • The Rails FAQ had zero issues that were problems with the Ruby object model.

(I am not going to post the breakdown, at least yet, because doing it is a good exercise, and you might come up with different numbers.)

What does this mean? I am not sure. There are lots of other factors to consider:

  • The Hibernate FAQs are a better, more comprehensive document than the Rails one. Since the FAQs are different, maybe a better comparison would analyze bug reports or mailing list traffic.
  • The proportional number of object model tax entries is small (the Hibernate FAQ has well over 100 total entries). However, their impact may be larger than this, because I bet some of the issues recur in other libraries, and in other layers of the enterprise stack.

Is anybody aware of any more detailed analysis along these lines?

May 29 2006


Relevance Review #9: Learn to Program

Learn to Program, by Chris Pine, is a small, swift introduction to programming for beginners. Despite its short size (150) pages, and conversational tone, LtP covers a lot of ground, including:

  • numerics
  • strings
  • variables
  • methods
  • flow control
  • iteration
  • methods
  • recursion
  • object-orientation (OO)
  • higher-order functions
How does such a short book cover so much? By using an excellent language for learning to program (Ruby), by following the Pragmatic Programmer mantra of "Don't Repeat Yourself" (DRY), and by introducing topics in a sensible order. (The book began as on online tutorial, and benefits from several cycles of use and feedback).

The ordering of topics above is not merely useful pedagogically; it stakes out a position about what is important in software development. Note that recursion comes before OO, that OO is important but has no special pride of place over several other concepts, and that higher-order functions appear in an introductory book. None of this has been conventional wisdom in the past decade, but I'd bet all of it will be conventional wisdom in the next.

Of course there are a few nits to pick. The pace of the book revs up substantially (and suddenly) in Chapter 9. By then, hopefully the reader is hooked and willing to work a little harder. The book has a very personal style, with lots of first-person humor. Such thing are always a matter of taste; while I usually want my tech content straight I have to admit I chuckled a few times. Finally, I'd like to see a chapter on automated testing in all introductory texts; maybe that can get into a second edition.

Last Word:Learn to Program is a solid, cleanly-written introduction to programming for technical people. As a followup to this book, of if you are already a professional programmer, check out the Pickaxe, which is the definitive word on Ruby.

May 26 2006


Posted Slides from the Ajax Experience

I have posted my slides from the Ajax experience: Prototype, Ajax Architecture, and Ajax on Rails.

Worthy of note is how the slides are built. If you follow the links you will see that I am using a custom DHTML app. I stated out using S5, but have gradually iterated towards my own bespoke JavaScript and Ruby on Rails powered solution. If you want to view the slides in print, you can now do that, thanks to Austin Ziegler's cool PDF::Writer for Ruby.

May 23 2006


Rails, meet Enterprise. Enterprise, Rails.

A long time ago, I asked the question: what would Rails need to have to be "Enterprise Ready(tm)?" A lot of the answer had to do with Messaging. Well, the fanboys at ThoughtWorks have apparently been working on just that. The really small sample looks interestingly compact, so compact, in fact, that I have a hard time seeing how and where you might configure it to talk to a .NET/MSMQ hub vs. a JMS provider, but I'm sure if I could get my greedy little hands on the code, all would become apparent.

The project apparently utilizes STOMP from Codehaus. It isn't a full-on MOM backbone, but close enough for government work, and certainly close enough to be useful for many of the needs of message-enabled web sites. If this really comes alive, then, according to my anecdotal research, the other three "must have for Enterprise Readiness" features still lacking are:

  • Support for 2PC distributed transactions. But, since only about 5% of enterprise applications, and, like, 0.00045% of web applications, ever actually utilize this, I won't hold my breath or demand anybody else do.
  • Internationalization. Huge problem, must be solved soon, many people working on it.
  • A real component-based backend for rendering, a la JSF or Tapestry. While I like Tapestry, I am at best ambivalent about JSF and just don't see the point in going this route for Rails. Beyond that, I believe that anybody who makes this a pre-requisite for being "Enterprise Ready" is just looking for excuses. What they REALLY want, it seems to me, is a marketplace for buying/trading chunks of reusable code for website generation, for which Rails offers the plugin model and distribution network.

So, while a half-finished, not-officially-announced-yet messaging backend that isn't a full JMS clone won't make the Fortune 50 swivel around in their evil chairs and shout "Down with Java! Vive la Ruby!", it sure could be a giant step in the right direction. Makes me a lot happier, anyway.

May 22 2006


Books Partnership: Relevance and the Pragmatic Bookshelf

I am pleased to announce that we will be partnering with the Pragmatic Programmers to provide a free book for each attendee of Relevance's onsite training in the following technology areas: Ajax, Ruby, and Rails.

When you schedule a course with use, tell us which Pragmatic Bookshelf book you'd like. (How do you know what books there are? Head over to the Pragmatic Bookshelf and browse their catalog. If you're coming to a Rails class, then Agile Web Development with Rails would be a first choice. If you already have that book, then perhaps Rails Recipes, or Enterprise Integration with Ruby, or Best of Ruby Quiz. Then let us know which title you'd like, and we'll have it available for you to pick up at the course.)

One part of the value in training is being able to point people to quality sources for more information, and I can't think of anyone I am more comfortable recommending than the Prags.

May 22 2006


Pragmatic Studio: Ajax coming to Boston Sept 11-13

The Pragmatic Studio: Ajax is coming to Boston September 11-13. You can check out the site for complete details, but I wanted to mention one thing here: our approach to hands-on exercises.

A big challenge with Ajax training is creating useful hands-on exercises that don't bog attendees down in the details of setting up some random server on their laptops. For the Studio, we have finessed this problem by providing a shared server. Attendees browse to a page, do "View Source", copy a file to their local machine, and edit the HTML file to make calls back to the shared server. This keeps things simple (no server setup) and forces everyone to think about keeping their Ajax code decoupled from server implementation details.

Since calling a remote server from a local HTML file isn't directly legal in Firefox, we provide various versions of the following hack to enabled limited cross-site capability.

  // Modifies Prototype so that Ajax requests ask permission to go cross-site.
  // Useful for pages that are run from the local filesystem.
  CrossSite = {
    wrap: function(original) {
      return function() {
        try {"UniversalBrowserRead");
        } catch (e) {
          //alert("caught " + e);
        original.apply(this, arguments);
  Ajax.Request.prototype.initialize = CrossSite.wrap(Ajax.Request.prototype.initialize);
  Ajax.Request.prototype.onStateChange = CrossSite.wrap(Ajax.Request.prototype.onStateChange);
  Ajax.Updater.prototype.initialize = CrossSite.wrap(Ajax.Updater.prototype.initialize);

As I have said before, Enterprise software is all about flexibility. It is a testament to the Enterprise-worthiness of JavaScript as a language that I was able to so easily find the hooks needed to make the cross-site hack work. Not to say that this particular hack is the best way to do cross-site Ajax in a production setting, but it is the exact fit for our needs.

May 22 2006


Get Your Requests In for the MetaRails Talk

I will be giving the MetaRails talk at RailsConf 2006. The purpose of the talk is to expose and document Ruby power techniques that are used in the Rails codebase itself. If you have always wondered how Rails does some piece of seeming magic, drop me a line or comment on this blog entry. I'll add the most interesting/challenging suggestions to the talk. My current list of topics is

  • Three Easy Pieces
    • The to_proc Trick
    • Indifferent Access
    • How nil Became whiny
  • How'd They Do That?
    • How Does Rails Guess Names of Things?
    • Where do ActiveRecord Accessor Come From?
    • How Do Variables Get From Controllers To Views?
    • How Do Classes Get Reloaded During Development?
  • Deep Magic
    • How Transactions and Versioning Work
    • How breakpoint Works
  • Following Their Example
    • Writing Your Own Validations
    • Generating Tests
    • Creating Non-ActiveRecord Models
    • Creating an Internal DSL

May 18 2006


When speakers write...

For the last three years, Justin and I have been speaking on the No Fluff, Just Stuff Symposium (NFJS) tour. Our reason for participating is simple: we like the people. Attendees are typically developers who are passionate about their work, enough so to come to a weekend conference. Speakers are not just talking heads, but real developers who spend most of their time building software, and then give up their weekends to share their interest with others.

This may not sound like conferences you remember. Many developers (including some of the best ones I know) are cynical about conferences, assuming the worst based on past experiences. Well, if you want a low-cost, low-effort way to check out No Fluff content, here's a possibility to consider. The speakers at NFJS have put together a book, the 2006 NFJS Anthology. My own contribution, on Spring AOP, is available at the book's site as a free sample. Thanks to Neal Ford for doing the editing, and the Prags for handling the printing. If you are on the fence about conferences, start with the book. If you like what you see, I hope we'll see you at an NFJS symposium soon.

May 03 2006


Rails Recipes Training

We're adding a new Rails Recipes course to what we think is already the most comprehensive Rails training curriculum anywhere . Rails Recipes is based closely on Chad Fowler's excellent book of the same name. Like all Relevance training courses, you will get to pick and choose the exact topics your team wants to cover. (Recipes are pretty bite-sized, so expect to be able to cover 5-6 in a day). And of course, every attendee will get a copy of the book!

Popular Tags