Anthony Ferrara has a new post today looking at password hashing and a type of hashing that's beginning to get more attention in the PHP community - scrypt. However, he doesn't recommend it for production password storage and shares his reasoning why.

Scrypt was not designed for password storage. It was designed as a key derivation function for generating keys from weak material (namely passwords). The prime type of attack that scrypt is designed to defeat is ASIC based attackers. It is not designed to try to favor CPU over GPU (and thereby defeat GPU based attacks). It is this fact that we can leverage to gain an advantage when used as a password hashing mechanism.

He covers some of the basic design decisions that were made when scrypt was created. He also points out that none of the results of these decisions are strictly fatal, they just make it a bit weaker than something like bcrypt for password storage. He goes through the basic inputs scrypt requires and includes a quick snippet of code (not PHP, but easy to understand) showing its use. He talks about its "chain of 4 operations" and gets into what he sees as limitations: loop unrolling and the tune-able reduced memory usages. He finishes off the post mentioning that scrypt is still secure, but despite this he doesn't recommend it for password storage specifically.

On the Web Builder Zone today Gorgio Sironi asks you, the larger development population of the web, what framework would you use today to start a new application?

One of the difficult parts of framework adoption, especially in the PHP world, is about choosing the right framework. There is a proliferation of open source solutions and a team must analyze the overall picture thoroughly before locking itself into a particular framework. Changing the framework which an application is built with without shaking its foundations would be probably impossible after a certain period of development.

He lists a few of the things he looks for in a framework - functionality, performance, community and a good license - and asks for some feedback (in the form of a poll) as to which you'd prefer to use next. He's narrowed it down to four options: Zend Framework, Symfony, CodeIgniter and CakePHP. (Expect plenty of comments asking "what about [insert framework here]?")

Recently Mike van Riel posted a review to his blog of an IDE that's growing in popularity - PHPStorm.

During my career as a PHP developer (hobbyist and professional) I have tried a multitude of IDEs and tools to write code in. Every IDE I have found thus far did great things but had their downsides. It is with phpStorm that I can send at least some of those problems to the past. [...] Having gotten that little push by MissYeh I decided to take a look at that new shiny IDE and found a true gem! phpStorm offers so much more than Netbeans and Eclipse in terms of performance, memory but also functionality.

He talks about some of his favorite features - native git support, a method usage search, more advanced docblock parsing and the ability to view "blame" information right in the IDE. He does note two things to keep an eye out for - the fact that it's still in beta and that, once it's fully released, it won't be free.

If you're a developer out there and are looking for that next job (contract or otherwise), you might check out this advice from Cal Evans as to what he, a hiring manager in the past, has looked for in a developer's resume.

am often asked to take a look at friends resume to give pointers on how that can make it more effective. Invariably, my advice is the same, so I'll share it here. When I was a manager and in charge of hiring, your resume had to get my attention for me to even consider it. If you got my attention, you had a much better chance at getting the job. That's the secret: get my attention, and get the job.

He points out that the usual situation is one manager to a large group of applicants. You may see the job post once, but so do 30 other people and you're all trying to grab attention. What's his recommendation? Brevity. Keep the first page short then dive deep behind that. There's more great tips in the rest of the post.

According to this recent post to his blog Zack Curl is a big proponent of using web application frameworks for development:

Most all PHP developers have worked off of their own code - they create all their own classes, sometimes borrow a little from previous projects, and basically create whole new frameworks without really knowing it. Even though most developers have the mindset that they have more flexibility, less redundancy in code, and other reasons that usually branch off of the two reasons, a framework actually makes your application load faster, work better, and work more effectively.

His reasons for the recommendation are:

• Classing and OOP Principles
• Model-View-Controller Schema
• Pre-built Libraries
• Built for speed

As far as his choice of a specific framework? He would opt for CodeIgniter, the lightweight and speedy product of Ellis Labs.

After having recently taken the PHP5 Zend Certified Engineer exam, Mike Bernat decided to shares some experiences about the time he spent preparing and his opinions on the test.

I decided that I wanted to take the test about 2 1/2 months ago. The first thing I did was visit the site and learn more about the exam itself. I discovered it covers almost every facet of the language and its use. [...] It's been mentioned before and I agree that none of these resources [websites, books, etc] alone are enough to make you feel confident going into the test. Rather, a combination of each resource should be taken advantage of to feel fully prepared.

He specifically mentions two books - the official Zend guide and the php|architect study guide - as well as some of the online testing he went through.

On the real test, he warns those looking to task it in the future of a few things - the trick questions, code blocks and some of the tougher subjects to watch out for.

As Lorna Mitchell has pointed out, the Call for Participation is open for this year's O'Reilly Open Source Convention - but the deadline is February 3rd!

We want to hear about your winning techniques, favorite life-savers, and the system you’ve made that everyone will be using next year. We’ll have tracks for sessions and tutorials on Linux, PHP, Perl, Python, Ruby, Java, Databases, Desktop Applications, Web Applications, Mobile, Administration, Security, People, Business, and Emerging Topics.

They have a few suggestions to consider when submitting your idea - things like "keep it free of marketing", "Straightforward titles are best" and "Explain why people want to attend". You can submit your idea via their proposal form.

The NETTUTS website has posted a top ten list of things from the PHP masters out there, a few words of wisdom to live by. Here's the list along with the authors of each:

• Use PHP Only When You Need it - Rasmus Lerdorf
• Use Many Tables With PHP and MYSQL for Scalability - Matt Mullenweg
• Never, ever trust your users - Dave Child
• Invest in PHP Caching - Ben Balbo
• Speed up PHP Development with an IDE, Templates and Snippets - Chad Kieffer
• Make Better Use of PHP's Filter Functions - Joey Sochacki
• Use a PHP Framework - Josh Sharp
• Don't use a PHP Framework - Rasmus Lerdorf
• Use Batch Processing - Jack D. Herrington
• Turn on Error Reporting Immediately - David Cummings

Some of them are conflicting, but that just means that you'll have to do what you've always done - take advice with a grain of salt and ultimately decide what's best for you and your application.

Take a hint from Maarten Manders when renaming and moving around your unit testing order:

It's absolutely amazing how much you can mess up unit tests just by changing their order! (Trevi_* comes after Tilllate_*) Everyone knows that tests are supposed to be independent. But we all know how it is.

He asks for recommendations on what to do to help the situation. Comments on the post (including ones from Lukas Smith and Sebastian Bergmann) mention using PHPT, a new version of PHPUnit that will do just what he wants and whether or not to use Singletons.

According to I-nfotech, there's ten projects that every PHP developer out there just can't live without:

As a php web developer, you should know that php is probably the language that has the biggest code repository. So no matter what module you want to include in your project there should be an open source solution. [...] Anyway, after many years as a web developer, I've compiled a list of php classes that can be easily integrated in any project and I am regularly use.

He has it broken up into the ten different categories including "sending emails", "user manipulation", "fetching RSS feeds" and "grabbing remote content". Some of his choices are things native to PHP (like the mail function) but others are external classes like the Magpie RSS package.