My last post discussed the different types of coupling between actors in a data-centric event-driven application. This post will follow up with a deeper look at semantic coupling in these data-centric event-driven applications and I will propose a way to loosen this type of coupling.
If it's not blatantly obvious, I value the Actor Framework (AF) as an important part of my toolkit. It's not the right tool for every job, but it is a useful tool for many. One part of the AF I don't love is the necessary tedium of building Actor Core event-handling UIs and then dragging reference controls (for my by-reference updates) into the Class Private Data Cluster. This got me thinking... In general, adding controls to a class feels like a relatively clumsy process, even when not using the AF. I let this mild frustration stew inside my melon for years, and then I finally did something about it.
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.