jurriaanpersyn.com

Disclaimer: This post wasn’t planned. In fact, it’s a comment on ‘End of an era‘, a blog post by my good friend Lennart, that’s gotten a bit out of hand. So much it didn’t qualify as a comment any more. Reading that post – and its references – first might help in trying to follow what I’m on about.

I get the impression there’s a whole bunch of people hoping to bring the Flash’ coffin to the grave, rather sooner then later. Here’s the arguments I’m hearing:

• Closed technologies suck.
• Flash websites suck.
• Flash is for ads. And ads suck, obviously.
• The web has innovated. We don’t need flash.

All of this is true.
In some way.
But the conclusion Lennart, and with him many other evangelists make, is – in my humble opinion – wrong, stupid and ignorant.

Closed technologies suck.

The car you drive, the stereo you use, the snowboard you skate, hell, even the OS and phone the Apple fans use (that includes me!), are all – in some extent – closed technologies. This post is typed on a machine that totally depends on one multinational’s benevolence. iTunes is closed software, right? But I still totally love it as my day-to-day media player.
I totally support open standards and open technologies – I make my living out of it -, but since when is that a synonym for thinking there’s no room, or even need (!), for closed technology?

Flash websites suck.

Last time Google indexed the web it probably found a gazillion POSH websites that are hard to navigate. Be it on the PC, iPhone or iPad; tiny click areas and unreadable color combinations aren’t an Adobe patent.
Apple tries to control quality for their iPhone OS Apps through whitelisting apps in the AppStore, making sure awful apps don’t get distributed. A policy that I can understand. But then why do they allow every single website, as sucky as it might be?

There’s both crap and good stuff for all platforms. Since when do we blame the platform itself?

Flash is for ads. And ads suck, obviously.

Why is flash being used so much as an advertisement technology? Because of its support and capabilities. From Farukat.es:

“Ever heard of an SVG blocker? A CSS3 blocker? They don’t exist because they’re not considered necessary; these technologies are open, but more importantly, they don’t get abused and they don’t create terrible user experiences.”

Is he joking? Not possible to create terrible user experiences with CSS3 and SVG?! What is annoying? Overlays that are hard to close, too much animation, ugly colors, autoplay of videos and sound, fake UI elements that don’t do what you expected them to do. Which one of those annoyances is only possible with Flash and not with CSS3 and SVG?

The only reason I see for the non existence of SVG or CSS3 blockers is because ad agencies don’t use those technologies. Yet. And they don’t use ‘em because not every user’s browser supports them properly, in a performant way. Yet.

Ad agencies use annoying ads because they want to make money, just the way salesmen can use annoying techniques. Be it on the phone or at your doorstep. Be it with flash or with open technologies.

The web has innovated. We don’t need flash.

Oh, hallelujah, the awesome stuff that you can do with open standards! Gradients, masks, reflections, animations, transforms, transitions, speedier Javascript, local storage; hooray!
No really, I love all this, it gets me excited. I’m a web developer, and I’m now handed new toys to improve my projects. I love the web, I love open standards, and I love all these new possibilities and the direction it’s going in. I’ve even advocated against the use of Flash for several parts of projects I was involved in. Either because better alternatives are (now) available or because more people in the company I work for could then implement and maintain that piece of code.

But, let’s face it; most of this isn’t innovation, it’s catching up with was already possible years ago. Yes, for some use cases Flash has lost its relevance and HTML5 now offers better alternatives. But don’t forget Flash has also helped innovating the web, has brought new possibilities and new ideas to this platform. (On a side note: Adobe even has offered us – web developers – the ability to easily create desktop apps through Adobe Air. While it sure isn’t the best platform to develop a MacOSX app on (hello there, Cocoa developers!), I still think that’s a good thing. I’m using Air apps on a daily basis.)

It is stupid to rule out the engineers of Adobe to continue trying to innovate the web. It is stupid to deny access to content that’s only available in flash right now. (You don’t get denied access to a HTML site that has more than 5 animated gifs, or – god forbid – tables-for-layout, either.) It is stupid to not use the potential of all those smart flash developers out there who do know a thing or two about usability and let them experiment on those new devices to create Plain Old Good Apps. (Disclaimer: I’m sitting in the room with three of them.)

I’m not saying Apple should support flash on their device. The iPhone and the iPad are theirs, if they decide not to support flash, that’s their choice. (Closed technology, right?)
In fact, personally I haven’t missed it all that much on my iPhone. And maybe flash even isn’t ready for these platforms. Is it fast enough? Can the OS support everything flash needs? I’d rather have a good implementation of flash then a slow buggy one.

I only don’t understand the shortsightedness of some of these evangelists who seem to be on a crusade against the availability of flash on those platforms, or any platform in fact. Invest your time in something else. Create good apps, support standards, teach best practices, talk about guidelines, experiment with the new possibilities, but – hell no – don’t try to start a battle against platforms that aren’t yours. It makes you look grumpy. Really.

A month from now, the first Netlog Developer day will be held. On this one-day, free admission event we’ll be discussing oa. the OpenSocial API, the gaming platform and monetization possibilities on Netlog.

OpenSocial defines a common API for social applications across multiple websites. With standard JavaScript and HTML, developers can create apps that access a social network’s friends and update feeds.
Netlog is one of the social networks supporting this standard. So, if you’re interested in developing social applications and while-doing-that would like to learn a little more about Netlog, this event is for you. Topics will also include performance and scaling, giving you an insight on how a site like Netlog is built.

In the afternoon there will be a codelab, where Google and Netlog developers will help you out experimenting with the available API’s.
Parallel with the codelab, there will also be a “Brand Integration Day”, where creative agencies and media buyers are invited to learn all about leveraging Netlog’s Brand Integration Platform and key customers will share their experience with Netlog.

A lot has happened during the past months, and we continue to work on improving our platform – for users and partners alike. We’d be thrilled to see you on April 2 to learn what we’ve done and share some of your thoughts.

The Developer Day kicks off at 9 am on April 2nd at Kinepolis in Brussels. Interested? Register here.

Keep an eye on the Netlog Developer blog for more info.

This article accompanies the slides from a presentation on database sharding. Sharding is a technique used for horizontal scaling of databases we are using at Netlog. If you’re interested in high performance, scalability, MySQL, php, caching, partitioning, Sphinx, federation or Netlog, read on …

This presentation was given at the second day of FOSDEM 2009 in Brussels. FOSDEM is an annual conference on open source software with about 5000 hackers. I was invited by Kris Buytaert and Lenz Grimmer to give a talk in the MySQL Dev Room. The talk was based on an earlier talk I gave at BarcampGent 2.

Overview

• Who am I?
• What is Netlog?
• A history of scaling database systems
• Hitting limits
• Sharding basics
• Sharding schemes
• Implications
• Existing solutions
• Implementation
• Tackling the problems
• Final thoughts
• Slides
• Resources

More… »

Here are the slides from yesterday’s presentation about horizontal database scaling through sharding at the mySQL dev room at FOSDEM 2009.

I’ve got a ton of notes and remarks to these slides, which will become available here soon.

Every so often, when in JavasScript-code-mode, there's the need to make some decisions based on data that's not available in the document itself. Say your templating engine comes up with the following HTML, which is basically a list of friends linking to their respective profiles;

Now you'd want to mix in some extra-js-fu, by displaying a mini profile when you click any of the links. For that you'll be using your AJAX-API that needs eg. a user-identification integer or string as parameter. How is your JavaScript gonna know what this userID is for each of the listed friends? Right, you need some extra information for this.

Different approaches

There's a few ways of including data you need on a js-application level to your DOM-tree, some of which I list here;

• Hidden form elements:
  You could nest some forms with hidden elements containing the data you need into your DOM. But I guess for the use case here, that would make your html quite cluttered and you'll have quite some overhead traversing the DOM to find the elements related to the click-event of your link. On the upside though, you can store about any value in those form elements as long as they're properly escaped. Example HTML:
  PLAIN TEXT
  HTML:

  1. <a href="/wolksken">Laura Bogaert</a><form><input type="hidden" name="userid" value="1043" /></form>

• Custom attributes:
  Why not just add some custom userID-attributes to the elements you need? It's very readable and flexible, it works in all browsers that support XHTML and - as with form elements - allows for about any type of text string, thus is an excellent solution. And in fact, the X in XHTML is for extensible right? But of course, there's the Standards Police™, who might not like that you're adding new custom attributes that aren't in the original specification, to put you off from using this technique. Example HTML:
  PLAIN TEXT
  HTML:

  1. <a href="/wolksken" userid="1043">Laura Bogaert</a>

• Abuse an existing attribute:
  You could hide the fact you actually want to use custom attributes, by just abusing some of the existing ones. Let's for instance take the rel="" attribute; an existing attribute, available on anchors, left mostly unused; if we use it to store a userid in, validators won't complain, so we're all set? Well, quite an ugly hack, isn't it? Not semantic, not always available and you still have no easy solution for key-value pairs. Example HTML:
  PLAIN TEXT
  HTML:

  1. <a href="/wolksken" rel="1043">Laura Bogaert</a>

• (Ab)use your class-attribute:
  There is one attribute that does fit for using to save data though, since it's available on every element, flexible enough, and it (can) even make sense on a semantic level. While class names will in 99% of the cases play a purely visual role, you could use them for application logic too. Isn't that what microformats are doing? Since you're using class names, you have to deal with some of it's limitations though; they can't have spaces, and some browsers might not like all characters. Example HTML:
  PLAIN TEXT
  HTML:

  1. <a href="/wolksken" class="userid_1043">Laura Bogaert</a>

Each of these 4 techniques have their own reasons to exist, and I'm not here to tell you which one is best, or which one you should use. I'm here to share two helper methods I've written for the class names approach.

Extending Prototype with classname data helpers

So, we're adding some extra data to our class-attributes. The templating engine does this in the format of "_".

If we want to access these key-value pairs in JavaScript we go to the DOM-element, loop over it's class names, split the keys and values, and return the value for the queried key. Likewise you might want to have a class data setter method too.

For this I wrote two methods, getClassData(key) and setClassData(key, value), for Prototype, my weapon of choice for JavaScript development. These methods are getters and setters for those key-value pairs, and thanks to Element.addMethods, available on every DOM-element. Here's an example of it's use:

Here's the source code:

Here's a seperate file with the script: classdata-extensions-01.js.

The getClassData will always return values as strings. You could build in some type-hinting methods, but you'd have to implement that same protocol in your templating engine too then, so I decided to leave it out here. The data value is now being url-escaped to add it to the classes, but of course there's some limitations there too.

Here's to hoping these 2 methods might provide you some use ...