Anyone elses judgement is used primarily to validate your own judgement. This is frequently for one of two reasons:

• To confirm your suspicion that you have done good work.
• To confirm your suspicion that you have not done good work.

The first seeks a confirmation bias and tends to discount or rationalise dissenting opinions and value judgements.

The second one is more interesting. In this case, you have a general unease that something is not as ‘good’ as you would desire and you are seeking to explore this unease and try to determine why you have this general feeling of unease.

The first is ego-stroking and adds no real value, simply gaining approval for a value judgement already made. The second similarly is simply gaining confirmation of a value judgement that has already been made. In both cases, the worthy judgement is your own, which determines if you are satisfied or dissatisfied with the work.

These rules are not things to strive for. Your overall goal of working code that achieves a function is what you strive for. These rules are merely possible ways to achieve this goal. They are easily mistaken for the goal itself though, because the attributes that we actually want in our code make it look like these rules are in play. The reality tends to be much more post-hoc, with rules and guidelines being extracted as patterns from code that has already been identified as exhibiting desirable attributes.

Rack is a fairly well known piece of the Ruby ecosystem nowadays, and is responsible for definining an interface between an HTTP request and your Ruby web app. It’s a remarkably simple interface, which can be demonstrated in a single line:

This shows the important parts of a Rackup file – you run a rack application. A rack application is a ruby object that responds to a single method ‘call’. This method takes a single argument of the environment for the request (including all the information like the header, the url, query params, etc). The call method must return an array with 3 elements – the status code, a hash of headers, and an array of body strings.

The full project (which includes a Gemfile and Procfile for heroku) is:

This time though, I didn’t worry about doing it from scratch. Instead, kudos goes to Octopress for their jekyll setup :)

Code provided:

Setting apart the issue of whether this is a good idea or not, the core of the problem is as follows:

• ‘includes(:account)’ gives you back an instance of ActiveRelation, a query-builder style object. It doesn’t execute queries immediately, instead it gives you lazy query evaluation
• The each iteration in the method doesn’t do anything with the method result, so the query will never be executed. On top of this, the result will just be discarded, as .each returns the collection it is called on.
• Executing a line in the console automatically calls ‘inspect’ on the result. This happens to be one of the methods that will execute the lazy query object, so you see the result of the query (and the query appears in your logs)

Keeping this in mind, the result to get the desired behaviour of a built query back can look a bit like:

So today I put together this thought with my common annoyance of not being able to come up with blog topics and thought ‘hey, why don’t I blog about the questions from IRC?’

We’ll see how it goes over the next few weeks, whether I actually manage to keep up the pace or not :)

So why does this sharp gap appear in ‘Unix Skills’? Why does there appear to be a jump from Level 2 straight to Level 5? I think it may be tied into the question ‘What is Unix Skill?’, which is (when phrased like that) a very amorphous, ill-defined question. Is Unix skill defined by kernel hacking? By bash skills? By zsh skills? By skilled sed and awk use? Where is the skill that is ‘Unix’?

My thought is that Unix isn’t a single skill, definable by a single level in the Dreyfus model. Instead, Unix is an entire ecosystem of skills in various different, but related, areas. So how do we appear to have level 2 people, level 5 people and no one in-between? I suspect that the ‘level 5’ people are really level 4 or level 5 in a large number of skills in the Unix ecosystem. This expertise creates a synthesis where they quickly become experts in other skills within the ecosystem, thereby becoming ‘Unix Experts’. The level 3 people exist, but they are level 3 in bash, or level 3 in Apache or nginx configuration, or level 3 in a large spectrum of unix skills, but they haven’t gained expertise in enough skills to spark the synthesis that draws all the skills together into a Unix expert.

So how can someone become a unix expert? I don’t know as I haven’t managed it yet. My suspicion is that as expertise is gained in various unix skills, they start to interact, combining and fusing together, with the common ‘essence’ of each skill that makes it a unix skill being distilled out. If I ever manage to reach this pinnacle, maybe I’ll have more insight. My worry is that if I do, I won’t be able to explain it.

So why should you write automated tests for your code? And why should you write them before you write the code that will pass the test? Obviously, if you aren’t convinced of the first answer then you won’t be happy with answers to the second one so I’ll address that one first.

Why write automated tests?

Well, the first thing to note is that you are probably already testing to some extent. I’m talking about the times when you compile your code and run it to make sure the brilliant new factorial function you just wrote does calculate a factorial and not just throw out random numbers. So what do you do? You probably bring it up in some way that you can call the method and throw some values at it and check that the values are correct, probably by manually working them out. And then, you throw all that work away. When you rewrite the function (because you realised that there’s a way to do it that’s 20 times faster), you either have to repeat all that work, or you decide that it must be right after all, it worked before didn’t it? Of course, you could just not test at all, but then you don’t actually know your code works. As you build more and more on top of your factorial function, there will always be a bit of doubt that it isn’t working quite right. And then you get a phone call at 2a.m. telling you to get in and fix a bug that just caused the entire banking system of the world to crash and burn and civilization as we know it has ended (or not… I’ve yet to come across a factorial function quite that important. But it might happen)

To contrast, the case with an automated test is that you write the test after the first run through and verify it. The test gives you a ‘yes/no’ answer for if the function calculates factorials. You’ve likely calculated a few simple cases manually still, but the important difference is that they are now recorded in an executable fashion. When you rewrite the function this time, you don’t need to repeat the testing or not bother verifying your changes, you just re-run the same test and it should still tell you that the code is calculating factorials (but hopefully the test runs quicker :) )

It should be obvious here that automated tests aren’t actually requiring you to do more work. They just give you a way to record what you should be doing anyway, namely verifying your assumptions that the code you just wrote does what you say it should. Every passing test is another verification that you can write code, that the code you write does what you tell it to and that when you change or add code, it still does what you expected.

Now, you could be writing your tests in test scripts that someone checks periodically, or writing expected outcomes in comments, or any other of a few hundred ways of recording your initial results for when you need to re-test later. However, if the record isn’t executable (as an automated test is) then you’ll still need to re-run the test manually, which will take time. And you’ll need to recheck the results manually, which will take even more time and is error prone (especially when comparing string outputs. Two letters mixed up are easily missed by a mere human, but a computer will always pick up on the error).

So you’ve recorded your assumptions and you can execute them whenever you want to give yourself that little pat on the back that says ‘Yes, I can do my job, see this green bar is telling me so’ (if the green bar does talk to you, turn off your speakers. If that doesn’t help, see a psychiatrist). There is another important thing happening here though – you’re double-checking your code. After all, you have written the same thing in two different ways. Far from being a waste, this is a very important thing to do. Most people have probably heard the old carpenter’s mantra ‘Measure twice, cut once’. Well, you’ve just measured twice. If either measurement is out, the test will fail and you’ll work out whether it’s because the test is wrong or the code is wrong. If you had just code, you’d have nothing to compare it to and when (not if) a problem occurs you can’t tell because you have no second measurement to act as a reference point. Obviously, tests without code are pointless so having just them isn’t much good (unless you know the tests are correct anyway… and then you have an interesting challenge in rebuilding the code they were testing)

So, now I’ve convinced you that writing automated tests is good (or you’re just reading on because you want to see if my writing gets any worse), I’ll go onto the case for testing first

Why test first?

So you’re happily writing your code, and then writing some tests to make sure it works as expected, and someone comes up to you and says “You’re doing it wrong! You should write the test before the code it’s testing”. To most people, this is counter-intuitive and sounds crazy (I know my wife thinks this) but it does bring a lot of benefits, which I’ll try and lay out here as the reasons you should be doing Test-First Development.

Firstly, test-first makes you stop and think about the code you’re going to write. You have an explicit step where you have to put down the keyboard, step back and say ‘OK, what is this code going to do that I can test?’. Now, hopefully you actually do this most of the time but if you’re like me then you will find yourself, on occasion, jumping into code and just hacking it out without any real thought going into what you’re writing or what direction you’re going. Having an explicit check before writing new code just reels you in and reminds you that, hey, a bit of thought before churning out code like a madman is a Good Thing™

Next, by writing the test first (and running it) then you know that the test fails. More importantly, when you have a test that fails, write some code, re-run the test and it passes, then you know that the code you wrote is what made it pass. If you write the test after the code then you are lacking this important verification and you simply don’t know if the test you wrote would pass without the code. And if you find the test would have passed, then what is that code you just wrote actually doing? Is it actually important? Can you remove it safely, or is some other test that you wrote even further down the line actually testing this? If this is sounding confusing, it’s nothing compared to the confusion of having tests that aren’t testing what they say (and you think) they should be testing.

Thirdly (and finally for me here), it helps to stop you writing code that you can’t test. This is coupled partly with the first point but I feel it stands alone. A lot of people who start with just automated testing find themselves having just written some code and they just can’t (easily) write test for it. There are many reasons, such as it requires a lot of expensive setup that just isn’t feasible or they can’t get the test input into it without hacking the code to pieces. Sometimes you just end up with something that doesn’t really return an output, it just manipulates some other object (and that leads to mocks, which is a subject for other times and places). However, by reversing the process and always thinking about how to test code before you write it, you invariably end up with code that you can actually test. And as long as you can test it, you can change it more easily, because you know when you break it and code that is more easily changeable is more flexible and less coupled to the rest of the system. Low coupling and flexibility are two things that are almost always present in designs that are classed as ‘good’ and test-first development is one way to achieve them with very little actual overhead.

TL;DR Summary

For those that don’t like reading too much (I can be quite verbose) the main points are:

1. Automated testing isn’t much extra work. Mostly it moves implicit testing into an explicit step
2. Automated testing removes work down the line from when tests were recorded and had to be manually followed, or aren’t recorded at all
3. Test first gives you explicit times to think about code
4. Test first provides you with a way to verify the test itself works
5. Test first is a way to achieve flexible designs with low coupling

So why don’t you test?

One key part of integrating such a sign-on mechanism to me is to make sure it is testable and then to test it, which in turn led me to find out how to test with third party services in omniauth. This is where Devise comes in handy, as it provides test modes and stubs for the omniauth library that allows you to test that your integration is correct while stubbing out the third party calls that would otherwise prove problematic (after all, you don’t want to actually authenticate against facebook with your tests).

The first part is to get Cucumber set up for these tests. Drawing on the Devise omniauth documentation, I came up with the following:

Basically, you start by putting OmniAuth into test mode, and then short-circuit and stub the authorizers before each scenario and reset them afterwards (to return them to a clean slate).

You can then login by following the link to the facebook/twitter/open-id login on your page in your Scenario. Once you’ve done the authentication callbacks for your chosen service(s) then the step will pass and you can continue as an authenticated user. Magic! Next, I’ll drill down into the implementation of the callback handlers and work out how to test them through RSpec.

For those interested in the boring technical details, this new site has been built using the static-site generator Jekyll, and I’ve styled it with the Blueprint CSS grid framework. The colour scheme is one I found that I liked in Kuler, the menu system is one I picked up from a free CSS menu site and I put it all together by hand.

The code and content is also hosted on github here

This is all in aid of trying to produce a blog that I’ll actually update. My previous attempts are Shared Illusions and Reflective Coder and my hypothesis is that now I’ve moved the blog onto my own domain I’ll be more driven to write content for it.

We’ll see how that goes :)