Forem: Jamie

10 Lessons Learnt From the Last 2 Years in Podcasting

Jamie — Sat, 01 Aug 2020 12:37:19 +0000

This blog post was originally published at the RJJ Software blog. The original post (without gifs) can be found here

The cover image for this post is by CoWomen over at Unsplash

For those who don't know, I'm the host of The .NET Core Podcast. I'm also a "serial podcast producer" (in the words of my friend James Studdart), as I've started a number of them throughout the years. Some of them are about technology, some are about video games, some are about the business of writing software, and some are just fun to produce.

You can see a list of all the shows I’ve been involved in at my podchaser profile page - which includes this wonderful statistic:

Anyway, none of that is the reason why I wanted to write this blog post. I wanted to talk about the 10 things that I've learned from running a tech podcast for two years.

Number 1 - You're Playing The Long Game

Some podcasts can achieve instant success, and that's fantastic. Usually, these shows have a very specific niche, an engrossing host team, or a large team of folks behind them.

Unless you are lucky enough to have those things, then you're likely going to be playing the long game. This is because it will likely take time for your show to gain traction - and that's partially because there are so many other people out there creating shows on everything. Seriously, almost any topic you can think of has several established podcasts with engaged audiences and a legion of not so well established podcasts.

With that being said, you shouldn't let what I've said stop you from starting the podcast of your dreams. But you should know that it may take a while to gain traction.

Number 2 - Ignore the Stats at the Start

It's incredibly exciting to jump over to your podcast host's website and take a look at the numbers going up. I'm not going to lie that I used to do this daily. The problem with that is, that podcasts are an on-demand type of media: folks will listen whenever it suits them.

Because of this, you will have days where it feels like almost no one will be listening to your show. This is because of the very ad-hoc nature of podcast consumption. Imagine the situation: you only listen to your favourite show when you're driving to work, and you suddenly no longer need to drive to work - let's say that there's a public holiday. Well, you're not going to be listening to your favourite show.

And that's where Number 3 comes in:

Number 3 - There's no "Perfect Day" to Release

I've seen this question come up a lot, usually from folks just starting out or from folks reaching out to me to up their game. I'll tell you what I tell them:

There's no perfect day to release an episode of your show, just a day which is perfect for you.

Let's face it when we start a new project we go through a "Honeymoon phase" of sorts: we want to keep working on it as much as possible and get as much content out there for people to see and consume. The problem with that is that it's not sustainable.

Imagine that you get super excited about a podcast that you're creating and decide to release 4 episodes a week. That's fine right now because you've likely budgeted your time out to give you time to experiment. But what happens in 6 months, when you're suddenly moving to another state? What about 12 months, when the enthusiasm starts to wear thing? What if the unthinkable happens and you get ill? What if - and I hope it doesn't happen to you - you have some tragic news? Can you keep that release cadence up?

The only perfect release day which matters is the release day that you can fit into your schedule. If you can't fit it into your schedule, then it's not a perfect release day.

Number 4 - Automate All The Things

At the start of every episode of The .NET Core Podcast, I say:

let's sit back, open up a terminal, type in dotnet new podcast and let the show begin

with the sound of me typing the command dotnet new podcast into my terminal. The reason for this is because I do that when starting a new episode.

I have a small .NET application for scaffolding all of the files I need to create a new episode. It creates a markdown file for show notes, adds an entry into my calendar, sets up a planning document, and opens a new email in my email client.

And that's just the recording side of it.

I also have an automated deployment pipeline for releasing the episodes. Each episode is released at 12:30 (UK time) on Friday afternoons, and the website for the show is built on using the Hugo static site engine. so I have a GitHub action which rebuilds the site at midday (again, UK time), ahead of the release of that week's episode. My episodes are also set to auto-release at 12:30 and to link back to the show notes address.

So the pre-production is automated, and the release is automated. I just have to deal with production, editing, and post-production.

Number 5 - Know Your Tooling

This goes without saying, regardless of whether you are working with audio, crafting code, writing unit tests, or writing prose. Once you know your tooling, you'll be both more efficient and be able to do things you previously thought not possible.

For a lot of folks who are new to podcasting and working with audio, this will mean learning both the audio production and editing tools and learning about the physics of audio. But don't be put off by the fact that you have to learn something new, you can pick it up as you go along.

For some, this might mean heading over to Udemy (or some other video-based training site), grabbing a course on Audition, Garage Band, or similar, and sitting through several hours of someone talking you through the tooling. For others, this might mean recording something and figuring it out as they go.

Let me just say that both of those strategies are fine because we all learn differently. Picking it up as you go along is just as valid as learning everything ahead of time.

Number 6 - The "Anti-Umm" Thing

Don't waste your time with this. It will sound unnatural, and there will likely be imperceptible audio spikes which cause issues when bouncing/rendering the audio. Everyone can tell when you cut out some umms and errs, so just don't do it.

Plus, it takes a very long time to do (see Number 8)

Number 7 - You'll Get Better At It With Time

Unless you have years of experience doing podcast production under your belt, you're going to start with something good enough and get better with time.

What I mean by "good enough" is not that it will be bad in any way, shape, or form. I just mean that because you don't have the experience, you won't spot things that you could have done to make the quality better, the edit faster, or the post-production tighter.

It's the same with anything in life: you want to get good at swimming? Go out and swim a lot, as you approach that magical 10,000 hours of deliberate practice, you'll start seeing improvements.

So don't sweat it, if you start slow or look back on where you started and cringe.

Number 8 - It Takes Time

Unless you hire an editor

one of the services that RJJ offers is podcast editing

then you can expect to spend a lot of time editing. The rule of thumb that I throw around is:

for every 30 minutes of recorded audio, you're looking at 60 minutes of editing time at the very least

The emphasis here is the important part. When you start, you'll likely be slower because you might still be learning the tooling. You'll get faster as you get better, but it will still likely take about double the length of the recorded audio. This is because you'll likely start picking up other tips and techniques, meaning that you spend even more time getting everything edited together.

And that doesn't count the time you'll be spending planning episodes, writing them, reaching out to and scheduling guests, getting promotional pieces done, shouting up about it on social media sites, and answering listener feedback.

There's a reason why folks like Joe Rogan have a team of people around him. He turns up to the studio with a list of topics, sits down in front of the mic, starts talking when the audio engineer clears him, and leaves when the recording is done. His team handle everything else.

Number 9 - Have a Pre-Release Checklist

You've recorded the audio, edited it down, post-produced it, sourced a sponsor, added the ad-read, and even uploaded the mp3 file to be released. But have you done everything?

That's where a pre-release checklist comes in. This allows you to doublecheck that you've done everything. What if you release an episode which was meant to have some ad-copy in there, but it's somehow missing from the episode? Well, you're likely going to have a very upset sponsor calling you up as soon as they find out - and they'll find out as soon as the episode goes live.

This is where having a pre-release checklist is vital, and having a step on there with "listen to the episode in it's entirety before releasing". The emphasis here is super important. What if the bounce/render failed partway through? What if the audio suddenly becomes super loud at the halfway mark? You don't want your listeners or sponsors to have to report that to you.

Number 10 - Don't Release Until It's Approved

Part of the process for getting your podcast out there is telling Apple about it. It's a step which goes back to the iTunes days - it's since been renames Apple Music. Here's what you need to do:

Tell Apple Podcasts (used to be called iTunes) that your show exists
Wait for them to approve it
Wait for them to approve it
...
Wait for them to approve it
It will appear in Apple Podcasts

If your podcast isn't in Apple Podcasts, then the majority of people won't have a chance at hearing it. This is because the majority of the podcast aggregators pull their podcast feeds directly from Apple Podcasts - whether they should or not is up for debate.

So if your podcast isn't on there, then it won't be anywhere. And if you've ever released an app to the Apple App Store, you'll know that there's a period where the folks at Cupertino need to do some checking and vetting of your show. If you don't follow Apple's guidelines to the letter, then your show won't be accepted, and you'll have a bad time.

As such, it's worth waiting until your podcast has been accepted by Apple before you start the media campaigns. You don't want potential listeners to flock to their podcatchers (the term for podcast consumption apps) only to struggle to find your podcast because Apple denied the show.

Summary

Those are some of the things that I've picked up over the first two years of producing, hosting, editing, dogsboddying, and promoting The .NET Core Podcast. I have so much more advice to give, but I'd rather not keep you all day.

Are you involved in creating a podcast? I'd love to hear some of your top tips? If you're not involved in one, are you considering it? Let me know in the comments.

One last thing: I've put a course together on getting into podcasting. If you liked this article, and are considering getting into podcasting, or if you already have a podcast and are looking to up your game (as it were), then I'd recommend enrolling today.

Backups Backups Backups

Jamie — Wed, 19 Feb 2020 14:29:32 +0000

The cover image for this post is by Markus Spiske over on Unsplash

A Little History

Like many people who came of age in the 1990s, I hadn't taken backups seriously until I got to college.

side note: by "College" I mean in the UK sense. For friends who went through the American style of education, this means non-compulsory education which usually starts at the age of 16 and lasts for 2 years

It was while at college that I suffered my first big data loss.

I'd been working on an app, written in Assembler for a Flight 68K. To run the application, we had to visit the labs and:

Boot a device into DOS
Start the IDE
Load the source code from either hard drive or floppy disk

I was at college in the early 2000s

Build, deploy, and run the application

At some point between making changes on my Windows 2000 machine and loading it into the DOS-based IDE, the source code became corrupted. These days, I would know how to repair the source code

and not just by the use of git reset --hard origin/master or whatever your favourite way is for undoing any local changes

but back then I had no way of knowing how to fix the text files. I also wasn't using source control, because I hadn't been introduced to the topic yet - we were studying electronics.

This would happen again, several months later, with a short story that I was working on.

Those of you who have read my other articles will know that I'm not much of a writer, but there was a time when I wanted to try it out.

I had a short story, stored as a Word document, on a 64 MB

yes, MB

USB memory stick. That memory stick was attached to my keys and was quite bulky. Keys have a certain amount of weight, and USB ports are usually found on the front or back of a PC tower.

Over time, the connectors between the USB port and the board within the memory stick snapped. Meaning that I had no (cheap) way of rescuing the data from it.

In both of these real-world examples, there was no real money lost. There was also no reputational damage. And there was definitely no-one holding me to ransom.

But that could happen to you if you're not taking backups.

3-2-1

image by Joshua Golde over on Unsplash

I am in no way a backup and restoration expert, but the most basic thing that you'll need to understand is the 3-2-1 rule. The tl;dr is:

at least 3 copies of the data, stored on 2 different types of storage media, and one copy should be kept offsite

If you are using git (or some other distributed source control system), you are almost doing this already. You have (at least) 2 copies of the source code, and one is offsite. I've said "at least" because there might be others in the team who also have the full git tree.

But what if you wanted to keep other things backed up?

Drafting a Backup Plan

image created by Med Badr Chemmaoui at unsplash

The first things to think about are:

What are you backing up?

Is it just source code? Usually, that is pretty small, compared to raw video footage, photos, or other types of data.

Is it financial data? You might need to look into certain regulations about long term storage for that.

How often does the data change?

If it's source code, this might be hundreds of times per day.

If it's raw video footage, this might be rarely. If you're dealing with raw video footage, you'll likely save edits to that as a separate file or project - depending on how what you are creating

How will you restore the data?

Is this going to be a single restoration process? i.e. when some calamity happens, like your office floods:

Get Insurance - A Real Story

Jamie ・ Nov 9 '19 ・ 2 min read

#reallife #insurance #advice

Are you going to be restoring individual parts, or files, within the backed up data? i.e. some kind of git revert action?

How will you test the restore action?

A lot of people forget this step. What use is a backup of all of your data, if you have no idea whether the restoration steps work?

This can be as simple as spinning up a new VM, pulling the most recent backup, and running through the restore steps. You'll be surprised at how many systems have restoration steps which don't work or aren't kept up to date.

Creating a Backup Plan

image by Alvaro Reyes over on Unsplash

Depending on the type of data that you are backing up, you might have different backup schedules.

Shortly after I graduated (University of Hull, 2008), I started working at a school. I wasn't working in the IT department, but I had a lot of communication with the folks in that team. Since the PCs that they had at the school where disposable, and all o the important data was stored on network shares, they didn't bother running backups on individual machines.

What they did backup was the collection of network shares. Each day, at around 11pm, a cron job would fire which would back up all of the network shares to tape

tape is more reliable than spinning rust

Each Saturday, those tapes would be taken offsite and copied. Once returned, they would be entered into a monthly rotation queue. Each month, the data on the tapes would be replaced. And every six months, the remote tapes would be rotated (and re-used).

This worked for them because the important data would change very slowly. And they accepted that, after an entire year, a backup would be destroyed.

They also had a separate network stack, at a third location. This network stack was isolated from the world

via network cards, anyway

and they would use it as a training and practice ground for restoring the data which had been backed up.

This might be too much for you, or might not be good enough. I decided to mention it because I thought that it was a good middle ground.

My Backup And Restore Plan

image by Plush Design Studio from unplash

For those who don't know, I work on a bunch of podcasts. In fact here is a link to my podchaser profile.

The reason that I bring this up, is because I currently have over 200 GB of raw audio, produced and edited content, and related files combined. I don't know whether you've tried to keep a rotating backup of 200 GB of data, but it requires some forethought.

I had decided early on that, once the data was backed up, I would hardly ever need to restore that data. In fact, it's a point that was reinforced in episode 19 of The .NET Core Podcast, when Richard Campbell told me:

Don't throw anything away. Your legacy is important too. And I think that listeners appreciate that you're evolving.

The History of .NET with Richard Campbell

The .NET Core Podcast

Your browser does not support the audio element.

1x initializing... ×

there was a time when I needed to revisit an episode, but that's a story for another day

And so I would need to backup:

raw audio
audio projects representing the rendered audio
cover art, in super high quality (we're talking 4000*4000 pixels png and the RAW GiMP project files)

The raw audio is created several times a week and can range from 60 to 240 minutes per show (remember: I work on several shows). So that is a huge amount of data: each person on the show has their own audio channel, so a 120-minute recording with 4 people actually maps to 480 minutes of raw, uncompressed audio.

for those who don't know, wav audio usually runs into about a GB per hour of audio. You can reduce the space required by using FLAC, but that makes the restoration process a little more complex

As many will have noticed, I use Pop!_OS which is a distribution of Linux

My Media Creation Setup

Jamie ・ Feb 4 '20 ・ 5 min read

#mediacreation #linux #request #suggestion

I also use a Mac Air for editing while travelling. What's great about Unix-based OS distributions is that they ship with a CLI app called rsync. Rsync does a lot of things, but the basic process is:

an SSH connection is created
files are copied over to the remote machine
validation is performed to ensure that the files made it to the remote machine

I also have several local Synology DS218s. These devices have two drives installed in them but have them in a RAID-1 which means both drives are exact copies of each other. These devices also run a Linux distribution, so rsync is available there, too.

The reason that I bring up rsync is that I use it to copy these large files across my network. So when I want to create a backup on one of the Synology devices, I run something like:

rsync -avP  -e "ssh -i /path/to/ssh/keys -p <port-number>". <user>@<IP>::/backup/path

This command tells my machine to set up a secure shell (ssh) connection to the remote device found at IP as a specific user user on the supplied port number (port-number)

I'd always recommend changing the default SSH port from 22, as an easy win for SSH security

it also uses an SSH key (/path/to/ssh/keys) to authenticate with the remote device. Once the connection is created, rsync takes over and sends all of the files in the current directory (.) using the following setup:

recursive
keeping symlinks
preserving
- permissions
- timestamps
- groups
omitting directory timestamps
preserving device and special files

and that's just what -a does

in a verbose way (-v), so that I can see if something goes wrong, and keeping any previously partially completed files copy operations (-P).

Because each of my devices (except for my Windows laptop) has rsync built-in, I can backup or restore files in either direction.

On top of that, I have one-way sync to an offsite cloud backup provider. Each week, my "master" or main NAS performs one-way sync to my offsite provider: meaning that it will never pull data down from the cloud, but it can write to the cloud.

I can get the data from the cloud but only do this every few months as there is a big cost involved in pulling the data back down, as it is Glacier-like storage.

writes are super cheap, but reads can be expensive

But when I do test a restore, I:

take down two of my NAS devices
clone the cloud version of the files to one of them
recursively verify that both of the NAS devices have the same data

If the data doesn't match, then I know which part of the backup process has failed and can pin-point where the weak step in the chain is.

This backup plan isn't for everyone one, and you might think that it's a little over the top. But I'd rather it was over the top than suffer some massive data outage.

Conclusion

image by João Silas over on Unsplash

Whether you simply have a couple of USB drives in rotation or a wildly over-complicated setup like mine

remember, it's just for podcast audio, not company data

you really should be looking into having:

at least 3 copies of the data, stored on 2 different types of storage media, and one copy should be kept offsite

But you should also be checking that your backups can be restored, too. Because what's the point of backing things up, if you're not checking that it can be restored?

What's Your Backup and Restore Plan?

Is it as complicated as mine? Is it more complicated? Do you think that mine is too complicated for the type of data that I'm backing up? Should my backup process be simpler?

Let's swap suggestions in the comments.

My Media Creation Setup

Jamie — Tue, 04 Feb 2020 01:25:51 +0000

The cover images for this post is by marvelous

I was recently asked (via DM) by someone on Twitter about writing a blog post on the tools that I used for creating media. It should be of no surprise to some of you all that I create a number of podcasts. In fact, I wrote a post with disparate pieces of advice for aspiring podcasters:

Starting a Podcast - My Advice

Jamie ・ Jan 2 ・ 25 min read

#podcast

For those wondering, I'm involved in the creation of two

psst. it's soon to be three

podcasts:

The .NET Core Podcast
The Waffling Taylors Podcast

Here is an embedded player for the latest episode of The .NET Core Podcast at the time of writing:

How Do You Even Start with Josey Howarth

The .NET Core Podcast

Your browser does not support the audio element.

1x initializing... ×

I've also tried my hand at video creation and editing - something you can see in my live coding streams:

I've even tried some graphic design work

no I didn't create the artwork for The Waffling Taylors - that's created by the super amazing Yuricannes

But I have tried my luck at creating SVG icons for some of my open-source libraries, such as the logo for my ASP .NET Core middleware for injecting OWASP recommended HTTP Headers: OWASPHeaders.Core

All of this whilst using Pop!_OS as my daily driver OS. So which tools do I use:

Audio

Aside from my development work (and writing), the majority of my time is spent doing audio work. So how do I go from no audio to a fully rendered MP3 of a podcast episode?

note: I started planning this blog post before I hired an editor, who takes the lion's share of the editing work from me

VS Code

It all starts with VS Code:

I start with VS Code when planning out episodes because I can quickly type out my idea using markdown. There are other editors which do a good job of rendering markdown, but I also use VS Code as one of my IDEs - so I'm happy using it for markdown, too.

I use VS Code to write out a plan for an episode idea or to take a bunch of ideas and expand on them. This is then saved in a private git repo

pro tip: source control all the things

.NET Core

I have a .NET Core template which I can use to scaffold everything I need to record a new episode:

note: the open-source version only scaffolds the markdown show notes; whereas the closed source version does all of the episode scaffolding for me

I use this to quickly set up everything that I might need in order to record a new episode of the podcast.

Audacity

Once the recording is completed, I'll use Audacity to edit the raw audio.

This is the application that I'll spend the most time in when putting an episode together. Editing and post-producing

which are similar, yet subtly different, things

an episode takes a long time - the rule of thumb is that 30 minutes of audio will take 60 minutes of work.

Auphonic

Auphonic is an amazing post-production tool, especially if you're not a fully-fledged audio engineer.

This is the first paid tool on the list, but I'm happy paying for it because it makes my shows sound much better than I could. It's also really simple to use - the default setup is almost perfect for my shows. I feed this app an uncompressed wav file (exported from Audacity), and it gives me an MP3 with radion and TV industry-standard audio levelling.

Beware: although there are desktop versions of Auphonic, there isn't a native version for any Linux distros. This means that you'll have to setup WINE in order to run the Windows version of Auphonic on your distro.

kid3

Once I have the MP3, I put it through kid3 in order to tag it correctly.

I like to set the ID3 tags on episodes of my podcasts before I upload them. Most podcast hosts allow you to alter them once episodes have been uploaded, but you can use the contents of the tags to auto-fill most data on podcast host sites.

Also, setting ID3 tags on any audio that you create

assuming that you're creating MP3s

will your listeners happy.

Video

In the past, I have scheduled live code sessions

something I'm tempted to get back into

and these have been facilitated by a single application:

OBS

OBS. This has become the de facto application for streaming video to and from services like Twitch, Youtube, and Mixer. It's used by the pros along with the amateurs

like me

all for free.

Did you know that the software which ships with Elgato devices is simply a re-branded version of OBS?

Images

I use two applications when creating images or doing any kind of (admittedly simple) design work:

GIMP

GiMP (or GNU Image Manipulation Program) is also known as "free Photoshop".

It's incredibly powerful, but the work that I do with it barely scratches the surface of what's capable with it.

Inkscape

When I need to work with SVGs or any kind of illustrations, I open Inkscape first.

Just like GiMP, Inkscape is super powerful and I'm barely even scratching the surface of what it can do. I've used it to create the icons for the majority of my opensource projects, and for touch up work on the Waffling Taylors logo ready for placing on business cards and hoodies:

The Waffling Taylors

@wafflingtaylors

And so we begin our journey to London for #EGX2019.

If you spot us (either during our journey, or whilst we're there) do say hello. We'll be wearing these incredibly limited edition hoodies, as moddeled by me.

- Jay

10:21 AM - 16 Oct 2019

1 4

What Do You Use?

If you're rocking a FOSS OS

that's pretty catchy

what do you use for media creation? I'd love to hear about other applications that I can use to potentially increase my productivity or create higher quality media.

I've intentionally left off the majority of the tools that I use for my day to day client work for a number of reasons:

Some of it is covered by NDAs
IDE choice is a sticky subject
This was a post specifically about media creation

Let's swap suggestions in the comments.

Securing a Webapp - Step 1: Start As You Mean To Go On

Jamie — Mon, 03 Feb 2020 23:47:06 +0000

The cover images for this post is by Helloquence

“Begin at the beginning," the King said, very gravely, "and go on till you come to the end: then stop.”

Lewis Carroll, Alice in Wonderland

For those who may have missed it, this is part one in a series of posts on how you can secure a web app. Here is a link to part 0, which lays out what I'm going to achieve with this series of posts.

As a quick reminder (and a form of tl;dr): I'm in the process of building a web application for a real client, and I'm going to be covering what I'll be doing in order to ensure that the app has security baked in from the get-go.

The point of this post is to get you thinking about the things you should be including in your design decisions at the start of your project. Some of these features require explicit design from the start (multifactor auth, for example), and some can be "bolted on" afterwards.

Before we start, I'm not a security expert. I'm simply collecting all of the knowledge that I've gained over the years into a series of posts. I want to give you a great place to start in discovering the ways to lock down the systems that you are designing. It's also not meant to be an exhaustive list of things to include but should be enough to get you out of the unknown-unknowns and into the known-unknowns

i.e. you should have enough information to do some more research of your own

Security From The Ground Up

The first thing that you need to be thinking about when you start a new project is how you can keep the bad guys^TM out. The easiest way to achieve this is to not build the app. Seriously, if it doesn't exist then they can't break-in.

How can someone steal your car, if you don't have one?

But your clients are going to get quite upset with you if you take their money and don't produce anything in return. So we need to take the next step up: add security in from the get-go.

Imagine that the building you work in has those card-based entry points. You know the ones: you have to present a card at each door for it to unlock and if you're not authorised to get in, then the door doesn't unlock.

Then you look up and realise that the building has those ceiling tiles which can be pushed slightly out of the way, revealing a walk-way.

How secure is that door now? Not very, right? Sure the bad guys need to bring a ladder, but that's totally doable.

Worse yet, you have floor to ceiling glass doors with a single lock on them; bolting them both closed and to the floor. What if I cut out the lock?

this may or may not have actually happened at a previous employer's office

With that in mind, we want to include security at the very beginning.

But I Don't Have a Site Yet

And this is the best time to start. Adding things like CSP in after the fact will just give you headaches.

Adding security at this stage (i.e. before there's a design) will inform how the design comes together.

Let's say that your client wants an e-commerce site. They want to be able to show off their wares, have users make orders, and take payments. Well, you don't have to build all of that functionality. Imagine having to create all of that, secure it, and be the person to blame when something goes wrong.

because it's going to go wrong

You don't need all that stress, so just drag in Stripe (or your payment processor of choice) and throw together a forms over data view for the database.

But even that needs security adding to it.

Single Responsibility Principle

Putting aside all of the complex stuff that you can to in order to make an app more secure, let's start right at the beginning: the single responsibility principle states that a user can do one thing only:

Is the user a blog post editor? Then they don't need access to the database settings
Is the user someone who packs customer orders into a box? Then they don't need access to credit card details

This goes hand-in-hand with the Principle of Least Privilege. Average users of Windows (i.e. usually not tech workers) fall afoul of this more often than Unix and Linux users, as the default type of user on Windows is an Administrator.

Create an account for your two-year-old so that she can play around with the keyboard and make the lights flash, and suddenly she's making system-wide changes to your computer, for instance.

that may or may not have happened to someone I know

I don't mean to pick on Windows here, I just use it as an example.

So now that you've decided that you have a number of user types, and you've started to slice the functionality into pieces, next is how the users log in.

Single vs Multi-Factor Auth

Multi-factor authentication isn't necessarily a new thing

hardly anything in tech really is new, these days

but it has been shown to vastly improve the security of a system with very little downsides. Sure it can be a headache for some users, but we're seeing the widescale adoption of multi-factor auth in systems. This means that - from an auth perspective at least - things are getting better.

But what is multifactor auth? We're all familiar with single-factor auth (i.e. username and password), as something that we know. Multifactor auth is an extension on this and includes:

Something you know (username and password, or pin)
Something you have (cell phone, YubiKey)
Something you are (biometrics, geolocation)

Multifactor auth can help in protecting both users and the software that they use by adding an extra step in the auth cycle. That way, if the credentials of a user are discovered, a malicious party won't be able to use them to log in - they'll need to figure out how to beat the multifactor auth steps.

Make no mistake, multifactor auth isn't a silver bullet and can still be beaten. But you only need to be more secure than your competitors.

User Input

Imagine that you have a series of antiques in your living room. One day, you have friends over and their three-year-old child causes some kind of Rube Goldberg machine like effect by knocking one of your chairs over, causing a chain reaction which destroys all of your antiques.

You question the little one, asking for the truth. "No one will be upset if you tell the truth," you say. And when the little one in question opens their mouth, they tell the most fantastical story involving aliens, soldiers, knights, and a crocodile.

There's a chance that you live in a country which has constant issues with aliens and crocs, but most of us don't.

The point is: do you trust what the little one said?

Just like the little one's story, you should never trust user input. It's ridiculously easy to target websites with things like SQL injection attacks - remember little Johnny Drop-Tables:

source

Each time you allow a user to supply any kind of input (text, files, telemetry, etc.) you are opening your system up to attack. Most of these attacks can be mitigated by enabling validation on three surfaces:

Client
Server
Database

EDIT:
It has been pointed out in the comments, that the original version of this paragraph seemed at odds with my intent. I'll leave the original paragraph here, but will also include a revised one

Original:

You can enable validation built into the HTML standard, or use libraries like jQuery Validation, for the client. Checking the input before it is sent to the server can be a lifesaver, and will save you from having to validate on the server - not to mention the roundtrip back to the server.

Revised:

You can enable validation built into the HTML standard, or use libraries like jQuery Validation, for the client. Checking the input before it is sent to the server can save bandwidth, but should never be trusted. You can't trust client-side validation for a number of reasons: chief of them being that I can turn JS off, alter the JS before it's executed, or add breakpoints to alter it whilst it's executing.

Relying on client-side validation alone is effectively suicide, as Pablo pointed out in the comments:

Paulo Renato • Feb 4 '20

Client: is the application making the request to the server. This can be a web app, a mobile app, a script, or a tool like Postman.

The server cannot trust data from the client, but if you only do validation in the client side, your web app, then your server is trusting in client data.

For me the message you are passing is that once you validate the data the user inputs on the client side, then the server doesn't necessarily need to check it again, and this his why I said that is a suicide.

All major server-side frameworks include some form of validation. I'm a .NET developer and I know that support for validation is built into ASP .NET Core. It requires a call to ModelState.IsValid in a controller method, in order to check the model. You can even have those errors sent back to the client to be displayed.

Validation at the database level is a little harder to achieve and is very specific to the database technology that you are using. Some database technologies don't have validation and will blindly accept any data that they are fed, whereas some have validation enabled out of the box.

If you want to go the whole hog, you can validate the data on the way out of the database, too. This might be required for your industry, or it might be seen as a little too much. YMMV.

Starting a Podcast - My Advice

Jamie — Thu, 02 Jan 2020 23:33:49 +0000

This blog post was originally posted over at the blog for RJJ Software - here is a link directly to it

A Question About Podcasting

Recently, KaleighS asked a question over at the Blogging Mastermind slack group all about podcasting:

any good articles/sites/(or even podcasts) on getting started podcasting?

We had a short thread, before I did a veritable brain dump of information. Here is the thread:

I've blurred the avatar that KaleighS uses because I didn't want to somehow dox them

I read back through the brain dump and thought that parts of it could be useful - if I tidied it up a bit, that is. So I've taken some time to do just that, and here it is: my advice for budding podcasters:

TL;DR

It's challenging, but rewarding
Stick to the cadence that you set
Don't look for sponsors right away
Don't focus on the download numbers, focus on quality
You get what you pay for

Intro

Everything you're about to read is my own personal opinion based on my experiences of running two regular podcasts (and having started a few which have podfaded), namely:

The Waffling Taylors - fortnightly releases
The .NET Core Podcast - fortnight releases
DevOtaku - podfaded, but may be returning
Ask a Brit - podfaded, but definitely returning

First a little terminology:

Podfade; when a podcast stops creating new episodes and fades into obscurity
Host; someone who will host your MP3 files and create an RSS feed for people to consume
IAB; The Internet Advertising Bureau - they have a standard for measuring a podcast's success when reporting to advertisers
RSS; a way to consume syndicated content on the web. There are many RSS feed readers, and podcasts are just one of the uses of it
Double Ender; when you and a guest have to use some kind of VoIP system have everyone record their audio and splice that together

Advice 1: Have a Solid Idea

My first piece of advice is that you should have a really solid idea. If it's not solid, then the show wont really be fully formed before people start listening, and if the show isn't fully formed then people will stop listening (people are fickle).

After that, take some time to record a few demo episodes. You'll get a feel for just how long a planned, structured show takes to produce. You'll also start to get a feel for what the show will be - the first 5 to 10 episodes that you record won't reflect the final material because you'll still be figuring out what goes where.

This is because, whilst the idea is still forming in your head you will want to try new things out. "What does this filter do?", "Can I somehow make my voice sound like I'm a ghost?"

yes. In Audacity: select a section, reverse it, add an echo, and reverse it again

You might even come up with new segments whilst you are figuring out how to use the technology that you have. As Steve Jobs said:

Stay hungry; stay foolish

You may also start having ideas about intro and outro music. I'll come to this later, but DO. NOT. USE COPYRIGHTED. MUSIC. If you didn't create it, and you didn't pay someone to create it, don't use it. There's a small group of folks called the RIAA who will likely send you a cease and desist.

Mini Advice 1: Music

Whatever you do, DO. NOT. USE COPYRIGHTED. MUSIC. Even a second is enough to get on the bad side of the RIAA. The RIAA represents all of the music industry types across the world. From their about page:

The Recording Industry Association of America® (RIAA) is the trade organization that supports and promotes the creative and financial vitality of the major music companies. Its members comprise the most vibrant record industry in the world, investing in great artists to help them reach their potential and connect to their fans. Nearly 85% of all legitimate recorded music produced and sold in the United States is created, manufactured or distributed by RIAA members.

emphasis is mine

If you want to have music in your show, then have it composed for you. I've used folks on Fiverr for this in the past, and I've actually received the full license from them. For the tiny sum of $11 (US) I was able to have someone compose a piece of music to my liking, but also to transfer all ownership rights to me.

Whether you go down the route of Fiverr or not, ensure that you legally own the music that you put into your show. Otherwise the RIAA will want a chat with you.

Advice 2: On Recording - Hardware

You can start with as little as the microphone in your laptop. Examples from my own past are:

53 Games in 63 Minutes which was recorded in my brother's games room with the mic built into my Mac Air - and it really sounds like it.
.NET to The Core! the first time I was interviewed for a show. I used my Mac Air microphone for this, and we connected over Skype

When you are ready to increase the production value and sound quality of your podcast, I would recommend buying an external microphone. Laptop microphones are ok to get started with, but they aren't the best. Take a look into the differences between Condenser and Dynamic mics: Condensers tend to be louder, but pick up a LOT of background noise; whereas Dynamic mics are quieter, but don't pick up the noise.

you don't have to spend a huge amount of money on a mic, as you're just starting out. But know that you get what you pay for. For the majority of the episodes for The .NET Core Show, I use a Blue Yeti mic. This a condenser mic which plugs directly into USB, and most apps will detect it without any issues. For the newer episodes of The Waffling Taylors we have been using lavalier mics which have XLR (rather than USB) connectors, which we plug into a Zoom H6N.

The H6N is a hardware recorder, which means we no longer need a computer to record, and can do recordings "in the field" - which is what we did for our episodes at EGX. This means we can take the hardware recorder, a number of mics, and set up shop wherever we want.

One of the best things about this piece of kit is that we can plug four mics into it, and still use the two mics at the top of the device (in the image, they are the silver mics at the top of the device), for a combined 6 mics. Each mic is recorded on it's own track, so it makes editing really easy.

On top of that, you can also use it as an input device for your laptop/PC, so those 6 mics can be recorded (on your laptop/PC) with yet more mics. I wouldn't recommend it, but if you desperately need to have 7 mics, it's a quick win.

Regardless, know that you don't have to jump to this level of equipment at the start, but setting aside some money for buying hardware (and eventually software) will help.

Advice 3: On Recording - Software

Recording episodes can be incredibly easy or fraught with difficulty.

If you have Apple hardware, like a Mac laptop or Apple computer, then you have access to a piece of software called GarageBand. This can be used to get you started. It's simple to pick up, but can be difficult to master. The first episode of The Waffling Taylors was recorded using GarageBand and the mic built into my Mac Air. All of which was free - after the cost of the laptop.

There are hundreds of products on the market for recording audio using a PC, laptop or Apple device. I use Audacity, mainly because it's free (remember: you get what you pay for). It's relatively bug free, and works wonderfully. But when it crashes, whatever you were working on cannot be recovered.

I've heard a lot of talk about Reaper and Davinci Resolve. These are paid products, as is the Creative Cloud. All of these products have the ability to record and edit audio. I'd recommend taking a look at demos of them on YouTube, and trying out any free trials of them to see which sits with you best. Reaper is definitely at the pro end of the audio and music production spectrum, so expect to see a lot of features that you are never going to use.

I've learned all of the short cuts for Audacity, and have a solid backup plan, so I'm happy using that. But YMMV (Your Mileage May Vary).

Advice 4: On Recording - Remote

There will come a time when you need to record part of your podcast remotely. This will likely be because you and a guest cannot be in the same physical location at the same time.

There are a lot of services which strive to help you with this. As I've said already: you get what you pay for. I've found that free services like Google Hangouts, Skype, and similar can be incredibly flaky. If you have to use these tools, ensure that you do a double ender.

A double ender consists of each person recording their own audio and sending it to you to be multiplexed together (that's a fancy way of saying "edited together"). If you have to do a double ender, ensure that you have a sync signal. The most common way to do this is to have everyone recording then count down from three and all clap together. When you come to edit everything, you can use the spike caused by the spike to line everything up.

There are products out there which are designed to do all of this for you. Some of them are:

ZenCastr
Ringr
Squadcast

The idea with these apps is that they set up a VoIP call for you, record each person's audio within the browser cache, and upload them to some central server. I've used ZenCastr and SquadCast more than I have done double enders; when they work, they work gloriously. But when there's an issue (I've seen this with ZenCastr more than anything else), nothing is usable. I've had to re-record several interviews that I've done with ZenCastr, and I still have a few that are unusable because I haven't had the chance to re-arrange them.

If you end up using something like ZenCastr or SquadCast, it's worth pointing out to everyone involved that they should read the FAQ for the service that you choose. They often have limits on the browsers that they support. The following text comes from the FAQ that I send to guests of my show:

One thing to note about SquadCast is that the default UI includes a map with a vague geo-location of all participants. This can be disabled on a per-guest basis by blocking the geo-location services API when it is requested, this will not affect the quality of the recording. However, according to their support channels, using a VPN may cause issues with the recording. If this is likely ot cause an issue, we can arrange another way of performing the interview.

SquadCast will also ask for video permissions. Video footage will not be used for the recording, as such it is recommended to not share video. Doing so will require more bandwidth, and could potentially affect the recording.

Having headphones, earphones or some other form of audio monitor will ensure that there is no audio feedback from a combination of the speakers that your computer uses and the microphone that you are using.

Also have an FAQ for your guests. This can help with easing them into being on a podcast, should they be new to being interviewed for them.

Advice 5: On Planning

I have a multi part plan for each episode:

Come up with an idea, or set of topics
Write out as much as I can think of for each topic
Figure out who (if anyone) will be on the episode with me
- If there are guests, reach out to them and arrange a time which suits them best
- Discuss the episode with them ahead of time, and share as much in the way of notes, so that they're not going in blind
Actually record the episode
Edit and post-produce the episode
Either:
- Provide show notes commenting on the episode (ala Waffling Taylors)
- Provide a full transcription of the episode (ala The .NET Core Show)

Mini Advice 2: Show Notes

If you take a look at the show notes for an episode of The Waffling Taylors - here's the latest episode as of posting this - you'll see that it's more like commentary, filling in gaps, and discussing the episode itself. This is because it's designed more as supplemental material to the show. I could provide a transcription of the episode, but they tend to be a little too frenetic to provide a transcription - which means it would take too long to create one. This means that we're cutting out a large portion of our potential listener base: those with accessibility needs. This is something I'm looking to fix in the future.

Whereas, if you take a look at The .NET Core Podcast - again, here's the latest episode - you'll find a full transcription of the episode. This helps folks with accessibility needs, as they can read the transcription rather than listen to the episode. This also has the side benefit of adding SEO juice

I really dislike that term

to your show notes site, as it's now searchable and indexable.

But if you're going to supply a transcription, do it for those with accessibility needs rather than the SEO; as your audience should be your priority.

Advice 6: Editing

I pay an editor to actually edit the shows, that way I don't spend my evenings and weekends doing it - but I did used to do that. It's hard to juggle a passion project like a podcast, a full time job, and family commitments. So I'd recommend looking into paying an editor to put it all together for you, but only after you've got the show off the ground. The reason for this is that a lot of really good editors will want:

A: a lot of money for what they do (again, you get what you pay for)
B: some kind of assurance that there will be a more than just one episode to work on (they've got mouths to feed too)

If you go down the route of being the editor, you'll need to learn a lot about the tools that you use. You'll potentially need to learn about filtering and equalising, noise gates, amplification levels, and things like LUFS.

The last part is pretty easy to learn about. LUFS are the loudness units (think like pounds and ounces, but for audio) for audio levels in radio, TV and movies. There's an industry standard for LUFS for TV and Radio and you'll want to stick with that. Otherwise your listeners will end up having to increase the volume of your show up and then scramble to reduce the volume when yours ends - from a listeners point of view, that's horrendous and separates the pros from the flight-by-nights.

You can achieve the LUFS levels by investing in an app called Auphonic. It's available for both Windows and Mac, and as a web site. All three offerings will take an input audio file, and apply Dynamic Range Compression to ensure that your resulting episode is within the LUFS range. I leave all of my episodes at -16 LUFS, as that's the standard for Podcasts and Mobile phone calls.

My typical work flow for editing an episode of The .NET Core Podcast is this:

Obtain all tracks from an interview recording
Feed them all into Audacity
Line them up
Go through the recording, tweaking things
- Removing any long sliences
- Removing any flubs (I often fall over my words)
- Removing any parts where someone mentions that they'd like to try again
- Perhaps the person speaking flubbed, or need to refer to notes
- Remove any gaps for taking a sip of water
Add an intro and outro
Add short musical indents at key places
Add any ad reads (if approprite)
Export as a WAV file
Put the WAV file through Auphonic
- 96 kbps MP3, Mono

Mini Advice 3: File Sizes

96kbps because the music idents are specifically designed to sound ok at that bit rate; MP3 because you don't want someone downloading a ~600 MB audio file; and Mono because it's conversation with everyone mixed to the centre, so it immediately halves the file size. Here is an example of an episode that I'm working on right now, a WAV version and the MP3 encoded version:

Your listeners will thank you for the smaller file sizes, and your host will thank you for saving them on bandwidth.

If your show has a lot of music - maybe it's a music review show or similar - you'll want to look at a higher bit rate. Because my shows are mostly speech, they can be encoded at a lower bit rate and still sound good.

As for actual advice on where to start: be prepared to put a lot of work in. The average episode of The .NET Core Podcast is 45-80 minutes long. But I actually spend about 8 hours working on a single episode.

Recording the episode is one of the easiest parts, as I hit record and my "podcast interview voice comes out". Also, I'm incredibly lucky that I'm an auditory learner so I can speed through the recordings a 1.6 to 2 times faster than normal and still take it all in. You might not be able to do this, but with a little training, you will be able to reach those speeds. I'd still recommend going through the episode again at normal speed, in case you miss something.

The rule of thumb for editing is: every 30 minutes of audio is going to take at least 60 minutes to edit - more if there are lots of issues with the audio. Even though I go through my episodes super quickly, I'm still spending around 90 minutes editing every 30 minutes of audio.

It just takes time.

Advice 7: Growing Your Audience

Getting and maintaining an audience is the hardest part. Just like blogging, it requires a lot of effort on your part.

When you start, you'll be shouting into the void. This is because there are so many other content creators out there offering the same stuff - and podcasting has had a lot of positive press in the past year or so. Once you've managed to differentiate yourself from the other creators, you'll need to try and stay ahead of them by innovating quicker or offering something that they don't. That's the biggest drain, for me.

After that, you'll need to try and get some kind of back and forth going with your listeners. Your podcast host will give you vague numbers for your subscriber levels - these are based on download levels, but are not accurate. Whilst it's great to see the numbers go up, don't create the show specifically for that because as soon as those numbers drop, so will your motivation to create the show along with your morale surrounding it.

Focus on quality over quantity.

Advice 8: Show Launch

I launched all of my shows, with a single episode each, whilst working full time. Others will tell you to have a number of episodes ready to go before you launch. It's really up to you.

If you have a specific date in mind for a public launch (maybe you have something planned for social media outreach) ensure that Apple Podcasts (formerly iTunes) and Google Podcasts have discovered your show at least before you launch. Most of the other platforms piggy back off of those two (even though Google Podcasts is still very new).

It will be worth looking into Podcasts Connect and creating an account before you plan to release your show. This is one of the ways that you can submit you show to Apple Podcasts (your host will likely have a way to post to Apple Podcasts for you), it's also a way to get some stats on your show from Apple.

some stats for The .NET Core Podcast from Podcast Connect

Podcast Connect have guidelines on how long it might take for your show to be indexed by them - as they do some kind of vetting process before allowing a show onto their system. The indexing time can change from month to month, and some periods (like the recent festive holiday period) have much longer wait times. So if you are planning to launch on a specific date, ensure that Apple Podcasts has indexed your podcast way in advance of that because there is no way to speed up the process.

The easiest way to get onto Google Podcasts is to let Google do it for you. This will mean that you'll need a website for your podcast - which I'd recommend anyway, that way you can have long form show notes. So you might need to approach a web developer in order to help you do it (YMMV), as there are specific tags that you need to include so that the Google bot can discover your show.

One of the neat positives to this is that you can have Google display the episodes in search results, and will let folks listen to the episode right there in the search results.

clicking on one of those play buttons will play the episode in the search results

Advice 9: Download Numbers - Ignore Them

Don't expect success overnight. For every Joe Rogan Experience, there are 300 other shows recorded in basements. For every McElroy trio, there are hundreds of other wannabe comedians who haven't been given air time. Keep working at your show, keep producing high quality content, and keep telling people about it; only then will the people come.

Most companies who offer sponsorship and advertising will want to know what your audience size it. But this is a difficult metric to measure.

Podcasts use RSS feeds. Here is the RSS feed for The Waffling Taylors. As you can see, you can just load it in your browser, and play the episodes there.

Even if you listen in Apple Podcasts (or some other app), you don't have to sign-in in order to listen to an episode. My previous screen shot showed that you can listen within a Google results page. So how do they measure your audience?

Total downloads.

It's that simple. The amount of time that one of your episodes has been downloaded, for the first 30 days after it was released. SOME hosts count unique downloads by IP address and User Agents, but not all of them do. Which leads to some confusion with this metric.

The problem with that, is that podcasts are ad-hoc: you can listen when you like. I've found podcasts which are 2 or 3 years old, and gone back to the start listening from the beginning. Doing that (which a lot of folks do, if this history of the show is important) doesn't add to their audience from a sponsorship point of view, but it does make their audience larger.

On top of that, streaming an episode (clicking play on and of the links in the screenshot above) will only count as a listen after the first 30 seconds has been played. Anything less than that, doesn't count as a listen.

On top of THAT, the potential sponsors could ask to see proof that you're actually getting as many listens as you claim. It could just be one person listening to your show, on repeat for all they know.

Some podcast hosts will give you access to a bunch of stats about your listeners. These are (usually) anonymised stats collected from useragent and IP addresses. All webhosts have access to this data for the websites that they serve, and a podcast feed is no different in this aspect.

Here's a rough idea of the worldwide listener stats for The Waffling Taylors:

All of this can be faked with someone who has access to a global VPN, as they can connect to a node in one country, download an episode of your show, then change to another node and repeat.
In fact, this is what a lot of folks who offer to boost your download stats (on sites like Fiverr and the like) are actually doing. Whilst it will increase that number, it doesn't actually grow your audience. Again, that download number is just a number, and shouldn't be your goal.

Advice 10: Sponsorship

When it comes time to actually look for sponsors, take a look at some of the ad networks. But do your due dilligence. Look for reviews of them by folks who are actually using them. Most of the ad networks will include testimonials on their site, but do some background checking to ensure that they are still using the network. The quote may be old or fabricated, so look into it. Also familiarise yourself with the IAB. Look into things like their podcast measurement guidelines. Your potential sponsors will know this stuff and will be looking for specific numbers, so make sure that you have them to hand (or know where to look to find them).

Some hosts will only give you access to IAB numbers if you pay them extra. LibSyn does this (they host The .NET Core Podcast), but their stats breakdown is amazing, and totally worth paying for. Without the IAB numbers, many sponsors simply won't be interested.

If you go directly to a potential sponsor - rather than using a network - be ready to sell your podcast as a platform to get their message out. You want to go for the hard sell here, why should this company put their ad on your podcast? Is it even relevant to the subject matter? If your podcast is about submarine engineering and you are approaching Casper, they might pass. What can your show bring to their brand? Do you have those numbers to hand?

Another thing to know is that a lot of sponsors will only be looking for shows which release episodes very frequently - one sponsor I approached said that they where only interested in shows which released new episodes every day.

Advice 11: Release Cadence

It can be super exciting to release your first episode, and you may want to release the next episode right away. But you need to think about the longevity of your show.

If you release two episodes a week now, will you be able to keep that cadence up in 6 months time? What about in a year? What about if you get sick? You need to set a cadence that you can stick to in a year's time.

When I started The .NET Core Podcast, I was releasing episodes every week. But that was impossible to maintain. I was editing episodes during my lunch break at work, during my commutes to work, and into the evenings on most days - and once or twice on the weekends. I dropped the release cadence to fortnightly and built up a backlog of episodes to fall back on, and I'm much more relaxed now.

Mini Advice 4: Backlogs

Before I created a single episode for The .NET Core Podcast, I had a markdown file with ideas for the first 15 episodes. Each of these ideas was fully fleshed out. This helped me to see what the longevity of the show would be. I had a clear topic for each episode, and I spent time writing them, cross referencing them with blog posts that I had written, blog posts by friends, or official documentation. These 15 episode drafts became monologues about aspects of .NET Core that I thought would be interesting to listeners - either new to .NET and seasoned veterans alike.

Looking at the released episodes for the show, I have only released 9 of these monologues so far. Which means that I still have 6 episodes that I can turn around very quickly, should I find myself without any episodes ready to go.

in fact in writing this blog post, I came up with 5 more monologues

The key is to have a stable of episodes that you can fall back on. I've been in a situation (early on) where I was editing right up until the hours before release of an episode - reading on, you'll be able to guess what time I stopped editing that episode. The key to never ending up in that situation is to have a bank of episode ideas ready to go.

Once you've set your cadence STICK. TO. IT.

The majority of podcast listeners have subscribed to around 10-15 shows. As such, they actively look for new episodes. Just like how a lot of people without YouTube accounts use YouTube: they'll search for their favourite shows, and if there isn't a new episode they'll move onto something else, if there's no new episode then they'll stop watching altogether.

I'm a bit of a "power listener" as I have a lot of shows that I subscribe to

just some of the shows I subscribe to, as shown in PocketCasts

A number of podcasts that I listen to aren't available on PocketCasts, so I use the podcast feature of VLC to keep up with those shows.

So called "power listeners" are folks who listen to podcasts the majority of the time. They don't tend to listen to music. They listen to podcasts when doing menial tasks (commuting, chores, etc.), and some (including me) listen when they work (I'm an auditory learner so can usually both work & listen - and take it all in).

A lot of your audience will NOT be those listeners. As such there will be peaks and troughs in your listenership (those download numbers that you can't trust). The majority of your listeners will likely listen during their commute and when doing chores, and that's it. Because of that, you should expect to see dips in listenership during holiday seasons, and times when folks aren't working (Labour day, etc.). This is because they'll be doing what you (likely) are doing: spending time with family.

So don't be put off with occasional dips in download numbers.

The two peaks here are episode releases, but the trough afterward is the 2019 festive season

Advice 12: When To Release Episodes

Whenever fits your schedule.

Don't set yourself up for failure by releasing episodes when it's hard to. You still need to edit, upload, release, and publicise the episodes. So you need to factor in time to do that. Fit it in around your schedule.

I'd recommend taking a look at your monthly calendar and finding multiple days which work; and remember you need to be able to do this every time you release and episode. Once you've found a number of days which work with your schedule, have a think about your subject matter. Is it evergreen? Is it related to a real-time event?

Most of the episodes for my shows are evergreen, so I release them on a day which suits me. But the EGX episodes of The Waffling Taylors went out at the end of each day of that conference. This was super tiring, as we'd recorded hours of content which needed to be whittled down to 90 minutes, edited together, and released AFTER a full day at a gaming conference... for four days in a row.
It was not easy.

Is your show about a specific TV show? It might make sense to release it very soon after each new episode of the TV show. Is it about a series of ongoing movies (still being released to theatres)? Is it possible to release your episodes during the lead up to the release of the new movie? If so, people will organically find your show when they are searching for the subject.

I chose Fridays at 1230 GMT because I'm usually on my lunch hour at that time, and can quickly sign into my podcast hosts to ensure that the episodes have gone out. I also have all of the tweets/posts/statuses (stati?) for them ready to go just before that. On top of that, it's a time during the day where most folks will be able to listen to the episode:

For folks in the far east, it will be late at night so that covers commute times
For folks in Europe and The UK, it's lunch time into early afternoon
For folks in the Americas, it's relatively early in the day - again more commute times

Again, YMMV and do what works for you.

Advice 13: Automate What You Can

I've partially automated the entire process. I have a .NET Core application that I can run which:

Creates a SquadCast recording session
Creates the Audacity Project on disk
Creates an empty show notes file

Which takes the ceremony of getting everything set up. I'm also looking into whether I can automate that with an IFTT connected to the calendly for the show.

Once an episode has been uploaded to my hosts, I set up a another IFTT job to do the social stuff, release the show notes, and email folks for me (usually the guests, and my editor). It isn't hugely difficult to get this all set up, it just means reading a bit of documentation and getting your head around how it all works.

Advice 14: Share The Load

If you are going to have co-hosts, make sure that you divide the lion's share of the responsibilities for the show between you. Otherwise, you'll end up doing it all and they'll take all of the credit. You don't want to be working until the wee hours of the morning, wondering if you'll ever see sunlight again, slaving over getting the next episode out, for your co-hosts to take all the credit and claim all the glory. It's just not fair.

A friend of mine (who has a very successful, weekly show) has gone as far as to draw up a contract between him and his co-hosts. I don't suggest going this far, but it can help. Especially if co-hosts end up not pulling their weight, or want to leave the show: you then have a legal document saying whether the IP is shared between you and the co-hosts, and whether they should expect to receive a share of any sponsorship or profits after they have left.

For a number of reasons (copyright, legal protection, sponsorship, taxes, and sharing the load), it might be worth looking into setting up some kind of legal entity which owns the show. Seek legal and accounting advice on this, as this will differ per state and country.

I have done this, both The Waffling Taylors and The .NET Core Podcast are owned by my limited company. This same limited company is the one that I use for my development contracting business. This protects me (the individual) in case a guest makes a libellous or incorrect statement on the either of shows, and someone takes issue with it.

The Coding Blocks Podcast is owned by an LLC for tax and accounting reasons (as far as I know). This helps the three hosts keep an eye on spending (they each put money into the LLC, and that is spent on things relating to the podcast), and it helps with taxes due to sponsorship. However, they are based in the Atlanta, GA area and this may be a requirement based on local laws.

Again, due diligence.

Advice 15: Guests & Promotion

Look for other shows in your niche, and approach the hosts about potentially being on their show as a guest. A lot of shows will happily do this, because it makes it easier to create content, and it means more people will listen (you will likely tell all of your friends, family, and colleagues about your appearance). It also works in your favour, because it gets your name out to people who are very likely to be interested in your show. And you can return the favour and have them on your show, doubling down on the guest spot potential.

Before I even started The .NET Core Podcast, I was on a number of shows talking about .NET Core (Cynical Developer, Productivity in Tech, etc.). This meant that when I launched my show, the hosts of those shows were willing to shout out about it, and place a link on shows notes for the episodes I was in.

I would also look into Facebook, Twitter, and LinkedIn groups with a lot of users in your niche. Before you start blindly posting links to your episodes, check with the admins of those groups as to whether that's permitted - some groups will want to foster a conversation rather than turn into a link farm. Each group will be different, so check with the admins and make sure that your posts follow those guidelines.

I haven't looked into other social networking sites, as I didn't see how they were relevant to the podcasts that I create. But they might be relevant to yours, so I'd recommend doing some research.

So that's 15 peices of advice for budding podcasters. Do you agree with everything here? Is there something you would have added? Do you disagree with anything in the list? Let's chat in the comments, or get in touch over on Twitter, and let's talk about it - lets not get into arguments about bit rates though, that doesn't help anyone.

Get Insurance - A Real Story

Jamie — Sat, 09 Nov 2019 12:20:23 +0000

TL;DR

If have any things in your house: GET INSURANCE!

For those of you who missed it, I tweeted this out on Thursday:

dotnetcore.show

@dotnetcoreshow

It is with an extremely heavy heart that I must announce that The .NET Core Podcast has go on an indefinite hiatus.
I returned home from work this evening to find that my home office had flooded. I don't know how, or what the source was, yet.
But it destroyed all of my hardware.

20:23 PM - 07 Nov 2019

9 16

Essentially what happened was:

the UK had a month's worth of rain in 24 hours
many parts of the UK where affected
there was chaos on the roads and railways

dotnetcore.show

@dotnetcoreshow

Rather than announce that any trains are cancelled (they're appearing as cancelled on third party sites and apps), they're allvlisted as delayed.
Including one which has been delayed by three hours (far left).
It's cruel to make people wait around for that long.

17:02 PM - 07 Nov 2019

1 1

Also, my home office was flooded out.

Flooded

My home office was in the basement of my house - which was the only free room in the house. It was the room where I did remote work for my clients; it was the room where I recorded podcast interviews and episodes; it was the room where I wrote my open source projects and worked on my websites.

Before the flooding, that room contained my:

desktop PC - a machine which was less than a year old
XPS 13 - a machine belonging to my company
Apple Macbook Air

It also contained all of the hardware that I use to record the shows, and all of my books.

Right now, it contains a marsh-land of a carpet, a dehumidifier, and a radiator which is working 24/7 to try and dry everything out.

I was able to rescue the XPS 13, and the majority of the desktop (SSDs are safe, but the spin rust drives are gone), but everything else is ruined.

Reflections

As I said in the edition of the newsletter that I released shortly after the event:

First, I need to apologise for the potential sombre feel to this newsletter. Secondly, let me say that no one is injured or hurt in anyway.

There were a lot of people who were more gravely affected by the recent weather - there have been reports of people having lost their lives - and I'm eternally thankful for the fact that no one I know was harmed.

I'm also incredibly thankful that I have a multi-stage backup process. This is a process that I follow when creating episodes of the podcast:

I record the episode or interview
I store the raw files on a local NAS
Those raw files are then backed up, offsite

At every step along the editing and rendering path, all data goes back through that same pathway. Meaning that, even though the majority of my drives where kaput, I still had two copies (one warm, and one cold) of all of my data.

And of course, I'm thankful that I have insurance which covers the damages. Once every thing has dried out, I will be able to have contractors in to rebuild, and I'll be able to get new hardware to replace the lost parts.

It will mean that things are a little difficult for me for the next month or so, but The Show Must Go On and it will do.

In short: GET INSURANCE!

Should I Jump Ship to iOS?

Jamie — Wed, 28 Aug 2019 06:46:34 +0000

Before we begin, I want to point out that the code of conduct applies to this post and all others on DEV. I don't expect that anyone will be particularly horrible, but I do know that many folks can get quite proud of their #gear choices.

On to the topic at hand: Should I jump ship to iOS?

I've been an Android user since Gingerbread was released, so I'm quite deeply entrenched into the ecosystem. But I feel like the lack of immidiate update support for Android, and the lack of care for privacy is really turning me off from the OS.

I'm currently using an Honor device (you care about privacy and bought a Huawei device?) and the hardware is amazing, but the base OS is terrible.

I know that I could totally buy a device which actually allows me to unlock the bootloader (Huawei have locked all of their devices down), and flash something like LineageOS onto it. In fact, until I bought my current device, this is exactly what I used to to - stock Android (as in the AOSP) is good, LineageOS with root is better, and most vendor specific builds of Android are terrible.

Security updates for Android, as some folks know, can take months (if not years) to be released for devices. And a lot of users are often left running insecure, outdated versions of the OS simply because the hardware vendors want to sell you the latest and greatest rather than support a device which is less then 9 months old - and the less said about companies like WileyFox the better.

I'm also totally aware thst iOS devices tend to become a lot less useful after 2-3 years of use, and that they're not as open as Android devices can be. I do have PC hardware which runs MacOS, Linux distros and Windows, so I'm not averse to running different OSs.

I'm really interested to hear the experiences of folks who have jumped ship (either way), and folks who have tried out both.

So fellow DEV readers, help me out. Should I jump ship? Or what are some of the things that I should be considering with reference to jumping over?

The .NET Core Podcast Episode 31 - The Liberal Arts and Levelling Up Your Career with Thomas Betts

Jamie — Mon, 12 Aug 2019 19:25:00 +0000

Hey everyone!

Episode 31 of The .NET Core Podcast was released a few days ago. But, as usual, I wanted to create some show notes for it which are specific to dev.to

As a quick reminder, The .NET Core Podcast is the only podcast devoted to:

.NET Core
ASP.NET Core
EF Core
SignalR

and not forgetting The .NET Core community, itself.

I wont make you browse over to the show notes page

because I'm not the boss of you

because I'll add a dev.to specific player here:

The Liberal Arts and Levelling Up Your Career with Thomas Betts

The .NET Core Podcast

Your browser does not support the audio element.

1x initializing... ×

This was an exceptionally wonderful conversation with Thomas Betts about the ways that you can increase your ability to communicate with your clients by studying the Liberal Arts, we also talk about the use of metaphor

I particularly love one he uses which is related to coffee shops

in getting the core idea of how the project should work across to your clients. We also talk about strategies for when your boss comes to you and says:

I've heard of this great new technology, and I want you to build our next mission critical application with it.

The full show notes and a transcription are available at the show's website

here's a link directly to the show notes

I'd love any and all feedback that you can provide on the show, this episode, or anything related to it.

Links to Related Stuff

these came directly from the show notes

Social and Stuff

If the show has been helpful in anyway, please consider giving it a rating or review in your podcatcher of choice. Services like Apple Podcasts, Stitcher, and Podchaser allow you to leave a rating or review. These help other potential listeners to find the show.

And finally, if you wish to support the show in a more direct fashion, I have created both a Patreon page (which has bonuses, but requires a monthly commitment) and a Buy me a coffee page

but I wont harp on about that

Call for Guests

We're always on the lookout for anyone who might be interested on being on the show. It's about and for the community, so if you have something cool to show off, or something you'd like to talk about, then get in touch.

I'm a .NET Core Contractor, Podcast editor, and host of both The .NET Core Podcast and The Waffling Taylors. Ask me anything!

Jamie — Thu, 08 Aug 2019 12:43:34 +0000

this is my first #ama, so please bear with me

What I'm Willing to Talk About

I'm happy to answer questions on podcasting (hosting, producing, and editing), creating content, .NET Core, and anything else that the following information inspires you to ask about.

Posting Questions

Please post any questions that you have as comments on this article.

About Me

I've been a .NET developer for close to 11 years, recently went contractor. I've been writing about .NET Core since November 2016 over at https://dotnetcore.gaprogman.com/ which, combined with my appearances on:

The Cynical Developer podcast - across four episodes
The Productivity in Tech podcast
- This was on the old show, before the recent rebrand
The Rising Young Minds blog
My posts on codeshare.co.uk on Free HTTPS Certificates and Rider from Jet Brains

lead to the creation of one of my podcasts: The .NET Core Podcast - which is celebrating it's one year anniversary this month.

I've also been writing and creating podcast episodes for a website that I run with my brother: The Waffling Taylors. We've been writing about video games since January 2017, and launched our podcast in November that same year, too.

In November 2017, I started working as a DevOps engineer for a UK-based start up consultancy. This required me to learn containerisation technologies (focusing primarily on docker) and cloud based architecture (focusing on Microsoft's Azure platform). It was during this time that I started looking into productivity tools, and I started making .NET Core Global Tools and .NET Core custom templates.

I'm an open source advocate, and have created a number of NuGet packages

that's kind of like npm packages but for .NET

which are used in a lot of projects:

OwaspHeaders.Core
- which adds OWASP recommended HTTP Headers for ASP.NET Core applications (33,456 total downloads according to NuGet)
- The source code is freely available on GitHub (used in 10 other open source projects)
ClacksMiddleware (4,054 total downloads according to NuGet)
- which adds the GNU Terry Pratchett HTTP header to ASP.NET Core applications
- The source code is freely available on GitHub

I'm also a Hack24 winner - as part of a four person team called Merge Conflicts. I also entered in 2017, as a member of Abstract Sausage Factory - although we didn't win, we had a great time.

I've also been looking into JAM Stack and static site generators like Hugo, Jekyll, and Gatsby. Which is something that I talked about on my recent appearance on the Developer Side Quests podcast.

So I invite you all to ask me anything. I'll be answering questions until around 10pm UK time.

The .NET Core Podcast Episode 30 - Reflections on .NET with Pablo Santos and Phil Haack

Jamie — Tue, 30 Jul 2019 21:12:55 +0000

Hey everyone!

Episode 30 of The .NET Core Podcast was released a few days ago. But, as usual, I wanted to create some show notes for it which are specific to dev.to

As a quick reminder, The .NET Core Podcast is the only podcast devoted to:

.NET Core
ASP.NET Core
EF Core
SignalR

and not forgetting The .NET Core community, itself.

I wont make you browse over to the show notes page

because I'm not the boss of you

because I'll add a dev.to specific player here:

Reflections on .NET with Pablo Santos and Phil Haack

The .NET Core Podcast

Your browser does not support the audio element.

1x initializing... ×

I was incredibly honoured to get the chance to interview Pablo Santos and Phil Haack in this episode about where .NET has come from, it's evolution, and where we think it might be heading.

The full show notes and a transcription are available at the show's website

here's a link directly to the show notes

I'd love any and all feedback that you can provide on the show, this episode, or anything related to it.

Links to Related Stuff

these came directly from the show notes

Social and Stuff

And finally, if you wish to support the show in a more direct fashion, I have created both a Patreon page (which has bonuses, but requires a monthly commitment) and a Buy me a coffee page

but I wont harp on about that

Call for Guests

The .NET Core Podcast Episode 29 - Developer Relations and Education with Jasmine Greenway and Cecil Phillip

Jamie — Sun, 14 Jul 2019 17:44:19 +0000

Hey everyone!

Episode 29 of The .NET Core Podcast was released a few days ago. But, as usual, I wanted to create some show notes for it which are specific to dev.to

As a quick reminder, The .NET Core Podcast is the only podcast devoted to:

.NET Core
ASP.NET Core
EF Core
SignalR

and not forgetting The .NET Core community, itself.

You don't even have to browse away from this page to listen to the episode, because it should appear here:

Developer Relations and Education with Jasmine Green and Cecil Philip

The .NET Core Podcast

Your browser does not support the audio element.

1x initializing... ×

This episode is an wonderful discussion that I had with Jasmine Greenway and Cecil Phillip about teaching and learning in the tech space, developer relations, and what Microsoft are doing to help us developers (and aspiring developers) to learn in ways which suit them.

The full show notes and a transcription are available at the show's website

here's a link directly to the show notes

I'd love any and all feedback that you can provide on the show, this episode, or anything related to it.

Links to Related Stuff

these came directly from the show notes

Social and Stuff

And finally, if you wish to support the show in a more direct fashion, I have created both a Patreon page (which has bonuses, but requires a monthly commitment) and a Buy me a coffee page

but I wont harp on about that

Call for Guests

The .NET Core Podcast Episode 28 - memstate with Robert Friberg

Jamie — Tue, 02 Jul 2019 07:02:54 +0000

Hey everyone!

Episode 28 of The .NET Core Podcast was released a few days ago, but I wanted to create some dev.to specific show notes for it. So here they are.

As a quick reminder, The .NET Core Podcast is the only podcast devoted to:

.NET Core
ASP.NET Core
EF Core
SignalR

and not forgetting The .NET Core community, itself.

You don't even have to browse away from this page to listen to the episode, because it should appear here:

memstate with Robert Friberg

The .NET Core Podcast

Your browser does not support the audio element.

1x initializing... ×

This episode is an wonderful discussion that I had with Robert Friberg about memstate, the Memory Image Pattern, and how you could be storing your entire database in RAM.

The full show notes and a transcription are available at the show's website

here's a link directly to the show notes

I'd love any and all feedback that you can provide on the show, this episode, or anything related to it.

Links to Related Stuff

these came directly from the show notes

Robert on twitter
DevRex Labs
The Cynical Developer
ACID Transactions
Memory Image Pattern
An article I've written on the Amstrad CPC 464
Prevayler
MapReduce
memstate.io
memstate on GitHub
memstate Tutorial
memstate on Gitter

Social and Stuff

And finally, if you wish to support the show in a more direct fashion, I have created both a Patreon page (which has bonuses, but requires a monthly commitment) and a Buy me a coffee page

but I wont harp on about that