From time to time I see bugs in the code and I start thinking "really? is it possible that no one noticed that bug before? am i the first person to see this code?". I thought it might be worth writing a little post on what helps me to deal with bugs and software quality in general and what are the common pitfalls in developer's thought process. Although it is not a very extensive post i hope it may inspire some developers to try new approaches.

Other topics he offers for consideration involve the fact that bugs will never fix themselves (they might disappear in a refactor though), that the bug is almost never in the language/data source's code and how automated (unit) testing can help to find new bugs before they're released to the users.

In this edition, I talked with Enrico Zimuel a computer geek since he was 9yrs old. He has written a couple of books namely "Secrets, Spies and Cipher Codes" published by Apogeo in 1999 and the recent "How to use the digital sign" published by Tecniche Nuove in 2010. Enrico has a pretty impressive 'geek' path. He also speaks at many international conferences [...]. You can find his presentations on slideshare.

Questions in the interview include:

• How do you find PHP now as compared to when you first started?
• Based on your experience, what are the good and bad parts of PHP?
• To someone who wants to become a better PHP developer, what is your advice?
• What are some good PHP blog or resources you highly recommend?

Read the full interview here.

Jason Austin gave a great presentation at CodeWorks Raleigh recently about cultivating one's passion for software development through side projects -- safe spaces where we can play with new technologies and techniques. The point's well taken: as developers, we're probably putting most of our energy towards the thing that must be solved, that keeps us employed, that pays our bills. [...] And so all of us, at one time or another, end up in a backwater of our own devising -- a locked box.

He also puts an emphasis on collaboration and community as it relates to becoming a better developer. By interacting with other code and other projects' developers, you learn not only more about other ways to develop but are exposed to ideas you may not have come across on your own.

I'd add that active participation in the local community is just as important though: the opportunities for exposure to new ideas outside your sphere are greater than your feed reader will probably provide, and the depth of information that you can get in a conversation may be better than any blog post or man page.

Code reuse is largely accepted as "best practice" in our industry. Code reuse has many advantages, such as a smaller code-base which is easier to grok for developers. It's easier to maintain and optimize, since you can make less changes in order to achieve the desired results. Many modern techniques and tools were created in order to better reuse and modularize code. But while we're reusing code, we're duplicating effort. The same code is being written over and over in different places, wasting time and money.

He suggests that custom development should always be a last resort for software development, that there's plenty of other (open source) software out there that meets many of the needs businesses have. In his opinion, component-based development is the future of the industry - pieces that fit together with common interfaces and are larger than the sum of their parts. He sees a "commercial open source" model emerging from the current state of things. This model could result in more well maintained OS projects and more functionality being released as a part of it.

What we have currently is increasing noise, as more and more people have easier access to start programming and publishing their projects. We need to streamline the process and add that missing financial element that makes it sustainable and repeatable.

This is a much more common problem than engineers and architects are willing to admit. Far too often I see someone in charge of writing a piece software worry about how a product works without paying so much as a passing thought to whether it actually works the way people expect it to. The truth is that we are, by and large, stuck in a reality where software somehow equates with automation.

He goes on to talk about how easy it is for us, as developers, to forge head with features and software that may not be useful to the masses. We worry more about solving a problem that may or may not actually be there. He illustrates with the example of a to-do list, providing the automation to make list tracking easier, but no guidance of how the user can make use of it effectively.

Every now and then, I get asked by developers who are just getting started in the trade if I have any suggestions to help them out - favourite language, tips and tricks, and the like. None of these things matter, really, but there are a few things I wish I had known when I started out that have nothing to do with the mechanics of software development.

His tips each come with a paragraph or so of explanation:

• Be humble
• There is no magic
• Programming is a craft, not an art
• Software solves problems
• Code doesn't leave sawdust

The social media company has, without question, taken the time to work on those projects. The hackers at Facebook have done perhaps more than any other single entity to advance and optimize PHP, the programming language on which the network is primarily built.

They talk about some of the projects, both PHP-related and not, that the developers of Facebook have either created or contributed to. There's mentions of Facebook's "hacker culture" and a mention of their workflow and how they decided on going forward with something like HipHop.

Every time you purchase a new Linux VPS, you need to go ahead and set it up for use. Even though we manage to do one server a month, we always seem to forget one thing or the other. So we decided to write down the things that we do. I thought it would be a good thing to share it with everybody as well, so that we could get a few comments about what we're doing wrong, and people who do it the first time can probably pick up a few things from here.

Steps and software involved in their process include:

• Updating to the latest Ubuntu packages
• Creating other users for the system
• Installing the web environment (including PHP, MySQL, phpmyadmin and Apache2)
• Minin for monitoring
• Configuring IPTables
• Installing Fail2Ban

All of this comes complete with the additions you'll need to make to configuration files and the commands to get everything installed (via aptitude).

Oh how we love acronyms. We've discussed a lot about writing a class, but we haven't talked about writing classes yet. How do you know if your solution is right? It is not enough to have a working program. SOLID is a set of principles that define severable measurable properties your architecture should have at least, in order to be dubbed right.

He goes through each of the principles (single responsibility principle, Liskov substitution principle, etc) and gives a summary statement, a definition and code illustrating it in use. The examples aren't all based on the same code as implementing all of these principles at once as been found to be difficult. He also includes another principle to keep in mind - the "Law of Demeter" dealing with calling scope of properties and methods.

There has been some discussion recently on the Zend Framework mailing list around release cycles. I proposed a release cycle of six months for major versions (someone else suggested eighteen months, which may be more reasonable for a framework). Rapid releases allow one to accelerate the cycle of building, measuring, and learning. Gathering data from actual usage (measuring) provides an opportunity for learning that can be applied to the next release (building).

He points out that the post isn't specifically targeted at the Zend Framework project, merely that it was the inspiration point for the idea. He talks about what rapid release cycles are and what it can give the team that implements it - less worries about backwards compatibility breaks, a potential encouragement for development pacing and the ease for the customers doing upgrades.

A rapid release cycle allows you to apply new learning, knowledge, and perspective as often as possible. Do your best today, and give yourself opportunities to do your best in the future as well.