Introduction As I improve my knowledge and framework for a Go based web service I am building, I continue to go back and enhance my Beego Sample App. Something I just added recently was providing localized messages for validation errors. I was fortunate to find Nick Snyder's go-i18n package. Nick's package made it easy to support multiple languages for the Go web service I am writing. Abstracting go-i18n The go-i18n package is simple to use and you can use it to read files or strings that contain all the messages you want to localize.

If you are attending GopherCon 2014 or plan to watch the videos once they are released, this article will prepare you for the talk by Gustavo Niemeyer and Steve Francia. It provides a beginners view for using the Go mgo driver against a MongoDB database. Introduction MongoDB supports many different programming languages thanks to a great set of drivers. One such driver is the MongoDB Go driver which is called mgo.

Introduction In my last post called Concurrency, Goroutines and GOMAXPROCS, I set the stage for talking about channels. We discussed what concurrency was and how goroutines played a role. With that foundation in hand, we can now understand the nature of channels and how they can be used to synchronize goroutines to share resources in a safe, less error prone and fun way. What Are Channels Channels are type safe message queues that have the intelligence to control the behavior of any goroutine attempting to receive or send on it.

Introduction When new people join the Go-Miami group they always write that they want to learn more about Go’s concurrency model. Concurrency seems to be the big buzz word around the language. It was for me when I first started hearing about Go. It was Rob Pike’s Go Concurrency Patterns video that finally convinced me I needed to learn this language. To understand how Go makes writing concurrent programs easier and less prone to errors, we first need to understand what a concurrent program is and the problems that result from such programs.

Introduction We are working on a project where we have to make calls into a web service. Many of the web calls return very large documents that contain many sub-documents. The worst part is, we usually only need a handful of the fields for any given document and those fields tend to be scattered all over the place. Here is a sample of a smaller document: var document string = `{

Introduction In October 2013 I sent out a call to action to the Go community. I wanted to form a group of Gophers that would come together and help write a specification and build a working implementation of a package management tool. We are not there yet, but the group did accomplish a few things: We started a mailing list called Go package management [go-pm] where people could discuss ideas and get feedback on existing and new tools.

Gopher Academy announced a great program today. Today I’d like to announce the GopherCon Scholarship Program. It’s goal is to increase the visibility of women in the Go community through the most direct path I can imagine: sponsoring their attendance to GopherCon 2014. The program works by you purchasing one of these special tickets. There will be a selection/nomination process and those woman selected will be able to attend GopherCon thanks to you.

Introduction There are lots of posts that talk about the internals of slices, but when it comes to maps, we are left in the dark. I was wondering why and then I found the code for maps and it all made sense. https://golang.org/src/runtime/hashmap.go At least for me, this code is complicated. That being said, I think we can create a macro view of how maps are structured and grow. This should explain why they are unordered, efficient and fast.

Introduction The first thing I did when I started programming in Go was begin porting my Windows utilities classes and service frameworks over to Linux. This is what I did when I moved from C++ to C#. Thank goodness, I soon learned about Iron.IO and the services they offered. Then it hit me, if I wanted true scalability, I needed to start building worker tasks that could be queued to run anywhere at any time.

With the release of Go 1.2, slices gained the ability to specify the capacity when performing a slicing operation. This doesn’t mean we can use this index to extend the capacity of the underlying array. It means we can create a new slice whose capacity is restricted. Restricting the capacity provides a level of protection to the underlying array and gives us more control over append operations. Here are the release notes and design document for the feature request: