Développement, réseaux, sysadmin et futilités
Posts by e-t172
Agrégaweb : un nouvel agrégateur est né
2266 jours
by e-t172
Après plusieurs mois de dur labeur, je suis maintenant disposé à vous présenter un service co-produit par notre cher ami ApOpH!s et moi-même : Agrégaweb. Comme d’habitude, les rôles se répartissent de la façon suivante : votre serviteur a codé la partie PHP de la bête, et mon confrère s’est chargé du XHTML / CSS.
Le principe est assez simple (contrairement à son développement d’ailleurs) : il s’agit d’un agrégateur RSS sur le Web.
J’entends déjà des huées au fond de la salle : Eh, c’est pourri ton truc ! Google IG, Netvibes et Microsoft font pareil !
. Oui, mais il y a ici une subtile mais importante différence : les flux ne sont pas téléchargés en Javascript, c’est à dire par votre navigateur, mais par le serveur lui-même. En quoi est-ce utile ?
- Vous pouvez accéder à l’ensemble de vos flux de n’importe où en conservant la trace de vos éléments lus et non lus.
- Tous les flux sont gérés de manière centralisée, c’est à dire que si un utilisateur a ajouté ce flux avant vous, les archives sont partagées de telle sorte qu’il se peut que vous ayez des centaines d’éléments déjà présents dans un flux alors que vous venez de l’ajouter. Fonctionnalité intéressante lorsque combinée aux possibilités de recherche dans les flux offerte par Agrégaweb.
Hop, voilà 3 personnes qui se sont rassises, mais il en reste une. Eh, Google Reader aussi stocke les flux sur son serveur !
. Oui Mr. Le Chieur, mais :
- Google Reader ne gère pas les archives centralisées.
- Agrégaweb a plus d’un atout dans sa manche : essayez de consulter le flux de NoFrag, dont la particularité est de ne pas prodiguer de descriptions d’éléments, sous Google Reader puis sous Agrégaweb. Et sentez la différence.
Agrégaweb a été conçu dans une optique de compatibilité maximale tant du point de vue des flux RSS que de l’utilisateur : ainsi, l’ensemble du site n’utilise pas Javascript (donc pas d’AJAX, oui c’est voulu) et est aux normes, ce qui le rend accessible même au plus exotique des navigateurs (par ailleurs, une version spécialement conçue pour téléphone portable est prévue). De plus, un soin particulier a été apporté au moteur d’analyse des flux de sorte que tous les flux RSS, même les plus mal foutus, soient lisibles par l’agrégateur.
Agrégaweb a nécéssité une quantité non négligeable de travail du fait de la complexité sous-jacente (et non apparente) du service. La majorité du boulot a concerné la partie immergée de l’iceberg (robot d’analyse des flux notamment).
Enfin, en ce qui concerne la publicité affichée sur l’ensemble du service, sauf généreux donateur il semblerait que ce soit une nécéssité. En effet, notre principale préoccupation actuellement est la quantité de ressources que va consommer le système, principalement en termes de trafic web et d’espace disque. Et pour cause : pour le moment le service est hébergé sur mon compte 1 and 1, lequel possède une limitation de trafic de 20 Go / mois et un espace disque de 2 Go. Cela peut sembler large, mais vous n’avez pas vu la vitesse effarante à laquelle la base de données grossit alors qu’on était que deux à utiliser le service (d’un autre côté, il fallait s’y attendre, à force de tout stocker). Un système sophistiqué de gestion de cache HTTP intégré à l’architecture utilisée pour Agrégaweb, couplé à la gestion centralisée des archives, nous permettront de limiter la casse, mais la pub s’avère néanmoins nécéssaire pour pouvoir évoluer sans dégrader la qualité de service.
Pour finir, je vous invite chaleureusement à venir essayer ce nouveau service créé par nous, pour vous. Cependant, malgré le fait que le service ait subit de longues périodes de bêta-test, il est possible que des bugs se cachent parmi les méandres du site. Si vous en voyez, je vous serai gré de venir le signaler. Merci. Par ailleurs, si vous avez une quelconque suggestion susceptible d’améliorer le service, vous pouvez venir vous exprimer sur le forum correspondant.
Bonne syndication sur Agrégaweb !
Firefox 1.5 / IE7 : la guerre est imminente
2284 jours
by e-t172
Notre cher Tristan Nitot vient d’écrire un billet concernant le plan de bataille de Firefox face à la menace IE7.
La communauté des utilisateurs doit continuer son formidable travail, avec SpreadFirefox.com. Il faut continuer à faire PAF la clé USB. Il faut continuer à en parler autour de nous, à table dans les repas de famille, sur les blogs. Je travaille, avec Mozilliens américains, à de nouvelles campagnes innovantes. Stay tuned
Il y a un truc que j’ai du mal à comprendre ici : j’ai dû installer Firefox chez au moins une bonne dizaine de mes proches (amis et famille). Ils l’utilisent en lieu et place de IE et n’ont aucune envie de revenir en arrière. Si on imagine que chaque personne qui installe Firefox en parle à 2 ou 3 autres, la croissance devait être exponentielle et augmenter beaucoup plus vite qu’actuellement. Pourquoi ce n’est pas le cas ?
Cette guerre contre IE va être lente et difficile. Je vais être pessimiste mais dans l’état actuel du marché elle est vouée à l’échec. Pourquoi ? Pour deux raisons.
- Microsoft a beaucoup, beaucoup plus de moyens que Mozilla. J’ai peur que ce ne soit une variante de la fameuse bataille pendant laquelle la cavalerie Autrichienne faisait face aux lourds blindés Allemands.
- Dans le cas improbable où Firefox arriverait malgré cela à atteindre une part de marché dangereuse pour Microsoft (quelque chose comme 30%), il va changer de stratégie et tout simplement copier toutes les fonctionnalités et concepts de Firefox pour que IE devienne un clone de Firefox. Du coup, il n’y aura que deux différences entre IE et Firefox : IE est préinstallé sur tous les systèmes Windows, et Firefox est un logiciel libre. Du point de vue des initiés Firefox reste le plus intéressant, mais l’utilisateur lambda, qui constitue la majorité des Internautes, ne réfléchira pas de cette manière.
Pour arriver à battre Microsoft, il n’y a qu’une solution : intégrer à Firefox un gros truc que Microsoft ne pourra pas intégrer lui-même à son navigateur. Comment y arriver, je n’en sais rien, mais c’est à mon avis le seul moyen pour Mozilla de gagner non seulement la bataille, mais aussi la guerre.
Actuellement, Microsoft prépare IE7, une réponse à Firefox. Mais il n’utilise que très peu de ses moyens pour le moment, probablement parce qu’il pense que IE7 suffira à arrêter ou du moins à ralentir fortement la croissance de Firefox. Mais si, même après la sortie d’IE7, Firefox continue de croître à la même vitesse, là Microsoft va se sentir menacé et va sortir l’artillerie lourde, faisant alors tout pour tuer dans l’oeuf toute possibilité pour Firefox d’obtenir des parts de marché supplémentaires. La seule façon de s’en tirer dans ce cas sera de frapper un grand coup, quelque chose à laquelle Microsoft ne s’attendra pas. Il se dépêchera de réagir mais ce sera déjà trop tard, l’explosion provoquée par cette nouveauté aura déjà atteint beaucoup trop de monde. Bien sûr, pour que ça fonctionne il faudrait le faire avant la mise en place de l’artillerie lourde de Microsoft. La firme de Redmond sait à quoi s’attendre, elle connaît les directions que prennent les développeurs de Firefox et anticipera son évolution. Pour cette raison, évoluer « normalement » dans ces directions ferait inéluctablement gagner Microsoft. Il faut le surprendre, attaquer là où ça fait le plus mal, là où il ne s’y attend pas.
Le monopole de Microsoft en ce qui concerne Windows a provoqué un cercle vicieux : les utilisateurs ne veulent pas passer à Linux parce qu’il n’y a pas assez d’applications ou parce que celles-ci sont moins évoluées que sous Windows, mais de l’autre côté, les entreprises refusent de développer pour Linux justement parce qu’il n’y a pas assez de clients potentiels. C’est sans fin. Une victoire de Mozilla face à Microsoft sur le marché des navigateurs ouvrirait une brèche bouleversant toute la politique de Microsoft d’intégration du navigateur dans le système d’exploitation. Cette brèche, si elle est correctement utilisée, pourrait servir aux autres logiciels libres à « passer derrière les lignes ennemies », c’est à dire utiliser la brèche pour pénétrer les défenses de Microsoft et l’attaquer de l’intérieur, et non de l’extérieur comme c’est le cas actuellement.
En conclusion, de grands espoirs reposent sur Firefox. Mais la moindre erreur lui sera fatale. Les dirigeants de Mozilla devront analyser minutieusement la situation et en profiter pour repousser les parts de marché de Microsoft. Espérons qu’ils sauront prendre les bonnes décisions.
Passons maintenant au point de vue du développeur web. Il faut savoir que la lutte du développeur Web n’est pas la lutte de Mozilla.
- Mozilla cherche à inciter le plus de personnes possible à utiliser son navigateur.
- Le développeur web cherche à inciter le plus de personnes possible à abandonner IE.
Ce n’est pas la même chose. Le développeur web s’en bat les cacahouètes de savoir que l’utilisateur utilise Firefox ou Opera. Sauf quand il utilise IE, auquel cas il doit tout faire pour l’en arracher. Parce que IE est le seul navigateur encore en service qui peut être considéré comme étant non respectueux des standards du web, et que tout développeur web « nouvelle école » doit utiliser ces standards.
« Oui, mais IE7 respectera ces standards » me direz-vous. C’est oublier qu’il y a souvent une longue distance entre ce que Microsoft dit et ce qu’il fait. Il est possible que IE7 adopte les fonctionnalités utilisateur de Firefox mais n’améliore pas le moteur de rendu, ou très peu. Et ça, ce serait la pire chose qui pourrait arriver. Pourquoi ?
Il faut regarder la réalité en face : l’utilisateur lambda se contrefout de savoir si son navigateur respecte les normes ou pas, il n’a aucune idée des enjeux et il ne veut pas le savoir. Il veut juste que son navigateur affiche les pages correctement. Alors c’est très gentil les pensées philosophiques du style « je vais respecter l’esprit des standards du web et faire en sorte que ma page s’affiche correctement sous IE quitte à limiter certains aspects du design » mais ici c’est se fourer le doigt dans l’oeil jusqu’au coude. Parce que si IE7 n’améliore pas son respect des standards et qu’on continue à coder nos pages de cette façon, il n’y a aucune raison pour que cela change. Les utilisateurs passeront de Firefox à IE7 parce que ce dernier se sera amélioré, mais il ne sera pas meilleur en termes de respect des standards. Et là, on aura perdu sur les deux tableaux : la bataille de Mozilla et la bataille des développeurs web. Au final, IE restera le navigateur majoritaire et, en prime, il n’aura pas amélioré son moteur de rendu. Il ne nous restera alors que nos yeux pour pleurer.
Comment éviter ce scénario catastrophe ? Aujourd’hui, les développeurs web ont trois directions de développement possibles :
- Faire en sorte que le site s’affiche de manière identique sous IE et Firefox au détriment du design.
- Ne pas prendre en compte les utilisateurs IE et annoncer « cash » à l’accès au site qu’il faudra utiliser Firefox ou un autre navigateur alternatif pour l’utiliser correctement.
- Faire un design différent pour IE et pour les autres navigateurs.
La première solution mène au problème énoncé plus haut.
La deuxième solution n’est pas viable, du moins tant que Internet Explorer aura plus de 50% de parts de marché.
La troisième solution nous permet de résoudre le problème. Plutôt que d’interdire l’accès au site aux utilisateurs d’Internet Explorer, on va faire un compromis : on va offrir un design moche et/ou peu ergonomique aux utilisateurs d’Internet Explorer, et un design parfait aux utilisateurs de navigateurs alternatifs. Cette solution est déjà utilisée par Laurent Denis pour Blog & blues, qui s’affiche de manière différente sous IE et sous les autres navigateurs.
L’objectif est de faire en sorte que l’utilisateur consulte tout de même le site sous IE parce que son contenu l’intéresse, mais que la navigation soit plus agréable sous les autres navigateurs. Quand l’utilisateur s’apercevra que les sites qu’il consulte sont plus jolis et plus ergonomiques sous Firefox (ou Opera, etc), il sera beaucoup plus enclin à changer de navigateur que si l’affichage est identique ou que si le site refuse de s’afficher sous IE (auquel cas l’internaute passera purement et simplement au site suivant). C’est donc la solution à adopter, qui résoudrait le problème sans porter atteinte à l’accessibilité du site. Son seul défaut est qu’elle exige plus de travail au moment du développement mais également pour la maintenance et l’évolutivité. C’est le prix à payer.
Les développeurs web et la Mozilla Foundation mènent des batailles différentes, bien que toutes deux rudes et difficiles. Mais avec un objectif commun : détruire le monopole de Microsoft. Souhaitons-leur bonne chance.
"Daemonizer" un script PHP
Suite à mon document sur la création de serveurs en PHP, peut-être certains d’entre vous ont dû se poser la question : comment « daemonizer » un script PHP ? En clair, comment faire en sorte qu’il fonctionne en arrière-plan sans user de saletés telles que nohup, comme un véritable serveur tel que Apache, MySQL, Samba, etc ?
Il est clair que la documentation de PHP manque de précision sur ce point, ce qui m’a forcé à aller récupérer quelques morceaux de réponse un peu partout et même à m’inspirer de programmes écrits en C ou en Perl. Je vais récapituler dans ce billet ce que j’ai appris.
Pour « daemonizer » un script PHP, il faut 3 étapes bien distinctes :
- Le script doit se relancer lui-même en redirigeant tous les flux (STDIN, STDOUT, STDERR) vers
/dev/null. Faute de quoi la sortie du script sera envoyée sur votre terminal. De plus, un problème avec OpenSSH se produit également lorsqu’on ne le fait pas. - Le processus doit être « forké ». En d’autres termes, on va faire une copie à l’identique du processus. La seule différence est que cette copie sera orpheline, c’est à dire qu’elle sera enfant direct de INIT (le processus racine du système), et non du terminal à partir duquel le démon a été lancé. On fermera ensuite le processus original. Si le fork n’st pas fait, l’administrateur se verra contraint de faire CTRL + C pour détacher le démon, ce qui n’est pas problématique (le processus ne sera pas fermé), mais peu esthétique.
- Le processus doit être transformé en « chef de session ». Cela n’est pas réellement nécéssaire mais plus propre : ça évitera que le processus ne soit encore rattaché au terminal qui l’a lancé.
Pour programmer ces trois points, nous aurons besoin de 3 fonctions (respectivement) : proc_open(), pcntl_fork() et posix_setsid().
Voici le code :
// On se place dans le même répertoire que le script chdir(dirname(__FILE__)); // On vérifie que l'extension PCNTL est bien là if (!is_callable('pcntl_fork')) { die('Error : PCNTL extension not available, recompile PHP with --enable-pcntl'."\n"); } // Si cela n'est pas déjà été fait... if (!in_array('/redirected', $argv)) { // ... on relance le script en redirigeant les flux $desc = array( 0 => array('file', '/dev/null', 'r'), 1 => array('file', '/dev/null', 'a'), 2 => array('file', '/dev/null', 'a') ); // Note : on peut améliorer ceci en repassant les paramètres de ligne de commande proc_open('php -f '.basename(__FILE__).' /redirected', $desc, $null); // Puis on ferme le processus parent die(); } // On tente de forker $pid = pcntl_fork(); if ($pid == -1) { // Erreur lors du fork die('Error: cannot fork'."\n"); } if ($pid) { // Fork réalisé : on ferme le processus original die(); } else { // Fork déjà réalisé : on ne fait rien } // On devient maître de session posix_setsid(); // Let's go !
Vous pouvez coder tout ce que vous voulez à la suite, ce sera « daemonizé ».
1 and 1 fait de gros cadeaux
2311 jours
by e-t172
Anniversaire : 1 and 1 fête ses dix ans. J’en aurais eu strictement rien à cirer si l’hébergeur ne proposait pas une offre très exceptionnelle pour cet anniversaire. En effet, 1 and 1 vous offre un pack d’hébergement web « premium » gratuit pendant 3 ans. Pour rappel, voici les grandes lignes de ce pack :
- 2 Go d’espace disque
- 20 Go de trafic
- 5 accès FTP
- 1 nom de domaine en .info offert
- Gestion DNS
- 500 comptes mail POP3/IMAP/Webmail
- PHP 3, 4 et 5 (avec tout un tas d’extensions)
- 10 bases de données MySQL
- Accès SSH et tâches CRON
Et tout ça pour pas un rond. Oui, vous avez bien lu. Et oui, il serait suicidaire de ne pas se jeter dessus tout de suite : courez ! (bon, ça peut attendre quand même, l’offre dure jusqu’au 31 novembre)
Il faut avouer que 1 and 1 nous fait ici une excellente surprise et invente un système de vérification d’inscription des plus originaux : en effet, pour éviter que des petits malins s’amusent à faire 30 comptes pour une seule personne, une fois l’inscription faite un robot vous appelle par téléphone et vous demande d’entrer un code pour valider votre inscription. Or, un numéro de téléphone ne peut servir pour plusieurs comptes. Oui, ça calme, même si ça ne doit pas être très compliqué de trouver un pote qui accepte d’entrer un numéro quand on l’appellera sur son téléphone (et qui n’a rien à faire d’un hébergement web).
Le panel d’administration de 1and1 est joli mais apporte parfois peu d’informations là où on aimerait en avoir plus. Néanmoins, il fait ce qu’on lui demande. Dommage qu’il faille attendre plus ou moins longtemps pour que chaque modification soit prise en compte (une dizaine de minutes).
En résumé : jetez-vous dessus.
Les normes, le salut du web ?
2319 jours
by e-t172
Considérons le Web comme étant une ville. Chaque site représente un bâtiment, qui peut avoir diverses fonctions : Wikipédia serait un musée, votre webmail le bureau de poste, les magazins seraient les sites d’e-commerce, etc.
Pour pouvoir construire un bâtiment dans nos villes bien réelles, nous devons respecter un certain nombre de normes de construction. Ces normes peuvent être comparées aux standards du W3C. Elles garantissent la perrénité et l’accessibilité du bâtiment.
Aujourd’hui sur le Web, la grande majorité des webmasters construisent leurs bâtiments sans respecter ces normes. D’où des constructions branlantes, miteuses et inaccessibles aux personnes handicapées. Les standards du W3C, dont le respect serait dans la réalité obligatoire, sont bafoués dans la plus grande anarchie résultant de la « guerre mondiale du web » (guerre Netscape-Internet Explorer). Cette guerre est terminée depuis longtemps, et l’ONU (le W3C) a été créé afin de maintenir la paix. Malheureusement, les architectes n’ont pas suivi la croissance démographique et technologique du Web qui a suivi la fin de la guerre. Ils en sont resté à des techniques de construction dépassées complètement sous-dimensionnées censées pallier les déficiences de la technologie d’antan.
A l’inverse, certains architectes ont découvert les nouvelles techniques de construction, plus sûres, plus fiables, en respectant les normes de construction du W3C. Alors que les autres ne font que des baraques branlantes, ces constructeurs de la « nouvelle école » construisent des immeubles et des gratte-ciel, inventant de nouveaux styles et posant de gigantesques baies vitrées. Ces prouesses leur sont permises grâce aux nouvelles techniques telles que la mise en page CSS, leur garantissant une construction solide et pérenne.
Aujourd’hui, dans la réalité, quel architecte oserait refuser d’installer des accès pour handicapés à son bâtiment sous prétexte qu’ils ne constituent que quelques % de la population ? Cela ferait assurément scandale. Malheureusement, c’est encore monnaie courante sur le web. La plupart des bâtiments du web sont en effet encore aujourd’hui innaccessibles aux handicapés visuels ou moteurs, leur refusant ainsi l’accès à une source d’information et de culture. Beaucoup de webmasters envoient balader certains de leurs visiteurs sous prétexte qu’ils utilisent Firefox ou un autre navigateur alternatif. En forçant quelque peu l’analogie avec les handicaps, on obtient ceci : « Désolé, vous n’avez qu’à avoir des yeux ». Presque comique si ce n’était pas aussi grave.
Mais il y a aussi plus préoccupant : nous sommes dans une ville constituée en majorité uniquement de baraques branlantes. Le web est un bidonville. Et ce bidonville est l’oeuvre de tous ces webmasters dont l’irresponsabilité a bloqué tout progrès sérieux dans les domaines des matériaux de construction et des techniques associées. Lorsque vous faites une baraque de plus avec votre éditeur WYSIWYG, c’est tout le web que vous saccagez. Prenez du recul. Regardez plus loin que le bout de votre site. Vous n’avez pas le temps ou les compétences de construire proprement ? Eh bien ne construisez pas ou déléguez cette tâche à quelqu’un d’autre. Mais par pitié, ne venez pas ajouter encore une poubelle au web. Vous faites un site pour VOS VISITEURS, pas pour VOUS.
Le web est un pays en voie de développement. Rendez le plus attractif en diffusant et en enseignant les normes du W3C autour de vous. Il nous faut d’autres initiatives louables telle que celle du Site du Zéro. Certains se complaisent dans le fait que les standards seraient réservés à une « élite ». Il faut casser cette image.
Sur le web, le permis de construire n’existe pas. Au début on a trouvé ça super, maintenant il ne reste plus qu’à pleurer.