Using Xcode and Interface Builder is like a bizarre, retro-futuristic dream, where Code Warrior for Palm OS has somehow evolved into the interface for the Great New Empire.

On the date of the last scheduled shuttle launch, I started thinking about return on investment.

NASA’s entire cumulative budget, from 1958 through the present, in dollars (adjusted to 2007 value), has been $843 billion.

Our little adventure in Iraq has cost over $1 trillion.

Which has done more for us as a nation?

Wikipedia page on NASA’s budget
Wikipedia page on Iraq war expenditures.

I just received my paper copies.

You can get a copy too!

(I wrote this back in October of last year, never bothered to post it. I probably had a reason for that, but it’s long forgotten by now, so I might as well post what I had.)

So I wasted a great deal of time trying to get my SHA-256 hashes from a .NET application to match up in a PHP application. It seemed really like it should be straightforward: make sure your string has a known character encoding, SHA-256 digest it, and then base64 encode it. How hard could it be?

Well, after a day of ripping my hair out, I concluded it’s harder than it seems. Here’s what the problem is: the application I’m trying to match encodes the strings as UTF-16 before hashing them. Unbeknownst to me, the double-byte strings are big-endian in one case, and little-endian in the other, even though they’re on the same Intel box. Took longer than it should have to track that down.

Oh, but is that the end of it? No, no, no. No, it’s not.

I also had to decrypt some strings. It was encrypted using the ManagedRijndael class, and I had the key and iv string. Those strings also got encoded into wrong-endian UTF-16, which was easily fixed (once I knew what was going on). But I was still getting gibberish. Well, to make a very long story short, the ManagedRijndael class in .NET and the mcrypt_generic function using Rijndael256 algorithm in cipher-block chaining mode in PHP aren’t exactly compatible. The mighty Google finally pointed me to the solution, which is using the Rijndael128 algorithm. The ManagedRijndael class creates actual AES-256, which mcrypt_generic is using Rijndael, which differ in the length of the initialization vector. Switching to the Rijndael128 but still passing the 32-bit key is equivalent to the AES-256.

What’s all this mean, then? This is all stuff that’s probably pretty obvious to anyone who knows anything. I, however, found this bewildering and confuzzling.

Back a few years ago, I posted a quick’n’dirty tool for generating plausible user data. I had a need for some improvements, so I’m posting the new version here.

The new version supports back-references, composite fields, and SQL output. So, for example, you could do:

./user-data-maker.pl -t id:lname:fname:city:state_code:zip:company -f i:ln:fn:c:s:z:/1+^+[Cars,Trucks,Boats,Planes,Motorcycles,Ships,Trains]+^+of+^+/3 -s -m tbl_dealer -n 5

and get the following output:
-- generated data from ./user-data-maker.pl
INSERT INTO tbl_dealer (id,lname,fname,city,state_code,zip,company) VALUES (0,'Nelson','Leslee','Akron','OH',44311,'Nelson Boats of Akron');
INSERT INTO tbl_dealer (id,lname,fname,city,state_code,zip,company) VALUES (1,'Bowen','Beatriz','Miami','FL',33176,'Bowen Trucks of Miami');
INSERT INTO tbl_dealer (id,lname,fname,city,state_code,zip,company) VALUES (2,'Hammond','Raymond','Ninilchik','AK',99639,'Hammond Motorcycles of Ninilchik');
INSERT INTO tbl_dealer (id,lname,fname,city,state_code,zip,company) VALUES (3,'Kim','Arielle','Columbus','MI',48063,'Kim Ships of Columbus');
INSERT INTO tbl_dealer (id,lname,fname,city,state_code,zip,company) VALUES (4,'Estrada','Warner','Iuka','IL',62849,'Estrada Cars of Iuka');

Nothing earth-shattering, but useful to me. Maybe to you too!

Download it here: user-data-maker.pl.gz