The Laravel News site has posted a tutorial that offers some advice on how to prioritize fixing bugs and errors in your applications.

One major problem is that prioritizing errors isn’t always clear. Figuring out how much negative impact a bug is really causing is important to answer because not all bugs are worth fixing.

That’s why having a solid workflow in place for prioritizing bugs is so important. In order to confidently allocate your engineering resources on bug fixes and feature building, you need to understand the scope of each application error, and its impact on your customers. Then you can definitively say particular bugs are high enough priority that they should be scheduled into a sprint alongside your work on building new features.

The article is then broken down into a few different sections, each with a few points underneath:

• Get setup with smart error reporting from the start
• Focus your error inbox to keep it actionable
• Prioritize the most relevant errors first
• Prioritize errors by moving them into your debugging workflow

The post is sponsored by Bugsnag so there's some of the content that suggests using their service but the advice is sound for any kind of error handling workflow.

TutsPlus.com has continued their "Building Your Startup with PHP" series today with this latest tutorial covering the creation of an issue tracking and feature planning process with the help of the Anana service.

Even for a one-person startup, it helps to have more than a spreadsheet (or paper) to track issues, ideas, and bugs. A few years ago, I'd used Lighthouse for my grant-funded NewsCloud Community Starter Project. Last year, I'd been introduced to Asana during a consulting gig.

[...] Eventually, I found my way and discovered the tool works well whether you're working with a variety of people or just solo. In today's episode, I'll walk you through how I began using Asana for Meeting Planner. I use Asana not only to track issues but to organize them and plan for the future. I also use it to track and process bugs.

He walks you through getting started with the service (they have a free tier) and how to set up your first project. He includes examples of task creation, tagging tasks and tracking bugs right inside the service. He then uses it to create a "release plan" for the next version of the Meeting Planner application. He wraps up the post talking about what's next on his side for the Planner application and its funding goals.

The SitePoint PHP blog has a new tutorial for the Composer users out there talking about Composer plugin development and how they can add functionality to this already powerful tool.

Composer is the sharpest tool in the toolbox of the modern PHP developer. The days of manual dependency management are in the distant past, and in their place we have wonderful things like Semver. Things that help us sleep at night, because we can update our dependencies without smashing rocks together.

[...] Even though we use Composer so frequently, there’s not a lot of shared knowledge about how to extend it. [...] Yet, recent changes have made it much easier to develop Composer plugins. [...] So, today I thought we would explore the possibilities of Composer plugin development, and create a fresh bit of documentation as we go.

He walks you through the creation of a simple plugin: one that tracks users and the dependencies they require. He shows you how to create the initial plugin boilerplate and the creation of the addDependencies and activate methods. These grab the dependencies being added and send the information off to a remote site.

Derick Rethans has posted another in his series covering the latest release of the Xdebug debugging tool for PHP, version 2.3. In this new article Derick introduces the "shared secret" handling, a custom string that for the "XDEBUG_PROFILE" that can trigger the the profiler to start.

Xdebug's profiling and trace file capabilities can both be triggered by a cookie, GET or POST variable, as long as you have enabled xdebug.profiler_enable_trigger and/or xdebug.trace_enable_trigger. With these triggers enabled, basically anybody could initiate a profile run, or trace file, by simply sending the XDEBUG_PROFILE or XDEBUG_TRACE cookies with an HTTP request. Although you should not really run Xdebug in production, you can see that this is not an optimal solution. Xdebug 2.3 adds supports for shared secrets for the trace file and profiler triggers through the xdebug.trace_enable_trigger_value and xdebug.profiler_enable_trigger_value.

He points out a browser extension, The easiest Xdebug, that already has support for this new feature. He also mentions two other tools but they have yet to integrate support for these shared secrets (but will soon hopefully): Xdebug halper and xdebug-helper-for-safari .

On the HHVM blog today there's a new post shows how far along they are with parity with the PHP language based on the tests from a sampling of several large PHP-based projects.

HHVM has a large suite of unit tests that must pass in several build configurations before a commit reaches master. Unfortunately, this test suite passing doesn’t tell you if HHVM can be used for anything useful – so we periodically run the test suites for popular, open source frameworks. [...] The frameworks test page is now public, as is the JSON data backing it (which you’re welcome to use).

They look briefly at what exactly is tested (latest stable version, with exceptions) and how it all works. The tests are run once an hour and are based on a completely clean build of HHVM in "csv" mode. The results of the tests are automatically pushed into the MySQL+Memcached system reporting system, accessible via the JSON API.

If you'd like to help with testing for the upcoming PHP 5.5.0 version, they've announced the release of the latest alpha on the PHP.net site, ready for download and test execution.

The PHP development team announces the immediate availability of PHP 5.5.0alpha2. This release adds new features and fix some bugs from alpha1. All users of PHP are encouraged to test this version carefully, and report any bugs in the bug tracking system.

You can see the full list of the changes in 5.5.0 (so far) in the NEWS file including things like using empty on return values, enabling systemtap by default for dtrace probes and optimized variable accessing. They need your help to make this upcoming release even better, so if you'd like to help out and test, go grab the download (Windows builds).

There's an interesting post on Eric Holk's blog talking about how we read code - a look at the results from a psychology experiment that tracked the viewer's eye movement as they scanned through code (complete with video).

The goal is to figure out some way of measuring what features in programming systems help programmers understand wht they are doing, and how this can be used to make systems that lead to higher quality software. Mike is currently running an experiment where he shows people several short Python programs and asks them to tell the output of the program. The test subject is sitting in front of an eye tracker, so afterwards Mike can see where you were looking at various times during the experiment.

The results are pretty interesting and Eric likens it to a sort of "just-in-time compilation" that the mind is doing as it reads through the code, not a straight forward read through. The timing of the read is interesting too, noting that once something is figured out, it's run through faster the following times.

One aspect he’s interested in is how the approach of inexperienced programmers differs from that of experienced programmers. For example, there seems to be some evidence that following variable naming conventions helps experienced programmers understand the code much quicker, while breaking these conventions leads to a severe penalty. On the other hand, inexperienced programmers seem to take about as long regardless of how the variables are named.

This study is still going on and, if you're in the Bloomington, Indiana area and would like to lend your eyes to the cause, send an email over to Mike Hansen (more on the subject on his blog here).

This recent post to the PHP::Impact blog looks at a way you, the Zend Framework user can check to see which files are dependencies in your application. Their example uses the Zend_Debug_include component to find out during run-time which of the libraries/components your script might need.

The concept behind Zend_Debug_Include is that the dependencies for each source file are stored in a separate file. If the source file is modified, the file containing that source file’s dependencies is rebuilt. This concept enables you to determine run-time dependencies of files using arbitrary components. This solution is also useful if you are deploying your application using Linux packages.

He has it broken up into a few different kinds of tracking examples - file dependencies, package dependencies and external dependencies. There's also a tip for the URL adapter showing how to make a different file for each request that comes through.

The PHP-GTK Community website has an announcement about the launch of a new PHP-GTK related forum at http://phpgtk.opsat.net/.

Another PHP-GTK forums site has sprung up [...] to provide a very informal environment, where posting will not need registration, or the use of a real identity. The site currently offers 3 PHP-GTK sections, and one general section.

The forum is also linked to back and forth with the PHP-GTK Community site whenever a a cross-post is made from the forum.

The PHP-GTK Community website has an announcement about the launch of a new PHP-GTK related forum at http://phpgtk.opsat.net/.

Another PHP-GTK forums site has sprung up [...] to provide a very informal environment, where posting will not need registration, or the use of a real identity. The site currently offers 3 PHP-GTK sections, and one general section.

The forum is also linked to back and forth with the PHP-GTK Community site whenever a a cross-post is made from the forum.