The Traveling Salesman Problem (TSP) is a problem in Graph Theory requiring the discovery of the most efficient route a salesman can travel through the multiple cities. As an example if the salesman's route included 20 cities he would have to choose the most efficient of 20! = 2432902008176640000 possible routes (If he evaluated one solution every second it would take over 77 Billion years). Having that many possible routes to chose from makes optimization of the solution difficult and the optimization problem gets harder as the number of cities increases.
The Bowling Game Kata is a very well known coding exercise created by Robert C. Martin geared towards practicing Test Driven Development (TDD). My cohort Russell Blake from G Systems was reading through Robert Martin's fantastic book, "Agile Software Development" where he came across the Bowling Game Kata and had the brilliant idea of recreating it in LabVIEW and blogging about it. We decided to each go through the kata with a different unit test tool and blog about our experience, I will be going through the kata using the LabVIEW Unit Test Framework Toolkit (UTF), Russell will follow up with a post that goes through the kata with JKI's VI Tester.
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.