On the Laravel News site there's a new post that continues their series about building applications with Composer. In this latest post they talk about the "other half" of the Composer ecosystem - Packagist.

In our last blog post, we saw the basics of Composer but skipped over where it actually finds its packages, and how to publish packages of your own. In this blog post, we will be looking at exactly this, plus some security considerations when using composer in your application.

Packagist is the primary package repository for Composer. This is where you can publish your packages, and also where you can view other people’s packages. Composer will use Packagist to look for packages by default, however, more advanced users can customize this if they wish.

With the basic description out of the way, they then get into how to add your package to Packagist for others to use. The post also talks about package licensing, development versions, branch aliases, security considerations and how to keep on top of new versions of the packages you have installed.

Matthew Weier O'Phinney has posted an article to his site showing you how to fix version issues in branches when using Composer packages and libraries in your applications.

For the Zend Framework component repositories, we occasionally need to backport changes to the 2.4 LTS releases. This requires checking out a branch based off the last LTS tag, applying patches (often with edits to translate PHP 5.5 syntax to PHP 5.3), and running tests against PHP 5.3 and 5.4.

Of course, to run the tests, you need the correct set of dependencies installed. If you have any component dependencies, that means running a composer update to ensure that you get the 2.4 versions of those components. And that's where my story begins.

He talks about some of the issues he's come across when testing components and Composer, not understanding that the environment has changed, does not load the correct versions of the necessary libraries. He first tried to fix the dependencies himself, adjusting the version numbers required but with no luck. Finally he stumbled across something on the Composer site that helped: the ability to define a "root version" environment variable that made it adhere to the versions he needed.

In his latest post Derick Rethans talks about something that plagues every project, PHP or otherwise, after its grown to a large enough size: dead code. He's been asked why his Xdebug tool finds this code in places where people don't expect, so he figured he'd answer it once and for all.

The explanation for this is rather simple. Xdebug checks code coverage by adding hooks into certain opcodes. Opcodes are the building blocks of oparrays. PHP converts each element in your script - main body, method, function - to oparrays when it parses them. The PHP engine then executes those oparrays by running some code for each opcode. Opcodes are generated, but they are not optimised. Which means that it does not remove opcodes that can not be executed.

He gets down to the opcode level and shows some output from vld on how things are being executed (and what's not). Using a simple "foo" function example, he shows the execution flow and how the "branches" of executions work through the code. In his case, the "dead code" marker is coming from the line with a closing brace from an "if" statement. He points out that it entirely depends on the lines executed as to what is marked as "dead code".

On the main PHP.net site today there's an announcement posted about the working being done on the next generation of the PHP language based on some recent discussions (and actual development work). The PHPNG branch helps boost the performance of the language to new levels and cleans up some of the core APIs.

When we aren't looking for pictures of kittens on the internet, internals developers are nearly always looking for ways to improve PHP, a few developers have a focus on performance. Over the last year, some research into the possibility of introducing JIT compilation capabilities to PHP has been conducted. During this research, the realization was made that in order to achieve optimal performance from PHP, some internal API's should be changed. This necessitated the birth of the phpng branch, initially authored by Dmitry Stogov, Xinchen Hui, and Nikita Popov.

The post talks about the performance increase of these changes (an average of 20%) and the current progress made on the internal project. This is "only the start" of the work on this new functionality, so keep an eye on the PHP.net site for more upcoming details.

If you're relatively new to using version control, there may be one technique you've yet to get a grip on. In this new post on SitePoint.com's Web blog they introduce you to using the "diff" functionality to discover differences between versions of code.

Every project is made up of countless little changes. With a little luck, they will finally form a website, an app, or some other product. Your version control system keeps track of these changes. But only once you understand how to read them will you be able to track your project’s progress. Using the example of Git, the popular version control system, this article will help you understand these changes.

They include several screenshots and line-by-line descriptions of what each part of the output of the "git diff" command is. There's also a brief description of what each of the sections contains and how to inspect both committed and non-committed changes. There's even a link to a list of other applications that may help provide a clearer picture of the changes rather than just the command line output.

The PHPClasses.org blog has a new post today looking at a recently introduced proposal for updates to the core PHP functionality that could lead to significant speed and overall performance gains. In this latest article they talk about PHPNG.

Not a very long after Facebook announced the Hack language, Dmitry Stogov of Zend announced a somewhat secret development branch of PHP called PHPNG that brings a JIT engine, significant speed and memory management improvements eventually to PHP 6. [...] This branch was added somewhat secretly by Zend developers to the PHP development repository in April 16 but it was openly described only in May 5 when Sebastian Bergmann of the PHPUnit fame asked in the PHP internals about it. Dmitry Stogov of Zend presented a more or less detailed description of the PHPNG branch. He explained that he has been experimenting using a JIT engine (Just In Time compilation to native machine code) using LLVM.

The post talks about the availability of the branch and some of the changes (like updates to extensions) that would need to be made for it to work correctly. There's also a mention about the "plot to kill mod_php" in the future and how the discussion around it reminds the author of the deprecation of the MySQL extension a few years back. The rest of the post compares the PHPNG branch's features with that of one of the other high-performance PHP tools out there, HHVM.

Lorna Mitchell has a quick post to her site today showing you how to use a GitHub branch as a Composer dependency when the need arrises for something other than master (or whatever branch is "stable" for the project).

My current project sees Celery (a python distributed task queue) added to my PHP application. There's a handy PHP interface to the RabbitMQ that Celery uses as a backend, which makes it easy for me to create jobs, called celery-php. This requires either the PECL AMQP extension< or alternatively it has experimental support for the PHP library for AMQP - I would normally prefer the PECL version but ran into version compatibility problems, missing manual pages, and decided that a pure PHP solution might be more portable and perhaps I would just add the experimental branch to my composer.json file for this project.

She includes an example of what the "composer.json" file would look like to pull this other branch. Two pieces of data have to be defined - the URL for the repository (to prevent Composer from trying to find it) and the branch name in the "require" section where the version would normally be.

So you've been working on your own code for a while now but have been hearing about Github and how it makes it simple to contribute to other projects too. Maybe you haven't found the time to get into git and Github yet. Well, this new post (a reprinted article from php|architect) to Lorna Mitchell's blog will tell you all you need to know.

Often I find absolutely competent programmers, who aren't involved in open source, either because they don't know how to approach a project, or because they just aren't sure how the process even works. In this article we'll look at one example, the conference feedback site joind.in, and how you can use GitHub to start contributing code to this project. Since so many projects are hosted on github, this will help you get started with other projects, too.

She covers all you'll need to know to get in and get going with Github - forking a current repo (she uses Joind.in as an example), cloning your fork, making updates and submitting them as a pull request back to the main project. There's also some things about general git topics like branching, merging from the upstream source and using "git log" to view the changes.

In this new post to his blog Johannes Schlüter shows you how to easily set up a development environment for the recently moved PHP repositories (to git) using "out of tree" builds to keep versions and configurations separate.

As PHP has moved to git recently everybody who works on the PHP source has to recreate his work environment. When working on PHP I have a few requirements for my working dirs. For one I want to be able to use different branches (like 5.3, 5.4 and master) at the same time and I want to quickly test different PHP configurations, like builds using thread-safety or debug mode on or off.

He includes a set of commands you can use to to clone the new repository and create different working directories for the different kinds of builds that you want to install. He also points out as a shell script on github.

The day has finally arrived for the CodeIgniter fans out there - EllisLab has officially released CodeIgniter 2.0.0 in two versions - the Core and Reactor branches.

Today EllisLab and the CodeIgniter Reactor Engineers are proud to announce the first official release of CodeIgniter 2.0.0, which is being released in two flavors.

The "Core" version will be the branch that EllisLab uses for their internal applications and will be a bit slower moving. The "Reactor" branch, however, is more community-powered and headed up by a set of Engineers that will guide the framework and work to make it its best. Also mentioned as new in the post are the upcoming ability for users to contribute directly to the user guide, the creation of a standardized Authentication library and a more object-like model setup. If you're interested in the Reactor branch and want to try it out or contribute, head over to the bitbucket account for the project.