I recently published the code behind the event-driven reactive programming examples on the Composed System Bitbucket page under the project name Stream.  Stream is open source and if you are interested in collaborating on it let me know.  Because the source code is now being hosted in a public repository I am going to remove the VIP from the Tools page on this blog, that VIP is already out of date so go to the Bitbucket page and get the latest version.

I've spent the last few posts talking about decoupling actors using event driven architecture (EDA).  Now that we have a common vocabulary I want to show some code that practices what I've been preaching.  So I decided to take the CLD ATM sample exam twice, writing one solution as a queue driven producer consumer and the other as an EDA actor system using event streams to drive the application.  Let's take a look at both.

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.

Owen Search

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.

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.