A new entry has been posted to the PEAR blog with the latest minutes for the group's July 13th meeting.

Some highlights from the meeting include new/upcoming RFCs for package naming schemes, exception handling in PHP 5.3, and a vote on extending the current PEAR2 Policies. Heavy stuff, check it out!

You can check out the full notes here on the PEAR portion of the PHP.net wiki.

The Akelos project has posted a screencast of their framework in action, their answer to the "Creating a blog in 15 minutes" screencast that the Ruby on Rails folks tout so heavily.

This video shows you how to create a weblog engine from scratch using Akelos in just 12 minutes, we implement comments and an administrative interface, so we also had time to cover other Akelos PHP Framework areas.

You can either watch it there on the page or download the quicktime video to watch and learn.

The Akelos project has posted a screencast of their framework in action, their answer to the "Creating a blog in 15 minutes" screencast that the Ruby on Rails folks tout so heavily.

This video shows you how to create a weblog engine from scratch using Akelos in just 12 minutes, we implement comments and an administrative interface, so we also had time to cover other Akelos PHP Framework areas.

You can either watch it there on the page or download the quicktime video to watch and learn.

Edin Kadribasic shares some great news on his blog this morning those using the PHP Windows builds will be happy to hear.

During my time at Emini I was using an old beat up machine to build PHP snapshots for Windows. It was only a Pentium II 400MHz and compiling a PHP snapshot on that machine took more than an hour. After leaving Emini I needed to find a new box for compiling PHP snapshots and PECL extensions for the Windows platform.

The light at the end of the tunnel came when Wez Furlong reminded him about a box OmniTI had that could handle just that. Now, what used to take over an hour to run takes around six minutes (a full compile of the latest snapshot with all of the extensions, including checkout and upload of the Win32 snapshot).

Edin Kadribasic shares some great news on his blog this morning those using the PHP Windows builds will be happy to hear.

During my time at Emini I was using an old beat up machine to build PHP snapshots for Windows. It was only a Pentium II 400MHz and compiling a PHP snapshot on that machine took more than an hour. After leaving Emini I needed to find a new box for compiling PHP snapshots and PECL extensions for the Windows platform.

The light at the end of the tunnel came when Wez Furlong reminded him about a box OmniTI had that could handle just that. Now, what used to take over an hour to run takes around six minutes (a full compile of the latest snapshot with all of the extensions, including checkout and upload of the Win32 snapshot).

Kore Nordman has been making even further advancements in the development behind the PEAR Image_3D library - this time, he looks at raytracing in PHP.

I was always writing, that implementing a raytracer (or the better german description) in PHP would be far to slow. And then, two days ago, I had the feeling I should prove this ... this was also the way Image_3D was born. With the infrastructure Image_3D offers, all the existing models, the abstraction etc. it wasn't such a big thing. You mainly need to write a short algorithm which gets the intersection point for a polygon with a line, and that's it. For sure, you should optimze the algorithm a bit. And it is really fun to implement such a simple mathematical model like raytracing is.

He talks about some of the problems that raytracers don't have that normal renderers do (shadows, reflections, etc) and notes that the images display in the post took about seven minutes to render on his system. He proved that it can work, but notes that it supports his original hypothesis - rendering like this with PHP is just too slow.

Kore Nordman has been making even further advancements in the development behind the PEAR Image_3D library - this time, he looks at raytracing in PHP.

I was always writing, that implementing a raytracer (or the better german description) in PHP would be far to slow. And then, two days ago, I had the feeling I should prove this ... this was also the way Image_3D was born. With the infrastructure Image_3D offers, all the existing models, the abstraction etc. it wasn't such a big thing. You mainly need to write a short algorithm which gets the intersection point for a polygon with a line, and that's it. For sure, you should optimze the algorithm a bit. And it is really fun to implement such a simple mathematical model like raytracing is.

He talks about some of the problems that raytracers don't have that normal renderers do (shadows, reflections, etc) and notes that the images display in the post took about seven minutes to render on his system. He proved that it can work, but notes that it supports his original hypothesis - rendering like this with PHP is just too slow.

In this post on Bitacle.org, they look at a 5 minute approach to finding some of the more common issues with PHP web applications.

Detecting and correcting problems with applications at early stages is an important role of the server manager. Unfortunately, not all errors are detected at the testing stages. Even more unfortunate is the fact that most errors go undetected because they are usually triggered when a certain set of criteria is met.

Since all you have is 5 minutes (which is one of the tenets of this Server management series, and quite possibly the only simple truth in your case), in this installment, we'll unlock the secret of server log foraging.

They mainly make use of grep, a very handly unix command-line tool, to parse through the server logs for answers. Combine that with upping the error reporting level inside of PHP itself, and you should be able to track down most of the problems you'd have. They also include a sample situation or two to watch out for specifically.

In this post on Bitacle.org, they look at a 5 minute approach to finding some of the more common issues with PHP web applications.

Detecting and correcting problems with applications at early stages is an important role of the server manager. Unfortunately, not all errors are detected at the testing stages. Even more unfortunate is the fact that most errors go undetected because they are usually triggered when a certain set of criteria is met.

Since all you have is 5 minutes (which is one of the tenets of this Server management series, and quite possibly the only simple truth in your case), in this installment, we'll unlock the secret of server log foraging.

They mainly make use of grep, a very handly unix command-line tool, to parse through the server logs for answers. Combine that with upping the error reporting level inside of PHP itself, and you should be able to track down most of the problems you'd have. They also include a sample situation or two to watch out for specifically.