Christopher Pitt has posted a new article on Medium.com about when an "array is like an adventure" when in the context of co-operative PHP multitasking. In it he shows how to make code work asynchronously with out the use of extensions, only generators.

Last week I got the opportunity to share recent work with my colleagues, at SilverStripe. I was going to present Async PHP today, but since I covered ReactPHP last week; I decided to talk about something slightly different. So here's a post about cooperative multitasking.

He starts with some basic arrays and other things that act like them and can be iterated through (Traversable). He talks about implementing custom iterators to act the same way and the use of IteratorAggregate to "cheat" a bit when making them. The he gets into generators, showing how they can be used to iterate similarly. He shows how it's possible to send data to a generator, throwing exceptions inside them and the use of "coroutines" to create asynchronous code. He builds up a queue system with this method and shows how they execute with some simple echo output. He also shows the use of RecoilPHP, another coroutine-based library, to replace the main kernel for a ReactPHP script. He also mentions IcicleIO as another option.

Julien Pauli has a recent post to his site that "zooms in" on objects and classes with a look behind the scenes at how they're handled in the PHP source (at the C level) with plenty of code examples and explanations as to how they work.

Everybody uses objects nowadays. Something that was not that easy to bet on when PHP5 got released 10 years ago (2005). I still remember this day, I wasn't involved in internals code yet, so I didn't know much things about how all this big machine could work. But I had to note at this time, when using this new release of the language, that jumps had been made compared to old PHP4. The major point advanced for PHP5 adoption was : "it has a new very powerful object model". That wasn't lies. [...] Here, I will show you as usual how all this stuff works internally. The goal is always the same : you understand and master what happens in the low level, to make a better usage of the language everyday.

The article does a great (if lengthy) job of covering everything that happens with PHP's objects and class system, including stats about memory consumption. He includes both the PHP code and the C code to illustrate what's happening with classes, interfaces, traits and object methods/attributes (including object references). He also talks about what "$this" is and how class destructors are handled.

In his latest post Piotr Pasich shares some handy tips (and tools) to help you use Composer to do some of the common tasks you might use Ant or Phing for.

I decided to start with something uncomplicated - a simple solution that could help me solve a prosaic, but annoying issue. For instance, XML format. No, I won't fight with it. I see it as great and practical, however mostly I don't need so sophisticated code to cover my needs - the yaml usually fits the purpose. [...] Yet, do I really need this flexibility [of XML configuration] when I use vagrant or docker to maintain the same environment as on the production? For 90% of PHP projects probably I won't use all of the features of the virtualization tools. I only want to install necessary libraries, check the code quality before committing or introduce fixtures. Most of those points are easily feasible in composer.

He then shows how to execute these checks through the functionality included with Composer to run custom scripts. His example measures the quality of the code based on the results first from a single run of the PHP Mess Detector (phpmd) command. He then extends this with the open source contribution he mentions earlier with his CodeQualityThreshold library allowing not only for more checks (phpmd, phpcs, phpcpd, etc) but also allows you to configure the thresholds for each class if desired. He includes an example of it in action and screenshots of the results.

Derick Rethans has continued his series looking at the code coverage handling that XDebug and PHPUnit make available, allowing you to find the spots in your code not tested much easier. In this new post he talks about a new feature coming to the XDebug tool - branch and path coverage.

Picking up from where we left last time, in this second article we will look at some upcoming functionality in Xdebug. Sebastian has been pressuring me for years to add branch and path coverage to Xdebug, with issue #1034. In the post I will show you what "branch and path coverage" is, and how it helps.

How does this new type of coverage differ from the current functionality? Derick goes on to explain the difference via a simple example (and its resulting coverage). In the first example, using the XDebug available today, shows a fully tested function despite not all paths being testing correctly (a false coverage report). He gets into the "under the covers" changes he's made including how the opcodes are reported and changes he's made to the VLD to make it handle the branching smarter and make coverage more than just a "lines covered" metric. He shows an updated graph of the new coverage/branch flow and what a resulting coverage report might look like with the new "Paths" reporting.

In his latest post, Stefan Koopmanschap shares an interesting idea he thinks more software developers would do well to adopt - Use what you can (or "don't do it yourself).

In her book, Amanda Palmer talks about DIY, and how when you start asking for help, Do It Yourself is a strange term. Instead, she suggests UWYC, which stands for Use What You Can. I think software developers can learn a lot from this mindset. As Palmer says: "I have no interest in Doing It Myself." This is exactly how we should approach software development.

He points out that, for the most part, the tasks and needs of most software have been solved. There already exists functionality to do those things, so why would you need to create your own? By doing so, you only increase your load as a developer, shifting the hard work of maintenance and improvement into your already loaded work schedule. He does make a good suggestion for using other people's code, though: filter the solutions (according to criteria like following good practices, documentation and if it's in active development).

We had been looking into code quality checking tools for a while here on SitePoint - most recently in a series on Jenkins, but none of those could do what a project I've only recently found out about can. PhpMetrics uses D3 and some sophisticated analysis algorithms to scan your application's code and output intricate reports about it.

He walks you through the install (via Composer) and how to clone two example projects, Laravel and Symfony, to evaluate. He includes the command line to run the evaluation and plenty of screenshots showing the results for things like:

Cyclomatic complexity

Abstractness

Maintainability

Code density

He uses the results from these two projects in his examples and, at the end of the post, summarizes and compares the results it produced.

Eric Wastl has written an open letter to software developers out there in response to this post and sharing some of his own thoughts (and corrections) about what it suggested.

Dear [Software] Engineers, Your job is not to write code. Rather, your job isn't only to write code. Your job is to design and build software, and one of the steps in that process happens to be explaining to a computer how to do its new job. An article appeared on Medium recently that writing code isn't really a big deal and it's not really what your job is about. It is. You can smell "Product Manager" miles before the signature line of the article. The article goes on to talk about how your job is to improve your products for your users. This is not the job of an engineer - this is the job of every person at your company.

He talks about some of the "other jobs" the Medium article suggests a software developer be doing including making sure the "code runs the way it should" (devops, testing, etc) and that it "actually gets merged and pushed into production" (a release engineer). He points out the dissonance between the request for things to "run under all conditions" and when it makes sense to add analytics to your code.

Because your job is to write code. Your job is to write the best code you can, as quickly as you can, within budget, meeting all of the expected features, in a maintainable way, and a million other things, and still make the users happy. [...] Your job is to tell someone when you make a mistake. Your job is to work together with your testers and with operations and with product and finance and, yes, even the other engineers. Your job is to figure out what product will ask for before they ask for it, and build the code so that if and when they do, adding the feature is easy because the code wasn't written in a way that requires a year-long refactoring project to do it in a way that wouldn't make Cthulhu literally gleeful at the thought of it.

In this new post to his site Jani Hartikainen suggests a few things you can do to help make your code "self-documenting" and more readable down the line (or for other developers).

Isn't it fun to find a comment in code that's completely out of place and useless? What if you could write fewer comments and still keep the code easy to understand? One of the primary ways to do this is making your code-self documenting. When code is self-documenting, it doesn't need comments to explain what it does or its purpose, which is great for making the code easier to maintain. As a bonus, with fewer comments, it's less likely they'll be crap! In this article, I will show you several ways you can make your code document itself.

He breaks it up into a few different sections, each with some code examples and descriptions:

Naming things

Extract functions

Introducing variables

Defining class and module interfaces

Code grouping

He finishes up with a few smaller tips including "don't use strange tricks" and "use named constants". What do you think makes for good self-documenting code? Share some of your own thoughts on the post.

Over the past weeks, Taylor introduced many great changes and new features that we'll be able to use in the new version, firstly numbered 4.3 and later 5. According to the framework's six month release cycle, it should had hit stable late this month or in early December. Because of that, I started to play with it and to apply the changes to make my application use it.

However, a couple of days ago, Taylor wrote a blog post on the Laravel's blog saying that because of the importance of this release, the release date will be postponed to January. Considering this, everything you'll read here MUST NOT be applied to applications that are currently in production.

He starts with some of the major differences, including changes in the dependencies required and the removal of the "start.php" file for bootstrapping the application. He talks about the changes in startup and shutdown as well as autoloading. He looks at directory structure changes and the addition of a base namespace. He then gets into how to fix these issues, one at a time, including code and configuration changes that need to be made. This includes updates to the facades, changes for middleware, environment configuration, pagination and routing. There's lots of other changes happening with Laravel 5, so be sure to check out the full post if you're interested in the steps you might need to take when this latest version is released.

NetTuts.com has completed their series on refactoring with the posting of part eleven today: "The End?" This post finishes off a series where they've moved from the most basic level of testing out to a complex set of tests that can ensure your code's quality and functionality even after making their recommended refactoring changes.

In our previous lesson we've learned a new way to understand and make code better by extracting till we drop. While that tutorial was a good way to learn the techniques, it was hardly the ideal example to understand the benefits of it. In this lesson we will extract till we drop on all of our trivia game related code and we will analyze the final result.

They start off by "attacking the longest method" (wasCorrectlyAnswered) by starting the testing process. They make some simple checks to ensure the output is correct for various circumstances and values. With these tests in place, they safely refactor the method, splitting it up into functional pieces and completely dropping the method in favor of more targeted handling. They finish off the post with a look at some final results and comparing the refactored code with the original on things like lines of code, complexity, dependencies and structure (using this tool).