Pixelmator for iPad

I love using Pixelmator on my MBP, but it’s great to see it’s now available on the iPad too.

via Tools and Toys

Fixie Friday - Legor Cicli 29er

Obviously this isn’t a fixed wheel bike, but with just a single gear and no suspension in sight, this is about as close as you can get to off-road fixie.

via Cycle EXIF

New Todoist for Macs

A new look Todoist for all you Mac people. Love this service.

NB is Timeless

No fads, gimmicks, or shortcuts. Just practical advice and hardwork.

Be More You ...

with a journal.

Incubating Ideas

Techniques like brainstorming try to sell a way of generating ideas in a short space of time, but is there a better way?

Out of the blue you have an idea for something. A product, a book, a service, something. What do you do with it? The obvious answer here is to write it down. Anywhere. Whatever comes to hand, get that idea down. Give it an hour or two and you might simply forget it even existed.

Great. Now what?

The next step for many is to re-visit this idea at some point in the future and decide whether to act on it or not. The down side to this is that while the idea might have sounded great on its own, it is only one idea. One single good thought.

If the idea is so good then you might be thinking that it would be a challenge to improve upon it. What’s better than a single idea though? How about two, three or even seven ideas that support this one single idea?

The problem is that while we might want to set aside a 30 minute session to brain storm more ideas to support this new idea of ours, the new ideas we want might not simply be there. You can’t force yourself to come up with new ideas. You might be able to expand on an idea but limiting yourself to a time period will only leave you with a couple of new ideas.

If you’re the patient type then how about trying a different approach?

Let your ideas incubate.

I’ve wrote before about incubating mind maps in the past. Rather than starting and finishing a mind map in a single session, I would re-visit my mind map on a weekly basis to give myself time to allow the central topic of the mind map to sink in. The benefits to this is that you allow yourself time to think about the central topic of the mindmap thereby allowing associations to that central topic to develop over time.

The same can be said for new ideas.

By allowing an idea to incubate over time, it gives us a chance to think about the idea. Thoughts and ideas often come at the most inconvienent of times. When you’re walking the kids to school, when you’re out on a bike ride, when you’re anywhere other than on your computer to execute the idea.

This is a good thing though. Being away from your desk or your workplace means that you don’t act on a sudden impulse to test the idea. Just make a note of it and then carry on with your day.

At the end of the day, make a more permanent note of your idea so that it can be easily found later along with any other ideas that you have had that support this idea.

Give it a couple of months and you should start to see that single idea develop into something more. And this is the benefit to incubating your ideas. An incubation period of two months can yield more positive results than a single brainstorming session could. It’s not for everyone though, but I’m more of a believer that slow and steady wins the race.

Fixie Friday - Look AL264

via PEDAL Consumption

Notebook Organisation

For the paper purists out there, a great tip for organising your notebook.

via Unclutterer

Reading Redmine: Multiple Assertions Per Test

In an effort to brush up my development skills I’ve been reading the Redmine source code this week. I’ve been curious to find out about examples of Rails applications that use Minitest.

Ever since I suggested a move away from RSpec for projects with my clients, I’ve been curious about real world examples of using Test::Unit/Minitest to test a Rails application. It was clear from a search of Rails applications on Github that RSpec was the preferred choice for many applications. However, after reading an email newsletter from developer Eric Davis, the RedMine project sprung to mind so I decided to check it out. Sure enough, it was the sort of application I was looking for. A mature code base using Minitest as the test framework. A few interesting points stood out which I’ll cover over the next few weeks, but for today I’ll talk about Redmine’s multiple assertions per test.

I was always led to believe that tests ahould only contain one assertion per test. It was ingrained into me from reading countless books on TDD and hundreds of blog posts on the topic. The thing is I never questioned why this was so. It was clear from seeing the RSpec syntax why it was a benefit.

before do
  get :index
end

it "must respond with a success code" do
  assert_response :success
end

it "must render the index view" do
  assert_template :index
end

it "must assign the users journal" do
  assert_not_nil assigns(:journal)
end

If your test (or ‘spec’ in this case) has one assertion and it fails then you know exactly what went wrong. Multiple assertions in a single test have always been frowned upon.

When I started using MiniTest as the test framework for a couple of Rails applications of my own, I started to write multiple asserts per test.

def test_index
  get :index

  assert_response :success
  assert_template 'index'
  assert_not_nil assigns(:journal)
end

It was discomforting to do but only from the view point that I had believed for so long that multiple assertions per test was wrong. However when I read the Redmine source code I was pleased to see that not only was the application not using the RSpec, it was also using multiple assertions in a single test. After an hour of reading through other tests in the code base I could see why it was done. The layout of the tests in Redmine are flat. Often there’s just a single setup and teardown method and a list of tests. It makes it much easier to read.

RSpec has a number of advantages in that tests can be nested in different contexts and within each context you can define a before block to setup anything needed for the tests that follow. This can result in heavily indented code and with the practice of one assertion per test it can lead to a lot of tests relying on a number of different setup methods higher up in the test file. This can be difficult to read if a test file has a number of contexts within it.

It’s re-assuring to see that while many developers might point out the benefits or reasons why we do one assertion per test, it’s not a rule that is set in stone. You can include more than one assertion in a test, as long as it’s a reasonable number of assertions.

Is it worth writing seperate tests for each of these or is it better to simply bundle them into a single test?

I’ll leave that for you to decide. There’s no right or wrong answer in my eyes. If I was still using RSpec I probably would still write one assertion per test out of habit, but having a flat layout using Minitest does make it easier to read and having multiple assertions isn’t going to make it any harder for me to test my code and debug any problems.

The Real Life Thor

An amazing account of a USMC pilot who ejected from his F-8 Crusader over a thunderstorm.

As the parachute opened, he felt the familiar tug upwards. Except instead of a slow descent, he experienced a rapid ascent. The powerful updraft filled his parachute like a sail and rocketed him vertically thousands of feet at a velocity of nearly 100 mph. During his ascent, he could see hail stones forming around him. The lightning was described by him as “blue blades several feet thick” and incredibly close. The thunder was so loud, he could feel it resonating in his chest cavity and remembered this more so than how loud it was.

via Kottke.org