By default now, Cake will automatically use the AppModel class and create a unique alias to a database table if it does not find the file. This means that if you have a table that follows the Cake conventions, needs no validation, and has no associations to other tables, you don't even have to create the model file any more. Woah, talk about a serious time saver in some cases.

He also mentions a gotcha to keep an eye out for - misspelling the model name when you use it. It'll definitely break things. You can find out more about models in CakePHP from this section in their manual, The Cookbook.

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.

I'm an outsider when it comes to tracking the going-on in the world of PHP internals. So, because of that, I'm not going to comment on the actual syntax of how namespaces will be implemented or it's impact on internals. That's not really important as far as this particular discussion goes.

He mentions one of the primary arguments for namespaces from the casual developer's perspective - keeping things separate and so classes can have the same naming as some of their cousins in other namespaces.

Namespaces are potentially coming in PHP 5.3 (does anyone believe?) and people start discussion about how they can even shorten their names from Abstract to aSomething and from Interface to iAnotherthing. I'm a fan of short names. [...] I agree with these rules and am of the opinion that class names must all above anything contain a semantic. Interfaces indicate what you can do with an object, while abstract classes model that different classes have a common base and can be used in the same mannor. And indeed you can add these semantics to names without using the terms.

He gives a few examples, things like Persistable, Configurable and Reflector.

From the first tip:

Don't rely on obscure names to keep your application safe. You should always check permissions, test for vulnerabilities with testing tools and keep an eye on your log files for suspicious activity. When designing your applications and web sites though, don't make it easy for bad people to do bad things. Don't use default or common names for your files and directories.

And from the second:

It's a sad fact of life but users are evil. Users want nothing more than to find a way to exploit your application. As soon as you let your guard down and start thinking "I'm only selling small stuffed animals so how evil can my users really be?" you've lost the battle.

You can catch up on these and the other previous security tips on this page on the Zend Developer Zone website.

We've been together for about five years now. I've had a lot of good times and I've really enjoyed being with you. However, the more we work together, the more concerned I get about our future. I'm sorry, but you don't have the elegance that inspires me to want marry you. I think it's time we broke up.

Some of the reasons given for moving on is PHP's seeming identity crisis, consistency in function names/functionality, and performance issues that were just too much.

Despite being a bit anti-PHP, it's still a well-written piece. Check it out...

By far the most convincing reason to use the file naming convention, which means that a class located in your include path like Foo/Bar/Baz.php is called Foo_Bar_Baz, is the ability to take advantage of PHP 5's __autoload magic method.

The __autoload functionality in PHP 5 is definitely one of the most handy, elegant single lines of code out there and I'd definitely vote for anything that will make working with it even easier. Demian also includes a few lines of example code to show the interaction between the function and the files with the naming convention.

At the request of a listener to past podcasts, Scott created this one to share some of his experiences and findings along the path of his develoopment. Some of the items covered in the podcast include:

• package and library management
• naming conventions
• the seperation of UI and business logic
• code distribution
• using test harnesses

You can download the MP3 of the podcast directly from here.

Exactly one month after the last release, I have uploaded version 0.20.0 alpha. There are lots of changes in this release, but the biggest news is that the page-controller now uses method-based actions (as opposed to file-based actions).

You can read the change notes here, but it's a really long list. If you want something a little more readable, with better narrative, you'll find it after the jump below. The new page-controller information is especially good. However, the narrative is quite long, so consider yourself warned. ;-)

For those that don't want to take the time to read through it all, he summarizes it into six different sections:

• Naming and Standards
• Class Name Changes
• Inherited Config File Values
• Adapter Configuration
• Locale Files
• Page-Controller Class

Each section has its own explaination of the changes made in (a bit) more concise manner. Be sure to check out the full notes to read up on everything.

The article takes a look at several different topics under this one umbrella, including:

• Arguments and return values are extremely inconsistent
• PHP has inconsistent function naming
• PHP has no lexical scope
• PHP has too many functions in the core

Obviously, they all seem to take a negative slant on PHP, but they do provide some content under each of the headings to back up their claims. They break out the contents of each of these examples to make comparison of Perl's and PHP's similar functionality easier. At the end, they also provide links to other resources and other posters illustrating some of the points they've shown.