June 24, 13:23 | Comments (8)
Paul from infrared must has surely had a terrible experience in the past jumping on some flavor of the month, but then being horribly burned when that flavor lost taste and he was stuck without the flexibility to solve the problems at hand.
Buy who hasn't? Most of us have experienced jumping on the wrong bandwagon only to be end up in a dead-end situation and the feeling of being abandoned. Experiences like that leaves scars.
We deal with those scars by building survival rules like "don't trust something until it's been around for years (or you will be burned again)". In some regards these survival rules help us navigate the world at a greater pace because they can serve as filters for what should be deserving.
Survival rules are rarely something we think of consciously — unless provoked. And it certainly seems like Paul was provoked:
If I switched to using the Next Big Thing, only to find that the thing we need to do to keep Client X happy is actually impossible or fraught with bugs, we're fucked. You need total flexibility, because no matter how smart they think they are, the designers of any web application framework can never have thought of everything.
In other words, he's tempted to play with new technology, but the survival rule is telling him not to — don't mess with something that works, the promises are false (like the last time). The source of this provocation is outlined in the introduction:
A lot of people (especially people who submit stories to Slashdot) are going doolally about Ruby on Rails, the Next Big Thing in web application development. You can't read a blog without someone going on about it like it's the second coming. The end of PHP/J2EE/mod_perl/python/blah! Everything before it is shit! It makes everything so easy! Why on earth are you using anything else, ever, at all? You web development savages!
Leaving aside the internal amplification of the original messages that Paul applies in his understanding (that's an interesting topic for another time), I believe what he's hearing is the voice of a lot of people violating his survival rule around adopting new technology.
That's a challenge, which can be dealt with either by reexamining the survival rule (and asking whether it's helpful to apply it in this case or not) or by distancing himself from the source of the challenge, so as to render it invalid (it doesn't apply to me).
Paul picked the latter and uses a "there are two kind of people" dichotomy to describe why the challenge doesn't apply to him (and thus why the survival rule can still work). The split is centered around "...hype about whatever the Latest Cool Thing is for building pointless web sites and the needs of people like myself, who build web applications professionally".
We have the Bad Technologists (using Latest Cool for pointless web sites):
I wonder how many people are getting hold of RoR, understanding it a bit, using it to write a piss-poor CMS for their weblog or a widget engine, and then never using it again.
These people obviously don't care about the important issues that the Good Technologists follow:
I wonder how many people like me, who rely on the tools they use to be mature, stable and (above all) familiar, in order to Get Stuff Done, when there's never enough hours in the day and the site's going live tomorrow or they pull the contract.
With the world divided into good and bad, it's not hard to pick the side of the good. And thus, it's safe to render the conservative, survival rule-preserving conclusion:
Meanwhile, I stick to mod_perl and Stuff That Works because the track record gives me faith in its persistence. I'm not playing at this, it's my livelihood, so jumping horses onto an unknown runner isn't a risk I feel I should take.
What do I make of this? First of all, that it's not really or at all about Rails. This is a fundamental defense mechanism that any new technology, development approach, and way of thinking will encounter. So in that sense, I consider it a sign of good things when we force survival rules to be invoked (and subsequently examined). That's definitely the first step.
The second step is of course to figure out how to help people make more informed decisions, so they have better grounds on which to decide whether the survival rule is helping or hurting them.
I surely didn't pick the right approach in one instance that Paul highlights, but at least I realized and attempted to revert that approach the day after (Paul doesn't link to that).
So. I won't try to convince Paul with my own words just now. Instead, I'll let Mike Clark attempt to address the issue of flexibility in the Rails world. He has a wonderful piece called Dumpster-Diving Rails, here's a snippet:
I'd also encourage you to study the Rails code just for fun. There's a lot of incredibly cool stuff going on in there, and just reading the code will make you a better Ruby programmer. You shouldn't be afraid to take a peek; it's good code. Being able to read, tweak, and run the Rails code with ease drastically lowers the price of participation.
In much the same way that the web took off because of "View Source", Rails is taking off because it lowers the barrier to entry and holds nothing back.
(If you want to read more about survival rules, I can recommend the writings of Jerry Weinberg — the Quality Software Management series and the Secrets of Consulting series deals with them at length)
June 23, 15:43 | Comments (5)
One of the hallmarks of disruptive technologies is that they eat their way up through the chain of capabilities over time. With the rise of Ajax, DHTML techniques like drag'n'drop are becoming a lot more useful. And together, they're taking the web application up another step on that chain of capabilities. The gab to mimicking the rich desktop applications is growing ever more narrow.
Point in case: We just introduced drag'n'drop for reordering of list items and notes in Backpack. It freaking rocks. Yes, everything old is new again. But that's the point. OmniOutliner still has a much richer environment for manipulating lists, but I already valued the sharing and accessibility of the content more. Taking one step closer to the rich feel is going to do the same of a lot more people.
But the real reason this is a big deal is because the rocket science department has been put on leave. With the script.aculo.us Javascript library by Thomas Fuchs, that builds on the great Prototype library from Sam Stephenson, it's silly easy to add advanced drag'n'drop to your Rails (or any) application.
By taking the complexity out of the ordeal, it becomes more accessible, less of a project, and more something you just do. Rails initial support for Ajax through Prototype had the same characteristics. Make it as easy as not to. And thus, Backpack was filled to the brim with Ajaxing goodies. Something it certainly wouldn't have been if we were doing it old skool style with loads of custom Javascript build by experts.
So we're getting closer every day. With the impending, upcoming release of Rails we'll include all this stuff right in the box. Rails is going to push the frontier of integration once again. Everything needed to build web applications like Backpack. Slick effects, cool interaction, and a solid MVC stack without having to strap on the professor hat.
June 06, 23:50 | Comments (8)
How Ruby on Rails used equal parts technology, necessity, and passion to create a larger-than-life buzz in web-application development. Including why developers with a cause are more productive.
That's the pitch for my 18:30 talk on Friday at Reboot. It's going to be following Jason's How to Make Big Things Happen with Small Teams talk. And preface dinner. Quite the challenge following that and fighting a survival instinct to eat.
June 01, 14:41 | Comments (15)
Holy smoly! The Agile Web Development with Rails book as sold more than 1,000 copies in just the first week available. And it's not even finished! Thank all of you who bought the book (and even more if you picked up the combo-pack). It's great to see that releasing the unpolished version now, with the promise of a clean version later, was accepted so broadly.
It's also a great sign of encouragement for the ecosystem of paid content around Rails. Books are certainly the primary outlet for that, but I hope we'll soon see other sources emerge, too. I've been pimping various ideas left and right on that.
So once again, thanks everybody. Rails is in stronger shape than ever and the race towards 1.0 is surely in.
May 26, 20:32 | Comments (21)
Dave has released the Agile Web Development with Rails for beta consumption. The demand within the first hour has already been huge, so if your download takes a little longer than the 5 minutes, that's why. I'm really proud to see this happen. Many thanks to Dave and the people who've contributed. End of brief transmission from Brazil.
May 19, 20:32 | Comments (147)
It's been interesting to watch the market lag to satisfy the huge demand for more Rails documentation. Once the publishers recognize there's a market, it easily takes 6 months (or longer!) before the final book is ready in the stores. That's a terribly long wait and an abrupt switch from "no books" to "plenty of books". It's bad for users that want better documentation today and its bad for publishers that wants to sell that documentation.
Now that I actually have some say in the production of one of these books, I've been pushing Dave Thomas to recognize this. And lo and behold, I've been making progress. Basically, the content for Agile Web Development with Rails is all done. Some 500+ pages.
But of course that doesn't mean that the book is done. There's editing, second readings, typesetting, printing, and more. All of this post production work makes a release around August feasible. AUGUST?!? That was what I was thinking. When you're used to the web, the book publishing business can appear utterly arcane.
So. Instead of letting a ton of high quality, really important documentation sit on the shelf for two and a half months while the machinery of publishing is ready to deliver, we'll be trying to get the book out in digital form for those that really want it. Basically, we'll be playing release early, release often with the book while it undergoes the last mile.
And I think a lot of people are interested in making that trade. Getting content early, recognizing it's a beta release that may have spelling mistakes or even a few bugs. Especially so when the choice is between no book and a 90% done book. Then getting the final tome when that's done too.
Dave has all the common reservations to that as a publisher, naturally. Will people look down upon the unfinished work? Will they pirate it like mad? Will the final product be uninteresting when it finally arrives? I don't think so. Rails is still enough of "labour of love" kind of thing for the people into it that I think they're smart enough to recognize that this model only works if those fears are brought to shame.
Let's blaze the trail with this one. Show publishers that we want the quality writers that they all have lured in to start delivering according to the open source model. There are so many interesting topics that could use a flow of high quality, commercially-backed documentation production today. Not 6 months from now.
May 19, 0:41 | Comments (2)
The first Building of Basecamp to leave the States is heading for its second home of Copenhagen. While that's a great thing in itself, it's even better that we're running in pairs with Reboot. The Copenhagen BoB is on the 9th on June. Reboot starts on the 10th. So the city will already be filled with interesting people. You really have no excuse not to come.
We even have a spiffy new site for the workshop in honor of taking it to Europe after much and heavy demand. The last workshop sold out in just one week. I wouldn't be putting off my registration, if I were you ;)
May 18, 14:05 | Comments (3)
It's months away still, but preparations are called such because they are made in advance, so that's exactly what I did today. Completed the speaker registrations, book the flight (17 hour trip total, uagh!). I'll be flying into Portland on the eve of the 29th of July. That means a weekend to hack and have fun in Portland before the show starts the following Monday.
And what a show. I'll be doing a keynote, a session talk, and a tutorial to be sure to fill the days. You should really come. It's going to be a fantastic show for Ruby. We'll have Matz, Dave Thomas, _why, and most of the Rails core group too.
With enough perseverance, the book will be hot off the press too. I'm excited.
May 18, 1:33 | Comments (21)
I think that's the coolest thing I've ever been called. Or at least as cool as fearless leader. Maybe they can even co-exist. I'm seeing images. See mastermind is guy in nice chair with a cat. Amiable is the friendly smile. Dutch is a hat of some sorts. Then fearless must be patch across one eye and then leader can be a fist on the table. Are you seeing it yet?
Oh. You're missing the context. Yes, yes. Of course. Jonathan Boutelle from the SiliconValleyWatcher did a write-up of the recent Ajax Summit that O'Reilly and Adaptive Path threw. Here's the bit about the Dutch masterminding:
Technical frameworks for making AJAX development are cropping up like mushrooms after a rainstorm. Of the many developments, the most compelling is clearly Ruby on Rails. Rails is a rapid web application API that already has remarkable momentum. David Heinemeier Hansson, the amiable Dutch mastermind behind the rails framework, gave a nice overview of how Ruby on Rails makes AJAX websites easy to develop.
I've been meaning to write more about that Summit. And I will. Soon. Lots of great things to come of it. In a few fragmented sentences: "readers don't care about the last 20%", "could flash become relevant again?", "(at least) two flavors of Ajax", "making ajax and mobile gel". If I shouldn't get around to actually write any of these, you should have enough to make up your own story.
Oh, by the way, I'm Danish. Not Dutch. But now that you had to mistake my nationality, you could have done worse, Jonathan. You could have called me German. Or Swedish :).
UPDATE: Jason is a mastermind too! "Jason Fried has been a mastermind behind the new direction...". Too funny. He's not getting Dutch, though. That's mine.
May 16, 16:02 | Comments (12)
I'll be undertaking another twenty hours of traveling next Monday to get Mary and myself from Copenhagen to Porto Alegre, Brazil. That'll give us a week's worth of vacation time before the International Free Software Forum starts. I think I did mention that I'll be speaking about Rails there. Thanks to Pablo Lorenzzoni for making that happen.
Anyway, we're Brazilian newbies, so we're looking for advice. Taking outset from the Coral Tower Hotel where should we go? What to see? Where to eat? As many suggestions as you can come up with.
Also, stories of how the world works in Rio and San Paulo are not exactly calming our minds. Is Porto Alegre also a place where you don't want to be caught in a bad neighborhood without armed guards? If so, where would those neighborhoods be, such that we can avoid them. I've promised Jason not to get killed :)
May 08, 20:40 | Comments (17)
San Francisco, baby. A small gang of Railers are getting together at the Ireland's 32 tonight at 8pm. We're going to talk lots of Ruby, Rails, and more. It's open. Write a note in the comments if you're coming.
May 07, 17:11 | Comments (16)
As I'm making the trip from Copenhagen to Chicago (and then on to San Francisco), I thought it prudent to take an airborne view of the latest bruhaha over Google's Accelerator. Yes, specifications such as the HTTP are important. Yes, POSTs are a better way of modifying data than GETs. We should all move in that direction. Backpack made the switch yesterday.
That being said, there's a reason why GETs was used in the first place. Just like tables were mis/used for styling, people will route around specs that doesn't allow them to do what they need to do. HTML is not a particularly friendly place to implement a RESTful interface, so people find other ways. Bend the rules to Get Stuff Done.
But standards improve. The table-based design have fallen from grace due to the strong support of CSS now available. When there's a better way available, most people will eventually follow it. But the switch doesn't happen over night. And it certainly doesn't happen because Google or RESTful purists would like it to. That's just not the way these things go.
So. Google: Recall the accelerator. Make it do no more damage in that real, imperfect world we're living in. Application developers: Let's route around the lack of support in HTML for a RESTful interface the best way that we can.
Rails will ship its next version with a link_to that looks just like a GET, but uses Javascript, or some other way, to do a POST. Since the HTML isn't moving forward, we'll just have to build on top and make it no harder than not to. We're doing that with Ajax, we can do it with REST.
(Just in case you didn't get the implicit message at the top. This message was posted from some 30K feet in the air while onboard the SAS SK943. $30 for an entire flights worth of 30-60kb/s satellite connection. Oh my, it's sweet.)
May 04, 15:28 | Comments (15)
I'm going to be in San Francisco from Saturday through Wednesday. It would be fun to meet up for a drink with the natives already doing or interested in Rails. Anyone interested in putting something together? I'm staying at the Savoy Hotel on 580 Geary Street, so something in the vicinity of that area would be great.
May 03, 19:10 | Comments (25)
Backpack is out. Available. Here. Launched. Pushed. Online. Ya, know, yours for the playing.
May 03, 1:40 | Comments (7)
With the coming launch of Backpack (our third application) just around the corner, it was a fitting occasion to revisit 37signals.com. The relaunch reflects the company transition from world-class web design shop to application maker striving for the same accolades. I admired the former for years before getting on board to help create the latter.
And just like we try to do with the apps, we've said goodbye to bloat on the presentation too. So its just that single page you see. Instead of static praising that invariably grow out of date (and fashion), the focus is on the conversation instead. Through Signals vs Noise and the personal blogs of our people, like this.
It's been a fun ride. From we first started thinking about Basecamp a year and a half ago to today where we're steering a whole suite of applications forward. It's a testament to the flexibility of small companies. A reinvention of the self in a short time span and incurring none of "restructuring costs" of the giants.
Having been through a number of such re-inventions now, I've been growing ever more confident in saying the words: you can do it too! Whether its you as a company owner, employee, or independent consultant. We've never had better opportunities to break out and make it on our own, make it differently, and making it with passion.
The barriers of old are crumbling. Seize the excitement. Break out.
May 01, 14:46 | Comments (6)
Rails is the middle ground for a lot of incredibly interesting interactions between designers and programmers. As Rails was extracted from Basecamp where the collaboration between designers and programmer(s) has been intensely tight, it's very welcome to see that this pattern replicates outside the original setting too.
One of the reasons for this is of course that designers are able to work right on the system without losing their mind. The cries of Ruby in the template is always a call coming from over-caring programmers that think they need to shield the poor designers from the evils of code. But I and others have found through experience that there's no reason to sell designers short like this.
The primary reasons for this is of course the rise of the domain language and the succinct nature of Ruby. Designers are perfectly capable of understanding and manipulating constructs like <% for person in @post.whos_talking %> or < if @person.administrator? %>. While they will rarely be the originator for these fragments, they'll surely be the manipulators of them. Moving stuff in and out of conditions and loops.
A recent example of this is a posting by Justin Palmer on creating the Azure template for Typo (that hot weblogging engine in Rails):
As I’m still new to ruby and rails , I thought it might be somewhat of a learning process trying to get this implemented, boy was I wrong.
It was extremely easy to get everything put in place. While there is mixed ruby and html in the templates, it is very minimal. Great care has been taken to minimize the efforts on designers, and make it just as fun to design for rails as it is to program for it :-) . There’s nothing like the satisfaction of seeing things just come together, and your design coming to life.
At 37signals, the designers (Jason, Ryan) have their own sandbox and uses the same Subversion repository as developers (Jamis, me). Thus, they can make changes to their local version of the application, switch to the browser and refresh. There's no compilation phase. The templates are not overburdened by programming constructs thanks to a strong domain language.
Working on the same code base and sharing the same tools is an empowering environment that unifies the team and breaks down barriers between professions. It's in that mold where magic happens.
April 28, 21:35 | Comments (16)
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.
April 27, 12:29 | Comments (5)
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!
April 16, 12:11 | Comments (14)
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
April 15, 15:53 | Comments (23)
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.
April 15, 13:44 | Comments (6)
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.
April 15, 11:28 | Comments (3)
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.
April 15, 0:50 | Comments (0)
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.
April 14, 22:08 | Comments (6)
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.
April 14, 21:17 | Comments (5)
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.
April 12, 23:36 | Comments (9)
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.
April 12, 12:56 | Comments (3)
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.
April 06, 17:41 | Comments (17)
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.
April 05, 12:53 | Comments (18)
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.
March 29, 12:51 | Comments (21)
Ian Bicking has issued a call to arms for the Python community under the banner of Why Web Programming Matters Most. In the piece, he expresses his frustration with web programming not being more in the center for Python and longs for the growth curve of PHP.
A fellow Python programmer, Jonathan LaCour, responded with his opinion that Rails should be the model for how to turn Python into a relevant force in web programming and prevent that "...Rails will be the dominate open source, dynamic web framework for the next few years at least":
I don't even like Ruby very much, but Rails is obviously the best web framework out there because of the tightly integrated simplicity of it! Rails is the Apple of web frameworks — one tightly controlled stack. Sure, you may lose some flexibility, but you gain beauty, simplicity, and ease of use! I really really wanted to pick Python, but I just couldn't do it. There are too many frameworks, none of which are as good as Rails.
Jonathan further argues the damage of excessive choice and the prevalence of Not Invented Here syndrome in the Python web world. As a tangent to this discussion, I highly recommend listening to Barry Schwartz's excellent talk on The Paradox of Choice: Why More Is Less from Pop!Tech 2004.
In short, indistinguishable choices (or just too many) leads to lower satisfaction with the eventual pick and increases the chances that no pick will be made at all. The latter seeming to be exactly what Jonathan describes by being overwhelmed with choice of Python web frameworks and then picking an entirely different language altogether.
Unfortunately, it seems that there is little faith in resolving the situation of choice overload. Glyph Lefkowitz describes it as:
I can understand being frustrated with the proliferation of web frameworks, but let's face it: there is no way you are going to be able to convince anyone to give up on their pet framework to work on someone else's.
I see a lot of people in the Python web community complaining about proliferation of frameworks. I don't see anyone at all standing up and saying "My web framework X is unnecessary, I will abandon it and spend my web-framework development time working on web framework Y instead."
So there's a a somewhat shared understanding of what the problem is (too many, too similar frameworks of varying quality), a somewhat shared sense of a possible solution (combine efforts to get fewer, but stronger choices), but no will for the sacrifice or cooperation needed to make it happen.
Jonathan compares this situation of unsatisfactory choice with what we're doing in Ruby:
In the Ruby world, if you are developing a web application, there is no choice: there is Rails. And thats okay, since its so damn well done. In the Python world, if a web framework doesn't do something that you want, you just create your own framework... why not fix the original one? The whole situation is embarrassing.
Of course this is an oversimplification. There are quite a few other Ruby solutions for how to deal with the web problem. And new ones still appear, like the recent introduction of Wee (a Seaside-inspired framework in Ruby).
That being said, I strongly believe that there's a big benefit in having a dominant framework draw a strong profile for a small language. The amount of positive attention Rails has been able to shine on Ruby for a long time has made me particularly proud. Languages need blockbuster hits like that to establish their authority in the public perception for a given domain.
I'll continue to do my earnest in order for Rails to stay deserving of this honorable role for Ruby. The growing community around Rails is intent on doing the same. We're just pushing ~30,000 downloads now (through gems, across all versions) and are aiming to get that into the hundreds by year end.
I wish the Pythonists all the luck in finding their own formula for raising the attention of Python as a web language. Just as I welcome Pythonists that would like to give Rails a try while waiting for the former to happen.
March 23, 17:15 | Comments (10)
Dave Thomas has revealed the not-so-big secret that I've jumped on board Agile Web Development with Rails as a co-author. Dave is definitely the driver of this title, but I'll be writing about "Deploying and Scaling" as well as doing a series of "David says" sidebars explaining the philosophy of Rails.
Just as importantly, I'll be making sure that the book represents the state of the art in use and approach of Rails. As Dave says:
So how do you go about writing a book about a technology that’s advancing every week? How do you make sure that you capture both the detail and, as importantly, the spirit behind the surface? How do you make it the best book it can be?
Seems to me that a good way would be to have the guy who invented the technology help write the book.
I'm honored to be on board. Seeing my name on the cover of a book is one of my 17 things after all. And to see it happen along side one of my all-time favorite authors is, literally, a dream come true.
It's amazing to see all this book action. Agile Web Development with Rails will definitely be the foundation, though. The bible title you get first and then compliment with all the others coming out. I'll try my very best to make it deserving of this pole position.
March 23, 0:27 | Comments (9)
It's time to drop the code name. Honey is Backpack. The next big thing we've been working on at 37signals. It's an application we've been trying to narrow down in our heads for the better part of six months, but only recently acquired a focus sharp enough to start Getting Real.
And getting real we have. Backpack has once again provided me a fresh slate to experience the Rails anew, which always gives rise to a wealth of new ideas. I couldn't build a better framework any other way even if I wanted to. Frameworks Are Extractions and all that.
We've already extracted a big chunk of the technology already, actually. Remember those shiny new Ajax helpers in Rails 0.11.0? That's a Backpack extraction. Since the scope of this application is significantly larger than that of Ta-da, there was simply no way I was turned every Ajax opportunity into a mini-project of its own.
Those constraints again. If we had allowed ourselves to allocate an abundance of resources, we would perhaps just had followed what we knew from Ta-da. Did the mini-projects. Poured sweat and tears into hard work of hand-held Javascript. But we couldn't, so we didn't, and there you have it: A need to innovate.
Actually, that script/runner we also added this release. Backpack extraction. Oh, the incoming email support for Action Mailer? Backpack extraction.
No wonder the lines of code is currently a mere 585 despite having an application that does a ton more than Ta-da. I'm extracting every infrastructure breath I take. Luckily, I haven't drawn a kitchen sink yet.
But what do you care about technology. Do you want to know what it is, Neo? Yeah, I'd love to tell you, but what fun would that be. We're still 30-45 days from a release so why don't we leave it at what the trailer says:
Backpack helps you bring life's loose ends together
It's true too. My loose ends are being tied together awfully well. We've been eating the dog food since the application was a mere 100 lines.
Intrigued? How about signing up for our announcement list. We'll be picking beta testers off that list too.
Backpack is coming soon — it'll be better, not beta.
March 22, 15:48 | Comments (27)
Rails 0.11.0 is out on the street and I'm especially proud of the Ajax support we've been able to include. Instead of trying to soften the blow of doing client-side Javascript libraries as many others are doing, we've gone ahead and more or less removed the need for hand-written client-side javascript entirely.
This is done by off-loading the creation of DOM elements to the server side, which returns complete constructs that are then injected live through innerHTML. While this method is slightly more verbose than just peddling data across the wire, it's immensely easier to develop.
And especially the ease of development is critical to the success of Ajax. I used the old style of hand-crafting the DOM on the client-side with Ta-da List and was quite disillusioned at the mess of browser differences and the sheer effort it took. Basically, each sliver of Ajax was a project in itself.
With Backpack, though, I've been all over the new Ajax style that Rails affords. And what a difference it makes! It's basically no harder to make something Ajaxed than it is not to, which means that the decision is based on whether its a good fit for the user interface — not on whether we have time to another Ajax project.
We can argue about the name, we can argue old wine on new bottles, but the attention this technique is getting and its integration in frameworks like Rails will rocket its use to the moon and further blur the decision on when you need to go rich and when not to.
March 22, 11:49 | Comments (1)
O'Reilly is getting on board the Rails too. Their first book is going to be the Rails Developer Notebook, which as the name suggests is part of their Developer's Notebooks series:
The Developer's Notebook series is for early adopters of leading-edge technologies who want to get up to speed quickly on what they can do now with emerging technologies. If you're a coder down to your core, and just want to get on with the job, then you want a Developer's Notebook. Coffee stains and all, these books are from the minds of developers to yours, barely cleaned up enough for print.
The book is being coauthored by Bruce Tate (Bitter Java, Bitter EJB, more) and David Geary (Core JavaServer Faces, Core JSTL, more). The writing is supposed to start in April and the book should be out by June. So the focus is definitely to get something short out early and quickly.
If you've been following Rails advocacy, you may remember the name David Geary. I ripped into him fiercely about a month ago as he quickly dismissed Rails as being nothing but a CRUD scaffolder and declared "...you take this ROR koolaid. I'll stick with the JSF flavor".
Luckily, it didn't take much more than two weeks for Geary to reconsider the dismissal and commit to looking closer at Rails. And now just a month later, he has signed on with Bruce Tate and O'Reilly to write a book about Rails!
What a fantastic and inspiring transformation. Hopefully Geary can serve as a role model for other Java developers who are feeling "...a bit nervous about this ROR thing". Despite being heavily vested with Struts, Tiles, JSF, and Shale, he was able to see that there was amble room for a competing stack and jumped on to it.
My warmest welcomes to the Rails world, Geary! I wish Bruce Tate and you the best of luck with the Rails Developer Notebook and can't wait to read it.
March 21, 14:07 | Comments (2)
I'm incredibly proud to announce the third Rails book in the making. The title is "Pragmatic Rails Recipes: A Guide to Elegant Web Development" and the authors should be very familiar to the Rails community: Marcel Molina (noradio) and Scott Barron (htonl). They've been around since the first release and are both integral parts of the Rails community through their programs, writing, and help on IRC.
The publisher is Dave Thomas' progressive Pragmatic Bookshelf. The same umbrella that'll carry the first Rails book to be published, Agile Web Development with Rails. This will of course ensure that the two books will become very complimentary and that they'll both be available in my favorite reference book format: PDF.
It's still very early in the process, the signatures on the contract is hardly dry, so the release target is tentative at best. Never the less, Scott and Marcel are aiming at October of this year. That'll give the three books current announced a nice spread. Dave's book around July, this one around October, and the German book around December/January.
That's of course not to say that we can't fit more books into the calendar. Quite the contrary. And from the handful of offers I've been getting from various authors and publishers, I'd be quite surprised if we didn't see at least a couple of more Rails book announced this year.
Exciting times indeed.
Scott also talks about the book today.
March 18, 11:57 | Comments (15)
Yahoo! Research Labs has a pretty cool new app out making markets out of buzz called Buzz Game. It uses the Yahoo search engine to identify hot topics and assigns a dollar value based on that. When you sign up, you get $10,000 to trade for an can invest as you see please.
Now the reason this is terribly interesting is of course that they have a Web Application Frameworks market. And as I spotted this, I saw that Rails was already trading at twice the value of number two (Flex) and more than four times the value of Java. Wow!
Puzzled as to what all this would mean, I asked recognized internet entrepreneur Thomas Madsen-Mygdal. As the founder of internet conference Reboot, co-founder of wifi hotshot Organic, and a slew of other companies, I knew he would know. While Rails was trading at $22, he predicted:
I see the core fundamentals in the Rails market taking it to 80 dollars six months. A strong buy recommendation.
Holy moly! That's a four-fold increase prediction right there. Not one to distrust Thomas, I immediately invested all my starting capital of $10,000. Are you in yet?
March 11, 20:10 | Comments (9)
So I ripped into David Geary pretty good a while back for his early look at Rails, which I found to be... uhm... "lacking". But there are no grudges, only additional information.
Geary is pent on acquiring that and I'll cheer him on for that! Change can be an unsettling place, but as long as you recognize your own emotions, you're going to be fine. Geary writes about that with:
To be honest, I'm a bit nervous about this ROR thing. I've poured an awful lot of David Geary into Struts, Tiles, JSF, and now Shale and it'd be really hard for me to admit that something else is better than that stack. On the flip side, Ruby seems a lot like my beloved SmallTalk and ROR is a youngster, so hopefully I can climb up the learning curve quickly.
Excellent, Geary. Glad to have you take another look. There's nothing like peer pressure from people like Bruce Tate and Dave Thomas to offer an opportunity for revisits.
March 11, 17:42 | Comments (10)
Dion discovers the pleasure of removing code. This is also by far the most enjoyable aspect of programming for me. When I'm able to remove code, it means that my understanding of the domain has deepened. Some times it's just picking up another Ruby insight that turns three template lines into one succinct expression. That's satisfying in the "getting closer to my tool" kind of way.
But more interesting is it when the domain model reveals itself. When once fuzzy associations and unsure delegations become crystalized abstractions. I've had this experience a good handful of times with both Rails and Basecamp. When it clicks and you spot the missing class or the deeper pattern, there's a unique burst of energy released. The light bulb that goes off.
And this is where I think test-driven development has been most rewarding. It gives you the courage to execute on the deeper understanding. To radically simplify through swift cuts and add missing bridges.
The few times where I haven't had the comforting confidence of a good test suite when discovering an insight have been some of the most frustration ever. The gold is right there, yours for the taking, but you dare not grasp for it in fear of what hidden traps you'll uncover. It's horrible.
Especially because the mind is now set on the gold. The regular joy of working with the rest of the code base drops below zero when you know that an executable insight is available.
So, like, do your tests, 'mkay?
March 11, 2:11 | Comments (20)
My partner in excellence, Jason Fried, has been interviewed by O'Reilly's Marc Hedlund under the title The Builders of Basecamp. It shall be no secret that I was a huge fan of 37signals and Jason's work and ton long before I actually got involved with the company some three years ago. This interview does a fine job of highlighting a lot of the reasons why.
Jason has an incredible passion and drive for keeping it simple, telling it straight, and delivering. I'm frequently counting my lucky stars that he decided to attempt to learn PHP back in '01, that he couldn't make it work and asked for help, and that my help got the relationship going.
Asked about why we went with Ruby and subsequently extracted Rails, Jason speaks straight to my ideal on management and cooperation:
If you don't trust your developer to choose the right environment, then how can you trust him to build the best application? Trust is critical here. And, further, why would you dare impact your developer's morale by throwing him or her into a language where he can't be as productive or as satisfied? You only get good work from people who enjoy doing the work. I'll take a happy average programmer over a disgruntled, frustrated master programmer any day.
From that, it's not hard to see how we were drawn to the vision for Basecamp:
Our baseline approach is this: project management is communication. Projects don't fail from a lack of charts, graphs, tables, reports, stats, spreadsheets, and so on. Projects fail from a lack of simple two-way communication.
I wouldn't want to run a business with any other partner in the world. I wouldn't want to run any other business than 37signals in the world. And I wouldn't want to work on any other products than the family we're building with Basecamp, Ta-da List, Writeboard, and Honey. I'm having the time of my life in the best possible company.
So that's my round merry, happy back padding for today :)
March 10, 13:56 | Comments (23)
Bill Katz is a fiction author and technologist currently busy on his new venture Writertopia. He's also very interested in the beauty of Ruby on Rails and how it relates to Paul Graham's love for LISP:
Graham talks about bottom-up design, changing the language to suit the problem. It suggests one reason why Rails looks so good compared to other web frameworks: Rails looks like souped-up Ruby and not just a bunch of classes, procedure calls, and bolted-on code.
"In Lisp, you don't just write your program down toward the language, you also build the language up toward your program," Graham wrote. "Language and program evolve together... In the end your program will look as if the language had been designed for it. And when language and program fit one another well, you end up with code which is clear, small, and efficient." That's a pretty good description from 1993 on Rails development and points to a not-so-subtle difference between the web frameworks.
This is with out a doubt one of the Ruby features that excites me the most. The ability to evolve your own dialect of the language to fit the domain. The purity and beauty in code like the following is intensely satisfying (this is not pseudo code, it's fully executable without a precompiling code generation phase):
class Project < ActiveRecord::Base
belongs_to :portfolio
has_one :project_manager
has_many :milestones
has_and_belongs_to_many :categories
validates_presence_of :name, :description
validates_acceptance_of :non_disclosure_agreement
validates_uniqueness_of :key
end
Which is also why calling glue kits like Trails a clone of Rails in Java just makes no sense (and exposes the sender of such a statement as uninformed at best). Replicating a single feature of Rails, such as Trails does with Scaffolding, does not a clone make. Not only is it a pick on one of the most shallow features of Rails, but it also possesses none of the elegance. Katz addresses this with:
When answering the question "Could Rails be built without Ruby?", I think you have to address not only the functionality but the aesthetics as well. It's more than the simple lines-of-code metric. It's whether you've built a language up towards a Rails language that solves problems common in web development. As Graham points out, you could build Rails out of any language that's Turing-equivalent; the real question is in your quest to duplicate the aesthetics, whether you'd wind up doing a back-door implementation of a Ruby interpreter in the process.
When Bill Katz calls Rails "...a work of art in progress", I can definitely imagine Serious Developers tuning out: "Code is not supposed to be artistic, just functional". To me that's a terribly depressing statement. Code that can be both "art" (as defined by striving for elegance and readability as primary motivation factors) and functional is what makes programming interesting to me.
Oliver Steele from Lazlo touched on many of the same issues.
March 09, 13:27 | Comments (21)
While there wasn't much hesitation before sharing our troubles with the latest upgrade, I did pause for just a second. Will people think less of us because we didn't do this or that? How will the story reflect in the light of calm analysis and perfect hindsight? Luke offered just that view in the comments:
...building solid web applications is your THING. And that's not just about development. You need to take some of your developer brilliance & insight, and invest I tiny bit into the operations side of what you do too.
Which is a fair stance. But it's of course also what makes a lot of companies terrified of sharing stories of trouble. And what gave me pause. In the end, though, I believe that the net benefit of transparency far outshines the small bruises you'll inevitably in return.
As an example, we're currently conducting an open-ended questionnaire with our customers asking what they like, don't like, and would love see changed. I took especial comfort in this comment on what to like about Basecamp:
The clean interface, ease of use, basic tasks are easy to execute. All features aside, I greatly appreciate the transparency of the operation. Not only has david released Rails to the world, but you guys (or David) had the balls to discuss the hardships felt during your recent upgrades. Most companies would leave it at "we apologize for the failures".. but letting/having a partner discuss the issues in detail is something you just don't get every day. It's extremely refreshing, and something more companies should emulate.
I believe this is part of the competitive advantage that small companies can enjoy if they dare. The freedom to say that you made mistakes. How you made them and why. The freedom as a partner of the company to say fuck, if that's how you feel.
P.S.: It definitely seems like the transparency is infectious. Jamis just shared another story on what can happen when you go to the keyboard ill. Hopefully we'll soon return to the stories about how we're conquering the world instead of how we're failing to ;)
March 08, 19:36 | Comments (14)
When we did the first Building of Basecamp, the last seats were sold just a few days before the workshop. The pace of registrations have steadily accelerated with each time we put on a new show. But this is getting pretty insane. We just opened for registrations five days ago and we've already sold more than half the seats!
Can't wait to get back to Chicago (the last two were in Seattle and San Francisco). I got my favorite flight (SAS SK0943, 9 hours direct) booked already. I hear they have wifi on the planes now, so that's going to be pretty cool.
Hopefully we'll be able to run a show just as good as the one Jason Hummel attended:
I attended a previous conference in Chicago, and I can tell you it's worth every penny. If for nothing else, just to see people speak who are passionate about what they do, and more importantly how they do it. Of course, if your like me, be prepared for lots of conflict at your job on your return, since you'll immediately recognize how wrong your coworkers/supervisors have it. You'll also wish a job opening would open up at 37signals. ;)
March 08, 19:15 | Comments (7)
The O'Reilly Open Source Convention is happening on August 1st until 5th and I just got the official confirmation that both of my proposals have been accepted. I'll be doing a tutorial and a session talk:
- Ruby on Rails: Enjoying the Ride of Programming: "Learn how to use the open-source web framework Rails to create real-world applications with joy and less code than most frameworks spend doing XML sit-ups. We'll get heads on and learn enough Ruby on the go to take us through to something useful. We'll examine all the major components of the framework and learn how they make up the full stack of Model, View, and Control." (3 hour tutorial)
- Extracting Rails from Basecamp: "Rails owe its origin to Basecamp and the experience formed the hypothesis that "good frameworks are extracted, not invented". The hows and whys of a successful web-application framework emerged from a equally successful real-world application." (45 minute talk)
I'm really honored to see both proposals being picked up. Especially considering O'Reilly had to reject three out of four proposals. I'm also really looking forward to be presenting back-to-back with Dave Thomas, who will be doing a 3-hour tutorial on Ruby.
With all the enthusiasm around Ruby (and Rails) at the moment, I don't have any doubts that we'll be presenting to packed rooms either. Especially since Rails 1.0 will have been released by then and we'll have at least one book about Rails out too.
UPDATE: _why is going to be at OSCON too! He's the village genius of weird goodness. Can't wait for his show. Oh yeah, the creator of it all, the honorable Matz will also be there. How can you not want to do everything possible to get to OSCON this year?
February 26, 0:19 | Comments (8)
Bruce Tate's discovery of Rails and his comments about where it could (or should) be applied got me thinking of Clayton Christensen again. I've been reading The Innovator's Solution (and the Dilemma too, actually). In Christensen's model for describing disruptive technologies, Tate's description fits in nicely with the notion of over-served customers:
I’m not going to pretend that anyone would ever use Rails for everything. But think of the number of applications that you build that do nothing but put a big web front end on top of a persistent model. That’s a huge part of what we do. If Ruby and Rails can make you that much more productive, and if it solves the problem, why wouldn’t you?
The industry is being massively over-served by J2EE/.NET in the majority of projects. The backlash against EJBs and other Titanic-type technologies demonstrates this well. And I see a hope in the increased collective awareness that maybe not all projects need the tools targeted at the very most complex ones. And not only don't need, but are damaged by.
In this frame of thought, Rails is able to deliver incredible improvements for the majority of projects that are currently being over-served by J2EE/.NET by sacrificing a whole herd of golden calves. The sacrifices are condemned by the high priest exactly because of their status as high priests, which means they work on the most complex projects and hence cast all decisions on technology in that context. Would this work for the 5% most difficult projects? If not, then it "doesn't scale".
This, according to Clayton's theory, invites the incumbents and their high priests to flea higher up in the market when attacked at "the low end". They seek refuge by attempting to deal with even more complex cases, which in turn makes their tools even more complex.
At the same time, Rails as a disruptive technology undergoes rapid improvement that expands the number of projects for which its a good fit all the time. What may have started as only suitable for simple projects become suitable for medium projects (top of the bell) and in time becomes suitable for the complex and even very complex projects.
As this process unfolds, it's natural that both a fair share of cognitive dissonance will be developed by the incumbents and their high priests and that a lot of companies following them will be caught in the competency trap. High rents are being extracted from the accumulated knowledge and technology held by big corporations and the companies and consultants around them. Attempts to uproot will not be taken kindly.
February 25, 13:53 | Comments (11)
Evan Williams (of Blogger fame) and friends have unveiled their latest venture: Odeo. It's going to make "...it easy for you to discover, create, and subscribe to fresh, independent audio content for your iPod". In short, Portal for Podcasting. That hook got the interest of The New York Times, but to get the full story, you'll be well advised to read Evan's blog posting about it and the Odeo blog in general.
I had a sneak peak at the application a few days ago and it looks mighty cool. I'm a big fan of podcasting myself (especially from the ever excellent ITConversations), so the prospect of Odeo makes me pretty excited.
What also makes me excited is Odeo running Ruby on Rails. Remember that posting Evhead advertises for a Rails developer back in the beginning of December? That resulted in the hiring of Rabble as the lead developer on Odeo. He talks about the Odeo launch and how they "...built it with the wonderful Ruby on Rails framework" in his blog.
So congratulations, guys! It's great to see another high-profile site launch on Rails and loving it. Keep 'em coming.
February 24, 16:26 | Comments (19)
The Rails team has released Rails 0.10.0. It's a huge upgrade and a big step on the road to 1.0. The key words for this release are Routing, Web Services, Components, and Oracle. It has never been a better time to get your Ruby on Rails. Stop procrastinating, come on over.
February 22, 2:46 | Comments (37)
After the last salvo of Java fire, I considered it best let the gun cool off for a while before giving it another round. But it's just so darn hard when my newsreader is flooded with misinformation, shallow intentions, and the smell of fear.
Let me start in good manners by offering up some self-deprecation. It has been a mistake to power-push scaffolding through movies and tutorials without following up with the story of how Rails is actually used by people building real-life applications. I acknowledge that while it has brought plenty of wow-factor attention, it would leave the recipients — who only got that message — with an easy path to draw distorted conclusions.
The fact is that scaffolding plays a very small role for anything more than getting people interested, teaching them the first baby steps about doing CRUDs in Rails, and possibly, remotely for doing non-important admin stuff. It was hacked together in a single afternoon as a spur of the moment thing after I had remembered about naked objects and just wanted to take a quick stab at shallow auto-wiring. The main driver for scaffolding is a mere 100 lines of Ruby code!
Why code and HTML gel in Ruby and not in Java
Suffice it to say, I'm disappointed, but certainly not without blame, when I see the simplicity of scaffolding being used as a straw man to convict Rails. I'm equally disappointed, but at some level understanding, when Java programmers apply the misfortunes of their own environment to ramp up the indictments. Dave Geary has this bit:
It's nice to get you up and running, and great for seductive demos and articles, but you're going to override at least 100% of the views that ROR generates. And therein lies the rub... because views in ROR are a mixture of HTML and Ruby scriplets! We've been there before, of course, in the early days of JSP with HTML mixed with Java scriptlets. No thanks, I'll pass on that giant step backwards.
Let's examine the origins of one of that charge — the mixture of Ruby and HTML being a bad idea — and I'll explain why its misguided.
In Java with JSP, it's incredibly tempting to allow your view logic to deteriorate through responsibility creep (overloading them with business or mere complex logic) that leads to a rapid rot. Back in 2001, I worked on a J2EE system fraught with rot of this kind. I can perfectly understand the fear of such decay can instill in any developer.
There are many reasons that things turn from bad to worse with JSP. Allow me to list just three:
- JSPs are normally auto-compiling: Unlike the controllers and models, you can make a change, then see it work. In other words, you can circumvent the drudgery of letting the Ant loose to recompile the half or all of the system and redeploying it in the container. Hence, JSPs serve as a constant and appealing temptation to do the bad thing to get the job done.
- Extracting complex view logic is painful: With tag libraries, it's possible to be a good programmer and rid the views of complex logic by extracting code and replace it by tags. That is a noble and right path to follow. The problem is when the effort required to do the right thing is so intense that its basically a project in itself. Then its not something you're gently invited to do. It's a huge barrier and easy source of procrastination ("I'll extract later...") and guilt ("If only I had extracted sooner...").
- Java is a terribly view logic language: I talked at length about this subject in The false promise of template languages and I doubt there's any disagreement here, so I'll leave it at that.
Let's contrast this to the situation with Ruby on Rails:
- All layers are "auto-compiling": There's no compilation penalty for placing code in the controller or model in Rails. All changes are instant! This creates an environment of equal opportunity where code can be placed in the appropriate level right away. In fact, it is often less convenient to place code in the views than in a helper or in the model because you have to integrate it with the HTML instead of just making another method. Temptation to do bad has been replaced with convenience to do good.
- Extracting view logic into helpers is easy: As I was riffing on in the rant about template languages, view logic is not a bad thing. It just needs to be managed through extraction of commonalities and complexity. Exactly how easy it is in Rails is hard to explain in words, so I made a little video to do it on its behalf (I'm just working with scaffolded code here, perpetrating the original crime, I know).
- Ruby is an excellent view logic language: Ruby is incredibly succinct and imminently suited to do view logic where conditionals and loops are mixed and matched with HTML. Allow me to demonstrate with another example.
But it gets even better. You don't have to mix Ruby and HTML, if that doesn't cook your noodle! Rails provides a fully programmable alternative using Jim Weirich's excellent Builder class. It's very cool and I use it in all the places where I don't collaborate with designers (where HTML is a nice common language). An example is the Builder-template for the RSS feed in Ta-da List.
So with the addressing of Dave Geary's hasty conclusion that "But [Rails] seems to me that once both apps are up and running, ROR is no match for a Java-based web app six pack of JSF-Shale-Tiles-SiteMesh-Hibernate-Spring" purely on the basis of "implementing my own views in ROR looks mighty ugly to me", let's move onto to the even more depressing perception of Rails held by Trails creator Chris Nelson.
'This seems to totally preclude having a rich domain model'
Trails is a can of glue for binding existing Java frameworks like Spring, Tapestry, and Hibernate together into what Chris calls "...a domain driven development framework in the spirit of Ruby on Rails or Naked Objects". Seeing he even got the casing right on RoR, you should think that he spent an equal amount of time understanding the very spirit he's attempting to clone. He echoes the charges from Dave Geary's post on scaffolding and Ruby in HTML (apparently equally ignorant of the issues outlined above), which we won't bother with again, but also adds a third to the mix:
First, domain classes in Rails have to extend ActiveRecord::Base. At first I didn‘t get how big an issue this is, as I assumed Ruby had multiple inheritance or something similar. But having delved into a bit, I‘ve learned that it does not. This seems to totally preclude having a rich domain model. That‘s a compromise I wouldn‘t be willing to live with. It seems like maybe this could be easily done in a different way (with mixins maybe), so let‘s hope Rails makes an improvement here. Since Trails uses Hibernate to persist POJOS, that just isn‘t an issue here.
(My emphasis). Reading that gave me one of those woah experiences. Let me try to give my understanding of what the above means and then address it (then Chris can perhaps correct my understanding): Because Rails already used the first step of inheritance, you can't use inheritance for your own domain model. This is of course not true.
In addition to regular inheritance, Active Record supports single-table inheritance that can give you hiearchies like:
class Company < ActiveRecord::Base; end
class Firm < Company; end
class Client < Company; end
class PriorityClient < Client; end
Additionally, Active Record supports a very flexible and powerful set of associations for describing relationships between classes:
class Project < ActiveRecord::Base
belongs_to :portfolio
has_one :project_manager
has_many :milestones
has_and_belongs_to_many :categories
end
Hence, it addresses both of the short-comings of the original Active Record pattern as described by Martin Fowler while making it incredibly easy to create rich domain models without the overhead of XML sit-ups to describe the mapping.
True, Hibernate can certainly handle more edge cases and legacy database integration jobs, but to state that "This seems to totally preclude having a rich domain model" is one of the most ignorant statements I've ever read about Rails. And its baffling that it comes from a guy that claims to be interested enough in Rails to attempt to recreate the spirit in a Java package.
Jumping back to Geary for a moment, I'd like to ask him to reconsider just how big a Dave Thomas fan he really is (he states "I'm a big Dave Thomas fan"). You obviously don't have very much respect for Dave's sense of judgement, if you think he would be excited enough about Rails to talk about it in front of Amazon and at the Java No Fluff conferences, not to mention that he's write a whole book about Rails!, just because of a little scaffolding.
So please, both of you. Don't be a stereotype. Dislike Rails for all sorts of reasons based on more than a shallow look and a quick dismissal. Talk about how it has no major vendors behind it to make your enterprise feel secure, how static typing makes you all warm and fuzzy, what terrible life would be without IDEA, or how you need to integrate with crazy legacy schemas all day long that Active Record can't handle. There are plenty of enterprisy reasons to diss Rails. Using scaffolding or Ruby in HTML as straw men are not.
To everyone else spectating this with curiosity: Unless you've already been turned off by Rails with my inability to let any negative Rails mentioning on the web slide me by without a big fuzz (and I forgive you if you are), I recommend that you have a look at some Rails code that isn't about scaffolding. Tobias Lutke has some great Subversion repositories available online for the minimalistic weblog-engine Typo and for the book collaboration project Hieraki. And there are move available at documentation.rubyonrails.com.
Even better, download Rails. It's really easy to get started. We include just about everything in the box and there's always somewhere between 150 and 200 people available in #rubyonrails on Freenode to help you get started.
February 19, 1:51 | Comments (26)
One of the clear goals for Rails from the start was to stay at the infrastructure layer. I didn't want Rails to succumb to the lure of high-level components like login systems, forums, content management, and the likes.
I worked in a J2EE shop for seven months that tried to pursue the component pipe dream for community tools with chats, user management, forums, calendars. The whole shebang. And I saw how poorly it adapted to different needs of the particular projects.
On the surface, the dream of components sounds great and cursory overviews of new projects also appear to be "a perfect fit". But they never are. Reuse is hard. Parameterized reuse is even harder. And in the end, you're left with all the complexity of a swiss army knife that does everything for no one at great cost and pain.
So Dan Creswell's SOA doomed? rings particularly true in my ears. And reaffirms my belief that Rails will do the right thing by resisting the temptation of high-level components and focus on bettering the infrastructure:
All attempts at creating high-level business components that can be re-used and re-configured have failed previously. This failure has not been for technical reasons - it happens because the requirements that yielded the original component interface were sufficiently different from the new requirements so as to require re-writing massive chunks of functionality.
I have similar issues with the ever recurrent case tool dreams. I'll address those some time.
February 15, 23:50 | Comments (24)
Simen Brekken writes in comments for The false promise of template languages:
Our designers never deliver anything but Photoshop comps or at best slices, and I wouldn't want it any other way. It's all about delivering a quality product and the graphic designers should focus on the design, and you as a programmer on the implementation.
Simen, surely photoshop comps is the right thing to deliver is all you have is "graphic designers". Thankfully, there are many other forms of designers. The ones running 37signals are first and foremost application designers — focusing on visual priority, interaction flow, etc. The closer to real they are, the closer to the elements they can operate, the better designs they do.
The constraints of HTML/CSS and web interfaces should be available to the designers all the time. It's the feedback that causes good designs. Constraints don't inhibit creativity, they foster it.
When you're just photoshop comping, you're merely painting pretty pictures. Those pretty pictures may or may not translate well into designs. My experience has been that they are way more "pretty" than useful. They also tend to make you focus way to much on looks and way to little on interaction. You can't interact with a photoshop comp, but you can easily interact and get a feel for a flow of five HTML screens linked together.
Additionally, it's a big waste. Doing the whole thing in photoshop, then redoing everything in HTML is wasteful. It certainly depends on your organization, but getting real faster, going HTML sooner, is a way to do big things with small teams.
I believe photoshop comp'ers are great for making the next Nike commercial site with spinning wheels, flashing shoes, and pretty photos zapping back and forth. They're terribly inefficient and inadequate for designing applications, though.
February 14, 17:12 | Comments (22)
This is a repost from an exchange on the Rails mailing list. I got a recommendation to give it a more permanent home and share it with the world. We had a long running thread on whether Rails would benefit from some form of Amrita-style template language that "doesn't contain any code". Steve Longdo wrote about that:
The designers that a lot of the rest of the world works with aren't
the same caliber as 37 signals by a long shot. Dreamweaver expert
does not likely yield a decent ruby/rhtml coder...
Florian Weber followed up:
i think it's better to get the designer work as close to the real thing
as possible. that also avoids wasting time.
And I wrote about how we work at 37signals...
I concur that its a false dichotomy. The designers at 37signals are not Ruby programmers. What they are capable of is reading english-like code fragments and move them around accordingly.
This is how we work:
- Designer cooks up static HTML template.
- Programmer sprinkle it with rhtml tags to make the dynamic elements
dynamic.
- Designer and programmer can both revisit the template to make
changes.
The reason step 3 is possible is exactly what forces good programmer behavior in the templates:
<% if @user.is_administrator? %>
# show stuff that's only for administrators
<% end %>
...or
<% for comment in @post.comments %>
<h2><%= comment.headline %></h2>
<% end %>
No matter how "easy" you make your template language, new dynamic templates are not going to originate from the designers. What you can make possible is cooperation around the same templates once they're alive.
I remain utterly unconvinced that Amrita-style templates are going to do much anything than please the aesthetics that have fallen in love with <li oid="people">Loop</li>. It's not going to put designers in the driver's seat for new templates. And even the one promise of being able to edit in Dreamweaver falls to the wayside when you introduce layouts, partials, or other productivity techniques for dealing with templates.
The pursuit of "no code"-templates reminds me of the search for the holy grail of the MDA camp with "no code"-programs. It's mirage, but its also a play on words of the "a rose by any other name..." variety.
Code is just another word for decisions about instructions. Whether those decisions are made through indirection and tag decoration, they are still decisions about instructions. That is, its still code.
With all that said, I shall not stand in the way for the pursuit of another man's aesthetic dreams. Many will know that I guide many decisions about Rails from my own sense of aesthetics all the time. I'd feel a lot more at ease about it if the proponents of Amrita-style templates would just confess, or realize (as the true motive may still lie in the subconcious ;)), that the pursuit is one of aesthetics.
So. If you want to try this out, feel free. Should a truly non-intrusive solution emerge, I shall even give it serious thought as whether to include it.
UPDATE: The reason why I think the whole notion of code-less templates have taken hold is because people have been used to languages that were utterly unsuited for template logic. The template languages presented a less painful way to add logic and due to the lower pain associated with their use, it grew too tempting to fit in inappropriate code to them.
That's totally different with Ruby on Rails. First of all, Ruby is an excellent language for view logic (succinct, readable) and Rails is also made out of all Ruby. So there's no longing for a better suited template language and there's no pain relief in misappropriating business logic into the view.
January 28, 16:30 | Comments (23)
Our fourth Building of Basecamp went really well yesterday. We didn't make as many radical changes to the presentation this time as we've done before, so the material was more intimate to us and we are able to deliver it in a more convincing and timely manner.
Especially the timeliness was helped along by Apple's great new Keynote 2, which has a presenter view that's different from what's being shown on the projector. This view has a clock, a timer, notes, and — most importantly — a preview of the upcoming slide.
We also had significantly more push-back from the audience on our views on functional specs and contract-driven development, which gave a more varied discussion. Speaking of discussion, Dave Thomas of the Pragmatic Programmers was in the crowd asking lots of questions. Thanks, Dave!
All in all, it was really fun doing it again. I look forward to our next one, which might be in New York in a couple of months. The plan is to do the workshop every two-three months.
Today the plan is to hang with Jamis Buck and Dave Thomas before they head back around noon, visit the Robots to talk about the 43 Things experience on Rails, and finally pay a visit to the Seattle.rb (the user group for Ruby in Seattle) at the Omnigroup's offices.
Oh, and of course pick up my Mac Mini and iPod Shuffle also at the Robots office. Can't wait to fondle the both of them!
January 22, 12:46 | Comments (48)
Just as Patrick Lightbody recants his ill-guided charge, Geert Bevin — also involved with a Java web-framework, this time RIFE — picks up the torch and tries his best to scorch the earth anew:
About tadalist, that application is so stupid that I'm wondering how the hell it could have taken him 600 lines to write it. Also, the hugely hiped 'killer application' of RoR, Basecamp, is a total fraud imho. The screenshots look nice, and are nicely presented. So I did make an account and started using it. And honestly, everything they say is true, it sets itself apart in simplicity. Not difficult to write that in a few weeks.
It's incredible how much vile bile that lies within the Java community. I'm beginning to understand why many of the defectors I've talked to are so happy about the Ruby and Rails communities. Oh well, back to the stupid, fraud applications.
January 22, 1:22 | Comments (30)
Patrick Lightbody is on the steering committee of the Java web-framework WebWork and not at all happy about all the attention Ruby on Rails is gaining. Apparently, it's all terribly undeserving as Rails surely "doesn't scale" to applications with "thousands of concurrent users and/or hundreds of thousands of gigabytes", right?
Of course, Patrick doesn't bother to back up his charge besides asserting that "anyone... knows that a CRUD framework just doesn't cut it". Interesting. Rails follows a similar approach to scaling as do Yahoo and LiveJournal. Share Nothing. Push concurrency into the database and the memcache. I hear that approach is working rather well on LJ's 100 machine park handling 5+ million dynamic requests per day.
But why bother addressing the specifics when you can just assert the somewhat cryptic "Mapping web UI directly to the DB never scales". What does this mean exactly? Does Patrick think that the only UI you can do in Rails is a scaffolded one? Oy, talk about forming ill-informed opinions.
If any of these vague, hand-waving assertions should have failed to convince you, then of course, we can always rely on our good friend complexity!
Form processing, payroll, etc probably work very well with RoR. But trying to implement Spoke using RoR would be impossible — the schema is just too complex.
I'm sure it's too complex, Patrick. Can't beat an expert at his own game. But since you're interested in learning more about marketing your open source wares, you might start by dropping the FUD tactics. They leave such nasty stains of ignorance and bitterness.
Brian McCallister offers a similar rejection of Patrick's fear mongering:
It is scary (FEAR FEAR) to see opinions formed, and backed with vitriol, by fear that something different than what they are doing works better. Something you don't know that approaches the same problems as something yo | 
