Browse Month: August 2019

Reflecting on GDevCon #2

GDevCon #2 is wrapped. I’m really proud of the event we put on this year and its got me really excited about where we can take it next year. We’ve got plenty to think about and I hope that we can top it again.


I’ve taken some really interesting thoughts away and I thought it would be interesting to share them (and help me by having to describe them!)


Practical Talks


Our target from the start has been that this has to be valuable to all members of a team. The CLA summits are often a place to pontificate about architecture and design but that is of no interest to someone getting going with LabVIEW or working on an established framework but with engineering challenges and deadlines to meet.


This year I feel we got this much better. I believe that showed in the variety of levels, engaging presentations and useful takeaways.


Pragmatism


On the whole, it felt like there was a more pragmatic approach than other conferences (influenced by DSH workshop’s pragmatic software development workshop?).

This is a combination of confident presenters who were happy to present what they do and accept it may not be perfect but it works for them. This was then largely reflected in comments and questions that respected this. (while still looking to inform when there are other options as well)


This really excites me as I think it makes it a more friendly and open environment and hopefully might encourage more to speak so we get different perspectives on topics.


So think about this in future presentations. It works for you! and try and think about the pros, the cons and your context which all factor into it being a good engineering decision.

“Chill Out” Room

I still love having the streaming room. I get frustrated sitting in one place for too long so it was great to have somewhere to stretch out but not miss the content (as I often have at other conferences). It does cost money! But it seems to be valued by those who use it.


Ready for Next Year!

I hope we can start soon with planning next year so make sure your signed up to the mailing list at gdevcon.com to hear about it.

We will be asking for feedback soon as well so do let us know what works and what doesn’t. My final takeaway is that I can be very wrong about what people will like! I’m happy to admit that I had concerns about a few things this year and how they would be received that were completely wrong. So help me to be right more by telling us what you need!

The Graphical Tax

I’ve been thinking a lot lately about tooling. I’ve been getting my CI system running smoothly (ish, more on that later) as well as exploring another new language and working on open source projects on GitHub.

I’ve realised that there are specific penalties that we have to face as LabVIEW developers that are largely down to the graphical nature of LabVIEW.

In my head, I think of this as the graphical tax and thought it would be interesting to put these out there, see if there are solutions I’m missing or at least let’s have a discussion.

Software Engineering Tools

This one is an easy place to start.

Most software engineering tools assume a text-based system. Git works incredibly well on text. Github can merge requests in the browser on text-based files. CI tools use a text-based interface (the command line) to automate tasks like building, testing and linting your code.

As LabVIEW developers, we miss out on a lot here:

  • I’ve tried to plug the gap to CI tools with G CLI ( https://github.com/JamesMc86/G-CLI) but it is far from seamless as LabVIEW still has many cases where it pops dialogues.
  • Git etc. do work but don’t understand the files so manual merge and diffs all round
  • Any tooling for the language has to start from scratch. We can’t leverage what already exists.

This one is frustrating as software engineering marches on – we have to be careful not to get left behind. NXG promises to help a little with a human-readable VI format but I’m not yet convinced it will solve many problems (though some I’m sure).

Consistent Style

This is one that I think is really fundamental and just something we have to accept.

Compared to LabVIEW, text-based style seems simple! spaces vs tabs, newlines or not, camel-case or snake-case. There are certainly huge debates but it is essentially a 1D problem. It’s also easier to manage with linters and code analysis tools.

With LabVIEW, we take that problem and add new dimensions. Style is literally 2D. There is so much room for variation. So many mitigating circumstances for given diagrams that having a common set of skills is hard.

With text, you can add your own visual style on top with your editor while keeping the code “pure”. With LabVIEW, if you want different colours for your background it saves into the code.

A great example was a pull request I got on GitHub. After downloading the code to my machine many of the comments were too small. When I requested they were made larger to fit the text, they sent back a screenshot showing it fits on their screen.

This is an area that interests me in understanding more. I’m not sure if it is hopeless or we just need to be stricter. It certainly feels like a barrier to more collaboration and so something that should be considered.

Web Tools for Review

I think this is going to get harder and harder over time.

Increasingly the web is the centre of our working world. Text translates to that world well.

Recently I found a bug in an open-source javascript project that I wanted to fix. But I wanted to understand it more first, so I could go to Github and explore the code in the browser rather than littering my computer with hundreds of GitHub repos I want to study.

Review is also getting bigger. The place this really hurts for me is in pull requests on GitHub. When I receive a pull request for the C# part of G CLI it can be a 5-minute process. I can review the diffs in GitHub and understand what is going on.

With LabVIEW, you are forced to pull the project down to the desktop to open the IDE and view it. So when, like as I write this, I’m not on my main dev machine I may not be able to provide any comment on what is happening.

This could be improved by having sites with plugins for LabVIEW that can generate code images and diffs. I know some work has been done on this in Jenkins so it can be improved. But it will never be as straightforward as commenting on text code (line by line comments are handly).

Why Pay?

So why pay the graphical tax? Or:

If your just going to moan about it James then use text based languages

Well, there are still some hugely compelling reasons:

  • I believe it is easier to understand program structure graphically which greatly speeds up development and debugging. At least I’m a very graphical thinker.
  • There are no other tools that allow you to target desktop, real-time and FPGA systems with very little difference in syntax and concepts.
  • Even on a single target – there are not many other languages that combine a fairly high level of abstraction and the level of performance that LabVIEW provides.

So I still think I’m a net gain for using LabVIEW. I have no plans to jump ship any time soon. But maybe, by sharing my concerns, I might trigger some thoughts on how we can tackle these issues.

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close