Wikipedia has a great summary of the Javascript/ECMA language. It beats the pants off of the average ad-laden Javascript site, as it’s easy to read and covers a useful subset of the language.

The city’s central computer told you? R2D2, you know better than to trust a strange computer! – C-3PO

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.

A good overview of contextual user interfaces, including several examples.

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.

A much better set of rewrite rules for CodeIgniter apps than the ones suggested by their docs. Use these rules, not the ones in the official docs, as these rules specifically exclude access to the library’s naughty bits, and more sensibly enable access resource-type files.

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 mildly entertaining JoelOnSoftware forum discussion on Logon versus Login. Which do you prefer?

Google releases a much better RSS reader for the iPhone. I’ve been waiting for a rich RSS client for my iPod Touch, but this may just be good enough.

Jeff Atwood on ‘XML: The Angle Bracket Tax‘ (via Yangman).