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.
Amidst all this traveling and planning for traveling, we've recognized that we need to get the "real" Summer vacation tour down. Before ticket prices start to become filthy expensive and before my calendar books full. So, considering all the good advice I've been receiving on this blog about traveling in the past, I'll ask once more.
What's the best way to enjoy Hawaii? We're thinking 10-14 days some time around mid-August. Perhaps Maui. Hotel in the ~$120/day area. Good beaches, interesting spots to visit. All that jazz.
I just discovered Kathy Sierra and her Creating Passionate Users blog. I'm already signed up for her tutorial at OSCON and after reading just a bit from her blog, I couldn't look forward to it more. I basically have an instant reaction to all of the posts I've read or skimmed so far. She seems to be verbalizing a lot of the reasons that I think Ruby on Rails, 37signals, our applications, and my other endeveaurs have made some waves.
But let me riff on just one of them for a while. The idea of Hiring Different. This rings true to me in a lot of ways because I was never Computer Science Smart. While I can appreciate the beauty of mathematics and algorithms, I could never be that person. I tune out, like I did in high school earning an F in mathematics after a year of copying other people's papers and skipping class as much as possible.
So that's actually why I was in my twenties before I got into programming (that sounds old, but that's recent history when you're 25). I thought that you had to be crazy about math to be a programmer. I feel like that about a lot of subjects forced upon me. I think I've boiled it down to the fact that I don't really like hard problems. That's of course another piece of programming sacrilege. When you watch programming from the outside, everyone seems to love the hard problems and its widely celebrated as the interesting accomplishments.
But there are so many simple problems that haven't been solved. Or haven't been solved well. I'd rather solve them. And if I must tackle a hard problem, which you'll be hardpressed to totally avoid, I'd rather enlist the help of people who like that or judo the hard problem into an easy one. Because for me its all about value (and probably attention span): If you can get those magical 80% of the solution for 20% of the effort, how about just finding a way to cope with the missing 20% of the solution? If you can, you get to solve five easy problems (with comparable value) instead of solving one hard.
Naturally, this doesn't work for all situations or everywhere (I'm guessing). In my current context, building web applications, I've found it to work exceedingly well. And that's of course what makes it interesting in relations to Hiring Different. I would likely not fit into the celebration of hard problems and mathematical aptitude that places like Google, Microsoft, Joel Spolsky, and others see as the filter for good programmers.
And I think that's a shame. Not on my own accord (he said with arms crossed), but for the lack of diversity it creates, as Kathy Sierra notes. And in turn, for the lack of products coming out of that diversity. Products I would have liked to buy and use.
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.
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 ;)
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.
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.
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 :)
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.
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.
(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.)
When car companies produce faulty vehicles that cause horrible accidents or aggravated injuries on regular mishaps, they do a recall. Google's Web Accelerator is causing death and destruction on an admitted much lower level of criticality, but it too is in need of an immediate recall.
Google screwed up on this one. Really bad. But that's not what's important. Or at least not the most important thing. No, the trial of "do no evil" is how quickly and effectively Google can react to their screw-up and set things right. How fast will they make the calculation:
Take the number of accelerators in the field, A, multiply by the probable rate of failure, B, multiply by the average out-of-court outrage over loss of data, C. A times B times C equals X. If X is less than the cost of a recall, we don't do one.
Google needs to acknowledge the size of X immediately and act on it yesterday.
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.
Backpack is out. Available. Here. Launched. Pushed. Online. Ya, know, yours for the playing.
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.
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.