SitePoint PHP Blog: PHP and RabbitMQ: Advanced Examples

Mon, 10/20/2014 - 20:19

On the SitePoint PHP blog Miguel Ibarra Romero continues his series looking at the use of RabbitMQ with PHP in part two. He builds on the code (and setup) from the first part of the series and gets into some more advanced examples this time.

In part 1 we covered the theory and a simple use case of the AMQP protocol in PHP with RabbitMQ as the broker. Now, let's dive into some more advanced examples.

The remainder of the post includes two examples of more advanced operations:

  • Example 1: send request to process data asynchronously among several workers
  • Example 2: send RPC requests and expect a reply

Each example includes a diagram of the overall flow of the process, the code to make it happen both for the sender and receiver.

Link: Design Patterns: The Facade Pattern

Mon, 10/20/2014 - 19:17 has continued their series covering common design patterns and their implementation in some example PHP scripts today. In their latest post they focus on the Facade pattern, a member of the "structural" family of patterns.

When it comes to design patterns, you may have questions: Why should we use design patterns in programming? Our code can work just fine without it. [...] Code that employs design patterns is easy to understand, easy to maintain, and easy to extend.[...] In this tutorial, we are going to cover the facade design pattern. It falls under the category of structural patterns because it deals with how your code should be structured to make it easily intelligible and keep it well maintained in the long term.

They start with a UML layout of a typical Facade and include a typical problem/solution where it could be used. They get into a code example that creates a simple checkout process. In this process, they use the Facade pattern to create a more maintainable, extensible ordering workflow.

Link: Blog: Using the Accept Header to version your API

Mon, 10/20/2014 - 18:56

On the blog today there's a new tutorial talking about the use of the Accept header in REST HTTP requests and, more specifically, working with it in a Symfony-based application.

I investigated different ways to version a REST API. Most of the sources I found, pretty much all said the same thing. To version any resource on the internet, you should not change the URL. The web isn't versioned, and changing the URL would tell a client there is more than 1 resource. [...] Another thing, and probably even more important, you should always try to make sure your changes are backwards compatible. That would mean there is a lot of thinking involved before the actual API is built, but it can also save you from a big, very big headache. [...] Of course there are always occasions where BC breaks are essential in order to move forward. In this case versioning becomes important. The method that I found, which appears to be the most logical, is by requesting a specific API version using the Accept header.

He shows how to create a "match request" method in his custom Router that makes use of the AcceptHeader handling to grab the header data and parse it down into the type and API version requested. He also includes an example of doing something similar in the Symfony configuration fil e but hard-coding the condition for the API version by endpoint.


Laravel Podcast: Episode 18 - Laravel 5 Routing, the War over PHP Annotations, and The Secret Weapon

Mon, 10/20/2014 - 17:05

The Laravel Podcast has released their latest episode, Episode #18: Laravel 5 Routing, the War over PHP Annotations, and The Secret Weapon(tm). Join hosts Shawn McCool, Taylor Otwell and Jeffrey Way as they talk all things Laravel.

In this episode, we discuss new Laravel 5 features including annotated routing and middlewares. We discuss some motivations and guiding forces that make Laravel what it is. Also, hints about Jeffrey and Taylor's secret new project. The referenced article by @everzet can be found here:

You can listen to this latest episode either by using the in-page audio player, by downloading the mp3 or by subscribing to their feed.


Joshua Thijssen: Deepdive into the symfony2 security component: part 1

Mon, 10/20/2014 - 16:26

On the latest post on his site Joshua Thijssen has kicked off a series taking a deep dive into the Symfony security component, a key piece in the security of Symfony-based applications. In this first part of the series he introduces the component and starts in on some of the features it offers.

Once in a while I like diving into code and see how things work under the hood. And as the symfony2 framework consists of many different components, bundles and bridges, there is a lot to discover. But ultimately, the code itself mostly isn't really as complex as it might seem from the outside world: just like a good magic trick, once unraveled, it all seems very simple and makes sense.

However, this is not true for one of those components: the security component. This black box full of dark magic doesn't like to give up its secrets, and after some (miserably) failed attempts, I am trying to unravel it once more in a few blog posts. Either we achieve complete victory, or fail yet again.. At this point, I will give both fair odds.

He starts off with an overview of the component, pointing out the two main things is handles: authentication and authorization. He also pulls in a few other things to do with security in Symfony to give a more complete, well rounded picture - the component itself, the security bundle and security bridges. He gets into a bit more detail about this last one and describes their specific use.


Rob Allen: Setting up PHP & MySQL on OS X Yosemite

Mon, 10/20/2014 - 15:43

Rob Allen has posted a quick guide to help you get PHP and MySQL set up on Yosemite, the latest version of Apple's OSX operating system (just released last week).

t's that time again; Apple has shipped a new version of OS X, 10.10 Yosemite. Apple ships PHP 5.5.14 with Yosemite and this is how to set it up from a clean install. However, if you don't want to use the built-in PHP or want to use version 5.6, then these are some alternatives [including the Liip binary package, Homebrew or Zend Server 7.x).

He opts for the Homebrew method, installing it first then getting into the PHP and MySQL packages. This is all done from the command-line, so you'll need to be comfortable there. He includes the commands needed to install PHP, MySQL and Apache along with all configuration changes to make them work together. He also shows how to install Xdebug, PEAR, Composer and the Mcrypt & Intl extensions if needed.


Community News: Packagist Latest Releases for 10.20.2014

Mon, 10/20/2014 - 14:01
Recent releases from the Packagist:

Community News: Packagist Latest Releases for 10.19.2014

Sun, 10/19/2014 - 14:08
Recent releases from the Packagist:

Community News: Packagist Latest Releases for 10.18.2014

Sat, 10/18/2014 - 14:02
Recent releases from the Packagist:

PHP Town Hall: Episode 31: The One About Hot Dogs

Fri, 10/17/2014 - 19:33

The PHP Town Hall podcast has released their latest episode today: Episode #31, The One About Hot Dogs with hosts (and PHP community members) Phil Sturgeon and Ben Edmunds. They also feature guests Kayla Daniels and Matt Frost.

We talk waaaaay too much about hotdogs, Phil's fun-employment, cocaine, and what's new in PHP-land. The recommended cool stuff of the episode is: Dossier - super secret stealth mode project for managing talk abstracts.

They also mention the No Capes, WurstCon, SideSwell and using Treehouse to learn to code. You can listen to this latest episode either through the in-page audio player, downloading the mp3 recording or you can watch the live video recording of the episode.


SitePoint PHP Blog: How to use RabbitMQ with PHP

Fri, 10/17/2014 - 18:43

The SitePoint PHP blog has published a new tutorial today by Miguel Ibarra Romero introducing you to the RabbitMQ queuing tool and shows you how to use it in PHP-based applications via the php-amqplib library.

AMQP (Advanced Message Queueing Protocol) is a network protocol that can deliver messages from one application endpoint to another application endpoint. It does not care about the platform or language of said applications, as long as they support AMQP. [...] The advantage of having a message broker such as RabbitMQ, and AMQP being a network protocol, is that the producer, the broker, and the consumer can live on different physical/virtual servers on different geographic locations.

With some of the introductions out of the way (common terms, flow of the data, etc) he walks through the installation of the RabbitMQ software on your system. He uses a Ubuntu install, but the commands could be easily ported for other distributions. From there he shows how to install the PHP library and a simple example of a pizza ordering system where orders are sent to be processed offline. Complete code is included to make the "SimpleSender" class and push the request out to the queue. With that working, he also shows how to create a SimpleReceiver class that consumes the data from the queue and sends the data to be processed.


Anthony Ferrara: A Followup To An Open Letter To PHP-FIG

Fri, 10/17/2014 - 17:51

Based on some of the responses to his previous open letter to the PHP-FIG (Framework Interoperability Group), Anthony Ferrara has posted a follow-up explaining some of his points made and the caching proposal in a bit more detail.

A few days ago, I wrote An Open Letter to PHP-FIG. Largely the feedback on it was positive, but not all. So I feel like I do have a few more things to say. What follows is a collection of followups to specific points of contention raised about my post. I'm going to ignore the politics and any non-technical discussion here.

He points out that while the previous post wasn't completely about the cache proposal (it was used as a "literary device") there was some confusion on it. He walks through the "unnecessary complexity" he sees with it, citing code examples, and makes points about performance, memory usage handling stampede protection and the creation of standard ways to avoid it. He ends the post with a look at group invalidation handling and two ways it could be accomplished, either via namespacing or through tagging the items and using that as a reference point for the invalidation.

Link: PHP 5.4.34 & 5.6.2 Released

Fri, 10/17/2014 - 16:14

On the main site an announcement has been posted about the release of the two latest versions in the PHP 5.4.x and 5.6.x series - PHP 5.4.34 and 5.6.2

These releases fix several bugs in both versions including several security-related issues including CVE-2014-3668, CVE-2014-3669 and CVE-2014-3670. In the 5.4.34 release there was also a fix put in to correct a regression issue in the OpenSSL functionality.

As both of these contain security-related fixes, it's strongly recommended that you upgrade as soon as possible. As always, you can find the latest downloads on the main downloads page or for the Windows users. The full list of changes in each of the versions can be found in the Changelog.


Acquia Blog: The Future of PHP is Shared Power Tools

Fri, 10/17/2014 - 15:06

On the Acquia blog there's a recent post from Ryan Weaver from KnpLabs, well known for his contributions to the Symfony2 framework. In his post he suggests that the future of PHP is "shared power tools", less around the monolithic frameworks or installable software and more about the combinations of small pieces of code doing exactly what they need and nothing more.

[Things like Drupal, Joomla and WordPress are] painstakingly thought about and solved the same problems from scratch. And despite that, the results were incredible. How? Because they leveraged the sheer size and passion of their respective PHP communities. But it makes me wonder: what crazy things could we build if we worked together? Fortunately, we're on our way to finding that out. The PHP world is transforming and the individual armies and empires are blurring together.

He talks about how PHP developers should stop fighting the same battles and start working together using existing libraries to solve problems. He points out that applications, even the big names, are becoming more and more modular. Even Drupal has recently made the move to include Symfony packages for some of its functionality (other examples are given too). He also talks about "developer experience" in using these tools, what Symfony is doing to help it and how building on these and other components is essentially "standing on the shoulders of giants" to solve problems easier, faster and with better quality code.


Community News: Packagist Latest Releases for 10.17.2014

Fri, 10/17/2014 - 14:09
Recent releases from the Packagist: Unit Testing Succinctly: Why Unit Test?

Thu, 10/16/2014 - 18:06 has kicked off a new series of posts today that answers the question "Why unit test?" The series, Unit Testing Succinctly aims to define what unit testing is, approaches to implementing them and what they can do to help you and your application.

The usual mantra we hear regarding any software methodology is that it improves usability and quality, reduces development and testing time, and brings the product to market faster and with fewer bugs. These are lofty goals, but I have yet to see a methodology deliver the Grail of software development. Ultimately, the primary reason to write unit tests is to prove correctness, and this happens only if you write unit tests well.

In this first post they cover three of the more general reasons for making the dive into unit testing your applications at all. These are more "business value" kinds of ideas but they trickle down into the development level, providing value for the developers too.

  • Measuring Correctness
  • Repetition, Repetition, Repetition
  • Code Coverage

Their main point to reinforce is the first of the three, though. Unit testing helps to measure and ensure correctness of both the code itself and the functionality it performs.


Qafoo Blog: Utilize Dynamic Dispatch

Thu, 10/16/2014 - 17:52

On the Qafoo blog today Tobias Schlitt talks about dynamic dispatch, what he calls a "fundamental concept of OOP" to help provide clean, clear interfaces in the code.

I want to use this blog post to illustrate the concept of dynamic dispatch which I use a lot recently to motivate creating clean OO structures in my trainings. In my experience, this helps people to understand why we want to write code in this way. After that I will show why traits are bad in this direction.

He explains the concept of "dynamic dispatch" by starting from the beginning...with procedural PHP code. He looks at the usual flow of this kind of application that call shared functions in a "top down" fashion. He looks at what would happen if new logging needs were introduced (use a new method? patch the current one?) and the dependencies that can be introduced because of it. With this in mind, he continues and talks about how the "dynamic dispatch" happens during the code execution, splitting the log request based on the information it's given instead of different implementations for each. He points out that using a trait doesn't allow for this abstraction and instead embeds the code into the class itself, re-introducing the original problem.


Phil Sturgeon: What is The League of Extraordinary Packages?

Thu, 10/16/2014 - 16:48

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.