Here’s a quick cheatsheet for svn stat codes, as I can never find a good one when I need it.¹

    U        Local file updated
    G        Local file safely merged
    M        Local file has been modified, needs to be checked in
    C        Local file contains conflicts that need to be resolved
    ?        Local file not in repository
    !        File missing from local copy
    A        Local file scheduled to be added
    A+       Local file scheduled to be moved
    D        Local file scheduled to be deleted
    L        Local file is locked by a running svn command

1. Note: this is a just a summary of the much better detailed svn help stat. The one some most of my developers are unaware of. ↩

One of the projects I’m working on this year is an interactive fiction engine built in a wiki interface. The game engine uses a markup similar to wikitext, with a helpful UI to simplify building world elements. The player interface is a webified version of a z code type of game, supporting MUD features for authors who want it.

The game editor

A SVG mock-up for “thwarter”

1. The main location editor. A location is a wiki page with a bunch of state attached to it. In the mockup example, you’re looking at “The Meadow,” in its “Chapter 1″ state. The text is like wikitext, allowing you to tag other areas, objects, and so on as you write. The approach differs from zcode, allowing you to write the story parts first (and worry about connecting the programming parts later).
2. The object editor pulls meta data from the wiki page (and things you add directly), allowing you to edit their properties. All concepts in the games are objects like this, including NPCs, things, paths, and game event triggers.
3. The object editor tabs show each kind of world element.
4. The location timeline for each location shows the story states. State can be used for description of an area over time or other story variants like branches, portals, and so on. Each area can have an unlimited number of these states, allowing the author to write all of the story for one area in a single interface. World objects can have a timeline too (not shown here).

The art of prototype

I use Inkscape to mock-up user interfaces. It’s a good starting place as it’s quick, vector-based, and it uses text (SVG plays nice with Subversion). I sketch the interfaces directly in Inkscape now, skipping paper prototypes for everything but the earliest concept sketches. I sometimes take the vector drawings to completion too, polishing them, and dissecting them later with the Gimp for HTML templates.

Notice that the editor mockup has no icons or colours. It’s a habit I’ve developed over the years, limiting my thinking in terms of highlights instead of worrying about the details. I get bogged down with details early on, so I have to force myself to sideline the distractions until later. I limit mock-ups to 10-20 minutes too, to avoid getting sucked in to trying to perfect ideas early. The time for polish comes later, after I can prove the utility in the approach.

Prototyping

I am also careful while building the prototype not to get too lost in the details. The purpose is to test the viability of the interface and the initial approach. So far, I’ve discovered that I need to be able to parse the wikitext in both client and server, as well as parsing the NL text from the game interface on the server. I’m considering externalizing the parsing rules (via regex or similar) so it can be shared between Javascript and PHP, so I can provide a rich UI and storage. This complexity is a good discovery to make in the prototyping stage, as it gives me lots of time to consider alternative–and hopefully simpler–approaches.

Another test of the prototype is to see if CodeIgniter is a good fit. I’ve been pleasantly surprised so far, and have found it an extremely comfortable framework. I’m also looking at hosting needs (AWS, Slicehost, Dreamhost), considering how DNS and DB partitioning will work, and what sorts of load might be put on the system. Some of this thinking is early, so I have to try not to get stuck in it.

Level up

Next up, I’m going to start to prototype the game play interface and expand the schema. The game implies a great deal of state, something that I want to be careful to contain simply. I’m siding on partitioning the games in their own databases (or tables), especially for the live game states. A live game will have large multipliers of the number of locations, their states, by the number players and their time in the game so far. At a small scale it won’t matter, but thousands of players multiplied by hundreds of locations (and dozens of states each, dozens of variables per state) becomes a large persistent data problem.¹

1. And there I am again shearing the Yak ↩

I started using Zip.ca last month, a Canadian by-mail DVD rental service. I did my homework, it was recommended by a trusty co-worker, and am really happy with the service so far.

What I like

• They have a huge selection of foreign films, festival films, documentaries, obscure films, animé/manga, and TV shows.
• You queue up what you want to watch, and the discs arrive a few at a time.
• You can tell them when you’ve returned a disc, and they’ll send you another one while it’s in transit.

What could be better

• Movies arrive in pretty much any order, in a fairly random distribution of genres. I have some ideas on how to improve this, and I’m told they respond well to user recommendations.
• The site is far from web2.0 and is a bit slow at times. Once I got used to the site, I found it worked well enough for me … it just wasn’t inspiring.
• The recommendation system is pretty tame, and the per-movie content a bit thin. I realize that a Canadian service has a pretty small customer base compared to an Amazon or a Netflix, but there’s room for improvement.

Stats so far …

• I’m receiving 4 DVDs per week¹
• Average delivery time (to or from) is 1.25 days
• Cost per DVD: $1.17²
• Great movies so far: 8
• So-so movies so far: 3
• Crappy movies so far: 1

Survey says …

I’ll stick with Zip until the summer, then will pause or reduce it until the fall. Zip has great value if you don’t have to see the newest thing the moment it’s released³, so it fits my personality well. I’m excited about the large selection of hard-to-find stuff, though I haven’t received much of it yet.

The best part? Not having to wander around the video store like an idiot: I can research directors, writers and actors, queue up movies at my leisure, and the movies magically appear on my desk a few days later.

1. I watch them while coding in the evenings ↩
2. 3/Unlimited plan, 3 months with 1-free month promo ↩
3. They have an option for getting a movie “now”, but it costs more ↩

I’m tired of wrapper libraries. They’re a cognitive consumerism gone awry, wrappers for wrappers wrapping wrappers. Every development team I’ve known has their own¹, each somehow better than the others, most ignoring the long history of thinking gone into libraries written throughout computing history.

What’s wrong with using the basic standard libraries, ported where they don’t exist? I mean, really, why do we need another date class, or another wrapper on file paths?² Are you or your development team so challenged that you can’t reliably use fopen or fprintf? Is your own brew of file.Open() more reliable than, say, C#’s, Java’s, Perl’s, the STL’s (or whatever toolchain you’re immersed in)?

I’ve heard the excuse that standard libraries fall short in some way: maybe they’re not available for a required platform, or maybe they’re missing a key set of functions. Then port the libraries (there are enough free implementations out there), or add a companion library, class, or unit. It’s really not that difficult. Re-wrapping the entire damned universe should be left to the crazies with their tin-foil hats and couches covered in plastic. And the standard libraries aren’t so bad that you need to be protected from them. In fact, they’re pretty damned good, once you’re willing to get over your own ego.

I think that teams are looking at the problem of abstraction the wrong way. Wrapping concepts in your product’s domain is a good thing (as long as you don’t overdo it). But where’s the value in wrapping things that have thousands of existing implementations? Why repeat what’s been thought, built, and tested thousands of times over? Just learn the fucking standards, understand that they’re imperfect, and make peace with the fact that they don’t fit your personal mental model of things. Assume that where your mental model differs that it’s wrong or unimportant, because it probably is.

And if you’re not willing to use the standards, at least use the de facto libraries for the platform. If you’re targeting Windows prefer the Posix libraries³, then default Win32 libraries for your toolkit, and as a fallback, any absurdly popular library that has a vibrant community. The same goes for whatever platform you’re on. But if you’re tempted to write your own basic-concept-wrappers, in your own brand of library magic, then you’re full of shit. Get over it: you’re not that good. None of us are.

That’s why we share standards. That’s why out of thousands of class libraries, only a few bubble to the top. Only one or two of them are good enough to be worth using. Spend your time on problems related to your application, on the things that your users will actually care about.

1. And yes, I’ve fallen to this bug myself in decades past ↩
2. Companions to the standard libraries are good, as long as they don’t repeat what’s already available ↩
3. Because it’s the right thing to do ↩

I borrowed a serial UPC scanner from work today for some Friday night hacking. It’s a ReaderWare LaserChamp/Flic Barcode reader re-branded under the SerialIO name. It came with a standard serial cable and didn’t have a manual.

First, I booted to my Ubuntu partition to see the raw data from the scanner.

$ cat /dev/ttyS0

No dice. I did some searching and found that the scanner likely ran at 4800 baud.

$ setserial /dev/ttyS0 baud_base 4800
$ cat /dev/ttyS0

^B043396143234

Ah, some data. I removed the control characters and had myself a UPC symbol. I wrote a script and scanned a bunch of books, CDs, and other crap sitting on my desk. I also found a manual for the scanner, which had some settings symbols¹.

I booted to my XP partition and started Cygwin. I wrote a Perl script to mimic what I did on Linux, except using the Win32::Serial module. I fired up CPAN to grab the library, but CPAN was down. I switched to ActiveState’s Perl distribution and grabbed their Win32:: PPM. I finished the script and tested it. It worked.

A while later I checked CPAN again, grabbing the Win32:: module using Cygwin’s Perl. It didn’t build. This seems typical for Cygwin and CPAN/Perl modules². I moved on.

I switched to C# to see how it compared to Perl and the Linux/Bash hack. I whipped together a simple application³ that listened for data on a serial port, cleaned it up, and copied it to the clipboard. It worked⁴.

I also attempted to hook the C# code up to the Amazon API (to get ASINs), but found the networking libraries more complicated than I had time for⁵.

My favorite approach? Hands down, I liked the Bash script⁶ best. It was one line of code, including cleaning it up with sed. It’s not something I can ship, but it’s the way I’ll scan all of my books/CDs/DVDs.

The Perl Win32::Serial hack was longer (a dozen lines), but it also worked. It was no better than the 1-line Bash script, so I tossed it.

The C# hack consisted of a single form and its supporting class (a few dozen lines of code). It worked, and is easy to distribute. I’ll use this if I’m stuck doing something in Windows.

Total time for all 3 hacks? 3 hours and 25 minutes⁷.

1. You print the page and scan the symbols to change the scanner’s settings ↩
2. Most of the tests failed for the Win32::Serial module ↩
3. And the .NET build of it ↩
4. C#’s serial code was nicer than Perl’s, but not as nice as the devfs hack ↩
5. Perl’s networking is much nicer than C#’s ↩
6. Bash and devfs’s /dev/ttyS0 ↩
7. My wife and kids were out for the evening ↩

As a follow-up to last year’s top10 list of things Linux does well, I figured I should write about what the Windows platform does right.

And as I’ve said before, I’ve been developing software for Windows and *nix on a daily basis for more than a decade. I’ve also used OSX (and earlier), WinCE, PalmOS, and many other operating systems. Each system has things that work well, and each has things that will suck the life out of you. Looking at the differences is a great way to learn about what works and what doesn’t.

Note to Digg readers: Windows succeeds as a platform because it’s everywhere, and it’s easy to build software for, something that’s only possible due to their great vendor support (and chair-fueled monopoly). And while Linux vendor support has improved vastly in the last 10 years, it is still no match for the base Microsoft has built. So what? Linux will get there (and it’s my home platform), it’s just not there yet.

What do I think Microsoft Windows does well?

1. Snappy application startup and windowing. I dual boot most of my systems, and on equal systems (with reasonably optimized packages) Windows beats Linux hands-down in general snappiness (outside of older tools like vim). Recent Linux distributions have improved a lot, but they still lag in snap (especially startup times, window resizing, etc.). This goes for both KDE and Gnome applications. My definitive test? Firefox on both platforms: 250ms on WindowsXP, 1.5s on Ubuntu 6.10. This is partly a Gnome problem, partly an XFree problem, and partly a gcc problem. And if you haven’t noticed the difference, try measuring it yourself.
2. 3d and wireless drivers. Hands down, most hardware vendors support Windows best. Linux still wins with most of the tangent hardware (printers, scanners, nics, etc.), but it tends to fall on itself with the proprietary mess of new-fangled 3d, capture, and wireless hardware. Some vendors like NVidia have improved their Linux support greatly (and I actually prefer NVidia’s newer XFree driver package over their Windows package), but in terms of support and performance, Windows XP’s vendor support has Linux beat.
3. Stable ABI and APIs. While the Win32 APIs are a mess, they are binary stable. The nature of Gnu and OSS prefer source-stable APIs (which is also good). Binary compatibility, though, is handy for writing commercial software. Yes, commercial software can be written for Linux, but it makes more sense to release sources on Linux than to aim for widely-compatible binaries.
4. Games. I’m not a PC gamer, but if I was XP (or 2k) would be the place to do it. Personally, I prefer my hand-held and console games.
5. Specialty applications. Software development of nearly any specialty software is still cornered in the Windows market. We’ll all be happy when these vendors start supporting Mac, Linux, and web platforms, but that’s still years off. Until then, most people need to keep a Windows machine around. It’s not that custom Linux applications aren’t possible, it’s just that they’re so pervasive in the Windows world: every shop I’ve consulted at has a handful of custom applications that are Windows-only, and no longer maintained. This makes it very difficult for businesses to consider switching away from Windows.
6. Browser plugins. Flash, for example, even on the newest Linux distros will stop working after a few months of updates (or may not work at all for some architectures). This is especially annoying now that Flash is actually useful, as sites like uTube and Google video use it to package video online. To contrast, I’ve never seen plugins stop working in IE or FireFox on Windows. Flash on Linux has lagged behind the other platforms too, and is not available for 64bit builds of Firefox.

I’ve been working on a handful of web apps in my spare time. Nothing amazing, nothing revolutionary, just simple, fun tools. And while I’ve shown off a few of the logos, I haven’t written about the applications or their design. I’m not sure if I hate giving up the ideas (as if ideas were golden), or if I’m wary of not finishing them (free time is a commodity, and new ideas hit me regularly).

Well, fuck that. I need to write more. The lack of writing is a sign that work is getting under my skin, or that I’m getting lazy, complacent with life in zombie land. Zombie life sucks: it’s undisciplined and it’s uninteresting: far from my normal inspiration. And inspiration is fun.

Thwarter

One of my most tangent projects is for a Z-machine replacement of sorts. It’s working out to be a text-adventure tool that obsesses over making writing the games about the writing (and playing the games about reading). Infocom’s Z-machine was fun, but it wasn’t a writing tool (it was a programming language). Confusing the two limits both who becomes authors, and how much writing they do. And including the potential for multiple players (and/or authors) makes it damn-near freakin’ cool.

I’ve completed the “language” design for this one (it’s all table-based, edited like a wiki), and have a few basic prototypes done. This weekend I moved on to the UI design, something that I’ve been doing in Inkscape and the Gimp (an incredible pair of tools). The next step is to settle on a first approach and grind my way to a working demo. I have an unfortunate fixed-deadline work project this summer, which will likely eat into my spare time, so I don’t expect to have a useful prototype done until the late fall at best.

Elsewhere

I’m in the midst of a few other projects, interleaved with life, work, and art. I have a simple TODO tool in the oven, to tame my never ending stream of ideas, and a number of other things at varying stages of completion.

I’m learning to cull my growing queue of ideas too. Part of the trick is to let things percolate for a while, and see if they stick to the mental wall of, well, stickiness. Good ideas keep coming back to you, and the rest just evaporate by themselves. There are other heuristics too, but that’s a topic for another post.

Free domains!

Speaking of culling, my domain portfolio needs some cleanup. I’m giving away the following domains to a good home (for non-profit use), or for a reasonable fee (for non-evil commercial interests):

• aggregatorator.com
• cheatsheetbuilder.com
• sixwords.org
• gr8tr.com
• feedr8r.com
• gatorator.com
• justaskoldguy.com
• cookbookr.com

One per person; first come, first served (friends first); highest bidder, and so on.

I’ve heard a few people wonder how Apple ported Webkit to Windows, so I cracked open depends.exe and took a look at what Safari was linking to. A few of the more interesting dependencies:

• Webkit (via CoreGraphics)
• CoreFoundation (and CF-Net)
• PThreads
• MSVCP8 (interesting to see them use MSVC SP2)
• SQLite3

So it’s not based on QT, and it doesn’t seem to match the iTunes set (which has no Core* dependencies). Looks a lot like a straight port of some of the base Cocoa libraries.

(click to enlarge)I did a quick survey of what people were reading on the site this month, and the results were surprising:

RSS (75% of my readers)

1. 97% of RSS readers dug Cygwin + Putty
2. 27% of RSS readers followed The programmer’s three virtues (the only quote-of-the-week above 1%)
3. 14% of RSS readers hit How much sleep is healthy on Win32?

Direct viewers (25% of all readers)

1. 25% of traffic hit my Markdown cheatsheet (50% referred from Wikipedia)
2. 20% were looking for my Calling Perl from PHP article
3. 10% of visitors read my Tweaking Ubuntu guide
4. 10% of readers wandered through my tongue-in-cheek Top 10 things Linux distros get right that Microsoft doesn’t fluff piece
5. 9% of people hit my 2 week old Flash games for kids page

Top keywords

1. 65% of all searchers were looking for “howto make ice coffee”
2. 25% of searches asked about “tuning ubuntu”

Browser/OS/Screen size

1. 60% Firefox (20% Linux)
2. 25% IE
3. 10% Safari (Mac)
4. And only 2% of readers had a 800×600 or smaller display

The moral of the story

RSS is king, based on my mostly geek readership. Writing fluff for Digg is less useful than writing useful cheat sheets and guides. Links that solve/discuss really annoying technical problems get the most clicks.

I was especially surprised at how few people were interested in Ruby or Rails, and how a page of flash games I made for my kids could get thousands of hits in a matter of weeks.

(All statistics represent unique views, and exclude traffic from my own IPs.)

Taking pictures is fun. It’s an ego trip. Armed with a camera, anyone can slice the world into tiny planes of expression. Photography can be art, history, science, or just plain interesting. But how can you escape the mundane?

The inspiration for this HOWTO came from a friend who reminded me that the greats of photography worked with primitive equipment, and that even the simple cameraphone was enough to create art. So I grabbed my camera phone and took some very average shots. I then I applied a few simple tweaks using the Gimp, and the results were surprising. In the end, good photography is more than just equipment and light.

It turns out that the process is really quite simple:

1. Shoot. Get closer. Try different angles, and take several shots.
2. Crop. Rotate. Find the interestingness.
3. Blur the image and reduce the camera noise (unless it looks cool).
4. Adjust the levels.
5. Fit the contrast to the texture of the image. Higher contrast for crispy, lower for fluffy.
6. Nudge the colours. Try different tones and saturations.
7. If the colours are really horrid (or the image is still noisy), drop to black-and-white.