JMP 8.0

I upgraded to JMP 8.0 this fall, and it's great.

I'm in danger of being redundant, since I've mentioned this software package FOUR separate times over the past couple years: here and here in 2007, briefly in 2008, and again this past summer. But I've used the software regularly since 2005 for data analysis and presentation material. I really like it.

Anyway, I wanted to give props to SAS for the latest version of JMP. There are a few big things they added (I liked the animated graphs) and several smaller additions, but the best feature for me has been the graph builder. In the past when I was trying to see a trend in data I would graph some things as linear plots, try them as contour plots, maybe add histograms. In other words, I would play around with it.

Graph builder sort of automates that process. You can interactively add data to the x-axis, multiple sets of data to the y-axis, separate plots with the same x-axis, separate sets of data on the same plot, etc. If you don't like what you see, remove a set of data, or graph it differently. It's helped me out with two specific problems already, which makes it worthwhile in time savings alone.

I don't work for SAS, I don't get any compensation from them. I just really like the software.

Instrumentation Finder website

There's a relatively new website called Instrumentation Finder. To quote from their intro page:

This site aims to provide a one stop shop for any and all Instrumentation requirements whilst providing all users with the option to source equipment from overseas suppliers outside their normal purchasing reach.

I've tried it out some and it is a) heavily biased towards UK and Europe suppliers (they say that is changing), and b) still a work in progress. But I certainly like the idea of a website specifically for finding instrumentation manufacturers and their products.

FIRST robotics

I posted over a year ago about FIRST Lego League and how my oldest son liked it. Well, now my second son is in middle school and decided to join the robotics club as well. They had their regional competition a few weeks ago and just barely missed the cutoff for the state championship.

He was disappointed about it, but I know he had a lot of fun. From an engineering point of view, I thought the best part was the night before the regional competition. I stopped by for the last half hour of their planning session and got to see them toss ideas back and forth, debug code, and try out different ideas for solving a tough challenge. In other words, it was a lot like a group of engineers solving a problem. Cool.

Spam

Well, today I had to implement word verification for comments to my blog. Up until a couple months ago I'd never had this problem. Test engineering is not exactly a hot button topic, so this blog never gets more than a couple dozen hits a day. I probably flew below the radar.

But starting early this fall, and accelerating the past couple weeks, have been a lot of badly-phrased comments advertising drugs and websites of the usual varieties you see in spam. I guess the auto-generating junk-mail code out there is starting to expand.

So now I've implemented captchas for anyone who wants to add comments. Hopefully that will cut down on the comments I have to delete.

Test engineering fears

I originally planned to write this post for Halloween, but my schedule slipped. Today is Friday the 13th, so that's a decent fallback position.

========================

My middle child was talking about scary movies and what he thought made them scary right before Halloween. That started my thought train on what I fear as a test engineer. More specifically, what a test engineer at a startup fears. Here's my top five:

5) Bugs caught by management

In a small firm most everyone helps out, even management . When you write code, bugs are inevitable. It's okay when other engineers spot the bugs, but it's really embarrassing when the CEO emails you about a mistake he found in your program.

4) Feature creep

Things are always changing in a startup, and that most definitely applies to the testing process. You come up with better ways to test the DUT, you come up with new things to test on the DUT, you speed up your testing, etc. All of these things are fine, but sometimes they feed into extraneous changes to the test system. A design engineer may think, "Hey, it'd be really cool if I could see this set of data while the test is running," but any change like that takes time, and those changes can eat into the time you need for something else.

3) Bad requirements

Worse than feature creep are bad requirements. Suppose you are told that you need to measure current and temperature of a DUT under specific load conditions. So you get the hardware, set up the software, build the station. THEN you are told that - oops - we also need to measure optical parameters of the DUT under a separate set of conditions as well. Suddenly, you have a serious rework on your hands. That scenario can happen in a startup, and it's a real pain.

2) Data getting lost or corrupted

In every startup I've been a part of, data management is a problem. In the beginning, it's easy to sort your data and analysis work with a combination of spreadsheet files, text files, and a good subfolder setup on your network. As the startup grows, you have to implement a database, which introduces its own growing pains. In the meantime, your company lives and dies on that test data. About 4 years ago I had a problem at a startup where an entire set of test-data subdirectories was accidentally deleted from the network by an engineer working in his own directory. I spent an entire day getting the IT guy to get the network backup from two days before and then figuring out which devices had to be retested. Gruesome.

1) Great test results

This is my top fear. At a tech startup you are developing new technology. Things aren't supposed to work right. You have problems with the manufacturing process, you miss key design issues, or you discover unexpected behavior. When I see great test results from a DUT I get nervous; my first thought is that something is screwed up with the test equipment. So I will do a quick check of the hardware connections, software design, and the algorithms used. Good results can play havoc with my sense of well-being.

Post Eleventy One

I didn't realize until last month that I had recorded 100 posts to this blog. By then it was too late to really say anything about it, but I wasn't about to pass up a chance to commemorate 111.

Why that number? You could say that it's because of the interesting information about it on Wikipedia, the fact that it is symmetrically slick, or even that it was Bilbo's birthday when he left the Shire.

But really, it's because in binary form the number 111 converts to 7. And as everyone who watched Saturday morning cartoons in the 70s can attest, seven is a lucky number.

LabVIEW source code control, Tortoise, and JKI

All programmers should know the advantages of source code control (SCC), so I'm not going to talk about that. What I do want to touch on is using SCC with LabVIEW.

I've used Tortoise SVN for close to three years now with LabVIEW. It works pretty well, although LV doesn't sync well with SVN. Several years ago I used Visual Source Safe, and I liked being able to check files in and out from within the LV development environment. So I was happy when I saw JKI say that they had a Tortoise tool. I installed it later that summer, but then LV2009 came out so I had to re-install it.

I don't use it anymore, for one simple reason. Everytime I try to check something in or out, this annoying popup appears:

I might as well just go to the explorer window to check in & out, which is what I've done for years now.

I can understand JKI wanting to make money for their work (although $99 seems steep). But that pop-up appears every single time... it has annoyed me so much that I'll never buy it. Too bad, because otherwise JKI seems to do great work.