The LabVIEW IDE gives us a way to visualize class hierarchies but I always thought it would be useful to visualize the source code dependencies between my classes as well, so I put a tool together.

The Liskov Substitution Principle (LSP) is one of the five SOLID principles of object oriented design.  At first glance the LSP seems rather complex but I hope that my presentation below will help clarify what it means and how it can effect the flexibility of your software.

The Dependency Inversion Principle (DIP) is a principle of object-oriented design that will change the way you think about writing software.  It is one of the 5 SOLID principles Robert Martin discusses in his book, I highly recommend checking this book out if you have never read it.  I gave a presentation on the DIP with Stephen Loftus-Mercer at NI Week 2015, and just gave a slightly different presentation on the DIP at the Software Craftsmanship Workshop at NI Days Boston 2015.  Below is a recording of the Software Craftsmanship Workshop presentation, along with my slides.

Communication between Actors is meant to be done by traversing the Actor tree.  Assuming we decide not to pass message enqueuers around to all Actors in the tree, we will end up with a lot of message classes and a lot of message routing.  The extra messages and routing, however, buys us robustness as Actor E has no way of knowing if Actor C currently exists.  But what if we could bypass the tree for certain types of messages in a way that allowed us to decouple our actors from each other...

NI introduced two new functions to the Application Control palette back in LabVIEW 2013, "Get Control Values by Index", and "Set Control Values by Index".  These functions allow you to get or set control values faster than is possible with other VI Server objects, such as the Value property in the Control class.  How much faster?  How can I use this?  How am I not learning about this until now?  Read on...

I am by no means a UML guru, however I do believe that UML can help me communicate complex ideas.  In order for this communication of ideas to be useful everyone taking part in the conversation needs to be speaking the same language, but don't panic, not everyone taking part in the conversation needs to be fluent.  

I was recently writing a TCP connector for MySQL so that I could call it from both 64-bit LabVIEW and LabVIEW RT and I realized that I needed a way to spy on my localhost network traffic for debug purposes.  So I fired up WireShark, but it turns out that WireShark can't see localhost traffic because localhost traffic is not sent over a real network interface.

As writers of software we strive to craft code with high cohesion and loose coupling.  This can be tough to do with the Actor Framework as the default method of sending messages between actors effectively couples them together.  Depending on your application this coupling may not matter, but I will show you one way to manage it if it does.

The above image illustrates a small section of the flow of control for an application used to calculate properties of a black hole.  There is a high level module used to calculate the tidal force that objects experience while near a black hole's event horizon.  This tidal force calculation requires the black hole's mass as an input, which is calculated by a lower level module.  The high level tidal force module needs the black hole's mass in order to perform its calculation, and it depends on the low level mass module to supply it.  

If you were paying close attention as you went through the blog post on the root loop you may have noticed a little slight of hand.  I may have been stung, but I'm not sure.

In the central coastline deserts of Chile there exists an elusive wingless wasp that looks like a panda bear, is referred to as an ant, and has a sting strong enough to put a cow down.
Meet the Panda Ant:

Similarly, deep within LabVIEW there exists an elusive message loop that has the potential to sting you.  The Panda Ant is neither good (its sting can paralyze a cow) nor bad (it looks like a panda bear), but learning about it now will prevent you from getting stung by it in the future.  The same can be said for the root loop, it's not a bug in LabVIEW and you have most likely never noticed that it exists, but learning about it now could prevent you from getting stung by it in the future.