Browsing movies on Netflix the other day I found myself wishing they still had a ‘Watch Trailer’ button. Now the easy solution would be to look for an existing Chrome extension that added it; unfortunately this didn’t occur to me so I decided to make my own. Follow along and learn how to make a simple extension that adds a ‘Watch Trailer’ button to Netflix movie and TV show details pages. Let me preface everything by reminding you I’m a UX guy, so the quality of the code can best be described as ‘it works’.
You can organize your extension into subfolders as well, but for this case it’s pretty simple so we’ll just throw everything in. First we need a manifest.json which will tell Chrome a few things about our extension:
To make sure it’s working we’ll just show an alert. Also we’re wrapping the whole thing in a IIFE as recommended by Bryan, one of the real developers here.
So, now we need to actually test the thing. Go to chrome://extensions
You’ll see a checkbox in the upper right labeled ‘Developer Mode’, check that and you’ll see a few buttons appear. Click ‘Load unpacked extension…’ and find the directory we created earlier. Tada! Your extension is now loaded. When you go to a Netflix detail page, you should see the alert pop up. Anywhere else, including the Netflix home and category pages you shouldn’t see it.
Now we can get started with everything else. We’ll want our plugin to do a few things:
- Add a button to the page that says ‘Watch trailer’
- Extract the movie or TV show info, including title and year, from the page.
- When the button is clicked, use the YouTube API to find a match and embed that video on the page.
Adding the button
This is pretty easy. Using the Chrome DevTools we can find the class of the div that holds the other action buttons on the page. We just want to add our own button in that matches those.
Here we’re appending some HTML to the ‘actions’ div. By duplicating all of Netflix classes we can make sure it matches the other buttons in style. We also add an id of ‘watch-trailer’ which we’ll target later for the click action. Now that we’ve made a change in contentscript.js, we need to reload the extension. On chrome://extensions refresh the page, now refresh the Netflix detail page and you should see the button!
Get the movie info
Now that we’ve got a button we need the information about the show or movie. By using inspect element again we can see that Netflix has some nicely named elements: an h1 with class ‘title’ and a span with class ‘year’. We have to be more tricky to determine if it’s a movie or TV show. Down in the right sidebar by the reviews there’s a header that says ‘Movie Details’ on movies and ‘Show Details’ on shows. We’ll use that to grab it’s type.
In this function we just create an object and grab the info from the page. In the case of type we strip out the ‘Details’ text from the string. Now we can just call this function whenever we need any of these pieces of data.
Getting the trailer from YouTube
Now we need to find the trailer on YouTube. You’ll need an API key, that’s a whole process you can find instructions for here. What we want to do is use the search to find a match using the information we extracted from the page. Let’s just test it out by logging to the console.
Now when the button is clicked, we combine the title and the year to create a search query and pass that to our function. Using jQuery’s getJSON we grab the results from YouTube and log them. You’ll notice some parameters in the query URL, namely: maxResults=1 (because we only need one result), type=video (because we don’t want to get users and playlists) and videoEmbeddable=true (because we need to embed it). Now when we click the button and pop open the console we should see the data we got back from YouTube:
The important bit here is the ‘videoID’ if we paste that into a YouTube URL we’ll see the video the search returned https://www.youtube.com/watch?v=eajuMYNYtuY Cool! Let’s embed that on the page now.
Now we’re grabbing the videoID from the search results and appending the YouTube embed code to the page just like we did the button earlier. Also after the video we’ll include a link to search YouTube for the query in a new window in case we showed an incorrect match. Test it out and you should see a trailer appear on the page when you click the button.
Now we’re almost done and are ready for some finishing touches:
- If the video is already embedded when the button is clicked, we’ll remove it.
- We’ll make our search queries a little bit smarter.
For the first item, since we wrapped the video in a div with id ‘yt-trailer’ we can just check if that exists, and if it does, we remove it. Otherwise we proceed with appending the video on the page.
The second required a bit of trial and error to find what worked best. Since we know if it’s a show or movie we can do the following:
- If it’s a movie the query can be: moviename + movieyear +’trailer’
- If it’s a tv show the query can be showname + ‘season 1 trailer’
Actually publishing to the Chrome Web Store is as easy as uploading a zip to the Chrome Developer Dashboard
You can install the finished extension from the Chrome Web Store.
Say you have a responsive website design that very image intensive, as I did recently. You want to ensure the clients images come across clear and sharp on all devices, but you don’t want to have to worry about mobile devices needlessly loading in larger versions of the image that they won’t end up displaying.
Given the slow pace of modern browser adoptation, it will be years before we’re able to widely support to the proposed
srcset solutions. But here’s a quick look at how these they will work.
The picture element wraps a list of one or more
<source> elements declaring a media query and a srcset.
The comma seperated list in the srcset attribute indicates the name of the file to load depending on the pixel density ratio of the display: `large.jpg` for normal screens, `large-@2x` for Retina displays. Below the `source` elements is a fallback image. With this markup, we can expect the following behavior:
- Mobile devices would load small.jpg
- Screens larger than 600px load large.jpg,
- Screens larger than 600px with a screen pixel density ratio of more than 2.0 would load email@example.com
- Devices that do not support the picture element will load the small.jpg image by default.
Luckily, through a combination of polyfills, we can reproduce rough the same effect.
<picture> element for use in the here and now and Version 1,
<span> elements and custom data attributes to accomplish the same behavior. Here’s what Picturefill 1.0 looks like in action.
A lot of my work at Doejo involves building sites on WordPress. Naturally, clients tend to manage these sites on their own after launch and it’s impractical to expect them to upload both a normal and Hi-DPI version of each image they upload in the Media Uploaded.
To assist in the process, I like to install WP Retina 2x. This plugin will generate both versions of on an image in each of the themes specified image sizes, when provided with a quality high resolution source image. WP Retina gives you several options for configuration and my preference is to use the Retina.js option. Retina.js will determine if a visitor is using a Hi-DPI device and if so, will attempt to load Hi-DPI version of each image, assuming they’re named with the standard ‘-@2x’ suffix convention.
So what does that mean? It means we can leave off the redundant data-src
<span>s for the Hi-DPI images and get a much cleaner, DRY-er code block.
Now, let’s throw in some WordPress.
Welcome to Terminal Tips, a series where we’ll be sharing some shortcuts and tricks we’ve picked up along the way as we use the command line. Today’s post covers a command that is more frequently associated with a text editor than the command line: “Find and Replace”. If you need to do a find and replace on a file, especially a large file, it becomes cumbersome to do so in a text editor. Github’s new editor, Atom, won’t let you open files larger than 2MB as of the time of this post.
So let’s say you have a CSV file with a couple hundred thousand rows and you want to change any occurrences of the string ‘old’ to the string ‘new’. You could do this using a word processor or an editor, but it would likely crash before you even got the file open, or it would take forever to actually perform the find and replace. What you need is something that gets the job done without all the overhead of an editor. This is where sed comes in. A quick look at the manual for sed tells us:
The sed utility reads the specified files, or the standard input if no files are specified, modifying the input as specified by a list of commands.
(If you want to read more, open up the Terminal and run the command ‘man sed’ without the quotes)
So now that we know what we’re working with, let’s start to construct our command.
From the man page, the -i flag edits files in place, allowing you to specify a backup. If you’re not concerned about running out of disk space this isn’t absolutely necessary, so we’ll just leave that blank for now. Our command now looks like:
sed -i ''
Now we actually have to specify the text we want to find and replace. If we want to replace the word old with the word new, we need to construct a suitable expression to tell sed what it is looking for:
From the manual, the -e flag will “Append the editing commands specified by the command argument to the list of commands.” Sounds perfect. Our command now looks like this:
sed -i '' -e 's/old/new/g'
Now all we have to is specify the path to the file you want to run the command on. If we had a CSV file called list.csv in our current directory, we could just append that to the command. Now we have:
sed -i '' -e 's/old/new/g' list.csv
When we run this command and go look in the file, we can see that all instances of ‘old’ have been replaced with ‘new’ and you’ve learned a new shell command!
What if you wanted to find and replace a URL? You can’t use a slash as the seperator character, because there will most likely be slashes in your URL. sed uses whatever follows the ‘s’ in the regular expression as the seperator. So, for example, we could use a comma as a seperator.
sed -i '' -e 's,http://www.oldurl.com,http://www.newurl.com,g'
We can really use any symbols we want.
sed -i '' -e 's#http://www.oldurl.com#http://www.newurl.com#g'
Keep an eye on the blog in the coming weeks for more Terminal Tricks!
It’s a dreary Thursday afternoon, so naturally, music is necessary. Ever the aesthete, Doejo creative director, Garrett Galayda, was kind enough to show me this customizable Soundcloud player, courtesy of ToneDen. A departure from the standard waveform, this plugin makes me want to just stare at my music. Check it out.
This is the sixth article in our “The 12 Dos and Don’ts of becoming a Web Developer” series.
“Fine,” you tell me. “I won’t get caught in tutorial paralysis. So what do I need to do?”
Set up a Github account and push some code, young padawan. It’s that simple.
It doesn’t matter what you’re working on; create a repository for it, commit it, and push it to Github. It doesn’t matter if it’s good or not; you can always go back and improve it later, or leave it as-is and push something better to a new repository next time. Once you figure it out, it will take you an extra 30 seconds every hour or so to do this, but the benefits are pretty great:
1) Remember when I said you need a solid grasp of Git? Here’s your chance to practice. Initializing a repository, adding your changes, committing them with a descriptive message, and pushing them to a remote repository (such as Github) should all be second nature to you. That way, when you start working on a team and need to handle more advanced concepts like branching / merging / rebasing, soft and hard resets, cherry-picking, etc., you won’t feel totally overwhelmed — or, worse, break something and have to spend an hour figuring out how to undo it.
You’ll be able to turn a moment like this:
Into a moment like this:
2) Employers love to see that you’ve been active on Github. From my experiences with hiring and conversations with other developers, I’d say that having an active Github profile will not only move you to the top of the pile but probably put you in the top 10-20% of applicants. It shows that you not only know what the hell you’re doing but also gives us a window into how you solve problems. Github alone may not get you a job, but if you have an active profile, it’ll definitely get you some interviews. That’s where you get to kick ass, take names (literally. Get business cards. You’ll never know when you’ll need them), and show what an awesome member of the team you’ll be.
3) You never know when you’re going to need old code. Perhaps you’re trying to remember how you made a full-size background image resize properly on a website you built six months ago, but you can’t recall exactly how you pulled it off and you need to do it again for a new site you’re working on. You can either a) spend an hour or two Googling how to do it and trying to re-implement it or b) take a peek at your Github profile, grab the code, and adjust it for the new project. Having tried-and-true code snippets at hand will save you a lot of time.
One final protip before you go: commit early, commit often, and leave yourself descriptive messages about what you actually did (no “updated css and lots of other changes” crap). When you break something (and you will) and need to revert to an earlier commit, you’ll be glad you did this. What I like to do is, before I sit down and write a single line of code, think of my commit message in terms of my tasks ahead of time; if my commit message involves the word “and” too many times (“updated styling of h1 on front page AND repositioned contact box AND performed data-sanitization on contact box”), I know I need to be vigilant about breaking it up into multiple commits. You’ll make your life a lot easier, trust me.
Most of the resources I linked in my earlier post cover Git in some shape or form, but here are a few additional (free) resources to check out:
One more thing before I sign-off (I’ve said it before, but it bears repeating): invest the time to learn Git in the command line. There are programs out there (such as Sourcetree) that will handle a lot of the heavy lifting for you, but they also make it much, much easier to screw things up (as one unfortunate developer in my acquaintance learned recently, when he accidentally deleted most of his hard drive.) The command line is a powerful tool, and even though it’s super intimidating at first, it won’t take you long to become familiar with it — as long as you take the time to learn it.
Articles in this series:
- Don’t: Spend too much time picking what language to learn
- Do: Make sure you have a solid grasp of the basics — AKA how to keep other developers from hating you
- Don’t: Feel like you need a traditional education
- Do: Invest some money in educational resources
- Don’t: Get caught in tutorial paralysis
- Do: Set up a Github account and push some code