Bislang dachte ich, dass eine Geburtsurkunde ein amtliches Dokument ist, dass bei der Geburt eines Menschen als einzelnes Schriftstück ausgestellt wird und bei Verlust nur unter extrem hohem bürokratischem Aufwand neu ausgestellt werden kann.
Wie ich heute festgestellt habe, ist das nicht der Fall und man kann durchaus mehrere Exemplare der eigenen Geburtsurkunde haben und beim Standesamt seines Geburtsortes problemlos, gegen ein entsprechendes Entgelt, weitere Exemplare erhalten.

Club-Mate bei ICA in Schweden
Ich bin gerade das erste Mal Club-Mate im Ausland begegnet und das auch noch ohne danach zu suchen. Es stand einfach auf diversen Tischen eines Szenecafes im angesagten Stockholmer Stadtteil Södermalm. Gut, irgendein Cafe-Besitzer der für den Verkauf in seinem Cafe Club-Mate selbst importiert um es als “exotisches” Getränk im Angebot zu haben, das klang für mich nicht weit hergeholt.

Erstaunt war ich dann allerdings als ich Club-Mate ebenfalls im Regal eines schwedischen ICA, einer der großen schwedischen Supermarktketten, fand. Dort ist es für 22,90 SEK zu haben, was nach aktuellem Wechselkurs ungefähr 2,60 EUR entspricht. Das wiederum ist ungefähr der dreifache Preis, den man in Deutschland für eine Flasche Club-Mate bezahlt, aber angesichts der Tatsache, dass Lebensmittel in Schweden generell teurer sind als in Deutschland (am absurdesten finde ich Speiseeis mit 25 SEK pro Kugel im Straßenverkauf) und Club-Mate extra importiert werden muss, finde ich den Preis durchaus vertretbar.

Club-Mate mit schwedischem Label

Wie auf dem unteren Foto schön zu sehen, druckt Loscher die Flaschenfront mit einem generischen Label auf Englisch und die Rückseite mit Zutaten & Co. auf schwedisch. Man scheint dort also inzwischen verstanden zu haben, dass Club-Mate auch im Ausland gut ankommt. Das finde ich sehr löblich, denn so ist zumindest Club-Mate dort verfügbar, wo die von mir inzwischen favorisierten 1337Mate und Flora Power nicht zu bekommen sind.

Die Bezeichnung “Cloud” ist schon seit einer ganzen Weile ein Hype-Begriff und wurde von mir lange belächelt. Denn was unterscheidet schon “die Cloud” von dem, was schon immer das Internet selbst definiert?

Seit gut einem halben Jahr habe ich nun beruflich recht intensiv mit ebendieser Cloud zu tun, um genau zu sein mit Amazon Web Services (AWS).
Grundsätzlich stehe ich solchen großen Unternehmen wie Amazon erstmal skeptisch gegenüber, denn je größer ein Unternehmen desto wahrscheinlicher ist eine marktbeherrschende Stellung und die Ausnutzung dieser. Auch Amazon hat bereits mit seinem Online-Shop gezeigt wie gut sie in der Lage sind eine marktbeherrschende Stellung zu übernehmen.

Auch der Bereich Cloud-Computing ist bei Amazon inzwischen so groß, dass sie in diesem Bereich der größte Anbieter sind und er in Zukunft voraussichtlich ähnlich hohe Gewinne abwerfen wird wie ihr Online-Shop. Doch wodurch kommt das? Beim Online-Shop sind die wichtigsten Kriterien für den Erfolg meiner Meinung nach niedrige Preise und guter Service. Zumindest mit niedrigen Preisen kann AWS auf den ersten Blick nicht punkten.

Während man bei üblichen Hostern im niedrigen Preissegment in Deutschland problemlos Server mit Quadcore Prozessor, 16GB RAM und mehreren Terabyte an Plattenplatz für 50 Euro im Monat bekommt, zahlt man bei AWS in der billigsten Region (und zwar us-east-1 und us-west-2, beide in den USA) mindestens 300 Dollar für ähnliche Hardware. Bei Mehrausgaben von 500% muss also entweder ein relevanter Mehrwert vorhanden sein oder die Angebote von Amazon sind maßlos überteuert.

Die Erfahrungen der letzten Monate haben mir gezeigt, dass die Preise durchaus berechtigt sind und was “die Cloud” von herkömmlichen Webhostern unterscheidet.

  1. Amazon bietet nicht einfach wie andere Webhoster reine Hardware, sondern eine komplette Infrastruktur mit unterschiedlichsten Dienstleistungen und dazugehörigen Programmierschnittstellen (APIs) für diverse Sprachen an. So ist unglaublich viel Funktionalität um deren Bereitstellung man sich sonst selbst kümmern müsste bereits vorhanden und lässt sich neben einem Webinterface komplett über APIs nutzen und somit einfach in eigene Anwendungen einbinden.
  2. Hardwarenahe Probleme gehören der Vergangenheit an. Darum kümmert sich Amazon und da alles in irgendeiner Form virtualisiert läuft, bekommt man als Anwender davon auch nur in Ausnahmefällen etwas mit.
  3. Die Dokumenation der einzelnen Dienste ist umfangreich und verständlich und als größerer Kunde bekommt man unglaublich gute Betreuung und ausgezeichneten Support.
  4. Amazon ruht sich nicht auf seiner Marktstellung aus, sondern veröffentlicht fast im Tagesrythmus neue Verbesserungen ihrer Cloud-Plattform.
  5. Eigene Dienste lassen sich ohne großen Aufwand in lokal gruppierten, aber räumlich getrennten Rechenzentren (Availability Zones) oder auch weltweit verteilt über fünf Kontinente (Regions) betreiben.

Dazu kommt, dass die Preise aus dem oben genannten Beispiel bei intensiverer Nutzung je nach Anwendungsfall drastisch sinken, wenn man Reserved Instances oder Spot Instances nutzt.

Mir macht es, aufgrund der oben genannten Gründe, unglaublich viel Spaß mit AWS zu arbeiten und für mich ist inzwischen gut nachvollziehbar, warum Amazon im Bereich Cloud-Computing diese überragende Marktstellung hat: So schade das für gesunden Wettbewerb ist, aber es gibt einfach keinen Anbieter, der auch nur ansatzweise die gleichen Dienste bieten kann und wenn ich mir das Tempo an Innovationen bei Amazon anschaue, dann wird das auch noch lange so bleiben.

Die Debatte um die Deutsche Telekom, die sich in neuen DSL-Flatrate-Verträgen nun vorbehält nach dem überschreiten eines bestimmten Übertragungsvolumens die Verbindung zu drosseln, ist ja inzwischen nun schon ziemlich breit durchgekaut worden. Als Option wird es wohl möglich sein, gegen Aufpreis wieder eine echte Flatrate zu bekommen.
Ich frage mich allerdings, warum sich die Telekom überhaupt diesen medialen Stress gemacht hat? Sie hätte doch auch einfach die neuen Verträge nicht mehr Flatrate nennen und stattdessen entsprechend teurere Verträge mit der Bezeichnung Flatrate einführen können. Dann hätten sie PR-technisch sogar noch entgegengesetzt argumentieren können, dass bei ihren Nicht-Flatrate-Verträgen nach erreichen des Limits ja “nur” gedrosselt wird, statt gleich komplett abzuschalten.

IKEA ist “in” und das schon seit Jahren. Das wird meist mit den, im Vergleich zu traditionellen Möbelhäusern, bezahlbaren und modernen Möbeln erklärt. Aber ich finde IKEA hat noch ganz andere Vorzüge. Vorzüge, die traditionelle Möbelhäuser nicht bieten wollen und oft auch gar nicht können, da die Möbel keine Eigenproduktionen sind, sondern letztendlich nur aus den Katalogen ihrer Zulieferer stammen.
Mir sind die folgenden Vorzüge von IKEA aufgefallen.

Eine ausgesprochen gute Internetpräsenz

Die Webseite von IKEA listet auf sehr ansprechende und übersichtliche Weise sämtliche im Angebot befindlichen Artikel auf. Von Beschreibung und Fotos, über Maße und Bedienungsanleitungen bis hin zu Lagerstand in der jeweiligen Filiale und dem exakten Regalfach in dem es bei IKEA lagert. Und wem das noch nicht reicht, der kann die Artikel gleich im Internet bestellen.

Modulare Bauweise

Der Klassiker dafür ist der bekannte IKEA-Schraubenschlüssel, der für gefühlte 90% aller IKEA-Schrauben passt. Gerade die Vereinheitlichung von Kleinteilen, wie zum Beispiel Schrauben, auch über diverse Produktfamilien hinweg, sorgt (neben Kostensenkungen bei der Produktion) dafür, dass man einfach und unkompliziert Ersatzteile anbieten kann. Inzwischen gibt es in IKEA-Filialen sogar Automaten aus denen man sich Schrauben und Co. besorgen kann.

Langlebige Produktlinien

Serien wie die berühmten Billy-Regale kennt inzwischen vermutlich fast jeder. Viele der eigenen Produkte bietet IKEA über lange Jahre hinweg an, so dass einer Erweiterung des Mobiliars nichts im Wege steht. Wobei das nicht heißt, dass bei bestehenden Serien keine Änderungen mehr durchgeführt werden. Neue Farben und Muster werden von IKEA gerne eingeführt und auch die Ausführung im Detail über die Jahre mal angepasst. Letzteres fiel mir bei den Billy-Regalen auf, von denen ich inzwischen zwei Generationen mit unterschiedlicher Befestigungstechnik für die Aufsatzregale kenne.

Die genannten Punkte sind für mich ein klares Zeichen für die Fixierung auf die Bedürfnisse der Kunden und so soll’s ja schließlich sein. Allerdings kann das natürlich nicht darüber hinweg täuschen, dass die Qualität der Möbel bedingt durch die Preise oft nicht die Beste ist. Insbesondere wenn man versucht damit umzuziehen, sorgt das schnell mal für Tränen. Aber auch dafür hat IKEA eine Lösung gefunden: Kunden können sich direkt bei IKEA mit Köttbullar und schwedischem Apfelkuchen darüber hinweg trösten. 😉

Google hat heute eine Webseite zum schon länger in Entwicklung befindlichen “Project Glass” veröffentlicht. Glass ist platt gesagt eine intelligente Brille mit Kamera und Display, die es erlaubt im alltäglichen Leben ins eigene Sichtfeld zusätzliche Informationen eingeblendet zu bekommen und das eigene Sichtfeld zu filmen.
Auf der Webseite ist unter anderem auch das im Folgenden eingebettete Video zu finden.

Beim anschauen des Videos drängt sich mir förmlich auf, dass Google Glass, sobald es für den Massenmarkt für einen bezahlbaren Preis verfügbar ist (und dafür wird Google sorgen), das Produkt sein wird, nach dem Apple so krampfhaft sucht: The Next Big Thing.

Some time ago I had the requirement to limit the number of requests per IP to a CouchDB-instance. I couldn’t find an option for CouchDB to achieve that, but as communication with CouchDB is based on HTTP-requests I thought that it should be possible to use nginx as reverse proxy with rate-limiting capabilities for CouchDB. The CouchDB-wiki lists some basic steps how to use nginx as reverse proxy, but rate limiting isn’t mentioned there.

Beside the actual rate limiting I noticed that nginx won’t work, because it doesn’t support chunked request-bodies out of the box, which CouchDB seems to rely onto. But to the rescue there is a nginx module called ngx_chunkin, which adds chunkin support to nginx. To get that module in Debian you need to install nginx-extras from the repository (available since squeeze-backports). The configuration of that module is straight forward as described on the wiki page. All you have to do is to put the following code snippet into the server-context of your nginx configuration:

        chunkin on;

        error_page 411 = @my_411_error;
        location @my_411_error {
                chunkin_resume;
        }

Having solved that issue, doing the actual rate limiting was the next step. Therefore nginx ships the module ngx_http_limit_req_module. All I had to do was to configure a zone for the limited requests in the http-context of the configuration:

limit_req_zone $binary_remote_addr zone=couchdb_write:10m rate=10r/s;

and the logic what to rate limit (writing requests in my case) into the server-context:

        location / {
                # POST, PUT, DELETE ... requests will get rate limiting
                if ($request_method !~* GET) {
                        rewrite ^(.*)$ /throttled$1 last;
                }

                proxy_pass       http://127.0.0.1:5985;
                proxy_buffering  off;
                proxy_set_header Host $host;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }

        location /throttled {
                internal;
                limit_req        zone=couchdb_write burst=10000;
                rewrite /throttled(.*) $1 break;
                proxy_pass       http://127.0.0.1:5985;
                proxy_buffering  off;
                proxy_set_header Host $host;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }

So if you put together the chunkin support and the rate limiting, you’ll get the following piece of configuration for a server which does rate limiting of writing CouchDB-requests using nginx:

limit_req_zone $binary_remote_addr zone=couchdb_write:10m rate=10r/s;

server {
        listen 5984;

        chunkin on;

        error_page 411 = @my_411_error;
        location @my_411_error {
                chunkin_resume;
        }

        location / {
                # POST, PUT, DELETE ... requests will get rate limiting
                if ($request_method !~* GET) {
                        rewrite ^(.*)$ /throttled$1 last;
                }

                proxy_pass       http://127.0.0.1:5985;
                proxy_buffering  off;
                proxy_set_header Host $host;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }

        location /throttled {
                internal;
                limit_req        zone=couchdb_write burst=10000;
                rewrite /throttled(.*) $1 break;
                proxy_pass       http://127.0.0.1:5985;
                proxy_buffering  off;
                proxy_set_header Host $host;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
}

I really enjoyed figuring that out, because it was a lot of fun to be able to use a great tool (nginx) to extend another great tool (CouchDB), because they’re using the same protocol (HTTP).

die geladenen Elemente auf der "Microsite" von IKEA PAXAuf der deutschen IKEA-Webseite gibt es aktuell eine PAX-“Microsite”. Diese ist echt schick. So bekommt man beispielsweise durch scrollen verschiedene Schrankkombinationen und Befüllungen innerhalb desselben Bildes angezeigt. Auch werden moderne Technologien, wie zum Beispiel jQuery und Modernizr, benutzt.
Was mich dann aber doch etwas staunend zurück ließ ist die Tatsache, dass beim Aufruf der Seite über 1500 HTTP-Requests ausgelöst werden und die damit angeforderten Daten eine Gesamtgröße von über 35MB haben? Srsly? Das geht doch auch besser.