RND Websites

Debugging Mocha tests in WebStorm

Ron — Thu, 03 May 2012 06:19:50 +0000

I’m a recent convert to the WebStorm IDE and for Node development especially, the debugger is a godsent. No longer do I need to add console.log statements to my code to figure out what’s going on, I can just set a breakpoint and go from there. Simply awesome! However, I wasn’t able to do this for Mocha test scripts. I tried these instructions that I found, but that didn’t work for me.

When I came across a post on Stack Overflow asking if Mocha could be used as a Node.JS module, I immediately figured out the solution. Create a Node.js script, include Mocha as a module and start the tests like that. Using the Mocha JS API, this was a simple task.

var Mocha = require('mocha'),
	path = require('path'),
	fs = require('fs');

var mocha = new Mocha({
	reporter: 'dot',
	ui: 'bdd',
	timeout: 999999
});

var testDir = './test/';

fs.readdir(testDir, function (err, files) {
	if (err) {
		console.log(err);
		return;
	}
	files.forEach(function (file) {
		if (path.extname(file) === '.js') {
			console.log('adding test file: %s', file);
			mocha.addFile(testDir + file);
		}
	});

	var runner = mocha.run(function () {
		console.log('finished');
	});

	runner.on('pass', function (test) {
		console.log('... %s passed', test.title);
	});

	runner.on('fail', function (test) {
		console.log('... %s failed', test.title);
	});
});

The only problem is the Mocha timeout setting. When you’re debugging, the timer will continue to run, so by the time you are done debugging, the timeout will have fired. Of course, this can be solved by setting the timeout value to a sufficiently high value for debugging. Running the tests can actually be done more easily by invoking mocha from the command line.

How to use Mocha.js to unit test YUI

Ron — Thu, 26 Apr 2012 19:11:21 +0000

We’ve recently started using YUI as the basis for a new version of our product. It’s a very solid library, which provides a lot of high quality code. And although YUI has a nice testing framework as well, we wanted to use Mocha.js, so we could run tests continuously. At first, it was unclear how to integrate YUI into Mocha tests, but in the end the solution was very simple:

var path = require("path"),
    YUI = require("yui3").YUI,
    chai = require("chai"),
    expect = chai.expect;

(function () {
    describe("MyModule", function () {
        var Y, myModule;

        before(function (done) {
            Y = YUI({
                modules: {
                    'mymodule': {
                        fullpath: path.join(__dirname, '../modules/mymodule.js')
                    }
                }
            }).use(['base','mymodule'], function () {
                done();
            });
        });

        beforeEach(function (done) {
            myModule = new Y.MyModule();
            done();
        });

        it('should instantiate the MyModule class', function (done) {
            expect(myModule).to.be.a('object');
            done();
        });

        it('should have a title', function (done) {
            myModule.set('title', 'test');
            expect(myModule.get('title')).to.be.equal('test');
            done();
        });

        it('should have a description', function (done) {
            myModule.set('description', 'test description');
            expect(myModule.get('description')).to.be.equal('test description');
            done();
        });
    });
})();

The trick is to use the ‘before’ method of Mocha.js to create a YUI sandbox and assign that to a variable that is in the larger scope, so it can be accessed in the other classes. To make sure everything has loaded, the ‘before’ method’s ‘done()’ call should be done inside the callback function of YUI’s use method.
And finally, the required YUI modules for custom modules aren’t loaded properly, unless they are mentioned in the use method’s first parameter.

Questions? Ping me on Twitter!

Robbed

Ron — Sun, 08 Apr 2012 08:28:52 +0000

Two nights ago, we were rudely awakened by loud noises coming from downstairs. I immediately knew what was happening: someone was breaking into our house, probably to grab our iMac. By the time I got to the room the bastards were gone, leaving broken glass all over the room. They smashed a window, probably using a sledgehammer. The window was doubleglazed, and the outside pane was almost a centimeter thick. It took them at least five swings to break the glass. But within a few minutes they were through, managed to grab the computer and drive off on their scooter.

We immediately called the police and they responded quickly, sending units to search for the scum that stole our computer. Sadly, but not unexpected, they didn’t find anyone. The police arrived 10-15 minutes later at the house and did their best to calm us down and get our statement. Our neighbours also came out right after it happened. Considering we all just moved here and haven’t really got to know each other, I was very grateful that they were there for us. One neighbour actually saw the direction they took off in, but it didn’t help in the recovery of our computer.

The day after, I just went to work as if nothing happened, but all day I had a knot in my stomach. Luckily, work was a good distraction. That night we had already planned to go out, so we did that, again as if nothing happened. But in the back of my head, the memory still lingered. The exhaustion kicked in when we got home and both of us had a pretty good night’s sleep.

Yesterday, I finally managed to get a good look at the room and the broken glass everywhere. Perhaps foolishly, I let it sink in, because I wanted to trigger the feelings that were slumbering inside. The most prevalent feeling was anger. I’m so mad that someone took a sledgehammer to our house, smashed our window and grabbed our computer that held a lot of personal stuff, like the original photos from the birth of our little girl (luckily we had the best pictures backed up on the net). Last night, I woke up around the same time as the break in happened. I lay awake for an hour, thinking of all the things I would’ve done if I had managed to get down there in time. All the time I felt that knot in my stomach grow bigger. I can still feel it now. I want to get rid of it, I want to get past this and feel safe and happy in my home again. I won’t let those bastards make me feel like a victim, like I somehow deserved what happened. They had no right, whatever they might think about that themselves. I live in a terrific country, where no one has to steal to survive. It’s pure, unadulterated envy that made them do what they did. They saw something they wanted to have, and instead of working for it and earning the money to buy it, they had to invade my home to get mine.

Next week, our window will be fixed, all the broken glass will be removed and hopefully, the room will look like nothing happened, so we can move past this. I hope that whoever did this, will, at some point, be held accountable and be punished for their evil. In the meantime, I will overcome my fear and move on with my life.

Fronteers 2011 – The videos

Ron — Tue, 18 Oct 2011 10:36:30 +0000

All the presentations at Fronteers 2011 have been recorded, and the first presentation (The Future is Native by Aral Balkan) has now been uploaded to vimeo, the other talks will follow soon. View the presentation below:

Aral Balkan | The Future is Native | Fronteers 2011 from Fronteers on Vimeo.

All videos will appear on this page at a later time:
http://vimeo.com/channels/fronteers11#30659519

Fronteers 2011 Day 2 – more thoughts

Ron — Mon, 10 Oct 2011 18:05:34 +0000

The second day promised to match the quality and depth of the talks on the first day and it totally fulfilled that promise. Although it started off a bit rocky for me, because I arrived about 20 minutes late for the first presentation, I still managed to get the most important information out of it. So let’s go through the various talks.

Web Components and Model Driven Views – Alex Russell

Alex Russell works at Google on improving the open web and building Chrome Frame, the IE plugin that allows Chrome to take over the rendering (basically). He started off the second day of the conference with the current state of browsers in the world and from there moved on to some new features that are coming to the latest browsers soon: web components. Alex built it up slowly, starting of with scoped CSS. Simply put, this allows you to style an element by including a style tag within the element containing the CSS rules for it. It’s already available in some browsers, I think (maybe only in nightly builds). He then followed up with HTML component templates, which do what it says on the tin: you write a block of HTML, insert some scoped CSS, wrap it in a template tag and you’re done. Then you can use JavaScript to link in some data which controls how often the template is rendered.

At Informaat we’re building something with similar features, but that could become much easier using these innovations. Although I don’t see a use for this in a regular website, it will be much easier to build a web app. For instance, if you need a login box, you can make it into a web component and make it very easily reusable. I’m interested to hear and read more about this, but I’ll have to look at Alex’s presentation again when the video is up on the Fronteers website.

The New Developer Workflow – Divya Manian

Following up after the break was Opera’s Divya Manian, talking about the new developer workflow. She was a big fan of SASS/Compass, which are CSS preprocessors. They allow you to use mixins, variables and functions within a CSS-like syntax. This code is then run through a tool that converts it all to CSS. Another one of her points was the fact that Photoshop mockups don’t account for things like interaction, impatient users and the general complexity of the web. This makes it hard to build a site based on nothing more than a few Photoshop files.

She then moved on to the 2012 workflow for a developer:

Get to know your developer tools, use the browser to see where you are heading.
Make use of Version Control Systems to go through iterations of the project. Divya advised to get to know Hg or Git.
Make design choices based on the supported feature set. The web ecosystem is much larger nowadays, when you decide to use a certain new feature, you need to figure out what to with browsers that don’t support (fully).
Have a policy on when to use polyfills. Polyfills are usually for the older browsers, like IE7/8, that don’t have very capable JavaScript engines. This means that if you put in too many polyfills, these browsers will grind to a halt. She mentions several polyfills that are bad to use, because of performance.
Vendor prefixes are a necessary evil, you can use prefixr to generate the needed code.
Use preprocessors. They make life much easier when working with complex CSS. Also keep in mind the lifecycle of W3C specs. Once they turn into Candidate Recommendations, the browser vendors will start to accept prefix-less properties.
Build scripts also help to make life easier and optimize stuff for deployment.

HTML5 Forms KISS time – Robert Nyman

Mozilla’s Robert Nyman is one of my personal favourite speakers, because he comes across like a regular developer. Don’t get me wrong, he’s good at what he does, but he doesn’t make me feel like I’ve just started . At Fronteers 2011 he spoke about HTML5 form elements and his talk basically proved that although it is possible to use them in production, you will need to explain to your client or boss that websites don’t have to look the same in every browser. The implentations for certain aspects (like error messages) vary wildly between browsers, as do the styling capabilities. It is being worked on and with the current release rate of chrome and firefox, it should improve in those browsers pretty soon.

After a short introduction, he started with a summary of the new input types. These are mostly useful for mobile browsers (read: iPhone and Android) as they support various input methods for specific fields (e.g. a date picker for an field). Next up were the various new attributes, e.g formaction, formenctype, formmethod, formnovalidate and formtarget on submit buttons. Robert showed a slide with these last attributes on an , but they will work on the

Fronteers conference 2011 Day 1 – my thoughts

Ron — Fri, 07 Oct 2011 21:59:15 +0000

The past two days, I’ve been at the Fronteers 2011 conference. Fronteers is the Dutch trade union for front end developers and this is the fifth year they’ve organized this conference. Last year was the first time I went to the conference, which was okay. This year’s conference, however, was very much worth the time and money spent.

The Future is Native – Aral Balkan

The conference started with a great talk by Aral Balkan titled “The Future is Native”. Of course, that’s a pretty daring title at a web conference, considering the whole “web vs. native” debate. Being a web developer, I had to disagree with his presentation title, but as it turned out, it didn’t cover the whole talk. He started off with how we are basically cyborgs; we use all kinds of technology to extend our physical capabilities. A simple watch enables us to tell the time exactly, a smartphone allows us to communicate with people around the globe, etc. One of these extensions is the web, however, it is limited due to the fact that it’s separated from the OS by the browser. This hinders the user experience, as it stops web apps from doing everything a native app can do. The web also has a few advantages over native, however.
Firstly, web apps don’t have to be installed. You can just go to a URL and you’re good to go. Native is catching up with this with app stores.
Secondly, the web is universally accessible (e.g. from anywhere on any device). This will always be difficult for a native app.
Finally, it’s easy for a web application to always have up-to-date data, a native app will have to set up some sort of sync. The concept of “always connected” is still a pipe dream.

After this comparison, Aral bridged over to the importance of the user experience. He goes on how we build things for other people to use, that means that the user experience is more important than our needs as developers. This is what makes UX design extremely difficult. If you first take away non-verbal communication, then take away spoken communication, you are making it very hard for humans to communicate. Now imagine how hard it is for machines and humans to communicate: that is what UX design is about.

The presentation is finished off with the explanation that good UX design makes a user feel superhuman. The example Aral shows is a comparison between an airplane ticket machine in Sweden and in Norway. The Swedish version requires a lot of user actions, and includes many instructions on what to do and even a phone to call someone for help. The Norwegian version only requires you to swipe your credit card. It makes your life easier, not harder. That is what good UX design is all about.

I liked Aral’s presentation style and at first his talk was a bit too conceptual for me personally. After letting it sink in for a while, I could pick out more and more useful bits.

Accessibility for the modern web – Derek Featherstone

Before I discuss this presentation, I have to admit that accessibility for me is a not just an elephant in the room, but a whole herd of elephants in the room. I know it’s important, but somehow I never get around to applying it or researching how to do it. To all disabled people that surf the web, I therefore apologize. So on to the talk by Derek Featherstone. Derek showed off several techniques to improve existing websites through Greasemonkey scripts. For example, making Google Maps more accessible by adding an interface that uses actual HTML buttons. This allows tools for disabled people to create an interface for their users by binding spoken commands to these buttons.

He then went on to show some examples of code that was totally inaccessible. The example that stuck in my mind were some checkboxes on Amazon.com, that actually weren’t checkboxes, but a whole bunch of tags that were styled to look like checkboxes. This made it impossible for screen readers to recognize them.

As I said, accessibility is the elephant in the room for me, but I’m not alone. Derek’s examples show that it happens on many sites, even those made by large companies that made their name on the web. I do see the importance of it, so I should make some time available to learn about this.

CSS3 Secrets: 10 things you might not know about CSS3 – Lea Verou

The next talk was by Lea Verou, one of the rising stars within our trade. I went to the workshop she gave the day before the conference (which was excellent), so this talk was more or less a summary of that day for me. The ten secrets are:

Advanced transition functions with the cubic-bezier() function
Lea kicked off with showing us her web tool for making cubic-bezier curves that can be used in CSS3 transitions to control the easing of the animation.
Border-radius: using percentage values to make scalable circles and ellipses
Everyone by now has played with border-radiuses, but no one has played with them like Lea has. She did a lot of research to see how this property can be used. One of her conclusions was that to make scalable ellipses you shouldn’t use pixel values, but percentages for the horizontal and vertical radii.
Achieve multiple outlines on a box by using multiple shadows and the spread parameter
The box-shadow property is usually used with three pixel parameters and a colour value. However, it allows a fourth value that controls the spread of the shadow. By using this value, it is possible to create multiple “borders” around a box.
Making pointer events pass through overlaying elements by adding pointer-events: none;
Setting the pointer-event property to none allows the browser to allow clicks on an element to syphon through to underlying elements. This can be used to make nicer select fields, for example, by overlaying the arrow button with an image. However, several people on Twitter noted that it’s also a risky CSS property, as it makes it easier to create a clickjacking hack.
Adjusting tab size for code display with tab-size: 4
This may or may not be very useful for many websites, but if you write about code often and use tabs to indent that code (which, of course, is the only correct way), you can adjust the tab size with this property.
Doing cool stuff with :nth-child, :nth-last-child and :first-child pseudoselector to select elements with a certain amount of siblings.
On their own, these pseudoselectors are relatively straightforward to use. However, if you combine them, it’s possible to create a selector that targets all matching elements, if the total number is larger than a certain amount. If I recall correctly, it was something like this:
:first-child:nth-last-child(n+2), :first-child:nth-last-child(n+2) ~ b
Styling checkboxes and radiobuttons with the :focus and :checked pseudos
I forgot how she did this exactly, but luckily, her slides are online. So, what she does is this: first, she hides the checkbox. Then she adds some generated content (e.g. an icon), and finally using the focus and checked pseudoselectors, she changes the text color on that generated content.
Use new CSS3 mouse cursors like cursor: none; (in games for instance) or cursor: not-allowed;
There are a lot of new CSS3 mouse cursors. She lists them all in her slides and I’m sure they might come in handy at some point. cursor: row-resize and cursor: col-resize sound pretty useful for manipulating tables, for example.
Create background patterns with CSS3 gradients (check out her pattern library too)
This is probably the most awesome secret she shared. These gradients can be used to create some wild patterns, and I’m very impressed with some of the patterns she managed to create.
Position your background by using background-origin
The last secret explains how the background can be aligned on the content-box, so that when you change the padding on the containing element, the background will reposition itself so it stays within the padding. Could be useful.

Well, what can I add to this? The presentation was very well executed. Lea has created her own presentation framework in HTML/CSS/JS that allows her to do live coding from within her slides, manipulating elements on those slides. It makes the whole thing feel very magical.

HTML5 Semantics: you too can be a bedwetting antfucker – Bruce Lawson

After an excellent lunch, it was up to Bruce Lawson to keep us all from falling asleep, and I can say he managed that perfectly. The thing that everyone will remember about this presentation is use of a mankini to explain the difference between the section and article elements (basically, a section can be cut up in pieces, while an article is a single entity, much like said mankini). But that was halfway through his talk, let’s not get ahead of ourselves!

Bruce started off, after some silliness about a certain Dutch word, with the elements that have been kicked out of the HTML spec in its latest incarnation. Things like

, and and some attributes on other elements. Basically nothing that any sane front end developer still uses. He then went on to mention the sexy new elements, like , and

30 days

Ron — Sun, 25 Sep 2011 19:35:17 +0000

A few days ago, I watched the TED presentation by Matt Cutts where he explains how he changed things in his life by trying out new things for thirty days. Towards the end of his presentation he also admits that it doesn’t always work, like when he tried to go thirty days without sugar. However, I think that the essence of his story might work for me. I usually set enormous goals for myself and then never start them, because I decide upfront that there’s no way I can achieve said goals.

One of those things is improving my JavaScript and general programming skills. I try to keep up with new developments, but I hardly ever sit down and play around with code, unless my day job requires it. Of course, my life has changed enormously after the birth of my daughter and it’s been a very tiring few months. But that is quieting down now, so I feel this is a good time to start this experiment.

So what am I going to do? For the next thirty days (starting tomorrow, Monday 26th), I’m going to spend at least two nights a week on improving my skills, instead of improving being a couch potato. Because my kid usually doesn’t sleep before 8pm, and I need to get some sleep as well, a night will consist of two to three hours. So, let’s see how it went on October, 26th!

Recreating a C64 game

Ron — Thu, 24 Mar 2011 22:07:51 +0000

To challenge myself as JavaScript programmer and to learn new things, I’ve decided to try and rebuild a Commodore 64 educational game called “Topography Netherlands”. I couldn’t find a C64 video of it, but this MSX version is basically the same. The idea is that the game gives you a name of a Dutch city and you need to fly there as fast as possible. The goal is to score as many points as you can in a set amount of time. The game was intended to teach younger children the location of Dutch cities. Later versions of the game also offered German and European maps.

As you can tell from the video, the game isn’t that complex. Here’s my shopping list:

an animation of a helicopter
a map of the Netherlands
coordinates of all Dutch cities
a clock
a scoring system
a randomizer to select different cities
some form of collision detection to determine if the helicopter is at the required location on the map
a way to convert keyboard presses into directional controls

To make things slightly more interesting, I want to use a canvas element. It would probably be easier to use a collection of divs, but where’s the challenge in that, right?

I’ve already found a nice, large map with all Dutch municipalities on it that I can use as a basis for my map and for my coordinates list.

As I’m doing this in my spare time, I’m giving myself one month to finish it. Also, I’m not going to use any library (except for excanvas.js to make it work in IE as well). Reason for this is that I’m not used to work without the safety net of a framework, and I notice that it limits me in being a good JS programmer (basically, I’m too used to the Prototype.js idiom). This will probably mean that I’ll need to look at code optimization at some point.

I’ll start on this next week, after a weekend of relaxing. I hope you (read: someone) will follow my endeavours and maybe learn something from it (as I hope I will).

The problem of massive CSS

Ron — Mon, 06 Dec 2010 14:55:59 +0000

In the past few years, I’ve worked on several big websites as part of a front end team. And all those sites have the same problem: a cancerous growth of CSS. The problem starts out small; a designer changes the look of a new component of the site in such a way that existing CSS classes can’t be used, so the developer adds some new classes. However, over the years this process turns a few hundred lines of CSS into a few thousand lines (or even more than a few). And at some point the developer might not even try to reuse CSS code, because it’s easier to add a few more classes than to find the proper classes in all those lines of CSS. And so the problem of massive CSS is born.

So what is the solution for this problem? In my opinion, the solution has multiple layers. Firstly, for a large site a very strictly adhered style guide and component guide is a requirement. It might not be as much fun for the designers, but it is a very good way to maintain cohesion in the designs across a site. Secondly, build the component with reusability in mind. Don’t make them location dependent (i.e. it should be possible to put a component in the main column and in the sidebar without adding new CSS). This is quite difficult, but not impossible. If there is no other way, make sure to document this in your CSS and HTML. However, the hardest part to solving the issue is getting people on board with any new solution. People don’t like change, and there are actually people that thrive in the chaos of massive CSS.

Technically speaking, I think the best solution is Nicole Sullivan‘s Object Oriented CSS approach. Although the link goes to Github, it’s not only a technical solution, it’s a mindset solution (just like OOP). You need to learn to “see” the “objects” in a page that can work with the OOCSS approach. OOCSS also isn’t a silver bullet, you can’t use it for every single part of your website. However, it can work for the interface elements of your site: the elements that keep popping up all over your site. Things like content boxes, a picture with some text or a form field and label. The clue of OOCSS is figuring out a singular way of building a component and then sticking with it. Of course you can extend a component so that it becomes a new component (just as you extend a class in OOP), but you shouldn’t have two components that look similar on the same level in your “OOCSS hierarchy”.

HTML5 forms with fallback for non-supporting browsers

Ron — Mon, 18 Oct 2010 09:53:27 +0000

Last week, I did some research into creating fallbacks for the new HTML5 form elements, such as email fields, date fields, etc. As it turns out, this is very easy. I used Modernizr for the feature detection. Although it’s just a 5k script, you could easily extract the required code from it if you want to keep your footprint to a minimum.

Based on the Modernizr results, I applied a CSS class for design purposes and attached event handlers. For example, the code below handles the “required” attribute.

function validateRequired(e) {
var fld = e.element(),
ph = fld.getAttribute('placeholder') || '';
if (fld.value === '' || fld.value === ph) {
console.log('field ' + fld.id + ' is required');
fld.removeClassName('validated');
} else {
fld.addClassName('validated');
}
}

if (!Modernizr.input.required) {
$$('input[required]').invoke('addClassName', 'required')
.invoke('observe', 'blur', validateRequired);
}

I use Prototype.js as my framework of choice, but it can be done just as well with other frameworks or plain javascript. As long as you use Element.getAttribute you can access the new attributes without any problems in all browsers. Of course, this is just proof-of-concept code, so it needs some tidying up for actual production use. I’ll probably create a full Prototype.js library of modules to handle the various attributes and field types. I’m also figuring out a good way to handle data-* attributes so you get an easy way to access those. My aim is to stay as close as possible to the official spec for those interfaces.

I’ve tested the code in IE6, IE7, IE8, Firefox 3.0, Firefox 3.6, Safari 5 (Win), Chrome 6 and Opera 10 and they all work as expected.