Jump to content

Nom Nom Nom... Eating Crow


Recommended Posts

I really like this idea. (Maybe because I think I would do much better in that kind of test.) I don't know how practical it would be to do in real-life, but it is much more aligned with the skill set I think of when someone talks about an architect.

...

Lot s of good thoughts there. Please excuse my laziness with quoting you.

The interactive nature of a review process would help bridge the gaps transfering your solution to the minds of those ding the evaluation. I think it could also help out with the terminology barier (Non-CS types who kick-ass in LV but never took any official cousrse... How exactly do you pronounce "boolean" anyway?) as well. I had been designing application for years before I figured out what "Use Case" was talking about (Yes, I admit it ! I was teaching myself to design and implement software before any college ever concidered including it as course work. I recall having a PHD from Pitt floowing me around asking question while I was fixing his hard-drive.

Re: Patterns

The intent of Patterns serves multiple roles. Not only do they help us idientify solutions to well defined situations but they also are a form of short-hand that should eliminate the need to explaining them.

I hope you find the chance to confront this challenge again some time. I do not feel I am alone in saying;

"There is chair with "DAKLU" in the virtual hall of CLA waiting for you."

Take care,

Ben

Link to comment

The interactive nature of a review process would help bridge the gaps transfering your solution to the minds of those ding the evaluation. I think it could also help out with the terminology barier (Non-CS types who kick-ass in LV but never took any official cousrse... How exactly do you pronounce "boolean" anyway?) as well. I had been designing application for years before I figured out what "Use Case" was talking about

Yes! I kept reading over and over on LAVA about this wonderful thing called "plug-in architecture", finally researched it, and discovered it was something I'd been doing for quite some time -- I just didn't know the fancy name for it. I will admit to some concern over potentially being stuck by not knowing "correct" terminology when/if I ever get around to taking any of these certification exams.

Link to comment

Yes! I kept reading over and over on LAVA about this wonderful thing called "plug-in architecture", finally researched it, and discovered it was something I'd been doing for quite some time -- I just didn't know the fancy name for it. I will admit to some concern over potentially being stuck by not knowing "correct" terminology when/if I ever get around to taking any of these certification exams.

Perhaps we should design a BS Bingo game for LabVIEW :)

Edited by ShaunR
  • Like 1
Link to comment

I've used OO in all my LV applications since 2000, but I agree, I won't use OO in the exam, since without a toolkit it would take me to a bit too long time.

I might buy this argument for the CLD, but not for the CLA. You're not having to fill in all the detailed code in the CLA, which means its mostly "Create some basic classes and put empty VIs into those classes."

Somewhere between 2 and 3 out of 10 of all CLA exams submitted do use LVOOP as their primary design orientation. I did both my CLD and CLA exams with "no VIs that weren't a member of some class" partially because I usually design that way and then prune back later if it seems prudent, so at the architecture stage it really is all classes, and partially to prove that it could be done within the time.

Yes! I kept reading over and over on LAVA about this wonderful thing called "plug-in architecture", finally researched it, and discovered it was something I'd been doing for quite some time -- I just didn't know the fancy name for it. I will admit to some concern over potentially being stuck by not knowing "correct" terminology when/if I ever get around to taking any of these certification exams.

The exam doesn't care so much about the terminology as long as you explain what you're doing. The value of the terminology is the shared vocabulary can save a lot of time. If you can just write down "put a standard producer/consumer loop pair here linked by a queue", that's faster than explaining all the bits and pieces. There is a common parlance that develops around any technical field. The CLA exam does not require that you speak it, but it does weight advantage to those who do.

And, for the record, since you are reading LAVA, you've picked up that bit of terminology. Anyone who keeps reading like that will eventually pick up the terms.

No, but I'd have to give enough details that an over-the-wall developer could implement it. That means describing the details of the MessageQueue class, the Message class, and the ErrorMessage class.
It would be worth asking whether the CLA graders would accept a VI that says, "Download standard toolkit XYZ from location MNO and instantiate the following template, then put that subVI here." ... and similar comments. Any of the tools like LapDog, or AMC, or ReX, or the Actor Framework, or the GOOP Toolkit might be usable then. After all, that's exactly the instructions I would give to a developer in some of these cases.

I seriously doubt that it would get you off the hook for actually doing the module design and layout of pieces, but if you can broadly mimic the pieces that you want those tools to generate, that might pass examination. Worth asking, IMHO.

I suspect it is driven by business needs. Customers want some indication of whether a consultant is worth his salt or blowing smoke, so NI created certification. I'm not particularly fond of the way the CLA is structured, but perhaps that is driven by customers too. If customers are asking for architects to do designs so they can be implemented by lower cost labor elsewhere, then maybe that's what NI should give them.
My understanding of the intent of the CLA, and how it is used by managers who look for the certification when hiring, is that the CLA is a leader of CLDs, someone who works a bit faster than a CLD because of long practice, but more importantly, someone who can teach. Not every crackerjack developer can actually teach others how to develop. An architect has to have that skill. "This project is larger than what any single developer can build alone; I'm going to spec out the parts of that system and then farm them out to you guys. If you build them wrong, I'll show you why it doesn't fit with the rest of the system." Over time, a CLA should be able to create new CLDs from untrained new hires. That's my understanding, anyway, and I believe that's why documentation counts so much in the exam.
Link to comment

You're not having to fill in all the detailed code in the CLA, which means its mostly "Create some basic classes and put empty VIs into those classes."

I'm not convinced this will save me a lot of time. As I've learned OOP and applied it to LV over the last several years my classes have gotten smaller and more specialized. Each class is very limited in what it does, often to the point where the functionality a class encapsulates is contained on a single bd. (The LDM MessageQueue class is a prime example of this.) And my custom data types are almost always classes with accessors instead of clusters for reasons I've explained elsewhere. Of course these decisions requires more classes overall, so even though I don't have to fill in all the details of every vi I still have the overhead of creating the classes and all the public methods the class exposes.

Somewhere between 2 and 3 out of 10 of all CLA exams submitted do use LVOOP as their primary design orientation.

That's interesting. I wonder if that reflects the LVOOP adoption rate overall among intermediate to advanced developers? It would also be interesting to see how much this number changes over time.

so at the architecture stage it really is all classes

The way I develop apps at the architecture level it is all components (typically a lvlib,) where each component's api is made up of several classes that work together to fulfill the component's responsibilities. Probably very similar to what you do with a slightly different project structure.

and partially to prove that it could be done within the time.

In practice my apps are heavily multi-threaded and message based because I find adapting to changing requirements and reusing code is much easier using this paradigm. Maybe I need to just abandon the messaging architecture for the CLA and use something more direct, even though I wouldn't do that IRL...

The exam doesn't care so much about the terminology as long as you explain what you're doing. The value of the terminology is the shared vocabulary can save a lot of time.

Yeah, this is another area where I'm having a hard time figuring out how much is enough. There are implementation patterns I use that address the shortcomings I've encountered in many of the common LV patterns. (i.e. I've written at length about the QSM and it's dangers, so I'd never instruct a junior developer to create one.) Unfortunately for me these patterns aren't widely recognized within the LV community and explaining how and why to implement them to a typical over-the-wall Labview developer is difficult, to say the least. Yet some of the implementation details are important from an architectural standpoint, so I have a hard time sweeping them under the rug.

For example, when a component reacts to messages sent by a source it doesn't have intimate knowledge of, I don't ever put functional code in a timeout case because the timeout might never expire. Instead I create separate timer loops to regularly enqueue messages which in turn trigger the functionality that needs to execute. That's an important detail if the component is going to be robust, but over-the-wall developers--especially if they are overseas contractors--may not even be aware of the potential issue, much less know how to resolve it. In my hypothetical organization everyone knows how to correctly build a reactive component so I can focus on the interface instead of specifying implementation details.

I've mentioned the SlaveLoop in previous threads. I like using it in combination with the LDM because it presents a well-defined interface to a parallel component's functionality without adding the complexity of dynamically spawning clones. It's certainly not a well-known pattern. It doesn't really translate to text languages so I don't get any help from there. As far as I know I'm the only one who uses it. (Well, me and my hypothetical organization.) How much detail do I have to show or explain to get credit on the CLA? (It's a rhetorical question... I don't expect you to answer.)

I guess some of my uncertainty is due to a lack of maturity in LVOOP terminology, which is in part due to LVOOP's relative newness. We're all still learning how to apply ideas and terminology from other OO languages to Labview so one person's "factory method" might be another person's "creator method."

My understanding of the intent of the CLA, and how it is used by managers who look for the certification when hiring, is that the CLA is... <snip>... someone who can teach. <snip> "If you build them wrong, I'll show you why it doesn't fit with the rest of the system."

That is a sensible take on it, but I don't quite see how the exam's current format promotes that. Teaching is an interactive process between teacher and student. The CLA exam doesn't allow that at all. Furthermore, if I'm going to be teaching a junior developer I need to have a good understanding what he knows and what he doesn't know. The CLA guidelines simply say that someone else will implement the details; they don't give any indication about what these other developers know.

Link to comment

RE: CS terminology

Yes those term would help those being tested if they know them but the time the same in writting the question could inhibit the non-CS types.

I would like NI to put together an glossery of all CS terms that COULD be used on a CLA exam. It would include all of those phrases that non-CS type may not be familiar with by name.

The CLA Glossery would;

Be posted as part of the exam prep matial

Included in the CLA application

Included as part of the exam packet.

I feel it would;

help the CS types relax about the terminology

Aide in prep for the exam

Allow non-LV types to get a better picture of what a CLA has to know.

I do not feel it would in anyway decrease the effectiveness of the exam. After all, the exam is not a CS terminology exam.

Re: What Aristos said about a CLA training rookies. Thank you!:rolleyes:

Ben

Edited by neBulus
  • Like 1
Link to comment
  • 1 month later...

It would be worth asking whether the CLA graders would accept a VI that says, "Download standard toolkit XYZ from location MNO and instantiate the following template, then put that subVI here." ... and similar comments. Any of the tools like LapDog, or AMC, or ReX, or the Actor Framework, or the GOOP Toolkit might be usable then. After all, that's exactly the instructions I would give to a developer in some of these cases.

I would be happy with the following change - any free for commercial use code (i.e. free, not just trial mode) software that can be downloaded from the LabVIEW Tools Network should be allowed in the CLA exam. It is really frustrating to experienced developers when they can't use their standard tool-set (and one that is ultimately managed by NI) on the CLA exam. It definitely takes critical time away from creating an architecture when you are compelled to recreate architecture components (or even their interfaces) from scratch, especially when you already use them every day.

  • Like 2
Link to comment

I would be happy with the following change - any free for commercial use code (i.e. free, not just trial mode) software that can be downloaded from the LabVIEW Tools Network should be allowed in the CLA exam. It is really frustrating to experienced developers when they can't use their standard tool-set (and one that is ultimately managed by NI) on the CLA exam. It definitely takes critical time away from creating an architecture when you are compelled to recreate architecture components (or even their interfaces) from scratch, especially when you already use them every day.

I'm probably in the minority here (again biggrin.gif) but you don't need a software tool-chain to create an architecture. You are only using the LabVIEW IDE as your editor instead of (say) Microsoft word. The NI exams are specifically designed to be challenging in the time frame provided. However. If people feel the architecture for these fairly simple systems require a tool-chain just to realise it. Then perhaps the proposed architecture is over-complicated for the task (KISS).

Link to comment

However. If people feel the architecture for these fairly simple systems require a tool-chain just to realise it. Then perhaps the proposed architecture is over-complicated for the task (KISS).

I couldn't agree more. The best thing I took away from the CLD is that my approach was way too complicated for what I was being asked to do. My submission was good-enough to pass, but I didn't complete all the features. I've really concentrated on the KISS principle ever since. Thanks NI!

Link to comment

I couldn't agree more. The best thing I took away from the CLD is that my approach was way too complicated for what I was being asked to do. My submission was good-enough to pass, but I didn't complete all the features. I've really concentrated on the KISS principle ever since. Thanks NI!

location1.jpg

biggrin.gif

Link to comment

If people feel the architecture for these fairly simple systems require a tool-chain just to realise it. Then perhaps the proposed architecture is over-complicated for the task (KISS).

In principle I agree with you. As a practical matter, the simple architectures don't allow for the kind of flexibility that accomodates the changes customers commonly request, so I don't use them and don't practice them. Maybe customers do exist who have well defined requirements and don't ask for changes partway through development. If so, I haven't encountered them.

Link to comment
I would be happy with the following change - any free for commercial use code software that can be downloaded from the LabVIEW Tools Network should be allowed in the CLA exam.

I don't think that would work (we could put a whole CLA-style project in OpenG :) ), besides, most of my reuse comes from our internal reuse libraries, which certainly aren't externally available, nor free :)

Link to comment

we could put a whole CLA-style project in OpenG

It would have to be based on the sample exam to avoid violating NI's privacy terms. In principle the "real" exams could be made different enough to force users to change the structure while still allowing them to use the framework components.

Alternatively, they could restrict it to free code available on the Labview Tools Network.

besides, most of my reuse comes from our internal reuse libraries, which certainly aren't externally available, nor free

Well then, maybe this would provide some motivation to make them so. :D

(Or maybe not... I'm not sure there's a good business case for putting work into making it easier for competitors to obtain their CLA.)

Link to comment

(Or maybe not... I'm not sure there's a good business case for putting work into making it easier for competitors to obtain their CLA.)

Well the business case is seeing the forest for the trees. Turf wars over libraries will never help LabVIEW become a mainstream programming language. CLAs should be banding together and working with NI to compete with C# and Java. Part of that work is sharing the libraries that make a bare-bones LabVIEW installation actually productive for large-scale app development. Kudos to all OpenG and LAVA contributors for getting us that far.

I know everyone has proprietary libraries and has a right to keep them, I'm just saying that this is an issue that is holding the whole ecosystem back.

Edited by jdunham
  • Like 1
Link to comment

I'm just saying that this is an issue that is holding the whole ecosystem back.

I agree. I'm just saying I would have a hard time making a good business case (with real dollars and cents) for doing it.

Regarding competing languages, I've seen C# and VB in places where Labview could be used, but I haven't seen Java used in the test & measurement industry. Has anyone else?

Link to comment

Yes, be careful with architectures that are more advanced than what is typically submitted.

For my CLD, I used a MVC architecture with a subpanel plugin Controller process with messaging to the 'HMI' View.

This seemed appropriate since the fictitious system described would in practice be designed with an embedded controller and HMI.

I initially failed and assumed, since 2 qualified engineers had reviewed my exam, that I had misjudged

the rigorousness of the exam. Despite the 'all grades are final' statement, I contacted NI and it turns out

that somehow they missed entirely the 'process' code that was in the solution project. I did finally pass, but

clearly understood that no credit was given for the more 'professional' i.e. robust and flexible approach.

That to me is misplaced emphasis. It seems to me that if there was more time, most could add comments and

better vi descriptions, but understanding the best architecture to use is garnered from experience and skill.

  • Like 1
Link to comment

Yes watch out for submitted architectures that are more advanced than what is typically submitted.

For my CLD, I used a MVC architecture with a subpanel plugin Controller process with messaging to the 'HMI' View.

This seemed appropriate since the fictitious system described would in practice be designed with an embedded controller and HMI.

I initially failed and assumed, since 2 qualified engineers had reviewed my exam, that I had misjudged

the rigorousness of the exam. Despite the 'all grades are final' statement, I contacted NI and it turns out

that somehow they missed entirely the 'process' code that was in the solution project. I did finally pass, but

clearly understood that no credit was given for the more 'professional' i.e. robust and flexible approach.

That to me is misplaced emphasis. Obviously, if there was more time, anybody could add comments and

better vi descriptions, but understanding the best architecture to use is garnered from experience and skill.

The emphasis on architecture choice is more in the CLA, not the CLD. The CLD focuses on getting the app working and documenting what you did so clearly that someone else can pick up your app and figure out what you did. If two engineers reviewing the code missed the core of your app, I gotta say that does suggest some weakness in the documentation department. On the other hand, I've had days where I "just can't see the Matrix" and no amount of staring at the code makes it make sense. ;-)
Link to comment

Well actually there were no significant points taken off for documentation. No one ever said the code was obscure. In fact no explaination was given, just an oops and a grade change.

You could argue that the naming of your top level the 'VIEW' and the subpanel process the "Controller' in your init state was a pretty big hint. :)

Link to comment
  • 4 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.