The day started with a supply run. Chris, James and I went to B&Q to buy some timber and other bits and pieces we'll need for constructing the flats. Unlike the day before, the weather was nice and sunny.

With the timber loaded, we headed back to the yard for some serious construction. The bench we built was based on a design I found at Hammerzone, with a few basic modifications. Here's a picture of the design in Sketchup:

The main difference with this design is that I've added a way to slot extensions into the ends of the bench, which can act as support for timber when using the mitre saw. These supports will eventually have some custom jigs which allow the timber for the flats to be cut very quickly (without the need to measure each piece). Given that we will need to saw approximately 60 pieces by the time we are done, it seems like it might be worth it, especially since it will help to ensure everything is the same size.

The first thing we did was assemble the frame for the tabletop. This was quite straightforward:

1. Cut the pieces to length
2. Drill one pilot hole in each corner and screw the frame together
3. Use the tabletop timber to square up the frame
4. Drill more holes, one in each corner and screw together.

The frame was pretty sturdy by itself, and we then fixed the table top to it with more piloted wood screws. Finally we attached the cross-pieces for holding the end of the extended supports.

Next we attached the legs of the table. Even without any further support, the table was pretty sturdy. Standing 3' tall, it was already the perfect height for measuring timber.

James can be seen here measuring for the lower reenforcing frame.

We made a few small adjustments to the original design shown above. The main one was to add triangular cross-bracing at the ends of the bench. This has greatly improved the front to back stability, and it barely wobbles, even when given a solid shove. Here's the finished article, loaded up with a pile of tools.

We finished off the day with a barbeque - the first of 2009!

We don't know which show it is, or where it is being performed, but we do know we need a new set, the old one having mostly fallen apart or been dismantled.

Sunshine and Showers

First things first, we needed to clear out the remnants of still-assembled set from our storage container. This was mainly the tops of the pagodas from The Mikado. After dodging the rain all morning, we decided we'd done about as much as we could.

So, after a trip to the pub for lunch, we tidied up back at the container, grabbed a few useful tools, and returned to my back yard to begin experimenting with power tools.

After some considerable time working out how to set up a router to cut dovetail joints, we finally made the tongue part of the joint. It's going to need some more work to get these made efficently - I'm planning on making a jig for turning these out very quickly. Here's a picture of james finishing the first part off with a hand saw:

The groove part of the joint (socket, notch, I'm not sure of the correct terminology here) was trickier to make. The first attempt was a bit of a mess, and makes a fairly loose joint. But it holds together, without glue or screws, which is impressive for a first attempt. Only 80 or so left to make.

I'll be describing in more detail how the pieces all fit together as we go along. For now, here's a nice 3D rendering of what the finished framing should look like:

Diagnosis

It appears that the problem was too much play in the rotor shaft: when it sits on the ground, the shaft drops the bottom (large) gear down by about 1mm, causing it to partially disengage from the motor (small) gear.

The easiest way to fix this is to reduce the slack in the shaft. The rotor itself and the gear seem pretty firmly glued on, so I didn't fancy my chances of pushing them together any more without breaking the 'copter. In this picture, you can see the extra space between the bottom of the rotor and the white nylon spacer which is causing the vertical movement in the shaft.

Making a spacer

Since I didn't have any way to remove the rotor without breaking something, I decided I needed some kind of clip washer to go between the rotor and the spacer. When the helecopter is operating, the spacer will sit on the bearings and the rotor will rise up, leaving all the slack between them (as indicated above by the arrow). This then is the best place to add an extra spacer.

I started out by stripping a small piece of wire from a twist tie. This length was actually a bit short, as you will see in the next image.

I folded the wire in half, leaving a loop which will form the washer. The next step was to hook this loop around the rotor shaft in the space, and twist it closed to form a ring which won't slip off.

Finally, I trimmed the extra wire with wire clippers as close to the shaft as possible.

This left me with an extra loop of wire in the slack space, which pulls the gear up and into the right position when the 'copter is sat on the ground.

All fixed

You should just be able to make out the wire washer in the enlarged version of the above image.

With this modification in place, the grating noise is gone, and take-offs are much smoother. I'm having much more luck getting the helecopter stable after launch, so I count this as a success.

After a few experiments I tracked this down to Facebook's re-encoding process, since the source videos are fine.

Putting videos on Facebook

There are a few ways to achieve putting videos onto Facebook. The most useful is the Videos application provided by Facebook itself, since it includes the usual tagging and descriptive features.

In order to get my 3gp format videos to work correctly with the Facebook videos app, I had to first transcode them into a more common format. First I tried FLV (Flash Video) since this is the format that will eventually be used by Facebook. This seemed to produce similar results to the original source video, with noticeable desync by the end of the video (about 3 minutes).

I had better luck generating an mp4 format file, which seems to result in correct behaviour.

Interestingly, the mp4 file resulted in a Facebook video which was approximately 30 seconds longer than the one created by uploading the original 3gp file.

Alternatives to the Facebook Videos app

I also tried using a couple of file sharing sites: DivShare and Box. Both of these sites have their own Facebook apps which allow you to add files to your profile, or share them directly with your friends in wall posts, etc.

These allowed me to use a file I had transcoded myself, thus allowing me to make sure it was converted correctly. Uploading the mp4 file used above didn’t yeild a particularly useful result: Box recognised it as a video format, but couldn’t play it in the browser, and DivShare had similar results.

The FLV file however was picked up by both sharing services and presented to the user in a Flash player.

These services’ only real advantages over the standard video sharing system are the abilities to do your own encoding (potential for higher quality) and to share all sorts of files using the same system.

I would recommend DivShare over Box for casual video sharing - it’s Facebook portlet is more usable (just a simple list of shared files, compared to a complicated folder system), and you also receive 5GB of storage straight off, without the 20MB per friend system imposed by Box.

Making reports prettier

Paperclips is a Java library which aims to simplify printing support in SWT by providing an object model for constructing documents. These ‘building blocks’ consist of tables, headings and images.

In RapiTime 1.4, I implemented printing support from the new Java GUI based on Eclipse, and chose Paperclips as a quick solution for printing report pages. In version 2.0, the GUI embeds charts directly into the report pages (previously only tables were displayed), so the printed reports needed to reflect this.

The charts are drawn unsing the excellent JFreeChart library, which provides renderers for a great many different types of chart. Due to the nature of the RapiTime dataset, we’re mostly using bar and pie charts for the time being.

Embedding JFreeChart in Eclipse Forms

The first step was to get JFreeChart embedded in the report pages on screen. The reports are built using the JFace Forms framework, which is built on top of SWT, but JFreeChart is natively a Swing component. SWT has some support for hosting AWT (the layer underneath Swing) controls, so that was my first attempt.

It wasn’t great though - the JFreeChart control kept all its AWT/Swing menus and properties dialogs, which look slightly out of place amongst the slick OS-native interface provided by Eclipse. I probably could have improved matters by applying the correct “look and feel” to Swing, but decided to try out the experimental SWT container for the chart instead.

This basically reimplements most of what the Swing Chart control does using SWT. When it gets to providing a drawing surface for the chart plot, the swing graphics context is emulated by a wrapper around a SWT graphics context called SWTDraw2D. The result is surprisingly effective, and allows seamless embedding of the chart in any SWT window.

Printing Reports

The reports are built up using the Paperclips GridPrint class. It’s pretty flexible, and all I need to do is pull the values out of the tables in the on-screen report, and place them in the printed equivalent.

For charts, we don’t have an alternative data structure, we just want to use the same JFreeChart renderer as we use on the screen. Luckily paperclips provides the ability to create new PrintPiece objects which render directly to a graphics context, so that’s what I attempted to do.

public void paint(GC gc, int x, int y) {
	Transform t = new Transform(gc.getDevice());
	gc.getTransform(t);

	float[] elements = new float[6];
	t.getElements(elements);
	Transform t2 = new Transform(gc.getDevice(), elements);

	// Apply transformation for printer resolution
	Point printerDPI = gc.getDevice().getDPI();
	Point screenDPI = Display.getCurrent().getDPI();
	float scaleX = printerDPI.x / screenDPI.x * 1.5f;
	float scaleY = printerDPI.y / screenDPI.y * 1.5f;
	t2.scale(scaleX, scaleY);
	gc.setTransform(t2);

	SWTGraphics2D graphics2D = new SWTGraphics2D(gc);

	// Decrease rendering size
	chart.draw(graphics2D, new Rectangle((int) (x/scaleX), (int) (y/scaleY), (int) (width/scaleX), (int) (height/scaleY)));
	graphics2D.dispose();

	// Restore original scaling
	gc.setTransform(t);
}

The code above scales the coordinates used for rendering to match the printer’s resolution. It then creates a new SWTGraphics2D instance which is used to render the chart control.

Unfortunately there is an incompatibility between the JFreeChart’s SWT renderer and Paperclips.

In SWTUtils.java, there is a method which checks that font sizes match each other between SWT and AWT. This fails however when the device behind the SWT graphics context is a printer:

GC tmpGC = new GC(device);
Font tmpFont = new Font(device, fontData);
tmpGC.setFont(tmpFont);

My workaround is to omit this check when the device is an instance of Printer. This doesn’t seem to cause great problems, but due to my scaling of the chart coordinates above, I’m not sure exactly what it does to the font sizes. The patch can be downloaded here.

Roll the presses!

Putting it all together, you end up with something like this pdf.

I finally gave in to temptation and bought myself a new MacBook. I was quite keen to try out the Apple Boot Camp software for myself, and have a native version of Windows running on my Mac.

The only spare licence I had was for Windows 2003 Server - it was left over from before we installed linux on our house server and wasn’t installed on anything any more. So, after reading about the Windows 2003 - XP conversion pack, I decided to give it a go.

Installation

Installing Windows was easy - after updating the firmware and installing Boot Camp, I split up my hard drive to give Windows a 20GB partition. The new firmware provides a nifty graphical boot loader (you can switch between installations by holding down the alt key while it boots) which would seem to allow you to boot from any bootable partition. It certainly allows you to boot from both hard drive partitions and the DVD drive if there’s anything in it. I’ll have to try installing Windows without Boot Camp at some point to see if it’s actually doing anything except providing a repartitioning app.

Once installed, 2K3 asked me to press Ctrl-Alt-Delete to log in. This set me back a day since you can’t seem to type that combination on a MBP keyboard. I went out and bought a cheap USB keyboard, which seems a bit of a waste since I only needed it for 5 minutes.

After running the XP conversion pack, everything worked much like an XP-Pro installation.

Drivers

I declined the option to burn a CD with the drivers on - I didn’t have a CDR to hand - so I opened up the package, mounted the DMG file containing the drivers, and copied them to a memory stick. This seemed to work just as well.

The main hurdle came when I tried to install the drivers - the setup program only works on Windows XP. I was pretty sure the drivers were exactly the same for XP and 2003, so I set about trying to get them out of the installation package. After several false starts, I managed to extract the drivers. The command is:

Install Macintosh Drivers for Windows XP.exe /V /a

This will perform an ‘Administrative Install’ and bypass the normal installer checks. This allows the installation files to be extracted to a directory of your choice.

The drivers were pretty straightforward to install, you have to do each one manually, but there aren’t that many of them. I’ve still not managed to get everything working, Bluetooth for example so I think I may be missing something.

The main problem I have is that Service Pack 1 won’t install. It gives me an unhelpful message telling me I haven’t got enough space to make backups, or install (if I disable the backups). I’ve slipstreamed it into a copy of the installation CD, but I can’t seem to use that to upgrade the existing installation. I’ll probably have to do a reinstall instead. For the time being I’m bypassing SP1 and installing about 60 updates from Windows Update.

Keyboard Layout

Finally, I’ve been tweaking a few things to make them work a little more like they should.

I couldn’t find an appropriate keyboard map for the Apple keyboard. I tried about four different key mapping utilities without success, until I happened upon Microsoft Keyboard Layout Creator (MSKLC). This is a handy little utility which allows you to create new keyboard maps for Windows XP and 2003, and even packages them for you with an MSI installer. Below are the screenshots for the new layout I created.

You can download the mapping DLL and the MSKLC source file to use yourself. I mapped the ° (degree) symbol to Alt Gr-8 on a whim. Also, the section/plusminus key doesn’t work at all under windows.

Exposé

I remember trying a few Windows Exposé-esque utilities about 18 months ago when I first got a Mac and was pretty impressed with the idea. Unfortunately, I was less impressed with the Windows implementations.

I decided to have another look around to see if there was anything new, and came across iEx. iEx does what you’d expect, and seems to perform pretty well on the MacBook (it should do, with all that CPU power to make use of!). I’ve yet to use it in anger, but with light usage it seems to be extremely quick.

iEx is free, but is pretty basic. I’d like to be able to drag-n-drop between windows in the same way as in OS X, but that’s my only quibble.

Conclusion

I’m pretty happy with the way the install went. The only remaining problems are to do with a few drivers, and hopefully they will be fixed if I can run windows update properly, which won’t happen until I’ve managed to get Service Pack 1 installed. I’ve still to fully test this, but so far I’ve not had any problems. The platform is pretty stable. I’ll post an update if and when I get everything working.