The Laravel News site has a new post sharing the application of "clean code" concepts to PHP with a few handy examples. These suggestions are pulled from this set of guidelines.

Clean Code PHP (jupeter/clean-code-php), is a guide based on the book Clean Code: A Handbook of Agile Software Craftmanship, a classic programming book about writing maintainable code by Uncle Bob Martin.

The clean-code-php guide is inspired by a JavaScript adaptation, clean-code-javascript with PHP-specific features.

Examples they show in the post are around unneeded context, the number of function arguments and functions doing more than one thing. They also include a word of warning about these and other "clean code" suggestions, pointing out that they're mostly matters of opinion and not hard and fast rules to enforce every time. The post ends with links to two "clean code" resources for more reading: "[Clean Code]"(https://amzn.to/2wFCjo4) and "The Clean Coder: A Code of Conduct for Professional Programmers".

The SitePoint PHP blog has posted a new review of Appserver, a "production-ready PHP application server" that includes a web server written in PHP. Appserver is a downloadable project that can be run on any server that already has PHP installed.

You’re probably asking, “Why is appserver paradigm changing?” The answer is, because it tackles the last frontier of PHP application development: high performance for large applications from a server resource optimization and collaboration perspective. This is the realm of PHP development which a good number of professional PHP developers have been calling for, like Manuel Lemos in his “PHP7 Features and Release Date” blog (see the section about a “Standalone Multi-threading Web Server”) and Fabien Potencier, father of Symfony, in his presentation “My Take on PHP”, where he notes he is also working on such an application server solution himself. Well, look no longer Fabien, we already have a really good solution with appsever.io.

In this first part of a new series author Scott Molinari introduces some of the basic concepts behind an appserver in general and helps you get the software installed. He talks about threading and compares the typical PHP server stack against the appserver approach. The main difference is that, with the appserver, there's more control over what's destroyed for each request, allowing more control over the execution and reuse of components. He points out that it does require a bit of different kind of thinking to write code that works with an appserver. He finishes off the post with a few quick steps to getting the latest version of the Appserver build into a local VM via the apt-get package manager and starting it up.

Alejandro Celaya has shared some advanced concepts when using Composer that you may or may not know this popular tool could do.

Composer is The Tool in any modern PHP project. Nowadays I can't imagine to work without it. It is much more powerful than some people think, easily solving the integration of third party components in our projects, but there are some advanced features that are less known. I'm going to try to explain some of the best practices and mechanisms bundled with composer.

His list of more advanced techniques and concepts includes:

• Globally installing composer
• Create the composer.json file (with composer init)
• Production environments (and flags to customize the installation)
• Executing CLI scripts

There's several more items in his list and each includes a description of the feature/practice and commands or code where appropriate.

Anthony Ferrara has posted what he calls a beginners guide to MVC for the web, a tutorial that introduces to you the basic concepts behind the Model-View-Controller design pattern and how it should fit in with the SOLID design principles.

There are a bunch of guides out there that claim to be a guide to MVC. It's almost like writing your own framework in that it's "one of those things" that everyone does. I realized that I never wrote my "beginners guide to MVC". So I've decided to do exactly that. Here's my "beginners guide to MVC for the web".

He starts with his first lesson, his most important one really - you don't need "MVC" (the concept, not the pattern...he notes them differently). He then gets into what the MVC pattern actually is and describes each piece and how they fit together. Following that, he talks about "MVC" as a concept and how it's different from MVC, the design pattern (hint: the pattern describes one implementation of the MVC ideals). He talks about the role of state in the MVC structure and how the implementation of the MVC idea is slightly different in the various "MVC frameworks" out there.

There is a very useful lesson that MVC brings: Separation Of Concerns. Meaning that you should separate different responsibilities into different sections of your application. Separation of Concerns is a necessary step in dealing with Abstraction. Instead of latching on to MVC, latch on to abstraction. Latch on to separation of concerns. Latch on to architecture. There are far better ways to architect and abstract user interaction for server-based applications than MVC.

On the Qafoo blog today Tobias Schlitt talks about dynamic dispatch, what he calls a "fundamental concept of OOP" to help provide clean, clear interfaces in the code.

I want to use this blog post to illustrate the concept of dynamic dispatch which I use a lot recently to motivate creating clean OO structures in my trainings. In my experience, this helps people to understand why we want to write code in this way. After that I will show why traits are bad in this direction.

He explains the concept of "dynamic dispatch" by starting from the beginning...with procedural PHP code. He looks at the usual flow of this kind of application that call shared functions in a "top down" fashion. He looks at what would happen if new logging needs were introduced (use a new method? patch the current one?) and the dependencies that can be introduced because of it. With this in mind, he continues and talks about how the "dynamic dispatch" happens during the code execution, splitting the log request based on the information it's given instead of different implementations for each. He points out that using a trait doesn't allow for this abstraction and instead embeds the code into the class itself, re-introducing the original problem.

Adrian Schneider has started up a new series of posts on his blog today with part of of his look at models in the Zend Framework.

The power in Zend Framework lies in its uncompromising flexibility. However, evidently, this also means its very difficult for new ZF users to pick up the framework and hit the ground running. The most common question I see is usually "where is the model?". The goal of this post is to show some examples and hopefully some new ideas on how to tackle models. There is no one-size-fits-all solution folks. Let's look at some options and some background...

He starts off with the concept behind models, explaining how they're just a place to get your data from whether it be in a database or other resource. Processing that happens to your application's data belongs in a model. He illustrates a database model that uses the Zend_Db_Table component to connect to a backend database. There's only a bit of introductory code in this first post, so expect that to come in the parts to follow.

The DevX website has recently posted this tutorial - a look at simple internationalization for your website.

If you develop Web applications that have an international target audience, then you have to take internationalization into account—a process that includes avoiding date/time or currency confusions and delivering all text pertinent to the user interface in the user's preferred language. Applications that can grow international traffic and improve revenue must respect their clients' needs.

They use the I18N PEAR package to handle most of the hard work and include the howto on grabbing the package, the structure and how to use it to get a country name from a code, work with the translation of numbers, currency and changing up date/time strings.

According to Felix Geisendorfer's newest post on the Debuggable blog, he thinks that "private and protected methods and properties are one of the most stupid concepts of OOP."

This is a thought I first shared at CakeFest Orlando this year, but could not explain properly at the time.

He illustrates with an example of a protected "balance" variable in a BankAccount class. Sure, it's marked as private but less skilled programmers might not use it that way. He recommends a method without the getters/setters to help make the usage of the variable a bit simpler. He also suggests that using protected/private scoping helps to promote "crappy code" - using them to provide a sort of protection for code that you either don't want getting used or hiding it away so the API can't get at it.

Jonathan Snook points out a new take on working with tags on a site - a focus cloud.

With this fairly broad classification I set about working out exactly what a Focus Cloud should show. To me the name could only suggest one thing. It shows the area which currently is receiving the most Focus! [...] So a Focus Cloud should show not what has been the most popular tags overall, but what is the most popular tags at present. What is your current focus.

The post not only includes the theory behind these focus clouds but also has some PHP code to back it up (using the del.icio.us interface and tags as the foundation of the cloud's contents). The full code for the cloud can be grabbed here.

Jonathan Snook points out a new take on working with tags on a site - a focus cloud.

With this fairly broad classification I set about working out exactly what a Focus Cloud should show. To me the name could only suggest one thing. It shows the area which currently is receiving the most Focus! [...] So a Focus Cloud should show not what has been the most popular tags overall, but what is the most popular tags at present. What is your current focus.

The post not only includes the theory behind these focus clouds but also has some PHP code to back it up (using the del.icio.us interface and tags as the foundation of the cloud's contents). The full code for the cloud can be grabbed here.