LiveHTTPHeaders for Firefox
Live HTTP headers is a FireFox extension that lets you look at all HTTP headers for all requests issued by the browser. Now updated for Firefox 1.5.
2 connexions ADSL simultanées
Voilà un truc qui m'énerve depuis un bout de temps: au bureau on a 2 connexions ADSL: une chez Free et une chez Wanadoo. Bien évidemment, aucune des deux ne fonctionne correctement de manière inintérrompue entre 9h et 23h.
La solution pro serait d'avoir un routeur qui route entre les deux.
La solution "cheap" qu'on a ici consiste à brancher chaque poste sur les 2 réseaux par l'intermédiaire de 2 cartes réseau (sachant que les cartes mères arrivent maintenant avec une ou 2 interfaces réseau intégrées, ça ne revient vraiment pas cher).
Reste que Wanadoo est encore moins fiable que Free et que Windows semble insister pour passer par Wanadoo même quand il marche pas (ou mal...).
Jusqu'ici j'allais dans Paramètres > Connexions Réseau et je désactivais le réseau Wanadoo tant que je n'en avais pas besoin. Mais ça commençait à devenir un peu pénible...
En cherchant un peu aujourd'hui, je crois que j'ai trouvé un truc qui devrait faire l'affaire: Propriétés de la connexion Wanadoo > Propriétés TCP/IP > Avancé . Là, je décoche "Métrique automatique" et je mets "Métrique de l'interface: 100".
A priori ça devrait clairement indiquer à Windows: "n'utiliser cette connexion qu'en dernier recours, si aucune autre route moins couteuse n'a été trouvée".
En tapant route print en ligne de commande, ça à l'air de faire ce que je veux, mais je vais voir à l'usage si ça rend la double connexion plus cool...
Rasmus: "I don't like SOAP"
At PHP Forum, Rasmus wisefully explained that SOAP is intrinsically broken because it's too complex... just as anything that takes more than 20 minutes to understand.
When it comes to webservices, I myself tend to prefer XML-RPC ("Does distributed computing have to be any harder than this? I don't think so.")... and sometimes I wonder wether REST would be a nice alternative...
PHP: why use DOM/XML writer functions?
There's one thing I was wondering about: why would you actually want to use the DOM/XML writing functions of PHP to generate XML? I mean: we've been generating HTML without specific functions for over 10 years, so why would we need a library to build a DOM tree instead of outputting XML directly??
Well... I got an answer at PHP Forum: it makes sure your XML is well formed when you spit it out!
Ha! I should have thought about it! :roll:
Now I'm wondering if I should be using this as a replacement for echo in order to make sure I generate well formed XHTML all the time... ;) I mean... generating a DOM tree would be overkill, but generating the XHTML code on the fly with XMLwriter might actually work out pretty well...
Hum...
Cacheing built into PHP?
The PHP Core Team is meeting this week to decide wether or not there should be some cacheing built into the next major release of PHP. (I guess that would be PHP 6).
I definitely hope the answer will be YES since this has been available on others platforms for ages (J2EE, ColdFusion, ASP...) and it's really missing when you want your app/site/service to scale to large numbers of users.
Furthermore, once they decide to include cacheing, they still have to decide which cache technology they'll build in.
There are many add-ons/plugins to PHP which do cacheing, but it's important to keep in mind that there are actually 3 different kinds of cacheing involved here:
- Cacheing the .php files in memory, so you don't access the disk everytime you include _header.php!
- Cacheing the compiled opcode for those files, so you don't have to recompile them all at *each* request!
- Cacheing arbitrary data from inside the script, so you can reuse it on subsequent requests without recomputing everything
There is one PECL extension that manages all of these 3 cacheing forms: APC. (Note: precompiled for Windows here). I'll bet on that one! Not only because I think it's doing the job as it should be done (easy setup, clean function syntax and everything), but also because Rasmus is already involved on that one's development team! ;)
Anyway, I think it's really important for PHP to standardize on some cacheing mecanism so we can design our applications to take advantage of it, no matter what host you'll be running it on.
The main reason we don't yet use shared memory data cacheing in b2evolution, is precisely because there is no standard that will be broadly available on hosts. Of course, we could still have included our own PHP class writing cache files, but that's bound to be less efficient than shared memory cacheing!
[Edit: the big 'no' argument to including cacheing would be that because APC uses shared memory, it kind of breaks PHP's "shared nothing" architecture. With shared memory it is so much more likely that a small error will corrupt something that might eventually cause a larger crash... So, be bottom line is that introducing a shred memory architecture introduces a potential weakness, do we want that?]
