Archives de
Auteur : Emilie Chung

Pilier Rails 5 – La beauté du code tu célèbreras

Pilier Rails 5 – La beauté du code tu célèbreras

On écrit du code non seulement pour être compris de l’ordinateur ou d’autres programmeurs, mais aussi avec une intention esthétique. Un code qui plaît à l’œil a de la valeur en tant que tel et doit être encouragé au maximum. Cela ne veut pas dire que l’aspect esthétique est l’unique priorité, mais il a sa place aussi bien que les autres dans les critères de choix du programmeur

Mais qu’est-ce exactement qu’un beau code ? Quand on parle de Ruby, un beau code se situe souvent au croisement entre un assemblage d’idiomes Ruby et d’un langage customisé et spécifique à un domaine.

Voyons un exemple simple issu d’Active Record :

  class Project < ApplicationRecord

     belongs_to :account

     has_many :participants, class_name: ‘Person’

     validates_presence_of :name

   end

Cela ressemble à du DSL mais c’est une définition de classe avec trois appels de méthodes de classe qui prennent en paramètre des symboles et options. Il n’y a rien de sophistiqué, mais ces quelques lignes, aussi simples que jolies, offrent autant de pouvoir en plus que de flexibilité.

Une partie de la beauté de ces lignes de code vient de ce qu’elles honorent les principes mentionnés ci-avant, dont celui de Convention plutôt que Configuration.

Lorsqu’on crée une association avec un belongs_to :account, par convention on référence un modèle « Account » stocké dans la table nommée « accounts » via la clé « account_id ».

Un autre exemple du système de migrations de base de données :
   class CreateAccounts < ActiveRecord::Migration
     def change
       create_table :accounts do |t|
         t.integer :queenbee_id
         t.timestamps
       end
     end
   end

Le programmeur déclare une classe de façon conventionnelle, comme la sous classe ActiveRecord::Migration qui implémente #change, et le framework peut faire toute la plomberie autour, et sait que c’est cette méthode qu’il doit appeler. Dans le cas de ces migrations, cela va non seulement permettre d’appeler rails db:migrate pour mettre à jour la base de données avec cette nouvelle table mais aussi de la supprimer avec un autre appel.

Mais parfois, un beau code peut être plus subtil, et plutôt que de le rendre aussi bref que puissant, le challenge pourra être d’avoir une écriture fluide et bien rythmée.

Prenons ces deux lignes :

if people.include? person

if person.in? people

Même si le résultat est le même, le style et le focus sont légèrement différents. La première ligne se focalise sur la collection, tandis que la seconde se concentre sur la personne. Même si les deux lignes ont quasiment la même longueur, la deuxième semble beaucoup plus belle et peut susciter un réel plaisir esthétique pour le programmeur lorsqu’elle est utilisée dans un cas où la condition concerne la personne. 

Pilier Rails 4 – Un paradigme unique tu refuseras

Pilier Rails 4 – Un paradigme unique tu refuseras

Il est toujours tentant de choisir une seule idée centrale pour sous-tendre votre architecture et de la suivre jusqu’à sa conclusion logique. Cette méthode séduit plus d’un programmeur. Rails est à l’opposé de ce principe.

Rails n’est pas un tissu uni et lisse, mais plutôt un patchwork, composé d’une variété d’idées et de paradigmes, dont certains qui pourraient sembler incompatibles s’ils étaient combinés deux à deux. Mais Rails n’est pas un championnat de la meilleure idée où un seul vainqueur serait choisi.

Prenez les templates qu’on utilise pour construire le view dans notre graphe Rails MVC.  Par défaut, tous les assistants qui nous permettent d’extraire du code de ces templates sont juste une bouillabaisse de fonctions, très semblable à une soupe PHP. Mais cette bouillabaisse fonctionne parfaitement lorsqu’on doit présenter des fonctions individuelles qui n’ont que rarement besoin d’interagir.

Cela ne veut pas dire qu’on n’a pas besoin de temps en temps d’avoir recours à quelque chose d’orienté objet lorsqu’on construit des views. Le concept de Presenters, dans lequel on emballe de nombreuses méthodes interdépendantes les unes des autres et les données en-dessous, s’avère parfois un antidote parfait à la bouillabaisse de fonctions. Mais cela arrive rarement.

La flexibilité idéologique de Rails lui permet de résoudre une large gamme de problèmes. La plupart des paradigmes individuels conviennent parfaitement pour résoudre un certain type de problèmes mais sont inadaptés et trop rigides dès qu’ils sont sortis de leur zone de confort. Appliquer des paradigmes en couches superposées permet de couvrir toutes les zones à problème et rendent le framework final plus puissant et bien plus flexible que tout autre paradigme individuel.

Mais cette flexibilité a un coût : elle requiert de maîtriser non seulement la programmation orientée objet mais également d’avoir pas mal d’expérience en programmation procédurale et fonctionnelle.  Cette contrainte concerne également les sous-langages de Rails : il est ainsi fort utile de maîtriser Javascript pour les views ou SQL pour résoudre quelques queries un peu plus complexes, du moins pour pouvoir profiter au mieux de toutes possibilités qui s’offrent à vous.

La seule façon de gérer cette contrainte est d’adopter la technique de la tortue plutôt que celle du lièvre pour apprendre en chemin, patiemment. Ce qui veut dire qu’au départ vous ne comprendrez pas forcément chaque aspect du framework mais cela ne vous empêchera pas de faire quelque chose de simple qui aura une réelle valeur.

Pilier Rails 3 – Un menu omakase tu utiliseras

Pilier Rails 3 – Un menu omakase tu utiliseras

Comment savoir quel plat commander dans un restaurant quand on ne sait pas ce qui est bon ? Si vous laissez le chef choisir pour vous, vous avez de fortes chances de déguster un bon repas. Tel est le principe de l’omakase.

En matière de programmation, ce principe consistant à laisser des experts choisir pour vous est proche du principe de Convention plutôt que Configuration mais à un niveau plus macro. Alors que le premier se concentre sur la meilleure façon d’utiliser des frameworks individuels, omakase se focalise sur le choix des frameworks et comment les assembler les uns avec les autres. Ce principe contraste donc avec la tradition forte en programmation de présenter les différents outils disponibles comme des choix individuels et de laisser au programmeur le privilège (et le fardeau) de décider le(s)quels il va utiliser.

Vous avez probablement entendu souvent ce conseil : « Utilisez le meilleur outil pour accomplir la tâche », mais la question de quel est le « meilleur outil » est souvent plus difficile à trancher qu’il n’y paraît au premier abord. Ruby a fait le choix de réduire le privilège du programmeur individuel, celui de choisir chacun de ses outils, au profit d’un plus grand bien : une boîte à outil plus performante pour tous.

Les bénéfices sont légion !

  • La force du nombre : l’expérience partagée par le nombre d’utilisateurs de Rails offre une base saine pour partager, débattre, et apprendre les uns des autres,
  • Les utilisateurs travaillent tous à améliorer la même boîte à outil : en tant que framework complet (Full Stack Framework), Rails inclut une variété de parties mobiles qu’il est important de savoir assembler. La plupart des difficultés rencontrées dans les logiciels provient non pas des composants individuels mais des interactions. Le travail commun de l’ensemble de la communauté Rails permet  de mieux comprendre et maîtriser ces interactions,
  • Des substitutions possibles mais pas obligatoires : si Rails est une pile de composants fonctionnant selon le principe omakase, il est toutefois possible de remplacer certains de ses frameworks et librairies par d’autres composants, mais ce n’est pas une obligation. Ce qui signifie que vous pouvez prendre le temps de développer une palette que vous maîtrisez bien avant de penser à remplacer certains de ses composants.
Pilier Rails 2 – Les conventions tu adopteras

Pilier Rails 2 – Les conventions tu adopteras

Cette semaine, nous poursuivons notre série de billets blog sur la Doctrine Rails avec le Pilier 2, qui préconise les conventions plutôt que les configurations.

L’un des premiers slogans de Rails a été :

« Chacun d’entre vous N’EST PAS un magnifique et unique flocon de neige. »

Le postulat était qu’en renonçant à un individualisme aussi tentateur que vain, il serait plus facile d’échapper aux complications liées à la prise de décisions quotidiennes et d’avancer plus rapidement sur les questions réellement importantes.

Une des missions de Rails est ainsi de dégraisser le mammouth né de l’accumulation de décisions auxquelles doivent faire face chaque jour les développeurs. Des centaines de ces décisions ont juste besoin d’être tranchées une seule fois et si quelqu’un d’autre que vous peut le faire, tant mieux ! En effet, que vous importe le format dans lequel vos identifiants de base de données sont décrits ? Est-ce une décision digne de délibérations récurrentes ?

Le passage de la configuration à la convention permet non seulement de se libérer des affres de la délibération récurrente, mais aussi d’approfondir le niveau d’abstraction. La force des bonnes conventions est qu’elle permettent des gains de temps et de productivité sur un vaste ensemble de fonctions.

De plus, les conventions facilitent la maîtrise de Rails par les débutants qui peuvent ainsi créer d’excellentes applications sans forcément savoir que telles ou telles conventions existent ou pourquoi elles existent. Il leur suffit souvent de comprendre comment les pièces du puzzle s’assemblent, ou plus concrètement de regarder les autres applications créées pour comprendre comment s’imbriquent les pièces. En fin de compte, l’imposition d’une contrainte confère même aux esprits les plus rebelles davantage de liberté.

Cependant, le pouvoir de la convention n’est pas sans danger. Il est aisé de croire que chaque aspect d’une application peut être conçu à partir de templates prédécoupés, alors qu’en réalité, la plupart des applications valables contiennent quelque chose d’unique, même un élément mineur. Le plus difficile reste donc de savoir quand s’écarter des sentiers battus de la convention et d’être capable de se montrer créatif.

Les 8 Piliers de la Doctrine Rails : Pilier 1 – Le bonheur des programmeurs tu assureras

Les 8 Piliers de la Doctrine Rails : Pilier 1 – Le bonheur des programmeurs tu assureras

Ruby on Rails ou ROR pour les intimes, framework web libre écrit en Ruby, connaît un succès grandissant et rassemble une communauté de plus en plus importante et passionnée.

Selon David Heinemeier Hansson (DHH), créateur de Ruby on Rails (2004) et de l’outil de gestion de projet Basecamp dont RoR est issu, une des réalisations majeures de Rails a été d’unifier et de cultiver une tribu fortement soudée autour d’une pensée variée et peu conventionnelle sur la programmation.

DHH a rédigé en janvier dernier un article très intéressant listant et explicitant les 8 piliers de Ruby on Rails qui plus qu’un framework, constitue une véritable philosophie de la programmation et du métier de programmeur selon lui:

Nous lançons donc aujourd’hui une série de billets hebdomadaires pour vous présenter les 8 piliers de la Doctrine Rails. Notre série de billets constitue une synthèse du point de vue de DHH sous-tendant la création de chaque pilier, dans une perspective de découverte d’un aspect « culturel » de la programmation, à savoir la création d’un langage informatique et l’importance des valeurs qui peuvent sous-tendre cette création. Toutefois, si nous tenons à restituer les idées clés avancées par DHH, nous ne partageons pas forcément l’ensemble de ces idées et tenons à rester neutre par rapport à ses arguments. Nous espérons que vous lirez ces billets avec le même regard critique que nous avons eu pour les écrire, et qu’ils vous permettront d’avoir une lecture objective sur la création de Ruby on Rails.

Pilier 1. Le bonheur des programmeurs tu assureras

Ce premier pilier est issu tout droit du principe à l’origine de la création de Ruby : placer le programmeur sur un piédestal. En se mettant au service du bonheur des programmeurs, Ruby s’est placé dès le départ en porte-à-faux avec les environnements de programmation les plus populaires :

  • Là où Python soutient qu’il n’y a qu’une seule façon de faire quelque chose, Ruby se délecte des subtilités et des nuances d’expression de la programmation.
  • Là où Java s’efforce de protéger les programmeurs de leurs propres faiblesses, Ruby les encourage à prendre des risques, quitte à les pousser à l’autodestruction.
  • Là où Smalltalk milite pour la clarté du message, Ruby accumule les mots-clés et structures avec un appétit gargantuesque.

Et c’est bien ce qui a rendu Ruby si attractif aux yeux de DHH  comme de nombreux autres programmeurs après lui. Pour DHH, la découverte de Ruby a été une véritable révélation, un passage  de« faire de la programmation parce qu’il avait besoin de programmer » à « faire de la programmation parce qu’il en est tombé amoureux comme mode d’expression et exercice intellectuel ».

Plus qu’un langage, Ruby est une vision, une contre-culture, un lieu où les marginaux de la programmation peuvent se rassembler et ressentir un vrai sentiment d’appartenance.

Pour donner un exemple concret, prenons un principe souvent associé à Ruby dans un premier temps : le principe de moindre surprise (Principle of Least Surprise), selon lequel Ruby devrait se comporter de manière prévisible (par contraste avec Python). Mais ce principe présentait un problème, il était intrinsèquement subjectif : en effet, prévisible pour qui ? Plus la communauté Ruby s’élargit, plus ce principe devint une source de débats sans fin et finit par s’effacer du devant de la scène. Rails a été conçu selon un principe similaire mais quelque peu différent, le Principe du Plus Large Sourire, qui doit permettre à l’utilisateur de profiter au mieux de sa vie.

Il peut sembler difficile de mesurer le degré de bonheur que Rails permet d’atteindre. Mais à un niveau macro, ce bonheur est palpable dans la communauté, qui se targue de meilleures conditions de travail et de vie.

5 bonnes raisons de participer à la Code Week 2015

5 bonnes raisons de participer à la Code Week 2015

L’heure de la Code Week 2015 a sonné ! Ce samedi 10 Octobre marque le début d’une  semaine dédiée au code et à la programmation numérique dans toute l’Europe. Toxicode s’est mobilisé pour vous proposer tout au long de la semaine des événements en Région Parisienne et à Rennes et vous donne 5 raisons imparables de ne pas rater ce rendez-vous à échelle européenne.

Parce que c’est hyper tendance

La Code Week, c’est avant tout des opportunités de rencontres et d’échanges dans toute l’Europe. Et d’année en année, les événements organisés se font plus nombreux, et visent un public plus large. Il faut dire que la question de l’apprentissage du code est désormais devenue centrale et mobilise de plus en plus le gouvernement comme les acteurs sociaux. En 2014, on a compté environ 300 événements organisés rien que dans la France ! Cette année, Toxicode a mis les petits plats dans les grands et s’est associés à différents partenaires pour vous proposer des ateliers ludiques et innovants autour de l’apprentissage de la programmation (voir programme ci-dessous).

Parce qu’il y aura de l’action

La Code Week, c’est des ateliers ludiques pour les enfants (ateliers Scratch), des activités manuelles pour mettre les mains dans le cambouis (Makey Makey), de la création de jeux vidéo y compris la programmation de comportements d’un héros et de monstres (ateliers Toxicode – Code N Slash )…  Tout est fait pour que les participants de tous âges puissent vraiment avoir une expérience concrète de la programmation et de ses nombreuses applications au quotidien.

Parce qu’il y aura des robots et des IA (Intelligences Artificielles)

La Code Week, c’est des rencontres du 3ème type garanties ! Et oui, fini les heures assis devant un écran à écrire des lignes de code incompréhensibles. Désormais, la programmation permet de coder des intelligences artificielles (atelier Toxicode – Coder une intelligence artificielle à Rennes), le comportement d’un robot constructeur (ateliers Toxicode – Codecraft) ou de robots en chair et en os, enfin vous voyez ce que je veux dire… (ateliers robotiques avec de vrais robots pour devenir l’ami de Wall-e)         

Parce qu’il y aura de la compèt

La Code Week, c’est aussi l’occasion de participer à des challenges quel que soit votre niveau, passionné de programmation ou débutant. De nombreuses game jams sont prévues, permettant de se mesurer aux autres participants pour créer un niveau de jeu vidéo (ateliers Toxicode – Code N Slash ) ce qui obligera à sortir de votre zone de confort et à repousser vos propres limites !   

Parce qu’il y aura des filles (et des garçons)

Désormais, le code n’est plus seulement réservé à la gent masculine ! Les filles ont investi la place et ne comptent pas en partir. Les assoc de promotion de la programmation et des nouvelles technologies destinées aux filles type Girls in Tech ou Rails Girls fleurissent un peu partout et on ne va pas s’en plaindre… Lors des ateliers Toxicode organisés cet été, on comptait certes encore une majorité de mâles, mais les filles sont de plus en plus nombreuses ! Donc n’hésitez plus et venez apprendre à coder ou vous perfectionner au code, partout en France et en Europe !

Programme des ateliers Toxicode pour la Codeweek 2015 (10 au 18 octobre 2015) :

  • 10 octobre 2015 de 15h00 à 16h30 – “Atelier Codecraft” à la Médiathèque Hélène BERR, Paris 12ème, le cadre de NUMOK, festival numérique des Bibliothèques de la Ville de Paris.
  • 10 octobre 2015 de 14h30 à 17h30 – “Atelier Code N’ Slash” à la Médiathèque Françoise SAGAN, Paris 10ème.
  • 13 octobre 2015 de 19h à 23h – “Atelier Code N’ Slash” à l’ISART DIGITAL, Paris 11ème.
  • 17 octobre 2015 de 10h00 à 13h00 – “Atelier Bot Arena pour coder une Intelligence Artificielle” dans le cadre du Festival MAINTENANT à Rennes.
  • 17 octobre 2015 de 11h00 à 12h30 – “Atelier Codecraft” au Cube à Issy-les-Moulineaux.
  • 17 octobre 2015 de 14h30 à 17h30 – “Atelier Code N’ Slash” au Cube à Issy-lesMoulineaux.

Nos interventions :

  • Le 17 octobre 2015 de 15h15 à 16h30 – Échanges autour de l’apprentissage du code et des jeux vidéo : outils numériques de réappropriation du monde dans le cadre du Festival MAINTENANT à Rennes.
  • Le 23 octobre 2015 – Participation à la soirée de clôture de la Codeweek, organisée dans les locaux de Mozilla à Paris autour du thème : « Code, Créativité et Pédagogie ».

Exemple d’outils : http://silentteacher.toxicode.fr/

Démonstration de Bot Arena : https://www.youtube.com/watch?v=faS7zrRijAg

Démonstration de Code N’ Slash : https://www.youtube.com/watch?v=ZYv90pAvGe8

Nos formations en ligne : http://www.toxicode.fr/events

Pour plus d’informations sur ces événements  Code Week 2015, vous pouvez consultez la page www.codeweek.eu/

 

 

NodeJS fusionne avec iojs

NodeJS fusionne avec iojs

Et voilà, c’est fait : NodeJS fusionne avec iojs. L’annonce faite par Mikeal Rogers le 8 mai 2015 suivie d’un vote du Comité Technique 5 jours plus tard a permis de confirmer la rumeur qui courait depuis déjà un moment. Retour sur un événement historique pour notre cher internet et sur ses implications dans un futur proche et lointain.

NodeJS, kézako?

Pour les non-initiés, revenons-en aux définitions de base.

Node.js est ce qui permet, depuis 2009 / 2010, d’ utiliser JavaScript aussi hors du navigateur, comme des langages plus classiques, en lui donnant accès notamment à la manipulation de fichiers et aux interactions avec le réseau. Du fait de ses performances, et ses caractéristiques, il est surtout utilisé pour coder des serveurs web minimalistes, rapides, capables de répondre à de nombreuses requêtes en parallèle ou de faire du web temps-réel (chats / jeux multijoueurs…). Son développement et sa maintenance sont effectués par l’entreprise Joyent. Node.js est progressivement devenu populaire et est utilisé par Groupon, SAP, LinkedIn,Microsoft, Yahoo!, Walmart, Rakuten et PayPal entre autres. Nous l’utilisons également beaucoup chez Toxicode pour nos jeux multijoueurs et nos outils autour de l’apprentissage de la programmation.

Pourquoi iojs a changé la donne?

Il y quelque mois de cela, la v0.1 d’un  nouveau fork de Node, baptisé io.js, voyait le jour. Quand io.js a été lancé en janvier 2015, nombreux y ont vu une sorte de « Node amélioré », un fork plus agressif dans le développement et qui permettait d’implémenter des fonctions qui manquaient dans les v0.11 et 0.12 de NodeJS. (Pour les débutants comme moi, un fork est un projet ou logiciel issu d’une scission avec un projet initial unique, et qui partage avec lui une part de son code source).

Mais alors que Node.js avait déjà été forké auparavant, avec l’avènement de io.js, une vraie scission s’est produite : plusieurs contributeurs majeurs ont quitté Node.js et ont commencé à faire des pulls requests pour io.js. L’année 2014 avait déjà vu une diminution des suiveurs de Node.js, mais en 2015, la division s’est faite plus profonde également pour des raisons de gouvernance. En effet, la communauté des développeurs autour de Node.js s’agrandissant, certains des contributeurs trouvait qu’il était difficile de s’intégrer au projet et reprochaient aux chefs de projets un certain manque de transparence. Ils n’approuvaient pas de voir Node.js aux mains d’une compagnie privée, et d’avoir à passer du temps à faire accepter aux chefs de projets chacune des améliorations qu’ils voulaient apporter au code.

Au contraire, io.js a lancé dès janvier 2015 des cycles d’amélioration rapides, en suivant un modèle de gouvernance ouverte qui a attiré de nombreux contributeurs.

Naissance de la Node Foundation

Voyant l’évolution de la situation, Joyent a réagi rapidement, annonçant en février 2015 son intention de créer la Node Foundation, gérée par un Comité Technique, une initiative soutenue par IBM, Paypal, Microsoft et la Fondation Linux et qui permettrait de résoudre les problèmes de gouvernance qui s’étaient posés. Selon ioJS, les deux projets convergent donc sous l’appellation Fondation Node, « sous la tutelle conjointe des équipes techniques de Node.js et io.js ». Par ailleurs, la Node Foundation utilise le nom de Node.js et s’appuie sur un référentiel io.js

L’objectif principal est de réunifier la communauté divisée autour d’un modèle plus ouvert, transparent et proposant des updates très réguliers.

Souhaitons donc la bienvenue à cette nouvelle fondation  et gardons un oeil sur les prochains développements du projet !

 

Bienvenue chez Toxicode – Première Game Jam dans nos nouveaux locaux !

Bienvenue chez Toxicode – Première Game Jam dans nos nouveaux locaux !

Ambiance conviviale et cacahuètes… Tels étaient les mots d’ordre du premier atelier Toxicode organisé dans nos nouveaux locaux parisiens. Après le succès de notre collaboration avec le réseau des Bibliothèques de la Ville de Paris cet hiver, nous venons de lancer une série d’ateliers et de formations Toxicode… pour fêter l’arrivée des beaux jours !

Notre premier event : une Game Jam organisée lundi 4 Mai, qui a rassemblé une trentaine de personnes de tous niveaux. Le concept : apprendre à coder en utilisant des outils ludiques conçus et développés par Toxicode.

Ca s’est passé comment?

Tout d’abord, nous avons commencé avec Silent Teacher, un de nous outils qui permet de s’initier en douceur aux concepts sous-tendant la programmation (formules, algorithmes) sans même avoir l’impression d’être en cours.

Ensuite, on est passé aux choses sérieuses avec Code N’Slash, une autre de nos créations, permettant d’apprendre à coder en construisant soi-même ou en petits groupes, des niveaux de jeu vidéo de difficultés variables. Le héros, un petit mais preux chevalier en armure, doit affronter des monstres et franchir des murs et des abysses pour rejoinder la sortie de chaque niveau.

Notre public, très motivé, a posé des tas de questions à notre équipe de sept formateurs Toxicode. Pierre Lancien, l’un de nos organisateurs Toxicode, explique : “Les gens ont entendu parler de l’événement par bouche à oreille, et ceux qui sont venus étaient donc souvent des groupes de potes, dont toute une troupe venue de Simplon, d’ou l’ambiance chaleureuse. Les gens se levaient pour aller faire des pauses et grignoter, et en profitaient aussi pour discuter avec certains membres de notre équipe à l’extérieur de la salle.”

Verdict ?

Au vu des retours très positifs des participants, pari réussi pour ce premier atelier chez Toxicode !

Vous aussi, vous voulez participer ?

Vous aussi, vous aimeriez apprendre à coder ? Vous voulez en savoir plus sur la liste des prochains ateliers et programmes de formations Toxicode prévus sur Paris ?  Visitez notre page Toxicode Events.

Entre programmation et créativité : Bret Victor, le visionnaire décalé

Entre programmation et créativité : Bret Victor, le visionnaire décalé

A première vue, Bret Victor semble être un type plutôt banal. Il n’a ni la gouaille ou l’assurance d’un Mark Zuckerberg, ni le côté businessman génial d’un Steve Jobs. Il passerait presque inaperçu. Lorsqu’on commence à regarder une de ses présentations d’une heure sur Youtube, on se dit qu’on risque de s’ennuyer un peu, même si on est intéressé par la programmation.

Et en une minute, tout est retourné… On se prend une claque conceptuelle en pleine figure, on est sonné et surtout on n’a pas envie d’en perdre une miette. Car Bret Victor est avant tout un visionnaire… et un visionnaire de la meilleure trempe… un visionnaire décalé.

Bret Victor, ancien interface designer chez Apple, considère tout ce qui l’entoure et l’intéresse, notamment ses domaines d’expertise – programmation et créativité – et les triture, les retourne dans tous les sens pour mieux s’interroger et ouvrir de nouvelles portes… et c’est totalement prenant de le voir entreprendre ce questionnement philosophique des choses.

J’en veux pour preuve deux vidéos fort inspirantes que je vous conseille de regarder au plus vite.

« Les créateurs ont besoin d’une connexion immédiate avec ce qu’ils sont en train de créer. »

Dans “Inventing on Pinciples” (Inventer selon des Principes), Bret Victor traite du sujet de la créativité en s’appuyant sur des exemples liés à la programmation mais pas que. Et sur un précepte essentiel : quel que soit votre domaine d’expertise, technicien, ingénieur, vous pouvez (même vous devez) avoir le sentiment de travailler pour une cause qui vous semble juste, de défendre un principe éthique auquel vous croyez. En gros, il y a de la morale dans tout ce que l’on fait, même quand on met les mains dans le cambouis.

Bret Victor illustre ce principe en citant son exemple personnel. Le principe auquel il croit fermement ? Lorsqu’on crée quelque chose, on devrait pouvoir voir immédiatement, sans délai, le résultat ou l’impact de ce que l’on a crée. Il prend d’abord pour exemple une page de code classique d’une image. Si l’on souhaite modifier un détail de l’image, il faut aller dans le code, modifier, sauvegarder, relancer avant de confirmer que le résultat est bien celui qu’on espérait. Et Bret Victor de demander : pourquoi ne pas pouvoir voir immédiatement le résultat de toute modification dans notre code? Je vous laisse regarder la vidéo pour découvrir ses idées qui permettraient de coder efficacement, en ayant un lien direct avec ce que l’on veut créer.

Il n’utilise pas que des exemples issus de la programmation, également des algorithmes mathématiques, des circuits électriques… Mais le principe fondateur reste le même, et franchement, plus il parle et plus on en est convaincu. Bret Victor se place constamment en porte-à-faux par rapport à ceux qui croient déjà “savoir ce qu’ils font” et qui à force de ne rien questionner, finissent par simplement stagner plutôt que créer.

“La pensée la plus dangereuse pour un créatif, c’est d’avoir la certitude qu’il sait ce qu’il fait. »

Dans “The Future of Programming” (L’Avenir de la Programmation), Bret Victor est également dans le décalage, mais cette fois temporel. Il utilise une pirouette élégante : arrivant sur la scène avec un vieux rétroprojecteur, il fera mine pendant toute sa présentation d’être en 1973 et de présenter les idées révolutionnaires des années 60 et 70 qui à coup sûr, seront totalement acquises d’ici 40 ans, c’est à dire … en 2013.

Pourquoi ? Pour mettre la « nouvelle génération » qui constitue son public devant ce qu’il nomme une « tragédie » : que de toutes les idées visionnaires nées dans les années 60, à l’époque ou la programmation n’était pas encore clairement définie, nombreuses ont été totalement oubliées. Et le futur qu’on imaginait serait le nôtre en 2014 n’a pas pris en compte les idées géniales du passé. Du coup, on code encore comme il y a 40 ans… on a stagné. Et pire encore : la nouvelle génération tient pour acquis que tout a été déjà réfléchi, que la programmation ça doit être comme ça. Ils ne sont pas bridés, ils sont juste aveugles…

Pour remédier à cela une bonne solution : écoutez ce que dit Bret Victor, essayez d’être inspirés par ce que vous faites et ne prenez jamais pour acquis les systèmes dans lesquels vous évoluez.

Si vous faites partie de la nouvelle génération de développeurs, concepteurs de jeux vidéos, ou autres experts IT, si vous manquez d’inspiration lorsque vous vous levez le matin, regardez ces deux vidéos… elles changeront peut être votre façon de travailler ou même votre vie !

Initiation du grand public au code : l’action des bibliothèques de la Ville de Paris

Initiation du grand public au code : l’action des bibliothèques de la Ville de Paris

Pour bien commencer l’année 2015, Toxicode voulait partager avec vous l’avancement de notre projet de coopération avec le réseau des bibliothèques de la Ville de Paris sur l’initiation du grand public au code. Depuis Septembre 2014, nous avons en effet lancé une initiative en lien avec ce réseau, en intervenant pour former les bibliothécaires à l’animation d’ateliers de programmation et permettre ainsi au grand public de pouvoir apprendre à coder en bibliothèque. Cécile Quach, conservatrice des bibliothèques à la Ville de Paris, en charge de la mission services innovants pour les bibliothèques municipales, nous livre ses impressions et son bilan sur ces premiers mois de collaboration.

Êtes-vous déjà initiée à la programmation? Quand avez-vous entendu parler de la programmation pour la première fois?

Non, au sens où je n’ai pas de bases en programmation. J’ai entendu parler de la programmation pour la première fois à six ou sept ans, lors d’un atelier à l’école primaire où les élèves devaient programmer le chemin d’une tortue et les couleurs du paysage où elle évoluait. Avec le recul, je me dis que j’avais peut-être alors fait connaissance avec le LOGO, mais je n’ai plus moyen de vérifier !

Comment vous est venue l’idée de ce projet en partenariat avec Toxicode?

Ce projet est né d’une rencontre avec Pierre Lancien à un meetup Code Cambouis, où j’avais fait connaître l’intérêt des bibliothèques de la Ville de Paris pour la vulgarisation de la science informatique

En quoi consiste ce projet?

Toxicode a commencé à développer des outils pour apprendre à coder de manière ludique. Pierre Lancien avait proposé de les faire connaître au public des bibliothèques. Ce projet correspondait également à notre politique d’inclusion visant à faire connaître et prendre conscience sans forcément proposer un enseignement systématique, rôle qui relève davantage de l’école. Pour accompagner la mise en place de ces outils dans les bibliothèques, Pierre Lancien a proposé des séances de formation pour la prise en main de ces outils et leur présentation au public. Pour sensibiliser les bibliothécaires aux enjeux de la vulgarisation de la science informatique, j’ai également confié à Pierre Lancien une conférence métier sur ce thème.

Les bibliothécaires qui ont assisté à cette conférence métier en sont ressortis pleins d’enthousiasme. Nous avons pu expérimenter dès octobre 2014 une première participation des bibliothèques de la Ville de Paris la Code Week, où Toxicode a proposé une game jam collaborative à la bibliothèque Jacqueline de Romilly, avec un outil spécialement développé pour l’occasion. Nous avons aussi expérimenté « Hello Codeur ! »,  un format transposant l’activité de conseil du bibliothécaire dans le domaine de la science informatique, à la bibliothèque Couronnes – Naguib Mahfouz, sur la proposition de Julien Dorra et d’Etienne Charignon, d’ut7, qui sont également impliqués dans le meetup Code Cambouis.

Est-ce essentiel selon vous que le grand public, y compris les enfants, apprennent à coder ? 

Je ne dirais pas que la question soit tant d’apprendre à coder, que de prendre conscience de l’importance de l’informatique en tant que moteur conceptuel et technique du numérique, de comprendre qu’à l’heure du numérique, la science informatique fait désormais partie de la culture générale et pour cela, de permettre au grand public de dédramatiser son rapport à l’informatique. Les bibliothèques en tant que service public ont une mission politique d’empowerment des citoyens. Montrer que tout le monde peut apprendre à coder, que ce n’est pas une activité, dans son principe, si compliquée qu’elle peut en avoir l’air, cela fait partie des voies possibles pour susciter une telle prise de conscience.

Bien sûr, sur le plan économique, les entreprises et les administrations auront de plus en plus besoin de programmeurs, mais ce n’est pas pour cette raison que les bibliothèques se positionnent sur la question de l’apprentissage de la programmation informatique.

Apprendre à coder en bibliothèque : une révolution ou une évolution naturelle?

J’ai commencé à répondre à cette question dans ma réponse précédente ! Donc oui, c’est une évolution naturelle. Les bibliothèques sont des services publics destinés à favoriser l’accès de tous  à la société de l’information et de la communication, afin de permettre une participation à la vie sociale et politique. Or, le numérique est l’exacerbation de cette société ; accompagner le public dans son appropriation du numérique est donc dans la continuité de la mission propre aux bibliothèques. Et, comme je l’ai expliqué plus haut, la science informatique est une clé d’entrée fondamentale pour comprendre le numérique.

Quels sont les retours des bibliothécaires suite aux premières sessions d’initiation réalisée par Toxicode?

Concernant la conférence métier, les bibliothécaires sont, comme je l’ai dit, tout à fait convaincus et impatients de se lancer dans l’action. Concernant les formations pratiques de prise en main de Codecraft, les bibliothécaires sont également très satisfaits, même s’il faudra expérimenter en situation réelle un atelier avec des enfants.

Quelles sont les prochaines étapes de ce projet? Et avez-vous déjà en tête d’autres projets possibles autour de la programmation?

D’autres sessions de formation sont encore prévues jusqu’en mars, avec une reconduction prévue, à la fois sur la sensibilisation aux enjeux et sur la prise en main de Codecraft. Il faudra ensuite tester des ateliers en bibliothèque avec les usagers.

Les bibliothèques de la Ville de Paris ont proposé d’autres actions autour de la programmation et de la science informatique : des ateliers Scratch (à la bibliothèque Jacqueline de Romilly), des coding goûters (à la bibliothèque Louise Michel). Ces actions vont être complétées à partir de 2015 par des ateliers avec les outils de Webmaker, des ateliers de bidouille avec des MakeyMakey et des activités  avec les Lego Mindstorms. La plateforme de France-ioi pour l’entraînement à l’algorithmique et la programmation sera proposée pour l’autoformation, avec la possibilité pour l’usager de se faire accompagner par un bibliothécaire. Des game jams sont également à l’ordre du jour, notamment à la bibliothèque Václav Havel, qui développe son offre autour de la programmation informatique.

 Pour plus d’information, rendez-vous sur Que faire à Paris, le site de la Ville de Paris pour dénicher bons plans culturels, sorties et activités. Guettez aussi les sélections « Que faire à Paris avec un geek » ! Et enfin, suivez votre bibliothèque préférée sur les réseaux sociaux.

Propos recueillis par Emilie Chung

Illustration Lou Pine