All the signals have been crunching for past few days wrapping up our Next Big Thing. So what is it? We've been struggling with a succinct way to answer that question for a while, but one angle is to define it off something you already know.
Backpack is Basecamp for your life. It's the product I've longed for when I used Instiki as a personal wiki. It's the product I tried to create through a mesh of outlines, email inboxes, post-it notes, The Brain, and a gazillion other systems under the sun. It's a Get Your Shit Together And Keep It So kind of system.
But at the same time it's not limited to or just about productivity, such as The System in a Getting Things Done kind of way. Which is of course what's making it a bit harder to explain. This is really one of those things were words are poor substitutes for experience, which is why the marketing site is all about examples.
All the people we've been demoing Backpack to got it as soon as they started seeing how we used it. So examples, examples, examples. That's what you'll see when the marketing site launches next week.
Until then, you can either hit refresh in your mailbox an unhealthy number of times per hour waiting for one of those golden tickets we'll be distributing, or you can check out the Backpack Manifesto that Jason wrote up.
It's almost here.
For as long as I've been dabbling in programming, O'Reilly has been an institution in that good, authority-inducing sense of the word. Thus, I'm incredibly happy to have them on board not only with the work we're doing at 37signals (Marc Hedlund is the current guest author at SvN, for example), but also behind Ruby on Rails in such a significant way.
They're doing two Rails books of their own and distributing two more from the Pragmatic Bookshelf. Rael Dornfest, their CTO, is programming away on an upcoming application using Rails (and I've been as lucky as to help guide him through that on AIM).
And I'm really excited about how much Rails is going to be a part of OSCON in August. I interviewed with Nathan Torkington not too long ago about the keynote and it seems like he's getting it like no other:
Ruby on Rails is astounding. Using it is like watching a kung-fu movie, where a dozen bad-ass frameworks prepare to beat up the little newcomer only to be handed their asses in a variety of imaginative ways. I've got David Heinemeier Hansson giving a session, tutorial, and keynote. That's how much I love "convention over configuration" and the other philosophies behind Rails. Rails shows us a very interesting future for web applications, and is a great example of innovation from within the open source community.
Flatter will get you anywhere. Especially when you're the content coordinator of OSCON, as Nathan is, and responsible for shepherding a power-house of Ruby developers onto a super track for this year's conference.
Add to that, Tim O'Reilly himself picked up on another Rails philosophy the other day with Frameworks are Extractions:
For example, basecamp wasn't built on top of Ruby on Rails. Rather, Ruby on Rails was extracted from basecamp. This approach seems obvious and commonsense — but hardly common in this era of heavy web services standards-ware designed by technical committees far in advance of actual implementation.
So before I break into song, I'd like to wrap up the lovefest by simple saying: Thanks, O'Reilly and friends!
So I've upgraded to the latest and greatest during my trip to Chicago, which means that I now have the following items for sale:
- Powerbook 17": 1.5 Ghz / 1GB RAM / 80GB HD / US keyboard / 6 months warranty left.
Asking: 16.000 DKR.
- iPod Mini: 4GB / Silver / 6 months warranty left.
Asking: 1.000 DKR. SOLD!
Both are in good condition and great machines. Write me at email@example.com (Danes / Malmø residents only).
Ben Curtis is concerned about the "significant changes happening" in Rails and how to cope with keeping up. We hear you, Ben. That is why we've been striving hard to keep new releases after 0.9 (which did require significant) as gentle an upgrade as possible.
The release log documents this by showing just how little change you've had to make to your application over the last four months to keep it running. The next release (0.11.2) promises once more to be an effortless upgrade despite the huge mass of new features, fixes, and tweaks.
Regarding the youth of Rails, you are indeed correct that in calendar time we're fairly freshly backed (9 months, just in time for delivery). But do consider the following facts in your evaluation of Rails' infancy:
- Although not released until the 24th of July 2004, Rails has been in development since the Basecamp project started in mid/late 2003. During that time it grew under the real-world constraints of a an application first in development then live
- Rails has since its release been used in hundreds if not thousands of applications of varying size
- We have more than a hundred contributors who actually have a patch live in the source
- The framework is stable enough than no less than four books are being written about it
Adoption, patches, and usage are certainly not the only qualifiers for neither framework fit nor "maturity". If so, all should be flooking in eager joy to projects like Struts. But they give some indication that perhaps calendar time is not the best, or at least only, way to gauge that elusive "maturity" idea (see more on my thoughts on maturity).
All this is especially interesting information when comparing Rails to maintaining a framework of your own. It is indeed a hard choice to exchange the complete flexibitlity of your own creation with the relative unknows of a community effort like Rails. While Rails is by no means billing itself as a short stop for "maturity" and stability (stasis are to be had in many other projects), though, it's still a big step up from having to do everything yourself.
We've had many developers echo exactly the opening sentiment you bring of "...a lot of the grunt work with building web applications goes away". This is true not only for features, but naturally also for the smaller things like a just right API or fewer bugs. In short, it makes sense to be part of a community where you can leverage the work of others and contribute back your own. Which is exactly what all of these many, many contributors have done over the recent months.
In closing, you're almost there anyway! A big step for many others coming over from PHP is the use of the Model-View-Control pattern, object-relational mapping, and many of the other patterns and approaches that may appear foreign to a lot of PHP developers. Thus, your mind is already in the accepting state. I encourage you to execute and come on over.
This reworked message was brought to you by the No-flames Committee for a Kinder Rails Face after reconsidering the gall-inspired wordings of Rails infancy but home-grown dish solid
For all the flak I've fired at the old boys doing J2EE, it at least appears that they got one lesson down that escapes many PHP programmers I've had words with. Ben Curtis demonstrates this disconnect exceedingly well as he labels Rails to be in its infancy:
Finally, there is youth. Rails is still in its infancy. While that’s a great opportunity for getting in there and being able to make contributions to the core product (I have more ideas than I do time), it’s not so great when you have to do deal with significant changes happening to your framework.
This is a charge I would expect to hear from someone flaunting the use of "industry standards", such as Struts on Hibernate or whatever the flavor. But get this, Ben Curtis is comparing Rails to a home-grown soup of hack'a'heel with a dash of ADODB, spiced with some unpolished generators, and then he's "...a little hesitant to use something at version 0.11.1".
Woah?! There's a contradiction if I ever saw one. So Rails is in its infancy with 9 months of rapid improvement by hundreds of contributors, used across hundreds (or thousands?) of applications of various size. But the home-grown dish is the pillar of stability and vintage quality?
Please. Don't be silly now. Your arguments of inertia and a sense of investment might have appeared silly (read up on sunk cost), but at least they were beliveable.
TextDrive is pioneering a new frontier for web hosting. Gone are the days where web hosts where merely a slice on a shared machine and a "good luck!". TextDrive has evolved the web hosting business into an application and framework hosting business.
This is particularly relevant for Rails as its the framework of choice for TextDrive. And they just upped the dedication another notch as they took on Marten Veldthuis:
Rails savant Marten Veldthuis is coming on as a TextDrive staffer. While being one of developer partners for some time and helping out with Rails support issues, he’s officially coming on part-time (he is still in school you know) to develop best practices for Rails development and deployment, write and curate Rails chapters in Manuals and to continue helping in the support system.
I'm continuously proud to be affiliated with TextDrive (they donate 50% of the profits on Rails' plans to further Rails development). They get it and their plans for the future is incredibly inspiring. From their uptake of lighttpd to their home-growned applications such as TextPanel.
Congratulations, Jason, Dean, and the rest of the crew. The whole Rails world will be hosting with you guys in no time. This is the place to be if you're getting into Rails. Join the community.
Reboot has been an institution in the Danish internet scene since I had my first job in the business. And just like my own career during that time, Reboot has bounced back and forth between different roles. From the "internet businesses' day off" at the peak of the dotcom bubble to the focused "meetup for the practical visionaries" that its billed as today.
The 7th incarnation is happening on June 10th and 11th. And it looks like it'll be a smashing show. 37signals will be featuring both myself and Jason Fried on the speakers list alongside Douglas Bowman, Jason Calacanis, Cory Doctorow, Robert Scoble, Doc Searls, Jimbo Wales, David Weinberger, and many more.
And it'll be a great weekend to be in Copenhagen. The Umbraco guys are doing a get-together, we'll have a Rails gee-ohh-good-time too. And its looking like Building of Basecamp will make its premiere out side of the States on the day before Reboot (June 9th).
So. You should come. Really. Copenhagen is beautiful in the Summer. Reboot is a guaranteed good time with lots of learning, challenges, and a hotspot of interesting people.
It's even pretty darn cheap. Just 175 euros. To schmooze among "heroes" and "mavericks". Bargain deal.
I'm flying out for Building of Basecamp 5 in Chicago next week. The workshop sold out in a mere week, but there's still a chance to meet up and talk Rails, Ruby, and other good stuff. The Chicago Area Ruby Group has arranged a meeting on Saturday, April 23rd. Chad Fowler, Curt Hibbs, and others are joining the fun too.
So if you're in Chicago or the area around consider signup up. If you're into the whole nerds meeting to talk nerd about nerdy stuff. I know you are.
Part of the joy of seeing a new major release of OS X is the enviable speed increase that follows. Going from Jaguar to Panther, we got something along the lines of twice the user interface performance. Just by upgrading the OS.
Now it's time for another considerable boost with Tiger. My new 1.67ghz Powerbook is getting +50% on CPU and threading and +25% on the UI. That's just nice. You get more features, newer apps, cuter eye candy, and everything is smoother.
Since I seemed to have missed the opportunity to piss off a few Windows users in the back: Have you switched yet? (Pronounced with pointy finger and tall hat). Just kidding... kinda.
My co-authorship of Agile Web Development with Rails is no longer a mere postulation. It's fact. Cover fact in fact:
How about that. My two-foot name underneath that of one of my all-time favorite tech authors. Pinch that arm.
It's dawning on the big guys that perhaps things have gotten just a tad out of hand with the complexity in Kingdom of Enterprise. As makers of WebSphere and pushers of deep and tall J2EE stacks, Big Blue has certainly been more than willing to partake in chanting that the "complexity is good, complexity is billable" mantra of the upper consulting echelon.
So it's wonderful to see that they're waking up to find a world outside of the statically-typed and XML-ridden garden. The very same that has this perceived aura of being the only way to do Serious Business. First they jumped on PHP, now they woe to continue the look outside under the banner of Radical Simplification:
Application development using IBM programming models and tools is untenably complex. The Research Division's new Services and Software strategy includes a strong focus on radical simplification. Radical simplification was one of the featured topics at Paul Horn's recent Vision Conference. Over 70 people in IBM worldwide are currently participating in an effort to define the problem, and the scope of the solution, more precisely. Our effort will lead to recommendations to emphasize, grow or refocus selected existing Research projects, to start new projects, and to undertake other initiatives to promote a culture of simplicity. This talk will discuss some of the insights we have gained so far into different perceptions of complexity, the nature of complexity in IBM software, why complexity is a high-priority problem for IBM, and some of the directions being pursued inside and outside IBM to deal with complexity
What great news (decorated with my emphasis)! It certainly lifts hope that their embrace of PHP is merely part of a larger strategy to fight complexity and not just stop at where PHP does.
What's even more encouraging is that IBM'er Sam Ruby followed up with a presentation entitled Hello from the open source world!. It talks about how the open source approach is providing greater transparency and much lower complexity on a number of key areas (such as going from idea to patch on a major project).
He presents the concept of Zero Training to be essential to achieving simplicity. And I couldn't agree more. I'm constantly reminded and amazed at the power of this when I see new quality patches for Rails coming from people who just picked up the framework yesterday.
Ruby (the language) itself is also an intensely well-suited language for chasing Zero Training. Not only does it make the construction of domain-specific languages so easy that we use them all over, but it also puts them right it in hands of the application developer and leads to significant reductions in complexity and increase in learnability (gotta love those -ilities).
And lo and behold, what's on the last page of Sam's presentation? Worth Watching. Item number four from the top: Ruby on Rails.
Hey, Sam, there's no reason to stay on the sideline watching. We got plenty of room in our pool of Radical Simplification to let both you and the rest of IBM dip in. It's a party and a pursuit where everyone's invited.
I've been invited to deliver a keynote on Rails for O'Reilly's Open Source Convention in August. Fifteen minutes in front of some two thousand people. I've naturally accepted, but that's a pretty scary prospect considering my largest audience to date was the 60-80 people at RubyConf.
I'll be talking about "The Secrets Behind the Success of Ruby on Rails". Or at least that's the working title for the talk. I got past gate keeper Nathan Torkington talking about Less Software, Convention over Configuration, and stories along that tune, so those will be likely ingredients.
But man, I'm excited. It's a chance to knock off another of my 43 Things. With "See my name on the cover of a book" coming through with the Agile Web Development with Rails that I'm co-authoring with Dave Thomas, "Deliver a keynote on Rails to 500+ people" will be a very symbiotic next step.
Of course, I'm still also doing both a session and a tutorial on Rails at OSCON as well.
The rise of Rails has one story that's more important than any other. The story of blending. Blending mind, talent, and passion from widely different cultures across the entire complexity scale of software development.
It's a story about building a community consisting of seasoned J2EE developers responsible for making banks and the rest of the corporate world run on time. And at the same time inhabited by graphical designers pushing the envelope in look'n'feel who are just starting out in programming. And every single step in between.
That's remarkable. The J2EE guys would probably never have felt passion for doing Cold Fusion or PHP or any of the other technologies that normally appeals to designers turning into programming. And likewise, the designers would run screaming away if dumped in the backyard of J2EE. But Ruby on Rails is turning out to be that place in the middle capable of igniting excitement from both ends of the spectrum.
Why is that? I think part of the reason is that a lot of interesting properties around technology are universal in their appeal. Getting started quickly and feeling success early appeals to everyone (perhaps more critically to newcomers than veterans). Seeing the rise of beautiful coding structures arising from elegant syntax and the adherence to DRY (something that should be more appealing to the veterans as they've seen the consequences of the opposite). So what we're basically trying to achieve is the meeting of quick'n'dirty with slow-but-clean into quick'n'clean.
Now that the place in the middle exists, we're seeing the results of combining vast experience in enterprise systems with dedicated attention to look, feel, and eye candy. This is infecting both sides with the opposite concerns. The designers learn to appreciate abstraction through encapsulation and coherence much earlier than otherwise. The back-end programmers learn to appreciate and build consistent, accessible interfaces.
And Rails benefits enormously from the ideas and implementations steeming from both camps. From optimic locking strategies on the one side to Ajax visual effects on the other. The vision to address the full stack of web development makes ample room to include everyone.
See also ThoughtWorker and J2EE developer Obie's take on many of the same perspectives.
It's a family tradition to convene at the second of the Easter days. So is the tradition to stroll to the beach at the setting of the Sun. As is tradition, so was it this year. The light was as usual amazing and luckily I had my camera with me. And what a great moment to really put that 50mm lens to good use. My cousin:
...and 8 more shots at Flickr.
As a world of programmers is still processing an incredible amount of gall and spite generated over the rise of Ajax as a term (and some as a technology), let me step back to salute Jesse James Garrett for coining the term.
I must admit that when I first heard it, I too twitched for a second in displeasure of a new cap for an old hat. But as my lizard brain retracted, I recognized the brilliance in timing and the benefits of explanation.
Jesse James told me, told us, a story about the rise of a new approach (or technique, if you're still pessimistic). He gave the web a reference point wrapped in a catchy term that has been fantastically beneficial at creating awareness.
That's valuable. That's an important contribution. Disrespecting the story teller for such an offering reflects a narrow, harmful view of progress on a grander scale. In the aim to lift the industry higher, the stories are as important as the technology. The stories carry good ideas from the mighty high to the mighty far.
The resentment around the term Ajax reminds me of the recurrent rejection I've observed in some programmers around design patterns (less so in recent years, though). An instant rejection that a story can be valuable on its own. That if you know the tech before it received a catchy label, you're entitled to the smug sense of superiority as you berate the illiterate commons of how you were there before it was cool.
I can't stand it. Great ideas are ripe for better packaging. Let's honor the bards of our time as they carry, improve, and spread messages of improvement farther and further. The irrational rejection of stories is the hallmark of a world view that treasures enlightment only among the few.
There's a special magic to catch-all dismissals of new technology. Usually, they start out being fairly generic and vague enough to sorta pass by with enough waving and implied assumptions. But that only works for so long and soon the catch-all dismissal must retreat to higher ground seeking to be ever more generic, vague, and, of course, meaningless.
I'm sensing that "does it scale?" is experiencing the end of its run along this course. A general understanding that scalability is achievable with most modern web-development platforms has left a void for the role of quick dismissal. But what was lost on scalability is quickly recouped with the advent of... wait for it... Maturity!
Maturity is such a wonderful blank that your brain can readily fill with any property that fits for the moment without even being conscious about it. Hence, most everything can be attacked for lacking maturity. It's a great joker that fits in any hand of argument.
Its greatest fallacy is inherent in its close ties to absolute age. Unlike the growing of man, technological progress is less determined by the passing of time than it is the expendure of attention and determination. A focused burst energy, a large enough set of eyes, the right ideas can all be drivers of "maturity".
That is when maturity is played as meaning something more specific, like...
- Friendly (easy to get started with)
- Polite (reasonable reporting of mistakes)
- Dependable (free of critical run-time bugs)
According to these definitions, some projects remains immature years after their premiere, others achieve it in much shorter time.
So please, take the joker out of the deck and replace it with arguments of specificity and clarity.