From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
03-20-2017 05:36 PM
The main issue here is differentiating between:
For sample code, I care about the other developer understanding how the VI is done and understand some underlying principles.
Reusable code, it could be password protected and the other developer doesn't need to care about how it is implemented. What the other developers care about is that it is "bullet proof" and it has been tested. If I am going to reuse this code in multiple projects, I want to make sure that it has been tested and that it does not add problems to my code, such as the ones mentioned above.
If we build either Darren's or David's solutions to a reusable package, then the palette in both cases has a single VI in it. When the developer wants to add this functionality to a VI, all they have to do is grab their Ctrl+A reusable VI from their palettes (or via Quick Drop!) and put it in their code and it works.
Another advantage about bullet proof code that if it is shared via packages is that I can start using David's implementation, then decide that for the next revision I will use Darren's and finally deciding to use James' solution. Every time it would be transparent to the developer reusing the code, all they care about is that Ctrl+A works.
Looking for simple VIs in reusable code leads to tons of technical debt. I have seen it over and over and over again. Like James said, you want your reusable code to not be dealing with things that you have already figured out. I have seen developers reducing the QMH project template to a simple Producer Consumer full of naked calls to Queue functions, only to find later on that the reason they were wrapped in subVIs was because corner cases were being addressed.
So the question would be, do you want sample code or reusable code? If you want reusable code, why do you care about how it is implemented?
03-21-2017 09:33 AM - edited 03-21-2017 09:34 AM
@FabiolaDelaCueva wrote:
If you want reusable code, why do you care about how it is implemented?
Unfortunately, one would be (rightly) reluctant to add an entire framework just to access one minor function. Especially if you are unsure of whether there might be problems with it that you might have to debug. Frameworks have a significant learning curve, and you don’t necessarily want to have to make an investment in more than one.
03-22-2017 11:28 AM
@drjdpowell wrote:
@FabiolaDelaCueva wrote:
If you want reusable code, why do you care about how it is implemented?
Unfortunately, one would be (rightly) reluctant to add an entire framework just to access one minor function. Especially if you are unsure of whether there might be problems with it that you might have to debug. Frameworks have a significant learning curve, and you don’t necessarily want to have to make an investment in more than one.
If the single VI that provides the small functionality is password protected, there is no need to understand the underlying framework. This framework could be Messenger, Actor Framework or DQMH. In the case of DQMH, the only dependency is to the Delacor DQMH library in vi.lib.
03-29-2017 09:22 AM
Just to close the loop on my end, I had an off-line discussion with Fabiola and she was successful in convincing me that using a tried-and-true architecture for this use-case in fact makes more sense than the "Simple" one-VI solution. To be clear, I'm not specifically making a case for DQMH, but reusable architectures in general (Actor Framework, Messenger, JKI State Machine Objects, DQMH, etc). However I did learn more about DQMH and there's definitely some cool stuff going on in there.
Here's a summary:
Anyway, thanks to all for the healthy conversation. Obviously this little tool is a very non-critical thing, but the overall concept and discussion was a good lesson in proper programming practices for me.
Happy Wednesday,
David