In part one of a new series on the SitePoint PHP blog Bruno Skvorc looks at the right way to start a PHP package using a set of guidelines that have evolved recently in well-structured, well-tested PHP packages.

In recent years, good standards for PHP package design have popped up, in no small part due to Composer, Packagist, The League and, most recently, The Checklist. Putting all these in a practical list we can follow here, but avoiding any tight coupling with The League (since our package won't be submitted there - it's specifically made for a third party API provider and as such very limited in context).

The list of rules includes topics like having a license selected, using PSR-4 autoloading and having in-depth code comments. Bruno uses these as a foundation and starts in on the creation of a package. He uses the PHP League skeleton structure to create the files and folders for a basic package. From there he updates the contents with details for his Diffbot example and installing other needed software libraries. The rest of the post is broken up into the two remaining steps and examples under each: sticking with the PSR-2 guidelines and planning for the structure of the package.

The more you use modern frameworks and the more modular you build your PHP applications, the more likely you'll use a skeleton (or template) for creating new projects. In fact, most of the better known frameworks provide skeletons for you to bootstrap your application with. Those skeletons are great to get started, but it's very likely you'll have your own stack of composer packages that you integrate in each project after a while. Each skeleton will be slightly different, so you'll likely fork your own. This article is meant to provide you with an understanding on how to build a skeleton that will allow you to automate things as far as possible.

He starts with some of the basics, both in the terminology that will be used in the article and a little bit about projects in Composer. He shows how the Zend Framework 2 project makes uses of a built-in "composer.phar" file to make bootstrapping easier but soon asks how it could be improved. The answer comes in the form of Composer's own "create-project" functionality (with a few additions, like cleanup scripts run after the fact). He then gets into building his own custom skeleton that includes a custom post-create-project cleanup script, templates for static files (README, CHANGELOG, etc) and a basic "composer.json" configuration for the end result.

One of the big advantages of both Symfony and Silex is that they are based on the Symfony HttpKernel component. [...] But handling HTTP requests with the Symfony HttpKernel also gives you a lot of free and optional features like a built-in reverse proxy written in PHP, easy handling of ESI and Hincludes (via the Fragment sub-framework), or the gorgeous Symfony web profiler.

The profiler provides information on which components were accessed, their memory consumption and how long they took to execute. The integration happens via the WebProfiler provider for Silex and is already integrated into the Silex skeleton base application.

Evan Coury has a recent post to his site showing you how to set up and use the ZF2 skeleton and ZfcUser components of the Zend Framework 2.

This is meant to be a short, easy-to-follow tutorial to help you get started with Zend Framework 2.0 and add perhaps one of the most common modules, ZfcUser. By the end of this tutorial, you'll have a simple ZF2 application with user registration and authentication capabilities.

In this new post to his blog, Philip Norton reminds you about a handy feature of PHPUnit, the popular PHP unit testing tool, that can make generating tests for your application simpler - the skeleton class generator.

If you create classes in PHP then you should be unit testing them as much as you can. Setting up unit testing classes for your code can be time consuming and involve a bunch of copying and pasting. Thankfully, PHPUnit comes with a couple of helper functions that allow the creation of unit testing classes automatically, which can save a bit of copying and pasting.

He includes an example of a class named "Spider" and shows both the contents of the class and the resulting test that comes from running "phpunit --skeleton-test" on it. The resulting test has methods for each method in your class and marks them all as incomplete. As Philip notes, this is a good start but should never be relied upon as a test to leave as-is.

In the continuing development of his online PHP-based game, Pádraic Brady has created a simple class to help with mapping out the objects/structures in the game. He shares the code for this in his latest blog post.

The code sets the stage for the Redux mapping system. Basically, we're aiming at a grid-based map with each grid coordinate representing a Sector.

Right now, it's just a skeleton structure, but it already has some of the key bits of functionality in place. The Redux_Map class manages the requests coming back and forth between the client and server, and the Redux_Map_Grid class helps to generate a grid structure of the objects found in that sector.

He even includes the unit tests for testing the Redux_Map_Grid class to ensure everything's in tip top shape. Next on his list is adding actual entities to the game - planets, facilities, etc.

Sebastian Bergmann has posted another update about the upcoming PHPUnit 3 project, this time concrening the improved skeleton generator that's been put in place.

PHPUnit can help you write your tests by analyzing the code of an existing class and generating a skeleton test-case class for it. With PHPUnit 3 this feature will be more powerful as it now supports @test annotations in the class source.

To illustrate the point, he gives a bit of code for a calculator class with a single add() method. When the skeleton generator gets its hands on it though, it spits back out a complete testing suite with predefined functions ready for your assertions (and completely valid, even without them).

Without going into theoretical details, some of which are quite alien to me, I'll try to describe some of the challenges that pattern patching rewriting macros might pose for a language like php. After brief explanation what kind of a beast is this, I try to explore some of the finer points, which might cause problems. The intent of this post is to sketch a design and highlight some of the possible issues.