On the TutsPlus.com site today they're "getting back to basics" with a tutorial targeted at those just learning the PHP language. In this latest tutorial, they focus on control structures and loops such as if, else, for, foreach, while and more.

In simple terms, a control structure allows you to control the flow of code execution in your application. Generally, a program is executed sequentially, line by line, and a control structure allows you to alter that flow, usually depending on certain conditions.

Control structures are core features of the PHP language that allow your script to respond differently to different inputs or situations. This could allow your script to give different responses based on user input, file contents, or some other data.

They start with a flowchart showing the basic idea behind how flow control structures work and provide a more "real world" example of a user login. It then goes through each of the control structure types, providing a simple explanation of what it does, where it's useful and code examples of it in action.

The North Meets South podcast, hosted by PHP community members Jacob Bennett and Michael Dyrynda, has posted their latest episode - Episode #47: Reinventing form controls, typing ahead, and converting MySQLi to Query Builder

In this new show Jacob and Michael return after a hiatus during the summer to talk largely about accessibility in applications (including forms and the overall UI) and updating the Query Builder to work with MySQLi versus MySQL.

You can listen to this latest episode either using the in-page audio player or by downloading the mp3 of the show. If you enjoy it, be sure to subscribe to their feed and follow them on Twitter to stay up to date on when new shows are released.

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).

Frank de Jonge has a new post to his site covering something that always seems to be a difficult topic in development: time. In his post he suggests that date and time handling in your application is a "dependency" that could be difficult test.

When developers talk about the infrastructural boundaries or external dependencies they often talk about databases and third-party integration. They're the first thing we'll put behind an interface so we can stub them out during our tests. This gives us some control over them. It's become relatively easy to spot these dependencies because we do it frequently. They're the usual suspects.

However, some "dependencies" are much harder to spot. They even live right inside the standard library of PHP and often manage to seep through the cracks. Date/Time handling is such a thing. So what's the problem and how do we fix it?

He goes on to talk about date/time handling programming languages in general and how its variance can can cause issues that might be out of our control. He suggests that when time "gets the best of you" you should opt to be more specific in your date/time handling (the cause is usually precision). He then gets into some code examples of how to "control time" by reducing the impact that direct date/time handling could have on your application. He also includes an example of testing this handling and finishes with the idea of "consuming time as a service".

The MyBuilder.com Tech blog has a new post from Edd Mann looking at designing immutable concepts in PHP with "transient mutation".

In a recent project we felt it beneficial to introduce the Money pattern. There are many good resources on this pattern, so I will delegate to those for further definition. We decided that encapsulating this into a immutable value object allowed for a cleaner API and removed the fear of any unexpected mutation bugs. However, we noticed a spike in memory and processor usage when wishing to perform many successive actions on such values i.e. summation.

In such a case, new ‘temporary’ Money objects would be instantiated upon each applied addition. As many of these objects were simply a stepping stone to generating the final result, they were just left for the Garbage collector to clean-up.

The idea of "transients" is something pulled from the Clojure language allowing for the mutation of the immutable object and returning a new immutable one....with with some controls, not free form mutation. He includes showing an example of a "Money" object that implements this concept including a "withMutable" method that handles a callback for the mutation operation.

Lorna Mitchell has a post to her site with some helpful instructions for the CakePHP3 users out there around access control. The framework comes with no built-in functionality for authentication so she shows how to set up your own.

The newest version of CakePHP doesn't ship with built in ACL, which means you need to write your own. Personally I think this is a smart move, having looked at the one-size-fits-all solutions for previous versions of the framework and knowing that every system has different requirements, this version has good hooks and documentation on how to add something that works for your application. I thought I'd share what worked for mine.

She starts with some of the initial setup: creating the relationship between the users and her custom roles table and "baking" the controllers and templates. She then goes through the use of the authorize method and how it can handle the user/request combination to determine access. She includes the code for her auth class, showing both the authorize method and a simplified userHasRole method. She walks you through the code and one downfall the setup has: not being able to validate access in views and templates.

The SitePoint PHP blog has posted a tutorial from Bruno Skvorc showing you how to use Rauth, a tool that's designed to control access to parts of your application as set by annotations in the code.

Rauth is SitePoint’s access control package for either granting or restricting access to certain classes or methods, mainly by means of annotations.

[...] Traditional access control layers (ACLs) only control routes – you set anything starting with /admin to be only accessible by admins, and so on. This is fine for most cases, but not when: you want to control access on the command line (no routes there) or you want your access layer unchanged even if you change the routes Rauth was developed to address this need. Naturally, it’ll also work really well alongside any other kind of ACL if its features are insufficient.

He starts by dispelling the common thought (at least in most of the PHP community) that annotations are a bad thing and relying on them for functionality isn't a good practice to follow. With that out of the way, he shows a simple example: a set of users and fake routes that are evaluated by Rauth based on the annotations in a One controller-ish class. He describes what the evaluation is doing and how changing the annotations would make a difference in the results. He also includes a dependency injection example with PHP-DI and the Fast-Route package and a more "real world". He ends the post with a look at another handy feature of the library: bans (blocking based on other types of annotations, @auth-ban).

The SitePoint PHP blog has posted a tutorial showing you how to help your applications understand natural language with the help of the Api.ai service.

In this tutorial we’ll be looking into Api.ai, an API that lets us build apps which understand natural language, much like Siri. It can accept either text or speech as input, which it then parses and returns a JSON string that can be interpreted by the code that we write.

They start by explaining some of the concepts you'll need to know in using the service: agents, entities, intents, contexts, aliases and domains (each with a summary and examples). In their example, they show how to get the current time from any given places using their API. He shows you how to set up a free account and create a new agent. He then uses Guzzle (the HTTP client library) to make the request to the API with your API and subscription keys. They show the result of a query for "What's the current time in Barcelona Spain?" and how to extract the "location" value from the results. With this they then search the Google API for the local time of "Barcelona Spain". With the time in hand, they then use the responsive-voice.js library to convert the text to speech at the click of a button.

With all these concepts under your belt, they also walk you through a second application, a currency converter. It uses the same workflow as the previous example with the exception of using the CurrencyLayer.com API to perform the financial conversion. All code needed for this example is included as well. If you'd like to just jump to the end, they've also shared the complete code for both examples over on Github.

The MyBuilderTech.com site has a new tutorial posted talking about the use of traits and magic methods for optional value handling.

Recently I have been interested in experimenting with different ways to handle optional values. Their are many examples that exist demonstrating the use of the Maybe/Optional structure within the PHP landscape. I would instead like to focus my attention on only looking into the concept of 'orElse', which I have found to be a prominent control-flow whilst using these types of value. Typically, in an imperative mind-set we are accustom to evaluating a value, and based on its existence - defined as falsely in this regard - follow a different course of action, and by-way result.

He gives an example of where a value is checked for null and something else happens when it is. This is a common practice in PHP development, but he's more interested in other ways of handling. The first of these ways is with traits. His example shows an "OrElse" trait that can be used to perform the same evaluation but does some extra magic based on the method name called (his example is "findByIdOrElse"). If the trait method isn't for you, he also offers another possible solution around the use of composition. In this case he uses the same trait but makes it a part of its own class that's then given the object to work with (his "repository").

The post ends with one more "bonus" method for handling optional values - a simple function ("_or") that evaluates the arguments given and returns the first that's "truthy".

The Laravel News site has a post today linking to five handy resources you can use to learn about the Laravel IoC (inversion of control, dependency injection) container.

The Laravel IoC container is a powerful tool for managing class dependencies. It is widely used in Laravel and an important tool for your arsenal. The community has created several tutorials for this and here are five resources that will teach you all about it. [...] By reading these tutorials you’ll be up to speed in no time on the Laravel IoC container and also improve your code by implementing it in your application.

As a "bonus" there's also a link to a video narrated by Laravel creator Taylor Otwell himself about the IoC container and its use.