Je vais commencer ce billet en souhaitant à tous une excellente année, pleine de code bien indenté et de non-régressions ![]()
Il est temps de faire un petit point sur les évènements techniques marquants dans le domaine du développement web en 2007, et de jeter un oeil sur ce que cette nouvelle année nous apportera.
Dans le cadre d’un petit projet perso, j’ai voulu reproduire une version Ajaxifiée d’iTunes. Le première phase consistant à contruire le modèle de données, il était nécessaire d’utiliser quelque chose de suffisamment performant pour que des requêtes sur la bibliothèque réagisse correctement - lors de l’autocomplétion dans le champ de recherche notamment.
Ils l’ont fait ! Un an après l’annonce du partenariat entre Zend et Microsoft, une version de l’extension FastCGI pour IIS6 est disponible. Cela rend donc possible l’hébergement d’applications PHP sur des serveurs Windows 2003 sans se demander si le serveur va dégager de la fumée noire. Andi Gutmans de Zend affirme avoir des performances similaires entre les versions Linux et Windows, ce qui augure du bon - même si un peu plus de transparence sur les versions utilisées serait sympathique.
Petit rappel sur la technologie FastCGI. A l’origine, la technologie CGI exécute un php.exe à chaque requête ce qui donnait des perfs catastrophiques. FastCGI consiste à conserver ce processus ouvert afin d’accélérer le mouvement (d’où le “fast”) mais cela restait assez instable sous Windows.
Cette collaboration montre en tout cas la bonne volonté de Microsoft d’aider cette technologie, et peut laisser entrevoir des perspectives intéressantes. Des initiatives comme Phalanger pourraient laisser planer une intégration de PHP dans .Net à moyen terme ?
Si vous souhaitez développer une bibliothèque de photos, il peut être intéressant de sécuriser l’accès à des images. Par exemple ne pas permettre de télécharger des images HD avant de les avoir payées.
En utilisant les fonctionnalités d’Apache et PHP, on peut obtenir un résultat assez intéressant.
S’il est un choix difficile et consciencieux à faire pour un codeur, c’est bien celui de son environnement de développement intégré. Comme le cavalier et sa monture, c’est avec lui que vous allez passer la plupart de vos heures de geekitude absolue. Conséquence, autant bien choisir son partenaire, avant d’hurler avec un fort accent latino que le monde du web est à vous !
Dans le cadre d’un des mes projets, j’ai été amené à me poser la question de l’internationalisation de données d’un site multilingue, en particulier des dates.
La date n’étant pas formatée automatiquement avec une locale idéale par MySQL, puisque GETFORMAT ne renvoie pas de valeur correspondant au format français, je me suis résigné à le faire “à la main”.
Les sites Web communiquent depuis toujours du contenu à travers des documents joints, allant des communiqués de presse aux manuels utilisateur. Certains d’entre eux peuvent devenir une vraie jungle et parfois même une recherche s’avère nécessiare sur un ensemble de sites (ex : des Intranets).
Il existe pour résoudre ce problème des moteurs d’indexation permettant de trier et extraire l’essence des documents. Cet article présente 3 d’entre eux dont l’attrait principal est, bien entendu, leur interaction avec PHP, même si la majorité d’entre eux tournent avec d’autres technologies (Perl, C, etc.)
Si vous avez déjà travaillé à plusieurs sur un projet, vous avez pu, malgré toutes les garanties qu’offre la gestion de configuration comme Subversion ou ClearCase, voir votre fichier de paramétrage écrasé par celui d’un autre développeur. Cela peut devenir vite rageant lorsque le travail est envoyé sur le serveur quotidiennement. Voici une astuce pour tenter d’y remédier.
Dans toute application un tant soit peu professionnelle, vous aurez besoin de définir le chemin racine de votre site, pour diverses tâches comme par exemple l’upload d’un fichier.
Cependant, il y a des fortunes diverses. Certains comme osCommerce vous laissent cette opération à faire dans le fichier de config. D’autres comme Typo3 tentent un calcul à l’arraché à partir des variables DocumentRoot et de l’URL appelante, donnant des résultats croustillants (surtout lorsque le DocumentRoot est séparé physiquement de vos sites Web…).
Alors qu’il y a une astuce assez simple. La directive suivante :
$site_rootdir = realpath(dirname(__FILE__));
vous donne le chemin absolu vers le script dans lequel vous vous trouvez. Donc, si votre fichier de configuration est à la racine du site (ce qui est souvent le cas quand il n’est pas dans un dossier include ou conf), c’est gagné
Commentaires récents