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.

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.

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.

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.

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.

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.

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.

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.

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.

In this day and age, it's quite normal for a developer to have an understanding of consoles, and how to issue basic commands. But what if you could code your own custom commands to improve your workflow? If we look back to Laravel 3, you might remember that it offered tasks. Tasks were extremely helpful, but still came up short for more complex operations. Thankfully, Laravel 4 packs a beefed up Artisan that will make your life as a developer so much easier!

They start by introducing you to Artisan and what it can do already, then move into how you can create you own custom commands (with code examples). They show you how to add a description, coloring for the output, work with arguments, use confirm/question prompts and working with dependencies you might need.