Timing errors with Angular Protractor e2e testing

I had this nasty error in my Protractor tests:

Error while waiting for Protractor to sync with the page: {}

My tests were kicked off too early and didn’t seem to wait for the angular library to load.

I added the following solution to my specs, but was far from confident, because other timing issues arised:

// Don't do this!
browser.ignoreSynchronization = true;

With help of Angular-contributor Shyam Seshadri I found out that the issue had it’s origin in my protractor config file!

By default Protractor assumes that the ng-app declaration sits on the BODY-element. However, in my case it was defined on a DIV lower in the DOM. I had to assign the selector of that element to the rootElement property:

  // rootElement: 'body', // default, but does not work in my case
  rootElement: '.my-app', // or whatever selector the ng-app element has

Corresponding HTML:

<div ng-app="myApp" class="my-app">

Happy testing!

Run both Grunt and Codeception in a Laravel project

In my Laravel project I use Grunt for testing and building client-side code and Codeception to run my acceptance tests. It might be possible to trigger Grunt from Codeception, but I don’t know how. However, to run Codeception from Grunt you should just install the grunt-shell plugin and add the following lines to your Gruntfile.js:

shell: {
  codeCeption: {
    options: {
      stdout: true
    command: 'php codecept.phar run'


Don’t FTP the Git Shit

I didn’t even realize I was pushing all my (uncountable) git directories when FTP’ing. But Filezilla appears not to have a default filter for git directories. Luckily it’s easy to create one:

In Filezilla 3.5.3 go to View > Filename filters… and add a filter with the following settings:


Done, happy FTP’ing!

A front-end build with Grunt 0.4

Update February 22, 2013:
Grunt 0.4 is officially released. Please take that into account when following the instructions below.

grunt-logoAddy Osmani’s talk on the developer toolbelt at Fronteers 2012 inspired me to have a closer look at Grunt. Especially for front-end or JavaScript driven projects, Grunt looks like a promising alternative to the Ant or Maven build systems.

Note: this is not a tutorial on Grunt or build systems in general. If you’re new to building read the Grunt introduction on Nettuts. This article aims to overcome the pitfalls when setting up a build with Grunt 0.4. Grunt version 0.4 differs a lot from 0.3, but unfortunately both the Grunt documentation as well as a lot of plugin documentation have shortcomings regarding which Grunt version is supported.

Continue reading

HTML5 JavaScript APIs to be used in mobile environments

At the moment I’m attending the online course Mobile Web 2: Applications at W3 Tech courses. This post is a summary of the fourth week’s subject JavaScript APIs. (Please note: this is not a thorough objective summary of the course, but just the highlights that I found important for myself to remember.)


A simple example:

 if (navigator.geolocation) {
              function (pos) {
              function (err) {
                  $("#status").text("ERROR: " + err.message);

Continue reading

Basics of Mobile Web Development

At the moment I’m attending the online course Mobile Web 2: Applications at W3 Tech courses. This post is a summary of the second week’s subject Basics of Mobile Web Development. (Please note: this is not a thorough objective summary of the course, but just the highlights that I found important for myself to remember.)

  1. The way to address scaling issues on a mobile device is to use the meta viewport element.
    <meta name="viewport" content="width=device-width"/>

    More info: An introduction to meta viewport and @viewport (dev.opera).

  2. CSS Media Queries is a way of applying specific CSS styles depending on a number of properties of the target device. Typical properties include whether it is rendered on screen or in print, the orientation of the device, its resolution or colordepth, and many other such aspects (called “media features”). Examples:
    @media screen and(max-width:959px){     /* CSS rules to apply specifically when the above is true */}
    <linkrel='stylesheet'href='style.css'type='text/css'media='all and (min-width: 960px)'/>
  3. When writing web sites that target both mobile and desktop, it is usually a better idea to write the core style sheet in a manner that works for mobile devices, and then use media queries to render the same page on larger screens, “mobile first”. This concept can be taken further by starting to design for the “dumbest” phone.
  4. How to test for native JSON:

    if ("JSON" in window) {
        // code that depends on native JSON being available

    Or, with a polyfill:

    <script>"JSON" in window || document.write('<script src="json2.js"><\/script>')</script>

  5. In a mobile context, use opacity sparingly.
  6. Xui has the advantage over Zepto that it’s fully portable to all known browsers, while Zepto tends to be Webkit focused.

Mentioned resources:

To GZIP or not to GZIP

When the question to GZIP or not to GZIP is raised I’m sometimes asked if the cost (in time and battery usage) of decompressing data on the client is balanced against the gains in transport efficiency. “Yes, I assume it is, otherwise why would Yahoo propagate it?”, was mostly my answer.

I was pleased to see that the W3C gives a more thorough answer to this question in it’s section on Mobile Web Application Best Practices:

Web servers should be configured to serve appropriately compressed responses. However:

  • Most image formats (especially JPEGs) do not benefit from compression, but SVG does;
  • Most other media formats (e.g. audio, video) do not benefit from compression;
  • Very small files (e.g. <1k) generally do not benefit from compression.