CLA Summit 2018

Friday marked the end of the 2018 CLA summit in Austin. It was 2 and a half days full of presentations and discussions. Kudos to Jon McBee and Jeremy Marquis for running the summit and leading the discussion.  Stephen Loftus-Mercer also helped in the organizing, but he was sick and unable to attend.

Officially Wednesday was about “Build Tools and Tool Chains” and Thursday was about “Solutions to Complex Problems”.  However, the 2 main themes I saw over the whole conference were: 1. How we create tools and 2. How as a community we can collaborate on tools and share them with each other.

Creating Tools

Several people talked about various tools they had created.  Due to the format, I was unable to see all the presentations, but I hear they will all end up on the COE website next to the SEPAD presentations from NI week.  In general, these presentations were a mix of cool useful tools and scripting tips and tricks.

Quentin Alldredge aka Q, presented on several of his tools, particularly his Q controls, which are a very clever replacement for xcontrols.  If you ever wanted to make an xcontrol but were intimidated, this is a much simpler solution.  You should definitely check it out. The toolkit is free and he also has a few very useful Q controls that he distributes for free with the toolkit.  In his 7×7 he also threw out a few other useful tools he has created.

I presented about my AFTester and Allen Smith presented about his project provider tools for AF.  My presentation was more of an overview of what the tool does and some of the design decisions I made, but Allen’s was much heavier on scripting details.  He has lots of good tips and tricks in there. I highly recommend checking it out. Allen and I also did a 7×7 on a UI Actor tool that we built that automatically adds event support for indicators inside GUI Actors (ie. it automatically creates the event, adds it to the actor’s private data, and destroys it).

Speaking of Actor Framework, Ethan Stern gave a presentation on his MVA framework which is built on top of the actor framework.  Basically it adds a mediator bus that the actors access to publish and subscribe to data. The framework also handles inserting UIs into subpanels. It let’s you create some really cool nested UIs.  It also helps to completely seperate the UI logic from the business logic. The framework does that using the Mediator Bus, which is basically another communication channel that bypasses the normal messaging system. Normally that would concern me, but I think here they have found a good reason to bypass it.  This was more of a demo. If you want details, check out his previous presentation (I think it was the last CLA summit).  The demo was really slick. I definitely downloaded a copy and am going to check it out.

When it comes to tools Darren was quick to chastise those who are not using VI Analyzer.  If you are not using it, you should check out his 7×7 presentation.  Whatever excuse you happen to have, he has a response.  There really is no legitimate excuse.

Collaborating

Derek Trepanier and Matt Harrison from MGI gave a presentation on workflow for using gitlab (or github, bitbucket, etc) to collaborate on opensource tools.  They talked a lot about how to set things up with licensing and contribution guidelines.  Then they demoed the process for a community member reporting a bug.  They also demoes the process for a developer to fork the project to make changes and the whole merge/pull request process.

Derek also gave a presentation on a new package manager he is working on called GPM.  I missed his presentation, but I have talked to him about it in the past, so I kind of know where he is coming from.  The big idea is that his package manager installs packages on a project basis (in your project folder) instead of installing them for all of LabVIEW.

So here is my brief summary (as I see it), for the use cases for the various package managers.  I feel like they all still have their place – at least at the moment.

• NIPM – This is used to install most NI software and drivers: LabVIEW, TestStand, DAQmx, etc.  It’s also great for packaging third-party installers and binaries. It can also support distributing ppls.  It can run some pre and post-install actions, but they have to be .exes.  It also has no palette support if you are distributing source code.  It also doesn’t have support for installing a package to multiple versions of LabVIEW. So it’s not so great for reuse code.  There are some other issues, but I haven’t really played around with it enough to comment.
• VIPM – This is useful for installing LabVIEW-wide toolkits.  Examples would be DQMH scripting tools, MGI class Method Browser, etc.   It is nice for reuse code as well since it handles the palette building and handles multiple versions of LabVIEW.  However since it installs to .vilib you get one version for the IDE, which is not project-specific.  VIPM does have the idea of VI package configuration files (.vipc) that can be associated with a project and used to manage versions.  You do have to pay to create that though.  You also have to pay (or go through the NI Tools Network) to make your package globally available.  Overall really great for scripting tools that create or edit code and for setting up your LabVIEW environment via pre and post-install vis.  For toolkits of reusable vis, there are some issues.
• GPM – The main issue Derek was trying to solve was having different projects that use different versions of a toolkit.  Since vipm installs packages to the IDE, you have to jump through hoops with .vipcs to make sure you have the right version.  If you don’t use .vipcs it is very easy to run into problems. Even if you do use them, you have to remember to manually apply them when you switch projects. Derek’s solution to that is to install the toolkit into the project directory so the installation is project specific.  This way the toolkit vis can also be put into source code control. So for packages of reuse code, this appears to be a better solution.  I need to play around with it before I can make a final judgment.

Miscellaneous

Dmitiry gave a presentation on “Design by Contract.” (DBC)  He introduced the concept by talking about the Arian 5 Rocket failure and how perhaps DBC could have prevented it. Then he covered how DBC is implemented in Eiffel. He went into lots of details. If you are interested in that you should just watch his presentation.  He talked about how DBC is implemented in other languages and how it could be implemented in LabVIEW.  He talked about Unit Testing as part of it. He also touched on the importance of adding some sort of Interfaces or Traits to LabVIEW.

Probably the best presentation of the whole summit was Chris Cilino’s “Everything A Software Engineer Should Know That Has Nothing To Do With Software.”  It was all about dealing with office politics and trying to promote yourself and your ideas. It was on par with Brian Powell’s presentation at GDevCon.  I cannot possibly do it justice here, you should just go watch it.  I will mention a few takeaways though.  The best political currency is trust.  Building trust with your boss and coworkers is key.  Chris went into detail about various ways to do that.  He also talked about “Defense Against the Dark Arts”, which basically dealt with toxic people and how to deal with them.

Conclusion

There was a lot of interest in collaboration overall.  Most attendees realized the value of not reinventing the wheel and leveraging what others have already done.  There was some concern about regulated industries.  There was also some concern about licensing.  There were also lots of different ideas about the best way to collaborate.  There was definitely some mourning over the decline of the lava forums and discussion about what might replace it as an online community.  I don’t know that any of that was really settled.