On her blog Lorna Mitchell has posted an example of a basic generator written in PHP, a feature of the upcoming PHP version 5.5.

I really like the generators feature that's arriving in PHP 5.5, and since we're now into release candidate releases, it's actually not that far away. I've been speaking on this topic and I thought I'd share my trivially simple code example from my slides.

She includes an example of a very basic generator using the new "yield" keyword and how to implement it in a simple foreach loop. There's also a little talk about when is a good time to use generators in your applications (two examples: complex number calculation and working with large data sets a chunk at a time). For more information on how these generators will work, check out this page in the PHP manual.

PHPMaster.com has posted part two of their series looking at indexing in MongoDB databases (part one here) with some more advanced concepts Mongo makes available.

In part 1 of this series we had an introduction to indexing in MongoDB. we saw how to create, use, and analyze queries with indexes giving us a good foundation to build on. In this part, we'll take a look at a few more small but important concepts, like indexing on sub-documents and embedded fields, covered queries, and index direction.

They use the same "posts" collection from the previous article, showing you how to index it based on a "location" sub document and "embedded fields" inside of it. They also touch on complex sorting with a multi-field index and the idea of "covered queries." These are queries that all fields queried are part of an index as well as all returned. They finish up the article by showing you how to remove indexes too.

Christopher Martinez has a recent post to his site that covers some of the static analysis tools available for PHP including the PHP Mess Detector, PHP CodeSniffer and the PHP Analyzer.

I believe in writing code that is easy to understand, easy to test, and easy to refactor. Yes, I realize that the statement above is pretty general and open to interpretation. Not everyone needs external tools to ensure quality in their code...but, I work on things from time to time that have absolutely no tests. [...] For whatever reason, this happens a lot more frequently in the PHP world. I'm guilty of not writing tests and checking how I write code, sometimes, too. Things are bright, though, for the PHP community - for quite some time now, we've had fantastic tools that assist us in writing better code.

He covers each of the tools, talks some about what they're good for and gives examples of their use, including output. He also talks some about the Pfff set of tools created by Facebook. He also talks some about how these tools fit into his daily work as a part of his pre-commit hooks in git.

New on PHPMaster.com is the first part of their series about indexing in MongoDB, a method for optimizing your collections to make querying them even faster. They cover the five main types of indexes and situations where they can help.

Indexing is one of the more important concepts of working with MongoDB. A proper understanding is critical because indexing can dramatically increase performance and throughput by reducing the number of full documents to be read, thereby increasing the performance of our application. Because indexes can be bit difficult to understand, this two-part series will take a closer look at them.

They look at the default "_id" index, secondary, compound, multikey and multikey compound indexes. Example documents and results are included as well as some of the options that can be set on the index types to tweak performance. They finish up the article with a look at some of the limitations and considerations to think about when using indexing, including that they cannot be used with regex queries.

On DZone.com Giorgio Sironi has written up a post about some testing he's done with the ""PHP Refactoring Browser" (more on that here) on some basic code examples.

IDE proponents love, in fact, an Integrated Development Environment that provides all the functionalities you need while writing and editing code; the followers of the Unix way typically write code in Vim while augmenting it via plugins where feasible and leveraging external tools that do one thing, and do it well. [...] Automated refactorings in PHP were out of the league of Vim and Unix users; thanks to Qafoo, however, a new open source tool is able to edit code with predefined refactoring recipes: PHP Refactoring Browser.

He goes through some of the basic features and functionality of the browser, setting expectations a bit. He shows how to get it installed (via Composer) and the results of some of his testing. Rather than including them all in the post, he opted to make actual commits on github of the changes.

In a new post to his site Benjamin Eberlei shares an opinion about traits, noting that they're basically the same as static functionality when it comes to several things like coupling, not being testable and being a "global state" container.

I used to look forward to traits as a feature in PHP 5.4, but after discussions with Kore I came to the conclusion that traits are nothing else than static access in disguise. They actually lead to the exact same code smells. Familiar with the outcome of too much static use, we should reject traits as just another way of statically coupling your code to other classes.

He includes some code examples showing traits in use in an example controller to handle a simple redirect. He points out at least six different issues with just this simple implementation. He rewrites it as "static" code to help prove his point. He comes to the conclusion that, much like static methods, traits should be avoided and instead aggregation should be favored.

Anna Filina has a new post to her site that helps to clarify the definitions between functional, unit and integrations tests of your application's functionality.

I have recently read a blog post claiming that functional tests are not "true" tests. The author also claims that unit testing shows you where the problem is occurring, while functional testing simply identifies that a problem exists. This argument is deceptive and the conclusion dangerous. Different kinds of tests are not mutually exclusive. One is not superior to the other. They have different goals and can happily coexist. Let me explain the kinds of tests so that you could make enlightened decisions.

She covers each type of test in detail, noting the goal of that particular type and some examples of the kinds of things they might test. She starts with the highest level, functional testing, then jumps down to the lowest - unit testing. She finishes up the post defining "integration tests" as tests that ensure you're integrating correctly - that you're using the API provided by the tool in the right way and that it's working as expected.

Adam Bard has written up a post that takes the same small application (a "Nurblizer") and writes it as a web application in four different languages - PHP, Python, Ruby and Clojure. His point is less about which is "best" but more to show the differences between them.

Here's a toy program I wrote implemented in PHP, Python, Ruby, and Clojure. I hope it's helpful for someone who knows at least one of those and wants to learn another. The program is called "Nurblizer", and it does one thing: Accept free-form text, and attempt to replace all words but the nouns in said text with the word "nurble". It's up and running at http://nurblizer.herokuapp.com

He includes the source for each language's version using Sinatra for Ruby and Flask for Python but for PHP and Clojure it's just straight code. For each he briefly explains what its doing and a bit about how it relates to the examples from the other languages. He also points out a Hacker News discussion that's popped up about the examples.

On PHPMaster.com there's a new tutorial that introduces you to React, the PHP-based event-driven non-blocking socket tool that's similar to some of the functionality Node.js provides. The article is a very basic introduction but can help get your feet wet with the tool.

For the past couple of years, Node.js has been drawing increasing amounts of attention as a promising web technology. While it has some strengths, like being event driven, some people just want to stick to PHP. For over a year now, however, there has been a similar project for PHP named React. React is mostly coded by Igor Wiedler, who is also a prominent contributor to the Silex framework. While reading through the React examples, it really does look similar to Node.js.

Included in the post are the instructions on how to get the latest version of React (via Composer) and the code to create a sample server that just writes out a string with a counter for the number of requests made. There's also an example of a "keystroke logger" for all data that's coming across the connection. The author (Igor) notes, however, that he wouldn't recommend using React in production, though, as its target is mostly those working with "cutting-edge technologies" rather than more stable applications.

On the Setfive site there's a recent post from Ashish Datta about some thoughts around array functions and closures for callback methods.

The other day, I was hacking away on the PHP backend for the "Startup Institute" visualization and I realized it was going to need a good deal of array manipulation. Figuring it was as good a time as any, I decided to try and leverage PHP 5.3+ new closures along with the array_* functions to manipulate the arrays. I'm not well versed with functional programming but I've used Underscore.js's array/collection functions so this is mostly in comparison to that.

He gives a sample data set he's pulling from - basic user data - and goes through a few different actions that can be taken on the data (with code examples for each): sorting, mapping and filtering. He shows the use of closures as the callback methods instead of defining them separately and passing in their names.