Docker Tutorial For Beginners (Update)

I’ve been super busy this week behind the scenes working on the new site version. Typically, every time I think I’m done (we all know we are never done :)), I hit upon something I’ve either missed, or overlooked.

There are a bunch of CSS related jobs:

Yeah… if you could just fix that margin-top, that’d be great

And React seems to have completely broken my mailing list sign up forms:

You can’t tell from a static image, but these inputs don’t allow input 🙂

And some things I only noticed when testing my user journeys:

What, no remember me?

One thing I am really happy with is the new Profile panel:

4 tabs, a lot of work 🙂

There are 29 open tickets left before I consider this next version done (again, never really done :)).

I reckon I will be happy enough to open the beta when I’m down to 20 tickets. I genuinely wish I was a 10x developer, able to blitz stuff like this out in a weekend.

I’m really looking forward to switching over though. This new site is so much nicer to work with from a development point of view. And I have a bunch of improvements from a member / visitor point of view, too 🙂

Both the front end and back end are completely separated. Both are pushed through a GitLab CI pipeline, which automates the test runs, and if all goes to plan, builds a Docker image for both. I can then deploy these using Rancher.

It’s a great setup.

As you may have noticed, Docker is currently the main course topic on the site. This is a Docker tutorial for beginners. If you’ve ever wanted to learn Docker, and prefer to see real world setups rather than simplified examples then this is the right starting point for you.

Which brings me neatly on to this weeks…

Video Update

This week saw three new videos added to the site.

All of this week’s videos fall under the same theme:

Long, and short term storage of data in Docker.

One of the most confusing aspects of switching my stack from Virtual Machines to Docker was what was happening to my data?

In Virtual Machine-land (if such a place ever existed) the location of my data was fairly obvious. It would either be on the VM itself (on the virtual hard disk), or on some attached network drive.

Things are roughly the same in Docker, but it’s not a 100% like-for-like experience. Especially not on a Mac.

#1. Docker, Without Volumes

Are volumes essential for persistent storage in Docker?

It can sometimes seem that way. A lot of Docker tutorials I followed seemed to equate persisting data with Docker Volumes.

In this video we explore persisting data within Docker containers without Volumes.

Yes, it can be done.

Yes, it works just fine.

And yes, you will lose your data if you delete the container your data belongs too 🙂

So don’t fall in to that trap. Watch this video and learn how to avoid this mistake.

#2. [Part 1] – Docker Volumes – Bind Mounts

I’m going out on a limb here, and I’m going to guess you love a good Star Trek episode as much as me.

Nothing troubles my tribbles quite like a blurt of technobabble:

The temporal surge we detected was caused by an explosion of a microscopic singularity passing through this solar system. Somehow, the energy emitted by the singularity shifted the chroniton particles in our hull into a high state of temporal polarisation.

Now the good news, when watching Star Trek, is that you really don’t need to understand any of that to gain enjoyment from the episode. The writers make sure the characters appear to understand it, and the Federation once again, save the day.

But what about technobabble we do have to understand?

Docker Bind Mounts.

Well, in this video we run our tricorder over bind mounts and figure out just what the heck these things are.

The good news?

Beyond the name they are surprisingly straightforward.

Set tachyon cannons to maximum dispersion!

#3. [Part 2] – Docker Volumes – Volumes

Here’s the unusual thing:

Docker bind mounts sounds complicated, but as we saw in the previous video, they really aren’t.

Docker volumes, on the other hand, sound quite straightforward.

But they are more complicated.

Docker’s Volumes are the future of the way we work with data in Docker.

Therefore, understanding Volumes is a very useful skill to have.

Fortunately, even though Volumes are more involved than bind mounts, by watching the previous two videos you have all the pre-requisite information required to grasp this concept.

In this video we work through a bunch of examples to ensure the fundamentals are in place. Volumes will feature heavily throughout the rest of our dealings with Docker, so be sure to understand this section before moving on.

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

Chris

How can I become a Technical Evangelist?

Earlier this week I had a really interesting conversation with Thijs Feryn. You may know Thijs already, and you may have seen him / heard him speak at one of 171 different conference talks across 14 countries.

I was lucky enough to catch Thijs speak at PHP North West 2015. Incidentally, the 10th Anniversary of PHP North West occurs at the end of this month – shout up if you’re going, it would be great to meet up.

I’ve met a couple of Technical Evangelists in my time, and I have found them to be amongst the smartest people I know. And yet I’ve never though to ask them how they got that job role / title. Until now:

What I wasn’t quite expecting was the depth and quality of his response.

Thijs recorded a really interesting video / vlog answering the question:

The video itself was enough to make me sit up and take notice, but the accompanying blog post included even more depth and avenues to explore.

I shared this link out with a few devs I know earlier this week. There was a complete division that caught me off guard.

The responses I got were either:

Hey, cool, thanks for sharing, this looks interesting

or

WTF is a technical evangelist?!

Ok, so I paraphrase, but that’s the gist.

Now, I’m no expert. I can only share my view-point from the outside looking in. But here’s what I think when I hear “technical evangelist”:

A technical evangelist is a mixture of pre-sales / sales, consultant, and conference speaker.

As a technical evangelist you would be an expert in a particular field, or technology.

This typically means keeping a blog about your specialist subject, and regularly creating new content in that subject area. It helps to create very high quality / useful content as the perception that site visitors have of you both during, and after the site visit will influence who they choose when things go wrong / get complicated.

In Thijs’s case this also involves becoming a published author as a direct result of evangalising a particular tech (Varnish). Thijs goes into how this book came about and how this is different to the usual approach to writing a book.

The short version of this is best viewed from a real world problem I experienced in a previous role:

  1. My employer bought some expensive hardware
  2. I was out of my depth, so started having to learn both on the job, and in my own time
  3. Google searches led me to the same blog, over and over
  4. I went to a conference in Manchester where I met said blogger after watching him do a talk
  5. I went back to the office and told my boss about “this guy” who knew all about our problem space
  6. A few phone calls were made, and “this guy” and others from the same organisation came in to do salesy / consultancy type stuff
  7. Lots of money changed hands

I think the details here may be a little hazy as this was ~10 years ago.

Ultimately though, the company I was with at the time would never have chosen to start working with that consultant at random.

By establishing himself as a subject matter expert, backed up with conference talks and a decent blog, a lot of trust was pre-established.

From here the sell is a lot softer. In fact, I ended up as the internal advocate for this particular chap, which in turn opened the door for his company.

I can imagine, because it involves sales / money, that this whole thing sounds quite sleazy.

I would argue against this.

Sure, money changes hands. And in the context of big business, that can be big money.

But on a personal level I got to work with a subject matter expert who was both incredibly helpful, and still in my mind the very best person for the job.

Anyway, that’s why I find the whole “technical evangelist” role so fascinating. It encompasses so many of the facets of “the business of software” (or hardware) that I find so interesting.

The reason I wanted to share this with you – beyond the unexpected response from Thijs – is that there are opportunities out there that you very likely will not see advertised on the job’s boards.

To get these roles requires you to push yourself outside your comfort zone and think beyond coding.

I genuinely found this whole exchange fascinating. I’d urge you to read Thijs’s blog post, and watch his video. We spend our 37+ hours a week at work, we might as well do something super enjoyable – and being paid to evangelise a tech you personally love sounds like a brilliant role to me.

Here are some other posts on “what is a technical evangalist”, as maybe I didn’t do this justice:

Site Update

I said last week I hoped to get out some “beta” invites.

I’m almost there.

Just the 23 remaining tickets in my GitLab issues register 🙂

What’s crazy about this whole process is all I am doing at this stage is reproducing exactly what I already have. In other words, everything you see on CodeReviewVideos.com at the moment will be how the new site looks and feels in the first phase of version 2.

Kinda nuts. It’s a lot of work for the same outcome 🙂

There is method to the madness though. There are some crucial fixes to some problems of my own making in the first version of the code.

There’s also a completely new member’s area – probably the most requested feature since Site Search.

On the subject of site search, I’m now using Elasticsearch whereas the existing implementation is just MySQL fulltext (aka meh).

I’m looking forward to getting the new code “out of the door” because it means I can get back to recording a lot of new content. And I have a ton of content I want to cover.

Instructor Update

Thank you to both respondents to my request for new instructors. This made my week last week 🙂

If you’d like to create tutorials / screencasts then please do get in touch (chris @ codereviewvideos.com) and I will tell you more.

There will be a set of new pages on the new site version that explains this process further.

The short version is simply:

If you’d like to share a screencast on any subject (front end, back end, devops, open source, WordPress, Magento, other) then you are more than welcome at CodeReviewVideos.

Aside from growing your own knowledge, and sharing that knowledge with others, there is a potential for earning a monthly recurring income.

You need not be the World’s best screencaster – sharing your knowledge is the most important part.

Video Update

This week saw three new videos added to the site.

1. How can I implement Sorting in a Symfony 3 JSON API?

This video is answering a question I received regarding Sorting in Symfony (in this case, a Symfony 3 JSON API) without relying on third party bundles, such as KNP Paginator Bundle.

We cover how to sort on one field, in both Ascending, and Descending order. To this we borrow an idea from Django Rest Framework.

Then we cover how to sort on multiple fields at the same time. We cover a few ways we might restrict down what fields can / cannot be sorted on.

And we finish up by discussing whether adding this logic to your code is worth it, when more full-featured plugins (such as the aforementioned KNP Paginator) already exist.

2. Docker Images vs Docker Containers

In this video we cover the differences, and similarities between Docker Images and Docker Containers.

The tl;dr version of this would be that Docker Images are very similar to Classes in object oriented programming.

Docker Containers are as though we new up an instance of that Class.

As with almost everything in Docker-land, you can dive a lot deeper than this if needed. However, for most day-to-day tasks you likely only care that you a) have the right Docker Image, and b) can create a Docker Container from that image.

By the end of this video you will have learned about the differences between Docker Images vs Docker Containers, and have had hands-on experience with both.

3. Elixir and Phoenix with Docker Tutorial

I’m indulging myself somewhat in this short video series on Elixir, Phoenix, and Docker.

Yes, Docker is featuring heavily on the site lately 🙂

In case you aren’t aware, Elixir is a functional programming language.

Phoenix is a web framework for the Elixir programming language.

And no, I am not abandoning Symfony or PHP 🙂

I am firmly in the camp of thinking that learning a new programming language is one of the very best ways to improve your programming knowledge.

In the case of learning Elixir I have greatly improved the way I think about the structure of my code, and how each method / function can often be bettered modelled as a series of transformations of data.

Elixir has some incredibly interesting patterns and paradigms that coming from a PHP-background have been very tricky to learn.

In this short course we will create an Elixir / Phoenix stack along with Postgres for our database, and Docker to manage our infrastructure. We will then spin up a typical JSON API with all the expected interactions:

  • GET
  • POST
  • PUT
  • PATCH
  • DELETE

This sounds like a lot of work, but if you’re anything like me, you will be amazed at how quickly this implementation can be achieved.

As ever thank you very much for reading, have a great weekend, and happy coding.

Chris

How I am using Docker with Symfony, nginx, and MySQL

Behind the scenes this week I have been continuing my work on the next major iteration of the CodeReviewVideos website.

I’ve split the site into two parts:

  • A Symfony 3 powered JSON API for the back-end.
  • React / Redux / Redux Saga for the front-end

It’s a stack that I really enjoy working with, and is all stuff I’ve covered here on the site before.

Progress has gone fairly well this week. As a developer I always expect to be further ahead than I actually am. Partly this is impatience, and partly because I am still not so good at estimating 🙂

By next week’s newsletter I am hoping to be able to share access to the “beta” (for want of a better word) with existing site subscribers.

Become An Instructor

I really want to make CodeReviewVideos as useful to you as possible.

There are likely dozens of topics you’d like to see covered that either I have not yet had chance to record videos for, or do not have any experience in.

Topics like Angular 2/4, Vue, WordPress, Magento… all the things that we as developers have to work with in our real-world, day-to-day jobs.

If you have ever wanted to start recording screencasts / tutorials then this may well be the perfect opportunity to do so, and earn some extra recurring income in the process.

If you’d like to know more then please send an email to chris@codereviewvideos.com.

Video Update

This week saw three new videos added to the site.

#1. How to add a Flash Message on Successful, or Failed Login

I got asked this question:

how can I “$this->addFlash” for login? Because now its working only with registration. How can I make it work with login? Check if signing in was successful/not successful?

There is a solution built into Symfony’s security bundle (think: Login form configuration) to make this fairly easy to accomplish.

There is just one small problem: lack of documentation / example.

I’m hoping to correct that with this video. Before going too much further, you may be wondering:

What are Flash Messages?

Flash messages in Symfony are simply one time messages – notifications, by another name – that are stored in the session and are removed as soon as they have been shown once.

If still unsure, I have a video called the Beginners Guide to Symfony Flash Messages. It’s free to watch.

Symfony 3.3 comes with some improvements to the way Flash messages work.

We cover how to add a Flash Message using the success_handler and failure_handler services. The tricky part is that these two services must behave a certain way, and this video covers one approach to this problem.

I’m always open to answering questions like this, so if you have any that you feel would be best answered by video then do please send them in.

#2.  [Demo] – Docker with Symfony, nginx, and MySQL

Docker.

It’s popular.

It’s good for the CV.

It’s also complicated.

In this video we take a look at a Dockerised environment in which the latest version of Symfony 3, an nginx webserver, and a MySQL database can be “spun-up” in next to no time.

The idea here is to take a look at what’s possible, rather than me saying: Hey, this is all you need to know.

I’ve planned out the Docker series and it’s going to be a few shorter series that can be watched independently, or all together.

There are a bunch of topics in Docker that you can initially skip over. Only as and when you have a need for either a more complex setup, or want to satisfy your curiosity do you need to delve any deeper.

This is good, in my opinion, as Docker itself is both broad and deep, and if we covered all the fundamentals upfront then you may be sound asleep by the end of the first few videos.

Because seeing code is fun, here’s the docker-compose.yml file that this video covers:

# docker-compose.yml

version: '2'

services:

    db:
        image: mysql:5.7.17
        env_file:
          - ./.env
        volumes:
          - "./volumes/mysql/dev:/var/lib/mysql"
        networks:
          crv_dev_network:
            aliases:
              - mysql

    nginx:
        image: codereviewvideos/nginx.dev
        ports:
          - "81:80"
        restart: always
        volumes:
          - "./volumes/nginx/logs:/var/log/nginx/"
        volumes_from:
            - php
        networks:
          crv_dev_network:
            aliases:
              - nginx

    php:
        image: codereviewvideos/www.dev
        restart: always
        env_file:
          - ./.env
        volumes:
          - "./volumes/php/app/cache:/var/www/dev/app/cache/:rw"
          - "./volumes/php/app/logs:/var/www/dev/app/logs/:rw"
          - "./volumes/.composer:/var/www/.composer"
          - "./app:/var/www/dev"
        networks:
          crv_dev_network:
            aliases:
              - php

networks:
  crv_dev_network:
    driver: bridge

You can watch the video here, and then hit the Repo over on GitHub.

We will cover everything in this repo piece by piece, building more than just a Symfony stack in the process.

#3. Linux Permissions 101

Oh my, this sounds dull.

Yes, I hear you.

There are parts of Development that sound sexy and fun (e.g. Docker, the latest JS framework, real-time mobile apps, etc), and then there are the dry and boring sounding topics that unfortunately, you really need to know.

I realise permissions aren’t much fun.

That’s why I have compressed the essential knowledge down into a 4 minute long video.

If you have ever seen something like this:

➜  ~ ls -la Development/docker/nginx

total 24
drwxrwxr-x  4 www-data www-data 4096 Apr  3 19:43 .
drwxrwxr-x 74 chris    chris    4096 Aug 17 20:15 ..
drwxrwxr-x  2 www-data www-data 4096 Apr  3 19:37 conf.d
-rwxrwxr-x  1 www-data www-data  137 Apr 18 20:51 Dockerfile
-rwxrwxr-x  1 www-data www-data   13 Apr  3 19:42 .dockerignore
drwxrwxr-x  8 www-data www-data 4096 Aug 19 12:05 .git

And you have wondered just what the heck most of this means then this video will see you right.

To work with Docker it is essential you understand just a small amount of this output. Most every problem I have had with Docker has been related to permissions. Trust me on this, if you want to use Docker then you need to know this stuff.

And the good news is that it’s really not that bad. And it’s useful beyond working with Docker too. Win win!

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

Chris

 

Here’s How I Learn – The Two And Ten Method

I had an interesting discussion this week with a developer who is currently working mainly with WordPress websites, and wanted to know how get started with “the new stuff”.

The new stuff this developer was referring too would be things like React, VueJS, maybe Angular, but more generally JavaScript’s ES6 (and beyond), and things of that nature.

It’s a good question, and one I have been thinking about ever since.

As you may recall from previous emails / blog posts, I spent quite a while over the past few months working on a WordPress plugin myself. As it turns out, that plugin is now very unlikely to ever get released. That’s sadly very unfortunate, but there’s no point dwelling on that.

One of the cool things I tried with that plugin was to use React inside WordPress. It worked quite well, certainly better than I expected.

Why I mention this is because if you really want to get stuck in to using React (or other libraries), you can do so, even if you are working in the confines of another project (WordPress, Drupal, Magento, etc).

Ok, but maybe this is not so helpful. I was working on a plugin of my own creation, with no boss and/or client to satisfy. This allowed me to satisfy my own curiosity (can I even do this?) at the expense of a few days of prototyping and experimentation.

Typically that’s not how most paid software development goes.

Let’s change this up then, and view the problem from the perspective of a developer working in one of the many, many “full service agencies” we have here in the UK. Typically these agency businesses cover a wide range of activities:

  • Social Media management
  • Pay Per Click advertising
  • Logos and branding
  • Search engine optimisation
  • Web development

I’m going to generalise here and say that the vast majority of the web development projects these companies undertake involve WordPress, the lovable blog platform that’s also a shop, a membership site, a boat, a car, and whatever else its been hacked into these days.

The problem we hit upon here is that if your day job is to churn out WordPress website after WordPress website, there is an imposed ceiling on your learning. By which I mean that whilst initially the problems you will be tasked with will feel challenging, after you’re on your 10th build, adding yet another jQuery slider is going to be very run-of-the-mill.

And this becomes a major problem.

Firstly – jQuery. WordPress is full of jQuery, and whilst it is a really useful library that’s good to know, and to be able to use, it’s not going to set your CV on fire.

Secondly – WordPress. It gets a(n unfair) ripping even from the PHP community. When used for the right things, WordPress can be a great platform. However, without an experienced mentor to guide you, it’s incredibly easy to write sloppy / confusing / pain-inducing code.

Put together, these two skills can likely see you through for the next 3-5 years without any issue. If you have no desire to improve further than being yet another commodity developer taking up a seat in an agency then feel free to stop reading here.

Still reading?

Good.

The question now becomes:

How do I get from my day job doing WordPress, to coding in React / modern JavaScript?

This Is The Modern Way

I’m going to let you in on a little secret:

Your boss doesn’t want you to improve.

If you improve too much you will either want promotion, or worse, you will leave and take your skills elsewhere.

Either way, your current employer loses out.

Of course, your employer wants you to improve a little. They don’t want you spending a day trying to get that jQuery slider to work. They would rather it took you twenty minutes so you can get on to adding another jQuery slider to your next project.

As a side note here this isn’t something that’s unique to software developers / agencies. I have seen this pattern repeat in every company I’ve worked with.

I used to work with a lad who would sit and moan about how the organisation never trained him. He wanted to become a senior member of the team – if only the pesky business would pay for him to go on a week-long training course. I remember him sitting and moaning about this for years (I worked there for 9 years), all the while his more pro-active peers steadily climbed the corporate ladder around him.

Here’s the thing though:

A week long training course won’t really help you.

An exam certificate won’t help much either.

All that matters is experience.

And the best way to get experience is to take control of your own learning.

Now here’s the really cool part:

You can learn whatever you like.

You don’t need to wait for a project to come along in your day job to start hacking on React. In all likelihood that day will never come, anyway.

What about other cool technologies you’ve heard about? Docker, for example. Will your boss ever come over to your desk and say, hey, let’s try using Docker for this project!

Of course not. The chances are your boss hasn’t even heard of Docker.

You know who has heard of React, and Docker? The team at your next job.

Ok, so here’s my approach which I call two-and-ten:

#1 – Get On The Jobs Boards

Don’t be a newb and browse jobs boards at your work PC.

Instead, browse either on your phone (at dinner time) or at home.

Search for skills you would like to learn, and see what you could potentially earn if you had experience in this skill.

What I would suggest is looking for both permanent, and contract roles, and assess the pay.

There’s no point devoting a bunch of time (potentially years) to learning something that doesn’t pay that well. I know, I know, do what you love, and all that, but if you have a choice between tech A and tech B, and tech B pays £xx,xxx more per year, why would you learn tech A?

What you will find in doing this exercise is that there’s a bunch of related skills that frequently come up on the job’s listings for any particular skill set. For example, if you look for Docker roles, you will likely frequently see requests for experience in Amazon’s AWS, Puppet, Ansible, and more.

Spend some time here. This will form the core of the skills you will be learning.

Write these skills down, along with the pay rates. This will be a strong motivator to keep learning, when you inevitably hit the tough spots.

#2 – The 10 Step Plan

It may be that you really want to learn React.

Well, the good news is that we’re still early in the curve. Even if it takes you a year to gain proficiency, there will likely be more jobs then than now.

Take this into consideration when choosing what you are learning. Try not to back the 3-legged horse 🙂

Once you know what it is you want to learn (e.g. React) then what I do next is plan out 10 small projects that take me from “what the heck is this?” to “ok, I have some idea how to do this!”.

Here’s how I would break down learning React:

1. Read through, and follow along with the official Facebook tutorial.

This will give you the basic knowledge of what React is, and what it can do for you.

2. Try Create React App

This is pretty much the defacto way to kick start a React project these days, and means you completely avoid having to learn about Webpack, or Babel.

3. Make a Very Simple One Page Web App

Using the skills you learned in the previous step, now try to create a one page website / web app with a HTML table and some fake data.

At this point you can still easily Google for answers, but without a written tutorial to guide you, you have to start thinking for yourself. It’s hard, and it may take you a few evenings of work, but now you’re learning.

4. Make a Multi Page Web App

You now know how to make a one page web app. What about if we need more than a single page? How to do we navigate between these pages?

Each page doesn’t need to do anything interesting at this point. It’s just about pushing ourselves further.

Try to do this without using a third party library.

5. Make a Simple Form

Forms are almost unavoidable in a modern web app. Sooner or later you will need to accept user data.

Add a single text input , along with a submit button. When data is submitted, have it log out to your browser’s developer console.

6. Make a More Complex Form

There’s more to forms that text inputs, unfortunately.

Practice adding a dropdown select  box, and for extra points, make the list of options dynamic.

At this point you may wish to try my Symfony 3 with ReactJS and Angular course. You can skip the Angular part without any issue.

7. Get data from an API

We have no database setup. We could get stuck here and start worrying about how to set up a back end, what language that should be in, how it would even work…

But we don’t need to do any of this. Set up a fake REST API using the JSON Server library.

Then, use React to GET  data from that API.

This is a super common thing you will be doing with React, so it pays to learn how to do this.

True story: I have been in interview situations where I have been expected to write a CRUD-style app in this fashion.

8. Update An API

Most of the time you won’t just be reading (GET ) from an API. You will need to add new, or update existing data, too.

Good news, we can use everything we learned in #7, and expand on our knowledge here.

9. Talk To A Real API

It’s cool hitting the JSON Server from #7, and #8, but this cannot replace working with a real life API.

Fortunately there are tons of publicly available APIs for us to play with.

Find one that seems interesting and code up a search box to send in queries, and another page to display the results.

For extra credit, choose an API that requires authentication. Feel free to use a third party library here, as it’s very unlikely you’d write this part by yourself in real life.

10. Go Crazy

You surely can’t be around React for too long without hearing about Redux, Reselect, Redux Saga, React Router, MobX, Redux Form, React Drag and Drop, and who knows how many more.

You’re now at a point where tackling my React, Redux, and Redux Saga With Symfony 3 suddenly isn’t so daunting.

There’s still a lot left to learn, but now you know the basics and can start building up your knowledge further.

The good news here is that you’re further than most people who say they want to learn React will ever get.

I use this same process over and over, every time I want to learn something new. Start simple and take baby steps. Just because they are baby steps doesn’t mean you won’t stumble and fall – watch how many times a toddler falls on their backsides before they finally master taking just a few short steps.

It’s easy to forget how important it is to be persistent. 

The key thing here is we are no longer reliant on our boss / day-job to structure what it is that we learn.

We get to work on cool and interesting things (such as React, and ES6 / ES2017) at our own pace, and without pressures of “when’s it done!?”.

Each of these steps can be tackled in small bursts.

I completely understand that after a day of working on WordPress you may have no desire to get back on a computer. That’s fine. You don’t need to do this every single evening.

The idea behind this approach is to have small goals which are well defined, and don’t need the full spit-and-polish of a production implementation. They can be super rough, no tests, just fun and perfect for self-improvement.

Video Update

This week saw three new videos added to the site in new short series:

Testing DateTime In PHP

We know we should be testing our applications, but sometimes testing is really hard. One such time is when we need to test instances of PHP’s \DateTime, or more recently, \DateTimeImmutable.

The primary problem with dates and times is that they constantly and unceasingly march ever forwards.

This presents a huge problem in our tests, where we need predictability.

In this series we cover three ways to address this problem.

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

 

Chris

CodeReviewVideos Goes Hollywood

Hollywood loves a good sequel. Just this year alone we’ve had:

  • XXX: The Return of Xander Cage
  • Resident Evil: The Final Chapter
  • Fifty Shades Darker
  • Despicable Me 3
  • T2: Trainspotting
  • Alien: Convenant
  • Pirates of the Caribbean: Is anyone still watching?

There’s method to the apparent madness, of course. Sequels are made when some semblance of success was seen with the original.

And when your budget is in the hundreds of millions, the people stumping up these vast amounts want themselves a significant return on that investment. It makes sense to play the percentages.

The games industry follows suit, and again just a short round up of 2017’s releases include:

  • WWE 2K17
  • Zelda: Breath of the Wild
  • Warhammer 40k: Dawn of War 3
  • Mario Kart 8
  • Final Fantasy 49.2: Yet Another Merciless Cash-in

With all this talk of sequels I figured it’s about time CodeReviewVideos got in on the action.

That’s right…

It’s time for a course on SQL 🙂

Woo!

Yeah, yeah, I know, only granddads like me still say it as “Sequel”. All the cool kids just say the letters – S-Q-L. But that would have ruined an enjoyable introduction to this post.

What I’ve found is that I’m getting many questions from users of Doctrine where, when probing a little deeper, I’m finding the basics of SQL are somewhat of a mystery.

I liken this to my recent forays into learning the Elixir language, and the Phoenix framework. I know, I know, I never shut up about Elixir / Phoenix, but please hear me out:

It’s super easy for me to forget what it’s like to experience Symfony, or Doctrine for the first time. I’ve been working with the Symfony ecosystem now for about four years and – thankfully – I’m largely over that frustrating phase of figuring it all out.

When I swap to a new language or framework (or both), I am rudely dumped back into the position. And it is rarely enjoyable.

Regardless of language / framework, there are some common problems we need to address in our day to day lives as developers. A big one of these problem areas is working with the database.

Now, the good news is that whether you’re working with MySQL (or a derivative), Postgres, or MSSQL (and likely Oracle but I have no first hand experience here), the vast majority of SQL is the same.

What this means is that regardless of learning Laravel, or Symfony, or Django, or Rails, if you know the basics of SQL you have a head start on learning your framework’s method of DB interaction.

Before I started using Symfony I had years of experience with SQL. Largely raw SQL as it happened. Stuff like:

SELECT * FROM blah

and

UPDATE widget
SET name='new name'
WHERE id=20

and

SELECT col1,col2
FROM table_whatever
LEFT JOIN
  different_table
    ON table_whatever.id = different_table.something

Even so, when I saw DQL I didn’t feel entirely confident.

Even worse, we don’t just have DQL. We have DQL, the Query Builder, and if need arises, we can drop down the Native SQL.

So here’s what we are going to do:

We’re going to start with the basics.

We’re going to spin up a database server, create ourselves a user, and a table, and we’re going to put some data in to that table.

Then we will learn how to do some basic queries.

SQL is really quite repetitive, which is a good thing as there aren’t that many things to learn individually. It’s really just about stacking a few concepts together to manipulate our data into a shape we want / need.

We will learn how to create, read, update and delete data directly using SQL.

We will then take what we have learned and map this – as close as possible – to the way Doctrine will expect us to work.

From here we can start getting a little more advanced. Updating our data, and deleting it too.

Then we will move on to situations where we have related data in two or more tables, and we want to bring everything that is related together in one query.

Joins, in other words.

Again, first we will look at Joins without Doctrine, and then we will figure out Joins with Doctrine.

If you have any queries (ho ho) or questions regarding SQL that you’d like to see covered in this series then please hit reply and let me know, and I will do my very best to cover them for you.

Video Update

This week saw three new videos added to the site.

https://codereviewvideos.com/course/let-s-build-a-wallpaper-website-in-symfony-3/video/test-driven-wallpaper-delete-part-1

We’ve done everything we need to do except cover a test-driven approach to Deleting Wallpapers. Let’s fix that up in this, and the next video.

https://codereviewvideos.com/course/let-s-build-a-wallpaper-website-in-symfony-3/video/test-driven-wallpaper-delete-part-2

We are continuing with our test-driven (PhpSpec) approach to Deleting an existing uploaded Wallpaper, and making sure the associated image gets deleted too.

https://codereviewvideos.com/course/let-s-build-a-wallpaper-website-in-symfony-3/video/easyadminbundle-login-form-tutorial

Learn how to quickly and easily add a secured Login Form to your Symfony 3 EasyAdminBundle admin back end setup with this free tutorial

There are a couple of remaining parts of this project that need addressing. Both of these will involve refactoring and clean up, primarily around the service definitions. Mostly though, for phase one of our Wallpaper website, this is a wrap.

Things will get a little more advanced as we move into Phase two, but this won’t be for a few weeks time as there’s an accumulation of videos / topics that need to be covered in the mean time.

Anyway, enough from me. As ever, thank you very much for reading. I hope you have a happy weekend and happy coding 🙂

Chris