In this new post Joseph Scott takes a look at hashing in PHP, specifically around md5 hashes, and a better alternative (that's also more secure.

The majority of the Coding Horror: Speed Hashing post talks about speed based on MD5. [...] If you are still using MD5 to hash passwords (or worse, aren't hashing passwords at all) then please stop and go use bcrypt. For those using PHP phpass is a great option.

He talks about the crypt method, how its encryption method and "cost" value effects the speed and how difficult it would be to generate all possible hashes for a password (hint: crypt with a cost of 13 is worlds better than md5).

Brandon Savage has a new post about something that some developers out there factor into their development estimates from the beginning and others are just learning how to adjust to - the sunk cost that can be associated with writing code.

Last week, I began working on something that didn't pan out. For whatever reason, I went down the wrong path, and ultimately abandoned the task I was working on. In discussing it with my boss, he mentioned to me that it was better to realize early on that something wouldn't work than to trudge onward, insisting that it be finished due to the "sunk cost" of the time already spent.

There's two sides to this story - one in which the application continues to be developed and takes up more time (but still ends up as a product) and the other where the time already spent is lost as a completely new approach is taken.

On the Ibuildings techPortal site Stefan Koopmanschap has written up some thoughts on one of the eternal struggles development shops face - whether to buy or build the software they need (either for themselves or their clients).

One of the biggest struggles in any software development company is "Buy vs. Build". How do you strike a balance between writing custom software and purchasing off-the-shelf solutions. This is something that is very hard and everyone gets it wrong every once in a while. In this article we will explore the way that Ibuildings approaches this issue, in the hopes that it helps others in getting it right more often.

He talks about considerations made on both sides - how flexible is the application, what is on-hand that could be adapted - and how the base product they might have purchased can act as a based to work from (like a content management system). There's no overall recommendation, though - too much of the decision depends on what's needed at the time and the capabilities of the technical staff employed.

Sometimes power comes at a price - you get benefits from the added features and functionality, but you can lose something else along the way - the simplicity that brought you in originally. Federico Cargnelutti takes a look at a tool that can do just that - the Zend Framework.

Don't assume that just because you're using an object-oriented framework you are writing reusable and maintainable code. You are just structuring your spaghetti code. [...] The main problem with flexibility is that most developers give up trying to understand. I don't blame them, no one likes dealing with complexity

TO illustrate, he gives two code snippets from two example developers - Developer A makes full use of the framework and takes a more compact approach to the problem while Developer B adds in a bit more checking and takes a different path to the same (basic) end result.

A recent post from Francois Zaninotto has been getting a lot of attention recently. It's his look at what would be needed to design a complete CMS and the full architecture behind it.

When faced with the alternative between an off-the-shelf CMS or a custom development, many companies pick solutions like ezPublish or Drupal. In addition to being free, these CMS seem to fulfill all possible requirements. But while choosing an open-source solution is a great idea, going for a full-featured CMS may prove more expensive than designing and developing your own Custom Management System.

He breaks it up into sections that look at the hidden costs behind custom development, what components it takes, the environment to build in and some of the fundamental questions you need to ask before even getting started.

Wez Furlong posts today about a response made to a previous mention of "PHP vs. ASP.NET" in this article from Joe Stagner in this post on his MSDN blog.

From Wez:

Joe's response is perhaps a little pro-Microsoft (you can't really blame him for that--he does work there :-) but the essence of his response rings true; there's nowhere near enough factual data in the OTN article to make a balanced decision one way or the other.

To be fair to Sean (the author of the OTN article), it does say "Opinion" across the top of the page and the byline is "One developer's view of the pros and cons of the two most popular means of building web applications", but it's easy to forget those once you're into the article.

Wez also mentions one of his personal views on the whole debate, basically saying that even if PHP is the faster/more efficient, some situations might do better with an ASP.NET solution (what's the cost of implementation?).

When someone talks about PHP and drags up the old "but it doesn't scale well" argument, drop them an email with this new article from the O'Reilly ONLamp.com site that might change their minds. In it, they share some information they gathered (spurred on by James Gosling's comments on PHP a bit back) on how one large site, digg.com, has dealt with their huge popularity and scaling their PHP-based system.

They focus mainly on the cost of scalability - whether that be in hardware costs or simply in manhours. He interviews Owen Byrne, Senior Software Engineer for digg.com about some of his decisions on how to handle the explosive growth. They look at what "performance" and "scalability" really are, and some of Byrne's concerns on the matters as it pertains to PHP. They touch briefly on a few topics, including the hardware cost, the database cost, and the actual PHP coding cost of applications.

It turns out that it really is fast and cheap to develop applications in PHP. Most scaling and performance challenges are almost always related to the data layer, and are common across all language platforms. Even as a self-proclaimed PHP evangelist, I was very startled to find out that all of the theories I was subscribing to were true. There is simply no truth to the idea that Java is better than scripting languages at writing scalable web applications. I won't go as far as to say that PHP is better than Java, because it is never that simple. However it just isn't true to say that PHP doesn't scale.

Pass it on...

On his blog today, Jim Plush has a list of sites that have "popped up" to decode Zend encoded files.

I have yet to find a response by anyone from Zend on this matter but it seems sites are popping up all over the place that can decode Zend Encoded scripts. Since my company is a customer of this product and rely on this product I'm quite scared as to the slowness of Zend's response.

Some of the sites listed are:

• phpdecode.com
• phprecovery.com
• zic-recovery.com

Of course, of the ones he lists, only one might be a free service. Otherwise, the prices range widly from $15 USD all the way up to $2000 USD.

On LinuxToday.com, there's this new pointer to an article that brings up the age-old struggle between two popular web development languages - ASP vs. PHP.

Both ASP and PHP are languages used to build Dynamic Web sites that can interact with Databases and exchange information. ASP (Active Server Pages) is from Microsoft and is used with IIS (Internet Information Server) that runs on Microsoft Servers. PHP (Personal Home Pages) is from Rasmus Lerdorf, who originally designed this parsing language which was later modified by different people. It runs on Unix and Linux servers and it also has an NT server version.

There are a lot of differences between ASP and PHP.

They go through several topics comparing to two - things like cost, speed, and database connectivity. The information provided here isn't anything groundbreaking, and there's no real conclusive choice (despite their "choice" at the end) between the two. What it really boils down to is the old "right tool for the right job" kind of situation, really...