This is the blog, but if you want to know more about me and my projects, check out the Projects and About pages.

2016 Security Best Practices for Collective Digital Studio Talent

With YouTubers becoming larger celebrities every year, 2016 has started off with a hacker group getting access to YouTuber’s social, financial and management account and sharing their data via their Twitter feed. This obviously has some of talent very worried. Theories were flying: “They must have cracked 2-factor authentication!” “No, I bet the MCNs are getting hacked.”

The following is a note I sent to all of our creators regarding best practices for securing their accounts and I thought it was a good summary for everyone, including and especially Collective Digital Studio talent, so I figured I would post it here on my blog to share the info and to give people a taste of how we help our awesome talent throughout the year.

CDS Creators —

The new year is always a good time to review and update the security on your various social accounts and 2016 is no different, especially with the recent attention YouTubers have received from various hacker groups. I’d like to go through a few best practices that everyone should do, but first let me assure all of you that CDS takes security very seriously and we do everything we can to ensure your private information remains private. As for the recent threat by hacker groups, let me say clearly that no one has broken 2-factor authentication nor is there any evidence that they have hacked any MCN. It is clear, however, that they have successfully hacked many individual accounts for various MCN dashboards and social accounts like Instagram and even PayPal. To protect your accounts from hacks like that here are four things you can do right now to make yourself a harder target:

Always use 2-factor authentication.

2-Factor authentication, where your phone is required when logging in to a new computer, can be annoying at first but it is the best way to protect against people getting access to your account. Passwords can be guessed, or someone might just accidentally give it to them (though, we at CDS keep your password so secure that we don’t even know it). In those cases, a hacker still couldn’t access your account unless he also had your phone.

2-Factor Authentication is available on your Google account, but also Twitter and Facebook. We strongly recommend you use it wherever available.

Change your password regularly.

You should rotate your password at least once a year and the start of a new year is a great way to easily get in the habit. Be sure to use a secure password that is ideally not just a word and is long enough to make guessing difficult. There are several good password generators out there if you need help generating a secure password:

Use a different password for each site.

I know. This might sound like a huge pain, but having a different password for each site is a great way to make your online life more secure. This is important because if someone does get access to one of your accounts, they won’t immediately be able to try the same password on everything else you use.

Password management software can be a big help with this one (as well as #2) and there are really good free options available, like Last Pass:

Review which apps and sites have access to your accounts.

Another way for people to gain access to your data without the need of a password is to simply ask for it. It’s true! Think of every app you sign in with Google, Facebook, or Twitter asks your permission for different parts of your account data. That’s usually a good thing and makes the apps useful, but even good apps can become bad partners and it’s important that you know who else can see your data or post to your accounts. Luckily each major provider supplies lists for you to see which apps you’ve approved and give you the chance to remove them. We strongly suggest that you review these list regularly, especially if you think something weird is happening on your accounts.

Google / YouTube



Thanks for taking a moment to talk about something that may not be as exciting as the great content you all produce every day, but is critical to ensure your content and earnings are safe. If you have any questions about this or anything else related to security, please reach out to your talent manager and we’ll do our best to get you an answer as soon as possible.

Mike Flynn, Chief Technology Officer @ Collective Digital Studio

Building Lego WALL-E

This Hotel is Awesome Thumb

I got a Lego WALL-E for Christmas and I’m not sure there’s ever been a better use for time lapse than watching me in my basement workshop play with Legos on a Saturday night.

How to Deploy Wordpress without Murderous Rage

Wordpress Logo

Wordpress. Ugh. Arrg! The Windows 98 of the internet! The thing that everyone thinks they’re an expert on because they used to run a blog a few years back on it (now they use Medium) and they had this great FTP client they used…they can’t remember the name…but it was great…uploaded a ton of plugins…oh, do you know about the W3 Total Cache? It’s super important. Blah blah blah.

I dislike Wordpress. I understand why it’s popular. I understand when it’s a good tool to use. I even understand why it’s a great tool to use for people with a single webserver from Dreamhost that want to share pictures of their kids and this amazing lunch place by their office…but I still dislike it. My dislike comes from having to run multiple Wordpress servers for lots of little disconnected brands. Some of the sites get traffic, others don’t, but we run them all on a small cluster of web servers, with each site (ideally) running on at least two servers. We don’t want to run the security risk of FTP, and even if we did, we can’t allow users writing directly to the servers because of the load balancing. Wordpress is terrible at this…or should I say, we as a tech team, were terrible at finding a way to make Wordpress work like this.

The primary issues we had with Wordpress were, in no particular order:


We used to keep a repo for each of these Wordpress sites. In that repo was a full copy of Wordpress with their theme (sometimes custom, sometime off the Theme Forest shelf), and a copy of all the plugins they needed. In reality this isn’t really development. Maybe we were tweaking a theme, but the vast majority of what was happening in the repo was pushing in new plugin code or updating the theme or Wordpress itself by cping in tons of files.


Deployment consisted of cloning the repo to the deploy server and syncing out the files. It was assumed that the developer making the change must have ran the Wordpress site locally and activated any plugins that write files to the system first and committed those new files to the repo.

Preventing Writes to the Server

Every time we started a new site we would send out an email to the team that reminded everyone to not install plugins or use the Wordpress code editor to change anything as that would break the site…and then a few weeks later when the team’s “Wordpress Ninja” (aka the intern) tried to make a “super small tweak” for them “super quick” and it broke the site, I would send the email again. Maybe this time I would put certain lines in a bold type face.

…but that was in the past. Now we don’t have these problems! Lets discuss.


Most of our research pointed to using Docker, which sounds good and we might get there, but for now that felt like more of an infrastructure change than we had the time and inclination to do. Instead we settled on a classic solution: make Setting up a simple Makefile for Wordpress allowed us to store only the essential pieces of each site: a few lines of configuration, the theme, and a few specific plugins. Everything else is blown away, downloaded, and copied in to place on deployment. We have several sites using this, so we have a .mk file that holds the common functionality and is included in to each of the sites’ local Makefiles. Here’s an example of a site Makefile and the global file

You can see in the first site-level Makefile, we’re just defining the specifics for this site. We configure the site with temp (or local development) DB configuration via wp-cli (which is installed as a part of the included global Makefile), install the theme that lives in the site’s directory as a zip file and then a series of plugins. In this case, we are installing a few plugins we use to have the media files live on S3.

In the global file you can see all the real work. Blowing away the wordpress directory, downloading a fresh copy of the latest Wordpress, looking for a content.xml file to auto-import and installing wp-cli. There are two quirks to this setup that are worth calling attention to: 1. We don’t use wp-cli to add the plugin files. The reason is that it requires a DB connection to activate the plugin and we don’t want this to expect a DB connection as we’re just building the filesystem to sync out. Instead we simply copy the plugins and themes in to place and worry about activating them when the site is in place in production. 2. You’ll notice that the make deploy command applies a patch to the wp-config.php file. wp-cli has a great function where you can throw arbitrary PHP in to the wp-config.php, which we were using but we also need to modify the structure of the DB configuration (we have the site look for environmental variables for the DB connection data) so we have to do this patch workaround to accomplish both.

As for our #3 problem, we found the solution after going deeper in the Google search results than I think I’ve ever had to. It turns out that Wordpress supports the following configuration flags:


Setting those two flags to true removes the plugin installation and file editing UI from the admin. We did see some issues when activating a theme or a new site installation when those config options on, but we were able to get the site setup and then reapply the config options.

We converted our Wordpress sites repos to the Makefile structure a few weeks ago and the change has been significant. Simple tasks like adding a new plugin is now actually simple as all it involves is adding a couple of lines to the Makefile. Upgrading Wordpress is even easier as it simply requires a deployment.

Wordpress(.org) still just isn’t designed to work well enough in a multi-server environment but with the Makefile and a few tweaks we’ve been able to fix a huge headache…or at least downgrade it to a small headache and allowed us to shift focus back to the fun stuff we do at Collective Digital Studio: Clojure, Big Data, Node, Video Distribution, React, …

The Orange Dog Thing

I’m fortunate that I get the chance to do some occasional (and not so occasional) traveling for work, mostly to Los Angeles. Recently I had the chance to stay at the Andaz Hotel in West Hollywood, which has a storied history in rock and roll, but now they just include these orange dog-like things in every hotel room. There’s zero chance I notice somethign like that and not figure out something weird to do with it…so I took the dog and make a little Instagram story with it over the three nights I stayed at the Andaz.

First encounter with ODT

ODT blocks the TV

ODT drinks from toilet

ODT wants to come too

ODT likes to be scratched

ODT wakes me up

ODT drinks from sink


No, ODT, stay here.

ODT: The End

Reaction on my Facebook (mostly family and closer friends) was mixed. Instagram didn’t care that much as I don’t have many followers, but Twitter (mostly people I don’t know) seemed to enjoy it. Not sure if picture storytelling via Instagram is something I’ll dabble in again, but it was a fun experiment even if I have to deal with people asking my why I didn’t buy the dog to take home with me (it was $250 and a bit like this had a 3 day shelf-life).

Over the Moon Pie

Over the Moonpie Video

The family went to Charleston, South Carolina for Thanksgiving and swung by the Downtown Market and the Moon Pie General Store.

mikeflynn @ GitHub thatmikeflynn @ Twitter