Le blog est mort, vive le blog ! En fait, je ne sais pas ce qu’il adviendra de CE blog. Autant j’ai énormément de sujets à aborder, autant je peine à développer des articles que je considère « intéressants ».
Face à cette variété de sujets, j’ai décidé de créer Born to Segfault, un blog 1) en anglais 2) qui ne parlera pas de 10000 choses différences 3) qui essaiera autant que possible de balancer du contenu intéressant.
Bref, à vos bookmarks,
Auparavant, je maintenais un blog entièrement dédié à la photographie et à mes projets. Dorénavant je rédigerai avec parcimonie quelques expériences ou retours d’expériences photographiques ici même. Un peu d’art et d’art numérique dans ce monde très binaire, ça ne peut pas faire de mal.
Equipé depuis plusieurs années d’un réflexe, force est de constater qu’il m’était impossible d’emporter ce dernier partout avec moi. Quand bien même je suis un adepte de la focale fixe, notamment mon 28mm très peu encombrant, on sacrifie la compacité pour jouir d’une qualité et réactivité accrue. Réalisant que je « manquais » beaucoup trop de photos juste parce que je n’avais pas le bon outil au bon moment, j’ai décidé de trouver mon compagnon photographique idéal.
Aux premières annonces du Fujifilm X100 — le grand frère du X10 — je sentais le vent tourner. Enfin un retour aux fondamentaux de la photographie ! De beaux boitiers, bien construits, avec des modes manuels. Quand Fujifilm a continué sur sa lancée pour sortir le X10, j’étais conquis. Présentation rapide, pour les non initiés : il s’agit d’un compact haut de gamme, qui a pour lui un viseur optique exceptionnellement clair et large, un capteur d’excellente facture qui, bien que plus petit que les réflex se montre 2 fois plus grand que ses concurrents, et propose de maîtriser le zoom manuellement, comme sur un objectif de réflex. Avec toutes ces spécifications, le Fujifilm X10 ne tient certes pas dans une poche, mais se trimballe facilement n’importe où.
Les spécifications papier, c’est bien, mais à quel point suis-je séduit en pratique ? Mes premières craintes se portaient sur l’utilisation du viseur optique. Me voilà bien obligé de reconnaître que ce dernier est largement utilisable. Il n’y a certes pas de correction des problèmes de parallaxe, et aucune information n’est affichée en surimpression, mais sur des plans larges et des sujets éloignés, on peut parfaitement lui faire confiance. Et quel confort d’en profiter ! Pour des sujets rapprochés, si on commence à s’approcher des 112mm que couvre le zoom, le défaut de parallaxe est bien présent et il faut s’y accoutumer, avec un peu de pratique.
Le second critère décisif pour moi était la réactivité de l’appareil. J’étais prêt à sacrifier une partie de la qualité des réflex (je ne suis pas un adepte des images parfaites au piqué absolu), mais certainement pas la réactivité ! Là encore, je suis tout sauf dérouté. L’autofocus se montre faste comme peu d’autres, et le déclenchement franchement réactif. A confirmer, mais je devrais pouvoir faire sans soucis de la photo de rue ou évènementiel avec un tel compact.
Bien évidemment, cela ne fait que quelques semaines que je vagabonde avec mon X10. Le temps me dira si cet appareil est robuste et aussi fiable qu’il en a l’air. Gageons que dans le pire des cas, la marque ait démontré qu’il y a une véritable attente autour de ce créneau.
Lien : Site officiel Fujifilm X10
Cher lectorat, bonjour.
Alors que l’on parle plus que jamais de casino en ligne, de paris sportif, poker ou des fameux « bonus » de casino sans dépôt, l’été dernier a été pour moi l’occasion de retourner de l’autre côté de la barrière. L’occasion de collaborer à nouveau avec mon ancien (excellent) employeur en matière de gambling. La mission qui m’était confiée était la suivante : partager mes expériences en matière de QA pour les projets PHP, et sensibiliser/développer tout un lot de bonnes pratiques auprès de l’équipe technique en place.
Pour formaliser un peu le périmètre, ces 2 mois devaient permettre de dérouler un état de l’art des tests unitaires, fonctionnels, de performances, sur l’intégration continue et les bonnes pratiques de développement « modernes » appliquées au PHP.
Ma plus grosse crainte était résolument celle de voir ces pratiques rejetées, jugées « inutiles », ou « trop lourdes » à appliquer au quotidien. Je savais que j’avais alors 2 mois pour démontrer tout l’intérêt de ces pratiques, pour prouver que les métriques de phpcs, phpcpd ou phpunit étaient bien plus que des simples chiffres.
Mon approche fût la suivante : adapter chaque point au cas précis des développeurs de l’entreprise, et les impliquer le plus tôt possible dans un processus « d’auto-formation », pour assurer une pérennité à la politique qualité, une fois ces 2 mois – à mi temps – terminés. Craignant des rejets du type : « les tests, c’est pas pour nous ! », je me suis efforcé de résoudre TOUS les problèmes qui pourraient m’être posé. L’exemple le plus concret concerne un refactoring de classes PHP. L’une d’entre elle mélangeait logique métier, logique d’accès aux données, logique utilisateur… L’argument avancé était que le code devait être comme cela, que ça avait été pensé et que finalement, ça marchait très bien.
Sans forcément rejeter cette idée (après tout, un code qui marche, c’est déjà beaucoup de nos jours !) j’ai accordé le temps qu’il fallait au problème en décortiquant chaque ligne. Après avoir expliqué ma méthodologie (qui en est une à peu près standard parmi tant d’autres), on obtenait un code iso-fonctionnel, mais :
Je pense que cet exemple concret a été le déclencheur sur la prise de conscience de la part de l’équipe. L’exemple qui a montré que le changement n’est pas impossible, et, mieux encore, peut être pas si coûteux que ça en temps s’il est fait rigoureusement.
Une fois la théorie abordée et l’exemple donné, j’avais dédié une partie à la « pratique » collaborative. Les mains dans le cambouis, comme on dit. Des micro-tâches étaient assignées entre les différents développeurs, afin qu’ils s’approprient les outils et différents outils, et intégrer les bons réflexes. Ajout d’une nouvelle métrique à Hudson, modification d’un test unitaire, relecture du code d’autrui, consultation de la documentation… Autant de minutes dépensées à bon escient.
J’ai oublié de vous dire : c’était ma première vraie expérience en « formation ». Je ne peux me targuer d’avoir 10 ans d’expérience en QA ou en pédagogie, mon but était d’apporter mon regard et de partager ce que je savais. Le pari est apparemment réussi. Les 2 points clés (exemple concret autour des besoins réels et implication des acteurs) ont l’air d’avoir porté leurs fruits. La plate-forme d’intégration continue fonctionne… en continue. Voilà 2 mois bien rentabilisés !
C’est une nouvelle (?) que vient d’annoncer Sebastian Bergmann. Suite aux remarques de la communauté, il n’y aura pas moins de $this dans vos tests unitaires.
Pour rappel, Sebastian avait eu pas mal de plaintes d’utilisateurs réclamant la disparition du $this pour effectuer les différentes assertions.
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.
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.
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 :
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é.
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.
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.
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).
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…
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.
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 :
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.
Non, c’est vrai ! Et en guise d’excuse, je ne peux pas dire que ce sont les sujets qui manquent ! En fait, il y a plein de raisons à la passivité actuelle de ce blog. La première, c’est le travail ; mais ça, c’est pas une excuse, tous les blogueurs ont un travail (pour les plus chanceux). La deuxième, la vraie, c’est que je me passionne en ce moment pour un tas de sujets, sûrement les sujets phares de 2010 :
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…
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…
Comment augmenter sa productivité ? Celle de ses employés ? C’est une question à laquelle un peu tout le monde s’attache ou du moins peut s’attacher. Il y a des pistes purement organisationnelles (méthodologie – Scrum a le vent en poupe -, hiérarchie dans l’entreprise, workflow général…) mais un certain nombre de petites choses peuvent venir agrémenter le quotidien d’un travailleur. D’un point de vue très général, j’identifierai :
Autant de modifications qui peuvent paraître extrêmement anodines mais qui tiennent constamment l’esprit en alerte. Sans jouer au neurologue expert, le cerveau identifie inconsciemment un changement et relance l’attention, la créativité. En dehors de ces dispositions inhérentes au poste de travail, on peut s’attaquer à l’outil de travail en lui même. En prenant le cas – fréquent – d’un intranet fréquemment consulté par les employés, on pourrait ainsi imaginer un changement, global ou mineur, de l’apparence de cet intranet.
Effectuer des changements sur un outil de travail est un art qui s’il est manié sans précaution peut très vite venir semer la zizanie. Un bouton déplacé, un champ qui n’apparaît que dans certaines conditions, des menus ré-organisés… voilà de bien bonnes manières de diviser par 2 la productivité !
Bien que des choses comme ITIL existent pour aider à mener à bien ce genre de changement, je ne souhaitais évoquer ici que les modifications purement visuelles, sans engendrer un seul impact fonctionnel. Changer les couleurs du bandeau principal, mettre un fond aux couleurs de noël ou d’halloween, faire jaillir de l’écran une photo « volée » qu’un employé souhaitait partager (attention aux dérives !) autant de petites modifications qui peuvent venir casser le train-train des employés manipulant constamment l’outil et se lassant du jeu de couleur bleu et blanc. À condition, bien sûr, d’avoir un outil un tant soi peu personnalisable.
Encore une fois, c’est une question qui obtient une réponse au cas par cas. Il y aura certains employés qui souhaiteront qu’une habitude ne soit JAMAIS cassée (jamais de musique, ne jamais changer de poste de travail, etc.) et qui ne manqueraient pas de vous le faire savoir, j’en suis certain. Ce billet n’est qu’une réflexion personnelle après une petite analyse introspective de mon comportement, corrélée avec une observation effectuée sur l’ensemble de la population estudiantine comme professionnelle que je peux côtoyer jour après jour.
Il y a les perles du Bac, voici les perles de la démonstration de Piwam. La version de démo disponible en ligne a en effet déchaîné le sens de l’humour des joyeux testeurs. Je vous propose ce qu’on appellerait un « best-of » des idées qui m’ont fait sourire.
Un titre bien accrocheur pour en fait vous suggérer l’idée que oui, Ze-Technology.com est bien en vacances. Comme vous avez pu le constater, plus de « lien de la semaine », plus de billet plein de bonne technologie, plus de scoops.
Mais qui dit vacances dit retour, et dès la rentrée, c’est partie pour…
Mais en attendant tout cela… je vous souhaite de bonnes vacances.
Abonnement Fil RSS