Bulix.org » Life snippets

Why apps are good, why apps are bad

There's an app for that. (probably trademarked by Apple). We now all know this little mimic from our friends in Cupertino. In the last two or three years, the mobile world has evolved from portable telephone booths to 100 grams portable and very capable computers. And with the evolution of the hardware and of the networks came a whole new field of opportunities for the mobile web and mobile applications.

Although being a huge supporter of open web standards, I have never been a huge fan of web-based applications. I always felt that the browser was only a piece of software in an operating systems. In short, that the Internet was not just the Web. That there is a whole other 65535 other ports for doing great stuff, differently, with the network. Applications offer so much more possibilities.

Just looking at the growth rate of the various mobile app markets out there shows the vast potential of these new platforms.

But I am afraid this will soon backfire.

Windows Mobile, iOS, Android. Microsoft-based, Apple-based, Linux-based. Sounds familiar? Yep, we still have that very same portability issue. Every single application needs to be written three times, in three different languages and frameworks, to reach the broadest audience. And that's not even mentioning Blackberry and Nokia, if these guys are even still meaningful.

Newer and cutting-edge web standards are slowly closing the gap, and great things are now possible with HTML5, CSS3, Canvas, etc (although I have yet to see good, hardware-accelerated, multi-browser support for all of this). What we need though, is better mobile browsers that really fade away to leave you with your application. ChromeOS probably does a step in the right direction there, but it needs a lot more than that to be awesome on the mobile phone space.

And finally, security. Most of these applications are closed-source, which makes auditing them virtually impossible. You don't have access to web services source code either, you'd say. And I would agree, but in more cases that is actually fine. I don't really care what the Pandora app is doing, how it logs in, etc. But what about your favorite banking application? Are you really sure it's really secure? When logging in my bank's website, I can check the SSL certificate, and I trust my open-source browser for doing the right thing with HTTPS and certificate checking. Can we really say the same about a mobile application? Does it actually check the SSL certificate, or just accepts anything? Does it even use SSL? Are you even sure it comes from your bank?

The mobile application market is growing so quickly some of the good virtues of F/OSS (open and accessible source code, transparency, security, attachment to standards, etc) didn't have the time to reach the large community of mobile developers. And Android might be the most "open" (yes, you need to say it fast) commercial platform available right now, the apps that run on it clearly aren't. And that's a shame.

I don't think the "app model" will fall apart. It's there already, and an even greater proportion of its users (compared to computer users) simply doesn't care as it "just works". But for these (not so well put together) reasons, I wish applications developers, publishers and markets would do a better job of either using the full capabilities of the mobile web or providing more transparence through the development of their applications, if at all possible!

The same actually applies to TVs, now that we connected that to the Internet as well :-)

Geekeries du jour

Au menu des geekeries du jour, j'ai enfin résolu les problèmes de WiFi sur mon MacBook. Depuis plusieurs mois, la portée du WiFi sur mon MacBook s'était considérablement dégradée, un peu comme si l'antenne n'était plus branchée. Je ne pouvais donc que très rarement me servir du WiFi sur mon laptop, ce qui était particulièrement handicapant en déplacement, et même dans mon appart où je ne pouvais pas m'éloigner à plus de quelques mètres du routeur.

Après quelques recherches, c'était apparemment un problème connu, mais malheureusement non-résolu par Apple. Une des solutions proposées sur les forums était de remplacer la carte WiFi du laptop. J'ai donc acheté sur eBay une carte WiFi d'occasion pas chère (BCM94321 a/b/g/n) que j'ai reçu un peu plus tard. Le temps d'acheter les tournevis de précision qu'il me manquait, et me voilà enfin en train de démonter des dizaines de vis de tous les côtés pour accéder à la carte WiFi et la remplacer. Magie, l'opération est un succès ! Il s'agissait donc bien de la carte et non de l'antenne (certains utilisateurs mentionnaient des câbles d'antenne sectionnés !), et je peux maintenant à nouveau profiter d'un WiFi fonctionnel, avec le petit bonus de la compatibilité 802.11n.

Autre geekerie du jour, que je note ici pour simple mémoire, concerne sed. Pour remplacer les caractères NUL (\0) dans un flux, il faut utiliser \x0 et non \0 directement :

$ echo "Hello\0world." | sed -e 's/\x0/, /g'
Hello, world.

Notez que ça fonctionne aussi avec \d0 (pour spécifier la valeur en décimal plutôt qu'en hexadécimal, ce qui ne change rien pour 0).

Enfin, Google propose depuis peu des paquets Debian officiels pour Chrome sous Linux. Je teste donc la 4.0.249.30-r33 actuellement, et sans surprise sur une machine quad-core ça avance beaucoup plus vite que ce bon vieux Firefox. Bonus points pour la vitesse du navigateur, sa rapidité générale dans l'interface et le rendu, et pour la présence des extensions. Malus points pour l'absence d'une extension Delicious correcte, et l'absence d'une extension Vimperator (à première vue, si il y en a une faites tourner).

Network autoconfiguration

Network autoconfiguration is considered one of the interesting features of IPv6. But it also exists in IPv4, albeit a lot less used in the real world. I had the opportunity to give it a try a few weeks ago during one of my practical sessions on NxOS at the UTBM to transfer some software archives to the students' laptops, which were of course not all running a GNU/Linux system.

With all the computers on the same network segment, we simply left all computers on automatic addressing via DHCP. Without a DHCP server available, the computers fell back to IP address autoconfiguration, getting a 169.254.x.y address in a /16 subnet. Then, without ever having to wonder about which computer got which IP address, we simply relied on mDNS to get .local names automatically. For more info, take a look at the Wikipedia article on MDNS and Zero configuration networking.

So, only a few seconds after plugging the Ethernet cables, students were able to access http://egg.local/~sam/nxos/ and get all the software they needed. Way faster than using USB sticks, and a very good proof of interoperability through open, recognized standards and technologies, all for a seamless experience!

A faster git branch in your prompt

A little while ago, I posted here a snippet that would add the current git branch (when applicable) into your prompt's display. This snippet used git branch directly, which turned out to be quite slow when entering a git repository in a new shell session, especially large repositories like kernel trees.

Salvaging from Bash's completion for git, a new snippet was put together. Albeit much larger, it is way faster since it directly relies on the files present in the .git/ directory. Here it is, as included in my ~/.zshprompt file:

# For the git branch name in the prompt
function git_ps1 {
  if which git &> /dev/null; then
    local g="$(git rev-parse --git-dir 2>/dev/null)"
    if [ -n "$g" ]; then
      local r
      local b
      if [ -d "$g/rebase-apply" ]; then
        if test -f "$g/rebase-apply/rebasing"; then
          r="|rebase"
        elif test -f "$g/rebase-apply/applying"; then
          r="|am"
        else
          r="|am/rebase"
        fi
        b="$(git symbolic-ref HEAD 2>/dev/null)"
      elif [ -f "$g/rebase-merge/interactive" ]; then
        r="|rebase-i"
        b="$(cat "$g/rebase-merge/head-name")"
      elif [ -d "$g/rebase-merge" ]; then
        r="|rebase-m"
        b="$(cat "$g/rebase-merge/head-name")"
      elif [ -f "$g/MERGE_HEAD" ]; then
        r="|merging"
        b="$(git symbolic-ref HEAD 2>/dev/null)"
      else
        if [ -f "$g/BISECT_LOG" ]; then
         r="|bisecting"
        fi
        if ! b="$(git symbolic-ref HEAD 2>/dev/null)"; then
          if ! b="$(git describe --exact-match HEAD 2>/dev/null)"; then
            b="$(cut -c1-7 "$g/HEAD")..."
          fi
        fi
      fi

      printf "%s" "(${b##refs/heads/}$r)"
    fi
  else
    printf ""
  fi
}

You can then simply add $(git_ps1) to your PROMPT variable definition.

Notes on Django applications internationalization

Yesterday I took a closer look at Django's i18n framework to bring translations to a small web application I'm currently working on. Django's documentation on i18n is, as always, comprehensive and well-explained as long as you take the time to read it entirely. But there are still a few tricks that aren't covered by this documentation and I would like to explain them here for others to find, or else for myself as future reference.

When internationalizing a Django application, there are three main places that need work:

1. the templates, of course, to mark all the strings that need translation;
2. the code, where models and forms field names need to be marked as translatable as well, plus maybe a few other places in your code depending on your application;
3. and finally the locale files where you actually translate everything.
   

In the templates. Marking strings for translation in your templates is fairly easy. You just need to enclose each string with the {% trans "my string" %} tag. This goes well until you start having complex strings with variable values inside them. In this case, you need to use the {% blocktrans %}...{% endblocktrans %} construct, and each variable inside will be replaced by a placeholder for translation. For example, the following block:

{% blocktrans %}
Hello, {{ name }}.
{% endblocktrans %}

Will yield the following string to translate: "Hello, %(name)s." But this is only supported if you aren't going to apply any value filter on your variable. Say you want to convert the name to titlecase, you can't just add the |titlecase filter to your variable there. You need to inform blocktrans of what you're attempting to achieve:

{% blocktrans with name|titlecase as name_t %}
Hello, {{ name }}
{% endblocktrans %}

This is still reasonable. The problems come when you have different formulation depending on the cardinality of a variable to decide if you need a singular or plural form. Normally, you would do something like:

I have {{ money }} euro{{ money|pluralize }}.

But pluralization is a complex problem in internationalization, which can unfortunately only be solved by explicitly having the singular and the plural forms expressed in the template and translated. For this, blocktrans comes again to the rescue, this time in an even less intuitive markup:

{% blocktrans count apples as apples_t %}
There is {{ apples_t }} apple.
{% plural %}
There are {{ apples_t }} apples.
{% endblocktrans %}

This will create the following construct in your .po files:

msgid "There is %(apples_t)s apple."
msgid_plural "There are %(apples_t) apples."
msgstr[0] ""
msgstr[1] ""

Where msgstr[0] is used to translate the singular form, and msgstr[1] is used to translate the plural form. Note that this will only work if you have exactly the same placeholders in both the singular and plural forms, as the same string formatting is applied afterwards, so all placeholder keys must match.

For value filters that include strings, like the |yesno filter, it is still possible to translate the output:

{{ my_boolean|yesno:_("yup,neh") }}

And then providing the translation for the combined string: "yup,neh" in the locale file, for example "ouaip,nan".

In the code. Let alone the few strings here and there you may keep in your code like form validation errors, the main things you need translated are your model names and fields, and your form fields. You probably know that Django infers a lot of information automatically from the model classes names and properties names. Unfortunately, if you want those translated, you will need to specify them yourself.

For the model names, which you probably want translated if you plan on using the administration site, you need to add a Meta class to each one of your models to specify the singular and plural name:

class Apple(models.Model):
    class Meta:
        verbose_name = _('apple')
        verbose_name_plural = _('apples')

Note that these must not be capitalized, as Django will do that itself only when required and you would otherwise have capitalized model names in places you shouldn't.

For field names, you specify them like this:

class Apple(models.Model):
    kind = models.CharField(_('Kind'), max_length=1, choices=APPLE_KINDS)

This may seem redundant, but it's unfortunately required so that Django uses the provided translatable verbose field name instead of the statically inferred one.

In forms, this is very similar:

class EatAppleForm(forms.Form):
    count = forms.IntField(label=_('How many?'))

Now come the tricky stuff. If your model contain a relation, it's likely that you have it showing up it the administration site when editing an object of that type. To get this relation field translated, you need to specify a verbose_name on the relation, too:

class Apple(models.Model):
    kind = models.ForeignKey(AppleKind, related_name='apples',
                             verbose_name=_('Kind'))

Even trickier: you may have defined extra model methods that you use in your templates or in the list_display setting of the administration pages for this model. Here's how to get this translated:

class AppleKind(models.Model):
    ...

    def apples_count(self):
        return self.apples.count()
    apples_count.short_description = _('Apples count')

To find this in Django's documentation, you need to go back to the very first tutorial, and it's not even in an i18n context there.

One last thing about putting these translation hooks in your code. Django provides two methods for translation: ugettext and ugettext_lazy (along with the ungettext/ungettext_lazy versions that support plural forms). The non-lazy versions directly return the translated string, whereas the lazy ones return a lazy object that will provide the translation only when necessary.

The bottom-line is: never use the non-lazy versions in the static parts of your code like model and forms definitions, otherwise these will be set at the server's startup time and will not change even when requesting a language change with the LocaleMiddleware!

Translating the locale files. After placing all the markers for translations in your code and in your template files, you can generate the .po file with django-admin makemessages and start translating, by hand or using a translation tool. On this subject, what is your preferred tool? I tried poedit, which seems fine but segfaults on non supported headers and does not support plural forms. gtranslator works a bit bettor, and has a nice translation memory, but its management of plural form doesn't seem to work either!

All in all, Django's i18n framework is very decent. The i18n helpers from django.utils.translation and the i18n URLs from django.conf.urls.i18n provide a complete solution to easily localize your application. The LANGUAGE_BIDI constant will even tell you if the currently selected locale uses a right-to-left language, which could allow you to output from a different template. Well, that's just one of the joys of i18n/l10n!