Keen-eyed HomeKit users have likely seen these sensors in their Home apps, but we can extract this data for our own automation purposes…fairly easily, as it turns out! In this post, we’ll unlock access to these sensors via the Shortcuts app and some CLI magic. Stay tuned!

Shortcut to Success

Apple’s Shortcuts app is a surprisingly powerful tool for automation, but it’s also a bridge between Apple’s oft-locked-down ecosystem and some of our own custom workflows. Let’s create a simple Shortcut that reads a HomePod’s temperature:

We need but two Shortcut actions here:

• Get State. This node will read the value of our HomePod sensor, which you’ll see exposed as “Temperature Sensor” unless you’ve renamed it (which isn’t a bad idea!).
• Stop and Output. This node does exactly as described: It halts execution of the Shortcut and outputs a given value…here, the temperature! More on this later.

Save the Shortcut and make note of its name, as we’ll use that next!

It’s Terminal Time!

The magic happens when we step outside the Shortcuts app and into the CLI: Shortcuts provides a conveniently-named shortcuts command to execute a Shortcut via its name.

shortcuts run "Read HomePod"

Running the command now, however, produces…not much. The “Stop and Output” action is really designed for running a Shortcut interactively, and shortcuts run prefers a file as output, which doesn’t do our automations any good; however, a helpful Redditor came up with a nifty workaround!

The Unix tee utility takes its input from STDIN and writes it simultaneously to STDOUT and a file. Serendipitously, piping the output of shortcuts run to tee makes our output visible!

$ shortcuts run "Read HomePod" | tee

  20.8°C

From here, our options are endless! Aside from the obvious geeky satisfaction, programmatically reading data from your HomePods—or any of your HomeKit accessories, for that matter!—can open all kinds of doors. Personally, I have a service that vends these values for my homelab’s dashboard…but that’s another post! Until then, share your favorite Shortcuts and HomeKit hacks in the comments…and happy hacking!

In this post, we’ll look at using Docker Compose to create a quick way to start building on WordPress plugins and themes that’s both developer- and source control–friendly. Read on to find out more!

Getting Started

Before starting, you’ll need Docker installed locally. Once installed, the official MySQL and WordPress Docker images provide an excellent foundation for what we need. We’ll start with a standard Docker Compose configuration; the only points of note are that we’re using a volume for the WordPress database (so we don’t lose any data if we need to recreate the containers), and that we establish a dependency for the WordPress image on the MySQL one (via the depends_on property).

NOTE: Please be aware this is absolutely not a production-safe configuration: Its purpose is solely for local development.

version: '3.9'

services:
  wordpress:
    image: wordpress:latest
    depends_on:
      - db
    restart: always
    ports:
      # NOTE: WordPress will be accessible via port 8000, as defined here.
      - '8000:80'
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD: wordpress
      WORDPRESS_DB_NAME: wordpress
      WORDPRESS_DEBUG: 1

  db:
    image: mysql:5.7
    restart: always
    ports:
      - '3306:3306'
    volumes:
      - dbdata:/var/lib/mysql
    environment:
      MYSQL_ROOT_PASSWORD: somewordpress
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wordpress
      MYSQL_PASSWORD: wordpress

volumes:
  dbdata:

Once we have the Compose configuration in place, we can get WordPress started:

$ docker compose pull
$ docker compose up

It will take a moment for the images to be pulled and spin up, but once that’s done, visit http://localhost:8000 (port 8000 was configured in our Compose configuration file) and go through the WordPress setup. Once that’s complete, we now have a full WordPress instance up and running!

Adding Our Code

Now that we have a running WordPress instance, let’s modify our Compose config to link up our own code. I won’t prescribe a specific folder structure, but this approach has worked well for me: Everything’s grouped in a src folder, within which each theme and plugin has its own folder:

- /project
  - /src
    - /example-plugin
      - index.php
  - docker-compose.yml

We’ll use Compose’s volumes collection to do the mapping. Note that we’re not mapping the entire plugins folder: Since most WordPress instances use at least some other plugins, it behooves us to map only the plugins we’re working on. This also helps keep the source code clean and focused to just our own code.

version: '3.9'

services:
  wordpress:
    # Other fields removed for brevity
    volumes:
      - ./src/example-plugin:/var/www/html/wp-content/plugins/example

Creating a WordPress plugin is beyond the scope of this post, but let’s use the following trivial plugin for testing: The plugin’s only “function” is to render a message on each page…just enough for us to verify everything’s working.

<?php

/**
 * Plugin Name: Example Plugin
 */

add_action('wp_footer', 'add_footer');
function add_footer() {
    echo '<p>Hello, world!</p>';
}

Compose won’t be aware of our new volume mapping until the service is stopped and restarted (a normal restart command isn’t sufficient):

$ docker compose stop
$ docker compose up

Once the containers are running again, take a peek at your instance’s plugins page at http://localhost:8000/wp-admin/plugins.php. If all went well, you should see our new plugin in the list! Just click “Activate” and verify everything works by visiting any page of your WordPress instance and scrolling to the bottom.

Next Steps

Though we’ve just demonstrated plugin development in this post, the same procedure applies for themes, as well: Just map your theme to /var/www/html/wp-content/themes/<theme>. Don’t forget to activate it!

If you’d like a jumping-off point, the code for this post is available on GitHub. Happy coding with WordPress!

Part I: The Story So Far

In which we review some basics about Alpine.js

Part II: Moving Beyond HTML (This post)

In which we refactor our app and add filtering

Part III

Coming soon!

Part IV

Coming soon!

Part V

Coming soon!

In this series, we’ve been building a music playlist app using some modern workflows and Alpine.js features. Today, we’ll add a quality-of-life improvement for our users and get to know some of Alpine’s more advanced features. We’ll start by moving and refactoring our inline code into a separate JavaScript file, then add filtering so users can more easily navigate through the 250+ playlists. Let’s get started!

Moving Beyond HTML

Up to this point, we’ve used Alpine’s expressive inline code directives for all the behavior in our app. Though this is a perfectly fine way to continue, reading JavaScript inside HTML attributes gets more and more difficult over time. If you’re working with Alpine’s inline scripts in production, I’d encourage you to frequently revisit whether it’s time to move to a more formal script file. For our playlists app, now is that time!

Alpine provides a convenient global for injecting our formerly-inline scripts into its runtime, as well as a global document event so we can ensure it’s completely loaded before attempting to do so:

document.addEventListener('alpine:init', () => {
  // We have access to `window.Alpine` here to add our logic
})

At this point, though, we have a choice of how to proceed: Continuing to use a data object, or upgrading to a store. These two concepts are fairly similar, and use nearly-identical APIs, supporting properties, functions, etc. The main difference is that Stores are globally-accessible in Alpine apps (via the $store variable), while Data objects are designed to be more tightly-scoped and flexible.

Our straightforward app could quite easily rely on either approach, but we’ll take this opportunity to add a Store. In your apps, this is a great opportunity to think about whether you need to reuse these services, and how much of your app they affect. Logic included in specific parts of your app (think widgets, cards, and the like) are well-served by Data objects, while tracking global state like a user’s authentication status and preferences work well with Stores.

Okay, back to some code! After creating our new script file, let’s create a Store and add some basic functionality. In part one, we used Lodash and a window global to group our playlists by a given property. We could continue to use Lodash’s response format (a single object with one key per group), but I think a proper array is more understandable, so we’ll dip into the native Object.entries() function to clean that up, as well:

document.addEventListener('alpine:init', () => {
  // Note the Store's name of "app", which we'll reference in the HTML.
  Alpine.store('app', {
    get groupedPlaylists() {
      return Object
        .entries(_.groupBy(window.data, 'group'))
        .map(([ groupName, playlists ]) => ({
          groupName, playlists
        }))
    },
  })
})

We also need to update the HTML directives to reference our nascent Store. Our wrapper <template> tag now looks like this:

<!-- `$store.app` is how we reference our Store by name. -->
<template
  x-for="group of $store.app.groupedPlaylists"
  :key="group.groupName"
>
  <!--
    References to `groupName` and `playlists` need to be updated to
    use `group.`, as well.
  -->
</template>

Hopefully you can already see the benefits of a separate script file: Putting our multi-step conversion from an object literal into an array of objects would be quite confusing to try to read in the middle of an HTML attribute, and that’s even assuming syntax highlighting works!

Now that we have a great place for more complex logic, let’s add some!

Our Feature Presentation

The first feature we’re going to add to our app is filtering. Our playlists collection comprises over 250 items, which is a lot to scroll through! Adding a quick filter would really help our users narrow down the potential mood playlists they can listen to. The Alpine docs already contain a tutorial on building a search input, so I won’t go into too much detail on how to build one, but the code is quite clear, regardless.

There are two behaviors I’d like to highlight, however: One, we’d still like our playlists grouped after they’re filtered, so we’re going to update the groupedPlaylists property to group the filtered list instead of the complete one; and two, since we’re using each playlist’s slug, we need to replace any hyphens with blank spaces in case a user searches a string like “chilling out”. The latter is easily accomplished with a regular expression.

Alpine.store('app', {
  filter: '', // This property will be bound to an HTML <input>
  get filteredPlaylists() {
    let filterString = this.filter.toLowerCase().trim()

    // If the user hasn't entered text, return all playlists
    if (filterString === '') return window.data

    // Otherwise, perform the basic "search" by playlist name
    return window.data.filter((playlist) => {
      let playlistName = playlist.slug.replace(/-/g, ' ')
      return playlistName.includes(filterString)
    })
  },
  get groupedPlaylists() {
    // This property remains mostly the same, but we'll replace
    // `window.data` with `this.filteredPlaylists`.
  },
})

As you might expect with a modern JavaScript library, Alpine handles all the reactivity for us! Just referencing this.filter and friends automatically re-evaluates each property whenever the upstream values change.

At this point, we could play around with the filter property to make sure the searching works, but it’s so easy to add the <input> so users can perform the filter that we may as well! We’ll add the search filter input into the page’s <header>; if you’ve been following along with the HTML, you’ll know that only our <ul> is “Alpine-aware” via a x-data attribute, so we can either add x-data to the header element, or the HTML <body> itself. I’ve chosen the latter, since this entire page now is one big app!

<body x-data>
  <header role="banner">
    <div class="constrained">
      <h1>Apple Mood Playlists</h1>
      <!-- Note the `$store.app` prefix is here, as well. -->
      <input x-model="$store.app.filter" placeholder="Search">
    </div>
  </header>
  <!-- ... -->
</body>

We now have a nice quick filter input that searches playlist names, and thanks to our updates to the groupedPlaylist property, we don’t even have to deal with empty groups! If you’re feeling adventurous, though, a great UX improvement would be to display a “no results” message, but I’ll leave that as an exercise to the reader.

Until Next Time!

In this post, we refactored Alpine’s inline HTML directives into a separate script file, and added a quick filter so users can easily find playlists. Filtering is a great start to improving our app’s user experience, but we can go further: Allowing users to “favorite” mood playlists is a fantastic way to make our app even more usable! Stop by in our next post when we do just that, and we’ll look at another nifty component of Alpine while we’re at it. Happy listening!

Resources in this post

• Source code for Part II (GitHub)

Part I: The Story So Far (This post)

In which we review some basics about Alpine.js

Part II: Moving Beyond HTML

In which we refactor our app and add filtering

Part III

Coming soon!

Part IV

Coming soon!

Part V

Coming soon!

Recently, I’ve been spending a lot of time with Alpine.js, a self-proclaimed “rugged, minimal” JavaScript tool that sprinkles behavior on top of rendered HTML. This is the kind of technology I wished for—and briefly experimented with—in the bygone days of back-end-language-rendered HTML before single-page apps became the norm. Though Alpine isn’t as full-featured as other frameworks, I’ve found it refreshingly easy to work with, and perfect for proof-of-concept apps.

In this series, we’ll look at some advanced workflows with Alpine by building out a music playlist app. We’ll start by setting up Alpine (a shockingly trivial thing to do), then add some features, a build system, and finally, some testing. The final code is available on GitHub if you’d like to take a peek before we begin. Let’s dive in!

What we’re building

Like many developers, I love listening to music while I code. Also like many developers, I hate being interrupted while I’m focused…like when I need to find a new album to listen to after the current one ends, for example. Thankfully, playlists have been part of the streaming music streaming since the very beginning, and solve this problem nicely. Recently, Apple announced some curated (and constantly-updated) playlists for “moods”, and I’ve been a huge fan of every one I’ve listened to.

Unfortunately, as of this writing, Apple hasn’t published this list, and their discoverability is limited to asking Siri to “play the dinner party playlist”. Thankfully, MacStories took the initiative to document as many as they could find, but we can do better!

Our Alpine app will display these playlists, roughly categorized (thanks again to MacStories for the grouping), but also allow us to search for playlists and “favorite” some so we can easily find them later.

An Alpine Climb

If you’re brand-new to Alpine, I strongly suggest working through their tutorials. It’s quite remarkable how trivial it is to get started with Alpine: A single <script> tag is really all you need!

For our app, we’ll start with just two files: An HTML page and a JavaScript file containing a static list of the playlists (there are just over 250 of them, so this helps keep our other code clean). Following the conventions of the Alpine docs, our HTML file looks something like this:

<html>
<head>
  <script defer src="https://unpkg.com/alpinejs@3.x.x/dist/cdn.min.js"></script>
</head>
<body>
  <!-- Our markup will live here... -->
  <script src="./data.js"></script>
  <script>
    // ...and our behavior, here!
  </script>
</body>
</html>

The data file creates a global variable for the playlists that we can reference from the app. Though global variables aren’t a good practice, this one will work for for the moment, and we’ll fix this issue in a later part of this series.

For this app, we’ll need two pieces of information to uniquely identify each playlist (an ID and a slug, which I’ve pulled from each playlist’s URL), as well as a group name (again, from the general grouping provided by MacStories):

window.data = [
  // ...
  {
    id: '163ac0d163734b888fb6490db5520094',
    slug: 'spring',
    group: 'Seasons and Weather',
  },
  {
    id: '9d61a50fbc9c42a9b5eb5df3eb763d0c',
    slug: 'summer',
    group: 'Seasons and Weather',
  },
  {
    id: 'b04a92a765114f8691c08ff96f57ed57',
    slug: 'fall',
    group: 'Seasons and Weather',
  },
  {
    id: '8b36c21d1ce7493392a2f845c4293408',
    slug: 'winter',
    group: 'Seasons and Weather',
  },
  // ...
]

Listing the Playlists

We’ll start building the app proper by showing a basic list of each playlist, and adding URLs so they can be clicked to open each playlist in Apple Music. We’ll use a combination of Alpine’s x-data, x-for, and x-text directives to render a list of each playlist’s slug:

<ul x-data>
  <template x-for="playlist in window.data" :key="playlist.id">
    <li x-text="playlist.slug"></li>
  </template>
</ul>

Alpine uses x-data to identify which parts of the page require interactivity, so we’ll add that to our <ul>, even though we’re referencing the playlist array directly in the x-for directive. You could also add a proxy variable inside x-data if you choose (i.e. <ul x-data="{ playlists: window.data }">), which is a testament to Alpine’s flexibility when integrating with existing HTML.

Just showing playlists’ slugs isn’t very useful, so let’s add links so users can open each playlist. For this, we’ll use the x-bind directive (more accurately, its shorthand of :<attribute>) to populate each playlist’s href attribute. Alpine lets us use plain JavaScript expressions (be sure to read up on the security implications), so a string interpolation to translate a playlist’s ID and slug into a correct URL is straightforward:

<li>
  <a
    :href="`https://music.apple.com/us/playlist/${playlist.slug}/pl.${playlist.id}`"
    x-text="playlist.slug"
  ></a>
</li>

Of course, a flat list of 250+ playlist slugs isn’t a great experience, but to improve that, we’re going to need a little help…

(Lo)Dashing up the Mountain

Lodash is a fantastic utility library that comprises a large number of useful functions. It’s worthy of its own blog series, but we’re going to use only two of its many helpers: startCase(), which converts a slug into something more human-readable, and groupBy(), which, well, groups the playlists by a given key (in our case, we’re using group).

Adding Lodash to our app is as simple as inserting another <script> tag into our <head>; we can use the same CDN as Alpine itself:

<script src="https://unpkg.com/lodash@4.x.x/lodash.js"></script>

…and humanizing our slugs is nearly as straightforward:

<li>
  <a
    :href="..."
    x-text="_.startCase(playlist.slug)"
  ></a>
</li>

Grouping the playlists is slightly more complex, but only just. Lodash’s groupBy() function’s return value is an object with the group names as keys; for example, our example data from above would get grouped thusly:

{ 'Seasons and Weather': [ { ... }, { ... }, { ... }, { ... } ] }

Built-in functions like Object.entries() could help us out here by converting this object to an array, but I’ve found Alpine is capable of iterating objects on its own. Be warned, though: I haven’t found any official documentation suggesting this is a supported feature, so it’s possible it will break in future releases, or behave strangely. That said, we can use a similar template as we’ve used above for the groups:

<ul x-data>
  <template
    x-for="(playlists, groupName) of _.groupBy(window.data, 'group')"
    :key="groupName"
  >
    <li x-text="groupName"></li>
  </template>
</ul>

Ah, but now we have a list of 250+ playlists and a list of about twenty groups. So how can we put the two together? Spoiler alert: Quite easily! We can nest the x-for for the playlists (and its associated <template>) inside the one for the grouping:

<ul x-data>
  <template
    x-for="(playlists, groupName) of _.groupBy(window.data, 'group')"
    :key="groupName"
  >
    <li>
      <h1 x-text="groupName"></h1>
      <ul>
        <template x-for="playlist in playlists" :key="playlist.id">
          <li>
            <a
              :href="`https://music.apple.com/us/playlist/${playlist.slug}/pl.${playlist.id}`"
              x-text="_.startCase(playlist.slug)"
            ></a>
          </li>
        </template>
      </ul>
    </li>
  </template>
</ul>

We’ve now got a lovely nested list of grouped playlists and the playlists themselves:

Throw in a bit of styling, and we have ourselves a great mini-app for finding our favorite Apple “mood” playlists! If you’ve been following along, you may have noticed something interesting: Excepting the data file and the sprinkling of Alpine code, this app contains zero JavaScript! Everything’s done within Alpine’s directives.

Next Up: More Features!

In the next post in the series, we’ll expand our simple app with some quality-of-life features: Filtering the playlists by name, and “favoriting” some so we can easily get back to our most-loved moods. Until next time!

Resources in this post

• Alpine.js docs
• Lodash docs
• Source code for Part I (GitHub)

Like many Ember developers, I’m excited about Glimmer. With the Octane release, the Ember team has removed a lot of cruft from the framework and dramatically simplified day-to-day development. As such, I was excited to upgrade to the latest releases that support Glimmer—3.13 and 3.14—and try out the new goodies.

Unfortunately, I quickly ran into what seemed like a strange miss on Glimmer’s part: Glimmer components don’t appear to support unit tests. Most of my Ember projects use a large number of component unit tests, so this was a bummer to discover: I’d have to make major changes to the way my components worked in order to have test coverage.

The Problem

A default component unit test (created via ember generate) looks something like this:

test('it exists', function(assert) {
  let component = this.owner.factoryFor('component:my-component').create();
  assert.ok(component);
});

This test is pretty easy to understand: the test looks up the factory function for the component we specify, then creates an instance, returning a reference so we can make assertions against the component, minus its rendering. I use this kind of test all the time to exercise computed properties, so I naturally started here when looking to test Glimmer components.

Running said test, however, provided the following error:

Error: Failed to create an instance of ‘component:my-component’. Most likely an improperly defined class or an invalid module export.

I asked around on Ember’s Discord (a great place to get help, if you haven’t discovered this already), but there was no obvious solution. I tried a couple of other suggested options, all to no avail:

new (this.owner.factoryFor('component:my-component').class);
new MyComponent(this.owner.ownerInjection(), {});

Error: You must pass both the owner and args to super() in your component.

What I was provided with, though, was some background on Glimmer’s internals and some discussion on component testing in general: just enough to get the little grey cells moving.

To the source!

Fortunately, Glimmer’s source (and Ember’s, too, really) is very readable, and it didn’t take long to grok how Glimmer’s components work: arguments passed to components are given to a ComponentManager, which then passes them to newly-created Components after confirming that the args’ integrity is intact. Can we then use this same approach to create components for unit testing? In short: yes!

The Owner. First, we’ll need a reference to the “owner”: a shortcut into Ember’s dependency injection container. If we’re already inside a test, we can access this via this.owner; otherwise, we can use a function from @ember/test-helpers:

import { getContext } from '@ember/test-helpers';
let { owner } = getContext();

The Factory. We also need a factory function to give to the Component Manager so it can create the Component instance. Historically, this was in a factoryFor() function, and it still is: just behind a class property (since we’re using classes now!). To get this, we’ll need the lookup key for the component (usually of the style of component:my-component). If you’re migrating an existing unit test, this is the string passed to factoryFor():

let lookupPath = 'component:my-component';
let { class: componentClass } = owner.factoryFor(lookupPath);

The Component Manager. Next, we need to create the aforementioned Component Manager, through which we’ll pass arguments to our soon-to-be-created component. The component manager is injected into Ember’s dependency container, so we can import it thusly:

let componentManager = owner.lookup('component-manager:glimmer');

At last: the Component! Now that we have an Owner and Component Manager, we can create the component we’ve always wanted! We’ll need one last thing: any arguments we want to provide the Component. The Component Manager expects these in an attribute named named, so we’ll oblige it:

let named = { myArgument: 42 };
let component = componentManager.createComponent(componentClass, { named });

The Tests. The component alone is not enough, of course: we still need our tests. I was concerned about this part, because Glimmer components do away with computed properties and Ember’s getters and setters. I needn’t have worried, though: Octane’s changes mean most Glimmer component code is regular JavaScript! Just set values as you would inside the Glimmer component, and you’re all good!

named.myArgument = 1337;
assert.equal(component.someGetterThatUsesMyArgument, 1337);

Don’t Repeat Yourself

I use this approach often enough that I usually create a test helper to do all the hard work for us in one place. Here’s the helper in its entirety:

import { getContext } from '@ember/test-helpers';

export default function createComponent(lookupPath, named = {}) {
  let { owner } = getContext();
  let componentManager = owner.lookup('component-manager:glimmer');
  let { class: componentClass } = owner.factoryFor(lookupPath);
  return componentManager.createComponent(componentClass, { named });
}

And you can use it thusly:

import createComponent from 'my-app/tests/helpers/create-component';

test('should calculate the value', async function(assert) {
  let model = { val: 4 };
  let component = createComponent('component:my-component', { model });
  assert.equal(component.valueSquared, 16);

  model.val = 3;
  assert.equal(component.valueSquared, 9);
});

I’ve published a sample Ember Octane app on GitHub if you’d like to play around with real code.

A Disclaimer

As I mentioned earlier in this post, Octane doesn’t officially support unit tests for Glimmer components. Although (as far as I can tell), everything in this post uses non-private APIs, there’s no guarantee this approach will work in the future. Of course, I hope the Ember and Glimmer teams restore official support for this type of test, as it’s usually the first thing I reach for when building out components. Until then, I’ll try to keep up with any API changes and update this post to match.

I want to extend special thanks to NullVoxPopuli, pzuraq, and bendemboski from the Discord server, for listening to my concerns, patiently explaining me through the Glimmer rendering process, and offering suggestions on how to proceed.

I also owe Discord user DanDan a debt of gratitude for letting me know of the breaking Glimmer API and his work to resolve it. Much appreciated!

Do you have any other approaches you use for component tests? Suggestions for improvement? Let me know in the comments below, and happy testing!

One option is to simply pass along the upstream status code to the client: if your server can’t login to another server, for instance, return the second box’s 4XX.

// HTTP 401 Not Authorized
{
  "response": {
    "error": "Your credentials were invalid"
  }
}

Unfortunately, this introduces some confusion to the consuming code: did your server reject the request, or did the upstream one do so?

The solution that has worked well for us is to wrap the upstream request before sending it to the client. In other words, your server should return its own status code, but contain the upstream one. Philosophically, if the request to your server succeeds, still consider the request “successful” (with a 200) even if the upstream errors (a 404, for example).

// HTTP 200 OK
{
  "upstreamResponse": {
    "statusCode": 401,
    "error": "Your credentials were invalid"
  }
}

This allows us to both represent our system’s status (where a 401 may represent that a user isn’t logged in for us) and the upstream’s status (where a 401 may be completely unrelated to our own authentication system). It’s helpful to include both for user experience purposes, as you can easily differentiate to users whether it’s your code or someone else’s that threw an exception.

This behavior is nuanced, but we’ve found it effectively represents disparate servers’ statuses. Have you had similar results? Is there a solution that works better for you? Weigh in in the comments!

In the tradition of trying out new things for the new year, I want to share a few of my favorite coding typefaces. If you’ve been staring at the same letterforms for a while, maybe consider a change!

SF Mono

A relative newcomer, SF Mono is Apple’s monospace variant for its fantastic San Francisco family. It comes in six weights (useful if you use multiple sizes at once) and features some of the same personality its proportional cousins bring to macOS. If you own a Sierra-or-thereafter Mac, you already have it, though it takes some steps to install.

Fira Mono/Fira Code

I’m a huge fan of the Fira family (as of this writing, this blog uses Fira exclusively), and its monospaced version is no exception. The slightly whimsical serifs don’t detract from the business of programming, and it’s surprisingly readable at any size. The alternate “Code” version adds programming-specific ligatures, if that’s your thing.

PT Mono

The PT family traces its origins to Russian typefaces, and you can still detect the hint of Cyrillic letterforms in its monospaced form. It’s limited to two weights, so beware if you find yourself shifting between display pixel densities.

Verily Serif Mono

If a traditional, literary typeface is more your style, give Verily a try. Its refined serifs seem plucked from your favorite hardcover, though I find it grows quickly distracting on-screen.

Fantasque Sans Mono

If you like your text editor on the playful side, Fantasque is for you. For a typeface described as “the mutant child of Comic Sans and Helvetica Neue”, Fantasque looks quite good on languages from JavaScript to HTML.

As For Me…

I’m going to give Adobe’s excellent Source Code Pro a few weeks on my editor’s surface. It’s a lovely standby that always helps me clear my head. After that, who knows? I might just go nuts:

What about you? Have I missed your favorite? Have a visceral reaction to any of these? Weigh in below, and happy coding!

One of the “complementary tools” to React (and the one recommended by many example apps I’ve encountered) is Webpack: a self-described “module bundler” that’s also commonly used to compile and process images, CSS, and other soon-to-be-static assets. Though Webpack is often suggested, I encountered several problems that led me to look elsewhere for setting up a build task. In this post, we’ll look at a few of those problems and what I ended up replacing Webpack with to solve them.

TL;DR: If you want to jump straight to the good parts, I’ve created an example app hosted on GitHub that covers everything in this post.

A (Web)pack of Trouble

When I was first getting started with React, I found the guides to be lacking with regards to setting up and maintaining a local development environment. Admittedly, I’m very spoiled by the Ember ecosystem and Ember CLI, but I eventually happened on “The React.js Way” blog series, which advocates using Webpack for this purpose. I started using it, but quickly ran into a number of issues:

Regular expressions. Web pack uses “loaders” to transform files, which rely on regular expressions to select the files to be transformed. Coming from the world of Grunt and friends, which uses very readable strings like src/**/*.js to represent files, expressions like /src\/.+.js$/ make my head hurt, and I’m utterly unable to create new expressions without a reference guide.

Magic strings. Once you’ve managed to select your files using arcane RegEx strings, you’ll need to tell Webpack how to transform them. Webpack implicitly imports these loaders, then relies on string parsing to figure out what to do to the files, and in what order. Here’s an example from the Webpack documentation:

require("!style!css!less!bootstrap/less/bootstrap.less")

Aside from using Bootstrap, there are more insidious issues with this approach: one, it’s very unclear what, exactly, each of these processing steps does (and from which package they’re loaded), and, two, it turns out they’re executed from right to left, thereby guaranteeing I’ll get the execution order backwards every time I write a config file. Even after you decipher this processing instruction, you still need to import your CSS into your JavaScript, of course. Wait: what?

Confusing documentation. Your mileage may vary, but I had a heck of a time deciphering the official Webpack documentation. I mostly relied on other confused individuals who had divined the secrets of Webpack’s functionality and blogged about it.

I normally try to stick with new concepts for a while when learning a new language/library/framework; after all, these ideas and tools typically exist for a reason, and it can sometimes take a while to really grok them. With Webpack, though, I kept running into the same issues, with nothing but hacky-feeling workarounds to “solve” them. So, instead, I went back to the drawing board to look for an alternative.

Eat Your Vegetables

If you’ve spent any length of time talking shop with me, you’ve probably heard me mention Broccoli. If you haven’t, here’s the gist: I’m a huge fan. I find it insanely simple to start with, yet solidly scalable when the need arises. Massive build systems have been built from it (read more about the aforementioned Ember CLI if you’re interested), yet even at that level of complexity, it’s pretty straightforward to work with.

When I finally made the decision to ditch Webpack, I first thought of Broccoli, even though I honestly wasn’t sure if it would solve all of my issues. I wanted, in no particular order, something that would:

• Let me use React and libraries written for it (most of which used calls to require(), meaning I couldn’t just stick more <script> tags on a page);
• Compile any non-standard JavaScript, including JSX for templating and ES2015 for, mostly, arrow functions and template strings;
• Process any CSS I might need (without making me import it into JavaScript files, naturally); and
• Run all of this stuff in a web server.

As it happens, Broccoli’s pretty amazing at all of these, even with the JSX compilation (the cause for most of my uncertainty). Let’s see how to set up a simple React app with it.

Replacing Webpack with Broccoli

Taking the requirements from the previous section, here’s what we want Broccoli to do:

1. Compile any JSX and/or ES2015 in our JavaScript files.
2. Bundle the scripts together, respecting any dependencies using require().
3. Process our CSS from, say, Sass.
4. Serve everything from a web server.

To start with, let’s install Broccoli. It’s an npm package, so you’ll probably want to run npm init and get yourself a package.json file you can save these dependencies to first. After that, install Broccoli:

$ npm install -g broccoli-cli
$ npm install --save-dev broccoli

The first command installs the Broccoli binary, while the second tells our app that it’ll need Broccoli as a dependency. Next, let’s make a simple Broccoli build file, named Brocfile.js. This file is a node module, so we’ll be using calls to require() to bring in dependencies, and expose any outputs with module.exports.

Broccoli works primarily with directory paths, called “trees”, that represent files and folders in your app. If we wanted Broccoli to act as a passthrough and not do any real processing, all we’d need in Brocfile.js—assuming our app assets are in an app folder—is:

module.exports = 'app';

We need a bit more than this, so let’s continue. First, we’ll need to install React, since our code depends on it. You’ll use a similar method if you want to install other packages on which your runtime code depends. Install it with the following npm command:

$ npm install --save react

Next, we’ll use two Broccoli helper packages to accomplish Objectives #1 and #2 (compiling and bundling our JavaScript), so run these commands to install them. Note that we’re installing these with --save-dev, not just --save, since they’re used for building, and not running, this app.

$ npm install --save-dev broccoli-babel-transpiler
$ npm install --save-dev broccoli-browserify

broccoli-babel-transpiler is a Broccoli wrapper around the excellent Babel library. When we use it, the package will convert any ES2015 code we might right into code that runs in the majority of modern browsers (TL;DR: IE9+). As it happens, Babel also features support for converting JSX templates into JavaScript, as well, so that problem solves itself! We’ll then use Browserify to take care of those require() calls. Here’s what our Brocfile looks like now, after we’ve imported and used these two packages:

var browserify = require('broccoli-browserify');
var babel = require('broccoli-babel-transpiler');

var js = 'app';
js = babel(js, {});
js = browserify(js, {
  entries: [ './app.js' ],
  outputFile: 'app.js'
});

module.exports = 'app';

Broccoli lets us pass trees (like app in the above example) through varying processing steps, which will be executed in order (and, if you ask me, with far less confusion than Webpack’s approach).

Let’s move on to Objective #3: processing CSS. There are a number of CSS preprocessors, and a number of Broccoli plugins for them, but let’s go with one of my favorites, Sass. Install the broccoli-sass package with npm install --save-dev broccoli-sass, and point it at your CSS directory in Brocfile.js:

var compileSass = require('broccoli-sass');
var css = compileSass([ 'app/styles' ], 'app.scss', 'app.css');

I’ll leave the explanation of this plugin to the broccoli-sass documentation, but, in essence, we grab the uncompiled Sass code from app/styles and transform it, starting with app.scss.

At this point, we’ve run into a bit of a problem. With module.exports, we can only export a single tree object, but what we want is to “merge” the compiled JavaScript from Objectives #1 and #2 with the compiled CSS from Objective #3. Another Broccoli plugin to the rescue: broccoli-merge-trees. This package, hopefully unsurprisingly, can merge our two (or more!) trees together. Here’s an example where we also bring in a public directory:

var merge = require('broccoli-merge-trees');
module.exports = merge([ 'public', js, css ]);

Let’s then create an index.html file that will represent the starting point of our app. We’ll stick this file in the public directory since it doesn’t require any special processing or compilation. You may notice that the build steps we’ve created output two files: app.js and app.css. We’ll want to reference these in this HTML file like so:

<!doctype html>
<html>
  <head>
    <meta charset="utf-8" />
    <link href="app.css" rel="stylesheet" />
    <title>(Your App)</title>
  </head>
  <body>
    <script src="app.js"></script>
  </body>
</html>

What about Objective #4? You’ll be pleased to know Broccoli comes with a simple web server preinstalled! To start it, run:

$ broccoli serve

Then visit http://localhost:4200/ in your favorite web browser (I don’t know where the port number comes from, but I like to think it’s inspired by the late Douglas Adams). If all goes well, you should see your React app in all its compiled and bundled glory!

If you’ve been fighting with Webpack for building your React apps—or if you, too, struggle with setting up a React dev environment—why not give Broccoli a try? Alternatively, if you’re a die-hard Webpacker, or if you’ve found another build tool to solve Webpack’s issues, I’d love to hear what’s keeping your React apps built!

There’s a bit of a plot twist at the end of the talk that I get a lot of questions about (watch the video above first if you don’t want spoilers). In this post, we’ll look at how this plot twist was created.

Spoiler Alert

If you’re reading this, I assume you’ve either watched the above video, or you don’t care about spoilers (you monster). Okay, here’s the big plot twist:

My entire presentation—the slides, the inline CSS editing, everything—was built without a single line of JavaScript.

Let’s take a look at how to pull that off.

Thinking without JavaScript

A slide deck doesn’t have many “features” beyond showing one slide at a time (and having some way to switch between those). As it happens, we have access to an HTML element that also shows one thing at a time: a radio button.

<input name="slide" type="radio" checked>
<label ><!-- Slide 1 --></label>

<input name="slide" type="radio">
<label ><!-- Slide 2 --></label>

<input name="slide" type="radio">
<label ><!-- Slide 3 --></label>

Now, if we could somehow link the “checked” state of a radio button to the visibility of another element, we’d have the beginnings of a slide deck right there. Select the radio buttons in the following pen to see what happens:

See the Pen LppWpY by Tim G. Thomas (@TimGThomas) on CodePen.

So far, we’ve got a passable—albeit boring—slide deck, and all it took was some very basic HTML and a little clever CSS. Turns out styling elements is pretty straightforward thanks to the :checked pseudo-class and the + (adjacent) selector:

/* Hide all slides by default. */
.slide {
  display: none;
}

/* But show the currently-selected one. */
input[name='slide']:checked + .slide {
  display: block;
}

radioButton.hide()

You’re more than welcome to stop here, as what we’ve covered so far is technically all you need to make your own JavaScript-less styles, but there’s more we can do.

Seeing all of those radio buttons sucks, so let’s get rid of them:

input[name='slide'] {
  display: none;
}

That’s better, but now we have no way of moving through the slides. Fortunately, this is already (partially) solved for us: browsers will let you switch between radio button values with your keyboard. Try it out below: click on a radio button, then use your arrow keys to select different options. Obviously, this won’t work if you’re on a device without a keyboard, so keep that in mind if your slides’ consumers will be on their phones:

See the Pen xwwqRK by Tim G. Thomas (@TimGThomas) on CodePen.

Next, we’ll have to link each slide to its radio button. If we’re hiding the inputs, we need some way of giving them focus so that the browser can work its keyboard magic. This is as easy as either giving each input an ID and changing each slide to be a <label>…

<input id="slide_1" name="slide" type="radio">
<label for="slide_1"><!-- ... --></label>

…or wrapping each combination in its own <label>:

<label>
  <input name="slide" type="radio">
  <div><!-- ... --></div>
</label>

Either technique will make each slide “clickable” to set the focus on the radio buttons, thus enabling keyboard movement.

Give each slide some CSS that makes it look like a real slide deck, and you’re good!

Inline CSS Editing

My slide deck also included the ability to edit CSS on the fly and see it instantly update. This is actually a very old CSS Trick that works well to this day. Just move your <style> block inside your <body>, set its style to display: block, and give it the contenteditable attribute: browsers will use it for styling and you can use it for CSS demos. The CSS Tricks site has a great demo page for playing around with this feature.

That’s all there is to it! A few lines of HTML per slide, a sprinkling of CSS, and a little <style> block trickery, and you’ve got yourself a modern—and JavaScript free!— slide deck! If you’d like to learn more about (mis-)using CSS for behavior, read my blog series on “stateful CSS”, watch the presentation video, and check out the code for my slides on GitHub.

If you’ve seen or built any great functionality with little or no CSS, share in the comments!

Just the other day, I discovered that their back-end can host static files, meaning I could move my deployed Ember apps away from services like S3 or Heroku, thus simplifying (and cheapening) my deployments. Getting an Ember CLI app to run on Parse was a little less than frictionless, though, and, in this post, we’ll look at how to manage it.

To get started, you’ll need:

• A Parse account (there’s a free option) and Account Key,
• A Parse application, and
• An Ember CLI app.

But First, a Caveat

To be fair, deploying static files to Parse (such as those generated by Ember CLI) is quite simple. The Parse team provides a command line tool to deploy your code and assets, and it works well. What makes deploying Ember apps tricky has to do with Ember’s URLs.

By default, Ember CLI apps use a browser’s history API, which gives you URLs like your-app.com/photos/1. Here’s the issue: if a user navigates directly to that URL, most web servers will look for either static files or a defined route to serve, neither of which we’ll have after deploying this app.

$ curl -s -w "%{http_code}" http://your-app.com/photos/1 -o /dev/null
> 404 # Ruh roh.

To fix this, we can tell Ember CLI to use “hash”-based URLs instead (like your-app.com/#/photos/1), which we’ll see how to do momentarily. This tells the server to load the root document, and Ember can then step in to figure out what route you’re looking at based on what’s past the “hash” symbol.

Now that’s out of the way, let’s get started deploying our Ember CLI app to Parse.

The Easy Way

Update Ember CLI’s location type. We now know that history-based URLs will break when Parse serves the app from static files, so let’s change our app to use hashes instead: in config/environment.js, simply change the locationType property from 'auto' to 'hash'.

Get your project Parse-ready. The fastest way to do this is to create a new Parse app using their command line tool. From there, you can either copy the files you need into an existing project, or create a new Ember CLI project inline. Using the Parse CLI, run parse generate and answer its questions. You’ll see a few files in there that you’ll need in your Ember app:

• The /cloud folder contains any custom server code your Parse app needs. The Parse CLI generates some default code in main.js…you can take it or leave it, but you’ll need the cloud directory either way.
• The /public folder is where your compiled Ember app will belong. You don’t need to copy this over; we’ll make our own.
• .parse.local contains some properties that tell Parse to which app this code will belong. Warning: since this file contains your application’s unique key, make sure you don’t check it in to public source control. The ember-cli-dotenv library can help with this.
• .parse.project tells Parse what version of its SDK to use. This one’s safe to stick on GitHub. :)

For more details, check out the Parse documentation on the subject.

Deploy! This step requires a bit more prep. What we need is to compile the Ember app into a public directory, then copy the Parse files from the previous step, then tell the Parse CLI to perform the deploy. I use a bash script for this, but be warned: I’m not a bash expert by any means, so feedback is definitely appreciated.

# Compile the Ember app.
ember build -prod -o dist/public

# Copy Parse files and any Cloud Code.
cp .parse.project dist/.parse.project
cp .parse.local dist/.parse.local
cp -R cloud dist/cloud

# Deploy to Parse.
cd dist
parse deploy

# Clean up after we finish.
cd ..
rm -rf dist

Just run the bash script with sh your-file-name.sh, or maybe set it as an npm package script.

The Hard(-er) Way

At this point, you should have a fully-operational Ember app running on Parse…but we can do better. Let’s change our deploy process so we can use those history-based URLs.

Reset things. To start, change your app’s locationType parameter (in config/environment.js) back to 'auto'. No use in sticking with hash-based URLs anymore!

Make a mini node app. We’ll need to tell Parse to always serve up the root document (located at public/index.html) to any and all requests so that Ember can take over routing. Fortunately, this is easily accomplished by giving Parse a simple node app that it will run alongside serving static files. The following code is from Erik Hanchett‘s great blog post on serving Ember apps from Express:

var express = require('express');
var app = express();

app.get('*', function(req, res) {
  // TODO: Send the contents of "public/index.html".
});

app.listen();

Parse starts by looking for files in the public directory before it will run this simple server, so we won’t need to worry about not handling routes for static assets like CSS and JavaScript. From the Parse documentation:

When a request goes to a URL of your subdomain, Parse will first look for a matching file in the public directory. If there is no match, then Parse will invoke any Express request handlers that you have registered in Cloud Code.

To tell Parse about this node server, have your app’s main.js file import it with require('cloud/app.js'); on the first line.

Send down the root file. Unfortunately, Parse’s node implementation lacks certain features (like Express’s Response object’s sendFile() function) that would make sending down a static file trivial. Instead, I’m using a bit of a hack: in the deploy script, make the root file an EJS template, then tell the node app to render it (something the Parse node binary can do):

var express = require('express');
var app = express();

app.set('views', 'cloud/views');
app.set('view engine', 'ejs');
app.use(express.bodyParser());

app.get('*', function(req, res) {
  res.render('index');
});

app.listen();

Here’s the new part of the bash script that does that:

# Create the 'views' directory.
mkdir -p dist/cloud/views

# Copy the root file.
cp dist/public/index.html dist/cloud/views/index.html

# Rename it to '*.ejs'
mv dist/cloud/views/index.html dist/cloud/views/index.ejs

Deploy! Again! With the build script modified, we’re ready to deploy again! This time, our script will also copy the index.html file into the cloud/views folder so our mini-node app can serve it. All that’s left is to visit your Parse app and see if everything works correctly. If not…well, Parse has some great logging tools!

Even with the workaround for Ember’s history-based URLs, I’m thrilled with how easy it is to deploy an Ember CLI app to Parse. If you’re already a Parse user, or have been looking for an excuse to give it a try, why not try your hand at deploying an Ember app? If you run into any issues, or have suggestions for ways to streamline this process, share them in the comments!

Installing Ember CLI

Before I begin, some bad news: when I began this arduous journey, I didn’t realize how difficult it would become, so I neglected to document most of the error messages I received. If I’m feeling masochistic and ever try this again, I’ll update this post with more detailed errors.

Also, I based this post on my experiences, so your mileage may vary (and I certainly hope it does). For reference, I’m using Windows 7 Ultimate, 64-bit. Let’s get started:

1. npm. On Windows, nested packages in node_modules often overflow Windows’s file path length limitations. To bypass this restriction, the npm 3 (beta) stores modules in a flat structure. I didn’t install this at first, and soon ran into issues. To get npm 3, install Node, then use the npm-windows-upgrade package to upgrade it. One caveat: the package’s README implies you should run the upgrade in an Administrator console, but this later caused several permissions errors. Everything worked as expected when I ran the command in a non-Admin window.
2. Python. One of Ember CLI’s dependencies, node-gyp, requires Python. If you’re unfamiliar with the Python ecosystem, there are two major, and somewhat-incompatible, versions. The package doesn’t state which version it needs, but it will complain if you’ve installed the wrong one. You’ll want some flavor of 2.x (I used the newest as of this writing, 2.7.10).
3. Visual Studio. Yep, you read that right: you need Visual Freaking Studio to build Ember apps on Windows. node-gyp only requires some of VS’s C++ compilers, but a full install is the reliable way to get those. A free version is available (I used the recommended “Visual Studio 2013 Express for Windows Desktop”), but set aside at least an hour to find, download, and install it. Oh, and say “goodbye” to a clean “Programs and Features” screen after you’re done:
   
4. Bower. You’ll also need Bower for browser-side package management, but this was a painless installation for me. Just npm install bower -g and you should be good to go.

Building an Ember CLI Project

At this point, I was about 90 minutes into the process…but I wasn’t done yet. After installing Ember CLI, you’ll need to install a project’s npm and Bower dependencies (with npm install and bower install, respectively). The Bower packages installed fine, but npm’s were another story:

1. Folder permissions. I encountered several npm EACCES errors when installing a project’s dependencies, stating that I didn’t have permissions for C:\Program Files\nodejs. This is an easy fix on OSes that have chown, but I had to use Windows’s infamous “Security” UI instead. Though my user account is a member of the “Administrators” group, which has access to that folder, that’s not enough: I needed to give my user account full access to the nodejs folder and its children. The permissions errors disappeared after that.
2. Disconnections. Once the permissions errors cleared up, I started receiving ECONNRESET errors a few seconds into downloading npm packages. Re-running npm install sometimes worked, but changing the npm registry to a non-HTTPS version solved the issue.

Finally, two hours after I began, I was able to build and run an Ember CLI app. Unfortunately, I then discovered Windows is abysmally slow at compiling the Ember CLI stuff. There’s an npm package to help, but it was still pretty painful for me after that…but at least it was working.

I’m still trying to remember exactly why I embarked on this near-Sisyphean experience—I had a MacBook Pro within arm’s reach on which I develop most of my Ember apps—but I hope documenting my painful journey will help yours be less so. Happy Embering!

This year, I gave a talk on adding interactions to your web apps using only CSS, a topic on which I’ve frequently blogged in the past. A full recording of my talk is on Vimeo, and embedded below. The talk’s slides—written entirely with HTML and CSS—can be viewed online and are on GitHub, as well.

As the web becomes a more vivid, interactive medium, page payloads increase dramatically. Images, templates, and behavioral plugins add needed richness, but also code complexity and, yes, file size. Fortunately, there’s an unusual way to add some great interactions to your web apps without bloating your pages: with CSS!

If you’d like to learn more about this topic, check out my blog posts on the subject:

• Mute Your Asynchronous UIs with Stateful CSS
• Fun with Stateful CSS: A View/Edit Screen
• Fun with Stateful CSS: Modals
• Fun with Stateful CSS: Tabs

As always, I’d love to hear your feedback. Have some comments or suggestions? Let me know in the comments!

Moving Files

You may have used Atom’s “rename” feature a time or two, but did you know you can also use it to move files, as well? When you open the “rename” palette, Atom displays the file’s full path (relative to the project root). Want to relocate the file? Simply change the path and hit return:

Copying/Pasting Files

The next time you need to copy and paste a file, why not use Atom instead of your OS’s file explorer? Right-click a file, select “Duplicate”, and Atom prompts you for the file’s new name. Much like moving a file, just change the path to wherever you’d like to copy the new file, hit return, and presto!

Creating New Files

Sure, new files are only a couple of mouse clicks away, but why should you even have to take your hands off your keyboard? Spoiler alert: you don’t have to! Atom includes a command to do just that, but it’s not bound to a keyboard shortcut…yet. Here’s how to make that happen:

1. Open your Atom keymap (Mac: “Atom” > “Open Your Keymap”; Windows: “File” > “Open Your Keymap”).
2. Add the following text, replacing the keystroke with one of your preference (I took mine from a Sublime plugin):

   'body': 'cmd-alt-n': 'tree-view:add-file'

3. Save your keymap file.

Now, just hit ⌥⌘N (or whatever you specified your shortcut to be) and Atom presents you with the “new file” palette. Enter a path for the new file (again, relative to the project root) and hit return/enter. Your shiny new file will present itself instantly.

Have you used Atom’s features to do things otherwise thought the domain of other apps? Share them in the comments!

Having dozens of layers is great when you’re putting the finishing touches on a design or figuring out what pieces fit best together, but it can be a pain sorting through everything in the Layers panel until then. Keeping a mental note of where all your objects and groups are located—not to mention navigating the sea of norgies—can be a nightmare. Fortunately, Illustrator has the perfect feature that can help.

Introducing Isolation Mode

You may be familiar with Isolation Mode if you use symbols in Illustrator: double-clicking a placed symbol enters a mode where changes you make apply only to the symbol, and not the rest of the document. In fact, the Layers panel only shows the symbol’s objects, so there’s no chance you’ll accidentally select some external object.

Fortunately, you can also enter Isolation Mode on other things (including layers, groups, and even single objects), as well! To start, select a layer in the Layers panel (you just need to select the layer, not “target” it), then click the panel’s “menu” icon and choose “Enter Isolation Mode”.

Working in Isolation

After entering Isolation Mode, you’ll notice a couple of changes to the Illustrator UI. First, the Layers Panel updates to only show the layer you’re working with. Second, everything not in the isolated layer will fade out, allowing you to visually focus on the layer you’ve selected. Finally, a new bar appears below the active tab (or below its rulers, if you have those enabled) that shows the hierarchy of this layer:

Now that you’re in Isolation Mode, any new objects you create will become part of the isolated layer, and you won’t be able to select anything outside that layer (that part alone is my favorite part of this feature).

To leave Isolation Mode, you have a couple of options. If you’re in a deeply-nested layer, you can click the name of an ancestor layer in the Isolation Mode bar to switch to Isolation Mode for that layer. Alternatively, just double-click an empty part of the document window to exit Isolation Mode entirely.

I hope you find Illustrator’s Isolation Mode feature as invaluable as I do when working with complex documents. Have any layer productivity tips of your own? Share them in the comments!

I gave two talks at the event: first, an introduction to the Broccoli build tool, entitled “Chocolate-Covered Vegetables”. We discussed how to use the build tool and some essential plugins to get the most of it. Slides for the talk are available on SpeakerDeck:

On the second day, I presented on “Stateful CSS”: a way of adding behavior to web apps with no JavaScript. We discussed building tabs, modals, and more, all with only CSS. The slides (themselves created using only CSS!) are available on GitHub, and the code examples can be found in a CodePen collection.

PrDC is absolutely one of my favorite conferences, and I encourage you to check it out if you ever find yourself in the area in early spring. The organizer, D’Arcy Lussier, knows how to put together a seriously epic conference. If you have any feedback about my talks or their content, let me know in the comments!

{{#each post in posts}}
  <a {{action 'markAsRead' post}}>Mark as Read</a>
{{/each}}

While Controllers are the perfect place for logic used on a single view, you may find that, over time, that behavior becomes duplicated in multiple places. Creating Mixins is one way of DRY-ing up your code (and is the preferred solution for interaction logic), but, in this post, we’ll look at another method that’s more domain logic–friendly.

To begin with, let’s take a look at a simple Controller that contains both interaction and domain logic:

Ember.Controller.extend({
  actions: {
    readMoreLess: function(post) {
      post.set('expanded', !post.get('expanded'));
    },
    markAsRead: function(post) {
      post.set('read', true);
    }
  }
});

Expanding and collapsing a blog post’s content is clearly an interaction concern (in other words, not something you’ll likely want to persist to a database), but marking a post as “read” is probably something more meaningful to your application. If we move this functionality to a Model object, our action handler may end up looking something like this:

Ember.Controller.extend({
  actions: {
    readMoreLess: function(post) { /* ... */ },
    markAsRead: function(post) {
      post.markAsRead();
    }
  }
});

At this point, there’s not much use for having an action on our Controller that does nothing but delegate out to the Model for this behavior. Fortunately, we can hook into Handlebars for a solution:

{{#each post in posts}}
  <a {{action 'markAsRead' target=post}}>Mark as Read</a>
{{/each}}

By telling Handlebars what the target of this action should be (in this case, the post object itself), we can bypass an explicit action handler on a Controller entirely (and it’s entirely possible you may be able to completely remove a Controller in some cases) and call a function directly on that Model. Note, however, that the function names must match exactly between your templates and your model objects (much like a Controller’s action’s name must match the template):

BlogPost.reopen({
  markAsRead: function() { /* ... */ }
});

This approach won’t work in all cases, and you’ll want to keep an eye on your behavior to make sure you’re only including domain logic in Model objects (remember: interaction logic duplication should be kept in check with Mixins), but hopefully you’ll find your Controllers are cleaner and more expressive as a result.

If you’re unfamiliar with the concept, icon fonts are a way of symbols in your web apps without requiring images. They’re contained in a single typeface file (which means they only cost a single HTTP request), vector (so they’re infinitely scalable), and, since it’s still technically text, can be styled with CSS. A wide variety of icon fonts are available for use (many of them free), but some designs need a custom touch. In this post, you’ll see just how easy it is to make your own icons with some great tools.

What you’ll need

The only hard requirements you’ll need for this exercise are a) a vector graphics editor that can export to SVG (I’ll be using Adobe Illustrator) and b) and internet connection (one of the tools is online). Naturally, it helps to have some experience with the graphics editor you choose, but if you know how to draw lines and basic shapes, you’ll be just fine.

Making the icons

To start, we’ll create a new document in Illustrator. Illustrator supports multiple “artboards” in one document, so we can make each one the exact size of our finished icons and keep them all in one file. For this example, we’ll use icons that are 16 pixels square, but you could choose any size that fits your design (though I generally stick to sizes in multiples of 8 pixels since they’re easier for me to design).

Next, create the icon. Illustrator has a myriad of tools available for this, but I find myself using the Pen and Line Segment tools most often. The most important thing to keep in mind at this point is to stick to whole values for sizes and positions; putting a half-pixel-thick line in-between pixels is a one-way ticket to Blursville. In Illustrator, you can check the potential blurriness of an icon by turning on Pixel Preview (View > Pixel Preview) and zooming in. I generally use a one-pixel grid while designing to make sure everything lines up just so, and check with Pixel Preview frequently.

For this example, we’ll create a simple “delete” icon. I used perpendicular lines to form an ‘x’, and made each one two pixels thick. Rounded caps may not add much visual interest for some screens, but if any of your users have high-density displays, they’ll appreciate the extra level of detail. (Note: in this image, I’ve reduced the opacity of the lines so you can see how the anchor points align perfectly with the pixel grid.)

As I mentioned, I generally work with lines when making icons, but feel free to experiment with any of the vector tools at your disposal. Remember, though, that only vector shapes can be used for icon fonts, so any raster images (drop shadows are a common example) won’t come across in the final icon.

There’s one last thing we need to do before moving on: while lines are great to work with while constructing icons, icon fonts require filled shapes instead. To do this, “expand” the lines into shapes with the “Expand…” (Object > Expand…) command. Next, I typically merge the two now-shapes together to make a single path with the “Union” command of the “Pathfinder” palette (Window > Pathfinder).

Exporting the icons

Now that we’ve created our icon, we’re ready to export it to SVG. Illustrator makes this process incredibly easy, as you can save a document directly to that format. Here’s how:

1. Choose File > “Save a Copy…”. The “Save As…” command also works, but changes your open document to the saved copy, meaning you have to close it and re-open your original Illustrator file. “Save a Copy…” doesn’t do this.
2. From the “Format” selector, choose “SVG (svg)”, and click “Use Artboards” below it. If you so choose, you can also specify a certain range of artboards to export, but I typically export all of them at once so the output SVGs are never out of sync with my Illustrator file. If you have more than one or two icons in this file, you may want to save the SVGs in a separate folder: each artboard will become a separate file.
3. Next, you’ll select some options for the output SVG. I follow Adobe’s recommendations for the web from “Exporting SVG for the web with Adobe Illustrator CC”; scroll to the “Best export options for the web” section. When you click “OK”, your artboards will be turned into SVGs!
4. (Optional.) I find Illustrator does a passable job of exporting concise SVG markup, but, if you’d like to take another pass at it for some extra saved bytes, I recommend the SVGO app. You could also edit out any extra line breaks and decimal places by hand if you’re so inclined.

Creating the icon font

At this point, you should have a number of SVGs that are all exactly 16 pixels square (or whatever your base size is) and nicely contained into their own files. There are a couple of options for you at this point: you could simply use the SVGs in your sites directly (SVG support in browsers is quite nice, as it happens), but that’s a different post. Instead, we’re going to create an icon font out of our SVGs using the awesome IcoMoon app.

To get started, fire up the IcoMoon app. There are some great sets included with IcoMoon by default, but we’re creating our own, so feel free to ignore those.

Click “Import Icons” and navigate to your icon folder. Select any of the icons you’d like included in this font and click “Open”. If all goes well, you should instantly see your newly-crafted icons. If, instead, you see blank boxes, check that you converted your lines to shapes (in “Making the icons” above). By default, none of the icons we’ve uploaded are included in this icon font, so make sure the “select” tool (the first icon with the mouse cursor) is active, and click your uploaded icons. Each selected icon is outlined.

At this point, you technically already have an icon font. If you want, you can stop here, click “Generate Font” at the bottom of the app window, followed by “Download”, and use this font in your app; however, there are some optimizations we can perform at this point to make our lives as web designers easier.

First, I like to turn on “Quick Usage” (available in the “Generate Font” screen). This feature provides us with a <link> tag directly to this icon font, hosted by IcoMoon, that we can drop in to any web app and start using immediately. Upgraded plans feature permanently-available links, while the free version keeps them alive for 24 hours.

Next, I give names to each icon. IcoMoon uses the SVG file names to prepopulate names for each icon, so you’ll often end up with values like “iconcopy_delete”, which isn’t very clear (you’ll be forced to use this verbose name in your HTML, too). Just select the text and replace it with something better, like “delete”. IcoMoon updates your values automatically.

Next steps

At this point, you’re ready to start using this icon font! If you hover over one of the glyphs in IcoMoon’s “Generate Font” screen, you’ll see a “Get Code” link, which opens a modal describing exactly how to consume your newly-minted font. You can either use the <link> from Quick Usage, or download the font files and set it up yourself.

If you’d like to learn more about icon fonts, CSS Tricks has an excellent article on their use. If you’ve made your own icon font that you’d like to show off, or if you have any suggestions for improving this workflow, let me know in the comments!

Like the rounded corner trend of old, however, it’s easy to jump on this particular bandwagon with reckless abandon, adding every conceivable animation without truly understanding why. In this post, we’ll look at a few common web animations, and how they support—rather than supplant—a design’s intent.

The Appear

Admittedly, having an element simply appear on a page isn’t truly an “animation”, but I feel it’s important to list for two reasons: much like every app and site has a “design” even if it has no “designer”, instantly showing an element still qualifies as a transition between two states in your app, even if it’s not in motion per se. And, before the days of JavaScript libraries and CSS animations, it was the only “transition” available. Though The Appear may not stand as proudly as its more “motion-ey” cousins, it’s important to remember that we didn’t always have such refined tools at our disposal.

The Fade

One of the first animations I began using in my designs was the humble Fade. Simply adjusting the opacity of an element over time removes much of the jarring nature of The Appear, and adds an element of subtlety wherever it’s used.

Unfortunately, using The Fade sometimes requires rearranging elements on the page instantly before a new element can fade in, leading to similarly jarring results as The Appear.

The Unfold

The Unfold seems to follow The Fade quite closely in popularity, but, for me, it’s one of the first truly useful transitions I used. While The Fade uses opacity for its transition—an interaction rarely, if ever, seen in the physical realm—The Unfold relies purely on movement, and evokes a sense of opening a door or extracting a letter from an envelope. Revealing content in this way reinforces the sense that the newly-shown information was there all along, just waiting to be freed from its overflow: hidden prison.

The Slide

While The Appear, The Fade, and The Unfold work well for introducing new content, you’ll sometimes need a way to animate the removal of something. The Slide is my go-to solution, as both provides visual interest and supports “removal” metaphor…in fact, it rather reminds me of sweeping papers off a messy desk.

An inelegant follow-up to The Slide is to instantly—and jarringly—delete the space the recently-removed element once occupied, but pair The Slide with The Fold (The Unfold’s helpful cousin), and your users will never be left wondering what happened to their nicely-stacked lists.

The Tint

Sometimes motion isn’t the best way of expressing change. Maybe a green element changes to red to indicate that a server is down, or a toggle switch changes from light to dark to signify it was just selected. In both cases, we’re not relying on movement to indicate change, but, rather, other appearance characteristics: I call this The Tint.

This kind of inline change can be very impactful, especially when numerous items have their statuses updated in real-time, but can even help in very subtle ways, as with a button’s “hover” state.

Beware, however, that if your transitions are too subtle, many users may not notice them. Even seemingly-obvious changes (like a dramatic color shift) may be meaningless to users with difficulty seeing small changes in contrast.

Runners-Up

Two more animations that have gained a great deal of popularity recently are The Flip and The Shake. Though I’m unsure of the exact origin of either of these transitions, I remember first seeing them in native iOS apps.

I typically find The Flip hanging around card-based UIs (cards…card flips…makes sense) to hide less frequently–viewed details without having to break the context of whatever content they were viewing. This animation can be very helpful (or, if you’re building an online trading card game, downright essential), provided it’s obvious enough to people that certain elements can be interacted with in this way.

Anyone who fat-fingers their OS X password is undoubtedly familiar with The Shake. One of the most deliciously-simple animations I’ve ever seen, The Shake is the perfect response to incorrectly input data. You needn’t move your eyes to see that something happened (yet it’s obvious something did), and the gesture so closely represents what many of us do when frustrated: give our phones, monitors, or produce a good jiggle.

The next time you find yourself about to implement some carefully thought-out animation, think about the humble beginnings of what promises to be the Year in Motion for the Web. We’re just getting started bringing some amazing transitions to a historically-static medium, and the future looks more animated than ever before.

Let’s start with a small list of books. In this fictional UI, we’ll show each book’s title and author, and let users filter the list of books by genre:

To begin, we need to polyfill a currently-missing component of Ember: radio buttons. It may seem odd, but these innocuous input fields are the key to this solution: we’ll bind the selected item’s value to an Ember property, which we’ll then use to filter the list. Matthew Anderson wrote a great post on adding support for this input type, so we’ll start by adding the code from that post to the Ember app.

Next, let’s create a Component to house our filtering functionality. This step is optional, but helpful if you plan to filter multiple lists in your app, or if your code’s getting a bit messy.

{{filterable-list list=listToFilter}}

In our Component, we’ll include a property, filterBy, to store the current filter (defaulted to “all”) from the selected radio button, as instructed by Mr. Anderson’s post. Our Component also needs a “proxy” list property (let’s call it filteredList). We’ll display this collection in the UI, and we can use its property function to perform the filtering. To start, this property will return the whole collection, but we’ll filter it shortly. Don’t forget that this property needs to respond to changes for both the list of objects itself as well as the selected filter:

App.FilterableListComponent = Ember.Component.extend({
  filterBy: 'all',
  filteredList: function() {
    return this.get('list');
  }.property('list', 'filterBy')
});

Now let’s write the Handlebars template for this Component. We’ll need to use the new radio button View we added to the app earlier (one for each filter), and loop through the “proxy” list:

<ul>
  <li>
    {{view Ember.RadioButton name='filter' id='filter_all'
      selectionBinding='filterBy' value='all'}}

    <label for="filter_all">All</label>
  </li>
  <!-- other options omitted for brevity -->
</ul>
<table>
  <tr><!-- column headers --></tr>
  {{#each filteredList}}

    <tr>
      <td>{{title}}</td>
      <td>{{author}}</td>
    </tr>
  {{/each}}

</table>

Finally, it’s time to hook up our filtering. We’ll use an object with properties that match those of the radio buttons, and values of functions that will perform the filtering. Then, when either the list of objects or the selected filter changes, we’ll perform the filtering by pulling the matching filter function from that object:

App.FilterableListComponent = Ember.Component.extend({
  filterBy: 'all',
  filters: {
    all: function() {
      // Show all books.
      return true;
    },
    fantasy: function(book) {
      // Show only fantasy books.
      return book.get('genre') === 'fantasy';
    }
  },
  filteredList: function() {
    // Get the filter from our `filters` object.
    var filterFunction = this.filters[this.get('filterBy')];

    // Perform the filtering with an array function.
    return this.get('list').filter(filterFunction);
  }.property('list', 'filterBy')
});

Add in some nice styling, and we’ve got a pretty nice filterable list!

See the Pen Filterable Lists in Ember.js by Tim G. Thomas (@TimGThomas) on CodePen.

Hotel Room Keys

In the past year, I’ve had to request something like three or four additional room keys because I realized I hadn’t grabbed one…right after the room door slammed closed. What’s the solution? The locks in my Norwegian hotel wait for a full minute before engaging, giving you ample time to get to the elevator, remember you left your key, and rush back to the room. What’s more, you can turn the key card around and slide it into the lock to immediately bolt the door, ensuring you can only explicitly lock your room when you have your key card in hand.

In addition to the great at-the-door experience, the light switches just inside the room won’t even turn on unless a room key is inserted, providing both insurance that you don’t leave any lights on when you leave, and a convenient place to store your room key while you’re inside.

Light Switches

Speaking of lights, most light switches I’ve encountered in the States fall into one of two categories. On one side of the spectrum is the style of a tiny, protruding block of plastic. It’s difficult to manipulate without physically pinching the plastic block with two fingers: a feat practically impossible when you’re carrying bags of groceries in both arms, for example.

The alternative is a much larger flattened toggle switch: a “rocker”. While it’s certainly much easier to switch in the aforementioned grocery scenario, I’ve frequently found them to be too sensitive, often turning lights on (or off) when I gently brush past. Their flat shape also makes it difficult to see the switch’s position from far away.

In Norway (and many other countries), however, light switches take on a more thoughtful appearance (see the above photo). The switches are square and generally larger in size, and feature a flat rocker switching mechanism that sticks out some distance from the wall at it’s farthest point. The result is a switch that’s easy to turn on and off (but not too easy) without requiring large amounts of dexterity, yet sizeable enough to be easily seen from across a room.

Cigarette Trash Cans

I’m not a smoker, but it seems many Norwegians are: I encountered a seemingly large number of them in Oslo. What I didn’t encounter a large number of, however, were cigarette butts, and I credit two things with this: one, the Norwegians’ apparent desire to keep their country clean (shocking, I know), and two, these cleverly-obvious trash cans. The punctured recepticle opening practically begs to have a spent cigarette disposed of therein.

Street Signs

The street sign system in the States is adequate, but that doesn’t mean it can’t be improved upon. One of the signs I remember having a problem with is the “do not enter” sign: the graphic itself makes sense, but the signs are often oriented so that you can’t easily see them unless you’re almost directly facing the street you’re forbidden to enter. I sometimes find myself leaning to one side while driving to make sure the sign I’m seeing is, in fact, of the “no entry” variety.

The Norwegian signs of the same purpose feature an ingenious solution: curved metal. From straight-on, the signs appear just as they would otherwise. From a cross street, however, you can still clearly see enough of the sign to realize you shouldn’t make that turn.

Emergency Exit Signs

I’ve been fortunate enough to never need the help of an emergency exit sign, but I always felt I’d be of two minds if I ever did need its navigational assistance: on one hand, I, as a person in hypothetical need of an emergency exit, would be quite pleased to see a convenient and well-labeled escape route. On the other hand, I’ve been trained from a young age that the color red means “stop” or “don’t do this”. Fortunately, the Norwegians (among many other countries, to be fair) have solved this problem entirely: make the exit sign green. The Portal-esque iconography is a nice touch.

Shower Faucets

My least favorite morning ritual involves fiddling with the shower controls for fully half a minute trying to get the temperature just right. My hotel room featured the solution of my dreams: a shower that allowed you to specify the water’s temperature, in degrees, independent of the flow rate. When arriving at a suitably-equipped hotel—I had one in the UK last year, too—I just dial in the temperature before my first shower (a process that takes about three seconds) and never worry about it again.

The Oslo Opera House

By far the most spectacular example of great usability I encountered on my trip, the Oslo Opera house is beautiful, iconic…and can be walked on. Almost the entire roof of the building is effectively a stone-floored plaza (that I’ve been told represents the Norwegians’ enthusiasm for mountain climbing), featuring breathtaking views of the city. What better example of usability than to turn something almost exclusively unusable for the public—a building’s roof—into something an entire city can enjoy?

Even though I interacted with (or sometimes just looked at) these items, experiences, and places only briefly during my trip to Oslo, I remember each one quite well: it’s amazing how some simple solutions to common problems can leave such a profound impact. What examples of great usability have you encountered on your travels?