the announcement that google will be closing down its RSS reader didn’t go down well with a lot of people, including me. i use the RSS reader daily. i have subscriptions to ca. 30 feeds, mostly for general news (newspaper), tech/linux news and a few for work (some academic journals provide RSS feeds, i also have set up notificiations for a few web pages like job advertisement pages at universities etc. through page2rss ). i know we have no right to complain when someone stops providing a free service – still, it is annoying because it means that i have to look for an alternative. an essential criterion for me is that it needs to be web-based, because i use it from different computers and it needs to stay synced. the most promising alternative so far seems to be the old reader. i really like the minimalist approach. however, it seems it’s more or less a hobbyist project and we’ll have to see how they handle the large influx of new users. i’m also not convinced with their update speed yet. they say that they refresh the RSS sources at least once a day. but once a day is too slow. with google reader, i’m used to get updates within ca. 15 minutes. another alternative is feedly, but it requires a browser add-on and looks bloated. actually, i have more hope for a new reader that is being developed by digg. let’s see what they can cook up.

the question remains why google is suddenly closing down the reader. in the announcement, they are hinting at the possibility that it has something to do with their ongoing attempt to concentrate their activities around google+. but of course social media sites are not a full replacement for a full-fledged RSS reader. google also mentions that usage of their reader has been declining. i have a hard time believing that there is not enough demand, though, when i look at the user stats of the old reader before and after google’s announcement. this is more likely to be a business decision. google’s core business is ads. that’s why they don’t want you to read the news inside the RSS reader, they want you to read it on the webpage itself, where you’ll see the ads. of course in reality that won’t change anything because people will simply move to another RSS reader. besides, any sane person has an ad-blocker installed anyway.

there is a free, legal and fairly easy way to test webpages/webapps in IE7,8,9 on mac and linux. i recently learned that microsoft provides virtualbox images created for this purpose. follow these instructions to install one or more VMs with IE. note: the script provided there gave me an error while trying to install a virtualbox extension pack. i had to download that manually from here and load it into virtualbox.

why is this a big deal? because i’m working 100% on linux and testing in IE has been a pain so far. while i do still have a winXP partition on my computer, having to reboot every time i want to test a change is extremely tedious. besides, IE9 doesn’t run on winXP and i’m most definitely not going to buy a vista/win7 license just in order to test IE9 compatibility. what’s more, windows to my knowledge never allowed to install multiple versions of IE alongside each other, so this is the first time i can actually test something in multiple versions of IE without rebooting and/or leaving my usual working environment.

html5 audio in 2012 is still in a rather sad state. true, there has been some progress. the <audio> tag is now widely supported across browsers and usable. however, anyone who has tried using it for a real life application like a game will have noticed that html5 audio is still pretty much unusable.

for one, there is the codec issue – there still isn’t a codec supported by all browsers, you need at least mp3 and ogg if you want to reach a signficant part of the userbase. if you want a single format that covers all major browsers, your only choice is WAV. i think this alone is enough of an annoyance to make working with the platform a headache.

second, the <audio> tag just doesn’t cut it for games. even for the most basic games (beyond tic-tac-toe) you need at least the following two features: immediate playback and support for overlapping samples. that’s because with games, you are usually dealing with short samples (sound effects) that need to be played back without delay, and they also need to be able to overlap. timing is crucial. the <audio> tag has not been created for that purpose, and it just won’t work reliably across browsers if you attempt to use it that way. a simple example with an html page that has a button and some javascript hooked up to it that plays a short sound via <audio> tag when clicking the button is enough to show the problem: when you click it a couple of times repeatedly it will give strange and unreliable results in different browsers. it’s just not good enough for games. there are a lot of people these days who say that html5 is going to kill flash on the web soon, but it makes me wonder whether those people have looked into audio at all?

the good news is that the w3 is working on a much more sophisticated web audio API. you can follow the discussion here. however, it’s still in draft version and currently only webkit has a (vendor prefixed) implementation. it seems to me that the w3 audio group is pretty much focusing on the web audio API now, so that’s probably where we are headed. mozilla’s own lowlevel audio data API appears to be on the way out. although there is one working implementation of the web audio API (webkit), it is clear that the specification process is far from over, with a large amount of issues recently brought up by the opera team. the group seems to be targeting 2013 for a first release of the spec (recommendation status), but some members have described this as very optimistic.

i’ve been playing around with the web audio API myself and i must say it makes a lot of sense and it has an impressive feature set. it provides all the functionality that i will ever need but is still fairly easy to pick up. for html5 games it really seems like the ideal solution. so here’s to hoping that it will reach a stable version soon and that other vendors will pick it up. with neither mozilla nor opera having started an implementation (as far as i can see), and no sign from microsoft whether they are planning to support it, it seems unfortunately that html5 audio still has a long road ahead.

in the meantime, you have three choices: 1) stick with the <audio>-tag and live with the poor results, 2) use the web audio API when available, otherwise fall back to the <audio>-tag, or 3) fall back to the flash plugin.

update: check out this talk about the web audio api from google i/o 2012.

seit es doink.ch gibt, hat die seite schon einige veränderungen erfahren. nun ist wieder einmal die zeit für eine grössere neuerung gekommen. schon seit einer weile war ich unzufrieden damit, dass die beiträge hier zu uneinheitlich waren. auf der einen seite stehen die themenbereiche germanische sprachwissenschaft, universität usw., daneben gibt es eine reihe von beiträgen zu ‘geeky’-eren themen wie html5, linux, webdesign usw. nun finde ich es grundsätzlich nicht gut, wenn die themen eines blogs zu weit gestreut sind. besser ist es, inhaltlich zu fokussieren und eine möglichst spezifische nische einzunehmen, ansonsten droht das bei vielen blogs zu sehende “kraut-und-rüben” problem.

da ich mich in jüngerer zeit wieder vermehrt mit html5 und webtechnologien beschäftige, schien es mir am besten, die beiträge zu diesen themen auszulagern. es ergab sich allerdings dabei das problem, dass ich den namen doink, den ich vor einigen jahren ohne bestimmte absichten gewählt hatte, eigentlich für die beiträge rund um html5 passender fand als für die themenbereiche germanische sprachwissenschaft usw. aus diesem grund habe ich am ende entschieden, statt den html5/webdesign-themen vielmehr die beiträge zur germanischen sprachwissenschaft auszulagern. diese sind neu auf swanrad.ch zuhause. auf doink verbleiben demnach nur die etwas ‘geeky’-eren themen. wer den RSS feed abonniert hat, soll also je nach interesse den feed von swanrad dazunehmen / denjenigen von doink entfernen.

zum neuen namen: swanrād ist ein altenglisches wort, das im heldenepos beowulf vorkommt (Z. 200). es bedeutet wörtlich ‘schwanen-strasse’ (engl. swan road) und ist eine poetische umschreibung für das meer.

einiges befindet sich zur zeit noch im umbau, ich bitte, gelegentliche 404s und irrtümliche RSS benachrichtigungen zu entschuldigen…

i was having some fun with native ‘drag-and-drop’ in HTML5. as an exercise for myself, i designed a geography training app. head over to map-o-matic to check it out. needless to say, this works only with the latest generation of web browsers (works on firefox/chrome, doesn’t work on IE).

i mostly followed a tutorial over at html5rocks.com.

this was also my first time to translate a PHP webapp with gettext/poedit. pretty nifty :)

recently, i noticed that the locate command on my ubuntu system didn’t work as expected. it simply didn’t list files located in my $HOME dir, while it did still list files in the system directories. it took me a while to figure out that this behaviour was due to the fact that i decided to check the “encrypt home dir” option when i last (re-)installed the OS.

on second thought, it makes sense that it works that way, since the command to update locate‘s database (updatedb.mlocate on ubuntu) is run as a root cronjob, and as such it can’t access the filesystem while it’s encrypted. on the other hand, understanding this requires quite a bit of prior knowledge about how locate works, and i think it’s a bit rough to let the users figure this out all by themselves, without as much as a warning. the situation would be much improved if locate would at least spit out a warning that it can’t access the home dir, instead of the ominous silence, from which we usually conclude that no matching files exist on the disk.

after some googling, i found a good solution for this problem. this guide explains how to set up locate to store a separate, user-specific database inside the encrypted home directory. this also requires a user-specific cronjob. after following that guide, locate once again works just as expected on my system.

note: this will work only on very modern browsers (latest firefox, opera, safari). it will work partially on chrome (no audio), and it will not work at all on internet explorer.

update march 2012: major update! the game logic has been re-written from scratch (it was buggy), the game now has 5 levels, a reset button, fading effects, and even one very simple animation :) in addition, audio should now work on chrome.

“If a company designs both hardware and software,
it can build much better systems than if they only design the
software. That’s why Apple’s iPhone is so much better than
Microsoft phones.”

this statement comes from larry ellison, oracle’s CEO, in a recent reuters interview.

what he says is a simple truth, almost trivial, yet it can’t be stressed enough how significant it is. while i personally couldn’t care less about phones, the statement holds of course just as well for desktop / laptop computers. frankly, both windows and linux desktop OSes work crappily on many computers today. you will get devices without proper support, driver issues, incompatibilities between components and all sorts of other problems. and this problem will never go away as long as the hardware and the software are not engineered together. there are literally quintillions of different PC devices / components out there today, and there is just no way any OS could ever support all of them – and all combinations of them – equally well.

the solution, then, is to buy hardware and software that comes from the same company and has been designed to work together. both windows and linux fail in this regard, only apple (and sun) get this right as of today. and this is IMHO the main reason while apple is so successful these days. it’s just not possible to get the same stability and reliability with an OS that is supposed to work “on any PC hardware”.

hopefully, we will get linux computers at some point in the future that are engineered in this way. the company could make money from the hardware, and the software could still be free/open source. i at least would be happy to pay the extra charge.

google got all fat & rich because of one single reason: they excel at sorting search engine hits. the secret behind this is called PageRank, a clever algorithm to sort links. they even explain the basics of how that works on their homepage. how nice of them.

but hold on a second. if all of their success was based on one single business secret, why in the world would they be talking so openly about it on their webpage? granted, they don’t give any implementation details there, but still, why put the competitors/cloners on the right track with information about the way PageRank works?

personally, i think it’s a priori much more likely that the information about PageRank on the google homepage is deliberately misleading, so as to fool the competition (and the general public…).

but what else could be google’s secret, then?

well, try this: go to google and search for ‘antoine meillet’ (feel free to use your favourite linguist instead ;). look at the results and hover over the links. you will see nothing strange: the full URL in the status bar will indicate that they are direct links to the target webpage.

or maybe not? check out the source code of the google result page (on firefox, select the text and choose ‘view selection source’ from the right-click menu – god i love that browser). surprise, surprise: the href attribute does in fact not show a direct link to the target (we expect: href=”http://en.wikipedia.org/wiki/Antoine_Meillet”), but instead shows something really cryptic like:

href=”/url?sa=t&source=web&ct=res&cd=1&url=http%3A%2F%2Fde.wikipedia.org%2Fwiki%2FAntoine_Meillet&ei=IzJQSaP3JY_m0gXV7KWEBA&usg=AFQjCNFHbV4saUM80cY7BQ6pfEYNAGnD0A&sig2=a9sZLl2cPM-V7WC5dGs–A”

now what exactly that means (and how they manage to still show the simple address in the browser’s status page) is a mystery to me. but what seems quite obvious is that people are in fact never directly forwarded to the target site when they click on the google search hit. instead, it looks like they are secretly routed back through google HQ. now since it’s rather difficult to figure out what exactly happens if you click on that link (too much javascript involved…), it’s easier to just log the browser’s activity to see what’s going on behind the scenes. sounds like a job for wireshark (good thing i use linux, where great tools like this one come included!).

here’s wireshark’s list of the all HTTP/GET requests that happend on my network interface when clicking on one of the links from google’s search result:

notice that the first HTTP/GET request went back to google! only the second (and the following ones) went to wikipedia:

with the help of wireshark, we have therefore confirmed that the users are being routed back through google before they reach their actual destination, so the question is: what could be the purpose of this? simple: google will store the key words of your search along with those hits from the search result that you actually clicked on, trusting that you will look through the list of results that google presents and choose the relevant hit(s) from among them. with this information, they will increase the ranking of the hits you clicked on, and decrease the ranking of those hits which you skipped, all in relation to your specific search keywords.

if true, it means that google does in fact let the users do the sorting for them. humans are much better at sorting out relevant hits from among a mass of unrelevant ones, and since google has the possibility to collect that information, why not use it to improve the ranking? it seems not too far fetched, then, to suspect that the core of PageRank is in fact not a fancy algorithm at all – but that it is simply a clever way to let the users rank the search results for them, by (secretly) collection data on which hits the users clicked on and which ones they didn’t.

ps: further investigation showed that the cryptic links in the source of google’s search result pages are not always there. but even in those cases, wireshark shows a HTTP/GET request sent to google before the loading of the actual link target.