date('Y-m', strtotime('2008-02')) = '2008-03'
mercredi 31 décembre 2008 à 11:28 (Julien Tartarin)
Ça peut paraître incroyable mais pourtant c'est vrai :
date('Y-m', strtotime('2008-02')) = '2008-03'
Du moins, les 29 (sauf si l'année est bissextile), 30 et 31 de chaque mois. Il semblerait que strtotime remplace l'absence de numéro de jour par la date du jour courant. En ce qui me concerne, je m'attendais plutôt à ce qu'il considère ça comme le jour 0, jour 1 au pire.
La même règle est valable pour les mois à 30 jours parsés un 31...
Comment réussir son changement de serveur sans prise de tête
samedi 12 juillet 2008 à 21:54 (Julien Tartarin)
Déplacer un site entier d'un serveur (ou hébergeur) à un autre n'est pas toujours chose aisée, surtout quand il s'agit d'un site dynamique et actif.
Beaucoup ignorent le fonctionnement de la propagation des zones DNS (et des TTLs ou durées de vie). L'erreur numéro 1 à ne surtout pas commettre est de changer les serveurs DNS, leur pointage et le serveur en même temps. L'erreur est fréquente et conduit au mieux à des sites "parallèles" : deux versions à gérer, et des interactions aléatoires avec les utilisateurs. Au pire : le site disparaît, les mails n'arrivent plus et le monde s'écroule.
J'ai récemment vu plusieurs fois ce genre d'annonce de service :
Bon allez, c’est parti, la copie du blog est en place sur le nouveau serveur et la base remontée, je modifie le DNS et la propagation devra se faire dans les 24, 48h. Demain [le blog] aura donc changé de serveur si tout est Ok. [...]
Les éventuels commentaires postés sur l’ancien serveur pendant la période de migration ne seront pas présent sur le nouveau serveur. Ce post ne sera pas visible non plus sur le nouveau serveur.
(bold ajouté par mes soins)
Même si prévenir ses utilisateurs, lecteurs et clients est une bonne chose, je trouve dommage de s'avouer si vite vaincu par un outil technique inconnu. Et de leur faire subir, également.
Voici quelques exemples de migrations mal planifiées malgré une certaine notoriété des sites et/ou de leur responsable :
- Jeremie Berrebi change son blog de serveur : ... Bon, c'est pas trop grave, seulement quelques commentaires perdus. Le contenu était toujours accessible (en dehors des nouveaux articles bien sûr)
- Eric Dupin déménage Fuzz, domaine, DNS et serveur en même temps. Résultat : plus de 72 heures de downtime... Et autant de frustration pour les utilisateurs de ce service web.
- Mathilde décide de déménager Bagatelles.fr : catastrophe ! Outre l'indisponibilité du site, l'export se passe mal (visiblement un problème d'encodage), mais surtout pendant plusieurs jours, pas de commande ni d'email... Dans le e-commerce, non seulement la perte est quantifiable, mais c'est aussi le sérieux, l'image et la confiance de l'enseigne qui est remise en cause.
Heureusement, tous les déménagements de serveur ne se passent pas aussi mal et tout un chacun (un minimum réceptif à la technique) peut parvenir à déplacer son site sans problème et surtout sans le classique délai inexploitable de 24 à 48 heures... Il suffit de faire les choses dans le bon ordre !
Voilà ma procédure :
On suppose que :
- le domaine est configuré pour recevoir ses emails (MX) sur un serveur tiers (Google Apps, par exemple), le contraire étant pour moi une hérésie.
- on n'a pas de solution type "IP fail-over" permettant de basculer le routage d'une adresse IP instantanément (et annulant la problématique des DNS)
Y a-t-il transfert de domaine ?
OUI : S'il y a transfert du domaine d'un registrar à un autre, il faut prévoir au moins 2 à 4 semaines pour avoir la certitude que le transfert sera fait au bon moment. Pour un .com, c'est plus rapide, pour un .fr, ça peut être plus lent... La procédure varie selon l'extension du domaine et les registrars entrant et sortant, je ne la détaille donc pas plus. Attention toutefois à bien laisser les mêmes serveurs DNS que précédemment, sans quoi le domaine risque d'être "parké"...
NON : Rien à faire pour l'instant.
Y a-t-il changement de serveurs DNS ?
OUI : Il faut s'y prendre au moins une semaine à l'avance. Dans un premier temps, configurer la nouvelle zone à l'identique de l'ancienne. Seuls les champs SOA et NS diffèrent, puisqu'ils doivent contenir l'identité des nouveaux serveurs DNS. Ensuite, lancer la procédure au niveau du registrar. Il peut se passer plusieurs heures (habituellement entre 6 et 48 heures) avant que le changement soit bien pris en compte partout. Toutefois, même pendant la transition, le site est accessible et fonctionnel. Zéro coupure.
Note : S'il y a transfert de domaine ET changement de serveurs DNS, la procédure au niveau du registrar peut n'être effectuée que sur le nouveau registrar au moment du transfert, tant que les nouveaux serveurs DNS sont configurés correctement. D'une pierre deux coups, et toujours aucune coupure malgré une transition un peu longue.
NON : Rien à faire pour l'instant.
Étapes préliminaires
Le nouveau serveur
Il faut bien le faire à un moment, ça peut être fait bien avant les transferts de domaine et DNS, ou pendant, ou après.
Commander, installer, configurer, et tester le nouveau serveur (ou hébergement). Mais surtout, y installer une copie du site : si le site crée/supprime des fichiers (upload d'images/vidéos par exemple), on utilisera de préférence rsync. Si les fichiers sont statiques (comme un blog : aucun fichier n'est créé en dehors des images ajoutées aux billets), une copie pure et dure à coup de scp ou via FTP est également possible. rsync est nettement plus souple (ne copie que ce qui diffère) et rapide (liaison serveur à serveur vs serveur vers client vers serveur), mais ne peut pas toujours être utilisé (il faut un accès SSH et/ou un hébergeur sympa).
Y installer une copie de la base de données. Un réimport de backup à peu près à jour peut faire l'affaire. J'ai une commande magique et extrêmement rapide pour ça, mais c'est secret défense :) Ce qui compte, c'est que la structure SQL soit à jour, peu importe pour les données elles-mêmes.
Pour pouvoir tester correctement le nouveau site sur le nouveau serveur, la meilleure solution à mon goût est de modifier temporairement son fichier hosts (ce fichier permet de passer outre les serveurs DNS pour résoudre un nom en adresse IP) pour tester le site sur le nouveau serveur et ajuster les petis détails si besoin (un module oublié, une permission mal remise, etc.). L'emplacement du fichier dépend du système d'exploitation, mais Google a la réponse.
Cette étape de test permet un passage en production sans aucun problème.
Réduire les TTLs au niveau de la zone DNS
Malgré des acronymes barbares, les TTLs (pour Time To Live) sont de précieux alliés s'ils sont bien utilisés, mais sont aussi la cause de tous les problèmes cités plus haut quand ils ne sont pas compris et maîtrisés. La propagation, ennemie jurée ? Je dirais plutôt amie incomprise...
Une fois les transferts administratifs effectués et effectifs (soit minimum 48h après l'application du changement de serveurs DNS et au moins autant après la notification de fin de changement de registrar), il faut donc réduire les TTLs. La procédure change du tout au tout selon l'entité qui gère les DNS : interface d'administration ou fichier de configuration... Le principe reste le même : il faut que chaque enregistrement dans la zone expire le plus vite possible. Par défaut, la valeur est souvent de 86400 secondes (24 heures). Je recommande une valeur de 5 minutes maximum (300 secondes), 1 minute si possible (60 secondes). Il ne faut surtout pas modifier le pointage des enregistrements pour l'instant.
Cela aura pour effet de rendre les prochains changements rapides, et de réduire la période de propagation à quelques minutes... Et pour l'instant toujours rien de visible par les utilisateurs, lecteurs et clients.
Transfert des données
Quand toutes les étapes précédentes sont terminées et vérifiées, on peut passer au transfert réel des données.
Afin de conserver l'intégrité des données, il convient de passer l'ancien site en lecture seule, sans quoi des évènements aléatoires peuvent se produire. Il faut ensuite mettre à jour les fichiers (rsync ou FTP) et la base de données. C'est pendant cette étape que la migration apparaît aux utilisateurs, puisqu'ils ne peuvent plus intéragir. Dans certains cas (média), cela peut tout à fait passer inaperçu. La durée de la copie est variable et dépend directement de la taille du site.
Une fois le transfert effectué, vérifier (toujours grâce au fichier hosts) une dernière fois que le nouveau site est en état, puis changer le pointage DNS sans modifier les TTLs (au cas où un problème survient, le retour en arrière doit rester possible rapidement). Le changement sera propagé en quelques minutes seulement (penser à retirer la ligne du fichier hosts pour confirmer...), le nouveau site est en production.
Finalisation
S'il n'y a toujours pas de problème après quelques minutes ou heures, il faut remettre les choses en mode croisière : remettre des TTLs longs (1 jour / 86400 secondes), lancer une première backup sur le nouveau serveur et récupérer (et conserver) la dernière backup de l'ancien serveur.
Conclusion
Zéro coupure, zéro bizarrerie, seulement un passage en lecture seule de quelques minutes (durée égale au temps de la mise à jour des données).
Tout ça parce que la transition a été planifiée, surtout pas précipitée, et que les choses ont été faites dans l'ordre.
Une ville dans la ville : Linked Hybrid
mardi 5 février 2008 à 11:46 (Julien Tartarin)
Certains se souviendront de mes délires futuristes d'immeubles gigantesques où il n'y aurait plus besoin de sortir de chez soi, les chinois l'ont fait !
Huit tours reliées entre elles au 20ème étage par des grands couloirs aériens, 750 appartements de luxe, une capacité de 2 500 habitants qui n'ont besoin de sortir de chez eux que pour travailler. C'est écologique : recyclage de l'eau et énergie géothermique. Et c'est organisé de façon a rester aussi aléatoire qu'une vraie ville, histoire de ne pas se désociabiliser. Et ce n'est pas qu'une idée folle puisque le Linked Hybrid est déjà en construction à Pékin et est prévu pour 2008 !
J'espère que ça arrivera vite par chez nous, je trouve ce concept absolument génial, il ne restera qu'à l'associer à un programme de "courses automatiques" livrées à domicile (à frigo, tant qu'à faire) et inventer l'écran à joli paysage de The Island, pour ne pas déprimer les habitants des appartements qui ont une mauvaise vue/exposition.
Via Wired.
Gmail for your Domain : augmentation de l'espace disque !
mercredi 10 octobre 2007 à 18:26 (Julien Tartarin)
Tout est dans le titre !
Gmail (version Google Apps) rejoint son homologue au niveau de l'espace disque : 2910 Mo 3714 Mo de stockage disponible par compte à la place des 2048 Mo précédents :)
De quoi convertir les derniers frileux ?
Mysqldump + InnoDB + grosse table
vendredi 27 juillet 2007 à 16:17 (Julien Tartarin)
Pour dumper une grosse table InnoDB (manipulation inutile en MyISAM) malgré de nombreux accès clients simultanés, sans perte de performances, il ne faut surtout pas utiliser l'option --opt de mysqldump qui ajoutera un verrou sur la table et mettra en attente toutes les requêtes secondaires pendant toute la durée du dump, qui peut atteindre plusieurs minutes ou dizaines de minutes selon les cas...
Au lieu de ça, le plus efficace est d'ajouter les options suivantes :
--extended-insertou-e: le résultat du dump sera optimisé avec des insert multiples : moins de texte brut et plus de performances lors de la récupération des données--quickou-q: pour ne pas utiliser de buffer lors de la lecture des tables (le cas contraire saturerait la RAM en quelques secondes)--single-transaction: le plus important, ou presque, qui permettra de ne lire que l'état de la table au début du dump, malgré les modifications qu'elle peut continuer à accepter.
Le reste des options, hormis --opt et --lock-tables, est variable et à la convenance de l'utilisateur.
Rediriger le flux STDOUT directement vers gzip ou bzip2 permet d'économiser un espace non négligeable sur le disque : pour une table de 160 Mo une fois dumpée, 13 Mo après le passage de bzip2, ça fait mal !
Conclusion : mysqldump -q -e --single-transaction base | bzip2 -c > base.sql.bz2
Je reprends la lecture
mardi 19 juin 2007 à 20:10 (Julien Tartarin)
Lecture de geek, of course.
J'ai (re)commencé en dévorant "Concevoir et lancer un projet : de l'idée au succès" de Raphaël Cohen, repéré sur TechCrunch, qui décrit le modèle IpOp (l'Innovation par les Opportunités).
L'idée est de ne pas tout baser sur un business plan, mais plutôt sur un opportunity case : il y a un besoin non satisfait, voici comment je peux y répondre
. (C'est d'après moi bien plus agréable et réaliste que : je compte drainer 20 millions de visiteurs par mois, ce qui génèrera 2 millions d'euros avec les annonces AdSense
).
L'avantage de la démarche présentée ici est que la plupart des étapes permettent de déterminer si le projet est viable, si l'opportunité vaut la peine d'être saisie, si la motivation est suffisante, etc.
Je reprends aussi depuis quelques jours la lecture partielle et désordonnée de l'énormissime "Advanced PHP Programming: A Practical Guide to Developing Large-Scale Web Sites and Applications With PHP 5", à ne surtout pas confondre avec cet aperçu de la version papier de la documentation PHP qui porte très mal son nom... Je l'avais commandé sur Amazon il y a... plus d'un an et demi, mais je n'avais jamais pris le temps d'entrer dans les détails.
Les sujets abordés sont variés, il suffit de voir la table des matières pour s'en rendre compte :)
J'ai lu ce midi le chapitre "Data Component Caching" (mise en cache de données) qui explique en long, en large et en travers pourquoi il est très risqué de baser le cache sur des fichiers "normaux" dans un environnement multi-serveurs. Assez marrant de voir toutes les choses auxquelles je n'avais jamais pensé en implémentant certaines solutions de cache...
Je pense que la plupart des autres chapitres sont aussi passionnants que celui-là, en particulier tout ce qui concerne le scaling et la mise en place de distributed environments pour des applications PHP. Passionnants pour des développeurs PHP, bien sûr...
En bref, je recommande !
Google would like to converse with you
mercredi 6 juin 2007 à 21:05 (Julien Tartarin)
Reçu un mail il y a quelques jours :
From:je.dis.pas@google.com Subject: Google would like to converse with you
Première pensée, évidente : Oh, un spam !
Mais chose bizarre, comment Gmail pourrait laisser passer un spam se faisant passer pour Google ? Je vérifie donc les informations du mail. Les "détails" (c'est l'appellation des headers simplifiés dans Gmail) indiquent que le mail a été signé par Google.com.
Wow ! Je suis jaloux, je leur avais envoyé des dizaines de mails pour leur demander de supporter les signatures électroniques, ce qui par ailleurs n'est toujours pas le cas.
Intrigué, je vais carrément voir les headers complets, qui peuvent bien plus difficilement mentir... Le mail a été envoyé par un serveur *.corp.google.com, bon, c'est un vrai ! Maintenant je peux le lire :)
Son expéditrice, une chasseuse de têtes pour la Google Engineering Team, m'a "trouvé sur Internet" et souhaite en savoir plus sur moi. Elle cherche des gens ayant des connaissances approfondies en C, C++ et Java, langages que je suis très loin de maîtriser malgré quelques essais plus ou moins fructueux[1].
Bien évidemment, c'est un mail que je n'ignore pas, si demain je peux travailler chez Google à San Francisco, je dis oui... Qui pourrait refuser ça ?
J'ai donc répondu, raconté mes expériences, et obtenu un appel téléphonique. Pardon, un call[2]. Entretien téléphonique "confidentiel" avec un décalage horaire de neuf heures : tout d'abord une auto-évaluation dans quelques domaines techniques, de 0 à 10 :
- 0, aucune connaissance ;
- 1 à 3 : besoin d'un manuel à côté ;
- 4 à 6 : fluent ;
- 7 à 9 : expert, a contribué à l'amélioration du domaine ;
- 10 : expert reconnu, qui a écrit un best-seller sur la pointe du domaine
Difficile de se donner au dessus de la moyenne avec tout ça... Ensuite, une petite série de questions, auxquelles il fallait répondre sans aide (trop facile en cherchant à côté, of course).
N'ayant pas rempli mon quota de bonnes réponses, je ne tirerai de cet entretien qu'un contact et la preuve, encore une fois, que mon anglais oral laisse à désirer...
J'en ai aussi conclu, même si ça pouvait paraître évident, que les profils recherchés par Google (que ce soit ressources humaines ou startups à racheter) sont les experts dans un domaine (quel qu'il soit). Ayant plutôt un profil polyvalent (développement, gestion de serveurs, webmastering...), ça ne pouvait pas coller !
Petits détails en vrac :
- Je n'ai rien demandé pour travailler chez Google (en dehors peut-être d'un vague début de demande de stage il y a quelques années)
- Après enquête, elle m'a trouvé en faisant des "Boolean searches", je me demande d'où sortent les données :)
- Le fait que je ne sois pas fortement diplômé de l'a pas ralentie
- Si quelqu'un est intéressé par un job @ Google, je peux transmettre, j'imagine que ça ira plus vite que par la voie classique...
Une page se tourne
vendredi 11 mai 2007 à 17:22 (Julien Tartarin)
Une page se tourne dans l'histoire de Beyoung.
La suite, c'est pour l'instant Fiftiz.fr et Les-horaires.fr, mais croyez-moi on ne s'arrêtera pas là ;-)
RE: Un antispam qui fonctionne ?
vendredi 23 mars 2007 à 10:31 (Julien Tartarin)
Il y a presque trois semaines, j'ai mis en place un antispam ''trapbot''.
Ce piège à spam bot fonctionne à merveille : 850 spams bloqués, aucun n'est passé !
Chose amusante que je n'avais jusqu'alors pas remarqué, en plus de remplir tous les champs, les bots en modifient également !
Sur Dotclear, le formulaire d'ajout de commentaire a un champ caché (redir) qui contient le permalink du billet commenté, pour rediriger le rédacteur du commentaire vers la bonne page. Typiquement, il contient une valeur de ce type : /2007/03/05/200-un-antispam-qui-fonctionne
La très grande majorité des envois bloqués (du moins, tout ceux que j'ai regardé) n'envoient pas /2007/03/05/200-un-antispam-qui-fonctionne mais /2007/03/05/200-un-antispam-qui-fonctionne/ (ceux qui sont réveillés auront remarqué le dernier slash).
Soit parce que les bots ne savent pas lire les balises XHTML finissant par />, soit en pensant qu'il s'agit d'un dossier et non d'un fichier et en anticipant une redirection envoyée par le serveur, je ne sais pas, mais le test pourrait être aussi simple que ça !
En attendant que les bots apprennent le CSS (ça viendra, un jour), je vous conseille de mettre ce type de système sur tous vos formulaires publics !
Tout casse en même temps !
lundi 19 mars 2007 à 16:55 (Julien Tartarin)
La semaine dernière, notre serveur local (développement, tests, backups, etc.) a commencé à rebooter (tout seul comme un grand, à cause de l'alim), puis à planter (crash inopinés sans charge ni log, sans utilisation CPU ni RAM). Les différentes copies de fichiers sur le deuxième serveur local échouaient via le réseau, et parfois même en montant directement les disques dur en IDE : freeze complet pendant la copie.
Les fautifs ne sont toujours pas clairement identifiés, il s'agit soit de l'utilitaire rsync, soit des disques durs eux-mêmes, puisque toutes les autres pièces ont été changées sur les machines... soit de la combinaison des deux. Toujours est-il qu'il arrive que certaines copies de fichiers entraînent un freeze du serveur... (Sur le net, on dit que rsync est très gourmand en réseau et constitue un très bon test matériel de la carte...)
Ce midi, je reçois un mail d'OVH qui me prévient que le disque d'un de nos serveurs commence à rendre l'âme (merci S.M.A.R.T.)... Evidemment c'est le seul serveur qui n'est pas en RAID1 :)
Du coup une question me vient à l'esprit :
POURQUOI est-ce qu'ils craquent tous en même temps ?
Il y a moins de 2 semaines, c'est le serveur de WebmasterClub.fr qui a craqué...
Je ne vois qu'une solution :
C'est une conspiration !
Un antispam qui fonctionne ?
lundi 5 mars 2007 à 18:23 (Julien Tartarin)
Je viens d'implémenter cette technique simple et pourtant radicale sur ce Dotclear. Il ne reste plus qu'à en suivre l'évolution.
D'après cet article, le taux de réussite de détection d'un spam est de 100%, quelques tests sur Fiftiz ont montré qu'effectivement ça fonctionnait bien :)
Voici le principe en résumé : il suffit d'ajouter un champ typique au formulaire à protéger, et de le masquer grâce à une classe CSS. Aucun utilisateur réel ne le verra. Les spam bots, eux par contre, le rempliront avec une valeur plus ou moins aléatoire. Si le champ est rempli, c'est un spam...
Note pour ma mémoire et pour les bidouilleurs : ça se passe au niveau du template (form.php et la feuille de style) et de layout/prepend.php
En vrac
mercredi 21 février 2007 à 21:30 (Julien Tartarin)
- Nous (Beyoung) avons organisé ce soir un premier test de Fiftiz.fr par des personnes de la cible ! Bilan à chaud : beaucoup de retours sur tout un tas de points, des choses à changer, améliorer mais aussi à laisser tel quel, des aberrations évidentes qui nous avaient échappé !
- Nous (Beyoung aussi) utilisons depuis quelques jours la todolist que Romain nous a concocté pendant sa première semaine de stage, ce n'est pas encore parfait, mais ça va plus vite qu'une feuille de papier !
- Bonne résolution : nous (moi) avons installé un "wiki d'entreprise". Son objectif : nous aider à documenter notre code, nos serveurs, etc.
Knowledge is power
disaient certains, ce wiki nous permettra de centraliser la nôtre ! (On va aussi développer nos efforts sur la centralisation du code et des méthodes de développement, c'est la révolution dans la devteam !)
Fiftiz.fr en home de Google News !
mercredi 24 janvier 2007 à 11:45 (Julien Tartarin)
Internet Explorer
mardi 9 janvier 2007 à 16:20 (Julien Tartarin)
J'ai des sautes d'humeur à chaque fois que je code un morceau de JavaScript qui doit fonctionner avec Firefox et Internet Explorer, ce n'est pas une nouveauté.
Aujourd'hui le truc "incroyable mais vrai", c'est qu'avec Internet Explorer, il est impossible de connaître la taille de la fenêtre avec document.body.clientHeight si le doctype HTML est déclaré. Et ce, même avec IE7...
Si quelqu'un a une solution plus "respectable" que de ne pas déclarer le doctype sur les pages à problème, je suis preneur !
Je passe à Google Apps for your domain
mercredi 27 décembre 2006 à 21:36 (Julien Tartarin)
J'ai décidé il y a quelques jours de passer sérieusement à Gmail. Pourquoi ?
C'est simple, mon pauvre Mac fête bientôt ses trois ans et ses 95% d'espace disque utilisé : il devient incapable de gérer mes mails correctement puisqu'avec le temps, les messages s'accumulent et ralentissent d'autant le Mail de Mac OS X... Et c'est sans compter la quantité énorme de spam que je reçois tous les jours !
Je me suis dit que Google pouvait faire ça pour moi ! Et d'ailleurs il le fait plutôt bien...
L'installation du domaine sens-interdit.fr pour Gmail et Gtalk a pris quelques heures seulement (vérifications et changements DNS compris). Le catch-all (*@sens-interdit.fr vers mon compte principal) est présent et c'est ce qui m'aurait manqué le plus (j'en fais une utilisation abusive !).
Je récupère toujours mes mails en POP, mais en laissant une copie sur Gmail. Ca me permet de tester l'interface web avant de continuer ma migration.
Et surtout, ça me permet de ne plus récupérer un seul spam sur mon ordinateur (pour ce domaine, bien sûr). L'antispam de Gmail a l'air plus qu'efficace même s'il lui est arrivé une fois de mal tagger un message. La synchronisation de mes contacts Carnet d'adresses/Gmail remédie à ce problème, sans étape fastidieuse et avec l'aide d'un freeware trouvé sur MacUpdate.
Mais le détail qui tue, c'est que Gmail vérifie le SPF. En gros, ça permet de vérifier que le message qui arrive vient bien de la personne qui l'a envoyé, ce qui n'est pas aussi évident qu'il n'y paraît !
Tous les services sont semblables à ceux fournis avec un compte Gmail "normal", et c'est ça qui est le plus appréciable !
Un seul point négatif : l'espace disque disponible par compte ne semble pas augmenter comme celui d'un compte Gmail normal (en ce moment 2,7 Go) mais reste figé à 2 Go. Mais bon, il faut le vouloir pour occuper 2 Go avec du mail...
Lexode dans Google News
mercredi 13 décembre 2006 à 19:29 (Julien Tartarin)
Depuis Samedi notre section Actualités et les sorties ciné de la semaine sont indexées par Google News !
Il ne reste plus qu'à envoyer de l'actu ultra pertinente au bon moment pour apprécier les retours... Affaire à suivre de près :-)
Lexode pourrait heurter la sensibilité des plus jeunes...
vendredi 8 décembre 2006 à 18:25 (Julien Tartarin)
... A ce qu'il paraît, en tout cas !
Deux charmantes demoiselles étudiantes devaient pour une mission tout à fait scolaire concevoir un questionnaire pour nos membres Lexodiens, histoire de connaître leurs habitudes de navigation et leur impression du site.
Jusqu'ici, tout allait bien !
Mais aujourd'hui nous avons appris que ce projet pourtant pas vraiment conséquent avait été refusé par la commission de leur établissement. Et en particulier par le directeur de celui-ci (j'ignore son nom, et celui du bahut aussi, dommage !).
La raison ? Certaines parties du site pourraient choquer (oui oui, choquer) les plus jeunes élèves de l'établissement !
J'imagine bien sûr qu'il parlait du forum "Amour et Sexualité", qui bien entendu n'est pas rempli de tabous, c'est un peu son rôle, en même temps.
Par contre il n'a pas dû comprendre que le contenu de ce forum était exclusivement rédigé par les membres de Lexode, des adolescents et pré-adultes de 12 à 24 ans... Qui pourraient très bien être les élèves qu'il veut "protéger".
C'est pourtant évident ! Il NE FAUT PAS laisser les jeunes échanger sur la sexualité, ce n'est pas de leur âge ! Mais alors ? S'ils n'ont pas des forums comme ceux de Lexode pour avoir les réponses à leurs questions, où vont-ils aller les trouver ? Parce que jusqu'à preuve du contraire... quand on est jeune, on s'en pose des questions !
Bref... Une autre fois peut-être, les filles !
Spammés par... le gouvernement Slovaque !
mercredi 29 novembre 2006 à 14:50 (Julien Tartarin)
Indirectement bien sûr, mais c'est bien une machine qui appartient au réseau officiel du gouvernement Slovaque qui spamme nos Bloxodes depuis ce matin !
Absolument incroyable
jeudi 23 novembre 2006 à 11:17 (Julien Tartarin)
Il semblerait qu'un américain ait découvert que les interactions sociales dépendent directement de l'activité des utilisateurs !
Concrètement, un utilisateur de Facebook échange plus de messages avec les gens qui sont dans sa contact list qu'avec les autres, remarque qui démolit tous les à prioris qu'on aurait pu avoir ! On remarque par ailleurs que l'activité dépend du jour de la semaine, et est donc proportionnelle à la quantité de cours ou de devoirs à faire. Wow.
Une chose semble bien différente de l'autre côté de l'océan cependant : le rapport indique que l'utilisation de Facebook se fait... en cours, ou du moins, beaucoup dans les locaux équipés des écoles. Le weekend est donc moins actif que la semaine. En France c'est tout le contraire : pas d'ordinateur en classe, et des chiffres plus généreux le mercredi et le week-end.
En tout cas je suis amusé de l'engouement subit que ces graphiques ont généré auprès des "2.0".
Pour être in, voici un mardi (en bleu) et un mercredi (en orange) :
Et le même mardi (toujours en bleu), avec un samedi (en orange) :
Page 1 sur 3 - Page suivante
