Matthew Weier O'Phinney has a new post to his site talking about PSR-7 and HTTP headers and how they (headers) are handled in the structure of this PHP-FIG specification.

Yesterday, a question tagged #psr7 on Twitter caught my eye: "When I call $request->getHeader('Accept') for example, I was expected that I'll get [an array] but, in reality I got [a string]. Is this correct?" In this post, I'll explain why the behavior observed is correct, as well as shed a light on a few details of header handling in PSR-7.

He talks about the planning that went into PSR-7 and how they had to work around some of the "flexibility" (quirks) in the HTTP specification. This was especially true when it came to repeated headers. He also walks through their thoughts on multiple header handling and that custom header values are allowed. Because of these two things, they decided to treat all headers as collections and, despite there being separators already in the values. Instead they collected headers of the same types into these collections, some containing only one value while others could contain multiple. Back to the question - this explains why the "Accept" header they desired was still in its comma-separated form and not split into the array they expected.

The [...] example provides another good lesson: Complex values should have dedicated parsers. PSR-7 literally only deals with the low-level details of an HTTP message, and provides no interpretation of it. Some header values, such as the Accept header, require dedicated parsers to make sense of the value.

Stephan Hochdörfer has a new post with a handy tip on speeding up the indexing Satis does on your local repositories to generate its information. His tip involves being more selective in the rebuild process, only indexing the projects that might need it.

In the last couple of months this [indexing] process takes quite a while because Satis rebuilds the index for every repo it knows about. Since we deal with quite a few repos containing a large amount of versions it slowed down the "build time". Obviously it does not make any sense to run Satis on a repo that has not changed. Since Satis was lacking this feature I started hacking on it and I am happy that the feature got merged into master this morning.

With his patch, you can specify only the repository you want reindexed via the "build" command. You can even specify multiple repositories to rebuild, allowing for a bit more automation around the process.

NetTuts.com kicks off a new series of posts today with this first article covering the SOLID development practices. SOLID is a set of principles that can help make your code more robust and well structured in the long run. In this first post they jump right in with the first letter - "S" for Single Responsibility Principle.

[The Single Responsibility Principle] is one of the five SOLID agile principles. What it states is very simple, however achieving that simplicity can be very tricky. A class should have only one reason to change. But why? Why is it so important to have only one reason for change? [...] Even though you may not use a compiled language, you may need to retest the same class or module for different reasons. This means more QA work, time, and effort.

They go on to talk about how to figure out the "audience" for your class and how that effects what it should contain. A few "class examples" are shared in the post including objects that can print or save themselves. There's a bit of talk about software design ideas to consider and a less obvious example that might be breaking the principle (and how to fix it).

Chris Jones has a new post to his site showing you how to use Oracle 12c's implicit result sets in your code. Note: this functionality is still in development, so the naming/exact functionality might change.

The new Oracle Database 12c "Implicit Result Sets" (IRS) feature allows query results to be returned from a stored PL/SQL procedure (or a PL/SQL anonymous block) without requiring special PHP code. Support for IRS is available in PHP OCI8 2.0.0-devel extension when it is compiled and used with Oracle Database 12c. (OCI8 2.0 can be compiled and used with other versions of Oracle Database but the available feature set is reduced).

He shows a normal fetch loop that calls the oci_* functions and grabs each row with a oci_fetch_row call. He updates this to use an anonymous PL/SQL block (a string) instead that allows for more flexibility. He includes examples that fetch from one table, multiple tables and returns multiple result sets (that can be fetched one at a time) from the same single call.

In a recent post to his site, Brandon Savage has a few helpful hints to keep in mind when you're refactoring your applications to make them easier to maintain (and possibly perform better) in the future.

The downtime [of this week] provides a perfect opportunity for the aspiring software developer to do the one thing they are always told there’s no time to do: make the code better for better’s sake. With few deadlines and plenty of free time, most developers can get a few hours of refactoring in to their code towards the end of the year. They can rearchitect sections that were implemented with haste in September; they can write tests for sections that were untested in April. Put another way, the “lost week” can be redeemed.

He has a few recommendations, each including their own brief summary:

Test Everything First

One Method, One Job (Also One Class, One Job)

Don’t Be Afraid Of More Objects And Classes

Remove Dead, Unused, Unnecessary or Old Code

Document Your Code

Check out the full post for the summaries and links to other useful resources.

On PHPMaster.com today Alejandro Gervasio has a new tutorial posted about the Single Responsibility Principle - a guideline that states that each class should only have one "area of concern" and not try to do to much.

One of the most notorious consequences of this rational associative process is that, at some point, we effectively end up creating classes that do too much. The so-called “God class” is quite possibly the most extreme and coarse example of a structure that packages literally piles of unrelated operations behind the fence of the same API, but there are other subtle, more furtive situations where assigning of multiple roles to the same class are harder to track down. [...] What the principle attempts to promote is that classes must always be designed to expose only one area of concern and the set of operations they define and implement must be aimed at fulfilling that concern in particular and nothing else.

He starts off with a typical violation of the principle, showing a class that not only handles user data but also includes the functions to work with the database directly as well (insert/update/delete). He refactors this into a few much more manageable classes - a mapping class to handle the database interaction and a "User" class representative of a true user object.

Freek Lijten has written up a new post to his blog about a set of development principles that have been getting more press in the PHP community lately - SOLID. In his post he starts with a look at the "S" in the set - "Single Responsibility".

The single responsibility principle isn't all that hard to explain. It states that an object should do one thing, and one thing only. [...] A responsibility is a reason to change, and a class should only have one of those. Now all of this may sound abstract and since the objective of this series is to avoid just that we'll just dive into the why now.

He includes some sample code to illustrate, going with an active record implementation, some of the problems that come with a typical setup including issues with unit testing, bad practice of using the data store directly, etc. He shows a refactored code example that splits out the functionality previously all in the one class ("Bike") into three different ones - one is the normal Bike object, another compares the Bikes and the third works with the data store to handle the CRUD for the objects.

I've been working with the Basecamp API to plugin our IRC bot that we use for time tracking and I'm astounded to learn that escaping single and/or double quotes for XPath queries in PHP does not have a well documented, best practices solution. In fact, it seems as though this is not peculiar to PHP. I took a look around and found this excellent article by "Kushal": http://kushalm.com/the-perils-of-xpath-expressions-specifically-escaping-quotes.

He's put together his own (PHP) solution to the problem - running the entire XPath query through a filtering method that splits it up, replaces the quote characters and combines it back down to a single string.

On the Lullabot.com blog there's a recent post from Nate Haug showing how you can set up a single sign on with Drupal even if your user crosses multiple sub-domains on your site. The technique is particularly handy in that it doesn't require any extra modules to be installed to make it work.

With the multitude of single sign-on modules out there for Drupal, it's easy to miss the fact that Drupal has a built-in single sign on mechanism already. No modules, no configuration, just 20 easy lines of PHP in your site's settings.php file. This solution works for a lot of clients, but the set of requirements is pretty specific as to when you can use this approach.

To make it work all sites must be on the same domain (just sub-domains of it), be using MySQL as your backend database and, if you're using clustered hardware, they need to be on the same cluster to be able to make the cross-database queries. Since Drupal can prefix tables so the settings for each site are split out, you can create a "shared table" by making a few changes in your master and slave configuration.

Arnold Daniels has a new post to his blog today dealing with something (usually companies) are looking towards to help deal with the infamous "too many passwords for too many places" issue - a simple single sign-on tool that can be dropped in an used anywhere.

Associated websites often share user information, so a visitor only has to register once and can use that username and password for all sites. A good example for this is Google. [...] There are many single sign-on applications and protocols. Most of these are fairly complex. [...] I've written a simple single sign-on solution (400 lines of code), which works by linking sessions. This solutions works for normal websites as well as AJAX sites.