Matthew Lang

Skipping the TDD cycle isn't always a bad thing to do. After all, sometimes you just want to write code.

Over the holidays I had some free time. An idea has been in my head for most of the year, but I never got round to scheduling anytime to work on it. I decided now was the chance to throw something together to see if this idea was worth exploring. To change things up a bit I decided to not follow my usual practice of TDD. Some might call that laziness and that might have been a minor factor, after all it was the holidays and this was just me trying something out, but the major factor in skipping TDD was that I had the knowledge to build the application quickly. Over the course of a couple of days I put together the first attempt at implementing this idea.

Aside from a couple of typos and minor bugs, the application is working fine and doing its job. The bugs were just oversights made by myself during those two days and they were easy to fix once found. I'm not surprised by the this as it is a simple application comprising of some basic CRUD operations and a single Rake task. Once everything was looking good, I deployed the application so that I could see it running for a few days. After a week it was clear that all was in working order. I've shared the idea with a couple of people who have so far been positive about it.

Now being a good developer I mostly write tests before I write code. It's the TDD way. This time though I skipped the tests in favour of getting something basic up and running. I had the knowledge and I ran with it. It was supposed to be just a prototype after all.

In the past I've stuck with using TDD when building even the smallest of products. At that point in my career however I was a less experienced developer. I was still figuring things out. The tests made sure that everything was working as I stumbled through different parts of the product. Now though, I have the knowledge and confidence to throw small web applications together without writing tests to in order to explore simple ideas for web applications.

Is it still a prototype then now that it has been shipped and is being used daily? Yes and no. The line between prototype and product is definitely blurred here. I would have to say that until the code itself was backed by a test suite, it's still just a prototype, an idea. So why not trash the code I have at the moment and start again from scratch using TDD?

I could, but I already know what code I need to write. Do I really want to scrap the whole thing knowing that I'm just going to write similar code again? In an ideal world I would probably do this but I knew it would be a while before I got free time like this again. The next obvious step then would be to add tests to the prototype and gradually refactor this code into something more stable. Something ready for the masses.

TDD is still a great practice to follow when writing software, but I think there's a time and a place for it. When writing software as part of your job, for a client, or as a contribution to an open source project, then yes, TDD should be used in these cases, especially if they are expected of you. However, when you are exploring code, ideas and simply playing around then I think it's down to yourself to decide. And if you decided not to TDD, don't sweat it.

TDD might be advantageous when learning a new language or framework but when you have the knowledge to build something quickly then why not. If it's worth pursuing further then start writing tests for the code that you have before things start to get more complicated.

It was a bit of a double win today for me and my son. We each got good news today that have changed how we're viewing the rest of the year. I'm looking forward to seeing what this will end up for both of us. I'm staying tight lipped at the moment on both sets of news but I'll be sharing both of them in due time.

I've been thinking for a couple of week now about learning Rust, but something that's been bugging me has been what to build with it. Rather than focusing on what to build first, I should really be focusing on learning Rust first.

This sketchbook of implemented ideas isn’t a paper book, but a collection of small programs. It could be as simple as a folder full of Python scripts or Erlang modules. It’s not about being right or wrong; many ideas won’t work out, and you’ll learn from them. It’s about exploring your interests on a smaller scale. It’s about playing with code. It’s about having fun. And you might just become an expert in the process.

— A Developer's Sketchbook for the Twenty-First Century by James Hague

Setting a goal for the year is made by many at the start of each year, but people frequently give up or just abandon their goal because it seems too far away. With a little change in tact though, there's a better way of hitting your goals for the year.

Set Smaller Goals

Instead of focusing on big goals for the year, what about setting smaller goals for throughout the year? Smaller goals are within easier reach, easier to track and it means that if the goal isn't hit you can try again the next month.

When goals are set for the year, people usually forget to set aside regular checks to ensure they are on the right track. After a few weeks many people simple give up. With smaller goals though, you can set yourself a more manageable and attainable goal that will give you the confidence to succeed on subsequent goals.

Continually Refresh

The start of the new year is traditionally seen as the only and best chance to start afresh but there's more than one opportunity available in the year to do this. New year, new month, new week or even new day. There's more opportunities to start afresh than you think.

If you set yourself goals for smaller periods of time then you give yourself more chances to achieve that goal. Right okay, you didn't do that bike ride in the time you wanted for January. Could you do it in February though?

The chance to start afresh is there every day, every week and every month. You just need to decide what you can realistically achieve in those periods of time.

... with NB.

Surprise them. Shock them even. Don't even complain once. About having eaten too much, the vacation being too short, the ridiculous queues at Starbucks on New Year's Eve afternoon. Don't let that stuff get to you. It's a little friction in the wheels of life. It may be the first week back. Heck it's the first Monday of the new year.

— Back to Work? by Nicholas Bate

Click through for the reason why you do this.

In this roadmap are many questions. In your journal — whether digital or by hand — you can simply write out the question at the top of the page, and answer as if having a conversation. Don’t worry about formality, how it may sound out loud, grammar, etc. Just write your thoughts. It may seem mundane, but there is a magical quality in writing something down that cannot be fully explained. You just have to trust me and try it out.

— Jumpstart Your Journaling: A 31-Day Challenge by The Art of Manliness

What a terrific idea. A roadmap of journal prompts to build up a journaling habit.

I would have to say that the Jack Ryan reboot was by far my most disappointing movie of 2014.

Chris Pine seems suffocated to be playing the straight-man hero (he is more at home in Stretch and Into the Woods), Kenneth Branagh is really not Russian, and really you just want to weep for Keira Knightley, whom everyone assumed would have a secret role to play in the film but is merely there to have a light bulb shoved in her mouth while she tearfully waits for her man to save her.

— 'Exodus,' 'Maleficent' And The Worst Films Of 2014 by Forbes

My own cinema going experience for 2014 was limited, but I'm glad to see there's a few must-see movies for 2015. Roll on 2015!

Sadly I failed to completely fill a whole notebook this year. Seems like a trivial goal to have, but having a notebook full of notes, ideas, mind maps and lists gives you more book than a notebook only partially filled with notes and other stuff. Armed with these suggestions though I'll have a better chance at finally filling a notebook.

via The Cramped

I was on a roll there for a while, but it's been difficult to get that consistentcy back again. I am working on it, it's just the hovering over the publish button that has frequently held me back.

Software engineers should write because it promotes many of the same skills required in programming. A core skill in both disciplines is an ability to think clearly. The best software engineers are great writers because their prose is as logical and elegant as their code.
— Software engineers should write by Shubhro Saha

Resolutions rarely affect only ourselves when we make them. Patrick makes a good point of getting those around you to help support your resolutions.

And even those things you think are just for you — to exercise more, to eat better, to meditate — may not be able to be successful without our partners actively supporting those efforts and allowing us the time, space, and resources to achieve them. Accountability helps here too. If those around you know them you are more likely to be held to the goal.
— Resolutions don't happen in a vacuum... by Patrick Rhone

Ending Fixie Friday 2014 with a lovely Pelizzoli.

via FGGT, photo by Father Tu

Boxing Day: a day where you avoid anything too clever and start by reflecting on (1) identifying the boxes in your life and (2) checking what's inside them.

— Jagged Thoughts for Jagged Times 130 by Nicholas Bate

I already have too many boxes. Perfect timing to de-clutter.

An early Christmas present from Arizona. All you need to know to get things done.

It turns out, 31-year-old me who’s played a handful of sports in adulthood is substantially more coordinated than 17-year-old me who’d played none and was suddenly five inches taller than before.

— Clear Your Mental Cache by Thoughtbot

Is it time you re-visited those things that you think you know about yourself?

Read from the best, read from Nicholas Bate.

Yeah, I know. It's a single-speed. But you can't deny it's a rather fetching bike.

via PEDAL Consumption

I can't wait for the run-up to Christmas to finish, and for Christmas itself to begin. This frantic running about gets worse every year.

I may take NB's advice this weekend and start bringing the quiet forward.

The different sound components of the Millennium Falcon's hyperdrive failing explained by Ben Burtt. The biplane used was probably more reliable than that hunk of junk.

This morning's topic of conversation in the car to school with the kids was very enlightening.

Where would you go if the zombie apocalypse started?

Some barmy theories were proposed, but perhaps the best one was to hole up in a bike shop.

There's coffee, energy bars, bike tools, plenty of bikes for barricading doors and their reliable as transport.

And they say kids today aren't imaginative!

I haven't been reading the Dr Dobb's site for a while but back in my days as a .NET developer, it was a regular place to visit. Still, it's a shame to see there won't be any new content after the end of the year.

No amount of analysis and explanation can mask the deep, personal sadness I feel at writing about this decision. Like many of you, I grew up reading Dr. Dobb's. For me, as I suspect it was for many of you, Dr. Dobb's Journal was the lifeline to a thorough understanding of programming. I recall that when the magazine appeared in my mailbox, all other activity for the day came to a sudden stop and the remaining hours were spent blissfully poring over article after article, soaking in the information. I learned C from Allen Holub's C Chest column, operating systems from the 18-part series on 386BSD, video programming from Michael Abrash's Black Book, and data compression from Mark Nelson. And so on — each month brought new, enabling insights and explanations of often arcane topics.

— Farewell, Dr. Dobb's by Dr Dobb's

Feedbin has been my goto RSS Reader ever since Google Reader closed. I'm glad to see that development is continuing at a good pace with new features being added regularly, including the new Updated section that includes articles that have been updated after being published.

Excellent for keeping track of changes to articles.

In the last few weeks I've been working on a Rails 3 application for a client. The test suite doesn't cover the whole application, so along with features being added for the client, I've been gradually expanding the test suite to cover the entire application.

The test suite itself uses Minitest and the test syntax. So far I've had an enjoyable experience in adding tests for each part of the application. This week though I faced an issue of duplication in my tests. The application includes a number of mailers. Each mailer has an erb and plain text template. In my first pass at testing this mailer I had some duplication going on with the different templates for each mailer.

assert_match(/Hi there #{person.first_name}/, mail.text_part.to_s)
assert_match(/Hi there #{person.first_name}/, mail.html_part.to_s)

This is just one of many lines in the tests that assert that the two mailer types include the right content. Wouldn't it be nice to wrap these two assertions into one?

Minitest allows you to define your own assertions but up until this time I made do with Minitest and Rails' own assertions. Turns out that adding your own assertions to Minitest is easily done. I included the following assertion in my test_helper file but you can include your own assertions in a seperate file if you want to and then include that in your test_helper file using require.

module Minitest::Assertions
  def assert_mail_match(expected, actual)
    ["text","html"].each do |mail_part|
      assert_match(expected, actual.send("#{mail_part}_part").to_s)
    end
  end
end

What we're doing is adding a wrapper around Mintest's assert_match method and pass in our expected value and the actual value. The method will iterate over the two mail parts in the mailer and assert that each format has the correct corresponding content.

We can now call the new assertion in our tests:

assert_mail_match(/Hi there #{person.first_name}/, mail)

Wrapping these two assertions into one makes sense. The template formats for the mailers is unlikely to change and the two different formats have the same content albeit with different formatting.

After a couple of years of using RSpec, Minitest has been a nice change to how I test the Rails applications I'm working on. Its syntax and single way of doing things means that I find it easier to write tests. Hopefully, I'll be able to share more insights into using Minitest in the future.

A little self promotion. My latest book, This Could Help, is now officially available on all platforms. It’s a collection of essays and asides, all of which could potentially help you in some way. Each one is purposely written to land hard and make an impact that matters.

— This Could Help — Now Everywhere by Patrick Rhone

Patrick's latest book will help many people. Not too late to buy as a stocking filler!

It's that time of year where you should be thinking about goals and plans for next year. Here's a little tip. Try measurable goals.

2015 is just around corner. Just over two weeks in fact. For many the setting of goals and plans for next year won't begin until that period between Christmas and New Year. Right about that time where the over-indulgence of food will probably lead to a planned diet for the length of next year but will most likely only be until the second week of January. I learned a long time ago that setting such goals and plans on the eve of the New Year rarely last beyond January.

Such goals often fall apart simply due to them being set in such a short period of time with little thought to making actual plans to achieving those goals. They also rarely succeed due to the fact that there's no clear end goal in mind. If your goals are financially related, why not think about the amount of savings you have just now. How much more would you like to have in savings by the end of next year? If your goals are health related, think in terms of improving the numbers you have now. What's your time for a five minute mile now? How many seconds do you reckon you can take off by the end of next year?

At the end of last year I set myself a few goals. One of them was the total amount of income I wanted from my freelance work. I had a figure in mind that was more than the previous year. A good 25% more in fact. I managed to hit that goal this year with a steady stream of work coming in. Next year I'm increasing that figure again by a further 25%. With the projected work I have for next year, that figure can't be gained by invoicing clients alone, it will require me to start thinking about income from products and services as well as perhaps re-negotiating my rates before the start of the new financial year in April.

A measurable goal is much more achievable when you define the figure you have now and the figure you want to achieve. It doesn't need to be a goal for the whole of next year either, it could be a attainable in nine months, maybe even six. The point is that a measurable goal is an attainable goal.

Rory McIlroy reckons a faster version of the game is required to get more kids interested in the game again.

Everything’s so instant now and everyone doesn’t have as much time as they used to,

— Golf needs speeding up - McIlroy by BBC

Having watched Ethan and the rest of his friends develop in the junior section over this year I would have to say that the pace of the game isn't the main problem. There's plenty of enthusiasm from kids to play and professionals and golf clubs are trying to provide facilities for even the youngest of aspiring golfers.

Facililties and equipment for these young kids might be more of an issue. Golf is an expensive sport (even for kids) and there's still a lack of accessible facilities that allow kids to simply go out and play when they want.