Code Review Videos

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

Conditional SerializerGroup in FOSRESTBundle

I needed to conditionally add an entry to the list of active Serializer Group entries in a FOSRESTBundle controller action.

Here’s my attempt:

    /**
     * Get a single Widget.
     *
     * @Annotations\Get(path="/widget/{id}")
     *
     * @ApiDoc(
     *   output = "AppBundle\Entity\Widget",
     *   statusCodes = {
     *     200 = "Returned when successful",
     *     404 = "Returned when not found"
     *   }
     * )
     *
     * @param int         $id    the widget slug
     *
     * @Annotations\View(serializerGroups={
     *     "Default",
     *     "timestamps",
     *     "widgets_all",
     *     "feature_summary",
     *     "sprocket_summary"
     * })
     *
     * @return View
     */
    public function getAction(int $id, WidgetRepository $widgetRepository)
    {
        $widget = $widgetRepository->findOneById($id);

        if ($widget === null) {
            return new View(null, Response::HTTP_NOT_FOUND);
        }

        $view = $this->view($widget, Response::HTTP_OK);

        if ($this->isGranted(WidgetVoter::VIEW, $widget->getSprocket())) {
            $view->getContext()->addGroup('sprocket_all');
        }

        return $view;
    }

The idea behind this code is to that a Widget should show all of its information to all users.

It should show a summary of related features to all users.

It should show a summary of the related sprocket (one-to-one) to all users.

However, if you are logged in, you should see all the sprocket information, not just a summary.

It seems to work quite well in my use case. Gotta love them sprockets!

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 🙂

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

This Is What My Brother Found When Trying Symfony

My brother recently tried to get up and running with Symfony. His theory was that learning Symfony (out of all the available PHP frameworks) seemed like a good idea, being that he could ask me questions as and when he got stuck.

I anticipated that he would have problems with the “typical” problem areas:

Security
Forms
Database interaction

And maybe, given it is his first time using the MVC pattern, some of the concepts around that area, too.

What I didn’t anticipate was that he couldn’t even get started.

He experienced so many issues with installing Symfony, that after a couple of hours effort – with essentially nothing to show for it – he gave up.

I could sense his frustration.

Here’s a guy who spends all day working with PHP (mainly WordPress I believe), and after 8+ hours at his desk, he comes home, grabs a bite to eat, and tries to improve his dev chops by learning about Symfony.

For most of us, time is extremely limited, and spending two hours sat at home after doing 8 or more at your desk is a pretty big ask.

To come away with nothing (except a bad experience) is, understandably, enough to put him off.

What follows may appear heretical:

I suggested he try Laravel.

The next evening he did, and was up and running in less than ten minutes.

This got me to wondering just how many others are suffering from a similar fate?

I am well aware that Symfony has a steep learning curve. Laravel does too, if you are brand new to modern PHP practices.

What I hadn’t factored in was just how difficult it is to get the “hello, world” of Symfony up and running.

Coincidentally, around the same time I got an email from a site member (thank you Parminder) stating the following:

Please note that I am not a php developer and I haven’t dabbled at all with it beyond setting up the server to work with the react/redux/sagas project on your site. I think it would be useful to include instructions in the intro to the course on setting up the server for someone who is not familiar with Symfony/backend and just wants to focus on the React/Redux material – this would probably help with course uptake I think.

And in response to my reply, Parminder also shared the following:

It did take me a while to set up the Symfony server for the course on my mac and it no doubt is a barrier for people taking up your course, which is a shame because your material is very good.

Ok, so after I had told Mr Worf to stand down from Red Alert, I started to give this problem some serious thought.

Firstly, up until very recently I had not envisaged anyone who isn’t a PHP developer would join the site.

I’ve been proven wrong on this point.

Secondly, I have seemingly forgotten to cover a fundamental part of working with Symfony – getting set up.

I’m going to remedy this with a forthcoming video series. I will try and cover set up from the three major operating system variants – Windows, Mac, and Linux.

I will offer some suggestions as to how I’ve worked, and touch upon Vagrant, Ansible, and Docker.

Another really good suggestion that I’ve had from Parminder is to spin up a standalone server which none-PHP devs, or those who do not wish to spend the time doing all the setup themselves, can access my server instead. This would likely be on a 24 hour cronjob to reset the DB, or similar. This is something I will implement moving forwards.

It pains me that Symfony is potentially losing new devs at the very top of the funnel. There’s so much good stuff to be had from using the Symfony framework. I’m not just talking about developer productivity, but the wider benefits like:

a well paying job
an enjoyable and (generally) intuitive stack to work from
a community filled with incredibly smart and friendly folk

I’ve said before that learning Symfony has changed my life (and yes, for the better :)), and it’s part of my mission to share that same joy with you.

I’d love to hear your experiences of what it was like getting started with Symfony.

Was there a specific issue you hit upon?

Has this process improved as you’ve used Symfony more and more, or is the pain still there?

Please hit reply and let me know.

Video Update

This week saw three new videos added to the site.

We are coming to the end of the first phase of the Wallpaper Website.

https://codereviewvideos.com/course/let-s-build-a-wallpaper-website-in-symfony-3/video/doing-the-little-before-the-big

Firstly we start by cleaning up our project.

Swapping and changing between branches in order to see how to write code with and without tests starts off fairly easy, but as the underlying design diverges, the setup (fixtures etc) need altering in differing ways for both branches.

There’s other stuff to cover here, too, such as the naming of files (and associated tests). It sounds almost trivial, but I’m sure you’ve experienced occasions when writing code where the names of things has started to feel… not quite right 🙂

Housekeeping is an important, if underappreciated aspect of the lives of us as developers.

https://codereviewvideos.com/course/let-s-build-a-wallpaper-website-in-symfony-3/video/tested-image-preview-sort-of

In the un-tested approach we added in a nice little preview snippet which allowed us to see our existing uploaded wallpaper image when going to the Update screen.

We’re going to add the same functionality into our tested version, but we won’t be able to directly test the template. Is this a problem?

https://codereviewvideos.com/course/let-s-build-a-wallpaper-website-in-symfony-3/video/finishing-up-with-a-tested-wallpaper-update

Finally we wrap up the test-driven approach to Wallpaper Updates. We cover not just the “happy path”, but two potential sources of bugs in our form setup.

This is really the major benefit of writing tests, as far as I am concerned. They make you think about the bad times as much as the good. It sounds very pessimistic, but 80% of the headaches I have as a developer stem from having not given enough thoughtful consideration to what might happen if things don’t go according to plan.

All we have left to do now is add in a tested approach to Deleting wallpapers (and their associated uploaded image files), and adding a little security. After all, we don’t want just any Tom, Dick, or Harry accessing our Admin panel.

That just about wraps up this week’s update. Thank you very much for reading, and I hope you have a great weekend.

Until next week, happy coding,

Chris

Software Development Is Not Beginner Friendly

As we are coming to the end of the first part of the Wallpaper Website tutorial series, I wanted to quickly reflect on a bit of feedback I’ve had regarding these videos.

The gist of this feedback was that I had miss-sold the course as being “beginner friendly”, when in fact, it has been quite a tricky course.

Here’s my view point, and as ever, feel free to disagree:

Software Development is hard.

There are two approaches I could take:

Show you abstract examples where I cover concepts on an individual basis.
Show you a complete, working example and all the things that getting to a “working” state entail.

My life would be easier if I opted for #1.

However, in my opinion, I would be misleading you if that’s all I showed you.

I’ve been writing software for over 15 years now, and I still regularly underestimate just how much effort is required to go from the idea phase through to “phew, it’s finally online” phase.

And as I’m sure you know, even once it’s online (or launched), it’s not done. Far from it. If anything, that’s where the real work actually begins.

Working in software development in 2017 is hard. There are a ton of things to cover. This series has been about the more traditional approach – using Symfony (or PHP) for everything, front end and back end.

In reality, and as we push further into the second and third parts of this series, to become the most employable and to stand out from being “just another dev” you will need to know more than just Symfony (or PHP). You almost inevitably will need to be decent at JavaScript, too.

Does this make the series harder? Yes, unfortunately.

Is this still stuff a beginner needs to know? In my opinion, yes.

There’s no point in just showing you what I consider the old school approach. At least, not unless all you ever want to do is build old school style websites.

My guess is that you want to make websites – or web-based applications – like those that you typically interact with in 2017.

Can PHP – and more specifically, Symfony – get you to this point?

Yes. But only half of the way there.

The other half needs to be done in JavaScript.

In other words, Symfony for your back end, and JavaScript for the front end.

Which brings me back to the original bit of feedback that this course is not beginner friendly.

I would argue that the industry is no longer beginner friendly.

There is an immense learning curve to simply getting started.

Fortunately, once you are over the initial hump, things do get a bit easier.

This isn’t a problem unique to software development. Many industries expect you to have a very broad and general level of knowledge before specialising in a particular area.

That’s my opinion on the subject. As ever, please do feel free to hit reply and let me know yours. I’m not saying I’m always right by any means, and I am not averse to having my view points challenged 🙂

Follow Up From Last Week

Last week I posed a couple of questions in my “Would you use Symfony for SaaS?” post:

How many other developers are using Symfony for SaaS, or SaaS-like services?
Is Stripe / payment integration something that many other devs want or need tutorial content on?

Firstly, thank you to everyone who replied. I really appreciate you taking the time to respond.

I have learned that the majority of you are not using Symfony to build your own SaaS, or SaaS-like service.

This is useful to me as it helps shape the content I aim to produce.

Even though most of you are not doing SaaS related stuff, the payment integration video idea does seem popular.

As such, I have added a payment integration course to the ToDo list. This will cover not just Stripe but also Braintree (aka PayPal), and all the fun that supporting multiple providers entails.

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/adding-an-image-preview-on-edit

As mentioned earlier in this series, there is a way to integrate with VichUploaderBundle when working with EasyAdminBundle.

In doing so, one of the nice ‘bonus’ features is the image preview when viewing an existing entity with an attached image file.

In this video we look at a way to recreate this in our own implementation. It’s easier than you might think, and gives us a good opportunity to explore some of the less frequently used parts of Symfony’s form component.

https://codereviewvideos.com/course/let-s-build-a-wallpaper-website-in-symfony-3/video/delete-should-remove-the-wallpaper-image-file

One problem that’s been bothering me throughout this series is that when recording the videos I will do some uploading of images, and then delete the Wallpaper entity, but the image file I uploaded still remains on disk.

To fix this we can copy a process we’ve covered for both Create and Update – which is to say we can listen for a different Doctrine event, that of preRemove.

As we might be changing over to use a different storage mechanism in the longer term (think: Amazon S3, not storing everything on the server’s local hard disk), we also need to abstract away exactly how an image file is deleted.

We will no doubt revisit this (or a variation of this) during our test-driven approach.

https://codereviewvideos.com/course/let-s-build-a-wallpaper-website-in-symfony-3/video/getting-started-testing-wallpaper-updates

Speaking of tests, in this first video of the final part of this series, we are switching back to our test-driven approach and beginning the re-implementation of our Wallpaper Update and Delete features.

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

Chris