Le blog d'un geek devenu directeur technique

Beautifully Simple

Clean and modern theme with smooth and pixel perfect design

Learn more

Easy Customizable

Over a hundred theme options ready to make your website unique

Learn more

Contact Form Ready

Built-In Contact Page with Google Maps is a standard for this theme

Learn more

RDV AFUP Interopérabilité des frameworks mercredi 02 avril

Mercredi se tiendra le prochain RDV AFUP, dont le thème sera l’interopérabilité des frameworks PHP.

Deux conférenciers, David Négrier (TheCodingMachine) et Frédéric Marand (Osinet) vont venir pour parler des normes FIG et de l’injection de dépendance.

Cela se tiendra à la salle Spark de Microsoft, 6 rue du Sentier, 75002 Paris. Ouverture des portes à 18h30 (début des sessions à 19h00).
L’entrée est gratuite, il faut juste s’inscrire à l’avance. Attention, les places sont limitées.

Plus d’infos et inscription sur le site de l’AFUP.

L’email n’est pas mort (suite)

Il y a 4 ans, j’écrivais un article intitulé L’email n’est pas mort, dans lequel je réagissais au courant de pensée disant que la messagerie électronique était condamnée en milieu professionnel, face aux réseaux sociaux d’entreprise.

Pour faire simple, je disais que l’email est un outil parmi beaucoup d’autre (j’en listais une douzaine), et que vouloir travailler sans email est aussi intelligent que de vouloir travailler sans téléphone : il ne faut pas travailler avec ce seul outil, mais ça ne veut pas dire qu’il faut le bannir pour autant.
La force des outils universels, c’est avant tout l’usage et la pérennité dont ils bénéficient, qui sont assez difficile à prendre en défaut.

Ce qui me fait revenir là-dessus, c’est l’annonce de l’arrêt par Facebook de leur système de messagerie, qui avait été présenté en 2010 comme un « Gmail-killer » et qui n’aura finalement été qu’un pétard mouillé.

L’autre fameux tueur d’email qui n’aura pas fait long feu, c’est Google Wave. L’outil était splendide, mais difficilement utilisable au quotidien. Présenté en 2009, Google annonçait sa mort un an plus tard, pour finalement fermer le service début 2012.

Bref, que faut-il penser de tout ça ? Eh bien qu’il est difficile de remplacer quelque chose d’aussi universel que l’email. Mais plutôt que de vouloir le remplacer, je reste persuadé qu’il est beaucoup plus malin de chercher à enrichir le système, à le compléter, à s’y adosser pour aller plus loin.

Fonctionnement interne des langages de programmation

Juste pour le fun, voici quelques liens vers des sites qui détaillent le fonctionnement interne de plusieurs langages de programmation. C’est très intéressant à étudier.

Si vous connaissez d’autres sources d’information de ce type, n’hésitez pas à les ajouter dans les commentaires.

PHP
PHP Internals Book

Perl
Perl 5 Internals
Parrot

Lua
The Implementation of Lua 5.0 (PDF)
The Virtual Machine of Lua 5.0 (PDF)
A No-Frills Introduction to Lua 5.1 VM Instructions (PDF)

Java
The Structure of the Java Virtual Machine
JVM Internals blog

Python
Design of CPython’s Compiler
Python internals: Working with Python ASTs
Python’s Innards

Ruby
Ruby Under a Microscope
Ruby Internals (70 slides)

Dart
The Essence of Google Dart: Building Applications, Snapshots, Isolates

Javascript
The V8 JavaScript Engine
V8 Internals: Building a High Performance JavaScript Engine

.NET / CLR
Internals to .NET
Drill Into .NET Framework Internals to See How the CLR Creates Runtime Objects
.NET Type Internals – From a Microsoft CLR Perspective

Forth
A sometimes minimal FORTH compiler and tutorial for Linux (part 2)

Autres
The Potion Language

Edit : J’ai ajouté des liens Lua et Forth qui m’ont été transmis par @pchapuis. Encore merci !  :-)

Les 9 règles de Tim Minchin

Je vous invite à regarder la vidéo qui suit. Dans celle-ci, on peut voir Tim Minchin − un comédien et musicien australien − donner un discours de « graduation » (remise de diplôme universitaire). Ce qui est intéressant, c’est que l’homme est à la fois amusant et grave ; c’est un anti-conformiste qui a fait ses études dans l’université où le discours à lieu.

Il donne 9 règles à suivre, que je liste ici mais il faut regarder la vidéo pour en saisir toute la profondeur :

  1. Vous n’avez pas à avoir un grand rêve. Célébrez les micro-victoires. Si vous vous focalisez trop sur un objectif à trop long terme, vous risquez de passer à côté du vrai sens de votre vie, qui sera apparu entre-temps dans la périphérie de votre champ de vision.
  2. Ne cherchez pas le bonheur. Le bonheur est comme un orgasme : si vous y pensez trop, il disparaît. Rendez quelqu’un heureux et vous en aurez les retombées. Nous n’avons pas évolué de manière à être continuellement heureux.
  3. Vous êtes chanceux (d’être là). S’en rendre compte vous rendra plus humble et compatissant. L’empathie est un affaire d’intuition, mais on peut travailler dessus intellectuellement.
  4. Faites de l’exercice. Celui que vous voulez, mais prenez soin de votre corps. Vous allez vivre près de 100 ans, avec un niveau de richesse qui dépasse ce que la plupart des hommes ont pu rêver à travers l’histoire ; si vous ne voulez pas vivre cela en étant déprimé, faites du sport.
  5. Ayez des opinions tranchées. Les opinions sont comme les trous du cul, tout le monde en a un ; sauf que vos opinions seront constamment examinées en profondeur. Ayez une pensée critique qui soit la votre et non simplement celle des autres. Soyez intellectuellement rigoureux.
  6. Soyez un professeur. Partagez vos idées. Ne prenez par votre éducation pour acquise. Réjouissez-vous de ce que vous apprenez et diffusez-le.
  7. Définissez-vous par ce que vous aimez. Nous avons tendance à nous définir en opposition à quelque chose. Exprimez plutôt votre passion et vos louange pour ce que − et ceux que − vous admirez.
  8. Respectez les gens qui ont moins de pouvoir que vous.
  9. Ne vous précipitez pas. Vous n’avez pas besoin de savoir déjà ce que vous ferez pendant le restant de votre vie. Ceux qui connaissent le chemin que suivra leur carrière dès l’âge de 20 ans ont tous une « mid-life crisis ».

Au passage, il dit que l’art et la science ne sont pas antinomiques, ce qui est une pure vérité. Il ne faut pas être anti-scientifique pour faire de l’art. Il définit la science comme l’acquisition incrémentale de connaissances à travers l’observation. Il ajoute que l’art et la science doivent travailler ensemble pour améliorer la manière dont les connaissances sont communiquées.

(pensez à activer les sous-titres − ils sont en anglais, mais ils aident bien à comprendre par moments ; autre chose : son discours correspond aux 12 premières minutes de la vidéo)

Voici le lien original sur lequel j’étais tombé, qui m’a donné envie de vous le partager : http://www.upworthy.com/this-is-the-most-inspiring-yet-depressing-yet-hilarious-yet-horrifying-yet-heartwarming-grad-speech

Appel à avis : Handlers d’événement inline en Javascript

À la suite de mon dernier article, au sujet des technos navigateur, je prépare un autre billet consacré aux langage alternatifs qui génèrent du Javascript. Et au détour de tout ça, je suis tombé sur une page de la documentation Dart qui m’a un peu interloqué.

Cette page, consacrée à l’intégration de Dart dans du HTML, parle entre autre des handlers d’événement inline (désolé pour le franglais, je n’ai pas trop de synonyme correct qui me vienne spontanément à l’esprit). Vous savez, c’est le fait de mettre un “onclick” ou un “onchange” sur un élément HTML pour appeler une fonction Javascript lorsque l’événement en question est exécuté.

With JavaScript, programmers can embed inline event listener code directly onto HTML nodes. However, this is typically discouraged in modern JavaScript applications. HTML pages generally render more quickly if listeners are added programmatically afterwards. Modern security guidelines also discourage inline code. As such, we propose to not allow inline Dart listeners.

J’ai été un peu étonné de lire ça. En cherchant 30 secondes sur le web, je suis tombé sur une question/réponse du site StackOverflow :

Most experienced developers shun this method, but it does get the job done; it is simple and direct.

Je fais donc appel à l’aide des lecteurs de ce blog.
Je code pas mal de Javascript ; pas autant que de PHP, mais ce doit être au final mon deuxième langage en quantité de code écrit (eh oui, même devant le C). J’écris du code que j’estime propre, en créant des objets et en les rangeant dans des namespaces, utilisant des callbacks là où ça se justifie, tout en se gardant du « callback hell ».

Et personnellement, j’ai toujours trouvé qu’il était plus facile de maintenir du code avec les appels d’événements indiqués dans le HTML, plutôt que de les positionner par Javascript. Quand on cherche ce qu’il se passe quand on clique sur tel élément, ou quand on tape du texte dans un champ texte, il est très facile de regarder le code HTML, voir quel méthode de quel objet est appelée, et enfin aller voir directement dans cette méthode.

Donnez-moi votre avis s’il-vous-plait.

Préférez-vous ce type de code :

<script>
var site = new function() {
    this.init = function() {
        // quelques initialisations
    };
    this.checkContent = function(text) {
        // un peu de code applicatif
    };
};
</script>
<input type="text" name="content"
 onblur="site.checkContent(this.value)" />

Ou plutôt celui-ci :

<script>
var site = new function() {
    this.init = function() {
        // initialisation du handler d'événement
        $("#edit").on("blur", function() {
            site.checkContent();
        });
    };
    this.checkContent = function() {
        var text = $("#edit").val();
        // un peu de code applicatif
    };
};
</script>
<input id="edit" type="text" name="content" />

Et pourquoi ?

Dart, NaCl, Pepper, Emscripten, PNaCl : Du nouveau du côté de la programmation sur navigateur

Comme tous ceux qui font du développement web, je code pas mal en Javascript. J’en ai déjà parlé sur ce blog, c’est un langage dont j’apprécie la souplesse mais dont les limitations m’empêchent d’imaginer faire du vrai génie logiciel dessus. J’ai beau faire des développements JS “propres”, avec l’utilisation d’objets rangés dans des namespaces hiérarchiques, je ne cesse de pester contre l’âpreté de son modèle objet.

Toutefois, pas mal de choses bougent en ce moment du côté du développement sur les navigateurs. Je n’ai pas encore vraiment mis le nez dans tous ça − à part lire de la documentation − mais ça reste intéressant d’en parler un peu.

Dart

Pour commencer, le langage Dart − créé par Google pour remplacer un jour le Javascript − vient de voir son SDK publié en version 1.0. C’est un langage qui fait voler en éclat les problèmes du Javascript ; son modèle objet est complet, il gère nativement les packages, et il peut être aussi bien fortement que faiblement typé.

Pour le moment, seule une version spécialement modifiée du navigateur Chromium (Dartium) est capable d’interpréter directement du code Dart. Mais il est possible de « compiler » du code Dart en code Javascript, permettant son exécution par n’importe quel navigateur. Là où ça devient intéressant, c’est que cette phase permet d’optimiser le code Javascript généré au point de le rendre en 42% et 130% plus rapide que le même code écrit nativement en Javascript.
C’est d’autant plus intéressant que les interpréteurs Javascript ont connu une énorme augmentation de leurs performances ces dernières années.

Bon, par contre je ne suis pas persuadé que passer par une phase de compilation pour du code client soit très pratique d’utilisation. Mais il reste toujours la possibilité de développer sur Dartium, puis de tester le code JS généré sur les autres navigateurs.

En tout cas, si le Go (l’autre langage de Google) a réussi à obtenir un peu de “traction”, j’ai le feeling que le Dart a le potentiel pour se faire une place de choix dans l’univers des langages de programmation modernes.

Programmation C/C++

Bon, quand il s’agit d’obtenir les meilleures performances possible, on finit quoi qu’il en soit par programmer en C ou en C++. Les ingénieurs de Google en étaient arrivés à cette conclusion et ont développé NaCl (pour “Native Client”) qui est une techno permettant d’exécuter dans un navigateur du code compilé pour processeur x86.
Enfin, quand on dit « dans un navigateur »… ça marche tant que le navigateur en question est Chrome, hein.

En plus, avec l’API Pepper, le code C/C++ n’est plus cantonné à une simple fenêtre, mais il peut communiquer avec le navigateur, ça peut amener à des choses sympatiques.

Mais fondamentalement, j’ai toujours trouvé cette idée bizarre. Oui, c’est génial d’avoir Quake qui tourne dans un navigateur web. Mais le principe fondamental du web, c’est de reposer sur des standards multi-plateformes. Embarquer du code compilé nativement pour un type de processeur au milieu de tout ça, c’est moche.

Ça tombe bien, car deux technologies différentes permettent de contourner ce problème. Les deux reposent sur une particularité du compilateur LLVM. Pour schématiser grossièrement, un front-end prend en charge la compréhension d’un langage de programmation, génère un bytecode spécifique, qui est ensuite utilisé par le back-end pour produire un exécutable natif. Et donc, le bytecode intermédiaire n’est pas dépendant du processeur sur lequel il va être exécuté.

La première techno basée sur ce bytecode s’appelle Emscripten. Elle prend du bytecode LLVM, et génère du code Javascript qui peut être exécuté directement par le navigateur. Le résultat est assez bluffant, dans la mesure où le moteur Unreal 3 a été porté en seulement 4 jours, et que la démo Epic Citadel qui est basée dessus est vraiment impressionnante.
En plus, avec la bibliothèque pepper.js, il est possible d’atteindre le même résultat qu’avec l’API Pepper (intégrée à NaCl, citée plus haut).

La seconde techno, issue de Google (décidément !), s’appelle PNaCl (pour Portable Native Client). Grosso modo, vous prenez NaCl, vous lui ajoutez Emscripten, vous mélangez bien, et voilà le résultat. En fait, le navigateur intègre un interpréteur de bytecode LLVM. On obtient ainsi le meilleur de chaque monde : la vitesse d’exécution qu’on est en droit d’attendre d’un code C/C++, avec la portabilité qu’on est en droit d’exiger sur le web.

Conclusion

Comme je le disais, ça bouge du côté du développement sur navigateur. Et c’est assez excitant. Je vais avoir du mal à trouver le temps d’expérimenter ces technos, mais j’en ai bien envie.

On peut remarquer que le vénérable Javascript, grâce à son support quasi-universel, reste le garant de la compatibilité de ces technologies (Dart, Emscripten) avec tous les navigateurs existants. Il devient le bytecode générique du web, un peu comme le C est utilisé par certains langages exotiques comme un bytecode intermédiaire (j’en parlais dans un article sur la création d’un interpréteur).
Pas sûr qu’il soit très simple ni rapide de faire une triple compilation (C/C++ vers bytecode LLVM, puis vers Javascript, pour enfin être interprété sur le navigateur, éventuellement avec de la compilation JIT). Mais si on peut accélérer le codage en développant sur un navigateur spécifique, pour ensuite être compatible avec tous les autres, ça peut en valoir la chandelle.

Lancement de FineInfo, site de veille

Je viens de passer un peu de temps à créer le site FineInfo. C’est une sorte de Twitter-like dont le but est de centraliser la veille réalisée par les employés de mon entreprise, Fine Media. Je parle bien de « veille » au sens large, et pas seulement de « veille technique », car le but est de partager des infos sur des sujets assez large.

Développement, administration système, webdesign, référencement, gestion de communauté, marketing, e-business, … pas mal de thèmes potentiellement traités.

L’outil est encore en version beta, dans le sens où il fait ses premiers pas et qu’il va sûrement s’améliorer. Dans le sens aussi qu’il n’a été ouvert qu’à un nombre restreint de personnes dans l’entreprise, et qu’avec le temps j’espère que de plus en plus de monde l’utilisera.

Dans la partie immergée de l’iceberg, il y a plusieurs mécanismes développés pour faciliter le partage d’information. Quand nous voulons partager un lien, le système va récupérer automatiquement les informations sur la page, qu’il est ensuite possible de modifier ou compléter. J’ai même fait une passerelle email (en utilisant ce que j’avais écrit dans un précédent article) : nous pouvons partager une info en l’envoyant par email à une adresse spécifique.
Pour le personnel de Fine Media, il est possible de s’abonner à une newsletter pour recevoir directement dans sa boîte aux lettres électronique les infos qui ont été partagées sur le site.

N’hésitez pas à venir consulter le site et à vous abonner à son flux RSS. Faites-moi vos retours.

Edit : J’avais oublié de donner l’adresse du site. C’est http://fineinfo.net

Plates-formes de développement privilégiées

Je réfléchissais dernièrement à une chose un peu particulière : le fait que plusieurs plate-formes informatiques ont eu des environnements de développement privilégiés, qui en sont devenus plus ou moins indissociables.

Psion – OPL

C’est en fait le couple auquel je pensais initialement, et qui m’a amené à écrire cet article. Le langage OPL (Open Programming Language) est un dérivé du Basic que la société anglaise Psion a intégré à ses ordinateurs de poche. Au milieu des années 80, ces machines n’étaient pas très sexy, et ressemblaient plutôt à des calculatrices améliorées, mais elle n’en étaient pas moins de vrais ordinateurs programmables.

Psion Organiser

Mais c’est avec les Psion série 3 que les choses prirent une dimension différente. Cette machine a été lancée en 1991 puis a été améliorée durant toute la décennie, avec des améliorations concernant la taille de l’écran, la puissance du processeur ou la mémoire embarquée (voir des copies d’écran du système).

J’ai personnellement possédé un Psion 3a pendant la seconde moitié des années 90. J’avais été marqué par la sortie du premier modèle quelques années auparavant. C’était le premier véritable ordinateur de poche.

Psion Series 3a

Plusieurs applications étaient embarquées : base de données, traitement de texte, tableau, agenda, … Mais surtout, ce qui a fait le succès de cet ordinateur à mes yeux, était la facilité avec laquelle n’importe qui pouvait créer de nouveaux programmes et les diffuser. Et cela était possible grâce à l’intégration du langage OPL et d’un environnement de développement sommaire mais fonctionnel dans le système.

Psion avait même eu l’intelligence de proposer des émulateurs de ses machines, qui tournaient sous MS-DOS. Ils permettaient de développer en utilisant un clavier plus pratique que celui des machines de poche. Ces émulateurs restent un bon moyen de faire revivre ces systèmes, grâce à DOSBox (voir ce lien).
Néanmoins, une énorme quantité de programmes ont été créés directement sur des Psion Série 3, et distribués par les différents moyens de l’époque (disquettes ou CD dans les magazines, puis internet).

Pourquoi l’OPL était-il si intéressant ? Parce qu’il était simple à apprendre − c’était un dérivé du Basic, en plus puissant pour l’époque − et qu’il proposait des routines graphiques faciles à mettre en œuvre, permettant de créer des interfaces graphiques sans trop de difficultés.

Pour la petite histoire, Psion a proposé par la suite un ordinateur plus performant, le Série 5, là encore avec l’OPL intégré. Puis le système du Psion Série 5 a servi de base au système Symbian, qui a longtemps été au cœur des téléphones Nokia et Ericsson.

Macintosh – HyperCard

L’exemple le plus marquant est sûrement le couple formé par HyperCard et le système d’exploitation des Macintosh à partir de 1987 et durant les années 90.

L’ordinateur qui innovait le plus à l’époque (en dehors de l’Amiga, bien sûr − petit troll gratuit), notamment par la simplicité d’utilisation de son interface graphique, aurait pu rester une machine difficile à programmer, que seule une élite aurait pu enrichir de leur logiciels. Mais le génie de Bill Atkinson a créé un outil qui mélange à la fois le logiciel de dessin, la base de données, le langage de programmation et l’hypertexte.

Pour comprendre comment fonctionnait HyperCard, vous pouvez regarder la vidéo proposée sur le site hypercard.org :

Je ne sais pas s’il existait déjà des outils de programmation WYSIWYG, mais HyperCard a clairement démocratisé cela.

Windows – Visual Basic

Autre cas emblématique, le Visual Basic qui est devenu l’un des environnements de développement les plus utilisés au monde, dont la première version a été lancée sous Windows 3 au début des années 90 (1991 pour être exact).

Lancé 4 ans après HyperCard, il en reprenait les principes de programmation événementielle sur la base d’une interface graphique créée à la souris, en y ajoutant des concepts provenant du couple Project Builder / Interface Builder présenté en 1988 sous NeXTSTEP.

Visual Basic

Le succès a commencé avec la version 3, qui s’appuyait elle-même sur le succès de Windows 3.1.

Pour avoir programmé en VB au milieu des années 90, je peux affirmer qu’un tel langage fait prendre plein de mauvaises habitudes quand on ne sait pas encore vraiment développer. Par contre, il permet de créer facilement et rapidement des applications relativement complexes, et son succès n’est absolument pas volé.

Mac OS X – XCode

Héritier spirituel du Project Builder déjà cité, XCode est l’environnement de développement offert gratuitement par Apple aux possesseurs de Mac. L’un de ses grands intérêts est de servir à la fois pour développer des applications pour Mac OS X, mais aussi pour iOS.

© Apple

 © Apple

Sa gratuité et sa qualité générale en ont fait l’outil incontournable pour tous les développeurs Mac et iOS.

Et alors ?

Tout ça, c’est bien beau, mais à part l’aspect historique des choses, ça sert à quoi ?

En fait, j’ai deux réflexions qui me viennent à l’esprit.

La première, c’est que toute plate-forme informatique devrait fournir des outils de création gratuits et facile à prendre en main (on peut argumenter que le Visual Basic n’est pas gratuit, mais on connait aussi le taux de piratage des logiciels sous Windows, hein). Je ne parle pas d’outils ultra-pointus ; même quelque chose de limité permet toujours à des gens d’exprimer leur créativité. Je pense évidemment à des outils de développement ; mais c’est aussi valable pour de la création graphique (dessin bitmap, vectoriel, 3D), musicale, …
Il y a toutefois une légère différence : offrez un logiciel de dessin, et vous aurez des dessins ; offrez un outil de programmation et vous aurez des logiciels de dessins (et des dessins), des logiciels de musique (et des chansons), des éditeurs web (et des sites web), …

La seconde réflexion que je me suis faite, c’est qu’il faut toujours permettre aux gens de créer directement sur la plate-forme à laquelle est destinée les programmes qui sont développés. D’un côté l’exemple du langage OPL sur les Psion montre que cela a permis à tous les utilisateurs de ces machines de créer des programmes, sans attendre que des logiciels commerciaux remplissent tous les besoins.
De l’autre côté, je pense à GeoWorks Ensemble, une surcouche graphique de MS-DOS concurrente de Windows 3.x (apparue en 1990, soit 1 an avant Windows 3.0). Cette plate-forme était d’une qualité incroyable (multitâche, polices vectorielles, rapidité incroyable, …), mais nécessitait une station de travail Sun Sparc hors de prix pour développer des logiciels dessus. Échec commercial.

Je pense réellement que les terminaux de consommation passifs sont une chose qui ne devrait pas exister. Évidemment, la plupart des utilisateurs veulent pouvoir lire, regarder, écouter des média diffusés sur leurs appareils ; mais cela ne doit pas empêcher les autres utilisateurs de créer facilement et rapidement de nouveaux produits et services pour ces appareils.

Le futur ?

Ce qui m’embête un peu, c’est que j’ai donné des exemples plutôt anciens (à part XCode). L’informatique a évolué ces dernières années. Netbooks, ultraportables, tablettes et téléphone portables nous ont fait entrer dans une ère où l’ultra-mobilité règne.

Je trouve dommage que les éditeurs de systèmes pour tablettes imposent tous des SDK officiels qui s’utilisent uniquement sur ordinateur. Même si le SDK Android fourni par Google a l’avantage d’être multi-plateformes, il ne permet pas de coder directement sur une tablette Android.

Mais est-ce qu’un appareil mobile ne peut pas servir au développement ? L’exemple du Psion montre que si. D’ailleurs, il existe des solutions comme Codea (iOS) ou Droid Develop (Android) qui l’autorisent, et quand on regarde la vidéo de présentation de Codea, on se dit qu’il y a moyen de faire de très belles choses directement sur une tablette :

Pourtant, je reproche à ces solutions d’être encore trop proche du code. Il faut apporter des outils permettant de créer. Facilement. Directement sur l’appareil.

Est-ce que vous avez en tête d’autres exemples de plate-forme liée à une solution de développement privilégiée ?

Recrutement : Développeur PHP 5

Fine Media, l’entreprise que j’ai co-créé et dont je suis le directeur technique, est à la recherche d’un développeur web.

Présentation de l’entreprise

Nous sommes éditeurs de sites web. Notre activité principale porte sur les sites ComprendreChoisir, qui sont un ensemble de plus de 420 sites de niche, sur des sujets aussi variés que les fenêtres, la défiscalisation ou le home cinéma. C’est notre « encyclopédie de la vie pratique ».
Nous éditons aussi des sites communautaires, comme CommentFaitOn ou DcoPhoto.

Nous sommes localisés dans le 17è arrondissement de Paris (métro Villiers).

L’entreprise existe depuis 2007 et est une filiale du groupe Solocal (ex Groupe PagesJaunes) depuis 2011.
Nous sommes une vingtaine de personnes, et l’équipe technique comprend 9 personnes.

Environnement technique et méthodes de travail

  • Linux. On utilise de l’Ubuntu Server sur les serveurs, et de l’Ubuntu Workstation sur les postes de développement.
  • PHP 5. Tout est développé en PHP, en objet.
  • MySQL. On fait des requêtes assez compliquées. Il vaudrait mieux que vous sachiez la différence entre une sous-requête et une jointure.
  • Redis. Nous faisons de l’hybridation de bases, cela peut être l’occasion pour vous d’approcher le noSQL de près.
  • Temma. Nous utilisons notre propre framework MVC, qui est publié sous licence libre.

Nous travaillons suivant une méthode dérivée de SCRUM. Nous faisons des cycles itératifs d’une durée d’un mois (cf. l’article où j’en parlais).

Ce que vous aurez à faire

  • Améliorer notre framework MVC, ainsi que notre CMS. Ils sont petits et légers, des vrais jouets faciles à faire évoluer dans les directions qui nous intéressent.
  • Génie logiciel : modélisation des objets métier, évolution du modèle de base de données, développement orienté objet.
  • Gestion de projet : écriture des spécifications techniques, suivi du planning, supervision des tests.

Je cherche quelqu’un ayant déjà fait ses armes en développement Web, et qui aime ça. Un passionné avec des idées à faire valoir, ayant envie de les partager et de les appliquer. Une personne qui sache travailler en équipe, qui cherche à apprendre des choses nouvelles.

Alors si vous êtes ambitieux, si vous avez des idées techniques intéressantes, si vous aimez le Web et avez envie de bosser sur des trucs pointus et originaux, envoyez-moi votre CV à l’adresse amaury.bouchard@finemedia.fr.

Ajout : Suite à des questions, je préfère préciser que nous ne recherchons pas de prestataire, ni de développeur travaillant à distance. L’idée est d’embaucher quelqu’un qui fera partie intégrante de l’équipe − y compris dans sa localisation géographique.

Conférence « Créer une base noSQL en une heure »

Comme je le disais dans mon billet précédent, j’ai donné samedi une conférence ayant pour thème la création d’une base de données par paires clé-valeur, dans le cadre de l’Open World Forum.

La conférence s’est très bien déroulée, et elle s’est poursuivie avec des discussions très intéressantes au sujet des bases de données, de la réplication et du clustering.

Voici les slides que j’ai présentés :

Vous pouvez retrouver l’intégralité du code source de ce serveur ultra-simplifié sur GitHub. Sans oublier le projet FineDB, qui a servi de source d’inspiration.