Most of my recent posts can be found on Medium.

You might also want to follow me on Twitter, Facebook or Google+.

I’m mostly keeping this blog to not break links elsewhere (think “archives”) and for the about page.

Recently Google deprecated App Engine Backends in favour of Modules.

In my case, I want to use Modules to bundle indefinitely running processes responsible for frequently persisting data from Dedicated Memcache to Datastore. These processes should live outside any request context and just run “forever”.

An important aspect for me is to keep the module code separate from my main application’s code. On App Engine for Python and PHP this is pretty obvious, as one can simply map URIs to scripts. On the contrary, App Engine for Go uses a single binary and all of the URI matching is handled from within the compiled program.

Unfortunately, the Golang Modules documentation is incomplete and not extremely helpful in getting you up and running using Modules. For example, the samples for Module YAML files, do not include the handlers tag – which not only seems to be required in app.yaml but also on the module level.

Disclaimer: While I am not at all sure whether what I describe here is the correct, best or even idiomatic way of doing it, I can confirm it is working. Any comments are appreciated. You might also want to get in touch with me on Twitter, App.net or Google+.

I hope, Google will amend their docs so we all have a chance to find out how exactly Mountain View intends us to use Modules.

Folder structure

My project structure looks something like this:

/ Project root containing the .yaml files
/main The main applications .go files
/config Configuration files
/services Go files for shared services
/etl The Go files for the ETL Module

YAML files

The main app.yaml file is absolutely straight forward:

Here is the etl.yaml file:

A couple of important things to note:

• I’m using the manual scaling instance type, which according to Google’s docs facilitate the following: “Requests can run indefinitely. A manually-scaled instance can choose to handle /_ah/start and execute a program or script for many hours without returning an HTTP response code.”
• I have added a handlers section. Google does not illustrate this in their docs, but without a handlers section, I couldn’t get Modules to work at all. Also note that the modules registers for the /_ah/.* URI pattern. If you try to register the Module for any pattern, that gets registered by another Module or the default Module, you will see “panic: http: multiple registrations for / goroutine” errors in your logs.

The code

In my main application, I’m using the Martini web framework to route requests. The code lives in the /main folder and is not particularly important to understanding how to set up Modules.

The ETL Module lives in the /etl folder and does not make use of the Martini framework, as it essentially just needs to handle the start and stop triggers requested by App Engine’s runtime environment:
View the code on Gist.

Again, a few things to note:

• The Module belongs to the same package as the rest of my code. While the code for the Module is cleanly separated, we still get just one single binary.
• The Module implements handlers for  /_ah/start and /_ah/stop. Once an instance configured for manual scaling is fired up, App Engine automatically sends an empty GET request to /_ah/start.
• The rest of the code is straight forward: I’m using runtime.RunInBackground to start a background process which – in this case – will run forever.
• The first thing I do in the handlers is returning a response. If a Module does not respond with an HTTP 200 to /_ah/start, App Engine, the runtime environment will shut down the Module. (You can use this to signal initialisation or other failures to App Engine, by responding with a 404).

goapp deploy and the development server

goapp is just a thin wrapper around appcfg. To deploy your app along with its modules just type: goapp deploy app.yaml etl.yaml. Though the goapp serve app.yaml etl.yaml command works, too, I couldn’t get the module working on my local development server. If anybody figures it out, let me know!

This is my take on Golang Modules for App Engine. I’m looking forward to getting your feedback and possible hints of how to improve the code and setup.

I’m doing most of my Go development in Sublime Text 2 using the superb GoSublime package for code completion and many more IDE like features. One thing that bothered me for a long time, though, was that I could not get code completion working for Google’s App Engine packages.

I finally solved the problem:

1. Create a symbolic link in /go_appengine/goroot/pkg named darwin_amd64 and point it to darwin_amd64_appengine/ like so: ln -s darwin_amd64_appengine/ darwin_amd64

2. Make sure that in Sublime Text 2 > Preferences > Package Settings > GoSublime > Settings – User the GOPATH environment variable includes the path to App Engines goroot folder. Mine is: “env”: {“GOPATH”: “$HOME/src/gocode/:$HOME/src/go_appengine/goroot/”}

I hope this helps and appreciate any feedback.

When John O’Nolan announced Ghost, a new kind of blogging platform, I immediately jumped over to Kickstarter and chose the VIP package.

Today, the Ghost folks shipped the first version, they call it an “alpha of an alpha”.

Ghost is built on top of Node.js and Express. The default configuration binds to the loopback interface (127.0.0.1) which makes it available only to localhost. So even if you try http://192.168.2.1:2368 or something, it won’t work.

In case you want to make your Ghost deployment available to other hosts on your network or even publicly, make sure you change the binding in config.js inside Ghost’s root directory and restart Node:

View the code on Gist.

While this is not at all Ghost specific, I thought it might help users new to Ghost and without any Node specific experience.

“SVBTLE is a new kind of magazine. We’re a network of great people mixed with a platform that takes the best things from publishing and combines them with the best parts of the web. We want to make it easier for people to share and discover new ideas.”

Find my SVBTLE contributions at ralfrottmann.net and feel free to subscribe to the feed.

I’m excited to become a part of this diverse, inspiring, motivating, thought-provoking, educating and eye-opening community. I will keep my personal blog for deep tech talk and use SVBTLE mostly for all other posts.

“Hangouts has not been enabled for your account. Please contact your administrator to enable this service.”

To get rid of it, in the classical admin panel to to Settings > Talk and activate the feature called “Enable the new Hangouts for messaging and video calls”.

The Google+ help might wrongly point you to the Services > Google+ section. I hope this helps others stopping the frustration. If you want to stay in touch, I’m on Google+.

As somebody, spending most of his time on the console, I set up the Hotkey window so it opens fullscreen on my MacBook Air and fills half of the screen in my iMac. Obviously, I added iTerm 2 to the Login Items in Users & Groups to automatically launch it on startup.

One little thing always bothered me, though: On launch, iTerm 2 automatically opens a terminal window.

This means, whenever I reboot my MacBook Air, I end up having a console window open. Ticking the Hide checkbox in Login Items does not change anything.

Here is, how to prevent this behaviour. It’s not all that intuitive, so I thought sharing it might help others:

1. Open iTerm 2.
2. Close all console windows.
3. Go to Window > Save Window Arrangement.
4. Name the new arrangement. I named mine “No Windows”.
5. Make sure to set it as the default in Preferences > Arrangements.
6. Last but not least, in Preferences… > General under Startup make sure that “Open default window arrangement” is the only option checked.

That’s it. The next time iTerm 2 is launched on startup, no annoying window is opened.

Ever since Google+ Communities became available, people complained about their Community posts automatically popping up on their profiles. This has been the default for public Communities. In fact, many Community owners on finding this out killed their public Communities and started over doing private ones.

I just today found out, hinted to by Bruno Škvorc, that there is a setting allowing you to change the default behavior. Unfortunately, it’s hidden away at the very bottom of https://www.google.com/settings/plus:

I’d love to see this become

• a per Community setting
• more exposed in the Community UI

But it’s good for a start.

If I could only offer one piece of advice to a new web development student, it would be: “don’t worry; we all feel overwhelmed.” I’d then remind him or her that I, too, am still a student, and so are all of my peers. This industry is an incredibly tough one that requires constant continued education throughout your career. You better be okay with this truth.

You’ll never graduate. You’ll never know it all. But, if you love it enough, none of that will matter. In fact, you’ll crave education.

The standard programming joke is that, Monday-Friday, we go to work and stare at our computers. Then, on the weekend, we do the same thing in our bedrooms, contributing to open source projects. Why? Why do we dedicate precious free time to programming…for free? Well, despite the fact that this surely baffles our employers, there’s lots of reasons why we behave in this way:

• We feel the need to contribute back to the industry
• We crave some level of recognition from our peers
• It’s fun

All three items above factor into the equation, but the final point, “It’s fun,” is the core reason. Programming is like a puzzle. “Given this data, how can I get to that end-point?” And who doesn’t like a good puzzle or riddle?

But It’s Too Hard

Nonetheless, I’m often emailed by students, who either don’t know where to begin, or can’t determine what the next step is.

“What should I master next?” they frequently ask.

My typical response is to offer a handful of technologies that they should become fluent in. The irony, though, is that “mastery” shouldn’t be in your thinking just yet. That’s not the way it works. You don’t master HTML, and then master CSS, and so on. If only it was that easy!

The reality is that our web development training is similar to an RPG; you slowly level up in each category, as you gain more experience. An “aha” break-through in, say, Ruby or PHP, will frequently trickle down to a comparable break-through in your JavaScript understanding. Or, as another example, once you begin to grok object-oriented programming, you’ll likely find that you can apply the same principle to your CSS as well! These technologies are linked, even if you don’t immediately recognize it.

Learning how to develop for the web is a slow process of leveling up.

Imposter Syndrome

Unfortunately, from time to time, we all feel a bit down on ourselves. We’re surrounded by so much talent; am I falling behind? The truth is that this is a natural reaction – one that most developers feel at some point or another. It even has a name: “Impostor Syndrome.”

The impostor syndrome is a psychological phenomenon in which people are unable to internalize their accomplishments. Despite external evidence of their competence, those with the syndrome remain convinced that they are frauds and do not deserve the success they have achieved. Proof of success is dismissed as luck, timing, or as a result of deceiving others into thinking they are more intelligent and competent than they believe themselves to be.
– Wikipedia

One could argue that impostor syndrome is a sign of maturity. It ironically takes a considerable amount of education before you realize just how little you actually know. And that’s perfectly okay! Your peers, your teachers, your developer heroes – they’re all still learning new things every day. That’s what makes this industry so exciting. Because it’s still relatively quite young, there’s a vast world of new ideas and techniques at our finger tips. What could be more exciting than that?

So, to return to my one piece of advice: “Don’t worry; we all feel overwhelmed.” The key is to recognize this truth, accept it, and never, never… ever, stop.

I’ve missed more than 9000 shots in my career. I’ve lost almost 300 games. 26 times, I’ve been trusted to take the game winning shot and missed. I’ve failed over and over and over again in my life. And that is why I succeed.”
– Michael Jordan

Source