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 you do know does not make the first thing bad. It does not justify lashing out at it saying "it is just [foo] and sucks so bad compared to [bar] and can never [scale|perform|manage|eat] enough to be used for [serious|difficult|real] things." Possibly this is true, but reacting that way out of fear certainly does not make it so.
Now back to our mega-scala-enterprisy-serious-real-complex-important work. Nothing to see here, move along.
Please follow up with comments on the Rails blog version of this post
January 20, 17:53 | Comments (9)
We knew it we had a neat application going with Ta-da, but the last 24 hours since launch have really showed just how neat people think it is. We already have thousands of people signed up with tens of thousands of items recorded in their lists.
And the server isn't even breaking a sweat (load averages: 0.07, 0.03, 0.02). The caching additions to Rails have really made a huge difference and its fun to watch the logs race past your eyes with entries like "Completed in 0.003394 (294 reqs/sec)".
A huge part of this early success is due to the fantastic uptake by a bunch of bloggers. We're tracking it on a public list called Ta-da mentions and I believe that the count is already 42. The blogosphere can sure launch a project like nothing else. Thanks, all of you.
In addition to the bloggers, we're now #1 on del.icio.us / popular with just under 300 tracks at the time of writing.
January 19, 23:46 | Comments (16)
Todo lists have long been one of the favorite features in Basecamp, so we thought it would be a nice experiment to share that particular feature with the world at large. Free of charge. And Ta-da List was born!
A few user-oriented highlights of Ta-da:
- Extensive use of XMLHttpRequest: Adding new items and checking them on and off are done with remote calls that change their state in the database while simultaneously updating the view using Javascript. This makes it really, really fast to add new items to a list — and you're not restricted by the 10 predefined fields that most apps like this does.
- Loose sharing with unique URLs: Sharing a list with a single or group of buddies is easier than ever as there is no password to remember. Instead, everyone just gets a unique URL that they can bookmark right away. At 32 characters and as a MD5 hash, it's plenty of security for this type of application and much easier to use.
- Collecting all the shares: By allowing you to share any list with any email address, we already got the viral thing going. The barrier of signing up has been postponed until you're hooked, and once you are, you automatically collect all the shares as you signup. This means that they're all available from your dashboard and you can reduce the bookmarked lists down to one URL.
And for the technically inclined:
- Three levels of caching: I implemented page, action, and fragment caching for the Action Pack in Rails so I could be able to use it in Ta-da. And it's working exceedingly well. Lots of pages went from 50-70 req/sec to 400-1100 req/sec due to caching.
- 579 lines of code: That's including models, controllers, and helpers. It's really lean and really readable too. It was great to see just how small you can make an application with a recent version of Rails (especially the 0.9.x series) on a fresh code base. In Basecamp, I'm often working on code that predates the release of Rails, so it's a nice change of scenery.
- Finally FastCGI: Basecamp is still running mod_ruby for various reasons, but Ta-da is fresh out the gate on FastCGI. And what a difference it makes in memory consumption! We're currently running five FCGI processes (which is more than plenty) that come in at about 15MB a piece. On top of that, we got 50 Apache processes at just around 3.5MB a piece. That's just 250MB for the entire setup. Much unlike the situation on Basecamp where we have 40-60 Apache processes of 40MB a piece.
In addition, it seems we're off to a flying start as we blew through 1,000 people signed up in just a matter of hours! And it's getting blogged all over the place. Justin French has a really nice post about how he switched his workflow over. And Tobias Luetke already whipped up a script to integrate Ta-da into your site using Ruby.
January 07, 13:47 | Comments (1)
We just launched a major upgrade to Basecamp to coincide with the plan revisions for 2005. It includes a big push for security with SSL being available to both Premium and Plus plans and SFTP being available to all paying plans. It also makes it easier to use Basecamp if you're not in Central Time as its now possible to specify time zones on a per-company basis. Oh, and we finally added "Remember me for 2 weeks" back.
So launching a big upgrade is good, but getting the feedback from happy customers is even better. The thread on the launch is already filled with congratulations, like:
Thank you for kicking tremendous amounts of ass... My God, I love you guys. I think I'm going to cry... I seriously treasure the day I discovered Basecamp!!! So many amazing updates! Basecamp Forever!
The outburst of joy is even more welcome after we've been battling with a couple of extremely rude and totally unreasonable customers the last couple of days. One guy wanted to "DESTROY YOUR COMPANY" if we didn't refund his six months of usage. Yikes! So a huge thanks to the vast majority of our customers that are liking what we offer and are not afraid to say so.
This release is significant in another way too. It includes, for the first time, the work of another programmer in the core Basecamp code base. We've brought on Ruby master Jamis Buck as a moonlighting consultant and both the SFTP and timezone support are to his credit.
I've been impressed with Jamis work on sqlite-ruby, Needle, and Net::SSH for a long time, so when we had the opportunity to engage a working relationship with him, it was obvious that this would be a great fit. And it has been. I can't believe that a Ruby programmer of Jamis' caliber isn't doing it full-time, so we'll see what are in the cards to change that.
UPDATE: Jamis shares a few more details.
January 03, 18:57 | Comments (16)
I've been a test-driven developer for quite a while, but I haven't really gotten into the religious test-first branch yet. Usually, I'm too impatient. I have a good idea and want to execute on it right away. Then, when I see it in code, I'll come back to do the tests.
I have done short spurts of test-first — some tasks just seem to invite it — but not as a regular approach over a longer and sustained period of time. I want to give that a try. For a month. Where I can't right any code until I've seen a test fail.
It's one of my 43 things.
December 31, 13:18 | Comments (8)
Kevin Dangoor is getting out of J2EE development after four years of legacy mud and fear-driven technology choices. He has picked to start his new businesses on a dynamic language with Python. Unfortunately, he's still stuck in Java-skewed thinking on the difficulties of learning a new dynamic language or framework:
Ruby looks nice and Rails is attracting a lot of attention for good reason. Seaside on Squeak should be attracting attention, because it looks like a very productive way to put together apps. There are two problems with both of these: 1) I don't know them, and 2) they are less mature and have smaller communities than Python or Java.
I can certainly overcome (1), but that would slow me down initially. The clock is ticking, because I need to generate money to pay my mortgage and all that... The second point also means slower velocity: there are fewer places to turn for help. There are fewer prepackaged modules, and those modules may be less-tested.
I guess its natural to think that you must stay in the competency trap when exiting one of the deepest and most alive in the tech world today. But it needs not be this way. Very much unlike Java, it doesn't take months and months to gather hard-won experiences with application servers or climb mountain-high framework stacks when starting out with Rails (or Seaside+Persistance for that matter). You can try it out in a day or two and have a pretty darn good idea of what's going on. So the cost of escaping the competency trap is at an all time low.
So let's address the charge "less mature and have smaller communities". I've found that while a language community at large is a nice backup, the real importance for productivity is having a strong community around the frameworks that you pick. When people have problems with Ruby on Rails, it's very rarely the general ruby-talk mailing list that hears their pleas. It's the Rails-specific outlets.
Speaking of those, the Rails mailing list is buzzing with activity averaging 26 mails per day in December. The Rails IRC channel is ever so alive filled with between 100 and 120 developers every single day. This is a uniquely vibrant force that's able to provide end-to-end help and advice. Unlike the scattered search for assistance that's necessary when trying to combine template, web-flow, and persistance frameworks from separate communities.
This is not a charge against Python for not having a complete on Rails solution, but rather just a dissimal of the claim that the Ruby sub-community of interest should be less mature or vibrant than a comparable stack in Python. It's simply not the case.
So. Blue Sky Development woes to persue "technology choices [that] can be made on technical (and business) merit without politics getting in the way". I'd say you owe that statement at the very least a day or two outside your most immediate comfort zone. I'm pretty sure you'll find that the competency trap is not inescapable and that the fears of a missing community are expelled instantly.
Please direct comments to the version posted on the Rails weblog
December 27, 18:51 | Comments (21)
It's been far too long since the logo commissioned by the community was completed by John Hicks. But I think it was worth the wait to hold it back until the long-awaited relaunch of the Ruby on Rails website could happen. And today, it did!
The new website brings together all many web properties revolving around Rails. There's the brand new Hieraki-powered Manuals area, there's the Trac for patches and tickets, and of course we still have Instiki running the community area.
In short, it's all there. And we're mighty proud to finally be able to share it with the world!
December 23, 19:14 | Comments (17)
Berin Loritsch is thinking about how to validate his domain models in Java. He's on the right track with his intention to shun the XML morass so commonly sought by the J-people, but unfortunately his ambitions stop short. He seems to be content with merely annotating his models with the validation rules instead of actually embedding them in code.
If he were using Rails, he'd be able to enjoy specifying validation rules using actual code in his Active Record objects. The following is not even a mock-up, I literally yanked part of the Account model in that next project I'm working on:
class Account < ActiveRecord::Base
validates_presence_of :subdomain, :name, :email_address, :password
validates_uniqueness_of :subdomain
validates_acceptance_of :terms_of_service, :on => :create
validates_confirmation_of :password, :email_address, :on => :create
end
To me, this is beautiful. Programming poetry. Each method call reads like a sentence. "Account validates acceptance of terms of service on create". How can you not love that?
So please, aim higher. Annotations are a work-around for type system thats holding you back. Let it go. We'll be happy to help you transition out of the Sun and into the shade. Come join us in the Ruby on Rails community.
December 17, 16:37 | Comments (10)
The job market for Ruby on Rails is heating up. I've been hooking up companies with developers left and right. And now, it seems, even the #rubyonrails IRC channel has turned into a potential job interview. We got quite a few firm owners hanging out and one of them just hired a developer off the channel. Thijs van der Vossen writes:
This is probably the most nerdy thing I did this month: I just hired Marten Veldthuis as a freelance Rails developer in the #rubyonrails IRC channel without ever meeting him in person.
That's pretty cool! Congratulations to both Marten and Thijs for hooking up like this.
December 16, 23:19 | Comments (12)
Another huge upgrade to Rails with again close to 100 changes, additions, and tweaks. Most importantly are the new faster development environment that caches the framework and lets the application reload under both WEBrick and Fast CGI. Major is also the new breakpoints that allows you to inspect an application during execution, change the model, and resume. Additionally, we got a whole new way to do validations that extends the domain language of Rails with a wide range of new words.
The changelogs are so long I thought I'd just link to them this time:
But more importantly:
This massive release would never have been possible without the killer community hanging out at #rubyonrails. Known by such handles as noradio, xal, flgr, htonl, bitsweat, and many, many more, they really showed what a dedicated group of programmers are capable of. I'm deeply honored to be amongst such wonderful people. Thanks, guys!
December 10, 11:10 | Comments (7)
We've been hinting at it for some time, but today Dave Thomas finally committed in public, came clean, and confessed our intentions:
Just to get the ball rolling, I'm just starting to write the second book in the series (if you count PickAxe II as the first) — I'm working on an introduction to Rails.
I can't say how happy I am to be involved with a project that contains the words "book", "Dave Thomas", and "Ruby on Rails". Dave has been one of my favorite authors for the longest time, so it's really an exquisite honor to have him on board in such a significant way. Thanks, Dave!
But it gets better. Not only is there (at least one) Rails book coming out, the Pragmatic Bookshelf is launching a whole series called "Facets of Ruby" as "...a set of small, focussed, and technical books about different aspects of Ruby". Dave offers a few sample titles as to what kind of books could make it in with "Creating E-Commerce Sites using Rails" and "Migrating from Java to Ruby".
Ruby is headed for intensely interesting times in 2005. Rails will be hitting the big 1.0 early in the coming year, RubyGems will make it into the standard library, and a whole series of books will be coming out. I couldn't imagine any development ecosystem I'd rather be a part of.
And it's just the right time for you to get on board as well. The Ruby community is a delightfully friendly bunch that loves to share their enthusiasm for this beautiful and seductive language. You'll make a most welcome addition, I'm sure.
December 10, 10:44 | Comments (32)
Despite being an aesthetic who "...hate underscore characters", Ronaldo M. Ferraz has managed to fall in love Ruby on Rails:
I started to use Ruby to develop some of my Web applications, with Rails as the framework. I confess I’m more and more in love both with the language and the framework...
Rails is the best frameworks I’ve ever used. Things are always simple and intuitive, and I rarely need to resort to the documentation to understand how something is done. I had an epiphany when I saw how easily I could add authentication to an application that was already working.
Greetings to Belo Horizonte, Brazil! We're riding the Rails around the world to bring programming pleasure. Let's use the comments on this message to play with that idea. Add your name and country, if your country haven't been mentioned before (no duplicates please).
December 06, 16:36 | Comments (20)
Rails made the cover of Slashdot today with a story on RAD with Ruby. Primarily a story on how KDevelop now has integrated support for Ruby, but Amit managed to sneak in mentions of both Rails, the API for it, and my weblog. Thanks, Amit!
I'd recommend having a look at the 10-minute video, then reading Vincent's excellent tutorial, and then getting jiggy with it using Gem Rails. Enjoy!
And do bring your questions to the FreeNode channel at #rubyonrails. We're a happy bunch of almost a hundred willing to answer loads of questions with almost endless patience.
November 07, 19:05 | Comments (10)
One thing that surprised me coming to Ruby was how extremely friendly everyone was. On ruby-talk, pretty much everyone doing interesting things in Ruby are hanging out ready to pick up questions and debates when they fall within their territory.
This made the transition from the scattered and fragmented communities of PHP so much easier. One place to look for all the experts and they even bothered to answer my silly questions.
I was equally surprised by the presence of Matz. On several occasions, I'd write a simple question only to see it answered by the creator of the language itself. That's a pretty powerful motivating factor when the creator is still that involved and caring for his creation.
The best part of the friendly welcome is that it's contagious (Daughters will love like you do). I wanted to attempt the same effect with Rails, so since almost the beginning we've had #rubyonrails for the novice and veteran alike. And I try my best to spread the contagious message of friendliness and helpfulness. I doubt think the channel has ever heard the dread of RTFM!
Apparently, it's working too! but she's a girl.. talks about her experience with #rubyonrails:
The people who hang out in the #rubyonrails channel are also fantastically helpful and enthusiastic, and perhaps one of the best possible advertisements for both Ruby and Rails.
I can't say how proud of the community in #rubyonrails I am. It's truly one of the biggest assets to Rails. Just like ruby-talk (and #ruby-lang) is it for Ruby itself.
P.S.: I'm pretty excited to see what but she's a girl... comes up with in her Getting Things Done application. I'm rediscovering David Allen's approach to productivity and I'd love to see what a Rails application could do for it. About the road itself, she writes:
I’m stunned that a framework which can create something as complex and professional as Basecamp can also allow a totally green newbie like me to make something cool and functional, without making me tear my hair out.
November 07, 3:47 | Comments (12)
Michael Koziarski works for the canonical enterprise corporation: A bank. So the day job is all about Hibernate, Struts, Spring, and how to integrate that kind of infrastructure with legacy COBOL applications. Here's what he has to say about Ruby on Rails:
Rails is perhaps the most productive web development environment I’ve ever used. It’s simple, elegant and understandable. I’ve had some configuration files that are bigger than Basecamp (4kLoc)
If I were building an application for myself, or to start a web based business, I’d definitely choose Rails. In terms of time to market and maintenance costs I don’t think I could seriously consider using J2EE or PHP. Similarly, if I were doing contract development for small or medium clients, I’d strongly urge them to consider rails.
Beyond the fantastic endorsement (thanks!), Michael goes on to talk about why Rails probably isn't suitable for his work at the bank. He brings up issues about finding Ruby programmers as easily as in Java and about how DBAs won't let you get away with an easy and understandable schema. While I have no intentions of convincing Michael to push Ruby on Rails at the bank1, I'll try to give my observations anyway.
The perceived problems of finding Ruby talent
The hiring approach seems to commit Hiring Mistake #1: Hiring Tools, Not People, as Johanna calls it. After the week in Vancouver, I feel even more strongly that this is true.
Within a week, the team of three PHP programmers took in test- and domain-driven development, the Model-View-Control separation, and got fairly proficient with Ruby on Rails. Before my stay, they hadn't done any Ruby or even Rails before. I was pretty impressed with their ability to grok it quickly and further convinced that good programmers can adapt to new environments much easier than most people expect.
So stop worrying too much about finding people with x years of experience in y and look for people who are adaptable and good programmers. They'll learn Ruby on Rails easily. It's likely going to take them longer getting up to speed on the specifics of your application than adapting to the environment.
The DBA distortion filter
I have no doubt that there are DBAs out there that know a great many things about what makes a database tick, but every time I discuss their role with other programmers I get the distinct impression that their primary role is as a distortion device.
As a recent example, Jim Weirich was telling at RubyConf about how he'd submit a database schema to DBA process and pray it wouldn't get mangled too badly. Usually it would. Non-sensical prefixes would be injected, additional columns that might be useful some day would get added, and the turn around time would probably be about a week.
This sounds like a similar to what Michael is talking about:
I don’t know many DBA’s who’d let you call primary key’s “id”, or let your name your tables simply, without some whacked ‘standard’.
I wonder if there are any DBAs out there that has yet jumped on the agile principles of Do The Simplest Thing Possible and You're Not Gonna Need It. It sounds like a lot of them are still caught up in Big Upfront Design.
So maybe you need to route around the damage if distortions is truly what you're getting back? So opt out of the DBA (if he functions are characterized above) instead of "perhaps the most productive web development environment".
In the end, it's all about delivering the maximum amount of value to the stake holders. Doing so is usually fairly correlated with productivity. But regardless, I'm really happy to see that there's a discussion going on.
1 My Jedi mind tricks needs at least a few more strokes of confidence before I'd tackle an uphill battle like that
November 06, 1:59 | Comments (15)
The December issue of Linux-Magazin features an article called "Programmieren: Webanwendungen mit Ruby und Rails". I was interviewed for the magazine by the writer a while back, so perhaps that article also includes that?
If any of the German Railers have access to buy the magazine, I'd love to see the article scanned from it. I believe this is the first print mentioning of Ruby on Rails. A few more are in the pipeline.
November 06, 1:39 | Comments (1)
Jason has been interviewing a bunch of customers lately to find out more about how people are using Basecamp. These interviews have been made public in form of a series of case studies at the Basecamp HQ site.
I particularly like the story about Marie Thacker from the non-profit organization Donordigital in her Evercrack-inspired tribute to Basecamp:
Our first impresson was: Wow. Our second impression was: Oh my god, WOW. And now? We call it "BaseCrack."
Although flattery is always nice, it's even better to learn that Donordigital has been using Basecamp for more than six months and have been growing ever happier with it every day:
Basecamp has dramatically changed the way our firm gets the work done. It has introduced more efficiency and organization into our project process. We continue to use Basecamp today because, after using it for six months, we would be lost without it!
It's really energizing and motivating to hear about the effects that your software is having on people. Thanks for sharing, Marie!
November 04, 5:28 | Comments (0)
On The Rails is a new and very nice weblog tracking the learning curve of one London-based Railer "...build[ing] a large-scale production-strength Web Application". The last three days have seen daily posts, so it's looking promising indeed. Today the topic is getting authentication running using the form helpers. Good stuff!
November 03, 16:34 | Comments (10)
Topping seven thousand downloads, Instiki is now the most downloaded application on Rubyforge — the premier place for Ruby projects. The interesting thing is that the most recent version has an almost evenly divided split between .app, .tgz, and .zip downloads, which roughly translates to equal adoption by OS X'ers, Linux/FreeBSD'ers, and Windows people.
Even though I haven't had time to work on Instiki for quite some time, it's very warming to see these numbers climb higher and higher. I've talked to many people who've caught interest in Ruby after using Instiki. So as a trojan horse to increase Ruby adoption, it has been doing nicely as well.
So thanks to all Instiki users for the great interest! I hope that some day I'll be able to give it more attention again, but right now other projects take higher priority.
November 02, 9:26 | Comments (13)
Sean is a "professional Java coder" that has been working a lot with Ruby on Rails, lately. He's not particularly fond of the knee-jerk reactions coming out of the Java community in response to Trails (and the attempt to recreate Rails in Java):
And looking at the comments on TSS, I see the usual and expected condescending commentary that makes me ashamed to be a Java programmer. The most prevalent is the "cute, but too simple and can't possibly handle my manly enterprise needs" crowd. My experience thus far with Ruby on Rails says otherwise.
Before anyone asks or feels compelled to criticize me for obviously not understanding enterprise needs - yes, I do happen to deal with enterprise data. But I don't use it as an excuse to toss out new languages any more than I would insist that an enterprise system needs to stay on a mainframe.
I'm thrilled to have Sean on board. The Java community certainly has tons to teach Ruby on Rails. It already has in form of the inspirations that Rails have drawn from Hibernate, Struts, WebWork, Tapestry, and other great Java frameworks.
If only more of them could come to terms with the fact that J2EE isn't the last stop on the enterprise ride — the rails go on.
October 29, 12:23 | Comments (14)
Ruby on Rails is stirring up the waters in the Java world. Matt Raible, the man behind AppFuse (kickstarting J2EE development), has been "thinking about Rails ever since I wrote a post about it".
The thoughts must have lead to some frustration with his current environment, though. Here's his description of why doing a CRUD on a single database table would flunk any productivity test:
...if I did it right now in AppFuse's current state, it'd be a disaster... To CRUD a database table using AppFuse you have to create 11 new files and modify 5 existing files. 16 files. What a beotch, huh? If I made a video of this - it'd be 20 minutes long!
While this might make AppFuse look silly, it's really more of a symptom of the patterns we have in J2EE and how we're supposed to architect our apps. 3 tiers, test-driven, loosely-coupled and internationalized.
Compare this to the Rails approach:
class Post < ActiveRecord::Base
# All attributes are given accessors
# through column introspection
end
class WeblogController < ActionController::Base
# The controller now has actions for all
# CRUD operations and uses introspection
# to select the input fields and columns
scaffold :post
end
I'd be depressed too if my environment forced me to go through a 20 minute setup phase (and that's for an expert, I'm sure creating and updating 16 files could easily take longer for people less skilled than Matt).
Naturally, this has spawned interest in remedying the situation for Java. Enter Trails by Chris Nelson:
The Trails framework is a domain driven development framework inspired by others that have gone before it such as Rails and Naked Objects. Its goal is to make developing database-driven web applications in Java radically easier, faster, and more fun. The basic approach is to eliminate as many of the steps as we can.
While I laud the aspirations for easing the pain that is J2EE, I'd advice treating the disease rather than the symptoms. Which is of course while I keep stressing the use of Ruby on Rails instead of just Rails. Rails cannot happen in a language like Java. Approximations will try, though.
So I would recommend trying the real thing before settling with an approximation. This realization came to both Python on Rails, Rails.NET, and Active Record in Tcl.
But if you're stuck with J2EE as a fear-driven technology choice made by higher powers, I most certainly recommend checking out Trails. Chris is picking the best infrastructure J2EE has to offer and will attempt to make it fit like Rails. That's a great starting point and a good vision. Best of luck!
October 29, 11:44 | Comments (10)
Hi Matt. Thanks for the kind words. I'm honored. I'd just like to correct one misconception about Rails.
When you write "something like Rails would never fly in Java because it appears to be tightly coupled to the database" that's not really true. Active Record (the ORM part of Rails) has a database abstraction layer embedded called Abstract Adapter, which all the specific adapters are implementing transparently.
Hence, your Rails application is not tightly coupled to a specific database, but rather to the Abstract Adapter interface. Since concrete adapters are just ~100 lines of code, it's pretty easy to implement your own adapter if the current offering isn't sufficient.
The PostgreSQL and SQLite adapters were implemented one the same day by one person (Luke Holden). There's a Microsoft SQL Server adapter just around the corner (by Joey Gibson) and I've heard of people working on Oracle and DB2 adapters too.
So the only tightly coupling going on is if you write database-specific SQL. On that account, I'm actually very sympathetic to Jeremy Zawodny's Database Abstraction Layers Must Die!. Chasing database abstraction without a specific business case asking for it is just something You're Not Gonna Need and it's certainly not doing The Simplest Thing Possible.
October 28, 20:31 | Comments (16)
Lars Pind has just announced that Collaboraid has signed a big deal with a large NGO to develop their intranet using Ruby on Rails.
What's especially exciting about this deal is how fast Collaboraid have been able to adopt Ruby on Rails and secured a commercial contract using it. This shoots a big hole in the whole notion that off-mainstream languages are great barriers to entry for development firms. Here's what Lars' has to say about that:
Learning Ruby was quite easy - we were able to get started just by looking at the existing code, and the Ruby book by the Pragmatic Programmers is excellent. Rails has been similarly easy to learn, what with plenty of support from the Rails community on #rubyonrails, good introduction materials on the site, and a visit by David.
It's wonderful to see development firms like Collaboraid trumph fear-driven technology choices and work with forward-thinking organizations to get working software into the hands of users faster.
October 28, 13:29 | Comments (11)
Marten was the guy behind the short burst of Rails.NET activity. Since then, I've convinced him to convert to Ruby on Rails, get a Mac, and now he has even bought TextMate in anticipation of receiving said Mac (before Christmas).
So it seems that my Jedi mind tricks are quite operational. Muhaha. No, seriously. Welcome to a better world, Marten. You're going to love it here (as if you didn't already).
October 28, 12:35 | Comments (20)
Neil Weber seems to think that the world of tomorrow will be one where we shop for finished components, sprinkle them with business-specific attributes, and off we go with a done system in no time at all. This future has had industry-wide fascination since the beginning of time. I believe it is a false hope.
At RubyConf '04, Brad Cox (co-designer of Objective-C) blamed the apparent stand-still of the software industry on the lack of a viable commercial platform for components. If only it was easy to resell your Bill of Materials class, we could design it once and for all and merely "reuse".
In all humbleness, I think this is yet another software mirage. Software is not like hardware, high-level components can't be reduced to interchangeable IC's. Software is a collection of design decisions and where that cut should be made, which decisions we should bother with and which we shouldn't, is ever fluctuating.
The components dream is in many ways similar to the aspirations of model-driven architecture. Programming is a soon to be lost art of craftmanship, move over for industrialization!
Only it never really works out that way, does it? 4GL's and CASE tools have had their rise and fall. The point is that when you already know what you're going to build, such as a Bills of Materials system, then it's likely that you can just buy a finished system and alter it slightly. It's obvious that once you drastically reduce the problem space, pre-made applications are more likely to be a Good Enough fit.
But to think that we can reduce the problem space for information systems in general, to make it fit our existing components, is where I spot the disconnect. When I think back on the systems I've done, I can't come up with many good candidates for classes I could have carried all the way through and merely configured.
At least not on the business level. Rails is a great example of how infrastructure, that which is below our domain models, can and should be standardized. But design decisions can not follow this road.
Of course, I'm merely replaying my version of what many of the great thinkers in software had done long ago. The solution is not to embody repeating business problems in components, but to look for patterns. Gather, synthesize, and describe the forces, challenges, and good solutions that other people have come up with.
This sums up my vision for Rails as well. The border at which new functionality is accepted or rejected lies at the brink of the business domain. I don't believe that user management, access control, discussion boards, or Bill of Materials classes make for good component candidates.
I fully recognize that this might very well just be a limitation of my intellect and that wiser men truly has found the holy grail of software. But just label me skeptical on this one.
October 27, 15:03 | Comments (14)
David A. Black has just finished converting not one but two of the stable Ruby community sites to Rails. The Ruby FAQ is a searchable archive of questions and answers on all things Ruby. It was originally written in Iowa by Dave Thomas long, long ago, but due to lack of maintenance it was in bad shape and ripe for a rewrite. Enter Rails.
The RCRchive is a database for Ruby Change Requests. That is if you'd like something to change in the Ruby language, you write an RCR and the community comments. If enough people like it, Matz will have a look and a final word on whether it will go in or not. This system is now also powered by Rails.
If that wasn't enough for Mr. Black, he has also started developing the Aside application that he presented thoughts (PDF) on at RubyConf '03 in Rails. I believe it's scheduled for a demo at Seton Hall University — where David is an Associate Professor of Communication — later this month.
To top it of, RubyGarden has a new article online called Reflections on Rails where David gives his opinion on developing with Rails. Here's a taste:
It’s actually very similar, in its domain, to the feeling many get from Ruby itself. For me, it also represents a kind of enforced de-spaghettification that can only be for the good. Yes, one can write spaghetti code in a Rails controller. But the organization of one’s project itself will militate against it.
Oh yearh, David hadn't touched Rails — or any web-framework for that matter — before RubyConf '04 (which he organized with Chad Fowler and others). So all of this Rails activity has happened within the last three weeks or so. Now I'm the one impressed.
October 26, 11:45 | Comments (32)
I think more customers are choosing technology out of fear than good is and many developers are doing a shoddy job standing up to those fears. Customers fear that a world of risk and hurt will come unless they choose "a standard", like Java, C#, or PHP, and by silently bowing in agreement, developers are selling the customer short.
In the advent of highly agile and open source frameworks such as Ruby on Rails (and there are many others), it has never been easier or safer to "experiment" with new technology. Unlike the days of old, it no longer requires an engagement with a vendor and a blind bet on his treasury box of magic tricks. Vendor has turned community and the treasure box has turned transparent.
From the feedback I'm getting, most developers have a pretty good grip on how Rails is going to help them within a few hours. After about a day they're usually pretty convinced. And after a week, all I have talked to are turning out working software at high velocity.
With the barrier for examination so incredible low, there's simple no excuse to instinctively reach for the bow as the first response to fear. As much as it delights me to read Matt Raible write about his enthusiasm with Rails:
After watching the video this morning, it's enough to make me want to become a Ruby developer and use Rails to develop my next webapp.
I'm am equally disappointed by his defeat by default when he his mind wanders on to the possibility of actually using this stuff:
Then again, Ruby probably doesn't pay the bills nearly as well.
So maybe that's just Matt, right? Wrong. This depressing pessimism is pervasive. David Crow chimes in with enthusiasm:
Matt Raible points me to the Ruby on Rails quick setup video. Damn, that is impressive! After spending all weekend fighting with data objects and PHP, I need to spend more time with Ruby and Ruby on Rails.
And then follows the "self-evident truth" of Matt with an immediate dismissal for commercial viability:
Matt's got it right it might not pay the bills, but it looks like I can learn something.
As much as I commend both guys for their interest, kind words, and real enthusiasm, I'm frustrated beyond belief by their lack of energy to fight inertia. How can there ever be a better tomorrow if you're not even willing to contemplate fighting for your enthusiasms of today?
If I do anything of significance with Rails, I hope more than else that it's broadening the horizon of customers by inspiring developers to acquire the will to push for their beliefs and enthusiasms.
Customers are sold short when we as developers accept fear-driven technology choices.
October 26, 0:55 | Comments (7)
As earlier mentioned, the fine chaps at Combustion Labs invited me to come to Vancouver for a week to introduce their team of PHP programmers to Ruby on Rails.
Now considering that all three companies I've done Ruby on Rails consulting for has either already switched or anticipates to switch to the platform, I feel that the pressure is on to keep the winning streak going.
And I wonder when the bag of tricks is going to run out, so it won't be possible to dazzle guys like Lars Pind of Collaboraid who noted this after I visited:
Watching David demonstrated to me directly, visually, personally, a very productive way of working that broke with a number of traditions we've held for years...
So to ease my mind, I'm planning to think of stuff I'd like to do on whatever little spare time I might have. Do you have any good suggestions?
I'm flying in on Sunday and going out on Saturday. (Going out as in flying to San Francisco for Building of Basecamp III — do consider signing up if you're in the area, there's still a few seats left).
October 26, 0:15 | Comments (11)
Dave Thomas has been touring his Ruby talk ever since his first stop at Amazon. For his on-the-spot programming, he has been using TextMate about which he notes: "...this editor just works for these presentations". Mighty flattering. But Dave has even more up his sleeve.
For the Ruby tutorials, he has been using Rails to implement his Amazon application example. I'm not sure how many times he has run the presentation, but something about the feedback he's getting must be pretty convincing:
It’s generating some buzz—I think Rails may well be the framework to break Ruby into the mainstream.
I couldn't ask for higher praise or a greater vision for Rails.
October 25, 15:09 | Comments (0)
It's been fifty days since our last confession, so it's no wonder that this outpouring is by far the biggest yet in Rails history. It's absolutely packed with goodies ranging from a whole new framework for sending email to the smallest new alias for an existing method. In total we're just shy of 100 additions, changes, tweaks, and fixes.
This is also the release with the highest number of contributors. I've counted at least 23 different people with patches in Rails 0.8 — and there are many, many more responsible for suggestions and bug reports. This is truely turning into a community movement and I'm extremely pleased to be the steward for it.
Read more about the changes:
Get it all from the Rails website, talk it up on #rubyonrails (FreeNet). Or even easier, just do "gem install rails" (or "gem update" if you're already running on Gem Rails) — you'll automatically install all the newest versions of the required dependencies.
October 23, 17:30 | Comments (18)
Despite my obvious OS X/*nix bias, Rails works great on Windows. It's really easy to install as well thanks in large parts to the One-click Ruby Installer by Andy Hunt and Curt Hibbs. And to prove just how easy it is, Tobias Luetke has created three movies showing you every step of the way:
- Lesson 1: Setting up Ruby, RubyGems, and getting Rails loaded
- Lesson 2: XAMPP installation and database integration.
- Lesson 3: Making the jump from WEBrick to Apache.
Inspired to follow Tobi and interested in demonstrating some other part of Rails in a movie? Please do have a look at Rails Academy.
October 23, 2:21 | Comments (0)
Sean is yet another Java programmer burning the midnight oil with Ruby on Rails. Among many kind words, he offers a simple example on how to beat the dreaded 1+1 problem that a naive ORM will kill performance on any iterations with.
However, that doesn't solve the 1+1/iteration problem because this will face the same issue. But the solution is much simpler and elegant. I modify the Account class to:
class Account < ActiveRecord::Base
has_one :owner
def self.find_with_owner
find_all(
'select a.*, o.first_name, o.last_name ' +
'from account a and owner o ' +
'where a.owner_id = o.owner_id'
)
end
end
Welcome on board, Sean. I hope the productivity gains you've experience will allow that midnight oil to be replaced with a day-time engagement.
P.S.: There's an expanded discussion of this piggy-back technique on the Active Record wiki.
October 20, 13:37 | Comments (5)
RubyGems is one of the best things that have emerged while I've been Rubying. It's the equivalent of CPAN + apt-get as a repository for Ruby libraries and applications. It has been gaining speed fast and currently holds 111 distinct gems, which is about 10% of the number that age-old Ruby Application Archive has in store — impressive and fast take up!
Even more impressively, though, is the uptake among users. Chad has just announced that more than 5,000 copies of RubyGems have been downloaded and more than 20,000 gems have been retrieved! I'm incredibly proud to see that Rails is responsible for at least 1/4 of all gems downloaded.
I can't wait until RubyGems is part of the standard library. Now that the release of Ruby 1.8.2 seems to be taking longer than first anticipated, it would be fantastic if RubyGems made it in before release. Are you listening, Matz :)?
While we await inclusion in the standard library, let's make the world of gems even more exciting. I for one would bless anyone that would make these libraries available as gems: FastCGI, MySQL/Ruby, Posgres/Ruby. Those three are currently the only non-gem libraries I have installed.
October 19, 22:58 | Comments (5)
Jason does a great job describing some of the models we're currently contemplating in response to the growing interest in a hosted version of Basecamp. It gives a good deal of insight into how serious we take the whole No Human Scaling aspect of Basecamp.
We don't want to grow a company of 25 people around Basecamp even if that looks like a very possible road forward. Instead, we're sticking to our design of constraints and are thinking about how to leverage those best.
I particularly like the ideas of auctioning off just a handful of installable versions. We have quite a few large and very interesting companies on the notification list for an installable version. Just how much could a program like Basecamp be worth to have inside the firewall?
At the other end, I'm attracted to solution for dealing with upgrade cycles: Don't do them. Sell a v1.0 with all the bugs and inefficiencies that it might very well have. And then give people another chance at v2.0 — but no in-betweens. I wonder if it would work, though. Even with everyone as consenting adults. Would having the source available and being able to do internal improvements help assure people of the viability?
Business models for open source
While we're contemplating what to do in the commercial world of Basecamp, I'm at the same time seeing a number of opportunities arise for Rails. Just recently, I signed on to help Combustion Labs in Vancouver explore Ruby on Rails for a week.
That's the traditional open-source service model. Give away source and software, sell services. But there are many new models popping up. One of them is doing hosting, which of course is exactly what I announced earlier today.
Partner with a hosting company and make sure that they Just Work with your software. A lot of the pain in open sourcing is getting the stuff up and running. If you can pay something reasonable to have that all taken care and support the project, then what's to think about?
On top of that, there's of course taken either commercial sponsorships for feature improvements (I was talking to a guy at RubyConf about adding integrated Web Services support to Rails on that model) or raise funds directly from the community. A few of the guys from #rubyonrails talked about how they'd like to raise funds to allow me a month off to improve the documentation.
It's a brave new world for funding of great software and ideas outside of the traditional channels.
October 19, 15:26 | Comments (10)
TextDrive is an incredible cool hosting firm founded to support open source developers and projects by letting the users buy top-notch hosting straight from the source. They’re already home to Dean Allen of TextPattern, Rickard Andersson of PunBB Noel Jackson of Photostack and Matt Mullenweg of WordPress
On top of being in excellent company, Ruby on Rails is exceptionally well-supported on TextDrive. You’ll always have the latest version available as GEMs, you can keep your code under Subversion (and show it off with Trac), and have your choice of PostgreSQL or MySQL for the database.
Equally important: By being hosted on TextDrive, you’re supporting Ruby on Rails development with 50% of the profits from your plan. It won’t take many people before that turns into a very meaningful contribution that will allow Rails to go above and beyond. Be among the early adopters and you’ll be able to tell your grand children that you helped Rails reach world domination :)
Read more: TextDrive Hosting with Ruby on Rails
P.S.: These guys already hosts MacroMates.com, RubyonRails.org, and will soon do Instiki as well. They know their stuff.
October 10, 18:02 | Comments (18)
October 10, 0:33 | Comments (10)
Jason Fried attended Web 2.0 this week and while the enthusiasm for the next major version of the web was great, some things sounded an awfully lot like we were just rebooting the cycle:
But, I’ve gotta say, it felt a lot like 1999 again. Tons of VCs floating around. Tons of talk about Round A and Round B funding. The word “millions” was overhead in more conversations than was comfortable. Too many smiles and not enough skepticism.
Amen. What's so freaking special about Web 2.0 is that you don't need to let the organizational scaling get ahead of the business. All this newfound computing power, cheap bandwidth, and powerful technology are enablers for postponing the growth of heads:
So, my advice to these new companies with their new products and fresh-faced enthusiasm… Keep it small. Start small and stay small. Borrow from yourself before you borrow from someone else. You can have an impact with just a few people. You can build great products with a small team. You can do it on your own. You can.
Let's party like it's 2004.
October 09, 23:35 | Comments (16)
We've been pretty tight-lipped about the numbers on Basecamp, but we're now going to push two of them because we just couldn't stay quiet any more. So here's the official addition to the Basecamp website:
Used by tens of thousands of people in over 40 countries!
From individuals managing their home improvement projects, to professors managing their classrooms, to small and big businesses managing their client and internal projects, everyone is using Basecamp to keep their projects and ideas organized.
We're extremely proud to have gotten this far with a team of what amounts to about two and a half full timers. What's even more amazing is that we've been able to scale without adding a single person. That was one of the goals from day one: Build a product that doesn't require organizational scaling.
If you want to know how we did it, you really should consider attending the third Building of Basecamp. It's on November 9th in San Francisco. We're teaming up with Adaptive Path who are going to talk about Building Blogger the day before.
For the last workshop, people gave us a 4.76 out of 5 rating on whether they thought it was money and time well spent.
Some of the praise from attendees went:
Continued...
October 09, 2:26 | Comments (9)
Presenting in front of a tough crowd of mostly C/C++ and Java guys, I'm told by my robot spies that Dave Thomas did very well at Amazon. So congratulations on that!
When you're used to dealing with 32 million customers, I guess you do develop somewhat of a thick skin towards claims from new technology, so that skepticism certainly did put Ruby on the spot a few times. But once Dave drew in the examples with the Amazon domain, the crowd was somewhat more easily swayed.
Erik Benson snapped this shot using his camera phone of Dave going on about Active Record:
If there's anyone in the Amazon camp that were enticed by that last section on Rails, don't hesitate to drop me a line.
UPDATE: Erik Benson has posted a first-person report on the presentation.
September 30, 13:35 | Comments (1)
Or how I almost missed the first day of RubyConf. See the original flight to Newark operated by SAS was cancelled. No reason given, of course. So an hour in cue for rebooking and those were her words: "That's not going to happen". That being a touchdown in Washington DC tonight.
While the customers in the other line went with a threat strategy, I tried to go with sympathy: "But I have a conference starting tomorrow at 9 am. I'm speaking there." No reply. Keys being typed at dizzying speeds. Outlook not particular encouraging — the guy before me had just been told to stay another day in CPH.
Then, as had it been the plan all along: "You're traveling over Frankfurt. Departure is at 14.10."
I choose to believe it was my good-spirited, charming nature that did the trick. In any case, I'll be in Washington DC at 19.45. Who in the RubyConf camp are up for a late dinner at nine-ish?
September 22, 17:12 | Comments (7)
Despite having a presentational video on Rails that constructs a blogging system in less than 10 minutes, Loud Thinking is still chugging along on a Moveable Type installation that is years old. An installation that does neither Textile nor run of a database for integration with other scripts. It's one of those always-on-the-todo-list kind of things.
Thankfully, not all Rails developers are as slow as me to get their weblog running on Rails. Marten and Sarah are both running a home-grown weblogging system built with Rails on Standard Behavior and One Before, respectively.
Both systems look really nice and sports pretty designs on top of it. Sarah's system even has a nice statistics section to get an overview of how the blog is doing.
Hopefully Sarah (or Marten) will get around to open sourcing of her system, so there's a base to offset my eternal procrastination in getting my blogging on Rails going.
UPDATE: John Wilger also just relaunched his blog ThatWebThing that now runs Ruby on Rails as well.
September 13, 14:14 | Comments (23)
Jim Weirich, of Rake and RubyGems fame, has started on a wonderful application for planning eXtreme Programming projects called Story Cards. He's been doing it all with Ruby on Rails and has in just over 1KLOC developed a very functional creation that's already used to plan Rake 0.4.8, Story Cards itself (0.0.2), and Ecal (calendar system for tracking meeting room usage for Children’s Hospital).
Jim has also created a RubyForge project for Story Cards that allows you to check-out the source and have a look. Since this is categorized by Jim himself as pre-alpha software, you shouldn't expect a one-click install, but it's very cool to have a look over the shoulder this early in the game.
Massive kudos to Jim for embarking on this cool application and sharing it with the world this early. Thanks!
September 06, 22:15 | Comments (9)
Since my visit back in June, the three ex-amazonians from Seattle has revealed their identity as Josh, Daniel, and Erik. They're now working full-time on The Robot Co-op and are looking to fill no less than four technical positions.
The exciting part of this job announcement is that The Robot Co-op will be starting their first project using Ruby on Rails. So if you're interested in working commercially with Ruby on Rails alongside an awesome crew of clued-in people, this is stellar opportunity.
P.S.: This is the first announcement from a series of commercial opportunities that's growing around the Ruby on Rails platform. I've been in contact with a number of companies that are interested in launching projects of their own or doing consultancy work with the platform. Hopefully I'll be able to announce the second soon.
September 05, 20:10 | Comments (8)
Another important Rails release sees the light of day. If you're already running on Gem Rails, all you have to do is gem update, and you'll be running all the latest stuff. You gotta love those RubyGems.
P.S.: If you're interested in learning more about RubyGems, you can read chapter 17 from Programming Ruby, 2nd edition. It's available free through the good grace of Dave Thomas and Chad Fowler.
September 04, 11:38 | Comments (18)
informIT just started a new multiple-part tutorial on how to use Hibernate (the top dog in Java ORMs) to create a domain model for a small book shop. By the end of the second XML file, I was ready to cry for mercy. So I did and Active Record answered:
class Book < ActiveRecord::Base
belongs_to :publisher
has_and_belongs_to_many :authors
end
class Publisher < ActiveRecord::Base
has_many :books
end
class Author < ActiveRecord::Base
has_and_belongs_to_many :books
end
Whups. I think we just got ahead of ourselves. The model above won't materialize in the Hibernate tutorial for another few installments. For the first one, they just got Book up and running.
But since it took all of five seconds to describe the domain (please note that were assuming the existence of a database schema, just like the Hibernate tutorial), let's give a few examples on its usage as well:
pruby = Book.create(
"title" => "Programming Ruby",
"price" => "20",
"published_on" => Date.new(2004, 10, 3)
)
pruby.title # => "Programming Ruby"
dthomas = Author.create("name" => "Dave Thomas")
pruby.authors << dthomas
pruby.has_authors? # => true
pruby.authors.first.name # => "Dave Thomas"
pragshelf = Publisher.create(
"name" => "Pragmatic Bookshelf")
pruby.publisher = pragshelf
pruby.publisher # => "Pragmatic Bookshelf"
publisher.has_books? # => true
publisher.books.size # => 1
# Say "Hi, Dave Thomas"
puts "Hi, " + publisher.books.first.author.name
This is not pseudo-code. It's how most of the domain logic in Basecamp and other Rails applications work. Why does it how to be harder than this?
If you're ready to get outta dodge, please do have a look at Rails. It's a web-application framework that includes Active Record and its sister Action Pack. I wouldn't recommend it if you're trying to make a living as a tutorials writer and you're paid by the word, though.
Manual trackbacks: Rails: 1 vs Hibernate: 0
September 04, 10:58 | Comments (13)
Dave Thomas has completed the much anticipated second edition of Progamming Ruby. From my initial dabbling with the language and to this very day, Programming Ruby has served as my bible on syntax, style, and usage. It's always been the first book, I recommend to people just starting out in Ruby. And by the looks of the sample chapters, the new edition will only entrench that position.
Dave Thomas and Andy Hunt also deserve so much thanks for releasing the first edition of the book online for free. It's time to repay their generosity. Buy this book on the release day of October 3rd. And prove to publishers and authors that Ruby is a growing language that deserves more books.
Who knows, perhaps it'll encourage the writing of another book. You know of which I speak.
September 03, 13:53 | Comments (22)
Richard Dale is one of the developers on the KDE project and he's also wondering why the wiki revolution hasn't yet swept the world:
[Instiki] is simple to use software, that is also powerful, and it would scale easily to serve multiple users where my beloved Acta wouldn’t. Why do people still use word processors, rather than wikis, when they rarely print anything out on paper? I don’t know..
I couldn't agree more. I wrote my bachelor's degree together with three companions using Instiki and LaTeX. We used to have a good laugh at the other study groups still stuck struggling with Word. Why would they slave so endlessly for that beast? Inertia, ignorance, Stockholm Syndrome?
Ready to ditch that word processor of yours? Give Instiki a try.
September 03, 13:23 | Comments (6)
With 438 downloads of the GEM version and 1581 downloads of the zip/tgz version, Rails has climbed above and beyond two thousand downloads. This is roughly within the first month of release, so quite an achievement. In addition, the Rails packages take the second (AR), fifth (AP), and sixth (Rails) spot on the top 10 list over Ruby Gems.
Oh, and there's a new release coming shortly with a lot of funky goodies.
August 30, 0:56 | Comments (6)
Matt, the creator of MetaFilter, is finding out just how powerful a wiki can be as your personal notebook. I was very pleased to read that he picked Instiki, which he calls "an actually useful wiki":
Last week I got into the habit of launching [Instiki] and using it instead of having a BBEdit todo.txt file on my desktop. As a private scratchpad, it's absolutely fantastic. Over the past few days I've built out my ToDos into a pile of organized, hyperlinked pages that are useful to have around.
He's not alone, either. More four hundred out of the three thousand downloads of Instiki has been for the instant-on OS X version. Are you collecting your thoughts in Instiki yet?
August 29, 12:21 | Comments (14)
James Prudente has been blogging his learning curve with Rails. Despite his initial problems with full-fledged debugging screens and the pluralization rules, he's now completely sold after ten days of development:
(18 Aug) Now that the installation is over, I can get down to the business of evaulating if Rails is going to be my new web appiclation framework...
(19 Aug) The more I look the more I appreciate all the thought and design that has gone into Rails...
(21 Aug) It's official, Rails owns. Bye Bye PHP. Sayonara J2EE. Arrivederci ASP.NET. Hello future. I've reimplemented a bunch of my latest project in Rails, and all I can say is that it's so tight, clean, and beautiful that I must use it for all my web development...
(28 Aug) I've been working with Rails for 10 days now, and there is no looking back. I've completely converted my newest project to Rails and am nearing a beta version...
It's so nice to read accounts like this. James started out on Rails without knowing Ruby (like many others) and has been completely taken by the combination of Ruby on Rails in such a short period of time. Thanks for sharing, James!
August 27, 23:59 | Comments (3)
I'm stunned. Dave Thomas from the Pragmatic Programmers just informed me that him and Andy are getting behind the community fund raiser for the visual identity for Rails. On behalf of the Pragmatic Bookshelf, they'll be doubling any contribution made by the community!
Since the bar is already at $495, it means that we just have $5 to go to reach the target of $1,000. What an incredibly feat and testimony to the power of open source communities.
I'm really moved that Dave and Andy are taken notice of Ruby on Rails in such a significant way as to pledge $500 in its support. I can't thank you guys enough. But I'll try to return the favor by urging anyone doing Rails development to immediately pickup the Pragmatic Starter Kit. A three-volume series on version control, unit testing, and project automation. Topics that any Rails project would do well to master.
And did you know that the last touches are being put on the 2nd edition of Programming Ruby? It was the first edition that got me into Ruby in the first place and its still the book I use most in my daily work. You need this book if you're thinking about or already doing Ruby. Whether or not it's on Rails.
*UPDATE:* The last $10 was donated. The goal of $1,000 has been reached. It took 7 hours.
August 27, 23:48 | Comments (10)
With more than 1,800 downloads and an incredible amount of positive feedback, Rails has had an unbelievably successful first month in the wild. So I am thinking that Ruby on Rails might be on to some thing. If this is the first month, how will things look in three? In six? At the release of 1.0?
I'm betting on "pretty darn good", so I am wondering on what additional steps I could take to spread the gospel. The first will be the formation of a visual identity for Rails. It needs to look as good as it feels. And for that to happen, it needs to be done by a pro.
Enter the fund raiser: Rails Visual Identity. I'm thinking that $1,000 will hopefully suffice to get a really cool logo done. And what better way to unite the Rails community than doing a shared payment.
Just hours after the page was announced, it's already at $495!
August 20, 23:42 | Comments (7)
Let me underline one thing: There are surely many great Java programmers and there are surely many great ideas coming out of the Java community. It's just that when you read something like this from Sachin:
Java has considerably fewer surprises and prefers not to add complexity to the language for rarely used features thereby resulting in a language where you cannot really make your friends go ga-ga at amazingly brief programming constructs... This is probably the biggest reason Java is un-cool. It's too easy (although programming or software development remains as tough as ever).
It's hard to know whether to laugh or cry.
August 20, 20:59 | Comments (3)
John Lim writes why his companies love using Oracle:
People say that open source software has great technical support - yes it is good, but what our business needs more is marketing help, which Oracle provides. Using Oracle makes our products more attractive, as customers like to feel that they are running large and powerful applications on their systems (and it's true, we aren't kidding them). MySQL and PostgreSQL don't feel sexy to our clients.
This reminds me of a question I got during the colloquium at RUC about whether I could ever see a bank using Rails. No, I can't. Neither could I see any other corporation where the signal value of their technology choices is more important than whether the software actually works.
"Nobody ever got fired for buying..." is the name of the game. Oracle, like J2EE, is a great word to end that sentence with. Who cares whether the software costs more, is never finished, or crumbles?
August 18, 2:31 | Comments (13)
Chris Nelson was recommended by Jim Weirich (the Rake star) to have a look at Ruby on Rails at a Cincinati Java Users Group meeting. When he did, this was what he saw:
[I]t's called Ruby On Rails. And gosh darn it, it's just too darn good. Makes me sick. I'm no Ruby guy, believe me you. I don't go in for that alternative language kind of thing one bit. Unamerican if ya ask me. But confound it, I was blown away. Just watch the video ok.
Naturally, Chris has some concerns after watching the video. He's holding them dear as they're the only thing keeping him from "...spend[ing] every minute of my time at work crying while I code". I'd advise a big box of Kleenex for work tomorrow, Chris.
(UPDATE: Avik, another Java guy, discovers Ruby on Rails)
Continued...
August 17, 13:23 | Comments (0)
Chad Fowler is one of the masterminds behind the RubyGems packaging scheme and library repository for Ruby. He's also the founder of RubyCentral, alongside David A. Black, which is the organization behind RubyConf. Oh, and he's pretty found of Rails, too:
Writing database code is even worse. For the basics, you don’t have to do any coding. What kind of sick mind was behind ActiveRecord anyway? How are we programmers supposed to stay employed if there’s no work for us to do?
The most frustratingly boring part of all of this is the documentation. David’s got videos, wikis, tutorials and demo apps (all on www.rubyonrails.org), which means I didn’t get the fun of having to wade through Rails’ source code every time I wanted to implement a new feature for my web application.
That's just a few of the flattering words Chad chose to accompany his declaration of Rails as the RubyGem of the Month. Thanks, Chad!
August 16, 19:49 | Comments (8)
Paul Graham follows up on his original missive towards the Java drones and companies of the world with a further explanation of The Python Paradox:
I'll call the Python paradox: if a company chooses to write its software in a comparatively esoteric language, they'll be able to hire better programmers, because they'll attract only those who cared enough to learn it...
Only a few companies have been smart enough to realize this so far. But there is a kind of selection going on here too: they're exactly the companies programmers would most like to work for.
Developing successful software is much cheaper and easier if you're able to attract the best of brains. Programming projects scales rather poorly, so if you're able to do the same with less people, you'll experience non-linear benefits.
So what are you waiting for? Pick a dynamic language like Ruby, Python, or Smalltalk, hire from the grade-A talent pools, and get a shot a competitive advantage.
August 16, 12:44 | Comments (13)
Derek Sivers seems to really like the projects I've been involved with for the past nine months:
My award for beautiful coding goes to David Heinemeier Hansson... [Talks about Instiki, Rails, and Basecamp]... Absolutely brilliant. All of it. Did the beautiful language of Ruby inspire his style, or was it just a match meant-to-be?
I can't believe the stuff that David's done, and this is all just in the last 9 months or so!I think he's my new favorite author.
How intensely flattering. Thank you, Derek! And yes, I owe much of it to Ruby. It has indeed unleashed an amazing amount of creative energy. I never, ever thought programming could be this fun, challenging, and capable of teaching me new things daily.
Programming in Ruby inspires you to craft beautiful code. Then mold it further to become more elegant still. I recommend anyone who has the faintest interest in programming to give it a try: Getting started with Ruby (and if you're into web-app programming, you'll want to continue to put Ruby on Rails.
August 16, 0:53 | Comments (14)
Marten Veldthuis was already well underway with a .NET version of Rails before he stopped to give the real thing a second try. Here's his conclusion after giving it a proper look:
So my experience has been overwhelmingly positive, and I can only recommend everybody with doubts to just try it (and try it seriously… start work on a real project, instead of doing only two steps beyond the basic weblog demo like I did initially).
I'm thrilled to see that Martin is coming over to the existing Rails community instead of making a language fork. Glad to have you on board! No doubt, the speed of development helped Martin make the switch:
From the moment I started, I’ve been doing the cycle “look up stuff, program stuff". However, this cycle does not seem to slow me down, I’ve been working at nearly the same speed I used to be at on ASP.NET/C#.
Consider how fast you'll be able to go when you got a week or two of experience under your belt. Then consider how fast you'll be able to go in a month. Then in three months. Rails makes you go fast really quickly and then keeps on accelerating.
Oh, his adventures with Ruby on Rails have even inspired Martin to think thoughts of FreeBSD, Apache, and MySQL as a replacement for his Windows 2003 with IIS/MSSQL. Add to that, he's getting an Apple laptop as well. I couldn't think of a nicer ride out of Redmond.
August 12, 23:36 | Comments (11)
Dmitry V. Sabanin recently announced his PrettyException project on ruby-talk. It's an attempt to turn web-app box from black to white by making the internals more transparent. About his own usage, he said:
I find it very useful when you develop something for Web and you don't have access to apache logs. For myself, I'm using PrettyException when I develop a web site, and when it's time to release it, i turn PrettyException off.
This is indeed a critical component of any web-application framework. How easy is it to spot an error, how much information are you supplied to locate it, and how much time does the fix-test cycle take.
Continued...
August 08, 10:16 | Comments (4)
I'm really on vacation, but through my 2kb/sec GPRS connection from the mobile phone, I spotted that an amazing milestone has been reached for Rails. In the first two weeks since release, Rails has been downloaded more than 1,000 times (the RubyForge DL count + 35 due to a reset).
I'm extremely pleased with its sweeping uptake and with all the lavish praise it has gathered already. Just this morning, I received the following email from Gleb Arshinov:
I write systems code (C++, database kernels, app servers, http proxies, etc.) for a living, so web development is not usually my cup of tea... I've been helping a friend to get a custom CRM system for their office. I wrote up an MRD and was looking to offshore the development.
Then Rails came along, and now I am writing it myself :-) It's too much fun, and I think I can get it going in less time that it would take me to manage somebody else's work. That's considering that I don't know Ruby. I mean, I have a pilot running and I still don't know Ruby — I barely had to write any code :-)
So, cudos!
That certainly made my morning!
Continued...
August 06, 23:08 | Comments (15)
Mauricio Fernández has been working on Ruby Production Archive as an alternative packaging scheme to RubyGems. I'm still more of a GEM-guy myself, but Mauricio does deserve recognition for packaging both Instiki and Rails for RPA. Especially the latter is quite a task (which is why I haven't done a GEM for it myself, yet).
On top of that, Mauricio has taken a cue from the success of the 10 minute video for Rails and done a RPA video for installing Rails. It's pretty cool. He taped the whole thing through his prompt using Links to access the web-server. Very retro.
Cheers, Mauricio! And thanks for hanging out in #rubyonrails helping people who wants to use RPA. You'll have a lead on a packaged Rails until I get my own GEM done.
August 06, 15:47 | Comments (11)
Rails is closing in on the first thousand downloads, which means I've been getting a ton of good feedback on how Rails could be even easier to use and setup. I've taken all that to heart and improve the framework in a number of significant ways.
So if you've been holding back on having a look at the Ruby on Rails phenomenon, now is the time to get on board. As Chad Fowler noted yesterday after getting his first Rails application running: "This is the police — drop the J2EE and back away slowly". And as former CTO of GE Appliances in Bangalore and co-author of Professional Apache Tomcat, he should know.
Come on, then. Have a look. You'll be up and running in a few minutes, producing real results within hours, and hanging out with the, at times, 40+ crowd on #rubyonrails in no time at all.
August 04, 23:52 | Comments (25)
Jogin is turning out to be a guy of my liking. First he picks my platform of love, then he picks my language of love:
Ruby has two things going for it which makes me (want to) choose it over Python for web development. The first thing is that it's really and truly object oriented. Python's OO feels kind of like an afterthought, most likely because it is one. And even though the OO aspect is glued onto Python rather neatly, it doesn't permeat the language like with Ruby.
But, even still, that doesn't level Ruby with Python. What settles the matter is Rails. I'm willing to code Ruby, even though I prefer Python, because of Rails. If everything falls into place, I'll be doing a respectable amount of development using Rails in the future. Assuming that I'm not hit with a violent jolt of aspiration resulting in something similar in Python.
UPDATE: Ben Stiglitz also had a similar note saying "...a lot of people are moving over to Ruby because they want to play with Rails".
August 04, 0:51 | Comments (10)
Even before the complete Ruby on Rails experience was unveiled, the OpenACS guys were longing to get Active Record running in Tcl. Shortly after the experience went public, Pythonists were considering the making of Python on Rails.
Now, not much more than a week after the first release, M. Veldthuis wants to have Rails.NET, or Track as he has chosen to label it. It's certainly flattering if only a little befuddling: Why not try the real thing out for size first? Ruby on Rails is here, today, offering the rapid development experience free of charge.
If it's the language, Ruby, that you have doubts about taking on, I promise you it'll be a lot less work to Getting Started with Ruby and running on Rails than it will be to recreate the sensation in another language on another platform.
Heck, I was just writing the other day about Apple's Ben Stiglitz who picked up Ruby in a week and wrote the solid beginnings of a bug tracker in Rails within three hours.
August 04, 0:26 | Comments (22)
My proposal for a Ruby on Rails presentation at RubyConf has been accepted! I'm going to be sharing panel 4 early on October 2nd with Patrick May and Bill Atkins.
Continued...
August 01, 14:22 | Comments (10)
While wikis are great, they're perhaps not always the best for bug tracking larger projects with lots of testers. So the constituency in #rubyonrails have been petitioning for a switch to a real bug tracker.
While I was thinking about how to go about that, Ben Stiglitz already had an early skeleton running. Within three hours. With no prior Rails training. After having played around with Ruby for one week.
Needless to say, I was pretty impressed that he was able to pick up Ruby on Rails in such a short time. Additional respect for being a PHP refugee like myself.
If I can do it, he can do it, then you certainly can too! Sign up for amnesty at Getting started with Ruby and then revel in your liberation with Ruby on Rails.
August 01, 0:26 | Comments (18)
I've received an incredible amount of positive feedback on the 10 minute video of Rails. It's a reasonably comprehensive first impression (despite showing just 5-10% of Rails) delivered to you for no work at all. Forming a similar impression on a framework that just does text documentation and the odd example is a much more time consuming effort. Straight to the "I'll look at this later" pile.
That's why I've started Rails Academy as a place to hold future, more in-depth, video tutorials on Rails. I even got my Sony microphone hooked up to the stereo now, so that should end my brief career in silent movies.
But more importantly, I hope to ignite a general trend within the programming community at large and Ruby in particular: More showing, less telling! Capable programmers do most frameworks, projects, and languages much more justice than a dry piece of text can. I recognize that some frameworks and languages might be better suited for this than others, which is why I'm focusing mostly on Ruby where it's actually possible to show-off really cool stuff in no time at all.
On that note, I'm thrilled to see Mauricio Fernandez pick up the ball and show off his packaging system for Ruby in a series of gif anims. The fact that he chooses to display his wares using Instiki and Active Record made no difference in my appreciation (okay, just a little, then).
P.S.: I've been doing my own recordings with Snapz Pro X. While it's a great tool (albeit with a slightly weird interface), it does produce .mov files, which have proved somewhat hard to digest for the OS X-challenged people out there. Anyone who wants to donate me a copy of Camtasia will hence be much cheered by all since that'll allow me to convert those mov files to Flash, which everyone should be able to see (check out this old, old sample I did while still developing Rails).
July 30, 14:27 | Comments (3)
The fourth annual RubyConf will be happening from October 1st until October 3rd. I expect to go and have just submitted by extremely brief proposal for a full-length talk on Rails:
How Rails was grown on a diet of real problems and influences, attracted an audience by being concrete, and still kept a generic core. Will show off the Rails web-framework and discuss implementation details.
Hopefully it'll be accepted. If it does, you'll be able to hear me talk about Rails twice on US soil in the coming months. Starting with The Building of Basecamp in Chicago on September 17th and then RubyConf in Chantilly (Virginia) at some point during October 1-3.
If it's possible, I'll attempt to get a BoF spot at JAOO, too. (Anyone know how?)
July 29, 22:51 | Comments (7)
Statements like this is the reason I love picking on Java programmers:
The scripting languages like Perl, Python, PHP, and Ruby are useful for quickly hacking up a Web site. However, as Fowler's "Principles of Enterprise Application Architecture" notes, they are pretty much limited to the "Transaction Script" model.
The shear amount of arrogance and ignorance contained is staggering. It would appear as if Doug is simply playing word bingo and called it when he spotted that "Transaction Script" and "Scripting Language" were close enough.
There is absolutely no inherent connection between the two terms (neither does Fowler attempt to make one from page 110 to 115 of PoEAA that talks about Transaction Scripts — he even uses Java as the example!).
In Rails, as an example, we're using the Active Record pattern (relieved of the chief concerns with the original pattern) to facilitate the building of a strong domain model. We're using Action Pack, which is founded in the gulf between Page Controller and Front Controller along with a Template View and use of Helpers.
But this is not about name dropping patterns. It's about people working under a Sun that has all but blinded them from an outside world that doesn't appreciate the masochistic fascination with hard, manual labour and the real sweat it breaks. And Dough isn't even affraid to admit it:
Quickly? J2EE isn't really about building things quickly
I guess that's the self-referential reality that kicks in after you've spent another day working the nine to five in a XML configured and compiled sweatshop.
And the call to authority really underlines the audacity of exhibited. Martin Fowler is himself a big Ruby enthusiast from all that I've read, been told, and talked with him, so it's particularly ironic to see his name abused to spearhead an attack on the language.
P.S.: Unlike Graham, I don't necessarily think it's all Java programmers that share this combination of A and I, but it's just that there are so many that do. It makes it hard not to let those stereotypes assume the public face of The Java Programmer. Not impossible, just hard.
July 29, 17:29 | Comments (21)
Paul Graham is the hacker's bard. He puts in eloquent words what can otherwise seem fuzzy. He's also a LISP programmer on a mission:
When you decide what infrastructure to use for a project, you're not just making a technical decision. You're also making a social decision, and this may be the more important of the two. For example, if your company wants to write some software, it might seem a prudent choice to write it in Java.
But when you choose a language, you're also choosing a community. The programmers you'll be able to hire to work on a Java project won't be as smart as the ones you could get to work on a project written in Python. [2] And the quality of your hackers probably matters more than the language you choose. Though, frankly, the fact that good hackers prefer Python to Java should tell you something about the relative merits of those languages.
That's the paradox of picking an off-mainstream platform. It's not harder, but easier to attract top talent. We witnessed this first hand when advertising for help on Basecamp. Triple-A programmers were falling over themselves to get a shot at working commercially in their language of love. They were the kind of guys were I'd feel like the freshman just arriving on campus.
Who cares if there's 5 million Java programmers? Or 3 million PHP programmers? You usually just need a couple for any project and with star talent being 10 times as productive as your average Joe Programmer, it's extremely important to get hold of that upper-echelon. And as Graham says, you're much more likely to find one of those in languages of love.
July 29, 16:57 | Comments (6)
Keith Pitty is a J2EE developer with 20 years of experience in Software Development. Here's what he had to say about the upswing of dynamic languages like Ruby and Python after reading about Rails:
I know this is an inflammatory statement but it would seem like the smart money is on a shift away from J2EE to Ruby or Python-based web frameworks.
Of course, Rails is not alone in bringing this line of questioning before the holy temple of Enterprise Development, but its comforting to see that there is at least a shred of light from those on the inside. Perhaps web-development needs not be torture? Perhaps programming can actually be fun?
If Keith was feeling doubts, though, there are plenty of priests to calm him down with the usual chants about "...they are quick hacks..", "...people say that the J2EE solutions are more scalable", "...small-scale web applications...".
July 29, 2:35 | Comments (2)
I've just released a flurry of updates for Rails. There's a new release of the main distribution, which now works on Windows out-of-the-box and has a WEBrick-based internal web server (you can of course still use Apache). Both Active Record and Action Pack have also seen updates, which includes new features and bug fixes.
I've also worked hard to cure all the start up problems people were experiencing with the 0.5.0 release. There's better error reporting and better documentation to help everyone out. And if that shouldn't put you on straight on Rails, the IRC channel has been growing rapidly. There's plenty of people willing to help you out.
July 26, 23:52 | Comments (23)
It's been just over 48 hours since the first release of Rails was unveiled and more than 200 300 500 people have already downloaded the framework. While numbers are shallow, I'm really thrilled to see this take off so fast. Not even Instiki, which has a much broader appeal, took off that fast (although it has now been downloaded 2,418 times, which places 7th on the all time download list at RubyForge).
But as I said, numbers are shallow. What's really making my day are all the overwhelmingly positive comments that are flowing in. It's quite a kick to hear people say they want to learn Ruby just to use Rails. Thank you all so much. I'll be sure to make the transition worth while.
If you want chat about whether Rails perhaps also could be something for you to leave PHP/Java/C#/Per/Python behind for, there's already a great community blooming at #rubyonrails on FreeNET. Come join us.
July 25, 17:43 | Comments (14)
Naseby is disappointed that Action Pack, and by association Rails, doesn't offer a paradigme shift like Borges or other interesting new approaches to web-development. I'm always sorry to disappoint, but at least this time it's not out of regret. Here's a shocker: Rails is designed to be boring!
I bring no revolutionary, and hardly any evolutionary, ideas to the table with Active Record, Action Pack, and Rails. It's all based on familiar patterns and other peoples great ideas. My humble role has merely been one of selection and simplification. That approach was never going to make the science fair. Or have white papers printed in academic journals. It's just going to make the life of plain old web-developers easier.
Naseby also mentions Basecamp, which serves as a good analogy for Rails. Basecamp took an old concept (project management) and used familiar tools (weblogs, todo lists) to create something, from a perspective of earth-shattering innovations, boring. But the funny thing is that this is exactly what people were looking for.
So I welcome the label of boring. Rails is so boring that you might actually find a use for it in projects you're likely to work on.
P.S.: I do take offence to have Action Pack labelled as a "slightly buffed classic ASP lookalike", but I'll forgive Naseby his premature judgement, and hope he actually takes the time to discover why it is not.
UPDATE: Naseby apologies for calling Action Pack a ASP rehash and explains why it isn't for him with "...pragmatic excellence [is] not my criteria for selecting the frameworks I’d like to play with". Fair enough, all forgiven.
July 24, 21:30 | Comments (26)
I’ve been talking (and hyping) Rails for so long that it’s all wierd to finally have it out in the open. Mind you, we’re still not talking about a 1.0 release, but the package currently on offer is still something I’m very comfortable to share with the world. Undoubtedly, there could be more documentation and more examples, but Real Artists Ship and this piece will grow in public. Enjoy Rails!
UPDATE: Want to know more about how we built Basecamp using Rails (and how we built Rails using Basecamp)? Attend the Building of Basecamp Workshop on September 17th in Chicago. You better hurry too, it's already half full (and the last one sold out a month in advance).
July 15, 22:48 | Comments (14)
PHP 5 is officially out. Congratulations to Zend and friends. Even though I haven't really dug into much PHP work for about a year (since leaving for Ruby), I have many fond memories and thanks to extend to PHP. It brought me up well. Not that I'd want to go back. My mind has embraced Ruby so completely that whenever I'm forced back into PHP (for maintanence) it twists and turns — Don't make us go back there, masta.
It appears too that I'm not the only one. On the Slashdot topic for the PHP 5 announcement, an anonymous coward modded "5, Interesting" extols the virtues of Ruby in constrast to Python:
If you've ever been programming Python and wished it was cleaner and less "arbitrarily verbose", you'd like Ruby. If you wonder why Python arbitrarily makes you say "len(str)" instead of "str.len()", you'll like Ruby. If you wonder why Python makes you type "def foo(self)" instead of just "def foo", you'll like Ruby. If you wonder why you should type verbose hard-to-read stuff like "[f for f in n if f < 4]" instead of something like "n.each { |f| f<4 }", the give Ruby a whirl.
That gives few pointers to many of the smaller things that turned me off Python and on Ruby. More importantly, the flattered me said, is his promotion of Rails:
If you do MVC-type web apps, your mouth will hang open when you use the highly dynamic Ruby on Rails (how do you add a new object to your app when you add a new database table? ONE LINE OF CODE. How do you add a new field to your object when you add a new column to the database? DO NOTHING.)
So since I'm addicted to hanging mouths marvelling the full dynamic being that is Ruby, I'll do my best to finish up the first release in no time at all. Despite being in Rome and Venice for the past two weeks, I got in an impressive amount of coding and documenting during all those down times travelling and chilling. Do stay tuned.
July 10, 18:54 | Comments (6)
Ryan Dlugosz just wrote me about how Active Record made Hibernate, a Java-based ORM alternative, look like all labour and no fun: [A] coworker of mine was doing a talk on Hibernate Tuesday night (the OR Mapping tool for Java). About a week earlier, I showed him a bit of Active Record & asked him to throw it into the talk somewhere for perspective.
He showed the many XML configuration files, pile of required libs, a 30-property-long JavaBean supporting the "Client" table, and finally some Java usage of Hibernate to persist and restore it. Everyone agreed - it's great that you don't have to write any SQL and Hibernate does a good job of optimizing queries & managing the object cache. Cool stuff.
Then he pulls out Active Record. :) People were simply amazed that the same result was achieved using Ruby + AR without any of the configuration or dependencies required by Hibernate. Granted, AR can't do everything that Hibernate does, but as far as core functionality goes (the stuff you'll actually *use* in your job) it's beautiful.
Even now people are emailing me about how cool AR is now that they've been playing with it. Thanks for a great piece of software and I'm looking forward to seeing (and using) Rails!
This is my dream response to Active Record. Appreciating that the Active Record pattern is a worth-while competitor to the horde of data mappers and that a Ruby-implementation can remove all the tedious labour from the usage.
I'm even more excited to get Rails on the street now. Just about a week's worth left on vacation (in which I've sneaked in lots of neat Rails stuff on the train from Venice to Rome and will be doing the same on the way back). So late July is now the current target.
Thanks to all the continued encouragement and anticipation. It means the world.
June 27, 8:34 | Comments (20)
The Building of Basecamp workshop turned out to be a great success. The eight hours of the sold-out event flew by with tons of great questions from the audience and a real sense of shared understanding. Besides pushing all of the underlining themes for our development process, including Less Software and Say No By Default, I got plenty of opportunity to push Ruby on Rails.
The split was about 50/50 between developers and designers, so our broad approach spanning individual design techniques (like the yellow fade), to the wonders of MVC as a structure for web-applications, to promotion and pricing of a web-based application went over very well.
So this could easily turn out to be something we'd be interested in repeating. Perhaps even outside Chicago or even the US. So if you have concrete leads on how we could get a venue and gather 50 people at ~$400, we'd certainly be interested in hearing from you.
June 09, 15:00 | Comments (4)
Active Record was released just ten days ago, has so far undergone five additional revisions (adding tons of features), and has been downloaded close to two hundred times. But those are just the numbers. It's much more interesting to hear what the developers using it thinks. Thankfully quite a few of them are willing to share their impressions:
- [Active Record] is one of the coolest and most useful modules I’ve used in any language—Daniel Hobe
- I must stress that Active Record just plain rocks—David Nasby
- I love Active Record, and I have even started using it yet :)—Gavin Kistner
- I must congratulate you on the readability of your code; it took me no more than a couple of hours and I think I've got a handle on how it all works—Tim Bates
- Having browsed through the RDocs, I’d have to say AR is the best-documented Ruby package I’ve seen. Well done!—Gavin Sinclair
- Excellent work so far—Kevin Bullock
Thanks for the encouragement, guys! This certainly helps my motivation for making Active Record the darn best ORM package rapid application development out there.
June 06, 23:52 | Comments (23)
 The new version of Instiki ships among other options a native OS X client (2.7 MB), which comes complete with Ruby 1.8 and all the libraries needed to run from a double-click. It's a nice demonstration of how web-applications can blend with the native GUI and serve as a platform for making quick multi-os apps (I intend to do a Windows version at some point as well).
June 03, 13:59 | Comments (16)
This is the fourth release of Active Record in as many days. So while I perhaps didn't follow the first part of "release early, release often", I am surely following the latter. The same was true for Instiki, which underwent 9 releases in just two months. Open source has a habit of bringing that kind of rapid improvement to products.
May 30, 18:10 | Comments (8)
I'm incredibly proud to present the first public release of Active Record — an implementation of the pattern by the same name for object-relational mapping. I've entitled this release Three-Quarters to reflect the fact that Active Record has been in production use on Basecamp for more than three months and used during the many months of development before that. Additionally, it's been used by around five beta testers in a number of different projects. So even though I'm not ready to declare it 1.0 out of the gates, it is indeed a solid release.
It also marks the first step towards releasing the web-application framework Rails, which I've been hyping and talking about for some time now. Active Record is the model part of Rails and contains around two-thirds of the code in the framework. So if you want to get ready for making Rails applications, it's a good idea to familiarize yourself with Active Record.
Further more, I'd like to extend my thanks to Luke Holden, Jamis Buck, Aredidel, Guan Yang, and Lau Tårnskov for helping me make this release a reality. All your help and suggestions have been much appreciated!
Find more information and links to downloads on the official website and on the API site.
May 27, 17:17 | Comments (0)
Aredridel has been one of the beta testers on my Active Record object-relational mapping package that's going to be released in the very near future. It's the model part of Rails and about two thirds of all the code in the framework. So naturally, I'm very interested in feedback, and Aredridel provides just that in his Annoyances with ActiveRecord (currently down, try google cache).
Continued...
May 14, 19:19 | Comments (42)
My wonderful hosts from Roskilde University has completed the editing process on the footage from my Ruby on Rails, Take II presentation. It's a two-hour show split into a 1-hour presentation followed by a 1-hour tutorial.
If your default player won't eat that, Quicktime will play the feed. Copy rtsp://komm-video.ruc.dk/20040506/rubyonrails.mp4, pick Open URL in New Player, paste, enjoy.
UPDATE: If streaming doesn't work for you, a downloadable version (160MB / MPEG-4) is available.
May 12, 0:52 | Comments (34)
Active Record is doing a lot of magic to simplify associations between objects and their records in the database. Ruby is making this particularly easy due to ability of running methods during class definitions, which makes for instant domain specific languages.
Continued...
May 11, 22:14 | Comments (5)
I just uploaded the Keynote slides in PDF from the Ruby on Rails Take II presentation. They're a bit more inclusive than the first presentation I did with a closer view at Basecamp, what we did, and how it was received. It also includes code snippets that reflect the current state of the Rails framework.
It'll probably make more sense viewing this alongside the video recording of me presenting it. But since I don't know when that'll be done, I thought you might like to skim through this in the meanwhile.
April 30, 19:28 | Comments (11)
Next Angle, my company site, has been embarrassingly out of date for ages because flat HTML files are just such a pain to maintain. No more! The new site has been relaunched with timely content on the CMS-version of Instiki, which makes the back end look just like a wiki — and it's as easy to update as one, too. Since, well, it is just a wiki.
The new site doesn't yet contain my upcoming speaking engagements, but that and the details on my next commercial Ruby on Rails project (for a New Zealand company, no less!) will be up soon.
I've kept it really simple, mainly just running off the Instiki base template, with just a dash of CSS to do the two-column setup. Much nicer than my old "designed" boxy thang. Oh, that reminds me that I'm no longer billing myself as a web designer. How can I work with these guys on a daily basis and then even contemplate charging money for my own feeble attempts? I just can't do it.
April 26, 17:42 | Comments (19)
UPDATE: Ruby on Rails has been released!
It's official. I'll be giving the previously discussed two-hour presentation to all the stuff I've been working on for the best many months. The presentation is once again entilted Ruby on Rails to Basecamp and will consist of a one-hour introduction to Ruby, Rails, and Basecamp followed by a one-hour tutorial on Rails.
It'll be Thursday, May 6th at 13.00-15.00 in Biografen 41.1, Roskilde Universitetscenter. It's free to come and there's plenty of space. So do come if you're interesting in Basecamp, Rails, Ruby, or all of the above.
Continued...
April 21, 18:48 | Comments (12)
I'll be giving a two-hour introduction to Ruby on Rails at Roskilde University in the near future. It's going to be partly about Ruby, Rails, and Basecamp. The advantages of the platform and the story of the production. Along the lines of that Ruby on Rails to Basecamp presentation I gave to a small team under Madsen-Mygdahl recently. That's the first hour.
The second hour is going to be on how to build a web-application with the Rails stack. I'm going to build something small from the ground up to show you just how easy and fast it actually is to produce something of value in Rails.
An official announcement shouldn't be too far away, but I'd like to sample to interest around here anyway. Would you be interested in spending two hours on hearing my rave glowingly about Rails some time in May at Roskilde University? If so, please leave a note in the comments.
April 21, 18:24 | Comments (10)
Instiki is now in it's 0.7th release and already my default pick for any new content-oriented venture. It's used heavily in my study group to keep notes for our law class and write our bachelor's project (plans for a LaTeX-exporter is in the works). We've also installed it in Socialistisk Folkeparti for the internal side of our Social Software study (the external part is a weblog for member of parlement Margrete Auken).
On top of that, I'm running a wiki to collect knowledge on my new 3G phone from Motorola. A new commercial project I just started on uses it for requirements specifications. A friend of mine developing Mac shareware uses it to coordinate the development of their two projects. And of course Instiki itself is hosted on Instiki.
And it's apparently not just a mother's love, either. Russell wrote about wikis for intranet use yesterday and two different people immediatly jumped in to promote Instiki. Awesome!
So I thought it was about time for it to move out and onto its own domain: http://www.instiki.org/.
April 16, 0:22 | Comments (11)
Instiki is back on fork-challenged platforms (hello Windows!) after a short hiatus in the 0.5 release. It now also properly snapshots the Madeleine database when running in Daemon mode. So hopefully we should be working all around.
More interestingly, there’s a bunch of cool new features in Instiki. You can export the entire web to HTML files that come bundled in a pkzip (thanks rubyzip!), which works great for taking backups or distributing a wiki. It’s also a half-decent CMS this way that you can use to write documentation to all of those wonderful Ruby projects.
There’s also RSS feeds. Two flavors: Full content or just the headlines. Unfortunately, there’s a few problems with international characters like æåø that’ll render the XML invalid (so readers like Feed Reader? chokes). Any help to get that working properly will be much appriciated.
And thanks a ton to both Florian for a bunch of great patches and to Why The Lucky for keeping Red Cloth? running at full force.
Check out the full change log at the self-hosting Instiki wiki.
April 09, 18:30 | Comments (4)
Instiki have moved off the backburner and into full-on development as its been chosen for playing a part in my bachelor's project on Social Software. This release is entitled "Before the Storm" as it's mainly about polish before I start adding features that'll require data migration. Upgrading to 0.3.1 is a no-brainer. Just move your wikis from storage/ over from the old installation and all should be fine.
The most apparent change is that the user interface has been polished for all pages. This includes much requested Textile help on the edit page. But there's also locking, so you won't accidently start editing a page someone else is already working on.
Check out the full change log at the new self-hosting Instiki wiki.
April 04, 19:06 | Comments (9)
The rise of agile development methods have raised a range of questions about their general applicability. Martin Fowler ventures his speculation in Can average developers use agile methods?:
When a new technique or tool appears, it's usually tried out first by higher ability developers. This is quite a natural response. Early adopters have to be those who are more thoughtful and caring about their profession. New approaches are usually tried by them before it's tried out on the majority.
Thus with any new approach you have to ask the question of whether this approach is only suitable for these more adventurous souls. This is an unanswerable question, because until it's tried by more average teams, you can't tell how it will work for them.
I whole-heartily agree and simultaneously think it's a speculation that could be extended to include the rise of dynamic languages, such as Smalltalk, Python, and Ruby. I have plenty of first-hand experience with the fear and mistrust with which Ruby is met with by late comers that needs and relies solely on the affirmation of mass-adoption.
Continued...
April 04, 17:05 | Comments (41)
Charles Miller examines the getter/setter syndrome in Java1 from a usage (rather than the normal construction) perspective and devices a shortcut. Instead of using individual access methods, he proposes the unified set_properties that takes a hash of attributes and automatically assigns them on the object instance. Unfortunately, he fails to see its uses and discards the idea with a clever Simpsons reference (we like those).
That's a shame because he had the right idea.
Continued...
April 01, 0:59 | Comments (8)
The date has been set for June 25th and my flight has been booked for our Building of Basecamp workshop. A whole day to pick the brains of the team behind Basecamp on a wide variety of subjects from development to design to marketing.
I'll of course be talking at length about Ruby and Rails both during and after the workshop itself. Perhaps we'll even get down and dirty with some hands-on examples of this outstanding combination of pure web-app productivity. (As you can hear, I'm already at basecamp on the climb of Mount Evangelism).
Be quick, though. There's a hard limit of 40 spots available, which will likely be gone sooner rather than later judging from the early expressions of interest we got when airing the idea. Bring more than three people from your company and enjoy 10-25% discounts on the $395 admission and a free year of Basecamp premium.
See you in Chicago!
March 31, 13:21 | Comments (12)
Admitted, it's Yet Another Wiki Clone, but with a strong focus on simplicity of installation and running:
- Download
- Run "instiki.rb 2505"
- Chuckle... "There's no step three!" (TM)
You're now running a perfectly suitable wiki on port 2505 that'll present you with a textarea for the home page on entering. No web-server or database to configure. All you need is Ruby 1.8.x.
Continued...
March 30, 18:52 | Comments (17)
Florian writes after reading about how the Active Record implementation in Rails works: i dont see how active record is not marrying your bussiness objects with the orm solution. quite frankly i think its even worse with active record, because you marry each indidual business object to active record, since each one inherits from ActiveRecord::Base.
Perhaps I wasn't clear. I willingly pay the price of marrying my business objects to the ActiveRecord::Base to get a much more natural API in return. No, I can't swap persistance implementations. That's the cost.
Continued...
March 27, 13:53 | Comments (16)
Jeg kan godt lide, hvordan du I én sætning både formår at antyde, at Ruby er en passerende fase ("seneste besættelse") samt at sproget er ligegyldigt eller i bedste fald overflødigt ("endnu et fortolket scriptsprog"). På den måde så har man da sikret sig ikke at skulle besvære sit intellekt med den byrde rent faktisk at kigge nærmere på sproget.
Continued...
March 26, 1:48 | Comments (26)
As a Ruby developer, the tune of all these trumpets heralding the coming of SimpleXML in PHP5 sounds a bit out of key. Gutmans and Suraki from Zend gets really carried away in the introduction to PHP 5:
PHP 5 also introduces new revolutionary ways of dealing with XML that make it the ideal platform for XML processing—no other solution comes even close!
I can forgive their overreaching enthusiasm, though, they're just really proud of their creation. It's somewhat harder to forgive "Java heads" like Russell Beattie getting all giddy about PHP 5 because of the introduction of SimpleXML and XPath.
Continued...
March 24, 18:28 | Comments (12)
Since trackbacks hasn't yet been enabled on Loud Thinking, I thought I'd do some manual recognition of the latest round of link-love for Rails, Ruby, and Basecamp.
Continued...
March 22, 20:07 | Comments (13)
MVC is a pattern for separating the three basic concerns of a web application into isolated tiers, which can be constructed, tweaked, and tested apart from the others. MVC is short for Model, View, Control.
Continued...
March 21, 19:56 | Comments (17)
UPDATE: Ruby on Rails has been released!
I gave a presentation to Madsen-Mygdal, Guan, and Husager today over brunch on that upcoming Ruby web-framework I've been developing in conjunction Basecamp.
It's probably a somewhat different experience just watching the slides without my 4-hour oral presentation accompanying it, but it'll have to do. Hopefully it won't be too long before I'm ready to announce a beta version of the thing.
March 21, 18:45 | Comments (4)
What Ruby lacks more than anything is good starting points for getting into the language. There's a bunch of absolutely excellent resources out there, though. I've attempted to summarize the best of them by category.
Continued...
March 12, 17:19 | Comments (21)
When programmers speak of code as ugly or beautiful they reveal an appreciation of software that goes much deeper than the functionalistic appearance of their work. There are plenty of obvious and objective correlations between ugly and opaque code and defects and extendability, but the individual and psychological effects are at least equally interesting.
Continued...
February 05, 12:49 | Comments (6)
 After four months of development, 37signals and I have completed and launched Basecamp 1.0. It's a hosted service for flexible project management composed of categorized weblogs sprinkled with contacts, milestones, and todo-list tracking. There's no fee for single-project setups, up to 10 active projects is $19/month, 25 is $39, and unlimited is $59. 37signals explains pricing and the offering in detail on BasecampHQ and answers questions on Everything Basecamp.
Continued...
| 
