In this new post to his blog Artur Ejsmont shares some of his thoughts on bugs and how they can effect the quality of your software. He touches on topics like handling bug reports, how random code changes effect them and how effective a code review can be.

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 a new post to his blog today Phil Sturgeon responds to some comments made in another post about PHP not "being an acceptable COBOL".

Anyone who has used PHP for a while knows that it has its ugly parts. Recently I've seen a whole swathe of PHP-bashing articles and that would fine if they were they are making a valid point, but some of it has just been - as I tweeted recently - "absolute drivel".

He directly refutes some of the points made in that article, points out a newer post from the same author (which misses some points as well) and finishes it off with a look at why he "still" uses PHP versus something like Closure or NodeJS for his development.

Despite known flaws and imperfections I continue to use PHP as my primary language because during all the time I spend worrying about which technology is the neatest, coolest or shiniest I could have built a new application to sell or finished another client site.

Be sure to check out the comments for some other thoughts about the language (and Phil's responses).

On the Agile Toolkit blog today there's and interesting article with a slightly misleading title - "How to Earn Money with Open Source?" It talks less about strategies of how to monetize your open source project and more about how other projects are doing it and why a good core team is important.

OpenSource is an amazing phenomena, but how safe open-source projects are? Would commercial project be safer over the community-supported project? Frameworks can't exist without their core team and In this article I look at how different PHP frameworks are supporting their core developers.

He talks briefly about the need for a good, solid group of core developers on a framework (or really any product) to provide a stable foundation if a product was created with it. Four projects are mentioned - Zend Framework, CodeIgniter, Symfony and Agile Toolkit - and why, because of the backing they have from a company and a large group of developers (and contributors) they're not "yet another framework" that'll disappear over time.

Making new frameworks is fun, however, if you share framework with others, be responsible about the support. Make realistic goals and try to have a plan for a next few years. If you are the author, think who will support the community when you decide to move on.

Michelangelo van Dam has posted the fourth part of his "Quality Assurance in PHP projects" series to his blog today - a continuation of his emphasis on PHPUnit and testing his sample "Tic-Tac-Toe" game.

In parts one, two and three we focussed on writing tests for a game of tic-tac-toe, with in parts two and three we optimized our tests so they focus on the functionality of the individual parts Grid and Player, with a collection class Players to handle Player objects.

In this fourth part he focuses on the rules for playing the game and the unit tests to validate the correct flow. He covers one of his tests before, looking at the "can be played" validation for identical symbols. He modifies this to use a provider that gives the test the set of data to work from with varying symbols. He writes additional tests to be sure the game "stops after winning" and that it has a winner/which player is the winner. You can find the full game source (complete with these tests) on his github account.

Michelangelo van Dam is back today with the next part of his "Quality Assurance in PHP Projects" series, the third part of his look at PHPUnit, the popular PHP-based unit testing software.

Time for the third part on unit testing with phpunit in my Quality Assurance on PHP projects series. In part one we started writing unit tests for a simple game of tic-tac-toe. In part two we started converting our unit tests into actual code and moved our general unit test code for grids into a Grid focussed unit test. In this part, we're looking at how we can optimize the tests for our players.

He digs deeper into the TicTacToe application and focuses first on the single-player functionality, checking the symbol for the current player (an "X" or "O") and throwing exceptions in the code when things aren't right. He also shows the tests for checking on "more than one player" and "cannot add more than two players" scenarios. Full code for the Player class and tests are included.

Michelangelo van Dam has posted the second part of his look at PHPUnit in his "Quality Assurance in PHP Projects" blog post series. This is a continuation from part one.

I hope everyone enjoyed my first article on unit testing with phpunit where I started writing a few tests that would guide us building our little game of tictactoe. Today I'm going start with turning these tests into working code and adjusting our tests to have a clear separation of responsibility. Since we already know what the code should produce, we only have to work out the details.

He picks up where he left off on his "tic-tac-toe" example by defining some of the classes that will be needed to fulfill the tests and a sample test to check the generated grid's contents. He includes the Grid class that will do the job (full code included) and a full test case class that runs his example with checks on testGameGridIsSetAtStart, testGridCanPositionASymbol, testGridHasThreeSymbolsInARow and testGridHasThreeSymbolsInAColumn, some with their own data providers.

Michelangelo van Dam continues his "Quality Assurance in PHP projects" series in his latest post, the first of a few, about using PHPUnit to test your application.

Of all tools available for improving quality assurance, there's one tool that is the core tool you have to master: PHPUnit. PHPUnit is a complete testing framework crafted by Sebastian Bergmann (@s_bergmann), who ported existing xUnit frameworks to PHP. And with this testing framework you're able to test your functionality in an automated way before you push code into production.

Michelangelo walks you through the installation (via the PEAR installer), creating a phpunit.xml configuration file and making a basic bootstrapper to define some paths and environments. To make the tests a bit more relevant than just pseudo-test examples, he's created a set of tests based around a tic-tac-toe application in a test-driven design fashion (tests first, then code). In this first part he sets up some of his assertions in the tests, but you'll have to wait until part 2 for the code that will make them pass.

As a follow up to his previous post about using DocBlock commenting and phpDocumentor for automatic project documentation generation, Michelangelo van Dam has posted a deeper look at DocBlox, one of his previously mentioned alternatives.

First of all, thank you all for the enormous feedback I got on my latest article on documentation of code. I got a lot of comments on the usage of PHPDocumentor. [...] I have to agree that [there are reasons] valid enough to step away from PHPDocumentor as a tool for documentation purposes and look for a better alternative. So I've investigated one tool most people have commented on or tweet-ed/facebook-ed/g+-ed on: DocBlox.

He touches on the installation of the tool and mentions this tutorial from Matthew Weier O'Phinney that guided him through the setup and use of DocBlox. He rand a few tests comparing phpDocumentor and DocBlox for the documentation generate and DocBlox came out on top when it came to runtime (and memory usage).

Michelangelo van Dam has posted the latest in his "quality assurance in PHP projects" series today with a look at something that can make your life and documentation easier - PHPDocumentor.

Unfortunately I've come across too many lines of code that were just lines of code, no comments or annotations provided. So, in best cases I could guess the types and parameters, but in many it was too obfuscated. I already talked about usage of a code sniffer like PHP_CodeSniffer in my previous post where you can validate the usage of comments in the code. But forcing developers (using a pre-commit checker) into writing documentation with their code is not really a good thing.

He suggests using something like PHPDocumetor (there's other PHPDoc parsers including DocBlox and Doxygen out there) to automatically generate documentation for your code based on its comments, giving your developers easier web-based access to the contents. He includes some sample docblocks for a class/method and gives an example command line call to build docs based on a project. A screencast and screenshot of the generated site shows the results of the run.

Michelangelo van Dam has posted the next part in his "QA in PHP development" series to his blog, a look at PHP_CodeSniffer, a tool that can be used to keep the coding standards of your application in line.

PHP_CodeSniffer is probably the most convenient tool out there to analyze your source code and to verify it complies to company policies. Although it's debatable why source code should follow strict guidelines, it's only a matter of time before you discover yourself that it pays off to have a code base that appears to be written by one developer.

He talks about how it works to keep every brace in the right place and format the same through out all of your files. He also mentions that its standards are flexible and can be modified as you might see fit. He looks at the installation process (both manual and through the PEAR installer) and how to use it to analyze your codebase. He's even included a short screencast in the post so you can see the results first-hand.