How To: "Watch" a PSQL table from the command line

Follow this procedure to use watch with a psql query from a Linux command prompt:

• Create a .pgpass file as follows:
  • vi /root/.pgpass
    
  • Fill in the file as follows:

*:*:<username>:<password>

• Execute the command:

chmod 0600 /root/.pgpass

•  Execute the command:

watch 'psql -c "insert_query_here;" -U <username> <database_name>'

Discovering the PID of a running shell script

I recently needed a way to script the shut down of several bash scripts without killing all of the bash processes. I did not want to search through a series of ps axf | grep commands to kill each script one-at-a-time. I found this helpful tip on stackoverflow in relation to a similar question about Java:

# ps --no-headers -C scriptName.sh -o pid


This returns a list of PIDs, which can then be easily incorporated into a script with something along these lines:

for X in $(ps --no-headers -C scriptName.sh -o pid)
do
   kill -15 $X
done

Truth in Testing

My company's products deal with, among other things, enterprise video. Over the past couple of years, I've become a little maniacal about video quality. The problem is that video quality is, for the most part, a subjective measurement. Sure, you can quantitatively measure dropped frames, the percentage of pixelation, ghosting, mosquitoes, or other artifacts in a given frame. But at the end of the day, what is actually acceptable to end users will vary greatly from viewer to viewer.

My test group recently found ourselves inviting engineers and managers to a meeting specifically to demonstrate and discuss what we felt were significant problems in the video quality of an unreleased product. These problems would not be noticeable to most casual viewers, and it was sometimes difficult to articulate the exact nature of the bugs in writing or orally. These bugs had previously been discussed in many meetings, with some engineers feeling that the problem was more serious than others. My biggest concern was that the existing video quality would be deemed "good enough," that others would not agree with my opinion that the bugs were serious, or that the conversation would degrade into an argument over the definition of what was "acceptable" video. I was mentally preparing for a fight.

Somewhat to my surprise, getting all the key players together in the same room and simply watching the video with minimal commentary was sufficient. The facts--the problems that were easy to see though difficult to explain in writing--made argument unnecessary. A consensus was reached which largely backed the view of testing. The decision was made to address the problems prior to shipping the product.

I was reminded that record keeping and honest reporting of facts are critical to good testing. I sometimes allow my emotions to get wrapped up in a bug: I interpret any insinuation that the bug is not significant as a deficiency in judgment on the part of the critic. But this exercise reminded me that the best bugs are almost always simple presentations of facts. If I have an emotional attachment to a bug—if I find myself getting defensive when someone suggests that things aren't as bad as I believe—I need to make sure that I have enough objective data to back up my opinion and justify my feelings. If not, I need to step back and reevaluate my position. Before entering a bug I need to ask myself:

• Can I articulate clearly, in writing, why this is a problem? If not, why?
• What are the facts?
• Do any facts indicate that I have more investigating to do? Should the facts cause me to reconsider my assumptions?

Living in UTOPIA

As a matter of politics, UTOPIA was one of the worst ideas ever. But I won't complain about the bang for the buck at less than $50 per month.

A Cube With a View

Sometimes there are advantages to being near a window, even if there is a cube wall separating you from it.