/dev/nikc/blog

A while back, Jeff Atwood wrote about the proverbial Internet Driver’s license. I liked the article and agreed wholeheartedly. Lately even more so.

Nowadays, hardly a month passes when a new service or interesting site doesn’t pop up, that one simply “must” check out to keep on top of the game – especially being part of the industry, but mostly due to curiosity or peer pressure. Often, this site or service will offer a higher level of service if you register as a member. In my case, I tend to create user accounts just to take the alias I use off the market. Or, rather, I used to do so.

Lately I’ve noticed that I mostly shun away from sites that require me to create a new user account. It’ll have to be something pretty damn special for me to care. Despite the fact that I’ve given up on managing my credentials mentally and handed over the task to 1Password. I just don’t want Yet Another User Account, when there are existing established solutions available which will let me identify myself using one that I already have.

So stop asking me to register and let me use the identity provider of my own choice.

Approximately 24 and a half hours ago I placed an order on Amazon.com. During the night a shipment confirmation had arrived in my inbox. Five minutes ago, UPS Finland phoned me up to inform me my shipment is arriving next week and that they’ll be taking care of all the customs mumbo jumbo for me.

Wow.

These guys have their act together. Big time.

Thanks to the Mobile Meetup arranged by Frontend Finland, I was presented a quick look into the current state of developing apps for the three leading mobile platforms today, presented by people who are actually doing it. Personally, mobile development is a field I’ve dabbled time to time in over the years, but never created anything useful due to several reasons; me (and my [lack of] creativity) probably being the biggest obstacle and the lack of paying customers for my employers following closely after.

Of the platforms presented today, surprisingly, Qt Quick together with QML seemed the most appealing to the coder inside me, but sadly isn’t very current for me. iOS probably tickled the drag-and-droppers in the crowd – me, not so much. Android should be right down the alley for those who are familiar with razors and/or cranial acceleration towards firm surfaces – not the least thanks to the tools that are (not) available.

It really is a jungle out there. Maybe one day there’ll be a machete that’ll allow us to hack-n-slash our way through it in style.

I spent today debugging strange JavaScript behaviour in Firefox. The scenario was as follows:

The main interface of the app I’m working on loads document fragments on demand. These fragments contain script blocks. We use jQuery to load these fragments.

When jQuery.appending a new fragment into the DOM jQuery cleverly extracts all script nodes from the fragment and then synchronously executes them in the order they appear, regardless if their source is external or inline, and only after all scripts have been evaluated returns. A blocking operation, which in our case is what we want.

The script handling the main interface (and pulling in the needed bits) depends on this behaviour —(which might be silly and could be avoided by redesigning the architecture, but that’s a different story)— and today it broke for no apparent reason. After some hours of peeking and poking I found the culprit to be Facebooks’ loader script which appends more scripts with external sources into the DOM. The fact that the script came from Facebook is irrelevant here, the injected script nodes aren’t¹.

Safari and Chrome handles this elegantly, leaving jQuery’s behaviour unchanged, but in Firefox it caused jQuery to return prematurely. In Firefox, it looks as if the dynamically injected externally sourced script node is forcing asynchronous evaluation to all dynamically injected script nodes, including the ones with inline source code.

The solution was simple enough: keep the Facebook share script at the bottom, but locating the issue was a pain. Whether or not this is a Firefox bug, I don’t know, but I couldn’t find anything on the issue so I thought I’d give it my 2 cents.

A simple demo, for those who are curious. Latest production version to date of all mentioned browsers were used in testing.

When Chrome was released, I was thrilled. Well, not about everything, but mostly it was great. It’s speed was praised high and low and I was no exception. Lot’s of things I criticised have since been fixed, but one thing still remains:

There is no hint of an available feed in the address bar omnibox, or anywhere else either as far as I can see. What’s going on here, really?

Being a feed junkie (if you couldn’t already tell), I was very surprised to learn from Camendesigns’ blog post RSS is dying that Firefox is about to go down that same road in its upcoming version 4. Of course, the functionality is not going anywhere, as Asa Dotzler states in his retort, but will be moved inside the bookmarks menu.

Maybe it’s just me, but I think having to open up a menu just to discover whether a feed is present or not is hardly a step forward. In my mind this is the same as if a car manufacturer decided to move the fuel gauge from the dashboard to inside the glove compartment. Sure, you can still check the fuel level but you have to make an effort instead of being able to do the same with just a glance.

Naturally, webmasters can still flaunt their feeds themselves, just like I do, but I dislike duplicating browser functionality – in my defense, I’m doing it to justify the presence of the link to whatisrss.com with which I thought I could advocate and educate about feeds, optimistic as I am.

I’m glad that for Chrome the lack of feed hinting can be fixed with a plugin. One can always hope a similar Addon will be available for Firefox as well.