Monday, October 19, 2015

Google Analytics doesn't work a.k.a. name collision in JavaScript

Today is another great day I’ve encounter a trivial bug hard to catch. It goes as follow. I went to Google Analytics to setup a new page. I’ve followed the instruction and I’ve copied into a source:

  (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),

  ga('create', 'UA-AAAAAAAA-X', 'auto');
  ga('send', 'pageview');


and it didn’t work ;-)

First I’ve thought is my mistake, i’ve put a code just before </html>, but after trying </head> it wasn’t any better.

I’ve tried to copy paste the code to developer console and tadah, it works! Here I should mention that I use both Google Closure Library and Google Closure Compiler on my site. After thinking and poking the code for a moment I’ve made an educated guess:

Closure compiler compiled code is colliding a name with Google Analytics!

Took me 1 minute to verify and yes, I’ve got it.

The solution was straight:

  (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),

  dzialaj('create', 'UA-AAAAAAAA-X', 'auto');
  dzialaj('send', 'pageview');


Just for quick explanation, the string I’ve changed is a parameter to function which sets up a Google Analytics code on a website, it is a name that should be used as a Analytics main function and may be anything one wants.

Thursday, October 8, 2015

Save yourself and pass the context by

One of extending packages of Go is package. The idea comes form task oriented programming. You get a task to execute but want to attach some data to it. It appears to be useful when programing a RPC or web server solutions. In such cases your listener creates a context object and pass it to handlers. The handlers keep it and use it when appropriate.

This idea guided most Google App Engine APIs for Go. Now they’ve introduced a Managed VM’s which are something between App Engine and Compute Engine. The refactored libraries can be found here:

The standard way of logging in App Engine was to get a context and call methods:

func SomeHandler(w http.ResponseWriter, req *http.Request) {
    ctx := appengine.NewContext(req)    
    ctx.Infof("got request!")

Whereas the new way:

func SomeHandler(ctx context.Context, w http.ResponseWriter, req *http.Request) {
    log.Infof(ctx, "got request!")

The new way has one huge advantage, it allows you to pass any context which implements interface context.Context. It also requires to replace all appengine/log imports by a new package

The Go’ standard log library doesn’t have a concept of context at all.


I guess I should explain the advantage of using a context based log instead of standard one. In a case of task oriented application it allows the programmer to group all log messages related to given task. It’s a common practice to group messages by the place of the log function callback (the file and line where the log message is written). More sophisticated grouping includes process id and it may be a task id (or context in our case). Just imagine how much time it saves during debugging. It also allows much more sophisticated analysis of the server event flow without running in debugging mode.

I’ve created a tiny wrapper around both library and It should allow you to log both at App Engine and stand alone processes. Enjoy.

A real in depth explanation can be found in Go blog' article: Go Concurrency Patterns: Context