Con “solo” qualche mese di ritardo, una nuova puntata del diario di Giorgia dall’Etiopia. E’ di sicuro una delle cose piÃ¹ emozionanti che ho letto da tanto, tanto tempo.
ChissÃ sommando il tempo speso da migliaia di internauti a leggere e commentare tutte quelle news a che cifra astronomica si arriverebbe… Di sicuro IO vorrei indietro il tempo buttato!
Siccome l’unico party parigino a cui finora si Ã© iscritto qualcuno Ã© il 19 ottobre, e io quel giorno sono a Roma, mi sono detto: perchÃ© non provare ad organizzare un incontro nella cittÃ eterna?
I dettagli sono qui: http://slashdot.org/anniversary.pl
I’m excited, happy and proud to start my new job, based in Paris, as an employee of eZ Systems France.
Besides making a great product, the company truly believes in the open source model, and it is even making some money (enough at least to pay my rent!). What else could a php coder ask for?
I am eager to meet my colleagues Ã¼ber hacker Derick Rethans and Tobias Schlitt, whom I first met at the Italian php day last year, and of course the complete staff of the Lyon office, a bunch of young and talented geeks that will surely put my skills to shame.
Btw, for those lazy people that don’t speak italian, the title loosely means “put your money where your mouth is”
This is a very strange topic: even though a cursory google search using the words “multiple php versions apache” spits out a considerable amount of informative howtos and blog entries, when I recently mentioned in a mailing list that it is in fact quite easy to have multiple php installs running in parallel using Apache virtual hosts, I immediately received a private request for my configuration.
Well, here it is, along with a few details on how to set up the complete environment.
The desired goal is having “alot” of php installations running in parallel, so that php scripts can be quickly tested against as many versions of php as possible. It is very useful f.e. when
- you are migrating an existing app from php 4 to version 5
- you are deploying your applications on a large base of servers where different versions of php are installed, but develop all the different apps on the same workstation
- you develop a popular open source php library or shrink wrapped application, and want to make sure that it runs smoothly in every possible user setup
- you want to test an application against different sets of php.ini configurations, to check for possible problems in areas such as output buffering, opcode caches etc…
- you are into integration testing
There are many different setups that can be used to achieve this result (a big list is available on Gentoo docs, courtesy of Andreas Korthaus).
My preferred setup is: use a single apache instance, with a single php version installed as module, and many versions installed as cgi applications. Advantages:
- no need to rename any php file to run it with different php versions
- no need to restart the webserver or run any kind of script to switch php version
- uses less memory than multiple apache installs
The main disadvantages are:
- only 1 php version can run as an apache module, the others must limit themselves to cgi
- a very misbehaved php application can in rare cases hog or crash the webserver, and it will have to be reset before testing with other php versions
The instructions below are geared to a windows environment with Apache 2, but converting them to linux is left as trivial exercise for the sysadmin.
A simple question: why is the word “docbook” always followed by “toolchain” instead of “editor”? Why can’t I just write my documentation in xml as easily as I do with Ms Word and be happy with the results?
The answer is unfortunately not so simple. The core of the problem lies in the flexibility provided by the docbook format. After all, it is an xml dialect, which can be used to write (almost) any kind of technical documentation and produce (almost) any kind of output. Existing graphical editing and conversion tools either cater only to a specific category of documents or suffer from a generic interface that does not introduce significant productivity gains.
What I needed to document my php project was:
- A free (at least as in beer) docbook editor with a decent wysiwyg interface that would not force me to learn the intricacies of every single docbook tag
- some way to automatically convert the docbook file to a nicely formatted XHTML version
- some way to automatically convert the docbook file to a similarly formatted PDFversion
- nice-to-have but not required: php syntax highlighting in the final output, generation of (parts of) the docbook manual from javadoc embedded in the php source code, conversion of docbook to OpenOffice format, etc…
After struggling with a couple of buggy/incomplete editing and conversion tools, being somewhat of a coder myself, I decided to roll my own solution.
Here’s how I set up my toolchain:
Per fare un po’ di pubblicita’ occulta a siti ueb duezero…
E inoltre: il mio cadavere vale $5725, ho 87% nello spelling, 27% di possibilita’ di sopravvivere ad un’apocalisse zombi, 67% di dipendenza dal caffe’ e prenderei 96% in un quiz di scienza a livello di liceo americano…
So long, and thanks for all the fish, err… the great support and fantastic times together!
As everybody in the php world is bound to know, PHP4 is still the dominant platform on the net, despite its age and many shortcomings. Notwhistanding many improvements in speed, security and functionality, PHP 5 has seen so far a less-than-stellar adoption rate.
There have been a lot of discussions in the blogosphere about this “problem”, with the most basic explanation being:
- web hosters do not upgrade because some very successful web apps (blogs, cms, bulletins, etc…) still need php 4 to run
- php coders have to code for php 4 because otherwise they loose the opportunity of getting deployed on shared hosting
- since the apps run on php 4 anyway, why upgrade? (a classic case of dog-eats-tail)
Other people refer to PHP as victim-of-its-own-success: PHP 4 was good enough for everybody, so a lot of people do not feel compelled to upgrade.
While I am generally in favour of extreme ABInex and API stability (I have servers running php 4.0.4, pl1 mind you…), I have to admit that the current situation imposes a heavy burden on the developers of php libraries and applications: the coder has to cater to the quirks and bugs of every possible php version, and either avoid any enhancement that has seen the light roughly in the last 5 years (since the release of php 4.2) or resort to provide alternative code paths for the less-fortunate (the php-compat package on Pear is a great help if you’re into defensive coding).
The best proposal I have seen so far to this situation comes from the Drupal mailing list:
PICK A DATE FOR PHP 4 DESUPPORT AND ANNOUNCE IT TO THE WORLD WITH ENOUGH ADVANCE.
The chosen date has to be agreed upon by most major php application teams (this is the hard part), but most of them, have been planning the upgrade to php5 anyway.
- The hosters and sysadmins at private companies will be given enough time to test the deployment of the new php version
- The developers will feel the need to make sure that their app runs fine on php 5 before the cutover date
- Everybody will be happy (except Stefan Esser, he never is…)
One last question remains open: WHAT SHALL WE CALL THE DAY THAT PHP4 IS PUT TO REST?
Suggestions are welcome…
PiÃ¹ incredibile che vero, il mio luddita, tecnofobico e fissato-con-il-passato genitore (nonchÃ¨ artista mica da poco) mi ha scavalcato a piÃ¨ pari nell’utilizzo del media web, ed Ã¨ atterrato direttamente in google video.
Qui Ã¨ visualizzabile un breve – ma bellissimo – cortometraggio realizzato in occasione di una sua esposizione a Bruxelles, in cui racconta (in francese) la poetica e la visione alla base dei suoi lavori recenti.
RÃ©alisation: BenoÃ®t Dumont – Atelier du Coquelicot asbl
Dopo molti lunghi mesi, ecco finalmente una nuova puntata del diario di Giorgia dall’Etiopia, in cui si parla del mitico biciclown.