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

<code>/usr/bin/curl -s http://ilmatieteenlaitos.fi/saa/Helsinki|/usr/bin/grep "Päivän pituus"|/usr/bin/sed -e 's/^[ ]*//' -e 's/<[/]\{0,1\}[^>]*>//g'</code>

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.

Pitihän sitä nyt käydä katsomassa kun herraskaiset soivat meille alamaisilleen ystävällismielisiä eleitä ja muutaman sanan.

Niille jotka eivät päässeet itse paikalle tein simulaattorin jolla voi fiilistellä paikan päällä vallinnutta hurmosta. Taustamusiikin avulla voi kohottaa tunnelmaa entisestään.

Ympyrätalon Alkon yhteydessä on kolme hyvin aktiivisessa käytössä olevaa pullonpalautusautomaattia. Keskeinen sijainti takaa yleisömenestyksen, eikä ole mitenkään epätavallista että jokin koneista on poissa käytöstä. Tänään oli kuitenkin jonkinlainen huipennus, kun kaikki kolme konetta huusivat kuorossa virhetilannetta.

Palautuskoneet kuuluvat samassa rakennuksessa olevan S-marketin vastuun piiriin. Koneiden kiljunta ei kuitenkaan kuulu kaupalle asti, eli ellei kukaan käy asiasta sanomassa saavat koneet huutaa vaikka maailman tappiin saakka, tai vähintään siihen asti että joku S-markettilainen kaipaa tupakkataukoa.

Tilanne olisi käynyt paremmin kuin hyvin esimerkiksi Seth Godinin puheenvuoroon This is Broken.

Voisi helposti kuvitella että kun palautuskoneisiin kuitenkin palautetaan myös Alkon pulloja, olisi mahdollista luoda edes sen verran yhteispeliä että vikatilanteista ilmoitettaisiin S-marketin henkilökunnalle. Jokainen kassapiste kun kuitenkin on varustettu puhelimella.

Toisaalta täytyy ihailla Alkon henkilökunnan kärsivällisyyttä. Itse en voisi tehdä työtäni helvetillisen piippauksen tahdittamana.

Muut MOPV-sarjan kirjoitukset

Most developers working with the web will sooner or later need to deal with sending e-mail. Usually it’s a contact or feedback form that needs to be delivered to an inbox in a nearby universe.

What has been bugging me about this is that whenever I need to send e-mail, I actually need to use e-mail, which slows things down and is cumbersome in so many ways, since your sysadmin didn’t configure the mailer on the development server – and more often than not, that development environment is your own laptop and I certainly don’t want to setup a working mailer on mine. Besides, I might not even be connected to a network. And don’t even get me started on when you need to dry run bulk mailing.

Luckily, at least if you’re running *nix, there’s a very simple solution; replace your sendmail binary with the following shell script¹:

<code>#!/bin/bash

LOGDIR="/tmp/sendmail-sim"
NOW=$(date +%Y-%m-%dT%H.%M.%S)
CNT=1
PRIVATELOG="$LOGDIR/$NOW.$CNT.log"
COMBINEDLOG="$LOGDIR/combined.log"

# If privatelogs are being used...
if [ ! -z "$PRIVATELOG" ]; then
    # ...make sure the filename is unique and create the file
    while [ -f $PRIVATELOG ]; do
        CNT=$(($CNT + 1))
        PRIVATELOG="$LOGDIR/$NOW.$CNT.log"
    done

    echo "$0 $*" > $PRIVATELOG
else
    # ...otherwise swap filenames
    PRIVATELOG=$COMBINEDLOG
    COMBINEDLOG=''
fi

echo "[$NOW]" >> $PRIVATELOG
while read BUF
do
    echo $BUF >> $PRIVATELOG
done

# Append privatelog to combinedlog when both logs are used
if [ ! -z "$COMBINEDLOG" ]; then
    echo "[$NOW]" >> $COMBINEDLOG
    cat $PRIVATELOG >> $COMBINEDLOG
fi

exit 0</code>

This will result in all input that is sent to sendmail being written to a separate² log file in the /tmp/sendmail-sim directory, as well as a combined.log for convenient tailing.

Tim Bray also says that “the best attack on pirates is to make their work more difficult and expensive, while simultaneously making the legal path to products straightforward, easy, and fast.”

Right on Tim, but…

Google’s Android Market lets you install paid applications only if you are in one of the 13 supported countries. The “legal path” is neither “straightforward, easy, or fast” if you don’t live in one of the 13 countries that are supported. Maybe instead of focusing on developing anti-piracy services, Google should add more locations to the paid Android Market.

Android Market and Piracy