Articles by Justin Goeres

You are currently browsing Justin Goeres’s articles.

Next Tuesday, May 4th, I will be doing a presentation at Seneca5’s monthly user group meeting. The topic will be Popcorn Tweets: Going Viral with LabVIEW and JKI. Dave Britt (Popcorn Tweets co-creator) and I will be there with the Popcorn Tweets hardware to discuss why we built it & how it all came together, and also to demonstrate & discuss the underlying software architecture of the machine. There will be plenty of time for questions, too!

This is a great opportunity to get a real-life behind-the-scenes look at how a JKI engineer uses the free JKI State Machine to create robust, maintainable (and sometimes fun!) applications using LabVIEW, and how you can do the same. There’s even pizza!

Title: Popcorn Tweets: Going Viral with LabVIEW and JKI

Date: Tuesday, May 4th, 2010

Time: 6:30 PM Pizza / 7:00 Meeting

Location: Seneca5 / 419 N. Boylan Ave. / Raleigh, NC

If you’re in the Raleigh area, we hope to see you there!

A weird thing happened a few days ago.  The JKI State Machine went viral.

If you follow me on Twitter or are my Facebook friend, you would’ve known right away about the LabVIEW-, LEGO Mindstorms-, and Twitter-powered popcorn-popping contraption a friend and I built recently.  We built it to enter a contest, where the object was to make a video showing the “most inventive way to pop this all-American snack.”

Our first idea was a winner:  Crowd-sourced Popcorn.

Since we uploaded it last week, the video has gone viral.  It was picked up first by Engadget, but things got really big when it hit Mashable.  Even now, there’s a steady stream of #popcorn tweets on Twitter, as people send the link around and around to their friends.  Most importantly, we won the contest.

What does this have to do with JKI?

If you watch the video, you can clearly see that the famous JKI State Machine plays a starring role.  I got to thinking, though, that the JKI State Machine is by no means the only important piece of the puzzle.  I used a whole bunch of JKI products!

We didn’t spend a lot of time designing and building the Popcorn Tweets system.  After all, I have a real job at JKI.  But luckily, I live in a world where NI makes great products like LabVIEW, and where NI partners like JKI can extend the platform and provide great tools to help people turn any idea into reality!

Want More Technical Info?

I’ve posted a technical overview of the system on NI’s LabVIEW DIY Crew group.  Check it out!

JKI is pleased to announce the release of VI Tester 1.1.  This release fixes several issues reported by the community, and also adds some significant new features:

  • A programmatic API so you can run tests and obtain their results from your own code.
VI Tester's Programmatic API

VI Tester's Programmatic API

  • Several new toolbar buttons in your LabVIEW Project window so you can access VI Tester’s most common features right from your LabVIEW projects.
VI Tester's Project Toolbar

VI Tester's Project Toolbar

  • The ability to export your test results to a text file and/or print them.

We’re excited by the community’s response to VI Tester.  We hope you find the new features in VI Tester 1.1 as useful as we do!

How to get VI Tester

VI Tester is available on the VI Package Network.  If you’re already a VI Package Manager user, just click the “Check the VI Package Network for Available Packages” button in the VIPM window.  VIPM will notify you that VI Tester is available, and you can simply tell VIPM to download & install it for you.

check-network-for-pkgs

Check the VI Package Network for Available Packages

If you’re not already a VI Package Manager user, what are you waiting for?  VI Package Manager lets you take control of your reusable VIs, and is also the best way to put all the great tools from JKI Labs, OpenG.org, and the whole VI Package Network into your palettes!

For more information about VI Tester, visit jkisoft.com/vi-tester.

I’m terrible at remembering important details.  I’m great at relatively useless stuff, like powers of 2 and the lyrics to songs my parents used to sing.  I even remember the phone number of a girl I had to call once in fifth grade, to get homework from her because I missed school that day.  It had two consecutive zeroes in it, which I thought was cool.  Come to think of it, I should see if she’s on Facebook.  Anyway, my point is this:  I forget stuff that matters.  One example of something I forget, which matters a lot, is how to build my customers’ applications.

That’s why I create a one-click build VI for every project.

The idea of a one-click build VI is that anyone should be able to check my code out of SVN, open build.vi, hit Run, and build the application (or the VI Package, or whatever).

Example One-Click Build VI

Example One-Click Build VI (Front Panel)

Some smart people whose work I respect are big on this, and a one-click build VI offers several immediate advantages as soon as you start using it:

  1. It helps you document your build process,
  2. It makes it easy to build early and build often, and
  3. It lays the foundation for other good software engineering techniques.

I’m going to elaborate on each of these items, and then at the end I’ll show you how easy it is to get started with your own one-click build VI.


1) It helps you document your build process

For complicated applications that have multiple, separate pieces, an automated build is essential.  But even for small projects, the cycle of releasing an application can be surprisingly long:

  1. Build the EXE.  …and wait for it to finish.
  2. Build the Installer.   …and wait for it to finish.
  3. Find the installer on disk and zip it up.  What’s the convention I use for naming the ZIP?  Oh, yeah, I remember.
  4. Upload the installer to the FTP site.  What directory does it go in?  Oh, there it is.
  5. Copy the installer ZIP to the archives. Where are those archives again?
  6. Commit the project file to SVN, because the build process modified it.  Did I do that already?  Maybe after #2?  I don’t remember.  Oh, OK, I already did that.

The point is that even for simple applications, this process is long and error-prone, and you should write it down so you do it exactly the same way every time (because you’re a good engineer, and you care about repeatability).  So if you need to write it down anyway, why not write it in code?  Then, those 6 steps above collapse to

  1. Open build.vi and click Run.

That makes it easy for you to build your app whenever you feel like it.  How about over lunch?  Or when you leave your desk every night?  Or during that otherwise time-wasting meeting with your boss?

Not only that, when you use a one-click build VI, anyone can build your app exactly the same way.  It decreases the amount of tribal knowledge in your organization, because the build process is captured in the code, even if code itself is terrible (have you considered the JKI State Machine?).  Decreasing tribal knowledge is important because you might get hit by a bus.  Don’t laugh, it happens.

Example One-Click Build VI (Block Diagram)

Example One-Click Build VI (Block Diagram)


2) It makes it easy to build early and build often

If your build process is easy, you’ll want to build your application.  Or looking at it another way, if your build process isn’t easy, you won’t want to build your application.  We already know that it’s a good habit to build your EXE on day one, and keep it working.  But building is a mental context switch, and it takes you away from whatever other really important stuff you’re doing.  That’s why the act of building your EXE should be so trivial that it’s kind of fun.  Opening build.vi and clicking Run is pretty fun, as far as crummy, repetitive tasks go.


3) It lays the foundation for other good software engineering techniques

A one-click build VI is a type of automated build.  And an automated build is a core piece of a successful continuous integration system.  But continuous integration isn’t just for big companies with big products.  Imagine if you had a one-click build VI for your project, and you set it up to run every night at midnight.  Then you could come to work every morning, and a shiny, brand-new build of your current app would be waiting for you to test.  Or, if the build is broken, you’d know it immediately.  This allows you to have trust in your system, and in your software, throughout the development cycle.


OK, so how do I make a one-click build VI for myself?

The VI you see above is a typical one-click build VI for a project with an EXE and installer, built using NI’s application builder in LabVIEW.  It also includes some ancillary features, like zipping up the installer, making some changes to the project file XML, and committing the modified project file to SVN.  It incorporates some switches so I can enable & disable some of these features as required.

But you don’t have to go to that level of detail to get started with a one-click build.  NI gives you everything you need:

BuildTargetBuildSpecification.vi from vi.lib

BuildTargetBuildSpecification.vi from vi.lib

The VI highlighted above is located on your system at <LabVIEW>\vi.lib\AppBuilder\BuildTargetBuildSpecification.vi.  NI has a couple of reference pages on the topic here and here.  You pass it your EXE and/or installer build scripts as shown, and in seconds you’ll be on your way to forgetting everything about how to build your customers’ applications, just like I have.

In the future, I’m going to talk more about specific ways you can use a one-click build VI in your projects.  In fact, I’ll probably write those articles while a one-click build is running in the background!

NI’s New Year’s resolution to provide better support for third-party LabVIEW addons is already bearing fruit in some big ways inside JKI.

Very soon, you’ll be able to access VI Tester directly from the LabVIEW project toolbar.

By clicking on toolbar buttons you’ll be able to run all your project’s unit tests, as well as add new Test Cases and Test Suites without leaving the project window.

Here’s a short video showing a development version of the VI Tester’s LabVIEW Project Explorer toolbar in action:

All this is made possible by NI’s growing openness to providing LabVIEW developers with ways to plug into and extend LabVIEW.  We are very excited about this trend and are learning more every day about new ways to plug into LabVIEW.  Expect to see better integration with LabVIEW for more JKI tools, such as VIPM, in the near future.