Stuff

window.location = "https://ronan.amicel.net/articles/newcrafts-2018/";

Jeudi 17 et vendredi 18 mai 2018 avait lieu à Paris la conférence NewCrafts, et j'y ai participé pour la 2e année consécutive.

C'est une conférence en anglais, sur le thème du développement logiciel. L'organisation est impeccable, les intervenant(e)s varié(e)s, pointu(e)s, et inspirant(e)s.

Il y a plusieurs tracks en parallèle, plus des ateliers, et aussi les discussions dans les couloirs, et c'est donc parfois difficile de choisir vers où suivre ses pieds.

La première journée, j'ai assisté à pas mal de présentations, alors que la deuxième j'avais plutôt envie de pratiquer avec du code, et j'ai donc privilégié des ateliers. Et pendant ces deux jours, les différents moments de pause ont été l'occasion de nombreuses discussions enrichissantes avec les autres participants !

Voici quelques notes sur des choses qui m'ont intéressé, surpris, amusé, ou encore questionné pendant ces deux jours.

Fighting the Invisible Enemy (Paul Rayner)

Ce qui va à l'encontre du flow dans nos processus de développement de produits, ce sont les queues invisibles qui se forment : par exemple, une fonctionnalité est développée mais en attente d'être testée ou déployée.

Les queues sont des indicateurs avancés (leading indicators), contrairement au débit (throughput) ou au temps de cycle (cycle time). Il est donc important de prendre conscience de ces queues, de les rendre visibles, et surtout d'agir rapidement et de manière décisive quand elles commencent à grossir, avant que les conséquences ne se manifestent de manière plus problématique au niveau de l'ensemble du système.

Paul Rayner a utilisé des modèles de traffic routier (http://traffic-simulation.de) pour illustrer de manière très parlante les comportements non linéaires qui apparaissent à la moindre perturbation dès lors que le système fonctionne à un niveau de capacité élevé.

Il nous a aussi montré un outil sur lequel il travaille, et qui s'appelle tout simplement Flow. Celui-ci extrait les données temporelles depuis Pivotal Tracker / Jira / etc. pour visualiser le temps passé par chaque ticket dans chaque étape, et mieux identifier les temps d'attente.

Cette approche visuelle m'a fait penser à un autre outil du Lean, le diagramme de flux cumulé (cumulative flow diagram).

Fighting the Invisible Enemy - Paul Rayner (NewCrafts 2018) from Paul Rayner

Feature Branching is Evil (Thierry de Pauw)

Thierry nous raconte son expérience en tant que consultant avec deux projets assez différents.

La première équipe était peu expérimentée, et n'utilisait auparavant aucun système de gestion de versions. Pour rester simple, il les a aidé à adopter Subversion : seulement deux gestes à apprendre (checkout, et commit), et pas de branches. Il avait pensé ça comme une première étape, mais en fait ça marchait pas mal.

La deuxième équipe était constituée de développeurs expérimentés, qui avait choisi d'utiliser git et le mode de fonctionnement “git flow”. Lorsqu'il leur a suggéré d'arrêter les branches à longue durée de vie, il s'est heurté à une forte incompréhension :

mais les branches nous permettent de travailler chacun de notre côté sans être perturbé par les changements des autres !

mais les branches nous permettent de jeter un refactoring s'il ne va nulle part !

mais les branches nous permettent de contrôler la qualité de ce qu'on livre (via une revue de code pre-merge)

mais les branches nous permettent de contrôler quelles fonctionnalités on livre (on ne merge que quand on veut livrer)

Dans sa présentation, Thierry a abordé :

les inconvénients des branches à longue durée de vie :

elles retardent le feedback,

elles retardent l'intégration,

elles cachent le travail du reste de l'équipe et réduisent la communication,

elles découragent le refactoring,

elles créent du stock (au sens du Lean),

elles augmentent le risque,

elles créent du travail supplémentaire (brancher, rebaser, merger…),

les avantages du trunk-based development :

commits plus fréquents sur master → builds plus fréquents → déploiements plus fréquents → time-to-market réduit → expérimentation plus facile

builds plus fréquents → les problèmes sont détectés plus tôt → la qualité est améliorée

comment faire du trunk-based development :

l'application est toujours prête à être livrée sur la branche principale,

découper les gros changements en petits morceaux incrémentaux,

garder cachées les nouvelles fonctionnalités non terminées,

utiliser la technique “branch by abstraction” pour les gros refactorings,

utiliser les feature toggles (mais en dernier recours)

comment remplacer la revue de code ?

le pair programming est une solution possible (revue de code continue pre-commit)

on peut aussi faire une revue de code post-commit

pre-merge : pull requests fréquentes sur des branches à durée de vie courte

post-merge : revue de code de tous les commits poussés sur master

au delà des raisons invoquées explicitement, quels sont les peurs qui font qu'une équipe peut résister à l'adoption de ce modèle ?

les développeurs ne savent pas développer par petits incréments → c'est une compétence encore trop rare, qui doit s'acquérir

la base de code est trop couplée, et manque de tests → c'est difficile de changer quoi que ce soit sans craindre de casser quelque chose

les builds sont trop lents → 🐢

The Origins of Opera and the Future of Programming (Jessica Kerr)

Je regrette de ne pas avoir pu voir cette présentation. En attendant la vidéo, un article de blog est disponible qui en reprend la trame : https://the-composition.com/the-origins-of-opera-and-the-future-of-programming-bcdaf8fbe960

Endangered Species: Senior Craftsmen (Cyrille Dupuydauby)

Le goulot d'étranglement dans nos métiers, c'est l'apprentissage. Il n'y a pas beaucoup de développeurs qui ont 10 ans d'expérience, et encore moins qui en ont 20. Doit-on compter sur eux pour enseigner le métier aux nouveaux ? Seule une petite partie d'entre eux a envie de devenir prof, le reste préfère sans doute programmer. C'est tous ensemble, en tant que communauté, que nous devons être une organisation apprenante. Chacun, quel que soit le stade où il en est, peut aider les autres.

Slides : https://noti.st/dupdob/gX1kor/endangered-species-senior-crafters

How to take smart notes (Sönke Ahrens)

Les conseils pour prendre des notes sont généralement de les séparer (un cahier ou carnet par sujet / matière), de les relire dès que possible… Ce sont de mauvais conseils.

Les conseils sur comment écrire un article, un rapport, un mémoire, sont très linéaires : trouvez un sujet, puis faites des recherches, puis lisez et prenez des notes, puis faites un plan, puis rédigez… L'écriture y est une tâche parmi d'autres, et la vision est très top-down. Une meilleure approche est possible !

Pour Richard Feynman, la pensée est indissociable de l'écriture. Les notes ne sont pas une forme de stockage du résultat de notre pensée, elles sont notre pensée elle-même. L'esprit a besoin de cet échafaudage extérieur qu'est l'écriture.

Pendant sa carrière académique, Niklas Luhmann a écrit environ 600 publications, dont plus de 60 livres, sur des sujets comme la sociologie, le droit, la politique, les médias, la philosophie, l'art, l'amour… Son secret ? Sa boîte à notes (Zettelkasten).

90 000 notes accumulées. Ça semble beaucoup, mais ça fait seulement 6 par jour.

Son système est simple mais terriblement efficace :

une idée par note ; une note sert à développer une idée

chaque note a un identifiant noté en haut à gauche : 1, 2, 3… ( une note peut renvoyer à une autre par son identifiant noté à l'encre rouge dans le texte)

il n'y a pas de classement hiérarchique, l'organisation est émergente : une note liée à une autre peut être insérée derrière elle dans la boîte, et recevoir un identifiant avec une branche (par exemple : 1a1) ; cela permet de retrouver des notes pertinentes à proximité, et de dérouler ainsi le fil plus tard

En insérant la rédaction de ces notes à ses activités quotidiennes de lecture, séminaires, etc. l'écriture n'est plus quelque chose de séparé que l'on fera juste avant la deadline, mais devient un travail progressif et incrémental. Les questions à creuser et les catégories émergent. Les idées s'enrichissent les unes les autres. Penser, relier et comprendre deviennent des actions concrètes.

Pour en savoir plus : http://takesmartnotes.com

Big corps as little panopticons. Agile coaches as colonial imperialists. (Romeu Moura)

Le panoptique est une architecture de prison imaginée à la fin du XVIIIe siècle par Jeremy Bentham, et analysée au XXe siècle par Michel Foucault dans son livre « Surveiller et punir ».

Ses caractéristiques clés sont que :

les prisonniers sont toujours vus par les gardes et le savent ;

les prisonniers ne voient pas les gardes ;

les prisonniers ne se parlent pas entre eux.

Dans un premier temps, un prisonnier se comporte bien car il est observé. Mais dans un deuxième temps, il est conditionné à devenir son propre garde.

On peut comparer les entreprises à des panoptiques. Les managers veulent une complète visibilité sur ce que font leurs employés (reporting, etc), mais ne communiquent pas sur ce qu'ils font, et les équipes ne se parlent pas. Les équipes finissent par devenir leurs propres gardes, et s'interdisent de faire certaines choses : « ah mais non, ici on ne peut pas faire ça ».

En Amérique du Sud, les colons n'ont pas réussi à transformer les autochtones en esclaves. Ils avaient la mauvaise habitude de se laisser mourir. Ils devaient donc importer des esclaves venant d'Afrique. Jusqu'à ce que les missionnaires jésuites trouvent la combine : une fois convertis à la foi chrétienne, ils craignaient de mourir !

Les grandes entreprises déploient des armées de coachs pour effectuer leur “transformation agile”. Il s'agit moins de transformer toute la structure (et certainement pas le haut de la pyramide), que d'imposer un changement à certains

Pour Romeu, tous ces coaches agiles sont des jésuites. Qu'ils croient ou non aux valeurs de l'agilité, ils sont envoyés pour changer la culture de « ces gens là bas ». Ils sont instrumentalisés.

Alors que faire ? Comprendre le système. Lire « Thinking in systems ». Lire Foucault (c'est dur). Regarder la présentation de Jessica ou lire son article.

Chacun d'entre nous a plus de pouvoir qu'il ne croit. Nous sommes conditionnés à penser le contraire. Nous vivons dans une peur artificielle d'agir différemment. Nous surestimons le pouvoir de notre hiérarchie. On les croit malveillants, mais ils sont dans la même situation, à un niveau différent. Et à tous les niveaux, les gens aimeraient que les choses changent. Restez indignés !

What is programming anyway? (Felienne Hermans)

On emploie souvent des métaphores pour expliquer ce qu'est la programmation. Dire que programmer c'est comme les maths, ça peut avoir un effet négatif. Felienne suggère de dire plutôt que programmer c'est comme écrire. Tout le monde peut écrire, et l'écriture a des usages variés : fiction, poésie, calligraphie, pétition, dissertation, liste de courses…

Cette présentation m'a aussi fait réaliser qu'Excel est un langage de programmation fonctionnelle, et que c'était sans doute le meilleur langage de programmation, car des millions de gens l'utilisent sans le savoir… Imaginez vous programmer en Java sans faire exprès !

Atelier: 50 shades of FizzBuzz

L'atelier visait à prendre un problème simple (FizzBuzz) et à explorer différentes manières de l'implémenter, en se donnant des contraintes.

Par exemple, on a commencé en mode zombie pair programming : le co-pilote pouvait faire des gestes mais ne pouvait pas parler, seulement grogner ou dire « brains ! ».

On a ensuite enrichi les spécifications et vu comment le code évoluait.

J'ai profité d'une partie de l'atelier pour explorer comment utiliser le property-based testing pour exprimer les tests.

J'ai mis mes différentes versions sur GitHub : https://github.com/ronnix/50-shades-of-fizzbuzz

Atelier: Evolutionary Design

L'atelier visait à expérimenter l’evolutionary design.

La première activité a consisté à implémenter, en groupes de 4-5 personnes, une nouvelle méthode sur une base de code existante (cool, c'était en Python !), en mode outside-in TDD. Ç'a été une expérience à la fois intéressante et pénible pour moi, car je pense plutôt être de l'école classique du TDD, et faire les choses en mode London school allait un peu contre mon penchant naturel…

La deuxième activité a consisté, toujours en groupes, à prendre une base de code développée par un autre groupe lors d'un précédent atelier où ils avaient plus de temps, et à l'améliorer avec des refactorings.

Dojo tournant en continu

Pendant toute la durée de la conférence, un dojo de programmation a eu lieu en continu, où chacun pouvait venir participer au développement d'un jeu de la vie, en mode mob programming.

Je n'y ai participé que quelques minutes, mais c'était très drôle de voir apparaître en accéléré les problèmes que l'on voit en entreprise sur des projets plus longs sur lesquels il y a du turn over. Le code devient très vite du code legacy, l'intention initiale est vite perdue, les connaissances se transmettent mal, les nouveaux venus veulent aller dans une direction qui a déjà été essayée sans succès par les précédents, mais ils ne le savent pas…

Pauses, couloirs et soirée du jeudi

Les 23 et 24 septembre derniers, j’étais à Toulouse pour l’édition 2017 de PyCon FR. Le programme était riche, avec trois « tracks » en parallèle, sans compter les « sprints » et les ateliers. Je partage ici quelques notes sur les présentations auxquelles j’ai pu assister.

Tests

Le samedi après-midi, plusieurs présentations se sont succédées autour de la thématique des tests, dans une sorte de mini « track ».

Vincent Maillol nous a d’abord présenté une approche intéressante qu’ils utilisent pour les tests fonctionnels de leur API / application web. L’outil (cricri) permet d’exprimer des scénarios de test en déclarant les différentes parties et les contraintes associées (la partie A est optionnelle, mais doit s’exécuter avant la partie B). Il va générer automatiquement les tests correspondant aux différentes combinaisons.

L’outil s’intègre au test runner standard de Python, mais malheureusement pas à Pytest.

J’y ai retrouvé des analogies mais aussi des différences avec l’approche BDD (voir par exemple pytest-bdd pour une implémentation en Python) :

dans les deux cas on va pouvoir découper ses scénarios en « steps » réutilisables

dans l’approche BDD, on va plutôt lister explicitement tous les scénarios, ce qui a une valeur en terme de documentation et de communication avec l’équipe produit, mais qui peut introduire une certaine redondance ; l’approche générative est plus concise, mais ça peut devenir plus difficile de savoir quels scénarios sont effectivement pris en compte

dans l’approche BDD, on va plutôt écrire les scénarios dans un DSL comme Gherkin, toujours dans le but d’être lisible par des non-développeurs, mais ça rajoute un niveau d’indirection et donc de lourdeur dans l’écriture des tests (personnellement je préfère écrire un test fonctionnel directement en Python qu’en Gherkin)

Une piste de réflexion : utiliser Hypothesis pour générer automatiquement des séquences d’opérations sur une application ou une API, chacune étant ensuite définie par un « step », de manière à valider des invariants (par exemple : en aucun cas deux utilisateurs ne peuvent réserver un même logement à la même date).

J’ai apprécié ensuite la présentation de Boris Feld et Pierre-Yves David sur les tests de performance. Ils ont bien présenté l’intérêt de considérer la performance comme une fonctionnalité du logiciel, et de suivre son évolution avec le temps via une suite de tests de performances automatisés.

Ils ont exposé toute une série de facteurs à prendre en compte pour limiter la variabilité des résultats, au niveau du matériel, du noyau et des outils. Difficile d’avoir un environnement contrôlé dans le cloud, donc pour leurs besoins ils ont mis en place une machine physique dédiée.

Deux outils à retenir :

perf : prépare le système, exécute les benchmarks, enregistre les données...

asv (Air Speed Velocity) : un peu le Jenkins des tests de performance. Il sait lancer automatiquement la suite de tests de performance à chaque commit, stocker les résultats, les afficher sous forme de jolis graphe, et détecter les variations significatives.

Enfin, j'avais moi-même une présentation de quelques techniques de test avancées en Python (les diapos et les exemples). Merci à tous ceux qui m'ont fait des retours, j'ai apprécié vos compliments comme vos suggestions d'amélioration. J'ai noté notamment de regarder libfaketime, une alternative à freezegun avec de meilleures performances, et d'aborder les manières d'intégrer tox et Travis CI.

Devops

Côté devops, la présentation de Gaël Pasgrimaud montrait que malgré l’abondance d’outils d’orchestration et de gestion de configuration, certains cas d’utilisation restent mal couverts. Leur besoin : exécuter des tâches impératives sur un grand nombre de machines hébergées (plusieurs dizaines ou centaines) sur lesquelles ils ne peuvent pas forcément installer d’agent (connexion exclusivement par SSH). Ils utilisent habituellement Ansible, mais les administrateurs sytème n’étaient pas satisfaits de ses performances dans ce scénario.

Dans un contexte où l’on peut installer un agent, je pense que Salt serait une bonne solution (utilisé par exemple chez LinkedIn pour gérer plusieurs dizaines de milliers de serveurs). Et avec un plus petit nombre de machines, quelque chose de plus simple comme Fabric (+ fabtools !) fonctionne de manière satisfaisante. Mais pour commander efficacement 300 machines par SSH, aucune solution existante ne semblait convenir.

Ils ont donc développé un outil maison (nuka) basé sur Python 3, utilisant asyncio pour gérer les multiples connexions SSH concurrentes.

La discussion sur les goulets d’étranglement (bottlenecks) rencontrés a été intéressante : la principale limite aux performances (au delà de la qualité du réseau) était la connexion locale à l’agent SSH pour l’authentification par clé.

Un peu plus tard, la présentation de Philippe Pépiot a porté sur testinfra, une bibliothèque qui permet d'écrire des tests qui décrivent l'état souhaité d'un serveur, indépendamment de l'outil de gestion de configuration utilisé (Chef, Puppet, Salt, Ansible...). Je suis fan de cette approche, et ça me semble une super alternative à serverspec (là aussi, je préfère écrire mes tests avec Python et pytest qu'avec un DSL Ruby).

Scaling et parallélisme

La présentation de Julien Danjou était un excellent état de l’art sur les approches et les outils pour le parallélisme et les systèmes distribués en Python : multi-thread, multi-process, queues...

J'ai noté plusieurs bibliothèques et outils intéressants à regarder :

cachetools : lorsque le functools.lru_cache de la bibliothèque standard ne suffit pas

cotyledon : pour gérer des processus à longue durée de vie (services / démons)

futurist : extensions à l'excellent module concurrent.futures de la bibliothèque standard

tenacity : un décorateur @retry très paramétrable pour réessayer automatiquement les accès à des services qui peuvent être indisponibles

fasteners : une bibliothèque qui forunit plusieurs implémentations de verrous (locks)

Unicode et alphabets

Boris Feld a refait sa très bonne présentation qui démystifie les chaînes de caractères, les octets, l’unicode et toutes leurs feintes en Python 2 et 3.

Ensuite Guillaume Ayoub à enchaîné avec une présentation riche, agréable, analogique et participative, qui nous a emmené des origines de l’écriture aux Emoji en passant par l’explication des différences entre crénage (kerning), anti-crénelage (anti-aliasing) et hinting en typographie numérique.

Et le reste

Impossible de voir toutes les présentations intéressantes dans une telle conférence, donc j’ai notamment loupé :

la présentation de Stéphane Angel et Joachim Jablon sur les bonnes pratiques de packaging

la présentation de Xavier Ordoquy sur les fausses bonnes idées dans les API REST

la présentation de Frank Rousseau sur l’utilisation de Python par les professionnels de l’animation 3D

et plein d'autres qui étaient sûrement très bien aussi...

Heureusement les conférences ont été filmées, donc une séance de rattrapage sera possible dès qu'elles seront en ligne !

J'ai participé hier et aujourd'hui à la conférence PyParis 2017, un événement qui couvre deux grosses thématiques :

le développement Python en général ;

l'écosystème lié à la data science et au machine learning en particulier.

C'est toujours l'occasion d'échanger avec la communauté, de recroiser des copains, et de se tenir au courant des tendances et des nouveautés. Voici donc un bref résumé de ce que j'en retiens.

Je suis un fan de Jupyter et de ses notebooks, et j'ai découvert avec joie les dernières nouveautés de cet outil :

Jupyterlab : un environnement intégré qui permet d'associer notebooks, fichiers, console dans différents panneaux et onglets ;

les widgets interactifs qui permettent d'afficher et de modifier des données de manière dynamique.

Une autre découverte, c'est dask, un système qui permet de distribuer facilement des calculs sur des arrays NumPy ou des dataframes Pandas sur un cluster ou sur les différents cœurs d'une machine.

Le sujet de la programmation asynchrone est toujours populaire, avec deux frameworks web basés sur asyncio, la bibliothèque introduite dans Python 3.4 :

aiohttp

sanic, inspiré de Flask

Toujours dans l'asynchrone, le projet Bonobo est un framework d'ETL basé sur Python 3.5+, qui m'a fait pensé à une version modernisée de Pyf et autres frameworks de flow-based programming.

Pour le traitement du langage naturel, j'ai entendu du bien de spaCy, dont les performances sont plus au niveau de l'état de l'art que le classique NLTK.

Côté task queues, je n'ai pas pu rester pour la présentation de Sylvain Zimmer , et côté data pipelines il semble que Luigi est relativement populaire, et j'aurais aimé assister à la présentation d'AirFlow qui a malheureusement été annulée.

Enfin, je note l'existence de line profiler qui permet d'analyser le temps d'exécution d'un programme au niveau de chaque ligne de code, plus finement que le profiling habituel au niveau de chaque fonction.

Here is a quick recipe to install the latest stable PostgreSQL version on a server using fabtools.

from fabric.api import task import fabtools from fabtools import require @task def postgresql(): """ Install the latest stable PostgreSQL version on Debian/Ubuntu from the PostgreSQL Global Development Group APT repository See: https://wiki.postgresql.org/wiki/Apt """ # Get the distrib codename # # Note that with fabtools >= 0.14.0 this will be: # # distrib = fabtools.system.distrib_codename() # distrib = fabtools.deb.distrib_codename() # Add the PGDG key require.file(url='http://apt.postgresql.org/pub/repos/apt/ACCC4CF8.asc') fabtools.deb.add_apt_key('ACCC4CF8.asc', update=False) # Add the PGDG repository require.deb.source( 'PGDG', 'http://apt.postgresql.org/pub/repos/apt/', '%s-pgdg' % distrib, 'main' ) # Install PostgreSQL require.postgres.server()

(Cet article est le 5e d'une série sur l'histoire de la Silicon Valley.)

Yahoo!

David Filo et Jerry Yang, deux doctorants de Stanford, créent début 1994 une page web pour partager leurs bookmarks (essentiellement des liens en rapport avec leur thème de recherche, au départ).

Cette page devient populaire auprès de leurs collègues, qui leur envoient leurs liens préférés. Boule de neige, et ils finissent par passer plus de temps à maintenir cette liste de sites qu’à bosser sur leur recherche.

La société sera introduite en bourse dès 1996, après avoir reçu des investissements de Sequoia Capital l’année précédente.

Google

Larry Page et Sergei Brin, encore deux doctorants de Stanford, travaillent sur les bibliothèques électroniques et l’indexation du web. Ils mettent au point un nouvel algorithme pour classer les résultats de recherche selon leur pertinence, évaluée en fonction des liens venant d’autres pages. Tout comme un article scientifique sera jugé important s’il est beaucoup cité, une page vers laquelle beaucoup d’autres pages établissent un lien sera jugée comme faisant référence.

L’université de Stanford dépose un brevet, et essaie de céder une licence de la technologie aux principaux moteurs de recherche de l’époque, dont Yahoo!. Mais ceux-ci sont occupés à transformer leurs sites en « portails », dans lesquels le moteur de recherche ne serait plus qu’un service parmi d’autres, jugé non stratégique (car au lieu de maintenir l’internaute sur le portail, il l’aide à aller voir ailleurs !).

En désespoir de cause, Page et Brin, qui veulent voir leur technologie réellement exploitée, se résolvent à créer leur entreprise.

Tout comme le PARC, Google bénéficiera d’un contexte favorable en terme de ressources humaines. L’éclatement de la bulle en 2001 remet sur le marché un grand nombre d’ingénieurs talentueux, à des prix très raisonnables.

(Cet article est le 4e d'une série sur l'histoire de la Silicon Valley.)

En 1969, Xerox est une société florissante, grâce au développement du marché des photocopieurs.

Loin de se reposer sur ses lauriers, le PDG voulait anticiper les évolutions des besoins de ses clients et donc de son métier.

Pour donner corps à sa vision, il demande au responsable de la R&D de créer un nouveau centre de recherche, qui sera installé à Palo Alto.

En 1970, le gouvernement diminuait les crédits de recherche dirigés vers l’informatique, ce qui a permis à Xerox de recruter bon nombre des meilleurs chercheurs du domaine.

Pendant trente ans, ce laboratoire de recherche privé sera à l’origine de nombreuses innovations. Certaines seront exploitées par Xerox dans ses produits (imprimantes laser, copieurs), d’autres seront adoptées ailleurs (l’interface graphique chez Apple).

Lire la suite...

(Cet article est le 3e d'une série sur l'histoire de la Silicon Valley.)

Bill Hewlett et Dave Packard étaient étudiants à Stanford, et ont été diplômés en 1934. Ils ont eu l’idée d’un nouvel oscilloscope, en ont parlé à leur ancien professeur, le fameux Frederick Terman (voir la première partie), qui les a encouragés à créer leur société.

Avec un capital de 1 000 dollars, ils ont démarré dans leur garage à Palo Alto...

Dans les années 1970, Hewlett-Packard est devenu une très grande société. Un de ses employés, Steve Wozniak, rêve de réaliser un micro-ordinateur, mais le projet n’est pas jugé intéressant par HP, qui lui laisse les droits sur son invention.

C’est avec son ami Steve Jobs, dans le garage de ce dernier, qu’ils démarreront Apple Computer en 1976.

Lire la suite…

(Cet article est le 2nd d'une série sur l'histoire de la Silicon Valley.)

William Shockley, bien que né à Londres, a passé son enfance à Palo Alto. Diplômé de CalTech, il part lui aussi faire son doctorat au MIT, après quoi il reste travailler sur place, aux Bell Labs, où il a co-inventé le transistor, qui lui vaudra le prix Nobel de physique en 1956.

En 1953, il quitte les Bell Labs et revient sur la côte Ouest. Après un passage à CalTech, il s’installe à Moutain View où en 1955 il fonde Shockley Electronics.

Si Shockley est un brillant scientifique, c’est un manager exécrable, réputé pour être tyrannique et paranoïaque. Lorsqu’il décide d’abandonner les recherches sur le silicium, huit de ses ingénieurs qui ne sont pas du même avis (les « huit traîtres ») quittent la société en 1957 pour fonder Fairchild Semiconductors. C’est le début d’une série d’essaimages, qui donnera naissance à toute une industrie.

Deux de ces huit traîtres, Gordon Moore et Robert Noyce, quitteront à leur tour Fairchild en 1968 pour fonder Intel. (Andy Grove, un autre ancien de Fairchild, sera le 3e employé d’Intel, avant d’en devenir le PDG de 1987 à 1998.)

Ce seront également des anciens de Fairchild qui fonderont AMD ou encore National Semiconductors.

L’emploi du terme de « vallée du silicium » pour désigner cette zone date du début des années 1970, époque où est sorti le premier microprocesseur, le 4004 d’Intel.

Robert Kleiner, un autre des huit traîtres, fondera quant à lui l’industrie californienne du capital risque en s’associant avec Tom Perkins, un ancien de chez HP.

Durant les années 1980, l’industrie américaine des semiconducteurs dût faire face à une féroce concurrence des fabricants japonais. Beaucoup d’usines ont alors été délocalisées, l’ingénierie et la direction des entreprises restant cependant dans la vallée.

(Cet article est le 1er d'une série sur l’histoire de la Silicon Valley.)

La Silicon Valley s’étend sur une zone d’environ 250 km2, entre les villes de Palo Alto et San José. Jusque dans les années 1940, l’agriculture était la principale activité économique de la région, surtout connue pour ses vergers.

C’est la seconde guerre mondiale qui va changer la donne. L’effort de guerre mobilise toute la nation, y compris les universités, qui sont mises à contribution dans des projets de recherche appliquée (nucléaire, cryptographie, radars...) financés par le gouvernement fédéral.

Frederick Terman, diplômé de Stanford, était parti au MIT dans les années 1920, où son directeur était Vannevar Bush (autre personnage intéressant). Pendant la guerre, Terman a dirigé un gros labo à Harvard qui travaillait sur le brouillage des radars ennemis.

Après la guerre, il retourne à Stanford comme doyen du département d’ingénierie, et monte un labo de recherche appliquée dans le domaine des micro-ondes, de l’électronique et des radars. Si pendant la guerre, l’essentiel des fonds fédéraux sont allés à des universités de la côte Est, il est bien décidé à ce que ça change, et utilise ses relations pour attirer des financements à Stanford.

Les financements fédéraux (notamment militaires, la guerre froide entraînant un effort continu autour des technologies liées à l’espionnage : détection et brouillage de radars, cryptographie, etc.) permettent d’attirer des professeurs de talent, entrainant un développement important des sciences et de l’ingénierie à Stanford, amorçant un cercle vertueux, et transformant l’université en ce qu’elle est aujourd’hui.

Lire la suite...

Sometimes, you have dozens of messages clogging your Postfix queue, all with the same bogus recipient. Here is how to delete them in a go, using the postsuper command and some scripting magic (of course, you need to replace [email protected] with the desired recipient):

mailq | tail -n +2 | grep -v '^ *(' | awk 'BEGIN { RS = "" } # $7=sender, $8=recipient1, $9=recipient2 { if ($8 == "[email protected]" && $9 == "") print $1 } ' | tr -d '*!' | sudo postsuper -d -

Mac OS X comes with bash as the default shell, but it does not include the very convenient completion functionality commonly available in Linux distributions. So here are the steps to enable it.

First, you need to install the bash-completion package using the great Homebrew package manager:

brew install bash-completion

Then, enable the completions for the brew command itself:

ln -s `brew --prefix`/Library/Contributions/brew_bash_completion.sh `brew --prefix`/etc/bash_completion.d/

Now, edit your ~/.bash_profile to add the following lines:

export USER_BASH_COMPLETION_DIR=~/.bash_completion.d if [ -f `brew --prefix`/etc/bash_completion ]; then . `brew --prefix`/etc/bash_completion fi

Finally, create a file named ~/.bash_completion with the following lines (this will allow you to add your own completion scripts in the ~/.bash_completion.d/ directory):

if [ -d $USER_BASH_COMPLETION_DIR -a -r $USER_BASH_COMPLETION_DIR -a \ -x $USER_BASH_COMPLETION_DIR ]; then for i in $USER_BASH_COMPLETION_DIR/*; do [[ ${i##*/} != @(*~|*.bak|*.swp|\#*\#|*.dpkg*|.rpm*) ]] && [ \( -f $i -o -h $i \) -a -r $i ] && . $i done fi unset i

Presentation by Christian Baudry at the first meeting of our "Lean Startups and Business Models" group in Paris on November 3rd, 2010.

Note : the first ~2 minutes are missing, and I had to stop recording after ~25 minutes (no space left on my iPhone). Hope this is useful nevertheless!