Setting Up an iMac Pairing Station for Rails Development

April 22nd, 2010, by Aaron

I used this post today as a guide on how to get another iMac up and running so I thought it was probably a good point to chuck this up here, if only for our own reference.

We are starting with a 27″ iMac and a base Snow Leopard install.

The first step was to install Xcode from the Snow Leopard disc, you’ll find it in the Optional Installs part of the disc.

Ruby and RubyGems comes with Snow Leopard by default so we’ll use them. You’ll likely need to update the RubyGems system :

    sudo gem update --system

Now we can install Rails :

  sudo gem install rails

This will install the latest stable version of Rails. We need a specific version for some of our applications (until we’ve tested it under the newer version) and you can do this by adding the -v switch :

  sudo gem install rails -v=2.3.4

After this we can switch on Apache and install passenger, the module that runs Rails on Apache. So turn on Web Sharing in the Sharing panel of your System Preferences.

  sudo gem install passenger
  sudo passenger-install-apache2-module

This will compile the Apache module and give you some text to paste into your apache conf file to load it. I keep this in a separate config file in /etc/apache2/other/passenger.conf. It should look something like :

  LoadModule passenger_module /Library/Ruby/Gems/1.8/gems/passenger-2.2.8/ext/apache2/mod_passenger.so
  PassengerRoot /Library/Ruby/Gems/1.8/gems/passenger-2.2.8
  PassengerRuby /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby

Next download the Passenger Preference Pane so you can control your Rails sites from the OS X Preferences area. You can get it from http://www.fngtps.com/passenger-preference-pane. You should now be able to run Rails websites on your local machine very easily.

We use Git for our source control and Git X is the best GUI for this on OS X at the moment. You can download Git for OS X from http://code.google.com/p/git-osx-installer/ and you can get GitX from http://gitx.frim.nl/.

I like to use a Pomodoro timer when pairing and the one I like the best for OS X is just called Pomodoro Desktop. It will keep people focussed and also can serve to keep the control swapping in a fairly regular way. You can find out about how Pomodoro works here.

We use Github for our repository and exchange is done via SSH, so you’ll need to generate an SSH key and put that into your Github account.

  ssh-keygen
  cat ~/.ssh/id_rsa.pub

Copy the output and put that into your public SSH keys in Git Hub.

When pairing with Git the ability to have both parties responsible for the work they’re doing is appreciated sometimes. Especially twelve months from now when you can’t remember why you did something. Not that you don’t comment your code, or always write beautifully understandable code. There is a nice gem called hitch. It comes out of Hashrocket and handles the ‘hitching’ and ‘unhitching’ of partners on a machine. We have a pairing station so generally we just want to change the pair that’s in operation, so it works well. You’ll need to be inside a git repository to do the initial setup. I cloned one of our projects and then you issue :

  hitch -m

Which will prompt you for your main email address, this is the email address that all devs in your team receive, or a group email of some sort.

Now to hitch two devs you’d do :

  hitch dev1 dev2

This will prompt you for names of the dev1 and dev2 users so that they’ll be displayed in your commit. It’ll also associate your commits to the email address devs+dev1+dev2@company.com if you setup devs@company.com as the email address when you issued the hitch -m command. If you setup gravatars for all your devs+user1+user2@company.com email addresses then you’ll get a nice picture in Github too.

I think that’s about it really. We obviously just install gems as required and make customisations on a per developer need. We generally use Textmate for editing so this means installing a theme (we use the Railscast theme) and the relevant bundles for Rspec, Haml and Sass.

We are a Perth web design and web development company and this is our blog. We specialize in building web applications with the Ruby on Rails framework. Jump to the Ruby on Rails category or contact us.


Problems with DateTime, TimeZone, Bundler and Rails 2.3.5

April 21st, 2010, by Aaron

I’ve been converting a Rails 2.3.5 project to using Bundler and ran into a bit of a snag this week. I was getting a over 300 failing tests with errors such as :

uninitialized constant ActiveSupport::TimeWithZone

and

no such file to load -- tzinfo

I couldn’t find anything that I’d missed, I’d moved all my gem declarations from the various environment files into my Gemfile and hadn’t had many issues (many) but this was a really odd problem. It was as if part of Rails wasn’t being loaded correctly.

It turns out that you need to include a tzinfo gem for some reason. Don’t ask me how I ran across the solution for this issue, I really can’t remember. It works though.

So if you’re having issues with your app, or tests not passing due to time zone issues in Rails 2.3.x using Bundler then just include :

gem "tzinfo"

In your Gemfile, run another bundle install and away you go. It worked for me, I hope it works for you!

We are a Perth web design and web development company and this is our blog. We specialize in building web applications with the Ruby on Rails framework. Jump to the Ruby on Rails category or contact us.


Ruby on Rails Perth Meetup

February 2nd, 2010, by Aaron

Every third Thursday of the month we have a Ruby on Rails meetup at our offices. It’s a bit of a mix of some socialising and some tech sharing. A few of the guys share the same woes in trying to run a small business, or deal with clients, or implement some particular solution so it can sometimes end up being quite a mixing pot for solution finding and solution sharing.

I think in the year 2009 we’ve seen the group grow from a meeting of somewhere around 4-8 people each month to sometimes around 30. In December to celebrate a successful year of growth in the Perth Ruby community we went on a pub crawl down Barrack and Beaufort St, everyone seemed to have a lot of fun and it was good to take the show on the road. Generally we keep the drinking and tomfoolery inside the bounds of our office.

You can find out some more information at the meetup site but generally we get between 15 to 30 people attending and there will be talks ranging from using Capistrano for PHP deployments to Behaviour Driven Testing and a lot in between. In January we had talks on using Sinatra to setup some simple Javascript unit testing, using Sinatra and Rake to setup a simple management interface, and using Soap4R to interface with SOAP APIs.

The meetup is held in Unit 9, 1010 Wellington St from 5pm onwards. Beers and snack food are provided, you just need to bring yourself and a willingness to exchange ideas! The next meeting will be on February 18, 2010.

We are a Perth web design and web development company and this is our blog. We specialize in building web applications with the Ruby on Rails framework. Jump to the Ruby on Rails category or contact us.


Using RSpec Example Groups for Common Functionality

January 13th, 2010, by Aaron

I’m currently getting into using RSpec for testing our controllers on what is turning into a large project. It’s been more than handy because we have a lot of complex scoping to take into account whenever retrieving data. People don’t like to see other peoples’ financial data, mostly because it implies that someone is probably looking at theirs. With this in mind it’s more than important that we know the right data is going to the right places and hence the need for controller testing.

Now most of our controllers require the user to be logged in so writing tests to check this for every controller is annoying and time consuming, more than that it feels dirty. I think this is what some people call a code smell though I’m not up to speed on buzz words. There are also other tasks that are done quite often such as setting up the various types of users we’d like to test as, it would be nice if this were easily put in one place and could be easily pulled in. I guess I was looking for a template of tests that I could share.

It seems that the solution to it is found in Shared Example Groups which I hadn’t heard very much discussion about and it kind of leaves working out how they work to you rather than documenting it too much.

So far I’ve used it simply to make sure that controllers that require are redirecting users appropriately and also for setting up a specific type of user for our system before testing.

I created a directory under /spec/support called example_groups and in there I have a file called login_groups.rb. In that file I have something like the following :

shared_examples_for "customer is logged in" do
  before(:all) do
    @user = Factory(:customer_user)
    @user.customers.push Factory(:customer)
  end

  before(:each) do
    activate_authlogic
    OperatorSession.create(@operator)
  end
end

Now in my spec files when I have a bunch of tests requiring a logged in customer I will include this little snippet :

  it_should_behave_like "customer is logged in"

I get a logged in customer to start playing around with. I have the spec/support/example_groups directory in my include paths for Rspec and so it just all works.

My tests can then start to look like :

describe MerchantsController do
  it_should_behave_like "areas requiring login"

  context "customer logged in" do
    it_should_behave_like "customer is logged in"

    ... insert other tests here ...
  end
end

It means I can swap in another authentication gem/plugin pretty easily and also encapsulates the logic about creating customers, or whatever type of item you want to use, so that if that changes you can swap things in and out with a minimum of fuss.

Just to be clear, example groups aren’t limited to setup tasks or connecting to before/after hooks, you can also include a bunch of tests as well. This allows me to have a bunch of tests to run to make sure that a user does have to be logged in for various controllers and include these tests in on line.

I hope this helps someone, it took a bit of searching and trial and error myself this morning to get it working and find the uses for it that I’ve found. I’m definitely open to better solutions to this sort of issue though.

We are a Perth web design and web development company and this is our blog. We specialize in building web applications with the Ruby on Rails framework. Jump to the Ruby on Rails category or contact us.


Why Your Clients Should Upgrade Their Web Browsers

December 3rd, 2009, by Aaron

I think the IT industry has a tendency to push our clients and users to upgrade, or change things to suit our requirements or desires. Often times the reasons may be rooted in practicality, but as good IT workers tend to develop heuristics for problem solving they can sometimes find it hard to explain their reasoning.

A good example is browser upgrades. We all know it’s a worthwhile suggestion, and having the latest browser is the best option in most cases, but explaining that to a user or client can be difficult. It can be especially difficult if you don’t have face time with a user; the most common situation in the web environment.

Telling a user that the site works better in Firefox 3 or Safari 4 will, perhaps, just lead to the user finding a site that works better with their browser instead. It would be nice if we tried a different tact, and in doing so helped not only ourselves, but the wider community of developers. After all we want the same outcome : to have our work viewed the way we intended, for the minimum amount of work. Cross browser development sucks!

I was thinking the other day that I don’t think I’ve ever heard from a developer that users should switch browsers for security reasons, or any other reason the user would care about. Users don’t care about ACID compliance, or Javascript optimisations or any other technicalities. What they do care about though is security, especially now that mainstream operating systems, manufacturers and financal institutions have gotten the word out about phishing and other vulnerabilities.

  • All the latest browsers support some form of malware protection and anti-phishing protection. This increases user security.
  • All the latest browsers concentrate on process isolation and run time optimisations. This decreases crashes and increases browsing speed.
  • All the latest browsers have been improving standards compliance. This increases the likelihood that more sites will work for the user.
  • All the latest browsers manage their own update process. The user isn’t required to remember to stay up to date in the future.
  • All the latest browsers have the latest patches and updates and latest features. This gives the user the most secure, fastest, and feature packed experience.

We all know that unless you have a very good reason, it’s silly to be running an old browser. However when was the last time you explained the benefits for them personally? Increased security, increased stability, increased speed, more compatibility with other sites and the latest features available.

If you find a better way to sell your clients on spending 5 minutes to upgrade their browser then make sure you spread the word. Every user you convert is a win for the web community and the internet in general!

We are a Perth web design and web development company and this is our blog. We specialize in building web applications with the Ruby on Rails framework. Jump to the Ruby on Rails category or contact us.


Follow Us

Stay in the Loop

  • Enter your email address to subscribe to our mailing list. You'll get updates about our products, specials and bonus offers, and general behind the scenes news from our team.

Twitter

Facebook Fans

Newsletters

Alexa Rank

Testimonial

The boys at The Frontier Group are amazing! For such a relaxed and personable organisation, they have phenomenal technical ability and a rampant professionalism. They have customisable solutions for all of my IT needs and they always deliver, on time and beyond expectation.

They fix problems other service providers can't and they helped me get a critical section of my web site up and running 10 minutes after I emailed the request!

Alex Hyndman, Nexus Car Share.

Featured Project

Case Study - Caudo Group - www.caudo.com.au

Website

www.caudo.com.au

Caudo Machinery

Caudo Group engaged our services to redesign their outdated website. We sent our photographer on-site to capture the essence of their business and turned it into a stunning web design.