In the latest post to his site Stefan Koopmanschap offers some advice on when to use exceptions and when to avoid them (the result of a recent Twitter discussion).

I recently found myself in a discussion on whether or not exceptions could be used to control program flow in software (specifically in PHP applications). That triggered me to post a tweet:

Exceptions should not be used to control expected application flow. Discuss.... @skoop

This triggered quite a bit of discussion, which gave me a lot of input on this topic. I want to thank everyone who joined that discussion for their input, which was really valuable. In this blogpost I'll do a summary of the different arguments in the discussion, and give my opinion on this.

He goes on to define the term "program flow" and how that relates to the idea of using exceptions to control it. He then talks about naming things, the "intent" of your code and how the right names can make your code clearer and easier to maintain.

On the TutsPlus.com site they've posted a tutorial showing you how to integrate with Twitter's OAuth authentication through a few simple steps allowing the well known "Log in with Twitter" functionality.

In this tutorial, you will learn how to use Twitter API 1.1 and OAuth 2.0 to authenticate users of your application and publish a test tweet.

To create services which act on behalf of users' accounts and make it really secure and easy to develop, we need three things: a Twitter application, the REST API and access to the user account To put the pieces together into a working mechanism, we need an authentication framework. As a Twitter standard, the REST API identifies Twitter applications and users using OAuth.

The tutorial starts with a brief description of OAuth for those that aren't overly familiar with the use of the technology and its flow. They then go through the steps you'll need to get your app working with Twitter's OAuth handling:

• Create the Twitter application
• Get the OAuth credentials (secret and key)
• Installing a Twitter library via Composer
• Configuring your app with the OAuth credentials
• Building out the code to send the request to Twitter and receive the resulting callback

Once you receive that callback you'll have a token you can use to uniquely identify the user and interact with the Twitter API on their behalf. The post ends with some related links to other resources with more details about the Twitter API, their OAuth handling and other Twitter libraries.

In a new post to his site Alex Bilbie looks at a good approach to simplifying the OAuth 2 authorization flow for a device and some of the simple PHP that can power it.

When signing into apps and services on devices such as a Playstation or an Apple TV it can be immensely frustrating experience. Generally you will ordeal something similar to one of the following scenarios: The utterly terrible experience whereby you don’t have anything other than an onscreen keyboard [or] A slightly less terrible experience whereby you can pair a bluetooth keyboard to enter your username and that crazy long password.

[...] There are some apps however - such as Youtube for Apple TV - that have a much better end user experience.

He talks more about this better experience involving a simple code presented to the user, a special URL to link the device and the typical OAuth-ish authorization page to link the request to your account. He then explains how it would work with a PHP backend: making the request to the auth server, returning a message with the codes and URL to pass along and the "device code" it responds with. He also includes a few examples of error responses for polling too quickly, pending authorization and a denied request. This is all based on the (currently in draft) OAuth 2.0 Device Flow Grant currently in the works.

On the Yappa blog there's a new post about their "trip" towards a PHP and Docker based development environment and the steps they took along the way. The post even includes the full commands and configuration changes you'll need to replicate it.

During a regular work day we work on several PHP projects. Sometimes new projects, but also legacy code which still require earlier versions of PHP. We all work on Macbooks and want to switch quickly and easily between projects. The project requirements vary, the PHP version may be different, or additional services may be required (such as Redis, Elasticsearch, ..).

Unable to mimic the production environment without spending countless hours installing packages on a virtual box for each project.

They start with some of the initial steps they tried including a single local development server and remote servers but points out the issues with each. Ultimately they decided to give Docker a try and came up with their ("almost perfect") development environment. From there they get into the steps to reproduce, the more technical parts, and list the requirements you'll need and the steps in the setup process.

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

Luciano Mammino has a quick post to his site with information that tries to help make Symfony authentication simple (well, maybe).

The Symfony2 security component has the fame of being one of the most complex in the framework. I tend to believe that's partially true, not because the component is really that complex, but because there are (really) a lot of concepts involved and it may be difficult to understand them all at once and have a clear vision as a whole.

[...] Going back to the Symfony2 security component, the point is that I found out difficult at first glance to get a clear idea of what is going on behind the scenes and what I need to write to create a custom authentication mechanism. So in this post I will try to collect few interesting resources that helped me understanding it better and a graph I drawn to resume what I learned.

He provides a good list to some of the other resources that helped him along the way including several blog posts and links to the Symfony "cookbooks" about creating custom providers. He also shares a graph showing the full flow of the Symfony authentication process including commentary about each step.

On the SitePoint PHP blog there's a new tutorial today showing you how to setup a user login through PayPal that lets users authenticate for your application through PayPal's systems.

Curiosity is one of the most important traits in our job. The other day, I found myself exploring PayPal documentation to find something interesting to learn (and share). After a while I stumbled upon the Log In with PayPal tool. With the “Log In with PayPal” tool, your users can authenticate into your application using PayPal. It’s the same procedure we already know for Facebook, or maybe Twitter and GitHub. Using this type of authentication is recommended if you want to integrate it with an e-commerce website, but you can use it in every situation and application that requires a user account or membership.

He starts by answering the "why use it" question, suggesting that it adheres to one of the main goals of good, secure authentication systems - simplicity. He then shares an overview of how the process flow works including a graphic outlining each piece involved and what kinds of data is transmitted at each step. He then walks you through the full process of setting up a PayPal application on your account and using the Httpful library (installed via Composer) to connect to their API. He includes the code you'll need to include in your application to provide the link to PayPal for the login and the page it will return to once the process is complete.

In his latest post Derick Rethans talks about something that plagues every project, PHP or otherwise, after its grown to a large enough size: dead code. He's been asked why his Xdebug tool finds this code in places where people don't expect, so he figured he'd answer it once and for all.

The explanation for this is rather simple. Xdebug checks code coverage by adding hooks into certain opcodes. Opcodes are the building blocks of oparrays. PHP converts each element in your script - main body, method, function - to oparrays when it parses them. The PHP engine then executes those oparrays by running some code for each opcode. Opcodes are generated, but they are not optimised. Which means that it does not remove opcodes that can not be executed.

He gets down to the opcode level and shows some output from vld on how things are being executed (and what's not). Using a simple "foo" function example, he shows the execution flow and how the "branches" of executions work through the code. In his case, the "dead code" marker is coming from the line with a closing brace from an "if" statement. He points out that it entirely depends on the lines executed as to what is marked as "dead code".

Phil Sturgeon has a new post about some of the progress the PHP-FIG is making (the PHP framework interoperability group) and how some of the more recently proposed standards...and a workflow he thinks can help keep things from fading like they are now.

For the last two years the ML has been chock full of different discussions about potential PSRs that could be worked on. [...] This to me is the central point of the PHP-FIG as by defining these standards it can stop the need to build 6 different damn adapter classes for your composer package if you want it to work with Buzz, Guzzle, Zend HTTP, Curl, Whatever). [...] It became apparent to me that the PHP-FIG wasn't going to get all that far as things stood. I actually saw quite a few problems with the workflow.

To try to help resolve these problems, Phil has proposed a bylaw that aims to help (and has since been voted in as part of the process). The flow has several steps that a PSR proposal has to go through, all tracked by co-sponsors, one being the main coordinator. It goes through a pre-draft, draft, review and acceptance phases. There's also some points in there about attribution, the use of the voting protocol and the flow of the voting process.

On the NetTuts.com site today they've posted the transcript of a panel discussion they had with several developers about exceptions and whether or not they should be used for flow control.

I’m pleased to release our first ever round table, where we place a group of developers in a locked room (not really), and ask them to debate one another on a single topic. In this first entry, we discuss exceptions and flow control.

The opinions vary among the group as to what exceptions should be used for (even outside of the flow control topic). Opinions shared are things like:

• Exceptions are situations in your code that you should never reach
• Errors cause Failures and are propagated, via Exceptions.
• So, essentially, exceptions are an “abstraction” purely to model the abnormality.
• Personally, I envision exceptions more as “objections.”
• Exceptions like this should be caught at some point and transformed into a friendly message to the user.

There's lots more than this in the full discussion so head over and read it all - there's definitely some good points made.