darkness

Got the new Internap T1 connected to a new Sangoma 514/FT1 (PCI T1 serial card with built-in CSU/DSU; in other words, straight from the demarc to the card). Working great, and though the firewall keeps locking up user space, I was able to power it off (no clean shutdown), stick the card in, boot it up, and basically it worked. I had a little oopsie where the card didn’t get an IRQ because I still had the BIOS — yes, the BIOS — configured to think there was a PCI IDE bus master controller in that slot. Another reboot, though, and we were off to the races.

After I got the Internap T1 up so they could test it (which I think means “ping your serial side IP really fast”) I started building a new firewall. I selected an Asus A7V266-E (IIRC; either A7V or A7M) and an Athlon which runs at 1600MHz. What really shocked me is that I was basically able to get this board to work on the first try. Usually I have to end up mucking with something, changing BIOS settings, fucking with jumpers, reseating processor, getting new memory, etc. The only thing I had to do on this board was download the manual so I could figure out where to plug in the LEDs and such. It’s still up and running, so I must not have screwed up too badly. Or so we hope; the real test will be when I stick the T1 cards in there and replace the old firewall with this new firewall tomorrow.

I did a Red Hat minimal install. It was something like 260 packages, 450MB. Included some things I felt were a bit questionable, like audiofile, but I presume it was used by some management/configuration tools they feel the need to include in a minimal configuration. I immediately put APT on the box and now I’m happily installing things as I come across them. All the Perl RPMs I built for pipt installed from my custom package repository, and their dependencies even worked. Seriously, if you need to package some Perl modules, use cpanflute2 (see yesterday’s entry).

Did some coding tonight. A last bit of refactoring on code created by my first engineering task, then went on to creating the test for my second task. The test code for the second task looks much nicer than the first test case I wrote. Indeed, they will likely end up sharing some code. I just realized, though, that this most recent test case assumes that the first (only other) test case I’ve written has already run and completely successfully. If the class that test case tests is not running correctly, this test will fail as well. Probably not bad. I could probably either use a method for specifying dependencies between tests (not likely) or maybe I should combine them into one TestCase class. XP leaves out a bit about how your test cases should actually be constructed. Somehow I got it in my head that every class has a corresponding TestCase class when using JUnit. Then I remember that I was reading about how ParallelInheritanceHierarchies are a code smell. Oops, just spotted ExpensiveSetUpSmell. Me thinks I have a bunch of refactoring ahead of me, not including what I think might be some broken interfaces I’ve based my Producer class on. Sigh.

Listening to “Romeo and Juliet” soundtrack. I love this album.