The first script, 'aaa_dbcount.t' is roughly:
foreach database
open "$dbname.count.txt"
foreach table
print count(*) into "$dbname.count.txt"
And 'zzz_dbcount.t' is roughly:
foreach database
open "$dbname.count.txt"
foreach line
get count(*) for the table
is($old_count, $new_count)
The tests in zzz_dbcount.t fail when a test that runs after aaa_dbcount.t doesn't clean up after itself. This prevents one run from affecting the next one which can be a very difficult bug to catch otherwise.
When a failure happens I can use the tests to narrow it down. I pick a suspect and run:
make test TEST_FILES="t/aaa_dbcount.t t/suspect.t t/zzz_dbcount.t"
I've thought about doing something that looks at the writable areas of the filesystem too. I bet that would have caught a nasty bug in Krang that I noticed by accident recently - deleting a story deletes the published files (good) but leaves behind empty directories (bad).
So why not wrap this up as a Test:: module? I might but it's a very small amount of code and abstracting "foreach database" and "foreach table" so it'll work across DBD drivers seems hard.
-sam
Enter Greasemonkey, a plugin for Firefox which allows you to add Javascript to a page based on a URL match. I took the Javascript I already had in my link, converted it to a Greasemonkey user-script and now I see author names in Meerkat without any effort on my part. Fantastic!
For the record, here's my user-script:
// ==UserScript==
// @name Meerket User Names
// @namespace http://sam.tregar.com/userscripts
// @include http://www.oreillynet.com/meerkat/*
// ==/UserScript==
(function() {
for (var x = 0; x < document.links.length; x++) {
var l = document.links[x];
if (l.href.indexOf('~') != -1) {
var name = l.href.substring(l.href.indexOf('~'));
name = name.substring(1, name.indexOf('/'));
l.innerHTML = '[' + name + '] ' + l.innerHTML;
}
}
})();
-sam
The new system will allow Krang to mature into a true application development platform. Addons will be installed into their own space under addons/. This has two important advantages: 1) it will keep addons from accidently or purposefully overwriting Krang source files (and vice-versa) and 2) addons can be developed in-place under version control.
Fixing these two issues should make developing add-ons a lot more pleasant. But the new design doesn't stop there - it also brings Krangs build system to addons so they can come with their own dependencies. A new class factory system will allow add-ons to selectively extend core Krang classes without needing to alter Krang's code. Finally, Krang's left-nav area will be modularized so add-ons can register new entries without having to completely override the navigation templates.
The new system should land in Krang v1.103 sometime later this week. I'm off on a branch for now so v1.102 can get out the door without more QA.
-sam
To solve this problem I wrote a script which uses wmctrl to raise a window on the current desktop by name. Here it is:
#!/usr/bin/perl
use strict;
use warnings;
my $what = shift;
die "Missing what arg." unless $what;
my $desktops = `/usr/local/bin/wmctrl -d`;
my ($active_desktop) = $desktops =~/^(\d+)\s+\*/m;
die "Unable to determine active desktop!" unless defined $active_desktop;
my $windows = `/usr/local/bin/wmctrl -l`;
my ($id) = $windows =~/^(0x\w+)\s+\Q$active_desktop\E\s+\w+.*\Q$what\E/m;
die "Unable to find $what on $active_desktop!" unless $id;
system('/usr/local/bin/wmctrl', '-i', '-a', $id);
I called it raise.pl and call it like:
$ raise.pl emacs
Then to finish the job I edited the Metacity configuration to bind Alt-e to raise Emacs, Alt-f to raise Firefox and Alt-s to raise the terminal (shell). Mission accomplished!
(Of course, all this would be much easier if Metacity supported a scripting language like Sawfish did. I miss Sawfish...)
-sam
The thing is, it's missing something: tests. I still have to switch to a terminal every time I run my tests. Ideally I'd like to bind a key to run 'make test' on the project and see the results in a buffer. Syntax highlighting would be icing on the cake.
Anyone know of something I can use for this? I tried M-x compile but the Test::Harness output looks horrible in it. Googling around and looking in the Emacs Wiki didn't turn up much.
-sam
-sam
The big draw last night was a chance to meet David Wheeler. I worked with David on a nearly daily basis for over a year on the Bricolage project without ever meeting face-to-face. Aside from our running MySQL vs PostgreSQL "conversation," the meeting was a pleasant one. Things got a bit ugly when someone asked David for a "three sentence description of Krang" but I can't honestly say I would have handled a similar question about Bricolage with any greater sensitivity!
I also got a chance to talk to a couple guys working on Phalanxing HTML::Template. I'm looking forward to their contributions with a mixture of embarrassment and hopefullness. I'm sure better testing can only help, but that's some very old code and more than a little gross. Oh HTML::Template version 3, when will I write you?
-sam
I also updated my onchange script to do a recursive walk when passed a directory. I don't know if anyone else uses this script but I find it terribly useful.
-sam
Now, for a second act, I think I'll go post my picture on Am I Hot or Not.
-sam
I honestly couldn't be more excited about this for many reasons. To name just a few:
-sam