« April 2004 | Main | June 2004 »

May 29, 2004

Mike Benson wins Evvy Award for Manilla Sky Short

A friend of mine just finishing his studies in film at Emerson College. Each year they have something like the Emmy's, called the EVVY Awards, which is apparently a pretty big production, in the world of student-run productions.

Mike won Best Film for a short he did called "Manilla Sky." Mike does a good deal of his filming (the ones I've seen) on old black and white, hand operated and manual exposure cameras. Hard work.

The point of this entry was to provide a link, but I can't seem to find the film online (I know Mike put it up somewhere). Will track it down and update.

Posted by mike at 10:14 PM

May 28, 2004

No More Self-Maintained Private Network

Today marks the removal of the self-installed private network between our machines. A few months back I had put a Cisco Catalyst 2950 between our machines to make it easy and secure to move MySQL data between machines.

Shortly after the networking group recommended we request a private VLAN and let them be responsible for managing the private network. In December the VLAN was ready for use and with a server change this week our data is now all moving across the VLAN.

On my way home I stopped by the data center and pulled out the remaining cabling and switch. Interesting, it was put in 1 day shy of exactly a year ago. Even though we have no use for it (probably sit in a closet gathering dust for the next 10 years), it was worth the ~$1,000 to have machine cpu freed up from encryption for the past year.

Posted by mike at 10:36 PM

May 24, 2004

What Difference Firewall (ipf) Makes in HTTP Performance?

Getting ready to put a new machine into service with a reconfigured set of ipf rules, wanted to see just how much a difference the firewall made in performance. Seemed like a good time, as nothing else is happening on the machine and could actually get some fairly reliable results.

If I pound on the server with thousands of HTTP requests while ipf is up we're serving out pages at an average of .33 seconds. When I turn off the firewall and make the same set of requests the pages get served in .32 seconds, meaning we are .01 seconds faster without the firewall.

Seems like an agreeable hit for having the firewall up. The latest config changes were to utilize ipf's rule groups, which means packets are seeing a small subset of the rules once ipf determines the direction and service. Each of our machines has several network interfaces, and require ~150 lines of ipf rules (varies depending on the machine's purpose).

Posted by mike at 6:23 PM

Stupid Maxtor Return (RMA) Process

One of the hard drives in a Linux box next to my desk started making this loud clicking sound the other day. Sure enough, the drive is hosed. It's a Maxtor DiamondMax Plus 9 120G ATA/133. Pretty sure it was whatever was cheapest at the time.

Having had good experiences with fujitsu and western digital RMAs, I hoped that Maxtor had a similar process. Almost, with the exception that rather than letting you assume the risk that the hard drive might not be bad and paying the shipping, they *require* the diagnostic software output as a part of the RMA process.

Even more annoying, the PowerMax tools are only available for Windows. The tools is actually a small executable that creates a boot floppy. What if I'm running Linux, and on a box that doesn't have a floppy drive? Just getting my hands on an unused floppy took 20 minutes and digging around a supply closet on another floor.

I found an available Windows box to go through this process, 2 hours later I'm back to putting the RMA together online. Now as I'm re-entering (session expired) the information I discover that the PowerMax diagnostics info is only required if you give a soft answer to what's wrong with the drive. I had chosen "bad sector," but if I choose "drive makes noise" the diagnostic code is bypassed. Grrrrr.

For future reference when filling in the Maxtor RMA either choose "drive makes noise" or use diagnostic code de67a669 (hopefully that's not unique to the serial number of my hard drive).

Posted by mike at 1:19 PM

May 20, 2004

I May Need a New Video Camera

Lately, I have found more and more that I'm using my PowerShot s400 as a "video camera," to catch live action. It's a great digital camera, but by no stretch of the imagine should it be used for making movies.

We have a nice Canon Hi8, but the bottom line is that if I want to make a DVD for someone, or myself, I've got to go through some complicated capture process. Stacked up against the ease of getting video from the s400, Hi8 loses.

The s400 creates .avi files that I can bring right into iMovie (thinking about Final Cuth Express) and in no time have something ready for iDVD.

Of course I'm convinced I'll need something with 3+ CCD.

Posted by mike at 11:35 PM

Day+ Trip to New York City

Took today off to spend it in NYC. It's been too long since we've gone. Much too long.

We drove to Milford, CT on Wednesday night and stayed at the SpringHill suites (accomodations we're as expected). Got up this morning, swam in the pool for an hour and then drove into Manhattan. We took a semi-new route, across the the Bronx and Manhattan on the Cross Bronx Expressway and down into the city on 9a (Henry Hudson Parkway). The 9a stretch was pretty cool, runs right along the Hudson, lots of green grass, biking trails etc. Dropped us into the upper east side.

Had lunch at Lincoln Center (this trip was on the cheap, all meals were pb & j and homemade cookies), took a tour of the almost completed LDS Temple (beautiful) on 65th and Broadway and then walked the two blocks to Central Park and spent the remainder of the afternoon running on the grass.

The trip back was uneventful except for a frustrating amount of traffic on the Cross Bronx Expressway and in Connecticut which eventually got so annoying we stopped for an hour and played/ate (more pb & j) for an hour until traffic was moving.

I liked taking a mid-week trip, not stacking it up against a weekend. Somehow it was more enjoyable knowing that we still had the weekend to get things done.

The trip was a reminder of how much I love being in New York City. Found myself wishing that somehow circumstances would change and moving there would make a lot of sense (currently, moving to NYC makes no sense). We did agree that we'll be back soon and will allocate more than a single day.

Posted by mike at 11:15 PM

May 19, 2004

Annoyed at Decision to use Storable.pm

Today I'm doing a bit of testing on a new server, built with the latest version of everything.

It's becoming a headache that somewhere in our history the decision was made to take information from a web form, freeze it with Storable.pm and save it in the database for future reference. The first time this caused a problem was when we moved from perl 5.6 to 5.8, all of the entries had to be pulled out with 5.6 and saved back using 5.8 (also changed from 64 to 32 bit Perl).

Now we're having an issue because I want to test a new server, with a new version of Storable. After testing against a dev database I wanted to point the new machine at the production database, but realize that any testing I do will render that data useless on the real production machine which is back a few versions. I guess will just have to wait and hope, and worry.

The more I look around at the code the more I can see the reasons for using Storable, but the reasons don't make it possible to test against production data.

Posted by mike at 5:09 PM

May 18, 2004

Change File Permissions on Apache-created Files

I've been digging around trying to find an answer to how to get apache to create files with different permissions. We sync the files between a few machines using another user, and need apache-created files as rw-rw-r-- (default seems to be rw-r--r--) so they can be overwritten by the rsync user (who's in the apache group) if the file is updated on another machine.

I couldn't find a clear "this is how you do it" but a lot of suggestions about using umask. I added umask 002 to /etc/init.d/httpd, restarted apache and now files are created rw-rw-r--, just like I wanted.

A little too easy . . .

Posted by mike at 4:27 PM

May 13, 2004

Switching Method Naming Conventions in Perl

We're in the process of redoing a core library (base module for 75% of our code). Up to this point we've always used underscores in method names like get_version() and set_primary_key(). The new version of this library is written using a different style: getVersion(), setPrimaryKey() (also known as lower CamelCase).

I'm troubled. I think because I associate the underscore naming convention with Perl and wouldn't want to do anything that isn't unPerl-like. I searched a bit but didn't find any concrete documentation saying such. A recursive grep through our code reveals we've got 3373 methods, 2617 of those have an enderscore separating words in method names and 87 use lower Camel Case (mostly in the new library). An egrep of /usr/local/lib/perl5 reveals 11290 methods, 4188 methods with separating underscores and 320 with lower CamelCase (2-3% in both our and CPAN code).

I think more important than being Perl-like is being consistent in naming. Moving to CamelCase means that we've got a noticeable difference in our code. That could be good in the sense that the next generation of our code has a new naming convention and is easy to separate from the old. It could also be bad in the sense that we're having to use different styles in code that references newer code and older code. It could be good in that to migrate dependant code the code will break until it's updated. That could make a lot more work, but I think we're convinced we want to redo the module without any gaurantee of compatibility (gives us freedom to do things right, even if it breaks stuff). Either way, unless we plan to rewrite everything, it will be ugly to have intermixed styles (not that our code is pretty without it).

Sounds like an excellent conversation for our next developer meeting.

Posted by mike at 8:45 AM

May 11, 2004

Hold the Button - Don't Waste Your Time

This is really stupid, a site that pits you against everyone else to see how long you can hold your mouse button down? Yes, I pushed the button. I even held it down for a few seconds. Realizing it was idiotic and a waste of time I decided to stop but accidentally bumped the right mouse button (I was trying this on an unused Windows box at the office) and realized that the counter kept going after I had let go of the "button," somehow confused because there was a right-click menu open.

I let it run over the weekend, and now am wasting more of my and everyone else's time by posting about it. Please resist the urge to try it, you'll only end up wishing you had your time back (even if it's 30 seconds).

Posted by mike at 7:27 AM

May 10, 2004

Using CIDR Notation for Netmask

Today I'm writing a script to generate firewall config files for a handful of servers that fall into a few functionality groups (each requiring a specific set of rules). ipf, which seems to be the Solaris firewall package of the day, accepts both CIDR notation as well as dotted decimal for specifying the netmask. We use CIDR, makes for a more readable conf file. Thought I'd dig up some documentation for reference when making changes to the rules.

A.B.C.D - host (/32)
A.B.C   - class C (/24)
A.B     - class B (/16)
A       - class A (/8)

Gaurdian Digital covers it in more depth.

Posted by mike at 1:50 PM

May 7, 2004

Not a single line of code in 4 days

My streak continues, spent another day doing administrative work and not a stitch of coding or sysadmin. Thought I'd make a list of activities so I can review exactly what it is that's keeping me from working on my real projects.

- put together and request quotes for new hardware (several different machines)
- push server requests to purchasing
- negotiate 2004-2005 service contract for hardware (conference call, numerous follow-up messages)
- fill out and submit matching grant application
- request nagios coverage for new machines
- request backup for new machines
- complete business impact analysis survey for consultants
- meet with consultants
- get up to speed with a couple new mailing lists (apache, perl)
- work on documentation for installation of our software
- make estimate for hours to bring server in South Africa up to date
- initiate working with networking, operations and university systems group for building disaster recovery server to live off-site

Amazing how fast time gets eaten up.

Posted by mike at 11:33 PM

May 6, 2004

Today's Meeting with Bob and Bob

After bragging about being freed up to code I'm now three days of solid administrative work.

Today included a meeting with some consultants hired by a group at the university to determine just how critical different IT systems are. Let's just say their names were Bob and . . . Bob. It's been awhile since I've seen Office Space, but it sure felt like the conference room scene with the consultants.

The consultants I met with today aren't here to determine what or who needs cut, but what systems will get priority in case of a disaster. We were pleasantly suprised that their assessment of our service to Tufts was actually phrased in a way which made it seem more critical than we would have indicated.

Now I've got the urge to watch the Office Space, and Netflix is fast, but not fast enough. Guess it's time to get a copy for myself (perfect thing to do at lunch tomorrow).

Posted by mike at 11:14 PM

May 4, 2004

A Good Meeting with a Manager Does Wonders

I recently had a meeting with my manager that has created a noticeable change in my level of stress and productivity at work (stress down, productivity up).

It's not that we (manager and I) don't meet often, in fact it's the opposite. Rarely a day goes by that we aren't meeting at least once, sometimes more (and then there's the days we're meeting before and after other meetings to discuss what happened in the other meetings).

Last week I was asked to put together a list of projects up for consideration after our (dev team) current projects. This implies that each developer has one project and will move on to one other project when the current one is complete. Not true. The project list has never been small. When I started (the first full-time developer) there were several dozen projects waiting. The dev team has grown to three, but the project list has grown even faster. What we're faced with is not a single current project, but the 6 *critical* projects with promised deliverables and a dozen other things that are pretty important. And if that's not enough, the priorities can change depending on who's complaining the loudest.

Back to the good meeting . . .

In the meeting with my manager to discuss the projects, I was firm in wanting a reasonable list and some concrete priorities. It took some work, but I walked out with 4 things on my list to have completed by Aug 31, and some priorities for each item. After thrashing between so many competing demands for such a long time I just can't say enough how good it feels to have a visible road map. So nice to tackle an issue and actually get to remain with it for long enough to make a good coding decision or two.

I got the first project into alpha testing in a fraction of the time I thought it would take, and am pretty pleased in the organization of the code and coding.

My next project is shibboleth, which I've ignored since I got it built in January.

Posted by mike at 9:59 PM