Cela fait maintenant quelques temps que je donne plus de nouvelles, plus un signe de technologie, de recherche. Et pourtant, de la recherche, il y en a eu ! Après avoir passé une longue période à essayer les différents outils de QA dédiés au web, j’ai passé ces derniers mois à essayer – et exploiter – les NoSQL. La littérature est déjà bien large sur le sujet dans ses généralités. Cassandra, HBase, Voldemort, Redis… tout y passe, du plus ancien dépôt clé/valeur au plus évolué système orienté graphe ou document. Je vais parler ici finalement de MongoDB, que j’ai pu torturer en long, en large et en travers, et qui appartient justement à la catégorie des NoSQL orienté document.

Un NoSQL, pourquoi ?

Certainement pas par effet de mode. Une prise de décision basée sur ce critère ne serait que folie. Par besoin ? Il va être temps de définir ces besoins. Car on assiste à bon nombre de projets qui tendent à délaisser ces bons vieux SGBDR au profit de leurs cousins non-relationnels. Or, la plupart de ces projets ont – selon moi - surtout un problème de conception et non d’outils. Si ces projets reprochent à MySQL une certaine lenteur, ils feraient bien mieux d’apprendre à tirer profit d’une configuration optimale, et d’une conception sérieuse du modèle de données, avec une stratégie d’indexation adaptée. On ne le dira jamais assez : des bases comme MySQL, PostgreSQL ou autre ont perduré pendant des années. La réplication est fonctionelle. Le partitionnement est possible. Les plus gros l’ont utilisé et continuent à l’utiliser. Twitter avoue même rester sur MySQL après avoir essayé timidement de mettre en place Cassandra. Non, pour moi, une des raison qui peut pousser à envisager une solution NoSQL est ailleurs. La grosse plus value de ces solutions reste toujours leur très bonne disposition à « scaler ». Autrement dit, si on souhaite absorber un déluge de données croissant, on y trouvera un allié puissant pour rapidement doubler, quadrupler la puissance de stockage, sans se lancer dans une trop lourde configuration du partitionnement et/ou de la réplication.

Orienté document, pourquoi ?

Comme d’habitude, nuançons ce point de vue par un autre apport, mais celui-ci est propre au modèle de stockage choisi. On en dénombre 4 :

• dépôts clé/valeur (Voldemort, Redis…)
• orientés colonne (Cassandra, HBase…)
• orientés documents (CouchDB, MongoDB…)
• orientés graphes (Neo4J…)

Chaque modèle répond à des problématiques et stratégies de stockage différentes. MongoDB stocke des « documents ». Un document est un ensemble de paires clé/valeurs, ici décrites au format BSon. Ce format est largement comparable au JSon, modulo quelques types additionnels.

{
blog: http://www.zt.com,
authors: [adrien, robot],
comments:
[
{ author: robert, age: 42 },
{ author: johanna, age: 25 }
]
}


Voolà donc typiquement ce qui peut être stocké dans une collection (= table) MongoDB. Ce stockage est dit « schemaless », traduire par « sans schéma ». Les documents ne correspondent à aucune définition formelle qui aurait été préalablement définie. Ainsi, on pourrait très bien rajouter un autre document « blog » similaire à l’exemple, mais sans champs « authors » et avec une colonne « keywords ». le NewYorkTimes tire partie de ce modèle avec MongoDB en permettant à ses contributeurs d’ajouter des méta-données à la volée pour chaque photo soumise. En effet, on ne retrouve pas forcément les même méta-données entre une photo de lieu et celle d’une star. Certes, la chose reste largement faisable avec les outils actuels. Le modèle document est juste extrémement adapté à ce type de stockage, sans s’occuper d’un modèle relationnel et ses multiples contraintes. Je sais, je viens de donner un argument qui pourrait remettre en cause le premier : certains NoSQL ont un rôle qui dépasse de loin celui d’un entrepôt extensible et redondé.

MongoDB, pourquoi ?

Voyons maintenant le cas particulier de MongoDB. C’est un NoSQL orienté documents, qui se qualifie par l’acronyme « CP » du théorème de CAP.

1) Langage de requêtage intuitif

Tout naturellement, lorsqu’on essaye un système de stockage, nos premiers essais se tournent vers l’insertion et la récupération de données. Pour l’insertion, nous venons de voir qu’elle s’effectuait au format BSon. Concretement, après avoir lancé le shell MongoDB, la commande suivante effectuerait une insertion dans une collection  »test » :

db.test.insert({ »name »: « Adrien »});

Et pour requêter nos collections, cela s’effectue également tout naturellement au format BSon ! MongoDB fournit un certain nombre d’opérateurs classiques : >, <, =, >=, IN, NOT IN, etc. Quelques exemples :

# Tous les utilisateurs "toto"
db.test.find({"name": "toto"});

# Les 3 premiers "Adrien", ayant plus de 23 ans, triés
db.test.find({"name": "Adrien", "age": {$gt: 23}}.sort({"age": -1}).limit(3);

C’est en général le premier point qui ressort de MongoDB par rapport à la plupart de ses rivaux. Son système de requêtage séduisant permet une prise en main extrémement rapide.

2) Auto-sharding

Venons en maintenant à ce qui fait normalement tout l’attrait des NoSQL : leur forte extensibilité et leur mécanisme de réplication. MongoDB offre des possibilités de sharding (partitionnement) afin de distribuer les données au sein de plusieurs  »shards » (bloc venant constituer le cluster, et ne possédant qu’une partie des données). L’auto-sharding reste aujourd’hui (version 1.5.3) en version beta, mais il est possible tout de même de spécifier ses propres pattern de sharding. Par exemple, on peut décider que le champs « name » de nos exemple deviendra une clé de sharding. Il est possible, à l’instar des indexes, de spécifier des clés composées de plusieurs champs. MongoDB calculera un hash de ces clés pour déterminer sur quel shard envoyer tel ou tel document. La configuration du cluster et toutes ses méta-données sont stockées au sein de « serveurs de configuration ». En production, trois serveurs de ce type sont normalement configurés. Si un de ces serveurs tombe en rade, le système continue de fonctionner normalement. Si deux de ces 3 serveurs montrent un dysfonctionnement, le dernier serveur de configuration devient accessible en lecture seulement. Ceci n’empêche pas le cluster complet de fonctionner, mais empêche toute modification de la configuration, et tout déplacement de « chunks » (position des blocs de données, qui est elle aussi stockée dans ces serveurs de configuration).

3) Replica pair, replica sets

Chaque shard peut actuellement être redondé par ce qu’on appelle un système de  »replica pair » : le shard est constitué d’un master et d’un slave. À tout moment, si le master tombe en panne, le slave prend le relai. Les données peuvent être répliquées instantanément ou avec une certaines latence dans le cas d’un système dit « finalement consistant ». Cette paire est bien limitée actuellement en matière de fail-over et laissera place aux « replica sets » avec MongoDB 1.6, qui laissera la possibilité de plus de 2 serveurs de sauvegarde. Dans cette nouvelle situation, en cas de panne du master, l’élection du slave qui deviendra master se fera par la résolution d’un consensus basé sur la disponibilité de chaque noeud, le nombre de serveurs vus par chacun, etc…

4) Map/Reduce

L’algorithme Map/Reduce a le vent en poupe depuis les papiers Google et l’implémentation Hadoop. Et devinez quoi ? MongoDB, à l’instar de CouchDB, offre des possibilités d’interrogation en Map/Reduce. Dans un environnement « shardé », les requêtes sont en effet ciblées ou globales (parallèles ou séquentielles). Pour effecter un certain nombre de calculs efficacement, MongoDB permet l’écriture de fonctions map() et  reduce() – et finalize() – en javascript. Les résultats peuvent être stockées dans des collections temporaires pour conserver un cache des résultats.

5) Autres fonctionnalités

En fait, il y a trop de choses à raconter sur MongoDB. Je vais faire un bon petit lot de petits articles pour détailler chaque point, mais pour ce soir, il faudra se contenter d’une découverte rapide :

• Un moteur d’indexation géographique, que Foursquare utilise à outrance
• Une indexation en background
• Des capped-collections, collections de tailles fixes auto-gérées pour ne conserver que les X derniers éléments insérés (fonctionnement par TTL prévu pour les futures versions)
• Profiling des requêtes
• Interface REST

Conclusion

MongoDB est la solution qui actuellement suscite le plus ma curiosité, et surtout mon intérêt, tant pour ses performances que pour sa conception et ses fonctionnalités. Son plus gros défaut actuel est sa grande jeunesse. Gageons qu’une fois l’auto-sharding et les replica-sets 100% fonctionnels, 10 Gen Confluence arrivera à mettre en place une architecture composée de 1000 shards, son objectif actuel.

• Les NoSQL (Cassandra, HBase, MongoDB…)
• Parallèlement, les systèmes distribués (Hadoop, Gearman…)
• MariaDB
• Les produits Talend
• Les outils de qualité logicielle open-source (Hudson, PHP Under Control…)
• Le framework symfony, toujours et encore

Comme l’objectif de Ze-Technology n’a jamais été d’écrire des articles superficiels et sans intérêt, je souhaite avoir un minimum de recul sur chacune de ces technologies avant de pouvoir écrire quoi que ce soit d’intéressant (ou d’inintéressant, vous en jugerez !). Je tombe bien chaque jour sur des dizaines de liens tous plus passionnants les uns que les autres, mais ce blog ne peut se résoudre à devenir une simple liste de liens. Cher public, vous qui m’aimez, la  caisse attend votre générosité un peu de patience…

Bien connu des développeurs Java, Ant est un build-system, à l’instar des Makefiles, permettant d’automatiser le déploiement d’un projet. Bon nombre de projets PHP ne sont en effet pas directement utilisables tout de suite après récupération des sources, et/ou nécessitent un certain nombre d’adaptation en fonction du serveur sur lequel le projet est déployé. Voire même, parfois, certaines tâches de maintenances assez rébarbatives pourraient être automatisées.

Je ne connais même pas Ant !

Pour ceux qui ne connaissent pas du tout Ant (et je ne parle pas d’un diminutif d’Antoine…), les rouages tournent concrètement grâce à un fichier XML classiquement nommé « build.xml », comprenant une succession de balises du style :

<target name="NOM_REGLE" depends="REGLES À EFFECTUER AUPARAVANT">
     <actions à effectuer ... />
</target>

Une fois ce fichier XML dûment rempli, vos règles s’exécutent par le biais d’une ligne de commande, après bien entendu avoir vérifié qu’Ant était bien installé sur votre machine :
> ant NOM_REGLE

Il y a un certain nombre d’options disponibles, il est par exemple possible d’afficher les règles disponibles et leur rôle respectif via ant -p pour peu que vous ayez renseigné un champ « description » dans le fichier build.xml.

Bon, et pour mon projet, ça sert à quoi ?

Vous manquez d’imagination ? Voici à titre d’exemple la liste de règles que j’ai définie pour Piwam :

• init: Créer les répertoires manquants (log, cache, build…
• cc: Vider le cache
• doc: Générer la documentation Doxygen
• up: Update SVN
• phpcpd: Cherche le code PHP dupliqué au sein du projet
• pdepend: Génère un rapport de dépendance des classes
• phpcs: Vérifie la conformité du code avec une norme donnée
• lint: Vérifie qu’aucun fichier ne contient une erreur de syntaxe
• test: Lance les tests unitaires et fonctionnels
• css: Concatène l’ensemble des fichiers CSS en un seul grand fichier CSS
• css.min: Minimise la taille du gros fichier CSS. (appelle automatiquement la règle css en amont)
• clear: Nettoie les fichiers générés
• build: Lance l’ensemble des tâches permettant de vérifier la qualité du projet

je vous invite à découvrir le fichier XML correspondant sur le dépôt SVN du projet. Ce fichier vous permet alors d’effectuer toute une batterie d’actions de manière extrêmement simplifiée. Ant est utilisé au sein d’une multitude d’outils du monde Java, des IDE (Eclipse…) aux outils d’intégration (Hudson, CruiseControl…). En pratique, ces outils vont aller lire votre fichier build.xml et appeler les commandes correspondant aux tests (dans mon cas : phpcs, pdepend, etc.) de manière 100% automatisée afin de vous permettre de suivre l’évolution de votre projet au fil des révisions.
Sur ce, je vous laisse rédiger votre propre antfile, en attendant de vous présenter comment l’exploiter au sein d’Hudson dans un projet article !

Liens utiles

• http://ant.apache.org : Site officiel de Ant, par la fondation Apache
• http://phing.info : Alternative à Ant spécialement conçue pour les outils PHP. (Basée sur Ant)
• http://hudson-ci.org : Hudson, outil d’intégration continue

Il y a eu toutes sortes d’expériences autour du réseau social qui fait tant parler de lui. Je vous en propose une nouvelle. Mon but était d’établir un état des lieux des comportements des utilisateurs envers une demande d’ami inconnu. Le procédé fût fort simple : la première étape fût la création d’un compte d’un personnage complètement fictif et inconnu, qu’on appellera Jean-Claude. Suite à ça, ce sont quelques 250 personnes qui ont été sollicitées pour faire partie du réseau d’amis. 250 personnes de toutes origines, tous pays, sélectionnées complètement aléatoirement.

Une semaine plus tard, les résultats sont là. Il y a déjà 119 personnes qui se sont déclarées ami(e)s avec mon Jean-Claude. Sur ces 119 individus, seulement 6 ont envoyé un message pour connaître mon identité. Après avoir répondu, 2 m’ont retiré de leur liste d’amis. Jean-Claude aurait donc 113 personnes qui le connaissent vraiment ? En tout cas, Jean-Claude a accès à toutes les informations de ses amis : photos, statuts, quizz, etc.

Des conséquences qu’à titre personnel, je considère désastreuses. Ok, je ne suis pas mal intentionné. Mais qu’en savent ces « amis » ? De même, rien ne semble m’empêcher de dresser une liste d’habitudes, de comportements. Ces problèmes de confidentialité ne sont pas nouveaux, je ne vais les déballer ici, mais ce qui m’intrigue surtout au plus haut point, c’est cette facilité déconcertante de rentrer dans le cercle de connaissances de n’importe qui. Une sensibilisation des utilisateurs ne ferait de mal à personne…

Un code de la route version DBA. Le maillon faible puissance 10 000. Voyez ça comme vous voulez, « MySQL Question Of The Day » est un sympathique site qui vous permettra de tester vos connaissances et d’apprendre en tentant de répondre chaque jour à une nouvelle question. Bref, à suivre ! http://mysql-qotd.casperia.net

Cette semaine, c’est un lien pour tout le monde ! Au diable la technologie, au diable l’innovation, nous n’avons que faire du business, place à l’humour ! J’ai récemment découvert pas le biais de ma dulcinée la « BD de Maé« , signée Pacco.

En quelques phylactères, Pacco retrace sa vie avec sa fille Maé, insupportable au possible. Deux tomes ont d’ailleurs été édité en chouette BD papier, disponibles chez les libraires habituels. Un petit aperçu avec un récent épisode qui fera sourire tout geek qui se reconnaît : ici. N’hésitez pas donc pas à suivre dès maintenant cette agréable aventure : http://www.mae-bd.fr

Certains d’entre vous ont peut être entendu parler d’ »Hyper PHP ». Le nom du projet est apparemment « HipHop ». Il s’agit là du compilateur complètement customisé par Facebook, pour ses propres besoins liés à la scalabilité et la montée en charge.

Ce compilateur réécrit le code PHP en C++, puis le  compile avec le bien connu compilateur G++. Chez Facebook, ils nous font part d’un gain de 50% en terme d’utilisation du CPU.

Utilisé en production depuis 2 ans mais présenté seulement aujourd’hui à la communauté, le projet HipHop est d’ores et déjà disponible, n’hésitez pas à l’essayer

Vous avez récemment découvert mon histoire d’un curieux recrutement. J’y montrais alors une portion de code PHP exemptée de bonne pratique et fourmillant d’erreurs. This might sound more complicated than playing online casino (http://www.casino.com/fr/) at first but you will soon get your head around it. Voici donc la « correction » que je vous propose, recensant les points que j’aurais aimé voir soulevés par les candidats :

1. Le tag <?php dans sa version courte
2. Un code intégralement en français.
3. Pas de commentaires multi-lignes en entête de fonction
4. Pas de tags pour la génération de documentation (phpDoc, Doxygen…)
5. Pas de typage pour le paramètre $voiture (en tant qu’objet, autant bénéficier du typage apporté par PHP)
6. Commentaires inutiles dans le code (lignes 8 et 13)
7. Mauvaise indentation
8. Problème de type pour $max
9. If/else à problème
10. L’opérateur de comparaison pourrait être poussé à « ===« 
11. Lorsque que $max vaut « inconnu », on pourrait préférer une constante
12. Pas d’utilisation d’ORM, utilisation de mysql_query natif
13. Requête SQL peu lisible (mots clés en minuscules, une seule ligne…)
14. Problèmes dans la requête SQL (guillemets mal placés, le SET est après le WHERE)
15. Pas de protection de la requête
16. return est un mot clé, pas une fonction : on devrait omettre les parenthèses.
17. Il vaut mieux éviter d’insérer les tags de fermeture PHP
18. Vu ce que fait la fonction, ça serait sûrement mieux d’en faire une méthode au sein de la classe (mais l’analyse de ce que fait la fonction n’était pas demandé)

Bravo à tous ceux qui avaient farfouillé ! Sans forcément trouver exactement tous ces points, il était sûrement aisé d’en identifier au moins 4 ou 5. Attention, ce ne sont pas forcément des erreurs, mais des points qui pourraient être discutés (les commentaires pourraient très bien être en français pour telle ou telle raison, par exemple)

J’ai récemment effectué une session de recrutement de 3 élèves pour un organisme de formation. Ce dernier souhaitait développer et mettre en place un intranet capable de gérer les notes des étudiants et des emplois du temps. Laissez moi conter dans les colonnes de ZT les questions et points abordés, et les retours obtenus.

Premier contact entre le candidat et le recruteur : le CV. Bien que corrects, ils comportaient quelques perles. Pour commencer, une utilisation assez litigieuse du terme « ingénieur », pour une école qui ne propose absolument pas des formations et des diplômes d’ingénieurs. Je retiendrai aussi l’approximation suivante :

Base de données : Oracle (MySQI, Pl/SQL certifié 1Z0-007)

Étrange utilisation des parenthèses, n’est-ce pas ?

Question 1 : le jeu des 15 erreurs

Passons ensuite aux questions techniques. Je commence par fournir un code hideux, écrit par mes soins, tant au niveau du comportement de la fonction que du code en lui même. Je demande alors au candidat de me trouver un maximum de choses qui ne vont pas, qu’on pourrait changer, qu’il ne faudrait pas faire, dont on pourrait discuter. L’objectif n’est pas tant de trouver TOUS les écarts, mais au moins de montrer ce à quoi on accorde de l’importance. Voici le code en question, admirez plutôt :

<?

// fonction qui calcule la vitesse maximale
// en fonction du type de la voiture passé en paramètre

function calcul_vitesse_maximale($voiture)
{
   // si le type est "sport"
   if ($voiture->getType() == "sport") {
     $max = 230;
      }

   // si le type vaut "1980"
   if ($voiture->getType() == "1980") {
     $max = "120";
   }
   else
   {
     $max = "inconnu";
   }

   mysql_query("update from voitures where id="$voiture->getId" set max=$max);
   return($max);
}
?>

Je considère qu’il y a facilement 15 « erreurs », ou au moins points à discuter. Certains sont carrément des gorritudes. Je vous invite à essayer de touver un maximum de choses par le biais des commentaires, je laisserai la solution dans un prochain billet.

Et bien, quelle ne fût pas ma surprise de découvrir que les candidats avaient un mal fou à trouver ne serait-ce qu’un seul point discutable. À l’exception d’un candidat, qui paradoxalement avait beaucoup moins de pratique que les autres (pour ne pas dire presque aucune), qui a tout de même remonté 3 points importants. Inquiétant, pour des élèves « ingénieurs » et développeurs en Bac+4. La réponse la plus surprenante ? La voici : « Oh vous savez, j’ai l’habitude de travailler sur du code bien plus laid que ça ! »

Question 2 : Simulateur de grand mère

L’organise recruteur ne possède absolument aucune connaissance technique. J’étais donc à la recherche d’un stagiaire capable de vulgariser au mieux les termes, questions et démarches techniques. Je demande donc aux candidats de m’expliquer un mot technique comme si j’étais leur grand-mère. Voici un extrait de conversation type :

- Pouvez-vous m’expliquer le mot « framework » ?
- Hum.. un quoi ?
- Un framework. Comme Zend, symfony, ou Struts
- Jamais entendu parler…
- Bon.. peut-être pouvez-vous m’expliquer ce qu’est un design pattern ?
- Ha.. ça me dit quelque chose, mais en mathématiques…
- Un ORM alors peut être ?
- …

Et je vous jure que je n’exagère pas du tout. Pas évident de faire un exercice de vulgarisation dans ces conditions… Du coup, j’ai laissé de côté mes autres questions :

1. Vous utilisez un système de versionning ?
2. Vous pourriez m’écrire la fonction factorielle en récursif ? en itératif ? (Amaury si tu passes par là…)
3. Quels types d’attaques connaissez-vous ?
4. Vous aimez le Nutella ?

Le but de ce billet était bien évidemment de montrer comment une école qui prétend au titre d’école d’ingénieur en informatique peut envoyer des étudiants avec peu de background technique pour un stage en Bac +4. Ces étudiants avaient bien entendu d’autres qualités qui leurs sont propres : bon relationnel, bonne gestion de projet, pour ne citer que les principales. La solution de l’exercice1 au prochain billet !