Jeremy pointed me at an article mentioning JSLint today. It’s a fantastic idea, and even more astounding, it’s actually implemented in JavaScript. This is great for showing it off as “the little language that could”.

The only problem is that it doesn’t integrate well with my development environment. I normally use TextMate or Vim. JSLint needs a JavaScript runtime, which is conveniently loaded into my browser, but inconveniently not loaded into my command line. So I set out looking for a way to come up with a command line version of JSLint.

The JSLint web site actually points out a few options. But I don’t run windows (for WSH) or Konfabulator, so that’s no good. I could try using Rhino, but I’d rather avoid a heavyweight JVM invocation (1.5s to run is too slow).

The first port of call is Mozillas spidermonkey. Handily, this is already in my FreeBSD ports collection, so it’s a quick install. But there’s one slight problem—it provides no way to do I/O. So I can’t tell it to read stdin to get the JavaScript to check. Interestingly:

  • Rhino does provide a ReadFile() call, but not spidermonkey. How annoying.
  • Spidermonkey provides a File() constructor, but it doesn’t appear to compile when enabled (I think this is down to spidermonkey being disassociated from the main mozilla source tree).

So, let’s try another little hack. There’s another port available, lang/p5-JavaScript-SpiderMonkey. I should be able to use a small amount of Perl to complete the task. Except that the API is bizarre, baroque and hangs when I feed it jslint. Grrr.

On to njs. That fails to even parse the blasted fulljslint.js, stopping on the first line with an unexplained “syntax error”.

Oh well. I guess I’d better go and try to get SpiderMonkey working again.

It’s really depressing that it’s so hard to get JavaScript working outside of the browser.

Update: Ian Bicking is coming to much the same conclusions about this…


cfengine Introduction

For years, I’ve looked at cfengine and thought “I must get around to learning that”. Today, I was reading Building a Self-Healing Network and finally thought that I need to give it a try.

One of my problems is that processes on my FreeBSD server often get stopped when I run portupgrade and I don’t notice. cfengine claims to be good at fixing non-running processes, so I gave it a try and came up with this:

      actionsequence = ( processes )

      "amavisd"        restart "/usr/local/etc/rc.d/amavisd restart"
      "clamd"          restart "/usr/local/etc/rc.d/clamav-clamd restart"
      "dhcpd"          restart "/usr/local/etc/rc.d/ restart"
      "dovecot"        restart "/usr/local/etc/rc.d/dovecot restart"
      "freshclam"      restart "/usr/local/etc/rc.d/clamav-freshclam restart"
      "httpd"          restart "/usr/local/etc/rc.d/apache restart"
      "named"          restart "/etc/rc.d/named restart"
      "nmbd"           restart "/usr/local/etc/rc.d/samba restart"
      "ntpd"           restart "/etc/rc.d/ntpd restart"
      "postfix/master" restart "/usr/local/etc/rc.d/postfix restart"
      "postmaster"     restart "/usr/local/etc/rc.d/ restart"
      "smartd"         restart "/usr/local/etc/rc.d/smartd restart"
      "smbd"           restart "/usr/local/etc/rc.d/samba restart"
      "squid"          restart "/usr/local/etc/rc.d/squid restart"

When run via cfagent -f checkprocs.conf, this works a treat.

The next step should be getting all the other cfengine gumph working on my network. However, I’ve only got one box, so running it every hour out of cron is good enough.

  0 * * * * root /usr/local/sbin/cfexecd -f /usr/local/etc/cfengine/checkprocs.conf

In accordance with the cfexecd documentation, I also amended my control section so I’ll get mail when it does something.

      actionsequence = ( processes )
      smtpserver = ( localhost )
      sysadm = ( )

This seems to be a good start on getting cfengine working. Now I can play more with it. It seems like it’d be another useful tool for work.

Update: cfexecd doesn’t work. Running cfagent directly does. How annoying.


London JavaScript Night

I’ve just gotten back from LJS. It was an excellent evening of talks (bar mine, I feel). The two talks I really wanted to see (“JavaScript Idioms” by Paul Hammond and “JavaScript Taste Testing” by Simon Willison) were superb.

Paul Hammond gave a very good overview of why things often look a bit funny in JavaScript, but are actually sensibly thought out. His idioms in other languages managed to draw puzzled looks and laughs in almost equal amount.

Simon did a whirlwind tour of Dojo, Prototype, the Yahoo UI Library and MochiKit. It was a pretty well thought out and explained piece of work. He did a good job of showing where the tradeoffs lie in each case. It’s also made me realise how much I need to try the alternate toolkits to get a feel for them… (NB: Apparently YUI makes a best effort at accessibility for its widgets, which sounds like a Good Thing™).

Of the remaining talks, I really enjoyed Dan Webb’s DOMBuilder, which strikes me a an extremely elegant solution to the verbosity of the DOM.

Tom Insam’s enthusiasm for E4X was extremely entertaining, despite the ending (“It’s hardly worth bothering”).

It was a difficult act to follow, and to be honest, I completely tanked. I had expected about 30 people, and there were around 200. Plus my topic was relatively obscure to most people. Ah well. Next time I’ll find a better subject (and practise more beforehand). Oh, and get a proper PDF presentation instead of S5. That would have been much easier to handle. BTW, the slides are up.

Hopefully the slides for the remaining talks will be up in the next day or two.

A big thanks to Greg McCarroll for organising it all in the first place. Good job, Greg.


mod_perl 2 not ready yet

I’ve spent nearly three days this week trying to port one of our sites to Apache 2.2 and mod_perl 2.0.2 (from Apache 1.3.33). It should be a relatively simple exercise thanks to the porting notes available:

Yet sadly, there’s still a lot of problems with mod_perl 2. Firstly, much CPAN software still hasn’t adjusted. In my case it was SOAP-Lite. But I also noticed that libapreq wasn’t classed as “ready” by Mason, so we had to fall back to there.

But the real killer is that they managed to completely break environment variables, in the name of thread safety. Unfortunately, our application uses Inline::Java from inside Apache to talk to Lucene. Now Inline::Java spawns a JVM to run a JAR file and be the server. So that the JVM can find the jar (as well as the lucene jar and our code), it sets $ENV{CLASSPATH}. Except that change never shows up, so the JVM just says “unknown class” and exits.

Basically, mod_perl2 breaks system. This is not clever.

So we won’t be upgrading to Apache 2.2 for a while. This is a shame, as it has a bug fix we really need (>4Gb file support). Instead, we switched to using FTP. Yuck.


Firework Fun

Speaking of the Brighton Festival, I should mentioned the utterly awesome display of theatrics and fireworks that I saw last Saturday. In preston park at 22:00, Groupe 4 1 put on the most marvellous display. It wasn’t just fireworks. it was also men with suits made of lights, flying through the air to a musical and video backdrop. Absolutely beautiful. Touching, in places. Downright weird in others.

Sadly, most of the photos that I’ve seen so far have just been of the fireworks, so that’s what you’ll have to see.

All culled from brighton fireworks on flickr.

1 Sorry, it’s a horrid flash based site. Completely unknown to google as well. I ended up there almost by accident.


Revenge of LoveLock

It’s Brighton Festival time. On Tuesday, I saw James Lovelock speak about his new book “Revenge of Gaia”. I’m new to the whole gaia thing, but the notion of treating the earth as a holistic system makes a lot of sense to me.

He talked a little bit about Gaia, but much of the talk seemed to be given over to his dislike of wind farms and his pro-nuclear energy stance. Myself, I’m neither anti-nuke nor pro-nuke. He did question much of the evidence regarding nuclear energy that we had been led to believe, claiming that the safety issue of spent nuclear fuel is overrated, and the cost issues of nuclear are mostly because of onerous health & safety legislation.

He quipped that he’d be more than happy to have spent nuclear fuel in his backyard because it might keep the damned wind farm developers off it…

The other main theme was about global warming. Like most scientists, he cheerfully accepts that it’s happening. But his view of what will happen and when seems to be markedly more doom-and-gloom. But he’s still happy, because he just thinks we should prepare more. Oh, and that Britain will probably emerge relatively unscathed because of it’s location.

Overall, I certainly wasn’t convinced he was correct, but he did give me food for thought. Thanks to the wonders of this internet thingy, I can also read his critics at the same time.

Oh—I didn’t buy the book. I’m not that convinced…


XTech is Over

The months go past and the conferences come and go. As usual, I can’t afford to go (and “it sounds interesting” isn’t a convincing business case), so I eagerly lap up all the blogs and slides afterwards.

Jeremy’s just come back from xtech and triggered an hour or two of reading. I definitely recommend checking out his slides on Hijax, which is a very good way of doing gracefully degrading Ajax.

He rightly pointed out Suw Harman who seems to have been in many of the sessions and provided good summaries (although possibly in more of the web 2.0 talks than the others, but that’s mostly what I’m interested in).

Following the links, Paul Hammond mentioned Alex Russell’s talk, which has some rather good insights:

Comparing JavaScript to Java or C++ has always been like converting Unicode to ASCII by lopping off the high bits.

Brendan Eich’s talk on JavaScript 2 appears to be the same one that he gave at the Ajax Experience last week, and are hosted at JavaScript 2 and the Future of the Web. It’s really heartening to see that JavaScript is going in a sensible direction after the appallingingly bad (yet thankfully stillborn) js20.

Lastly, everybody needs to read Mark Nottingham on Web 2.0 Caching. It’s critical to getting good performance in the new web order.

Next years is scheduled to be in Paris. I’ll have to see if I can make it this time. Maybe if I get off my arse and find something interesting to write about…


Firebug 0.4 Preview

firebug is one of the best tools I’ve seen for web development in Firefox. There’s a new version due out soon, and Encytemedia have put up a fantastic preview. I’m drooling with anticipation!


Perl List Slice Weirdness

A colleague at work just found this little gem in File::Copy::Recursive:

  my $two = join '-', ( stat $cur )[0,1] || '';

That should pick out the device and inode, join them with a hyphen and set $two to the empty string if the stat failed. However, there’s a precedence problem:

  # Intended code.
  my $two = join( '-', ( stat $cur )[0,1] ) || '';
  # Actual code.
  my $two = join '-', ( ( stat $cur )[0,1] ) || '';

Spot the difference? The || bit applies to the result of the list slice. But what happens when you use || on a list slice? Let’s look at the debugger…

    DB<1> x @statinfo = stat '/etc/hosts'
  0  2050
  1  327794
  2  33188
  3  1
  4  0
  5  0
  6  0
  7  332
  8  1089379886
  9  1134738486
  10  1134738486
  11  4096
  12  8
    DB<2> x @statinfo[0,1]
  0  2050
  1  327794
    DB<3> x @statinfo[0,1] || ''
  0  327794
    DB<4> x @statinfo[0,1,2] || ''
  0  33188

So it appears that putting a list slice into scalar context always returns the last element of the list. Weird. More info (including examples at perldoc/C-style Logical Or).

Hopefully, he’ll file a bug report as it was actually tripping him up…

Update: RT#19205


Prototyping Squirrels

There’s a new article on ExplorerCanvas: Interactive Web Apps. It’s all about chasing squirrels with a web page. So far so good.

But I noticed that the author is using Prototype. Good stuff! Great way to cut down on having to do a lot of stuff yourself.

Yet reading through the article, it seems that the only thing it’s being used for is the $() function and the Ajax bits. I base this on the fact that on page 2, the wheel (in the form of event handling) is completely reinvented. Why bother including all of Prototype if you’re going to ignore large bits of it? You can cut’n’paste $() in a few lines of code instead…

Personally, I’d spend a short amount of time reading a couple of the really good articles on Prototype:

Remember: Prototype isn’t just for Ajax.