Making this toy app was a fun little project. Building something that promotes positive thinking during this chaotic age gave me the motivation to actually finish it – which is something that can't be said for the majority of the side projects I start. I'd attempted to build something similar to this app a couple times over the years, but always got distracted halfway thru. Spending all Spring indoors, hiding from the pandemic, gave me ample free time to focus on getting it done this time.

This project is written in Python using the Django framework. Python is and has been my favorite programming language since I learned it, and even tho Django is a pretty heavy-duty framework for such a small project, I chose it for educational reasons. Despite having worked with three large Django codebases over the course my career, it feels like there's so much more to learn. So I'm also going to use this project as an opportunity to install new libraries, explore unfamiliar techniques, and dig into the Django internals.

August 24, 2019: This website is no longer maintained.

I created Chicago, Where's My Car? to make it easy to find out if your vehicle has been towed or relocated by the City of Chicago, and to where. It utilizes ember-socrata, the Ember addon I recently created, to consume data provided by the City of Chicago's open data portal.

I recently created an Ember addon for consuming Socrata open data resources: ember-socrata. Subsequently, someone over at Socrata found my library and asked me to write a bit on how to use it, so I created a quick follow-along tutorial and live example.

I was recently hired by a company called Syncano to write their official Ember CLI addon: Ember-Syncano. I'd never written an Ember CLI addon before, so it was a learning experience for me. I feel like I should write more about my experience, but I think I may contemplate my experience a bit more and possibly write a tutorial on the process.

I wrote an article for the Code School blog: Dynamic Sorting in Ember.js to coincide with the recent launch of their new Ember courses.

My twenty-two-year-old self would be proud! His dream of getting paid to be a freelance tech journalist is finally realized ... ten years later. It feels sort of surreal but pretty rewarding to earn a paycheck for writing a tutorial that I probably would have written anyway and published here for free.

January 7, 2019: This article was originally published on the now-defunct CodeSchool.com blog. See the Internet Archive snapshot.

Most modern web applications that display lists or tables of data often offer the user some mechanism for sorting that data dynamically. From the developer’s point of view, this would ideally happen client-side without the need to contact the server and requerying for the resorted data. So today I want to explore how this can be accomplished in an Ember app.

In this blog post, I’ll be assuming you’re using Ember CLI >= 2.3.0. If you’d like to follow along with the tutorial, I’ve created a base project you can check out here, or you can view the completed tutorial code here.

The Scenario

Let’s imagine we’re working on a product review site. We’ve been given the task of creating a component to display the reviews for a given product and allow for them to be sorted by date, rating, or the name of the reviewer.

We open up the Review model and it looks like this:

// app/models/review.js

import DS from 'ember-data';

export default DS.Model.extend({
  date: DS.attr('date'),
  product: DS.belongsTo('product'),
  rating: DS.attr('number'), // score out of 5
  text: DS.attr('string'),
  title: DS.attr('string'),
  username: DS.attr('string'),
});

We see that each review contains a reference to a product, a title, some text, a rating, as well as the date it was written and the username of the user who wrote it. Let’s get started!

The Basics

First, let’s generate the component scaffolding:

ember generate component review-list

Now, since our component will be a list of reviews, let’s update our component’s tag to use the list tag <ul>.

// app/components/review-list.js

import Ember from 'ember';

export default Ember.Component.extend({
  tagName: 'ul',
});

Next, we’ll create a basic template to output the reviews as we received them — no sorting just yet.

{{!-- app/templates/components/review-list.hbs --}}

{{#each reviews as |review|}}
  <li>
    <h3>{{review.title}} - {{review.rating}} out of 5</h3>
    <p>{{review.text}}</p>
    <p>by {{review.username}} on {{review.date}}</p>
  </li>
{{/each}}

Each review is contained inside a list element. It displays a title and the rating out of five, the full text of the review, and a byline. Right now, it’s just pretty simple stuff.

Now, let’s add our component to the Product template:

{{!-- app/templates/product.hbs --}}

<h1>{{model.title}}</h1>

<img src="{{model.image}}" />

<hr />
<h2>Reviews:</h2>
{{review-list reviews=model.reviews}}

If we run:

ember serve

then navigate to http://localhost:4200, we should see a product with a list of reviews in no particular order. Of course that doesn’t make very much sense, so let’s sort the list.

Sorting

First, let’s sort the reviews by date:

// app/components/review-list.js

import Ember from 'ember';

export default Ember.Component.extend({
  tagName: 'ul',
  sortedReviews: Ember.computed.sort('reviews', 'sortDefinition'),
  sortDefinition: ['date'],
});

Ember.computed.sort takes a reference to the collection it will sort as its first argument — in this case, reviews — and a reference to a sort definition as its second. A sort definition is simply a list of properties to sort by. Each property may be followed by :asc or :desc to specify sorting in ascending or descending order. If left off, the property is sorted in ascending order by default, but more on this later. For our purposes, we’re only ever going to sort by one property at a time. And to begin with, we’ll set our sortDefinition to just one property, date. And that’s it — Ember.computed.sort handles the sorting for us! The collection of reviews returned by sortedReviews is now sorted by date. Now we just need to update our template to use the new sortedReviews property instead of reviews:

{{!-- app/templates/components/review-list.hbs --}}

{{!-- ... --}}
{{#each sortedReviews as |review|}}
{{!-- ... --}}

Side Note on the History of Sorting

Previously in Ember 1.x, dynamic sorting was accomplished using SortableMixin. A good amount of material out there still discusses using this mixin for sorting collections. However, in Ember 2, SortableMixin has been removed — though, inexplicably it does not appear in the 2.x deprecations list — in favor of Ember.computed.sort. It’s still possible to use SortableMixin in Ember 2.x via the ember-legacy-controllers addon, but in this article we’ll be using the Ember-2.x-preferred Ember.computed.sort.

Choosing Which Property to Sort By

So, we’ve changed the reviews to be sorted by their date property. But we want to give the user the ability to choose what property to sort on — by either date, rating, or the reviewer’s username.

We’ll add some logic to our component to handle this:

// app/components/review-list.js

// ...
sortedReviews: Ember.computed.sort('reviews', 'sortDefinition'),
sortBy: 'date', // default sort by date
sortDefinition: Ember.computed('sortBy', function() {
  return [ this.get('sortBy') ];
}),
// ...

First, we create a new property in our component called sortBy and, in keeping consistent with the previous iteration, we’ll set the default value to 'date'. Then we update our sortDefinition to be a computed property — not a sorted computed property, just your run-of-the-mill Ember.computed property. We give it the name of the component property, sortBy, to observe for changes and a callback to return the sortBy property in an array. By default, sortDefinition will return the same value as it did before — ['date']. But now we can change the sortBy value to dynamically update the property the collection of reviews is sorted by.

Let’s give the user the ability to update the value of sortBy. I think this is a perfect job for a set of radio buttons — one each for sorting by date, rating, and username. Ember doesn’t come with a built-in radio button input helper, but some fellow Emberists have already created a nice addon for us. Let’s install it so we can use it in our template:

ember install ember-radio-button

{{!-- app/templates/components/review-list.hbs --}}

<div>
  Sort by
  {{radio-button value='date' groupValue=sortBy}} Date
  {{radio-button value='rating' groupValue=sortBy}} Rating
  {{radio-button value='username' groupValue=sortBy}} User
</div>
{{!-- ... --}}

Here, we create a set of radio buttons, each with one of the Review properties we want to sort by as its value. When a radio button element is clicked, the radio-button helper sets the groupValue equal to the element’s value. So for instance, clicking on the Rating radio button will set the sortBy property to 'rating'. You should see that the Date radio button is selected by default, and that clicking on the others changes the sorting of the reviews. Now there’s just one more thing to do — allow the user to reverse the sort order.

Choosing a Sort Order

I mentioned before that a sort definition can contain a :asc or :desc flag to denote whether the sort should be done in standard ascending order or the reverse, descending order. Let’s give the user the ability to choose this sort order.

// app/components/review-list.js

// ...
sortedReviews: Ember.computed.sort('reviews', 'sortDefinition'),
sortBy: 'date', // default sort by date
reverseSort: false, // default sort in ascending order
sortDefinition: Ember.computed('sortBy', 'reverseSort', function() {
  let sortOrder = this.get('reverseSort') ? 'desc' : 'asc';
  return [ `${this.get('sortBy')}:${sortOrder}` ];
}),
// ...

We add a new static property named reverseSort and give it a value of false so that by default, the items are sorted in ascending order. Then we update our sortDefinition computed property to also observe reverseSort. In the callback, we set the sortOrder flag to either 'desc' if reverseSort is true or 'asc' if it is false, then tack that flag onto the sortBy string, separated by a colon. If you were to log the sortDefinition to the console with default values of sortBy and reverseSort, it would return ['date:asc'].

Now let’s update our template to put the sort ordering choice in the hands of our users.

{{!-- app/templates/components/review-list.hbs --}}

{{!-- ... --}}
<div>
  {{input type='checkbox' checked=reverseSort}} Reverse sort
</div>
{{!-- ... --}}

By default, the Reverse sort checkbox will be unchecked, but when the user checks it, the order of the items will be reversed.

You should now be able to manipulate not only the property the reviews are sorted by, but also whether or not they are shown in ascending or descending order!

Even More Sorting

As I hinted at before, Ember.computed.sort can handle a multivariate sort definition that contains multiple properties by which to sort, each in either ascending or descending order. So even if you have some very specific sorting needs, Ember.computed.sort should be able to handle them.

That said, don’t try to reinvent the wheel. The great thing about the Ember community is that there are so many awesome addons out there. For instance, if you’re looking to sort, filter, and search a data table based on multiple criteria, give the ember-models-table addon a try. In general, EmberObserver.com is a great place to find just about any kind of Ember addon you can imagine. Have your own favorite addons? Let me know in the comments section below!

If you would like an Ember refresher, Code School’s Ember.js course, Try Ember, is a great place to start.

California Crystal is a simple WordPress brochure site utilizing a purchased, prepackaged theme. Unfortunately, the theme turned out not to that well designed (but it was really cheap, so I guess that's to be expected), so I had to make some heavy modifications to it to make it work. All in all, the customer was really satisfied with the site.

I guess you could say that I'm an Elixir core contributor now, no big deal.

Elixir came back onto my radar recently because someone made a pull request to a library that I had written and promptly abandoned over a year ago. Even just working through the simple fix for my library and contributing that minor correction for the URI module in the standard library that I mentioned above has reinvigorated my interest in the language. I had forgotten how simultaneously foreign but comfortable Elixir is for me. I find it exciting to write in, which I can hardly say of the other languages I'm familiar with. I need to hurry up and finish the other side projects I'm juggling at the moment so I can find some idea worth implementing in Elixir.

List Maker is a fun side project written in Ember. It utilizes the EmberFire and Torii addons to authenticate (so far, only using Facebook) and store data via the Firebase service.

Anonymous users can browse and read lists. Authenticated uses can start new lists and add items to any list. List items consist of a title and an optional description and image. Users are only allowed to edit and delete lists and items that they have contributed.

Rough patches:

• Input validation
• Error handling
• Error feedback
• UI in general

Features still to come:

• User's view of their contributed lists and list items
• User voting/liking for lists and items
• List and item ranking
• More authentication platform options
• Social media sharing options

I created this follow-along demo for my User Authentication Made Easy with Firebase tutorial. It's written in Ember and uses the EmberFire and Torii addons for authenticating via the Firebase service. It also makes use of the Bootstrap and Font Awesome addons to make it more visually appealing.

The app allows the user to sign up, sign in, and sign out. When they are authenticated, users can see the Welcome page that displays their user information. The app demonstrates action-based redirection (eg. When the user signs in, they are taken the the Welcome page) and authentication-based redirections (eg. If the user is not authenticated, they are redirected from the Welcome page to the Home page). The app specifically lacks input validation and proper error handling, as those items were out of the scope of the tutorial and left up to the reader to implement.

Note: This tutorial is for version 2.x of the Firebase SDK and some of its content may be outdated.

No matter what sort of application you're creating, you almost always have to allow your app's users to sign in and out. Including user authentication functionality in a project is time-consuming, often wrought with gotchas, and just plain boring. It's necessary to make your app function, but it takes time away from getting to the nitty gritty of what your app is actually designed to do.

I've been messing around a bit with Firebase recently. It's an interesting "cloud"-based noSQL data store. But the feature that really caught my eye about it is its user authentication capabilities. The authentication feature is billed as an ancillary side benefit to the main data storage functionality, but I think that Firebase makes it so simple to do user authentication for client-side web applications, that I'd even recommend using it for just that feature alone! I'd like to show you just how easy it is to make an authenticated web application using the Ember framework and Firebase.

What You Need to Begin

In this article, I will assume you have Ember CLI installed. I will also assume you have at least a basic familiarity with Ember. I'll go into detail about the code we're writing as we go, but I won't be doing an exhaustive, line-by-line break-down. The Ember documentation is pretty good, though, and can fill in any gaps I might leave. You can see a live demo of the code here. All the code for this demo is located at https://github.com/zachgarwood/ember-firebase-demo.

So, let's get started!

Setup and Configuration

Ember

Create a new Ember project and jump into the project directory:

ember new ember-firebase-demo
cd ember-firebase-demo/

Firebase

To set up Firebase to handle user authentication, go to https://firebase.com, sign up for a free account, and create an app. Go to your app's management screen by clicking the Manage App button. In the sidebar menu, select the Login & Auth tab, then check the Enable Email & Password Authentication box.

To set up our project to use Firebase, go back to your terminal and install the EmberFire addon:

ember install emberfire

When it's done installing, you should have a new app/adapters/application.js file and a new firebase property on the ENV object in the application's config file (config/environment.js). Replace "YOUR-FIREBASE-NAME" with whatever you named your Firebase app (in this example, "ember-firebase-demo"):

//config/environment.js

module.exports = function(environment) {
  var ENV = {
//...
    environment: environment,
    contentSecurityPolicy: { 'connect-src': "'self' https://auth.firebase.com wss://*.firebaseio.com" },
    firebase: 'https://ember-firebase-demo.firebaseio.com/',
    baseUrl: '/',
//...
  }
}

Torii

We will install and use the Torii addon to manage our authentication sessions:

ember install torii

We will need to manually create an adapter so that Torii and EmberFire play nice with each other:

// app/torii-adapters/application.js

import Ember from 'ember';
import ToriiFirebaseAdapter from 'emberfire/torii-adapters/firebase';

export default ToriiFirebaseAdapter.extend({
  firebase: Ember.inject.service()
});

Here we're extending the Torii adapter that EmberFire already provides for us and injecting the Firebase service that we previously set up.

Then, once again in the app's config, we need to set the name of the session service that Torii provides:

// config/environment.js

module.exports = function(environment) {
  var ENV = {
//...
    firebase: 'https://ember-firebase-demo.firebaseio.com/',
    torii: { sessionServiceName: 'session' },
    baseUrl: '/',
//...
  }
}

Here we set it to "session." Torii will automatically inject this service into our routes and controllers.

Bootstrap and Font Awesome

In order to make our Ember Firebase Demo app look pretty, we'll install the Bootstrap and Font Awesome addons:

ember install ember-bootstrap
ember install ember-cli-font-awesome

Building the App

We've got everything installed and configured, so let's start our app:

ember serve

When you point your browser to http://localhost:4200, you should see "Welcome to Ember."

The Basic Templates

Let's remove the welcome message and give our application a navigation bar:

// app/templates/application.hbs

<nav class='navbar navbar-default'>
    <div class='container'>
        <div class='navbar-brand'>EmberFirebaseDemo</div>
    </div>
</nav>  
<div class='container'>
    {{outlet}}
</div>

Now let's create some content for the index route so we're not just staring at a mostly blank page:

// app/templates/index.hbs

<div class='page-header'>
    <h1>You must be signed in to use this app</h1>
</div>

Signing Up

The first bit of functionality we need to create is allowing new users to sign up. First, we'll need to generate a new controller:

ember generate controller sign-up

This generated an app/controllers/sign-up.js scaffolding file. Let's create a signUp action in that file:

// app/controllers/sign-up.js

import Ember from 'ember';

export default Ember.Controller.extend({
  firebase: Ember.inject.service(),
  actions: {
    signUp() {
      let controller = this;
      this.get('firebase').createUser({
        email: this.get('email') || '',
        password: this.get('password') || '',
      }, (error, data) => {
        if (error) {
          console.log(error);
        } else {
          controller.set('email', null);
          controller.set('password', null);
        }
      });
    }
  }
});

Here we inject the firebase service. Then, in the signUp action, we get the service we just injected and pass in the user's email and password, along with a callback, into its createUser method. In the callback we check to see if there were any errors. (For the sake of expediency in this demo, all of our error handling will be in the form of logging to the console.) If there were no errors, the user is now signed up, so we clear the email and password properties.

But where are the email and password values coming from? We'll have to create a form, so that the user can provide them.

Generate a new route:

ember generate route sign-up

This will add a sign-up route to app/router.js as well as create scaffolding route and template files. Let's update the template it created:

// app/templates/sign-up.hbs

<div class='page-header'>
    <h1>Sign Up</h1>
</div>
{{input
    type='text'
    class='form-control'
    value=email
    placeholder='email'
}}
{{input
    type='password'
    class='form-control'
    value=password
    placeholder='password'
}}
<button
    class='btn btn-default'
    {{action 'signUp'}}
>
    {{fa-icon 'user-plus'}} Sign Up
</button>

We created email and password fields and a button with a signUp action.

Now let's add a Sign Up link to our index template:

// app/templates/index.hbs

<div class='page-header'>
    <h1>You must be signed in to use this app</h1>
</div>
<div class='list-group'>
    {{#link-to 'sign-up' class='list-group-item'}}
        Sign Up
    {{/link-to}}
</div>

So, now we should see a Sign Up link on our index page. When we click it, we'll be taken to the sign-up route and presented with a form. When we fill out the form and press the Sign Up button, the form fields should reset if the sign up was successful. You can confirm that a user was created by going back to the Login & Auth tab of your Firebase app's management screen. At the bottom there is a Registered Users table. If you don't see your email address, try hitting refresh list.

Signing In

Now that our users can sign up, we need to let them sign in. As with the last step, we'll need to create a controller:

ember generate controller sign-in

Then we'll create the signIn action:

// app/controllers/sign-in.js

import Ember from 'ember';

export default Ember.Controller.extend({
  actions: {
    signIn(provider) {
      let controller = this;
      this.get('session').open('firebase', {
        provider: provider,
        email: this.get('email') || '',
        password: this.get('password') || '',
      }).then(() => {
        controller.set('email', null);
        controller.set('password', null);
      }, (error) => {
        console.log(error);
      });
    }
  } 
});

Here we get the session service (remember, Torii automatically injects it into our routes and controllers) and create a new Firebase session instance by passing in the action's provider parameter and the user's email and password to the open method. On success, we clear the form, and on error we log to the console.

Again, we need a form to collect this information, so let's generate the route:

ember generate route sign-in

Then we'll update the generated template. It will look remarkably similar to the Sign Up template:

// app/templates/sign-in.hbs

<div class='page-header'>
    <h1>Sign In</h1>
</div>
{{input
    type='text'
    class='form-control'
    value=email
    placeholder='email'
}}
{{input
    type='password'
    class='form-control'
    value=password
    placeholder='password'
}}
<button
    class='btn btn-default'
    {{action 'signIn' 'password'}}
>
    {{fa-icon 'sign-in'}} Sign In
</button>

The notable difference is in the button's action, specifically the additional 'password' string parameter. This corresponds to the provider parameter that we saw passed into the signIn action in the controller. This parameter denotes the authentication provider, in this case Firebase's own Email & Password Authentication provider.

Finally, let's add a Sign In option to our index template:

// app/templates/index.hbs

<div class='page-header'>
    <h1>You must be signed in to use this app</h1>
</div>
<div class='list-group'>
    {{#link-to 'sign-up' class='list-group-item'}}
        Sign Up
    {{/link-to}}
    {{#link-to 'sign-in' class='list-group-item'}}
        Sign In
    {{/link-to}}
</div>

Now you should be able to go to http://localhost:4200/sign-up to create credentials, then go to http://localhost:4200/sign-in to enter those credentials and sign in. If the sign in is successful, the form will clear and you will be an authenticated user.

The Session

We just used the Torii session service to create a new session instance with the open method. Let's see what else we can do with it.

I mentioned how Torii automatically injects the session service into our routes and controllers. So, by extension, session is available in our templates, as well. Let's update our sign in template to utilize it:

// app/templates/sign-in.hbs

//...
{{#if session.isWorking}}
    <button class='btn btn-default' disabled='disabled'>
        {{fa-icon 'spinner' spin=true}} Signing in...
    </button>
{{else}}
    <button
        class='btn btn-default'
        {{action 'signIn' 'password'}}
    >
        {{fa-icon 'sign-in'}} Sign In
    </button>
{{/if}}

We check the isWorking property of the session service to see if Torii is currently in the process of authenticating a user. If so, we display a disabled Signing In button with a spinner. If not, we display the regular Sign In button.

So now, when we go to http://localhost:4200/sign-in, enter our credentials, and sign in we should see the button change as we wait to be authenticated.

"But wait!" an astute observer might exclaim, "didn't we previously sign in? Shouldn't we still be authenticated?" That's correct. But since the page has refreshed and our app reloaded since then, it has lost track of our session.

So, let's add some functionality to our application route so that whenever our app reloads, our application retrieves the current session:

// app/routes/application.js

import Ember from 'ember';

export default Ember.Route.extend({
  beforeModel() {
    this.get('session').fetch().catch((error) => {
      console.log(error);
    });
  }
});

We've added a beforeModel hook that is executed as the application route is initializing, ie. before any of the other routes. It simply calls fetch on the session service to retrieve the current user's session, if it exists.

Signing Out

Let's allow our users to sign out from anywhere inside our app. To do that we'll first need to create an application controller with a signOut action:

// app/controllers/application.js

import Ember from 'ember';

export default Ember.Controller.extend({
  actions: {
    signOut() {
      this.get('session').close();
    }
  }
});

We simply call close on the session service.

Now let's add a Sign Out button to our application template:

// app/templates/application.hbs

//...  
    <div class='container'>
        <div class='navbar-brand'>EmberFirebaseDemo</div>
        <div class='navbar-right'>
            {{#if session.isAuthenticated}}
                <button
                    class='btn btn-default navbar-btn'
                    {{action 'signOut'}}
                >
                    {{fa-icon 'sign-out'}} Sign Out
                </button>
            {{/if}}
        </div>
    </div>
//...

We used the session service's isAuthenticated property to check to see that the user is signed in before displaying the Sign Out button. Because what's the point of giving the user the option to sign out if they're not even signed in!

Welcome Page

So, now that our users can sign up, sign in, and sign out, let's create a welcome page for users once they have signed in. First, generate the route:

ember generate route welcome

Then we update the template to display information about the authenticated user:

<div class='page-header'>
    <h1>Welcome, you are signed in!</h1>
</div>
<div class='panel panel-default'>
    <div class='panel-heading'>{{session.currentUser.email}}</div>
    <div class='panel-body'>
        <img src='{{session.currentUser.profileImageURL}}' />
    </div>
</div>

Now, if you're signed in and you go to http://localhost:4200/welcome, you should see a panels with your email address in the header and your avatar in the body.

Redirection

Depending on what actions our users take and whether or not they are signed in, we want them to be redirected to various routes of our application:

• When they successfully sign up, they should be taken to the Sign In route
• When they successfully sign in, they should be taken to the Welcome route
• When they sign out, they should be taken to the index route
• When they try to access the Sign Up and Sign In routes while authenticated, they should instead be taken to the Welcome route
• When they try to access the Welcome route while not authenticated, they should instead be taken to the Sign In route

Action-Based Redirection

Let's start with the redirection that happens when the user completes an action.

Let's add redirection to the sign-in route in the signUp action:

// app/controllers/sign-up.js

//...
    signUp() {
      let controller = this;
      this.get('firebase').createUser({
        email: this.get('email') || '',
        password: this.get('password') || '',
      }, (error, data) => {
        if (error) {
          console.log(error);
        } else {
          controller.set('email', null);
          controller.set('password', null);
          controller.transitionToRoute('sign-in');
        }
      });
    }
//...
});

And add redirection to the welcome route in the signIn action:

// app/controllers/sign-in.js

//...
    signIn(provider) {
      let controller = this;
      this.get('session').open('firebase', {
        provider: provider,
        email: this.get('email') || '',
        password: this.get('password') || '',
      }).then(() => {
        controller.set('email', null);
        controller.set('password', null);
        controller.transitionToRoute('welcome');
      }, (error) => {
        console.log(error);
      });
    }
//...
});

And then add redirection to the / route in the signOut action:

// app/controllers/application.js

//...
    signOut() {
      this.get('session').close();
      this.transitionToRoute('/');
    }
//...

Authentication-Based Redirection

Now let's add in some redirection that occurs based on the user's authentication status.

Let's add redirection to the welcome route when an authenticated user attempts to go to the sign-up or sign-in routes; update both app/routes/sign-up.js and app/routes/sign-in.js:

// app/routes/sign-up.js and app/routes/sign-in.js

import Ember from 'ember';

export default Ember.Route.extend({
  beforeModel() {
    if (this.get('session.isAuthenticated')) {
      this.transitionTo('welcome');
    }
  }
});

Here we're checking the isAuthenticated property of the session service in the beforeModel hook, while the route is initializing. If the user is already signed in, they will be redirected to the welcome route.

Now let's add redirection to the / route when a non authenticated user attempts to navigate to the welcome route. This is going to be a little bit more indirect than our previous updates. First, we're going to add an accessDenied action to our application's route:

// app/routes/application.js
import Ember from 'ember';

export default Ember.Route.extend({
  beforeModel() {
    return this.get('session').fetch();
  },

  actions: {
    accessDenied() {
      this.transitionTo('/');
    },
  },
});

All this action does is redirect to the index route. So, how do we call this action when non authenticated users try to access routes that require authentication? Well, Torii provides us with a special route method called authenticatedRoute that we can use in our router map. If a non authenticated user navigates to an authenticated route, Torii will invoke the accessDenied action.

Let's update the welcome route to be an authenticated route:

// app/router.js

//...
Router.map(function() {
  this.route('sign-up');
  this.route('sign-in');
  this.authenticatedRoute('welcome');
});
//...

Try navigating to each route while signed in and then again when signed out. You should be redirected appropriately.

Whatever It's Actually Supposed to Do

So, now you have an Ember application with user authentication! It's a little rough around the edges and not quite production-ready, to be sure; you'll want to do some input validation, put some error handling in place, and update the project's content security policy in your config for starters. But now you can start focusing on whatever it is that your app is actually supposed to do.

Literally minutes after I started splashing this newly launched freelance portfolio site all over my social media yesterday, my hosting provider went down. What luck, huh?

I should have anticipated it, though. Linode, my hosting provider, had been under attack for the past week or so (you can read all about it on their status page), and even when I'd been setting this site up, I'd experienced some intermittent outages.

So, I spent some time this morning migrating the site to a new hosting provider, DigitalOcean, and cancelled my service with Linode. I feel a little bad abandoning them after I've used their service for years (mainly just futzing around with side projects). After all, it's not their fault that some ne'er-do-wells have a vendetta against them and have been trying to bring their service down day after day. In the end, loyalty is great; however, if I'm going to rely on this site to help me reach potential clients and make a living, I can't pay them to host a site that no one can see.

So far I'm pretty impressed with DigitalOcean. The interface is clean and easy to understand, and they've got pretty good documentation. They even have a cheaper hosting option than what I was using at Linode that better serves my needs. All in all, I'd say this was a change for the better.

Written in Javascript, using Ember with the Bootstrap addon for the interface and Express and MongoDB for serving and managing the data, this commission was a simple UI to be used on a company's intranet for viewing the differences between various versions of JSON objects.

The user clicks on an object ID in the Objects panel on the left and is shown a list of revision dates for that object. Checking one or more dates displays the data for the revisions in the Data panel on the right. When a given key does not appear in a revision, the corresponding table cell is blank. When a value for a particular key has changed from one revision to the next, the corresponding table cell is highlighted in the latter revision.

See the code on GitHub.