The Rails Brothers

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

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

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