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

This is How You Comedy Hack Day

We can all talk about my Comedy Hack Day 10 / Sketchfest later, but for now lets check out this git log from this weekend. This is how you Comedy Hack Day!

image

An Ode to My Work Laptop

When my laptop and I first met

I started at Collective Digital Studio in 2012 as the month of December awoke from it’s yearly slumber. I was handed a computer. A Macbook Pro Retina. That Retina part was new, as was how thin and light it was. Instantly I realized it was the best computer I had ever used. That computer has been with me every day since then, and it died today. A little piece of me did too.

My Macbook Pro lived a hard life. I asked a lot from it. Not “a lot” in the sense that I managed to tax any part of it’s excessive specs, as I’m a developer and I just edit text files all day, but I brought it everywhere. It was thrown in countless bags, eaten over for countless meals (but never spilled on), taken out at countless TSA checkpoints, and even sat on a couple of times. It was a tray, it was a paper weight, and it was a way to block my face while I laughed at some guy from a different company farting during a sales presentation at my office. Oh, and I worked on it. Tons of times. I coded the first version of the API we use at Collective Digital Studio, typed out a ton of emails, and planned the reboot of the tech team we had in 2012 in to the amazing tech team we have today.

It Facetime’d with me. It Hangout’d with me. It brew install‘d with me. It XCode’d with me. It Sublime Text’d with me. It “I’m Googling that because there is no way a piece of software is actually named…oh, it’s a Node.js thing”‘d with me. We saw Google IOs, f8s, Clojure/Wests, and Variety Big Data conferences. We watched a lot of YouTube. We wrote a bunch of code that hopefully helped make YouTube a better place.

I’ll miss you buddy. You died in a really weird way where you just kept restarting all the time which was super frustrating…and you’re a huge asshole for dying a month or two before the next model of Macbook Pros will be announced, but that’s OK. The intern was using a computer just like you and I took his and imaged it with my backup. Once I put my cover on it will be just like you didn’t die at all. My stickers will even be back! Ok, I gotta make up all the time from yesterday when I was yelling at you and then replacing the intern’s files with my files…but you were a good friend so I’m going to write “broken” on a Post-It Note and leave you in this cabinet. A fitting tribute! Maybe one day we’ll get you repaired, or maybe one day someone will throw this cabinet away and forget to open it first, but either way you should know that I loved you.

Shit.

Which one of these was the broken one?

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: passwordsgenerator.net

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: https://lastpass.com/

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

Twitter

Facebook

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:

Development

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

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.

Solutions

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 wordpress.mk 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 wordpress.mk 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:

define('DISALLOW_FILE_EDIT',true);
define('DISALLOW_FILE_MODS',true);

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, …

mikeflynn @ GitHub thatmikeflynn @ Twitter