The Rails Brothers

The moment we were all waiting for is finally here: Channelthing (the microblogging application for team collaboration brought to you in Technicolor by Railslove) is going public alpha next week. I already signed up for an invitation because I'm pretty sure it will be a great app to use. So go ahead and drop them your email already. They need all the feedback they can get.

I wish them all the best with that project. Keep the good work going.

Recently I struggled a bit with our continuous integration system. We had broken tests for several weeks and everybody knows that in this such a situation a continuous integration system is as useful as ladder for a moth. So we obviously had do something against it. After fixing all the tests again I tweaked my Rake cruise task a little bit. The result looks like this:

  
    desc "Task to run all required tasks to perform continuos integration with CruiseControl."
    task :cruise => ["db:migrate", "db:test:prepare"] do
      build_path = ENV['CC_BUILD_ARTIFACTS']
      mkdir_p build_path unless File.directory? build_path if build_path

      Rake::Task["log:clear"].invoke
      Rake::Task["test:test:clobber_rcov"].invoke

      ENV['RCOV_PARAMS'] = "--html --exclude boot.rb"

      ENV['SHOW_ONLY'] = 'models,lib,helpers'
      Rake::Task["test:units:rcov"].invoke
      mv 'coverage/units', "#{build_path}/unit_test_coverage" if build_path

      ENV['SHOW_ONLY'] = 'controllers'
      Rake::Task["test:functionals:rcov"].invoke
      mv 'coverage/functionals', "#{build_path}/functional_test_coverage" if build_path

      Rake::Task["test:integration"].invoke

      Rake::Task["doc:app"].invoke
      mv 'doc/app', "#{build_path}/api_doc" if build_path
    end
  

It is designed to work with CruiseControl.rb. It clears out the log and the rcov results from the previous run and runs the tests using rcov. Because I want to run rcov only against our unit and functional tests the integration suit is run without rcov. Finally it builds the API documentation of the application.

As you can see everything is copied the CruiseControls artifacts directory which makes the artifacts available via the CruiseControl.rb dashboard.

In addition to this task you need the rails_rcov plugin by Coda Hale:

  
    ./script/plugin install http://svn.codahale.com/rails_rcov
  

Acknowledgment: This task is inspired by CruiseControl.rb very owns task to build the tests.

Ah, one more thing. If you are interested in the task for building the documentation, here you go:

  
    namespace :doc do
      desc "Generate documentation for the Schwacke Service Application."
      Rake::RDocTask.new("app") do |rdoc|
        rdoc.rdoc_dir = 'doc/app'
        rdoc.template = 'doc/jamis.rb'
        rdoc.title    = "Schwacke Service Application Documentation"
        rdoc.options << '--line-numbers' << '--inline-source'
        rdoc.options << '--charset' << 'utf-8'
        rdoc.rdoc_files.include('doc/README_FOR_APP')
        rdoc.rdoc_files.include('app/**/*.rb')
        rdoc.rdoc_files.include('lib/**/*.rb')
      end
    end
  

I had to overwrite the default task to use another template. I know there should be a way to use this with a simple option, but for my case it refused to use this option. I use Jamis Buck's great template, which you can find here.

And last but not least one more thing. We use email notification with our continuos integration setup and that works OK, but if you are on a Mac and wish a more integrated notification system I can highly recommend CCMenu. This is a super simple Menu Bar application which shows you the current status of your builds and you can even trigger them via the GUI.

I hope this helped some of you.

If Batman was a Ruby hacker he would definitely use this: http://utilitybelt.rubyforge.org/index.html. This is a great collection of some great IRB enhancements. Among others, like UNIX style history and a grep for method names and classes (which I really need a lot) I find this to be the most productive one, at least for me: Edit IRB content in TextMate (or any other editor) and save it back to IRB!

This is really great!

After you closed your editor window and are back to your IRB session and have something more to add you just go back and have all the previous code still there.

For me who works a lot with IRB for prototyping and testing purpose this comes in really handy. It is much easier to work with code that span multiple lines due to this helper script.

Thanks to Giles Bowkett and the other contributers of this fine collection.

See ya!

PS: I put up a little screen cast for demonstration. Enjoy!

Utility Belt Gem Screencast from Dirk Breuer on Vimeo.

In my last post I already mentioned it, we had a relaunch at pkw.de. I just wanna give this event its own post. Everybody worked very hard to get this online in a very tense timeframe. But everything went just great (as everybody can see) and here we are with a new face.

But we did not only change some colors and our layout but did some major redesign with the search interaction. Our project management is confident the new interface will be more usable because we adopt now to best practices. Being a convinced Student of Media Informatics and due to this of the Art of HCI and Interaction Design I challenge this opinion. I'm a little sad we disagreed to walk on the street of innovation but I understand the motivation from a non-technical point of view.

And even when we now just adopted some so called best practices we will of course not stop to work hard on building the best car search platform you find in Germany. And this relaunch was some important landmark on our way achieving this goal.

Enjoy it! Railsbros Dirk

Today we had a relaunch at pkw.de and due to this we celebrated a little bit. After all but Ethem and me were gone we decided our office needed some major re-factoring itself. So we rearranged our table sticked a oversized Rails poster at the wall and ... Ah, stop the talking, you say? We wanna see some pictures, you say? You are right! Here we go over at Ethem's Flickr account. Or just this picture of me sitting on the couch and drinking beer.

What will the colleagues say ... ;-)

Stay tuned!

Sometimes there is just not enough time to read all those feeds. But you try to read them later and sometimes you succeed and that happened to me last weekend while I'm was riding to Berlin. I read Dr Nics great Article about Git and decided that it this was something I should try out for myself. Of course I get myself the latest TextMate Rails 2.0 Bundle via Git as Dr Nic explained in his other post, but I wanted to have my own Git.

I asked Bumi from our friends at Railslove.com if he could spare one of those github invitations and I was very happy he could. Today I finally found some time to setup a railsbros account and port our SVN repository over to github. The address is http://github.com/railsbros/nostromo/tree/master and everything you found in our SVN you can now find over there. I'm really looking forward to play around with this a little bit and will for sure write about it.

Read you online Dirk

This week I found out that the sexy fixtures were indeed really sexy. The so far pretty random ids you got with the new fixtures style (omitting the id) isn't that random after all.

This again a pretty nice example for RTFM, cause all those blogs I've read about Rails 2.0 told you that you don't have to worry about the id of your test data. As far as I can recall they all spoke of being generated, but after reading the API docs it is more something like being transformed. They absolute value of the hash of the fixtures label. And because all your labels have to be unique all your ids will be unique.

Now knowing that I came along with a little .irbrc hack to use something like this in your Rails console:

  
User.find('my_fixture_user')
  

and it will get you the database row with the id according to that string. Of course you must have loaded your fixtures into the current environment.

For me who is an excessive user of the Rails console this is a really handy feature.

Enough of the talking, show me the code already. - OK, here you go ...

  
if ENV['RAILS_ENV']
  require 'active_record'
  ActiveRecord::Base.class_eval do
    class << ActiveRecord::Base
      alias_method :classic_find_from_ids, :find_from_ids

      private
        def find_from_ids(ids, options)
          ids.collect! { |id| id.to_i <= 0 ? id.hash.abs : id }
          classic_find_from_ids(ids, options)
        end
    end
  end
end
  

Enjoy it!

UPDATE: Andi pointed out that you can omit the assignment of the local id variable within the block. So I updated the code snippet. Thanks Andi!

Like most of you already know we both work on the project pkw.de and starting with today everybody can offer a car. We have some nice features like multiple images upload and you can move completly free during the offering process between the steps and change nearly everything. We are really all very happy about this relaunch, because it is a major step towards our (speaking of the whole team) visions of this product. And one thing is for sure, we will keep putting new features and enhancements of this great product online.

Stay tuned Your Railsbros Dirk

I put together a Sake task which allows you to create a Rails project and put directly into subversion. And the clue with this is, it asks you interactivly where your SVN repository lives and which name your project should have. Knowing this the tasks creates a directory in your Subversion repository named after your project, sets up directories for trunk, branches and tags. After that checking the trunk out as your project name, creates the Rails stubs in it, add everything but the stuff you usually don't want to see under version control (log files, temporary directory and the database.yml). In the end everything is where it belongs and you can start coding.

Hope you enjoy this little task.

  
namespace :rails do
  desc "Sake Tasks for setting up a new Rails project and put into SVN"
  task :setup_with_svn do
    puts "-----------------------------------------------"
    puts "| Setting up a Rails Project with SVN Support |"
    puts "-----------------------------------------------"
    puts
    puts "Enter your SVN URL where the Rails projects will live ..."
    print "> "
    svn_url = STDIN.gets.strip!
    puts "Enter the name of the Rails project ..."
    print "> "
    project_name = STDIN.gets.strip!
    system("svn mkdir #{svn_url}/#{project_name} -m 'ADDED - project to dir'")
    system("svn mkdir #{svn_url}/#{project_name}/trunk -m 'ADDED - initial trunk directory for the project'")
    system("svn mkdir #{svn_url}/#{project_name}/branches -m 'ADDED - initial branches directory for the project'")
    system("svn mkdir #{svn_url}/#{project_name}/tags -m 'ADDED - initial tags directory for the project'")
    system("svn checkout #{svn_url}/#{project_name}/trunk #{project_name}")
    system("cd #{project_name}; rails .")
    system("mv #{project_name}/config/database.{yml,yml.sample}")
    system("rm -rf #{project_name}/log/*")
    system("rm -rf #{project_name}/tmp/*")
    system("cd #{project_name}; svn status | grep '^? \+\(log\|tmp\)' -v | sed -e 's/? *//' | sed -e 's/ / /g' | xargs svn add")
    system("svn propset svn:ignore '*' #{project_name}/log/")
    system("svn propset svn:ignore '*' #{project_name}/tmp/")
    system("svn propset svn:ignore 'database.yml' #{project_name}/config/")
    system("cd #{project_name}; svn commit -m 'ADDED - the Rails Project has been added and all files that are not needed in the repo have been ignored.'")
    system("cp #{project_name}/config/database.{yml.sample,yml}")
    system("cd #{project_name}; rake tmp:create")
    system("touch #{project_name}/log/{development,test,server,production}.log")
  end
end
  

You can grep the tasks via pastie or via our SVN with the sake -i <URL> command.

Hi Folks!

I'm very sorry you didn't from us such a long time, but I'll promise to write more in the future. In the last weeks we had a lot to do both at work and university (especially me), but here I am and give you something to start.

I put a SVN repository online where we will publish some plugins, (more or less) useful code and some other stuff you can put into a SVN repository ;-) Feel free to browse it anytime! At the moment you will find two things there, one plugin for authentication (yes another one) and some code related to image processing. About both things I'll will write up something in the next days. Eventually the authentication plugin needs some words why we decided to do another authentication plugin ;-)

That's all for now and thanks for stayed tuned.

greetz

If you are serious about agile software development you should use continuous integration. Over there in the Java world are plenty of professional tools available to do this job. Here in the Ruby/Rails world we are suffering from a little shortcoming of those tools. Of course you can always use CruiseControl for doing the job, but some tool aware of the specific settings in a Ruby/Rails environment would be nice.

And guess what, somebody thought just the same and through such a tool right out there as an OpenSource tool: CruiseControl.rb. This great tool is maintained by the guys from ThoughtWorks Studios and provides a very simple approach to CI. It is implemented in Rails, comes with some nice plug-ins for build notification and has a convenient web-interface.

There is only one thing, I was struggling with quite a while: The tasks CruiseControl.rb runs to build your project. I know this sounds really simple and it surely is, but as I had some problems I want to share my experience. First of all CruiseControl.rb looks for a tasks named cruise in your projects Rakefile. If there is no such tasks it will look for the default task, which is in your everyday Rails project the test tasks. If you are not using vanilla testing alone but enhanced it by some test/spec testing you cannot solely use the default tasks, but you have to run an adapted test tasks. It seems kind of rational not to overwrite your test tasks, but to provide your own tasks for running the BDD test cases. And if this is not enough imagine your tests rely on a running memcached server (which some people say is a bad idea). Given all that we come to a point where leaving CruiseControl.rb guessing the right tasks to build our project isn’t a good idea anymore.

The result is the following (simple) custom tasks:

  
    desc "Task to run all required tasks to perform continuos integration with CruiseControl.rb."
    task :cruise => "db:migrate" do
      Rake::Task["db:test:purge"].invoke
      Rake::Task["db:test:prepare"].invoke

      # Restarting the memcached server for the test
      sh 'kill -9 `ps auxw | grep memcached | grep -v grep | ruby -a -e "puts gets.match(/^\\w+\\s+(\\d+)\\s+.+(memcached -d).*$/)[1]"`'
      sleep(4)
      sh 'memcached -d'
      Rake::Task["spec"].invoke
    end
  

This will run the migrate task on your development database before every build, setup a clean test database and find, kill and restart your memcached instance before it invokes our own spec tasks to run our BDD style testing.

Hope this will help some folks out there.

Dirk

I started to Twitter starting today. This will maybe help to get a little bit more in touch with this whole webcrowd thing. Maybe we will even get some more readers on this blog ;-)

Anyway we gonna see were this will lead to …

Today was one of those days I had to travel to little town of Gummersbach for a university course. I speak of travelling, because it takes you more than an hour by train to go there. Fortunately most the time you meet some fellow student to talk with. Today I met Tim and Jan which are both quite active in this whole web 2.0 social thing and everything that comes with that like BarCamps and Webmontage. Another event they are into are the idea of DevHouse. The idea behind it sounds really great: meet for 1 or 2 days in some hackish facility, get some session on the track, code some cool stuff with great people and of course all this is community driven. Due to this the fees for such DevHouse Events are quite low (nevertheless some sponsors for some things, like facility and partying, have to be acquired). The next DevHouse in Cologne will be planned over here, so be sure you drop over.

This whole idea of getting out and meet new and talented people really seems to work :-)

Stay tuned

Dirk

Last thursday we attended the first (at least at seems like the first) gathering of the ’Ruby und Rails User Group Köln/Bonn’ (that is the user group in Cologne/Germany). The meeting took place at the premises of the C4, which is for sure a great location for such a happening. We got everything we needed like WLAN access, video projector and of course Club Mate. Through some circumstances we got around to presenting our workshop we are doing normally our university. Due to the fact that the attendees were predominantly beginners in both the field of Ruby and Rails we started of with the basics: What is Ruby? How does it work (on a very sketchy level)? What is Rails? What is the idea behind Rails? How can you start off something in Rails?

Unfortunately neither Andi nor me had a MiniDVI to VGA adapter with us (we promise to change this next time ;-) ), but Moritz helped out and we could run the presentation on his linux box. That was really great, because later he was able to show some hands-on hacking during the talk. I think this really helped a lot in understanding what Rails is all about in the first place.

In retrospect I can say it was great fun and the feedback on our talk was good. And this really meant a lot to us. Although the workshops we are giving at the university are appreciated by the students (till now all undergraduates) it was nice to see, that we were able to give a spontaneous talk in front of an unknown audience without completely fail :-) Besides that we were able to identify weaknesses in the slides and our way of explaining things. Eventually we will continue with the slides next time we meet to build a stronger foundation for the beginners. Furthermore we have a little sample application (originally build for the workshop) we will share via Subversion with the group (I will provide access to the code at least through this site). Providing the slides themselves is a bit difficult: before we can share them we have to check the copyrights with the university (we got paid for doing them …).

Anyway, under the URL of the group there is a link to the mailing list. A Wiki will be available soon (so has been told) as well as a dedicated Subversion repository for projects.

We are really looking forward to the next meeting, which will happen at December 12th (or in other words: every second Tuesday of every month).

See you there and stay tuned Dirk

Today I decided to change the hosting of our Blog - away from blogg.de to a self-hosted solution based on the Rails blogging application Mephisto. A small but powerful blogging application, totally adequate for our needs. I utilized the beautiful simple template Scribbish.

There were two main reasons for switching the technique of hosting this blog:

1. Blogg.de isn't a very nice tool. The web interface is cluttered and so not Web 2.0 ;-). Using your own template is not straight forward the standard templates couldn't offer what I wanted. The Scribbish template is just perfect. Additionally we are able now to further enhance our blog with features like CodeHighlighter by Dan Webb which makes beautiful code listings possible.

2. The second reason was that I was not able to get the Blogg.de API (if this really exists) to work with TextMate ... I know this reason sound crazy, but that's what I am, I like the idea of offline editing your blog posts (even if this would be possible with TextMate's 'Edit in TextMate ...' InputManager).

We hope you like the new more then the old. Enjoy and stay tuned.

Dirk