« June 2008 | Main | August 2008 »

July 2008 Archives

July 10, 2008

Logs

There's a recent thread on the DR-ED mailing list about student logs. One administrator talked of how they took their student logs so seriously that made the submission of logs required for graduation.

As a student I have to say, I find these logs a rather odd thing. Most students I know (and I'm including multiple schools here) fill these logs out just before they're due and forge whatever requirements they don't recall actually accomplishing.

Logbooks started on ships in the days of celestial navigation. They used the speed of the boat, which they determined by dropping a log in the water, tied to a rope with knots. The log would float and the number of knots that landing in the water in one minute would be recorded in a book. The logbook. In the days of celestial navigation beyond sight of land, it was vitally necessary to keep track of every compass heading, every rudder and sail order the officer of the deck gave, along with the time of each of the ship's clocks (which varied quite a bit more then than now) in order to make an educated guess about where to start your celnav calculations. This became the deck log. Even after the advent of mechanical measures of speed, the deck logbook stuck around.

Having been an officer of the deck at sea, I signed the deck log for orders I gave at the end of every watch. I reviewed the deck log to ensure all routine entries were made (like soundings, etc). I reviewed the Captain's standing orders in the back of the logbook every month, but I didn't review logs for learning, I don't know anyone who did.

The deck log proved to be quite useful, not only for navigation, but for reconstructing battles, resolving admiralty claims (collisions, piracy, and other legal affairs of the high seas), and, once steam was introduced, maintenance on engines.

When I was the engineering officer on duty on my ship, I logged the state of the ship's plant routinely, logged my changes, and signed my orders at the end of each watch.

Logbooks came to be used to record the vital signs of other machines, including machines on land, again, for maintenance. It was a short step for early aviators to appreciate the value of recording flight hours and cycles, along with their navigation numbers, in logbooks.

The aviators took their logbooks into space in the 60s.

I don't know who introduced logbooks to surgery residencies, but we can still appreciate how the number of cases a surgical resident does still has can have a life-or-death impact, and so those numbers should be closely tracked. If I had to guess, they were probably introduced by some military surgeon after WWII, like DeBakey.

Logs are now kept by computer. Not only in the Navy, but, as a sysadmin, my computers keep automated logs of network traffic and reports from applications. I review them for unauthorized access attempts (china is the most common attacker, about twice a week), recurring system errors that suggest I need to tweak something, who's accessing the system, from where, etc. I review debugging logs if a new application doesn't work right. On navyhpsp.net, I review the recent activity log for wiki spam and implement security to combat it.

Once I redesigned the Draft Log of the USS Wadsworth. The ship's Oil King recorded the level of every single water, fuel, and oil tank, every day. He gave that to me as the repair officer, to calculate the ship's displacement, pitch (bow up, bow down), and hog (bow and stern down, light in the middle, or bow and stern up, heavy in the middle). I put all the calculations in his spreadsheet and from then on, the Draft Log printed itself. Saved me two hours a day at sea.

Logbooks were never intended as learning tools. They were intended to protect life and property. If some old salt recounted how reviewing a log was a powerful learning experience, then they were surely cherry picking their anecdotes, for example, appreciating the value of the standard practice of taking more frequent soundings after crossing the line of demarcation inland if, on some occasion, they forgot and found themselves in shoal water. Reviewing the log while the tug was hauling him back to the channel, might cue have cued him in on where things went wrong. But that was never the log book's primary function, and that sort of in-the-incident learning will never be captured in a medical student's procedure log.

It seems to me that, at best, these student logs are intended for some sort of survey database purpose that has not materialized in any meaningful form. I'm sure you can find some students who will happily tell their professors that their logbooks were wonderful ideas and changed the way they experienced medical school. This is like Clarence Thomas asking Anita Hill if he treats her fairly. "Yes, sir, absolutely, sir." The most functional answer I've heard, and I'd been hoping to hear something better in this thread, is "LCME wants these numbers." One of the more laughable reasons I've heard is "It's important for you to learn how to code". Based on what I've seen from faculty and residents at work, these student logs, even those that do require ICD-9 codes, are not the same as coding. In fact, I've found Google to be the best way to find accurate codes for things I haven't memorized.

So what life and property are these student logs protecting? What analysis are you doing with these logs, which are so often taken on paper? How are those analyses getting back to the students? What thought, what sentence do you believe these logs would spark in a student's mind that would constitute learning? Threats of expulsion seem to me to be good only for promoting a culture of gundecking, the forging of logs. And gundecking has sunk many a ship.

July 16, 2008

Setting up Mailman in CentOS 5

The first thing: use the repos. I didn't see an svn checkout, and a simple make install is going to have dependency errors. The one I recall was something about python.

Next: note that the install goes to /usr/lib/mailman, not /usr/local/mailman

The biggest thing is that CentOS splits the contents of mailman's default "data" directory across two system directories, /etc and /var/lib. The contents are split as you might expect.

/etc/mailman/adm.pw
/etc/mailman/aliases
/etc/mailman/aliases.db
/etc/mailman/creator.pw
/etc/mailman/mm_cfg.py --> /usr/lib/mailman/Mailman/mm_cfg.py
/etc/mailman/sitelist.cfg

/var/lib/mailman/archives
/var/lib/mailman/data
/var/lib/mailman/lists
/var/lib/mailman/spam

You will need to know one or another of these tidbits in virtually every chapter of the install guide.

I recommend you make your first list a 'test' list, because it's likely to be broken. And you remove a list like this:

bin/rmlist listname

If you want to remove the list contents too,

bin/rmlist -a listname

One problem I ran into, was that another admin had set up a relayhost to the university's smtp server, which is stunningly slow. Hours -- try troubleshooting mail when every test email takes *hours* -- you can't. I didn't even realize that I *did* have everything working correctly the first time until I had reinstalled mailman several different ways and finally, the very first test email came through. Gotta love the university's Microsoft Exchange server.

July 23, 2008

Journal Club and Surgery subreddits

For anyone who uses reddit for their news, I started a couple of subreddits: Journal_Club and surgery.

About July 2008

This page contains all entries posted to The Haversian Canal in July 2008. They are listed from oldest to newest.

June 2008 is the previous archive.

August 2008 is the next archive.

Many more can be found on the main index page or by looking through the archives.

Creative Commons License
This weblog is licensed under a Creative Commons License.
Powered by
Movable Type 3.34