Tomorrow I begin work at Trifork! There I’ll be doing iOS development, so before I begin I thought I’d like to share a bit about how I do my development now.

First of all, I use GitHub and Beanstalk for source control, depending on what client the work is for (for my own projects, I use GitHub). Mercurial is nice, but git and svn just work with XCode, so I stick to that.

Since I have source control, I can have continuous delivery. For that I use Jenkins. Jenkins is not good enough. It’s not great. It’s not beautiful. It’s not intelligent, easy, friendly, intuitive, or all those other nice words. But it works! I use the Clang Scan-Build, Github OAuth, Github, Pre SCM BuildStep, Redmine, SICCI, SSH Slaves and Xcode integration plugins, even though I’d get most things done by just adding a shell script. That gives me a build per commit, which is nice and reliable and brings the pain forward. Jay pain!

Of course, having this infrastructure in place begs for tests. Now I think tests for iPhone applications suck. Bigtime! The reason is that I hate deployment cycles. It takes time, and that time I’d rather use writing code, thinking about the application, solving real problems for my customer, preferably before he knows about them. If not that, I’d rather drink coffee, do chores in my home, or clean my pipes, rather than waiting for build cycles. It’s just an enormous waste of time. And tests for iOS drain time, as there’s no such thing as a unit test for iOS. Everything is an integration test or a user acceptability test. You always fire up the entire application before running any test.

So now I have that rant done, it’s great that I can leave my tests to Jenkins. It will perform them, and the output will get converted to what looks like a JUnit test so that it can get picked up by Jenkins’ tooling and be presented nicely. Jay!

Then we get to deployment. My clients communicate with me. A lot! This should be different like so, I changed my mind about this, I’ve found a bug if you do like this and that. It’s great! I love my users for this! It creates such a momentum! So how awful wouldn’t it be if I said “I’ll collect everything and give you a beta in three weeks”? Continuous delivery isn’t just delivery to me, it is to the users as well. For this I use HockeyApp. They’re a great bunch and really responsive, and while they just don’t support iOS 5 well enough yet, there is so much good there. My app gets auto-deployed up there and my client sees the new release, hits install and boom! Now he’s running the latest build! Crash reports get sorted by build numbers, and the guys at HockeyApp have told me they’re working at making the crash reports even more awesome! Jay!

So how do I follow up on these things? I have to admit, I’m a cheapskate, so I use Redmine. I would use Basecamp, and I hope to be using it, it’s so awesome, but so far it’s not been worth the extra cost. The day it is, I’ll run and buy it quickly. My problem with Basecamp and Redmine? I just haven’t seen how I’d integrate it with my scrum sprints. Yet. I’m sure they both can, and I hope to learn from people that are wiser than me in this regard.

Finally, after a deployment to the appstore, I use Flurry to keep track of where my users are at, both in version of the app (why don’t they upgrade! This new version is awesome! I need to tell them more about it!) and the OS (really? They’re still on iOS 4?? iOS 5 has been out a month now! Oh well, not everyone is like me). Also, I’ve rolled my own crash reporting that, should I have failed horribly, the users can get in touch with me or the client, with a detailed log of what went wrong.

So, that’s my work setup this far, and I’m quite happy with it. It still needs better scrum integration. It’s still too many pieces that don’t talk sensibly together. But it’s getting better knit together, and I’m looking forward to seeing how Trifork does it, how I can improve based on what they have to teach, and how I can improve the way they’re doing it. It’s going to be great! Those guys are brilliant, and I love working with brilliant people.

Finally, if you’re in the Esbjerg area, working with iOS, get in touch with me. If you’d love to start working with iOS, get in touch with me! There’s an NSCoder Night coming up soon, biweekly I hope.

I’m such a sucker: now I’ve bought the Steve Jobs biography for Kindle, to be delivered tomorrow. I hope the book is great. I borrowed my last book of the kind to someone, but I don’t know who.

It’s great seeing that Play 2.0 is on its way. Play is my favorite Scala playground, but it’s always felt like a second class citizen there. With 2.0, it’s a first class Citizen, and they’ve even thrown Akka into the mix. So, as with anything I’m especially interested in, I’ve signed up to submit two bugreports.

Ok, everyone, let’s all calm down. There’s been so many blog posts and podcast debates all over the net about what’s wrong with Dart. The only problem with Dart, the way I see it, is that Google is too good at marketing: too much hype before we got to see the product.

The way I see Dart, it’s another language for doing client-side web application programming. Luckily, it’s not another Flash or Silverlight with its plethora of languages. It would like to be a part of the browser, but for now it contends itself to being a language that compiles down to JavaScript. That puts it together with CoffeeScript and Objective-J, to name but a few. See a long list here. As you can see from the list, this is nothing new.

The only problem with Dart is that everyone had their hopes up for the perfect language that would contain all their pet features. And of course, the set of preferred combinations is probably as big as the number of developers in the world.

What I find to be one of the strong points of Dart is that it uses the actor model as its concurrency model. I remember it well from my days at uni, thinking it was a model leading to waaay to much overhead. Surely, the Smalltalk guys must be mad! But as time has given us more power, I’ve come to believe that this is a great model, which has lead me to Scala and Akka. Although GCD is very powerful, I find myself looking into using actors in my language of choice, Objective-C, all the time.

So where does Dart go from here? Well, that depends on what kind of backing it has from Google. Google hasn’t been very clear on how well the Dart support is grounded in the organization. But if it gains a good community of libraries and evolves a good community, it could become the preferred way of writing Android apps, letting developers re-use code for their web-app and mobile app. If not, it could become shelved like Go.

Personally, on this front I’ll brush up my ancient JavaScript skills and look more at SproutCore the next couple of weeks, probably along with CoffeeScript. Then in a month or two, if there is any momentum going for Dart, I’ll probably write something where I can exploit Darts actor model and see if we become good friends. 2011 will be interesting still.

I’m working with Xcode & Jenkins, and as part of that I’ve filed https://issues.jenkins-ci.org/browse/JENKINS-11370 for pre-scm-buildstep

The clang-scanbuild-plugin fails on install, so for that I’ve added https://issues.jenkins-ci.org/browse/JENKINS-11372