Composer is something special in the world of PHP. It has changed the way we handle application dependencies, and quelled the tears of many PHP developers. You see, in the olden days, when you wanted to build an application that relied on third party dependencies you would have to install them with PEAR or PECL. These two dependency managers both have a very limited set of outdated dependencies and have been a thorn in the side of PHP developers for a long time. [...] Enter composer, king of the package managers.

He jumps right in and gets into the configuration (the composer.json file) and using it to describe the package. He shows how to set up "required" resources complete with version number information. There's a bit about setting up autoloading and classmaps too. He then moves on to getting the tool installed and using the composer.json definition to load in needed packages (and development ones if needed).

Enjoying the introduction to Zend Framework 2? I hope so. In part one of the series, we looked at Dependency Injection, otherwise know as the Inversion of Control principle. Then, in part two, we looked at Modules and the ModuleManager, the next key aspects. In this part, we started to work through what they are and stepped through how to build one from scratch; along with some pointers for taking them further. In this, the 3rd of 4 parts, I'm taking you through the next key aspect of the framework - the EventManager.

He starts with a graphic showing its overall functionality - an implementation of the Observer design pattern - and a general description of its goal (basically, execute code when actions are triggered). He talks about its implementation of aspect oriented programming and its event-driven architecture. Then he gets into some code-based examples: checking a query parameter on a dispatched request and logging form data before and after validation.

Zend Framework 2 uses a ServiceManager component (in short, SM) to easily apply inversion of control. I notice there are good resources about the background of service managers (I recommend this blog post from Evan or this post from Reese Wilson) but many people still have problems to tune the SM to their needs. In this post I will try to explain the reason why the framework uses multiple service managers and how you can use these.

He talks about the different service managers that are available in the framework, why they're used, how they relate to the service locator and how you can define/fetch your own services in them. He includes some basic configuration code and compares the behavior of the root service manager to the others (application services, controllers, view helpers, etc).

Elizabeth Naramore interviews Laura Thomson about being a manager, the current state of PHP and speaking at Hacker School.

They talk some about Laura's background in development and PHP, how she learned to become a manager of a development group at Mozilla, the Hacker School event and some of the things she's seen happening in the PHP community. You can listen to this latest episode by downloading the mp3 or subscribing to their feed.

You may have heard about Composer and Packagist lately. In short, Composer is a new package manager for PHP libraries. Quite a few people have been complaining about the lack of information, or just seemed confused as to what it was, or why the hell we would do such a thing. This is my attempt at clarifying things.

The briefly explains what the tool(s) do and shows how to set up the configuration on both sides - Composer to manage the packages and the package definition configurations (including meta about the project and any dependencies). He also answers several "why" questions about the need for a package manager, using this versus PEAR, the choice of JSON for config definition and a current status of the project.

Flexible hours, great pay and a fun atmosphere awaits the ideal candidate for this position.

Fun, dynamic software development company in North Dallas looking to hire an experienced web applications developer on a contract-to-perm basis.

The ideal candidate will possess extensive experience in the following:

• PHP (experienced with Object and Class PHP methods) (5 yrs+)
• Applications project lead experience - includes managing project lifecycle from concept, requirements gathering, development .. through testing.
• MySQL - must have experiences with complex queries, store procedures. (3 yrs+)
• JavaScript - Advanced Scripting, AJAX, JQuery
• Linux (Red Hat)
• HTML
• XML/XSLT

Ideal candidate must be able to self-manage for multiple tasks, able to adapt to changing circumstances and have 3-5 years direct experience in business web application development. Must be able to work well alone or as a team.

Please submit your resume as soon as possible. Position is 30 day contract-to-perm.

Applicants must be US citizen or be able to prove legal work status

Please send resumes to careers@firescope.com Subject: PHP Developer Position

If you aren't already familiar, a package manager and repository for CodeIgniter libraries was released last week at GetSparks.org. In the few days between then and now, some very interesting and useful packages have been submitted. There's one for combining, minifying and caching assets, one for database scaffolding, viewing logs, geocoding, template-ing, etc.

A screencast is included showing his in-depth look into the service and how easy it is to use. He also points to the service's twitter account and github repository.

A new release of PHP Manager for IIS (version 1.1.2) is available for download. This release includes translations into 5 languages. [...] Note that this release still includes English and it is recommended to upgrade even if you do not need these translations

The new languages are German, Dutch, Turkish, Japanese and Russian and the post thanks each of the community members that helped with the translation. The PHP Manager for IIS is a tool for managing one or more PHP installations on a single IIS server.

Its possible to create up to 100 test users per app, creation allows you to choose whether the user already should have the application installed and which permissions you want them to have, using API calls. You can also remove users, list all of your app's test users and even create friend connections between them using the API. This really is a great resource, but using an API to get this information all the time is cumbersome and might take time away from your time to develop the application itself. This is where the Test User Manager comes in.

He explains some of his thoughts behind the development structure of the tool and includes some basic descriptions (and screenshots) of listing out the test users for an application, making a new user and creating/viewing the relationships between those users. As of the writing of his post, he's in version 0.9 which you can download from github. Obviously, you can also clone the repository and submit your own enhancements too if you'd like.

This post is not so much for developers as it is for the managers and bosses from those developers. As you probably know by now, managing software engineers (or programmers) is not an easy task. They just don't like to play by the rules you always took for granted. Why is that? Why are those pesky programmers too hard to handle? Why is it so hard to sit down, write code and shut up??

The questions are yes/no and, at the end of the test, your questions will be assigned to points from 0 to 12. Here's just a few of the questions (they all come with summaries to help you understand what its asking):

• Do you work with lenient working hours?
• Do you give enough time for planning?
• Do you enforce an IDE?
• Are your programmers in the loop?
• Do you have enough distraction for programmers?