Wednesday, July 19th, 2006

Time	Event
12:04a	I'm moving, time for a cheesecake. One of the joys of working from home is that you can leave anywhere. I figure that means home can be bangkok for a few months. I've got the leave approved for Sept, and flights booked. I'm quite excited by the opportunity, but a little scared about what I'm leaving behind. I figured I'd make a short list; friday beers with the fellas buying slurpees and reading the paper with friends getting cooking lessons from my South Australian friends cooking dinner for people I offered to cook a 'cheesecake' (not mentioning the Chili & Lime part) for a friend who's also moving. It seems I can no longer find habaneros at the supermarket, so I substituted for a mix of other chillies. This is a recipe I've cooked twice prior, but I'm not sure how it will turn out this time. I figure if nothing else, it will be a legacy to be remembered by. (Comment on this)
9:55p	I want my 4 bytes back damn it. I was working with a customer today, and I noticed they used varchar(10) to store an ISBN. This got me thinking, is that the most efficient way of storing an ISBN? Some quick googling revealed that it is always 10 characters in length, so while a varchar would take 11 bytes to store this, a char will only take 10 bytes (the extra byte in the varchar is required to maintain the length). But an ISBN is not a string, it's a number. To store a 10 digit number, I need a BIGINT(10) ZEROFILL; that brings it down to 8 bytes. A bit more googling, and I find out that the tenth digit in the ISBN is actually a checksum. I think to myself for a second that if I can recreate that checksum, I can move down to an INT(9) ZEROFILL, which means 4 bytes. 4 bytes for storing what was previously 11 bytes! Of course, I had to share my excitement with one of my colleagues, who then told me that as of Jan 07, ISBNs are moving to a 13 digit representation. Damn it, I'll have to stick to my BIGINT(13) ZEROFILL. For those that are curious, 978 will prefix existing ISBNs (1 Comment | Comment on this)

<< Previous Day

2006/07/19 [Calendar]

Next Day >>