Wednesday, January 03, 2007

Author Interview: Christian Hellsten

This time around, I'm interviewing Christian Hellsten, the co-author of Beginning Ruby on Rails E-Commerce (I interviewed Jarkko Laine the other co-author here).


Christian, would you please introduce yourself?

Christian: I'm a father of two, a software consultant, and as of lately founder and CEO of Aktagon.

Why do you do outside of Ruby on Rails devleopment? Any hobbies?

Christian: I have two kids, which I spend most of my spare time with, so there's not much time left over for my own hobbies. When I have the opportunity, I travel, read books, roller blade, ski, swim, go mountain biking or perform some other sport.

Can you tell us a little bit more about Aktagon?

Christian: Aktagon is a tiny IT consultancy based in Finland that I founded in 2006 . We, including me, myself and I, develop software and sell consulting services.

How much Ruby/RoR work are you doing? What advantages do you find that Ruby/RoR gives you?

Christian: Right now I'm doing J2EE development for a client, which takes most of my time. This month, I've done about 60% J2EE, 30% Rails and 10% Python. Rails contracts are pretty non-existent here in Finland, so I'm not doing as much Rails work as I would like.

The main advantage of using Ruby/RoR (for a typical web application, not all) is that I can complete the project in less time, and maintain it with less effort. With Ruby/RoR, I don't have to spend time on tasks such as recompile, restart or redeploy. And, when the application is ready, I can easily deploy the application to production with Capistrano. Also, I don't have to integrate a gazillion different libraries. Most things are available in Ruby/RoR, out of the box, or through plugins.

What role do Ruby and RoR play in your day to day work?

Christian: Before Ruby on Rails was released, Python and to some degree Java were my favorite programming languages. I had heard about Ruby and tried it a couple of times. But I preferred Python over Ruby, because it had more libraries and seemed to be better documented. After trying Rails, both Ruby and Ruby on Rails immediately became my favorites.

Did you find that Ruby had more libraries than you thought, or were there other factors that made it better the second time around?

Christian: All I needed to make the switch was a killer application like Rails. After making the switch, I found out that Ruby had almost all the libraries I needed. Early on, a decent search engine didn't exist, but Ferret has now solved this issue.

What do you still miss from your Python and Java days?

Christian: I'm still doing both Python and Java development, but I can't say that I miss anything from either environment when I'm programming in Ruby.

Compared to Java, Ruby is a lot more productive and fun. Ruby is identical to Python, but I like the Ruby syntax more.

There are things that aren't available in Ruby, but most of the time you don't need them, or can work around them.

What do you think Rails should/needs to learn/steal from other frameworks (like Nitro or IOWA in the Ruby world, or the non-Ruby based ones)?

Christian: Difficult question. I haven't used Nitro or IOWA. There are a lot of things that could be copied from other frameworks/languages, such as continuations (Seaside), JMX (J2EE), automatic admin interfaces for models (Django) -- to name a few. But, I don't think those features would benefit most projects -- they would only add more complexity.

Since I don't have any answer, I can only say that it would make sense to copy things that make development for ~80-90% of the web applications out there easier.

How did you come to write a book about Ruby?

Christian: I was asked by Apress if I would be interested in writing a book about Ruby on Rails and e-commerce. The thought of writing a book about Rails had crossed my mind before, so I jumped at the chance.

Now that you know more about what writing a book takes, would you jump again?

Christian: I would definitely do it again, if I had the opportunity. But, right now I would hesitate a bit, because it requires so much time and effort.

What sets Beginning Ruby on Rails E-Commerce apart? Why should people buy it?

Christian: The whole book is built around a fictional e-commerce project. We start out by showing you Rails basics and then gradually introduce you to more complex technologies and features. At the end the reader has a complete e-commerce site that we also show how to deploy to production.

The book is not all about Rails features, we also included a lot of third-party tools and plugins, such as Active Merchant, the PayPal plug-in, the Shipping gem, Globalize, Ferret, Capistrano and more.

It's also for those who want to learn Test Driven Development (TDD). The book shows the reader how to do unit, functional, integration and acceptance testing (Selenium on Rails).

It sounds like you're a lot more interested in the process than the language. How does Ruby affect your ability to be able to focus on getting things done?

Christian: True. I'm more interested in getting the job done than in the technology. Ruby allows me to focus on the problem at hand in a completely different way than for example Java. I don't have to recompile anything or wait for my application to redeploy, which can take 20-30 minutes with a moderately sized J2EE application.

Ruby is also a lot more powerful than Java, which has all kinds of constraints that make you less productive. The thing I like the most about Ruby is that you can easily change almost anything at runtime - for example, add methods and classes.

If someone created something even more productive than Ruby and Rails tomorrow I won't hesitate to switch.

That's an awfully strong statement. Can you give me some examples of Ruby being more powerful than Java in a production setting?

Christian: Note that I'm not saying that Ruby is always going to be more powerful than Java for a given project. With powerful, in this context, I meant that Ruby puts less constraints on the developer. I can, for example, decide to introduce a new method to the String class in Ruby, which in Java wouldn't be possible.

Rails itself, is I guess the best example of this -- ActiveSupport in particular. Rails is also doing a lot of things behind the scenes that would be very complicated, or not possible at all in Java. Rails is creating methods and classes at runtime by using method_missing and const_missing , which have no equivalents in Java.

Another example is Dr Nic's Magic Models, which is doing some pretty amazing things at runtime.

It also leads to a corallary questions, what Ruby/RoR problems do you find that you have to work around?

Christian: Lately, I've had some problems with a couple of Rails bugs that I have had to fix or find patches for.

This is again one of the reasons why I like Ruby so much. If I find a bug in Ruby, Rails or a third-party plugin I can usually fix it by modifying the code at runtime. It also helps a lot that the source is available.

What was the most rewarding part of writing your book?

Christian: I enjoyed working with Jarkko Laine, Peter Marklund and the rest of the project team. After many long nights of writing and coding, I also found it very rewarding to see the book being published.

What was the hardest part about writing it?

Christian: The schedule was very tight, so I would say the lack of time. It was also difficult to keep all chapters in sync with each other, since each chapter builds on what was done in the previous one. Another problem was that Rails evolves so quickly that it's difficult to keep up with all the changes, while writing a book and changing diapers.

What did you learn while writing it?

Christian: I learned a bit about everything, including Ruby, Rails, writing, myself and the book publishing business.

Which other Ruby books do you envy?

Christian: Ruby for Rails by David Black and Ruby Cookbook by Lucas Carlson and Leonard Richardson. Go buy them :)

What non-Ruby books do you think Ruby and RoR hackers should be reading?

Christian: Don't Make Me Think: A Common Sense Approach to Web Usability by Steven Krug, would be a good choice for those who want to learn more about usability . And, since a lot of startups are using Rails , I also recommend Good to Great: Why Some Companies Make the Leap... and Others Don't.

rubinius Internals Guide

A while ago, Mauricio Fernandez posted an excellent Guide to Ruby Internals. Since YARV, JRuby, and rubinius are all drawing more attention, I thought it would be great to see parallel guides to each of these platforms as well. I'm going to try to take on rubinius, but I'll happily link to anyone doing the others.

Here's a quick table of contents. It's not complete, nor are the sections listed. As I complete a section, I'll turn it into a link.

As I collect them, good links for learning about rubinius will go here:

Tuesday, January 02, 2007

No Space for memcached

Users of memcache need to guard against hung applications. The keys used to identify stored data in memcache must be 250 characters or less and must not contain whitespace characters or control characters.

Programmers using memcache-client, Eric Hodel's popular memcache client library for Ruby, should be especially careful as memcache-client does no escaping to protect against this.

Thanks to Zed Shaw for getting the word out. Thanks also to Eric for a quick confirmation of the potential problems.

Rubinius Serial Interview: Episode III

A comment that seems to be coming up a lot is: "Where are the docs?". Let's detour briefly from testing and talk about docs (okay, it won't be a complete detour ...):

What plans do you have to get solid user and developer level docs for rubinius?

Wilson: In the near future, one of us will kick out a big shiny diagram of all of the moving parts of Rubinius. I like diagrams. Particularly shiny ones.

On the developer doc side of things, it would be helpful to know what people were looking for first. There are a number of things that need to be documented eventually, but spending time on pieces people aren't looking at yet is a waste.

People can use either the mailing list or the ticket system to make documentation requests. That would be helpful, I think.

Evan: I've been starting to think more about developer docs lately actually. I've begun to draw a diagram of how the majority of the components interact.

I'd love to start to get questions from people about how certain parts work so that I can begin to document those parts first.

A big knock against Ruby is that there's no spec for it. Charles Nutter has been trying to build one, but it's not there yet. How much does this hurt you? What are you doing to overcome it?

Wilson: I think the lack of a spec is OK. Specifying everything too early has a long track record of killing perfectly good languages. That being said, I think Ruby 1.8 is ready for one. There are now several implementations that can run real code, and the 'specs' from 'ri' only go so far.

I'm looking forward to working with Charles and the others on a spec. Until then, we're planning to just pit the various runtimes against each other, Thunderdome-style, as part of the test suite.

Evan: I agree with Wilson, currently no spec is not the end of the world. There seems to be a lot of movement toward formulating a spec for how the core functionality should perform. I'm fully committed to running rubinius against any and all specs for the core functionality that are available.

One of the things that I like about RSpec is it's ability to output specification docs. How does this feature play into rubinius' future with RSpec?

Wilson: I love this feature. The doc output is probably not detailed enough to be a spec in its own right, but it should make for some nice, readable developer documentation. The only drawback to RSpec for Rubinius at the moment is that it depends on rubygems, and that library will take some doing to get running under Rubinius, due to its large bag of tricks. It will come, but probably not this week. :)

Evan: My hope is that we can begin to use the specs as real documentation and verification of the system, ala perl 6's integrated documents and test runs. This provides people with a great insight into what parts work and don't without diving into the code.


Episode three of the rubinius Serial Interview is brought to you by: Spring Into Technical Writing. One of my favorite books about technical writing. Buy yourself a copy, then help document rubinius (or any other deserving project).

Previous episodes of the Serial Rubinius Interview are available here:

  • Episode 1, in which we talk about the rubinius community
  • Episode 2, in which we talk about cuby and testing tools

Monday, January 01, 2007

Win Books By Blogging

Digg this

Update: ¿Hablas espaƱol? Mira aqui.

Update: It's time to get going on the February contest. — this one is now closed.

Update: It's time to get going on the March contest.

I can't tell you how excited I am to have Jarkko Laine as our guest judge this month, and even better, he's come up with the theme for this month's contest: "How has Ruby on Rails made you a better programmer". (You can read more about Jarkko in the interview I did with him.) Here's his challenge:

For me, the spell of Rails comes roughly in three parts:

  1. Productivity boost
  2. Having more fun
  3. Doing the right things

#1 has been the reason numero uno almost everywhere Rails has been mentioned. I guess it's easier to sell productivity to managers than having fun ("oh, that's so unprofessional!") or doing the right things without rigid explicit processes. However, I see the increased productivity mostly as an inevitable consequence of the two latter points.

Much of my liking Ruby and Rails development more than other environments comes from the feeling of the language and tools being a natural extension of my brain. Why shouldn't I be able to write something like "2.weeks.ago"? It's easy to dismiss things like that as just syntactic sugar without real meaning, but you know, things add up, and overall happiness in work is built of small details.

Point number three could be described as the dullest and most minor benefit Rails brings to table. However, in many ways it's the grounding factor of both the happy Rails development and the improved productivity.

The things I include in doing the right things are stuff like making testing as easy as not to, conforming to the Rest principles and naming conventions, the MVC-type separation of concerns, and keeping yourself DRY (don't repeat yourself). I sleep my nights much better when I know that my application has extensive test coverage and that anyone knowledgeable with Rails can take it up in a few hours in case we need more labour force because the structure of the application is so obvious.

Now, none of these things are specific to or even popularized by Rails. However, many web developers have come to learn these lessons through Rails and I don't know any other framework that would make them as integrated part of the development process as Rails does. As the king of the Rails kingdom, David Heinemeier Hansson, has said, Rails tries to be the angel on the developer's shoulder ("Write your tests, it's as easy as not to!") as opposed to the PHP devil ("SQL in the views, quick'n'dirty, man!").

However, my imagination is very limited and I'd like to hear more about what healthy habits Rails has made people learn and what bad habits to abandon. That's why the topic of our January blogging contest is "Rails Revelations: How Rails made me a better programmer". Heck, if Rails made you quit smoking, tell us about it.

So, post links to your entries here, and Jason, Jarkko, and I will look them over the first week in February, pick a winner, and award the prize. Happy blogging!