What’s the best thing about your favorite operating / windowing system? What’s the best thing about your least favorite system? I was thinking about it this morning, considering the most inspirational design in each of the systems I’ve used. While not every vendor finds that balance of excellence, releasing a functional system is itself a difficult problem.

• Windows XP/Vista: I love how the login/desktop locking system works. It supports multiple users properly, making switching between them trivial.
• Gnu/Linux + xorg + Gnome: multiple desktops + Compiz. It’s a developer’s dream, like a desk the size of a large room. Enough room for a dozen editor windows, without having to navigate a mess of windows or tabs.
• Apple’s OSX: It’s a brilliant looking desktop, with the best font rendering, colour and monitor management (nailing multiple monitor support). It does other things well, but I’m always impressed with its affinity to photo/video/music productivity.
• *nix: I love how the unix philosophy wreaks of pragmatism. It’s simple, decoupled, and completely bent toward scaled production uses.
• Nintendo’s Wii/DS/etc.: In a word, casual. Simple, predictable, and fun to the bone.

So what do you love about the systems you’ve used?

A longish, interesting writeup of a Steve Yegge presentation on server-side Javascript. It’s called Rhino, and is hosted in the JVM (which I don’t think is as bad as it sounds). Yegge comments on the stigmas around the JVM and Javascript itself. He asks the crowd about Javascript:

Who here thinks JavaScript is kind of icky? Come on, come on, be honest. Yeah, there we go, a couple of people. Yeah.

And then jokes about Java:

You need to write unit tests, and unfortunately in Java it’s very painful. I’m speaking into the mic now, so that everybody can hear. Unit testing in Java is painful!

What I like most about the talk is that he’s an open thinker about languages in general, and is willing to look at their respective strengths and weaknesses. It’s a mindset I can respect, where merit is based on good sense.

I agree with the 37Signal way of mocking up web stuff, using HTML/CSS straight-up. It’s fast, it pushes you to know your tools better, and produces layouts that can actually be solved in the medium. There is still a place for Photoshop/Gimp/Illustrator/Inkscape, however, as you still need to explore the look and feel, textures, colours, and shapes.

For my own sites, I use Inkscape sketch out new ideas. It covers most of what a web designer needs, and is freely available. Today’s 10 minutes of mock-up produced a very blue, boxy alternative layout for my blog. I limit myself to 10-20 minutes of sketching, then I put it away for a few days/weeks and look at it compared to other sketches made over the year. When I find something I like, I move on to slice it into a theme.

Today’s sketch:

• Inspired by Eric Wendelin’s excellent blog. I’m thinking of a 1-column version, with the sidebar in the footer, with subtler colours (I’m not sure I can pull off his excellent bright colours).
• Background is 2 layers, one as a background colour, the second as a diagonal texture (pattern-fill, rotated + sized, at 10% opacity)
• The body is another 2 layers, one as the shadow for the second (a 2% layer blur, reduced color level)
• The header is in two parts, one for the text/menu, the second will be some sort of art (hopefully classy vectors, or a high contrast photo)
• The date callouts are a simple box combined with itself rotated (with a second layer for the shadow)
• I’m not sure about the blue, and textured charcoal is a good possibility. The blue was the first colour I picked from my current Inkscape palette (Khaki).

Download the SVG.

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.

I ran into a well-known, but odd IE6 caching bug this week. If caching is turned off for IE6 browsers, modifying DOM elements triggers the browser to reload any resources referenced by the changed elements. So if a script changes the class name of 5 elements and the CSS classes have a background image property, then the background image will be reloaded once for each DOM update. This sucks the performance out of a web application.

There are several work arounds, but the best I’ve found is a simple IE6 Javascipt toggle that turns off the behaviour.

I’ve been meaning to write out my philosophy of software development for a while now. Over the years I’ve watched developers struggle to find solid ground when stuck in design, development, and debugging. They get stuck in what they believe about problems, and the related knowledge that would help them. And when they don’t believe that something can be solved, they make make it harder to find the paths that would get them there.

So if you find yourself swearing at your compiler, computer, or sacrificing chickens to solve difficult problems, then you’re missing a fundamental part of the reality of software: problems are simple once you believe that they are, and once you learn approach them objectively.

The laws (simplified for the impatient)

You (and I) suck. Plan for it. Expect it. Get over it.

It’s a humility thing. Be open to the possibilities, including you’re own fallibility.

The laws (extended mix)

1. Every problem can be solved, and most are solved already. Solid ground exists, it can be found, it has been found, and it’s usually easy to find. If you don’t believe that a difficult problem can be solved, then you’re missing something. Step back and look for possibilities, and test each theory carefully.
2. There aren’t just possibilities, there are many great possibilities. If you can’t see more than one way to approach a problem, then you’re not looking hard enough. If you can’t see any possibilities, then you need to know that you are wrong. There are always possibilities.
3. Software and hardware are deterministic. Have you found a problem that appears to be intermittent or flaky? Relax, you just haven’t discovered the cause or understood the underlying mechanism yet. Focus your tests, and look for a simple, plausible explanation: it’s there. If you think you’ve found something non-deterministic, then expect that you’re wrong and keep looking for answers.
4. It’s your fault, until it isn’t. Have you found a compiler bug, a CPU flaw, or a library issue? You’re probably wrong. It’s not that it doesn’t happen, it just doesn’t happen very often. Be absolutely certain before you’re willing to believe that it’s not your fault. It’s much more likely to misunderstand syntax, usage, side-effects, and such, than it is for well-vetted tools to be broken. If you can’t prove it, then you don’t understand it well enough.
5. Study history, as it’s almost always smarter than you are. There’s a whole universe of thinking that exists outside of your head. Until you realize this, you’re going to bang your head needlessly. Don’t be stupid: look around you, and know that many people are intelligent. If you believe that everyone is an idiot, then you really only know yourself.
6. Your intuition isn’t as good as you think it is. Or as a friend says, “Always, always measure, ” and “Do the arithmetic.” Even when you’re sure that something is true, it’s doesn’t mean anything until it’s proven. Test it. Measure it. And make sure you’re looking at it in isolation of other changes. If you fix it by chance, then you’ve lost a critical piece of learning. Go back and figure out what the underlying truth was, or it will bite you again and again.
7. Your code isn’t as good as you think it is. No, really, it isn’t. Neither is mine. And that’s just the way it is. Learn to accept your flaws, and the experiences of others. And if you think you’re the best developer on your team, you’re wrong. The best developer is the one who realizes that they’re not the best.
8. Leave yourself a trail. When you hit a particularly sticky problem, write down the possibilities and record your progress. If you try to do it all in your head, you’ll get lost. And sometimes the act of writing it down (or talking it out) will uncover the path, or at least uncover new possibilities. But mostly, writing it down will save you from wandering around in circles.
9. RTFM. No really, read it. If you can’t solve a problem, and you haven’t read THE FUCKING MANUAL, then you don’t deserve to solve the problem in the first place. Newsgroups, forums, and wikis can help too. And if you’re stuck and not thinking, testing or reading, then you’ll stay stuck. And as likely as you’re wrong about something, TFM can be wrong too, so test what you learn carefully.
10. And finally, Just f@ck!ng do it. Are you stuck in development because there’s something you don’t understand? You need to attack the problem and get it over with. There’s only so much to learn about any given problem, and it doesn’t happen any faster when you avoid it. Take small steps. Measure, test, learn, ask questions. You’ll find the solution more quickly when you stop wasting time throwing chairs.

Remember, if you don’t come to understand why things work the way the do (and how things often break), then you will run into the same problems over and over again. It’s always worth the time to figure out the fundamental truths in what we do: it will save time and prevent future pain.

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.

WordPress’s tagging feature is good, but it lacks mass-editing. Healthy taxonomies need regular maintenance too, so I went hunting through tag plugins compatible with 2.5.1. I found Simple-tags, which is proving handy for nudging around the tags on my 2,000 or so posts.

Useful features:

• Bulk tag delete and rename, including tags listed by popularity
• Tag grouping, which allows you to add a tag that encompasses other tags
• Auto-tagging, on post-save or en-mass

While it takes some time to clean up a tag space, it’s at least possible now.

According to Jeff Atwood, programmers don’t read anymore. And in my small slice of the universe he’s mostly right, a problem of motivation, time, and a lack of good reading materials.

So what’s a developer to do? How about you spend a few hours reading this week. Here are a few recommendations:

• A paper on Causality and probability theory (Postscript)
• A Kerneltrap post on the C semantics of constants and pointers (good comments too)
• A free Addison Wesley book on C++ Gotchas
• A manuscript on Linkers and Loaders
• A large collection of demos and essays on how to think in terms of extensible CSS
• Linus comparing the organization of the Linux Kernel to the evolution of the universe
• Dijkstra answers questions from students about software engineering
• A paper on coroutines in C
• A manuscript for an upcoming book on algorithms (PDF)
• A paper entitled ‘Software Is Hard‘

There’s no excuse for a professional who doesn’t read: understanding needs to be fostered and is always incomplete. And excellence is fueled by obsessively feeding, exercising, and applying the mind. So what are you reading this week?

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.

A great Michael Pollan talk at Google, where he questions nutrition in the hacker way: boiling nutrition down to simple rules based on fact. The root philosophy?

Eat food. Not too much. Mostly plants. –Unhappy Meals, NYT

His thesis is bigger than that, though, and his method of deconstructing what we believe about nutrition is interesting. Really, why do we believe what we hear about nutrition when it clearly isn’t working?

Here’s an interesting NYT feature on burnout, which suggests that burnout is a problem with self-efficacy, a lack of social support, and an increasingly chaotic environment. One of the most interesting studies found that interruptions are as destructive as drug use to IQ:

The uninterrupted group did better by an average of ten points, which wasn’t much of a surprise. What was a surprise is that the e-mailers also did worse, by an average of six points, than a group in a similar study that had been tested while stoned.

One of the effects of lowered IQ is that we get less done. When we accomplish less, we’re frustrated because we wanted to do more. And that frustration is one of the big factors in our burnout.

I’ve had several hours to play with Inkscape 0.46 since it was released, and despite the minor version increment, a lot has changed.

New features

• A “fill” tool, making it trivial to turn bitmaps into vectors quickly
• 3d drawing shapes (including perspective)
• A tweaking tool, making it easy to nudge/blur/soften shapes
• Several new effects (including path effects)
• Many performance improvements, including huge improvements in blur speeds
• Better gradient tools
• Dockable tool windows (nicely done too)

I’m especially excited about the “fill” tool, as it simplifies tracing scanned sketches and logo bitmaps. The tool creates vectors using a flood-fill algorithm, based on the zoom level and configurable limits (fill method, threshold, gap-closing, etc.). In my tests so far, I’ve been able to turn pencil sketches into vectors quickly, as well as scans of real-world-objects.

I found two new natural-language markup tools after noticing that RestructuredText hadn’t been updated for 2 years.

The first is PanDoc, a multi-format natural-format converter. It converts to and from Markdown, Wikitext, ReST, LATeX, HTML, groff, man, RTF, and more. It’s only downside is that it’s written in Haskell, which is only a problem if you need to run it on Windows.

The second is Texy, a PHP-based tool with a syntax that distills Wikitext, Markdown, and ReST concepts into one very complete format. It even supports formatting hints and citations for most XHML tags, in a format that surprisingly intuitive.

A complete guide to optimising websites for speed, rolling up dozens of tips I already knew (and a few I didn’t). The site’s footnotes are cool too (side notes?).

The most interesting tip, “don’t use document.write“, was news to me. I’ll have to test this to see if it’s doing what the author suggests. Also, combining files into libraries is something I’ve planned on doing for a while, and calling them “libraries” is probably the clearest way to think about them: a link phase in site deployment makes a lot of sense.

In case you’re curious, the upgrade to WordPress 2.5 is trivial:

1. Upgrade source:

svn sw http://svn.automattic.com/wordpress/tags/2.5/

1. Run upgrade DB script (just visit your site).

That’s it.

FWIW, the new admin panel is slick, a lot like the Tumblr dashboard. The navigation is sensibly split into regular tasks and lesser-used administration tasks, and the colours/shapes/widget placements are much easier on the eyes. Well done!

It’s difficult to pick a development stack on Windows. Is Windows development falling into the minority?

For what it’s worth, I prefer C++/QT/Boost/STL on Windows, despite the cost and complexity. C# was disappointing, based on having to deploy the runtime with the application (and lack of portability). Python + QT sound enticing, but really I’m looking forward to Webkit/PHP/Apache.

I like Joel Spolesky. He’s a great writer, and he’s got a good head for managing software. But he is blind to Microsoft’s insanity, taking the agnostic-zealot position. I can forgive him, though, as he writes passionately and is willing to question the other zealots.

What Joel and the other flamers have missed is that standards conformance is easy, if you can pull your head out of your ass long enough to realize that it’s already solved. If Microsoft could place nicely, they would be able to cooperate and join the Webkit fray. The world would be a better place.

Apple, Nintendo, and others have figured it out. Why build your own browser? Why not just pitch in to an existing effort, or license something? Standards are easier if you don’t insist on building it yourself.

Standards are easy. It’s NIH that is difficult.