Sammy Powers has a new post to his site today showing you how to find and patch a bug in php-src, the source of the PHP language itself.

While he does provide all of the details in the post he also has created a screencast that walks you through the whole process as well. He breaks up the process into the different steps of the process:

• Find the bug (his was with the JSON handling)
• Submit a bug report (on bugs.php.net)
• Make a patch
• Run GDB
• Make a test
• Submit a PR and update the bug

He includes code and descriptions along the way and finishes out with further suggestions about feedback on the PR and how his own situation finished out.

Sammy Powers has a new post to his site today showing you how to find and patch a bug in php-src, the source of the PHP language itself.

While he does provide all of the details in the post he also has created a screencast that walks you through the whole process as well. He breaks up the process into the different steps of the process:

• Find the bug (his was with the JSON handling)
• Submit a bug report (on bugs.php.net)
• Make a patch
• Run GDB
• Make a test
• Submit a PR and update the bug

He includes code and descriptions along the way and finishes out with further suggestions about feedback on the PR and how his own situation finished out.

Jason McCreary has a post with an interesting perspective about code refactoring and what it means to refactor. He suggests that just changing code isn't refactoring and that it's more about changes in the observable behavior.

There was a good discussion on Twitter yesterday regarding a code contribution to the Laravel framework. It ended with some good questions about the distinctions between “refactoring” vs “changing” code.

While I want to focus on these distinctions, let’s first focus on the code change.

He gives an example of some code from the suggested change that reduced the number of lines in a before function call that still satisfied the requirements defined by the unit tests. He suggests that, while this change allowed the method to work as expected, it was more of a "change" than a "refactor". He suggests that because the code internal to the method changed that the "observable behavior" changed because of a special case with the return value. Existing tests didn't catch the change so it was assumed the refactor was successful even when it wasn't. Adding this test and fixing the issue then resulted in a true refactor and not just a change.

Given the symbiotic relationship between refactoring and testing, some consider the tests to be the requirements. So if all tests pass, you met the requirements. I think that’s a slippery slope. For me, the definition of “refactoring” again provides the answer through its own question - did we change the observable behavior?

Leonid Mamchenkov has an interesting post to his site detailing a plugin for the popular Composer package management tool that makes it easier to apply patches to the current version of libraries in use: composer-patches

composer-patches is a plugin for Composer which helps with applying patches to the installed dependencies. It supports patches from URLs, local files, and from other dependencies.

This plugin makes it so that, during the normal Composer installation flow, you can apply your own patches to fix functionality that may not be corrected upstream yet. It replaces the need to "fork and fix" in your own version of the repository and cleans up the process to a more automated flow. It can also help when working with multiple people on the same code that's not your own and apply their patches to evaluate their changes.

You can find more information about the composer-packages plugin in the README on its GitHub repository.

In his latest post Ben Ramsey suggests that "yak shaving" (a seemingly useless activity that lets you solve an immediate problem) is a core part of what we, as developers, do.

When I began my journey as a programmer, every task was fraught with problems, and I loved it. Everything was new, and every problem was an opportunity to learn and grow. It was great.

Somewhere along the way, though, problems became nuisances. As I grew older in life and my career, my tolerance for problems became lower, and my desire for things to Just Work became greater.

As I struggled to find a solution for the problem I had with Packer, Tate Eskew reminded me that yak shaving is a part of my job.

In his example he was working with Packer and hit a problem with the environment required to get it working. Instead of slogging through it he created a patch to make it work correctly with Amazon Machine Images.

Stephan Hochdörfer has a new post with a handy tip on speeding up the indexing Satis does on your local repositories to generate its information. His tip involves being more selective in the rebuild process, only indexing the projects that might need it.

In the last couple of months this [indexing] process takes quite a while because Satis rebuilds the index for every repo it knows about. Since we deal with quite a few repos containing a large amount of versions it slowed down the "build time". Obviously it does not make any sense to run Satis on a repo that has not changed. Since Satis was lacking this feature I started hacking on it and I am happy that the feature got merged into master this morning.

With his patch, you can specify only the repository you want reindexed via the "build" command. You can even specify multiple repositories to rebuild, allowing for a bit more automation around the process.

In this new post to the Liip blog Christian Stocker talks about how they use the popular application and server monitoring service New Relic with the HHVM (despite no official support).

As discussed in one of my last blog posts, we really like New Relic for performance metrics and use it a lot. Unfortunately there isn't an extension for HHVM (yet) and HHVM is becoming an important part in our setup. But - a big great coincidence - New Relic released an Agent SDK and with that, an example extension for HHVM and WordPress. That was a great start for me to get behind the whole thing.

He talks about writing a HHVM extension and includes an example of the implementation. Christian also talks about the challenges around profiling data and finding out where the requests "spend their time" in the execution. There's two solutions he suggests, but they each have their tradeoffs (a recompiled/patched version or a performance hit). He provides the extension they've built in this github repository.

Christian Weiske has posted information about a feature in the upcoming PHP 5.6 version of the language - large file upload support. This new feature allows files over 4GB to be uploaded correctly.

PHP version 5.6 brings support for file uploads larger than 2GiB. We can say "thank you" to Ralf Lang for the initial patch that fixes bug #44522 , which was open since 2008. During testing uploads of files with a size of 4 - 11GiB on my PHP-CGI setup, I noticed that files above 4GiB did not get uploaded correctly. Michael Wallner was quick to fix that bug, and now 5.6 has fully working support for big files.

PHP 5.6 is still in development and some other new features are slated to be added to it. You can find some of them listed in the RFC section of the PHP wiki.

Phil Sturgeon has a new post to his site today looking at a new feature that's included with PHP 5.5, Curlfile, and how he uses it with calls to the Facebook API (and a fix to make it cooperate).

One of the features implemented in PHP 5.5 was CurlFile, a nice addition to the Curl extension to allow you to specify specific arguments as a file for upload. In previous versions (pre-PHP 5.5) the syntax looked like this: [@/foo/bar.jpg]. A little digging around lead me to try this syntax: [new CURLFile('/foo/bar.jpg','image/jpeg')]. Sadly while Curl was happy with this, the Facebook PHP SDK (v3.2.2) was not. It turns out the SDK will turn ANY value you send it in that params array into a string.

To get around the issue, he worked up his own fix to the Facebook PHP SDK and submitted a patch to get it introduced into the tool. He also includes a reminder to filter incoming user data for things containing the "@" too to prevent unwanted file transfers.

In this new post to his site William Durand looks at creating a RESTful API with the help of the Symfony2 framework.

Designing a REST API is not easy. No, really! If you want to design an API the right way, you have to think a lot about everything, and either to be pragmatic or to be an API terrorist. It’s not just about GET, POST, PUT, and DELETE. In real life, you have relations between resources, the need to move a resource somewhere else (think about a tree), or you may want to set a specific value to a resource. This article will sum up everything I learnt by building different APIs, and how I used Symfony2, the FOSRestBundle, the NelmioApiDocBundle, and Propel.

It's a long post and covers things very completely with plenty of code samples and descriptions showing you how to use these pieces to make the API. He covers the major HTTP verbs (GET, POST, PUT & DELETE) as well as one of the lesser used ones - PATCH. He also looks at the HATEOAS documentation method and a brief look at using a simple client to do some testing.