iPhone 3.0 Beta 4 Bluetooth tethering results: Less than 1/3 the speed of USB

April 29th, 2009 • 1 comment Apple, Internet, iPhone

So, it’s rather slower – 96kbps.

To test it, i tried the ThinkBroadband speed tester, (that i successfully used to test USB tethering), but it failed to complete the test.

I then tried the Broadband speed tester site and got the above results, as well as a 74kbps upload speed.

When (if!) i find time, i’ll go digging and find out if there’s an obvious reason for this – it’s clearly shouldn’t be bottlenecked by the performance of BlueTooth, as it should run up to 3 Mbit/s (http://en.wikipedia.org/wiki/Bluetooth)

iPhone 3.0 Beta 4 + iTunes 8.2 Pre-release = USB Tethering Active Again :)

April 29th, 2009 • Apple, Internet, iPhone

Yep, USB tethering died in Betas 2 and 3, but with iTunes 8.2 Pre-release and Beta 4, all is working again and it feels wonderfully fast. Well, it’s only running at 336.58 Kbps, but it feels great! As a note, i think the fix was actually iTunes rather than iPhone Beta 4.

Lovely

Now to test the Bluetooth speeds

Important iPhone Push Notification consideration

April 16th, 2009 • Apple, Business, Internet, Objective C, iPhone, programming, software development
Tags: linkedin

A point worth noting by all iPhone developers considering the exciting opportunities of cloud-side iPhone app notifications – how much will it cost you to provide this service?

An important point to consider.

Presenting BDD Story-driven delivery to project and account managers

April 15th, 2009 • agile, bdd, dsl, programming
Tags: linkedin

Today, i had the true pleasure of presenting my view of how BDD stories offer real business value to project delivery, quality and to the lives of everyone on a software delivery project.

Part 1: Collectively clarify what happens on projects now (on projects that do not use stories)

It was a highly interactive session and i first asked attendees to collectively draw on a whiteboard the project process as they saw it, with all of the project’s actors, products and interactions.

What was drawn resembled a kind of mashup of a UML activity diagram with swim lanes & a gantt chart. It showed what the individual actors in the process did and when, and who fed into who in the process.

Part 2: Clarify what documents are written and the associated risks and costs

When the whiteboard was complete, I asked the attendees to consider a number of things:

1. At what points during the process are documents produced and by who?
2. Of those documents produced, which are directly focused on the business and user requirements?
3. Of the many producers of those documents, which of these producers had their focus on the business and user requirements?
4. Of the many documents produced, which were open to interpretation and translation?
5. What are the perceived risks of having so many documents and periods of documentation translation?

When this work was complete, a few points became clear to the group:

1. The project team, as defined on the whiteboard, was greatly separated into areas of expertise and each was concerned about their area of expertise
2. Interactions between actors were mostly through written documents
3. Few actors following this project process retained a direct focus on the business and end user requirements
4. A lot of documentation was being written and much of it was being duplicated, at times to protect actors within the process
5. Vast amounts of document interpretation and translation was going on to produce each document

Part 3: Consider stories

After this part of the session was complete, i gave some examples of the wonderfully simple story DSL and then suggested that many of these documents could be replaced by stories and scenarios:

1. I explained that stories can be used to clarify both high-level requirements and detailed solution definitions. I described how stories can be expanded through the use of scenarios.
2. I described how everyone on the project, including the client, can understand the wonderfully simple DSL and contribute to the bank of stories.
3. I then came in with the ace Stories can be used to drive automated browser tests! Man, they fell off their seats at the point!

It was an awesome session. A lot was discussed and understood.

Hudson, Sonar & Ruby: Continuous integration of a Rails app

April 15th, 2009 • 2 comments agile, programming, subversion, version control
Tags: linkedin

I’m currently playing (well battling at times – VMWare can be an arse at times – or maybe i’ve been away for too long) with plugging a rails app into Hudson and Sonar.

My intention is to have the Rails app on a separate server from the Hudson server and have the Rails app return Hudson-friendly XML from RSpec and Cucumber tests. When i get this to work, it’ll enable me to roll this out at work, with a central Hudson server (perhaps) that interacts with multiple app servers of various technologies and, along with the wonders of Sonar, gives a view into code test coverage, pass rate and complexity. I feel that i might struggle convincing Sonar to play with Ruby, but we’ll see.

Why Hudson?

To be completely honest, at work, i didn’t make that decision and am yet to chase down exactly why it was chosen over CruiseControl, but I completely trust those that made the decision on their project. I’m a big believer in standardising and am as such following suit and trying out Hudson.