In my previous article, we covered some of HTTP's basics, such as the URL scheme, status codes and request/response headers. With that as our foundation, we will look at the finer aspects of HTTP, like connection handling, authentication and HTTP caching. These topics are fairly extensive, but we'll cover the most important bits.

In this article, they talk about things like the HTTPS secure version of HTTP, server-side connection handling, identification/authorization and working with caching and cache control headers.

IDE proponents love, in fact, an Integrated Development Environment that provides all the functionalities you need while writing and editing code; the followers of the Unix way typically write code in Vim while augmenting it via plugins where feasible and leveraging external tools that do one thing, and do it well. [...] Automated refactorings in PHP were out of the league of Vim and Unix users; thanks to Qafoo, however, a new open source tool is able to edit code with predefined refactoring recipes: PHP Refactoring Browser.

He goes through some of the basic features and functionality of the browser, setting expectations a bit. He shows how to get it installed (via Composer) and the results of some of his testing. Rather than including them all in the post, he opted to make actual commits on github of the changes.

Dice is a Dependency Injection Container for PHP. It allows you to very quickly and simply use Dependency Injection techniques in your code with very minimal effort on your end.

The article talks some about the features of the Dice DIC and shares a simple introduction to its use in a more practical example. It uses constructor injection and type hinting to automatically handle the injections based on its current set of object references.

With Dice you don't have to worry about how the User accesses the Session object, you add it as a constructor parameter and it Just works. You don't need to reconfigure the container, you don't need to do anything at all. You just alter the constructor definition and everything is done for you.

You can find more details about Dice in this post (including more examples of it in action and a link to it's repository on github.

As web developers, we know the importance of the JavaScript console provided by the browser in testing out code snippets. We don't need to write an entire HTML page and JavaScript code just to verify the functioning or logic of a small routine we wrote. Instead, we simply run the expressions in the console and immediately see the results. Similarly, a REPL (Read-Eval-Print Loop) is the console of a programming language in which we can write code line-by-line and see what it does. [...] PHP's REPL is very good in what it does, although it does have some limitations. [...] And so, Boris tries to solve these problems and other concerns as well.

He walks you through the installation (via a git clone and, later, through Composer) and shows how to run it as well as some sample output. He also shows how to make a custom command-line Boris runner and how to embed it into your application. His example of a tool that would benefit from this is a command-line web service client using Boris and Guzzle.

A piece of software is only as good as its documentation. The Zend Framework team and a dozen or so contributors are working hard to improve the Zend Framework 2 documentation, but we still want you to help us improve it even more. Any kind of help is welcome and greatly appreciated.

Most of what they're looking for is clarity - they want to ensure that what's in the manual makes sense (and is correct for the release it relates to). They're also looking for feedback on what helps you learn best - tutorials, user guides, API docs, etc. Issues and suggestions should be posted to the issue tracker in github. If you're not sure where to start, check out the contributors guide.

Since its inception, Zend Framework 1 has used Subversion for versioning. However, as we approach its end-of-life (which will occur 12-18 months from the time this post is written), and as our experience with ZF2 processes becomes more familiar, we -- the Zend team and the Community Review team -- feel that we can better support ZF1 via GitHub. As such, we will be migrating the ZF1 Subversion repository to GitHub this week. Please read on for details!

The post details the steps that'll be taken during the process including the changing of the location of the "master" branch (and how to change svn to point to it) and the updates to the integration of the Dojo libraries. They also talk some about the "extras" repository and how things will work with the Issue Tracker and pull requests in the future.

The repository and issues migration is the first step in a series of planned migrations. We also plan to eventually migrate our wiki to GitHub; this will allow us to offload functionality from the main ZF website, and also consolidate all development-related functionality (other than the mailing list) in a central location.

At first I though Cloud9 would be a simple editor, perhaps a nice showcase of what you can do with HTML5 and some well-written javascript but it quickly became evident that this app was packing a lot of powerful features. [...] Sounds pretty awesome if you think about it. You can even connect you own server via SSH instead of using the build in sandbox (this is a paid feature). Is this the Holy-Grail? Not Really, but it's close. This is a very exciting product that almost reaches holy-grail status, but it falls short in a few key areas.

He includes a little bit about trying to use PHP 5.5 in the Cloud9 editing, and points out that while he was (eventually) able to get the PHP 5.5 alpha compiled, he wasn't able to get things like memcache compiled and working.

The Cloud9 team has done a great job removing the barriers to getting a simple idea out the door. I implemented FizzBuzz in PHP using Composer, PHPUnit, and some SPL interfaces and got it all done , and posted to GitHub in about an hour.

Recently, I gave a lunch-and-learn to my team on the topic of Dependency Injection (DI). Instead of showing a bunch of slides explaining what DI is and what it's good for, I created a small project and demonstrated the process of migrating a codebase that does not use DI to one that does. Each stage of the project is a different tag in the repository. The code can be found on Github: http://github.com/jadell/laldi. Checkout the code, and run composer install. To see the code at each step in the process, run the git checkout command in the header of each section.

He goes through each "checkout" step (the title is the git command to run to follow along) showing how he migrated away from a simple micro-framework based site to one that defines the various objects (and repositories) inside the "application" object. He adds in a few comments to let you know a bit more about what's going on and some basic event handling. He finishes off the post with some potential issues that could come up both during the process and with the resulting application.

Although the main PHP-GTK site at http://gtk.php.net/ does not (yet ?) make mention of it, development of PHP-GTK is still active, but is using a more recent infrastructure, having moved to Github like many other projects.

You can find this new repository at https://github.com/php/php-gtk-src. The PHP-GTK project is an extension for the PHP programming language that implements language bindings for GTK+. It provides an object-oriented interface to GTK+ classes and functions and greatly simplifies writing client-side cross-platform GUI applications.

These days, good PHP object-oriented libraries are all around and easily available. To me, it is actually thrilling to be part of this flourishing community, while working with Symfony2 and blogging about the Framework, the Components and their neighbors (like Silex). [...] Still, to me, contributing felt like too big a step to take right now. Until a few weeks ago, when I was looking for something I needed (a PHP client for the Microsoft Translator API) and could not find a decent solution. I decided to make it myself, and share it online.

He shares his "checklist" of steps he followed to get the library up and working (less about the library and more about the process):

• Write the code
• Initialize a Git repository
• Add a composer.json file
• Add unit tests
• Make it open source and developer friendly
• Push your code to GitHub
• Register your project at packagist.org
• Register the Packagist Service Hook
• Versioning
• Continuous integration using Travis CI

He also suggests that, at least at the outset, you skip some of your tests that might rely on external data sources/resources (so the build can start as green on Travis) then coming back and refactoring to mock things out correctly. It might look like an intimidating list for a beginner, but it's a great process to follow to have a robust, effective development/deployment process.