Monday, August 07, 2006

Long Time No Post

Its been a busy few weeks!  But on my flight home from Vancouver I ran across an intereting little brain-teaser I thought I would share.  Suppose a man with two children tells you one of them is a boy.  Given that the probability of a child being either male or female is equal (50%), what is the probability that the other child is a boy?  The answer is so easy it hurt my brain...

Friday, June 02, 2006

Making Pretty Pictures

I was recently faced with the problem of converting a single-page PDF document into a nice high resolution image.  Now I'm sure some company out there has created a fancy expensive tool to do this quickly and easily.  However, I am not the type to spend money on such tools.  Also, I was doing this at work on my Linux box, and chances are most software wont work on this platform.  The question is, are there any tools available for Linux to easily accomplish this?  Turns out not surprisingly the answer is yes.  The ghostcript tool GS is very well suited to accomplish this task.  Just give it the resolution, input file, output file and output type and you get an image with no hastles.
gs -r300 -dBATCH -dNOPAUSE -sDEVICE=jpeg -sOutputFile=moo.jpg moo.ps
I created a nice ruby script to gather the relavant options and run GS for me:

# Need to create commands like this:
#
# gs -r300 -dBATCH -dNOPAUSE -sDEVICE=jpeg
# -sOutputFile=arp-activity-per-20-minute-interval.jpg
# arp-activity-per-20-minute-interval.ps


if ARGV.length < 3
  puts "Usage: ruby imageconvert.rb <input> <output> <output format> <dpi>"
  exit
end

# Get the command line arguements we need
input = ARGV[0]
output = ARGV[1]
format = ARGV[2]
dpi = ARGV[3]

if (!dpi)
  dpi = 100
end

puts "Input file: #{input}"
puts "Output file: #{output}"
puts "Output format: #{format}"

puts "Running: gs -r#{dpi} -dBATCH -dNOPAUSE -sDEVICE=#{format} -sOutputFile=#{output} #{input}"
system "gs -r#{dpi} -dBATCH -dNOPAUSE -sDEVICE=#{format} -sOutputFile=#{output} #{input}"

Thursday, May 25, 2006

Vacation Time!

There is no better place to spend your valuable vacation time than at a car dealership waiting 3 1/2 hours for the maintenance guy to tell you he cant reproduce your problem.  I should have known this would hapend, but I figured they would just ignore my complaint and send me on my merry way after completing the oil change.  At least they updated my car's computer software...how long could that have taken...5 minutes?

In any case, I will be on a real 4 day vacation with my sisters in town starting tomorrow, so hopefully I will find a way to make better use of my time :)

Thursday, May 18, 2006

The Carpet Guy

I made an appointment to get my carpet cleaned last night.  The rude secretary told me that a time slot was available the next day...sweet!  So I scheduled an appointment for 8-10 this morning.  At around 9:55 I was starting to get impatient as you can imagine.  Of course just as I was about ready to leave for work the doorbell rings and hes ready to get busy.  I always love burning 4 hours of vacation time because of someones incompetence.  At least he seemed knowledgable, could speak english, and did a good job with the carpet.  Hopefully Ms. Peanut will be a bit more forgiving on it this time.  Its supposed to be off white, not yellow!

Thursday, May 11, 2006

Post Horsey Mortem

Well my fears of sore legs after the horse riding excursion did not come to fruition. However, there was another sort of pain during the ride but I'll spare you the details. Needless to say, the greatest impediment to me running well in my race the next morning at 8:30 was the lack of sleep and the number of beers I had the night before.

Race Details

In any case, the race was by far the largest I have ever been involved in. The organizers said there were approximately 6000 run/walkers and I have no doubt that this was true. It was truly inspiring to be able to pass so many people at the start of the race. What is better motivation than racing a bunch of slow walking people? Anyways, here are my results...about what I expected.

235 35/103 1992 Rodney Jokerst 26 27:24 24:30 7:54

Now I just need to find one more race to run at the end of the summer...inspiration to keep myself in shape and just enough time to train to be my 24:30 time :)

Wednesday, May 03, 2006

Horsey

I've been getting alot of feedback recently that my horseback riding expedition on Saturday is going to make my 5k race on Sunday miserable. Well, I am ready to take on this challenge. I think my ass is well suited to handling anything a horse might attempt to throw at it. Bring it on. Just be gentle on the other stuff down there.

Wednesday, April 05, 2006

Redhat 9 Sucks


I spent the better part of 3 hours at work on Friday trying to figure out why my Perl script wasn't working. I had an arbitrary collection of binary data skimmed from the network that was perfectly coherent and viable when stored in a hashtable. However, as soon as I decide to write this data to a file, random garbage was interspersed with real data, resulting in a file on disk that was much larger than the file in memory, in addition to it being total garbage. Since my work is on an isolated system, I cant post details of what I was seeing. Nevertheless, it was a very perplexing problem. Perplexing that is until I remembered having a similar problem a number of years ago with Perl on a Redhat 9 system...back when Redhat 9 was relatively new and still in favor with me.

After several futile google searches to narrow down the problem, I decided to try the solution that I remembered from my prior disastrous experiences...open the file in binary mode. Even though the documentation explicitly says that this is only necessary on broken operating systems like Microsoft Windows, this simple modification made my script work flawlessly. I am not in the mood to run this issue into the ground much further since I don't use Redhat products by choice anymore and this work project is nearing its completion. However, I did find out what the culprit most likely was.

At some point around the release of Redhat 9, Perl was going through its transition to Unicode support. Apparently, parts of the system were not completely functional for the Redhat 9 Perl release. In particular, it seems that the print function was converting my binary data to Unicode before writing it to the file, translating certain bytes to the extended form. This would explain why I had extra data in my file on disk. Doesn't make me any happier though :(