GigaMegaBlog

I have long been a fan (and subscriber) of O’Reilly’s Safari service. This web site gives you access to a vast library of books (currently 4000), mostly tech-related. Rather than purchase each book, you can sign them out to your “bookshelf” and read them in a browser. The books include recent titles from major publishers, with more added every day.

I love this idea because:
a) if you read a lot of books, it is a lot cheaper than purchasing them individually
b) it allows you to copy and paste text, which for me is a much better way of taking notes than a highlighter
c) no dead trees need to be toted around or placed on a real bookshelf

The one drawback to this concept is that you need a browser. As geeky as I am, I don’t want to spend all evening in front of a PC after working all day in front of a PC. I want to read in an easy chair, or on the balcony, or in bed, without having to perch a notebook on my knee or on my wife.

Wouldn’t it be great if you could access Safari on a Pocket PC or Smartphone? I’ve been pursuing this dream for a few years on a succession of Windows Mobile devices, but none could make it any further than Safari’s login screen before stumbling over some AJAX trickery. So, I eventually gave up and began picking through the relatively meagre assortment of non-Acrobat ebooks available at sites like Diesel eBooks. (Don’t get me wrong — I’m a fan of Diesel, too, since both their prices and selection are generally better than other eBook sellers that I’m aware of. But it’s not a geek-in-a-candy-store paradise like Safari).

I recently gave the Opera 8.65 for Windows Mobile a try and, to my astonishment, it has finally passed the Safari acid test. It’s slow and it’s cramped, but it works! The speed can be greatly improved by turning off images (which, of course, limits the types of books you can read), and the small screen is only a slight hindrance since Opera does a good job of reformatting the text so that you don’t have to scroll horizontally. Copy and paste work fine.

Having more or less reached paradise I have, of course, turned my attention to where the next gadget could take me. Wouldn’t it be great if you could read graphics-rich books on Safari on a mobile device? And about those Acrobat documents: even without Adobe’s newfangled DRM most Acrobat ebooks are cumbersome on a Pocket PC because the available readers are all underpowered. My acid test for PDF files is the digital version of Popular Science.

I just bought a Nokia N800, and I’m quite impressed with it as an ebook reader so far. It has passed the Safari acid test, and it has passed (somewhat sluggishly) the Popular Science acid test. But these are still early days for my new best squeeze, and our relationship has had its ups and downs. More on that in a future post.

Until recently, my .Net project had been using a bug tracking system that was, to put it politely, loosely structured. It was basically just an Excel spreadsheet with columns containing the bug description, the coder it was assigned to and the status. Testers would e-mail their bug reports to the coder, and the coder would (in theory) enter the bug into the spreadsheet, then later update the spreadsheet when the bug was fixed.

Clearly, there was plenty of room for improvement. What I needed was a system that
a) allowed screenshots to be included with the bug report,
b) allowed testers to enter the bugs directly, and
c) allowed me to generate reports of open bugs and bug fixes in each new release.

The problem was my time and cost budget available for implementing a better system: both zero.

On a quiet day just before the holidays, I decided to browse through some sites looking (make that desperately searching) for a system that fit our needs and our budget. I was delighted to find several open source bug tracking systems with a large user base and a rich assortment of features, and only one of them ended in “zilla”.

As I contemplated the feasibility of learning MySQL or PHP in an afternoon, I realized that there was another requirement that was important to me:

d) based on a development environment that I knew and loved: .Net

This narrowed the field considerably, and the option which caught my eye was Bugtracker.NET.

BugTracker.NET is an ASP.Net-based system that uses SQL Server as its database. All you need to get it up and running is IIS and a SQL Server database (the Express Edition is fine). And all you need to know to configure and customize it is a little C# and SQL.

I found it dead simple to setup, and our testers have taken to it with virtually no training. It allows screenshots to be attached, and displayed in the browser page inline. It has a very intuitive interface for generating lists of bugs based on pretty much any criteria, and the list can then be exported to Excel for further refinement. Adding custom fields to the bug entry form can be done without any coding, and customizing the form to remove unused fields is just a matter of editing as .aspx file.

It has one other feature that I didn’t think I needed, but would now hate to go without. Point it to an SMTP server, and it can generate e-mails to notify coders and testers that a bug has been assigned to them.

Bugtracker.NET turned out to be one of the simplest development tools to install and use that I’ve ever come across. Just plug it in and it works. That’s a goal that all of us developers should aim for.

Quick quiz: what glorious work of art was released on 08/01/09? Answer: this blog entry.

If you are in North America, and reading this sometime before Aug 1 2009 (US) or Jan 8 2009 (Canada), you might wonder what kind of stupid answer that is. (You might be wondering that anyway). Doesn’t that date just look wrong?

If you’re a programmer you’ve probably got my point by now. One of the most common causes of date conversion errors, and time conversion errors, and currency conversion errors, are “funny” regional settings. Back in the day, we used to have the luxury of decreeing that our programs would use such-and-such a format, and expect users to toe the line. After all, our programs weren’t mind readers — how could they be expected to know what the user was thinking when they entered “08/01/09″, unless we told them what to think.

Most modern programming frameworks have a more liberal approach. They grab date, time and currency formats from the operating system, then automatically apply them to strings that are being parsed until told otherwise. In theory, our code shouldn’t have to tell it otherwise very often, and us programmers just have to remember to stop hard-coding things like date formats and time separators and get them from the framework instead.

For example, we have a data entry program that allows the user to enter a time as just the hours: for example 15 for 3 PM. To check if the user has entered minutes, we don’t parse the string for “:”; instead, we get the time separator from the .Net Framework:

System.Globalization.CultureInfo cult =
System.Threading.Thread.CurrentThread.CurrentCulture;
return cult.DateTimeFormat.TimeSeparator;

I’m currently having to deal with 2 good arguments for hard-coding formats instead. The first is when you have to pass the data to a legacy system which handles date formats the “old school” way: by decree. Our Universe Basic APIs expect dates to be in “dd MMM yy” format, or sometimes “mm/dd”. That one’s not a big deal coding-wise, since the .Net ToString method accepts a format string:

return datDate.ToString(“dd MMM yyyy”);

The second argument is not so easily dealt with. The users of our .Net application are also users of our legacy application. We have beat them into submission to our hard-coded date, time and currency formats, so what is an eclectic French user going to enter when they see a .Net date input field. 08/01/09? Je pense que non. By habit, they’ll enter 09 JAN 08, or maybe 01/09.

So, do we hard-code our date parsing formats to match tradition, or loosen the shackles and allow them to enter dates the “right way”? I’ve gone with the latter approach, but it will turn out to be the “wrong way” if it results in a lot of incorrect dates entering the system.

I’ve been enjoying the ability to spend some quality time over the holidays with my gadgetry (and, I suppose, my family).

Among the gadgets that I dusted off and played around with was my GP2X and breakout board. The GP2X is a handheld Linux based device, primarily aimed at Linux hackers and gamers but also quite good as a video and MP3 player. The breakout board is an add-on which provides TV out, audio out, and USB host capabilities. Plug it into your TV, insert a keyboard and USB hard drive, and you have something pretty close to a Linux based PC.

(Incidentally, back in the day when the greenback was strong and the GP2X was considered the Yugo of the handheld world, I would have said a “dirt cheap Linux PC”. This Engadget article from the summer of 2006 prices the breakout board at US$46. Now, the breakout board is US$75, and the new version of the GP2X is US$250. On the other hand, both the handheld and board have been given hardware upgrades, so you’re getting more of a Kia than a Yugo).

While most aspects of the breakout board require nothing more than plugging in the cables, I had a problem with the TV-out. The board only supports S-Video, and my aging TV only has RCA jacks. Converter cables exist, but at a price that offends my do-it-yourself sensibilities. Fortunately, it isn’t hard to find DIY solutions to this problem, and I went with the one described here.

The solution involves splicing together an S-Video and RCA cable, along with 1 small capacitor. One of the nice things about analog video (especially when combined with a Yugo-quality TV-out source) is that you can do this kind of splicing fearlessly, since all of parts involved can be found for $1 or less.

I’m a software guy, not hardware, so the approach I took is undoubtedly not the optimal one. But the steps I followed were:

1) The above web page shows the pin out of the S-video connector, but I wanted to avoid working within the narrow confines of the connector plug. So, before lopping off the connector, I needed to confirm which of the inner cables were connected to which pins. When I slit open the outer cover of the S-video cable, I saw that the inner cables had four colours: red, orange, brown and black. The web page pinout shows that 2 of these are ground and 2 are video. It seemed reasonable to assume that the black and brown were ground, and the other 2 video, but which was which?

Half an hour of Googling convinced me that there isn’t a standard for such things, so I had to get my answer the hard way, by tunneling into the hard plastic which shields the connector. As it turns out, red is luminance (Y), orange is crominance (C), black is Y-ground and brown is C-ground. Naturally your cable’s colour scheme may differ, but hopefully you’re either a good guesser or a good tunneler.

2) Chop off one of the S-video cable connectors (leaving a male plug at the other end), then strip off a couple of centimeters of the outer rubber. Carefully strip off about 1 centimeter from each of the 4 inner cables. The cables were a little 2 thin for my dollar store wire stripper, so I had to score the cable with a box cutter before pulling off the cable. (People who use box cutters for wire stripping probably shouldn’t preface their instructions with the word “carefully”).

3) Twist the brown and black wire together. (Yeah, I know, so who cares which ground is crominance and which is luminance? But a little scientific exploration never hurt anyone.)

4) Here’s where the capacitor comes in. If you have no idea where to find a capacitor, then go to Radio Shack and pay their ridiculous mark-up. Stop off for some caviar while you’re at it, Mr. Trump. Otherwise, scrounge one from your junkpile, or somebody else’s junkpile. The web page suggests a 470 pF capacitor. I tried a couple of varieties, one 510 and the other 550, with no discernable difference in picture quality. Twist the wire from the orange cable around one leg of the capacitor, and the wire of the red cable around the other. (This type of capacitor isn’t polarized, so it doesn’t matter which leg you choose.

5) Take an RCA cable and snip off one connector, leaving a male plug on the other end. Strip off about 2 centimeters of the outer cable.

6) Unless you have a fancy shmancy gold-plated RCA cable (in which case you probably shouldn’t have picked it for step 5, Mr. Trump), you’ll find one inner cable, probably white, and a bunch of wire strands. The white cable is for the video, and the strands are the ground. Strip a centimeter off the white cable.

7) Twist the wire from the white RCA cable around the same leg of the capacitor that the red S-video cable is connected to. Twist the ground cable around the brown/black joint from step 3.

And you’re done. Plug the S-video connector into your GP2X breakout box, the RCA connector into your TV, select TV-out in the GP2X’s Settings menu, and you should have a glorious colour GP2X menu on your TV, full of crominance and luminance.

Assuming you want your cable to keep working if someone happens to trip over it, or breathe on it, you’ll need to strengthen the connections you just made. I suppose that electrical tape is better than nothing, but using a soldering iron would be advisable. I’m no whiz with the iron, but even I was able to solder these connections without doing any damage to the cable or myself. I added some heat shrink tubing to prevent shorting and for, ahem, aesthetics, resulting in the glorious wonder of electrical workmanship that you see to the left.

While on the subject of the GP2X, I made another discovery recently — nothing new to the GP2X, but new to me.

The GP2X’s built-in video player, a variant of Linux’s MPlayer handles a good variety of codecs, but with the conspicuous exception of the commonly used AC52 audio codec. It turns out that AC52 support, along with a few other codecs missing from the GP2x’s built-in player (notably .wmv) have been available for some time in the MP2X player, which was built upon the source code released by the GP2X’s makers, Game Park Holdings. MP2X has handled every video and audio format I’ve thrown at it so far.

I also played around with MP2X’s support for subtitles (i.e. captioning). Support for SMI sub-titles is nice and simple: just give the .smi file the same name as the corresponding .avi file. If you already have some .avi files without captions and have no idea how to extract captions from the DVD (or are a shameless pirating scofflaw), you can download just the caption files here.

My wife’s PC occasionally (about once every 3 months) stops playing nice with the other PCs in my house, rejecting file sharing and print requests with an error message ” No more connections can be made to this remote computer at this time because there are already as many connections as the computer can accept.”

The first time I saw this error I was perplexed and somewhat alarmed. XP Home is supposed to have a hard-coded limit of 5 connections, and we don’t have that many PCs in our household. With visions of a horde of hackers (well, a horde of 5 hackers) running amok on the PC, I ran over to pull its network cable, and spent the next hour poring through the Event Viewer and Firewall logs for some indication of how these intruders had broke in. The Event Viewer just had its usual list of generally mundane and often incomprehensible messages. (“The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer.” Good to know!) No viruses reared their ugly heads, and no files proved to be missing or changed. Looks like an inside job, sarge.
Although I usually scoff at those who blame Microsoft bugs for every problem they encounter on their PCs, I’ve come to regard this message as nothing more than a gradual build-up of crud in the Windows connection sharing code. My wife’s PC is used for both printer and MP3 sharing, so connections are frequent and, in a wireless household, sometimes dropped.

Fortunately, there is a quick fix to the problem (assuming you have a way of getting at the PC): just restart the networking stack. The quickest way to do that is to right-click on the system tray icon for your connection and select Repair. If you don’t have a system tray icon, select Control Panel, then Network Connections, and right-click on the item for your network. The “repair” process takes a few seconds, no reboot necessary, and all queued print requests should immediately start printing.
If you Google the error message, you’ll find a lot of theories on the root cause of this error, but none of them seemed to apply to my situation. Perhaps XP SP3 will fix this one, but if not I’ll just keep taking the easy way out.