Yahoo! Bookmarks est bâti sur le framework Symfony !
Ce n’est pas anodin si Yahoo! a choisi Symfony et ça démontre que ce framework a du réellement du potentiel.
Je vais re-regarder ce qu’il a dans le ventre du coup 
via PrendreUnCafé
Un IDE pour PHP écrit en PHP-GTK, mais que demander de plus ? Compatible aussi bien avec Linux que Windows, capable de gérer en natif la colorisation syntaxique, l’auto-complétation des fonctions de PHP, FTP, CVS et même MySQL & PostgreSQL. De quoi réjouir n’importe quel développeur PHP ! Vous l’aurez compris l’un de ces principaux avantages est de pouvoir facilement lui ajouter des fonctionnalités.
Un projet qui mérite vraiment le détour, d’autant qu’il est distribué sous licence GNU et peut donc être utilisé et modifié à votre guise.
Je tiens d’ailleur à remercier Manico qui me l’a fait découvrir.
Liens : Tulip-IDE
En fait le concept est assez simple, plus un site fait des mises à jour régulièrement et souvent, plus il fera beau. La météo est basée sur le fil RSS des sites syndiqués, elle possède un mécanisme de cache qui permet de soulager le serveur de ThiberNet. Elle est mise à jour environ toutes les 2 heures de jour comme de nuit par une tache cron. A chaque nouvel ajout de site dans le bulletin météo, il faut une semaine au script pour s’étaloner et afficher correctement le temps. Si vous avez des idées de mises à jour, n’hésitez pas à me contacter.
Lien : Voir la Météo
Un système de cache est un ensemble de fonctions qui permet de diminuer le temps de création des pages en faisant un compromis avec l’espace disque ou la mise à jour des pages. Une des techniques de cache couramment utilisée est le cache par timeout, la technique est simple : on définit une période de mise à jour fixe pendant laquelle les données mises en cache resteront figées. Si des données proviennent d’un long traitement ou d’une grosse requête en base de données et que le rafraîchissement de l’information admet une période, l’utilisation d’un système de cache pourra augmenter les performances de l’application. On peut mettre presque tout en cache, aussi bien des données provenant d’un SGBD que du HTML ou encore des images. Pour ThiberNet, j’utilise moi-même une classe de cache qui permet de ne pas faire appel à ma base de données à chaque appel de page et donc optimiser les performances de ThiberNet.
La classe que je propose est vraiment très simple mais augmentera considérablement les performances de votre site si vous l’utilisez bien. Elle nécessite une autre classe File qui modélise un fichier et qui lui permet de sauver les informations sous forme de fichiers. Pour l’utiliser, vous devez créer une instance de Cache en faisant :
// période de 2 heures $cache = new Cache('cache/information.cache.php',60*60*2);
Ensuite pour l’utiliser utilisez la structure suivante :
if($cache->verify()) {
// Le cache est valide
echo $cache->get();
// On affiche le cache par exemple
} else {
// Le cache n'existe pas ou n'est plus valide
// Traitement qui génère l'information à mettre dans le cache
$information = foo(); // On rempli et affiche le cache
echo $cache->set($information); }
En effet le méthode set($contenu) renvoie le contenu qui lui est passé en paramètre pour une programmation plus propre. A noter que $information peut être de n’mporte quel type sérialisable : une chaîne, un tableau, un objet, …
Téléchargement : cache.tar.gz - 0.7 ko
Un des points clé dans un CMS, c’est la gestion des erreurs et des alertes utilisateurs. En effet, quand une erreur de lecture de fichier, d’accès à la base de données, ou de saisie d’un utilisateur est générée, il faut pouvoir la récupérer, puis la traiter, tout en gardant à l’esprit que les scripts qui traiteront cette erreur ne doivent pas être bloqués par celle-ci. Par exemple, si on souhaite traiter les erreurs d’accès à la base de données, et que pour celà le gestionnaire d’erreur à besoin d’accèder à la base de données, il y a un serieux problème. C’est pour celà que je pense que le gestionnaire d’erreur d’un CMS doit rester assez isolé de celui-ci et qu’ils ne puissent communiquer entre eux que par un système de trigger. Après pas mal de réflexion, je pense avoir trouvé un moyen de les gérer efficacement en utilisant les fonctions trigger_error, set_error_handler et les constantes d’erreur de PHP. L’idée serait de développer un gestionnaire d’erreurs propre au CMS dont hériteraient les classes de celui-ci. Ainsi en utilisant les erreurs déjà définies dans PHP et de nouvelles erreurs propre au CMS, on pourrait obtenir un système plutôt stable et sécurisé qui devrait avoir l’indépendance nécessaire pour bien fonctionner.