Hab gerade auf der Fahrt in die Arbeit die Episode “Paul Adams on Product” des Intercom Podcasts gehört (den ich grundsätzlich immer recht interessant finde und deshalb abonniert habe), und da sind mir 2 Punkte hängen geblieben:

1. Aus seiner Zeit bei Google und Facebook hat Paul gelernt welchen Unterschied verschiedene Teamgrößen und das Verhältnis zwischen der Anzahl an Projektmanagern, Designern und Engineers macht. Er findet deshalb, dass die beste Teamgröße 1 Projektmanager : 1 Projektdesigner : 4-5 Engineers ist.
2. Bei Google wurde immer für 20 Jahre und für 1 Jahr “geplant”. Wobei 20 Jahr die Vision darstellte in welche Google die Welt verändern will. Paul arbeitet jetzt bei Intercom nach einem Modell dass für Startups und kleinere Unternehmen besser geeignet ist als der lange Zeitraum von 20 Jahren und einem Jahr. Er nennt es 666 😉 Das bedeutet sechs Jahre, sechs Monate und sechs Wochen. Sechs Jahre als Vision, sechs Monate als längerfristige Planung was die Produkte betrifft und sechs Wochen für die tägliche Projektarbeit als Ziel.

Die Episode vom Intercom Podcast sind immer super aufbereitet in eine Blog Post nachzulesen, sogar mit dem vollen Transkript.

Nachdem in den letzten Monaten Tesla Motors in den Nachrichten war, weil sie zuerst via Softwareupdate den Autopiloten nachgerüstet haben und jetzt das “Summoning” (selbständiges Ein- und Ausparken), habe ich mir die Frage gestellt seit wann Softwareupdates eigentlich so cool geworden sind.

Ich hab ja immer schon gerne Softwareupdates eingespielt, auch wenn nicht wirklich neue Funktionen dadurch dazugekommen sind. Für die meisten Benutzer war es aber schon zu mühsam Windows Updates einzuspielen bevor das voll automatisiert wurde.

You can t tempt developers to support Windows Phone by saying “it’s easy to deploy your desktop app to mobile” if there is no desktop app.

Good article from Benedict Evans about the new strategy of Microsoft.

Letzte Woche hatte ich die Gelegenheit beim 27. Technologieplauscherl über Docker zu sprechen. Es hat mich sehr gefreut, dass mehr als 75 Leute beim Plauscherl waren und mir super Feedback zu meinem Talk gegeben haben. Hier die Folien zu meinem Vortrag:

Zusätzlich zu den Folien haben wir in unserem Podcast Donau Tech Radio dem Thema eine ganze Episode gewidmet: Episode 53 – Docker - damit kann man zu den Folien auch noch mal den Vortrag hören.

Ich war etwas optimistisch, als ich am 19.12.2013 hier auf meinem Blog gepostet habe: Fast am Ziel. Damals hatte ich gerade die Zusage erhalten, in Weichstetten einen FTTH Anschluss zu bekommen. Erst ein paar Wochen später stellte sich heraus, dass noch einiges zu tun war um zum Ziel zu gelangen.

Ende Februar 2014 habe ich dann Markus Lauss und Johannes Schachner aus Weichstetten kennengelernt, die auch beide sehr daran interessiert waren FTTH nach Weichstetten zu bringen. Wir haben uns ein paar mal getroffen und einen Schlachtplan entwickelt.

Mit fällt auf, dass ich in letzter Zeit sehr wenig auf meinem Blog schreibe. Das liegt hauptsächlich daran, dass ich vor eineinhalb Jahren begonnen habe, zusammen mit meinem Freund und Kollegen Andre Steingreß, regelmässig einen Podcast aufzunehmen: Das Donau Tech Radio

Den möchte ich an dieser Stelle allen empfehlen, die gerne mehr davon hören wollen, was mich gerade so beschäftigt.

Shortly after I published my post on Countly in a Docker container my pull request was approved, adding the Dockerfile directly to the Countly github repository.

So now it is possible to build the Countly Docker image simply by running:

docker build -t countly/countly-server https://github.com/Countly/countly-server.git

Countly even created an official Docker hub repository which means you do not have to build the image yourself, just run it via

docker run -d -p 80:80 countly/countly-server

The image will be pulled from the repository and launched on your host - the simplest way to try out Countly.

We are using Countly to track and analyse usage of our various mobile apps at troii. Since we are hosting Countly ourself, and I am in the process of moving all our hosted services and apps into Docker containers, Countly was next.

Dockerfile

Of course the first thing to do when starting with creating a Docker container for a specific application is to look for already existing ones. I found two, but but none of them worked out of the box. The one from dz0ny looked best so I forked the repository and based my efforts on it.

After having our Sonatype Nexus repository running in a Docker container (see my previous post), the next part of our infrastructure I wanted to move into a Docker container was our Jenkins build server.

The most difficult part of this, was to get the Android SDK installed inside the Docker image. After downloading the compressed SDK you have to run the android installer from the tools folder. This installer downloads the requested Android versions and asks for accepting the different license agreements - which is a problem because the building the docker images is non interactive. After a lot of trial and error, I found the Android SDK Installer project on github which provides the necessary scripts.

Since I saw the 5 minute long video “The future of Linux containers” last year in April, in which Solomon Hykes presented Docker the first time at PyCon, I wanted to use Docker for running my server side software.

The first thing I thought about, was using it for running our time tracking product timr. It is currently deployed on multiple hosts with multiple tomcat instances and a MySQL database. Docker would make it easy to spin up more instances and to deploy new versions.