In my last post I took a look at data-centric and message-centric communication and their effects on software systems. This post will take that discussion a little bit further by connecting the idea of data-centric messaging to Event Driven Architecture (EDA). Along the way, we will build up a vocabulary that we can use to disucss systems of actors and the types of coupling we encounter while building them.
Delving into the world of asynchronous and concurrent programming can be quite daunting these days. There is a deluge of jargon and hip new libraries to learn as a newbie. At times, it feels like the difficulty in navigating these rough waters might rightly be interpreted as a dire warning: BEWARE THEE WHO DOES NOT KEEP HIS PROMISES. But what is a promise anyway? And for that matter, what is a future? Or a continuation? And here I thought I was in over my head when I started threading...
While I won't even try to completely illuminate these topics in a single blog post, I hope to provide a straightforward explanation that can help a beginner navigating the waters of asynchronous programming. Really, once you get past the nomenclature, these programming constructs are REALLY interesting and useful.
I recently gave a presentation at a local user group on message transport abstraction and how it can be used to abstract communication between actors running in LabVIEW and thin clients running in web browsers. During the presentation an interesting question came up regarding why I chose to make communication between my actors data centric instead of message centric. This question triggered a lot of thinking on my part and after a few days of rumination I decided that a blog post on the topic was warranted.
Rolling the turkey takes some skill in bowling - since this article is the third in the TDD series, I feel a tad bit of pressure to execute! In this article I’m going to create a parallel solution to the bowling game using the Caraya test framework by JKI that will converge with the final solution in the previous articles based on the Kata solution written by Robert C. Martin.
Typically the first program you write when you are learning a programming language is, "Hello World!". Due to the popularity of my prior post on optimizing the traveling salesman problem with genetic algorithms I decided to write a general parallelized Genetic Algorithm Framework for LabVIEW, naturally the first thing I taught it to do was to say, "Hello World!".
As a follow up to the post, Bowling Kata - Unit Test Framework written by Jon McBee, I will be following the same Bowling Game Kata by Robert C. Martin using the JKI VI Tester. Because the original kata was written in Java, you will notice that Jon and I took different approaches when translating it to LabVIEW. You will also see differences based on the unit testing tools we each used. Hopefully you will find these differences interesting and informative. To give another valuable perspective, Omar Mussa will follow up with a post that goes through the kata using Caraya.
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.