One of the Javascript libraries we use at work includes a method called getLayersByName(). It has a parameter, name, described as follows:

{String | Object} A layer name. The name can also be a regular expression
literal or object. In addition, it can be any object with a method named
test. For reqular expressions or other, if name.test(layer.name) evaluates
to true, the layer will be included in the list of layers returned. If no
layers are found, an empty array is returned.

So, if you want to test using a function that returns true or false, similar to filter() in functional languages, you can’t just do this:

var name = function(n) { var r = doSomeTest(n); return r; };

Instead, you have to do something like the following:

var name = {
    test: function(n) {
        var r = doSomeTest(n); return r;
    }
};

(Actually, there are several functions that work in a similar way, but this is the simplest one to use as an example.)

Why not check the type of the parameter and, if it’s a function, call it directly rather than looking for a property? I have no idea. I’m assuming that originally the function was intended to take a regexp object, and the fact that it supports any object with a test() method is more by accident than design.

For most of the last 9 months, I’ve been working on a project called InterRisk; specifically, developing a web portal for viewing scientific data overlaid on a map. (The scientific data is marine-related, in our case mostly to do with algae levels around the UK and Irish coast). Anyway, most of the coding has been in Javascript; there was some PHP, but I’m trying to avoid it, and any new server-side code will probably be in Python because it’s awesome.

Before I started, I’d done very little javascript, just a few toy programs and whatnot. Mostly my experience of it was through bloody annoying websites that use it unnecessarily.

What I’ve learned, though, is that it’s actually a reasonably decent language — yes, it has some misfeatures, and some things don’t behave as I think they should (for (i in object), for example, which sets i to the index of the member, not the member itself like in python or sh). They’re fairly minor, though, in my opinion, compared to some of the good features, like functions being first-class objects that you can pass around, for example as event handlers. (I know that quite a few languages can do this, but it was a surprise to learn that Javascript could).

The real spoiler, though, is browsers. If I could write an application that only had to support one browser, I’d be reasonably happy. At least, if the browser in question wasn’t Internet Explorer. The variability in javascript support in the various browsers, though, is a serious issue; there are so many features that just can’t be used because Internet Explorer 6 still needs to be supported (or even IE7, which as far as I know has almost identical javascript support to IE6). I don’t know if IE8 will be an improvement, but it’s hardly important — it’ll be years before IE6/7 are sufficiently rare to make using newer features safe in a portable application (mostly because there are organisations still using IE6, after more than two years — I understand the arguments for not rolling out new software immediately, especially in large corporate environments, but two years? What the hell are you doing?).

(There is a bright side — as I have no access to any IE6 machine at work, I have an excellent excuse not to support it. As mentioned, I don’t think it makes a difference where javascript is concerned, but it’s one less thing to worry about.)

Even discounting Internet Explorer for the moment, things aren’t perfect; I’ve run into problems because, for example, Firefox allows things that Opera doesn’t, when Opera’s behaviour is actually the correct behaviour (but of course, I can’t code to Opera’s strict standards-compliance, because discounting Internet Explorer was only wishful thinking, and IE7 doesn’t support the correct way of doing things that Opera mandates).

Not supporting large chunks of the DOM (DOM level 2 or 3, if I remember correctly) is okay, though, because I can just extend the Node object to provide wrappers — if getElementByTagNameNS isn’t defined, fake it using getElementByTagName instead. But oh, wait, Internet Explorer doesn’t let you extend the built-in DOM objects. Why? No idea, but it means that I have to write a wrapper function for every browser to use, even if it supports the necessary methods natively. So much for that plan.

Then, when something goes wrong — and it will — you’re sort of stuffed. While Firefox has Firebug, which isn’t perfect but does the job well enough, and Opera has Dragonfly which was great while it worked but seems to have broken for me, Internet Explorer has…nothing. As far as I know. Extensive Googling has, at least, turned up nothing. IE7 seems to have only about two or three javascript error messages anyway (which at least is more than ed, which makes do with one — ? — but they aren’t much more helpful), so it’s back to alert() and popping up the value of variables at a dozen different points throughout the application. (I assume Microsoft expect people to fork out for Visual Studio or something to get access to a debugger. Sod that, all I want is useful error messages and a DOM inspector)

Anyway, this has turned into more of an Internet Explorer rant than a Javascript rant. As I mentioned, no browser is perfect, but some are less perfect than others, and as Internet Explorer is still ⅔ of the browser market, it’s proportionately more of an issue than Opera or Safari, or even Firefox, would be if their javascript implementation was as poor.

Update: Simon points out that IE8 does no better on the Acid3 test than IE7, but suggested the Internet Explorer Developer Toolbar from Microsoft; I’ve not yet had a chance to test it.

Wrote a script to display Twitter updates via notification-daemon (used quite heavily in Gnome, I believe, but I’m not sure about KDE). It’s written in Python, and it’s here.

Did some coding today, for the first time in far too long (not counting Uni work, anyway). A while back, I wrote a quick-and-dirty PHP script to display the contents of the TermiSoc quotes database (which is just a text file in fortune format, i.e. delimited by \n%\n).

Anyway, I wanted to generate RSS output, but that was basically impossible without rewriting the entire script. So that’s what I did, in Python instead of the devil-language that is PHP. Source is in my git repo, live version is on zaphod.

The advantage of doing it this way is that it’s easily extensible to do basically any format; currently supported are HTML, Atom, and raw (i.e., fortune), with RSS, Yaml, and JSON in the works.

Software portability isn’t much of an issue nowadays; standard APIs (like Win32 and POSIX), virtual machines (Java, .NET/Mono), and interpreted languages (like Ruby, Python, Perl, and PHP) mean that whatever your chosen platform, you probably don’t need to worry too much about it.

This site is generated by three shellscripts and a makefile. I originally wrote them on Debian, using GNU make and coreutils. Then, I attempted to port them to FreeBSD, with Berkeley make and userland.

Big mistake.

• GNU stat takes a long option --format to specify the output format. BSD stat takes a short option -f instead. GNU stat apparently does have a short option for it as well: -c. Your guess is as good as mine.
• The format specifications for the two versions of stat bear no resemblance to one another whatsoever.
• GNU date has an option -r to display the last-modified time of a specified file. BSD date uses -r to indicate that it should interprete the following number as seconds since epoch, and print the corresponding date.
  • Actually, that’s something I’ve missed in GNU date, especially since the GNU version’s replacement feature is just a duplication of stat’s functionality.
• GNU sed has some crazy extensions that aren’t in BSD sed, that I suspect were coded by the crack-smoking monkeys of Gnome fame.
• BSD head doesn’t let you specify relative to the end of the file like GNU head does (e.g. print all but the last two lines), although BSD tail has the equivalent (e.g. all but the first two lines).
• rms scares small children.

I’d really like to make it portable, at least between BSD and GNU, but it looks like it may be a bugger to do so.

Dan,

Bugger! has been delayed due to my laziness. However, as of yesterday I’m working on it again. Keep an eye on ?this page for more details.

I wrote a script for irssi, that uses SmartyPants to turn normal quote marks into fancy ones in messages you send.

It requires Text::Typography and HTML::Entities from CPAN (in Debian, HTML::Entities is in libhtml-parser-perl).

You can get the script from my Darcs repository: http://darcs.bmalee.eu/. It’s GPL.

A few tweaks to the template used by Planet TermiSoc, and now the Atom feed include’s the poster’s name in the title. This means I can actually tell who the post is by. :)

I can do the same to the RSS feeds, if you like, but frankly Atom is a better format, so you should be using that anyway. :)

Bugger! is the bug-tracking software that I’m writing (and yes, the exclamation mark is part of the name). It’s written in Ruby, and designed to have as few external dependencies as possible (so far, it looks likely that it’ll need an MTA, web server, or command shell to manipulate the database, and possibly GnuPG for authentication - other than that, I hope to keep it to just the core Ruby libraries).

Partly I’m writing this for programming experience, or just for something to fill my free time. Partly it’s because I haven’t yet found a BTS that I like (Trac is quite good, but the Darcs support is still experimental; Bugzilla is awful and requires MySQL, though I think it can do Postgres now; Debbugs works how I want, in general, but seems very complicated - probably because it’s Debian-specific).

Bugger lives in my public Darcs repository: darcs.bmalee.eu/repo/bugger/; the web interface is at darcs.bmalee.eu and the project home page is ?right here.

After using Python a lot recently, I’m starting to miss Ruby; it has some nice features that Python lacks (object.each iterators, for a start, and the very nice Date (or is it Datetime or Time?) object that parses input in gods know how many different formats then allows you to output it again in any format you like - I know Python has strptime, but it doesn’t guess at the format like Ruby can).

It’s a grass-is-always-greener thing, of course; if I was using Ruby a lot I’d miss Python’s syntax (I hate having to type out “begin” and “end”, partly because I cock it up so often).

I’ve been looking at Haskell recently, but I’m a long way from understanding functional programming well enough to actually use it. All I’m sure of is that I don’t want to have to use Perl much in the near future (dollar signs get on my wick).