Hacks from the kitchen

Lovefilm survival kit

Det tidligere Digitarian, nu Lovefilm, er supersmart - undtagen søgeinterfacet. Det er langsomt og besværligt og kedeligt og de anbefalinger der kommer frem for film er bare ikke fede. Godt man har Greasemonkey!. Ved at bearbejde Jon Udells biblioteksscript har jeg modificeret Amazon så man på hvert enkelt filmopslag kan se om filmen kan lejes på Lovefilm. Hent Greasemonkey. Hent scriptet. Installér. Se effekten her.

(tech note til greasemonkey hackere: Manage userscripts|Edit er din ven når du debugger)

My way into scripting stuff

I thought I'd spend a couple of minutes recounting how I got into scripting languages since it was quite a quirky way to get there. When I got started with computing (post "BASIC on an Amstrad") I was using the turbo products, notably Turbo Pascal on the PC which was a really nice environment. I truly miss the simplicity of that interface many many times, in particular I miss how extremely simple it was to write simple graphics to. Those were the days.

Anyway, Turbo Pascal and later Fortran at the university, running through compilers and all that, instilled the notion "software is difficult" in me, which of course is really stupid. Latex and Tex, other environments one is heavily subjected too when doing math, didn't change that perception. I worked a little in matlab and also in mathematica and really, really liked mathematica. Mathematica uses just what you'd expect from functional programming if you're a math major and the convenience of that tool was for me unrivalled at the time.
After University I needed a job, and luckily one was available, but still in the "software is difficult" world, namely doing derivatives pricing in C. The company I worked for had a department for doing systems engineering however. They had done a lot of tooling for our development process - an intricate make based cross platform build system, documentation compilers, memory leak checkers and more. What they were doing was all based on unix tools - but unix tools from way back when. Their celebrated platform of choise consisted of korn shell scripts embedding AWK scripts as HERE documents for text manipulation when required. It wasn't pretty, but they had grown accustomed to it. Intrigued by this I stared learning AWK, which is really a nice language, even if it is kind of limited.
At first I did mainly reporting stuff and the occasional total file or variable renaming, but after a while I started doing heavier stuff. A particular thrill was when I built a code generator, which could take C-style type definitions and output all the boilerplate required to present these C types as structured data to Excel formulas. We used this to replace a horrible handwritten mass of Excel interface code. This was clearly one of the finer hackathons I've taken part in: 2 guys 2 days, 16 hours per day. Total workload 64 hours. And it's just so much easier to get right in 2x2x16 tan in two weeks done by one guy.
All of this was done in AWK, including the parser for the template output generator. Clearly the mix of AWK limited capabilities and my limited experience did not produce a very maintainable result.
I did one other very nice project in AWK though, which was a LaTex code extractor that would take sample code from LaTex documentation, wrap the sample code in setup and teardown code and run unit tests on the code. In this way we always knew that the sample code in the product manual compiled and ran as described.
It's still easy to remember the thrill and almost sinful enjoyment in not having a compile cycle. towards the end of my time at Simcorp we were working in template heavy C++ using Visual C++ and the compile times and tremendous ugliness of the error messages was just painful.
Finding AWK restrictive, I turned to perl and has since spent many happy hours with perl. And many painful gutwrenching "I just don't get why this doesn't work" hours too. The plan has been for a long time to switch to python or ruby - we're using ruby at Imity - but recently I have to say that it seems thaty python/ruby just isn't far enough to go. It seems that its time to go fully functional, only I have to admit I haven't yet been able to choose a language to invest in.

Controlling your Mindstorms NXT robot with bluetooth on Windows

I just got my Mindstorms robot and obviously had to start working on controlling the robot remotely. This is just some notes and a "hole in the wall" test.

Setting up bluetooth devices sucks - "setting up" anything does - but here's the mnemonic route for a sequence of actions that work.

• Turn on the NXT bluetooth radio and make it discoverable
  
• Add a bluetooth device (Win XP SP2 required, control panel, bluetooth settings)
  
• Enter a passkey on windows
  
• Wait for the passkey popup on the NXT and enter the same passkey there
  
• Wait for much too long
  

Note: I found the connection setup brittle if I also used bluetooth from the program editor.

I used the perl scripts here (These ruby scripts might work for you).

Use the configuration program to update the serial port configuration for your system. COM7, the default setting, should work unless you have a ton of devices. Look for the "outgoing" Com port for the NXT.
wrt to the perl scripts above, add the line
$data = "\x00\x09\x00\x02a\x00";
to send a single letter 'a' to the NXT mailbox no 1 (zero based here, third byte is mailbox). Reading messages from a mailbox is how the visual programming environment can interact with the mindstorms robot.
I had limited success with the preset commands included in the perl script. Of all the commands in the Bluetooth SDK I only got the "PLAYTONE" direct command to work and then the more important one, which is the messagewrite above.
Note: Speed is not a feature of this communication channel.

I wrote a simple program to test: It checks the BT mailbox for a string 'a' - if it finds one it takes a quick roll back and forth. It's worth mentioning that you can't send messages to a mailbox unless a program is running - it's not enough that the NXT is turned on.

I then added a CGI wrapper around the perl script, exposed it temporarily on this webserver and had a world controllable robot. Next project: Sensor output back on the web.

Visual programming environment alert: The Labview derived visual programming environment seems buggy to me. I had to do 2 tries in generating a test program, because the first program just wasn't picking up the scanner input. I tested with the ultrasonic sensor that it wasn't buggy Bluetooth. I then reassembled the exact same program - and that worked. I got a clue when I shut down the editor and got an error message that my program had an "insane object " something or other. Very kid-friendly, that.

My test robot is here (286kb). (dig that filezise btw, that's completely insane for what the program does).