I’ve been immersed in Blackberry development for several weeks now. It’s an interesting platform, lost somewhere between the older platforms (like Palm and WinCE) and the newer ones (like iPhone and Android). While it has an extensive UI toolkit, most of the applications written for it are simple and uninspired. And while it’s a hugely popular platform, it has a grossly primitive filesystem, limited data storage choices, and a surprisingly sparse set of open source and commercial libraries.

Despite the platform’s limitations, it is a workable environment. It supports a large subset of the J2ME runtime and libraries, and it has a functioning set of development tools. The most interesting thing about Blackberry development, however, is the lack of great documentation. Very few developers write about the platform. There are only a handful of specific Blackberry textbooks, and RIM’s own developer site is horrid. They have reorganized the developer site a number of times in the past few years (there are many dead links), its best documentation is hidden deep beyond its own search tools, and it lacks the sort of details needed to make good architectural decisions.

The limited development environment and RIM’s position between the old and the new make it a risky platform. It’s obvious that RIM hopes to catch up with Apple, with their upcoming OS (4.7) and their new application store. I hope that they’re able to release the new OS before the end of next year, otherwise both Android and the iPhone OS will have left Blackberry in the dust, along with Palm, Symbian, and Windows Mobile.

I was an OS X virgin until about a month ago. My company offered to buy me a Mac, a shiny 24in iMac. It’s the first inspiring piece of technology I’ve had the luxury of using, next to my iPod touch. Not that I haven’t used a Mac before, I just haven’t owned one as a primary computer.

I’ve owned dozens of PCs. Laptops, integrated units, and plain-old-boxen. I mostly build my own PC hardware now, and it turns out okay. Nothing I’ve used, though, compares to the iMac. Why? The answer is somewhere between the superbly packaged hardware, and the damned reasonable OS.

I’m a Linux guy. I was a Windows / generic Unix developer before Linux was usable (and DOS before that, ST/Amiga before that, 850x before that). Ubuntu is an enjoyable packaging of Gnome and Linux; I use it daily, side-by-side with XP and Vista. They’re both capable. They’re both flawed. Depending what I’m doing, Ubuntu is my first choice, as it’s a developer’s platform. But neither Linux nor Windows compare to OS X.

On Ubuntu, things break regularly. Nothing insurmountable, but I found myself cursing broken Sane drivers, USB bugs, and package dependencies more than I should have. On Windows, things are just fundamentally broken, as the legacy design is so horribly coupled that developers don’t really stand a chance of building anything great. Microsoft knows it, but legacy has made it difficult for them to progress. I don’t hate either system, but neither inspire me.

OS X is better. Not perfect mind you, but it forces several simple patterns on developers, making for a less coupled environment, inspiring a surprisingly rich set of tools for such a small market. And it’s that inspiration that drew me to Mac in the first place. Great software is hard to pull off, and I’ve found that most Mac apps are clean, simple, polished, and damned useful.

I’ve spent a few dozen hours in Xcode now too. Like the rest of the platform, it’s surprisingly sensible and productive. Objective C is a smart approach (C with eventing extensions), and the platform libraries (frameworks) of Cocoa are quite good. As an experienced C/C++ programmer, with experience in Java, C#, Perl, PHP, Ruby, Smalltalk, Lisp and other languages, learning Objective C was a breeze. The performance/abstraction balance is brilliant, especially for the iPhone.

I’m still using Ubuntu and Windows (VMWareFusion), but the Mac has replaced my desktop system. I was more productive in Mac land within the first two weeks, mostly a function of Spotlight, Textmate, Spaces, and the great default terminal/shell tools. Next up, I’m saving for AI/PS, to replace the Gimp and Inkscape.

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

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.

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. Note that this style of layout only works on systems like Mac and Linux that have useful symlinks.

First, the folder layout

some-domain.com/
    app/
        config/
        controllers/
        (etc)
    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 local 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.