Thinking in G

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.

Google has done it again.  They’ve just introducing a new web browser called Chrome that is fast, easy to use, and has lots of nice features — oh ya, it’s also very pleasant to look at.  If Microsoft wasn’t worried before, they had better be worried, now.

Here’s a screenshot of chrome in action:

What I immediately noticed about Chrome is that it is amazingly fast.  I use Google Apps (mail, calendar, maps, and docs) a lot and found these sites to be way faster than when using IE or Firefox.  Also, opening new windows and tabs is faster, as is start-up time.

I’m definitely looking forward to spending more time using the web with Chrome.  And, as more applications move to the web, I guess I might be spending more of my time, in general, with Chrome.  That said, one thing that seems to be lacking with Chrome, is support for 3rd-party extensions and plug-ins — maybe that’s why it’s so fast.  But, I doubt that that’s really what Google was going after, when it designed Chrome.  They were probably trying to build (among other things) a super-fast browser for running Google Apps.

NI is hard at work enabling young people to learn about science, math, and engineering via LabVIEW with products Lego WeDo and Mindstorms, as well as sponsorship and involvement in the FIRST Robotics Competitions.  In addition to doing a great thing by helping young people learn, a side effect is that LabVIEW is being squeezed into universities.  I’ll explain.

LabVIEW has been highly successful in industry, where it really has become a tool of choice for engineers who need to automate test, measurement, and control applications.  Additionally, the NI platform is well poised to be a tool of choice for system design, development, and deployment, as industry sees that the graphical approach, with a fully integrated tool-chain, just makes a lot of sense (because it saves time and money).

However, universities and engineering schools are very entrenched in both older (and freely available, open) technologies.  These academic institutions currently feel the top-down weight of industry demanding engineers who are proficient in LabVIEW and will soon feel the bottom-up swell of myriad youngsters who learned LabVIEW while playing with the Lego WeDo and Mindstorms and then participating in FIRST Robotics Competitions.

Universities won’t have any choice but to start using LabVIEW to teach a variety of engineering courses, because students will be demanding it — that’s the squeeze. When this happens, NI will have realized its goal of getting LabVIEW to be used everywhere from “K through Rocket Science” (an NI marketing mantra).

Now, I don’t want to undermine what an incredible thing NI is doing by helping educate our youngsters, using LabVIEW — I’m just saying that it’s a pretty smart move

Note: I wish that LabVIEW was a standard at UC Berkeley, back in the late ’90s, when I was in school.  I was fortunate to get a student research assistant job at LBNL during my first year, which lasted through graduation, where I was assigned the task of learning LabVIEW and adding a couple features to spectroscopy control and data acquisition system.  I loved LabVIEW and had to fight hard to get my instructors to let me use it for my assigments instead of HP (now Agilent) VEE.  Anyhow, I kept using LabVIEW all through school and decided to keep using it, to this very day.

One of the members of the JKI team just pointed me to the new version (2.5.2798.17141) of XML Notepad.  The major improvement is performance — it’s MUCH faster!  The old version was pretty clunky (although, very feature rich and easy to use).

This free tool from Microsoft is very useful for editing and debugging XML when you’re working with XML data in LabVIEW (which doesn’t have to be hard).  Give it a try, and you’ll be happy that you did.

We’ve just posted video of JKI’s sold out NIWeek 2008 presentation on Effective LabVIEW Code Reuse Strategies and Tools.

We used Zentation to mash-up the Google Video with the PowerPoint slides and it turned out very good.  Next year, we’re going to try to focus on taking video of the presenters (hopefully with better lighting), rather than video of the slides.

We hope you enjoy it.