Tomorrow morning at the ungodly hour of six, I'll be boarding a plane to travel the world. Or, rather a few good conferences around the world. Or, really, just the US and the Netherlands. Anyho, the itinerary is: Web 2.0, RubyConf, and EuroOSCON. Listening to Jason keynote at the first, speaking myself at the second, and keynoting at the third. Go KLM!
So remember that project we promised all that long while ago? The one that got bumped not once, but twice? So it's finally done. No, it's not a huge thing. But quite possibly the most polished one we've done so far. And simply useful. Anyway, I shall withhold my teasing. You'll be able to play around with it yourself come early next week.
Boy, there was a lot of pent up demand after running short on the last printing. This week has seen some 4,700 copies of Agile Web Development with Rails ship to directly to customers, to Amazon, and to lots of local book stores. That should hopefully deal with the massive shortage that has been around for a good long while. They didn't even have any copies of the book at JAOO — despite having lots of willing buyers. What a shame.
Naturally, not every week is like this. But it's a pretty wild number to think about. 4,700 copies in one week. Glad I didn't have to lick the stamps on all of those.
I've been going to JAOO for three years and over that time I've seen a remarkable change in atmosphere among a growing number of the attendees: Java has lost its aura of invincibility. It's no longer blasphemy to suggest that neither Java, J2EE, and the rebel frameworks are too complex for their own good. That it's both a fundamental, deep, and cultural problem where the solution is unlikely to come from within.
And, even more interestingly, that it's prudent to investigate alternatives for a large percentage of the applications that are currently being developed using these technologies. There's a growing sentiment that picking Java as a "corporate standard" is nonsensical. Dave Thomas recently phrased this beautifully in terms of sledgehammers and nuts recently:
Using the full might of a J2EE stack to write a small stand-alone application is using a sledgehammer to crack a nut. But I keep hearing the sound of nuts being pulverized as developers seem to think that using anything other than J2EE is somehow unprofessional.
In a telebriefing about Rails for the Burton Group yesterday, Dave Geary told an audience of hundreds of CxOs and team leaders from Fortune 500 companies that Java and its stacks are greatly overused for web development. And that his estimate would be that 70-80% of the applications currently being developed with these technologies would be better off using Ruby on Rails.
Dave Thomas, who also participated, noted that while Geary's numbers were probably right, but he was even more interested in the first 40%. That share of applications were he would consider it negligent to use the current Java-based stacks when something like Ruby on Rails could offer such a big advantage.
Regardless of the numbers, the writing is certainly on the wall: Java and its stacks are grossly over-serving the majority of web applications that are built today. It's not that it should never be used, just that it shouldn't be used nearly as often as it currently is.
Jason Hunter describes this in the terms of the innovator's dilemma. That the price of complexity in the Java world is far too high for the value it delivers in a large portion of applications:
Ruby on Rails today looks poised to eat Java's mindshare on the web tier. If not Rails, then something else. Empirically 10 years seems like the right
point. Java's viewed as solid and stable, mature enough for the most stodgy
business folks. That leaves a large soft underbelly for a technology intended
to help small teams (10 or fewer) who just want to make a site that's good
enough without paying a high price in mental effort.
With Bruce Tate's new book Beyond Java, this growing discontent with the status quo is given voice on paper. In its opening remarks, Tate describes the motivation for the book:
But I’ve come to recognize some real limitations in the Java language, and many of the frameworks that power it. For certain problems, Java just isn’t productive enoughfor me any more. I’ve experienced success with some alternatives. Though a language can last half a century to support legacy applications, I know no language can keep its leadership and its luster forever. Java's reign will end. It’s not a question of if, but when.
All these prominent voices have compounded to present a very different atmosphere today than the JAOO of 2003. I vividly remember debating Ruby in the enterprise with Paul Hammant of ThoughtWorks at that conference. While very sympathetic to the benefits of Ruby, he had a decidedly disillusioned opinion on anything going up against the Java (and C#) behemoths in the corporate world. Today, ThoughtWorks is working on commercial Ruby on Rails projects and looking for more.
Things are different today. It just requires enough hope and conviction that things can change. Talking to the other Dave Thomas at JAOO this year, I got the impression, though, that people who've been around for a long time doesn't quite believe it yet. Especially former Smalltalkers that saw the Java juggernaut crush everything in its path. Here's to hoping that they do pick it up again and help us show the world what we had all along.
In summary: Java and J2EE isn't going any where — neither should they. As an industry, we should merely realize that the sledgehammer is grossly over-used. Reserve its heavy-handed might to those cases where its truly needed. Whether that's 20 or 30% of the time that its currently being applied.
Christopher Petrilli voices a frequent misconception about Active Record, the ORM of Rails, in Least common denominator. The thinking goes that MySQL is holding us back from taking advantage of more advanced database features available in PostgreSQL, Oracle, and others. That if only MySQL was more clever, had more features, we would be embracing them with open arms. Wrong.
Active Record is opinionated software, just like the rest of Rails. This is a matter of opinion, not constraints. And the opinion goes as follows: I don't want my database to be clever! Keep those crayons firmly in place, please.
Unlike Christopher, I consider stored procedures and constraints vile and reckless destroyers of coherence. No, Mr. Database, you can not have my business logic. Your procedural ambitions will bear no fruit and you'll have to pry that logic from my dead, cold object-oriented hands.
Before the DBA-induced side of your brain explodes at that statement, please do read Martin Fowler's article on the difference between application and integration databases. And realize that my opinions are confined to dealing with application databases (and that doing integration through the database belongs in a time where Beverly Hills 90210 was a hit show on TV). Hopefully that calmed you down again.
In other words, I want a single layer of cleverness: My domain model. Object-orientation is all about encapsulating clever. Letting it sieve half ways through to the database is a terrible violation of those fine intentions. And I want no part of it.
All that being said: Whatever floats your boat. Active Record is surprisingly forgiving of your transgressions if you choose to hang out at the Peach Pit. As long as you're not banking your savings on a hope we'll change our ways once MySQL "grows up" and adds all these Enterprise Features to become something bigger and better than a "toy project". You'll die poor, then, I tell you.
UPDATE: Alex Bunardzic has a great follow-up entitled Should Database Manage The Meaning? — spot on.
Tomorrow I'll be delivering a double-session Ruby on Rails cocktail for the JAOO crowd, which consists mainly of Java and .NET developers. It's going to be an interesting audience to present in front. First session is going to be a live demo and the second session we'll be answering such marvelous questions as "But does it scale?". I'll be back Tuesday morning.
Chad Fowler has announced that RubyGems, the defacto packaging standard for Ruby, has served over one million packages. That's amazing. RubyGems has surely lived up to its promise of making the installation and maintenance of libraries, frameworks, and applications a painless experience. Whenever I'm drawn back into the dark world of a three-step setup.rb, I shudder. We all have to start somewhere, but I'm thrilled that we don't have to stay there.
Equally fantastic is the fact that almost half the gems served are from Rails. The main Rails package alone has been downloaded through RubyGems 110,243 times at the time of writing. Combined with the tgz downloads, that puts Rails at almost 130K downloads. Not too shabby for a 1-year old.
But in all this cherry go happy, I'm still not an entirely happy man. See, RubyGems is still not part of the core Ruby distribution. I still can't just type "gem install rails" on a fresh Ruby installation and expect it to work. That makes me sad, as Shugo would say.
Thankfully, it looks like its finally going to happen. If not for the imminent Ruby 1.8.3 release, then for the soon-following 1.8.4. Can't wait to cut that step out of the How To Get On Rails message.
As the world transitions its infrastructure from proprietary to open source, we need a cultural transition to fit. One of those transitions is the exchange of base-level support from paid vendors to passionate volunteers. It's a trade-off where you often get better-than-before information, but have to give up your I-can-scream-at-you-because-I-pay privileges.
It seems obvious that you can't invoke the same instincts in a samaritan transaction as you would in a commercial transaction. Your leverage to retract your contract or complain to the manager has been reduced to all but nothing. The people you are asking for help have no external obligations to assist you.
In simpler terms, don't expect anyone to help you if you're acting like an ass. You just simply have to be nice. Ask with courtesy, grace, and a humble attitude. Don't crash the party slinging accusations about how its everyone's fault but your own. Unlike the commercial world, you have to at least act like a decent human being when you ask the open source community for help.
That doesn't mean you are to become a subservient subject of the open source priests. Just that you recognize the switch of context and the new balance of power. You want something that someone else has. Since you can't say please with dollar bills, try words. You'd be surprised how well and often they work ever better than green.
Did you get your RubyConf '05 registration in? Otherwise, you're probably out of luck. We've managed to more than triple the number of attendees over last year's turnout to 195. There's certainly no mistaking that Ruby is burning-red hot. San Diego will indeed be host to an exclusive gathering come October 14-16. Can't wait.
I lavishly predict that we'll see 800 people at RubyConf '06. Watch it happen.
While Microsoft may have gotten the ball rolling back in the day, they certainly can't keep up with it any more. At PDC they announced Atlas: The Ajax framework destined to put Microsoft back in the game. But surely they didn't put their sharp shooters on the target. Atlas is a late, verbose, buggy, and under-whelming stab at catching up to yesterday.
It's obviously "inspired" by script.aculo.us and Prototype, but fails to deliver even the work-arounds for their own browser that the dynamic duo has been showing them how for a long time.
Thomas Fuchs, author of script.aculo.us and Rails core member, has documented their feeble attempt to clone the two-line auto-completion control from Rails with 23-paged(!) tutorial for .NET (danger, word document). If it wasn't so funny, I'd be worried.
Sam Stephenson, author of Prototype and Rails core member, has a similar story about another slight inspiration.
Why go through the trouble of recreating these two de-facto standards for Ajax development when you could have been part of the originals? They're even under the MIT license, for crying out loud!
Every Rails-inspired framework under the sun have already joined up behind the path we set. Heck, even MonoRail for .NET is getting jiggy with Prototype and script.aculo.us.
So come on, Microsoft. How about scrapping those black'n'white and tilted copies and join the open source community in improving the real deal instead? Not even .NET developers deserve this cruel and unusual punishment :).
On the ladder of corporate acceptance, few achievements rank higher than to bestowed the honor of becoming a bullet point on the recruiting check list. Today, my friends, it happened in an application for a "IT Architect":
Should have ideally 5 years experience with all of the latest and greatest tools out there. The more the better. J2EE, struts, Ruby on Rails, Websphere, etc. Should have experience constructing Enterprise wide Java solutions from whitepapers.
This is so good that I have to repeat it: Should have experience constructing Enterprise wide Java solutions from whitepapers.
Rails has truly broken through the awareness barrier when its included as part of a job application that's the antithesis of everything Rails is about. Clueless recruiters of the world, I salute you!
(And good bless your soul if you choose to sell it for 120K/year + 15% bonus)
When I look around at most of the interesting web-based startups, it's striking how few are from Europe (let alone just outside the US). Considering my fanfare about small teams and superpowers yesterday, this seems like paradoxical. Europe affords its citizens an impressive social security net, which you should think would make people more willing to take a risk of doing it on their own. But its not, at least not in this space. Why?
More concretely, let's look at the technology adoption. Why does France just have of 5 people working professionally with Rails, Germany 13, while the US have 130+? Is there really a notion of "old Europe" when it comes to innovation and the web?
As just one Dane with one set of opinions, let me give you my half-baked hypothesis: We have it all too cozy. There's not a lot of incentive to "get out of the ghetto" when the governmental care is so good. It's too easy to remain complacent in a stable job at a stable company that's not your own. Europeans simply lack the motivation to reach higher for themselves.
So it doesn't help much that the requirement for capital expenditure is plummeting when the primary driver of web startups is passion. Europe needs to wake up from the haze, ignite the passion, and make it more desirable to reach for the stars.
(Yes, yes, I know that it's not all Europeans who are suffering from slumber — I'm one of them, after all)
Mena from Six Apart deserves a lot of credit for taking a stab at defending big in a time where small is the new black. That being said, I'm less fazed by the particulars of argument. But as much as the blogosphere would probably love a good ping-pong duke, I'll reserve my push back for the core underlying assumption: You need to be big to do big.
Never before in the history of the world — cue trumpets! — has the potential to do extraordinary things been this big for the smallest of teams. The reach of the net, the low/no-cost of infrastructure, and rise of fiercely-productive environments have empowered those with passion near superhuman strength in business, by last-century standards.
I would have thought Mena of all people would have recognized this. Which is why the insinuation that the entrepreneurs of the net face a choice between a life-style, small-potatoes business (where people sleep in the office and are uncountable to their customers) or signing up for a VC-powered 80+ troupe (that can really make an impact and escape tunnel vision) is so frustratingly disappointing.
What I really want to say is "don't buy it". Don't buy it if you're a customer. Don't buy it if you're an entrepreneur in the making. While the term New Economy rightfully so sunk by the weight of "make marginal losses up on volume" nonsense that it supported, we are living in a different economy.
It's no longer necessary to be big to do big. It's optional. Mena and crew chose to do so, but they had every opportunity to have done it differently.
So eBay picks up Skype for $2.6 billion, which is wild enough in itself. But even more exciting is that Malthe is riding that windfall as head of design with equity. I've never known someone personally that had a share in such an incredible buyout. Many congratulations to the Skype team, but especially to Malthe. A fellow Dane and friend.
Now where's my 371 P/E evaluation...
Jason has announced the table of contents for our forthcoming book. Coming as little surprise, it'll be on the Getting Real approach that we've been talking about for a while now. But get your expectations straight before diving in. This is not a methodology or even much of a process.
Getting Real is merely a set of guiding stories, values, and thoughts on software and business development. It's an attempt to cram a lot of short essays of advice into a big pot that'll hopefully convey a somewhat coherent image of how, why, and when we do things at 37signals.
In short, it's for holistic managers of tomorrow's gazelle sprinters in the new economy who aims to attain shoutability, best-practice patterns, and value-enhancing B2C leaps.
In the wake of open source, traditional hiring practices seem like an unnecessarily risky way to hire new employees. Especially for small teams where each hire can make it or break it. Why bet the composure of your collective on abstract indicators, hearsay, and a biased bio?
I remember my last interview a few years back for a technical position. I was hired on a shiny CV concocted on own, a few emails back and forth, and a one-hour interview. That's it.
That bothered me even back then. Especially because I kept hearing of that process as the norm. And the effects of it was painfully clear. It's a lot easier to hire someone than to fire them, so most companies would just keep the outcome of their crap shot. Regardless of whether they rolled snake eyes or boxcars.
There had to be a better way. And of course, now there is. Open source is a golden gift to hiring process of technical people. It reduces the risk enourmously by allowing you to sample candidates over a much longer period of time using all the right variables:
- Quality of work: Many programmers can talk the talk, but can't walk the walk in any direction I would be interested in tagging along for. With open source, you get the nitty-gritty specifics of the programming skills and practices exposed in high defintion. Contrast with the black and white distorted image from playing "how to build a linked list" at a whiteboard.
- Fit of culture: Programing is all about decisions. Lots and lots of them. Decisions are guided by your cultural vantage point. Your values and ideals. It's possible to reverse-engineer a lot of cultural substance by backtracing from specific decisions made in coding, testing, and community arguments. If there's no cultural fit, every decision will be a struggle.
- Assesment of passion: By definition, involvement in open source requries at least some passion. Otherwise why would you forgo laying on the beach, on the couch, or in your bed all those hours spent crouched in front of your screen? But it can also be more specific and along with the cultural fit, give you an indication of what it is that really makes a person tick.
- Capability for completion: Also known as "gets stuff done" and perhaps one of the most important qualities in a programmer. All the smarts, proper cultural leanings, and passion doesn't amount to valuable software if you can't get stuff done. And lots of programmers, unfortunately, can't. So look for the zeal to ship, get it out the door, make the pragmatic trade offs at the finish line. Open source offers a world of options to both deliver and linger.
- Degree of humanity: Working with someone over a long period of time, during both stress and relaxation, highs and lows, allows you to know someone as a human. And filter out the stereotypical geeks with no manners or social skills.
This could also have been called People I Wouldn't Hire, Part II (revist part I for a flame fest). I can't imagine hiring someone that I didn't know through open source. I would consider it irresponsible to endanger the composition of 37signals by bringing someone on in the same manner I have personally been hired a good number of times.
Which is of course also why we hired Jamis Buck at the beginning of the year. Because I was in awe of his rating on the five qualities listed above by following his releases and his participation in the Ruby community.
Who cared about his GPA (or if he even went to college)? Or that he lived in Provo, Utah? Or how many years of experience he had programming? We didn't. It's simply unnecessary to rely on secondary factors when the work is available to extract values for the five variables listed above.
Open source gives companies a way out of the crap shot. A competitive advantage in picking winners with a much higher rate of success than the guessing, interpolation, and charade of old.
At the same time, open source allows programmers a way to route around dressing up for a meeting with the bank in your Sunday suit. Stop optimizing the secondary factors and focus on what it's all supposed to be about: the craftsmanship.
I had a chat with Peter Mønnike from newz.dk yesterday about winning the Best Hacker award, the what and why of Ruby on Rails, future plans, and more. Today, this thirty-something minute conversation is available as an MP3 (or OGG) as part of the newz.dk podcast series. It's all in Danish, though.
the Danish Computerworld features a full-page portrait of yours truly on page 23 today. It tells the story of how I started out with gaming journalism, but left for web development when I got involved with 37signals.
It's also a story of "love it or leave it". How I fell in love with web development in Ruby and how that lead to Rails. I picked up this monicker from Chad Fowler's new excellent book My Job Went To India (And All I Got Was This Lousy Book). He writes about his own transition from music to programming:
Looking back on it, I was addicted, but in a good way. My drive to create had been ignited in much the same way that it had when I started writing classical music or playing improvisational jazz. I was obsessed with learning anything and everything I could. I wasn’t in this for a new career. In fact, many of my musician friends thought of it as an irresponsible distraction from my actual career. I was in it because I couldn’t not be.
That's how it becomes all worth it. The long nights, the single-track focus, and eyes on the work itself as the prize. And Chad's book codifies a lot of the techniques I instinctually followed to be at whatever position I am in today. You really should read it.
Regarding the Computerworld article, I can't distribute the PDF and they don't have the story up on their online version. So that'll have to be a paper pick-up to read.
Katrina has wrecked horrible death and disaster. 37signals wants to make a contribution alongside the readers of Signal vs Noise. We're matching $5,000 in donations from the readers of the blog. Raising funds online can indeed be for more than political campaigns or server space.
Despite my personal departure from PHP, I still have the gravest respect for Rasmus Lerdorf, his accomplishments, and views on immediacy. Speaking about REST vs SOAP, Rasmus offers this compelling comparison:
I still much prefer the REST services out there. SOAP always reminds me of being stuck behind the guy in a hat driving a Lincoln Towncar. You eventually get to where you want to go, but the journey is painful. With REST you can just toss your query into your browser and have a look at the returned XML. SOAP starts to make more sense when the queries you are sending get more complex than just tossing a couple of keywords to a search service and setting a couple of flags. But don't even try to read the SOAP spec. If you managed to fight your way through that spec already, try the new WSDL 2.0 Draft Spec. This is the sort of stuff that makes my brain hurt.
There is a time and day for most solutions, but Rasmus paints a great picture on why REST shares many of the great qualities that made HTML flourish. Immediacy should be a prime directive for any standard and platform that seeks wide adoption. Rasmus is the king of immediacy.
Nathan tells us that he'll be at EuroOSCON talking about Scaling, Securing and Deploying PHP. I hope I get a chance to press his hand and say "goddag".