Some friendly introductions, and a quick overview of the training plan.

Like many opinionated web frameworks, most of the code developers write is in hooks: important functions that are called in a predictable way, which may be extended to customize behavior.

When things appear to go wrong between hooks, being able to peek into a few of the important framework internals can be incredibly valuable. We'll cover three important concepts that will start to give you visibility into what may have previously been a black box

Using our knowledge of the loader, let's put a file in our /vendor folder to make an ES6 module available in our app in totally different namespace.

If you've ever copied and pasted a code from a library's source, in order to customize a little behavior within a complex internal process, you've likely felt the pain of keeping your customized behavior in sync with upstream changes to the library.

Ember's boot process was built with customization in mind, and provides a mechanism for inserting our own custom code at various places in startup process. These bits of code are called initializers and instance-initializers.

We'll build on our knowledge of the container, and use the Registration API to prepare it for our app, in some initializers and instance-initializers of our own.

We only want our app to boot up once we have geolocation data. Retrieving this from the browser is an async process, so we'll need to ensure we halt the boot process until it's complete. Once data has been retrieved, put it in the container under the data:location key, in such a way that we only have a single copy of the object used across the whole app.

Broccoli is the asset pipeline used by ember-cli, and it has one job: transforming and combining files. While the core broccoli library is great, some of the most important build-related stuff happens inside the many broccoli plugins that are used to transpile, minify, uglify and analyze your source code.

We'll build our own broccoli plugin, explore some debugging techniques and learn some broccoli best practices.

We want to add a copyright notice comment to the top of all built JavaScript files. Do so by way of a broccoli plugin.

Note: you may end up tampering with files after the've already been fingerprinted, so you may need to remove ember-cli-sri from your project.

Break for Lunch

One of the distinct advantages of working with an opinionated framework is that many people are working with the same set of libraries and tools. Continuous integration and continuous deployment typically take a lot of effort to set up, but in the ember world, it's incredibly easy! We'll use Travis-CI and Heroku (coincidentally, two both apps) to automatically test and deploy new code that's pushed to our project's GitHub master branch.

Set up free continuous integration w/ Travis-CI, create a new app on Heroku using the ember-cli build pack, and have Travis automatically deploy in the event that tests pass.

BONUS: setup a heroku pipeline, and enable PR apps, so you can view and play with proposed changes before merging PRs!

Ember's server side rendering technology is incredibly easy to set up, particularly in comparison to getting something equivalent working in ecosystems that are less opinionated and aligned to a common set of ideas.

Although both browsers and Node.js both run JavaScript, there are a couple of very important differences that we need to be aware of, as we prepare our app for Fastboot.

Install ember-cli-fastboot, and run ember fastboot --serve-assets. You'll find that something we're doing is making our lightweight and incomplete DOM implementation unhappy. Use our knowledge of Fastboot guards to fix this problem (i.e., skip it if we're running in fastboot land).

Grab the user agent of the incoming request to index.html, and make it available in the container under the container key data:request