I’m working on a small app running on Google App engine using Go and upgraded to the latest version of the GAE SDK. The latest version uses Go 1.6 instead of 1.4 like the older version I had. Upgrading was mostly straightforward, but once I started using vendoring I got strange build errors like this:

2016/05/22 13:26:47 go-app-builder: Failed parsing input: parser: bad import "syscall" in vendor/golang.org/x/net/ipv4/dgramopt_posix.go

I got different variations of this, but all came down to the same problem: some code was importing packages that GAE doesn’t want you tu use. Sadly these errors don’t show up during normal goapp build or goapp test cycles, but only when you want to deploy or start a local devserver.

I’ve been reading The little book about OS development and wiki.osdev.org and took some notes along the line. Here’s what I wrote on environment setup.

Environment setup

You’ll need a cross compile toolchain consisting of GNU Binutils and gcc. The osdev wiki has a great page on setting up a cross compilation toolchain.

It took me a few times because I didn’t read the instructions properly. It is important to unpack the sources for binutils and gcc and have separate build directories, gcc-4.2 and gcc-build for example. Then, for building gcc, make sure the newly built binutils are on your path.

This took me longer to figure out than I care to admit, so here’s the solution.

The issue comes up when trying to use gorename:

$ gorename -from "github.com/ilikeorangutans/foo".MyType -to 'MyBetterType'
gorename: -from "github.com/ilikeorangutans/foo.MyType": invalid expression

Even though the from query looks normal, gorename just refuses to work. However the issue is not so much with gorename but rahter my shell, zsh. Turns out properly escaping your from query, fixes the issue:

$ gorename -from '"github.com/ilikeorangutans/foo".MyType' -to 'MyBetterType'
Renamed 15 occurrences in 5 files in 1 package.

Notice the single quotes around the entire from parameter.

At work we are maintaining several large and complex grails applications. In order to improve stability and reliability, we’re trying to increase test coverage. But as with all projects, time and resources are limited. In order to get a better understanding of what parts of the application are more important than others, I decided to use Graphviz to help me get a better overview of our applications.

Meet Graphviz

I discovered my love for the dot language when I used it years ago to analyze template hierarchies in a proprietary CMS system I worked on. In a nutshell, it lets you specify a graph with nodes and edges plus some extra attributes for labels, shapes etc. It’s really a concise little language:

Ran into this issue today and wasted a good hour on figuring out what happened. Seems to be an issue with Git 1.9.x.

Symptoms

Maven release plugin successfully completes the release:prepare goal, creates the tag, but fails to commit the changed pom.xml.

Solution

Git’s output format changed slightly in one of the recent versions and Maven’s SCM provider expects output in a certain way. Luckily you can force git to use the old output style:

Last week I attended the Toronto Golang Usergroup Meetup and it was plenty of fun. If you’re in or near Toronto and like to dabble with Go, come out. Oh, and did I mention free pizza?

Notes

• Casting in Go is slightly different than in C related languages. Instead of a cast, you perform a type conversion:

    var myVariable SomeGenericType = ...
  
    casted, ok := myVariable.(MoreSpecificType)
    // ok is a bool
    if ok {
    	// Type conversion successful
    } else {
    	// myVariable does not implement MoreSpecificType
    }
  

• The range keyword when used with two return values does not return references, but rather copies. This had me struggle for a while as my code was not behaving as I thought it would. I had a slice of structs and was happily iterating over it:

Note: I’m still working on this post, but I already use it as a reference so there’ll be more content over time.

I’ve been quite busy at work with updating a Grails 1.3 application to 2.3.4. While writing a test harness it became apparent that lots of things have changed since I’ve last worked with Grails. Many changes are for the better, especially the integration of Spock framework. However, there were some issues that took me a while to figure out. The Grails docs on testing are comprehensive, but long. Here’s my cheat sheet.

Ever since Google release Go I’ve been curious. Many good things were said and I always read bits and pieces here and there. Last week I decided to dive deeper and write some small things and get to know the language.

So far I’m really impressed. This is a quick list of things I’ve noticed:

Language

The go language is full of nice surprises. I haven’t seen everything, but just a few things that really impressed me:

Today I was experimenting with some new tools (Prose) and was confronted with a screen that probably everybody that owns a smartphone or uses any kind of connected online service has seen before: an authorization screen where the user is expected to either approve or deny an application based on list of permissions. Here’s how Github’s screen looks like:

Android has a similar screen when you install an app, IOS probably has one as well. Pretty much every connected system, be it Facebook, Github, Stackoverflow, pretty much everything that uses OAuth or similar technologies will have a screen like this. From a technology and development point of view it makes a lot of sense; at least initially. You break down privileges in a system into a few neat categories and if an application wants to use this service, it has to declare what it uses. Ideally the system would enforce that the application can only use the declared permissions and in theory that would make everything safer…

I’ve been contemplating compile time bytecode manipulation for the Object Mapper Framework for a while now. Compile time instrumentation of classes seems to be a better approach and does away a whole lot of class loading issues, especially in OSGI environments. In any case, I remembered Project Lombok and reading about JSR-269, which was introduced with Java 1.6. It’s an API that allows you to plug custom annotation processors into javac.

After experimenting and reading a bit, here is my reading list: