Why I support “The League”

There has been a lot of drama and press around it lately, but which does it really deserve?

“The League of Extraordinary Packages” is what I have dubbed a collective of composer packages. Its essentially a group of developers who have gathered under a single flag (or in this case a vendor name) and set standards for the packages that live there.

Why does this even matter? Well for one Packagist (the repository that indexes all libraries known to Composer) is an open repository, this means that it is wide open for anyone to join, from the best packages to the most ridiculous ones. Quality control is not one of its roles and quality checking is on average 2-3 clicks per package away.

In Packagist, Quality control (or quality information), basically means going to the package homepage and looking at its *github bling*, those developer badges we see everywhere, then diving into scrutinizer, travis, etc. Hence, click on the package, click on the link, click on badge. This is something I believe the listing should handle better.

For these reasons a curated list of packages, whomever it is that is curating it, is an interesting resource to have, adding credibility to packages and making your life easier when you are searching for that one tool.

Lots of its bad press comes based on the name, which is wrongly interpreted as a pompous attempt at superiority by Phil Sturgeon, while it is quite simply a funny reference and a fun name. Also its the joint effort of many other fine authors and amazing PHP developers, not just him.

Also, can we stop throwing knifes at everything Phil does? Sure he has his moments, we all do, but he does good stuff also, give him a break.

So these are a few reasons I like this effort:

  • Imposed Quality, Curated List: The League has its own set of rules and internal standards, this means all their packages are at a certain quality point, this makes it easier for you to judge a package’s quality and pick the right one.

  • Reduced author fragility: since the authors of packages join the league, they receive a lot more contribution and guidance from the existing pool of authors. This helps them keep the package up to date, but it also offer a possible pool of people who can take over if the original author has to step away. The internal pulse-check also helps catch inactive packages a lot faster.

  • Extended reach: as an author its not really easy for everyone to find your package. Packagist’s ordering makes it very easy to re-use the same packages over and over and not find the new ones. With the league you get a lots more attention coming from another source. This means you can reach more people with your package and bootstrap it.

  • Reduced duplication: while we cannot stop duplication on Packagist (of function and much less of vendor and package names), at least inside the League we can rely on having on a single one of each package. In the long run this helps guide developers to work together and not isolate themselves in their own package.

I really enjoy the work being done by The League, or The PHPLeague, or Pleague as I prefer to call it. I think it has provided us with some very good packages and given us all something to strive for. Maybe more collectives is what we need.

Go check them out and give their packages a whirl.

Update: I wrote this a few weeks back, and today as I publish this, I’m very happy to see the League enroll into FIG via its representative Kayla Daniels. This gives me one more point I like about it:

  • Operates as a Single Project: this means this group of people work as a unit and discuss all these internally as a team. This is a great reason to join, simply for the learning aspect, but it also brings a lot more quality to their internal ecosystem.

The AmsterdamPHP ElePHPant Project

EveScreen Shot 2014-12-01 at 16.57.24r since I started building User Groups and getting involved in the PHP community I always had a dream of introducing a new color to the ElePHPant collection. Always wanted to make more elePHPants available and to make sure everyone had access to them. With Kickstarter and the example of php[arch] and PHPWomen, the time has finally come.

AmsterdamPHP has launched a new kickstarter project to make a new color, black! We have already hit our initial funding goal, which is amazing and speaks to what an amazing community we have. We still need to get more units sold to be able to make all ends meet and walk away from this with a total win in the books.

KS_pictureI always believed elePHPants should be earned not bought, so look at it this way. You will be earning an elePHPant for supporting AmsterdamPHP. We are just getting ready to celebrate our 3 christmas as a UG and this is our way to give back to all these wonderful people who have helped us build this amazing community, a group that build knowledge, relationships and great projects. I hope you too can get motivated by all we have acomplished and adopt one of our elePHPants and give the user group a little something to keep on ticking and starting new awesome events.

Our Kickstarter is up at https://www.kickstarter.com/projects/rdohms/the-amsterdamphp-elephpant

Installing Composer Packages

I have been putting together a new talk about Composer, and that means looking around the community, doing loads of research and trying to identify the items that need to be covered in a talk. Mostly I have been trying to identify things that people do on a regular basis that according to composer internals is either wrong or not ideal.

One such thing that I have found is the proper selection of versions, and that also led me to find a new feature in composer that makes everyone’s life so much easier. So let me break this down.

Version selection

First we need to define how to properly set the version of a library you need. I’ll consider you already know about semantical versioning and its dynamics.

  • vendor/package: *
    So this is a NOPE right off the bat. As it turns out this has 2 flaws: first it will grab any version, meaning if the library breaks BC, your library will go along with it. Second it makes Composer turn into (even more) of a power hungry CPU and memory muncher, since it wides the “search scope” for the Version Resolver to work. Sounds bad right?
  • vendor/package: 1.2.*
    This one is not bad, however a point release does not break BC, so you should be able to move to 1.3 without issues, this does not allow that. Fine in this case, but it gets complicated once you have two libraries with the same requirements you now blocked the download of v1.3, which the second library may need.
  • vendor/package: >= 1.2
    Once more this bites the dust with semver since it leaves you wide open to get v2.0 which very likely will make you unit tests turn red.
  • vendor/package: 1.0.0
    This is the most restrictive of all, it will keep you locked on this version and will probably not play nice with any other library using this dependency.
  • vendor/package: ~1.2
    This is what you are looking for, its called the tilde, and it means “Next Significant Release”, its internally expanded to >=1.2.0,<2.0.0 meaning all the non-BC breaking releases before the next significant release, which will be 2.0.0. You can also be more specific with ~1.2.3 this will basically always be the lower end of the match.
    Update: Keep in mind that the number of dots will define which level of release you wish to grab, i.e ~1.2.3 expands to >=1.2.3, <1.3, restricting you to patch updates. One option you have is to use ~1.2,>=1.2.3.

Using the tilde operator gives you the best chance to avoid conflicts with other libraries, which means you will play nice and also avoids you having to update your composer.json file everytime another library releases a new version.

Adding new dependencies and Install instructions

With Composer gaining more and more traction we seem loads of libraries out there using and supporting it. However since not everyone is familiar with composer (yet!) we often end up with loads of install instructions on how to install libraries via composer.

The most common of those unfortunately goes something like:

Install this library using Composer, please add this to your composer.json file

{
  "require": {
    "vendor/package": "*"
  }
}

Now, this is a problem for 2 reasons. One, you have to edit the composer.json file, and two: to avoid editing this all the time developers usually pick “*” which we already learnt was a no-no. Also people don’t seem to agree on these instructions to no two are the same.

It just so happens there is a better, faster way to do this, which even comes with a few perks. And it fits in a single line you can copy/paste to your console and run:

composer require vendor/package

That’s it, simple as, well this. This will obviously done one thing, it will open your composer.json file and add this requirement in there for you, now messing with the file. Now some of you will be telling me i did not add the version to it, like so:

composer require vendor/package:~1.2

And this is where Composer blew me away a few weeks ago. I did not, and i should not. Turns out composer figures that part out for you (meaning it identifies the latest version available) and also binds it properly using the proper tilde operator. How awesome is that?

composer require vendor/package
Using version ~1.0 for vendor/package

Disclaimer: if you know you need a version and its not the latest, then yeah, stick to the previous option.

Campaign: PRs for a better Composer Ecosystem

So this month we are in the middle of #hacktoberfest, promoted by Digital Ocean, so you all want to stack up those Open Source contributions right? Here is my idea, let’s send a PR to every package that has the old composer.json instructions and send them an updated version with the new recommended install method. It would look something like:

To install this library, run the command below and you will get the latest version

composer require vendor/package

Feel free to add composer.phar if you feel the need. If you want to hear more, come see me talk at php[world].

How about it? Let’s fix the internet and revolutionize composer installs! Add links to your PRs in the comments!

 

J and Beyond 2014: An Overview

The past weekend marked a very important moment for me. After almost a year on the sidelines dealing with personal matters, I finally had the opportunity to go talk to and teach another community.

I was invited by Brian Teeman (@brianteeman) to go keynote at J and Beyond, an annual Joomla Conference focused on their core leadership group and the most active community members. I was very excited about the opportunity and the timing seemed to be right to get back on the speaking wagon, so I accepted the invitation, and along with my wife, made our plans to be at Konigstein im Taunus for the conference.

This event was a merge of very important and exciting points, so let me walk you throughout my side of things. First of all it marked my return, something that i had been looking forward to for a while, since teaching and speaking are things i very much love to do. The second aspect of it is that it was a new community to me. I have only worked with Joomla many years ago in a short 4 month contract in the Brazilian Government. Sufficient to say I knew basically no one in the conference, apart from Lorna Jane (@lornajane) and Sebastian Bergmann (@s_bergmann). I love reaching out to new communities and bringing to them some of what we are doing in the greater PHP community, i love getting them in touch and integrated, so this was something i really looked forward to.

The third aspect is that i was keynoting. A keynote talk has a different mindset from a regular one as it does the role of inspiring and setting a tone for the conference. This event does not use the regular opening and closing keynote format, but it still posed an entirely new area of speaking which i had wanted to try for years. So off I went into this mix of new and old and eager to make new friends and see the ones i had not seen in ages.

The event was amazing, the hotel was very nice and isolated bringing in the aspect of socials that I really enjoy from conferences like php[tek]. The organizers did a wonderful job of the regular conference and the socials. I did indeed get to know many new people, some of which were familiar with my work, some which had never heard of me, which is also very refreshing. I was very happy to spread my ideas on development and quality to a new crowd like i had done so many times before. New communities are a fresh playground to me and I love the energy that comes from them at hearing these fresh points of view.

The Joomla community is truly a great and lively one, everyone was very open to receiving me and talking about various topics, and even reaching out to my wife who was there for the ride. I felt very good amongst these people and truly happy to be speaking again. If you do any work related to Joomla, you should get to know their events and their community, they will surely have lots to add to your day to day work.

I was invited to keynote, but ended up covering a few extra topics the organizers asked me to address, so I also spoke about composer and did my talk on object calisthenics with far more detail then the keynote.

The keynote was a fresh new talk that i had been working on for a few months, trying to tie my lessons from Object Calisthenics and inspiration of writing clean code into an inspirational talk to promote these values in developers. It held the title of “Writing code that lasts” or as I like to call it “Writing code you won’t hate tomorrow”. The reaction of the crowd was very good and i really had a wonderful time being on stage ant talking to them. The conversations i had afterwards make me believe that my goal was achieved and i had developers now thinking about their code and becoming aware of these quality markers.

I hope to give this talk in many more communities and CakeFest has already invited me to do so in the CakePHP community, so hopefully you will see this talk somewhere close to you some day. Below are the slides if you want to have a sneak peek into it.

Thank you all from the Joomla Community and the Conference Organizers, it was a wonderful weekend of seeing friends, making new ones, inspiring and learning from a new community and I even got some time to explore the area which was also stunning.

DMS\Filter v2.0

I have completed the release of the DMS\Filter Package, this includes:

  • DMS Filter Library
  • DMS Filter Bundle, that integrates all filtering capabilities in Symfony.

This release includes some new features and a huge overwrite of the filters.

Independent Repositories

The first big change was a proper split of the repositories, before you had the option to go to the DMS repository where all the code would reside together, this gave me a huge overhead in management having to do sub-directory splits all the time and just slowing down releases as a whole.

Now the core library and the Bundle reside in their own repositories and issues are moved there. What does this mean to you? It just means you should report issues and follow releases in these new repositories.

  • DMS\Filter can be found at: https://github.com/rdohms/dms-filter
  • DMSFilterBundle can be found at: https://github.com/rdohms/dms-filter-bundle

DMS\Filter

Rules rewrite

I’m a big preacher of Object Calisthenics, you may have seen my talk around. And now of the OOP practices described by this is the SOLID acronym. The “S” stands for Single Responsibility, and as it happens my Rules were violating exactly that aspect of it, they were handling both the Annotation aspect of it, and the actual filtering of values. They are now split into two folders Rules, which holds the Annotations and their configuration settings, and Filters holds the classes that actually do filtering, and can even be used apart from the annotations.

This makes little difference to users, unless they were using the classes in a standalone way, but it also allows me more flexibility to provide annotations that work in providing other types of filters, as we will see in the Bundle. This brings a bit more quality to the code, I hope you all like it.

To import annotations, use:

use DMS\Filter\Rules as Filter;

New Filters: Zend and Callback

I have introduced two new filters into the fold. The Zend Filter allows you to refer to Zend Framework Filters directly form DMS\Filter, this means you can stick to using annotations and a single entry point to get all you filtering news, even if you have need of a Zend Filter. Below is an example of how to use it:

@Filter\Zend('Zend\Filter\HtmlEntities') // options may be passed as the second parameter

The Callback filter supports three types of input:

  • string: name of a method on this same object
  • array: standard PHP call type: {'classname', 'method name'}
  • closure: a closure, which is not supported in case you are using annotations

The callback filter gives you flexibility to create filters that depend on multiple properties of the object.

DMSFilterBundle

New Filter: Service

A new filter is available using the Bundle in Symfony. The service filter allows you to identify a service/method to be called. This gives you the freedom to create your own filters, without having to create all the annotation support it would require. Just use this one annotation and point it to your new service. Below is an example of its usage, beware that you need to import a separate annotation namespace in order to use this filter.

<?php

namespace App\Entity;

//Import Annotations
use DMS\Filter\Rules as Filter;

//Import Symfony Rules
use DMS\Bundle\FilterBundle\Rule as SfFilter;

class User
{
    /**
    * @Filter\StripTags()
    * @SfFilter\Service(service="dms.sample", method="filterIt")
    *
    * @var string
    */
    public $name;
}

Integration Improvements

The bundle was updated for newer versions of Symfony, as well as implementing proper support for cascade filtering. This means that if you forms use sub-forms which define child entities, these will also be filtered by the automatic form filter. This can also be disabled by setting the cascade_filter to false.

class TaskType extends AbstractType
{
// ...
public function setDefaultOptions(OptionsResolverInterface $resolver)
{
    $resolver->setDefaults(array(
            'cascade_filter' => false,
        ));
}

// ...

}

Bug fixes

The bundle was not caching its annotation use, we have now fixed that and made use of the same strategy as Symfony uses internally, so you should see improvements if you were looking at this level.

Enjoy!

I hope these new improvements give you a boost in filtering and open up new worlds of amazing possibilities. Not really. But I still hope it helps you. So go, update!