CODEgrunt blog

I suppose that I am paranoid by nature, at least with respects to web technologies. Javascript for example is obviously a powerful, feature friendly way of creating dynamic content but the idea of client side scripting that is not under the user's control has always made me a little nervous (the vast majority of browser exploits rely on it for example). So my default browsing environment is with ads blocked and Javascript disabled.

More and more these days I am seeing artifacts of new school web designers either confusing or forgetting that client side is not under their control and that not everyone (or every thing such as the plethora of bots out there) sees the world through rosy Javascript coloured glasses. Take the NHL's web designers for a Javascript-less ride and we get this:

What's in the red circle? Let us take a look:

//values were inserted here in example

It is hard to tell whether someone was taking "copy and paste" too literally or whether a 3rd party is injecting content they should not be but none the less, it makes for an amusing and informative Google search.

The obvious lesson is do not forget to test your code with Javascript disabled because at the very least Google will.

topics: javascript, opinion, programming

Linux has been my primary desktop OS now for close to a decade, originally via Gentoo but for the last while now I have been sticking with the less attention demanding Kubuntu. As pleasant as the Linux experience generally is, one unfortunate downside is that the two most prevalent MP3 players out there require proprietary software to use - there is no iTunes or Windows Media Player available for Linux. This forced vendor lock-in immediately takes the iPod and Zune out the running when looking for a new device to help you rock some tracks while out and about.

When looking for cross platform media players, the magic acronym you want to hear is "MSC" (Mass Storage Class) which means that the drive will be mountable as a standard removable drive. "MTP" (Media Transfer Protocol) can be hit or miss due to lack of standardization so has less chance of working. An article over at the venerable British tech rag The Register suggested that the Philips GoGear Muse had decent support for MSC mode and should be a suitable option for those running Linux.

Now I was fairly late to the PMP (portable media player) party so my first device was a 16GB Sansa View. Forgotten and unsupported by the manufacturer with terribly written firmware (OS crashes, bugs, poor power management, you name it), the View should be the textbook example of how not to implement an MP3 player. I cannot speak for Sansa's other products but I for one will never buy another MP3 player from them. But hey, at least I now have a low water mark to compare against.

With my frustration with the View finally bubbling over and a need for a reliable player, I wandered down to the local Future Shop outlet and picked up a 16GB Muse for $100 CAN (plus taxes).

Note: this review is an ongoing project.

My main uses for the Muse are feeding music to a PA for in between performances, fuelling a small portable PA for group bike rides and for listening to music before going to sleep via the RCA ins of a small ghetto blaster. For these uses this player has performed well enough that I am not seeking a replacement.

For a hundred clams (at least in my town) your MP3 options are often fairly limited. The Muse is not perfect but for that price of entry I can recommend it to those looking for a Linux friendly player who do not require a loud audio output. If the Muse could generate a better volume level and if the random play was less prone to repetition my prognosis would be glowing. As it stands, this player has given me my money's worth and I will definitely consider Philips when I need a replacement.

Pros

• on device playlist support
• good format support including OGGbattery life is usable
• nice display
• standard mini USB connector
• on device database generation handles missing ID3 tags gracefully
• mounts in MSC mode with Kubuntu 9.* and 10.*
• sleep timer

Cons

• "random" play is not as random as it should be
• rather anemic output level (volume much too low)
• lack of a compressor (volume limit helps but aggravates the already low output volume
• occasionally does not seem to shut down properly
• long boot up time
• device does not currently work with Amaraok 2.*
• sleep timer rudely cuts off which can cause audible glitching instead of fading out gracefully

topics: review

While rewriting an old codebase of mine I decided that I should re-think how I was storing country data and switch to using country codes directly since those are standardized, immediately obvious when looking at the data and just as indexable by MySQL as numerical Indices. My old HTML piped through Awk generated MySQL table does not contain country codes so off to Google I went. Well somewhat surprisingly there are a lot of bad answers out there as to where to find an official list of country codes.

To hopefully safe time for those on the hunt, the official list of country codes can be found here:

• ISO 3166 code list

The data is available in a number of formats including XML, plain text and viewable HTML.

topics: programming

Ahh, carriage returns how I love thee. Today I managed to waste around 20 minutes banging my head against some very simple Javascript used to open a new window when the user clicks a link:

<a href="http://codegrunt.com" onclick="window.open(this.href); return false;">this is a link</a>

Trivial code, user clicks link and new window opens up. If life was only that simple - instead of the desired behaviour, the original URL was also firing and causing the originating window to load the URL as well. Arrrgh.

Can you see the bug? It is a trick question really as you would have probably have to view the source to notice it. The problem was a stray carriage return after "return" which causes Javascript to skip the return value of "false" and happily follow the link in both the current page and a new window. Now normally this would have been immediately obvious to me but my IDE is set up to nicely linewrap long lines which normally is pure awesome but unfortunately tricked me today when high LCD contrast (and perhaps not enough coffee) made the grey line wrap less obvious.

I hate these situations, something so simple going inexplicably astray. It becomes so easy to spiral off on dangerous tangents, "Oh no, maybe NoScript is doing something funny. . ." or "Crap, I bet something buried in an external library is messing with events!" Time consuming goose chases which could easily create their own mess as you wade frantically through trying to solve an issue that seems both impossible and ridiculous.

It has been a while but I again know how it feels to get punked by carriage returns.

topics: javascript, programming

Sometimes reference documentation can do more to confuse than to help. Take the terms "URI" ("Uniform Resource Indicator") and "URL" ("Uniform Resource Locator"). You will often see these acronyms tossed around like they are radically different beasts and this can lead to confusion when sorting out what the authors intent is.

For those just wanting the quick answer, a URL is just a specific type of URI. They are not different things. Now for the long answer. . .

Back in ye olde days of the early World Wide Web there was a different view of how web pages (and other services) were going to be found. A URI represented the entire heirarchy of methods for finding resources and these were broken into 3 discrete types (with the option to add more later). The 3 types were URL, URN and URC (with the latter "Universal Resource Characteristic" never gaining common use). URLs were to be the addresses that machines would use to locate services and then there were URNs ("Universal Resource Name") which humans would use to find these services. The intent was that humans would never see URLs at all and much like how DNS maps human readable host names like "codegrunt.com" to numerical IP addresses, browsers would hide URLs behind more readable URNs using some external service to do the conversion between then.

Well, this approach never really took off as people (and programmers) started using URLs directly. While URNs still have a place in modern infrastructure, they are no longer thought of as a discrete type of URI. The W3C covers this pretty well:

URIs, URLs, and URNs: Clarifications and Recommendations 1.0

. . . according to the contemporary view, the term "URL" does not refer to a formal partition of URI space; rather, URL is a useful but informal concept: a URL is a type of URI that identifies a resource via a representation of its primary access mechanism (e.g., its network "location"), rather than by some other attributes it may have. Thus as we noted, "http:" is a URI scheme. An http URI is a URL. The phrase "URL scheme" is now used infrequently, usually to refer to some subclass of URI schemes which exclude URNs.

Unfortunately, even documentation writers do not always get the distinction fully right which does not help with the confusion of this issue:

PHP Documentation: parse_url()

Note: This function is intended specifically for the purpose of parsing URLs and not URIs. However, to comply with PHP's backwards compatibility requirements it makes an exception for the file:// scheme where triple slashes (file:///...) are allowed. For any other scheme this is invalid.

The above note suggests that URIs and URLs are not the same thing which is not true. What they should be saying is:

Note: This function is intended specifically for the purpose of parsing URI schemes "http" and for backwards compatibility reasons, "ftp".

Ah, jargon. How I hate love you.

topics: Internet, jargon, PHP