In his latest post Pádraic Brady looks at a new addition to PHP (well, to be included in the next release) related to the SSL/TLS handling it provides in streams. He's happy to report that things are improving. This commit integrated an RFC allowing for TLS perr verification in PHP streams.

The RFC reverses PHP’s course and provides PHP streams with defaults that enable both peer verification and host verification. The patch implements the RFC and it lets PHP leverage the local system’s own certificate stash (e.g. Debian’s ca-certificates) where possible to avoid PHP having to distribute a bundle of its own and while also assisting in backwards compatibility. [...] Once we have a PHP streams/sockets system with a passable level of default security, the rest will be left to programmers on the ground to change their practices.

With this new functionality coming in PHP 5.6, he strongly encourages developers to change how they're currently doing things and embrace this new verification to keep their code safer.

PHPMaster.com has a new article about a practice that's becoming more popular in recent years to help increase the quality of code that comes out of development - code reviews.

Every developer knows the pain of banal mistakes. A wrong attribute here, a misspelled property there, an accidentally duplicated line of code which you missed because of the coffee-fueled 16 hour hackathon you’ve been on. [...] Code review is simply the act of having someone else look at your code to find the mistakes you missed.

The tutorial talks about the types of code reviews (three of them with varying levels of involvement) as well as some best practices to follow in your reviews like:

• Know your common mistakes and actively fight them.
• Peer code review means being reviewed by someone of equal or greater skill.
• Collect metrics.
• Be mindful of the social aspect – finding bugs is good, not bad!

In the latest post to his blog Chris Roane looks at something that, while not generally considered a good thing, can help to make your development and work better - peer pressure.

When you are held responsible to other people and when you are in an environment that has competition, that not only helps the company as a whole, but it allows for more individual growth. In the typical corporate atmosphere, accountability and competition can be lost because no one really knows anyone else. But the other side of this, in extra small companies, you can have too much accountability...where every move is constantly watched.

He notes that, without the pressure of peers - ones that you really know and that really know you and your work - the quality of the applications written degrades in most situations. Sure, there'll be the one or two developers that are extra motivated, but without the real interaction with other skilled developers, innovation can quickly fade.

Brandon Savage's latest post in his "Peer Review" series has been added to his blog today. This time he focuses on the requests and responses - modifying the sample code to make it more testable on how things are quested and the responses they give back.

There is one last area that I want to address, and this has everything to do with object-oriented principles and code reusability. For those who are familiar with OO programming, they realize that the use of classes does not make something object oriented by nature. In this final part of the series, we’ll move one step closer to being object-oriented, by introducing the concepts of request and response objects.

He changes up the Twitter object to take in a HTTPRequest object (instead of creating one by itself) and to use exceptions and a "Twitter response object" to encapsulate any responses from the service making it much easier to work with and understand than just a true/false return.

In this latest post in his "Peer Review" series Brandon Savage looks at things that can make the sample code he's been working with easier to test.

Now that we've worked out the abstraction issues and the logic questions, we should take a moment to focus our attention on a few of the issues relating to the architecture and testability of the class we've worked out.

He mentions changes to a call to get_included_files, a bit of code requiring magic quotes, and changes to the code to make writing using tests simpler (like injecting objects rather than creating them and writing a unit test every time a bug is found so it doesn't happen again).

Brandon Savage has posted the fifth part of his "Peer Review" series where he's taken a sample application and worked it over - refactoring, updated to meeting coding standards and abstracting out interfaces to simplify the code. In this latest article he looks at a method to improve the business logic behind the scenes.

So far, we’ve done quite a bit of work on our Twitter class, making it better. There’s still work to be done, though, especially improving the logic. The Twitter class we have now has a number of logical flaws in it that we need to address. Additionally, there are some logical flaws that we started with that I want to highlight, even though we’ve already fixed them. Let’s get started with those.

He looks at a few things like setting the host name as a property, using the return of the HTTP request and handling exceptions (like when Twitter's down). The resulting code is included.