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

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:
  • DMSFilterBundle can be found at:


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.


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.


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)
            '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.


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!

Using Git Hooks to delegate routine tasks

My team currently uses GitHub as the center of our development process, taking full advantage of Pull Requests and all that. That means we use git and our process is to always develop using feature-branches, making PRs for each feature and then merging them in after code review.

This means we switch branches a lot, either to see someone’s code and review it or to kickoff a new branch for a new feature. Over time this scenario seemed to happen a few times:

  • Switch to master and pull in updates
  • Start working in a new feature in a new branch
  • Write something and run tests or view the site
  • OMG!! everything is broken!
  • turn to team: “I’m getting an error on the stuff you added, did you get it?”
  • team says: “No”
  • me: “ah dammit, did not pull in required dependencies” or “ah dammit, I did not regenerate assets” (this may or not be preceded by hours of pointless debugging)

Basically I keep forgetting that every time I switch branches I should get up-to-date dependencies and compile a new CSS to get all the latest shiny. So in order to make this automatic I decided to setup a git hook that did that for me.

Creating a Git Hook

Git has lots of hook points, so just pick one that fits your flow. In my case I picked the post-checkout hook, since I want this to happen every time I switch to another branch.

To create a new hook, you need to create a file in the .git/hooks folder with the name of the hook you want to attach to, in my case post-checkout, make sure this file is executable and then code your hook in shell script format.

chmod +x .git/hooks/post-checkout

Writing a on-demand hook

Sometimes you just flip between branches to check up on things and get some updated code, so you may not always need to run composer and install assets, so I also baked in a confirmation step to allow me to abort in case I’m doing something else.

For now all I needed was to run Composer and generate my assets (less to css and such), so this is what I got:


# Allows us to read user input below, assigns stdin to keyboard
exec < /dev/tty

while true; do
    read -p "Run Composer install and Assetic Dump? [Y/n]: " yn
    case $yn in
        [Yy]* ) composer install; php app/console assetic:dump; break;;
        [Nn]* ) exit;;
        * ) echo "Please answer yes or no.";;

Wrap up

Git Hooks are pretty cool, if your workflow is build around git like lots of team do nowadays the hooks are a cool place to tie in your day to day stuff that tends to be forgotten and generate unneeded debugging and such. Take a look at available hooks and think about your routine, I’m pretty sure you will find something you can delegate out to git and stop worrying about it everyday.