In the finally-got-off-my-butt-and-did-it department, I now have a network drive that all of the computers here can talk to. The NSLU2 (network storage minus the storage) I bought two months back has been sitting on my desk with a big USB drive plugged in (under the desk). The NSLU2 runs samba. The laptops saw it right away. The last, lingering step was to get the Linux boxes talking to it. Done. This is the first time since I've owned more than one computer that they've all been able to directly share storage. No more sneaker net or bouncing files off a remote server. The network drive needs its own backup, but that's the easy part.
Everyone is now safely (cough) backed up, and I can get on with the Ubuntu upgrade that my desktop has been nagging me about for weeks.
Is there portable Perl somewhere for producing GIFs or PNGs?
Every month or so, usually in different environments, I need to produce data-drive graphic for some web app. If I'm lucky (which has been about 25% of the time), GD will be installed. If I'm not lucky (again, about 25% of the time), I either can't acquire admin rights on the box, or can't marshall all of the pieces needed to build GD, and then burn up time doing some kludgey one-off. The in-between 50% just takes time.
This time, I scratched the itch by finding a half a page of pure Ruby for generating PNGs, and did the data analysis and graph production in another two pages of Ruby.
There's gotta be a way to painlessly convert bits to some web-friendly image format in Perl.
For the holidays, I gave myself an NSLU2, (AKA "Slug"), which a small, fanless Network Attached Storage device minus the storage, which attaches via USB. (The picture doesn't do it justice; the Slug is about the size of a moderately thick paperback book.) NSLU2s go for about $85 USD if you shop around.
The same folks who cracked the Linksys Router also figured out how to flash a new Linux into the NSLU2, yielding a tiny (albeit slow) Linux box that draws about 9 Watts and is absolutely silent. There's a thriving hacker community, which has come up with several hardward mods, including which resistor to clip to double the lock speed of the ARM chip from 133Mhz to a whopping 266Mhz.
I'm going to migrate several periodic tasks (e.g., network backups, periodic scraping of some web pages, etc.) onto mine, which will further plans for a silent home office by freeing up an older, larger, noisier box.
Go, Uninterruptable Power Supply!
It's not too late to ask Santa for one (or two). One of mine is getting on in years, so I'll take advantage of post holidays sales to replace it with something beefier.
AirWave is a late stage startup with customers who love the product. (Here's a recent product review.) The team has been doing Agile (XP, tuned for local conditions; serious Test-Driven Development) for several years. As one indicator, we have 25% more test code by volume than we do product code. It's the best, most productive team of this size that I've ever worked with, and I'll miss them. If you're looking for a great team to do great Perl work, drop 'em a line, or feel free to ask me questions out-of-band (dws at davewsmith dot com).
You know you've worked with someone long enough when you can tell from a subtle change in their tone of voice that they're about to speak a silly idea.
It's surprising how far you can get in one day by starting with
use constant STARTING_URL => 'http://localhost//notyetbuilt.cgi';
my $agent = WWW::Mechanize->new();
ok( $agent->status, 200 );
and then writing just enough CGI code to make that first little test pass, and then by writing the next test, and then writing just enough code to make that pass, and so on. Tiny step by tiny step.
By the end of the day, what looked like two days of work is nearly done, with good functional test coverage. Add unit tests on the other side, as appropriate.
Replace Test with Test::Simple or Test::More as your preferences dictate.
A shout out to Andy for a fine piece of work on WWW::Mechanize, which made quick work of driving form development.
We had one of those "This can't possible fail, we didn't change code anywhere near there!" unit test failures today while doing a full test suite run after spending the day on a story card. The failing test file hadn't been touched for a while, nor had the code it was testing. But when I ran the test file by hand, it passed. Uh oh.
Long, hard experience has shown that 98% of the time this happens, there's some obscure interaction that's been missed or forgotten, or some other test just happens to leave the system in just the right (wrong) state to expose some wacky interaction.
Then there's the other 2%.
It turns out that our test harness uses file to determine how to run an individual test file. (Most of our tests are in perl scripts; a small few are something else.) And a nightly automatic update had just upgraded the database that file uses. Now, if 0x200 bytes into a file the characters "MP" appear, file identifies the file as some Apple block file thing, regardless of whether the file starts with #!/usr/bin/perl. And on this one particular test script, 512 bytes into the file...