Verse Of The Day

Tuesday, August 28, 2007

Crazy Women Drivers

We went to a picnic a few weeks back, and my wife got to "drive" a horse-drawn cart. Here she is with our friend Anita driving the horses.....

Wednesday, August 08, 2007

A Few Notes on my Load Tester Ruby Script

A few days ago I posted a Ruby script I use to simulate multiple users hitting a web application. I have a few notes regarding that script:
  1. There is a minor bug in it, that doesn't affect functionality so much as the "logging". I used a global var like a dummy and then reference that in the threads.
  2. I also added a 3rd command line param to tell the script how many times each thread should run through the list of URL's.
  3. I also added a sleep() feature so each thread will pause between each run through the list of URL's. Right now that is just a global var instead of a command line param.
I will have to repost the source to get these changes up here. (Actually the *.rb source file is up, I just haven't regenerated the HTML yet.)

On a related note, I wanted to do a better simulation of the types of requests coming through to our prod box. My clever idea, take the actual requests out of Apache's access_log or (in my case) ssl_request_log.

So how to easily grab all those requests to build my file? The format of my ssl_request_log looks a bit like this (some stuff renamed to protect the innocent):

[08/Aug/2007:14:42:23 -0400] SSLv3 RC4-MD5 "GET /appcontext/en/US/CZN2/css/main.css HTTP/1.1" -

Well I just want the URI starting after the GET, so from the Linux/Unix/Cygwin command line do something like this....
$ cat ssl_request_log | cut -d' ' -f 7 2>&1 | tee URIs.txt
Then in vi, I can just put the "http://myserver" portion of the URL at the beginning of each line with a global replace, and I'll have a file with every request, including those for images, stylesheet *.css files, javascript *.js files, etc.

This is much easier than sitting here trying to piece together URL's by hand.

Monday, August 06, 2007

A Great Interview Question

I had to do a few interviews last week, and some of my standard questions were getting a bit stale. So I went out on Google and searched for some new ammo.

I came across this question: "What is the difference between final, finally, and finalize()?"

At first I thought that was too easy, mostly because I knew the answer, and it seemed fairly obvious. Even so, I broke it out in an interview, and the guy nailed the first two, missed the last one.

I was relating that tale to a coworker afterward, and she said, "what was the question he missed?" She nailed the first two, didn't know the last. She's a good programmer; I've worked side by side with her every day for the past few years, and she missed it. That's when I came to the conclusion this is a great question.

Even good programmers don't know everything, and not many Java programmers really have to get into the bowels of memory allocations and garbage collection. This is a great question, not because I want the guy who can answer all 3, but because I want to see how people handle themselves when they don't know the answer. Sometimes that will tell you more about the person than if they just know all the answers.

The first guy I asked this question got the first two 100% correct, then he flat out said he didn't know what finalize was, hadn't run across it, and then he wrote it down in his notebook and said he would have to look it up.

The second guy I asked, he missed it, but didn't seem to know he missed it. For finally, he stammered about a bit and mentioned it was for garbage collection, then switched gears a little and said you usually use it with a try/catch block. Then for finalize, he said he didn't know what it was.

So both missed it, but was one answer better than the other?

In my mind, first guy won. He admitted what he didn't know and showed some level of ambition to look it up. The second guy tried to dazzle me with a little BS for a minute before admitting he didn't know. He didn't write anything down or mention looking it up, he just racked it up as a missed question.

They both went on to answer other technical questions to my satisfaction, but I came away with a slightly difference perspective of each. If they both just nailed every tech question I threw at them, I wouldn't have that added bit of perspective. And how do you know it isn't just "book smarts" -- a lot of those guys that rattle off every new buzzword and argue about architectures and design patterns can't write code to save their lives.

Other Interview Follies:

A lot of funny things do happen when interviewing. Everything I have ever learned about interviewing seemed like common sense, until I met some of these folks:
  • One of my manager's standard questions: "How would you structure your ideal work day?" (e.g. 50% development, 20% support, etc.) One guy told us he would sleep in, get to work late, of course he would stay late also, but his brain just doesn't work in the morning unless he has 10 cups of coffee, so he would rather sleep. Honesty is NOT always the best policy.
  • One lady told us she mostly does front-end work. When I asked her what she was using to build the interfaces (Swing, JSP, JSF, etc.), she told me she mostly does back-end server work. Nice 180, thanks for coming in today!
  • Another guy just got done telling us about all these web applications he wrote, JSP's, servlets, etc. I asked if he was using STRUTS, and he told me he wasn't sure, he might be using it. Then when I asked what application server he was using, he said UNIX and Windows. I tried to clarify, asking him which J2EE server he was using, he looked confused; so I changed my terminology to "servlet and JSP container", he still looked confused; so I made it multiple choice: "Are you using Websphere, Weblogic, Tomcat, Jboss?" His final answer: "Tomcat sounds familiar."

Wednesday, August 01, 2007

HTTP Load Tester Script in Ruby

Here it is, after running my newly acquired Ruby code to HTML converter script, I am finally able to post decent looking Ruby code. Just not directly on Blogger (yet).

Here's the link to my HTTP "Load Runner" script I have been using to debug certain issues (memory leaks, database connection leaks, etc) with a certain un-named inherited application. It's written in Ruby.

For the more hard-core stuff I use JMeter, but this served two purposes:
1. learning more about Ruby
2. having a quick and simple script for small stuff instead of the heavyweight JMeter.

Ruby Source:

Making Code Pretty For The Web

Any time I post code to this stupid blog, I always run into the same issue. How to make it look like readable code? Seems that just putting code inside <PRE> tags doesn't seem to work -- something about the Google / Blogger engine mangles the crap out of the end if it gets "too long".

For Ruby at least, I just found this blog entry that helps out immensely. It's missing a step, as it assumes you have Rio already, but it was easy enough to figure out.
> gem install rio
> gem install syntax
Then save that Ruby script off locally and run it against your script file. Include the CSS or just add it to the HTML inside <STYLE> tags and you're golden.

Of course, the braindead Blogger engine doesn't seem to be picking up the stylesheet, so the code doesn't appear as pretty as it should -- no syntax coloring or anything. I'll have ot figure that out before I post my HTTP load runner script.