out through the winter throat

out through the winter throat le blog de Anahkiasen.

Redesign de mon portfolio

Mardi 4 décembre 2012 à 16:08

Redesign de mon portfolio

J’ai je l’avoue une habitude assez superficielle — et peut-être partagée par d’autres dans ma profession — quand je commence à m’adresser à quelqu’un qui fait mon métier, la première chose que je fais c’est cliquer sur le lien de leur site. Je jette un œil aux sources, et de là la critique vient vite.
Ce n’est pas logique je l’avoue car même moi qui suit très au courant de tous les bons codes et pratiques en terme de webdesign, je n’ai pas toujours encore le temps ou les moyens de tout mettre en œuvre. Mais certaines choses ne passent pas, comme les sites qui lient treize feuilles CSS et douze Javascript; du code non sémantique bourré de tirs croisés entre présentation et contenu; des designs soit ni fluides, ni reponsive, soient pseudo-proclamés mobile-friendly mais qui balancent à l’utilisateur des pages de 24 mégas.

Le double-tranchant c’est que d’autres s’adonnent aussi à cela et que dans des discussions houleuses, mon portfolio personnel donnait une bien triste image de moi professionnellement. J’ai fait mon portfolio peu avant de sortir de l’école, avant même de trouver mon premier emploi (que j’occupe toujours). À l’époque ayant seulement des bases en web et étant plus tourné vers le graphisme, j’avais fait ça vite fait, tout en pages statiques et n’y avait plus touché depuis.
Les années passant, j’étais dans un premier temps fier de montrer mon portfolio, puis progressivement gêné, et enfin honteux. Du coup j’ai mis un bon coup de collier, je me suis retroussé les manches, et je m’y suis enfin mis.

Penser device-agnostic

Avec l’explosion du mobile, et désormais des tablettes — pire, des frigos, des voitures, et j’en passe — tout le monde va sur internet, tout le temps. Dans ce contexte il est devenu de plus en plus complexe de faire des sites en gardant en tête les anciens préceptes et méthodes où l’on faisait de jolis sites de 960px de large sur Photoshop. Ce temps est révolu tout simplement car le web est désormais flottant, il n’est plus uni, c’est un bazar de centaines de hardware différents, chacun avec leurs tailles d’écran, leur capacités propres, et j’en passe.
De là est né le responsive design — altérer la feuille de style à des points clés pour adapter, masquer, afficher, réorganiser les blocs fondateurs à mesure que l’espace disponible varie. Ça a bien vite tourné malheureusement à la foire de l’Apple où si ça marchait sur iPad et iPhone, alors on considérait que ça marchait partout (ce qui est bien sûr complètement con). Le design device-agnostic c’est celui qui se réadapte quand il se casse, non par rapport à d’éventuels téléphones ou tablettes existants, garantissant que le site est préparé à tout ce qui sortir dans les années à venir. Et à la vitesse où ça va c’est la moindre des choses.

Don’t define your breakpoints according to some device, define your breakpoints when your design breaks

J’ai refait mon design pour qu’il s’adapte en conséquence de l’espace disponible. J’avoue être encore parfois coupable d’employer des largeurs assez peu agnostiques, en particulier sur ce portfolio. Utilisant des helpers SASS qui me restent, les breakpoints majeurs sont encore dans la veine des 768px et autres.



Le design est entièrement (à trois poils près) structuré par des unités non fixes comme des pourcentages bien évidement, mais aussi em et rem. Pour ceux à qui ces deux unités sont inconnues, l’em est une unité variable dépendant du corps du bloc sur lequel il est appliqué. Plus concrètement, au sein d’un paragraphe ayant un corps de par exemple 16px, 1em == 16px.
Mon idéal était de calculer toutes mes marges, hauteurs, corps etc en em qui cascaderaient depuis le corps général du site. Le problème c’est que dès qu’on travaille par exemple sur des titres, la valeur d’un em change radicalement et tout s’emporte.

Entre alors en jeu l’unité rem ou root em qui dépendent en toute situation du corps du site.
Ainsi un rythme vertical est maintenu, et comme toute le design est en SASS, un simple changement du corps du site cascade sur tous les blocs du site et leurs marges. J’ai pu ainsi aisément rendre le texte un poil plus grand sur mobile simplement en changeant la taille de corps à la racine.

html {
  font-size: 100%;
  line-height: 1.5em; }

@media (max-width: 768px) {
  html {
    font-size: 112.5%; }
}

SASS et Compass m’ont aussi permis d’implémenter des _fallbacks_ aux rems pour les anciens navigateurs, vu que Compass connaît le corps du site, il peut aisément faire les calculs correspondants.

myblock
  +rem(margin, 1rem 0.5rem)

// Génère
myblock {
  margin: 16px 8px;
  margin: 1rem 0.5rem;
}

Propre, net, les navigateurs qui savent lire le rem le lisent, les autres l’ignorent et gardent la dernière chose qu’ils comprennent : les pixels.

En web depuis un certain temps il y a deux grands principes : la dégradation gracieuse (graceful degradation) et être préparé au futur (future-proof).
Ce qui risque de se casser doit le faire de manière gracieuse et ne doit pas altérer l’expérience de l’utilisateur sur un site.
Ce qui est déjà en place doit être préparé aux futures évolutions du web et ne doit pas dépendre de technologies flottantes.
Beaucoup (dont moi) pour cela utilisent des librairies comme Modernizr qui permettent de tester les capacités du navigateur et de faire évoluer le site en conséquence — mais beaucoup se reposent trop sur ces dernières en oubliant que le CSS par nature ignore les propriétés non reconnues et permet ainsi via son principe de cascade de répondre gracieusement aux failles de l’âge dans le navigateur du visiteur.

C’est le même principe que quand on déclare une propriété background brute avec une couleur plate avant d’ensuite déclarer un fond dégradé.

Pleine utilisation de l’OOSASS

Pendant longtemps le CSS a été un peu délaissé face à d’autres langages. Il faut dire qu’à l’heure où l’on brandit l’étendard du HTML5/Javascript/CSS, ce dernier reste celui des trois qui met non seulement le plus de temps à valider les modules, mais de surcroît celui dont les mises à jour sont souvent les plus mineures.
On a eu quelques apports majeurs tels le CSS3D ou justement les rems, mais des modules cruciaux comme Flexbox (module de présentation et structuration de page) que l’on attend depuis la création du langage peinent toujours à montrer le bout de leur nez. C’est pour ça que dans énormément de feuilles de styles on retrouve pléthore de préfixes (-webkit-, -moz- etc) tout simplement car attendre que ces fonctions soient officiellement validées et recommandées vous mettrait en retard de plusieurs années en terme de webdesign.

Bref, CSS est un peu le vilain canard délaissé du lot et de fait la manière de coder en CSS a assez peu changé depuis sa création avouons-le (tout du moins jusqu’à l’arrivé des préprocesseurs qui a tout fait exploser).

Un des rares (voire seuls) changements majeurs dans la méthode ces dernières années est l’OOCSS — ou l’orienté objet appliqué au design. Résumé simplement : plutôt que de définir le style de chaque élément les uns après les autres jusqu’à avoir tout bouclé, on repère et isole des patterns dans le design que l’on abstrait en des modules (en l’occurrence des classes).
Si vous avez du mal à cerner l’idée pensez par exemple à de célèbres frameworks CSS comme Twitter Bootstrap ou Zend Foundation qui emploient l’OOCSS. On style ainsi les éléments comme cela :

.light-block {
  background-color: rgba(255, 255, 255, 0.5);
  color: #333;
}
.quote {
  text-align: right;
  font-style: italic;
}
<p class='light-block quote'>Lorem ...</p>

Les styles sont abstraits en des modules que l’on répartit ensuite aux blocs. La feuille de style est ainsi beaucoup plus concise et optimisé puisque le principe DRY (Don’t Repeat Yourself) si cher à la programmation est appliqué au CSS.
Si vous voulez en savoir plus l’OOCSS je ne peux que recommander de suivre des gens comme Harry Roberts qui est pour ma part mon point de référence en la matière.

L’OOSASS ne fait que varier peu le principe mais propose plusieurs avantages non négligeables. Les modules sont abstraits et définis de la même manière qu’en OOCSS, mais plutôt que via des classes, ils sont définis des placeholders SASS. Cela implique deux changements : on n’applique non pas les modules dans le code HTML mais bien au chaud dans sa feuille de style, ce qui produit des pages ainsi beaucoup plus propres et surtout sémantiques.
Ensuite, les placeholders ne sont générés dans la feuille de style finale que s’ils ont été employés, à l’inverse des modules OOCSS qui doivent être présents dans la feuille finale vu que celle-ci n’a pas moyen de savoir lesquels ont été appliqués ou non (le CSS n’étant à la base pas un langage de programmation).

%light-block
  background-color: fade(white, 50)
  color: grey(30)

%quote
  text-align: right
  font-style: italic

.article p
  @extend %light-block
  @extend %quote

Pour ce portfolio j’ai essayé de tirer au maximum profit de l’OOSASS même si je n’ai pas l’expérience OOCSS de personnes comme Nicole Sullivan que je recommande de suivre aussi au passage.

Du statique au dynamique

Mon premier portfolio était entièrement statique — le problème du statique c’est qu’il entraîne incontournablement une grosse part de copier/coller dès que l’on veut rajouter quoi que ce soit. Et du coup c’est la merde.
À l’occasion de refaire mon portfolio j’ai décidé de le refaire entièrement sous Laravel cité dans l’article précédent. La plupart des concepts clés de ce que je fais ont été répartis dans des modèles, les miniatures sont générées automatiquement, et je récupère mes photos et albums de Flickr directement depuis leur API via une petite classe faite vite fait maison.

Toute la mise en page est découplée en vues — chacune avec son but propre — pour permettre une mise à jour simple et concise, avec des hooks aux endroits clés pour permettre des variations si besoin selon les pages.

La base de données est entièrement en SQLite qui était amplement suffisant pour le peu de besoins que j’avais vis-à-vis de ma base de données.

Mobile-first

Je parlais plus haut de responsive design — il faut savoir qu’en la matière il y a deux écoles. Desktop first et mobile first.
La première c’est la méthode qui aux premiers pas du responsive a été privilégiée car il s’agissait à l’époque d’adapter des sites existants en versions mobiles — ou alors qui est pratiquée par des gens n’ayant pas passé le cap et dû aux habitudes préférant encore faire d’abord un site version large pour ensuite le réduire.

La seconde approche (et celle qui est aujourd’hui largement recommandée) en est simplement l’inverse. On part du plus petit espace possible, et on construit de là. Faisant pendant longtemps partie de la catégorie de gens sus-nommée ayant du mal à passer le cap, c’était je l’avoue mon premier essai.

Le mobile-first n’est pas vraiment une technique en soi, plus une méthode subconsciente. Quand on part de la vue la plus large, on a tendance à simplement masquer deux trois blocs, tout passer sur une colonne, et se laver les mains l’air de dire “Bon bah ça marche, voilà !”.
Partir d’un cadre de 300px de large implique plusieurs choses que l’on va exécuter sans forcément s’en rendre compte.

D’une : la hiérarchisation du contenu viendra naturellement. Quand on a autant d’espace qu’on le souhaite il est facile de continuer à bourrer les pages çà et là. Posséder un espace restreint force à réévaluer quel contenu doit être mis en avant pour chaque page, et à mettre en place des moyens de passer/masquer le contenu secondaire.
De deux, le contenu rajouté sur les espaces plus larges sera plus en accord avec celui déjà en place, puisqu’en tête sera bien établi ce qui est à mettre en avant.

J’ai du mal à décrire les différences de démarches, mais le résultat souvent décrit et qu’au lieu d’avoir une version bureau encombrée et une version mobile délaissée, on a deux versions traitées en égal et tout autant léchées.

Voir le portfolio

portfolio

Vous pouvez voir le portfolio en cliquant sur la miniature ci-dessus. Notez que même cet article publié, je compte encore améliorer quelques points, et suit plus qu’ouverts à vos remarques (ou aux bugs éventuels).

Les sources sont en libre consultation sur Bitbucket, en particulier dans le dossier public/app/sass pour voir l’OOSASS dont je parlais au-dessus.

Laravel — l’élégance perdue du PHP

Vendredi 16 novembre 2012 à 18:05

laravel

Dans la vaste école des frameworks web, de langage en langage le paysage est bien différent. Là où les développeurs Ruby et Python ont su se mobiliser pour une même cause autour des piliers que sont désormais Rails et Django, il faut bien avouer que du côté du PHP ressort un certain côté cours de récré. Des frameworks à la pelle, chacun dérivés de X ou Y, pas un pour s’entendre sur des conventions, pas tous respectueux des standards du PSR. Si dans cette masse on en dégage une poignée devenus majeurs (tels Symfony ou encore CodeIgniter), reste cette impression constante de brouhaha dès que l’on ose partir à la recherche d’une réponse claire et précise à la question « Lequel dois-je utiliser ? ».

taylor Puis il y a quelques années de cela, a commencé à naître Laravel — petit bijou de Taylor Otwell, un développeur venant du monde du .NET et ayant décidé sans trop que l’on sache pourquoi de partir dans le PHP en parallèle. La différence est simple mais elle est là : Taylor a dans son framework insufflé tout ce qu’il avait de bonnes habitudes et de respect des conventions, de composants indépendants et j’en passe. Bref, tout ce que la communauté PHP a du mal a faire avaler à ses nouveaux venus, malgré des efforts récents comme PHP: The Right Way.

Il faut dire que dans le domaine des langages web, PHP a mis du temps à rattraper son retard. Là où Ruby et Python avaient déjà des bases rodées du fait qu’ils n’étaient pas faits pour le web, PHP a connu la démarche inverse. D’abord conçu pour injecter des bribes de dynamismes çà et là dans des pages statiques, il a fallu ensuite combler les manques et ce n’est que depuis peu que la plupart des fonctions perçues comme acquises chez les devs Ruby/Python ont vu le jour (entre autres OOP, classes, les namespaces, les magic methods, composants indépendants etc).
Depuis longtemps aussi il manquait à PHP un manager de composants comme NPM pour Javascript ou Rubygems pour Ruby, qui rendait plus complexe la distribution et la séparation du code en de petits paquets. Un vide comblé par la récente arrivée de Composer qui gagne lentement du terrain. Si Laravel 3 est d’ailleurs pour l’instant distribué manuellement, la version à venir – Laravel 4 – sera un ensemble de composants utilisables indépendaments et sera entièrement distribué et mis-à-jour via Composer.

Une syntaxe élégante

Sans doute un des principes les plus importants de Laravel, c’est la simplicité et la clarté de sa syntaxe. Là où des frameworks comme Symfony, bien que surpuissants, vomissent des centaines de lignes et de lignes qui partent dans tous les sens pour faire des choses parfois basiques, Laravel se lit plus comme du Ruby ou Python – avec des noms de classes et de méthodes orientées pour que le code se lise presque comme des phrases :

Route::GET('album/(:any)', function($album_id) {

  // Récupération et mise en cache de ressources
  $album = Album::where_category(3)->find($album_id);
  Cache::forever('album-artist', $album->artist->name);

  // Appels depuis la partie front-end
  if (Request::ajax()) {
    return Response::json($album);
  }

  // Classe d'authentification intégrée
  if (Auth::guest()) {
    return Redirect::to_action('users@login')
      ->with_message(Lang::line('errors.unlogged'));
  }

  if ($file = Input::has('file')) {

    // Helpers généraux
    $input = Input::except('file');
    Input::upload('file', 'uploads/', $file->name);

    // Validation des modèles
    $validation = Validator::make($input, Album::$rules);
    if ($validation->fails()) {
      return Redirect::back()
        ->with_input()
        ->with_errors($validation);
    }

    $album = Album::update($input);
  }

  return View::make('albums.show')
    ->with_album($album);

});

Plusieurs choses qui ressortent si on est habitué à la syntaxe plus “instance” qui est coutume. D’une, ces classes statiques qui servent d’interface entre l’utilisateur et le moteur de Laravel – c’est ce qui fait toute la différence. Si derrière les rideaux le framework est codé comme n’importe quel autre, Taylor y a supplanté le concept des façades, faisant qu’ainsi quand l’utilisateur tape URL::to_route('admin') il appelle en réalité une autre classe bien plus robuste, tout en laissant champ libre pour utiliser les composants du framework à des fins plus avancées.
Ce souci tout particulier du développeur est à mes yeux ce qui le fait ressortir du lot ; utiliser les classes données est un vrai régal et on se prend à sourire en faisant en quelques lignes ce qui auparavent en nécessitait des dizaines. Les façades évitent aussi le problème récurrent des frameworks où la moindre page doit auparavent être préfixée d’une dizaine de use souvent extrèmement longs.
Laravel fournit un array d’aliases que l’on peut compléter à sa guise pour raccourcir les noms de classes souvent utilisées, cet array étant directement fourni à l’autoloader du framework.

Autre chose que l’on remarque : contrairement à d’autres frameworks récents, Laravel a été pensé pour PHP 5.3 et plus. Ce qui veut dire exploitation à fond du potentiel des Closures, des magic methods et j’en passe. Le fait de ne pas avoir des années d’utilisateurs à prendre en compte et à porter sur ses épaules, ça a permis de tirer parti des dernières avancées du langage et de placer Laravel hors du lot.

Démystification du MVC

J’ai longtemps eu énormément de mal avec le MVC. Je connaissais le principe mais j’avais beau lire article sur article au bout d’un moment l’application concrète m’échappait. Pour ceux qui ne connaissent pas, le (controversé) pattern MVC (Model - View - Controller) prône la “séparation des buts” (separation of concerns en anglais) via une division du code en trois grands concepts. Le modèle récupère, aide et organise les données ; la vue représente et affiche les données voulues ; le controlleur sert de pont entre l’utilisateur et les modèles.
C’est le controlleur qui, quand l’utilisateur demande albums/read/3 va aller chercher le troisième album et remplir la vue albums/read.php avec les bonnes informations.
Très grossièrement hein.

Laravel rend incroyablement plus aisé le concept et son appréhension en, entre autres, ne forçant pas l’utilisation de controlleurs pour afficher la moindre page. De vues non plus en fait. De manière générale c’est peu difficile de cerner ce qui rend le MVC plus abordable avec Laravel mais force m’est de constater à moi et aux autres utilisateurs que le résultat est là. Comparer les premiers pas sur Laravel avec les premiers pas sur Symfony, c’est un monde à part. Un simple Hello World avec Laravel se résume à ça :

Route::get('hello/(:any)', function($name) {
  return 'Hello ' .$name;
});

Alors qu’un autre framework requierait au minimum la création d’une vue hello et d’un controlleur pour y accéder. De manière générale, mettre en place un site est beaucoup plus direct que sur d’autres frameworks. Je ne sais pas si vous avez déjà essayé de vous mettre dans la peau d’un débutant lisant le Getting Started de Symfony, mais il y a de quoi pleurer pour ces pauvres âmes.

Artisan, l’assistant CLI

Laravel vient préfourni avec un assistant CLI (Command Line Interface) nommé Artisan, permettant d’exécuter rapidement une multitude de fonctions de maintenance et de test. Il est même possible en quelques lignes de créer ses propres tâches pour Artisan.
Les tâches n’étant que de petits scripts PHP, on a accès à toutes les classes de Laravel et il est très facile de se créer des tâches de routines pour se rendre la tâche plus facile.
Artisan s’intègre aussi dans PHPUnit pour créer facilement des tests unitaires – que ce soit pour son application, un plugin, tester le moteur de Laravel si on fait une fork, ou autre. Il y a un petit dossiers tests dans application, il y a juste à y glisser des fichiers et tout roule. C’est essentiel parce que les tests unitaires font partie de ces habitudes cruciales et rentrées dans les habitudes des devs d’autres langages mais qui pourtant ont du mal à s’ancrer chez les devs PHP.

artisan

Les migrations

Concept que l’on retrouve nativement dans Ruby on Rails ou via South dans Django, les migrations permettent de versionner l’évolution de votre base de données.
Le principe est simple : une migration représente une modification de la base de données. “Hier soir j’ai renommé la colonne name en lastname“. Via Artisan il ne suffit alors plus que de faire artisan migrate et si des modifications ont eu lieu entre temps, Laravel saura où vous en êtes et mettra à jour la structure et les données de votre BDD. Un exemple de fichier type :

class Create_Categories
{
  public function up()
  {
    Schema::create('categories', function($table) {

      // Classe de schemas intégrée
      $table->increments('id');
        $table->string('name');
        $table->boolean('visible')->default(true);
        $table->integer('user_id')->unsigned();
      $table->timestamps();

      // Gestion des foreign keys
      $table->foreign('user_id')
        ->references('id')
        ->on('users')
        ->on_delete('cascade');
    });
  }

  public function down()
  {
    Schema::drop('categories');
  }
}

Ceux qui n’ont jamais touché à des migrations se demanderont sans doute l’intérêt par rapport à de simples fichiers SQL. L’intérêt c’est qu’un schéma est par définition language-agnostic – au moment de dessiner le schema de votre table, le code n’a aucune idée de si vous utilisez MySQL, SQLite, un serveur Redis, ou encore de simples fichiers textes. Il sait simplement à quoi ressemble la table et au moment de la créer, Laravel va utiliser ses classes de grammaire pour traduire chacune des commandes en son langage voulu.
C’est valable pour les schémas mais surtout – et plus intéressant – pour toute intéraction avec la base.

Fluent & Eloquent

Fluent est le moteur d’abstraction de BDD de Laravel. Il ressemble à ceci :

// Récupérer des données
DB::table('users')->where('group', '>=', 2)->only('name')
DB::table('categories')->order_by('name', 'asc')->first()
DB::table('users')->where_null('category')->or_where_level(1)->count()
DB::table('products')->where_in('id', array(2, 3, 4))->max('sales')
DB::table('users')->increment('votes')
DB::table('users')
  ->join('phone', function($join)
  {
    $join->on('users.id', '=', 'phone.user_id');
    $join->or_on('users.id', '=', 'phone.contact_id');
  })
  ->skip(5)->take(10)
  ->get(array('users.email', 'phone.number'));

// Insérer, modifier, supprimer
DB::table('users')->where_age(18)->update(array('age' => DB::raw('age + 1')));
DB::table('users')->delete(5)
DB::table('users')->insert(array(
  'name' => 'name',
  'age'  => 18,
));

Rien d’extraordinaire, si ce n’est la constante lisibilité qu’apportent les magic methods telles __callStatic et qui permettent des choses comme ->where_name_or_firstname('foo'). Si Fluent est intéressant, c’est parce que c’est le béton fondateur d’Eloquent, l’ORM (Object-relational Mapping) de Laravel. Eloquent est la base (non obligatoire) de vos modèles dans Laravel, ce qui fait que lorsque vous créez un modèle vous pouvez simplement faire ceci :

class Artist extends Eloquent {}

…Et c’est tout. Laravel est un framework qui sous ses airs simplistes traverse de larges distances pour comprendre ce que le développeur essaye de faire plutôt que de placer devant lui vingt outils et de lui dire « Bonne chance mec ». Ici Laravel reconnait le modèle Artist et fait le lien avec la table artists présente dans votre base de données. De là il en extrapole le schéma de votre modèle – pas besoin de mapper manuellement chaque colonne.
Mais la clé de la puissance d’Eloquent c’est tout ce qu’il est ensuite possible de faire depuis le canvas vide de votre classe désormais propre de tout spaghetti prérequis.

D’une, vous pouvez indiquer pour un attribut donné sur un modèle, ce qu’il lui arrive à l’entrée/sortie. Forcer un mot de passe à être toujours crypté, forcer une date à apparaître toujours au format X. De deux, la gestion des relations de Laravel est d’une simplicité déconcertante tout en étant incroyablement optimisée. Quelques exemples simples :

// Définition simple de relations
class Album extends Eloquent
{
  public function artist()
  {
    return $this->belongs_to('Artist');
  }

  public function tracks()
  {
    return $this->has_many('Track');
  }
}

Album::find(4)->artist->name
Album::tracks()->where_rating(5)->take(5)

Artist::with('album', 'album.tracks')->get()

Comme on peut le voir, Eloquent étant construit par-dessus Fluent, toutes les méthodes de l’un se retrouvent chez l’autre.

La dernière requête toute particulière va utiliser la fonction eager-load d’Eloquent, signifiant que ce qui suit, bien que faisant appel à de multiples relations éparpillées sur de multiples modèles différents, à des profondeurs différentes ne va pourtant exécuter que deux/trois requêtes. Laravel va optimiser et précacher les relations pour un rendement optimal, employant les données qu’il a déjà à chaque fois.

foreach($artists as $artist) {
  foreach($artist->albums as $album) {
    echo $album->name;
    echo $album->tracks()->count(). ' pistes';
    foreach($album->tracks as $track) echo $track->name;
  }
}

Eloquent via ses setters/getters dynamiques simplifie aussi immensément la syntaxe de vos vues.

class User extends Eloquent
{
  // Assure que dès que l'on modifiera/attribuera un mot de passe à un
  // utilisateur, celui sera crypté
  public function set_password($pasword)
  {
    $this->set_attribute('password', Hash::make($password))
  }

  // Crée un attribute fictif "name" vous permettant de faire
  // $user->name et d'obtenir son nom/prénom, même si ce champ
  // n'existe pas dans la base
  public function get_name()
  {
    return $this->get_attribute('firstname'). ' ' .$this->get_attribute('lastname');
  }

  // Vous pouvez aussi "écraser" des champs pour
  // y faire du travail préalable à l'affichage
  public function get_created_at()
  {
    return new DateTime($this->get_attribute('created_at'))
      ->format('H:i:s');
  }
}

Blade

Autre point fort de Laravel, son moteur de template, Blade. Contrairement à d’autres moteurs de template comme le célèbre Twig, Blade utilise PHP pour son rendu, ce qui veut dire qu’en plus des tags préfournis il est à tout moment possible d’ouvrir des balises PHP et d’y taper ce qu’on veut. C’est à double tranchant et beaucoup voient celà comme un inconvenient, incitant peut-être trop les nouveaux venus à mettre leur code business dans leurs vues.
Ci-dessous un exemple de vue Blade :

@layout('layouts.main')

@section('title')
  Articles - @parent
@endsection

@section('content')
  @forelse($articles as $article)
    <h1>{{ $article->name }}</h1>
    <article>{{ $article->content }}</article>

    {{-- Commentaires --}}
    @if($article->comments)
      @render_each('partials.comment', $article->comments, 'comment')
    @endif
  @empty
    {{ Alert::info('Aucun article à afficher') }}
  @endforelse

  @unless(Auth::guest())
    @include('admin.footer')
  @endif
@endsecton

Les bundles

Similaires aux plugins de tout framework, les bundles sont là pour compléter toute fonction non disponible nativement. Pour l’instant distribué via un repository privé, ils seront dès Laravel 4 de simples composants distribués via Composer. La différence avec beaucoup de frameworks c’est que les bundles de Laravel sont vraiment chez eux – ils ne sont pas dans une bulle fermée, mais au contraire sont au même niveau que l’application elle-même (puisque le dossier application est en réalité lui-même un bundle).
Les bundles peuvent enregistrer des routes, ajouter des tâches à Artisan, fournir des classes, des vues, et j’en passe. On peut à tout moment accéder à des données d’un bundle via la convention bundle::. Par exemple View::make('admin::index') génerera la vue index du bundle admin.
Laravel fournit aussi toute une poignée d’helpers liés à l’autoload, permettant en une ligne d’ajouter et d’aliaser un ensemble de classes PSR, à la manière de Composer.

J’ai moi-même un ou deux bundles publiés, celui marchant le mieux étant Former qui permet avec facilité de créer des formulaire complèxes :

Former::horizontal_open()
  ->id('MyForm')
  ->secure()
  ->rules(array( 'name' => 'required' ))
  ->method('GET')

  Former::xlarge_text('name')
    ->class('myclass')
    ->value('Joseph')
    ->required();

  Former::textarea('comments')
    ->rows(10)->columns(20)
    ->autofocus();

  Former::actions (
    Former::large_primary_submit('Submit'),
    Former::large_inverse_reset('Reset')
  )

Former::close()

Conclusion

Laravel est un framework extrèmement prometteur, avec une communauté forte derrière-lui. La prochaine version majeure est prévue pour la fin du mois et apportera le support complet de Composer majoritairement, plus d’autres fonctions très utiles comme les ressource controllers qui faciliteront extrèmement la mise en place d’API à la manière de ce que Rails Scaffold propose.

Si vous êtes à la recherche d’un framework pour votre prochain projet, je ne peux que conseiller Laravel – il s’intègre parfaitement à des frameworks JS comme Backbone ou Express, est simple tout en étant puissant, et la fréquence de ses mises à jour laisse deviner un avenir radieux.
Pour savoir par où commencer, je ne peux que recommander la documentation officielle constament tenue à jour, ainsi que le livre gratuit Code Happy qui vous guide pas à pas dans Laravel et en présente les principales fonctions.

Nouveau design test

Lundi 29 octobre 2012 à 4:23

Pendant les travaux l’exposition continue. On ne se moque pas je bidouille encore.
Si vous avez des remarques ou que ça bug chez vous dites-le moi.

Pour ceux que ça intéresse après mon article sur les préprocesseurs, le code du design est sur Github. Si vous avez toujours codé en CSS et vous demandez après mon article à quoi ressemble le code d’un design en SASS, vous pourrez y voir comment j’ai sectionné le design, employé les placeholders pour optimiser le code, passé mes images en data64 pour réduire les requêtes HTTP et l’usage et la puissance des variables au sein du code. Il y aussi des exemples de comment avec Susy et deux/trois mixins personnels j’ai pu aisément et rapidement ajouter une touche de responsive à la plupart des blocs.
Les ms([nombre]) que vous verrez dans le code correspondent au plugin modular scale de Compass (la boîte à outils de SASS) qui permet de calculer tous vos paddings/margins/font-size en tant que multiples de votre taille de police de base ce qui permet d’ajouter un semblant de rythme vertical à votre design.

body
  @extend %fontSerif // étend les blocs auxquels j'ai attribué une police sérif
  +font-smoothing(antialised) // Mixin ajout les préfixes propriétaires à la propriété font-smoothing
  background: $baseColor inline-image('crisp_small.jpg') // Utilise la couleur de base du design comme fond et aplatit l'image dans la CSS en data64
  color: $bodyFontColor // Utilise la couleur de base du texte

div#page
  @extend %container // étend le style de base d'un conteneur à colonnes
  @extend %reset // étend le reset des styles de wefrag
  margin: auto
  max-width: 75%
  padding: 0 ms(0) // Calcule le padding selon la taille de base du texte
  +to($tablet)
    max-width: 100% // Change la largeur du corps selon la largeur de la fenêtre
  +from-to($tablet, $wider)
    max-width: 95%

Le code principal du design est donc dans le dossier sass qui ensuite compile la feuille de style dans le dossier css.

Le Version control

Mercredi 23 mai 2012 à 13:00

“If you’re not on Github, you’re essentially unable to participate in the rich open-source community that has arisen around front-end development technologies.”

Quand je dis que ma manière de travailler a changé je ne parle pas seulement du résultat final de mon travail mais du processus en lui-même, le workflow. En quelques mots c’est tout ce qui, de l’idée originelle, conduit au résultat final — les étapes suivies, les logiciels et langages utilisés, les pratiques mises en œuvre… bref vous saisissez l’idée. Chacun a sa méthode, chacun a rodé ses étapes, et il est toujours utile de lire et d’étudier la manière dont les autres travaillent.
Beaucoup de choses ont changées depuis que je me suis mis au webdesign, j’ai beaucoup fait évoluer ma méthode personnelle, mais s’il y a une chose que je tiens à mettre en avant en particulier aujourd’hui c’est l’importance du versioning et de sites comme Github.

Le version control en gros c’est l’acte de scinder son travail en versions (et oui). Le terme est assez large, il peut aller du simple fait de créer des versions de son projet (v1, v2) au fait de marquer chaque changement au code comme un point d’encrage en tant que tel, via des technologies comme svn ou git. Je ne vais pas (trop) m’étendre sur ces deux technologies parce qu’il y aurait trop à dire, mais comme le site de Git a il y a peu fait peau neuve je me permets de vous glisser un lien.
Cette article est plus sur le principe du versioning que sur les fondamentaux techniques. Si vraiment vous ne voyez pas de quoi je parle, et ne voyez pas de raisons de lire cette article, faites-le quand même. Le versioning s’applique tant à la programmation qu’au travail graphique – garder un historique de ses images et de son travail en général est un atout énorme, et même si je parlerai principalement de mon cas et de code ici, il y a de grandes chances que cela s’applique à vous aussi.

Dans la poignée de webdesigners que je suis de près, j’étais à une époque tombé sur un article de Rebecca Murphey qui disait « If you’re not on Github, you’re essentially unable to participate in the rich open-source community that has arisen around front-end development technologies. » (Si vous n’êtes pas sur Github, vous êtes fondamentalement incapable de participer à cette riche communauté open-source qui s’est formée autour des technologies du développement front-end [1]). C’est une phrase qui m’a beaucoup marqué, surtout parce qu’à l’époque je ne la comprenais absolument pas.

[1] Rebecca fait ici référence à des technologies comme le HTML5, le CSS3, Javascript, Ruby, PHP, et j’en passe. Le front-end se définit comme tout ce qui se trouve entre l’utilisateur et le back-end (le code moteur), l’interface en quelque sorte.

Historique

Pendant longtemps j’ai laissé ça de côté - parce que je ne voyais pas trop à quoi il était fait allusion, et parce qu’avouons-le, pour qui n’y a jamais touché Git et SVN sont des mondes qui donnent mal à la tête. Faits de branches, de commits, de pull request, de merge et de revisions, et j’en passe. Chaque technologie y va de son petit terme à elle, parfois même pour parler de choses identiques, et quand arrive l’heure de se lancer on peut mettre un long moment avant de saisir réellement ce dont il s’agit.

Dans mon cas j’ai décidé de m’y frotter quand ma petite ébauche de framework a commencé à faire ses preuves, et qu’il devînt de plus en plus complexe de gérer différentes itérations du moteur sur plusieurs projets. De répercuter les bugfixes et améliorations, de savoir où chaque projet en était et ce qui avait changé depuis la dernière fois. Du coup à l’époque je me suis lancé dans SVN, un peu arbitrairement – j’ai placé mon moteur sur un hébergement SVN en ligne (à savoir Beanstalk) pour me faciliter la tâche. Et après quelques coups d’essais j’arrivais à gérer plusieurs versions du moteur sur plusieurs projets — déployer des modifications sur chacun sans me prendre la tête, gérer facilement conflits et historiques, etc.

J’ai toujours considéré que quand on apprend une technologie nouvelle il n’y a de meilleur maître que la pratique. Sans se lancer complètement à l’aveugle non plus, le fait de tenter de mettre en œuvre ses connaissances dans un petit projet, parfois même au fur et à mesure de l’apprentissage, aide beaucoup à comprendre l’ensemble. Ça m’avait aidé à l’époque du HTML, puis du PHP, et ainsi de suite jusqu’à aujourd’hui.
Pour moi, Cerberus - le nom de mon framework - était ma manière de tâter le terrain de manière concrète. Séparer mes modifications en versions et ainsi savoir où en était tel ou tel projet. J’avoue bien sûr que, travaillant seul, il m’est bien plus simple d’expérimenter avec les technologies du web que pour beaucoup de gens.

À mesure que je me familiarisais et rattrapais mon retard avec la scène du webdesign, que j’employais et suivais de nouveaux projets et technologies, j’ai appris à connaître GitHub. Pour ceux qui ne connaissent pas, c’est un site basé sur le principe des repositories : des sortes de “répertoires” symbolisant des projets. Tout s’articule autour des interactions possibles entre eux : les gérer, les héberger, discuter autour d’eux; laisser les utilisateurs disséquer, réparer voire améliorer votre code.
C’est la base de l’open-source : votre code est à la vue de tous, les utilisateurs peuvent venir commenter ou interagir sur chaque ligne. C’est un concept qui peut paraître terrifiant à première vue mais qui révèle bien vite plus de points positifs que négatifs.

Le version control pour tout, partout, tout le temps

Vous l’aurez compris, le principe est de créer une sorte de ligne de temps de votre code. Où chaque modification est distincte des autres, ce qui ouvre tout un monde de possibilités, la plus utile étant sans conteste celle de ramener à tout moment votre code à un instant T. Qui n’a jamais fait une grosse modification sur son code pour ensuite se rendre compte même après tests qu’elle cassait quelque chose d’inattendu ?

De là une fois qu’on y a goûté il est difficile de faire marche arrière, et bien vite je me suis retrouvé à héberger, non plus simplement le code moteur de mes sites sur Github, mais mes projets eux-mêmes.
Ça me donne entre autres une facilité de transport. En ce sens où l’état des fichiers sur le disque n’importe désormais plus - finies les galères avec Dropbox de conflits de fichiers, d’erreurs de copie, et j’en passe. Les commits (modifications faites au projet) sont enregistrés en ligne et je peux décider de télécharger de n’importe où n’importe quelle version de mon projet, de sa naissance à la fin. C’est un outil miraculeux, surtout lorsque l’on travaille à plusieurs ou sur plusieurs postes : chacun peut améliorer un code dans son coin, tout en ayant toujours la dernière version sur son poste. Et si conflit il y a, les fonctionnalités de merge (fusion) de git et svn sont assez malignes pour gérer tout ça. Imaginons par exemple que deux personnes travaillent sur un même fichier et envoient leurs changements en même temps, pour peu que ces changements soient à des endroits distincts du fichier, tout sera habilement combiné en arrière-plan.

On en devient vite accro, de la technologie elle-même certes mais de la communauté autour aussi. Pour tout vous dire, même cet article a été écrit en Markdown (un langage de formatage) sur Gist, la plateforme d’échange de bouts de texte et de code de Github, qui permet elle aussi de créer une instance du fichier à chaque modification, de discuter autour. Bref de faire tout ce qu’on peut en temps normal.

Être au plus près du travail des autres

L’autre point fort comme je l’ai dit c’est la facilité d’interaction et la proximité des développeurs. Quand je repense à il y a quelques années, je pense que jamais je ne me serais imaginé participer de si près au développement des projets qui me sont chers. Lointain est désormais le monde des boîtes à suggestions où on envoyait des emails désespérés en priant pour être pris en compte. La plupart des gros projets sont désormais sur Github. Même PHP - le langage lui-même - est depuis peu passé au Git.
Désormais quand il manque quelque chose dans un projet que j’aime, je ne reste plus les bras croisés - je fork le projet (fait de créer une version séparée), fais mes modifications, et fais un simple pull request pour que mes modifications soient ajoutées automatiquement au projet si le développeur les trouve à son goût. Tout ça parfois en quelques heures – jamais les choses n’avaient été aussi vite.

A contrario quand désormais je tombe sur des projets intéressants qui n’utilisent aucun système public de version control, je ressens toujours une certaine impuissance. Trouvé un bug dans le code ? Envoyez un email et attendez. Envie de suggérer une amélioration ? Passez par les (parfois inexistants) forums et croisez les doigts pour que quelqu’un les lise.
De manière moindre ça me fait aussi un peu ça quand je tombe sur des ancêtres (Sourceforce) ou concurrents (Google Code, qui utilise SVN) de Github.

Oser faire le premier pas

Si vous n’avez jamais touché ni à Github ni à Google Code, essayez. Tout le monde a au moins un projet qui gagnerait à utiliser ces technologies. Et rappelez vous que dans version control il y a control.
De nos jours les pages de démarrage de Github se sont faites moins effrayantes, vous serez guidé pas par pas et tout devrait bien se passer.
Si git et svn restent des technologies qui favorisent la ligne de commande, sachez par ailleurs que de nombreuses interfaces existent, de Mac à Linux. Une bonne poignée est répertoriée sur la page GUI du site git, à l’exception de Github for Windows qui vient d’être lancé.

Si vous êtes un débutant, Github for Mac et Github for Windows (dans un très léché style Metro) sauront se prouver intuitives et vous accompagner dans vos premiers pas.
Si vous êtes plus expérimenté et avez besoin d’accéder à des fonctions plus poussées, Smartgit sur Windows et SourceTree (gratuit) ou Tower (payant) sur Mac seront là pour vous. Au niveau du svn je n’ai testé que Versions sur Mac mais en ai été très satistait.

Ces logiciels répondent tous à une peur de la ligne de commande qui éloigne beaucoup de gens de ces technologies, et c’est une perte grave car se couper d’une communauté aussi passionnée, rassemblée autour de l’open-source et des possibilités offertes, c’est effectivement se priver d’énormément de choses.

Conclusion

Quelques mois plus tard je comprends enfin la phrase de Rebecca et s’il n’y a qu’une chose que je puisse dire c’est que je ne pourrais être plus d’accord.
Les simples technologies citées dans l’article précédent : LESS, SASS, Compass, CoffeeScript, ou d’autres comme jQuery, Ruby on Rails — toutes sont sur Github, ouvertes à discussion, à amélioration.
J’ai récemment vu le développeur d’un plugin pour Compass me laisser les clés du projet car je le développais plus activement que lui.

Le web et les technologies qui l’entourent n’ont jamais avancé aussi vite. Là où avant le HTML et le CSS par exemple étaient des technologies fixes mises à jour toutes les X années, sont désormais devenus des langages mouvants. Des standards en constante évolution par la communauté (ça sera le sujet d’un prochain article).
Si vous voulez commencer à garder le rythme, mon meilleur conseil est de suivre ce qui vous passionne au plus près, à la source. Mon meilleur conseil, c’est de commencer par .

Note

Mon prochain article se portera sur le Responsive Design. De ses premières ébauches à la (re)découverte des Media Queries, jusqu’à son actuelle forme où les designs adaptatifs ont dans la plupart des cas supplantés les versions mobiles et consorts.

Je discute aussi beaucoup avec des développeurs étrangers et dans l’optique de mieux m’ouvrir à tous j’ouvrirai bientôt un blog compagnon à celui-ci où des versions anglaises de mes articles sur le webdesign seront postées. Ne vous étonnez-donc pas si je lie alors chaque article vers un blog externe, celui-ci reste mon blog principal.

Depuis quelques temps j’ai envie d’écrire une mince série de billets sur ce que je fais plus concrètement au travail. Histoire de partager, recueillir quelques avis et puis pouvoir discuter un peu de sujets qui me passionnent avec des gens qui traversent la même chose. Comme je l’avais mentionné dans un précédent article, j’ai commencé à travailler il y a deux ans et demi de cela. Quand je suis arrivé, j’avais quelques vagues et lointaines connaissances de PHP, des connaissances un peu plus récentes en CSS3 et xHTML, et puis c’était environ tout.
Projection aujourd’hui, où j’ai peu à peu monté et amélioré mon propre framework PHP avec tout le confort et la simplicité dont j’ai besoin; où j’ai la tête plongée dans le CSS3 et le HTML5, ses normes et avancées quotidiennes en termes d’interface et d’ergonomie. Je tâte un peu de Javascript et d’AJAX. Je suis quelques blogs, me tiens au courant des dernières modes et nouveautés, participe activement au développement des projets qui me sont chers sur Github, etc. Sans jamais vraiment arriver à m’appeler webdevelopper, j’ai parcouru bien du chemin et tiens beaucoup mieux le rythme face au flux perpétuel de changements d’un web qui se renouvelle en permanence.

Je comptais diviser ces articles en quelques points, un peu au hasard. Aujourd’hui, et parce que c’est ce qui me passionne le plus en ce moment, je voulais aborder un peu le monde des préprocesseurs qui ont le vent en poupe depuis quelques mois*. Ils existent depuis plus longtemps certes, mais j’ai l’impression que c’est vraiment depuis peu qu’ils ont explosé et se sont démocratisés.
Qu’est-ce qu’un préprocesseur ? C’est comme son nom l’indique une sorte de langage supplémentaire dans lequel on va coder, et qui va ensuite être processé (compilé quoi) vers un autre langage. L’intérêt d’employer des préprocesseurs CSS, JS ou HTML ? C’est qu’ils rajoutent des couches assez exceptionnelles de fonctionnalités, d’améliorations de syntaxe et de possibilités, à des langages vieillissants. Ils simplifient des tâches répétitives, sont plus souples, et l’intérêt comme ils sont ensuite compilés et non calculés en direct, c’est que le client ne voit aucune différence.

* Ma copine me précisant que cette expression lui fait penser à « PD comme un foc », à cause du vent en croupe.

LESS, SASS et Compass

sass
696863337

Petite note préambule : je n’aborde pas les autres préprocesseurs car moins connus et ou plus mis à jours (Stylus etc).
LESS et SASS sont tous les deux des préprocesseurs CSS, qui à mes yeux de tous les langages était celui le plus vieillissant. Comme l’abordait Chris Eppstein, le créateur de Compass, le CSS est devenu un langage qui ne répond plus aux attentes et besoins du web moderne. Beaucoup de choses ont contribué à l’alourdissement de ce langage : son interprétation variable selon les navigateurs, sa syntaxe trop simpliste, les différents moteurs qui l’empoisonnent de propriétés propriétaires et contribuent à sa non-uniformisation. Entrent en jeu les préprocesseurs, ici LESS, SASS. Tous différents mais se rejoignant sur un ensemble de grands thèmes : la création de fonctions (ou mixins), des bouts de CSS dynamiques qu’on peut pré-créer et réemployer, l’ajout de variables au CSS, de fonctions permettant le calcul de mesures et de couleurs, et le nesting de classes. Ce n’est pas tout bien sûr mais c’est l’essentiel. De là découlent énormément de possibilités.


À gauche du SASS, à droite le résultat en CSS

À l’idée d’aborder ce paragraphe j’étais teinté d’une légère honte en ayant l’impression de retourner ma veste. Deux articles plus bas j’encensais LESS par sa simplicité d’intégration et ses possibilités, et à contrario descendait le SASS par sa difficulté pour le premier venu. LESS pouvant être compilé à la volée via du Javascript, et SASS devant être compilé via Ruby, à l’ancienne dans la ligne de commande (sauf si votre projet est lui aussi en Ruby, par exemple via Ruby on Rails).
Mon changement d’opinion s’est fait alors que je tentais de transposer un fichier SASS en LESS; alors que tout se passait plus ou moins bien, je ne cessais de buter sur des fonctions et choses diverses complètement irréalisables en LESS. Pour une raison simple : SASS possède des syntaxes de boucles et de conditions (if, for, while, else etc) que le développeur de LESS refuse d’intégrer par principe. J’ai alors peu à peu entamé ma migration vers le SASS et quand j’ai mis la pointe du pied dans l’océan de possibilités qu’offrait Compass, je n’ai plus regardé derrière moi.
Compass est une librairie de fonctions pré-créées en SASS, une sorte de toolkit prévoyant tout ce qu’on peut imaginer avoir besoin pour faire du CSS de nos jours. Création de sprites à la volée, gestion dynamique des dossiers, myriades de fonctions et mixins, grille CSS, et j’en passe. Je me suis peu à peu rendu compte en codant en SASS des limitations du LESS et ai compris que le seul vrai point noir de ce langage était sa documentation déroutante et peu aguichante pour le nouveau venu alors que LESS propose un site simple en une page. Un point que le développeur assure être en train de corriger via une équipe dédiée à la refonte du site et de la documentation de SASS.

Le poids le plus important à mon goût c’est que Twitter lors de la création de Bootstrap, son framework CSS, a décidé de le coder en LESS. J’ai mis un peu de temps à faire la transition, moi qui suit le projet aux derniers commits, mais après création d’un petit script de conversion LESS->SASS ça ne me pose plus de problèmes.

CoffeScript

267-coffeescript-basics

Au niveau du Javascript je passe désormais toujours par du CoffeeScript. D’une parce qu’il m’évite des erreurs de débutants, moi qui n’emploie pas autant le Javascript que d’autres langages, et de deux parce qu’il simplifie sa syntaxe à un point que je n’imaginais possible. Les exemples en page d’accueil sont à mes yeux les plus probants donc je vous laisse y jeter un oeil.
De paire avec des bibliothèques comme jQuery c’est désormais un plaisir d’apporter interactivité et dynamisme à des pages plates, et je n’ai à ce jour rien trouvé que sans grandes connaissances en JS je ne puisse faire à l’aide de ces deux outils.

HAML

haml

HAML est un préprocesseur HTML. J’en parlerai moins parce que de tous c’est celui que j’emploie le moins, la plupart de ce dont j’ai besoin pouvant déjà être fait en PHP. Il reste cependant utile lors de la création de longues pages HTML complexes (emailing etc), car il simplifie énormément la syntaxe HTML, un peu à la manière de ZenCode.
Il est aussi assez peu mis à jour, le créateur étant celui de SASS et étant du coup assez accaparé par ce dernier. On retrouve une syntaxe justement proche du SASS, avec des { } qui sont omis au profit de l’indentation, et une intégration du Ruby assez soutenue. La possibilité d’y dédier des zones “filtres” où l’on peut par exemple employer du Markdown ou autre, rend la mis en page de contenu très simple et ça reste un bon gain de temps par rapport au fait de taper le HTML à la main. C’est aussi beaucoup plus facile de revenir dessus pour corriger des choses.

Conclusion

Cet article était plus dédié à ceux qui ne connaissent pas la chose qu’aux autres. En tout cas dans mon travail à l’heure actuelle ce sont désormais des outils dont je pourrais pas me passer. Revenir au simple CSS maintenant, avec toutes ses contraintes et ses lourdeurs, me serait impossible.
Pour ceux qui ont du mal ou manquent de courage quant à se lancer dans Node.js, compiler à la console et autres, je suis prêt à vous guider si vous le voulez. Ce ne sont pas les tutoriaux qui manquent mais étant moi-même passé par là je sais à quel point il est dur d’entrer dans le monde du Ruby, des gems et compagnie quand on n’a jamais touché à autre que du PHP.

Les Choses Mortes VIII - La Page Blanche

Dimanche 26 février 2012 à 19:54

Il y a quelques temps on m’a envoyé deux lieux à visiter par email, et comme j’ai trouvé l’initiative vraiment exceptionnelle je me devais d’aller voir sur place. Même si en ce moment j’ai encore deux autres endroits sous le coude à visiter, j’ai souvent de longues périodes de vide donc n’hésitez pas à m’envoyer par email si vous connaissez des lieux dans le sud qui pourraient me plaire.
Celui-ci en particulier est une maison dont la construction a été interrompue, perdue dans les hauteurs de Villefranche (et quand je dis perdue c’est véritablement perdue). C’était une série plus dure que les autres, et je doute un peu du résultat final. Une maison en construction c’est toujours cette certaine omniprésence de gris ciment drapant des poignées de pièces en devenir. Ni meuble, ni papier-peint; ni rien. Un canvas qui pouvait devenir ce que je voulais — c’était un défi au sens où si je voulais faire ce que je fais d’habitude il fallait être très imaginatif pour trouver des choses à montrer ou à raconter.
Ce monochrome de gris qui m’a été imposé je l’ai détourné - peut-être à tort - en jouant beaucoup plus sur les variations de couleurs que sur d’autres séries. Parfois par jeu esthétique et souvent pour mieux faire ressortir ce que je voyais à ce moment-là. Ma hantise en fait en photographie c’est toujours l’incompris : étant donné qu’il m’arrive tout le temps de voir des choses qui ne me semblent évidentes qu’à moi, j’ai toujours peur de ne pas arriver à les cerner. Je suis le genre de personnes qui voit des peintures épiques dans les arabesques du marbre, et faire transparaître ce genre de visions par simples cadrage et réglages, c’est toujours un challenge en soi.

01
02
03
04 - La Vénus d'Ille
La Vénus d’Ille
05
06 - Natalités
Natalités
07
08 - Suspiria
Suspiria
09
10
11
12
13
14
15
16
17
18
19
20
21
22

Iconic et Entypo

Samedi 18 février 2012 à 4:33

Petit historique

En terme de web les modes vont et viennent, tant au niveau du fond que de la forme. C’est à la fois dû à l’évolution des langages eux-mêmes et l’évolution des navigateurs qui lisent et déchiffrent ces langages. Sans doute est-ce le fait que je suis plus informé qu’avant mais j’ai l’impression que les choses s’accélèrent de plus en plus - et dans le bon sens. Quand je vois les efforts monstrueux de certains sites pour atteindre la perfection en terme d’interface, de design et d’intuitivité, je me dis que le web que nous côtoyons aujourd’hui revient de bien loin comparé aux premières pages perso qui ont vu le jour à son ouverture.
Pour travailler dans l’envers du décor, je pense qu’énormément de gens ne réalisent pas la masse de technologie et de puissance qui se cache derrière leurs sites préférés. La quantité de gens qui par exemple utilisent Facebook au quotidien sans jamais se poser et réfléchir au travail et à la complexité de ce qui fait tourner un des plus gros sites du web.

Je divague un peu. Je comptais me pencher sur un cas en particulier puisque c’est ma dernière découverte en date : une technologie qui n’est pas forcément neuve puisqu’il s’agit d’une propriété CSS.
La propriété en question, c’est @font-face. Font-face je pense fait partie de ces changements qui s’est insinué dans les standards du web discrètement jusqu’à ce que plus personne ne réalise la prouesse de la chose.
Je me souviens quand j’ai fait mon tout premier site, à l’époque je tenais à ce que mes titres et corps soient dans une police en particulier. J’avais donc demandé à tous mes (deux) visiteurs de télécharger un pack de huit polices pour voir correctement mon site. Oui j’étais pas forcément futé.

Ce texte est écrit en Raleway

Avançons de quelques années. De nos jours rares sont les sites à la pointe du design qui n’y vont pas de leur police à eux - tantôt esthétique, tantôt créative, tantôt subtilement inédite. Cette capacité d’apporter à l’utilisateur des polices dont il ne dispose pas, le temps d’un site, c’est la magie de @font-face. Plusieurs personnes ont fait leur business de répertoires de polices prêtes à être utilisées sur le web, parmi les plus grands : Google Fonts et Typekit. Dans répertories dans lesquels on n’a désormais plus qu’à naviguer et faire son petit shopping.

Image hosted by uppix.net
Image hosted by uppix.net

Du détournement de @font-face

Un autre des points communs à une partie des sites d’aujourd’hui - en particulier ceux qui proposent une certaine interactivité - c’est la récurrence de certains pictogrammes. Lorsque l’on veut créer une gamme de pictogrammes il n’y a pas trente-six moyens : il faut les créer sur Illustrator, puis les exporter et décliner en tout autant de tailles et de couleurs qu’il sera nécessaire. Ce qui résulte souvent à des centaines de petits PNG de 8 à 32px qui encombrent et qui sont une misère à gérer et à charger.
Beaucoup de ces problèmes sont résolus par l’utilisation de nos jours de sprite mais rien qui ne compense les avantages de ce qui va suivre.

Jusqu’à ce que naissent s’élèvent des voix en arrière-plan. Des voix qui avaient alors une idée : utiliser @font-face pour faire une police d’icônes. Des icônes qu’ont pourrait alors étendre à l’infini et dans la couleur de notre choix, comme n’importe quel texte sur une page.
Au début ce fut difficile, parce qu’il y a avait un monde de problèmes d’accessibilité et de contraintes à surmonter. Maintenant, les choses sont arrivées à un point où c’est non seulement fonctionnel, mais très puissant. Beaucoup d’acteurs se sont lancés dans cette idée, si je n’en retiens que deux c’est parce que pas tous n’ont pris en compte l’accessibilité (aveugles/liseuses etc) et pas tous n’ont eu la décence de ne pas faire payer. J’ai donc retenu Iconic et Entypo. Ceux-ci ont mappés leurs icônes sur les caractères Unicode correspondant, ou sur des emplacements vides, plutôt que sur des lettre. Comme ceci :

Concrètement dans mon travail je les emplois comme ceci : pour Iconic par exemple j’ai une feuille de LESS iconic.less contenant ceci :

	[class^="iconic-"],
	[class*=" iconic-"]
	{
		&:before
		{
			#font #family .custom-sans-serif('IconicFill');
			vertical-align: middle;
			display: inline-block;
			content: "";
			width: 1em;
			line-height: 100%;
		}
	}
	.iconic-stroke:before { #font #family .custom-sans-serif('IconicStroke') }

	.iconic-aperture:before                 { content: "\e026" }
	.iconic-aperture_alt:before             { content: "\e00c" }
	.iconic-arrow_down:before               { content: "\2193" }
	[…]

De là pour utiliser une icône, soit j’applique directement la classe à l’élément auquel je veux joindre une icône :

Envoyer une image

Soit je crée une balise selon le modèle que Twitter utilise dans l’exceptionnel Bootstrap.

Les avantages

- Les icônes sont à la taille à laquelle vous les désirez, sans pixeliser ni quoi que ce soit, la magie du vectoriel
- Autant de couleurs que vous le désirez
- La possibilité d’appliquer du CSS3 dessus par-dessus comme sur n’importe quel texte : ombres, transitions, bordures, animations, et j’en passe.
- Moins de requête HTTP : seule une police est chargée et cachée plutôt qu’un éventail d’image (ceci n’est pas valable bien sûr dans le cas d’utilisation de sprintes).

Application ci-dessous dans un petit test vite fait pour mettre en oeuvre. Ça rame et tout mais c’est plus pour montrer le principe qu’autre chose.

Allez sur ce, je reviens quand j’aurai trouvé un nouveau truc à vous montrer.

Lost and found

Lundi 13 février 2012 à 23:21

En ce moment je traverse un peu une période de disette en terme de lieux à visiter. On m’en a bien envoyé deux (et je remercie la personne soit dit en passant) mais rien de l’envergure d’un complexe à la Terre d’Asile ou du faux village de The Wasp. Du coup en attendant dans ma sécheresse visuelle je rumine; tourne et retourne mes vieux clichés, et de temps à autres j’en trouve que je ne vous ai jamais montrés parfois par manque de qualité par rapport au reste de la série, parfois par simple envie de ne pas trop en mettre d’un coup.
Du coup voici quelques photos qui jusqu’à présent étaient perdues au fond de mes tiroirs virtuels, pas tout d’exception qu’on s’entende, mais de quoi occuper un peu ce blog en attendant ma prochaine série. Gardez ça en tête et soyez indulgents.

01
02
03
13 - La gorge du brasier
La gorge du Brasier
04
05 - New York City
New York City
06
07
08
09
10
11
12
14
15

LessCSS : mon coup de cœur du moment

Mercredi 21 décembre 2011 à 15:06

Je ne parle pas beaucoup de webdesign et de programmation sur mon blog. Pendant longtemps la raison a été que je ne me sentais pas forcément à l’aise avec ce que je faisais - pas assez au point par rapport aux nombreux standarts du web et à la qualité de ce qui se faisait ailleurs. Depuis le travail en agence m’a fait énormément progresser : moi qui n’avait à l’origine que quelques lointaines connaissances en PHP, ai désormais codé mon propre framework pour les sites qu’on me demande de faire. Avec gestion des templates, mise en cache des pages, code orienté SEO avec URL Rewriting et consorts, gestion du multilingue, admin intégrée etc. Le tout en OOP et conforme aux standars actuels du web (xHTML/HTML5/CSS3 et des touches de jQuery).

Le tout est plus formaté à mes propres besoins qu’à un usage public mais reste que depuis mon entrée dans le monde du travail, j’ai énormément progressé, principalement parce que je suis curieux et que j’adore apprendre sans cesse de nouvelles choses. Ma découverte du moment ? LessCSS.
Il n’est pas rare que dès que quelqu’un découvre ou redécouvre quelque chose de nouveau en webdesign, tout le monde s’emballe du jour au lendemain (voir le cas des CSS Media Queries). LessCss est à l’origine une extension Ruby qui propose d’enrichir le langage CSS via un panel de fonctions qui jusque là manquaient cruellement - le but étant de rendre le langage CSS plus flexible et lisible. Malgré son énorme potentiel (tout comme SASS, une extension CSS du même genre), la contrainte du langage Ruby a fait que le tout est jusqu’à peu resté dans l’ombre. Ce qui a changé il y a peu justement ? C’est que LessCSS est désormais proposé comme une script Javascript. Ça veut dire que concrètement tout ce qu’il y a à modifier dans son code c’est ça :

<link rel=”stylesheet/less” type=”text/css” href=”styles.less”>
<script src=”less.js” type=”text/javascript”></script>

Il suffit de changer l’extension de sa feuille de style par .less et de joindre le fichier en ligne LessCSS, et c’est tout. On a une extension CSS portative, facile à intégrer, et universelle. Mais qu’apporte concrètement LESS pour ceux qui ne connaissent pas ? Pour peu que vous ayez un peu de connaissances en CSS, voici un exemple de code LESS que vous devriez comprendre et qui vous donnera un aperçu de ce qu’on peut faire :

// Fonctions
.box-shadow (@x: 0, @y: 0, @blur: 1px, @alpha)
{
	@val: @x @y @blur rgba(0, 0, 0, @alpha);

	box-shadow:         @val;
	-webkit-box-shadow: @val;
	-moz-box-shadow:    @val;
}

// Mixins
.gras
{
	font-weight: 900;
	text-decoration: underline;
}

// Blocs principaux
div
{
	@base: #f938ab;

  	.gras;
  	color:        saturate(@base, 5%);
  	border-color: lighten(@base, 30%);

	a
	{
		text-decoration: none;

		&:hover { color: red; }
		&:active { color: blue; }
	}
	p.introduction
	{
		background-color: @base - #333;
		.box-shadow(0, 0, 5px, 0.4);

		strong { .gras }
	}
}

#header        { color: black;
  .navigation  { font-size: 12px }
  .logo        { width: 300px;
    &:hover    { text-decoration: none }
  }
}

Création de fonctions, de variables, de mixins (des propriétés que l’on pré-créer et ensuite réattribuer), mathématiques des couleurs, nesting des propriétés, et j’en passe. Le joli petit site officiel détaille mieux la chose que moi (et avec de la coloration de code surtout), toujours est-il qu’une fois qu’on y a goûté il est dur de s’en passer. Les possibilités sont vraiment nombreuses, comme par exemple cette grille dynamique en LESS.

La cerise sur le gâteau c’est - pour les soucieux de l’infime temps de calcul de LESS - les nombreux compileurs gratuits et multiplateformes qu’il existe, comme LESS.app qui vous demande un dossier de projet et qui ensuite compile des fichiers .css propres et valides en réel à mesure que vous travaillez sur vos .less. On a donc là une extension de langage qui peut-être à la fois vu comme une aide au code ou/et comme une extension matérialisant vos rêves les plus fous de design dynamique.
Je ne sais pas ce que vous allez en penser, peut-être des gens plus experimentés se prononceront-ils sur des défauts majeurs m’ayant échappés, mais pour l’instant LESS c’est mon petit coup de cœur et je ne suis pas seul.

Quatre ans en images

Vendredi 16 septembre 2011 à 21:14

Avec mon agence on a décidé – pour alimenter un peu notre blog – de chacun chaque mois y poster un petit article au thème libre. C’était mon tour pour la première fois et ne sachant trop quoi écrire je me suis dit que je parlerais photo. Bien sûr je devais présenter ce que j’avais fait depuis zéro et ça m’a poussé à faire un bilan de mon travail. Notez que deux ou trois phrases de cet article sont des phrases qui viennent de précédents articles de ce blog mais que je voulais vraiment voir figurer dans celui-ci. Si vous avez un sentiment de déjà vu, ça vient de là.
J’aurais bien mis le lien vers l’article sur le blog de l’entreprise mais il n’est pas encore en ligne. Et de toute façon tant que j’ai pas fini le redesign du site de l’agence j’ose pas vous le montrer.

—–

Le champ des thèmes que j’aurais pu aborder pour ce premier article était vaste : il y a nombre de domaines que je côtoie ou pratique et qui auraient pu figurer sur notre blog. Puis après réflexion je me suis dit que quitte à parler image et à faire le pont avec la communication, le choix le plus judicieux serait de parler photographie. Pourquoi ? Parce que la photo - de mon point de vue tout du moins - c’est à moitié de l’instinct et à moitié de la connaissance. Deux choses qui sont essentielles pour faire du bon travail de manière générale qu’il s’agisse de print ou de webdesign ; savoir composer quelque chose, allier les couleurs ou les formes. Faire de l’image et la capturer, c’est aussi étroitement lié que composer et décomposer une musique.

04

Dissension

Premiers pas

Il y aura sûrement d’autres articles photo sur ce blog parce que dans l’équipe c’est une passion qui revient souvent – ce qui est intéressant c’est que des bagages différents de chacun découlent des approches différentes. Quand j’ai personnellement commencé à faire de la photo, en mars 2007, c’était plus par principe, me dire « Ce serait intéressant de faire de la photo » plutôt qu’une envie réelle de tâter l’objectif. Puis j’ai été accroché, et j’ai continué à faire mes escapades avec pour but de chaque fois me rendre dans une ville différente et de faire des séries comme ça. Ma démarche de l’époque était simple : mettre en image les détails, textures et autres teintes que les gens croisent tous les jours sans pour autant que leurs yeux ne voient réellement. Un peu comme du Christo sauf qu’au lieu d’emballer, je voulais déballer au grand jour.
De nombreuses fois je me suis amusé aux jeux d’abstractions, d’oppositions ou de symétries. Jouer sur le détail, sur la couleur, prendre d’infimes pans de murs et ressortir de vastes murailles monochromes — c’est important parce qu’au fur et à mesure de ma démarche c’est un goût que j’ai conservé et c’est une volonté qui se lit aujourd’hui encore dans mes séries.

01

Diagonales

Les choses mortes

J’ai continué comme ça à aller de ville en ville autour de moi jusqu’à inéluctablement être à court d’endroits à visiter. Et après un premier jet d’une grosse poignée de séries allant du paysage au portrait sur fond de vagabondage urbain, je suis revenu à une série en particulier que j’avais pris un plaisir malsain à faire : Les choses mortes. C’était une série que j’avais faite durant l’automne 2009 et qui consistait pour moi en une sorte d’exorcisation d’une de mes vieilles peurs. Durant toute mon enfance j’avais vécu près d’une grande bâtisse abandonnée, encagée par un abstrait chaos d’arbres et d’herbes, et c’est une maison que longtemps j’avais cru, disons, « hantée ». Plus tard j’ai grandi au-delà de cette idée, mais j’avais gardé en moi une curiosité quant à ce que les murs meurtris de la demeure recelaient vraiment.
Alors un jour j’ai pris mon courage à deux mains – mon appareil photo dans la troisième – et j’ai escaladé ce qui restait du mur d’enceinte. J’avais passé quelques heures dans la maison à y photographier chaque parcelle dépérie de pièces laissées sans vie. Tout m’avait fasciné à l’intérieur. De l’aléatoire qui, par couches et surcouches d’objets, avait inondé les couloirs, en passant par les vestiges figés d’une époque passée. Mais surtout, j’avais trouvé là un terrain de jeu magistral à mes essais visuels. Il y a une complexité, une richesse visuelle dans des dégradations telles la rouille ou le papier-peint calciné que je n’ai jamais retrouvé ailleurs. Si j’avais eu un objectif macro j’aurais passé des heures à recadrer bosselures jusqu’à ce qu’elles n’aient plus l’air que de collines maladroites enlacées par des terres de feu.

08b - Corrasion30

Exemples de richesse dans les palettes et textures de la dégradation

J’ai réfléchi longtemps au plaisir que j’avais pris à pénétrer l’inconnu pour en ressortir avec ce que nul œil n’avait vu, et de là j’ai réorienté mon style et ai fait de mon devoir de collecter autour de moi les lieux morts qui me venaient. Comme des papillons sur un mur, je m’étais mis en tête de visiter chacune de ces visions d’abandon devant lesquelles les gens passent en voiture ou à pied en se murmurant tout bas « Des fois je me demande ce qu’il peut y avoir dedans ».
Moi, je savais. J’avais foulé du pas ces lieux esseulés et m’était laissé absorber par leur atmosphère aliénante. Les complexes arabesques rousses de métal décrépi, les murs arrachés, et l’eau croupie qui par vastes traînées venait assombrir le papier peint et gorger le plancher. Il y en a qui aiment prendre des centaines d’images d’infinis paysages, moi je m’étais épris des recoins enténébrés qui les choses mortes accueillent.

05 - The Life and Death of a Wasp1

The Life and Death of a Wasp - Sans titre

Forteresses techniques

Mon parcours a de longs mois durant continué comme ça. Je repérais un endroit que j’estimais futur théâtre de mes errances, je m’armais de mon appareil, et avec la retenue d’un courant d’air passant dans l’embrasure d’une porte, je m’insufflais par la première fenêtre cassée que je trouvais. Photographier dans des lieux abandonnés m’offrait un tout nouveau challenge technique, parce que cela revenait à prendre des images dans les pires conditions imaginables — et à aimer ça. Nombre des séries que j’ai faites se sont déroulées dans les lieux ou peu voire pas de lumière ne filtre, où l’exiguïté de chaque pièce me faisait sans cesse chercher des angles nouveaux. J’ai essayé un, puis deux, puis trois trépieds avant d’en trouver un capable de se positionner de manière stable entre des piles de décombres, tout en me permettant de l’emmener par Dieu sait quelle ouverture s’étant percé dans le béton des murs.

Ce manque de luminosité a très vite donné du fil à retordre à mon appareil — depuis le début de ma démarche des « Choses Mortes » à aujourd’hui j’ai travaillé avec un Canon EOS 350D. Un appareil qui s’il a des qualités indéniables, souffre de son ancienneté et a tendance à très vite voiler les images de grain, même en réglant l’ISO au plus bas. Pour les non initiés, je laisse Wikipedia expliquer à ma place :

Plus la valeur de la sensibilité est élevée, plus la pellicule (ou le capteur) est sensible à la lumière, et donc plus la quantité de lumière nécessaire à une exposition correcte est faible. Si l’on peut être tenté de prendre systématiquement une pellicule de forte sensibilité (de type ISO 400/27° par exemple), il faut savoir que cela a une influence sur l’image finale - par exemple, un film rapide montre un grain plus prononcé et une définition plus faible qu’un film lent.

Dans les lieux sans lumière comme ceux-ci, ce temps devient vite le rival de vos clichés réussis : la moindre microseconde en trop peut rendre l’image floue, et sur le petit écran de l’appareil c’est quelque chose qui ne se remarque pas forcément. J’ai raté de nombreuses images comme ça, et aujourd’hui encore j’appuie une bonne dizaine de fois sur le déclencheur – par paranoïa – juste pour être sûr d’avoir la photo que j’avais en tête.
Maintenant que je me suis fait à l’idée que mes images ne seront jamais parfaites j’ai plus ou moins appris à faire avec ce grain et quelque part j’en ai fait un sceau d’authenticité. À la manière de vieux films que l’on reconnaît aux cicatrices de leur pellicule, j’ai mêlé ce bruit visuel à ce qui faisait que mes photos étaient de réels témoignages des endroits que j’ai visités.

0809

Sans titre - Out through the winter throat

La frontière noire

Il est à savoir que – en France ou ailleurs – je suis loin d’être le seul à m’être mis en tête de revisiter les vestiges encore chauds du passage de l’homme. Le terme officiel englobant la chose étant « l’urbex » (pour Urban Exploration). Et si je m’y adonne pour le principal intérêt photographique de la chose, beaucoup le font par simple désir d’aller au-delà des limites imposées. Et j’avoue que c’est un aspect qui m’a toujours plu également — le nom de l’activité paraît exagéré mais il y a bel et bien un côté exploration à la chose. Un lieu abandonné étant quasi tout le temps condamné, une bonne partie du travail consiste à trouver le point d’entrée et ce, malgré les nombreux panneaux, cadenas et issues murées qui se dressent usuellement sur ma route. Tenir tête à l’interdit de telle manière, c’est quelque part à la fois excitant et gratifiant ; quelque chose de puissant dans l’acte de marcher tête haute devant les mille et une chaînes malhabilement jetées en travers du chemin, pour enfin écarter un bout de grillage et se faufiler telle une ombre. Par-delà les frontières imposées et les interdits restés non-dits.
L’exploration urbaine c’est accepter de plonger dans le plus absolu des inconnu, là où même les yeux des abysses ne portent, et affronter les risques qu’on pourrait rencontrer.

Risques oui car il y a tout d’abord le facteur humain qui, s’il reste rare, n’est pas à négliger. De tous les lieux que j’ai arpentés, pas un n’avait été traversé des vagues destructrices des divers squatteurs et sans abris. C’est une constante, un peu comme si à la fermeture d’un lieu, on y envoyait une équipe chargée de renverser les meubles, déchirer le papier-peint et disperser quelque menues bouteilles vides pour le côté « authentique » de la chose. Peu importe que l’endroit ait été fermé récemment ou pas, tous portent ces mêmes stigmates caractéristiques qu’inconsciemment on a appris à reconnaître : le verre cassé, les tags sur les murs… Mais surtout ces objets modernes et propres qu’on repère à des kilomètres de distance, jetés entre les dunes de débris et poussière comme des oasis égarées.

Risque aussi car un lieu délabré et condamné l’est souvent à raison : infrastructures fébriles pour les maisons, dangers biologiques pour les friches industrielles, et accessoirement, l’éternel risque de ne jamais retrouver son chemin vers la sortie. L’exploration urbaine ça englobe tant les friches que les catacombes et nombre sont ceux s’étant aventurés dans les dédales sous-terrains d’une quelconque usine sans que jamais on ne les voit en remonter. C’est toujours quelque chose que j’ai trouvé glacial : la simple pensée que l’homme ait un jour pu percer dans la terre des couloirs infinis au cœur desquels il se perdrait lui-même.
Je ne pense pas un jour pouvoir faire de photos dans de tels lieux : l’oppression seule de ne pas voir la lumière du jour élèverait de véritables couleuvres d’angoisses le long de ma colonne vertébrale. Je reconnais toutefois le mérite et le courage de ceux qui osent s’enfoncer toujours plus loin dans un labyrinthe, par pur goût de l’exploration ou de la photographie.

09 (No Mercy)

No Mercy - Sans titre

Altérations partielles

C’est sans doute quelque chose qui va se voir en regardant mes photos, mais je fais partie des gens qui pensent qu’une image n’est pas tant faite pour refléter la réalité, mais plus refléter la vision du photographe — montrer ce qu’il y a derrière plutôt que devant l’objectif. De fait je n’ai jamais réellement trouvé culpabilité dans le fait de retoucher mes photos, bien que cela soit en partie dû au fait que ma manière de les retoucher a grandement évolué.
Quand j’ai commencé la photo, venant de milieux où il m’arrivait souvent d’avoir à créer une ambiance sur Photoshop en partant de zéro, j’ai eu tendance à avoir la main lourde sur mes premiers clichés. J’isolais certaines couleurs, je modifiais vastement la luminosité et la profondeur d’éléments… en un mot comme en cent je traitais mes images comme j’aurais traité n’importe quoi d’autre : sans forcément de respect pour le travail photographique en lui-même. C’est aussi dû au fait qu’à l’époque j’apportais beaucoup (trop) d’importance au concept de “photo”, je ne les publiais qu’une par une, les titrais toutes, leur mettait un cadre, et au final les posais à tort sur un piédestal. Et plus j’avançais, et plus les critiques négatives se faisaient grandissantes. Me voyant accusé de « maquiller la réalité », j’ai lentement perdu confiance en moi jusqu’à arrêter de sortir pour prendre des photos. J’ai posé mon appareil de l’époque – un petit compact – et ai attendu.

L'Aîné

Exemple d'une des photos de l'époque : L'Aîné (2008)

Puis au noël suivant j’ai eu mon premier reflex, celui que j’ai encore aujourd’hui. Et lors d’une randonnée que je devais faire avec mon père j’ai décidé de prendre des photos tout du long. Je suis revenu chez moi avec une série d’une vingtaine d’images, maladroites certes, mais que je n’avais pas touchées. Je les avais montrées telles qu’elles, sans titre ni cadre, à la suite les unes des autres. Unies seulement par le sentiment de cohérence qui se dégageait des couleurs et de l’ambiance de l’ensemble. C’était ma toute première série et le début d’un long parcours. De là j’ai commencé à ne plus retoucher si ce n’est les réglages habituels de chaque photographe : pousser un peu les contrastes par-ci, rehausser la lumière d’appoint par là…
Il n’a pas fallu quelques mois avant que je retombe dans l’excès et sorte des photos surcontrastées et visuellement violentes. Toujours en modifiant les mêmes paramètres – je n’étais pas revenu complètement en arrière – mais telle de l’eau qui trouve toujours passage, mon naturel avait trouvé moyen de revenir à ses envolées artificielles. En résultait des photos sombres, beaucoup trop de pseudo noir et blancs, et j’en passe. Les critiques ont a nouveau grondé et la main tremblante sur mon appareil, j’ai courbé l’échine et me suis rangé une seconde fois.

1

Exemple d'une des photos de l'époque : Lame de fond (2009)

Le temps passa, et de la même manière que c’est une randonnée qui m’avait ramené à la raison la première fois, ma seconde remontée vers l’air libre se fit happé dans les mailles omniprésentes de la nature. Durant l’été 2009 je suis parti en sortie photo avec ma cousine dans un village de montagne où j’avais été durant mon enfance. Quand je suis rentré chez moi je n’ai pas eu l’envie de faire quoi que ce soit à ces images tombées dans mes mains presque par hasard. Je me suis juré de ne plus jamais tromper la réalité comme je l’avais fait dans le passé, ai attendu six mois, et en plein coeur de l’hiver j’ai pour la première fois fait succession à ma série des choses mortes en allant visiter une gare abandonnée.
Ma volonté à l’époque et aujourd’hui encore fut de rompre visuellement avec mes séries précédentes en me focalisant sur une technique nommée le virage partiel, plus particulièrement le split toning. Le toning en soi consiste à faire virer la teinte dominante d’une image vers une autre : rendre la photo légèrement plus verte, plus bleue, plus jaune. Comme dans un film où les scènes glaciales sont voilées de ce sombre masque cobalt. Le split toning c’est la même chose mais en mêlant deux couleurs : pour moi du brun et du vert.

Ça a donné des photos légèrement orangées par moment, légèrement vertes de l’autre, parfois bleues. Mais surtout cela donnait au tout une ambiance reconnaissable immédiatement, celle de vieilles photos aux couleurs hésitantes. Et dans ma démarche des choses mortes ça a toujours été quelque chose que j’ai recherché : faire passer en une image le sentiment d’être transporté à une autre époque, un autre lieu. Capturer un bâtiment en ruines dévoré par le temps, et l’espace de quelques instants, pouvoir montrer au monde une image qu’on aurait pu prendre dans les fonds de l’union soviétique il y a trente ans.

0104 - Tunguska
051

Mai 1965 (dominante verte) - Tunguska (mélange brun/vert) - Sans titre (dominante brun) - Sans titre (dominante bleue)

C’est entre autre cet aspect qui m’avait capturé lors de ma visite de la maison abandonné. Ces hordes de magazines des années 50, 60, ces vieux vinyles, ces objets dont le but s’est estompé dans les années. Visiter un lieu défunt c’est se mettre soudainement à s’imaginer qui a vécu là et comment ils y ont vécu ; c’est se plonger dans le quotidien de bâtiments redevenus poussière. Je me suis toujours demandé comment était la vie dans les décennies passées — comment vivaient, respiraient et s’amusaient les gens par-delà les filtres sépias et le trouble des noirs et blancs. Et c’est une question qui frustre parce que la réponse est si proche qu’elle en est terrifiante. Nous sommes entourés de gens ayant vécus en des temps qu’on n’arrive même plus à concevoir autre que par grandes dates, pendant que l’intérêt tout comme les souvenirs restants de ces époques, se calcinent graduellement dans les flammes véloces de la modernité.
C’est ça que j’ai voulu montrer et c’est ça que par moments je pense accomplir. Alors même si j’ai sans doute tendance à encore trop toucher mes photos, leur aspect convient à ma vision actuelle des choses. Évoluer c’est se réinventer perpétuellement, s’améliorer, changer sa perception du monde.
Moi par touches de brun et de vert, je couche sur image ce que mon esprit voit. Plutôt que ce que l’appareil, dans toute sa duperie et son incapacité à ne pas copier la réalité, veut me montrer. Ça ne veut pas dire que ma petite vérité vaut plus que celle du voisin, ça veut simplement dire qu’elle a le mérite d’être réellement mienne et de surcroît, d’être sincère.

0319

Sans titres

Excroissance

Je parlais peu avant de se réinventer et il y a un point sur lequel j’ai beaucoup évolué au fil du temps. À mesure que j’avançais dans ma reconquête des fantômes de l’urbanisme, mon ambition vis-à-vis d’eux grandissait. Moi qui avais commencé mon parcours par la menue porte d’une maison, j’avais bien vite projeté mes excursions dans des fantasmes de toute autre envergure. Des gares, des hôpitaux, jusqu’à mon accomplissement personnel de la visite d’un projet de lotissement et ses sept bâtiments de quatre étages. Mais toute comme l’ennui peut naître des choses dont on se délecte le plus, il me manquait un sentiment de progression et cette envie de mettre en scène comme je l’avais fait avec les passants lors de mes envolées en ville. Alors un jour j’ai posé mon trépied, et ai plongé de l’autre côté de l’objectif — une première fois, puis une seconde, puis encore et encore jusqu’à ce que mes autoportraits cannibalisent les autres types de photos que j’avais pris l’habitude d’employer.

Mes postures furent dans un premier temps lâches, au mieux. J’avais peur de la caméra et de ce qu’elle pouvait montrer de moi, je me dissimulais sous les ombres, baissait la tête ou ne laissait entrevoir que de minces parcelles d’expressions neutres. Se prendre en photo pour la première fois quand on a la volonté de montrer son travail au reste du monde, c’est un exercice au combien difficile. Il est aisé de prendre n’importe qui en photo et de laisser l’image parler, parce qu’importe ce qu’elle semblera dire ce sera un message qui nous conviendra. Si la personne laisse échapper un sourire complice, et bien tant mieux, cela montrera à quel point elle est malicieuse ! Qu’elle le soit ou pas n’importe pas réellement, le résultat est là. C’est un tout autre enjeu de s’autocapturer, parce qu’on a conscience de qui on est et de ce qu’on veut faire transparaître dans le visuel. Et arriver à une émotion précise plutôt que la première venue, c’est un combat perpétuel entre l’objectif et soi-même.

05 (Le Serpent et l'Arc-en-ciel)06 (Terre d'Asile)

Le Serpent et l'Arc-en-ciel - Terre d'Asile

Avec les séries j’ai pris de l’assurance, ai accepté ce que les gens verraient de moi en image. De là j’ai pu me mettre en scène — je n’étais plus moi-même couché sur papier, j’étais une silhouette inconnue sur fond de statique. Plus que visiter les lieux, je voulais les habiter ; j’avais trouvé fascination dans le contraste crée par l’insertion artificielle d’une notion de vie en des décors qui, s’ils avaient un jour respiré le même air que nous, ne s’animaient désormais plus qu’au rythme du feu d’ombres qu’était le passage du jour à la nuit.
C’était un peu comme replacer un poisson dans un aquarium vide.

Je continue aujourd’hui encore à faire de la photo même si mes séries se sont faites rares. N’étant pas dans une région où abondent les bâtiments abandonnés, je me nourris des quelques occasions qui se présentent à moi, tout en cultivant dans un coin la crainte de ne plus jamais retrouver d’endroit comme ceux que j’ai déjà visités. Plus qu’une phobie de la page blanche, il y a plutôt à imaginer une pénurie mondiale de papier, ne me laissant plus que moi seul avec mon appareil.
Bien sûr un bon photographe ne trouve pas le sujet, il le conçoit à partir des maigres éléments que son environnement daigne lui tendre. De mon côté, je ne fais qu’attendre que le sujet se pose sur ma main comme un insecte curieux.
Ce ne sont pas des photographies, ce sont des papillons.

2007

Sans titre - L'Ouragan

Il y aurait sûrement d’autres choses à dire, mais cet article est déjà plus long que de raison. En espérant vous retrouver sur ce blog avec le reste de l’équipe pour partager cette étincelle créative en chacun qui fait que plus qu’une agence de communication, nous sommes des personnes prenant à cœur la création et l’originalité en elle-même.