unfolding disasters

I've given up on NanoBlogger and moving to ikiwiki (hooray Git!). Head on over to the new blog location.

As the Physics webmaster, I'm in charge of transitioning most of the static department content into SiteCore, as the powers that be get wise to the ways of version control. Unfortunately, I'm not the biggest fan of SiteCore. Major gripes include:

• Poorly conceived versioning. Some things are versioned, some things aren't. No tools (that I've found yet) for analyzing history except on a per-page scope. Also, can only commit changes at the page level, which makes a single "I added alt tags to all my images" commit impossible.
• Browser-only interface. That's right, no scriptable API short of driving a browser through a script. This one is so huge, I'm not really sure what else to say. Surely people occasionaly want to do something that the designers hadn't planned for, like, oh, importing data from a preexisting database.

Anyhow, to overcome the major limitation, I'm driving my browser through a script. Thanks to the magic of WebDriver/Selenium for making this possible.

I finally got around to translating some IBW readers from C to Python. And so, I present (drumroll :) igorbinarywave.py. Python because it's easy to drop it into my other Python projects (in this case, Hooke). It's also easy to get a hold of all that useful metadata in a hurry. No writing ability yet, but I don't know why you'd want to move data that direction anyway ;).

Thanks to the folks at WaveMetrics for publishing some good documentation, even if it's in a goofy format.

Peeter Vois's git-php is a nice PHP script which you can drop in to make your public Git repo's browsable. Take a look!

I just wrote up a flexible little HTML photo-gallery generator using Python. I imagine there are millions of these floating around, but I think mine's pretty flexible, so I thought I'd share ;).

I just discovered Selenium, which allows you to drive browers programmatically. This allows you to test the effects of javascript on the browser's internal page representation. Not very useful for the department website, since we don't use much javascript, but I like its python interface, so I'm replacing my traditional spider with a Selenium implementation.

Some bugs I've run into so far:

• start() doesn't take any args. Simple fix in selenium.py.
• captureNetworkTraffic("xml") returns requestHeaders as responseHeaders. Fixed in source, but you'll need to compile your selenium-server.jar on your own. There's a nice, detailed explaination of building Selenium with Maven here, but for the impatient, a simple mvn install in the svn root directory should do it.
• captureNetworkTraffic("xml") captures invalid XML in URL's (ampersand problem). Another simple patch, but this one's just posted by me, so you'll have to apply it by hand and recompile. You get the feeling that people don't use the captureNetworkTraffic side of Selenium very often ;). Ah well, only 3 open bugs in that area left to bump into ;).

To keep the test suite easy to maintain, I build it on the fly using nose generators, which are awesome :).

More details to come...

Recently I've been writing up an article for one of the Elsevier journals using their elsarticle LaTeX package. Unfortunately, their BibTeX style file, elsarticle-num.bst (version 1.1, 2008-10-13), is a bit broken. With the help of Nicolas Markey's excellent Tame the BeaST, I've fixed it up, so it runs without errors (!), works with natbib's \citet{}, and conforms with the examples posted in the International Journal of Biological Macromolecules' author guide.

Update: Oct. 6. Turns out the code linked from Elsevier is out of date. Rishi over at River-Valley (writers of the elsarticle package) pointed me to some more up to date documentation and source. Version 1.2 fixes most of my problems (with elsarticle-num-names.bst), but I'm still not sure why it doesn't replace elsarticle-num.bst entirely...

I've been amusing myself over the past few days working up an email interface for the distributed ugtracker Bugs Everywhere. One of the things we've been struggling with with BE is how end users should submit bugs/comments/etc, since

$ apt-get install bzr
$ bzr branch http://whatever/remote/repo local_repo
$ cd local_repo
$ be new "The demuxulizer is broken"
Created bug with ID 48f
$ be comment 48f
<Describe bug>
$ bzr send --mail-to "whatever-dev@fancyprojects.com"

mostly just raises eyebrows among non-devs ;). My interface replaces it with

$ cat | mail -s "[be-bug] new" "whatever-dev@fancyprojects.com"
The demuxulizer is broken

<describe bug>
^D

Which will hopefully be more user friendly. Of course, most non-devs I know (and some devs) avoid the command line like the plague, so we will still want a web-frontend. Luckily, web frontends seem popular with other devs, so I don't have to bother with that ;).

Curious parties can branch my public repo:

$ bzr branch http://www.physics.drexel.edu/~wking/code/bzr/be-email be.email

As a nice side effect of this little project, my send_pgp_mime is now much more elegant.

NPR coverage over the last few days has been bouncing back and forth between the 20th anniversary of the Tiananmen Square crackdown and Obama's Egypt speech. They featured an interview with a Chinese student. She said she'd read something about soldiers firing on civilians in one book, but didn't really believe it, since other than that there hadn't been any mention of shootings. Sometimes information passes so quickly, and sometimes surprisingly slowly... They also interviewed a history teacher in China, who said he could safely teach about the crackdown, but didn't because there wasn't enough time.

It all reminded me of my grade-school US history classes, which stopped after the 50s, conveniently before the Vietnam war kicked into high gear. We did get some Vietnam coverage in high school, but not much discussion of the protests, e.g. the Kent State shootings. Maybe not on the same scale as the Tiananmen crackdown, but still, the rose-colored history glasses are not unique to China. Not that that makes them acceptable, it's just a sign of how much people dislike rocking the boat. After all, I would certainly rank more Vietnam-at-home coverage above the War of Jenkins' Ear coverage we got in the high school course.

Anyhow, here's a bow to people taking nonviolent stands for what they believe in.

I was running make to build Comedi against the current Hardy kernel, and it died with

...
make[1]: Warning: File `Makefile' has modification time 1.1e+02 s in the future
make[1]: Nothing to be done for `clean-am'.
make[1]: warning:  Clock skew detected.  Your build may be incomplete.
make[1]: Leaving directory `/thor/wking/src/lab/comedi/comedi-build'
make: warning:  Clock skew detected.  Your build may be incomplete.

“No problem,” thinks I, since I'd just rebooted into the new kernel, but I'd pulled the source in under the old kernel. I'll just touch all the files to make sure their times are in the past.

Nope. Same error. Turns out my touch is from the future:

$ date; ll include/Makefile; touch include/Makefile; ll include/Makefile; date
Fri May  8 10:48:35 EDT 2009
-rw-r--r-- 1 wking wking 15540 2009-05-08 10:48 include/Makefile
-rw-r--r-- 1 wking wking 15540 2009-05-08 10:50 include/Makefile
Fri May  8 10:48:35 EDT 2009

This is because my files are NFS mounted from another computer, and the clocks were out of sync by two minutes. Time to setup NTP for the lab LAN ;).