October 16, 2018

What's in My Development Environment

What’s in the Box?!

I do a ton of development work across a variety of platforms. I like to tinker with automation in various scripting forms (Python, Powershell, some Golang, Ruby (because Puppet)). I like to tinker with my blog from a website perspective, so I’m doing a lot of web language work all of the time (HTML, CSS, Typescript/Angular, etc…). I use all of the above to work back with a number of different API endpoints (too many to list; but most commonly vRA/CAS these days). I’m doing a ton in Linux these days, so Bash is a frequent thing.

I’m not unique in this; If you’re reading this blog - odds are high you’re doing some of the above as well.

It got me thinking; what do peoples development environments look like? What are the main tools that people are using on a daily basis to do what they do? More importantly - if someone is starting on this journey, how can they gather some good tools together quickly to get started? Today we’re going to cover the following…

  • Visual Studio Code - my IDE of choice
  • Docker/Docker Compose
  • Chocolatey
  • VMware Workstation

It’s not a long list, but when you see all the things I’m using each of these platforms for - you’ll see that they form a solid support structure to helping me get stuff done efficiently. I’m a little bit all over the place with the things I’m working on - not everyone is going to be using all of these tools in all the ways I am. Let’s dive in!

Setting the Stage - Baseline Configuration

I wanted to cover at a high level what my OS level configuration looks like, to give a baseline for the applications and platforms covered later on

  • Windows 10 Professional Edition
  • Python 3.6 with Virtualenv
  • NodeJS 10
  • Google Chrome as primary browser - I don’t personally use a lot of Chrome extensions. I’m not against them at all - just not using any.

Now that that’s out of the way, on with the show!

Tools of the Trade

Visual Studio Code - The Most Dopest of IDE’s

There’s a healthy debate out in the community around what the best IDE is. For me, it’s VS Code hands down. There’s a lot of reason why I dig it so much…

  • Free
  • Insane plugin marketplace (specific dive in on this momentarily)
  • Constant updates and features being added
  • Active community
  • Kubernetes Cluster Integration (directly applying content to K8s is that fire)
  • Remote Code Share (For when Grant/Steve want to collaborate)
  • Solid GIT integration (commit everything, commit often)
  • Great theme choices (hate all you want; this matters)


Plugins, in my opinion, are where VS Code truly shines. I use a ton of different plugins to make development a lot easier. Plugins in VS Code can do a number of things. Many of my plugins are to help syntax structure or give “shortcuts” when building code. Some plugins extend the functionality of the VS Code IDE. An example of this are several plugins to expand the git (GitLens for example) capabilities. I use a GitLens for a number of reasons, for example seeing who was the last person to commit individual lines of the code im working on (effectively exposing ‘git blame’ capability in the UI). This is handy when Grant and I are working on our Python kit for interacting with Cloud Automation Services, to figure out who did what, when.

Attached is my list of plugins that I’m running currently running in VS Code. William Lam also posted a list of his here.

  • Code Spell Checker
  • Docker
  • Git History
  • GitLens
  • Go
  • Highlight Matching Tag
  • HTML CSS Support
  • Hugofy
  • IntelliSense for CSS class names HTML
  • PowerShell
  • Pettier
  • Puppet
  • Python
  • REST Client
  • Settings Sync
  • Start any shell
  • SVG Viewer
  • Terraform
  • VS Live Share
  • VScode Icons
  • YAML Support by Red Hat

What am I Doing In VS:Code?

Writing code. Stories done, right?

These days, my attention is split in a few directions. I’ve usually got multiple instances of VS Code running at a time (which is bad; I should be focusing on one - knocking out tasks, and shifting once tasks are complete…but whatever. Haters gonna hate.)

  • Enhancing the Python toolkit for easily interacting with VMware Cloud Automation Service APIs. This typically entails adding new Python functions (so I have the python plugin, obvs), and running tests the functions as I develop them. As I complete new functions, I’m commiting those changes from within the VS Code interface back into my repository. From there I issue PR’s to merge into our master repo.
  • Building Cloud Automation Service YAML Blueprints. Infrastructure as code is a core tenant in what we’re doing from an automation standpoint at VMware these days. As such, I’ve frequently got my repo of blueprints up through VS Code and am making adjustments to those blueprints. Same flow as above, making adjustments, committing these changes to my repo. As time moves forward and the Cloud Automation Services gets more GIT integration; this will pay dividends when I can attach these repos to aspects of CAS to have content imported!
  • Building Demo Content. I’m a huge believer that we should be building customized demo content that demonstrates solving problems that our customers have. Our demos should reflect things that our customers want to do with the platforms. When was the last time you saw a customer deploy an unconfigured wordpress environment? Thats what I thought.
  • Working with Puppet. I recently rediscovered a love of what Puppet “does”; especially the Open Source version. Working with Puppet manifests in VS Code, using the Puppet syntax plugins is massively helpful.
  • Containers. I’m doing a TON with containers/kubernetes/docker-compose these days. Leveraging VS Code for building dockerfiles, building Kubernetes YAML’s, building docker-compose manifests. The VS Code plugins help reduce silly mistakes (which of course still happen…) or help me understand expected behavior from blocks of code.

Docker / Docker Compose

Containers. Thats a thing still, right? Kidding…

I do a ton of work with containers right now; especially when I’m building webapps or demos. Building dockerfiles to deploy containers, pushing them into a local (running in VMware workstation) or remote Harbor repository (a tale for another time) is a frequent workflow for me right now. Recently, after working a ton in Kubernetes, I started deploying multi-tier applications using Docker-Compose (kind of backwards, since most people start with Compose and grow into Kubernetes - but hey, what are ya gonna do?). The awesome thing about doing what I do in Docker/Docker-Compose is that it’s consistent between environments. If I deploy a Docker Host in EC2, my same Docker-Compose YAML deploys into that environment the same way it does “on-premises” on my laptop. The obvious exception to this is things like persistent volume claims and such.

Sad news - Docker for Windows or VMware Workstation - Not Both

On Windows systems, you need to install the Hyper-V components in order to leverage Docker for Windows. Vendor alliances aside; this puts a serious cramp in my ability to leverage VMware Workstation. I could leverage Hyper-V for similar tasks; but my preferece (even before Pat was signing my checks) has always been VMware Workstation. Ultimately, this leaves me in a place where I leverage VMware Workstation and Ubuntu VMs for my “local” Docker/Docker-Compose work.

Chocolatey In Windows - Easy Package Management

I had heard about chocolatey quite a long time ago. It was a smaller “project” then; and to be blunt, it had a lot of garbage in it. I went away for a very long time. Recently though, I wanted a similar experience to the “apt get” feeling you get in the Linux world and it brought me back.

Chocolatey makes installing applications and packages very simple. In Windows, we’re used to this concept of “Download an MSI and execute it”. The struggle is, I spend so much time in command/powershell prompts these days - that often I just want to very quickly install a thing from an administrative prompt in powershell. When I installed the recent 1.0 release of Puppet Bolt, it was as easy as choco install puppet-bolt and I was off to the races. When I want to update hugo (my blog “engine”) it’s choco install hugo. Do I need to install the Puppet agent for a Puppet OSS apply? choco install puppet gets the job done. Very efficient, very straight forward!

VMware Workstation - Environments On Environments

VMware Workstation is one of the greatest and most under-realized treasures in the VMware arsenal; especially for “client side” development (not in the web sense of the word; in the infrastructure sense).

What am I doing in VMware Workstation?

I can’t always VPN into my homelab and SSH to a server. Sometimes I need to run a local environment for a variety of reasons. Maybe I’ve developed a new Puppet manifest and I want to run it on a fresh Linux box? Maybe I need to quickly spin up a Windows box to test some remote powershell? What if I’m on a plane and I want to work with a 3-node cluster, backed by NSX?

The flexibility that VMware workstation gives me when developing is unmatched, for the tasks I do. Being able to quickly clone out another machine, and connect “over the network” to it is an extremely common simulation I run. The ability to configure customized network configurations - and run an entire nested vCenter environment under workstation makes it easy for me to develop against a cluster wherever I am at on the go.

Programmatic Access

Many people don’t realize it, but VMware Workstation has an ever growing set of REST API endpoints. This enables programmatic access to common functionality inside the platform. That sounds very catch phrasey; but what about when I want to orchestrate a series of tasks as part of standing up a testing environment? The REST API allows me to easily build a process that allows me to get the environment to a state I need it to be. I’m a huge believer in automating our menial tasks - this falls into that category. If I have edge usecases, I can still do those manually!

What VMs Do I Typically Run in VMware Workstation?

Currently im on a fresh install (cleaned my laptop up!), so things are a little barren… that being said

  • Blank Ubuntu 16.04 Template VM
  • Blank Ubuntu 18.04 Template VM
  • Blank Windows 2012 Template VM
  • Windows 2016 Domain Controller w/ DNS
  • 2 Nested ESXi Hosts (Thanks to William Lam for his Content Library!)
  • Puppet Master running on Ubuntu 16.04

Continued Value from VMUG Advantage

Did you know you can get a copy of VMware workstation included in your VMUG Advantage membership? VMUG Advantage allows you to get your hands on most of our licensing, in a legal way, to configure in your lab environment! Not to mention all of the other crazy benefits that VMUG advantage gives. It’s totally worth it!

A Few Special Callouts

  • Postman - API Interactions from a GUI, with a rich library option for storing parameterized values. Critical for developing against APIs
  • NPM (Node Package Manager) - Used for installing packages against NodeJS, who woulda' thunk it?
  • Angular CLI - Tool for interacting with Angular Projects quickly
  • Puppet Bolt - Easily one of my new favorite tools. An agentless tool for running commands, scripts, and puppet manifests on remote nodes

Beyond the Laptop

This post was specifically covering a number of development items ON my laptop; but I have a number of services that I interact with often that aren’t on my local system. These will be covered in a future post - but my point in mentioning that is that knowing what tools exist for a given job is often times one of the biggest hills to solving problems. When you’re new to a concept (coding/scripting for example…) it’s hard to know where you can get started easily - and what tools will make you more efficient. I spent quite a long time writing code in Notepad++! I used to build new VMs for every web project I was working on! Knowing your tools gives you a greater breadth of options for development and delivery, but also can free you up to get back to doing what really matters - creating cool things!

I hope this helped out! Leave me some feedback on twitter @codydearkland if so!

(c) 2021 Copyright TheHumbleLab