A study performed in 2008 by the NCBI found that standard advice encouraging flossing for the prevention of cavities and gum disease is not supported by scientific evidence. This conclusion wasn't drawn because scientists discovered that flossing was not a worth while preventative measure, but rather because scientists found that people were doing it incorrectly. Additionally, a study done in 2013 by the ADA reported that 50% of Americans do not floss daily in the first place. When done correctly flossing can help prevent cavities and gum disease; yet 50% of us choose not to do it at all and the majority of the rest end up doing it incorrectly.
In my current role I have the opportunity to use a variety of tools to solve the problems I am presented with at work. While LabVIEW and TestStand were my key value propositions as a new hire, I quickly found myself gravitating toward C# as my tool of choice. This is in no small part due to the clunky nature of interacting with ActiveX APIs in LabVIEW.
This post will serve as a summary of a presentation I gave recently on Message Abstraction. We will start with a survey of messaging in LabVIEW and finish with an implementation of the Mediator design pattern (code included, scroll all the way to the bottom to download).
This post is intended to be the first of a series of posts targeted at exploring some of the development challenges I have faced during my time as a test engineer primarily leveraging the NI toolchain to do my work. I hope the series will serve as an informative and insightful look at the discipline of test engineering, it's challenges and how I have muddled through solving some of those challenges (or at least worked within their constraints). My experience as a (fairly) recent grad and new to the discipline is that it can be hard to navigate due to it's relatively tribal nature in most organizations. Combine that with the seemingly small number of formal educational programs in test engineering and you end up with a line of work that seems to mean many different things to many different people and organizations. My own goal for these posts is to attempt to make some sense of it all.
I should mention that most of me experience has been spent on the software side of things, although I am no stranger to sticking my head inside a 19" rack to go looking for the source of a short. Please provide feedback and insight (and corrections) in the comments!
Imagine you’re testing a system that has a long startup time, and you find a small change that needs to be made. Now you have to make the software change, rebuild the executable, shut down the application, deploy the new executable, and go through the long startup period again. What a waste of time! Wouldn’t it be great if you could avoid having to stop and restart the entire application? It would be like refueling in flight. Well, now you can.
In my last post I talked about how software has both a primary and secondary value, and how this idea relates to complexity within the framework of Scrum. I want to take a deeper dive into the ideas of complexity and simplicity in order to establish a common vocabulary that I can use in future posts (and hopefully to spur on a discussion with you, from which we will all gain a better understanding).
Imagine taking your brand new lowrider to a mechanic to have a hydraulic lift kit installed. You go back the next day to pick the car up and before you can say anything the mechanic jumps in, flips a few switches and your lowrider starts to hop. You are thrilled but as soon as you climb in and turn the key you realize that your lowrider no longer rides. If this happened to you, you would not be pleased with your mechanic.
While cleaning the code up behind the dependency viewer I was able to improve its performance by about a factor of 100. I will tell you how I did that and also give you some detail on how this thing works in this post. You can download the Class Dependency Viewer as a VIP at the bottom of this page.
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.