Tuesday, November 14, 2006

Tim Bray, Comparing Intrisics

Not too long ago, Tim Bray made a presentation at a PHP conference in Frankfurt. Several people jumped on some of the slides Tim used (see Floyd's post at InfoQ for a fairly balanced take). Everyone seemed interested in his comparison of maintainability and scalability between PHP, Rails, and Java. While I thought that was interesting (and a bit flawed, that's a topic for another post though), something else was even more interesting to me. Check out this slide (but remember while these show a ranking of the three languages, they aren't graded):

Comparing Intrinsics

To me it's really interesting to look at the three comparisons on the right:

  • Dev Speed: Rails wins here, with PHP second and Java third
  • Dev Tools: Rails and PHP tie for second behind Java
  • Maintainability: Rails wins here too, with Java second and PHP third
Something that leaps out to me is that Dev Tools are created and improved as a reaction to the friction a language throws in the way of 'Dev Speed' and the obstacles it presents to 'Maintainablity'. This becomes more interesting in light of the constant cry that Ruby isn't ready for prime time because it doesn't have 'real' development tools. (Please note, I am pretty happy with the Ruby tools I've got — not that I'd turn up my nose at newer, better, shinier toys, err tools though.)

Now, I don't think there's anything wrong with good tools ... I can do a lot of fancier things in a well stocked kitchen than I can when I'm camping. When a language doesn't get in your way, they seem less important though. Maybe that's why Ruby doesn't have them yet, and why most of the Rubyists don't complain too much about it.

I asked Tim what he thought. He replied,

Your hypothesis - that tools are created in response to language/developer friction, of which Ruby clearly has less - is plausible. But there are things that I can do easily in NetBeans that would increase my productivity tremendously if I could do them in Ruby, so even if you're right about the motivation for tool-building, the quality-of-life issue is real.

When I asked him about specific tools he thought would help, he listed two

  1. Integrated IDE with editing/refactoring/debugging/testing all at the touch of a button.
  2. "Find usages" - find me all the places this method is called. That's huge because once you have it, you empower yourself to do all sorts of automated refactoring support.

Technorati tags:

Friday, November 10, 2006

Ruby Certification: Is It Worth It?

For some reason industry certification is a real hot-button. Some people think they're not worth the paper their printed on, while others base hiring decisions on them. I'm encouraged by the fact that the university is putting some real training behind the certification, but I wonder if the Ruby community is ready for (or interested in) something like this. What do you think?

Ruby Certification: What should it cover?

I've been asked to take part in setting up a Ruby Certification course for a large univesity (no names until they announce it, sorry). I'm participating, but I have two questions that are lingering in my mind. I'd like to ask for your feedback on one of them here. (I've also recently agreed to do some blogging over at InfoQ and I'll discuss the results one there.)

Certification is kind of a hairy deal. A lot of people love them, and others think they're evil incarnate (or something close). I've never been a big fan of them, butI see this as being a bit different than the typical 'take a test and earn a cert' plan. The university is planning a series of three (non-credit) classes that will focus on Ruby and Ruby on Rails, with a pass-fail grading system. Anyone passing the three classes (which will have a significant hands-on, practical portion) will be recieve the certificate.

So, here's my question — What topics need to be covered to make a certificate work like this work? (For extra credit, what kinds of hands-on exercises do you think would help cement a student's understanding of those topics?)

Update: I'll dicuss the feedback on both questions at InfoQ later on ... for now, all the discussion will happen here

Wednesday, November 08, 2006

Apgar and Softtware and Bears, Oh My

Daniel Read wrote a great post about Apgar tests and software and Edward G Nilges wrote a response. (Read more about the Apgar test over at wikipedia). Daniel's and Edward's posts are worth reading before you get too much further here, go ahead ... I'll wait.

I think there are some good and bad things underlying the analogy (as there are with most analogies). Let me walk through them, the bad first:

  • The biggest issue is that there are a lot of variances in the way software is written and its success measured. Without some standardization, it will be hard to get a meaningful, universal dashboard (which is what the Apgar really is). That doesn't mean that there couldn't be Apgar-like dashboards for different kinds of projects and organizations — and having those would probably be a good thing.
  • The Apgar is somewhat subjective (gameable, to use a term that showed up frequently in the comments of Daniel's and Edward's posts). It's hard to imagine that a similar dashboard for software wouldn't be gameable as well. (Whether or not a team is gaming the tests is probably a great metric for the health of the software.)
  • The Apgar is a lagging indicator. You don't know the score until the process is over, and you can't do much to go back and fix things. It does help you identify cases where an urgent response is needed, but knowing that things are headed south earlier would be much better.
And then the good:
  • The Apgar isn't just given once, it's given immediately and again at 5 minutes (and several more times if the baby isn't thriving). Being able to apply the same test iteratively, watching for improvement, will help ensure that your corrective action is actually working.
  • The Apgar is simple. As Daniel said, there are five metrics each of which is assigned a score of 0-2, and the total score (0-10) is the single measure that's used. Almost anyone can learn to rate an infant or understand the resulting score. This simplicity would be important for any software dashboard.

So, where do we go from here? Maybe it's time to build a list of what you think is important to a healthy software project. Some things that come to my mind are: a solid test suite, documentation, frequent releases, more than one developer with the commit bit set, and traffic on a project specific mailing list. What are you looking for?

Tuesday, November 07, 2006

Author Interview: Jarkko Laine

Jarkko Laine is a 26-year-old web developer from Tampere, Finland. He's worked on web-related technologies since 1997, first for fun and then slowly turning the passion into a business. He and Christian Hellsten co-wrote Beginning Ruby on Rails E-Commerce: From Novice to Professional for Apress, which was published on the 6th of November 2006. A little while ago, Jarkko and I did this interview.


How did you discover Ruby?

Jarkko: I was working for some projects on OpenACS, a web framework built on AOLServer and TCL, when my friends and then OpenACS core team members Lars Pind and Peter Marklund from Collaboraid in Copenhagen, hired David Heinemeier Hansson to give them an introduction on Rails. They were instantly sold and raved me about it. In two months I was working on my first commercial project on Rails. So I came to Ruby because of Rails, but I actually learned Ruby (reading the Pickaxe2 from cover to cover) before doing any major Rails work. I had a very strong theoretical background in OO programming from university so for me everything in Ruby clicked right away.

Do you think that learning Ruby before RoR gives you an advantage over Rails hackers with less Ruby background?

Jarkko: I don't necessarily think you need to know Ruby inside and out _before_ jumping on Rails. But Rails leans so strongly on many Ruby idioms that you lose a lot if you just think you can wing it. You still see people iterating over containers an picking items from them manually when they could just write array.map(&:id). I think many people who think Rails benefits are overrated actually think so because they can't see the pros Ruby brings in.

How much Ruby does someone who's picking up Rails need to learn to really become proficient with Rails?

Jarkko: I think understanding the object model ("everything is an object") is crucial, as well as all the container methods like map/collect and inject. I think those + the Ruby basics are enough to get you going. However, if you really want to be proficient, you need to know your tools well, and that means knowing your Pickaxe. I don't want to frighten people, though. If you're a good OO hacker, you can pick up Ruby very quickly, and in the process experience a lot of those "oh, why didn't we have this in language X?" moments.

What role does Ruby play in your day to day work?

Jarkko: Currently it's Ruby and Rails all the way. I love doing the front end stuff, too, but I couldn't think of doing it on top of anything else than Rails these days.

How did you come to write a book about Ruby?

Jarkko: My co-author Christian Hellsten was contacted by Apress and he asked me if I would want to join in. Christian is the one of us with very strong domain knowledge about the subject and I'm then the Rails guy, although that difference is very subtle.

One thing that sort of leaps out is your relationship with Christian. Did you two work together before starting the book? How did you meet?

Jarkko: We haven't actually met, not in person. I think that's one of the true miracles brought by the internet and open source. You can work together with people you have never met but whom you've learned to trust because of what they've done. I think many Rails core team members met for the first team in person in Chicago Rails conf and the rest now in London. Still they've been working on a common goal and vision with a noticeable success.

What sets your book apart, why should people buy it?

Jarkko: We tried to write a very practical book. The book is structured task-oriented, and the different Rails concepts are introduced when they're needed in the building process. So I think it's a very good choice for people who like to learn by doing.

Can you give us an example of this?

Jarkko: The book is organized by tasks, just like proposed recently by Kathy Sierra. We don't have a chapter for ActiveRecord, for example, we have a chapter for creating a shopping cart. We do cover a lot of ActiveRecord (sprinkled around the book), but ours is not a reference book at all.

What was the most rewarding part of writing your book?

Jarkko: Every time I submit a chapter draft in the middle of a night I feel like finishing a marathon. Tired, but still very happy. It's also an honor to be able to give back something to the great community that has built around Ruby and Rails, hopefully taking their success even further.

Yyou talked about marathons as a metaphor for writing and about athletic training. Are you a runner? What's the last race you were in?

Jarkko: I'm a national level orienteer. Orienteering is a sport where you run through an unmarked course in forest with the help of a map and a compass. It's quite a big sports in the Nordic and perfect for people that want more mental challenge than just running mindlessly :-) That said, I run also some track and road races.

What was the biggest challenge in writing it?

Jarkko: I think every writer with a day job knows how hard it is to sit down and start writing when others go to bed. Adding 10 to 20 hours/week of training of an athlete to that brings us very close to an impossible equation. Fortunately, our editors at Apress are a very good combination of understanding and pushiness so we have been able to progress all the time, despite sometimes feeling exhausted.

What did you learn from writing it?

Jarkko: People say that the best way to learn something is teach about it, and the same goes for writing a book. There's tons of background digging needed that never makes it into the book but that make you know a lot more about the subject than you ever did. Apart from that, the writing process in itself is a good lesson of self-discipline that I can recommend to everyone.

What are your favorite five libraries for Ruby?

Jarkko: Rails is obviously something of a living legend for me. Zed Shaw's mongrel web server is also no short of a wonder. But I also love all the smaller gems, like Geoff Grosenbach's Gruff graphing library. Other things I use daily are Test::Unit + RCov (with the Rails plugin, I'm a testing junkie) and Jamis Buck's Capistrano, the brilliant deployment tool.

What do you think is next for Ruby?

Jarkko: Native unicode support (I hope ;-)

What do you think is next for Rails?

Jarkko: A MySpace-sized Rails app (which seems to be the only way to silence the "it doesn't scale" folks).

What's next for you?

Jarkko: See the previous question — I'm working on dotherightthing.com.