Derick Rethans

Xdebug 2.1.0beta2 released

Wed, 03 Feb 2010 18:51:00 +0000

Xdebug 2.1.0beta2 released

Wednesday, February 3rd 2010, 18:51 GMT

I've just released Xdebug 2.1.0beta2 which features a few small bug fixes only. With this release the Windows 5.3/VC6 binaries also return.

One of the bug fixes is in a new feature that allows you to configure that the debugger should connect back to the IDE running on the machine that initiated the HTTP request. This feature, that originally was contributed by Lucas Nealan and Brian Shire of Facebook, allows more easy use of multiple IDEs (users) working on the same code base. In order to enable this, set xdebug.remote_connect_back to 1. See the documentation for more information.

Of course, this feature should only be enabled if nobody besides authorized developers can access the machine on which the xdebug.remote_connect_back callback feature has been enabled. Instead of enabling this setting, you can also support multiple developers through the proxy functionality that the DBGp protocol supports. For more information on that, see Debugging with multiple users.

You can find the full changelog here and get the latest version from the download page.

Speaking at conferences in spring 2010

Tue, 26 Jan 2010 14:22:00 +0000

Speaking at conferences in spring 2010

London, UK

Tuesday, January 26th 2010, 14:22 GMT

In the next few months, I will be speaking at the following conferences:

PHPBenelux Conference 2010 is the first annual conference by the PHPBenelux usergroup. It is organized in Antwerp on Saturday January 30th. I will be giving a keynote titled "The PHP Universe".

PHP UK Conference is PHP London's fifth annual conference and held on Friday February 26th at the Business Design Centre. I will be talking on PHP on the D-BUS.

ConFoo (formerly PHP Québec) is the first edition of the Confoo.ca Conference. From March 10th to 12th 2010, international experts in Java, .Net, PHP, Python and Ruby will present solutions for developers and project managers the Hilton Bonaventure Hotel, located in downtown Montréal. I will be talking on Advanced Date/Time handling with PHP.

Hope to see you there!

Obtaining the next month in PHP

Fri, 08 Jan 2010 09:13:00 +0000

Obtaining the next month in PHP

London, UK

Friday, January 8th 2010, 09:13 GMT

Over and over again PHP users complain that next month in PHP's date-string parser doesn't go to the next month, but instead skips to the one after next month; like in the following example:

modify( 'next month' );
echo $d->format( 'F' ), "\n";
?>

The output of the little script will be March. March obviously doesn't follow January as February is in between. However, the current behavior is correct. The following happens internally:

next month increases the month number (originally 1) by one. This makes the date 2010-02-31.
The second month (February) only has 28 days in 2010, so PHP auto-corrects this by just continuing to count days from February 1st. You then end up at March 3rd.
The formatting strips off the year and day, resulting in the output March.

This can easily be seen when echoing the date with a full date format, which will output March 3rd, 2010:

format( 'F jS, Y' ), "\n";
?>

To obtain the correct behavior, you can use some of PHP 5.3's new functionality that introduces the relative time stanza first day of. This stanza can be used in combination with next month, fifth month or +8 months to go to the first day of the specified month. Instead of next month from the previous example, we use first day of next month here:

modify( 'first day of next month' );
echo $d->format( 'F' ), "\n";
?>

This script will correctly output February. The following things happen when PHP processes this first day of next month stanza:

next month increases the month number (originally 1) by one. This makes the date 2010-02-31.
first day of sets the day number to 1, resulting in the date 2010-02-01.
The formatting strips off the year and day, resulting in the output February.

Besides first day of, there is an equivalent last day of to go to the last day of a month. The following example demonstrates this:

modify( 'last day of next month' );
echo $d->format( 'F jS, Y' ), "\n";
?>

This outputs February 28th, 2010. Internally the following happens:

next month increases the month number (originally 1) by one. This makes the date 2010-02-08.
last day of increases the month number by one, and sets the day number to 0, resulting in the date 2010-03-00.
PHP then auto-corrects the invalid day number 0 by removing one from the month and skipping to the last day of that month, resulting in 2010-02-28.

I hope this clears up some of the behaviour of PHP's Date/Time handling. For more information on Date/Time Programming with PHP, please refer to my book "php|architect's Guide to Date and Time Programming" that is available through Amazon.

Xdebug 2.1.0beta1 released

Sun, 03 Jan 2010 02:08:00 +0000

Xdebug 2.1.0beta1 released

London, UK

Sunday, January 3rd 2010, 02:08 GMT

It has been two years since I released Xdebug 2.0.0. Since then I've added many new features to Xdebug. For some of those new features you can find a little description below—I will write more about these, and other features later.

Besides the features, I also fixed a whole array of bugs and Xdebug 2.1.0 comes with PHP 5.3 support. From now on I will not be supporting any PHP versions less than PHP 5.1 anymore. But now on to the descriptions:

Header Setting Interception

All functions that set HTTP headers such as with header() and setcookie() are now intercepted by Xdebug. The intercepted headers are stored internally in an array that can be retrieved by calling the xdebug_get_headers() function. This is very useful in cases where you need to test certain functionality that sets headers somewhere deep in code. This function is also used in eZ Components' test suite to test whether the correct HTTP headers are set in the MvcTools component.

Variable Assignment Tracing

Allows you to record changes to variables in scripts to trace files. I've already written more about it in Variable tracing with Xdebug.

"Scream" Support

The scream PECL extension disables the @ (shut-up) operator to actually see all notices, warnings and errors that PHP generates. The scream extension's functionality have been duplicated as Xdebug's xdebug.scream php.ini setting. Why disabling the @-operator is a good thing, I've already outlined in Five reasons why the shut-op operator (@) should be avoided.

What's Next?

There are still a few bugs left that need some attention, but this first beta should have most of them fixed. Please test the beta as much as you can and provide feedback in the issue tracker. After this initial beta it is like that one more more betas will follow before I prepare a release candidate. Xdebug 2.1.0beta1 can be obtained through the Xdebug website and a full changelog is also available. You can also follow Xdebug on twitter to be kept up-to-date with the latest developments.

PHP Development Environment 2.0

Thu, 31 Dec 2009 02:26:00 +0000

PHP Development Environment 2.0

London, UK

Thursday, December 31st 2009, 02:26 UTC

When moving the Xdebug website and my own website to a new server I had to pick a web server to serve the pages through PHP. Up to then I was still using Apache 1.3 with zero intentions to ever upgrade to any later version. I'd heard a lot about lighttpd and decided to give that a try—yes, that meant something that I didn't really know to well was going to run in a production environment. Unlike Apache, with lighttpd PHP doesn't run as a module, but instead you run it out of process with something called FastCGI.

On my development machine I was also running Apache 1.3 with PHP as static module embedded. If I want to test something with a different PHP version, I would start a different Apache daemon. When I had a quick look the other day, I found that I had about 28 different binaries named httpd-{Apache version}-{PHP version} ranging from PHP 4.1.2 to 6.0dev. Some of those I hadn't used for years.

All my PHP installations were installed with the same prefix (/usr/local), where the last built PHP version was available as php and additional versions as php-{version}. An annoyance with this is, is that I had to run make install in one of the PHP source directories before I could compile extensions against a different PHP version than the latest installed one. This combined with the enormous amount of httpds and the inability to run multiple versions of PHP at the same time prompted me to come up with something better: PHP Development Environment 2.0.

Multiple PHP Installations

The first thing I wanted to do was to make sure that each minor PHP version (5.1.x, 5.2.x, 5.3.x and 6.0.x) could be installed alongside each other, and that I could compile extensions to all of them without having to re-run make install. I did this by specifying --prefix=/usr/local/php/{PHP version} to the PHP configure call. At the same time, I also removed the --with-apache configure option and for PHP 5.1 and PHP 5.2 I added the --enable-fastcgi option which is default enabled for PHP 5.3 and PHP 6.0. The initial section of the configure invocation now looks like for the PHP 5.2 build:

./configure --prefix=/usr/local/php/5.2dev --enable-fastcgi \
  --with-gd  ...more configure options here...

Although /usr/local/bin is usually in the path, but /usr/local/php/5.2dev/bin is definitely not. The initial goal was to be able to easily switch between different PHP versions, so I added a snippet to my .bashrc that sets the correct PATH environment variable depending on the selected PHP version:

function pe () {
  version=$1
  shift

  if [ "$#" == "0" ]; then
    export PATH=/usr/local/php/${version}/bin:/usr/local/bin:/usr/bin:/bin
  else
    PATH=/usr/local/php/${version}/bin:$PATH $@
  fi
}

This bash function is then evoked like pe 5.3dev to set the path in such a way that php runs the PHP 5.3 binary, as well as additional tools such as pear, phpize (required to build extensions) and php-config. If you forget to call the pe function, then when running php you will encounter the warning bash: php: command not found. You could pick a default version if you wanted, but I prefer that I always have to be explicit about which PHP version I pick. Multiple install paths makes it easier to maintain multiple PHP installs, but it also means that you have to install tools such as PHP Unit for each of the installations.

Setting up Lighttpd

Now that I had multiple PHP installations, I could move on to setting up lighttpd. As I have mentioned, I never used lighttpd before and decided to take the easy way by installing it with apt-get install lighttpd. PHP works through the FastCGI interface with lighttpd which you can enable with lighttpd-enable-mod cgi fastcgi simple-vhost (I also enabled CGI and simple VHOSTing).

To enable PHP as FastCGI server, and to be able to run multiple versions at the same time, I modified the /etc/lighttpd/conf-enabled/10-fastcgi.conf configuration file. Find my annotated version below:

## Enable the FastCGI module.
server.modules   += ( "mod_fastcgi" )

Next we start an FastCGI server for the default PHP version (5.3) on the default port (80) by enabling it in the global scope:

fastcgi.server    = ( ".php" =>
  ((
    ## The path to the PHP-CGI executable
    "bin-path" => "/usr/local/php/5.3dev/bin/php-cgi",

    ## The listening socket that allows lighttpd to talk
    ## to the PHP FastCGI process. This needs to be
    ## different for each fastcgi.server definition.
    "socket" => "/tmp/php80.socket",

    ## Configure the number of parent processes that are
    ## spawned by lighttpd (max-procs) and configure how
    ## many many workers should be started (4) and the
    ## maximum number of requests that they can process
    ## before they get recycled (10000).
    "max-procs" => 1,
    "bin-environment" => (
      "PHP_FCGI_CHILDREN" => "4",
      "PHP_FCGI_MAX_REQUESTS" => "10000"
    ),

    ## configure additional bits
    "bin-copy-environment" => (
      "PATH", "SHELL", "USER"
    ),
    "broken-scriptfilename" => "enable"
    "idle-timeout" => 20,
  ))
)

Now tell lighttpd to also listen on port 8502. And in case requests come in over this port, use the defined FastCGI server for *.php. In this case we configure PHP 5.2. Similarily you can also define a block for PHP 5.1 (on a suggested port 8501) and PHP 6.0:

$SERVER["socket"] == ":8502" {
  fastcgi.server    = ( ".php" =>
    ((
      "bin-path" => "/usr/local/php/5.2dev/bin/php-cgi",
      "socket" => "/tmp/php8052.socket",
      "max-procs" => 1,
      "idle-timeout" => 20,
      "bin-environment" => (
        "PHP_FCGI_CHILDREN" => "4",
        "PHP_FCGI_MAX_REQUESTS" => "10000"
      ),
      "bin-copy-environment" => (
        "PATH", "SHELL", "USER"
      ),
      "broken-scriptfilename" => "enable"
    ))
  )
}

Tell lighttpd to also listen on port 8502. Because we're not overriding the fastcgi.server configuration from the global configuration (the bit were we set-up PHP 5.3 in the first few lines of the file), it will reuse this fastcgi.server configuration enabling requests for .php files coming in on port 80 or 8503 to be processed by the globally configured FastCGI server:

$SERVER["socket"] == ":8503" {
# Just some dummy text because lighttpd doesn't allow
# empty definitions.
}

With the configuration made, you only have to restart lighttpd with /etc/init.d/lighttpd force-reload and PHP is ready to go on multiple ports with different PHP versions.

New website layout

Sat, 26 Dec 2009 15:13:00 +0000

New website layout

London, UK

Saturday, December 26th 2009, 15:13 UTC

Just like Xdebug's server was moved 1 to a new VPS at XtraHosting so did my personal website (the one you're looking at). Hosting it on my own gives me full control over what software runs it, and which PHP version and extensions I run. I switched most of the code from a PHP 4.1 atrocity to PHP 5.3 goodness.

At the same time, I also moved all the contents from some self-invented XML format to reStructuredText. reStructuredText is a format that can be parsed and transformed into other formats by eZ Components' Document component. Right now I am transforming to HTML only, but in the future I will also transform certain articles to PDFs. Comments can also make use of some of the reStructuredText formatting options, but there are still some things that need sorting out there.

Besides changing the layout and converting the content to a more manageable format, I also introduced a stream of dopplr, flickr and twitter updates on the right side. This is implemented by parsing the relative RSS feeds from the different sources. If location information is present, this is also shown in this feed. Previously I would only export an RSS feed for all of the content, but with this site update, there is now a feed for every tag that I've used. All RSS functionality is provided by the Feed component of eZ Components (although a patch is currently needed for the location information).

I'm not a 100% happy with the new layout, so most likely I will be doing some changes in the near future.

1
http://derickrethans.nl/xdebug-moved-to-a-new-server.html

Xdebug moved to a new server

Fri, 27 Nov 2009 14:42:00 +0000

Xdebug moved to a new server

London, UK

Friday, November 27th 2009, 14:42 GMT

Xdebug 's CVS server was previously hosted at eZ Systems' office, but as I am leaving soon I needed to move this to a different server. At the same time, I decided to also convert from CVS to SVN. So from now on, there is no more cvs.xdebug.org, but just a svn.xdebug.org. This SVN server doesn't only host Xdebug, but also some of my other projects, such as VLD (opcode dumper to aid PHP engine development), the DBGp specs (debugger protocol as used by Xdebug and ActiveState's debuggers) and my OpenMoko perversions and projects.

Xdebug can now be checked out from SVN with:

svn co svn://svn.xdebug.org/svn/xdebug/xdebug/trunk xdebug

All other Xdebug services (mailinglists, web, e-mail and the bug system) moved to the same server as well. Just be aware that DNS servers might still need updating when you try to access the new services.

Xdebug and tracing memory usage

Fri, 13 Nov 2009 11:59:00 +0000

Xdebug and tracing memory usage

London, UK

Friday, November 13th 2009, 11:59 GMT

Recently people started to ask me how to use Xdebug to figure out which parts of applications use a lot of memory. Traditionally this was part of Xdebug's profiling functionality. Unfortunately the cachegrind format didn't fit this so well, and because it returned incorrect data I removed this functionality from the profiler. However, there is other functionality in Xdebug that does provide the correct data: the function traces.

Function traces log every include, function call and method call to a file. If the xdebug.trace_format setting is set to "1" then the trace file is an easy-to-parse tab separated format. The information that is logged includes the time-index when the function started and ended, and it also contains the amount of memory that was in use when entering the function, as well as when leaving it. With the last two numbers it's rather trivial to write a script to figure out which functions/methods increase the memory usage a lot. Of course, nobody had written a script yet to do anything with this information

As part of my preparations for my Xdebug talk at IPC next week, I now have written such a script. The script parses the tab-separated function trace files and aggregates all the information by function name. You can sort the output on a few different keys: time-own, memory-own, time-inclusive, memory-inclusive and calls. You can also configure how many elements it will show. As an example here is some output from a trace of one of the presentation system's PHP scripts:

$ php tracefile-analyser.php trace.2043925204.xt memory-own 20

parsing...
Done.
Showing the 20 most costly calls sorted by 'memory-own'.
                                               Inclusive        Own
function                               #calls  time     memory  time     memory
-------------------------------------------------------------------------------
require_once                                9  0.0541  4595160  0.0277  2548104
{main}                                      1  0.0600  2906032  0.0034   249744
fread                                       4  0.0001    33296  0.0001    33296
session_start                               1  0.0002    31824  0.0002    31824
XML_Presentation->startHandler             38  0.0073    36360  0.0035    18424
_pres_slide->_pres_slide                   27  0.0009    10152  0.0009    10152
_presentation->_presentation                1  0.0001     7912  0.0001     7912
strtolower                                 67  0.0017     6456  0.0017     6456
compact                                     1  0.0000     4832  0.0000     4832
each                                        5  0.0001     4320  0.0001     4320
XML_Presentation->endHandler               38  0.0014     3800  0.0014     3960
_slide->_slide                              1  0.0001     3896  0.0001     3896
XML_Slide->startHandler                     4  0.0009    10800  0.0004     3736
_image->_image                              1  0.0000     3040  0.0000     3040
fopen                                       2  0.0001     2816  0.0001     2816
getimagesize                                1  0.0001     2296  0.0001     2296
display->display                            1  0.0001     2120  0.0001     2120
explode                                     2  0.0001     2120  0.0001     2120
xml_parser_create                           2  0.0001     1680  0.0001     1680
XML_Parser->_initHandlers                   2  0.0011     1600  0.0005     1360

The script is available from SVN by running:

svn co svn://svn.xdebug.org:/svn/xdebug/xdebug/trunk/contrib xdebug/contrib

The script to run is then "tracefile-analyser.php" from inside the "xdebug/contrib" directory.

Update 2009-12-28: Changed the CVS instructions to the new SVN instructions.

Unix Epoch and PHP's calendar system

Thu, 12 Nov 2009 12:32:00 +0000

Unix Epoch and PHP's calendar system

London, UK

Thursday, November 12th 2009, 12:32 GMT

I just saw a commit flying past as a response to PHP bug #50155. While right now it is proper to define the Unix Epoch at "1970-01-01 00:00:00 UTC", UTC wasn't actually defined until 1972. So it would be more correct to define the Unix Epoch as "the number of seconds elapsed since midnight proleptic Coordinated Universal Time (UTC) of January 1, 1970, not counting leap seconds." (from Wikipedia). What the bit "not counting leap seconds" means, I've already explained before in Leap Seconds and What To Do With Them.

Similarly, PHP's internal calendar is the ISO 8601 calendar. This is a modification of the proleptic Gregorian calendar. The Gregorian calendar implements the current set of leap years every 4 years, but not every 100 years, but again every 400 years (to get to an average year length of 365.2425 days). Obviously this calendar is only in use since 1582 (some countries adopted it as late as the 1900s), so using days like 1066-10-14 in the Gregorian calendar makes little sense because that calendar didn't exist back then. Now, PHP's ISO 8601-based calendar even modifies the Gregorian calendar by including the year 0. The Gregorian calendar goes straight from -1 to 1 which is a pain to do proper date calculations with. Therefore the ISO 8601 calendar uses Astronomical year numbering.

Good bye eZ Systems

Tue, 27 Oct 2009 10:36:00 +0000

Good bye eZ Systems

London, UK

Tuesday, October 27th 2009, 10:36 GMT

During the past 6 years I've been working as a developer for eZ Systems — first as a developer on eZ Publish and later as project lead for eZ Components. Working on a project like eZ Components as lead was challenging and interesting and taught me many things. eZ Systems as a company is changing a lot, and now the time has come for me to move on and find something new and exciting to do. I've recently moved to London to explore life from a different point of view, and that will now also include a search for a new challenge professionally. I will still be with eZ Systems for awhile longer to finish the next eZ Components release. If you think you can provide me with a new challenge, feel free to contact me.

CodeWorks and ZendCon

Mon, 19 Oct 2009 04:46:00 +0000

CodeWorks and ZendCon

London, UK

Monday, October 19th 2009, 05:46 BST

CodeWorks was a blast, I recorded a few talks that I will be publishing through Vimeo. As teaser I have a recording of Scott MacVicar's PECL picks talk. I also have recordings of Brian Moon's Memcached talk, Chris Shiflett's Security-Centered Design talk and Sharon Levy's Web-Based Retrieval Demystified talk. With all the other random video material I am creating a compilation as well, but that will have to wait a bit more.

At the moment I am on my way to San Jose where I will speak on Xdebug and PHP's DateTime support. Xdebug 2.1 is now feature complete, and I will be working on getting all the open bugs resolved. A release before the end of the year seems likely.

Autumn Plans

Mon, 14 Sep 2009 12:26:00 +0000

Autumn Plans

London, UK

Monday, September 14th 2009, 13:26 BST

I've been missing-in-action on my own blog for some time. Moving to London does that to you. Anyway, I've not been idle in the meanwhile at all, and been working on some cool side-projects. First of all I've been adding some features to Xdebug . Xdebug is now slow reaching beta-status for the 2.1 release. New feature will include proper PHP 5.3 support, variable tracing, "scream" support and other minor features.

Besides Xdebug I've also been hacking on PHP-GTK applications for my phone . The major new thing that I have now is a PHP-GTK twitter client that works like I want it... and I even use it on my desktop instead of all the other stuff that's out there. I will soon be publishing this client in my CVS repository.

Now that the conference season is starting again I'm working on improving several talks, as well as rewriting some parts for them. The first conference that I will be speaking at, are part of "Marco's Crazy PHP Conference Tour" aka CodeWorks . I'll be giving three different talks here, one on "Debugging with Xdebug ", one on PHP's DateTime support and one on "Improving your development process" where I'll be talking about Test-Driven Development and other tricks associated by running a project. As CodeWorks is a bit like a rock-star tour, I'll be keeping a video blog of it somewhere on the intertubes.

Good bye Norway, Hello London

Sun, 21 Jun 2009 00:32:00 +0000

Good bye Norway, Hello London

Skien, Norway

Sunday, June 21st 2009, 02:32 CEST

Today, at the longest day of the year at the summer solstice , I am making a bit change to my life. If you're following me on twitter you probably already know what I'm up to. For everybody else, I am going to say good bye to Skien in Norway, and move to London (the one in England, and not the one in Ontario). Norway has been my home for the past five years, and I've had a great time exploring the nature as well as working at our office in Skien . Skien is a nice place, but ... not the most interesting of cities in the world. From today I will be living in London to see what life will bring me there. I am both sad to leave Norway, but I am also excited to live in a cool new place like London. I'll have awesome house mates (Hi, Mr. Þorbjörnsson, Ms. Cherry and Mr. Ray!!), and something new to put my energy in. I will continue to work as project leader for eZ Components for eZ Systems and continue to make great software with Alexandru, Tobias , Kore and Sebastian . If you are about in London, let me know! We could go for a pint or something. See you there!

Debugging with multiple users

Thu, 11 Jun 2009 08:47:00 +0000

Debugging with multiple users

Amsterdam, the Netherlands

Thursday, June 11th 2009, 10:47 CEST

As author of Xdebug, people ask me often the question how to handle the case in teams when there is one development server and multiple developers working on the same project on that server. Xdebug only allows you to specify one IP address to connect to (through xdebug.remote_host ) while doing remote debugging. It does not automatically connect back to the IP address that runs the browser the request the PHP scripts because of security reasons. You don't want everybody on the Internet to be able to run a debugging session against your code for example. There is no problem if all developers are working on a different project, because the xdebug.remote_host setting can be made for each directory (through Apache's .htaccess functionality). However, for the case where multiple developers work on the same code, the .htaccess trick won't work as the directory in which the code lives is the same.

Now, in order to solve the above mentioned issue, you will need to run a DBGp proxy. DBGp is the protocol, designed by ActiveState and myself to facilitate communication between an IDE (such as Komodo, or any of the other listed clients ) and PHP+Xdebug. A DBGp proxy is a bit of software that acts as a redirector for DBGp streams. In order to make things work for multiple developers and one source base, you set Xdebug's xdebug.remote_host setting to the machine on which the DBGp proxy runs. This is most likely going to be on the same machine that acts as development server, so that the xdebug.remote_host setting should be set to "127.0.0.1" (i.e. localhost). The proxy server the listens for IDE connections. An IDE needs to register itself with the DBGp proxy by using the proxyinit command. This command requires an "idekey" that is a unique identifier for each client (IDE). Every developer should have its own unique idekey (I usually just pick my name), and this idekey should be configurable in the IDE. For Komodo, it's at Edit->Preferences->Debugger->Connection->"I am running a debugger proxy and Komodo should use it"->"Proxy Key". In Komodo you also need to select "a system-provided free port" in the same configuration panel. When initiating the debugging session from the browser with either XDEBUG_SESSION_START=session_name as GET/POST/COOKIE parameter, or export XDEBUG_CONFIG="idekey=session_name" from the comment line, make sure to change "session_name" to the idekey as configured in your IDE. (See the documentation on how to set this up). The Xdebug Firefox extension also has a setting for this. You have to configure Xdebug's xdebug.remote_host setting to the IP address of the machine that the proxy runs at. Xdebug itself does not see a difference between either the proxy and a normal IDE. But the proxy itself now knows because of the configured idekey on how to forward the requests and responses to the correct client.

You can find the DBGp proxy code as part of the python remote debugging package that ActiveState provides. By default it listens for IDE registrations at port 9001, and for Xdebug connections at port 9000. To run the proxy, do:

tar -xvzf Komodo-PythonRemoteDebugging-5.1.3-28369-linux-x86_64.tar.gz
cd Komodo-PythonRemoteDebugging-5.1.3-28369-linux-x86_64
cd bin
./pydbgpproxy

This outputs:

INFO: dbgp.proxy: starting proxy listeners.  appid: 30430
INFO: dbgp.proxy:     dbgp listener on 127.0.0.1:9000
INFO: dbgp.proxy:     IDE listener on  127.0.0.1:9001

Running a DBGp proxy also allows you to avoid NAT issues where (as seen from PHP+Xdebug on the server) all connections seem to come from the same IP (because your internal network is NATted). In this case, you can simple run the dbgp proxy on your NAT machine, configure xdebug.remote_host setting to the IP address of your NAT machine, and configure the IDEs to connect to the proxy running at :9001.

As a last note; there is a patch to allow the connect-back-to-requesting-IP-address functionality that is not available directly in Xdebug. This patch, written by Brian Shire and Lucas Nealan of Facebook made its way into Xdebug 2.1. However, great care should be taken by using this functionality. It does not make the NAT situation as outlined above work however.

php|architect's Guide to Date and Time Programming

Wed, 03 Jun 2009 19:06:00 +0000

php|architect's Guide to Date and Time Programming

Skien, Norway

Wednesday, June 3rd 2009, 21:06 CEST

In the past year I've been working on a book, describing PHP's Date and Time functionality in great detail. It's now finally out under the name " php|architect's Guide to Date and Time Programming ". Look at the pretty cover! It's actually a picture I took some months ago from the church in Skien , where I am still living (more about that in a later post).

The book is devoted on helping you understanding dates and times, as well as how PHP deals with it. It explains how PHP parsers and reads dates and times in strings including possible pitfalls; timezones, their history, the annoyances and how to deal with them properly; formatting and displaying dates and times; and last but not least, how to handle intervals and iterating over time. There is more information on the website where you can also buy this awesome book. And in case you're wondering "what? dates and times are really simple!", then this book is definitely for you.

Rumour is that all attendees of the Dutch PHP Conference will receive a copy with their tickets, if you're asking nicely I might even sign your copy! I'll be there to give a talk on "PHP on the D-BUS" and will show you how to talk to skype, GSM chips and other desktoppy things!