Two of the examples in my MetaRails talk (given yesterday) are already out of date. Rick Olson pointed out that the “around advice” idiom has already been DRYed out a bit, and David told me that reloadable classes had been totally reworked.
I don’t have time to update the slides today though—for next 72 hours I am completely buried preparing and teaching a Java course. Don’t feel sorry for me though, I get to talk about the cool parts.
Its always fun to be recognized, but it was a real treat to have Dave Thomas mention us during the opening keynote at RailsConf this week. I found him in the hallway later and thanked him for the kind words, and in classic Dave fashion, his response was: “No problem—now live up to it.” Dave, we hope we will.
The topic of Dave’s keynote was the “3 Unsolved Problems” of Rails. His second problem was lack of good CRUD support, specifically anemic scaffolding. Its no secret that the scaffolding in Rails is what brings most people in, but is also the first thing left on the cutting room floor when people start really getting into it. We think this is a shame.
The idea of scaffolding isn’t the problem; the implementation is. Companies with lots of internal projects with rapid deployment schedules (dare I say “enterprise”) need a way to quit worrying about the same stuff every time they whip up a new app. Specifically, layout, relationship management, add/update/delete features, find and sort, etc. The stuff that dev teams waste thousands of hours recreating app after app, even on the same team for the same company.
We’ve been struggling with that problem both internally and with our customers, and we’ve taken the tools that we’ve been building over time and are going to release it as an open source addition to Rails. We’re calling it Streamlined. The first public release will be at OSCON in July, but you can check out the blog now for features, futures, screenshots and technical details.
Stu and I will be at RailsConf this week. If anybody is there and wants to hook up and chat, here’s a vague outline of where we’ll be:
Hope to see folks there! We’re excited about seeing the community come together, and can’t wait to see what happens in the hallways (that’s where all the fun is, anyway).
Reading through the comments on Cedric’s post, I came across this beautiful gem by Hani:
“it’s probably no coincedence that many/most agilists (at least,that I know of, they don’t tend to be a closeted species) are consultant types; an environment where maintanability is not an issue, and the fact that it takes a long time to get acquainted is a good thing.”
As a consultant, I can tell you this: if I write unmaintainable code, I don’t get invited back next quarter. If I don’t contribute right away, I don’t get invited back next week. Generalizations like this are just silly. Maybe there are companies that just pay out consulting fees without bothering to examine the results, but if they’re out there, could somebody please hook me up? We’re looking for a cushy gig.
I don’t know exactly what makes a programmer an Agilist, but the straw man just got a thorough beating.
It sounds like the presentation Cedric saw was over the top. That’s too bad—I’ve seen some smart people do a good job demoing TDD with examples like the Stack example Cedric mentions. I even sneak it into talks myself sometimes. (Admittedly the examples are toys, but usually the presenter is able to go off script and explore more serious examples.) I hope the people at the presentation Cedric mentions get some other, more even-handed exposure to TDD.
Full disclosure: I have written a book for Dave, and consider him a good friend.
Like a lot of technical folk of my generation, The Pragmatic Programmer is a shining city on a hill. After reading that book, I was never the same, as a programmer, and in some ways, as a person. Dave and Andy wrote a classic.
When moving from a general-purpose, philosophical book like PragProg to a more directly technical tome like Programming Ruby, you might think that something could get lost. The great conversational style, the ability to get to the heart of problems and not get lost in the wilderness of meaningless details, the brevity, might all fall away. As the wise man said, two out of three ain’t bad. Coming in at 787 pages without counting the index, the book can be called many things, but brief is near the bottom of the list.
As for the rest, I can say that this book is one of the most engaging technical books you’ll ever have the pleasure to read. The Pragmatic style, wit, and insight are all on dramatic display throughout the book. In fact, they pulled off one of the greatest tricks in the biz: they made this giant technical reference book almost feel narrative. No mean feat.
When I read a technical book, there are usually two important reactions I have to the text as I read through it. “Why in the world are they covering this?” and “How could they not talk about that?” The Pickaxe simply never makes me ask the first question; everything covered in the book is easily placed in context and never feels out of place or too esoteric to be useful. There are certainly times when I asked the latter question (and still do) but it is impossible to fully document any technology, let alone a 10-year-old language and community, in a single volume. It is therefore difficult to find this to be much of a problem.
The book is broken into three primary sections. The first is the narrative portion. This is what most people will read when they site down with the book the first time. It takes up at least half of the total space, and is laden with fact and opinion. I find myself turning to it time and again to remind myself of not just how a given piece of Ruby works, but how I ought to be using (or not using) it.
The second part of the book is the standard library guide. This collects into one place every method of every class that makes up the Ruby core. This is enormously useful in a world where very few of us have IDEs with code completion for Ruby. However, I almost never use the book for this purpose, using the online version of the previous edition instead, since that gives me online search and copy/paste.
The third part is the only really flawed portion of the book. It is a reference describing all of the non-core Ruby libraries. Each library gets a page which is often barely enough to tell you what it is for let alone how to use it. On the plus side, most of the pages have a piece of example code that lets you try to get started. I understand the underlying problem; if they’d done each library full justice, the book would be another 200 pages and only 8% of the readers would have reaped any benefit. However, if you are looking for an example of how to use OpenSSL with Ruby, the page in this section isn’t terribly useful.
For my money, the Pickaxe goes down as one of the finest technical reference books ever published. Its combination of wit, wisdom, style and efficiency should (and do) serve as a model for how other technical books should be written. If you write (or want to write) Ruby code, it should be laying open on your desk at all times.
We’ve been using Javawin for a few months now; its a great windowing toolkit in pure JavaScript. Its good enough that, while demoing it recently, somebody complained because the modal windows still let them click. On the desktop.
One of the library’s great features is configurable open/close effects per window instance. You can choose any effect from the Script.aculo.us library for bringing your window into being and getting rid of it when you are done. The latter, though, has a problem.
If you call setDestoryOnClose() on a window, this means that the instance will be terminated whenever the window is closed (as opposed to left hanging around taking up memory). However, the way the code in the library is written, this means that your hide effect will never be invoked and the window simply disappears. Here is the fix.
Change setDestroyOnClose to this:
setDestroyOnClose: function() {
if(!this.hideEffectOptions) this.hideEffectOptions = {};
Object.extend(this.hideEffectOptions, {afterFinish:
this.destroy.bind(this)});
this.destroyOnClose = true;
},
Change Windows.close to:
close: function(id) {
win = this.getWindow(id);
// Asks delegate if exists
if (win.getDelegate() && ! win.getDelegate().canClose(win))
return;
if (win) {
this.notify("onClose", win);
win.hide();
}
},
(just take out the call to win.destroy).
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")
to
if(/\.PNG/.test(imgName))
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.
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:
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:
What does this mean? I am not sure. There are lots of other factors to consider:
Is anybody aware of any more detailed analysis along these lines?