How to make Git ignore different line endings

warning: CRLF will be replaced by LF in [filename].
The file will have its original line endings in your working directory.

Getting errors like these, and want to deliberately ignore them?

If you don’t know why you would, you should read this great blogpost about line endings in Git by Tim Clem.

Don’t look at line endings!

In some cases you want to ignore these errors. In my specific situation i don’t want Git to warn me about the line endings, because my IDE takes care of that. I work in a project with multiple people, and somewhere in the process some files with different line endings than the project standard slipped into the repo. It happens. Your Git could be configured so that it automatically corrects the file line endings for you when you pull this code.  And this can be pretty annoying.

You can change this behaviour, but again, to avoid problems you have to know the reason why you get these errors. Be sure you know, see the link earlier in this post.

You can disable the CRLF behaviour completely, or per filetype by changing entries in your .gitattributes file. In my case, i put this:

* -crlf

This tells git to ignore the line endings for all files. And does not change the files in your working directory. Even if you have the core.autocrlf set to true, false, or input.

PHP CLI remote debugging with PhpStorm & Zend Debugger

This post aims to give an overview of how to get remote cli debugging working with PhpStorm and Zend Debugger. You can find more detailed information under the links in this article.

Some time ago i wanted to debug a PHPUnit test in PhpStorm, debugging PHP scripts using the cli sapi turned out to require some extra effort.

The situation is that my project files reside in a virtualbox, and open the project files -via a mounted directory- in PhpStorm. This means that, for normal web debugging, you have to specify some server settings, including the path mapping.

Since you work on the server directly, you have to set up a remote debugging connection to your IDE. In his blog post, Kevin Schroeder explains how to do this.
You can do this by running the following command, as copied from Kevin’s post:

Don’t forget to change the IP-address and port to the address that you’re IDE is running on.

Now there is one more thing you have to do to make PhpStorm understand where the files are, otherwise you still wouldn’t hit those breakpoints.
According to this article from the JetBrains team, this can be done by setting the PHP_IDE_CONFIG environment variable to “serverName=name-of-server” where name-of-server is the name as configured in Project Settings -> PHP -> Servers.

And oh, make sure your “Listen to Debug connections” button is green!

As i work with different projects on the same virtualbox, i have created this small script that you can put in your .bashrc

You can enable debugging by running:

$ bugon server-name

And disable by running:

$ bugoff

Happy debugging!

Software Development and the Broken Windows Theory

There is a theory called the “Broken Windows Theory“. This theory states that if there is a disorder in a neighbourhood for a substantial period of time, the mess will only get worse. The authors give the example of a broken window in an abandoned building. If it isn’t replaced within some time, the chances are that vandals will break another window. And another. Gradually making the mess worse, and therefore making the issue bigger.

How the broken windows theory relates to software development

This theory applies to quality in software development as well. Over time the quality of our software may decrease for a variety of reasons. For instance, when under the pressure of a deadline we tend to do concessions to the quality of our software. Or when some tests fail, and no-one acts, it doesn’t motivate to write good tests and more tests will fail over time. Effectively making the testsuite useless. This disorder is also known as technical debt.

How it works

The mechanic about this effect is that you unconsciously and gradually lower the norm of quality of your software. This is of course not what you want for your customer. But also for your team.
Not responding to the “broken windows” in your project will effectively change the mindset about quality, and it leads to passive/reactive behaviour. Do you know that feeling that you’re constantly running into problems with existing code? Then you might have had some broken windows for too long!

Fix the windows!

The broken windows theory in full effect
©2012 iStockphoto

The solution that the broken windows theory describes is to actively monitor and report any disorder like a broken window, litter, holes in the road, or graffiti. In software development their equals would be poor code, bugs, failing tests, or bad design implementations.

The key to success is to maintain a zero tolerance policy on technical debt. And to clean up the list of disorders within a timely fashion.
Of course, you and your team have to decide on what you consider technical debt within the project. This will usually be affected by customer expectations and/or budget. But make sure you all agree on what the quality standard is. Otherwise maintaining a zero tolerance policy will be ineffective, and may cause frustration.

It’s in your hands

Implementing this strategy is something you can start doing today. If you start pointing out and act to the so-called technical debt, you will soon start a movement within your team. You will create awareness and team members will follow your example. Social control on the subject will grow, which encourages to stick to the set quality standards.

Ultimately leading to a better product, happy teams, and happy customers!

Productivity ABC: A



© 2011 foxbit –

Automation can be very profitable when it comes to boosting productivity. Not only because you don’t have to do an action manually, but there are other productivity gains.

Eliminating the possibility of human error is one of them. Automation is especially useful for repetitive tasks. Tasks which are more often than not boring as waiting for grass to grow.
Waiting, or being bored decreases focus and causes the need for distraction. And losing focus on the task at hand is the worst thing that can happen to your productivity.

There are a lot of tools that can help you with automating different type of tasks. As a software developer i usually make small scripts for tasks i need to automate. Therefore i don’t use many automation tools. However, if you have suggestions for productivity tools, please leave a comment!
Some of my favourite automation languages: PHP & shell.

Attention span

Oh look, a butterfly!

Distraction: “Oh look, a butterfly!” – © 2012 irum –

Try to find out what your average attention span is, and always take a short break after that period.
It doesn’t have to be a long break. Just grab a coffee, stretch, do a small (but different) task, or anything like that. You need this to re-focus on the task. If you start on the original task again, work while your attention span lasts, and then take a break again to refocus after that.

It may sound that you will lose a lot of time because of all the breaks, but this is not true. (if your breaks are short enough, hehe).
Working longer on a task longer than your full attention lasts will result in working less efficient, and what you do is possibly more prone to errors. So taking a break every now and then will most likely boost your productivity.

Finding out how long your attention span lasts can be quite a challenge. It might be good to know that the maximum attention span lies somewhere between 3 minutes (young children) and 20 minutes (adults).
The easiest way to find your attention span is to start a stopwatch, and start working on the task you want to complete. Stop the stopwatch and remember what time is on the stopwatch. Reset and start the stopwatch and continue on the task. Do this a couple of times and you’ve found your average attention span.

For more information on attention span visit Wikipedia.

Is success the key to happiness, or the other way around?

Yesterday I was watching this TED talk from Shawn Achor and this question hasn’t left my mind since. The speaker talks about that being happy makes you work and learn more effective, and claims that therefore you can be more successful. I think this statement, or rather, fact is very valid and is worth to stop and think about for a minute.

Shawn mentions that chasing happiness by working towards successes that we want to have is a never ending one, as we constantly set new targets and raise the bar. Or, quoting Shawn “If happiness is on the opposite side of success, your brain never gets there.”

Standing still by what we have achieved so far makes one happy, and let’s you do and focus on what you like and love. Which, according do Gary Vaynerchuck (you should read his book Crush It! and The Thank You Economy) is the key to success and personal development. Which, in turn, raises your level of success and if you stick to this approach, your level of happiness.

Think about it. What is your attitude to happiness and success?

I found this all very interesting and worth thinking of. If you are reading this and are looking for more in-depth info I can recommend you to view Shawn’s presentation.

Fast search and replace in large files with sed

Last week i had to search and replace all occurences of a string inside a relatively big MySQL database dump file. My previous experiences with search and replace actions in files of similiar size or bigger suggested that this was going to take me a while. Normally i would write a small PHP script to do the search and replace action for me. However, recently i’ve been looking to find better, more productive, ways to do everyday things. So after a quick google i found the *nix tool sed.

What sed is, is best described from it’s manual:

Sed is a stream editor. A stream editor is used to perform basic text transformations on an input stream (a file or input from a pipeline). While in some ways similar to an editor which permits scripted edits (such as ed), sed works by making only one pass over the input(s), and is consequently more efficient. But it is sed’s ability to filter text in a pipeline which particularly distinguishes it from other types of editors.

The command to search and replace is similar to the syntax you would use in vi.
Let’s say you have a file database.sql and want to replace every occurence of to You would use the following sed command:

$ sed -i 's/' database.sql

By executing this command sed will go through your file, searching and replacing every occurence of within moments. In my case, on files of 18MB and 32MB, the search and replace took under a second. But will take just moments on files much bigger than that.
Since sed is a command line tool and accepts all kinds of input, be it streamed or piped, it is a tool that is suited for a lot of different use cases.

Sed is probably good for a lot more than just search and replace. But i’ll have to look more into it to write something meaningful about it. If you want to read more about sed or check out the slides of the presentation “Sed & Awk – The dynamic duo” by Joshua Thijssen.

Oh by the way, as i mentioned sed is a linux/unix tool, but also seems to be available for Windows. It’s probably included in Mac OS distributions as well.

Anticipating for change with the Strategy-pattern

We developers get to deal with change nearly every day. As your project progresses, stories or requirements are changed or added. And we’ve all been to the point where our code gets brittle or unmaintainable after too many changes and/or additions.

Let’s start with a metaphor. Let’s say your keyboard is broken and you need a new one. Luckily the keyboard is connected via a USB-connector to your computer, so you can replace it with another keyboard with ease.
But what if there wasn’t a common interface (USB) to connect your keyboard to a computer, for example if it was directly connected to the computer?
Indeed, you would either get an entire new computer or you’d be soldering your new keyboard onto your computer. None of which are ideal solutions to the problem.

This metaphor applies to programming in many ways, but arguably the most important principle that comes from this example is that you should program to an interface where possible.

In a lot of cases programming to an interface encourages the interchangeability of certain parts of your application. Thus it enables you to write flexible code, and anticipate for changes in domain logic.

If you’ve ever written or worked with an online shop you might have come a cross the problem that different countries have different tax rates. Each country has their own tax rate, which of course can change independently. When implementing an online shop, this problem cries out for a flexible solution, and you need to think of a durable strategy to solve this problem.

Diagram 1 - Different implementations of TaxInterface

A good way to do this is to look for commonalities of the different calculations. It is not hard to see that every tax calculation has nothing more than an in- and output number. As long as the tax is calculated correctly, the calculation itself is not really important to the system.
These commonalities are the things you define in the interface, in this case we’ll call the method calculateTax. By programming each country-specific implementation to the interface (TaxInterface) the Order does not need to know (or worry) about the outcome of TaxInterface::calculateTax(). The only thing that it needs to do is instantiate the approperiate implementation, which is out of the scope of this post.

See Diagram 1 for a clarification.

This solution is defined as the “Strategy pattern”, and it is about anticipating on (potential) change of features. In the example it is fairly easy to add a tax implementation for another country, while you have to make only small changes to your existing code.

I hope this example demonstrated the reason behind programming to an interface and and the purpose of the Strategy-pattern in a fairly simple manner.

“I rest my case”

So there it was tonight. Some criticism on my talk/slides called “Let’s live inside the browser”. In a tweet Ivo Jansch, a well known and respected person in the PHP community, expressed how the lack of cross-browser compatibility of my slides proves why “living in the browser” is not gonna happen. Or well, that’s more or less what i think his tweet implies.
In this specific case i think the reasoning is unjustified as i didn’t program mouse control, although that’s a good idea! But of course it’s ironic that my presentation about living inside the browser lacks support for convenient input (you have to use the keyboard left/right arrows).

Anyway, this is a discussion i was hoping to start with my presentation. The discussion about if and how we will end up living inside the browser. And for obvious reasons the native vs. web apps thing is a big part of the discussion.
I have already posted my thoughts on why i think the web is suitable as an application platform a couple of days ago, but i feel that post is not comprehensive enough, so i’ll add some more thoughts.

Web apps vs. native apps
This is an interesting one. If you’re thinking mobile then, as for now, native apps win in terms of functionality and possibly user experience. Simple.

However i don’t think that the web as an application platform becoming more common will rule out native applications per se. Maybe eventually, but that takes years, maybe even decades. If it is at all.

Choosing the web as an application platform is choosing for an easy way to deliver to every device with a browser, instead of limiting to a certain vendor.
However if you choose web, you limit yourself to the use of API’s available through the browser or web services. This is a limitation that should not be underestimated, and is where native applications win big time

Of course, there are these hybrid solutions like the awesome PhoneGap. These enable you to write applications using web standards, and abstract the device specific API’s so you can still develop for cross-platform solutions, but deploy to multiple ones.
I guess this is okay solution, but it shows there’s still lots of work to do regarding web standards. And even then, web standards will always be behind the features “native” API’s provide.

Other concerns
Without a doubt, choosing between the web or native platform for a project is also dependent on the business model behind of your project.
I’d say the web provides more freedom for implementations, which encourages innovation. On the other side, native platforms, and especially mobile platforms have built-in mechanisms to monetize through your application.

Another big thing is the capability difference between desktop and mobile browsers. Mobile browsers, and especially the Android browser are lacking (draft) standard support already, which slow the large adoption of the web as an application platform. But although the mobile browsers seem to be behind on functionality, web developers have always been inventive in finding work-arounds for these issues.

So.. the web huh?
Yeah, i still believe there is a big future for the web as an application platform. And even though native apps are really powerful, the reach of applications is obviously a lot bigger.
With the web standards always in development the web will slowly become more and more suitable for deploying and distributing applications.

Although i feel this post is still not comprehensive enough, i hope i expressed my point of view of this topic.

In the end of the discussion Ivo mentioned the idea of a “web vs native bar fight” with presentations with the standpoints of each camp.
While this sounds like a whole lot fun (i’m definitely up for it!), i’m feeling more for an open discussion with the aim to share thoughts. It’s an interesting but also really important topic to share thoughts on. Preferably with people from different backgrounds.

Anyone want to help set up a meeting for it? I’m not so familiar with it..

How HTML5 Web Workers make unicorns run

A unicornOne of the things that HTML5 brings us is Web Workers. These things are great for enhancing user experience in webapplications or javascripts that contain heavy computations or other sort of long running scripts.

Web Workers are like threads, which you might know from other development platforms. The definition of threading is the following according to Wikipedia:

“The threaded programming model provides developers with a useful abstraction of concurrent execution.”

Let’s start with identifying the problem.
For the working example for this post, check out this page and hit the ‘Freeze’ button. Under this freeze button there is a function that does a huge secret calculation that is supposed to use a lot of your CPU’s time. Actually it’s not that secret, see code sample 1 for the code. Notice that the unicorn stops moving for a while when you press that button. The freeze function is freezing the UI while executing. (Thank you Captain Obvious). See diagram 1.

// Code sample 1 - Secret freeze function
function freeze() {
    var total = 0;
    for (var i = 0; i < 100000; i++)
        for (var k = 0; k < 20000; k++) total++;
    return total;

Diagram 1 - Single threaded script execution

Obviously, this causes the user to wait, and that’s bad practice. Nobody likes to wait.
Web Workers enable you to start another thread that can process computations parallel to the browser’s so-called UI thread. (That executes your “normal” javascript)
With the result of not blocking the user interface.
Simply put; you delegate your heavy computations to another process, which, when ready, will send the result back to your UI thread. This is visualized in diagram 2.

Diagram 2 - Multi threaded script execution

Delegating the long running function to another thread leaves computing space in the UI thread open for other computations. UI computations of course, as it is the UI thread.
Doing this is actually quite simple, and requires to put your code in a new javascript file that will  execute in the worker’s context. Running a script in the worker context means that the script does not have access to the DOM or anything else that is not thread-safe.

Exchanging data between the UI and Worker is being done by the Worker.postMessage method. This method requires one parameter, the data you want to send.
This data is internally serialized as JSON by most browsers to prevent callbacks or other pointers being passed (which would potentially cause cross thread errors). (source)
Code example 2 demonstrates how to create a worker in javascript, and code example 3 demonstrates how the worker script itself should be defined. Notice that event handlers/callbacks are used to start and communicate between the Worker and the UI thread.

// Code example 2 - Creating the Worker and listen to onmessage
var worker = new Worker('webworker.js');
worker.addEventListener('message', function (event) {
    document.getElementById('calculation').textContent =;
}, false);
// Code example 3 - webworker.js
self.addEventListener('message', function(event) {
    var total = 0;
    for (var i = 0; i < 100000; i++) {
        for (var k = 0; k < 30000; k++) {
}, false);

Inside webworker.js, the self keyword is used to approach the Worker’s API. In here you also see that we add a listener to the onmessage event, and use the Worker.postMessage method to send the output back to the UI thread.
You can start the worker from the UI thread (your normal HTML page or javascript) by using the Worker.postMessage method, as seen in code example 4.

// Code example 4 - Starting the worker
var worker = new Worker('webworker.js');
worker.addEventListener('message', function (event) {
    document.getElementById('calculation').textContent =;
}, false);

worker.postMessage(null); // postMessage parameter accepts everything that’s serializable.

Obviously, you don’t want to stop a unicorn from running across your screen. So if you delegate the freeze function to a Web Worker, you get the result as in diagram 3.

Diagram 3 - Delegate the big calculation to another thread/worker, so the unicorn can keep running

Now click the “Via worker” button in the working example page.
Yay awesome, the unicorn can continue to run across your screen in the meantime! So yes, that’s what Web Workers are good for, making unicorns run across your screen.

No but seriously, i couldn’t think of a more interesting use-case.. But you can fill in your own use-case for a long running function that causes the UI thread to block.

Of course, you want to know in which browsers Web Workers are supported. Fortunately, on desktop browsers the Web Workers are widely supported (although, IE10+). A bit less fortunate is the support on mobile browsers, with the exception of Opera Mobile 11 no mobile browser supports Web Workers. For a comprehensive overview of supported browsers, take a look at the MDN page “Using web workers”.

A more in-depth explanation of HTML5 Web Workers can be found at the HTML5 Rocks website.

Why i think the web as a platform is the future

Lately i have found myself thinking about why applications built on web standards are becoming more and more common. What is it that draws us all to this amazing place called the web? And why are more and more companies investing in applications based on web standards?
Personally i am really enthusiastic about the direction the “applicationscape” is heading and i  think web applications have the potential to go a (really) long way.

But seriously, why?

I think the answer lies in how people consume information. It seems we have this (subconcious?) urge to find and use information as effective as possible. And the technology of today has brought us to the point that we want this information anywhere, and we want it NOW.

There are a lot of ways to consume information in modern (internet) times: PC’s, laptops, tablets, smartphones and what not. Each of them having their own vendors and platforms but they also have their own distinctive level of speed, mobility and have different input mechanisms. Each device is used different.
However, important to note is that all these devices serve the same purpose: to serve information.

There is an important thing that, nowadays, all of these devices have in common, and that is that they have a web browser. So all of these devices have access to the web.
That is what makes the web so interesting as a platform. The reach is enormous.
Online, offline, anywhere and any time, on any device. The world wide web is a shared platform across devices already. Regardless of operating system.

An important downside of developing applications for multiple platforms is that it is time consuming. Another downside is that, for various reasons, the different applications you end up with do not always contain the same functionality. Now i can see sometimes this is because the project is on a time constraint, but an often heard reason is that to offer users of different devices the best user experience.
Now there is a big difference between offering a different user experience based on certain context parameters and designing an different application for each platform possibly limiting users access to certain functionality of your original product.

Now this is where i think the web as a platform has it’s potential and can offer more for both end-users and developers. Of course, web applications do not offer the same functionality as native applications at this time, but i think this is a matter of time. The open web standards have become really mature at present time, and i think it is time that we start embracing the web as a platform.

And what about you? I would love to hear your thoughts about the web as a platform in the comments and get some discussion going around this…

On September 17th i am speaking at the PFcongres (in dutch) about the web as a platform and what technologies you can use today to develop for it as such. If you are interested in this topic, or even if you are not (the other speakers on schedule cover amazing subjects!!) PFcongres is the place to be in Utrecht this saturday!