News Feed
Sections




News Archive
feed this:

Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Jordi Boggiano:
My view of PHP version adoption
November 18, 2014 @ 09:28:12

Jordi Boggiano has a new post today sharing some of his own insights about PHP version adoption but, unlike some of the raw numbers shared before, his perspective comes from aggregating data from Packagist.

Pascal's number are interesting but I believe they have a bias towards older PHP versions. I would argue that people configuring their servers properly are also those that tend to keep up to date with newer versions, and part of the best practices is to avoid publishing the software versions you are using (i.e. disable expose_php in php.ini). If I am correct here that means early adopters are mis-represented in those numbers. In any case, I do have another biased dataset to present so here it comes! I looked in the packagist.org logs of the last fifty days for GET /packages.json which represents a composer update done by someone.

He notes that the data is biased towards development machines (not always running the same version as their production counterparts) but that it shouldn't skew the numbers too much. He compares two different datasets, one from November 2013 and the other from November 2014, showing a major change in the overall numbers and moving the largest version used up from 5.3.10 to 5.5.9. He also shares some interesting statistics around the requirements developers are putting on Packagist packages...that have basically remained the same over the past year (sadly).

0 comments voice your opinion now!
jordiboggiano version adoption packagist statistics

Link: http://seld.be/notes/my-view-of-php-version-adoption

SitePoint PHP Blog:
Personal Packagist with Toran Proxy
September 09, 2014 @ 11:43:43

In a recent tutorial to on the SitePoint PHP blog, Alexander Cogneau shows you how to create a personal Packagist (the repository for Composer packages) using the Toran proxy.

Most of you reading this already know Composer. For those who don't, you can read a previous article of mine before continuing. We can all agree that Composer has brought many good things into the PHP world. If one dares however to look for drawbacks, or better put, not included features, he could state that it is not possible to work with private repositories. That argument won't hold anymore, since there is Toran Proxy.

He calls this the "end of the Satis era", replacing the Packagist clone that mirrors the packages locally rather than pulling them right from GitHub. Using the Toran proxy, he walks you through the setup of the proxy and using the wizard to complete the configuration. There's a personal use license for Toran that allows for one developer but after that you'd need to upgrade to the yearly/per developer pricing structure.

0 comments voice your opinion now!
toran proxy packagist tutorial setup configure

Link: http://www.sitepoint.com/personal-packagist-toran-proxy/

Matthias Noback:
There's no such thing as an optional dependency
April 11, 2014 @ 11:19:19

In his latest post Matthias Noback suggests the idea that there's no such thing as an optional dependency when it comes to working with packages and Composer.

On several occasions I have tried to explain my opinion about "optional dependencies" (also known as "suggested dependencies" or "dev requirements") and I'm doing it again: "There's no such thing as an optional dependency." I'm talking about PHP packages here and specifically those defined by a composer.json file.

So that everyone's on the same page, he starts with an example of a true dependency in a sample adapter class. He asks the usual question - "what's needed to run this code?" - and looking a bit deeper at the "suggested" packages. As it turns out, some of these dependencies turn into actual requirements when you need certain features of the tool. He points out that this is a problem with quite a few packages in the Composer ecosystem and proposes a solution - splitting packages based on requirements. He gives an example based on his adapter with a Mongo requirement split off into a "knplabs/gaufrette-mongo-gridfs" package that's more descriptive of the requirements.

0 comments voice your opinion now!
optional dependency composer packagist suggested package

Link: http://php-and-symfony.matthiasnoback.nl/2014/04/theres-no-such-thing-as-an-optional-dependency/

Gary Hockin:
Less is More
April 07, 2014 @ 09:56:36

Gary Hockin has a new post to his site talking about how he's found that less is more when it comes to what to include in your "composer.json". He works through some of his own opinions on the matter and suggests a bit more thought before just including another library.

I have absolutely no doubt this post will be largely disagreed upon by many in the PHP community, but I've had a terrible day and I'm hoping that the process of just getting this off my chest will be therapeutic in some way. [...] So, today I sat down and started writing the tests for our new lightweight SDK that offsets much of the work needed in the delivery of the adverts to workers via a Beanstalk queue. It should have been so easy. Things went well for the early part until I realised that I wanted to be able to extract and serialise our Device object to put it into the queue, and then hydrate it back into a Device object inside the worker

He assumed that since he'd used Zend Framework 2 a good bit and there were no (declared) dependencies, he could directly use an individual component. Unfortunately, there was a dependency (ZendFilterChain), requiring another package to be added via Composer and pulled down. He points out that Composer has made this almost too easy and developers maybe aren't as thoughtful about the libraries they pull in because of it.

He makes a call out to developers to remember the idea behind the MicroPHP Manifesto and really think about the code they're puling in, how large it is and if it's what they really need. He's not suggesting that Composer is the problem, rather the blind usage of it without thinking through the implications.

0 comments voice your opinion now!
less more library composer packagist include

Link: http://blog.hock.in/2014/04/05/less-is-more

Pádraic Brady:
PHP Package Signing My Current Thoughts
March 10, 2014 @ 11:57:49

Pádraic Brady has a new post sharing some of his ideas around PHP package signing and a few possible ways to approach (and possibly solve) the problem.

We figured out how to write good code. We figured out how to write good code in a reusable way...for the most part. We figured out how to distribute and mix all that good reusable code in a sensible fashion. Can we now figure out how to do it all securely? [...] The problem with package signing from my perspective is tied up in a phrase most of you would know: The needs of the many outweigh the needs of the few. Thank you, Spock.

He compares two different alternatives, Public-key infrastructure (PKI) vs (Pretty Good Privacy) GPG, and how the idea of trust fits into the picture. He also points out an unfortunate fact when it comes to the initial adoption of package signing methods - people are lazy (and cheap). They want to get things done and not have extra steps. Signing their packages would be one of these steps. He suggests an alternative, though, using double signatures to verify the integrity and validity of its contents. He also talks about the role that metadata plays in the overall package ecosystem and how signing it as well could be part of the solution.

0 comments voice your opinion now!
package signature signing metadata packagist composer

Link: http://blog.astrumfutura.com/2014/03/php-package-signing-my-current-thoughts

Matthias Noback:
PHP - The Future of Packages
January 22, 2014 @ 09:04:03

In a recent post to his site Matthias Noback looks at what he sees as the future of packages in PHP including some thoughts about the offerings on PHPClasses.org and the rise of Composer/Packagist.

When you ask me: what is the reason for a PHP developer to write classes? I answer: in order to separate responsibilities and hide data. Many principles have been devised to help developers fulfilling these tasks. But in most cases there was no sign of these principles underlying the code on phpclasses.org. This is why many people have turned their back on phpclasses.org. I was about to do the same. But in response to my tweet some people, including Manuel Lemos, responded that everybody needs a place to learn and try.

He looked a bit more into the PHPClasses site and found some new features not known about (including Composer support). He points out some issues with their approach about publishing packages and how they're released. He contrasts this with how Packagist.org handles the Composer information and package statistics. He looks at some recommended ways to judge the quality of packages and mentions a new book he's writing to help PHP developers create better, more useful (and flexible) packages.

0 comments voice your opinion now!
future packages phpclasses composer packagist

Link: http://php-and-symfony.matthiasnoback.nl/2014/01/php-the-future-of-packages

Qandidate.com:
Using Satis for fast and reliable software deployment
December 05, 2013 @ 11:57:32

One of the major recent advancements in the PHP ecosystem has been the use of Composer (and the Packagist service) for package and dependency management. Unfortunately, this default setup comes with one big limitation - if the Packagist or Github are unavailable for some reason, your Composer install will fail, possibly leaving you dead in the water. So, what can you do to help? On the Qandidate.com blog today they introduce you to Satis and how to integrate it into your deployment process.

If you're familiar with Composer you know it can be slow and sometimes unreliable when one or more packages are not available. Every time you run composer update Composer will access Packagist to check for new versions of the packages you use. When it finds new releases it will access GitHub, BitBucket (or wherever the packages are hosted) to download your packages.

Satis is a "private Packagist" and provides the data Composer needs to fetch and integrate either your internal packages or mirrors of external ones you've created. They help you get it installed, configured and show how to build and serve up the information via PHP's own built-in web server. They also touch on a few other related points - the speed of Satis, reliability and some concerns around securing your installation.

0 comments voice your opinion now!
satis introduction packagist composer alternative private package

Link: http://labs.qandidate.com/blog/2013/12/05/using-satis-for-fast-and-reliable-software-deployment/

Zend:
Apigility Progress report zf-mvc-auth, packagist, and PHP's built-in web server
November 01, 2013 @ 15:52:11

In a new post to the Apigility forums today Matthew Weier O'Phinney has announced the release of an authentication/authorization component for the recently announced project from Zend. Apigility is a Zend Framework-based tool for easily constructing and managing an API.

We've been working hard on Apigility since ZendCon, and have released some more code into the wild. zf-mvc-auth exists to provide both authentication and authorization for your APIs; in fact, it's a bit of a general-purpose library for ZF2 MVC apps! Right now, we support HTTP basic and digest authentication out of the box, and will be working next on OAuth support. Authorization is done by default via ZendPermissionsAcl, as we discovered a problem with using RBAC: RBAC is deny-by-default, which does not work when you want an open-by-default schema. You may opt-in to deny-by-default, as well as mark individual services as requiring permission by default. Finally, you have the option of denying/allowing per HTTP method of a service as well.

You can find out more details about this functionality in this quick screencast. The zf-apgility module depends on this new zf-mvc-auth module, so it will be included and available by default in your APIs. In that same post Matthew also talks about the listing of the Apigility packages on Packagist service and a note for those wanting to use the built-in HTTP server to run the tool (a PHP version dependency).

0 comments voice your opinion now!
apigility progress zendframework mvc authentication authorization packagist http server

Link: https://groups.google.com/a/zend.com/forum/#!topic/apigility-users/_mOPkxxmGYI

PHPMaster.com:
Listing Packages on Packagist for Composer
April 24, 2013 @ 11:57:49

Composer has changed how PHP developers work with external libraries and packages in even just the small amount of time its been around. One of the keys to its use, though, is getting your code listed on the Packagist site for easy requesting. In this new tutorial on PHPMaster.com, they walk you through doing just that.

You've created an awesome library, and now you're ready to open source it and share it with the world. Hopefully someone else can benefit from your work, and maybe you'll even receive a bug report or patch to make the library even better. But none of that can happen unless people can find itů and the modern way is increasingly becoming through Composer and Packagist. In this article I'll show you what information is needed in your composer.json file and how to list your library on Packagist so others can easily find it.

He talks some about the "composer.json" file for your project and talks some about the content that has to be there for Packagist to be able to pick it up correctly. He then shows you how to go over to the Packagist website, log in and add a package to their repository. It then shows you where on Github you'll need to go to set up a Service Hook to talk back to Packagist when a new version is deployed.

0 comments voice your opinion now!
listing package composer packagist tutorial repository

Link: http://phpmaster.com/listing-packages-on-packagist-for-composer

Matthias Noback:
Experiences with PHP Open Source Software in a Symfony-Friendly Environment
November 14, 2012 @ 11:24:19

Matthias Noback has a new post today sharing some of his experiences working with Open Source software, specifically as it relates to this dealings with a "Symfony-friendly environment".

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.

0 comments voice your opinion now!
opensource software process checklist github composer unittest travisci packagist



Community Events





Don't see your event here?
Let us know!


symfony conference interview security community library voicesoftheelephpant series artisanfiles framework laravel version opinion podcast introduction composer release language list tool

All content copyright, 2014 PHPDeveloper.org :: info@phpdeveloper.org - Powered by the Solar PHP Framework