It’s been ~3 months since Deis officially joined the Microsoft Azure containers team.

Recently I posted a link on the /r/golang subreddit announcing that Microsoft is hiring Go engineers to work on Kubernetes. The responses were overwhelmingly positive, and I had the chance to reflect on what our culture is like for one Redditor who asked in a DM. I gave them a summary of how we do our work, and thought it would be useful to share publicly so here it is.

We are very practical and realistic, and generally like to think about a new project or feature before diving in.

I heard recently, outside of work, that there are 3 ways to implement software - the way that takes 200 hours, the way that takes 100 hours, and the way that takes 7 hours.

I believe that regardless of which way you take, you can end up with the same core functionality, but if you take the 7 hour approach, you’ll have a...

At Google Cloud Next, Google announced that Google Container Builder is now generally available in beta.

Very simply put, container builder is a CI service that runs pipelines of build steps. Each step is run inside a Docker container.

I have a lot of experience with developing locally in Docker containers. I’ve even taken a stab at building a tool to help me do so, called Godo. We at Deis have also been running containerized CI jobs for a long time inside Travis CI (example: https://travis-ci.org/deis/builder). I have a lot of experience with running docker-based CI jobs.

After learning all about Google Container Builder, I decided to give it a shot for one of my personal projects. Below are my thoughts on the product.

Pipelines are Great

Many CI systems (Jenkins, Wercker, Travis, Circle) let you define your jobs as a pipeline, and it’s a great abstraction.

Container builder lets...

Summary: I’m looking for contributors to do part or all of a screencast for Go in 5 Minutes. Email me at arschles+gifm@gmail.com if you’re interested.

A few months ago, I decided to put together Go In 5 Minutes, which is a series of 5 minute (you guessed it) screencasts about one topic at a time.

My original goal was to take something really focused, boil it down, and present it an in easy way for any Gopher to get started on the topic. The project is going strong today. Here are the vanity stats as of this writing:

• 398 GitHub stars
• 1,184 YouTube subscribers
• 302 subscribers on the mailing list.

I’ve found that the project is a lot to manage along with my other responsibilities in life, so I’m going to try some new ways to provide the same type of content. The community will stay the same, and all the videos, code outlines will remain open for the foreseeable future. You can always...

A while back, I developed a Go web app on Google App Engine, and naturally I used html/templates to render web pages.

In production, ParseFiles calls were failing, and I’m still confused whether reading from the filesystem is allowed and reasonably performant on GAE. I also have some other Go projects that run a web server, and I’d like to ship only a binary, not extra template files.

I’m using go-bindata to bundle my templates with my code. In doing so, I found I had to keep writing error checking code like:

tmplBytes, err := Asset("templates/my_tmpl.tmpl")
if err != nil {
  return err
}
tmpl, err := template.New("tmpl").Parse(string(tmplBytes))
if err != nil {
  return err
}
//...

So, I decided to write a small library with a large (but logical) name to help: go-bindata-html-template.

The library reduces the above code to:

import "github.com/arschles/go-bindata-html-template"

I wrote briefly about Orthogonality at the end of my last post but it’s an important topic so I’m giving it its own post.

Also, I seriously can never remember this word so I hope after this post I’ll be cured.

What It Is

Orthogonality is a fancy word that’s pretty simple for Go. There’s a huge wikipedia definition for it that talks some gibberish, but here’s the gist of it:

Orthogonality means that pieces are independent from each other.

When you change one part of your codebase, you (probably) won’t mess up other parts.

How Go Does It

Go takes a lot of design cues from the Unix Philosophy.

Again that’s a huge Wikipedia definition, but I trudged through it a few times to boil it down for you, dear reader! Here are the parts that matter for Go.

• do one thing well
• keep things simple
• have a standard way to communicate

Do One Thing Well

The Go standard library is organized into...

William Kennedy talks in this article about the many technology benefits of Go in the startup ecosystem.

Yes, Go is important for your technology stack. If you grow big enough, in fact, you can save a lot of money on servers. But the article leaves out the massive flexibility benefits that Go brings to your codebase.

If you’re trying to find a market fit for your product, your code & technology will grow and change fast. Every once in a while you’ll get blindsided and have to change completely.

Hell, even if you’re established you’re gonna have to change. That’s just the nature of software.

Whatever/whoever you are, your product will change. And since your product is code, the transitive property applies here. If you can’t deal with a lot of code changing constantly, you’re done.

Here’s how Go helps you grow and change fast.

Simple Packages

Creating a package is just putting...

I recently wrote about a Scala Style Guide that my team and I at PayPal recently released.

I’m following up here about Cascade, an Scala project that I open sourced a while ago (this post has been a long time coming!)

History

Cascade started way back I was at StackMob as a bunch of utilities thrown together ad-hoc. It grew over time into a big disorganized repository called “stackmob-common.”

When I joined PayPal, my team and I started bringing it over to an internal repository one piece at a time. We wanted to make sure its new home was clean, simple and organized.

Goals

Fast forward to today. We’ve (obviously) open sourced it and divided it into 4 major pieces.

I also created a set of goals that everything has to follow. I want Cascade to stay simple and focused, because that’s how it’s stayed useful for us.

Each piece must:

1. Work well with Scala and the Typesafe libraries.
2. ...

I was a StackMob engineer and I moved to PayPal as part of their acquisition in December 2013.

Since I joined, I’ve been able to write a lot of Scala, and open source some of it with the support of a great team and open source advisors. A while ago, I released Cascade and Horizon. More on those in a later post.

Today I want to talk about a style guide for Scala that I just released.

Before I start, PayPal makes me put this part in - I’m not representing them here, just myself.

Let’s start with some history.

The “StackMob Days”

The style guide started before I worked at PayPal.

My team and I at StackMob brought Scala with us to PayPal. Some people at eBay were already using Scala but the language was pretty new to PayPal and I think we had most of the experience.

And here’s why: before the acquisition, we had seen some crazy shit with Scala.

We started with Scala 2.8 and...

I recently discovered that I was rendering Go templates on every HTTP request. Luckily, my templates are small and Go renders them quickly. Unluckily I didn’t notice the rendering overhead (ironically, because it was so small).

Before the optimization, my HTTP handler looked like this:

func myHandler(res http.ResponseWriter, req *http.Request) {
  tmpl, err := template.New("MyTmpl").ParseFiles("some_template.tmpl")
  if err != nil {
    http.Error(res, "couldn't parse template", http.StatusInternalServerError)
    return
  }
  tmpl.Execute(res, map[string]string{})
}

Notice that every request executes myHandler, so ParseFiles gets called on every request. I ran a simple benchmark that calls Parse instead of ParseFiles and still takes 6 milliseconds (reading files would add even more latency.)

Let’s eliminate that latency by removing the ParseFiles call from the handler and...