Keith Pitty

Being productive without coding

2013-04-05T12:46:42+11:00

I feel like I’ve been quite productive over the last day or so even if I haven’t written any code.

The requirements I had for a new feature were a little vague so I spent some time:

investigating third-party open source libraries (in this case Ruby gems) that may have helped
exploring the code base of our own application
talking with stake-holders in order to clarify the scope and steer the first iteration of this feature towards gaining a small set of big wins for the users
sketching a possible solution in brief notes rather than code
reviewing my intended approach with a colleague

Now I’ve reached the point where I think it’s a good time to start coding.

Different people have different approaches to solving software problems. I’m quite systematic and methodical by nature.

In any case, I wanted to share this experience because I think that sometimes it pays to spend time thinking, exploring and talking before diving into coding.

Installing Ruby 1.8.7 with rbenv

2013-03-09T00:59:40+11:00

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

Anticipating RubyConf Austalia 2013

2013-02-15T14:43:10+11:00

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.

The establishment of Ruby Australia as a non-profit organisation to support the conference (and Rails Camps) was a crucial first step. This avoided individuals being liable and clearly marked the conference as being owned by the Australian Ruby community.
The partnership with YOW! has been invaluable. They have run very successful software development conferences in Australia for several years and it made sense to utilise their expertise.
A small core group of organisers has also worked well. I am indebted to Mike Koukoullis and Martin Stannard for their collaborative support. I think we’ve made a very effective team.
Having underlined the importance of the core organising group, it would be remiss of me not to acknowledge a host of others in the community who have helped, or will be helping, in different ways at various times. They know who they are.
Another point worth mentioning was the use of a GitHub repository for collecting and managing talk proposals. I liked it’s openness, it worked well and I would recommend it to other organisers of technical conferences.
Finally, we have been able to attract more than 15 overseas presenters and sell the tickets at a reasonable price only because of the generosity of our sponsors, whom we much appreciate.

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!

Twitter Bootstrap to the Rescue

2013-01-28T13:46:54+11:00

OK, I admit it. I have finally acknowledged that web design is something I should not waste my time on.

The design of this site has gone through several phases, all my own attempts and none that I was satisfied with. So yesterday I finally bit the bullet, jettisoned my old home grown styles and images and resorted to Twitter Bootstrap.

Whilst a quick glance reveals the obvious use of Twitter Bootstrap, I’m encouraged by the result. I can now rely on a popular, well-designed, well-documented tool to produce an acceptable looking site rather than struggling with my own incompetence. For me, Twitter Bootstrap hits the sweet spot. After all, it is aimed at programmers who don’t have good web design skills.

The Conversion

For those interested in what it took to convert a Rails site to use Twitter Bootstrap, here are some of the steps I followed:

installed the twitter-boostrap-rails gem
enabled the Twitter Bootstrap responsive styles
tailored my layouts to use Twitter Bootstrap
removed my old styles
converted forms to use the simple_form gem, which supports Twitter Bootstrap
made use of the various classes in Twitter Bootstrap to easily improve the appearance of forms, buttons and tables

Responsive Design

One aspect I’m delighted with is the fact that Twitter Bootstrap supports responsive design out of the box. I’ve found it interesting that one of the barriers to adding content to this site has been it’s poor display on mobile devices. Not only did the site look ugly, but it didn’t facilitate easy browsing on mobiles.

Not any more. As a by-product of using Twitter Bootstrap, my site is now responsive!

Conclusion

Having used Twitter Bootstrap before, it was a fairly painless exercise to convert the site. All it took was a rainy day on a long weekend to finally encourage me to bite the bullet.

Now I have one less excuse for writing blog posts!

Is TDD Enough?

2012-06-11T13:51:35+10:00

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:

loosely coupled
highly cohesive
easily composable
context independent

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:

Does it have one responsibility?
Does everything in it change at the same rate?
Does it depend on things that change less often than it does?

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.”

Ruby Resources on my Radar

2012-06-06T00:44:33+10:00

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.

Inspiration

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.

Podcast: Ruby Rogues

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.

Book: Objects on Rails – Avdi Grimm

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.

Book: The Rails View – John Athayde and Bruce Williams

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.

Screencasts: Railscasts Pro – Ryan Bates

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.

Github Ruby Style Guide

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.

Podcast: The Ruby Show

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.

More Resources on my Radar

When I delved further into my library of Ruby resources, I found more excellent examples, some more thoroughly explored than others.

Articles: Practicing Ruby – Gregory Brown

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.

Book: Practical Object-Oriented Design in Ruby – Sandi Metz

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.

Book: Eloquent Ruby – Russ Olsen

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.

Book: Metaprogramming Ruby – Paolo Perrotta

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.

Screencast: The Ruby 1.9 Walkthrough – Peter Cooper

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.

Some Old Favourites

Peepcode Screencasts – Geoffrey Grosenbach

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.

Book: The Ruby Programming Language – David Flanagan & Yukihiro Matsumoto

Finally, if you want a definitive reference, The Ruby Programming Language provides a comprehensive yet concise coverage.

In Conclusion

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.

Rails Camp 9

2011-06-24T22:28:55+10:00

Phew! I’ve just about recovered from Rails Camp 9, an event that may be described as an unconference. It took place over the June long weekend at Lake Ainsworth near Byron Bay on the NSW far north coast.

For this camp, it was my honour to be one of the organisers. Fortunately, Rails Camp now has a well-established pattern and there were many organisers of previous camps willing to help and advise. And I had a terrific team amongst whom to share the workload.

Nevertheless, for the benefit of future Rails Camp organisers, I thought I’d share a few recollections of how our team went about organising Rails Camp 9.

The Organising Crew

I present the wonderful bunch of Rails hackers who all played their part in ensuring that Rails Camp 9 was, to use an over-used adjective du jour, awesome: Jason Crane, Scott Harvey, Zubin Henner, Ben Hoskings, Tim McEwan, Elle Meredith, Keith Pitty and Jason Stirk. (Trivia note: half of this crew were at the inaugural Rails Camp at Somersby in 2007.)

The Venue: Lake Ainsworth

How did we choose the venue? Once we had settled on the idea of holding Rails Camp in the Byron Bay area, the locals in the organising crew – Zubin Henner, Elle Meredith and Jason Stirk – scoured the region looking for a suitable venue and came up with only one that could accommodate the numbers we were expecting.

In many respects Lake Ainsworth was a perfect venue. Nestled between the lake and the beach it had excellent facilities for our needs. The staff were very helpful and I can really only think of two negatives: we were obliged to deal with some unexpected government bureaucracy and we had to hold the camp on a long weekend.

How we organised Rails Camp 9

Settling on the venue was half the battle. Happily, as this photo shows, we were also able to organise the essential ingredients of Rails Camp.

Thanks go to Zubin for organising the beer and Elle for organising the coffee machine. As for the coffee itself, Jason Crane ensured we had excellent beans and well trained baristas!

Speaking of essential ingredients, securing the services of Ben Hoskings to again set up the server and wifi was wonderful. Apart from one brief power outage during the weekend, everything ran as smooth as clockwork. So coffee, beer and wifi were sorted, ensuring happy campers!

Some of the other things we did to keep the organisation on track leading up to the weekend were:

Set up a Basecamp project, which may have been overkill but proved to be invaluable
Distributed responsibilities – e.g. finance, sponsorship, ticket sales, coffee, beer – to various members of the crew
Held regular virtual meetings via IRC, capturing the logs in Basecamp for reference
Used Eventbrite, Paypal and a joint bank account to manage ticket sales
Sent messages and encouraged communication via the Railscamp Google Group
Sent messages via the @railscamp_au Twitter account
Took advantage of the skills of Tim Lucas and Daniel Bogan to get the t-shirts designed and ordered
Created a simple Rails app that, amongst other things, enabled sending emails to participants via MailChimp and facilitated printing lanyard inserts
Organised buses to transport campers between Gold Coast airport and Lake Ainsworth
Created a Rails Camp 9 Twitter list
Organised a welcome BBQ (thanks Zubin) for those who arrived early enough on the Friday
Thanks to Elle and Gabe Hollombe, provided an Ideagora app for sharing interests, projects and talks

Running the event

One of the wonderful things about an unconference such as Rails Camp is that, once it starts, it is largely self-organising. The 146 participants of Rails Camp 9 decided how they would spend the weekend. Many chose projects to work on and talks to either present or listen to. Some simply appreciated the opportunity to socialise amongst like-minded people. And, of course, there were games of Werewolf to be played.

As an organiser, once the camp had started, I found my role was largely to be alert to the possibility of requests for assistance. Whilst this did keep me reasonably busy I did have the chance to catch up with and meet lots of Ruby people from around Austalia and New Zealand. I also managed, thanks to Phil Oye, to remember how to use Bananajour so that I could submit a couple of patches to Ideagora. And, there was one particularly epic game of Werewolf (thanks Carl) to remember.

Thanks to our Sponsors

A wrap of Rails Camp 9 would not be complete without thanking our sponsors. So, on behalf of the organising crew, I extend a big thank you to:

Future Australian Rails Camps

Another heartening thing about the Australian Rails Camp community is that by the end of one camp a volunteer invariably steps up to take responsibility for organising the next camp. Happily, Sebastian von Conrad did just that at Lake Ainsworth, agreeing to take possession of the virtual baton to ensure that Rails Camp 10 happens near Adelaide.

Not only that, there have already been discussions about the possibility of Rails Camp 11 in Queensland and Rails Camp 12 in Tasmania!

Committed Stand-Ups

2011-05-13T10:57:11+10:00

How effective is your daily stand-up meeting? Is it energising the team or does it have a “going through the motions” feel to it?

In his book, The Agile Samurai, Jonathan Rasmusson recommends that each person tell the rest of the team:

What you did to change the world yesterday
How you are going to crush it today
How you are going to blast though any obstacles unfortunate enough to be standing in your way

It’s a change of emphasis that I think is worth trying. As Jonathan says, it is a demonstration of commitment to the team and “dramatically increases the chances of you getting it done.”

However, if being so positive feels uncomfortable or forced, this probably indicates that there are other problems affecting the team’s morale that need to be dealt with.

On Agile

2011-04-27T23:35:11+10:00

Bingo

Before you turn off, I realise that the term “agile” in the context of software development has been overused to death. My aim is not to write a buzzword-compliant essay. Rather, having endured many projects run under the misapprehensions of outmoded assumptions and having endeavoured to get the best out of so-called “agile” approaches to software development, I feel I have a worthwhile perspective to offer.

Different Perspectives

I think the crux of discussing “agile” is to acknowledge the differing points of view of the developer and the customer. This may seem obvious but, in my view, it’s a crucial point.

The Developer’s Viewpoint

As a developer, I’ve had a lot of time to reflect upon shortcomings of the more traditional approach to building software. I well remember attending in-house courses on “Requirements, Planning and Estimating” and “Project Management” at IBM, early in my career, in the mid-80s. At the time there was much emphasis on documentation. The requirements, the external design and the internal design all had to be documented and formally approved before one line of code was written.

To be fair, in some cases, projects were divided into stages but, by and large, my experience of project management in the 1980s and 1990s was dominated by the waterfall model. The idea of iterative development had yet to hit the mainstream.

Central to the problems of the waterfall model is the difficulty in estimating accurately when grappling with initial requirements and designing an application. Usually, throughout the course of a software development project, understanding of requirements and design changes significantly. So it is very unlikely that an accurate estimate can be given at the outset. No doubt this is why estimation games have been well practiced in the software industry.

As described in Jonathan Rasmusson’s excellent book, The Agile Samurai, all projects are bound by four variables: Time, Budget, Quality and Scope. The problem with basing a software development project on the waterfall model is that this often leads to an expectation that all four variables will be fixed. Given the inherent difficulty in accurate software project estimation, this is obviously unrealistic.

The agile approach addresses these problems by treating scope as the only variable and delivering software in frequent iterations. As shown in Extreme Programming Release Planning, which I first experienced about ten years ago, requirements are broken up into “user stories”, each of which is estimated and prioritised.

A key point is the unit of estimation. In the agile approach, it is not a measurement of actual work hours which may be translated into a monetary amount. In original XP planning, the unit was an ideal week. The name of the unit may be arbitrary. It doesn’t matter what you call it. What really matters is that each user story is estimated relative to others. This enables allocation of user stories to releases more accurately as the developers discover roughly how many units they can complete in each iteration. Also, since iterations are kept small in duration, user feedback allows timely modification and exploration of user stories that will comprise subsequent iterations.

All the elements of agile planning make sense to me as a developer. However, a customer, not necessarily used to software development, may be less easily persuaded.

The Customer’s Viewpoint

As a customer, speaking generally, I expect value for money. For most goods and services I am used to having a fixed-price quotation honoured for clearly agreed specifications.

Why should I expect any different for software development? If I ask how much it will cost for a specific software application to be built, why should I not expect the supplier to let me know in advance?

What’s this talk about estimating requirements in terms of arbitrary points? And what’s this I hear about pair programming? Do you seriously expect me to pay for two developers working on the same piece of code at the same time?

At this point I should emphasise that I am trying to think of various customers that I have dealt with over the years and put myself in their shoes. As I do that I am reminded that these customers have had various degrees of acquaintance with the complexities of developing software. I think that this gets to the heart of the matter. As a customer, if there is a good reason why I should not expect a fixed-price quotation then the developer must be able to explain that reason clearly to me.

After all, the customer is paying the bills. Any argument for embracing an agile approach must be compelling in monetary terms.

Bridging the Gap

When we consider the agile approach to software development, I think it is clear that there is a gap between what proponents see as benefits of this approach and the expectations of many customers.

If you’re still with me, you may be expecting that at this point I will reveal my brilliant answer to the conundrum. I am sorry to disappoint you. If there was a brilliant answer I am sure someone else would have capitalised on it before now. Obviously, it is critical for an agile software developer to clearly describe to their customer at the very beginning of an engagement what to expect. As with so much in life, setting expectations is crucial. It is a lesson I need to keep reminding myself.

Every customer is different. Every relationship will differ. And relationships change over time. I forget where I read it, but the essence of the quote was that “in a good agile relationship, trust improves with every iteration”. I like the spirit of that statement.

It is also important to allow your approach to evolve. As Ben Webster said recently, “embracing as many mistakes as possible on the job” is a useful resource as an agile practitioner.

In Conclusion

To borrow from The Mythical Man-Month by Fred Brooks, there is no silver bullet. Making the most of the agile approach to software development requires an individual response. If you would like to share elements of yours, I look forward to your comments.

Maintaining a Legacy Rails App

2011-04-05T22:02:19+10:00

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:

Rails 2.3.11 with Bundler and latest compatible gems.
Ruby 1.9.2
Rails 3.0.5

Wish me luck!

Reflections on YOW 2010 Conference

2011-03-04T00:38:09+11:00

Introduction

Perhaps I needed time to reflect on such a wonderful conference.

Ever since the YOW! Developer Conference in Melbourne last December, I’ve been meaning to share some of my impressions. It may be three months down the track but I’m finally getting around to it!

Five Favourite Talks

The conference deserved praise for many reasons but I’ll narrow it down to some brief reflections on five talks that impressed me for different reasons.

Neal Ford

A small percentage of Rails developers have the opportunity to work in teams developing large, enterprise-scale apps. A not insignificant number of aspersions have been levelled at Rails, claiming that it can’t scale. So it was refreshing to hear Neal Ford talk about Rails in the Large, based on his experiences leading a team that has built arguably the biggest Rails app in the world.

Neal’s invigorating talk reviewed the lessons learned in the project such as effective testing strategies. For example, he unsurprisingly impressed the audience by relating how, with the help of UnitRecord, the team was able to run just under 9,000 tests in 41 seconds! Neal described other testing techniques as well as strategies for aspects such as continuous integration, effective communication in a development team and automation. Crucially, he emphasised ingenious ways that the team kept a sense of fun to the fore at all times.

There were many more nuggets that this talk contained. If you get the chance to hear Neal speak I thoroughly recommend it.

Keynote by Guy Steele and Richard Gabriel

I cannot find the words to adequately describe the gem that was the 50 in 50 keynote by Guy Steele and Richard Gabriel.

So I’ll keep my reflections brief. Wise, well-informed and witty, this talk by Guy and Richard was rich in its perspective of the often weird and wonderful paths that computer languages have followed over the last 50 years. A perfect tonic to prepare us for the conference party!

Eric Evans

Getting a message across through dry humour is a gift which Eric Evans demonstrated amply in his talk entitled Strategic Design: Avoiding Responsibility Traps.

Eric led the audience through a story about several sub-optimal scenarios that can eventuate when a software development team is faced with the challenge of augmenting a legacy system. His key messages included the importance of distilling the core domain, using context mapping and building an anti-corruption layer. Eric’s parting recommendations were to:

look for assets in the legacy
work in the core domain

And, of course, to make use of his book, Domain-Driven Design, even if only to read Chapter 14.

Jason Yip

I love the tagline on Jason Yip’s blog: “Making software is about making people.” So true.

Jason’s talk, Row Together, Row in the Right Direction, Row Faster: Improving alignment and throughput in software development, tuned into vital aspects of collaboration, whether at the level of a team, department or organisation.

After setting the stage with a few amusing but relevant anecdotes, Jason expanded on his contention that groups of people maximise their collective effectiveness by:

being aligned and coordinated;
sharing the same direction and vision;
improving productivity by mastering skills

Jason emphasised that what he had presented was intended to be more of a useful metaphor than the result of rigorous analysis. It would be interesting to see Jason’s observations validated by quantitative research. Meanwhile, I’m glad I listened to Jason’s typically thoughtful, entertaining and thought-provoking talk.

Dan Ingalls

As someone who, when first exploring object-oriented programming cut his teeth on Smalltalk, I was fortunatate to be able to listen to Dan Ingalls reminisce about his Forty Years of Fun with Computers.

It was amazing to listen to Dan speak so humbly about his experiences when they included working with Alan Kay and attending lectures given by Don Knuth, not to mention being the principal architect of five generations of Smalltalk environments. Regardless of all his achievements what shone through above all was his enduring sense of fun. I won’t attempt to describe the specifics of Dan’s talk. Suffice to say it was a privilege to be there and a special way to end the conference. If you get the chance to hear Dan speak, grasp it!

Dan concluded his talk with this wonderful advice:

“Keep things simple, general and flexible and you’ll have fun.”

A Conference to be Recommended

So there you have it. Five of my favourite talks from the YOW! Australia 2010 Developer Conference.

Belated congratulations to Dave Thomas and Lisa Cumes from Bedarra Research Labs for attracting such a superb collection of speakers covering a broad range of topics. The whole conference was a blast and I certainly wholeheartedly recommend the 2011 edition to other Australian developers.

Upgrading to Rails 3

2011-02-27T20:53:10+11:00

Introduction

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.

Ruby 1.9.2

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.

Syntax Highlighting Adventures

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.

Rails 3 Here I Come

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.

Time to jettison old plugins

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.

Some comments about testing

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.

Reflections

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:

replace old plugins with more recent gems;
take advantage of Bundler;
practice upgrading to Rails 3;
position the app for further code improvements courtesy of Rails 3 and Ruby 1.9.

And, of course, now I can say that I have upgraded an old Rails app to Rails 3!

RVM, Bundler and Ruby Tracker

2010-08-11T12:11:34+10:00

Lightning Talk at rorosyd

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.

RVM, Bundler and Ruby Tracker

View more presentations from Keith Pitty.

Ten Years On

2010-02-10T22:28:00+11:00

Ten years is a long time in technology.

Recently, on New Year’s Day, whilst waiting for the Spirit of Tasmania to leave Devonport after a family holiday, I was killing time on Twitter. Several tweets with the tag #10yearsago set me thinking. For a start, ten years ago I’m sure I wouldn’t have dreamed of using an application like Twitter on a device like an iPhone.

Turning my thoughts back in time, I wondered what was significant about my programming career at the turn of the century? After a little thought and stroking of my greying beard my response was that 10 years ago I was leaving mainframes behind and about to enter the world of EJBs. For me that was quite a milestone. After earning a living within the realm of IBM mainframe programming since 1983 and delving into object-orientation and the emerging world of web development during the 1990s, the transition to working full-time with Servlets and Enterprise JavaBeans was an exciting step.

Fast forward to the present and it would appear that I have left the Enterprise Java world behind. Over the last couple of years I haven’t used Java in anger, instead using Ruby as my language of choice in conjunction with frameworks like Rails and Sinatra for developing web applications.

You may have noticed that I’ve only mentioned server-side technologies so far. This is not just because I have felt more at home developing server-side rather than client-side software. When I started down my path of developing web applications, JavaScript was the subject of scorn for valid reasons that I won’t elaborate on here. However, in 2010 I can see that JavaScript is definitely growing in importance. Developer-friendly libraries such as JQuery that have been well tested on all major browsers have changed what JavaScript brings to the table. Ajax has earned it’s place in web applications. RaphaÃ«l is an example of sexy visual effects that can be added to a site via a JS library.

So I have becoming aware that I need to focus more on improving my JavaScript skills to better equip me to enhance user experiences of web applications via JS that runs in a web browser.

But it turns out that my reasons to learn more about Javascript aren’t confined to web browsers. Late last year I became aware of Node.js, which enables the development of event-driven servers using JavaScript. I’ve barely scratched the surface but I know that others, like Simon Willison, are very excited by Node.

Meanwhile, I’m going back to fundamentals and have started reading PPK on JavaScript to give me a more solid basis on which to build my JS skills.

So ten years since I left mainframes behind to enter the world of EJBs I love programming in Ruby and am giving more focus to JavaScript. As for trips down memory lane, maybe another time I’ll write about the technology I was using 20 years ago…

Configuring CapGun

2009-10-10T01:11:00+11:00

I’ve long been a fan of Capistrano, the Ruby deployment tool that is typically used for deploying Rails applications. And I’ve also been impressed by the work of Glenn Vanderburg and his colleagues at Relevance. So I took notice when I recently read about CapGun, which is useful for sending email notifications whenever a project is deployed.

The point of this post is that very recently I had the opportunity to install and configure CapGun for a client. The blurb on github told me how to install and configure CapGun. Under the heading of Usage I was encouraged to read the first paragraph:

Good news: it just works.

Well, almost. CapGun does “just work” once you’ve configured it correctly. Included in the config sample to be added to deploy.rb was:

# define the options for the actual emails that go out -- :recipients is the only required option
set :cap_gun_email_envelope, { :recipients => %w[joe@example.com, jane@example.com] }

Unfortunately this was not quite complete enough for CapGun to work. Instead it died deep in the bowels of net/smtp.rb:

/usr/local/lib/ruby/1.8/net/smtp.rb:930:in `check_response': 555 5.5.2 Syntax error. 7sm1592402qwb.55 (Net::SMTPFatalError)
	from /usr/local/lib/ruby/1.8/net/smtp.rb:899:in `getok'
	from /usr/local/lib/ruby/1.8/net/smtp.rb:828:in `mailfrom'
	from /usr/local/lib/ruby/1.8/net/smtp.rb:653:in `sendmail'
	from /usr/local/lib/ruby/gems/1.8/gems/actionmailer-2.3.4/lib/action_mailer/base.rb:684:in `perform_delivery_smtp'
	from /usr/local/lib/ruby/1.8/net/smtp.rb:526:in `start'
	from /usr/local/lib/ruby/gems/1.8/gems/actionmailer-2.3.4/lib/action_mailer/base.rb:682:in `perform_delivery_smtp'
	from /usr/local/lib/ruby/gems/1.8/gems/actionmailer-2.3.4/lib/action_mailer/base.rb:523:in `__send__'
	from /usr/local/lib/ruby/gems/1.8/gems/actionmailer-2.3.4/lib/action_mailer/base.rb:523:in `deliver!'
	from /usr/local/lib/ruby/gems/1.8/gems/actionmailer-2.3.4/lib/action_mailer/base.rb:395:in `method_missing'
	from ./vendor/plugins/cap_gun/lib/cap_gun.rb:70

The lesson was that the :cap_gun_email_envelope needed to be configured with :from as well as :recipients. And the good news is that the people at Relevance have just accepted my documentation patch.

And the even better news is that now CapGun does “just work”. It’s a very handy tool for keeping everyone in a team informed about deployments in an automated and timely manner.