As I blogged yesterday we created our own coding standard for our Javascript code. In addition to that we were looking for a way to lint SCSS code and found a tool called scss-lint which seems to be the only option out there when it comes to linting scss code. We were not happy with the default settings of scss-lint and came up with our own version which we`d like to share with the world today. Head over to Github and have a look at our cs-scsslint repo. The package can be consumed via npm, the package is called "bitexpert-cs-scsslint".

About two years ago we agreed on dropping our own company-wide code standard (which in fact was none!) in favour of the common standards used in all the programming languages which we use. That's PSR-1 and PSR-2 for PHP projects, the Java Code conventions for our Java projects and the Puppet Language Style Guide for our Puppet cofigurations. For Javascript we were not able to find the one and only standard out there. So once again we had to jump in and create our "own" standard. However, this time we`d like to share it with the world ;)

Long ago I started to globally .gitignore all the things. Recently I ran into a few issues with setting up Sencha projects via SenchaCmd. In my global .gitignore file I have a setting to ignore the vendor folder which perfectly makes sense in a Composer setup. As a side-effect this means that in a Sencha project the folder resources/themes/vendor/ will not be added to the repo. The work-a-round to avoid this is easy and simple. Add the following line to your global .gitignore file:

Am Mittwoch den 22.04.2015 trifft sich die Java Usergroup Mannheim. Ich wurde eingeladen meinen Vortrag "Microservices: Klein aber oho!" zu präsentieren. Der Vortrag gibt einen Einblick was Microservices wirklich sind, welchen Vorteil sie uns im Alltag bringen und welche Anforderungen Microservices an die Unternehmenskultur stellen.

Recently I had the need to extend a Silex application to be able to return JSONP responses when needed. I was looking for a generic approach and came across a blog post by Raphael Stolt who solved the problem with a clever "after middleware". This is the code you need to add to your app.php file:

Recently we developed a mobile application based on Sencha Touch and Cordova. The application was communicating with a REST backend. Since I did not want to change the URL to the REST backend manually when deploying the app in the testing or production environment, I was looking for a way to use multiple configuration files based on the active environment.

Vom 25.06.2015 bis zum 27.06.2015 findet in Amsterdam die Dutch PHP Conference 2015 statt. Ich freue mich zum sechsten Mal in Folge dabei zu sein und meine beiden Vorträge "The NoSQL Store everyone ignores: PostgreSQL" und "Improving the quality of your Javascript application" präsentieren zu dürfen.

Since version 2.5.1 of jshint it is possible to extend your own .jshintrc configuration from another .jshintrc config file. This allows you to extend a common configuration and add project specific options (e.g. custom global variable names) to a local configuration file. This way you do not end up with the pain of keeping multiple configurations in sync. It's fairly trivial to use. In your .jshintrc configuration file add an extends field which points to the configuration you are extending from:

Am Donnerstag den 19.03.2015 trifft sich die PHP Usergroup Frankfurt. Auf vielfachen Wunsch hin werde ich meinen Vortrag "Microservices: Packs small, plays BIG!" halten und erklären was Microservices wirklich sind, welchen Vorteil sie uns im Alltag bringen und welche Anforderungen Microservices an die Unternehmenskultur stellen.

For quite some time we run the unit tests for our libs and tools against PHP and HHVM, at least that is what I thought up to now. As it turns out I missed a minor detail. In our Jenkins job we invoke the Phing task like this: