macrobug

Well, what did you expect? Obviously I’m going to post about the iPhone: I work in the mobile phone industry and I’m a Mac user. I’ve been told of two people today who foolishly read this blog so I ought to post something!

My view:

1. The mobile phone industry needs a kick up the bum. Especially in the areas of user-interfaces and reliability… or in short, attention to detail. The process of putting together a modern smartphone is fairly haphazard and driven by deadlines, and it shows in the results. There just isn’t the cohesion and usability which users should demand. (Except in Japan.)

2. The iPhone may just deliver that kick. I don’t know if Apple will have got the user interface completely right – probably not – but I bet there’s things they’ve got right which nobody else has. It’s not because they’re geniuses, but because they will have lavished attention to detail on the product. Even if the iPhone itself isn’t great, it will up the standards for the rest of the industry.

3. The phone itself probably won’t sell. I think it’s too expensive, doesn’t have 3G, will have too many annoying user interface issues (until they’ve worked them out). It’s locked to one network. I also think the lack of a third party developer community will worry purchasers, because there won’t be the tantalising possibility to expand the device (no matter how few users ultimately would have done so).

But future versions probably will! Hats off to Apple – the iPhone is still due out tomorrow and they appear to have produced a smartphone (or nearly a smartphone) on schedule – which is something rare in itself!

Finally – go and see Shrek 3 – it’s good!

I am currently about half-way through doing Macrobug’s first-ever tools contract. It’s just the sort of thing I want to be doing: porting a debugger engine from one development platform to another. It really couldn’t be closer to the areas where I want to develop a reputation and experience.

Whilst at the device manufacturer, I had an opportunity to let a small team borrow some of my tools. They used them to solve a real, tricky problem.

Don’t get too excited – Macrobug is still vapourware. This was a special case because:

1. Since we were all working at a device manufacturer, we didn’t need special access to Symbian OS.
2. The tools used were some of my early Perl prototypes – not my recent Java-based code. That’s just because my current codebase is Eclipse-based.
3. I was there so was able to fix the bugs that became apparent during the process.
4. I didn’t charge for the privilege :-)

Nevertheless… hopefully this has shown at least a couple of engineers that Macrobug tools are invaluable – I think they would have been looking at this particular problem for another couple of days otherwise.

Better still, those engineers are in two different companies, so I’ve now got useful contacts in both those organisations, who will hopefully listen when I come a’calling in the future…

As many readers (oxymoron?) know, my ideal is to get some tools-related contracts, and pull together a reputation as a solid tools developer for Symbian OS, as well as trying to sell my pre-existing tools.

Right now I am doing a short-term contract for a major Symbian licensee. It’s not tools-related, but it is related to debugging difficult problems so I’m coming up with a useful list of things which could be solved by tools. (Actually, I’m not – all the problems I’m trying to solve are too difficult to automate, but hopefully I’ll have some ideas!)

But better still, the prospects for further contracts, all tools-related, are gradually firming up for after this one. If all my current prospects worked out, I’d be a very happy bunny. Having said that, this contracting lark is quite a roller-coaster… one minute you have rosy looking prospects and the next minute you have nothing at all. So I shan’t be counting my chickens yet. They don’t like roller-coasters anyway.

Meanwhile back to phone bug fixing. Byeee….

Ouch! Bitten by a VAT quirk! Contractors – read this.

If you’re doing a contract, typically you’ll provide an invoice to a customer which lists your fees, plus any expenses incurred in performing that contract (assuming you’ve persuaded them to pay your expenses). For my last contract, nearly all of those expenses were train fares to and from the place of work. So, my invoice might have looked like this:

Note that there’s no VAT on the train fares. That’s because train fares are public transport, which attracts a 0% rate of VAT.

And therein lies the problem. Even though train fares don’t attract VAT, when I put them on an invoice for my services, apparently they are not train fares any longer. They’re part of the service I’m providing, and therefore should have attracted standard 17.5% VAT.

Sadly I didn’t know this, and didn’t find out until I went to an HMRC seminar last week. (Yes, yes, I accept it’s my responsibility to know all these things – but as I’ve said in a previous post, you can’t keep on top of everything and still have time to actually do any work.) So I am £66 down, assuming I correct this mistake on my next VAT return, and assuming I don’t try to squeeze this money out of my customer due to wanting to save face.

Oh well. Ho-hum.

I think I will be signing up to the flat-rate VAT scheme soon, to save myself some paperwork.

One of my most troublesome bits of code has been to resolve numeric memory locations into useful descriptions of the code that lived there. Many of my tools squirt thousands of these memory locations from the device to the debugger, and I later present them to the programmer. They’re useless if I can’t convert from the memory location to something the programmer can understand: the function name and source code location.

(Even a non-programmer can see that the “after” results are likely to be more useful for any techie.)

In the autumn I tried, in vain, for weeks to find a “nice” way to perform this conversion. I tried dozens of potential methods in increasing desperation. Each branch on this tree is something I tried, or a reason why it didn’t work:

The last method I tried – and the one which worked – was a Microsoft library. It’s called dbghelp.dll, and performed this conversion. But it had some problems:

• It’s slow
• It has to load big databases of symbol information, using lots of memory
• It’s hard to use from Java tools like those I’m developing
• It could conflict with Carbide’s own debugger
• It would only work on the Symbian OS emulator, running under Windows

Because of that, the code was complex and I didn’t properly trust it.

Nokia came to my rescue.

At the pluginfest back in January, Ken Ryall from Nokia offered to make an API available within Carbide to perform this conversion on my behalf. (API = application programming interface, essentially a means to provide access to somebody else’s code). The theory being that Nokia’s debugger code already has routines to perform this conversion – it’s just that independent plug-in developers like myself didn’t have access to it.

Well, in the past couple of Carbide beta releases, he’s done it. And it works. I expect I owe him (or somebody) a few beers, but other than that, Nokia have just done it out of the goodness of their hearts, and because they want to encourage third-party plug-in developers like Macrobug.

Thanks Nokia, and Ken specifically!

Now, for the techies, here’s how to use it:

ICDITarget cdit = ((CDebugTarget)dt).getCDITarget();
if (cdit instanceof ICDIAddressToSource) {
	IMappedSourceLocation loc;
	try {
		loc = ((ICDIAddressToSource)cdit).getSourceForAddress(address);
	} catch (CDIException e) {
		throw new SymbolResolutionException(e);
	}
}

The resulting ‘loc’ contains everything you need.

Ken is contributing this as a standard part of Eclipse CDT, so it should even be available outside Carbide.c++. Woohoo!

I seem to have plateau’ed at 140-odd bugs. That’s great news! I have been trying hard to think what might be wrong, and I was really expecting to come up with hundreds upon hundreds of bugs.

Even better, I’ve fixed three already!

Mylar is indeed pretty good – it integrates very nicely with Bugzilla, although I don’t like all of its features as much as I should.

I’ll post more about it in a couple of weeks…

This will be the first article I’ve written in a while which is related to new-techie-business setup. The reason is simply that I did all my setup before Christmas, and have just been beavering away working since then.

However, as I mentioned a few days ago, I’ve now got to the end of my “experimental” phase, and my code is settling down into a proper portfolio of products. There are lots of bugs which need tracking, before things reach saleable quality.

For those non-techies reading, bug tracking may seem an obscure thing, but it’s very important. Programming is hard – sufficiently hard that it’s impossible not to make mistakes. Hence, for any given project, perhaps half the total programming time is just spent fixing bugs you made in the other half. It rather depends on your development methodology, but either way, you need a system to track your bugs.

My requirements for my bug tracking system were:

• Open-source
• Undergoing active development
• Can import and export bugs in some sensible format

The first bug-tracking system I looked at, Bugzilla, fitted the bill, so I just went with that. I am not aware of any other open source bug tracking systems but I expect they exist – and I suspect some of the commercial ones are free for small-scale use (which would be a good policy for the creators, because once you’ve picked a system it’s hard to change).

I was pleasantly surprised to find out that my shared-hosting server at my ISP contained all the required dependencies to get Bugzilla running straight away. So I now have it running on an “intranet” part of the Macrobug website.

I also want to give Mylar a go, to integrate Bugzilla into Eclipse. I’ve only heard good things about it.

Meanwhile, I’m still coming up with that list of bugs to put into Bugzilla. Right now I’ve only thought of 96 things – which I’m sure will easily double, but it’s still less than the 500 or so I was estimating. Which is nice. Many of them will take several days to fix, though, so it’s still a while before I have a polished product.

Today, I raised my first bug on myself.

I predict I’ll be following up with several hundred more in the next few weeks.

This is quite an important milestone for me: it means my gubbins are reaching the end of the ‘hack-and-experiment’ stage, and hopefully settling down towards becoming a product. So, once I’ve raised those 500 bugs, I’ll be having to fix them all. (And a lot of them are going to say “this bit is missing test code” so I’ll be writing a lot of test code too).

In other news, Symbian OS tools-related contracts are like buses… you wait ages for any, then five come along at once.

However, also like buses, I fear that none of them will actually stop at my particular bus stop. We’ll see. Ting ting!

Phew! It works.

The problem was a ‘missing link’ between two types of information which made the whole flow-of-control trace a bit useless. I have found a way to link the two types of information, and the trace now happily spans all the threads and tasks.

Screenshots hopefully soon – a few things to sort out before I can post them.

It won’t be long before I start to demonstrate my wares to people! (The real proof of the pudding.) Anyway, fortunately, my slow development progress before Christmas has been reversed since, and I’ve now reached the point that I had planned to reach at Easter. Woohoo!

At the beginning, I said I was scared about three things: the technical side, the co-operation-with-Symbian side, and the marketing side. The first is now officially ticked off the list. The second is going OK. The third is a big unknown :-)