macrobug

I’ve…

• Burst my spleen in a snowboarding accident, nearly fatally…
• Got married
• Quit my long-term job and started my own company

What a memorable year! :-)

Thanks to everybody who’s reading! May you have a terrific 2007.

I trust all readers had a good Christmas.

Here are some of the presents I got for Christmas.

I’m not quite sure, but I think there’s a theme…

I seem to get a lot of post addressed to MacRobug Ltd. There’s obviously some automatic capitalisation software in use somewhere in the world which thinks I’m Scottish. Hoots man!

Merry Christmas to all you readers.

Ari Jaaksi’s blog is a good read for anyone interested in non-Symbian mobile devices. He works on the 770 Internet tablet. They use D-Bus for message passing: a system with very similar semantics to how things work in the Symbian universe.

However, Symbian’s message passing is used uniformly throughout the operating system, whereas I bet that D-Bus is only used in certain components on the 770 where Nokia’s teams have put it in place. For example, broadcasting battery status notifications, etc.

Whereas, for example, accessing files or network sockets is done through kernel APIs, there’s bound to be some processes that still communicate using CORBA, sockets, signals, UNIX shared memory etc… So although Macrobug tools should theoretically be much easier to put in place on Linux due to its openness, I suspect in practice the results would be rubbish until the tools had good support for tracing all these different types of interactions.

Anyway, an interesting read, nonetheless.

Apologies for the non-techy readers of this blog. I’ve got to post this techie stuff somewhere - I’ll eventually probably create a library of technical articles somewhere on this website.

Eclipse’s modularity is successful partly because it contains great tools for creating Eclipse plug-ins. But those tools break down when you want to create a plug-in that includes native code. Of course, you want to avoid that in the first place since it won’t be cross-platform… but sometimes you have to.

Here’s a recipe for creating a native plug-in on Eclipse 3.2. There might be better ways!

First of all, reference sources…

• [1] The University of Manitoba has a good walk-through but it’s for Eclipse 2.1. In many ways this article is just an update of that.
• [2] What if you can’t find the Convert to C menu option?
• [3] How to mix Java and C code in a single project
• [4] More about how this stuff should work in future
• [5] Request for nature refactoring
• [6] CDT interworking with JDT

First, if you’re not familiar with JNI, read the introduction in [1] - it’s much more thorough than this. This article just talks about how to do it in Eclipse.

Step One - create your plug-in project

Create a standard Eclipse Java plug-in project.

I used the “Hello, world” template to create a plug-in which will create a menu command. By default, it prints a string: “Hello, we’ll soon be replaced!”… our intention is to replace that with a string generated by native code.

Check that your plug-in builds and runs (Run As Eclipse Application), and that the menu option appears as intended and does what you wanted.

Step Two - making Java code changes to call a native API

Here’s where you write your JNI code in the Java. Refer to [1] if you don’t know enough about JNI. I’m adding:

    public native String getNativeMessage(); 

    static {
        System.loadLibrary("testjniplugin");
    }

and of course changing run to

	public void run(IAction action) {
		String message;
		try {
			message = getNativeMessage();
		} catch (Throwable e) {
			message = e.toString();
		}
		MessageDialog.openInformation(
			window.getShell(),
			"MyProjectWithJNI Plug-in",
			message);
	}

Step Three - watch it break

Now try running the Eclipse application. Impressively, Eclipse works fine, and even gives you a nice error message if you choose the offending action.

Step Three - Add C Nature to the Project

Eclipse projects have one or more “natures” - for example, Java or C++. We want to add a C nature to the project. See [4] and [5] for information about how this should work in future, but for now, it’s a little fiddly.

1. Choose Window -> Open Perspective -> Other
2. Select C/C++
3. Right-click on the project folder
4. Under New, select Convert to a C/C++ Make Project
5. Choose C

If you choose Build Project, you’ll find that nothing much happens. You’ll get an error message:

make -k all
make: *** No rule to make target `all'.

So we have to tinker with the build files.

Step Four - add a Makefile with javah

1. In the root of the project, select New -> File.
2. Entitle it Makefile.
3. In the Makefile, add the following lines:

all : myprojectwithjni_actions_SampleAction.h
myprojectwithjni_actions_SampleAction.h : bin/myprojectwithjni/actions/SampleAction.class
	javah -classpath bin -jni myprojectwithjni.actions.SampleAction
clean :
	-del myprojectwithjni_actions_SampleAction.h

For those new to JNI, javah is a command which takes a Java .class file and creates a C .h file representing the different native functions therein which need to be implemented.

Now right-click on the project and select Build Project. You’ll find that a new file appears in the project view: myprojectwithjni_actions_SampleAction.h. The important line of that file is the function you must implement in your DLL:

JNIEXPORT jstring JNICALL Java_myprojectwithjni_actions_SampleAction_getNativeMessage
  (JNIEnv *, jobject);

Note that we’re being passed a JNIEnv and a jobject - the latter being the SampleAction class on which our method is being called - and returning a jstring.

Step Five - Add a C (or C++) file that implements it

We now add our C code to the project. First choose New -> Source folder, and name it nativesrc. Secondly, add a new source file - SampleAction.c - within that folder. Put in:

#include 
#include “myprojectwithjni_actions_SampleAction.h”
#include  

JNIEXPORT jstring JNICALL Java_myprojectwithjni_actions_SampleAction_getNativeMessage
  (JNIEnv * env, jobject obj)
{
    return (*env)->NewStringUTF(env, “Here’s a native string in UTF8!”);
}

and of course the Makefile will need some changes:

all : testjniplugin.jnilib

testjniplugin.jnilib : nativesrc/SampleAction.c myprojectwithjni_actions_SampleAction.h
	gcc -I . -I /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/headers -c 
		-o testjniplugin.o nativesrc/SampleAction.c
	libtool -dynamic -o libtestjniplugin.jnilib testjniplugin.o

myprojectwithjni_actions_SampleAction.h : bin/myprojectwithjni/actions/SampleAction.class
	javah -classpath bin -jni myprojectwithjni.actions.SampleAction 

clean :
	-del myprojectwithjni_actions_SampleAction.h
	-del testjniplugin.jnilib

(Note the eventual library is getting called libtestjniplugin.jnilib. That’s under MacOS X. The filenames and commands will be somewhat different under Windows. See [1] for the details).

You should see the .jnilib DLL appear in the project:

Step Six - Run

That should be all you need. Now run the project and try the menu item in the spawned Eclipse. You should see it working!

If it still doesn’t work, you can try to manually add the DLL to the library search path like this.

Remaining unknowns

• Whether there’s a way to use Managed make, or Ant buildfiles, to build the native stuff. [3] suggests so, with some hackery. And whether there’s any way to make things cross-platform by doing that.
• Whether you can arrange for C++ code to hit breakpoints while you’re running your DLL in a spawned Eclipse. Doug at [6] suggests not, for now.

At the beginning of this adventure, back in October, I said I’d work 3-6 months part-time, then I’d have to make a decision about whether to go full-time.

I guessed right. I’m four months in, and I’m going full-time from today onwards.

That doesn’t mean, by a long shot, that I think Macrobug is going to be a success or bring me any income in the near future. If anything, it’s the oppposite - I wasn’t getting anywhere part-time so I need to work harder at it. That doesn’t really come as a surprise.

My early blog posts (gosh, I hate the word blog - maybe I’ll change this page to Macrobug Diary)… My early blog posts stated quite a few obstacles that might completely have sunk the whole thing. These included technical problems, saleability problems and relationship-with-Symbian-or-Nokia problems. I was expecting one or other of these to totally, unarguably, doom the whole thing. Much to my consternation, none of them have done so, so I’ve had to make more “squishy” subjective decisions about whether I think it can work.

My conclusion is - I still think the business idea is sound. I think there’s a need for greater intelligence in debuggers, and I think that a business can be built up around it. I also think that doing it on Symbian OS first makes sense - it’s so much easier.

So, I’m quite pleased that after a few months effort I still think the business is valid.

However… the scale of the task is appearing more epic with every moment that goes past. Although I knew from the beginning that it could take years to make a viable income out of it, I genuinely thought I’d be able to knock up some sort of prototype in a few months, which I could demonstrate to Symbian and to potential customers. That prototype, in itself, is now seeming like a nightmare long project. There’s too much technical uncertainty, and every avenue I turn down seems to be a blind alley - I run up against limitations in Symbian OS, or Eclipse, or Carbide, or something else. I knew from the beginning that I’d face big performance problems, shifting around so much data. They were worse than I feared.

Anyway, it’s this paradox of potentially good idea versus lots of trouble actually doing it, that makes me need to go full-time to see whether it works.

Hopefully at Easter I’ll be a bit further down the path. My stated aims for the next two or three months are to get that prototype working… or at least, have worked out all the remaining technical uncertainty points so it’s just a clear run of development until I have something working.

We’ll see.

What do I do in my spare time? (Except for DIY, grumble grumble). I think most of the readers of this blog know me, so they’ll know I am into mountain biking and snowboarding. My particular favourite is snowboarding; my wife’s is mountain biking (though we’re averaging out gradually).

We have some friends - Dave and Ruth - who are really into snowboarding. Last winter they somehow managed to spend around six weeks snowboarding (yes, they have proper jobs too). These guys are moving to Vancouver, at the foot of the mountains in the city’s north shore.

They’re obviously moving there primarily to increase their snowboarding opportunities.

But - this is the weird bit - they are not interested in mountain biking. Anyone who knows anything about mountain biking will know that “northshore” is now, effectively, a globally known noun. That noun represents raised wooden cycleways, made famous by those over marshy bits in the tracks down the mountains of the north shore of Vancouver. They will be five minutes’ cycle away from some of the very best downhill mountain biking territory in the whole world. Whistler, just up the road, is a world-renowed mountain bike resort in the summer too. Why would they ignore the mountain biking? Mad.

I think it’s almost inevitable that Dave, at least, will succumb and get a mountain bike, but right now he is vehement in his belief that mountain biking is “rubbish” and doesn’t give you the “floaty feeling” that powder snowboarding does. Well, perhaps not, but there’s something really satisfying about nailing the correct line down some tricky singletrack on a bike, which I think is probably as good.

Right now Dave and Ruth are in the middle of their journey from London to Vancouver… via New Zealand. Their exploits are here.

A lot of people seem to think I’m schizophrenic about Carbide.C++ (the development environment into which my tools are intended to plug).

Some days I am heard saying “it’s great!” only to be found swearing at it a few hours later.

I don’t think this is too much of a contradiction. The IDE itself is a huge improvement over CodeWarrior, and the openness of the Carbide environment lends itself to plug-ins, enhancements and so-on. Furthermore (except for the fact it’s not open-source) I think Nokia have done quite a good job of enhancing the standard Eclipse IDE to support Symbian OS in a sympathetic way.

But, Carbide is a first-generation product. There are still lots of rough edges, and when you run into them, they’re hugely frustrating. Examples include:

• Inability to import MMP files whose SOURCEPATH statements start with “.\..”
• Hours to import certain types of MMP files.
• Refusal to import MMP files containing unknown keywords (instead of a warning).
• Massive CPU usage (and consequent emulator boot failure) when your emulator is logging significant information to the console, and you’ve told Carbide to display it
• Annoying way it insists on rebuilding everything on startup, even if you haven’t changed anything
• Import from bld.inf ignores PRJ_EXPORTS
• Lots more

Undoubtedly every other Carbide user has their own list of bugbears. (Lots showed up on the Carbide beta mailing list last time!) All of those things are hugely frustrating, and darn it, I will swear about them, but they don’t affect the fact that it’s fundamentally a good product.

The big question is, how well will Nokia respond to the challenge of smoothing these rough edges? Undoubtedly they’ve received hundreds of requests… do they have the customer focus required to smooth these rough edges and make Carbide into the product it deserves to be? Or will they just fill up the next release of Carbide with high-profile new features like user interface editors, without spending enough time polishing these nitty-gritty things?

We’ll see. (I wonder if the Carbide team still read this blog?)

A lot of people assume that contractors are rich scummy gits.

It’s true to an extent, so long as you have a long-term lucrative contract. Let’s do some sums on a hypothetical contractor. Numbers are based on a few contractors I’ve spoken to - so don’t assume they relate to me, cos they don’t.

Gross salary if they weren’t contracting: say £50,000.
Net salary if they weren’t contracting: That might leave £32,000 net salary after tax and national insurance has been deducted.
Effective net salary: add on 6% pension payments your company makes and a couple of other percent for miscellaneous benefits like life insurance, and you can call your net salary £35,000. All very approximate of course.

Contracting rate per hour: £50
Hours a week: 40
Weeks a year: 44.

Why 44? Because some of that time you’ll be ill, or on holiday, or will be between contracts. None of that you get paid for.

Income per year: £88,000

Gosh, that’s a lot isn’t it? We can deduct a bit for operating expenses of running the company (accountants etc.) and also for hardware and software, which typically a contractor has to provide. So let’s say:

Effective income into company: £80,000

Now what do we do with that? It rather depends on the Inland Revenue. They have a set of regulations called IR35, under which they assess your contract. If you appear to be like a regular employee of the company to whom your company is contracting, they’ll treat you like an employee and tax that £80,000 as a standard gross income. In which case you can expect your net salary to be about £44,000.

However, if your contracts are riskier, shorter-term, and look more like genuine task-based contracts rather than employment, you are “outside” IR35 and there is another option.

That option is to pay yourself a small salary - say, £6,000 - and take the rest of the cash as company dividends. Since you’re the only shareholder and director, you can do that. Income tax is not due on dividends - woohoo. However, dividends come out of company profits. Company profits are taxable (through Corporation Tax) - but that’s only 19%. So your income will effectively be taxed at 19% (plus a titchy amount of income tax on the £6,000). Net income: £66,000.

Seems pretty appealing hey?

But… (didn’t you know there would be a but?)

• You accept the risk that if you fall ill, or get unemployed, that’s it - there’s no safety net.
• You have to actively try to sell your services.
• If you end up with a cushy low-stress contract for a fixed number of hours a week, the Inland Revenue will decide you’re an employee and tax you accordingly, making the whole thing much less attractive. Contractors will therefore only make really big heaps of money if they are accepting a lot of risk.
• No chance of career progression/pay rises. Not as fully integrated into teams. etc. etc.

For me the biggest downer is the extra risk. For example if you get RSI you’re pretty messed up. Most contractors accumulate so much money that the cash heap acts as effective insurance against such problems (or they can use some of the income to get insurance against such illnesses etc.) Obviously, contracting part-time, I am actually earning less than I did with my full-time job, so I have no such cash pile as protection against such problems. Scary! At least I’ve got a talented and beautiful wife who can support me if it all goes tits up. Can’t you, dear?

Even full-time contractors aren’t happy. I don’t know of a single one who wishes they didn’t have an interesting full-time job.

In my case, taking a contract to bring some income into Macrobug seems like it was probably the right thing to do. But spare a thought for the full-time contractors - they’re probably rich but miserable.

(See Contractor Calculator if you want to play with these figures.)