Aaron Schlesinger

Software Engineer, Soccer Player, Creator of Go In 5 Minutes (bitly.com/goin5minutesyt)

Read this first

A Critique of Google Container Builder

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

Continue reading →


Seeking Contributors for Go In 5 Minutes

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

Continue reading →


go-bindata-html-template

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"

Continue reading →


Orthogonality in Go

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

Continue reading →


Why Tech Startups Should Look At Go II

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

Continue reading →


Scala @ PayPal: Cascade

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.

Continue reading →


A Scala Style Guide

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

Continue reading →


Go Templates

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

Continue reading →


Concurrency is the New Memory Management

These days, we all need to build “cloud apps.” We’ve heard “cloud” so many
times at this point that it’s a buzz word, but underneath the hype lives a real
fact for us developers: everything we build needs to be a distributed system.

For our apps to run, we must have servers and they need to respond to requests
from our apps, all the time. So we need to build systems that have many
computers to provide all the fault tolerance, throughput, etc… we need.
You’ve probably heard this all before.

 Distributed Systems are Hard

This is a fact that we all know by now. Computers die, networks get congested,
etc…

The bottom line is that our programs are deployed onto multiple nodes as a
process on each, and each process communicates with all the others.

The process model is still powerful but it has changed on the server side. Now
every process communicates with N other identical ones, making a

Continue reading →


My Ideal Programming Language, Part 1

I’m shifting in this post from writing about my life, health, etc… to writing about software again.

Among the many things Bjarne Stroustrup has said that someone has published on the internet, my favorite is this: “There are only two kinds of languages: the ones people complain about and the ones nobody uses.”

As of this writing, I’ve been writing code as my full time job, as well as for some open source projects, for a few days over 5 years. Before that, I majored in computer science, where I wrote lots of code, and I worked for the UM Computer Aided Engineering Network, where I wrote lots of code. Before college, I wrote code for fun.

Most of the work I’ve done in my adult life has been writing code, so I’ve worked with a wide variety of programming languages. I’m writing here what my ideal programming language would look like. I’m writing this post as a time capsule. In 5 more

Continue reading →