On 7PHP.com today there's a new interview with Jakub Vrana about his tool Adminser, a lightweight alternative to things like phpMyAdmin for database management.

Adminer, formerly known as phpMinAdmin, is a full-featured database management tool to be used as a more simple, effective and fast alternative to the famous PHPmyAdmin. Being curious about it, I had a chat with the creator of Adminer, Jakub Vrana.

They talk about the problem the tool tries to solve and where the idea to make it came from. There's also a bit about why to use it over something like phpMyAdmin and what the current status/future plans for it are. If you want to read an interview with Jakub about his work and experiences, you can check out this post.

PHPMaster.com has a new tutorial posted that introduces you to a build tool that's more common in the Java world but can easily support PHP projects, Apache's Maven.

Apache Maven is a build automation tool with the purpose of building, reporting, and creating documentation of projects. It builds projects using a Project Object Model (POM) and a set of plugins shared by all projects using Maven, thus providing a uniform build system. Once you familiarize yourself with how one Maven project builds, you automatically know how all Maven projects build. [...] Through this article you will gain familiarity with Maven for PHP, and how to install and use the PHP-Maven plugin from the command line and in Eclipse.

The tutorial walks you first through the basic install of Maven and get you started with an example "settings.xml" file helping to set up the PHP-Maven plugin. They help you create your first project using the Archetype plugin and its related "pom.xml" file. The project already has a defined structure (similar to what you might see in a Composer-loadable PHP repo on Github) for the source of your app and the tests. They show you how to hook in PHPUnit and phpDocumentor for testing/dcumentation builds and, finally, how to integrate it all into Eclipse to allow for easier, in-IDE interactions.

About a month back Samuel Levy wrote up a post sharing some of his thoughts on PHP, mostly centered around one idea - that PHP is the right tool for the job (for all the wrong reasons).

When people complain about PHP being a horrible language, not fit for human consumption, they will often talk about how the features of their favourite language are far more refined; have been designed with elegance in mind; are consistent and secure. And you know what? They're right. But PHP is still a better tool. [...] And it shouldn't be. It really shouldn't. I want another language to knock PHP out of the way. [...] I can't, though, because PHP does one thing really well that no other language seems capable of doing. It works, out of the box, for people who don't know what they're doing.

He goes on to talk about the "installation" required with running PHP scripts and how it makes it mostly "idiot-proof" to use. He points out that PHP has a definite niche in the world of web development languages - one that has a larger need that some others.

This is the challenge for all the people who want to complain about PHP - if your chosen language is so much better (and I have no doubt that in many ways, it objectively is), then make it accessible in the way that PHP is. Until then, keep that double-clawed hammer in your shed in case you want to make... burgers...

The QaFoo folks have posted information about a webinar they're putting on for those interested in using Behat for doing functional testing on their applications:

I've already written two blog posts here about Behat: Behavior Driven Development and Code Coverage with Behat. If that made you curious or you wanted to learn about Behat anyway, I can highly recommend to join the free webinar on Behavior Driven Development with Behat I'll be giving on May 8th 2013 on behalf of Qafoo in cooperation with Zend.

As mentioned, the webinar is free to attend, but you'll need to sign up to be able to attend.

On the QaFoo blog today the company is introducing a new tool to help PHP developers write better, more optimized code - the PHP Refactoring Browser (written in PHP too).

Without continuous refactoring, code maintainability and extensibility will start to decrease fast, even if it has tests. Until now, only IDEs contained functionality to perform automated refactorings. And then even only PHPStorm contains the most important refactorings such as "extract method". Today we release the PHP Refactoring Browser, a refactoring tool written completely in PHP. It is based on several outstanding open-source libraries.

The browser currently supports multiple refactoring methods including the extract method, renaming of local variables and converting a local variable to an instance. They include some example code and the result from the execution of the tool. The output shows where refactoring would work best with some color coding and formatting.

You can find more about this new tool over on its github repository.

On PHPMaster.com today Shameer C has a new tutorial introducing you to Boris, a REPL (read-eval-print loop tool) that's a bit more enhanced than the basic PHP interactive shell.

As web developers, we know the importance of the JavaScript console provided by the browser in testing out code snippets. We don't need to write an entire HTML page and JavaScript code just to verify the functioning or logic of a small routine we wrote. Instead, we simply run the expressions in the console and immediately see the results. Similarly, a REPL (Read-Eval-Print Loop) is the console of a programming language in which we can write code line-by-line and see what it does. [...] PHP's REPL is very good in what it does, although it does have some limitations. [...] And so, Boris tries to solve these problems and other concerns as well.

He walks you through the installation (via a git clone and, later, through Composer) and shows how to run it as well as some sample output. He also shows how to make a custom command-line Boris runner and how to embed it into your application. His example of a tool that would benefit from this is a command-line web service client using Boris and Guzzle.

Andrew Podner has a new post to his site today introducing you to Phing, a PHP-based build tool (designed after on Apache Ant) that makes automating builds of your applications easy.

One of the things I have been focusing on lately is trying to to a better job of mechanizing and automating the process of building and deploying an application. The reason for this is pretty simple: applications just seem to keep getting more and more complicated and intricate as time goes on. [...] Phing is a "project build system" that helps developers manage repetitive tasks associated with preparation and deployment of applications. Phing uses XML based files to allow you the ability to customize the build process to the individual application.

He walks you through the Phing installation (from PEAR, note that you can install it via Composer now too) and how to set up your first project XML definition. He shows you how to add a "target" or step to the build with the basic example of running your app's PHPUnit tests. He also includes a list of other things Phing can do and work with including CodeSniffer checks, FTP handling, version control interfaces and automated documentation.

In a follow-up to his previous article about why languages don't matter, Brandon Savage has a new post (part two) carrying on the theme but getting more into the thought patterns behind language selection and use.

Developers like to think that companies hire developers to write code. But companies do not hire developers to write code; they hire developers to solve problems. They hire developers with the expectation that the developer knows about, or can learn about, the problems of the company, and find a creative solution to those problems at minimal cost.

It is therefore up to the developer to choose what tools they will use to achieve the outcome. The customer doesn't much care what tools the developer uses; they only care that the outcome they desired is achieved.

He goes on to talk about preferences in the tools "used by craftsmen" and why they're less important than the result of the work they create. He notes that languages matter, but only in a certain context - as a piece of a puzzle, a part of a whole to reach an objective of functioning software.

The Codeception testing tool has released a new major update with some interesting new features - the expected feature for generating code coverage reports (similar to other tools) but there's also the idea of "remote code coverage" introduced.

There is no magic in local codecoverage. XDebug and PHP_CodeCoverage libraries do their job. The tricky thing is remote codecoverage. We attach small script into application's front controller. When a special header is sent this script starts to collect coverage information. And in the end of tests, this data is merged, serialized and sent back to Codeception. So you can test and collect coverage report even on staging servers in real environment.

They also mention a few other updates in the release - new Redis and MongoDb modules, UX improvements and the normal bugfixes. You can find out more about the code coverage feature in their manual or just about the project in general from the main site.

On PHPMaster.com today there's a new tutorial showing you how to effectively debug your applications with Xdebug, a handy tool that provides more detail around your errors just by installing it.

Xdebug is a free and open source project by Derick Rethans and is probably one of the most useful PHP extensions. It provides more than just basic debugging support, but also stack traces, profiling, code coverage, and so on. In this article you'll see how to install and configure Xdebug, how to debug your PHP application from Netbeans, and how to read a profiling report in KCachegrind.

He walks you through the installation process (installing it from a package, not compiling) and how to enable it in your "php.ini" configuration file. He also shows how to hook it into the debugger on your IDE (in this case Netbeans) to receive debug messages and be able to step through the code to easily locate the issues. Also included is some basic information about profiling your application and viewing the resulting data in something like Kcachegrind or Webgrind