The SitePoint PHP blog continues their series about combining PHP and the Neo4j graph database with part two, adding social features to the code they created in part one.

In the last part, we learned about Neo4j and how to use it with PHP. In this post, we'll be using that knowledge to build a real Silex-powered social network application with a graph database.

Author Christophe Willemsen dives right back into the code showing how to get the basic application up and running (using Silex, Twig, Bootstrap and the NeoClient). He loads the PHP libraries up via Composer and injects the NeoClient instance into the application. He includes the view and controller handling for each of the pages:

a main all user list

showing who a user follows

listing suggested users (who to follow)

adding a relationship

Screenshots are also included to show the example output along with all the code you'll need.

Lorna Mitchell has a new post today with five things that you could gain by upgrading your platform, mostly centered around the changes PHP has made recently.

In recent years, the release cycle of PHP has become much shorter. We now have a much more controlled and well-publicised process of releases, and moving between each version is no longer a leap of faith. The newer versions have HUGE performance improvements, great features, and better security, and the software is free to use. Yet we have a very, very long tail of PHP installations on older versions (around 75% on entirely unsupported versions at this point). Many of the companies I talk to think that upgrading will be pointless and painful, but that's not my experience of migrating PHP projects. Here are a few things you might like to think about or be aware of before you make the decisions that "not broken" is good enough for your applications.

She offers her list of five things, each with a bit of summary and a few links to more information on the topics:

Improved Performance

Security and Support

New Syntax

Traits

Built In Webserver

She also technically includes another in the list (#6 in the top 5, naturally) talking about the password hashing functionality that's been introduced in recent versions and how much simpler it can make your life.

I've followed the techempower benchmarks, and every now and then I check out benchmarks of various projects (usually PHP) to see what the relative state of things are. Inevitably, someone points out that "these aren't testing anything 'real world' - they're useless!". Usually it's from someone who's favorite framework has 'lost'. I used to think along the same lines; namely that "hello world" benchmarks don't measure anything useful. I don't hold quite the same position anymore, and I'll explain why.

He goes on to talk about the purpose of using a framework and what kind of functionality they should provide. The usefulness of a framework is measured in what tools it provides and how easy it makes them to use. Benchmarks are only about speed, performance and overhead.

What those benchmark results are telling you is "this is about the fastest this framework's request cycle can be invoked while doing essentially nothing". [...] These benchmarks are largely about establishing that baseline expectation of performance. I'd say that they're not always necessarily presented that way, but this is largely the fault of the readers.

He refutes some of the common arguments about increasing performance of an application using a framework (like "just throw hardware at it"). He points out that, even with other improvements, it may come to a point where your framework of choice has become too slow and you need to move on. Think about maintainability too, though, and what you're switching from or to when considering making a move.

As well as massive performance improvements, PHP 7's change / feature list is already looking great. You can find most of the features that have been accepted or are under discussion on the PHP Dev Wiki: RFCs section. But what changes would make a difference to you? What would you really like to see make it in (already suggested or a new suggestion)?

Here's just a few of the suggestions made by fellow Reddit users:

fixing inconsistencies in naming

sandboxed eval

a complete rework of the standard library

the introduction of generics

adding enum functionality

type aliasing

stack traces for fatal errors

Check out the full post for more ideas and feedback from other members of the community too. It's an interesting list of suggestions, some that are even already in the works.

This year is just about over, but we are too excited to wait until the new year to share with you a feature we are developing for the AWS SDK for PHP. We are calling it the AWS Resource APIs for PHP. This feature is maintained as a separate package, but it acts as an extension to Version 3 of the AWS SDK for PHP.

He talks about the new resource objects that contain information to identify what it represented (like a S3 bucket or SQS queue) and includes an example object structure. He shows how to perform actions on the objects and working with collections. He also includes a helpful hint about using the "respondsTo" method on the object to get the methods the object can use.

NetTuts.com has posted the second part of their "Laravel, BDD and You" series (part one is here) building on their introduction in part one and building a first feature (what BDD tools call their tests).

In the second part of this series called Laravel, BDD and You, we will start describing and building our first feature using Behat and PhpSpec. In the last article we got everything set up and saw how easily we can interact with Laravel in our Behat scenarios. [...] In short, we are going to use the same .feature to design both our core domain and our user interface. I have often felt that I had a lot of duplication in my features in my acceptance/functional and integration suites. When I read everzet's suggestion about using the same feature for multiple contexts, it all clicked for me and I believe it is the way to go.

He starts in with the creation of the first feature - a simple "welcome" test that evaluates the main Laravel start page. He uses this example to set up a Laravel trait that can be reused in other parts of the testing and how to use it in a Feature Context file. He then starts to create the tests for the sample time tracking application started in part one. He gives an example of the feature file's contents, the result from its execution and the "small refactors" that it will suggest to add functionality to the feature file. With this skeleton in place, he then fleshes out the test to make it actually work with the requests. He walks through each function and provides the code needed for both the test and other tools/objects they need.

Analysis of my own email showed I was receiving email from more than 230 automated senders, far fewer actual people. I was tired of constructing filters in Gmail and filling in a myriad of unsubscribe forms. I wanted to have more control over managing my email and simplifying my life. Finally, this past year, I decided to build the features I needed. The result is Simplify Email (SE), a small web app you can host yourself which offers a variety of cool new email features all of which you can check out on the project website. The coolest thing about SE is that it's a platform for reading, analyzing, routing and managing your email - the possibilities abound. Simplify Email is essentially a programmable playground for "hacking" your own email.

His three examples show you how to:

Checking your inbox and filter messages

Implement a Whitelist challenge to unknown senders

Reporting unanswered email

Each of these comes with plenty of code examples, screenshots and output examples (as well as some places where you might need to change some SE configuration values).

On NetTuts.com they've kicked off a new series of tutorials teaching you about Laravel development but using the principles and testing of behavior-driven development (BDD). In this first part of the series they get you started with the basic environment and a few simple tests.

Welcome to this series about developing Laravel applications using a behavior-driven development (BDD) approach. Full stack BDD can seem complicated and intimidating. There are just as many ways of doing it as there are developers. In this series, I will walk you through my approach of using Behat and PhpSpec to design a Laravel application from scratch. There are many resources on BDD in general, but Laravel specific material is hard to find. Therefore, in this series, we will focus more on the Laravel related aspects and less on the general stuff that you can read about many other places.

He talks about what it means to "describe behavior" versus other kinds of testing and introduces the sample application they'll be creating to show these principles: a time tracker. Following this, they help you install the needed tools (via Composer) and initialize the directory to be ready for the Behat/Phpspec tests you'll create. An example of a basic Feature is included, testing the initial Laravel "Welcome" page it defaults to and how to execute it. Finally, following the ideals of BDD, they show how to implement the "Given I am logged in" step first in the test then in the Laravel application.

In his latest post Dave Marshall takes a look at a handy feature of the Mockery mocking tool (helpful for unit testing) and how to use them in your testing.

Spies have been on the cards for mockery for a long time and even after putting together an implementation in February, I kind of stalled out on making a decision on the public API. Fast forward a few months and I figured it was just time to ship it, so I went with the most mockery like API and merged it in. Mockery still doesn't have a 1.0 release, so I can always make changes before we go 1.0.

For those not familiar with the concept of "spies" in testing he includes a brief definition and some of the reasoning behind using them. The first is relatively simple: how they can reveal the intent of the test. They also allow for two other types of testing methods, "Arrange-Act-Assert" or "Given-When-Then" thinking patterns. He does mention, however, some of the problems with using spies over mocks (including that they're less precise, possibly leading to looser testing). He finishes up the post with a quick note about partial spies and how they can provide a nice compromise in your testing.

It's been a long time coming, but we finally have a new version of PHP. With it comes a some nice, new features, improvements to existing features, as well as features that have been removed or marked as deprecated. Let's dive in and take a look at everything that's offered by the latest version.

There's several items on the list, broken up into various sections, each with brief explanations: