A strict type system is one thing that differentiates Swift from Objective-C. This type system, along with other related features like generic types and custom operators, has started a movement among developers to adopt some techniques that Swift’s predecessor made difficult or impossible. Some of these language features and techniques come from the language Haskell, one of the many languages Chris Lattner drew inspiration from in creating Swift.

As I try to learn and adopt these new techniques I feel a bit like a woodworker who’s been given a new tool, one with new features that I don’t completely understand. One trick I’ve learned is that with such a strong type system comes certain affordances.

Let’s look at an example.

Optional has a method called map. Now if you’ve used map functions that are common for collection types you might be able to intuit what this map function does. An Optional isn’t an array, however, so it might still be a little confusing. But if you take a moment to inspect the type of map you will see the trail of breadcrumbs.

1

func map<U>(f: (T) -> U) -> U?

Here we can see that map takes a single function from (T)->U as a parameter and returns an U? (which is just nice syntax for Optional<U>) as a result. Remember that T is the generic parameter type of the Optional on which you are calling map. This effectively allows us to take an object wrapped up in an Optional context and apply a function to it resulting in an Optional object of the given function’s return type.

Higher order functions like map are common in functional programming languages. For example, Haskell defines a function fmap that performs the same operation as Optional.map. Haskell programmers use this function so often that they’ve even given it an operator: <$>, and many Swift programmers are following suit (though, due to some limitations on special characters in Swift, most implementations seem to have settled on <^> for that paricular operation).

When confronted with new symbols and unfamiliar techniques for solving problems in a strictly typed language like Swift, I find it helps to follow the types.

Photo by Seán A. O’Hara. Licensed under CC BY 2.0.

Derrick Hathaway is a Sr. Mobile Engineer at Instructure. He is currently working on making Instructure’s iOS apps more awesome!
Github and Twitter.

Cursor Modes

When you first start building accessible websites, you learn quickly that there are different cursor modes when using Windows screen readers, Léonie Watson explains them well here.

Certain element roles, like application and dialog will change the mode of the cursor. Very often this is not what you want. Yes, It does allow the developer to implement convenient keyboard events for the component, but it disables the normal keyboard navigation shortcuts for screen reader users. For sighted users, that would be a lot like opening your page up in Internet Explorer 5.5 on a mac.

The Problem With ARIA Dialogs

Unlike other components, dialogs and modals usually just contain regular content like the rest of the website. They don’t need special keyboard navigation implementations, except for handling the escape key to request to close it.

When you use role="dialog" the forms/focus cursor mode is activated and the screen reader user can’t interact with the content in the dialog like they can with the rest of the website. In most cases, this results in much of the content in the dialog becoming completely inaccessible to them.

The Solution

The solution is to “hide” everything in the application—except the dialog—from the screen reader. This way the dialog can be navigated normally and the rest of the app is inaccessible until the dialog closes.

In a nutshell:

1. Don’t use role="dialog", to avoid switching cursor modes.
2. When a dialog opens, set aria-hidden="true" on the rest of the page and focus the content of the modal.
3. When a dialog closes, remove the aria-hidden attribute and return focus to the element that initiated it.

The easiest thing to do is simply wrap your entire website in a containing element and then just manage aria-hidden on that one element instead of many.

It would end up looking something like this:

1
2

<div id="app"> ... </div>
<div class="dialog"> ... </div>

And when the dialog is open:

1
2

<div id="app" aria-hidden="true"> ... </div>
<div class="dialog"> ... </div>

But That’s Not The Spec!

The spec probably needs to change to support dialogs where forms mode doesn’t make sense. We implemented this in order to get Canvas certified as an accessible web application. The web moves fast and the specs don’t always keep up.

Until the specs catch up, and all the parties involved implement them, we choose to focus on the experience of our users (oh, right, and getting certified).

Ryan Florence heads up the Web Frameworks team at Instructure where they chase both squirrels and JavaScript frameworks, inviting the rest of the team to join them. Follow his adventures on Github and Twitter.

However, all of that Being in Charge may actually be counterproductive to the mindset that will make you most successful—Not Being in Charge. The truth is, everyone else’s input is far more important than mine.

“But,” you say, “product is supposed to be the mini-CEO and the vision, right? How can you be the vision if you’re not deciding all the things?”

Here’s the secret—what I want doesn’t matter. The only thing that will make us win as a company is making an easier or better way for other people to do what they already do. That means that a good product person works for everyone. Users and buyers of our software (of course), engineers, support, client services, designers, salespeople, QA, executives, marketing—they’re are all my boss. What they need comes way before what I want.

The trick is in the balance. A good product person keeps an eye on where the market is going, what users need today, things that are confusing or broken, code that’s old and crusty, what’s losing sales to competitors, where the terrible UX/UI is, and all the executive initiatives.

However, having all those bosses doesn’t mean you just do what they tell you to do. The other side to the balance is knowing enough about everything to be able to prioritize, say “no,” and live with your bosses’ inevitable disapproval.

Bug fixes bore marketing. Sales features add complexity for support. Engineers are sad working in ancient code. Executives need this thing to make money. To top it off, no one’s asking for what you know they’ll need next year or recognizes the magic in your new car idea.

Sound difficult? It is. You have to be passionate about supporting everyone and really feel their pain. You have to be patient enough to wait if the time isn’t right and spend far more time listening than you do talking. You also have to be okay with very delayed reinforcement. But sometimes, when you get the balance just right, you really do get to be part of making a dent in the world.

Before I dive into the “tips and tricks”, I have to dispell a few myths:

Accessibility Myths

Accessibility only affects blind people

Blind people are not the only ones affected by inaccessible websites; they affect people with motor impairments, color blindness, or cognitive impairments, amongst others. Accessibility testing is necessary because we as human beings should all have access to the web. If you or your company is not doing accessibility testing, bring it up at the next meeting.

Assistive technology is super cheap

Many people rely on screenreading software or a braille display, and it can get very expensive. The license for JAWS, a popular screenreading software, costs anywhere from $895 USD to $1,095 USD, and another couple hundred dollars if you want to buy the upgrade that comes out once each year. Choosing to skip an upgrade may mean that the latest version of your web browser may not work well, or at all. A braille display, which is a device that displays braille using pins that move up and down (a necessity if you are deafblind), can cost thousands of dollars. And this is only for your computer – you have to pay more money on top of that for your mobile devices. Imagine if you had to pay for all that, and it only worked part of the time. It’s like buying a car that only runs on Tuesdays.

Assistive technology is always up to date

Technology changes so fast that, when we buy the newest smartphone, it becomes outdated months later. In the same way, assistive technology is often behind new web technologies. Screenreaders can’t keep up with the fast pace of web development, which includes new features every other week.

All screenreaders are the same, I only have to test with one

Like browsers, not all screenreading software is alike. Mac OS X has a built in screenreader called “VoiceOver”, which you can enable in the Accessibility section of your System Preferences. It also includes a comprehensive guided tutorial. For Windows, two popular options are JAWS and NVDA. NVDA is free and open source, and is available in many languages. For Linux users, Orca, which is also free and open source, is a great option. The screenreader output can greatly vary; when you navigate to a “Close” button on a modal window, you might hear “Button Close Button” from one, but hear “Close Button” from the other. Talk with your users and see what they are using, and if your budget allows, test with as many screenreaders as you can. At Instructure, we test Canvas using the latest version of VoiceOver and JAWS, and are currently evaluating NVDA.

Accessibility testing is the worst kind of testing

Testing of any kind can be painful, whether it be writing unit tests or doing user experience testing. Accessibility testing is also on that list, but realize the more you test, the more aware you will be when writing your code. You will start to look out for things here and there because you had to spend twenty minutes trying to navigate to a submenu in a previous commit.

I can just throw my website at an accesibility evaluator and call it good

An evaluator only looks at the structure of your site; it doesn’t emulate the user experience. We all know that, sometimes, what looks good on paper doesn’t work out in real life. The same goes for an evaluator. It will tell you if your headers are out of order, but it won’t tell you if your navigation is terrible because you are inconsistent with what keypress you are using for a certain element. You need actual people to test your site out. Which brings me to my next point…

Only blind people can do accessibility testing

Anyone who learns the software or hardware can do accessibility testing. At Instructure, we have our Quality Assurance (QA) engineers do a lot of the testing, and all of them are sighted. If you have questions and would like to ask someone who is blind, there are a lot of resources out there. For those in the education sector, many universities have a disability resource center – reach out to the coordinator there, and ask for permission to get feedback. Your city or state may also have a dedicated center. We also have the Internet for a reason; use it!

Where to start and how to test for accessibility

If you haven’t already, run your site through an evaluator. There are many free accessibility evaluators online, where you feed the URL into an evaluator, and it tells you how accessible the page is. Two popular evaluators are WAVE and FAE. If you use FAE, note that it is evaluating in accordance with the Illlinois Information Technology Accessibility Act. Not all evaluators are running against the same guidelines, so find out what it is evaluating against. Many evaluators will use the W3C Web Content Accessibility Guidelines. The evaluator will show you any errors and provide feedback. Do you have redudant title text? Are your forms labeled? These are items that will be pointed out to you, which you can easily fix.

Once you have your baseline, and fixed the structural elements, it’s time to move on to testing with real people. Ask for feedback from your users and see what needs the most attention, and start there. Here are a few of the things we do:

1) On each page we check to see if there are headers, a main landmark, and a complementary landmark (if applicable). We also check for to see if there are any lists, forms, and tables on the page, and use the appropriate screenreader key. Many users navigate using these elements to quickly jump to content on a page. It’s hard to scroll through an entire page, so make sure headers and landmarks are available for easy access.

2) We try to use the keyboard as much as possible. Keyboard navigation is critical to many users, especially those with physical disabilities. Not everyone can use a trackpad for gestures, but most everyone has a keyboard.

3) We heavily reference the keyboard layout and shortcuts provided by the screenreader we are using. When I first started accessibility testing, I used the tab key to go through the page. I didn’t realize there were screenreader users and keyboard only users. If you are unsure of which keys correspond with which action, look up the keyboard layout for your respective screenreader.

4) We look to see if our elements have consistency; not all of the elements on our pages share the same keypress, even if they look the same visually (which, we are working on). For example, don’t have a “Submit” button that reads as a link on one page, and as a button on another. Make sure your elements are all the same under the hood.

5) With links and buttons, we always make sure a user can read the link/button text and execute the appropriate action. Sometimes it will only read the link text and won’t open the link. Don’t assume something works just because you can navigate to it.

6) We look at a page from top to bottom, then outline all the elements in a spreadsheet. For example, under “main body navigation”, I would have “Reads Assignment Title”, “Reads Published Button”, and etc. Organizing and writing out all the elements and the location make it much easier for other people to read and follow your work.

What we do at Instructure isn’t limited to this list; this is merely a springboard for you to start. We also conduct accessibility audits, and actively work with our clients and other vendors. Instructure is also fortunate to have a dedicated accessibility team in addition to engineers who are passionate about accessibility on each individual core team of Canvas.

Tackling accessibility testing may seem like a daunting task, but start with the steps outlined above. Your changes will start out small, and it may seem insignificant, but realize that every effort you make changes the web to be more accessible. Soon, you will be the one teaching others about what you’ve learned, and how to make an accessible product. We at Canvas hope that one day, we’ll be reading a blog post from you.

We are then faced with a dilemma: our app has become too big and too complicated to test, and we no longer want to write tests for it because it is so painful. This is unavoidable. No matter how many conference talks we attend that promise to teach us how to writing clean, maintainable code, we’re still drowning in a bog of bad. The reality isn’t that we’re bad developers, it’s that we don’t dictate our workload, deadlines, or priorities. We have to make sacrifices in our code, which isn’t a bad thing until it is. So how do we fix it? How do we take away the pain?

The short answer: it’s not easy to fix, and it takes time.

Prioritize technical test debt

There is no sense in prioritizing technical debt if you have technical test debt. No one wants to write tests for a messy test suite, and you can’t fix problems in your code if the tests are contributing to them. Start chipping away at test apathy by improving the test writing and running experience. There are a few ways to quickly improve your testing environment.

Clean up your factories and spec helpers

Remove redundant factories or duplicate spec helpers. Helpers with miles of conditionals don’t actually help anyone. Consider refactoring any method that takes a hash of options to be more semantically named. Search for factory settings or attributes, or helper methods arguments, you often find yourself using and make them the defaults instead of a passed argument.

If you’re using a homegrown factory system instead of a gem like FactoryGirl, considering refactoring your factories or completely re-writing them. Lots of bad or unused factories can accumulate when you have many developers working on the same code base.

Using Selenium? Delete your specs

… and re-write them, preferably with a Selenium wrapper, such as Capybara. Using a wrapper will also helper clean up your cluttered helper files for these specs.

Selenium specs are a source of constant pain and heartache for developers: they take a long time to run, and they’re incredibly complicated. It’s a lot of test setup and clicking on stuff for one assertion. In lieu of comprehensive Selenium specs that handle all of your edge cases, improve your unit test coverage (on both the client- and server-side), consider writing end-to-end specs for happy paths, and invest in manual testing where people actually click on things. Simplify your Selenium specs and improve your developers’ happiness by only testing your happy paths and expected error messages.

Organize your spec files properly

Do everyone a favor and fix your nesting. If you’re using RSpec, you shouldn’t have a describe block with a context that has two more sets of nested contexts. If a describe or context block only has one test in it, consider re-organizing to incorporate it with other tests. If you’re writing unit tests, use the #my_method_name syntax to group your tests together. Re-write tests that contain multiple assertions: why do you need to assert two things in one test? Assertions that loop through arrays or hashes are sometimes necessary, but they should only be checking one thing, not multiple attributes of your objects.

Lastly, re-organize your file so it is in roughly the same order as your code. The first method in your class shouldn’t be the second-to-last thing tested. A little file organization goes a long way when it comes to debugging and adding new tests.

Use your tools well

A hammer is not a screwdriver, nor is it a crowbar: don’t make your developers be the whole toolbox.

QA Analysts: real humans you need

Your developers are not your users: they’re your developers. While it is reasonable to expect a level of familiarity with your software, developers ultimately are not the ones using it on a day-to-day basis. They are not the experts on your software. You need experts, and they’re not your developers.

Automation is all fine and dandy, but you can’t automate people: we’re unpredictable and kind of stupid. The huge value in manual QAs and regression tests are that you can actually test your code against the human element. Your QAs Analysts are neither unpredictable nor stupid, but they can replicate that element of humans more realistically than automated tests can.

Regression tests are not a bandaid

Regression tests aren’t just good for finding bugs: they are a tool that can help you spot the holes in your test suite. A bug fix for a regression test shouldn’t just be a fix to the code, it should also repair the holes in your tests. Dig through your spec files: is the spec for that bug missing? Is it testing the wrong thing? Is the setup wrong? Fix it.

Don’t monkey patch it

Use the gems, libraries, and tools as they are actually intended. Your test suite will rapidly spiral out of control (again) if you find yourself ripping apart your tools.

Maintenance mode

Fixing bad tests and cleaning up ugly factories is all well and good, but what happens long term? Maintaining a test suite is just as important as maintaining code. If you walk away from your test suite after putting in so much effort, it will be all:

Don’t wreck your test suite by ignoring it.

Don’t be afraid of repeating yourself

Sometimes DRY code is bad code, especially if you’re creating unnecessary objects or making redundant database calls in your test setup. Clean up the setup that runs before each test, and make sure you’re only creating what you need to.

Abstract after the fact

In the (paraphrased) words of Sandi Metz: it is better to repeat yourself than to abstract the wrong thing. You don’t have the perspective to abstract the right thing at the very beginning of your refactoring and cleaning process. To ensure you’re not recreating the problem you’re trying to fix, periodically block off time to review spec files for duplicate code that can be extracted. It takes time and hindsight, which is why reviewing spec files periodically is just as important as refactoring legacy code.

Remember that tests are code, too

Consider these two quotes:

“Ugh, I have to write code. This has robbed me of my will to live.”

No developer, anywhere, ever.

“Ugh, I have to write tests. This has robbed me of my will to live.”

All developers, on a daily basis.

Why do we dread writing tests so much?

A lot of developers approach tests as an after-the-fact thing: the code is done, it’s time to write tests.

But really, it should be: the code is done now that I’ve written my tests.

The virtue of TDD is that you have to write tests. You can’t write code unless you’ve written tests. This one factor has contributed largely to its success. I’m not advocating for or against TDD, I’m lobbying for you to consider your tests as an essential part of your code.

If anything, a well-written test just proves that you’re right, and who doesn’t love being right?

Liz Abinante is an engineer for Instructure and co-leader of the Girl Develop It Chicago chapter. She is infectiously enthusiastic about web development, teaching, learning, and tacos. She enjoys writing and speaking about education, diversity, and happiness in engineering. Previously, Liz has worked as a writer, editor, and knitwear designer.

Ember Functions, Computed Properties, Observers and More by Deric Abel

Binding to Twitter Bootstrap with Ember by Brett Valentine

Slides

répondez, s’il vous plaît – a deep dive into Ember Promise/RSVP by Daniel Dunkley

Slides

At a high-level, the solution is simple: find all the unused drawables in the project and remove them when you build for release. Historically that’s been a tedious and error-prone process, but not anymore. I’m proud to announce a new open-source script from Instructure: ImageSweep. It will run through every file in your project and check for references to drawable resources using regular expressions to check for instances of R.drawable. and @drawable/. The script will then iterate through the resource folder and delete ALL unused drawable resources.

It’s extremely easy to use. Simply run:

    python ImageSweep.py project_src_directory

where project_src_directory is the relative or absolute file-path where your source code lives. Make sure the chosen directory contains all of your source code and AndroidManifest.xml, but none of the libraries you’ve included. The script auto-determines where the project’s resource folder is and libraries can potentially break this detection.

We recently added this script to our release process for Canvas for Android. In that project, we were able to delete 2,593 files for a total of 72.37 Mbs freed on disk. This correlated to a 46% size decrease on the apk itself and 26% size decrease on the installed application.

To get started, visit the project homepage. Take note of the warnings in the README prior to using the script.

When looking at what was eating up our time, we found the differences between our CI environment and average developer’s environment was at the forefront. Most of us at Instructure use Macs, a few of us Windows, and there are a handful Linux users. Among us, browser choice varies, but the most popular is Chrome. Engineers develop locally using their own OS, browser type/version and the Ruby Selenium driver to power tests. Listed below are a few of the differences we found:

1. AWS images were Ubuntu
2. Variance in browser versions
3. Selenium grid uses Java stand alone server VS local specs running using native Ruby driver
4. Variance in native event capabilities VS Jenkins running exclusively using native events
5. Parallelization in CI vs single threaded specs in developer’s environment

We began to strive for consistency between the average dev environment and the CI environments, where we could, without sacraficing production like implementation. This helped with mitigating many intermittency issues. During this process, it simplified the CI upgrade process while edging maintenance towards dreamland and further from Elm St.

So, what did we do to make this happen? First, all logic for Selenium driver code was changed from Selenium grid\Java stand-alone server to the native Ruby Selenium driver. This change immediately resulted in noticeable stability improvements, and easier resolution for intermittency creep from tests.

In the past, we had challenges reproducing errors, locally, that our CI server would throw because of the variance in environments. We spent a lot of time debugging these errors, and had to create CI environments that devs could SSH into, to debug the spec failures. This was highly inefficient, and not consistent with the nature or true purpose of CI. Making the two environments consistent gave us more time to work on other things, instead of time-consuming and meaningless failures that were challenging and intensive to debug. Now we are easily able to (for the most part) reproduce all errors produced by our CI server.

Along the way, we also found Selenium grid was not the ideal solution for us. The main reason being the variance in spec outcomes between dev environments and CI, resulting in too much overhead for maintenance and upgrades, while also sapping dev time on CI spec debugging. Many shops use a hardware infrastructure that is distributed across multiple boxes and the tests are farmed out to them; this is ideal for Selenium grid. We, however, prefer one big box with parallelization done internally, reducing the need for a Java stand-alone server and Selenium grid. Capabilities for the drivers are consumed from config files written at runtime for different browsers and we have no need to push each test to a Selenium hub to be farmed out to a worker. We found this complicated setup offered little reward and brought on noticeable burden in maintenance and stability while introducing a variance in spec outcomes.

Making these changes made our lives noticeably easier. When managing or implementing a CI environment, we believe it’s prudent to not only consider your core tech architecture, but the relationship with your developer’s workflow. Although complex implementations of Selenium grid and multiple browsers can be beneficial, it may add more complications than are worth it. We recommend a lean implementation of Selenium, using the driver of the native application language for tighter integration and better maintenance with more consistency between test runs.

Ember Run Loop

Jason Madsen (@jason_madsen) discussed the what, why, and how of the Ember Run Loop. Learn how Ember manages the run loop for you, and cases where you will want to manage the run loop. Here’s a hint: speed and testing.

Slides

Testing Your Ember Application using TDD

Eric Berry (@cavneb) presented on how to “Test Drive” your Ember applications. Eric starts from scratch and walks through different types of tests that can be written. By the end, you will have a much better understanding of how to test your Ember application.

Slides | Code

Nerd with us!

Feel free to join our monthly meetups (even remotely). The meetings are posted at http://www.meetup.com/EmberJS-SLC/.

For our inaugural hackthing back in May, I worked on the problem of having lots of objects in memory in Ruby 1.9. Ruby uses a mark-and-sweep garbage collector, so the more Ruby objects you have in memory, the longer each GC run will take. This can be a significant contributor to slow page loads in a large Rails app like Canvas.

At the time, Canvas was localized in 7 languages (we’re now up to 15). We use the excellent I18n gem with a few handy extensions of our own. While I18n’s default in-memory backend is plenty fast, it comes at the cost of having all of those strings in memory. Every new language you add or feature you implement makes the GC problem even worse.

Because localization strings should be static for the lifetime of a Rails process, there is no reason the garbage collector needs to know about them at all. But we still want to keep them in memory for optimal speed.

Enter I18nema, a fast I18n backend that unstops the garbage collector and gets everything running quickly and smoothly :).

What Is an I18nema?

At its core, I18nema is a Ruby C extension that moves I18n’s translations out of Ruby-land and into C structs. It also includes a handful of other optimizations to I18n, leading to some nice all around speedups.

How Is It Administered?

In your Gemfile, do

1

gem RUBY_VERSION >= '2.0' ? 'i18nema' : 'i18nema19'

and then put something like this in an initializer:

1

I18n.backend = I18nema::Backend.new

You can still pull in additional I18n features (e.g. I18n::Backend::Fallbacks). Refer to the README for more information.

How Will It Improve My Quality of Life?

More Get-Up-and-Go

I18nema loads translations into memory much more quickly—over 4x!— making for much faster Rails startup time. While this is just a one time hit, it’s very noticeable when you’re waiting on it (e.g. console, specs). In Canvas, I18nema brings it down to a little over a second (from almost 6).

Minimal Blockage

Because there are fewer Ruby objects, the periodic GC runs are proportionally faster with I18nema. That means faster page loads for your users.

How much faster is a question of how many translations you have versus how many other Ruby objects. Applications that are localized in more languages should see a bigger boost (since the translations make up a bigger share of the original ObjectSpace).

For example, Canvas is translated into fifteen languages, and I18nema reduces both (startup) ObjectSpace and GC runtime by about 15%. As more languages are added, that number should only increase.

I18nema also moves I18n’s normalized_key_cache into C structs. This key cache grows over time (it eventually holds a key/value for every translation key used in the app), so that’s another area where I18nema is nicer on ObjectSpace than vanilla I18n.

More Pep in Your Step

I18nema speeds up translate calls, getting the right text to your users more quickly.

Simple lookups (i.e. no options or interpolation) take a bit over 15% less time.

Lookups with options see slightly bigger gains (over 20% less time), in part due to some speedups on the Ruby side of things (I18n uses Hash#except, which is quite slow when you have a long list of arguments).

Is I18nema Right for Me?

I18nema is not for everyone.

If you’re still on Ruby 1.8, you should not use I18nema. Although I18nema has been tested on Ruby 1.9, 2.0, and 2.1, it has only been benchmarked on 1.9. You may find it less effective on 2.1, due to its dramatic GC improvements.

When using I18nema, you should make sure that your translation files are UTF-8. I18nema cannot be used with .rb translation files (only .yml)

Refer to the fine print for more information and benchmarks.

Objectives

Our old color coding system was pretty simple: we had a list of ten hues, and we assigned them to calendars in order. The drawbacks were that colors would repeat after ten calendars and that the colors used weren’t very appealing.

Another system we considered was our hash-based color generator, which creates a color based on an object name or ID. This would avoid repetition, but unlucky users could end up with three slightly different shades of green for their three courses.

For the new system, then, we had three goals:

• Produce colors that look nice and are accessibly readable for text.
• Allow an unlimited number of colors without repetition.
• Keep colors visually distinct, especially for short lists.

Text colors

The simplest way to generate bright colors would be use HSV and to vary the hue while using 100% saturation and value. For text on a white background, though, this makes yellows almost invisible:

Instead, we use the Lab color space, which adjusts for human sensitivity to green, providing a better measurement of lightness and more evenly distributed hues. This not only looks better, but also helps users with limited vision by meeting WCAG AA contrast guidelines.

Spacing

An easy way to space the colors would be to divide the hue circle by the number of calendars. We didn’t want all of the colors to change whenever a user added a course, though; we wanted to use the same colors for the first three calendars whether there were three or thirty total. To accomplish this, we progressively divide each gap in half: first we use 0°, then 180°, then 90°, then 270°, then 45°, and so on. This way, your first few calendars are always very visually distinct.

Formally, this is essentially an online Thomson problem. We’re lucky to only have to solve the one-dimensional version, but the same basic idea could certainly be used to vary hue and value simultaneously if you wanted to generate many distinct colors and didn’t care about legibility. The spiral point heuristic would probably work well—we’d love to see someone send us a pull request.

Results

We’re always refining our user experience, but we’re happy with the look of our new colors.

We’ve released color-slicer in UMD format under an MIT license, so it should be easy to add to your projects. I hope you’ll find it useful. My favorite part of working at Instructure—better than weekly lunch—is spending most of my time crafting code that we give back to the community. Let us know what you think.

We engineers at Instructure love Ember. We also love to learn about other frameworks and know which tools are the best for the job at hand. One of the newer frameworks to come out is React.

React is Facebook’s new JavaScript library for building user interfaces. I’m excited to see another player in the game of front-end JS frameworks. When we have so much mind share going to a similar problem, we all win.

On the home page (screenshot), there are a few examples of how React can be used. I thought it might be fun to show how each of these can be done using Ember.

A Simple Component

React components take data and return content which is to be displayed. Here’s their example code:

1
2
3
4
5
6
7
8

/** @jsx React.DOM */
var HelloMessage = React.createClass({
  render: function() {
    return <div>{'Hello ' + this.props.name}</div>;
  }
});

React.renderComponent(<HelloMessage name="John" />, mountNode);

Let’s build this in Ember. For something as simple as this example, a Handlebars Helper will do the trick.

1
2
3
4
5
6

Ember.Handlebars.helper('hello-message', function(name) {
  var escaped = Handlebars.Utils.escapeExpression(name);
  return new Handlebars.SafeString('<div>Hello ' + escaped + '</div>');
});

{{{hello-message "John"}}}

Example:

Facebook React vs Ember

A Stateful Component

The stateful component example on the React page is cool. It tracks the elapsed time on a page (since refresh). Here’s their code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

var Timer = React.createClass({
  getInitialState: function() {
    return {secondsElapsed: 0};
  },
  tick: function() {
    this.setState({secondsElapsed: this.state.secondsElapsed + 1});
  },
  componentDidMount: function() {
    this.interval = setInterval(this.tick, 1000);
  },
  componentWillUnmount: function() {
    clearInterval(this.interval);
  },
  render: function() {
    return React.DOM.div({},
      'Seconds Elapsed: ' + this.state.secondsElapsed
    );
  }
});

Since we are maintaining state within the component itself, let’s build it using an Ember Component.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

App.TimeOnPageComponent = Em.Component.extend({
  secondsViewed: 0,

  // Increment the secondsViewed attribute
  tick: function() {
    this.incrementProperty('secondsViewed');
  },

  onInterval: function(){
    Ember.run(this, this.tick);
  },

  // Initiates timer when element is rendered
  startTimer: function() {
    this._interval = setInterval(this.onInterval.bind(this), 1000);
  }.on('didInsertElement'),

  // Ensure that the timer stops when closed
  clearInterval: function() {
    clearInterval(this._interval);
    this._interval = null;
  }.on('willDestroyElement')
});

Example:

Facebook React vs Ember

An Application

The application example is a simple todo list which has a TodoList class (for rendering content) and a TodoApp class (maintains the state and renders the layout). Here’s the code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

/** @jsx React.DOM */
var TodoList = React.createClass({
  render: function() {
    var createItem = function(itemText) {
      return <li>{itemText}</li>;
    };
    return <ul>{this.props.items.map(createItem)}</ul>;
  }
});
var TodoApp = React.createClass({
  getInitialState: function() {
    return {items: [], text: ''};
  },
  onChange: function(e) {
    this.setState({text: e.target.value});
  },
  handleSubmit: function(e) {
    e.preventDefault();
    var nextItems = this.state.items.concat([this.state.text]);
    var nextText = '';
    this.setState({items: nextItems, text: nextText});
  },
  render: function() {
    return (
      <div>
        <h3>TODO</h3>
        <TodoList items={this.state.items} />
        <form onSubmit={this.handleSubmit}>
          <input onChange={this.onChange} value={this.state.text} />
          <button>{'Add #' + (this.state.items.length + 1)}</button>
        </form>
      </div>
    );
  }
});
React.renderComponent(<TodoApp />, mountNode);

When writing this in Ember, we would use both a controller and a handlebars template. The controller will maintain the state and respond to user interaction and the template will display the form and list.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

App.ApplicationController = Em.ArrayController.extend({
  content: function() {
    return [];
  }.property(),

  btnLabel: function() {
    return "Add #" + (this.get('content.length') + 1);
  }.property('content.length'),

  actions: {
    handleSubmit: function() {
      this.get('content').pushObject(this.get('text'));
      this.set('text', '');
    }
  }
});

1
2
3
4
5
6
7
8
9
10
11
12
13

<div>
  <h3>TODO</h3>
  <ul>
  {{#each content}}
    <li>{{this}}</li>
  {{/each}}
  </ul>

  <form {{action "handleSubmit" on="submit"}}>
    {{input value=text}}
    <button type="submit">{{btnLabel}}</button>
  </form>
</div>

Example:

Facebook React vs Ember

A Component Using External Plugins

This example on the React website under A Component Using External Plugins is a great example of encapsulating functionality.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

/** @jsx React.DOM */

var converter = new Showdown.converter();

var MarkdownEditor = React.createClass({
  getInitialState: function() {
    return {value: 'Type some *markdown* here!'};
  },
  handleChange: function() {
    this.setState({value: this.refs.textarea.getDOMNode().value});
  },
  render: function() {
    return (
      <div className="MarkdownEditor">
        <h3>Input</h3>
        <textarea
          onChange={this.handleChange}
          ref="textarea"
          defaultValue={this.state.value} />
        <h3>Output</h3>
        <div
          className="content"
          dangerouslySetInnerHTML={{
            __html: converter.makeHtml(this.state.value)
          }}
        />
      </div>
    );
  }
});

React.renderComponent(<MarkdownEditor />, mountNode);

The caveat to this example is that it assumes that the showdown library is already loaded. In our Ember example, note that the library is loaded in the head.

1
2
3
4
5
6
7
8
9
10
11

App.ApplicationRoute = Em.Route.extend({
  model: function() {
    return { value: 'Type some *markdown* here!' };
  }
});

Em.Handlebars.registerBoundHelper('markdown', function(str) {
  var converter = new Showdown.converter();
  var html = converter.makeHtml(str || '');
  return new Handlebars.SafeString(html);
});

1
2
3
4
5
6

<div class="container">
  <h3>Input</h3>
  {{textarea value=value class="form-control"}}
  <h3>Output</h3>
  {{markdown value}}
</div>

I added Twitter Bootstrap to this example for cleanliness.

Facebook React vs Ember

I haven’t spent enough time with React to be able to convert the Ember examples to it, but I would love to see someone do that for a better comparison.

Eric Berry is a software engineer at Instructure and loves giving back to the community via blog posts and meetups. He was a co-founder of ShareAPhoto, Ltd, a European online photo sharing company which was acquired by Hewlett-Packard in 2006. He was the author of Rails Pocket Reference (published 2008 – O’Reilly). He spear-headed TeachMeToCode.com, a popular on-demand screencasting website dedicated to helping others learn how to program.

The Old Way: AsyncTasks

As of the latest version, we use the built-in AsyncTasks to retrieve data from Canvas’ servers. A quick Google search will explain the numerous issues with our approach: no orientation-change support, no ability to cancel network calls, as well as no easy way to make API calls in parallel. With the exception of Froyo and Gingerbread, AsyncTasks (by default) run in a serialized fashion. In a practical sense, this means that only one AsyncTask is running at any given time. Views that require multiple API calls (the DashBoard currently has 7) run extremely slow; sometimes taking multiple seconds to load.

Introducing Volley and Retrofit

Luckily, there are a few third party libraries that provide support for concurrent background threads, network caching, as well as other features that clean up networking code substantially. The first library that we looked into was Volley, an open-source library written by Google. It’s currently used in AOSP Android as well as most of Google’s first-party applications. The other library we looked into was RetroFit, another open-source library written by Square.

How We Decided

The decision to switch the architecture of our networking code was not an easy one to make. The interface with the Canvas API is a substantial part of our application. At the time of writing this blog post, the Canvas for Android project has about 43,000 lines of actual code. Around 3,500 lines of that code are dedicated to interfacing with the Canvas API (setting up API endpoints, etc). JSON parsing comprises of another 7,300 lines of code. That means that more than 25% of our code is dedicated to retrieving/saving data from the Canvas API. That’s just making the API calls and parsing the results. That doesn’t include any AsyncTask code or caching, which we feel should be categorized as networking code as well.

As you can see, if we were going to switch out our networking code, it would have to be for compelling reasons as it’d be a huge refactor. In order to decide if it was worth it, we did a lot of reading about both Volley and Retrofit. We looked at forums, blogposts, example code; we read as much as we could. We learned a lot, but we will try to summarize it the best we can.

From outwards appearances, they are quite similar in usage. They both allow you to provide a “callback”, which is an interface with two methods that you must override: success and failure. One of the methods will be called on the main thread at the completion of the asynchronous network call. The big difference is in how you specify the API endpoint and what you actually get back.

With Volley, you specify the entire endpoint dynamically (parameters and all) at the time of making the API call. By default, Volley returns a JSONObject or a JSONArray depending on the type of request.

Retrofit, on the other hand, has you set the base endpoint url for all API calls, then it has you build static interfaces that specify endpoints using Java annotations. You can cleanly and dynamically substitute path-segments, POST/GET variables, etc. into the endpoint at the time of making the API call. In order to make an API call with RetroFit, you call a method on the interface, pass in any substitutions, and it will return to you a java model object. By default, Retrofit does the JSON parsing automatically using GSON (which is really, really fast) although you can plug in your own JSON parser if you want. Even though the setup is slightly different, the actual API calls are done in a similar way.

In order to get some performance benchmarks, We wrote a sample application where we could control/simulate real-world API calls that Canvas for Android actually makes. It would also give me a little bit of experience actually using the libraries. To start off with, we wrote a very basic app that allowed me to toggle between an easy API with little JSON parsing and a complex API with a long response. The total number of API calls to make could be changed in the app as well. We also included the exact suite of API calls that the Canvas for Android Dashboard makes for a more real-world test. This benchmark showed me three things: 1) they were both significantly easier to use than AsyncTasks, 2) they both cleaned up the codebase, and 3) they were both a lot faster than what we were currently doing. Obviously the benchmarks fluctuated based upon network conditions; however, they consistently outperformed the way we are currently doing our networking.

In all three tests with varying repeats (1 – 25 times), Volley was anywhere from 50% to 75% faster. Retrofit clocked in at an impressive 50% to 90% faster than the AsyncTasks, hitting the same endpoint the same number of times. On the Dashboard test suite, this translated into loading/parsing the data several seconds faster. That is a massive real-world difference. In order to make the tests fair, the times for AsyncTasks/Volley included the JSON parsing as Retrofit does it for you automatically.

At this point, we wanted to switch our networking library for performance reasons, but our decision had to take other criteria into consideration. If we were going to spend time refactoring a quarter of our code base, we would have to be a little bit picky. Some of the things we took into account were speed, ease of integration, code cleanup, scalability, and time required to write new API calls.

RetroFit Wins

In the end, we decided to go with Retrofit for our application. Not only is it ridiculously fast, but it meshes quite well with our existing architecture. We were able to make a parent Callback Interface that automatically handles the error function, caching, and pagination with little to no effort for our APIs. In order to merge in Retrofit, we have to rename our variables to make our models GSON compliant, write a few simple interfaces, delete functions from the old API, and modify our fragments to not use AsyncTasks. Now that we have a few fragments completely converted, it’s pretty painless. There were some growing pains and issues that we had to overcome, but overall it went smoothly. In the beginning, we ran into a few technical issues/bugs, but Square has a fantastic Google+ community that was able to help us through it. We have successfully converted our entire app to Retrofit. A build that’s running solely retrofit can be expected in the Play Store in the coming weeks.

Feel free to ask questions in the comments if you have any.

Resources:

Retrofit:

• Source and Samples (Source and samples)
• Square Homepage
• Square Google+ Community

Volley:

• Source
• Demonstration
• Github of Examples
• Usage Example

The old advice we’ve all heard about using semantic markup, headers, and alt attributes on <img /> tags is still true, but it doesn’t address how we can best develop accessible content in a rich client application. Despite rumors to the contrary, rich content can be accessible if we pay attention to a few basics.

Getting started with accessibility

The Web is fundamentally designed to work for all people, whatever their hardware, software, language, culture, location, or physical or mental ability. When the Web meets this goal, it is accessible to people with a diverse range of hearing, movement, sight, and cognitive ability.

Let’s start with a few definitions:

• Accessibility: Web content is accessible when it usable by persons with disabilities. While this includes users of screen readers, it also includes persons with cognitive and other disabilities.
• WAI-ARIA: A suite of technologies designed to make rich Internet applications accessible to users with disabilities.

Authoring accessible rich content most often means (1) using WAI-ARIA attributes such as role and aria-expanded to mark-up content in a machine-parseable way; (2) ensuring that all content is keyboard navigable; and (3) managing page focus.

So what does all of this mean when you’re developing widgets? Let’s take a look at an example of a button set component.

Building a button set

We’re going to build an accessible button set using Twitter’s Bootstrap styles and jQuery.

Our button set is going to work like a filter, so users can only select one button at a time. This means it’s like a radio button. Watch how we can use aria roles and attributes to convey that behavior to non-sighted users:

1
2
3
4
5
6
7
8
9
10

<div class="btn-group" role="radiogroup">
  <button type="button"
          class="btn btn-default active"
          role="radio"
          aria-checked="true">Open</button>
  <button type="button"
          class="btn btn-default"
          role="radio"
          aria-checked="false">Closed</button>
</div>

First, notice that we didn’t change Twitter’s recommended button set markup — we only augmented it with the role attributes and an aria-checked attribute. The role attribute describes the component’s behavior to screen readers, and aria-checked attribute notifies users of the current option in the same way that the active class does for sighted users.

Here’s the JavaScript to make this happen:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

$.fn.buttonset = function() {
  $(this).on('click', function(e) {
    var $target = $(this);

    $target.siblings()
      .removeClass('active')
      .attr('aria-checked', false);

    $target
      .addClass('active')
      .attr('aria-checked', true);
  });
};

// usage
$('.btn-group .btn').buttonset();

While we’re defining this as a jQuery plugin, we could have just as easily made an Ember component, an Angular directive, or a Backbone view.

We’ve found that this level is often the best place for dealing with accessibility. By handling accessibility details in our reusable widgets and libraries we can code it once and benefit across our stack. New engineers can immediately start writing accessible code, and all engineers benefit from quick, accessible implementations of common patterns.

In this case, our code is almost all standard jQuery. This solution doesn’t require us to manage focus or worry about keyboard navigation because buttons are already in the tab order, but often widget markup will need a tabindex=-1 attribute and calls like $('.item').focus() to ensure that screen reader users aren’t lost on the page.

Here’s our component in action (it’s easier to test with a screen reader if you pop out this example into its own page first):

JS Bin

Testing accessibility

If you’re on a Mac, you already have the software you need to get started testing for accessibility. OSX ships with a screen reader, VoiceOver, that can be enabled in your System Preferences and activated by pressing Cmd-F5.

If you’re on Windows, take a look at the free NVDA or, if you’re doing professional development, the more widely used JAWS.

To ensure that everything we write is accessible, we test all new commits in VoiceOver and JAWS as well as in our supported browsers before merging to master. And while giving accessibility top priority alongside visual fidelity and layout initially slowed us down, we’ve long since adjusted and now have better code and a better product.

Wrapping up

Developing with accessibility in mind has been a great experience at Instructure. By starting with an eye to accessibility we’ve been able to leverage WAI-ARIA tools to create rich, accessible content in an unobtrusive way.

Additional resources

To learn more about accessibility, take a look at the W3’s Authoring Practices document. It covers additional topics like keyboard shortcuts, managing focus, and properly labeling content. The Illinois Center of Information Technology and Web Accessibility also have a great collection of accessibility examples.

Feel free to join in the discussion. If you disagree, don’t be a wimp—speak up.

Look forward to talking more!

Joel CTO