February 28, 17:46 | Comments (31)

Google wants to change your content

Robert Scoble (of Microsoft) is spot on taking Google to task for wanting to rewrite the content of the web with adding their sponsored links (isbn goes to Amazon, etc). Winer has had similar good comments. The choice Google's DiBona talks about excludes content authors from the discussion. It's a terrible, terrible idea. Google needs to back paddle out of this evil doing. Post haste.

February 26, 0:19 | Comments (8)

Rails as a disruptive technology

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)

Odeo is launching on Rails

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)

Rails 0.10.0 finally makes an appearance

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, 16:51 | Comments (21)

Required number of years of experience

Scott Baron has an excellent post on the silliness of specifying years of experience in a given technology as a meaningful indicator for job performance. I couldn't agree more! Merely specifying the quantity of exposure someone has had to a given technology has to be one of the most widespread stupidities in hiring.

By those yearly standards, I would probably qualify as a rookie programmer with just over 1 year's worth of experience in Ruby. Ignoring the fact that everyones a rookie at something or another in programming, this is just silly.

So if this is the best your HR manager can do, coming up with a laundry list of technologies and attach year counts, you need to get rid that person (or department!) post-haste. Oh, and you need to start subscribing to Johanna Rothman's blog Hiring Technical People and listen to her talk on ITConversations — alongside Jerry Weinberg, she has the best hiring advice I've come across.

February 22, 2:46 | Comments (37)

Serving the koolaid with the facts

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)

The case against high-level components

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)

I want my photoshop comps!

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)

The false promise of template languages

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:

1. Designer cooks up static HTML template.
2. Programmer sprinkle it with rhtml tags to make the dynamic elements dynamic.
3. 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.

February 02, 17:01 | Comments (38)

Getting the wakeup call through Skype

Everything Basecamp has a short blurb about FIXED: Temporary database glitch. Jason called me up at 7 AM this morning (three hours after I went to bed) to tell me about it. Nothing unusual in that, programmers and system administrators are woken up in the middle of the night all the time.

Only Jason was calling from his Powerbook at 2 cents a minute. To my cell phone. In crystal crisp quality. In other words, Skype 1.0 is out for the Mac and SkypeOut freaking rocks. The quality was so good, I didn't even realize he was skyping me until long after the call.

Once more, that's lower-than-local rates for calling across the atlantic to normal phones. I'd start to worry if I was a telco living large off overpriced international calls. They're going to be 1, 2, 3, gone in no time at all.

While iChat AV is pretty darn cool and getting even cooler in Tiger, I can easily see Skype growing big and large in no time. Or, actually it is big and large at 54 million downloads. But bigger and larger then.

I especially like their voicemail feature. I'm not sure if its available to the general public yet, but my man on the inside of Skype hooked me up and it's super cool. It's just one more step to get push-to-talk and then it'll all get even more interesting.

I'd love to see recording of calls straight to MP3 as well. It would be a great way to record design conversations and then upload them to Basecamp for the team to share.

P.S.: Jason is just as psyched about it on SvN.