Early detractors of the Rails approach with application skeletons and component generators dismissed the framework at large under reference to "code generation". The thinking went that all Rails was really doing was creating a boilerplate mess that might give a quick taste of productivity, but would rapidly turn into a sour soup of mud.
Like those wizards of yesteryear that would ask you a bunch of questions through multiple screens, generate a ton of code you didn't understand, and then leave you stranded when a bug arose or extensions were needed. Needless to say, no sane software developer would be interested in bringing those dinosaurs back from the grave.
So the argument almost played itself. Rails is all code generation, code generation is bad, therefore, Rails is bad. Only one problem: What Rails is doing with its generators lie far enough away from the horror stories of the past to go under the same name.
The problem is that the code-spewing wizards gave the whole field of code generation a bad name. That in and of itself is certainly a shame. There are a lot of good forms of code generation (see the excellent Code Generation in Action for examples). But I admit that the term is somewhat tainted and its not really representative to what we do in Rails anyway.
Enter Structure Generation. See what we do in Rails is a lot less about generating lines of code and a lot more about generating structure. Herding the programmer down the path of conventions. Creating the right directories, the right files, and calling them the right names. It's conventions on rails.
So it's a little bit more of an ego-wank than what might have been desired, but I can cope. LaMonica certainly did a good job at representing the spirit of my excitement in the conversation we had. And how can we mind this billing Ruby on Rails as "High Impact" and displaying quotes like "This is exactly how things like Linux got started".
Ruby on Rails is certainly making its way into the mainstream. Even Sun CEO Jonathan Schwartz dropped us some link love the other day.
Now to take it all up a notch with the bang of 1.0.
I spent three years at the Copenhagen Business School to largely acquire one skill: The ability to price something at its value, not cost, and feel damn good about it. It sounds trivial, but it can be the hardest thing. Russell Beattie gives you the guilt version:
Let me make an aside for a moment and say that I’m always fascinated by what I call “natural business people.” These are the folks that have absolutely no problem making money. If I buy something for $2, I have this vague sense of guilt when I turn around and try to sell it for $4, and even worse if I sell it for $6. It may be worth $6 now, but I know how much I bought it for and I feel bad. People like Bill Gates for example, don’t have this problem (remember the story of QDOS as the prototypical example).
The inability to price at value instead of cost is what separates nice (or niche) businesses from great businesses, what fizzles good ideas, and what turns would-be entrepreneurs into "starved artists".
But its also something that separates people at a moral level. People who charge at value are often labeled as cynical or price gaugers or downright inhuman. It creates a false split between "the compassionate" and "the cold business people". It's probably also one of the prime puzzles for economists: Why is this so hard for "normal people" to understand?
I won't attempt to pontificate on why, but I will say that the three years was well worth it. Not only as a way of conducting business, but as a way of developing projects and products (even living life, to be grand!). In some ways, I think its my most important skill and asset for programming. The ability to discern value and make calls based on it: Worth it?
This is naturally what attracts me to simple problems. What's the least amount of work I can do that ends up having big value? Before I've cleared all the simple problems of high value, it's just not for me to engage in solving hard problems. Too much risk, not enough ratio.
(Oh, and just to satisfy Russell: If you're not using Ruby on Rails for your start-up, it's going to fail. No buts, no discussion. Fail. Hear?)
So while I still consider the GWA to be pretty evil stuff, it's at least not double evil by intention. Product manager for the Google Web Accelerator, Othman Laraki, just wrote me with the scoop:
Turns out that what you noticed about "X-moz: prefetch" headers missing from requests was a bug from our side. After reading your post, we realized that one of our several types of preloads indeed does not issue the necessary headers. We started rolling out a fix last night and should be visible to all users by end of today.
That's great news! I did have a hard time figuring out why the team would pull the only guard we have against GWA out, so I'm happy to hear it wasn't intentional. Pretty nasty bug, but shit happens every where.
Now this naturally doesn't exonerate the vanilla evilness of the GWA concept, but its definitely a step in the right direction. And since I now have an email address and a handle on someone in the know at Google, I took the opportunity to fire off a bunch of questions about their motives and intentions. Othman willing, I'll post the answers here.
(Lest you think that we didn't try to contact Google before ripping them a new one, we did. I wrote the highest level contact I had and Jamis wrote directly to the GWA team. But Othman's email is the first response I've seen — and it came after my loud whining here)
So the Google Web Accelerator is back and twice as lethal as before. It no longer reports its pre-fetching intentions, so now you can't detect whether its either or. In other words, you can't block the fucker.
This time around, though, Rails is a lot better prepared. Not only does Rails ship with two different methods of easily creating POST actions without the drudgery of the manual form, but also makes it easy to guard actions against unsupported verbs.
If you want to be a real pretty momma's boy, you can use the new button_to, which just makes it easy to create a mini-form that'll submit to the chosen URL as POST. But that generates a real, visible form, which despite being subject to styling, is often not something that's easy to fit into an application design of your choice.
On top of making it easy to generate POST links and buttons, we've added easy guards to the controllers in form of verify. You can now very easily guard certain actions from being accessed by anything but posts. Example:
class WeblogController < ActionController::Base
verify :method => :post, :only => %w( delete update )
# a GET request will never gain access to me
There you have it. A complete package to Do The Right Thing And Look Pretty While You Do It. So that means that we should welcome our new Google Web Accelerator overlords with a cheer and a smile, right? Wrong!
The problem with the GWA is not that you can protect against it. It's not whether Rails makes it easy or not to do so. It's the fact that we know the Real Web doesn't behave uniformly like this. It's the fact that we know that the world of applications that exist with state-altering GETs out there is huge and not going to change tomorrow.
To willfully release an application that wrecks havoc, potentially wiping data left and right, is malicious. Especially when you consider the gains: Your web experience may or may not get a little bit faster. Are you kidding?! The sense of proportions, of gain vs risk, of price vs reward, is completely and utterly out of whack.
If Google doesn't retract and profess their sins. I will pull out the juggernaut of all arguments on public policy. Don't make me do it. I swear I will: Won't somebody please, please think of THE CHILDREN!
As t approaches zero, people will realize that many types of software are non-sensical in their generalized form. I believe the time has come to mark a date in the not too distant future for celebrating the death of the general-purpose content management system.
In many ways, I believe it was always a pipe dream. Sort of like the high-level components that the industry has always sought. Or model-driven architecture/CASE tools. I believe all these fantasies can be summarized in a correlation of price and delusion:
The more expensive it is to create fresh software, the more appealing the mirage of generalization will appear.
And I think we've already seen the rise of its replacements for smaller segments of generalities. The blog is a much more specialized, much better alternative for a large group of problems that where previously considered content management. The same for the wiki.
We need even more narrow tools. While it'll never reach zero, t is aiming enough in that direction to expose the fraud of ultimate generalization. So don't accept the label of content. Nobody produces content. People write reviews, people write news, people write articles, people exhibits photos.
Try to realize, there is no content.
"Sorry" can truly be the hardest word. That notwithstanding, I was disappointed to see Dave Winer's Scripting News update twice today. First update blasted Evan Williams of Odeo to smithereens, second retracted it all without a trace:
Contrast this to Russell Beattie's handling of the same situation today. First he blasts the Surfarama guys for nicking his idea(?) on RSS feeds for serialized content, then retracts his blast openly in the comments.
I came out empathizing more with Russell than before the entire incident, I came out empathizing less with Winer than after he had posted the original blast. I can certainly relate to knee-jerk reactions, which you later regret.
Paraphrasing from one of Jerry Weinberg's books on Quality Software Management: "It's not the incident, but how you deal with it that matters".
So I'm 26 today, eh. That's worryingly closer to thirty than it is to twenty. But still not so close that you can actually see thirty. That doesn't arrive before 28 or something. There is time.
We've just launched Writeboard integration for Basecamp, which means that all projects now have the option of associating Writeboards with them. This is interesting because it shows how the "app-less app" design allows us to reap the benefits of development thrice.
From a single code base, we've provided a stand-alone application at writeboard.com and decorated both Backpack and Basecamp with Writeboard-powered "features" integrated deeply into each of the applications. They even specialize Writeboard slightly differently by passing in UI configuration options.
Behind the scenes its all a simple REST-powered architecture following a simple observer pattern. Writeboard has the notion of folders, which can register themselves with a given writeboard as a URL. When the writeboard is updated, the system will ping each of these folder URLs with information about who made the edit and when. This allows Backpack and Basecamp, which both serve as folders in this setup, to provide writeboard indexes with up-to-date information — without doing expensive look-ups on each request.
Programming-wise, it's been trivial to implement. But functionally it's a big win and a great way for a small team like us to scale our suite of applications at near 1/3 of the cost.
Writeboard is the first of these app-less, or document/single-url, based applications we've done. But the same model is already slated to power a second application we have under development. Develop once, launch many times.
The beast has certainly taken on a life of its own. It seems like every day brings new, exciting announcements from all sorts of expected and unexpected corners. Here's a short recap of some of the latest developments:
- Professional training programs: Dave Thomas and Mike Clark just announced the Rails Studio under the new Pragmatic Studios umbrella. Big Nerd Ranch also announced a Rails training program a little while ago under the direction of Rails committer Marcel Molina.
- Ruby on Rails shows up in Wired: Tim O'Reilly and the rest of the O'Reilly family has been some of our strongest supporters since very early days. And Tim echoes the recommendation once again in his Tim's Radar segment in Wired.
- RubyConf draws in the big shots: On top of being totally sold out, RubyConf has managed to draw in a lot of big names, like Martin Fowler, Sam Ruby, Dave Thomas, and many others. It'll be one heck of a show next week in San Diego.
- Paul Graham funds lots of Rails' "startups": I spoke with Paul Graham at Web 2.0, after his appearance on a panel where he had already plugged Ruby multiple times, and learned that his new seed-funding venture were already backing a large number of Rails-powered ideas. Sehr cool.
Ruby on Rails has really arrived. There's so much going on, so many new opportunities popping up every day, and so many interesting people announcing Rails-related stuff left and right. I can't believe how far we've come in just a year.
After months of uncertain, I've finally secured my O-1 "Extraordinary Alien" Visa. After missing the H1B quota by a mere two days back in August, it's such a relief that it finally happened. I'm now legal to stay, work, and pay taxes in the US of A for 3 years. With the possibility of infinite 1-year extensions.
So for at least the next year, I'll be residing in Chicago, and thereby joining Jason and Ryan at the company "headquarters". Marianne is planned to start a study in Psychology for the Spring semester, probably at Loyola. We'll be living in the Bucktown area renting Jason's old place.
Oh boy, oh boy.
But all this wouldn't have happened if it wasn't for the tremendous help and good timing I've enjoyed in the process. The publication of the book, the Best Hacker award, letters of recommendation from Tim O'Reilly, Martin Fowler, Sam Ruby, Bruce Perens, Jeffrey Zeldman, Richard Bird, and my old Computer Science professor Uffe Kofoed. It all played a vital part of demonstrating to the INS in Nebraska that I qualified as an "extraordinary individual". Thank you all so much!
And of course thanks to Susan C. Ellison from Fragomen, our lawyer. She put the application together, wrote a cover letter so endorsing my ears were burning, and always answered our questions fast and comprehensively. Warm recommendation extended.
Also a special thanks to O'Reilly Media. I've bugged more than a handful of people there to get everything from conference fliers with my name on to letters of peer review. Rael Dornfest, Nathan Torkington, and all the rest of you. Thanks!
So. With that acceptance speech out of the way, I look very much forward to moving over in November.
Writeboard is live. It's an app-less app for collaborating on text with version control, difference tracking, and commenting. You can use it as a stand-alone application or as a feature of Backpack. It's entirely free and its not even beta.
It's also a whole lot less software than many people probably expected. Which of course is nothing new. Ever since we introduced Basecamp, all our subsequent applications have been billed as too simple and too little by a choir of pundits at their launch. So I think Writeboard is in great company with the likes of Ta-da List and Backpack.
I have no doubts that our next couple of applications will receive the same mixed appraisals. And that's a good thing, in my book. We've never been in the business of wowing people with an amazing wealth of features. And that's certainly not a secret. The company website proudly proclaims: "Simple for sale (and for free)".
So while we'll continue to proudly underwhelm people looking for more software and more features. At the same time, we'll be equally proud to please those who find the less we do, just enough to get their work done better today than yesterday.
Now take the tour, get inspiration for use, and then do start your first Writeboard today.