In a recent post Freek Lijten shares a simplified version of a solution he came up with to separate models and their logic between the fetch and save operations.

Basically I am wondering how storing data and retrieving data are different and how you should / could model this. Since we need different information while storing and retrieving information it makes sense to model those actions in different ways. The how is still bothering me and in this post I give a possible solution. I truly hope I can get some reactions and thoughts of other people in on how they would solve these kind of problems.

He introduces the basic structure of the application he's working with and how the concept of "documents" ties in. Then he gets into the problem: the differences in data required for the save versus locate and load. His solution is to split out the different pieces (relations) of the document into separate value objects. These objects then only contain the handling to get only the relations needed on the load. He doesn't like the solution, however, because of the amount of overhead it introduces.

On the PHPMagazine.net site there's a new article about PHP user groups and some of the resources that can be used to help find one in your area.

Part of this community a lot of core developers, documentation editors, web application developers, hackers, Quality assurance team, tons of open source projects, PHP UG around the world, and many many other people contributing each one in its category, and even friends and family! Users Group are an active element of the PHP ecosystem, and I believe that everyone should be involved to contribute and keep these UG active around the world.

Some of the efforts that he's pointed out from the past are the phpgroups.org site, phpusergroups.com as well as the sharemymap.com effort to map the groups out. Unfortunately there's no single resource that you can point to that has a full listing.

On his techfounder.net blog today Eran Galperin talks about one of the issues you might currently see with the date validation in your Zend Framework application - a problem in the Zend_Validation_Date component related to its use of Zend_Locale.

Zend_Date tries to validate dates according to a given format (with a default fallback). The dangerous behavior is that it tries to convert the given format to a localized format using Zend_Locale. Zend_Locale attempts to detect automatically the locale of the requesting client, and it appears that on the machines that were exhibiting the bug, a different locale was determined than those I was testing it on.

His problem was when the method tried to parse a non-localized date format and ended up converting it based on the local machine's locale settings. To correct the issue, since he didn't really need the autodetect local feature anyway, he just manually set the locale in his bootstrap via a registry setting.

On LifeHacker.com there's a tutorial on how you can use a simple PHP script running on a remote server to tell Google Voice which is the best phone to forward your calls to. The method requires the use of an Android phone, though.

I figure the only way Google Voice could be improved is if it magically knew where I am and made my phones ring accordingly—so that's exactly what I made it do. You can, too, with an Android phone, the Locale app, and a web server. The overall goal: have Google Voice know which phones to ring, based on your current location or situation.

You'll need a Google Voice account (obviously), some software for your phone and a remote web server running PHP 5 (with cURL and json functionality). You can then use the PHP script by passing parameters as to which phones to turn off and on and use the Locale tool to create the "situations" where it needs to make the switch.

Douglas Brown has posted some hints to help you find errors in your PHP scripts all centered around error reporting settings.

There are several methods to solve errors in PHP code. Sometimes when the user waits to see an output a blank page will be shown if there is an error. To show the errors E_ALL^E_STRICT is used for the PHP 5 version. Contrarily, remaining versions just use E_ALL.

He talks about the log_errors and display_errors settings in your php.ini, the error_reporting function call or a custom error handler as shown in this example from the PHP manual.

On the IBM developerWorks website, there's a new article that works to show some of the benefits of working with PHP code on the command line and some helpful ways to debug the code.

Of course, just the fact that you can use PHP on the command line isn't necessarily the best reason for doing so. However, you might quickly find several pleasant surprises when you first begin to experiment with PHP in this way. [...] In fact, there's really nothing stopping you from using PHP as your Swiss Army knife for almost any given programming project.

They walk through the installation and a sample of the debugging before getting into the more complex methods of finding and fixing errors, using the PHP I/O channels and the creation of your first command-line script (including the use of arguments).

On the IBM developerWorks website, there's a new article that works to show some of the benefits of working with PHP code on the command line and some helpful ways to debug the code.

Of course, just the fact that you can use PHP on the command line isn't necessarily the best reason for doing so. However, you might quickly find several pleasant surprises when you first begin to experiment with PHP in this way. [...] In fact, there's really nothing stopping you from using PHP as your Swiss Army knife for almost any given programming project.

They walk through the installation and a sample of the debugging before getting into the more complex methods of finding and fixing errors, using the PHP I/O channels and the creation of your first command-line script (including the use of arguments).

David Coallier has an update today on the effort to get PEAR developers all over the world mapped out to a Google map to show their locations - one that's finally been launched.

Over the past weeks we have had many people asking around if it would be possible to have a place to see the pear developers around the world. Well now Christian Weiske and I (With the help of Arnaud Limbourg) have put up a nice little map system on pear.php.net. You can see it at http://pear.php.net/map/

David also links to images of some of the administration panels for the application (one, two, three) and the connection information for a web service (REST) that allows access to all of the data.

David Coallier has an update today on the effort to get PEAR developers all over the world mapped out to a Google map to show their locations - one that's finally been launched.

Over the past weeks we have had many people asking around if it would be possible to have a place to see the pear developers around the world. Well now Christian Weiske and I (With the help of Arnaud Limbourg) have put up a nice little map system on pear.php.net. You can see it at http://pear.php.net/map/

David also links to images of some of the administration panels for the application (one, two, three) and the connection information for a web service (REST) that allows access to all of the data.

Etienne Kneuss has an update on the PHPT Generator project posted to his blog, mentioning specifically how it was used to discover documentation problems in the generated phpt files.

The main use of those phpt files was to have an easy way to check examples used in the documentation. Along with a php script analyzing the results and Hannes' great testing environment, I was able to generate a summary of the examples failing.

The results show that over 50% of the documents passed the test, with the rest split between failing because of missing extensions (9%) and because of an error in the example (41%).