RND Websites

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

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. (continue reading…)

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.

(continue reading…)

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!

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).

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.

At JSConf.eu 2010, Chris Williams closed the conference with an inspiring speech to rally javascript programmers to help newcomers to the language find decent documentation and to be proud of the work we do. His goal is to build a community that is open to new members and supportive of existing members. We should accept that our language is a true programming language, not just a “toy language” to create some silly effects on a web page.

He also pointed out that there are many people out there that are just in it for the money. They’ll sell whatever they can, not worrying about quality, about what they leave behind for the next developer to come along. He called them privateers, hirelings without an honor code, who aren’t in it for love of the language, or the challenge it brings.

Of course, some of his speech might be no more than good rethoric, but at least part of it rings true. The bit about promoting the language documentation in particular is a strong point, in my opinion. It’s silly that old, out-dated documentation like w3schools still comes in higher than the quite good, actively maintained documentation at Mozilla’s Developer site. It’s even worse that a download link for Java scores higher than actual javascript documentation.

If you’re serious about javascript development, I urge you to watch the speech. Even if you don’t care about what he says, the presentation in itself is worth watching .

Community.js by Chris Williams: http://jsconf.eu/2010/communityjs_by_chris_williams_1.html

Here’s a little help for improving search results for people looking for JavaScript documentation!

So what is this all about? At JSConf.EU, Chris Williams (JSConf US organizer) gave a closing speech about that the javascript community needed to come together to promote knowledge of javascript, so that people who want to come into the community, can learn about the language as a whole, instead of some form of javascript (like jQuery). One way to do that is to get the Mozilla Developer Center documentation higher in the Google search results for searches like “javascript”, “javascript documentation” or specific javascript elements, such as Arrays. That is what the promotejs banner is about. At the promotejs website you can find code to place a banner to specific pages in the MDC JavaScript documentation. By placing this banner on your site, you increase the value of that link from Google’s point of view and thus help getting good documentation at the top of the search results!

As a JavaScript developer, I sincerely support this effort and I hope it will help to give new JavaScript developers the knowledge they need to advance their knowledge. I know that, even at my knowledge level of the language, I can still learn some good things from the documentation, so for someone new, it will most definitely be a great way to understand the actual language, instead of some framework built with the language.

Just quickly posting this bit of code that I’ve written to have a play with YUI3. There’s definitely room for improvement (e.g. making Tooltip inherit from the Overlay widget) and I haven’t tested the code thoroughly yet. But for a first try with a library, I figured it was nice enough to get the expected result:

YUI.add('tooltip', function (Y) {
	var Tip = function (config) {
		Tip.superclass.constructor.apply(this, arguments);
	};

	Tip.ATTRS = {
		offsetX: {
			value: 10,
			setter: function (val) {
				return val;
			}
		},
		offsetY: {
			value: 10,
			setter: function (val) {
				return val;
			}
		},
		showDelay: {
			value: 0.5,
			setter: function (val) {
				return val*1000;
			},
			validator: function (val) {
				return Y.Lang.isNumber(val) && (val >= 0);
			}
		},
		hideDelay: {
			value: 1.5,
			setter: function (val) {
				return val*1000;
			},
			validator: function (val) {
				return Y.Lang.isNumber(val) && (val >= 0);
			}
		}
	};

	Tip.HTML_PARSER = {
		header: function (srcNode) {
			var h = srcNode.getAttribute("title").match(/header=\[([^\]]*)\]/);
			if (h !== null && h.length > 1) {
				return h[1];
			}
			return "";
		},
		body: function (srcNode) {
			var b = srcNode.getAttribute("title").match(/body=\[([^\]]*)\]/);
			if (b !== null && b.length > 1) {
				return b[1];
			}
			return "";
		}
	};

	Tip.NAME = "tooltip";

	Y.extend(Tip, Y.Widget, {
		_srcNode: null,
		_tipNode: null,
		_config: null,
		_timers: null,
		initializer: function (config) {
			this._config = config;
			this._srcNode = config.srcNode;
			this._createTipNode(config.header, config.body);
			this._timers = {
				show: null,
				hide: null
			};
			Y.on("mouseenter", Y.bind(this._onMouseEnter, this), this._srcNode);
			Y.on("mouseleave", Y.bind(this._onMouseLeave, this), this._srcNode);
		},
		destructor: function () {
			this._onMouseEnter.detach();
			this._onMouseLeave.detach();
			this._tipNode.remove();
		},
		_createTipNode: function (header, body) {
			this._tipNode = new Y.Overlay({
				headerContent: header,
				bodyContent: body,
				visible: false,
				width:"280px",
				constrain: true
			});
			this._srcNode.setAttribute("title", "");
			this._tipNode.render();
		},
		_onMouseEnter: function (e) {
			if (Y.BOL.activeTooltip !== null) {
				Y.BOL.activeTooltip.hide();
				Y.BOL.activeTooltip = null;
			}
			if (this._timers.hide !== null) {
				this._timers.hide = clearTimeout(this._timers.hide);
			}
			this._timers.show = setTimeout(Y.bind(function () {
				this._tipNode.set("xy", [e.pageX+this.get("offsetX"), e.pageY+this.get("offsetY")]);
				this._tipNode.show();
				Y.BOL.activeTooltip = this;
			}, this), this.get("showDelay"));
		},
		_onMouseLeave: function (e) {
			if (this._timers.show !== null) {
				this._timers.show = clearTimeout(this._timers.show);
			}
			this._timers.hide = setTimeout(Y.bind(function () {
				this.hide();
				Y.BOL.activeTooltip = null;
			}, this), this.get("hideDelay"));
		},
		hide: function () {
			if (this._timers.show !== null) {
				this._timers.show = clearTimeout(this._timers.show);
			}
			this._tipNode.hide();
		}
	});

	Y.namespace('BOL');
	Y.BOL.Tooltip = Tip;
	Y.BOL.activeTooltip = null;
},
'1.0',
{
	requires: ['event-mouseenter', 'overlay']
});

To use it, the HTML needs to look like this:

<div id="testDiv" class="tooltip_trigger" title="header=[Verzendkosten per bestelling] body=[Nederland: &amp;euro; 1,95&lt;br&gt;Belgi&amp;euml;: &amp;euro; 0,00&lt;br&gt;Overige Europa, Noord- en Midden-Amerika, Cara&amp;iuml;bisch gebied, Azi&amp;euml;, Australi&amp;euml;, Nieuw-Zeeland: van &amp;euro; 3,45 tot &amp;euro; 19,80&lt;br&gt;&lt;br&gt;&lt;strong&gt;Let op!&lt;/strong&gt; Software, pc-accessoires, elektronica en telefonie worden niet in het buitenland bezorgd.&lt;br&gt;&lt;br&gt;]">Test</div>

And finally, to call it:

YUI().use('tooltip', function (Y) {
	Y.all(".tooltip_trigger").each(function (trgNode) {
		var tip = new Y.BOL.Tooltip({
			srcNode: trgNode
		});
	})
})

This is my response to Kyle Simpson’s post about HAML.

Let’s start with a disclaimer of my own: I haven’t used HAML (or SASS) in a real environment, so I don’t know how useful it can be.

Now, with that out of the way, here’s my opinion, based on Kyle’s post:
HTML (and CSS) are two languages that are easy enough to learn. Of course, there are certain intricacies related to how browsers handle HTML and CSS, but that doesn’t change the difficulty of writing in those languages. A link will always be marked up with an a tag, and you’ll always use the background property to set background styles on an element. Once you get the basic syntax, there’s not much you can do wrong (luckily Geocities doesn’t exist anymore to disprove my point ).

I agree with Kyle that templates should contain as little logic as possible. This allows for them to be easily changed to be used with a different server side language and makes them easy to maintain for people that have little to no knowledge of the server side language that’s being used. And of course, there’s the whole separation thing; client side developers are always very adamant about separating HTML, CSS and Javascript, so why should you mix HTML and server side languages (above a certain level)? So, to keep things simple, a templating language should, in my opinion, probably only offer simple variable replacement.

I also agree with Kyle that languages based on indentation don’t make sense. I also like the clarity of having something wrapped in brackets, like it is in Javascript. On top of that, I don’t see the advantage of having to type HTML-like syntax, and leave out the closing tags, or even the brackets around the tags. Yes, it requires more key presses, and I’ve been taught that programmers are extremely lazy (hence the DRY principle), but if that means adding some kind of processing (which requires server power), then I think you’re going overboard.

And to round off my response, here’s a little analogy: I prefer reading books by English authors in their native language instead of a Dutch translation, because I can understand all the subtle nuances and jokes the authors make as they intended them when they wrote them down. However, if my English wasn’t that good, I’d probably prefer the Dutch translation.
It’s the same with HTML versus HAML. To really understand what’s going on, it’s easier to look at the HTML code that’s being put out, as long as you have a good understanding of HTML. However, if you’re not really that good at HTML, but understand HAML very well, you’ll probably prefer reading the HAML code. But that will always mean that you won’t always get the subtle nuances of HTML (granted, there aren’t that many, but if you look at CSS vs SASS, then it starts to make more sense).