I've been using Vim exclusively for all of my Go development work for the past year or so and over that time I've slowly been customizing my setup.

There are a number of essential plugins, including Vim-go and YouCompleteMe, but after recently working on a Rails project I encountered Vim-rails which includes some useful commands to jump around the project such as:

:Econtroller users

:Emodel thing

:Eview blah

Along with setting up alternates for jumping between source files and test files etc...

I wanted the same for my Go projects and luckily Tim Pope split out the functionality into a standalone Vim plugin called Vim-projectionist that lets you do just that.

After some fudging around with the project specific option I managed to get a global config that you can drop into your .vimrc:

tl;dr

I've put together an easy to use Map/Reduce package for Go. It manages the creation of background workers (goroutines) and the channels that connect them.

Go-mapreduce

go-mapreduce is a simple Go package that makes it super easy to apply the Map/Reduce pattern in Go using goroutines and channels.

In order to use the package you'll need to implement both a map function and a reduce function (implement interfaces) and then pass those into the Run function.

Currently it only allows you to specify the number of mappers as part of the configuration passed into Run, but I plan to build it out to be more intelligent (dynamically throttle workers, report statistics etc...).

I've been looking for an excuse to use DynamoDB for awhile and I finally got a chance to this week. Previously I'd played around with it using IRB and the AWS Ruby SDK, but for my current project I'm integrating it into a Go application.

I've been looking for an excuse to use DynamoDB for awhile and I finally got a chance to this week. Previously I'd played around with it using IRB and the AWS Ruby SDK, but for my current project I'm integrating it into a Go application.

Unfortunately it didn't take long for me to realise that there isn't a mature package. I was able to find two, goamz and go-aws-sdk (created by the Stripe team which was recently adopted by Amazon as the basis for the official SDK)

Initially I thought I'd go with the (now) official SDK but after looking at the code I decided against it (didn't want to get involved with all the crazy Input/Output struct shenanigans), so I went with go-amz...which has almost no documentation for DynamoDB use either.

My fellow proofers and I took part in the first Gopher Gala 48 hour hackathon over the weekend (23rd - 25th of January 2015). It was loads of fun and our project turned out pretty well.

We'd love to get more people working on it and hopefully turn it into the ultimate social jukebox.

Gopher Gala

To paraphrase their website, Gopher Gala is a distributed hackathon where people submit projects written in Go (mostly) that were created in 48 hours. The projects are then judged by the community, with the top 20 then being judged by the expert judges and ultimately prizes awarded to the top 5.

Our project: Groupify

Groupify is a Web Based Jukebox for Spotify (powered by Go). It consists of a Go/AngularJS web application and a lightweight Go remote app that drives the Spotify OSX app via Apple Script.

Architecture

The system consisted of 2 main components, the core web app and a remote component, with messaging between the two handled via 2 SQS queues.

Web Application/Core API - Go + AngularJS

Remote - Go

Messaging - Amazon SQS

3rd Party APIs

Spotify Web API

Github OAuth

What's next?

We're super pleased with what we managed to put together over the weekend, but there's a laundry list of additional features we'd like to add (not to mention addressing some major stability issues).

I partnered up with Sohaib Bhatti and after some brief brainstorming we decided on building out a Twitter based downtime notification system.

The Idea

The idea consists of a Web Service that listens to the Twitter stream looking for a particular trigger hashtag.
Once it detects a trigger tweet, it pulls out the URL included in the tweet and hits the url and checks to see if the endpoint is reachable. If it is, it tracks the http status code retrieved (e.g. 200, 404, 500 etc...) and takes a screenshot of the url. It then replies to the Twitter user with the status and the screenshot (if available).

Architecture

Obviously, being a Rails Rumble entry, the app was built on Ruby and Rails 4 specifically.

The app itself consists of 3 main components:

Twitter Stream Monitor (long running rake task)

URL Tester Sidekiq Worker

Rails Web App

Twitter Stream Monitor

We setup the Twitter monitor as a long running rake task. We're using this Twitter gem to tap into the Twitter streaming API with the filter configured for our chosen "trigger" hashtag. The rake test fires off Sidekiq jobs that actually do the URL testing work.

Sidekiq Worker

So Sidekiq is pretty awesome. We use Sidekiq to do most of the heavy lifting. The worker fires up Phantomjs which renders the webpage, uploads the image to S3 and then uses the Twitter Rest API to reply to the original user.

Rails Web App

The Rails App displays a paginated list of the downtime test history, including the screenshot, URL and status.

It was great fun taking part in Rails Rumble 2014 and I'm really happy with how the project turned out. We just about managed to get everything up and running before the deadline. Looking forward to the next one!

]]>

I've been thinking about building a MMO of sorts for the longest time, and during one my many "thinking sessions" I came up with this question: "Has anyone built a game where it is purely an API and People create their own clients?"

I've been thinking about building a MMO of sorts for the longest time, and during one my many "thinking sessions" I came up with this question: "Has anyone built a game where it is purely an API and People create their own clients?"

In a nutshell the game would exist as a REST endpoint, that exposes a number of APIs covering all the possible interactions with the game. Here are some examples:

user signup - Register a new user

start quest - Initiate a quest

end quest - Checks for end quest criteria, awards items/xp etc...

Obviously a great deal more throttling/validation would have to be employed to prevent cheating, but it would be no different than any other web service.

]]>

My main development machine is a Macbook Pro Retina (running OSX naturally), but our production servers all run Ubuntu.

The vast majority of our platform is built on Ruby, so we've never needed to consider compilation for particular platforms. I rather naively assumed that I'd just run go build, send

My main development machine is a Macbook Pro Retina (running OSX naturally), but our production servers all run Ubuntu.

The vast majority of our platform is built on Ruby, so we've never needed to consider compilation for particular platforms. I rather naively assumed that I'd just run go build, send the binary over to the server and launch it.

I finally decided take learning Kanji seriously, so spent some time searching for apps or tools that I could use.

I ended up checking out WaniKani (which is a SRS based learning tool by the Tofugu guys)

I've been using WaniKani for awhile now and how found it to be incredibly useful so far. Although the mnemonics can be a little weird at times (almost nonsensical actually), I do seem to be remembering them, which is really what matters.

I'm now on level 6, having Guru'd (or better) about 200 Kanji and 420 Vocabulary.

One thing that I've noticed is the sheer amount of time required to stay on top of reviews. I find myself have to go through 20+ reviews several times a day just to clear them out.

To say that it has been a painful experience would be an epic understatement.

I felt that sharing my experience might makes things easier for anyone else looking to setup something similar. This post covers the initial setup, but if I have time (and I remember) I'll publish a follow up.

Setup Go Server

Setting up Go Server was pretty straight forward (naturally went with Digital Ocean).

Configuring Authentication

The next step was to configure authentication (since by default it's disabled). Go seems to lean towards using an LDAP server for auth, but that's overkill for my use case, so I'll have to use a password file instead.