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 Konferenz 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.
Currently we have to refactor some parts of an ExtJS4 application for one of our clients. During the refactoring process we renamed some namespaces to fit the current naming schemes, which changed a little bit over the time.
Inspired by Ben Ramsey`s blog post I thought I should share my PHP story as well. I discovered PHP in late 1999. Back then I was looking for an alternative to Perl which I used back in those days to "hack" smallish web applications. I did not really like the syntax of Perl (sorry) and it was always hard to debug on most web hosts. By accident I found PHP and loved it, well in fact I still do love it. I used PHP in 2001 in my first job where I had to develop a web-based DNS management system which was the biggest project for me back in those days.