How Ember Data Loads Async Relationships
This post simply links to each part in the series.
Read on →
This post simply links to each part in the series.
Read on →
Greetings! Please read Part 1 and Part 2 before continuing on.
Part 1 explored how Ember Data responds to a few common scenarios. Part 2 discussed some less straightforward examples. Part 3 will examine how to load relationships when the API does not provide data or links.
Read on →
If you haven’t already read Part 1, I recommend doing that now, as this continues right where we left off.
Part 1 explored how Ember Data responds to a few common scenarios. In Part 2, we will look at some less straightforward examples. Then, in a later post, we will examine limitations of Ember Data.
Read on →
Ember Data has two main ways to load asynchronous relationship data through adapters. It is not always obvious when or why Ember Data calls the adapter hooks that it does, or doesn’t.
In Part 1, we’ll explore how Ember Data responds to a few different common scenarios. In later posts we’ll look at some less-straight-forward examples.
Read on →
NOTE: I originally wrote this when I was still working on Stride. I’ve reposted it here for posterity. Here is the original post.
Reliably delivering time-based emails (daily, weekly, etc.) to users has always been a little tricky for web-based applications. There are multiple possible failure points, and we need to contend with different time zones.
Currently, Stride sends two time-based emails:
We wanted both of these emails to arrive in the user’s inbox in the morning. At first, this seems like a simple specification; we’ll just send the emails off at 7am.
But hold on a minute — if we send the Monday morning email at 7am PST, users in New York won’t get their email until 10am, and even worse, our users in Australia won’t get it until 1am on Tuesday; that certainly isn’t Monday morning. What if we send it early enough so that everyone gets it before Monday morning? Unfortunately, if we send the it at 7am in eastern Australia, our users in Hawaii will get their Monday morning email at 11am on Sunday. That just isn’t going to cut it.
We decided to batch up the emails and send them off depending on each user’s time zone. Here’s how it works:
Read on →
Using I18n and Draper to Render Database Attributes
TL;DR: Check out my additions to ApplicationDecorator in this gist.
Update: This has been released as a gem: Olson.
When my models have an attribute that matters to the code (like Admin#role or User#status), I like to store the value as a string that makes sense as an identifier. For example, User#status might be 'active' or 'awaiting_approval'. However, when it comes time to render the admin’s role or the users status in the view, we want to show ‘Awaiting approval’ instead of ‘awaiting_approval’. Another example of this sort of thing is the #type attribute for STI.
Ok, this isn’t too hard, we can just use #humanize. But, here’s what happens: