Symfony 4 has caused me a few headaches this week. In between the usual site work, I’ve been tackling a noticeable up-tick in support requests regarding video content.
There are a number of reasons why this is, some of my own making.
Anyway, though I had planned to work on finishing each of the currently in-progress courses, I am instead switching to updating every existing Symfony related course on the site to use Symfony 4.
I’m honestly not sure how much work this will involve at this stage. I’m expecting it to take a few human days in total, which I unfortunately don’t have in one large block.
What this will mean is for each course I will pull the code from GitHub, and add a new branch, or branches, to enable support for Symfony 4.
I don’t expect, nor plan to have to update every video.
I do expect to have to record some new video content around updating some of the bigger projects.
I’m going to work on the courses based on the volume I’ve been receiving in support requests.
I’ll know and share more on this next week.
This week saw three new videos added to the site.
Backing stuff up is a real chore.
During development it’s not that big of a deal. Sure, if we accidentally destroy the DB it *might* be a pain, but it’s unlikely to cost us our jobs, or make national news (or, at least, hackernews).
Once we hit production however, backups are up there with the toppest of top priorities.
I guess we could do manual backups. It’s a good way to waste 30 minutes every day by following some regimented process.
A better way is to delegate to our robotic helper: the computer.
In this video we cover a basic but “good enough” (for me, at least) method of backing up pretty much anything, and keeping only the last X backups (where X may be 7 days for example).
We’ll cover how to write a backup script using Bash shell scripting, and how to automate running that script using a cronjob.
Most every application I work on involves the database in some way.
When starting a fresh application it’s fairly easy to remember how and why the database schema ended up the way it is.
Then, after chopping and changing between four other projects, I come back to this “small” project and I’ve forgotten everything about it. Including why one of the fields is inexplicably an integer when a boolean seems like it might have been a better choice.
Fortunately, if you’re using database migrations, you can easily check back through the Git logs and figure out just what was changing in the code when you made such an interesting schema change.
I once read, somewhere, that having database migrations is effectively like adding version control to your database. I’m not entirely convinced by this, but they are helpful, and have proved worthwhile for me over the last few years.
Whatever your opinion, database migrations are available to us right “out of the box” with Phoenix, so using them is a no-brainer.
In the previous video we covered how to tell the database about our changes, be it adding a new table, editing an existing table, adding or updating an index, and so on.
In order to work with that table we must write some Elixir code that represents that table.
This code is called a Schema.
In this video we cover how we can generate a Schema for any particular table, and what the generated code is doing for us, and why.
Once we have a Schema, in this case for our “Contact”, we can start adding new records to the database. And we will do just this by making use of the REPL.
There are some interesting extras included in this video, such as touching on the purpose of alias, working with dates and times, and our first encounter with Pattern Matching.
That’s a Wrap
Ok, that’s it from me this week.
Until next week, have a great weekend and happy coding.