A great introduction to reverse engineering Win32 applications, including a tutorial on hacking the built in Mine Sweeper game.

I’ve come up with a simple rule-of-thumb for cropping group pictures: Center heads horizontally, so that the left and rightmost people are the same distance from the edges of the shot. Don’t worry about torsos and legs, focus on the heads. Vertically, aim for the rule of thirds.

Google launches a web reference/encyclopedia called Doctype, under an open license, with collaborative editing. The site includes, for example, compatibility charts for popular browsers for every point of reference, and a good selection of HOWTO articles.

After working with CodeIgniter for a few months (and WordPress for a few years), I’ve settled on a way to set up web projects that works well for development, deployment, and source control. The layout only works on systems like Mac and Linux that have useful symlinks, though.¹

First, the folder layout

some-domain.com/
    app/
    public/
        .htaccess           -> ../site-extras/.htaccess
        favicon.ico         -> ../site-extras/favicon.ico
         js/                -> ../site-extras/js
         images/            -> ../site-extras/images
        system/
            application/    -> ../../app/
    site-extras/
         js/
         images/
        .htaccess

The layout favours a vhost setup, and splits your code and resources out of the CodeIgniter sources. Splitting your stuff from the CodeIgniter stuff lets you link your Subversion repository to theirs, so that you can keep it in sync with their development.

How it’s done

1. Set up your source tree (not including the symlinks or CodeIgniter source) and add to your Subversion repo.
2. Add a svn link to CodeIgniter’s repo (via svn propedit svn:externals, with public http://dev.ellislab.com/svn/CodeIgniter/tags/v1.6.2/) and run a svn update to grab the framework. See the Subversion docs for details.
3. Copy the CI application folder to the site root (as app), remove the .svn folders, symlink to application, and add it to your svn repo.
4. Symlink the other site-extras to the public webserver root, and configure your local machine (and public webserver) to point to this root for the domain’s virtual host setup.
5. Alternatively, you can modify the $application_path to point to ../public/app/ (I’m not sure which is better yet). See the CodeIgniter docs on apps for more details.

You now have a CodeIgnitor project ready for development. You can keep up-to-date with CodeIgniter updates, deploy easily, and get at your code without wading through extra levels of hierarchy.

1. I don’t think that Windows is suited for PHP/MySQL/Apache development anyway, as it’s more work to configure, harder to get packages for, and lacks things like SSH, symlinks, and useful shells. But that’s me. ↩

A few good tips on writing daemons in Python, including a Python example of the double-fork console detachment method.

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.

A great HOWTO on hacking your camera. The coolest thing is that there are alternative operating systems for many common SLR digital cameras.

A thorough introduction to the craft of text adventures. In good old ASCII too.

Random wiki page of the week: Sakichi Toyoda’s 5 Whys, a simple method of solving problems by looking for the root cause.¹

1. The principle applies directly to software development and troubleshooting. ↩

I’m a big fan of code generation. It fills the two basic needs of every good programmer, to maximize laziness, and to extend one’s own hubris. That, and it makes DRY possible.

Hooking code generation into a build system is trivial on most platforms, but Visual Studio presents a few unique problems: namely a poorly documented (but feature-rich) custom build system. Not only can the build system can be tamed, but you can do some cool stuff with it.

Here are a few of the things I’ve learned while using it:

• Don’t configure code generation in the pre/post build steps (seems the obvious place, but it doesn’t handle dependencies/changes)
• Calling Cygwin/Perl scripts is possible, but you’ll need to thunk them with a batch file to proxy build environment paths usefully¹ (helps prevent brittle paths)
• Add code generation tools as source files, and set them as a custom build tool via their properties dialog²
• Set the custom tool’s file dependencies (and command line) in the same properties dialog (under Custom build step - General)
• From your code generation script, you can emit errors, warnings, and info messages to STDERR that the Visual Studio can understand and display in its rich error/warning/info viewer (just follow the same formatting as the C/C++ compiler)
• To stop a build on errors, you can either emit error messages or you can return a non-zero value from your script

Most of my code-gen scripts are written in Perl as simple sed-style scripts. They’re unixy in the sense that they mash a few scripts together (cat $file | script.pl > $file2), and are easy to maintain and test. Python/Ruby/Sed would work just as well, given a reasonable Cygwin install.³.

1. Thanks Steve ↩
2. Another great find by Steve ↩
3. Note that the “E” text editor includes a full Cygwin environment ↩