I’ve been gravitating toward web development in the past few years. If anyone is curious, here is my basic approach to web site (and web application) development:

1. Concept: do interviews, write stories about the site/application, create & collect storyboards, sketches, swatches, metaphors, and ideas
2. Pitch: redraft storyboards and organize other materials into a final set including basic requirements if software is needed
3. Plan: milestones, resources, inter-dependencies (only if the $ or scale requires it)
4. Design: site + URI maps, basic visual design, information design, software design
5. Analysis: review design, prototype tough bits, capacity analysis, reflect, and improve as needed
6. Bootstrap: server setup, source repository setup, shell out software and content
7. Development: short, minimalist development (simple styles, skip color + bling, simple implementations, simple code)
8. Finishing: a small amount of review, refactoring, reflection, and improvement (only enough to get off the ground)
9. Release: start internal, limited beta, public beta, version 1, etc.
10. Spit and polish: make things shine
11. Repeat: goto 8 until version 1, then continue incrementing as $/time allow

Notes

• Web development only differers from other software in how easy it is to release quickly
• Some of these items can be skipped, depending on the size of the project
• Many of these items can parallelized with the right people, or when stalled on preceding items
• Too much parallelization becomes chaos (must balance it)
• You must release before polishing, even if internally
• Internal (and beta) releases must be real … if you fake them, the results are useless
• Milestones are critical to finishing, in that you need to finish the project in stages for psychological reasons (or you may never finish)
• Analysis cannot be skipped, even if short (capacity, data, information, etc.)
• If you’re developing framework, then you’re project will fail: focus on your goal
• Use the simplest tools possible: paper, pen, wikis, existing libraries, etc.
• Metaphors, swatches, and examples are cool, and are cheaper than visual-design from scratch

I’m learning Objective-C and Cocoa, starting from the beginning. I toyed with it a few years ago (via GnuStep), but never went anywhere with it. GnuStep wasn’t inspiring, and there wasn’t much of a market for it at the time.

I’m deeply impressed by the visual beauty of what gets built for platforms, with their tools, and the quality of the websites and texts surrounding them. It seems like a shallow heuristic, but every ounce of inspiration counts when wrangling complexities, and any excess of quality (or lack thereof) cannot be ignored. Crafting software is hard. Beauty is elusive. So when tools that bleed excellence, there’s a reason. And it’s stupid to ignore it–if you want have a chance of building great software.

And while I will continue to use and enjoy Linux, it’s time to jump into the land of Mac. Neat stuff is happening there, and I’m often in awe of the software built for it. I’ll still build web stuff too, but I need at least one good rich platform in my toolkit, and Windows isn’t it (and a commercial market for Linux desktop apps may never happen).

Speaking of beautiful sites, here’s today’s Objective-C/Cocoa reading:

• Core Animation Sample Code: NanoLife (TheoCacao)
• Learn Objective-C (Cocoa DevCentral)

I’ve been heads-down on a fun work project, and haven’t had time to post. Or read. Or eat with any regularity. We’re about to ship, so I should get back to my normal posting routine in a few weeks.

Are you a Dummy? David at 37Signals argues that the “Dummies” mentality is a weak form of thinking, where the reader of the book psychologically cheats themselves into the dummy mentality, helping to fulfill their destiny as such.

I think it’s simpler than that. The “Dummy” books (and their low-end counterparts) are crappy information. They’re like fast food and couch-ups for the mind. You put garbage information in, you get garbage thinking out.

I first noticed the GIGO textbook effect with a few books I bought on C++ in the early-mid 1990s. I knew C fairly well (thanks to K&R and Plauger), so I figured learning C++ would be a breeze. I picked up a few cheap texts at a local bookstore and went on my merry way. Months later I was still struggling with the language. I didn’t understand why until I went back to my old C texts: they were simpler and clearer than my new C++ books. The C++ texts were part of a newer generation of material infected with screen-shots, compiler-settings, and half-truths. They were horrible.

At the time, I couldn’t discern between good information and bad, and I had filled my head with a bunch of weak metaphors and buggy examples. The problem was that I didn’t realize that there was a difference in quality of information, and how important that quality was to learning. And it wasn’t just the correctness of the information either, it was the whole approach to critical thinking that an author impresses on you: things like how a language should be used, what was intended, and how it actually works.

Later I relearned C++ through the eyes of Stroustrup, Plauger, comp.lang.c++, and such. It was a different language. There was no mystery. I knew what should be possible, and where to look when it wasn’t.

I spent a few minutes tonight figuring out why PNG files display differently on Safari (and IE6/7). It’s related to both gamma and colour space.

A partial solution:

pngcrush -rem cHRM -rem gAMA -rem iCCP -rem sRGB -d fixed/ *

The real solution:

There is no way of making PNG images that match CSS colors in all PNG-supporting browsers. This reduces the usefulness of the otherwise excellent image format. If the image colors and the colors defined in a style sheet need to match, it is safer to use GIF or JPEG. If you want to use PNG and don’t care about older browser versions (pre-Tiger Safari in particular), the best course of action is removing all the color space information from the PNG files. If you only want a match with the background color, you could make the background a PNG image as well. –The Sad Story of PNG Gamma “Correction”

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. ↩

Named, optional function arguments are a commonly used calling convention in Perl modules, used for constructors and heavily overloaded functions. They’re usually implemented with hashes in Perl, and while somewhat more work to iterate in the library than fixed arguments, they clearly document the call for the caller (and tend to be far less fragile).

They’re also easy to implement in PHP. Here’s an example (based on some CodeIgniter code I had laying around):

class bar extends Controller {

    protected $data = array();

    function foo($name, $extras = array('desc' => 'default1', 'on' => false)) {
        $this->data = array_merge($this->data, $extras);
    }

}

1. The optional parameters are defined as the array elements of the $extra default array parameter value.
2. The optional parameters are merged with the class data $this->data.

Calling the function is simple:

$b.foo('test', array('on' => true));
$b.foo('test 2' /* uses defaults */ );
$b.foo('test 3', array('desc' => 'Here is a description'));

The caller’s syntax isn’t quite as clean as Perl’s, but applying the defaults is cleaner (and merging the structures is about equivalent). Despite the slightly more complex calling convention, it’s still useful for setup functions with multiple optional parameters.

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.

1. I just purchased Adobe CS3 ($1600+) for my commercial design work. It isn’t cheap, but it is an excellent set of tools. ↩