The obligatory, “I love golang” post

Golang gopherI’ve spent the last year and a half designing and building a microservices architecture in Go (First rule of Go. Always google “golang”.) After all this experience with Go, it’s finally time to write the obligatory “Here’s why I like Go” blog post. This post, of course, is a required assignment for all real gophers (that’s how golang users are referred to. Cute, ain’t it.) All kidding aside, I’ve really fallen in love with Go. Most of my work is done in Go these days, and it’s a really powerful language, with some good design choices. However, it’s not a panacea. It won’t solve all your problems by itself, and there are some times and places, where it really doesn’t fit.

First of all, for those who have been living under a rock for the past couple of years, and may not have heard of Go, here’s a quick run down. Go, or golang, was invented at Google to solve some problems that they were having with other languages. It’s a systems language (think C) based on C, but with specific design choices intended to make it simpler, and more flexible than C. Wikipedia says that it is “a compiled, statically typed language in the tradition of C and C++, with garbage collection, various safety features and CSP-style concurrent programming features added”. First of all, it’s garbage collected, so no more `malloc` baloney, and shooting yourself in the foot because you forgot to deallocate memory. Second, it’s got a crazy awesome concurrency model built in! This is the thing that gets most people excited about Go. Go makes it dead simple to write highly concurrent software. That’s a post all to itself, so I won’t get into details here, but seriously, it’s damn good. At heart, it’s still just managing threads on the OS, but Go abstracts away the dirty work of creating and managing those threads. Third, it’s a compiled language, which means that deployments become so much simpler, there’s no “dependency hell”, since you can compile a statically linked binary executable. It’s completely self-contained, and you just drop that binary on the machine that you’re deploying to. If you’re my age or older, you might think that’s ironic, since one of the “benefits” of scripting languages (like perl, php, ruby, etc…) was that there’s no need to compile them. It’s funny to me that we seem to have come full-circle there.

With all this Go goodness, are there any downsides? Well, kind of… Go is still a fairly new language, and the ecosystem isn’t as strong as some others. Perl and Python have been around long enough that no matter what problem you’re trying to solve, there’s probably a well vetted library that will help. That’s not necessarily the case with Golang. Of course, that’s changing as we speak. As more and more people start to use Go, more and more libraries get created, and the ecosystem just keeps growing. Golang is designed as a systems language, meaning it provides low level hardware access, so you’re not going to want to write a web CMS with it. With that being said, people certainly can and have written web CMS’s with Go. Personally, I don’t think that type of high level application is the sweet spot for Go. However, I do think that, for example, building a REST API for that web CMS, is a perfect application for Go. And as a matter of fact, that’s exactly what I’ve been doing lately, building REST API’s in Go that provide access to other services and systems.

In any case, Go just works for me. I’m planning a series of posts, where I’m going to go into more depth regarding some of Go’s features that I’ve either very fond of, or that I find myself using all the time. But for now, I just wanted to get back into the swing of writing. I just realized that I haven’t posted anything at all in 2015.

Development environments done right, with Vagrant, Puppet and VirtualBox

When I first started out in web development, I worked directly on the server. I had an FTP client and I’d download files, edit them, and re-upload them. If it was a “serious” project, I might even use source control. I thought this was a pretty handy way to work… Looking back on that workflow, I’m embarrassed, but the thing is, I know people who still work that way. I’m not going to go into the merits of having a dedicated development environment, automated builds and tests, etc… Just take it as a given that you need them. With that being said, however, it’s always a pain trying to set up a new development environment, and having an environment already set up on my laptop doesn’t guarantee that it’ll be the same environment that the next client has in production. If you’re on a different machine, it’s a problem. I’m going to talk about how I’ve solved this age old problem using Vagrant, Puppet and VirtualBox.

Continue Reading…

Moving Kohana to a non public directory

Kohana, PHP framework

This is the second post in my series on the Kohana php framework.  For more, see:

Part 1: Getting started with the Kohana php framework

One of the simplest, and most basic security precautions that you can take is to move your application’s files into a non-public area of your webhost. Having your applications code and configs sitting there in your document root is just never a good idea. An attacker could very easily gain access to the source code of your application, as well as configuration. Next thing you know, there’s empty beer cans all over your apartment and the silverware’s missing. In general, this applies to any kind of web based application, but I’m going to be dealing specifically with Kohana, as part of my series on Getting Started with Kohana.

Continue Reading…

Getting started with Kohana, the Swift PHP Framework

Kohana, PHP framework

This is the first in a series of posts on installing and using the Kohana PHP framework.  For more in the series, see:

Part 2: Moving Kohana out of the docroot

Kohana home page

Kohana is an open source, object oriented, MVC framework that originated as a fork of the CodeIgniter project.

For a long time, I’ve been a big fan of CodeIgniter, the PHP framework. I’m still a big fan. CodeIgniter is lightweight, fast, and has a short learning curve. The problem is that it’s dead in the water, see After looking around at some other options, I’ve started putting Kohana through it’s paces. Kohana was originally a fork of CodeIgniter, although later versions have been rewritten from the ground up. So, first off the bat, there’s that shared ancestry, which should mean that a lot of my CodeIgniter knowledge will be directly translatable to the Kohana world. Kohana also keeps that commitment to being fast and lightweight. That’s important to me. A framework is a development tool. It should enable me to get something up and running quickly, but it shouldn’t be so heavy that it gets in the way. Kohana looks like a good option, so I’m going to take a look at what it takes to get something up and running.

Continue Reading…

Emulating powerline with just Vim and tmux

In a recent post, I looked into powerline, a bash status line utility. Powerline looks pretty cool, and I really wanted to run it, but try as I might, I just couldn’t get it working with my set up. Specifically, it doesn’t work really well with tmux. If you spend as much time on the command line as I do, them tmux is indispensable for serious work. That’s another post, but what I really want to talk about is how I emulated some of Powerline’s features using just the native tmux configuration. In addition, there’s a great Vim plugin, airline, which is sort of a vim only powerline. Using the combination of tmux and vim-airline gives me a status line that I’m really happy with.

Continue Reading…

Perl arrays for fun and profit

In my day job, I deal with a lot of perl. After really taking the time to learn it, and working with it in a production environment, I really have a new respect for perl. But that’s a topic for another day. The other day, someone presented me with a perl coding challenge, and it took me a while to come up with the answer. Granted, I’m not really a perl guru, so I’m not too concerned, but I wanted to talk about and document how I solved the problem. The challenge can be simplified a little bit, and restated almost like a homework problem:

Given 2 arrays, find the union, intersection and difference.

See, here’s the thing. Most every other high level language makes this pretty trivial. PHP has the built in functions array_intersec and array_diff, in Ruby, you can just do something like ary1 & ary2 or ary1 - ary2, etc… Perl’s arrays suck eggs. I’m serious, arrays in perl are virtually useless… Well, that’s too strong. Array’s in perl are emenintly useful, they’re just kind of dumb. In order to do most serious processing in perl, you wind up turning things into hashes. And that’s basically what you have to do to get the array intersection, difference and union. Here’s a little script that does the job.

Continue Reading…