I’ve been rather busy recently with all sorts of contracting work, but I’m glad to announce that in between it all I’ve been slowly working away on additions to both Ambientweet and Neu.

First up for public preview is Ambientweet 1.1b1.

The main thing that’s new in this release is the ability to focus Ambientweet on a search term and have it cycle through tweets that contain it.

This opens up a pretty handy new use for Ambientweet - if there’s a term trending or a topic that you particularly want to follow, you can set Ambientweet up to display just those tweets (perhaps whilst you continue to view your own stream with another client).

Feel free to give the beta a try….

So, NSConference 2012 has finished. I wanted it to go on for another week, but alas it was impossible, and that many cooked breakfasts probably wouldn’t have been advisable.

I won’t go for a full on summary of the whole thing - a few other folks have been doing a good job of that.

Here’s a quick take on my initial thoughts though. After further reflection I may have more, or may revise these ones.

The Good

• Seeing old friends
• Making new friends
• Some great inspirational talks
• Lots of valuable Nuggets Of Information (tm)
• Tom bringing me my favourite beer

The Un-Good*

• Not enough technical content for me this year
• Some (undeniably brilliant) speakers essentially doing the same talk as last year
• Quality of the blitz talks varied wildly, and I think I preferred them being elsewhere
• The conference clearly needs more QR codes

(*this may be a bad translation)

Overall though - another fantastic experience. Many thanks to Scotty and the whole team for looking after us all so well.

Daniel Pasco just blogged an article named Radar Or GTFO.

The gist of his argument is that it’s all very well moaning about Xcode 4, but unless you file Radar bugs on it, you don’t have a leg to stand on.

Since I’ve recently been moaning about Xcode 4, I have a view on this. Not that I have anything against Daniel, but from the title of this blog post, you can probably guess what it is.

Funnily enough, a few weeks ago, I was also moaning about Radar.

You can read the post if you want the full details, but my basic point about Radar is that it’s a crock of shit for anyone outside of Apple. It’s an impenetrable black hole - bugs go in, but little or nothing ever comes out. It takes a lot of time to make a well formed bug report, yet Apple won’t even let you know whether or not they know about an issue unless you go through all of that effort.

If you are lucky enough to have someone publicise a radar number that you can file a duplicate on, you can avoid some of this work, but even then it’s far harder that it ought to be to just post a “me too” report. You can’t even see the content of the bug report so you have to take someone’s word that it’s actually the issue you are complaining about (Open Radar is a little help in this, but it’s run by us, not by Apple, it’s entirely voluntary and therefore very incomplete, and using it is potentially even more work).

I have every sympathy for Michael Jurewitz (developer tools evangelist at Apple), and the Xcode team - it’s not their fault that they are stuck behind The Great Wall of Cupertino. Unless Apple give some serious love to the bug reporting process though, it is they who don’t have a leg to stand on.

Coincidentally, John Gruber made a tangental but highly relevant post on this the other day.

Apple’s resorting to moaning about a lack of bugs filed in Radar is either them being deliberately obtuse, or it exposes a fundamental misunderstanding of human psychology (something that Apple usually can’t be accused of).

People do things (or fail to do things) for a reason. If we’re not filing bugs, it’s because the bug reporting process is fundamentally broken. Fix that, and we’ll drown Apple in bug reports.

Then maybe I can have a development environment that doesn’t crash on me at least once per hour.

I’ve been using Xcode for a good long time (since before it was called Xcode).

It has many detractors, and though I understand why people get frustrated with it, on balance I’m not one of them these days. I say on balance because there are undoubtedly things about it that drive me mad. That’s has been equally true in the past though of Visual Studio, Eclipse, Metrowerks, Think C, etc.

I think a lot of the criticism of Xcode is unjust.

A lot of it comes from switchers who are actually saying “I don’t understand this because it doesn’t look like insert-my-favourite-IDE-here”. Well, no shit! Different it is, but different is not necessarily worse.

A lot of it also comes from the kind of programmers who don’t really understand build systems, don’t like the fact that making large software projects is complicated, and would really like it if someone else just made it all work. These guys are probably happy with a simple project (maybe taken from a sample and hacked about a bit), but as soon as they have to make a change to a build setting, or work with a multi-target, multi-project setup, and something goes wrong, they get snarky and blame the IDE for being crap. These guys would probably not be much happier with anything else, but for whatever reason they’re using Xcode, so they bitch about Xcode.

So, anyway, hopefully we’ve established that I quite like Xcode. Xcode 4, in particular, is a bit improvement in lots of ways over Xcode 3.

Except. Except.. ah..

WHAT THE FUCK HAPPENED TO XCODE 4.3?

On the face of it, not a lot has changed. Except for one really big thing, which is that almost every file that it uses has moved to a new location on the disc, inside the application bundle. But that shouldn’t affect us right? All we generally do is launch the application, and a few other tools, and some command line utilities, and - well, it shouldn’t affect us too badly, surely?

Well, you’d hope not, but you can see how it might flush out certain incorrect assumptions about where things are relative to each other.

Whether that’s the reason, or it’s something else, this version appears to be really, really crashtastic! It crashes when I do stuff. It crashes when I don’t do stuff (seriously, it crashes when I just leave my computer sometimes). It throws up random modal alerts with obscure error messages. It gets confused and refuses to build projects that it happily builds if you approach them from a different direction. Worst of all, it ignores previous settings about where I want my curly brackets god dammit!

It may be that I’m alone in this, and there’s something strange about my setup. I do admittedly have four different generations of Xcode installed on my machine to cope with the different requirements of various clients.

I doubt that’s it though. The word I’m hearing from all the other developers that I know suggests that my experience is pretty typical.

To me this raises some concerns about Apple’s internal Q&A for their tools department. How exactly did this thing end up going out in this state? The first beta of it was actually quite solid, but the last one and the actually release have been woefully unstable.

What concerns me more though is that Xcode is one great big monolithic lump of closed-source code. It may be modular under the hood (there’s clearly some sort of plug-in architecture), but it’s clearly not modular in a very rugged sense, since Apple only ever seem to want to distribute releases of the whole damn thing in one big lump. If that policy is based on the danger of instability if pieces are updated individually, that’s bad in what it hints about the true state of the code. It’s also bad because, frankly, that policy ain’t working.

To be fair, the decision to keep the releases monolithic may be based more on the complexity of supporting lots of versions of Xcode. If all the components were changing all the time that could get messy I grant you, but if that’s the case then the really really need to make sure that official releases are stable.

Because new releases don’t come along that often.

Betas aren’t that rare (indeed, I have one right now, which is even crashier than 4.3), but betas don’t always help. For every thing that is fixed, a couple of others are either broken or in a state of temporary flux.

I don’t have any simple solutions, but I really hope that this is a blip, since currently, working with Xcode is a profoundly unpleasant experience for me.

Actually, I do have a couple of solutions, but I doubt that Apple will go for them.

One is to open source the bastard. How I would love to be able to just dive in and fix the bugs that are biting me. If there’s one thing that really ought to make sense to open source, it’s a development environment, given the skill set of the user base!

Assuming that’s not going to happen, the next thing I’d really like to see is for Apple to split up the release cycles a little bit.

Fair enough maybe we can’t have a crazy free for all where I can download the latest beta of IDEGit.ideplugin and install it individually, but why on earth do I have to wait for iOS 5.1 to be released before someone will fix some bugs in Xcode’s text editor? It’s ridiculous. No reason at all, except for the monolithic release model.

It would be great if at least the release cycle of the editing environment, the compiler tool chain, the sdks and the ancillary tools were independent, so that the IDE could be updated far more frequently.

There are signs that they’re attempting to go that way, but I’d really like to see them pursue it more aggressively. In the meantime, I live in hope of a new, more stable, beta.

Following on from my post on parameterised unit tests, another little utility hidden away in ECUnitTests is some support for running the run loop in unit tests.

Why would you want to do that, I hear you ask?

The answer is: because you want to do something asynchronous in a unit test, which relies on the run loop. An example would be using NSURLConnection to download something.

The Problem

Each unit test typically runs as a single, discreet test method.

If you need to use something like NSURLConnection that relies on the run loop to post notifications or call delegate methods, then you have a problem doing so in a unit test method. The asynchronous stuff won’t run until after your test method has exited (if at all), at which point it’s too late to test the results.

The Solution

The solution is simply to set things up, call your asynchronous method, then run the run loop until something flags that it’s time to stop, and finally test your results.

This is actually very simple. All you need is to set up some sort of boolean variable which you can test to see if it’s time to exit the loop.

You then set it to false, and enter a loop like this:

exitRunLoop = NO;
while (!exitRunLoop)
{
    [[NSRunLoop currentRunLoop] runUntilDate:[NSDate dateWithTimeIntervalSinceNow:0.1]];
}

In order that you don’t get stuck in this loop forever, you need a way for one of your delegate methods or completion blocks to set the value of exitRunLoop to YES.

The easiest way to do this is to make exitRunLoop a property on the test class, and make sure that the test class is also the delegate (or accessible from the delegate or completion block).

To simplify things, the ECTestCase handles this for you, and provides two methods that you can call.

- (void)runUntilTimeToExit;
- (void)timeToExitRunLoop;

If you inherit from ECTestCase in your test class, you can simply call the first one of these when your test needs to wait for something to happen, and call the second one when the thing has happened and you want to stop waiting.

You can see an example of this in ECUnitTests.