Category: News and Updates

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

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:

version: '3'

services:

    db:
        image: mysql:5.7.19
        hostname: db
        volumes:
          - "./volumes/mysql_dev:/var/lib/mysql"
        env_file:
          - ./.env

    nginx:
        image: docker.io/codereviewvideos/nginx.symfony.dev
        hostname: nginx
        volumes:
          - "./volumes/nginx/logs:/var/log/nginx/"
          - "./:/var/www/dev"
        ports:
          - 81:80
        depends_on:
          - php

    php:
        image: docker.io/codereviewvideos/symfony.dev
        hostname: php
        volumes:
          - "./volumes/php/var/cache:/var/www/dev/var/cache/:rw"
          - "./volumes/php/var/sessions:/var/www/dev/var/sessions/:rw"
          - "./volumes/php/var/logs:/var/www/dev/var/logs/:rw"
          - "./:/var/www/dev"
        env_file:
          - ./.env
        depends_on:
          - db

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.

Chris

Several weeks ago I decided to knuckle down and get the new version of CodeReviewVideos.com 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!

Woohoo.

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.

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.

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.

Chris

Behind the scenes this week I have been extremely busy with the new site launch.

All being well, I anticipate sending out the first batch of emails today. If you’re an active site subscriber, please keep an eye on your inbox.

I still have a bunch of outstanding tasks before then, so I’m going to keep today’s update short and sweet.

Whilst I have your attention would you mind hitting reply and letting me know:

If you could see a video / course on the site that would help you right now, what would it be about?

Thanks!

This week saw three new videos added to the site:

#1 – Dependency Injection and Symfony Services (Updated for 3.3)

First up we are covering the recent changes to Symfony’s approach to Dependency Injection.

One of the recurring issues I see with many developers who are new to Symfony is in understanding how to access Services from other Services.

See, it’s fairly obvious in a Controller. There are a lot of examples about, and particularly in the docs this use case is covered a lot.

However, after a short length of time in using Symfony you will inevitably migrate from everything in your controller, to controllers making use of services.

This means creating your own services.

And these services need access to other services – whether they are services provided by the Symfony framework, or ones of your own / your team’s creation.

I often see the same mistakes being made here, so wanted to cover this in a video I can refer developers to in the future.

#2 – An Introduction to Symfony Events

I make a heck of a lot of use of Symfony’s event dispatcher.

Typically these days I try to keep my controller actions as small as possible, and one way to do this is to dispatch events when things happen during a controller action.

This is better illustrated with some code, so here goes:

    public function postAction(
        Request $request,
        EntityManagerInterface $em,
        EventDispatcher $eventDispatcher,
        CourseFactory $courseFactory
    )
    {
        $form = $this->createForm(CourseType::class, $courseFactory->create(), [
            'csrf_protection' => false,
        ]);

        $form->submit($request->request->all());

        if (!$form->isValid()) {
            return $form;
        }

        $course = $form->getData();

        $em->persist($course);
        $em->flush();

        $eventDispatcher->dispatch(
            Events::COURSE_CREATED,
            new CourseCreatedEvent($course)
        );

        $routeOptions = [
            'slug'    => $course->getSlug(),
            '_format' => $request->get('_format'),
        ];

        return $this->routeRedirectView('get_course', $routeOptions, Response::HTTP_CREATED);
    }

This is an example of a controller action from the new version of CodeReviewVideos.

This controller action allows me to create new courses, and do the majority of the common stuff inside the controller action.

I use a form to ensure the data being submitted is valid according to my business rules.

I create the course with a factory, because I no longer use Doctrine’s lifecycle events for created at / updated at.

I still save / persist the new course in the controller action. More on this in a sec.

I then dispatch an event to say, hey, a new course has been created.

At this point other interested parties (registered listeners / subscribers) can ‘hear about’ this event, and take some appropriate action.

Examples of this are writing some data to the log. Or in this case specifically, indexing the new course within Elasticsearch.

The good news is the controller action needn’t be concerned with any of that stuff. It just ensures an action is dispatched, and my concerns are nicely decoupled.

Back to why I persist in the controller still, though.

I did try moving this logic to a separate subscriber, and it did work. But I didn’t like it. It didn’t feel right, for me. Your opinion may vary, of course, and that’s cool too.

#3 – Keep Constant, and Dispatch Events from Services

There’s two parts to this video.

First, rather than rely on strings for our event names, it’s better – in my experience – to use a Constant instead.

To begin with we cover one approach to doing this. It may seem trivial, but on larger projects your sanity will be thankful 🙂

Secondly, and tying in with the video #1 above, we look at how we can dispatch events from our own Symfony services.

This second part is almost a recap of video #1, albeit a little faster, and more specific to dispatching events. The reason I cover this topic twice is because the original email I received regarding events mentioned this particular problem, which led to me creating this new short series on Symfony events in the first place.

That’s all from me for this week. Until next week, have a great weekend, and happy coding.

Chris