Browse Tag: process

Getting VI Analyzer Into Our Workflow

We have long known that VI Analyzer is a good idea – much like unit testing – people on the other side of adoption swear by it.

We’ve found a few hurdles for mainstream adoption into our process, and I suspect yours too.

1. Understanding Why

The first step in adopting VI Analyzer (and keeping that adoption going) is understanding why you are doing it!

What I mean by this is you need to make the tool fit your process – not the other way round. If you use VI Analyzer because NI says so then you’re going to see less benefit and it will feel a lot more effort.

For me –  I believe that consistent style and code inspection reduces bugs and improves readability of the system. I have a style guideline, but I don’t always follow it. As I typically work on my own, then code reviews aren’t an option.

Your “why” will probably be very similar but the subtle differences will make some of the following items slightly different from mine.

2. Complicated Setup

As I said above, VI Analyzer is all about consistency for us. We want every project to follow the same style guidelines. Unfortunately, VI Analyzer does not make it very natural to create a standard test configuration and share it between projects since there is a single configuration file for test setup and which VIs to test.

These are the steps that I went through to build a standard configuration:

  1. Start with your style guidelines. I made mine into a table and identified what already had a VI Analyzer test, what had a custom test in the community, what could have a custom test and what was not testable.

    Style Guide With Tests
  2. I downloaded the custom tests that are available online and created a couple of key tests myself. I didn’t do them all, and I will expand my coverage over time.
  3. I used a project to create a VI Analyzer configuration file. I worked through the tests and configured them to my style guideline. Then I removed all of the VIs to be tested. I saved this configuration file as my standard.
  4. I created a VI package which would install the custom tests and the configuration file to a shared location in my documents. Full credit to Fabiola De La Cueva and Delacor for this idea. They have been helping their customers with this for some time. (You can see their video of this on Youtube)

By completing these steps up front, I can introduce a consistent VI Analyzer configuration to a new project quickly and easily.

3. Defining A Trigger

As with any good habit, you need a trigger to tell you when to do it else you often won’t follow through. There are a few common triggers that I have seen people using:

  • Post-Commit in a CI Server – I’m not a big fan of this one because you now need another trigger to review the results and implement the changes.
  • Pre-Code Review – This is a great one if you are on a team. You should test with VI Analyzer before a code review. You don’t want to waste time picking up things a machine can identify faster. As I am a solo developer, this one is limited for me.
  • Feature Branch Merge – If you are using a branching workflow in Git or Mercurial, then you can use a feature branch merge as a trigger. This is a good trigger as it should limit the scope of what needs testing. However, if the change list gets long, then there could be a lot to review.
  • Pre-Commit – I use a Javascript IDE that has a tick box in the commit tool to check style before the commit. This workflow is what I want in LabVIEW. Testing at each commit makes the tests quick (since only a few files have changed) and it means that you fix issues while you are in the mindset of that code. It also means that once you commit the code, it is “done”. The main problem with this in VI Analyzer is the execution time of the tests.

4. Speed

I wanted my trigger to be a commit. I feel like the code should go through VI Analyzer to be “finished” and only “finished” code should be committed.

This is a problem though. Analyzing a whole project can take many minutes, and I might commit 10+ times a day.

One way to solve this would be to test only changed code, but VI Analyzer lacks any native support for this workflow.

I have developed a tool to tie it to git changes. It isn’t great, so we haven’t shared it yet (it still lacks many essential features), but it has started us using VI Analyzer regularly.

This tool will take a configuration file and then run it against only the code that Git shows as changed. Testing only the changes cuts the test time and now means that it is possible to check at each commit and fix the changes before that commit.

Ugly – But Basically Works

By overcoming these hurdles, VI Analyzer has become a standard part of our workflow. I hope you can use this to incorporate it as well.

Whats Your Architectural Language?

The word of the year here at Wiresmith Technology is process. In areas where I have standardised processes life has got easier, less stressful and more reliable. Now I’m looking at the software processes to see where we can get the same benefits.

Something that I have wanted to address for a while is architecture. Working on my own has given me the benefit of being able to be quite ad-hoc and try different designs on different projects.

Well, I often think coming back to your own work after 6 months isn’t so different from working with someone else and I’ve certainly felt the drag of having to review how I built the architecture on each project. So I want to at least have some standard templates.

What I found when I came to it was I first had to define what is in a program!

Language Is Important

There are so many conflicting terms and every framework has its own terminology.

I really wanted to start with knowing what I want in a generic sense. By doing this without looking at specific frameworks it gives me the freedom to find a framework that fits the way I work best (as well as the freedom to change or not use frameworks depending on the project).

I’ve seen this approach work in my business. I’ve been trying to find tools to help me be more productive, but it isn’t until I decide on what the process is that these tools are supporting, I waste hours trying to choose as I have no way to determine what is best!

So before even trying to work with templates or frameworks, I reviewed my previous projects to try and pull out and name the different elements of my architectures so I can map other tools to this.

What I Picked

So here is what I listed as my architectural definitions. Before you read them, understand I am sharing these for your curiosity – you may have your own set of definitions in your team already. This isn’t about right or wrong, this is about consistency between team members and projects.

Term Description Not to be confused with…
Application Component An asynchronous VI with it’s own lifetime and own control of when to run. This is the top level of the architecture design.
Data A piece of engineering data e.g. acquired data. Messages: We split this concept as messages are more framework-oriented.
Message A framework command for a process to do something. Data: although they are data in the strictest sense, they are not directly related to the data involved in the engineering domain.
Message Handler A process that receives heterogenous messages and data. Data-driven process: this has homogeneous data to handle.
Module A set of related code. In our system, it is a class. It is generally unit testable. Module (DQMH), Actor (AF) – These are processes or message handlers.
Process A loop within an application component. It has a single reason to run.

I’m pretty happy with this – the one element of confusion is where the actor style module (whether that is an actor framework actor or another QMH based framework like DQMH). In reality, this sits somewhere between a module and a process but I need to experiment more with how to think about those.

The one I think is particularly important is modules. Too often the important logic gets muddled and mixed with framework code

Next Steps

For me the next step now is to create templates or frameworks to handle these items in a consistent way – more on that in a future post.

My challenge to you is to think about this for yourself. Maybe you already have a framework so you don’t need definitions like this, but where do you find you or your time are inconsistent over time and would a common language help?

Strangers and Coding – Can Rock Help?

A bit of a break from the LabVIEW technical content but hopefully something many of you may find interesting.

I’ve been thinking a lot lately about the process of writing software for someone. Both as someone that others look to and currently looking for outside assistance on some JavaScript code, it is undeniable that this is often a scary process for everyone involved. Can rock help?

Taking on or outsourcing a project involves large unknowns. Unknowns generally require trust in your partners but that has to be built first, it’s a chicken and egg situation.

I have recently become a big fan of listening to podcasts, one of my favourites is NPR’s TED radio hour. As someone who loves TED talks but never gets around to watching them it is a great way to consume them.

This week’s theme was all about playing games. The interesting section for me was the first about strangers.

Research shows that just putting two strangers in a room together, no tasks, just in each others presence, raises their stress levels.

In fact the study goes on to show that this stress means it is very hard to empathise with the other person. In a related experiment on pain, participants tended to believe their pain was worst than the strangers, even when inflicted in the same way (holding your hand in ice water, no developers were harmed in the making of this article!).

This reminded me immediately of the relationships in taking on a new project, everyone is on edge being forced to leap into the unknown with a stranger.

The solution? In this case it was shown that 15 minutes of playing rock band together eliminates this stress, causing participants to empathise with each other as much as a good friend.

So as part of our on-boarding process, bring your singing voice! Not really, but it has certainly set my mind to work on what we can do to remove the unknown and make the process easier for everyone involved.


By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close