Have You Ever Used A Symfony Compiler Pass?

It’s been JavaScript, JavaScript, JavaScript for the past few weeks, so this week I thought I’d vary things up a little and, heck, cover a little Symfony 🙂

Yes, two new – dare I say – useful videos were added to CodeReviewVideos this week.

Lets go ahead and jump right into it.

First up we venture into the wonderful – and scary sounding – world of Compiler Passes. Now, this is one of those Symfony things that is really useful, but also something you’re unlikely to try until you’ve seen it working before. Ahh, the old catch 22. Not so bad if you work in a huge team of devs who all share knowledge (or you are particularly good at reverse engineering), but if you’re a lone wolf, or part of a smaller, less experienced team, things like this may completely pass you by.

To begin with, we start with a code smell that I saw recently when working with a client. This problematic code is fairly common, and isn’t specific to Symfony projects. You may even have it in your own projects:

Controller bloat.

This particularly issue starts off with an if  / else , which turns into an if  / elseif  / else , and within a few further iterations you’ve got this nasty conditional dominating the method. Actually in the code I was looking at, this was a common theme throughout multiple controllers, and multiple actions in each controller. It’s things like this that make people believe Symfony is hard, when in reality, this problem would follow you if you switched to Laravel, or Zend, or Slim, or any other.

We’ll use an example of having to convert an array of data into a variety of formats – CSV, XML, YAML, and so on.

To begin with, these various conversion strategies live inside our controller action.

In the first video we cover a simple way to start refactoring this code:


At this stage all we are doing is extracting the problem code from the controller. This is really easy to do, and can immediately start to reduce duplication, and increase code re-use.

Unfortunately this doesn’t actually solve the tight coupling problem. But sometimes, you know what? You don’t need too. Over engineered code can be just as painful to work with as sloppy code. It’s just a different kind of pain.

Anyway, on larger systems simply extracting code out like this may not give you the flexibility you need. For that we can use a technique that third party bundles use:


In this video we cover how to use a Symfony Compiler Pass to decouple the Conversion service we’ve created from the various conversion strategies (e.g. convert to YAML, convert to JSON, and so on).

Let’s imagine that you wanted to create a Symfony Bundle that you could then share with the world in order to help others who might need to convert arrays in the future. Whilst you might provide a variety of implementations out of the box – ConvertToJSON, ConvertToXML, and so on – you don’t want to be solely responsible for adding every possible implementation in the future.

Instead, you could allow users of your library to implement the expected interface, and then use a Symfony service Tag that tells your Conversion service to also include this custom converter that your library user has created.

There’s loads of uses for this approach, and honestly it’s easier to do than you might think. Much like a lot of Symfony concepts, actually 🙂

All of this weeks videos are free to watch, though I will be making the Compiler Pass video a Members Only video at the end of this month.

Until next week, take care and happy coding


Testing, Testing, 1, 2, 3

2017 is here. I hope you’ve had an enjoyable New Years? These last two weeks seem to have flown by, but then I guess they always do.

I’m going to keep this week’s update short and sweet, as I’m sure you will have had a bunch of accumulated emails to plow through after a two week break.

In the first two videos this week we covered testing the “happy”, and “unhappy” paths through the Request reducer. Writing the tests helped guide us through what should happen, and as your logic gets more complex, tests become ever more important in delivering working code on time, every time:




Testing reducers should be easy though. After all, they are pure functions. Where things get a little more involved is in functions that have side effects – calls to our API, and all the perils that entails.

As we’ve already covered, to handle these side effects we are using Redux Saga. But up until now, we haven’t tested these functions. When I first sat down to write a test for a Saga I have to admit, I found it daunting. Thankfully though, testing Redux Sagas is actually really, really easy.


We’re covering the “happy” path through our doLogin generator function, and in the process we’ll see how easy it is to reliably test functions that contain calls to APIs, or other side effect generating (excuse the pun) activities.

What’s New This Week at CodeReviewVideos – 30th December 2016

I hope you’ve had a nice Christmas week. I remember carving the turkey on Christmas day somewhat concerned there might not be enough. And yet, only yesterday did we finish the last of the left overs. Madness.

Over the course of the last week you may have read (via Twitter) a discussion around “side projects” and should developers be doing them in their free time over Christmas. I’ll start by sharing my opinion on this, but I’d love to hear yours:

For me, side projects are amongst the most important things a developer can be doing with their free time. Now, I’m not talking about sacrificing spending time with your family to instead be eyeballs-in-front-of-monitor (Lord knows, we do enough of that all year anyway). I mean if you’re going to sit down and write a bit of code, it might as well have some structure to it.

One of the things that I frequently hear from others developers is that we don’t get the opportunity – at work – to play with interesting / new technology. For example:

“I want to learn Redis, but my boss won’t let me.”

Controversial – I agree with your boss! 🙂

I mean I agree with the underlying reason: no, you are not hacking Redis into the production, money-making stack that runs the companies business to scratch your technical itch.

And that’s fine. There’s a way to play with Redis without any approval from your boss:

Use it in a side project!

Side projects don’t need to change the world. They don’t need to become self sustaining businesses in their own right. They have always worked best for me when they satisfy some personal demand I have that might also just happen to allow me to play with some new tech – Elasticsearch, Ansible, Graylog, etc.

Then, once you’ve played with your new tech (e.g. Redis), and used it in a real (side) project, not only will you have something new to stick on your CV, but you can also talk more authoritatively with your boss / colleagues / significant other about how awesome {shiny_new_tech} is, and how it might improve said current money making business system even further.

And hey, if your side project does transform into something money making, maybe one day in the not too distant future you will have employees of your own asking to shoehorn Rails into your PHP code, so they too can scratch their own itch 🙂

This Week in Videos

Throughout this week there have been three new videos.

First up, we looked at how we might add a spinner to our React / Redux application:


Whilst on the surface this seems really simple, what’s cool here is how that spinning icon is displayed depending on a current value in our Redux-managed state. The idea here is to keep our application’s code sane and manageable as we grow.

This implementation is fairly naive. As our application grows – think: maybe we add a Registration flow using Stripe – then we’re going to hit a bug in the way our spinner works on the back end. Thinking about this, we then move on to a better implementation:


This is nice and all, and maybe good enough, but from my own personal real world experience, we could still hit on an issue whereby our spinner seems to show / hide unexpectedly. The problem we have now is that to track multiple requests (e.g. one to Stripe, another to our API, all in the same form submission), we need a more involved reducer implementation. And whilst we could have a hack at it, instead it makes sense to write a tested implementation.


As if we haven’t covered enough new stuff in this series (what with React, Redux, Redux Saga, React Router, Yarn, Bootstrap 4… the list goes on), we’re going to start testing all our code using Facebook’s JavaScript testing framework – Jest.

To me, this makes sense as our entire stack is Facebook centric already. We might as well embrace the tooling they use. After all, if it’s good enough for the third biggest web site in the world then it’s good enough for me.

I’ll finish up here by covering one last point:

In my quest to find out how popular Facebook is for the purposes of this post, I Google’d “alexa”. In the olden days, the defacto result for Alexa would have always been the site I linked to earlier. Now Alexa is an Amazon product which occupies the top two search engine results. Alexa – the company – is owned by Amazon, and comes third. I feel old.

And with that, I would like to wish you all a very Happy New Year, and a prosperous and successful 2017.


What’s new this week at CodeReviewVideos? 23rd December 2016

I hope you’ve had a fun week coding. As it’s really nearly Christmas I’m in full scale geek mode over a present I know I’m getting. I’ve been looking forward to reading this for ages, and I’m also excited about reading a paperback. It still sucks if you drop it in the bath, but at least you don’t risk electrocuting yourself like if you drop your tablet.

I’ve been experimenting with Elixir (the language used by the Phoenix Framework) over the past few months and I love it. Apparently it’s very similar to Ruby, which I never gelled with, but there’s so much more to it than that. If you are at all interested in learning Functional Programming, I cannot recommend Elixir highly enough. A couple of nice resources to check out are:

But that doesn’t mean I’m stopping with PHP. Far from it. PHP7.1 is proving really nice, and my codebases are starting to see a liberal use of return types, nullable types, and more.

I also couldn’t be happier with how Symfony is performing as the API (back end) for the React / Redux / Saga project.

There’s some really cool new things in Symfony 3 that will be covered over the next few weeks, and there’s a really cool thing that’s been in since early days on Symfony 2 that may help make your code base more modular. Stay tuned for those.

This week we covered logging out (in a fashion) from our React front end:


There’s a bit more to it than this as we shall see once we add in a few more pages to our app, but as a starting point, it’s good enough.

Then we added a Bootstrap 4 (alpha :)) NavBar to our project:


We added in some of that ‘classic’ React style ternary to display our username and a logout button if available, or just the log in button if not. Though the code to implement this is trivial, it’s only trivial because we’ve done a bunch of the hard work before hand (via Redux / Sagas).

BTW – did you know ‘Sign In’ is probably better to use than ‘Log In’ – obligatory StackOverflow link.

Finally, we tidied up the project:


With using a boilerplate, we gain a load of things we do want, but a few that we don’t. The benefits of initially having these files around as examples far outweighs the downsides of having to spend a bit of time deleting them in the future.

All this code is fine, but it’s untested. I know there’s an absolute ton of new things to cover for any PHP dev who is new to JavaScript, but now that we’ve covered a typical work flow, and you’ve hopefully started to get a feeling of how pages / components fit together, we can now add yet another ‘thing’ to our cornucopia of things, and look at testing.

We’re going to be using Jest. It’s CV friendly 🙂

Before I go, could I ask you to reply and let me know of any conference / meet up group / user group talk – that you can find on YouTube (or similar) – that you would recommend a watch?

I’ve been watching a bunch of them recently (follow along on Twitter if you’d like to know which) and my mind seems to go blank whenever I need to think of one to watch next. I’d love a few recommendations.

I hope you have a very merry Christmas. I’ll be back before New Years, but if you don’t catch the mail before then, a happy new year to you also 🙂


Deploying With Ansistrano

I have a major problem. I keep waaay too many open tabs on my phone. Every time I see something interesting – via Twitter, Hacker News, or Reddit – I open the link in a tab and promise myself I will check it out more thoroughly soon.

I currently have 47 open tabs 🙁

This is only amplified by the fact I do the same on desktop. Right now, across three desktops I have over a hundred open tabs.

It’s becoming an epidemic.

Anyway, once in a while, one of these tabs becomes useful.

Recently I hit on a problem whereby I needed to deploy a bunch of individual JavaScript files – node.js scripts – to a server to be used as Rabbit MQ workers.

I had a bunch of requirements for these workers:

  • start with specific flags ( --harmony-async-await )
  • restart automatically if the server reboots
  • restart if the script crashes
  • can run multiple instances

And so on.

These turned out to be the superficial problems – and I say this because there’s a tool out there that already nails this problem – PM2.

Initially I thought these would be the hard problems.

What I hadn’t banked on was how much of a royal pain in the backside it might be to deploy my node.js scripts to dev / prod / wherever.


My requirements are fairly straightforward – they could be solved by using rsync. However,  rsync becomes unmanageable as a project grows.

There’s the issue of remembering the right command, and then duplicating the command – altering slightly – for the prod deploy.

And what if it goes wrong? Well, you have to handle that yourself.

Call me spoiled, but having become accustomed to Deployer (Matt did a fantastic job on this course btw, you should check it out), I now use that as my baseline for deployments.

I have a similar tool I use on JavaScript projects called Flightplan. It offers a decent level of functionality, but with one major issue (from my p.o.v):

It is a pain to deploy more than one directory.

Flightplan works on the assumption – as best I can tell – that you will be running your project through some webpack-style setup first, producing a dist directory which contains everything you need to boot your single page app, or whatever.

This is cool, but I needed to run many different worker scripts – all ideally from one directory.

As best I understand it, webpack allows this via it’s multiple entry options, but I’m not using webpack. Actually, I tried to use webpack but it threw out a bunch of errors right away and I gave up.

I also tried Deployer. But that didn’t work much good either. JS mixed with PHP leads to mess.

Enter Ansistrano

Ok, so all that was a very long-winded precursor to the eventual solution.

However, I felt I needed to do justice to how much I have struggled to get this thing working. It’s taken 5 hours… ouch.

Needless to say I tried to give up on getting Ansistrano at numerous times (see how I ended up at Deployer, Flightplan, webpack etc).

In the end though, I cracked it. So here goes:

Firstly, my playbook:

Pay special attention to the  ansistrano_git_repo entry, whereby I needed to add the prefix of  ssh:// to make this work. If you don’t, you will find Ansible doesn’t understand the path you are providing, and blanks it out instead :/

I guess I wasn’t the only person to notice this.

Also, note that the typical git path given by gitlab will contains colons, which need to be replaced with spaces:


Now note, this is an Ansible issue, not an Ansistrano issue.

This should be enough to get most of the way there.

However, I hit upon another issue.

No matter what I did, all the Ansistrano managed folders were being created as root .

Since the days of yore, I have been using the same set of flags on my runs of  ansible-playbook, and today I was well and truly bitten on the backside:

Ultimately this command sees me through. I’ve started using -vvvv on every playbook run as it saves me having to re-run when things inevitably go wrong. Also, for the love of God, use snapshots before running.

But yeah, my issue was I was running with the additional flag of  -s which forced the playbook to run as root. Silly me.

Anyway, early signs are promising. It all works. I just wish it hadn’t taken me so much time to figure out these problems. Hopefully though, by sharing I can save someone some hassle in future.