Ze Technology

Auparavant, je maintenais un blog entièrement dédié à la photographie et à mes projets. Dorénavant je rédigerai avec parcimonie quelques expériences ou retours d’expériences photographiques ici même. Un peu d’art et d’art numérique dans ce monde très binaire, ça ne peut pas faire de mal.

Equipé depuis plusieurs années d’un réflexe, force est de constater qu’il m’était impossible d’emporter ce dernier partout avec moi. Quand bien même je suis un adepte de la focale fixe, notamment mon 28mm très peu encombrant, on sacrifie la compacité pour jouir d’une qualité et réactivité accrue. Réalisant que je « manquais » beaucoup trop de photos juste parce que je n’avais pas le bon outil au bon moment, j’ai décidé de trouver mon compagnon photographique idéal.

Aux premières annonces du Fujifilm X100 — le grand frère du X10 — je sentais le vent tourner. Enfin un retour aux fondamentaux de la photographie ! De beaux boitiers, bien construits, avec des modes manuels. Quand Fujifilm a continué sur sa lancée pour sortir le X10, j’étais conquis. Présentation rapide, pour les non initiés : il s’agit d’un compact haut de gamme, qui a pour lui un viseur optique exceptionnellement clair et large, un capteur d’excellente facture qui, bien que plus petit que les réflex se montre 2 fois plus grand que ses concurrents, et propose de maîtriser le zoom manuellement, comme sur un objectif de réflex. Avec toutes ces spécifications, le Fujifilm X10 ne tient certes pas dans une poche, mais se trimballe facilement n’importe où.

Mon avis

Les spécifications papier, c’est bien, mais à quel point suis-je séduit en pratique ? Mes premières craintes se portaient sur l’utilisation du viseur optique. Me voilà bien obligé de reconnaître que ce dernier est largement utilisable. Il n’y a certes pas de correction des problèmes de parallaxe, et aucune information n’est affichée en surimpression, mais sur des plans larges et des sujets éloignés, on peut parfaitement lui faire confiance. Et quel confort d’en profiter ! Pour des sujets rapprochés, si on commence à s’approcher des 112mm que couvre le zoom, le défaut de parallaxe est bien présent et il faut s’y accoutumer, avec un peu de pratique.

Le second critère décisif pour moi était la réactivité de l’appareil. J’étais prêt à sacrifier une partie de la qualité des réflex (je ne suis pas un adepte des images parfaites au piqué absolu), mais certainement pas la réactivité ! Là encore, je suis tout sauf dérouté. L’autofocus se montre faste comme peu d’autres, et le déclenchement franchement réactif. A confirmer, mais je devrais pouvoir faire sans soucis de la photo de rue ou évènementiel avec un tel compact.

Bien évidemment, cela ne fait que quelques semaines que je vagabonde avec mon X10. Le temps me dira si cet appareil est robuste et aussi fiable qu’il en a l’air. Gageons que dans le pire des cas, la marque ait démontré qu’il y a une véritable attente autour de ce créneau.

Lien : Site officiel Fujifilm X10

Image par Mogmi.

Mon dernier article laissait penser que je reprenais goût pour la programmation fonctionnelle, ayant apprécié mes études à bases d’OCaml. Depuis, j’ai effectivement eu l’occasion de jouer avec Scala, avec Haskell. Je ne suis pas spécialement un pro-FP ou un anti-POO, ni même l’inverse. Ce qui m’intéresse, ce sont les enjeux derrière chaque paradigme. Que vais-je pouvoir tirer de telle ou telle techno ? Au fond, qu’est-ce que je veux vraiment faire ?

Why learning Haskell/Python makes you a worse programmer ?

L’auteur évoque ses difficultés de revenir à la réalité, à la réalité du Python, du C#, du Java ou du C++ (pour les plus chanceux). Je vais dans ce billet donner mon point de vue. De la philosophie de la programmation fonctionnelle, je retiens notamment la gestion des listes et structures récursives, le pattern matching, l’immutabilité, les monades, la lazy-evaluation. J’en oublie, mais ce sont là les éléments que j’estime utiliser régulièrement, au naturel.

Sans prétention, la manipulation de ces concepts fait que le programmeur acquière une certaine gymnastique qui n’est — à mon sens — que bénéfique. Gestion de la concurrence ? Modularité ? Travail en équipe avec d’autres adeptes de la FP ? Du bonheur. Je ne parle pas spécialement de performances, mais seulement d’architecture logicielle.

Seulement voilà, dans la vraie vie, difficile de débarquer, imposer une industrialisation de Haskell ou d’OCaml. Difficile de dire à des développeurs ayant l’habitude d’imbriquer trois niveaux de boucles for ou while de réfléchir par récursion. Difficile de remettre en question les modélisations objets de projets industrialisés recoupant plusieurs dizaines ou centaines de développeurs, sous prétexte que de nombreux bugs pourraient être évités en appliquant des mécanismes d’immutabilité.

C’est bien là le problème. Renouer avec les fonctions impures à outrance (se dit des fonctions à effet de bord), les API approximatives de Java ou PHP n’est pas synonyme de plaisir. L’argument de la « démotivation » lancé par Luke sur son blog est réel. On écrit du code bizarre, rien n’est séduisant.

En revanche, j’estime que ça me force à comprendre comment le langage fonctionne, et à ne jamais faire confiance à son fonctionnement. En 2 mois de temps, j’ai appris un nombre impressionnant de choses sur Java, notamment sur sa gestion de la concurrence (faut-il que je me sente honteux de tout juste découvrir que le langage propose des CountdownLatch ?) En tout état de cause, c’est mon arme contre la démotivation.

Un compromis intéressant me semble émaner de Scala. Son interopérabilité parfaite (?) avec Java lui donne l’avantage instantané de participer à toutes les logiques d’industrialisation. Scala, pour rappel, est un langage multi-paradigme, qui aime la POO autant que la FP ou l’AOP. Un méli-mélo, vous dîtes ? C’est sans doute vrai. Et je n’aime pas les mélanges incohérents, vraiment pas. Mais en pratique, force est de constater que, pour le moment, c’est un moyen assez élégant de faire en sorte que chacun puisse y trouver son compte. Il m’est arrivé, par exemple, de parcourir un graphe en Scala et d’appliquer un traitement en une ligne de code, via le paradigme map/reduce (mais pas distribué, cette fois-ci). Scala peut également obliger les développeurs à formaliser leurs types de retours en Option[Integer] si la fonction peut retourner l’équivalent de null ; tout en conservant la possibilité d’écrire des boucles itératives aux moments opportuns, ou de modéliser ses concepts sous formes de classes, sans rien changer — ou presque — des habitudes prises en Java.

Oh, et tant qu’on en parle, je vous invite à lire le billet de Marwan sur la FP. C’est aussi un élément déclencheur de cet article.