Before we head in to my specific learning path of Go, I would like to take you on a brief tour of what problems I am trying to solve. Where I work there are loads of opportunities to automate small things, solve small but time saving issues, and gather data and metrics from systems. I need to be able to write small applications to help me solve all of these, and also pass these solutions over to my team for continued support.
We are mainly a Microsoft focused development house and as such we host Microsoft SQL Servers, run Office 365, and use Windows Desktops. We are starting to use other server and desktop environments such as Mac and Linux. To future proof whatever I was doing, and to make it easy to target any system, I wanted a toolset that was not tied to a specific operating system. I run Mac systems at home so it would be great if what I was doing at work is also something I could learn at home.
Some of the tools I looked at were AutoIT and AutoHotKey, two very popular utilities in the Windows world for automating common tasks. The two major issues with these tools is that they are Windows only, and their scripting languages are somewhat bizarre from a programmer’s viewpoint. They do the job, but they are not a great language design. However, these are excellent utilities for UI automation, as you do have fine grained control over mouse, keyboard, and window management. In my case, this is not what I needed, and so I abandoned these tools for this case.
I also looked at .NET Core, which is probably the most equivalent to Go in terms of problem domain. It also works across platforms, and is pretty simple to get up and running. One if its downfalls for this particular scenario is that it still needs a large runtime to support any executables you create. This may or may not be an issue for you, but I needed a statically linked single binary. You can get quite close with self contained executables, but this is a much larger package than the Go ones I can create as it includes the .NET Core runtime for each package. It also requires button twiddling to get right.
Finally, Go came across my desk through a TIOBE report (if I recall correctly). This language intrigued me as it is simple to learn, simple to read, and is pretty on par performance wise with .NET Core. You can also target an executable for any operating system from any operating sytem. Yes, that’s right, I can create a Linux binary from my Windows machine, from the same source, with the same toolset. So that problem is solved for me. It’s also a bonus that Go is becoming a very popular choice for micro services, something that our company is heading towards. It helps that it’s the TIOBE Language Hall of Fame winner for 2016.
I need to connect to custom Web APIs and Microsoft SQL Servers, along with various other systems. I either create CSV files of output, output SQL scripts for deployment, or just output to the console. What I don’t need to do, at least at this stage, is write GUI interfaces, or automate anything GUI related. My team’s work comes through JIRA and Remedy, and we capture our Remedy tasks in JIRA manually. We do need to be able to ask some simple questions about this, for example:
- What new tasks have appeared in Remedy that we have not yet captured in JIRA?
- What tasks in Remedy have new updates that are not in JIRA?
- What updates in JIRA have not made it to Remedy?
We get all our updates from our IT support team via Remedy and we work in JIRA. We send work to various development teams in our organisation via JIRA. They, in turn, send details back to us via JIRA. We need to selectively keep JIRA and Remedy up to date, but we cannot mirror each system. We cannot automate this as we need to sanitise and summarise a lot of the discussion from JIRA in to Remedy and vice versa.
The JIRA API is a JSON WebAPI and the Remedy database is a Microsoft SQL Server. I struggled for weeks trying to get a working connection to Microsoft SQL Server in tools like AutoIT, or to get a working JSON parser. I gave up on AutoIT as JSON parsing is hard, and there’s very little information about connecting to Microsoft SQL Server reliably. Once I’d figured out how to consume Web APIs and connect to databases using Go, I had a solution up and running. A Git user named denisenkom has provided an excellent native Go Microsoft SQL Server database library, and Go’s standard library has a great JSON parser for free. I could now answer my 3 questions.
Along the way I’ve created a little Hash utility, another utility to easily create SQL files for deploying a complex system live (Go has templates, something I will elaborate on in a later article), and a quick Web API to host an end point for one of our own systems. All of this in Go, and each one can be done in a matter of hours. Since I am not a full time developer at work, I certainly need something that is both easy to write, and more importantly, easy to read by myself and my team. Future proof also means “it can be read by someone who has never used Go”.