
Lossy RGBA images are something that always has been missing on the web (If you ignore Mozilla's brief support of JNG, that is). Nowadays, browsers typically support JPG, PNG, GIF, ICO, and BMP. There is obviously some feature overlap, but there isn't any good choice for true color images which also happen to use alpha.
Generally your choices boil down to JPG and PNG. If you ignore animated GIFs (which are pretty useless for Canvas usage), PNG can easily replace GIF, ICO, and of course BMP.
Today, I'll demonstrate how you can create RGBA images which use JPG for the RGB channels. Since this can decrease the file size up to 75%, it's a very easy and intriguing way to speed up the loading time of your game or application. (If you are currently using heavy PNG32 images, that is.)

Generally speaking: off-screen rendering allows you to cache expensive drawing operations in some sort of image, texture, or buffer. With the new Canvas API the vector drawing operations for example can be a bit taxing. Same goes for gradients or patterns (Firefox 3.x). Or well, anything that requires many drawing steps or per-pixel calculations.
If you have used any other 2D drawing API in the past, you'll probably picture this a bit more complicated than it actually needs to be. As it turns out, it's surprisingly easy with Canvas since the drawImage function can also take another Canvas as parameter. So, there is no need to construct an actual image – you already got one, kinda.
Komodo Edit – the open source spin-off of Komodo IDE – is hands down my personal open source application of the year. It had a massive impact on my productivity and it made web development so much less of a pain.
I used so many different text editors in my life, but none of them comes anywhere near the sheer awesomeness of Komodo. There is proper Unicode support, smart indent (which actually behaves smart), remote file editing (FTP, FTPS, SFTP, and SCP), Code Intelligence (~IntelliSense™), and lots of polish on top. It supports many languages and runs on the three most popular platforms (i.e. Windows, Mac OS, and Linux). It's also extremely stable, which is very important for this kind of tools.
The ActiveState guys are also very helpful and surprisingly responsive. For example there were some issues with active mode FTP, but after a bit of nagging and poking around in the code (mostly nagging though) the problem was solved. Just like that. I also asked for some shortcut which basically does the same as a double click; selecting the word below the caret. A few minutes later the JavaScript macro was there (thanks Todd!) and it even made it's way upstream; the next version of Komodo will include it as a regular command.
I really like standards and absolute strictness when it comes to things which are interpreted by zillions of different programs. After all, a scenario like this just asks for trouble. Validators do help there and as I wrote a few months ago they can really help you avoid many issues, potential issues, and also future issues.
However, I do like automation a bit more and herein lies the problem: 100% standards compliance isn't always an attainable goal. And if you simply can't get a perfect score, you cannot use those validators for your automated tests. A test which always fails isn't really helpful.
There are many things, which never will be valid and you can't do anything about it. Proprietary or legacy content management systems and components thereof are a good example. Another source of pain are those bloody rich text editors. Some of them produce amazingly awkward markup with zillions of font tags all over the place for good measure.
In a nutshell: A static initializer is executed whenever you do anything with that class. It's executed before whatever you wanted to do (e.g. calling the constructor or accessing a field). It's also only executed once.
Many moons ago I released some code which utilized a static initializer. That code worked fine back then, but recent versions of the Flex SDK compiler don't really like it. Well, to tell the truth I also didn't like it, because the construct I used was sorta ugly and, well, pretty wrong.

I just finished a tiny web application. And by tiny I do indeed mean tiny. It's a single file and less than 8kb in size (thanks to GZRepack). You can check it over at riddler.kaioa.com.
It allows you to store the hashes of answers to some question in an URL. If someone clicks on that URL he/she is then asked for the solution. If it matches any of the up to 5 hashes the icon and the border turn green and he/she can then start the next round.
Here you'll get Flash (AS3), haXe, JavaScript, PHP, Perl, and Python ports of my continuous shuffled sequence algorithm. (Update: There are C# and C++ versions in the comments.) As usual the code is available under a Zero-clause BSD-style license, which means you can use it in any way you like.
All implementations utilize an un-seeded default source of randomness. If determinism is required, you'll only need to hand over a PRNG and use that one instead. Or hand the seed over and initialize the PRNG with that one as the original Java version did it.
If you port it to other languages or if you modify it a bit (e.g. as outlined above), you'll have to verify that it works correctly. Fortunately testing it isn't that hard. E.g. if you add "X" and "O" and call next four times you should receive one of the following sequences:
The startup time of Java applets isn't all that great. If you place an applet directly on your front page, some users may not like it. Caspian from puppygames.net removed the (awesome) Puppy Invaders game for this very reason. It's a shame, really. So, what can be done about that?
The issue is the direct start of the Java VM without any user interaction or any indication of what will happen. Apparently there are two options: