Stuart Herbert has two new posts to his blog showing how to use the ContractLib tool he's created to define programming "contracts". In the first he shows some sample usage of the tool and in the second he compares the functionality of ContractLib's features and PHP's own "assert" method.

ContractLib is a simple-to-use PHP component for easily enforcing programming contracts throughout your PHP components. These programming contracts can go a long way to helping you, and the users of your components, develop more robust code.

In his example tests he shows how to set a pre-condition on a method's input ensuring that it will always be the correct datatype (array). In his comparison with PHP's "assert", he lists out some of the features that either one has and notes that ContractLib allows you to be much more flexible with your checking than just simple statements.

In this recent post to his blog Stuart Herbert introduces a system he's created to handle "contracts" in PHP development - ContractLib.

Programming contracts are tests around functions and methods, and they are normally used: to catch any 'bad' data that has been passed into the function or method from the caller, and to catch any 'bad' data generated by the function or method before it can be returned to the caller. These are pre-condition and post-condition tests, and they are tests that either pass or fail.

He points out that by having contracts you not only increase the robustness of your code but you also save time not trying to hunt down data-related issues. Using pre-conditions, you can can check data to ensure things like correct formatting, data that's out of range and data that might be missing. His ContractLib comes with a set of tests that provide good examples of how to use the functionality. Installation instructions are included.

In a quick new post today Kevin Schroeder asks his readers for feedback on what programming rules you should always follow in your development practices.

Earlier today, more for my own interest, I asked the question on Twitter "What programming rules should you ALWAYS follow, regardless of the scenario you're working in?" In other words, are there programming rules that you ALWAYS should follow. It doesn't matter if it's a script to copy a bunch of files for a one time migration or if you're building the next Facebook (DON'T try to build the next Facebook. You will fail miserably. Build something else). In other words, what was the purist of programming rules.

Responses he received ranged from the simple to slightly more complex including:

• Always comment your code
• Test your code
• Use source control
• "Think. Think again. Then write code"
• Use a good debugger to help track down problems
• Make effective use of logging/output

Lars Tesmer is currently in the process of learning Ruby. He' been working through the tutorials and some sample scripts and has come across some pitfalls along the way. In his latest post he shares four of them that've stood out in his development so far.

I'm currently learning Ruby. In this post I'll list some pitfalls for programmers coming from PHP that would probably cause some confusion if you aren't aware of them. This list is by no means complete, while I learn Ruby I'll very probably encounter more gotchas, which I will blog about, too.

For each of his four examples, he gives the code PHP developers are used to seeing and the Ruby code that may or may not do what you'd expect:

• Arrays are continuous
• Zero is not falsy
• The keywords private and protected
• There's no static keyword

In a new post to his blog Sameer Borate looks at using the Underscore.php library to do a little functional programming in PHP. Underscrore.phpis a PHP port of Underscrore.js.

Underscore.php provides a utility library for PHP that provides a lot of the functional programming support that a programmer would expect in Ruby, but without adding much overhead during execution. The only caveat is that underscore.php requires PHP 5.3 or greater. Although you could accomplish some of the things using PHP's built in functions, the functional approach looks intuitive and easy to work with.

He gives a few simple code examples - one using the "pluck" method to pull certain values out of an array, the "map" method to apply a transformation to each item in an array and some OOP examples showing the use of the "max" and "template" methods.

On IT World there's an interesting article about the programming skills that seem to be lost in today's coders and how what they may not know might hurt them in the end.

Some of these skills aren't likely to be needed again, any more than most of us need to know how to ride a horse or (sigh) drive a manual-transmission vehicle. But other skills and "lessons learned" may still or again prove relevant, whether developers are banging their heads against legacy systems, coding for new mobile and embedded devices... or other devices and applications we haven't yet thought of. [...] Here's what some industry veterans and seasoned coders think the younger generation doesn't know ... but should.

He's broken it up into a few different sections - one dealing with the lack of general hardware knowledge by a good section of the today's developers, another noting that programming is not the same as software engineering (yes, really). He also touches on the lacking idea of "thinking before coding" and how planning for errors has become less and less of an importance.

On the Smashing Magazine site there's a post some of Paul Tero's favorite programming mistakes he's come across and heard of in his time programming.

I like to classify these mistakes into three broad groups: cock-ups (or screw-ups in American English), errors and oversights. A cock-up is when you stare blankly at the screen and whisper "Oops": things like deleting a database or website, or overwriting three-days worth of work, or accidentally emailing 20,000 people. Errors cover everything, from simple syntax errors like forgetting a } to fatal errors and computational errors.

Included in his list are things like:

• Leaving Debug Mode On
• Turning Debug Mode Off
• Wrong Variable Type
• 1p Errors

Examples of each are included with both code and descriptions as well as "lessons learned" to help you not make the same mistakes in your applications.

Eran Galperin has posted a last call for entries into the Binpress programming contest with the final ten days looming on the horizon.

Have you been developing custom solutions for the web? pick your best feature, module or UI component that can be packaged and re-used and publish it on Binpress. Binpress is a marketplace for source-code, where developers can sell and buy source code from each other. We are looking for high-quality code from professional developers. If you think you have what it takes, please go over our submission guidelines and join the contest.

There's over $40,000 USD in prizes for the winners of the contest in categories for "best submission" and "best submission per language" (you can submit PHP, ASP.NET, Python, Java, Ruby or Javascript).

Binpress has announced a new contest they've put together to try to find the best of the best programmers out there. The contest offers over $40,000 USD worth of prizes in three different categories going to the best code submitted to the Binpress site.

Have you been developing custom solutions for the web? pick your best feature, module or UI component that can be packaged and re-used and publish it on Binpress. Binpress is a marketplace for source-code, where developers can sell and buy source code from each other. We are looking for high-quality code from professional developers.

If you're interested, check out the submission guidelines and or just jump in and join the contest with your own submission. The grand prize winner will receive a $17,000 USD award, second and third will receive $13,000 USD and the winners of the "best submission per language" awards will all receive $10,000 USD.

In a new post to his blog Henri Berguis takes a look at something that seems to be popping up more and more these days - literate programming. He's created a simple tool that can help implement this in your development too called noweb (modeled after the noweb python project).

The literate programming paradigm, as conceived by Knuth, represents a move away from writing programs in the manner and order imposed by the computer, and instead enables programmers to develop programs in the order demanded by the logic and flow of their thoughts.

Literate programming allows the developer to set up one file, one with more natural language, and have the tool split it up into two other files - one for execution and the other used as documentation. He steps you through how the noweb tool works to pull in the file, parsing out the information via regular expressions (based on the noweb-style) and pushing the two versions of the file back out on the other side. The documentation is set up to end up as HTML and the code will be the literal code pulled from the noweb document itself.