If you're going to be rolling your own user handling in your application, no doubt you've heard that something like bcrypt-ing your passwords is a good idea. Well, Anthony Ferrara has some suggestions for you and shows you seven ways you can "screw up" when trying ti implement it.

There are numerous articles on the web about how to properly use bcrypt in PHP. So this time, rather than write yet-another-how-to-use-bcrypt article, I'm going to focus on the mistakes that are commonly made when implementing bcrypt.

Here's the list of seven ways (each has its own description in the post):

• Using A Non-Random Salt
• Using An Incorrect Random Source for Salt Generation
• Using Too Weak Of A Cost Parameter
• Using The Wrong PHP Version
• Using The Wrong Prefix
• Not Checking For Errors
• Not Using A Library

He also includes two "bonus" things to consider: "Not Using A Timing Safe Comparison" and "Not Encoding The Salt Correctly".

Wan Qi Chen has returned with the next three parts in his "Background jobs with PHP and resque" series (first parts here) with parts four, five and six helping you implement the concepts from the first three parts.

• Background jobs with php and resque: part 4, managing worker
• Background jobs with php and resque: part 5, creating jobs
• Background jobs with php and resque: part 6, integration into CakePHP

That sixth part of the series uses the CakeRisque plugin to make the integration simpler. Save that, you could integrate this setup pretty easily into whatever framework you choose.

In a recent post to his blog Devis Lucato introduces the "Inversion of Control" design pattern and shares an implementation he's created as an illustration - a Service Locator called Select.

[In a Service Locator] all the dependencies are provided by a builder, which serves as a registry of dependencies and/or service definitions. The service locator knows how to instantiate each dependency. Such service exposes methods like 'getMailer()', 'getLogger()' etc. A service locator centralises the configuration detailing classes and parameters involved on objects instantiations.

He includes some sample code showing the structure of a Select implementation using a "Mailer" identifier and definitions of the classes to load for it. He also includes a bit of documentation of the (simple) API you can use to work with the tool - setting namespaces, replacing class definitions, creating definitions and finding the resource associated with a definition (to name a few).

On the Java DZone.com section today there's a "which is faster" post comparing PHP, Java and Python. No, it's not quite what you're expecting - I'd suggest reading on.

Sigh. What a difficult question. There are numerous incarnations on StackOverflow. All nearly unanswerable. The worst part is questions where they add the "in general" qualifier. Which is "faster in general" is essentially impossible to answer. And yet, the question persists. There are three rules for figuring out which is faster. And there are three significant problems that make these rules inescapable.

His three rules are:

• Languages don't have speeds. Implementations have speeds.
• Statistics Aren't a Panacea.
• Benchmarking Is Hard.

He seems to hit most of the issues with these sort of "faster" posts up front and notes that, while benchmarks can be run on a lot of different aspects about the languages, the results depend on how you slice it. His suggestion is, instead, to not try to compare the languages in a grand sense. Take each of them and compare them on specific tasks and let those results stand alone. Each of the three languages is going to be better at something than the other two.

On Developer.com today there's a new tutorial about Quercus - the Java-based implementation of PHP - and how to get it up and running in your environment.

Imagine the possibilities when a PHP developer can continue using the language's templating capabilities while leveraging Hibernate's object-relational features. Thanks to an open source project named Quercus, PHP and Java developers alike can mix and match the respective capabilities of both languages. [...] This approach (part of the movement that software architect Neal Ford famously defined as "polyglot programming") opens up a whole new world of opportunities for developers seeking to squeeze every last ounce of performance and capability from their application platforms.

They help you get it installed and show you how to execute a PHP script from inside. There's also a bit about integrating Java libraries into your code and the integration of a type of tool PHP doesn't come native with, something like iTextPDF.

Even with the release of PHP 5.3 looming closer and closer on the horizon, there's a few things that are still being worked through - one of which is the much touted namespace support. Elizabeth Smith has posted a few of the issues that she's having with how they're being implemented, four and a half of them, to be exact.

The first thing to clarify is that I like the new implementation overall, it's fairly light and although it isn't really namespacing or packaging in any sense of the word, the best way to describe it is aliasing, it does help keep code easy to use. In fact I have a couple of projects and even a PHP extension that's all namespaced code.

Her list of five (four and a half) things are:

• multiple namespaces in a file
• you can't have ANYTHING before the namespace statement but an opening <?php tag
• The autoload and resolution paths
• Functions in namespaces
• No use * and three million use statements (this is the one with the workaround - class_alias)

The results from the latest poll the International PHP Magazine conducted this past week are in. The question they asked developers to respond to was "Which One of the Following Ensures Smooth Implementation of PHP Sessions?".

Options this time were:

• Don't use underscore in host names
• Commit your session before it redirects
• Prevent session fixation
• Don't expose session_id's

The results were pretty close for all of the options with one coming out on top (committing the session) and two tying for second - preventing session fixation and not exposing session IDs.

Subversion and Symfony users should cast their votes in this week's poll. It asks, of the four options given, which is your favorite "trick" to running the Symfony framework with Subversion.

Jacob Santos has started a series of posts to his blog that focuses on the use of the opcode cache and language features in your applications.

The posts will be researched and go through multiple drafts for professionalism before posting. In this hope, it will strive to enable discussion that isn't flaming and collective of the topic at hand. For as much as I can achieve at my level of writing skill and researching the topic at hand.

He he goes through the purpose of the posts, the areas he's going to focus on, some about the theory that will be used, and the implementation and documentation he'll provide through the series.

The OC Food Review blog has posted part one of a two part series covering the creation of a location-based search engine. They're currently implementing it into their site and wanted to share the knowledge.

Conceptually, location based searching is pretty straight-forward: find out where you are, find out how far you're willing to travel, and compare your location against the locations of all your choices. If the distance between where you are and what you're interested in is less than what you're willing to travel, add it to your results list. Simple, right? Right.

He talks more about the concepts behind the search and one of the keys to the entire process - geocoding. They opted to go with the Yahoo! Maps API to grab this information. There's some sample REST urls and the output of the results after they've been unserialized.

They've even created their own class to make things even simpler. It does require that you have cURL installed with your PHP5 installation, but outside of that, there are no other dependencies.

Alexey Zakhlestin shares with us in this new blog post, how the fast-cgi PHP developers think they're using isn't really a true FastCGI.

Most PHP programmers believe, that PHP has support for FastCGI. They refer to fastcgi-sapi, which is bundled with php since long ago, and which was recently reimplemented for PHP 5.1.3/4. This SAPI really does exist and actually working quite good. But… it is not a real fast-cgi. It is just an imitation of mod_php which is linked against fastcgi api, instead of apache api. So, it's time for you to ask: if it exists and works, then what am I talking here about? Let's start from the basics...

He talks about a history of how things go to where they are, starting back with regular CGI scripts, moving up through using server-based APIs, and finally to FastcGI, a method for overcoming a lot of the limitations of its predecessors.

With that look back, he turns his attention around and looks to the current situation within PHP. He talks about the sudden appearance fastcgi made in PHP's SAPIs, but that the implementation wasn't true. He suggests that the reasoning behind this "fake" implementation was for the sake of speed. He also notes, however, it's his opinion that true FastCGI support in PHP will be a requirement for future large-scale applications.