DEV Community: RJJ Software

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.

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.

Take a Vacation!

Jamie — Tue, 04 Jun 2019 05:34:38 +0000

You know the situation: the project is chugging along nicely, the sprint is going well, QA hasn't failed anything in weeks, you have 75% (or higher) code coverage in your unit tests, and it looks like it'll be delivered on time.

Productivity couldn't be higher. In fact, you can often be seen reclining in your chair with your feet on your desk.

The project is three weeks behind, you can't seem to write code fast enough for QA to test, you haven't got any unit tests, and the project manager is screaming at you about how it's all your fault.

psst - buy your favourite PM three copies of The Mythical Man-Month. They should be able to read it three times as fast, right?

Everything is getting quite stressful, and you're not getting enough sleep. You don't know what to do, and you are concerned that the project won't make its deadline.

both of these are a little hyperbole mixed with past experience

It doesn't matter which of these two people you are, or whether you are a combination of the two, you still need to figure out when to take a vacation.

But Jamie, They Need Me!

What did they do before you got there? And what will they do when you make yourself sick from overwork?

Seriously, they'll be fine. They're all adults... probably. And can take care of themselves and the code until you get back. If it truly is a team effort, then there is no "most important person on the team".

we all know that last part isn't true, even if your workplace claims to have a "team effort" mentality

And even if they do need you, they need a relaxed you who can get the work done; not a super stressed out version of you who is hunched over, muttering under their breath, rocking back and forth, with two attendees on stand-by ready to give you a sedative and take you to the place with the comfy walls.

If you're stressed, then you'll be horrible to everyone who is willing to try and talk to you. You'll be like an angry dog, barking at everyone. No one will want to talk to you, and everyone will give you a wide berth.

That is if you're well enough to come into work.

Ok, I'll go. But I'll be checking my emails

No, you won't.

I recently spent two weeks in Japan

Fukuoka, Nagasaki, and Hirado

and although I rented a mobile 4G WiFi hotspot, it was there so that the group I was in could use Google Maps and could send messages to some of our Japanese friends (arranging meeting up, etc.) and each other (in case they got lost).

Aside from the daily backup of the photos that I'd taken - and sending the odd message to my folks to let them know that I was ok - I was completely disconnected from the network. Like, I'd even removed all social and email apps from my phone

I ended up not wanting to set them up again when I got home

Being disconnected allowed me to be totally in the moment whilst I was there. Being in the moment allowed me to rest, or to take in things that I wouldn't have seen because I'd have been running around taking photos of everything

I ended up taking very few photos whilst I was out there, actually

I was isolated from the folks that I work with, and guess what:

The code was still there when I got back. In fact, very little of the code that I was maintaining had changed. There was only one change, that I could see, and that was to an HTTP retry policy.

I walked away from the code for 14 days and came back to find that everything was fine.

But What If...

No.

Delegate.

Before you go on vacation, make sure that someone knows what you do on a daily basis and that they know where to find documentation on the things they'll need to know

and make sure to write this before you go

Pick a number of colleagues, and spread the knowledge between them evenly. That way, even if you fall foul to the dreaded bus factor, there are enough people who know what you do and can carry on whilst you heal up.

Plus, this has the added bonus of making everyone in the team a little bit smarter about the entire codebase, and it stops you from becoming a Brent

seriously, go read The Phoenix Project

Once you've done that, you can go rest. You don't need to disconnect from the network (and I wouldn't recommend going cold turkey anyway) and expect to have calls from your colleagues.

Feel free to take those calls, but make a point of telling the person who is calling that you're not going to be on the line for long and that you are busy with other things.

Give them a few moments of your time if you want - you never know, you might help someone by letting them explain a problem to you - but make sure that they know you aren't going to be available for longer than a few minutes. Tell them to give you the elevator pitch rather than the intimate details.

If they email

and you are somehow checking - which you shouldn't be doing

reply with something like:

Thank you for your email. I'm currently on vacation/annual leave and will get back to you when I'm back in the office. I am due to be back on the following date:

Be less formal if you want, but the key point is to let the person know that you aren't available right now.

also, enable out of office auto-responses for your emails

In Summary:

Take a vacation
The code will still be there
Other people are working on it
- Hopefully
And they are intelligent people
- Hopefully
And will be able to figure everything out in your absence
- Hopefully
Take calls from people, but make sure that they know you have a hard stop time
- Around 2-5 minutes
Don't check email
- But if you do, reply with "On vacay; drinking mojitos by the pool; can't help"
  - or similar
Rest, relax, sleep, chill
You are at your best when you're relaxed. That should be the goal of the vacation.

Securing a Webapp - Step 0: An Introduction

Jamie — Tue, 21 May 2019 13:57:53 +0000

The cover images for this post is by Alvaro Reyes

I've had an idea for a series floating around in my head for a while

baking security into a new website, as soon as a client approaches me

I even ended up rubber ducking this idea in a recent comment thread:

Jamie • May 21 '19

I've use Feedify and QR Codes in one post (shortly before the first instance of MageCart), a discussion on OWASP, and how it could ruin your company or brand as examples about why folks should look into this in the past. Especially since it's a relatively easy problem to solve.

I feel like you could make it into a series of posts. Even as someone who knows this stuff and how to implement it, I'd love to read a series where the author goes from "here's the theory" through "here's my initial plan", to "here's why my assumptions were wrong" (because with CSP, they will be) to "here's the finished headers for my site".

A lot of folks who write about headers tend to focus on the first and last step here, but devs need to know that the middle part is hard. Maybe you could cover that, or nominate someone to do so. Maybe I'll take a whack at it with an app for one of my clients 😉

Those who have been keeping up with my writing will know that I've written about this topic before, but always from a more theoretical view:

But in this series, I'll be taking you through the whole process. From no webapp all the way up to a webapp with security headers, with everything in between.

But Why?

Aside from the fact that I do this for every webapp that I create, I've noticed that almost no one who talks about these things covers the middle step - which is the pain that you feel when the CSP still doesn't work, or when the marketing person wants to add an insecure feature to the site without checking with you first (which is the most likely thing).

Seriously, you'll probably spend the most time trying to figure out where all of your disperate JS and frames are loading in from, and will be scratching your head as to why these things are being loaded in. In that way, creating a CSP alone can help with performing a sort of spring clean on your application, but we'll get to that in a later post.

What Can You Expect From This Series?

I'd say that you can expect practical advice for implementing recommended security headers into your web application, by example.

Exactly how you add these headers will differ, depending on which technology you're building your webapp with. So I won't spend much time on actually how to add them to your app (though most technologies offer a similar approach).

I'm going to be building a real app, for a real client of mine, and will document the process. I'll also link to a dev.to specific build of the app, as I'm building it, so that you can all see it being built up.

(I'll also provide the source code)

So stick around, watch this space, and you might learn a few things - hopefully.

Giving Talks at Meetups

Jamie — Fri, 26 Apr 2019 18:08:47 +0000

In a recent (ish) Tweet, we asked:

// Detect dark theme var iframe = document.getElementById('tweet-1111397254722654208-372'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1111397254722654208&theme=dark" }

The options where:

DevOps
Setting Expectations
Learning New Technologies
Giving Talks at Meetups

Hopefully, you can guess which way the Twitter-verse voted.

An Intro To Giving Talks

Giving talks isn't for everyone. Some folks just don't feel comfortable standing in front of a room full of people and talking about a technical subject. In fact, even the folks who do it as part of their jobs find it scary.

What I'm getting at, is that it might not be for you. But there's no way to know unless you try it.

is that irony or dichotomy?

So how do you try it? I can only say what worked for me: I gave a talk on docker, at a local (to me) WordPress meetup.

I spent a long time creating crafting a slide deck and examples which I thought would show off docker in a really cool way. It had a lot of big examples showing things like, how I could scale a site, how I could run a production-like environment on my machine for pen testing, and how I could use k8s to spin up a self-healing mesh of servers.

Then I ditched it all and started again with a new direction:

Docker is magic

I borrowed a magician's top hat, learnt a magic trick, and created a new set of slides. The new slides and examples where all about pointing out how I didn't need to know how the docker internals work in order to use it.

I did this because I was presenting to a WordPress user group consisting of a handful of devs, a number of designers, and a room full of writers. Why should they need to know about how docker works in order to get a installation of WordPress running on their local machine?

setting up all of the moving pieces required for WordPress can be quite difficult for some users

Luckily for me, when it came to the day that I gave my talk, only about 10 people showed up. That was fine with me - it was my first public talk.

Prior to this, I'd given lightning talks at my (then) workplace.

Lightning Talks

Usually a lightning talk is a 5 to 15 minute talk on a very specific subject. Maybe something like:

Using Linq's Where method to filter a list of objects
JavaScript's map function and what it does
What are HTTP headers?
A quick and dirty instruction to Map-Reduce

The point is that you're focusing on one specific thing, and presenting enough information for your audience to get the gist of what it's about. It's not a super detailed, 45 minute talk with examples, and explanations. Heck, you might not even have slides.

Linq's Where method can filter an ICollection<T> of objects down by passing in a lambda which represents a filter function.
A common example would be getting all Users with a birthday in March 1992. One way to achieve this would be to...

For example.

I'd given lightning talks on .NET Core (back in mid 2016); Content Security Policy; Visual Studio vs Visual Studio Code vs Rider; and Blazor before I'd decided to tackle a meetup.

But I'm No Expert

You don't need to be, you just need to have a story to tell. Did you recently implement something cool in a project? Have you recently changed technology stack? What about some new technology stack which has just come out? Have you got an application that you're super proud of?

I interviewed Steve Gordon on episode 13 of The .NET Core Podcast

you can listen to it here

about giving talks and here's what he had to say about not being an expert:

You don't have to have a deep a deep technical expertise in any one particular subject, I certainly don't consider myself an expert. I just share a story, that's what I've done with most of the talks that I've given so far:

This is the problem we were facing

This is what we decided to do

This is what worked

This is what didn't, or what we would do differently That kind of thing. Because no one can really challenge that kind of talk, so don't worry about people telling you that you're wrong, because it's your experience and your opinion on what you did and didn't do right

And he's absolutely right.

Some of my favourite meetup and conference talks haven't been "I'm an expert on this thing, and I'm going to convince you to use this thing in all of your projects from now on" type talks. My favourites have always been the "here is what we tried to do, this is what we tried to do it with, here's how we got on, and this is what we would do differently" type talks.

Why? Because they teach you the most, but also because they are a real story: you can see how someone has grown as a result of taking that journey.

What Should You Talk About?

I'm drafting this after giving a 30 minute talk covering some of the highlights of the history of .NET

it's one of my many open source talks which you can clone here

I really like to learn about how and why we got to where we are now, so I collected a bunch of information about the creation of the .NET Framework, the maturation of it, and how we got .NET Core from it.

it helps that I've interviewed Richard Campbell about it in the past

But you could totally do something similar to my .NET IDEs talk, which simply talks about the differences and similarities between Visual Studio, Visual Studio Code, and Rider.

Or you could deliver a talk about your first dev job, or what attending a coding bootcamp was like. You could create an application and talk about how you did it. Or you could learn some theory and talk about it, with some live demos*

(* pro tip: never do a live demo)

Finding Somewhere To Speak

Start small. Like, a local meetup or ask if you can give a lightning talk where you work. You could even ask a bunch of developer friends if they wouldn't mind if you practised for a non-existent conference or talk by giving the talk in front of them.

If you are part of a local user group, try to find out if they'll let you give a short talk (but let them know that it's you are quite new to it). One developer meetup that I go to a lot - Leeds Sharp - often has lightning talk evenings: where anyone can get up and give a 5 to 15 minute talk on anything. These are great because you're only in front of everyone for 5 or 15 minutes, so you don't have to prepare too much stuff. Plus, it's a super supportive atmosphere at Leeds Sharp.

Once you've figured out where, and you have the what, you'll probably have to submit a title or an abstract. Abstracts are usually only needed for conferences, but it'll be handy to have a few sentences about your talk. You don't need to say much, just:

What your talk is about
Who the intended audience would be
Whether there are any live demos
What technology stack you'll be using
How long it should take to deliver

Delivering The Talk

Get to the venue early. The last thing you want is to be running late. In fact, you might not even be allowed to deliver your talk if you are late. So plan your route ahead of time.

Make sure that you have everything you need. Do you need an HDMI cable? How about an adapter for your mini display port? Do you need speakers? Have you charged your laptop? Have you got a USB drive with your slide deck in case something goes drastically wrong?

Don't do anything complicated in your talk. Remember KISS: Keep It Simple Stupid. You're going to be juggling a slide deck, keeping everyone's attention, telling an entertaining and captivating story, running live demos, speaking loud enough such that everyone can hear you, and engaging with the audience. You don't want everything to go horribly wrong, because you forgot to get that one meme image before you started, or because you forgot that one command you needed to run.

Have a way of resetting your presentation environment. This is especially handy if you're going to be giving live demos; this way you can push a button and reset things, should something go wrong. It also means that you can practise the live demos whilst you are waiting for your queue, and don't need to panic when resetting everything.

Remember to breathe. Delivering a talk can be nerve wracking and, when stressed, some people breath less or in a more shallow way than normal. Just breathe. Take an in breath, wait for a second, then exhale. Stay calm, and you'll be fine. No one is going to be angry or upset, if you need to take a second.

Please don't just read your slides aloud. The slides are there as a prompt for you to talk about something. They don't want to be paragraphs of text; they do want to be bullet points. Full sentences are OK, but paragraphs aren't - unless you're showing a quote.

Don't worry if you get lost or forget what to say. Take a moment to breathe and re-centre. Also, don't be afraid to skip a point, or a slide. Even the best folks skip over bits when they can't remember what to say.

Don't worry if the live demo fails. Live demos are harder to get right than anything else, so don't be upset if they don't work. Simply explain what should have happened, and offer to show people after your done giving the talk. You'll probably find that someone figured out why, but didn't want to shout out and interrupt your flow - they'll let you know after the talk.

And most important: have fun.

In Summary

It can be incredibly scary to think about standing in front of a room full of people, but the benefits can greatly out the cost. I'm not going to lie, the prospect of giving a talk to a room full of strangers had my frightened. But after I got through the first talk, I found that I had rekindled a passion that I hadn't felt since I was a teacher: "showing off something that I thought was cool"

which was the approach I took to teaching - which is a story for another day

Hopefully I'll see you all on the conference circuit; in front of, or as part of a crowd.

Security For Your Web Apps - And Why It's Important

Jamie — Sun, 10 Mar 2019 09:46:42 +0000

Your company's web applications are the gateway for your customers.

Gone are the days when someone would browse through Amazon, pick an item, call Jeff Bezos directly, give him their credit card details over the phone, and expect their product within 2-4 weeks. Almost everything is done online.

Almost none of your customers will travel to your head office; very few (if any) will ever call your publicly listed phone number; a handful of them will make it as far as emailing you; a small percentage of them will use an online-chat system (if you provide one); but all of your customers will use your web applications.

Hackers Abound

I personally don't like to use the phrase hackers, but that's because I prefer the old meaning of the term:

Someone who doesn't use engineering processes when creating code. They "hack around in the code base, removing code blindly, trying to make it work"

But if the shoe fits...

Sure, a lot of hackers these days will launch complicated attacks against your servers - and that's still a legitimate concern. But with services like Azure, AWS, and GCP, it's getting harder for malicious folks to break into your infrastructure.

NOTE

My previous statement assumes that the infrastructure is set up with security best practises in mind. i.e. no VMs (WebApps or serverless architecture), service principals rather than usernames and passwords, multi-factor authentication, applying the principle of least privilege

There have always been attacks against the client (in this case the Browser), but they are slowly becoming more prevalent. A lot of folks get started in this arena by utilising Google dorking techniques, they then move on to the techniques used by Script Kiddies. These are simple techniques that you can just copy and paste without having to understand what they do.

In fact, it's so easy to do that Troy Hunt had his (then) 3 year old son perform a SQL injection attack, on camera.

These techniques can be pared up with the results of a quick search on Shodan to launch attacks on vulnerable systems.

Pro tip:

Have someone within your organisation do frequent searches on Shodan to ensure that you haven't opened any potential gateways into your applications or infrastructure.

If you don't, someone malicious will.

Security As a Feature

Oh so frequently, we (at RJJ) have seen that security is thrown in as a last minute feature. This can be, and is often, disastrous.

We've seen cases of applications where security is added as an afterthought, yet breaking into the system was child's play (see my earlier comment about how easy it is do use Script Kiddie techniques).

This leads to security teams becoming the nemeses of development teams. But, just as with Dev and Ops, we all need to be working together to ensure that the applications we built are secure from the off. For allegorical proof of this, I'd recommend reading The Phoenix Project.

The most secure applications - just like the most secure buildings - have security baked into their designs from the very beginning. This allows us to include security checks as part of our automated test suite.

you ARE using automated testing, right?

This ensures that no one is able to release a "quick fix, will improve security later" (that's an actual commit message that I've seen in the past, by the way), because it won't get past the automated tests.

But doing this is hard. Which is why "DevSecOps" is now a legitimate career path for folks who want to increase the security of applications. The problem is that there's so much to learn, and almost no time to learn it, right?

Free Tools

I've written about OWASP before. In their own words:

The Open Web Application Security Project (OWASP) is a 501(c)(3) worldwide not-for-profit charitable organization focused on improving the security of software. Our mission is to make software security visible, so that individuals and organizations are able to make informed decisions. OWASP is in a unique position to provide impartial, practical information about AppSec to individuals, corporations, universities, government agencies, and other organizations worldwide. Operating as a community of like-minded professionals, OWASP issues software tools and knowledge-based documentation on application security

Everything that they do (aside from conferences like Global Appsec) is free. Free training materials, free meetups, free software tools, free knowledge sharing.

by "free" I mean "free as in beer, a.k.a: no remuneration required

Not just that, there are conferences and meetups all about application security. There are courses you can take, and there are books that you can buy. You can even try to become a l33t hax0r yourself by using things like Kali Linux

Kali is a distribution of a Linux based operating system which is designed for penetration testers and white-hat hackers

The problem is that learning how to beat the malicious folks requires a tonne of learning. Sure, it's all free information, but there's a lot of it and it can take a lot of effort to learn it. But you can learn it piecemeal.

You Company's Applications ARE Its Reputation

Imagine if Amazon suffered a massive security breach. Like, lets say that all of orders for a 6 month period for all of their customers were leaked. We're talking names, addresses, credit card numbers, order line items (the stuff that people ordered), everything.

I'm not saying this has happened, I'm just trying to craft an example

Aside from the initial fallout of everyone's data being available to malicious people, and the potential embarrassment some people might have about their shopping habits become public knowledge

seriously, have you ever bought something that would be difficult to explain to a loved one, let alone a friend, stranger, or even your employer?

Aside from all of that, Amazon's reputation would be trashed. They would be dragged through the mud by the media and would have to work exceptionally hard to spin the story in their favour.

Not only that, AWS is an Amazon product. There are millions (if not billions) of people who rely on AWS on a daily basis - even if they don't know it. If Amazon was breached, AWS would be next. Companies like Capital One, BP, GE, Time, and Philips would be hit. Not to mention AWS's killer app: Netflix.

Imagine if your company was successfully attacked, and all of your customer data stolen. Would it survive the PR nightmare?

And that doesn't even touch on things like GDPR, and other sets of regulations that you need to abide by. Imagine if your company had to defend itself against against a GDPR strike. There's no coming back from that, no matter how good your products are services are. You customers would leave.

That's why application security is so important to your company. At least, from a business owner's perspective.