On the Happyr.com Developer blog Tobias Nyholm has written up a tutorial showing how you can use functionality included in the Symfony framework to define access control rules in a database using voters and values stored in the database.

I was recently at a PHP conference in Odessa where I met many great developers. One of them asked me a question, that the answer was not obvious. His use case was that he wanted to use Symfony's Access Control configuration to restrict access in his application. But he also wanted to configure the rules dynamically.

Since all the configuration in Symfony is cached with the container for performance reasons, we could obviously not allow a use a database to somehow “print” new configuration. We need to do something smarter.

Voters are a part of the Symfony security component and are set up as a service in the Symfony DI container. When a route is defined in the access_control section, the matching voter is called and the access granted/denied state is determined by values from the token and subject provided (from the database).

In a post to his site Tomas Votruba shows you how to test the PSR-12 standard on your current codebase using some custom PHP-CS-Fixer rules. The PSR-12 standard is a recommendation from the PHP-FIG group about consistency in coding styles and formatting. It expands and replaces the previous PSR-2 standard.

The standard is still behind the door, but feedback, before it gets accepted, is very important. After accepting it will be written down and it will be difficult to change anything.

Try PSR-12 today and see, how it works for your code.

Korvin Szanto, a developer working on the PHP-CS-Fixer project, has put together a commit with the rules to update and enforce the PSR-12 coding standard. The post shows how to install these rules and how to change up your YAML configuration to include them. He also includes a discussion about agreeing/disagreeing with the coding standard idea and gives examples of two rules he personally doesn't agree with.

On the Toptal.com site there's a new post from author Timofey Nevolin sharing hist list of Eight Rules for Effective Software Production to follow to help keep your development process flowing well based on some of his own experience.

During the course of my career, I’ve participated in multiple real life software projects and observed how things are done on all levels: decision making, practices adoption, team building, recruiting, skill distribution, etc. Obviously, different approaches yielded different results. Being an improvement-oriented type of person, I noticed and collected the most effective practices and best practical tricks to help me up in my work.

Learning from observation is a hard and lengthy way to do it. I would be extremely happy to pick this knowledge earlier from books instead. Unfortunately, I found none on the topic. So I decided to share my experience with other seekers of this kind of knowledge. Hopefully, it’ll save them few years of personal research.

His list of eight, targeted mainly at those needing a productivity boost, includes rules such as:

• Understand the IT Mentality
• Stop Wasting Time on Formal Time Estimation
• Understand the Cost of Switching Tasks and Juggling Priorities
• Use Architecture Reviews as a Way to Improve System Design

He finishes with one of the more important rules to follow: valuing those on the team and respecting them for what they bring to the table.

Mohammed Said has a new post to his site sharing how you can add validators conditionally in Laravel based on different requirements using the "sometimes" method.

Laravel's validation library is very powerful and easy to use, using a few keystrokes you can build a strong defence around your application, preventing invalid user input from corrupting the application flow and potentially introducing bugs.

In this post I'd like to highlight a trick related to conditionally adding validation rules, this trick is specially important since I've seen many people on Laravel's GitHub repository opening issues complaining about an un-expected validator behaviour.

He sets up a simple scenario where the "subject" value is required allowing for a custom value but validating the length if custom is selected. He then shows how to modify things to use the "sometimes" method for conditional checks for the same "custom" checking. He also shows how to pass in multiple fields and how to evaluate a "model exists" for a user.

Continuing his series looking at the features coming in Laravel 5.3, Matt Stauffer has posted his latest article in the series covering some of the image validation rules that the update will include.

In Laravel 5.3, we have a new validation option: image dimensions for image uploads. The validation rule is called dimensions, and you can pass the following parameters to it: min_width, max_width, min_height, max_height, width, height and ratio.

This provides a simplified version of many of these checks you might have been doing manually in the past (and fits in with the Laravel validation structure). He gives a few examples of verifying images from a basic form submission. The validations are put on the "avatar" field and work much like the other validation definitions with the checks "stacked" and separated by the pipe character ("|").

In this post to thePHP.cc site Sebastian Bergmann looks at validation data, both in the sense of user input and the contents of objects you're application is currently working with.

Validating data seems to be one of the most important tasks of an application. After all, you cannot trust data from external sources. So let us have a look at how to efficiently implement data validation.

He gives an example of a user profile with requirements on the data it should contain. He focuses on the email address property as it's one of the easier options to validate (or is it). He walks through the usual progression from controller injection to setter injection of the value but wonders when the validation should happen to keep the Profile object from becoming invalid. He points out that simply having a validate method perform the checks isn't enough as it may not always be called correctly, leading to potentially invalid objects. Instead he recommends an alternative - using a validator object/tool in the setters of your object instance as the values are set. This prevents the object from getting into an unknown state and provides immediate feedback to the developer when something's wrong.

Jonathan Wage has a new tutorial on his site showing you how to use the Symfony Expression Language to create simple logic statements. He illustrates with a project they (OpenSky) applied it on - a "reward" rules engine.

We recently adopted the Symfony Expression Language in the rules engine at OpenSky. It has brought a new level of flexibility to our system and creating new logic has never been easier. [...] The expression language allows you to perform expressions that get evaluated with raw PHP code and return a single value. It can be any type of value and is not limited to boolean values.

He starts with a simple example, showing how it can return a boolean based on the results of an evaluation of an array of data. He then takes this up to the next level and use it with a Doctrine object, evaluating the results of methods to apply "rewards" to a user's account. He shows how to define the Doctrine objects with the necessary methods, how to write the rule and a lookup class to find rules that apply to the current situation.

The Voices of the ElePHPant podcast has posted their latest in their series of community interviews this time with Larry Garfield, an advocate and well-known speaker in the PHP and Drupal communities.

They talk about Larry's involvement with Cal's "secret project" (no longer secret): the Wisdom of the ElePHPant book. Larry shares the concept behind his entry based on a quote from Pablo Picasso and when to break the rules. They also talk about Drupal 8 and the current state of the project.

You can listen to this latest episode either through the in-page audio player or by downloading the mp3. If you enjoy the episode, be sure to subscribe to their feed to get the latest.

In his latest post Phil Sturgeon talks about a project that's been running for a while, the The League of Extraordinary Packages and aims to clear up some recent misconceptions about the group and what they strive for in the projects they endorse.

This is the story of group of friends, who decided to write some code, but somehow confused and angered everyone with a keyboard. [...] Where should I release this code [I was super excited about releasing]? Should I release it with a vendor name of Sturgeon? That seemed rather egotistical. I could make something up, but what is the point of a single vendor with a single package? I wondered if any of my buddies were having this problem. [...] Being as hungover as I was, I thought long and hard, for about 5 seconds until something amazing happened in my brain... The PHP Super Best Friends Club! The guys loved it, and we started making plans immediately.

He goes on to talk about The League and some of the goals of the organization including the stated desire for quality code and a constant stream of work on the project (no abandoned or stale projects). He talks about how some of the rules for inclusion were created and some of the members of the various projects it includes. He then gets to the "recent misunderstanding" part of things with the clash of the League and the PHP-FIG (see here). He clears up some of the confusion in that thread by stating that:

• League != PHPClasses
• League != PEAR

He finishes off the post talking some about the leadership of the group (hint: it's an organization, not really run by a person or persons) and some of the work he's doing to ensure the future of the League and the packages it includes.

Paul Jones has a new post to his site today talking about the importance of naming when it comes to the use of different patterns in development. He also makes some recommendations to help clear up some of the confusion around different names for the same things.

[Thoughts in a] Grumpy Programmer mailing-list essay got me thinking. [...] I completely agree with the emphasis on using a common vocabulary. One issue here is that naming things properly is very, very hard. It is one of the only two hard problems in programming. Are there any rules (even rules-of-thumb) that can we use to make it easier to pick good names for the classes and concepts in our projects?

He reminds readers that code is no place for a "novel context", that is that it's not meant to be instructions for humans, but instructions for computers. He points out that patterns are more about behavior than the name you give them and that picking a name that's "close enough" isn't a good idea. He also recommends that you avoid picking a name for a special context the code might be involved in.