Thinking in G

I’m excited to tell everyone that the JKI Team has been hard at work on (and just announced) a tool to make using TortoiseSVN easier to use in your LabVIEW projects.  It’s called the JKI TortoiseSVN Tool for LabVIEW and allows you to use TortoiseSVN from directly within your LabVIEW projects and VIs, without having to find VIs on disk in Windows Explorer.

For more information, check out the official announcement on the JKI Software Blog.

I’m excited about the new LabVIEW Idea Exchange where users can share and vote on ideas for LabVIEW features.  In fact, I’ve already posted an idea, Option for Disabled Structures to Not Use Default Value for Unwired Output Tunnels, which was taken from a previous post (a rant, really), here at Thinking in G.

I’m thankful that NI is giving users ways to communicate ideas for how to improve LabVIEW, and I’m certain that this will really help in giving users a voice about pain points in LabVIEW that might not be readily apparent to NI.  This is yet another example (here are a couple more) of how NI is working hard to open up LabVIEW and let the community participate in making LabVIEW better.

Kudos to NI and the great feature ideas that are already showing up on this powerful, new community tool.

Sorry for the late notice…

I’m going to be presenting tomorrow, at the LabVIEW Developer Day in Boston (Chelmsford).

I’m going to be discussing LabVIEW Code Reuse in the Enterprise and demonstrating some of the new Enterprise Package Repository Management features that are coming soon in the next release of VI Package Manager.

If you’re able to make it, I look forward to seeing you there.

Wow!!! LabVIEW Scripting (using LabVIEW to programmatically edit LabVIEW code) is going public and you’ll be able to created new LabVIEW features that extend the right-click menu of FP and BD objects.  Check out the lastest blog post on JKI Software for more details:

• Announcing the JKI Right-Click Framework for LabVIEW

I’ve already created a few new right-click menu features and it’s really fun and easy.

This is another article in a series showing some of my favorite OpenG VIs — “The OpenG VIs that I couldn’t live without“. In this article, I’m going to show a very useful VI, Array of VData to VCluster, that is used for converting arrays into a clusters.  The benefit of using this function, is that, unlike the Array to Cluster primitive, it defers type checking to run-time.

Here’s a short, 5 minute video showing how to use this function:

If you want to give this VI a try, you can obtain it using VI Package Manager (VIPM). Simply select the OpenG LabVIEW Data Tools (oglib_lvdata) package from within VIPM. Once installed, this will add a new functions palette at OpenG>>OpenG LabVIEW Data Tools.  (See here for a quick guide on how to install OpenG on VIPM.)

Hopefully, I’m not contradicting myself right now by writing this post, but I think it is worth stating:

If you can’t think of something great to say, don’t say anything at all.

Joel Spolsky just pointed out a perfect example of how being redundant and wordy can make your product look lame.

In today’s world of information overload, getting noticed and remembered is about being remarkable and saying more with less.

This is true for many things, including: blogs, websites, emails, and even software installers.

Recently, JKI announced the new JKI Software Blog.  I wanted to make sure that all of you, the readers of Thinking in G, knew about this great new resource on LabVIEW.  But, I also wanted to explain how the JKI Software Blog relates to this blog, Thinking in G.

Over the years that I’ve been blogging here at Thinking in G, many of my posts have related to the software products of JKI, such as VIPM, EasyXML, and the JKI State Machine.  But, from now on, I’m going to be posting JKI-related articles on the JKI Software Blog.

The goal of this change is to:

1. draw a more clear line between my own personal thoughts on LabVIEW and the messages coming from JKI, and
2. encourage other JKI team members to post articles (on the JKI Software Blog) that relate to JKI and LabVIEW.

Hopefully, this means more great articles about LabVIEW for all of you.  I know for a fact that the JKI team has a LOT of great stuff planned for 2009, so stay tuned in to the JKI Software Blog.

For more information about the JKI Software Blog, visit blog.jkisoft.com.

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.