Ma traduction n'est pas parfaite, et je n'ai pas voulu employer les mots "bon/mauvais code" qui sont trop vagues.
PHPFreaks nous livre 10 ways to avoid writing crappy code

• Concevez par les tests
• Pratiquez la refactorisation
• Restez simple
• Utilisez des design patterns
• N'utilisez pas de design patterns
• Acceptez les limitations de votre langages
• Faites comme si vous écriviez un livre
• Faites valider votre code par une personne tierce
• Développez E_STRICT
• Distinguez code source et version livrable

Je rajouterai juste : "pensez sécurité et types d'utilisations de votre code"

Zend Studio 7 est actuellement en version Béta, mais librement téléchargeable et testable par tout le monde.

Un rédacteur de developpez.com l'a testé pour vous, voyez l'article ici : Présentation des nouveautés Zend Studio 7.0

Dès la sortie de PHP5.3, un nouveau débat (nouveau ... pourtant vieux de plusieurs années déja) a ressurgi sur les mailing-lists internes.
A quand le typage complet des arguments de méthode ?
Actuellement, il n'est possible de typer qu'un objet d'une classe, ou encore un "array", on a donc ridiculement un typage incomplet, que les afiçionados d'autres langages ne manquent pas de nous renvoyer en pleine tête ;-)

Ilia Alshanetsky possédait un patch pour 5.2 rajoutant un support à la fois complet et souple, il l'a porté sur 5.3 et le remet donc sur la table au sein du PHP Group. Vous pouvez lire son billet blog ici

Vous pouvez suivre des fils de discussion par exemple ici, sur les @internals.

Sinon, il existe encore une page très intéressante sur le wiki de PHP, proposant un support total du typage des fonctions : non seulement tous ces arguments peuvent être typés, mais aussi sa valeur de retour.
Enfin une bonne idée ! Mais malheureusement pas encore dans PHP, en effet le PHPGroup n'est pas d'accord avec lui-même. Certains pensent que PHP devrait évoluer vers un tel typage (qui pour rappel resterait entièrement facultatif comme l'est le typage actuel) , d'autres pensent qu'au contraire typer strictement une fonction enlèverait de la souplesse à PHP dans la mesure où si une méthode type sur un entier, lui passer "1" mènerait à une erreur alors que par transtypage cela est valide.

Ce que j'en pense moi ? J'aime l'idée d'Ilia : un typage souple et efficace, à l'image de PHP, mais s'il vous plait : vite vite vite !
PHP a vraiment mûri ces dernières années, et avec l'avènement des frameworks qui apportent un cadre strict à PHP, une telle fonctionnalité serait vraiment la bienvenue !
Peut-être pour PHP 5.4 ?

Tout est dit, et vous êtes déja tous au courant de toute façon.
Le 30 Juin 2009 est à marquer sur le calendrier, après environ 2 ans d'attente, PHP 5.3 est enfin sorti !

Voila la page de download, faites chauffer les modems ^^

Mon confrère Guillaume Rossolini vient de traduire un article d'IBM sur la migration PHP5.2 vers PHP5.3

"PHP V5.3 est prévu pour bientôt. De nombreuses fonctionnalités de cette version étaient prévues depuis plusieurs années. Initialement décrit comme « PHP 6 sans le support natif d'Unicode », PHP 5.3 est une amélioration riche en nouvelles fonctionnalités pour la branche de la version 5. Cette version est destinée à préparer les développeurs pour PHP 6 quand elle sortira, en ajoutant de nombreuses fonctionnalités, en opérant du nettoyage moyennant l'amélioration des fonctionnalités, en résolvant des problèmes liés à certaines plate formes et en décourageant l'utilisation de fonctionnalités qui n'existeront plus dans les versions ultérieures. Dans cette série « les nouveautés de PHP 5.3 », nous allons entrer dans le détail de ces fonctionnalités et voir comment elles peuvent être utilisées dans votre application Web."

Tout développeur Web connait le SOP, pour Same Origin Policy. Ces règles qui empêchent notamment un objet XHR de requêter un domaine différent de la page depuis laquelle il est issu, obligeant les développeurs à avoir recours à des proxies ou autres joyeusetés du genre. C'est la même chose avec les cookies, et fort heureusement sinon le Web aurait explosé depuis des lustres.

Malheureusement, la protection SOP ne suffit plus aujourd'hui, et XSS règne en maitre dans le domaine des failles de sécurité sur le Web.
Conscients de ce problème depuis bien longtemps, les ingénieurs de chez Mozilla ont inventé CSP : Content Security Policy.
Les règles basiques sont simples :
- Tout javascript inline, c'est à dire non issu d'un fichier JS est totalement interdit et ignoré par le moteur JS
- Tout javascript issu d'un fichier JS ne pourra être exécuté que si le domaine de provenance du JS fait partie d'une liste blanche établie par le développeur

Tout cela sent bon pour la sécurité car XSS semble définitivement impossible. Enfin presque, car avec cette règle il faudrait alors trouver une faille dans le navigateur - ce qui reste tout à fait faisable et possible : mettez vos navigateurs à jour.
Ou encore spoofer le DNS - ce qui est aussi possible, soit en s'introduisant dans la table de routage de la box de l'utilisateur, la plupart du temps c'est assez simple car ils ne changent pas le mot de passe par défaut de leur box, soit en empoisonnant les cache DNS plus haut, là ça se corse tout de même.

Une fois de plus, la question de la migration :
Mozilla assure que celle-ci sera simplifiée, le processus CSP pouvant être personnalisé et ne se résumant pas aux 2 règles que j'ai citées plus haut ( la page officielle pour plus d'info ). Ils ont étudié beaucoup de pages Web, de complexité plus ou moins grande, et ont assuré que passer à CSP pourra se faire progressivement pour les pages très complexes, et sera simple pour les pages moins complexes.

CSP arrive dans FF 3.5 (c'est à dire très bientot). Quant aux autres navigateurs qui ne supportent pas la technologie : aucun changement pour eux, ils ignoreront les tags HTML et les en-têtes HTTP rajoutés par la technologie CSP (qui d'ailleurs posent des problèmes de confidentialité car les en-têtes utilisés s'approchent grandement du Referer, à suivre ...)

Le blog de Mozilla Security saura vous renseigner d'avantage
La page officielle du CSP, à lire en long, large et travers
Les groupes Mozilla Security

Enfin, le voila !!
Ca fait juste 2 ans qu'on l'attend, et personnellement 1 an / 1 an et demi que je tourne avec pour expérimenter (les versions CVS).
Le guide de migration est à lire par tous les développeurs PHP :-)
PHP 5.3 est officiellement prévue pour le 30 Juin après un report tout chaud d'une semaine. Même s'il reprend du retard, il est certain qu'il va sortir sur une période très très proche, les RCs sont terminées, beaucoup de bugs ont été corrigés, quelques petits résistent encore.

Cette version est un pas de géant en avant pour PHP, je rappelle donc le lien officiel vers les nouveautés : http://docs.php.net/migration53

La douloureuse question de la migration, que dire de mon point de vue... ? Elle sera plus simple que PHP4 vers PHP5, mais probablement plus difficile que PHP5.1 vers 5.2. En tout cas, vous avez bénéficié d'une période de temps non négligeable pour tester vos projets avec cette version, depuis la alpha 1.0 (sans parler de CVS). PHPUnit et Zend Framework (et probablement beaucoup d'autres projets) se sont déja posé la question.
Si votre application est orientée objet (ce qui est fort probable), plongez-vous dedans car PHP 5.3 introduit des chamboulements et des nouveautés sur lesquelles il serait dommage (voire idiot, oui oui) de faire l'impasse. Ne refaites pas la même erreur que la migration PHP4 vers PHP5, penchez-vous sur la question tout de suite (Comment ça, vous ne pratiquez pas la veille techno ? ;-)).
Les frameworks comme Zend Framework vont abandonner le support de la branche PHP5.2 un jour, quand exactement ? On ne sait pas, mais je table sur "quelque part en 2010". Connaissant Fabien Potencier et la communauté Symfony, je pense ne pas me tromper en disant "idem pour le framework Symfony, il va rapidement abandonner PHP5.2". Rapidement signifie 2010, dans environ plus ou moins 1 an.

Vos nouveaux projets qui démarrent aujourd'hui (oui bon, attendons quand même qu'elle soit réellement sortie cette version 5.3) doivent être développés pour être compatibles PHP5.3, et j'irai même jusqu'à dire doivent tourner sous PHP5.3 !
PHP n'est plus un langage de bidouilleur et la plupart des entreprises semblent avoir compris ce fait. PHP avance et évolue, en suivant la courbe d'évolution du Web comme il l'a toujours fait. Ces nouveautés permettent de programmer plus efficacement, la plupart du temps en écrivant moins de lignes de codes ou en structurant mieux celles-ci, sans compter sur les améliorations de performance qui sont toujours minimes, certes, mais au rendez-vous sur chaque version mineure de PHP. Il y a en effet eu pas mal de changement dans le fonctionnement interne de PHP

Je ne pense pas faire de petit (ou gros) article sur PHP5.3, car Pascal Martin (par exemple) a déja tellement bien fait les choses, que ça serait du plagiat idiot ;-).

Sebastian Bergmann en a parlé il y a pas mal de temps déja et ca a été mergé dans la branche 3.4 de PHPUnit.

Rappel : PHPunit lance actuellement chaque test dans le même processus PHP. En gros, il n'y a qu'un seul process PHP pour tester. Ceci a des conséquences, tout d'abord : il est possible, en programmant cela correctement, d'accélérer l'exécution du test.
Ensuite, (et c'est plu gênant) si le code testé possède une erreur E_FATAL (par exemple une parse error, ou encore un "require" qui échoue), alors c'est tout le processus de test qui échoue et fait quitter PHPUnit.

Bientôt dans la version 3.4 (qui est actuellement disponible, mais toujours en version beta), il sera possible de lancer des tests dans un processus PHP séparés du père, ce qui donnera la possibilité entre autre, de "capturer" ces fameuses erreurs fatales éventuelles, et les reporter.
Plusieurs manières seront offertes : par test unitaire, par classe entière de tests, par suite de tests ou encore de manière générale avec le switch --process-isolation

Vivement ;-)

Encore une faille FaceBook (qui semble les collectionner), entre les dumps SQL (lisez ça c'est adorable), les possibles problèmes de leak et le total contrôle des données, les attaques phishing, les failles HTTP et applicatives ... Allez, quand même pas une XSS ou CSRF dans le futur, si ?
Non, ne m'envoyez pas d'invitation par pitié, je serai au regret de la refuser :'-(

Cette faille (comblée) exploite un paramètre de la requête HTTP afin de pouvoir lister les infos d'un membre les ayant rendues privées.
La vidéo est par là

On voit pas grand chose, si ce n'est l'extension tamper data de Firefox en action.

J'adore cette extension, car taper la requête HTTP dans telnet peut vite virer au casse-tête !
De plus, elle possède tout un tas de patterns XSS ou SQLInjection intégrés ainsi que d'autres options sympathiques.

Je rappelle tout de même que l'on teste avec sa propre sécurité sur ses propres serveurs n'est ce pas ? ;-)
Puis enfin concernant la faille, n'hésitez pas à schématiser votre application et tous ses points d'entrée. Validez les tous. Pour cela vous disposez de plusieurs niveaux : serveur (mod_security de Apache, règles htaccess ...) , hook d'entrée CGI comme l'extension ext/filter de PHP et ses paramètres ini, amont applicatif : objet de requête, ou encore dans les contrôleurs individuellement).

Non, il n'y a pas de coup de gueule sur ce blog ;-)
Les phrases que je rencontre trop souvent "Dis moi avec Zend tu sais faire ?", "Et en Zend ça se fait comment ?".

Rappel au cas où : Zend est une entreprise. Est ce que vous dites "Et toi, tu sais faire ça avec Peugeot ??" , "Non, j'arrive pas à le faire en Sony" - C'est un peu ridicule non ?

Dieu, faites en sorte que j'arrête de lire et d'entendre des phrases dénuées de sens, dont je devine le sens.
Zend est une entreprise, qui propose des produits et des services autour de PHP, pour l'entreprise.
Le Zend Framework (ahhhh ben voila !) est un des produits, il est open source, gratuit, mais piloté par Zend.
Parmi les autres produits, on trouvera Zend Server, Zend Platform, ou encore Zend Studio qui est un IDE permettant d'utiliser le Zend Framework au quotidien.

Zend est le rapprochement de "Zeev Suraski et Andy Gutmans", nos 2 fabuleux programmeurs qui durant leur études ont développé le ZendEngine : le moteur de traitement de PHP, la machine virtuelle si vous préférez, entièrement écrit en C, disponible dans les sources de PHP et interchangeable avec d'autres moteurs (Project Zero de IBM).

C'est plus clair ?

Si vous utilisez encore ext/mysql (les fonctions PHP mysql_*) , soit vous êtes sous PHP4 (vous connaissez donc la solution : PHP5), soit vous êtes sous PHP5, mais supportez une vieille application.

Je rappelle - et Zend vient de fermer le ticket #ZF-5406 confirmant ceci - :
L'extension ext/mysql pour MySQL est vielle, elle est maintenue mais n'est plus développée (enrichie), elle concerne MySQL < 4.1.3. Elle ne fournit pas d'API concernant le traitement des procédures stockées, des transactions, des requêtes préparées. De plus, cette extension ne fournit que des fonctions et aucuns objets, ce qui la rend d'autant moins facilement utilisable.

Citation du manuel PHP :

Qu'est-ce que l'extension mysql de PHP?

C'est l'extension originelle, conçue pour réaliser des applications PHP qui sont en interaction avec une base MySQL. L'extension mysql fournit une interface procédurale, et est destinée à une utilisation avec les serveurs MySQL versions 4.1.3 et plus anciennes. Cette extension peut être utilisée avec les versions de MySQL 4.1.3 et plus récente, mais elle ne pourra pas tirer partie des nouvelles fonctionnalités.

Note: Si vous utilisez MySQL versions 4.1.3 ou plus récent, il est fortement recommandé d'utiliser l'extension mysqli.

Toute nouvelle application devrait utiliser ext/mysqli ou ext/pdo.
La question de la migration d'un existant est épineuse en fonction de l'application, mais si une refonte doit s'annoncer, elle doit commencer par là.
Toute application "moderne" tirera bien des avantages de ext/mysqli ou encore ext/pdo_mysql. Quant à la question de la version de MySQL, aujourd'hui il y a quand même beaucoup de 5.x , même si on trouve encore des 4.x ou 3.x. Même sur ces vieilles versions, ext/mysqli tourne (mais les nouvelles fonctions non prises en charge par MySQL renverront une erreur).

Pour les allergiques à l'objet, ext/mysqli propose une interface entièrement procédurale (et une objet aussi) :-)
De plus, la migration n'est pas très difficile, les API se ressemblant énormément. Voyez plutôt ma présentation à SolutionsLinux

C'est une question qui revient souvent : comment limiter la bande passante en envoi de son serveur ?

Les puristes Unix/GNU-Linux vont vous recommander des outils, comme par exemple iptables ou l'excellent tc permettant de faire du traffic shapping (du QOS de bande passante en gros).

Sans aller aussi loin, si le serveur web est Apache, alors mod_bandwidth est ce qu'il vous faut.
Ce module permet de limiter la bande passante d'envoi d'Apache, de manière poussé :par Vhost, par IP du client, par taille du fichier demandé ...

Documentation de mod_bandwidth