We’re apparently in for a lovely weekend of sunshine here in the UK. Perfect weather for sitting indoors coding 🙂
It’s been a busy week for me. I’ve had a long stint of travel, followed by busy days on a contract. In the evenings I’ve been fighting GitLab CI, which seems to have gone haywire. Builds are now taking hours to finish. I’ve unfortunately still not resolved this. There’s always some fun challenge to tackle.
On the plus side, thanks to the travel I did managed to see the Flying Scotsman here in Preston earlier this week:
Ok, enough ramble, on with the show…
Over the last 4+ years of creating content for CodeReviewVideos.com I’ve tried a whole bunch of different approaches. I’m always trying to optimise my process and make things that touch more efficient, with the ultimate aim of delivering the most interesting and useful software development tutorials for you.
A number of people have asked why I “drip” out content. Typically, at least until the start of this year, I would release three videos a week: Monday, Wednesday, and Friday.
This approach worked well for me.
But, I got those emails frequently enough, asking why I didn’t either:
- Release more videos, or;
- Upload loads at once, rather than a few at a time
I had a definitive answer to the first question:
I can typically only get three videos done per week. Each video takes a lot of effort, from planning, to creating the initial code, to writing up that process, then recording, editing, uploading, and finally publishing. On average, for any minute you see on screen, it’s taken me about ~30 minutes to create.
The second question, however, I wasn’t sure on. The only way to find out would be to test the system.
As such, at the start of this year I decided I would switch to releasing blocks of content – an entire course at once, when it was done.
There’s a bunch of reasons why I don’t think this approach has worked. Probably the most disappointing for me, personally, is having had a number of subscribers cancel with feedback that I appeared to have abandoned the site. Heartbreaking.
Rather than dwell on this as a negative, I choose to take it as an experiment that didn’t work out. I’ve learned some lessons, and I know – more definitively, rather than just “gut feel” – that this is not the right process, for me.
As such, I have, in recent weeks, switched back to regular video updates. From now on, the previous approach of three videos per week will return.
Something I’m considering at the moment is livestreaming things that I am working on. If you’ve ever watched Twitch, you’ll know the sort of thing I’m on about.
The main reason for this is to capture the thought process that I go through when writing code. I think this would be incredibly interesting to share. I do try to capture this when creating the more traditional content.
But even so, sometimes that exploratory stage holds big reasons as to why the code ended up as it did. This is much harder to cover in the traditional video approach.
For each of these livestreaming sessions I would record the screen as normal, along with the audio. I’m not sure how to capture chat as of yet, as the screen real estate is already extremely limited. I record at 1280×720, which is great for clarity of font etc, but severely limiting for real world dev. These things will need to be addressed.
This idea stemmed from this tweet:
I made a backlink checker in Symfony, Node, Elixir, and Go. After trying each project, I’ve come back to the original #Symfony project and am re-writing, full #tdd. The difference between prototype and this design is staggering. It’s one way to spend a Saturday evening. #PHP
— Code Review (@CodeReviewVids) June 9, 2018
There would also be no formal, written notes created for these videos. And each video would likely be ~1 hour long. I know this isn’t for everyone, but I’d be really grateful to hear your feedback on this idea.
This week saw three new videos added to the site:
One thing that I found initially confusing when working with the API Platform was in the creation of custom routes. In particular, in this video we address the issue of using a URI that differs from auto-generated route name / path that’s based off our underlying entity.
This is really useful, and I use this concept in every API Platform project I’ve created.
In this video we finish up the POST implementation for our API Platform setup.
The number of videos required to get a POST endpoint working is a little misleading. We could have done this much quicker, but the Behat tests “dogfood” our API, and as such are making use of the POST endpoint also.
This is all about killing multiple birds with a single stone.
A major selling point, for me, of the API Platform is the rapid application development potential.
As mentioned above, the POST videos make this look a lot less rapid than it really can be. We had to take a care of a lot of setup / boilerplate for our testing in the previous few videos. Now we can spread our wings a little, and leverage a lot of the benefits that the API Platform provides in getting a brilliant API up and running, fast.
In the next few videos we will continue on with GET ‘ting multiple resources in one API call, PUT for updating existing resources, and DELETE for, well, I’m sure you can figure that one out yourself.
Have a Great Weekend!
Ok, that about wraps it up from me this week.
If you haven’t yet done so, please do come and say hi on the forum. It’s early days on there, but the discussions I’ve been involved with so far have been good fun. Here’s to more of them 🙂
Until next time, have a great weekend, and happy coding.