I have decided to have a go at writing an app for the iPhone with my new-found free time. It is a platform I haven’t written for before so it’s a nice opportunity to delve into some technologies that I am not very familiar with. First on the list is choosing which language/environment to write my application in. Given the app I have in mind will need to talk to a physical sensor plugged in to the dock connector, I am going to need access to native APIs. So, after briefly flirting with Appcelerator’s Titanium and discounting MonoTouch as I don’t know C#/.NET either, I have settled upon getting to grips with Objective-C and XCode.

I have not written anything in C/C++ for over ten years, which means I have essentially forgotten what little I knew. That’s not a problem, so the best place to start I thought would be Apple’s developer documentation. Let’s start with the good news. These documents appear to be put together really quite well. They’re structured for people new to both iOS and Objective-C development, as well as having links off to XCode docs in relevant places. This is a good thing. Their hand-holding tutorials have got me up to speed with at least getting a bare-bones single-screen application up and working and the language tutorial has given me a sense of the key differences between Objective-C and Java (ugh, memory management).

What is astonishing, though, is the way that unit testing seems to be an afterthought across the board. Of the three Objective-C books I flicked through in Foyles the other day, not one of them even mentioned unit testing. That is including a book specifically targeting Java programmers looking to convert their existing knowledge. Apple’s own iOS Development Guide at least covers unit testing in chapter 7 of 10 and there is a small XCode Unit Testing Guide in Apple’s online documentation. These are OK as far as they go, and they have at least got me as far as getting my first tests up and running, but none of this suggests that unit testing is anything like as ingrained in the development process as it is with my Java experience. There certainly doesn’t appear to be any expectation that you’ll be doing anything as silly as writing your tests first.

XCode itself underlines this. Yes, unit testing is possible, but it just doesn’t feel as ingrained or as natural as with either Eclipse or IDEA. Take this as an example. Here is the first failing test, exactly as prescribed in chapter seven of the iOS Development Guide.

Wait, two errors? But I’ve only written one test! That’s because XCode is reporting the return status of the shell command as a failure, too. Have a look at a fragment of the expanded output from the first error.

Even a passing test suite is a little disappointing - you need to drill down into parsed console output to see what went on.

Is it just me, or is that a little dumb? It is what you would put up with in a third-party plugin that was thrown together quickly, or for a little-known tool, but for something as fundamental as unit tests? Really?

After four and a half years working for BioMed Central, I have decided it’s time to move on and try something new.

Quite what form of new that will be, I’m not entirely sure. One of the reasons for leaving is that the job took up so much head room that there really wasn’t any time left to think about other things. My trombone playing has suffered horribly over the past couple of years so this is a golden opportunity to put that right again. Also, it’s a good time to get in to some of the technologies and ideas that I didn’t have the chance to explore whilst working full time - either due to restrictions during the day or lack of energy to pursue outside work hours.

I’m certainly not going to retire from being a techie or turn this into some kind of musical retreat - concentrating only on one side I think would drive me nuts.

The idea of working for a consultancy does seem very appealing - primarily the breadth of experience gained by going in to many different organisations and working with many different people. Contracting also appeals for mostly the same reasons - there’s even the possibility of being able to take significant blocks of time out between contracts to help the life/work balance thing. For all that, though, the idea of starting up something of my own is most tempting.

So how about this for the perfect Christmas gift - why not buy the one you love some extraordinarily expensive IT consultancy? Nothing says you care more than getting someone in to tell them how to run their programming team… surely?

More seriously, come the new year I will be open to offers of work, both musically and technically. Drop me a line either through this site or to enquiries [at] odum.co.uk.

I’ve decided to deliberately put some time aside to get back to coding and explore some of the technologies that the day job doesn’t allow time for. It is an opportunity to get more deep in to tools that I have had an interest in for a while, and so I thought I would put a hobby project together using the following:

Scala

Given the uncertainty around the Java language, even before Oracle took it over, I keep coming back to the question of what is likely to replace Java. Scala, to me at least, looks to be a genuine contender.

Gradle

For all that Maven is a pain in the proverbial, I still prefer it to writing reams and reams of Ant configuration that gets copied and pasted across multiple projects. Perhaps Gradle is the answer? Let’s find out.

Getting Started

So, the first thing to do is get gradle down. The installation instructions on Gradle’s site are pretty clear so there is no need to repeat them here. You will need the Scala plugin though. The bad news is that this plugin does not support ScalaTest out of the box, so let’s have a look at what’s needed.

First off, here’s the build.gradle setup as suggested by Scala’s Gradle plugin page:

1
2
3
4
5
6
7
8
9
10
11
12

repositories {
    mavenCentral()
}

dependencies {
    // Libraries needed to run the scala tools
    scalaTools 'org.scala-lang:scala-compiler:2.7.7'
    scalaTools 'org.scala-lang:scala-library:2.7.7'

    // Libraries needed for scala api
    compile 'org.scala-lang:scala-library:2.7.7'
}

So far, so good. What we do need, though, is to add ScalaTest to our dependencies:

1
2
3
4
5
6
7
8
9
10
11
12
13

repositories {
    mavenCentral()
}

dependencies {
    // Libraries needed to run the scala tools
    scalaTools 'org.scala-lang:scala-compiler:2.7.7'
    scalaTools 'org.scala-lang:scala-library:2.7.7'

    // Libraries needed for scala api
    compile 'org.scala-lang:scala-library:2.7.7'
    testCompile 'org.scalatest:scalatest:1.1'
}

After some mucking about it turns out that this isn’t enough, either, as Gradle’s Scala plugin doesn’t support ScalaTest. We need to get in amongst the test phase and make use of ScalaTest’s Ant support in order to get Gradle’s test phase to acknowledge the existence of ScalaTest classes. So, we end up with this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

repositories {
    mavenRepo urls: 'http://scala-tools.org/repo-releases'
    mavenCentral()
}

dependencies {
    // Libraries needed to run the scala tools
    scalaTools 'org.scala-lang:scala-compiler:2.7.7'
    scalaTools 'org.scala-lang:scala-library:2.7.7'

    // Libraries needed for scala api
    compile 'org.scala-lang:scala-library:2.7.7'
    testCompile 'org.scalatest:scalatest:1.1'
}

task test(overwrite: true, dependsOn: testClasses) << {
    ant.taskdef(name: 'scalatest',
        classname: 'org.scalatest.tools.ScalaTestAntTask',
        classpath: sourceSets.test.runtimeClasspath.asPath
    )
    ant.scalatest(runpath: sourceSets.test.classesDir,
        haltonfailure: 'true',
        fork: 'false') {reporter(type: 'stdout')}
}

Thanks to Gradle’s user mailing list for leading me here. There is also an enhancement logged against Gradle to include this support out of the box.

Given my previous post, what were the chances I’d sign up for Facebook? I’ve given up and joined everyone else to see what the fuss is about.

With the continuing march of social media there’s a growing assumption that whatever you’re up to, you need to broadcast it to the world at large. It’s certainly true that some of the resulting insights into people’s lives are truly fascinating (I was subscribed to 50 rss feeds at the last count, checking for updates daily), and the emergence of blogs and news aggregators mean that I’m able to keep abreast of pretty much any given subject more effectively than ever before. What has been happening for a good while though is that companies are noticing this and encouraging their staff to broadcast on their behalf. Now don’t get me wrong, there’s nothing inherently bad in this and, indeed, a large number of the blogs I’m subscribed to are individuals writing about the cool stuff they’re doing at work. The difficulty comes in keeping work and personal lives distinct. This tension has been around forever (a colleague once got in to a little hot water at work over a letter published in The Times), but the ease by which search engines are able to pull published content of all types together makes the risk of associating personal views with that of the company you work for much greater.

I have been very careful with this blog to avoid mentioning my employer or writing about topics that could be seen as sensitive but I have not gone out of my way to anonymise it either. It’s under my own name and, for the sake of a couple of minutes armed with your search engine of choice, you could work out who I work for with minimal effort. Whilst at the moment it’s OK to write things like “crap day today, got nothing done” (and who doesn’t have the odd day like that?), once I’m also a public voice for my employer this will reflect badly not only on the company but also on me as an employee.

An amusing consequence of these professional demands encroaching on our social media is that it could make us more sociable again. It will no longer be OK to post online daily thoughts like “grr, my boss is being unreasonable” or “bored - is it Friday yet?” so instead we will have to meet up with friends and share our lives in person. Who fancies a pint?