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:
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.
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!
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.
For those interested in what it took to convert a Rails site to use Twitter Bootstrap, here are some of the steps I followed:
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!
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!
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.
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.”