Kotan Code 枯淡コード

In search of simple, elegant code

Menu Close

Tag: google (page 1 of 2)

Creating a Microservice in Go

A while back (like, quite a while) I started playing with Go and then unfortunate circumstances kept me from continuing my exploration. My recent exposure to super brilliant people has rekindled some of my desire to explore new languages. Since I’ve been knee-deep in microservices recently, I decided to try and build a microservice in Go.

There are a number of libraries available to Go developers that help with this kind of thing (including Martini). But, I want to see what it looks like to build the most minimal microservice possible. Turns out, that’s pretty damn minimal:

package main

import (

func main() {
 http.HandleFunc("/zombie/", zombie)
 http.ListenAndServe(":8080", nil)

type ZombieThing struct {
 Text string
 Name string
 Age int

func zombie (w http.ResponseWriter, r *http.Request) {
  zomb := ZombieThing {"Watch out for this guy!", "Bob Zombie", 12}
  b, err := json.Marshal(zomb)
  if err != nil {

So now I just type go run service.go and the service is running. Now I can just curl the service:

$ curl http://localhost:8080/zombie/
 {"Text":"Watch out for this guy!","Name":"Bob Zombie","Age":12}

If you’re wondering why I used upper-case member names for the JSON object being returned, it’s because I’m lazy. Go considers a variable name with lower case to be private or non-exported, so if I were to make the ZombieThing struct have lowercase names, nothing would be exported and the service would return {}.

So, basically we have yet another example in a long list of examples proving that microservices are a language-agnostic architecture and you can build them in pretty much whatever language and framework that suits your needs.

Implicit Interfaces in Go

In my continuing obsession with learning a new language, I’ve gotten to the point in experimenting with Go that I want to know what all this implicit interface stuff is about. In my previous blog post, I talked about how Go doesn’t actually have classes, but rather it has explicit receiver functions that look like they are methods being invoked on an object.

The rumor on the street is that Go has a facility similar to duck typing in that when you declare an interface, anything can be said to implement that interface as long as that thing has all of the method definitions declared in the interface. This isn’t entirely unique – dynamic languages are full of stuff like this and Scala’s got the ability to define type aliases that do the same thing. The curious thing about Go’s implicit interface satisfaction is that it is compile-time checked. That’s right – your code won’t compile if you have code that attempts to convert an object into an interface that it can’t satisfy.

Let’s take a real-world example: wielding a chair (what, that’s not real-world to you?). When building MUDs and even some more modern game types, you often run into this type of thing. If a developer didn’t originally intend for an object to be used as a weapon, it can’t be treated like one. But, what if you want to make it so that the player can wield a chair as easily as a sword? Sure, they will have different behavioral characteristics, but you should still be able to wield either.

In a classic programming language problem, this is easy to solve: Create an interface called Wieldable (or IWieldable if you’re a .NET person) and then two classes that both implement that interface: Chair and Sword. In Go, you still create a Wieldable interface that defines a Wield() method, but the difference is you never create a class nor do you explicitly indicate what interface you’re implementing. If there’s an explicit receiver in scope called Wield() for that object, then your code can treat it as a wieldable.

Let’s take a look at some code:

// interfaces
package main

import (

type Wieldable interface {

type Chair struct {
	Legs	int
	Wielded bool
	Name	string

type Sword struct {
	DamageRating	int
	Wielded			bool
	Name			string

type Test struct {
	Wieldy		Wieldable

func (s *Sword) Wield() {
	fmt.Printf("Wielding Sword %s\n", s.Name)
	s.Wielded = true

func (c *Chair) Wield() {
	fmt.Printf("Wielding Chair %s\n", c.Name)
	c.Wielded = true

func main() {
	fmt.Println("Hello World!")

	s := Sword{
		DamageRating: 12,
		Wielded: false,
		Name: "Sword of Doom",

	c := Chair{
		Legs: 4,
		Wielded: false,
		Name: "Death Seat",

	t := Test {
		Wieldy: &s,

	t2 := Test {
		Wieldy: &c,


In this code I am creating a Sword struct and a Chair struct and then I created an interface called Wieldable and another struct called Wieldy which holds a Wieldable object. To prove that I can convert between Chair/Sword and Wieldable, I create two test objects – each holding a Wieldable converted from either a sword and I then call the Wield() method on each.

So here’s something unexpected – this is a one-way conversion. In a runtime managed language when you typecast a reference to an object from one type to another, the actual underlying object remains unchanged and you get a runtime-limited view onto that object. For example, if you’ve created some serializable object called Zombie, you can cast that to a Serializable and then still get back the original zombie. If you attempt to get a Sword object out of a Test.Wieldy field, you will get an error message from the compiler.

That said, you can still prove that the wield methods did actually change the value of the things you’re wielding:

fmt.Printf("Wield status: %s, %s", s.Wielded, c.Wielded)

The big take-away that I learned from this experiment is that while implicit interfaces are pretty damn awesome, you should not be using them so you can do a pile of random typecasting or to somehow treat your structs like the target for mixins (traits in Scala). They should be used to assert that a particular set of receiver methods exist for a particular data type. And since there are no classes and there is no inheritance, that data type is strictly enforced.

Further, I might have been better off just using embedding to contain a wieldable inside either my chair or sword objects, which would make them both wieldable. Also, interfaces cannot contain fields. So you might be tempted to try and model some statement like “anything wieldable should have a wielded boolean property”. You cannot model this with interfaces.

So I’m already starting to run into scenarios where it feels awkward or downright limiting to model things like business logic (or game logic) in Go. I will keep trying, however, to see if there’s a more Go-idiomatic way of doing things that I’m not seeing because I’m still knee-deep in the class-and-inheritance world.

Object-Oriented Design in Go

One of the first things I tend to look for in exploring a new language is OOD. What does a class look like? How does inheritance work? And, because I’m such a huge fan of Scala, I now ask questions like “Does it support mixins (traits)?”. The trick with Go is that there are no classes. That’s right, it’s a language that can be called object-oriented but you’ll never write a single class.

Let’s take a look at a little bit of sample code, where I’ve created a struct (remember those? Ah, the good old days…) called Mob and I’ve also created one called Coordinate:

type Coordinate struct {
	X	int
	Y	int

type Mob struct {
	Hitpoints	int
	Name		string
	AggroRadius	int

Something worth noting here is that it might look like Mob inherits from Coordinate, but that’s not what’s happening. Instead, the Mob struct is embedding Coordinate struct. To really be object-oriented, I need to be able to write methods on my “objects”. Go supports this by allowing you to define functions that have something called an explicit receiver. In other words, when you invoke a method on a struct, that instance of that struct becomes the explicit receiver for that function.

Let’s create a method that moves our mob around a game board. In the process, you’ll see another one of Go’s differences from traditional C in that it can return multiple values. What happens if we invoke a method called MoveTo in a traditional OOP language and it fails? How do we know where the mob stopped en route to its original location? There are other classes we traditionally create like MoveResult or some junk like that, but that’s all ceremony slapped on top of the real problem. Here’s how to do it in Go:

func (mob *Mob) MoveTo(x, y int) (success bool, newLoc Coordinate) {
	success = true
	newLoc = Coordinate{x,y}

	mob.X = x
	mob.Coordinate.Y = y // can choose to be explicit about embed or not

	return success, newLoc

In the preceding code, the mob *Mob is declaring an explicit receiver of type Mob and it will be named mob (think of it as being able to provide a name for the traditional this in other OOP languages). X and Y are integer parameters to the method, and success and newLoc are the return values from the method.

Now let’s take a look at how to create a Mob and use it:

func main() {
	var brutus = Mob{
		Hitpoints: 500,
		Name: "Brutus",
		AggroRadius: 20,
		Coordinate: Coordinate{X: 100, Y: 200},

	madeIt, newLoc := brutus.MoveTo(60, 50)
	fmt.Printf("Did I make it? %s\n", madeIt)
	fmt.Printf("Brutus is now at %d,%d\n", newLoc.X, newLoc.Y)

	// Can also shortcut through the embed:
	fmt.Printf("Brutus's X location - %d (or %d)\n", brutus.X, brutus.Coordinate.X)

I strongly encourage you, if you’re just learning Go, to copy this stuff in (remember each file needs a package) and run it with something like go run mob.go. Also remember that there’s absolutely no restriction on filename and it doesn’t need to correlate to the package it contains or the structs used. One subtle take-away from this is that you can add explicit receiver functions (methods) to any struct from anywhere in your code.

Here’s something subtle but important: Did you notice that it looked like I used a pointer in the MoveTo method? If you’ve got the code running, go ahead and delete the asterisk and run it again. Note that you don’t get any memory violations or null pointer exceptions or any of the usual crap you would expect from downgrading a pointer to a stack reference. BUT, what does happen is that the modification of the mob’s current location is ignored. Well, it’s not really ignored, but the modification is being made to a stack copy of the mob which is different than the mob reference sitting inside the main() function. To ensure that changes made inside the method actually happen to the shared instance of the mob between main() and the method, you need to use a pointer. This is because the method isn’t some vtable dispatched reflection-discovered shenanigan, it’s a legitimate C-style function that just happens to have been passed a value called mob. This is one of those dichotomies I mentioned in my previous blog post, about how it seems that Go is straddling the line between low-level, C-like functionality and modern awesomesauce like goroutines and asynchronous processing via communication over channels.

In my next post, I’ll show you some stuff about type inference and another cool feature: implicit interfaces.

First Impressions of the Go Language

I recently got a chance to hang out with some very brilliant people and one of the guys mentioned how fond he was of Go, a programming language most commonly associated with Google. To be honest, the fact that it was “yet another thing that came out of Google” is exactly why I hadn’t played with it up until this point. I’d seen a few blog posts but skimmed them. This time, however, I decided to give Go a more fair shake and so I downloaded it and started hacking away. What happened next shocked even me.

I’m not a coding newb, but even I know that there’s a learning curve to each language and recently the learning curves have been getting steeper – Scala and Clojure come to mind, as well as some of the UI frameworks that aren’t languages, but they have language-sized learning curves (AngularJS is the 800 pound gorilla of learning curves). That’s why when I had ‘Hello World’ compiled and running in about 12 minutes after my first click on golang.org, I was shocked.

If you are unfamiliar with Go, it takes a little getting used to because at first glance it seems like a hodgepodge of some features you would never expect to see in the same language. Here’s a quick list that I found over on this blog post entitled Why Go?:

  • Asynchronous – We’re all about reactive programming these days and all the hip kids are building non-blocking, asynchronous code. In fact, if I hear one more Node.js zealot shout “it’s non-blocking” one more time, I will stab him in the face with a web socket. Go has these things called Goroutines that are lightweight async execution blocks and they have channels that make my inner Erlang and Akka fanboy giggle. Bottom line is you write synchronous-looking code but it’s non-blocking and there are no callbacks. Callback hell needs to be avoided at all costs.
  • Concurrency – Paired with the asynchronous support features and support for multi-core with channels is very appealing, especially considering some of the other aspects of the language (check out the next bullet, you’re going to crap yourself)
  • Static Binaries – Oh that’s right. There’s no JVM. There’s no VM of any kind. You don’t have to wait for a runtime to go dig through classpath garbage and dynamically load a hojillion JAR files. These are compilednative binaries. Remember way back in the good old days when you could just pass around and executable and that worked?? Yeah, I had almost forgotten those times as well.
  • Language Features – In addition to looking like C, having asynchronous, actor-like support for concurrency and parallel programming, it also has a lot of the goodies that people think you can only get from some of the newer JVM or functional languages  like type inference and my personal favorite, implicitly satisfied interfaces … wait wait.. it gets better… the implicitly satisfied interfaces are checked and satisfied at compile-time… I almost shed a tear when I saw that.
  • Privacy indicated via case, not keywords – Capital lettered members are exported, lowercase ones are not.
  • Imperative, object-oriented language – You’d think this is contradictory, but with Go it just seems to work. I was very skeptical until I started playing with it. Go doesn’t have classes, yet it supports message passing via methods, polymorphism, and namespacing. Crazy, right?
  • Multiple return values – The language looks like C, but you can invoke methods that return multiple values and it looks just like a Scala unapply syntax. Me likey.

So, I sat down and I downloaded Go and got it working and followed the advice of setting up the $GOPATH environment variable that pointed to a single root under which all of my Go code would reside. It felt a little awkward, but there seemed to be some method to the madness, specifically relating to the fact that Go can fetch its dependencies directly from Github and that it can resolve transitive dependencies without the need for a make file, maven, or sbt. Holy crap – compiling to a native binary without maven or sbt? That’s cause for celebration.

So, let’s get to the hello world? (You can get the instructions to download Go and set up “Hello World” from here at golang.org.

package main

import "fmt"

func main() {
  fmt.Printf("Hello world.\n")

When you issue a go install command at the command line, this compiles your Go code. It doesn’t just create a JAR file or a DLL file that will be interpreted (JIT or otherwise) by a runtime like the .NET CLR or the Java Virtual Machine, it creates a static standalone self-executing binary. Ah but you say Java can create executable JARs too, right? This isn’t the same, this is a native executable whereas an executable JAR is just a regular JAR with the JVM launching bootstrapped in.

When I first sat down and started reading the docs on Go, I had mixed feelings and still do. On the one hand, it feels like a step back in that some of it looks like old school C (don’t get me wrong, I love me some old school C) whereas other parts are amazingly terse yet ridiculously powerful (channels, goroutines, slices, transitive no-makefile dependency resolution). I don’t know yet what my final thoughts are, but I know that right now it is appealing to my love of the C language (I think Go is one of the most C-pure looking syntaxes I’ve seen in a long time) with my love of Erlang, the actor pattern, and asynchronous back-end programming.

This is just hello world. If you’ve read this blog before then you know the real test I have to put Go through in order to vet it as a language and I’ll be posting a series of blog posts on that soon. The real question I ask of any new language is this: Can I create a MUD with this language?

I’m about to find out – stay tuned!

Protocol Buffers on iOS – Source Code

For those of you who have been asking for the source code to the sample I wrote some time ago illustrating how to serialize and de-serialize protocol buffer messages on the iPhone, then you can download a fully functioning sample project from here:


This contains the Xcode project file as well as all of the source code, which should hopefully get you started.

Note that this sample is really just a serialization and de-serialization sample. The code expects for there to be some socket server listening on localhost, so you will have to modify it to no longer expect that (or write your own server that receives ZombieSightinmessages).


Google Protocol Buffers on iOS and Mac – Redux

In a previous blog post, I talked about how I used the C++ stock Google Protocol Buffers generated code and the native C++ library in my iOS application. It involved some trickery of creating a wrapper Objective-C++ class to keep the C++ from bleeding into my Cocoa project, I had to link a static library, and it actually bloated my application quite a bit.

Since then, I have found a great native Objective-C protobuf implementation that not only plugs into the regular protoc compiler, but it generates ARC-friendly code. Check out this library on Github for the Objective-C protobuf code.

Now, rather than fussing with creating a C++ object (which requires me to manually malloc and free!), I can just create a new protobuf object that feels natural and native to my iOS and Mac code:

ZombieSighting *sighting =
        [[[[[[[ZombieSighting builder] setDescription:@"This is a zombie"]
                setName:@"Lord Kevin of the Undead"] build];

With this implementation of protobufs, I can just do [sighting data] to get the NSData for the object, and I can de-serialize a protobuf object that I plucked off the wire far more easily than before:

DirectMessage *dm = [DirectMessage parseFromData:data];

See how much easier and cleaner everything is? The moral of the story here is good enough isn’t good enough. Just because you find one solution doesn’t mean it’s the best one. I am constantly in search of simpler, easier, more elegant ways of doing things and I think I’ve finally found a decent way of dealing with protobufs in Objective-C.

Sending Protocol Buffer Messages from iOS to a Socket Server

In a previous blog post, I took a look at how to create an Akka socket server using Akka IO that would read incoming messages in the form of Google Protocol Buffers. The information on the wire was framed so that it contained the length of the protobuf message as well as a numeric identifier telling my server which protobuf message.

Using a Scala client was a decent way of debugging things to figure out if my server code worked properly, but my real goal was to be able to send messages from an iPhone or iPad application to the Akka socket server. I continued to use the zombie sighting message that I created for the Akka server and for my “ProtoPhone” sample from this blog post here.

Now what I need to do is write some code in Objective-C that will send the protobuf messages over TCP via socket streams to the Akka server. The following code is not production ready, it’s just a brute force way of making sure that it works. In a real-world scenario there would be much more error handling, I wouldn’t send bytes on the NSStream until I got the “space available” message, etc.

NSInputStream *inputStream;
    NSOutputStream *outputStream;

    CFReadStreamRef readStream;
    CFWriteStreamRef writeStream;
    CFStreamCreatePairWithSocketToHost(NULL, (CFStringRef)@"localhost", 9999, &readStream, &writeStream);
    inputStream = (__bridge_transfer NSInputStream *)readStream;
    outputStream = (__bridge_transfer NSOutputStream *)writeStream;

    [inputStream setDelegate:self];
    [outputStream setDelegate:self];

    [inputStream scheduleInRunLoop:[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode];
    [outputStream scheduleInRunLoop:[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode];

   // [inputStream open];
    [outputStream open];

    // Flip bytes for network order prior to transmission
    uint32_t length = (uint32_t)htonl([_rawZombie length]);
    uint32_t messageType = (uint32_t)htonl(1);

    // Keeping track of bytes written for debug purposes...
    int bytesWritten;
    bytesWritten = [outputStream write:(uint8_t *)&length maxLength:4];
    NSLog(@"Wrote %d bytes to the stream", bytesWritten);
    bytesWritten = [outputStream write:(uint8_t *)&messageType maxLength:4];
    NSLog(@"Wrote %d bytes to the stream", bytesWritten);

    // Write contents of protobuf object serialized as string, loaded into NSData pointer
    bytesWritten = [outputStream write:(uint8_t *)[_rawZombie bytes] maxLength:[_rawZombie length]];
    NSLog(@"Wrote %d bytes to the stream", bytesWritten);

    [outputStream close];

This is pretty much all there is to it. As I mentioned, there’s some refactoring that needs to happen in order to deal with things like error handling and to better handle situations when I have to use multiple writes to send a single object (e.g. not enough space available on the stream), but you get the general idea.

I will be posting more on this as I go along, but for now, I am plenty happy with my shiny new toys of being able to communicate between an iOS client and an Akka server.

Sending and Receiving Google Protocol Buffers via Akka IO and Scala

In a previous blog post, I illustrated how you can use the C++ versions of the generated protocol buffer classes to be able to work with protobufs on your iOS and Mac OS X applications via Objective-C (Objective-C++ actually). This is all well and good, but protobufs don’t do anybody any good unless you can send and receive them.

Yesterday I attempted an experiment where I was going to use Akka 2.0’s IO module to create a socket server that listened for Google Protocol Buffer messages. Unfortunately the tricky part of doing something like that is that you have to create a client to send protobufs also. Then, while debugging, you have to figure out whether the problem is on your server side or your client side, or, as was in my case, the problem may lie with the developer.

The first issue I ran into was this: when sucking bytes off the wire in streaming fashion like you do with Akka IO, you can’t tell when one message starts and one message stops. In short, you have nothing to show you the boundaries and so, without a little bit of heuristics, you can’t properly frame your messages. That’s when I found this blog post here, a very nice little sample of using Akka IO to receive length-bounded strings. In it, you see that it uses take(x) to pull bytes off the wire. One thing that I find very appealing about Akka IO and its use of Iteratees is that when you call take(10) it will take 10 bytes off the wire, but it will do so when 10 bytes are available. So all that code you used to have to write to maintain your “expected received bytes” count and your “current received bytes” count just to grab a block of bytes off the wire is taken care of for you.

The next problem I had was generating Scala case classes from my .proto files. For that, I turned to ScalaBuff. The author of that particular library is an amazingly helpful guy and actually helped me troubleshoot some of my issues with serialization and sockets in StackOverflow chat.

Here’s what it looks like to create a new zombie sighting message using the generated Scala code:

val zombieMessage = ZombieSighting(
    description=Option("This is a zombie"),

So far so good. I have a socket server that can receive length-framed strings, I’ve got a protobuf library that lets me generate protobuf objects in Scala. Next, I needed to modify the server code to receive length-framed protobufs. Here’s a snippet where I’ve modified the readMessage method to yield ByteStrings rather than yielding ASCII-fied strings like the original blog author’s method did:

def readMessage: IO.Iteratee[ByteString] =
 for {
    lengthBytes <- take(4)
    len = ascii(lengthBytes).toInt
    bytes <- take(len)
 } yield {

On the other side of this Iteratee, I’ve got the original author’s printString method, but now I need to modify it to extract a zombie sighting message:

def printMessage: IO.Iteratee[Unit] =
   repeat {
      for {
        string <- readMessage
      yield {
	val theBytes: Array[Byte] = string.toArray
	val theMessage = ZombieSighting.defaultInstance.mergeFrom(theBytes)
        println("name:" +theMessage.name)

That’s pretty much it for the server… I didn’t alter any of the other code I got from Richard Searle’s blog. For the client, it’s all pretty simple – create a socket, connect to the server, and then write some bytes. Here’s the code (the code that caused me no end of frustration all night last night until I got help from Sandro Grzicic) to encode a protobuf object and drop it on a socket:

val zombieMessage = ZombieSighting(
   description=Option("This is a zombie"),
val zombieBytes = zombieMessage.toByteArray()

// and here's the code that writes to the socket handle (in this case it's the parameter indicated by the underscore)
_ write ByteString("%04d%s".format(zombieMessage.getSerializedSize,
		new String(zombieBytes)))

So, there are a couple of important take-aways here. First and foremost, people on the internet are freaking awesome, and I never would have figured this out without a combination of other people’s blog posts, open source software, and late-night chat sessions on StackOverflow.

The second most important thing to note here is that Scala is awesome and Akka is awesome-er.

Using Google Protocol Buffers in Objective-C on iOS and the Mac

For all the hype and buzz surrounding web services and SOAP and JSON these days, sometimes we still need to deal with sending and receiving binary messages. In fact, we need to do this far more often than you might think. When we think about sending and receiving messages via TCP socket streams or storing information in binary format, one option that has become increasingly popular lately is Google’s Protocol Buffers, Google’s standard data interchange format.

Firstly, why do we need to use a different interchange format? With Cocoa, we have serialization with the NSCoding protocol. Well, the NSCoding protocol only really works best when both sides of the data interchange are Cocoa applications. If you want to exchange messages from C# to Java or from iOS to C++ and so on, and you want to describe this interchange pattern in a platform agnostic IDL, then this is where protobufs really start to shine and you can see their real value.

Feel free to go read the documentation on protobufs, but the cliff notes are as follows: By creating .proto IDL files (simple text describing message schemas) you can use the protoc compiler to generate code in C++, Java, or Python. The generated code contains simple classes representing the messages described in your IDL, as well as methods that allow you to dump the messages to a string and read and write the messages from various formats, including raw binary.

In terms of utilizing protobufs in iOS/Mac OS X there are a couple of options. There is an open-source extension to the protobuf compiler that produces Objective-C code, but it’s newest release is three years old and I couldn’t get it to compile. I would much rather use the protobuf trunk so my code is up to date. So the rest of this blog post is devoted to showing you how to use the C++ generated protobuf classes in either your iOS or your Mac application code without any hackery, shennanigans, or reliance on stale OSS projects.

First, you’ll need to download the source code for protoc, the protocol buffer compiler. You can get this from the link earlier in the blog. Follow the instructions on your Mac to autogen, configure, and make the compiler (you’ll need the command-line developer tools turned on, not just the stock Xcode install). Once you’ve got the compiler on your machine, you can create a sample message.

Here’s some IDL for a message that will send indications of zombie sightings during the apocalypse:

package kotancode;

enum ZombieType {
    SLOW = 0;
    FAST = 1;

message ZombieSighting {
    required string name = 1;
    required double longitude = 2;
    required double latitude = 3;
    optional string description = 4;
    required ZombieType zombieType = 5 [default = SLOW];

Now that you have a protobuf IDL file, you can run the protoc compiler (see protoc –help for syntax) to generate the C++ classes. In this case, it produces a zombie.pb.h and a zombie.pb.cc (I renamed it to zombie.pb.cpp since I’m more familiar with that extension).

Next there’s a bit of manual mucking around but you only have to do it once. In the source code directory you downloaded from Google, delete all of the files related to unit testing, delete the compiler source, and I actually got rid of the gzip sources as well because I had linker issues with those. Add this google directory (e.g. ~/Downloads/protobuf-2.4.1/src/google) to your Xcode project (iOS or Mac, doesn’t matter.. isn’t cross-platform awesome?). You’ll also need to modify config.h so that it doesn’t include the “tr1” namespace prefix. You may not need to do this, but on my Mac I had to. For example, you’ll need to change the HASH_NAMESPACE #define to just std instead of std::tr1 and you’ll need to change the HASH_MAP_CLASS from tr1::unordered_map to just unordered_map. Again, this is a pain but you only have to do this once and then never again for all of your subsequent protobuf projects.

Next, add the config.h file to your Xcode project (this is in the root of the protobuf source dir). Now add the source root (one level above the google directory) to your Xcode project’s header search paths (e.g. mine was ~/Downloads/protobuf-2.4.1/src). You do not need to statically link the protobuf library because you have all of the source code directly in your project, which comes in really handy when you get EXC_BAD_ACCESS errors in your messaging layer.

Now we can get down to business. You have a couple options in terms of how far you allow the C++ stuff to leak into your application. I prefer to write a single wrapper object around the C++ stuff so that the rest of my application can be written in Objective-C and I can minimize the syntax blending. While this blending makes cross-platform stuff on the Mac easy, it can also get confusing when you start bleeding C++ memory management into your UIKit view controllers.

So, here’s the .h and .mm (note the extension!) of my ZombieSightingMessage Objective-C class. Right now it just has a method called doSomething that lets me verify that I can construct, serialize, dump, and de-serialize protobuf messages but you should be able to extrapolate from this how you might wrap your messaging layer behind a small number of Objective-C++ classes.

// -- ZombieSightingMessage.h - note my C++ object is not in the public interface.
#import <Foundation/Foundation.h>

@interface ZombieSightingMessage : NSObject
- (void)doSomething;

// -- ZombieSightingMessage.mm
#import <UIKit/UIKit.h>
#import "ZombieSightingMessage.h"
#import "zombie.pb.h"

@implementation ZombieSightingMessage

- (void)doSomething {
    // Doing random stuff with a UIView here to show the mixing
    // of C++ and Objective-C/Cocoa syntax in the same file...
    UIView *uiView = [[UIView alloc] init];
    [uiView setCenter:CGPointMake(20, 10)];

    // instantiate my protobuf-generated C++ class.
    kotancode::ZombieSighting *zombieSighting = new kotancode::ZombieSighting();
    zombieSighting->set_description("This is a zombie");

    // Some small tomfoolery required to go from C++ std::string to NSString.
    std::string x = zombieSighting->DebugString();
    NSString *output = [NSString stringWithCString:x.c_str() encoding:[NSString defaultCStringEncoding]];
    NSLog(@"zombie: %@", output);

    // Instantiate another zombie from the previous zombie's raw bytes.
    NSData *rawZombie = [self getDataForZombie:zombieSighting];
    kotancode::ZombieSighting *otherZombie = [self getZombieFromData:rawZombie];

    // Dump the second zombie so we can see they match identically...
    NSString *newOutput = [NSString stringWithCString:otherZombie->DebugString().c_str() encoding:[NSString defaultCStringEncoding]];
    NSLog(@"other zombie: %@", newOutput);

    // Grimace all you want, but this is C++ and we need to clean up after ourselves.


// Serialize to NSData. Note this is convenient because
// we can write NSData to things like sockets...
- (NSData *)getDataForZombie:(kotancode::ZombieSighting *)zombie {
    std::string ps = zombie->SerializeAsString();
    return [NSData dataWithBytes:ps.c_str() length:ps.size()];

// De-serialize a zombie from an NSData object.
- (kotancode::ZombieSighting *)getZombieFromData:(NSData *)data {
    int len = [data length];
    char raw[len];
    kotancode::ZombieSighting *zombie = new kotancode::ZombieSighting;
    [data getBytes:raw length:len];
    zombie->ParseFromArray(raw, len);
    return zombie;


Now when I run this application, I get no linker errors, my stuff compiles, and my console output log shows the following:

2012-10-14 16:42:23.919 ProtoPhone[15434:c07] zombie: name: "Kevin"
longitude: 21.007
latitude: 41.007
description: "This is a zombie"
zombieType: FAST
2012-10-14 16:42:23.920 ProtoPhone[15434:c07] other zombie: name: "Kevin"
longitude: 21.007
latitude: 41.007
description: "This is a zombie"
zombieType: FAST

While there’s an awful lot more to protocol buffers than just this, hopefully this blog post has shown you a way to get protobufs up and running in your iOS and Mac applications without you having to depend on a semi-maintained modification of protoc and can instead use the most currently available code straight from Google.

Because this is a binary, cross-platform data interchange format, you can use these messages to talk to web services, to communicate with C++ back-ends running on Unix/Linux boxes in the enterprise, or even use these for efficient persistence and file storage, which also comes in handy on storage-limited devices like iPhones and iPads.

Hands on with the Google Nexus 7

Over the past week or so I’ve been toting a Google Nexus 7 around with me. A few isolated minutes with a device is never really enough to get a feel for it so I forced myself to carry it around and I attempted to use it for everything I would ever normally use my iPad for. In fact, I did not turn on the iPad once last week.

So, what did I think, you ask? How was it, you might be wondering? Is the Google Nexus 7 the iPad killer the hype claims it to be? Hell no. Here’s why:

As a programmer I was super jazzed about how open and componentized everything is. I find a lot of elegance in the overall architecture of Android’s “intent” and “activity” system, it appeals to me on the same level that RESTful architecture does for web applications. But, I wasn’t writing code this week, I was using a consumer device that retails for $199. While this is $300 than the cheapest iPad, it’s still not throw-away money (unless you’re Mitt Romney).

First thing I noticed was that the device is really, really snappy. In most cases the OS is extremely responsive. Some of the stock animations are just timed faster than iOS so that may give me an artificial sense of speed but still, it is a quad-core ARM and its power is nothing to sneeze at. I’ve got an animated wallpaper with configurable seasons and weather and little birds you can tap on. I enjoyed the ability to create multiple home screens in any configuration I wanted and the “widget” capabilities are simply non-existent on iOS and they are even more flexible than Windows Phone 7.5’s Live Tiles.

Most of the applications I typically use are available on Android: Sirius XM, Evernote, Hulu Plus, Safari Books, Kindle, Nook, Gmail (the Gmail app is particularly good on Android, but that should be a foregone conclusion, right?), a few of the games my step-daughter likes to play when we’re out somewhere and boredom sets in and even a few I like to play (I’m particularly fond of “Where’s my Perry”).

This is where the love affair ends. As I said, the operating system is quick, tight, responsive, great on battery, and insanely configurable (almost to its own detriment). The love affair with Android stops the second I start using apps.

Sirius XM has never worked. Not once. I get the “unfortunately, blahblah has stopped working” message for Sirius 100% of the time, Hulu over 1/3rd of the time, half the games I play, and well over half the random apps that I tried. About the only non-Google application that hasn’t failed me once is Evernote. Safari books online is an utter pile of crap on Android (admittedly, it’s only marginally less crappy on iOS).

As any mobile application developer will tell you – the device is secondary, what matters are the apps. The only thing the Nexus has that I found appealing is a more comfortable book-reading grip but if Apple ever drops a 7″ iPad on us, then Google’s “iPad killer” will be pretty darn irrelevant for the higher price point tablets.

For $200, you still absolutely cannot beat this thing. I’m used to my iPad, so I found it infuriating that stuff crashed, and stuff crashes all the time, not just periodically. But for a tablet that has a relatively stable and highly performant OS with a pretty good browsing experience and good performance from the big name app developers, it’s worth it if you don’t want to drop down $600 for an iPad.

If you’re like me and have spent any time using an iPad, then you simply won’t be able to come to terms with the shoddy workmanship of the apps in the Android ecosystem. I know some of you are going to yell at me and say that the device is new and the developers haven’t caught up to the nexus 7, but that’s also b.s. because many of the apps that crashed frequently had update messages like “updated for the new nexus 7!!”

Fragmentation across an increasingly wide spectrum of devices makes it impossible for developers to achieve ecosystem-wide reliability in a way that keeps people like me happy. Bottom line is that the Nexus 7 is a neat little gadget, but I’m not retiring my iPad for it – not now, not ever.