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 :
- Le tag <?php dans sa version courte
- Un code intégralement en français.
- Pas de commentaires multi-lignes en entête de fonction
- Pas de tags pour la génération de documentation (phpDoc, Doxygen…)
- Pas de typage pour le paramètre $voiture (en tant qu’objet, autant bénéficier du typage apporté par PHP)
- Commentaires inutiles dans le code (lignes 8 et 13)
- Mauvaise indentation
- Problème de type pour $max
- If/else à problème
- L’opérateur de comparaison pourrait être poussé à « ===«
- Lorsque que $max vaut « inconnu », on pourrait préférer une constante
- Pas d’utilisation d’ORM, utilisation de mysql_query natif
- Requête SQL peu lisible (mots clés en minuscules, une seule ligne…)
- Problèmes dans la requête SQL (guillemets mal placés, le SET est après le WHERE)
- Pas de protection de la requête
- return est un mot clé, pas une fonction : on devrait omettre les parenthèses.
- Il vaut mieux éviter d’insérer les tags de fermeture PHP
- 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)
Abonnement Fil RSS