• The Most Dangerous Word In Software Development: “When you hear the word “just” being thrown around, dig deep into that statement and find all of the assumptions made within it.” – it is dangerous to assume things without reflecting on it first
  • Mobile Web vs. Native Apps or Why You Want Both: An interesting reflection on the different use cases for mobile web and native apps, and why one might need both. tl;dr: Mobile Web is great for reach, Native for engagement.
  • It’s a Bystander Problem: “It’s other men who have the power to create social consequences. It starts with refusing to be a bystander by calling things out. Ultimately, if men stopped working with, hiring, and funding those men who behaved badly, the effects would be dramatic.”
  • Good CEOs aren’t busy: “As you start to grow from a tiny startup into something that resembles a more mature company, your #1 priority becomes surrounding yourself with incredible leaders who can do their jobs better than you ever did. You delegate more, question less and start to see the big picture.”
  • Netflix & brilliant jerks: “Some companies tolerate them – for us, cost to effective teamwork is too high” (and a lot of other insights in the team culture netflix had a few years ago)
  • Brilliant Jerks? Bring ‘Em On!: “If a brilliant jerk is someone who simply questions the answers and rejects the status quo, by all means, he should not only be kept, he should be rewarded.” – response to the comment above. When and what kind of jerk might be good to have around in the company
  • Silicon Valley Lies And Those Who Tell Them: “But the media has played up an untrue connection between successful leaders and their occasionally dysfunctional character and demeanor. Being more like Gates or Jobs doesn’t require that you emulate some of the worst behaviors you’ve read about them.”
  • The Hardest, Shortest, Lesson Becoming a Manager: “There’s something we all talk about in becoming a manager – and that’s the process of writing less code. We bemoan it because it’s hard to let go of that part of our identity. But also because it’s so quantifiable. (..) If you team needs a manager more than they need an engineer, you have to accept that being that manager means that you by definition can’t be that engineer. I know some people manage both, but you need to decide if you’re going to suck at one which one that will be.”
  • How to hire: “We should not be afraid of False Positives. We can quickly fix a False Positive hiring decision. (..) For those of you questioning the morality of fast iteration of new hires please consider the alternative: we deny people opportunity for fear they won’t succeed or we keep people in roles where they won’t be successful.”
  • Mockbox: A free “in-browser SMTP server simulator”. Basically, a dumbed down version of Mailtrap without signup and free.
  • Tech leads: Circles of responsibility: Tech leads should have skills from three different core competencies: A classic developer skillset, some insights as a systems architect, and obviously team/leadership skills. This graphic is nice to orient oneself where someone currently is, where to improve.
  • Engineering ladder: I really love this approach to standardize and formalize the various aspects of “seniority” of engineers. There are several situations where such a standardized approach could help: During 1:1s to discuss with an engineer where and how they can improve, to assess ranking and title during job negotiations, and most important as a tool to move from subjective biased employeed “judgements” to a more objective approach.
  • “Success at Work, Failure at Home”: Food for thought: How work and family life affect each other
  • (DE, Werbelink)Mindfuck Job: Okay-ish book highlighting some mechanisms that you might use to block yourself in your job development, and how to get past them.

Cache PECL builds on Travis

One of my customers, Imagine Easy, is making extensive use of Continuous Testing using Travis CI. Some of the test runs require additional PHP PECL Modules to be compiled and installed, like php-apcu or gearman support. Since Travis provides a new provisioned VM for every test, this happens before every test run, and slows it somewhat significantly down.

While Travis has support for caching similar artifacts between builds for other types of data, it is not yet supported for PHP modules.

So I wrote a small shell script and the accompanying travis setup which copies the modules to a cacheable location after compilation, and tries on start to use those cached modules before compiling it if necessary. A sample setup is to be found at Github.

By the way, Imagine Easy is hiring in New York and Berlin – see some of their job offerings here. I can fully recommend working there, the team and technology is pretty awesome.

WordPress: Speed up akismets “show approved comments” feature

The WordPress Anti-Spam-Plugin Akismet features the option to show the number of approved comments for each comment author in the comments overview.

Akismet Comment Count

While this is a somewhat interesting feature to see if this is a regular user commenting, it significantly slows down the admin interface on blogs with a large comment database. This can be fixed by adding a new index to the database assisting the underlying query Akismet does:

CREATE INDEX akismet_comment_count_loggedout ON $PREFIX_comments (comment_author_email, comment_author(100), comment_author_url(100));

Please note that you have to replace $PREFIX with your table prefix, obviously.

Vagrant: Cache packages between rebuilds

Sometimes I have to destroy and reprovision a vagrant box several times. This causes a lot of redundant bandwidth – varnish downloads all those ubuntu packages over and over again. My initial idea was to set up a transparent squid proxy on the host machine, but this turned out to be quite a maintenance nightmare, so I abandoned it.

Luckily, there exists a vagrant plugin fixing my problem: vagrant-cachier mounts several cache directories like /var/cache/apt to the host machine, so they will be already available for a newly provisioned vagrant machine. As soon as my PR is being accepted, composer downloads will be cached the same way, too.

PS: I collected some interesting Vagrantfiles over at my pinboard profile.

Vagrant: Inline provisioning script

Sometimes I use Vagrant not for a full featured chef provisioning setup, but just with a shell script which installs some packages and minor modifications. This can be done using a separate shell script, but I prefer having it inline, so the whole setup is visible within one file:

Vagrant: Naming your boxes

Being a pretty heavy user of Vagrant, I tend to have multiple Vagrant boxes idling on my machine.

The plugin vagrant list helps to shed some light there by showing a list of all current existing vagrant boxes and the current status in the console. However, the name of the box is by default just the name of the directory the Vagrantfile resides in and a numeric id, resulting in something like var_1370856673.

Thankfully, there exists the --name virtualbox-parameter, where you can provide a better custom readable name for your box:

And suddenly, the list of boxes on your machine make a lot of sense.

Debugging OpsWorks

Amazon Opsworks, the awesome tool formerly known as Scalarium, stores all its logfiles and json-dumps of every task being executed in /var/lib/aws/opsworks/chef at the instances.

The JSON-dumps are quite handy to figure out what variables are available to be used within the custom cookbooks. To have them somewhat more readable, use python:

cat <timestamp>.json| python -mjson.tool

Update: Or, way simpler: Use opsworks-agent-cli get_json – thanks, till. :)

Deployment mit Chef – Teil 3: Vagrant

Whoops. Ein Produktlaunch und ein paar Tage fiese Erkältung später, und der letzte Beitrag hier ist schon drei Wochen vorbei. Sorry. :)

Nach dem eher allgemeinen Teil 1 und Teil 2 zu Chef nun endlich zum spannenden Teil: Wie nutzt man den Kram eigentlich?

Wie auch die Entwicklung einer Webapp startet diese Frage bei der Entwicklungsumgebung. In den meisten Projekten, in denen ich bislang meine Nase hatte, gab es meist einen von zwei Ansätzen für die Entwicklungsumgebung: Entweder gab es ein Image für eine Virtualisierungsumgebung, das herumkopiert worde, oder es wurde direkt auf der Host-Maschine ein mehr oder weniger klassischer LAMP-Stack installiert, konfiguriert, und damit entwickelt. Ein gern gesehener Gast hier war zum Beispiel XAMPP.

Mit Chef haben wir nun den Vorteil, dass das Setup der Server jederzeit gescripted reproduziert werden kann – und genau das nutzen wir auch für unsere Entwicklungsumgebung. Mit Vagrant kann vollautomatisch eine Instanz in Virtualbox initialisiert und installiert werden. Damit kann jederzeit mit drei Befehlen eine neue VM aufgesetzt werden, die im Setup und Konfiguration sehr ähnlich zur Live-Umgebung ist. Vagrant existiert für Linux, Windows, OSX und Solaris.

Vagrant ist sehr einfach zu installieren: Zunächst muss Virtualbox installiert werden. Virtualbox ist die eigentliche virtuelle Umgebung, in der der virtuelle Server später ausgeführt wird. Ebenfalls gebraucht wird ruby – aber ich gehe mal davon aus dass jeder Entwickler das sowieso auf seinem Server schon sauber konfiguriert hat ;) Anschliessend wird vagrant mit “gem install vagrant” installiert – alternativ kann vagrant auch mit Installationspaketen installiert werden, mehr dazu auf der Vagrant-Website.

Die Konfiguration der VM von Vagrant wird in einer Datei Vagrantfile festgelegt. Unsere Konfiguration bei Digital Pioneers sieht in etwa so aus:

Mit dieser Datei lässt sich eigentlich der Server auch schon direkt mit vagrant up starten und aufsetzen. Wichtig sind hier allerdings einige Pfade, die entsprechend angepasst werden müssen:
chef.cookbooks_path ist der Pfad zu den Chef-Cookbooks, die von Vagrant ausgeführt werden sollen. Ausserdem werden zwei Verzeichnisse mit der Host-Maschine geteilt: webdev ist relativ logisch: In diesem Mount befindet sich der Code der App, die wir entwickeln. aptcache ist dagegen ein “Hack” – die von Ubuntu heruntergeladenen Pakete werden dadurch auf der Host-Maschine gespeichert. Damit müssen bei einem zweiten Aufsetzen der Virtuellen Maschine nicht erneut alle Pakete heruntergeladen werden, sondern werden direkt aus dem Cache installiert. Bonustipp: In dem Verzeichnis muss sich das (leere) Verzeichnis “partial” befinden, sonst fällt apt auf die Nase.

Durch das Portforwarding kann dann mit einem Zugriff auf http://localhost:8080 der Webserver der virtuellen Maschine erreicht werden.

Vagrant ist relativ selbsterklärend, und auch gut erklärt – vor den ersten Schritten mit Vagrant lohnt es sich aber trotzdem, den “Getting started”-Teil der Doku von Vagrant querzulesen, da hier die wichtigsten Kommandos vorgestellt werden.

Im Entwicklungsalltag bei uns hat sich gezeigt, dass Vagrant zwar durchaus seine Ecken und Kanten hat: Insbesondere die Datei-Mounts, über die Daten zwischen Hostmaschine und der VM geteilt werden können ziemlich zickig sein. Auch fehlt beispielsweise ein sinnvolles Vagrant-Plugin, mit dem direkt von aussen verschiedene Shell-Kommandos in der VM ausgeführt werden können, wie etwa Unittests oder die Generierung von Sass-Assets.

Allerdings sind die Vorteile von Vagrant klar überwiegend: Mit Vagrant können wir mit wenigen Kommandos die Entwicklungsumgebung wieder auf den ursprünglichen Zustand zurücksetzen, das Setup der Entwicklungsumgebung und der produktiven Server wird parallel vorangetrieben, und die Einführung in ein neues Projekt ist sehr viel weniger aufwendig.