Charles is my superhero!

As a true geek I am a big fan of several superheroes. Actually, Iron Man is by far my favourite one. Or actually, the coolest part about Iron Man is J.A.R.V.I.S. if you ask me. The Just A Rather Very Intelligent System, is a clever system that assists Tony Stark in virtually everything that he considers “everyday tasks”.

Unfortonately I do not embody a superhero, but I do have several tools that assist me with my everyday tasks, and one of these tools is Charles Proxy.
Like my IDE helps me with being productive in writing, testing and troubleshooting code, Charles Web Debugging Proxy helps me with most of the things that are related to HTTP. And as a web developer, you know, that’s a lot. Here are some of the most significant contributions of Charles in my everyday work.

Communication insight

Specifically when developing APIs, a lot of communication is happening “under water”. A website does a request to an API, or a mobile device calls some webservices, and you want to know what’s going on. As with most proxies, Charles can show the HTTP-client requests. What’s connecting when, to where, and with what headers, cookies, request/response bodies etc.

Request tampering

Screen Shot 2013-07-25 at 20.34.59By setting a breakpoint on a specific request, you can modify the entire HTTP request the client is sending to the server. Change headers, cookies, request bodies, query parameters. In short, everything that you need to troubleshoot most common HTTP-related issues. Activate this in the context menu of a specific request -> Breakpoints, and the next time your client requests this URL, charles will break on the request.

Give colleagues and devices access to your dev environment

Another very convenient feature is that if you set your proxy server as a system-wide proxy on let’s say, your mobile device or colleagues’ machine, that they can see everything web-accessible on the machine you’re running Charles on.
So in practice, it means that you can check out your application that’s running on let’s say, a host-only connected virtual machine. This is something that we use a lot here in the office. Pretty neat, huh?

But there’s more…

Actually, the list above is just the tip of the iceberg of Charles’ features. There are a lot more features in the application, like: Bandwidth throttling, Request filtering, Recording/Replaying and saving sessions, DNS spoofing, SSL proxying, and there’s still more.

So, why a blog about Charles’ features while I could also visit it’s website?

Well, if you’ve read this far, I’ve got your attention. And that’s exactly what I was after. My goal with this post is to show that there’s a tool that can help you with things that can be very cumbersome without a proxy. And more! Charles is just great, and every web developer should at least know about it’s existence.

Of course, Charles is not the only Proxy program out there, and probably there are tools that have more or less the same features. If you know such a tool, could you let me know in the comments?
Oh, and Charles runs on virtually every desktop platform!

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.

“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!

Javascript beyond the browser

As a web developer, i am using javascript on a daily basis.
I use it to manipulate elements in the DOM, set css properties, animate objects, interact with user elements, etc. etc.
Now i can’t say that i’m a true javascript ninja, but let’s say javascript and i get along pretty well. I like writing javascript; it’s a flexible, easy to write language, and there are some excellent frameworks that makes life a whole lot easier. Especially when writing cross-browser compatible code.

All the above mentioned usage of javascript is from within the browser, on the client side.
About a couple of weeks, click-happy as i am with links on Twitter i stumbled upon this talk about Node.JS by Ryan Dahl on Ontwik (great website for technical screencasts!).

Now the first thing that got my attention was that Ryan was visibly nervous, and i wanted to see how he made it through the hour. But soon the contents of this talk became my main point of attention. It’s very interesting how Node.JS’ approach to I/O operations leads to high scalability in terms of concurrent users. Now if you are interested in Node.JS specifically, i would suggest viewing this talk, and i’m not going into details in this post.
(Although Node.JS is on my “things to write about” list)

A week or two after that, i was experimenting with PhoneGap, an “Open Source framework for building cross-platform mobile apps”. PhoneGap enables a developer to create mobile apps (for iOS, Android, Symbian, Windows Mobile, BlackBerry and Palm) using HTML, CSS and javascript.
Now the best thing is you can still use platform specific core features like camera, contacts, geolocation or network.

After playing around a bit i got this great idea about using my laptop’s browser, a Phonegap app and a Node.JS server app to link up my mobile phone with my laptop. This enables real-time interaction between the two (or three, or four, or five)!! Now how awesome is that?!

First off an Android app with PhoneGap would send data from the phone’s accelerometer using ajax (but streams are excellent for this purpose aswell) to a Node.JS server application.
The Node.JS app would then broadcast it to all browser clients,  who will then *do stuff* with the data received from the phone.
Eventually i got this communication between my mobile phone, server app and browser running in real-time, which is what it was all about. Pretty awesome!

Now both of these (at least to me) ‘new’ technologies put javascript in a whole different perspective for me. I already knew the javascript language, but didn’t realize it has a lot more potential than just manipulating the DOM.

The use of javascript outside the browser has been a trending topic for quite some time now, but i’ve always been a bit in doubt of how this would be a good addition to our current stack of of tools, and how it would make a developer’s life easier.
Node.JS and PhoneGap proved to be very easy to use, and opened a new perspective of interaction to me.

If you know how to write javascript, don’t limit yourself to the browser!