Meeting Thursday 2014-November-13: Thoughts after NIWeek 2014

[FabiolaDelaCueva]

UPDATE (Recording Available)

View at youtube.com/laftracks or embedded below.

Meeting Logistics

• Location: Mopac C - 1S13 @ NI headquarters 11500 North MoPac Expressway, Austin TX
• Date: Thursday, November 13, 2014
• Time: 6:00 PM
• Duration: ~ 2 hours
• Format: presentation plus group discussion

Food: National Instruments will sponsor food for this meeting. We will need an accurate headcount, so please register here. We will need National Instruments members to register as well, for that, you will get an internal invitation. If you are not sure if you are in that internal list and want to be, please let Fabiola know (fabiola@delacor.com). If you are attending remotely, there is no need to register, just let us know where you are joining us from when you log in.

Meeting Description

"An Early Adopter's use of the CEF (Configuration Editor Framework)"

At NI Week 2014, the Configuration Editor Framework was released. The CEF is a framework for providing system configurations for applications. In particular, it is designed for tree-like configurations with built-in support for dynamic addition/removal of componets. Aaron used the released version in a recent project and  he     will share some of the advantages it offered, as well as some learning moments/bugs that he had to overcome. 

Presenter: Aaron Gelfand from Gelfand Technology Est. Duration: 30 minutes + 10 minutes for Q&A

"Some Thoughts about Accessor Methods"

People are often quick to create Data Member Accessors and to use properties out of convenience without considering the OOP-bending and practical consequences of this decision. Let's take a minute to discuss the [appropriate] use of Accessor Methods and possible coding guidelines that result. I'm very interested to hear what guidelines you've created for creating and using Accessor Methods.

Presenter: Nate Moehring from SpaceX Est. Duration: 30 minutes + 10 minutes for Q&A

"Open Mic"

Presenter: ?? Est. Duration: 10 minutes / person

If you have anything cool you are working on that you would like to share with the group or if you want to ask questions, brainstorm in a new architecture come prepare to present to the group.  If possible, let fabiola@delacor.com know in advance what you would like to present.

Remote Attendance

Thanks to Sixclear for sponsoring remote connection. If you absolutely cannot make it to NI for the meeting, we have remote connection options.  You will be able to participate in the meeting remotely, including viewing presentations live & joining a conference line.

Join the meeting: https://join.me/242-480-164

On a computer, use any browser with Flash. Nothing to download.

On a phone or tablet, launch the join.me app and enter meeting code: 242-480-164

Join the audio conference:

Dial a phone number and enter access code, or connect via internet.

By phone:

United States  +1.213.226.1066

Access Code  242-480-164#

Other international numbers available

By computer via internet:

Join the meeting, click the phone icon and select 'Call via internet'. A small download might be required.

***Remote Attendee Special Request***

Please mute your phones during presentations to help minimize background noise for others joined on the conference line.  To ask questions or supply comments simply pipe up, or better yet, use the chat window (available when you join the screenshare) which we'll monitor throughout.

[jlokanis]

Will this be recorded?  I really want to attend but I have conflicts with the meeting time.

[Charles_CLA]

We will try but I can't make any promises.

[FabiolaDelaCueva]

Thanks to everyone who attended the meeting yesterday or joined remotely. I hope you like the meeting as much as I did. The presenters were great and it was really hard for me to stop the open mic session, I wanted to learn more. I will be starting a new post to ask for ideas for presentations for next year.

Also, I promissed I would expand on my comment regarding LVOOP scopes, here it is:

Yesterday I mentioned that I had seen customers stay only with private and public scopes and avoided Protected.

I went back to look at my notes, the one that they avoid is "Community" scope. They leave private, protected and public as options.

In my code I use private until proven otherwise, then protected for children to access parent data and public for everything else. I stay away from Community scope, some links on the subjec:

http://lavag.org/topic/16251-community-scope-unfriendly-to-password-protection-bad-design-decision/p...

http://lavag.org/topic/16348-cannot-dynamically-launch-friended-community-scope-method-screenshot-co...

Regards,

Fab

[smithd]

Someone in the back of the room said they had a script or quick drop shortcut for wrapping methods with a DVR IPE structure. If that person is listening: is that code available anywhere online?

[Nate_Moehring]

Uploaded my presentation

As with most things in life, there are pros and cons to Accessor Methods.  This presentation was difficult for me to organize because I frequently break many of my own recommendations.  For example, I like being able to call accessor methods in property nodes and want the same capability for methods. And yet I also believe this convenience can lead to bad habits that sometimes causes us to get lazy in protecting encapsulation.

I also talked about references in objects.  In general, I think classes should be all by-value or all by-reference if possible.  I really like the GDS implementation of by-ref classes and don't have any problem with storing a DVR as THE private data of a class.  Its the hybrid classes that can be problematic, but is also required for many design patterns and feature implementations in LabVIEW.  That's why its important to communicate to your clients, in a variety of ways, how to correctly use your class.

If nobody ever modifies/extends your code besides you, then these things may be of little consequence to you.  But I hope this presentation created some space for you to think about one small aspect of LabVOOP programming that I believe most people have given little consideration.

[Charles_CLA]

smithd, I wrote the code about a year ago. I'll try to get it cleaned up enough for release today. The right answer is for NI to make all class input accept either a ByRef or ByVal class. I certainly don't want this utility to be used as an excuse as to why NI doesn't fix it the "right way". http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Have-Dynamic-Dispatching-terminals-accept-Data-Value-r...

[smithd]

I don't have any more control over that than you do, unfortunately, but I did kudos that post.

Anyway, I'm very interested to see what you've got

[Charles_CLA]

smithd, here's a link to the document I created with the code.

[smithd]

Nice, thanks. If I find some time I might take a stab at converting CreateRefWrapper.vi into a quick drop like you mentioned.