You’ve Got To Go Forwards To Go Back

Another week goes by, and another newsletter where I can’t announce the launch of the revised version of CodeReviewVideos. It’s killing me.

I’ve pulled a PHP 6.

I’m now onto CodeReviewVideos version 3, and yet version 2 never got released! Oh my.

What’s most amusing to me is that v3 is so similar to v1 in terms of look-and-feel that I almost needn’t have bothered. Good times. Good times.

Anyway, I still have an absolute ton of stuff left to do, so today’s update is going to be short and sweet.

Video Update

This week saw three new videos added to the site:

#1 – Docker PHP Symfony Tutorial

In order to get a Symfony stack up and running with Docker there are a few pieces that already need to be in place.

These are your webserver (nginx, in our case), and likely a database (mysql, for us).

Our web stack

Also, being that Symfony uses PHP, we kinda need PHP available inside the Docker container 🙂

Now the good news is that we sorted out PHP last week. We created a ‘base’ image, based on PHP 7.1.

We can now use as the starting point for any PHP project we do. This could be Symfony, or WordPress, or Slim, or whatever.

In our case this will be a Symfony Docker image.

And what this means is that we will do a bunch of Symfony-specific tasks such as copying over the app , src , web , and bin  directories, and setting up the parameters.yml  file.

By the end of this video you will have all the pieces of the puzzle (the puzzle being: how to get a Symfony stack up and running in Docker) ready to go.

You could – if you were being particularly cruel on yourself – decide that you’re going to  docker run all these images and get everything hooked up by hand.

Or, if you prefer life being that little bit easier then you could use Docker Compose to make this task massively simpler…

#2 – Docker Compose Tutorial

In a nutshell, Docker Compose allows you to define an environment in which your project / code will run.

As above, in our case we need nginx for our web server, we need MySQL as our database server, and we need our Symfony code to run our application.

Docker Compose allows us to define how all of this fits together.

It might not make much sense as words, so here’s some real config:

Even if you don’t understand how it all works, the likelihood is you can figure out what it will do if you were to run docker-compose up  against this config.

However, one of my goals with CodeReviewVideos is to ensure you do understand how. And so in this video we cover exactly that.

#3 – Docker Compose Tutorial For Elixir and Phoenix Framework

In this tutorial series we are covering how to get a working Phoenix Framework environment up and running with Docker.

In case you aren’t aware, Phoenix is a web framework written in Elixir, a rather interesting functional programming language.

The main reason for this tutorial series is to show you that the back end and front end code can be completely separate entities.

We could use Symfony as our back end. We could use Laravel. We could use Django, or Rails, or in this case, Phoenix.

Ultimately, in most of my projects lately, all my back end does is serve up a JSON API.

From the point of view of the front end (React, Angular, Vue, some mobile app, or whatever), it doesn’t matter – at all – how the back end works. It just needs to work.

One of the often repeated pieces of advice for programmers who want to improve their craft is to “learn a different language”.

We aren’t going to be learning Elixir here. If there is interest then I would be happy to share what I know.

However this series is intended to show you how to achieve a working JSON API, and quickly, in a different environment to that which you might be used to.

Hopefully you find it interesting regardless of whether you decide to investigate Elixir / Phoenix any further.

And that’s about it for me this week.

I’ve had a lot of requests lately for “how to deploy Symfony“, so this will be covered in next week’s videos.

Until next week, have a great weekend and happy coding.


PHP > React > Server Side Rendering > PHP

Back when I was a server room techy there was a line my old boss used to say whenever I got wind of something new and shiny:

There are no new ideas in IT, just the same ones on repeat.

Of course he was being tongue-in-cheek, but there was a truth in what he said.

For example, around the time I was in this role, the IT industry was moving from distributed to centralised. That is to say we had a bunch of servers dotted all over the county, and the plan was to bring them into just two central server rooms.

This, I was assured, was very much like “the olden days” when individual desktops were replaced with “dumb terminals”, which relied heavily on a centralised Mainframe.

At some point, someone (likely an army of well paid consultants) espoused the failings of such an architecture (oh my, single point of failure!) and likely sold them a bunch of high powered standalone desktops.

This worked well for a while, then companies like Citrix came along and sold a different spin on “dumb terminals” using your existing high powered desktop, and so on, and so on.

What the heck does any of this have to do with Web Development, I hear you ask.

Good question.

As you may recall, I have been getting quite excited about launching the new, shiny revision of I had my zip lock baggy of party poppers at the ready. Things were looking super.

Then, over the previous weekend, it dawned on me:

How’s the SEO on this new site then?

Seeing as about 70% of the incoming visitors to CodeReviewVideos arrive via Google, I figured I should probably – ya’ know – give this some consideration.

I checked, and it turned out that I had, ahem, neglected to set any of the head information.

Yes, I felt quite the chimp.

But not to worry, I have all the SEO data just sat ready and waiting in the DB. After all, it’s exactly the same as for the existing site.

What happens with the existing site is what happens with pretty much any PHP site I have ever worked with:

  • A request comes in
  • The relevant data is fetched from the DB (thanks, Doctrine)
  • This data populates a template (thanks, Twig)
  • The response is returned to the end user (thanks, Symfony!)

It doesn’t matter if the request is from Google Bot, or from a real person. The process is always the same.

What this means is that the response contains everything needed to make a full page representation.

Google Bot can look at the page and see all the expected “stuff”: the header tags, and body content, it’s all there.

Sure, we can then augment this with a snazzy bit of JS here and there, but largely, it’s good to go.

Web 2 Point… Oh?!

Then sometime a few years back, Single Page Applications (SPA, and not the relaxing kind) became popular.

SPA – not as relaxing as you may have been led to believe

Fast forward a few years and boom, I’ve done a few of these here SPA’s with React and Angular, and I’m thinking: yeah, this is awesome, let’s make CodeReviewVideos all snazzy using all this wicked tech.

So I did.

The new version of the site uses React, and Redux, and Redux Saga, and it talks to a Symfony JSON API, and it’s all lovingly tested and fills me with warm fuzzy feels whenever I work with either code base.

Unfortunately, all this awesomeness does make the architecture more complex. Let’s revisit how a request / response works now:

  • A request comes in
  • The user gets sent this:

  • We are done, let’s go to the pub.

If you’re a bot Yahoo, Bing, or Yandex, you’re now done.


By all accounts these bots do not process JavaScript, so forgettaboutit.

This may very well be of no major consequence.

By way of some hard figures, the combined total visitors that CodeReviewVideos received over the last 7 days that came via a search engine that isn’t Google was:


Fixing the world for the sake of these other search engines probably isn’t worth my time right now.

But Google… well, we must do better.

Now, it turns out that maybe Google has already solved this problem.

My guess is they have. I mean, this is Google. They are super smart, and it’s their job to get this right.

But can I risk killing the site on a maybe.

No, definitely not.

What Happens Next?

Back to the HTML from above. Thinking about the request / response sequence, what happens next?

Well, on the client side – which is to say in your visitor’s browser – assuming they have JavaScript enabled, the JS is read and run (or parsed and executed, if you’re a CS text book).

Cus i’m Shiny!

This is where all the cool stuff happens!

  • React builds the page from my components
  • The components instruct the browser to make requests to the back-end API for the real content
  • The real content is received
  • React renders the content into the right place(s)
  • The visitor is completely indifferent

By the way, if the visitor doesn’t have JavaScript enabled then they are going to have a bad time. But, ya know, 2017, etc, etc.

When I realised my mistake about SEO last weekend, my first thought was to simply grab my Helmet and populate the head tags using the API response.

Alas, as we have now seen, this simply will not do.

So I figured I would be a Smart Guy ™ and put a caching layer in front of my web server. Maybe I could trick the bots by returning a fully cached version of each page.

Yeah, that didn’t work.

At this point I had a short breakdown.

Fortunately, PHP North West happened which took my mind off of the problem.

Ultimately though, it meant I had to postpone the scheduled launch. And that sucks.

Server Side Rendering anybody? No? SSR? No?

Of course I’m not the first person to have experienced this problem.

There is already a solution:

Server Side Rendering.

The idea here is rather convoluted, but stick with me:

We already have our shiny new React site, right? Yes, yes we do.


So, let’s get a Node JS instance to sit in front of our React site, and uses some of the stuff we learned in the Dark Arts class at Hogwarts to run this code, then convert the response to a string, and write the string to a template, which is turned into another string which is sent back to the browser so that we now have the necessary HTML to please Google like in the olden days.

Oh my.

It seems like we’re repeating ourselves here.

But now with more layers. More bug filled, confusing, maybe unnecessary layers.

Anyway, that’s where I’m at with CodeReviewVideos right now. Trying to migrate my existing front end code from client-side only, to this SSR setup to essentially reproduce the outcome I already have with plain old PHP.

What this means is right now I have no ETA on the next version, and once it is again “ready”, I will need to go back through a phase of testing before go-live.

Video Update

This week saw three new videos added to the site:

#1 – [Part 1] – Twig Extensions – How to add a custom CSS class to an invalid form field

Between this, and the next video we look at a question I got asked late last week:

How can I add a custom CSS class to the input / other form field when validation fails for that field?

This video explores one possible solution to this problem.

What happens however, is that we end up with a bunch of repeated logic living in a Twig template.

Generally, if you find yourself repeating yourself… or you end up with complex logic living inside a Twig template, you can probably extract it into a better location – a custom Twig function.

#2 – [Part 2] – Twig Extensions – Create a Twig Extension Function to Keep DRY

As such we look at extracting this repeated logic from our Twig template into a Twig Extension.

It’s one of those topics that sounds like it might be hard, or too nerdy, or whatever.

It’s just a strange name for a very useful concept.

If you use Twig in any seriousness, and you don’t yet know about Twig Extensions then this video should help you understand how to use one, and why it’s not as hard as you might think to do so.

#3 – Docker Elixir Phoenix – Part 1 – The Web Server

In my personal experience there has been no better way to improve my overall knowledge of software development than by learning another language.

Elixir, in this case, is the language.

Phoenix is somewhat akin to Symfony, or Rails, or what have you. It’s a framework for web applications.

In this series we are building up a small but functional (ho, ho) JSON API using Elixir and Phoenix.

In this video we cover how to set up the Web server by way of docker-compose.yml. This series is a little more advanced than most of the content on CodeReviewVideos, but I hope you’re finding it enjoyable all the same.

That’s It, That’s All

That’s just about it from me this week.

My favourite snowboarding movie 🙂 Great soundtrack.

As mentioned last week I spent the previous weekend at the PHP North West conference.

You can read about my time there right here.

There are pictures 🙂 and also a lesser spotted Rasmus found in his natural habitat.

Have a great weekend, and happy coding.


[PHP North West 2017] – Conference Review

This was my fourth consecutive year attending PHPNW, which is now in its 10th year overall.

Why didn’t I attend the first six? I didn’t get involved in the PHP – or indeed any tech – community until then. Probably to my detriment. So, if you’re sat reading this and you’ve never been to a conference then I would urge you to find a local one and head along, even if you go solo (as I always do).

For once I was early, so managed to get a coffee before heading into the keynote.

Keynote – PHP in 2018 – Rasmus Lerdorf

This year the keynote was by creator of PHP, Rasmus Lerdorf.

I was very excited when the conference line up was announced and Rasmus was revealed as the keynote. I know, I know, major geekout, but still, this is the person whose hard work has allowed me to do what I do for the past 15 years or more. Without PHP I might still have found my way into software development, but the barrier to entry would have been significantly higher.

This talk covered a bunch of interesting topics:

Firstly, Rasmus suggested those interested in search technology like Lucene, Elasticsearch and similar should look at Vespa. I saw this on Hackernews the other day but haven’t looked into it as of yet. Rasmus suggested an entire industry might spring up around this, similar to Hadoop.

This slide caught my attention. Although way beyond my personal needs, it’s pretty cool to see that you can create an optimized PHP binary for your specific needs… at least, I think that’s what this is doing.

There were some interesting slides on the financial cost of power savings as a result of using PHP7+. This could be contrasted with Bitcoin:

Running Bitcoin uses a small city’s worth of electricity

I’m not sure of the orders of magnitude, but according to Rasmus’ slides, PHP drives 50% of the web which is ~1 billion websites.

Currently only ~5% of those are running PHP7.

That 5% equates to ~$200m savings annually. Plus a lot less CO2 in the air.

If PHP7 could reach 100% adoption this could save $4 billion annually, with 7.5 billion kg less CO2.

In other words – switch to PHP7 and save the planet.

Probably the coolest thing coming in PHP 7.2 (in my opinion) is Dead Code Elimination (DCE). What this does, from a very high level, is to analyse your code, and then silently discard any instructions that would have been redundant.

The funny part about this is that the worse your code is, the better your potential savings 🙂 And the joke of it all was that there’s likely a lot of bad code out there in PHP-land (especially if you listen to the haters), so things look rosy 🙂

The slides explain this much better than I could ever hope too, should you wish to understand how. Simply using PHP 7.2 (and especially 7.3+) will give you this benefit for free.

There are a few new features coming in PHP 7.2 that you may find use for. Honestly, there’s nothing here quite as big as those PHP7, nor 7.1.

There is parameter type widening:

You can use trailing commas everywhere:

You can now use  object as a typehint:

Also Libsodium is now in the PHP Core. Crypto is not my strong point, but my understanding of this is that by having Libsodium as a part of the PHP Core that the resulting code that does need to use encryption, signatures, and password hashing will be more secure by default.

Rasmus gave this link for reference.

Phan was also covered.

Now I recently tried to use Phan against both a Symfony project running on PHP7, and also a legacy app that had a ‘custom’ framework. I struggled with it.

What I’d like to do is put Phan into my GitLab CI pipeline. I haven’t managed this yet as at the time it didn’t work for me ‘out-of-the-box’. I will revisit it though – maybe it would be a good topic for a video 🙂

One thing I did take note of was that Phan works a lot better if you use Docblocks in your code. Yet another reason to document 😀

Overall it was reassuring to see PHP as a language is still being very actively developed, and the future holds a good many treats for us as developers, without us really having to do very much (just upgrade to the latest release).


Meet Terraform – Michael Heap

From the keynote I headed to Michael Heap’s talk on Hashicorp’s Terraform.

Hashicorp make some great tech – Vagrant being the one you’re most likely to have heard of.

I had heard of Terraform before this talk, but was not too sure how it might fit into my personal dev / ops workflow.

My biggest question before this talk was:

How is Terraform different from Ansible?

Here’s what I concluded:

Terraform allows you to define your server / infrastructure setup as code.

For example, say I wanted three digital ocean droplets of a particular size, in a particular data centre, all named in a particular way.

Terraform makes this easy for me.

I would likely still need Ansible to actually install and configure the software that runs on these machines, however.

After Terraform has created the machines according to my spec, it could invoke my Ansible playbook commands to do this for me.

In short, the tools are complimentary, rather than competitive.

Michael shared a bunch of potential gotchas towards the end of this talk. You can find these from slide 87 onwards. I liked this as not only did it demonstrated Michael’s obvious real world experience in using the tool, but also that in reality, once you do start using Ansible, or Terraform, or whatever, they are never quite as simple as you might have been led to believe.

An example of this might be in what happens if you make a mistake. Michael explained that the  taint command could be used to mark a box as to be destroyed and re-provisioned. This definitely sounded easier than when things go wrong with Ansible…

Morning Break

During the first break of the day I decided to quickly review the notes I’d taken from the first two morning sessions.

It was at this time I realised my handy note taking app – Gmail – had somehow deleted my draft. Sigh.

Needing a place to sit and hastily re-type my notes, I headed for the ‘Unconf’.

If you aren’t aware, the Unconf is the fourth talk-track. It only announces its speakers on the day, so you won’t find them on the official website. The talks here are shorter – 25 minutes – and often more advanced, or specific in subject.

As soon as I saw a talk about Symfony Flex I decided I would be in there for a while 🙂

Unconf – Creating Rich Universal React Apps Powered By RESTful PHP – Akihito Koriyama

There was a lot of detail in this talk – more than could be reasonably covered in 25 minutes.

A really useful takeaway for me here was in what the HTTP OPTIONS  verb is supposed to be used for. Now, here’s me thinking it’s just the annoying verb that often reports a failure when CORS problems occur 😉

OPTIONS , I learned, are (rather unsurprisingly, given the name) supposed to tell the API consumer exactly what can be done with any given endpoint.

Now this all assumes you are providing a truly RESTful implementation. In most of my projects lately I have instead opted for the simpler approach of providing a JSON API.

There was a lot of emphasis on HAL. All examples were given in the context of Bear.sunday though Akihito did also mention that API Platform offered similar functionality, for the Symfony-inclined.

I really enjoyed this talk. I wish I had taken further notes around Akihito’s implementation of Server Side Rendering, which has become a problem for me in the time since attending PHPNW17.

Unconf – Enfys: The Infant Year – Mark Baker

I had absolutely no idea what Enfys was before this talk.

You may not either, so allow me to enlighten you:

Enfys is the Elephant plushy representing diversity in the PHP Community.

This talk was all about the journey from idea to successful kick-starter.

This was an absolutely fantastic talk, well delivered and full of warm feels 🙂 It is obvious that Mark cares passionately about his project, and its wider implications.

I would strongly recommend reading the kickstarter page as it contains a great description of what this project is about, and why it’s needed. I confess my ignorance to issues like this well in advance. Being that I work almost entirely remotely, I have never experienced any of the problems that this project aims to address. Without attending PHPNW17 I likely would never have come to hear about this project.

I had to ask – what does Enfys mean? Mark told a wonderful story of how he came across the name. Again from the kickstarter page:

“Enfys” is a Welsh name meaning “Rainbow”, and is gender neutral (it can be used for both boys and girls), so it seemed an ideal name for a new Rainbow Elephpant, to promote Diversity within the PHP Community.


Dinner Time

I wouldn’t normally spend too long on the dinner time round up, but at PHPNW17 I got lucky.

Rasmus, less so.

One of the strange parts about the PHP North West conference is that at dinner time the food is served in the main exhibition hall area, but you can eat in the unadvertised dining area.

Fortunately having been a few times now, I knew about the dining area, as eating a chicken steak stood up is not easy to do.

Anyway, in I went and being a loner, it’s usually fairly easy to find a seat.

I spied 3 empty chairs towards the back of the room, and plonked myself down.

Shortly after, Rasmus arrived back to his chair – the very next chair – and took his seat. Oops, had I stolen Rasmus’ seat? Alas no. Thankfully.

Anyway, not wanting to miss my opportunity, I asked if he’d mind my interruption for a question. He obliged.

After thanking him for giving me the opportunity to do what I do (in a roundabout way), I asked him: why Etsy?

Here is a person who can very likely walk into literally any tech job in the world – so I was entirely curious as to why he would take that job.

Rasmus explained how Etsy is a great choice if you want to make a real difference to the lives of artists.

There’s a ton of opportunities about (particularly in Silicon Valley) that are simply about making money for the various mega-corps, but Etsy enables real people to make a living from their art work.

I can identify with this not just because my wife is an artist, but because as coders a lot of what we do is more art than science. Well, at least that’s my interpretation of it. I can totally understand why Rasmus would take such a role.

Symfony Flex 101 – Renato Mendes Figueiredo

Symfony Flex is just around the corner. If you haven’t heard of Symfony Flex yet (come out from under that rock!) then you will do as of November 2017, when Symfony 4.0 becomes the new stable release.

My understanding of it is that Symfony Flex replaces the Symfony Installer. Symfony Flex aims to reduce / remove the boilerplate config needed to get most any Symfony bundle up and running.

The main point of concern I have currently is that this will possibly make it harder, not easier for those new to Symfony to get started. My own observations are that Symfony has lost a sizable chunk of new project market share over 2017 because of how difficult, by comparison, it is to get started with Symfony compared to e.g. Laravel.

Anyway, Renato’s talk was thankfully not about such things.

Instead it focused on how to use Symfony Flex to get a new project up and running. A live demo, over a potentially sketchy wifi connection is always fun, but Renato pulled it off.

Renato covered how to use some of the official recipes – for example to get the Web Debug Toolbar, and Web Server pulled into the project, and up and running without any configuration required.

Renato then covered pulling in, and starting a GraphQL server. All rather fantastic.

I thoroughly enjoyed this talk. I thought it was well presented, and the content was easy enough to digest in the allotted time. I found the demos interested, and the presentation style both relaxed and informative.

Great stuff.

Async requests and reactive responses with php-fpm – Holger Woltensdorf

This talk covered a problem that so many non-trivial PHP applications face:

How to do work in the background without it becoming a nightmare?

Typically when faced with background jobs I would reach for RabbitMQ. Holger showed that perhaps we could use PHP-FPM for the job, instead.

This is a really interesting project which I would advise you check out on GitHub.

The problem defined here has been puzzling me for a while. My personal experiences with RabbitMQ have been largely enjoyable in development, and largely horrible in production.

My own experiences tell me this is a really tricky and complex problem. The solutions to which are exactly the kind of black-box code that cause head-scratching and hair loss when they go wrong. If you have such a problem, potentially Holger’s library may offer you a solution.

As a side note I’ve lately been looking into the Elixir language as a potential alternative in this problem space. Some of the built-in features offer a potentially ‘simpler’ (or at least, less black-box-y) alternative. Time will tell.

Baking security into your workflow – Tim Nash

I have to admit by this point I was flagging. My brain was filled with good, useful stuff. What better then than a security talk!?

Fortunately Tim was full of enthusiasm and joviality, and was clearly enjoying presenting.

Tim drilled in the oft-repeated maxim of never trusting user data. Ever.

If you receive data from end-users then it must be validated. Good solid advice.

It made me think of how sometimes this kind of advice is really hard to bake into a real workflow, however.

For example, when working with Stripe and their Webhooks, one of their recommended practices is to verify the data signature. This is good advice, of course, but with some of Stripe’s Webhook data, it is impossible (to the best of my knowledge) to test – because the signatures don’t work in their faked / test responses. At least, that was my experience.

Of course this isn’t a slight on Tim’s talk in any way. It is simply that even with the best of intentions, security is flippin’ hard.

Tim shared a bevvy of useful tools, so here goes:

  • Kali Linux – full of hacker tools which you can pen-test your network / website(s) with.
  • Metasploit – I *think* this was the one Tim said was most Scriptkiddy-ish.
  • OWASP Zap – good, but possibly going to give false positives / noise
  • Vesuppi Garcon – detect a bunch of bad stuff via static analysis. Maybe useful in your CI pipeline?

A couple of other points made where:

  1. Disable registration on your WordPress blogs, if at all possible. And certainly don’t make the default user role to be Administrator. Lel.
  2. Watch your mail queue – often spikes are a great indicator of hacks.

The GDPR is coming, are you ready? – Michelangelo van Dam

The short answer: probably not.

The General Data Protection Regulation (GDPR) is a law that’s going to affect most everyone, as best I understand it. Essentially if you collect and process privacy related of EU subjects, you need to be paying attention.

(sorry that’s a terrible photo, and that’s saying something as typically my photos are terrible to begin with :))

Most big businesses have not got their acts together regarding GDPR as of yet.

You kinda ought to take this seriously, as if you suffer a data breach and are subsequently found responsible,and fined, you may very well be put out of business as the fines are incredibly steep.

One key takeaway from this talk is that you cannot be compliant with GDPR – you can only be ‘ready’. And defining ‘ready’ appears to be the biggest grey area of all.

It’s highly contentious, as was demonstrated during the QA section of this talk.

Hallway Track

For the first time ever at a conference I skipped a session (the closing session) to chat with a fellow dev.

I had a great chat with Rick West, who I encourage you to follow on Twitter.

Thanks Rick 🙂

After this it was back down the M61 for me, home in time for tea and medals.

Day 2

Yes, PHP North West is a two day conference over both a Saturday (all day), and a Sunday (till 13:00).

I missed the opening address – in fact, I didn’t even know there was an opening address on day 2 until reviewing the schedule for this blog post. Whoopsie daisy.

Chatbots and PHP – Katy Ereira

This was my favourite talk of the entire conference.

I remember relatively recently having a discussion with my wife about how, when I used to go to a bunch of business networking events, I was always getting asked “do you make apps?”, and “how much for an app?” etc. So many variants. So many people wanting the next Facebook for £1000.

Anyway, I don’t go to any of those business networking events anymore. Success.

But after hearing Katy mention how Bots are the new Apps, I do wonder now if the questions have changed to “how much for a bot?”. Thankfully, I’m happy to wonder.

I really enjoyed this talk because of how wonderfully practical and inspiring I found the content.

The examples were clear, and I could envisage real world use cases immediately.

The concept for the bot used in the talk was to accept restuarant reservations. To begin with this began as a command line app, but Katy explained how this could be turned into a Facebook or Slack bot without a huge amount of effort.

Times have moved on since I last looked into some of the concepts behind how these bots work. I remember working with spammy article spinners that would convert / spin articles using { he | him | man | person } sorts of thing, and the resulting articles came out at about the same quality as paying $5 for 10,000 words on odesk (ahem, upwork :/).

Nowadays, however, we don’t need to concern ourselves with such matters. Instead, Katy explained how we can simply hook into Google or Facebook’s AI, and get them to figure out what the user is talking about. Very fascinating, though I’m somewhat dubious about Google / Facebook’s longer terms plans from all this data collection.

Skynet was mentioned 🙂

Some interesting links:

Beep boop.

Teaching the next generation – Michael Woodward

I attended this talk as it seemed to be inline with what I’m trying to do.

Michael introduced us to his project – PHP School, which if you have ever used Node School should feel instantly familiar.

Taking ownership of your learning is a concept I feel more developers should pay attention too.

I strongly believe that being a software developer – if you enjoy writing software – is the best job in the world.

MySQL Worst Practises: Bring your system to its knees – Andrew Moore

After a somewhat unusual start, this talk was amongst my favourites of the conference. Fortunately I don’t do a huge amount with vast volumes of data in databases as of late, and haven’t had to do ops tasks on such complex setups as described for a good long while.

sorry this photo is bad 🙁

This talk, as the name suggests, focused on stuff that you ideally should not do if you want to get your 8 hours of sleep per night.

These included:

  • Don’t use NFS

Putting your database on disk accessible via the network introduces latency, which makes people sad.

  • SAN / NAS also not good because of the latency, and are effectively an expensive single point of failure.

NetApp were mentioned. Ho ho.

  • RAID 10 is preferable for your DB disk
However, we aren’t all made of money. Mirroring and striping are costly. But then, so is losing your data 🙂
  • Don’t put your temp dir on same disk as the data dir

Say no more.

  • Don’t use Windows as server

I wasn’t going to write anything further here, but Andrew did expand on that this is because lack of access to good MySQL tooling.

  • Don’t use MyISAM
Yesterday tech for today’s applications. My sides.
There are a bunch of other tips in Andrew’s slides which I am unfortunately not able to locate. If you do MySQL beyond the basics then I would urge you to watch the video of this talk when the vids are released.

Closing Keynote: For The Love Of Code – John Cleary

This talk had a couple of important points that left a lasting impression on me:

  1. If you want to do the Keynote, then you should ASK.

I don’t want to do a keynote. As a matter of fact, conference speaking in general holds very little appeal to me.

But asking is so, so important.

One of the hardest things do as a developer can be to ask for help. It feels like defeat.

However, often those around you would much rather you simply ask early, rather than spending hours / days / weeks going down rabbit holes or feeling lost / confused / distressed.

What’s the worst that can happen if you ask? You get rejected. Rejection sucks, but at least you asked. Now go ask someone else 😀

2. Test Your Core Values

In order to test your core values, you need to know what your core values are.

Now this exercise is beyond the scope of this blog post, but it’s well worth taking the time to do this, even if it feels like bull hockey.

The content of this talk is based on the book The 7 Habits of Highly Effective People by Stephen R. Covey. Also his website is built with PHP, so no excuses.

My only criticism of this talk was that it was too short. I’m not even sure why it was so short, perhaps it was explained but I missed it.

And On That Bombshell

All that remained was for the conference to be closed for another year.

At this point Jeremy dropped the bombshell that this was to be the last PHP North West conference for the foreseeable future.

I can understand this: plenty of conferences organisers have stated just how physically and emotionally taxing it is to run a conference, and after 10 consecutive years the entire crew of PHPNW are only to be applauded.

And indeed they were, with a standing ovation.

I’m not sure how to take the news that PHPNW18 won’t be a thing. I’m not sure what it says about PHP. This was the (possibly unanticipated) message that I pondered on my journey home.

The truth is PHP is not a sexy language right now. It hasn’t been for a good long while, and possibly never will be again. Depending on where you are in the world right now, there may be a language that is dominant in your location.

Typically that language is JavaScript.

I don’t see any immediate issue for PHP. For the next decade or so everything should be business as usual.

But as we approach 2030, will PHP still be relevant? It’s hard to say. And it ties in with the decline in new developers taking an interest in the language.

Anyway, rather than end of such a downbeat note:

I have thoroughly enjoyed my previous four years at PHP North West, and want to say a huge thank you to everyone involved in making it happen. I hope to see you all again in the future 🙂

Beta Blockers

It’s been a busy week here at CodeReviewVideos.

I want to thank everyone who tried out the site in the “beta” test. This has now ended, and I’m ready to launch the new site version. Hooray.

The only reason to delay now is that I’m away all weekend (more on this below), and as such, don’t want to launch on a Friday. Instead, the launch will likely be Tuesday, all things being equal.

There’s a bunch of tasks for the launch – it’s not quite as straightforward as I’d like. The hardest part is around migrating the database. I’ve changed the structure quite a lot between versions, and keeping both in sync across two different servers is proving… interesting.

There have been so many lessons learned during this process. Just this week I realised none of the pages had HTML head tags. Whoops. But then it turns out populating these tags from an API response isn’t super straightforward either. There’s no server-side rendering to help me 🙁

Another problem that caught me totally off guard was the sitemap.

Being that CodeReviewVideos is an existing, live site I know that whatever SEO ‘stuff’ I have in place already must be mirrored to the new site.

What I hadn’t thought through was the location of the sitemap.xml  file.

In the current iteration, I’m using Symfony with Twig. Everything lives on one server, and as such, making the sitemap is really straightforward. I use a bundle (PrestaSitemapBundle) and it just works.

For the new site there are two areas where pages may come from:

  • Static pages – i.e. the FAQ, contact / support, privacy policy, etc
  • Dynamic pages – i.e. the Course / Episode pages

There are some libraries available that will help generate sitemaps for React-based projects. I looked at each in turn but none seemed to fit my needs. I found this odd, honestly, as surely I’m not the first person to meet this problem.

Instead, I decided to roll my own. Well, I say “roll my own”, but really it’s a combination of some Doctrine query output dumped into Samdark/sitemap.

This worked really well, but.

It’s a big but.

The sitemap is generated on a sub-domain – under api dot codereviewvideos dot com.

Apparently, having done some research, Google ain’t so keen on this. They want the sitemap to live on www dot codereviewvideos dot com.

The problem being that behind the scenes these are two entirely separate concepts. Both are Docker images with all the necessary data “baked in”. How could I dynamically generate a sitemap from one, and it appear on the other?

Well, it turned out Docker Volumes came to my rescue. I could bind mount a file on the underlying host, and make the file appear as though it were on the www site automatically.

There have been an absolute ton of unexpected surprises like this along the way.

Video Update

This week saw three new videos added to the site.

#1 – Docker MySQL Tutorial

There’s a school of thought that says Docker and Databases don’t make good bedfellows.

For my money, this debate is really only worth having if you’re heading into production. If you’re simply wanting to play around with a database, or you have some local development work to get done, then Docker is perfect for the task.

In this video you will learn how to quickly spin up a working MySQL database server, in almost no time at all. Once you’ve got the latest MySQL Docker image stored locally on your computer, getting a new container up and running takes seconds.

As with almost anything Docker related, there are a few potential gotchas. It’s really all about reading the instructions (or the docker logs  output) if things don’t go according to plan. In particular here, you will need to use one of the mandatory environment variables.

We finish up this video by taking the example docker run command provided in the docs, and turning it into a more practical, usable variant along with storing our database on a named volume.

#2 – Docker nginx PHP Tutorial

Getting MySQL up and running was fairly easy going. And earlier in this series we saw how we could quickly spin up a Dockerised nginx server without much effort, either.

However, beyond some simple examples, the truth is you will need to do quite a bit more to get a working development environment that replicates Vagrant or some Ansible-managed VM infrastructure.

The way we will work through this is to separate nginx from the actual application code. In other words, nginx, php, and our Symfony site will all be separate Docker images.

On the surface of it, this seems like we’re going a little overkill. However, stick with me through this, and the next two videos, as this approach has served me well in the real world.

#3 – Docker PHP 7 Tutorial (7, 7.1, and higher)

As covered in the previous Docker nginx tutorial, our stack will be split across multiple Docker images and containers.

We’re going to let nginx accept incoming requests for our PHP-powered site(s), but the nginx container won’t know how to process PHP code. Instead, it will hand off to a dedicated PHP-processing container.

For our purposes we are going to create a PHP 7.1 image. This will be relatively generic, containing all the stuff most every PHP site will need. This will include a bunch of system level dependencies such as curl , and git , through to PHP deps such as intl , pdo_mysql , and optionally xdebug .

However, we won’t directly use the PHP image we create. Instead we will use this as the starting point for all future PHP Docker images. For example, in the next video we will use it as the basis of a Symfony image. But I also use the image as the base for WordPress, and custom PHP projects too.

PHP North West

This weekend I will be at PHP North West. If you are heading to PHP North West then please say hello 🙂 I already know a few of you will be attending, and I’m looking forward to meeting up in person.

The other reason I mention this is that support response times may be a little slower than usual. Apologies in advance if this causes you any inconvenience.

This will be my fourth year attending PHP North West, and whilst I didn’t blog about my first visit (not sure why), I did capture the previous two. Expect similar for PHPNW17 some time next week.


Pffft, who browses on Mobile anyway?

Several weeks ago I decided to knuckle down and get the new version of out from the safe confines of my desktop, to the scary world of Production.

“How much work can it be?”, I thought, rather foolishly.

It turns out that I had completely underestimated the scale of the task.

As an indicator of just how poor my estimation was, I thought it would take ~2 days. It has taken 3 weeks 🙂

But the good news is: it’s done!


Well, of course, I say done, but what I really mean is it’s ready to launch but there’s still a whole raft of improvements yet to come.

But we already did it. It took SEVEN HOURS, but we did it. It’s done.

Ok, so to set the scene:

My vision for the next major release was to separate the front end and the back end entirely. This means the front end code (React/Redux) lives in one GitLab repo, and the back end (Symfony) lives in a different GitLab repo. The only way they interact is via HTTP requests.

This has worked really well, but came with a whole bunch of ‘gotchas’ that I hadn’t planned for.

There’s still a big one on my todo list: the Sitemap.

For CodeReviewVideos when using Symfony with Twig I made use of Presta SiteMap Bundle. This works really well. It does the job it sets out to do, and generally gets out of the way.

However, being that the back end is now simply a JSON API, I cannot use Presta SiteMap Bundle any longer – after all, Symfony is no longer aware of every available route.

It’s not a show stopper, but it does delay me switching the site over completely until I figure it out.

Then there’s the Mobile Responsive view.

Even though it’s 2017, and one of the first things I do when I wake up in the morning is to roll over and check my phone, I still routinely forget to test my dev projects outside of Desktop view.

As such, it only dawned on me on Tuesday this week that hey, perhaps I better check what the site looks like for mobile. And needless to say, it didn’t look good 🙂

There have been a bunch of other issues, particularly with Bootstrap / CSS. I decided to go with Bootstrap 4 for this one – figuring it would be relatively easy to do large chunks of copy / paste from the existing site to the new one.

Again, not so.

Whenever I use an image in a video write-up I use the css class of  img-responsive which means, as you likely will have guessed, the image scales nicely depending on the screen size.

Oh sure, I meant for it to look this way :/

In BS4 they have removed  img-responsive. Now it’s img-fluid. Even though it sounds minor, it still involves a bunch of MySQL tomfoolery to find and update each instance, and that all costs time.

Anyway, I could go on, and on… and on about this but that wouldn’t be much fun for anyone, I’m sure.

I really just wanted to share this as I’ve had conversations with other fellow developers in the past and have found sometimes they believe it’s a problem personal to them. Like they should have anticipated every potential problem and planned accordingly. Launching stuff is hard 🙂

Video Update

It wasn’t all work on the new site this week. Heck no.

I managed to get three new videos up, too.

#1 – Symfony Event Subscriber Tutorial

Are you using Events in your code?

If not, you may be missing out on a way to separate and (from one perspective) simplify your code.

I use Events all the time.

In this video we look at Symfony’s Event Subscribers, and how they can be used to split up your logic into easily digestible chunks.

And that’s all great, but sometimes a real world example can illustrate the point a lot better, so…

#2 – Symfony Event Subscriber in a JSON API Example

This video covers one way I’m using custom Events and Event Subscribers to respond to ‘things’ (some may call them: Events) that happen in my code.

For the purposes of this example I want to show how I use an Event Subscriber to help process incoming POST  requests when using Symfony as a JSON API.

In just over three minutes, the aim of this video is to show how easy this setup is to use inside a real code base. I say real, because aside from changing some variable / object names, this code is ripped directly from the new version of CodeReviewVideos 🙂

#3 – Symfony Events – The Gotchas

Alas, using Events in Symfony isn’t all happy paths and hi-5s. There are some potential gotchas.

In this final video in this short series we cover some – potentially – unintuitive ways that Events behave inside Symfony. This stuff may be obvious to you, but all of these problems are things I have experienced as points of pain for other fellow devs in real projects.

Watch this video and keep your blood pressure at its normal level 🙂

Other Stuff

If you haven’t received an invite to test out the new site, and you’d like one, please do get in touch.

Please don’t take it personally if you haven’t received an invite – I’ve been basing it on the most recently logged in users during the exact times I’ve been sending out invites, and only in groups of twos and threes.

PHP North West is next weekend.

If you are planning on being there, I’d love to meet up and say “hi” in person. Please get in touch if so.

Ok, until next week, have a great weekend and happy coding.