GDevCon 1 Review

This last week I had the pleasure of attending and presenting at the first annual GDevCon in Cambridge. This post is about the presentations I saw and my takeaways.  I apologize for the length, but there was a lot of content crammed into those two days.  In order to do it justice required more than a few paragraphs.  I figure if you are really interested in seeing what you missed, you won’t mind.

Purpose

GDevCon is the first independently organized conference on graphical software development organized by leaders in the LabVIEW Community. This contrasts with NIWeek and other National Instruments (NI) Events which are obviously sponsored and organized by NI. If you are interested in learning more about why GDevCon exists and why they feel being independent is important, check out the explanation on their website. It really does a good job of explaining the spirit of the event. I really feel the organizers helped ensure that the event stayed true to its stated purpose.

Here are just a few of the organizers. From left to right: Darren Mather, James McNally, and Steve Watts. The entire list can be found here.

There was quite a sense of community and camaraderie among the attendees.  Here is a photo of me hanging out at the bar with some old and new friends afterwards. From left to right: Matthias Baudot, Wiebe Walstra, Gert, and Shane O’Neill.

Sponsors

It should be noted that there were some sponsors.  You can see the list here (NI was not among them).  The organizing committee was very careful to clarify that the sponsors had no influence over the content and simply helped to keep the cost of the conference for attendees reasonable by helping to pay for the venue and logistics and/or donating services such as Malcolm Myers volunteering to be the official photographer.  So if you run into any of the sponsors, thank them for helping to make GDevCon possible.

Overall Content

The conference was very well organized and the presenters all brought relevant content and were very engaging. There was plenty of audience participation and discussion, which sometimes rivaled the content in terms of usefulness. The information presented spanned the range of LabVIEW competencies very well. Even though particular presentations may have been geared more towards either beginners or experts, most of the presenters were able to include plenty of information that would be valuable to both. There was also a good balance between highly detailed tactical content, such as how to perform a very specific task in LabVIEW or how to best utilize a specific framework, and more high-level strategic content, such as software architecture considerations or strategies for managing teams of developers.

The agenda is available on the GDevCon website if you are interested in seeing who presented and what was presented. Note: Chris Roebuck was ill and did not attend, so everything got moved up and another presentation was added. The presentations were videotaped. I believe that will become publicly available, but I don’t know all the details at the moment. I will post my presentation later once the videos have been released.

Our Giants Are Female

You may have seen Fab’s blog post about this. A large portion of the presenters did choose to add a slide about an outstanding woman in technology.  A variety of women were highlighted.  Some were women you may have heard of before, some were more obscure (such as one presenter, Danielle Jobe’s, mother for example).  I did not make a list of them, but 2 did stand out.  One presenter chose to honor Fabiola de la Cueva and another chose to honor Nancy Henson.  If you have been around the LabVIEW Community for any time you will recognize their names and the contributions they have made over the years.

Here is my slide:

Presentations

I’m going to try to summarize the presentations I saw here and point out what I found particularly relevant. I did miss a few due to meetings and phone calls, so I can’t comment on all of them. If your presentation doesn’t appear, all it means is that I did not get a chance to see it.  The ones I saw were well worth the time to watch and from what I hear, so were the ones I missed.

Frameworks: An Executive Summary – Dr. Richard Thomas

When I saw the title I was very interested in seeing this presentation, particularly since from the title it seemed very similar to one that I had done a while ago. I was pleasantly surprised to see that even though they were both about the same topic, there was not a lot of overlap and Dr. Thomas really was able to add a lot to the discussion.

My original presentation on frameworks featured a very technical comparison of the DQMH and the Actor Framework. Dr. Thomas’ presentation was much broader. He introduced the concept of frameworks and the theory behind them. Then he gave an overview of all the available frameworks in LabVIEW and briefly touched a little deeper on a few of them to illustrate some of the differences. If you really wanted to learn about frameworks, it would be very useful to watch his presentation first and then mine.

Practical Design of Event and Message Handlers – Dr. James Powell

Dr. Powell gave a presentation about his Messenger Library and how he uses it as a basis for a framework he has developed. He was careful to stress that the Messenger Library is simply a library that can be used for any kind of generic messaging. The framework that he has built around it was simply the way he was using the messenger library.

At that point, the presentation dove rather deep into theory. Dr. Powell put it very succinctly: “A framework frames the way you work.” As such is it represents not just a bunch of code but a set of (often unwritten) mental rules of what to do and more importantly what not to do. This set of mental rules takes the whole realm of possibilities in LabVIEW and limits you to just a subset of it. As an example, in the case of the framework Dr. Powell uses and many of the other popular frameworks, the way you communicate between loops is limited. There is a dedicated communication path (in this case messages) and introducing other methods of communication is discouraged because it can cause significant issues.

Dr. Powell is certainly onto something with the mental aspect. I found that when I learned the Actor Framework, it really changed the way I thought about decomposing problems. I started to follow this mental set of rules on how actors should behave and communicate. When I encounter people who are having issues with either the AF or the DQMH, it is often because they have not adopted the set of mental rules associated with that framework. They start doing certain things that, when I look at them intuitively stand out to me because they break some of those rules. That is what causes most of their problems. Unfortunately, those rules are often unwritten. As a community, we should do a better job of clearly articulating those mental rules.

Dr. Powell also mentioned another technique I hadn’t really thought of that seemed quite powerful. He introduced the idea of adding continuation (or callback) to messages. When one of his actors would send a message to another requesting some data, that message would include a continuation. The continuation contained instructions for what the original actor should do with the data once it gets the return message. The original actor that sent the message doesn’t have to remember what to do with the return data because it is contained in the return message. It’s difficult to explain using just text, so if it is not clear, watch his presentation. He does a thorough job of explaining.

How Do I get started with my DQMH Project – Fabiola De La Cueva

Fab did a short presentation on some tips and tricks for getting started with the DQMH. There were quite a few. I’m not going to get into them here. If you use or are thinking about using the DQMH you should check out her presentation.

A Case Study in VI Scripting – Allen C. Smith

Allen used the AF Scripting tools as a way of introducing some tips and tricks on writing scripting code. If you are into scripting, you should definitely watch it. Here are a few techniques he highlighted:

1. Don’t reinvent the wheel.  Install the hidden gems .vipm package and look through it. There is some very useful stuff in there such as:
   1. Get Ancestors for a class without loading
   2. Save All this library
   3. Icon management
   4. Tags management
   5. Traverse for GObject by label
2. Creating wires is difficult. Avoid this by using scripting by wiring up dummy vis, objects or constants in your template and then replacing them
3. It is easier to delete code than to create it. When there are multiple possibilities, use case structures in your template with one case for every possibility. Figure out which case you need, select it and then remove the case structure.

Everything about PPLs – Matthias Baudot

Matthias did a very thorough presentation on using packed project libraries. There is way too much information in his presentation to go through it all here. He explained what they were and then went through the process of creating them. He clearly mentioned all of the potential problems and caveats (and there were quite a few). He showed how to use them to build a dynamic plugin architecture. He also showed how to use ppls to dynamically load and unload modules. I didn’t know it was possible to unload a class from memory, but apparently, it is. If you use packed project libraries, use a plugin architecture, have a large application that takes a long time to load, or want to distribute libraries for others to use without distributing your source code, you should definitely check out this presentation. Matthias covers how packed project libraries can help with all of that in great detail.

My Continuously Evolving Practice of Software Engineering – Brian Powell

Brian’s presentation was about building culture within a company and how that can evolve over time. He used lots of examples from his time at NI, Athena Health, and the Zebra. If you manage a team, it was the presentation to watch at GDevCon. I will attempt to summarize, but really you should just watch the presentation.

Here’s my summary. Software Engineering is an engineering problem and can be solved by applying process. The key is to do that in such a way that you get people’s buy-in. You do that by being reactive instead of proactive. It sounds counterintuitive, but you need to allow people to feel the pain a little so that they see the need for process. If you do that and then let them drive the development of the process it will be their process and they will own it. You can’t micromanage and do it from the top down. You also have to encourage dissent by displaying, as Brian put it, “Universal Positive Regard for other people’s intent”. That helps with buy-in and keeps you from charging blindly off a cliff. Another key is to focus on making progress on the long-term roadmap instead of just fighting fires. The last interesting takeaway I had was valuing failure because it’s going to happen. Instead, follow the process of Experiment, Fail, Learn, Repeat.

Basically, Brian’s presentation was 99% of what you need to know about leadership boiled down into an hour. Watch his presentation. It is well worth your time.

How to Blow Your LabVIEW Project – Joerg Hampel

Joerg’s presentation was a list of things that will cause your project to fail. Here are his 6 points:

1. Not talking to your customers
2. Not gathering requirements
3. Not planning tasks, schedules, and budgeting
4. Not Communicating with your team
5. Ignoring Best Practices
6. Not tracking your progress

Joerg’s presentation was entertaining with lot’s of audience interaction.

LabVIEW, Python, and Javascript – Danielle Jobe

Danielle’s presentation was about interfacing LabVIEW with Python and Javascript. Python has tons of useful libraries. Why reinvent the wheel when you can just use the python libraries by calling them from LabVIEW? The two examples she used were tensor flow for machine learning and opencv for vision applications. She enumerated 3 different ways to call python code from LabVIEW.  The second half of her presentation was about using javascript for better UIs. The one deficiency in LabVIEW UIs that I hadn’t really considered was responsiveness (ie. displaying intelligently on phones, tablets, and full-size monitors). Apparently, that is really easy on Javascript. Using Javascript with LabVIEW is as simple as building a web service in LabVIEW which provides the data and then hiring someone else to design a javascript UI which calls the web service.  Danielle finished with a live demo using a webcam.  The LabVIEW code used python and opencv to detect faces in the image and the broadcast the results using a web service.  The Javascript UI then interacted with the web service.

Dynamic GUIs – Wiebe Walstra

Wiebe gave a presentation on a toolkit he has built for dynamically scaling UIs. If you are tired of splitters, or if you are having issues with things not scaling exactly the way you want, you should take a look at his presentation. I could explain it, but it is better seen. It was impressive.

Taking the CLD with Nxg – David Barr

David took the place of Chris Roebuck, since Chris was ill and unable to attend. David recently took the CLD practice exam using NXG for the first time. He was able to get a working solution in a little over 4 hours. Overall that is good news, but he did run into some pitfalls. His presentation is about pointing those out so you don’t learn them the hard way. If you are considering using NXG in the near future or are curious how it is progressing, I suggest you check it out.

API Design Choices – Christian Butcher and Exposing the Holes of the Assert API – Peter Horn

Both Peter and Christian were very courageous and humble and decided to basically use the audience to perform a code review. They both got up there and basically said “Here’s this thing I am working on. I’m not quite happy with my solution. It may not be the right way to do it. What do you guys think?” To their credit, they were very receptive to the feedback. To the credit of the audience, everyone was very respectful. People in the audience asked very revealing questions and provided some useful suggestions. Both presentations demonstrated what a great community we’ve built.

Why Go To GDevCon2?

Well if you’ve read this far and you’re still not convinced, there is probably not much else I can say, but I will try anyway. The content and the camaraderie were excellent. If you get the chance, you should come and join us next year. I am confident it will be equally as good or maybe even better if that is possible.