April Fools Day - Klingon Tests

Back a couple months ago I posted a couple of bad jokes I had made up about hydrogen.  Since then I've been thinking about posting more jokes, but in a testing vein.  I've done that before (here and here), and April Fools' Day seems like a good time to do it again.

If you hate Star Trek, you might want to stop now.  You won't really get it.
======================


Okay, what I'm posting below is actually a repeat of some jokes I had on my group's website when I worked at HP.  Enjoy.

• Specifications are for the weak and timid!
• You question the worthiness of my code? I should kill you where you stand!
• Indentation?! - I will show you how to indent when I indent your skull!
• What is this talk of 'release'? Klingons do not make software releases. Our software escapes, leaving a bloody trail of designers and QA testers in its wake.
• Klingon function calls do not have 'parameters' - they have 'arguments' - and they ALWAYS WIN THEM.
• Debugging? Klingons do not debug. Our software does not coddle the weak.
• A TRUE Klingon Warrior does not comment on his code!
• Klingon software does NOT have BUGS. It has FEATURES, and those features are too sophisticated for a Romulan pig like you to understand.
• You cannot truly appreciate Dilbert unless you have read it in the original Klingon.
• Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are!

As a bonus feature, a friend of mine from high school forwarded these old Star Trek images to me.  Enjoy.

Falling into your lap

Sometimes a perfect project just falls in your lap.

At work I've been heavy into upgrading an existing test system, but I'm at that point in a project where I can see the end.  I was starting to consider what I should work on next.  I'm not at a loss of potential ideas, but none of them seemed very urgent.  Then one of the R&D engineers came to me with a need to do some visual inspection measurements.  That sounded great to me, because it's been three years and two companies ago since I last worked with the LabVIEW vision tools.  This should be fun.

Passed the CLD (part 5) - test day

I passed the CLD exam a couple weeks ago, and I'm writing about that experience.  I've talked about the NI courses, working sample problems, and my test prep guide.  So all that's left is to go over the actual experience.  The description is a bit personal, but hopefully if you take the test yourself you might get something out of this account.

It's been a long time since I took a serious test.  The last time must be when I took CS grad school classes back in the late 90s.  I was nervous.  To fight that feeling, I tried to prepare myself as well as I could.  Get plenty of sleep for about two days prior to the test, jam to good music the night before, eat a good breakfast that morning.  I drove down late Monday morning for the 10am appointment.

I brought my own mug in with me to the test, filled with Mountain Dew (an old college habit).  I took the exam in a nice quiet room at a nearby NI office.  Unfortunately, this nice quiet room was right next door to the breakroom.  At noon it got very noisy.  The NI employees were having a good time discussing their weekends.  They must have enjoyed it, because there was a lot of loud laughing.

Around 1pm, after trying to code through an hour of conversation, LabVIEW crashed.  Great.  Fortunately, I had the sense enough to leave the computer alone and show the coordinator what happened.  She called down to NI in Austin, and they gave me the option of getting some extra test time or retaking the test another day.  Tough call, but I decided to just finish the thing.  So I rebooted the computer, restarted LV, recovered the code, figured out what work I had lost, and got back into the programming zone (thankfully quiet this time around).

So that's what my test day was like.  It could have been worse, but if any of you take the exam I hope your day is better than mine.

Passed the CLD (part 4) - preparations

I passed the CLD exam a couple weeks ago, and I'm writing about that experience.  I've talked about the NI courses  and the NI sample problems.  Now I want to show you my test prep guide.

Before I copy it down, let me describe it.  I had two goals.  First, I suspected that the 4 hour limit would be tough for me, so I wanted to lay out what I should be doing and when.  Second, I researched the test extensively.  Aside from reading the NI-provided preparation materials, I read online articles and what people wrote about it (for example, on the NI forums or at LAVA).  I wanted to efficiently summarize that information.

So, here it is.  If you copy it to a two-column document, it fits on a single piece of paper.

1.       Open LV if not already open.

2.       Read through the problem.

3.       Create a blank project and save it.

4.       Ctrl-H so I can see the help box.

a.       Reminds me to comment everything.

5.       Create a blank VI.

a.       Turn off automatic tool selection.

b.       Select nothing on the front panel and change the font style to bold.  This makes all subsequent creations boldface.

c.        In the block diagram, open the function palette and search for something.

                                                               i.      It takes time for the list to populate.

d.       Click on the icon to change it.

                                                               i.      It takes time to load the icon editor.

6.       Read through the problem again, in detail.

a.       Define the basic objects.

                                                               i.      These will likely be custom controls.

                                                              ii.      Start creating some base objects.

1.       Reference the GUI.

b.       Define what the different state conditions are.

                                                               i.      The graders look for a state machine, event structure with states, etc.  Looking for specific states is a good place to start.

c.        Decide on the basic architecture to use.  NI states that “exams are based on a sequencer-type application” and “timing is an essential aspect.”

                                                               i.      State machines: obvious solution, but not suited for storing sequences or (maybe) GUI events.

                                                              ii.      Queue-based events: commonly used, stores sequences, limit the processing in the event case.

                                                            iii.      Producer-consumer: possible choice for some CLDs, not great for non-user interface events.

d.       Timing

                                                               i.      Execution: Regulates loop execution (ie – state machine) – may introduce jitter or unresponsiveness.

                                                              ii.      Software: Measures elapsed time with stop/reset/pause options.  Use func global, subVI, or express VI.

                                                            iii.      Others: Event case timeout, synch VI timeout.

e.        Create a top-level VI using a design pattern.  Probably a state machine, producer-consumer, or something like that depending on the problem.

                                                               i.      Take up the full screen width so you know your space – shrink it later.

f.        Save it and verify it’s added to the project.

7.       From the provided screen shot, design the basics of the front panel.

8.       Style checklist

a.       Avoid local variables.

b.       Property nodes <> indicator or control values.

c.        Type defs!

d.       No coercions or default tunnels.

e.        Make subVIs.

f.        Readable code!

9.       Error handling

a.       Wire error terminals.

b.       Wire error clusters to “no error” case.

c.        Stop top level VI on error (all loops)!

d.       Use simple error handler on program exit.

e.        Monitor errors from parallel loops.

10.    Documentation

a.       Documentation for the VI & subVIs.

b.       Free labels on wires.

c.        Labels on block diagram items.

d.       Label the actual loops (yes you can).

e.        Label constants.

f.        Tip strips on GUI.

g.        Consistent icon scheme.

h.       Be brief & to the point.

11.    Test

a.       Functionality

b.       Weird behavior from user.

12.    Final check through.

a.       Close the project.

b.       Reopen it.

c.        Open the top level. 

                                                               i.      Make sure there are no errors.

                                                              ii.      Verify that it runs correctly.

d.       Double check documentation on every VI.

e.        Make important terminals on subVIs required.

f.        Run VI Analyzer if time permits.

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

I'll have just one more posts on this subject: the actual test day experience.  That should be up in a couple of days, and then on to other topics.

Passed the CLD (part 3) - preparations

I passed the CLD exam a couple weeks ago, and I'm writing about that experience.  In part #2 I talked about the courses that NI offers.  Now I want to write about the example problems NI publishes.

NI has plenty of information on their website about their exams - preparation guides, slide shows, and sample exams.  There are three samples: a traffic light, a security system, and a car wash.  These problems have been posted as examples for a while.  I know for a fact that the traffic light problem has been on the NI site since at least 2003.

There are two lessons to draw from that last statement.  First, the problems are older and, in my opinion, not as sophisticated as current test problems.  Second, the solutions are old as well and not very good.  I'm not the only one who thinks this.  Do a search through the comp.lang.labview users group, or LAVA, or even on the NI discussion forums, and you'll see that many others have expressed the same opinion.

Here's what I'm saying: don't limit yourself to the practice exams and the NI-provided solutions.  Look online for the solutions from other people, read through the discussions about the problems, think about how the problem could be made more complicated.  A couple of links to get you started are here, here, here, and here.

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

In the course of preparing for the test, I tried to summarize what I learned from the sample exam solutions.  Here's an abbreviated list of what I wrote down as important - your own lists may differ.

• The top level VI is at least a state machine.  Make sure you have an initialize option, and set up default properties within the initialize state.  Don’t have them sitting outside the loop – that’s messy.
• Controls & clusters
• When in doubt, type-define.
• There are some things (like changing colors) on a strictly type-defined control cluster.  Make it a regular type-defined control instead.
• For a control reference, use the To more specific class function to cast the reference as a known control.

• SubVIs
• Wire errors for all subVIs.  Use a case statement to skip operations if there is an error.
• Make use of functional globals.
• Always have an initialize case for functional globals.
• Some subVIs will be state machines themselves.
• Timing is an essential part of the CLD exam.  You need to understand how to time operations, pause them (while maintaining the elapsed time), and abort them.
• If you can, just use the express timer.
• If you have to create a timer VI, make it a functional global.
• The main states are Initialize, Start Time, and Get Time.
• Use the initialize option to set everything to zero
• The stored items in the VI are the target time, start time, elapsed time, and Time Elapsed?
• Check the time as the image below: subtract the current time from the start time to see if the difference is greater than the set time.

• Queues are often used in sequence-type patterns.  Know them well.
• Adding something to the queue puts it at the end of the line.  To put it at the front of the queue, use the Enqueue element at opposite end function.
• If you must abort a sequence, place the abort action in the front of the queue.
• Queue VIs wait until there is something in the queue to act upon.  Use the timeout option if this behavior is unwanted.
• You can preview the next item in the queue without removing it.

Passed the CLD (part 2) - preparations

As I mentioned last week, I recently passed the Certified LabVIEW Developer (CLD) exam.  In that post I said that I'd write more about my preparations.  One way I prepared was studying course materials.

There are three courses that NI recommends you take before trying the CLD exam: Core 1, 2 and 3.  In fact, they offer a money back guarantee if you don't pass.  That's a good thing, since the price just for Core 3 is ~$2k.

Note: the courses used to be named LabVIEW Basics (I and II) and LabVIEW Intermediate (I and II).  They were renamed last year to "better align with NI certification program."  Sounds like marketing to me.

Anyway, I said that I studied the course booklets.  I didn't actually take the courses.  Well, I did take a LV basics course, but that was back in 1997.  I borrowed a copy of the Intermediate course books from friends, along with the CDs, and worked through them on my own time.  Most of it was review, but I picked up a few tidbits while studying.  Furthermore, that work helped me focus in on LV in a way that my normal job couldn't.

Alternative: If you want to take the classes but can't afford it (or your company won't pay for it), and you can't get a copy of the books from a friend, then try searching online.  I suspect that somewhere out there someone has published the contents of the courses.  Not that I'm condoning that, since I'm unsure of the legalities.  But it is an option.

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

I think I'll make three more posts on this subject.  Two of them on preparations for the test, and the third on the test experience itself.

Changed the RSS layouts

Someone pointed out to me that many of the RSS feeds at the bottom of the blog had Invalid Date listings.  I then found out that Science Magazine now requires a (free) membership to view articles.  That's all well and good, but they should change their RSS settings to at least allow the "article publish date" to go through.  Looks like they didn't thoroughly test their software...

Anyway, I changed my feed to Science News, which gives me no invalid results at all.