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

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.

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.

• 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.

If you’re going to be in the San Francisco Bay Area next Wednesday evening (February 18th, 2009 at at 6pm), then be sure to come to the LabVIEW User Group Meeting at the NI Mountain View office.

I’ll be giving a demo of JKI’s new VI Tester and talking about ways to improve your software quality via unit testing. 

For more details, see the meeting agenda page.

I hope to see you there!

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.)

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.

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.

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?

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.