Forem: Jake Faris

Go Tips & Tricks

Jake Faris — Wed, 19 Sep 2018 14:22:36 +0000

After a few years of programming almost exclusively in Ruby on Rails and Javascript, I’ve been fortunate enough to expand my skillset and get involved with some projects that are written in Golang. Golang, also known as Go, is Google’s open source programming language, and has been growing in popularity as a resilient, opinionated backend language. Some of the more interesting features in my opinion are:

Compiled
Statically Typed
Strong concurrency support
Documentation & Testing Tools built in

There are many awesome things about Go, and after developing projects in Go for a little while I’ve found a couple of neat things about the language that I wanted to share. It’s been a while since I’ve blogged, so hopefully this post will put that fire under me and encourage me to pick technical blogging up as a hobby again. As for this post, this is not an exhaustive list of awesome features and libraries (there are too many to name!), but it’s a start. So, let’s get started!

NOTE: This blog post assumes some basic knowledge of Go.

Forced Randomization When Iterating On Maps

Suppose your code has a map in it and you want to display the contents of that map. A common way to do so is to iterate over a range of that map and fmt.Println() the keys/values.

func main() {
  m := map[int]bool{
    1: true,
    5: true,
    99: true,
    101: false,
    14: true,
  }

  for k, v := range m {
    fmt.Printf("%d: %t\n", k, v)
  }
}

It’s more or less commonly accepted that relying on ordered maps is a bad idea, because you’re depending on a functionality that isn’t a primary purpose of that data structure. Golang agrees with this and enforces it aggressively. In fact, it actively randomizes the map’s ordering based on the random seed that’s generated at runtime.

Try it out yourself on this Go Playground (which is a GREAT tool by the way!). In that playground, we’re manually setting the rand.Seed(), which affects the pseudo-random algorithm used by the language. As you re-run the function with the same seed, the map will print out the same way each time. However, when the seed is changed, the ordering changes.

The seed changes with every go run (except on the Go Playground where it’s a fixed seed by default, that’s why the above code manually changes the seed), so you wouldn’t get the same order regularly in production ever. This is Go’s way of enforcing this good behavior!

Embedding and Composing structs

I was impressed to see Go’s methods of Composition and how methods can be shared by “Embedding” structs.

Consider that we have two types, User and Admin:

type User struct {
  Name string
}

type Admin struct {
  User User
  Permissions map[string]string
}

In the above example, there’s a User and an Admin, where the Admin has a User property along with some additional Permissions.

Here, one could access the Name of the Admin via admin.User.Name (assuming there’s an instantiated Admin called admin).

However, consider the removal of one word in the previous example which changes the Admin’s method surface completely:

type User struct {
  Name string
}

type Admin struct {
  User
  Permissions map[string]string
}

Did you notice it? The second User in the Admin struct was removed. This means that the User is “embedded” within the Admin, and all its methods are “promoted” to the Admin as well. This means that one can reference the name of the user via admin.Name - no intermediate call to the User needed!

I found this to be pretty neat - it can definitely be used to share methods and help keep code clean.

Another additional use of this technique is known as “Composing” types, which consists of embedding various types to create other types/interfaces. A good example is in the io library, the ReadWriter, whose code I lifted directly from the Go Docs:

type ReadWriter interface {
    Reader
    Writer
}

What I can see from the above definition is that a ReadWriter is an interface which must contain all the functions defined on both Reader and Writer, which are defined elsewhere. Knowing the way composition is set up in Go, that makes a lot of sense! It also allows the Reader and Writer to be used independently of each other, which is a plus.

Testing

Use the Test flags to your advantage

The testing package provides methods to give the test suite itself a way to know how it is being run. The -v and -short flags that can be used with go test are hooked into the package itself, and the user can write tests that behave differently depending on if those flags are present.

Consider a package and test that look like the following:

import "fmt"

func main() {
  return fmt.Println(helloWorld())
}

func helloWorld() string{
  return fmt.Sprintf("Hello world")
}

import (
  "testing"
  "fmt"
)

func TestHelloWorld(t *testing.T) {
  if testing.Short() {
    t.Skip("Short test suite, skipping test.")
  }

  if testing.Verbose() {
    fmt.Println("About to test helloWorld()...")
  }

  exp := "Hello world"
  got := helloWorld()
  if exp != got {
    t.Errorf("Expected %s, got %s", exp, got)
  }
}

In the above example, you will see that the testing package exposes a testing.Short() and testing.Verbose() method which can be used to dictate testing logic. These correspond directly to go test -short and go test -v. Even though this is more of a minor feature, it allows programmers more expressive control over their test suite, which I appreciate!

Stubbing Tests & Keeping Code Loosely Coupled

One common problem that Go programs suffer from is an inflexibility to stub things out in testing due to Go’s strict type-checking at compilation time. What Go is doing when it complains about typing issues in tests is really surfacing a common problem known as “tightly coupled” code, where functions and structs are explicitly relying on other constructs internally, which prevents them from being tested in isolation.

Here’s an example: Suppose you are building a Go app that hits an API and then does some work. Let’s call the struct that does this a Worker:

type Worker struct {
  APIClient *Client
}

func (w Worker) Work(input string) {
  // Some work here...
  result, err := w.APIClient.Update(input)
  if err != nil {
    return nil, result
  }
  return result, nil
}

This seems great, but consider what a test for this struct might look like:

import (
  "testing"
)

func TestWork(t *Testing.T) {
  // Setup test...
  worker := Worker(&Client{})
  result, err := worker.Work(input)

  if err != nil {
    t.Fatalf("Error: %s", err)
  }
  // Other assertions...
}

The problem with actually calling the Work() function above is that it internally uses the Client.Update() method and that’s not the thing we’re trying to test here! We just want to make sure that the Client is being called with Update(input). In Rails’ rspec tests, stubbing this out would be pretty easy, as we could say something like

expect_any_instance_of(Client).to receive(:update).with(input).and_return(result, nil)

But we can’t stub so easily in Go, as the Go compiler would be very unhappy with us if we tried to instantiate a Worker with anything other than a real life Client struct.

Because the Worker and the Client are tightly coupled, we can’t test one without building out the other. Let’s try to edit the Worker struct so that it isn’t so directly dependent on the Client struct. Instead, we can give the Worker an interface that looks like the Client and has an Update method, like so:

type Worker struct {
  APIClient DataLayer
}

type DataLayer interface {
 Update(string) (string, err)
}

This way, we can make a fake Client in our test and bypass all of the logic that takes place in the real Client struct. (Obviously, we’ll have to test that separately 😉) Our updated test could look something like this:

import (
  "testing"
)

type FakeClient struct {
  updateCalled bool
}

func (f *FakeClient) Update (string, error) {
  f.updateCalled = true
  return "", nil
}

func TestWork(t *testing.T) {
  // Setup test...
  client := &FakeClient{}
  worker := Worker(client)
  _, err := worker.Work(input) // Goes out an hits an API

  if client.updateCalled != true {
    t.Fatal("Expected Client.Update() to be called")
  }
  // Other assertions...
}

Now, we can use our stubbed Client class to verify that the Worker’s internals are behaving correctly without having to worry about the details of Client!

Unlike Ruby or Javascript, where testing frameworks are built by external parties that aim to give their languages a rich testing culture, Go’s testing features are built in with the default libraries. What usually ends up happening with Go tests are suites that may need a little extra setup, but the benefit is that there’s no additional testing DSL that programmers need to learn - it’s all just Go code! Writing tests so closely to the executed code helps bring extra clarity to what you’re working with.

Benchmarking

Benchmarking, in Go and all other languages, is the process of evaluating the performance of code.

In Go, benchmark tests are constructed similarly to conventional tests. Benchmark tests follow some strict guidelines and look like so:

func Fib(n int) int {
  if n < 2 {
    return n
  }
  return Fib(n-1) + Fib(n-2)
}

import "testing"

func BenchmarkFib(b *testing.B) {
  for n := 0; n < b.N; n++ {
    Fib(20) // run the Fib function b.N times
  }
}

In benchmark tests, functions start with the prefix Benchmark and take a pointer to a testing.B, not testing.T like logic tests. The tests commonly involve a loop up to b.N, where the benchmark tests control what N is and how many times the tests are run. The tests can be run with the -bench flag, ie:

go test -bench=.

The . here is a regular expression which tells Go to bench everything! If you have a complex suite, you can run a slice of your tests and bench however you like! The results will look something like this:

pkg: farisj/mypackage/fib
BenchmarkFib-4 30000 49477 ns/op
PASS
ok farisj/mypackage/fib 1.996s

This type of work is useful when refactoring, for example. Benchmarking two different algorithms can help programmers make engineering decisions which are backed not only by their own intuition, but by numbers too!

Something that I personally struggle with in regards to Benchmarking is getting used to the idea that the numbers presented are relative to my machine and that there is no objective “speed” that code runs at. Not only are there so many different platforms/processors that run Go code, all of which perform differently, but there are usually a lot of other processes running which use up resources. If I had it my way, there would be some objective ‘score’ that the code could have, but that’s just the way it is! I have to trust the relative performance of different functions and hope that my computer’s processor can handle it.

(Action shot of me trying to accept the things I cannot change.)

Use Delve To Debug

Delve is a Go package that starts a interactive session where the user can set breakpoints in functions, evaluate variables, and step through code in real time. It’s similar to binding.pry in Ruby, although there are a few differences. From what I’ve seen so far, delve is a little more involved than binding.pry, but hey, that’s just Go vs Ruby for ya! It’s a tradeoff for sure.

Given the following example program, we can use delve to inspect our variables:

func (user User) String() string {
  return fmt.Sprintf("%s %s", user.First, user.Last)
}

func main() {
  names := []string{
    "Steven",
    "Connie",
    "Onion",
  }
  for index := 0; index < 3; index++ {
    name := names[index]
    message := Hello(name, index == 0)
    fmt.Printf(message)
  }
}

func Hello(name string, firstTime bool) string {
  if firstTime {
    return fmt.Sprintf("Hello %s. You're first!\n", name)
  }
  return fmt.Sprintf("Hello %s. Happy to see you!\n", name)
}

Once you’ve got it installed (check out the docs), Delve is run with:

dlv debug ./main.go

where ./main.go is the application entry point. From there, the session begins, where you can set breakpoints, evaluate variables, etc. Here are a few of the basics:

Set a breakpoint with the breakpoint command and specify either the function name or line number, ie:

break main.go:25

break main.Hello

Once the breakpoints are set, run continue to start the program. From there, it will begin to execute the code normally and stop when a set breakpoint is reached. Supposing we set a breakpoint on Hello(), we would see the debugger wait for input there:

(dlv) continue
> main.Hello() ./main.go:25 (hits goroutine(1):1 total:1) (PC: 0x1088ffb)
    20: message := Hello(name, index == 0)
    21: fmt.Printf(message)
    22: }
    23: }
    24:
=> 25: func Hello(name string, firstTime bool) string {
    26: if firstTime {
    27: return fmt.Sprintf("Hello %s. You're first!\n", name)
    28: }
    29: return fmt.Sprintf("Hello %s. Happy to see you!\n", name)
    30: }

Then, one can type firstTime to see the value of that boolean! After hitting continue and returning to this breakpoint, the value will have changed from true to false.

Delve seems to be a very effective and helpful tool for debugging applications that provides more flexibility and control than simple fmt.Println() debugging. That being said, I’ve gotten by so far with fmt.Println() debugging, so I haven’t found its usefulness apparent firsthand. I’m waiting for the day I’m working with a very complex application where fmt.Println just doesn’t cut it!

Summary

Golang is a powerful language with a lot of conventions, but also a lot of tools for developers built right in. With an expressive and highly opinionated syntax and structure, it’s easy to jump into a project and start contributing without spending so much time untangling any complicated metaprogramming conventions, monkey patching, or stubbed methods. Switching back and forth between Rails and Go projects lately, I can see how Go’s lower-level syntax and static types can appear challenging, but the truth is that those language choices mean that there are fewer places for bugs to hide!

Venturing into a new language can be pretty daunting, but Go’s vibrant community and stellar documentation tools make it much easier to get started. I would definitely recommend anyone interested in backend programming to dip their toe in the waters of Go and see what it’s all about!

Thanks to everyone taking the time to read my blog post highlighting a few things I’ve learned about Go. Hopefully I’ll be back soon with another informative post!

The Risks You Take When You Use Ember.computed.oneWay

Jake Faris — Fri, 14 Jul 2017 21:22:36 +0000

(Note: this post originally appeared on my company AlphaSight’s blog. You can view that version here.)

The risks you take when you use Ember.computed.oneWay

Ember, the framework for building Ambitious Applications(tm), provides developers a number of tools to build apps quickly. One of the most used tools in this repertoire is Ember.computed, a suite of functions that transform data so that it can be used and manipulated across your application.

Some of the functions provided by Ember.computed are pretty straightforward. Ember.computed.empty takes a stringified key for an array, and returns true or false depending on whether or not that dependent property contains any elements. Ember.computed.gte takes a stringified key that represents a number and an actual number, and returns true or false based on whether or not that dependent property is greater than or equal to that second number.

While the more mathematical computed functions are simple to understand, there are a few more tools provided by computed which need clarification.

alias, readOnly, oneWay

There are several functions that provide a way of renaming or reassigning other values for use in an Ember Object. Don’t feel like writing get(this, 'todo.user.name') over and over, and wish there was a faster way? Ember’s got ya covered.

alias

Ember.computed.alias provides a bi-directional data flow property in your Ember object that allows you to write a shortcut to another property. Referencing the above example, if you kept referencing todo.user.name repeatedly in your Object, you could write a computed.alias to make get and set actions a few characters shorter.

import Ember from 'ember';

const { computed } = Ember;

export default Ember.Component.exend({
    todo: null,
    userName: computed.alias('todo.user.name'),
    //...
});

With a set up like this, you can reference todo.user.name elsewhere in your component (and its template!) without reaching through todo and user every single time.

With computed.alias, get and set actions onto the aliased property behave exactly as if you were referencing the original property. This means that if you’re using a component to set the userName, that would be reflected on that User model in the store.

readOnly

Ember.computed.readOnly is almost the same thing, with one very important difference. The set up for a readOnly property is similar:

import Ember from 'ember';

const { computed } = Ember;

export default Ember.Component.exend({
    todo: null,
    userName: computed.readOnly('todo.user.name')
    //...
});

In this setup, calling get to userName is exactly what you expect. However, trying to call set on this property actually raises an error! You would see this in your devTools if you called set on a readOnly property:

Cannot set read-only property 'userName' on object: <twiddle@component:my-component::ember323>

The readOnly function provides us a healthy reminder about what we should and should not be setting in our application.

oneWay

The Ember.computed.oneWay function is the trickiest one to understand, and also one that is potentially dangerous! Let’s explore why.

The setup is essentially the same…

import Ember from 'ember';

const { computed } = Ember;

export default Ember.Component.exend({
    todo: null,
    userName: computed.readOnly('todo.user.name')
    //...
});

With oneWay, properties act as an alias to their dependent property until they are set. This means that the two properties, once representing the same data, diverge and no longer represent the same value. Suddenly, the data flow has been broken. The original property and oneWay property no longer have a connection, as it’s understood that the oneWay property has been updated in a way that isn’t expected to affect the original object.

What Does This Mean For My Application?

The computed.oneWay property can be great for things like forms, where you really don’t want a new input to immediately persist a change to a model’s field in the Ember Store. However, certain code practices can cause oneWay to unexpectedly create incorrect displays to the user. Let’s explore how.

Consider you have a collection of Todos and are using computed properties to display the data about those todos to the user. Consider the following template:

//templates/application.hbs

<div class="todos">
  <div class="selected-todo">
    {{#if selectedTodo}}
      {{todo-display todo=selectedTodo}}
    {{else}}
      <div>Please View A Todo.</div>
    {{/if}}
  </div>
  <br>
  <div>
    {{#each todos as |todo|}}
      <button {{action (mut selectedTodo) todo}}>
        View {{todo.title}}
      </button>
    {{/each}}
  </div>
</div>

and in the todo-display component/template:

import Ember from 'ember';

const { computed, set } = Ember;

export default Ember.Component.extend({
  todo: null,
  title: computed.oneWay('todo.title'),
  body: computed.oneWay('todo.body'),

  actions: {
    updateBody(){
      set(this, 'body', 'jk, do this thing. haha! youre stuck doing this thing instead');
    }
  }
});

<div class="todo">
  <div class="todo__content">
    <h3>{{title}}</h3>
    <div>{{body}}</div>
  </div>
  <button {{action "updateBody"}}> Update body </button>
</div>

This example’s application/template.hbs provides a few buttons to set a selectedTodo property, and pass that into the todo-display component.

In the todo-display component, we are using computed.oneWay properties to display the todo’s title and body. We also have an action that overwrites the component’s body property.

The entirety of this example is below in an Ember Twiddle.

In this scenario, toggling between Todos at first updates all of the data in the todo-display component correctly. However, after the first time the updateBody action is called, the data flow from todo.body to body on the component is broken. Thus, every subsequent toggle to a different Todo does not update the body property in the component.

This can be dangerous because your application suddenly has mixed state. Now, your users are able to view Todo B with a different body that was actioned when viewing Todo A. If you were performing an action based on the todo-display’s body and title properties, your action may not have the state it was intended to!

This behavior can be useful in other cases. For example,Ember.computed.oneWay can be useful when building a form for a single model. As long as the component is properly destroyed, it would not have a chance to affect another model. If we’re using the same component for multiple models, that’s where the problem occurs.

How Can I prevent this?

One of the problems with this setup is the fact that different todos are being passed into the same todo-display component, and the state of that component is not being reset correctly whenever data changes. One fix to this could be:

//components/todo-display.js
import Ember from 'ember';

const { computed, get } = Ember;

export default Ember.Component.extend({
  todo: null,
  title: computed.readOnly('todo.title'),
  body: null,

  didReceiveAttrs(){
    let body = get(this, 'todo.body');
    set(this, 'body', body);
  }
  //...
});

By hooking into the lifecycle of a component, we ensure that we are setting up our component the same way every time a new todo is passed in. Now, our todo-display component is more robust and does not display our todos incorrectly!

These are but a few of the powerful tools provided by Ember.computed. Now that you’ve read this post and understood the differences between alias, readOnly, and oneWay, go forth and create some side-effect-free components! Cheers ;)

Dotenvious, or, my first foray into Open Source

Jake Faris — Fri, 14 Jul 2017 21:22:36 +0000

Dotenvious; or, my first foray into Open Source

As a software engineer, I rely on Open Source Software each and every day. Open Source Software (herein referred to as OSS) describes a piece of technology that is often community-driven and free to use. Common examples of Open Source Software are Ruby on Rails or ReactJS, but OSS casts a wide net - even Operating Systems (i.e. Linux, Ubuntu) can be open source.

Since I’m using software written by thousands of people from across the globe every day, I thought I’d dive further into understanding how some of this software works in hopes that one day I might be able to contribute. However - this is a nice intention but I also need an idea for an open source project too!

Remembering to keep my eyes out for any problems/projects I might be able to solve with an open source project of my own, I went back to work as a software engineer. At my job, I build web applications primarily with Ruby on Rails and EmberJS. My best bet for creating my own open source project was to find a problem that I encounter regularly and try to come up with a custom solution for my needs.

My Open Source Origin Story

In our biggest Rails Application, we rely on a .env file that contains a variety of sensitive environment variables. In a production environment, these are commonly authentication credentials or variables that point to other applications across our domain. Since we’re a fast paced company with constantly evolving business needs, engineers might add variables to this file at any given time as they’re developing features. Generally, if a new environment variable is required, engineers will commit a fake example into a file called .example-env. This file is used to share domain knowledge across our team and help ensure that everyone’s development environment is consistent.

With this .example-env file constantly changing, I found myself I always am double checking my .env file to make sure it’s up to date with .example-env. This was a manual task that I noticed people on my team often forget to do, and find themselves with a broken development environment without any reason why.

Thus my idea for an open source project was born: creating a CLI to help manage the differences between our various environment variable setups.

I decided to call this project Dotenvious because it served as an extension to manage our current .env process - a gem called Dotenv. Get it? My .env file is ‘jealous’ of its fellow git-committed example files that always have the necessary variables.

I realize that there are a few other open source gems that can do this, but I loved the name and I wanted to further my understanding of gems and open source, so I decided to continue with this process for my own benefit.

How Gems Work

To create a new gem, the easiest way is to install Bundler and run bundle gem my-new-gem. This will create a directory called my-new-gem and create a few subdirectories and important files. Your directory may look something like:

bin/
lib/
spec/
.gitignore
Gemfile
LICENSE.txt
my-new-gem.gemspec

There will be a few other files in there as well. A key file I’d like to mention is the gemspec file. This file contains a lot of metadata and information about how your gem should be compiled among other things. You can view more information about how to develop a gem using Bundler here and more generally here.

The typical development process involves making changes to your gem’s lib or bin folders (or whatever files you’re including via the .gemspec). As the gem is developed, one will have to recompile and reinstall the gem into your console, a la:

gem build my-new-gem.gemspec //=> compiles my-new-gem-0.0.x.gem
gem install my-new-gem-0.0.x.gem //=> Installs updated gem

From my personal experience with my company’s large Rails Applications, I’ve found that there are two real things that I was doing when checking the .example-env file: adding new variables and updating variables as conventions changed.

Given these two use cases, I wanted to create a CLI where one can iterate over different variables in the .example-env file.

Working with Dotenvious

When you run dotenvious in the terminal, Dotenvious will compare the .env and .example-env (by default) and evaluate whether or not they have any differences. If there are any differences, Dotenvious will prompt you to remedy any differences:

You have missing ENV variables. Examime them? [y/n]

As the CLI takes the user through the differences it has discovered, it will either prompt the user to add a new variable or overwrite one that has a different value:

MY_SECRET_KEY=secret
Add to .env? [y/n/q]

ENV[MY_AUTH_TOKEN] is set to: the0dev8token
Example [MY_AUTH_TOKEN] is set to: example-dev-token
Replace with the example value? [y/n/q]

As Dotenvious takes the user through every variable in their example file, they will see a variation of one of the above messages. After this is done, Dotenvious will sort the collection of variables by key, keeping things organized in case the user wants to edit the file manually.

It also will read a .envious file in one’s repository, which looks similar to:

Dotenvious::Configuration.new do |config|
    config.example_file = '.env.example'
    config.custom_variables = ['MY_LOCAL_VAR']
    config.optional_variables = ['GOOGLE_AUTH_TOKEN','OTHER_AUTH_TOKEN']
end

On load, Dotenvious will check to see if this file exists and if so, load whatever customizations are present. If example_file= is set, Dotenvious will check that file as the example file to compare to .env (it is .example-env by default). Additionally, custom_variables will permit whitelisted variables to differ from what is set in the example file (it won’t prompt the user if they are different). Thirdly, it won’t prompt the user for optional_variables either.

My First Feature Request

I announced the Dotenvious project to my coworkers and it was pretty well received! As far as a first iteration of an open source project goes, the general feedback I received was positive - it solved the problem my coworkers were having where they had to scan through the .example-env file for a newly added/changed variable and manually copy it over to their .env file. Dotenvious provided a more automated solution to this while still giving the user full control over the relationship between these two files.

One day, a coworker on a different team approached me with a question. Did Dotenvious work with YML files? They were working on a project in a repository I wasn’t using, trying to wrangle their CircleCI setup to work correctly. As an experiment, he was trying to import some variables in a .yml file to his development environment.

At the time, no, Dotenvious did not work with .yml files. This meant that I had received my first feature request!

Due to the nature of Dotenvious’ internals, this was actually a pretty easy addition to make! Simply moving a few lines of code around, I was able to add this feature pretty quickly.

Future Work

I have some hopes for the future of Dotenvious. I hope to expand the CLI’s functionality to include the ability to add variables to the optional or custom whitelists stored in .envious on the fly. Another feature request that has been asked of me is to export variables from .env directly into the terminal. (This might be dangerous, so I’ve been hesitant to do this.)

At any rate, my experience building Dotenvious has been hugely helpful in providing insight into the development process of other open source projects I appreciate or use frequently. Here’s hoping that another open source project will be near in my future! :D

The Proper Way to Test Custom Controllers in Rspec

Jake Faris — Mon, 11 Jul 2016 01:24:03 +0000

The Proper Way to Test Custom Controllers in Rails

Recently at work we spent some time refactoring one of our app’s test suites to fix a few flaky tests and decrease the total amount of time the suite takes to run. That day, I ran rspec --profile to obtain a glimpse of what test and test groups were slowing the test suite down the most.

Most of the tests were acceptance or request specs that use Capybara or other tools to help simulate real requests from the app. However, two tests were actually controller tests! I was intrigued and dug into those files to find out more.

It turns out that both of the slow specs were testing behavior of controllers that inherit from a parent controller with some specific functionality. At work, our main app serves as a data store to some other applications that we develop. These different apps or contexts all hit specific controllers or namespaces around which we customize security and scope, among other things.

Both of these controller tests defined a new controller that inherited from the controller being tested, and then drew custom routes to hit during the test. After the test was completed, the spec redrew all of the routes to reset things back to the previous router state.

An example of how this looked is below:

class TestController < CustomController
  def index
  end
end

describe TestController do
  before(:all) do
    Rails.application.routes.draw do
      resources :test
      end
    end

  after(:all) do    
    Rails.application.reload_routes!    
  end   

  describe "custom behavior" do
    # tests here
  end
end

Turns out that drawing and re-drawing routes is very costly in Rspec, as both of these tests were in the top ten slowest groups in our entire suite! (Note: A mystery still remains where when I ran these tests individually, they weren’t that slow. Maybe if I figure that out you’ll see it in a blog post in the future!)

Instead of defining a new controller to inherit from the one we want to test, creating new routes, and then erasing those routes once the test ends, we can test controller behavior via a built in Rspec method!

The controller block within an Rspec describe or context will generate an anonymous controller that inherits from the controller class given in the parent describe block. With this in mind, we can rewrite our tests like this!

describe TestController do
  controller do
    def index
    end
  end

  describe "custom behavior" do
    # tests here
  end
end

Now how much cleaner is that! Pretty sweet if you ask me. It also clears up the issue of slowly redrawing routes with each test!

Go forth and test!

Testing React Components With Shallow Rendering

Jake Faris — Sun, 03 Jan 2016 02:44:54 +0000

Facebook’s React provides developers with a lightweight frontend framework that creates views using a blend of Javascript and HTML in what are known as components. While React can be written using pure Javascript, our team constructs these components using JSX - our team prefers it because it dramatically improves readability and has no impact on performance since it transcompiles to pure Javascript on every build. While it will take time to transcompile, a modern web app will need a build step anyway.

Components are designed to be modular and reusable, which actually makes them great for unit testing! This post assumes you have a moderate understanding of React, but let’s look at an instance of two React classes that interact with each other - a simple TodoList and some Todos.

import React from "react";

import Todo from "components/todo";

class TodoList extends React.Component{
  render(){
    var { todoTexts } = this.props;
    return (
      <div className="todo-list">
        <span className="greeting">Welcome. Here are your todos.</span>
        {
          todoTexts.map( (todo, index) => {
            return (<Todo key={ `todo-${index}` } text={ todo } />);
          })
        }
      </div>
      );
  }
}

TodoList.displayName = "TodoList";
export default TodoList;

This TodoList is pretty straightforward - it greets the user with a simple span and then lists as many Todos as were given to it via its parent (let’s assume the parent of the Todo is contacting a store or API or whatever to gather exactly what are the todos).

Now, like good developers, let’s establish a test suite to ensure that our TodoList does exactly what we want it to.

Enter: TestUtils!

React provides a nice set of test utilities that allow us to inspect and examine the components we build.

There are several different uses, but I want to discuss the use of Shallow Rendering. Shallow rendering allows us to inspect the results of a component’s render function, and see check what HTML and React components that particular component returns.

So, just to be sure, let’s make sure that the TodoList returns an element with class “todo-list”, that it has a child element that greets the user (we can guess this by it having a class “greeting”), and that it will render Todos for all of the Todos that are given to it.

A test suite for that might look like this:

import chai from "chai";
import jsxChai from "jsx-chai";

import React from "react";
import ReactDOM from "react-dom";
import TestUtils from "react-addons-test-utils";
import shallowTestUtils from "react-shallow-testutils";

import TodoList from "app/components/todolist";
import Todo from "app/components/todo";

chai.use(jsxChai);

var expect = chai.expect;

describe("TodoList", function(){

  var renderer, todolist;

  beforeEach(function(){
    var todoTexts = ["eat breakfast", "have lunch", "go out to dinner"];
    renderer = TestUtils.createRenderer();

    renderer.render(
      <TodoList todoTexts={ todoTexts } />
    );

    todolist = renderer.getRenderOutput();
  });

  it("renders a todolist", function(){
    expect(todolist.props.className).to.equal("todo-list");
  });

  it("greets the user", function(){
    var greetingSpan = todolist.props.children[0];

    expect(greetingSpan.props.className).to.equal("greeting");
  });

  it("will render three todos", function(){
    var todos = shallowTestUtils.findAllWithType(todolist, Todo);
    expect(todos.length).to.equal(3);

    var dinnerTodo = todos[2];
    expect(dinnerTodo).to.deep.equal(
      <Todo key="todo-2" text="go out to dinner" />
      );
  });
});

Woah, okay, that’s a lot of information. Let’s break it up piece by piece.

Loading Dependencies

The dependencies that I’ve loaded up are as follows:

import chai from "chai";
import jsxChai from "jsx-chai";

import React from "react";
import ReactDOM from "react-dom";
import TestUtils from "react-addons-test-utils";
import shallowTestUtils from "react-shallow-testutils";

import TodoList from "app/components/todolist";
import Todo from "app/components/todo";

chai.use(jsxChai);

var expect = chai.expect;

Let’s go through these piece by piece.

To construct expect statements, I’m using Chai and jsxChai. These libraries will allow us to build expectations directly against JSX components, like expect(component).to.equal(<Todo />) for example.

As of React 0.14.0, the main functionality of React is split into two dependencies, React and ReactDOM. The former consists of all of the fundamental logic that React relies upon, and the latter gives us the virtual DOM into which we can render components and verify that they render the way we want to in the tests.

TestUtils and shallowTestUtils are two other optional React libraries provided by Facebook itself. They are going to be the primary libraries which will allow us to artificially render our components and inspect their inner workings.

Finally, we’re testing the TodoList, so we need that, as well as its inner component, Todo, which we’ll use in a test later on.

The Setup

beforeEach(function(){
    var todoTexts = ["eat breakfast", "have lunch", "go out to dinner"];
    renderer = TestUtils.createRenderer();

    renderer.render(
      <TodoList todoTexts={ todoTexts } />
    );

    todolist = renderer.getRenderOutput();
  });

This beforeEach simply sets up a suitable test environment for each test. Using TestUtils.createRenderer(), it generates an object which can superficially render a React component and return that object which is rendered (in this case, todolist). Since we declared todolist and renderer beforehand, we now have access to them in the scopes of the test.

Test 1: The Todolist

it("renders a todolist", function(){
  expect(todolist.props.className).to.equal("todo-list");
});

As noted above, the todolist variable is the object which is to be rendered. We can treat it like other React components and inspect its props - here we’re just making sure that it receives a className of “todo-list”.

Test 2: The Greeting

it("greets the user", function(){
  var greetingSpan = todolist.props.children[0];

  expect(greetingSpan.props.className).to.equal("greeting");
});

As this test shows, not only can we inspect the rendered component itself, but its children as well. Since the children are delivered down through React components via props, we can obtain the children there. This test simply grabs the first child of the rendered component and ensures that it has a class of “greeting”.

Test 3: The Todos

it("will render three todos", function(){
  var todos = shallowTestUtils.findAllWithType(todolist, Todo);
  expect(todos.length).to.equal(3);

  var dinnerTodo = todos[2];
  expect(dinnerTodo).to.deep.equal(
    <Todo key="todo-2" text="go out to dinner" />
   );
  });

The findAllWithType method comes in super clutch right here.

It traverses the semi-rendered TodoList and returns an array of all sub-components that are of the type passed in the second argument. This way, we can make sure that there are exactly as many Todos as we expect (3, since we passed 3 in to the TodoList), and they look like exactly what we expect.

But Wait, Jake! React Doesn’t work like that, does it?

I know what you may be thinking right now: If the renderer renders a TodoList that contains Todos, shouldn’t the Todos be rendered as well? Isn’t this almost a recursive process of rendering down to the smallest, dumbest sub-component?

No, because we’re using shallowTestUtils! This tool allows us to inspect only the rendered output of that component itself, leaving all React subcomponents as unrendered. In this way, we only need to check that the correct props are passed to subcomponents, and don’t need to worry about their inner details here (we should definitely make a Todo test though!)

Like, totally cool, right?

In this way, React components are made to be very prone to unit testing - we can test a parent component to make sure it renders the subcomponents it needs to, while not having to look at the entire DOM structure that gets rendered when that component is loaded in the browser. It’s really helpful, especially given the complicated nature of front-end and user-simulating tests. So, with your new knowledge of React’s Shallow Rendering, go forth and test!

How Associations Are Built In Rails

Jake Faris — Sun, 20 Dec 2015 22:55:43 +0000

As web developers, one of the core components of our job is figuring out efficient ways to manage user’s data.

In Rails, Active Record gives us many ways for us as web developers to maintain and manage relationships between data points in Rails using its handy dandy ORM. It has a variety of endpoints when it comes to dealing with data, wrapping this functionality into objects that serve our purposes.

However, we need to really understand these tools before we can use them with the finesse that web apps need from time to time. A lot of the time, it’s easy to let Rails abstract away the magic of ORM and creating relationships between data, but what if we want to really understand what Rails is doing under the hood?

This post will address ActiveRecord::Association and outline how relationship methods are generated in this framework.

There are several different relationships that datapoints can have with each other. The most common of these relationships are:

belongs_to
has_one
has_many
has_and_belongs_to_many

This post will assume you have a basic knowledge of these relationships.

Most of us are familiar with these methods in some way shape or form in Rails. But what really happens under the hood when we add these lines into our Activerecord classes?

When Rails is booted up, ActiveRecord Models are loaded into memory and a little metaprogramming magic begins. When a Model contains one of the above methods, a series of methods are fired to construct methods that address these relationships. Consider we have two models, User and Post.

class User < ActiveRecord::Base
  has_many :posts
end

class Post < ActiveRecord::Base
  belongs_to :post
end

The main way we manipulate the relationship between these two models is using the accessor methods that are given to us by these models. These accessor methods are built in Rails through a chain of events - let’s look at some of the methods in that call stack.

We start in the ActiveRecord::Associations::Builder::Association class, a parent class that is inherited by CollectionAssociation (for has_many and has_and_belongs_to_many) and SingularAssociation (for belongs_to and has_one). It contains a method self.build. The source code is below:

def self.build(model, name, scope, options, &block)
  if model.dangerous_attribute_method?(name)
    raise ArgumentError, "You tried to define an association named #{name} on the model #{model.name}, but " \
                         "this will conflict with a method #{name} already defined by Active Record. " \
                         "Please choose a different association name."
  end

  extension = define_extensions model, name, &block
  reflection = create_reflection model, name, scope, options, extension
  define_accessors model, reflection
  define_callbacks model, reflection
  define_validations model, reflection
  reflection
end

So, a lot is going on here - it’s ensuring the method names are okay, defining some things, general rails shennanigans. Let’s focus on define_accessors. A reflection in Rails is an object that allows the system to determine what type of associations that object should have (it’s not a huge focus for the purpose of this post). This will generate things like post.user and user.posts=. Let’s check out that method, also in this Association class:

def self.define_accessors(model, reflection)
  mixin = model.generated_association_methods
  name = reflection.name
  define_readers(mixin, name)
  define_writers(mixin, name)
end

As we can see, we break down the defining of readers and writers here. These methods look like this (we’re still in the same class):

def self.define_readers(mixin, name)
  mixin.class_eval <<-CODE, __FILE__ , __LINE__ + 1
    def #{name}(*args)
      association(:#{name}).reader(*args)
    end
  CODE
end

def self.define_writers(mixin, name)
  mixin.class_eval <<-CODE, __FILE__ , __LINE__ + 1
    def #{name}=(value)
      association(:#{name}).writer(value)
    end
  CODE
end

A little bit of metaprogramming here - these methods define a new method on the class in question. The reader method will return either a CollectionProxy which contains data about a set of objects (for non-singular associations), or the object itself. The writer method that is being called actually delegates to a replace method, as seen below:

def writer(records)
  replace(records)
end

Now, the replace method and the rest of the call stack gets pretty complicated from here (and isn’t the purpose of this post), but just know that the replace method eventually delivers a query to your database to update ids and reflect the proposed changes you’re making in the database.

At its core, it’s some relatively simple metaprogramming which is being used to create all of these methods. Of course, the inner details can get quite complicated (what does a Reflection do, exactly? how are these things differently handled between singular and collection Associtations? ), but the main idea of this metaprogramming is easy to follow.

Hope this clears up a little bit of the mystery from the magic of Rails!

Custom Buildpacks in Heroku

Jake Faris — Sun, 06 Dec 2015 00:00:09 +0000

So picture this - you’re building a web app and hosting it on Heroku. The frameworks and tech stack you’re using, however, has some configuration problems and don’t quite push to Heroku in the way that you would like - maybe your repo doesn’t quite have the structure you need on site, something that was abstracted away locally by something or other. What should you do?

Enter: Custom Heroku Buildpacks!

Heroku allows for applications to take any buildpack that the admin specifies and runs that buildpack before deployment. To add a new buildpack to your app, simply run

heroku buildpacks:set https://github.com/some/buildpack.git -a myapp

in the terminal and you should be good to go.

So what do these buildpacks look like, exactly?

According to the Heroku docs, buildpacks contain three main files which are executed at runtime:

bin/detect: Determines whether to apply this buildpack to an app.
bin/compile: Used to perform the transformation steps on the app.
bin/release: Provides metadata back to the runtime.

`bin/detect`

The detect file will determine if the application this buildpack is mounted on is suitable for the buildpack itself. It’s essentially a safeguard to ensure that you’re working within the right frameworks for whatever your buildpack is about to do.

It receives one argument, BUILD_DIR, which is the root of the app itself. From there detect should analyze the file structure to see if it is compatible (for instance, if you need it to be a Rails app, make sure there’s a Gemfile and config.ru).

`bin/compile`

This file actually executes what you set out to do with this buildpack. This can be whatever you want!

In addition to BUILD_DIR, it also receives a CACHE_DIR argument, which represents a directory that the buildpack can use to cache files between builds.

Additionally, it receives a third argument, ENV_DIR, which is a file directory that contains all of the environment variables provided from the Heroku setup. In this directory, the file name is the variable name, and the file contents are the variable’s value.

`bin/release`

An optional file to be run, this program will return a list of addons and default_process_types for the application to use, in YAML format. addons is only executed on the first deployment. If you’re trying to add additional technologies in the app based on the buildpack, this is a good place to do that.

With this information, it’s easy to do a variety of things before deployment to Heroku. A variety of custom buildpacks are listed on Heroku’s website here, but go ahead and make your own if nothing quite fits your use case!