StarTutorial.com has posted a new tutorial in their series introducing commonly used design patterns. In their latest article they cover the State pattern.

[The State pattern] allows an object to alter its behavior when its internal state changes. The object will appear to change its class.

In the example situation, a worker at a customer support company and his state when dealing with customers (happy/angry/moderate). They codify this in a SupportRep class with a "state" value to track his mood. They expand on this with some additional conditions for number of calls to change the state as time goes on. This requires several if/else statements to be added. They refactor this to reduce the clutter using the State pattern, passing off the logic to various "state" classes.

php[architect] magazine has posted the announcement about the release of their latest issue today - the July 2018 edition: Navigating State.

Articles in this issue include:

• "State in the Stateless World" by Luka Mužini?. See how to model complicated workflows with existing PHP packages.
• "Pro Parsing Techniques with PHP, Part Two: Fault Tolerance" by Michael Schrenk. See how to build error-resistant parsers.
• "Making Use of Our Robot Overlords" by Brian Thompson shares how he automated his team’s deployment.
• "MySQL Without The SQL—Oh My!" by Dave Stokes explains how to use MySQL as a JSON document store.

The usual columns have all returned with tips from the "dev trenches", security advice, community and contributions and if programmers are actually needed anymore. If you're interested in the content and want a small sample, check out the free article for this month (Dave Stokes' MySQL article). For more information about the article and to pick up a copy of your own, check out the php[architect] site

The Laravel News site has posted a tutorial that takes you deeper with factories when using the framework looking at the factory states.

I suspect that if you are familiar with Laravel that you might use factories and possibly even factory states in your application development. The documentation shows you the mechanics of using factories to seed and create test data, but there are a couple of guiding thoughts to using factories with your models effectively that I’d like to consider.

He starts with two options he sees for using factory states: making them with static values or using them to make simple models instead. He goes through these two options, introducing some of the basic concepts of each, how it would work and the code to make it happen. He also covers a few other approaches including the use of a trait to include the factory functionality directly in a class. He finishes the post with a few links to more information in the Laravel manual and other outside resources/tools.

In this new post to his site Herberto Graca has posted the latest part of his "The Software Architecture Chronicles* series, focusing this time on event-driven architectures.

This post is part of The Software Architecture Chronicles, a series of posts about Software Architecture. In them, I write about what I’ve learned on Software Architecture, how I think of it, and how I use that knowledge. The contents of this post might make more sense if you read the previous posts in this series.

Using events to design applications is a practice that seems to be around since the late 1980s. We can use events anywhere in the frontend or backend. When a button is pressed, when some data changes or some backend action is performed.

But what is it exactly? When should we use it and how? What are the downsides?

He starts by talking about the "what", "when" and "why" of using events to drive the architecture of the system, going into each of the topics in a bit more depth:

• To decouple components
• To perform async tasks
• To keep track of state changes (audit log)

He then goes on to talk about common patterns for event-driven applications including event notification, event-carried state transfer and event sourcing.

In a post to his site Benjamin Eberlei looks at global state in PHP using something called "context objects" and how they can be used as an alternative to true global state.

Global State is considered bad for maintainability of software. Side effects on global state can cause a very nasty class of bugs. Context objects are one flavour of global state. For example, I remember that Symfony1 had a particularly nasty context object that was a global singleton containing references to very many services of the framework.

As with every concept in programming, there are no absolute truths though and there are many use-cases where context objects make sense. This blog posts tries to explain my reasons for using context objects.

He starts by getting everyone on the same page by defining a context - the "circumstances in which something can be fully understood". He then moves into the world of context objects, talking about how they encapsulate the information other objects need to execute. They're essentially "container" objects that allow for more control that something like the normal PHP superglobals. From there he helps you define what kind of context objects you might need in your application and provides a real-world example from his own experience at Tideways.

The SitePoint PHP blog has a new post sharing the current state of PHP MVC frameworks in 2017. The article doesn't focus on any particular list of frameworks (though the more popular ones are used in the examples) and instead focus on the overall trends they've seen in frameworks and their use.

A simple question prompted me to sit down and write this follow up to my article from about a year ago: "Any thoughts about where things are today?"

He suggests that, while several of the major frameworks are still in active development and are seeing new features in recent versions, the front-runners are probably Laravel and Symfony. He includes trend numbers to back this up (popularity, basically) but also briefly touches on others: CakePHP, CodeIgniter and Zend Framework 2. He then breaks it down into two groups: Symfony/Laravel and "the rest". The post wraps up with a look at the rise of microservices, the "destruction of the monolith" and a more recent emphasis on scalability over just features.

The Symfony Finland site has posted a new tutorial showing you how you can share state in a Symfony application between Twig, React and other Javascript-based applications.

Front end development has certainly grown up in the last few years. UI logic is increasingly being moved to the client side, but the traditional server-rendered views aren't going anywhere soon. And they shouldn't.

The two methods will live alongside each other and you'll have to work with two worlds. Let's explore an idea how to make this pleasant to work with, by sharing state between Twig templates and JavaScript.

The post starts with some background on a case where this kind of sharing was a requirement and, while the initial version was scrapped, a prototype application was born. He details what this prototype showcases (which JS libraries) and links to the Javascript involved over on GitHub. They then get into the code examples showing the creation of an AppState object that handles the serializing of the state information and store the result in the database via a Doctrine connection. This value is then output to the pages that require it, making it available to the frontend application (Vue.js, React or plain Javascript).

In this new post to his site Kevin Schroeder thinks out loud and wonders if an idea of his is "a dumb idea" to be included into the PHP core - engine state caching.

I was consulting and I would see significant server resources consumed by bootstrapping the apps. Loading config files, loading dependent classes, setting up dependencies, initializing ACL’s, and the list goes on and on. One of the ways to negate the effect would be to cache a bootstrap object and then pull that object from the cache at the start of the request. However, the problem is that unserialization can actually end up taking more time than the bootstrap process itself.

He wonders if, after the initial bootstrapping happened, a method could be called (his example is "init_engine_state") that would cache the Zend Engine's current state and pass that to a callback function. This would cache everything - objects, variables, classes, etc - all pre-interpreted into memory and make them easy to reuse on future executions. What do you think? Share your thoughts in the comments of the post.

XPertDeveloper.com has a quick new post looking at a function that might be overlooked until it suddenly becomes just what you need - clearstatecache for clearing file state information in the current script.

For the functions like is_file(), file_exists(), etc PHP caches the result of this function for each file for faster performance if function called again. But in some cases you want to clear this cached information, for the task like getting the information of the same file multiple times in same page.

Other methods this cache effects include stat, file_exists, is_file and more. If the state of a file is changed during the course of the script - say it's deleted manually, not by PHP, your script may not recognize that. By calling clearstatecache, you refresh this cache and make it possible to see the latest file system info.

Ilia Alshanetsky has started to gather more and more information about PHP usage on the web as a whole (that was started here) and has been extended with some additional statistics he's done on the location of the domains he's collected.

The first step of the process has been resolving all of these domains, which is now complete. The next step is fetching the server information, which began, but will take some time to finish. However, even from the domain revolving data there is a lot of useful data to be gleamed, which is what I am now publishing. My first focus was on the world-wide distribution on these TLDs, which at least for me held a few surprises.

He includes a few graphs of the results he's found showing things like:

• The US has the most domains hosted followed with less than half by Germany
• The overwhelming majority of the PHP domains are in the .com area
• In the US, the state with the highest number of PHP-powered domains was Arizona with Clifornia coming in second

If you'd like something more interactive, he's also come up with a clickable world map of the results for you to click around on.