If you haven't already heard--or tried it for yourself--LabVIEW 2017 offers a simple but powerful new language feature that definitely warrants a deeper look.
Somehow, I made it all the way to the CLA Summit in Austin--having used LabVIEW 2017 for months--before learning about this. Obviously I neglected to scan the LabVIEW 2017 Features and Changes list. At the very least, this new feature addresses the common tedium of making typed polymorphic APIs. It also potentially addresses a design problem I've been banging my head on for months. (A little more on that later.)
This will be a short post on a minor annoyance with putting together a dynamic UI in LabVIEW. I am currently building a multi-subpanel UI with Stream and my simple actor implementation and was annoyed with the difficulty of registering for events on the individual panes in my UI. This annoyance is rooted in the fact that I neglected to label my panes as they were created. So I wrote a very simple little tool for identifying and labeling populated panes.
I've been wanting to write a network extension for Stream for about a year now, adding the ability to extend the mediator to the network and allow pub/sub between actors on different machines. I finally got the motivation to do it after starting to collaborate with Jarobit Peña Saez at Bits 2 Byte on the Stream project. This extension is a result of our collaboration efforts and the sharing of ideas.
One of the many things I can stand to improve upon is how I version my software. I say this because throughout my career I have never adhered to a strict versioning scheme for the software I write. This has been tolerable because my decisions typically only impacted me or at worst my team, but now that I am diving into the world of open-sourced software I think it is time to embrace a standard for software versioning.
I love reading about ancient Roman history and I also love reading about software design. Occasionally those two areas of interest smash together in my brain and weird ideas come out. This post is one of those weird ideas, I'd like to introduce you to Janus, the god of software.
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.