September 20, 11:24 | Comments (20)
Criticism is one of the most powerful creators of progress in every facet of life. People change, laws change, governments change in the face of sufficient criticism. But that doesn't mean it's always a net benefit. Some times criticism can destroy instead of create.
Dan Russell talks about how much he learned from having a piece of software he created labeled "..the most white male fascist tool I’ve ever had the misfortune to use..." on Creating Passionate Users. His tool was too opinionated for this one female designer and the designer let her know. Dan was able to use that experience as a positive reflection. The criticism worked.
 Not all creators are as strong as Dan. Sitting in a doctor's waiting room the other day, I read an interview with Danish comedian "Anden" (The Duck). He talked about how he chooses to deal with criticism of his shows. His guiding principle? Criticism from friends considered useful, criticism from anyone else considered harmful.
He expressed it like this:
"A show is one-way communication. I show them what a pearl I've created. How polished it has become. Then they shouldn't come up and expect a diamond. I can show them that this is THE PEARL. Perhaps it'll come in other colors, too. But regardless, this is a pearl."
I love that. Anden is protecting his fragile source of motivation by scoping his work narrowly. "If this is a pearl, I can reject criticism arising from the desire to get a diamond". That's a powerful survival rule in effect. If Anden was as strong as Dan, it's likely that he could learn and improve his show from diamond criticism. But he's not, so he rejects criticism to protect his ability to make any show at all.
And on some level, I'd wish more software developers did the same. I've seen more than a fair share of developers withdraw from public development because of criticism they either didn't shield against or weren't strong enough to absorb. Yes, it's preferable if you can develop enough distance from your work to accept criticism like the best of them. But it's not a skill worth pursuing at the expense of creation.
So if you have to choose, at least in the short term, I hope you pick to shield rather than to run. Mark your work a pearl, reject requests for diamonds. I desire your creation more than I care for the privilege to criticize it.
September 16, 0:18 | Comments (13)
What an amazing two days! Such an overwhelmingly good experience. Not that I expected the official European RailsConf to be a tame affair, but I frankly hadn't expected this level of quality, intimacy, and breadth. There were so many good talks, so many enthusiastic people, and so many truly impressive projects being showcased.
 I personally had the good fun of talking about the next step in our theme of Simply Something. First, I gave a working demonstration of Active Resource and how it'll immediately work with the forthcoming resources_scaffold. Wrapping up Simply RESTful by showing all the thoughts from RailsConf Chicago converted into live, working code.
Then I got to show off Simply Helpful. Our intent to bring conventions and simplifications to the world of the view. From div_for(person) to render(:partial => @people) to link_to(:name, person). Scott's Place has the full write-up. You'll surely hear more about this, especially once we have Rails 1.2 shipped and are able to focus on it more exclusively.
But in the overall scheme of things, my presentation was rather inconsequential. It was far more interesting to see all the other fantastic stuff being demonstrated from people in the community at large.
Impressive shows from HAML, UJS, JRuby, and Capistrano
 HAML gave us a great take on how views can also be done. It looks a little cryptic at first, but don't let that shake you off. Once you internalize the meaning of %, #, and . it should be all good (and you already know most just from CSS). I'm not sure it's my flavor, but I love the willingness to think different.
Additionally, I can't help but have respect for a Canadian who manages to swear more than I did during my vendoritis rant and drink beer at the same time. A perfect example of the diversity in the Rails community. Very much part of what makes us special.
Honorable mention also goes out to Unobtrusive Javascript for Rails (UJS). By far the most professionally produced plugin I've seen yet. The guys behind it has strong opinions and plenty of passion. It's thrilling to see them being able to express it all with Rails without necessarily needing any kind of official support or blessing. This is one to watch for sure.
JRuby also impressed me. It's hard not to be in slight awe of seeing Rails run at a fast clip on top of Java and making snappy calls to EJBs. It's one of those things were I count my lucky stars that I won't ever need, but it's incredibly cool for those who happen to be saddled with a significant Java investment. Props to Charles Nutter and crew for making such rapid progress and to Sun for seeing the potential.
 From my own backyard, Jamis Buck knocked my socks off with Capistrano Shell. What I wouldn't have given to have had that feature available during the initial setup of the new 37signals cluster.
If you manage more than one server, you should run, not walk, to get hold of Capistrano 1.2.
Kathy Sierra, _why, and Dave Thomas
I'm probably one of the biggest Kathy Sierra fans out there. She's so spot on in just about everything she writes about that it's a true joy to refresh my newsreader and see a new post from her Creating Passionate Users blog.
 Having her talk at a RailsConf was an honor. She probably couldn't have picked a community more in tune with her values and more interested in her work. She's a sensational speaker and she made a great impression on the crowd. I kept overhearing conversations mentioning her talk throughout the conference.
Just as spot on Kathy was, just as funny _why was. But not only is he an overly-entertaining performer, he's also one heck of a programmer. Every _why talk has at least a handful of Ruby nuggets that I hadn't thought about.
 And his latest work on sandbox looks stellar. Making it drop-dead easy to run multiple Rails applications in the same Mongrel process without conflicts. Thumbs up to both him and Matz for getting Sandbox on track for inclusion with the next Ruby release.
Finally, Dave Thomas rounded it all off with one of the most inspirational technical speeches I've ever heard. Tying terrorism, FUD, and enterprenuial aspirations together under one overarching theme takes serious skill. No wonder he was met by standing ovations afterwards.
And everything else that went on
I really had a blast. Meeting half the core team again in person was great. Shaking the hands of so many programmers who've found passion in Rails was great.
There was such a strong sense of community. Despite lots of minor disagreements and different view points, we all seemed to share a great many underlying values and appreciation for the same aesthetics.
And it's still hard to believe that we've come so far, so fast. That we have so many extremely talented developers working together. Enough to fill two conferences with multiple days of up to 4-way tracks within just a few months apart. Truly astonishing.
On top of these two recent real-life highlights, it's great to know that we'll be taking it even higher next year. With O'Reilly co-organizing both RailsConf US in Portland (May 17-20) and RailsConf EU in Berlin (September 17-19). I've grown a little weary of conferences in general, but there's no doubt that these are two I wouldn't miss for the world. I hope to see you there.
To get a taste of RailsConf Europe, see the Flickr stream and the Technorati tail.
September 13, 2:22 | Comments (58)
There's a reason we have more than one programming language at our disposal. And it's not just because some people like curly brackets and others like forced indentation. It's because they're actually good at different things. It's usually the overlap areas we debate. Places where one could reasonably argue that more than one language would be a good fit.
It's not so often we argue about the extremes. I don't hear a lot of people claiming that operating systems should be written in PHP. Or that guest books should be written in C. It just appears self-evident that you pick from the sphere of reasonable applicability.
This is true even within single applications. Yahoo mandates PHP at the surface, but uses C++ for most back-ends because they need to handle a few billion page views per day. Amazon too has lots of core computations in C++ (and even Java), yet uses Perl and Mason for the front end. A reasonable division of labour at the biggest sites on the internet.
But we don't need to go to the moon to look at a rock. In Basecamp, we accept uploads for pictures of people in the project. We just need a 48x48 mug-shot, but plenty of people upload multi-megabyte images, because that's all they've got handy. Now we're completely screwed, right? Ruby is painfully slow, so doing live image manipulation would surely bring us to our knees, right? Here's the method:
def thumbnail(temp, target)
system(
"/usr/local/bin/convert #{escape(temp)} -resize 48x48! #{escape(target)}"
)
end
I can hear it already: "But that's cheating!" Of course it is. Cheating is good, cheating works.
That's one of the wonders of living in a so-called scripting language. You don't have to invent image resizing from scratch. Someone already did a stellar job in C. You also don't have to invent, say, a Bayesian filter from scratch. Someone probably also did a pretty good job of that in another fast language that you can just call out to.
Most of the time people even institutionalize the cheating by creating thin, native wrappers around C-libraries. For image resizing, there's RMagick. For database calls, there's MySQL/Ruby. Hell, even PHP started out being primarily a friendly way to call C functions.
The era of islands is over for most development scenarios. You don't have to make one definitive choice. Instead, you get to hog all the productivity you can for the common cases, then outsource the bottlenecks to existing packages in faster languages or build your own tiny extension when it's needed.
We did the exactly the latter for Campfire. It has one clearly defined bottleneck. Hundreds of users polling every three seconds for updates. Originally the polling mechanism that handled that was 100 lines of Ruby. We rewrote it over a few hours to 300 lines of C. So we got to keep 90% of the application in Ruby and then we outsourced the bottleneck to C. Writing the entire application in C just so we could get the maximum performance from the polling service would have been madness, so I'm glad we didn't have to choose.
So please don't let bottlenecks (real or imaginary, usually the latter) dictate your choice of software development environment. We have a term for that and it's called premature optimization. I hear Mr. Knuth puts people on trial for exceptionally gross violations. And I fully expect that Mr. Spolsky will be served his papers instructing him to appear before the tribunal shortly.
Just after he explains to the grand jury of Smalltalkers how dynamically-typed languages can't be fast because a method call doesn't compile down to a single CALL instruction.
P.S.: Yes, this was provoked by Ruby Performance Revisited. I swear I won't bite on the next Joel trolling. Really. Promise.
September 01, 22:19 | Comments (88)
It seems quite a lot of people assume that Joel's Wasabi language was or is a joke. I sure hope so too, but I really don't think it is. If I had just read his Language Wars piece, I probably would have chalked Wasabi up as a joke. The benefit of the doubt would have made me err on the side of sanity.
But I happened to remember an interview that Doug Kaye from IT Conversations did with Joel about a year ago. In this episode, Joel talks about the wonders of building FogBugz on technology that he controls. Namely VBScript. He explains how they built a compiler for VBScript that emits PHP and that they have plans for extending the compiler for future hot targets.
I think that's what eventually turned into Wasabi, although the name itself may indeed be a joke. Even better, he recommends this as a good strategy for other companies, presumably in the web-application space (since all of this talk is stemming from his FogBugz experience). Among other things, he says:
We feel we've built technology on a platform that we, to some extent, control... and that's really what you should be doing if you're trying to make technology that you're going to build a company on.
(For those listening along, this discussion starts at about the 47:17 mark. Near the end of the show.)
So for Joel, portability is so important that you'll want to stay with a language like VBScript and just consider all other platforms a compile target. It's in light of those words of wisdom that I don't think Wasabi is a joke. By god, I wish it were, but I don't think so.
Joel?
Update: Joel just wrote me and confirmed that Wasabi is not a joke. His claim goes that making your own language is great for his environment (installable software for many platforms), but that an enterprisey context needs The Big Three because the prime directive is not to get fired. I think that's a depressing world-view and it doesn't explain the FUD, but none the less. Wasabi is real.
Update 2: Joel wrote up the Wasabi is real piece and his argumentation.
P.S.: Quick comments on the original two complaints that actually had any merit. First unicode, yes, it's currently more cumbersome than would be nice to deal with it. But it's by no means insurmountable. All applications at 37signals happily speak UTF-8. We got people from 50+ countries using Basecamp with content in their native language. Lots of applications run internationalized too. We got a great Rails constituency in Japan, Russia, and elsewhere who manage to make it work. But sure, it should and will be nicer to deal with shortly.
Second speed, Rails is for the vast majority of web applications Fast Enough. We got sites doing millions of dynamic page views per day. If you end up being with the Yahoo or Amazon front page, it's unlikely that an off-the-shelve framework in ANY language will do you much good. You'll probably have to roll your own. But sure, I'd like free CPU cycles too. I just happen to care much more about free developer cycles and am willing to trade the former for the latter.
September 01, 7:20 | Comments (136)
Joel Spolsky is a good writer. I've thoroughly enjoyed many of his pieces. Language Wars is not one of them. Actually, let me recant that. It's not entirely true. I did enjoy his latest piece on one level. It's one of the purest forms of FUD I've ever seen against Ruby and Rails. Not even the best of the Java guys can keep up with Joel on this.
Fear:
I for one am scared of Ruby because (1) it displays a stunning antipathy towards Unicode and (2) it's known to be slow, so if you become The Next MySpace, you'll be buying 5 times as many boxes as the .NET guy down the hall. Those things might eventually be get fixed but for now, you can risk Ruby on your two-person dormroom startup or your senior project, not for enterprisy stuff where Someone is Going to Get Fired.
Uncertainty:
I'm really not sure that you won't hit scaling problems, or problems interfacing with some old legacy thingamabob, or problems finding programmers who can understand the code, or whatnot. So while Ruby on Rails is the fun answer and yes I've heard of 37 Signals and they're making lovely Ruby on Rails apps, and making lots of money, but that's not a safe choice for at least another year or six.
Doubt:
Ruby is a beautiful language and I'm sure you can have a lot of fun developing apps it in, and in fact if you want to do something non-mission-critical, I'm sure you'll have a lot of fun, but for Serious Business Stuff you really must recognize that there just isn't a lot of experience in the world building big mission critical web systems in Ruby on Rails.
This is truly golden. Now, now. Some might accuse Joel as being a little late to the FUD party. That most of the guests already went home. But what's a few years off? It wasn't too long ago Joel thought VBScript was a reasonable language for web development. Or that these new fancy exceptions probably didn't scale.
But it gets better. Joel finishes off with a prize so good you can't help but wonder if he's pulling your leg or not. So in summary, Ruby and Rails are both immature, right? A decade for the language, two-something years for the framework. Tens, if not hundreds, of thousands of programmers exposed between the two. Okay, I buy that this could be seen as "immature" if you're into comparing quantity of programmers or deployed applications against, say, Java or PHP.
Now strap yourself in and reach the final paragraph:
FogBugz is written in Wasabi, a very advanced, functional-programming dialect of Basic with closures and lambdas and Rails-like active records that can be compiled down to VBScript, JavaScript, PHP4 or PHP5. Wasabi is a private, in-house language written by one of our best developers that is optimized specifically for developing FogBugz; the Wasabi compiler itself is written in C#.
So Joel and friends invented their own language, which has to reasonably compile to three and a half different ones. Yes, they're building their Serious Business Stuff application on a 1-off, closed language. So please do as I say, not as I do, dammit. And pick something mainstream and "safe".
I swear I couldn't make this stuff up even if I tried. Joel, you're my new hero of irony. And as soon as you start selling those t-shirts with "Serious Business Stuff", I got green ready to flow. Short of that, I'd take a red teddy bear with the embroidering "Someone is Going to Get Fired".
Update: Was Joel's Wasabi a joke?
| 