Dave Thomas has released the third and final beta of the Rails book. It's heading for the publishers some time next week and should be available in hardcopy around the beginning of August. If all goes well, Agile Web Development with Rails should be here soon indeed.
It's been quite a long process for something that was meant as a quick tutorial-type book at no more than two hundred pages. But what a product coming out in the end. Dave Thomas has been doing an outstanding job on giving all part the framework at least a cursory overview and most parts so much more all combined with easy-to-follow examples (my favorite way of learning for sure). With excellent help from Leon Breedt, Mike Clark, Thomas Fuchs, and Andreas Schwarz, he has steered the book into an essential reference point for any Rails developer.
And the timing has been great. Not only did the beta books hit just as people were crying out the loudest for more documentation, but the final copy will hit just as Rails reaches 1.0. I'm really happy to have been a part of the creation of this defining work. The uptake of Rails will no doubt be helped immensely but this and hopefully the book will also pave the way for the long string of other titles announced.
Once again, thanks a bunch to the ~2,500 people who bought into the idea of the beta book. Hopefully this will encourage even more publishers to try out the format and reinforce the few others already doing it in that it's a great idea.
True, there really hasn't been enough love on Loud Thinking lately. To substitute for that, here's a lovely flower:
It's great to hear that Microsoft is waking up to the message that Ajax used to be really hard. They're even going to build tools to make it easier as part of Visual Studio. Fitzgerald says:
But (you knew that was coming). I'm sorry to rain on your parade, Fitz, but the world has moved on since that was the case. Ruby on Rails, for one, shipped with top notch Ajax support all the way back in March. We've been improving the situation rapidly ever since.
And the next release, the just-around-the-corner 0.13, is taking that to new heights with script.aculo.us, no-effort auto-completion, upload progress, and a new version of Prototype.
When is Fitzgerald and team going to ship? Some time in November.
So if you're looking to get jiggy with the Ajax, don't hold your breath for Microsoft to deliver. Jump on the Rails and enjoy the tightest integration of Ajax in any complete tech stack. We've been making it "just as easy as not to" for quite a while now and shipped products with tens of thousands of users on it.
There's no time like present time to open the trunk and getting out of Redmond's grip.
The crew at Aimido must think that there are multiple internets, divided by country borders, and that stealing from one net to another will have no consequences. Because they have shamelessly ripped off the entire concept and much of the design behind 43things. Their contribution? A German translation.
But a German translation of 43things already exists — it's called de.43things.com. Thanks, but no thanks. And considering that the management consisting of Berit Ernst and David Kuczek have both graduated from prestigious universities, such as Stanford and MIT Sloan, you should think they were familiar with the idea of plagiarism. But it would appear not.
And that's the wildest thing about it, really. Berit and David have formed an entire company around this blatant rip-off with high and mighty board members from the German business elite. They even got the German press to pump it up.
When called on their sham by 43things head honcho Josh Peterson, they brushed it off as insignificant. At least one of the board members, Harald Schröpfer, is having second thoughts, though:
Sorry for not having been clear enough on this – I am one of the advisors, so with “them” I refer to the core team (which, by the way, are just what I would call “young enthusiasts”, so I still recommend giving them a chance. Or giving “us” a chance, because I have to admit that I was part of this and so I’m also to be blamed … Shit, I really didn’t find the time to pay more attention)
PS: I’m pretty sure I will delete this comment in a few minutes … :-))
Maybe that's why the revised management page doesn't include the board members/advisors any more (but luckily there's a snapshot available). I'd sure think twice about having my name associated with such a shady operation as well. So no wonder Andreas Arntzen, Dr. Lars Langusch, Harald Schröpfer, and Oliver Weyergraf seems to have decided the same.
So please, Berit and David, get the fuck out of Josh and crew's house. Founding your own company is a wonderful thing, but doing so on the top of despicable plagiarism like this is not. Get off the air, spend a few months thinking up something original, and then come back for a second try.
Disclaimer: 37signals designed 43things and we're friends with the Robot Co-op.
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)
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.
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.
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.
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.