All modern frameworks (including FLOW3) push a lot of patterns into the software stack that do a great job at separating the concerns of your business logic; among them the famous MVC that is separating your logic into different layers. However, an application is not only built on business logic alone. As it grows, you may want to implement additional services, features, plugins or plugins of plugins. You surely don't want this stuff in your business logic! But what are your options?

For their example, they show how to implement a logger across your classes, taking it out of the actual code and implementing it in an aspect (at the "pointcut") by "weaving" it into a DocBlock comment with special annotations. They help you get the FLOW3 framework set up and show you how to "kickstart" a new project and work with its controllers and resources. They show you how to implement the Logging aspect and how to define it in your code (and where it caches the requests).

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.

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.

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

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

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.

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.

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.

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).

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.