Having considered the move for quite a while, this evening I finally decided to migrate from RVM to rbenv. The tipping point came as I was freeing up space on my laptop’s hard disk and discovered that the .rvm directory was occupying 21G, which seemed rather excessive.
Having jettisoned RVM, installed rbenv and ruby-build, I set about installing various versions of Ruby.
Despite the fact that Ruby 2.0.0 has recently been released and Matz has strongly encouraged users to upgrade from 1.8.7, which is due for end of life this June, I still have one customer I need to support on 1.8.7 for the time being.
This brings me to the point of this post. Unlike later versions, I struck a couple of problems with installing 1.8.7 with rbenv, just as I had done recently with RVM.
The solution was to use configuration options to tell rbenv where to get readline and to not bother with installing tcl and tk:
$ CONFIGURE_OPTS="--with-readline-dir=$(brew --prefix readline) --without-tcl --without-tk" rbenv install 1.8.7-p371
We are on the home stretch!
Just over a year ago I made a commitment to ensure that the inaugural Australian Ruby programming conference would become a reality. Next week, in Melbourne, it will.
RubyConf Australia 2013 will kick off with a day of workshops on Wednesday before more than 350 delegates gather at the conference to hear speakers present a variety of Ruby-related talks on Thursday and Friday.
With less than a week to go, you may wonder why I have chosen to devote time to a blog post now. You’d think I would be flat out doing last minute things in preparation. Of course I am, but I guess I thought it would be therapeutic to spend a few minutes sharing my reflections about organising the conference.
I won’t go into exhaustive detail now but I do want to emphasise several factors which have underpinned the conference organisation. Without them, I doubt we would have got to where we are today without much more pain.
That’s it for now. I’m not sure how insightful that was for you. It was somewhat cathartic for me but not as helpful as the drinks at the conference closing party will be.
Wish us luck!
One thing that the Rails community prides itself on is that test-driven development (TDD) is widely employed. But is this sufficient to produce good quality code that stands the test of changing requirements over a long period of time?
In my recent roundup of Ruby resources, Sandi Metz is one author I recommended. In her excellent talk at the 2009 Gotham Ruby Conference, Sandi contested that TDD is not enough. Sandi’s talk, which concentrates on applying SOLID design principles in Ruby, is well worth listening to in its entirety.
2009 – Sandi Metz – SOLID Object-Oriented Design from Gotham Ruby Conference on Vimeo.
As Sandi explains, central to SOLID design is avoiding dependencies by striving for code that is:
As she demonstrates applying these principles through refactoring a small Ruby application, Sandi shows that, if we want code to endure in a state that makes it fun to work with, we need to do more than use TDD. As Sandi refactors she emphasises that when we reach a point where the tests pass, we should not be satisfied. Nor should ensuring that the code is DRY be enough. Other questions that need to be asked about the class under test are:
Only when the answer to all of these questions is “yes” should we move on.
I know these are questions I should ask myself more often. As Sandi stresses, “test driven development is good, but it’s not enough.”
There’s never enough time!
I’d love to have more time to make use of all the resources I have at my disposal to learn more about the Ruby programming language.
It is eight years since I first encountered Ruby and nearly five since I moved to using Ruby as my language of choice to earn a living. So I’ve collected many different resources during those years as I have progressed through my journey to hopefully become a more proficient practitioner of the language that Matz designed to make programming a happier experience.
Recently I gave a lightning talk at the Sydney Ruby meetup (a.k.a. rorosyd) inspired by the Ruby Rogues podcast. I love the format that Charles Max Wood et al use, particularly their “picks” at the end of the show. So I decided I’d give the podcast a plug, provide some picks of my own and then open it up to the audience to share their picks.
The experience set me thinking about all the wonderful resources now available to Ruby programmers – so many to choose from. I thought I’d take the time to share my viewpoint. Hopefully you’ll take away something useful.
First of all, here are the picks I chose to share at “rorosyd” and why I chose them.
Ever since I started listening to the Ruby Rogues podcast a few months ago I have found it compelling. Regular panelists Charles Max Wood, Avdi Grimm, Josh Susser, James Edward Gray II and David Brady always present a lively and entertaining podcast. When combined with the views of their guest, the discussion never fails to leave me with lessons learned and thoughts provoked.
Even though I’m still working my way through Avdi’s book I’ve read enough to know that I can thoroughly recommend his approach. As the title implies, Avdi encourages readers of Objects on Rails to go beyond blindly using Rails and think in terms of Ruby objects. His use of what he calls Exhibits to bridge the gap between views and models is exemplary.
Although not strictly a Ruby book, it is one that I nevertheless thoroughly recommend to all Rails developers. The Rails View provides a long overdue, comprehensive coverage of the one part of the Rails MVC triad that has been often overlooked in the past. With the advent of the Rails 3.1 Asset Pipeline, this is a timely addition.
For years Ryan Bates endeared himself to the Ruby on Rails community by providing free, informative, well prepared and presented Railscasts about various Rails topics on a weekly basis. Ryan manages to summarise the essence of his topics in 10 or 15 minutes per episode. Now he has launched Railscasts Pro, and at $9 per month I consider them a steal.
Whilst there are numerous resources about how to solve various problems with the Ruby language, the Github Ruby Style Guide provides an excellent guide to the nuances of the style with which Ruby code should be formatted.
For several years I’ve been enjoying The Ruby Show, a weekly Ruby news podcast hosted by Peter Cooper, of Ruby Inside fame, and Jason Seifer. I like their informal style of banter during which they also manage to deliver a good coverage of what’s topical in the world of Ruby programming.
When I delved further into my library of Ruby resources, I found more excellent examples, some more thoroughly explored than others.
I’ve found some gems of understanding about Ruby within the articles of Practicing Ruby, which Gregory Brown describes as “an eclectic journal for the dedicated hacker”. It certainly comes under the category of “Ruby resources I’d love to fully utilise if I had more time”. If you want to explore the nuances of programming with Ruby, I thoroughly recommend Practicing Ruby.
In fact, it was within a Practicing Ruby article about SOLID Design Principles that I first came across the excellent work of Sandi Metz through a recommendation Gregory gave about a talk she gave at GoRuCo in 2009. Now Sandi is in the process of releasing her book, Practical Object-Oriented Design in Ruby. Sandi shows how to design Ruby classes so that programmers who use your code later will thank you.
How could Ruby programmer who values craftsmanship and who has already read Russ Olsen’s work not be tempted by his book Eloquent Ruby? This book guides the reader through a series of rules of thumb about how to make the most of Ruby’s many facets. For more, see the book’s companion site.
Want a thorough treatment of metaprogramming techniques in Ruby? Look no further than Paolo Perrotta’s book, Metaprogamming Ruby. It guides the reader through the fundamentals of metaprogramming before exploring the way it was used in the Rails 2.3 codebase. Also included are some useful appendices about common Ruby idioms and how DSLs overlap with metaprogramming.
At the time of writing I’m about half way through watching Peter Cooper’s detailed screencast about what’s new in Ruby 1.9. What’s really instructive is the tool that Peter uses throughout to show how snippets of Ruby code produce different results in different versions of Ruby, all as part of the same output. This is a superb way of demonstrating the improvements in Ruby 1.9. Obviously very well researched, The Ruby 1.9 Walkthrough is to be thoroughly recommended.
I’m a self-confessed fan of Peepcode Screencasts. Whilst Peepcode now covers a broad range of technologies there are some excellent recent screencasts which focus on Ruby, such as the Play by Play episodes featuring Aaron Patterson and Jim Weirich.
Finally, if you want a definitive reference, The Ruby Programming Language provides a comprehensive yet concise coverage.
The resources about the language have proliferated since 2001 when Dave Thomas and Andy Hunt helped spread Ruby beyond Japan through their book popularly known as The Pickaxe, which has been updated to cover Ruby 1.9.
Wherever you are along your journey with exploring programming in Ruby, I hope there is something in this list that you will find useful.
Last night I deployed a new release of a Rails app.
Having deployed apps built with Rails 3 or at the very least Rails 2 apps using Bundler, the experience of deploying a Rails 2.3.5 app left me with a keen desire to at least bring this app up to Rails 2.3.11 with Bundler.
One of the delights of last night’s deployment was having to update RubyGems on the target machine. Usually this is as simple as:
gem update --system
That is, unless you are forced to upgrade to a specific, old release of RubyGems. Being at Rails 2.3.5 with this app, we were in this situation.
Speaking of “not exactly state of the art”, the version of Ruby on the target machine is Ruby Enterprise Edition 1.8.6.
Obviously, the preferred option would be to upgrade to Ruby 1.9.2 and Rails 3.0.5 forthwith.
However, it’s not my money that will be funding the upgrade. First steps first. I’m aiming for the following path:
Wish me luck!
It was long overdue.
Rails 3.0.5 is out and I’ve finally bitten the bullet and upgraded this site to Rails 3 and Ruby 1.9.2. The site had its genesis back in mid-2007 as I was preparing to start my own business. Since 2008 the codebase hasn’t received much love. Indeed, I have only published articles here in dribs and drabs over the last couple of years.
So, as I embarked on this upgrade, I was aware that it also represented an opportunity to clean up some of my code as well as update third party libraries.
What follows is a story of how the upgrade unfolded including some decisions I made along the way and some lessons I learned.
My initial intention was to just upgrade the app to use Ruby 1.9.2 and attack the Rails 3 upgrade later. However, as I soon found out, getting the app to work on Ruby 1.9 wasn’t as easy as I had anticipated. Sure, using RVM it was easy to change to using Ruby 1.9.2 in development. I also chose to move to Bundler even though my intention was to stay at Rails 2.3 for now.
However, I quickly discovered that not all the plugins I was using had been upgraded to run on Ruby 1.9.
Back in 2008 when I implemented syntax code highlighting I chose to use the tm_syntax_highlighting plugin, which is based on Ultraviolet. Unfortunately, the original tm_syntax_highlighting plugin is not supported on Ruby 1.9. There is a gem derived from it that claims to support Ruby 1.9 but I failed to get this to work.
I had a look at the suggestions from Ryan Bates and, because I had been using a solution based on Ultraviolet, I considered using Harsh but soon found that it was not supported on Ruby 1.9.
At this point I decided to go the whole hog and upgrade to Rails 3. As for supporting syntax highlighting, I ended up switching to use CodeRay.
First point of call for anybody embarking on a Rails 3 upgrade has to be Jeremy McAnally’s Rails 3 Upgrade Handbook. This invaluable resource not only guides you through using the official “rails upgrade” tool but explains how to make the most of the improvements in Rails 3.
So I methodically worked my way through the upgrade to the point where I was able to start and use the Rails console. This was a real milestone but I still had much to do before I could consider my upgrade complete.
When I attempted to get the app running via a browser it quickly became evident that it was high time I jettisoned some ancient plugins.
Chief of these was the acts_as_authenticated plugin. Yes, I did say ancient. I’m aware that Devise is a favoured authentication solution for Rails 3. However, having had success in other projects with Authlogic, I chose to use it in the interests of expediency.
Another old plugin that needed replacing was acts_as_taggable_on_steroids. The acts_as_taggable_on gem proved to be an effective replacement for this with minimal changes required.
The final old plugin to be jettisoned was akismetor, which I replaced with the Rakismet gem.
I haven’t said anything about automated tests to this point. That is quite simply because I haven’t touched them. I know I should but, since this is a relatively small app that really only affects me, I decided to bypass automated testing in favour of completing the upgrade quickly. Some may scold me for this decision but I couldn’t justify the effort to myself. I’ll come back and get the automated tests working again later.
Note: If this was a larger app for a customer I would be far less inclined to bypass the task of ensuring that the automated tests work before considering the upgrade complete.
I’m glad I’ve taken the time to upgrade this app to Rails 3 and Ruby 1.9.2. It has given me the chance to:
And, of course, now I can say that I have upgraded an old Rails app to Rails 3!
Here are the slides from a lightning talk I gave at rorosyd last night. Having found RVM, Bundler and Ruby Tracker to be a useful set of tools this year, I thought I’d take the opportunity to share my experiences. And, as I mentioned during the talk, kudos to Mikel Lindsaar for his blog post earlier this year which alerted me to the power of creating a .rvmrc file.
Recently, during discussions with a client about reducing the amount of boilerplate coding that recurs from time to time in the project, the idea of developing a Domain Specific Language (DSL) arose. If you’re wondering what a DSL is, here is what Martin Fowler has to say. Or, you may prefer this cheeky piece from Dr Nic Williams.
I’ve been intrigued by DSLs for some time but not had the motivation to develop one until now.
In preparation, I’ve gathered a list of resources for writing a DSL in Ruby.
I’m happy with that list of resources but if anyone has any other suggestions please feel free to comment.
My next challenge is to think about the problem domain and design an elegant syntax.
I’ve been aware of Prawn, the Ruby PDF generation library for some time. Today was the first occasion I had an opportunity to utilise it and I was delighted with how easy it was to use.
My Ruby application needed to generate some tabular PDF reports so I installed the prawn gem and, with a little help from the examples on the Prawn home page and the core and layout documentation, I was off and running.
An example of using prawn via a rake task follows:
require 'rubygems' require 'prawn' require 'prawn/layout' namespace :report do desc "Generate top 10 points getters report" task :top10 => :environment do Prawn::Document.generate("reports/top10.pdf") do font "#{Prawn::BASEDIR}/data/fonts/DejaVuSans.ttf" font_size 14 text "Top 10 Points Getters" text " " # fetch two-dimensional array of data for the table data = Player.top10_data table data, :font_size => 9, :position => :center, :headers => ["#", "Player", "Points"], :row_colors => ["ffffff", "eeeeee"] end end end
Generating the report was then as simple as running:
rake report:top10
I’m looking forward to using other features of Prawn such as image embedding and content positioning. At the time of writing prawn itself is version 0.4.1 and prawn-layout is 0.1.0. Hopefully James Healy, an Australian noted as “instrumental to the forward development of the library”, is coming to Railscamp 5 next month. Then I can pick his brains about what other features are in the pipeline.
The fifth Australian Open Source Developers’ Conference was held last week in Sydney. In addition to helping organise the conference, I was fortunate enough to be one of the Ruby presenters.
Naturally, these slides were designed to assist my presentation rather than contain all the content. Indeed, the inclusion of some of the slides may beg some questions so I thought it may be helpful to add some explanation here.
Each of us programmers is on a specific journey, especially when it comes to testing. Early in my professional career I was taught how to unit test program modules written in PL/I. However, the drivers for those tests had to be written in Job Control Language (JCL) – an experience I am not in a hurry to repeat.
Many years later, having escaped from working on mainframes, I discovered JUnit. This was a fundamental tool in my early experience of test driven development and refactoring. When I began exploring Ruby and Rails, I was eventually introduced to autotest, which I considered another quantum leap forward in the realm of automated testing.
In 25 minutes there was obviously a limit to the number of Ruby testing tools I could cover. So, having quickly explained the benefit of autotest and touched upon Test::Unit, I moved on to describe some tools that I have used in the last year.
To make sure the audience was still awake, at this point I showed a cute photo of our family dog. My lame excuse was that he exhibits a wide range of behaviours and RSpec is all about specifying behaviour. My main example of using RSpec was for specifying a controller. This led on to a brief digression into consider what makes a good test and the use of mock objects to isolate unit tests and make them faster by avoiding unnecessary database I/O.
I was pleased to be able to include Cucumber, Webrat and Selenium in my talk. It’s only fairly recently that I started using Cucumber in conjunction with Webrat or Selenium and I’m impressed. As Mike Koukoullis showed in his subsequent talk, developing with Cucumber is a very powerful approach, which fosters clear description of intent before development of any feature.
Speaking of other talks, Alister Scott used a lightning talk to share his enthusiasm for Watir, which looks like a good alternative to Selenium.
After briefly relating the motivation for developing alternatives to relying on fixtures for test data, I described Machinist, an elegant tool recently developed by Pete Yandell. When used in conjunction with Sham, Machinist provides a neat way of generating “blueprints” that can be used in Cucumber steps.
I briefly mentioned JavaScript unit testing tools that are the subject of a blog post by Dr Nic as well as touching upon Shoulda, which is well written up by Dave Thomas.
To round out my talk, I thought it was important to offer a few philosophical thoughts. In a nutshell my view is that, whilst it is important to remember that automated testing is just one of many error removal approaches, we can all benefit from investing in automated testing.
In my case, as well as practicing using these tools, I’m also looking forward to reading the upcoming title The RSpec Book by David Chelimsky and others.
agile bundler capgun capistrano community conferences consulting css deployment design development approaches dsl estimation jaoo javascript legacy apps osdc pdf planning prawn programming rails railscamp rbenv reflections resources rorosyd ruby ruby australia ruby tracker rubyconf_au rubygems rvm standups syntax highlighting testing twitter bootstrap unconference wds08 web design xml yow