Head On

A year ago I was frustrated over Rails’ close ties to Subversion. But as Rails is moving from SVN to Git, the future is looking bright. The only bastion left I can think of is RubyForge.

I am creating a small site using Merb, DataMapper and RSpec, all in all a very enjoyable experience. I did however have problem getting the test database to be automigrated when running the specs, as I am used to in Rails.

As Google did not help, I turned to #merb on IRC, and got immediate help.

Two alternatives:

1. Run rake MERB_ENV=test dm:db:automigrate before running rake specs
2. Insert DataMapper::Base.auto_migrate! into your spec/spec_helper.rb

Big thanks to topfunky, afrench and jdempsey for the help.

Tim Bray on the JVM being the good part of Java:

“But the Java language just doesn’t seem like the interesting thing about Java, these days.”

I wish more Java programmers would agree to this. One of my observations at JFokus the other day was that a lot of people really like Java the language, and are going through hoops to implement their ideas in it.

Stephan Janssen has created a kick ass new version of parleys.com in Flex/Air, but he wants to redo it all in JavaFX script, just so that it is Java. Rickard Öbergs new framework for composite oriented programming could be useful, but in my opinion it introduces enough new concepts to qualify for a whole new language. Lipsticking on top of Java makes it feel verbose and clumsy. After a year of Ruby I have very little patience for Java interfaces.

(Via ongoing)

I cannot help myself from making a small comment on Rick Hightowers post on Groovy vs JRuby. In short he thinks Sun should support Groovy instead og JRuby, because the syntax is familiar to Java programmers.

To support his case he presents a chart showing language popularity according to job postings. And since Ruby is at the bottom and Java is on the top, Sun should support Groovy. Which by the way is not even on the chart.

One thing I did recognize was this:

Notice that between Java and Ruby/Python there is a wasteland of languages that you will not see running on the JVM in any near future. So if Sun wants to expand the developer base for the JVM (not Java the language), I believe they are making a very wise decision to support the largest languages available to them outside of Java.

Supporting Groovy would probably be popular among the already converted, but Sun has to appeal to new markets to expand the JVM usage. I believe that is what they are doing.

Ola has released JtestR 0.1. It seems to b a great tool for those doing Java development. I can personally not imagine doing any development these days without RSpec.

I just read the following in a month old post on the RSpec list:

As someone who uses an IDE, I find dealing with multiple SCMs is a real pain, and one of the cool things about Ruby has been that (traditionally) nearly everything’s in Subversion

It might be that Rails will have hard time keeping up with new stuff, both technically and culturally, since it tied really close knots with everything that was cool 2005.

RSpec 1.1: “The RSpec Development Team is pleased as glug (that’s kind of like punch, but more festive) to announce RSpec-1.1.0.”

Woohoo! We’ve used RSpec since the 0.7-ies and I personally could not be happier with it. The RSpec community is really pushing the boundaries for testing/speccing frameworks and is now the standard for all others to follow.

(Via David Chelimsky)

I was happy to note that Dion Almaer commented on my blog post on Merb. Dion is one of my favorite bloggers/podcasters and I value what he writes highly.

But I disagree with him on this one. The problem with using Java for web application development was never one of too much choice. In fact, it was because of that choice that Java became a player in the server side market at all. Sun alone never had the answer to what was needed for server side development, instead the open source world stepped in and made incremental corrections.

The same thing is happening to the Rails world. The core team cannot create a framework that is a one-size-fits-all. The initial Rails proposal is great for a large number of webapps, but it is other things around it like plugins and JRuby that is making Rails a viable choice for all.

My Java tools of choice was usually Tomcat/Jetty, FreeMarker, iBatis, WebWork tied together with Spring or PicoContainer. What I hated was having some frankensteinian-enterprise-architect-design-by-comittee-lets-not-be-different stack forced upon me with a fullblown J2EE server, EJB’s, Struts or the JSF monster, sprinkled with an Eclipse-only development environment. And I hope dearly that Rails development is not going the same way where people question you on your choice of tools and wonder why you are not using MySQL and TextMate like the rest.

There is one choice that I do not miss though - directory layout. I am truly happy every time I do not have to choose it.

Instead of not having to choose, the most important difference I’ve experienced is that Java as a language together with the Servlet/J2EE spec induces a lot of accidental complexity, which is almost non-existent in the Ruby/Rails world. It is that which enables the increased velocity many development teams experience when switching to Ruby.

DHH’s post about the Rails 2.0 is incredibly well written. It is almost as he is showing off a unknown past as a PR agent when he talks about Rails not supporting commercial databases out of the box:

But that doesn’t mean the commercial databases are left out in the cold. Rather, they’ve now been set free to have an independent release schedule from the main Rails distribution.

This sort of well formulated marketing has been known to render some sour remarks from the rest of the open source web framework world. My belief is though that when they ask themselves “Why are people so attracted to Rails, my framework of choice is just as good or even better”, sentences like the one above are probably a large part of the answer.

I have used Rails on a daily basis for almost a year now, and before that I was a night time hangaround. While I am definitely a happier programmer using Rails than anything built on Java, I still feel that it can get better.

First of all I want more things to be plugins. And really, they should not be plugins at all but gems instead.

Why plugins? We use RSpec instead of Test/Unit, HAML instead of erb and are seriously looking into JQuery instead of Prototype. And of course, we are using Mercurial instead of Subversion. All of this is of course possible to use in Rails, but a lot of things are sort of made for the default choice, such as generators generating tests, and plugins having the -x switch for Subversion. And I am pretty sure that this is the way DHH wants it.

So, when 2.0 is now released, I see that the Rails community as a whole does not see the same problems as I do. If they did, they would have done more like the stuff above, instead of sexy migrations and ActiveResource.

This is where Merb becomes really interesting. I have looked at it before not understanding its value, but now I see a framework that does everything I want Rails to do. Gems as plugins and very agnostic about templating languages, Javascript frameworks and even ORM frameworks - almost a heresy in Rails. I will definitely think about using it instead of Rails in the future.

I am subscriber of the Test Driven Development mailing list as well as the RSpec ones. One thing that strikes me continually is the lack of innovation and new ideas in the former one, as opposed to the flurry of brilliant ideas constantly coming out of the RSpec one. It seems to me that communities stagnate and that the people who once were the revolutionaries turn into keepers of their own revolutions ideas. The free thinkers become conservative.

Guy Kawasaki gave a brilliant keynote on the MySQL conference, talking about innovation. He said that the only way most people think about how to improve themselves is by using the tools they know more proficiently. No makers of horse carriages became car manufacturers. And the original TDD’ers are still talking about the same things they did five years ago. The revolution has moved on.

This tutorial on RubyOSA is great. I have never got around to learn AppleScript, and now it seems like I never will.

I just got a mail confirming that I will not speak at RailsConf Europe this fall. I had submitted a proposal named “Version Control in Rails using Mercurial” which was going to show the benefits of using a distributed version control system when developing a Rails app. My opening line would have been “Hi, I am Marcus and I have been Subversion free for six months”.

For some weird reason, so many people in the Rails community - and the open source community as whole - still talk about Subversion as something great. It is not. Subversion is decent at best if you are comfortable knowing that you are using second or third best tools, but believe me, it is a crap choice knowing the alternatives in distributed version control.

I really wanted to point all this out to the a larger audience so that we maybe will move beyond the Subversion centric mess which is the Rails community today. Oh well, maybe next year.

For a very entertaining and opinionated view on version control systems, watch Linus Torvalds most awesome presentation on Git at Google.

Sitting in Stockholm reading blogs, it feels like being home on a friday night knowing that there is a great party going on and you are not going.

I am using Ruby based DSL’s for a number of tasks in my current project. But one day it struck me - am I using the right tool for the job, could there be a better, more simple solution?

Some DSL’s I use are simply declarative and look something like this: [source:ruby] quiz “Let’s ask stuff” do question “What is 1+1?” do alternative “2″, :correct => true alternative “3″ end question “Vad is 2+3″ do alternative “1″ alternative “Infinity” alternative “Don’t know” alternative “5″, :correct => true end end [/source]

I find that quite readable, but it requires me to maintain code that handle the DSL. So I figured, what if I used YAML? It is simple, and using it would mean less code to maintain.

After doing some experimenting, this is what I came up with: [source:yaml] quiz: Let’s ask stuff questions: - question: What is 1+1 alternatives: - text: 2 correct: true - text: 3 - question: What is 2+3 alternatives: - text: 1 - text: “Infinity” - text: “Don’t know” - text: 5 correct: true [/source]

In my opinion, the YAML is not as readable as the Ruby DSL. I also find it more error prone as those dashes are sort of tricky.

XML? [source:xml] 2 3 1 Infinity Don’t know’ 5 [/source]

With the correct schema, errors can be avoided, but it is just too much text in there, it gets heavy and verbose.

The verdict was to stay with the Ruby DSL’s - their readability and flexibility are well worth the effort of maintaining a separate parser - which is quite short really.

I just noticed that the mapping between PostgreSQL’s Time Without TimeZone column type maps to Rubys standard Time class. Which gives the following behavior in script/console:

   >> t = TimeEntry.find(1)
   >> t.time
   => Sat Jan 01 23:00:00 +0100 2000
   >> t.time = Time.now
   => Wed May 09 19:02:07 +0200 2007
   >> t.save
   => true
   >> t = TimeEntry.find(1)
   >> t.time
   => Sat Jan 01 19:02:07 +0100 2000

Am I very anal to find this … sloppy?

Reading this a little bit earlier would have saved me a lot of time. In short: callbacks such as :before_add does not work with has_many :through, and the documentation does not tell you that. To get callbacks, add them to the join model.

The current incarnation of autotest seems to assume that you are using integrated views. If not, you can modify the rspec_rails_autotest.rb file to run the view specs as well:

  # when %r%^app/views/layouts/(.*)\.rhtml% then
  #   ["spec/views/layouts/#{$1}_spec.rb"]
  when %r%^app/views/(.*)\.rhtml$% then
    ["spec/views/#{$1}_view_spec.rb"]

Your view spec must be postfixed with “_view_spec.rb” for it to work

Update This works out of the box now.

Autotest 3.5.0 is out, and the result given from Autotest is no longer a String, it’s an array of strings. So if you still want Growl to function properly just modify the .autotest slightly:

[source:ruby] module Autotest::Growl def self.growl title, msg, img, pri=0, stick=”" system “growlnotify -n autotest –image #{img} -p #{pri} -m #{msg.inspect} #{title} #{stick}” end Autotest.add_hook :ran_command do |at| output = at.results.last.slice(/(\d+)\s.*specifications?,\s(\d+)\s.*failures?/) if output =~ /[1-9]\sfailures?/ growl “Test Results”, “#{output}”, ‘~/Library/autotest/rails_fail.png’, 2 #, “-s” else growl “Test Results”, “#{output}”, ‘~/Library/autotest/rails_ok.png’ end end end [/source]

I am getting all parts of my Rails development environment settled. In addition to vanilla Rails, I am currently using RSpec, Selenium and Autotest. I am seriously considering Haml and Sass as well.

When googling arounf to learn more about Autotest, I realized that people are using together with Growl. It works out-of-the-box with Test::Unit, but RSpec needs a little tweaking. I took the basics from here and modified to my liking. The following is what my .autotest looks like.

module Autotest::Growl
  def self.growl title, msg, img, pri=0, stick="" 
    system "growlnotify -n autotest --image #{img} -p #{pri} -m #{msg.inspect} #{title} #{stick}" 
  end

  Autotest.add_hook :ran_command do |at|
    puts "at: '#{at.results}'"
    output = at.results.slice(/(\d+)\s.*specifications?,\s(\d+)\s.*failures?/)
    puts "out: #{output}"
    if output =~ /[1-9]\sfailures?/
      growl "Test Results", "#{output}", '~/Library/autotest/rails_fail.png', 2 #, "-s" 
    else
      growl "Test Results", "#{output}", '~/Library/autotest/rails_ok.png'
    end
  end
end