A taxonomy of programmers describes what various levels of programmers are capable of. The paper was written with procedural programming in mind, but most of it is relevant to newer languages.

Praising companies for providing APIs to get your own data out is like praising auto companies for not filling your airbags with gravel. I’m not saying data export isn’t important, it’s just aiming kinda low. You mean when I give you data, you’ll give it back to me? People who think this is the pinnacle of freedom aren’t really worth listening to. –DiveIntoMark

Boost’s Filesystem library is an incredible library: it abstracts paths, directories, and stat results. It simplifies coding shell problems in C++, it’s portable, and is maintained by a large community of contributors. The one downside of Boost is that some of its newer libraries are poorly documented.¹ Until I have time to get involved in the Boost project, I’m going to post examples here.

Traversing a directory tree

This is the coolest feature I’ve found in boost::filesystem so far. It treats directory elements like iterators, and has a convenience iterator that flattens the problem of iterating through a directory tree recursively. The only examples I found for it were in their extensive test sources,² which are a bit light on comments.

#include "boost/filesystem.hpp"
#include <iostream>

for ( boost::filesystem::recursive_directory_iterator end, dir("./"); 
       dir != end; ++dir ) {
       cout << *dir << std::endl;                                    
}

The example starts in the current working directory, and prints all of the file names (and directories) in inode order.³

Notes:

1. I don’t alias the namespace here (but I recommend doing so in production code, see below)
2. Creating an instance of recursive_directory_iterator sets it to the .end() element by default.
3. The path type supports all standard string paths, including relative paths.

Aliasing Boost namespaces

Here’s how Boost’s own source recommends aliasing their namespaces:

namespace fs = boost::filesystem;
namespace sys = boost::system;

Other cool bits

I’ll write more about these later, but for now here are a few things you’ll find in the library:

• fs::exists( boost_root / "libs" ), a static function to check if a file exists (-e)
• fs::current_path() that returns the application’s cwd
• fs::create_directories( "xx/yy/zz" ) is equivalent to mkdir -p xx/yy/zz
• fs::is_directory( "xx" ) is the same as Perl/*sh’s -d
• fs::change_extension("a.txt", ".tex") does the obvious
• fs::extension("a/b.txt") == "txt" is used to check file extensions
• fs::remove_all( "x/" ); deletes everything in "x/"
• ifstream file2( arg_path / "foo" / "bar" ); shows the overloaded / operator!

Things that are great about boost::filesystem’s approach:

• Static functions are used for ‘helper’ stuff. Take note C++ devs: this is a great balance for types, it keeps the types noise-free while still providing a great deal of utility.
• It mirrors Perl/*sh functionality, something most developers should know well.
• It throws errors (filesystem_error), allowing for some really clean, transactional code.
• And, it abstracts paths that work on Win32, OSX, Unix, and Linux variants.

1. Something I want to contribute to. ↩
2. See convenience tests and operations tests for more examples. ↩
3. Later I’ll try to post an example that uses the stat features to dump extra information. ↩

JSDocToolkit is a tool like Doxygen for Javascript.

Ten reasons SimpleDB is over-hyped. I’ve been arguing some of the same points myself: losing the expressiveness of SQL (especially for aggregates) and the ease of developing with SQL is a huge factor to consider.

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. –Martin Golding

Some random Sunday fun: a live Pong game where you can enable/disable the lines of code driving it. Fun for at least a few minutes.

An introduction to the Boost filesystem library, from the IBM developerworks archive.

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 ↩

There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. –C.A.R. Hoare