After my flash of insight I’ve decided to build a tool to help me migrate apocryph.org away from drupal.

Requirements are:

• Work with my Drupal configuration
• Not so tightly coupled to my Drupal configuration that no one else can use it
• Output posts in a neutral format that users can post-process and import into other tools
• Preserve all the important elements of each post, including:
  • Formatting. Most posts are in Markdown, and a few are in SmartyPants. Those must be converted to XHTML using the same rules which generate the markup in Drupal
  • Files. A few of my posts have files attached, usually images but sometimes other stuff. Those files must be preserved themselves, and any references to the files from within a post (like IMG or A elements) must be preserved as well
  • Metadata. The tags, author, timestamp, published/unpublished flags must be preserved
  • Links.

A while back I thought it would be a good idea to implement face detection in Gallery2, based on a similar feature in Facebook. I downloaded the OpenCV computer vision toolkit and ran the facedetect sample app against a collection of 60 photos from my gallery, some with no faces, others with a single face, still others with multiple faces, faces in profile, etc. No matter which training file I used, the face detection was horribly unreliable.

This past weekend my little sister and I were going through the Facebook profiles of various cousins, and I noticed something about Facebook’s photo support that I somehow missed before: it automatically detects the presence of faces in each photo, and allows users to tag each face with the identity of its owner. Already-tagged faces have the owner’s name superimposed over the image.

As soon as I got my Nokia N810 Internet Tablet, I set up the WLAN and configured the built-in chat application to use my Google Apps for Domains GTalk accounts. Chatting on the slide-out keyboard from the comfort of a TV chair or couch was immediately sweet, and the automatic conversation archiving still allows me to go back and look at transcripts.

Earlier today I was ranting about lack of built-in support for grayed-out image buttons in WPF. I’ve come up with two workarounds; one correct, and one workable.

This weekend I’ve been working on one of my many self-edification projects, and against my better judgment I was implementing it with .NET 3.0/Windows Presentation Foundation, mainly because of the markup-like UI model which fit nicely with a few of my project’s idioms.

Right on schedule, about once every quarter I feel the need to build an ubertool to capture, organize, present, and share all the information I keep around me, structured and unstructured, textual, audio, visual, etc. Each time it takes a different form, and each time I end up going nowhere with it, but I write it down nonetheless.

Now that I’m getting a laptop again, I’ll face a situation I dealt with a few years ago: one or more external hard drives at fixed locations, with a laptop on the move. I want to take advantage of this extra storage when I’m at home or at work, but on the road when it’s not there I still want access to my important files.

Three years ago I had a firewire hard drive that I just carried around, and manually copied files onto my laptop hard drive if I needed them. Now, time has marched on and there’s a better option: high-end eSATA drives running off a fast ExpressCard34 bus.

Lately I’ve been playing with wireless network monitoring, using kismet. Kismet produces dumps of all wireless traffic in libpcap-compatible packet captures, which is the same format used by Wireshark, tcpdump, and any other packet capture tool worth its salt.

The problem is that after a week of capturing, I have several gigabytes of capture files, though most of the captured packets are 802.11 beacons that have no information in them. Wireshark eats shit and dies on a 500MB capture file, so a 2GB one is out of the question.

My recent investigations into Win32 socket performance led me to a few performance measuring tools, like iperf and netperf. However, in my case I wanted some extra features:

• Use of Win32 IO completion ports for disk and network IO
• Use of Win32 TransmitFile/TransmitPackets high-performance socket routines
• Benchmarking of disk read/write performance as a part of overall throughput

So, yesterday I threw together a quick-and-dirty test harness to exercise these features. The code isn’t written for maintainability or readability; the point was to get something out quick which I could use to explore the performance landscape.

The sources are in my svn repository, and I’ve attached a source and Win32 binary tarball based on a snapshot of the code today.

The code requires a client and a server at each end.