On the SitePoint PHP blog they've posted a tutorial about the Theory of Constraints, how it can be related back to PHP and what it means for building effective code.

I had been reading The Phoenix Project, a great novel about IT (you read that right), which presents day to day IT and devops problems at a large Amazon-like company in a way which makes mortals understand the complexities and chaos of 21st century technology.

Without giving away any spoilers, at one point in the book the Theory of Constraints is mentioned. [...] The Theory of Constraints can be distilled to the idea that the chain is only as strong as its weakest link.

In the book it was phrased thusly: "Any improvements made anywhere besides the bottleneck are an illusion." For some reason, this resonated with me much more than the chain idiom. There’s just something about building something that’s ineffective that’s more relatable to me than breaking something that’s weakly built.

He goes on to talk about the subject of "factories" and "browsers", relating work done (or not done) on browsers to a factory where throughput of work isn't optimized. He then applies this back to PHP, mentioning some of the tools that can help optimize your workflow to prevent the same kind of factory backlog. This list includes services like Blackfire, XDebug and MySQL optimization techniques.

Frederick Vanbrabant has posted an interesting article to his site covering the "broken windows" theory, what it is and how it shows that some projects are just destined to suck.

Why is it that most legacy software projects are not really fun to work on? How can we stop that greenfield project to turn into one of those dull big projects? I would argue that it’s all in the foundation.

He starts with a brief description of the "broken windows" theory based on the 1982 definition proposed by James Q. Wilson and George L. Kellin. Basically it states that all it takes is one "broken window" to change the perceived value of something, even if it's a small thing. He then gets down to the code level and relates it back to some examples from the Slim framework project. In his examples he shows how it might look after a refactor and how removing best practices makes it harder to understand (breaking windows). To help prevent it, he recommends following the Boy Scout rule of leaving the code better than you found it and using automation to help find and fix the issues.

Leonid Mamchenkov has a post to his site showing how he solved an interesting problem in one of his recent projects: determining the order to use items based on their dependencies.

One of the projects I am working on at work presented an interesting problem. I had a list of items with dependencies on one another and I needed to figure out the order in which to use those items, based on their dependencies.

He gives the example of database tables where it would be required to export the tables so that the relations between them are maintained when imported back in. He gives some example data, a basic nested PHP array, and defines the relationships between them (just strings in this case). While he did solve the problem, he wasn't happy with the solution. Instead he went looking for other options and found graph theory to be a good match. He briefly cover what the theory involves and links to an example that basically does what he needs...but is written in Python. He finishes off the post sharing his refactoring of this logic into PHP including a recursive "dependency resolver" and the output showing the correct ordering for loading objects based on their dependencies.

The Laravel Podcast, with host Matt Stauffer and guests Taylor Otwell and Jeffrey Way, has posted their latest episode today: Episode 28: Documentation, JavaScript, & Conspiracy Theories.

In this episode, the crew discusses recent improvements to the Laravel documentation, Vue.js, ECMAScript 6, and a few conspiracy theories.

You can listen to this latest episode in a few different ways. You can either use the in-page audio player, download the mp3 or subscribe to their feed and get this and future episodes delivered directly to your reader of choice.

Przemek Sobstel has a recent post investigating an interesting theory in caching of any kind of application, not just PHP ones. He looks at the dogpile effect: when a cache expires and the database or host cannot catch up with so many non-cached requests coming in.

Implementing caching in web apps seems to be simple. You check if value is cached. If it is, you fetch cached value from cache and serve it. If it’s not, you generate new value and store in cache for future requests. Simple like that. However, what if value expires and then you get hundreds of requests? It cannot be served from cache anymore, so your databases are hit with numerous processes trying to re-generate the value. And the more requests databases receive, the slower and less responsive they get. Load spikes. Until eventually they likely go down.

He recommends using something called a "semaphore lock" to help prevent this kind of issue from happening. This lock prevents the removal of any stale content until after one process has finished refreshing the requested data. Only once the lock is released are the other processes allows to serve the fresh data. He includes some PHP pseudo-code that illustrates the point: trying to fetch the content, checking for the lock and releasing it when the single process is done with the refresh. He includes a link to a full implementation as well. He's also written up a full library, Metaphore, that integrates this into a full caching system.

Nikita Popov has a new (language agnostic) post to his blog today about one of the most powerful things you can use in your development - something that a lot of developers don't understand the true power of - regular expressions.

As someone who frequents the PHP tag on StackOverflow I pretty often see questions about how to parse some particular aspect of HTML using regular expressions. A common reply to such a question is: "You cannot parse HTML with regular expressions, because HTML isn’t regular. Use an XML parser instead." This statement - in the context of the question - is somewhere between very misleading and outright wrong. What I’ll try to demonstrate in this article is how powerful modern regular expressions really are.

He starts with the basics, defining the "regular" part of "regular expression" (hint: it has to do with predictability) and the grammar of the expressions. He talks about the Chomsky hierarchy and how it relates to the "regular" as well as a more complex mapping of expression to language rules. He talks about matching context-free and context-sensitive languages and unrestricted grammars as well.

In an opinion piece posted to the php|architect site Marco Tabini suggests that we (as developers) are doing it wrong as we move further and further away from the pragmatic side of programming into the abstract.

No matter how advanced the techniques that we use, there is always something that we could be doing better. [...] Which one is right? The real problem is that the answer to that question is, “yes.” That’s because it lacks a specific context in which it can be inserted.

He suggests that, in our quest to figure out what the perfect case for any situation, we stop focusing on the practicality of writing applications to accomplish goals. Sometimes it's not about getting the right theory behind the code - sometimes it's just doing it.

Jacob Santos has started a series of posts to his blog that focuses on the use of the opcode cache and language features in your applications.

The posts will be researched and go through multiple drafts for professionalism before posting. In this hope, it will strive to enable discussion that isn’t flaming and collective of the topic at hand. For as much as I can achieve at my level of writing skill and researching the topic at hand.

He he goes through the purpose of the posts, the areas he's going to focus on, some about the theory that will be used, and the implementation and documentation he'll provide through the series.

Jacob Santos has started a series of posts to his blog that focuses on the use of the opcode cache and language features in your applications.

The posts will be researched and go through multiple drafts for professionalism before posting. In this hope, it will strive to enable discussion that isn’t flaming and collective of the topic at hand. For as much as I can achieve at my level of writing skill and researching the topic at hand.

He he goes through the purpose of the posts, the areas he's going to focus on, some about the theory that will be used, and the implementation and documentation he'll provide through the series.

Despite the release candidates for PHP 5.2.0 marching on, Lukas Smith still has some misgivings about some of the functionality being introduced in the release - specifically about the fatal errors that are going to break a lot of (working) object oriented functionality.

Anyways I just posted the following email to internals in a list attempt to get some of the people with php-dev karma to lift their finger.

In the message, he notes the change he's looking for and a suggestion to get it included before RC6 of the series gets released (which has been released as of this post already).