Category: Code Review Videos

Thank you to everyone who took part in last weekend’s Black Friday / Cyber Monday sale.

This was the first time I’d ever run a promotion like this and it was fun, exhausting, and not quite as smooth as I’d have liked. Next year I’ll give myself more than 48 hours prep, I think 🙂

In other news, Symfony 4 landed yesterday. As did PHP 7.2.

I’d like to say a huge thank you to everyone involved in both of these releases.

As I type this I have a GitLab CI build underway to bump up from PHP 7.1, to PHP 7.2 for CodeReviewVideos. One of the major benefits of using Docker for deployments is the speed in which upgrades like this can now take place.

I’m less ready for Symfony 4.

Personally I’m still experiencing a variety of deprecation warnings on 3.4 that stop me from upgrading. Fixing these, and any further incompatibilities is a task scheduled in for later next week. If you’ve taken the plunge already I’d love to hear about your experiences.

With Symfony 4 in mind, I’ve already had a bunch of requests for some Symfony 4 tutorials.

Currently I have four (purely a numerical coincidence) existing series in progress. I am going to finish these before I start anything new. Trying to do too many things at once has been a major learning experience for me this year, so I’m reluctantly taking heed.

Video Update

This week saw three new videos added to the site.

#1 – Part 1/3 – Deploying with git

Much like in the earlier videos on deploying with rsync , our initial explorations of deploying with git are as simple as possible. This means some things – Symfony’s var  directory for example – will cause headaches. Fear not, we will address this in the next few videos.

Personally I don’t like using git for deploys. There’s something strange about having to fake a commit to trigger a deploy.

Even so, a lot of people ask me how to deploy with git. These three videos cover one such way.

#2 – Part 2/3 – Deploying with git – Sharing folders

Having to sort out the var directory on each git push quickly gets tiresome.

We also likely cannot rely on the generated values in the parameters.yml file after a composer install has run. The setup we have, and the demo app we’re using have masked this problem from us. In the real world we won’t be so lucky.

Fortunately, we can fix both of these tasks.

We’re going to set up a shared directory, adding in the var directory and also the app directory.

We’ll then automate the symlink process to ensure both the var  and app/config/parameters.yml  file are correct for each deploy.

#3 – Part 3/3 – Deploying with git – Adding builds

By the end of the rsync  deploy process videos we had a nice setup where each new build ended up in a timestamped directory, and we could easily switch out the current  symlink to make any build live with relative ease.

We’re going to replicate this, but automate even more of the process.

We’re even going to automate some of the housekeeping chores (deleting old builds).

 

Ok, that’s about it from me this week. Until next week, have a great weekend and happy coding.

Chris

Starting right now until 5pm on this Monday (27th November) at 5pm you can get a yearly membership to CodeReviewVideos.com for just $99.

This is a saving of over $150 on the usual price.

As of this morning there are 500 videos covering Symfony, React, Docker, and a whole bunch more. There’s 63 courses to check out.

And those figures grow every week.

This is the only offer I will be running this year. Make sure you take full advantage.

Video Update

This week saw three new videos added to the site:

#1 – Part 1/3 – Deploying with rsync

Probably the easiest way to get code from your desktop to your production server is to use a tool like rsync  or scp .

We’re going with rsync as if you’re copying up largely the same contents multiple times (as we are in this approach) then rsync  will only transfer up the differences on second and subsequent runs. Secure copy (scp ) on the other hand would copy across every file, every time.

This deployment approach is super simple:

Copy stuff from our development directory right into the live / production website directory.

It’s simple and it works.

But it also breaks everything whilst a deployment is in progress, and rolling back is not easy.

We’ve got to start somewhere thought, right?

#2 – Part 2/3 – Deploying with rsync – Using builds

In the previous video we learned the fundamentals of how to shift our data from point A to point B.

There are at least two major problems with this approach:

1. We copy everything into the Live / production directory, breaking stuff as we go
2. Rolling back is a total pain

Fortunately with just a small tweak to our process, we can improve things greatly.

We’re going to bring the concept of a builds directory into play, and instead of copying up from our PC to the Live website directory, we will instead copy into a sub-directory of builds , such as builds/20171124-0921 .

If we did another deploy a short while later, we could copy up to e.g. builds/20171124-1015

What we then set up is a symlink, or short cut.

We tell Apache or nginx to serve from the shortcut, and then swap out what the shortcut points at, in order to make a different build live.

This solves both of the two problems above, but unfortunately, we lose the benefit of using rsync as each new build is effectively a full copy up of new files.

Still, that’s a minor gripe considering the improvements.

#3 – Part 3/3 – Deploying with rsync – Shared var

There is one remaining problem:

Everyone who is logged in gets forcefully logged out on each new deploy.

Why is this?

Well, each new deploy brings in a new var directory. The var directory contains the sessions  directory. If every new deploy creates a new sessions  directory then every existing session is going to be lost.

This is a lot less of an issue with stateless authentication.

The fix to this is straightforward:

Share the var  directory between every deploy.

To accomplish this we will make use of symlinks once again.

The cool thing about learning all of this is that this is almost exactly how automated deployment tools such as Deployer do this. By learning how to do things by hand, you’re going to find understanding the automated tools much easier.

One thing that automated tools do bring for us is in automating housekeeping chores:

• deleting old builds
• sorting out symlinks
• making long winded commands into one liners

And that sort of thing.

As far as manually deploying with rsync  goes, we’re about done.

This process could do to be a lot more robust, but in truth, I don’t recommend hand-cranking a deploy anyway. All we’re really doing here is learning and building a foundation for understanding automated tools, which I would strongly recommend you use instead.

Even so, we’re going to continue looking at another manual approach in the next few videos, this time learning how to Deploy with Git.

Ok, that’s it from me this week.

Don’t forget: the Black Friday Offer expires at 5pm GMT on Monday 27th November.

Have a great weekend, and happy coding.

Chris

This time a week ago I switched the DNS over from the old IP to the new. There are ways to launch with a bang, and this – thankfully – was not one of them.

Instead, a gently increasing trickle of visitors began hitting the new site.

Even though I’ve run through the Behat tests enough times to trust them, and I’ve PHPSpec’d my way to a suitable level of coverage, I still get nervous when real people start running my code 😀

I knew there would be teething problems. It’s nigh on impossible to predict every hurdle you will encounter when live, and fear of this stopped me pressing “go” for about 2 weeks.

There was also the big known hurdle:

Migrating the database

The new code uses modifications of the original entities. There were no removals of data, but some properties got moved to different objects.

All of this had to be managed by a rather fun migration script I cobbled together.

It is your typical thing of beauty / monstrosity all-in-one.

It gets the job done, but you’re glad you’re not maintaining that bad boy in the long run.

This had to be done just before the DNS change over.

This process involved dumping the live db, restoring it into a local replica db, then connecting to both the old and the new databases, and looping over each item to migrate it appropriately.

Fun times.

Last Friday morning, when I was confident with everything, I ran through this process for the last time, and the new database was up to date.

Well, close enough 🙂

Post Go-Live Fun

I expected a couple of issues.

I didn’t know what they would be, but the change was sufficiently complex enough to guess that the process wouldn’t be seamless.

As it turned out, there were two problems, and then some little tweaks.

Yeah, it ain’t workin’ on iPhone, bruv

I tested the change on every device I have.

I tested on an Apple device.

I tested in a bunch of browsers.

I didn’t test on iPhone.

Of course, I had a problem on iPhone. Not on iPad. No, no. It worked fine on the iPad. Just the world’s most recognisable phone.

I’d used URLSearchParams to get around a problem created as a result of having to use redirects for navigation, instead of being able to use React Router.

URLSearchParams needs a polyfill to work on Safari on iPhone, it seems.

What this meant was that the site would load, but not the header / footer, or any JavaScript.

My wife told me about this, but I thought it was some weird DNS issue she was having.

I asked my brother to check on his, and sure enough, he saw same. Worse, it was happening in Edge, and Internet Explorer, too.

Not having a clue how to get to a browser console on iPhone, I booted up the iOS simulator via XCode, and saw the error about being unable to use URLSearchParams which thankfully led me to the polyfill, and the next push fixed it.

I believe this is also fixed on Edge, but now not on Internet Explorer – if you use IE then oh my! No, seriously, if you use IE (or have access to it), I’d be grateful if you could let me know how the site looks in there.

So that was that.

Video Migration Woes

Between me properly starting the revamp, and launching, took me 12 weeks, give or take.

During that time I had put up 40+ new videos.

Each existing video needed to be migrated, and also the new ones imported.

I had all of this scripted up.

What I’d not factored in was that the order I expected, and the order I received would be inverted.

I was asking Vimeo – my video host – for the latest 100 videos.

I was then cross referencing the video they had, with the video I had.

If they matched, super duper.

If they didn’t, that meant a new video, so import it.

I only ran this script twice, as best I remember, as Vimeo have some rate limits which, when hit, were taking the old site offline… yikes.

Anyway, long story short, I managed to run the import and flip the last 40ish videos so the most recent had the oldest video, and so on. This was noticed in production, by a site member.

That made last Saturday morning a little more lively than I expected.

Few Other Issues

I noticed and fixed a bunch of other issues in this time.

I 404’d a bunch of blog pages.

I 500’d two video write ups.

I got the CORS header wrong which broke the shiny new Profile area (www, and non-www users)

I found and fixed some CSS problems.

There still remain some CSS issues from migrating from Bootstrap 3 to Bootstrap 4. I have these on my todo list.

If you spot anything on your travels, do please shout up.

Video Update

I recorded 5 new videos this week.

I published: 0.

There’s a couple of reasons for this, one being that to release the new videos without the next few videos, they would make no sense (it’s setup for deploy, without showing any deploy…), and also I’ve been working on the re-launch.

Being one guy doing quite a lot, I have to respect my limits. Because burn out sucks.

Thanks for all your support with the new site, I’ve had some great feedback, thank you!

If you haven’t already done so:

Check out the new site

And please, let me know what you think.

Well, that’s about it from me this week. Until next week, have a great weekend, and happy coding.

Chris

I’m always grateful to receive feedback.

Things that might seem obvious to you may have completely bypassed me altogether. Some of the forthcoming site improvements would honestly have never even made my radar if I hadn’t been told so by your feedback.

Sometimes though, I get feedback that throws me.

Earlier this week I got an email from a site visitor saying there are too many long courses on the site, and it’s hard to find the time to follow along with each course.

It was suggested that focusing on specific concepts would be preferable to the vast majority of people.

Now, I admit to having taken guesses at the answer to questions like this in the past.

And the problem with guessing is that I’m often wrong. Fortunately, I’ve learned (the hard way) that it’s simply better to ask.

Yesterday (thinking it was Wednesday), I sent out a 1 question survey to see what others thought about this.

The answers are as above.

Now, the “other (please specify)” drew in some extra interesting feedback, so thank you to those who added answers in this field. Mostly, these were requests for Symfony 4 content 🙂 There were two other requests which have been added to the list also.

Anyway, I found the answers interesting. My personal preference is for longer tutorials, with shorter ones every now and again. It seems that’s roughly in line with the feedback, so that was good to learn.

Video Update

This week saw four new videos added to the site.

All four videos come under one short course:

Stateless User Impersonation

This is a new feature coming in Symfony 3.4 that, if you’re using Symfony as a JSON API, will make one small part of your day-to-day admin burden that little bit easier.

(who am I kidding, I only recorded this series as I wanted to use this as a course cover image :))

#1 – Tutorial Setup – Getting Docker Up and Running

Docker is great. It’s allowing me to cover bigger project setups in shorter video series.

It’s not so great as, despite all its good intentions, the process of using Docker is different on Linux to how it is on a Mac. I haven’t used Docker on Windows, but I dare say the process is different there, too.

The big problem is permissions. I keep harping on about Docker permissions because they give me 95% of headaches in my usage of Docker.

This video aims to get you a working stack with the right permissions.

If you are already a Docker user, you can likely skim, or entirely skip this video.

#2 – Impersonating Users on a JSON API (WIthout FOS User Bundle)

Up until Symfony 3.4, if you wanted to impersonate a User when using stateless authentication (think: LexikJWTAuthenticationBundle), then you had to use a third party bundle to enable this functionality.

Unfortunately, it looks like support around this bundle is lacking.

Robin Chalas (chalasr) put in a change (which subsequently got merged) to add this functionality directly into Symfony.

So, now we get it for free. Well, so long as you are using Symfony 3.4 onwards.

Note that at the time of writing, Symfony 3.4 is still in Beta.

#3 – Impersonating Users on a JSON API (WIth FOS User Bundle)

Whatever I do here on CodeReviewVideos, I more likely than not get asked the question:

Yes, but how can I do {insert anything} with FOSUserBundle?

There’s no magic to FOSUserBundle. It doesn’t change the way your Symfony application works. But I understand why people ask this question.

Anyway, I get asked this so much that I have preemptively covered how to do stateless user impersonation with FOS User Bundle to save both of us the trouble 🙂

Honestly, it’s 99% the same as what we covered in the previous video. Only this time, with 100% more Friends of Symfony.

#4 – Digging A Little Deeper

To round up this short series we go a little more in-depth as to why this setup works.

We examine what the outcome of both $this->getUser()  and the outcome of injecting a $user  object directly into our controller actions.

More specifically, we cover how each of these differ, or stay the same, when working with stateless user impersonation.

What’s Next?

I keep getting requests to cover deployment. I’ve had some interesting deployment setups requested, and plan to cover these, too.

I started recording this series about 3 weeks ago. And then Symfony 4 started looming.

I then got hesitant:

Should I record a bunch of videos for deploying Symfony 3.x and Symfony 2.x, only to have Symfony 4.x drop, and make all of the newly recorded content almost immediately obsolete?

Well, then today I saw sense:

I will cover deploying with both. The Symfony 4 content will be added at a later date, and in the interim I will upload what I’ve already recorded.

Right now this is mainly Symfony with Apache, and Symfony with nginx. There’s a bit more too it than this, but that’s the gist.

Ok, that’s it from me. As ever, have a great weekend, and happy coding.

Chris