In HTML5, including any arbitrary attribute may be included in any element provided that it is prefixed with data- and doesn’t interfere with the rest of the standard. Anything. So I can do the following and have it be perfectly valid:

<div data-panda="bamboo"> Whatever <div>

How awesome is that?

In reality, this has been a big month for JavaScript with Google open sourcing its internal JS toolkit, Closure along with much attention being paid to to projects like NodeJS (for network stuff) and CommonJS (for everything else).

The Google Chart API provides a rediculously clever way to get high-quality information graphics which are generated on the back of the clearly-amazing Google infrastructure. You just use the URL layout provided and it sort of just works. All types of charts can be created. It’s very nice if you’re willing to take the time to piece together the URLs in the proper format. There are some abstractions, though.

Then there’s flot (which I’m told is Swedish for “pretty”). Flot is a library written in JavaScript on top of jQuery which produces very nice charts inside a canvas element. The demos are quite gorgeous and it’s operation seems straightforward enough. As a side note, Lift has a built-in flot widget.

• Emacs concurrency (or lack thereof)
• XSLT for fun and profit
• Programming with distributed objects in Ruby
• Unit testing JavaScript

That is all.

The perils of clobbering namespaces for the sake of convenience in any language are well know. Now, in some languages, a use directive is not always the culprit when namespaces get clobbered. Languages which also have an as clause can be dangerous as well because they obscure the true origin or name of a given object.

Part of the reason is that using USE or one of it’s friends is dangerous due to the fact that programmers risk forgetting that they used it. This kind of error is not restricted to the USE statement, however. For example, in Lisp, global variables are typically enclosed in asterisks by convention. So what, right? Well, early on in Practical Common Lisp, Peter Seibel points out that redirecting something like *standard-output* to point to another source, it would be all too easy to forget to put it back! Just like it’s easy to screw up redirection by forgetting to put it back, USE in most languages makes it quite easy to make trivial mistakes.

Now, I am not suggesting that these examples are directly equivalent. I am, however, making the point that, in this day and age, we are well aware of how easy it is to make careless mistakes and USE directives only make it easier. Say we have an example instance of an SQL server and there are a couple of databases in there. We want to work with two of them (called panda and bamboo) each but we’ve got quite a lot to do with one. For an example such as this, databases like MySQL, provide USE only to be compatible with Sybase and even then only as a utility function.

In any case, we’re going back to the example. We’re at the prompt and we’re going to work with with our first database, panda. So to save ourselves trouble, we go forth with a USE panda; and then go about our business. Then, we’re ready to go ahead and delete a whole bunch of records from bamboo so we run our DELETE * FROM trees; and all should be well, right? WRONG! We forgot to switch to the right database by using USE bamboo; so now we’re in trouble. While this is a simplistic example, the world would be hard-pressed to find a competent programmer who’s never been tripped up by the most simple of errors.

It is for this reason that I am wary of USE and it’s friends. Unless there is a very good reason to USE USE, I suggest that programmers be very careful AS well AS when we USE AS. Together, they can be a tricky combo.