A few weeks ago I gave a presentation at the Jenkins User Conference London 2015 about how we have set-up and use Jenkins to power our builds. One idea I mentioned in the talk and I`d like to share now is how we bind our jobs to specific buildnodes. Given the fact that we are doing lots of different projects for different clients we have quite a few buildnodes to cover every use case we need. When we started using Jenkins about 4 years ago we bound every job to a set of specific buildnodes (e.g. buildnode01 || buildnode02). When our setup grew, it was not easy to keep up-to-date to figure out which buildnodes offer which capabilities. In the end this lead to jobs failing every now and then because Jenkins picks a buildnode from the list which does have all the required tools installed, this behaviour I call the "Jenkins law".

This article is the second of a three-part series and describes how we optimized our data processing and reached performance improvements tweaking our code. Make sure you covered the first article about how we tweaked PHPExcel to run faster while reading Excel and CSV files.

Google Chrome 43, which was released in mid-May, has introduced several problems for applications using the ExtJS 4.x or the Sencha Touch 2.x frameworks. For example, the 'painted' event is no longer fired, list components cannot be scrolled, submenu items disappear, and the loadmask no longer plays the spinning animation. This is mainly caused by the removal of the formerly deprecated 'overflowchanged' event. As a reaction, Sencha has offered three overrides, which need to be required in app.js. The overrides can be found here.

A few weeks back I covered a small article about a CSV-Tool optimized for memory usage and additionally tweaking performance.

Am 29.09.2015 und 30.09.2015 findet in Hamburg die conference code.talks 2015 statt. Ich freue mich als Sprecher dabei sein zu dürfen und meinen Votrag "Composer for Corporate Use" zu halten. Der Vortrag stellt dar warum es Sinn macht Composer einzusetzen und wie man Composer konkret im Projektkontext im Unternehmen einsetzen kann.

Recently in an AngularJS project we used the ngTagsInput directive for AngularJS. In the documentation it is shown how to set-up your own function to load the data for the autocomplete functionality. Since our API returned the data in a way that ngTagsInput did not expected it, I needed a way to convert or extract the data before returning it to ngTagInput. It turned out to be quite easy:

I recently covered our Vagrant setup. As mentioned in the blog post we mostly use the Vagrant shared folders setup which unfortunately is rather slow. When searching for alternatives I came across the vagrant-gatling-rsync plugin which seems to work better compared to the built-in rsync support of Vagrant. As it seems the built-in rsync support uses a lot of CPU and disk I/O especially when working with very large rsynced directories. The vagrant-gatling-rsync plugin is designed to work well with such large rsynced folders and performs a lot better. In addition to that you are able to fine-tune the rsync latency via your Vagrantfile which is also a huge win. To install the plugin simply run the following command:

Vom 29.09.2015 bis zum 01.10.2015 findet in Karlsruhe die Konferenz data2day 2015 statt. Ich freue mich dabei zu sein zu können und mit meinem Vortrag "PostgreSQL: Die NoSQL Datenbank die niemand kennt" zeigen zu können dass sich auch tradtionelle relationale Datenbanken für "NoSQL" Anforderungen eignen können.

Lately I have seen more and more libraries picking up PSR-3 when it comes to logging. What a lot of libaries do wrong is that they depend on a concrete implementation of PSR-3, e.g. Mongolog instead of relying on the PSR-3 interface. From what I have seen this is because loggers get instantiated directly within the class. This is not a bad thing but it couples your code to a concrete implementation of PSR-3 which in turn means that there's no interoperability.

There's one plugin for Vagrant which I love to promote in my talks and this is the Cachier plugin. When giving my talks and mentioning the plugin I realized that not many people are aware of the plugin. That's the main reason I write the following lines. The downside of Vagrant is what whenever you destroy a virtual machine and build it again all packages (eg. .deb packages for the OS or Composer packages for the application) need to be downloaded again. Downloading and installing a lot of packages can be quite time consuming which in turn means developers try to avoid it. Which in turn means no one regularly checks if provisioning of the virtual machine still works as it should. The Cachier plugin is the solution for that problem. As the name implies the plugin will cache the downloaded packages and re-use them when possible. To achieve that the plugin will link several folders of the virtual machine back to the host, so that the packages are actually stored on the host, not the vm. Very clever.