DockYard blog

Building a Shared Language

2017-05-30 00:00:00

When we start a project at DockYard, we rely on a process that we refer to as âDiscovery.â This exploratory period occurs at the start of an engagement and helps to uncover the parameters of a project. We treat discovery as an opportunity to identify stakeholders, business goals, project requirements, user types, communication expectations, etc.

During a discovery we select techniques to help distill out problems. These problems then inform decisions for building a product. Over time this process has gotten more efficient but I wouldn't say it's gotten easier. Strictly because every project drums up a different set of problems, each unique to the design and the industry we're designing for.

Recently, our design team read Practical Design Discovery, a great resource, chock-full of strategies and techniques for running a valuable discovery. One section that I found interesting talked about "building a shared language."

A crucial component of discovery is understanding - understanding the people, the users, & the problems. For this, we rely on language. However, as with any new project comes a glossary of new terms often referenced while explaining a project's goals. If it's an unfamiliar industry, this can be confounding, almost like being in a country that is foreign to you.

The most recent discovery I was a part of was for a project in an industry very foreign to me.

Before discovery had started, we prepared by reading a few materials including project goals, user descriptions, and desired functionality. It was quickly apparent to me that there was quite a few terms that I was unfamiliar with. I immediately thought of "building a shared language."

To help us get acquainted with the industry, I scoured the documents pulling out each unfamiliar term. I then dropped those terms into a document with space to the right of each item. During discovery we printed out the document handing it over to the stakeholders of the project. We asked them to independently define each term and its association to the project at hand, an activity that took maybe 20-30 minutes.

The results were insightful. These definitions helped outline expectations for delivery. It shed light on alignment between stakeholders. It showed us that these terms could mean something different for each person, or that a discussion needs to happen to help bring people onto the same page. Not only was this revealing, it will also serve as reference material when we move deeper into the project. We can feel confident about decisions around functionality, because together we have agreed on the meaning.

Discovery is really about understanding and it always helps to be able to speak the same language.

Think your company can benefit from a design discovery or other UX support? Contact us.

Experience Economy, user interviews, and design discovery

2017-05-26 00:00:00

In my reading and podcast-listening lately, Iâve found myself more and more interested in business rules and principles. Part of the reason Iâm doing all this reading is, Iâm just curious about how things work. But I also noticed that the better I understand how a business operates, the more I can use design strategically to solve the right problems at the right time.

The principle of customer sacrifice

In The Experience Economy, B. Joseph Pine II and James H. Gilmore talk about the principle of Customer Sacrifice. This sacrifice happens when a customer settles for something they know is available, rather than what theyâd truly want, if only they could have it. The book explains that even a business attentive to its customers will often miss the customer sacrifice. We often measure how well a business is doing for its customers by conducting customer surveys. These questionnaires are great at measuring satisfaction levels: the difference between what a customer expected, and what they think theyâve received.

Are you limiting the upside of customer UX?

But customer satisfaction is only a good retroactive measurement: how did we do, compared to how well our customers thought we might do? Satisfaction pre-supposes that the best a business could possibly do is within the bounds of what the customer already expected. This approach is limiting because it caps potential improvements at what the customers already knew they wanted. And, perhaps more importantly, satisfaction does not measure what the customer might have preferred but assumed they couldnât have.

The Experience Economy uses soft drink preference to illustrate this second type of missed opportunity. On most airlines, if asked for a Pepsi, the attendant will offer a Coke instead. After a few flights, the customer would realize Pepsi is not an option and start asking for a Coke instead. If the airline were to measure customer satisfaction at this point, it would look like the customer received exactly what they wanted, and thereâs no room for improvement. The airline would miss an existing opportunity to improve customer experience by providing a preferred drink.

Understand customer sacrifice through user interviews during design discovery

Customer sacrifice is one of the reasons unbiased, open-ended user interviews are so important. We normally conduct several of these as part of a design discovery. When you apply design thinking, and ask good questions youâll get a broad set of insights from users. The interview style I always recommend, and practice myself, includes open-ended questions and touches on the experience around the product, not just the product itself. Doing this work takes time, but the quality and depth of insight is well worth the investment.

My favorite, most rewarding moments when leading a design project are when discovery wraps up, and I can confidently propose a way forward based on what weâve learned. It usually goes something like this: hereâs the problem you hired us to solve. But actually, your customers are experiencing a slightly different problem. And hereâs how you can be even more successful in the future by solving that.

As a designer, itâs a humbling experience to be able to jump into a business problem, rapidly learn its key aspects from the folks who are infinitely more experienced in their field than I am, then talk to their users and other stakeholdersâ¦ and come back with something new or surprising. How can we do this? Part of what helps us find these new things is a beginnerâs mentality. (I call it: weâre not afraid to ask the âstupidâ questions!) Another part is - applying the right process to a business problem at the right time will yield results. Design can still have a limited interpretation as âdecorative stuffâ, but more and more businesses are realizing designâs strategic role in tech.

Reading more business books, in a funny way, makes me more optimistic for the future of design. Iâm making connections and realizing that the business world has terms for the stuff Iâve sometimes been doing intuitively, because it feels right and gives results.

If your company could benefit from a strategic design engagement, contact us.

Optimizing Your Elixir and Phoenix projects with ETS

2017-05-19 00:00:00

Many Elixir programmers have probably heard references to "ets" or "ETS" in talks, or may have seen calls to the Erlang :ets module in code, but I would wager the majority haven't used this feature of Erlang in practice. Let's change that.

ETS, or Erlang Term Storage, is one of those innovative Erlang features that feels like it has been hiding in plain sight once you use it. Projects across the community like Phoenix.PubSub, Phoenix.Presence, and Elixir's own Registry take advantage of ETS, along with many internal Erlang and Elixir modules. Simply put, ETS is an in-memory store for Elixir and Erlang terms with fast access. Critically, it allows access to state outside of a process and message passing. Before we talk when to ETS (and when not to), let's begin with a basic primer by firing up iex:

First, we'll create an ETS table with :ets.new/2:

  
  iex> tab = :ets.new(:my_table, [:set])
8211

That was easy enough. We created a table of type :set, which will allows us to map unique keys to values as a standard key-value storage. Let's insert a couple items:

  
  iex> :ets.insert(tab, {:key1, "value1"})
true
iex> :ets.insert(tab, {:key2, "value1"})
true

Now with a couple items in place, let's do a lookup: elixir iex> :ets.lookup(tab, :key1) [key1: "value1"]

Notices how we aren't re-binding tab to a new value after inserting items. ETS tables are managed by the VM and their existence lives and dies by the process that created them. We can see this in action by killing the current iex shell process:

  
  iex> Process.exit(self(), :kill)
** (EXIT from #PID<0.88.0>) killed

Interactive Elixir (1.4.4) - press Ctrl+C to exit (type h() ENTER for help)
iex> :ets.insert(8211, {:key1, "value1"})
** (ArgumentError) argument error
    (stdlib) :ets.insert(12307, {:key1, "value1"})

Once iex crashes, we lose our previous bindings, but we can pass the ets table ID returned from our call to :ets.new/2. We can see that when we tried to access the table after its owner crashed, an ArgumentError was thrown. This automatic cleanup of tables and data when the owning process crashes is one of ETS's great features. We don't have to be concerned about memory leaks when processes terminate after creating tables and inserting data. Here, we also got our first glimpse of the esoteric :ets API and its often unhelpful errors, such as ArgumentError with no other guidelines on what the problem may be. As you use the :ets module more and more, you'll undoubtably become famliar with frustrating argument errors and the :ets documentation is likely to end up in your bookmarks.

This just barely scratched the surface of what features ETS provides. We'll only be using a fraction of its capabilities, but just remember where it really shines is fast reads and writes to key-value storage, with the ability to efficiently match on most erlang terms stored within the table (excluding maps). In our examples, we'll only be storing simple key-values with basic lookups, but you should consult the docs to explore the breadth of provided features.

Optimizing `GenServer` access with an ETS table

Optimizing code is a rewarding experince, but doubly so when you don't have to change your public interface. Let's see a common way ETS is used to optimize data access for state wrapped in a GenServer.

Imagine we're writing a rate limiter GenServer which is a process in our app that counts user requests and allows us to deny access once a user exceeds their allotted requests per minute. We know right away that we'll need to store the request count state for our users somewhere, as well as a process that periodically sweeps the state once per minute. A naive first-pass with a plain-old GenServer might look something like this:

  
  defmodule RateLimiter do
  use GenServer
  require Logger

  @max_per_minute 5
  @sweep_after :timer.seconds(60)

  ## Client

  def start_link do
    GenServer.start_link(__MODULE__, [], name: __MODULE__)
  end

  def log(uid) do
    GenServer.call(__MODULE__, {:log, uid})
  end

  ## Server
  def init(_) do
    schedule_sweep()
    {:ok, %{requests: %{}}}
  end

  def handle_info(:sweep, state) do
    Logger.debug("Sweeping requests")
    schedule_sweep()
    {:noreply, %{state | requests: %{}}}
  end

  def handle_call({:log, uid}, _from, state) do
    case state.requests[uid] do
      count when is_nil(count) or count < @max_per_minute ->
        {:reply, :ok, put_in(state, [:requests, uid], (count || 0) + 1)}
      count when count >= @max_per_minute ->
        {:reply, {:error, :rate_limited}, state}
    end
  end

  defp schedule_sweep do
    Process.send_after(self(), :sweep, @sweep_after)
  end
end

First, we defined start_link/0 which starts a GenServer, using our RateLimiter module as the callback module. We also named the server as our module so we can reference it later in our call to log/1. Next, we defined a log/1 function which makes a synchronous call to the rate limiter server, asking it to log our user's request. We expect to receive either :ok back, to indicate our request can proceed, or {:error, :rate_limited}, to indicate the user has exceeded their allotted requests, and the request should not proceed.

Next, in init/1, we called a schedule_sweep/0 function which simply has the server send itself a message one per minute to clear out all request data. Then we defined a handle_info/2 clause to pickup the :sweep event and clear out the request state. To complete our implementation, we defined a handle_call/3 clause to track request state for the user and return an :ok, or {:error, :rate_limited} response for our caller in log/2.

Let's try it out in iex:

  
  iex> RateLimiter.start_link()
{:ok, #PID<0.126.0>}
iex> RateLimiter.log("user1")
:ok
iex> RateLimiter.log("user1")
:ok
iex> RateLimiter.log("user1")
:ok
iex> RateLimiter.log("user1")
:ok
iex> RateLimiter.log("user1")
:ok
iex> RateLimiter.log("user1")
{:error, :rate_limited}

13:55:44.803 [debug] Sweeping requests
iex(9)> RateLimiter.log("user1")
:ok

It works! Once our "user1" exceeded 5 requests/minute, the server returned the expected error response. Then after we waited we observed the debug output of the state sweep, and we confirmed we were no longer rate limited. Looks great right? Unfortunately, there's some serious performance issues in our implementation. Let's see why.

Since this feature is for rate limiting, all user requests must pass through this server. Since messages are processed in serial, this effectively limits our application to single-threaded performance, and creates a bottleneck on this single process.

ETS to the rescue

Fortunately for us, Erlangers solved these kinds of problems for us. We can refactor our rate limiter server to use a publicly accessible ETS table so clients can log their requests directly in ets, and our owning process can be responsible only for sweeping and cleaning up the table. This allows concurrent reads and writes against ETS without having to serialize calls through the single server. Let's make it happen:

  
  defmodule RateLimiter do
  use GenServer
  require Logger

  @max_per_minute 5
  @sweep_after :timer.seconds(60)
  @tab :rate_limiter_requests

  ## Client

  def start_link do
    GenServer.start_link(__MODULE__, [], name: __MODULE__)
  end

  def log(uid) do
    case :ets.update_counter(@tab, uid, {2, 1}, {uid, 0}) do
      count when count > @max_per_minute -> {:error, :rate_limited}
      _count -> :ok
    end
  end

  ## Server
  def init(_) do
    :ets.new(@tab, [:set, :named_table, :public, read_concurrency: true,
                                                 write_concurrency: true])
    schedule_sweep()
    {:ok, %{}}
  end

  def handle_info(:sweep, state) do
    Logger.debug("Sweeping requests")
    :ets.delete_all_objects(@tab)
    schedule_sweep()
    {:noreply, state}
  end

  defp schedule_sweep do
    Process.send_after(self(), :sweep, @sweep_after)
  end
end

First, we modified our init/1 function to create an ETS table with the :named_table and :public options so that callers outside of our process can access it. We also used the read_concurrency and write_concurrency options to optimize access. Next, we changed our log/1 function to write the request count to :ets directly, rather than going through the GenServer. This allows requests to concurrently track their own rate-limit usage. Here we used the update_counter/4 feature of ETS, which allows us to efficiently, and atomically, update a counter. After checking rate limit usage, we return the same value to the caller as before. Lastly, in our :sweep callback, we simply use :ets.delete_all_objects/1 to wipe the table for the next rate limit interval.

Let's try it out:

  
  iex> RateLimiter.start_link
{:ok, #PID<0.124.0>}
iex> RateLimiter.log("user1")
:ok
iex> RateLimiter.log("user1")
:ok
iex> RateLimiter.log("user1")
:ok
iex> RateLimiter.log("user1")
:ok
iex> RateLimiter.log("user1")
:ok
iex> RateLimiter.log("user1")
{:error, :rate_limited}
iex> :ets.tab2list(:rate_limiter_requests)
[{"user1", 7}]
iex> RateLimiter.log("user2")
:ok
iex> :ets.tab2list(:rate_limiter_requests)
[{"user2", 1}, {"user1", 7}]

14:27:19.082 [debug] Sweeping requests

iex> :ets.tab2list(:rate_limiter_requests)
[]
iex> RateLimiter.log("user1")
:ok

It works just as before. We also used :ets.tab2list/1 to spy on the data in the table. We can see our users requests are tracked properly, and the table is swept as expected.

That's all there to it. Our public interface remained unchanged and we vastly improve the performance of our mission-critical feature. Not bad!

Here Be Dragons

This just scratched the surface on what's possible with ETS. But before you get too carried away and extract out all your serialized state access from GenServer's and Agent's to ETS, you need to think carefully about which actions in your application are atomic, and which require serialized access. You can easily introduce race conditions by allowing concurrent reads and writes in the pursuit of performance. One of the beautiful things about Elixir's process model is the serial processing of messages. It lets us avoid race conditions exactly because we can serialize access to state that requires atomic operations. In the case of our rate limiter, each user wrote to ets with the atomic update_counter operation so concurrent writes are not a problem. Use the following rules to determine if you can move from serial access to ETS:

The operations must be atomic. If clients are reading data from ets in one operation, then writing to ETS based on the result, you have a race condition and the fix is serial access in a server
If the operations are not atomic, ensure different processes write to distinct keys. For example, Elixir's registry uses the Pid as key and allows only the current process to change its own entry. This guarantees there are no races as each process work on a different row of the ETS table
If none of the above apply, consider keeping the operation serial. Concurrent reads with serial writes is a common ETS pattern

If you're curious about using ETS for a dependency-free in-memory cache, check out SaÅ¡a JuriÄ's excellent ConCache library.

Five Business Problems Progressive Web Apps Solve

2017-05-03 00:00:00

Todayâs businesses are extremely reliant on the web. Finding and acquiring new customers while engaging and retaining current ones is a costly balancing act requiring more and more bandwidth and budget.

How can businesses communicate with all customers, across all devices, and in the most cost effective way? Progressive Web Apps (PWAs) are not only forward thinking technology but also an answer to issues like this that businesses face on a daily basis.

The need to develop and maintain for multiple platforms. A Progressive Web App works in the browser so there is no need for specialized development. Specifically, Chrome, Opera, and Firefox support PWAs with Safariâwhile not (yet?) supporting themâstill sees an increase in engagement. When implementing a PWA, many companies like Alibaba see a 76% increase in conversion across all browsers, not only those in which they are completely supported.

Mobile applications are not discoverable. A big barrier to mobile application adoption is that they do not show up in search results. This means that new customers looking for solutions you provide are unable to find you, unless they are already aware of you. By implementing a Progressive Web App the opportunities for new user acquisition are amplified by their ability to find you on their own terms when they need you. Not to mention the fact that Google rewards mobile-friendly content in itâs search algorithm.

Re-engagement and timely communication is costly (and âpeople donât read emailâ). PWAs allow websites to be added to home screens on mobile devices and receive push notifications. After users opt in they can be provided timely information on sales, abandoned carts, or other information valuable to them at that specific time or location. Push notifications offer users the right information at the right time without the need to check, open, and interact with email.

Still, one experience doesnât fit both desktop and mobile visitor goals. Should you want to provide a varied experience for your mobile audience this is also supported by Progressive Web Apps. Where your desktop users may be completing tasks focused on research and narrowing solutions, your mobile users may be looking to make decisions and purchases. Providing upfront information on sales, new products, or upcoming events can be spotlighted making it easier for them to move from discovery to purchase.

Mobile sites can be slow and not user friendly. It is true that mobile apps provide a user and device driven experience which many websites are not optimized for. Progressive web apps solve for this by providing an app like feeling to the user without the need to develop for multiple devices. PWAs create a faster, lighter, and interactive way for consumers to interact with a business in a way that makes sense for them. Given that 53% of users will abandon a site if it takes longer than 3 seconds to load, speed is a very important consideration.

Whether combatting a poor mobile experience or trying to reduce long term costs, all businesses can benefit from upgrading to a Progressive Web App. The reduction in overhead and simplification of communication with your key customers are just a couple of ways companies can see the immediate impact of PWA implementation.

DockYard Senior Engineer To Present at GOTO Chicago

2017-04-28 00:00:00

DockYard.com Senior Engineer Marten Schilstra will present at GOTO Chicago on May 2, 2017. He joins a number of other industry experts and leaders presenting at the two day international software conference.

Tuesday, May 2, Schilstra will present in the Frontend track âMaking the web frameworks titans feel tiny.â This talk will focus on Service Worker technology and solutions that web frameworks are implementing to alleviate their deficiencies.

GOTO is the enterprise software development conference designed for team leads, architects, and project management organized by developers, for developers.

DockYard is a software consultancy driven by creating exceptional user experiences. By approaching software with the user experience at the forefront, DockYard delivers web applications that beat out native applications in any web browser using HTML5, CSS, and JavaScript.

DockYard Launches Redesigned Website

2017-04-18 00:00:00

Today, DockYard released a new version of their flagship website DockYard.com. This latest iteration provides more indepth information on DockYardâs software design and engineering services, body of work, and pursuit of best practice web app development.

âOur new website design represents a collaborative effort between our design and engineering teams to deliver a clean, fast, and beautiful vision for how we want the world to view DockYard,â says Brian Cardarella, DockYard CEO. âAs with all of our internal design and engineering efforts we pushed ourselves to not compromise on the implementation.â

In the coming weeks users will see even more advances on DockYard.com, including better representations on the company's culture, hiring, and team. Their blogââReefpointsââwill also receive a refresh with a design that better organizes content and provides a more immersive reading experience. New case studies and exclusive content on Progressive Web Applications (PWAs) will also be updated regularly, providing a more thorough understanding of the solutions that DockYard creates.

âWe have many lessons learned that we hope to share with the community as a whole,â continues Cardarella. âOne of our primary missions at DockYard is to help improve the eco-system that we work in. Improvements to many of our Ember.js and Elixir libraries came out of this effort, and weâre excited to share these in the coming weeks.â

For more information on DockYard and itâs services please visit DockYard.com/services.

What type of business problem are we solving?

2017-04-17 00:00:00

Tl;dr: skills or expertise alone donât guarantee a great business outcome. You also need to know where to apply them.

I was listening to an episode of Marketing for Owners podcast recently, and one idea stopped me in my tracks.

Kate Cook, a nutrition specialist, leads a consulting company focused on the benefits of nutrition. As part of her practice, she audits work environments from the nutritional health perspective, setting up educational programs and/or planning meals. Improving something like the food employees eat may seem like a nice-to-have and might often be treated casually. However, there is a different approach.

Kate is often asked to go to a company and has done so under health and safety rather than employee wellness. Thatâs because youâre far more likely to have a manual handling accident if your blood sugar levels are not balanced. And that happens as a result of coming to work without breakfast and drinking energy drinks.

source

The idea that struck me was this: the fact that Kateâs work is classified under Health & Safety can allow her to make a much bigger impact. This is because the business can clearly see value in preventing accidents and improving safety. Accidents cause suffering, can stop work, increase insurance premiums, etc. etc..

If the same specialistâs work is classified under âhuman resourcesâ instead, the impact can be limited by the scope and budget of that department. Human Resources deals with important issues, of course â but nutritional advice filed under HR could be interpreted as optional. The problem to be solved here is comfort, pleasure, and perhaps health. But without a clear connection to known important business goals (like health and safety) there will not be enough room in the budget to create an impactful nutritional program.

Itâs not just what you doâitâs where you do it.

My takeaway from listening to the podcast is this: the impact of my work is never defined by my skill or expertise alone. The impact of my work will be limited or multiplied by how itâs classified - what type of business problem I am solving, in the clientâs eyes?

Just like categorizing a nutrition program as âOptionalâ vs. âSafetyâ, you could think of design as something optional, or as something essential. Youâll get different results depending on your approach.

You can expect better results if you have the opportunity to define not just the solution, but also the problem and where that problem belongs in the bigger picture of a business. A thoughtful, structured approach of a discovery frames both the problem and a proposed solution against a set of assumptions and constraints.

When we bring in design after the problem has been fully defined, or even once itâs been partially solved, we reduce the potential impact. With a limited impact (for example, if we treat design as aesthetic-only) we can only justify a respectively smaller effort.

What this means for designers

As a practitioner, I know this understanding comes with experience. It took several years to see how much the impact of design work depends on the âcategoryâ itâs been assigned by a client. You can be the best designer, but if thereâs a limited field to work in, you can only do so much. This can feel frustrating at times, but a good understanding of where you stand can help propose a right-size project instead of wasting time on an unnecessarily ambitious proposal, or under-estimating the impact your work can truly have.

What this means for business owners

For folks who are considering hiring design to solve a problem, itâs important to consider two things. One â the earlier you bring in design thinking - the larger potential impact it can have. Bring designers in at the planning stages to help define big wins for a project. And two â when you do collaborate with designers, at any stage, be honest about what âcategoryâ the project falls into within your business. Youâll support the design teamâs ability to think at the right level, right away, and get better answers to your questions around scope, time, and scale.

Improving Ember app page load times using the App Shell model

2017-02-17 00:00:00

In the past week I have been experimenting with the App Shell Model to make the DockYard.com website load faster. In this blog post I'll walk through which changes I made and how I've made them. Complete with some benchmarks!

Why improve page load speed?

According to Google, if loading a page takes too long, they'll just abandon it. This hurts your conversion rates. Key metrics that contribute to better conversion rates are when the browser is able to make its first paint and when the page is fully loaded.

Tools of the trade

In this section I'll introduce the tools I've used to measure the loading performance. Please take a minute to follow the links to the mentioned tools and read how they work and what they are for.

To be able to measure the performance of DockYard.com I have used Lighthouse and the Application, Network and Timeline DevTools from the Google Chrome team to see changes made a positive impact on loading speed.

Lighthouse is the successor of Google's PageSpeed tool. Lighthouse uses your Chrome DevTool to do a host of automated audits. I.E. it checks if a Service Worker is registered and that a Web App Manifest can be found. The audits I'm most interested in are the page load performance audits. These measure the first meaningful paint, the speed index and time to interactive performance.

What I'm measuring

I'm measuring the page load in two situations. The first situation is as if it's the very first time I'm visiting the website, this means no assets have been cached yet. The second situation is when I'm loading the website on a repeat visit, which means the browser had a chance to cache the assets. I'll also measure the same two scenarios using network and CPU throttling to simulate being out and about on a mobile device. Mobile simulation is done on the 'Regular 3G' network throttling setting and the 'Low end device' cpu throttling setting.

There are three key performance metrics I'm looking for in each test, first I'll look for when the first meaningful paint happens and second I'll look for the moment when the Ember.JS app has booted client side and when the Ember.JS app has done its initial render on the client side. The first meaningful paint and the initial render metric are the two metrics that according to Google contribute the most to abandonment rate.

Getting the baseline

Benchmarks have been made on a standard mid 2015 15" MacBook Pro, all tests have been done with a wired 500 megabit up/down internet connection. I have about 90ms latency towards the webserver and about 7ms to the assets server.

To start out, here are the baseline performance metrics of the current DockYard.com website. It is a Ember.js application that is served with FastBoot.

Baseline Lighthouse score

Note: Lighthouse measures without CPU slowdown and a custom network throttling setting

This initial lighthouse score shows that the first meaningful paint comes just before the time to interactive. This does mean that when the page shows up, it's almost immediately interactive, but you'll see nothing before that.

Baseline Desktop: Page load with empty cache

First paint: 600ms
App boot: 1,175ms (the dip in the CPU graph)
Initial render: 1,400ms

Baseline Desktop: Page load with warmed cache

First paint: 325ms
App boot: 750ms
Initial render: 950ms

Baseline Mobile: Page load with empty cache

First paint: 1,200ms
App boot: 8,900ms
Initial render: 10,200ms

Baseline Mobile: Page load with warmed cache.

First paint: 850ms
App boot: 2,850ms
Initial render: 4,200ms

The changes I've made

First off I've added (offline) caching by a Service Worker, using Ember Service Worker with various plugins. This did not, as expected, improve the cold boot scenarios, but did improve the scenarios with warmed cache slightly. Especially the first paint was much earlier. Results of the warmed cache scenarios are:

Service Worker only Desktop: Page load with warmed cache

First paint: 125ms
App boot: 725ms
Initial render: 900ms

Service Worker only Mobile: Page load with warmed cache

First paint: 300ms
App boot: 2,700ms
Initial render: 4,000ms

Next I wrote a small Ember CLI addon that concats both scripts (vendor.js and dockyard.js) that Ember CLI produces together. Then I proceeded to load that single JavaScript file using a `element in the head that was markedasync`. This had no significant improvement on the desktop side, but loading on mobile did improve. There is a small downside to this technique though, the two files aren't cached seperately by the browser anymore, which can increase the amount of data needed to be transferred when deploying new builds often.

Async'ed script Mobile: Page load with empty cache

First paint: 750ms
App boot: 7,950ms
Initial render: 9,000ms

Async'ed script Mobile: Page load with warmed cache

First paint: 200ms
App boot: 2,350ms
Initial render: 3,550ms

Lastly I extracted all the critical CSS for an initial render and inlined it into the `` section. Then proceeded to asynchronously load the remaining CSS using loaddCSS. This made the first paint come slightly earlier in all scenarios, but hurts the initial render by about 150ms on mobile.

Async'ed CSS Desktop: Page load with empty cache

First paint: 550ms
App boot: 1.100ms
Initial render: 1.325ms

Async'ed CSS Desktop: Page load with warmed cache

First paint: 125ms
App boot: 675ms
Initial render: 900ms

Async'ed CSS Mobile: Page load with empty cache

First paint: 500ms
App boot: 8,100ms
Initial render: 9,150ms

Async'ed CSS Mobile: Page load with warmed cache

First paint: 125ms
App boot: 2,500ms
Initial render: 3,700ms

All the stats summed up in a table

Final Lighthouse score

Note: To get the perfect 100/100 score we also added a Web App Manifest.

That's an impressive 10x speed up in first paint and almost a second and a half in time to interactive. This gives your user much more confidence in that your page is loading.

Browsers without Service Worker

You might ask: "How does this affect page loading in browsers that not yet support Service Workers?". I've tested the before and after with Safari's timeline tool. The results show no significant speed up in full page load, but actually a slight slowdown. The results do show a significant speed up in first paint time with either empty or warm cache.

After the benchmarks I've noticed that loading the service worker registration script plays a big part in the slowdown. I'd need to fiddle some more with loading that script to see if I can get rid of the slowdown.

Below are the timeline graphs for loading in Safari. Notice the big shift of the blue DOMContentLoaded line. That counts as the first paint. The red Load line is the app boot. The last green bar is the initial render.

Baseline: Page load with empty cache

First paint: 510ms
App boot: 600ms
Initial render: 740ms

After improvements: Page load with empty cache

First paint: 250ms
App boot: 650ms
Initial render: 820ms

Baseline: Page load with warm cache

First paint: 510ms
App boot: 575ms
Initial render: 730ms

After improvements: Page load with warm cache

First paint: 250ms
App boot: 620ms
Initial render: 780ms

Safari tests summarized

Conclusion

A Service Worker and a bit of techniques from the App Shell model can boost your page load times. Your app will show up on the screen earlier and be interactive quicker, which in turn can improve the conversion rates of your website.

Please try out these techniques and see for yourself if it improves page load times of your app. In any case let me know how it works out for you.

Closing: don't forget to compress your images, svg's and fonts! Those too can impact page load performance by seconds on mobile.

How GenServer deals with errors in a concurrent environment

2016-11-18 00:00:00

Pattern for stateful server process

After newcomers wrap their minds around immutability, they quickly question how to hold and change state in a language that does not allow mutation. Elixir uses Erlang's OTP libraries to formalize state access and mutation, but to understand how this can happen in an immutable world we can implement our own stateful server using only a process with tail recursion:

In the following sample code, we define a start function which can be used to start the server process with an initial state.
Because of receive, the process will be blocked to wait for messages. Whenever clients send a message to the server process using call, it will pattern match on {:message, caller, msg} and invoke the corresponding function to get the new state.
After getting the new state, it replies to the client and runs the loop function from the beginning with the new state.

  
  def start(inital_state) do
  spawn(fn ->
    initial_state = ...
    loop(initial_state)
  end)
end

defp loop(state) do
  receive do
    {:message, caller, msg} ->
      new_state = handle(msg, state)
      send(caller, {:reply, new_msg})
      loop(new_state)
    :stop -> terminate()
  end
end

def call(name_or_pid, message)
  send(name_or_pid, {:message, self(), message})
  receive do
    {:reply, reply} -> reply
  end
end

It's simple but error-prone because we don't handle any error condition. This becomes more complicated when dealing with a concurrent environment. The good news is that GenServer can help deal with race conditions, deadlocks, and many edge cases.

GenServer helps with error handling

Ensure source of message using `reference`

In the stateful server process above, the client sends a message to the server with a format of {:message, pid_or_name, message} and waits for a message with a format of {:reply, reply}.

As shown in the picture, the client might receive a similarly formatted reply from different servers, how can we make sure that the reply is from the correct server?

The solution is to use a unique reference to tag the message. when the client sends a request to the server, it creates a unique reference first and sends it with its pid together: {:message, {ref, pid}, message}, and the server can reply with {:reply, ref, reply}. This way, the client can pattern match based on the unique reference.

Now, the call function becomes:

  
  def call(name_or_pid, message)
  ref = make_ref()
  send(name_or_pid, {:message, {ref, self()}, message})
  receive do
    {:reply, ^ref, reply} -> reply
  end
end

Erlang/OTP solves this problem with a unique reference as shown here.

What if the server crashes

Server crashes before message is sent by client via server Pid

If the server crashes before the message is sent from the client, the message will be lost and the client will be blocked in the receive block.

The solution is to monitor the server process using Process.monitor(server_pid). The reason why we choose monitor instead of links is that monitor is unidirectional, so termination of the client will not affect the server.

In case of a server crash, the client will receive a Down message, so we can take action in the receive block. Noting that monitor returns a reference, we can now drop the make_ref().
Server crashes before message is sent by client via registered name

In this case, the client process will terminate. To avoid crashing and return better error stack, we need to rescue the runtime error by using try...rescue.
Server crashes right after replying to client

If the server crashes right after it sends its reply to the client, a Down message will be sent to the client's mailbox. The client, however, will never have a chance to pattern match this message because it demonitors the server.

This might cause memory leak and slow down the server. Ultimately, a single slow process may cause an entire system to crash by consuming all the available memory.

Process.demonitor(ref, [:flush]) is the solution for this issue. Every time we demonitor a server, passing in a flush option can make sure that any Down message that belongs to that monitor will be cleared.

After handling the server crash, the call function looks like:

  
  def call(name_or_pid, message, timeout \\ 5000)
  ref = Process.monitor(name_or_pid)
  try do
    send(name_or_pid, {:message, {ref, self()}, message})
  rescue
    _ -> :error
  end
  receive do
    {:reply, ref, reply} ->
      Process.demonitor(ref, [:flush])
      reply
    {:DOWN, ref, ...} ->
      {:error, reason}
      exit(reason)
    {:DOWN, ref, ..., :noconnection} ->
      node = get_node(name_or_pid)
      exit({:node_down, node})
  after timeout -> exit(:timeout)
  end
end

Deadlock

If two processes synchronously call each other using the code above, both of them enter the receive block which will cause a Deadlock. This can be resolved with a timeout in the receive block. When the time is out, the system can terminate the process and release the resources held by the process.

An example is shown here.

Conclusion

There are a lot more concurrent errors that we haven't discussed yet. Fortunately, GenServer handles all the concurrent conditions and edge cases, we should almost always use it instead of reinventing the wheel.

Making a DDAU checkbox list in Ember.js

2016-11-18 00:00:00

Data Down, Actions Up (A refresher)

An important part of creating stable, maintainable Ember applications is following the Data Down, Actions Up (DDAU) paradigm. This means that your data comes in at the route level and is displayed further down in your UI (by templates and components), while when you want to manipulate that data, you trigger an action which gets sent back up to the route that manipulate the data at its source. This makes your application simple and easy to reason about because there is a single source of truth for your data and the route that manipulates the data.

Okay... so?

So, it's hockey season! Let's finally build that favorite player voting app you've always wanted. We'll display a list of players via a list of checkboxes and have the user select which ones they like. Our input will be a list of strings, and we want the output to be another list of strings. Following DDAU, ideally we want our checkboxes to not actually manipulate a selected value directly, but send an action back up which manipulates our model and marks the player as selected. (We'll leverage One Way Controls for that).

Setup

Model: Our model hook is dead simple:

  
  model() {
  return [];
}

Also we'll need some options to select from. Let's put that in the controller:

  
  import Ember from 'ember';

const { Controller, set } = Ember;

export default Controller.extend({
  init() {
    this._super(...arguments);
    set(this, 'playerOptions', [
      'Phil Kessel',
      'Sidney Crosby',
      'Tyler Seguin',
      'Steven Stamkos',
      'Connor McDavid',
      'Patrick Kane'
    ]);
  }
});

And a simple template:

  
  <div>
  <h2>Pick your favorites</h2>
  <ul>
    {{#each playerOptions as |player|}}
      <li>
        {{!TODO Checkbox}}
        {{player}}
      </li>
    {{/each}}
  </ul>
</div>

<div>
  <h2>You picked</h2>
  <ul>
    {{#each model as |player|}}
      <li>{{player}}</li>
    {{/each}}
  </ul>
</div>

Checkboxes

Now we have some options, and a place to select them into. Let's write the checkbox logic! The API for a checkbox looks something like:

  
  {{one-way-checkbox selected update=(action "someAction")}}

Where selected is a boolean.

For our use case, the checkbox should be selected when the player is in the model. Note our input and output are both lists of strings, no selected attribute. So how do we mark it as selected if we don't store it?

Quick detour into helpers!

We want to have selected in our template be true when an item is in an array. We can write a helper that does this for us which we can use in the template to return our selected boolean value:

  
  import Ember from 'ember';

const { Helper: { helper } } = Ember;

export function includes([haystack, needle]) {
  return haystack.includes(needle);
}

export default helper(includes);

This enables us to write

  
  {{one-way-checkbox (includes model player) ...}}

It's also useful in that if your model returns some options, the template is reactive to that and automatically marks them as selected because the helper is computing it from the higher up data flowing into it.

Cool!

Actions

So far so good, but if we click on the checkbox... it doesn't do anything. We'll need an update action, which we want in our route (using ember-route-action-helper).

  
    actions: {
    togglePlayer(player, checked) {
      let model = get(this, 'currentModel');
      if (checked) {
        model.pushObject(player);
      } else {
        model.removeObject(player);
      }
    }
  }

Finally

Now we can insert a checkbox using our includes helper and action.

  
    {{one-way-checkbox (includes model player)
    update=(route-action "togglePlayer" player)}}

And we're done! Here's a demo.

I hope this demonstrates a practical example of DDAU in Ember to build a pretty common UI element.

Live Search with Ember & JSON API

2016-10-20 00:00:00

Live search is a feature commonly found in applications. There are various solutions to implementing search functionality on a website, but "live search" promotes a better user experience over the traditional way of searching (i.e. type in keyword and click to view results); it's satisfying to a user since immediate feedback is received based on what they have typed, without having to click some form of a "submit" or "search" button. It's refreshing to see results narrow as you type more words, or broaden as you backspace to delete already-typed characters from the search box. The less work your user has to do, the better.

Live search is not new concept whatsoever, but if you're new to the JSON API specification and would like to follow its conventions, this may be helpful.

The specification states the following on the subject of filtering:

The filter query parameter is reserved for filtering data.
Servers and clients SHOULD use this key for filtering operations.

Given that info, we'll go over how to set up the client-side (Ember), and the server-side (in both Phoenix and Rails) to get live search working. In the following examples, we'll work with a Food model having a category attribute.

On the Ember side

To get started, make sure your application is using the DS.JSONAPIADAPTER; it's the default adapter in a new Ember application. This informs your application of the type of data that it should be expecting from the server. In our case, the payload will be expected to have a specific format and will be expected to contain certain keys. Check out the spec if you'd like more details on this.

Having that, we only need to add a couple of things: query parameters and the call to the server itself.

  
  // controllers/foods.js
import Ember from 'ember';
const { Controller } = Ember;

export default Controller.extend({
  queryParams: 'category',
  category: ''
});

  
  // routes/foods.js
import Ember from 'ember';
const { Route } = Ember;

export default Route.extend({
  queryParams: {
    category: { refreshModel: true }
  },

  model(params) {
    return this.store.query('food', { filter: { category: params.category } });
  }
});

It's that simple. Notice that we're using the store's query method and providing it with a filter. This filter must be included in the call. This will result in a GET request containing a URL encoded string with the filter query parameter:

/foods?filter%5Bcategory%5D=pastry

Now let's see how to set this up on the backend for a seamless integration.

On the Phoenix side

Hex package needed: ja_resource
Recommended to use with: ja_serializer

After following the lib's quick installation instructions, and aside from needing to add our route and schema, that's all we need to do in Phoenix before heading over to our controller for some filtering logic.

  
  defmodule MyApp.FoodController do
  import Ecto.Query

  use JaResource
  use MyApp.Web, :controller

  plug JaResource

  def filter(_conn, query, "category", category) do
    from f in query,
      where: ilike(f.category, ^("%#{category}%"))
  end
end

On L7, plug JaResource is reponsible for providing all the controller actions by default. There is no need for you to implement these actions unless you'd like to add custom logic. That's a pretty nice time saver! Plus we can customize our controller's behavior via the many callbacks that the library provides. JaSerializer conveniently provides the callback filter/4 where we can handle our custom filtering given our filter parameters. In the example, we only want to filter by category, so we add "category" as the third argument so that we get a match. You'll have to define one of these filter callbacks for as many filter parameters as you want to pass. "Anything not explicitly matched by your callbacks will get ignored."

On the Rails side

Gem needed: jsonapi-resources

After having installed the gem, like in the Phoenix section above, you'll need to declare your routes and models. To gain the simplest form of the filter functionality, you just need to add the following (L5) to the corresponding resource file (this will find an exact match):

  
  class FoodResource < JSONAPI::Resource
  attributes :category

  filter :category
end

The filter will be based on the term passed in from the GET request coming from the Ember side; it will make sure that we are only returned Food records whose category value matches exactly that of the request parameter (i.e. "pastry").

Below, I show another example that leverages the :apply option whose arguments are records (an ActiveRecord::Relation), the value to filter by, and an options hash. However, you have much flexibility on how you decide to implement your filter. The README filter section has a more comprehensive list of the possibilities.

  
  class FoodResource < JSONAPI::Resource
  attributes :category

  filter :category, apply: -> (records, value, _options) {
   records.where('category LIKE ?', "%#{value[0]}%")
  }
end

Conclusion

That wraps it up! The Ember frontend and the Phoenix/Rails backends now work together to provide a live search functionality to a web application. Since we're following the JSON API spec, there is little to no friction on either side in order to get this working as expected. Happy filtering!

When you could turn a bug into a feature

2016-10-19 00:00:00

My background often plays into what I pay attention to when assessing design projects. I grew up outside of the US - in Soviet Russia, where the proverbial [fill-in-the-blank] eats you. Iâve now spent about half my life in the US. This experience gives me a good amount of insight into both worlds, and just enough distance to question things.

âBugâ in behavior

One of my favorite things to explore is the meaning behind behavior oddities - small quirks we might often make fun of, or find âincorrectâ when we observe them in others. I see many of these in tech and web products, but first letâs explore an example from physical life, very analog indeed.

When commuting on the metro in Moscow, I would often see folks reading a book wrapped protectively in newspaper. This trend would continue even after books have become relatively easy to find and purchase. The folks who continued the seemingly antiquated habit of wrapping books in newspaper tended to be older, and youâd be forgiven for chuckling at their behavior. âTheyâre not with the times! Why would they inconvenience themselves by dealing with that unwieldy newspaper?â

Bug or feature?

Look deeper. The newspaper wrapper doesnât just protect a bookâs surface. It gives the user a sense of safety and individuality.

Books were a controversial item in Soviet Russia. A large portion of what is now considered classic Russian literature was censored. Censorship extended to encouraging citizens to snitch on others if they observe suspicious behavior. Reading a book in public was an invitation for others to check out what it is, and express an opinion. A camouflage behavior emerged: when reading anything more controversial than a gardening manual, or a state-issued newspaper, people would wrap the cover for privacy.

How would you feel, knowing that your phone screen is clearly visible to everyone else on the train? Probably not that comfortable. To someone whoâs grown up 30 or so years ago in Russia, an exposed book cover would feel the same. Itâs a protective wrapper that gives us a bit of room to disagree with the system - and to avoid judgement.

In my practice, Iâve seen plenty of examples of âbugsâ that reveal desired behaviors. For example, when redesigning a complex dashboard interface for specialist users, we noticed that the screen seemed overwhelmed with tabular data, almost to the point of being unreadable. It seemed like a quick visual design fix to reduce the clutter and show less information to help people focus. But that âbugâ revealed a level of comfort the users had with seeing all of the information at once. They actually preferred the high density of information in some parts of the experience, because it matched an existing workflow in Excel, and reduced the cognitive load of switching back and forth.

Tl;dr.

Quaint behaviors that donât make sense are a signal. When we observe them, we should know thereâs more to discover. Something that looks like a bug to a design practitioner, can lead to a valuable feature in the eyes of a specialized user.

We should train ourselves to see these little âbugsâ in othersâ habits as opportunities to discover a deeper motivation, then build uniquely useful products as a result. And learn a fun fact for a blog post!

The Role of Discovery Phases and Design Sprints

2016-10-06 00:00:00

In terms of design processes, there are two that have proven to be integral parts to building a project: the Discovery Phase and the Design Sprint. Both provide vital information and guidance in the pursuit of bringing an idea to fruition. However there are occasions when it can be difficult to decide which to employ. Do you need one or the other? Do you need both?

First, we need to remind ourselves of the definition and purpose of each process and better educate clients on the two.

What are they?

In essence a Discovery Phase is an interval of time in which a team focuses on exploring the ins and outs of an existing product and identifying its impact on a clientâs bottom line. We use Discovery Phases to discover untapped value. This is done by executing an array of exercises ranging from stakeholder interviews to user interviews, from personas to journey maps. At its end, a client is provided opportunistic suggestions on how to improve on an existing product in ways that add value to their company and/or their customers.

In regards to a Discovery Phase, itâs important to recognize that while this processâ deliverable might take many forms, its purpose is primarily to audit and recommend, not necessarily to build and implement. Instead, part of the deliverable might be specific options for designing, building and implementing the recommendations.

While a Discovery Phase is focused on review of existing products, a Design Sprint is intended to be utilized when there is a need for something new â new products, features, services, etc. It is a methodology of agile product design that revolves most heavily around end users. We design, prototype and test ideas with users to validate or invalidate new products, features and services whose value is solving business questions. At its end, a client is witness to a new idea come to life and put in front of their users in the hopes of rapid validation or invalidation. This product, feature or service is intended to show value quickly or otherwise fail quickly, saving time and resources that otherwise might have been spent on a more robust build.

In regards to a Design Sprint, itâs important to recognize that its purpose is to allow for rapid validation or failure of a product (or feature, service, etc.) which requires user involvement and feedback.

While there are some similarities in how the two processes are carried out, their intent is quite different. This difference becomes especially clear when we look at the staples of a design project lifecycle: the time it takes, whatâs being produced and the people involved.

With a better understanding of the two, we can better dictate with our clients whether to conduct a Discovery Phase or a Design Sprint (and when not to).

Differentiating the Two

Length (time)

Discovery Phases and Design Sprints are often drastically different in terms of the amount of time needed to complete each. While a Design Sprint is modeled within one weekâs time, a Discovery Phase can take as little as 1 week or up to 8 weeks to complete depending on the project size, complexity, familiarity and goals. Sprints can be repeated, but they follow the same routine and still focus on validating or invalidating a narrowed idea or question.

Structure (time)

A Discovery Phase might call for very mild quantitative research or it might require a plethora of user research methods to be carried out. Because of the variability from project to project, the organization and scheduling of a Discovery Phase often requires a much more custom approach than the Design Sprint. A Design Sprint, due to the nature of its deliverable, generally follows a similar structure each and every time. A Discovery Phase has us discover, research, assess, report and recommend ideas via an array of design research methods. A Design Sprint has us map, sketch, storyboard, prototype and user test in the same or similar structured approach each time.

Completion (deliverable)

A Discovery Phase can generally be considered complete when the variables surrounding the existing challenge, and the way forward for the product, are defined. What are the goals? Have we identified not just whatâs wanted but whatâs needed? Whatâs the scope of the challenges uncovered and the solutions proposed? How are the outcomes of these solutions going to be measured?

A Design Sprint can generally be considered complete when users have validated or invalidated the product, feature or service to be built via testing prototypes. Was this product, feature, service, etc. desired by users? Did users achieve their goals? What patterns surfaced from interviews and tests? What can we do better? What have we learned?

Expertise (team)

In both a Discovery Phase and a Design Sprint itâs important to bring the right team together. In a Discovery Phase we want stakeholders such as owners, designers, developers, business analysts, service reps, etc. who can identify problems to be solved. Yes, in a Design Sprint we might involve these entities as well, but we need to involve users who can validate solutions to the challenges weâre trying to solve.

Understanding the general differences between a Discovery Phase and a Design Sprint will help in deciphering which one is needed and when, as well as when and to whom to sell these processes. What are some things to look for when determining if you should pursue a Discovery Phase or a Design Sprint?

Deciding Between the Two

Generally, the broader the scope of the challenge the less likely a team is in a position to do a Design Sprint. Instead, one might consider engaging in a Discovery Phase to narrow a problem area first. Then, consider Design Sprints to prototype and test primary solutions to a target facet of that narrowed problem. For example, asking to âreinvent the way in which we communicateâ might be a tall order for a week long Design Sprint, and more so a discussion suited for Discovery.

The value of a Discovery Phase to a business owner its ability to provide a crystal-clear understanding of what their company, product or service needs in order to advance and increase value moving forward. Itâs a hands-on experience that will give everyone involved the tools and insight they need to make informed decisions about the future of their product or service.

In order to focus in on a Design Sprint there generally needs to be a significant amount of input to draw from. This would mean design research data should already exist, particularly in regards to users. Interviews, personas, journeymaps, ethnography, etc. should be considered prior to a Design Sprint, often within Discovery. However if these already exist, one might consider using a Sprint.

The value of a Design Sprint to a business owner is itâs ability to bring an idea to life and then validate or invalidate it quickly. This is because its structure allows for failure to happen without wasting resources, therefore quickly invalidating ideas. Yet it provides a rapid and solid foundation for beginning development on validated ideas. The time and effort spent on validation or invalidation is significantly less, therefore potentially saving business owners large amounts of money when chasing prospective innovation.

How to Contribute to Ember

2016-09-30 00:00:00

tl;dr

There are numerous ways to contribute to open source software. You can do one of the following:

Engage, Help and Teach
Write articles and improve learning resources
Create and comment on issues
Contribute code
Build the community

Today, we'll use Ember as an example. To find out ways to aid the Ember community, read more below!

Open Source is Used by Everyone

A majority of the tools we use at DockYard are open source software (OSS) and we love giving back to the community. If you're reading this post, the chances that you are using OSS are pretty darn high. Just take a look at the Wikipedia page for the list of free and open source software packages. It's safe to say that OSS is used by a bizallion companies each day!

Examples of OSS at DockYard

Some highlights of DockYard's current stack includes Elixir, Phoenix, and Ember. Not only do we utilize these tools to build amazing applications, we also contribute back to these fantastic organizations.

If you're interested in Elixir, I recommend checking out Brian's post entitled How to contribute to Elixir. In that post, he goes over his experience contributing code to the language.

Cheesy Call to Action: What Can You Do?

Today, we'll touch upon a few basic ways to contribute back to the Ember community.

If you're a beginner to open source, have no fear! I have had the great fortune of working with some amazing OSS contributors, who all started out inexperienced, yet, have grown to become open source powerhouses.

Let's Start Contributing (to Ember)

Ember has been around for while (some say as early as 2011), and as expected, has greatly matured. From recommended tools to best practices, Ember's ever improving wave has been a wild, yet relatively safe ride. I've been working with Ember before it was cool, and can share my personal experience with helping out the community.

Thanks, Hassan for the hilarious infuriated Tomster

Engage, Help and Teach

The Ember community page lists various places where users can chat, discuss, or ask questions. However, it should be noted that from my experience, IRC and discussion forum do not receive as much traffic as the Slack community.

I recommend using the Slack community as the number one communication resource. There are numerous channels that range from local user groups to testing practices. I suggest examining the channels you'd like to belong to, and engage with fellow users.

The #-help channel is a great place to ask Ember-related questions. Furthermore, there are plenty of opportunities to help and teach your fellow developers about Ember.

A real life enactment of someone helping another person in the Ember Slack community

Write articles and improve learning resources

I have read my fair share of articles based upon web development (I have stopped reading any articles about JavaScript fatigue though). I imagine many of us have learned a great deal from articles detailing one cool trick by a seasoned developer, or an article describing the pros and cons of a given programming language. My point is that so many of us learn from consuming blog posts, articles, etc.

So, add to the sea of knowledge, and write something you know about. Heck, I'm doing that right now! And, if someone has already written about a topic you care about, perhaps you can offer another perspective or additional advice.

The Ember guides are open sourced on GitHub, and there are plenty of issues marked as "help-wanted".

Create and Comment On Issues

Just like any other open source project, Ember and its associated libraries, receive a high number issues. Luckily, we can help out!

Let's say you happen to run into a "bug", what should you do next? First, search through the existing issue tracker for the given project, and attempt to find your issue. If you find your issue, add a comment!

Thorough comments on a particular issue can help tremendously. If you see a comment, and are experiencing the same issue, please don't bombard the maintainers with a "+1" comment. Instead, offer something more insightful. You can attach an Ember Twiddle in an effort to recreate the issue, and state your expectation vs. actual behavior.

If you can't find an existing issue that replicates yours, create a new one. Ember actually has a good recommendation on issue reporting. Following these steps helps to ensure that your issue can be recreated and corrected as soon as possible. Moreover, it opens up the opportunity for others from the community to solve your issue.

Contribute Code

Submitting pull requests to Ember libraries is straightforward. There is a channel within the Slack community called dev-ember that is reserved for the discussion of "development on Emberjs itself."

So long as you follow the aforementioned guidelines, submitting a PR is an easy process.

Just like any other code base, Ember libraries can be intimidating at first, however with enough persistence, you'll be cooking in no time! In addition, "contributing code" can take the form of contributing documentation.

Lastly, if you stick around, the maintainers occasionally ask for community help, and you'll be rewarded with a great opportunity to help out.

Please Ember community... you're my only hope

Build the community

When I say building the community, I mean you don't necessarily need to go out and create a whole new meetup, or start a brand new conference (though those are all good things). There are other less exhausting methods of building and improving the Ember community.

There are various meetups to join, and plenty of ways to contribute. Submitting a talk - whether it is a conference proposal or a lightning talk - will allow you to broadcast your experiences with Ember, and help generate new discussions. Secondly, I enjoy attending local meetups and conferences as it gives me the chance to place faces with GitHub, Twitter, and Slack handles.

Fin

Hope you found this article helpful! And before you go, our entire blog is open sourced, so if you find a typo or want to make a suggestion, please feel free!

Retiring Ember Suave

2016-09-30 00:00:00

"The role of style in programming is the same as in literature: It makes for better reading. A great writer doesn't express herself by putting the spaces before her commas instead of after, or by putting extra spaces inside her parentheses. A great writer will slavishly conform to some rules of style, and that in no way constrains her power to express herself creatively."

While the writer analogy taken from Douglas Crockford's much rigid JSLint may hold true for the English language, even something as simple as a space can follow different rules in different parts of the world. For instance, in French, the exclamation point is always preceded by a space.

In the world of code, it matters less whether you are a fan of semi-colons first, or whether you favor tabs over spaces (except that we all know one is right and the other is wrong); what matters is that code style is consistent within a team, and that there is a way to enforce it.

The rise of `ember-suave`

When my fellow DockYarders and I originally decided to make code style checking a part of our regular Ember CLI development workflow, JSCS was the de facto code style checker. We thus set out to build ember-suave.

The addon used broccoli-jscs internally, but it also shipped with an already configured set of JSCS rules as well as custom rules we had written. We wanted it to be opinionated, something that we could simply drop into any of our Ember CLI projects and start coding against. We wanted to put the S in Suave.

We also made the preset configurable with the hope that it would be usable by anyone outside of DockYard who might be looking for a quick jump start on JSCS, since they would only need to overwrite those rules that do not align with their team's style guide. It turns out that ember-suave did end up being used across a sizeable number of projects.

For all those folks, I would like to announce at last that we are retiring ember-suave. This means that we will no longer build custom rules for it or enhance it in any way, and that it may just as well find its way into Davy Jones' Locker, which is where all abandoned DockYard open-source projects go to die.

JSHint, JSCS, and ESLint

JSCS reached end-of-life back in July, three months after joining up with ESLint.

For a bit of history, when JSHint started focusing strictly on functional rules, JSCS emerged as the static analysis tool for all stylistic concerns in JavaScript. This was sometime back in 2013. For the longest time, JSHint and JSCS complemented each other rather well.

Meanwhile, Nicholas Zakas created ESLint as a fully pluggable alternative to JSHint. As ESLint and JSCS matured and grew in popularity, the two projects started overlapping in functionality and goals, so instead of continuing to lead separate ways, they joined up. You can read more about the merge here.

`ember-suave` returns as an ESLint plugin

Most of the rules from ember-suave, including the custom ones, have been converted to ESLint in a new repo called eslint-plugin-ember-suave.

The biggest difference is that you are no longer looking at an Ember CLI addon. eslint-plugin-ember-suave, as its name implies, is simply an ESLint plugin (the equivalent of a JSCS preset). It's just a collection of custom rules and their configuration, as well as configuration of additional rules already built into ESLint.

In order to run ESLint with the supplied configuration, you will need to install the ember-cli-eslint addon into your Ember project. It is worth noting that doing so will also uninstall any existing installation of ember-cli-jshint, since it doesn't make sense to use both linters simultaneously.

The joy of having contributors

Migrating ember-suave over to an ESLint plugin had been a lingering goal for quite some time. I just happened to have limited time to devote to it. To that end, I have contributors to thank, particularly Alex LaFroscia, for spearheading the effort. He rewrote all the JSCS custom rules we had in ember-suave to their ESLint equivalents. Robert Wagner also landed a hand in accelerating the development of the plugin, at a time when I was mostly taking a hands-off stance due to maternity leave. I do appreciate that they motivated me to code every now and then, as much as it was challenging to pair program with a two-month old.

Understanding Ember's resolver

2016-09-14 00:00:00

Ember's dependency injection system is driven by a resolver. It is used to lookup JavaScript modules agnostic from what kind of module system is used, which can be AMD, CommonJS or just plain globals. A resolver works based on a set of rules, which reflects how Ember apps are structured.

How the resolver is used

The resolver is used widely throughout an Ember application. It is used to lookup routes, models, components and much more.

When your Ember app transitions into a route, the resolver is used to find the corresponding route module. For example: if you navigate to /blog, then the blog route needs to be looked up. This is done by asking the resolver to resolve route:blog, this will resolve a module named blog of type route. After the route is done loading the model, we need a controller, so we ask the resolver for controller:blog. Lastly a template needs to be rendered, so once again we go to the resolver and ask for template:blog.

The same thing happens when rendering a component. First the resolver is asked for component:my-component, then template:component/my-component.

The rules of the resolver

Today the resolver is used the most to resolve modules using Ember CLI's AMD module system. So I'm going to use that in the next few examples.

The prefix

First of all, a resolver requires a modulePrefix variable. This variable is found in the config/environment file of an Ember CLI app and is being passed to the resolver by your Ember application. You should also know that the app/routes/blog.js file in your Ember CLI app gets a different path in the compiled output. The app part of the path is replaced by the modulePrefix variable. So our example would become my-app/routes/blog if our modulePrefix variable is my-app.

Dissecting a resolver statement

The resolver disects the statement route:blog into two parts, a type (route) and a name (blog). Those parts are then translated into a path which can be used to load a module. In the case of Ember CLI's AMD modules it would give you my-app/routes/blog, which is constructed of modulePrefix / type (pluralized) / name.

The resolver can also easily resolve things nested inside subfolders. For example, template:component/my-component, it'll be resolved to my-app/templates/components/my-component.

You can also make up your own type, it doesn't have to be one of Ember's types. For example, Ember Validations uses the resolver to look up modules of the validator type.

Resolving addon modules

The resolver has one more trick up its sleeve, it can resolve things outside of your app using a custom modulePrefix. If you prefix the statement asked to the resolver with your custom modulePrefix and an @, then it'll replace the configured modulePrefix with yours. The statement an-addon@component:x-utility would be resolved to an-addon/components/x-utility.

Some exceptions

The resolver has some exceptions built in, to resolve a few special things. Anything with main as the name part will resolve without the name in the resulting module name. So router:main will resolve to my-app/router, leaving out the name part. The same rule applies to store:main.

Conclusion

The resolver is a fairly straightforward abstraction that helps you resolve modules, agnostic from all the various module loading systems. If you get to know how it works it can be a great new tool in your arsenal.

KISS by Example: Authorization in Phoenix

2016-09-08 00:00:00

Modules, Functions, and Pattern Matching. Oh My!

As a relatively new Elixir developer, I continue to be impressed by the things the language allows me to accomplish relatively easily. Features that seemed daunting or time consuming before end up being as simple as: "Modules. Functions. Pattern Matching." Instead of relying on pre-built solutions, a lot of the time your code ends up simpler and easier to reason about if you take advantage of what is in front of you.

Example: Web App Authorization

Let's pretend we're building a web application where users submit talk ideas for a conference and then the best ones are selected to be included. Users can submit and edit their own proposals, and admins can mark a talk as chosen. We want to enforce that a rogue user can't select random talks or edit other users' talks to be about nonsense.

Not worrying about how the logic works within the application, let's just lay out some rules for what users can do to talks.

  
  defmodule FakeConf.TalkAuthorizer do
  alias FakeConf.{Talk, User}

  # Anyone can go and create a talk
  def authorize(:create_talk, %User{} = _user), do: :ok

  # Only the user that created a talk can edit it
  def authorize(:edit_talk, %User{} = user, %Talk{} = talk) do
    if owned_by?(user, talk) do
      :ok
    else
      {:error, :unauthorized}
    end
  end

  # Only admins can 'choose' talks
  def authorize(:choose_talk, %User{is_admin: true} = user, %Talk{}), do: :ok
  def authorize(:choose_talk, %User{}, %Talk{}), do: {:error, :unauthorized}

  defp owned_by?(%User{} = user, %Talk = talk) do
    talk.user_id == user.id
  end
end

This keeps our authorization code nice and contained! When we implement more features, it will be easy to add them to this module.

Now that we have these rules, we can use them in our application. We'll use the new with macro here to chain authorization into our existing app logic.

  
  defmodule FakeConf.Talks do
  alias FakeConf.{Talk, Repo, TalkAuthorizer}

  def create_talk(%User{} = user, talk_params) do
    talk = %Talk{user_id: user.id}
    with :ok <- TalkAuthorizer.authorize(:create_talk, user),
         {:ok, talk} <- Repo.insert(changeset(talk, talk_params)) do
      :ok
    else
      {:error, :unauthorized} -> {:error, :unauthorized}
    end
  end

  def edit_talk(%User{} = user, talk_id, talk_params) do
    with %Talk{} = talk <- Repo.get(Talk, talk_id),
         :ok <- TalkAuthorizer.authorize(:edit_talk, user, talk),
         {:ok, talk} <- Repo.update(changeset(talk, talk_params)) do
      :ok
    else
      {:error, :unauthorized} -> {:error, :unauthorized}
      {:error, :not_found} -> {:error, :not_found}
    end
  end

  def choose_talk(%User{} = user, talk_id) do
    with %Talk{} = talk <- Repo.get(Talk, talk_id),
         :ok <- TalkAuthorizer.authorize(:choose_talk, user, talk),
         {:ok, talk} <- Repo.insert(changeset(talk, %{chosen: true})) do
      :ok
    else
      {:error, :unauthorized} -> {:error, :unauthorized}
      {:error, :not_found} -> {:error, :not_found}
    end
  end
end

Super simple, clean, and easy to read because we're combining functions that are organized in modules. Nothing crazy happening.

This isn't just an example of how to do authorization. When you're looking to add a feature to your application, consider it might be simpler than you think when you take advantage of the tools you have available. When in doubt... 'Keep It Simple, Silly'!

Deep Work - Lessons I will apply to UX Design

2016-08-24 00:00:00

Last week, I finished Kal Newportâs Deep Work. I started out reading the book, but about halfway through realized Iâm getting a lot of value from it and purchased the audiobook of it as well. This not only increased my retention of the material, but allowed me to listen to it while doing other things. I got through the book at least twice within three weeks, a relatively fast pace for me.

Deep Work had many takeaways for my career as a whole, but it seemed especially useful for running design processes. A key concept in the book is the title, Deep Work: it is both the state and the ability to concentrate on knowledge work, and is the opposite of a distracted state. Kal argues that deep work is becoming more important and more scarce in the current economy.

There is deep work in UX design

The first thing I considered was, which parts of my and my teamâs jobs deep work applies to. Does my entire day need to be deep? When is the best time to schedule âshallowâ vs. deep tasks?

One key activity where I see the most need for deep work is the Discovery phase of a project. Specifically, the second half - once weâve opened up the playing field and outlined all the possible ideas and directions in which we could potentially focus our effort, we must narrow down to get to a realistic product definition. Kal describes this process as operating with many variables and considerations in our active memory. To keep this focus, we must perform deep work. Distraction at this point is very costly, because it requires a long time to get re-started even after a quick break.
Another key activity where I know deep work is needed is the wrap-up of a project. The last week of design work (letâs say weâre talking about a 5-6 weeks total) involves making detailed changes and refinements to designs, as well as looking at the big picture to ensure all needs are covered. The combination of detail focus and the âbig pictureâ in the active memory is quite taxing as it is. Even a quick switch of focus to answer a question on another project will impact the quality or speed of the wrap-up.

Thereâs a time & place for less-deep work

In planning my and my teamâs time I also need to consider activities which can be performed in a more âshallow workâ mindset. While we could ideally have full focus all of the time, we do need to prioritize. Here are some things that would suffer less from a shallow focus mindset, and potentially even benefit from a relaxed, improvisational atmosphere, where group chatter and distraction can actually lead to new ideas.

Every project has some component of âpoking aroundâ or initial research into visual style, the industry, or typical interactions of a given type. (Do not confuse this with the deeper research and strategy efforts, which are focused on getting very specific, hard-to-find answers.)
In the middle of the visual design effort, with tasks and priorities lined up and activities somewhat predictable, shallow work may be acceptable. Itâs still beneficial to keep sustained focus, but the cost of focus switching is relatively lower.
Collaboration and critique (also called design reviews) can be a great âshallowâ activity. For example, when I check in with the team to see how their day went, I might actually benefit from having a shallower focus on their specific project. From this outsider perspective, I can catch âobviousâ things they may not have noticed due to a deeper focus on the details, but avoid micro-managing and let folks be professionals and own their own work.

You may already be scheduling deep work

As I looked back on the way DockYard Design operates after reading Deep Work, I noticed that weâre well on our way to creating a system that supports deep work where needed. For example, when running design sprints, we go âofflineâ - meaning weâre less available on Slack or by email - for large chunks of the day. We also schedule time to catch up on shallow tasks around those focused times: a typical in-person collaboration would be scheduled 10ânoon and 1â4, leaving an hour of our workday in the morning and afternoon to catch up, document and regroup with the team.

I also noticed (with no surprise) that a schedule heavily focused on management cannot be fully tailored to maximize deep work. There will be times when meetings, or urgent questions will take priority and the amount of deep work I can schedule around them will be decreased.

The main takeaways

If I were to summarize the key takeaways from the book, hereâs what youâd see:

Schedule deep and important work in large, unbroken chunks of time first. Then, schedule shallower tasks together in batches around that.
Most people donât consider their availability purposefully. With modern communication tools, weâve become available by default, and it is costing us the ability to focus. If nothing else - question this assumption, and consider the consequences of allowing yourself to be distracted.
One interesting strategy to manage shallow work is to schedule a specific, limited portion of your work day to tackle shallow tasks. This way, the less-important tasks may not get done, but they will also not prevent you from achieving the truly important goals, which require deep work.
Kal proposes to measure the depth of any given task by imagining how long it would take a bright and energetic recent college graduate to train up to do the task for you. If the time is relatively short (e.g. taking a couple of weeks to learn how to manage a social media presence) then the task is shallow. If the time is long (e.g. taking several years to learn how to create original academic research or acquire insight to write a book) then the task is deep.

In conclusion - Deep Work questions many assumptions about the way we run our work lives, and proposes specific alternatives. The book is structured as such a clear logical argument (perhaps, owing to Kalâs background in the theory of computation and his academic writing) that itâs hard to ignore the advice. It felt a bit repetitive as I was listening to the introductory chapter (in a Dale Carnegie kind of way) but Iâm now reaping the benefit of that repetition by being able to recite the argument back to anyone whoâd care to listen. This is great book for any knowledge worker, and Iâve confirmed that itâs useful for anyone in a design role. I highly recommend it!

What design discovery feels like

2016-08-23 00:00:00

I often struggle to describe what it is that I do for a living. You may feel the same, especially when talking to friends outside of your industry, or at any given family gathering. In the past few months, a large and I believe most important part of my job at DockYard was helping get projects started right.

A stereotypical UX designer at work. Sticky notes in bright colors are essential.

We call this initial phase of a project design discovery, and believe that a design-first approach saves a lot of money and frustration by figuring everything out with the simplest paper-and-pen prototypes first. But Iâm not talking about the business logic, or methods that inform discovery right now. I want to talk about how it feels to be part of it - from the beginning, staring at a bunch of unknowns, and right through the end when the answer becomes clear.

Among all the things I do, the activity of kicking off projects is the hardest one to describe. Itâs the thing that needs to happen before anyone can start making the actual thing. Before youâve done a discovery, you mostly have questions, or rather, you have questions about what the questions should be. (After all, asking the correct question is 80% of solving a problem.) Then, as you work through user flows and specific screens the answers start to become more obvious, and you can make decisions together with the client about what the thing youâre building should do, and which features youâll build first to make that possible.

Feeling âdoneâ with discovering something doesnât always look complex.

If all goes well, the end result should look suspiciously simple. Obvious, even. Youâll have gotten rid of many creative but complex features. Those would be nice to have in the future, but it doesnât make sense to invest in the bells and whistles until youâve built the basics. The outcome of a Discovery can feel like the outcome of a good summer vacation. Youâve done some (but not all) of all the possible things youâd imagined youâd do. Youâve had to narrow down your long list of fuzzy imagined dream-like things you could possibly do to a realistic and actionable schedule.

The feeling of summer and possibility is similar to the beginning of discovery. It wonât last forever, but enjoy it while it does! Image Credit

Discovery is a process that turns a strong desire to have a vacation, plus a list of ideas and dreams into something you can reliably act upon. If the end of summer has ever hit you by surprise, as you realized youâd never made time for the one important trip youâd definitely thought youâd do this year - planning could help.

And if youâre an entrepreneur, or a UX designer, or even an engineer about to embark on a discovery process, this is how it should feel.

And in the beginning, itâs open and exciting but often so open itâs scary. Your collaborators keep asking seemingly obvious questions. (We uncover a new and important motivation every single time. Itâs worth the time and effort.) It can be frustrating because the things you thought were clear still need definition. Things can even get heated, as you discuss the details of a collaborative project and realize your assumptions might be different from your collaboratorsâ, and also different from the assumptions your users hold. The early stages of a discovery are like the beginning, dreamy stages of planning a vacation. You know a good thing is ahead, and you can spend some time with all the possible amazing options open to you, but know that the longer you delay the decisions, the longer you wait to do the actual thing.

In the middle, itâs hard. Youâre making tough decisions to prioritize among ideas and features, while you care and see the need for all of them. (Eventually).

At the end, things look obvious - so obvious that you canât wait to get started actually making them. You know exactly what to do first.

Enjoy the rest of the summer! (Remember, officially, we have till September 21st :-)

The minimum knowledge you need to start Metaprogramming in Elixir

2016-08-16 00:00:00

Metaprogramming is writing code that writes code. In Elixir, we use macros to transform our internal program structure (AST) in compile time to something else. For example, the if macro is transformed to case during compilation, we call this macro expansion.

  
  if true do
  IO.puts "yea"
end

# becomes

case(true) do
  x when x in [false, nil] ->
    nil
  _ ->
    IO.puts("yea")
end

The Abstract Syntax Tree (AST) and AST literal

The internal representation of Elixir code is an abstract syntax tree which is the protagonist in program transformation. Elixir also refers to an AST as a quoted expression.

The quoted expression is composed of three-element tuples:

  
  # simple one: AST for 1 + 2
{:+, [context: Elixir, import: Kernel], [1, 2]}

# nested one:
# AST for
# def hello do
#   IO.puts "hello"
# end

{:def, [context: Elixir, import: Kernel],
 [{:hello, [context: Elixir],
   [[do: {{:., [], [{:__aliases__, [alias: false], [:IO]}, :puts]}, [],
      ["hello"]}]]}]}

Essentially, All tuples in the AST follow the same pattern:

{function_call, meta_data_for_context, argument_list}

During compilation, all of our source code will be transformed into AST before producing final bytecode. However, there are five Elixir literals that will remain the same format as their high-level source.

The following example shows the differences between Elixir literal and other normal data types:

  
  # AST for {1, 2, 3}
{:{}, [], [1, 2, 3]}

# AST for %{a: :hello}
{:%{}, [], [a: :hello]}

# AST for {1, 2} (AST literal)
{1, 2}

Macro

Macros receive AST as arguments and provide AST as return values. The returned AST is injected back into the global programâs compile tree, in this way, macros enable syntactic extensions and code generation.

Syntactic extensions: e.g. we can implement while which is not available in Elixir or create DSL
Code generation: e.g. generate function from external data

Return AST

There are three ways to create quoted expressions in Elixir:

Manually construct it
Macro.escape
quote/unquote to compose AST

  
  defmodule MyMacro do
  @opts: %{time: :am}

  # case 1
  defmacro one_plus_two do
    {:+, [], [1, 2]}
  end

  # case 2
  defmacro say_hi do
    quote do
      IO.puts "hello world"
    end
  end

  # case 3
  defmacro ops do
    Macro.escape(@opts)
  end
end

defmodule MyModule do
  import Mymacro

  def case1 do
    IO.puts one_plus_two()
  end

  def case2 do
    say_hi()
  end

  def case3 do
    IO.inspect ops()
  end
end

#=> c "example.exs"
#=> MyModule.case1()
#=> "3"
#=> MyModule.case2()
#=> "hello world"
#=> MyModule.case3()
#=> %{time: :am}

In this example, we define three macros using defmacro, all of them return quoted expressions, then we import MyMacro module into MyModule. During compilation, these macros will be expanded and the returned AST will be injected into MyModule's compile tree.

It's difficult to construct an AST by hand. We should almost always should use quote and Macro.escape to build up an AST using Elixir's own syntax. The main differences between these two are:

quote returns AST of passed in code block.
Macro.escape returns AST of passed in value.

Here are some examples:

  
  data = {1, 2, 3}

quote do: {1, 2, 3}
#=> {:{}, [], [1, 2, 3]} (AST of {1, 2, 3})

quote do: data
#=> {:data, [], Elixir} (data is not inject into returned AST)

quote do: IO.inspect(1)
#=> {{:., [], [{:__aliases__, [alias: false], [:IO]}, :inspect]}, [], [1]}
quote do: IO.inspect(data)
#=>{{:., [], [{:__aliases__, [alias: false], [:IO]}, :inspect]}, [],
 [{:data, [], Elixir}]}

Macro.escape(data)
#=> {:{}, [], [1, 2, 3]}

IO.inspect(1)
|> Macro.escape()
#=> :error

Notice that data variable is not injected into the AST returned by quote block, in order to do that, we need to use unquote, which we will discuss later.

Receive AST

Let's take an example to see how macros receive AST:

  
  defmodule M do
  defmacro macro_args(a, b) do
    IO.inspect a
    IO.inspect b
  end
end

#=> c "example.exs"
{:+, [line: 22], [1, 1]}
2

After compiling the module, we can see the results: {{:+, [line: 22], [1, 1]}} and 2, they are both quoted expressions. Remember that number is an AST literal so its quoted expressions remains the same as itself.

Combining this fact with the pattern of AST, we can easily do pattern matching to get what we want from the argument for further AST composition.

Keep in mind that code passed into a macro is not evaluated or executed. As we saw earlier, Macros receive AST as arguments and provide AST as return values.

unquote

unquote injects quoted expressions into the AST returned by quote. You can only use unquote inside quote blocks.

To make it easier to understand, you can think quote/unquote as string interpolation. When you do quote, it's like creating string using "". When you do unquote, it's like injecting value into string by "#{}". However, instead of manipulating string, we are composing AST.

There are two types of unquote:

Normal unquote

  
  data = {1, 2, 3}
quote do
  IO.inspect(unquote(data))
end

It looks correct, but when we evaluate the AST, we will get an error:

How come? It's because we forget an important concept:

unquote injects AST into AST returned by quote.

{1, 2, 3} is not an AST literal, so we need to get the quoted expressions. first by using Macro.escape.

  
  data = {1, 2, 3}
quote do
  IO.inspect(unquote(Macro.escape(data)))
end

Unquote fragment

Unquote fragment is added to support dynamic generation of functions and nested macros.

  
  defmodule MyModule do
  Enum.each [foo: 1, bar: 2, baz: 3], fn { k, v } ->
    def unquote(k)(arg) do
      unquote(v) + arg
    end
  end
end

#=> MyModule.foo(1) #2
#=> MyModule.bar(1) #3
#=> MyModule.baz(2) #4

In this example, we use unquote(k) as function name to generate functions from keys of a Keyworld list.

You might wonder why we can use unquote without quote. It's because def is macro, its arguments will be quoted automatically as we discussed above.

Besides, we need quote(v) inside function body because of scope rule in Elixir:

for named function, any variable coming from the surrounding scope has to be unquoted inside a function clause body.

Bind_quoted

bind_quoted does two things:

1 prevent accidental reevaluation of bindings.

If we have two same unquote inside quote block, the unquote will be evaluated twice, this can cause problem. We can use bind_quoted to fix it:

  
  # bad
defmacro my_macro(x) do
  quote do
     IO.inspect unquote(x) * unquote(x)
  end
end

# good
defmacro my_macro(x) do
  quote bind_quoted: [x: x] do
     IO.inspect x * x
  end
end

2 Defer the execution of unquote via unquote: false

unquote: false is the default behavior of bind_quoted.

The order of execution is:

when a macro module is compiled, code in the macro context will run first (IO.puts 1). Normal code in quote block will not be executed until the returned AST is injected into caller module. However, unquote code will "break the wall" and run in macro's context.

Macro module

  
  defmodule M do
  defmacro my_macro(name) do
    # macro context
    IO.puts 1

    quote do
      # caller context
      IO.puts 4
      unquote(IO.puts 2)
    end
  end
end

Caller Module

  
  defmodule Create do
  import M
  IO.puts 3
  my_macro("hello")
end

According to the explanation above, we can know the result of the example is: 1 2 3 4.

If we use bind_quoted in the example, the order will change. The unquote code will be treated as normal code and run in caller's context. Therefore, the result for the following example is: 1 3 4 2.

  
  defmodule M do
  defmacro my_macro(name) do
    IO.puts 1

    quote bind_quoted: [name: name] do
      IO.puts 4

      def unquote(name)() do
        unquote(IO.puts 2)
        IO.puts "hello #{unquote(name)}"
      end
    end
  end
end

  
  defmodule Create do
  import M
  IO.puts 3
  my_macro(:hello)
end

This is helpful because when we change my_macro(:hello) in caller module to

  
    [:foo, :bar]
  |> Enum.each(&my_macro(&1))

Our code will still work because the each function is executed before the injected AST.

How to do experiments

The best way to learn is trial and error. Elixir provides a few functions that can help us: IO.inspect, Code.eval_quoted, Macro.to_string, and Macro.expand/Macro.expand_once. Let's find out more about each one:

IO.inspect

We can use IO.inspect to output the details of macro arguments or whatever we want.

Code.eval_quoted

eval_quoted helps to evalute AST we created:

  
  data = {1, 2, 3}
ast = quote do
  IO.inspect(unquote(Macro.escape(data)))
end
Code.eval_quoted(ast)

#=> {1, 2, 3}

Macro.to_string

It converts the given quoted expressions to a string.

  
  Macro.to_string(ast)
#=> "IO.inspect({1, 2, 3})"

Macro.expand/Macro.expand_once

Macro.expand will receive an AST node and recursively expand it. We can also expand AST once a time using Macro.expand_once.

  
  ast = quote do: if true, do: IO.puts 1
Macro.expand_once(ast, __ENV__)

{:case, [optimize_boolean: true],
     [true,
      [do: [{:->, [],
         [[{:when, [],
            [{:x, [counter: 0], Kernel},
             {:in, [context: Kernel, import: Kernel],
              [{:x, [counter: 0], Kernel}, [false, nil]]}]}], nil]},
        {:->, [],
         [[{:_, [], Kernel}],
          {{:., [], [{:__aliases__, [alias: false, counter: 0], [:IO]}, :puts]}, [],
           [1]}]}]]]}

Resources

Now we know the basic about metaprogramming in Elixir, it's time to write simple macro, do some experiments and read source code of Elixir or Phoenix.

Also, there are two great resouces:

Metaprogramming Elixir by ChrisMcCord

Great book to read. A lot of practical examples in the book that teach you how to write macros.

understanding macro blog series by SaÅ¡a JuriÄ

Pieces of Ember: Part 1

2016-08-12 00:00:00

I've been working with Ember for years now, even though it feels like just yesterday. Not everyone has had this opportunity and I am often met with questions from inquisitive developers and engineers about the state of Ember.

They know that Ember is an ambitious framework. They've heard it can help boost their productivity. Yet, they hesitate. The project put in their hands is "basically just a landing page" or they believe most frameworks to be excessive - and this concern can be valid. Ember is a mature framework with opinions, build tools, and blueprints that enable me, an Ember developer, to focus on engineering an application rather than boilerplate and redundancy.

What these developers probably don't know is that many of the core pieces that make the Ember ecosystem the beautiful powerhouse that it is are also available as micro-libraries.

Some of the most well known micro-libraries behind the Ember framework are:

These pieces of Ember would be able to provide any JavaScript project with:

Promises
Build tools
Routing capabilities
View templating
Templating with Virtual DOM

All without the need to buy into the entire Ember ecosystem.

This post is part 1 of a 3 part series on the pieces of Ember. It is also a continuation or elaboration of a lightning talk I gave at the July SanDiego.js Community event which can be found here.

Part 1: RSVP and Broccoli
Part 2: Route-recognizer and Router
Part 3: Handlebars and HTMLBars

tildeio/rsvp.js

This library is a tiny implementation of the Promises/A+ spec. This can be used without a transpiler just like any other promise library.

The library itself is rather similar to Bluebird and When. Under the hood there are some performance boosts gained by avoiding unnecessary internal promise allocations. This provides noticeable improvements in many common scenarios.

The other unique thing to note about this library is that RSVP aims to be fast across more than just the V8 runtime, while libraries like Bluebird are more or less V8-focused.

  
  let RSVP = require('rsvp');

let promise = new RSVP.Promise((resolve, reject) => {
  //succeed
  resolve(value);
  // or reject
  reject(error)
});

promise.then((value) => {
  //success
}).catch((error) => {
  // failure
});

broccolijs/broccoli

Broccoli is the fast build pipeline used by ember-cli and that is available outside of the Ember ecosystem. Broccoli is intended to be relatively easy to learn, performant, and composable. The plugin system for broccoli is what makes it so composable and even with plugins depending on other plugins, creating a large tree of plugin dependencies, broccoli manages to still provide performant sub-second speeds.

Broccoli provides a powerful build tool chain that can be used very easily to get a project up and running outside of Ember.

Given a simple project with the following structure:

  
  .
+-- app
|   +-- css
|   +-- js
|   +-- img
|   +-- index.html
+-- node_modules/
+-- .gitignore
+-- Brocfile.js
+-- README.md
+-- package.json

It is easy to serve up the assets and create a pipeline with just a few key broccoli plugins and a rather short Brocfile.js.

  
  $ npm i --save-dev broccoli-concat
$ npm i --save-dev broccoli-merge-trees
$ npm i --save-dev broccoli-static-compiler
$ npm i --save-dev broccoli-uglify-js

  
  'use strict';

const concatenate = require('broccoli-concat');
const mergeTrees = require('broccoli-merge-trees');
const pickFiles = require('broccoli-static-compiler');
const uglifyJS = require('broccoli-uglify-js');

const app = 'app';

let appCSS;
let appHTML;
let appJS;
let appImages;

/*
 * move index from `app/` to root of tree
 */
appHTML = pickFiles(app, {
    srcDir: '/',
    files: ['index.html'],
    destDir: '/'
});

/*
 * concat and compress all js files from `app/js/` and move to root
 */
appJS = concatenate(app, {
  inputFiles: ['js/**/*.js'],
  outputFile: '/app.js'
});

appJS = uglifyJS(appJS, {
  compress: true
});

/*
 * concat all css files from `app/css/` and move to root
 */
appCSS = concatenate(app, {
  inputFiles: ['css/**/*.css'],
  outputFile: '/app.css'
});

/*
 * move images from `app/img` to image folder
 */
appImages = pickFiles(app, {
  srcDir: '/img',
  files: ['**/*'],
  destDir: '/img'
});

// merge the trees and export
module.exports = mergeTrees([appHTML, appJS, appCSS, appImages]);

Now running broccoli serve will build and serve the project and provide build times in a well formated and easy to read table.

  
  Serving on http://localhost:4200


Slowest Trees                                 | Total
----------------------------------------------+---------------------
SourceMapConcat                               | 30ms
UglifyJSFilter                                | 13ms
BroccoliMergeTrees                            | 7ms
StaticCompiler                                | 3ms
Slowest Trees (cumulative)                    | Total (avg)
----------------------------------------------+---------------------
SourceMapConcat (1)                           | 30ms
UglifyJSFilter (1)                            | 13ms
BroccoliMergeTrees (1)                        | 7ms
StaticCompiler (2)                            | 6ms (3 ms)

Built - 63 ms @ Tue Jul 26 2016 16:43:40 GMT-0700 (PDT)

When ready to build for deployment the command broccoli build 'dist' would compile all of the assets into the dist directory.

Get more from the Ember ecosystem

Check back for part 2 and part 3 of this series where I review the routing capabilities and templating systems and how to use them outside of Ember.

Using Ecto Changesets for HTML input validations

2016-08-11 00:00:00

All web applications with user submitted input have some constraints on what input is acceptable. We as developers have two methods to make sure what the user entered falls within those constraints.

Client Side Validation where your application checks form data prior to a network call and prevents the call from happening if it finds the data invalid.

Server Side Validation where your application sends data to the server and waits for it to tell you if the data is valid or not.

Both are means to the same end but have their advantages and disadvantages.

Server Side Validation (Necessary)

Pros

Source of truth / "Last line of defense"
Can be tied to DB logic
Knows context of the user, session, or other data
More powerful and secure

Cons

Slow to get feedback due to network latency
Sending the entire form just to get one error

Client Side Validations (Optional)

Pros

Immediate validation
Preventative
Semantically accurate
Nicer feeling feedback due to styling with CSS selectors

Cons

Have to keep it in sync with server side
Brittle
Not a substitute for server side validation

Generally client side validations are optional, faster, and provide better UX, while server side validations are necessary, stronger, and better tied to your data schema.

Ideally you utilize both, but they're a pain to keep in sync. In a perfect world your application's back end validations automatically apply to the client. We're going to explore how Phoenix and Ecto give us the power to help us do exactly that.

We can leverage Phoenix and Ecto.Changeset on our front end with just a few lines of code. This doesn't work for everything (uniqueness constraints for example), but there are some nice things we can validate for: min/max, length, and required fields. Ecto changesets within Phoenix support validate_length, validate_number, validate_required which correspond to the HTML input validations minlength/maxlength, min/max, and required.

Our goal is to have the validations defined in a schema's changeset function automatically apply the correct HTML input validation to our form.

Let's write some code.

The Code

Let's work with a schema named foo with the following changeset function:

  
  def changeset(struct, params \\ %{}) do
  struct
  |> cast(params, [:name])
  |> validate_required([:name])
  |> validate_length(:name, min: 2, max: 4)
end

By default our form should have something like this:

  
  <%= text_input f, :name, class: "form-control" %>

Which generates this markup:

  
  <input class="form-control" id="foo_name" name="foo[name]" type="text">

It works, but we have to wait for a server round trip to get any validations. We can add client side validation by appending opts by hand like this:

  
  <%= text_input f, :name, class: "form-control", required: true, minlength: 2, maxlength: 4 %>

Which generates this markup:

  
  <input class="form-control" id="foo_name" maxlength="4" minlength="2" name="foo[name]" required="required" type="text">

This is better, but if we ever changed the max to something else we would have to remember to change it in two different places!

We can do better by using input_validations. This function generates the HTML validation attributes from our Ecto changeset for us.

Now we can define our own functions which simply add on those generated input validations to our text and number inputs...

  
  alias Phoenix.HTML.Form

def text_input(form, field, opts \\ []) do
  Form.text_input(form, field, opts ++ Form.input_validations(form, field))
end

def number_input(form, field, opts \\ []) do
  Form.number_input(form, field, opts ++ Form.input_validations(form, field))
end

Keep the same markup we had initially...

  
  <%= text_input f, :name, class: "form-control" %>

... and get the semantically correct markup with no changes to the template!

  
  <input class="form-control" id="foo_name" maxlength="4" minlength="2" name="foo[name]" required="required" type="text">

Other validations

This will also work for number validations. Say our changeset function had a line like

  
  |> validate_number(:count, greater_than: 2, less_than: 9)

That would give us this markup

  
  <input class="form-control" id="foo_count" max="8" min="3" name="foo[count]" required="required" step="1" type="number">

Using this in your application

To leverage this in your own Phoenix application, we'll use a module that we will automatically import in all our views.

First define the module with our custom text_input and number_input functions in web/views/valid_inputs.ex

  
  defmodule HelloPhoenix.ValidInputs do
  alias Phoenix.HTML.Form

  def text_input(form, field, opts \\ []) do
    Form.text_input(form, field, opts ++ Form.input_validations(form, field))
  end

  def number_input(form, field, opts \\ []) do
    Form.number_input(form, field, opts ++ Form.input_validations(form, field))
  end
end

Then in web/web.ex just have Phoenix make it available for all our views.

  
  def view do
  quote do
    use Phoenix.View, root: "web/templates"

    # Import convenience functions from controllers
    import Phoenix.Controller, only: [get_csrf_token: 0, get_flash: 2, view_module: 1]

    # Use all HTML functionality (forms, tags, etc)
    use Phoenix.HTML

    # vvvv BEGIN OUR CODE vvvv
    import Phoenix.HTML.Form, except: [number_input: 2, number_input: 3, text_input: 3]
    import HelloPhoenix.ValidInputs
    # ^^^^ END OUR CODE ^^^^

    import HelloPhoenix.Router.Helpers
    import HelloPhoenix.ErrorHelpers
    import HelloPhoenix.Gettext
  end
end

And we're done! Now that your inputs have constraints, you can use CSS selectors like :invalid and :required to make things look a bit nicer for the user.

Custom Validations

There's also a lesser known pattern HTML attribute for regex validations. The JavaScript and Elixir regex engines are not 100% compatible so it's not supported by default in input_validations but we can add it ourselves as an exercise in custom validations.

  
  |> validate_format(:email, ~r/.+@.+/)

  
  def text_input(form, field, opts \\ []) do
  Form.text_input(form, field, extend_opts(form, field, opts))
end

defp extend_opts(form, field, opts) do
  defaults = opts ++ Form.input_validations(form, field)

  case form.source.validations[field] do
    {:format, regex} -> [{:pattern, Regex.source(regex)} | defaults]
    _ -> defaults
  end
end

  
  <input class="form-control" id="foo_email" name="foo[email]" pattern=".+@.+" type="text">

Because we're just composing and calling functions, we can extend our initial implementation easily without having to inherit or monkey patch from an existing View module. Going further, you can tweak your text_input and number_input to, for example, take an optional validate parameter to include opt in/opt out functionality.

The takeaway

Using simple functions available in Phoenix, your application can automatically apply some of your in-place server side validations to your front end markup to improve your UX in only a few lines of code!

ELI5: Upcoming Developments in Ember.js

2016-08-10 00:00:00

ELI5: Upcoming Developments in Ember.js

As a newcomer to Ember in the past few months, it's been fascinating to not only learn how to build applications with a great JS framework, but also to gain insight into how a massive and popular open source project grows and absorbs new ideas. Although I'm probably a little bit biased at this point, I believe Ember does a better job than most at managing and encouraging this process.

The primary channel for discussion of introducing new features into Ember is the public RFC repository on GitHub. RFCs, which stand for 'Request For Comment', are pull requests in which any developer can outline a feature specification and open the floor for comments and criticism. This is what true open source looks like, and the success of the RFC repo represents to me the best aspects of the Ember community.

All of that being said, it can certainly be a little intimidating for someone new to the framework to dive right in and catch up on the most significant RFCs being discussed. So I decided to do a little write up that made that easier.

Here are the three RFCs that have provoked the most discussion, and perhaps demonstrate what the future of Ember looks like:

Module Unification

Create a unified pattern for organizing and naming modules in Ember projects that is deterministic, extensible, and ergonomic.

This seems like the best one to start with, since it's the one most likely to affect all users of Ember and dramatically impact daily use of the framework. In short, this RFC aims to provide an improved ergonomic directory structure for all new Ember projects.

Why? Well, there are unfortunately a few too many deficiencies with the current system of organizing Ember modules.

Developers have to decide between using the pod or classic app structure.
Addons are directly mixed into the codebase and therefore present opportunities for name collision.
Module resolution rules are esoteric and inefficient.

The proposed solution to these problems does a major refactor of default Ember app structure. Replacing app at the top level is a new directory called src which can contain several subdirectories (data, init, ui, utils, and services). Here's an example of what this could look like in a blogging application, as shown in the RFC:

  
  src
  data
    models
      author.js
      comment
        adapter.js
        model.js
        serializer.js
      post
        adapter.js
        model.js
        serializer.js
    transforms
      date.js
  init
    initializers
      i18n.js
    instance-initializers
      auth.js
  services
    auth.js
  ui
    components
      capitalize.js
      date-picker
        component.js
        template.hbs
      list-paginator
        component.js
        template.hbs
        paginator-control
          component.js
          template.hbs
    partials
      footer.hbs
    routes
      application
        template.hbs
      index
        template.hbs
        route.js
        controller.js
      posts
        -components
          capitalize.js
          titleize.js
          -utils
            strings.js
        post
          -components
            post-viewer
              component.js
              template.hbs
          edit
            -components
              post-editor
                post-editor-button
                  component.js
                  template.hbs
                calculate-post-title.js
                component.js
                template.hbs
            route.js
            template.hbs
          route.js
          template.hbs
        route.js
        template.hbs
    styles
      app.scss
    index.html
  utils
    md5.js
  main.js
  router.js

There are a couple of examples of this in action; namely the Ghost Admin and Travis Client. Rob Jackson has also done a fantastic job in releasing a tool that allows us to migrate our apps over to this new structure.

The RFC goes into a great amount of detail regarding other changes that will need to take place, such as renaming and reorganizing modules, and a refactor of the Ember Resolver. You can read the whole thing here.

Testing Unification

The goal of this RFC is to unify the concepts amongst the various types of test (acceptance, integration, and unit) and provide a single common structure to tests.

Look, most of us don't really love writing tests. It's okay to admit it. But as Rob Jackson explains in his RFC, Ember's testing story is coming together quite nicely, and it's never been easier to write comprehensive tests across all the various pieces of your app (routes, components, templates, etc). One of the best aspects of Ember being a "full featured" framework is that it comes packaged with all the libraries and tools you'd need to write great tests, with as little friction as possible.

The only persisting problem is that these tests look and function quite different from one another. Specifically, they handle things like asynchronous requests differently and use unique sets of helpers. This RFC seeks to "unify" the three types of tests - acceptance, integration, and unit - by introducing new syntax to handle asynchronous test actions, and establishing a set of test helpers that would be shared across the three types of tests.

Like the Module Unification RFC, this one goes into a great amount of detail that eclipses the scope of an ELI5. I highly recommend checking it out the full spec if you're interested in the future of testing.

Routable Components

Eliminates Controllers.

Ah, yes. The Holy Grail of RFCs. The future of Ember. The promised land.

In all seriousness, routable components are a pretty big deal, and received an appropriately large reaction when first presented at EmberConf 2015 by Tom Dale & Yehuda Katz. It's been a long time since then, and if you've been following along, you might need a little refresher on how they are intended to work.

As the description above concisely states, routable components essentially mean the death and deprecation of controllers. This is a good thing. For many months now, controllers have been a key point of confusion for new developers, and stick out as a remnant of pre-2.0 Ember. One of the biggest complaints about the framework in the early years was that the architectural pattern was far too complicated ("MVC? MVVM? What's the difference between a view and a controller?"). Ember continuing to simplify and mature these patterns is great news.

Routable components hope to replace controllers by absorbing the few functional responsibilities that they still have, such as query parameters and setting a route's model on the template or top-level component. Discussing the implementation for these changes, however, is a tricky subject due to the length of time passed since the concept of routable components was first introduced. Original proposals included removing older model hooks (such as beforeModel and afterModel) and introducing a new, automatically invoked hook called "attributes", that would allow a route to specify the positional and query parameters to be passed into a rendered component.

Phoenix Channels vs Rails Action Cable

2016-08-09 00:00:00

At DockYard, we transitioned our backend development from Ruby and Rails to Elixir and Phoenix once it became clear that Phoenix better served our clients needs to take on the modern web. As we've seen, Phoenix is Not Rails, but we borrow some of their great ideas. We were also delighted to give back in the other direction when Rails announced that Rails 5.0 would be shipping with Action Cable â a feature that takes inspiration from Phoenix Channels.

Now that Rails 5.0 has been released, we have clients with existing Rails stacks asking if they should use Action Cable for their real-time features, or jump to Phoenix for more reliable and scalable applications. When planning architecture decisions, in any language or framework, you should always take measurements to prove out your assumptions and needs. To measure how Phoenix channels and Action Cable handle typical application work-flows, we created a chat application in both frameworks and stressed each through varying levels of workloads.

How the tests were designed

For our measurements, we used the tsung benchmarking client to open WebSocket connections to each application. We added XML configuration to send specific Phoenix and Rails protocol messages to open channels on the established connection and publish messages. For hardware, we used two Digital Ocean 16GB, 8-core instances for the client and server.

The work-flows for each tsung client connection were as follows:

open a WebSocket connection to the server
create a single channel subscription on the connection, to a chat room chosen at random
Periodically send a message to the chat room, randomly once every 10s-60s to simulate messaging across members in the room

On the server, the channel code for Rails and Phoenix is quite simple:

  
  defmodule Chat.RoomChannel do
  use Chat.Web, :channel

  def join("room:" <> _id, _params, socket) do
    {:ok, socket}
  end

  def handle_in("publish_msg", %{"body" => body, "user" => user}, socket) do
    broadcast!(socket, "new_message", %{body: body, user: user})
    {:reply, :ok, socket}
  end
end

  
  class RoomsChannel < ApplicationCable::Channel
  def subscribed
    @topic = "rooms:#{rand(1..8)}"
    stream_from @topic
  end

  def publish_msg(data)
    ActionCable.server.broadcast(@topic,
      body: data["body"],
      username: data["username"],
      started: data["started"]
    )
  end
end

After establishing N numbers of rooms, with varying numbers of users per room, we measured each application's responsiveness. We tested performance by joining a random room from the browser and timing the broadcasts from our local browser to all members in the room. As we increased the numbers of users per room, we measured the change in broadcast latency. We recorded short clips of each application's behavior under different loads.

This simulates a "chat app", but the work-flow applies equally to a variety of applications; real-time updates to visitors reading articles, streaming feeds, collaborative editors, and so on. As we evaluate the results, we'll explore how the numbers relate to different kinds of applications.

Rails Memory Leaks

After creating the Rails chat application, setting up redis, and deploying the application to our instance, we immediately observed a memory leak in the application that was visible just by refreshing a browser tab and watching the memory grow; to never be freed. The following recording shows this in action (sped up 10x):

We searched recently reported bugs around this area, and found an issue related to Action Cable failing to call socket.close when cleaning up connections. This patch has been applied to the 5-0-stable branch, so we updated the app to the unreleased branch and re-ran the tests. The memory leak persisted.

We haven't yet isolated the source of the leak, but given the simplicity of the channel code, it must be within the Action Cable stack. This leak is particularly concerning since Rails 5.0 has been released for some time now and the 5-0-stable branch itself has unreleased memory leak patches going back greater than 30 days.

Scalability

We set the memory leak issue aside and proceeded with our tests for the following scenarios:

Max numbers of rooms supported by a single server, with 50 users per room
Max numbers of rooms supported by a single server, with 200 users per room

Note: For Phoenix, for every scenario we maxed the client server's ability to open more WebSocket connections, giving us 55,000 users to simulate for our tests. Browser -> Server latency should also be considered when evaluating broadcast latency in these tests.

50 users per room

Rails: 50 rooms, 2500 users:

Responsiveness was speedy at 50 rooms, so we upped the room count to 75, giving us 3750 users.

Rails: 75 rooms, 3750 users:

Here, we can see Action Cable falling behind on availability when broadcasting, with messages taking an average of 8s to be broadcast to all 50 users for the given room. For most applications, this level of latency is not acceptable, so the level of performance for maxinum rooms on this server would be somewhere between 50 and 75 rooms, given 50 users per room.

Phoenix: 1100 rooms, 55,000 users (maxed 55,000 client connections)

We can see that Phoenix responds on average in 0.25s, and only is maxed at 1100 rooms because of the 55,000 client limit on the tsung box.

Making sense of the results, 50 users per room

These results show that if you are building an application for small to medium sized businesses, if 75 companies visit the app at the same time, their notifications will be delayed. Given the severe degradation in performance from 50 to 75 rooms, it may also be hard to pinpoint your server density when planning for load.

For load planning, horizontal scalability will be required with 50-75 companies per server, but the reliance on redis should be considered as a central bottleneck. Horizontal scalability was the obvious choice for Ruby when it came to stateless HTTP requests, but we can see why vertical scalability becomes increasingly important for stateful connections. If you require dozens or hundreds of servers, Action Cable will still rely on a central redis bottleneck for PubSub.

200 users per room

Rails: 8 rooms, 1600 users:

We can see Action Cable starts off with acceptable latency, but begins to quickly fall behind as broadcast latency grows with each message. Broadcast latency grows longer than 10s. Next, we upped the room count by 1, to see where the limit was.

Rails: 9 rooms, 1800 users before availability was compromised when broadcasting.

At 200 users per room, Action Cable is unable to maintain the broadcast load and supported just 9 rooms before we experienced messages stop arriving or subscriptions failing to establish. At these levels, the only consistent performance we could get for 200 users per room, was limiting the server to 7 rooms, or 1400 users.

Phoenix: 275 rooms, 55,000 users (maxed 55,000 client connections)

We can see that Phoenix responds on average in 0.24s, and only is maxed at 275 rooms because of the 55,000 client limit on the tsung box. Additionally, it's important to note that Phoenix maintains the same responsiveness when broadcasting for both the 50 and 200 users per room tests.

Making sense of the results, 200 users per room

You may be thinking, "but my application isn't a chat app, and only needs simple page updates". These tests apply equally to many scenarios. Imagine you have an information system where you want to publish periodic updates to pages. This could be for a news site where visitors see new comments, or a booking site where visitors see "20 other people are currently viewing this hotel".

This tests shows that if your app receives a sudden spike in visitors and more than 7 articles have 200 or more readers, the server won't be able to keep up with the notification demand for both the popular articles, as well as the low traffic ones.

For a booking site, imagine 7 hotels across the country release a discount rate and customers jump online for the deal. Suddenly, you need to spin up extra servers to maintain booking notifications, and the severity of the delays becomes worse if critical functionality of your application relies on these notifications.

Conclusions

If memory leaks can be ruled out or addressed, the sweet-spot for Action Cable today is small workloads with few subscribers on any given topic. Going beyond this means engineering efforts and resources must be spent on managing multiple nodes and optimizing code out of channels. Higher workloads with broadcasts to more than a few dozen subscribers risks availability. With Phoenix, we've shown that channels performance remains consistent as notification demand increases, which is essential for handling traffic spikes and avoiding overload.

When I started my own real-time Rails features with Sync several years ago, memory leaks and consistent performance were my main fears that drove me to look elsewhere, find Elixir, and create Phoenix. The rails-core team has done a great job putting a real-time story in place, but wrangling Ruby's lack of concurrency features will continue to be a challenge.

The source code and instructions for running these tests on your own hardware can be found here.

Understanding the & (capture operator) in Elixir

2016-08-05 00:00:00

Understanding the & (capture operator) in Elixir

& is the capture operator in Elixir, it is used to capture and create anonymous functions.

Anonymous functions and arity

Before going into details about the capture operator, let's get familiar with anonymous functions and arity first.

Given the following example:

  
  add_one = fn x -> x + 1 end

we defined a function, but it isn't bound to a global name, so it is an anonymous functions or a lambda.

This function takes one argument, so its arity is 1.

How to use `&`

capture function

Let's first talk about capturing function. Capture means & can turn a function into an anonymous functions which can be passed as arguments to other function or be bound to a variable.

& can capture two types of functions:

function with given name and arity from a module

The notation is: &(module_name.function_name/arity), e.g.

  
  speak = &(IO.puts/1)
speak.("hello")  # hello

We capture puts function from IO module and bind it with a local name speak.

local function

In the following example, put_in_columns and put_in_one_row are defined in the same module, so we can capture put_in_one_row by &put_in_one_row/1, notice that we don't include the module name here.

  
  defmodule Issues.TableFormatter do
  def put_in_columns(data_by_columns, format) do
     Enum.each(data_by_columns, &put_in_one_row/1)
  end

  def put_in_one_row(fields) do
     # Do some things...
  end
end

create anonymous functions

The capture operator can also be used to create anonymous functions, for example:

  
  add_one = &(&1 + 1)
add_one.(1) # 2

is the same with:

  
  add_one = fn x -> x + 1 end
add_one.(1) # 2

You might notice that &1 is used in the above example. That's called a value placeholder, and it identifies the nth argument of the function

In addition, as {} and [] are also operators in Elixir, & can work with them too.

  
  return_list = &[&1, &2]
return_list.(1, 2) # [1, 2]

return_tuple = &{&1, &2}
return_tuple.(1, 2) # {1, 2}

It's hard to comprehend at first, we just need to think about it from another perpective:

Measuring the unknown

2016-08-05 00:00:00

As a designer, I often get the opportunity to participate in starting and planning projects. Some projects have many unknowns, and we follow a Discovery process before proposing a blueprint for what to build, and why. And sometimes, we need to understand the scale of a challenge without following this familiar discovery process.

Now, please measure the unknown

At first, it may seem impossible: how can I âsize upâ a solution to a problem without knowing all the variables, and the potential ranges for each one? How can I estimate when the thing I am measuring feels like a black box?

If you step back from the problem, however, you may find that you know more than you think. This situation reminds me of an example a Mathematics professor gave me to explain how they work with abstract concepts.

Start by measuring the infinity

Letâs say youâre trying to measure an infinite thing. Imagine if you were to remove two walls and the ceiling from the room youâre sitting in. Take in all the space, stretching out into the cosmos â in front, to your left and above you (but not the other four quadrants.) It is, indeed, an infinite amount of space that you couldnât measure in familiar ways - but what you do know is that itâs smaller than the other three quarters you did not include.

By itself, a thing can feel immeasurable, but in the context of other like things, you can easily size it up.

Decide what kind of infinity it is

Your problem might still feel like a black box. Thatâs fine. Shake the box a bit - does it rattle? How does it behave? What youâre trying to get at is the structure, rather than the size or weight.

Structure corresponds to design intent, versus the weight and size deals with implementation. The intent of a bridge is fundamentally different from the intent of a house. They are meant to behave differently, even though the size, materials and construction techniques could be similar. If you can reliably say that youâre building a bridge, and itâs smaller than any of the previous three bridges youâve seen - you can have a good amount of certainty that the project will fall between X and Y size.

Even more importantly, by calling the project a bridge, youâve now reduced the number of confusing variables youâre working with. You and your team can how have a conversation around how long, and how strong the bridge needs to be, but youâre not worrying about whether it needs to fly, or have a patio in the front.

No one has all the answers

As professionals, we often feel like we should have all the answers. But no one can have them all. True professionalism means being honest about what you donât know while doing our homework to narrow down the infinity to something we can address intelligently.

Scientists do this all the time. We measure far away planets by looking at very scarce data and comparing it to what we know. As we learn more, whole theories get rewritten and replaced. But if we donât start with the theory we have, and make a good attempt at solving a problem, we will never learn more.

The opposite of knowing isnât not-knowing. Itâs not trying. We must share openly what we donât know and, in case of a design discovery, document assumptions and caveats. If weâre sizing up an unknown bridge, be vocal about your assumption that the bridge posts are not underwater (thatâd triple their cost and complexity) or resting on a volcano (good luck). Your black box may contain an infinity, but by describing it and naming it youâve gone a long way towards answering, âhow large?â

We're looking for an HTML/CSS Specialist!

2016-08-04 00:00:00

If you have a passion for HTML and CSS we want you at DockYard!

Weâre a premiere design-first web consultancy based in Boston and we are looking for DockYarders to join our growing team.

Our workflow involves three steps. Designers hand off mockups to the HTML/CSS specialists who then give styled templates to engineers. Traditionally writing HTML and CSS was the responsibility of designers or engineers but with the growth of HTML5 and CSS you need a role within the team solely focused on HTML and CSS.

As an HTML & CSS specialist at DockYard you will be in a unique position where you will work closely and engage in great communication with both the Design team and Engineering team to help facilitate the handoff between visual design and app implementation. Additionally to that, you'll be challenged with helping drive the creation of web applications and solving interesting problems regarding accessibility, browser compatibility, standards compliance, and responsive design.

Send us a note - we are looking forward to hearing from you!

We're looking for a designer!

2016-08-03 00:00:00

Weâve got several exciting projects lined up, and weâre looking to grow the design team on a per-project basis.

Weâre looking for a designer with strength in both UX and visual design. Design research experience would be a plus.

For this project, you would be paired up with a DockYard designer to help lead a 4-6 week product discovery. You would get the opportunity to see a product through from conception to finished visual designs, user testing, and even collaboration with Engineers. Our sprint-based, focused approach to working, in close collaboration with our team and the client, is ideal for achieving deep, high quality work.

This contract engagement would be ideal for a mid- to senior designer looking to expand their toolkit, and collaborate closely with a premier web application consultancy. This opportunity could lead to a full time position in the future, based on a 32-hour workweek.

This contract requires you to be in-person at our office in Boston for the duration.

Send us a note - weâre looking forward to hearing from you!

Patterns from Ember Composable Helpers

2016-07-27 00:00:00

Co-creator of Ember Composable Helpers Lauren Tan recently wrote about the what, why and how of Ember Composable Helpers. Now I'd like to talk about one of the patterns we have used to make Ember Composable Helpers work.

The fundament of the array helpers is the get helper

Most of the array helpers are built upon the implementation of the get helper. Let's take a closer look at a simplified version of the get helper:

  
  import Ember from 'ember';

const { 
  Helper, 
  get,
  set,
  observer,
  defineProperty,
  computed: { oneWay }
} = Ember;

export default Helper.extend({
  compute([targetObject, propertyPath]) {
    set(this, 'targetObject', targetObject);
    set(this, 'propertyPath', propertyPath);

    return get(this, 'content');
  },

  propertyPathDidChange: observer('propertyPath', function() {
    let propertyPath = get(this, 'propertyPath');
    defineProperty(this, 'content', oneWay(`targetObject.${propertyPath}`));
  }),

  contentDidChange: observer('content', function() {
    this.recompute();
  })
});

Let's start with the compute function on lines 13-18. It expects a targetObject and propertyPath param, which stands for the object you want to get the given property from. These params are set as properties on the helper itself each time compute is called. Finally the compute function returns the content property. This will be the result of getting the propertyPath from the targetObject.

Why not just return the given property from the target object?

Well, writing the helper as follows would have the downside that it will only recompute whenever the targetObject changes or when the propertyPath changes, but not when the desired property on the target object changes.

  
  import Ember from 'ember';

const { Helper: { helper }, get } = Ember;

export function getHelper([targetObject, propertyPath]) {
  return get(targetObject, propertyPath);
}

export default helper(getHelper);

Solution: Observers

Yes you heard it right, observers are a perfect candidate to solve the problem that our helper won't recompute when we want it to. So let's take a look at the propertyPathDidChange and contentDidChange observers.

  
  propertyPathDidChange: observer('propertyPath', function() {
  let propertyPath = get(this, 'propertyPath');
  defineProperty(this, 'content', oneWay(`targetObject.${propertyPath}`));
})

Let me explain what happens with this observer. On the first line we define an observer that will be triggered every time propertyPath gets updated. In the function body we get the value of propertyPath and use it to define a new computed property at runtime. We do that using defineProperty. This means that every time the propertyPath's value changes, the content computed property gets redefined to point towards the correct path on the target object.

  
  contentDidChange: observer('content', function() {
  this.recompute();
})

Then there is the contentDidChange observer. This one watches for changes of the content property, which we define with the propertyPathDidChange observer. The contentDidChange observer calls recompute, which recomputes the end value of the helper.

Putting it all together to create the map-by helper

Now that we know how to build a helper that can recompute when a property that we only know of at runtime changes, it is very simple to create other similar helpers upon this pattern. I'll leave you with the map-by helper, which doesn't look that different from the get helper I've shown you.

  
  import Ember from 'ember';

const { 
  Helper, 
  get,
  set,
  isEmpty,
  observer,
  defineProperty,
  computed: { mapBy }
} = Ember;

export default Helper.extend({
  compute([byPath, array]) {
    set(this, 'array', array);
    set(this, 'byPath', byPath);

    return get(this, 'content');
  },

  byPathDidChange: observer('byPath', function() {
    let byPath = get(this, 'byPath');

    if (isEmpty(byPath)) {
      defineProperty(this, 'content', []);
      return;
    }

    defineProperty(this, 'content', mapBy('array', byPath));
  }),

  contentDidChange: observer('content', function() {
    this.recompute();
  })
});

How to use git bisect by example

2016-07-26 00:00:00

I'm writing this tutorial because I ran into a problem, while working on an addon, with Ember.js the other day. The problem was that the test suite did not pass anymore on Ember.js' canary build channel, while it used to pass before. After debugging the problem I wanted to find out which commit in Ember.js did break the tests. Thanks to Robert Jackson, who pointed me to a GitHub comment, I've been able to use git bisect to find the commit that introduced the issue and report it.

What bisect does

git bisect uses the bisection method to find the first commit that introduced the bug you are looking for. You will have to tell the bisect command one commit you are sure contains the bug and one commit that you are sure of that it does not contain the bug. Bisect will then start searching, asking you if a given commit it proposes is good or bad, until it has found the commit that introduces your bug.

Setting up before the bisect

To find out what commit has introduced a bug in the Ember.js repository, you need to clone a different repository, that is components/ember, which contains the Bower builds of Ember.js. You can link this repo to your app directly and then use git bisect to find the first build that contains the bug. You can then cross-reference the build with the real Ember.js repo to find the actual commit that introduced the bug.

To clone and link the components/ember repository:

  
  git clone git@github.com:components/ember.git components-ember -b canary
cd components-ember
bower link

Now you need to do a little bit of setup in the app that you are working with. You will need to modify your bower.json to use components/ember#canary for Ember.js and then link it to the local repository you just cloned. I recommend you do this in a seperate terminal window/tab, as you will have to go back and forth between this and the other a few times.

Example bower.json after the change:

  
  {
  "name": "my-app",
  "dependencies": {
    "ember": "components/ember#canary"
  },
  "resolutions": {
    "ember": "canary"
  }
}

After updating your bower.json remove the installed Ember Bower component and link it to the local one.

  
  rm -rf bower_components/ember
bower link ember

Now you're ready to start running git bisect.

Finding the bad commit with bisect

From the components-ember folder start with running the git bisect start command, this will start your bisect session. Then run git bisect bad to tell the bisect session that the current commit is a bad commit. The next step is a little bit harder, you will need to find a commit that you are sure of to be good. One trick is to go back about six weeks (about one Ember version) in the history and pick a commit, this commit will have a high chance of being good. One warning though: going back too far might cause you to find a bug that is irrelevant to your case. When you have found such a commit, run git bisect good <sha-of-good-commit>. The response will look something like the following:

  
  Bisecting: 117 revisions left to test after this (roughly 7 steps)
[4e1224de1687a86dc83936e880104b6b1a48bbe2] Ember Bower Auto build for https://github.com/emberjs/ember.js/commits/d2b56a290a45b23a792575dfa6e3af37cf58bc79.

This means that there are 117 commits left that can contain the commit you are looking for, and that it will take about 7 more steps to find it.

You should now notice that bisect has moved the components-ember repository to a different commit somewhere between your initial good and bad commits. In this case it is 4e1224de1687a86dc83936e880104b6b1a48bbe2 This is the first commit bisect has selected to test. It will wait for you to report if this commit is good or bad.

Now go back to your app's folder and run your tests (ember test for example). If all tests pass the suggested commit must be a good commit, run git bisect good in the components-ember folder to tell the bisect process that this commit is a good commit. If the tests fail, then run git bisect bad to tell the bisect process that this commit is a bad one.

After having specified if the commit is either good or bad bisect will respond with a similar message:

  
  Bisecting: 58 revisions left to test after this (roughly 6 steps)
[73f02564972bbd14a719f707af019d94c822939c] Ember Bower Auto build for https://github.com/emberjs/ember.js/commits/1be0354068d933065ac542f49d42d73409366a47.

With this step it has eliminated 59 commits, and there are only 58 commits left that can contain the commit you are looking for. It has also moved the components-ember repository to the next commit that it needs you to test if it's good or bad.

Run your app's tests again and either run git bisect good or git bisect bad based on the results of the tests.

Keep repeating this process until it reports the bad commit:

  
  9f6b98391523c4be437e1f6cd1a5956e69ecc0a9 is the first bad commit
commit 9f6b98391523c4be437e1f6cd1a5956e69ecc0a9
Author: Tomster <tomster@emberjs.com>
Date:   Sat Jun 11 00:03:22 2016 +0000

    Ember Bower Auto build for https://github.com/emberjs/ember.js/commits/b44f9dad912a73668dda142c34a6858283003403.

Congratulations! You have found the bad commit that introduced the bug that you were looking for. In this case it's 9f6b98391523c4be437e1f6cd1a5956e69ecc0a9, and luckily the commit message includes the commit the build is from, so you can go to the GitHub url from the commit message and see the original commit.

What if I wrongly report a commit as bad or good?

Unfortunately, bisect has no undo command, so you will have to start from the top again. To do this first run git bisect reset, this will end your bisect session. Now you can start over by running git bisect start and then marking a good and bad commit, which then will start the iterative process of marking commits selected by bisect good or bad again.

Can I automate this a little bit more?

Yes you can! Bisect has the command git bisect run, which will run a command for you on each iteration. If the command succeeds it will mark the commit as good, if the command fails it will mark the commit as bad.

Let's take a look at how to do this with our example.

To reliably run the tests each iteration I added the following bash script to the components-ember folder, I called it ember-bisect-test.sh:

  
  #!/bin/sh

cd <path/to/your/project/folder>
rm -rf bower_components/ember
bower link ember
ember test

Mark the file as executable:

  
  chmod +x ember-bisect-test.sh

And now we can let bisect run your script on each iteration:

  
  git bisect run ./ember-bisect-test.sh

What have we learned?

You have now learned:

The basics of how git bisect works.
How to use git bisect with the Ember.js canary channel to track down commits that introduce regressions.
How to restart the process when you mess it up.
How to automate git bisect with a script.

Productive debugging

2016-07-26 00:00:00

If you attended Wicked Good Ember this past June, it quickly became apparent that it was a Test Driven Conference - three testing-related talks happened to be grouped together at the start of the conference. It's clear that Ember developers care about testing. In fact, there is an open RFC to unify the way Ember does testing. I highly recommend reading it! Currently, there are three different ways to test; one for each of the different types of tests: unit, integration, and acceptance. However, while the unification becomes reality, we must keep testing as usual, and I'd like to go over some quick tips for debugging in the different test environments!

pauseTest();

This first function is acceptance test specific, but according to the RFC, it will eventually become available to use in all types of tests. When writing tests, it's helpful to be able to inspect the state of the DOM. Inserting a call to pauseTest() inside an acceptance test will pause the test suite at the point that it sees the function call. This allows for developer interaction with the current state of the application. Internally, pauseTest() returns a promise that will never resolve.

  
  test('I can submit the contact form', function(/*assert*/) {
  visit('/contact-form');
  return pauseTest();

  // failing interaction
  click('button:contains("Submit")');
});

After running the above test on the browser, the test suite would pause once it reaches L3. The application would be viewable exactly as it appears before the click takes place.

Example use case:

I want to click the "Submit" button but my test is not finding that element, therefore, it's failing. With return pauseTest(), I'm able to see that I'm not actually in the expected /contact-form route, but that I'm being redirected to the /login route. Now I can fix my test by logging in before visiting /contact-form.

assert.async();

This function is a favorite of mine, and I remember the excited when I first learned about it a while ago (thanks Marten!). The use of assert.async() is available to use in both acceptance and integration tests, but it's currently the only way to pause an integration test Calling assert.async() is similar to pauseTest(); you can inspect the state of the DOM and play around with it while the test is paused. It's a great tool for integration testing because much of the time, you're testing that certain content/element appears on the page as a result of a user interaction. I find it particularly useful to quickly find class names, data-auto-ids, etc, instead of going back to the templates where they are defined.

This async() method comes for free with Qunit, which is Ember's built-in testing framework.

  
  test('Clicking "Add contact" displays new contact form', function(assert) {
  this.render(hbs`{{contacts users=users}}`);
  click('button:contains("Add contact")');

  assert.async();

  // failing assertion
  let form = this.$('[data-auto-id="new-contact"]');
  assert.equal(form.length, 1, 'New contact form is displayed');
});

Like with the pauseTest() example, once the test runner reaches L5 above, the test suite will pause and the current state of the DOM can be viewed.

Example use case:

I want to make sure that my new contact form is displayed on the page. I know that the functionality is working, but my test is still failing. I can add a call to assert.async() to check out the DOM. Turns out I was using the wrong data-auto-id.

debugger;

No debugging function left behind. There's no need to explain what debugger; does, but when you need to debug some functionality without caring about what the UI looks like, then you're good to place a debugger; call inside any test.

Gotta Catch 'em All!

2016-07-20 00:00:00

If you haven't yet heard of Pokemon GO, you might be living under a rock. Or under an Onyx. Pokemon GO was released on July 7, 2016 in the United States and it immediately became viral. It's a mobile application that makes use of the GPS and camera to bring the user an Augmented Reality experience by allowing them to catch Pokemon in a real-world environment. The game encourages its users to go outside and become the Pokemon Masters they always dreamed of being, or now dream of being. Talk about nostalgia. Even if one didn't grow up with the franchise, the newly-released game is still revolutionary due to its immersive nature and social aspect. Like much of the world, most DockYarders have picked up the game and some would like to share their thoughts and experiences with you!

Maria M: Pokemon GO UX Lessons

I took four days to experiment casually with the game - and looked over the shoulder of a few others with a far more serious approach to it. Here's what I learned about UX design.

11:30pm, near downtown Boston

I'm an observer right now, not actively playing. Pleasant summer night in Boston and a whole lot of people are walking circles around the body of water near the Christian Science Center - a complex made up of a large cathedral and an even larger administrative building. Normally, the area is pretty empty at this hour. Not everyone is staring directly down at their phone screen, but I can pretty much tell who is playing the game and who is here for other reasons. The players are all in their 20s, and come from a similar demographic, about half white and half Asian. (This does not represent what I have seen in Boston on average, or even in the Boston tech and design scene.)

Population

Once I got adjusted to the sight of the chill looking crowds gathering in spaces that are normally emptier, I realize what looks âoffâ about the situation. Itâs the feeling I might get on a college campus tour, when everyoneâs around my age. I am guessing the earliest adopters of Pokemon GO very clearly the people of more access to games and the Internet and technology in general. I spot just one family with a stroller - and they stand out. I realize that just being able to gather here unencumbered by 6am school drop-offs, caring for a family, or working several jobs represents privilege and access to leisure that not everyone has.

I think this reveals that we often end up designing for folks just like us. Early adopters of the Pokemon GO are probably similar to the first users who sign up for many web apps, and even though we assume we're making something that's good for the âgeneral publicâ weâre often actually catering only to ourselves.

The space

Obviously one of the reasons that the game is so addicting is that it uses 3-D space to play the game. You physically have to be close to an object to claimant in the game and geolocation is playing a major role in making that happen. The game is designed for walking on foot but sometimes you can cheat a little bit and for example the on the bike or claim some of the objects from a public bus. But in either case I found that I've learned remarkably well after just a few attempts exactly how close I have to be physically to a marks location in order to claim it. I think this is especially interesting because before this I had a general sense of how accurate things like GPS and Wi-Fi are to locate me in 3-D space but now I have a physical sense in my body exactly how far I need to walk to or from the corner to be within reach of a specific object on the 3-D map. If nothing else, the game will vastly improve our understanding of the accuracy of GPS and Wi-Fi location tracking.

When a digital experience works, it changes the world

The third takeaway for me is a really hopeful one. Obviously I'm not going to be the only one who says that his game is changing the world. People are not just sitting or walking staring at their phones by themselves. They are chatting with other people, yelling out when when they successfully capture rare PokÃ©mon they really wanted and in general or just smiling at each other. I assume these are the same people who would normally sit at home by themselves staring at the personal screen and not talking to anyone. And even though we fight around the same damn pool of water near the Christian science center about seven times already, I'm getting a fun romantic evening walk with my s/o, when normally at this time I would have been staring blankly at my own screen.

He just informed me that it is midnight and we should probably leave so we could get home in time to get a little bit asleep before starting work tomorrow. But overall it was a fairly nice night and he seems happy as well.

But more importantly, the experience people are having in this park and in many places in the world right now with this game is not virtual â it's real. And it gives me hope because when working for a long time on complex products it's easy to get discouraged. When you're tired, itâs easy to slip into thinking that whatever you're making will not make a difference. This game offers us a reminder for me of real change in the physical world that can happen when an interaction is built just right.

"Broken tech culture is seeing the success of PokÃ©mon Go & attributing it to AR instead of a huge 25-year-old global cultural phenomenon."

Cory T: Expert user point of view

With walking everywhere and following PokemonGoHub on Twitter, I have been appointed DockYard Pokemon GO expert! This game has been on my radar ever since one of the first teasers surfaced online and the nostalgia hits you like a punch from Rocky Balboa.

Ten minutes after Pokemon GO was available in the Play Store (thanks Twitter) I had the game downloaded and caught my first and favorite Pokemon of all time, Squirtle. After seeing Squirtle in my Pokedex I legitimately felt like I was back in 4th-6th grade collecting Pokemon cards in my 3-ringed binder. Crazy thing is I now I have my own freaking Pokedex on my phone with Pokemon I caught in the real world!

Nostalgia aside, I might have a different opinion on the UX of the game.

I like it.

For example, Pokemon GO doesnât tell you to spin the ball in order to throw curve balls (this makes it easy to catch rare Pokemon). The mechanics on how to fight a gym is never explained. How to pick what your Eevee will evolve into is not obvious.

Does this game tell you how to do anything? No. But, I actually like figuring out how to play this game - socializing with other people about new tricks they have found has been great.

What I want to see

Web app that lets me manage my Pokemon online
Pokemon trading (coming very soon according to Pokemon GO)
Have the ability to select multiple Pokemon and transfer them to Professor Ashe
- Currently 3 clicks to transfer a Pokemon
Currently the game is a grind to find the best version of a specific Pokemon species, I would rather invest and care for one that I catch and train the Pokemon new attacks and upgrade its statistics. Will make them more personable and pet-like

Pro tip: If you want to actually know what your Eevee will evolve into compared to the random selection, give Eevee the desired nickname. This should work every time unless there is a bug/glitch. The trainers of Vaporeon, Flareon and Jolteon in episode 40 of the TV show are the key to this trick:

Pyro = Flareon
Sparky = Jolteon
Rainer = Vaporeon

Patrick B: Resister Turned Lover

Generally when an audience as large as...well...seemingly the entire world...takes notice of an application, game or service, I start my relationship with said application, game or service with resistance. Not because I donât want to involve myself but because I want to witness the reactions of others. Iâm not judging people using it. Iâm observing people using it. Eventually I give in (usually after patch 1 or 2) and then compile my thoughts and assemble my like or dislike for the application, game or service.

This process has never been harder than with Pokemon GO. Perhaps itâs because no application for a mobile device has become this popular this quickly. Perhaps itâs because I love(d) Pokemon and donât want to tarnish my grand memories of the franchise. Perhaps itâs because...it wouldnât install the first few attempts.

I resisted hard at the beginning. One week later, Iâm level 13 and furiously collecting as many Pokemon as I can. I love it as much as I hoped I would. I love it as a designer. I love it as a casual fan of Pokemon. I love it as a heavy gamer. My mother loves it. My brother loves it. My cousin loves it. None of them design, game or were ever engulfed in the world of Pokemon.

At the very least, you should try Pokemon GO. Perhaps youâll love it too. Here are four reasons why in one week you just might find yourself taking notice to the game everyoneâs talking about:

Nostalgia

If you were at all in tune with video games through the 90s and 00s, youâre inevitably familiar with at least the name âPokemon.â However if youâre familiar with the name, you likely fell hard in love to some degree with the Pokemon empire (whether youâd like to admit it or not). If you traded, collected or sold the cards youâre very likely to enjoy this game. If you were consumed by the colored Gameboy games youâre very likely to enjoy this game. If you dreamt of the Snap or Stadium realms being real environments for you to roam and interact with beyond the 64 joystick youâre very likely to enjoy this game. If youâve lived by Nintendo platforms in general youâre very likely to enjoy this game. What once was a game then became an empire. That empire is now an entire world.

We Love Collecting

While it remains a strange compulsion, itâs no secret that people like to collect things. Cars, video games, sports memorabilia, sneakers, art, you name it and there are people who focus on collecting as much of it as they can. Thereâs an addictive pleasure to finding something that may have been lost or perhaps evaded us for some time. Dating back to the Victorians, the act of collecting items has been a consistent habit driven by both necessity and desire. The entire Pokemon franchise is heavily built on this addictive action. Itâs why we see their playing cards sold for thousands of dollars. Itâs why an entire video game can be built around simply discovering and photographing objects. And itâs partially why people are taking time to feverishly compile libraries of Pokemon in their Pokedex sometimes entirely omitting from their play the many other aspects of the game. The idea of collection is built directly into their brand. You just âgotta catch them all!â Itâs a challenge we secretly love.

Augmented Reality

While VR (virtual reality) is undoubtedly all the rage, thereâs something to be said about AR (augmented reality). Letâs look at it in the context of Pokemon GO: It can be created without extra hardware, itâs portable in that itâs reliant on a mobile device, it doesnât cost much, and it fuses fictional subjects with the reality of your environment â an actual, unprogrammed, environment. VR, while amazing in its own right for so many reasons, relies on those things AR doesnât. This isnât to say Pokemon GO is popular because of its emphasis on AR, but it proves that an AR driven experience can still be immensely successful. Before we strap on our head gear, what opportunities can this success story shed light on?

UX Exposure

Itâs not a secret that the Pokemon GO application has kinks. On an average day, I have to close and restart the application several times do to it freezing or completely crashing. Do I care? No because Iâm addicted. When I installed Pokemon GO it failed to install, and then failed to create my account two times. In fact I uninstalled it for a day I was so frustrated. But here I am a week later using it. As a visual designer in a UX word, this exposure to conflicts and failures has actually caught my attention, mostly because Iâve forced myself to experience them knowing the payoff will be worth it. Itâs allowed me to take notice of how the visuals handle failures on the server side. Itâs allowed me to take notice of my behaviors when failures do happen. Do I wait to close the app? How long do I wait? When do I notice itâs not working correctly? How is this represented by the field of view? Is the AR functionality instigating it? Because Iâve experienced the pleasure of playing, and am willing to suffer to an extent, Iâve allowed myself to be content with its failures so much so that itâs begun to provide me insight into aspects of the actual application I may not have given the time to. Maybe itâll result in a useless collection of observations. But maybe itâll result in my paying attention to these aspects more so in the next project Iâm involved in. Nevertheless, itâs a remarkable feat to be so successful yet still provide so many instances of frustration unrelated to the game itself.

DockYard Expands To San Diego

2016-07-05 00:00:00

For almost two years I've been talking a big game inside DockYard about opening a San Diego office. The need for this became more apparent after the winter of early 2015 in Boston. Try recruiting anyone to move to Boston after hearing about nearly 20 ft of snow being dumped on the city. So I figured we'll open an office in the nicest place in America.

Having a San Diego office gives us a West Coast presence. Heading up this effort we've hired Heather Brysiewicz. She's been heavily involved with the tech community in San Diego for a few years now, running the SD JS meetup and founding the SD Ember meetup. She recently started co-organizing the SD Elixir meetup. On top of that she's an amazing engineer.

We're beginning to explore other locations as well. As we continue to grow some of our existing employees have expressed interest in leaving Boston. Until recently we held a "Boston-only" policy but over the past six months we've been experimenting with changing this. Our reluctance lay within managing client projects with remote devs properly and exporting our culture. Our team has been working hard to codify many of the aspects of what it means to work at DockYard but also work with DockYard. We've come to a good comfort level with remote developers and the idea of other "DockYard"s outside of Boston.

Starting today we're now accepting contracts and offering on-site training for Ember.js and Elixir for the West Coast. If you have a project in mind please get in touch!

The Personal Growth Cycle: Learning How To Learn

2016-07-01 00:00:00

For the longest time, I've felt like an imposter in the ever-increasingly complex world that is the tech industry. New terminology and best practices emerge every other day at a relentless pace. Frameworks come and go, new ideas become standard, and thought-leaders discover that yet another thing is considered harmful.

With an intense culture unlike any other, it's no surprise that feelings of inadequacy are commonplace. Prior to joining DockYard, I was just another Australian developer enjoying internet anonymity. The startup I worked with (2014) then used Ember on the front-end, and my colleagues and I found it difficult to work with. This was prior to Ember 1.13, so things were a lot different back then!

The first step is admitting it

I started my blog during that time, mostly writing about "cool" things we had done with Ember like drag and drop, flash messages, and so on. I didn't think too much of it then. After all, I was still considered relatively junior, it being my first real job outside of my own startup.

Starting out as a self-taught designer, I learnt front-end development while working on my startup, and in my time at my first job. Coding was unlike anything I had ever done before, but I loved it, and kept at it even when I was frustrated.

My writing was a way to document (and learn from) how I tried to solve a particular problem. To my surprise, some of the more prominent members of the Ember community started to take notice, and I was asked to try my hand at submitting a talk to EmberConf.

Get out of your comfort zone

Public speaking was (and still is) my greatest fear, so it took a little convincing before I decided I would try submitting a proposal. My talk ended up being accepted, and despite being absolutely terrified, I walked up on stage facing hundreds of people, and delivered the talk I had prepared so hard for.

Brian reached out to me shortly after, and I joined DockYard in March last year. He saw the potential in me I couldn't, and in the past year or so, I've grown in many ways. There are amazing people here who constantly push you to become better, and it's no exaggeration when I say that DockYard is one of the best places I've been fortunate enough to work at.

When I first started, I was terrified. I didn't think I could do it, because I had little experience. Despite that fear, I kept at it â things started making sense, and I could even explain to others.

This year, I worked solo on a project for a client â an API built using Elixir / Phoenix. I was terrified, again. I didn't think I could do it, because I had only read a book and wrote a tiny bit of Elixir. Despite that fear, I kept at it â things started making sense, and now I'm a self-taught full stack developer.

The cycle of growth

I'm not going to tell you that getting good at something takes 10,000 hours, but it does take time and effort. Learning a new skill or improving one is rewarding, but learning to learn will reward you many times over.

Unfortunately, I can't teach you how to learn. Everyone learns differently, and you must discover it for yourself. What I can tell you, is that how you learn (visual, experiential, etc) is merely an implementation detail. What's important is the cycle:

Reflect â Know where you stand
Do â Get out of your comfort zone
Learn â Fail and try again

If you're familiar with the Lean Startup, you'll notice that the steps are the same. The cycle is your real world REPL, and just like programming, is an excellent way to take a more exploratory approach to learning.

Help someone else to grow

When you find yourself in a position to mentor, embrace it. Although the cycle is personally rewarding, being able to help someone else to "learn how to learn" is even more so.

It's bittersweet, but this month will be my last month working with this amazing team. DockYard has been the perfect environment to put this in practice, and I am eternally grateful that I had the chance to be a part of something special.

Here's to more growth!

Component Dependency Injection for Testing In Ember.js

2016-06-28 00:00:00

The Dependency Injection (DI) pattern is a subset of Inversion of Control, and is a useful technique for decoupling the creation of a dependency from the object itself. Don't let the terminology scare you though! DI is really just giving an object its instance variables.

For example, below is a simple example of the Player class being implicitly coupled to the Bag class. The Player is responsible for creating the dependent objects.

  
  export default class Player {
  constructor() {
    this.inventory = new Bag({ /* ... */ });
  }

  add(item) {
    return this.inventory.add(item);
  }
}

let bob = new Player();

Although the example is simple, it's fairly easy to see that this implementation could be difficult to test in isolation, as you now need to know about the Bag class in the Player class' test. DI can help us here:

  
  export default class Player {
  constructor({ storageObject }) {
    this.inventory = storageObject;
  }

  add(item) {
    return this.inventory.add(item);
  }
}

let bob = new Player({ storageObject: new Bag({ /* ... */ }));

In the second example, we "inverted control" of the player's inventory, and now we pass the storage object instance at runtime. This means that in our test, we can simply stub the inventory object out:

  
  test('it adds an item', function(assert) {
  let dummyStorage = { /* ... */ };
  let dummy = new Player({ storageObject: dummyStorage });

  assert.ok(/* ... */);
});

The Player class no longer needs to know anything about the Bag, and also allows other kinds of storage object classes to be used. Great!

Component Dependency Injection

I recently realized that the DI pattern can also be used to great effect in Ember components. For example, let's say you have a container or parent component that uses multiple child components:

  
  <!-- templates/application.hbs -->

{{edit-location location=location}}

  
  <!-- components/edit-location.hbs -->

{{google-map 
    lat=location.lat 
    lng=location.lng 
    setLatLng=(action "setLatLng")
    setMarkerRadius=(action "setMarkerRadius")
}}
{{edit-location-form location=location}}
{{location-activity location=location}}

The parent component edit-location's primary responsibility is to provide UI to edit a location. It could have actions defined on it, like so:

  
  // components/edit-location.js

export default Component.extend({
  actions: {
    setLatLng(latLng) {
      // logic
    },

    setMarkerRadius(radius) {
      // logic
    }
  }
});

The google-map component provides UI for the user to drop a marker on a map, and adjust the radius around the marker by using the radius control. Needless to say, that UI interaction is quite difficult to test, and is tested in the google-map component test itself. Because the edit-location component is tightly coupled to its child components, testing it is no easy task. We need to make sure all the child components are setup just right, which introduces a lot of boilerplate in our component integration test.

Not my concern

In this scenario, the edit-location component itself shouldn't need to concern itself with how the latLng and radius arguments are passed into its actions. The drag and drop UI is a concern of the google-map component, and as such should be tested in its own component integration test.

Using DI, we can decouple the edit-location component from its child components, and clean up our tests. This technique is currently only possible with contextual components due to the use of the component and hash helpers, which were made available in Ember 2.3.0.

  
  <!-- application.hbs -->

{{edit-location 
    location=location
    ui=(hash
      location-map=(component "google-map")
      location-form=(component "edit-location-form")
      location-activity=(component "location-activity"))
}}

We've passed in a hash of the child components using the hash and component helpers. This effectively inverts control to the template that calls the edit-location form:

  
  <!-- components/edit-location.hbs -->

{{ui.location-map 
    lat=location.lat 
    lng=location.lng 
    setLatLng=(action "setLatLng")
    setMarkerRadius=(action "setMarkerRadius")
}}
{{ui.location-form location=location}}
{{ui.location-activity location=location}}

Now, in our tests, we'll need to write a little test helper to create a dummy component we can use to no-op (do nothing). Credit goes to @runspired for nudging me in the right direction:

  
  // tests/helpers/dummy-component.js

import Ember from 'ember';

const {
  Component,
  assign,
  getOwner
} = Ember;

export default function registerDummyComponent(context, name = 'dummy-component', opts = {}) {
  let owner = getOwner(context);
  let options = assign({ tagName: 'dummy' }, opts);
  let DummyComponent = Component.extend(options);

  unregisterDummyComponent(context);
  owner.register(`component:${name}`, DummyComponent);
}

export function unregisterDummyComponent(context, name = 'dummy-component') {
  let owner = getOwner(context);

  if (owner.resolveRegistration(`component:${name}`)) {
    owner.unregister(`component:${name}`);
  }
}

This test helper registers a fake component in the container, making it available for us to use in our component integration test:

  
  // tests/integration/edit-location-test.js

test('it ...', function(assert) {
  registerDummyComponent(this);
  this.set('location', {});
  this.render(hbs`
    {{edit-location
        location=location
        ui=(hash
          location-map=(component "dummy-component")
          location-form=(component "dummy-component")
          location-activity=(component "dummy-component"))
    }}
  `);

  assert.ok(/* ... */);
});

Now we can test the edit-location component itself without worrying about setting up child components. That said, DI still allows us to test those child components integrating with edit-location, in a more controlled environment:

  
  // tests/integration/edit-location-test.js

test('it updates location via the form', function(assert) {
  registerDummyComponent(this);
  this.set('location', {});
  this.render(hbs`
    {{edit-location
        location=location
        ui=(hash
          location-map=(component "dummy-component")
          location-form=(component "edit-location-form")
          location-activity=(component "dummy-component"))
    }}
  `);

  assert.ok(/* ... */);
});

I hope you find this useful! It's not a silver bullet by any stretch, but DI can help you write better isolated components and simplify your tests.

Bringing Ecto Changesets into Ember.js

2016-06-17 00:00:00

The past month or so, I've been working on an Elixir and Phoenix API for a client. I am blown away by how nice it is working with Elixir and functional programming (FP) concepts. FP feels more intuitive and less prone to "shoot yourself in the foot" scenarios compared to OOP. In fact, I try to use functional approaches wherever possible in JavaScript as well.

That isn't to say that one is better than the other, but in my experience less unexpected behavior occurs in FP. It turns out whole classes of bugs disappear when embracing immutability and pure functions.

Ecto Changesets to the Rescue

In Elixir, we use Ecto, a DSL for writing queries and interacting with databases. One of the core concepts in Ecto is the changeset â an atomic collection of changes. Changes are validated and checked against database constraints (such as uniqueness) before casting. This ensures that we catch invalid data in the app layer before insertion into the database. Ecto is often confused with Rails' ActiveRecord, but it isn't an ORM, and shouldn't be used like one.

The idea for bringing changesets into Ember occurred to me while I was working on a new client app. An edit page featured 3 forms, all bound to the same model. Each hidden form had separate "toggle", "save" and "reset" actions. Using ember-form-for and ember-cp-validations, this turned out to be harder than I thought. Editing one form would immediately update the model with 2-way bindings. This was a poor user experience, since you might edit more than 1 form at a time, but want to separate saves and resets.

Changesets in Ember

In my mind, I could see a solution using changesets. Each form would have a separate changeset, so changes (and validations) would be independent. It turns out that this approach works really well, and I'm happy to announce that you can install it today as an addon with:

  
  ember install ember-changeset
ember install ember-changeset-validations

I wrote the addon with compatibility in mind, so it's easy to wire up with your favorite validation library. The simplest way to incorporate validations is to use ember-changeset-validations, a companion addon. It has a simple mental model, and there are no observers or CPs involved â just pure, plain JavaScript functions.

Let's take a look at ember-changeset is implemented, and we'll also demonstrate how they align with Ember's Data Down Actions Up (DDAU) philosophy.

Virtual Properties with `unknownProperty` and `setUnknownProperty`

The core concept behind ember-changeset is the definition of unknownProperty and setUnknownProperty. These methods are invoked (if present) in Ember.get or Ember.set whenever an Ember Object does not define a property. Ruby developers would be familiar with this behavior via the method_missing method. A colleague I used to work with wrote an excellent blog post on this topic, please check it out if you're interested in finding out more!

For example:

  
  let Person = EmberObject.extend({
  firstName: null,
  lastName: null,

  unknownProperty(key) {
    console.log(`Could not get ${key}!`);
  },

  setUnknownProperty(key, value) {
    console.log(`Could not set `${key} with ${value}!`);
  }
});

When a Person is created, trying to get or set a property other than firstName and lastName will invoke the unknownProperty and setUnknownProperty methods respectively:

  
  let jim = Person.create({ firstName: 'Jim', lastName: 'Bob' });
jim.get('firstName'); // "Jim"
jim.get('fullName'); // "Could not get fullName!"
jim.set('age', 25); // "Could not set age with 25!"

These two methods allow us to proxy our changeset to the actual model, meaning we can hold back changes but still forward gets to the model.

Storing Changes

Our changeset needs a reference to the underlying model, as well as an internal list of changes to be applied. We can set this up in the init method of our object, which is invoked whenever a new instance is created.

  
  export function changeset(obj, validateFn/*, validationMap */) {
  return EmberObject.extend({
    init() {
      this._super(...arguments);
      this._content = obj;
      this._changes = {};
      this._errors = {};
      this._validator = validateFn;
    }
  });
}

export default class Changeset {
  constructor() {
    return changeset(...arguments).create();
  }
}

We want to be able to forward gets to _content, but hold back sets on _changes, and this is easy enough to set up via virtual properties:

  
  {
  unknownProperty(key) {
    let content = get(this, '_content');
    return get(content, key);
  },

  setUnknownProperty(key, value) {
    return this._validateAndSet(key, value);
  },

  _validateAndSet(key, value) {
    // if valid, set it on `_changes`
    // otherwise set it on `_errors`
  }
}

Since a changeset should only allow valid changes to be set, we validate the change using the validateFn function that was passed in to the changeset factory. If a change is valid, we add it to the hash of changes in _changes, and if it's invalid and returns an error message, we add it to the hash of _errors.

Of course, there are more implementation details than that, but the concept remains unchanged. After defining a simple public API for using changesets, there wasn't too much more code to add! For example, this is how you would use a changeset:

  
  let changeset = new Changeset(user, validatorFn);
user.get('firstName'); // "Michael"
user.get('lastName'); // "Bolton"

changeset.set('firstName', 'Jim');
changeset.set('lastName', 'B');
changeset.get('isInvalid'); // true
changeset.get('errors'); // [{ key: 'lastName', validation: 'too short', value: 'B' }]
changeset.set('lastName', 'Bob');
changeset.get('isValid'); // true

user.get('firstName'); // "Michael"
user.get('lastName'); // "Bolton"

changeset.save(); // sets and saves valid changes on the user
user.get('firstName'); // "Jim"
user.get('lastName'); // "Bob"

Rolling back changes, and even merging them, becomes trivial with a changeset:

  
  changeset.set('firstName', 'Milton');
changeset.get('isDirty'); // true
changeset.rollback();
changeset.get('isDirty'); // false

  
  let changesetA = new Changeset(user, validatorFn);
let changesetB = new Changeset(user, validatorFn);
changesetA.set('firstName', 'Jim');
changesetB.set('firstName', 'Jimmy');
changesetB.set('lastName', 'Fallon');
let changesetC = changesetA.merge(changesetB);
changesetC.execute();
user.get('firstName'); // "Jimmy"
user.get('lastName'); // "Fallon"

Data Down Actions Up, Not 2-Way Bindings

One of the reasons DDAU is so strongly emphasized in Ember 2.x is because it helps us avoid shooting ourselves in the foot with 2-way bindings (2WBs). 2WBs were the "killer feature" of many JavaScript frameworks when they first debuted. As client side applications matured and became more sophisticated, developers realized that 2WBs were more harmful than useful. 2WBs led to instability and difficult debugging in the form of cascading changes, and React was the first library to attempt to solve this problem.

React's breakthrough was in the use of a virtual DOM, a representation of the actual DOM as a tree-like data structure. Diffing the changes between the virtual and real DOM paved the way for the complete removal of 2WBs â the application simply re-renders whenever there is a change in value.

This continues to be a simpler mental model, and just like Elixir (and other functional languages), eliminates a whole class of bugs. DDAU in Ember.js is built upon the same idea, that data should flow one way.

Using changesets in Ember takes the DDAU philosophy used in rendering into the realm of interacting with client side view models. Instead of 2WBs, changesets allow one way data flow to a model, ensuring that they are always valid, and eliminating a whole class of synchronization headaches.

Is This Real Life?

When I dropped in ember-changeset and ember-changeset-validations into my client app, it instantly clicked with the way I've been writing Ember, using DDAU. My complex forms now have independent validations and changes, and I no longer need to worry about saving an unintended change in one form when I submit another.

Because ember-changeset can be used directly in place of an ember-data model, using it with a form library like ember-form-for is trivial using the changeset helper:

  
  {{dummy-form changeset=(changeset model (action "validate"))}}

  
  {{#form-for changeset as |f|}}
  {{f.text-field "firstName"}}
  {{f.text-field "lastName"}}
  {{f.date-field "birthDate"}}

  {{f.submit "Save"}}
{{/form-for}}

Validating Changesets

Validation becomes even simpler with changesets. Throughout Ember's history, we have largely relied on addons like ember-validations which make extensive use of observers. Newer libraries like ember-cp-validations use computed properties (CPs) instead, but that still relies on 2WBs.

Using ember-changeset and ember-changeset-validations, you can take a functional approach with validations. A validator function is passed into the changeset, that is invoked whenever a property is set. This validator function then looks up the appropriate validator (say presence or format) on the validation map, and returns true or an error message.

  
  import {
  validatePresence,
  validateLength,
  validateConfirmation,
  validateFormat
} from 'ember-changeset-validations/validators';
import validateCustom from '../validators/custom'; // local validator
import validatePasswordStrength from '../validators/password-strength'; // local validator

export default {
  firstName: [
    validatePresence(true),
    validateLength({ min: 4 })
  ],
  lastName: validatePresence(true),
  age: validateCustom({ foo: 'bar' }),
  email: validateFormat({ type: 'email' }),
  password: [
    validateLength({ min: 8 }),
    validatePasswordStrength({ minScore: 80 })
  ],
  passwordConfirmation: validateConfirmation({ on: 'password' })
};

A validator like validatePresence is simply a function that returns a function:

  
  // validators/custom.js
export default function validateCustom({ foo, bar } = {}) {
  return (key, newValue, oldValue, changes) => {
    // validation logic
    // return `true` if valid || error message string if invalid
  }
}

Which is simpler to reason about compared to an OOP implementation that relies on extending base classes and holding on to state. Because validation maps are simply POJOs, composing validators is intuitive:

  
  // validations/user.js
import {
  validatePresence,
  validateLength
} from 'ember-changeset-validations/validators';

export default {
  firstName: validatePresence(true),
  lastName: validatePresence(true)
};

You can easily import other validations and combine them using Ember.assign or Ember.merge.

  
  // validations/adult.js
import Ember from 'ember';
import UserValidations from './user';
import { validateNumber } from 'ember-changeset-validations/validators';

const { assign } = Ember;

export const AdultValidations = {
  age: validateNumber({ gt: 18 })
};

export default assign({}, UserValidations, AdultValidations);

This approach lets you build up validations independent of the model. Ember Data models aren't 1 to 1 representations of server-side records, they're View Models. This means we shouldn't need to validate them the same way we would a server-side model. For example, you might have User models in your application, and some of these users might have different roles that require different validation. Best of all, we don't need to use observers or CPs!

The Only Constant is Change

I hope you enjoyed reading about the concept and implementation of changesets in Ember. DDAU on your models will make your life simpler and your app easier to reason about! Work is still on-going on these addons, so please try them out and let me know if you have any issues or feedback.

As always, thanks for reading!

Git Init: My First Two Weeks at DockYard

2016-06-17 00:00:00

How I Got Here

Two weeks ago I started working as an intern at DockYard - though it feels like Iâve been learning from the employees here long before then. If that sounds a bit confusing, I can explain.

As a young and (excessively) restless developer, Iâm constantly experimenting with new libraries and frameworks. The âProjectsâ directory on my laptop is a messy graveyard of half-finished Todo apps, CRUD blogs, and coding sandboxes created to try out a promising new language or technology. You probably know the type, or share some of these same symptoms.

I decided to check out Ember.js a year ago, and soon realized that I kept finding myself back here on ReefPoints. I was reading fantastic pieces by DockYard engineers on almost every topic pertaining to Ember development. I learned a tremendous amount about the various nooks and crannies of the framework, but more importantly, began to recognize what makes Ember such a great tool for building truly ~ambitious~ web applications.

So when I read Michael Dupuisâ email to the Tufts CS group about DockYard looking for new developers, I knew that this would be a fantastic opportunity. Directly working alongside some of the most prolific OSS contributors and JavaScript engineers in the Boston area is not something to miss out on. DockYard takes their engineering seriously, and I really wanted to level up my engineering skills this summer. It was a perfect match.

In the past couple of weeks, however, Iâve realized that thereâs far more to this place than just a deep knowledge of web development.

What makes DockYard so special?

One of the things that I immediately noticed clearly defines this place is the sheer amount of collective knowledge shared between everyone in the company. Iâve only just started to get to know people here, and it seems like each member of the twenty-two person team has a unique area of expertise. DockYarders include the creator of an incredible web framework, expert JavaScript and Ember.js engineers, Boston architectural enthusiasts, and craft beer sommeliers. If you put all of these people in a room together and have them work on creative projects, youâre bound to get great results. There is a contagious, inventive energy in the air that is noticeable right when you walk into the office, and you can tell that DockYarders are proud of the work that they do.

Expertise and mastery of craft is ingrained in the culture here, but so is self-improvement and knowledge sharing. DockYard does a fantastic job of consulting and working with their clients, but they do just as great a job of training and educating their own employees.

I've experienced this first hand. Despite how intimidating it could have been to pair program with an engineer on an Ember client project (and fumble around with an addon that they created), it has never really felt that way. Itâs why every Thursday two DockYarders do an in-depth presentation on a topic of their choosing, which are then frequently taken to conferences around the country. Itâs why the Slack channels for technologies like Ember and Phoenix are constantly buzzing with questions and back-and-forth conversations about best practices. And itâs why youâre reading this blog post from me right now: sharing of experience is not just encouraged, itâs expected.

Time to get to work!

I think Iâm joining DockYard at a really exciting time for both the company and the software consultancy industry as a whole. Thereâs such a wide variety of interesting and challenging projects being started, and the tools with which to build them have never been more promising or enjoyable to use. DockYard recognizes this more than anything else, and makes sure to invest their time in projects and technologies that have the most future potential.

My goal for the next three months is to learn as much as possible from the many talented individuals in the office, and hopefully be able to contribute in my own way. Iâm excited to get hands-on experience working with clients, but Iâm also looking forward to participating in the many traditions that separate DockYard from other companies: Wicked Good Ember, hallway talks, monthly outings, DockYard Fridays, and countless others. I know that at many points I will struggle, and perhaps even fail, but thatâs okay. In fact, thatâs what I signed up for - a challenging new experience. Hereâs to a great summer.

Today, User Experience is KingâWhy Your Technology Choices Should Reflect That

2016-06-13 00:00:00

In Norton Justerâs The Phantom Tollbooth, an intriguing character introduced as The Whether Man tells the protagonist Milo, âExpectations is the place you must always go to before you get to where you're going. Of course, some people never go beyond Expectations, but my job is to hurry them along, whether they like it or not.â While Expectations is an actual locale in a childrenâs novel, web developers and designers should similarly go beyond Expectations, although the Whether Man is right in that some never do. In order to do so, one must recognize that in todayâs market, user experience reigns supreme. The most direct way to surpass Expectations is by delivering a user experience via a mobile web app but that feels like a native app (such as an iOS application that you purchase through the App Store).

I had an English teacher in high school who said that you need to hold your readerâs hand through an essay, meaning your writing should be clear and easy to understand. Similarly, an application should deliver a user interface where a user can move intuitively and fluently through each piece of the application. That being said, that experience can only be as good as the tools that are used to create it. At DockYard, these tools include design strategy and Ember.js as our client-side framework to build the single page applications that we design and develop in-house.

Single page applications, also known as client-side applications (as opposed to server-rendered applications), are web applications that upload to a single HTML page, dynamically updating the experience as the application is in use. Because of a client-side configuration, an application can respond to its users instantly. The design supports self-directed navigation, and the process is not disrupted by the reload of a page, which creates a more native feel. Further, these web applications cater to all variants of operating systems, and the framework we use to build these applicationsâEmber.jsâis backwards compatible, meaning there will be support for the long haul. Ember.js is also a versatile framework, so it can also be used to build can be used for hybrid apps, which live within a native app âshellâ but can be launched within a web browser (e.g. LinkedIn, Groupon, and Yahoo use Ember.js).

By design, these applications help to alleviate information overload and simplify navigation, which allows users to easily understand content. Users are therefore encouraged to engage further, whether they are aware of it or not. Before I started working here, I didnât really pay attention to UX. Now, Iâve noticed that users, including myself, become frustrated with longer-than-needed loading times and poor design. Importantly, applications that have faster response times yield higher conversions, so you get a greater return on investment with a single page app. Additionally, according to surveys done by Akamai and Gomez.com, nearly half of web users tend to abandon a site that isnât loaded within 3 seconds. 79% of web shoppers who have trouble with website performance say they wonât return to the site to buy again.

When you think from the perspective of the user and strategize production with them in mind, you set yourself up for the greatest chance of success. You can ensure that your product is user-driven from the beginning by engaging design strategies, such as user research and prototyping, which can allow you to test initial hypotheses and create a product development roadmap. In this way, you can build reliably and save yourself time and frustration in the future.

When applications are built well, its users have more agency to interact with the application more deeply. The single page web app model is at the forefront of mobile and web design and development, allowing both designers and developers to consider unique solutions. Please be advised: if youâre not paying attention, you can quickly find yourself in the Doldrums, and no one wants that.

Is design really just decoration?

2016-06-13 00:00:00

Historically, design has been an afterthought, the philosophy behind it being, âBuild something, then weâll employ design afterwards to improve its appeal.â That being said, as Mike Monteiro describes in Youâre My Favorite Client, bringing in designers once a product has been built is âakin to baking a cake, and then hiring a baker to make it taste good.â

In todayâs competitive marketplace, solid user experience design is a key advantageâyou canât succeed without it. Products can no longer succeed simply because they workâthere are too many other products competing for your usersâ attention. Users want to be impressed, and starting with exceptional UX design is a necessity to achieve that.

Visual design refinement can be left for later.

Involving design brings up another common misconception that begs the question, âWhat is exactly is included in design?â If we narrowly define design as color, typography, pattern, and layout, then it is understandable how that might be left for later.

There are a few instances when it does make sense to begin a project with visual designâparticularly for branding and marketing campaigns. If youâre tasked with designing a digital experience for disinfectant wipes, you could use a design sprint to create and test visuals-and-copy concepts. You might come out with two concepts: one around âa motherâs instinct to care for her familyâ and the other âthe inconvenience of taking a sick day.â

Without a strong visual component, it would tough to communicate these emotional concepts to potential consumers to gauge their response. One or more additional sprints could be used to flesh out the features and functionality of a campaign and application that leverage the concept that emerged from that initial sprint.

However, in most of the projects we encounter, we're not designing visual branding elements in isolation. Rather we're working out complex experiences for products and services, along with the visual identity, the sum total of which become the brand. In these, it does not make sense to lead with visual design. In order to design and create an effective, well-done user experience, one must establish who the users are, what the goals are for the product, and validate the productâs workflows.

Whatâs there beyond visual design?

A designer can barely cross the road without considering the systems and forces in place that are behind a variety of scenarios. While one potential solution for a poorly-designed crosswalk is creating a better-looking sign, most of the work behind that decision will be strategically thinking about the systems behind the crosswalk and relevant interactions.

Many parts of our design-first approach to business problems at DockYard could go by different names. Here are some examples that are crucial to its process despite not being initially associated with design:

Product strategy

As designers, we ask lots of questions about why and how a product will serve its users, while at the same time achieving business goals of the product owner.

Research

Research at the early stages of a project can prevent expensive mistakes later down the line. Questions we ask could include: - âDoes your audience actually want the product?â - âWhat does the audience think the product does?â - âDoes your audience exist? Is there a viable market for this product?â

Planning

Once we start building, we discuss what should be built first and how production can be implemented in manageable chunks, with testing and check-ups in between. We examine if there are certain parts of the product or service and any differences between them.

Testing

Having real users perform a specific task on a real product or a prototype is the only way to discover whether it actually works in the way which you expect. Moreover, user research allows you to potentially uncover and fix glitches early. User tests are more valid and the data is more authentic if an outside party helps run the tests in an impartial manner.

Setting up goals & measures

Finally, we operationally define success and how to measure that success. By setting a baseline early on, you have a standard to which to compare later performance.

Planning, testing, and research are all parts of design. When applied early, these exercises are magnified in terms of effectiveness. Afterwards, during the product development stage, we'll have some basis for making each of the hundreds decisions that go into your product.

Answering questions early with design sprints

2016-06-13 00:00:00

In this day and age, efficiency is crucialâwe live in a world where the rate at which we progress is almost unsettling. In business, efficiency becomes essential in that we must keep up with our competitors, not waste anyone's time, and operate economically and efficiently, all without sacrificing quality. While strategy is possible without an outside party, weâre often too close to a situation to see the drawbacks and obstacles.

Weâre often sensitive about the things we know best, and thatâs not a bad thingâit only makes sense that we should be so invested in our work. A new perspective is advantageous in that it allows for a number of unique observations, exposing potential pitfalls and eliminating assumptions. A design sprint can be a good way to enlist that outside perspective.

A while back, I explained what design sprints are for:

The purpose of a sprint is not to deliver a whole product, but a realistic model of a product experience. In a few cases a product experience may be small and focused enough to be encompassed entirely in the sprint. More likely, a design sprint focuses on a specific aspect of an application, and a single user story.

Action towards the implementation of a product may seem more favorable option than planning. However, strategizing and answering unknowns via a design sprint is an investment that will pay dividends by saving so much time and sparing a lot of frustration down the line. Further, involving all the different players (e.g. strategists, engineers, designers, potential users) allows us to brings realism to the project.

The best time for a sprint is not after a project has already started, but before any implementation work has begun. A design sprint early in the planning stages will go a long way to reduce uncertainty and validate the current projectâs merit. That way, your team can confidently focus on the projectâs success.

Harvard Business Review recommends sprints because they help âfocus on whatâs important.â To get an idea of how a design sprint could work for you, check out the open source Design Sprint Guide weâve produced to explain how design sprints can reduce uncertainty by efficiently testing business ideas.

New to Elixir 1.3 - Kernel.pop_in

2016-06-05 00:00:00

Back in February I wrote about how to work with deeply nested maps. One missing piece was the ability to easily prune data from a deeply nested map. Today I'd like to introduce you to Kernel.pop_in which will be available in Elixir 1.3.

Given the following:

  
  my_map = %{
  foo: %{
    bar: %{
      baz: "my value"
    }
  }
}

In order to delete the baz atom you would have to write something like this:

  
  put_in(my_map, [:foo, :bar], %{})

For this contrite example it may not seem that bad. But let's take a look at another example:

  
  my_map = %{
  foo: %{
    bar: %{
      baz: "my value",
      qux: "other value"
    }
  }
}

If we wanted to preserve the qux atom we'd write:

  
  put_in(my_map, [:foo, :bar], Map.delete(my_map[:foo][:bar], :baz))

Now we're starting to see something that could get ugly. This is where Kernel.pop_in can help:

  
  pop_in(my_map, [:foo, :bar, :baz])

That's nice and clean! However, unlike the other accessor-based functions this one returns a tuple:

  
  {"my value", %{foo: %{bar: %{qux: "other value"}}}} = pop_in(my_map, [:foo, :bar, :baz])

The first element in the tuple will be the value that is being removed. The second element will be the new map.

Elixir 1.3 comes packed with a bunch of improvements for the developer experience like this one. Hopefully we can all start enjoying it soon!

How to make sense of a complex project, fast

2016-06-02 00:00:00

We live in an increasingly complex world. Your business doesnât exist in a vacuum, and thereâs so much to keep track of. When you have a problem that needs solving, itâs often hard to define what that problem is, whoâs having it, and what the solution might look like. Everyone seems to have a different opinion. And just when you think youâre making progress trying to understand things, something changes. Or everything changes. No wonder folks become overloaded and frustrated — what a mess!

Complex, dynamic systems often exist beyond understanding by any individual.

Image Credit: Telegraph

No one person on an aircraft carrier understands all of the complex systems on board — not even the captain. And yet, that ship is able to function as it does due to a network of common understandings and cooperation. Design Thinking is a set of tools and methods we can deploy to make sense of the jumble before solving problems. The goal isnât to simplify whatâs inherently complex, but rather to embrace that complexity through better, shared understanding.

We take our first steps by wrapping our heads around what we already know or have. Working together, weâll create models, much like scientists do. This gives us something in common - something we can all point at and discuss.

We often start with language, by naming things. From there, weâll create sketches collaboratively, defining concepts, showing relationships and allowing us to compare and contrast. Weâll do this iteratively, which increases our collective understanding over time. Knowing where we are today — and then layering on where weâre trying to get to and how weâll know when we get there — gives us a sound framework for future decision-making.

One of our clientâs goals is to open up a system used internally to external customers, for self-service. The current system was developed over many years and has hundreds of screens and functions. Itâs not only a complex workflow - itâs a complicated user interface, a ratâs nest of tabs and sub-tabs and pop-ups that open pop-ups.

We couldnât possibly begin to redesign it without trying to make sense of it first. But how? This is a problem best approached from several directions.

First, weâd gain some level of shared understanding of the present system. Like that aircraft carrier, it seems like not one person understands the whole system. Weâd talk to the product owners, engineers, support team, and existing users. Weâd also make our own way around the app. Along the way, weâd create and validate mental models and sketches.

The goal is orientation, not complete understanding.

Image Credits: Boston Discovery Guide, Wikipedia

Second, weâd look toward the future. Weâd talk to the business stakeholders, to gain their understanding of the problem weâre trying to solve, and for whom it is a problem. Do they all agree? Weâd also examine the external contexts that the system will exist in: user, industry, and technology.

Third, weâd talk to the prospective self-service users. Our client isnât the only player in its huge market, and most of their customers are already familiar with several competing systems. By comparing and contrasting the language and mental models of these customers with what we know about the existing internally-focused system, weâd discover where we have alignment and where we have conflict.

Because itâs always easier to leverage entrenched behaviors than to try to instigate new behaviors, our insights will directly influence the prioritization, naming, and design of the features, functions, and flows of the new system. Weâll even spot opportunities to be better than the competition!

Finally, weâd design and construct prototypes — and test them.

The time and effort we spend together in up-front sense-making may not feel like âdesign.â But itâs one of the most important and best investments you can make.

TIL: Ecto supports a query inside another query

2016-05-27 00:00:00

If you read the Ecto.Query documentation, one of the first sections explains how Ecto queries are composable. Meaning, we can extend a query after creating it. Like so:

  
  query = from e in Event,
  where: e.category == ^event.category

case event.host do
  host -> from e in query, where: e.host == ^host
  _ -> query
end

This was a feature that I learned a while after starting Elixir (apparently I didn't read the docs well enough). And it is totally awesome. But today I learned Ecto also supports nested queries!

  
  last_event = from e in Event,
  distinct: e.id,
  order_by: [desc: e.inserted_at]

query = from a in Attendee, preload: [events: ^last_event]

Here, we are referencing a query (last_event) from within another query. How exciting! It is also important to mention that Ecto 2.0 supports subqueries in the from and join fields (see example below). This makes queries even more malleable and powerful. Hope you enjoy it as much as I do!

  
  query = from e in Event, select: e
q = from e in subquery(query), select: e.summary

Narwin-Pack: A PostCSS Package for DRY and Efficient CSS

2016-05-27 00:00:00

In my last blog post, Why DockYard transitioned to PostCSS, I explained why our UXD team adopted PostCSS into our development process.

During the transition process we realized it would be best to only use PostCSS plugins that meet two criteria:

Encourages DRY CSS
Simplifies our development process

Thatâs when narwin-pack was born, An easy-to-use PostCSS package that holds all six of our plugins in one easy-to-use package.

Having many plugins bundled into one package that can easily be included in our projects is valuable to our team. It gives our UXD team a structured environment to develop CSS.

If another UX developer wants to add a plugin to narwin-pack a discussion is had within the narwin-pack repository and we discuss the pros and cons of using that plugin. If everyone agrees that a plugin is needed then it will be added to narwin-pack.

PostCSS has options for hundreds of plugins that you can include in your project. Having only one package to use for our projects provides consistency, knowing that every developer within out team will be using the same plugins.

The plugins in narwin-pack are as follows:

1. postcss-partial-import

The postcss-partial-import plugin provides the environment for a modular CSS file structure. You can have multiple CSS files and then with the help of postcss-partial-import we merge all our CSS files into one central file that the browser will use.

The ability to have multiple CSS files but only reference one CSS file in our HTML is important for page performance. The browser now only has to ask the server for one CSS file. At the same time using multiple CSS files lets us modularly organize our CSS based on BEM naming conventions and SMACSS file architectures.

Modular CSS file structure:

  
  styles/
  modules/
    header.css
    footer.css
    nav.css
  base.css
  load.css
  layout.css
  type.css

Using this CSS architecture we can now add all of those CSS files into one central CSS file. Our CSS file with @imports pointing to other CSS files could look like the following:

  
  @import: "load.css";
@import: "type.css";

@import: "modules/header.css";
@import: "modules/footer.css";

The plugin will recognize the @import and add the contents of the referenced CSS files into this one CSS file.

2. postcss-custom-properties

Who doesnât love using variables!

The use of variables in CSS has been a hot topic lately, and eventually all browsers will support them. Firefox and Chrome already have support , but we are still waiting on Edge and mobile browser support. Until all browsers support variables, we will need a plugin.

I think most developers would agree with me when I say that I would rather remember a color for its name, as opposed to its hex code. Further, we make sure to organize our variables with naming conventions so they are easy to both read and use.

An example of how we organize our variables in our load.css file is as follows:

  
  :root {
  /* COLORS */
  --white: #FFFFFF;
  --green: rgb(61, 154, 104);
    --75-green: rgba(61, 154, 104, .75);

  /* FONT WEIGHTS */
  --light: 200;
  --bold: 600;
}

Notice that we break our variables down into sections and give them easy to use names with indentation. This way other developers can look at this CSS file and know what everything does.

An important thing to remember is that if you want variables available globally, wrap them in a :root {}.

Hereâs a quick example of how to use variables:

  
  :root {
  --green: rgb(61, 154, 104);
}

In other CSS files, you can just use the variable name in place of the color code.

  
  .text {
  color: var(--green);
}

The output of this will be the rgb color code. This is simple but allows us to organize colors and other variables.

3. postcss-nested

Nesting is a technique that we use, but in moderation. We make sure not to nest class names for easier âBEM-ingâ because it can be difficult to try to find BEM classes that are made with nesting. We canât search for .hero__heading if __heading was added to .hero with nesting.

Incorrect Example:

  
  .hero {
  margin-top: 10px;
  &__heading {
    color: blue;
  }
}

Using BEMâs naming conventions without nesting keeps our CSS files readable and searchable.

Correct Example:

  
  .hero {
  margin-top: 10px;
}
.hero__heading {
  color: blue;
}

We do use nesting for media queries, pseudo elements/classes and parent dependent classes styles.

Example:

  
  .nav__links {
  float: right;
  .body--black & {
    border-color: var(--white);
  }
  .body--white & {
    border-color: var(--black);
  }
}

.nav__link {
  color: var(--green);
  &.is-active,
  &:focus,
  &:hover {
    color: var(--50-green);
  }
  @media (max-width: 599px) {
    display: block;
  }
  @media (min-width: 600px) {
    display: inline-block
  }
}

The block of CSS above is a simple example of good nesting according to the guidelines we have set for ourselves.

4. postcss-calc

Having this plugin included in narwin-pack is a result of having postcss-custom-properties. With this plugin we can include variables inside calc() equations if we would like.

Input:

  
  :root {
  --font-size: 18px;
}

Any CSS file within the same root folder:

  
  .text {
  font-size: calc(var(--font-size) * 2);
}

Output:

  
  .text {
  font-size: 36px;
}

5. postcss-svg-fragments

A downside of using the symbol method for multiple SVGâs is that itâs not supported with inline CSS, only inline HTML. SVG Fragments solves this problem for us.

Without this plugin, we would need to have individual SVG files for background-images in CSS, and the browser would have to pull multiple SVG files when loading a page. The plugin postcss-svg-fragments solves this by doing what its name implies, it adds SVG fragments into CSS.

We take all our SVG files and add them to icomoon.io, generate a new SVG with a <use> that has an unique id. Then we add the new SVG code to our defs.svg.

Input:

  
  .background-patter {
  background-image: url(defs.svg#pattern);
  fill: blue;
  stroke: black;
}

Output:

  
  .background-patter {
  background-image: url(/* SVG data */);
  fill: blue;
  stroke: black;
}

6. autoprefixer

One of the most used tools by HTML/CSS developers is autoprefixer. Before having autoprefixer as a PostCSS plugin, we would go to caniuse.com to see what CSS rules still needed browser prefixes. Even developers who donât use PostCSS use the autoprefixer plugin in their projects.

Now, we have a plugin that looks at the CSS and searches for what prefixes are needed. Then adds them into the compiled CSS file according to how itâs configured. Autoprefixer lets us configure custom browser support.

Example with autoprefixer:

  
  .block {
  display: flex;
}

Output:

  
  .block {
  display: -webkit-box;
  display: -webkit-flex;
  display: -ms-flexbox;
  display: flex;
}

Takeaways

We choose these plugins because they are intended to make our lives easier as developers. Further, these plugins will help us develop DRY and efficient CSS, which is significant because that is the interface with which the user will interact.

If chosen carefully, the combination of plugins and self-set guidelines can foster a great environment in which to make exceptional CSS.

TIL: Elixir pattern matching for argument equality

2016-05-26 00:00:00

Pattern matching and guard expressions are fundamental to writing recursive function definitions in Elixir. Sometimes guard clauses and pattern matching can be used for the same purpose. For example:

  
  # pattern matching
defmodule Exponent do
  def power(value, 0), do: 1
  def power(value, n), do: value * power(value, n - 1)
end

# guard expression
defmodule Exponent do
  def power(value, n) when n == 0, do: 1
  def power(value, n), do: value * power(value, n - 1)
end

In both cases above, we only want the first power function to run when the second argument is equal to 0. When it is as simple as equality, I tend to use the pattern matching syntax. I typically leave the guard for more complex logic like when rem(x, divisor) == 0. However, to check whether one argument is equal to another I thought a guard was neccessary: when a == b. But, today I learned, this can also be handled with pattern matching, like so:

  
  # guard
def equality(a, b) when a == b, do: IO.puts "equal"
def equality(a, b), do: IO.puts "not equal"

# pattern matching
def equality(a, a), do: IO.puts "equal"
def equality(a, b), do: IO.puts "not equal"

Tada! There you have it. It seems so simple I don't know how I hadn't tried it earlier!

How does project communication become complex?

2016-05-25 00:00:00

Projects of larger scale or longer duration often involve a large design team. We typically keep everyone informed and share information efficiently on teams roughly the size of a large family. But we don't have that intuitive understanding of how teams work once they get much larger than that.

As Iâve gotten the chance to look into how larger teams work on projects, I realized that they have the potential to get too complex for one person to understand, and therefore communication requires careful attention and structure.

On a project of any size, there is inherent value in communication: it allows everyone to know what theyâre working on, and to avoid getting in the way of others. The value of clear and efficient communication is a subject for another time. What Iâm most concerned with here is how the level of complexity grows with team size.

Letâs see what happens as the number of people on a team grows. Weâll assume the hierarchical structure stays the same, leaving everyone roughly on the same level and allowing all team members to communicate with one another like they would on a small team.

A team of two or more needs to communicate.

With a team size of two, everyoneâs ideas and questions can be exchanged freely, and all team members are on the same page as these conversations happen.

With more people on a team, communication adds up.

If team communication style stays the same as a team grows, eventually it becomes more and more difficult for everyone to tell everyone else everything. At first it may look like the complexity of communication grows in a linear way, along with team size. But the pattern soon changes.

On larger teams, unmanaged communication becomes overwhelming.

If everyone keeps telling everyone everything, without a defined structure to contain those conversations, the amount of communications will grow (nearly) exponentially faster, even as team size grows in a linear fashion.

Remember that math problem from school, where youâd count the number of combinations of several objects? The teacher would make you go through manually counting the combinations for 2, 3, and maybe 4 objects until at 5 or 6 youâd determine that the number of combinations gets really big really fast. This is the same pattern I suspect would emerge if we allowed a flat structure of everyone talking to everyone, with no teams or management effort, for a large group of people.

Manage the conversations on larger teams. Because you have to.

The answer to the math problem is structure. As team sizes grow, managers or team leaders emerge who become responsible for keeping on top of communications within a smaller team (think - the drawing of four people above) as well as for relaying that information to other team leaders.

Reinventing the wheel?

The need for management is not a new concept. As I was discovering it for myself, I was surely reinventing the wheel. Colleagues advised that the number of connections between nodes is described by Metclafeâs Law.

The information exchange in a group could be managed by breaking down & managing different stakeholders depending on their influence (power) and influence level.

I also learned that coordination cost becomes one of the factors in determining the productivity of a team.

All these are great ways to look at getting things done with more perspective than I would have had before I took on a management role. Re-discovering some of these principles for myself, and learning from colleagues has been a rewarding process - and I canât wait to see whatâs next!

2016-05-13 00:00:00

At DockYard, one pattern that we've been noticing in some of our projects is needing to render different components based on some value. This value could come from a computed property, a model attribute, etc. Typically, this means that your template will contain some branching logic to figure out the appropriate template to render. A helpful helper that became available pre-Ember 2.0 is the {{component}}. With its help, we can clean up our template logic.

A distinguishing factor between the {{component}} helper and the traditional component invocation is that the helper expects the component name as the first parameter following the helper name, and will dynamically render out the component specified by that parameter. An arbitrary number of parameters may follow the component name; these are what the rendered component expects.

{{component myComponentName param2=param2 param3=param3 ...}}

Suppose we have a Food model. And each Food model instance has a taste attribute. We want to render a certain template depending on the string value of food.taste. Prior to having the {{component}} helper, we'd do something like the following:

  
  // food/component.js
import Ember from 'ember';
const { Component, computed: { equal } } = Ember;

export default Component.extend({
  isSpicy: equal('food.taste', 'spicy'),
  isSweet: equal('food.taste', 'sweet')
});

  
  {{! food/template.hbs }}

{{#if isSpicy}}
  {{food/spicy-food food=food}}
{{else if isSweet}}
  {{food/sweet-food food=food}}
{{else}}
  {{food/other-food food=food}}
{{/if}}

We defined a couple of computed properties and threw in some if statements in our template to dictate which component to render based on the food taste. But we can do better! Let's see how our app cleans up when using the helper.

  
  // food/component.js
import Ember from 'ember';
const { Component, computed, get } = Ember;

export default Component.extend({
  tastyComponentName: computed('food.taste', {
    get() {
      let foodTaste = get(this, 'food.taste');
      return `food/${foodTaste}-food`;
    }
  })
});

  
  {{! food/template.hbs }}

{{component tastyComponentName food=food}}

Nice. Our template became a one-liner, and we were able to remove the computed properties that we had to define for each food taste that we wanted to render a separate component for. All of the logic is now consolidated into one computed that returns the name of the component that should be rendered. We can pass this property as the second argument inside {{component}}. If we wanted to later introduce new food tastes and components to go along with them, no changes would need to be made in these two files, since tastyComponentName takes care of all cases.

More powerful templates

In the above example, we are using the computed property tastyComponentName to name our template. But it's not immediately obvious what the template actually is without looking at the computed property itself. We can forgo the CP altogether and use Handlebars subexpressions to keep all logic within the template.

Recently, Lauren and Marten released the ember-composable-helpers addon whose aim is to make logic in your Ember templates more declarative. How convenient that this addon complements {{component}} well! The helpers within ember-composable-helpers can be used in different combinations to format your component name depending on your needs. Furthermore, Ember itself ships with some built-in helpers that can be used inside our templates as well.

The Ember helper concat is one of the helpers we use fairly often. It's common to name components based on a value of an attribute. In our example, the component name is based on food.taste. How would we modify our example to make use of the concat helper?

  
  {{! food/template.hbs }}

{{component (concat "food/" food.taste "-food") food=food}}

And just like that, the food/component.js file is no longer needed. The concat helper replaces the computed property entirely. If the value of food.taste is sweet, then the helper will output food/sweet-food.

Another useful helper that works well in conjunction with concat is dasherize. This helper is part of ember-composable-helpers addon and will take care of lowercasing and dasherizing a given value. Sometimes, we have to work with camelized values, and using dasherize will convert them to a more desired format. Here's an example of how the helpers would be used together:

{{component (concat "food/" (dasherize food.taste) "-food") food=food}}

In this case, if the value of food.taste is SuperSour, then our rendered component will be food/super-sour-food. With all the helpers we have available to us, think of all the combination possibilities!

Transitioning into Tech: From Googling âWhat is Ember.js?â to Interning at a Software Consultancy

2016-05-11 00:00:00

âEmma, have you ever heard of Ember?â I asked my roommate, a friend of mine from college who works as a user experience (UX) designer at a tech company here in Boston. I was looking for marketing positions and came across a software consultancy company called DockYard. I was drawn to their professional yet approachable feel: While they had built software applications for several big name clients (e.g. NASDAQ, the Democratic National Committee, Constant Contact), the language they used was straightforward and sincere. Whatâs more, they were a startup that didnât feel the need to have the word âawesomeâ splashed all over their website, and their job titles didnât include the words âninjaâ or âjedi.â It was an exciting find.

At the time, I wasnât familiar with Ember.js, Phoenix, or Elixir, which are several of the technologies we use here at DockYard in web application design and development. My background is in psychology and research, and I previously worked in the Department of Psychiatry at Massachusetts General Hospital (MGH). But I figured Iâm a millennial, right? I grew up as the sophistication and use of the Internet took off on a global scale, and I can write HTML/CSS. If on one end of the spectrum you have my father, who is a businessman yet has neither an e-mail address nor a computer in his office, and on the other end you have your Mark Zuckerbergs and your Tim Berners-Lees of the world, then I fall somewhere in the middle. As I sat there wavering between the feelings of apprehension and audacity, I remembered my dad saying that the guy who leads the league in home runs usually also leads the league in strikeouts. So, I decided that I had nothing to lose and went for it: I filled out the âJoin Usâ form on DockYardâs website, and now Iâm sitting here reflecting on my first thirty days as a marketing intern.

Being new can be awkward as you try to orient yourself within the organization, but you also have the unique opportunity to look at something from an original, unlearned perspective.

The reaction you fear as a new employee when youâre about to say nearly anything

What I realized is that while Iâve always had a lot of respect for web developers and designers, I had never considered the future of tech in terms of the long-term viability of software applications or what that means for these roles. Admiration is not the same thing as appreciation, because to truly appreciate what someone does, you have to recognize the skill that it requires and the challenges facing that industry. Itâs easy to take software and other forms of technology for granted without considering the engineering and design that have gone into creating them.

Prior to my interview at DockYard, I found it nearly impossible to find material that would explain Ember.js, Phoenix, or Elixir at a level that someone who was tech-savvy but not a developer could grasp (e.g., me). As I have an acute dislike of that left-out, lost feeling that accompanies not fully understanding a topic, Iâve been absorbing as many new concepts as I can while also learning about DockYardâs approach to design and engineering. Whatâs really impressed me in my first month is the careful consideration about the long-term viability of the applications we create.

One can further see the foresight of DockYardâs leadership in the deliberate technology choices that we make. For example, at DockYard we specialize in single-page applications that have an average shelf-life of ten years. The average iOS application that you purchase in the App Store, also known as a ânative appâ due to its installation onto the phone itself, has a shelf life of one to two years. This disparity is due to a variety of factors, including that the software has to be compiled specifically for that operating system, the expense of marketing a native app in hopes of climbing the App Store ladder, and importantly, the backwards compatibility of the JavaScript framework we useâEmber.js. It is noteworthy that this backwards compatibility is what precludes the issues that native apps typically face when new versions are developed, as it is a good demonstration of the webâs design as a platform to endure. On the backend, we employ Phoenix and Elixir, Phoenix being the framework and Elixir being the language. Itâs ironic that the language we use for back end development is called âElixir,â because DockYardâs ingenuity originates from the pursuit of sustainable progress as opposed to the industryâs panacea.

The experience for employees is no different from DockYardâs approach to design and engineeringâtransparent and uncomplicated. The value placed on communication was echoed during my first meeting with our CEO, Brian. When asked if there was anything I should be sure to do as a new employee, he said: âIf youâre siloed in by yourself, thatâs seen as a failure here.â

Looking over the past thirty days, I think my biggest fear was feeling embarrassed about my lack of software know-how on top of being a new employee. That being said, my difference in background hasnât made me feel like the albatross of DockYard. Rather, what we have at DockYard is a unique kind of strength that is the result of the inclusion of people from different backgrounds and different skillsets. William Arthur Ward was quoted as saying, âWhen we seek to discover the best in others, we somehow bring out the best in ourselves,â and at least at DockYard, thatâs incredibly true.

Building a Space: Chart a Course

2016-05-06 00:00:00

DockYard has been growing over the past couple years. In 2015 we relocated to a larger space which resulted in a lot of creative opportunities internally. âBuilding a Spaceâ is a short series of articles about our successes, failures, and lessons learned from stepping outside our comfort zone and designing for a medium we admittedly are not experts in: our physical work environment.

Reception wall

Adjacent to our lobby, divided by our newly built rope wall, there is our reception area. The previous tenant painted the reception wall a vibrant red. It provided a brilliance to the environment that was visually stimulating and aligned with their brand colors. However, the walls were painted white prior to our move in, leaving us with a space that lacked character. Though white walls made the space feel âclean,â it also made it seem unfinished. The vision for our lobby area already relied heavily on a lighter palette so we knew this reception wall was an opportunity for creativity.

Challenges and constraints

Once a guest walked through our door, the first thing they would encounter was the big blank wall. There wasnât a lot of discussion surrounding fixtures for the wall, such as shelving, hanging artwork, or additional lighting. Instead we gravitated towards the idea of painting a mural. The question was, what do we paint? Before answering this question, there were items to consider. Much like the rope wall, the mural was dependent upon a few considerations.

First, our team wanted to be able to execute the mural on its own. This would lessen the time and budget needed, but it also provided the prospect of working on a project we donât often get the chance to. This resulted increased motivation and morale throughout the team. The cost of doing it ourselves equated to the time it would take us (about a week). We found that hiring an outside artist would likely put pressure on the budget or the deadline. Plus, weâre imaginative! Weâve all painted before! Surely we can rely on our own expertise, right? Weâre designers after all!

Second, we needed to make sure to maintain a realistic perspective on time and budget without sacrificing our ambition and passion for an excellent result. This meant paying close attention to the complexity of executing the piece on the wall. Again, much like the rope wall, we hadnât had much recent experience in works of this nature. Paint primer? Whatâs that? This didnât hinder our ambition, however. Instead it helped us focus on a single direction.

That direction was to hand letter the entire mural. We thought painting the mural in our DockYard blue provided a weight and simplicity that would counter the existing white space. This color also wouldnât interfere with the personality of the letterforms or the message in its entirety. The idea of a lettered piece allowed us to clearly display meaning to our new space, our guests and our employees. However, the meaning of the words would prove to be the most complex challenge of them all.

What to say

Initially our design team constructed a list of statements we envisioned on the reception wall. Most had to do with welcoming guests or providing inspirational words to entice potential clients. Some options were merely two words in length while others were entire quotes from some of historyâs great creative minds. We then consulted with others internally. We wanted the statement to be representative of not just designers but also developers, managers, and the entire companyâs shared vision. This is when a larger question surfaced.

What does this mean to us?

What are we trying to accomplish in this space? Does it align with the aspirations and desires of our guests? It turns out this wasnât just a greeting to be written on a wall. We were actually touching on a brand element, a mantra that could resonate with both our employees and our guests â anyone who entered the office. It had to be something motivating and thought-provoking. It had to represent not just our progress as a company but the journeys we take our guests, clients and partners on.

Chart a course

After much more discussion, we landed on âchart a course.â There are many reasons why we believe this is a fitting statement for the space.

Considering its position and audience it made sense to present something that is instantly digestible in the reception space. The statement has the ability to hold different meanings for different audiences, all resembling the idea of progression or forward thinking. Charting a course is what we do with clients and employees. We push their adventures and ideas forward, whether it be a career or a project.

Also, like the rope wall, it subtly hints at a nautical theme. Though the nautical theme isnât meant to be at the forefront of the entire office experience, it can be delightful to encounter our name, âDockYard,â upon entry and then extend the introduction with a corresponding statement such as âchart a courseâ. The name and the statement calmly connect the entire entry experience, which may help in a guestâs ability to recall our brand name.

How?

Where do we start? Sketches of course! We brainstormed multiple compositions, arrangements, letterform weights and styles. We played with decoration, shadows and highlights. Here are just a few:

After reviewing countless sketches and ideas, we discovered one which was particularly engaging to us. The fluidity and movement of the letterforms caught our attention. The sequence in size and weight helped guide the eye from start to finish. We werenât exactly sold on the arrangement, but it was a great starting point.

As with any project, we began to iterate. The piece changed with time for the better. We rearranged the words, and began to pronounce a specific brush lettering style. We used tracing paper, pencil and ink to continuously refine the letterforms until it satisfied our vision. We then finished refinements on screen.

The rest of the process was smooth sailing. We matched our DockYard blue with Behr paint professionals to arrive at a color named Secret Society. We used a projector to outline the piece on the reception wall. Lastly we spent hours painting, starting with the outlines and finishing with the fills.

What we ended up with was a beautiful hand lettered mural that has the potential to greet and engage anyone who enters our office. Itâs fluid, flexible and, most importantly, it retains a human personality. It doesnât feel manufactured. It doesnât speak arbitrarily. It represents the beginning of everything we stand for at DockYard.

Here's a look at more of the process:

Building a Space: Learning the Ropes

2016-05-04 00:00:00

Our challenge

Previously when someone entered our office, theyâd be greeted at the door and instructed to take a seat. Between them and the immediate seating area was this curved wall. Theyâd step over it. Theyâd step around it. Theyâd even ask us whether to step around it! It was a surprisingly large interruption in the initial experience of visiting the office.

When building a work space itâs important to ensure the space not only benefits the employee but also prospective clients (or really anyone visiting the office). When a guest visits a space there are a lot of moments that leave a lasting impression. Having a sign that directs guests where to go impacts a guestâs experience. Greeting guests with a smile as they enter the space impacts a guestâs experience. Having a space for guests to queue in while awaiting their meeting impacts a guestâs experience. So when a guest enters a space for the first time and is confronted by a curved wall-curb-thing, their experience is impacted, likely for worse if they donât know what it is theyâre being confronted with.

What is that?! Well, weâre not completely sure what it is, what it was or what its intended purpose might have been. We refer to it as a curved wall yet itâs barely a wall. This was the most immediate challenge. This small curved wall was one of the points in the greater project weâve tasked ourselves with: the client experience.

So how did we go about solving this challenge?

Use rope

Materials are plentiful in the life of a designer. Paints, inks, brushes, pens, pencils, stock, fabrics, devices, and so on. These are typical materials needed perhaps when one is exploring creative outlets, studying for a career in the arts, or merely going about their career as a designer. These are our familiar materials when solving a challenge. But how often do you see rope used to solve a design challenge?

Okay, thatâs not a shocking or specific question. Let me rephrase: how often do you see a group of web application designers using rope to solve a spatial design challenge?

Rope is potent with creative potential because of its malleability. Its ability to structure complex forms and functions was something we believed we could use to our advantage. After all, itâs been used since...forever, and in a seemingly infinite amount of scenarios. These characteristics proved beneficial to solving the challenge we were faced with.

Why?

We pursued this challenge with rope for three primary reasons. First, it provided a boundary between the reception area and the lobby area. This was important as it gave both our employees and our guests respective space to tend to their tasks. This also allowed for easy communication. With a traditional wall or barrier, one party or the other would have to physically move to converse with or greet the other. Instead, a rope wall provides a subtle sense of privacy while still allowing for interaction between reception and guests at any given time. It effectively solidified a comfortable space for simply waiting. No more guests wandering onto the floor. No more need for reception to reassure the space as a waiting area.

Secondly, it was achievable with the tools at our disposal and the ambition of our design team. We believed that it was completely possible for us to build this wall on our own even though none of us had experience in building such a structure. We saved a lot of money purchasing and installing materials ourselves and by using materials we already owned. We also wasted no time as we were able to complete the project on our own schedule with time weâd allot to it.

Lastly, it speaks to our brand. Being a raw manila rope, itâs physical qualities suggest a nautical theme. Aesthetically, the ropeâs texture and color complement other items in the space, fitting the overall vision of our DockYard lobby area perfectly. We also searched for anchoring hardware that would supplement a subtle nautical theme. This led us to choosing eye screws as our anchor hardware. Theyâre unobtrusive, visually satisfying when sequentially ordered, and can be found throughout nautical products and scenarios.

How?

We approached the project in a way very similar to how we approach any of our web application projects: by researching, planning, prototyping, and executing.

We first gathered inspiration from a variety of sources. We found everything from loosely hanging rope acting as entryway drapes, to beautifully anchored, tightly positioned lines of rope acting as entire room dividers. From what we found, we knew we wanted our rope wall to use anchored rope and not to be too tightly arranged. This required a bit of prototyping. We utilized string and tape to measure and mock the arrangement of the rope.

We then researched how to anchor the rope. As we weighed our options a few considerations became clear. Each vertical piece of rope needed to be measured close enough to one another to approximate the curve of the wall. We also realized we couldnât anchor individual lines of rope because it would require labor and resources we didnât budget for. These insights informed two key decisions. First, each vertically positioned piece of rope needed to be within 4-6 inches from one another which happened to align with our prototype measurements. Second, we needed to use one piece of rope to thread the entire wall.

The result? A slightly angled, âtooth shapedâ pattern we love. Itâs clean cut, but itâs movement provides a dynamic unlike one weâve come across in terms of rope walls. In more ways than one it not only achieves the goals we began with but also provides a variety of interesting perspectives to a space previously in search of an identity.

A closer look at the process

Phoenix Tips and Tricks

2016-05-02 00:00:00

As newcomers get up and running quickly with Phoenix, we see folks hit a few common issues that they can cleanly solve with a few simple tips.

Override `action/2` in your controllers

Often times, you'll find yourself repeatedly needing to access connection information in your controller actions, such as conn.assigns.current_user or similarly reaching deeply into nested connection information. This can become tedious and obscures the code. While we could extract the lookup to a function, such as current_user(conn), then we are needlessly performing extra map access when we only need to do the lookup a single time. There's a better way.

Phoenix controllers all contain an action/2 plug, which is called last in the controller pipeline. This plug is responsible for calling the function specified in the route, but Phoenix makes it overridable so you can customize your controller actions. For example, imagine the following controller:

  
  defmodule MyApp.PostController do
  use MyApp.Web, :controller

  def show(conn, %{"id" => id}) do
    {:ok, post} = Blog.get_post_for_user(conn.assigns.current_user, id)
    render(conn, "show.html", owner: conn.assigns.current_user, post: post)
  end

  def create(conn, %{"post" => post_params}) do
    {:ok, post} = Blog.publish_post(conn.assigns.current_user, post_params)
    redirect(conn, to: user_post_path(conn, conn.assigns.current_user, post)
  end
end

Not terrible, but the repeated conn.assigns.current_user access gets tiresome and obscures what we care about, namely the current_user. Let's override action/2 to see how we can clean this up:

  
  defmodule MyApp.PostController do
  use MyApp.Web, :controller

  def action(conn, _) do
    args = [conn, conn.params, conn.assigns[:current_user] || :guest]
    apply(__MODULE__, action_name(conn), args)
  end

  def show(conn, %{"id" => id}, current_user) do
    {:ok, post} = Blog.get_post_for_user(current_user, id)
    render(conn, "show.html", owner: current_user, post: post)
  end

  def create(conn, %{"post" => post_params}, current_user) do
    {:ok, post} = Blog.publish_post(current_user, post_params)
    redirect(conn, to: user_post_path(conn, current_user, post)
  end
end

Much nicer. We simply overrode action/2 on the controller, and modified the arities of our controller actions to include a new third argument, the current_user, or :guest if we aren't enforcing authentication. If we want to apply this to multiple controllers, we can extract it to a MyApp.Controller module:

  
  defmodule MyApp.Controller do
  defmacro __using__(_) do
    quote do
      def action(conn, _), do: MyApp.Controller.__action__(__MODULE__, conn)
      defoverridable action: 2
    end
  end

  def __action__(controller, conn) do
    args = [conn, conn.params, conn.assigns[:current_user] || :guest]
    apply(controller, Phoenix.Controller.action_name(conn), args)
  end
end

Now any controller that wants to use our modified actions can use MyApp.Controller on a case-by-case basis. We also made sure to make action/2 overridable again to allow caller's downstream to customize their own behavior.

Rendering the `ErrorView` directly

Most folks use their ErrorView to handle rendering exceptions after they are caught and translated to the proper status code, such as a Ecto.NoResultsError rendering the "404.html" template or a Phoenix.ActionClauseError rendering the "400.html" template. What many miss is the fact that the ErrorView is just like any other view. It can and should be called directly to render responses for your error cases rather than relying on exceptions for all error possibilities. For example, imagine handling the error cases for our PostController in the previous example:

  
  def create(conn, %{"post" => post_params}, current_user) do
  with {:ok, post} <- Blog.publish_post(current_user, post_params) do
    redirect(conn, to: user_post_path(conn, current_user, post)
  else
    {:error, %Ecto.Changeset{} = changeset} -> render(conn, "edit.html", changeset: changeset)
    {:error, :unauthorized} ->
      conn
      |> put_status(401)
      |> render(ErrorView, :"401", message: "You are not authorized to publish posts")
    {:error, :rate_limited} ->
      conn
      |> put_status(429)
      |> render(ErrorView, :"429", message: "You have exceeded the max allowed posts for today")
  end
end

Here we've used the Elixir 1.3 with/else expressions. Note how we are able to succinctly send the 401 and 429 responses by directly rendering our ErrorView. We also passed the template name as an atom, such as :"401" so our template will be rendered based on the accept headers such as "401.json" or "404.html".

Avoid Task.async if you don't plan to Task.await

Elixir Tasks are great for cheap concurrency and parallelizing bits of work, but we often see Task.async used incorrectly. The most important thing to realize is that the caller is linked to the task. This means that if the task crashes, the caller does as well, and vice-versa. For example, the following code is perfectly fine because we await both tasks and we expect to crash if they fail:

  
  def create(conn, %{"access_code" => code}) do
  facebook = Task.async(fn -> Facebook.get_token(code) end)
  twitter  = Task.async(fn -> Twitter.get_token(code) end)

  render(conn, "create.json", facebook: Task.await(facebook),
                              twitter: Task.await(twitter))
end

In this case, we want to fetch a token from Facebook and Twitter, and we can do this work in parallel since the tasks are not coupled in any way. When rendering our JSON response for the client, we can await both tasks and send the response back. This use of Task.async and Task.await is just fine, but now imagine another case where we want to fire off a quick task and immediately respond to the client.

  
  def delete(conn, _, current_user) do
  {:ok, user} = Accounts.cancel_account(current_user)
  Task.async(fn -> Audits.alert_cancellation_notice(user) end)

  conn
  |> signout()
  |> put_flash(:info, "So sorry to see you go!")
  |> redirect(to: "/")
end

In this case, we want to notify our staff about an account cancellation, say by sending an email, but we don't want the client to wait on this particular work. It might feel natural to use Task.async here, but since we aren't awaiting the result and the client isn't concerned about its success, we have an issue. First, we are linked to the caller, so any abnormal exit on either side will crash the other. The client could get a 500 error after their account has been canceled and not be sure if their operation was successful. Likewise, our staff notice could be brought down by an error when sending the response, preventing our staff being alerted of the completed event. We can use Task.Supervisor and its async_nolink to achieve an offloaded process that is isolated under its own supervision tree.

First, we'd need to add our own Task.Supervisor, to our supervision tree, in lib/my_app.ex:

  
  children = [
  ...,
  supervisor(Task.Supervisor, [[name: MyApp.TaskSupervisor]])
]

Next, we can now offload the task to our supervisor. We'll also use the async_nolink function to isolate the task from the caller:

  
  def delete(conn, _, current_user) do
  {:ok, user} = Accounts.cancel_account(current_user)
  Task.Supervisor.async_nolink(MyApp.TaskSupervisor, fn ->
    Audits.alert_cancellation_notice(user) end)
  end)

  conn
  |> signout()
  |> put_flash(:info, "So sorry to see you go!")
  |> redirect(to: "/")
end

Now our task is properly offloaded to its own supervisor who will take care of any failures and proper logging. Likewise, any crash in the task, or the controller, won't affect the other.

With these tips, you'll keep your code clean and to the point, and isolated when required.

EmberConf 2016 Recap

2016-04-29 00:00:00

Last year's EmberConf was a conference packed with exciting new things. The Ember 2.0 release was closing in. A lot of 1.0s of big Ember projects would be shipped soon. FastBoot was announced and so was Glimmer. Our new rendering engine got on par with React's blazingly fast rendering engine. There was a lot of hype and excitement.

This year the atmosphere of the conference was different. Not a bad different per se, but different. This year felt as if we had just completed major goals set out at last year's conference, and that we were now on track to keep leveling up those achievements in the foreseeable future.

For example, Glimmer II drastically improves upon Glimmer I. The 60fps rendering demo was mind blowing, but it felt different from seeing for the first time how comically bad the rendering engine was before Glimmer 1.0 and then see it run as fast as React's rendering engine. It was already expected that Glimmer II would improve upon Glimmer I.

There is one big new movement this year. It is the movement of Progressive Web Apps (PWA). FastBoot 1.0 will be released soon and there are a bunch of other exciting projects putting effort into pairing up Ember with ServiceWorkers and other PWA tools that (recently) have been added to (mobile) browsers.

Because of these developments I would like to dub this year:

"Year of Progress and Progressive Web Apps".

There is another thing I want to mention: Living Styleguides. Chris LoPresto gave a talk about this. I did not yet know of this movement until Luke Melia told me I should go see Chris' talk. It was supposed to be awesome. I'm glad I followed Luke's advice and went to see Chris' talk. You may think that styleguides are for designers, but the way these styleguides are built will actually help developers architect better components.

I had a really good time at EmberConf 2016. I'm excited to start trying out Living Styleguides at DockYard. We're already using FastBoot and we're also actively experimenting with Progressive Web App technology.

I look forward to another round of talks that show how the Ember ecosystem has been improved and solidified in 2017. Also to meet all the wonderful people I've met this year again.

Choosing a Strategy + Design Partner

2016-04-26 00:00:00

Image Credit: AMC

Youâre interviewing candidates for an opening on your team. Youâre torn between two finalists. Each has deep skills and experience, comes with solid references, and would increase diversity. In both a subjective or objective evaluation, theyâd be equal.

How can you make such an important decision, without resorting to a coin flip?

Choosing a partner for strategy and design of web applications is a lot like hiring that new team member. Every agency youâll meet will tell you about their services and âThe Process.â Theyâll share a cloud of client logos and case studies with slick creative and impressive results. Their offices will be way more hip than yours. Youâll be shown a photo of a designer pointing to a wall of design artifacts.

With every agency pitching what can feel like the same experience and capabilities, how do you choose?

The Client Should Always Come First

âA gossip talks about other people. A bore talks about himself. A brilliant conversationalist talks to you about yourself.â

âUnknown

In a similar vein, an agency that understands the importance of objectives in design will move quickly from talking about their reputation, to a deeper conversation about you and your business goals. Theyâll get excited about what could be accomplished together.

Do the memebers of the team seem interested in listening to you, and learning from you? Are they focused on trult understanding the problems, rather than jumping to their favored solutions?

Are they asking deep questions about your goals? Your past successes and failures? Your personal situation? They should regard their job as not only to deliver what you want and need but also to make you look good.

Become Comfortable by Being Uncomfortable

âIf it scares you, it might be a good thing to try.â

âSeth Godin

As you answer the agencyâs questions, also pay attention to the kinds of questions they ask. Are they making you uncomfortable with some of those questions? Thatâs OK.

Sometimes the most important questions are uncomfortable because they challenge some sacred-cow assumptions. They may force you to reconsider things that really need fixing. Being hopeful that stuff will work out is the opposite of strategy. Itâs always better to know â or at least to be less uncertain.

Strategic designers routinely chart a course through uncertain seas. They should be comfortable being uncomfortable and they should help you feel the same way. Rather than being taken aback, take a shot at answering those questions.

Direct vs. Indirect Experience

âExperience is simply the name we give our mistakes.â

âOscar Wilde

A claim of âexperienceâ is no guarantee of a favorable outcome. Experience is a set of responses to particular business problems (not yours), in particular contexts (not yours, either). Thatâs why duplicating a successful companyâs business model or solution rarely works out. Despite what best-selling business books seem to suggest, thereâs no single recipe for success. Every challenge is fresh, and every solution begins with a blank page.

If an agency claims direct experience in your industry, ask to also see examples of how they solved problems like yours for clients in other industries. Have they worked through problems of similar scale or complexity?

There are scenarios where specialized experience does matter. This is particularly true in industries that are highly-regulated or highly-competitive. If having specific domain knowledge on your project is important, discuss that. For example, if youâre a pharma brand with a âblack box warningâ on your product, youâd ask about their understanding of the specific FDA rules.

In some cases, an agencyâs lack of direct experience can be an asset rather than a liability. Sometimes distance makes things clearer. This is especially true for an industry or company that tends to be a technology laggard. Expect to hear pushback on phrases like, âWeâve always done it that wayâ or âThat would never work here.â Itâs likely theyâve met similar resistance elsewhere â and overcome it.

Experts Are Made, Not Born

âAn expert is someone who tells you why you canât do something.â

âSir Alec Issigonis, designer of the Morris Mini (predecessor to the Mini Cooper)

An agency should be able to show how fast they can learn your business. Even in the earliest meetings, they should bring insights and a pain hypothesis. Theyâre outsiders to your private domain, so the attempt means more than getting the details right.

Look for evidence for how an agency leverages âabductive reasoning,â which is the seemingly magical ability to synthesize what theyâve learned into actionable insights and design ideas. They should tap both personal and institutional knowledge and apply it to new learnings about your circumstances.

A rich set of design-thinking tools and methods will enable the agency to wrap their heads around the unfamiliar. Ask them not just which problems theyâve solved but also how they learn and share knowledge.

Itâs Decision Time

âTrust yourself, you know more than you think you think you do.â

âDr. Benjamin Spock

Like hiring the right team member, finding the right agency partner is as much about who they are as what they know. To ensure a good fit, the agency should care as much about figuring out if youâre a good client for them, as you do figuring out if theyâre a good agency for you.

Donât look for an agency who claims they can solve all your problems. Look for one who will face them with you.

A learning experience in web application design (part 2 of 2)

2016-04-20 00:00:00

In my last post, I described Sprout Pass, a speculative project for a web application that would deliver fresh local produce right to oneâs doorstep. Sprout Pass is inspired and informed by the idea of community-supported agriculture, also known as farm sharing. Sprout Pass would facilitate orders and delivery between users and their local farmers.

Users need a UI they can trust and enjoy, especially for a perishable product like produce. Coming to DockYard from a background in print design, I wanted to explore how an interface provides user support. An interface communicates with a user through feedback and component states, which have the potential to build trust and positive experiences. I consolidated my exploration, planning, and research to focus on the visual UI design. To cover my bases, I designed component screens with a broad range of associated states.

My first consideration for the app's visual design was its color selection. Produce delivery applications arenât exactly a flooded market, so while green might be an âobviousâ choice, it was a viable branding option. I chose a positive green thatâs closer to blue than yellow to avoid an overly acidic aesthetic. For the typography, I relied on the humanist sans serif Whitney, because the heavier weights of this typeface have an honest and friendly tone that establish the personality of Sprout Pass. Let's go through a few examples of different states an interface can be in.

Before a user does anything

Every introduction has the potential to start a new, meaningful relationship. Before subscribing, a user must know what Sprout Pass can do to enhance their quality of life. The introduction for Sprout Pass allows the user to swipe through as much of the content as they want while always providing a path to sign up or login.

Background photo credit: Sven Scheuermeier

Confirmation & errors

Confirmations and errors will dynamically appear next to input fields, to reassure the user of their progress as they work on the form. For questions that require more thought on the user's part, inline validation messages can help people complete web forms faster and with less effort. If youâd like a more detailed reference for when to show inline validation, Luke Wroblewski tested inline validation against the submit-and-refresh model.

For this sign up, both input states use color and icons to identify and distinguish themselves without being overly dramatic. The brand color is a saturated green, which correlates with correct and positive states. The submit button would turn this color when every validation has been satisfied.

Error states are a necessary part of any application, but the language and form of them is often overlooked. The brandâs personality should manifest itself through all bits of copy, even the error states. Negativity and blame in error states doesnât contribute to a successful application experience. For the invalid email example, Sprout Pass takes the blame for the error and offers a solution. Model applications like MailChimp and Tumblr maintain a charming personality while doing this as well.

Empty state | An existing component with no data

New users typically love to poke around before making any purchases or commitments, but Sprout Pass initially wonât have any data to fill its various components. Engaging and informative empty states support this behavior, and can lead to greater customer retention. Other instances of empty states can exist when a user clears the data or an error occurs. When a new user opens Sprout Pass, there wonât be much to show them at first, but they can still be engaged. A successful empty state will delight, educate, and motivate the user to add information and interact with the app. In this empty state, a bit of copy identifies what will eventually exist, and the vibrant green button is used as direction.

Background photo credit: Matt Benson

Done | Ensuring a successful transaction

To reassure the user of their order completion, the brand color overtakes the screen for a positive order confirmation. The color and icon, consistent with the completed state, combine to substantiate the order confirmation. This screen also prompts the user with two paths forward. This keeps the user engaged while the application is in between waiting for and scheduling packages.

Ideal state

The completed package screen is where most users will become more familiar with the application. They will see this section for the longest amount of time, unlike some of the other states that will be viewed only for a few moments. The selection process and empty state have prepared the user for this level of complexity. Because the primary objective of this product is a delivery service, the status of the next delivery is most prominent. This screen updates to track delivery progress, and the editing function becomes inactive 48 hours before deliveries.

Too much | Managing full data sets

When the past orders history exceeds the set limit of five items, this state identifies quantity and provides access to the full dataset. The user is going to want to know how much more history there is available to them. If the quantity and navigation of your data isn't intuitive, a too much state can be very frustrating. This Sprout Pass content is condensed and limited by time, so the full history does not require pagination.

Final thoughts

Exploring Sprout Pass helped me develop a familiarity with interface states that I admittedly would have overlooked. After understanding the value and characteristics for each state, I was able to apply my knowledge of visual systems and hierarchy. Every state of a web application component is integral to a userâs positive experience and should be designed with intention. Thoughtfully designed interface states will reduce the risk of confusing or surprising a user, and all of these states work together to make a streamlined experience.

Is it time to call a designer?

2016-04-19 00:00:00

There is an old fable about a philosopher. A baby was born, and the parents presented the baby to the philosopher in their city at the age of just one month. They apologized for being so early, and asked for advice on how to best plan for an education so the baby would grow up as a proper citizen. To which the philosopher replied - âYouâre not too early. You are ten months late.â

I could not track down a proper source for this - most likely itâs an ancient Confucian fable. But I always come back to it when I plan and schedule design work. The moral of it keeps coming to mind: âyou thought it was too early, but itâs best to start even earlier.â

Why we think âitâs too earlyâ to add design

In fact, many people have the understanding of what design can do for business based on a historical truth. The value (and timing) for design seems closely tied to the idea of decoration and the value it could add to mass produced consumer products. This understanding is rooted in the late 1800s, when adding decorative elements to mass produced consumer goods made them more attractive to the public. The decoration helped increase sales from what people practically needed and drove consumer demand based on a desire for updated styles.

Mass production allowed for âdesignedâ (but actually decorated) consumer products to be widely available at the turn of the last century.

The other jobs of design

I often hear a similar âdecorativeâ understanding of design when I talk to people about what my job is today. At the recent MIT Ideas Global Challenge, hosted at the Media Lab, I talked to several of the teams about their goals, and UX design. All the teams were very enthusiastic, but in every conversation I heard the phrase âonce we finish X technology, weâll be ready for designâ¦â This phrase reveals an assumption that design is something you might apply on top of an existing product or service, once itâs almost finished.

MIT Ideas Global Challenge presentations event in April 2016

The way to think about what design can do for business, in fact, is almost exactly the opposite. Applying design - specifically, design thinking - at the inception of a project will allow for the greatest impact.

Why start with design

Design today is well adapted to dealing with unknowns, considering the big picture, and proposing a way forward. You can name specific steps, such as design research, user experience design, and user story development - or keep everything under the bigger umbrella of âdesignâ. But it is the ability to start early (before everything is known) and move forward in an iterative manner (by testing and improving) that makes design impactful at the early stages of a product or service.

Business leaders are well aware of the value visual design can bring to their products. But strategic design, applied early in the life of a project, is often a missed opportunity. To get the best value from the latest design practices, consider it early, and bring a designer to the table at the first stages of product strategy.

For a deeper look into the relationship between design & business, check out John Maedaâs Design in Tech report. In it, he presents compelling proof of the value design brings, and predicts the top three directions in which design will experience the most growth over the next year.

Ember: Declarative Templating with Composable Helpers

2016-04-18 00:00:00

Previously, I mentioned that Ember's new Helper implementation landed in 1.13. In my opinion, helpers are one of the most useful, yet least talked about features in Ember.

In my EmberConf 2016 talk (video) on Idiomatic Ember, I spoke about helpers in detail, showing how they can be used to power up and essentially extend Handlebars with custom functionality. These helpers can then be used to allow declarative templating - a style of templating by composing actions, and giving templates more responsibility with regards to presentational logic.

Together with fellow DockYarder Marten Schilstra, we've created the ember-composable-helpers addon. It's a package of declarative helpers that lend themselves naturally for composition, and using it can help remove boilerplate code in your app. You can install it today with:

  
  ember install ember-composable-helpers

One of my favorite helpers in the addon is the pipe helper (and its closure action cousin, pipe-action). This lets you declaratively compose actions in your template, instead of creating many variants in your Component:

  
  {{perform-calculation
    add=(action "add")
    subtract=(action "subtract")
    multiply=(action "multiply")
    square=(action "square")
}}

  
  {{! perform-calculation/template.hbs }}
<button {{action (pipe add square) 2 4}}>Should be 36</button>
<button {{action (pipe subtract square) 4 2}}>Should be 4</button>
<button {{action (pipe multiply square) 5 5}}>Should be 625</button>

This pipe helper was inspired by Elixir's pipe operator (|>), which lets you write the following:

  
  A(B(C(D(E), "F"), "G"), "H")

As a series of data transforms:

  
  E
|> D()
|> C("F")
|> B("G")
|> A("H")

Using the pipe operator, we can naturally express how E is passed to the D function, then the return value of that function is passed into C as its first argument, and so on. I think we can agree that the pipe version is a lot easier to read!

If only you knew the power of the Helper

You can think of a helper as a primitive KeyWord construct used by Ember and HTMLBars to extend the ordinary expressions provided by Handlebars. At its most basic level, the Handlebars library is responsible for compiling the hbs language down to HTML:

  
  <p>{{myText}}</p>
<!-- compiles down to: -->
<p>Hello world!</p>

Ember and HTMLBars then builds on top of this, adding useful keywords like action, mut, get, and hash. In fact, all the familiar keywords you've been using (everything from each to component) are actually HTMLBars helpers under the hood!

Ember Helpers operate at a higher level compared to HTMLBars helpers, but can also be used as a way to let you create new keywords in Ember, effectively allowing you to extend templating with custom behavior.

It depends

More experienced or conservative developers might see this as a red flag: while making this framework construct available to end-users is useful, it can also open up potential for abuse.

For example, in Elixir, macros can be used to extend the language, but aren't recommended unless you really need to. In fact, this has been informally codified in the excellent Metaprogramming Elixir book by Chris McCord â "Rule 1: Don't Write Macros".

Fortunately, helpers aren't quite as powerful as Elixir macros, and play an important role in the Ember programming model. Unlike a macro, which lets you reach down to the AST, using an Ember helper to extend presentational logic is OK as long as we don't abuse it, and that distinction is where experience comes into play. So use helpers responsibly.

Get your logic off my lawn

Some people may feel uneasy using addons containing helpers because of the misconception that it introduces too much logic in their templates, and that they prefer to keep their templates logic-free.

As a best practice, we should strive not to have complicated logic in our templates, and when your sub-expression looks like this:

  
  {{#unless (or (and (gte value 0) (lt value 0.0001))
              (and (lt value 0) (not allowNegativeResults)))}}
  ...
{{/unless}}

It's a sign that you're better off using a computed property.

On the other hand, keeping your templates 100% logic-free is really hard â you're likely already using a logical helper like if/else or unless. It can be easy to lose sight of the fact that the amount of logic in your template lies on a spectrum, and is not a strict dichotomy.

Back to the future

ember-composable-helpers doesn't significantly increase the amount of logic in your templates â in fact, if used correctly, it encapsulates presentational logic within these helpers, and in many cases can help you eliminate now redundant code in your Components or Controllers.

For example, you might have written something like this in your app:

  
  import Ember from 'ember';

const { 
  Component, 
  computed: { filterBy, setDiff }, 
  set 
} = Ember;

export default Component.extend({
  activeEmployees: filterBy('employees', 'isActive'),
  inactiveEmployees: setDiff('employees', 'activeEmployees')
});

It's quite common to have "intermediary" CPs in your Component that you then use in some other CP. Using ember-composable-helpers lets you compose that directly in the template, where the intent becomes incredibly clear:

  
  <h2>Active Employees</h2>
{{#each (filter-by "isActive" engineers) as |employee|}}
  {{employee.name}} is active!
{{/each}}

<h2>Inactive Employees</h2>
{{#each (reject-by "isActive" engineers) as |employee|}}
  {{employee.name}} is inactive!
{{/each}}

You can think of a composable helper as a kind of computed property macro that you can use and compose directly in your template. And since you can compose sub-expressions in Ember, these can become powerful constructs to reduce boilerplate code in your application.

With that said, remember not to get too carried away with deeply nesting helpers!

Exercise best judgment

As with all programming tools, it's important to exercise best judgment and use them responsibly.

Just because you can do something doesn't mean that you should.

A well written view layer means that templates should be as declarative as possible (communicate intent clearly), and not that we should avoid logic altogether. That said, we're not advocating for moving all your logic into your template â again, it's not a dichotomy, but a spectrum.

If you'd like to see how the addon is being used, Katherin Siracusa wrote an excellent blog post about how she uses ember-composable-helpers at AlphaSights:

This pattern, of performing some significant, data-changing action and subsequently performing a more ancillary, short-term state-like action, keeps arising in our application. Using [...] composable-helpers, we can take care of this in a fairly straightforward way, without much duplication and without having to worry about unintended side effects.

You can also join in the discussion on our Slack channel #e-composable-helpers.

As always, thanks for reading!

TIL: Elixir can pattern match at multiple depths in a single statement

2016-04-13 00:00:00

One of Elixir's greatest assets is its pattern matching. If you have ever used Elixir, you have probably had the pleasure of writing something like:

  
  def background_check(%{manager: employee} = company) do
  %{name: full_name} = employee

  from(c in Criminals,
  where: c.full_name == ^full_name,
  select: c)
  |> Repo.one
  |> case do
    nil -> congratulate(employee)
    criminal -> notify(company)
  end
end

Here we are assigning the entire parameter map to a variable called company, and pattern matching to get the employee we want to do a background check on. We need to query our Criminals database table for a criminal with the same name as our employee. To do so, we first have to grab the name property off the employee object.

Well, today I learned, that you can have multiple matches in a single statement! With this newly acquired knowledge, we can simplify our background_check() function definition:

  
  def check_company(%{manager: %{name: full_name} = employee} = company) do
  from(c in Criminals,
  where: c.full_name == ^full_name,
  select: c)
  |> Repo.one()
  |> case do
    nil -> congratulate(employee)
    criminal -> notify(company)
  end
end

Now we can pattern match to get the employee's full_name, while also assigning the entire map under the manager key to the variable employee, as we did before.

Hopefully, you learned something too! Enjoy.

A Match Made In Heaven

2016-04-10 00:00:00

Unless you've been living in a bubble, I'm sure you've all heard of ember-concurrency. It's been all over Twitter; it's been brought up on Ember Weekend; it was even mentioned during this year's EmberConf keynote.

This past February, Alex Matchneer gave us a walkthrough of his addon at the monthly Boston Ember.js Meetup. There is ample documentation and examples on the website already, so I will forgo the details, but the TL;DR is that ember-concurrency offers an elegant way to write asynchronous, cancelable tasks in an Ember app. It also leverages the power of generators so we can adopt a more readable, synchronous-like syntax.

I was unfortunately way too busy working on my talk for EmberConf at the time, that I didn't really get a chance to take the addon for a spin. But it was clear in my mind that the problems the addon addresses were the exact type of problems we had to solve in more traditional ways a year ago, as part of a client project.

It's a project I have brought up in the past when demonstrating the use of Ember in a NW.js-powered desktop app, but it just happens to also be a perfect candidate for ember-concurrency.

Did we find ourselves having to invoke Ember.run.cancel to cancel previously scheduled tasks? Yes, indeed.
Did we have to clean up asynchronous tasks in willDestroy hooks? Absolutely.
Did we have to write guards to prevent an operation from running concurrently? For sure!

One of the goals of the app was to provide indoor cycling instructors with a better interface for managing and running a class, including a built-in roster and classroom map of which bikes riders had reserved, tools to start a class, start a race, view real-time stats and ranking, etc.

While we wrapped up the project a while ago, I felt compelled to recreate the elements that could have benefited from ember-concurrency in this (highly) simplified demo app.

To give a bit of context, a class runs for a specific amount of time, e.g. 1 hour. During that time, students can ride at their own pace. At various times during the session, the instructor may initiate a race that lasts 30, 45, or 60 sec. Racing occurs numerous times during a class, and one critical piece of information the app needs to convey to the instructor is how much time is left within any given race, as well as how much time is left before the end of a class. You don't want to accidentally start a 60 sec race if there's only 10 sec left of class time!

Let's take a look at the more traditional approach of managing a race timer with Ember.run.later.

We have a race-panel component that holds the race buttons for various race duration options. When a race button is pressed, the race-panel component's startRace action is invoked with the duration specified by the button itself (in seconds):

  
  // In app/components/race-panel/component.js
actions: {
  startRace(duration) {
    if (!get(this, 'isRaceInProgress')) {
      this.startTimer(duration);
    }
  }
}

The first thing we do is check whether a race is already in progress, as there can only be at most one active at any given time.

If the way is clear, we start the race timer. The main function here is updateTimer, which calls itself every second, each time decrementing the race counter, until we reach 0.

  
  isRaceInProgress: computed.gt('countdown', 0),

startTimer(duration) {
  set(this, 'countdown', duration);
  this.updateTimer();
},

updateTimer() {
  let timerId = run.later(() => {
    let countdown = this.decrementProperty('countdown');
    if (countdown > 0) {
      this.updateTimer();
    } else {
      this.stopTimer();
    }
  }, 1000);

  set(this, 'timerId', timerId);
},

stopTimer() {
  set(this, 'timerId', null);
},

The reason we need to store the ID of the operation started by run.later is so we can cancel it should the user navigate away (e.g. by aborting the class rather than let it run to completion). This means we also need to implement a willDestroy hook to do the clean up work:

  
  willDestroy() {
  let timerId = get(this, 'timerId');
  if (timerId) {
    run.cancel(timerId);
  }
},

The value assigned to the countdown property is used by the component to display a race timer in the instructor's UI.

This isn't rocket science, but if you consider the fact that we also need to disable race buttons depending on whether a race is already in progress, or disable specific race duration options depending on how much time is left in a class, all while keeping track of the class overall progress and possible early termination, this does end up being quite a lot of timer-related code to get right and maintain.

With ember-concurrency, the above can be simplified to just the following:

  
  raceTask: task(function* (duration) {
  let countdown = set(this, 'countdown', duration);
  while (countdown > 0) {
    yield timeout(1000);
    countdown = this.decrementProperty('countdown');
  }
}).drop()

The generator function allows us to write asynchronous code that feels synchronous, while the special task function lets us adhere to the idea of structured concurrency.

We can instantiate the race task directly from the template, using the {{perform}} helper that the addon provides. In addition, figuring out if a race is in progress is just a matter of checking the value of raceTask.isRunning.

  
  {{#each raceDurations as |duration|}}
  <button disabled={{or raceTask.isRunning (gte duration classTimeRemaining)}}
      onclick={{perform raceTask duration}}>{{duration}}</button>
{{/each}}

Even though we are disabling the race buttons when a race is already in progress, having the option to use the .drop() task modifier in the component code guards us further against concurrent races in a more elegant way than if we had to do so via an internal property. The modifier ensures that future requests to run the race task will be dropped until the current one completes.

The best part, however, is that we no longer need those willDestroy hooks as ember-concurrency automatically manages the lifecycle of these tasks for us, so we can rest at ease knowing that when our component is destroyed, all tasks will be cancelled and cleaned up as well.

The result is a clear reduction in boilerplate code to manage asynchronous tasks and timers, as well as code that is much more readable overall. In short, I wish this had existed a year ago when we were still active on the project, but these sorts of asynchronous operations are common enough that they're sure to come up again. They don't have to necessarily deal with time-related events, as you can yield promises that hit some backend API as well, and let ember-concurrency handle the trickier concurrency or task cancellation logic.

Some user involvement is good for design. But is more better?

2016-04-05 00:00:00

In a typical UX project, user involvement begins early on, as part of research. This leads to insights, which lead to a concise definition of the design problem(s) we're tasked with solving. Then we disappear and transmogrify our inputs into concepts. The users return for usability testing. Their collective feedback informs the next iteration of the concept.

A movement to keep users around for the entire design process has been gaining traction. Whether it's called "collaborative design," or "co-creation," or "generative design," the starting premise is that everyone, users included, is capable of being a designer. Stick figures welcome.

I recently attended a local design thinking meetup which sought to introduce us to co-creation by having us each design a new service for ordering pizza or sushi. First weâd each sketch something using Sharpies and Post-Its. Then weâd engage one our peers as a âuserâ to interpret and edit what they saw. We repeated this 3 times, with each user moving the design forward from the point where the last left off.

It was a lot of fun and highly engaging. The reactions from the participants were overwhelmingly enthusiastic. But I was surprised to find that the end result was a room full of nearly identical designs â both to each other and to what already exists in the marketplace. All were some variation of: 1 Select a location, 2 View the menu, 3 Order something, 4 Check out, 5 Thank you.

With a design brief that was akin to, "Design a new car â anything you want," we ended up with a lot full of lookalike beige sedans. No bold hypercars. No original go-anywhere vehicles that could hop a chasm if commanded to do so. This outcome was especially concerning given we weren't "typical users" â we were mostly "designers." So, what happened?

Image Credit: KIA Media

Donât Facilitate â Collaborate

We were asked to adopt a facilitator's mindset when co-designing. This meant that we pushed and prodded our users into both finding problems and fixing them with design.

Users are experts in identifying that problems exist. This is why usability testing works so well. But their ability to articulate the cause(s) of problems and designing solutions varies with their expertise, experience, and aptitudes. A user can tell you they hear a rattle when making a left turn, but unless they have experience in auto mechanics, they likely canât tell you whatâs causing the noise, or make the repair.

Image Credit: Funzy Pics

Finding problems and fixing problems are not the same activity. While simple problems have an obvious cause and effect, most problems faced by designers are complicated or complex â their causes and/or solutions are not obvious and require further analysis or expertise. Homer Simpson can bang together a doghouse from a bunch of boards, but only skilled architects, engineers and builders can erect a skyscraper and expect it to stand.

Image Credit: frinkiac.com

Tips for Designers:

Design with the user as an equal partner. Think through problems and solutions together, allowing both of your perspectives and expertise (them as user, you as designer) to inform where things go.
Put faith in what users identify as problems. Even if all they can articulate is that âsomething doesnât feel right,â chances are, theyâve stumbled upon something that needs to be thought through.
Encourage multiple cause hypotheses and multiple solutions by coaching the user through the problem solving process: What do you think is the cause of that problem? What else could it be? What else? Whatâs a solution for it? Whatâs another? And another?
Pool the ideas generated from co-creation activities with other possible ideas conceived separately by designers; downselect from there. Designers have an obligation to propose the best possible solutions. It is important to include ideas from designers who know many design patterns (and when to use them), understand context and behavior, and give equal weight to what's left unsaid or undone.

Use the Appropriate Concept Fidelity

The ground rules for the collaborative part of the pizza/sushi activity were to use Socratic questioning, similar to how we do it in usability testing: the facilitator should answer âWhat is this?â with "What do you think it is?" As a result, none of my users were able to decipher this image:

It was supposed to be a livestream of a sushi chef making your sushi, in an attempt to bring the sushi-bar experience home.

Because the method we used called for real-time editing, one of the potential differentiating features was edited-out solely because of a poorly drawn stick figure. So much for the premise that "everyone is a designer."

Tips for Designers:

When sketching concepts, consider increasing the fidelity beyond the bare minimum of Sharpies on Post-its â for example, use pencils and/or larger Post-Its. This can allow for a bit more detail and/or annotations for those that prefer words to pictures.
If a user cannot interpret a low-fidelity sketch, allow clarifying questions to be asked and answered, in addition to Socratic questioning.

Avoid Design by Committee

Teamwork is effective in accomplishing shared goals: Dribble, pass, shoot, score. But have you heard the expression "too many cooks spoil the broth?" The idea is that each might add a different ingredient, which, in the end, creates something unpalatable.

Image Credit: Moz

If we allow every user to manipulate the design â one after the other â we may end up with an unappetizing design that pleases no one. Thatâs what happened In our sushi/pizza exercise â each user started where the previous user left off and were free to change the design to their liking.

What if a user changed or removed something a subsequent user might have found compelling in its earlier form? What if the final user added something that none of the previous users would have found to their liking, or removed something that excited all the others? Clearly, the order in which users took their turn designing impacted the outcome. It was a handoff, rather than a handshake.

You don't need a whole committee to spoil the broth â one empowered user can muck things up quite well on their own given half a chance. Homer Simpson was tasked with designing a car for the "average American" and came up with The Homer, a completely unworkable solution:

Image Credit: Simpsons Wiki

Tips for Designers:

Provide users with a common problem statement. All designers need context and constraints. Provide these in a well-articulated problem statement (e.g. "We're trying to do [something] for [someone], without [negative consequences/constraints]"). Edit out any ideas that don't conform to the statement.
Reset the concept between users. Let everyone begin at the same place and end up where they will. Compare and contrast the results.
Use other collaborative design methods that allow multiple users to work together on the same problem at the same time. Two examples are Lego Serious Play, and Convivial Toolbox.

As seen with the pizza and sushi app exercise, collaborative design has the potential lead to a lesser result than if users had only been consulted before and after the act of designing. But it still offers tremendous potential to improve products and services. In the next post, Iâll talk about some areas where collaborative design can add value.

EmberConf 2016 - Bigger and Better

2016-04-01 00:00:00

Leading up to this year's EmberConf I wasn't sure I was going to attend. My indecisiveness had nothing to do with concerns about Ember or DockYard's commitment to the framework. It was simply that I personally haven't been writing much Ember over the past six months. Between being a new dad, buying a house, running DockYard, and exploring Elixir I lacked the bandwidth to keep up with what has been happening in Ember.

The deciding factor was to lend moral support for two of our engineers who were speaking: Estelle DeBlois and Lauren Tan. They both gave great talks and if that was the only reason it would have been more than worth the trip. However, like many things, I was thankfully wrong about my concerns attending and would like to share my experience this year.

.@sugarpirate_ takes the stage at #emberconf // #emberjs @DockYard pic.twitter.com/aWMmgIaIMp
— Mike North (@michaellnorth) March 30, 2016

First, I'd like to point out how great of a job Leah Silber has done building and organizing EmberConf. This year the attendance was just shy of 1,000. That's almost double from last year. I've heard the aim is for 1,500 next year. As someone who has run a few conferences I can say that Leah has been kicking ass.

My time was split about 50/50 between the hallway track and the talks. Tom & Yehuda's keynote was probably my favorite talk as we're very interested in the mobile web becoming more competitive against native. Elements of that keynote should play out over the next year or so to help position Ember as the best choice for Progressive Web Applications.

Enjoying #emberconf so far w @bcardarella @jeremy_w_rowe @tundal45 @atonse @sweatypitts #emberjs pic.twitter.com/J7Tr8fWTex
— Tracy Lee | ladyleet (@ladyleet) March 29, 2016

I was really impressed with how many people were interested in Elixir. Easily a majority of the conversations I had were with people curious about Elixir or actively using it. I don't want to dwell on Elixir too much because this was EmberConf but this reinforced my opinion that Elixir/Phoenix are a natural fit for Ember backends. It seems there are many people out there that have the same idea.

This is now my fourth EmberConf (if I'm counting the original EmberCamp) and catching up with old friends is important but I really enjoyed meeting new people. As always, the regret is not meeting enough people. I wish that future EmberConfs were more days with more down time. I realize this is not realistic as the days really increase the cost to run the conference and more down time creates less incentive for companies to send employees, but I personally find the most value from networking.

Climbing right after @EmberConf with these great emberiÃ±os ïªï #emberconf pic.twitter.com/TsWWZ1c2mF
— Filipe BraganÃ§a (@filipecrosk) March 31, 2016

I am aware of DockYard's place in the Ember community. Thinking back to the earlier RailsConfs, and companies that were in a similiar position to DockYard, I don't recall the leaders of those companies being very accessible. There were clear social cliques that these people stuck to. I'm trying not to repeat that. At times I found myself gravitating towards friends but after a few minutes I'd excuse myself so I could meet new people.

Thanks @DockYard for sponsoring amazing time at @GroundKontrol #emberconf pic.twitter.com/2NEiXp4ZbO
— Tom Chen (@tchen) March 30, 2016

Tuesday night we hosted an event at Ground Kontrol. For those unfamiliar, Ground Kontrol is a video arcade with a bar. We rented the entire space for three hours and had close to 100 EmberConf attendees through the doors that evening. All the games were free. When I walked in to get the place ready for the event it was like stepping into a time machine. Nearly ever coin-op game from my childhood was there. If I learned anything that evening it is that I vastly over estimated my skills as kid. Or I am just rusty. Or it was the controller... all of the controllers. Also, I am really out of touch with modern arcade games as I was completely unaware of this Killer Queen game.

Killer Queen at Ground Control at 9! Ping us and let us know if you can make it!#EmberConf
— Ember Weekend (@emberweekend) March 31, 2016

A good conference leaves you feeling energized and wanting more, EmberConf has done that for me every year. A great conference gives you the opportunity to connect with friends new and old, and it takes a great community to build what Ember has. We hear a lot about Ember vs X. Not often enough do I hear the practitioners of other frameworks bragging about their community the way Ember does. I think there is a good reason for that. Twenty years from now I'm not going to give a shit about which library rendered which obscure demo the fastest. But I will remember...

Who is a better puppy? @bcardarella or @mikepack_ ? Follow "modernweb" on snapchat for the full story #emberconf pic.twitter.com/VBPruOLft2
— Tracy Lee | ladyleet (@ladyleet) March 28, 2016

Having some fun with the tomster at #emberconf @EmberConf ï¨ï´ pic.twitter.com/zjFd3ll5EB
— JuliÃ¡n CÃ¡rdenas Mazo (@juliankmazo) March 31, 2016

Kudos to @thejameskyle for the most visually entertaining talk at #EmberConf pic.twitter.com/INwmqboMVo
— Wedge Salad Antilles (@suzidao) March 30, 2016

I love @emberconf #ImgPlay pic.twitter.com/plZWIsoyku
— Emanuele Tozzato (@mekdigital) March 29, 2016

Loved my new Ember socks :) thanks @EmberConf #emberconf #portland #socks pic.twitter.com/X2odXYlgVK
— Filipe BraganÃ§a (@filipecrosk) March 28, 2016

So good seeing @cball_ at #emberconf! â¤ï¸ïïïï see you at @wickedgoodember? #emberjs pic.twitter.com/fpW6HlinlA
— Tracy Lee | ladyleet (@ladyleet) April 1, 2016

Farewell Ember Conf, until next time. #emberconf pic.twitter.com/7PsVcd7lsR
— tomguisuru (@tomoguisuru) March 31, 2016

...the people.

Announcing VerifyOrigin

2016-03-31 00:00:00

In web applications, if you are using cookies for storing authentication state, you should be worrying about Cross Site Request Forgery (CSRF). In short, when using cookies, other sites can create an HTML form that submits to your backend. When your browser submits that form, it will attach any cookies it has that are associated with the URL that the form is submitted to. Without any steps taken to mitigate this, a malicious third party could create a form on their site that performs an action on application, maybe as harmless as following them on a site, or as malicious as deleting your account or transferring funds. OWASP has more details on CSRF attacks as well.

Typical CSRF prevention

The way that most applications mitigate CSRF attacks is by utilizing a synchronizer CSRF token that is stored in a hidden HTML input in the form which matches a token in the current user's session. In short, malicious forms will be lacking this token and will be rejected. More details on token based mitigation are covered in this OWASP page.

What about Single Page applications? Is a JSON only API vulnerable?

CSRF tokens work well for server side rendered applications (SSR), since the HTML generated on the server can securely include the token that is in the session cookie. But what about single page application like Ember? Can you craft an HTML form to submit a valid request to a JSON based API? The answer is yes it is possible.

Ok, so how can we secure this API backend without a CSRF token?

Enter Referer/Origin header verification

With the exception of GET requests, when your browser submits a request, it attaches both a Referer (that typo is historical) and Origin header. The Origin header is a bit newer, it was originally introduced for Cross Origin Resource Sharing (CORS), but has been repurposed for CSRF mitigation as well. We can use the Referer or Origin header to verify that the request originated from the domain we expect. In this case, I prefer the Origin header. When a request originates at an HTTPS page and is made against an HTTP page, the Referer header is dropped, while the Origin header will continue to be sent. Both OWASP and Mozilla talk about the validity of using the Origin header as a way to mitigate CSRF attacks.

Places where CSRF prevention fails

No matter how good your CSRF prevention is, there are other vectors that will open your application to malicious requests. If your session cookie is not HTTPOnly (details), and/or you accidentally allow malicious JavaScript to execute on your site, you have a couple of problems. When not using HTTPOnly cookies, your cookies can be retrieved via JavaScript, and if you have malicious JavaScript on your site, someone could siphon off all your session cookies. At that point, this third party could forge any header it needs to, and then include the session cookie to automate requests against your server, so it could bypass the Origin check. They could also replace the cookie in their browser with another person's cookie that they stole, and use your site as that user, bypassing CSRF Tokens. If your cookie is marked as HTTPOnly, they can still use malicious JavaScript via a Cross Site Scripting (XSS) attack, since any users' browser that executes this malicious JavaScript will make the request with either the necessary CSRF token or Origin header.

Ok, so why all this information about CSRF mitigation?

At DockYard, we produce Ember applications for our clients. Since Ember is a single page application, Origin header checking is the best way we can protect any backends we produce. To the end, I recently published VerifyOrigin to hex.pm. VerifyOrigin provides a Plug you can add to your applications pipeline to only allow requests from Origins you expect:

  
  plug VerifyOrigin, ["https://example.com"]

The plug expects a list of valid Origin URLs. If the request does not have an Origin header that matches your list, then it returns a 400 Bad Request response to the client. Simple CSRF mitigation for your Phoenix app is at your fingertips!

A special thanks to Craig Ingram, who I consulted with multiple times when coming up with this plug!

Announcing: ember-deferred-content

2016-03-30 00:00:00

There are times that you may have some content that you want to load outside of the model hook. An example of this would be a blog post with comments. You want your post to be loaded in the model hook of your route, but don't necessarily want to wait for all of the comments to load before displaying the blog post.

ember-deferred-content takes the promise you need to resolve to show your content, and yields four subcomponents that you can use to show content during the different states of your promise:

  
  {{#deferred-content promise=promise as |d|}}
  {{#d.settled}}<h2>Your content!</h2>{{/d.settled}}
  {{#d.pending}}Loading your content...{{/d.pending}}
  {{#d.rejected as |reason|}}<strong>Could not load your content:</strong> {{reason}}{{/d.rejected}}
  {{#d.fulfilled as |stuff|}}<strong>Loaded:</strong> {{stuff}}{{/d.fulfilled}}
{{/deferred-content}}

If you want to handle transitions with something like liquid fire, you can use if (or liquid-if) statements and the flags provided:

  
   {{#deferred-content promise=post.comments as |d|}}
    {{#if d.isSettled}} <h2>Comments</h2> {{/if}}
    {{#if d.isPending}} <img src="spinner.gif"> {{/if}}
    {{#if d.isFulfilled}}
      <ul>
        {{#each d.content as |comment|}}
          <li>{{comment.author}} said: {{comment.body}}
        {{/each}}
      </ul>
    {{/if}}
    {{#if d.isRejected}} Could not load comments: {{d.content}} {{/if}}
  {{/deferred-content}}

Demo

As you can see above, you pass the promise to the deferred-content component, then you get four contextual components for the four states of the promise: settled, pending, fulfilled, and rejected. Each is a block component where the content you place the content you want to see when the promise is in that state. rejected and fulfilled yield the result of their states to the component so you can reference the result of the promise.

Let's take one step further

Let's peak at an example in which we have no asynchrony in our model hook: Example app

So what's happening here? This app simulates a slow loading blog post. We have some basic information on the blog list page (the title), and we can use this to do a hero animation right away, instead of waiting for the model hook to resolve. Clicking the deferred link shows that, as clicking on the normal link waits for the model to be fetched in the model hook before starting the transition.

Deferring asynchrony to the template

When we use deferred-content to show the loading state note that the URL update and animation happens immediately, as opposed to waiting for the model hook to resolve. This approach will also encourage you to model your data slightly differently so that you push your asynchronous to logical divisions in your templates.

By utilizing animations to mask your loading times you improve your perceived performance. Given that two sites take the same ammount of time to render, the one with a loading animation will be perceived as faster, and tends to be less likely to lose conversions.

Where this really shines

Pages with multiple pieces of async content benefit the most from this approach. You can load in each piece of content as you receive it, making the page more responsive.

Handle the states of your content easily

With ember-deferred-content it becomes trivial to handle async content after rendering the page. You can provide a pending state to let your users know that content is incoming, and switch over to the actual content once it's loaded.

Served with FastBoot (again)

2016-03-29 00:00:00

A little less than a year ago, we launched the redesigned DockYard.com, which at launch was running an early version of FastBoot. And by early version, I mean alpha version, when Ember had some memory leaks, which caused FastBoot to crash. Since then, DockYard.com was a FastBoot Rendered, Statically Servedâ¢ site. I would run a local instance of FastBoot, use a custom crawler to crawl everything but the blog and save static files of the site. I would then push those static files to the server and let Nginx serve the files. This gained us the benefits of running FastBoot (except on the blog), without FastBoot running and crashing because of the memory leaks. The reason that the blog was left out was because of the fact that using {{{blog.body}}} was not rendered in that version of FastBoot, leaving the post content of every blog post out of the page source.

FastBoot keeps moving

As time went on, the memory leaks in Ember were fixed, and FastBoot has been continually developed. Ember has also been updated so that stable releases, as of 2.3.0, support FastBoot. Previously you had to use the canary version and enable a feature flag to allow Ember to work with Fastboot.

And recently, I revisited the DockYard site and worked to reimplement FastBoot. In terms of work on DockYard.com, there was little to no work, we had previously submitted pull requests to addons we were using to make them FastBoot compatible. Most of the recent work was around contributing to FastBoot to help make it easier for applications to drop in.

There have been many contributors to FastBoot, helping to make it a reality. Ember Data, as of 2.4.0, works with FastBoot with little configuration (you need to provide the host to your adapter for now, as relative URLs do not work for FastBoot's AJAX layer). There is a FastBoot service available to your Ember app that gives you access to cookies, headers and the requested host in the FastBoot version of your application. DockYard.com may be a bit on the bleeding edge, but a production version of FastBoot is not that far off.

If you and your company are looking for help getting your application FastBoot ready we'd love to help. Please reach out to us.

Prefer Integration Tests over Acceptance Tests

2016-03-28 00:00:00

It is suprisingly easy to test your whole Ember.JS application using acceptance tests only. All you have to do is to reproduce how you would normally navigate through the application using a stellar set of helpers. Don't want to test your API? Add ember-cli-mirage!

You should realize though, that each acceptance test boots up the whole Ember.JS application and starts you at the application.index route. You then have to navigate to the right page and then test the thing you wanted to do. This is fine when you want to test a complex user-flow through an app, but a big waste of time and CPU cycles to verify if a form submit button is unclickable when the data is invalid.

If you create acceptance tests for every edge case and every regression, then it will be likely that your test suite will quickly grow to be five, ten or more minutes long. That is a problem since slow test suites are likely to be run less often by the developer, and test failures won't be caught quickly. I have caught myself relying on the CI server to run the tests for me, while doing other stuff, because I didn't want to wait for just five minutes.

Having said all that, I think we should write more integration tests and less acceptance tests. Integration tests in most cases run much faster, because you don't have to boot a whole app, or navigate to the page where your component is being used.

Integration tests are also more flexible than most people think. They're not only for testing components, you can also test template helpers. Actually you can test anything with an integration test. For example a model that has logic depending on its relationships is a good example where you can use a non-component integration test.

Using component integration tests to test components should also improve your component design. Test driving individual components will make you think more about their external API, prevents building a LMAO and promotes loose coupling.

There is, however, a small downside to integration tests: the API for writing component integration tests is completely different than the api for writing acceptance tests, so you will have to learn another totally different style of writing tests while maintaining the knowledge of how to write acceptance tests. Luckily there is a motion to unify the API for integration and acceptance tests.

If you aren't that familiar with EmberJS' integration tests I'd recommend to read Alisdair McDiarmid's Ember component integration tests post.

Closing out I'd like to say that this post isn't mean't to say don't do any acceptance testing anymore. Acceptance tests are still necessary to smoke test the whole application.

What makes Phoenix Presence special, and a sneak peek

2016-03-25 00:00:00

At DockYard, our goal is to build the fastest and most robust applications for our clients both on the front-end and back-end. When it comes to the server, Elixir and Phoenix give us the fastest platform with the highest productivity. And it just keeps getting better. New features like the much anticipated Phoenix Presence have us extremely excited about treading new ground on what a Web framework can accomplish.

Here's a sneak peek of the new features in action that show how we're putting cutting edge CS research into practice and how you can try it out for yourself. Jump below for full details:

Phoenix Presence

Phoenix Presence is an upcoming feature in Phoenix 1.2 which brings support for registering process information on a topic and replicating this information transparently across a cluster. Its simplest use-case would be showing which users are currently online in an application, but we're excited about other lower-level uses such as service discovery. This feature at first seems simple and mundane, but most libraries fail to properly tackle it and those that do introduce extra dependencies without solving edge-cases. Not so with Phoenix.

What makes it special?

What's special about Phoenix's implementation is we have a system that applies cutting edge CS research to tackle day-to-day problems in the applications we all write. Phoenix Presence:

has no single point of failure
has no single source of truth
relies entirely on the standard library with no operational dependencies
self heals

Unlike most libraries and web frameworks in various languages, Phoenix does not require a central datastore to hold presence information. While having to deploy Redis or similar datastores increases your operational overhead, it also introduces a couple severe penalties â a single point of failure, and central bottleneck. Worse still, if one of your servers goes down, you'll have orphaned data stuck permanently in your database. With Phoenix, we've developed a system based on a distributed heartbeat/gossip protocol which uses a CRDT to replicate data in a conflict-free way. This gives you high availability and performance because we don't have to send all data through a central server. It also gives you resilience to failure because the system automatically recovers from failures. This includes other nodes going up or down or spotty networks causing netsplits and missed data replication.

Great platforms yield great solutions

None of this would be possible without the innovations from Elixir and Erlang which gives us a distributed runtime that's unmatched by other languages. When we sat down to design Phoenix Presence, instead of immediately asking "which database would be best to hold presences?", we could ask "how can we best replicate data in a distributed system without the user having to worry about it?". The platforms you build on top of drive the design decisions you make in your products. With Elixir, you are empowered to tackle problems that in other platforms would feel impossible to solve without tradeoffs with heavy dependencies. Overtime these decisions play out to more reliable products and services, and better user experiences.

Testing function delegation in Elixir without stubbing

2016-03-24 00:00:00

In other lanugages mocking/stubbing are part of your regular toolbelt, in Elixir Jose has come out against them

I will fight against mocks, stubs and YAML in Elixir with all my... friendliness and energy to promote proper education on those topics.
— JosÃ© Valim (@josevalim) September 9, 2015

Instead he suggests

@bcardarella for tests, create a simple module (or an agent if you need flexibility) that will be used by your app during your tests
— JosÃ© Valim (@josevalim) September 9, 2015

I've been trying to practice this until the other day when I was building a library that was adapter based. I wanted to unit test the parent module that would delegate to the adapter. The adapters can change and I don't want the unit test of the parent module to be tied to any particular child. As a matter of example, we could have something like this:

  
  defmodule Parent do
  defmacro __using__([adapter: adapter]) do
    quote do
      def __adapter__, do: unquote(adapter)
      def make_it_so(command) do
        __adapter__.make_it_so(command)
      end
    end
  end
end

In other languages I would stub out Parent.make_it_so/1 and assert that this function was being called. For example, if you were using the mock Elixir library you would do:

  
  defmodule CustomParent do
  use Parent, adapter: FooBar
end

with_mock CustomParent, [make_it_so: fn(command) -> command end] do
  CustomParent.make_it_so(:ok)
end

But as Jose has pointed out we don't want to do this. So how do we test that the adapter's make_it_so/1 function is being properly delegated to without stubbing? Well we can rely on Elixir's send/3 and assert_receive.

Keep in mind that send will allow you to put messages into a process's mailbox and assert_receive will allow you to test against that.

Here is how you might test the delegation:

  
  defmodule ParentTest do
  use ExUnit.Case

  defmodule CustomAdapter do
    def make_it_so(_command) do
      send self(), :ok
    end
  end

  defmodule CustomParent do
    use Parent, adapter: CustomAdapter
  end

  test "delegates to the adapter" do
    CustomParent.make_it_so(%{foo: "bar"})

    assert_receive :ok
  end
end

And that's it. You can handle more complex situations by adding your own logic inside the CustomAdapters function, to send or not send depending upon the value passed in but that should depend upon your use-case.

So what happens when you are testing with a module that might spawn its own process? In those cases I might have an opts argument that I can work with. Let's assume that for whatever reason Parent.make_it_so is working in a process on its own:

  
  defmodule ParentTest do
  use ExUnit.Case

  defmodule CustomAdapter do
    def make_it_so(_command, opts) do
      send opts[:pid], :ok
    end
  end

  defmodule CustomParent do
    use Parent, adapter: CustomAdapter
  end

  test "delegates to the adapter" do
    opts = [pid: self()]
    CustomParent.make_it_so(%{foo: "bar"}, opts)

    assert_receive :ok
  end
end

This works because each test in ExUnit runs in its own process. You could even do this in a setup block if you needed to capture the PID for many tests. However, you cannot do this in setup_all as that runs in a different process than the individual tests.

Testing in Elixir has been fun as it has forced me to think about things differently than I've been used to over the past few years. If this topic is of interest to you check out my talk from ElixirDaze on Building and Testing Phoenix APIs

The things about Red, Green, Refactor that nobody ever talks about

2016-03-23 00:00:00

"Red", "Green", "Refactor"

Red, Green, Refactor

RED GREEN REFACTOR

This process has been drilled into our head for over ten years. The goal is to push to writing better software by ensuring that only what you have spec'd out is implemented. The problem however is when you're in new territory. In order to write proper tests you need to have an understanding of the system it is spec'ing. If the implementation of that system is still a mystery then you can find yourself getting blocked trying to dream up how to test a system you have no idea is going to work.

Does this sound familiar?

The dogmatic approach of Red, Green, Refactor can sometimes be a blocker. If it is preventing you from delivering business value what good is it doing?

Well, I've got some secrets to share about Red, Green, Refactor...

It's OK to spike the implementation first

When trying to implement something new writing the actual implementation is sometimes easier than reasoning about how to test said system. In these cases it is perfectly reasonable to:

Code spike the implementation
Gain knowledge on what the boundaries and requirements of the implementation are
Toss out the spiked code
Write the tests
Write the new implementation

More often than not you'll find this strategy to be very effective and you'll break through the wall faster than attempting to dream up the implementation in your head before writing the tests. You may also find that when you get to Step 5 the re-implemented code is much better than the spike you originally wrote.

You don't have to follow any "order"

Take a look at the graph at the top of the page. Where does it start? Where does it end? Most people, because of the phrase "Red, Green, Refactor" feel they must start with "Red". Well, you don't. Let's assume you inherit an application that has poor, or no, test coverage. It's perfectly OK to write simple acceptance tests that assert the current behavior of the application. Go directly to "Green". This is OK because the application is already live, it's working. Once you have the happy paths covered in the acceptance tests you've written you can refactor with confidence.

Break the "rules"

Like most rules "Red, Green, Refactor" makes sense for most cases, but not all. In situations where you find yourself restricted or not moving forward feel free to break the rules until you can get back to a place where observing them again makes sense.

Ember's getWithDefault

2016-03-18 00:00:00

Getting Default Values

Here's a quick look at a common gotcha that slips into pull requests from time to time.

When working in Ember, you'll often want a default value for certain properties. Ember provides a convenient means for getting a default value with the aptly named, getWithDefault:

  
  Ember.getWithDefault(person, 'lastName', 'Doe');

The above code would retrieve the lastName property off of the person object, and if the value is undefined, it will return Doe.

An Example

Let's say we're working on a campaign application with a Donation model. This app will primarily be used by Super PACs to fund campaigns of legislators who represent the interests of a small group of deep-pocketed individuals. These well-funded legislators will win their elections about 90% of the time.

Naturally, if the donor does not disclose her name, the Super PACs would like the default donation to display "Anonymous."

Our first pass looks something like this:

  
  // app/donation/model.js

import Model from 'ember-data/model';
import attr from 'ember-data/attr';
import computed from 'ember-computed';
import get from 'ember-metal/get';

export default Model.extend({
  amount: attr('number'),
  fullName: attr('string'),

  displayName: computed('fullName', {
    get() {
      return get(this, 'fullName') || 'Anonymous';
    }
  })
});

We soon realize we can clean up our displayName computed property with getWithDefault:

  
  displayName: computed('fullName', {
  get() {
    return getWithDefault(this, 'fullName', 'Anonymous');
  }
})

Using getWithDefault in that example is a bit cleaner and easier to read.

Then one day, we wire up with a new, external API. The JSON payload from this backend sends null for fullName if the record does not have a value. Our displayName no longer defaults to "Anonymous" and we're slightly confused. If our fullName value is falsy, why does getWithDefault not return our default value?

Remember, getWithDefault is not evaluating whether or not the return value is truthy or falsy: it only returns the default value if the get returns undefined. The value that was once undefined is now null, so getWithDefault returns null.

The solution here is probably to cleanup the JSON payload in the serializer so that null values are treated as ''. But for this contrived example, and for any instance in which you would like to set a default value based off a falsy return value, use a good, old-fashioned or operator:

  
  displayName: computed('fullName', {
  get() {
    return get(this, 'fullName') || 'Anonymous';
  }
})

I hope this prevents a few people from scratching their heads when getWithDefault doesn't behave as expected.

Thanks for reading, and don't forget to support campaign finance reform this tax season by opting into the Presidential Election Campaign Fund (it's free)!

Why?

2016-03-17 00:00:00

Just the other day amidst working on what would be classified as a longer term client engagement for DockYard, I was reminded of the power of âWhyâ. One of the most wonderful things about being human (and what separates us from machines) is that we are motivated by many different things both in our personal and professional lives.

When it comes to working on projects which involve the design & development of a product not owned by our company, itâs easy to get stuck in a rut of just churning out âDeliverablesâ and forgetting what you're actually contributing to in the greater scheme of things. A good work environment, generous compensation and work life balance can only go so far. High performing teams also need to know and feel that they are contributing to the world they live in - sometimes in an evolutionary way and sometimes a very revolutionary way.

One important distinction which sometimes gets missed - âwhyâ is very different from âhowâ. âHowâ is much more easily defined.

How = adverb. In what way or manner; by what means.
Why = adverb. For what reason or purpose.

It might come as a surprise to some of our clients how personally vested we get in their products even though we may be acting as supporting cast. You have to consider that we essentially live and breathe our clientsâ products while they are in development. We think about it during our workday, we think about it while commuting and we think about while taking a shower - TMI perhaps! After many months of contributing to a product's evolution, to maintain motivation, we must remind ourselves âWhyâ we are there in the first place.

Passionate product owners are those who always provide their team with a compass heading towards an eventual goal. The path to get there is twisty and bumpy but at end of the day the team knows what the end game looks like and how it contributes to the world. As an agency we are always looking to amplify this real-world connection for our team members to make sure they feel aligned with the overall product objective. Our Project Management team at DockYard shouldered this responsibility, making sure they stay aligned to our clientsâ compass throughout the project journey. This will no doubt allow our team to better navigate that twisty/bumpy path towards the overall product objective while at the same time providing a motivating work environment for our most valued company resource: the employees.

A learning experience in web application design (part 1 of 2)

2016-03-11 00:00:00

After a summer of freelance magazine work, I joined the DockYard design team. This has required my design practice to evolve. My education and experience in editorial and publication design made me comfortable with visual systems and hierarchyâa skill fundamental to any design project. Yet, shifting my focus to UI involves working through a new set of problems.

Even though I use web applications daily, it doesnât mean I understand every crucial detail that makes a successful interface. I know when a design doesnât work, but the thing about good UI is that it can slip right by you. If you asked me what the loading state for tumblr was, I would have to go and check even though I see it everyday.

A common idea in UI design is to fail fast and iterate often. Understanding means nothing without experience. With this in mind, I chose to design the UI for a speculative project that would challenge me to confront the differences between print and web application design.

Designing for the user, not for yourself almost seems like a new concept born out of interaction design, but editorial is no stranger to this ideology. Just like with any web application, a magazineâs user needs to be able to absorb the important information quickly and navigate seamlessly. Good print design is consistent with grid, type, and color choices. This consistency provides a level of comfort for the user.

Unlike a magazine, an application should provide constant feedback to communicate with its user. Every action needs an appropriate reaction to simplify and support the userâs journey. Interface responses manifest themselves in different component states. âWhy is this taking so long?â is met with a skeleton UI that makes the application appear faster than it is. Answering a userâs instinctive questions lets the brain focus on the task at hand.

For this project, I focused on a concept for a produce delivery service from an article by Steven Trevathan. Working on this app gave me a chance to explore different states and forms of feedback for many application components. For a range of different states, I planned to design the components shown below.

To guide this project, I referenced The Nine States of Design article by Vince Speelman. Given that these states are a necessity for any web application, the exciting part is experimenting with the form and language of them. My next post will show my own process designing states that align with a specific brand personality. Well crafted states can give the user an experience to enjoy and not just tolerate, even when they deviate from the intended path.

How we taught an intro to UX design workshop

2016-03-08 00:00:00

Earlier this week, my colleague Amanda and I taught a workshop for the Northeastern University Women in Tech group. More than 35 computer science majors, as well as designers and inter-media studies students joined us for two hours of hands-on learning.

By presenting this workshop, we got a chance to meet and collaborate with a great bunch of motivated students, and learned a few things ourselves!

You can learn fast when you start with a common background

A big portion of the workshop consisted of a hands-on exercise: the participants conducted design sprints from user interviews to screen flows. The constraints were that our audience was generally new to UX design and the workshop was to fit in a one hour timeframe. We started with an introductory UX design presentation and then posed our workshop prompt. The hypothetical client and problem set was intimately familiar to all of the participants: the Boston MBTA.

Participants switched between end-user and interviewer roles, and conducted quick interviews to find problems to solve. The process went very smoothly and had quite a few laughs, as we all shared painful experiences weâve all had on the clunky and crowded transit system.

When in doubt, propose a magical solution

Because the goal of the workshop was an introduction to the whole UX design process, rather than a refinement of a particular skill, we decided to move away from any potential time-consuming sticking points like detailed research or gathering real data.

Our demo: the low-fidelity presentation of UX problems and solutions for a unicorn to find a compatible public transit car.

As an example outcome, we demonstrated a UX design proposal that solves the problem a unicorn might have when she doesnât know if a unicorn-compatible train car is available on the MBTA. This is clearly not a practical design premise. What it is, is a story so ridiculous and open to interpretation that it gives participants the license to invent a solution, however crazy, rather than get stuck in the process. As a result, folks were able to improvise solutions quickly.

Present what youâve learned

Hands-on learning seems like the best method to internalize new concepts quickly. But to really make sure that our participants are able to remember and apply their new UX design skills in their work going forward, we asked them to present their findings at the end of the workshop. Each team of 5-6 people was asked to pitch their app proposal to the entire group. They had to explain each proposed interface solution by stating what user problem they had discovered through interviews, and how the interface would address that problem.

By âpitchingâ UX design considerations for the fictional MBTA app, the participants got practice and gained confidence to do it again in a future project.

Whatâs next

In the follow-up discussion, a participant asked what the next step might be for someone learning UX design for the first time. We did not have a prepared answer at the time, except for this: anyone can and should include UX design considerations at the beginning of any project to save time and effort.

Here is a list of actionable items to further your initial set of skills so you can start including UX in projects in any discipline:

Join UX-oriented Meetups and learn through presentations, networking, workshops, and panel discussions. DockYard hosts UX East, which includes quarterly workshops, plus other educational events.
Watch this great introductory video thatâs drawn on a whiteboard!
Read this article on Simplicity vs. clarity in UX Design by Robert Hoekman Jr.
Read IDEOâs primer on Design Thinking, The Field Guide to Human Centered Design, available in print or as a free PDF
Read Erika Hallâs A Book Apart book, Just Enough Research, a solid introduction to the whyâs and howâs of design research

This was fun. Letâs do it again!

The workshop results surpassed our expectation: every group put together a fun, articulate presentation with their UX considerations for a fictional app. We saw many fun creative ideas, as well as âahaâ moments where an obvious problem and a simple solution found a match. We had a great group of students, and saw a lot of results in the two hours they invested into learning with us.

The creatively named âMBT-Yayâ app

Interested in hands-on learning?

If you and your team are curious about hands-on workshops, and would like to chat to one of us about potentially hosting one, get in touch! Weâd love to collaborate.

TIL: Elixir maps have built in syntax for updating

2016-03-07 00:00:00

I am relatively new to Elixir and often find there are numerous ways to implement a single task. For example, when I want to update a key value in a map, I have several options before me...

Given, expenses = %{groceries: 200, rent: 1000, commute: 70}, I could employ:

Map.merge(map1, map2) if I want to update multiple key value pairs and/or several new ones

  
  Map.merge(expenses, %{
  rent: 1200,
  comcast: 100
})

Map.put(map, key, val) if updating or adding a single key value

  
  Map.put(expenses, :booze, 100)

Map.update(map, key, initial, fun): if I want to increment a value by a certain degree

  
  Map.update(expenses, :misc, 300, &(&1 * 2))

Kernel.put_in(data, keys, value): if I want to update a value in a nested structure

  
  expenses = %{groceries: %{milk: 5}, apartment: %{rent: 1000, comcast: 100}}
put_in(expenses, [:rent, :comcast], "too much")

However, today I learned, maps come with a built in syntax for updating one or more key values!

  
   %{expenses | groceries: 150, commute: 75}

While a bit obscure, and not easily found in the elixir docs, this trick is definitely nice to have in my elixir tool belt. The only thing to remember is that this syntax requires groceries and commute to already exist. Otherwise, it will fail with an error. Hopefully, this syntax comes in handy for you now too!

If you want to know more about how to deal with nested structures, check out Brian's post "Elixir Best Practices - Deeply Nested Maps"!

Code Linting: An Inside Look

2016-02-29 00:00:00

A little while back, I wrote a blog post introducing ember-suave, an addon that we created at DockYard to help enforce a common code style across all of our projects. With the addon installed, any code that doesn't align with the established styleguide will cause the build to fail. During development, as files are modified, the linter will reprocess the changed files, displaying errors in the console right away.

If you've adopted ember-suave in your own projects, you may be content to find that things just work. But there's a lot of satisfaction to be had with understanding how the addon does what it does.

Let's start at the core with JSCS.

JSCS

JSCS is the wonderful library that uses a set of predefined code style rules to lint your code. It comes with a very simple API:

  
  let Checker = require('jscs');
let checker = new Checker();

checker.registerDefaultRules();

checker.configure({
  verbose: true, // shows rule name next to error messages
  requireSpaceBeforeBinaryOperators: true,
  requireSpaceAfterBinaryOperators: true
});

As this snippet shows, once you install jscs from NPM and create a new Checker instance, all you need to do is register the default JSCS rules and configure which ones to enable. You can now start linting your code:

  
  let results = checker.checkString('let x = y+z;');
let errors = results.getErrorList().map((error) => {
  return results.explainError(error);
});
console.log(errors.join('\n'));

Running this example will output the following:

  
  requireSpaceBeforeBinaryOperators: Operator + should not stick to preceding expression at input :
     1 |let x = y+z;
-----------------^
requireSpaceAfterBinaryOperators: Operator + should not stick to following expression at input :
     1 |let x = y+z;
------------------^

It's as simple as that! Of course, this example is merely checking a String literal. In practice, you would want to check the content of your application files, one at a time. This is where broccoli-jscs comes in.

broccoli-jscs

broccoli-jscs was created by Kelly Selden, and encompasses both a Broccoli plugin and an Ember CLI addon.

As a plugin, broccoli-jscs implements a JSCSFilter function that accepts a collection of input nodes, which map to file paths. Each file is read into a string, which is then passed to JSCS's checkString method for linting. Every time that you make a change to a file while ember s is running, the file will be reprocessed by the plugin, and any JSCS errors found will be displayed in the console.

In addition, JSCSFilter will generate a test file for every file represented in the input nodes. Given foo/example.js, the plugin will output a test file named foo/example.jscs-test.js, with the following content:

  
  module('JSCS - foo');
test('foo/example.js should pass jscs', function() {
  ok(false, 'foo/example.js should pass jscs.\nrequireSpaceBeforeBinaryOperators: Operator + should not stick to preceding expression at foo/example.js :\n     1 |let x = y+z;\n-----------------^\n     2 |\nrequireSpaceAfterBinaryOperators: Operator + should not stick to following expression at foo/example.js :\n     1 |let x = y+z;\n------------------^\n     2 |');
});

If no JSCS errors are found, the test file is still generated, but with a passing assertion: ok(true, /* message */).

As an addon, broccoli-jscs implements the lintTree function, which is one of the many hooks that Ember CLI exposes, as a way to extend the core build pipeline. In this case, the function simply creates a new instance of the JSCSFilter plugin and returns it. Ember CLI will call the hook for every addon discovered inside a project, if it is defined. So if you install broccoli-jscs as an addon, its lintTree function will be called on every build or re-build, therefore linting your code every time it changes.

It is worth mentioning that the JSCSFilter plugin instance returned by lintTree is also considered a node (representing the collection of JSCS test files), and this node further serves as an input node to additional plugins along the course of building out the project. For instance, it is passed to broccoli-babel-transpile to turn ES2015 code into ES5 syntax, then to broccoli-concat in order to be concatenated with other files and produce a single assets/tests.js file.

So where does `ember-suave` fit in this picture?

If you install ember-suave, the Ember CLI addon portion of broccoli-jscs isn't used. The goal of ember-suave is to augment the plugin provided by broccoli-jscs, by configuring it with a set of rules (both JSCS built-in rules as well as custom ones defined inside of ember-suave), so you don't have to do so for each project. As such, it has its own lintTree implementation that calls out to the JSCSPlugin.

Eager for more?

Even though this post focuses on ember-suave, you can imagine the process being very similar for other linters, such as JSHint or ESLint.

Understanding the inner workings of a build helps tremendously for various situations: when something breaks, you know where and what to look for. Furthermore, you are now better equipped to build extensions of your own, should the need arise.

If you found this post informative, and would love to learn more about Ember CLI's build process, available hooks, and how to use them, EmberConf is right around the corner. I'll be diving more into this topic as part of my talk on "Dissecting an Ember CLI Build".

Ember Best Practices: Route Actions

2016-02-19 00:00:00

In my previous post, I wrote about moving singleton state in Controllers into Services that back components. This means being able to lighten the responsibility of Controllers in your application, and in some cases even remove them completely. However, a common pain point that remains for many is that it isn't really clear what should live on a Controller, if anything.

Locks has written an excellent blog post on this topic. Unless you require query parameters, I'd say that you probably don't need one. That said, I wouldn't go out of your way to creatively avoid using Controllers, and would only remove them if it makes sense to do so.

Refactoring away from Controllers

If you do want to remove Controllers from your application given that they are going to be deprecated and removed in the future, great!

One of the benefits of removing Controllers is that it reduces the amount of "glue code" you need to write to connect your data (route) and its presentation (components). This means a simpler mental model, and reduces the amount of "Ember" you need to write. Instead, you can rely on regular JavaScript you're already familiar with to build your applications.

Sending closure actions directly to the route

Closure actions are probably one of my favorite additions to Ember. Instead of casting string actions into the void and praying that something is listening, we can instead use an action like we would any other JavaScript function. This means that we can do useful things like curry arguments, utilize return values, and all of the other good stuff we expect from a regular JS function call.

For example, the following action is implicit in that you have no idea where the action actually lives â it could be on a component, controller or route.

  
  {{! where does `myAction` live? }}
<button {{action "myAction"}}>Do it</button>

Unfortunately, Ember's in a bit of an awkward transition phase right now. Without bringing in an addon (or making a custom helper), it's not possible to use a closure action directly from the route â it would have to be defined on the Controller.

If you wanted to remove Controllers from your application, then you would have to resort to using string based actions instead of closure actions. This seems like a lose-lose situation, so I worked together with rwjblue to turn his jsbin spike into a working addon.

ember-route-action-helper lets you use closure actions defined on the route in your templates, meaning that many Controllers that only exist to implement actions can now be removed. You can install it today with:

  
  ember install ember-route-action-helper

And to use it, you can just use route-action in place of action inside of your route's template, like so:

  
  {{! foo/template.hbs }}
{{foo-bar click=(route-action "updateFoo" "Hello" "world")}}

This addon gives you all the goodness of closure actions, and is a great way of taking steps to future proof your Ember application. When Routable Components do land, and actions work correctly, then upgrading your app simply becomes a search and replace for s/route-action/action.

Power up your Handlebars templates with Helpers

Helpers are a really nice way of extracting utility functions that you can use in your application. You can create class based Helpers, like ember-route-action-helper, or simple pure-function ones using Helper.helper like the one used in ember-toggle-helper.

Pure-function helpers are simple to grok and understand, so a look at addons like ember-truth-helpers is sufficient to understand them.

ember-route-action-helper uses the class based implementation, which must define a compute method. This is then invoked every time one of the positional arguments to the helper changes.

Under the hood, the route-action helper retrieves the router from the application instance as a computed property, then locates the function reference from the currently active routes:

  
  function getRouteWithAction(router, actionName) {
  let handler = emberArray(getRoutes(router)).find((route) => {
    // find the route with the action
  });

  return { action, handler };
}

The action and the handler (route) is then returned, and wrapped with a closure action, which allows us to do all the nice stuff we expect from any other closure action in Ember. By returning a function in a helper, you can essentially "decorate" the action helper with some custom functionality.

  
  compute([actionName, ...params]) {
  let action = function(...invocationArgs) {
    let args = params.concat(invocationArgs);
    let { action, handler } = getRouteWithAction(router, actionName);

    return run.join(handler, action, ...args);
  };

  // return the closure action
}

And because Helper classes are just like any other class in Ember, you can do the usual things like inject services, define computed properties, and so on. Here's a contrived example:

  
  import Ember from 'ember';

const {
  inject: { service },
  Helper,
  observer,
  get
} = Ember;

export default Helper.extend({
  session: service('session'),

  compute([shoe]) {
    return parseInt(get(this, 'session.currentUser.shoeSize')) === parseInt(get(shoe, 'size'));
  },

  onShoeSizeChange: observer('session.currentUser.shoeSize', function() {
    this.recompute();
  })
});

The simplified Helper class was introduced in 1.13, and are an excellent addition to Ember. In my next post, I'll talk a little bit more about them and how we can use them to replace certain CPs.

Until next time, thanks for reading!

Ember Data: Worryless Model Defaults

2016-02-12 00:00:00

When working with Ember Data models, itâs common to want to set default values for certain attributes. Setting a default value on a model is super easy and you've probably done it countless times:

  
  import Model from 'ember-data/model';
import attr from 'ember-data/attr';

export default Model.extend({
  isHungry: attr('boolean', { defaultValue: true })
});

The above syntax works flawlessly for Boolean, String, and Number types. But what if you want to set defaults on an Object or an Array type?

Before answering that question, you should note that Ember Data does not have out of the box support for Object and Array types. Well, kinda. If you don't specify a type as the first argument to DS.attr, it just means the value for that attribute will be untouched rather than coerced to the matching JavaScript type. You can easily add a transform for a custom type. Your transform should provide serialize and deserialize methods for proper processing.

Now to answer the above question, your first instinct might be to do the following:

  
  // app/models/person.js
import Model from 'ember-data/model';
import attr from 'ember-data/attr';

export default Model.extend({
  favoriteThings: attr('object', { defaultValue: {} })
});

Here, every new record created with the Person model would be expected to have a favoriteThings value of {}, rather than undefined. Which is correct, but only until you begin setting content on that object. An Ember Data model extends from Ember.Object, meaning that arrays and objects will be shared among all instances of that model. If you're not too familiar with that concept, check out this past Ember Best Practices blog post from Estelle!

The result from setting a model attribute default to an empty object:

  
  let foo = this.store.createRecord('person');
get(foo, 'favoriteThings'); // => {}
set(foo, 'favoriteThings.food', 'pozole');
get(foo, 'favoriteThings'); // => { food: 'pozole' }

let bar = this.store.createRecord('person');
get(bar, 'favoriteThings'); // => { food: 'pozole' }

Trolling at its finest. Bar doesn't even know what "pozole" is. (By the way, if you've never had Mexican pozole, you're missing out!)

This quirky functionality isn't particular to Ember, however. It all stems from JavaScript itself; this also happens with POJOs:

  
  var foo = { name: 'foo' };
var bar = foo;

bar.name = 'bar';

console.log(bar); // { name: 'bar' }
console.log(foo); // { name: 'bar' }

Lucky for us, Ember has made it easier to avoid this pitfall by deprecating the use of a complex object as a default value for a model property. If you try to set an attribute with a default value of type "object", you'll see a warning message: Non primitive defaultValues are deprecated because they are shared between all instances. If you would like to use a complex object as a default value please provide a function that returns the complex object. This is your cue to undo.

A better, and often forgotten option

Don't fret, because this issue is just a simple fix away. defaultValue also accepts a function. Hooray! Let's modify our code to work as we would expect.

  
  // app/models/person.js

import Model from 'ember-data/model';
import attr from 'ember-data/attr';

export default Model.extend({
  favoriteThings: attr('object', { defaultValue: () => {} })
});

That's it! This will ensure that every favoriteThings attribute contains its own object instance. Having the ability to pass in a function to defaultValue can also prove helpful if you would like to set custom defaults based on computed properties, as well as other attributes of the same model.

Hope this served as a sweet reminder, or as something new that you can leverage in your projects from now on.

Why DockYard transitioned to PostCSS

2016-02-11 00:00:00

The UX Development Team at DockYard takes pride in the ability to adapt to the latest tools that improve our workflow and benefit the team. We are always looking for tools that help with maintaining DRY CSS and quicken the development time of a projectâs CSS. Because of PostCSSâs evolving plugin library, PostCSS is the latest addition to our development process.

PostCSS is the new big kid on the block and for good reason. It has provided developers with modularity and flexibility in CSS development. The ability to add and remove plugins that fit a projectâs development process separates PostCSS from other tools that we used in the past.

What we used in the past

In the past we used Sass for all our projects and utilized the parts of Sass that we needed. Along with Sass we used a combination of BEM and SMACSS for naming conventions and file structure based on DockYardâs styleguides.

When we began using Autoprefixer, we had to lay it on top of Sass. This meant that we had to manage multiple tools, which increased setup time.

We were using the best available tools within our workflow that we could at the time. As you know, it feels like a new development tool comes out every month. Over time, we felt we could improve the environment of how we were writing our CSS.

Introducing PostCSS

PostCSS provides us with the flexibility to adopt new plugins with ease and within one NPM package that we manage at DockYard.

The PostCSS plugins we choose focus on two things. DRY CSS that does not trip over itself on overlapping styles, and creating organized CSS modules that have class names that explain themselves based on DockYardâs styleguides.

We want developers who see our project tomorrow (or in two years) not to be confused by our naming conventions.

We use five PostCSS plugins in our projects. To get our projects up and running even easier, we combined them into a package called narwin-pack.

Those five plugins allow us to have modular CSS and use simple variables to speed up our development time. We are able to choose plugins that meet our development needs with no extra âbells and whistlesâ. What makes PostCSS so appealing is the ability to easily add and remove plugins from our custom made package.

We also have syntax rules that we follow while using these plugins - more on those in our next blog post going over each plugin in detail.

How to have a side project

2016-02-10 00:00:00

Pretty much every designer I know has a side project (or five). They are often in a field related to design, but do not replicate exactly what they do at their full time job. Side projects and hobbies are great for relaxing, while adding extra skills or addressing a passion that does not yet have a place in one's career.

Hereâs what I learned about what works well, and what can be problematic for side projects Iâve had over the years. Hope it helps you in your own creative pursuit!

My watercolor sketch to study shapes and colors from Wassily Kandinsky

1: Different enough

To let your brain rest and relax, a side project should be different enough from what you do during the day. When a dayâs work is mostly at the computer, I feel a need to switch to analog afterwards, and still have lots of energy. If this is a design sprint week, and Iâm on my feet most of the day, sketching or writing on the whiteboard - then curling up on my couch with a laptop feels like a welcome break. Essentially, I have different types of energy I could use up during the day, and switching between activities allows me to get more done.

Another principle to keep in mind is to avoid conflicting interests between work and personal projects. When they are different enough, there is a clear separation between the two. I wonât resent filling my week-ends with the personal project, because it does not feel like work. It feels like play!

Sports or dance make a great hobby & side project. I used to spend hours each week rock climbing, then switched to social dancing a few years later. It may seem like thereâs no overlap in the skills - but the ability to clearly lead and follow (typical Tango dance roles) within a larger group setting is a great communication skill for a team of designers as well. It also helped me learn my limitations. When youâre several rope-lengths up a cliff and need to tell something to other climbers on the team without seeing them, my voice never seemed loud enough to get across. Since then, I always think of a backup communication method. Do two tugs on the rope mean âgoâ? You only know if youâve arranged it ahead of time.

2: Similar enough

When work and play are in related disciplines, you get a lot of benefit in combining the two. For example, my photography hobby provided a ton of material for my design work - material that I owned and could art-direct myself. Hours of practicing lighting and portrait photography on the weekend allowed me to quickly organize consistent and flattering staff photos at work. Photography wasnât exactly in my job description, but it gave me better material to design the website.

Photography is a hobby that often encourages me to get, and stay, outside!

An active pursuit of two related disciplines can act as a multiplier, where they feed off each other. Hobbies can âfeedâ on my primary work as well: I usually take time to design a logo and a few other pieces for each side project.

3: Frustrated? Pick just one

One problem with side projects is that they often compete for time with chores, rest and relaxation. And if I have too many side projects at the same time, the apparent lack of progress can be frustrating. At some point I remember I was doing a half-day photo shoot every other weekend (if you do photography, youâll know how much extra time it takes to sort and process the raw photos), had a pretty involved sewing project going (which takes both time and physical space), was learning French twice a week, and attempted to do a daily watercolor illustration. Oh, and a full time job with a lengthy commute.

I miss sewing projects, but stopped doing them for the time being so I can focus on one thing at a time, with higher quality and time investment.

I would write an overly optimistic to-do list for my week-end, but only get about halfway through it. I was probably less effective at my day job than I could have been, due to lack of sleep. My side projects felt stagnant because there wasnât enough happening in each one from week to week. With these projects, the end goal was to produce a portfolio of creative work to apply to grad school. But I felt trapped because even with hard work, I wasnât making enough progress.

I eventually climbed out of this. I negotiated Fridays off at work, trained the designer who would replace me, put together a portfolio and moved to Canada for a year to study. The experience left me with a better understanding of how important focus really is.

Focus

I now know I canât get good results from trying to juggle several side projects at a time. But deciding to do just one thing can feel scary. I often wonder if I'll ever get to work on my other projects. But itâs the only sure way to make progress.

Johannes Ittenâs classic Elements of Color (the book belongs to both ym art life and my design life) and some sticky notes we use for UX design. The colors match perfectly.

In 2015, I decided to focus on one side project: my exploration of the overlap between design and modern art. I put away my sewing machines, and set my Etsy shop in holiday mode. I even stopped nagging myself to keep practicing with watercolors or hand lettering. I now have a more realistic to-do list, and can feel âdoneâ and accomplished with the weekly illustrated articles that I plan to write for a year. Iâll be honest: I miss the other side projects I had put on hold. But I'm OK with not doing them for a while so that once I get to them, Iâll be able to make progress and commit to giving those other passions the focused time they deserve.

More examples!

I went around and asked my intimidatingly talented colleagues to share examples of what theyâre up to. Here they go!

Estelle

Pencil Portrait from my very limited portfolio

What do you do outside work? I tend to go back to the things I enjoyed doing before discovering the joy of programming. I have a variety of hobbies that I try to juggle as time permits, ranging from drawing or painting, practicing photography (I took an online photography course at the Photography Institute a few years ago and try to keep up), practicing piano (Iâve been taking weekly piano lessons for the past six years), and just gaming.

How do you feel it feeds into your work, if at all? I donât particularly feel that any of those activities feed into my work at all, but itâs a nice distraction from my day-to-day work.

Brian

Elixir Language logo (image via Bruna Kochi)

My after-hours time is spent on open source software. Right now I am working on Elixir tools that will be used to support our future application development efforts.

Steve

A self portrait done on 35mm black and white film.

This is a picture I took of ice. Its appearance is more smokey than usual due to melting and refreezing, and because of the size of the river I took this in, I was able to capture somewhere around 15 original compositions.

This is purely representational for me of a possible musical composition. As I do not know how to write and read music, this serves as a visual for my work. Memory alone isnât enough.

What do you do outside work? I compose and play music on various instruments. I also do photography.

How do you feel it feeds into your work, if at all? I think in any medium it is really important to let it express itself as much as I can allow it. I do not attempt to make them feed into each other. However, as I dive deeper into the creative process for each there is something, some way of thinking or structure, that Iâm able to carry back. For instance, I attempted to create 20 original songs in 12 hours, which sounds absolutely insane, but it is truly possible depending on how âbig pictureâ youâre willing to remain on the compositions. It really engrains the concept of taking broad strokes more seriously before getting caught in the details.

Amanda

Oil and graphite on panel (18â x 24â)

What do you do outside work? Prior to design and web development, my main passion was painting. During undergrad, I spent most of my time in the studio oil painting and I still do it occasionally. This painting was for the Fountain Art Fair in Chicago a couple years ago.

How do you feel it feeds into your work, if at all? In UX development, I work closely with designers. Understanding basic design principles is useful. Many practices are transferrable like balance, contrast, composition and attention to detail. More abstractly, coding and painting come together quite similarly to me. Individual brush strokes or pencil lines form a hand or a pillow. In code combinations of letters and numbers make up shapes and components of a website.

Jon

2015 Pukwudgie Time Trial - Assonet, MA

What do you do outside work? Competitive mountain biking

How do you feel it feeds into your work, if at all? Over the years I have participated in many team sports where the performance of the collective group dictates outcome of the competition. Competitive mountain biking has taken out the variable of team and placed full responsibility on me. Any success I have realized in this endeavor (which has been minimal to date) is a fringe benefit of deliberate training, sacrifice, failure and exhibition of mental toughness.

I love the fact teams are a significant part of my professional life - It is the only way I would want it to be. However, outside of work I have chosen something that is âDifferent Enoughâ to keep my other lesser used mental and physical muscles engaged.

Lauren ï· paints!

Moar here

What do you do outside work? Draw / paint characters and landscapes (usually from imagination, but sometimes from real life), but I havenât done it in a while and I miss it a lot. I want to buy a Wacom tablet again as my old one was left (sadly) in Australia.

How do you feel it feeds into your work, if at all? Art has taught me how to see things, and my approach to painting has always been about improvisation. I usually work in digital, and I generally splash blocks of color and refine silhouettes that form into something coherent. I like to think of them as happy accidents that I can then go on and transform into something interesting.

One of the best lessons Iâve taken away from art that translates well into programming is to pause occasionally, take a step back and evaluate the bigger picture before getting lost in the details. Composition is important, as is other elements like color, lighting, and brush stroke economy. Similarly, composing applications in the form of their architecture is also a process that requires much thought before a single line of code goes into the project.

Cory

Tremblant, Canada over winter break. Went for a week and stayed at a hostel and met amazing people.

Weekend trip up to Loon mountain for the first time. Big fan of exploring new mountains.

What do you do outside work? Every year I attempt to plan out my winter snowboarding trips and look for new mountains I have not explored yet. I try to do at least one multi-day solo trip every year to absorb the entire experience differently than going with friends. Snowboarding for me is about connecting to nature and getting an adrenaline rush while pushing my limits as a snowboarder. The best day on a mountain for me is having no clouds in the sky, great music while riding, fluffy powder and empty slopes. Searching for that âunicornâ type of day is what keeps the excitement of going snowboarding fresh.

How do you feel it feeds into your work, if at all? I feel the constant exploration and creativity of snowboarding directly relates to UXD at DockYard. I am constantly trying to find new ways to build things and you have to be creative/think outside the box sometimes to come up with the best solution. Not only thinking outside the box but stepping outside your comfort zone is something I do with snowboarding and trying a new CSS technique. Taking a chance on something you are not sure you can do and just going for it has been something that has helped me as a developer and a snowboarder.

Marten

Appetizer I made for Christmas dinner.

What do you do outside work? In the weekends I like to go nuts on cooking. Weekdays I keep it simple.

I also spend a lot of time in a local bar that has many different craft beers + drink craft beer at home.

Marin

Handmade bags: (See more bag pics)

Sculpture:

Sketches:

What do you do outside work? I make laptop cases, pencil cases and general purpose bags (pouches?) out of scrap fabric that I find or have. I also enjoy making sculptures out of various media, including metal, wire, or anything I can find (one time I used hundreds of marbles for a piece). And I like sketching people/faces using charcoal. Unfortunately, I donât have access to a big studio and lots of materials, so recently, I mostly stick with the bag making.

How do you feel it feeds into your work, if at all? In one sense I donât feel like my hobbies feed into my work very much. Which is nice because it's a break from my day-to-day; getting to use my hands, and unwind. On the other hand, programming involves creativity and thinking outside of the box just like art.

Romina

What do you do outside work? I enjoy cooking most nights of the week, I game, and I exercise. Fitness is my main focus, however. Year-round (except winter), I run outside, otherwise I lean to miscellaneous fitness classes and gym equipment. I love racing and the competitive aspect of it; Iâve been running competitively since I was 11 years old. I strive to beat my previous times in races that I have previously ran. I just completed my first half marathon a few months back, which was a fun challenge. I love and hate the feeling when youâre about to start a race!

How do you feel it feeds into your work, if at all? I donât feel like my hobbies feed directly into my work, but they do play a role in my overall well-being since they serve as relaxation and a way to unwind from work and things life throws at me.

Tim

Mandala Project

After sketching, I arrived at the above digital renderings.

The final result.

What do you do outside work? The images above are from a quick side project I worked on where I was commissioned to create and put up a mandala - a spiritual symbol representing the universe and often geometric in design.

How do you feel it feeds into your work, if at all? This was a huge learning process for me. Wheatpaste, a technique for applying artwork often associated to street art, was something I had never before attempted. This project allowed me to hone in on my digital design capabilities as well as practice a craft that requires more of a hands-on approach.

Patrick

2015 pumpkin beer bottle shoot light boxing.

Pumpkin beer and light photo experimentation.

Preliminary top downs of pumpkin beer pours for 2016 pumpkin beer photo mosaic.

Outside of work, I spend time tasting, photographing, and reviewing craft beer, particularly pumpkin beer. I run a pumpkin beer review site at bumpinpumpkinbeer.com where every year I taste close to 100 of the previous yearsâ best pumpkin beers. I curate photography experiments by doing so, as well as build archives of data on ingredient, recipe, and batch alterations, transitions, and successes which I enjoy visualizing.

Logo and color scheme for the Bumpinâ Pumpkin Beer review site

I think this hobby has fed into my design work in that it has inspired me to pursue different avenues in design, and gain greater interest into parallel areas. For one, itâs constantly forcing me to write (reviewing means writing of course!) which in turn has made me feel more comfortable writing about design. It also has inspired me to pursue photography (out of need originally) and hand lettering (which is prominent in craft beer labeling and branding). Itâs constantly inspired me to pay closer attention to the immense complexity that goes into creating something seemingly so simple and beautiful. The grandeur of the craft, from years of testing recipes to the intricate labor of its packaging design, never ceases to impress me, especially since itâs a commodity thatâs taken for granted so often.

The Self-reflecting Designer

2016-02-10 00:00:00

Meditation or serious thought about oneâs character, actions, and motives. This is the definition of self-reflection.

Self-reflection is something a lot of designers donât consciously do enough of. Yet self-reflection is something designers take part in daily on behalf of other people. We are busy addressing other peopleâs needs, attempting to produce through other peopleâsâ eyes, and realizing other peopleâs thoughts and ideas, in pursuit of creating phenomenal products and services. This is what we love to do and sometimes we happen to be really good at it. However, weâre also users of our own products. We are the result of our own processes. Itâs worth spending time reflecting on our creative selves in order to continue to produce better for others.

Being a designer whoâs able to self reflect comes with many benefits including the ability to be aware of progress, the ability to identify challenges, and the ability to become more observant.

If designers take time to self reflect, they can intermittently check their work progress. Stepping back and looking at your work as an observer, not a designer, will often reveal sequences, patterns, and trends in progress. Perhaps you notice itâs taking longer than expected to produce a piece of work. Why is that? Perhaps you notice the redesign you did last year is similar to the one youâve just completed. Why is that? Perhaps you find that your process hasnât evolved, yet your work has. How is that possible? By surveying your work and reflecting upon it often, youâre likely to become more aware of progress and more cognizant of growth.

Self-reflection can also help us in identifying challenging situations before they occur. We gain experience through the work weâve created, and often remember failures more than successes. Does this project meeting seem similar to a past conversation that went awry? What happened and how did you react? Perhaps a project brief scares you because it calls for a similar result to a project that once fell through. How did you handle that? What part did you play in its failure? Failure is an important part of the evolution of a designer and therefore should be reflected on in an effort to inform future decision-making and reasoning.

Most importantly, self-reflection allows us to become more observant of ourselves when in motion. Observation produces curiosity and drives the imagination. However it also has the power to reveal negative tendencies and habits that have leaked into our processes over time. For example, you might find that youâre approaching the design of an application in the same way youâre approaching the design of a website. Is it because they both call for the same approach? Or is it because youâre subconsciously relying on the same approach due to its success in previous work? Trends and comfort are two aspects to design that, if you donât take time to question, can hinder experimentation and progress. Being able to better observe how youâre working while youâre working is beneficial to any designer.

Youâd think self-reflection is easy, but itâs not. Itâs hard to find the time. Itâs hard to be honest with oneself. Itâs hard to occasionally focus on yourself in an industry where youâre constantly focused on the actions and reactions of consumers and peers.

Hereâs a couple ways to help begin injecting self-reflection into your life as a designer:

Meet People

Surround yourself with friends and peers from other disciplines as often as you can. This will consistently provide perspective and insight into spaces and ideas you otherwise might be blind to in your everyday routine. It may allow for insight into your work that you might not have otherwise experienced.

Write Often

The rhythm and pace of writing your thoughts out, regardless of what they are, may in fact help you retain and further digest what youâre trying to express. It also allows you to reflect on your thoughts later on.

Extend Your Workspace

Work in spaces that are foreign to your everyday routine. A new space may influence both your thought process and work ethic. This presents the potential to make you question your routine and habits, therefore emphasizing self-reflection. Perhaps consider a sabbatical even.

Keep Your Books

If you take physical notes or have sketchbooks, archive them somewhere. Store them in a manageable place, in an organized way that allows for you to reference content from specific years or projects past. This allows for very easy self-reflection that will help you better understand what you have and have not accomplished in your journey as a creative. Itâs motivating at the very least.

Iâve found the most beneficial quality of self-reflection to be its ability to provide a valuable perspective on your creative self. It forces consideration of what youâve accomplished, as well as how far youâve come. This helps in identifying future pursuits.

Pens, Paper, Scissors

2016-02-05 00:00:00

I was recently involved in a staff augmentation project with one other DockYarder. The project involved us working at our clientâs office for approximately three months. Aside from a shift in daily culture and a completely different perspective on the projectâs challenges, I did discover a couple very, very simple techniques Iâll be exploring further in the future.

While my fellow DockYarder was tasked with user interface work for an existing application build, my task was to research, conceptualize, and design a full fledged careers section of a website. This website is the marketing tool for a greater web service. Itâs aimed at new users and represents the breadth of what the service and its suite of tools and programs has to offer. What it failed to provide was a way for the client to recruit and entice prospective employees, which they would need in order to fill an immense amount of positions that were opening up in multiple locations.

A lot of my time on this project was spent in research and brainstorming concepts, which meant a lot of data harvesting and sketching. The results, prior to executing visual design, came in the form of Content Frames (a term I'll explain in a later post). Using qualitative and quantitative research, we were able to quickly determine a viable layout and hierarchy option for the careers section. We did this without any content having been developed by the client. In fact, there was zero content at this point! Backwards sounding? Perhaps to some. Thatâs not what Iâm going to discuss though. Instead I want to note just two simple techniques that made a strong impact on how the team communicated, and eventually on how we were able to begin prototyping without content.

Sketch with ink

The first technique is to use ink when sketching. I use a set of Micron pens for various design tasks away from the screen. Iâve recently begun sketching all of my lower fidelity wireframes with them. Why? Because drawing out my wireframes is a therapeutic process. It allows me time to further think about what Iâm executing in the moment.

The varying weights also allow me to quickly suggest element context (buttons are a thicker 0.8mm line while images are 0.5 for example). Also because ink is permanent. This challenges my mind to make more calculated decisions in what Iâm sketching and it disallows my cautious self to throw away or erase ideas that I put on paper. You never know how valuable a seemingly wrong idea might be later on.

Construct with paper, scissors, and tape

The second technique is utilizing the sketches to determine the content flow.

Instead of limiting my sketches to the size of the dot grid paper (or any boundary for that matter) I sketched the page as I saw it in its full length, running on to a new piece of paper when needed. At the end I simply taped them together. The results were full page sketches that allowed the client to see the content holistically and sequentially, rather than parsed in a series of sketchbook pages, or having to continuously scroll multiple artboards on screen.

If you have multiple concept sketches for the page, like I did, use scissors to cut and paste your conceptsâ components together. Do this with the client. In fact, have the client do the cutting and taping. It emphasizes involvement, provides the client a sense of authority, and allows for the entire team to immediately rearrange, reorganize or compile their feedback and ideas by cutting and retaping components to one another. After just one meeting, we were left with a new page concept. It was derived from, and composed of, components from two of the four concept sketches we started with.

Thereâs something refreshing about incorporating materials into an approach. Everyone felt more connected, more involved, and frankly more confident with the work as we progressed. Granted the circumstances and constraints of my particular situation allowed for me to experiment with my process in this way. But Iâd argue itâs always worth considering alternative routes in the creative process when the situation allows for it.

Ember Best Practices: Brace Expansion for Computed Properties

2016-02-05 00:00:00

As an Ember developer, I can count on fresh features popping up almost every other month within a new release. There are numerous benefits to this, which certainly are out of the scope of this blog post. However, I will briefly cover one particular gem from 2014 - an oldie, but goodie - of a feature.

How many times have you written something like this?

  
  import Ember from 'ember';

const {
  Component,
  computed,
  get
} = Ember;

export default Component.extend({
  farmSentence: computed('animal.species', 'animal.noise', 'farmer.name', 'farmer.location', {
    get() {
      let animal = get(this, 'animal');
      let farmer = get(this, 'farmer');

      return `At ${get(farmer, 'location')}, Farmer ${get(farmer, 'name')} owns a ${get(animal, 'species')} that says "${get(animal, 'noise')}!"`;
    }
  })
});

Notice how we consume animal.species, animal.noise, farmer.name, and farmer.location? There are a lot of shared dependent keys. Gross.

Computed Property Brace Expansion

Well, back in 2014, "brace expansion" was introduced. Let's use this feature and tidy up our component!

  
  import Ember from 'ember';

const {
  Component,
  computed,
  get
} = Ember;

export default Component.extend({
  farmSentence: computed('animal.{species,noise}', 'farmer.{name,location}', {
    get() {
      let animal = get(this, 'animal');
      let farmer = get(this, 'farmer');

      return `At ${get(farmer, 'location')}, Farmer ${get(farmer, 'name')} owns a ${get(animal, 'species')} that says "${get(animal, 'noise')}!"`;
    }
  })
});

Why use Brace Expansion?

Isn't that much nicer? I prefer using brace expansion, because it organizes the dependent keys and makes it easier to read. Goodness forbid a coworker of yours writes dependent keys without ordering them alphabetically:

  
  ...

// This ordering isn't ideal
farmSentence: computed('animal.noise', 'farmer.name', 'animal.species', 'farmer.location', {
  get() {
    let animal = get(this, 'animal');
    let farmer = get(this, 'farmer');

    return `At ${get(farmer, 'location')}, Farmer ${get(farmer, 'name')} owns a ${get(animal, 'species')} that says "${get(animal, 'noise')}!"`;
  }
})

...

To those new to Ember, hope you learned something new! And to those experienced in Ember, hope this was a refresher! And to my coworkers that don't use brace expansions, shame on you!

Thanks for reading.

Setting up revision previews with Ember CLI Deploy

2016-02-03 00:00:00

I recently set up previewing revisions with Ember CLI Deploy. There is no single best practice on how to do this yet, but here is how I did it.

This post assumes you use the ember-cli-deploy-revision-data plugin in conjunction with an index adapter (Redis, S3, SSH) for Ember CLI Deploy.

About revisions

Everytime you deploy index.html with Ember CLI deploy, it gets tagged with a revision. By default this is an MD5 hash of the index.html file itself, but it can also be a Git commit hash, or the version from your package.json.

How exactly index.html gets tagged depends on the index adapter. For example: using the S3 adapter, the tag will be appended to the filename; using Redis, the tag will be part of the key where the file is stored.

Once you have one or more revisions deployed to the target server, you can activate one of the revisions, which will be the default index.html the users of your app will see.

Viewing revisions without having to activate them

It would be very nice to be able preview a revision (maybe QA test) on the production server, before you activate it and release it to the public. My idea was to be able to do this by visiting https://example.com/rev-a76df687f97e9ab8ca82d1a1/.

It is really simple to set up your webserver to do this, so I won't go into that, but there is a caveat on the Ember side of this. If you navigate to the revision, the router will throw an error: The route rev-a76df687f97e9ab8ca82d1a1/ was not found.

What is happening? The Ember.Router is not intelligent enough to know that you meant to route after the /rev-a76df687f97e9ab8ca82d1a1/ portion of the path.

You have to explicitly configure the router to route on a path other than /.

Fixing the router

Setting up the router to work from a base path should be fairly straightforward, for example to route on /awesome-app/ you can set the rootUrl:

  
  import Ember from 'ember';

const { Router } = Ember;

const Router = Router.extend({
  location: 'auto',
  rootURL: `/awesome-app/`
});

To route revisions is a little more complex, as you can't just type in a simple string and be done with it. To be able to handle revisions, you can make the rootURL a computed property instead:

  
  import Ember from 'ember';

const {
  Router,
  computed,
  isPresent
} = Ember;

const Router = Router.extend({
  location: 'auto',

  rootURL: computed(() => {
    let path = window.location.pathname;

    // Looks for /rev-a76df687f97e9ab8ca82d1a1/ at the beginning of the path
    // Tweak this regex to match your own style of revisions.
    let revisionMatch = new RegExp('^/(rev-[^/]+)').exec(path);

    // If there was a revision at the beginning of the path
    // return it as rootURL
    if (revisionMatch && isPresent(revisionMatch[1])) {
      return `/${revisionMatch[1]}/`;
    } else {
      return '/';
    }
  })
});

When the application loads, the rootURL computed property will be executed once. If the rev-* part is in the path it will return that as the rootURL, else it will just return the default /.

Caveat: baseURL is set in ENV

By default the baseURL property in your config/environment.js is / and does not interfere with the rootURL in the router, but when it is something like /awesome-app, then you will run into trouble.

It is best to not use baseURL in conjunction with rootURL. If you have a base path the app is served from, I would recommend you add it to the rootURL.

Here is how I solved it:

  
  import Ember from 'ember';
import config from './config/environment';

const {
  Router,
  computed,
  isPresent
} = Ember;

const Router = Router.extend({
  location: 'auto',

  rootURL: computed(() => {
    let baseRootURL = config.baseRootURL || ''; // NOTE: This is not baseURL
    let path = window.location.pathname;

    let revisionMatch = new RegExp(`^${baseRootURL}/(rev-[^/])`).exec(path);

    if (revisionMatch && isPresent(revisionMatch[1])) {
      return `${baseRootURL}/${revisionMatch[1]}/`;
    } else {
      return `${baseRootURL}/';
    }
  })
});

So now you know

If you have a backend that serves revisions on a scheme like /rev-a76df687f97e9ab8ca82d1a1/, then this is one way to set up your Ember app to work with that scheme. Don't forget to check your app's baseUrl.

If you figured out another way to set up something like this, then please share it!

How to contribute to Elixir

2016-02-02 00:00:00

I just got my first commit accepted into the Elixir programming language. Here are some notes on how to build and test Elixir on your machine to help you make your own contributions.

Up and running

After you've cloned Elixir you'll need to ensure that the state of your copy builds properly and all the tests pass. To do this you'll need to use Make. Simply run the following:

  
  $ make compile
$ make test

Hopefully the purpose of each command should be obvious. The entire test suite for the language doesn't take too long to complete. Once all the tests pass you can start. In the event that any of the two steps fail I would recommend getting help in the #elixir-lang IRC channel on Freenode.

You've made your changes

Assuming you've made your changes you'll need to test them. For any changes that you've made to the language you'll need to recompile. You can re-run the commands from above in the root directory of the project.

Elixir itself is made up of several packages. They're all listed in the lib/ directory:

  
  lib
âââ eex
âââ elixir
âââ ex_unit
âââ iex
âââ logger
âââ mix

Depending upon the package you are making changes to you may not want to run the entire test suite. For example, to compile and run the tests for ex_unit only you can run:

  
  $ make test_ex_unit

Check out the Makefile in Elixir for the available commands for testing individual packages.

Even this can be tedious. If you really want to move fast you can target a specific test file to run. Let's say you want to target the test file for ExUnit.Case:

  
  $ make compile
$ bin/elixir -r lib/ex_unit/test/test_helper.exs lib/ex_unit/test/ex_unit/case_test.exs

The second command will use the custom build of Elixir that is the result from make compile. The option -r will run the specific file at that path.

This should get you into a faster feed-back loop to ensure that your tests for the changes you've made are passing.

Real-world testing

It could be that you are making a commit to scratch an itch in an app you're building. In that event it would be great to ensure that the changes you're making in the language actually work for you. We can easily test this by using the custom build of Elxiir with your application.

In a Linux-based shell you can prepend the bin/ path of the custom Elixir build onto $PATH so it takes precedence:

  
  $ export PATH=/home/yourname/elixir/bin:$PATH

Replace /home/yourname/elixir/bin with whatever the path is for your machine. If you really want to live on the edge you can add this to your Bash or Zsh config, but I wouldn't recommend it.

You should confirm that your custom build is the one found. You can do this by running: which elixir and which mix. If it doesn't return the path for the custom build you should revisit the steps above and see why not.

You will likely need to recompile the dependencies for the custom build of Elixir:

  
  $ mix do deps.clean, deps.get, deps.install

Assume your application is using the changes you've made just run mix test as normal to confirm that your changes work.

Documentation

You may have to document your changes. Please see the Elixir guide on writing good documentation.

Bad builds

Sometimes there may be a bad build during compilation. In this event you can just run:

  
  $ make clean

This will reset the project to a clean state. You can now try to re-compile.

Finish up

I think you'll be surprised how easy and straight forward it is to contribute back to Elixir. Hopefully these tips have made it a bit smoother for you.

Elixir Best Practices - Deeply Nested Maps

2016-02-01 00:00:00

When writing Elixir apps you'll typically find yourself building up state in a map. Typically these maps contain deep nesting. Updating anything deeply nested means you have to write something like:

  
  my_map = %{
  foo: %{
    bar: %{
      baz: "my value"
    }
  }
}

new_bar_map =
  my_map
  |> Map.get(:foo)
  |> Map.get(:bar)
  |> Map.put(:baz, "new value")

new_foo_map =
  my_map
  |> Map.get(:foo)
  |> Map.put(:bar, new_bar_map)

Map.put(my_map, :foo, new_foo_map)

That's pretty complex for a simple nested key update! Elixir has a better way: Kernel.put_in/3

This function uses the Access "behaviour" to drastically reduce the keystrokes for inserting into deeply nested maps. Let's take a look at refactoring the above example:

  
  my_map = %{
  foo: %{
    bar: %{
      baz: "my value"
    }
  }
}

put_in(my_map, [:foo, :bar, :baz], "new value")

That's it! The really nice thing about this function is that the 2nd argument is simply a list which means when we're dealing building complex maps during recursion we can simply append to the list.

Similarly, we can get deeply nested values in a map using Kernel.get_in/2:

  
  my_map = %{
  foo: %{
    bar: %{
      baz: "my value"
    }
  }
}

get_in(my_map, [:foo, :bar, :baz]) == "my value"

Let's go deeper. Does the list syntax feel like too many characters to you? Let me introduce you to Kernel.put_in/2

  
  put_in(my_map.foo.bar.baz, "new value")

This version of the function is a macro that will break up the syntax and deal with each part of the path individually. It may feel like magic but it's just Elixir doing what it does best: blowing your mind.

Still going deeper...

Now its time to get fancy. Let's say you want to update the values according to a function. To do that we'll use Kernel.update_in/3

  
  my_map = %{
  bob: %{
    age: 36
  }
}

update_in(my_map, [:bob, :age], &(&1 + 1))
#=> %{bob: %{age: 37}}

update_in(my_map.bob.age, &(&1 + 1))
#=> %{bob: %{age: 37}}

Dealing with Lists and Structs

Deeply nested lists can also make use of these functions. However, there is a difference in the short-hand syntax.

  
  my_list = [foo: [bar: [baz: "my value"]]]

put_in(my_list[:foo][:bar][:baz], "new value")

This is referred to as "field-based lookup" and can differ depending upon the type you are acting upon. Maps can work with either form:

  
  my_map[:foo][:bar][:baz]
#=> "my value"

my_map.foo.bar.baz
#=> "my value"

Lists only work with the bracket form:

  
  my_list[:foo][:bar][:baz]
#=> "my value"

my_list.foo.bar.baz
#=> ** (ArgumentError) argument error

Structs only work with the path form:

  
  my_struct.foo.bar.baz
#=> "my value"

my_struct[:foo][:bar][:baz]
#=>  ** (UndefinedFunctionError) undefined function MyStruct.fetch/2

I hope this helps you deal with deeply nested maps, lists, and structs!

Running Elixir and Phoenix projects on a cluster of nodes

2016-01-28 00:00:00

Once you're ready to deploy your Elixir application to multiple servers, you'll want to take advantage of the distributed features that the runtime offers. For example, if you are using Phoenix channels, you'll want broadcasts to be sent across the cluster. You can setup your deployment as a cluster in a few simple steps:

Start by creating a new sys.config file in your project. We'll conventionally use the name sys.config because Erlang assumes exactly one system configuration file is used when building releases, with this name. Add the following contents the new file:

  
  [{kernel,
  [
    {sync_nodes_optional, ['n1@127.0.0.1', 'n2@127.0.0.1']},
    {sync_nodes_timeout, 10000}
  ]}
].

In this example, we have two nodes in the cluster, n1@127.0.0.1 and n2@127.0.0.1. The sync_nodes_optional configuration specifies which nodes to attempt to connect to within the sync_nodes_timeout window, before continuing with startup. There is also a sync_nodes_mandatory key which can be used to enforce all nodes are connected within the timeout window or else the node terminates. With our sys.config in place, we can pass a VM -config flag to use our configuration when booting the Erlang VM. For example, you could start two iex sessions like this:

  
  n1@host$ iex --name n1@127.0.0.1 --erl "-config sys.config" -S mix
n2@host$ iex --name n2@127.0.0.1 --erl "-config sys.config" -S mix
iex(n2@127.0.0.1)1> Node.list
[:"n1@127.0.0.1"]

If you're building Phoenix projects, you could start your servers like this:

  
  n1@host$ elixir --name n1@127.0.0.1 --erl "-config sys.config" -S mix phoenix.server
n2@host$ elixir --name n2@127.0.0.1 --erl "-config sys.config" -S mix phoenix.server

You might be wondering why we have to use Erlang-based configuration in our sys.config instead of Mix configuration. This is because the configuration must be passed to the Erlang VM when starting. By the time Mix configuration would be loaded, the VM has already booted. That said, we can use Mix configuration to drive our sync_nodes_optional list if we are using exrm to build releases for deployment. exrm builds your Mix configuration into a sys.config within the release, which lets you specify your node configuration like this, in your Mix config:

  
  config :kernel,
  sync_nodes_optional: [:"n1@127.0.0.1", :"n2@127.0.0.1"],
  sync_nodes_timeout: 10000

Then you build and run your releases as normal and the proper VM configuration is provided when starting. For a complete rundown on using exrm to deploy a Phoenix project, see the official guide.

That's all it takes to run distributed Elixir on a cluster of servers! The Erlang VM supports a number of more advanced options and strategies for running distributed applications, including automatic application failover to a configured subset of nodes, and more. See the Erlang documentation for a comprehensive rundown.

Home away from home

2016-01-22 00:00:00

For those who donât know my journey with DockYard, itâs quite an amazing story.

As an imposingly curious grad student studying data visualization, I absolutely couldnât resist the urge to jump into a conversation I overheard while bartending at Highball Lounge in March of 2014 (who can resist buzzwords like "information architecture", "JavaScript", and "data"!). A nice chat and a short introduction later, I was invited by Brian and Dan of DockYard to reach out and learn more about the company. I was immediately intrigued - both by the conversation and also the type of people who didnât dismiss me because of my job (as most tend to do to those who work in the service industry).

Iâll never forget the first conversation I had with Steve when I went to the DockYard office to learn about the design team. I was absolutely amazed that they would consider me for an internship, and saw value in my curiosity and engagement, rather than the checklist of my industry experience (which, for the record, was non-existent). After a summer internship in 2014 where I was welcomed with open arms and jumped right into the conversation, I joined DockYard full time in January 2015. This was during my final semester of grad school, and I received a tremendous amount of support from my colleagues while I worked simultaneously on my Masterâs thesis project.

A few weeks later, I moved to Brooklyn for summer 2015. I saw an opportunity to bridge two worlds that were very important to me - DockYardâs consulting services and civic technology. I asked for permission to take a leave of absence to attend a fellowship at Blue Ridge Labs, a social impact incubator focused on problem solving with technology for low income communities in New York. It was an amazing thing to receive their blessing and support.

DockYard is an amazing place that values people and relationships. But I think the most incredible part, which Iâve been so fortunate enough to receive time and again, is the grace of its individuals' willingness to mentor and teach. While some companies are in search of unicorns and are in the game of stealing resources, DockYard seeks out something special in its employees more important than skill, and fosters the growth of individual people as well as talent.

Today is bittersweet, because it is my last day at DockYard, and in the city of Boston. What Iâve been lucky to find I will be taking with me - the awareness to pay attention to qualities rather than attributes, to share and to be open, and to prioritize heart, sincerity, drive, and curiosity above all else.

DockYard is truly special (and youâd be hard pressed to find a DockYarder who doesnât feel this way). I feel proud and quite blessed to say that DockYard is my home away from home. Iâd like to take this opportunity to thank my friends, colleagues, and mentor, Steve, at DockYard; it's been an absolute privilege to learn and grow in this community with all of your support.

Heroic Elixir Pipelines

2016-01-22 00:00:00

One small source of beauty in Elixir code is the pipe operator. It passes the expression on the left as the first argument to the function on the right:

  
  1..100_000
|> Enum.map(&(&1 * 3))
|> Enum.filter(odd?)
|> Enum.sum

Here, a range of numbers is being passed through a chain of several operations. Much of the Elixir standard library can be used like this.

Code like this is great to read. Itâs got a protagonist. Our hero navigates trials, and comes out changed on the other side. Humans are wired to understand a story.

But do you ever think about how to keep your own functions pipeable? Hereâs a hypothetical bit of Elixir code:Â

  
  def read_time(str) do
  str
  |> String.split(" ")
  |> Enum.count
  |> Kernel./(200)
  |> Integer.to_string
  |> Kernel.<>("minutes")
end

def related_posts(title, body) do
  related_posts_by_title(title) ++ related_posts_by_body_text(body)
end

...

def publish_post(%Post{body: body, title: title} = post) do
  word_count = read_time(body)
  related_posts = related_posts(title, body)
  App.publish(%{post | word_count: word_count, related_posts: related_posts})
end

Here, the wonderful piping action is present in the read_time function, where youâre sticking to the standard library. But where did it go in the publish_post method? The functions you're writing aren't built to facilitate piping. A good pipeable function takes some thought.

Who is your hero? Here it's your post object. To write pipeable functions, your functions should take this hero as their first argument, and return a modified version/representation. Your first argument is your pipe intake, and your return value is your pipe outflow.

Taking your hero as your second argument (as the sidekick), or taking only specific properties, or returning another value rather than a modified version can all break pipeability. Sometimes you want to do those things for unit tests, or for encapsulation and reusability, but you can always write a wrapping function that is more pipeable. Hereâs how Iâd use those techniques here:

  
  def annotate_read_time(%Post{} = post) do
  %{post | read_time: read_time(post.body)}
end

def add_related_posts(%Post{body: body, title: title} = post) do
  %{post | related_posts: related_posts(body, title)}
end

...

def publish_post(%Post{} = post) do
  post
  |> annotate_read_time()
  |> add_related_posts()
  |> App.publish()
end

Ah, thatâs better! We realized our hero is the humble post. It learns a few things about itself along the way, and at the end of its journey is published to the world.

So. When writing your code, discover your protagonist. Write functions which take your hero as the first argument, and return it changed for the better. Then The Heroâs Journey will be complete, and you can have beautiful pipelines running all throughout your code.

Phoenix best practice: Decorating in views

2016-01-15 00:00:00

Recently I was updating an older Phoenix app that was built when I was first familiarizing myself with Phoenix and realized there were a couple architectural mistakes in some of the controllers and views. I rectified those mistakes with the following patterns.

Keep your database out of my view by preloading

The view layer in Phoenix serves as a decorator for the template you are about to render. It serves to merge data retrieved in the controller with the additional details that may be needed. On our JSON API backends, we use ja_serializer to convert our models into the proper response. When we have additional details (say we include a blog post's author for side loading into Ember), we want to make sure that we preload this data before it gets to the view. If we preload from the view itself, we will be creating an N+1 scenario.

Let's take the case of an index route where you have 20 posts you want to render. When we wait until we get to the view's show.json (which renders the individual post) to retrieve the author, we will be doing 20 additional SQL queries, as we will be getting the post one by one. If we preload the author relationship in the controller, we will be executing a single query that retrieves all the authors and places them in the struct with the post information.

Keep your decoration out of your controllers

You may have additional information you want your view to have access to. In one case that I came across, we query the database to find the number of blog posts a specific tag has. We end up storing the information in a map in the function we created to look up that information, where the key is the id of the tag, and the value is the number of posts for that tag. We just went over why you don't want to do this work in your view, so how do we pass that information down? We can use the Plug.Conn.assign (docs) to store the information on the conn which is passed to render in the controller. What we don't want to do is start Enum.maping across the list of tags and munging the data in the controller. That would be decorating the model, which is the job of the view.

Everything in its right place

By following the practice of decorating in the view, and doing data retrieval in the controller, it actually makes it quite difficult to create an N+1 query. When you have a list of records, the easiest way to preload data (if you aren't using Ecto.Query.preload), is to call Repo.preload(collection, keys), which will only perform a single query in the end.

Moving from Rails to Phoenix, I've personally found there to be fewer footguns to shoot myself with. I think a big part of that ends up being the fact that with a functional language, you can't accidentally make a call to the database because your relationship can't load itself. With Ecto, I have to explicitly load the data for the relationships and that requires me to think about when is the best point to do so.

This business needs to be about more than just business

2016-01-05 00:00:00

I just fired a client. Day one in the year.

I've done it before, I'll likely do it again. This one hurt. We've worked with this client for the past eight months to rebuild their platform. I've given them breaks on price. I've given them free engineering time. In the end it came down to a lack of respect for the relationship they had.

Each year I've written a retrospective about how the year went, the ups and downs of running a consultacy. In the first retrospective I wrote:

"As a consultancy we are looking to make money by engaging clients. If anybody tells you they're consulting because it is their passion or work with startups, they are full of shit."

I can tell you right now that I was full of shit. I got into consulting "for the money" but over the past four years we've built a company that has grown to 23 people. We've followed our passions with technology and design. We've made major contributions back to and have financially supported the software projects we think are going to build the web for the next decade and beyond. We made mistakes and we've made incredible bets that have paid off.

One of our engineers recently told me a story about how he was hanging out with a friend of his girlfriend. That friend knew our engineer was in software but didn't know the name of the company. The friend began to speak about how he was reading a series of blog posts on Ember.js. That blog was our blog and that friend was impressed when our engineer told the friend where he worked.

This was actually an incredible moment for me when I heard this story. This was the first time that I heard a story about someone knowing about DockYard without our prompting them. Perhaps this may seem pedantic to you. But knowing that we've built something that people know about and respect has become very important to me.

I realize that I'm emotionally wrapped up in DockYard. Arguably to the point where it may impact my efficacy as CEO. Today I fired a client because of the lack of respect they showed to us as people. Is this good business? I don't know, probably not. But I've become convinced that this business needs to be about more than just business.

How to uncover hidden assumptions

2015-12-22 00:00:00

A 911 fail

The first time I had ever called 911 was for an almost non-emergency reason. Driving on an Interstate highway through Baltimore, we noticed a large ladder that had fallen off a construction truck. It was blocking two lanes out of four, and cars were veering to the side to avoid it.

Because we were one of the first ones to notice the ladder falling off, and I was a passenger, I was in a good place to call and report debris on the road. So I called 911, assuming theyâd quickly route my call to the department that can easily deal with this stuff.

The call went something like this:

Hello, Iâd like to report a dangerous situation on the road.
Ok, where are you?
Iâm on Route 95, between exits 51 and 52, heading North, there is dangerous debris on the roadâ¦
Are you in the city or the county?
â¦

After a few attempts back and forth, I couldnât answer the dispatcherâs question because I didnât know where the city / county border was. It was certainly not on my phoneâs map apps. We were still driving, so I no longer was at the exact location. I was also getting frustrated because the dispatcher did not seem to care for my attempts to give her a location by highway exit number, or by listing the streets the highway crossed near the area. After a few minutes I gave up and the report went nowhere.

Perspectives and assumptions

I can only assume the dispatcherâs role was to route my call to the next responsible party. For her, the agency in charge of traffic safety in the city, and the other agency in charge of the county are completely different things. For me, and anyone on the ground, the difference between those territories could be invisible. The border is not marked, and could lie across two corners of the same intersection. In general, the public wonât usually see these boundaries in the same way administrators do.

However, the dispatcher had responded to my call with the assumption that anyone calling 911 locally would know if they are âin the city or the countyâ. Her assumption and my assumption did not match, and an emergency call failed as a result.

I disagree with that assumption: even though I lived in the Baltimore area for four years, Iâd only know the city/county border location for the immediate neighborhood where I lived. Even then, it was only because the university I attended had famously lobbied to move that border so they could have a more prestigious Baltimore city address. I wouldnât expect a typical 911 caller to know this stuff.

I donât fault the dispatcher in this case, by the way. Even though she could have been more prepared to understand my perspective, I can see how her environment could have made the city / county distinction so obvious it became an invisible assumption.

A designerâs job is to find out

It is important to discover the assumptions built in to a project. This responsibility is shared, but designers are often in the best position to lead this discovery because we deal both with understanding a userâs needs and the tools we might use to implement a solution.

Part of this discovery process is requirements gathering: we understand and document the business goals the client aims to achieve, the restrictions that will inform the choice of design tools and technologies, and the user and industry insights that will inform the functionality can propose for an application.

But in addition to gathering requirements, we must discover the âobviousâ things to people close to the product. These assumptions are so self-evident to the person who holds them that they wonât likely be included with requirements, or even communicated voluntarily. Designers must ask the âobviousâ questions to uncover those things and continue asking them throughout the process.

Not communicating those assumptions makes a project ripe for surprises. If you donât talk about the obvious things, everyone can hold on to conflicting assumptions for a long time. Making changes to address hidden assumptions after a portion of the work has been done adds cost (and frustration!) and decreases efficiency.

How to uncover hidden assumptions

To uncover hidden assumptions, designers must ensure open and frequent communication. It may feel like over-communicating at first, but will start to feel natural with practice. Here are a few of the practices we use.

Daily updates On most projects, we update the client on our progress daily. While it may seem like a chore to write up an additional description after the dayâs work has been completed, the updates force us to communicate clearly and often. This gives the client an opportunity to correct our assumptions early in the process.

These updates can include questions (e.g. âHow many people are likely to experience this particular use-case?â) and assumptions we need confirmed (e.g. âWe have found that most users will leave this setting untouched, so we included this default value. Is this value a safe one to default to?â). Pro tip: request feedback from a client with a clear list of questions and assumptions they can quickly confirm or correct. This format makes it easier for the client to respond, so itâs more likely that youâll quickly get the information you need to move forward.

Flow diagrams We often produce flow diagrams to map out the universe around the product weâre building. When all team members have access to a visual representation of the entire product, and things that influence it, we often find problems and special cases that were not previously considered.

Flow diagrams often include elements like triggers (what caused a process to be started), decision points (yes / no), variables (including an approximate range) and tentative bits (we are explicitly marking some part of the process as outside the scope, or as a secondary requirement).

Annotated wireframes and sketches We always annotate wireframes and sketches. We may draw low-fidelity sketches at first, but will note the type of content that might be included in a specific screen, and the reasoning and user goals that informed a specific layout. Notes like this will help frame the follow-up discussion with the client.

TL; DR

A difference in expectations is one of the most preventable causes of projects going wrong. And among all expectations, assumptions can be the most dangerous: they feel so âobviousâ that we donât even bring them up. If even a 911 call can be derailed by a dispatcherâs assumption, so can a large collaborative project.

And just like in the 911 call, itâs possible to prevent misunderstanding by asking the âobviousâ questions. The dispatcher could have asked for my location in a different way - by street intersection, or exit number. And if her standard process did not include the assumption that a caller would know where the border between the City and the County lies, she would have been able to route me successfully by asking the question in a different form.

Donât be that 911 dispatcher. Spend the time to talk about assumptions up front - and youâll save everyone on the team time, effort, and unnecessary frustration.

Which diagrams when?

2015-12-21 00:00:00

Diagrams are incredibly valuable as methods of communication. Through visual language and spatial representation, diagrams give form to concepts and ideas.

Diagram: (definition) a simplified drawing showing the appearance, structure, or workings of something; a schematic representation.

Mental model: (definition) an explanation of someone's thought process about how something works.

At DockYard, we use various diagrams at different stages of the design process. Each type documents and captures different aspects of the design research process. It is valuable to know when in the process these diagrams can be used, as they can support conversations between different stakeholders and help to align understanding.

The following case study utilizes a few of the diagrams we used here at DockYard. Each of these examples highlights the type of diagram and when in the design process they should be used. (We use OmniGraffle to build these diagrams.)

Case Study: OutdoorKidz.com

OurdoorKidz.com (fictional!) is a new online store that specializes in seasonal outdoor gear and activites for kids. We've been hired to design and build the customer facing website, which houses the entire inventory of products and allows customers to purchase gear directly from the website.

Target User: Parents with young kids who are looking for outdoor gear and activities for kids.

Goal: Design and build an online store that allows target audience to search for, compare, and purchase items.

1. Journey Map - Design Research

A journey map is diagram in the form of a timeline, which identifies a userâs arrival to and experience surrounding the use of the product. Journey maps are often developed from a user persona based on the target user. They help to understand the context in which someone might interact with the product: why they seek it out, where they interact with it, and what they hope to gain from it. Understanding the use case informs design decisions early on, framing the major actions the user might want to take (features) within the product flow.

Journey Map PDF

2. User Flow - Product Development

A user flow is a diagram of the high level product experience, used to frame the actions taken within the product itself. They are generated from the use case (journey map), allowing us to break down the step by step interactions that must take place for the user to accomplish their goal.

User flows become the basis for sketching and wireframing major areas of the interface. The navigation, framed around the user experience, informs the information architecture and interface design. Through wireframing, actual content is placed in context and functionalities are incorporated to support calls to action.

User Flow PDF

3. Master Product Flow - Product Development

When we build complex interfaces, they often have multiple use cases. This master user flow connects the customer facing interface, OutdoorKidz.com online store, to the inventory management system for the employees of OutdoorKidz.com. The products overlap where orders come in and invetory is tracked. Connecting the two separate user flows can show the points where the two systems overlap. This can help to ensure the systems are built efficiently and speak to one another.

Product Flow PDF

Knowing when and how to incorporate these diagrams can be very valuable to your process. Diagrams are also good for documentation and tracking decisions throughout the process. They support discussion around problem solving, and can clarify that all stakeholders in the conversation share a common understanding of the solution.

Here are some of my favorite resources about diagrams and mental models.

References:

101 Design Methods - Vjay Kumar

100 Diagrams that Changed the World - Scott Christianson

Models of Design - Hugh Dubberly

Ember Best Practices: Service Backed Components

2015-12-07 00:00:00

At EmberConf 2015, Yehuda Katz and Tom Dale announced the arrival of certain changes to Ember 2. Most notably, the routable components RFC attracted a lot of attention because of its proposal to deprecate and eventually remove controllers. Naturally, this was alarming to many existing Ember users, especially since Ember and Sproutcore have always been MVC frameworks.

Goodbye MVC

It is no secret that many new Ember 2 conventions and changes have direct influence from React and Flux (a pattern for data flow in React apps). What Flux calls the "unidirectional data flow" is what we call "Data down, actions up" (DDAU) in Ember.

DDAU avoids the traditional MVC pattern in favor of a single flow of data (hence unidirectional), which makes apps easier to reason about, and improves their performance. The fundamental problem with MVC is revealed as your application grows larger and more complex â cascading updates and implicit dependencies lead to a tangled mess and unpredictability. Updating one object leads to another changing, which in turn triggers more changes, and ultimately makes maintaining your application a frustrating experience.

In the DDAU pattern, data flows one-way and there are no two-way bindings. Different parts of your application can remain highly decoupled and predictable, which means you will always know the source of an object's change. If you've read my post on functional programming and the observer effect, you'll understand why it's important to keep your components free from side effects.

Instead of spending time cobbling together your own makeshift framework with a dozen micro-libraries and bike-shedding on the best way to implement a feature, using Ember means instant productivity and quick developer on-boarding. Combined with the DDAU pattern and the Glimmer rendering engine, Ember developers have both productivity and performance out of the box.

Preparing your application for DDAU

When routable components land, controllers will be deprecated and removed. Controllers and views have always been confusing for new Ember users, and "80% of their use cases were to do something that was fundamentally a component" (watch Yehuda and Tom explain more in this video).

Since Ember components aren't singletons, they will be torn down and re-rendered in an optimized fashion when Glimmer deems necessary. How then to handle state persistence when controllers go away?

For example, you might have some property on your controller that holds on to state that you would like to preserve throughout the app. To do so in Ember 2 (and today), we can remove that controller property in favor of "service-backed components". The service will hold on to singleton component state, and explicitly injected only where necessary. Because services are powerful and can be easily abused, I'll talk more about it at the end of this post.

Implementing service backed components

In the following example, I'll demonstrate how you can use services and one-way bindings today. You can follow along below as well as check out the demo.

Our little application consists of a couple of checkboxes for selecting animals. This selection needs to persist across different routes, and restore state when returning back to the route. All we need is to define a simple service that holds state for the selected items, and then inject it into the routable component.

In the route's template, we can just render the injected service's state using the each helper.

  
  {{! animals/index.hbs }}
<div class="row">
  <div class="col-md-3">
    <h2>Select Animals</h2>

    {{checkbox-group
        group=animals
        selectedItems=checkboxGroup.selectedItems
        check=(action "check")
    }}
  </div>

  <div class="col-md-9">
    <h3>Selected Animals</h3>
    <table class="table table-bordered">
      <thead>
        <tr>
          <th>ID</th>
          <th>Species</th>
          <th>Name</th>
        </tr>
      </thead>

      <tbody>
        {{#each checkboxGroup.selectedItems as |animal|}}
          <tr>
            <td>{{animal.id}}</td>
            <td>{{animal.species}}</td>
            <td>{{animal.name}}</td>
          </tr>
        {{/each}}
      </tbody>
    </table>
  </div>
</div>

In our controller or routable component, we inject the service and define the action for handling the checked animal. The service's bag of state is then passed into the component, keeping it as pure as possible. Although you could have just injected the service into the component, doing it this way makes things more explicit and allows the component to be decoupled from the service.

  
  // animals/controller.js
import Ember from 'ember';

const { inject: { service }, Controller } = Ember;
const OPERATION_MAP = {
  true: 'addObject',
  false: 'removeObject'
};

export default Controller.extend({
  checkboxGroup: service(),

  // In the future, actions will be defined in the route and passed into the 
  // routable component as `attributes`.
  actions: {
    check(group, item, isChecked) {
      return group[OPERATION_MAP[isChecked]](item);
    }
  }
});

As mentioned, the service itself is simple. We can define more complex behavior later, but the underlying persistence for its state is just a JavaScript array.

  
  // checkbox-group/service.js
import Ember from 'ember';

const { Service } = Ember;

export default Service.extend({
  init() {
    this._super(...arguments);
    this.selectedItems = [];
  }
});

Because our behavior is simple, we don't need to define a sub-classed component in this example. The check action is passed in from the routable component / controller, so using closure actions in the component's template means that we don't have to cast sendActions into the void.

In our component's template, we make use of small, composable helpers. These helpers are just simple JavaScript functions under the hood, and because they have return values, we can use them as Handlebars sub-expressions where we might have once defined a computed property.

The contains helper doesn't ship with Ember, but the function itself is one line of code. There are a bunch of useful addons that add helpers such as these to your application â for example, ember-truth-helpers is an addon I find myself using in almost all my apps.

  
  {{! checkbox-group/template.hbs }}
{{#each group as |item|}}
  <div class="checkbox">
    <label for={{concat "item-" item.id}}>
      {{one-way-input
          id=(concat "item-" item.id)
          class="checkbox"
          type="checkbox"
          checked=(contains selectedItems item)
          update=(action this.attrs.check selectedItems item)
      }} {{item.name}} <span class="label label-default">{{item.species}}</span>
    </label>
  </div>
{{/each}}

As mentioned in my previous post, the ember-one-way-input addon is an easy way to start using one-way bindings today.

I hope this simple example illustrates how you can build maintainable and performant apps with some of my favorite features of Ember â helpers, closure actions, components, and one-way bindings.

A word of caution about Services

As the clichÃ© goes, "with great power...". Because services in Ember are singletons, it becomes tempting to make multiple services and inject them everywhere.

If your main reason for creating a service is to use it as a "global", that is generally a code smell because dependencies become implicit (we learned earlier that this is a bad thing) and parts of your application become tightly coupled. Instead, expose data and actions via interfaces to keep your code decoupled and explicit. Remember the Principle of Least Power, and only use a service when strictly necessary!

So when should I use a service?

I like this Stack Overflow answer on when you should use a singleton. Essentially, you should only use one when you can only have a single instance throughout your application. For example, a shopping cart, flash messages or activity feed could be great candidates for a service.

Thanks for reading!

Speeding up Elixir project build times on Travis CI

2015-12-02 00:00:00

Elixir is fast, very fast. So fast that a good chunk of Continuous Integration jobs on Travis CI for our Phoenix projects were spent in fetching dependencies (this is very small, but still a few seconds) and then compiling all of the dependencies.

If you're willing to deal with getting a failed build once in a while then you can significantly speed up the CI jobs by caching certain assets. Specifically the _build/ and deps/ directories.

This strategy can be used on any CI service but the example here is for Travis CI. Simply add the following to your .travis.yml file:

  
  cache:
  directories:
    - _build
    - deps

We saw a big reduction in total Pull Request CI test run time

Here is a comparison of the individual jobs

Before:

After:

If you are getting a failing build when you believe you shouldn't, the issue could be the cache. You can simply clear the cache and start it from scratch at any time.

Comparing dates and times in Elixir with Ecto

2015-11-30 00:00:00

If you are working with Ecto.DateTime in your Phoenix application you may make a comparison of two variables at some point:

  
  d1 = {{2015, 11, 30}, {0, 0, 0}} |> Ecto.DateTime.from_erl
d2 = {{2015, 11, 29}, {0, 0, 0}} |> Ecto.DateTime.from_erl

assert d1 > d2

The above ends up passing the assertion, but only by coincidence. What if you had a situation where you wanted to assert a comparison between today and tomorrow, but tomorrow ends up being a different month:

  
  d1 = {{2015, 12, 1}, {0, 0, 0}} |> Ecto.DateTime.from_erl
d2 = {{2015, 11, 30}, {0, 0, 0}} |> Ecto.DateTime.from_erl

assert d1 > d2

The above assertion fails. If you think it seems odd that December 1, 2015 would be less than November 30, 2015 you'd be correct. To understand why we have to see what Ecto.DateTime.from_erl/1 returns:

  
  {{2015, 12, 1}, {0, 0, 0}} |> Ecto.DateTime.from_erl

# => #Ecto.DateTime<2015-11-30T00:00:00Z>

This is an Elixir Struct. The properties of the struct are not ordered, so the comparison does not actually understand the structure of datetime and how to compare properly. In this case it appears that the day values are being compared before the month values, resulting in a false assertion. To better understand this we need to take a look at the Erlang documentation for Maps (which are just Structs):

Maps are ordered by size, two maps with the same size are compared by keys in ascending term order and then by values in key order. In maps key order integers types are considered less than floats types.

To do a proper datetime comparison between two Ecto.DateTime structs we have to convert to a tuple. We can do this by using Ecto.DateTime.to_erl:

  
  d1 = #Ecto.DateTime<2015-12-01T00:00:00Z>
d2 = #Ecto.DateTime<2015-11-30T00:00:00Z>

assert Ecto.DateTime.to_erl(d1) > Ecto.DateTime.to_erl(d2)

This can be cumbersome to write all the time. Thankfully Ecto comes with a nice Ecto.DateTime.compare/2 function:

  
  d1 = #Ecto.DateTime<2015-12-01T00:00:00Z>
d2 = #Ecto.DateTime<2015-11-30T00:00:00Z>

assert Ecto.DateTime.compare(d1, d2) == :gt

Ecto.DateTime.compare/2 takes two time structs and compares the first to the second. The result will be :eq, :lt, or :gt.

Ember Best Practices: Handlebars's Overlooked {{#each}} {{else}} Conditional Block

2015-11-23 00:00:00

In the past few months, my esteemed coworkers have written about various Ember best practices. To follow suit, I'd like to reintroduce an often forgotten Handlebars trick.

How many times have you stumbled across a template that wrapped an {{#each}} block with an outer {{#if}} conditional block?

The Verbose

  
  {{! if-and-each-usage.hbs}}

{{#if footballTeams}}
  {{#each footballTeams as |team|}}
    Teamname: {{team.name}}
    City: {{team.city}}
    Mascot: {{team.mascot}}
  {{/each}}
{{else}}
  No teams to display!
{{/if}}

Logically, this makes sense. If there aren't footballTeams to iterate through, we render out a message.

However, the result is an unnecessary conditional! Thankfully, the {{#each}} block helper provides us with a more terse solution.

The Succinct

  
  {{! each-else-usage.hbs}}

{{#each footballTeams as |team|}}
  Teamname: {{team.name}}
  City: {{team.city}}
  Mascot: {{team.mascot}}
{{else}}
  No teams to display!
{{/each}}

We don't need the outer {{#if}} block, and we simply can add an {{else}} path within our {{#each}} block.

Although, the change here seems quite trivial, it immediately cleans up readibility (which is a huge win in my book).

More to Come

If you've enjoyed these series of best practices, stay tuned, we'll be writing more posts soon after the holidays! Thanks!

Phoenix is not Rails

2015-11-18 00:00:00

In his yearly recap last December, Brian went public with his plans to transition the company over to Elixir and Phoenix development. Throughout this year, he found it was a smooth transition for the team going from primarily Rails to Phoenix powered applications. On the surface, Phoenix shares some familiar conventions with Rails that lets folks jump into new applications and contribute early to a project â on their way to greater mastery. Complete mastery will take a bit more practice than knowing a few shared conventions, but the similar-at-a-glance features has enticed Ruby teams to get involved and many are delighted to get up and running quickly. Unfortunately, it has also led to wrong assumptions about Phoenix's likeness to Rails, causing some to miss the important differences around their core philosophies.

It is common in the Ruby community to say that there are Rails developers and Ruby developers. We don't expect this to happen with Phoenix. Although Phoenix of course introduces its own abstractions, ultimately writing a Phoenix application is writing an Elixir application. Testing Phoenix code is testing Elixir functions. This post aims to address these ideas by comparing the similarities and differences between Phoenix and Rails and why it matters.

Similarities

Most of the phoenix-core team comes from a Rails-heavy background, so it's natural we borrow some of the great ideas Rails brings to the table, such as:

Both focus on productivity, from client to server side
Both provide a default directory structure, although Phoenix simply relies on the structure imposed by Elixir applications
Both are MVC frameworks (Phoenix does a functional twist on the architecture though) with a router sitting on top
Both provide a default stack with relational databases (sqlite3 for Rails, PostgreSQL for Phoenix)
Both promote security best practices in their default stack
Both ship with a default toolkit for writing and running tests

Differences

With a few similarities, comes major differences. From how you structure your applications, recover from failure, debug your systems, or talk to a remote client, Phoenix takes an approach that few run-times can offer. We embrace Elixir and OTP conventions in Phoenix so that your Phoenix application is only a component of your greater application infrastructure. This deviation from Rails has effects throughout the stack.

Applications

There is no such thing as a "Phoenix application". Your Phoenix projects are first and foremost Elixir applications, which relies on Phoenix to provide part of its functionality. This means there is one way to build, run, and deploy your applications â the Elixir way.

Why it matters: no singletons

In Rails there is a single application that's accessible via Rails.application. Rails runs the show, from starting the application, configuration, and even running command line tasks. As an inherent limitation of this approach, you cannot run two Rails applications side by side. If you need sharing, you need to carefully break it apart into engines and learn a new set of rules.

With Phoenix, nothing is global. There is no monolith. A new Phoenix application will include one Endpoint, one Router, and one PubSub Server, but you are free to add more. With no global state or global servers, you can break your application into pieces as your infrastructure grows.

Why it matters: startup and shutdown

Elixir conventions structure your projects as small composable "applications" that can be started and stopped as a unit. The trail usually goes like this (using Phoenix itself as an example):

Every application has a specification, that may specify which module to invoke when the application will be initialized:
1 2 3 4 5

def application do [mod: {Phoenix, []}, applications: [:plug, :poison, :logger, :eex], ...] end
source

If a module is specified, the start/2 function of this module is invoked:

  
  defmodule Phoenix do
def start(_type, _args) do
  ...
  Phoenix.Supervisor.start_link
end
end

source

The start/2 function must return the identifier of a supervised process, such as Phoenix.Supervisor.start_link above

source

A similar flow happens when stopping your application. The consequence is that it doesn't matter if you are using Phoenix or not, every application has its own and contained start/stop mechanism.

This is a stark contrast to Rails initialization which is extremely complex and requires extensions to hijack a single, sequential initialization flow. For a Rails 4.2.2 app:

  
  $ rails c
Loading development environment (Rails 4.2.2)
irb(main):001:0> Rails.application.initializers.length
=> 74

Those are 74 snippets of code (Ruby blocks) spread around multiple files in a non-specified order! Having control of the initialization logic is extremely important to know exactly what your app is running and to keep boot times fast.

Why it matters: monitoring and introspection

By relying on applications, you gain supervision, fault tolerance, and introspection into your running system. We can easily view our applications running as a unit, or as a whole with tools like observer:

The beauty is, your project will start as a single application and it may (or may not) be broken into multiple applications naturally, be they all running in a single node or in a service oriented architecture. We pay no upfront cost because the runtime is built on tried and true patterns. In fact, we will cover such an example in an upcoming chapter of the Programming Phoenix book.

Request life-cycle

Phoenix provides fantastic performance out of the box, with benchmarks to prove it. The request/response life-cycle in Phoenix differs greatly from the approach Rails takes with Rack.

Why it matters: easy to understand

Explicit > Implicit. Almost Always. Phoenix favors explicitness in most of its stack. For example, when generating your Phoenix application, you can see all the "plugs" your request goes through in lib/my_app/endpoint.ex. Where Rails segregates Rack middleware to a side-loaded part of the application, Phoenix makes all plugs explicit. You have an instant, at-a-glance look into your request life-cycle by viewing the plugs in your endpoint and router.

  
  defmodule MyApp.Endpoint do
  use Phoenix.Endpoint, otp_app: :my_app

  socket "/socket", MyApp.UserSocket
  plug Plug.Static, at: "/", from: :my_app, gzip: false, only: ~w(css images js)
  plug Plug.RequestId
  plug Plug.Logger
  plug Plug.Parsers, parsers: [:urlencoded, :multipart, :json], pass: ["*/*"]
  plug Plug.MethodOverride
  plug Plug.Head
  plug Plug.Session, store: :cookie
  plug MyApp.Router
end

A request starts in your Endpoint, flows through the explicit plug "base middleware", and is handed off to your Router, which itself as just a plug. Then the router applies its own plugs before handing off to a controller, which is (you guessed it!), a Plug. A single level of abstraction throughout the entire stack makes reasoning about your request life-cycle as clear as possible. It also allows easy third-party package integration because of the simplicity of the Plug contract.

Let's compare two very similar looking controllers to see how Phoenix's functional approach with Plug makes the code easier to understand:

controller.rb:

  
  before_action :find_user

def show do
  @post = @user.posts.find(params[:id])
end

def find_user
  @user = User.find(params[:user_id])
end

controller.ex:

  
  plug :find_user

def show(conn, %{"id" => id}) do
  post = conn.assigns.user |> assoc(:posts) |> Repo.get(id)
  render conn, "show.html", post: post
end

defp find_user(conn, _) do
  assign(conn, :user, Repo.get(User, conn.params["user_id"]))
end

Unless you're a seasoned Rails developer, you wouldn't know that show calls render "show.html" implicitly. Even if it was called explicitly, you would have to know that all instance variables are copied from the controller instance to the view instance, which is a layer of complexity that few realize when first getting into Rails development. Convention over configuration is a Good Thing, but there's a threshold where implicit behavior sacrifices clarity. Phoenix optimizes for clarity, in a way that we think strikes a perfect balance with easy to use APIs. Beyond that, as an Object Oriented programmer you must be aware of all the implicit state of the instance, such as the params hash, the request object, and any instance variables set in before_action filters. In Phoenix, everything is explicit. The conn is our bag of data and line of communication with the webserver. We pass it along through a pipeline of functions called plugs, transforming the connection, and sending response(s) as needed.

Why it matters: easy to test

Functional programming and the Plug contract make testing your controllers in isolation, or integration testing your entire endpoint, only a matter of passing a conn through the plug pipeline and asserting against the result. Additionally, controller actions in Phoenix are just functions, without implicit state. If we need to test the controller in isolation, we call the function!

  
  test "sends 404 when user is not found" do
  conn = MyController.show(conn(), %{"id" => "not-found"})
  assert conn.status == 404
end

There's no stumbling with setting up controller instances thanks to functional programming. And when we need to fully integration test through the endpoint, Phoenix just calls the pipeline of functions:

  
  test "shows users" do
  conn = get conn(), "/users/123"
  assert %{id: "123"} = json_response(conn, :ok)
end

Phoenix views follow the same principle as controllers: they are all just functions, there is no implicit data sneaking in!

Why it matters: easy to share code

Once you end-up relying on controller instance variables and methods, a method that you wrote to run in a Rails controller cannot be easily moved to a Rack middleware because it relies on many controller internals.

Since plugs are just functions, you know what is coming in and you know what is going out. There is one abstraction for the entire HTTP stack: whether in the endpoint, router or controller. For example, let's say you want to apply an AdminAuthentication plug to all "/admin" requests, as well as a special DashboardController. We use the same plug at both the Router and Controller levels of abstraction:

  
  defmodule MyApp.Router do
  pipeline :browser do
    plug :fetch_session
    ...
    plug :protect_from_forgery
  end

  pipeline :admin do
    plug AdminAuthentication
  end

  scope "/" do
    get "/dashboard", DashboardController
  end

  scope "/admin" do
    pipe_through [:browser, :admin] # plugged for all routes in this scope

    resources "/orders", OrderController
  end
end

defmodule MyApp.DashboardController do
  plug AdminAuthentication # plugged only on this controller

  def show(conn, _params) do
    render conn, "show.html"
  end
end

Since we use plug at all levels of the stack, we can plug in the AdminAuthentication plug in the Router and controller for fine-grained request rules. In Rails, you would inherit from an AdminController, but the clarity of what transformations apply to your request is lost. You have to track down the inheritance tree to find out which rules are applied and where. In Phoenix, router pipelines make the concerns of your request explicit.

Channels

Phoenix from day one was built to take on the challenges of the modern, highly connected, real-time web. Channels bring transport agnostic real-time connections to your application, which can scale to millions of clients on a single server. This deviates from Rails where historically real-time features have been second-class.

Why it matters: the web is evolving

Phoenix Channels target the Web beyond the browser. The web is evolving to include connected devices (phones, watches, smart toasters) â one of which is a browser. We need a framework that can evolve with changing and new protocols alike. That's why Channels are transport agnostic, with native channel clients available on iOS, Android, and Windows platforms. You can see this in action with a Phoenix chat app running natively on a browser, iPhone, and Apple Watch.

Why it matters: fast performance, with less dependencies

Rails' recent entry into real-time features with Action Cable bring a heavy list of dependencies: Faye, Celluloid, EventMachine, Redis, to name a few. Because Phoenix runs on the Erlang Virtual Machine, Phoenix gets real-time features out of the box from the run-time. The run-time is distributed, allowing Phoenix to skip any operational dependency like Redis to orchestrate PubSub messages across servers.

Naming

Phoenix does not impose strict naming conventions, like we see in Rails.

Why it matters: easy to learn

Phoenix does not tie module names to the filename. Rails requires a UsersController to be located in a file named users_controller.rb. We agree conventions like these are good, but Phoenix does not care about such tight restrictions. Instead we promote sane defaults, but are flexible to individual requirements. Naming also creates a lot of confusion for people who learn Rails first then try to write Ruby applications. Because Rails depends on const_missing to require files based upon the class name convention of file path, knowing how to require files in a regular Ruby application is a bit of a mystery for programmers looking to move their knowledge outside of Rails.

Phoenix includes a "web" directory where you put controllers, views, etc, but it only exists for code reloading purposes which gives you refresh-driven-development.

Phoenix also does not impose singular and plural naming rules. Rails naming rules can confuse beginners and advanced developers alike: models use singular names, controllers use plural ones, URL helpers mix both, and so on. Phoenix consistently uses singular rules, as any other Elixir code. You may use plural names for your tables and router paths, but those are explicitly written at your system boundaries.

Assets

Phoenix uses a tool named brunch by default for handling static assets, but it allows you to bring your own JavaScript build tool, instead of building one specific to the framework, like Rails does with the asset pipeline. Phoenix also leverages its channel layer to provide live-reload of changes out of the box.

Why it matters: ES6/ES2015 is the future

Phoenix promotes ES6/ES2015 instead of CoffeeScript, by supporting ES2015 out of the box for new projects. CoffeeScript served its noble purpose to push the industry forward. ES2015 and its first-class transpilers are the clear way forward.

Why it matters: live-reload is an essential feature

Phoenix ships with live reload out of the box. As soon as you change a .js or .css file, it is automatically reloaded in your browser. Once you add this feature to your development work-flow, it's one you can't live without.

Wrap-up

Regardless of your background, you'll find Phoenix borrows from great ideas that came before it, while using Elixir to carve its own path to take on the modern web.

Ember Best Practices: Functional Programming and the Observer Effect

2015-11-16 00:00:00

My awesome colleagues have written about patterns and best practices we use at DockYard, covering everything from the Ember Object model and better acceptance tests, to native inputs and closure actions.

Today, I'd like to write about something that is close to all our hearts â observers; and a topic I think about a lot â functional programming (FP). I'd like to take you through a tour of refactoring away from observers in your application and freeing yourself from the shackles of the "observer effect". Let's get started!

Side effects wreck projects

In science, the term "observer effect" refers to the changes that are effected on some phenomenon simply by observing it. This is often because of instruments that alter the state of what they observe in some manner.

Sound familiar? Funnily enough, the same effect can probably be found in your Ember application if you use observers. For reasons we'll cover in this post, observers are an anti-pattern and should be avoided, as it makes it difficult to reason about and to debug your application.

Difficult to reason about? Â¯\_(ã)_/Â¯

"Difficult to reason about" is a term that is commonly thrown around â but what exactly does it mean? Informally, it means being able to tell what a program will do just by looking at its code. That is, running the program should not lead to unexpected surprises. We strive to make our applications easy to reason about because it leads to more maintainable code that is easier to debug and test.

That is, running the program should not lead to unexpected surprises.

Since JavaScript isn't a purely functional language, it does not enforce immutability by default. Its mutable data structures can sometimes lead to surprising and unintuitive results (making some JavaScript applications difficult to reason about), so various attempts have been made to introduce immutability to the language.

For example, ClojureScript and Elm are functional languages that compile down to JavaScript. Mori and immutable.js are also excellent libraries that provide immutable data structures you can use in vanilla JavaScript. These tools bring in bits of FP philosophy into JavaScript applications, and have become increasingly popular in front-end development thanks to the introduction of React and the Flux pattern.

The "rise" of FP in front end development

FP is not a new programming paradigm â it's been around for a while since the introduction of LISP in the late 50s. However, it's only in recent times that we've seen FP languages become more mainstream, most notably with Elixir, which combines the elegance and productivity of Ruby with the performance of the Erlang VM.

The combination of Ember's conventions (over configuration), Glimmer, and DDAU means that just like Elixir, Ember developers too can find the sweet spot of having both productivity and performance.

Why is FP useful for building front end applications? React taught us that it is surprisingly cheap to diff the changes on the DOM, and to perform a series of updates to sync the DOM with its virtual representation. In other words, React made its render function a pure one (one of the core principles of FP) â you always get the same output (HTML) for a given input (state).

With the Flux pattern, that is taken a step further and the entire application is treated as a pure function â for a given serialized state, we can predictably render the same output each time. This has allowed Flux implementations like Redux the ability to have a "time traveling debugger", which is only possible when you model your architecture with a FP paradigm.

Object.observe is not the answer

These philosophies have had resounding success, so much so that Object.observe was withdrawn from TC39. All this means is that observing property changes are no longer the best way of building web applications, and Ember in general is moving in that direction with its "Data Down, Actions Up" (DDAU) philosophy.

In 1.13.x, Glimmer landed â it is Ember's new rendering engine based on the same pure render semantics, and gives us fast, idempotent re-renders. The combination of Ember's conventions (over configuration), Glimmer, and DDAU means that just like Elixir, Ember developers too can find the sweet spot of having both productivity and performance.

Data Down, Actions Up

Although you could bring in immutable data structures into your application (a topic for a future post!), that alone wouldn't be enough. We should also strive to make our business logic as pure (free of side effects) as possible. Of course, it wouldn't be possible to make everything pure, as web applications inherently involve mutation (i.e. updating a user record), but it is beneficial to explicitly know and isolate the functions in your app that do have side effects.

In Ember 2.x, the best way forward is "Data Down, Actions Up". This means:

One way bindings by default
Explicit closure actions over side effects
Components should not mutate data directly

My colleagues have already written about one way bindings, closure actions and not mutating data in Components, so I will leave you to do further reading in your own time.

Instead, let's continue the discussion above on how best to refactor away observers in your application, so that we can eliminate or reduce side effects.

Refactoring away observers

Let's say we have an observer in our application that needs to check a user's birthday (demo):

  
  // birth-day/component.js
import Ember from 'ember';
import moment from 'moment';

const { 
  Component, 
  computed,
  get, 
  set
} = Ember;

export default Component.extend({
  isBirthday: false,
  birthDate: null,

  age: computed('birthDate', {
    get() {
      return moment().diff(moment(get(this, 'birthDate')), 'years');
    }
  }),

  checkBirthday() {
    let today = moment();
    let birthDate = moment(get(this, 'birthDate'));
    let isBirthday = (today.month() === birthDate.month()) && 
      (today.day() === birthDate.day());

    set(this, 'isBirthday', isBirthday);
  },

  init() {
    this._super(...arguments);
    this.addObserver('birthDate', this, this.checkBirthday);
  },

  willDestroy() {
    this.removeObserver('birthDate', this, this.checkBirthday);
  }
});

In the above example, we're using an observer to set the isBirthday flag if it is the user's birthday.

  
  {{!birth-day/template.hbs}} 
{{input value=birthDate placeholder="Your birthday"}}

<p>
  You are currently {{age}} years old.
  {{#if isBirthday}}
    Happy birthday!
  {{/if}}
</p>

When you find yourself setting some value (be in on the component, record or somewhere else), you can easily refactor away the observer.

Removing an observer that sets a value on the component

In this scenario, you can simply replace the observer with a CP.

  
  // birth-day/component.js
import Ember from 'ember';
import moment from 'moment';

const { 
  Component, 
  computed,
  get
} = Ember;

export default Component.extend({
  // ...
  isBirthday: computed('birthDate', {
    get() {
      let today = moment();
      let birthDate = moment(get(this, 'birthDate'));

      return (today.month() === birthDate.month()) && 
        (today.day() === birthDate.day());
    }
  })
});

Using component lifecycle hooks

We could also move the input logic out of this component, and use the new component lifecycle hooks to set the isBirthday flag on the component.

  
  // birth-day/component.js
import Ember from 'ember';
import moment from 'moment';

const { 
  Component, 
  computed,
  get
} = Ember;

export default Component.extend({
  birthDate: null,
  today: null,
  isBirthday: false,

  didReceiveAttrs() {
    let isBirthday = this.checkBirthday(
      moment(get(this, 'today')), 
      moment(get(this, 'birthDate'))
    );

    set(this, 'isBirthday', isBirthday);
  },

  checkBirthday(today, birthDate)
    return (today.month() === birthDate.month()) && 
      (today.day() === birthDate.day());
  })
});

  
  {{!index/template.hbs}} 
{{one-way-input 
    value=user.birthDate 
    update=(action (mut user.birthDate)) 
    placeholder="Your birthday"
}}
{{happy-birthday today=today birthDate=user.birthDate}}

  
  {{!birth-day/template.hbs}} 
<p>
  You are currently {{age}} years old.
  {{#if isBirthday}}
    Happy birthday!
  {{/if}}
</p>

Both approaches let you remove the observer, but the didReceiveAttrs example is slightly more explicit, and transforms the component into a pure one. By limiting the scope of the component, we can easily isolate the origins of data mutations.

Removing an observer that sets a value outside the component

In this situation, let's say we want to update the user record's isBirthday flag instead. We can remove the observer by using one way input actions:

By bringing in the ember-one-way-input addon, we can eliminate the coupling of the component to the user record:

  
  // birth-day/component.js
import Ember from 'ember';
import moment from 'moment';

const { 
  Component, 
  computed,
  get
} = Ember;

export default Component.extend({
  // ...
  actions: {
    checkBirthday(birthDate) {
      birthDate = moment(birthDate);
      let today = moment();
      let isBirthday = (today.month() === birthDate.month()) && 
        (today.day() === birthDate.day());

      this.attrs.setIsBirthday(isBirthday);
      this.attrs.setBirthDate(birthDate.toDate());
    }
  }
});

  
  {{!birth-day/template.hbs}} 
{{one-way-input 
    value=user.birthDate 
    update=(action "checkBirthday") 
    placeholder="Your birthday"
}}

<p>
  You are currently {{age}} years old.
  {{#if isBirthday}}
    Happy birthday!
  {{/if}}
</p>

And then in the Controller:

  
  // index/controller.js
import Ember from 'ember';

const { Controller, set } = Ember;

export default Controller.extend({
  actions: {
    setIsBirthday(isBirthday) {
      set(this, 'user.isBirthday', isBirthday);
      user.save();
    },

    setBirthDate(birthDate) {
      set(this, 'user.birthDate', birthDate);
      user.save();
    }
  }
});

  
  {{!index/template.hbs}} 
{{happy-birthday 
    setIsBirthday=(action "setIsBirthday") 
    setBirthdate=(action "setBirthdate")
    isBirthday=user.isBirthday
}}

In the above example, we moved the logic for setting the isBirthday flag out of the happy-birthday component into its Controller. The component no longer needs to directly mutate state (an anti-pattern would be to set user.isBirthday directly in the component), and can instead send a closure action up, leaving the Controller to decide how to handle the actions. Data now flows down to the Component, and any changes to the input sends actions back up.

Who should use observers?

No one.

If observers are so terrible, why are they in Ember? According to Stefan Penner, observers are used by the framework itself as a low level primitive, so that you don't need to use them yourself. So unless you're working on a PR for Ember.js, stay away from observers.

I hope you've enjoyed this post â next week, stay tuned for Doug's post on more Ember 2.x best practices!

Ember Best Practices: Extend vs Mixin

2015-11-09 00:00:00

Code duplication: canât live with it, can live without it. As developers, weâre always trying to find ways to DRY up our code. No matter how big or how small an application, code duplication manages to sneak its way into your files. So far in this Ember best practices series, weâve learned how to write DRYer computed properties and DRYer tests. What about more general application code?

In Ember, there are two main concepts that we can adapt in order to share code between different parts of our application: Ember.Mixin and Ember.Object.extend(). Both of these essentially achieve the same end result, but depending on the scenario, one may be a better bet. Let's look at a brief overview of each one.

Ember.Object.extend()

Deep down, all Ember objects that we create and interact with are an extension of the Ember.Object. Ember.Object itself extends Ember.CoreObject, which includes the Ember.Observable mixin, and it's what gives Ember its "properties and property observing functionality." Without these base objects, there would be no Ember.

We can create a new subclass by calling the extend() method on any Ember object. This will give the new subclass all of the properties of the parent class, as well as any properties defined in the new one. You're also allowed to overwrite any properties found in the parent by defining them in the new class. If you've written an Ember App, you will be familiar with the following:

  
  // routes/index.js

export default Ember.Route.extend({
  // properties and methods
});

In this case, IndexRoute will inherit properties, methods, and anything else defined in the Ember.Route object, as well as everything down its prototype chain:

IndexRoute -> Ember.Route -> Ember.Object -> Ember.CoreObject

Keep in mind that any properties defined in the parent object will be shared among any child object. For this reason, you may want to initialize certain properties inside the init constructor, which gets called whenever an instance of an object gets created. This way, each object instance gets its own unique set of properties.

Ember.Mixin

Unlike the Ember.Object, mixins donât get extended. Instead, they get created via Ember.Mixin.create(). When we include the mixin inside an Ember object, weâre extending the constructorâs prototype. What this means is that like using extend(), any properties or functionality that is defined inside the mixin will be shared among all classes containing this mixin.

  
  // mixins/foo.js
export default Ember.Mixin.create({
  bars: []
)};

  
  // components/A.js
import FooMixin from â../mixins/fooâ;

export default Component.extend(FooMixin);

  
  // components/B.js
import FooMixin from â../mixins/fooâ;

export default Component.extend(FooMixin);

The above will result in both component A and component B sharing the same bars array. Any changes made to the array will be reflected in both components. If you want to play around with this sharing business, you can go here!

Mixin me, Mixin me not...So which do I use?

Ultimately, the decision will differ on a case by case basis. We can think of it in terms of inheritance vs composition.

A base class can usually live on its own or be extended. Inheriting from a parent object will provide the child with the full functionality of the parent, plus any additional properties and behavior that are specific to the child. The child should behave like the parent. Extending works well when you need several variations of a parent object. Take a form, for example. You may have differing templates, but will have mostly the same component logic. Extending each component from a base class would make sense, and their own component-specific properties would be defined in the new subclass.

The thing about mixins is that they encapsulate succint pieces of functionality. The code that they contain can be reused throughout different parts of the application, and is not a concern of any one route, controller, component, etc. They're also meant to be used with other objects, not as a stand alone piece; they don't get instantiated until you've passed them into an object, and they get created in the order of which they're passed in. Mixins can help to avoid long chains of inheritance and adds flexibility if the need for making changes arises.

Mixin example, plz

A good candidate for a mixin? Pagination! Pagination logic is not very extensive and it can be sprinkled throughout an application. Applications tend to need pagination for displaying a number of things; a mixin provides us with the ability to add this to different routes, without caring about the type of model or object that we're trying to display on the page. Let's say we have the following routes:

  
  export default Ember.Router.extend({
  this.route('authors');
  this.route('blog', function() {
    this.route('comments');
  });
});

All of these routes need to have pagination built-in. Even though the routes are not related, we can utilize the same pagination mixin for all of them. Each of these three routes will have to include the mixin like so:

  
  import PaginationMixin from '../mixins/pagination';

export default Route.extend(PaginationMixin);

Extend example, plz

A good candidate for extension? Authentication! More often than not, we need two different types of routes: authenticated and unauthenticated. The best way to handle this is to create a base class for each of those (or just one, depending on your needs!), and extend the routes which need the particular functionality. If we have the following routes,

  
  export default Ember.Router.extend({
  this.route('blog');
  this.route('account', function() {
    this.route('profile');
    this.route('settings');
  });
});

  
  // routes/authenticated.js

export default Ember.Route.extend({
  // check for session & transition accordingly
});

in account/index.js we would just extend authenticated.js

  
  // account/index.js

import AuthenticatedRoute from 'routes/authenticated';

export default AuthenticatedRoute.extend();

Doing this will make sure that account and any child route is off limits to users who are not signed in. We simply apply this same pattern to any other parent routes that need authentication. If we were to use a mixin instead, we would end up with having to import the mixin all over the application - and you're more likely to forget to add it.

Sum it up!

Hopefully this has helped in better understanding the differences between using Ember.Object.extend() and Ember.Mixin as it's not always black or white on whether to use one concept over the other. Ask yourself what the intent of the code is, where and how often it's going to be used, and make your best judgement. All in all, stay DRY!

CSS Dev Conference 2015 Thoughts

2015-11-05 00:00:00

As a UX Developer I specialize in HTML/CSS so a CSS developer conference could not have been any more perfect. Three DockYarders, including myself, had the opportunity to go to CSS Dev Conf last week aboard the Queen Mary in LA.

The talks went beyond my expectations and I learned something different at each one. Even with new content being presented it was good to see that the tools and opinions of the speakers were all aligned with how we structure HTML/CSS at DockYard.

The most interesting event at the conference was the open question session at the end of day 2. All the speakers got on stage at once and the audience could go to a microphone in the middle of the room and ask the group any question that came to mind. There were some great insights shared about what CSS developers should expect to see from the job market and what the future of CSS will look like.

The Queen Mary was amazing to stay on throughout the conference and I have to give a shoutout to left shark, right shark and the giant octopus at the after party. Could not have asked for a better venue. Who wouldn't want to go to a conference on a boat?!

Here are my takeways from the conference!

Keynote Sara Soueidan

Twitter: @SaraSoueidan

Slides: SVG For Web Designers (and Developers)

Use SVGs for everything possible and provide fallbacks for browsers that need it
Keep in mind you need to look at performance, donât choose SVGs over performance

SVG forâ¦

Icon systems
Add banners
Infographics
Data visualizations
Animated illustrations
Filter effects
Simple UI shapes

Future

CSS Spec custom add SVGs rules coming soon

Designing SVGs

Every design decision that is made while designing an SVG affects development
Developers and Designers need early communication and have some give and take to make both their lives simpler

Process

Outline text that has been changed into vectors are not selectable
Outline text preserves font-face
Use simple shapes over a <path>
- easy to maintain
Simplify your paths when you use them with simplify path tool in Illustrator
Only combine paths if you donât need sections to be separate for animation or coloring
Use organized naming/layer conventions in your SVG code
Designers should use SVGs filters that are available in Illustrator effects section
Always keep width and height attributes on the <svg>
- Great for fallback

Optimize

Most popular tool is SVGO but will change the structure of the SVG, also can break your SVGs :( so use the GUI version with custom options
Optimizing your SVG can cut your files size by half
Illustrator in the future will have optimize options
Sketch has no options yet :(

Development

<symbol> and <use>
- Multiple <symbol> elements being combined into one SVG, always include <title> and description for accessibility
- This technique puts the SVGs code in a shadow DOM that is difficult to style
- You can leak styles in with CSS variables var(--prime-color)
Use SVGs viewbox to create a view window that only shows a portion of the SVGs file. Also known as the sprite technique
- Place your SVG files into the CSS as background-images
- support back to IE6
Use CSS only for simple animations
Use JS for complex animations

SVG over icon fonts

Infinite scale and easy styling
Browser content blockers will block fonts and not SVGs
Tools for switching from icon-fonts to SVG are out there.
Greensock animation library is a go-to
<object> is most flexible embedding technique for SVG

Cracking the SVG Code: Brenda Storer

Twitter: @brendamarienyc

Slides: Cracking the SVG Code

Queen Mary is in the top 10 most haunted places in the world. Over 150 spirits on the boat
Whats inside a SVG? XML!
- It's like HTML but for digital drawings instead of content
SVG 1.0 became recommended in 2001 by W3C
SVG 2.0 maybe in 2018 :)
viewBox defaults to px if no value is given
viewBox="0 0 100 100" start x start y end x end y
For inline SVG remove all unneeded markup that is inserted by Illustrator
<g> is the <div> of SVGs
Stroke = CSS border and fill = CSS background-color
GO Shapes! <rect>, <circle>, <ellipse>, <line>, <polyline>, <polygon>
In Illustrator you can select what you want to be a SVG and then shorthand copy it, then paste in your text editor
- This also starts your viewBox at 0 0 !!!
Transforms on SVG is not 100% supported with your .css file but if you include the transform inline style its 100% supported
Checkout SVG Compressed book online

Creative Typography with SVG: Brenna OâBrien

Twitter: @brnnbrn

Slides: Creative Typography With SVG

VREAM - viewBox Rules Everything Around Me
SVG easy to manipulate with CSS and JS
Text becomes completely responsive when inside a SVG
Go on a code adventure with SVG you will find new things

SVG has a `<text>` element

<text> is accessible!
- Inherits font-family from <body>
- Use fill to change color
- y="0"is not good, use y=â1emâ
- font-size="80" is 80px

`<tspan>`

similar to <span>
use x and y for positioning

Curved text

use <textPath> and then link it to a <path> that is inside your <defs> with a xlink:href="pathName"

Gradients on text

<linearGradient> in your <defs>
In your fill on the <text> use fill=âurl(#grad)â

Images on text

Can put your <image> inside a <pattern> under your <defs> and apply the pattern to the fill on your <text>
You can also fill text with gifs :)

Knockout text

Place your <text> in a <mask> and then apply the mask to your element you want the text to be in as mask="url(#knockoutText)"

Self Typing Text

Use <animate> as a child of what element is being animated with from and to with a duration

Morph Text Glyphs

Convert your text to paths with Illustrator outlines

Self drawing text

stroke-dasharray and stroke-dashoffset are used to âhackâ this effect

Designing Complex SVG Animations: Sarah Drasner

Twitter: @sarah_edo

Slides: Designing Complex SVG Animations

Why make complex animations?
- powerful to convey meaning
- fun :)
Animation should be designed and not an afterthought or it will look like sugar on top animations
One size does not fit all, look at your website and limitations
Checkout Val Headâs âAll the Right Movesâ
When designing complex animations try to design everything first and then apply the animations
Ugly storyboards save you time (even if ther're ugly)!
SVG has less HTTP requests
Optimize your SVGs!
But donât overdo the amount of animations you include on your website, simplicity is key

UI/UX Animation

This is used to enhance the information on the page

Context-Shifting

This removes the breakpoints of information being loaded on the page
Use animation to fill time while loading to keep the users mind at ease
Provide clear focus on what the user should be reading or looking at

Standalone

Questions to ask
- Responsive?
- toggle on/off?
- Easing structures
- User flow
Easing can contribute to your branding
- You can convey emotion with how you animate elements
Animation branding guidelines make communication down the line easy

Animation performance

Test everything yourself
People expect everything to be faster on the web

SVG sprites complex to simple

Design your three steps for desktop, tablet, and mobile
Combine elements where you can so you have less SVGs elements you need to hide when going between views
Use animation media queries
viewBox shift with JS
provide fallbacks

Complex animations

Use JS to make this easy
Use Greensock
If you need more then 2-3 chained events in your animation its a good idea to use JS
Relative color tweening
- Example: shifting from day to night scenes
Motion along a path is important for realism
Responsive animations should be made with thought as you place the elements in DOM

Design + Animation + Data

Combining these things can bring back the success of static infographics used to have
We can make them responsive and interactive with SVG
Add accessibility with <title> tags
Go CodePen! Easy to learn new things when you can dive into other peoples code

The Dark Arts of Light Speed: Henri Helvetica

Twitter: @HenriHelvetica

Slides: The Dark Arts of Light Speed

Web performance = speed
Font-end development suffers from the embarrassment of riches
57% of visiters will abandon a page after 3 seconds of not loading
User experience metrics over network-based metrics
Need a culture based on building apps for performance
Placing defer in your <script> tag will download JS at the same time as HTML but execute JS at the end of the HTML loading
- async will download JS and load HTML at the same time but pause the loading of HTML when the JS download finishes to execute it
Donât send larger images to mobile when you donât have to, it waists bandwidth on phones
<srcset> <picture> you can use media queries inside them to load images for specific VW
Reduce the number of HTTP requests with combining .css files into one and .js files into one

No Pain No Gain: Stacy Kvernmo

Twitter: @funstacy

Slides: No Pain No Gain

Build a culture of code review in your workplace
- Catch bugs
- Increase familiarity of the project with your team
- Education! communication with your team on why you did what you did will tach you to explain things simply
Review the compiled code when you use pre-processors
Contributing to open source is great and try to repay the contributor somehow
Stay positive during code reviews
Avoid absolute terms when commenting
- Must
- Always
- Never
Ask questions about why the person coded a certain way
Document the issues you find
Document your code with comments
A pull request should say what you did very clearly

What to review

Follow standards
Is the code easy to understand
Donât need to nest everything, donât go as far as 3-4 levels deep
Accessibility
Using correct vendor prefixes?

Keynote Jina Bolton

Twitter: @jina

Slides: Designing a Design System

Communication between Designers and Developers is important
designing systems rather then pages
style guides should be living and constantly updated
designprinciplesftw.com
Donât make things until you need it

v2mom

vision
values
methods
obstacles
measures

Keynote Val Head

Twitter: @vlh

Slides: Designing Meaningful Animation

With new tools we have the ability to make accessible responsive and beautiful animations for the web!
Using motion in our design language is important
When you have motion across all platforms it provides a more recognizable interface for the user
Be subtle with movements, a little will go a long way

CSS Architecture: Jonathan Snook

Twitter: @snookca

Slides: CSS Architecture

Build modular systems
INLINE STYLES WON'T SAVE YOU FROM INHERITANCE
Donât write multiple of the same rule for one element
Future we can us all: inherit on an element to ignore all inherited styles
Element queries can be used but you need JS to accomplish this
Design has a cost on the web just like it does in print
Every peace of design ends up in code
You can use emojis as class names :P

Categorization of styles

state
Theme
module
layout
base

Naming conventions

Use them!
SMACSS
BEM
The goal is to isolate an element from everything else on the page

Create Standards For Your CSS

Without standards and code reviewing, CSS will get out of control
Styleguides.io is a great resource

Future

Web components
Composable UIs
Communicate!

Bower Power! Supercharging Front-End Manageability: Eric Carlisle

Twitter: @eric_carlisle

Slides: Bower Power! Supercharging Front-End Manageability

Keep It Stunningly Simple (KISS)
You get a happy team
Better products, process, reduce cost
Donât be afraid to use npm and bower

Bower keeps it simple

Maintains a dependency manifest
Fetches them when you need it
Tracks dependencies
Integrates with everything

You need

Node.js Javascript runtime
npm, Node.js package manager
git, version control

Starting the awesome

npm install -g bower
bower init

Installing dependencies

bower install dependenciesName
add a --save after install to save that dependency for the project
add a --save-dev after install to save that dependency for development or debugging
Add bower_components to .gitignore!!

Fight the Zombie Pattern Library: Marcelo Somers

Twitter: @marcelosomers

Slides: Fight the Zombie Pattern Library

âHow do you keep building interfaces knowing thats what the world is likeâ
Pattern library accelerate both the design process and development process
Photoshop has libraries that you can make/use in multiple files/projects
- You can do this in teams also
Traditional handoff between designers and developers is broken
Use pattern libraries as the connection between the groups
Libraries eliminate waste
This reduces tweaking static comps to make one small change but rather make one change to an item in a library
You want an automated library or a team managing your libraries

Get started today

Take an inventory
Take documentation
- Base styles
- Components
- Page templates
Focus on standardizing what you find
Define CSS standards
- Refactor to perfection
- Namespace the CSS
- Donât forget about JavaScript applying classes
Govern your library
Open source culture
- opencss.klamp.in

Pattern Library Tools

Writing CSS documentation with KSS
- will auto document comments in your .css file
Pattern lab on GitHub

The better way

patternpack
- what it does
- Build your static site
- Increment your version
- Create a new commit
- Tag the commit
- Lets you share the code to multiple applications
- Keeps versions of the design
- Start new project with npm init and git init
- Install npm install --save-dev pattern-pack
- Start with grunt patternpack run
- Create your first patter with a .md and .css file
- .md is the documentation for the equivalent css file
- Use semantic versioning for your pattern pack
- Publish your patternpack
- grunt pattern pack:release
- git push âfollow-tags

Web Components and the Future of Modular CSS: Philip Walton

Twitter: @philwalton

Slides: Web Components And the future of Modular CSS

Good news is that web components were primarily a google effort but not all vendors are on board but could be available sometime in 2016
Your selectors are the biggest determining factor in how scalable your code is

Whats changed?

Multiple shadow roots have gone away
createShadowRoot() is now attachShadow(mode)

CSS is hard

Manage global names
Scoping/isolating styles
Specificity conflicts
Unpredictable matching
Managing styles dependencies
Removing unused code

What is CSS missing

Scope or isolate styles to a particular set of DOM nodes
Ability to abstract away implementation details
Goooo Web components! They do this
You donât want to have to depend on tools that everyone has to learn
No ecosystems

The Anatomy of a Web Component

Elements in a shadow DOM
- Its a subtree of a DOM node that canât be styled by CSS
- Shadow nodes are private
Custom elements
HTMl imports
The template element

Keynote Dave Rupert

Twitter: @davatron5000

Slides: The Art Of Being Wrong

Woot Shop Talk show plug
Working on godaytrip.com
Remove the must doâs and âfactsâ from statements online on twitter or medium
what you think you know about dinosaurs is WRONG!
Be afraid of the Donald Trump effect where you believe bullshit if it is said loud and long enough
Donât spell Sass or SASS wrong or the internet will bring the pitchforks, aka people should not fight about every little thing on the web
You donât have to be right all the time and you donât have to correct people on everything all the time

Data visualization workshop

2015-11-03 00:00:00

Iâm very excited to host UX East's next workshop on data visualization here at DockYard! I received my Masterâs degree earlier this year from Northeasternâs Information Design and Visualization program, and data visualization is one of my favorite things to geek out about.

There are many interesting parallels between UX design thinking and the process around creating data visualizations. This workshop will be a comprehensive overview of that process, with a special focus on context and experience. Together, weâll explore a dataset (a very interesting one!), create a story around a target audience, use the data to define appropriate visualization methods, and storyboard the experience.

Creatives and makers of all types and skill levels are encouraged to come. During this workshop, weâll manually look through the data and sketch our explorations. No background in engineering or design is needed, but we can discuss digital visualization tools for those who are interested. Itâll be a very fun collaborative evening.

To give you a taste of some of the examples to come - here are a few of my favorite data visualizations that create very different experiences. Many more will be included in the pre-workshop presentation about data visualization basics and best practices.

âCSIS data chandelierâ - SoSoLimited

âWhatâs really warming the world?â - Bloomberg

Dear Data - Stephanie Posavec and Giorgia Lupi

Come make with us! If you have any questions about the workshop, please feel free to email me. Hope to see you there!

Ember Best Practices: Stop bubbling actions and use closure actions

2015-10-29 00:00:00

Back in January, I talked about bubbling actions through components so that you could nest components and have an action be triggered from the depths of your inner component. This involved passing actions down through your components, and then using sendAction to trigger the action at each level until you got all the way out of your nesting. With the introduction of closure actions, you end up passing actions down, but no longer have to bubble out.

Actions down

Let's look at the example from the previous blog post again:

  
  {{! index.hbs}}
  {{pressCount}} Button presses
  {{button-wrapper action="buttonClick"}}

{{! components/button-wrapper.hbs}}
  <h2>Button Wrapper</h2>
  {{press-button action="buttonClick"}}

{{! components/press-button.hbs}}
  <button {{action "buttonClick"}}>My Button</button>

Notice how we we are using the action="buttonClick" above the press-button component to pass the action down. We end up calling this.sendAction() in both components so that the button 2 levels deep calls the action defined in the index controller.

What if I told you that you only need to define the templates for the components, and no longer need to have any actions defined within the components themselves?

  
  {{! index.hbs}}
  {{pressCount}} Button presses
  {{button-wrapper click=(action "buttonClick")}}

{{! components/button-wrapper.hbs}}
  <h2>Button Wrapper</h2>
  {{press-button click=(action click)}}

{{! components/press-button.hbs}}
  <button {{action (action click)}}>My Button</button>

Closure actions are called by using the action helper, which in turn passes down the function to the component, defining it at <property name>, just like other properties passed to your component.At the bottom, the <button> action just calls the action, and the controller action is the same as before. You can see it in action here. There is no code backing the component at this point.

Ok, what if I wanted to do something a bit more complicated

This is where closure actions really show off. With closure actions, you can have the function you pass in to the action return a value. This was previously impossible because the return value of a function was used to determine if the action should bubble. This also highlights one of the potential gotchas you may encounter when you first start using closure actions: they don't bubble. If you use a closure action, it won't bubble out of the controller/component. If you need this behavior, you need to call this.send in the controller to fire an action that will be triggered in your route. Here is an example. Note that the name of the action sent is different than the action called, you'll end up in an infinite loop if you try to this.send('buttonClick'). When routeable components land, you'll likely end up passing the route action into the component using closure actions, so unless you really need route actions with closure actions, I would recommend against leaning on this example.

Can you do anything cool with closure actions?

Yes, you can now curry! You can pass multiple arguments to the action helper at each level. Those arguments are added to the function at each scope. Let's look at a bit of code to make this clearer:

  
  {{! index}}
    Things: {{things}}
    {{cat-wrapper class="button-wrapper" click=(action "buttonClick")}}
    {{dog-wrapper class="button-wrapper" click=(action "buttonClick")}}

{{! components/cat-wrapper.hbs}}
    <h2>Cats</h2>
    {{press-button count=1 class="press-button" click=(action click "cat")}}
    {{press-button count=2 class="press-button" click=(action click "cats")}}

{{! components/dog-wrapper.hbs}}
  <h2>Dogs</h2>
  {{press-button count=1 class="press-button" click=(action click "dog")}}
  {{press-button count=2 class="press-button" click=(action click "dogs")}}

{{! components/press-button.hbs}}
  <button {{action (action click count)}}>{{count}}</button>

Notice how we pass cat/cats/dog/dogs to the action of each press-button in the cat-wrapper and dog-wrapper component, but in the press-button component, we just pass the count to the action helper after passing it the function we want to call. The function that is called in press-button has the signature function(thing, count), so if we click the first cat button, the buttonClick action in the controller is called with 'cat' as the first argument, and count as the second argument. Here is a living version of this example.

What if I don't use the action helper in my deepest component?

All the examples so far use the action helper in press-button, but if you wanted to call your action manually, you'd just call click() to call the function passed into the component. Here is an updated version of the currying example that uses an action in the press-button component. We still pass the argument to the curried function.

Functions Down, Actions up

With the introduction of closure actions in Ember 1.13, we gained a powerful way of passing data down in the form of functions to push data up and out of our components. This was possible before, but it was also a lot more work. You'd have to manually bubble actions all the way out, but now we punch a hole down to our deepest component and fire the action directly from there. This will lead to easier debugging, as the sendAction way was a lot harder to grok where your component actions were breaking.

How long it took to convert our team from Rails to Phoenix

2015-10-29 00:00:00

One week.

That is how long it took for our engineers, who had all (but one) worked with Rails for a few years, to be productive on a new Phoenix client project.

I had assigned each of them to read Part 1 of Dave Thomas' Programming Elixir book which was only 160 pages of material. Part 1 introduces early Functional Programming concepts and the Elixir standard library. In my mind, this is enough to make the switch.

âIt was cool being able to contribute to a Phoenix app without prior experience with the framework thanks to the similarity in structure with Rails. Elixir is the biggest hurdle, but a quick read through the key concepts is enough to make you productive - not to mention learning a new language is fun!â

-- Romina Vargas, DockYard Engineer

At the higher level of writing actions, routes, tests, models, queries, etc... there is so much overlap with the concepts that exist in Rails that it was simply a matter of syntax that had to be learned before a Rails engineer could make contributions back to Phoenix applications.

There is no doubt that Phoenix borrows a lot of concepts and structure from Rails. For good reason, Rails nailed the MVC app pattern. The benefit here is that a lot of that domain knowledge on how to build Rails apps can be transferred over to building Phoenix apps.

âRuby on Rails had a pretty steep learning curve. Not only did I have to study a new programming language, I had to master the MVC framework as well. But with RoR under my belt, the learning curve for Elixir and Phoenix was significantly reduced. Plus pattern matching makes everything way easier!â

-- Marin Abernethy, DockYard Engineer

Now, don't get me wrong. I am not suggesting that after this one week that you should be ramped up on the complexities of Elixir and the Erlang ecosystem. I think there is enough to Erlang that could take years to fully absorb. But that's not the point.

The best way to write a faster Rails app is to write it in Phoenix.

Get in touch with us if you'd like to move from Rails to Phoenix. We can help!

Validating your Ecto Models with ValidField

2015-10-26 00:00:00

When we were working with Rails, we would unit test our validations with a libary called ValidAttribute. This library would allow you to specify the attribute and a list of values then check if the values yield errors or not. On a recent client project, I resurrected the pattern and extracted it as a Phoenix library this weekend.

Introducing ValidField

Let's import ValidField and get right to the tests:

  
  defmodule App.UserTest do
  import ValidField
  use ExUnit.Case
  alias App.User

  test ".changeset - Validations" do
    with_changeset(%User{})
    |> assert_valid_field(:email, ["something@else.com"])
    |> assert_invalid_field(:email, ["", nil, "test"])
    |> assert_valid_field(:password, ["password123!"])
    |> assert_invalid_field(:password, [nil, "", "test", "nospecialcharacters1", "nonumber!"])
  end

  test ".changeset - Validations - complex changeset" do
    with_changeset(%User{}, fn (model, params) -> App.UserController.changeset(model, params, :insert))
    |> assert_valid_field(:email, ["something@else.com"])
  end
end

First, we use with_changeset/1, which takes the model struct as the sole argument and returns a map that contains an anonymous function that yields a changeset from Model.changeset. with_changeset/1 assumes that your changeset is defined at Model.changeset/2. If your changeset is defined elsewhere or has additional arguments, you'll want to use with_changeset/2. The first argument of with_changeset/2 is still the model struct, but the second argument is a function with an arity of 2. The first argument to the function will be the model struct passed in, the second argument will be a map of field values to be set in the changeset.

After we have a changeset map, we pass that as the first argument to assert_valid_field/3 and assert_invalid_field/3. Instead of returning a boolean of whether or not the field is valid for the list of values passed in, these functions run the assertions internally. This is done to provide useful testing errors when running mix test. Assume that you inverted the third line of the test to be the following (and didn't change your validations), the following error will be generated:

  
  defmodule App.UserTest do
  import ValidField
  use ExUnit.Case
  alias App.User

  test ".changeset - Validations" do
    with_changeset(%User{})
    |> assert_valid_field(:email, ["something@else.com"])
    |> assert_valid_field(:email, ["", nil, "test"])
    # (ExUnit.AssertionError) Expected the following values to be valid for "email": nil, "", "tests"
  end
end

OK, I see what you did there but why?

Clean workflow for unit testing changesets

By grouping all the valid and invalid cases in your tests, you can quickly understand what makes your changeset valid. It also allows you to update your tests by just adding another value to either function call. Say you want to stop accepting Gmail address as valid email address; you just add some-email@gmail.com to your assert_invalid_field call for email, and update the tests to satisfy this new requirement. We aren't worried about the error message anymore.

Less brittle tests

Most unit tests around changeset validations use the error_on function and assert that the field and a specific error message are contained in the list of errors provided. This is a decent starting point, but has a couple of drawbacks. The first is that your test is tied directly to the error message, meaning that changing a validation message requires you to update your test. A correction to a gramatical error would cause a test failure, showing how brittle this pattern could be. What if you support multiple languages? Since your error messages might be different for an email that contains a space or one that doesn't contain a valid domain, your tests will be more verbose since the messages need to be matched individually.

With ValidField, you are testing the behavior of your changeset, rather than the implementation of your error messages.

Go forth and test your changeset

Making sure your changeset is properly defined is important, and ValidField makes it much easier to unit test them. Having the list of valid and invalid values for your field in your tests also serves a documentation of what should be accepted for a given field as well.

Ember Best Practices: Computed Properties with Dynamic Dependent Keys

2015-10-23 00:00:00

In Ember, computed properties allow you to declare functions as properties. More often than not, you're going to have a set of dependent keys which invoke a function when their values change:

  
  const Team = Ember.Object.extend({
  city: null,
  league: null,
  name: null,

  fullName: Ember.computed('city', 'name', {
    get() {
      return `${Ember.get(this, 'city')} ${Ember.get(this, 'name')}`;
    }
  })
});

const redSox = Team.create({
  city: 'Boston',
  league: 'American',
  name: 'Red Sox'
});

Ember.get(redSox, 'fullName'); // "Boston Red Sox"

In the example above, fullName is dependent on city and name, so it watches those properties, and when either of their values change, its get function is invoked, thereby returning the updated fullName property for our beloved baseball team.

What if you wanted to write a computed property that didn't know what keys it needed to monitor until runtime?

In our contrived examples below, our model is an array of baseball teams which will be passed to a component.

  
  import Ember from 'ember';

const Team = Ember.Object.extend({
  city: null,
  league: null,
  name: null
});

export default Ember.Route.extend({
  model() {
    return {
      teams: [
        Team.create({ league: 'American', city: 'Boston', name: 'Red Sox' }),
        Team.create({ league: 'American', city: 'New York', name: 'Yankees' }),
        Team.create({ league: 'National', city: 'Los Angeles', name: 'Dodgers' }),
        Team.create({ league: 'National', city: 'San Francisco', name: 'Giants' })
      ]
    }
  }
});

In a component, we're going to separate our American League teams and our National League teams.

  
  {{league-teams leagueData=model}}

  
  // league-teams/component.js
import Ember from 'ember';

export default Ember.Component.extend({
  americanLeagueTeams: Ember.computed('leagueData.teams.@each.league', {
    get() {
      const teams = Ember.get(this, 'leagueData.teams');
      return teams.filterBy('league', 'American');
    }
  }),

  nationalLeagueTeams: Ember.computed('leagueData.teams.@each.league', {
    get() {
      const teams = Ember.get(this, 'leagueData.teams');
      return teams.filterBy('league', 'National');
    }
  })
});

We have two computed properties in our component. The first one pulls the American League teams and the second pulls the National League teams. The functions performing this work are virtually identical with the exception of the value against which they are filtering (i.e., "American" and "National"). Let's DRY this code up a bit:

  
  import Ember from 'ember';

function filterByLeague(value) {
  return Ember.computed('leagueData.teams.@each.league', {
    get() {
      const collection = Ember.get(this, 'leagueData.teams');
      return collection.filterBy('league', value);
    }
  });
}

export default Ember.Component.extend({
  americanLeagueTeams: filterByLeague('American'),
  nationalLeagueTeams: filterByLeague('National')
});

That refactor removes a bit of code duplication, but we can go further. Rather than leaning on the static dependent key of leagueData.teams.@each.league, we can make the filterByLeague function more generic if we can just pass in the key we want to filter on:

  
   import Ember from 'ember';

 function filterCollectionByValue(collectionKey, propName, value) {
   return Ember.computed(`${collectionKey}.@each.${propName}`, {
     get() {
       const collection = Ember.get(this, collectionKey);
       return collection.filterBy(propName, value);
     }
   });
 }

 export default Ember.Component.extend({
   americanLeagueTeams: filterCollectionByValue('leagueData.teams', 'league', 'American'),
   nationalLeagueTeams: filterCollectionByValue('leagueData.teams', 'league', 'National')
 });

ES6 allows for string interpolation. This means that we can pass in the key we want to filter by and also watch it as the dependent key. If we need to filter a collection based off of keys other than league in the future, we can use this generic filterCollectionByValue() util rather than creating a unique filterByX() function for each key.

Another dimension to the idea of dynamic dependent keys is the ability to watch an arbitrary number of them. The macro computed property getPropertiesByKeys() does just that. This function allows you to provide an arbitrary number of dependent keys and return their values:

  
  export function getPropertiesByKeys(...dependentKeys) {
  const computedFunc = Ember.computed({
    get() {
      return Ember.getProperties(this, dependentKeys);
    }
  });

  return computedFunc.property.apply(computedFunc, dependentKeys);
}

As you can see, this macro is more or less relying on Ember's getProperties() method, but it allows you to specify the dependent keys at runtime.

Leveraging dynamic dependent keys in computed properties opens the door to greater refactoring. These helper functions which return a computed property can be moved into a computed property macros util and imported as needed throughout your project.

Better yet, let my esteemed colleague, Lauren Tan, do the work for you! Her ember-macaroni library wraps up many of the macros we use at DockYard in a convenient Ember addon.

Chris McCord is a DockYarder

2015-10-21 00:00:00

I'm very happy to announce that Chris McCord, the creator of the Phoenix Framework, has joined the DockYard team!

We've been working with Phoenix for nearly a year now. We love it. So much so that we dumped Ruby on Rails and doubled down on Phoenix and Elixir as the future. With Chris joining our team we hope to invest heavily in that future.

Chris' primary responsibility at DockYard is to continue building Phoenix and make it the best choice for backend frameworks. He will be available for consulting through DockYard in limited capacity but his knowledge is already making its way through our team.

If you have a project in Phoenix we'd love to chat.

Ember Best Practices: Don't Don't Override Init

2015-10-19 00:00:00

The double negative in the title of this article is a jab at another article I wrote nearly a year and a half ago: Don't Override Init. In that article I advocated for never overriding the init function for your Ember.Object derived classes, instead using Ember.on to kick off a function call for what you'd normally put into init. At the time I still believe this was a good recommendation. But times they do change, and now that we're all happily using es2015 features via Babel we get access to the great spread operator.

Here is how we are now writing our init functions:

  
  export default Ember.Object.extend({
  init() {
    // our custom code
    return this._super(...arguments);
  }
});

This is a very clean approach. More importantly: it is more performant. Ok, but what if you were using several Ember.on calls? That's easy, just break them into functions:

Before:

  
  foo: on('init', () => {
  // ...
}),

bar: on('init', () => {
  // ...
}),

baz: on('init', () => {
  // ...
})

After:

  
  init() {
  this._super(...arguments);
  this.foo();
  this.bar();
  this.baz();
});

Bonus points for taking back control of execution order.

You don't always have to return this._super(...arguments); but in most cases you should.

If you are using ember-cli and you using Ember.on for init-like functionality you should consider this approach instead. Do Override Init!

Ember Best Practices: Actions Down, Data Up... wait what?

2015-10-14 00:00:00

Welcome back to the fourth installment of DockYard's Ember Best Practices Blog Post Series! Last time Aaron Sikes explains why we can move away from the Ember {{input}} helper with angle-bracket components and improved actions. Aaron briefly discusses "Data down, actions up", the topic of this post. So if you want a bit of context, stick around here for a minute then head over to his post afterwards.

Data Down, Actions Up

Two-way data binding is what originally attracted many to Ember.js. Data changes that affect the model are immediately propagated to the corresponding template, and conversely, any changes made in the UI are promptly reflected in the underlying model. Magic! This conveniently removes unnecessary boilerplate code.

However, when employed in large scale and complex applications, two-way data binding can often become more of a headache than a blessing. Have you struggled with where to mutate your data? Have you spent an excessive amount of time tracing the source of mutated data? You are not alone. The Ember core team in their quest for continuous growth and improvement, has decided that in Ember 2.X, one-way bindings will be the default. And the ability to opt in to two-way data binding will be provided. This new adopted data flow model will simplify communication between components and can be encapsulated in the phrase: "data down, actions up".

That's all well and good, but what does that actually look like in the wild?

Enough jabbering and show us!

Let's build an app together. Our app will be a simple budgeting tool. Picture the money managing application, Mint, and more specifically an elementary version of its budgeting feature.

  
  // application/index/route.js

import Ember from 'ember';

export default Ember.Route.extend({
  model () {
   return this.store.findAll('expense');
  },

  setupController(controller, model) {
    controller.set('expenses', model);
  }
});

Assume our server responds with a list of expenses, where each expense has a category and amount. In our template we provide an input box for the user to tell us their income. Then we iterate over the expenses, wrapping each expense in a component. And lastly, we display their total remaining money (income - expenses).

  
  {{! application/index/template.hbs }}

<h4>Income:</h4> 
{{input class="income-input" type="integer" value=income}}

<table class="expenses">
  <tbody>
    {{#each expenses as |expense|}}
      {{expense-summary expense=expense}}
    {{/each}}
  </tbody>
</table>

<h4>Total: {{total}}</h4>

  
  // application/index/controller.js
import Ember from 'ember';

export default Ember.Controller.extend({
  income:  0,
  total: Ember.computed('expenses', 'income', {
    get() {
      const amounts = this.get('expenses').mapBy('amount');
      const expenseTotal = amounts.reduce((previousValue, currentValue) => {
        return previousValue + currentValue;
      }, 0);

      return this.get('income') - expenseTotal;
    }
  })

In each row of our expenses table, we have an expenseSummaryComponent that displays the expense category, provides an input box for the expense amount, and has a "Save" button.

  
  {{! expense-summary/template.hbs }}

<tr>
  <td>{{expense.category}}</td>
  <td>{{input type="integer" value=expense.amount}}</td>
  <td><button {{action 'amountChanged'}}>Save</button></td>
</tr>

In our expense-summary component we implement the amountChanged action.

  
  // expense-summary/component.js
import Ember from 'ember';

export default Ember.Component.extend({
  actions: {
    amountChanged() {
      const expense = this.get('expense');
      expense.save();
    }
  }
});

Yay! Done! However, we forgot something - we haven't applied our new mantra, "data down, actions up", to this code yet.The issue is that the expenseSummaryComponent is updating the data (expense.amount), but the data should solely belong to our IndexController. Not only did the IndexController give the expenseSummaryComponent the expense data, but it also uses the expenses data to calculate the total. Meaning, if the IndexController was out of sync and had stale expense data, it would be displaying the incorrect total. While that may not be a huge concern in this simple scenario, it can be really difficult to trace in more extensive and intricate applications.

The Better Way

Instead we need to pass an action to our expenseSummaryComponent.

  
  {{! parent component: expense-table/template.hbs }}

<table class="expenses">
  <tbody>
    {{#each expense in expenses}}
        {{expense-summary expense=expense amountChanged="update"}}
    {{/each}}
  </tbody>
</table>

The expenseSummaryComponent template looks the same as before. But this time, the action amountChanged, called when the user clicks the "Save" button in the component, will look different.

  
  // expense-summary/component.js
import Ember from 'ember';

export default Ember.Component.extend({
  actions: {
    amountChanged() {
      const expense = this.get(this, 'expense');
      this.sendAction('amountChanged', expense); 
    }
  }
});

The update action is now sent up to the parent Component or Controller, along with the expense as a parameter.

  
  // application/index/controller.js
import Ember from 'ember';

export default Ember.Controller.extend({
  ...

  actions: {
    update(expense) {
      expense.save();
    }
  }

Since expense.save() is now happening in the Controller, the server will respond with the updated version of the expense (with the correct amount) and update the template automatically.

The Angle-Bracket Way

In Ember, components (and solely components) are the way of the future! And the future is now, with the recent release of Ember v2.1.0, routable components and angle-bracket components are live on Canary behind a feature flag. Here is what that might look like for our budget form example.

  
  {{! expense-table/template.js}}

<table class="expenses">
  <tbody>
    {{#each expenses as |expense|}}
      <expense-summary expense=expense amountChanged={{action "update"}}>
    {{/each}}
  </tbody>
</table>

  
  // expense-summary/component.js

export default Ember.Component.extend({
  actions: {
    amountChanged() {
      this.attrs.amountChanged(this.get('expense'));
    }
  }
});

Final Remarks

I won't dive anymore into that in this blog post. A little birdy told me that closure actions will be the subject of a future Ember Best Practices Post. So look out for it! And remember to go back to Aaron's post on using native input elements if you haven't already.

I have put together an Ember Twiddle with the example we worked through today. It also demonstrates how by following the "data down, actions up" best practice, changes in the UI of one component can easily propagate and be reflected in other components. Check it out and feel free to play around!

Capturing the colors

2015-10-06 00:00:00

If youâre interested in learning about color for UX Design, weâre teaching a hands-on workshop on October 29th!

For me, autumn is the most fascinating time for colors. The obvious fall foliage attraction (all the streets and parks are suddenly so pretty!) and the fall fashion (summer was casual, fall calls for a slightly dressed-up, more academic, more pulled together style) combine to create an intense appetite for color. Naturally and seasonally, I am attracted to the rich earthy rust and gold in the leaves, but also the burgundy, darker navy and all kinds of leather colors that people wear to the offices downtown.

There's just one problem. The color effects of autumn are frustratingly difficult to capture.

Difficult to capture.

The fleeting nature of colors in the fall increases my fascination with them. Itâs not just that the leaves change every day, and shrivel up and dry within hours of bringing them home. Itâs the difficulty of reproducing how these colors feel. Peak foliage color attracts crowds every single year. Everyone dutifully takes photos. But those photos rarely compare to the vibrant feeling in real life.

How the colors feel in real life (left) does not always match up to the photographic results (right). But which one is more ârealâ?

You canât always capture whatâs in your head

The reason photos often donât live up to out vibrant expectations (think ~90% of all sunset photos ever) is partially that the camera is only able to capture a small part of what our eye can see (the human eye has a very high dynamic range), and partially our brain.

The way our brains âreadâ colors is not only based on the colorsâ measurable intensity, hue, and brightness, but also on the context. For fall foliage specifically, we might âreadâ a very saturated orange in the maple leaves when they are surrounded by less saturated brown leaves, grass or buildings, and against a complimentary blue sky.

So, I imagine that reality is somewhere in-between: my brain makes the fall colors feel very intense, while a camera might dull them in the process of trying to capture all the information.

A way to look at colors

Today at the library, I picked up this book on colors â Mix your own watercolors : an artistâs guide to successful color mixing by John Lidzey. I have painted with watercolors for a while, but this specific book attracted me because of its focus on mixing specific shades of colors and getting predictable results. In the introduction, John Lidzey makes an important point distinction: colors will always appear to be a certain way, but we actually need to measure and isolate them to accurately understand the hue and value of the color before we can reproduce it. Context can change a color, and we can only truly see it by isolating a swatch.

He suggests making a simple tool to help judge colors: a white paper card with a small square cut out of it. Because I am interested in color for many uses, not just on (white) watercolor paper, I modified this tool to have a neutral gray and a black context for the small cut-out as well.

DIY color evaluation tool!

Hereâs what I found

I used my new, very scientific (also, a bit like magic!) color analyzing tool. I found actual autumn leaf colors to be more complex and less vibrant than they first appear. I also confirmed that context can significantly alter the perception of a colorâââa concept I had learned in my freshman year of design school, but keep having to go back to look deeper.

Hereâs an exercise straight from the book:

The colors in the still life appear more vibrant than the paint swatches next to them.

However, by comparing the swatch of mixed paint to an isolated swatch of the still life, we see the match is very close. Context makes such a difference!

The golden-brown leaf suddenly feels dull when brought in to photograph on a lighter color. But the actual color swatch, when framed by gray, is quite saturated and warm. A good choice of context to bring out this kind of brown is any neutral, like I show here with felt.

Here, a yellow leaf looks quite a bit more intense either framed by gray, or on a backing of a less saturated color.

In a pile of leaves, this yellow looks saturated.

The yellow by itself, on a lighter background, still looks quite vibrant.

Compared with a very saturated yellow flower, we see that the leaf was not such a saturated color after all.

What to do

In summary â I highly recommend making this simple color context tool. It can help evaluate and compare colors in nature, and understand them better. Also, when expectations do not line up with reality, it could be that because the subject was removed from the environment in which it was first evaluated. When I design, I need to use color well. Todayâs exercise helped me get a better understanding of just how important context is. I might alter my process in the future, to start with establishing a âbackdropâ, or a context, for my color selections. Just like a painter, I might âunderpaintâ my Photoshop file before I start fine-tuning the accent colors for any given layout.

And I might just use the little gray square trick on my computer screen, when no one is looking.

Ember Best Practices: Using Native Select Elements

2015-10-05 00:00:00

This is the third in a series of posts designed to share our experiences around developing Ember.js apps and the best practices that we've found while doing so. Check out Lin's post on page objects and acceptance tests, or Estelle's post on not leaking state into factories.

Closure actions

Ember 1.13 came with the release of improved actions. A side effect of this feature is that it enables us to move away from {{view 'select'}} and simply use DOM <select> elements with actions.

trouble with forms/form elements in ember? Turn out in 1.13.3 you can just use "THE DOM" http://t.co/9U73q0KOOE
— Stefan Penner (@stefanpenner) July 7, 2015

His linked JSBin links to Ember canary and no longer works, but a clone modified to use 1.13 is available here.

You are probably familiar with the previous action bubbling semantics. Actions in a component are isolated within that component. Actions outside a component bubble first through the current controller, then through the route hierarchy.

The new approach of closure actions is simply to wrap this action up in a function and pass it around. Anyone can call this function later. And since the context is wrapped up in the function closure, the caller does not need to know where it came from.

For us, the important thing is that it enables us to bind actions directly to elements, like this: <select onchange={{action "doThing"}}>.

What's wrong with `{{view 'select'}}`?

Ember is moving away from two of the core concepts used by {{view 'select'}}.

Views

The Ember team, as well as many people in the community building Ember apps have discovered that the confusion around view scopes has been a huge source of hassle and bugs. The explicit scoping of components is much more maintainable. Thus, the Views section has been removed from the Ember guides, and the {{view}} helper has been deprecated. Nowadays, you get one view to go with your route, and otherwise View serves simply as a superclass to Component. As we move towards routable components, even the routes' views will begin to disappear.

Two-way data binding

Ember and the Ember ecosystem are also moving away from two-way bindings, and towards a Data Down, Actions Up architecture (DDAU).

Triggering an action includes context that is missing with simple data binding. Why is this value changing? Did we receive an update from the back-end, or did the user hit save? Lacking this context can lead to complicated conditional logic. Or, when combined with observers can cause an infinite loop hitting your back end.

It's also hard to go back once you opt-in to two-way bindings. You've hooked up a form field with data binding, and now you realize you need validation on that field. Oh, you also need a confirmation when it is valid (this is some high-stakes data). You'll find yourself using an observer, or splitting your value property into previousValue and currentValue properties. It is easier to hook in for these kinds of things when triggering actions instead.

There's also an issue of trust and boundaries. It turns out, "components want to be able to hand out data to their children without having to be on guard for wayward mutations." Data flowing only in one direction keeps things more predictable.

Okigetit, how do I do it?

Well, Stefan's JSBin I spoke about above is really a better example than I could give here. But, basically:

Use a DOM <select> tag, and use an {{#each}} to render option tags.
Bind an action to its onchange attribute.
Create an action handler to set the property value.

But what about `{{input}}`?

Although {{input}} behaves more like a component than a view, there are similar issues around the data binding.

However, it turns out the same approach as above does not work quite as well with <input> tags. Because of how HTMLBars re-renders views, any time you type a character, your cursor will be reset to the end of the text field. This is awful! There's a way around it, using the side effects of readDOMAttr(). I won't go into it here, but Rob Jackson has put together a small example component using this technique.

May your forms be filled, your inputs valid, and your error template never render!

Note: This post has been edited. It originally recommended using <input> tags with actions. Because of the issues mentioned around cursor position, it has been changed to discuss select instead.

Announcing the Design Sprints Guide

2015-10-05 00:00:00

Weâre extremely excited to announce the release of our first version of the Design Sprints Guide. This releases focuses on a special 4-day variant of the ever popular rapid-validation product design methodology.

In this guidebook we provide everything you can (and cannot) expect of the methodology, the processes and tools you can use for running a design sprint yourself, and a boat-load of resources for further reading.

This content is free and weâd love for those already running sprints to contribute wisdom from their experiences. For now, anyone whoâd like to make edits, suggestions, or additions to this guide may send pull requests or open issues on the github repository. The README has some instructions for how weâll manage these.

Plans for future releases:

Adding the original 5-day process plan.
Adding more real life examples / photographed documentation.
Creating tools that allow readers to suggest and accept additions or edits on the guide.

We hope youâll find this guide useful. If not, we really hope youâll help us improve it.

Huge credit and thanks to the DockYard design team for putting the Design Sprints Guide together: Maria Matveeva (@rgbcolor), Ashley Treni (@ashleytreni), Cory Tanner (@ctannerweb), Amanda Chueng (@acacheung), Tim Walsh (@imakemusic), and Patrick Branigan (@pbranigan).

Ember Best Practices: DRYer and less fragile Acceptance Tests

2015-09-25 00:00:00

This is the second in a series of posts designed to share our experiences around developing Ember.js apps and the best practices that we've found while doing so. If you missed the first post from Estelle about not leaking state into factories you should check it out!

Intro

In this post, I'm going to be talking about writing less fragile acceptance tests that are easier to maintain. Renaming CSS classes or refactoring the HTML structure of an application can cause our acceptance tests to fail, even if the end-user experience is the same. When this happens, it's not uncommon to spend a disproportionate amount of time fixing broken tests rather than refactoring code. If that sounds familiar, I've got a few approaches that you can use to create less fragile acceptance tests. And more than that, when they do break, you can fix your test logic in one place rather than in every test that's failing.

Minimize coupling tests to presentation

The first approach weâre going to talk about is decoupling your acceptance tests from the HTML structure and CSS of your application. If your tests are breaking due to semantic HTML or class name changes but the end experience to the user is nearly exactly the same, this should be a red flag that your tests are too closely coupled to the HTML and CSS of your application. Our acceptance tests should be from the perspective of a user interacting with the application. A user doesnât care about whether the element they are clicking on is a <button> or a <span> or whether we use a class name of post or blog-post. They care that they can read a blog post, comment on it, and like it.

However, we canât perfectly decouple our tests from presentation, as we still need to be able to find the elements that we need to interact with and make assertions against. One approach to minimizing the coupling is to add a data attribute to elements that we want to target during our tests. Data attributes are attributes that are prefixed with data- and are intended to store meta data on elements:

  
  <div data-foo="some arbitrary data" data-bar="123"></div>

Example test using data attributes

We can use these data attributes to identify elements that will be interacted with in our tests:

  
  <div class="post-likes">
  <span class="likes-count" data-test-selector="post-likes-count">{{likesCount}}</span>
  <button class="btn like" {{action "likePost"}} data-test-selector="post-like-button">Like</button>
</div>

  
  test('a user can like a post', function(assert) {
  assert.expect(2);

  visit('posts/1');

  andThen(function() {
    const likesCount = find('[data-test-selector="post-likes-count"]');
    assert.equal(likesCount.text(), 0, 'precondition - likes count starts at 0');
  });

  click('[data-test-selector="post-like-button"]');

  andThen(function() {
    const likesCount = find('[data-test-selector="post-likes-count"]');
    assert.equal(likesCount.text(), 1, 'clicking the like post button increments the likes count');
  });
});

Now, if we want to refactor our like button so it contains the likes count and change around some class names...

  
  <button class="btn like-post" {{action "likePost"}} data-test-selector="post-like-button">
  <span class="count" data-test-selector="post-likes-count">{{likesCount}}</span> Likes
</button>

Our test still passes without having to update our test logic because we're not targeting elements based on their class names or their relation to other elements on the page. Success!

Page Object Pattern

The next approach we're going to talk about is using the Page Object pattern to DRY out our test logic. The goal of a Page Object is to represent an area of your UI that gets interacted with during tests. Page Objects are responsible for abstracting away the details of how to target and interact with elements in the DOM and providing an API that can be used in tests for page interactions. The name Page Object can be a bit misleading. Most "pages" have a bit too much going on for them to be encapsulated into one object. Generally, Iâve found that it makes more sense to model Page Objects after logical chunks of the UI. You might have a Page Object representing your nav-bar, side-bar, or a group of components that compose a logical section of the UI. For example, you might have a Page Object that is responsible for providing an API for targeting elements of an individual post:

  
  // tests/page-objects/post-show.js

// PageObject implementation using es6 Classes
import BasePageObject from './base'; // A base class for all page objects to extend from

export default class PostShowPageObject extends BasePageObject {
  constructor(assert) {
    this.assert = assert;
  }

  // interactions
  readPostId(id) {
    visit(`posts/${id}`);

    return this;
  }

  clickLikeButton() {
    click('[data-test-selector="post-like-button"]');

    return this;
  }

  // assertions
  assertLikesCount(count, message) {
    andThen(() => {
      const likesCount = find('[data-test-selector="post-likes-count"]');
      message = message || `likes count is: ${count}`;
      this.assert.equal(likesCount.text(), count, message);
    });

    return this;
  }
}

Here's what the exact same acceptance test would look like using our new Page Object:

  
  import PostShowPageObject from '../page-objects/post-show';

// other test code

test('a user can like a post', function(assert) {
  assert.expect(2);

  new PostShowPageObject(assert)
    .readPostId(1)
    .assertLikesCount(0, 'precondition - likes count starts at 0')
    .clickLikeButton()
    .assertLikesCount(1, 'clicking the like post button increments the likes count');
});

The real benefit here is that if you need to change how you target elements, you only have to fix it in one place rather than every test that interacts with that element. Besides the maintainability of the test logic, it makes for super clean and readable tests! One thing to note is that there is some disagreement about whether assertions should be a part of the API of a Page Object. Some people feel that a Page Object should strictly provide an API for page interactions. Others feel that we tend to assert around a certain set of elements in our tests and DRYing up assertion logic by including assertions in the Page Object makes sense. In my experience, I've found that including assertion helpers in my Page Objects has saved me a ton of time when adding new tests and maintaining old tests.

Additional Resources

Mike North gave a great talk at Wicked Good Ember last year about using Page Objects and data attributes for acceptance testing. I definitely recommend checking it out.

ember-page-object

If you're sold on the idea of using Page Objects and data attributes to target elements in acceptance tests, Lauren and I created an addon called ember-page-object that provides a base PageObject class you can extend from to help get you started! Enjoy!

What to expect from a Design Sprint

2015-09-22 00:00:00

A design sprint is a research strategy which focuses on and explores a feature or specific part of a product. With a limited scope and a short duration of a week, a sprint can test and validate ideas about user flow, functionality, and interaction design around a specific product goal. To elaborate on Maria's post about Design Sprints, here's a "what to expect" about participation, outcomes, and deliverables.

Participation

A stakeholder from the product in development is a very important participant in the design sprint, and they should expect to be hands on and present for the full sprint duration. Design sprints move very fast, and their industry knowledge and understanding of the product is key to a successful outcome. The team can move forward quickly and efficiently with the availability to ask questions and help make informed assumptions along the way. Stakeholders come with unique insights about the product that can illuminate conditions of the target market, knowledge about users, business goals, and any known limitations or pre-existing conditions up front.

Planning the sprint objectives and project goals before the start of the sprint is important to stay focused on the task at hand. New ideas will arise during a sprint - the design team leader will make sure to document for later, or redirect the sprint to address those considerations if they are integral to the solution.

Outcomes

Part of establishing project goals is determining the outcomes and deliverables that result as a product of the sprint. The outcomes of a design sprint depend on the state of your product before the design sprint, and based on the project goals that were defined. The outcome of a sprint can go many different ways:

A working prototype. Usually for a one-week design sprint, the result is a clickable prototype and one or two user stories. The thinking that went into defining the user flow and key interactions can be tested and validated through the prototype and user testing.
Detailed wireframes and a full user flow. Often times, a series of sprints are held to explore a more complex product. With each week focusing on a different facet of the product, wireframes and prototypes from each sprint can start to carry over to inform design decisions in consecutive weeks. With consecutive sprints, it is possible to explore the product more deeply and examine the connections and interdependencies between the proposed user flows.
Preliminary visual design. If the content of a given sprint is narrow in scope, there may be time at the end of the sprint to begin visual design. Developing a visual style for the product can inform prototypes in consecutive sprints, or lay a framework for visual tone in the product itself.
Product direction. For newer products, sprints can explore the wide landscape of possibilities to discover and prioritize the best ways to move forward. A sprint can help select and test directions early on to determine the strongest product values to put into action.

Deliverables

The deliverables for the following outcomes may come in various forms such as original files (Sketch, photoshop, illustrator documents), JPGs/PDFs/PNGs, links to online prototypes, and photographs.

The outcomes of a design sprint are more strategic in nature and not a fully completed project. What youâll take away from a sprint are research tools, the skeleton of an interface with core features and interactions and, most importantly, a better understanding of the next steps for your product. Setting these expectations for participation, outcomes, and deliverables up front is imperative to a successful design sprint.

We're excited to share more of our process with you through our soon to be released (and free) design sprints resource guide! Signup to the DockYard newsletter below and we'll let you know when it has been released.

Ember Best Practices: Avoid leaking state into factories

2015-09-18 00:00:00

At DockYard, we spend a lot of time with Ember, from building web apps, creating and maintaining addons, to contributing back to the Ember ecosystem. We hope to share some of the experience we've gathered along the way through a series of blog posts that will focus on idiomatic Ember practices, patterns, anti-patterns, and common pitfalls. This is the first in that series, so let's start by going back to the basics with Ember.Object.

Ember.Object is one of the first things we learn as Ember developers, and to no surprise. Pretty much every object we work with in Ember, whether it's a route, component, model, or service, extends from Ember.Object. But every now and then, I see it used incorrectly, like this:

  
  export default Ember.Component.extend({
  items: [],

  actions: {
    addItem(item) {
      this.get('items').pushObject(item);
    }
  }
});

To those who have encountered this before, the problem is obvious. But I'm sure this has trolled many developers at one time or another, so if the issue doesn't immediately jump at you, keep reading!

Ember.Object

If you were to browse the API and deselect all Inherited, Protected, and Private options, you'll see that Ember.Object has no methods or properties of its own. The source code couldn't be any shorter. It's literally just an extension of Ember's CoreObject, with the Observable mixin applied:

  
  var EmberObject = CoreObject.extend(Observable);

CoreObject provides a clean interface for defining factories or classes. It is essentially an abstraction around how you would normally create constructor functions, define methods and properties on the prototype, and then create new objects by calling new SomeConstructor(). If you're able to invoke methods of a superclass using this._super(), or merge a set of properties into a class via Mixins, you have CoreObject to thank for. All the methods that come up often when working with Ember objects, such as init, create, extend, or reopen, are all defined there too.

Observable is the mixin that makes it possible to observe changes to properties on an object, and is where both get and set methods come from.

When developing an Ember app, you would never use CoreObject directly. You would extend from Ember.Object instead. After all, Ember is all about reacting to changes, so you need the methods from Observable in order to detect when a property value changes.

Defining a new class

You can define a new type of observable object by extending from Ember.Object:

  
  const Post = Ember.Object.extend({
  title: 'Untitled',
  author: 'Anonymous',

  header: computed('title', 'author', function() {
    const title = this.get('title');
    const author = this.get('author');
    return `"${title}" by ${author}`;
  })
});

New objects of type Post can now be created by calling Post.create(). Each post instance will inherit the properties and methods that have been defined on the Post class:

  
  const post = Post.create();
post.get('title'); // => 'Untitled'
post.get('author'); // => 'Anonymous'
post.get('header'); // => 'Untitled by Anonymous'
post instanceof Post; // => true

You can change the property values and give the post a meaningful title and author name. These values will be set on the instance, not the class, and therefore will not affect future posts that get created.

  
  post.set('title', 'Heads? Or Tails?');
post.set('author', 'R & R Lutece');
post.get('header'); // => '"Heads? Or Tails?" by R & R Lutece'

const anotherPost = Post.create();
anotherPost.get('title'); // => 'Untitled'
anotherPost.get('author'); // => 'Anonymous'
anotherPost.get('header'); // => 'Untitled by Anonymous'

Because updating properties this way has no impact on other instances, it is easy to think that all operations done on an instance are safe. But let's expand on this example a bit more.

Leaking state into the class

A post can have an optional list of tags, so we can create a property named tags and default it to an empty array. New tags can be added by calling an addTag() method.

  
  const Post = Ember.Object.extend({
  tags: [],

  addTag(tag) {
    this.get('tags').pushObject(tag);
  }
});

const post = Post.create();
post.get('tags'); // => []
post.addTag('constants');
post.addTag('variables');
post.get('tags'); // => ['constants', 'variables']

Looks like it's working! But check out what happens when a second post is now created:

  
  const anotherPost = Post.create();
anotherPost.get('tags'); // => ['constants', 'variables']

Even though the goal was to create a new post with empty tags (the intended default), the post was created with the tags from the previous post. Because we never set the post's tags property to a new value but simply mutated the underlying array, we have effectively leaked state into the Post class, which is then shared by all instances.

  
  post.get('tags'); // => ['constants', 'variables']
anotherPost.get('tags'); // => ['constants', 'variables']
anotherPost.addTag('infinity'); // => ['constants', 'variables', 'infinity']
post.get('tags'); // => ['constants', 'variables', 'infinity']

It is not the only scenario where you may confuse instance state and class state, but it is certainly one that comes up more often. In a related example, you may wish to default an object's property named createdDate to the current date and time by setting it to new Date(). But new Date() will only get evaluated once, when the class is defined. So no matter when you create new instances of that class, they will all share the same createdDate:

  
  const Post = Ember.Object.extend({
  createdDate: new Date()
});

const postA = Post.create();
postA.get('createdDate'); // => Fri Sep 18 2015 13:47:02 GMT-0400 (EDT)

// Sometime in the future...
const postB = Post.create();
postB.get('createdDate'); // => Fri Sep 18 2015 13:47:02 GMT-0400 (EDT)

Keeping things under control

In order to avoid sharing tags between posts, the tags property would need to be set when the object is initialized:

  
  const Post = Ember.Object.extend({
  init() {
    this._super(...arguments);
    this.tags = [];
  }
});

Since init is called whenever you call Post.create(), each post instance will always get its own tags array. Alternatively, you could make tags a computed property. It won't observe anything, but will be unique to each instance:

  
  const Post = Ember.Object.extend({
  tags: computed({
    return [];
  })
});

Conclusion

It should be obvious now why you should not write components like the example I showed at the beginning of this post. Even if the component only appears once on a page, when you leave the route, only the component instance gets destroyed, not the factory. So when you come back, a new instance of the Component will get created, and this new component will have traces of the previous time you visited the page.

This error may be encountered when using mixins as well. Even though Ember.Mixin is not an Ember.Object, properties and methods defined on the mixin get merged with the Ember.Object you mix it into. The result would be the same: you may end up sharing state between all objects that use the mixin.

If you found this post helpful, stay tuned for more blog posts from myself and fellow DockYarders on Ember best practices in the future!

Design is about systems

2015-09-10 00:00:00

As I commute, every time I have to pick between risk and delay.

There is an intersection that takes a pedestrian three separate lights to cross. For cars, itâs just one. If you obey all traffic signals youâll cross this intersection in two traffic-light cycles heading downtown. In the opposite direction, it can take three full cycles.

Clearly, this leads to frustration for pedestrians. With cars potentially coming from three different directions (look at Crossing 2), itâs easy to look to just one side, assume there is no traffic, and jaywalk. It often happens just as the cars start moving. In addition to being dangerous for people, this slows down the cars and buses even more, adding to residual delays as they eventually clear the intersection on red.

This intersection design is stupid

As a pedestrian, I have a choice between jaywalking (running) as I glance left, right, and back to see if any cars are coming - or waiting several minutes extra to cross. It seems such an injustice that I have to request a pedestrian light up to three times while cars clear this monstrous intersection in just one. As a user of this intersection, I feel like I am an afterthought, not a primary consideration.

What if we mandate that all intersections be crossable in one light? What if we prioritize pedestrians, not cars?

I start to imagine potential legislation, participating in a "healthy city" campaign of some sort, and even a crosswalk design that would accommodate a faster, safer crossing for me.

This intersection is part of a system

Then I think about it more. Why was this intersection designed to accommodate cars better than pedestrians? Why do most cities in the US still feel like theyâre planned for cars and not people? Because they are. Long story. I start to imagine all the infrastructure changes that might be required for this seemingly simple change: to alter the path of a crosswalk, and make it feel more efficient.

I think this way because as a designer, I am responsible for making sure that the things I build and âmake prettyâ actually work - and for more than one type of user. I donât put a button or a variable into a mockup unless I know it can be supported by engineering, and is necessary for the user. Because of this sense of responsibility, I canât really enjoy lofty, speculative discussions about potential changes it might be nice to make.

Design thinking is both a blessing and a curse

As a designer, I canât help but think about how the environment around me works, and why. Iâm a walking critique machine, a small nudge will get it started. I can see, or at least imagine, the systems that stand behind every designed detail of my life.

But even when I can often see clear ways to fix situations that annoy me, I can just as clearly see why change wonât usually be easy or fast. A change in my path across a traffic intersection is not just about the intersection. It involves the systems that control traffic flow on the three streets. One of these streets goes underground to flow into a highway, and another exits to Bostonâs busy Financial District.

A design approach is powerful precisely because we take into account the systems, requirements, and groups of users who will interact with the thing we design. We aim to help people accomplish their goals while minimizing potential frustrations. This is a lot of responsibility, but itâs exactly what makes our work powerful.

And while we can never know about all the components of the systems we design for from the start, we must ask questions and rely on othersâ expertise to draw conclusions. The ultimate responsibility in design is to think holistically.

Define: Functional Decoration

2015-09-04 00:00:00

If youâre unfamiliar with the implications of decoration in design, a good place to start is to read Beatrice Wardeâs âThe Crystal Goblet, or Printing Should Be Invisibleâ. It sums up fairly well a belief I carry to the products we produce at DockYard.

Designers working in graphic, industrial, architectural, and user experience design have experienced many revolutions of overly decorative design followed by a great decorative purge. A most recent example of this is the explosion of âflat designâ and aggression turned toward all things skeuomorphic. This was inevitable, and I welcome the sea change.

However, I think if weâre able to open our hearts for a minute to unpopular ideas, weâll find that decoration does indeed have a functional role in design. I think that role could be called Functional Decoration. Let me explain what I think Functional Decoration is by explaining what I think it can do.

Functional Decoration is decoration that assists in creating a new context through which expectations shift, or distort our sense of "normal", to allow us to amplify the messages within the content it surrounds. It can let usÂ exemplify the experience of a thing better than purely representing it in the written word. It can be effective in emphasizing the tone of a process, providing a sense of the experience of an event, or perhaps even an expectation of the performance of a product.

Can you tell me if you felt real emotions when seeing Inside Out, Up, Spirited Away, or Princess Mononoke? What if we stripped the âdecorativeâ medium from these films? The answer is we would have a very different experience with the content. I think proponents for moderate use of decoration are experiencing something similar to attempting to get someone who refuses to watch anime to watch a single animated film. It's an uphill battle, but I digress.

I believe useful decoration - Functional Decoration - extends the readers' imagination to help their mind do the dirty work of turning text into imagined experiences or expectations. Done well, it can be much better than the content on its own.

Here are a few examples of what I'd call Functional Decoration:

XOXOs changing background pattern and use of overlay yellow on blue. The absence of photography, the unabashed use of a basic but vibrant blue and yellow, and the dynamic overlaying shapes describe an inclusive nature of their event well: âyou're with friends, it's ok to be you hereâ
Super-Loopers "pixelated" visuals pay homage to the environment that inspired the software but also act as a visual description of the sound you're hearing.
Bloombergâs "What is Code?" by Paul Ford uses graphics and pattern as Functional Decoration in that they themselves are illustrations of the content. They facilitate a sometimes humorous and other times very awe-struck wonder of the origins of computing and its concentric cultures.

At the end of the day, my goal with the concept of Functional Decoration is to do necessary repair from damages caused by scorched earth dismantling of decoration (such as skueomorphism) and to help myself and my team to make better use of the communicative tool decoration can be.

And I really just wish there was a better word than "decoration".

Clear communication through HTML and GitHub

2015-09-02 00:00:00

If you follow the DockYard blog I am sure you are familiar with how we structure our teams.

Design

You can get a feel for how our designers operate by taking a look at Steve's post, Job: Senior UI & Visual Designer.

UX Dev (User Experience Development)

Brian has a great post describing the UX Dev team, The most difficult position to hire for in tech right now.

Development

Mainly with Ember.js the Development team wires up all of the functionality required with the HTML and CSS provided by UX Dev.

Our current process

What helps us the most when we have multiple teams on a project is clear communication.

DockYard has methods of communication between all three teams but this blog post will be focusing on methods the UX Dev team uses to communicate with the Development team.

Our UX Dev team is always looking to make work easier for the Development team and a simple way to do that is through how we communicate an application's conditionals. When we receive designs of the application we need to communicate to Development what the conditionals are in a clear and organized way.

We have done this through our HTML templating comments and this alone has worked well.

In a previous post we went over how to add comments to your code in Helping Our Engineers, and we go over two methods of communication.

Note: we use Handlebars for our templating.

Pseudo-code comments

  
  <a class="t-link" href="">about</a>
<a class="t-link" href="">contact</a>
{{! if signed in}}
  <a class="t-link" href="">manage</a>
{{! else}}
  <a class="t-link" href="">sign in</a>
{{! end if}}

This lets our developers know that if the user signs into the application, the manage link is added to the HTML, else the sign in link should be present.

This method works great for adding notifications to the page, you just need to say the following.

  
  <input class="button">Log In</input>
{{! if <input> has errors on submit}}
  <div class=ânotificationâ>
    ...
  </div>
{{! end if}}

TODO comment

  
  {{! TODO: Toggle class .is-selected on <a> when active}}
<a class="t-link" href="">about</a>
<a class="t-link" href="">contact</a>

If we donât need to add complete blocks of code to the HTML we will use a TODO comment to let the developers know a class needs to be added to the next line of code.

Whatâs new: Track Everything

In addition to adding comments it is recommended to provide a trackable issue referencing the comment in your code. On GitHub this is very easy and we can assign the issue to a team member.

We donât do this for every individual comment but rather make a checklist in the GitHub issue per modular component or one issue for simple pages.

An example of a simple page would be a static "About Us" page that only has about 1 - 2 comments and no complex conditionals.

Issue example

Having trackable issues for comments is helpful because there can be so many of them. Keeping everything organized in a project management system like GitHub is very helpful.

Final Thoughts

Our goal as UX Developers is to provide crystal clear communication with the Design and Development teams so the client gets the best product possible.

Having standardized techniques for communicating the application HTML conditionals within your team can greatly help the workflow and make everyone's life easier.

I hope this helps your templating process with HTML and provides clear communication with your team!

CSS Tooltips: What clip-path & gradients can do for us

2015-08-27 00:00:00

What I wanted

This came about when I was trying to create an error tooltip with borders and a transparent background following this design:

It has a subtle wave texture to it so it was important that the tooltip held transparency. I also wanted to set up a constraint for myself to not add extra HTML elements.

The old solutions and why they didnât work

Previously, when I wanted to implement a tooltip, I could make it transparent without a border OR have a border and the background would have to be opaque. The only way I knew to do borders was stacking the before and after pseudo elements to simulate a border like so. This method prevented transparent backgrounds because one pseudo element had to be on top of the other pseudo element which had a background color of the border.

New ideas

After coming across Gregor Adamsâ Pure CSS Tooltips blog post, I piggybacked off the idea of using linear gradients to create the triangle of the tooltip.

Finding a solution

It was a bit strange trying to figure out how to get a triangle with borders only on two sides without extra surrounding artifacts (watch what happens when we leave out background-repeat: no-repeat in the CodePen at the bottomâ¦ weird!). Then came finding a solution for the border around the tooltip. The border had to skip the portion where the triangle tip sat.

It wouldâve been cool if we could control dashed lines to be able to change the lengths of the dashes or the space in between each dash. Unfortunately we donât have that level of customization for border-styleâs. Or if we could use some sort of border gradient with color stops, but after trying that, I figured out that it didnât play well with border-radius. Then I thought to use some type of clipping and I would even be able to angle my clip-path to fit better with my triangle tip! The path I figured worked best is outlined in black:

If you are unfamiliar with clip-path, Bennett Feelyâs tool clippy helps visualize clip-path polygons and provides a good starting point with its dragging feature.

See the Pen Transparent tooltip with border by Amanda Cheung (@acacheung) on CodePen.

Itâs not the DRYest, but it is flexible for tooltips that are multi-line as well as tooltips that are longer in length. This also works with box-shadows, but clip-path would need to be adjusted and it can also handle transparency for the borders. Unfortunately at this time, Firefox and IE are not supported because of how clip-path is being used.

Design sprints: what are they for?

2015-08-17 00:00:00

Design sprints at DockYard are based on the Google Ventures model, but with a shorter four-day duration. Design Discovery (the research and strategy phase that enables us test and plan out the entire application before proceeding with Visual Design and Engineering) lasts several weeks, and has a greater scope.

While each process has its individual benefits, there are many that they share. In both cases, of Design Sprints and Discovery, we share work with the client early and often. This quick turnaround requires close attention and abstract thinking from the client (for example, evaluating an idea in sketch form rather than fully resolved designs). The benefit is that we course-correct quickly and eliminate alternatives early on.

The difference is in the scope, end objective, and the deliverables. A design sprint can encompass a specific aspect of a product. It's a highly collaborative and budget friendly way to spike on an idea. Design discovery is a holistic approach to goals and strategy for a product.

What sprints are good for

The purpose of a sprint is not to deliver a whole product, but a realistic model of a product experience. In a few cases a product experience may be small and focused enough to be encompassed entirely in the sprint. More likely, a design sprint focuses on a specific aspect of an application, and a single user story.

A sprint might address a question like âhow would a new user sign up for your service on a mobile phone?â or âIn what ways could an existing customer use the web service youâre building in the course of their day?â A sprint is a rapid way to model and test specific situations, so that the product can be refined. In order to run a sprint, we make reasonable assumptions about a situation around your product, and then isolate, model, and test a them.

What a sprint looks like

Hereâs what a design sprint might look like at DockYard. Letâs imagine a product that helps customers know when a farm share they purchased would be delivered.

For the sprint, we would be focusing on sending and receiving messages between a delivery driver and a customer.
We would only focus on the mobile view of this interaction (with an informed assumption that itâs the most convenient context for checking up on a delivery)

Monday: analyze the context

We kick off the sprint by analyzing the situation around the delivery. Who are our users? What problems do they encounter, and which ones can we help them solve?

By the end of the day, we expect to diagram the portion of a customerâs experience receiving a delivery, and any actions they might take along the way.

Tuesday: sketch and define

On day two we take the workflow we already defined and turn it into a series of hand-sketched wireframes. In this process, additional details become clear and we move toward a standardized approach to similar screens. We define a series of messages between the customer and the delivery driver as the key interaction.

Wednesday: design and prototype

On day three, we translate the sketches into visual design. We design the key screens for the messaging interaction and create a minimal prototype to test drive how the messaging app might feel.

Thursday: test and refine

On the final day, we run several quick user tests with potential customers. We give test users a scenario like âyour delivery is coming - use the app to check on its arrival!â and observe how they interact with the prototype. We record any lessons learned - e.g. âuser assumed the button was inactiveâ.

We then make any quick corrections based on the results of user testing (like making the button appear more active) and document what we learned as potential improvements or things to explore in the future.

The result of a sprint in this case is a working prototype of messaging for our specific use case, and an understanding of what role this key interaction plays within the larger context of the app.

Picking between Sprint and Discovery

To decide which design process is right, consider the job each process does well.

A sprint quickly illuminates a specific aspect of your product, for example, a single user story. A series of sprints could produce a full picture, but at some point a Discovery approach becomes more effective.

Sprints result in prototypes of your product or parts of it, and allow you to test things quickly. They are most efficient for solving shorter term business goals: validating or iterating quickly on a function of an application.

Original image source

Discovery usually requires more time and resources, but shows the larger picture.

The combination of design discovery and visual design is a holistic process. It is a better investment in cases where youâre developing a new product, or have long term business goals and would like an investigation from all angles into how to achieve them.

If you have a specific question in mind, contact us. Weâll set up a short consultation meeting so we can help find out which process is right for you.

Applying the Adapter Pattern for Analytics

2015-08-10 00:00:00

At DockYard, most (if not all) Ember apps we build for our clients require analytics in some form or other. For many of these apps, simply including the Google Analytics tracking script is sufficient. However, we're noticing an increased interest in other analytics services such as Mixpanel or Kissmetrics for the more data minded clients.

Including multiple services (typically we see about 3â5 different analytics in use) with different APIs leads to a lot of code duplication, which is less than ideal, and is generally a maintenance nightmare. I don't know about you, but deleting repetitive code is one of my favorite things to doâââso Michael and I set out to build an Ember addon that would apply the adapter pattern to analytics.

In this post, we'll explore what the adapter pattern gives us, and demonstrate how to implement it in an easily extensible Ember addon so we can use one API to orchestrate multiple analytics services.

Introducing the ember-metrics addon

To install the addon:

  
  $ ember install ember-metrics

You can also find the source on GitHub.

The ember-metrics addon adds a simple metrics service and customized LinkComponent to your app that makes it simple to send data to multiple analytics services without having to implement a new API each time.

Using this addon, you can easily use bundled adapters for various analytics services, and one API to track events, page views, and more. When you decide to add another analytics service to your stack, all you need to do is add it to your configuration, and that's it.

With this addon, we wanted to make it super simple to write your own adapters for other analytics services too, so we set out to make it extensible and easily tested.

What is the Adapter Pattern?

In a broad sense, the adapter pattern is about adapting between class and objects. Like its real world counterpart, the adapter is used as an interface, or bridge, between two objects.

In the case of analytics, this is an excellent pattern for us to implement, because these services all have different APIs, but very similar intent. For example, to send an event to Google Analytics, you would use the analytics.js library like so:

  
  /** 
 * Where:
 * button is the category
 * click is the action
 * nav buttons is the label
 * 4 is the value
*/
ga('send', 'event', 'button', 'click', 'nav buttons', 4);

While in Mixpanel, you would track the same event like this:

  
  mixpanel.track('Clicked Nav Button', { value: 4 });

And with Kissmetrics:

  
  _kmq.push(['record', 'Clicked Nav Button', { value: 4 }]);

As you can probably tell, this gets repetitive really quickly, and becomes hard to maintain when your boss or client wants to update something as simple as the event name across these services.

Applying the Adapter Pattern

We generally have a few players in the adapter pattern: the client, the adapter (or wrapper), and the adaptee.

For ember-metrics, the client is our Ember.Service, the adapter is the adapter created for each analytics service, and the adaptee is the analytics library's API.

Each analytics service has its own adapter that implements a standard contract to impedance match the analytics library's API to the Ember.Service that is responsible for conducting all of the analytics in unison.

Using ember-metrics

The addon is first setup by configuring it in config/environment, then injected into any Object registered in the container that you wish to track.

  
  module.exports = function(environment) {
  var ENV = {
    metricsAdapters: [
      { name: 'GoogleAnalytics', config: { id: 'UA-XXXX-Y' } },
      { name: 'Mixpanel', config: { token: 'xxx' } }
    ]
  }
}

Then, you can call a trackPage event across all your analytics services like so, using the metrics service:

  
  import Ember from 'ember';

export default Ember.Route.extend({
  metrics: Ember.inject.service(),

  activate() {
    this._trackPage();
  },

  _trackPage() {
    Ember.run.scheduleOnce('afterRender', this, () => {
      const page = document.location.href;
      const title = this.routeName;

      get(this, 'metrics').trackPage({ page, title });
    });
  }
});

If you wish to only call a single service, just specify its name as the first argument:

  
  // only invokes the `trackPage` method on the `GoogleAnalyticsAdapter`
metrics.trackPage('GoogleAnalytics', { title: 'My Awesome App' });

This is clearly a much cleaner implementation, as we can now use one API to invoke across all services we want to use in our app.

Implementing the Adapter Pattern in ember-metrics

The service metrics is the heart of the addon, and is responsible for orchestrating event tracking across all analytics that have been activated.

Setting up addon configuration

A simple pattern for passing configuration from the consuming app's config/environment to the addon is through an initializer:

  
  import config from '../config/environment';

export function initialize(_container, application) {
  const { metricsAdapters = {} } = config;

  application.register('config:metrics', metricsAdapters, { instantiate: false });
  application.inject('service:metrics', 'metricsAdapters', 'config:metrics');
}

export default {
  name: 'metrics',
  initialize
};

This lets us access the configuration POJO from within the metrics service by retrieving the metricsAdapter property when the service is created.

  
  import Ember from 'ember';

export default Ember.Service.extend({
  _adapters: {},

  init() {
    const adapters = Ember.getWithDefault(this, 'metricsAdapters', Ember.A([]));
    this._super(...arguments);
    this.activateAdapters(adapters);
  },

  activateAdapters(adapterOptions = []) {
    const cachedAdapters = Ember.get(this, '_adapters');
    const activatedAdapters = {};

    adapterOptions.forEach((adapterOption) => {
      const { name } = adapterOption;
      let adapter;

      if (cachedAdapters[name]) {
        warn(`[ember-metrics] Metrics adapter ${name} has already been activated.`);
        adapter = cachedAdapters[name];
      } else {
        adapter = this._activateAdapter(adapterOption);
      }

      Ember.set(activatedAdapters, name, adapter);
    });

    return Ember.set(this, '_adapters', activatedAdapters);
  }
});

With the retrieved configuration, we then call the service's activateAdapters method in order to retrieve the adapter(s) from the addon or locally, then caching them in the service so they can be looked up later easily.

Activating an adapter simply calls create on the looked up adapter (which inherits from Ember.Object) and passes along any analytics specific configuration such as API keys.

  
  _activateAdapter(adapterOption = {}) {
  const metrics = this;
  const { name, config } = adapterOption;

  const Adapter = this._lookupAdapter(name);
  assert(`[ember-metrics] Could not find metrics adapter ${name}.`, Adapter);

  return Adapter.create({ metrics, config });
}

Because we've also implemented caching, we can safely call activateAdapters without having to re-instantiate already activated adapters, which allows us to defer the initialization of these analytics if (for example) we need to dynamically retrieve a property from one of our models:

  
  import Ember from 'ember';

export default Ember.Route.extend({
  metrics: Ember.inject.service(),
  afterModel(model) {
    const metrics = Ember.get(this, 'metrics');
    const id = Ember.get(model, 'googleAnalyticsKey');

    metrics.activateAdapters([
      { name: 'GoogleAnalytics', config: { id } }
    ]);
  }
});

Leveraging the container and resolver

Then, leveraging the Ember container and conventions around the ember-resolver, we can lookup adapters from the addon first, and then fallback to locally created adapters.

  
  _lookupAdapter(adapterName = '') {
  const container = get(this, 'container');

  if (isNone(container)) {
    return;
  }

  const dasherizedAdapterName = dasherize(adapterName);
  const availableAdapter = container.lookupFactory(`ember-metrics@metrics-adapter:${dasherizedAdapterName}`);
  const localAdapter = container.lookupFactory(`metrics-adapter:${dasherizedAdapterName}`);
  const adapter = availableAdapter ? availableAdapter : localAdapter;

  return adapter;
}

Invoking adapter methods from the service

Now that our service can access both local and addon adapters, we can invoke methods across activated adapters like so:

  
  identify(...args) {
  this.invoke('identify', ...args);
},

alias(...args) {
  this.invoke('alias', ...args);
},

trackEvent(...args) {
  this.invoke('trackEvent', ...args);
},

trackPage(...args) {
  this.invoke('trackPage', ...args);
},

invoke(methodName, ...args) {
  const adaptersObj = get(this, '_adapters');
  const adapterNames = Object.keys(adaptersObj);

  const adapters = adapterNames.map((adapterName) => {
    return get(adaptersObj, adapterName);
  });

  if (args.length > 1) {
    let [ adapterName, options ] = args;
    const adapter = get(adaptersObj, adapterName);

    adapter[methodName](options);
  } else {
    adapters.forEach((adapter) => {
      adapter[methodName](...args);
    });
  }
}

Creating Adapters for the Addon

With the service implemented, we can now create a base adapter class that all adapters extend from. This is mainly so we can assert that the adapter's init and willDestroy hooks are implemented, and to give it a nicer output in the console through overriding the toString function.

If you're not already familiar with the Ember Object model, the init method is called whenever an Ember.Object is instantiated through Ember.Object.create().

We can thus rely on this knowledge that init will always be called on object instantiation to pass in configuration to the analytics, and to call its setup. Typically, an analytics service will create a script tag through JavaScript, and asynchronously load its library from some CDN.

For example, here's the Google Analytics adapter that's bundled with the addon.

Enhancing the developer experience with blueprints

One of my favorite parts of ember-cli are its generators. Using blueprints, we can easily extend the cli commands to generate new metrics adapters using:

  
  $ ember generate metrics-adapter foo-bar

This creates app/metrics-adapters/foo-bar.js and a unit test at tests/unit/metrics-adapters/foo-bar-test.js. You can take a closer look at these blueprints here.

With these conventions in place, it's now trivial for consuming app developers to add new adapters to work alongside bundled adapters. And when they feel that an adapter they've built is ready to be shared with the community, they only need open a pull request to have that adapter included in the addon.

At some point in the future, it would make sense for each adapter to have its own repo and npm module, but to keep things simple, we've placed them within the addon.

Now we can easily send data to multiple analytics integrations through one API, DRYing up our code and making it more maintainable.

This post also appears on Medium in longform.

Polymorphic URLs in Ember

2015-08-08 00:00:00

Ember makes it easy to consume polymorphic records, assuming you have the following data retrieved from your server:

  
  {
  "data": [
    {
      "id": 1,
      "type": "hooman",
      "relationships": {
        "pet": {
          "data": {
            "type": "cat",
            "id": 1
          }
        }
      }
    }, {
      "id": 2,
      "type": "hooman",
      "relationships": {
        "pet": {
          "data": {
            "type": "dog",
            "id": 3
          }
        }
      }
    }
  ]
}

Let's put aside my contrived data model for a minute, the point is that in this set the pet relationship for the hooman can be of type cat or dog. We can handle this in Ember Data by first creating a pet model:

  
  import DS from 'ember-data';

const {
  attr,
  belongsTo,
  Model
} = DS;

export default Model.extend({
  name: attr('string'),
  hooman: belongsTo('hooman') 
});

Then in the hooman model:

  
  import DS from 'ember-data';

const {
  attr,
  belongsTo,
  Model
} = DS;

export default Model.extend({
  pet: belongsTo('pet', { polymorphic: true })
});

This will instruct the relationship to look at the type property to determine the model type. You can then access through the pet property:

get(hooman, 'pet') // <cat-model>

Ok, this was probably review for some people. I recently ran into an issue where I needed to do a link-to for a polymorphic relationship. Using our same example, I would have done:

  
  {{link-to hooman.pet.name 'pet' hooman.pet}}

The router would be setup as:

  
  // you should make this one of the last routes
this.route('pet', { path: '/:pet_type/:pet_id' });

When we are using link-to there really isn't an issue as Ember will just use the model passed in as the model. But we want a nicely formatted URL. Ideally if we are passing in a cat pet we would end up with the url: /cats/2 and if we are passing in a dog pet we'd get /dogs/5 and both would be processed by the pet route and template (of course we'd have to make sure they both respond to the same properties).

To get this we can override the serialize function in our pet route. serialize is used to parse information out of your model to render the URL associated. It is simple enough to do what we want:

  
  import Ember from 'ember';

const {
  get,
  Route
} = Ember;

export default Route.extend({
  serialize(model) {
    return {
      pet_type: model.constructor.modelName,
      pet_id: get(model, 'id')
    };
  }
});

Now the link-to will render how we'd expect. Well, mostly. With this we end up with singular route names: /dog/5 instead of /dogs/5 for example. We need to pluralize.

Because we're using Ember Data the ember-inflector library is pulled in automatically. Let's use that:

  
  import Ember from 'ember';

const {
  get,
  Route,
  String: { pluralize }
} = Ember;

export default Route.extend({
  serialize(model) {
    return {
      pet_type: pluralize(model.constructor.modelName),
      pet_id: get(model, 'id')
    };
  }
});

Now we get /dogs/5. If you are using a different type that does not pluralize nicely (for example person => persons instead of people) then check out the ember-inflector README for details on how to add the pluralized types you need.

This is great, except if someone visits the URL directly instead of clicking on a link. Let's add support for that.

  
  import Ember from 'ember';

const {
  get,
  Route,
  String: { pluralize, singularize }
} = Ember;

export default Route.extend({
  model(params) {
    return this.store.find(singularize(params.pet_type), params.pet_id);
  },
  serialize(model) {
    return {
      pet_type: pluralize(model.constructor.modelName),
      pet_id: get(model, 'id')
    };
  }
});

There we go! Because the URL segment was pluralized we used singularize to force the type back to what the store expects. I hope this helps you.

Suave Up Your Code

2015-08-07 00:00:00

/swÃ¤v/ "Smooth in texture, performance, or style"

You may have heard of this thing called ember-suave. It's a handy Ember CLI addon that Robert Jackson and I put together a few months ago to enforce code style consistency across teams and projects. If you're wondering how the addon got its name, just ask Rob. He was feeling inspired that day.

ember-suave uses JSCS to ensure that your code conforms to a set of code style rules, and fails your tests if it doesn't.

Unlike JSHint, which aims to detect errors and potential problems in your JavaScript code, JSCS is a code style linter. In other words, it is the tool you need to make sure all those hearty debates on tabs vs. spaces don't go to waste, and that whatever style guide you managed to settle on within your team can be enforced and maintained.

The first rule of `ember-suave` is to install `ember-suave`

With JSCS, you control which rules to enable within a project by specifying the rule names and options in a .jscsrc file, which may look something like this:

  
  {
  "esnext": true,
  "disallowSpacesInsideParentheses": true,
  "disallowTrailingComma": true,
  "requireBlocksOnNewline": true,
  "validateIndentation": 2
}

Assuming you're adhering to a single style guide for all your projects, the configuration would be the same everywhere. ember-suave exists so you don't have to recreate and maintain that file in every project. The addon comes bundled with a default configuration file that's nicely tucked away within the addon itself so you don't have to muck with it.

Using the addon consists simply of running ember install ember-suave, then monitoring your console for error messages during development.

ember-suave also creates a test for each file it finds in your project, so that you can enforce the code style rules as part of your continuous integration flow, and fail any builds that don't comply.

You don't rule `ember-suave`. `ember-suave` rules you.

Actually, that's not exactly true. The addon was made to be quite configurable.

You can use it as is, or you can tweak which rules to enable or disable. To configure ember-suave, simply create a .jscsrc file at the root of your project, listing just those rules that you want to modify. The addon will take care of merging your custom configuration with its own. For example, the following .jscsrc file would set a different indentation style from the default of 2 spaces. It would also disable the requireSpaceBetweenArguments rule and instruct JSCS to ignore all the files in the fixtures folder:

  
  {
  "validateIndentation": 4,
  "requireSpaceBetweenArguments": null,
  "excludeFiles": ["fixtures/**"]
}

Need more suaveness?

If you have a particular code style need but no rule exists in JSCS yet, you can easily roll your own. In fact, ember-suave ships with a few custom rules already. Let's take a look at the rule that disallows the use of var, preferring const and let instead:

  
  // lib/rules/disallow-var.js
var assert = require('assert');

module.exports = function() {};

module.exports.prototype = {
  configure: function(option) {
    assert(option === true, this.getOptionName() + ' requires a true value');
  },

  getOptionName: function() {
    return 'disallowVar';
  },

  check: function(file, errors) {
    file.iterateNodesByType('VariableDeclaration', function(node) {
      node.declarations.forEach(function(declaration) {
        if (declaration.parentNode.kind === 'var') {
          errors.add('Variable declarations should use `let` or `const` not `var`', node.loc.start);
        }
      });
    });
  }
};

A rule will always have these three methods: configure, getOptionName, and check.

getOptionName is self-explanatory.
configure is where you assert that a rule has been configured properly in a given .jscsrc file. For example, this would not pass the assert, since the value has to be true:

  
  {
  "disallowVar": "Feeling suave today!"
}

check is where all the magic happens. Any given file would first get parsed by JSCS into an AST (Abstract Syntax Tree) before you can analyze its content. You can use the file object that is passed into the check function to iterate over specific nodes of the tree. For this custom rule, we are looking for any variables that were declared using var. If such a declaration is found, we add to the errors object, passing in an error message and the position of the offending code. This is what you would see in the console if you tried using var:

  
  disallowVar: Variable declarations should use `let` or `const` not `var` at router.js :
|import config from './config/environment';
|
|var Router = Ember.Router.extend({
--------^
|  location: config.locationType
|});

Confused about the node types and what to look for? It's actually not very complicated. You can navigate over to Esprima, the parser used by JSCS, enter a code snippet into the Online Parsing Tool, and see what the corresponding tree looks like.

For instance, var color = 'blue'; will generate the following syntax tree:

  
  {
  "type": "Program",
  "body": [
    {
      "type": "VariableDeclaration",
      "declarations": [
        {
          "type": "VariableDeclarator",
          "id": {
            "type": "Identifier",
            "name": "color"
          },
          "init": {
            "type": "Literal",
            "value": "blue",
            "raw": "'blue'"
          }
        }
      ],
      "kind": "var"
    }
  ]
}

Now you can see why we were checking for nodes of type VariableDeclaration, and why we checked whether they were declared with var using declaration.parentNode.kind === 'var'.

You can also refer to the many rules that already exist in JSCS as you write your own.

Conclusion

ember-suave started as an internal need at DockYard to enforce our style guide in a painless, automatable way.

That said, the addon was built such that anyone can take advantage of the tool. If you start a new Ember CLI project, I recommend you check it out. And if you're thinking of dropping it into an existing project, but fear that the sheer amount of potential error messages would be too time-consuming to address all at once, you can always start by disabling all the rules, then re-enable them one rule at a time. Or you could exclude specific folders; whatever helps bring more suaveness to your code.

Building json-api endpoints with Phoenix

2015-08-05 00:00:00

I'm currently building a Phoenix backend API that is being consumed by Ember Data 1.13 which uses JSON API. Here is how I hooked everything up.

Configuration

You first need to tell Phoenix that it should accept json-api format. I created a new pipeline/2 for the API:

  
  # web/router.ex

pipeline :api do
  plug :accepts, ["json-api"]
end

We next need to add the corresponding MIME type:

  
  # config/config.exs

config :plug, :mimes, %{
  "application/vnd.api+json" => ["json-api"]
}

Now we have to force Plug to recompile. To do this we have to touch a file in the dependency. This may seem a little odd but the documentation recommends this.

> touch deps/plug/mix.exs

> mix deps.compile plug

I like to namespace my APIs so I created a scope and piped it through my api pipeline:

  
  # web/router.ex

scope "api/v1", MyApp do
  pipe_through :api
end

I declare all of my API routes in that scope.

Emitting

To emit json-api responses I am currently using ja_serializer. The author has indicated that some big changes are likely to better align with Phoenix conventions but for now this is the only serializer I am aware of. The README explains how to serialize, it is pretty simple. For example, to serialize a collection form an index action:

  
  def index(conn, _) do
  foos = Repo.all(Foo)
  |> MyApp.FooSerializer.format(conn)

  json(conn, foos)
end

You may wish to use Views but I've opted not to.

The serializer itself would look like:

  
  # serializers/foo_serializer.ex

defmodule MyApp.FooSerializer do
  use JaSerializer

  serialize "foo" do
    attributes [
      "name",
      "description"
    ]
  end
end 

You can embed relationships as well, check out the project for more deatils.

Consuming

Ember Data not only expects to get JSON API format but also sends JSON API format back to the server when you are creating or updating. The attributes keys come in hyphenated and everythig is nested under "data" => "attributes". Here is how I made life easier for mmyself.

I first wrote a new plug that deserializes all params that are coming in by forcing hyphenated keys to underscore format. It works recursively on all keys and produces a new params object that is Phoenix friendly. Here is the code:

  
  # web/plugs/deserialize.ex

defmodule MyApp.DeserializePlug do
  def init(options) do
    options
  end

  def call(%Plug.Conn{params: %{"format" => "json-api"}, method: "POST"}=conn, _opts) do
    result = _deserialize(conn)
  end

  def call(%Plug.Conn{params: %{"format" => "json-api"}, method: "PUT"}=conn, _opts) do
    _deserialize(conn)
  end

  def call(%Plug.Conn{params: %{"format" => "json-api"}, method: "PATCH"}=conn, _opts) do
    _deserialize(conn)
  end

  def call(conn, _opts), do: conn

  defp _deserialize(%Plug.Conn{}=conn) do
    Map.put(conn, :params, _deserialize(conn.params))
  end

  defp _deserialize(%{}=params) do
    Enum.into(params, %{}, fn({key, value}) -> { _underscore(key), _deserialize(value) } end)
  end

  defp _deserialize(value), do: value
  defp _underscore(key), do: String.replace(key, "-", "_")
end

I then added this custom plug to my api pipeline:

  
  # web/router.ex

pipeline :api do
  plug :accepts, ["json-api"]
  plug MyApp.DeserializePlug
end

Next, JSON API's schema is verbose and I didn't want to have to deal with this in my actions, Elixir's pattern matching is perfect for this. I capture all the attributes into params:

  
  def create(conn, %{"data" => %{"attributes" => params}, "type" => "json-api"}) do
  # create action now has
  # a "params" object with all the
  # attribute date from the client request
end

We can even guard the action for JSON API specific types.

Conclusion

Getting JSON API working with Phoenix takes a few hoops to jump through, but hopefully this helps you get up and running.

Paving Desire Paths

2015-08-03 00:00:00

Desire path by wetwebwork is licensed under CC BY 2.0

I recently came across the term Desire Paths while reading The Universal Principles of Design. Desire Paths are signs of use or wear indicating a preferred method of interaction. Most often they can be seen as shortcuts or diversions from the expected route. Some have clear intentions, like the picture shown above. This one in particular provides a direct route to the other side of the park.

Desire paths are helpful in understanding users. They provide unbiased, concrete evidence into usersâ preferred activity. But they also serve as a reminder about how we may have assumed their activity incorrectly.

Letâs consider this scenario. You are a park planner. Your job involves figuring out where the trees, benches, and other park related objects go. Your goal is to have people use and interact with the park. Adding paths seems like a direct means to accomplish this objective. âI add paths, and people will use them to get where they need to go.â This follows a sort of âbuild it and they will comeâ logic.

However this is not the best practice. What the park planner lacks in this scenario is any insight from users. Are the paths they're designing really the best, most efficient routes through the park? Is that what users are even after? Maybe users simply want to meander and walk leisurely. Or maybe they use it for running. In any case, the park planner likely forgot to holistically consider the user base.

Imagine instead they had planted grass and trees and waited a year or so for users to interact with the park. The result would be a network of natural paths created and defined by users. At this point, the park planner could then pave all the paths, feeling confident that the decisions were justified. This method of design is not only efficient, it is also affordable. A little bit of research can save on both time and money, all while creating a better experience. Â

Desire paths are a design principle that can be applicable to any industry. Letâs take a look at Twitter. During its humble beginnings Twitter was a pretty basic service, offering not much besides a stream of updates from your friends. Over time, Twitter noticed some unexpected trends appearing in their service. People who wanted to reply to someone else would simply direct it at them with an @ symbol and then enter the user's name. (i.e. @Bill). As more people began doing this, Twitter began to take notice, eventually integrating it into the service. The same thing happened with hashtags and group discussions.

What Twitter did correctly was first come up with a solid concept and deploy it, paying close attention to their user base. They provided the infrastructure, then sat back and watched as people used it to their liking. From this, natural trends began to emerge, paths became visible, and soon features were being defined - not by the service, but by the users.

This is precisely the value of desire paths. They can reveal better solutions for users. Ones that werenât even considered in the first place. So take note of desire paths, learn from them, and build on top of them. Itâs your users talking, time to listen.

Taking Advantage of Time Limitations In Design

2015-07-31 00:00:00

There may not be a larger, more persistent constraint in design than the notion of time. Time haunts us with its impact on our projects. There exists a constant struggle to come to terms with the fact that time is never going to be on our side. How often do we find ourselves saying, âIf only I had more timeâ¦â?

One of the primary effects of time on design is its ability to force a result. The limiting nature of time forces us to be persistent and show progress. Yet persistence and progress are important parts of creating meaningful work. Designers need to focus on how to best use time weâre allotted because we donât seem to notice just how beneficial time can be when itâs limited.

The following three practices can always help in delivering a successful design. They add clarity to your work but are especially valuable in the sense that they donât require a massive amount of time in the design process.

The grid

A grid can be constructed promptly and is very flexible in solving our visual design goals. Grids allow us to control the proximity of elements, therefore providing balance, arrangement and other visual suggestion to users. For a user, this can make a design attractive. How attractive something is, regardless of its usability, will inevitably leave a positive impression on users. This is loosely derived from a principle known as the aesthetic-usability effect. Content is an important driver in design but the grid assists in providing clarity and consistency in digesting content.

Design patterns

The ability to dictate color, shape, size and behavior of elements means we can create design patterns that are easy to repeat, and assist the user in interacting with and understanding a design. Our ability to quickly reuse patterns saves us time in the design process. Remember that users are humans â theyâre creatures of habit. Patterns allow users to become easily acclimated to a design. Patterns will also allow users to manufacture habits of interaction and recognition.

Consistency

Reuse core interactions in a designâs micro experiences. This will build consistency in a design and can increase usersâ engagement and comfort. Where patterns allow for habitual experiences, consistency allows for predictability, smoothness and comfort in experiences. Consistency will not only keep your users happy but will often encourage them to represent your experience to others in a positive light.

The next time you find your time is limited, play to the advantage of the user by focusing on practices like these that help maintain quality and focus and directly impact your usersâ experiences. Your end result will be more likely to satisfy the goals youâve set within the limited time you have.

An Existential Redesign

2015-07-27 00:00:00

tl;dr Particularly in branding oriented design, designing for yourself really is much harder than designing for others. Iteration is important, but ensuring youâre iterating in the direction you actually want to be heading is equally (if not more) important.

When we started our company repositioning, we knew we had a great, passionate team of designers and engineers together in one office space. We knew that our focus on collaboration would allow us to create something larger than ourselves. The unique story wasnât that we collaborate, but is more about who we are and why weâre here together. What weâve come to realize is that everyone, whether theyâre a designer, developer, or project manager, is here to deliver the most impactful and delightful user experience they can. Period. Full stop.

Communicating those goals to everyone outside the walls of the business is the real challenge, however. Boiling down those huge goals that are important to us (the reasons we exist) into something that is consumable and effective for the business is a struggle. Most of the writing felt inaccurate, fluffy, or just purely missed the mark. The same was true for visual communication of that language.

Weâre in the client services industry and that means the messaging is not really about us, our story, or our work. Itâs about how we solve problems for the businesses we serve in a way that is long lasting, thorough, and exceedingly performant. This is what our team is able to do, and this is what matters to both our clients and to us. This is where our objectives clearly align with our clients. This is where we found our focus.

Iâm very happy with the release of our site and company direction, and I hope youâll benefit from the detail on the challenges and personal growth we experienced in the process.

The sawing in the garage

It started small, quiet, with hardly any expectation to grow into a project. We were experimenting to see what something more representative of our design process and skill might look like. And what a very big project that became.

Initially, we were in unbound exploration mode using our 20% time (we reserve Fridays for improving craft / professional development) to freely experiment with the design vision for DockYard. Undoubtedly a valuable use of time as it stirred up the realization of our need for a full repositioning, but the actual scope of the project crept up on us fast.

When the project became more serious we did not formalize our process as we would have with any of our client projects. This sucked. We wanted it to be perfect and decided weâd spend whatever time we needed to make it so. But, as many of you know, this can become (and was) the enemy of production. We suffered for it, for a period, but the experimentation did lead to something very good. Once we discovered and felt the pains of not running through our own processes, we ate our own dog food and pushed onward with everything we had learned from the experiments.

Sit down, stand up

We followed many paths. Many were really not optimal, even though at times quite beautiful. Only a few actually made any business sense.

Illustrate darn near everything This is one of those reactions to your own work where you feel a little crammed in a box and just want to âdo youâ. After a couple days of self reflection on this we had to tell ourselves the obvious: weâre designing a site for a product design and development services company, not a game or event promotional site. This served the latter much better than the former, and we moved on after a few iterations that included degrees of illustration use. While beautiful, unique, and fun to experiment with, they didnât meet our own business goals. It was part of what we do, not all we do.
Patterns Some pattern work was considered for masthead imagery, but ultimately it never communicated anything, so we killed that as well. Perhaps weâll bring back some patterns in the future, but itâs going to depend on the content of the page. In these cases they felt like mere decoration without reason.
Photography â¨We relied upon photography pretty heavily for our last site, and perhaps subconsciously we decided we would avoid it for the new site. Because we did, and for a long time. We used some silly photographs here and there that we found as placeholder, but didnât take the approach seriously until iteration began on the site design you see today.

Content is hard, people!

We knew it wasnât going to be easy, of course, but then we tried hiring an outside editor to help us improve the content we had created according to our messaging goals. They made a lot of promises, and we framed our project timeline around them. After several disappearances and excuses, then later finding out that they never made movement on the work, we moved on. We went back to the process we use for every blog post: one owner of the content, and team review on Github or Google Docs.

Aside from that, we had created a lot of content over the years, but had deemed it all out of date with our current thinking. So we wrote it all over again. In the process of writing we discovered better branding positioning and a better content strategy.

Continuous integration

Embracing the concept of iteration on a marketing site is actually pretty strange in practice. Iâm very used to the experience within application product design and development, but much less so with a site that is supposed to communicate a well formed brand message and is typically considered very static.

But that message will never be perfect, will it? Putting up a site like ours and planning on iterating on the messaging feels a bit like sending an extremely important e-mail before you had a chance to read over what you had just written. But our site really isnât that one-and-done static marketing site anymore: itâs to constantly evolve with us and our thinking.

We treat our releases now like we would any client project. We experiment, collaborate, create timelines, do reviews, and dedicate people to the project full time. This is how weâre able to deliver on client projects, and itâs how weâll continue to deliver on the DockYard website, events, and other projects.

The site and brand are a significant improvement over what weâve had in the past, and theyâre a great base for continuous iteration. Content, photography, illustration, and even branding will evolve with much greater ease here, and that makes me very excited for whatâs to come.

Using bare arguments with Ember components

2015-07-24 00:00:00

ember-cli-async-button provides you with a button that changes state based on a promise in an action. We received a request a while back to allow users to pass parameters to the action the async-button calls. We provided the following API for doing so:

  
  {{async-button model action="save" default="Save" pending="Saving..."}}

The async-button calls the following save action:

  
  export default Ember.Component.extend({
  actions: {
    save(callback, model) {
      callback(model.save());
    }
  }
});

Notice that the callback function is still your first argument, but you get the model as the second argument now. Prior to Ember 1.13, you had to create a helper which looked through the parameters passed in, and instantiate the component, and pass the parameters down. And you had to worry about bindings and streams, so this was a bit complicated.

Positional Parameters

With the release of Ember 1.13, components have a special property called positionalParams, which can be an array of strings that would translate parameters in the component instantiation into properties on the component.

  
  {{x-foo "Dan" "McClain"}}

  
  // x-foo component

export default Ember.Component.extend({
  positionalParams: ['firstName', 'lastName']
});

// Retrieving the values
Ember.get(this, 'firstName'); // => "Dan"
Ember.get(this, 'lastName');  // => "McClain"

"Dan" and "McClain" would be set as firstName and lastName, respectively, on the component. You may ask "What if we want to have an arbitrary number of parameters passed to our component?" Well, that's handled for you too! If positionalParams is a string, instead of an array, the parameters passed to your component will be an array set to that property.

  
  {{x-foo "Dan" "McClain"}}

  
  // x-foo component

export default Ember.Component.extend({
  positionalParams: 'nameParts'
});

// Retrieving the values
Ember.get(this, 'nameParts'); // => ["Dan", "McClain"]

Cleaning up `ember-cli-async-button`

We no longer have to make a helper to clean up our API for async-button, and here is the commit where I did so. I set the positionalParams here. Note that I removed the helper that we had previously used to provide the same API. When you are creating a component and you want a way to pass parameters that are not explicitly bound to properties, you can now use positionalParams, and not muck around with helpers and streams just to pass info into your component!

Color and culture

2015-07-15 00:00:00

This post is based on a talk I will be presenting at UX Camp July 18â20, 2015.

Four posts in this series: - Part 1: Color use in art history - Part 2: Color in culture - understand your own assumptions (youâre reading it!) - Part 3: A quick intro to color theory (coming soon) - Part 4: A three-step approach to selecting color for UX design (coming soon)

A dangerous color combination

This was a fence painted blue and yellow. It stood around a kindergarten building in Moscow, Russia early last year. The color of the fence almost caused the kindergarten to be shut down. Because, at about the same time, there was political turmoil between Russia and Ukraine and the fence colors just happened to be a cheery combination of blue and yellow that matched the Ukrainian flag.

After the brief scare, the kindergarten was not shut down or burned to the ground. Instead, they simply had to repaint the fence.

This shows we canât use colors without understanding their cultural context. Letâs look at some other curious examples of what colors could mean to audiences of differing cultures.

Did Ancient Greeks care about color?

Source

There are dozens of references to a âwine-dark seaâ in the Iliad and the Odyssey. But did Homer actually mean that the sea was the same, deep red, color as wine?

Not necessarily. It is still a mystery to historians how exactly color was perceived in ancient Greece. My favorite explanation is that color, meaning hue, did not matter as much as how dark or light an object appeared.

Color systems in Greek, Latin and other languages do not map neatly to the rainbow. Umberto Eco compares the color terms in the HanunÃ³'o language to the ones we use today. Instead of hue, tint and shade, they describe objects as light and dark, but also fresh vs. dry and edible vs. inedible.

Color is poetry

Japan in the Heian period is the opposite of Homerâs Greece. People at court really care about colors. By looking at the arrangement of the layers of silk in someoneâs sleeve, you could judge their social status, sophistication, and knowledge of the arts.

How do you read a color?

Green

The color green is most often used to mean money. It just happens that one of the richest countries in the world prints âgreenbacksâ. Our green currency is partially due to the plentiful and stable ink that was available at the time, but also related to an earlier Dutch reference: the cloth on bankersâ money counting tables used to be a deep emerald green. Regardless of the source - other countries with much more varied color currencies simply had to adjust to how the US reads âgreenâ.

In predominantly Muslim countries, a stronger cultural reference for the color green is the religion of Islam.

When weâre talking about natural things, or, say, sourcing construction materials - green stands for ecology and recycling.

And, of course, the meaning of green in user interfaces is similar to a traffic light: green is âsuccessâ.

Letâs keep going.

Blue

The same blue can refer symbolically to Maryâs clothing (the âreservedâ color of Ultramarine blue), or the skin of Krishna, and in modern days - to accessibility or web links.

Red

Red is used consistently in traditional bridal-wear, in combination with gold. Politically, red often refers to Communism. In interfaces, the most common use of red is to show an error or a warning (like a stop sign) but I find that in Chinese interfaces, red has much less connection to âerrorâ and is used more freely as an additional brand color.

Yellow

Just a few examples of âobviousâ meanings of yellow: Buddhist monks, alert messages, a school bus, and sunshine.

Itâs a mess. Where do we go from here?

So weâve seen examples of color meaning that contradict each other (which one to pick?) There are many more. We took time to look at them so that we can be sufficiently scared of misunderstanding our users. This way, weâll actually do our research.

The formula is this: add together politics, cultural context, language differences, and how important color is to the audience. This is how you know where to check for mistakes in selecting UI and brand colors. Always check your defaults and assumptions, and youâll reduce the risk of a cultural #facepalm.

Changing your environment will change your work

2015-07-13 00:00:00

Environment is key to the way we learn and work

We often hear stories of genius artists and designers working hard and defying their odds. And while this is certainly an option, I want to talk about the opposite: we have the power to intentionally move into an environment that supports our creative process.

We often think of âenvironmentâ as a physical space, but people and expectations can determine our mental work space regardless of physical location.

1. Physical location

It seems obvious, but the physical location â the room, the set-up, the potential distractions and the familiarity of the space â play an important role. Many creatives choose to work in coffee shops, hotels or other âanonymousâ spaces because leaving their home office helps focus on the task at hand. It can be easier to focus against an unfamiliar environment, rather than to focus against an intimately familiar space of your own house â full of potentially distracting things you could do.

In addition to focus, we can gain inspiration and a fresh perspective from traveling to a new place. These will reflect in the content, as well as the quality of work.

2. Momentum

Studies show that people eat more when they have the momentum of eating in a group. For work, too, the momentum of a group doing a similar thing at once can be powerful. Imagine trying to study in a loud dorm room, or focusing on a project while everyone else in your house is doing the normal weekend activities: preparing for a barbecue, watching a favorite TV show or just socializing. Normally, we try to improve our working conditions simply by removing the distractions: getting a quiet place to concentrate, where no TV show is competing for our attention.

Why not go a step farther? Purposefully placing yourself into an environment where the momentum points toward producing creative work tips the balance in your favor.

3. Expectations

And while weâre on the subject of momentum â just being in an environment where people expect that youâve showed up to do creative work can support your process. Normally, the first step is to start â to make the decision to work on a creative project right here and right now. In a dedicated time and space, when you have intentionally decided to set aside a weekend for creative work, and made the effort to show up, you are now removing the choice of whether to start on that project or not. The expectations of everyone around you will nudge you forward.

This is true for many types of environments: dedicated âproject workâ time in a college class, an art studio where you might attend life drawing sessions, a co-working office space, or even a very supportive office environment when creative projects are encouraged on set-aside time. However, we stumble across fewer and fewer of these environments as our careers progress (whenâs the last time you took a college class?), so it is important to purposefully place ourselves in them.

4. Feedback

Another important aspect of a working environment is giving and receiving feedback. It can help you when you feel stuck on a project, but more importantly, it can help you realize things you have not seen from your perspective. Basically, find out that you were stuck without even knowing it.

Creative feedback is a two-way process: in order to receive it, we have to be prepared to give it as well. Investing time to learn about othersâ process and goals may feel like a setback when you are eager to make progress on your own ideas, but, aside from being a fair exchange, itâs also beneficial to broaden your frame of reference.

Giving and receiving feedback openly has another advantage. When you expect to share your work in a supportive environment, youâre mentally preparing to explain your project to someone who is unfamiliar with it. Just the effort of translating your thoughts into a clear outline for others to understand can expose potential improvements in the process, and make your work better before you even begin to share it. In a common scenario, you could start explaining a complex bug youâve been dealing with, then stop halfway with an âaha!â because the explanation caused you to solve the problem yourself.

5. The nudge

Sharing your work, even with a small group of like-minded creative people, can also nudge you to wrap up any loose pieces and present it well. It is often easier to complete some portion of a project, even in draft form, instead of explaining over and over again what you imagine that component to be in the future.

I had this ânudgeâ happen to me recently, as I was presenting a short talk here at DockYard about an idea I had been working on. I mentioned the domain name I had registered for it, but at the time of the talk, the website was still in draft mode. Brian called me out on that â âthereâs nothing there yet!â â and I quickly proceeded to publish the site to be able to support my words when I mention the project again.

In summary

As we prepare for UX Camp, I realize more and more that the environment we are building is special exactly because it embodies all of the qualities of a supportive working environment. And the type of people who will go out of their way to rural Maine for a project-based learning weekend are exactly the type of people I want to be around.

My project for UX Camp summer 2015

2015-07-08 00:00:00

Iâm super excited to attend (and help organize) this summerâs UX Camp. Last fall we had an inspiring, productive weekend and this year I expect even more.

The camp is a project based weekend, meaning that in addition to talks and workshops, we can all bring a project we want to focus on. Today, I want to share what I tried last fall, how it turned out, and what Iâm bringing with me this year.

What I got last year

Last year, I focused on improving my visual thought process through quick sketching. I brought a clipboard, a felt tip marker and a stack of paper, and practiced quickly and roughly sketching out any ideas or notes that I wanted to capture throughout the event. My set-up (clipboard, paper and one pen) was intentionally minimal because I wanted to be able to pick up the project in the breaks between helping run and document the event, and listening to lectures and workshops.

The result was encouraging: I was able to fill about 25 sheets with rough drawings, and got a bit more comfortable capturing my ideas in drawing form, rather than as a list or a paragraph of text.

What Iâm doing this year

This year, I am hoping to try a slightly more involved project: repeat patterns. It will require a few extra tools, and a bit more space than last yearâs.

The inspiration

I was inspired by Matisse - his paintings and even more, his creative process. He sourced colors and textures for his work from an extensive collection of textiles, artifacts and clothing. I want to create repeat patterns for use online (an existing interest of mine) by sourcing color and texture inspiration from Matisse.

The tools

To sketch the patterns, I will bring: - Markers in a few colors - Sheer marker paper - Masking tape (to display my results on a window) - A ruler and a pencil - Scissors and clear tape to re-combine shapes

The process

I plan to start with a grid and play with layering patterns on sheer paper to arrive at different solutions. The initial drawings will likely be very messy, but I expect that the clarity will improve as I work on the same idea a few times.

The goal

I plan to iterate in public so I can take advantage of the camp setting. While a specific result (pattern) may look good and useful to me, others may offer an unexpected opinion. By showing my work early and getting feedback - even if feedback is anecdotal, like - âyeah, I might use something like that for a web projectâ - I will have the advantage of many peopleâs perspectives.

So, here! Iâve shared my plans for camp! My colleagues at DockYard are getting ready as well.

Tim is planning to either focus on a typeface heâs been crafting this year, or begin conceptualizing an idea for a live music website.

Steve is still undecided about what heâll focus on in addition to running the camp. (Perhaps, you can tweet an idea for him to work on!)

Patrick might finally tackle an infographic heâs been planning to make for a pumpkin beer review site he runs, so that he can release it in the fall.

Amanda will be working on a future conference talk and learning about animating SVGs.

What are you excited to work on? Share your ideas with us!

Use of color through art history

2015-06-25 00:00:00

This post is based on a talk I presented at UX Burlington

Color is one of the basic tools for UX design. It is very powerful: it affects us psychologically, physiologically, and, of course, aesthetically. But color selection can be intimidating: with millions of options, designers often feel lost because all the options look equally valid.

In this series, I will show where color is complex, and then suggest a stepâby-step process to make color selection less intimidating.

Color was not always a thing.

Peopleâs understanding of what color is has changed over time. Today, we think of it as a continuous spectrum, consisting of millions of options.

Our ability to digitally manipulate color contributes to our understanding of it as an infinite space of millions of options.

Medieval color: paint-by-number

This was not alway the case. In Medieval Europe, people thought of color as colors â separate pigments that are made of different physical materials. Where we might think of two blues as related shades of a single color, medieval artists considered Ultramarine blue and Indigo two separate colors, and never mixed these pigments. In fact, ultramarine - a rare imported pigment - was more expensive than gold. Because of this, colors were rarely mixed (giving a distinct âpaint by numberâ look to illuminated manuscripts) and the expensive pigments were reserved to paint nobility, royalty or holy figures.

Vermeerâs color: under contract

In the 1600s, we start seeing the use of color loosen up a bit. Pigments are no longer reserved for specific use. In this example, the milkmaid by Vermeer, is not royalty. But her dress has the precious ultramarine - and it is mixed and glazed over other color to produce a color effect we would call realistic today. However, the pigment was still very expensive, and the amount of ultramarine to be used in the painting was specified precisely in a contract.

Industrial revolution: OMG COLORS!

The Industrial revolution brought two important innovations to art: synthetic pigments and tube paints. Synthetic pigments started making vibrant colors more available and affordable for artists, and tubes made paint portable for the first time.

William Perkinâs Mauve was the first synthetic pigment. It allowed a vibrant shade of purple-fuchsia to be applied in a stable manner to fabric and of course to paint. Other pigments followed, and soon there was enough to make art a bit too colorful for some tastes.

The invention of paint tubes by Windsor and Newton allowed artists to bring painting outside. So, where before we saw the sky, the trees and the hay their respective âproperâ colors, modulated by dark shadows and bright highlights, impressionists started painting from observation and added all kinds of wild atmospheric colors to their hay.

After impressionism came expressionism. Here, Van Gogh does not show his impression of the way the room looked by using these vibrant, almost âacidicâ colors. Instead, he expresses his emotions through how he treats the appearance of the room. By this time, the use of color moves away from realism and towards expressing artistic goals.

1950s: color is the message

Even farther from references to reality - this 1950s piece by Yves Klein uses color by itself as the message. In fact, the artist patented the chemical process to make this pigment (very similar to a synthetic ultramarine) and made the pigment itself a central part of his artwork for the remainder of his career.

1960s: any color you want!

By the time we get to pop art, the technology behind making pigments has become so advanced that we as consumers became used to expecting any mass produced product to be able to be any color we want. This is why, in pop art, we see the color variations of Warholâs Marilyn and they seem equally valid. Any color selection, as long as it is intentional, can be as good as any other.

Where are we now?

In summary - we went from color being an inseparable, intrinsic part of the material something is made of, to color being a changeable, almost arbitrary attribute of a thing. With seemingly all the possible (digital) colors at our fingertips, it is no wonder we are lost for choice. It is understandable to feel a overwhelmed by the selection.

In the next post, I will explore the meaning different cultures can give to color.

Copy to Clipboard Without Using Flash!

2015-06-19 00:00:00

For a long time we've had to rely on Flash plugins like ZeroClipboard to copy text to the clipboard. While Flash still remains the only cross-browser solution for copying to a userâs clipboard, some browsers have recently added the ability to trigger cut and copy using document.execCommand()! Specifically, IE10+, Chrome 43+, and Opera29+. Firefox seems to have some options that allow users to grant permissions to certain sites to access the clipboard, but I haven't tried it out myself.

For those of you not familiar with execCommand(), it is more than just cut and copy! It is one of the core methods of rich-text editing in browsers. You can manipulate the contents of the current document, current selection, or a specified range through various commands. Some other common commands include: bold, delete, createLink, and indent.

execCommand(commandName [, showUI [, value]])

commandName (String): the property that you are validating.
showUI (Boolean) optional: Display a user interface if the command supports one. Defaults to false.
value (DOMString) optional: Specifies the string, number, or other value to assign. Possible values depend on the command. Pass an argument of null if no argument is needed.

Note: You must set document.designMode = "on", or set contenteditable="true" on the element that you wish to use execCommand() on.

However, like cut and copy, not all commands are enabled across all browsers. I created an Ember JSBin with a simple WYSIWYG to demonstrate some of what execCommand() can do. Feel free to play around!

Now to demonstrate how execCommand paired with the Selection API can easily copy to a user's clipboard. Below is our HTMLBars with a promo code string that we want to copy.

  
  <p>Promo code: <span class="promo-code">SALE123</span></p>
<p><button {{action "copyToClip"}}>Copy</button></p>

When the Copy button is clicked, the following action will be called:

  
  copyToClip: function() {
  const promoCode = document.querySelector('.promo-code');
  const range = document.createRange();  
  range.selectNode(promoCode);  
  window.getSelection().addRange(range);
  document.execCommand('copy'); 
  window.getSelection().removeAllRanges();
}

In this action we create a range of the document and add our promo code text as a node of that range. We then use the Selection API method window.getSelection().addRange() to add the part of the document we want to copy to the user's selection. document.execCommand('copy') then copies that selection to the clipboard. And finally, we remove the selection by calling window.getSelection().removeAllRanges() so that the user never sees the highlighting.

And that's it! If you wanted to confirm everything worked as expected you can examine the response of document.execCommand(); it returns false if the command is not supported or enabled.

You can check this example out in this Ember JSBin.

Maintaining a session in Phoenix integration tests

2015-06-12 00:00:00

I'm using Phoenix to power the backends for a couple of Ember projects I am writing. For those applications, I've been using OAuth2 + cookie-based sessions to authenticate my users. When testing the authentication flow, I wanted to make sure that I was properly retrieving my session from the cookie I previously set.

The hard way (pre Phoenix v0.13)

The following maintains a session across multiple requests:

  
  test "Creating a session with a GitHub code" do
  use_cassette "successful_sign_in" do
    response = conn(:post, "/api/v1/session", %{ "authorizationCode" => "dan", "format" => "json", "provider" => "github-oauth2" })
    |> DoorApi.Endpoint.call([])

    assert response.status == 201

    current_session_request = conn(:get,  "/api/v1/session")

    current_session_response = response.cookies
    |> Enum.reduce(current_session_request, fn ({key, value}, conn) -> put_req_cookie(conn, key, value) end)
    |> DoorApi.Endpoint.call([])

    assert current_session_response.status == 200
  end
end

The above code copies the cookies from the first (completed) request, and appends them to the second request. This allows you to retrieve information from the session returned in the first request.

But wait! There is a better way

With the release of Phoenix v0.12, new test helpers debuted that allow for the concept of connection recycling. TL;DR: the new helpers create a new connection with the details of the old, completed connection. We can update our first example to use the new helpers:

  
  test "Creating a session with a GitHub code" do
  use_cassette "successful_sign_in" do
    # We call the conn function to get us an initial connection.
    # From then on, we just pass the result of the last request to the helpers
    conn = post(conn(), "/api/v1/session", %{ "authorizationCode" => "dan", "format" => "json", "provider" => "github-oauth2" })

    assert conn.status == 201

    conn = get(conn, "/api/v1/session")

    assert conn.status == 200
  end
end

The helpers remove the need to call our endpoint, and make the code much more concise. This is a huge improvement to testing in Phoenix. You can see a bit more about the helpers in the Phoenix.ConnTest documentation

Go: UX Camp 2015

2015-06-09 00:00:00

Letâs go back to camp.

This July 18-20 weâre heading back up to Maine, and to a really cool (remote) location. We have four cabins on the lake in Caratunk, ME, and I invite you to join us!

Just like last year, itâs a UX design focused project weekend with intermittent design talks, workshops, games, and music. This year weâre going to have the incredible (Boston based) band The Grownup Noise performing for us around the camp fire.

And for those of you who are musicians, I implore you to bring some instruments. There will be musical improvisation, led by The Grownup Noise, and weâd love for you to play along with us.

If you have questions or are interested in sponsorship, please e-mail me at steven@dockyard.com.

See you there!

A clean pattern for modal dialogs

2015-06-08 00:00:00

Recently, I was working on a project which had a number of different modals. I discovered a really clean pattern for implementing modals via actions and ember-modal-dialog.

We implemented each of the different modals as separate components, and rendered ember-modal-dialog in the application template the following way:

  
  {{#if isModalVisible}}
  {{#modal-dialog}}
    {{component modalDialogName modalContext=modalContext closeAction="closeModal"}}
  {{/modal-dialog}}
{{/if}}

The component helper allows us to dynamically choose which modal we'd like to see. We call the modal via the following action in the application route;

  
  const { setProperties, set } = Ember;

actions: {
  showModal(modalDialogName, modalContext) {
    const applicationController = this.controller;

    setProperties(applicationController, {
      modalDialogName,
      modalContext,
      isModalVisible: true
    });
  },

  closeModal() {
    const applicationController = this.controller;

    set(applicationController, 'isModalVisible', false);
  }
}

We invoke the modal via a normal action call:

  
  <button {{action "showModal" "my-component-name" contextForModal}}>Show the modal!</button>

The modalContext could be as simple as a string, or as complex as an Ember-Data model. It gets passed to the component as the modalContext attribute, so you'll need to remember to retrieve your properties from within there if you are trying to do something a bit more complex.

The component helper is really what enables this pattern, otherwise you'd need to either have a series of ifs to display the correct modal. I may extract this pattern into a separate addon, as I see it as one I'll reuse frequently whenever we have multiple modal dialogs.

Declarative Breadcrumb Navigation in Ember.js

2015-06-02 00:00:00

Breadcrumb navigation isn't a new concept, in fact, it's usefulness has been endlessly debated about by UX designers all over. Today, I won't get into the nitty gritty on whether or not your app should include one, but I'd like to share an addon I built for a project I'm working on that required it.

This is a simple Component that is placed once in your application, and then generates a dynamic breadcrumb by looking up the current route hierarchy. The addon has a simple declarative API, which makes integration with your app super easy.

Let's dive in!

Demo & Source

You can take a look at the demo app to see ember-crumbly in action. What's cool about it is how little code it takes to add dynamic breadcrumbs to your app, and how declarative it is. The source is on GitHub, as always.

The idea

We work on many Ember apps at DockYard, and one particular client's project I was working on called for a very dynamic breadcrumb type UI that would respond to changes in the route and model. Before I started actually implementing it, I sketched my plan on paper to see if I could make it nice and declarative instead of manually setting the breadcrumb on each of those route templates.

The Ember Container and currentRouteName

The Component relies mainly on Ember's container and the current route name. On a high level, the Component is injected with the Application Controller's currentRouteName prop, then looks up the appropriate route in the Container to check if it has a breadCrumb prop defined. If it does, we display whatever the POJO is, or else we show its route name in the Component.

Intended usage

The goal was to have an API as declarative as the following:

  
  {{bread-crumbs linkable=true outputStyle="foundation"}}

And the route:

  
  // foo/route.js
export default Ember.Route.extend({
  breadCrumb: {
    title: 'Animals'
  }
});

We also wanted to be able to pass in our own template block too:

  
  {{#bread-crumbs linkable=true as |component route|}}
  {{#if route.title}}
    {{route.title}}
  {{else}}
    {{route.foo}} ({{route.bar}}) ... {{route.baz}}
  {{/if}}
{{/bread-crumbs}}

Let's see how we can write a component that does just that using some of Ember's new features.

Injecting the Application Controller

I've explained how we inject things in other posts, so I won't go into detail for the initializer. Ember adds the currentRouteName and currentPath to the Application Controller, so we'll inject it into our Component so we can extract it.

  
  export function initialize(container, application) {
  application.inject('component:bread-crumbs', 'applicationController', 'controller:application');
}

export default {
  name: 'crumbly',
  initialize
};

Declaring your variables

We typically declare our variables and functions used at the top of each file, to make code easier to read and refactor in the future. For ember-crumbly's bread-crumbs component, we're using the usual suspects:

  
  import Ember from 'ember';
import layout from '../templates/components/bread-crumbs';

const get = Ember.get;
const {
  A: emberArray,
  EnumerableUtils,
  Component,
  Logger,
  computed,
  getWithDefault,
  assert,
  typeOf,
  setProperties
} = Ember;

const {
  classify
} = Ember.String;

const {
  map,
  filter
} = EnumerableUtils;

const {
  warn
} = Logger;

You might be wondering why we declare const get = Ember.get; by itself on L4âââcurrently there are issues with destructuring { get } and bugs in Esprima, so we do it by itself as temporary workaround.

Component props

Here we set a bunch of default props for the component.

  
  export default Component.extend({
  layout,
  tagName: 'ol',
  linkable: true,
  reverse: false,
  classNameBindings: [ 'breadCrumbClass' ],
  hasBlock: computed.bool('template').readOnly(),
  currentRouteName: computed.readOnly('applicationController.currentRouteName')

We've injected the Application Controller into the component in our initializer, so getting the current route's name is as simple as setting a computed property macro. We make it readOnly so we don't set it by accident.

Computing the route hierarchy

Ember's currentRouteName prop returns the current route hierarchy separated by periods. For example, if you were on /foo/bar/baz, your route would probably be something like foo.bar.baz.index. Knowing this, the goal would be to split the string by the period, and then working out the route name for each of its parts. With the correct route name, we can then lookup the route on the container and extract the breadCrumb POJO we need for our bread-crumb.

  
  routeHierarchy: computed('currentRouteName', 'reverse', {
  get() {
    const currentRouteName = getWithDefault(this, 'currentRouteName', false);

    assert('[ember-crumbly] Could not find a curent route', currentRouteName);

    const routeNames = this._splitCurrentRouteName(currentRouteName);
    const filteredRouteNames = this._filterIndexRoutes(routeNames);

    const crumbs = this._lookupBreadCrumb(routeNames, filteredRouteNames);
    return this.get('reverse') ? crumbs.reverse() : crumbs;
  },

  set() {
    warn('[ember-crumbly] `routeHierarchy` is read only');
  }
})

You'll notice straight away that we're using new Ember computed property syntax here. The new syntax allows you to set both getters and setters on your CP, instead of checking argument length like you used to have to do.

Figuring out the route name

First, we split the currentRouteName string into an array, and then filter out any index routes. This is because the string splits into an array with all the parts, so foo/bar/baz would yield [ 'foo', 'bar', 'baz', 'index' ], while we only want the first 3.

  
  _splitCurrentRouteName(currentRouteName) {
  return currentRouteName.split('.');
},

_filterIndexRoutes(routeNames) {
  return filter(routeNames, (name) => {
    return name !== 'index';
  });
}

Now with the array of parts, we need to piece them together again bit by bit to reconstruct their constituent routes.

Looking up the route on the container

In here, we:

Map over the filtered route names individually
Reconstruct the route name by slicing the original array of route names with the right end argument
Look the reconstructed route name up on the container
Retrieve the breadCrumb POJO, add props to it, and return an Ember Array that our component can iterate over in its template

  
  _lookupBreadCrumb(routeNames, filteredRouteNames) {
  const defaultLinkable = get(this, 'linkable');
  const breadCrumbs = map(filteredRouteNames, (name, index) => {
    const path = this._guessRoutePath(routeNames, name, index);
    let breadCrumb = this._lookupRoute(path).getWithDefault('breadCrumb', undefined);
    const breadCrumbType = typeOf(breadCrumb);

    if (breadCrumbType === 'undefined') {
      breadCrumb = {
        path,
        linkable: defaultLinkable,
        title: classify(name)
      };
    } else if (breadCrumbType === 'null') {
      return;
    } else {
      setProperties(breadCrumb, {
        path,
        linkable: breadCrumb.hasOwnProperty('linkable') ? breadCrumb.linkable : defaultLinkable
      });
    }

    return breadCrumb;
  });

  return emberArray(filter(breadCrumbs, (breadCrumb) => {
    return typeOf(breadCrumb) !== 'undefined';
  }));
}

Reconstructing the route name

Each time map runs in the previous method, we get a single piece of the route name, e.g. bar. We know that its correct route name is foo.bar, so we can slice the original array with the map's index argument to piece those bits together. When we start with the first piece (foo), we know that we need to look up foo.index so that we can generate the correct link-to, so we check for that.

  
  _guessRoutePath(routeNames, name, index) {
  const routes = routeNames.slice(0, index + 1);

  if (routes.length === 1) {
    return `${name}.index`;
  } else {
    return routes.join('.');
  }
}

Now that we have the correct route name for each path, we can look up the actual route object on the Container while we map over the filtered route names.

Looking up the route on the Container

The Ember Container (basically how Ember keeps track of all its different objects) isn't well documented because it is originally intended to be private API. However, many addons and apps make use of it to do certain things, and this one is no exception. There is an RFC on the table with reforming the Registry and Container, so this might have to be changed in the future. For now, we can still get the Container from the Component, and then use its lookup('type:name') method to find the route.

  
  _lookupRoute(routeName) {
  const container = get(this, 'container');
  const route = container.lookup(`route:${routeName}`);
  assert(`[ember-crumbly] \`route:${routeName}\` was not found`, route);

  return route;
}

Extracting the breadCrumb POJO

With the route object in hand, we can then easily extract the breadCrumb POJO we define on our routes.

  
  let breadCrumb = this._lookupRoute(path).getWithDefault('breadCrumb', undefined);
const breadCrumbType = typeOf(breadCrumb);

if (breadCrumbType === 'undefined') {
  breadCrumb = {
    path,
    linkable: defaultLinkable,
    title: classify(name)
  };
} else if (breadCrumbType === 'null') {
  return;
} else {
  setProperties(breadCrumb, {
    path,
    linkable: breadCrumb.hasOwnProperty('linkable') ? breadCrumb.linkable : defaultLinkable
  });
}

return breadCrumb;

In certain scenarios, you might want to opt-out of displaying a specific route in the breadcrumb. We allow that by setting breadCrumb: null inside of that route. If no breadCrumb POJO is found, we set the title to be the route's capitalized name by default, and if we do find one, we simply add the path and linkable keys to it.

Finally, we return an Ember Array so that the resulting array is iterable in the template, and filter out any undefined breadcrumbs.

  
  return emberArray(filter(breadCrumbs, (breadCrumb) => {
  return typeOf(breadCrumb) !== 'undefined';
}));

With the logic done, let's look at our somewhat complicated template to handle all the different uses!

Template logic

Because we want to handle both the inline and block form of the Component, as well as the ability to make each route linkable, the template does get a little complicated:

  
  {{#each routeHierarchy as |route|}}
  <li class={{crumbClass}}>
    {{#if hasBlock}}
      {{#if route.linkable}}
        {{#link-to route.path}}
          {{yield this route}}
        {{/link-to}}
      {{else}}
        {{yield this route}}
      {{/if}}
    {{else}}
      {{#if route.linkable}}
        {{#link-to route.path}}
          {{route.title}}
        {{/link-to}}
      {{else}}
        {{route.title}}
      {{/if}}
    {{/if}}
  </li>
{{/each}}

And that's done!

This post also appears on Medium in longform.

Announcing Voorhees

2015-05-29 00:00:00

I've been building JSON APIs in Phoenix for a few Ember apps I've been working on. I wanted to ensure that the JSON response didn't include extra information in the form of attributes that should be kept server side, and returned the correct payload. We can break these two concerns into separate tests, the first making sure that our JSON response conforms to a specific "schema", the other making sure that the attributes that we care about are correct. Voorhees, named after JSON...I mean Jason Voorhees, provides functions for both of these concerns.

`Voorhees.matches_schema?`

Voorhees.matches_schema?(payload, expected_keys) makes sure that a payload conforms to a certain format. You pass in a string that is the API response and a list of keys to check it against. If that payload has extra keys, or the payload is missing keys, the function returns false, causing it to fail the assert in your test.

Examples

Validating simple objects

  
  iex> payload = ~S[{ "foo": 1, "bar": "baz" }]
iex> Voorhees.matches_schema?(payload, [:foo, "bar"]) # Property names can be strings or atoms
true

# Extra keys
iex> payload = ~S[{ "foo": 1, "bar": "baz", "boo": 3 }]
iex> Voorhees.matches_schema?(payload, [:foo, "bar"])
false

# Missing keys
iex> payload = ~S[{ "foo": 1 }]
iex> Voorhees.matches_schema?(payload, [:foo, "bar"])
false

Validating lists of objects

  
  iex> payload = ~S/[{ "foo": 1, "bar": "baz" },{ "foo": 2, "bar": "baz" }]/
iex> Voorhees.matches_schema?(payload, [:foo, "bar"])
true

Validating nested lists of objects

  
  iex> payload = ~S/{ "foo": 1, "bar": [{ "baz": 2 }]}/
iex> Voorhees.matches_schema?(payload, [:foo, bar: [:baz]])
true

Validating that a property is a list of scalar values

  
  iex> payload = ~S/{ "foo": 1, "bar": ["baz", 2]}/
iex> Voorhees.matches_schema?(payload, [:foo, bar: []])
true

`Voorhees.matches_payload?`

Voorhees.matches_payload?(payload, expected_payload) makes sure that a payload contains the right values. It should be used in conjuction with Voorhees.matches_schema?/2. Voorhees.matches_payloads? ignores values that are present in the payload but not in the expected_payload; this allows you to ignore server generated values, like id and created_at timestamps. You may not necessarily care about the values of these server generated attributes. It will return false when a value in expected_payload is missing from the payload, or when the values in the payload differ from the expected_payload.

Examples

Expected payload keys can be either strings or atoms

  
  iex> payload = ~S[{ "foo": 1, "bar": "baz" }]
iex> Voorhees.matches_payload?(payload, %{ :foo => 1, "bar" => "baz" })
true

Extra key/value pairs in payload are ignored

  
  iex> payload = ~S[{ "foo": 1, "bar": "baz", "boo": 3 }]
iex> Voorhees.matches_payload?(payload, %{ :foo => 1, "bar" => "baz" })
true

Extra key/value pairs in expected payload cause the validation to fail

  
  iex> payload = ~S[{ "foo": 1, "bar": "baz"}]
iex> Voorhees.matches_payload?(payload, %{ :foo => 1, "bar" => "baz", :boo => 3 })
false

Validates scalar lists

  
  iex> payload = ~S/{ "foo": 1, "bar": ["baz"]}/
iex> Voorhees.matches_payload?(payload, %{ :foo => 1, "bar" => ["baz"] })
true

# Order is respected
iex> payload = ~S/{ "foo": 1, "bar": [1, "baz"]}/
iex> Voorhees.matches_payload?(payload, %{ :foo => 1, "bar" => ["baz", 1] })
false

Validates lists of objects

  
  iex> payload = ~S/[{ "foo": 1, "bar": { "baz": 2 }}]/
iex> Voorhees.matches_payload?(payload, [%{ :foo => 1, "bar" => %{ "baz" => 2 } }])
true

Validates nested objects

  
  iex> payload = ~S/{ "foo": 1, "bar": { "baz": 2 }}/
iex> Voorhees.matches_payload?(payload, %{ :foo => 1, "bar" => %{ "baz" => 2 } })
true

Validates nested lists of objects

  
  iex> payload = ~S/{ "foo": 1, "bar": [{ "baz": 2 }]}/
iex> Voorhees.matches_payload?(payload, %{ :foo => 1, "bar" => [%{ "baz" => 2 }] })
true

Take a machete to your API responses

Make sure your API responses are what you expect, or cut them down at the knees when your tests fail!

Begin with Benchmarking

2015-05-22 00:00:00

Design research is critical to the beginning stage of every design project. Research orients us in the world in which we intend to build and the audience we intend to build for. It is helpful to begin by identifying other services that already exist in that space, to observe the current market offerings. Building a research catalog for reference and critique is what we refer to as "benchmarking."

Here are three major benefits to benchmarking:

It helps you better understand and articulate how your product or service is different
It is a tool for learning about topics you might not be familiar with (especially for client projects)
It allows you to observe strengths and weaknesses of existing experiences to inform your own design decisions

At DockYard, we always begin with benchmarking. Benchmarking helps us define a scope based on realistic expectations, and identify opportunities and core values for the project. It is a way to learn through exploration. In this practice and analysis we deconstruct existing complex systems, identify the minimum viable product and core interactions, and pinpoint the major actions that support user goals.

These exercises give us a better understanding of the space we intend to support, and the expectations for building a system of our own. It sets a focus and direction for ideation and user interviews, and aligns our understanding with the client's, which supports conversation.

There are several different layers to observe in a given case study from structural to aesthetic: content organization, accessibility, systems architecture, user experience methods, interface design, to visual design. It can be challenging to observe all these different layers and identify what about them creates a quality online experience.

Start broad. Identify the overall goal of the service that brings you from A to B. Is that process transparent and supportive? Were you able to easily use the product and accomplish the task at hand? Is the information accessible? How is it organized and delivered?
Look at the usability and interactions. Do the interactions make sense in context? Is the structure intuitive, clear, and easy to use? Are design patterns present: experiential, cognitive, tangible ways that help users interact with the interface? Identifying these patterns in context helps us understand where they can be used to support user interactions.
Consider the visual design and experience. What is the quality of the experience, and does it reflect the overall goal of the service? Is it delightful? confusing? distracting? Does the visual language and style support understanding?

Benchmarking isn't about taking someone else's solution and using it as your own. Every project has different content, different goals, different challenges. Deconstructing existing design solutions is key to identifying structural and experiential decisions, and reflecting on why those decisions were made to support the task at hand. This kind of critical thinking allows us to be discerning, to ask questions about how others have solved problems in similar spaces, so that we can anticipate and identify the major goals for the system we intend to build.

Through intentionally observing systems and strategies, we adopt a perpetually observant and critical mindset. The benchmarking mentality encourages us to pay attention to and appreciate the complexity of data driven web experiences, and to see how the challenges of vision, architecture, and experience were met and resolved.

Sign Up For The DockYard Newsletter

2015-05-21 00:00:00

We are now running a monthly newsletter, we'll send currated design and engineering content directly to your Inbox. The best articles from our blog as well as exclusive content that we'll only publish in the monthly newsletter.

You can sign up at the bottom of this page!

The New DockYard.com

2015-05-20 00:00:00

I'm proud to announce the new DockYard.com

With this relaunch of our website we are also changing our direction as a company. We've always been considered an engineering company but we are now considering ourselves a User Experience company. All of our design and engineering decisions go into delivering a modern user experience on the web for our clients.

This new website is also built how we believe modern web applications should be built: with Ember.js on the front-end and Phoenix on the back-end.

Over the next few weeks we're going to share the story of how our team rebuilt DockYard.com. You'll hear from our Creative Director Steven Trevathan on what went into the Discovery of our new website, the design decisions made, as well as a view of some early mockups and how we came to the final design. Dan McClain, the head of our Engineering team will discuss how we built our Ember application the "DockYard Way" which meant we had to make contributions back to Ember itself, as well as several other libraries, in order to get the experience just right. Amanda Cheung, our Lead UX Developer, will share what efforts went into the implementation of the design; how we build modern responsive markup. Finally you'll hear from Jon Lacks, our Project Manager, who will show how we managed the rebuild of our own website using the exact same processes we use on our client projects.

Along with these stories we'll not just tell you how we did things, we plan to show you. We'll be open sourcing all of the code for the Ember front-end as well as the Phoenix back-end in the coming weeks. There are also many libraries that we plan to extract from the application to share with everyone.

I'm extremely proud of the team for delivering this rebuild. It is the best example of the quality and integrity of our design and technical capabilities to date.

Detecting Ember.js Components Entering or Leaving the Viewport

2015-04-20 00:00:00

This concise version originally appears on Medium in longform.

I wrote a post last year about how I made an Ember Mixin that would let Ember Components or Views know if their DOM element had entered or left the viewport. If you're unfamiliar with the getBoundingClientRect API or the approach in general (for determining if an element is in the viewport), please have a read of that post first!

This time, I want to talk about how I improved the original Mixin to use the requestAnimationFrame API for improved performance at close to 60FPS. Because certain browsers (mainly IE) don't support rAF, we'll also setup an automatic fallback to using the Ember run loop method I used in my previous post.

Demo

I made a simple demo app to demonstrate how you might use the Mixin. The goal for this addon was to allow you to easily style or do something with Components/Views when they enter or leave the viewport. For example, you could easily use this Mixin to build a lazy loader for images, or even for triggering animations. Using this Mixin, you won't need to use a jQuery plugin and can instead rely on a highly performant ember-cli addon.

Installing the addon

If you're using ember-cli and want to use the addon, you can install it with:

  
  $ ember install ember-in-viewport

The source for the addon is available at dockyard/ember-in-viewport.

Rewriting the In Viewport Mixin

The Mixin still uses the same method for determining if a DOM element is in the viewport, using getBoundingClientRect and the window's innerHeight and innerWidth.

Updating the Is In Viewport logic

The method for calculating whether or not a DOM element is in the viewport remains mostly unchanged, except with the addition of a new viewportTolerance argument.

  
  import Ember from 'ember';

const { merge } = Ember;

const defaultTolerance = {
  top    : 0,
  left   : 0,
  bottom : 0,
  right  : 0
};

export default function isInViewport(boundingClientRect={}, height=0, width=0, tolerance=defaultTolerance) {
  const { top, left, bottom, right } = boundingClientRect;
  const tolerances = merge(defaultTolerance, tolerance);
  let {
    top    : topTolerance,
    left   : leftTolerance,
    bottom : bottomTolerance,
    right  : rightTolerance
  } = tolerances;

  return (
    (top + topTolerance)       >= 0 &&
    (left + leftTolerance)     >= 0 &&
    (bottom - bottomTolerance) <= height &&
    (right - rightTolerance)   <= width
  );
}

With the addition of the viewportTolerance option, addon users can relax how precise the check is. When set to 0, the Mixin only considers an element inside the viewport when it is completely visible inside of the viewport.

Setting up the Class variables

  
  const {
  get,
  set,
  setProperties,
  computed,
  run,
  on,
  $,
} = Ember;

const {
  scheduleOnce,
  debounce,
  bind,
  next
} = run;

const { not }     = computed;
const { forEach } = Ember.EnumerableUtils;

const listeners = [
  { context: window,   event: 'scroll.scrollable' },
  { context: window,   event: 'resize.resizable' },
  { context: document, event: 'touchmove.scrollable' }
];

let rAFIDS = {};

If you haven't had the chance to use ES2015 features, now's a good time to learn, since ember-cli-babel has been shipped with ember-cli by default for a while now. Here, we're destructuring certain methods from Ember, as well as setting up an array of listeners we want to register. I also declare a mutable variable rAFIDS with letâââI'll be using this object to store the ID that's returned by requestAnimationFrame so that we can cancel it later.

Something interesting to note is that these variables are actually shared by all instances of the Mixin. This means if we stored the ID in that variable, it would be overwritten by other instances of the Components that are being watched by the Mixin. So instead, we'll store each ID as a key (the element ID for the Component) inside of an object. More on that later.

Initial state

  
  _setInitialState: on('init', function() {
  setProperties(this, {
    $viewportCachedEl   : undefined,
    viewportUseRAF      : canUseRAF(),
    viewportEntered     : false,
    viewportSpy         : false,
    viewportRefreshRate : 100,
    viewportTolerance   : {
      top    : 0,
      left   : 0,
      bottom : 0,
      right  : 0
    },
  });
})

We'll need to setup some initial values for our Mixin's state. We do this when the Object the Mixin is mixed into is instantiated, by setting some properties on init. This is because Mixins extend a constructor's prototype, so certain properties will be shared amongst objects that implement the Mixinâââ and in our case, we want these to be unique to each instance.

Here, we're also going to make use of our utility function canUseRAF to let the Mixin know whether to use requestAnimationFrame or fallback to the Ember run loop.

Setting up the DOM element rendered by the component

When the DOM element is inserted, we'll need to do a few things:

The initial check on render to see if the element is immediately in view
Setting up an observer to unbind listeners if we're not spying on the element
Calling the recursive requestAnimationFrame method
Setting up event listeners if we are spying on the element

  
  _setupElement: on('didInsertElement', function() {
  if (!canUseDOM) { return; }

  const viewportUseRAF = get(this, 'viewportUseRAF');

  this._setInitialViewport(window);
  this._addObserverIfNotSpying();
  this._setViewportEntered(window);

  if (!viewportUseRAF) {
    forEach(listeners, (listener) => {
      const { context, event } = listener;
      this._bindListeners(context, event);
    });
  }
})

Checking if the DOM element is immediately in view

After the element has been rendered into the DOM, we want to immediately check if it's visible. This calls the _setViewportEntered method in the afterRender queue of the Ember run loop, which ensures that the DOM element is actually already inserted and available for us.

  
  _setInitialViewport(context=null) {
  Ember.assert('You must pass a valid context to _setInitialViewport', context);

  return scheduleOnce('afterRender', this, () => {
    this._setViewportEntered(context);
  });
}

Unbinding listeners after entering the viewport

It makes sense in certain use cases to stop watching the element after it has entered the viewport at least once. For example, in an image lazy loader, we only want to load the image once, after which it makes sense to clean up listeners to reduce the load on the app. We do that with the viewportSpy option.

Here, we programatically add an observer on the viewportEntered prop if viewportSpy has been set to false by our addon user. The observer itself doesn't do muchâââit unbinds listeners and then removes itself.

  
  _addObserverIfNotSpying() {
  const viewportSpy = get(this, 'viewportSpy');

  if (!viewportSpy) {
    this.addObserver('viewportEntered', this, this._viewportDidEnter);
  }
},

_viewportDidEnter() {
  const viewportEntered = get(this, 'viewportEntered');
  const viewportSpy     = get(this, 'viewportSpy');

  if (!viewportSpy && viewportEntered) {
    this._unbindListeners();
    this.removeObserver('viewportEntered', this, this._viewportDidEnter);
  }
}

Setting up event listeners

Let's look at binding our event listeners before we take a look at _setViewportEntered, the main method for the mixin. We'll be using the array of listeners we declared earlier at the top of the file, and binding the event to the appropriate context (window or document), like so:

  
  _bindListeners(context=null, event=null) {
  Ember.assert('You must pass a valid context to _bindListeners', context);
  Ember.assert('You must pass a valid event to _bindListeners', event);

  const elementId = get(this, 'elementId');

  Ember.warn('No elementId was found on this Object, `viewportSpy` will' +
    'not work as expected', elementId);

  $(context).on(`${event}#${elementId}`, () => {
    this._scrollHandler(context);
  });
}

Note that we can actually pass the Component's elementId (the id attribute that is rendered into the DOM) to the event, which will allow us to only unbind the listener for that particular element. If we didn't do this, all listeners would have been unbound when the first DOM element enters the viewport, which isn't what we'd want.

Handling the event

Now, we can handle the event by debouncing the main method with the viewportRefreshRate set by the addon user.

  
  _scrollHandler(context=null) {
  Ember.assert('You must pass a valid context to _scrollHandler', context);

  const viewportRefreshRate = get(this, 'viewportRefreshRate');

  debounce(this, function() {
    this._setViewportEntered(context);
  }, viewportRefreshRate);
}

Unbinding listeners

When we eventually destroy the Component, we want to make sure we also cleanup after ourselves. We'll have to remove both event listeners and the recursive requestAnimationFrame call:

  
  _unbindListeners() {
  const elementId      = get(this, 'elementId');
  const viewportUseRAF = get(this, 'viewportUseRAF');

  Ember.warn('No elementId was found on this Object, `viewportSpy` will' +
    'not work as expected', elementId);

  if (viewportUseRAF) {
    next(this, () => {
      window.cancelAnimationFrame(rAFIDS[elementId]);
      rAFIDS[elementId] = null;
    });
  }

  forEach(listeners, (listener) => {
    const { context, event } = listener;
    $(context).off(`${event}#${elementId}`);
  });
}

  
  _teardown: on('willDestroyElement', function() {
  this._unbindListeners();
})

If you recall, the requestAnimationFrame function returns an ID that uniquely identifies the entry in the callback list. We can pass this on to cancelAnimationFrame in order to cancel the infinitely recursive call to the main method. Because we register the Component's DOM elementId as a key in the rAFIDS object, we can remove the specific rAF call for that single Component. I've wrapped the cAF call in an Ember.run.next to avoid a race condition that happens occasionally.

Updating the viewportEntered property

Let's take a look at the main method responsible for setting the viewportEntered property. This method does two main things:

Set viewportEntered to true or false
Fire off the next requestAnimationFrame step

  
  _setViewportEntered(context=null) {
  Ember.assert('You must pass a valid context to _setViewportEntered', context);

  const $viewportCachedEl = get(this, '$viewportCachedEl');
  const viewportUseRAF    = get(this, 'viewportUseRAF');
  const elementId         = get(this, 'elementId');
  const tolerance         = get(this, 'viewportTolerance');
  const height            = $(context) ? $(context).height() : 0;
  const width             = $(context) ? $(context).width()  : 0;

  let boundingClientRect;

  if ($viewportCachedEl) {
    boundingClientRect = $viewportCachedEl[0].getBoundingClientRect();
  } else {
    boundingClientRect = set(this, '$viewportCachedEl', this.$())[0].getBoundingClientRect();
  }

  const viewportEntered = isInViewport(boundingClientRect, height, width, tolerance);

  set(this, 'viewportEntered', viewportEntered);

  if ($viewportCachedEl && viewportUseRAF) {
    rAFIDS[elementId] = window.requestAnimationFrame(
      bind(this, this._setViewportEntered, context)
    );
  }
}

As a simple optimization, we can cache the selected DOM element inside the Object as $viewportCachedEl so we don't have call the expensive DOM node selector method every time. Then, we pass the Component's element properties to the utility we defined earlier, and set the viewportEntered property.

If requestAnimationFrame is enabled, we call the method again inside of the rAF method, after binding it to the correct context. Like Function.prototype.bind, this creates a new function, that when called, has its this keyword set to the correct value (along with any arguments). With that first call after the element is inserted into the DOM, this fires off an infinitely recursive loop that will only end when we cancel it.

Hence, we don't have to setup event listeners when rAF is enabled. And that's it for the Mixin!

The Beginner's Fallacy

2015-04-10 00:00:00

Helping onboard beginners is a hot topic right now in software development. It is very good that this is important to people as we need new software developers. However, I have noticed that many of these developers are finding it difficult advancing beyond beginner. This is especially evident when they are taken out of their current development environment.

Beginners require guidance and a set of rules to follow. This has been shown time over time to be an effective strategy for learning. The rules/principles/laws, whatever you want to call them, are based upon the experience of more advanced developers that essentially boil down to "here is what you want to do most of the time". They are a great substitute for experience. They also fit in very nicely with the notion of Convention Over Configuration. But unless you are stepping outside of your framework the advantage of COC may turn into a career hindering disadvantage.

I am a big fan of Convention Over Configuration. I was first exposed to it with Ruby on Rails and I like that Ember.js has been following this path as well. However, I also believe that it can become a crutch for beginners. The rules that they are following coupled with the low friction environment of COC leads to a developer experience that does not present too many obstacles to be overcome. Learning requires challenge. You meet a challenge, you learn how to overcome that challenge, you move on and now that experience is a tool you can wield in the future.

The market being flooded with beginners along with COC frameworks should produce an environment that is heavily favored towards employers. (buyer's market) In most cases these developers will be able to accomplish most of what a very experienced developer can accomplish. This is great for the company's bottom line but not so good for the individual developer's own career growth.

Instead, if you are interested in advancing beyond being a beginner, you must get out of your comfort zone. This is going to require you to put more time into your craft than your job necessarily allows. Try new software languages, try old software languages. Go read SICP. Attend meetups, read papers, contribute to open source. Contribute to open source even if you think your PR won't be accepted. All of these things will take you out of the comfort zone that your daily work gives you, but you'll grow and become a better (and more in demand) developer for it.

The Importance of Being Experience First

2015-04-09 00:00:00

We're in the middle of a digital renaissance that has software eating the world. Like the industrial revolution, the digital revolution might see us eventually becoming obsolete, but that's okay because that's what progress looks like. To stay relevant, we need to place the Experience First.

The architects of the digital world

The modern architect has her roots in ancient and medieval history. They originated as artisans; master craftsmen such as stone masons and carpenters. In ancient times, there was no clear separation between the role of the architect and the engineer â they were seen as one and the same.

In some ways, the architects of the digital world are similar to those of the physical. There are many parallels between the two, although it's important to be aware of leaky abstractions, and that they are only similar, not exactly the same.

The craftsmens' renaissance

We're currently living in an age of digital renaissance. Software is eating the world, and some of us believe that we're right in the middle of a great technological revolution â the software revolution.

It's no longer enough to build a good product or service. The world demands excellence, because good is the new average.

I believe it's partly a symptom of how efficient manufacturing has become, that we're experiencing wide scale commoditization of goods and services that were historically considered luxuries. Because of this, we're also at the start of a new renaissance â one in which there is a resurgence of an appreciation for well designed experiences.

In my EmberConf talk, I defined design to mean more than aesthetics; design is how things work, and encompasses the entire experience across different mediums. Airbnb calls this being Experience First, as opposed to Design First, which suggests that anyone who isn't a designer has their contributions take a backseat.

"That experience is essentially a story, a narrative which ultimately enjoins us to a brand." â Om Malik, Gigaom

In other words, itâs obvious that we place value on things that fulfill both form and function. The popularity of beautiful user experiences, both online and offline, are the expression of a digital renaissance that is only going to continue growing.

The rise of website builders and what it means for us

Unlike classical portrait painters, bowling alley pinsetters and other jobs that have become redundant, the digital creator seems to be relatively safe.

With the rise of website builders like Wix, Squarespace, The Grid and portfolio/shop builders like Shopify, BigCommerce and Virb though, it's easier than ever for an individual or business to get a beautiful looking website created at a fraction of the cost.

The beauty of the web is that once an asset has been made, it effectively costs nothing to clone. A designer with a copy of Sketch or Photoshop can very quickly design a 'theme', have it converted into HTML/CSS by a "PSD to HTML" service (as they're commonly known), and then sell it on one of these site builders. You could very easily get a beautiful looking website setup and live on the web on Squarespace for less than $10 a month.

Why you need to place the Experience First

One thing I've learned from my time in Business School, is that humans suck at predicting things. Maybe we're all going to be made redundant, but the ones that design the best experiences will continue to be more relevant than ever.

If creating a website or app is commoditized, so be it. After all, who's going to design and build the website builder? The fact is, designing a beautiful experience across different mediums will never be automated, not until we have the technology to build incredibly intelligent Sentient AIs. But by then, we'd all be in trouble, so I wouldn't worry about it just yet.

Because it's easier than ever to build a website or app, the experience matters more than ever as the way to differentiate your product or service from the average. When you look to hire a developer or consultancy today, I think it's important that you seek out the ones that have honed the balance between design and engineering, and have spent time thinking about designing truly delightful online (and offline) experiences.

Lauren is a DockYarder

I've had a very diverse and varied experience with the web â I went to design school, did a finance degree, and started a company. Recently, I made the exhausting move from halfway across the world in Australia to join DockYard, because we truly care about the entire experience. I'm very proud to be able to call DY my new home.

This is my first post on Reefpoints â I hope you've enjoyed reading! If you'd like to read more of my writing, you can find more on my Medium.

Special mention to @nfFrenchie and everyone else who helped review this post.

Elixir: Come for the syntax, stay for everything else

2015-04-08 00:00:00

I have been programming for over 20 years now. I started with Basic, found my way to C++, and spent two years writing Assembly (MASM). Then I found Ruby. Ruby completely changed everything for me. I loved Ruby. I loved Ruby for a reason that many "elite" programmers tend to dismiss: the syntax.

You see, syntax is very important to me. Call it what you will, bikeshedding, OCD, stupidity. I care about syntax. It matters to me, and with Ruby I found a community that shared my thoughts.

When Go and Rust came along I was disappointed. Clearly these two languages were superior in performance (and in many other areas) but were a syntactic step back from Ruby. What was their reason? Clearly Ruby, and even Python, have proven that the masses are attracted by clear and readable syntax. New languages should take the best of what is currently available and improve upon them. Go seems to target the C/C++ audience, whereas Rust seems to attract JavaScript developers. So I guess this becomes a matter of perspective and opinion.

Elixir is different. I put Elixir up there with Go and Rust as part of the three new languages that will define the next decade of backend software development. With Elixir I found a language that embraced Ruby-like syntax, but also gave me much more.

The syntax is only skin deep, but this is part of allure of Elixir. It is my foot in the door. When I first saw Elixir code I thought to myself "OK, this is something I can wrap my head around".

I think a lot of Ruby developers will find their way to Elixir. It seems that many were attracted to Go but I suspect when they start to explore what the Elixir language has to offer they'll see the benefits.

But a language needs more than just a hook, there has to be a compelling reason to stay. For me that was Functional Programming.

It seems that Functional Programming is making a come back. Every day there is a new blog article on why you should start writing Functional code. Let's break this down into a few points:

1. Scalability

This is an Erlang trait. Elixir apps will attempt to make the best use of all the cores in your CPU as possible. Compared to Ruby this is a big deal. We don't have to write anything special, the Erlang VM (BEAM) just handles this for us automatically. This means we are efficiently using our hardware. This type of approach didn't make a lot of sense a few years ago, multi-core CPUs were expensive. Now they're cheap and Elixir benefits.

2. Memory

Elixir programs are meant to be broken into many different processes. The garbage collection strategy being used isn't revolutionary but because we are dealing with many runtimes instead of just one the impact on GC is negligible. In addition, you can picture how short-lived processes might be the equivalent of objects in an OOP lanuage. We pass messages into the process and get back a value. Each process manages its own memory, if the process is short-lived enough GC is never even run and the process is destroyed after it has completed its job. As opposed to Ruby where everything lives in one world and if you stop using the object it will get GC'd eventually impacting performance.

3. Immutability

Immutability got a bad rap when memory was expensive. Why would we write applications in such a way so as to waste memory by having variables whose values couldn't be mutated? Memory is now super cheap, and this is not much of a concern. With this in mind we can evaluate immutability within the context it was originally meant: to ensure state. When we talk about parallel processing the state of a process becomes very important. If we are expecting X to always be a specific value but we are writing in a language where X can change this can lead to problems.

4. Fault Tolerance

This one really impressed me when I started to dig into it. You may have heard that Erlang was invented for telephony. How often do you get a message from your phone company saying "we're updating our systems so you won't get a call for a while". This is the level of uptime that is achievable with Elixir. Hot code swapping is another very cool feature. Think real Zero Downtime Deploys.

5. Community

This one is more personal to me. I'm attracted to technology that is not centralized into one company. Go and Rust are very much just Google and Mozilla technologies. Those languages will always be at the whim of their corporate masters, wheras a language like Elixir that is not tied to any one company feels like it has a more democratic process behind its development. Let many companies develop use-cases and improve the language. (I realize that Erlang falls into this category, but Erlang is pretty much set in stone at this point)

The community around Elixir also feels very much like the Ruby community did early on. I said the same thing about the Ember.js community. I guess I'm just chasing that Ruby dragon, trying to catch that high again.

Conclusion

We've been exploring Elixir heavily over the past few months. The more I dig into the language the more I love it. We're going to bet pretty heavily on Elixir and if you are a Ruby developer looking for a change in pace I highly suggest you check it out. The best place to start is with Dave Thomas' Book.

Helping Our Engineers

2015-03-31 00:00:00

Writing Pseudo-Code as UX Developers

As a team, we are always trying to improve our process at DockYard to make things easier for one another. Iâm part of the UX development team, which takes care of the HTML and CSS/Sass for our projects. One thing we have found to be helpful to our Ember/back-end engineers is pseudo-coding where loops and conditionals should go in our templates. It only takes a basic understanding of flow control.

When we are in the development phase of a project, UX development usually tries to complete HTML first. That way UX dev and engineering can work in parallel without completion times depending on each other. What can we do to make this process smoother? Below are two code examples of what an engineer may see given these mockups.

Unorganized comments:

  
  {{! at the beginning the user will not have any followers so show this}}
<div class="follows-wrap">
  <h2 class="follows--is-empty">You donât have any followers.</h2>
</div>

{{! when a user has followers show this block and not the block above}}
<div class="follows-wrap">
  <div class="follows">
    <div class="follow">
      <img src="" class="follow__image">
      <h2 class="follow__name">Alfred H.</h2>
      <h3 class="follow__interests__heading">Follows for:</h3>
      {{! must be following for at least one interest to have a follower. when the follower is only following for one interest will not have the part that says 2 others or span below that}}
      <p class="follow__interest">Tennis &amp; Racquet Sports,
        <a href="#" class="follow__interest--other">2 others</a>
        <span class="follow__modal__interests">
          <span class="follow__modal__interest">Photography</span>
          <span class="follow__modal__interest">Soccer</span>
        </span>
      </p>
    </div>
  </div>
</div>

Pseudo-code comments:

  
  <div class="follows-wrap">
  {{! if user has followers}}
    <div class="follows">
      {{! each follower / following}}
        <div class="follow">
          <img src="" class="follow__image">
          <h2 class="follow__name">Alfred H.</h2>
          <h3 class="follow__interests__heading">Follows for:</h3>
          <p class="follow__interest">
            Tennis &amp; Racquet Sports
            {{! if following for more than one interest}}
              ,
              <a href="#" class="follow__interest--other">2 others</a>
              <span class="follow__modal__interests">
                <span class="follow__modal__interest">Photography</span>
                <span class="follow__modal__interest">Soccer</span>
              </span>
            {{!end if}}
          </p>
        </div>
      {{! end each}}
    </div>
  {{! else}}
    <h2 class="follows--is-empty">You donât have any followers.</h2>
  {{! end if}}
</div>

The unorganized way can get out of hand with complex applications. The pseudo-code method turns out to be slightly more work for UX developers, but it saves our engineers a lot of time and confusion. Being able to break things down into simple if/else statements or each loops has been much more efficient. No more reading paragraphs of whatâs supposed to go where and when, or re-organizing the template!

Pluralize Your Word(s) With ember-pluralize

2015-03-27 00:00:00

Do you ever find yourself repeating identical pieces of code throughout different projects? If so, that's the perfect indicator for an addon opportunity. Ember Addons allow you to quickly integrate sharable code into different projects, without copy and pasting, via one simple command:

  
    ember install:addon addon-name

On some of our most recent projects, we kept finding the need to pluralize words based on how many of each item we had. Also, since our data is dynamic and constantly changing, the pluralization of a word should remain in sync with our fluctuating data. And so ember-pluralize was born.

After a quick ember install:addon ember-pluralize, using the addon is a piece of cake.

Let's suppose we have a model like so:

  
  export default Ember.Route.extend({
  model: function() {
    return Ember.A([
      Ember.Object.create({ name: 'Cartman', cheesyPoofs: 20 }),
      Ember.Object.create({ name: 'Stan', cheesyPoofs: 5 }),
      Ember.Object.create({ name: 'Kyle', cheesyPoofs: 1 }),
      Ember.Object.create({ name: 'Kenny', cheesyPoofs: 0 })
    ]);
  }
});

Now we want to output how many Cheesy Poofs each person has. This addon provides a helper that allows us to do the following in our template:

  
  {{#each model as |person|}}
  {{person.name}} has {{h-pluralize person.cheesyPoofs "Cheesy Poof"}}
{{/each}}

which will output

  
  // Cartman has 20 Cheesy Poofs
// Stan has 5 Cheesy Poofs
// Kyle has 1 Cheesy Poof
// Kenny has 0 Cheesy Poofs

And now, as they each start throwing back some Cheesy Poofs, the counts will start to update, as well as the word "Cheesy Poof", according to how many are remaining. Alternatively, if you don't need to display the actual number, passing in omitCount=true as the third parameter will exclude it from the output:

  
  {{#each model as |person|}}
  {{person.name}}'s {{h-pluralize person.cheesyPoofs "Cheesy Poof" omitCount=true}}
{{/each}}

  
  // Cartman's Cheesy Poofs
// Stan's Cheesy Poofs
// Kyle's Cheesy Poof
// Kenny's Cheesy Poofs

Note: If you're using Ember Data, you will be provided with a built in pluralize helper through the Ember Inflector library. The helper is registered for availability in the template; the functionality is similar, but given that it takes up to two arguments (the count and the word), you're not able to solely display the pluralized word based on a given a count.

If you'd like to see more on the addon, it can be found on GitHub!

Bringing Ember to the Desktop with NW.js

2015-03-26 00:00:00

One of our recent client projects at DockYard had us go in a totally new direction in terms of technology stack. We needed to build a desktop application that could communicate with some Arduino devices via WebSockets.

Let me first put this out there: I love building for the web. The mere thought of developing native desktop applications always makes me cringe a little, though I admit, I haven't done much in that arena since those Java Swing days from forever ago. Nevertheless, you may find yourself at some point needing to build for the desktop. Thankfully, you don't have to put your fuzzy little Tomster away.

NW.js, formerly known as Node WebKit, is a runtime built on top of Chromium and Node/IO.js that lets you develop native applications using the web technologies that you love. You can essentially build an Ember app, and also invoke Node modules all within the browser, then package it up as a Mac OS X application or Windows exe file when you're ready to distribute.

Demo

Here's a screenshot from a NW.js app built with Ember for demonstration purposes:

It's a simple GitHub-flavored Markdown Editor that lets you create and preview Markdown documents, and save them to disk.

You can try it for yourself. Just download the application from the following links for your platform, unzip, then double-click on Markdown Editor.app (Mac) or Markdown Editor.exe (Windows).

For a touch of user friendliness, the app even ships with your favorite mascot:

Mac:

Windows:

Getting Started

The main entry point to a NW.js application is an HTML page that you specify in your project's package.json:

  
  {
  "name": "my-app",
  "main": "dist/index.html"
}

On startup, NW.js will launch a new Chromium browser window, then set the location to that starting page: file:///Users/brzpegasus/projects/my-app/dist/index.html#/.

This does require that you set your Ember.Router location type to hash. In Ember CLI, this is a simple tweak to your config/environment.js file:

  
  // config/environment.js
modules.exports = function(environment) {
  var ENV = {
    locationType: 'hash', // Change this from 'auto' to 'hash'
    // ...
  };
};

From there on, you should feel quite at home and ready to develop your Ember app.

Or maybe not quite yet.

A Bit About NW.js

NW.js tweaks Chromium and Node in order to integrate the two worlds and make it possible for you to call Node modules from the client:

  
  console.log(location.href);   // Yup, we're in browser land

var fs = require('fs');       // Call core Node modules
var async = require('async'); // Or even third-party modules!

If you're used to Node and CommonJS, this require function should look very familiar, but it isn't exactly the same. Here's what it does:

  
  function require(name) {
  if (name == 'nw.gui')
    return nwDispatcher.requireNwGui();
  return global.require(name);
}

So if you were to call require('nw.gui'), you would get access to the Native UI Library to do things like manipulating the window frame, adding menus, keyboard shortcuts, etc. Otherwise, the function ends up calling global.require to import Node modules.

global is Node's global namespace object. You can use it to retrieve other global objects besides require, such as global.process. However, many of them are made available directly on the window object, so you can reference them without prefix, just as you would in Node:

  
  console.log(window.process === global.process) // => true
console.log(process.env.USER) // "brzpegasus"
console.log(process.platform) // "darwin"

Naming Conflicts

Modules written with ES2015 (previously, ES6) syntax in your Ember app get transpiled into AMD for today's browsers. This is problematic because AMD also specifies a require function for loading modules. In Ember CLI, this is implemented via ember-cli/loader.js.

By the time the app is done loading, any functionality that depends on the native UI library or Node modules will break as the require function would have been redefined.

You can get around this by saving a reference to Node's require before loading any script. Once all scripts are loaded and executed, redefine require to work with both module systems. This is necessary as certain operations will not work with the alias:

  
  // Before loading any script
window.requireNode = require;

// After all scripts are loaded
var requireAMD = require;

window.require = function() {
  try {
    return requireAMD.apply(null, arguments);
  } catch (error) {
    return requireNode.apply(null, arguments);
  }
};

An Addon For All Your NW.js Needs

I've recently released an Ember CLI addon to help make this process easier. Simply install ember-cli-node-webkit, then start coding right away. All the configuration will be taken care of for you, so no need to worry about require naming conflicts.

The addon can build your project, watch for changes, and reload the page in NW.js during development. And when you're ready to distribute, packaging is just one command away. The packaging is a wrapper around the excellent node-webkit-builder but the configuration is done automatically based on the addon's understanding of your app structure.

I will not spend time talking about the addon in this blog post, but I invite you to check out the README to get familiar with all the options that are at your disposal.

Conclusion

When we first set out to build a desktop app for a client project, documentation on how to integrate NW.js with Ember was scarce. Even more scarce was documentation on how to integrate it with Ember CLI. I hope this post and this addon will provide some guidance to others down the road.

I'd love to share some code samples and discuss patterns you can adopt to make your NW.js app more manageable and testable, but they'd be too dense for this introductory blog post. However, you'll be hearing more from me on this topic in the future!

Testing when your frontend and backend are separated

2015-03-25 00:00:00

The last project I worked on was an Ember app that had a Rails backend that was deployed on Heroku. We had this application as a single repository, where there were two folders at the root, frontend and backend. This was somewhat easy to test on Travis-CI; it would check out the one repository, run the Rails tests, start the Rails server, then run the ember tests that hit the Rails server. This ended up being a pain to deploy, as when you changed the Rails app, you were going to redeploy the Ember app, and vice-versa. It also presented an issue when deploying to Heroku, as we had to utilize git subtree to push the backend, which contained the production assets.

With the latest project I started, I'm keeping the backend and the Ember app separate. Since the apps are separate, they can be deployed independant of each other. This made it a little bit harder to run integration tests against the backend.

Side note: while you can mock/stub your API in your Ember tests, it is important to run integration tests against your backend regularly. When you mock your API, it ends up giving you this false sense of security when it comes to your Ember app being compatible. Your models may line up perfectly with your mocks, but your mocks can fall out of date. To prevent this, at least when running on your continuous integration (CI) server, you should have your Ember app hit the backend server.

To run end-to-end integration tests on Travis-CI, I added tasks to the .travis.yml file to clone the backend repository, install dependencies, and run the server:

  
  language: node_js
node_js:
  - "0.12"

sudo: false
cache:
  directories:
    - node_modules
    - backend
    - vendor/bundle

before_install:
  - npm config set spin false
  - npm install -g npm@^2
  # Select the RVM version
  - rvm use 2.2.1 --install --binary --fuzzy
  # Clone the repository if isn't cloned
  - "[ -d backend/.git ] || git clone git@github.com:<backend-repo> backend"
  - "cd backend"
  # Reset the repo so we can have a conflict-less pull
  - "git reset --hard"
  - "git clean -f"
  - "git pull"
  # Install dependencies
  - "bundle install --path=../vendor/bundle --jobs=3 --retry=3 --deployment"
  # Run the server
  - "RAILS_ENV=test ./bin/rails s &"
  # Wait for the Rails app to start
  - "sleep 5"
  - "cd .."

install:
  - npm install -g bower
  - npm install
  - bower install

script:
  - npm test

Note that I cached both the backend and bundle directories to speed up the time it takes to get the backend running. Since the backend is cached, we only have to pull the new code.

In this example, we have a Rails app with no database, but it would be pretty easy to add one. The only other required step was to add an SSH private key to the Travis settings, since you would have two separate deploy keys. That would prevent you from cloning the backend repository from the frontend test. There should be nothing holding you back from performing end to end tests when you have separate repositories!

Rubyists Guide to Ember.js Dependencies

2015-03-24 00:00:00

At DockYard, we have a lot of Ruby on Rails experts who have adopted Ember on the frontend. One of the early hurdles a Ruby developer faces when working on an Ember.js application is dependency management. A popular mechanism for managing a Ruby applicationâs dependencies is the Gemfile provided by Bundler. Including a library is as easy as declaring it in the Gemfile and running bundle install:

  
  # Gemfile
source 'https://rubygems.org'
gem 'rails', '~> 4.2.0'

For better or worse, there is no dominant, single package manager in JavaScript. Ember applications, and more specifically, those running Ember-CLI, rely on two package managers: Bower for client-side libraries and npm for server-side libraries.

In this post, I'll provide a basic dependency management primer for those moving from Ruby to JavaScript.

npm

Ember-CLI uses npm to manage internal dependencies. npm resembles RubyGems, in so far as it allows you to install and manage third-party libraries, which in this case, are Node.js programs.

package.json

Libraries for npm are referred to as âpackages.â Each package has a package.json file which lists the dependencies of the library itself. In this regard, the package.json is analogous to a RubyGemâs gemspec file.

.npmrc

You can configure how node packages get installed via the .npmrc file. You may have one globally, per user (~/.npmrc), or per project.

Installing dependencies

To install an npm package, run npm install [package-name] from the command line.

This will either install the library and it's dependencies into your current working directory or in one of its parent directories. Here's how it works: if there is a node_modules/ or package.json in any directory above the current working directory, packages will be installed into that directory. Otherwise, calling npm install [package-name] creates a node_modules/ directory in your current working directory and installs the packages there.

This is a slightly different mental model for Rubyists who are not used to installing gems on a per project basis; gems are generally installed into version-specific Ruby directories with the more popular version managers like rbenv or RVM.

Itâs also possible to install packages globally using the --global flag when installing. This installs the package in your usr/local/lib/ directory by default. These packages typically contain executable files and are used via the command line (such as Ember-CLI).

Your dependencies will likely have dependencies. These get installed within a node_modules/ directory in the given package. It's a little strange the first time you navigate into a node_modules/package-name/ only to find another node_modules/ directory, but that's what that is. Youâll notice a node_modules/ directory for dependencies of global packages as well if you look in the usr/local/lib/ directory where global packages live.

One last thing to note regarding npm installations: npm caches the libraries you pull down to prevent you from having to download libraries that are already on your system. You'll find that cache: ~/.npm/.

Bower

While you'll use npm to manage your server-side Node.js dependencies, youâll use Bower for managing front-end assets, such as JavaScript, HTML, CSS, image, and font files.

.bowerrc

Bower itself is an npm package. Its libraries are referred to as âcomponentsâ and the end user can configure their installations via a .bowerrc file. This file specifies where dependent components will be installed, the URL where the component will be registered (its registry), and the JSON file used to define the component (bower.json by default) among other things.

bower.json

The bower.json file resembles the gemspec file you find in Ruby gems. It contains the library metadata, such as the name, version, dependencies, and development dependencies for the library.

As we mentioned, components can be searched for via registries. The registry matches the name of a component with the endpoint at which itâs hosted. Bower.io/search closely resembles rubygems.org in this way.

Installing dependencies

When you install a Bower component via bower install [component_name], the repository will be cached locally to expedite any future installations of the component. In case youâre curious, the bower cache location is: ~/.cache/bower/.

Unlike npm, Bower components are installed "flat" as opposed to in a hierarchical manner; all of your project's components (and their dependencies) will be installed into bower_components/ directory, by default. For example, if one of your components is dependent on the underscore.js library, both will sit side-by-side in the bower_components/ directory (remember, with npm, dependencies of dependencies are continually nested in their parent's directory within a node_modules/ directory).

Conclusion

Here's a quick wrap-up of the analogous files between Ruby and the JS package managers we discussed:

Description	Ruby	JS (npm, server-side)	JS (Bower, client-side)
Term for external library	"Gem"	"Package"	"Component"
End-user configuration file	`.gemrc`	`.npmrc`	`.bowerrc`
Per-library configuration file	`*.gemspec`	`package.json`	`bower.json`
Cache directory	`~/.gem/`	`~/.npm/`	`~/.cache/bower/`

As ES2015 (formerly known as "ES6") becomes more prevalent and JavaScript code becomes more modular and better for passing around, dependency management grows in importance. Hopefully this quick primer will clear up some confusion Rubysists have as they transition from working with the Gemfile to working with the package managers JavaScript offers.

Beginnerâs mentality

2015-03-23 00:00:00

Many people consider us UX or Web experts, and experts are clearly the best people for the job. But we know we have a significant blind spot - our extensive knowledge of the system makes us less likely to see the potential problems a novice might encounter. Anyone who is very familiar with a system, a discipline, or a product has put some distance between them and their beginning level challenges that cause them to develop an expert blind spot.

I am sure you are familiar with this situation: youâre invited (or invite yourself) to an event at a university campus. You arrive a bit earlier than you needed, so you can orient yourself in the unfamiliar space. The map on your phone is only accurate to the nearest block, so you get a campus map and try to find room 41-B in the Humanities building named after someone important. You feel stupid.

This is what campus maps often look like:

The reason most outsiders find campus maps confusing and difficult to use is the shift in the frame of reference.

For someone who lives or works on campus, the frame of reference is relative to the borders and shape of the universe that is the university (or corporate, or hospital) campus. They might consider their office to be âin the far North cornerâ relative to the outline of the campus on a map. Or, they might think of themselves as âright in the middle of the Art Departmentâ. The Art Department here is amorphous: itâs something that may either span two city blocks, or half of a floor in a physical building.

For an outsider, the frame of reference is still the surrounding landscape. They may not know precisely when they entered the school campus (there is no painted border on the ground) or that they are in its top left corner. The âyou are hereâ marker on the campus map helps, but it still takes a while to adjust to the landmarks differentiated by department, not by road or city block. To find a building, they are forced to adapt to a new system of coordinates.

Work with an outsider

I often see this situation reflected in the websites of large institutions. When someone very close to an institution thinks of how their web presence may be organized or used, they inevitably do so with the influence of all the expertise they have. They canât help it - they âliveâ inside the campus, and they are good at what they do.

There are many examples of this kind of insider thinking: organizing content by internal structure (instead of user need), breaking up a university website into Athletics, Academics, and Arts (which one contains the event I want to attend?) or assuming that a typical user has even a basic understanding of specialized terminology and concepts.

This is by no means a treaty against specialized knowledge and perspective. The insider knowledge of an industry expert makes a product good, their know-how makes it work. But the outside perspective of a novice-expert truly helps make a product findable and usable.

To attract new customers or visitors, a product needs to make sense to someone unfamiliar with it in their own broader frame of reference. To ask the right questions, to establish user goals and needs, and to judge the effectiveness and clarity of a product, we need both the insider and the outsider perspective.

Tips for writing Ember Addons

2015-03-22 00:00:00

After having published many Ember addons I have started to develop my own sense of "Best Practices" and I'd like to share those with you:

1. Keep it minimal, don't include stylesheets

I see quite a few addons out there that include their own look & feel by including sytlesheets. I actually think this is a bad idea. Keep in mind, every line of code you put into your addon will end up in the final footprint of the apps consuming it. This means if you are including stylesheets those will end up in vendor.css. The odds are that whatever styles you decide look good, someone else might not. They'll waste even more space by including their own overrides. This is wasteful.

Instead, you should keep it minimal. See ember-admin. I intentionally did not style the addon so it is left as minimal as possible. If you want to show off a styled version of the addon, you can either include styles in the dummy app's styles for the addon's test dummy. Allow people to run the addon's server locally and view what could be. Or, you can include an addon wrapper library that depends upon your addon. This wrapper can include default styles that consumers may choose not to alter. For example, ember-admin-bootstrap styles ember-admin with Twitter Bootstrap. If this is good enough for you then you just install this library and it pulls in ember-admin but gives you some nice styling that you don't have to spend time doing.

2. Allow for overrides

I believe strongly in composable addons. A consumer should have the ability to easily extend your addon to do whatever they want. This means organizing your code a certain way. To provide this you should put all of your business logic into addon/ and then include wrapper classes in app/ that just import then export the extended class. For example:

  
  // addon/components/foo-bar.js
import Ember from 'ember';
export default Ember.Component.extend({
  // business logic
});

// app/components/foo-bar.js
import FooBar from 'my-addon/components/foo-bar';
export default FooBar;

These light wrapper classes should not include any business logic. Again, they simply import then export the extended class. This gives consumers the option of overriding this in their own app/components/foo-bar.js file to extend and add customization.

3. Turn off Prototype Extensions

Currently ember-cli will not generate an addon project with Prototype Extensions turn off. However, I have requested this be the default. Turning off Prototype Extensions will cause the following syntax to fail in your addon's test suite:

  
  foo: function() {
  // whatever
}.property('bar')

There are several syntax shortcuts that Ember injects into the base Types. Arrays have quite a bit. Turning off Prototype Extensions will force you to write the above code as:

  
  foo: Ember.computed('bar', function() {
  // whatever
})

And this will play nice with consumer applications that must run with the Prototype Extensions turned off.

It should be noted that Ember 1.10 has a bug where turning off Prototype Extensions causes Ember itself to fail. This should be fixed in 1.11 (Update: This has been addressed in Ember.).

Avoiding Prototype Extensions can be difficult. I plan on writing a future blog post to outline certain strategies to duplicate the behavior that you miss out on without Prototype Extensions.

To turn off Prototype Extensions you'll need to install the ember-disable-prototype-extensions:

  
  npm install --save-dev ember-disable-prototype-extensions

See ember-validations for an example.

4. Test your addon

This one should go without saying but I have seen way too many addons out there that are untested (the generated tests don't count). Please keep in mind that there are people building products that might consume your work. Untested code is just one more thing that could go wrong in someone's app. If unit testing the code is too difficult, at the very least write integration tests against the dummy application to ensure the happy paths.

5. Depend on other addons

You may not know this but addons can depend upon addons. Rather than recreating behavior per-addon it would be best to extract out common behavior to its own dependency. For example, ember-data-route and ember-cli-async-button are both being used in ember-admin.

To use an addon as a dependency it must be put into the dependencies object in package.json, not devDependencies. You may need to add this keyword to your package.json as it is not part of the auto-generated file.

Ember's addon eco-system is getting better every day, and as a community we are learning as we grow how best to build and maintain addons. I'm hoping you find these tips helpful. Please feel free to share your own in the comments below.

The Lean Project

2015-03-19 00:00:00

I am a firm believer in Lean processes aimed to maximize value while minimizing waste. When it comes to running projects in a Lean way, this goes far beyond the role of the Project Manager (or Scrum-master) thus requiring the right recipe of team, process, communication, work environment and pride. Often I am asked what are the typical practices I apply to projects which fall in the mobile/desktop application development context- this is my attempt to answer the question. Important disclaimer - this is not a prescription for how to run a project, nor does it guarantee success. The secret sauce is always the people NOT the process.

The Raw Materials

If any of these seem unreasonable, you need to take a hard look at your team and work environment. Any concessions made here will reduce team effectiveness.

A team well-balanced in terms of seniority - Experience is contagious!
Dedicated team members - not split across multiple projects
Co-located team members
Smaller teams (no more than 5-7) â Once you breach this team size communication complexity increases exponentially.
Conduct retrospectives with full participation - Always seek to get better
A knowledge management strategy ensures team members know where to store/post directional artifacts that other team members require to do their job (e.g. Wireframes, PSDs, Test Cases, Context Diagrams )
Use of Information Radiators â Physical views into plans (e.g. Post-Its on a whiteboards) that may supplement a digital plan view

1) Breakdown the work

Decomposition of capabilities/features is a necessary and somewhat painful evil. However, you do not need to go to a painful level of detail to create this artifact. The importance is breadth not necessarily depth. The depth only needs to go as far as necessary for the team to directionally understand where a feature needs to go. If a team member is able to provide some form of time estimate (best and worst case) for one of those lower level items, you're low level enough. If estimates are coming out to less than 1 day you have likely gone too far. Get the full team involved, apply the 80/20 rule in terms of completeness and time-box the activity.

2) Define a Path

Once you have step 1 in place, work with the team to derive a chronological execution of the work driven by perceived value and/or risk/complexity of a given feature. Front loading your risk/complexity (as long as it is somewhat high value) is a very acceptable and smart approach because impact of course correction early on is much less invasive than the alternative. Ensure a basic architecture for the overall solution is derived and communicated. This ensures that the team has a solid foundation to build upon.

3) Respect the Pyramid of constraint

Scope, Time and Cost â Fundamental variables applicable to any project context. Visibility and active monitoring of these variables is essential to ensure project success. First and foremost, ensure that a baseline is established for each of these variables before a team even start the project. Understand how your stakeholders rate the relative importance of each of these variables and uphold the "Rule" that trade-offs are the only way these baselines can/will adjust. Deferring this activity to after a project gets going can result in scope creep and cost/time over runs.

4) Hold up the mirror

As a PM, itâs your responsibility to hold up a mirror in front of your team that shows the good, the bad, and the ugly. This allows the team to maintain appreciation for the big picture while they do their best to work through the small one. I am huge advocate of a plan view that I have written about in the past (High and Mid-Level Plans) â which shows time, features, tasks, distribution of work across team capability areas (Design, Backend, UXD, etc.), progress made, unplanned work and deferred work that will come in later releases. If you have this and revisit it often, consider your team informed and that those Triangle of Constraint variables are being monitored (for the most part.)

5) Create an environment of ownership and accountability

Everyone is a player. PMâs should be servant leaders, therefore any plan created needs to be the team's plan not the PMâs (or Sr. Mgmt.) This way the team has accountability and ownership rights over whatever happens to the plan. If something is not going as planned the team can understand the implications of this and course correct and work to reveal why something may not be working out. Constant readjustment and calibration is required to keep things moving along. The project manager helps ensure these conversations happen.

No team member can slip into the shadows. To be successful every contributor needs to have a voice. A PM needs to put their âFacilitationâ hats on and ensure they proactively encourage all to participate and chime in on team affairs. Thatâs the beauty of teams. They succeed together, not as individuals.

6) Demonstrate Progress

Demos encourage quality, because no one wants to demo something that works and looks subpar. Stakeholders can rest assured they did not buy snake oil and value is being delivered in some regular interval. Demonstrations affirm you're heading in the right direction. Last but not least, demos allow the team to celebrate success in short bursts - It feels great to get something done especially when the road ahead is a long one!

Give it a go and let me know if this works for your team.

The Doldrums of Consulting

2015-03-18 00:00:00

The Doldrums is a sailing term. It means when you're stuck on the water with no wind. Your only option is to wait for the wind to pick up so you can continue on your way.

DockYard is currently in the doldrums.

Maybe this isn't something that a consultancy should publicly admit, but we've seen client engagement significantly dry up for us in the past month and a half. Where we were selling and turning clients away a few months ago, we are struggling to close a single deal right now. This is the ebb and flow of consulting, it happens. Our only option is to wait for the wind to pick up so we can continue on our way.

I was speaking with a few other software (Ember) consultancies recently and they voiced similar stories. I am not certain why Ember has seen such a steep drop off in interest. One theory is that Ember is currently in the Trough of Sorrow

Does a framework follow similar trends to a startup? Perhaps. In any event, we're now trying to diversify our offerings. I announced last week that DockYard is now offering Staff Augmentation services. This has piqued some interest but we're seeing a lot of inquiries for starting a few months from now.

It is funny because I know in a month or two we'll be fine. We just have to survive the thin times, which is always stressful. How we weather this will speak a lot about DockYard as a company. It is said the only way to survive the Trough of Sorrow is going to be company culture. If this is true then I'm quite confident in us.

I also realize that we're towards the end of a financial quarter. Companies tend to reach out after the start of a quarter, but if I were them I wouldn't wait. If companies were to contact us now they would find us in a position that would be easy to negotiate with.

I'd be interested in hearing from other shops: have you experienced The Doldrums? What pulled you through? What strategies have you put in place to avoid them in the future?

Thriving in a New Work Environment

2015-03-16 00:00:00

My Background

If you asked me a month and a half ago when I was living and working near Philadelphia as a Director of digital communications, âCory what are the chances that you will be in Boston working for a new company?â. I would have said you were crazy and I couldnât see myself leaving the Philly area unless a company blew me away with their culture and work environment. How would I watch my Sixers, Eagles, and Phillies games if I left the Philly area?

Then in a week and a half frenzy I was moving up to Boston after it had just snowed another two feet in Boston. A day after that I had moved in to my new apartment and it was my first day at DockYard as a Junior UX Developer!

Fast forward a week and I had met 16 new DockYard co-workers (who, yes, are crazy smart) and was introduced to a new coding/project management environment. I was then challeneged to learn how to structure my SCSS with the BEM class naming conventions and rules for Scalable and Modular Architecture for CSS (SMACSS), all of this was a tidal wave of new information and personally a different way of thinking.

Itâs Not All About You

I would love to say that the sole reason that Iâve been able to handle all the new information is that I am purely that awesome. But in reality I could not have gotten through any of this without the work environment DockYard has implemented.

Estelle and Marin explain how âWicked Goodâ the DockYard team is and do so better than I can, but from my experience after a month of working here it is clear that everyone wants to help each other (new guy included). If you need help and youâre not approaching other team members with questions, you might find yourself out of place.

This type of atmosphere is exactly what you need for soaking in all the information you receive at a new job. You will always have questions and uncertainties in a new environment like:

Am I meeting their expectations
Am I messing this up
Will I look stupid if I ask this question
What will they think if...

It is inevitable to have these questions when you are in a new work place and you should have them, don't be afraid to solve those concerns by asking productive questions! The new company you just joined would rather be asked a stupid question then see you running in circles not willing to interact with the team.

I have asked many questions in my first month here and not once has someone:

Said no
Told me there was no point to my question
Looked down on me for not knowing something

That is a testament to DockYard but also should be how any team should be run, especially web development teams.

Success Is Ultimately Decided By You

Now itâs not all up to the team you are joining to make you successful, you have to be willing to do the following:

Put time into reading about things you did not understand
Research tools/techniques that you see yourself using in the future
Be open minded with new development techniques and a new project management process

If you are successful with goals/projects your boss gives you, then you are meeting your employers standards. In the web development line of work in order to thrive in an environment you should be going above what is expected of you.

When coworkers look at your work they should be impressed and surprised with:

The product you are presenting
How quick and thorough you are when learning new things
Contributions you make to current projects

When you are getting those type of reactions to the list above you are thriving in the new work environment.

"Thriving in a new work environment comes from working harder and more efficiently than expected"

Be willing to be one of the first people at the office and leave later than most, you want to soak in as much information as you can. When you are given new things to learn tackle them immediately.

During all the chaos of starting a new job stay organized and keep notes of things you are learning, you will probably not remember that Git command after one or two uses.

If you find yourself in a new work environment and feel overwhelmed just remember to ask as many questions as you can and work hard to understand the solutions your team provides you.

Ask good questions

2015-03-11 00:00:00

In an earlier post, I focused on the challenges of leading a good user interview. Today, Iâd like to focus on one rule about asking questions to get reliable results.

Ask open-ended questions.

Otherwise, the responses you get will be either biased or useless.

Let's look at some interview questions (from worst to best)

They appear in order: from least useful to most useful in getting you good responses. For context, imagine youâre doing some user research and you're in the middle of a project to design some widgets.

âYou like this widget in green, right? We picked green because itâs calming.â This question is so bad it's grotesque, but it may still happen to novice interviewers. Not only does the question suggest a specific answer (you like it!), but it also gives reasons why that answer might be the right one (green is calming!) The interviewee is not likely to share a genuine opinion with this much pressure to say âyes, I love it in green!â.
âHow do you feel about this widget? Do you like its color?â Slightly better, but still of limited use. By suggesting a response and allowing the user to narrow it down to a binary yes/no, weâre getting a very limited amount of information back. In addition, likes and dislikes move the conversation into a potentially awkward area. Some people may not be comfortable telling you they donât like something you made.
âHow do you feel about this widget? What do you think it does?â Now, this is better. We are opening up to qualitative responses with lots of detail. By not suggesting options for what an answer might be, we are more likely to get unexpected, valuable results.
âTalk me through what you see here.â A super open-ended question, useful in the beginning of an interview. Do they even see the widget?
âHow would you normally approach (widget-related task)?â This seems to be the best opening question for a user interview. While not appropriate for all circumstances, it is great at opening up areas you may not have considered to be in the scope of the project. This question can help reframe the problem you are working to solve.
âHow did you last (widget-related task)?â Past behavior is a more reliable indicator than a behavior people might describe as their normal. So, this re-phrasing can encourage more honest answers.

You may notice that it takes more time to ask open-ended questions. You may trigger your interviewee to share a lot of extra information, not just a concise answer to the question you asked. You may have to follow up with more questions to get to the âwhyâ behind a certain behavior. But with the increased effort comes a better result. The responses are real. They are not influenced by your opinion about the thing youâre asking, because youâve kept that opinion outside the questions. These responses present a more nuanced picture of your usersâ needs and environment.

I condensed this principle from conference talks, books and workshops I attended over the past few years. Two sources in particular:

Michelle Yaiser's talk on user research at UX Camp
Sound reporting : the NPR guide to audio journalism and production. This book is outside of the usual UX Design reading list, but it's useful for interviewing skills. It shows how much effort and consideration it takes a journalist to gather information in a neutral, ethical way.

It's almost always a better investment of your time to conduct a few in-depth, âdifficultâ and neutral interviews, than to rush many interviewees through surface-level questions. This is especially true at the beginning of a project, when more design options are open. Your effort to keep the process unbiased will yield quality results, and quality wins.

DockYard is now accepting staff augmentation Ember.js contracts

2015-03-09 00:00:00

Over the past three years DockYard has primarily taken on "greenfield" projects, where we are responsible for building applications from scratch through design, development, and launch. Starting today we're adding Ember.js Staff Augmentation to the services we provide to our clients.

If you are looking to add an Ember.js expert to help your team you should contact us. Our entire engineering team is extremely experienced in Ember.js application development, Ember.js best practices, and Ember.js Test Driven Development. We can help your team finish existing features, guide your team on how to properly build an Ember.js application, and help you hit your delivery deadline.

Visit our contact page and choose "Staff Augmentation" for the Budget

EmberConf 2015 Day 2

2015-03-04 00:00:00

Fault Tolerant UX by Dan Gebhardt

@dgeb

Users should be shielded from any application issues that are encountered

Transaction UX

Atomic: all or nothing
- Ex. if a user fills out a form your app should save all the data, not just some.
Consistent: move between different states
Isolated: allows concurrent changes
Durable: changes are persisted

Apps MUST NOT violate the rules of transactional UX or you are violating the users trust

Forgiving User Experience

Fault Tolerant UX --> Forgiving UX
Transitional experience: to persist data that has not yet be saved, but in the process of being edited
Undo/redo
Offline support
Asynchronous interface (non-blocking)
- user can make changes as quickly as possible (changes can be queued up and synced at your apps convenience)

Engineering Fault Tolerant UX

Ember provides simple elgant patterns for building a consistent UX
Similarly, ember data provides durable UX
Ember data requires customization (extra code) to provide atomic and isolated code

Orbit

Orbit application patterns

Client first development
Pluggable sources
Data synchronization
Editing contexts
Undo/redo

ember-orbit

Provides a store with synchronous and asynchronous methods

Aligning Ember with Web Standards by Matthew Beale

@mixonic

Standards

The JS standardization process is about to change: ES5, ES6, ES2015!
Standards Process
- 5 stages - strawman, proposal(polyfills), draft(experimental), candidate(compliant), finished(shipping)
- Polyfill: A polyfill is a piece of code (or plugin) that provides the technology that you expect the browser to provide natively.
2 major standards groups:
- WHATWG + W3C (html / dom related)
- TC39 + Ecma International (promises, classes, for loops, etc)
Aligning with standards is not a one time event. It is ongoing!

Why Standards?

The goal is productivity
Standards are portable, reflect best preactices, and endure
Participants win

ES5 -> ES2015

New API for maps
Promises
Proxies

Babel

Babel will turn your ES6+ code into ES5 friendly code
- Enables new syntax (fat arrow, let) , APIs (map, set), not everything

Aligning Ember's Object Model

is this feature: stable? a good pattern? implemented correctly? implemented performantly?

ES Classes

Three new tools: class, extend, super
More gotchas:
- setUnknownProperty
- Transpiler output
- New syntax
- Changes in way that super behaves
- Mixins

Remember: standards are a two-way street!

Ember Community Survey

Growing Ember One Tomster at a Time by Jamie White

@jgwhite

How did a tech community come to be so vibrant? How can we continue?

1. The Tomster

Representation of productivity and friendliness
Tomster wore different hats
- Custom tomsters
Good defaults
- Having a friendly mascot makes things easier.
- âAmbitionâ and âfriendlinessâ is hard to juxtapose
Composing concepts

2. Language

Tomster is a tool. Productivity and friendliness implicitly part of conversation
- Words stick; the right words enable conversations
- âhackâ is not a good vocabulary word - negative connotation

3. User Interface

Programming language and documentation with good user interface

4. Hackability

Parts have to be accesible - has to feel hackable.
- Tomster was not overly done.

5. Roles

Many specialisms in Ember Community: documenteer, student, mentor, critic, explorer, and many more!

Community building is a design and engineering challenge

Interaction Design with Ember 2.0 and Polymer by Bryan Langslet

@blangslet

The web browser is the largest app runtime in the world, and will continue to grow
Every device has to be connected to the web
Web frameworks and toolkits are getting closer to native performance everyday

"How can I - one person with a laptop - leverage my time as powerfully as I possibly can, every minute I work?"

Ember-Flow

A paradigm shift for web interaction design
The goal: to blur the lines between native and web applications

Web Components

Extends the browser itself
- Polymer components extend a base component
Encapsulation
Declarative
True reusability/portability

Ember vs. Polymer Use Cases:

Ember: developer productivity, conventions
Ember: community
Ember: World-class routing and state management
Polymer: constantly pushing the web forward

Web Animations API

Has the best of both CSS and javascript animations
Web animations run outside of the main thread and can be accelerated on the GPU

Treasure Hunt Demo Application

"Demonstrates an experimental integration between ember.js routing and Polymer's core-animated-pages component to create beautiful inter-state animated transitions"

Building Applications for Custom Environments with Ember CLI by Brittany Storoz

@brittanystoroz

Ember CLI

Everyones favorite command line tool
Build organized ember apps quickly
Fills huge void in toolset for JS devs

Ember CLI Addons

Extend ember-cli beyond core fucntionality
Follow standard npm conventions
Easy to create & install:

ember addon name-of-your-addon

ember install:addon name-of-your-addon

Firefox OS

Requirements that Ember CLI could not provide
1. Generate and validate a manifest file (same concept as package.json)
2. UI components that mimic OS interface
3. Publish to Firefox marketplace
Ember CLI Addon was born to fill those requirements.

1st Requirement: Generating The Manifest

Creating Blueprints
- rules for generating common code and file structures:

ember generate blueprint name-of-blueprint

2nd Requirement: FirefoxOS UI (Gaia)

Building components bower install gaia-components/gaia-stubs
2 responsibilities:
- including dependencies and creating the addon
- making both available to the consuming application

Components Review

Dependencies:
- bower install within addon
- bower install withing consuming logic
Component logic
- create component
- export components to consuming aplication
- define component template
Validation & Publishing
- creating commands for control over when these things happen
- includedCommands hook: returns object of commands which are found inside lb/commands
- ember help lists out information about available add-on commands. And lots more useful info.

Building Real-time Applications with Ember by Steve Kinney

@stevekinney

Integrating browser functionality and third party code into our applications. In this case, WebSockets.
What is a WebSocket Used for?
- Collaboration, analytics dashboards, prompting user to upgrade application
Can I actually use WebSockets?
- For the most part, yes (some earlier version of IE not supported)
Socket.io -> library for Node
Faye -> simple pub/sub messaging

Approach #1: Use Standalone Controller

Somewhat limited because it only works between controllers

Approach #2: Dependency Injection with Services

ember generate service websocket
Declare where you want to inject it inside the Initializer
Inside controller: websocket: Ember.inject.service()

Approach #3 Using Socket.io

Socket.io is both a server and client side library

What is your favorite thing about JavaScript?

Minitalks!

1. Measuring Performance with User Timing API by Bill Heaton

@pixelhandler

Measuring the differences in template rendering speeds between Ember.js v1.8.1 w/Handlebars v1.3 and Ember.js v1.10.0 w/HTMLBars
Check out his findings on blog!

2. `ember-islands` by Mitch Lloyd

@mitchlloyd

ember-islands
Render Ember components UJS-style to achieve "Islands of Richness". You can arbitrarily render Ember components in the body of the page and they will all be connected to the same Ember app.

3. Ember Testing with Chemistry Dog by Liz Bailey

@lizzerdrix

Migration from Rails to Ember
Ember does not provide as much documentation on testing
Would love to help make Ember more approachable to beginners

4. Running C++ in ember-cli with Emscripten by Michael Nutt

@mnutt

ember-cli-emscripten
Allows you to add C or C++ to your ember app, then require the exposed functions and classes.
Fibonacci sequence demo!

5. Ember Observer by Kate Gengler

@kategengler

Ember Observer
Gives addons a score out of 10
pulls hourly from npm and Github

6. CSS is Hard by Erik Bryn

@ebryn

ember-component-css
namespaces our component styles automatically!

Physical Design by Edward Faulkner

@ef4

Computers are so abstract. Possibilities are endless, only hindered by your imagination.
Constrained by physics
Googles material design spec
- does not break rules of physics
- animations and motion appeal to us because they fit into our idea of how it should physically work.
Liquid Fire live demo!
- npm install âsave-dev liquid-fire for Ember 1.11+
Ember Paper

Closing Keynote: Chris Eppstein

@chriseppstein

Announcing: Eyeglass

Distribute SASS extensions as NPM modules for LIBSASS
Will be able to integrate with a number of different build systems, including Ember CLI
Major performance improvements
The best parts of SASS and Compass, working with the best tools JS has to offer

A Selection of Chris' Inspirational Messages

"Don't be a Sasshole"
"People come to a community for the tech, but stay for the love!"
"Sass didn't lose when I started ignoring the haters"
"If you use a framework you love, you'll never work a day in your life"
"Secret to a vibrant community: be excellent to eachother"

EmberConf 2015 Day 1

2015-03-03 00:00:00

Opening Keynote: Tom Dale and Yehuda Katz

To kick off the conference Tomster joined Tom Dale and Yehuda Katz on stage!
@mixonic @ef4 @mmun were welcomed as new members to the Ember Core Team
Big thanks to Robert Jackson @rwjblue!!!! Get rwjblue a beer!

Ember 2014 in Review

Rapid Release worked great! 6 week release cycle to get new features into everyone's hands.

HTMLBars

  
  <a href={{url}}>

instead of

  
  <a {{bindAttr href="url"}}> 

Block parameters, faster and lower memory, validation for templates
Killed metamorphs!
Improvements to Ember Inspector including Ember Data and promises pane, render performance tab, multiple <iframe>s, and redesigned UI, to name a few.

Ember CLI

Single install command for Addons, test support, massive performance improvements, and API stubbing, and server proxy (the list goes on!).

Testing Ecosystem

handles asynchrony

Ember Data

Relationship syncing, async relationships - built with async loading in mind.
Adapter Ecosystem

That was last year, what's next?

Versioned Guides -- live today!
Next Version of Ember CLI (as of last night)
Engines
List View
Components (already in Canary)
Liquid Fire
Async and Routable Components
Ember Data: JSON API support out of the box
Pagination and Filtering
Shipping Ember Data 1.0
6/12 release date for Ember 2.0, Ember Inspector, Ember CLI, LiquidFire, etc.

Ember.js Performance by Stefan Penner

@stefanpenner

Important choices to make, how to make the right choices?
Time vs. Space
Things that are costly in space: closures, objects, non-optimized code, compiled code, excess shape allocations
In Ember.js, need to do less work, align with primitives

Mis-alignment #1

Problem: Ember does too much work.

Solution: do less

Actions up, bindings down, no two-way bindings, explicit data flow
RIP singleton controllers, explicit lifecycle

Mis-alignment #2

Problem: init and super are hard to learn and mis-aligned with ES2015

Solution: Embrace super

Explicit defaults in super
Don't set properties until super
When to call _super(): When overwriting a framework method before touching this

Mis-alignment #3

Problem: Ember.Object.reopen, buggy, complex internals, massive allocations & shapes

Solution: Limit reopen to before first instantiation

Meta is a good thing. Every class has a meta, every instance has a meta. Metas for instances are what kill us. Meta is "live" inheriting. If can limit reopen, can make all metas one shape.
meta.listeners is crazier
Solution: work with V8 to make things better

Designing for Ember Apps by Steve Trevathan

@strevat

Mental models: Understand where the user is coming from and what kinds of interactions they deal with
- "What I think the thing is"
- Influenced by experiences from the past
- Not always solid: can be updated and changed. (improvements)
2 types of mental models
- Macro: what I think it is from a distance.
- Micro: how I think each individual interaction works; the specific feature.
Build a framework of understanding
- Some apps are just too complicated
- Use explicitly if they apply
- Break mental models if it improves the experience

Design Patterns

#1 Gradual Engagement

Core value given for free. Eventually you may be asked to sign up.

#2 Skeleton UI

ex. Google maps: grid becomes fully rendered map.

#3 Carry Context

ex. rdio: music played on laptop is reflected on iPad (or other devices).

#4 Reuse Core Interactions

ex. Browsing Pinterest: provides click and follow tangent.
Micro becomes Macro; core interactions become a symbol of your app.
"When I go home and think of your app, I think of the experience, the micro features more than the macro ones."

#5 Offline Mode

ex. Google Docs: âtrying connectâ message and canât interact with document. Incredibly Frustrating.

Tools of the Trade

A free design pattern library for Ember apps. Sign up!!

Hijaking Hacker News with Ember.js by Godfrey Chan

@chancancode

Being a canadian is awesome

Hijacking Hacker News App

Browser extension that transforms old site design to new, more usable app
Runs in hacker news domain

Getting the Data

$.get("/news').then(): request html page, extract data, then manipulate
Hacker News HTML Scrapper: need adapter to help talk to Ember Data store; customize adapter and serializer.

Fixing the URLs

Hacker News urls are not ideal for building an Ember app.
HN urls (serialized App States) to Ember Router (Actual App States)
- trick Ember into seeing URLs that are different from what is in the address bar
Router location types: Ember.HistoryLocation vs. Ember.HashLocation
- Can use same mechanism to make a custom Ember.Location: App.HackerNewsLocation = Ember.Location.extend()

Preferences

Changing preferences in one place and can see changes reflected in other
- Use observer pattern

The Possibilities

What if your ideas do not line up with the framework's choices?
If the frameworks is doing it's job, than the possibilities should be endless!

The Art of Ember App Deployment by Luke Melia

@lukemelia

Need to adjust deployment techniques from "server app" days
When traffic starts routing to the new app, finger-printed assets can no longer be accessed
- Need to keep old and new finger printed assets for a few minutes after a deploy.

Versioning

Learn from native apps - phones run different versions of an app
Keep API working for older clients through API versioning

Deployment & serving strategy

HTML page should be managed and deployed as part of static asset deployment process
HTML page should be served by the API server
Preview before activating
A/B Testing
- Setting global flags based on A/B buckets
- Serving up wholly different HTML based on A/B bucket
Notify connected clients

The New `ember-cli-deploy`

Merged these three projects: ember-deploy, front-end-builds, ember-cli-deploy
Now, one project with 6 maintainers (and growing!)

Roadmap

Release 0.4.0 by the end of this week!
Reelease 0.5.0
- New pipeline hooks and plugins architecture
- Includes post-deploy hook
- Documentation for plugin developers
- ember-cli-front-end-builds becomes a plugin
- USAGE: ember deploy staging
Beyond 0.5.0: deployment to named buckets, support A/B tests, beta testing, etc.

Ambitious UX for Ambitious Apps by Lauren Tan

@poteto

Good Design is:

  
  * how it works
* reactive
* playful
* informative

Designing the product vs. designing the experience
You are not the same as your website users

Good Design is Reactive

Instant feeback
Flow of data and maintaining relationships between that data
Ember allows reactivity through the observer pattern

The Observer Pattern

Computed properties transform properties and keep relationships in sync
Computed Property Macros to keep things DRY.
- Ember ships with a bunch of these out of the box (map, mapBy, concat, etc)
Observers synchronously invoked when dependent properties change

Good design is playful

Has personality
Ex. Slack when you open app (fun messages)

Good Design is Informative

Visibility of System Status
- Jakob Nielson - 10 heuristics for User Interface Design
Ex. Flash messages
- ember-cli-flash

Good Design is Intuitive

Drag and drop (trello, Google Calendar, etc...)
Ember handles drag and drop events out of the box
- add draggable=true to any html element to make it draggable

Bring Sanity to Frontend Infastructure with Ember by Sam Selikoff

@samselikoff

How Ember Can Help Today:

Ember and Ember CLI helps infastructure by reducing boilerplate
Similar directory structure and architecture
Conventions: eliminate trivial differences that hold us back
Writing add-ons for shareable code. Allows us to build structure.
Use ember deploy to deploy apps. Auth and backend config work into separate deploy server.
Testing in Ember using ember test. QUnit provides helpers.
Identify redundancies and abstractions

How Ember Can Help Tomorrow:

Semantic versioning and CLI conventions
Flexibility
New standards and best practices
- generally, shared solutions/frameworks help identify and discover ways of improving applications
- Ember always keeps up to date with these best practices
âEmber is not just a framework, itâs a philosophyâ of how to create and improve software
- First, give real developers the tools to tinker
- Then, deliberately fold in shared solutions

In summary, innovate & share!

Dynamic Graphic Composition In Ember by Chris Henn

@chnn

Spliting a Statistical Graphic into Parts

Splitting a problem allows us to change one feature of the graphic at a time
Suggests the aspects of a plot that are possible to change
Encourages custom visualizations for every data situation
Demo: Scatterplot example
- Adds multiple regression lines (in example, based on # of cylinders of each car)
  1 2 3
  
  {{#each subset as |subset|}} // component {{/each}}
  - Each point in the graph is an svg circle

Grammer of Graphics by Hadley Wickham

(Book of guidlines to follow)

Data to Aesthetic Mappings
Scales: one per Asthetic mapping
- Each data to aesthetic mapping has some mapping function
- he has chosen to represent these as points in scatterplot example
Layers: geom, stat, optional data to aesthetic mapping
Coordinate System
Faceting

What does this look like using Ember?

Data to Aesthetics = outer layer component which takes in the data as params
Scales = computed properties (using computer property macros)
Layers = looks like top level component, but must pass the scales

Further Considerations

Interactivity
Animations and transitions
- performance (updating graphic many times per second)

Test-Driven Development By Example by Toran Billups

@toranb

Live coding!!

Red, green, refactor
- You get a lot of feedback from red (so it can be red, red, red, green, refactor)
Incorrect selector in template to make sure youâre doing it correctly (aka. test should fail)
Test should not be very layout dependent
- Should be more general and not break whenever you make template changes that do not change app functionality.
Test names should be descriptive
Testing computed properties is recommended because of how caching works with them. Failing test will let you know which properties should be observed in order to break the cache.
Design proof testing

Rubyist's Guide to Executing JavaScript

2015-02-24 00:00:00

JavaScript is introduced to developers as a programming language that runs client-side, in the browser. This is convenient as a jumping off point for aspiring programmers, who can simply open up Chromeâs Web Inspector and start alerting âHello, World!â, but itâs a concept that isnât easy to unpack. Soon enough, the developer will likely find herself in contact with JavaScript outside of the browser â Node.js being the most prominent example of this. At this point, the notion of JavaScript being a language for the browser is no longer helpful; it obfuscates what is happening when a developer executes a line of code.

This post is a high level primer on what is happening âunder the hoodâ with our code. It will lend some insight into what terminology like âtokenizing,â âinterpreting,â âcompiling,â and a host of other terms mean. You'll gain a better sense of what the concept of a virtual machine encapsulates. And hopefully you'll leave with a better understanding of what your script is doing before it hits your computer's processor.

I feel this article will be well-suited for Rubyists who find themselves increasingly working in the realm of JavaScript, as Iâll be comparing how code executes between the two languages.

Rather than explaining how a line of Ruby or JavaScript code gets processed and run, Iâd like to work our way backwards, beginning with machine code. When you write a line of Ruby, it doesnât simply go to the processor when you run the script. It goes through a number of translations before being turned into machine code that the processor can execute. Weâll look at how Ruby gets processed and then touch on how JavaScript differs.

Ruby

Machine code

Machine code is binary that is executed directly by your computerâs CPU. The bit patterns correspond directly to the architecture design of the processor.

Before a statement in a scripted language becomes machine code, it gets compiled into machine code by a compiler.

Virtual Machine

LLVM compiles code on most Unix-based machines. It generates the machine code for the processor during compilation, which is just the process of translating one language to another.

The virtual machine executes your code. It's written in C and is known as the YARV interpreter. It is at the heart of a scripting languages "implementation," as it executes the source code via whatever language the scripting language is built upon (C in the case of Ruby MRI).

YARV doesnât receive the Ruby statement as you typed it. It goes through an abstraction of your code known as an Abstract Syntax Tree (AST), which get compiled to YARV byte code and run.

This "tree" is made up of nodes assembled by something called the parser.

Parser

You can think of a node on the Abstract Syntax Tree as an atomic representation of a Ruby grammar rule. The reason that Ruby knows to print âHello, Worldâ when it sees print 'Hello, World' is because the parser knows that print is a method and the string 'Hello, World' is its argument. These syntax rules are located inside of a languageâs grammar rule file.

Again, the parser creates the Abstract Syntax Tree that the virtual machine compiles and interprets.

Tokenizer/Lexer

If youâre wondering how Ruby knows that print is a separate element in the language from 'Hello, World', then youâre understanding the function of the Lexer or Tokenizer. The Tokenizer scans your line of Ruby code, character-by-character and determines where the "words" of the language begin and end. The Tokenizer can tell the difference between a space separating words and a space separating a method name from its arguments.

And thatâs the 10,000 foot lifecycle of a Ruby statement, as it goes from Tokenization to becoming machine code. If youâre looking for the microscopic explanation, Iâd recommend Ruby Under a Microscope.

JavaScript

Client-side

Most browsers implement Just-In-Time (JIT) compiling. This means that the JavaScript code you write is compiled right before it gets executed by the virtual machine; though, in JavaScript, the interpreter is not referred to as a virtual machine, but as a JavaScript engine.

V8 is the engine that interprets and executes JavaScript in the Chrome browser, Nitro is the engine for Safari, SpiderMonkey for Firefox, and Chakra on Internet Explorer. The efficiency with which a browser interprets JavaScript accounts for a substantial portion of its performance these days, especially as JavaScript-heavy, Single Page Applications become increasingly important.

Server-side

Node.js is the predominant framework for running JavaScript server-side. It is built on top of Googleâs V8 engine, which is a little confusing if youâve just read that V8 interprets JavaScript in the browser. In general terms, the JavaScript interpreter is extracted from Chrome, compiled on the server, and utilized by Node.js, allowing you to execute JavaScript outside of the browser.

Conclusion

Upon researching how a line of Ruby or JavaScript gets executed, you'll quickly find that you can go down a rabbit hole. There are so many different implementations of Ruby, so many advancements in how code gets processed, and so much ambiguity in the terminology we use, that it can be quite challenging to form a mental model of what's going on under the hood. That being said, a little patience goes a long way, and if you're looking to dive into any one of the topics described above, I think you'll be surprised at how readable much of the technical documentation is out there.

Automating Reefpoints

2015-02-12 00:00:00

We have a healthy mix of developers and designers, plus a project manager and office manager. This results in a group of people with varying degress of command line expertise. To make it easier to write blog posts, I added instructions to create a blog post using only GitHub.

This made it super easy for anyone to create a new blog post, have people review it, but one piece was missing: making it easy for people to publish their article once it was reviewed. Well, I solved that problem today with Travis-CI and a little bit of bash script.

The first step required was to script the publishing of our blog. We already use middleman-gh-pages, which makes publishing as easy as rake publish. I created the following travis_deploy.sh script:

  
  #!/usr/bin/env bash

set -e

git config --global user.email "socko@dockyard.com"
git config --global user.name "sockothesock"

# This specifies the user who is associated to the GH_TOKEN
USER="sockothesock"

# sending output to /dev/null to prevent GH_TOKEN leak on error
git remote rm origin
git remote add origin https://${USER}:${GHTOKEN}@github.com/dockyard/reefpoints.git &> /dev/null

bundle exec rake publish

echo -e "Done\n"

middleman-gh-pages is smart in that it figures out your GitHub remote based on the origin, so what we did is update the origin to use a GitHUb OAuth token that allows writing to public repos. We store the OAuth token in the environment variable GHTOKEN, which we encrypt in our travis.yml:

  
  language: ruby
sudo: false
cache: bundler
rvm:
- 2.0.0
branches:
  only:
  - master
script: "./travis_deploy.sh &> /dev/null"
env:
  secure: eAyjmkDKLbXnGvC75KRNVLoAr6WE7ldT6JGOzOKOfQ9WxhEFgzAXoKZVO4mX4DfDfJbZbCyFmxKqALXGXjaBKwU2eQKeq1g4svBnxGPHmOKFMfVjkSCFag0bppE2JK9VXn70lVYFh8kJHavHgQ2pRYlSb78WfmUKbbB9PSH/rSE=
notifications:
  slack:
    secure: o2ksyDNq6Ea2oHUbUpgICYHAUdZ0QgHSQNqgn/gginNyPYAd2MtS2h7iXVrzSgeXDSNi6WpAvAeOcUnzpA6h6oBkl0YvUTaXJs50IepWfAE4UZPwX9ZFfV8YiwnOCU9ByUTU2L9qeq83W3LuDYY7j6xZJjP5KMLC78TqTKy5pd8=

I also added a Slack notification so that people can see when new blog posts get published. The last thing I did was go into the Travis-CI setting and turned off the option to build Pull Requests, as that would publish articles before they were merged. I accidentally leaked the OAuth Token in the Travis logs (that's why the script step is redirecting output to /dev/null).

In the end, it was really simple to automate the publication of our blog. It has the added bonus of publishing corrections to the blog when anyone's pull request is merged.

Manage the conversation

2015-02-11 00:00:00

One of my core UX design skills is finding information through user testing and interviews. What we gather will help us decide what to build, and how. This makes our ability to source qualitative information very important to the success of a product.

A user interview is, at its essence, a closely managed conversation. It is my responsibility, as the designer, to manage it. The level of control required of the UX designer in this situation is unfamiliar, and can be stressful in the beginning. I think the reason for this initial discomfort is that we have little context for this managed type of conversation in our everyday life. Weâre used to conversations in which both parties share control over the direction and tone. Owning the conversation completely can feel rough and undemocratic. It takes skill and experience to do it while making the other party feel at ease.

I want to share what I learned while conducting interviews and user tests at DockYard. I hope this will take some of the edge off the initial difficulty for others also learning this skill, and make it a more pleasant and productive time for all.

Lessons learned

1. Prepare well

There is a lot of prep work involved, before the conversations can even start. Taking the time to do these steps properly allows me to get the most out of the time I spend with the interviewee.

Schedule the interviews. You may need to find suitable users yourself. Or, the client may help by putting you in touch with some preselected users to interview. Try not to schedule interviews back-to-back in case one takes a bit longer than expected.
Arrange for the legal details. This could include notifying the interviewee of privacy arrangements, having them sign an NDA, or otherwise vetting the situation. Basically, you want to protect yourself, the person youâre interviewing, and the client by specifying how information is going to be used.
Draft a sequence of questions that cover your desired information.
Edit until questions sound polished and neutral (more on this to follow, in a separate post)
Prepare a notebook, pen and a laptop.
Print the questions so I can write notes in context and check off completed ones.
Prepare backups and extra copies of any materials Iâm planning to use.
Grab water and a snack! You donât want to take focus away from the interview by being too thirsty or hungry.
If needed, also grab a timer and a sound recorder (your needs may vary)
Triple-check the list of interviewees and their basic information. For example, phone interviews can happen over different time zones. Itâs nice to verify you're not calling the person who kindly offered up their time at 6am.

2. Establish context

Your interviewee should theoretically know who you are and what youâre talking about. After all, they agreed to the interview. However, it is always a good idea to confirm your assumptions. A brief introduction wonât hurt. For example, you could start with âHi ____, thank you for taking time to do this! My name is ____, and my company was hired by ____ to improve their product. How familiar are you with the product?â

3. Direct the conversation

For a UX designer starting out, it may seem rude to redirect the conversation. Especially so if your interviewee is describing, with passion and detail, a subject they are an expert in. But don't be afraid to redirect the conversation. You need to get to the specific questions you want answered (but of course be nice about it!). For example, to get back on track, you might say âGreat - this extra information is very helpful, but Iâd like to get back to the original reason you started using ____?â This acknowledges the value of their insight, then nudges them to answer your original question.

4. Go with the flow

At the start of the interview, there is a prepared, logical sequence of questions to ask. But in a conversation, one thing may lead naturally to another. If it makes sense to ask things out of order, itâs totally acceptable to do so. This is where a printed list of questions helps. Check them off as you go to make sure none remain unanswered.

5. Use teamwork

It is definitely easier to have a team of two handling the interview. This way, one person asks questions while the other focuses on capturing notes. Some notes may be of things like body language, expression, and movement - all important indicators of how a user may feel about the questions in addition to what they actually say. An experienced interviewer could probably handle both tasks with grace. As a beginner, it's almost impossible. Try to do both at once, and you'll either get awkward pauses as you write notes, or you'll fail to record some of the valuable details.

6. Donât be afraid to clarify

Some interviews happen over the phone. The challenge here is that we lose most of the added information of body language and facial expression. This could be remedied with extra questions. For example, if I think the interviewee is referring to their laptop to answer something, I would literally ask that: âIâm guessing youâre looking at the laptop screen for reference - is that correct?â It is also important to be attentive to the tone of voice so you can hear emotion, like hesitation.

Another possible challenge in phone interviews is sound quality. Users may be on a shaky cell phone connection, or calling us via Skype. This can make their (and potentially your own) voice difficult to understand. It is tempting to dismiss the poor quality of sound and just omit details you canât quite hear. Make sure to always ask the interviewee to repeat or speak louder if you do not understand whatâs being said.

In conclusion

Conducting interviews caused me to cringe quite a few times. Am I doing it right? What does the interviewee think of me? Do I sound professional? Looking back, I can see how I and my colleagues got over our fears, and made significant improvements with just a few rounds of practice.

Remember, both you and the interviewee are there because you want to improve some aspect of peopleâs lives through your work and their experience. Youâre on the same side, and you share this interest in the thing youâre discussing. Make the most of this interviewing situation, and you will see improved results each time.

Ember QUnit 0.2.x

2015-02-06 00:00:00

Ember QUnit 0.2.x has been released. It brings a whole bunch of bug fixes and some much needed cleanup, but there are a couple breaking changes also.

History of the changes

Ember QUnit started as a self contained library to make unit testing of Ember applications significantly easier. Ember QUnit proved that unit testing an Ember application could be very simple, and users of other testing frameworks wanted to join in the unit testing fun. Unfortunately, the early code was fairly coupled to QUnit (the testing framework being used) so reusing the Ember unit testing helpers separate from QUnit was not possible.

Ember QUnit 0.2.x is a complete organizational refactor to remove the Ember unit testing helpers (into the appropriately named ember-test-helpers) and keep the QUnit specific parts in Ember QUnit. The majority of this refactoring effort was done by Dan Gebhardt and sponsored by the good folks at SwitchFly (you can read their write-up of the work here). Out of this effort we have been able to create Ember Mocha which now has feature parity with Ember QUnit and is a truly first class Ember unit testing solution. Due to the usage of a general purpose underlying ember-test-helpers library, it should now be possible to create a nice wrapper around nearly any JS testing framework.

Notable Changes

setup and teardown Deprecation

setup and teardown are deprecated in favor of beforeEach / afterEach. This update was made to allow closer conformance to QUnit 2.x concepts.

  
  // Refactor from (under 0.1.x):
import { test, moduleForComponent } from 'ember-qunit';

moduleForComponent('awesome-sauce', 'AwesomeSauceComponent', {
  setup: function() { },

  teardown: function() { }
});

// To (under 0.2.x):
import { test, moduleForComponent } from 'ember-qunit';

moduleForComponent('awesome-sauce', 'AwesomeSauceComponent', {
  beforeEach: function() { },

  afterEach: function() { }
});

Global Assertion Deprecation

Usage of global assertions are deprecated and should be replaced with the Assert argument to your test callbacks. This update was made to allow closer conformance to QUnit 2.x concepts.

  
  // Refactor from (under 0.1.x):
import { test, moduleForComponent } from 'ember-qunit';

moduleForComponent('awesome-sauce');

test('implements awesomeness', function() {
  equal(....);
  ok(....);
});

// To (under 0.2.x):
import { test, moduleForComponent } from 'ember-qunit';

moduleForComponent('awesome-sauce');

test('implements awesomeness', function(assert) {
  assert.equal(....);
  assert.ok(....);
});

Arguments to setup / teardown / beforeEach / afterEach

In prior versions of Ember QUnit, the setup and teardown hooks were called with a single argument: the container. In Ember QUnit 0.2 this argument is no longer present.

Note: usage of setup and teardown are deprecated, you should use beforeEach and afterEach.

  
  // Refactor from (under 0.1.x):
import { test, moduleForComponent } from 'ember-qunit';

moduleForComponent('awesome-sauce', 'AwesomeSauceComponent', {
  setup: function(container) {
    /* do stuff */
  },

  teardown: function(container) {
    /* do stuff */
  }
});

// To (under 0.2.x):
import { test, moduleForComponent } from 'ember-qunit';

moduleForComponent('awesome-sauce', {
  beforeEach: function() {
    var container = this.container;

    /* do stuff */
  },

  afterEach: function() {
    var container = this.container;

    /* do stuff */
  }
});

Deprecated this.append in Component tests

In a component test you would previously call this.append() to append your component into the DOM. This was somewhat confusing, and took some explaining when teaching to newcomers, so it has been replaced with this.render() which fits much better in our Ember mindset.

  
  // Refactor from (under 0.1.x):
import { test, moduleForComponent } from 'ember-qunit';

moduleForComponent('awesome-sauce');

test('implements awesomeness', function() {
  var component = this.subject();

  this.append();

  equal(component.$().text(), 'WHOAA!! AWESOME!!!');
});

// To (under 0.2.x):
import { test, moduleForComponent } from 'ember-qunit';

moduleForComponent('awesome-sauce');

test('implements awesomeness', function(assert) {
  var component = this.subject();

  this.render();

  assert.equal(component.$().text(), 'WHOAA!! AWESOME!!!');
});

Ordering of afterEach / teardown Callback

In Ember QUnit 0.1.x, the teardown callback was called after all internal cleanup was finished (like clearing the container, removing any views from the DOM, etc). In Ember QUnit 0.2.x afterEach / teardown is called before the internal hooks.

Build Changes

There are a few build related changes with Ember QUnit 0.2.x:

Build output is removed from the main repo, and now is maintained at ember-qunit-builds.
The output file locations are no longer nested in dist/.
CJS and AMD output is no longer generated.

ember-cli-qunit Version

If you are using Ember CLI, you should update to ember-cli-qunit version 0.3.7.

Summary

Please file issues ember-qunit issues if you come across anything that isn't listed here.

Vim: Jump, Jump, Jump!

2015-02-04 00:00:00

Jump, Jump, Jump!

In the last Vim-related post, we discussed mark motion, and today, we're going to cover another type of navigation: jump motion.

The main benefit of jump motion is its speed; it allows us to quickly traverse through the current file open or previously visited files.

Let's briefly cover some of the most familiar ones.

File Jumps

File jumps will navigate you to a location within the current file, regardless if that location is seen or not seen within the window.

Ain't no Mountain high enough, ain't no valley low enough...

Will take you to the top of the file.

Will take you to the bottom of the file.

Sentences and Paragraphs

(

Move a sentence backwards, can take a prefix argument.
- 5( - Navigates you 5 sentences backwards.

)

e Move a sentence forward, can take a prefix argument. * 10) - Navigates you 10 sentences forwards.

{

Move a paragraph backward, can take a prefix argument.
- 5{ - Navigates you 5 paragraphs backwards.

}

Move a paragraph forward, can take a prefix argument.
- 5} - Navigates you 5 paragraphs forwards.

Search and Destroy

Allows you to search forwards for a desired pattern within the file.
- /fishsticks - Searches for all occurences of fishsticks ahead of your current cursor.

Allows you to search backwards for a desired pattern within the file.
- ?catdog - Searches for all occurences of catdog behind your current cursor.

Repeats the last / or ? search.

Repeats the last / or ? search in the opposite direction.

Window Jumps

Window jumps allow you to move within the current scope of the window or viewport.

High, Middle, and Low

Jumps your cursor to the highest line of the window.

Jumps your cursor to the middle line of the window.

Jumps your cursor to the lowest line of the window.

System Wide Jumps

System jumps are special; they have the ability to take us to any previously visited file, regardless if those files are or are not within the same directory.

This is where jump motion really shines!

Jump Around

Give these next commands a try:

CTRL-O

Jump to our previous position.

CTRL-I

Jump to our next postion.

By pressing these commands repeatedly, you'll see that you are traversing through your recently visited files.

Jump list

Our recent jumps are stored on our jump list. We can view all the jumps through Vim's command-line mode. There are three ways to open up the jump list.

:jumps

:jump

:ju

Opens up the jump list

Above is an example of a jump list. There are four columns: jump, line, col and file/text. The numbers underneath the jump column are used to prefix our jump command, CTRL-O and CTRL-I. We are also given the position of our cursor from the line and column columns. Lastly, the file/text column, gives us either the file path or, if the jump is located in our currently opened file, the line of text.

Using our example jump list, if we want to jump to the 4th jump, located within ~/dir2/file.md, we'd prefix our previous jump command with the number 4, i.e. 4CTRL-O.

Next if we want to get back to our previous position, the line This is another sentence! we can cycle back to it with a couple of CTRL-Is. Cool!

I find that jump motion complements mark motion really well. By setting multiple marks in the current file, and flying to different files with jumps, my workflow has greatly improved.

Hope you give jump motion a try!

Debugging a Broccoli Tree

2015-02-02 00:00:00

Broccoli is a great tool for building up assets gradually through a list of changing steps. Unfortunately, when things go wrong in one of your steps it is often very difficult to figure out what is happening at each stage.

Here is where broccoli-stew comes in, it is a Broccoli utility library that contains a number of super useful plugins with a posix flair to them. Tools like mv, rename, find, map, rm, log, and debug make it much easier to reason about your Broccoli build.

And thanks to the debug and log plugins it has become massively easier to log the contents of each tree, or get an extra copy to poke at manually.

Initial Brocfile.js

Lets assume you have the following Brocfile.js:

  
  // Brocfile.js
var Funnel = require('broccoli-funnel');
var ES2015 = require('broccoli-es6modules');
var log = require('broccoli-stew').log;

var app = new Funnel('app', {
  destDir: 'my-app-name',
});

var transpiledTree = new ES2015(app);

module.exports = transpiledTree;

The goal of the Brocfile.js listed above is:

Grab all files in app/ and its subdirectories
"move" those files to my-app-name/
transpile those files from ES2015.

So far this seems pretty easy, but what if your resulting output didn't contain the files you expected? How would you track that down?

Log Tree

You can log the files in a tree using broccoli-stew's log:

  
  // Brocfile.js
var Funnel = require('broccoli-funnel');
var ES2015 = require('broccoli-es6modules');
var log = require('broccoli-stew').log;

var app = new Funnel('app', {
  destDir: 'my-app-name'
});

var loggedApp = log(app, { output: 'tree', label: 'my-app-name tree' });

var transpiledTree = new ES2015(loggedApp);

module.exports = transpiledTree;

Using log like this will list out the files that are present just after the Funnel step. It might output something like the following:

  
  my-app-name tree
âââ my-app-name/
   âââ my-app-name/cat.js
   âââ my-app-name/dog.js

This is super helpful to see that the right files are selected, but what if you are seeing the right files but the contents were not right?

Debug Tree

Using broccoli-stew's debug you can have a duplicate copy of the tree generated into the root of the project so you can inspect it later (it will not get cleaned up at the end of the build like the temp folders do).

  
  // Brocfile.js
var Funnel = require('broccoli-funnel');
var ES2015 = require('broccoli-es6modules');
var debug = require('broccoli-stew').debug;

var app = new Funnel('app', {
  destDir: 'my-app-name'
});

var debugApp = debug(app, { name: 'my-app-name' });

var transpiledTree = new ES2015(debugApp);

module.exports = transpiledTree;

The debug plugin as used above will create a folder on disk at DEBUG-my-app-name in the root of your project with the full contents of the app tree when it was called. You can review this folder's contents at your leisure without worrying about the Broccoli server calling cleanup and deleting the directory.

Conclusion

Using broccoli-stew to debug a Broccoli pipeline is absolutely awesome, and makes getting a project using Broccoli much easier. Thanks to @stefanpenner and @chadhietala for pushing things forward!

If you'd like to checkout and play with the Brocfile.js above, you can do the normal git clone and npm install song and dance with https://github.com/rwjblue/debugging-broccoli.

Why I'm disappointed in React Native

2015-01-30 00:00:00

This week at React.js Conf 2015 React Native was introduced. You can see the two most important videos here:

The TLDR is that Facebook has developed a view layer for React that can be used within native mobile apps. Within this context React's templates can call native components (and views) as if you were referring to normal HTML elements. Furthermore a JavaScript layer has been introduced to the native layer that runs the React applications, this means that you can debug your React Native applications in Chrome Web Tools while it runs on an iOS device.

This is amazing technology and I don't think anyone was expecting this. As an Ember developer I'm jealous. After some reflection I realized I was also incredibly disappointed in Facebook for heading in this direction.

We are (supposed to be) all in this together

The web development Holy Grail right now is to compete directly with (perhaps someday replace) native mobile applications. With React Native the web has lost a huge partner in Facebook for helping make this a reality. What incentive does Facebook have for pushing forward mobile web now that they can just produce native applications with web technology? What incentive do the existing React developers (and the large number of developers that will move to React in the near future) have for building and proving out mobile web use-cases with React Native? None.

We are getting close

This year saw significant improvements in mobile web. We are so close. Check out this video from Google showing off the potential of mobile web:

No longer is mobile web a matter of if but a matter of when. However, with Facebook effectively taking themselves out of the conversation we've lost one of the best use-cases and the largest voices with one of the most popular JavaScript frameworks.

Mobile web is a point of friction currently, and that friction existing is good because it will drive people and companies to pursue solutions to the problem. React Native is a work-around for mobile web. Some will think of it as a "best of both worlds" and perhaps they are correct. But the problem of mobile web will continue to exist.

Business needs trump ideological ones

Of course Facebook should do what is in its own best interest. In 2012 Mark Zuckerberg said that Facebook bet too heavily on HTML5. He was correct then and he is correct now: mobile web feels like shit when compared to native. The User Experience is the primary concern for any product company. This, however, should not stop us from persuing mobile web and pushing the technology forward. I just hope that React Native doesn't impede that progress in any way.

Empowering through Design

2015-01-30 00:00:00

There has been some debate in the development community between the "tradeoffs in server side and client side rendering." As a UX designer working at an Ember shop that focuses on rich client experiences, I've observed the benefits of single page web applications, from a design perspective.

The best kind of user interface is one where the system remains transparent, and moves the user fluently through relevant prompts to accomplish the task at hand. That experience can only be as good as the tools we have to shape and elevate that participation. At DockYard, we design and develop single page web apps using Ember as our client-side framework, because it allows for greater clarity of interaction, while keeping the technology transparent.

A single page web app is a webpage that can update contents within the page without refreshing the entire browser window. Because the server doesn't dictate the display, the "client," or browser, determines how to represent it. Only the data associated with the selection is changed to reflect the action.

You can imagine how beneficial that real time feedback is on the user side of the experience. Whether aware of it or not, this creates a more immersive experience, and enables the user to better grasp the information by directing attention to content. There is more opportunity to nest information which alleviates information overload, and animation simplifies complexity while still engaging the user.

To do this well, good information architecture and content organization are imperative. Functionality and interaction must be part of the architecture, but not interrupt the flow and navigation. The visual design and communication must be clear and directive. The design supports self directed navigation and the process is not disrupted by the reload of a page. Creating this kind of real time response in the browser is the result of better, faster performance, bringing us closer to a native feel from the web.

Learnivore is a website that connects teachers and students searching for instruction across many disciplines. The search page is one of the largest hubs in the Learnivore experience. This "complex search" filters by type of instruction, location, rate, price, qualifications, and more. The results change dynamically, reflecting the filter selection, as demonstrated in the video above.

Good design empowers the user to make the choices they need to accomplish their goals. It promotes communication and supports informed decision making through real time response. The single page web app model and the technologies to create and innovate with it are at the forefront of mobile and web design and development. It is a technology that not only provides opportunities for creativity and innovation for designers and developers alike, it constructs a more informative and cooperative experience for our users.

Bubbling actions through components

2015-01-28 00:00:00

If you're building components for re-use, you're likely to run into the following problem. Say you built a form component, and you also built some type of custom button component. You want the action triggered by the button to be handled in your controller or route. If you try to bind the action of that inner button, it will be captured by the component, not the controller. The issue is that components swallow actions that are triggered within them; they will not escape the component unless we punch a hole for them to bubble up.

You need to capture the action of the inner components and fire off new actions from the parent component. In the example below, the button is in a component that is inside of another component. The controller has an action to increment the counter.

Ember Starter Kit

Our components' templates are super simple:

  
  {{! index.hbs}}
  {{pressCount}} Button presses
  {{button-wrapper action="buttonClick"}}

{{! components/button-wrapper.hbs}}
  <h2>Button Wrapper</h2>
  {{press-button action="buttonClick"}}

{{! components/press-button.hbs}}
  <button {{action "buttonClick"}}>My Button</button>

Notice we bind to the action of the press-button component in our button-wrapper component, and in our index template, we bind to the action of the button-wrapper. This alone doesn't work; we need to send actions from each component when they receive actions from the underlying component.

In our press-button component, we send an action when the button is clicked:

  
  App.PressButtonComponent = Ember.Component.extend({
  classNames: 'press-button',
  actions: {
    buttonClick: function() {
      this.sendAction();
    }
  }
});

Our button-wrapper receives the action from the press-button component and fires its own action:

  
  App.ButtonWrapperComponent = Ember.Component.extend({
  classNames: 'button-wrapper',
  actions: {
    buttonClick: function() {
      this.sendAction();
    }
  }
});

And our index controller receives that action from button-wrapper and increments the pressCount:

  
  App.IndexController = Ember.Controller.extend({
  pressCount: 0,

  actions: {
    buttonClick: function() {
      this.incrementProperty('pressCount');
    }
  }
});

Wrapping up

It's pretty easy, yet tedious to wire up an action from a component within a component. You can trigger actions multiple levels above your initial action, and even mutate the action's arguments on the way up. Maybe the model that triggered the initial action should be put into some type of intermediate state. Maybe you want to normalize several different actions that are bubbling up through certain components. Since you need to manually bubble these actions up, we can manipulate them at each level that the bubbling occurs. It's somewhat trivial to handle, you just have to be aware of the work needed to tie all your pieces together.

Estimation Buyers Guide

2015-01-28 00:00:00

As a Project Manager, I have seen estimates in all forms - points, days, months, hours, mario coins, etc. Many say estimates in Software development are garbage and significant margin of error should be the expected norm. I believe this perspective to be true if estimation is conducted in a vacuum vs. as a means to have a conversation with prospective clients about what it is going to take to achieve their vision.

While estimation provides financial insight into a project, it also provides the project team with a point of reference when it comes to establishing schedules and conducting impact analysis when something needs to change (which is inevitable). As a project manager, a solid process by which we establish an estimate allows me to best serve the client and team.

I would question any firm who claims to offer a high confidence estimate to a prospective client without spending time mapping out the direction an application/product may take on paper. I am not talking about writing a 50 page requirements document (which I once did on a project 10 years before I knew any better). I am talking about getting the âsupporting" cast the context they need to provide an informed perspective on the complexity associated with building the application. This complexity spans design, engineering, quality and any other overhead associated with a project.

Let me paint this picture for you. Client X wants to build out a new application. The team to build said application provides client X with an estimate based off of a couple pre-sales meetings. Cost is negotiated until everyone around the table is happy with the economics and then the project is handed over to the project team and they are told to build âthisâ application in âthisâ amount of time. Client X is doomed regardless of whether or not that application is handed over in the agreed amount of time. Hereâs why:

The team has no context - Therefore, they are going to spend the first weeks of development getting up to speed as opposed to delivering working features putting the schedule behind right out of the gate
The team does not "own" the estimate - Someone else provided it on their behalf (who wants to be responsible for something they donât own?)
Unexpected risks and complexity will (not âmayâ) put schedule at risk
Quality will (not âmay") suffer because the team will attempt to meet the date commitment at the expense of quality

To avoid this at DockYard, we use a tool called Discovery. This is an intensive time-boxed exploration of a clientâs business objectives, market and user needs, as well as technological possibilities. These inputs translate into wireframes and those wireframes translate into an estimable breakdown of deliverables that provides a platform to discuss scope, schedule and cost with our client. Our Discovery phase is cross-functional where we have designers and developers working hand in hand to understand the direction a client wants to go. We iterate on design concepts, we discuss technical direction and potential complexities, we map out scope in a way that allows clients to make decisions which may adjust cost and schedule up or down. While this Discovery phase might feel like a tough nut to crack, it typically results in lower overall project cost, higher quality and better probability of staying on budget/schedule.

A recent post by our own Mike Dupuis speaks to the value engineers can add to the âDiscoveryâ phase of a project resulting in savings later in the project lifecycle- Features as Business Objectives

Whether you love them or hate them, estimates are here to stay in a client services context. Therefore, instead of grumbling about them - make sure you're using estimation as more than just a number but a means to have a conversation. Buyer beware of anyone who slaps an estimate on the table without providing you an explanation of how that estimate was derived.

âLuck is what happens when preparation meets opportunityâ - Well said by someone much more insightful than I!

Is your homepage as good as your door sign?

2015-01-20 00:00:00

Today is a federal holiday, and a day off for us at DockYard. On days like these, when I do not travel, I often go to the local library.

Today gave me the perfect opportunity to see how easy it would be to find a specific bit of information (is the library open today?) on a library website.

Like many government and community organizations, libraries are easy targets for ridicule when it comes to web design. Look at the outdated styles their site uses! How crowded it is! The HTML tables used for layout! The multi-colored announcements âdesignedâ in Word!Â

What I am looking for today is something else: I want to judge the achievability of a specific task regardless of the presentation. Presentation (layout, hierarchy, and just plain good design) affects a userâs ability to achieve her goals, no doubt. I just want to start with the goals, and a specific measurement, rather than starting with the common pitfall of visual designers like myself: noticing the surface details that seem broken rather than the process behind them.

So, hereâs my experiment:

Find out if the library is open today.

With a few considerations.

It may be self evident that a library is closed on a government holiday. It was not to me. I assume that most casual users have a vague suspicion that it may be closed, and would seek confirmation via the website.

I narrowed my search to just the homepage for this exercise, expecting to find the equivalent of a physical âSorry, closed today!â door sign. And while many libraries provided the same information on Twitter or Facebook, it would be prohibitive to compare all these resources for this quick study.

I saw most of these homepages for the first time today. A regular user of the local library may notice things differently than a new user, so for example the âCLOSEDâ text announcement that replaces a daily schedule of events, might stand out more for them.

I looked for three things:

was the holiday at all on the homepage, Â
was it clear, andÂ
was it obvious?

I got about halfway down the alphabetized list of Minuteman Library Network locations, and consider this to be a useful and fair sample for my purpose.

Letâs roll:

1. Acton

3/3!

The site is visually appealing and clear at the same time. I immediately got an answer to my question. Success!

2. Arlington (Robbins Library)

0/3

Hours are clearly listed, but the holiday is not. Based on this page, I would assume it is open todayâââin fact, the clear listing of hours reinforces my wrong assumption. To see the holiday announcement, I would need to know to visit the Calendar. A shame, because the site looks quite polished to me and was likely re-designed fairly recently (guessing 2013, from its footer). An investment in a bit of user testing and research would have likely fixed this.

3. Ashland

Huh? 0.5/3

While there is no indication of library closure today, the Townhall is clearly closed. As a local, I might know what that means for my library trip, so I gave 0.5 points for at least mentioning the holiday exists.

4. Bedford

0/3

Todayâs closure is not mentioned anywhere. Neither are the regular hours. I would look either in About Us, or (eventually) see a link for Hours & Directions close to the top right.

5. Belmont

3/3!

The site doesnât look like much, but it accomplishes my goal today perfectly. The library is clearly closed.

6. Brookline

3/3

This library goes beyond my expectations by clearly listing not only todayâs closure, but the entire holiday weekend for all three of its locations. The âClosedâ notice is clear and immediately jumps to my attention. While there is no âclosed TODAYâ notice, I found this more detailed listing works just as well.

7. Cambridge

0/3

This library was a particular disappointment, because I have used it many times and the collection and its building are delightful. I am assuming it is one of the better funded libraries, given its location in direct proximity to Harvard. While the amount of content this page needs to show may be far greater than what a smaller local library deals with, this is no excuse for making things difficult to find. I get the feeling that the structure of the site is based on internal objectives, rather than user goals.Â

Hereâs where todayâs closure information is, in fact, located:

I would have to do this: - âfind library hoursâ on the homepage - select âholidaysâ among eleven listings - see on the list that today, January 19th, is a holiday

8. Concord

0/3

No indication of whether it is open today. The latest news seems to be the New Yearâs.

9. Dedham

3/3

It is immediately clear that the library is closed today.

10. Dover

2/3

There is a clear indication that the library is closed today. I had to scan the page for a while and read a few things before I noticed it, so it was not obvious.

11. Framingham

2.5/3

It was almost obvious that âall libraries will be closedâ todayâââeven on this crowded page. I was distracted by the email sign-up notice, but the next thing I read was the closure notice. Not pretty, but close to functional.

12. Franklin

0/3

The public library website seems to be just a layer of content on top of the Franklin local government site. Very confusing. No indication of closure.

13. Holliston

2.5/3

I found the closure information quickly, but it did not stand out enough (for my taste) from other news.

14. Lexington

3.5/3

The first indication of the library closure for MLK is in the featured image. It eventually changes to another feature, but there is a second indicator (Todayâs hours: CLOSED) that makes the situation obvious. This fall-back âclosedâ notice got this site an extraÂ .5 points on my scale.

What did I miss?

Of course, this is a very small test for a very specific user need. The sites that did well on my scale for âclosing hoursâ may fail miserably at providing an answer to âwhatâs the street address?â or âcan I renew my book online?â.

This test reiterated for me the importance of research and real-life user testing. Knowing what problems people might try to solve by going to a website, and where the site fails them, is necessary for most any meaningful improvement.Â

How not to miss things:

As a designer, I am often excited by a problem I see, and can jump to a solution I consider to be self-evident. (The page is too crowded. Letâs change the typeface and layout!) But to make my solutions truly useful to other people, I must know what they need.

In this example, I am a user with a specific need. Designers do not often start working on a project with solid knowledge of user needs. To bridge this gap, we test the current product (if it exists), create personas and scenarios, and ask lots of questions.

Research could have prevented the âis the library closed?â problem. If there was one question I could ask people, it would be âWhat was the most frustrating thing about this library?â Out of many responses, I would imagine at least one would mention showing up at the library to find it closed. Asking these types of general questions, not âhow satisfied are you with the library website? (on a scale from one to ten)â, will eventually lead us to meaningful design.

Or, at least, save us the frustration of showing up to a closed library.

Joining DockYard

2015-01-16 00:00:00

Six months ago today, I signed the letter officially accepting the offer to join DockYard as a Senior Developer. It was the best decision I could have made.

When I announced my resignation to my previous employer, he jokingly said that if they had known choosing Ember as a new client-side framework would eventually make me want to pursue a new Ember-focused opportunity, they would have chosen Angular.

I first started dipping my toes into Ember in late Spring 2013, some time after Ember 1.0 RC3 was released. The Ember.js community was undeniably very active and vibrant. That following June, I attended my first Boston Ember meetup, where Dan Gebhardt shared tips on testing Ember apps, and Alex Navasardyan gave an introduction to Ember Data. That's how I came to know of DockYard.

Soon, some names started to emerge as familiar names within the community. Brian Cardarella became known within our dev team as the one who wrote ember-validations, which we were using in our application. Robert Jackson was another name that kept popping up on my Twitter and GitHub feeds. Call me a nerd if you will, but I was as excited to have The Robert Jackson accept a fix that I submitted to ember-dev later that year to make builds pass on Windows (with Rake at the time) as I would have been meeting a film celebrity.

DockYard further reinforced its reputation by organizing the Wicked Good Ember conference in Boston, in June of 2014, which I of course attended.

Needless to say, when Brian reached out to me last July about joining the team, I saw it as an opportunity that was really hard to pass on. Logistically, I may have been better off staying where I was. I had a 40 min commute. Joining DockYard would have doubled my commuting time. I was also comfortable with the position I was holding, building out cool D3.js charts with Ember, leading the development of new products, and getting myself involved in all kinds of engineering team growth efforts. But then there was DockYard. I went with my gut feeling instead and left the warm and comfortable seat to face the exciting, though new and scary thing that was DockYard.

Scary? Yes. From everything DockYard had done for the Boston community to the talent behind its wheel, I was absolutely terrified of not fitting in, that it was too elite for me. I checked out the team page on the website and read everyone's biography a number of times, trying to picture what kind of co-workers I would be interacting with daily. No matter how great the projects can be, culture is a big thing. To my delight, the culture at DockYard is one that resonates the most with me in my 10 years of professional career.

DockYard has a well-balanced team of young, bright minds and more seasoned developers, and I embrace that. There is none of that "I am better than you" bullshit. Those I once viewed as Ember Gods and would have been intimidated to talk to have been incredibly supportive and encouraging. In the past, whenever I was involved in the hiring process for Engineering, I had always wondered where all the great developers were. Well, they're here, happily employed at places like DockYard. If there is one thing I can say about the company, it's that it's doing something right to attract an amazingly talented and diverse crew. I've been particularly impressed with our designers. It's nice as a developer to work on such nifty UIs!

Doing consultancy work was new to me, and I had been warned about what I was throwing myself into, that I'd end up losing focus on quality and just hack solutions together quickly to meet client deadlines. I don't doubt that those kinds of situations can creep up, but so far, I've found quite the opposite in the two projects that I've been involved in. People care deeply about delivering clean, maintainable, and well-tested code, and they've been especially adept at maintaining those principles throughout the life of a project.

It's also refreshing to be able to work on a diverse portfolio of projects. In the first few months since joining DockYard, I worked on a Rails and Ember app that incorporated some really cool geolocation functionality. I am now working on something that is unlike any other app I have ever developed. The project includes Arduino code, Ember.js, and Node WebKit (NW.js).

The best, of course, is DockYard's mindset towards open source. I always look forward to our "DockYard days" on Fridays to hack on code, blog (this is my first one!), contribute back to the community in some ways, or just to level up our craftsmanship.

And as much as everyone works really hard, we also know when to have fun, be it through Risk game tournaments, friendly games of Carcassonne (or, as some would say, "Casserole"), or world exploring and building on Minecraft.

Finding a job that you'll love can be hard. Finding a team that you'll love working with can be twice as hard. And sometimes, it's okay to leave behind what is comfortable and secure, in light of something promising, yet unknown. You may be pleasantly surprised.

Job: Senior UI & Visual Designer

2015-01-14 00:00:00

We are looking for the next addition to our design team.

The ideal candidate is someone who can demonstrate a strong user-centric approach to their work, cares deeply about how their work will ultimately function, has been part of the user research process in the past, and shows strength in typography, color, and information layout.

Weâre a design-driven software consultancy with design projects typically lasting 2-4 months. If youâre sick of working on the same product for years at a time, this may be a welcome change for you. Many of our client projects are âgreenfieldâ, so youâll have the opportunity to define the core concepts that will permeate throughout the application and be built upon as the product grows.

We are also heavily involved in the Boston design community. We very successfully ran our first UX East Camp last Nov, we host and coorganize UX Boston, run UX Happy Hour, speak at industry conferences and meetups, and blog about our experience (blog traffic is around 300 hits per day). If youâre publishing your work and articles through DockYard they will get traction.

You will be expected to take part in your community and we will give you tools to do so. We run weekly internal talks on a rotating schedule, run company wide peer-reviews of blog posts, and will fly you to one industry conference a year.

DockYard also has a full engineering team on staff (actually much larger than the design team by about 2-to-1). They are experts in both front and back end technologies. The implementation of your work will be on-point and very well engineered.

We offer better than market rates. Full health and dental coverage (no matter what your coverage requirements are). We also have 6 weeks of vacation time per year. 4 of those are mandatory vacation.

This is an on-site position in Boston, MA.

If this type of working environment interests you, then weâd love to hear from you. E-mail us (we do not work with recruiters) to get in touch.

Check your expectations (at the bathroom door)

2015-01-14 00:00:00

This is what we walked through one Friday evening as we were leaving work.

The building we work in is under construction. There are many small and large annoyances that come with a live construction site nearby. One thing has been particularly awkward: access to our restrooms.

As you might suspect, most if not all construction workers are men. There is active pipe work going on in the building, so they often need to do work directly inside the women's restroom at random times throughout the day. We would discover that a man is working on a ceiling duct in a space we expected to be for women only, and it has caused a considerable amount of tension.

While there may be many alternatives to doing construction work like this without warning, with less disruption of our work day, I had also started to question why this behavior felt like such an intrusion. After all, there are covered stalls with doors that go down close to the ground, so there's still a significant amount of privacy.

The reason seems to be not the exposure itself, but the fact that a certain space (e.g. beyond the door that says "WOMEN") has been designated for a specific use, and is limited to one gender. This situation is not default - in fact, there are a few alternatives:

Often located in smaller restaurants or coffee shops, a single-user bathroom normally does not have a gender restriction. One would simply wait for it to be vacant, and use it without a second thought.

A "family" bathroom (explicitly marked as such) is for one or many users. It is roomier than the "regular" bathrooms next to it, and normally utilized by a parent with children, or someone using a wheelchair. Few eyebrows would be raised when several people at once, regardless of gender, walk out.

At MOMA PS1 there is an explicitly declared unisex shared restroom. It has three stalls (with doors) and a urinal facing the back wall. It is a bit unsettling to use for the first time, but the explicit declaration makes it feel like a shared awkward experience, rather than a disadvantage of one group of people or another.

In summary - our expectations always determine what we consider to be unacceptable. The example of bathrooms in our office building clearly shows that a construction worker's expectation ("this is my work site") and my female co-workers' expectation ("this is a space for women only") did not line up. More importantly, both parties were "right" in their own way.

To me as a designer, this awkward situation clearly illustrates how important it is to understand a client's or a colleague's expectations in any given situation. It is entirely possible â especially when working with a client in an industry I am not familiar with â to commit terrible missteps without even knowing they happened.

To avoid the kind of toxic misunderstanding, it is important to communicate assumptions (even the "duh!" kind) early on in a project. It may feel awkward to have to say out loud the things that you consider to be understood by everyone involved. Get over it. When you find and defuse that one thing you did not agree was a given, it will all be worth it.

Masking private information from the owner

2015-01-13 00:00:00

Should we consider allowing the display of all private or risky information to the owner strictly through a prompt?

This could include:

username
password
e-mail
birth date
social security number
credit card info (maybe never show it)
account numbers
you get it by now

Why?

Well, one little bit of information that someone tweets about themselves in a screenshot could mean theyâre sharing a useful piece of data to a DOXX operation by some douchebag on the internet. Thatâs the theory, but as I know very little about DOXXing it may not make sense.

Why am I thinking this?

I just tweeted a photo and I realized after the fact I might have put some sensitive information in it. Not like credit cards or actionable items to any normal viewer, but the kind of information that could add up to something a technically sophisticated malicious person might like. Turns out it was just my name, which seems ok to me.

Because users donât really know better and they never will

Iâve spent a lot of time resisting the âour users donât knowâ mantra in certain scenarios, and I can tell you why sometimes still resist it, but I digress. When it comes to security, our brains arenât very good at remembering the pieces of information weâve shared. I have 4k+ tweets and I know a lot of people are at that or beyond. How can we be sure we havenât shared too much information? I donât think we can.

It could certainly be a pain in the designer's ass to worry about protecting the user from doing something harmful to themselves (on purpose yet without being aware) in addition to everything else our daunting jobs require us to, but maybe this really warrants consideration by designers. Maybe itâs part of the job.

Book design and the web

2015-01-13 00:00:00

I recently attended a presentation by a Swiss book designer Ludovic Balland where he described the process behind his beautiful and sophisticated books. His studio has done many architecture monographs, because the format lends itself well to carefully considered custom design. (Architects with lots of work to show also tend to have the budget for and interest in such things.)

Formats in print

A key concept in his book design process is the selection of an appropriate medium, or format, for each type of content. He explained that with enough analysis, the materials from which a book is to be made can clearly be separated by type of content. For example, photographs of completed buildings are one type, and architectural drawings of incomplete or conceptual projectsâââanother. Once the separation is made, the next logical step is to select the best format for each type of content, with sensitivity to its beautiful representation. Type of paper, ink, printing methods, folding and binding possibilities all become variables in an equation, which can have a logical and aesthetic solution.

Barents Lessons is a book based on a trip that a group of students took to the Barents Sea. (All images via ludovic-balland.ch)

This book consists of three sections, with three distinct formats. The firstâââAnalysisâââis text, meant for long form reading.

It is followed by a section of detailed maps. Colors were individually selected to take advantage of the cartographic detail. For this and other projects, Ludovicâs studio often completely re-draws graphics like this all in a consistent style for the book, which they then can print at the highest quality.

The final section holds student photographs. They are shown in an order determined by the value of the photo: from dark to light, avoiding forced storylines between photographs that do not necessarily relate to each other. The paper selection has changed once again, and the photos are given full prominence with minimal captions.

I find this book to be a great example of logical and thoughtful design: content is well supported and enhanced through the technology of book production. Everything, from the binding, to the paper, to the colors and page layouts, supports the content of the book. I also think itâs a strong parallel to the use of technology to support users, and the things they want to do, when we build products on the web.

Formats on the web

While technology allows us to make things respond in a specific manner to an action, to show only the necessary things to the right person, or to add delightful and playful details to already common tasks, it is the thoughtful and often economical selection of the âformatsâ we use on the web that makes for a strong, impactful project.

For example, using Ember.js - a technology that allows us to change portions of a web page without reloading the entire thing - allows us to enhance a search page very effectively. We could use the same technology to enhance a gallery type page (whose primary purpose is to show static content) but the improvement would be marginal and not cost effective. The Inexhibit platform focuses on âa community of users who place emphasis on content over complicated website designâ and offers a minimal tool for artists to create a gallery and show their work.

We can always add technology to marginally improve the experience. We could also print newspapers on higher quality paper, but the format would conflict with the nature of a newspaper as a frequently updated disposable item.

Our ability to select the appropriate format, or technology, for a task reflects our deep understanding of the content and the problem we are solving. The rejection of unnecessary improvements is an important decision. It makes our work efficient and focused.

Why is Google ignoring over 400,000 backlinks to DockYard?

2015-01-11 00:00:00

Imagine our enthusiasm when the opportunity to add hundreds of thousands of backlinks from one of the web's most popular library hosting websites back to our domain came our way. And imagine our surprise when Google decided they meant nothing.

Back in November we launched the redesign of RubyGems.org. We were contacted by RubyCentral about 9 months prior. I was interested in this opportunity for three reasons:

It gave DockYard the opportunity to give back to the Ruby community, one that has been so pivotal to our growth early on (and one that has been pivotal to my growth as a professional engineer for nearly 10 years)
DockYard can show off its design talents to the community
DockYard would get a "Designed By" sponsor link at the bottom of every page.

This blog post is going to explore the third reason and the result of this over the past two months.

At the time of launch RubyGems.org had over 90,000 gems published. This meant a sponsor link at the bottom of every page that was backlinking to DockYard.com. In addition to the landing page and the other static pages. This was an appealing value to gain from a re-design effort. According to Google's own backlink search DockYard had only 65 pages linking back. This struck me as odd considering this blog itself links back to DockYard.com and there were more than 65 posts. But surely after the redesign this number should go up. Our estimated PageRank was 5.

After the redesign we saw the expected spike in traffic

Checking in on the referrals we can see that to date we have received over 600 referrals from RubyGems.org. I'm OK with these numbers as I never expected everyone to be clicking on those links.

However, what did shock me was that none of these backlinks were being counted by Google.

The sponsor link does not have a nofollow attribute. And I admit that SEO is not something I've very good at. But if I were to look at another backlink source such as ahrefs

You can clearly see the spike in referring pages. A huge jump from nearly nothing to over 400,000. The bottom graph shows that these are primarly DoFollow links.

So these backlinks aren't being counted by Google? Does Google only count one domain per backlink? Color me confused. I suspect we're doing something wrong on our end to not get any credit. Could it be that such a huge spike in backlinks are flagged as suspicious by Google? I'd appreciate any thoughts in the comments.

Complex Search Pages Feel Better in Ember

2015-01-07 00:00:00

With many server rendered search pages, a change to your search parameters typically renders a new page. The use of some JavaScript can alter the search results, as seen below. Note that both refreshes and JavaScript results swapping happens.

Whenever the results are altered, it feels (and is) slow. The times that refresh the whole page feel the slowest, but even when a partial change happens, it's obvious and slow. It feels clunky

With Ember, we can provide a better experience. The video below is a similiar style search page on a site we built for Learnivore with Ember.

Notice that the page never refreshes completely. The search box always stays on the page. And when we switch categories, only the relevant options are swapped out, we don't have to redraw the whole page. And when we select an additional filter on the left, only the search results are swapped out. This page performs better because it performs less work. It feels better because you are constantly seeing parts of the page reloaded without being changed. The filters on the left only change when they need to.

It will also perform better on low bandwith connections; it only requests the data necessary to render the page. This will require fewer bytes to be sent compared to the server rendered page. When you render the page on the server, you have to include every tag necessary to render that content. When you are using a single page application architecture like Ember, it will only need the data that makes up that result.

What a representation of the server rendered page looks like coming across the web to your device:

  
  <html>
  <head>
    <title>Your search results</title>
    <!-- Several to tens of lines for stylesheets and javascript -->
  </head>
  <body>
    <header>
      <h1>Search results!</h1>
      <p>This can be tens of lines, hundreds of characters to establish content
      and look</p>
    </header>
    <div>
      <a href="somepage">Here is one of the search results</a>
      <p>Some description of your search result</p>
      <img src="SomeImage>
    </div>
    <!--Repeat the result 10/20/50 times -->
    <footer>
      <a href="about>About us</a>
      <p>Hundreds more characters to provide links, style, etc</p>
    </footer>
  </body>
<html>

Since the page needs to be completely reloaded, we need to display not only the contents, but any header and footer content. This simplified example also lacks any type of filters or inputs to alter your results, which would make the amount of data sent to your device larger to view the page. This needs to happen whenever the page is updated.

Compare the above to what Ember requires to update the page:

  
  {
  searchResults: [
    {
      title: 'Here is one of the search results', url: 'somepage',
      description: 'Some description of your search result', image: 'SomeImage'
    },
    Repeated 10/20/50 times
  ]
}

Bytes are wasted sending down the markup to render the page; it's already there, along with the header and footer. This payload is much smaller, and provides a friendlier experience to those on a slow connection.

We can provide better interactions with Ember because the user will not see unnecessary rerendering of the same content. The requests to update the content will be smaller, so new results will arrive faster. The difference in speed of these two approaches is increased as the user's bandwidth shrinks. Faster pages help with conversions, and Ember can provide a faster, more intuitive experience.

BEM Tips: Avoid Chaining Modifiers

2015-01-05 00:00:00

At DockYard, we use the BEM methodology for naming our CSS classes. BEM stands for Block, Element, Modifier and is a front-end development technique that suggests a class naming convention for your HTML elements. If you aren’t already familiar with BEM, it would be helpful to take a look at Harry Robert’s MindBEMding blog post and the BEM website first.

When I started looking into using BEM, I thought it would definitely work well for large web applications. The more rules we could put in place regarding naming conventions, the better. What I didn’t understand was what to do when an element could be considered an element of a block or a modifier. If I had a button that was in the footer and it was styled differently than other buttons in the website, should it be named .footer__button or .button--footer? Arguments could be made for both sides, so is one better than the other?

After trying out both ways, .footer__button proved more scalable because this rule could be consistently applied in more situations. Could there be more types of buttons in the footer? If there are also social buttons in the footer, our choices now become .footer__button--social or .button--footer--social. In the second one, is social modifying footer and footer modifying button? Or is social modifying button as well? To avoid confusion, I would call it .footer__button--social and not chain my modifiers. This doesn’t mean we shouldn’t use multiple modifiers in a class name at all. .person--female__hand--right is still fair game. It’s clear that female is modifying person and right is modifying hand.

TL;DR

If I had an element that could potentially be either an element of a block or modifying an element, the latter is better because chaining modifiers can be confusing.

Tips on Mental Models

2014-12-30 00:00:00

Just as a single color can have conflicting associations between different cultures, mental models can vary widely between users. If you havenât heard of mental models, they are a beholderâs mental image of a designed object and how it may be interfaced with.

Understanding the mental models your users have created of your product (or similar product experiences) is important. It will help you improve either by adjusting the product to better fit their mental model or by changing the usersâ mental model to better fit your product. Neither are simple.

To give you a sense of how a mental model is constructed or applied to a product, let's imagine looking at a new object in extreme slow motion:

The object is placed before you. The first thing you notice is its size and shape. Itâs small enough to fit in the palm of your hand, thin, and rectangular in shape. Its color is off-white. In this first glance you might make some general assumptions about the objectâs nature and function, but given that there are countless objects that could share these qualities, your observation continues.

On the grey rectangle you can clearly see a small red button, a small green button, a large square button, and a series of small grey buttons in a familiar 3x3 grid. Given that the device is small enough to fit in your hand, has multiple buttons, and lacks a screen, you might conclude that itâs a remote of some kind. And you might stop there, unless you actually have to use the remote.

While making these observations, your brain was building a mental model of how to interact with it by referencing past experiences with similar objects. Taking the path of least resistance, your brain wants to reapply these models wherever and whenever it can. You wonât need to re-teach yourself how to use something youâve consistently used over the years unless something significantly breaks the pattern. With each connection you make with familiar and unfamiliar qualities of the object, either consciously or not, you pave ways to interpret the purpose, value, and effectiveness of the object.

The speed with which we identify these things correlates to how similar the object is in form to other objects weâre familiar with. The models you create as a user arenât originating solely with the object in front you; instead they are created from all the objects youâve ever interacted with. This is where understanding and employing mental models gains value in design. We can use them to manipulate, speed up, or slow down interpretation of our products.

The information and interpretations from that first glance are all gleaned with relatively low effort, almost instantaneous, and youâre not always aware that you are making these evaluations. However, a unique object often takes a conscious effort to understand. If the object wasnât very well designed to reveal its own function you may instead have exhausted yourself with a seemingly uninterpretable thing and given up.

Borrowing

We sometimes borrow mental models from unrelated or contextually irrelevant experiences because some aspect of what we are interacting with may have unconsciously reminded us of previous experiences. A thing isnât always what we think it is.

Because we are all somewhat responsible for building our own mental models from our experiences with the designed world, our interpretations of an objectâs purpose or quality of performance can vary greatly. I think this is part of the reason why reviews of products are so polarized. Peopleâs expectations and preferences are different, and sometimes they just arenât able to build a fitting mental model of the product. So theyâll borrow it.

If the object is truly unique, layers of mystery may remain for a broad user base. Thus, there may be limits to how they have evaluated the objectâs purpose. As designers, we donât need to hold ourselves responsible for explaining everything, but it is important to get a user to as complete an understanding as possible using the objectâs form alone. No language, no manuals, no tutorials. No automatically playing videos after they log in for the first time.

Against the grain

Going against the grain of a mental model is generally a bad idea, but it can be valuable. It should be by design, of course, and might provide some comparative market value and interest. An example of this working was the introduction of the iPod and its very unique interface (the wheel) while competitors had basically indistinguishable and boring (by comparison) arrow key pads. The iPod might have been a little more difficult to use, but the innovative design wasnât enough of a challenge to stop people from using it. Instead the change helped Apple greatly differentiate their product from other MP3 players.

What happens when you go against the grain for no good reason? Lots of avoidable and silly mistakes, thatâs what. Take this remote for our projector as an example. For emphasis, Iâve erased the small labels generally ignored by users when turning the projector on or off.

We know itâs a remote at first glance because weâve used them before. The shape seems to suggest both purpose and a direction for use. Which end of the remote would you point toward the projector?

If you said youâd point it with the slanted side forward and the red button in the upper right, you would have found on your first (and second, and third) attempt that this remoteâs form does not align with your mental model. With this particular design, you are expected to hold the remote with the red button positioned on the bottom left.

In other words, the mental model I have for remotes is not matched to the device because the manufacturer ignored a common design pattern without apparent reason, adding only momentary confusion, rather than enhanced functionality, to my experience.

Last words on defining (and refining) your models

When designing your product, be aware of your usersâ mental models and recognize that your own will be very different from theirs. This is an overwhelmingly common mistake.

You should also be aware of user and market contexts to judge what aspects of their models you may break and which you should keep. Donât break the model just to be different if the difference provides no value or delightful experience for a user.

Lastly, designers must understand that users will have wildly varying points of reference, so presumed models need to be tested with multiple different users before the direction of the product design is settled upon. Failure to do this will put the success of the product at risk.

Lessons Learned - Three years of running a software consultancy

2014-12-28 00:00:00

This year's story is one of how we nearly went out of business twice yet still managed to pull off our most successful year yet.

People

In 2013, we ended the year with 11 employees. We made a key hire at the start of the year with Robert Jackson joining us. I had met Robert a few months prior at Burlington Ruby Conf. Robert had been contributing to a few of our Ember libraries, as well as making a name for himself by quickly moving up the contributors list in Ember.js itself. Less than four months after we hired Robert he was welcomed onto the Ember.js Core Team. I'm extremely proud of him accomplishing that.

We added depth to our design team in Q1 2014 with Maria Matveeva and Tim Walsh. Tim and Maria have been invaluable for us, their dedication and ability allows you to easily forget how young they are. I'm looking forward to seeing how they continue to grow in 2015.

Early in 2014, we hired our first Project Manager, Jon Lacks. Jon and I went to college together, and historically I have not had a good run of working with friends. That has been my fault, I think I was more interested in working with people I was friends with than establishing what their responsibilities would be. Jon and I agreed that any and all potential issues that may arise that could conflict with our prior relationship should be aired out immediately. Jon joined DockYard in February and spent the first month or so observing our team more than taking complete ownership of our process. I gradually handed off some of what I was managing to Jon (running standups, getting involved with some client meetings, helping with estimations). All this to say that adding a dedicated PM was one of the highest impact decisions I made in 2014. I suspect that many companies don't need one until they're around 10 people in size but once you do hire one you'll be thankful.

Romina Vargas and Lin Reid were two engineers that went through our intern program and we upgraded them to full-time as soon as we could. Both Lin & Romina have been important members of some of our larger clients projects in 2014.

Marin Abernethy, a former engineering intern, came back for her third (and final) internship with us after her graduation from college. In the Fall we hired her as a full-time engineer.

Paul Webb interviewed with us in early 2014 but we had some projects fall through and things got very tight for us (more on this later) so we had to pass. But as soon as we had the bandwidth we brought Paul onboard to our UX Development team.

Heading into the Summer, we started to get spread a little thin on the engineering team. I had come off of client work completely to focus on the business so we needed another Senior level engineer. I reached out to Estelle DeBlois, who had come to our Wicked Good Ember conference in June. She's been lead developer for one of our larger clients over the past few months.

Our final hire starts full-time with us in January. Ashley Treni was actually tending bar at Highball Lounge right next door to our office (they can see us, we can see them). She asked what we did and it turns out that she is an amazing designer who was completing her Masters in Information Design and Visualization at Northeastern. She did a summer internship with us and accepted our offer for full-time employment just recently.

Hiring is hard

Hiring continues to be hard. We have had success by focusing on technology niches, but we may have tapped that out. Going into 2015, we will have to consider how do we reach out and attract top talent, and how do we improve the existing talent we have. Promoting from within is something I've talked a big game about but have done little with. This will change in 2015.

I began 2014 with the same trend I had in the previous two years: I would hire good people even if we didn't have projects to put them on. Coming out of Q1 2014, I had to stop this immediately. While we had built up a great team, the weight of that payroll and our lack of cashflow at the time was at a breaking point where I could no longer cover the difference by taking myself off salary. Since then I have been very conservative with hiring. Unfortunately we actually missed out on some great people because of this, and I regret that as I was perhaps too conservative in our hiring at the time. Heading into 2015, this will probably continue to be an aspect of the company I will continue to improve.

Firing still sucks

I had to fire two employees in 2014. Firing always sucks and I don't think I'll ever get used to it. There is a guilt that is attached that at some point is out-weighed by whatever you're not getting from said employee. So how does one mitigate the guilt? Netflix has a great policy when it comes to firing employees. The document outlines their full cultural philosophy but the gist of how they fire is that they give a very generous severance package. So managers don't concern themselves with the guilt what will happen to this employee without their job. I think this is a great idea, but not always practical for all companies. If we had Netflix money then I would definitely align our severance package with theirs.

Culture

We've done a lot of work to define what the culture of DockYard actually is. Until Q4 2014 our culture was never written in stone. So we took some time to put it into words:

strong problem solvers, with attention to detail
coachable learners and willing mentors
professional, kind and respectful
collaborative team players
disciplined
reputation
diverse
fun

I'm sure you're looking at this list and thinking "yeah this is pretty much what every company will say". That could be true, but these are going to be our hiring and retention criteria. We will be building a team around these principles and expect everyone at DockYard to live up to them.

Heading into next year

We have a goal of expanding our team to over 25 by the end of 2015. I would actually prefer to be closer to 30. Our hiring will be focused on Senior Level talent for engineering, design, and UX. We're always interested in hearing from great people, get in touch if you're interested.

Estimations

Our problems with maintaining our estimations were not significantly improving in early 2014. We had to eat a lot of money on contracts that was due either to bad estimations or our inability to properly manage our clients. If we ever expected to build a real company, this had to be fixed. This is where Jon came in as our first Project Managing hire. It took a few months but we've gone from being consistently late to being consistently early. Our estimations are currently one of the more reliable aspects of our business. This has not just helped relationships with existing clients but being able to reliably sell our services to new clients is incredibly powerful.

Heading into the next year

I suspect we will continue to hone our ability to estimate. We will also be looking to hire an additional Project Manager as we decided we don't ever want to spread a PM over more than three projects.

Financials

In 2013 we ended the year with $1.7m in revenue with about 20% profit margin. This year we improved that to $3.1 in revenue with 33% profit margin. This is a significant jump, in many ways I'm incredibly proud of what we were able to accomplish this year. However, I also know that we (as a company) underperformed. If we had been as productive in the first half of the year as we were in the second half we should have been closer to a $4m+ company with >50% profit margin.

What went wrong

We were getting contracts coming in through the year, but nothing with the challenge or scope that I was hoping for. Small $50k contracts here and there. I like working on small projects but from a business perspective we were burning too much time negotiating contracts, balancing people on and off between contracts. I was butting heads with our business developer. He and I had different ideas on how to run the company. The funny thing is that neither of us were wrong. He wanted to reduce price due to lack of the demand we had at the time. I didn't want to do that. I was willing to pass on contracts that we could have gotten if we cut our rate 25%. This eventually put us in a position of bringing in 0% of billings for more than 50% of the company rather than 75% of billings. Which would you rather have?

I'm sure there are people reading this was a deeper background in running a business than saying it was stupid not to take the 75%. Here is my problem: at that amount we weren't making any profit and our people were tied up on projects. I was tired of living hand to mouth, I had taken myself off of payroll consistently for the past few years. I was living off my wife's salary.

At the end of Q1 I was looking down the barrel of DockYard and not liking what I was seeing. Then we got a whale of a contract come our way. This was a contract that could right the ship. Or so I thought.

I was not heading up the contract negotiations. The only criteria I gave was what I thought our rate should be for this contract. When it came to it our business developer was not confident that we could get that rate. I was distraught. I was not willing to lock DockYard into a long-term contract at cost. I told my wife at dinner I was going to start looking for a "real job" and that DockYard was finished.

I didn't sleep. I stayed up and kept mulling over the contract, was this it? I came to several conclusions:

The client could afford our rate.
We were worth the rate.
Our business developer did not believe in #2
I should be handling contract negotiations for DockYard

I came into work that morning. Within a span of 15 minutes I fired our business developer and landed the client at the rate we felt we deserved.

I realize the above might seem indifferent to letting someone go. He and I actually got along very well on a personal level. But as I mentioned previously when it came to how to run DockYard we didn't see eye to eye. I was stressing out over this constantly and in the event I was not able to land this client on my own at the very least I could say that I went out my way. Egotistical? Yes, of course. But it is something I needed to do. If we had slowly died over the rest of 2014 due to no real profit margin I would have quit.

This was the first of two near-deaths for DockYard this year. The second would come just two months later.

The large client came with a large legal team, one that I was unprepared for handling properly. We have an excellent lawyer we're working with but I am accustomed to contract negotiation taking maybe a week. This took months to complete.

The problem with dealing with Enterprise companies is that they can outlast you. It isn't their intent to do so, it is in their best interest that their vendors are able to work on what they need to the best of the vendor's ability. It doesn't help either party if the vendor can't make payroll. However, because of how many Enterprise companies are structured, and who has to sign off on what, an unprepared small vendor can be put into a position of agreeing to some things that are not in its best interest so it can start getting paid ASAP.

I was perhaps too risky in this regard. I held out on the contract, I put it through multiple rounds of negotionation. There was some legit scary stuff in it that I was not willing to agree to. We had started work with the client before the contract was completed. At the time I didn't consider this to be a big risk.

What happened was that there was little to no incentive to speed up the contract signing for our client. We were working, doing what they wanted, and they had no obligation to pay us. I realize some of you are reading this and thinking "Rookie Move!" but consider the context. Starting work with large clients prior to contracts being completed is actually a common practice in the Enterprise. I hear some of you screaming "no it isn't!". Yes, it is.

We ran out of money. We had a payroll that we were $25k short for. I had a very difficult conversation with the client and made the tough decision to stop work until the contract was signed and our existing invoices were immediately covered. I made a personal loan to DockYard to cover payroll. (as a side-note, banks never loan you money when you need it) Thankfully the client saw the situation for what it was and we were able to move forward. This was in June.

Putting the brakes on the project and getting the contract done and getting paid was the turning point for DockYard. We went from invoicing on average $30k/week to over $100k/week. With no contract longer than Net-30 by August we had all of our debts paid off and were in a position to hire again. By November we had gone from a 1% profit margin for the year in June to over 25%.

It is actually strange writing about this now, and I'm not entirely certain I should have written all of this. In some ways it was one of the most stressful times in my life, and looking back it feels surreal.

I hope there are some nuggets of knowledge in here to help others avoid a similar situation.

Heading into next year

We have ambitious financial goals. We aim for a $5m+ business in 2015. A $10m+ business in 2016, each year with >25% margin. If we can maintain our current momentum we should easily meet 2015's goal.

Technology

Ember.js

We bet very heavily on Ember.js in 2013. That bet has paid off very well for us in 2014. The client mentioned above hired us for our expertise in Ember.js. We landed another great client in the Summer because of Ember.js. We are seeing a steady flow of work come in because of Ember.js but I don't think we can meet our $5m goal by relying on inbound leads from Ember.js.

One thing we've never dealt with is selling our services into another company. We've got most work by companies making a technology decision then finding who is good at working with said technology. How do you convince a company unfamiliar with Ember.js that it is what they should use to build their product with? What if this person is not technology savvy?

I came to the conclusion that you cannot sell Ember.js directly. I needed help with building a sales pipeline and sales pitch. A friend put me in touch with Lorne Cooper who I have been working with over the past two months. Lorne convinced me that I had sales backwards. We need to start with Marketing. (he also convinced me that I couldn't sell Ember.js)

So what we built was the DockYard marketing funnel. Working backwards from Ember.js, we broadened the funnel. If the answer is: Ember.js then the question should be What is the best Single Page App framework? (let's save tech debates for another time). I didn't feel that selling SPAs was any better than selling Ember.js. Again, the answer is Single Page Apps so the question should be How do you provide a modern user experience on the web?. Now were had something. Selling UX as a solution to companies was tangible. If we could market that UX improvements was the way to solve common problems in modern web apps then we could hook companies on the idea that Single Page Apps was the best way to deliver modern UX. If we could convince companies on SPAs then we have the chance to convince them that Ember.js is the best framework for building out SPAs. At this point we have to make a case that DockYard is the best company as building Ember.js applications. We now had our marketing funnel. We plan on putting this funnel to the test in early 2015, but don't expect any significant number of qualified leads to be produced until late 2015, more likely early 2016.

Elixir

While we are not currently writing any Elixir apps I think it will be part of our offerings around Q3 2015. Specifically because of the Phoenix Framework being very similar to Ruby on Rails I think we should be able to ramp upon it quickly.

The other choices I considered looking into were Go and Rust. Elixir feels like the best of the three to me. It is far less popular than the other two but considering it is backed by Erlang and boasts the most approachable syntax, has meta-programming, concurrency, and is built for fault tolerance I feel of those three language Elixir is the best suited for the future. Of course, this is a gamble and time will tell.

Ruby on Rails

Our involvement with Ruby on Rails will never go away completely but I don't see Ruby or Rails being a serious part of our technology identity in the future. I would like to think that we were out with a bang though, in early 2014 we were selected to redesign RubyGems. We launched the redesign at RubyConf and it was a nice way to say "thank-you" to a community that we've benefited from for so long.

Heading into next year

I always want DockYard to be a company that does not stagnate on technology. I enjoy working with and exploring new technology and I always want to push our engineering team to do that same. In the near future I think Ember.js and Elixir will be important for us, of course we must be open-minded enough about new technology on the horizon.

Design

Design has become so essential to our process I don't understand how we go by in the early years without a dedicated design team. We rely upon design to manage our Discovery Phase, build and inform our estimations. Design has more impact on us converting a client out of Discovery to a full client than engineering does.

UX East

This year we ran our first Design conference, UX East. It was structured as a design camp with two talks and one workshop. The conference was organized by our Creative Director Steven Trevathan and Maria Matveeva we believe we were hugely successful.

We're already beginning plans for next year's UX East (you can sign up for updates, including call for proposals, here).

Team Structure

Every project is now assigned at least two designers. This is partially because the projects are big enough to merit the team, but it's also a huge qualitative add to the final delivery. Pairing designers is really helpful for "leveling up" as well. Matching designers by their different strengths they'll help each other grow. The concept is very similar to pair programming, however the designers go through many rounds of critiques instead of using the same computer for an extended period.

While we hadn't previously done this, and it looks like a fairly obvious improvement to make, the result has been surprisingly positive and our most recent projects are seeing a huge benefit from it.

Setting Goals & Sticking To Them

One thing we're very good at is coming up with ideas. Lot's of them. There is no shortage there, however there is a real challenge in effectively using down time and DockYard Fridays to commit to delivering on those ideas. I believe this is due to not having specific departmental goals that directly fit into company annual or quarterly objectives.

An example of this challenge is Tools of the Trade. In the beginning of 2014 we put effort into creating small and novel icon packs and distrubuting them as free to use. It generated some interest, and we had fun with our icons, but we dropped the ball and lost momentum on it. Not because we didn't enjoy making them or that it didn't benefit our designers by the challenge, but because it didn't fit cleanly into any company objective.

We've set a Q1 2015 goal to create a program and agenda for design experimentation with a focus on single page web applications. By that objective we'll be aiming to provide more practical design tools, design and interaction patterns, and free assets for other designers in creating single page web applications. By commiting to this goal and using Tools of the Trade as vehicle, we should be able to promote ourselves, "level up" our designers, and effectively utilizing downtime.

Business

On the business side of things we've begun to add more structure to DockYard. We hired a CEO coach to take us through an OGSM (Objectives, Goals, Strategies and Measures) planning session for 2015. It was a tiring two days of time that helped us discover what type of company we want to be. The management team has all decided that DockYard should aim big and that is what we're going to do.

Office Space

In Q2 2015 we'll be moving into a new office space. Our current space has served us well but it has its problems. The new space will be modern and have plenty of space for us (we're upgrading from 2,800 sq/ft to 7,800 sq/ft). I'm excited to share those plans in the upcoming months.

Wrapping Up

I hope this year's reflection has been useful for you in some way. Each year's summary has felt different and I'm sure next year's will too. As a company DockYard has taken some knocks this year but we came out stronger for it with more focus and an actual gameplan. I'd love to hear other's experiences as well in the comments.

Pattern Matching in Elixir for Rubyists

2014-12-26 00:00:00

This is the first in a series of posts for helping Ruby devs understand some of the concepts in Elixir.

Pattern Matching

Pattern Matching is one of my favorite Elixir features. Let's take a look. (using an Elixir Map)

  
  %{foo: bar} = %{foo: "baz"}

The above is matching a pattern. Don't think of = as assignment, you should think of = as equality. The left-hand side of the = is equal to the right-hand side. Through pattern matching the variable bar is assigned the value "baz". Consider:

  
  [foo, bar] = [1, 2]

foo is assigned 1 and bar is assigned 2. Patterns can match to any depth:

  
  [foo, bar, [baz]] = [1, 2, [3]]

here foo and bar have the same value from the previous example but baz is now assigned the value of 3. Alternatively if we had written:

  
  [foo, bar, baz] = [1, 2, [3]]

baz is now assigned the value of [3]. This would be an example of a semi-greedy matcher. You can expand upon this to greedily match the entire statement:

  
  my_list = [1, 2, [3]]

Now my_list greedily matched to the entire right-hand side of the =. So why is this cool? Let's take a look at a Ruby method that has some conditions:

  
  def foo(a, b, c)
  if a == :something
    ...
  elsif b == :other
    ...
  else
    ...
  end
end

The above is likely something familar to many Ruby devs. This presents some problems. Any methods with several code paths increases the complexity of the method. Complex methods can be difficult to test in isolation. Let's take a look at how this would be implemented in Elixir:

  
  def foo(:something, b, c) do
  ...
end

def foo(a, :other, c) do
  ...
end

def foo(a, b, c) do
  ...
end

The first question Ruby devs have is why are there three functions of the same name? In Elixir you can define multiple functions of the same name as long as the function signatures are unique. Functions are matched against the values passed in. So foo(:something, 2, 3) would match the first foo defined. foo(1, :other, 3) matches the second. foo(1, 2, 3) matches the third. Match priority is the order in which the functions are defined.

Now our functions are concise, and focused on the very specific behavior. The conditional is obfuscated through the pattern matching but this is a common design pattern in Elixir so it should be embraced.

The pattern matching can be more complex:

  
  def foo(%{foo: bar}, "baz") do
  ...
end

The above will match: foo(%{foo: "zeb"}, "baz") but would not match foo(%{foo: "zeb"}, "bar") because the second argument does not match.

Take a look at the Elixir Pattern Matching Guide for more information.

The Importance of Process, and Why It Matters

2014-12-12 00:00:00

I joined DockYard in April of this year, after leaving a small startup. Before that, I was at another startup and doing lots of freelance/agency work. In all of these places, there was never an existing process in place, aside from what was in my head. For better or worse, this was fine and allowed me to get work done. What I have learned since joining DockYard however, is that my old method of working is dangerous for a bigger company and just does not work.

Initially, I resisted changing my process, like a fool/jerk. Why should I? My process has worked for years, it was inherently superior! Obviously, this was not true. I got too comfortable with how I had been coding and ignored requests to learn about BEM syntax and organizing my CSS in a different order. Applying most of these new techniques to my own personal projects allowed me to see the usefulness to our UX team's (evolving) process. It was then that I realized, process is not about you or I, it is about the team.

If I am working on a project for six months and spin off to another project, another UX developer can pick up where I left off and understand the code I have written. If everyone wrote code the way they felt like, there would be so much time lost (and wasted) trying to figure out what the original coder meant when they wrote something. Money would be lost as well because time would not be spent on doing actual work.

Process improves productivity and productivity allows the team to gain a better understanding of what is possible for the company as a whole. Which, in the long run, creates better opportunities and projects for all of us.

TL;DR

Be open to new ideas about process. If it does not make sense to you, apply it to your own work before completely dismissing it.

HTMLBars: Calling All Testers

2014-11-30 00:00:00

HTMLBars support has landed in Ember's canary channel thanks to the tireless work of the HTMLBars team. Make sure to chat them up at EmberConf (you are going right?!?!) for some war stories.

We are nearing the end of the 1.9 beta cycle (aiming for 2014-12-06) which means we will be making the go / no-go decision on all pending features in Canary when we branch for the next beta cycle. Clearly, we would all love to have 1.10 use HTMLBars.

In order to enable the HTMLBars feature flag in the 1.10 betas (shipping around 2014-12-09), we need help confirming that no major issues exist. This is where you come in!

Using Canary Builds with Ember CLI

Upgrading to the canary channel with Ember CLI is very straightforward.

Update Bower

Run the following:

  
  rm -rf bower_components
bower install --save handlebars#~2.0.0
bower install --save ember#canary
bower install

Bower also prompts you to confirm various "resolutions" that it is unsure of. Make sure you pick ember#canary and Handlebars 2.0 if prompted.

Update NPM Dependencies

Run the following:

  
  npm uninstall --save-dev broccoli-ember-hbs-template-compiler
npm install --save-dev ember-cli-htmlbars

Summary

Now we have successfully updated to the latest canary builds of Ember. Next up: HTMLBars.

Using HTMLBars with Ember CLI

Enabling HTMLBars is as simple as adding the following to your config/environment.js (under EmberENV.FEATURES section):

  
  EmberENV: {
  FEATURES: {
    'ember-htmlbars': true
  }
},

Now restart any running ember serve commands you have and you should be running with HTMLBars.

Report Issues

This part is critical: Please report any issues at GitHub, especially regressions from 1.8 or 1.9-beta. If your business has certain browser requirements (IE8 for example) testing on those edge-case platforms today will help us resolve issues in time for 1.10.

Ember Wish List

2014-11-28 00:00:00

It's getting close to Christmas and I've got a few things on my list for Tomster Claus this year. All of my wishes are about making my applications smaller. One of the constant complaints I see about Ember is that it is "too fat". You may not know this but this problem is solveable and can actually grow alongside Ember to ensure your assets are a slim as they can be. On to the wish list!

Tree Shaking

Are you familiar with Tree Shaking? The concept is simple, a dependency graph of your application is built. Let's say one of your files requires A, B, and C. And A requires D, and F. And C required F. Currently with Ember CLI all files for all of your dependencies will get included in the final build. So if there is an E file it will be in the final build even if you are not using it in any way, this is wasteful. With ES6 the dependency graph can be built between your files, any files that are not in the graph are not included in the final built. They are "shaken" out of the build process. This means a smaller footprint for your assets.

There are two major hurdles to implementing this in Ember CLI right now. The first is that doing a static analysis on the dependency graph may result in false positives of what files to ignore for the build. While there are many files that you are depending upon via the import statement:

  
  import { foo, bar } from 'baz';

This is very easy to parse. But your application can also import resources via the Ember Resolver:

  
  container.lookup('model:foo');

A few levels down a resolveOther function is called and lookup is turned into a require:

  
  require('my-app/models/foo');

parsing this out is not as simple. We could just assume everything in the app's namespace should be part of the final build, but when other libraries are doing more complex tricks with importing this presents a problem. For example, in the latest version of Ember Validations the validators themselves live in the ember-validations namespace. You can override validators by placing them in your namespace. The lookup is something like this:

  
  function lookupValidator(name) {
  return container.lookup('validator:'+name) ||
    container.lookup('ember-validations@validator:'+name);
}

How do we properly parse this out to include the correct validators in the dependency graph? One solution might be for library authors to declare which files should always be included in the final build, but this defeats the purpose of only including what is being used. If the application is using the Presence Validator but not the Inclusion Validator why would I want those extra LOCs?

The other major hurdle is Ember itself. While Ember's source is in ES6 form the final build that you get is in AMD. Which means it is one file. Ember will have to be distributed in the original ES6 form. I am also not a fan of the current package names. If this ever happens I would much prefer:

  
  import Component from 'ember/component';

rather than

  
  import Component from `ember-views/views/component';

Separate builds

Ember CLI is all or nothing right now. Which means that you have a single build pipeline for your application assets (app-name.js) and a single build pipeline for 3rd party assets (vendor.js). It would be nice to define additional assets that can be built into final files. For example, this request for Ember Admin. Technically this could be done right now but it would require some heavy hacking of the vendor asset pipeline in Ember CLI. Personally I would like to see an API for this specifically. Perhaps it could be in the form of isolating a namespace to be ignored in the vendor.js final concat but still output in the dist/ directory.

Async code loading

This wish dove-tails off the previous one. Now that we have our separate assets how do we safely load them into our Ember apps? If we are isolating the assets I would think this implies they aren't meant for consumption at application launch. Going back to the Ember Admin example, not all users need those LOCs. Only when an authorized user hits the admin functionality should it pull down the Ember Admin assets and plug into the app. This would be ideal. The major hurdle here is with how the container currently works. Perhaps something like this could put it on the right track:

  
  resolveOther: function(name) {
  if (needAsyncLoad(name)) {
    asyncLoad(name).then(function() {
      // after this load completes the name
      // would be removed from the list of
      // resources requiring async loading
      resolveOther(name);
    }
  } else {
    return require(name);
  }
}

This would allow even further shrinking of the initial applicaiton footprint. Only include what is necessary, async load other assets. This creates the illusion of speed which is just as good as actual speed. You will have the trade-off of periodic sections of your app with a longer than normal loading state, but that should only happen once per application instance.

Wishes to reality

Fulfilling these wishes should go a long way to negating the "too fat" argument for Ember. Here's to hoping that 2015 will see a more lean Tomster.

Rubygems.org Redesign

2014-11-18 00:00:00

Today I am very proud to announce that the DockYard-led redesign of rubygems.org has been launched.

Ruby Central just announced and put into production a redesign of Ruby's most popular community website during the Lightning Talk session at RubyConf 2014

The redesign effort was led by Logan Faerber and built out by Amanda Cheung. You can see how happy it has made them.

We would have been lost without the guidance from Ruby Central folks Evan Phoenix, David Radcliffe, AndrÃ© Arko. As well as some insight from Nick Quaranto.

We were very fortunate to have been selected. We hope that everyone enjoys the new look!

UX East Camp 2014

2014-11-18 00:00:00

We did it. This weekend went far better than we ever could have imagined. Weâre grateful and maybe a tad bit emotional, so bear with us.

The camp was initially intended as somewhat of a proof of concept, but became something much more real than that. Beyond proving that we are all willing to spend 3 days living with complete strangers, we experienced the unique value of the connections, friendships, and mentoring that this style of event facilitated. It turns out that the people who pay good money for and spend a whole weekend on such a unique social and learning environment are exactly the type of people who make it worthwhile. The need to learn, share, and be challenged by their peers is in their blood. This is who they are, and theyâre the people we want to bring together.

It goes without saying: Michelle, Ed, JD, and Ben did much more than they were asked to and were the core of what made the camp so great. They shared their wisdom, challenged us to solve hilariously weird and unique problems, guided us, and befriended us. They poured their hearts into this and we are proud and humbled to have had them for our first UX East Camp.

The event was a risk, but the speakers and attendees overwhelming proved to us that it can and should be done. So weâre going to do it again.

See you next year at UX East Camp, Spring 2015.

My project for UX Camp

2014-11-12 00:00:00

This weekend, I am heading to UX East's camp in Maine. It is kind of like a conference, except you also get the opportunity to work on your own project and get feedback from others while there. I am helping organize the event, and a large chunk of my time will be spent taking photos and helping with other random tasks, so I wanted to bring a project thatâs small and easy to manage.

My project is practicing how to quickly sketch ideas by hand.

When I first started as a UX Designer at DockYard, I noticed how confident the other designers were at sketching. Logan just happens to be a kickass illustrator, which helps. But still, I felt like I lacked confidence in comparison. Iâve been trying to improve, but had not tried anything focused on sketching specifically yet.

Why is sketching useful?

Sketching is a great tool not only to produce work deliverable to the client (hand drawn wireframes are often part of the Discovery phase in our work) but also a way to think more clearly. If I can articulate an idea through a drawing, I have a good understanding of it. In the process of drawing something out, I also find the fuzzy areas that need more definition, and I am able to ask better questions as a result.

Writing on a subject is similar to this exploratory sketching. By trying to write on a subject, I find unexplained pieces, and am forced to form my thoughts clearly. But writing only uses one aspect of an idea. Visuals are something else. I want to rely on both verbal (writing) and visual (drawing) thinking in my work.

How to practice?

I decided to focus on practicing only the skill to express a single idea through a very simple drawing. As an art supply enthusiast, it is easy for me to get carried away in selecting just the right pen, paper or color for a project. To counter this, I limited my tools: a clipboard, a single medium-weight black marker, and a sizable stack of half-sheets of printer paper.

I further limited possible distractions by deciding not to focus on high quality, thoughtful drawings, and instead produce many simple drawings. For this reason, I will also not look for great reference material, but try to just get the visual idea down on paper quickly instead.

I will also focus on actually drawing, rather than annotating. In the few practice drawings I made so far I resorted to writing the details I could not get into the drawing. It would be great to get away from this.

When I finish one of these simple drawings, I will slide it to the bottom of the stack so Iâm ready to start another one. I will not focus on judging the results too quickly.

At camp, I might share the drawings I make, and ask for feedback on how to make them more clear. Will they make sense? With some practice, I hope that they do.

So, hereâs what I am working on. Pretty simple, and should be fun! I also asked a couple of colleagues what they are planning to doâââand here it is:

What Steve is working on

He's going to work on a video game idea that originally started as a web-comic at DockYard. In addition to that he's taking a look at some various prototyping tools (as well exploring InVision a little deeper).

What Tim is working on

Tim has been working on a typeface that is targeted to be both practical and highly legible. He's hoping to gain some feedback from fellow campers and continue chipping away at the lowercase letterforms.

Pitch This

2014-11-07 00:00:00

Here is something I probably shouldn't be admitting: I can't put together a sales pitch for my own company.

It's not that I don't know what we do, I am intimately familiar with what we do. It's not that I don't believe in us, in fact we have big growth plans for the next 3 years and I am certain we'll meet them. It's just that I find it incredibly difficult to describe to others in an "elevator pitch" what a software consultancy can offer without going down the "technology" rabbit hole.

The exercise is: if I were introduced to someone at a party, how do I convince them they should hire DockYard? Funny enough, I can't do it. This is a very large deficiency for me/my company right now. To date all of our contracts have been from inbound sales. Which is great, but we need to be able to sell our services to companies that don't yet know about us.

So what does DockYard do? According to our current landing page We create web & mobile applications. Which is 100% true, but if I told this to you I doubt you'd hire us. I asked other DockYard'ers to try their hand at writing the DY pitch. To illustrate how difficult this is here is what they came up with:

DockYard designs and develops applications for people who have an idea and don't know what to do next
We build web products, and focus on quality.
We create software that helps people. A client can come to us seeking advice regarding software development practices or looking to implement a product he/she has been thinking about. Our main focus is delivering a solution that a client is happy with by using powerful visual design, best software engineering practices and latest technologies.
We're a design and development shop specializing in really intuitive, responsive user interfaces. We work primarily with Ember.js, which is a JavaScript framework similar to Angular and Backbone. On the backend, we prefer a Rails backend and transactional database, which is more reliable than the NoSQL databases out there.
DockYard leads projects from ideas to user-friendly products that are built by cutting edge technologies and methodologies. As a team, we put clients' business goals in the forefront through the collaborative expertise of our designers and developers.
DockYard helps business owners create web apps with the combined power of Ember and great design.
We're a team of software designers and engineers deeply invested in producing the best solution to a challenge, rather than just the one that works.
We do a lot of research before we start designing, so our projects are thought through. Designers have a lot of say in what we actually build, compared to other shops, so it makes the work more meaningful.

Some of these go beyond the scope of a "pitch" but I think the message is clear: this is not an easy assignment. The common theme is the focus on our expertise, which is a good angle. Expertise has been what defines DockYard. But do all companies care about how we build?

Currently nearly all of our clients get in touch with us because of our expertise in Ember.js. At that point the sale is actually quite easy. There aren't a lot of consultancies right now claiming expertise in Ember. Amongst those firms I believe that DockYard is considered one of the top. So by the time the client contacts us they have probably already decided to go with us. This is great but it paints us into a niche. We're missing out on the other 99.99% of the opportunities that don't know about us.

So how do some other software consultancies pitch? I don't know if it is fair to use the marketing tagline from their website as their "pitch" but I think it is close enough for the purposes of this article. Let's take a look:

Thoughtworks We provide software delivery, pioneering tools and consulting for organizations with ambitious missions.
Pivotal Labs We transform how the world builds software.
thoughtbot Our clients hire us to design and build their products. We focus on user outcomes and simplicity. We write code for iOS, Android, and the web.
37signals an elite team of expert web design and usability specialists dedicated to simple, clear, and useable customer-focused design.

I don't know if this really helps me or confuses me even more. These are all over the place, from general, to technology specific, to downright vague. Each of these companies have been very successful. How much of their success do they owe to their sales pitches? 37signals (when they were a consultancy) was famous for being a referral based business. (or at least advertising themselves as such) I don't know thoughtbot as well as I used to but I believe they still don't have any internal sales team. Thoughtworks and Pivotal both have sales/biz-dev teams. Their marketing lines are very vague, very "wide-net". No help here.

It's sad to say but I am currently at a loss on how to effectively sell my own company.

Motivation vs Discipline

2014-10-30 00:00:00

We've all seen the Motivational Posters:

I always hear people talk about motivation. What motivates you? I'm lacking motivation. Well I'm here to tell you that motivation is bullshit.

Motivation may get you to take on a task or behavior that you don't normally do but eventually that motivation will either not be there any more or won't be effective. Then you'll slip, and you justify it by thinking "well I just lacked proper motivation".

Motivation as a concept is a cop-out. If you feel that you need motivation to accomplish your goals you will likely fail over the long-term. Instead you should be looking toward discipline.

There is a saying "it takes 3 weeks for a new behavior to become habit". If you haven't heard that before that's OK because it isn't true. According to research it actually takes on average 66 days of continual behavior to form a habit. So ask yourself this. Can you use the same motivation for 66 days in a row? If not, do you have that many different forms of motivation to form this new habit over this period of time? I don't think many of us do.

Discipline on the otherhand is you saying to yourself "I will do this even if I would prefer to do something else". It's not an easy trait to establish but if you can do so you'll find that making changes happen more easily. I think many of us have a will to overcome existing habits and form new ones but we lack the way to do so. Too many distractions, too many opportunities, too many excuses. Take a look at successful people around you. Ask yourself are they successful because of some outside motivation or are they successful because they've made a conscious decision they're going to wade through the muck to get what they want.

Focus on being disciplined instead of waiting to be motivated.

KSS Your Styleguide Goodbye

2014-10-24 00:00:00

Styleguides are a place where developers and designers can find authoritative information about how elements are to be styled throughout a project. Contributors can always refer to a styleguide to help them create new pages and elements. Careful attention to a styleguide can prevent a contributor from designing or developing components that don't conform to the designers' vision.

Most styleguides are created by designers and developers prior to development to guide the translation of comps into code. In a perfect world, that styleguide is a living document that is updated as changes are made to the design. This often doesn't happen. As changes are made throughout a project's development cycle, the styleguide is rarely updated. At some point on almost every project, that styleguide is no longer a reliable, authoritative document.

If only there was a better way...

Enter KSS

KSS is a methodology and set of tools that will help you create automated, living styleguides. Through the KSS menting syntax and the KSS parser, the guide can be updated automatically throughout the development cycle. All those little adjustments and decisions that happen in conversations outside your documented channels will be reflected in your KSS styleguide. In theory, the styleguide will show the most up-to-date styles. KSS styleguides also render element states like :hover as you can see in this example from GitHub:

A KSS styleguide can be designed to reflect the look and layout of your project using existing styles:

KSS isn't magic. It's not going to create the styleguide for you. You still have to do a lot of custom configuration and coding. Coding the styleguide starts with commenting your CSS. You have been leaving helpful comments for future developers all along, right? KSS defines a syntax for these comments:

  
  // Short description of the element to be documented
//
// :hover             - description of this modifier.
// .disabled          - description of this state class modifier.
//
// Styleguide x.x.x. Section Name and/or Number
.element-to-be-documented {
  ...
  &:hover{
    ...
  }
  &.disabled{
    ...
  }
}

A KSS parser like this one for ruby parses the elements of those comments â the description, modifiers, and section â and applies it to a partial like this:

  
  <div class="styleguide-example">

  <h3>
    <%= @section.section %>
  </h3>
  <div class="styleguide-description markdown-body">
    <p><%= markdown h(@section.description) %></p>
    <% if @section.modifiers.any? %>
      <ul class="styleguide-modifier">
        <% modifiers.each do |modifier| %>
          <li><strong><%= modifier.name %></strong> - <%= modifier.description %></li>
        <% end %>
      </ul>
    <% end %>
  </div>

  <div class="styleguide-element">
    <%= @example_html.gsub('$modifier_class', '').html_safe %>
  </div>
  <% modifiers.each do |modifier| %>
    <div class="styleguide-element styleguide-modifier">
      <span class="styleguide-modifier-name"><%= modifier.name %></span>
      <%= @example_html.gsub('$modifier_class', " #{modifier.class_name}").html_safe %>
    </div>
  <% end %>

  <div class="styleguide-html">
    <%= @example_html %>
  </div>
</div>

You'll also need to create a controller, a template, helpers, and a front-end KSS script to render the styleguide. It's a lot of up-front work, but there are examples and parsers already written for Node.js, Ruby, PHP, Sinatra, Rails, and so on.

Why use KSS?

If standards, methodolgies, and tools are your thing, you'll like KSS:

The kss.js script can render elements with different states (called modifiers by KSS) directly in the styleguide blocks. For example, buttons with :hover, :focus, :active, states or even modifier classes like .red, .is-active, or .disabled will be automatically added to the styleguide allowing readers to see every possible state at once.
CSS comments and styleguide documentation are bound together in the stylesheets, not some other styleguide-specific template. UX developers can comment the stylesheets they work in most while they're working in them.
The styleguide templates can also include markup codeblocks, allowing readers to see the markup elements necessary to generate a component.

Why not use KSS?

If you're in the "tools are bullshit" crowd, you're going to hate KSS:

Styleguides created with KSS are only as reliable as the CSS and markup used to generate them. If an element is changed in a way that no longer conforms to the design comps, the styleguide will no longer reflect the correct way that element is supposed to be styled. For example, a developer might change the border radius of a particular button for a new page and doesn't realize that he or she has just changed the base button style in the styleguide. Now the button entry styleguide is no longer a reliable representation of the styles established in the design comps.
When elements are taken out of their context it can change how styles are applied. Elements have to be adjusted and changed just to appear correctly in the styleguide. This is work beyond what is strictly required to develop a site.
Styleguide-only styles and markup might be confusing to developers joining a project. The rules and markup in the styleguide aren't necessarily the same rules or markup used in the site. When creating new elements that follow from a styleguide entry, simply copying the elements as they appear styleguide could cause layout and style problems.
The KSS documention is spread out over many files. Nothing is centralized. Simply restructuring the styleguide, editing sections, or even adding new items requires sifting through many CSS files and templates. And when styles for elements are duplicated or spread across several pages, where do we put the documentation?
Deciding what goes in the styleguide and how it is documented becomes another tangle of challenging questions. How do we describe this element? How to we organize the guide? What do we include?

KSS Is Just Another Thing

The strength of KSS â automation â is also the source of its weakness â mutable elements. If the styleguide can be updated automatically, it can also be sabotaged accidentally. The styleguide must be QA'ed alongside the site to ensure that it conforms to the design comps and that it accurately illustrates elements as they appear in the actual site pages. Developers must take care to pay attention to styleguide-only rules and markup.

You could generate a static styleguide in your comping tool of choice as a definitive reference against which to check the living styleguide. But then you're just creating more documents that must be updated. You haven't solved the original problem.

Implementing KSS requires additional UX Development and Design resources (additional QA, more templates, styleguide-only styles, controllers, etc.), but may save resources spent creating and updating a static styleguide.

KSS is not a perfect solution to the problem of maintaining living styleguides. You'll simply have to try it in your workflow to evaluate its utility.

Go: UX East's UX Camp

2014-09-24 00:00:00

We are pleased to announce UX East's UX Camp, a weekend of creative thinking, collaboration, and design in one big house on Nov 14â16th in Bryant Pond, ME.

This isn't a typical networking event or conference. We'll escape the busy and distracting city environment to focus on our craft alongside others interested in design. It's a project weekend, a getaway, and a miniâconference all rolled into one. You'll work on whatever you like with the option of gaining creative input of others.

The environment is intimate by design. There will only be 30 people at this event who you'll eat, sleep, and work alongside. On top of all this, there will be a workshop and a few talks available to all who attend.

There are many more details to come, and I'm excited to share them with you! Follow our UX East twitter account or check back here for updates. If you're interested in taking part in the event in any capacity, please reach out to steven@dockyard.com.

See you all in Maine!

JavaScript Performance For The Win

2014-09-22 00:00:00

JavaScript performance is a very hot topic nowadays. There's a lot of information out there on what browsers do with JavaScript code in order to execute it faster. Let's go over some of the tips that will help you write faster JavaScript code.

Tooling

There're are couple of tools that you can use to identify and fix peformance problems. One of the them is Chrome Developer Tools (open Chrome Developer Tools, switch to Profiles tab and click Start). Developer Tools will give you a great overview of what actual happens in your application under the hood (what functions are called, how much CPU time they consumed, how much memory). That's a great starting point. Now you can start fixing performance where it matters.

Non-optimizable code

try-catch and try-finally blocks will not be optimized by the V8 (to be clear, if the function contains a try block, the whole function will not be optimized).

  
  // code
try {
  iMightThrowFunc();
} catch(exception) {
  iHandleExceptions(exception);
}
// code

A better way of writing the code above, would be to isolate the try block into a separate function so code can be optimized and only iMightThrowFunc would not be optimized:

  
  function iMightThrow() {
  try {
    // [code]
  } catch(exception) {
    iHandleExceptions(exception);
  }
}

// code
iMightThrow();
// code

Using Local Variables

If you're using a piece of code many times, it's better to create a local variable for it for a couple of reasons:

faster scope look ups (once the variable is local scope, it's faster to retrieve it)
caching (performing an operation once and storing the result will result in less work for the browser)

Literals

It might sound very obvious but you should use object literals whenever you can.

  
  // use
var array = [];
// instead of
var array = new Array(16);

You rarely know what the size of the array is going to be in your application. Let V8 manage the growth of the array as you add items to it. It will also ensure that the array is in "fast elements" mode and item access is always fast. You can read more about V8 object representation here.

"Dictionary Mode"

An object will go into "dictionary mode" when you add too many properties dynamically (outside constructor), delete properties, use properties that cannot be valid identifiers.

  
  function forInFunc() {
  var dictionary = {'+': 5};
  for (var key in dictionary);
}

When you use an object as if it was a dictionary, it will be turned into a dictionary (hash table). Passing such an object to for-in is a no no.

Iterating over a regular array

  
  function arrayFunc() {
  var arr = [1, 2, 3];
  for (var index in arr) {

  }
}

Iterating over an array using for-in is slower than a for loop and the entire function containing a for-in statement will not be optimized.

Using for loop is almost always a safe bet. Do you need to iterate over object's properties?

  
  var objKeys = Object.keys(obj);
var propertyName;

for (var i = 0, l = objKeys.length; i < l; i++) {
  propertyName = objKeys[i];
  // more code
}

for (var propertyName in obj) {
  if (obj.hasOwnProperty(propertyName)) {
    // more code
  }
}

For-In

For-In statements can prevent the entire function from being optimized in a few cases. It will result in "Not optimized: ForInStatement is not fast case" bailout.

`key` has to be a pure local variable

It cannot be from upper scope or referenced from lower scope.

  
  var key;

function doesNotSeemToBeLocalKey() {
  var obj = {};
  for (key in obj);
}

Arguments

Careless manipulations with arguments might cause the whole function to be non-optimizable. It might result in one of these "bailouts": "Not optimized: Bad value context for arguments value" and "Not optimized: assignment to parameter in arguments object".

Reassigning `arguments`

  
  // do not re-assign arguments
function argumentsReassign(foo, bar) {
  if (foo && foo === 5) {
    bar = 'Barracudas';
  }
  // code that uses `bar`
}

// use local variables instead
function argumentsReassign(foo, bar) {
  var localBar;

  if (foo && foo === 5) {
    localBar = 'Beantown Pub';
  }
  // code that uses `localBar`
}

Leaking `arguments`

  
  // `arguments` is a special object and it is costly to materialize.
function leaksArguments() {
  var args = [].slice.call(arguments);
  // code that uses `args`
}

// does not leak arguments
// accessing `arguments.length` is just an integer and doesn't materialize
// `arguments` object
function doesNotLeakArguments() {
  var args = new Array(arguments.length);

  for (var i = 0; i < args.length; ++i) {
    // `i` is always valid index in the arguments object
    // so we merely retrieve the value
    args[i] = arguments[i];
  }
  // code that uses `args`
}

Note, that in most cases optimizing takes more code. You can probably write a build step for that:

  
  function doesNotLeakArguments() {
  arguments_slice(args, arguments);
  // code that uses `args`
}

Happy Coding!

Building Quality Into Our Projects

2014-09-19 00:00:00

This article serves as a continuation of a âClient Targetedâ article recently published by our own Michael Dupuis (Features As Business Objectives). These posts aim to provide our current and prospective clients insight into how we approach development at DockYard.

Building âQualityâ software does not happen by accident. It is actually one of the unspoken sides of the âiron triangleâ of project constraints (Scope, Cost, Time) - or should we call it a diamond now? Letâs not go there!

When making an investment in development of an application, the level of desired quality influences project cost and schedule. Building an appropriate Quality Plan for a project requires time, planning and execution which is the responsibility of DockYard and the clients with whom we engage. Below I layout the primary types of quality related practices we may consider applying to our (your) projects; always driven by clientsâ unique context (See my earlier blog post about context driving practices - Process Paradox). This article does not serve to describe these quality practices in depth but will cover the basics in terms of how they could apply to client projects. Any one of these practices in isolation is not an effective recipe for quality, it is the degree to which these practices are commingled in a logical way that results in positive outcomes.

Practice #1 - Test-Driven Development / Automated Testing

Before the Engineer writes a line of code they are investing time in thinking about and writing the appropriate test cases for the code - these tests will serve as a functional quality benchmark which the engineer can code towards. In parallel these efforts build up a library of automated tests that will ensure that the âworkingâ features built early in the project continue to work when new features (code) are introduced later on. If we donât have these tests and we have 1000âs of lines of code, testing/debugging overhead raises exponentially which will result in increased risk to project cost and/or desired schedule. Itâs also important to note that this practice is functionally-centric and not visual which is addressed with other practices described below.

What this means to the client

The cost and eventual savings related to this practice manifest themselves as time spent thinking vs. coding vs. testing. When we estimate what it will take to develop a given feature, we consider the time spent thinking about these tests, writing the tests, maintaining the tests in addition to writing the feature code. However, keep in mind that the time spent testing later on in the project, when the code base has grown exponentially, is reduced due to this upfront investment of time (see figure below) because we have a growing set of automated tests that will ensure we continue to maintain high quality throughout the development cycle.

Practice #2 - Pair Programing / Code Reviews

Sometimes (usually) two heads are better than one. Pair Programming is exactly as it is described. Two engineers team up to work side by side on a single unit of code (or feature.) In a 2013 article published by the Economist a study conducted by Laurie Williams of the University of Utah showed â...paired programmers are 15% slower than two independent individual programmers, while "error-free" code increased from 70% to 85%. Since testing and debugging are often many times more costly than initial programming, this is an impressive result. Pairs typically consider more design alternatives than programmers working alone, and arrive at simpler, more maintainable designs; they also catch design defects early.â

Additionally, Code Reviews by a peer or more senior engineer serve to ensure that the code being written meets agreed best practices and that mistakes of the past donât get reintroduced.

What this means to the client

Pair programing and Code Reviews are practices DockYard believes yield higher quality code while also establishing a continuous learning culture across our engineering team. The extent to which we apply these practices is less variable in that it is part of our company DNA - however, like any practice, a clientâs project context will dictate the extent to which these apply. The client will incur the benefit of a well rounded and productive engineering team which can translate to reduced project cost.

Practice #3 - Manual Testing

In a literal sense this is the type of testing conducted by a human who seeks to ensure the less common use cases which may not have been exercised by an Automated Test or code review are working as expected. Additionally, this type of testing ensures the visual design of the product has been upheld - Spacing, pixels, colors, fonts, etc. Browser compatibility is also something manual testing will verify. This type of testing is usually conducted by members of the project team and the client. They work in collaboration across the feature set, report and classify severity of bugs which are eventually assigned to engineers when appropriate.

What this means to the client

The client should be prepared to be a very active participant in this practice and schedule their time accordingly. Feature complexity will drive the amount of time required for this type of testing - which might be nil if complexity is low. A very rich user experience will require more testing and thus manifest itself in terms of increased time/cost.

Practice #4 - Client Demos (and Acceptance Testing)

For most projects we work in 1-2 week iterations (sprints) and at the conclusion of this time period we typically demonstrate the progress we have made by sharing working software. These demonstrations serve a dual purpose:

gives the client opportunity to verify development is proceeding in the desired direction, and if not, attempt to course correct early on vs. late in the project when course correction can be very costly
allows the team to reflect and continuously improve how they are executing the project.

When a feature is ready for prime time, we will usually ask the client to formally accept the feature as complete. This ensures the team can shift their full focus and attention to building the next features on the backlog. Context switching can be very costly in terms of productivity, therefore we try to call things âDone Doneâ before moving on.

What this means to the client

Similar to manual testing, client should be prepared to be a very active participant in both demos and conducting acceptance testing within agreed timeframes. Deviation from established timeframes will result in increased project cost/time. Therefore, whenever we engage with a client, we request upfront a high level of collaboration and availability to keep things moving along.

Hopefully after reading this article, you have gained an appreciation for some of the considerations we make in terms building quality into our projects. The level of quality a client desires and the pride DockYard has in its deliverables drives the extent to which these practices are utilized. Therefore, if you are interested in engaging with us, think about the level of quality you expect and we will work together to derive an appropriate quality plan that balances your cost and time constraints.

Reducing Project Costs: Features As Business Objectives

2014-09-12 00:00:00

There is a lot of insight a developer can offer when it comes to reducing costs associated with building web applications. While few developers have MBA degrees, we are âin the trenchesâ when it comes to bringing a project from ideation to completion. We see where projects go astray and where in the process complexity gets introduced, timelines get pushed out, and costs rise.

Failed features are a significant cost to any project. Iâm defining a failed feature as a feature which gets implemented by the developer correctly, but which was ill-conceived in the planning stages. Thereâs no 404 error pages, just poor user experiences that donât serve the applicationâs aim.

To mitigate failed features, there is a first principle that I think clients should apply at the outset of any software project:

Align the applicationâs features with business goals.

âHave attainable goals,â is something you hear in a range of industries â from fitness to financial planning. For example, it is common when designing an investment portfolio to come up with a baseline for what youâd like to have saved by the time you retire. Goals help quantify short-term success (meeting monthly savings goals) and bring context to immediate financial decisions (going on an extravagant vacation vs contributing to the 401k).

In many regards, defining business goals is far harder than designing a feature for an application. Developers can implement an idea, but if the idea is not well grounded or refined enough, the implementation does not matter. Application consumers will not be able to use the feature in a way that translates to success for the business. For all intents and purposes, the feature is âbrokenâ and costs are about to go up because it will need to be fixed.

This is why coming to a consultancy with a list of features is problematic. Features are not grounded in any sort of reasoning; business objectives are. Enter the planning process with a set of business objectives for the application.

Letâs take a simple case. A client is overhauling their marketing site. They sit down in their first planning meeting with the designers and developers and say âwe want a blog.â A blog is a feature â it is not a business objective. What would be more helpful from the designer and developersâ perspectives is to hear: âwe want a way to show prospective clients that our firm is transparent.â This a business objective. It informs the designer that there is a target audience to design for (prospective clients). It tells the designer a little bit about the clientâs values (transparency). Yes, it may lead to a blog, but whatâs important is that it grounds the feature with a purpose.

Features must align with business goals, because they create the theoretical framework in which the application operates; the alternative is an aimless application with a lot of code, a lot of options, and a lot of usability problems. Designing a user experience which gets the consumer from point A to point B becomes difficult because there is not a logical consistency to the elements in the application. Features do not have a unique roles, and so the designer cannot delegate responsibility in a predictable manner.

Features that are not aligned with business objectives are expensive.

It goes without saying, but clear design thinking translates into cleaner implementations for the developers building the application. Features can be added, removed, and enhanced without hurting other elements of the application. Code becomes less coupled, is more maintainable, and can be better tested.

Features without well-defined roles donât have a place in the applicationâs ecosystem, and so they often fail. This is a worst case scenario. It means that users canât interact with the application in a way thatâs meaningful for the business. And since these failed features need to be fixed and re-worked to meet the business objective (which should have been known and communicated at the outset of the project âdiscoveryâ process), the client has expended the following resources:

the time that went into designing and implementing the failed feature
the cost that went into designing and implementing the failed feature
the time that will go into designing and implementing the correct feature
the cost that will go into designing and implementing the correct feature

This is to say nothing of the opportunity costs. While one client is figuring all of this out, a competitor who aligned their features with their business objectives and âgot it rightâ on the first attempt is gaining happy, new users.

When a businesses hires a software consultancy to develop an application, theyâre bringing in skills and expertise from the outside. Itâs unlikely that a developer is going to advise a client on how to gain market share, and itâs just as unlikely that a client is going to open a designer/developerâs eyes to a new application feature. Rather than planning an application around a set of features, clients can make the most of a consultancy's resources by coming to the planning stages of a project with well-defined business objectives.

The Fear of Failure

2014-09-11 00:00:00

When confronted with a new task it's natural for someone to feel a sense of anxious hesitation. Sure, it varies between individuals depending on the activity or setting, but entering an unfamiliar scenario can make anyone feel uncomfortable. Often this anxiety leads someone to succumb to their fears of failure, which ultimately results in them not even taking a chance at learning something new.

No one wants to be a failure - there's a connotation that you should just give up or else be publicly humiliated. Thanks to the recent development of social networks, anyone can declare someone as a failure simply by leaving a comment on a video online or posting blanketed statements on various articles - all the while never having to say it to their face directly or give useful constructive feedback. This mentality comes from a very judgmental and one sided declaration that spurs from people's fear of being a failure themselves.

Alone, the term failure is a simple solution to a more complex problem. It's quick to label the scenario as everything having gone wrong rather than taking the time necessary to provide constructive feedback or to consider steps leading up to the "failure". By neglecting to reflect on the the particulars of the situation we are not learning from our mis-steps.

Rather than refer to these results as failures, I like to think of them as mistakes, granting more leniency to a lifetime of self-educating. While a failure feels conclusive, a mistake feels like a small part of a whole, which is more representative of how learning a new skill or concept should be. We should always be approaching the chance to learn something new with an optimistic and open mind, and the only way to do that successfully is to embrace the fact that you're bound to make mistakes along the way. Think about it; if a kid messes up, we don't instantly jump to calling them a failure. We let them know that it's okay, they've made a mistake, but then we follow up with an instruction or demonstration on how they could improve next time. This ability to showcase compassion when sharing ideas is how we've come so far as a human race. We tend to be most curious as children because we're unaware of the cultural judgment that comes from not being right all the time. We're still willing to experiment without that fear of failure. The curiosity to learn something new is an exciting one, where we focus on ourselves improving and not the jealousy of what others have accomplished, so why not treat our entire lifetime of learning with a similar level of patience and understanding?

Fear can be incredibly influential when learning something new as long as it's used to fuel the fire and not extinguish it - prove it wrong. Instead of focusing on what you have to accomplish and getting overwhelmed, take time to learn at your own pace; as they say, patience is a virtue. The best way to learn is to dive right in without thinking too heavily. By getting directly involved you will be learning through a hands on experience, which helps to reconfirm what works and what doesn't. As with most things, repetition is key to retaining information. If you're willing to make mistakes along the way, jump right in and get your hands dirty. Not only will you avoid wasting time hesitating, but you're forced to find a solution now that you've already begun. The less you think in these scenarios, the better.

In order to learn we must be willing to make mistakes. Hundreds if not thousands of them. You'll probably even make some incredible, irreversible messes along the way. But rather than wasting time to criticize yourself or worry about what others think of you, focus on the task at hand. Take time to acknowledge what wasn't working, why it wasn't working, and move on. It's as simple as that. Ultimately our biggest failures lead to our greatest successes. So in order for us to improve and grow as individuals as well as a society we must try to overcome this fear or else we'll never progress, and that's the real failure.

Comics and Big Data

2014-08-25 00:00:00

Iâve never been into comics or graphic novels. Theyâve always remained in my periphery, but I never took the time to be interested in them. I appreciated good illustration, but rarely watched animations (except for Disney and Pixar of course) and pretty much ruled out that I would never âgetâ the appeal of a comic book.

I took a data mining class last semester, and we discussed the importance of visual storytelling. I jotted down notes and took away a comprehensive understanding of design implications - keep colors relative and consistent, scale, got it, check.

Dietmar, my professor, had mentioned a book by Scott McCloud, Understanding Comics, and suggested looking to comics and film as an important metaphor for data visualization. Though I didnât pay much attention at the time, this notion stuck with me, and a few weeks ago I invested in that very book.

Comics are a brilliant demonstration of visualizations that show multivariate information. Interactions, emotions, time, and space are all present, concurrent, and in flux - using frames and transitions to move the reader from one thought to the next. Comics pay attention to the readability of a story, by piecing together "juxtaposed images in deliberate sequence." (McCloud, Understanding Comics) Unlike film, however, the static nature of comics leaves room for creative challenges balancing those variables simultaneously, especially the evolution of time.

A series of information graphics is subject to the same dimensional considerations. Data Visualization is a balance of data analytics, visual representations, and a narration which provides a context for each investigation. Designing complex data to be comprehensive, interactive, and inviting is quite a challenge. While there are tools we can use to inspire visualization methods and techniques, there is much more to consider. There is an entire science behind visual cognition; why humans respond to certain characteristics faster than others (to be elaborated on at another point in time).

To incorporate storytelling into data visualization is to consider who we design for. Like comics, we must create an environment for the audience to become immersed, and the presentation of ideas shapes the interaction. The visual language we use, the way we sequence through visualizations, directly influences the legibility of the information. When we embrace the humanism of comprehension and perception, we design the experience to promote the success of the reader's ability to understand.

Let's design to agitate curiosity and engagement. How can we utilize visual storytelling to inspire research, critical analysis, and conversation? Harnessing the power of design, we can draw inspiration from comics, and present information in a way that considers how the mind observes and acquires ideas.

As it were, Iâm now devouring comics - making up for lost time. Iâve put my summer reading list on hold - to make time for books shared with me from fellow designers at DockYard, who maybe not so surprisingly, already have a deep appreciation and love for the brilliant medium that is comics.

Designing an Experience

2014-08-22 00:00:00

Over the years I have attended a lot of concerts, probably too many to count. Perhaps enough to make me deaf in the near future. One thing I've realized - I keep going back for the experience.

A good concert is one where Iâve stood witness to the construction of a musical composition, built piece by piece from each member of the band, materializing into a single living, breathing entity; emblematic of those who devoted the time and energy into building something bigger than themselves.

Good design should mirror this experience. It should be collaborative. It should be defiant and intelligent, original but cognisant of the past. It should set expectations for any and all future interactions. It should make the person say, ânow that was the best show Iâve ever been to.â

Because when it comes down to it, who would want the alternative? A bad performance is like something designed in Microsoft Word. It is obvious and unbalanced. It is âtoo loudâ and often âhas way too many drunk people.â

So control the stage while designing. Give people an experience that not only captures their attention, but gives them a reason to listen.

The most difficult position to hire for in tech right now

2014-08-06 00:00:00

The most difficult position to hire for in tech right now is not engineering. It isn't design. It is the hybrid position: the UX developer. Or the UX designer. Or the implementation developer. Or the CSS engineer.

This is how difficult it is, I have no idea what the "official" title of this position is. We seem to go back and forth every few weeks on what to call it. But, this role has become incredibly crucial to how we and most web companies operate.

Historically the responsibility for this position has fallen to engineering, or maybe design, depending upon how your team ran things. And it was the worst work. Cutting HTML, building terrible CSS. But today process and standards have fallen into place to make this role a legitimate one that people should build a career in.

Understanding how to optimize pages rendering, reduce CSS selector lookups, organizing stylesheets and markup files. This is just the start. Finding someone that can communicate between design and engineering is a challenge and the people I've found to naturally fit into this role excel at this. All of this before we ever start to talk about accessibility, browser compatibility, standards compliance, and responsive design.

However, there is barely anyone out there making a career in this role. Perhaps because it has been traditionally looked down upon. Or perhaps because engineering and design get the glory. The UX developer might think of one's self as the red-headed-stepchild.

We've taken a lot of efforts to bring the same quality we have in engineering and design here to our HTML & CSS. We've adopted BEM, SMACSS, and we're constantly looking to improve our process and the tools we use. Have other companies found similar issues with this growing field? I'd like to hear from some people.

(btw we're hiring)

Project Carpe Diem - "Game Plan"

2014-07-29 00:00:00

I have been exposed to many different work tracking/planning tools during my time as Project Manager. Early on it was tools like Excel, MS Project, IBM Rational. Later it was Jira, Kanban Boards, GitHub Issue Visualization Tools and physical PostIt Note boards. I would classify the former tools being more aligned with senior management's desire to be âWell Informedâ and the latter being more team centric and aligned with Iterative software development.

Working with both distributed and co-located teams has challenged me to devise appropriate work tracking strategies for these very different team contexts. However, one thing has remained the same to this day: I have never worked with a team that has determined they do not want to do any level of work tracking either in a high or low fidelity way regardless of the software development methodology being applied.

For purposes of this article I will be discussing some of the benefits we have seen in using a physical board with a couple of our co-located DockYard project teams. While I do maintain an appreciation of the big picture plan (aka High-Level Plan), I have come to embrace a concept that is advocated in the field of Exercise Science - something I have been reading up on lately. I am sure this is not the only field of study citing this approach but wanted to mention this one as top of mind. It is the notion of setting smaller objectives to take one (us) closer to a larger goal. In terms of software development a goal would be synonymous with a product feature. By no means is this a new frontier in development planning, it is simply an application of some already acknowledged concepts. What I believe is the slight twist is the setting of âDailyâ objectives in addition to full Iteration objectives. Consider this Project Carpe Diem!

At DockYard we are calling this approach âGame-Plan.â It covers the following four dimensions -

Features
Time (Days)
Tasks (Hrs)
Role on Team

At DockYard we harnesses the power of the daily standup meeting with low tech multi-colored Post-It Notes on a physical board in the office. During Iteration planning we discuss the next prioritized feature(s), lay out the relevant sub-features in agreeable sequence, define tasks for those sub-features across all the practice areas on our team. We set an estimation guardrail to have tasks be no smaller than half dayâs work and no larger than 2 - 3 days. We discuss dependencies, hand offs, opportunities to parallelize (Optimize) work across different team members. We start our iteration and reference the following board where we set/track daily team objectives -

At the conclusion of Iteration planning we take these tasks and convert them into GitHub issues aligned with a Milestone (Feature). However, we donât typically reference GH in our standup meetings but do see this as a very effective means to trace our code to the agreed tasks and enable a logical platform for code review.

Other fringe benefits we are afforded by our âGame-Planâ on a daily basis include the following-

Clearly show dependencies across the team
Helps us focus WIP (Work in Progress)
Allows team to understand implications if a task is taking longer than expected - adjust our plan
Allows us to suss out blockages that a team member might not reveal on their own
If a team member has capacity and someone is over capacity they can see where they can help out

You will also note we do maintain visibility into the âHigh-Level Planâ at all times to ensure we continue to be thoughtful of implications to the overall project objectives.

So Carpe Diem fellow Project Teams - Iâd love to hear if any teams out there are up to something similar or has learnings to share!

On Selling UX

2014-07-25 00:00:00

The Talk

People are talking about the difficulties of selling UX process to their boss, their clients, or their prospective clients. They're upset that they don't have the tools to create the caliber of experience others are building and it's all because a few people aren't buying into their process. You might have heard it or said it yourself that those in the way "just don't get UX". I know I've said it.

From this point of view, we appear to be looking at the problem as a matter of conversion; turning someone who isn't interested in change of process into someone who'll embrace it. It's a hard sell and, if you've ever experienced being hung up on while cold calling someone, you'll know that your chances of failure are much greater than your chance of conversion. But don't let that scare you.

Just like the design process itself, there are many ways to approach this problem. Success in your approach is a matter of understanding perspective and - dare I say - empathy for those in the critical path.

Definitions

We all have a habit of creating definitions in our minds of what other people do from what we hear around the office (or internet) and they're often pretty far off base. Those definitions become our foundation for what it means to be those other things: a designer, a developer, a product manager, a CEO. Those definitions, baseless or not, are used to judge the value of the things we do.

An example might be that most people realize they need a software developer to build an application but they may not understand the angles to be considered, the processes for discovering those angles, or the costs involved. It's easily misunderstood and can be a surprise for those outside of your industry.

Shared Values

We intend to create a great product and we understand there are many variations in process that could bring it to life. As creators, that process can often be poorly preconceived and unnecessarily limited before we get a hand in it. We have a few options from here to deliver our full value, and selling isn't one of them.

Aaron Scott from Leap gave a talk at UX Boston Conf about doing your best in getting to know those you're working with to help deliver a winning concept to the client. This approach holds true in more ways than just reaching a final design; it will help you gain the buy-in you need to perform at your full potential.

The stakeholder may understand what you do, need some experience of your process before understanding, or maybe they're not ready for it all. You need to know that they're acting off of their definitions, and it's not always their fault for having an incomplete picture. Just the same, it is equally important for us to understand them and their needs.

If they're not ready, convincing them otherwise will cause anxiety during the project and potentially cause issues of trust with you or future designers if things don't go well. Use your best judgment and tread lightly.

Collaboration

When your work is primarily visual it can be especially difficult to get the buy in you need. Most of the stakeholders will have had vision for their entire lives and trust themselves to judge what they feel is good and bad. They have their own tastes, their own definitions of what you do, and their own expectations of the process.

Our value as designers is best understood when demonstrated and this is your most powerful tool to gain buy in. Make room for them to be part of your design conversation. Problem solve and communicate with them like you might your design team. Let them breath the same air you are and replace your salesmanship with collaboration. Use this method instead of presentations and cold hard salesmanship or politics.

If you don't believe they're a good fit to collaborate with your design team, you may wish to pass on their project. Consider them a "client in training", give them your best advice, and set them free. Of course this isn't as easy when working in-house, where I would hope that if you've come to this conclusion you'd start looking for a more collaborative environment.

So stop selling UX. Look around, listen, ask questions, and help the client in training see further before you put a contract in front of them. Your process of gaining an understanding of the product, users, and their context will sell your expertise all on its own. If they're not ready, which is up to you to decide, set them free.

They may not always be a returning client, but they will respect you for being honest with them every step of the way - and that's a lifelong trust.

Making better repeat patterns

2014-07-23 00:00:00

I enjoy the look of hand-drawn things. And I use patterns a lot. But when the two are combined, the results are often disappointing. My least favorite thing is to see a pattern where identical copies of a hand drawn object were repeated without variation. The automatic repetition here is not appropriate to the shaky handmade look of the art.

The effect reminds me of Office circa 1995 (remember the classic marble and granite patterns?) or the obviously tiled walls in video game environments. In a 3D environment, a small size of the tile that causes this obvious tiled look is a necessity to conserve processing power.

Remember these?

Because I want to use hand drawn repeat patterns in my work, and it would be impractical to draw a thousand individual pieces to create the pattern, I experimented to determine exactly how many pieces I need to preserve the varied look, while being able to tile.

When I intentionally draw similar objects, I found that 15-30 copies will make a decent repeat pattern. I draw more than I need, then squint and get rid of a few that are too dissimilar. Once pieces are arranged on the pattern, there will always be a few that stick out and attract attention to the âseamsâ between your pattern tiles. To solve this, I leave only a small amount of variation in both shape and placement, and I repeat a few of the shapes several times in a single tile. This distracts from the âedgesâ of the tiles because repetition happens on two different rhythms.

Pattern element 2 is repeated several times within one unit.

Trying to get as far away as I can from the obvious square tiled look, I also experimented with other manners of tiling. Adobe Illustrator offers brick (offset), hexagonal and other options, but I eventually need to go back to a rectangular repeating unit because I want to use my pattern in browsers.

A rectangular repeat unit is used to make hexagonal tiles.

Here is one of the patterns I ended up making in this non-repeated style.

One unit of the repeat pattern.

I used this tree, circled, several times inside one repeating unit.

The pieces are aligned to the grid, of course, but they are hand drawn so sizes are slightly off. I intentionally spaced them slightly off the grid as well, but preserved the overall balanced appearance (just squint and fix whatever looks off - very scientific!)

And finally - here are the patterns!

Download the Illustrator file and use these patterns in any project. We only ask that you do not resell them. Enjoy!

Facebook Experiment

2014-07-18 00:00:00

I just read this thoughtful and refreshing article about Facebook's now infamous experiment on a large group of users. It outlines the ethical problems in running an experiment on unwilling participants, and how the scandal that followed damages the reputation of scientific research, which has ethical (not just legal) restrictions. It also reminds us that testing different versions of a product on users is nothing new, and we all seem OK with it as long as it stays in the realm of marketing.

The outrage over users' emotions being manipulated without consent reminds me of my own feeling of insecurity a few years ago, when personalized ads just started appearing on Facebook (somewhere around 2009?). Suddenly this free service, which I use for talking to friends, is listening in and pushing ads on me. Weird. I wanted to push them back.

Can I do anything to these algorithms that determine what ads I see? I wanted to experiment with them - to manipulate the ads by intentionally changing my information and posting fake content from my profile. I didn't keep any screenshots for evidence, so you'll just have to believe that some of it worked well.

At the time, I had to use Facebook at work quite a lot. As "the web design person" for a nonprofit organization, I posted to Facebook regularly and kept track of potentially abusive comments on the official page, so I had to be logged in and therefore exposed to the ads at the same time.

If you are a female - especially a female of an important purchasing age like me - you'll have many companies fighting for your attention. In your early 20s it's mostly personal purchases like shoes, clothes and makeup. A few years later, you qualify into the coveted "homemaker" target market. You supposedly start making decisions for a growing family about which groceries, appliances and brand of house paint to get - and companies really want your attention.

I was getting tired of the keywords and browsing history from my personal life following me around at work with supposedly relevant shopping ads, so I tried to confuse Facebook.

First I tried posting fake announcements of a tropical vacation and labeling some of my photos with far-away locations, but the ads didn't change much. I would see the occasional 50% off ad for brand name luggage, but nothing drastic. Many of my Facebook friends were confused, including a few coworkers. ("A three week vacation? What about my report?")

Next, I changed my gender to male. I loved the ads that I got in return. Suddenly there were no glitter shoes, no 75% off designer dresses, no engagement rings. Instead I saw "finish your computer science degree", high quality leather goods, and website hosting ads. I had not changed anything else about my behavior. The same keywords and likes give a girl and a boy version of me a completely different market persona. I enjoyed the boy version a lot more.

The third thing I changed was location. Facebook seemed to save different location privacy settings on desktop and in the browser, and defaulted back to showing my location once in a while. I was not happy to reveal my exact location with each post. It just seemed too invasive. On top of that, Facebook started mining my friends' location settings to determine mine whether I wanted to reveal it or not. It seemed easier to claim a false location than to keep fighting for it to remain blank. I set my hometown and current location to North Pole, Alaska.

The ads felt a bit more brawny on top of my previous change to "male". Some offers of rugged hiking boots (I actually buy hiking boots!) and tactical something or other. On the downside, one real life friend later said she was confused by the North Pole location.

Since I tried those interventions, Facebook algorithms have of course advanced, and the simple gender setting change today might not produce a significant change in ads. But it felt rewarding to kick back at the marketing machine, and to sometimes get results. I am a web designer, so I have to be a user of web things as well as a maker. I do not think I will be quitting Facebook this week, or next. But I enjoy running experiments back on it.

As a user, I was able to influence my ads. As a designer, I remain skeptical of user declared content. For example, if I had access to the kind of data Facebook has on most users, and wanted to target a person of a specific age and gender, I would consider their behavior instead of relying on one setting. I would look to confirm their gender, relationship status and age settings with specific keywords or themes in their posts and things they reacted to.

We should make sure our products do not break in "weird" cases (for example, when user settings and behavior seemingly contradict each other), and remain aware of the assumptions we make in the design process.

Design as Conversation

2014-07-18 00:00:00

Our understanding of design is perpetually in flux. Over the years design has transitioned from print and typography to web design, communication design to interaction design, user experience design to information design and design thinking. The space of design expands to encapsulate all these areas, while simultaneously formalizing specialized methodologies.

Design is a process; it no longer refers only to static artifacts or visualizations. Design is a craft as much as it is a way of thinking and interacting.

At DockYard, the design and development teams work closely together in an open dialogue, problem solving and giving real time feedback. Functionality and usability are built to work with one another, and it is this exchange of ideas, the conversation, that allows for the success of this interdisciplinary collaboration. There is no hierarchy of thought; each person brings personal experience and skill that contributes to a richer shared understanding. Many in the design world have begun to formalize this process - identifying these as environments for âinnovationâ.

The success of design, however, doesnât lie in the adherence of these systems. As much as we may reflect on the process of design - it remains a real time activity. Visual design, UI/UX considerations, and software engineering are all skills that come second to the ability for a team to work together. Through conversation, articulation, and modeling, we design the way in which we confront social complexities and wicked problems that exist as a result of differing perspectives. DockYardâs internal process is sensitive to these considerations, but doesnât attempt to formalize its methodology, as problem solving is unique to each individual circumstance.

The static, active, and meta states of design exist simultaneously layered within one another. When we invest in understanding one another, we truly embody what it means to design for experience, interaction, perception, emotion, and cognition. To âdesign the process of designâ is simply to be curious, present and engaged in all that we do.

Richard Wurmanâs explicit philosophy resonates with me a great deal. His approach to life is a demand to embrace a lack of understanding; a mentality that allows you to ask questions, to start at the beginning. It liberates you to say "I don't know what you mean" or "I don't know much about that" - something we are unfortunately as a society not encouraged to do - much to the detriment of learning and individual understanding. These fears exist in work environments, classrooms, within relationships - we so often are made to feel inadequate if our understanding doesn't match another's (or our own) expectations.

The collaborative nature of design reacts against these pressures. We each bring unique understanding, but it is our humility, interest in others and in experience, and the value we place in the exchange of ideas that makes design a powerful thing.

Ember Macros for DRY and Testable Code

2014-06-27 00:00:00

Intro

This post in going to explore the idea of writing your own Ember macros as a strategy for DRYing up and creating more modular Ember code. As you'll see, besides the maintainability and flexibility benefits gained by DRYing up and decoupling code, isolated code is significantly easier to test. We'll be using a sample application to illustrate refactoring some code into a macro.

What is a Computed Property Macro?

A computed property macro can really be thought of as a function that returns the definition of a computed property. Essentially, we are creating a function that will define computed properties for us. They look something like this:

  
  // Defining a computed property macro
function greeting(dependentKey, greeting) {
  return Ember.computed(dependentKey, function() {
    return greeting + ', ' + dependentKey;
  });
}

// Consuming a computed property macro
var Greeter = Ember.Object.extend({
  user: null,
  englishGreeting: greeting('user', 'Hello'),
  spanishGreeting: greeting('user', 'Hola')
});

var concierge = Greeter.create({ user: 'Narwin' });
concierge.get('englishGreeting') // => 'Hello, Narwin'
concierge.get('spanishGreeting') // => 'Hola, Narwin'

concierge.set('user', 'Boomer');
concierge.get('englishGreeting') // => 'Hello, Boomer'
concierge.get('spanishGreeting') // => 'Hola, Boomer'

So, why not just use a standard computed property? Macros give us the ability to take common chunks of functionality and share them throughout our code, allowing us to avoid re-writing the logic every time we need it.

Ember provides us with a bunch of useful computed macros right out of the box. If you're not familiar with them, you should definitely check them out.

Now that we've covered our bases, lets move on to the sample app.

Sample App

The goal of our sample application is to track financial transactions and to provide an overview of income and expenses for a given time frame. Our app has a Month model which has many transactions. A Month also has incomeTransactions (transactions with positive amounts) and expenseTransactions (transactions with negative amounts). Below are tests and code for our Month and Transaction models.

app/models/month.js

  
  var hasMany = DS.hasMany;
var filter = Ember.computed.filter;

export default DS.Model.extend({
  transactions: hasMany('transaction'),

  incomeTransactions: filter('transactions', function(transaction) {
      // Grab all transactions with a positive amount.
      return transaction.get('amount') > 0;
    }
  ),

  expenseTransactions: filter('transactions', function(transaction) {
      // Grab all transactions with a negative amount.
      return transaction.get('amount') < 0;
    }
  )
});

tests/unit/models/month-test.js

  
  import { test, moduleForModel } from 'ember-qunit';

var store, month, transactions, tran1, tran2, tran3, tran4;

moduleForModel('month', 'Unit - Month Model', {
  needs: ['model:transaction'],

  setup: function(container) {
    store = container.lookup('store:main');

    month = this.subject({
      name: 'June'
    });

    Ember.run(function() {
      tran1 = store.createRecord('transaction', { amount: 100 });
      tran2 = store.createRecord('transaction', { amount: 200 });
      tran3 = store.createRecord('transaction', { amount: -300 });
      tran4 = store.createRecord('transaction', { amount: -400 });

      transactions = [tran1, tran2, tran3, tran4];

      month.get('transactions').addObjects(transactions);
    });
  }
});

test('incomeTransactions returns positive transactions', function() {
  expect(1);

  var results = month.get('incomeTransactions');

  deepEqual(results, [tran1, tran2]);
});

test('expenseTransactions returns negative transactions', function() {
  expect(1);

  var results = month.get('expenseTransactions');

  deepEqual(results, [tran3, tran4]);
});

app/models/transaction.js

  
  var attr = DS.attr;

export default DS.Model.extend({
  amount: attr('number')
});

The month controller will handle computing the incomeTotal and expenseTotal for the month.

app/controllers/month.js

  
  var computed = Ember.computed;

export default Ember.ObjectController.extend({
  incomeTotal: computed('incomeTransactions.[]', function() {
    // Get the amount for each transaction in incomeTransactions.
    var amounts = this.get('incomeTransactions').mapBy('amount');

    // Sum the amounts
    return amounts.reduce(function(previousValue, currentValue) {
      return previousValue += currentValue;
    }, 0);
  }),

  expenseTotal: computed('expenseTransactions.[]', function() {
    // Get the amount for each transaction in expenseTransactions.
    var amounts = this.get('expenseTransactions').mapBy('amount');

    // Sum the amounts
    return amounts.reduce(function(previousValue, currentValue) {
      return previousValue += currentValue;
    }, 0);
  })
});

tests/unit/controllers/month-test.js

  
  import { test, moduleFor } from 'ember-qunit';

var set = Ember.set;

var monthController, incomeTransactions, expenseTransactions;

moduleFor('controller:month', 'Unit - Month Controller', {
  setup: function() {
    incomeTransactions = [
      { amount: 100 },
      { amount: 200 }
    ];

    expenseTransactions = [
      { amount: -300 },
      { amount: -400 }
    ];

    monthController = this.subject({
      incomeTransactions: incomeTransactions,
      expenseTransactions: expenseTransactions
    });
  }
});

test('incomeTotal returns the total of all incomeTransactions', function() {
  expect(1);

  var result = monthController.get('incomeTotal');

  equal(result, 300);
});

test('incomeTotal recomputes when an incomeTransaction is added', function() {
  expect(1);

  var newTransaction = { amount: 500 };

  monthController.get('incomeTransactions').addObject(newTransaction);

  var result = monthController.get('incomeTotal');

  equal(result, 800);
});

test('expenseTotal returns the total of all expenseTransactions', function() {
  expect(1);

  var result = monthController.get('expenseTotal');

  equal(result, -700);
});

test('expenseTotal recomputes when an expenseTransaction is added', function() {
  expect(1);

  var newTransaction = { amount: -600 };

  monthController.get('expenseTransactions').addObject(newTransaction);

  var result = monthController.get('expenseTotal');

  equal(result, -1300);
});

If your spidey senses are tingling, they should be. There is a lot of duplication going on in above code. In fact, the only difference between incomeTotal and expenseTotal is which set of transactions they are working with (incomeTransactions or expenseTransactions). Similarly, the only difference between incomeTransactions and expenseTransactions is whether the amount is a positive or negative number. Let's write a couple of macros to DRY up this code.

Creating custom Ember Macros

Both incomeTotal and expenseTotal have almost exactly the same logic. The goal of each is to take an array of objects and return the sum of a specific property on each object. Let's create a sumBy macro with the goal of being able to write something like: sumBy('array', 'property').

app/utils/sum-by.js

  
  export default function(collection, property) {
  return Ember.reduceComputed(collection, {
    initialValue: 0.0,

    addedItem: function(accumulatedValue, item){
      return accumulatedValue + Ember.get(item, property);
    },

    removedItem: function(accumulatedValue, item){
      return accumulatedValue - Ember.get(item, property);
    }
  });
}

tests/utils/sum-by.js

  
  import { test } from 'ember-qunit';
import sumBy from '../../../utils/sum-by';

var set = Ember.set;

var bankAccount, transactions, tran1, tran2, tran3, tran4;

module('Unit - SumBy', {
  setup: function() {
    tran1 = { amount: 1 };
    tran2 = { amount: 2 };
    tran3 = { amount: 3 };
    tran4 = { amount: -4 };

    transactions = [tran1, tran2, tran3, tran4];

    bankAccount = Ember.Object.extend({
      transactions: transactions,
      totalAmount: sumBy('transactions', 'amount')
    }).create();
  }
});

test('returns the sum of property for all objects in collection', function() {
  expect(1);
  var actual = bankAccount.get('totalAmount');

  deepEqual(actual, 2);
});

test('recomputes when a new object is added to the collection', function() {
  expect(2);
  deepEqual(bankAccount.get('totalAmount'), 2, 'precondition');

  var newTrans = { amount: 10 };

  bankAccount.get('transactions').addObject(newTrans);

  var actual = bankAccount.get('totalAmount');

  deepEqual(actual, 12);
});

incomeTransactions and expenseTransactions could also use some DRYing up. The only difference between the two is whether they are filtering by positive of negative numbers. Let's write a filterBySign macro with the goal of being able to write something like: filterBySign('array', 'property', '+').

app/utils/filter-by-sign.js

  
  var get = Ember.get;
var filter = Ember.computed.filter;

export default function(collection, property, sign) {
  return filter(collection, function(object) {
    return (sign + 1) * get(object, property) > 0;
  });
}

tests/unit/utils/filter-by-sign-test.js

  
  import { test } from 'ember-qunit';
import filterBySign from '../../../utils/filter-by-sign';

var bankAccount, transactions, tran1, tran2, tran3, tran4;

module('Unit - filterBySign', {
  setup: function() {
    tran1 = { amount: 1 };
    tran2 = { amount: 2 };
    tran3 = { amount: -3 };
    tran4 = { amount: -4 };

    transactions = [tran1, tran2, tran3, tran4];

    bankAccount = Ember.Object.extend({
      transactions: transactions,
      positiveTransactions: filterBySign('transactions', 'amount', '+'),
      negativeTransactions: filterBySign('transactions', 'amount', '-')
    }).create();
  }
});

test("'+' returns all objects with positive property values", function() {
  expect(1);
  var actual = bankAccount.get('positiveTransactions');
  var expected = [tran1, tran2];

  deepEqual(actual, expected);
});

test("'-' returns all objects with negative property values", function() {
  expect(1);
  var actual = bankAccount.get('negativeTransactions');
  var expected = [tran3, tran4];

  deepEqual(actual, expected);
});

test('recomputes when a new object is added to the dependent array',
function() {
  expect(2);
  deepEqual(bankAccount.get('positiveTransactions'), [tran1, tran2]);

  var newTrans = { amount: 1000 };
  bankAccount.get('transactions').addObject(newTrans);

  var actual = bankAccount.get('positiveTransactions');
  var expected = [tran1, tran2, newTrans];

  deepEqual(actual, expected);
});

When reading through the tests for filterBySign, note how much easier the setup is compared to our original tests for the same functionality on the Month model. Because we're testing the code in isolation, we're able to use POJOs and arrays to test our code. This allows us to avoid having to work around the Month model's relationships, creating records with the store and wrapping our setup code in an Ember.run to handle async behavior. Much nicer!

Refactoring the Month Model and Controller

We can now refactor our month model and controller to use our new macros.

app/model/month.js

  
  import filterBySign from '../utils/filter-by-sign';

var hasMany = DS.hasMany;

export default DS.Model.extend({
  transactions: hasMany('transaction'),

  incomeTransactions: filterBySign('transactions', 'amount', '+'),
  expenseTransactions: filterBySign('transactions', 'amount', '-')
});

app/controllers/month.js

  
  import sumBy from '../utils/sum-by';

export default Ember.ObjectController.extend({
  incomeTotal: sumBy('incomeTransactions', 'amount'),
  expenseTotal: sumBy('expenseTransactions', 'amount')
});

The refactored model and controller are nice and concise while still maintaining their readability. We can now delete our old unit tests on our Month model and controller as they now overlap with our macro tests. The net result is trimming down the code we have to maintain by about half.

If you're thinking about writing a macro or just want to see what other macros are out there, check out ember-cpm. It's a library of non-core macros that you can plug in to you Ember app. If you can't find what you're looking for there, take a shot at writing your own macro and send in a pull request to share it with the community!

Introducing Ember CLI Addons

2014-06-24 00:00:00

Distribution of reusable Ember.js libraries has been a pain point for quite a while. During application development we have frequently wished for a silver bullet for the sharing of concepts/code from one project to another.

Ember CLI has given us the opportunity to set the conventions for sharing that we have been searching for.

Over the last few weeks we have been focusing our efforts on the Ember CLI Addon story, and current support the following scenarios out of the box:

Performing operations on the EmberApp created in the consuming applications Brocfile.js. The most common things this would be used to call app.import (see Ember CLI - Managing Dependencies for more details) or process the various options provided by the consuming application. Examples: ember-cli-pretender, emberFire, and ember-cli-ic-ajax
Adding preprocessors to the default registry. This allows us to use a custom preprocessor to handle our templates, JavaScript, and/or styles. Example: ember-cli-esnext
Providing a custom application tree to be merged with the consuming application. This allows you to distribute anything that might need to be imported in the consuming application; including components, templates, routes, mixins, helpers, etc. Example: ember-cli-super-number
Providing custom express middlewares. This allows for an addon to completely customize the development servers behaviors, making things like automated mock Ember Data API's actually possible. This is currently only available on master (will be available in 0.0.37 and higher).

One of the design goals that the current crop of example addons follow is that they can all be installed and used simply via:

  
  npm install --save-dev <package name>

Details

Discovery

Ember CLI detects the presence of an addon by inspecting each of your applications dependencies and searching their package.json files for the presence of ember-addon in the keywords section.

Creation

Once the available addons are detected, Ember CLI will require the addon. By default it will use standard Node.js require rules (see here for a breakdown), but you can provide a custom entry point by specifying a ember-addon-main property in your package.json.

Either way you go, during the various commands that cause a new build to be done (ember server, ember test, ember build, etc) Ember CLI will create a new instance of the class that your addon returns passing it the Project instance for the current project. The Project model has a few functions that might be useful to your addon. You can see a full list by inspecting the source, but to name a few:

require -- Lets you require files or packages from the consuming application.
config -- Returns the configuration for the provided environment.
resolve -- Looks up a file from the root of the project using standard Node require semantics, but with the projects root as the base directory.

Build Process Inclusion

When the consuming application's Brocfile.js is processed by Ember CLI to build/serve/etc the addon's included function is called passing the EmberApp instance. You can use this to access the options provided (for configuration of your addon for example).

Intra Build Hooks

There are a few other points in the build process that your addon can hook into via the treeFor function. treeFor is called to setup the final build output for a few specific points in the build process. The addons treeFor function will be called with an argument that signifies which tree is being asked for.

Currently, the following trees can be customized by the addon:

app -- The tree returned by your addon for the app tree will be merged with that of the application. This is an excellent place to add custom initializers for your addon, add routes/controllers/views/components/templates/etc (anything that goes in app/ really). For additional information read through the blog post describing how ember-cli-super-number was turned into an addon.
styles -- The tree returned by your addon for the styles tree will be merged with your applications styles (generally app/styles/).
vendor -- The tree returned by your addon for the vendor tree will be merged with your applications vendor tree (generally vendor/).

All of the trees returned by addons are merged into the corresponding tree in the application. The application's direct trees are always last so they will always override any files from an addon. This actually makes a wonderful place for application specific customization: your addon could provide a good default template, and the application can override by simply placing their own template in the same path.

Future

Many things are still planned for the "Addon Story" in Ember CLI. A few of them below:

Allow addons to specify preferred ordering (before or after another addon). Similar in concept (and stolen from) the Ember initializer ordering. This is implemented on master and will be included in 0.0.37.
Allow addons to provide a blueprintPaths function that will return addition paths for blueprints to be looked up. This will allow an addon to override internal blueprints or add their own.
Allow more than one preprocessor to be used at once. Currently, it is only possible to have a single preprocessor, but this is a limitation if you want both SCSS and plain CSS (for example).
Expose post-processed stages. This will allow for better customization of the final output which things like autoprefixer would be able to take advantage of.

Call To Arms

This API is still very fluid and not set in stone. We need as much feedback as possible to truly solidify things.

Goodbye Heroku

2014-06-23 00:00:00

I've been a Heroku user since the beginning. And I understand they have had their ups and downs but over the past 2 years the service has been degrading and today was the last straw for me. Allow me to elaborate.

Downtime

Today Heroku had a "Scheduled Maintenance at 2pm EST". First of all, this is just stupid. Don't schedule a maintenance period at 2pm EST for anything. That period of time has to be one of the most heavily trafficked timeslots on the web. Its an hour after everyone on the East Coast has come back from lunch. It is an hour before lunch on the West Coast. This, to me, demonstrates a lack of judgement on Heroku's part. I know the counter-argument is going to be "we've done plenty of other scheduled maintenances at 2pm EST without incident". My reply is that this counter-argument is bullshit. Just because you got away without problems previously doesn't mean they won't happen in the future. Things go wrong, people screw up. When Heroku has control over when those screwups occur and they choose to push that risk at 2pm EST that is a problem.

Reporting of Downtime

I am convinced their Status team just sits on Twitter all day and waits for enough people to bitch and complain that Heroku is down before they update the status page. I don't care what data they provide to the contrary. Why is the updated status page important? When our customers email us during our vacation pissed off that we are not around and we have nothing to show to them to prove that this is Heroku's fault and not ours, to me that status page being updated immediately before our customers discover on their own is very important.

Price

It has been heavily reported that AWS has cut their pricing quite a bit over the past few years. Yet, how many times has Heroku reduced its price? (Heroku resells AWS) To my knowledge zero. So everytime Amazon reduces EC2 pricing Heroku just pockets the difference and gives a "fuck you very much!" to all of its customers.

Fixes for All

The major downside to hosted devops is that when something goes wrong that affects everyone you usually have to wait until they make the fix for everyone before your app comes back up. What should probably be a 5 minute downtime at most turns into a 30 minute downtime at least.

Buildpacks

Buildpacks are just terrible.

Conclusion

I get that I'm ranting and I'm pretty pissed off. But mistakes like today's are completely avoidable yet Heroku chose to expose everyone to this increased risk for no good reason that I can see.

We will no longer be starting any new customers on Heroku. And we will recommend to our current customers to move off of Heroku. We're big fans of Digital Ocean so we're likely to land there as our preferred hosting service.

KAPOW! Writing prototypes with Framer

2014-06-23 00:00:00

I've finally used Framer on a client project and couldn't be happier with the result. I normally use InVision and highly recommend it, but Framer is the obvious choice when we need the experience to feel significantly more real.

Every tool has its pros and cons, however, so it won't always be the best choice for you.

Let me start with Framer's big con: you must write JavaScript to knit a prototype together. The code itself is very easy to learn, but understanding how the Framer script interacts with your PSD's groups and layer organization is like flying blind. With practice you can get past this and work gets much, much faster.

The one other con is that their documentation is made more for developers than designers. So if you're not used to digging into developer docs you will likely be overwhelmed and unsure what you're looking for. Looking elsewhere won't help you either, there doesn't seem to be much community around this (yet).

Someone with less coding experience will find Framer difficult and more intimidating than it has to be. I'd recommend dealing with the learning curve by practicing on a few side projects before you put anything important on the line (not that side projects aren't important).

Where Framer really shines bright: you won't have to verbalize (or make embarrassing gestures) for how your app should feel, because you define that with enormous control. Oddly enough, the biggest con is your ally here, as writing custom JavaScript is what makes this control possible.

Framer supports clicks and taps just the same, supports many animation options, is highly configurable, and runs very, very smoothly on all (of my) devices. I've tested it on iPhone, iPad, and a Mac. Because of this control and variability of use, your prototypes will feel much more real to the user in a testing scenario. This is especially good when your interactions help communicate state and position.

If you've used Framer before, let me know how you like it. There's only so much time in the world to play with prototyping tools, but my next experiment will be with Origami.

Bonus!

While doing user testing sessions, you may want the testee to work on the actual device. To do so you can use Anvil to create a local web address using Pow. This will give you an address (something like http://yourappname.youripaddress.xip.io/) that you may access on your device.

Making the DIY conference badges

2014-06-21 00:00:00

What are badges for, anyway? At any professional event with more than fifteen people, we wear some sort of name tag.

The current situation with badges:

If it's a smaller or low budget event, you get a shipping label and write your name with a sharpie, then stick to your shirt and hope it holds. (I always stick mine to a pant leg just because.)

A step up would be vinyl stickers or shipping labels with something like the conference name printed on them, but again attendees must write their name.

At the highest level of badge, you arrive an event and receive a fully branded badge on a colorful lanyard with your name and photo printed on both sides, to prevent you from lending your $800 conference pass to a friend.

Three things badges do best:

Prove that you've paid for your ticket
Help brand the event
Help you meet people

Our focus for the badges was mostly to help people meet and talk, and if we get to show off the Wicked Good Conferences brand - that's cool too. We did not rely on the badges for ticketing because the event is relatively small, and held in a single location. There were no repeated check-ins at the door or strangers walking in off the relatively low traffic street.

This allowed me the freedom to experiment with the badges. The only restriction was the budget; we wanted to make about 200 customizable name badges with a budget range of $20â$50. This is not a realistic budget for high quality "professionally" printed badges (decent custom lanyards alone are at least $1 each).

No printed names

We decided to skip printing people's names altogether, and ask them to write names instead. This also allowed people to put a twitter handle and other useful information on the badges, and be funny with them. I am an introvert, so I appreciate any excuse to start a conversation. Stickers, twitter handles and stick figures on badges helped make interaction easier.

No printed lanyards

Custom printed lanyards, in the quality we wanted, were way above our budget. Instead, we tried a few DIY ideas: string, ribbon, rope and strips of jersey fabric. The fabric turned out to be the most comfortable to wear. Knit jersey ("tee-shirt") fabric will roll into a soft string if you cut 1" wide strips and stretch them out. We used about 2.5 yards of 52" wide fabric to make the 200 strips. We could make the strips a half to a third of the width of the fabric, depending on how long we wanted the strips to be.

An added benefit of using fabric is a much better selection of colors compared to lanyards. We managed to get a near-perfect match to our attendee shirts!

Actually, no printed anything

To make a color impression at a low cost we used a rubber stamp with a purple ink pad. We did not commit to placing any sponsor logos on the badges, so I had complete freedom with this design. We ordered a rubber stamp of the Wicked Good Conferences logo by itself so we can reuse it for the next conferences. To make the badge itself, we stamped and punched a hole in standard 3Ã5" index cards.

Budget breakdown

1Ã2" Custom rubber stamp": $12 + shipping
Purple ink pad: $3.50
Index cards, 2 packs of 100: ~$7
Single hole punch: ~$5
Jersey fabric (we already had it, but if you need to buy it cost about $5/yard): free or $15

Lessons learned

The badges felt about right for the event, not too formal, not too shabby. Some lanyards turned out a bit short, but people were creative with placement, wearing them not only around the neck but on a sleeve, on the hat, tying them to the belt loop or a shirt button, and even wearing as a soft choker. Next time around we can also experiment with other paper types and have the paper cut to size, to allow for a sturdier badge in a wider range of colors.

Were you at WGE? Let us know what you thought of the DIY badges!

Swift and JavaScript

2014-06-15 00:00:00

You might have already heard about a new language from Apple, Swift. If you haven't, make sure to check it out. This is the language that is going to replace Objective-C in the future.

So why should a JavaScript developer be excited about a language like Swift? Because semicolons are optional in Swift, too.

Variables

Let's declare a variable in JavaScript:

  
  var country = 'Argentina';

Here's how the same declaration looks like in Swift:

  
  var country: String = "Argentina";

However, the same statement can be rewritten as such:

  
  var country = "Argentina"; // inferred as String

Swift uses type inference. It looks on the right hand side of the assignment to figure out the type of the variable.

Swift is type safe language. It performs type checks during compilation time and informs you if there are any type mismatch errors. Unlike in JavaScript, that means that after you defined country variable and its type was inferred to be String, you can't re-assign with another type:

  
  country = 2; // Cannot convert the expression's type to type 'String'

Constants

JavaScript doesn't have a concept of a constant. All "constants" are just variables (typically in the outer scope). You can "freeze" the object using Object.freeze() to prevent new properties to be added and existing properties to be removed.

The next version of JavaScript is going to introduce const keyword and will support constants:

  
  const y = 10; // Note that you need to specift the value of the constant
y = 20;       // SyntaxError: Assignment to constant variable

If you want to define a constant in Swift, you will use let keyword:

  
  let bestCity = "Boston";
bestCity = "Cape Town"; // Cannot assign to 'let' value 'bestCity'

// Swift allows you to use underscore as a delimiter
// to improve readability of your code
let oneMillion = 1_000_000;

Tuples

So what is a tuple? TL;DR it's an ordered list of things.

You can think of a tuple as if it's an object:

  
  var villain = {
  name:     'Magneto',
  realName: 'Max Eisenhardt',
  powers:   ['Magnetic flight', 'Magnetic force fields']
};

villain.name; // => 'Magneto'

In Swift, the declaration of a tuple will look like this:

  
  let villain = (
  name:     "Magneto",
  realName: "Max Eisenhardt",
  powers:   ["Magnetic flight", "Magnetic force fields"]
);

villain.name; // => "Magneto"
villain.1;    // => "Max Eisenhardt"
villain.2;    // => [...]

Tuples are useful when you want to return multiple values from a function as a single compound value (that is exactly what we do so often in JavaScript).

Arrays and Dictionaries

Definining an array or a dictionary looks very similar.

In JavaScript:

  
  var names = ['Alex', 'Rob', 'Dan'];
var ages  = { 'Alex': 13, 'Rob': 5, 'Dan': 4 };

names[0];     // => 'Alex'
ages['Alex']; // => 13

In Swift:

  
  var names = ["Alex", "Rob", "Dan"];
var ages  = ["Alex": 13, "Rob": 5, "Dan": 4];

names[0];     // => "Alex"
ages["Alex"]; // 13

Generics

In a very generic, hand wavy terms Generics introduce type safety and reusability of the code. They're frequently used in classes and methods that operate on them.

To illustrate what Generics are, let's implement a Queue.

  
  function Queue() {
  this._queue = [];
}

Queue.prototype.enqueue = function(item) {
  this._queue.push(item);
}

Queue.prototype.dequeue = function() {
 return this._queue.shift();
}

var queue = new Queue();

queue.enqueue(2);
queue.enqueue('3');
queue.enqueue(0.5);

Now wasn't that easy, eh?

Note, that you don't have to care about types in JavaScript that much. You just enqueue a value of any type and you're all set.

Swift is different. You can't push objects of different types onto the array.

Here's a Queue class for Integer values:

  
  class Queue {
  var _queue = Int[]();

  func enqueue(item: Int) {
    _queue.append(item);
  }

  func dequeue() -> Int {
    return _queue.removeAtIndex(0);
  }
}

var queue = Queue();

queue.enqueue(2);
queue.enqueue(3);
queue.enqueue(4);
queue.enqueue("4"); // Cannot convert the expression's type to type 'Int'

What if you want to create a Queue class for String values? You're going to have copy implementation of Queue<Int> class and replace Int with String. A lot of code duplication. Here's where Generics shine.

  
  class Queue<T> {
  var _queue = T[]();

  func enqueue(item: T) {
    _queue.append(item);
  }

  func dequeue() -> T {
    return _queue.removeAtIndex(0);
  }
}

var intQueue    = Queue<Int>();
var stringQueue = Queue<String>();

intQueue.enqueue(2);
intQueue.enqueue(3);
intQueue.enqueue(4);

stringQueue.enqueue("2");
stringQueue.enqueue("3");
stringQueue.enqueue("4");

Now you can create Queue of the different types with just one Queue implementation.

Conclusion

Swift is a step in the right direction in my opinion. They lowered the "language ramp up" time by simplifying Objective-C syntax quite a bit without damaging the power of the language. I feel like it looks really compelling to JavaScript developers.

The Process Paradox

2014-06-06 00:00:00

If it feels like process, it is not workingâ¦ It should feel like a logical means to achieve an end.

For much of my career as a Project Manager I have been inundated with software development process, theories, techniques, methodologies and related tools - which by association has trickled into the teams I have worked with. Over time I have observed team members feeling the frustration that âProcessâ can bring to a project when it is applied in a theoretical way vs. a practical way. Have you ever facilitated a planning meeting while team members glaze over and bury their heads into their laptops? To all my Project Management brethren - if this is something you are observing in your teams, donât accept this reality; realize that your process "is not working".

The art of project management is not dictating process but finding practices that align with the teamâs needs and context. For purposes of this blog post these are the âlogical meansâ I refer to in my opening statement above. A little Scrum here, a little Waterfall there, and a sprinkle of Kanban might be the right recipe for a particular project - whereas it could be totally wrong for another.

In many ways this context is driven by the pyramid of constraints - cost/scope/time, which is project management 101. However, other contexts might be size of team, remote/co-located, green-field development, team member experience, criticality of deliverables to human life, number of stakeholders, thick/thin management hierarchy, complexity of business rules/logic, and many others which are industry specific.

One of my biggest gripes with the âAgileâ movement is that companies/teams are adopting variations of the methodology as a prescription to execute projects. I am pretty damn sure the pioneering thinkers who wrote the Agile Manifesto wanted teams to become more principled in thinking about the practices they chose to use vs. following the playbook blindly and not making sure it aligns with the project context.

It has been very affirming to know that engineers and designers in large and small companies loath process â Iâd say this is pretty universal. However, I have found that these same people are incredibly logical people who are willing to do something non-engineering/design related if they feel deep down it is a âlogical means to achieve an end.â I believe it is the project managerâs responsibility as a servant leader to make sure teams donât feel like process is holding them back but that it is helping them move forward.

What I love about being a Project Manager at DockYard is the diversity of the project contexts that come through our door. For me it is and has been a great way to experiment, mix, and match processes to find the right practices for a team/project context. I believe that DockYardâs acknowledgment of this reality allows us to better serve our clientsâ unique contexts. Not by accident - it is a very deliberate way to approach projects and one size never fits all.

Building an Ember App with Rails Part 4

2014-05-31 00:00:00

This is a four-part series: Part 1, Part 2, Part 3, Part 4

Before we get underway we need to update ember-data in our project to at least 1.0.0-beta.8. Open ember/bower.json and if you have any version less than 8 you'll need to update to at least 8. If you are already on 8 or higher you won't need to do anything.

Once you've made the change save the file and run bower install from the ember/ directory. If you are asked to choose between different versions of ember-data make sure you choose the correct one.

In this part we'll add Presentations to each of the Speaker pages. This means we'll have to add a relationship between two models.

In ember/tests/integration/speakers-page-test.js modify the test "Should list all speakers and number of presentations"

  
  // ember/tests/integration/speaker-page-test.js

test('Should list all speakers and number of presentations', function() {
  visit('/speakers').then(function(assert) {
    assert.equal(find('a:contains("Bugs Bunny (2)")').length, 1);
    assert.equal(find('a:contains("Wile E. Coyote (1)")').length, 1);
    assert.equal(find('a:contains("Yosemite Sam (3)")').length, 1);
  });
});

The number in the parentheses will represent the number of presentations that this speaker has given.

Next we need to modify our beforeEach function

  
  // ember/tests/integration/speaker-page-test.js

var speakers = [
  { id: 1, name: 'Bugs Bunny', presentation_ids: [1,2] },
  { id: 2, name: 'Wile E. Coyote', presentation_ids: [3] },
  { id: 3, name: 'Yosemite Sam', presentation_ids: [4,5,6] }
];

var presentations = [
  { id: 1, title: "What's up with Docs?", speaker_id: 1 },
  { id: 2, title: "Of course, you know, this means war.", speaker_id: 1 },
  { id: 3, title: "Getting the most from the Acme categlog.", speaker_id: 2 },
  { id: 4, title: "Shaaaad up!", speaker_id: 3 },
  { id: 5, title: "Ah hates rabbits.", speaker_id: 3 },
  { id: 6, title: "The Great horni-todes", speaker_id: 3 }
];

server = new Pretender(function() {
  this.get('/api/speakers', function(request) {
    return [200, {"Content-Type": "application/json"}, JSON.stringify({speakers: speakers, presentations: presentations})];
  });

  this.get('/api/speakers/:id', function(request) {
    var speaker = speakers.find(function(speaker) {
      if (speaker.id === parseInt(request.params.id, 10)) {
        return speaker;
      }
    });

    return [200, {"Content-Type": "application/json"}, JSON.stringify({speaker: speaker, presentations: presentations})];
  });
});

Completely replace the speakers variable that was previously there. The only change to the API stub is that presentations is being added to the payload. The JSON here is the style of JSON that ember-data expects to be emitted. We are returning a payload that includes all speakers and presentations. The speaker records include ids referencing the presentations associated.

We can now add the Presentation model to our Ember app:

  
  // ember/app/models/presentation.js
import DS from 'ember-data';

export default DS.Model.extend({
  title: DS.attr('string'),
  speaker: DS.belongsTo('speaker')
}); 

We've told ember-data to expect the Presentation model to belong to the Speaker model. Let's set the inverse relationship

  
  // ember/app/models/speaker.js
import DS from 'ember-data';

export default DS.Model.extend({
  name: DS.attr('string'),
  presentations: DS.hasMany('presentation')
});

Modifying our existing Speaker model to add to relationship to its many Presentation models.

Finally to make this tests green we need to change our template:

  
  // ember/app/templates/speakers/index.hbs

{{#each}}
 {{~#link-to 'speakers.show' this}}
   {{name}} ({{presentations.length}})
 {{~/link-to}}
{{/each}}

Notice that we we can call regular JavaScript properties like length on the association. There is also a slight change that I've made to the link-to. Adding ~ will tell Handlebars how to control whitespace.

At this point our new test should be green. Lets add another.

  
  // ember/tests/integration/speaker-page-test.js

test('Should list all presentations for a speaker', function(assert) {
  visit('/speakers/1').then(function(assert) {
    assert.equal(find('li:contains("What\'s up with Docs?")').length, 1);
    assert.equal(find('li:contains("Of course, you know, this means war.")').length, 1);
  });
});

This new test is asserting that when we visit a given speaker's page all of those speaker's presentations will be listed. We first need to add presentation data to the API stub (within our beforeEach function) for visiting a speaker page.

  
  // ember/tests/integration/speaker-page-test.js

this.get('/api/speakers/:id', function(request) {
  var speaker = speakers.find(function(speaker) {
    if (speaker.id === parseInt(request.params.id, 10)) {
      return speaker;
    }
  });

  var speakerPresentations = presentations.filter(function(presentation) {
    if (presentation.speaker_id === speaker.id) {
      return true;
    }
  });

  return [200, {"Content-Type": "application/json"}, JSON.stringify({speaker: speaker, presentations: speakerPresentations})];
});

This modification of the previously existing stub will build a new payload object that includes the speaker matching the id requested and all of the presentations specific to that speaker.

Tying up this test is easy now, we just modify the Speaker's show template:

  
  <h4>{{name}}</h4>

<h5>Presentations</h5>
<ul>
  {{#each presentations}}
    <li>{{title}}</li>
  {{/each}}
</ul>

Now that we have a green test suite with our mocked out API let's add the real Rails endpoint. We'll start by generating a new Presentation model. Change to the rails/ directory in your project and run rails generate model presentation title:string speaker_id:integer.

Next we'll generate the serializer: rails generate serializer presentation.

Let's expand upon the rails/db/seeds.rb file:

  
  # rails/db/seeds.rb

bugs = Speaker.create(name: 'Bug Bunny')
wile = Speaker.create(name: 'Wile E. Coyote')
sam  = Speaker.create(name: 'Yosemite Sam')

bugs.presentations.create(title: "What's up with Docs?")
bugs.presentations.create(title: "Of course, you know, this means war.")

wile.presentations.create(title: "Getting the most from the Acme categlog.")

sam.presentations.create(title: "Shaaaad up!")
sam.presentations.create(title: "Ah hates rabbits.")
sam.presentations.create(title: "The Great horni-todes")

Tell our Speaker model that there is a relationship to Presentation models:

  
  # rails/app/models/speaker.rb

class Speaker < ActiveRecord::Base
  has_many :presentations
end

Finally we need to modify the serializers.

  
  # rails/app/serializers/presentation_serializer.rb

class PresentationSerializer < ActiveModel::Serializer
  attributes :id, :title
end

  
  # rails/app/serializers/speaker_serializer.rb

class SpeakerSerializer < ActiveModel::Serializer
  embed :ids, include: true

  attributes :id, :name
  has_many :presentations
end

In the SpeakerSerializer we have instructed the serializer to include the associated Presentations.

Let's reset the database and re-seed rake db:drop db:create db:migrate db:seed

Make sure you are running your Ember server with the proxy enabled: ember server --proxy http://localhost:3000

Now you can hit your application and you should have a all of the necessary data.

Check out the actual code for this part

Avoid Rails When Generating JSON responses with PostgreSQL

2014-05-27 00:00:00

What if I told you that you could generate the following JSON response in PostgreSQL?

  
  {
  "tags":[
    {"id":1,"name":"Tag #0","note_id":1},
    {"id":1001,"name":"Tag #1000","note_id":1},
    {"id":2001,"name":"Tag #2000","note_id":1},
    ...
  ],
  "notes":[
    {
      "id":1,
      "title":"Note #0",
      "content":"Lorem ipsum...",
      "tag_ids":[9001,8001,7001,6001,5001,4001,3001,2001,1001,1]
    },
    {
      "id":2,
      "title":"Note #1",
      "content":"Lorem ipsum...",
      "tag_ids":[9002,8002,7002,6002,5002,4002,3002,2002,1002,2]
    }
  ]
}

What if I told you that it is over 10X faster than plain ActiveModel::Serializers for small data sets, and 160X faster for larger data sets?

Typically when you have an API serving up JSON responses, your web framework serializes your data after retrieving it with its ORM. We'll talk about Rails specifically in this article, but this will generally apply to most frameworks. So the typical Rails request will roughly follow this flow (I am purposely brushing over some parts of the request response cycle):

Rails receives the JSON request from the browser/client
Rails will apply some business logic and craft a query via ActiveRecord
ActiveRecord serializes its query and sends the query to PostgreSQL
PostgreSQL will compile the result set and serializes the records in its protocol format
ActiveRecord deserializes the records into a set of rows object
ActiveRecord will convert the set of rows into a set of model object instances
Rails will convert the set of models objects into a JSON string
Rails will send the JSON string down to the browser

Most of the time in this response cycle is spent in steps 6 and 7. Rails has to deserialize one format, then store that deserialized content in memory just to serialize it in a different format. Since PostgreSQL supports JSON responses, we can use its JSON functions to serialized our result set. That JSON response will still be serialized in PostgreSQL's protocol format, but ActiveRecord can deserialize it as a single string object, instead of a set of objects which it then converts and reserializes. We end up having this response cycle instead:

Rails receives the JSON request from the browser/client
Rails will apply some business logic and craft a query via ActiveRecord
ActiveRecord serializes its query and sends the query to PostgreSQL
PostgreSQL will compile the result set, serializes it as JSON then serializes the JSON in its protocol format
ActiveRecord deserializes the protocal format into a single JSON string
Rails will send the JSON string down to the browser

We are only removing 2 steps, but it is the bulk of the time spent generating the response. We are also limiting the number of ruby objects created, so this reduces memory usage and time spent garbage collecting short lived Ruby objects used only for JSONification.

What Do We Gain by Generating Massive Queries for PostgreSQL

It takes a lot of work to tell PostgreSQL to generate a specific JSON object; what exactly does that buy us? By doing all this in PostgreSQL, we avoid using CPU cycles and memory on our web server. I've done some very naive and basic testing with a new, unoptimized Rails project, and a database of 1000 notes, each have 10 unique tags, totalling 10000 tags. When retrieving all 11000 records with Rails and ActiveModel::Serializers, it took roughly 9 seconds to generate the request. Most of the time was spent in the View generating the JSON object in memory, with 657 milliseconds in ActiveRecord, which (I think until someone tells me otherwise) includes creating all the model instances.

When we apply the PostgreSQL technique outlined later in this article to the same result set, the response only takes 72 milliseconds for the first request. If we rerun this same request, PostgreSQL caching kicks in and the response time is 54 milliseconds. That is a ~160X throughput increase when we use PostgreSQL to generate JSON payloads.

The above numbers are a bit skewed by the size of this test payload. 11000 objects would be completely crazy to present to an end user. If we pare back our result set 10 notes and 100 tags, the first and second response times for Ruby side JSONification are 187 and 118 milliseconds. When using PostgreSQL to generate our JSON payload, the response times are 92 and 12 milliseconds. That is a 2X/10X increase. By utilizing PostgreSQL, we can increase our applications' response times and throughput.

Announce PostgresExt-Serializers

To utilize PostgreSQL, we have to generate a fairly complex query manually. That is, until you include the PostgresExt-Serializers gem into the project. PostgresExt-Serializers (PES) monkey patches ActiveModel::Serializers (AMS), and anywhere an ActiveRecord::Relation is serialized by AMS, PES will take over and push the work to PostgreSQL. I wanted to use the awesome work of AMS's DSL for generating JSON schemas without having to duplicate that work. I am finding some pain points in terms of extracting the information I need to generate the SQL query from AMS, but right now the code for PES is very immature, hence the 0.0.1 release.

Nitty-Gritty Details About How it All Works: Massive PostgreSQL Queries

Let's say we have an Ember application that we are generating the JSON request for. The Ember app wants the list of notes, along with the tags associated with the notes, and we will side load the tags. Side loading allows you to specify the ids of the tags on the note, and then include a list of tags, which will be used to instantiate the tags on the note. The benefit of side loading is that it allows you to save bandwidth by use tag ids and an array of de-duplicated tags, instead of embedding the duplicate tags objects under the notes, where you would have to duplicate the tag objects. We only want notes with id < 40, which is arbitrary in this example, but, as we will see, has implications on the query we need to execute.

Here is the whole query we need to generate the JSON required, which is also the example JSON at the beginning of this article:

  
  -- Note Ids
WITH notes_ids AS (
  SELECT id
  FROM "notes"
  WHERE "notes"."id" < 40
),
-- Tag Ids grouped by note id
tag_ids_by_notes AS (
  SELECT "tags"."note_id", array_agg("tags"."id") AS tag_ids
  FROM "tags"
  GROUP BY "tags"."note_id"
  HAVING "tags"."note_id" IN (
    SELECT "notes_ids"."id"
    FROM "notes_ids"
  )
),
-- Tag records
tags_attributes_filter AS (
  SELECT "tags"."id", "tags"."name", "tags"."note_id"
  FROM "tags"
  WHERE "tags"."note_id" IN (
    SELECT "notes_ids"."id"
    FROM "notes_ids"
  )
),
-- Tag records as a JSON array
tags_as_json_array AS (
  SELECT array_to_json(array_agg(row_to_json(tags_attributes_filter)))
AS tags, 1 AS match
  FROM "tags_attributes_filter"
),
-- Note records
notes_attributes_filter AS (
  SELECT "notes"."id", "notes"."content", "notes"."name",
coalesce("tag_ids_by_notes"."tag_ids", '{}'::int[]) AS tag_ids
  FROM "notes"
  LEFT OUTER JOIN "tag_ids_by_notes"
  ON "notes"."id" = "tag_ids_by_notes"."note_id"
  WHERE "notes"."id" < 40
),
-- Note records as a JSON array
notes_as_json_array AS (
  SELECT array_to_json(array_agg(row_to_json(notes_attributes_filter)))
AS notes, 1 AS match
  FROM "notes_attributes_filter"
),
-- Notes and tags together as one JSON object
jsons AS (
  SELECT "tags_as_json_array"."tags", "notes_as_json_array"."notes"
  FROM "tags_as_json_array"
  INNER JOIN "notes_as_json_array"
  ON "tags_as_json_array"."match" = "notes_as_json_array"."match"
)
SELECT row_to_json(jsons) FROM "jsons";

Let's break it down. You'll notice that I am making use of Common Table Expressions (CTEs). CTEs allow you to use temporary table definitions in queries instead of embedding the subqueries directly in your query.

Gathering our Note Ids

The first important step is getting the note ids of our final result set, which we do with:

  
  WITH notes_ids AS (
  SELECT id
  FROM "notes"
  WHERE "notes"."id" < 40
),

We are creating a CTE that represents the ids for our notes, we'll be using this extensively to generate our tag related records.

Getting Tag Ids Grouped by Note Ids

From our note_ids, we can assemble a list of tag ids grouped by notes. This will be used to create the tag_ids attribute on the notes later on.

  
  tag_ids_by_notes AS (
  SELECT "tags"."note_id", array_agg("tags"."id") AS tag_ids
  FROM "tags"
  GROUP BY "tags"."note_id"
  HAVING "tags"."note_id" IN (
    SELECT "notes_ids"."id"
    FROM "notes_ids"
  )
),

Our projection is the note_id, plus an array_agg of the id of the tags in our grouping. array_agg aggregates the group into an array. This projection will return the following:

  
  note_id | tag_ids
=================
      1 | [1,2]
      2 | [1,3]

In this example, the tags belong_to a note, so we are retrieving this data from the tags table. If this was a many-to-many relation, this query would execute against the join table (i.e. notes_tags).

We group our tags by the note_id, and we use the HAVING clause to only group tags which have a note_id contained in the note_ids CTE that we created at the beginning.

Generating Our Note Records

Most of the time, we don't want to expose all of our record data to Ember, since whatever we send to the client will be accessible by the user, whether we intend it to be or not. We filter down the attributes sent to Ember by limiting the columns in our projection.

  
  notes_attributes_filter AS (
  SELECT "notes"."id", "notes"."content", "notes"."name",
coalesce("tag_ids_by_notes"."tag_ids", '{}'::int[]) AS tag_ids
  FROM "notes"
  LEFT OUTER JOIN "tag_ids_by_notes"
  ON "notes"."id" = "tag_ids_by_notes"."note_id"
  WHERE "notes"."id" < 40
),

Also note that in the projection, we are using coalesce to ensure that we return an empty array if a specific note has no tag_ids. We are using a LEFT OUTER JOIN to combine our previously generated tag id groupings with our notes. We use an OUTER JOIN instead of an INNER JOIN so that all our notes are returned, even if no tags are associated with it. An INNER JOIN would only return notes that have tags associated with it. We also use the same WHERE predicate in this query as we did in the note_ids CTE, to ensure our query only returns the desired records.

Turning Our Note Records into a Single JSON Array

So now that we have our notes records filtered down, we need to create a JSON array of these records to use in our final query. At this point, we will use two of PostgreSQL's JSON functions and the array_agg function that we used earlier. row_to_json takes a PostgreSQL row and converts it to a JSON object, where the columns of the row converted into JSON properties.

  
  foo | bar
=========
  1 |   2

Will be converted to

  
       json
================
{ foo: 1, bar: 2 }

So at this point, our result set is a series of rows with a single column of JSON representing the original PostgreSQL row from our notes_attribute_filter CTE. We then use array_agg to turn the rows of JSON objects into a single row with a single PostgreSQL Array of JSON objects.

  
       json
================
{ foo: 1, bar: 2 }
{ foo: 1, bar: 2 }
{ foo: 1, bar: 2 }

will be converted to

  
                      Array
=======================================================
{{ foo: 1, bar: 2 },{ foo: 1, bar: 2 },{ foo: 1, bar: 2 }}

Lastly, we use array_to_json to convert the PostgreSQL array of JSON to a JSON array.

After combining these pieces, we get the following query:

  
  notes_as_json_array AS (
  SELECT array_to_json(array_agg(row_to_json(notes_attributes_filter)))
AS notes, 1 AS match
  FROM "notes_attributes_filter"
),

which yields

  
      notes    | match
====================
[{},{},{},{}]|     1

We are using the notes_attributes_filter as our source for all the JSON functions, and adding a column match with a value of 1, which we will need later.

Aggregating Our Tag Records

We apply the attribute filtering and the aggregation techniques to our tags table to generate our JSON array of tags. Note that when we filter the tags attributes, we only include tags that have a note_id of a note we are returning.

  
  tags_attributes_filter AS (
  SELECT "tags"."id", "tags"."name", "tags"."note_id"
  FROM "tags"
  WHERE "tags"."note_id" IN (
    SELECT "notes_ids"."id"
    FROM "notes_ids"
  )
),

tags_as_json_array AS (
  SELECT array_to_json(array_agg(row_to_json(tags_attributes_filter)))
AS tags, 1 AS match
  FROM "tags_attributes_filter"
),

which yields

  
      tags     | match
====================
[{},{},{},{}]|     1

Combining Our Notes and Tags

So at this point, we have 2 CTEs that represent our notes and tags. We need to combine these two tables into a single row, so that we can convert that row to a JSON object with a notes and tags property. This is the reason we added a match column onto both CTEs; we join those two table into our final table, which we then call row_to_json on to get our final JSON object, which mirrors the example at the beginning of this article.

  
  jsons AS (
  SELECT "tags_as_json_array"."tags", "notes_as_json_array"."notes"
  FROM "tags_as_json_array"
  INNER JOIN "notes_as_json_array"
  ON "tags_as_json_array"."match" = "notes_as_json_array"."match"
)
SELECT row_to_json(jsons) FROM "jsons";

So there you have it, you could generate this giant query by hand every time you need to create an API endpoint, or you could use ActiveModel::Serializers and utilize the PostgresExt-Seriliazers optimizations to avoid Ruby and Rails when generating API responses.

Building an Ember App with Rails Part 3

2014-05-09 00:00:00

This is a four-part series: Part 1, Part 2, Part 3, Part 4

Let's implement some navigation in the Boston Ember app.

Here is a list of sections in the Boston Ember website I'd like to add:

About
Speakers

For this part we will work with faked out data. In a future part we will provide the Rails backend.

Our first navigation test will be an easy one, create ember/tests/integration/about-page-test.js

  
  import Ember from 'ember';
import startApp from 'bostonember/tests/helpers/start-app';

var App;

module('Integration - About Page', {
  beforeEach: function() {
    App = startApp();
  },
  afterEach: function() {
    Ember.run(App, 'destroy');
  }
});

test('Should navigate to the About page', function() {
  visit('/').then(function(assert) {
    click("a:contains('About')").then(function(assert) {
      assert.equal(find('h3').text(), 'About');
    });
  });
});

After writing this test we can confirm that our test is red in our browser. To make this green we need to add an About route, a link from the landing page to the About route, and a template for the About route.

  
  // ember/app/router.js
Router.map(function() {
  this.route('about');
});

  
  // ember/app/templates/application.hbs
<h2 id="title">Welcome to Boston Ember</h2>

{{link-to 'About' 'about'}}

{{outlet}}

  
  // ember/app/templates/about.hbs
<h3>About</h3>

<p>Boston Ember is the monthly meetup where awesome people get together
to do awesome Ember related things!</p>

Your test should now be green. If you navigate to the root path in your browser you should be able to click through the app. What about getting back to root? We can add a test to for this navigation as well.

  
  // ember/tests/integration/landing-page-test.js
test('Should allow navigating back to root from another page', function(assert) {
  visit('/about').then(function() {
    click('a:contains("Home")').then(function(assert) {
      assert.notEqual(find('h3').text(), 'About');
    });
  });
});

  
  // ember/app/templates/application.hbs
{{link-to 'Home' 'application'}}
{{link-to 'About' 'about'}}

Great! A very simple navigation is setup and fully tested. How about something more complex. Let's allow our visitors to see the people that have spoken at Boston Ember. Before we do that we need to add new dependencies to our app for mocking out remote requests.

We will be using Pretender by Ember Core member Trek Glowacki. Pretender is a nice DSL for faking out remote responses.

We can use the ember-cli-pretender Ember CLI Addon to quickly set up Pretender:

  
  npm install --save-dev ember-cli-pretender
ember install:addon ember-cli-pretender

You may need to restart your server at this point.

Tell JSHint to ignore the Pretender constant. Open up ember/tests/.jshintrc and add "Pretender" to the end of the "predef" array.

Finally we need ember-data to make requests namespaced under api to our server:

  
  // ember/app/adapters/application.js
import DS from 'ember-data';

export default DS.ActiveModelAdapter.extend({
  namespace: 'api'
});

We should be in a good place to write our tests.

  
  // ember/tests/integration/speakers-page-test.js
import Ember from 'ember';
import startApp from '../helpers/start-app';
import Pretender from 'pretender';

var App, server;

module('Integration - Speaker Page', {
  beforeEach: function() {
    App = startApp();
    var speakers = [
      {
        id: 1,
        name: 'Bugs Bunny'
      },
      {
        id: 2,
        name: 'Wile E. Coyote'
      },
      {
        id: 3,
        name: 'Yosemite Sam'
      }
    ];

    server = new Pretender(function() {
      this.get('/api/speakers', function(request) {
        return [200, {"Content-Type": "application/json"}, JSON.stringify({speakers: speakers})];
      });

      this.get('/api/speakers/:id', function(request) {
        var speaker = speakers.find(function(speaker) {
          if (speaker.id === parseInt(request.params.id, 10)) {
            return speaker;
          }
        });

        return [200, {"Content-Type": "application/json"}, JSON.stringify({speaker: speaker})];
      });
    });

  },
  afterEach: function() {
    Ember.run(App, 'destroy');
    server.shutdown();
  }
});

test('Should allow navigation to the speakers page from the landing page', function(assert) {
  visit('/').then(function() {
    click('a:contains("Speakers")').then(function(assert) {
      assert.equal(find('h3').text(), 'Speakers');
    });
  });
});

test('Should list all speakers', function(assert) {
  visit('/speakers').then(function() {
    assert.equal(find('a:contains("Bugs Bunny")').length, 1);
    assert.equal(find('a:contains("Wile E. Coyote")').length, 1);
    assert.equal(find('a:contains("Yosemite Sam")').length, 1);
  });
});

test('Should be able to navigate to a speaker page', function(assert) {
  visit('/speakers').then(function() {
    click('a:contains("Bugs Bunny")').then(function() {
      assert.equal(find('h4').text(), 'Bugs Bunny');
    });
  });
});

test('Should be able visit a speaker page', function(assert) {
  visit('/speakers/1').then(function() {
    assert.equal(find('h4').text(), 'Bugs Bunny');
  });
});

Take a look at the beforeEach function. There is an array of objects that contains the speaker data, currently only ids and names. Below that we are setting up the request stubs. Currently this feels like a lot of boilerplate, and that is because it is. I'm sure eventually someone will write a nice abstraction to clean this up. This code simply stubs out the expected server-side calls and returns a JSON string in the format ember-data expects.

Our four tests are very simple. The first tests the navigation, the 2nd tests the speakers are in the list, the 3rd tests that we can navigate to an individual speaker, and the 4th tests that we can visit the speaker page directly.

Let's make each pass:

  
  // ember/app/router.js
Router.map(function() {
  this.route('about');
  this.resource('speakers');
});

  
  // ember/app/templates/application.hbs
{{link-to 'About' 'about'}}
{{link-to 'Speakers' 'speakers'}}

  
  // ember/app/templates/speakers.hbs
<h3>Speakers</h3>

{{outlet}}

The first test should now be passing.

  
  // ember/app/router.js
Router.map(function() {
  this.route('about');
  this.resource('speakers', function() {
    this.route('show', {path: ':speaker_id'});
  });
});

  
  // ember/app/models/speaker.js
import DS from 'ember-data';

export default DS.Model.extend({
  name: DS.attr('string')
});

  
  // ember/app/routes/speakers/index.js
import Ember from 'ember';

export default Ember.Route.extend({
  model: function() {
    return this.store.find('speaker');
  }
});

  
  // ember/app/templates/speakers/index.hbs
{{#each}}
  {{link-to name 'speakers.show' this}}
{{/each}}

The 2nd test should now be passing.

  
  // ember/app/templates/speakers/show.hbs
<h4>{{name}}</h4>

The 3rd & 4th tests should now be passing.

Passing tests are great and all, but let's actually make the app useable by getting our Rails backend in the game.

Let's generate a model from our Rails app rails g model speaker name:string

Add some seed data:

  
  # rails/db/seeds.rb
Speaker.create(name: 'Bugs Bunny')
Speaker.create(name: 'Wile E. Coyote')
Speaker.create(name: 'Yosemite Sam')

Create, migrate and seed rake db:create db:migrate db:seed.

Add a speakers resource under an api namespace:

  
  # rails/config/routes.rb
namespace :api do
  resources :speakers
end

Now add the controller:

  
  # rails/app/controllers/api/speakers_controller.rb
class Api::SpeakersController < ApplicationController
  def index
    render json: Speaker.all
  end

  def show
    render json: Speaker.find(params[:id])
  end
end

Finally we need to generate a serializer rails g serializer speaker.

Add name to the list of attributes to serialize

  
  class SpeakerSerializer < ActiveModel::Serializer
  attributes :id, :name
end

Start your Rails server with port 3000 and restart your ember server with the command ember server --proxy http://localhost:3000

Any remote requests will be proxied to this location.

Now you can point your browser to http://localhost:4200, click on Speakers and you should see:

That wraps up Part 3. In Part 4 we will get into relationships.

Check out the actual code for this part

Building an Ember App with Rails Part 2

2014-05-08 00:00:00

This is a four-part series: Part 1, Part 2, Part 3, Part 4

From your project directory root, go to your ember directory and start your server:

  
  cd ember
ember server

Open your browser and go to: http://localhost:4200/tests

You should see something like the following:

This is a typical Qunit test suite with some JSHint tests already in our app. What you'll notice in the lower right-hand corner is a blank white box. This box is where our integration tests will execute. This is an IFRAME so we can see our applications interacted with in real-time (albeit very fast real-time).

Let's build out a landing page for our app. We will TDD this entire application over this multi-part series. Create a new directory and file ember/tests/integration/landing-page-test.js.

All of our files will be in ES6 module format. If you are unfamiliar with ES6 modules I suggest you go and read up.

  
  import Ember from 'ember';
import { module, test } from 'qunit';
import startApp from '../helpers/start-app';

var App;

module('Integration - Landing Page', {
  beforeEach: function() {
    App = startApp();
  },
  afterEach: function() {
    Ember.run(App, 'destroy');
  }
});

test('Should welcome me to Boston Ember', function(assert) {
  visit('/').then(function() {
    assert.equal(find('h2#title').text(), 'Welcome to Boston Ember');
  });
});

Once you save this file go back to your browser. You should not need to reload anything, ember-cli has a live reload feature on file change. Now you should see your failing test:

Let's make the test pass:

In ember/app/templates/application.hbs

  
  <h2 id="title">Welcome to Boston Ember</h2>
{{outlet}}

Check your test suite and it should be all green.

Congratulations on your first ember test!

In part 3 we'll build out some pages and write tests to interact with these pages.

Check out the actual code for this part

Building an Ember App with Rails Part 1

2014-05-07 00:00:00

This is a four-part series: Part 1, Part 2, Part 3, Part 4

This series will take us through building and structuring an application with an Ember front-end built with ember-cli and a Ruby on Rails backend. We'll discuss project structure, testing, and deployment to Heroku.

During the course of this series I am going to re-build the Boston Ember website. (if it looks terrible that means I'm not done yet)

Getting setup with our tools

Let's start by making sure all relevant dev tools are installed on our machine. I am using the following:

Ruby 2.1.1
Rails 4.2.0
Node 0.12.0
npm 2.7.0
Postgres (only necessary because we are deploying to Heroku)

Versions at or above these versions should be OK for following along. Please refer elsewhere on how to install these tools on your development machine.

Next I will install ember-cli

  
  npm install -g ember-cli

Confirm that you have ember-cli installed:

  
  ember --version

You should see:

  
  version: 0.2.0

Or a greater version.

Setting up our project

For this project we will keep our Rails and our Ember apps in separate directories with a top-level directory containing the two. We'll have to do some project generating and renaming.

I first create a new top-level directory:

  
  mkdir bostonember
cd bostonember

Now we're going to generate our Rails project:

  
  rails new bostonember -B -S -d postgresql
mv bostonember rails

Note how we renamed the directory the Rails project is in to rails. This does not affect anything in that directory. If you do not have Postgres on your machine omit -d postgresql

Now the ember project:

  
  ember new bostonember --skip-git
mv bostonember ember

Now it should be obvious why we moved the Rails project. We should now have a structure like:

  
  bostonember
|- ember
|- rails

Let's confirm that our ember app runs:

  
  cd ember
ember server

In your browser visit http://localhost:4200 and you should see "Welcome to Ember.js"

At this point you can put everything in your top level directory under version control:

  
  git init
git add .
gc -m "Initial commit"

Let's make some modifications to our Rails app.

  
  rm -rf rails/app/assets

In rails/Gemfile remove the following:

coffee-rails
jquery-rails
turbolinks
jbuilder

Now everything related to the Asset Pipeline is completely removed.

Add the following to the Gemfile:

  
  gem 'active_model_serializers', '0.9.3'

If you don't have Postgres on your machine you can set this for Production only:

  
  group :development, :test do
  gem 'sqlite3'
end

group :production do
  gem 'pg'
end

Run bundle install in your rails directory. Let's commit our changes:

  
  git add -A
gc -m "Removed asset pipeline and added active_model_serializers in Rails"

That wraps up Part 1. In Part 2 will focus on Ember and creating some functionality in our app.

Check out the actual code for this part

The other thing DHH mentioned

2014-05-06 00:00:00

By now you've probably seen DHH's Rails Conf 2014 Keynote. Love it or hate it, the one thing you can't do is deny it got people's attention. I wasn't there, and I admit I reacted to Twitter before actually viewing it. If you only listened on Twitter your perception of the keynote is most likely that DHH is anti-testing. That is very far from the truth. Go and watch the video, a lot of what he talks about resonated with me. I still believe in "testing first" and "red-green-refactor" but my style is not as dogmatic as some other's. I rely on integration tests quite a bit, and I don't mind hitting the database during unit tests. Slow tests that actually test how clients use your app are much better than fast tests that actually test nothing.

On a side-note, I would be interested to know what DHH thinks about BDD as opposed to TDD, if he even thinks there is a difference. For me I feel there is a distinct difference and I would characterize my style of development as BDD.

But I don't want to talk about testing. I want to talk about the other thing DHH came down on during his keynote: Design Patterns.

Now before I get raked over the coals let me start by saying that overall design patterns are great. It was the MVC(ish) and ActiveRecord patterns that made Rails itself possible. When we speak in patterns it becomes the lingua franca for programmers. I can jump from language to language and can, with relative ease, recognize the patterns.

However, in the Ruby/Rails communities we have gone overboard. Design Patterns are the new Holy Grail of software development. A few years ago people were very excited about TDD, as DHH said it was sold to us as a necessary tool for "professional software development". Now that everybody just assumes TDD is happening the thought leaders went in search of the next intellectually challenging concept to hold everyone accountable for. This began to spring up maybe 2 years ago, at least that's when I started to notice it. Design pattern talks at conferences, books dedicated to design patterns, podcasts talking about patterns, blog posts (of which we have written a few), code schools teaching design patterns - developers ate them up. The Ruby community was hungry for patterns.

There feels to me a loss of pragmatism in the ruby community. I think this is due to there being no major problems to solve in Rails anymore. Developers are always looking for problems to solve, and in this case the hive mind has decided to hyper optimize on patterns.

I get it, they are intellectually stimulating. Implementing a pattern to "perfection" will give a developer that sense of self-satisfaction. "My code is clean". Until the next feature comes in and you have to blow up what you've been perfecting.

Be pragmatic. Don't follow the trends just because some guys behind a microphone say you should.

Preserve scrolling position in Ember Apps

2014-05-05 00:00:00

If you have a long list of items on a page and a user follows a link then goes back to that list, Ember will re-render the list and the user loses their place. This can be annoying if there is a very long list of items and the user is expected to be switching back and forth between the list and the item.

We can preserve the position by taking advantage of didInsertElement on the list's view.

Ember Starter Kit

Note: there seems to be a bug with the latest stable in Chrome where the position is never reset if you hit the backbutton. In reality it is but the position doesn't render until you scroll. Canary seems OK as do other browsers

In the above example you can scroll down, click on an item, then head back to the list and be in your original position. This is all done with the following mixin:

  
  var ScrollableMixin = Ember.Mixin.create({
  scrollingTimeout: 100,
  bindScrolling: function() {
    var self = this,
    onScroll = function() {
      Ember.run.debounce(self, self.runScrolled, self.scrollingTimeout);
    };

    Ember.$(document).on('touchmove.scrollable', onScroll);
    Ember.$(window).on('scroll.scrollable', onScroll);
  }.on('didInsertElement'),

  unbindScrolling: function() {
    Ember.$(window).off('.scrollable');
    Ember.$(document).off('.scrollable');
  }.on('willDestroyElement'),

  preservePos: function() {
    Ember.$(window).scrollTop(this.getWithDefault('controller.currentPos', 0));
  }.on('didInsertElement'),

  runScrolled: function() {
    var position = Ember.$(document).height() - Ember.$(window).scrollTop();
    var viewportHeight = document.documentElement.clientHeight;
    this.set('controller.currentPos', Ember.$(window).scrollTop());
  }
});

You then mix it into your list's view:

  
  ThingsView = Ember.View.extend(ScrollableMixin);

Enjoy!

Stop using Ember Appkit Rails

2014-05-04 00:00:00

A few months ago I released a gem called Ember Appkit Rails. Let me start by apologizing for its existence. For those that began projects around eak-rails it started with good intentions and felt right at first but we have abandoned the gem at DockYard.

eak-rails was/is a merging of Ember App Kit and Rails. It does some heavy monkey patching to Rails' Asset Pipeline to give as much project hierarchical power to your Ember code as your Rails code enjoys.

We used eak-rails in smaller projects, and intro to Ember courses. In small doses eak-rails felt right. However, when the surface area of an application increased eak-rails did not scale well. Having your Ember and Rails files mixed into the same directories created more problems than it solved.

This week I will be focusing on how we are building Ember apps backed with Rails at DockYard. Part of that will be in-line with what fellow DockYarder Dan McClain presented at Boston Ember last month.

For eak-rails users, we have not abandoned you. Anybody refusing to migrate we'll continue any critical bug fixes but no new features. We actually sunset the gem about 2 months ago.

ember-cli is the future.

Guarding with arrays

2014-05-03 00:00:00

This week I applied a pattern I've been using for years to two separate pull requests from our devs. (I like to review almost all of the code that DockYard devs write)

In both cases I was able to help them refactor their code to use an enumerator as code guards instead of conditional statements. Let's take a look at each example:

  
  users = User.where(type: 'employee')

if users.any?
  users.each do |user|
    # ...
  end
end

In this first example the each is avoided if the users collection is empty. However, with arrays the enumerator only acts on each member of the collection so we don't need to avoid if the collection is empty. We can refactor the above code into something like this:

  
  User.where(type: 'employee').each do |user|
   # ...
end

Much cleaner!

The next example may not be as straight forward but as we'll see with Ruby we can clean this up nicely.

  
  if params[:ids]
  params[:ids].each do |id|
    # ...
  end
end

Here we have a situation where params[:ids] could contain a collection of data. Or it could be nil. Because of this we cannot just assume we can always iterate over that value. In Ruby we can create a new Array:

  
  Array([1,2,3])
# => [1,2,3]

Array(nil)
# => []

Notice in the second example that when we pass nil it creates an empty array. Knowing this we can refactor our code:

  
  Array(params[:ids]).each do |id|
  # ...
end

If you find yourself putting guards around enumerators odds are you can refactor in a similar manner as I've shown above.

BTW, I've been using this pattern for years but I don't know if there is an actual name for this. If you do please share!

What is holding up the uniqueness validator?

2014-05-02 00:00:00

ember-validations has nearly all of the validator rules one needs. One glarring omission is the Uniqueness validator.

Not as straight forward as one would think

Before we even talk about the complication with implementing the remote validator, we should talk about if uniqueness should be both a remote and local validator.

Imagine you are working with ember-data, you attempt to create a new record with an email test@example.com. If you already have a record with that value for email in ember-data's store should uniqueness first defer here before we hit remote? This ends up being a strange thing because what if you have not persisted that first record yet. Do we only run uniqueness checks against local records that have been persisted? And how exactly would this fit in if you are mixing your validations into the controller instead of the model?

If the email example isn't working for you, imagine you are adding a bunch of line items to a parent record. None of these line items have been persisted yet. And you don't want to allow your users to add another until the current one they are working on is "valid". Validating uniqueness locally is all of a sudden very valuable. But also very complex to implement properly.

No standard yet

If the local validator is too complex of an animal to tackle perhaps the remote validator implementation will be easier. It is, in part at least. We can rely on Ember.run.debounce to ensure the the remote validator doesn't fire too frequenly when many changes are happening to the value of a property. (i.e. entering text into a field)

But where do we send this request for uniqueness? This is where I am currently hung up. I really don't want to implement a backend api expectation into ember-validations. I was hoping that something like json-api would define this for me then I could rely upon that as a starting expected endpoint. But I don't think this is anywhere on their radar.

This being said, there is a possible solution. One of my co-workers Lin Reid has put together a PR for introducing remote uniqueness to ember-validations. It is lacking tests (hint hint, Lin!) but I think this is moving in the right direction.

To summarize, uniqueness is not forgotten. It is just a pain in the ass to do properly. Personally, I would prefer not to implement an API have people buy into it now and have to change it (or be locked into it) a few months from now.

Alert messages in Ember Apps

2014-05-01 00:00:00

Something that feels missing from Ember is a way to send, from anywhere in my app, a general alert message. Something that would pop up in my app, display for a few seconds and disappear.

Clearly, this is something that should not be part of Ember itself but it is a common enough feature that someone should build it.

I call it Woof.

It currently only exists on jsbin

WoofWoof! Notifier for Ember

So for the time being you'll need to copy/paste. We'll be extracting it into a plugin soon enough.

Basically, Woof will inject itself into your routes, controllers, and components. You will need to embed the Woof component somewhere in your templates:

  
  {{x-woof}}

Woof injects a woof object similar to how ember-data injects a store object. You can push a message onto Woof using some of the pre-defined types or create your own:

  
  this.woof.info('This is an info message');
this.woof.pushObject({type: 'customType', message: 'Woof! Woof!
Woof!'});

This code comes with Twitter Bootstrap types setup:

danger
info
success
warning

The x-woof component will loop through all woofs in the array and print out a div with the type as the class for specific styling purposes.

The code in the JSBin is setup and styled for Twitter Bootstrap. The event handling is setup for removing the woof when the css opacity transition completes. Browser support may vary.

Understanding validation graphs

2014-04-30 00:00:00

If you have heard me speak about ember-validations then you may have heard me mention the term validation graph. What is this? Why is it important?

If you come from a Rails background then you are used to the validations being stored in an array on the instance of the model. When you validate your model all of those validations will be run and an errors object is produced. If you make a change to a property you have to run the validations again to determine the validity of the model.

I would refer to the style of validations described above as lazy validations. Meaning the validity of the model may not be truly representative of its current state. We have to opt-into running the validations again to determine this. Fortunately in most cases, the validations will run for us before we save. On the server this all happens within a request/response cycle so we don't really care too much about the validations being lazy because we care about the final result, not the state of the model at any given point during that cycle.

ember-validations has eager validations. This means when the property that is associated with any number of validations changes those validations will run again to determine the state of the model. This is great for client side apps that need to show the current state of the entire model any time you make a change, say during a user sign up. I might want to disable the Submit button if there are any failing validations. If I make a correction I want the error message to go away once the correction is made. I should not have to wait upon form submission to see my errors.

How does ember-validations do this? Let's say you have the following validations:

  
  var UsersController =
Ember.ObjectController.extend(Ember.Validations.Mixin, {
  validations: {
    firstName: {
      presence: true,
      length: 5
    },
    password: {
      confirmation: true
    }
  }
});

There are 3 validations on 2 properties. Each validation is an instantiated class that can observe the one or more properties. In the case of the firstName property the Presence and Length validators are observing it. The Confirmation validator is actually observing password and passwordConfirmation for changes. Each validator has a isValid flag that is set to true or false depending upon the result. Each of these validators are pushed onto a _validators array and the parent object is observing _validators.@each.isValid for any changes. If any of the validators are false the parent's isValid state is now false.

Please take a moment to re-read the above paragraph because it is very important to have a good handle on this before we move forward. The validating object's isValid flag is the result of its validator's isValid flags

Because we are in quack-quack duck-typed JavaScript we don't have to pass validator instances into the _validators array. What if we pass another validatable object? Now things get interesting.

Let's say we have a Profile that belongs to a User. The Profile can have its own set of validations as well as its own isValid flag. If the Profile is mixed into the Users's validation graph then the User will be invalid when the Profile is invalid. We can use this pattern to build an incredibly deep and complex graph where the validation state bubbles up to the root whenever a property change takes place anywhere in the graph.

We can do this simply with:

  
  var UsersController =
Ember.ObjectController.extend(Ember.Validations.Mixin, {
  validations: {
    firstName: {
      presence: true,
      length: 5
    },
    password: {
      confirmation: true
    },
    profile: true
  }
});

Notice profile: true in the graph. As long as profile is the path to the object to validate against ember-validations will work its magic.

However, the above only really works if the validations exist on the Profile model and not the controller.

A visualization of a complex validation graph might look like this. We can see the isValid states bubbling up to the original root node:

I welcome suggestions and thoughts on this API as well as the validation graph in general.

The problem with server-rendered errors

2014-04-29 00:00:00

The 3rd most popular question with ember-validations is how can the library work with server-rendered validation errors, such as the ones returned with ember-data.

The short answer for now: it can't.

(btw, 2nd most popular question is about uniqueness/remote validations and the 1st most popular question is when will I provide a dist/ directory... I'll cover the 2nd Q in an upcoming blog post. As far as dist/ its never going to happen, ever)

Here is the problem. When you are dealing with a client-side model and a server-rendered model there won't always be a 1-to-1 representation of the model. In those cases you can rely on ember-data's serializer to transform the properties on a server-rendered error object to ones that exist on the client data model. How about properties that don't exist at all in any form on the client? You could have a validation error on something only meant for server-rendered purposes. How do we best handle this?

Let's imagine for a moment that we can properly map all the properties back to their client-side equivalents. Now what? How do you resolve these validation errors? How do you know in the UI when the validation error has been resolved to clear the error message? Are you preventing data submission until your client model is valid? If the errors are happening server-side the odds are high that these are not validations that can be known to be resolved on the client unless you do another data submission and wait to see how the server responds.

So to re-cap the two issues are:

Potential lack of context on which properties errors can map back to
Inability to know when server-rendered validation errors are satisfied on the client

To start to consider a possible solution I think we need to step back and consider the ultimate goal of client side validations. In my mind this is purpose: to help the user submit valid data to the server.

Client side validations are just UI sugar. They are there to guide your users. ember-validations only has model-layer concerns, which means you have to provide how the validation errors are displayed on your UI. This is why I also wrote ember-easyForm which handles the complexity of what I consider to be best practices of how validation messages should be displayed and cleared. To fix this problem would have to tackle it from both sides:

How will server-rendered errors be stored in the validation graph? (ember-validations)
How will server-rendered errors be displayed and resolved in the client? (ember-easyForm)

Storing server-rendered errors

If you are already using ember-data then your data model is handling this for you already. IMO you should never mix your validations into your data model, they should be mixed into your controller:

  
  var UserController =
Ember.ObjectController.extend(Ember.Validations.Mixin, {
  validations: {
    firstName: {
      presence: true
    }
  }
});

This way the controller has its own errors object which will not clash with the errors object on your data model. One possibility of referencing the model's server-rendered errors is to have a base validator that is not part of the validation graph but who's errors can be used for presentation purposes.

Displaying server-rendered errors

So how do you properly display these error messages? Do you try to associate them with a property? What if that property is not represented by a form input? What if you aren't even using a form? How do you know when to clear the errors?

I believe this is a complex issue. My first pass at handling this in EasyForm will be to display all of the server-rendered errors in a single place. An upcoming version of EasyForm will simply group all errors in base and display them. These errors will not clear out due to any corrections made by the client. They will only clear when some other action clears out those errors, for example when ember-data itself clears out or changes the content of its errors object.

Conclusion

This is far from ideal. This moves us away from the "best practices" for high conversion forms outlined by Luke Wroblewski. But it is better than not guiding your users. If the server errors for any given reason we don't want our users sitting there without any feedback.

I am very interested in other approaches and brainstorming on the best direction for this. Please feel free to comment below.

Don't override init

2014-04-28 00:00:00

Too frequently I see the following problem. Someone creates a new class and overrides init:

  
  var UsersController = Ember.ArrayController.extend({
  init: function() {
    // some custom stuff
  }
})

export default UsersController;

init is a popular function to override because it is automatically run after the object is instantiated. It is the only lifecycle hook for Ember.Object, subclasses of Ember.Object add their own hooks to the lifecycle but the only one that is guaranteed to be there is init.

The problem is with the above example the controller is broken. I forgot to make a call to this._super() which will call the original init from Ember.ArrayController. That init assigns the proper value to content. (via ArrayProxy)

Instead of overriding init I have been writing functions that are specific to the logic I want to kick off on object instantiation and have that function trigger on('init'):

  
  var UsersController = Ember.ArrayController.extend({
  doSomething: function() {
    // some custom stuff
  }.on('init')
})

export default UsersController;

Now I don't risk messing with the original behavior of the parent class.

Calling up the super chain is a powerful and important feature in Ember but too often I was forgetting to call it. Now the only time I find myself overriding init is if I want to disrupt the default instantiating behavior of the object.

The first two months at DockYard

2014-04-28 00:00:00

The first two months at DockYard.

Recurring themes, and principles I learned in breaking into user experience design.

Invisible

The way I see websites has changed after a month and a half of paying attention to website UI. One thing that stands out: good design can support the message and content in a quiet, almost invisible way. This principle applies in all areas of design, but I am particularly focusing on elegant solutions in web interfaces. It is a pleasure to observe, and sometimes find myself, effective use of subtle visual changes.

The principle of quiet, effective solutions comes up most often when my work-in-progress is reviewed by the whole team. In most cases, I find that I start a design with many elements in a very âloudâ state, then evaluate the entire layout. Once I can prioritize things on the page, most elements can become more âquietâ.

Design for a typical case, not the worst case.

Before DockYard, my process relied heavily on finding out what the worst-case scenario could be, and designing for that. For example, I would consider a very long, but still plausible, title for an article, and then design the header to accommodate that comfortably. Iâd always consider extreme cases early on, and design heavily around those.

At DockYard, I learned to design for the typical use case, and then consider how an extreme case would be accommodated. Looking back, I realize that this approach is less limiting and can result in better graphical solutions.

Information density

Different use cases call for different densities of information.

When you are scanning through many search results, it is sometimes appropriate to show a lot of detail at once. Search results are basically many repetitions of one type of item. Users may want to compare what they see according to different criteria, and it is useful to neatly show many details about each result. If Iâve done a good job prioritizing the detailed information, many details do not cause clutter.

In other cases, it is more important to convey the atmosphere around a brand, or to highlight one or two primary actions. Showing fewer items and fewer details can work better. In these cases, the density of information may appear low, but each element has more prominence.

I can make good progress towards solving the layout of a page by deciding whether it is a detailed type of page (like search results) or a page focused on emotional impact, but not details (like some landing pages).

Does it look ârealâ?

Design is often about deciding what kind of animal a chunk of information will be. Through visual design, we have to clearly answer questions like âhow important is this thing, relative to others?â, âwhat can I do with this?â and even âwhat kind of thing is it?â. When I show a draft in a design review, I can see how the suggested changes âsnapâ to something that looks more real and interactive. I believe that the ability to make things look real quickly comes from experience, and also from paying attention to how user interface elements are crafted in products I use every day.

Through regular design reviews, close observation of UI design, and occasional experiments, I hope to continue improving my ability to judge my own work. This will allow for more efficient work, more refined design, and more awesomeness in the future.

Artist: Ryo Takemasa

2014-04-25 00:00:00

Artist: Ryo Takemasa

If youâre not using Pinterest yet to collect various reference material and inspirational artists, may I suggest doing so immediately? I typically like to keep a huge assortment of âmood boardsâ on various topics, ranging from product designs to comic books to grandiose natural landscape photography. It serves as an endless source of reference material, much like collecting magazine clippings and organizing them in various folders. Not only is it great for collecting all of the art you love in one place, itâs also a great platform for discovering new artists. A list of suggestions titled, âother pins like...â is displayed below the piece youâre currently viewing. This often times leads me down an endless tunnel of discovery - one that typically keeps me digging a hole into the wee hours of the morning.

During one of these excavations, I discovered the artist Ryo Takemasa, who I at first mistook as Charley Harper. The piece I saw was a series of stand alone fruits and vegetables, most of them cut in half to expose their cross section, which all shared a beautiful mixture of what appeared to be wood block print and cut paper. Their geometric and pattern infused forms created lovely shapes alongside color shifts that Iâd typically only see in particular vintage illustrations. Accompanying this pin was a link to his site. It turns out heâs a modern Japanese illustrator who works primarily in the print world for a variety of publications.

Once I discovered this, I began to see the Japanese line work and wood block printing aesthetics shine through in his work. The geometric forms and subtle color transparencies were clearly influenced by Japanese culture, but they still retained that vintage American aesthetic at times as well.

Iâd be curious to learn what amount of influence Charley Harperâs art had on the world and whether it was a huge influence everywhere, such as territories in Japan. Similarly I would also like to know the amount of influence, if any, ancient Japanese wood block printing had on Charley Harper. Was it a conscious decision or had it inadvertently shown through? If there had been a direct influence, that would significantly alter my view of someone who Iâve alway seen as having emerged purely from American Modernist abstraction. Either way, itâs amazing to think that two people, so separated by distance, culture and era could have produced such distinct, yet aesthetically similar artwork. As is the beauty of influence in this world.

Ember Object Self Troll

2014-04-17 00:00:00

Let's say we have a Month object. A Month has weeks.

  
  var Month = Ember.Object.extend({
  weeks: Em.A()
});

Consider the following code:

  
  var a = Month.create();
var b = Month.create();

console.log('before a', a.get('weeks')); // => []
console.log('before b', b.get('weeks')); // => []

a.get('weeks').pushObject(1);
a.get('weeks').pushObject(2);

console.log('after a', a.get('weeks')); // => [1, 2], as you expect
console.log('after b', b.get('weeks')); // => [1, 2], and you're like O_o

And another one:

  
  var Month = Ember.Object.extend({
  weeks: Em.A()
});

var a = Month.create({ weeks: Em.A([1, 2]) });
var b = Month.create();

console.log('a', a.get('weeks')); // => [1, 2]
console.log('b', b.get('weeks')); // => []

The results of the first example are quite surprising, if you are not used to the prototypical inheritance.

So what's going on there? Let's take a look at the "very scary" Ember.js create function:

  
  create = function(obj, props) {
  K.prototype = obj;
  obj = new K();
  if (props) {
    K.prototype = obj;
    for (var prop in props) {
      K.prototype[prop] = props[prop].value;
    }
    obj = new K();
  }
  K.prototype = null;

  return obj;
};

When you don't pass any properties to create (props), all instances of the Object will share the same prototype. That's pretty much the gist of the prototypical inheritance. It means that any changes on one object will reflect on the others. That explains the behaviour in the first example.

If you pass the properties (that ones that you specified at extend time) to create, they are going to be replaced on the instance's prototype.

There are two ways of changing the default behavior:

turn weeks into a Computed Property
set weeks on init

Using computed property:

  
  var Month = Ember.Object.extend({
  weeks: Ember.computed(function() {
    return Em.A();
  })
});

In this case, weeks is going to return a new Ember.Array on get. The code will run as you expect, weeks are not going to be shared.

Using init:

  
  var Month = Ember.Object.extend({
  weeks: null,

  init: function() {
    this._super();
    this.set('weeks', Em.A());
  }
});

This is very clear and nice technique if you're not familiar with computed properties. Overriding init and calling super allows to run code upon the object's creation. You can set the value for weeks there.

You can also use on('init') but it's discouraged because a subclass can provide its own implementation of setWeeks:

  
  var Month = Ember.Object.extend({
  setWeeks: function() {
    this.set('weeks', Em.A());
  }.on('init')
});

Happy coding!

Vim: On Your Mark...

2014-04-10 00:00:00

The strength of Vim's basic movement commands are immediately apparent. We can jump four words over with 4w or move to the beginning of a sentence with (. Once these movements are engrained to muscle memory, we can move within files with ease. However, there are certain limitations to these basic movement commands; wouldn't it be great if we could move to different and specific spots within multiple files?

Today, we're going to briefly cover a poweful motion strategy: mark motion.

What is a Mark?

Marks are essentially hidden positions that, when set, allow us to jump back to that specific location or line. What we mean by hidden is that these marks are not visible by default; marks are simply invisible points within a file.

The mark motion command starts with hitting m - m for mark - and then setting a destination marker - either a lowercase letter or uppercase letter. We'll introduce the differences among the destination markers soon.

Let's start by covering a simple example of setting a lowercase mark.

Example: Moving With A Lowercase Mark

  
  # ~/example1.txt

Here is Line 3
Here is Line 4
Here is Line 5

# On Line #3, use `mn` to set a mark on the letter `n` within the word `Line`.
# Move around the file.
# Go back to the previous mark by hitting: `n

First, in Normal mode, move to Line #3. Place your cursor on the letter n within the word Line.
Next, set a mark by hitting m and then the lowercase letter n. n is our lowercase destination marker. Congratulations, we've just set a lowercase mark! We could of used any lowercase character, but by using the letter n, we've setup a nice mnemonic device.
Now move to Line #5. We're going to move to our mark now. Hit `n - backtick and n, our previous destination marker.
Notice where our cursor is (hint: it should be located on the letter n within the word Line). Huzzah, we are now back to our previous position within the file!
Go back to Line #5.
Now, hit 'n - single quote and n.
We are now at the beginning of Line #3!

Jumps, Marks and a Few Commands

We know how to set a mark with m, but let's clarify the two types of mark jumps and the different types of marks.

Two Types of Mark Jumps

Backtick

`<mark> - The backtick places our cursor directly on the mark.

Single Quote

'<mark> - The single quote takes us to the first non-blank character of the mark's line.

Three Types of Marks

Lowercase Marks

a - z - These marks preserve locations within a single file. Each individual file possesses 26 settable lowercase marks. Lowercase marks are valid as long as the file remains in the buffer list. Furthermore, lowercase marks can be combined with other operators. For example, c`n, will change everything between the cursor to the mark, n.

Uppercase Marks

A - Z - These marks preserve locations within multiple files. Also known as file marks. These marks, which are shared among all files within the buffer list, can be used to jump from file to file. File marks can only be used in combination with operators if the mark is in the current file, i.e. when the current file opened contains the global file mark.

Numbered Marks

0 - 9 - Numbered marks cannot be set directly, instead they are created automagically and used by the viminfo-file (:help viminfo-file). Essentially, the numbered marks store the location of your cursor after closing Vim. For example, mark 0 returns the position of the cursor during your last Vim session, while mark 1 returns the next to last Vim session, and so forth.

Some Pertinent Commands

Viewing current marks

:marks {argument} - :marks will show you all current marks, their file location and destination marker. We can pass in an argument to view a range of marks between two marks.

:marks aC - will return all marks that are between a and C.

Deleting Marks

:delm[arks] {marks} - We can use :delm or :delmarks and then pass in marks that we want to delete.

:delm aAbB - will delete marks labeled a, A, b and B.

Okay, What's So Cool About Marks?

Marks can speed up our navigation workflow! Here are a few examples:

Discussion: Editing One Large File With Lowercase Marks

I've found lowercase marks extremely useful when editing multiple portions of a file. Instead of using CTRL+u, CTRL+d, H, or L to move up and down the file, you can set local marks at heavily treaded locations at jump back and forth among them. Moveover, marks give us the ability to jump to an exact location - backtick - or to the beginning of the line - single quote.

Example: Editing Multiple Files With Uppercase (File) Marks

When I first started using Vim (and began programming), I had multiple windows open constantly on the monitor. Not only does it quickly become cluttered, remembering which file is which becomes hairy.

Files marks to the rescue!

Here are three files we are want to work on. Let's add some file marks. Just like lowercase marks, the actual uppercase letter we use does not matter as long as it is unique.

  
  # ~/sheep.rb

# On the word `speak`, place a file mark with `mS` - `S` for "sheep"
def speak
  puts "Baah! Baah!"
end

  
  # ~/cat.rb

# On the word `speak`, place a file mark with `mC` - `C` for "cat"
def speak
  puts "Meow! Meow!"
end

  
  # ~/doge.rb

# On the word `speak`, place a file mark with `mD` - `D` for "doge"
def speak
  puts "Wow! Ahh yes method! Such quality!"
end

If we are in ~/sheep.rb and want to jump to the speak method defined within ~/cat.rb, we can do so with `C. Now that we're in ~/cat.rb, let's go to the speak method within ~/doge.rb with `D. Pretty sweet, huh?

"X" Marks the Spot

Hope you enjoyed the basics of Vim marks. We've only covered the basics here, so if you'd like to learn more check the docs.

Designing Within The Browser

2014-04-04 00:00:00

I employ a solid range of design tools and although Iâm spending some of my time designing in the browser, the ideal of designing entirely in that context is often unrealistic and stifling.

Save time for discovery

Sometimes an accident leads to an interesting and useful discovery. In art and design this is especially true. In a browser, unfortunately, accidents donât pleasantly surprise you in the way âstaticâ designs may. In development an accident means broken code â plain and simple. You may stumble on a solution, but youâre not going to be surprised by a random glimpse of order and possibility in the muck of your own broken HTML. Itâs broken until itâs fixed.

Such a quality of the web is necessary, but I donât find it very helpful for discovering new solutions to visual or experience problems. In the early stages you become very focused on minute details when you should be thinking in broad strokes. In later stages you find yourself seeing larger visual problems and with less power to change it. In many ways, I find designing in the browser akin to designing in the dark.

There are plenty of browser based design tools attempting to free designers of heavy weights such as Photoshop and allow designers to work without learning advanced HTML and CSS. This is a positive direction, but I still havenât seen the problem solved without losing the element of discovery. Instead of happy accidents, you may experience a gross misunderstanding between your intent, the front end code of the tool youâve chosen, and the DOM. Maybe the tools will get better, and Iâm sure they will, but Iâm not optimistic theyâll be architected to facilitate discovery within the next few years.

For the time being my opinion is that, in terms of process, improvements in web standards and web technology arenât going to change anything save for ensuring work may be completed in shorter order. We create tools (or products) and advance technology in order to increase efficiency and improve human capability. The computer added efficiency for designers by - among many, many other things - being faster and more forgiving than pen and ink, but we still use these older technologies today in tandem with computers.

The right tool at the right time

We can still integrate designing in the browser as a component of the design process. I donât view this as an allâorânothing deal and our process should be malleable enough to better facilitate reaching the goals of each and every project. Imagine, as an extreme example, that you were told to integrate sketching into your design process. You would absolutely not render your designs âpixel-perfectâ in a sketch book. It beats the whole point of the sketch book and the whole experience would be tremendously debilitating. Instead, youâd probably do at least a little bit of preliminary sketching before opening Photoshop, and return when you need to massage another idea out of your head.

The benefit of designing in the web, or at least getting a product in the browser sooner, is that you can experience it and identify major problems before youâre past the point of no return. This is a pretty well established idea (that I believe in), but just like using the sketchbook we need to identify when itâs appropriate to pop open a text editor and start punching in markup and styles. Iâll kick this off with two cases where I think designing in the browser is appropriate: prototyping unique interactions and defining visual state changes.

Prototyping unique interactions

We should prototype and test core product interactions when they are unorthodox. Design patterns should be used where possible, but if we are knowingly going against the grain we need to test that experience in the browser and with users (as available) before making it permanent. This is sometimes after the static design has been completed, but in many cases can be done before anything static has been created.

Visual state changes

When following design patterns there are still standard things to be fleshed out in the browser: hovers, presses, clicks, fades, sliding interactions, and so on. Generally, if you donât know how an interaction will truly feel and it involves a state change: design it in the browser. At DockYard, we often propose a solution first in Photoshop and then weigh our options again in the browser.

An example

We completed a project last year with the ambition of the design stage being completely browser based, skipping the use of Photoshop altogether. The benefits of having a usable front end in place of static mockups are great: you can use your app as it is being designed and get a sense of the failure points before they become too ingrained in the experience. User testing can begin earlier. This is awesome. From the outside, designing solely in the browser seemed perfect.

You guessed it: I was wrong. It wasn't right for us then, nor for that project. We were less focused on the userâs experience and more focused on the organization and creation of markup, styles, and script. We began (and ended) by worrying about and writing lines of HTML, CSS, and JavaScript. We were worried about front end patterns, but the design patterns we were aiming to support werenât fully identified yet. We introduced somewhat of a chicken and the egg problem, making our thinking more difficult and more sporadic than it should have been.

For us this meant spending hours and hours tweaking markup, all in the name of being able to feel and test the product as it was created. In some cases, for sure, this can be worth it. In our case we even had plenty of existing design assets to base our web interface off of, but that project had called for too many largely different iterations (and mixed opinions) of the same few designs.

Designing in the browser does not mean your project will turn out poorly. Ultimately, and fortunately, that project turned out well in the end, but we did spend a lot more time getting a complete idea of what we were actually designing and building. Our clients got to use the product before they bought into the concept, which was great for them. For us, however, it was as if we started designing a house by laying the concrete foundation before knowing what we were building.

Weigh your options

A successful product depends on its content, design, engineering, market fit, team, tools, and infinitely more. When consulting, those elements are wildly varied from client to client, including the toolset. So we must be mindful of what is necessary, be malleable in our processes, and most important of all: make room for discovery.

Magic behind ES6 Generators

2014-03-30 00:00:00

Overview

The next version of JavaScript (ES6 or ES.next) is going to have a lot of great features built in that are going to make developer's life much easier. Promises, Modules, WeakMaps, Generators to name a few. In this post I want to talk about generators.

Generators are objects that encapsulate suspended execution context. What the heck does it mean? In other words, generators allow you to pause execution of your code and return a value.

Let's say you need to write a cubic function (for any given number, calculate a cubic number) and then print it out.

Code without generators for 10 numbers:

  
  function out(n) {
  console.log('Cubic number:', n);
}

function *cube(n) {
  n = n * 3;
  out(n);
}

for (var i = 0; i < 10; i++) {
  cube(i);
}

Code with ES6 generators for 10 numbers:

  
  function *cube(n) {
  var i = 0, j = n;
  while (i < n) {
    i++;
    j = j * 3;
    yield j;
  }
}

var c = cube(10);
for (var i = 0; i < 10; i++) {
  console.log('Cubic number:', c.next().value);
}

Can you spot the difference? Generator represents a sequence of numbers and every time you call next() it gives you the next number in the sequence (it actually gives you an object back with two properties: value and done):

  
  c.next(); // => { value: 3, done: false }

Once the limit is reached, generator will return:

  
  c.next(); // => { value: undefined, done: true }

Pretty cool, eh?

Note, that generators look just like functions, but with *s:

  
  // regular function
function cube()  {}

// es6 generator
function *cube() {}

If you're a Python developer, generators and yield are not new to you. But it's a big step forward for JavaScript.

For-Of

The for of loop is a new iteration construct in ES6 which supports generators. This is really for performance purposes. Instead of returning a full array, you can just return a generator which lazily gives values back on each iteration. That decreases memory allocation and you can express infinite data structures (since no array allocation is needed).

A really interesting use case for generators is async operations:

  
  spawn(function() {
  var users = yield db.get('users');
  var posts = yield db.get('posts');
});

spawn is a function in node.js that allows you to create child processes. You can read about it here.

spawn hands control over the function to the scheduler, which knows that the function will yield promises and will send the values back as soon as the promises are going to be resolved (fulfilled).

This is really powerful.

Availability

If you really want to use this feature, you're going to have to use transpilers, such as Traceur or Regenerator. The reason for that is two new language keywords introduced by ES6 generators: yield and function *. There's a really good blog post about polyfilling generators that goes in depth about how transpilers deal with the new syntax.

Native implementations of generators are available in Firefox and Chrome Canary (you will need to enable harmony experimental flag).

I encourage you to play around with the generators and get familiar with the syntax because in couple of years from now, we all will be writing code using generators (hopefully).

P.S.

Great article about ES6 generators.

Ember Conf picks up where the Rails community left off

2014-03-17 00:00:00

I'm writing this on my flight from Portland back to Boston. On this plane I count at least 12 other attendees of the first Ember Conference. A lot has been said about Ember in the past year but if this conference was any indicator big things are happening and even bigger things are going to happen.

For me, the biggest take away from any conference is the people and this conference was no exception. In fact, Ember Conf is now my gold standard for a technology event. The only possible comparison I have is how early Rails Confs felt. There is an energy and a scary amount of creativity happening in the Ember community right now. Much like the community felt around Rails back in 2006 - 2009 there is the understanding that those doing Ember now are going to be shaping the future of the web. Whether that is setting the bar higher for how users will want to consume web applications in the future or being a large influence on what the future of the web standards themselves will be, Ember is the only web technology today that is positioned in the same place that I feel Rails was years ago. We are the rebels. We are the counter-culture. Ember is the future.

But, we're learning from the mistakes of the past. Where the Rails community was the counter-culture of its time it suffered from a male (and very juvenile) dominated culture. This culture was the result of the "RockStar" mentality set forth by its leader(s). Ember, in contrast, began its very first conference with Yehuda Katz and Tom Dale addressing the entire crowd with their desire for Ember to be an open and diverse community.

The conference was very well organized, big shoutout to Leah Silber at Tilde. She put on a great conference, I'm proud that my company had the opportunity to help make it happen.

From a technology perspective huge things are on the horizon for Ember. If you have been on the cusp of getting involved you will be kicking yourself later for not doing so now. If you are already building in Ember nearly all of the pain-points that have existed will be addressed in the next 6 months. Testing as a first class citizen, fastest template rendering of any JavaScript framework/tool out there, animation support, query params, a standardized project structure and build tool, and there was even talk of how we're going to package and distribute dependencies. Ember Conf was a continuous roll of one great talk after another loaded with the best tech on the web. I've already really enjoyed writing Ember apps for the past year, the next year will be amazing.

I realize at this point the article smacks of cheerleading optimism. How can it be this good? The real secret weapon of any open source software is its community. After this week I can tell you that I have not felt this way about a community since the early days of Rails. There is something very special happening here. It isn't just me. Go search Twitter for #EmberConf and see for yourself.

People are crying, having spiritual awakenings and overall life-affirming moments at #emberconf â¦ Think I want whateverâs in their punch
— Rob Conery (@robconery) March 27, 2014

ITâS HAPPENING!! HTMLbars eliminates <script> tags, {{bindAttr}}, and gives Ember the fastest bound templates on the planet. #emberconf
— Tom Dale (@tomdale) March 26, 2014

This scene with @tomdale @tehviking and @fivetanley sums up #emberconf - so much love â¤ï¸â¤ï¸â¤ï¸ pic.twitter.com/AEUEeiq97i
— Dan Gebhardt (@dgeb) March 27, 2014

Ember makes you a badass web developer. The productivity gains are unparalleled. Page flow is first class. #emberconf pic.twitter.com/DlKqmmdVEU
— John K. Paul (@johnkpaul) March 25, 2014

Notes on the morning #emberconf keynote by @wycats @tomdale pic.twitter.com/rYKEruaxRe
— Michael Chan (@chantastic) March 25, 2014

hug @tomdale achievement unlocked #emberconf pic.twitter.com/nLOBPGJwKL
— Ben Rosas (@ballPtPenguin) March 27, 2014

@ebryn @EmberConf Such a wonderful experience. One of the best conferences I've ever attended, it was like one big family finally united.
— Kasper Tidemann (@KasperTidemann) March 27, 2014

A Simple Ember Data Route

2014-03-03 00:00:00

When working with an Ember Data model it is easy to forget to properly handle the teardown of that model. For example, if you are creating a new model and the user hits the backbutton that model is still in the local store. Or if a user edits a model and decides to click the Cancel button or clicks a link that transitions out of this route without saving the model. A basic approach can be as simple as:

  
  Ember.DSModelRoute = Ember.Route.extend({
  deactivate: function() {
    var model = this.get('controller.model');
    model.rollback();
    if (model.get('isNew')) {
      model.deleteRecord();
    }
  },
  actions: {
    willTransition: function(transition) {
      var model = this.get('controller.model');
      if (model.get('isDirty') && !confirm('You have unsaved changes. They will be lost if you continue!')) {
        transition.abort();
      }
    }
  }
});

Routes inherited from Ember.DSModelRoute will always clean up after themselves. If the user has unsaved changes and attempts to leave the current route the app will guard against the transition and allow the user to confirm with a notice that changes will be lost.

Using Database Templates in Rails

2014-03-03 00:00:00

Using Postgres as your application's database? If so, there is a handy configuration option that you may not be aware about. The pg gem provides a template option that allows for copying already existing data into an application as long as you have matching schema.

To add this functionality, simply add the template option inside config/database.yml:

  
  development:
  adapter: postgresql
  encoding: unicode
  database: myapp_development
  template: my_template

Let's go through a quick example. Suppose we have an existing database, food, and it contains an abundant amount of data with the following schema:

  
  foods: name (string), category_id (integer)
categories: category (string)

To use the food database for our application, we are going to create a template by specifying our database with the following command:

  
  createdb -T food my_food_template

We must now set up our Rails application and make sure that our schema matches that of our new template. Our Rails models will mimick food. Having done that, we can now modify our config/database.yml.

  
  database: myapp_development
template: my_food_template

Run migrations and voilÃ ! Our database has been populated and is ready to be used.

  
  > psql myapp_development

> select * from foods;
  id |  name  | category_id
  --------------------------
  1   apple       1
  2   banana      1
  3   spinach     2
  4   ice cream   3

> select * from categories;
  id |  category
  --------------
  1   fruit
  2   vegetable
  3   other

Native App Developers: We Can Help You

2014-02-07 00:00:00

If you have an existing app, and are looking for a server component, whether it be adding a syncing service to your app, building out a web version to extend your user experience, or need a site to showcase your app, we have both the design and development resources to make that happen.

You might have realized that iCloud doesn't fit your needs, or you want a web application that interacts with your app. We can build your API to fit your exact needs, so you don't need to fight iCloud to fit your needs. You may be looking to build out a new RSS service that needs to parse and cache RSS feeds. We have the experience and resources that will help you bring a server heavy component to your app.

You may have users looking to use your application when they aren't on their phone. We can design and build a rich web application that brings your app to the browser without losing the spirit of your app. You might need a marketing site with video demos and screenshots of your app. We can design and build a site that really shows off your application.

If any of these sound like you, you should get in touch with us.

Announcing PostgresExt-PostGIS

2014-02-07 00:00:00

Today I released the first version of postgres_ext-postgis, which extends ActiveRecord to support PostGIS data types and some querying. This is definitely a beta release, but ready to the point where people can play around with it.

Migrations

With postgres_ext-postgis, you can easily add geometry columns:

  
  create_table :districts do |t|
  t.geometry :district_boundries
end

If you'd like to include your projection or geometry type, just include them as options to your column:

  
  create_table :districts do |t|
  t.geometry :district_boundries, spatial_type: :multipolygon, srid: 4326
end

Type Casting

Your geometry columns will be typecasted into RGeo objects. You can set your attributes with RGeo objects or EWKT/EWKB strings. EWKT/EWKB strings will be converted to RGeo objects:

  
  user.location = 'SRID=4623;POINT(1 1)'

Querying

For now, the only added querying method for ActiveRecord is contains:

  
  District.where.contains(district_boundries: user.location)

The above query will utilize PostGIS's ST_CONTAINS to see if the district_boundries column contains the user.location. I plan to add a convience method to convert EWKT strings to RGeo object, something like PostgreExt.geom('SRID=4623;POINT(1 1)'), to make generating queries from, say, a mobile user's current location a bit easier.

As I get feedback and use postgres_ext-postgis, more features will get added. Stay tuned!

Ember Conf: Ember for Rails Devs

2014-02-04 00:00:00

We invite you to learn from DockYard for a day before Ember Conf in Portland, Oregon. We will be offering a one day training session for Ruby on Rails developers interested in learning how to build Ember Applications. Over the course of the day we will teach you the following:

Introduction to Higher Level JavaScript Concepts

ES6 Modules
Promises

Introduction to Ember Concepts

Client side MVC
Ember.Object
All the stuff under the hood of Router, Routes, Models, Controllers, Components, Templates, and the Runloop
Ember Data

Introduction to Ember Appkit Rails

How to build a new Ember project with Rails
Generators
Testing

Together we wil build two applications before the day is over. The first will be a simple CRUD "blog" style application. Time permitting the second will be a more advanced desktop-quality style applicaiton.

Seats are limited, be sure to get your ticket before they sell out!

About The Instructors

Brian Cardarella

Brian is the CEO of DockYard and has been developing in Ember since late 2012. He was a speaker at the "first" Ember conference, Ember Camp, in 2013. Brian is the author of some popular Ember libraries such as ember-validations and ember-easyForm. Recently he has been focusing most of his open source time on building Ember Appkit Rails, which is a re-implementation of Ember App Kit for the Rails Asset Pipeline.

Robert Jackson

Robert is a Sr. Developer at DockYard. He is a member of the Ember Release Management Team and a significant contributor to Ember. He spends much of his free time helping maintain a number of Ember related open-source projects including: Ember Data, Ember Appkit Rails, Ember App Kit, the EAK/EAKR resolver, ember-rails, ember-easyForm, and ember-validations.

Lin Reid is a DockYarder!

2014-01-02 00:00:00

Lin comes to us from Alaska. Normally that is all that you need to say but Lin also brought us jerked-bear (actual Alaskan black bear) on his first day with us as an intern. From there it was easy street. Lin's published his own gem, contributed back to several of our projects, and has been expanding his developer horizons with Ember over the past few months. He is also the co-founder of Pizza Time

Follow Lin on Twitter and on GitHub

Robert Jackson is a DockYarder

2014-01-02 00:00:00

Today is Robert Jackson's first day at DockYard. Robert is joining our team as a Sr. Rails and Sr. Ember developer by way of Florida (but he'll soon be joining us in the Northeast). Robert is a member of the Ember Release Management Team and has been saving my ass with several of our open source Ember projects over the past few months.

Follow Robert on Twitter and GitHub

Romina Vargas is a DockYarder!

2014-01-02 00:00:00

Romina was a DockYard intern that we just recently hired to full-time! Over the past few months Romina has taken on all of the challenges we've thrown at her and excelled. Now she's TDD'ing, Vim'ing, Tmux'ing, Ember'ing with the best of them. She's also the co-author of the exciting new Ember application that is all the buzz: Pizza Time

Follow Romina on GitHub

Lessons Learned: The First Two Years of Running a Software Consultancy

2013-12-22 00:00:00

This is an update of the previous post that reflected on the first six months of DockYard. A lot has changed over the past year and a half, and a lot has not. I won't do a point-by-point comparison to the previous post but I will address some as well as some of the feedback I got at the time. But first, let's talk about revenue.

Revenue

After our first year we took in about $750,000 in revenue. DockYard officially began in January of 2012 so we had a full calendar year to earn. From what I've been told this is pretty good for the first year as a consultancy. In our second year we broke $1,500,000 at the beginning of December. I'm happy with that, we doubled revenue. I have set a revenue goal of $2,500,000 for 2014. Assuming there are no major screw ups next year we should exceed that goal.

Revenue is great and all but kind of useless information without our profit margin. We have averaged around 20% profit margin over the past two years. This year we were averaging in the mid to high 20s before we hit a lull at the end of November.

The Negative Stuff

Let's get the negative stuff out of the way first so we can focus on positives for the remainder of the post. We could have done better the previous year, we could have done better this year. We lost money due to decisions that I made throughout the past two years. Those choices include two bad clients, a mistake in the direction of our growth, and a lack of experience of running a conference.

Bad Clients

In the previous post I mentioned how DockYard nearly folded from the start due to a bad client. That nightmare lasted for a year and half and was finally settled in June of this year. It ended up being nearly a $50,000 loss for us. I am convinced this is due entirely to poor legal counsel; I cannot stress enough how important it is to have a competent lawyer on your side. We didn't have someone that was willing to fight for us, it cost us big time. We have since retained the law firm of Gesmer Updegrove. They're pricey, but it's worth it.

However, before we ever engaged with our current lawyer we unfortunately had another run with a bad client. This time to the tune of $20,000. That hit came this year. What is really strange is that I knew walking into this deal it was going to end badly, and I voiced my concerns internally to my people at the time but I still OK'd the deal and it unfolded just as I thought it would. It was a dumb move and we paid the price of it.

One of the plans for DockYard was to quickly grow into the political tech space in Washington, DC. I have experience working in political tech, I brought on a guy who I worked with at the DNC, and we hired another guy I worked with on a political campaign. We started making connections. It didn't work out. Three reasons:

Timing

Timing is everything I guess. Especially in political tech, we set out on this effort right when the 2012 cycle ended. It was a ghost town, and rightly so. There is no reason for campaigns or political groups to spend money on development efforts when the next election cycle is two years away. While we spoke with a lot of people that were interested in what we could do from a technical perspective there simply were very little groups without any budget at the time.

The People

During my time at the DNC I worked with some awesome people. Nathan Woodhull, Chris Gill, Brent Kimmel, Leo Zhadanovsky, and Nicole Aro to name a few. I've been lucky enough to work with a few of them since. Unfortunately I also got to work with some really shitty people too. I don't think its their fault, the political tech space is a real drag. It doesn't attract a lot of talented people because the money to work on the inside is very bad compared with any other job out there. The tone you get is that it is a privilege that you should be thankful for, and perhaps that is the case. But that leaves a vacuum that gets filled with people that frankly don't know their ass from a hole in the ground. Many of these people are now in charge of making technology decisions in many organizations. I have no interest in working with those types of people again, nor do I want to subject my employees to work with them.

Politics

I've always considered myself "on the Blue team" but the past year has really pissed me off. NSA, Healthcare.gov, drone strikes, and the President trying everything he can muster to go to war with Syria. I walked into our Business Developer's office one day and I said enough was enough. I could not in good conscience do work for the Democratic Party because of these issues.

Just Dumb Wasted Money

We ran a conference this year and due to my lack of experience running an event like this (and to be honest, being taken advantage of by the venue we held the conference at) we lost $15,000.

There were also downtimes when we didn't have enough money coming in, but I will get into detail about this later in this post. (and the changes we've made to hopefully avoid this in the future)

Overall I am pretty proud with our revenue over the past two years. We didn't start with an "industry superstar" on our team or with a significant open source project in our pocket, nor were we on the "inside" of the Boston tech scene. We've built a very strong brand for ourselves very quickly.

Open Source

This is still a financial loser for us. I don't care what people say, that's a fact. However, Pete Forde commented on my last post and what he said was absolutely true: it will help you hire good people. DockYard has been making a name for itself in the Ruby and Ember open source world. We have a good number of projects that people are actively using. I encourage all of our developers to contribute back to not just our projects but projects we use on a regular basis.

Personnel

I've made missteps on hirings, that is also costly. I'll get into this later in the article.

OK, enough with the negative stuff. Let's get into what we did right.

Great Clients

We have had some awesome clients over the past year and a half. I am pretty much happy with everyone we've had with the exception of the two clients I mentioned above. We have kept a balance of Startups and Enterprise, but we have been very careful about the people we work with. This is how I have boiled it down to the clients we want to work with:

Can they afford us? If you think it is callous to put this as the first thing we look for, then you are probably not someone we want to work with. We are running a business and there are plenty of great ideas out there and plenty of great people. But the sad fact is many of them cannot afford to build the applications they dream of, at least not through us. Financially vetting clients is very important. It makes no sense to waste our time in contract negotiations with someone that cannot afford our services. We try to discover this as soon as possible so we don't waste any of the client's time either. We try to make the best recommendation on the next steps they can take. We never take equity.
Is this an application we want to work on? I would make this the 2nd No. 1 if I could. While it is very important to make sure we have clients that can pay us so we can pay our employees it is equally important to make sure we have projects that our employees actually want to work on. This is something that I butted heads over with our Business Developer early on. He was not coming from a developer background and at the start did not know what projects were good and which were shit, from an engineering perspective. Consultancies are a feeding ground for other companies to poach from. We try to retain our employees by paying well and by keeping them on interesting and challenging projects.
Is this a project that helps us grow? This is something we have, over the past six months, started to think about when speaking with clients. Is this a project we would be proud to put in our portfolio? Is this a project we can write a case-study on? Is this a project that helps us make a sales pitch to an even larger client?

If we can stick to these three items when choosing clients I think we'll be fine. That is not always the case and from time to time we have had to sacrifice up the chain. So the first to go is #3, then #2, and finally #1 if we are desperate.

Our Tech Stack

While we started out as a Rails shop we have moved very quickly over the past year to brand ourselves also as an Ember shop.

I believe in Ember as a technology, it is superior to any other JavaScript framework out there in every way except for the learning curve. I see many developers that I have known in the Boston area hate on Ember. Good, let them. More for us. We also chose Ember for business reasons.

Competing with all of the other Rails shops in Boston is just stupid. Down the street we have one of the most well know Rails consultancies in the world (thoughtbot) and within a half a mile we have about 6 others lesser-known ones. From an ability perspective we are just as good as any of them, but then again that's the point of Rails. There is no technological advantage that any one shop has over another nowadays. We all pretty much do the same "best practices" and use nearly the same tech stack. There is nothing that distinguishes one shop from another. So we have diversified our offerings.

I chose Ember as a technology direction because it was, and still is, incredibly undervalued in the market. If I was playing a short game in our business I would invest in Angular, it is the tech-du-jour but a year from now I seriously doubt that will be the case. While everyone else is wasting their time specializing in Angular we're building an incredibly strong presence in the Ember world. When the scale tips we're going to be in a great position. At least that's the theory. Time will tell, maybe the next time I write on of these I'll be bitching about how wrong I was. We'll see.

Hiring

For the most part I've been very lucky with the team I've hired. Recently we just had our holiday party and I thought on my way to the dinner that this is the team I've always wanted. I can't imagine that is a very common thing for people to think. And that's not to say we haven't had missteps.

Finding The Right People

For us I hire for cultural fit. We have a good mix of senior and junior talent. If we hire a junior developer I only hire people that show an ability to learn fast. I really dislike white-board interviews so the face-to-face interview is for me to get a sense of their personality. Then I will ask some general knowledge questions to get a sense of where they are at skill-wise. I will then send the candidate away for a week and give them a project to create. I try to pick criteria that puts them outside of their comfort zone. Have they done TDD before, have they done Ember? I will ask them to challenge themselves and I will ask for access to the GitHub repository. One indicator I use is how soon did the candidate start this project? If it was started right away that shows an eagerness to complete the work. Was is started and finished the night before? This might show a tendency to procrastinate and get things in at the last minute. While these may be outside factors I do ask about them if they are extreme during the follow-up interview.

Recently we have been able to build enough of a name for ourselves in the development community where we have started to attract some good senior development talent. We are putting a pause on hiring junior developers and will likely focus on more senior developers for the next year.

Firing People

I've gotten permission to talk about this from Russ. Russ was a co-founder of DockYard and I fired him. It was around the time of the first post but I didn't want to reflect on it yet. In retrospect it was a long-term mistake but perhaps the correct short-term decision. We were not at the size when I was really thinking too long-term. I was not getting from him what I needed and it was weighing me down mentally, but this was my fault. I was not communicating to Russ properly what my expectations were. Thankfully we're still friends and grab drinks every now and then. If the roles were reversed I don't think I would be as magnanimous.

I've since fired two others. One was my fault, the other was not. It is a strange thing to fire someone. People try to make it nice by saying "let them go", but in reality you've shit-canned them. When you are employing someone, especially at a small company, you feel a sense of responsibility for them. You are paying them money and provide them with health care they use to take care of their family. I wish we could magically double the salaries of all of our employees but of course we cannot afford that. When it came time to firing someone it weighed on me and I considered the implications. I never did it lightly, but considering the alternative, each firing has turned out to be the correct move. Even with Russ, he's done much better without DockYard than he was doing with DockYard. Sometimes its not a good fit, I am guilty of letting things sit too long. I have learned to be quicker about acting upon this.

Losing People

We have so far lost just one employee, one of our DC partners Chris Gill. He got a job with the Department of Revenue that paid well beyond what we could afford. I was actually pretty proud of him that he landed it. I have left enough jobs in my career to know that I never want to be angry at someone that has decided to leave DockYard. If it is time to go, it is time to go. Considering the number of junior developers we have been training up I would like to think of it as an accomplishment of ours to see people "graduate" from DockYard and go on to do great things in the industry. (but don't leave us too quick!)

Business Development

In the summer of 2012 I was overwhelmed. I was Lead Developer, Business Developer, Office Manager, and Everything Else* at DockYard. The most important job I had was making sure new business was coming in. But focusing on that was having a negative impact on the client projects I was on as well as training any developers we had that required it. I started a search for a Business Developer. At first I hatched a plan to leverage the recruiters of Boston. It made sense: they already were talking to companies but it was difficult for those companies to hire. Why not just partner with DockYard and rent our services to those companies? At 8% the math actually worked out in their favor, however none of them bit. I'm still struggling with this one and I think it speaks to the state of recruitment. It was a good business opportunity but they could not think outside the box.

So it was time to find someone for that position. I had never made a non-technical hire before. I had no idea how to do that. I looked specifically for "Business Developers" but that was a bust. I gave up for a month or two then I realized that it was essentially a Sales position. So I put an ad out for a someone in sales looking to take on a larger role, a key role for the growth of a young company. I got about 50 resumes and brought in two people for interview. I liked them both and settled on the one with the better references. It was a great decision. Our Business Developer Dan Crowther has been huge for us. We butt heads on a few things; he's right sometimes and I'm right sometimes. But the fact is we would not be where we are today without him.

It took him about six months to really get comfortable with the position, this is very common from what I've been told of those transitioning into this position. He's helped us open up business we wouldn't have known about otherwise. And most important I can focus on other things.

We sell DockYard on the quality of our work. While we started as a technology company, design has become a large part of who DockYard is and has gone a long way to help sell our brand.

Design

Since our first "real" contract with Openbay we worked with an outside designer, Steven Trevathan. He was recommended to me by two separate people. Steve along with his partner Logan Faerber were starting their own consultancy Dobot. Steve and I got along well and I brought them back for a few more contracts. We bonded over our mutual disdain for many of the people in the C3 space at CIC and so when we finally got our own office last year I invited Steven and Logan to work from there. We even brought them along to check out the office spaces we were interested in. This past Spring it became obvious that we needed someone full-time at DockYard to take ownership of our design. Likewise Dobot was also looking for a lead engineer. It would be funny if it wasn't so stupid that we were literally sharing the same office, worked together on several projects, and were still looking for one another. Steve and I grabbed drinks and I laid it out: let's do this. He agreed and we brought Steve on as our Creative Director and a partner. Logan came on as a lead illustrator. It is the best move we've made to date. Steve and Logan quickly took ownership of the design direction of DockYard and have along with Amanda and Angelo put out a website that really represents who we are and have also put together some amazing designs for our clients.

While earlier I mentioned how it was very difficult to differentiate ourselves from other Rails shops, the one place we can totally do that is with design. Ultimately design sells much better than engineering. The engineering part of our contracts bring in more money, so we have to make certain that the design contracts we pick up will convert to engineering contracts. We look at design as the best Lead Generator we could get. It has worked, very well.

Office Manager

This is one that I was told multiple times that I should do sooner than later. I am very bad with context switching, I have to either do all business stuff one day or all of the engineering. I cannot do both effectively. After hiring Crowther I knew the next non-technical hire I wanted was an office manager. What I did might be considered overboard.

I put an ad on Craigslist. We got over 200 responses. I brought the list down to around 100 and sent out invites and asked people to schedule themselves for an interview through YouCanBook.me I blocked out over two weeks of time, and broke the interviews into 20 minute blocks. Over 60 interviews were scheduled. I ended up meeting with about 40 of people. It was one of the crazier things I've done but this was a position I had no idea how to hire and the only way I could figure to find the right person was to see a ton of candidates and waited to see what stuck. The person we hired was the 2nd person to walk through the door, Mariel Ebrahimi. We got real lucky, and I think I even came out of that interview and told everyone that we were probably going to hire her. However, considering she was only the 2nd candidate I still went through the next two weeks of interviews. It became obvious that she was well beyond anybody else coming in and over the past few months she has kept DockYard running smoothly. Being able to let go of these small things in the office is incredibly freeing and has allowed me to focus on the bigger picture.

I have been toying with the idea of hiring a Project Manager in Boston. We did that before in Washington, DC but we were in a very different position that we are now and I think the position only works for us, at our size, in Boston. I am currently running PM on most projects, at least to a certain degree. I allocate resources, and assign roles. Developers at DockYard look to me for what they should be doing next. It's time consuming and only gets worse as we grow. We'll see what happens in the next few months.

Building Our Own Products

We've tried it once and we failed. That simple. We failed for several reasons:

We could not work on the product consistently. This killed us. We were putting in days here and there in between client work. I was putting in hours on the weekend and this was burning me out for the rest of the week.
It was not an idea that was very good beyond concept. We built out a marketplace for Heroku called Igata It would allow developers to sell pre-baked applications for deployment on Heroku. I liked the challenge of building the initial technology. But when I began to think about the long term implications of maintaining a marketplace application I lost all interest.
Heroku was too much of an obstacle. I actually went out to Heroku and met with some of their people to pitch them on the idea. They liked it but it became clear that if we really wanted to make money we should just make our own Heroku and not lose the money on hosting. Then it was an easy mental jump to "let's forget about this marketplace and just compete with Heroku" which of course is a dumb idea.

So we bailed on the application and open sourced it. We are going to attempt another product built, this time we are going to save up a financial war chest so we can dedicate the proper amount of time to the project. I don't mind losing money on projects like this. They are fun to build and I think we come out the other end as a better shop once we dog food our own process.

Getting Our First Office

I was pretty annoyed with all of the entrepreneurial bullshit that was going on in the CIC in Cambridge. It is a terrible working environment, especially if you are a consultancy. You get bugged all the time by the worst people. The space is incredibly loud. If you go there to work on the weekends it's fantastic. But it became obvious very quickly that we needed our own office. We worked with Jon Frisch at T3 Advisors. We were growing and we need space to grow into. We decided upon a 2,200 square foot 2nd floor space in Downtown Crossing. I always wanted an office there because of how centrally located it was. Thankfully, Downtown Crossing ends up being much cheaper real-estate than many of the other places around Boston (although this is already changing).

We had some difficulty moving in. We were supposed to start the build-out in July of 2012. I was getting married in late August. The owner kept deflecting us, and deflecting. I went on my honeymoon and when I got back I asked him what the deal was. He said, "OK, it's no longer an active crime scene so I can tell you what happened."

It turns out that our office is a floor above a jewelery store. The floor in our office is concrete. Two guys broke down a side door to the vacant space, brought some mini-jackhammers and drilled a man-size hole into the store below. They then repelled down with ropes and started to clean the place out. There were some silent alarms that were set off and they got busted. Exactly why it took them 2 months to clear the place to allow us to build I don't know. But considering how crazy the story is I was OK with it.

Anyway, we finally got into the space in October of 2012. Thankfully no more jewelery heists have happened. We host a lot of community events at our office and I'm really happy with that. Currently we organize Boston Ember, Boston OpenHack, UX Boston, run classes for Girl Develop It Boston, and host Boston Postgres.

Starting Over

If I had to start DockYard from scratch today I would do it differently. The number one thing I would do different is not agree to a partnership until 6 months out. I would have awarded co-founder status to those that started, but I would have held off on awarding partnerships until everyone settled into their roles. I think when you first get going you don't really understand what those roles are. Assigning roles on day zero and expecting everyone to just stick to these roles is not realistic if this is everyone's first rodeo. Trial by fire is the best way to define the roles. Once that is done then the partnership can be established. Perhaps someone that previously thought being partner was a good idea was not actually interested in the added responsibility? Perhaps someone you didn't think was "partner material" ends up being one of your key people and that should be rewarded.

I would also hire a little more slowly than we did at first. I have not yet been able to pay myself what I've set my salary to. The first year I paid myself 25% of that salary. This year I've hit my goal of paying myself 50%. Next year I hope to hit 100% of that goal. Thankfully I've got a wife that makes a good living and we've been able to lean on that when I've needed to take myself off of payroll. If our situation were different I am not confident that DockYard would be around today, at least not in its currently form. I've been able to take risks that others might not be able to.

Conclusion

Any success we have had is due in part to not just the great team we have but honestly sometimes just luck. There have been several times in the past two years where I have not been able to sleep due to the stress of thinking how we were going to make the next few payrolls. Every time we got lucky, someone came along at the right moment and bailed us out. I would like to think we are out of those woods, we'll see.

One way I have changed how DockYard operates is moving away from always new clients to retaining clients. I had lunch with Andy Singleton and he stressed and convinced me that we were throwing away money by always looking for new clients. The really successful consultancies had several large contracts that would span multiple years. It was obvious but I had not seen it until it was spelled out for me. So we are going to look to retain and provide ongoing services for our existing clients. If someone is reading this and looking to get started that was probably one of our biggest mistakes over the past two years; find a client that you might even need to take a financial hit on but is always there to help you keep the lights on. Looking back it seem crazy that we were able to not just survive but thrive given out direction of always looking for greenfield projects.

In the next few years I don't want to see the same rate of growth we've previously had. I've said several times to my team I don't want to grow to more than 20. Any more than that and we'll have to consider some serious restructuring of the company. I also feel at that number the small team we have starts to feel more like a "real company". We just recently made an offer to a new member of our team that will be joining in January. I have not met her yet and that is strange to me, but is also an indicator that we have grown to that point that these things will happen.

I look forward to hearing the feedback from this article. I'm sure there will be people that disagree with some of the things I've said and the decisions we've made.

Simple Property Enum Cycling in Ember

2013-12-19 00:00:00

This is a quick one. I needed to cycle between the values in a set. Toggling between true and false in Ember is easy enough with the toggleProperty function but I had several properties I wanted to cycle between. So last night I wrote a simple function poorly named: cycleEnumProperty. You pass it the property you want to act upon and the enum set to cycle. If the property is currently empty or if the property matches the last value in the set the property will be set to the first value, otherwise the property will be set to the next value. Try it out:

Ember Starter Kit

Be A Blunt Axe

2013-12-18 00:00:00

Be A Blunt Axe

Something that was taught to us early on in College was how to make a "compliment sandwich." Iâm sure many of you have heard this term before, but for those of you who havenât, it's a communication tool that can keep yourself humble when confronted with the daunting task of giving others critical feedback on their work.

The idea is that you as the critic would point out a positive aspect about their work or concept, the top layer of bread if you will. Then youâd follow this by mentioning something they could improve upon, which is the meaty and true substance of the discussion. At the end youâd conclude by providing another positive aspect, a la the last bit of bread. The reason we had to come up with this step-by-step process when approaching a critique environment was to avoid hurting anyoneâs feelings. Rather than declaring an idea as stupid or bad, which honestly helps to accomplish nothing aside from increase the size of a criticâs ego, we had now formulated a way of give important and in-depth feedback that would actually help to improve an idea by simply being kind and genuinely interested in helping. Keeping to this method, people were much more adept to make the suggested improvements rather than declare themselves a failure, giving up before theyâve even begun to start.

It's important to remember that your feedback can and should be honest and frequent, but kindness prevails over being an asshole (every time). By being empathetic to the person receiving the critique, you get a better sense of what'll help them improve, rather than just tearing them down. With this, your critiques become genuine and no longer appear as a means to stroke an inflated ego. Without this, the whole world would be filled with broken hearts and ego-powered douche-bags. As they say, "an eye for an eye makes the whole world blind". Let's keep our eyes and hearts intact.

Introducing easydir.vim

2013-12-08 00:00:00

One of the things that I wish Vim had by default is the ability to create directories and files at the same time. Last month at our local OpenHack meetup, I had a conversation about it with a fellow developer and we both concluded that it wouldn't be too difficult to write something up.

Well, I'm happy to introduce easydir.vim!

It adds to the functionality of :new, :edit, :write, and more.

Here are some quick examples:

Edit a new file inside of a previously nonexistent directory.

  
  :e new_directory/new_file.txt

# Write some things to "new_file.txt" and save it.

:w

# The directory "new_directory/" and the file "new_file.txt"
# are saved!

Open the new directory and file into a split window.

  
  :sp another_directory/another_file.txt

# Write to "another_file.txt" and save the file.

:w

# another_directory/another_file.txt is saved!

Super nested directories

  
  :n thank/you/sir/may/i/have/another.txt

# Write some things to "another.txt" and save it.

:w

The directories and files will be saved under your current project's directory.

Thanks for checking it out and enjoy!

Never Stop Exploring

2013-12-06 00:00:00

Never Stop Exploring

Over the years, many artists seem to have fallen into a creative rut within their chosen career path. Some may have found a comfortable day job that sufficiently pays the bills. Others simply retired early, claiming to have burnt out creatively, and chose to throw in the artistic towel for a simpler lifestyle, one far less plagued by self doubt and critical objections, Iâm sure. Whatever the reason is, we as a society are more often selecting to pursue comfort over curiosity and I believe itâs hurting the progression of our personal artistic expression in both our culture and as individuals.

By choosing to accept whatâs handed to you by media, youâre merely absorbing otherâs ideas or predefined popular interests that have become media friendly rather than participating as part of the cultural influence. This accounts for many of the current trends that appear in graphic design, illustration, web design, music, and movies these days. How else would you have ended up with Independence Day, Mars Attacks, and Men in Black hitting the top box office charts all within the same year? You couldnât. Aliens and end of the world scenarios were accepted as hot topics at the time, but are any of them truly remembered as works of art? I would argue the answer to be, âNoâ. What makes something a genuine work of art is the passion with which it is made. A fresh and deeply personal idea that attempts to either break the rules of the medium or painstakingly craft them to best suit your particular need.

For example, as soon as iOS7 was shown to the public, a majority of the design communityâs reaction was negative. But as soon as this same operating system was made public and write-ups began appearing online from major figureheads in the industry, peopleâs views started to change, as did their designs. The same people who appeared to be so opposed to this recent announcement were beginning to cater their latest designs to having an extremely minimal feel, embracing extra thin typefaces and overly saturated primary colors. While I for one have definitely come to appreciate specific things about the iOS7 operating system, there are definitely things about itâs design that are not necessarily applicable to other interface scenarios. In short, just because a big company is successful with their design doesnât mean itâs the right fit for your project. No oneâs remembered for who theyâve copied. Theyâre remembered for what innovations theyâve made or new ideas theyâve brought to the table.

Whether this trend is a culturally specific problem or something that has plagued mankind for years, Iâm unsure. What I am sure of though is that I for one donât ever want to find myself in this predetermined rut. I think everyone has great ideas, and itâs important for them to take the time to properly express them. Itâs a matter of finding the motivation in yourself to make it happen and take the risk of making it public. As the great Bill Nye said, âEveryone you will ever meet knows something you don'tâ.

I for one keep a persistent list of ideas that I want to explore, both in a physical journal and on Wunderlist, just so that no matter how random the idea may seem, I can at the very least document it to be reviewed at a later date. When I do have down time between projects, I never have to search too hard for a new one to get started. For instance, my current side project is to keep an ongoing list of fictional band names that my friends and I have collected over the years and make actual merchandise out of them as if they were real bands. I treat these projects like tiny experiments and allow myself to try new things, technically and mentally. That way, when I do return to my other projects, they never feel stale. Iâm once again excited to work on them and have a new set of skills or ideas to help make them even better.

This is why I think itâs important that no matter what you do, whether itâs a full time design job, freelance illustration, or something far removed from the art profession you had originally pursued, to always keep your mind fresh with new ideas. Explore all possibilities and try new things whenever you can. The more you create, the more apt you are to legitimately think outside the box, rather than work within itâs constraints. And that, my friends is how you will be remembered, for being true to yourself and creating genuine, passionate work.

Buffers, Windows, Tabs... Oh My! Part 2: Vim Windows

2013-11-27 00:00:00

In the second part of this series, we'll be covering Vim windows. Windows are simply the viewports into buffers and I'm 110% sure that they are a huge part of your daily workflow.

Yes, there are numerous plugins that make our lives a lot easier, but let's dive into a powerful defaults that Vim offers us.

We'll first cover the basics, and then learn some neat window management commands.

Starting a Vim Session

One File

Vim windows are not complicated to use; if you want to open a file, file_one.txt, simply:

  
  $ vim file_one.txt

Multiple Files

If you want to open multiple files, file_one.txt, file_two.txt, and file_three.txt, you can do the following:

  
  $ vim file_one.txt file_two.txt file_three.txt

This opens the first file, file_one.txt, into a window. Files file_two.txt and file_three.txt are opened as inactive buffers.

Multiple Horizontal Splits

Say you want to view multiple files at once. Good news! You can open all files and place them into horizontal splits.

  
  $ vim -o file_one.txt file_two.txt file_three.txt

Multiple Vertical Splits

Don't like horizontal splits? Better news! You can open them all as vertical splits.

  
  $ vim -O file_one.txt file_two.txt file_three.txt

Within a Vim Session

There are two main arrangements for splitting windows, vertical and horizontal. Let's say we're editing a file and want to open up another file. We can do the following:

Horizontal Splits

This will open another_file.txt as horizontal split.

  
  :split another_file.txt

You can use this abbreviation:

  
  :sp another_file.txt

In addition, you can specify how large the new split will be by passing in a numerical value. This value will represent the line numbers shown within the split.

For example, this will reveal 25 lines of another_file.txt.

  
  :25sp another_file.txt

Lastly, you can open a split window with CTRL-W s.

Vertical Splits

You can open files as vertical splits as well.

  
  :vsplit another_file.txt

Which is abbreviated as:

  
  :vsp another_file.txt

Vertical splits can also take in a numerical value, which corresponds to the character width of the column.

  
  :30vsp another_file.txt

Finally, you can open a vertical split with CTRL-W v.

New Files

Let's create a new file.

Use, :new to create a new file inside the current window. After you save the file, it will be created within your current directory. You can also use the abbreviation :n.

  
  :n new_file.txt

If we specify the path, we can also create files inside existing directories.

  
  :n ../existing_dir/new_file.txt

Use :vnew or :vne to create a new file inside a new vertical split.

  
  :vne new_file.txt

Lastly, we can use CTRL-w n to create a new file inside a horizontal split. Note that we have not specified a file name. Upon saving the file with :w, we can give the file a name. Such that:

  
  # CTRL-w n

:w this_is_a_new_file.txt

Switching Windows

Switching windows ain't hard either!

CTRL-w h = Switch to the window to the left
CTRL-w j = Switch to the window below
CTRL-w k = Switch to the window above
CTRL-w l = Switch to the window to the right

Moving Windows

I've realized that window placement is incredibly useful when pairing with another person. Here's are a some ways to adjust the windows.

CTRL-w T = Move current window to a new tab
CTRL-w r = Rotates the windows from left to right - only if the windows are split vertically
CTRL-w R = Rotates the windows from right to left - only if the windows are split vertically
CTRL-w H = Move current window the far left and use the full height of the screen
CTRL-w J = Move current window the far bottom and use the full width of the screen
CTRL-w K = Move current window the far top and full width of the screen
CTRL-w L = Move current window the far right and full height of the screen

Resizing Windows

Sometimes windows open up funny or are rendered incorrectly after separating from an external monitor. Or maybe you want to make more room for an important file.

We can easily solve those problems with the following:

CTRL-w = = Resize the windows equally
CTRL-w > = Incrementally increase the window to the right
- Takes a parameter, e.g. CTRL-w 20 >
CTRL-w < = Incrementally increase the window to the left
- Takes a parameter, e.g. CTRL-w 20 <
CTRL-w - = Incrementally decrease the window's height
- Takes a parameter, e.g. CTRL-w 10 -
CTRL-w + = Incrementally increase the window's height
- Takes a parameter, e.g. CTRL-w 10 +

Wrapping Up

That was a lot to cover, but I do believe incorporating these commands into your workflow will prove pretty helpful. Thanks for reading!

Think

2013-11-15 00:00:00

Ever since Matt Aimonetti's talk at Wicked Good Ruby on there being such thing as bad code, I've felt I've needed to write a blog post about the cargo culting that happens in the development world.

Sandi Metz's Rules

Back in January, Sandi Metz was on Ruby Rogues to discuss her book, Practical Object-Oriented Design in Ruby. Out of this conversation came "Sandi Metz's rules". Many in the Ruby community took these rules as gospel, without knowing the context in which these rules were created.

The rules, for those unfamilar:

Your class can be no longer than 100 lines of code
Your methods can be no longer than five lines of code
You can pass no more than four parameters and you can't just make it one big hash
When a call comes into your Rails controller, you can only instantiate one object to do whatever it is that needs to be done

Sandi joined Matt during his talk at Wicked Good Ruby and gave some background to the story of her rules. To paraphase Sandi, at the time she was working with a group that had multi-thousand line controllers with multi-hundred line methods. These controllers and methods represented one end of a spectrum, which made code incredibly hard to read and maintain. They were begging Sandi for guidelines with which they could try to correct this problem. What she did was create a set of rules that lived on the opposite side of the extreme, to force them to meet somewhere in the middle.

In reality, these rules are a different way of looking at rules many of us strive for in the first place. An example: The 100 lines per class rule is really forcing you to create classes with the Single Responsibility Principle in mind.

My issue is not with these rules as they exist, but with the community's cargo culting of these rules and treating them as The Four Commandments. I don't have an issue with you following them, as long as you understand why they exist, and you feel as though they are principles you believe in. Don't just make five line methods because Sandi said so, and if you follow these rules, you feel like you'll be a great developer. Adhering to Sandi's rules does not make one great, it's understanding where these, or any rules, should and shouldn't apply. Sometimes a method that spans more than five lines will be more readable and maintainable than the same method spread across five or six 5-line methods. Striking that balance is where the power lies.

REMOTE

37signals just published REMOTE, a book about the benefits of allowing remote workers. I don't disagree that working remote has many benefits. At DockYard, we work from home from time to time. We also strive to have people in the office more often than not, not because Brian doesn't think we aren't working when we aren't in the office, but because it enables greater collaboration.

DockYard is a consultancy; we have client work with deadlines we have to meet. With having our developers and designers in the office together more often than not, it removes the latency from discussing issues. I can walk over to Steve and we can hash out an issue in a few minutes. If we were all remote, I'd have to ping him on HipChat, hope he's at his desk, try to go over the issue text-only until we realize we need to have a Google Hangout, etc. It makes more sense for us to be in the same place.

The other benefit of DockYard working from the office is that our junior developers enjoy the same face-to-face benefits. Also, body language makes a huge difference when teaching or learning topic. When someone pauses, has a slightly puzzled look on their face and says "....Ok", it easy to realize that a bit more background on the topic will really let them grasp the topic, but an "ok" in HipChat removes all the body language we could leverage.

Removing the latency between a junior developer having a question and getting the answer is crucial. If a junior developer has a question that's a show stopper, they can feel helpless while they wait for someone to be around to answer that question. That helplessness is killer; it makes someone feel like they aren't helping, and can potentially prevent them from asking other questions. If the that delay is interpreted as the senior developer blowing them off, they will be less inclined to ask questions in the future, hurting both themselves and the team.

A product company that employs experts (or creators) of a framework has a much different situation, where working remote makes a lot more sense. The conversations they have will be at a different level. They'll all have intimate knowledge of the code base, and so a few questions back and forth or a quick Google Hangout achieves a great deal. The conclusion was a result of the context they exist in. Remote workers work great for them because they have the perfect mix of experts in their domain; are working on products, which have very different requirements and issues of client work; and have a customer support group, which don't necessarily need to collaborate while working a customer through issues.

Figure Out What Works for YOU

In no way am I saying you should all work in the same office and disregard Sandi's rules. What I'm asking of the community is a bit of critical thought. Just because someone smart said one thing, it doesn't mean it's gospel. Realize that experience has led that person to that conclusion, weigh your experience against it, and apply it if you can.

Let's just not hope that the gods give us food because we made bamboo airplanes. Let's realize that moving to XYZ comes with both drawbacks and benefits, not just the benefits that everyone is touting.

Introducing Capybara-Extensions

2013-11-11 00:00:00

Today we're happy to announce CapybaraExtensions.

Testing with Capybara

We love Capybara at DockYard. We use it for virtually all of our integration tests and rely on it for writing tests that not only replicate how users flow through an application, but also for how they interact with page elements.

Briefly, let's take a look at a Rails application with and without Capybara. Without Capybara, inheriting from ActionDispatch::IntegrationTest provides some helpful RequestHelpers like get, which takes a path, some parameters, and headers (via RailsGuides):

  
  require 'test_helper'

class UserFlowsTest < ActionDispatch::IntegrationTest
  fixtures :users

  test "login and browse site" do
    # login via https
    https!
    get "/login"
    assert_response :success

    post_via_redirect "/login", username: users(:david).username, password: users(:david).password
    assert_equal '/welcome', path
    assert_equal 'Welcome david!', flash[:notice]

    https!(false)
    get "/posts/all"
    assert_response :success
    assert assigns(:products)
  end
end

Capybara adds some syntactic sugar with its Capybara::Session#visit method, and produces code that reads a lot cleaner and mimics how a user engages with the application:

  
  require 'test_helper'
require 'capybara'
require 'capybara_minitest_spec' # MiniTest::Spec expectations for Capybara

class PostsTest < ActionDispatch::IntegrationTest
  fixtures :users

  test "login and browse site" do
    visit login_path

    within find('form#session-new') do
      fill_in 'username', with: users(:david).username
      fill_in 'password', with: users(:david).password
      click_button 'Submit'
    end

    current_path.must_equal welcome_path
    page.must_have_content 'Welcome david!'

    visit posts_path
    page.must_have_content 'Welcome to ReefPoints!'
  end
end

Jonas Nicklas, who maintains Capybara, writes how the library leads to cleaner tests and clearer intent. This is exactly what we want from our tests, which not only test our code, but also document our application's behavior. A lot more could be written about this idea, but I'm going to assume I'm preaching to the choir here and jump into DockYard's newest gem: CapybaraExtensions.

CapybaraExtensions extends Capybara's finders and matchers. Our goal is to cull many of the find statements from our tests and remove the verbose CSS and xpath locators that come along with them.

Finders

find_<element>

The library contains helper methods for finding elements like form, table, and lists, as well as many HTML5 elements like article, aside, footer, and header.

So the above code in which we pass a CSS selector

  
  within find('form#session-new') do
  ...
end

becomes the following:

  
  within form('Login') do
  ...
end

In this example, "Login" is text found in the form. Passing the text contained within the element we're looking for better reflects what a user is thinking when she sees a form that says "Login."

Finder methods are also aliased so that you can call #form instead of #find_form (which you might expect from a finder method). This makes for better readability with the oft-used Capybara::Session#within method.

first_<element>

Each "find" method also has a corresponding "first" method. So when you have multiple article elements on a page with the text 'Lorem ipsum,' you can call first_article('Lorem ipsum') without returning an ambiguous match in Capybara.

<element>_number

In instances when you have lists or tables and you'd like to verify the content of a specific li or tr, CapybaraExtensions allows you to target the nth occurence of the element via #list_item_number and #row_number.

So given the following HTML:

  
  <ul>
  <li>John Doe</li>
  <li>Jane Doe</li>
  <li>Juan Doe</li>
</ul>

You can find the second li with:

  
  list_item_number(2) # => 'Jane Doe'

Use these methods for testing how elements are being ordered.

Matchers

CapybaraExtensions extends Capybara's matchers with methods for verifying the presence of images, the value of input fields, and the presence of meta tags. All of these methods return a boolean.

field_values

CapybaraExtensions comes with a #has_field_value? method which checks the value of a form field. Ensuring that your records save and update correctly should be the domain of your unit tests, however this method can come in handy when you're not persisting data to the back-end. For example, after performing a search, you may want to ensure that the query persists in the search field after redirect.

  
  within form('Search') do
  has_field_value?('search', 'capybara images')
end
# => true

images

Asserting that text appears on the page is easy with Capybara's #must_have_content method; asserting that a particular image appears has always been a little tougher. #must_have_image takes a hash with the src and/or alt attributes you're looking for. You can pass a string for either of these keys, and an instance of Regexp to the src attribute when you want to hone in on a portion of the src attribute without worrying about the rest of the URL.

  
  page.has_image?(src: 'http://gallery.photo.net/photo/8385754-md.jpg',
alt: 'Capybara')
# => true

meta_tags

#has_meta_tag checks the head for meta tags. Just pass in the name and content you're expecting to find. We use this method quite a bit to ensure that our pages are looking good from a search engine optimization standpoint.

  
  page.has_meta_tag?('title', 'Introducing CapybaraExtensions')
# => true

We hope this gem makes your tests a little more descriptive and your test_helper.rb a little lighter. As always, we welcome pull requests and issues via Github. Thanks!

Resources

Install CapybaraExtensions from Rubygems
Follow CapybaraExtensions on Github
Read up on CapybaraExtensions on RubyDoc.info

Design Patterns: The Command Pattern

2013-11-05 00:00:00

Let's get ready for some football!

One of my favorite sports is American football; it's strategic, physical, and wild! As a fan - and once high school player - of the sport, I've gained some valuable lessons from my experiences. For example, I've learned that "persistence is key", "giving up is for losers", and that "water sucks, Gatorade is better."

While those are fine gems of wisdom, today we'll be covering one of the most overlooked teachings in football: the power of Command pattern.

The Command design pattern intends to separate and decouple an object of invocation from the object that receives the message of invocation. We will encapsulate all pertinent information of a method and execute the method at a later time. Essentially, the Command pattern gives us the ability to queue a series of operations for a later time. Let's dig in.

Put me in, Coach!

Let's start by creating a BostonNarwin class from which our football players will inherit from.

  
  # football.rb

class BostonNarwin
  attr_reader :action

  def initialize(action)
    @action = action
  end

  def name
    self.class
  end
end

Next, we'll need some key players; let's create Quarterback and Receiver classes. For fun, we're going to add a TeamOwner class too. All three of these classes are going to possess a method called #execute.

Each of these classes can be considered as instances of separate commands.

  
  # football.rb

class Quarterback < BostonNarwin
  attr_reader :path, :play

  def initialize(path, play)
    super 'Hut! Hut! Red 19! Red 19! Hike!'
    @path = path
    @play = play
  end

  def execute
    file = File.open path, 'w'
    file.write "#{name}: #{play}\n"
    file.close
  end
end

class Receiver < BostonNarwin
  attr_reader :path, :play

  def initialize(path, play)
    super 'Run, run, run!!!'
    @path = path
    @play = play
  end

  def execute
    file = File.open path, 'a'
    file.write "#{name}: #{play}\n"
    file.close
  end
end

class TeamOwner < BostonNarwin
  attr_reader :path, :target

  def initialize(path, target)
    super "We are moving the team from #{prettify path} to #{prettify target}!"
    @path = path
    @target = target
  end

  def execute
    FileUtils.mv path, target
    file = File.open target, 'a'
    file.write "#{name}: We moved from #{prettify path} to #{prettify target}!"
    file.close
  end

  def prettify(pathname)
    (pathname.chomp File.extname(pathname)).capitalize
  end
end

Next, let's create a class that keeps track of the Quarterback, Receiver, and TeamOwner commands. We can use the Composite pattern to create this new class.

  
  # football.rb

class CompositeCommand < BostonNarwin
  attr_accessor :commands

  def initialize
    @commands = []
  end

  def add_command(*args)
    args.each { |arg| commands << arg }
  end

  def execute
    commands.each { |command| command.execute }
  end
end

Now, we can kickoff some football commands!

  
  load 'football.rb'

quarterback = Quarterback.new('boston.txt', 'I'm going to throw a perfect pass!')
# => #<Quarterback:0x007ff6f5c5c148
     @action="Hut! Hut! Red 19! Red 19! Hike!",
     @path="boston.txt",
     @play="I'm going to throw a perfect pass!">

receiver = Receiver.new('boston.txt', 'I'm going to catch the ball!')
# => #<Receiver:0x007ff6f5c949f8
     @action="Run, run, run!!!",
     @path="boston.txt",
     @play="I'm going to catch the ball!">

team_owner = TeamOwner.new('boston.txt', 'somerville.txt')
# => #<TeamOwner:0x007ff6f5ccd028
     @action="We are moving the team from Boston to Somerville!",
     @path="boston.txt",
     @target="somerville.txt">

Great! Now we'll create an instance of the CompositeCommand, add each sub-command with #add_command, and then execute each command with #execute.

  
  command = CompositeCommand.new
# => #<CompositeCommand:0x007ff6f5b82948 @commands=[]>

command.add_command quarterback, receiver, team_owner
# => [#<Quarterback:0x007ff6f5c5c148
     @action="Hut! Hut! Red 19! Red 19! Hike!",
     @path="boston.txt",
     @play="I'm going to throw a perfect pass!">,
     #<Receiver:0x007ff6f5c949f8
     @action="Run, run, run!!!",
     @path="boston.txt",
     @play="I'm going to catch the ball!">,
     #<TeamOwner:0x007ff6f5ccd028
     @action="We are moving the team from Boston to Somerville!",
     @path="boston.txt",
     @target="somerville.txt">]

command.execute
# ...  Omitted for brevity ...

exit

Finally, let's list out the files in our current directory and view the contents of our recently created text file.

  
  $ ls
# => football.rb   somerville.txt

$ less somerville.txt
# => Quarterback: I'm going to throw a perfect pass!
     Receiver: I'm going to catch the ball!
     TeamOwner: We moved from Boston to Somerville!

Wow! The Command pattern in action!

Discussion

The Command pattern suggests that we create objects that perform specific tasks and actions. For our example, the Quarterback object created a file, the Receiver appended to the file, and the TeamOwner object moved it. Each of the command objects completed their action through CompositeCommand#execute.

Having one object, an instance of CompositeCommand, that executes all stored commands presents us with solutions ranging from simple file manipulation to user triggered interaction. The Command pattern also allows us to "store" and "remember" commands prior to and after execution.

Hope you enjoyed our example and go Boston Narwins!

Buffers, Windows, Tabs... Oh My! Part 1: Vim Buffers

2013-10-22 00:00:00

First off, GO SOX!!!11

Now that I've reinforced my allegiance to America's favorite baseball team, let's talk about Vim. In this series of posts, we'll explore buffers, windows, and tabs.

Today, our topic will be buffers, editable files that are available in-memory.

When you first open a file through a Vim session, you are creating and working in a buffer, typically through a window. For the sake of today's discussion, we will consider working with multiple buffers through only one window, our viewport of the working buffer.

Let's open a buffer

We're going to setup an easy exercise for today's post. If you don't want to follow along, feel free to try the exercise in your own project.

Let's create a dummy directory and some of text files:

  
  mkdir dummy && cd dummy
echo 'The Red Sox rule!' > redsox.txt && echo 'Cardinals drool!' > cardinals.txt

Next, open up the redsox.txt file.

  
  vim redsox.txt      # => The Red Sox rule!

Congratulations, you're already using buffers!

Buffer indicators

Let's open the cardinals.txt file in a hidden buffer. We can accomplish this through the current redsox.txt buffer by using :badd or :bad. Next, we'll list out all buffers, hidden or active, with :ls.

  
  # Inside the current buffer, get into Vim's command mode and use the command `:badd`.
# List all buffers with `:ls`.

:badd candinals.txt     # 'badd' => 'Buffer ADD'
                        # You can also use `:bad`
:ls
  ### =>   1    %a   "redsox.txt"              line 1
           2         "cardinals.txt"           line 1

The :ls command returns information about each buffer: the unique buffer number, buffer indicators, file name, and the line number of your current position within the file.

Buffer number: A unique number to identify individual buffers.
Buffer indicators:
- %: buffer in the current window
- #: alternate buffer, which can be accessed by CTRL-6
- a: active buffer, loaded and visible
- h: hidden buffer, loaded but not visible
- -: a buffer that cannot be modified, modifiable off
- =: a buffer that is readonly
- +: a buffer that has been successfully modified
- x: a buffer with read errors
- : if there is no buffer indicator, it signifies a buffer that has not been loaded yet
Buffer name: The name of the file.
Buffer line number: The current line number that the cursor is on.

Working with multiple buffers

As we can see, our cardinals.txt has yet to be loaded. Let's open it into our window and view our current buffers.

  
  :e cardinals.txt   # => Cardinals drool!

:ls
  ### =>   1    #    "redsox.txt"              line 1
           2    %a   "cardinals.txt"           line 1

Nice! We can see that our redsox.txt file is our alternate buffer. Let's switch to the redsox.txt by hitting CTRL-6.

Now we'll create a new text file, worldseries.txt, write World Series! inside that file, and check out our list of buffers.

  
  :e worldseries.txt   # Write "World Series!" inside the file and save it.
:ls
  ### =>   1    #    "redsox.txt"              line 1
           2         "cardinals.txt"           line 1
           3    %a   "worldseries.txt"         line 1

Our alternate buffer is the redsox.txt file. Remember, if we want to quickly switch to the alternate buffer, we can use CTRL-6. What if we want to open the cardinals.txt into our current window?

Well, we have a couple of options. From the worldseries.txt file, we can use the following vim commands:

:bp : Switch to the previous buffer
:b2 : Switch to buffer number 2
- :b : Takes a buffer number as an argument

Go ahead and give it a try.

Here are some other pertinent buffer commands:

:bn : Switch to the next buffer
:ball : Open all buffers into windows
:brew : Go back to the first buffer in the list - "Buffer REWind"
:bd : Delete the buffer - also takes buffer numbers as arguments
- :bd 1 2 3 : Will remove buffer numbers 1, 2, and 3
- Note: :q is not the same as :bd... try it and verify with :ls!

So what good are buffers?

To be honest, I just realized the power of buffers about a month ago. Previously, thanks to a large monitor, I would have multtple windows - as many as 6-8 - open during one Vim session. Multiple windows are great, however, if I really needed to focus on a few files, I'd have to close each insignificant file window.

Nowadays, my workflow comprises of two or three windows, with multiple buffers in the background. This has allowed me to rapidly move between files that I actively open and edit.

Remapping buffer commands

Here are some key remappings that speed up buffer movement:

  
  " ~/.vimrc (or wherever else you keep your .vimrc)

" Move to the previous buffer with "gp"
nnoremap gp :bp<CR>

" Move to the next buffer with "gn"
nnoremap gn :bn<CR>

" List all possible buffers with "gl"
nnoremap gl :ls<CR>

" List all possible buffers with "gb" and accept a new buffer argument [1]
nnoremap gb :ls<CR>:b

Note: Remapping gp will remove the Vim default functionality of gp. Use :h gp to read more about it.

Hope that provides some insight into the capabilities of Vim buffers! If there is anything you'd like to add, please feel free and comment in the discussion area. Thanks!

[1] Special thanks to romainl.

Namespaced Pages

2013-10-06 00:00:00

Simple Namespacing

We've been using our Pages gem in nearly all of our projects for over a year now. Its been great but could only support pages on the root. I just released 0.2.0 of the gem that now supports namespacing:

  
  namespace :work do
  pages :client_1, :client_2
end

This will give you the routes of /work/client_1 and /work/client_2. Your views will go into app/views/work/pages. For more details see the README.

In a future release of Pages we plan on adding support automatic pages. For example, you will no longer need to declare the pages in your config/routes.rb file. As long as the templates exist in the app/views/pages directory the route will happen automatically. In addition we will also add support for pages nested under different namespaces, or accessible from certain authentication state. All in the name of serving up static page goodness!

Design Patterns: The Composite Pattern

2013-10-01 00:00:00

Coffee Coffee

If you're anything like me, you'll agree that every morning needs to start out with a cup of coffee. And, if you're anything like me, you'll have at least three different coffee making apparatuses. And, if you're anything like me... you'll soon realize you may have an addiction.

Joke aside, each coffee contraption requires a specific procedure to be completed in order to brew a cup of joe; each having multiple parts, taking differing amounts of time, requiring various numbers of steps, etc.

Our coffee making process can be described by a basic example of the Composite method pattern.

The Best Part of Waking Up is a Composite Pattern in Your Cup

We can start by thinking of each coffee maker and coffee related task as a subclass of our CoffeeRoutine. CoffeeRoutine will be known as the component, the base class or interface that possesses the commonalities of simple and complex objects. CoffeeRoutine#time is the common trait among all coffee related classes.

  
  class CoffeeRoutine
  attr_reader :task

  def initialize(task)
    @task = task
  end

  def time
    0.0
  end
end

Next, we'll create a couple of leaf classes, which represent indivisble portions of our pattern. Here are a couple of leaf classes that come to mind: GrindCoffee and BoilWater. These leaf classes are our most basic steps to making coffee.

  
  class GrindCoffee < CoffeeRoutine
  def initialize
    super 'Grinding some coffee!'
  end

  def time
    0.5
  end
end

class BoilWater < CoffeeRoutine
  def initialize
    super 'Boiling some water!'
  end

  def time
    4.0
  end
end

class AddCoffee < CoffeeRoutine
  def initialize
    super 'Adding in the coffee!'
  end

  def time
    1.0
  end
end

  
  g = GrindCoffee.new

g.task    # => 'Grinding some coffee!'
g.time    # => 0.5

Now, we can get to the namesake of the pattern: the composite class. A composite class is a component that also contain subcomponents. Composite classes can be made up of smaller composite classes or leaf classes.

Our various coffee making apparatuses can be thought of as composites. Let's check out the FrenchPress class:

  
  class FrenchPress < CoffeeRoutine
  attr_reader :task, :steps

  def initialize(task)
    super 'Using the French press to make coffee'
    @steps = []
    add_step BoilWater.new
    add_step GrindCoffee.new
    add_step AddCoffee.new
  end

  def add_step(step)
    steps << step
  end

  def remove_step(step)
    steps.delete step
  end

  def time_required
    total_time = 0.0
    steps.each { |step| total_time += step.time }
    total_time
  end
end

However, we can simplify the FrenchPress class by pulling out the composite functionality into its own class.

  
  class CompositeTasks < CoffeeRoutine
  attr_reader :task, :steps

  def initialize(task)
    @steps = []
  end

  def add_step(step)
    steps << step
  end

  def remove_step(step)
    steps.delete step
  end

  def time_required
    total_time = 0.0
    steps.each { |step| total_time += step.time }
    total_time
  end
end

Now we can create composite coffee makers easily... They'll look something like this:

  
  class FrenchPress < CompositeTasks
  def initialize
    super 'Using the FrenchPress to make coffee!!!'
    add_step GrindCoffee.new
    add_step BoilWater.new
    add_step AddCoffee.new
    # ... Omitted actual steps to make coffee from a French press ...
    # ... Imagine PressPlunger class has been defined already ...
    add_step PressPlunger.new
  end
end

class DripMaker < CompositeTasks
  def initialize
    super 'Using the DripMaker to make coffee!!!'
    add_step GrindCoffee.new
    add_step BoilWater
    add_step AddCoffee.new
    # ... Imagine PressStartButton class has been defined already ...
    add_step PressStartButton.new
  end
end

Swell... now we can call the FrenchPress and DripMaker coffee makers.

  
  frenchpress = FrenchPress.new

# => #<FrenchPress:0x007f88fcf46410
       @task="Using the FrenchPress to make coffee!!!",
       @steps=
         [#<GrindCoffee:0x007f88fcf46370 @step="Grinding some coffee!">,
         #<BoilWater:0x007f88fcf46320 @step="Boiling some water!">]>
         #<AddCoffee:0x007f88fcf46329 @step="Adding in the coffee!">]>
         #<PressPlunger:0x007f88fcf46098 @step="Pressing the plunger down!">]>

dripmaker = DripMaker.new

# => #<DripMaker:0x137t88fcf57109
       @task="Using the DripMaker to make coffee!!!",
       @steps=
         [#<GrindCoffee:0x007f88fcf46370 @step="Grinding some coffee!">,
         #<BoilWater:0x007f88fcf52520 @step="Boiling some water!">]>
         #<AddCoffee:0x007f88fcf46123 @step="Adding in the coffee!">]>
         #<PressStartButton:0x007f88fcf46432 @step="Pushing the start button!">]>

Now we can also check the time required for each coffee maker.

  
  frenchpress.time_required # => 12.4
dripmaker.time_required   # => 8.5

Discussion

Implementing the Composite pattern is pretty simple.

We create a component class that ties the numerous simple and complex characteristics together. In our example, CoffeeRoutine defines an elementary method #time and each child class implements its own amount.

Next, we create leaf classes, AddCoffee, BoilWater, and GrindCoffee, that share the same characteristics with one another. Remember that it's the nature of leaf classes to be simple. If you happen across a leaf class that could be broken up, it might potentially be a composite class in disguise. Break up those actions into individual leaf classes and turn the original class into a composite. All of our leaf classes had a #time method.

The composite class handles all the subtasks, essentially using the child classes at its will. We can see that our two composite classes and their methods, FrenchPress#time_required and DripMaker#time_required. manipulate the method #time from the leaf classes. Ultimately, our coffee makers are able to treat each step, GrindCoffee, BoilWater and AddCoffee uniformly.

Hope this helps you with your morning routine!

Vim: Moving Lines Ain't Hard

2013-09-26 00:00:00

In the last post, we briefly discussed the power of the map command. In today's post, we're going to use map again in order to move lines and blocks around.

Let's use an example: Our goal is to move the first line to its proper location. From this:

  
  --- second line ---
--- third line ---
--- first line ---

To this:

  
  --- first line ---
--- second line ---
--- third line ---

Delete, Then Paste

Here is one of the most common ways, it ain't pretty but it gets the job done. We'll delete the desired line and paste it to the target location.

  
  --- second line ---
--- third line ---
--- first line ---

# Delete the "first line", move to the "second line", and paste the registered
# "first line" above the "second line".
#
# :3 --> <ENTER> --> dd --> j --> P
#
# or...
#
# :3d --> <ENTER> --> :2P --> <ENTER>

I Like the Way You Move

The second way, use the move command with :m. I like this method a lot, as it requires fewer keystrokes. It does require line numbers though. When using absolute line numbers, the destination will be below the line number you specify, so use :m0 to move to the top of the file. Try using hybrid mode.

  
  --- second line ---
--- third line ---
--- first line ---

# Move your cursor on the "first line" (the third line), use the *move* command and
# pass your desired line number as an argument. Hit enter.
#
# :3 --> <ENTER> --> :m0 --> <ENTER>
#
# or...
#
# :3m0 --> <ENTER>

Lazy Moving

Now getting to the map command, I've found this pretty handy when I need to move a line or block of lines a couple of lines upward or downward.

  
  " In your ~/.vimrc
"
" Normal mode
nnoremap <C-j> :m .+1<CR>==
nnoremap <C-k> :m .-2<CR>==

" Insert mode
inoremap <C-j> <ESC>:m .+1<CR>==gi
inoremap <C-k> <ESC>:m .-2<CR>==gi

" Visual mode
vnoremap <C-j> :m '>+1<CR>gv=gv
vnoremap <C-k> :m '<-2<CR>gv=gv

Now you can move lines by holding CTRL and j (for up a line) or k (for down a line).

  
  --- second line ---
--- third line ---
--- first line ---

# Move to the "first line", hold <CTRL> and move up twice.
#
# :3 --> <ENTER> --> <CTRL> + kk

Now let's move a block of lines:

  
  --- fourth line ---
--- fifth line ---
--- first line ---
--- second line ---
--- third line ---

# Move to the "first line".
# Select the "first line", "second line", and the "third line" with Visual mode.
# Hit CTRL and move upwards twice.
#
# :3 -- <ENTER> --> <SHIFT> + V --> jj --> <CTRL> + kk

Other Ways

There are plenty of other tricks that move around lines in Vim. The preceding examples were just a few that I employ everyday. If you've got something cool to share, please let me know!

Vim: Staying on Home Row via Map

2013-09-11 00:00:00

Here at DockYard, the majority of us are using Vim. I don't want to write about the benefits of using this sweet editor, as that would take too long, but instead, I'd like to share a couple of my favorite mappings for escaping and saving files.

Vanilla Vim: Escaping and Saving

Escaping out to Normal mode from the other modes in Vim is straightforward: simply hit the Esc key. Saving files is accomplished by, from Normal mode, pressing :w and then Enter.

So... What's the Problem?

During a session, especially when I'm writing large pieces of text, I'd find myself in a repetitive rut:

I just typed out a couple of sentences and want to save my progress
I'd remove my left hand from home row to hit the Esc key
Saving the file required me, once again to leave home row, to hit :w and then the Enter or the Return key
To continue on, I'd press i and type along
Repeat, repeat, repeat...

See where I'm getting at?

Let's Talk About Map

Before we review and copy-pasta the portion of my .vimrc, let's briefly go over the very basics of the pertinent map commands. You can find the entire map documentation here or by typing :help map within a Vim session.

Protip: To open help texts into a full buffer, :h map | only or to open them in a separate tab :tab h map.

Recursive Map

First, we're going to talk about recursive map commands. A recursive command will transform one result to another result, if there is another binding to that key. An example can be found at the .vimrc below.

Here are the basic recursive map commands.

map - command to transform the operation of typed keys within ALL modes

You can prepend the first letter of the desired mode to map.

nmap - transform the operation of typed keys within Normal mode
imap - transform the operations of typed keys within Insert mode
vmap - transform the operations of typed keys within Visual and Select mode

For example, if I had this within my .vimrc:

  
  " ~/.vimrc
"
" Note: double quotes signifies comments

nmap 0 gg
imap n N

" Time for a little recursive map
imap d D
imap D wat

Since 0 is mapped to gg within Normal mode, I'll be sent to the top of the file by pressing 0. Moreover, while in Insert mode, every character n that I type will turn into N. Lastly, because of the recursive mapping, typing d in Insert mode will return wat. You can think of it as something like: d => D => wat.

Thankfully, there's a non-recursive map.

Non-recursive Map

Non-recursive map commands are signified by adding nore after the mode modifier.

nnoremap - non-recursive map for Normal mode
inoremap - non-recursive map for Insert mode
vnoremap - non-recursive map for Visual and Select mode

  
  " ~/.vimrc

inoremap c C
inoremap C nope

Now, in Insert mode, if we type c, we will return C; the transformation of c to nope will not occur.

Enter the .vimrc

Now that we got the basics out of the way, here is an example of my .vimrc.

  
  " ~/.vimrc
" *** The Two Hand system ***
"
" <Cr> signifies the "return" key

inoremap ;a <Esc>
inoremap ;d <Esc>:update<Cr>
inoremap ;f <C-O>:update<Cr>
nnoremap ;f :update<CR>

I'm using :update here, which is "like :write, but only write when the buffer has been modified."

Let's go over these mappings.

The first one, inoremap ;a <Esc> maps the semi-colon and a key together when in Insert mode. By pressing ; and then a immediately afterwards, we mimic the functionality of the Escape key.

The second map, inoremap ;d <Esc>:update<Cr> maps the semi-colon and the d key. Pressing ; and then d immediately afterwards returns the sequence of:

From Insert mode, escape to Normal mode
Type : to get inside the Command mode, and type the update command
Complete the sequence by "hitting" Return, thus saving the file

The third map command, inoremap ;f <C-O>:update<Cr>, allows us to type ; and then f to return:

From Insert mode, escape out to Normal with <C-O>, which allows us to escape out for ONE command.
Type : to get inside Command mode, and then type udpate. This is our one command for <C-O>
"Hit" the Return, thus saving the file
We're back in Insert mode, thanks to <C-O>

Finally, the nnoremap ;f :update<CR> mapping means by typing ; and then f in Normal mode, it will result in:

Since, we're already in Normal mode, we get into Command mode by typing :
Type the update command
"Hit" the Return key, and save the file
We remain in Normal mode

The snippet below restricts these commands to your right hand.

  
  " ~/.vimrc
" *** The Right Hand system ***

inoremap ;l <Esc>
inoremap ;k <Esc>:update<Cr>
inoremap ;j <C-O>:update<Cr>
nnoremap ;j :update<CR>

As you can see, I kept ; as a prefix to my map commands. This conveniently keeps me at homerow. I've played with mapping everything with my right hand, but it just didn't feel "right" (apologies for the bad pun).

Overall, this snippet makes me happy and I believe this will make your day as well. If there are some other tricks concerning escaping and saving files, please let me know in the comments! Thanks!

Postgres_ext adds rank and common table expressions

2013-09-06 00:00:00

This week, I released postgres_ext 2.1.0, which includes ActiveRecord::Relation methods to simplify queries that require the use of Common Table Expressions (CTEs) and the rank() windowing function.

Common Table Expressions

In a sentence, CTEs allow you to define a temporary table to be used in a larger query. Let's look at an example:

  
  WITH scores_for_game AS (
SELECT *
FROM scores
WHERE game_id = 1
)
SELECT *
FROM scores_for_game

In the above, somewhat arbitrary, example, we create a temporary table of scores_for_game which we then select from. CTEs allow you to organize your more complex queries, and can be really helpful in certain cases.

We can make the same SQL call in ActiveRecord with postgres_ext.

  
  Score.from_cte('scores_for_game', Score.where(game_id: 1))

We can also query against the CTE expression by chaining off the resulting ActiveRecord::Relation

  
  Score.from_cte('scores_for_game',
  Score.where(game_id: 1)).where(user_id: 1)

would generate the following:

  
  WITH scores_for_game AS (
SELECT *
FROM scores
WHERE game_id = 1
)
SELECT *
FROM scores_for_game
WHERE scores_for_game.user_id = 1

You can also include CTEs in your normal queries to join against by using with

  
  Score.with(my_games: Game.where(id: 1)).joins('JOIN my_games ON scores.game_id = my_games.id')

will generate the following SQL:

  
  WITH my_games AS (
SELECT games.*
FROM games
WHERE games.id = 1
)
SELECT *
FROM scores
JOIN my_games
ON scores.games_id = my_games.id

Rank

PostgreSQL provides a rank windowing function, which will take into account ties when ranking results. You would add rank to your projection, like the following example:

  
  SELECT scores.*, rank() OVER (ORDER BY scores.points DESC)
FROM scores

The results set will return ordered by the rank, which is determined the order passed into the rank's OVER. In the above example, the scores would be ranked by their scores descending, so highest score first. If there was a tie at first place between two scores, they would both ranked 1, and the next result would be ranked 3. We can achieve the same in ActiveRecord with postgres_ext:

  
  Score.ranked(points: :desc)
# or
Score.ranked('points desc')

Rank will rank independently of any sort order applied to the query, so you could have your scores ranked by points, but then ordered by their creation time.

  
  Score.ranked(points: :desc).order(:created_at)

will generate the following query:

  
  SELECT scores.*, rank() OVER (ORDER BY scores.points DESC)
FROM scores
ORDER BY scores.created_at ASC

Also, if you apply a sort order to your relation, and want to sort by it, you do not have to tell ranked what order you'd like to use, as it will reuse the order.

  
  Score.ranked.order(points: :desc)

One thing to watch out for if you use ranked without an explicit order and want to call first off your relation, if the results of the relation have yet to be retrieved, the first will use your table's primary key for an ORDER BY statement on the query. This has already bitten us before we discovered the behavior of first. To avoid this behavior in first, use take which does not use any implied order.

We've been using CTEs and rank on one of our client projects, and it's already cleaned up the from_sql queries we were previously using. Let us know if you hit any snags, or have any suggestions on how else we can make complex SQL queries easier to call from ActiveRecord! We only implement the rank windowing function right now, but plan to add the others shortly.

Computed Properties in Ember.Js

2013-09-04 00:00:00

Note: Short version of this post is a part of Ember.Js Guides.

What Are Computed Properties?

In a nutshell, it's a property whose value is computed the first time it's asked for. You can define the computed property as a function and when someone asks for it, Ember will automatically invoke the function and treat the return value like value of the property.

Here's a very well-known example:

  
  App.Person = Ember.Object.extend({
  firstName: null,
  lastName: null,
  fullName: function() {
    return this.get('firstName') + ' ' + this.get('lastName');
  }.property('firstName', 'lastName')
});

var ironMan = Person.create({
  firstName: "Tony",
  lastName:  "Stark"
});

ironMan.get('fullName');
// "Tony Stark"

The code above defines a computed property fullName by calling property() on the function with two dependencies firstName and lastName and whenever it gets called, it returns firstName + lastName.

Inception

Let's take a look at another example. Say we want to add a description computed property to App.Person. It will aggregate other properties like fullName, age, country:

  
  App.Person = Ember.Object.extend({
  firstName: null,
  lastName: null,
  age: null,
  country: null,
  fullName: function() {
    return this.get('firstName') + ' ' + this.get('lastName');
  }.property('firstName', 'lastName'),
  description: function() {
    return this.get('fullName') + '; Age: ' +
           this.get('age') + '; Country: ' +
           this.get('country');
  }.property('fullName', 'age', 'country')
});

var captainAmerica = Person.create({
  fullName: 'Steve Rogers',
  age: 80,
  country: 'USA'
});

captainAmerica.get('description');
// "Steve Rogers; Age: 80; Country: USA"

Notice that you can use an existing computed property as a dependency for a new one.

Caching

By default, all computed properties are cached. That means that once you requested the value of computed property (called get on it), it's going to compute and cache its value:

  
  captainAmerica.get('description');
// computes the value and returns "Steve Rogers; Age: 80; Country: USA"
captainAmerica.get('description');
// returns cached "Steve Rogers; Age: 80; Country: USA"

A computed property gets recomputed when any of the properties it depends on change:

  
  captainAmerica.set('country', 'United States of America');
captainAmerica.get('description'); // computes the value and returns"Steve Rogers; Age: 80; Country: United States of America"

Read Only

This property is false by default. You won't be able to set the value of the computed property if you call readOnly on it:

  
  App.Person = Ember.Object.extend({
  description: function() {
    // implementation
  }.property('fullName', 'age', 'country').readOnly()
});

var captainAmerica = Person.create();
captainAmerica.set('description', 'hero');
// "Cannot Set: description on: <(unknown mixin):ember133>"

Alternative syntax for defining Computed Properties

This code:

  
  App.Person = Ember.Object.extend({
  firstName: null,
  lastName: null,
  fullName: Ember.computed('firstName', 'lastName', function() {
    return this.get('firstName') + ' ' + this.get('lastName');
  })
});

does exactly the same thing as this code:

  
  App.Person = Ember.Object.extend({
  firstName: null,
  lastName: null,
  fullName: function() {
    return this.get('firstName') + ' ' + this.get('lastName');
  }.property('firstName', 'lastName')
});

with the difference that the first example works if you disable Ember's prototype extension.

How are Computed Properties different from Observers and Bindings?

The concept of observer is pretty simple. You have something that you want to track the change of. You add an observer to it, so next time it changes, a certain event is going to be fired notifying you that that something has changed.

There are two types of observers: before (observesBefore) and after (observes). When observer event (callback) is fired, it's called with two arguments: obj and keyName. It doesn't pass the value of the property to the event (callback). The reason is because the property you're watching might be lazily computed.

Observers are used by CP internally to invalidate CP's cache when its dependency keys were changed. Observers (like CPs) don't use runloop magic (fired "right away").

Observers are not going to fire if the value is unchanged from before (changing existing lastName from Stark to Stark won't trigger the observer callback).

Bindings is an internal concept that is not meant to be used. I'm not saying you can't, it's better not to. Typically, you don't need to use it in your application, using CP is plenty enough.

Bindings are meant to keep a property of two objects in sync. Their update (sync) happens through run loop, so there might be a period of time when two objects have the same property with different values and only by the end of a sync queue those values are going to be the same.

For example, in Ember those two objects are controller and view (any time a controller's property changes, view's property changes as well).

What do I use and when?

Computed properties are good for combining other properties or doing transformations on the property.

Observers are good for tracking changes of a property and reacting to them. Observers should contain behaviour that reacts to the change.

Bindings are used to make sure that the properties from the different objects are in sync. They are rarely used and most of the times can be replaced with computed properties.

Futher reading

You can read more about Computed Properties and Ember's Object Model over here. Happy Coding!

Alex Navasardyan is a DockYarder!

2013-09-04 00:00:00

Alex has been friend for a while now, I got to know him when I started attending the Boston Ember meetup. Alex has been a very active in the Ember.js community and helped with the 1.0 release last week as well as Ember.ListView

We're very dedicated to the future of Ember.js and with Alex on board we're well on our way to building out one of the best teams around.

Follow Alex on Twitter

Announcing Postgres_ext version 1.0 and 2.0

2013-08-23 00:00:00

Two versions of PostgresExt have been released today.

1.0.0 (and the 1-0-stable branch)

The 1.0.0 version is the first production release of PostgresExt. It supports Rails 3.2.x, adding in both data type and advanced querying support for ActiveRecord and Arel.

2.0.0

I have also released version 2.0.0, which supports ActiveRecord and Arel 4.0.x. Most of the 1.0.0 code is gone from 2.0.0, since Rails 4.0.0 supports all the data types that PostgresExt added to Rails 3.2.x.

The Future

I'm focusing on Rails 4.0.0 for all future features of PostgresExt. I will gladly pull in additional features for 1.0.0, but Rails 3.2.x is no longer the primary focus of PostgresExt. Maintenance on 1.0.0 will be minimal, since Rails 3.2.x will no longer be receiving releases for bug fixes, but pull requests for bug fixes would be graciously accepted.

Design Patterns: The Observer Pattern

2013-08-20 00:00:00

Note: We won't be going over the Ruby module Observable. Instead, we'll building out the pattern ourselves.

Your First Day at the NSA

Welcome to the National Security Agency, Agent Smith. You have quite an impressive background, and we believe your "go-getter" attitude will instill a new kind of vigor within the organization.

Your cubicle is down to the left... here are some NDAs for you to fill out. I'll swing by your desk in the afternoon and pick them up from you later. Oh, and before I forget, here is your first assignment.

Go get 'em, tiger!

The First Assignment

  
  Agent Smith
Spook First Class
[REDACTED]
NSA                                                     08-20-[REDACTED]

                     Operation [REDACTED] Observers

Welcome, Agent Smith:

Bluntly, we'd like to track everyone's emails.

Attached are two documents.

The first document will show you the basic structure of a typical email,
and the second document will provide you a basic profile of a suspicious
person.

If there are any questions, please reach me at [REDACTED].

Best of luck,

Agent [REDACTED]
[REDACTED]
[REDACTED]
NSA

  
  # Document 1:
# Basic structure of an email

module Email
  extend self

  def send(subject, sender, receiver)
    puts %Q[
      Subject: #{subject}
      From:    #{sender}@example.com
      To:      #{receiver}@example.com
      Date:    #{Time.now.asctime}
    ]
  end
end

  
  # Document 2:
# Characteristics of a suspicious person

class Person
  include Email
  attr_reader :name

  def initialize(name)
    @name = name
  end

  def send_email(subject, receiver)
    Email.send(subject, name, receiver)
  end
end

As we look through the Email module, we see that it contains Email.send which takes three arguments: subject, sender, and receiver.

Gazing at the suspicious Person class, we see that it includes the Email module. Person#send_email takes two parameters: a subject and a receiver. Person#name will stand in as the sender of the email.

Hypothetically, let's see how a suspicious person would send an email:

  
  bill = Person.new 'Bill'
bill.send_email 'Fishing Trip', 'Fred'
  # =>
      Subject: Fishing Trip
      From:    Bill@example.com
      To:      Fred@example.com
      Date:    Wed Aug 16 20:35:09 2006

Hmm... as you sit in your cubicle, you ponder the numerous possible ways of tracking emails. You won't need anything too complicated, just something to kick off a notification once an email has been sent.

Volia! You realize you can use the Observer pattern!

The Subject and its Observers

First, let's start off by creating two observer classes, Alert and Agent classes.

  
  class Alert
  def gotcha(person)
    puts "!!! ALERT: #{person.name.upcase} SENT AN EMAIL !!!"
  end
end

class Agent
  def gotcha(person)
    puts "!!! TIME TO DETAIN #{person.name.upcase} !!!"
  end
end

Next, let's create a Subject module.

  
  module Subject
  attr_reader :observers

  def initialize
    @observers = []
  end

  def add_observer(*observers)
    observers.each { |observer| @observers << observer }
  end

  def delete_observer(*observers)
    observers.each { |observer| @observers.delete(observer) }
  end

  private

  def notify_observers
    observers.each { |observer| observer.gotcha(self) }
  end
end

Here within the Subject#initialize, we create an empty array which will contain a list of observers. Subject#add_observer simply pushes our desired observers into the array.

Finally, we can alter the suspicious Person class, which will act as the subject class. Let's include the Subject module now.

  
  class Person
  include Email, Subject
  attr_reader :name

  def initialize(name)
    # 'super' requires a parentheses because we're calling
    # super on the superclass, 'Subject'
    super()
    @name = name
  end

  def send_email(subject, receiver)
    Email.send(subject, name, receiver)
    notify_observers
  end
end

Subject#notify_observers calls #gotcha on each observer, which informs each observer that Person#send_email has been kicked off.

Now let's give it a whirl...

  
  alert = Alert.new
agent = Agent.new

bill = Person.new 'Bill'

bill.add_observer alert, agent   # Bill now has two observers watching him

bill.send_email 'Fishing Trip', 'Fred'
  # =>
      Subject: Fishing Trip
      From:    Bill@example.com
      To:      Fred@example.com
      Date:    Wed Aug 16 20:35:09 2006

!!! ALERT: BILL SENT AN EMAIL !!!
!!! TIME TO DETAIN BILL !!!

Perfect, it works! Now we can start protecting our freedom!

Discussion

In our example above, we have two observers, the Alert and Agent classes, and a subject, Person. By creating the Subject module, any instance of Person now informs and updates any observer through #notify_observers, ultimately removing any implicit coupling from Alert and Agent.

There are a few similarities between the Observer and Strategy patterns. Both patterns employ an object (the Observer's subject and the Strategy's context) that makes calls to another object (the Observer's observer or Strategy's strategy). The difference between the two patterns is the purpose and use case. The Strategy pattern relies on the strategy to do the work, while the Observer pattern informs the observers of what is going on with the subject.

Hope you enjoyed this short example, thanks for reading!

Testing Context Validations

2013-08-05 00:00:00

Quick Refresher on ContextValidation

A few months ago, Brian released the ContextValidations gem. ContextValidations moves your model validations to the controller, allowing you to vary your validations by context, rather than relying on conditional validations.

Let's validate our user

We have a user model, that requires a password and a username when a user signs up. They can change their username and password, but if they can leave the password blank when updating their account, it will retain the old password. Whenever they enter a password , it must be 9 characters or greater. We're going to ignore the actual implementation of the password saving scheme and password confirmation in this example. Also, this example ignores setting up the test helper for valid_attribute and MiniTest::Spec.

Implementing the Tests and Validations in the Model

To test the above requirements model validations, we'd do the following:

  
  describe OldUser do
  describe 'new user' do
    subject { OldUser.new password: 'password_to_confirm' }

    it { must have_valid(:username).when('bob', 'test1234') }
    it { wont have_valid(:username).when('', nil) }
    it { must have_valid(:password).when('validpassword1234') }
    it { wont have_valid(:password).when('', nil, 'tooshort') }
  end

  describe 'existing user' do
    subject { old_users(:example) }

    it { must have_valid(:username).when('bob', 'test1234') }
    it { wont have_valid(:username).when('', nil) }
    it { must have_valid(:password).when('', nil, 'validpassword1234') }
    it { wont have_valid(:password).when('tooshort') }
  end
end

And here is the implementation of the model:

  
  class OldUser < ActiveRecord::Base
  attr_accessor :password
  validates :username, presence: true
  validates :password, presence: true, if: :new_record?
  validates :password, length: { minimum: 9 }, allow_blank: true
end

Implementing the Tests and Validations in the Controller with ContextValidations

We've been using ContextValidations with our client work since its release and realized we could unit test the controller to test the validations.

Our unit tests for the controller are here:

  
  describe UsersController do
  describe '#create' do
    subject { User.new(validations: validations_for(:create)) }

    it { must have_valid(:username).when('bob', 'test1234') }
    it { wont have_valid(:username).when('', nil) }
    it { must have_valid(:password).when('validpassword1234') }
    it { wont have_valid(:password).when('', nil, 'tooshort') }
  end

  describe '#update' do
    subject { User.new(validations: validations_for(:update)) }

    it { must have_valid(:username).when('bob', 'test1234') }
    it { wont have_valid(:username).when('', nil) }
    it { must have_valid(:password).when('', nil, 'validpassword1234') }
    it { wont have_valid(:password).when('tooshort') }
  end
end

Note the use of validations_for. It is a MiniTest helper method defined by ContextValidations, which looks up the name of the controller from the describe block, creates an instance of it, and retrieves the validations for the context passed in. This prevents you from needing to create your own instance and calling validations on it. The resulting tests end up looking very similar to what your model tests would look like.

Our model implementation is very light:

  
  class User < ActiveRecord::Base
  include ContextValidations::Model

  attr_accessor :password
end

And our validations are defined in the controller:

  
  class UsersController < ApplicationController
  include ContextValidations::Controller

  private

  def base_validations
    validates :username, presence: true
    validates :password, length: { minimum: 9 }, allow_blank: true
  end

  def create_validations
    validates :password, presence: true
  end
end

All of the examples are part of this repository.

Wrapping it up

As you can see, writing the validation tests for the controller are almost identical to writing them for the model. There are a few differences in setting up the subject for the tests, but the only major difference is that you are testing the controller instead of the model. If you have any feedback on the tests we came up with, feel free to let us know!

Putting things next to things with Susy

2013-07-29 00:00:00

I've often lamented that one of the most challenging things to do on the front end is to put things next to other things. Things on top of things? Easy. Things by themselves? Piece of cake. This thing next to that thing? Things just got complicated.

Should you roll your own layout, coming up with and refining conventions, browser testing to make sure everything still works? Do you rely on a front-end framework and all of the cluttered, confusing markup that comes going from that route?

What about something different? This is where Susy saves the day.

The little framework that can

Susy is a grid framework for Compass. With Susy, you simply define your grid settings and start laying things out. If you want to come back and adjust your grid later, that's totally fine. Susy will recalculate all your layouts.

  
  $total-columns: 12
$column-width: 4em
$gutter-width: 1em
$grid-padding: $gutter-width

Two main mixins do the bulk of the lifting. These are 'container' and 'span-columns'. Container is used to define the container of the grid. Span-columns is applied to elements within a container context. The syntax is easy.

  
  .page
  +container
  article
    +span-columns(8, 12)
  aside
    +span-columns(4 omega, 12)

This makes '.page' the grid container. The article takes up eight of twelve columns, the aside the final (omega) four of twelve columns.

Susy really shines at figuring stuff out on its own. Say I wanted to have two columns of different widths with different padding for each column, both nested within the article above?

  
  article
  +span-columns(8, 12)
  .one
    +span-columns(3, 7, 1em)
  .two
    +span-columns(4 omega, 7, .5em)

Where did the seven columns come from? Susy doesn't care. They are within the context of the article. Susy will figure out the math and make seven columns. The third option is the column padding. Susy will do the math there too. Thanks, Susy!

Susy, breakpoints and you

Susy is made to build responsive grids. The default layout is called 'magic'. It's a fixed width layout that fluidly scales if the viewport is smaller than the width of the grid. You can also opt for a fully fluid layout, or a static layout for pixel precision.

Any of these layouts can be further modified with the +at-breakpoint mixin. This mixin makes accessing media queries within the context of our grid simple and straightforward.

  
  .one, .two
  +at-breakpoint(30em)
    +span-columns(7, 7, .5em)

The one true grid

Everything Susy does is within context of a grid. You can define multiple grids, and nest these grids inside one another. You can define abritrary values within any context. Many useful features, such as push, pull, and bleed are there to make life even easier.

With all of this power comes some responsiblity. As with any tool, Susy just does what you ask it to do. It cannot explain why your layout isn't working. If you try to put too many things inside a grid, your layout will break. I'd recommend taking Susy for a spin. It's really easy to get started.

Design Patterns: The Strategy Pattern

2013-07-25 00:00:00

Walls are sooooo last week...

In our last post, we discussed the Template Method pattern and its benefits, finding it most useful when we need to simply shape behavior of subclasses. However, due to the reliance on inheritance, there are a couple of limitations to this pattern:

Subclasses are tightly bound to a superclass or baseclass
Runtime flexibility is hindered
Only a portion of the desired alogrithm is varied

Thankfully, there is another design pattern that resolves these problems: the Strategy pattern.

Summertime and the Livin' is Easy

Hot dogs, hamburgers, and veggie patties

It's the middle of July, and there's no better time to throw a day party. Our pals are bringing the tasty beverages, so we just need to prepare the food.

We'll first create a superclass Food that will delagate #type to its subclasses: HotDog, Hamburger, and VeggiePatty. Notice that this is the Template Method pattern in action.

  
  class Food
  def type
    raise NotImplementedError, 'Ask the subclass'
  end
end

class HotDog < Food
  def type
    'hot dogs'
  end
end

class Hamburger < Food
  def type
    'hamburgers'
  end
end

class VeggiePatty < Food
  def type
    'veggie patties'
  end
end

Now, let's get the grill ready.

  
  class Grill
  attr_accessor :food

  def initialize food
    @food = food
  end

  def grilling
    "Grilling the #{food.type}!"
  end
end

Nice. Now let's get grilling! We'll start with some hot dogs.

  
  grill = Grill.new(HotDog.new)
grill.grilling # => "Grilling the hot dogs!"

Oh watch out, these dogs are almost done... time to throw on the hamburger and veggie patties.

  
  grill.food = Hamburger.new
grill.grilling # => "Grilling the hamburgers!"

grill.food = VeggiePatty.new
grill.grilling # => "Grilling the veggie patties!"

Wasn't that easy? We were able to switch out items without creating a new class of Grill.

Discussion

Strategies and Context

The Strategy pattern employs strategies, objects of which possess identical behavior. Our grill party relies on strategies to tell us what #type of food they were. It's important that all strategy objects have the same responsiblity and support the same interface, which in our case was grill.grilling.

The Grill class is our context class, the operator of the strategies, which uses the HotDog#type, Hamburger#type, and VeggiePatty#type interchangeably.

Through our contrived example, we see the immediate benefits of this design pattern:

Separation of concerns
Strategies at runtime

We've achieved separation of concerns by designating the #type method as our desired set of strategies. HotDog, Hamburger and VeggiePatty are unaware of our implementation of Grill#grilling.

As for runtime flexibility, we're able to switch out the items up on the grill.

Special Patties: Lambdas

As we're grilling our hamburger and veggies patties, a last minute guest arrives, and she has brought some bacon, jalapeÃ±os, and onions. Let's make some custom patties, but avoid creating more subclasses of Food. What could we do here?

A quick and awesome solution would be to use lambdas!

Since we expect our strategies to return Strings for food #type, we can create a lambda which will behave just like the other strategy objects and return a String.

  
  CUSTOMPATTY = lambda { |type| "#{type}" }

Next, let's get back to our Grill class and alter the class a little bit.

  
  class Grill
  attr_accessor :food

  def initialize food
    @food = food
  end

  def grilling
    "Grilling the #{print_food}!"
  end

  private

  def print_food
    food_is_string? ? food : food.type
  end

  def food_is_string?
    food.is_a? String
  end
end

Since we know the strategies are Strings, we've created two private methods, #print_food and #food_is_string. #food_is_string will check if Grill has received a String or not, and #print_food will handle lambdas or classes of food.

Now let's try grilling some hot dogs and custom patties!

  
  jalapeÃ±os = CUSTOMPATTY.call 'spicy jalapeÃ±os patties'
bacon = CUSTOMPATTY.call 'greasy, yummy bacon patties'

grill = Grill.new jalapeÃ±os
grill.grilling # => "Grilling the spicy jalapeÃ±os patties!"

grill.food = bacon
grill.grilling # => "Grilling the greasy, yummy bacon patties!"

grill.food = HotDog.new
grill.grilling # => "Grilling the hot dogs!"

Mmm-mmmm... That is a tasty burger.

The Strategy pattern is a delagation-based design pattern, and shares some similarities with the Template Method pattern. However, instead of depending so heavily on inheiritance between a superclass and subclasses to use our target algorithm, we take our algorithm and consider it as a separate object. As long as we remember the relationship between the strategies and the context, we earn real advantages over the Template Method, as seen in our custom patty example.

I hope you had fun at our day party, and we'll next explore the Observer pattern.

Design Patterns: The Template Method Pattern

2013-07-10 00:00:00

Introduction

As the field of software development grows, we developers are continuously trying to catch up with the latest technologies. Fortunately, the craft of writing maintainable code is language agnostic, and in this series of blogposts, we'll focus on a powerful set of timeless tools: Design Patterns.

I highly recommend Russ Olsen's book Design Patterns in Ruby. Our series will draw inspiration from it and is brief in comparison. So if you enjoy these posts (and I hope you do!), the book will be a great investment.

We'll explore various design patterns and learn when to apply them. Our topic for today will be the Template Method pattern, the simplest design pattern.

Our First Day in Construction

The Right Tools

Quite simply, design patterns are just tools that help us construct software. However, just like tools, we need to use the correct and proper one for the task. We could use a hammer on screws, but we'd damage the wood planks and using a power drill will be much more efficient. Before using any one of the numerous design patterns, it is crucial to understand the problem we wish to solve.

It is incorrect to use a particular design pattern on the wrong type of problem. In other words, it is in poor practice to use a particular design pattern on a problem that does not require the aforementioned design pattern.

Let's Build Some Walls

Today, we've been asked by our foreman to build a couple of walls. All the walls will share the same dimensions and will be made from the same material (for this construction project, our foreman has given us an "easy" set of requirements).

  
  # Blueprints for Wall
require 'minitest/autorun'

describe Wall do
  let(:wall) { Wall.new }

  it 'should state its dimensions' do
    wall.dimensions.must_equal 'I am 30ft. long and 20ft. wide!'
  end

  it 'should be made from brick' do
    wall.made_from.must_equal 'I am made from brick!'
  end
end

What a nice boss, he's handed us the blueprints! Now it's just up to us to build out the Wall.

  
  class Wall
  def dimensions
    'I am 30ft. long and 20ft. wide!'
  end

  def made_from
    'I am made from brick!'
  end
end

Nice! Our tests pass, everybody is happy, and we're off to lunch!

A Hammer or a Nailgun?

Coming back to the site, our foreman has informed us that we need more walls. "That's a piece of cake," we reply, recalling how easy it was to build out the Wall.

"Not so fast," our foreman retorts. We're given new blueprints with different wall requirements.

  
  # Blueprints for a BrickWall
describe BrickWall do
  let(:brick_wall) { BrickWall.new }

  it 'should state its dimensions' do
    brick_wall.dimensions.must_equal 'I am 30ft. long and 20ft. wide!'
  end

  it 'should be made from brick' do
    brick_wall.made_from.must_equal 'I am made from brick!'
  end
end

# Blueprints for a ConcreteWall
describe ConcreteWall do
  let(:concrete_wall) { ConcreteWall.new }

  it 'should state its dimensions' do
    concrete_wall.dimensions.must_equal 'I am 30ft. long and 20ft. wide!'
  end

  it 'should be made from concrete' do
    concrete_wall.made_from.must_equal 'I am made from concrete!'
  end
end

# Blueprints for a WoodWall
describe WoodWall do
  let(:wood_wall) { WoodWall.new }

  it 'should state its dimensions' do
    wood_wall.dimensions.must_equal 'I am 10ft. long and 20ft. wide!'
  end

  it 'should be made from wood' do
    wood_wall.made_from.must_equal 'I am made from wood!'
  end
end

Hmm... A couple of ideas run through our heads. We could follow the initial Wall class and define each method, hardcoding each string output, for the BrickWall, ConcreteWall, and WoodWall classes. That seems like an okay idea, but we'd have to hard code each instance method. What if our house requires a dozen different types of walls?

Open That Toolbox!

Sipping on our after-lunch coffee, we realize that we've got a tool right for the job, the Template Method pattern.

In the Template Method pattern, the creation of a skeletal class will serve as the basis for various subclasses or concrete classes. Within the skeletal class there are abstract methods, which in turn, will be overridden by the methods of subclasses. Essentially, we'll define a Wall class (our skeletal class) and its subclasses, BrickWall, ConcreteWall, and WoodWall.

Going over the blueprints, we notice that the three different classes of walls each contain the methods #dimensions and #made_from, which result in slighty different strings. With this knowledge, let's create our Wall class and its subclasses.

  
  class Wall
  def dimensions
    "I am #{length}ft. long and #{width}ft. wide!"
  end

  def made_from
    "I am made from #{material}!"
  end

  private

  def length
    30
  end
end

class BrickWall < Wall
  private

  def width
    20
  end

  def material
    'brick'
  end
end

class ConcreteWall < Wall
  private

  def width
    20
  end

  def material
    'concrete'
  end
end

class WoodWall < Wall
  private

  def length
    10
  end

  def width
    20
  end

  def material
    'wood'
  end
end

Discussion

Hook Methods

Within the Wall class we have defined a private method called #length because we see that BrickWall and ConcreteWall share the same length. As for the WoodWall class, we simply overwrite the #length and give it a value of 10. These are examples of Hook Methods.

Hook Methods serve two purposes:

Override the skeletal implementation and define something new
Or, accept the default implementation

Please note that the default implemetation, within the skeletal class, does not necessarily need to define a method. For example, we could have had:

  
  class Wall

  ...

  private

  def length
    raise NotImplementedError, 'Sorry, you have to override length'
  end
end

class BrickWall < Wall
  private

  ...

  def length
    30
  end
end

In the example above, the #length method within the Wall class served as a placeholder for the #length for the BrickWall, it's concrete class. Essentially, hook methods inform all concrete classes that the method may require an override. If the base implementation is undefined the subclasses must define the hook methods.

Those Are Some Nice Walls

Our foreman is delighted with the results and we're going to call it a day. As we can see, using the Template Method pattern is not difficult at all. We first defined a base class, within which we defined necessary hook methods to be overridden by our subclasses. Of course, this particular design pattern does not solve every conceivable problem, but helps keep our code clean by the use of inheritance.

Next we'll be discussing the Strategy method pattern. Stay tuned!

First Month at DockYard

2013-07-09 00:00:00

I came to the programming party a little late in my college career, only having a year and a half of classroom experience under my belt. Due to my limited CS background, I was rather anxious to start work at a web development startup, fearing my qualifications were not up to par. However, my feelings of inadequacy quickly subsided after starting at DockYard! I was welcomed by a comfortable learning environment and an atmosphere of positivity and productivity. My coworkers are very approachable and always willing to answer my questions. Because of DockYard's intimate size I am able to see all sides of the business, and get to know everyone in the office.

It has now been a month since I began working and already I feel I am light-years ahead of where I started. My nerves have been replaced by an eagerness to continue learning and grow as a developer. The amount of information that has been thrown my way is rather overwhelming. I have already pored through 6 books, including: Agile Web Development with Rails by Sam Ruby and, Secrets of the JavaScript Ninja by John Resig, in addition to other readings on CoffeeScript, version control (git), and user stories. Not to mention my introduction to vim and all the commands that accompany it. While I cannot claim all of the information has stuck, the exposure will surely breed understanding. I have learned that it isn't about having all the answers, but the efficiency of finding them that is important.

In addition to all the reading, I have worked on a small side project: a simple blog site (my introduction to test-driven development) that I rebuilt 3 times, each time adding more features. The saying, "repetition is the mother of all learning", has certainly resonated with me after this exercise. Also pair programming with others in the office has also been extremely helpful, giving me an idea of the day-to-day. Overall, I feel lucky to be at DockYard in the midst of the growing field of web development. Already I can say my experience has been invaluable and I thoroughly look forward to the rest of the summer.

DockYard Acquires Dobot

2013-07-08 00:00:00

Today I'm very happy to announce that we have acquired local design firm Dobot, its two partners Steven & Logan have joined us full-time. This is a huge move for DockYard, and a simple one for Dobot (they have been working out of our office for the past few months so they don't actually need to move anywhere).

Please see the announcement for Steven Trevathan and the announcement for Logan Faerber.

Steven Trevathan is a DockYarder

2013-07-08 00:00:00

I'm very happy to announce today that DockYard has joined forces with Boston design firm Dobot! Leader designer Steven Trevathan has come on as a partner and Creative Director (until we come up with a title he prefers) of DockYard.

This is a huge step forward for us. While we have had in-house designers we have been actually leaning on Steven from time to time for our concept design needs. Now with Steven coming on as part of our team he will focus on building out the design side of DockYard and putting together a formal concept design process for us.

Follow Steven on Twitter

Logan Faerber is a DockYarder

2013-07-08 00:00:00

Along with his other fellow Dobot-er we welcome Logan Faerber to the DockYard team today!

Logan is a kick ass illustrator who has done work for New York Life, Dynamo Labs, CareShare, CustomMade, Bioware, and Archaia.

Logan has been working out of our office for the last few months and we are excited to have his unique talents at DockYard.

Follow Logan on Twitter

Sean Hussey is a DockYarder

2013-07-01 00:00:00

Today is the first day for Sean Hussey at DockYard. He has been contracting with us for the past few months and I was finally able to lock him down recently. Sean and I have known one another for years as he hired me for my first Ruby job at RakutenUSA. He brings years of Sr. level Ruby experience to our team.

Introducing destroyed_at

2013-06-28 00:00:00

See the project on GitHub

We've found that more and more clients are requesting "undestroy" functionality in their apps. We recently extracted this common pattern into a gem we're calling DestroyedAt, an ActiveRecord mixin that makes un-destroying records simple.

By setting the datetime of the #destroyed_at field of your record, you can mark records as destroyed, without actually deleting them. By default, the model in which you include DestroyedAt is scoped to only include records that have not been destroyed. So something like User.all will only return Users with #destroyed_at values of nil; and User.unscoped.all will return all User records.

When you want to bring a record back, simply call #undestroy on the instance and its #destroyed_at will be set to nil.

We've baked a bunch of other functionality in as well, including undestroy callbacks. For the full rundown, head over to DestroyedAt's GitHub page .

Marin Abernethy is a DockYarder

2013-06-19 00:00:00

Marin comes to us as from Trinity College for the summer. We've been overwhelming her with Ruby, Linux, SQL, JavaScript, and VIM. She's excelled and we're excited to see what she can accomplish over the remainder of the summer.

Michael Dupuis is a DockYarder

2013-06-19 00:00:00

Recently we added another great mind to the DockYard team: Michael Dupuis. Mike joins our Boston office and has already been busy building out client apps in Ruby on Rails and Ember.js for us! He also comes with some design chops. Welcome Mike!

Context Validations

2013-05-09 00:00:00

I just released a new gem called ContextValidations

ContextValidations allows you to set validations on the instance of ActiveRecord models. Any class-level validations you have already set in your models are ignored. You may be asking yourself "Whaaaaaat?" so let's look into why.

Conditional Validations Are A Smell

When applications grow in complexity the validation models required to support them usually grow too. Eventually you will have to "work around" the validations with conditionals that rely upon state flags. In some cases you end up writing empty model objects for use with your forms to avoid the mess that conditional validations introduce.

The problem here is that the model is defining a single set of validations but the model needs to absorb different sets of data under different circumstances. Imagine you have a user account that where depending upon how the users get to your app will depend upon what data they need to provide. You might also be importing data from an external incomplete data set. Do you set these records aside into another table until the records are claimed and the user can complete registration? Or do you allow the records to save and have the model enter a state of unclaimed to avoid authentication until claimed? You could just avoid the validations all together but you definitely don't want to allow records that don't have the most basic of identifying information such as email or username to be saved.

You can imagine with this scenario the current solution with Rails is either a very complex and messy validation model or breaking things out into other models and having a strategy to reconciling that at a later point in time.

Context Matters

I have come to believe that defining a monolithic validation set in your model is the wrong way to go. Context matters. If I am an admin I should be able to write data to a record that might not be acceptable to a regular user. Even the simple case of not requiring a password unless the record is new.

Controllers Are the Context

I believe the rule of "Fat Model, Skinny Controller" has conditioned Rails developers to never ever put anything more than a few lines of code into your controllers. For the most part this is a good trend. But as we have seen with Strong Parameters there are circumstances where adding a few more lines to our controllers isn't going to end the world. I submit the case is also true for validations. The controller is the context in which the user is interacting with the data. Going back to the admin example, you most likely have a UsersController and an Admin::UsersController defined. Two controllers, same data. Different contexts. Not only should you allow mass assignment to the models differently for each context but what is considered "valid data" should also be different.

Context Validations

To handle this need I have just released ContextValidations. The goals of this gem are simple:

Maintain simplicity
Enable instance level validations
Don't deviate from exisitng Rails validations
Backwards compatibility with 3rd party libraries

Before I dive into each one let's see how a set of validations might be applied in a controller

  
  class UsersController < ApplicationController
  include ContextValidations::Controller

  def create
    @user = User.new(user_params)
    @user.validations = validations(:create)
    if @user.save
      # happy path
    else
      # sad path
    end
  end

  def base_validations
    validates :first_name, :last_name :email, :presence => true
    validates :email, :uniqueness => true, :format => EmailFormat
    validates :password, :confirmation => true
  end

  def create_validations
    validates :password, :presence => true
  end
end

Maintain Simplicity

At this point some of you are probably thinking Form Objects. Perhaps in the end, Form Objects will be the real answer for what I strive for. But right now I don't see a justification for the increase in complexity. ContextValidations has attempted to keep the complexity as low as possible while still allowing for flexibility. The ContextValidations::Controller module can be mixed into any object, not just controllers. Let's say you had a Service Object

  
  class UserService
  include ContextValidations::Controller

  def initialize(params)
    @params = params
  end

  def create
    @user = User.new(create_params)
    @user = validations(:create)
  end
end

At this point the code looks identitly to the controller example from above. The validations are accessible anywhere, from any object.

Instance level validations

The real key here is that the instance of the model is able to declare what its validations are rather than the class. To that end you must mixin the ContextValidations::Model module into any model you want to use ContextValidations

  
  class User < ActiveRecord::Base
  include ContextValidations::Model
end

This mixin will do several things to you ActiveRecord model

A #validations setter and getter is added. The default for #validations is an empty array. When any arrays are assigned they are wrapped in an array and falttened out.
The :validate callbacks are completed removed. This allows the model to accept validations set on the class by 3rd party libraries but these validations will never run.
The #run_validations! protected method is overwritten to run through the instance level validations instead of running the :validate callback.

Don't deviate from exisitng Rails validations

The only difference from writing your validations now is they are written on the instance. The #validates method functions exactly the same way. You can still pass conditional validations if you'd like but I wouldn't recommend it.

Backwards compatibility with 3rd party libraries

As mentioned above we don't want your Rails app to crash if 3rd party libraries are declaring regular Rails validations in your models. They are just ignored.

Moving forward

There are a few directions things could move in. I still haven't come up with a simple way to test ContextValidations. There will also be validations that are always used regardless of the context. I don't think it makes sense to constantly rewrite these validations. One possibility would be to consider the class validations the base_validations that are always run then you can declare context validations on the instance. This might cause issues with 3rd party libraries that are using conditional validations. But, we could easily get around that by ignoring any class level validations that have conditionals on them.

I am eager to get feedback on this. I am sure this might cause some friction as it moves outside of the comfort zone for many Rails devs but now I am happy with the direction.

Tilde's Ember Training

2013-05-09 00:00:00

A couple weeks ago, Yehuda Katz and Tom Dale of Tilde ran their 3-day Introduction to Ember.js Training at Bocoup here in Boston. I, along with Amanda, Doug and Chris, attended the training.

Format

Throughout the training, attendees were building a simplified Rdio/Spotify clone using Ember. It was broken up into a series of exercises, which built upon each other. The exercises were test driven, each having set of QUnit tests that defined the exercise. Before each exercise, Tom and Yehuda would explain and demo the concepts via slides and JSBin.

Day 1

Day 1 was spent outlining the core concepts of Handlebars and Ember. We started with Handlebars, which is what Ember uses as its templating language. After covering the basics of Handlebars, we learned about how Ember handles routing and outlets. After we finished routing, we moved onto creating Handlebars helper functions.

Day 2

On day 2, we started off with Ember controllers and how they serve as proxy objects for the model of your current resource. After controllers, we covered computed properties. Views followed computed properties, then we wrapped up the day with creating custom controls with Ember and Handlebars.

Day 3

Once we had built the majority of the app, we had a couple more exercises that built upon all the exercise we had completed. Tom and Yehuda also went over how we would use Ajax requests to pull in data from a remote source with Promises. After wrapping up the remainder of the exercises, we covered how the Ember Run Loop works, and discussed approaches to testing Ember applications.

Feedback

Yehuda and Tom provided a great balance of not-to-dense information, useful demos and exercises. They did a great job of, what Tom stated as, "Providing a sufficient level of confusion" in the exercises. Before each exercise, they would provide all the information needed for the exercise, but would not give you a list of steps to complete the task. You may struggle a bit, but they answer any questions you would have during the exercise. This would help the attendees actually learn the concepts, rather than just copy/paste a set of code and modify it here and there and have it work. I, personally, felt that this worked really well.

I have worked on a couple side project with Ember before taking this training, and had a very shallow understanding of some of the concepts. Coming out of this training, I feel I have a great place to start building Ember apps. I really fleshed out my understanding of Ember and am really excited about the technology. I am planning on using it for any upcoming side projects, to really explore it further.

We are hiring for a fulltime Ember.js developer

2013-04-04 00:00:00

We are looking for an Ember.js Developer. Our ideal candidate:

Work on cutting-edge Ember.js applications
Passionate about new HTML/JavaScript technologies
Has experience building complex client side applications
Some backend experience would be nice
Some database experience would be nice
Enjoys contributing to open source, writing blog posts, giving talks
Willing to live in Boston (we can relocate for the right candidate)

Our current tech stack:

Ruby on Rails
Ember.js
PostgreSQL
CoffeeScript
Most of our apps deploy to Heroku, if not then to Linode

DockYard is a Boston-based consultancy that always wants to work with the best people and the best technology. We are committed to Ember.js as a client side framework. We help organize the Boston Ember.js meetup and I recently spoke at Ember Camp in San Francisco. We are already building tools around Ember.js and hope to continue to improve and build new ones in the upcoming years.

Please email contact@dockyard.com with all relevant information on why you would be an ideal candidate for a fulltime Ember.js developer.

Running PostgreSQL 9.2 on Travis-CI

2013-03-29 00:00:00

I spent most of yesterday trying to get PostgreSQL 9.2 running Travis-CI. After almost 30 attempts, I successfully tested postgres_ext against PostgreSQL 9.2.

Here is the final before_script needed to install PostgreSQL 9.2.

  
  before_script:
  - sudo /etc/init.d/postgresql stop
  - sudo cp /etc/postgresql/9.1/main/pg_hba.conf ./
  - sudo apt-get remove postgresql postgresql-9.1 -qq --purge
  - source /etc/lsb-release
  - echo "deb http://apt.postgresql.org/pub/repos/apt/ $DISTRIB_CODENAME-pgdg main" > pgdg.list
  - sudo mv pgdg.list /etc/apt/sources.list.d/
  - wget --quiet -O - http://apt.postgresql.org/pub/repos/apt/ACCC4CF8.asc | sudo apt-key add -
  - sudo apt-get update
  - sudo apt-get -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confnew" install postgresql-9.2 postgresql-contrib-9.2 -qq
  - sudo /etc/init.d/postgresql stop
  - sudo cp ./pg_hba.conf /etc/postgresql/9.2/main
  - sudo /etc/init.d/postgresql start

Step by step explanation

Out with the old

Currently, Travis-CI has PostgreSQL 9.1 installed with a passwordless postgres superuser role. We first stop the current user by calling sudo /etc/init.d/postgresql stop. We also want to copy the current pg_hba.conf, since we can reuse it with PostgreSQL 9.2 to disable the need for a password for the postgres role. We then remove the currently installed version via sudo apt-get remove postgresql postgresql-9.1 -qq --purge.

Add the apt.postgresql.org repositories

Postgresql.org maintains Debian and Ubuntu packages of the current PostgreSQL 8.3, 8.4, 9.0, 9.1 and 9.2 builds at apt.postgresql.org (more information). Since Travis-CI workers run Ubuntu, we can leverage these packages. We first load the Ubuntu distribution environment variables via source /etc/lsb-release. Using the $DISTRIB_CODENAME variable, we can set up the pgdg.list file that we will add to the apt-get sources list directory. We do so with the following command:

  
  echo "deb http://apt.postgresql.org/pub/repos/apt/ $DISTRIB_CODENAME-pgdg main" > pgdg.list
sudo mv pgdg.list /etc/apt/sources.list.d/

The last thing we have to do before we can start installing the 9.2 is to import postgresql.org's apt key via

  
  wget --quiet -O - http://apt.postgresql.org/pub/repos/apt/ACCC4CF8.asc | sudo apt-key add -

In with the new

After we update our package listing via sudo apt-get update, we can install postgresql-9.2 and postgresql-contrib-9.2 (needed for the PostgreSQL extensions) via:

  
  sudo apt-get -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confnew" install postgresql-9.2 postgresql-contrib-9.2 -qq

We need the Dpkg::Options to automatically resolve any configuration file conflicts left behind by 9.1 (even though we purge the files, for some reason the /etc/init.d/postgresql file gets left behind). Without the Dpkg::Options, apt-get will raise a user prompt that will hang the Travis-CI build.

At this point, we have a vanilla install of PostgreSQL 9.2, which will prompt for a password for the postgres role. We then need to stop the server, replace the 9.2 pg_hba.conf with the custom Travis-CI one we copied earlier, then restart the server:

  
  sudo /etc/init.d/postgresql stop
sudo cp ./pg_hba.conf /etc/postgresql/9.2/main
sudo /etc/init.d/postgresql start

At this point, you can use any other before_script commands you were previously using to create your database.

Conclusion

After a decent amount of trial and error, I arrived at the above before_script to install PostgreSQL 9.2. I am currently adding support for ranges to postgresext, which was added in 9.2. You should be able use this `beforescript` to add 9.2 to your Travis-CI builds.

Adding route specific body class tags in Ember

2013-03-27 00:00:00

Our designer likes to use body class tags depending upon the context of the app he is designing. We're currently building an Ember app and this is how I got it working:

  
  Ember.Route.reopen({
  activate: function() {
    var cssClass = this.toCssClass();
    // you probably don't need the application class
    // to be added to the body
    if (cssClass != 'application') {
      Ember.$('body').addClass(cssClass);
    }
  },
  deactivate: function() {
    Ember.$('body').removeClass(this.toCssClass());
  },
  toCssClass: function() {
    return this.routeName.replace(/\./g, '-').dasherize();
  }
});

Concurrent Indexes in PostgreSQL for Rails 4 and Postgres_ext

2013-03-26 00:00:00

PostgreSQL allows you to create your indexes concurrently so that your table isn't locked as the index builds. This allows you to avoid taking a performance hit when adding a new index to a large table. Yesterday, I submitted a pull request to Rails that as merged in this morning that allows you to add concurrent indexes through the add_index method in your migrations. To create an index concurrently, you add the algorithm: :concurrently option to the add_index call

  
  add_index :table, :column, algorithm: :concurrently

A side effect of this commit is that it also enables the algorithm option for MySQL too, so MySQL users can create indexes using DEFAULT, INPLACE or COPY algorithm when creating indexes.

Postgres_ext gains concurrent index support as well

This morning I added support for concurrent indexes to postgres_ext as well, using the same syntax as the Rails 4 example above. The 0.3.0 version of postgres_ext was released, which contains this, and a slew of other improvements as well. One thing to note, the index_type option for add_index has been renamed to using to match Rails 4.

If you have any features you want to see in postgres_ext or have any issues, open an issue!

Igata

2013-03-25 00:00:00

View the code

Try it out!

A year and a half ago I started thinking about a product I wanted to build. I am a big fan of Heroku and I felt something missing from their eco-system was an App Store. Similar to the WordPress Theme Store. This Heroku App Store would allow developers to create fully realized applications and sell them to non developers. The person on the purchasing side wouldn't even need to know about Heroku. We built this product over the past year, got the "thumbs up" from Heroku, finally got bored with the idea of launching it, and are now open sourcing it for all to see. I will go into the challenges we faced as a consulting firm building a product and why we decided to give this away rather than "go for it".

Concept to reality

The concept was simple: App Store for Heroku. I built the original app code in May of 2012. I would say about 50% of the app was completed in a week. However, what I quickly learned is that balancing consulting a product development is not easy. Quickly development on Igata turned into a see-saw. A day of work here and there in between contracts. It became very difficult to stay focused and keep interested in the project. But I believed it was one that could do well if positioned properly. The idea of proving an additional revenue stream to Heroku also felt like a good challenge.

I let the app sit for a few months while we were working on a very large contract over the summer. Then the Rails Rumble came and I was a judge, I saw an app called Deploy Button and I freaked out. This was essentially what we had already built but without the purchasing aspect. I emailed my team and told them we weren't taking any more contracts until we finished Igata. This proved to not work very well in reality. As a Rails consultancy we are not cheap but you don't realize just how expensive you are until there is no money coming in. So we went back on contract and shelved Igata, again. I kept coming back to it every so often. Finally I decided to open source it.

Validation

It wasn't until I made the decision to open source Igata that I started to get some validation of the concept. I was very secretive about the app as I figured if Heroku found out about it, and liked the idea, they would just toss a few devs at it for a week or two and come out with an "official" app store. But now that I was going to OSS is fuck it, I'll tell everybody! I told a few friends that work at Heroku and in the end it was foolish of me to worry about that sort of thing. Several people encouraged me not to open source and just finish and release. So I went to Waza (Heroku's Conference) and met with a few people from Heroku's Partner program, once I showed them the app they loved it.

I came home a few weeks ago, pumped to finish the app.

Back to Open Sourcing

I wouldn't say doubt began to creep back in, just more that I really didn't like the idea of what would come of Heroku if it it was a success. Maintaining an app store and building it out really doesn't interest me at all. I had a choice: shit or get off the pot. I've now decided to get off the pot.

I'm happy to go into more details on what our business model would have been in another post if people are interested. The app itself is about 95% complete. There were some changes to the payment system we would make. But overall I'm happy with what we built considering the very disrupted development schedule on it. I hope this app can serve someone well.

Fixing Capybara 2.0 and Labels

2013-03-21 00:00:00

I love Capybara, it makes integration testing a breeze. However, one of the decisions made for Capybara 2.0 confuses an annoys me. In Capybara 1.x you could do the following:

  
  fill_in 'Password', :with => '123456'
fill_in 'Password confirmation', :with => '123456'

And everything worked. In Capybara 2.0 this does not work. Capybara will notice two labels that contain 'Password' and complain about an ambiguous locator. The suggested work around is to attach meta data to the input element and use that for the selector. There are two reasons why I don't like this. First, I am doing Ember development now and I have no control of the ID, it is generated by the framework. Second, I believe that the integration test should be recreating the steps (as much as possible) as if a user were actually using the app. Something like:

  
  fill_in '[data-name="password"]', :with => '123456'
fill_in '[data-name="password_confirmation"]', :with => '123456'

Doesn't sit right with me. Users are looking at the text, not the selectors. I get that apps have the ability to show different languages but that doesn't conern me, I don't need to test if the Rails i18n works or not. I just care about asserting the happy and sad paths in my app.

So, to fix this problem simply add the following code into your test_helper.rb

  
  module XPath::HTML
  protected

  def locate_field(xpath, locator)
    locate_field = xpath[attr(:id).equals(locator) | attr(:name).equals(locator) | attr(:placeholder).equals(locator) | attr(:id).equals(anywhere(:label)[string.n.equals(locator)].attr(:for))]
    locate_field += descendant(:label)[string.n.contains(locator)].descendant(xpath)
    locate_field[~attr(:disabled)]
  end
end

And you should be all set!

Mike Sager Joins DockYard

2013-03-19 00:00:00

I'm very happy to announce that Mike Sager has joined DockYard! Sager and I met while working on The Campaign That Shall Not Be Named (it was a very "special" one in MA) we kept in touch on and off after that until we recently worked together on a project for the AFL-CIO.

Sager brings an intimate knowledge of the progressive political tech arena. DockYard is already making a great name for itself with political tech and NPOs and we're looking forward to the klout that Sager will bring to the table.

While not yet "official" we will soon be opening an office in Washington, DC. Sager and Chris Gill will be running this office and we are looking to hire Rails developers that have experience building apps in politics. Join us!

Introducing Ember-EasyForm

2013-02-21 00:00:00

View the project on GitHub

One of the more tedious tasks in Ember is writing forms. It is not uncommon to have to write something like so:

  
  <form>
  <div class="input string">
    <label {{bindAttr for="firstNameField.field_id"}}>First name</label>
    {{view Ember.TextField valueBinding='firstName' name='first_name' viewName='firstNameField'}}
  </div>
  <div class="input string">
    <label {{bindAttr for="lastNameField.field_id"}}>Last name</label>
    {{view Ember.TextField valueBinding='firstName' name='last_name' viewName='lastNameField'}}
  </div>
  <div class="input string">
    <label {{bindAttr for="ageField.field_id"}}>Age</label>
    {{view Ember.TextField valueBinding='age' name='age' viewName='ageField'}}
  </div>
  <input type="submit" value="Submit">
</form>

And this is just a very simple form, but what if we could write this:

  
  {{#formFor controller}}
  {{input firstName}}
  {{input lastName}}
  {{input age}}
  {{submit}}
{{/formFor}}

That is much more concise! We pass the controller as the context to the formFor Handlebars helper. Then we can simply call input for each property we want.

By default EasyForm will use text fields for the rendered input. However, in certain cases it will attempt to properly set the type. If the property contains email the type will be set to email or of the property contains password the type will be set to password. You can override this and set the type yourself:

  
  {{input code type="hidden"}}

Currently the only other input type supported is textarea, you can create one with:

  
  {{input bio as="text"}}

I plan on adding support for the other input types such as select in the next few weeks.

Validations

This implementation has basic support for property validations. Currently it works with ember-data-validations but that project might get rolled into a larger Ember Object Validation effort and at that time I will change ember-easyForm to support whatever that is.

Validations will fire on onFocusOut for each input and will render into a <span class="error"> element associated with the given input.

If your model doesn't have validations this behavior will be ignored.

Form Submit

The submit helper will render a submit input but you can just write one yourself if you wish. The onSubmit action for the wrapping form element will do the following:

Attempt to validate for object. If validations are not supported it will go to step 3.
If validations fail form submit is interrupted and errors are rendered. If not go to step 3.
The view for the form element will attempt to call a submit action on the controller. This is an action that you need to supply yourself:

  
  App.NewUserController = Ember.ObjectController.extend({
  submit: function() {
    // handle form submit here
  }
});

More to come!

This is very close to what I recently (and briefly) showed at EmberCamp last week. I hope to continue to build this project into a form builder that evrerybody will be happy to use. Please feel free to propose new idea in the issues for this project on GitHub

Building an Ember app with RailsAPI - Part 3

2013-01-10 00:00:00

This article was last updated on May 28, 2013 and reflects the state of Ember (1.0.0-rc4) and the latest build of Ember Data (0.13) as of that date.

Fork the project on Github!

Use the app live on Heroku

In Part 1 I showed you how to setup a Rails-API app for Ember.

In Part 2 I showed you the basics of building an Ember app, reading from a backend API and displaying that information.

Today we're going to do some coding on the Rails side and the Ember side to add Creating, Updating, and Destroying records.

Part 3 - The Big Finish

In Part 1 we setup the backend using Rails API. In Part 2 we built out the basics of an Ember app, reading from a remote data source and displaying that data. Now we're going to add the ability to Create, Update, and Destroy that data. This part will be a mix of Ember and Rails code.

Note: If you have been following along that Part 2 was recently updated to reflect new changes to the Ember Router, you will need to go back and update your code. Absolute make sure to update your ember.js and ember-data.js dependencies as they have been updated on the github repo

Create

Let's start by adding a Create button to our index page:

  
  {{#linkTo 'users.new' class='btn btn-primary'}}Create{{/linkTo}}

We need to add the proper route so the index page doesn't blow up. While we're in here we'll add the edit route as well.

  
  App.Router.map ->
  @resource 'users', ->
    @route 'new'
    @route 'edit',
      path: '/:user_id/edit'
    @route 'show',
      path: '/:user_id'

And now we can add the UsersNewRoute

  
  App.UsersNewRoute = App.UsersRoute.extend
  model: ->
    App.User.createRecord()
  setupController: (controller, model) ->
    controller.set('content', model)

Don't be fooled by the createRecord() call. This will not write anything to the backend. This call is simply used to create a new model. Now let's create the template app/assets/javascripts/templates/users/new.hbs

  
  <h1>Create {{fullName}}</h1>
<form>
  <fieldset>
    <div>
      <label {{bindAttr for="firstNameField.elementId"}}>First Name</label>
      {{view Ember.TextField valueBinding='firstName' name='first_name' viewName='firstNameField'}}
    </div>
    <div>
      <label {{bindAttr for='lastNameField.elementId'}}>Last Name</label>
      {{view Ember.TextField valueBinding='lastName' name='last_name' viewName='lastNameField'}}
    </div>
    <div>
      <label {{bindAttr for='quoteField.elementId'}}>Quote</label>
      {{view Ember.TextArea valueBinding='quote' name='quote' viewName='quoteField'}}
    </div>
    <a href='#' {{action save}} class='btn btn-success'>Create</a>
  </fieldset>
</form>
<div class='page-header'></div>

<a href='#' {{action cancel}} class='btn btn-inverse'>Cancel</a>

Next we'll add app/assets/javascripts/controllers/users/newController.coffeescript

  
  App.UsersNewController = Ember.ObjectController.extend
  headerTitle: 'Create'
  buttonTitle: 'Create'

  save: ->
    @content.save().then =>
      @transitionToRoute('users.show', @content)

  cancel: ->
    @content.deleteRecord()
    @transitionToRoute('users.index')

The first two functions save and cancel are actions that are mapped in the template. Let's break down each:

save will make a call to this.store.commit(). You will notice we are not modifying a model, assigning params, etc... as you would in a Rails app. Keep in mind that when you modify data that is bound in the form you are actually modifying the data in the model itself. The datastore in Ember needs to be directed when these modifications should be made "permanent", and because we are using the RESTAdapter Ember will attempt to write these changes to the backend.
cancel If the user decides to not create a new user we must delete the record we created then transition to the index page.

Learn more about the Ember Model Lifecycle

Finally we're going to hook up the back end in app/controllers/users_controller.rb

  
  def create
  user = User.new(params[:user])

  if user.save
    render json: user
  else
    render json: user, status: 422
  end
end

It has been mentioned that 422 is the proper status code for validation failures. Personally I would prefer to use respond_with but it isn't part of the default Rails-API stack, hopefully this will change.

Now let's run our app and see how it goes.

Whoops, we have undefined undefined for the fullName. Let's set default values of an empty string in our user model:

  
  App.User = DS.Model.extend
  firstName: DS.attr('string', defaultValue: '' )
  lastName: DS.attr('string', defaultValue: '' )
  quote: DS.attr('string')
  fullName: (->
    "#{@get('firstName')} #{@get('lastName')}"
  ).property('firstName', 'lastName')

Now when we add data and create it will write to the back end, take us to the show page. When can then click Back and we can see the record has been automatically added to the collection on the index page.

Adding Edit should be straight forward now that we have done create. Start will adding the route:

  
  App.UsersEditRoute = Ember.Route.extend
  model: (params) ->
    App.User.find(params.user_id)
  setupController: (controller, model) ->
    controller.set('content', model)
    @controllerFor('application').set('currentRoute', 'users')

You'll notice that this route is identical to App.UsersShowRoute we wrote in Part 2, let's DRY this up

  
  App.UserRoute = Ember.Route.extend
  model: (params) ->
    App.User.find(params.user_id)
  setupController: (controller, model) ->
    controller.set('content', model)
    @controllerFor('application').set('currentRoute', 'users')

App.UsersShowRoute = App.UserRoute.extend()
App.UsersEditRoute = App.UserRoute.extend()

Next we'll add the edit link to app/assets/javascripts/templates/users/show.hbs

  
  {{#linkTo 'users.edit' content class='btn btn-primary'}}Edit{{/linkTo}}

Now the edit template itself in app/assets/javascripts/templates/users/edit.hbs

  
  <h1>Edit {{fullName}}</h1>
<form>
  <fieldset>
    <div>
      <label {{bindAttr for="firstNameField.elementId"}}>First Name</label>
      {{view Ember.TextField valueBinding='firstName' name='first_name' viewName='firstNameField'}}
    </div>
    <div>
      <label {{bindAttr for='lastNameField.elementId'}}>Last Name</label>
      {{view Ember.TextField valueBinding='lastName' name='last_name' viewName='lastNameField'}}
    </div>
    <div>
      <label {{bindAttr for='quoteField.elementId'}}>Quote</label>
      {{view Ember.TextArea valueBinding='quote' name='quote' viewName='quoteField'}}
    </div>
    <a href='#' {{action save}} class='btn btn-success'>Update</a>
  </fieldset>
</form>
<div class='page-header'></div>

<a href='#' {{action cancel target='controller'}} class='btn btn-inverse'>Cancel</a>

And now the controller app/assets/javascripts/controllers/users/editController.coffee

  
  App.UsersEditController = Ember.ObjectController.extend
  destroy: ->
    @content.deleteRecord()
    @store.commit()
    @transitionTo('users.index')

  save: ->
    @content.save().then =>
      @transitionToRoute('users.show', @content)

  cancel: ->
    if @content.isDirty
      @content.rollback()
    @transitionTo('users.show', @content)

  buttonTitle: 'Edit'
  headerTitle: 'Editing'

This controller looks similar to App.UsersNewController but let's explore the differences

save here because the model already has an id we can commit to the datastore and transition.
cancel instead of deleting the record we want to rollback to its previous state. And we can only rollback if the record has changed.

I'm sure you know what is next. The new template is nearly identical to the edit template. Let's create app/assets/javascripts/templates/users/form.hbs

  
  <h1>{{headerTitle}} {{fullName}}</h1>
<form>
  <fieldset>
    <div>
      <label {{bindAttr for="firstNameField.elementId"}}>First Name</label>
      {{view Ember.TextField valueBinding='firstName' name='first_name' viewName='firstNameField'}}
    </div>
    <div>
      <label {{bindAttr for='lastNameField.elementId'}}>Last Name</label>
      {{view Ember.TextField valueBinding='lastName' name='last_name' viewName='lastNameField'}}
    </div>
    <div>
      <label {{bindAttr for='quoteField.elementId'}}>Quote</label>
      {{view Ember.TextArea valueBinding='quote' name='quote' viewName='quoteField'}}
    </div>
    <a href='#' {{action save}} class='btn btn-success'>{{buttonTitle}}</a>
  </fieldset>
</form>
<div class='page-header'></div>

<a href='#' {{action cancel target='controller'}} class='btn btn-inverse'>Cancel</a>

And in both the new and edit template remove the markup and replace with

  
  {{ template 'users/form' }}

Now we need to edit the two controllers. In App.UsersNewController add to the two attributes:

  
  headerTitle: 'Create'
buttonTitle: 'Create'

And likewise in App.UsersEditController:

  
  headerTitle: 'Edit'
buttonTitle: 'Update'

Last part for this section is to add the update action to app/controllers/users_controller.rb:

  
  def update
  user = User.find(params[:id])
  if user.update_attributes(params[:user])
    render json: user
  else
    render json: user, status: 422
  end
end

Now go through and everything should work! This allows us to treat the templates similar to a partial in Rails.

Finally we're going to add the ability to delete records. Because this is an action we are going to limit to the edit page we will put the link below the render call

  
  <a href='#' {{action 'destroy'}} class='btn btn-danger'>Destroy</a>

Now we add the action to the App.UsersEditController

  
  destroy: ->
  @content.deleteRecord()
  @store.commit()
  @transitionToRoute 'users.index'

And we add the destroy action to the backend

  
  def destroy
  user = User.find(params[:id])
  if user.destroy
    render json: user, status: 204
  else
    render json: user
  end
end

The 204 status here is refers to No Content. Ember-data expects this to ensure the destroy action is a success.

That's it! You've just created your very first Ember app with all of the CRUD actions. Congratulations!

Building an Ember app with RailsAPI - Part 2

2013-01-09 00:00:00

This article was last updated on May 28, 2013 and reflects the state of Ember (1.0.0-rc4) and the latest build of Ember Data (0.13) as of that date.

Fork the project on Github!

Use the app live on Heroku

In Part 1 I showed you how to setup a Rails-API app for Ember. Now let's build the app itself.

In this part I will go over building the Ember app from the perspective of a Rails developer. I will be making comparisons to where Ember resembles common patterns in Rails and even Ruby itself.

I know I promised a 2-part series but I'm going to extend this to 3-parts. This post was growing too large to cover everything.

Note: this post has been updated since it was originally written. If you were following along you should start from the beginning of this post as changes have been made to reflect the changes on Ember's master branch! *

Part 2 - Building with Ember

We need to start with something I forgot to setup in Part 1. Ember looks for templates in the Ember.TEMPLATES JavaScript object which is provided to us with the handlebars_assets gem we setup in Part 1. We just need to tell the gem to compile for Ember. We can do this in config/initializers/handlebars_assets.rb

  
  if defined?(HandlebarsAssets)
  HandlebarsAssets::Config.ember = true
end

NOTE: If you have skipped ahead and come back to this initializer you will need to run:

  
  rm -rf tmp/*

Otherwise your Ember templates won't compile properly.

Let's dive in by creating our application layout template in app/assets/javascripts/templates/application.hbs

  
  <div class='navbar navbar-inverse navbar-fixed-top'>
  <div class='navbar-inner'>
    <div class='container'>
      <div class='nav-collapse collapse'>
        <ul class='nav'>
          <li>{{#linkTo 'index'}}Home{{/linkTo}}</li>
          <li>{{#linkTo 'users'}}Users{{/linkTo}}</li>
        </ul>
      </div>
    </div>
  </div>
</div>
<div class='container' id='main'>
  <div class='content'>
    <div class='row'>
      <div class='span12'>
        <div class='page-header'></div>
        {{outlet}}
      </div>
    </div>
  </div>
</div>

Building an Ember app with RailsAPI - Part 1

2013-01-07 00:00:00

This article was last updated on May 28, 2013 and reflects the state of Ember (1.0.0-rc4) and the latest build of Ember Data (0.13) as of that date.

Fork the project on Github!

Use the app live on Heroku

Lately I've been playing with Ember.js and I have really grown to love it. I get the same "AHA!" feeling I got building my first Rails app 7 years ago. Let's see how to build a simple CRUD app using the RailsAPI as the backend. We're going to build a new app and deploy to Heroku.

Part 1 - Getting Set Up

  
  gem install rails-api
rails-api new ember-app
cd ember-app

Similar to the rails command RailsAPI comes with a rails-api command which under the hood is just using the normal rails CLI code but overriding some of the templates generated. Out of the box RailsAPI won't generate the asset pipeline directories as there is still some debate if it will use Sprockets, Rake-Pipeline or some other solution. In this example we're going to use Sprockets as it will save us a lot of time. RailsAPI is bundled with ActionPack which has Sprockets as a dependency. All we need to do is add in the directories

  
  mkdir -p app/assets/{javascripts,stylesheets,images}
mkdir -p vendor/assets/{javascripts,stylesheets,images}

Now we need to copy in the vendored asset files. You can either build yourself our run the following to copy directly from my Github project

  
  cd vendor/assets/javascripts
wget https://raw.github.com/bcardarella/ember-railsapi/master/vendor/assets/javascripts/ember-data.js
wget https://raw.github.com/bcardarella/ember-railsapi/master/vendor/assets/javascripts/ember.js
wget https://raw.github.com/bcardarella/ember-railsapi/master/vendor/assets/javascripts/jquery.js
wget https://raw.github.com/bcardarella/ember-railsapi/master/vendor/assets/javascripts/modernizr.js
cd ../../..

Note that if you're a Mac user, just replace wget (the Linux command) with curl -O (the Unix command) on the above lines.

Let's setup the directory structure for our Ember app

  
  mkdir -p app/assets/javascripts/{controllers,models,views,templates}

And now we'll setup the load order in our app/assets/javascripts/application.coffee file

  
  #= require modernizr
#= require jquery
#= require handlebars
#= require ember
#= require ember-data
#= require bootstrap
#= require_self
#= require store
#= require routes
#= require_tree ./controllers
#= require_tree ./models
#= require_tree ./templates
#= require_tree ./views

window.App = Ember.Application.create()

Add the routes.coffee and store.coffee files:

  
  touch app/assets/javascripts/routes.coffee
touch app/assets/javascripts/store.coffee

And the app/assets/stylesheets/application.sass file

  
  @import 'bootstrap'

body
  padding-top: 60px

That was a good amount of setup. Now we have the application structure for an Ember app in our asset pipeline. This will make things cleaner once we start coding.

Let's setup the necessary gem dependencies in our Gemfile. Just replace the entire contents with the following:

  
  source 'https://rubygems.org'

ruby '2.0.0'

gem 'rails', '3.2.13'
gem 'rails-api'
gem 'thin'
gem 'active_model_serializers', :github => 'rails-api/active_model_serializers'

group :development, :test do
  gem 'debugger'
  gem 'sqlite3'
end

group :production do
  gem 'pg'
end

group :assets do
  gem 'sass-rails', '~> 3.2'
  gem 'coffee-rails', '~> 3.2'
  gem 'compass-rails'
  gem 'uglifier'
  gem 'bootstrap-sass', '~> 2.0.3.0'
  gem 'handlebars_assets', '0.12.3'
end

group :development do
  gem 'quiet_assets'
end

There are two gems to take note of:

ActiveModelSerializers is a project that is written by the Ember core team which will normalize the JSON output for models in a Rails app.
HandlebarsAssets will allow the AssetPipeline to compile Handlebars templates which is required for Ember. There is the Ember-Rails gem which will also do this but I have found HandlebarsAssets to be a leaner solution.

After this, don't forget to run bundle install from the command line to pick up the gems we just added.

Let's create a simple model and the serializer

  
  rails-api g model User first_name:string last_name:string quote:text
rails-api g serializer User

Run 'rake db:migrate' to run the migration for our User model. Now open up app/serializers/user_serializer.rb and add the fields that require serialization

  
  class UserSerializer < ActiveModel::Serializer
  attributes :id, :first_name, :last_name, :quote
end

Again, this will instruct Rails to turn our ActiveRecord object into a JSON object properly normalized for Ember.

Let's write the Controller. Create and edit app/controllers/users_controller.rb

  
  class UsersController < ApplicationController
  def index
    render json: User.all
  end
end

Take note that we are inheriting ApplicationController but in a RailsAPI app ApplicationController itself inherits from ActionController::API instead of ActionController::Base.

This basic controller will serve up all of our users to our Ember app. We'll add more later.

Now let's add some routes to config/routes.rb

  
  EmberApp::Application.routes.draw do
  class FormatTest
    attr_accessor :mime_type

    def initialize(format)
      @mime_type = Mime::Type.lookup_by_extension(format)
    end

    def matches?(request)
      request.format == mime_type
    end
  end

  resources :users, :except => :edit, :constraints => FormatTest.new(:json)
  get '*foo', :to => 'ember#index', :constraints => FormatTest.new(:html)
  get '/', :to => 'ember#index', :constraints => FormatTest.new(:html)
end

A few things are happening here:

We are constraining against the format with a custom FormatTest class. We only want to map certain routes to JSON requests and certain routes to HTML requesets.
The get '*foo'... will greedily match all routes except / so we have the following line. We want to direct all HTML requests to a single controller#action. I will go into the reason why in a bit.

So let's create that Ember controller. This will act as the primary application serving controller that is hit when people visit the app. Create and edit app/controllers/ember_controller.rb

  
  class EmberController < ActionController::Base; end

Note that we are inheriting from ActionController::Base this time and not ApplicationController. This is so that the controller actions can respond to non JSON requests.

Now we will add the view in app/views/ember/index.html.erb

  
  <!DOCTYPE html>
<html lang='en'>
  <head>
    <%= stylesheet_link_tag :application, :media => :all %>
    <%= javascript_include_tag :application %>
    <title>Title</title>
  </head>
  <body>
  </body>
</html>

That is all the view that your Ember app will need. Ember will automatically attach its own default template to the <body> tag.

Let's add some data to db/seeds.rb

  
  User.create(:first_name => 'William', :last_name => 'Harrison', :quote => "I'm just singin' in the rain!")
User.create(:first_name => 'Abraham', :last_name => 'Lincoln', :quote => "I'd like to see a show tonight.")

Now run your migrations and seed

  
  rake db:migrate db:seed

Ok, now our app is in a good spot to start developing an Ember app with. Let's review what we did

Generated a new app using rails-api
Set up the javascript and stylesheet assets
Wrote a very simple JSON API for returning all users

In Part 2 we'll build the Ember app itself.

DismissibleHelpers released

2013-01-04 00:00:00

Have an application where you want to add some help text for the user, but they really only need to see it once? With the dismissible_helpers gem, you can quickly add dismissible help text to your application.

What you get

DismissibleHelpers includes:

DismissibleHelpers View Helper - Renders the help text only if the visitor has not dismissed it
DismissedHelpers Routes and controller - Handles the JavaScript requests to store the dismissal state
DismissedHelpers Javascript - Handles the front end interactions with the help text

By default, dismissible_helpers will use a cookie to store the dismissal status of the help text.

Three minute setup

To start using dismissible_helpers without any customization, you only three steps away.

Add dismissible_helpers_routes to your config/routes.rb ```ruby YourApplication::Application.routes.draw do dismissible_helpers_routes # Your other routes end```
Add the Javascript: Add the following to your app/assets/javascripts/application.js. ```javascript // Your other require statments //=require dismissible_helpers //=require_self $(function(){ $('.dismissible').dismissible() })```
Call the render_dismissible_helper method with the string you want to render. The string passed to the method will be processed by the I18n method t, so the content of the help message should be stored in your localization file. ```erb <%= render_dismissible_helper 'help.some_help_message' %> ```

Advanced setup

Changing the way the help text is removed

By default, the dismissed helper is removed from the page via $(helper).remove(). This can be customized by passing a callback to the .dismissible() call. To use jQuery's .slideUp() you would use the following call:

  
  $(function(){
  $('.dismissible').dismissible({
    success: function(helper){
      helper.slideUp(); //'helper' is the jQuery-wrapped element
    }
  });
});

Storing dismissed helpers for authenticated users

dismissible_helpers can store the help text dismissal state on a user/account. That way, when a user dismisses some help text, it follows them across browsers.

dismissible_helpers will attempt to retrieve the authenticated user by checking for a current_user helper method. If the ApplicationController responds to current_user, dismissible_helpers will check to see if the returned object has a dismissed_helpers attribute. It will then add the dismissed help text to that model.

dismissible_helpers expects that the dismissed_helpers attribute is an array. With vanilla ActiveRecord, you can achieve this with attribute serialization:

First, add the column to your model (we'll assume it's an Account class in this example)

  
  class AddDismissedHelpersToAccounts < ActiveRecord::Migration
  def up
    add_column :accounts, :dismissed_helpers, :text
  end

  def down
    remove_column :accounts, :dismissed_helpers
  end
end

Then add the serialize call to your model

  
  class Account < ActiveRecord::Base
  serialize :dismissed_helpers, Array
end

If you are using PostgreSQL as your database, you could use postgres_ext to add native array support to your models. You would just need the following migration to add the dismissed_helpers attribute to your model:

  
  class AddDismissedHelpersToAccounts < ActiveRecord::Migration
  def up
    add_column :accounts, :dismissed_helpers, :string, :array => true
  end

  def down
    remove_column :accounts, :dismissed_helpers
  end
end

Wrapping up

Hopefully you find the gem useful. If you find any issues with it, let us know!

Integration is Hard

2013-01-03 00:00:00

There's no one-size-fits-all approach to integrating with external systems because each system comes with its own unique requirements and constraints. This article aims to describe some of the varying approaches we used to integrate with external systems in a recent project we built for the AFL-CIO's Super PAC Worker's Voice.

For this project, integration with external vendors was the biggest technical hurdle to clear in order to ensure a successful launch. The project, called RePurpose, gives volunteers and activists a way to choose how the movement's resources get deployed. The more volunteering and activism a person does, the more RePurpose points they earn, which they can then use to direct the funding of things like more canvassers, direct mail pieces or online ads.

It's a way to give the people on the ground a say in how the money gets spent.

The volunteering and activism data for which RePurpose points get awarded exists in several separate systems:

VAN

VAN is the de facto standard tool used everywhere in progressive politics - from small local races all the way up to the Obama campaign. It's an organizing tool that stores volunteer records, canvass records (door knocks and phone calls), activist codes, and other organizing data used by progressive campaigns and organizations.
Salsa Labs

Salsa has a platform with a rich API and tools to create fundraising and advocacy campaigns and manage organizer data. It stores supporter records, online donation records, and pledges to take action - among other things.
Amicus

Amicus is a new online tool that leverages Facebook connections of volunteers to enhance fundraising and advocacy campaigns. It stores a set of volunteer records, friend invite records, and social calling records.

The goal was straightforward - RePurpose needed to know when a volunteer was performing tasks in external systems, so that the user could receive points in RePurpose for those tasks. RePurpose itself has a Task model that supports multiple kinds of tasks in the various external systems - survey tasks, activist code tasks, and canvass tasks in VAN, donation tasks and action tasks in Salsa, and friend invite tasks and call tasks in Amicus. So a RePurpose administrator could set up a task that would award 10 RePurpose points each time a volunteer knocked on a door, made a phone call, or made a donation.

Here's how we did it in each system:

VAN Sync

VAN, which was recently voted Most Valuable Tech at RootsCamp 2012, has a SOAP-based API that allows us to list survey questions, list activist codes, and create and list volunteers (among other things) - all of which we use to get that data into RePurpose, but the API doesn't support retrieving the raw canvasser data - which is the piece we really need to award credit. To get this data the two options were a nightly sync of flat files, or getting direct access to a replicated database. We opted for the flat file sync as we knew it had worked for other organizations (among them the Democratic National Committee) and the replicated database approach would have incurred extra time, expense, and risk.

We worked with the great folks at VAN to get a nightly data sync into place. Each night around 3am, VAN uploads a zipped TSV (tab-separated values) export of the relevant data from all the relevant tables in the AFL-CIO's VAN database. This is not a delta - because the data size is relatively low (< 1 GB), we receive the full data dump each night. We then unzip, verify that all the files we expect are present, convert character encodings from CP1252 to UTF8 (VAN uses MSSQL Server), and load this data into auxiliary tables in the RePurpose database using PostgreSQL's "COPY" command. All told it takes about 5 minutes each night to process, load, and index around 700MB of data from flat files to get it into PostgreSQL and ready to be used. Then based on the new data we award credit to volunteers for completing tasks. This approach handles the most data of any of the external integrations and does so reliably. It has one drawback which is that the data can be at most 24 hours stale by the time we receive it, which is not ideal but is certainly workable. In practice this has not been a problem for us.

Salsa API

Salsa has a REST-based API for authenticating and for creating and retrieving objects in the Salsa system. For RePurpose, that meant creating and listing supporters (Salsa's name for a volunteer record), listing donation pages, listing donations, and listing completed actions like making a pledge or writing a letter to an editor. In the context of RePurpose we were most interested in listing completed donations and completed actions so we could award the person who completed the task with their RePurpose points. Since we could get all this information via the API, and since the API can list objects created since a certain timestamp, we set up a scheduled job to poll the API and ask for anything new that has come in since the last record we retrieved. This job runs every 10 minutes and gets us pretty close to realtime - if you make a donation through one of the Salsa donation pages that's connected to a RePurpose task, your points will be credited to you within 5 minutes on average.

Amicus Exports

The Amicus API was still a work in progress during the RePurpose project, so we could not use it - but they did have an on-demand user export that could be programmatically triggered. Since the user export contained all the information we needed about how many calls a user had attempted and how many friends they had invited on Facebook, this would get us where we needed to be. We would import the Amicus users nightly on a schedule and load them into auxiliary tables in the RePurpose database, which were then used to award credit to the folks making calls and inviting friends. Since we could trigger the export on demand, we also added a button to the RePurpose admin area to allow administrators to reload the Amicus data on demand and credit any new arrivals.

Matching

You've heard how we get the data into the RePurpose system, but how do we match the volunteers from the various external systems up with the users in RePurpose?

There are all kinds of pitfalls in implementing person matching, like trying to match up on variations of a first name, or variations of a street address, or keeping track of previous known-good addresses. Complexity can quickly spiral out of control for marginal benefit. For this project we went with a simple assumption - all matching would occur via email address. So if a user was doing things in the field, which gets recorded into VAN - they should use the same email address that they would use to create their RePurpose account. Likewise for Salsa and Amicus. Since each of these external systems stores an email address for the volunteer, with this simple assumption, the matching logic becomes simple - comparing lowercase versions of email addresses.

Awarding Credit

There were some wrinkles with awarding credit for tasks performed in external systems. Since each task hinged on an external datapoint, it was critical to uniquely identify these datapoints. For most tasks, the granularity of data allowed us to use the primary key of the foreign data source as the unique identifier. In some cases the data would just be an aggregate count, like "15 calls made" - in which case we would generate our own idempotent IDs for those calls so as to award credit once and have a way to prevent awarding credit for the same call a second time. In addition to keeping things crediting properly, this had the added benefit of allowing any RePurpose points in the system can be traced back to the explicit data point in the external system that was responsible for creating them.

Wrapping Up

Now that you've seen how we took three different approaches to integrate with three different systems, you're probably thinking that integration can be tricky. But if you're in a progressive organization that uses VAN, Salsa, or Amicus - remember that here at DockYard we have the expertise and experience to make it look easy.

OpenHack Boston 1.0

2012-10-26 00:00:00

Last night we hosted Boston's first OpenHack event.

Nick Quaranto started OpenHack at his CoWorkBuffalo office space, based upon BostonRB's former (don't get me started) Hackfests. The idea is pretty simple: a quiet space with food, drinks, and wifi is provided. Developers show up and hack on some software for a few hours.

On 2-day notice we had 11 in attendance and all around everyone had a very productive night. Currently our office maxes out at 20 chairs so until we buy more we cannot accept over 20, but next month we will open the event to a wider audience. We want to welcome more than just Ruby devs (with the exception of 2 all were Ruby devs) to the event.

Follow @DockYard for all Boston OpenHack announcements.

Expanding the Yard

2012-10-11 00:00:00

Outgrowing simplicity

The first version of our site was contained within a single page. At the time, it served its purpose well. As we added more, it began to feel like it trying to do too much. Upon recognizing this, we began reimagining our site.

Structural changes

The very first step we took was to establish a reasonable structure of our new site. This helped to inform the site content, and much of the new site design.

We decided to make the landing page an overview of DockYard. Our work deserved its own place to be shown. We have added people to our team, and we wanted a page dedicated to community & open source projects. We have this blog thing, and we also wanted a dedicated contact page.

Design & code

After the structural decisions had been made, it was time to put down some design. This was done primarily in the browser using actual code. This allowed rapid iteration over page layout, content tweaks, and especially mobile design. Being able to try things almost right away in browser informed many design decisions.

With the new design, the Narwin (half narwhal, half penguin) was introduced as our mascot and overseer of all things nautical. We have high confidence that he will serve us loyally now and in the future.

Well done

It was a lot of fun to reimagine our site and we are all proud of the result. It is designed to grow and evolve along with us.

There are plenty of hidden surprises in the new site. See if you can find an easter egg or two.

ClientSideValidations 3.2 Released!

2012-10-09 00:00:00

I just released ClientSideValidations 3.2

This is a very big release for the gem, one that took way too much time to get done. I want to start by re-introducing people to the gem, what the value is, and what the changes for 3.2 are.

ClientSideValidations is just that, it will extract the validations from your model and apply them to your forms on the client. The README has more comprehensive instructions. But here is the quick guide:

Add rails.validation.js to your asset pipeline, then add :validate => true to your form like so:

  
  <%= form_for @user, :validate => true do |f| %>

And that is it. If you have more complex validators or custom validators on your models then you can quickly support these as well.

Changes

Version 3.2 brings many changes to the gem. The first of which is that from this version on we will be following Semantic Versioning or trying our best to do so.

The next change, and the biggest backward-incompatible change, is that the support for SimpleForm, Formtastic, Mongoid, and MongoMapper have been removed. These have been put into their own plugins:

This will be the convetion from now on. The ClientSideValidations gem itself will only support Rails out of the box. If there are additional FormBuilders or ORMs that people need support for these will be done so via the plugins. This will allow for quicker bug fixes and less complexity in the core gem.

I have also released a gem for Turbolinks support. Turbolinks support will be part of the core gem for the next release (4.0).

There have been a significant number of bug fixes for this release. If you ran into a bug before odds are it is now resolved.

Procs are now fullow supported in ActiveModel validators, you just have to force the validation to evaluate:

  
  <%= f.text_field, :validate => { :length => true } %>

I have also added a FormBuilder method for adding validations for attributes that are not being written to the form but may be added dynamically later:

  
  <%= f.validate :age, :weight %>

This method can also take validator specific options.

JavaScript API Additions and Changes

The first major change is that data-validate="true" is no longer rendered on the inputs server-side. It is added to the input at run-time.

The second is the addition of some jQuery functions:

  
  $(form or input).enableClientSideValidations();
$(form or input).disableClientSideValidations();
$(form).resetClientSideValidations();

$.fn.enableClientSideValidations() acts upon either a form or input and will enable them for ClientSideValidations. If you are adding forms or inputs dynamically to the DOM via AJAX or some other means you need to call this function on them.
$.fn.disableClientSideValidations() acts upon either a form or an input and will disable them for ClientSideValidations.
$.fn.resetClientSideValidations() will reset the validations. This means disabling, removing all error messages, and enabling validaitons.

Security

There have been some security fixes. Mostly around the Uniqueness middleware.

Calls to the uniqueness middleware only act upon models and attributes that have a uniqueness validator defined in the model.
The API for turning off uniqueness app-wide has been changed.

Backwards incompatiable changes

If you were relying upon data-validate="true" being rendered on the inputs from the server your code will break.
ClientSideValidations::Config.uniqueness_validator_disabled has been removed. Please add ClientSideValidations::Config.disabled_validators = [:uniqueness] to your initializer if you require this functionality.

Please give the gem a try and let me know what you think!

Querying PostgreSQL datatypes in ActiveRecord with postgres_ext

2012-09-21 00:00:00

I created the postgres_ext gem to add ActiveRecord support for PostgreSQL datatypes in Rails 3.2+. So far, I have added support for the CIDR, INET, MACADDR, UUID, and array datatypes. Please open an issue on GitHub if you'd like other datatypes supported that aren't currently. Since we can now add these columns via Rails migrations, and have INET/CIDR and array columns converted to Ruby IPAddr and Array objects, resepectively.

Rails 4.0 has also added support for CIDR, INET, MACADDR and array datatypes.

It would be great if we could take advantage of PostgreSQL's query support for these datatypes. Wait, we can already do that!

Querying against arrays using `ANY` and `ALL`

In PostgreSQL, you can query for records where any or all elements match a given predicate.

  
  SELECT *
FROM users
WHERE 'johnny' = ANY(nicknames)
-- Finds any record that has 'johnny' stored in the nicknames array

SELECT *
FROM user_scores
WHERE 1000 > ALL(scores)
-- Finds any record that has over 1000 stored in every element in the
-- scores array

We can actually use arel to generate these queries.

  
  user_arel = User.arel_table

any_nicknames_function = Arel::Nodes::NamedFunction.new('ANY', [user_arel[:nicknames]])
predicate = Arel::Nodes::Equality('test', any_nicknames_function)

sql_statement = user_arel.project('*').where(predicate).to_sql
#=> SELECT * FROM \"users\" WHERE 'test' = ANY(\"users\".\"nicknames\")

users_with_nickname = User.find_by_sql(sql_statement)

In the above example, we have to create an Equality node manually since the left hand side of the predicate is the value, instead of the column. If you need < in your predicate, you would create a LessThan node instead of an equality node.

This example applies to both Rails 3.2+ with postgres_ext and Rails 4.0 with native array support.

Array overlap

In PostgreSQL, you can check if two arrays have one or more elements in common by using the overlap operator, &&.

  
  '{1,2,3}' && '{4,5,6}'
-- f
'{1,2,3}' && '{3,4}'
-- t

In postgres_ext, I added a new Arel predicate node for the overlap operator. For the time being, it is named ArrayOverlap and can be called from a Arel::Attribute as #array_overlap. It is likely that this will be renamed to Overlap and #overlap, respectively, in the next release of postgres_ext.

  
  user_arel = User.arel_table

User.where(user_arel[:tags].array_overlap(['one','two'])).to_sql
# => SELECT \"users\".* FROM \"users\" WHERE \"users\".\"tags\" && '{one,two}'

One case that we have used an array column in tandem with the overlap operator was adding tags to a user. We had three tags that could be placed on a user, so we stored this data an array column. We then had a search form which had a multiselect field for that tags column. The multiselect would give us an array of possible values that we wanted to find records that had any of those selected values. So instead of crafting a statement with multiple ANY queries ORed together, we used overlap instead, resulting in only one predicate.

INET/CIDR subnet inclusion

In PostgreSQL, you can see if a particular INET address is contained in a specific subnet with the contained within operator, <<.

  
  inet '192.168.1.6' << inet '10.0.0.0/24'
-- f

inet '192.168.1.6' << inet '192.168.1.0/24'
-- t

In postgres_ext, I added a new Arel predicate node for the contained within operator. It can be called from a Arel::Attribute with #contained_within. I also added a visitor for IPAddr objects so that they are correctly converted to quoted strings when called within a Arel predicate.

  
  user_arel = User.arel_table

User.where(user_arel[:ip_address].contained_within('10.0.0.0/8').to_sql
#=> SELECT \"users\".* FROM \"users\" WHERE \"users\".\"ip_address\" << '10.0.0.0/8'

We're not done yet

We have only scratched the surface of the datatype specific functions and operators in PostgreSQL. There are many more to be implemented, and the plan is to support them all. This post highlights what has been implemented so far, and also what you can do with Arel already. I plan to put together some pull requests for Arel to add in some of the PostgreSQL operators. If there is an operator missing in postgres_ext that you want/need, please open an issue on Github!

Making of the DockYard Narwin

2012-09-20 00:00:00

Half narwhal, half penguin. He's a cute lil' fella with quite the personality. He set the stage for the redesign of our website while becoming DockYard's new brand mascot.

The Final Version:

The Evolution:

Rails 4.0 Sneak Peek: PostgreSQL array support

2012-09-18 00:00:00

I'm happy to announce that Rails 4.0 now has support for PostgreSQL arrays. You can create an array column easily at the time of migration by adding :array => true. Creating an array column will respect the other options you add to the column (length, default, etc).

  
  create_table :table_with_arrays do |t|
  t.integer :int_array, :array => true
  # integer[]
  t.integer :int_array, :array => true, :length => 2
  # smallint[]
  t.string :string_array, :array => true, :length => 30
  # char varying(30)[]
end 

It should be noted when setting the default value for an array column, you should use PostgreSQL's array notation for that value ({value,another value}). If you want the default value to be an empty array you would have :default => '{}'.

  
  create_table :table_with_arrays do |t|
  t.integer :int_array, :array => true, :default => '{}'
  # integer[], default == []
  t.integer :int_array, :array => true, :length => 2, :default => '{1}'
  # smallint[], default == [1]
end 

An example of a model with an array value

Let's say that we have a user model, which has a formal first and last name, and also a number of nicknames (I rarely ever go by Daniel). The following code would create the table we need to store this.

  
  create_table :users do |t|
  t.string :first_name
  t.string :last_name
  t.string :nicknames, :array => true
end

And we have a simple model for this table:

  
  class User < ActiveRecord::Base
  attr_accessible :first_name, :last_name, :nicknames
end

Where we don't have a default value, if we instantiate a User object with the following

  
  john = User.create(:first_name => 'John', :last_name => 'Doe')

If we call john.nicknames, nil would be returned, and is stored as NULL in PostgresSQL. We can set the nicknames attribute at the time of creation with

  
  john = User.create(:first_name => 'John', :last_name => 'Doe',
  :nicknames => ['Jack', 'Johnny'])

If we then retrieved this record from the database, the nicknames value would be casted to an array, instead of returning the string of {Jack,Johnny}. Rails 4.0 has a pure ruby array value parser, but if you would like to speed up the parsing process, the previously mentioned pg_array_parser gem will be used if it is available. PgArrayParser has a C extension, and a Java implementation for JRuby (although the gem currently broken in JRuby, this is something I am fixing now).

One important thing to note when interacting with array (or other mutable values) on a model. ActiveRecord does not currently track "destructive", or in place changes. These include array pushing and poping, advance-ing DateTime objects. If you want to use a "destructive" update, you must call <attribute>_will_change! to let ActiveRecord know you changed that value. With our User model, if we wanted to append a nickname, you can do the following:

  
  john = User.first

john.nicknames += ['Jackie boy']
# or
john.nicknames = john.nicknames.push('Jackie boy')
# Any time an attribute is set via `=`, ActiveRecord tracks the change
john.save

john.reload
john.nicknames
#=> ['Jack', 'Johnny', 'Jackie Boy']

john.nicknames.pop
john.nicknames_will_change!
# '#pop' changes the value in place, so we have to tell ActiveRecord it changed
john.save

One last note about arrays in PostgreSQL: there are no element count constraints, and any array can be multidimensional. With the multidimensional arrays, they must be "square" (the sub arrays must all have the same number of elements).

  
  [[1,2,3], [2,3,4], [4,5,nil]]
# Valid array value in PostgreSQL, each subarray has the same number of
# elements
[1,2,[3,4]]
# Invalid array, we are mixing values and arrays at a single level

In my next article, I will talk about querying PostgreSQL arrays in both postgres_ext and Rails 4.0. Go forth and use arrays in Rails 4.0!

Doug Yun is a DockYarder!

2012-09-05 00:00:00

Doug has been training with us for the past month and this week we've released him from his cage on the nearest client app. He's running wild!

This rounds out our Boston team to 4! ZOMG!

Follow him on the Twitters and github

Lessons Learned: The First Hire

2012-08-30 00:00:00

In February we made our first full-time hire with Dan McClain. He came on board at a time when our company was not very stable but we needed to grow to accomodate the larger contracts we wanted. I want to discuss the risks and benefits on making the first hire.

You will lose money

One of the first things you learn about making your first full-time hire beyond the founders is that you will most likely lose money. Which is kind of backwards because the entire point of hiring is so more money can be made. Brian Kaney at Vermonster told me this after we had already hired Dan. I was accustomed to balancing 3 people's salaries and now a 4th was in play and we didn't have any extra money coming in. So we the partners had to take less money. After Brian told me that Vermonster had similar growing pains it made me feel better. I've since spoken with others that have said the same. I suspect this is partly due to my inexperience as a first time business owner, if I ever start another company I can plan better for this. It is also due simply to the fact that we didn't have any extra work coming in and were now dividing the money 4 ways instead of 3. The employees have to be paid, the partners don't. I took on the brunt of the risk and actually just started paying myself for the first time in 2012 at the start of August. It was totally worth it.

Be picky who you hire

I'd like to say that Dan hired himself rather than we hired him. He was somewhat new to the Boston Ruby community but was going out of his way to make himself known. He took the initiative to introduce himself to me and wanted to make contributions to the BostonRB website. He developed a feature, made a pull request, and I gave him feedback. What impressed me was how quickly he adapted to the feedback I gave him. This told me one thing: Dan was a very quick learner. Before DockYard was even looking to hire Dan contacted me and expressed interest in being hired. When it came time for us to make a hire he was the first name that came to mind. I think the lesson to learn here is if you want to work somewhere, don't wait for them to hire for your talent. Contact them, let them know you are interested even if they don't have anything available. When the time comes they'll remember you.

Make full-time hires, don't contract to hire

We hired Dan on a contract-to-hire basis. The idea at the time was to have Dan on a "trial" period, test him out, see how he fit. I didn't like how this went and I don't think it was fair to Dan to hire this way. If you are hiring for a position, hire full-time. If things aren't working out you are always within your rights to let the person go. Whenever you are hiring someone there is always the risk that it won't work out.

Be mindful of taxes, benefits, salaries, etc...

Now that we had our first full-time on board we had to standardize everything. The best way to describe how I was handling all of this up until our first hire is "half-assed". I was the only one living in Massachusetts where it was required to have health-care so I was using the MA Health Connector (a terrible service), we were handling time-off as "whenever you want" which of course doesn't fly well as you scale, and taxes were a mystery to me. Let's break each one down to see what we've done:

Benefits

I went for the best health-care I could find for employees. When it comes down to it we're only talking about the difference of a few hundred dollars each month. If we go under because of this cost then I deserve to lose my company. If one of my employees cannot see the doctor they need to because of sub-standard health coverage I run the risk that they will not be back to work as quickly as they would otherwise. This risk costs far more than the extra $$$ for the better plans.

DockYard is currently covering 3/4 of the healthcare and I hope to bring that up to 100% in 2013.

We're doing 3 weeks of paid vacation per year. Employees can take off two weeks at a time. I am also experimenting with how to handle overtime. Because we're doing client work and sometimes deadlines have to be met I've told everyone that there will be a day when they get Lumberged. I'm going to be the guy that will have to ask people to work over a weekend, I don't like it and I would be pissed if I was on the receiving end of that. So, to compensate we'll offer an added vacation day in exchange for each weekend day. Of course employees can say "no" to working on the weekend. I understand that there are sometimes plans that are made well in advance.

Payroll

This is something we have struggled with. Everyone has always been paid but sometimes it has been a day late because of mistakes on my part. Originally I was cutting checks to everyone and mailing them myself. I would manually enter the data into QuickBooks for our accountant. This sucks. I eventually got it down to where it would only take me 5 minutes to do but for a while it was pretty disruptive. We eventually moved over Direct Deposit through QuickBooks. This was much better, and quicker. If you are not doing Direct Deposit you should highly consider it.

We've recently moved from QuickBooks to Less Accounting and Sure Payroll. QuickBooks blows. We only used it because our accountant suggested it. Here is some advice: don't let your accountant make software decisions for you, especially if you are a software consultancy. Our accountant is awesome, but QuickBooks is not. We lost an entire month of payroll, tax, and vendor payment data because a QuickBooks file corrupted. Never again.

Salaries, taxes

One huge mistake I made even before hiring Dan but continued into a month after he was hired was not withholding taxes from paychecks. We were losing money after our first quarterly taxes were paid and I couldn't figure it out. In retrospect it is pretty obvious what I should have been doing but keep in mind this was my first company, I never had to deal with this before, and simply fucked up. Things turned around after I corrected this. I didn't ask for employees to payback the money. I'm not trying to push this idea that I'm a "good guy" but this was my screw up and I took the hit.

Also, pay people well. "Industry average salary" will earn you "industry average employees". If it is well known that you are paying high salaries you will attract talented people. Talented people will more than make up the difference.

Hiring ain't easy

I've heard the term "peak people" thrown around a lot recently. It refers to the huge talent shortage that the tech industry has. It's true, it exists. You know why? Because everybody wants to hire top talent and nobody wants to train. I think it is pretty bullshit for companies to not train developers. Personally I would rather hire a developer that requires training that is a quick learner than hire a mid-level dev that is set in his/her ways. We got lucky with Dan, he required very little ramping up. Mostly just a push here and a push there. We've recently hired Doug Yun as a trainee. I told Doug that we are experimenting with him, I want to establish a training program at DockYard. So there will be ups and downs to it as we establish a playbook. I realize we run the risk of devs training up, then bouncing out. There are ways to address this. We can offer employment term benefits. If you are at DockYard for a year your salary will increase by X% every year. Let them know what the path for advancement is. We need to get better at this and it is something I want to focus on over the next few months. I would love to hear feedback and how others are approaching this.

It pushes you to make things happen

The best benefit of hiring is that it personally motivates me to grow the company. When it was just the co-founders we always had the fallback that a payroll period could be skipped. As I mentioned earlier that is not a choice when you have employees. Money must come in, people must get paid. Personally I have found this to be a good motivator for growing DockYard.

Share your experiences!

If you agree/disagree with anything I said, have a different perspective, or any general advice I'd love to hear it.

DockYard blog

Building a Shared Language

Experience Economy, user interviews, and design discovery

The principle of customer sacrifice

Are you limiting the upside of customer UX?

Understand customer sacrifice through user interviews during design discovery

Optimizing Your Elixir and Phoenix projects with ETS

Optimizing GenServer access with an ETS table

ETS to the rescue

Here Be Dragons

Five Business Problems Progressive Web Apps Solve

DockYard Senior Engineer To Present at GOTO Chicago

DockYard Launches Redesigned Website

What type of business problem are we solving?

Itâs not just what you doâitâs where you do it.

What this means for designers

What this means for business owners

Improving Ember app page load times using the App Shell model

Why improve page load speed?

Tools of the trade

What I'm measuring

Getting the baseline

Baseline Lighthouse score

Baseline Desktop: Page load with empty cache

Baseline Desktop: Page load with warmed cache

Baseline Mobile: Page load with empty cache

Baseline Mobile: Page load with warmed cache.

The changes I've made

Service Worker only Desktop: Page load with warmed cache

Service Worker only Mobile: Page load with warmed cache

Async'ed script Mobile: Page load with empty cache

Async'ed script Mobile: Page load with warmed cache

Async'ed CSS Desktop: Page load with empty cache

Async'ed CSS Desktop: Page load with warmed cache

Async'ed CSS Mobile: Page load with empty cache

Async'ed CSS Mobile: Page load with warmed cache

All the stats summed up in a table

Final Lighthouse score

Browsers without Service Worker

Baseline: Page load with empty cache

After improvements: Page load with empty cache

Baseline: Page load with warm cache

After improvements: Page load with warm cache

Safari tests summarized

Conclusion

How GenServer deals with errors in a concurrent environment

Pattern for stateful server process

GenServer helps with error handling

Ensure source of message using reference

What if the server crashes

Deadlock

Conclusion

Making a DDAU checkbox list in Ember.js

Data Down, Actions Up (A refresher)

Okay... so?

Setup

Checkboxes

Quick detour into helpers!

Actions

Finally

Live Search with Ember & JSON API

On the Ember side

On the Phoenix side

On the Rails side

Conclusion

When you could turn a bug into a feature

âBugâ in behavior

Bug or feature?

Tl;dr.

The Role of Discovery Phases and Design Sprints

What are they?

Differentiating the Two

Length (time)

Structure (time)

Completion (deliverable)

Expertise (team)

Deciding Between the Two

How to Contribute to Ember

tl;dr

Open Source is Used by Everyone

Optimizing `GenServer` access with an ETS table

Itâs not just what you doâitâs where you do it.

Ensure source of message using `reference`

âBugâ in behavior

The rise of `ember-suave`

`ember-suave` returns as an ESLint plugin

Thereâs a time & place for less-deep work