Phollow.me

Building and installing Go code

2012-11-05T01:00:00+01:00

So you just installed Go in your system, now you’ll have to create a workspace to work with packages provided by third-parties or making your own ones. A workspace is simply a directory which contains your code, binaries and package objects compiled from it.

Creating the workspace

The workspace can be created anywhere on your system, let’s create it on a directory called golang.

$ mkdir ~/golang
$ export GOPATH=$HOME/golang

We have to set up the GOPATH environment variable to tell golang tools this is where we want our workspace to be.

Writing our first program

Go code resides in the src directory of your workspace. Inside of it we will create our first namespace. Its name should be unique to avoid conflicts with other packages. Let’s create all this and make our first and awesome “Hello World” program.

$ cd ~/golang
$ mkdir -p src/phollow.fr

We want our program to be called hello, so let’s create a hello directory inside our namespace, and then the Go code itself.

$ cd src/phollow.fr
$ mkdir hello
$ cd hello
$ vim hello.go

package main

import "fmt"

func main() {
    fmt.Println("Hello, world!")
}

FYI: there is no real main package, it’s just a convention telling Go you want this code to generate an executable binary.

Now you just have to type go install to let the Go tools compile and install our binary. Every binary is installed inside the bin directory of your workspace.

$ ls ~/golang/bin
hello
$ ~/golang/bin/hello
Hello, world!

Yeah, it’s working. It may be a good idea to put this bin directory on our system PATH: export PATH=$HOME/golang/bin:$PATH. This way we just have to type hello to run our program.

Creating a package

Now let’s create a package. They can be imported in other Go programs and use a different package name, ie. not “main”. We want to make a little function that will double our strings. So we will create a string directory in our namespace and write the code.

$ cd ~/golang/src/phollow.fr
$ mkdir string
$ cd string
$ vim string.go

package string

// Pretty useless I know, it’s just for the sake
// of this example ;)
func Double(s string) string {
    return s+s
}

FYI: you can see that my function begins with an uppercase. This is a convention, telling that this function can be used outside the package itself (you know, like public/private stuff…).

You can check if this function is working by typing go build. No output = no problem. Let’s make this package available to other programs:

$ go install
$ ls ~/golang/pkg/darwin_amd64/phollow.fr
string.a

Great! There it is. As you can see you will find them all in the pkg directory.

Using our new package

Let’s go back editing our hello.go program:

package main

import (
    "fmt"
    "phollow.fr/string"
)

func main() {
    fmt.Println(string.Double("Hello, world!"))
}

$ go install
$ hello
Hello, world!Hello, world!

So basically the Go tools found our package phollow.fr/string and use the string.a and linked it to our hello code. Not really hard.

Bonus: Testing Go code

You can never be sure your code is 100% working without testing it. And good news, there is a build-in tool to do so in Go. What we want to test here is our string.Double() function. A test file resides besides the code and should be named packagename_test.go. So we will go with string_test.go inside the string directory in our namespace.

package string

import "testing"

func Test(t *testing.T) {
    var tests = []struct {
        s, want string
    }{
        {"Hello", "HelloHello"},
        {"Good Bye!", "Good Bye!Good Bye!"},
        {"日本", "日本日本"},
        {"", ""},
    }

    for _, c := range tests {
        got := Double(c.s)
        if got != c.want {
            t.Errorf("Double(%s) == %s, want %s", c.s, got, c.want)
        }
    }
}

$ go test
PASS
ok      phollow.fr/string   0.010s

And now you are ready to build cool stuff with Go!

Un simple serveur de fichiers statiques sous Golang

2012-10-27T16:55:00+02:00

Depuis quelques semaines, je me suis mis à l’apprentissage de Go. Et pour accélérer cet apprentissage je me suis mis en tête de refaire mon serveur de fichiers statiques (celui qui sert les pages de ce blog). Il était fait en Ruby avec Sinatra, j’en parlais ici.

Première version

Go possède déjà pas mal de bibliothèques pour tout ce qui est networking et serveurs. Le module http possède une méthode FileServer qui peut-être utilisée en tant que serveur de fichiers statiques.

package main

import "net/http"

func main() {
    http.Handle("/", http.FileServer(http.Dir("_site")))
    err := http.ListenAndServe(":8000", nil)
    if err != nil {
        panic(err)
    }
}

Seconde version

La première version, aussi simple soit-elle, ne me suffisait pas. Le problème étant lié aux pages 404, Go servant la sienne. Je voulais pouvoir mettre une page customisée. La solution consiste à créer ses propres types et à les wrapper autour des natifs. (Ce n’est pas de l’héritage, Go n’étant pas un langage orienté objet. Ce qui est bien.)

Mon type errorHandle contient juste le type habituel, mais grâce à lui je peux faire ma propre méthode ServeHTTP qui elle utilisera mon type errorWriter. Il contient le type de base ResponseWriter avec en plus un boolean. Je set ce boolean à true quand je détecte un header 404 et je sers ma page customisée à la place.

package main

import (
    "os"
    "net/http"
    "html/template"
)

type errorWriter struct {
    http.ResponseWriter
    ignore bool
}

type errorHandle struct {
    http.Handler
}

func (h *errorHandle) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    h.Handler.ServeHTTP(&errorWriter{w, false}, r)
}

func (w *errorWriter) Header() (http.Header) {
    return w.ResponseWriter.Header()
}

func (w *errorWriter) Write(p []byte) (int, error) {
    if w.ignore {
        return len(p), nil
    }

    return w.ResponseWriter.Write(p)
}

func (w *errorWriter) WriteHeader(status int) {
   if status == 404 {
      w.ignore = true
      w.ResponseWriter.Header().Set("Content-Type", "text/html; charset=utf-8")
      w.ResponseWriter.WriteHeader(404)
      t, _ := template.ParseFiles("_site/404.html")
      t.Execute(w.ResponseWriter, nil)
   } else {
      w.ResponseWriter.WriteHeader(status)
   }
}

func main() {
    fs := http.FileServer(http.Dir("_site"))
    http.Handle("/", &errorHandle{fs})
    err := http.ListenAndServe(":"+os.Getenv("PORT"), nil)
    if err != nil {
        panic(err)
    }
}

Ce bout de code est capable de tourner sous Heroku (et peut-être App Engine). J’ai 2, 3 autres articles sous le feu sur ce langage qui me plaît bien.

Générer son HTML sous Flask avec Jinja2

2012-10-23T20:40:00+02:00

Suite du précédent article sur le développement web avec Python & Flask, nous allons voir comment afficher nos différentes pages. Assembler du HTML tend à être fait avec un moteur de templates. Il en existe plusieurs sous Python, mais nous allons nous intéresser uniquement à Jinja2 étant donné qu’il est fourni de base avec Flask. Bien sûr Flask ne vous force pas non plus à l’utiliser et rien ne vous empêche d’en prendre un autre.

Logique du code dans les templates

Si vous avez déjà utilisé des templates dans d’autres langages, vous savez qu’il faut limiter la complexité du code à l’intérieur de ceux-ci. Les templates proposent des opérateurs de base pour gérer des boucles ou des conditions, et des modules pour transformer l’affichage de certaines variables. Quand vous devez faire quelque chose de complexe, la bonne pratique est de lire déjà la documentation pour voir s’il n’existe pas déjà une fonction pour ça. Ensuite il est toujours possible d’augmenter les capacités de Jinja2 avec un module fait maison. Plus d’infos sur ça plus tard dans l’article.

Toujours est-il que les templates doivent rester simple, de telle manière à ce qu’un designer puisse intégrer vos pages sans trop se poser de questions (no troll).

Usage bas niveau

>>> from jinja2 import Template
>>> template = Template('umad {{ name }}?')
>>> template.render(name='Jérôme')
u'umad Jérôme?'

Voilà en gros le principe. Dans l'utilisation courante on utilisera pas ces méthodes, car on chargera plutôt un fichier .html. Mais c’est ce qui se passe, à peu près, en arrière-plan.

Exemple concret avec Flask

Il faut créer un dossier templates/ à la racine du projet, c’est ici que Jinja2 ira chercher par défaut vos fichiers.

{# projet/templates/layout.html: #}
<!DOCTYPE html>
<html lang="fr">
    <head>
        <title>{% block title %}{% endblock %}</title>
    </head>
    <body>
        <section id="content">
            {% block content %}
            {% endblock %}
        </section>
        <footer id="footer">
            Copyright 2012 etc.
        </footer>
    </body>
</html>

{# projet/templates/index.html: #}
{% extends "layout.html" %}

{% block title %}Le titre de ma page{% endblock %}

{% block content %}
    <h1>Hello World</h1>

    <ul>
        {% for user in users %}
        <li>{{ user }}</li>
        {% endfor %}
    </ul>
{% endblock %}

Et maintenant côté Python:

# projet/app.py:
from flask import render_template

@app.route("/")
def index():
    users = [u"Jérôme", u"Rick Astley", u"Tony Stark"]
    return render_template('index.html', users=users)

Commençons par la fin. On a une route qui pointe sur la racine du site, on crée une liste appelée users contenant le nom de 3 personnes. On demande ensuite à Flask de nous retourner le template index.html en lui passant le contexte (notre liste). Le template index hérite du template layout. L’objet users étant une liste, on peut utiliser une boucle {% for %}{% endfor %} pour itérer. La liste des opérateurs (boucles, conditions…) peut se trouver ici.

Note: Les variables sont par défaut échappées dans Flask. (XSS, tout ça).

Les filtres

Un filtre permet de transformer une variable en la passant dans une fonction. Par exemple couper un texte au bout de X caractères, désactiver l’échappement pour cette variable en particulier, etc.

{# Par exemple mon_titre="mon super titre" #}
{{ mon_titre|title }}
  -> "Mon Super Titre"

Liste des filtres disponibles de base dans Jinja2, ici.

Création d’un filtre custom pour Jinja2

C’est plutôt facile d’augmenter les capacités de Jinja2. Par exemple:

@app.template_filter('cut')
def cut(s, arg="foo"):
    """Enlève certains caractères d’une chaîne de caractères"""
    return s.replace(arg, '')

{# name="foobar" dans cet exemple #}
{{ name|cut }}
  -> "bar"
{{ name|cut("f") }}
  -> "oobar"

Plus d’infos sur cette page et celle-ci.

Documentation

Sur cette page on explique comment Jinja2 est intégré à Flask, avec les variables présentes par défaut et certains filtres ajoutés pour l’occasion. Et voici la documentation officielle du moteur de templates lui-même. Et avec ça, vous devriez pouvoir tout faire :)

Démarrer la création d’un site avec Python et Flask

2012-08-15T01:00:00+02:00

J’avais envie depuis quelques jours de faire une série d’articles sur Python et le développement d’applications web. D’une part pour montrer que ce n’est pas plus compliqué qu’un projet PHP et d’un autre côté pour montrer qu’on perd moins de temps pour faire quelque chose de propre (pas besoin de palier aux bizarreries du langage).

Si vous n’avez jamais rien testé d’autre que PHP comme langage de programmation (back-end), faites-vous une faveur et sortez de votre zone de comfort. Il n’en sortira que du bon, c’est promis.

On va débuter, dans cet article, par mettre en place son projet de la meilleure façon qui soit. Et d’autres articles viendront par la suite pour montrer certains aspects du web-dev (base de données, sessions, templates, tests unitaires, AJAX, cache et optimisations, déploiement…). Le tout surement sur le thème d’une petite application. Je n’ai pas encore trouvé le sujet.

Python

Python existe en ce moment sous 2 versions majeures : 2.X et 3.X. Je vous conseille de dévélopper avec la branche 2.X sauf si vous avez une bonne raison de faire le contraire. La version 3 est en plein développement et beaucoup de bibliothèques Python n’ont pas fait encore le grand saut. La dernière version à l’heure où j’écris ces lignes est la 2.7.3

Installer Python

Python est pré-installé sur Ubuntu, et OS X. Même si ces versions sont suffisantes pour faire tourner les examples de codes que je vais donner, il est préférable d’utiliser une version à jour pour un développement plus sérieux.

Virtualenv

Python possède une quantité incroyable d’extensions/bibliothèques que vous pouvez installer et utiliser dans vos projets. Mais quand on travaille sur plusieurs projets à la fois (et pas forcément que sur du web), on peut arriver à des problèmes de dépendances. Mon projet A nécessite truc en version 1, mon projet B truc en version 2…

Une bonne pratique consiste à créer un environnement virtuel pour nos packages, avec un outil comme virtualenv, de cette manière cet environnement sera complétement indépendant du reste du système.

easy_install virtualenv
virtualenv mon_projet
cd mon_projet
source bin/activate # pour l'activer

Le répertoire mon_projet sera crée avec tout le nécessaire. Si votre prompt change légèrement, c’est que la manipulation a fonctionné. Virtualenv est très puissant, vous pouvez même lui passer la version de Python en paramètre.

virtualenv -p /usr/local/bin/python3.3 mon_projet
virtualenv -p /usr/local/bin/pypy mon_projet

C’est équivalent à ce que l‘on peut trouver chez Ruby avec Bundler. Pour désactiver un virtualenv il suffit de lancer la commande deactivate dans le terminal.

Flask

Flask est un micro-framework et je pense qu’il est du coup beaucoup plus approprié dans l’apprentissage du langage Python. Contrairement à Django qui fait beaucoup de choses tout seul (ORM, validations formulaires, back-end admin…), Flask reste simple et c’est à vous de lui coder/rajouter ces composants à la main (BYOB). On en sort avec un framework flexible où je ne ressens, personnellement, pas de contrainte à travailler avec.

Parmis les avantages de Flask, on retrouve :

Base code minimale, environ 800 lignes.
Très bien testé, environ 1 500 lignes.
Très bonne documentation (plus de 200 pages).
Possède un système de template (Jinja2).
Pousse à coder son application sous forme de services, ce qui est une bonne chose.

Installons Flask avec pip :

pip install Flask

Une fois installé, on va écrire notre premier script. Pour cela on va créer un dossier mon_projet/app et à la racine de ce dossier un fichier mon_projet/app/app.py, comme par exemple :

#!/usr/bin/env python
# -*- coding: utf-8 -*-

from flask import Flask
app = Flask(__name__)

@app.route("/")
def hello():
    return "Hello World!"

if __name__ == "__main__":
    app.run()

Pour tester ce code, il suffit juste de lancer la commande suivante. Et d’ouvrir le navigateur sur l’URL qui sera affichée dans la console.

$ python app.py
 * Running on http://127.0.0.1:5000/

GIT

Et pour faire les choses bien, on va se créer un dépôt GIT et commiter tout ça. Mais avant on rajoute le .gitgnore qui va bien.

venv
*.pyc
.env
.DS_Store

On crée le dépôt, on rajoute les fichiers et on commit avec un message explicite. On peut même rajouter des supers emojis sur Github.

git init
git add .
git commit -m ":sparkles: First commit :sparkles:"

Next step

La documentation de Flask est vraiment bien foutue, à partir de là, si vous êtes intéressé, le quickstart peut vous permettre de débuter rapidement avec le framework. En attendant je réfléchis à la suite de cet article.

Sur l’évolution du CSS et pourquoi ne pas attendre

2012-06-17T00:36:00+02:00

Les variables CSS sont apparues il y a quelques jours dans le dépôt Webkit et devraient être utilisables dans les dernières nightlies de Safari. La norme CSS continue de se doter de fonctionnalités permettant d’avoir un code plus facilement maintenable.

Don’t repeat yourself they said

À l’heure actuelle, sans variables, la duplication de code est inévitable sur des projets de taille moyenne ou plus. Imaginons une palette de 5 couleurs sur un site, si on vous demande d’en changer une sur les 5, vous devez faire un rechercher/remplacer sur les fichiers .css. Alors qu’avec les variables vous n’avez qu’une ligne à éditer.

Syntaxe de la spécification

-webkit-var-foreground: red;
-webkit-var-background: rgb(255, 255, 255);
-webkit-var-fontsize: 1.5em;

color: -webkit-var(foreground);
background-color: -webkit-var(background);
font-size: -webkit-var(fontsize);

La syntaxe est encore trop verbeuse à mon goût—et les préfixes webkit n’aidant pas non plus—on est loin de ce que propose un pré-processeur type Sass :

$foreground: red;
$background: rgb(255,255,255);
$fontsize: 1.5em;

color: $foreground;
background-color: $background;
font-size: $fontsize;

D’autres améliorations sur les sélecteurs

Les sélecteurs CSS v4 sont en cours de draft et devraient permettre eux aussi des choses assez sympathiques. Notamment pouvoir styler le parent d’un sélecteur bien précis.

Ne pas attendre

Le problème c’est qu’il va falloir attendre plusieurs années afin de pouvoir utiliser les spécifications natives sur nos navigateurs courants. Personnellement j’en ai un peu marre de coder du CSS comme dans les années 2000, et si je peux profiter d’ores et déjà d’une aide non négligeable, alors pourquoi pas ?

Je parle bien-sûr des pré-processeurs du type Sass, Less ou Stylus parmi d’autres. Je ne vais pas faire un billet sur leur fonctionnement, j’en ai déjà fait un ici, mais plutôt vous faire part de ce que j’en pense, après avoir utilisé Sass & Compass sur un projet perso.

With great power comes great responsibility

Le reproche que l’on fait souvent à ce type d’outils est la qualité du code produit. Les pré-processeurs ne sont seulement que des outils et ne produisent que ce qu’on leur demande de produire. Si vous lui demandez effectivement de produire de la merde, c’est ce qu’il fera. Il y a deux choses importantes à retenir :

Je ne conseille pas ces outils à des débutants ou à de mauvais intégrateurs. Ou aux psycho-rigides.
Il faut avoir une idée de ce que telle fonction est susceptible de produire, pour ça il suffit de lire la documentation. RTFM.

Si vous êtes plutôt mauvais côté intégration, ces outils ne vous aideront pas, au contraire. Par contre je pense que ça peut rendre quelqu’un beaucoup plus efficace, s’il l’est déjà.

Fausses idées et ignorance

“ J’ai pas envie de rajouter du JS pour interpréter LESS sur mes pages et les alourdir. Hurr durr derp. ” ← Aucun script .js n’est nécessaire en prod, tu compiles un .css et tu utilises le .css, point barre. Le .js est utile (dans le cas de Less) lors du développement pour ne pas avoir à compiler à la main à chaque changements. Et uniquement en développement.
“ J’ai parfois envie de modifier le code .css en live en production ” ← Sérieusement ?
“ En équipe les autres doivent être aussi formés ” ← Je suis d’accord. Il n’y a pas grand chose à apprendre non plus, il suffit de jouer une petite après-midi avec.

Il faut savoir que la plupart de ces fausses idées proviennent de personnes qui n’ont jamais testé l’outil. Un billet intéressant sur ça justement.

Retour sur mon utilisation

J’ai décidé d’intégrer Fake Images Please? en utilisant justement Sass+Compass pour me faire une opinion dessus.

J’ai changé plusieurs fois de palettes de couleurs, de largeur de colonnes pour la grille, de familles de polices… Les variables sont vraiment un gain de temps.
Échelle typographique avec Compass super simple. On définit une taille de base en pixel, avec le line-height associé. Tout est recalculé en ems (taille relative des headings, margin, padding, etc.). Ça c’est ce que je faisais à la main en CSS.
Utilisation d’une grille CSS simplifiée aussi. Dans le sens où au lieu de prendre un framework CSS existant où le nombre et la largeur des colonnes sont souvent pré-définies, ici j’ai utilisé Susy. Tu définis le nombre de colonnes, la taille et cette grid s’adapte à ton DOM (et pas l’inverse qui t’oblige à utiliser leurs classes).
Compilation automatique à chaque changement dans le fichier, donc pas de perte de temps à ce niveau là. Mon fichier .html lui link uniquement le fichier .css compilé final.

TL;DR

Je dirais juste à essayer (essayer concrètement) avant de dire que l’on aime pas. Ces fonctionnalités arriveront tôt ou tard dans la norme CSS. Et il y a beaucoup de temps à gagner si on sait utiliser les pré-processeurs.

Jekyll, Heroku et mon blog

2012-05-20T01:30:22+02:00

La migration du blog vers Jekyll était une première étape nécessaire pour une migration complète vers une solution gratuite – ou presque. Quand le site web n’est plus qu’une collection de fichiers statiques, l’hébergement devient vraiment simple.

Heroku

Heroku est une plate-forme cloud qui peut faire tourner des applications Python, Ruby, Scala etc. Le déploiement d’une app n’est pas plus compliqué qu’un git push heroku master. J’utilise la solution gratuite qui est amplement suffisante pour ce blog. Et si un jour ce blog devient extraordinairement populaire, je pourrai scaler simplement avec ps:scale web=x.

Amazon S3

J’en avais déjà parlé sur l’article précédent, les images et les uploads divers des articles sont tous stockés sur Amazon S3. C’était pour préparer la migration sur Heroku, car on est limité à 100Mo pour une application donné. Une application dont le code source fait 100Mo, c’est déjà énorme je trouve. Et généralement personne ne stocke les uploads d’une app. web dans un sous-dossier de l’application elle-même.

Du coup ça peut me permettre de stocker des trucs vraiment énormes sans avoir de limite (sauf les limites de mon porte-monnaie évidemment). D’un point de vue argent justement, S3 est la seule chose que je paie pour héberger ce blog, et pour info j’en suis à $0.03 depuis le début du mois.

Sinatra

Heroku ne permet pas de déployer juste un tas de fichiers statiques, par contre rien ne nous empêche de développer une application proxy, ici Sinatra, servant seulement à servir ces fichiers. Le code de l’application est simple :

# encoding: utf-8
require 'rubygems'
require 'sinatra'

configure do
  set :public_folder, Proc.new { File.join(root, "_site") }
  # Last modification time for browser cache
  @last_mod_time = Time.now
end

before do
  headers "X-UA-Compatible" => "IE=Edge,chrome=1"
  expires 300, :public, :must_revalidate
  last_modified(@last_mod_time)
end

get '/' do
  send_file('_site/index.html')
end

get '/*' do
  file_path = '_site/' + params[:splat].join('/') + '/index.html'
  if FileTest.exist?(file_path)
    send_file(file_path)
  end
  halt 404
end

not_found do
  send_file('_site/404.html')
end

Le code de l’application a été mise à jour sur le dépôt Github du blog.

Autres solutions

Heroku n’est pas la seule manière d’héberger votre blog à moindre coût. On peut utiliser entre autre :

Les pages Github http://pages.github.com/
Mettre le site en entier dans Amazon S3
Dropbox

CSS3 et polices OpenType

2012-05-15T00:00:32+02:00

Les polices au format OpenType ont pour avantage de prendre en charge un jeu de caractères étendus et offrent plus d’options au niveau de la présentation. Par exemple on peut gérer les ligatures discrètes, les fractions, les petites capitales… Les graphistes ont longtemps été seuls à pouvoir jouer avec ces fonctionnalités, mais savez-vous que vous pouvez faire la même chose avec un peu de CSS3 ?

Exemple des ligatures

Prenons par exemple les ligatures. C’est une des choses que je voulais depuis longtemps et qui est maintenant possible sur une page web. Le but d’une ligature est de rendre le texte plus lisible et plus beau aussi, comme en évitant une transition grossière entre un f et un i. Les ligatures fusionnent deux caractères et le résultat est vraiment considéré comme un seul.

fleurs, fille, off.

Vous devriez voir trois ligatures ci-dessus si votre navigateur supporte ces réglages, sinon vous pouvez toujours allez voir sur cette image.

font-feature-settings

Alors, comment en profiter à l’aide du CSS3 ? Il y a une nouvelle propriété utilisée pour ça qui s’appelle font-feature-settings. Voici le code utilisé pour l’exemple de ce billet.

p {
    -moz-font-feature-settings:"liga=1, dlig=1"; 
    -ms-font-feature-settings:"liga", "dlig"; 
    -o-font-feature-settings:"liga", "dlig"; 
    -webkit-font-feature-settings:"liga", "dlig"; 
    font-feature-settings:"liga", "dlig";
}

Vous avez sûrement remarqué les mots-clefs liga et dlig. Chacun possède une signification propre et active une spécificité OpenType, voici la liste complète :

liga ligatures communes
dlig ligatures discrètes
smcp small-caps, petites capitales
lnum lining-numeral, c’est ce que j’appelle les chiffres minuscules.
onum old-style numeral, les chiffres en mode old-school, par exemple le 1 ressemble un peu à un I.
swsh n les swashs, n étant le numéro de l’index voulu, certaines polices en ayant plusieurs. Ce sont des décorations pour certaines lettres, généralement sur des polices de type script
ss01–20 styleset (01—20)

Plus d’infos : font-feature-settings sur MDN

Support navigateurs

Le support des navigateurs n’est pas encore parfait, néanmoins rien ne vous empêche de l’utiliser à présent. Rien ne changera pour les navigateurs ne supportant pas cette norme, ils verront le texte… comme d’habitude. Les navigateurs supportant cette règle CSS3 sont Chrome, Safari et Firefox sur Mac. Sur Windows, il y a seulement Chrome et Safari d’après mes tests rapides. J’ai pu voir que cela marchait aussi sur Chrome Linux, je n’ai pas testé les autres. Je parle bien-sûr des dernières versions en date de chaque navigateur.

Où trouver des webfonts compatibles ?

C'est là que le bât blesse. Après quelques recherches je me suis rendu compte que le service que j’utilise, Typekit ne prend pas encore en compte cette fonctionnalité. Du moins sur les polices que j’ai essayé. Par contre FontDeck commence à répertorier ce genre de police sous le label Opentype. En allant sur le détail d‘une police, on peut voir les options OpenType gérées. Certaine comme Magenta en possède pas mal !

De Wordpress à Jekyll

2012-05-06T23:00:00+02:00

Cela fait plusieurs mois que j’en avait envie, je l’ai finalement fait ce week-end : une migration complète de mon blog Wordpress vers Jekyll. Vous ne devriez pas voir énormément de différences… Non, la différence est surtout pour moi, l’écriture et la gestion du site.

Je n’étais pas vraiment malheureux avec Wordpress, non. Seulement embêté par certaines fonctionnalités. Par exemple l’édition d’articles est juste infâme, je finissais souvent par utiliser l’éditeur HTML en fait. La performance de Wordpress est minable sans plugin externe (cache), car il fait les mêmes requêtes SQL à chaque pages vues. On ne sait jamais, peut-être que l’article change toutes les 5 minutes ?

Bref, je m’égare en trollant, parlons un peu de cette migration.

Jekyll

Jekyll est un “générateur de sites statiques”, écrit en Ruby. Il y en a d’autres comme Hyde ou Blatter en Python. J’ai essayé Jekyll et Hyde, j’ai trouvé le premier plus flexible, notamment au niveau de la gestion des filtres Liquid customisé et des permalinks.

Pourquoi avoir migré sur un système statique ?

Plusieurs raisons à cela mon bon monsieur.

Gain de mémoire et performances

Ce blog est hébergé sur un petit serveur virtuel. PHP et MySQL étant assez gourmand au niveau mémoire, me passer d’eux est non négligeable avec mes 512mb de RAM.

N’ayant pas énormément de visites, on ne peut pas dire que mes instances PHP travaillaient beaucoup. Mais on ne peut pas battre la performance de pages .html directement servies par Nginx.

Plus simple pour écrire

Sur Wordpress quand tu veux écrire un article, tu dois t’identifier dans l’interface d’administration, chercher le lien pour ajouter un article dans le bordel ambiant, cliquer dessus, et là tu peux commencer à t’amuser. Ah et tu dois être connecté aussi.

Avec Jekyll, mes articles sont de simples fichiers textes en Markdown ou HTML. Je peux écrire et tester le rendu de l’article localement sans avoir besoin d’être connecté aux internets.

Backup

Le site n’est qu’un ensemble de fichiers, donc Git.

Utilisation

Généralement un site basique sous Jekyll ressemble à ça :

.
|-- _config.yml
|-- _includes
|-- _layouts
|   |-- default.html
|   `-- post.html
|-- _posts
|   |-- 2007-10-29-why-every-programmer-should-play-nethack.textile
|   `-- 2009-04-26-barcamp-boston-4-roundup.textile
|-- _site
`-- index.html

_config.yml

Diverses variables utilisées pour la configuration, comme les permalinks, le moteur de rendu Markdown et d’autres choses.

_includes

Généralement des partials que vous pouvez utiliser dans vos templates. Si vous avez plusieurs bouts de HTML qui se répète un peu partout dans vos pages, c’est bon de les factoriser ici.

_layouts

Les templates de vos pages web.

_posts

Vos articles écrits en .html, .markdown ou .textile. Jekyll se basera sur l’extension lors de la compilation.

_site

Après compilation, toutes les pages iront dans ce dossier. C’est sur ce dossier que vous devez faire pointer votre serveur web.

Lancer Jekyll en local

jekyll --server

Migrations

J’avais vraiment envie de garder l’existant, et donc il a fallut trouver des astuces pour la migration. Rentrons dans le vif du sujet.

Bouger le contenu

Pour rapatrier les articles, j’ai utilisé un utilitaire appelé exitwp. Je n’ai pas converti les anciens articles en Markdown pour garder au maximum le rendu qu’avaient les anciens articles (oui parce que Wordpress te rajoute plein de merdes en HTML, qui aurait été viré avec la conversion). Heureusement rien ne m’empêche d’écrire les nouveaux billets autrement.

Wordpress met généralement tout ce que tu uploads dans un dossier. J’ai voulu les mettre sur Amazon pour gagner de l’espace disque. J’ai utilisé cette commande :

s3cmd put --acl-public --recursive --guess-mime-type * s3://phollow

Note sur les commentaires

Avec un site statique tu ne peux plus utiliser un système de commentaires server-side. Du coup on peut se rabattre sur un système comme Disqus ou Livefyre. Important : pour importer les anciens commentaires, il suffit d’installer un de ces systèmes sur Wordpress avant la migration.

Code source

Je mets à disposition le code source de la nouvelle version du site sur Github à cette adresse. Il y a quelques trucs sympas, dont un Rakefile qui permet le déploiement des articles au travers de rsync.

rake deploy

Sass – CSS on fire that sucks less

2012-03-04T21:30:32+01:00

Le css permet de définir des styles au travers d’un langage déclaratif, de sélecteurs, propriétés et valeurs. Le tout saupoudrée d’une notion d’héritage basique. Ce qui peut amener certains problèmes sur le long terme : répétition de code et complexification du fichier CSS où les relations entres nos éléments du DOM ne sont pas forcément claires.

Sass étend les capacités du css en rajoutant la possibilité d’utiliser des variables, des fonctions, l’héritage de sélection… Tout un tas de choses qui permet non seulement de simplifier le code mais aussi, selon moi, de rendre plus logique les feuilles de styles. La structure du dom saute facilement aux yeux.

Installation

On installe sass comme n’importe quelle autre gem Ruby.

gem install sass
sass --watch default.scss
>>> Sass is watching for changes. Press Ctrl-C to stop.
  overwrite default.css

Vous l’avez compris, le fichier est automagiquement compilé en css à la volée grâce à l’attribut watch.

Les 2 types de syntaxes

Il y a deux syntaxes différentes qui n’influent pas sur les fonctionnalités. On va dire que c’est une question de goût. Il y a une version Python-like (sass) qui, historiquement, était la première. La seconde (scss – Sassy CSS) reprend la syntaxe du css. L’avantage de celle-ci étant qu’un fichier .css est aussi un fichier .scss.
La différence se fait par le compilateur sur l’extension.

/* SASS */
section
  margin-bottom: 1em
  .entry
    color: red

/* SCSS */
section {
  margin-bottom: 1em;
  .entry {
    color: red;
  }
}

Imbrication

Principe

Le meilleur moyen d’éviter la répétition est d’imbriquer les sélecteurs entre eux. Dans la suite de l’article je montrerai le code scss et l’équivalent compilé en css.

/* SCSS */
table.hl {
  margin: 2em 0;
  td.ln {
    text-align: right;
  }
}

article {
  header, section { margin-top: 1em }
}

/* CSS */
table.hl {
  margin: 2em 0;
}
table.hl td.ln {
  text-align: right;
}

article header, article section {
  margin-top: 1em;
}

Le sélecteur parent

Pense juste à self ou this comme dans les langages objets, copain. Dans sass on utilise le symbole &.

/* SCSS */
a {
  color: #324567;
  &:hover { color: red }
  display: inline-block;
  line-height: 1.6em;
}

/* CSS */
a { color: #324567; display: inline-block;
    line-height: 1.6em; }
a:hover { color: red }

Media queries

/* SCSS */
#content {
  margin: 0 2.5em;
  @media screen and (max-width: 460px) {
    margin: 0 1.5em;
  }
}

/* CSS */
#content { margin: 0 2.5em; }
@media screen and (max-width: 460px) {
  #content { margin: 0 1.5em; }
}

Les variables

J’ai déjà eu la nécessité de changer une ou plusieurs couleurs dans le thème d’un site. C’est donc X lignes que tu dois modifier. Avec les variables on a pas ce problèmes là, il suffit de définir les couleurs une fois seulement. Les variables dans sass peuvent aussi stocker des tailles, des chaînes de caractères…

/* SCSS */
$link-color: blue;
$link-hover: red;
$pad: 3px;
a {
  color: $link-color;
  &:hover { color: $link-hover; }
  padding: $pad;
}

/* CSS */
a { color: blue; padding: 3px; }
a:hover { color: red; }

@extend

Cet attribut permet de spécifier qu’une classe hérite des propriétés d’une autre. Imaginons que vous ayez une classe .button contenant le style de base d’un bouton sur votre site et une classe .button-submit qui lui aura juste une couleur différente. L’attribut @extend vous évite à mettre dans le dom les 2 classes sur ce bouton mais uniquement la dernière.

/* SCSS */
.button {
  background: blue; color: white;
  padding:0.2em 0.8em;
  border-radius:0.4em;
}
.button-submit {
  @extend .button;
  background: green;
}

/* CSS */
.button, .button-submit {
  background: blue; color: white;
  padding:0.2em 0.8em;
  border-radius:0.4em;
}
.button-submit { background: green; }

Mixins

Les mixins ce sont des bouts de codes que tu peux rappeler ensuite ailleurs dans tes classes. Utiles pour éviter la duplication de codes encore une fois. Des valeurs peuvent être envoyés en paramètres, et celles-ci sont nommées et peuvent avoir une valeur par défaut.

/* SCSS */
@mixin border-radius($amount: 10px) {
  border-radius: $amount;
  -webkit-border-radius: $amount;
  -moz-border-radius: $amount;
}
.msg { @include border-radius(5px); }

/* CSS */
.msg {
  border-radius: 5px;
  -webkit-border-radius: 5px;
  -moz-border-radius: 5px;
}

Autres fonctionnalités

Vous pouvez diviser votre code en plusieurs fichiers et les importer avec @import, ils seront combinés avec la compilation
Des méthodes de calculs sont supportées, vous pouvez additionner, diviser et jouer avec les tailles, couleurs et autres valeurs.
Des opérateurs @if, @else, @else if, des opérateurs de logique and, or, =, ainsi que des boucles @for, @while et @each sont supportés. Mais je suis moins fan de ce genre de pratiques dans un fichier de style.
Des méthodes pour jouer sur les couleurs : plus foncé, plus clair…

Conclusion

Sass peut rendre l’utilisation du css plus sympathique. Si vous voulez en savoir plus je vous conseille de vous rendre sur la page officielle de l’application. Vous y trouverez des exemples et de la documentation sur d’autres fonctionnalités non évoquées ici.

Si Ruby vous rebute, il y a une autre application qui s’appelle LESS et qui fait en gros la même chose, la syntaxe étant un peu différente.

En tout cas une chose est sûre, je vais l’utiliser sur mon prochain projet. Reste à trouver le projet.

Enlarge your police

2012-02-04T22:42:16+01:00

Rien à voir avec les spams de Viagra. Non. Sous ce titre un peu malicieux, je tenais à vous parler d’une chose que je ne supporte plus : les tailles de texte minuscules dans les pages html. Cette impression d’avoir sous les yeux le dictionnaire Édition Larousse en lisant un article de blog.

Pourtant je ne pense pas qu’il soit plus difficile de lire sur un écran que de lire un livre. Il suffit de copier la façon dont les livres mettent en page le texte.

Pour être un peu plus précis, le problème se situe souvent sur le nombre de caractères que contient une ligne de texte. La taille de la police sera donc à priori proportionnelle à la largeur de son conteneur.

Être lu comme on lit un livre

Partons d’un constat simple : je suppose que pour vous aussi il est plus facile de lire un bouquin que de lire pendant pas mal de temps sur votre écran d’ordinateur. Le premier argument pour ça est de dire que c’est l’écran qui fatigue les yeux. Pour moi la vraie raison est la taille minuscule des typos sur le net.

Depuis plusieurs jours j’ai une obsession. Je compare les articles de blog à des livres de ma bibliothèque. Et souvent je vois la même chose : on est largement en dessous des 16px par défaut des navigateurs. À croire que les designers cherchent à mettre le plus d’informations possible dans le moins d’espace possible. Ça peut marcher pour quelques applications web mais pas pour une longue lecture.

Le nombre optimal de caractères par lignes

Tout est une histoire de rythme. Si une ligne est trop longue, le lecteur aura du mal à bien voir où une ligne commence et termine. Ça sera plus difficile de trouver la prochaine ligne sur de long bloc de texte. Pas top pour se concentrer dessus.

Inversement, des lignes trop courtes cassent le rythme de lecture. Elle se retrouve artificiellement accélérée et le lecteur sautera parfois des mots (pouvant être important à la compréhension).

Anything from 45 to 75 characters is widely regarded as a satisfactory length of line for a single-column page set in a serifed text face in a text size. The 66-character line (counting both letters and spaces) is widely regarded as ideal. For multiple column work, a better average is 40 to 50 characters.

— The Elements of Typographic Style Applied to the Web ^*

La bonne pratique est donc d’avoir environ 66 caractères par lignes, en comptant les espaces aussi. Le css avec les media-queries deviennent indispensables sur une page fluide, la largeur des colonnes de texte pouvant changer selon la résolution.
Je dois d’ailleurs améliorer pas mal ça sur mon blog.

Autres considérations

Ne pas hésiter à utiliser des interlignes amples dans vos textes. En utilisant la propriété css line-height avec un coefficient sans unité. Par exemple 1.5 est une bonne base, à ajuster suivant la police.

Les nouveaux paragraphes doivent être bien marqués. On peut utiliser des lettrines, de l’indentation, un pied-de-mouche (❡) ou simplement un saut de ligne.

Éviter la justification sur des colonnes de textes minces. Mais généralement la justification sur le web ne fonctionne pas. À cause du support des césures encore aléatoire, du manque de crénage (kerning) automatique et des ligatures (on y vient avec Firefox ^†).

Enfin les polices serifs facilitent la lecture. Boudées pendant un temps à cause des résolutions assez basses de nos écrans, elles sont parfaitement utilisables de nos jours.

Conclusion

Voilà pourquoi j’ai augmenté la taille du texte ici. Si votre navigateur à une taille de police de 16px par défaut, alors ce texte devrait faire 20px. Et si vous avez lu mon article jusque ici, j’aurai gagné une partie de mon pari.

Et promis j’arrête de vous faire chier avec la typographie avant un bout de temps.

❧

^* Une lecture que je conseille fortement, plein de conseils et de bonnes pratiques sur la typographie adaptée à l’usage du web – source
^† Using OpenType font features with CSS 3: Part 1 – source

Mes polices web préférées [sans-serif]

2011-11-30T13:35:38+01:00

Après un premier article sur les polices de types serif, je continue sur ma lancée avec cette fois-ci les sans-serifs. Ce type de police n’a pas d’empattements, d’où leur nom. En français on les appellent aussi polices linéales. Elles ont été longuement privilégiées pour le corps de texte sur les écrans, car à l’époque les écrans analogiques et la basse résolution ne rendaient pas l’affichage d‘une serif optimale. La nature simple des polices linéales fait qu’elles sont mieux lisibles sur ce type d’écran. De nos jours avec nos écrans LCD, l’antialiasing etc., ce n'est plus vrai je trouve.

Aujourd’hui je vais donc vous montrer quelques polices sans empattements que je trouve plutôt cool. Donc si vous en avez un peu marre d’Helvetica ou d’Arial, n’hésitez pas à les tester. Ces fonts ont été trouvés, à l’image de l’article précédent, sur Typekit.

LFT Etica Web & PT Sans

LFT Etica Web est une police moins froide que ces consoeurs, presque de type humaniste. Elle se décline sous 16 graisses/styles différents et peut être utilisée pour du texte ou des headings.

PT Sans est une font au look moderne et humaniste. Là encore, elle possède plusieurs familles et styles et peut donc s’adapter à l’usage. Par exemple la famille caption sera utilisée pour les petits textes.

Sur le site web de Joni Korpi, on peut voir l’utilisation de ces deux polices. Avec LFT Etica Web pour les titres et PT Sans pour le corps de texte.

Proxima Nova

Proxima Nova (2005) est une refonte complète de Sans Proxima (1994). Les six polices originales (trois poids avec italique) ont été élargies à 42 polices OpenType complet. Proxima Nova chevauche l'écart entre les fontes comme Futura et Akzidenz Grotesk. Le résultat est un hybride combinant des proportions humanistes avec un aspect un peu géométrique.

FF Dagny Web Pro

En 2002, le journal suédois Dagens Nyheter (DN) a migré du format broadsheet vers un format tabloïde. Le changement au format tabloïde a rendu le cadre plus compact et Pangea a été mandaté pour produire un correspondant sans-serif pour le journal Suédois. Cela est devenu DN Grotesk, qui a maintenant évolué en FF Dagny. Conçu par Örjan Nordling et Söderström Göran.

Myriad Pro

Myriad Pro, un grand classique d‘Adobe est aussi disponible sur Typekit. 10 fonts au total (5 graisses différentes).

Principalement utilisée sur ce site pour le corps de texte et quelques headlines.

Ratio

Ratio est disponible en 6 graisses allant de minces à lourdes avec les italiques pour chaques. Que ce soit sur papier ou sur écran, Ratio ajoute un niveau de sophistication et de polyvalence qui fait ressortir le meilleur dans n’importe quel design.

Disponible aussi sur Typekit, avec la variante Ratio Display.

Et voilà. Ce n’est qu’un petit échantillon des polices disponibles pour font-face, à l’heure où j’écris ces lignes, je compte plus de 140 sans-serifs sur Typekit. Pour le prochain article, je prépare une collection de slab-serifs.

7 frameworks CSS pour développer en Responsive Web Design

2011-11-21T13:51:19+01:00

Je commence une série d'article à propos d'outils permettant de faciliter le développement d’un site internet responsive, s’adaptant dynamiquement à la taille de l’écran du média. Dans cet article, je vais parler uniquement de tout ce qui a un rapport avec le CSS. En particulier des grids et des templates CSS.

320 and up

320 and up est un template basé sur HTML5 Boilerplate et la grid de Less Framework 4.

320 and up

1140 CSS Grid

1140 CSS Grid se base sur la résolution d’un moniteur de 1280 de large, et se réduit de manière fluide sur les plus petites résolutions.

1140 CSS Grid

Less Framework 4

Less Framework 4 permet de construire des sites web qui s’adaptent aux différents devices grâce à 4 templates et 3 pré-réglages typographiques.

Less Framework 4

Mobile Boilerplate

Mobile Boilerplate est une collection de CSS, HTML et diverses bibliothèques Javascript permettant de bien démarrer un projet web mobile.

Mobile Boilerplate

Skeleton

Skeleton contient une grille CSS et un style de base (typographie, formulaire, boutons…) pour commencer un projet.

Skeleton

Golden Grid System

Golden Grid System : Pour moi une des grilles adaptatives les plus propres. L’avantage de celle-ci est qu’elle conserve plusieurs colonnes tout le temps, même au format mobile.

Golden Grid System

The Semantic Grid System

The Semantic Grid System est intéressante dans le sens où c’est vous qui choisissez le nombres de colonnes, la taille des marges etc.

The Semantic Grid System

Je vous conseille aussi de ne pas hésiter à modifier ces divers frameworks pour votre utilisation. Par exemple le thème de ce blog tourne sur une version modifiée de Skeleton — j’ai rendu la grille fluide – et les bibliothèques Javascript de 320 and up.

En regardant le code de ces projets vous allez avoir une meilleure vision de ce qui se passe avec les media queries. Et ainsi adapter leurs fonctionnements à votre propre projet.

Si vous en connaissez d’autres, n’hésitez pas à en parler aux gens avec les commentaires.

Homebrew, un gestionnaire de paquet pour Mac OS/X

2011-11-01T20:12:51+01:00

Quand on a pris la bonne habitude de travailler sous un environnement Unix, il y a certains outils qui vous manquent cruellement quand on se retrouve par exemple sur Mac OS/X. Ce système d’exploitation ne possède pas de gestionnaire de paquet comme apt-get sous Debian ou yum sous CentOS. Il existe heureusement des solutions, comme par exemple Macports. J’en avais parlé sur ce billet il y a quelques temps déjà.

Aujourd’hui j’utilise un autre gestionnaire de paquet s'appelant Homebrew. Il se veut plus simple que Macports et diffère un peu dans sa manière de faire. Pour faire simple Homebrew va toujours essayer d'utiliser les librairies déjà sur le système pour compiler nos paquets. Cette manière de procéder possède des avantages et des inconvénients. L'avantage c'est que pour compiler un paquet, on ne va pas devoir compiler X librairies avant. L'inconvénient c'est que nos exécutables risquent grandement de planter après une mise à jour de l’OS ; les librairies de Mac OS/X étant mises à jour.

C'est donc un choix à faire. Et j’ai choisit Homebrew car je n'ai pas non plus 50 paquets à maintenir, une vingtaine tout au plus, et je ne mets pas mon système d’exploitation à jour tous les quatre matins.

Pré-requis

Il faut savoir que par défaut il n’y a pas les outils de compilation dans Mac OS/X. Alors on va devoir installer gcc et ses potes, et ça se fait simplement en installant Xcode. Pour certains paquets vous allez peut-être avoir besoin du « Java Developer Update ». On peut trouver ce qu’il faut sur cette page.

Installation

L'installation à proprement parler du gestionnaire de paquets peut maintenant commencer. Homebrew est écrit en Ruby et son script d’installation aussi.

/usr/bin/ruby -e "$(curl -fsSL https://raw.github.com/gist/323731)"

Il va faire son nid dans /usr/local, ce qui nous permettra d’installer des paquets sans passer par sudo. De plus cet endroit est assez indépendant du système, on pourra donc facilement tout enlever si besoin. Il est bien sûr toujours possible de mettre tout ça ailleurs si vous préférez.

Et ensuite on peut RTFM

J'admets avoir la flemme de tout vous expliquer, mais franchement il suffit de lire.

Pour avoir la liste complète de ce qu’il est possible d’installer, on peut se rendre sur GitHub, sur cette page. À savoir que vous pouvez créer vos propres formules et la proposer à la communauté si vous voyez un manque. Homebrew m’a servi pour installer quelques paquets toujours pratiques comme git, ffmpeg, x264, mongodb, redis, htop, wget…

Site web de Homebrew.

Mes polices web préférées [serifs]

2011-10-23T22:04:59+02:00

Le marché des « web fonts » ne s'est jamais aussi bien porté. Et son avenir le semble tout autant. La quantité et la qualité des polices croissent tous les jours et avec l'aide des services comme Adobe Typekit et Google WebFonts, l'intégration est simple.

Le processus de création d'une police pour le format web est moins simple que l'on peut le penser au premier abord. Il ne suffit pas de prendre une simple .ttf et de la convertir au format @font-face. La police doit être retravaillée complètement pour être lisible sur les différents OS/Navigateur. Un processus appelé en anglais « hinting » et très bien expliqué ici et là par Typekit. Les grandes fonderies travaillent donc à convertir leurs grands classiques au format web, pour mon plus grand plaisir ! J'ai donc décidé dans cet article de vous présenter ma série de polices web préférées du moment, en me concentrant uniquement aujourd'hui sur la famille des serifs. Vous l'aurez compris d'autres articles viendront plus tard dans le même style.

FF Meta Serif Web Pro

Cette police a été créee en partant de la version sans-serif de base (FF Meta). Elle a été développée en 3 ans par 3 designers Erik Spiekermann, Christian Schwartz & Kris Sowersby.

Fig. 1: Le blog personnel de Trent Walton utilise cette police à 100%. Elle rend bien à n'importe quelle taille que ça soit pour les paragraphes ou les headings grâce notamment à son « x-height » élevé.

Adobe Minion Pro

Une police Adobe désignée par Robert Slimbach dans les années 90. Elle a le style des polices utilisées dans les livres pendant la Renaissance. Minion est élégante et très lisible.

Fig. 2: Le blog de Rob Weychert l'utilise dans ces paragraphes.

FF Tisa Web Pro

Dessinée par Mitja Miklavčič pour l'usage dans des magazines modernes. Un « x-height » large et des serifs prononcés améliorent la lisibilité. Et je trouve vraiment la version italique jolie.

Fig. 3: Dan Cederholm l'utilise dans les paragraphes de ces articles.

Skolar Web

Skolar, la police primée conçue par David Březina, est une serif qui a été désignée à l'origine pour des publications savantes et multilingues. La police maintient sa crédibilité tout en incorporant un style subtil personnel.

Fig. 4: Elliot Jay Stocks utilise cette police à toutes les sauces. Dans les paragraphes ou les titres en majuscules avec un letter-spacing etc.

FF Scala Web

FF Scala is an old style, humanist, serif typeface designed by Dutch typeface designer Martin Majoor in 1990 for the Vredenburg Music Center in Utrecht, the Netherlands. The FF Scala font family was named for the Teatro alla Scala (1776–78) in Milan. Like many contemporary Dutch serif faces, FF Scala is not an academic revival of a single historic typeface but shows influences of several historic models. Similarities can be seen with William Addison Dwiggins' 1935 design Electra in its clarity of form, and rhythmic, highly calligraphic italics. Eric Gill's 1931 typeface Joanna (released by Monotype in 1937), with its old style armature but nearly square serifs is also similar in its nearly mono-weighted stroke width.

— Wikipedia, source

C'est la police que j'utilise dans les paragraphes de ce blog. J'aime beaucoup les détails calligraphiques. Il existe plusieurs familles dont une condensée et une « small-caps ». Et aussi une version sans-serif. Toutes ces fonts sont disponibles sur Typekit.

C'est d'ailleurs ce service que j'utilise, parce que c'est là où toutes les polices professionnelles se trouvent. J'ai testé un peu Google WebFonts et à vrai dire je n'en trouve pas beaucoup de bonne qualité. À part peut-être la famille de fonts Droid ou Lobster la nouvelle Comic Sans de nos chers designerfags en herbe — Mais c'est cool ça fait retro ! — Bref je m'égare, je garde ma haine pour la mauvaise utilisation de Lobster dans un article à part.

Les césures dans le web

2011-10-10T23:59:14+02:00

En typographie, la césure est l'art de couper un mot de telle manière à ce qu'il entre dans la justification. Cette pratique est utilisée dans les livres et depuis peu de temps possible aussi sur le web.

On a inventé ce système pour pouvoir mettre plus de mots sur une page donc économiser du papier à l'imprimerie et améliorer la justification. Même si on n'utilise pas de papier sur le web, on peut toujours gagner de la place et améliorer l'aspect général de la typographie.

Parfois les textes justifiés sont vraiment horribles sur les pages web, avec des rivières monstrueuses. Les césures améliorent nettement ça, donc passons maintenant au code.

Nouvelle méthode CSS3


p {
    hyphens: auto;
    -webkit-hyphens: auto;
    -moz-hyphens: auto;
}

À l'heure où j'écris ces lignes, les navigateurs supportant ces propriétés sont Firefox 6+ et Safari 5.1+. Pour les désactiver il suffit de passer auto en manual. En mode manuel, les  sont néanmoins toujours respectés.

Les césures ont des règles strictes d'utilisation, règles changeant suivant la langue. Le navigateur doit savoir dans quelle langue vous écrivez, donc vous devez la renseigner. Un lang="fr" dans la balise <html> suffit par exemple.

Hyphenator

Cette bibliothèque javascript permet d'activer les césures sur tous les navigateurs supportant le « trait d'union conditionnel ». Ce caractère  est invisible quand on le place mais il sert à déterminer l'endroit où une césure peut avoir lieu.

L'avantage de ce script est qu'il privilégie l'utilisation de la méthode CSS3 sur les navigateurs la supportant.

http://code.google.com/p/hyphenator/

Examples

Les paragraphes de mon blog devraient maintenant tous fonctionner avec ce système de césures — depuis la mise à jour du thème en fait — et donc vous devriez les voir sur cet article (et les autres) — à condition d'avoir un navigateur assez récent, mais je ne me fais pas de soucis pour vous.

CSS Multi-Columns

2011-10-07T00:28:43+02:00

Qu'est-ce que c'est ?

Le module CSS multi-colums permet de diviser un long flux de texte en plusieurs colonnes de manière automatique. Et donc nous n'avons pas besoin, par exemple, pour 3 colonnes de créer 3 conteneurs. Cette technique est beaucoup utilisée dans les journaux ou les magazines mais encore très peu sur le web.

Ainsi de larges blocs de texte peuvent être divisés facilement en sous-colonnes pour offrir une meilleure lecture et améliorer l'esthétisme d'un site. C'est un avantage aussi d'un point de vue sémantique, car on se passe de balises supplémentaires nécessaires pour avoir le même rendu sans CSS3.

D'un autre côté la lisibilité d'un site peut être complètement ruinée avec une mauvaise utilisation de ce module. Un site web n'étant pas forcément statique comme le serait la page d'un magazine. Par exemple l'utilisateur ne doit pas avoir à scroller quand il lit la fin de la colonne et passe à la suivante.

Compatibilité des navigateurs

Opera 11.10+, Opera Mobile 11.10+
IE 10+
Firefox 3.6+
Safari 3.2+
Chrome 10+

Utilisation

Il y a deux façons de créer des colonnes, on peut d'une part spécifier un nombre fixe de colonnes à l'aide de la propriété column-count ou alors spécifier la largeur des colonnes à l'aide de column-width (pixels ou ems, mais pas de pourcentage…). Les deux propriétés peuvent être cumulées, mais le navigateur choisira l'une ou l'autre suivant les cas. Il existe bien sur d'autre propriétés :

column-gap pour gérer l'espacement entres les colonnes
column-rule, column-rule-width, column-rule-style, column-rule-color pour gérer l'apparence de la séparation des colonnes
break-before, break-after, break-inside permet par exemple de forcer le passage d'un élément sur la colonne suivante. Plus d'infos sur le site du w3c.

Exemples

Séparation en deux colonnes

Now that we know who you are, I know who I am. I'm not a mistake! It all makes sense! In a comic, you know how you can tell who the arch-villain's going to be? He's the exact opposite of the hero. And most times they're friends, like you and me! I should've known way back when... You know why, David? Because of the kids. They called me Mr Glass.

Do you see any Teletubbies in here? Do you see a slender plastic tag clipped to my shirt with my name printed on it? Do you see a little Asian child with a blank expression on his face sitting outside on a mechanical helicopter that shakes when you put quarters in it? No? Well, that's what you see at a toy store. And you must think you're in a toy store, because you're here shopping for an infant named Jeb.

Now that there is the Tec-9, a crappy spray gun from South Miami. This gun is advertised as the most popular gun in American crime. Do you believe that shit? It actually says that in the little book that comes with it: the most popular gun in American crime. Like they're actually proud of that shit.

Look, just because I don't be givin' no man a foot massage don't make it right for Marsellus to throw Antwone into a glass motherfuckin' house, fuckin' up the way the nigger talks. Motherfucker do that shit to me, he better paralyze my ass, 'cause I'll kill the motherfucker, know what I'm sayin'?

Well, the way they make shows is, they make one show. That show's called a pilot. Then they show that show to the people who make shows, and on the strength of that one show they decide if they're going to make more shows. Some pilots get picked and become television programs. Some don't, become nothing. She starred in one of the ones that became nothing.

Code

div.twocol {
  column-count: 2;
  column-gap: 20px;
  -moz-column-count: 2;
  -moz-column-gap: 20px;
  -o-column-count: 2;
  -o-column-gap: 20px;
  -webkit-column-count: 2;
  -webkit-column-gap: 20px;
}

Séparation en trois colonnes + style

The path of the righteous man is beset on all sides by the iniquities of the selfish and the tyranny of evil men. Blessed is he who, in the name of charity and good will, shepherds the weak through the valley of darkness, for he is truly his brother's keeper and the finder of lost children. And I will strike down upon thee with great vengeance and furious anger those who would attempt to poison and destroy My brothers. And you will know My name is the Lord when I lay My vengeance upon thee.

Your bones don't break, mine do. That's clear. Your cells react to bacteria and viruses differently than mine. You don't get sick, I do. That's also clear. But for some reason, you and I react the exact same way to water. We swallow it too fast, we choke. We get some in our lungs, we drown. However unreal it may seem, we are connected, you and I. We're on the same curve, just on opposite ends.

Normally, both your asses would be dead as fucking fried chicken, but you happen to pull this shit while I'm in a transitional period so I don't wanna kill you, I wanna help you. But I can't give you this case, it don't belong to me. Besides, I've already been through too much shit this morning over this case to hand it over to your dumb ass.

Code

div.threecol {
	column-count: 3;
	column-gap: 10px;
	column-rule-color: #ccc;
	column-rule-style: dotted;
	column-rule-width: 2px;
	-moz-column-count: 3;
	-moz-column-gap: 10px;
	-moz-column-rule-color: #ccc;
	-moz-column-rule-style: dotted;
	-moz-column-rule-width: 2px;
	-o-column-count: 3;
	-o-column-gap: 10px;
	-o-column-rule-color: #ccc;
	-o-column-rule-style: dotted;
	-o-column-rule-width: 2px;
	-webkit-column-count: 3;
	-webkit-column-gap: 10px;
	-webkit-column-rule-color: #ccc;
	-webkit-column-rule-style: dotted;
	-webkit-column-rule-width: 2px;
}

Conclusion

La propriété CSS multi-columns se dégrade assez naturellement sur les navigateurs qui ne supporte pas encore la spécification. On voit simplement qu'une seule colonne. Pouvoir gérer ce genre de layout sans avoir recours à des scripts quelconque est vraiment pratique. À l'heure où les designers donnent de plus en plus d'importance à la lisibilité du contenu, je pense qu'on en verra un peu plus d'ici quelques temps.

P.S. : Vous avez reconnu les citations des exemples ?

Réf. : Spécifications

Un exercice sur le Responsive Web Design

2011-08-28T18:44:28+02:00

Mon blog est maintenant responsive. Terme que l'on peut traduire à l'arrache par qui répond bien. Le thème et le contenu va automatiquement s'adapter à la taille de l'écran. Le concept est intéressant et plus pratique que de faire un thème normal + un thème mobile par exemple. À l'heure actuelle les sites internets ne sont plus seulement affichés sur un ordinateur mais de plus en plus souvent sur des appareils de type mobile, smartphones ou tablettes.

S'adapter

Au début on avait pas énormément d'appareils exotiques en dehors du desktop. On voyait souvent un sous-domaine dédié à l'affichage d'un site sous iPhone, avec un thème propre. D'un point de vue conception on était tranquille, le thème mobile était indépendant du thème principal, et on connaissait les contraintes de l'iPhone. Mais maintenant on a beaucoup plus de smartphones et même des tablettes, chaque appareil possédant sa propre résolution. Et là on se rend compte que faire un thème dédié pour chacun de ces appareils est une idée complètement idiote. Donc le site web doit s'adapter.

Bonjour media query

Vous les avez déjà utilisées. Mais si, media="print" pour avoir un CSS dédié à l'impression par exemple. C'est pas nouveau, ça date de la norme CSS 2.1. Ce qui est nouveau se sont les ajouts de la norme CSS3. Des ajouts nous permettant de tester la résolution de l'écran, le type de device etc.

Si l'appareil à une résolution inférieure ou égale à 480px en largeur, le fichier mobile.css sera lu. L'attribut @media du CSS permet de faire la même chose sans avoir à le faire dans la balise <link>.

Par exemple sur ce site quand la résolution devient petite, j'enlève la sidebar sur la gauche pour la placer en dessous du contenu. C'est ce que permettent de faire les media queries. On peut imaginer faire disparaître certains éléments qui n'auraient par leur place sur un petit écran, avec un display:none; par exemple.

Les media queries de ce type ne fonctionnent que sur les navigateurs récents et sur la plupart des navigateurs mobiles (webkit, opera). Il y a donc un script js que j'utilise pour certains navigateurs (Oh hai, Internet Explorer). Vous pouvez le trouver sur cette page.

Responsive Grid

Pour me faciliter le travail j'ai utilisé une Grid CSS réactive. Construite sur les media queries, les différents blocs peuvent se ré-agencer suivant la taille de l'écran. Voici une liste non-exhaustive

FitText

FitText.js est un plugin jQuery permettant de rendre les tailles de polices flexibles. Je l'utilise pour certains headers. Ce plugin va les redimensionner par rapport à la taille du conteneur. Pratique.

Thème Phollow

Je met en ligne la source du thème Wordpress actuel sur Github pour les personnes intéressées. Vous pouvez le trouver sur cette adresse. Les forks sont fortement encouragés.

Pour moi il est maintenant obligatoire de travailler sur des sites qui fonctionnent sur n'importe quelles resolutions que sur des sites qui fonctionnent sur les résolutions des appareils actuels.

Wallpapers of the Week

2011-08-08T12:04:10+02:00

Wallpapers of the Week : 8 août 2011.

NY state of mind vs LA state of mind

green...ish? by ~liqui Grape Leaves by ~Zim2687 Icewind Dale by *IrvingGFM Suong Dem by =kAtz93

Mockups des futures versions de Firefox 7 & 8 — Mac, Windows

2011-08-04T21:15:20+02:00

La team des designers Firefox ne cesse de rechercher à améliorer l'ergonomie du navigateur. Et aujourd'hui ils nous proposent des mockups de ce que pourrait ressembler les futures versions de Firefox 7 ou 8. Firefox 4 avait déjà vu son interface grandement changée, l'histoire risque encore de se répéter — et c'est tant mieux !

Ces mockups ne seront pas forcément une image exacte des versions finales. Ils ont été réalisés avant tout dans une optique de recherche et de discussions. On peut voir sur ces premiers écrans la disparition de la barre de recherche, que j'avais déjà enlevé personnellement la trouvant inutile, un nouveau style de menu et un mode plein-écran qui a l'air plutôt sympathique.

Comme d'habitude ces expérimentations sont ouvertes et disponibles pour ceux qui veulent les tester. Mozilla a crée un nouveau build appelé Australis et téléchargeable à cette adresse. Ce build est une nightly, donc tous les jours une update pourra être téléchargée. La team UX Firefox déclare que c'est sur cette version que seront déposé leurs différents tests.

Maintenant je vais faire mon community manager en vous demandant ce que vous pensez de ces premiers concepts ? Pour ma part ça me plaît beaucoup même si on voit encore que Chrome a pas mal inspiré nos designers.

Via Mozilla

Dotshare.it, partage de .dotfiles

2011-07-27T12:45:31+02:00

Je joue beaucoup avec les dotfiles – ces petits fichiers cachés qui servent généralement à configurer un programme. Si vous aimez justement personnaliser votre système, vous en avez sans doute ouverts déjà pas mal. C'est là ou rentre en jeu Dotshare.it, un site web que l'on ma présenté il y a quelques temps.

Généralement il y a toujours un thread Post your screenshot and configs sur les différents forum des distributions *nix. La config était généralement collée à l'arrache en dessous. Pas pratique pour les retrouver plus tard. Certains utilisent Github, ce qui me semble déjà une bonne évolution mais encore à un niveau en dessous de Dotshare, qui lui est fait seulement pour ça.

Dotshare.it veut donc faciliter le partage et la recherche de fichiers dotfiles. Ils sont triés par applications, avec une capture du résultat. On peut aller chercher tous les fichiers d'un utilisateur en particulier sur sa page profil, suivre cette personne pour être alerté des updates etc.

Le look du site web est minimaliste et c'est une bonne chose. Ça ne devrait pas trop piquer les yeux des adeptes des CLI tools. L'information est bien présentée et l'essentiel est là. Il y a même des petites références au monde de la ligne de commande, comme scrot pour voir la capture du logiciel.

On a donc tout pour avoir un joli petit réseau social pour le partage des fichier de conf. Unix. Reste à voir si les gens vont suivre. Si vous avez des recommendations ou des demandes à faire aux devs vous pouvez toujours allez faire un tour sur #dotshare at freenode.

Via dotshare