Gophers meet in Berlin

Last Friday – coincidentally pi day – we attended the Golang User Group meetup at the Hub:raum in Berlin. The Hub:raum cafe, which is a beautiful space filled with an eclectic mix of seventies inspired design, hosted us bunch, a little over 20 attendees.

After a 5 minutes presentation of the sponsor of the evening; Spiffy, ‘incubating’ a number of projects written in Go, Alexander Surma (@surmair) presented, GoPin – a tool-less version pinning for Go. Alexander described his package manager like a man in the middle between your app and Github, Bitbucket, et al. In the end, GoPin made way for gopkg, written by Gustave Niemeyer. (more…)

Talking AngularJS and Internationalizing in Berlin

AngularJS-Berlin
Yesterday we attended the AngularJS Meetup Berlin, that took place at the Bitcrowd offices. Pascal Precht (CouchCommerce, sofa.io) talked about ‘i18n with angular-translate‘, or:
“going beyond basic localization with angular-translate”.

Starting with an introduction to AngularJS, Pascal evangelized the JavaScript framework (or rather: HTML compiler) that gives you two way binding (ng-model, ng-repeat) and dependency injection. And is built with testability in mind. (more…)

How to use the anynines Swift service with Paperclip

Web applications often produce files such as images, videos or documents. For a long time it was standard to put those files into the filesystem. Today this is considered a bad practice.

Why is storing to filesystem bad?

Using the filesystem as persistent storage breaks with rule number 6 of the 12factor manifest. This introduces two major architectural flaws:

1. Filesystems don’t scale well.
When storing a large number of files there is a point where a single server is not enough anymore. At this point filesystems become a problem as they don’t span across servers. Managing distributed filesystems is… painful.

2. A filesystem is a single point of failure.
Servers die and so will file servers. Making NFS servers, for example, redundant is an awkward task because it was never designed to be highly available.

Instead we want a storage service that is scalable and highly available by nature.

That’s where OpenStack Swift comes in.

Swift is highly scalable and can serve up to hundreds of petabytes. More than that it is also redundant. Data is replicated across a number of storage nodes. This allows Swift to survive the outage of one or multiple servers. (more…)