2011: A polyglot programmers journey

At Storm we like our developers to be polyglot programmers. We believe knowing a wide range of languages, APIs and toolsets makes for better programmers and ultimately, better deliverables for clients. It means we can pick the most appropriate tool for a task and deliver an excellent final product. As the old saying goes, ‘if your only tool is a hammer, everything looks like a nail’ – and that’s bad.

So, what have I learnt this year to add to my programming arsenal?

Continue reading

Things Storm bookmarked this week / 02-11-11

This week…

Dave tells ms that iMessage is coming to OS X: “iMessage is Apple’s new messaging solution for the iPad, iPod Touch and iPhone found in iOS 5. It allows customers to send SMS-like messages over standard data connections rather than expensive text messaging plans.” Also: “AirPlay mirroring is going to mean that meetings around the Storm flatscreen are going to be wireless :-) Can’t wait.

Liam chucked me a super-nerdy bookmark – the guide to Rails 3.1′s asset pipeline. I have no idea what this is so I’ll let him explain: “It’s a pretty scary concept to someone who learnt rails with static content in the public directory, but things like less will change your CSS developing life“.

From Paul – a live coding video from Ryan Biggs building some of an implementation of Conway’s Game of Life in Ruby using a Test Driven Development approach with RSpec: “It’s a good (if slightly long) intro to how to use RSpec, and the basics of TDD.

Adam pointed me to this rather useful “avoiding common mistakes using the new HTML5 elements and attributes” article. Handy.

For me, an oldish but very useful set of printable wireframing templates for hand-sketching new sites and mobile apps.

Generating code coverage metrics for a Ruby on Rails project with simplecov

As part of my dive into unit testing Rails applications I was keen to set up a tool to give me code coverage stats.  Code coverage represents the % of your source code that your unit tests exercise.  100% code coverage is a good goal to have and the earlier you hit it, the more likely you’ll find testing a worthwhile endeavour.  Whilst 100% coverage doesn’t guarantee that you’ve tested every permutation in your app, not having 100% coverage guarantees there are bits where daemons may be lurking.

Continue reading

Stop autotest continuously re-running your Rails tests

I’ve been getting up to speed with writing unit tests for Rails applications today.  My setup currently consists of RSpec tests being automatically run by autotest when I save a file.  This is a really nice workflow as you get instant feedback on failing tests.  Couple that with the autotest-growl gem to receive Growl notifications on failure and you’ve got a pretty funky setup.

However, autotest decided it wanted to re-run my tests over and over again, even if I hand’t saved a file in my project.  This had me very confused for quite a while until some Googling led me to ‘autotest -v’ which shows you which files had changed.  The culprit: test.log.

Continue reading