v1.1 of Genius due to arrive shortly.

Version 1.1 is on it’s way, awaiting approval from the Apple overlords (which means it won’t arrive until the new year). Here’s what you’re going to get in this exciting episode of Genius App updates:

Game Center Leaderboards 
Want to see if your mates really are sending you a massive mathematical smack down? Well now you can – just sign in with Game Center.

Undo last operation
How many times have you been playing, you’re tapping away making mathematics work wonders, only to hit the wrong operation and realise a little too late!! Well, worry no more, you can now press the undo button and all will be right with the world!

Fractional division
Again a frequent cause of abusing hurling – when you’re flying through a forest of functional finesse only to divide by the wrong number and end up with an unusable number… well worry no longer, you’ll see you can’t anymore. So there.

Other stuff 
There were a few annoying bits and bobs in there too, such as playing on an iPad rotating all sorts of things the wrong way when switching to landscape. Also you can now tap a selected operation a second time to unselect it… see who says I don’t help you score higher scores?

That’s it folks… you want more? Well you’ll just have to wait, but not for long. The tube seems to be delayed lots at the minute, so I’m sure I’ll finish off the next round of features very quickly indeed!

Oh, and one last thing – I’ve changed the colours… hopefully they’re a little less full on.

Happy holidays!

Posted in Uncategorized | Comments closed

Genius is Live!

Apple approved my game, ‘Genius’, this week.

Here it is in the AppStore

The feedback provided by everyone has been really useful, and my tube journeys are now taken up with implementing the next set of features. It will probably be in the new year, as Apple are scaling down app approvals for Christmas, but here’s some things to look forward to in the next update:

  • Game Center integration, so you can challenge people and see how rank compared to others.
  • You can skip a tough level, but this will incur a time penalty.
  • You won’t be able to choose numbers on division that don’t result in integers, saving you from the annoying ‘oops what is that number’.
  • Unselect an operation by tapping on it again.

Happy holidays!

Posted in Uncategorized | Comments closed

Please Beta Test my tube project.

Beta Test your what?

I’m asking you to help me test a little numeric puzzle game I’ve written with a WIP title of ‘Genius’. It’s incredibly simple, but you might find it quite enjoyable. If puzzle games aren’t your thing, no problem, I won’t be offended.

 What do you need?

You’ll need an iPhone, or iPod I’m afraid. If you’ve got one of those and you’re keen, drop me a line, and I’ll explain what I need you to do, it’s very simple… honest.

And then what?

Once you’ve got the game, and played it. I’m interested in any problems you’ve had with it, or any suggestions as to how to improve it.

What do I get?

I’ll buy you a beer (or if you don’t drink, I’ll bake you a brownie).

Finally, what’s a tube project?

Aha, well like many of you I commute on a train every morning and evening to work and back. Each trip is 40 minutes or so, and like many others I used to read the paper or a book, play a game, or smile at people who didn’t like eye contact. I decided to try and do something more productive, so took to sitting down and working on a project on my laptop.

Thanks!

Posted in iOS Development, testing | Comments closed

An iOS developers plea to Apple

Dear Apple,

As an iOS developer I’d really like the following things:

A command line tool to allow me to clean install my IPA onto a development enabled device which has already been provisioned.

For example: xcode-install -device=<device hex id> -deleteExisting MyWonderfulApp.ipa > results.txt

A command line tool to run an instruments automation test script against a given device (that works).

For example: instruments -device=<device hex id> MyWonderfulApp.ipa ./myTestScript.js > results.txt

Thanks.

 

Posted in iOS Development | Comments closed

iOS automated build environments part 1

Until recently, I was at the point of believing everyone in every programming language was building applications using a shell command and a server that continuously integrated checked in code. I struggled to believe that a lot of people building iOS applications do so on their desktop, using a mouse click from within Xcode to package the application. Even people who I have worked with, who tirelessly strive toward smoother building, testing and deployment cycles, admitted their dark secret of just banging it together in Xcode with no tests. Thankfully, Apple do provide some frameworks and command line tools to help you out, and if you’ve got Xcode, you’ve already got everything you need.

Create an application

First off, let’s try and at least compile our application from the command line. We’ll use a shell script to do most of this, but I’m sure you can adapt this to your chosen build system. So let’s create an application and write our build script.

  • Download and install Xcode if you don’t already have it, it’s available in the AppStore on your Lion machine.
  • Open Xcode and choose: ‘Create a new Xcode project’ from the left hand menu.
  • Choose a ‘Single View Application’. (Although it doesn’t really matter which one you choose).
  • Enter a product name of ‘AwesomeApp’, and a company identifier of ‘totallyawesome’, don’t include a class prefix, however you do want to use ARC (automatic reference counting) and ‘Include Unit Tests’. Click next to create the app. (Feel free to change my wonderful names).
  • Save it to your project folder (I have a folder called projects in my home directory).

Great, we now have something we can compile. You should be able to hit the big iTunes like Play button and launch the application in a simulator. Marvel at our application which just displays a big blank view… watch out Angry Birds here we come.

How to build it from the command line

Now we can start writing our build script.  The main command line tool we’ll use is something called ‘xcodebuild’, it has the following man page:

1 2 3 4 5 6 7 8 9 10 11
xcodebuild [-project projectname] [-target targetname ...]
[-configuration configurationname]
[-sdk [sdkfullpath | sdkname]] [buildaction ...]
[setting=value ...] [-userdefault=value ...]
xcodebuild -workspace workspacename -scheme schemename
[-configuration configurationname]
[-sdk [sdkfullpath | sdkname]] [buildaction ...]
[setting=value ...] [-userdefault=value ...]
xcodebuild -version [-sdk [sdkfullpath | sdkname]] [infoitem]
xcodebuild -showsdks
xcodebuild -list [-project projectname | -workspace workspacename]
view raw file1.txt hosted with ❤ by GitHub

This is a pretty useful tool that can provide you all sorts of information about the project from the command line. We’ll focus on the first entry, as this is what builds the targets in your project. You can obviously run this directly in a terminal, try typing the following into a terminal:

1 2
cd <project-root>
xcodebuild -target AwesomeApp -sdk iphonesimulator -configuration Debug build;
view raw file1.txt hosted with ❤ by GitHub

With any luck you should see a ‘BUILD SUCCESSFUL’ message. This has actually compiled your application using the default ‘Debug’ configuration that was set up on project creation, against the iPhoneSimulator sdk. This means the binary output will run on i386 based machines, but won’t run on an arm7 based device. The Debug configuration means the outputted binary will contain more information to allow the debugger to step through the code when it’s running. This is something we want to strip when it comes to building a production or ‘Release’ package. The good news is that by default the Xcode project is set up with another configuration called ‘Release’, this strips all the extra information required by the debugger. So try the following:

1 2
cd <project-root>
xcodebuild -target AwesomeApp -sdk iphonesimulator -configuration Release build;
view raw file1.txt hosted with ❤ by GitHub

Again you should see a ‘BUILD SUCCESSFUL’ message.

For now, let’s just put this into a build script. Right click the project definition in Xcode, that’s the one with the blue appstore icon on it, and select ‘New File’. Under the other menu, select a ‘Shell Script’, and give it the creative title of ‘build.sh’. You don’t need to add it to any targets, as this will run outside of Xcode. Then put the above code into the file so it looks like this:

1 2 3
#!/bin/sh
 
xcodebuild -target AwesomeApp -sdk iphonesimulator -configuration Release build;
view raw file1.sh hosted with ❤ by GitHub

There’s one final thing to do before we can run this as a script, and that’s add the execution flag to the script as Xcode doesn’t do this by default. So open a terminal at the project root and type the following:

1
chmod +x build.sh
view raw file1.txt hosted with ❤ by GitHub

Now we can run our simple build just by typing:

1
./build.sh
view raw file1.txt hosted with ❤ by GitHub

Breaking the build

So what happens we accidentally forget to add some code to the project, or miss a semi-colon? Let’s hope our build script will output some sort of failure message. Open the ViewController.m file and remove a semi-colon from the ‘return YES;’ at line 34. Then run the build again. You should see a ‘BUILD FAILED’ message in the terminal, but scrolling up a little, there’s some more useful information. The compiler lets you know where the error occurred and even puts a little hat at the precise point that caused the failure.

We now have the basis for a continuous integration environment, as we have a basic compile that can be run from the command line. We’ll deal with that in the next article, as there’s a whole load of fun and games to be had with that.

Posted in iOS Development | Comments closed

Agile Recruitment Agents

You are agile…

Posted in Uncategorized | Comments closed

Some GWT testing techniques.

Just a collection of links to other people’s GWT testing techniques:

Testing GWT’s async services: http://www.jmock.org/gwt.html

Mocking widgets in the view: http://www.assertinteresting.com/2009/05/unit-testing-gwt/

Simon Stewart’s example app: http://code.google.com/p/tdd-gwt-gae/

Posted in Uncategorized | Comments closed

Extending Selenium

I think Selenium is great for acceptance testing websites. But I’ve found it can be pretty slow to do certain things in Internet Explorer, in particular anything to do with xpath queries.

Something we need to test in work is that a particular CSS class is set on a particular element. Currently Selenium doesn’t provide a way to do this without using an XPath query. However, it is fairly easy to extend Selenium and implement this without the use of XPath. The basic idea is to use Selenium’s getEval method within an extended DefaultSelenium and wrap a particular call inside a standard Java method.

Here’s an example of what I’m waffling on about:

public class ExtendedSelenium extends DefaultSelenium {
  public String getCssClass(String elementId) {
    return getEval("{selenium.browerbot.findElement('" + elementId + "').className;}")
  }
}

Selenium provides the browserbot object, this has many handy methods that work cross browser. They tend to be pretty efficient too. However you’ll have to be careful that any extensions you write, are either only going to be run on a single browser, or you write cross browser code.

Have fun!

Posted in java, testing, web | Comments closed

Deleting code – what the inspector wasn’t told.

I like deleting unused code, it’s fun and satisfying. IntelliJ is brilliant at helping discover unused code too, with it’s code inspector.

Oddly, some developers go to great lengths to try and stop tools like this being able to identify if code is actually in use. One of the common techniques is to stick a class name into a database table – the reasoning for this tends to be ‘so we can change it dynamically’. This quite rightly induces a certain amount of fear in developers when it comes to deleting any code, as it might be in use.

A solution: Move the code in the database back into code.

By writing a script that runs a series of select statements on each of the columns and tables that contain the class names, then you can generate a java file that in turn has a static reference to each of the classes. This can then temporarily be included in your source tree, and the inspector can get on with it’s job. Lovely!

I’m sure this can be expanded to cover field/method names too with a little bit of generated casting.

Posted in java | Tagged | Comments closed

Technical Debt.

I was ambling through some blogs that Google Reader suggested to me, and came across an article by Joe Ocampo on ‘How healthy is your code‘. It reminded me of something I heard mentioned on a project recently. It went something along the lines of ‘You are not properly stuck into a project until you have introduced some technical debt’.

It’s no surprise that the project is now struggling to maintain the rate of delivery that it started off with. Check out ‘Listening to test smells‘, a good way of showing there may be trouble ahead.

Another interesting outcome of a discussion on the subject can be found at Exploration Through Example, Brian Marick’s blog.

Posted in Uncategorized | Tagged | Comments closed