Programming – Christopher Stryker

“Contain” your excitement!

Forewarning: For this to work, I suggest you have a rudimentary familiarity with Powershell. I believe this also requires an active NI SSP agreement, but you might be able to work around that.

OK, for those who don’t pay attention outside the LabVIEW community, using Docker for continuous integration is all the rage. Why? Well, a variety of reasons. For one, the ideal state is having a different build “machine” (or virtual machine) for every project you work on that builds it, and only it. Traditionally that hasn’t been a possibility.

Building LabVIEW Installers

To be honest, I’ve built basic LabVIEW installers before, but I’ve never needed to install crazy (non-NI) dependencies or write registry keys or anything “advanced.” Well, that is, until today. Here are some quick lessons I learned:

Finishing Your GitLab Configuration

This is one of a series of posts on “Demystifying the Magical World of DevOps”

Alright, so, as of last time, we have our basic GitLab instance installed and working. I’m not going to go through exactly “How do I Git” or “How do I GitLab” right now, but there are lots of good resources out there. Googling is useful, but I’d start with the GitLab Basics Guide. A later post will go in to my take on those topics and more importantly, how to use Git with LabVIEW.

So for now, let’s dive in. We’re going to do a few things this time:

Configure backups
Enable LDAP authentication
Configure the SMTP settings
Configure third-party integrations

Installing a DevOps platform

This is one of a series of posts on “Demystifying the Magical World of DevOps”

As of last time, we finally have a Hyper-V server with a copy of Ubuntu server on it. Now let’s actually make it in to something useful. We’re going to install a copy of GitLab Enterprise Edition on it, and do some basic configuration. Stepping back for a moment, however, why GitLab EE?

Installing an OS on your VM

This is one of a series of posts on “Demystifying the Magical World of DevOps”

Alright, so, we have our Hyper-V server up and running, but as you may have noticed, it’s not very useful at the moment; it needs an actual VM with an OS on it.

There are a couple things to consider before we get started:

What OS do you want to use?
Does the VM disk image need to be encrypted?

For this post we’ll be creating an encrypted Ubuntu Server.

Setting up a Hyper-V Server

This is one of a series of posts on “Demystifying the Magical World of DevOps”

Most of the content here is not applicable if you are going with a cloud-based solution.

I’m a huge fan of virtual machines. For those not familiar, VMs are essentially a way of running a completely independent OS inside of another. (Note that this shouldn’t be conflated with containers, which are similar but share underlying components with the host OS. More on that in a future post in this series.)

Hyper-V is a hypervisor created and distributed by Microsoft. In it’s simplest sense, a hypervisor is simply a platform for running virtual machines. I’m a huge fan of Hyper-V for a variety of reasons, some technical and some logistical, but I do feel compelled to point out that there are other solutions out there, such as Oracle’s VirtualBox and a variety of options made by VMWare. Today though, let’s just talk bout Hyper-V.

Demystifying the magical world of DevOps

Note: This the introduction to a series of posts on building your own DevOps infrastructure.

So, everyone knows that source code control is mandatory, unit tests are great. And hey, that thing called continuous integration? Yeah, you should be doing that.

When done properly, the results are fantastic. But let’s be honest… how many of us actually have the infrastructure in place for all of this?

Here at Hiller, we already do a good job of SCC, but we’re embarking on a journey to implement a full DevOps solution. Now, there are already a variety of resource detailing how you can do most of this, but we have a twist, as we must have provisions to be ITAR compliant for many of our projects. As such, we can’t use GitHub Enterprise, the cloud version of GitLab, or many of the other solutions out there.

So, as a general outline of the plan:

Create a Hyper-V server
Create a VM and install an OS
Install and configure an instance of GitLab Enterprise Edition
Finish up configuration
Create a “build system” for our CI
Develop and discuss a solutions for automated testing

As we go, I’ll generate blog posts on every step of the way. You can watch for posts with the “DIY DevOps” tag, or just keep an eye on this page, which I’ll edit and post links to new entries as I make them.

For reference, we’ll be hosting everything on-prem (at least initially). In my posts, I’ll try to make note regarding the differences between a cloud-based approach and what we’re doing (and how we may partially migrate to a cloud based approach down the road).

Act(or)ing up in NXG

So, like everyone else, I’ve been on the edge of my seat, waiting for NXG 4.0 to release. It finally dropped on NI Package Manager today! Wait, everyone else wasn’t opening NIPM several times a day waiting on NXG 4.0 to finally appear? Oh, well, here’s why you should have been.

NOTE: This post wouldn’t have been possible without my employer, Hiller Measurements, who provides me access to the software (and is also a pretty darned awesome place to work).

2019 CLA Summit: Top 5 Takeaways

For those that weren’t aware, the 2019 CLA Summit was held September 25-27 in Austin. I was fortunate enough to attend, and now that I’ve caught back up at work, figure I should highlight the points I found most interesting.

Worth noting, every session was recorded, and will be posted over at www.LabVIEWwiki.org along with the slides from each session. Major thanks to Q, Mark and everyone else involved in that effort!

To be clear, there was a TON of information there, and there’s no way I can do it justice in a single post. I’m going try it anyway, however, with full understanding that I’m leaving many things out. That said, I’m biasing my list towards things that are immediately actionable by the majority of readers, not just CLAs. So, without further ado, my top 5 takeaways (in no particular order):

Derived Base Class Restriction

I was writing some code to dynamically load a class the other day, and came up with this little nugget. I can’t seem to find anyone who has done this before, so I’ve dubbed it “Derived Base Class Restriction.” (Note: If someone else has already published this, let me know!)

We’re going to assume the following class hierarchy:

Let’s say I’ve built a framework that uses Abstract Class for some plugin. If I’m writing a particular application for a given customer, I might make Concrete Class 1, and use it as a starting point. I may add descendants, and customers may even add further descendants beyond that.