Moving to – bare domain and www


I moved to this week, from It is much faster, and now I won’t get popup ads.

While moving the site, I took the opportunity to upgrade to the current WordPress. I think I was on WP3.3 previously; now it’s on the current release. And now I’m on the current PHP, too. Nice.

Everything went pretty well. I had some fun with the wordpress part – updating the existing plugins, using wp-cli, fiddling around with my own plugins which had a few problems using deprecated WordPress functions…, doing surgery on other plugins, now abandoned.

I had to update from the old Twitter widget I had been using; it was still using the Twitter v1 API, which did not use OAuth. This API is no longer supported, so the widget wasn’t able to retrieve any tweets. I found a new one called… really-simple-twitter-feed-widget. And it was pretty simple, in the end. But I did have a problem: when pasting my token secret into the configuration box, I inadvertently had grabbed a leading space. Instead of pasting “XYZABC” as the token, I had pasted “_XYZABC”. But I didn’t realize this, because the textbox was masked, and all I saw was those dots.

The incorrect token secret caused all of the signatures generated by the widget to be invalid; therefore the Twitter API was rejecting them. I had to crack into *that* code as well, to diagnose this. Only printing out the token secret just before it was used to generate the OAuth1.0a signature showed me the light. After that, the new Twitter widget just worked! Sweet!

Finally, I got all the PHP squared away.

NFS is a cheap hoster, but easy? No. I don’t mind the lack of cPanel. I love the SSH access to my machine. Everything is possible on NFS; the trick is figuring out HOW to do stuff.

The last thing I got stuck on, in the move to NFS, was configuring to redirect to The FAQ for NFS says that you can do it using “a hard canonical name”. But doesn’t say HOW to make that effective. Back and forth through the FAQ on the NFS site, to no avail.

At last, this blog post helped me.

  1. Go to the Nearlyfreespeech UI ->Site->Select the site in question->Add a new alias e.g.
  2. Once appears under the Site Name and Aliases table in the site menu, click the “Set Canonical Name” (on the menu on the right)
  3. Select HARD Canonical settings and select

Thanks, Keith! I don’t know why this isn’t in the FAQ doc for NFS.

Comparing Graphite and Flot

Producing a dashboard with charts generated by Graphite using its render API I kinda liked the results:

Sample TP95 chart from Graphite

But then I thought, I wonder if I could produce the same dashboard from the raw data, using jquery flot?. And the answer is, of course:

Sample TP95 chart from flot

Which do you prefer? I kinda like the flot version better. As a developer, I have finer control over the look of the chart. This means, for one thing, the fonts are nicer. Also, I can move the title around, style things differently. And I can make the chart interactive, too. Using graphite involves significantly less labor, though. Less custom code.

I don’t really hate NodeJS

I don’t really hate NodeJS. Yes, a while ago, I said I hate NodeJS. But I didn’t really mean it. I was just suffering from unrealistic expectations. I learned to Let Go of my idea that JavaScript on MacOSX ought to be as easy as JS on Windows.

Since then I have adopted NodeJS pretty strongly. I use it for all sorts of tasks, from tools that automate Apigee Edge (nod to my employer) to API load generation utilities.

I write more code using NodeJS these days, than in anything else.

Recently I had occasion to write a little utility that computes TP99 for a set of API transactions being managed by Apigee Edge.

What it does is retrieve the transaction records logged from the Edge Analytics database, sorts them, and emits a computed TP99 (and TP95, TP90, TP50) to a Carbon server, which is backing Graphite, which then serves up charts of that data. A sample is below.

Sample TP95 chart from Graphite

For this tool, I chose NOT to use NodeJS but instead relied on good-old PERL. I didn’t want asynchrony, and I did want easy file I/O, pattern matching, and sorting. Also I wanted it to be maintainable by old-school sysadmins who no-doubt have not been following the finer points of using Q’s promises in NodeJS. Perl was the obvious choice. The sort required to compute TP99 will run on 60000 records or more, and needs to occur every minute, for all transactions logged during that minute. A cron job running a perl script was perfect for this.

But, recently I wrote another tool… this one automates the provisioning of EC2 instances in AWS, then installs Java and Apigee Edge on them, and configures them into a cluster. I wouldn’t want to do that in perl or Bash. NodeJS was the right tool for that much more complicated job. And of course there are NPM libraries for AWS, and for ssh and scp. Really helpful.

of nodejs and new clothes

A provocative post by Eric Jiang, entitles “The emperor’s new clothes were built with Node.js”, regarding the undeserved praise being heaped upon NodeJS. While I think he gets his analysis all right, he is still missing the forest for the trees.

Nodejs has grown the way it has grown for the same reason that Visual Basic and PHP grew the way they did: These things work well, and help people get things done quickly and relatively easily. And maybe, people even have fun doing it. The community support has been critical in all three cases.

Sure it’d be nice to have multi-threading like Go and a single set of known and blessed libraries like C# and performance like C. But we don’t have all those things in one package, not yet anyway.

There are weaknesses in NodeJS, just as there are in PHP and in VB. Despite that, JavaScript is effective for many many people, and will continue to be so. NodeJS makes JavaScript much, much more effective with the NPM and the vast set of downloadable modules.

No religion, yo: nodejs is not always the right choice. Of course it isn’t. I like nodejs and use it… daily. but I’m learning Go and am enjoying that as well.