The administration abundance chain, accepted for rolex replica uk its affordable accouterment and home apparatus offerings, is now peddling high-end artist accoutrement from above labels including, Chanel, uk replica watches and Zac Posen.The artist appurtenances will be awash on The Sears Marketplace through third-party vendors. The fake watches move may assume counterintuitive, but a Sears agent says it takes the administration abundance aback to its roots, which already included affairs cars.
Developing Go in Atom – Failing Forward

Developing Go in Atom

When I started developing software a few years ago, I was introduced to the wonderful world of Integrated Development Environments (IDEs) from the beginning. While these environments have their disadvantages, the primary benefit that I always got from them was the deep autocomplete functionality that they provided. This allowed me to give meaningful (and sometimes lengthy) names to functions and objects without having to worry about remembering exactly how I named it later.

When I started using Go, I looked for that same experience and found it in the excellent goclipse IDE. I used this for several years, but started to become dissatisfied with it due to the its occasional laginess and the quirkiness of Eclipse that I have never been able to get used to. As a result, I started to look for a new, text-editor based development environment. However, there are a couple of pieces that I had to put together to get it right.

The Editor

There are many text editors out there that have support for Go, so the first step was to settle that question. The big players that are out there appear to be:

Since I come from a Windows background and my history with programming is based on IDEs, I’ve never really been able to get comfortable with Vim. I believe that it is ultimately one of the more productive tools out there, but I’ve never been willing to pay the price to achieve that level of understanding so I took a pass on that.

Sublime is great and has, in many ways, led the text-editor revival that we are currently in, but I’m not a fan of its closed-source nature. Also, there was a newer kid on the block so I never really gave it the chance that I probably should have.

Eventually, I settled on the Atom editor that was initially created by github. It is open-source, easy to customize, runs on any platform and has a thriving plugin ecosystem. To be fair, I think that each of these editors makes an excellent platform to develop Go with, but eventually we all have to make a choice; this was mine.

 

The Plugins

Every text editor that wants to be taken seriously as a development environment has to address the plugin question. Without an ability for the community to expand and grow the capabilities of the tool, it can rapidly become irrelevant as technologies grow and evolve. Atom uses the “Atom Package Manager” or apm to manage the plugins that are used by the editor. Apm can be accessed via a terminal window (via the ‘apm’ command) or within Atom under the Settings menu. For Go development, the plugin of choice is go-plus that is supported by Joe Fitzgerald. It exposes quite a few tools that are used when developing with Go and even has functionality to retrieve any tools that are missing and update them. Here is a summary of the integration that go-plus provides:

  • Automatic code formatting via `gofmt`, `goimports`, or `goreturns`
  • Code quality inspection via `go vet`
  • Linting via `golint`
  • Test coverage generation via `go test`
  • Autocompletion via gocode (more on this in a bit)

Autocompletion

Go-plus is almost all you need to get working in Go. It’s ability to bootstrap itself with the latest tools and keep them up to date means that you generally don’t have to worry it. Go-plus will take care of things for you. However, there was one tricky bit that I had to work through in order to dial everything in the way that I wanted to.

In Go, autocompletion is normally provided by the gocode library. It’s been around since July of 2009 and has become the de facto standard for providing autocompletion support. It subscribes to the popular trend of providing a service that other tools can plug into. It is started as a service that waits for autocompletion requests and then inspects all of the code in the current file and on the GOPATH to determine the possible matches. Since it does this in a platform agnostic way, it can be integrated into a wide variety of development environments and, in fact, forms the basis for autocompetion in Vim, Emacs, Sublime, Atom, Goclipse, and several others.

When I first started working with this stack, everything seemed great. I had quick, reliable tools that made developing in Go pleasant. However, I started to run into problems as soon as I stared using multiple packages in my application. It seems that gocode couldn’t find the types and functions in my packages, but it could for any built-in functions and third party libraries that I had installed via the `go get` command. It took some digging, but I eventually discovered the answer and had to add one more tool to my development stack. First, let’s describe the issue.

The Problem

When gocode is called upon to provide the autocompletion options, it examines all of the code in the current buffer as well as code that is accessible via the GOPATH. Initially, I thought that it was parsing the source code in order to do that. What I discovered was that gocode actually inspects the libraries that are compiled and stored in the projects ‘/pkg’ directory when `go get` is used to retrieve a library. Since my packages weren’t compiled, gocode couldn’t find then and, therefore, couldn’t provide me will all of the correct options. I could get things to work as expected by using the `go install` command to install the package; gocode would immediately light up with the correct options so I knew I had identified the problem. I did not, however, want to manually install each of my packages whenever I changed a line of code. Something had to be done.

The Solve – Automatically Building Packages

While I understood why gocode took this step, I was left with a problem – any non-trivial application that I was going to write needed to have multiple packages and I didn’t want my autocompletion tool to occasionally fail on me. After looking around a bit, I didn’t see any standard work arounds for this, so I rolled my own. Primarily, I am a web-developer and so have become used to working with Node-based automation tools such as gulp and grunt to automate client-side tasks such as running unit tests and minifying JavaScript. Since I was already using gulp in my project, I decided that it would be a convenient place to build a small script that would install my custom packages whenever they changed.

I am not a gulp expert and I wanted something quick, so I had to research for a while until I got something working. Here is what I eventually came up with:

var gulp = require('gulp');
var path = require('path');
var shell = require('gulp-shell');
var goPath = 'src/pack/**/*.go';

gulp.task('compilepkg', function() {
  return gulp.src(goPath, {read: false})
    .pipe(shell(['go install <%= stripPath(file.path) %>'],
      {
          templateData: {
            stripPath: function(filePath) {
              var subPath = filePath.substring(process.cwd().length + 5);
              var pkg = subPath.substring(0, subPath.lastIndexOf(path.sep));
              return pkg;
            }
          }
      })
    );
});

gulp.task('watch', function() {
  gulp.watch(goPath, ['compilepkg']);
});

Let’s break this down one piece at a time. At the top of the file are the imports that make different modules available to the script (similar to import statements in Go). After that is a variable that holds the pattern for files that I wanted to keep an eye on. This demo project had everything under the package “pack” and so you see that in the second position. This could easily have been changed to ‘src/**/*.go’, but I had other code floating around this app that I didn’t want to get autocompiled and so I needed to limit things a bit.

The next block of code is the definition of the task itself. It starts with the task’s name – compilepkg and is followed by the function that actually installs the package. The function calls the gulp.src function that tells gulp which files that we’re interested in processing. It then passes files that match that pattern into the pipe function. That function calls the shell function which invokes a command in the operating system’s shell. The rest of the code in this section it just fiddling around with the path in order to convert the absolute path to the package name that the `go install` command requires.

At the end of the script, I defined a ‘watch’ task that starts watching for the relevant Go files. When one of them changes, then its entire package is recompiled and ready for gocode to use.

Whenever I start working on a project, I simply open a terminal and type `gulp watch` in the project’s root folder to kick everything off and I’m ready to Go.

 

If you want to learn more about Go, checkout my courses on Pluralsight. I regularly create new content that explores different aspects of working with Go.