Thinking in G

In LabVIEW, whenever you change a TypeDef (type definition) any VIs that use the TypeDef will require recompiling and need to be saved.  This presents a problem for developers working on a large project with other developers who might be working on code that “feels” the effects of the changed TypeDef.

So, how do you deal with all the unsaved VIs in your project that are not in an area that you “own”?  If you don’t save them, then LabVIEW will keep bugging you to save the VIs.  And, sometimes your LabVIEW code will even run slower until you save all your VIs.  But, if you do save these VIs, then it’s hard to tell which VIs that you’ve saved have “real” changes and not just recompile changes.  And, if you commit all the changed VIs, then you might increase the likelihood of creating a conflict with other developers.

Here’s a good process you can follow to deal with this issue:

1. First, commit your real changes, separate from the recompile changes.  This will give you a specific svn revision (changeset) associated with your real changes.
2. Then, save all the recompiled VIs and commit them.  For your commit log message, use “Recompiled due to typedef changes” (or similar).  This will indicate to other developers that the changes can be ignored, in the event that this revision conflicts with their own changes.
3. Finally, Alert your team that you have committed a recompile of code (with no real changes).  They can then easily resolve any conflicts, because they know that the commit contains no real changes.

Now, if you know that other team members are actively working on the code and you don’t want to inconvenience them with having to deal with conflicts, you can defer the recompile until a later time or schedule a time for the recompile with your team.

Note: Even if you use a locking system (such as svn locks or a check-in/check-out SCC model) where files for which you don’t have the lock are read-only, you will still have the slow-down issue and will periodically want to do save all to recompile.

Have you had this issue?  What solution or process do you use?

One great way to make the most of your time between projects is to work on your reusable code library.  You aren’t under the gun to finish a huge project, and you have some “free” time that’s not billable.  So, why not spend that time working on your reusable code?

You’ve probably created lots of reusable gems in your past projects that just needs to be polished up a bit.  Now is a great time to dig these up, improve them, organize them into a reuse library, and then use VIPM Professional to convert your reuse library into VI Packages.

The truth is, just because your time right now isn’t billable to customer projects, it doesn’t mean that you can’t profit from this “free” time later — if you’re working on reusable code that you can use in future projects, those future projects will get done faster and with higher quality by leveraging your reusable code.

Great companies work hard through slow downs, training for the moment that the starting bell rings, signaling the start of the next round.  Then, they come out strong and ready to scrap.  If you think a slow down at work is a good time to go on vacation, then you’re the one whose going to get knocked out by the competition.

There is a very cool Subversion feature called svn:externals (or External Definitions), which is a very powerful feature that allows several projects to reuse common code.  However, this can be a very dangerous feature, if you’re not careful… but we’ll get to that.

The svn:externals feature allows you to create a working copy consisting of multiple working copies from several repositories (or several locations within the same repository).  Basically, it allows you to create something like a “symbolic link” (or “shortcut” in Windows).  The end result is that a sub-folder in your working copy is actually in a different repository (or repository location) than it’s parent folder — you’ve effectively “mounted” a different repository location as the sub-folder in your working copy.

The way that you do this is to set the “svn:externals” property in the parent folder.  This tells the Subversion client (such as TortoiseSVN) to treat the sub-folder as part of the working copy.

This is a very powerful feature that allows several projects to reuse common code.  That sounds great, but there’s a big problem:

When you create a tag in subversion (such as when you create a release of your product), you’re not tagging the svn:externals repository — you’re tagging your working copy, which references the svn:externals repository.

So, if your svn:externals property does not specify the revision of the svn:externals repository, it will always float to the latest version when you do an update, including when you checkout or do updates on working copies of tags!  In other words:

If you do a checkout of a tag, any svn:external sub-folders (without revision information) will update to the latest revision and not the latest revision at the time you created the tag!  This means that you probably don’t have an exact copy of the code that you tagged.

The solution is to explicitly set the revision of the svn:externals property.  For example, instead of setting the property as the following:

toolkit http://svn.red-bean.com/repos/skin-maker

We should explicitly set the revision, like the following (note the “-r 21″ argument):

toolkit -r 21 http://svn.red-bean.com/repos/skin-maker

Allowing an svn:external to float to the latest revision may be is desirable for working in the trunk (when we’re working towards a release), however this is certainly not desirable in a tag (when we want a permanent record of what we released).  There is really only one correct way to address this issue (that I can think of):

Make sure that your trunk specifies the revision of svn:externals before you create a tag.  You can always unset the svn:externals revision in the trunk, after you create the tag.

Now, you might want to let svn:externals float to the latest revision when you’re doing development on the trunk, but this requires that you are diligent about setting the revision of svn:externals, before you create your tag.  This is manual work (unless you have a script that does it for you) and might not get done by lazy developers (and we’re all a little lazy, aren’t we?).

How do we fix this problem, if we’ve have already created a tag that doesn’t specify svn:externals revisions?  Easy: you can go into the tag and look at the log to determine the svn:externals revision at the time the tag was created.  Then, set the svn:externals revision in the tag.  However, this is considered “cheating”, since you’re not really supposed to commit changes to tags — that’s what branches are for.  However, it’s a necessary fix for a bad tag.

On a side note, I wonder why TortoiseSVN or the command-line svn client don’t have a feature to automatically set the revisions of svn:externals during a tag operation — and, at least they could warn you if you try to create a tag that has svn:externals that don’t have revisions set.

I’m very happy to announce that JKI has released the JKI State Machine™ to the public as a free download.  This is the very same template that is used by the JKI team, nearly every day, in our products and various projects.

This tool is the direct result of putting some of the best LabVIEW minds together for several years, tasked with the challenge of creating a LabVIEW architectural design pattern that would allow easy coding, readability, and maintenance.  As you might imagine the JKI team has created something truly special that we hope will have a significant impact on LabVIEW users everywhere.

This has been in the works for quite some time and we’re excited that the time has finally come to share this tool with you, now.

Please take this challenge:

1. Download and install the JKI State Machine.
2. Watch this great video tutorial.
3. Take a look at how we refactored the 3-button dialog (VI that ships with LabVIEW) using the JKI State Machine.
4. Tell us what you think.

Having a great product is an opportunity to do great marketing.  And, since JKI recently released VIPM Professional 2.0, part of our “great marketing” strategy is to travel to several cities across the United States for the NI Technical Symposium (NITS) 2008 tour (beginning this week) to show people how they can save time and money through more efficient and effective LabVIEW code reuse with VIPM Professional.

I’ll be personally attending each of the following NITS events:

• Detroit, MI October 9
• Irvine, CA October 14
• Santa Clara, CA October 16
• Boston, MA October 28
• Raleigh, NC November 5

Additionally, I’ll be presenting a technical session, Effective LabVIEW Code Reuse Strategies and Tools, at the Santa Clara, CA (October 16) and Raleigh, NC (November 5) events.  This presentation was sold out (standing room only) at NIWeek 2008.  So, make sure to get there early to get a good seat

The purpose of attending all these events will be to spread the word about VIPM Professional and how it can help LabVIEW developers and their teams take control of their reusable VIs.  I’ll be giving live demos at our booth showing people the benefits of VI Packages and chatting with people about how they reuse LabVIEW code in their projects and with their team members.

During our NITS tour, I’m looking forward to learning a lot, meeting new people, and visiting with colleagues, friends, and customers.  I hope that you can make it, too.   If you can, please make sure to stop by the JKI booth and say hello.  I’d love to meet you.

On Stefan’s blog on TortoiseSVN, he describes a trick that can be used to “unversion” an svn working copy — basically, how to remove all the .svn folders from a working copy.  This is something that I do, periodically, so it’s nice to learn a new shortcut — and, I love shortcuts.

I figured that I would re-present the information here, for LabVIEW users, but try to simplify the instructions, a little bit.

To do this trick, you basically export the working copy onto itself — meaning, you choose the working copy’s location as your checkout destination (so that the export source and destination are the same).  TortoiseSVN is smart about this and realizes what your trying to do, and it simply removes all the .svn folders from your working copy.

You can do this trick, one of two ways:

Method 1) Right click on your working copy and choose TortoiseSVN>>Export.  In the resulting file dialog, browse to the working copy folder, select it, and choose OK.

Method 2) You can use the TortoiseSVN Right-Click Drag and Drop feature, using the technique shown in the screenshot below.  First, make sure to select “Folders” to view the explorer tree.  Second, use the File Explorer tree to select the working copy’s parent folder in the tree (Folders area to the left), so that the working copy folder is visible in tree and in the file list (area on the right).  Third, right-click drag & drop your working copy from the file list (on the right) onto itself in the tree (on the left).  Then, when the pop-up list of choices appears choose “SVN Export versioned items here”.

Method 1 is a little bit harder, IMO, since the file dialog is one of those awful Browse for Folder (explorer) dialogs (which I don’t like), instead of a standard File Dialog that you can use to paste in a path (which I prefer).  But, Method 2 is trickier to understand, but hopefully the annotated screenshot, above, helps.

Do you know any other useful TortoiseSVN tips?  Please leave a comment and share them.

One of the best places to find reusable code is in your old projects.  However, “mining” your old projects for “reuse gems” (sorting through every VI, looking for sparkly little gems of general-purpose code that have immense value) is simply not an effective use of time or energy.

For example, if you were a miner looking for precious minerals, you would wouldn’t roam the countryside digging random holes in the ground.  Rather, you would work smart — you would try to identify a geographic location with a very high natural concentration of precious minerals (based on a variety of clues).  Guess what?  This is exactly how you should mine for reusable code in your past projects.  But, where do you start looking and what are the clues that will lead you to those reuse gems?

Here’s the secret:

While writing code, when you identify that you are writing a VI that is generic and has the potential to be reused, save it inside a sub-folder of your project folder called “Reusable VIs”.

If you adhere to this strategy, it will be very easy for you to come back later and find your reuse gems.  And, before you know it, you will have what resembles a reuse library.  Best of all, you didn’t even have to get your hands too dirty.

Note: As your reuse library grows (which it will if you use the planning techniques described above), you’ll need to start thinking about how to utilize your reuse library on multiple projects and share these VIs with other developers.  Make sure you don’t get stuck in the pitfalls of a monolithic reuse library caused by copying your reuse library from project to project or by using the same version of your reuse library on each project.  Create a VI Package and install your reuse library in your palettes using VIPM — it’s easy and simple.

I’d love to hear your feedback, so please feel free to leave a comment.  For example:

• Do you have a folder in your project where you put new, reusable VIs?
• Do you think that this is a good idea, or do you have a better strategy?

One of the great new features in LabVIEW 8.6 is the built-in set of functions for parsing XML.  Having an XML parser built-into LabVIEW is really a wonderful thing (previously, these VIs were part of the Internet Toolkit which was a paid, add on).  This makes XML a lot more accessible for LabVIEW developers.

The XML Parser VIs (shown below) can be found in the Functions Palette at Programming>>File I/O>>XML>>XML Parser .

One major drawback of these VI’s is that they still don’t make it easy to work with XML data.  Don’t get me wrong, I love the fact that these VIs ship with LabVIEW.  In fact, they expose more people to XML and thus create more demand for an easier approach to working with XML in LabVIEW.

At yesterday evening’s Bay Area LabVIEW User Group meeting, I saw a very cool LabVIEW demo given by Anders Grunnet-Jepsen.  Anders’ company, ThinkOptics, makes the Wavit remote control, which is basically a combined remote-control and pointing/gesturing device for computers and media PCs.  If that doesn’t make sense, just think of it as a Wii Remote for your controlling your computer or a wireless mouse that you can wave around in the air.

So, how does it work?  Basically (and I’m paraphrasing greatly), the remote control has an infrared camera that is looking at two LEDS (which appear as two bright dots to the remote’s camera) on the LED bar, which sits on or near your screen.  The remote calculates the position and orientation of the remote relative to the LED bar (and thus the relative position of the remote relative to the TV/Computer, after a simple calibration step).  The remote then transmits this position and orientation data via RF to a receiver in the LED bar, which then is communicated over USB to the computer.

It might have been partially due to Anders having a lot of practice using the Wavit, but it seems like a very efficient way to control a computer.  After seeing the demo, I can’t help but think that this will be one of the principle ways that we interact with computers and televisions, very soon.

Another reason that this demo was cool, was that Anders showed off a lot of very impressive LabVIEW software that the Wavit controls and communicates with.  ThinkOptics provides free LabVIEW drivers for the Wavit, so that you can use it to control anything that you can control with LabVIEW!  Now, how cool is that?

What reminded me, today, to write this post is that I watching a talk by Clay Shirky.  In it he describes an event where he’s having dinner with some friends and the friends’ four-year-old runs behind the TV to look for the mouse (because, TVs should obviously have a mouse to control them):

I was having dinner with a group of friends about a month ago, and one of them was talking about sitting with his four-year-old daughter watching a DVD. And in the middle of the movie, apropos nothing, she jumps up off the couch and runs around behind the screen. That seems like a cute moment. Maybe she’s going back there to see if Dora is really back there or whatever. But that wasn’t what she was doing. She started rooting around in the cables. And her dad said, “What you doing?” And she stuck her head out from behind the screen and said, “Looking for the mouse.”

Here’s something four-year-olds know: A screen that ships without a mouse ships broken. Here’s something four-year-olds know: Media that’s targeted at you but doesn’t include you may not be worth sitting still for.

I think it’s cool that LabVIEW is helping to shape the future and fixing the things that are broken in our world.  And, it’s very cool to be in the San Francisco Bay Area and get to see these new inventions, and their inventors, first hand.

I’m lucky enough to have a new project that will be developed in LabVIEW 8.6, so I get to use various new features (like Darren’s awesome Quick Drop tool).

When jumping head first into a new LabVIEW version there are bound to be some unknowns.  In my case, I noticed that, after saving my project (.lvproj) file, an .lvlps file showed up in my project folder (right next to the .lvproj file).

What's that new .lvlps file?

So, I opened up the .lvlps file in a text editor and saw that it contained the following:

[ProjectWindow_Data]
ProjectExplorer.ClassicPosition[String] = “59,221,459,571″

It appeared to store some window settings for my project.

Figuring there’s probably something in the LabVIEW help about this file, I search the LabVIEW help for “lvlps” and found the “LabVIEW File Extensions” help page.

.lvlps

File that stores project settings that are specific to the local machine. You should not check .lvlps files into source control because .lvlps files contain settings specific to the computer you are using; for example, .lvlps files contain the local source code control configuration. LabVIEW saves .lvlps files when you save a project, and correctly renames the file when you rename a project. You can remove or delete .lvlps files without affecting the performance or behavior of a project because .lvlps files only contain project settings specific to the local machine. If you build an application, LabVIEW does not copy the .lvlps file into the built application.

Conclusion: OK, the .lvlps file contains my LabVIEW Local Project Settings.  So, I don’t want to check it into Source Code Control, because each developer working on the project will probably have different settings and they aren’t really important enough to do change control.

Note: I kind of like how Apple Xcode project files (actually they are “package” folders — they just look like files, in the Finder) work.  Your local Xcode project settings (like window positions) are stored in files that include the user’s name, so that you can, if you want, save them in source code control without developers overwriting each others’ settings.  But, since Windows doesn’t really have a feature like “packages” (and LabVIEW needs to be multi-platform), I guess we’ll have to keep doing things the hard way.