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.

On his site Fabien Potencier has posted about a feature added to Silex to help make debugging the flow of your application "more fun" - the Symfony web profiler.

One of the big advantages of both Symfony and Silex is that they are based on the Symfony HttpKernel component. [...] But handling HTTP requests with the Symfony HttpKernel also gives you a lot of free and optional features like a built-in reverse proxy written in PHP, easy handling of ESI and Hincludes (via the Fragment sub-framework), or the gorgeous Symfony web profiler.

The profiler provides information on which components were accessed, their memory consumption and how long they took to execute. The integration happens via the WebProfiler provider for Silex and is already integrated into the Silex skeleton base application.

In the latest post to his site, Ruslan Yakushev looks at some simple ways you can debug your PHP-based applications running on a Windows Azure platform.

The need to diagnose and troubleshoot application's failures often comes up during deployment to a hosting environment. Some configuration settings in hosting server may differ from what application expects. Often it is not as easy to figure out the cause of the problem in a hosting environment as it is on a development machine. I found the following techniques useful when troubleshooting errors in PHP applications hosted in Windows Azure Web Sites.

He shares seven different tips, some pretty simple, others a bit more difficult requiring other software to be up and working:

• Using phpinfo()
• Checking the wincache settings
• Looking at your error logs
• Turning on the display_errors setting
• Turning on HTTP logging, detailed errors and failed request tracking in the control panel
• Using XDebug
• Getting the statistics for your ClearDB instance

Chris Jones has a new post showing how you can use Emacs and Xdebug for debugging with the help of the geben plugin.

When you want to test a PHP code snippet quickly, it's handy to do it within your day-to-day environment. For me, this environment is Emacs. The geben package for Emacs provides an interface to the DBGp protocol, such as used by Derick Rethans's standard Xdebug extension for PHP. With the combination of geben and Xdebug, I can quickly and efficiently step through execution of local files, examining code flow and data values.

He includes a ten step process (step 11 is basically "use it") that walks you through the installation of the full stack - PHP, Xdebug and geben - and the configuration changes you'll need to make to get them all working together. Some basic usage instructions are included, but if you want more details on using geben, check out the project's site.

Joshua Thijssen has a recent post for all the PHPStorm users out there (or maybe investigating a new IDE) and are looking for a way to debug your PHP apps easily with XDebug. Well, he's come up with a step-by-step guide to help you get it all set up and working, complete with screenshots. He helps you debug command-line applications, but the setup will work for your web apps too.

Even in these days, with full-featured PHP IDEs around, I still see PHP developers using var_dump() and die() to debug their code. Not only is this a very bad way of "debugging", it has other dangers as well [...]. We've probably all been there,.. But we don't have to. Debugging your code properly through an IDE is quite easy, but one of the major problems is debugging CLI code. Since many frameworks like Zend, Symfony and micro-frameworks like Cilex can be used to create command-line apps, cronjobs and even "deamons", so how do we easily debug this kind of code?

He starts with the setup of a development instance (he recommends a clone-able virtual machine environment) and shows how o configure both XDebug and PHPStorm to work together happily. He shows what configuration options and steps you'll need to take to be able to debug the CLI apps too, including a command-line option to specify the IP to report the debugging into back into.

Derick Rethans has a new post that the developers out there using MongoDB in their applications will find useful - a look at debugging your connections with the PHP driver (and what kind of information it can provide).

In a previous article I already mentioned that the 1.3 version of the MongoDB driver has improved logging functionality to aid with debugging connection issues. I've already briefly introduced MongoClient::getConnections(), but it provides a bit more information than I have already shown. The other improvement are changes to the MongoLog class.

He includes details on the information that comes back from the MongoDB "getConnections" call including the hash of the connection, the "last ping" time, connection type and a set of tags. He also shows how to enable the Mongolog logging, the levels of logging it allows and what kind of log messages you can expect it to output.

In a previous post Pablo Viquez talked about integrating JMeter and Zend Debugger for testing your PHP applications. In this new post he goes one more step in and talks about integrating Eclipse, JMeter and using XDebug this time for the debugging.

In a previous post I wrote about doing step by step debugging using Zend Debugger and Zend Studio making the calls from JMeter, however not everyone has Zend Server or Zend Studio installed, and since XDebug is an awesome project I though that will be awesome to do the same using XDebug. [...] As explained previously, using the browser for API debugging can be pretty hard or nearly impossible unless you build some sort of UI, which normally I do not have time to do, so JMeter is perfect for the job!

He includes the configuration changes that'll need to be made to Apache and how to set up and configure the new project in Eclipse. He also includes the setup of the jMeter plan (using his example) and executing it to execute the script/get the debugging information.

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

On PHPMaster.com today there's a new tutorial showing you a different method for debugging your code than the usual print_r or var_dump - using FirePHP, a tool that uses messaging to relay information back to your browser.

As the technical manager of a suite of software projects, one of my duties is doing code reviews. One of the things I see far more often than I'd like when doing reviews is debugging PHP code committed and pushed up the chain. [...] The safest method of debugging requires configuring your IDE to use a tool like Xdebug or Zend Debugger to trace currently executing code. This isn't always practical. In the absence of using a fully configured debug environment, I turn to FirePHP.

He shows how to set up and configure FirePHP to work with your debugging and some suggestions on browser extensions you can install to view the messages. Sample code is included showing you how to use the tool to send messages back to the browser including grouping messages, building tables and something that shows a conditional caching report message.

Wojciech Sznapka has shares his technique for creating colorized exports of Behat tests for use in PDF files:

Behat scenarios are one of the best ways to describe system. UML Use Cases or tons of pages in SRS documents are fine, but hard to understand from the begining, and even harder to maintain in the future. Behat eases this process and also gives opportunity to automate requirements verification. To write Behat scenarios you need a text editor. I've picked my favourite - Vim, which highlights *.feature files syntax. But business people mostly don't use Vim, so I need to figure a way, to expose scenarios in easy and pleasant way.

His solution involves setting up some printing options in vim to export the tests as a Postscript file, setting the "colorscheme" to the default setting so the colors will be retained. The result is exported (via the "hardcopy" command) and can be converted into a PDF (with a result like this).