Most companies don’t have a single stack anymore. You might have a few projects that use Elixir, and a few that use Rails (even those might have various versions of Rails). Sometimes my changes in a Rails project require me to run an Elixir service on my machine, but I have no clue how to set that up.

Take migrations as an example. Rails has you run ./bin/rails db:migrate and in Elixir I would do mix ecto.migrate. Both commands do the same thing, but have different syntaxes.

What I like is commonalities. My process for getting any project up and running should be the same, no matter which stack it’s on. The steps for setting up a repo should also be easy to understand and easy to learn from if I care to peek under the hood.

I ended up going with setting up a Makefile in each project at Chime. In the above example, I should just be able to make migrate in either project, and presto! My project does the right thing.

But… Why make?

I know, I know! Make is that thing you used forever ago to coordinate how your C++ files compiled to avoid linking errors. Or at least, I think that’s what I used to use them for. We’re going to use them as a glorified command line execution system — something far more benign.

Make is available in pretty much every linux environment. It’s straight forward, and it’s easy to debug. It doesn’t have a ton of bells and whistles, but that means it will always just work.

When a developer clones a new repo at Chime, they can take a quick glance at the Makefile and know what has to happen (also, keeping README’s up to date is key). I can run make build, then make setup_db followed by a make test and it won’t matter if it’s Ruby, Elixir, or some other crazy stack.

The best part? You can actually group make commands into similar files and then include them in your main Makefile. We use this to DRY up common make commands that relate to our mysql instance, as well as other things like bringing up and down docker-compose environments. You can do that by adding this to your Makefile:

include Makefile.common

You could have things like Makefile.rails and Makefile.phoenix to dry things up even more.

Tips & Tricks

Make it self-documenting! One of my favorite parts about this, is adding the following to my top level common Makefile:

This will pull any comments that start with #: out and display them nicely for anyone who’s looking at what’s available.

You can also use environment variables to pass parameters. To see a full example, here’s one that I have set up for a personal project of mine:

The end result of running make help looks like this:

Do you have some tips or tricks you can share? I’d love to hear them!

Unifying Projects with Makefiles was originally published in Breaking the Bank on Medium, where people are continuing the conversation by highlighting and responding to this story.

Switching to Fetch in a React with Redux Application

This tutorial demos switching to Fetch while working with React and
Redux.

Here at Chime we use ReactOnRails and have found a transition to using Fetch to be a big win. I’d been working with Ajax previously. I’ll show you how we did it.

Let’s create an Errors Reducer that propagates helpful error messages from your backend up to your React components. Then errors can be rendered to the user. We can use this to improve our form handling and CRUD operations.

Our example Actions look like this:

And our matching Errors Reducer looks like this:

This errors reducer pattern can be used with Fetch, Ajax, Axios, raw XMLHttpRequest or any number of other data retrieval tools.

We want to use this reducer with Fetch, so we’ll need to install and save the ‘fetch’ npm package. From your command line:

npm install fetch --save

Honestly, any of those tools will work fine, so why Fetch?

1. Fetch has great MDN documentation.
2. If you are switching off of jQuery and want a substitute for Ajax, Fetch is a good standard to adopt.
3. GitHub has open-sourced a nice polyfill for Fetch that supports older browsers.
4. If you work with modern JavaScript promises all the time, Fetch will feel comfortable and familiar.
5. If you don’t, then Fetch will make you familiar with modern promise handling!

Get your Linter ready

We will be working with JSON rendered by your backend and transforming it for use in your frontend. This means the variable names received by Fetch may trigger linter warnings since they won’t necessarily be formatted to follow JavaScript’s camelcase convention.

If you are using ESLint (and you really should be), you’ll want to include this line at the top of each of your Redux Action Creator files:

/* eslint-disable no-undef, camelcase */

If your backend is written in Node or is already serving up data that is CamelCased, you won’t need this line. (In our example, we technically don’t need this either since the one word variable,item, looks the same in both CamelCase and snake_case. I doubt you’ll be restricted to one word variables in practice though, so this is going to be helpful as you build more Redux Action Creators.)

Use the Action Creators in a Fetch Promise Chain

We set up our reducer, now let’s use it!

In our demo, we will include a few lines of configuration for ReactOnRails. You can substitute this with the corresponding requirements from any back-end server you are using in your app.

We import ReactOnRails at the top of the file to handle CSRF security in our requests to the server:

import ReactOnRails from ‘react-on-rails’;

Then we import our error action creators that we made above. This assumes they are in the same local folder as our new file:

import { receiveErrors, clearErrors } from ‘./errorActionCreators’;

As a best practice, always prefer constants over strings in Action Creators. This mitigates against silently failing actions in your Reducers. Mistyped strings are ignored by the Reducer, whereas an undefined constant will raise an appropriate error. This is a major win for trouble-shooting.

export const GET_ITEM = 'GET_ITEM';
export const DELETE_ITEM = 'DELETE_ITEM';
export const RECEIVE_ITEMS = 'RECEIVE_ITEMS';

You will use these constants when creating your synchronous actions:

export const getAdminUser = text => ({
  type: GET_ITEM,
  text,
});

export const deleteAdminUser = text => ({
  type: DELETE_ITEM,
  text,
});

export const receiveAdmins = payload => ({
  type: RECEIVE_ITEMS,
  payload,
});

You can use the following two functions to handle all of your promises.

1) If you are familiar with AJAX but not Fetch or general promise handling, this is the biggest change!

export const status = response => {
 if (response.status >= 200 && response.status < 300) {
 return Promise.resolve(response);
 } else {
 return Promise.reject(response);
 }
};

2) Meanwhile, this one-liner is pretty handy, you will do this a lot:

export const unwrap = response => response.json();

These will be used in all of your Promise Chaining to DRY out your Action Creators. Here’s what it looks like in action:

export const updateItem = (item) => {
 const url = `/api/items/${item.id}`;
 const body = JSON.stringify({ item });
 return (dispatch) => {
   fetch(url, {
     credentials: ‘same-origin’,
     method: ‘PATCH’,
     body,
     headers,
   })
   .then(status)
   .then(unwrap)
   .then(responseJSON => dispatch(receiveItem(responseJSON)))
   .catch(unwrap)
   .then(responseJSON => dispatch(receiveErrors(responseJSON)));
 };
};

Similarly, here’s the action creator for your show route (to get all items):

export const showItems = () => {
  const url = '/api/items/';
  return (dispatch) => {
    fetch(url, { 
      credentials: 'same-origin', 
      method: 'GET', 
      headers 
    })
    .then(status)
    .then(unwrap)
    .then(responseJSON => dispatch(receiveItems(responseJSON)))
    .catch(unwrap)
    .then(errors => dispatch(receiveErrors(errors)));
  };
};

We’re using a lot of ES6 implicit object de-structuring there. One of the variables you will have to fill out for it to work properly is headers.

If you are using ReactOnRails, you can configure your headers as follows. Otherwise, you will want to set up headers in the expected format for your backend. You can put this in a utilities folder and make it accessible to all of your different Action Creators.

export const headers = {
 ‘X-Requested-With’: ‘XMLHttpRequest’,
 ‘X-CSRF-Token’: ReactOnRails.authenticityToken(),
 ‘Content-Type’: ‘application/json’,
 Accept: ‘application/json’,
};

You’ll want to set your Fetch headers properly for security reasons, especially for CSRF protection.

Now we’ve made Fetch happen

Did you find this useful? Need help with something else? Have a better way to do it? Please tell me all about it in the comments.

If making code reusable like this gives you a thrill of satisfaction, check out career opportunities at Chime.

Making Fetch Happen: was originally published in Breaking the Bank on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’ll cover the following topics, feel free to jump around to the bits that speak to you:

1. Background
2. Initial Proposal
3. Prep Work
4. Day-of
5. What I Learned

In late 2017, I found myself in a position to look for a new job, which meant asking myself what I wanted. Did I want to keep pushing down the Python route? Maybe go back to Ruby? I had been playing around with React and thought it was pretty amazing, but I’ve always been more of a back end kind of person.

I ended up focusing on Ruby because I felt I had a strong grasp on it and generally liked working in it. About two weeks into the job search, I had a ping from a recruiter asking if I would be interested in a job that was using Elixir. At first I thought, “No way, I’m wanting to get back into Ruby and don’t need to get side tracked. Besides, I tried Go, and it was ok, but not my jam.”

Fast-forward about two more weeks and I’m trying to do some of my interview take-home questions in Elixir in an attempt to force myself to learn it. Functional programming? Heck yes. Immutable data? Be still my beating heart. Parallel processing and async I/O? It was like falling in love all over again. There was just one tiny hiccup: I accepted a job at Chime where the back end is all Ruby on Rails.

Luckily I had already talked about Elixir in my interview, and the overall engineering vibe at Chime is one of “if it makes sense and we can present a business case for it, let’s try it!” Before I could really push any kind of Elixir-based project, I needed to get people excited and interested in learning a new language and framework.

Making the Initial Proposal

At past jobs, I’ve participated in learning groups when a adopting a new technology or framework. These can work well, but one large problem is that the “extra” work of learning usually gets offloaded to non-work hours. If Chime was going to be serious about trying out this new tech, I wanted us to put valuable work hours toward learning Elixir.

I wrote up a quick one-page document to lay out the goals and budget requirements to set up a one-day off-site Elixir focused hackathon. I noted that the off-site part, while not necessary, was high priority for me. Pulling engineers out of the day-to-day would allow for a more focused space for learning and building. I can also now admit that getting the CTO to OK some budget for a breather room was also a bit of a litmus test on how seriously we were considering Elixir. I made sure to find a range of options for the breather to fit different budgets. If you will have more than 6 people, I would definitely suggest finding a space that has at least two physical rooms so that groups can collaborate without interfering with each other.

For the hackathon to be successful, I wanted other engineers to see where functional programming could be powerful. They should walk away from the day with a sense of accomplishment for having pushed out production-capable code. This meant that picking projects that would benefit from the underlying differences of Elixir was crucial to the hackathon’s success.

It took all of about 10 minutes for the CTO and VP of Eng to say “very yes” to the hackathon idea. I was pretty stoked, but now I also had to deliver on my ambitious plan.

Hackathon Prep Work

I really wanted to focus on getting as much learning done as possible. I identified the following as the enablers of that:

1. Focus only on Elixir and Phoenix work.
2. Remove as many setup issues as possible.
3. Pick the right projects.

I encouraged people to do as much prep work as they could in the weeks leading up to the event. This included everything from “here’s some good learning resources to pick up the syntax”, to “here’s a dockerized project that you can start playing with”. The goal was to remove as much of the language basics learning time as possible.

For the hackathon itself, I took each of the potential projects and set up repos a week ahead of time with all the necessary set up to hit the ground running. Each project had a working docker-compose environment and a README with instructions on how to get the project running locally. Having this ready early also helped reduce setup time during the hackathon.

Picking the right projects was the hardest task. The scope had to be small enough that people could work on it and make progress in one day, and it had to be something that would leverage the power of Elixir. There’s no secret recipe here. I had never run something like this before, and I am far from an expert in Elixir and Phoenix. For our next hackathon, I’ll have a better idea of what our team can accomplish in one day, and which internal projects would benefit from the tech.

The three projects I ended up going with:

• a GraphQL server
• a background script processor job
• common logging and stats tracking for Phoenix projects

Why GraphQL? Outside of wanting to experiment with it for our apps, we also see it as more of an aggregation framework for our transition to SOA. Since GraphQL allows us to define reducers, we can farm out pieces of a query to multiple back end services and aggregate the results without forcing the front end app to hit multiple services. We can leverage the async I/O strengths of Elixir - in this case for any of the downstream services that take a while to respond (a common experience when dealing with moving money).

The last piece of the puzzle was matching people with shared project interest and Elixir skill levels. We’d work in pairs, each pair having one developer with more Elixir experience. This would help facilitate more knowledge sharing and learning.

Day of Learnings

With the Hackathon day upon us, we settled into the Breather we rented near the office. I gave a quick overview of the projects along with the first few steps that I thought people should tackle (I put these into GitHub issues, but we ended up not really using them since... GitHub issues).

The rest of the day was split into three, two-hour focused working sessions:

• First kick off the projects
• Lunch break
• Second focus sesssion
• Show and Tell
• Final session to wrap things up

The two hour cadence seemed about right. More can get taxing when you’re learning something new, and less can prevent you from finishing anything.

One of my initial goals was to produce a production-ready piece of software in Elixir that we could deploy, or at least get to a deployable state with minimal follow-up effort. Turns out that was a lot more ambitious than I thought, and that ended up being my biggest frustration with the entire event. While we made some great progress on the projects, we did not have enough dev ops infrastructure in place to run any Elixir projects in any of our environments. We also didn’t get to a good deployable state for any of the three projects. Between initial language learning, and overall project context, everything I picked was far too ambitious to finish in one day.

In spite of those results, the day went well. The GraphQL service pulled a separate service in, validating that it could work as a proxy. Our background script jumped over the initial hurdles and had the inklings of some impressive performance improvements. We even have a Plug that we can use to do stats tracking for request durations in Phoenix projects.

Post-Event Learnings

I set up a quick type form feedback survey for people to fill out after the event to see what went well or didn’t go well. The interesting learnings:

1. Having a space with two rooms was great, but the lack of monitors and more collaborative work stations wasn’t great.
2. Being explicit about ensuring all participants get work time to prep would help reduce frustrations (mostly around me feeling like the time wasn’t used to its maximum potential).
3. Taking time away from the normal office was a big win.
4. Sharing what people accomplished and learned half way through was really helpful for everyone.
5. Finding the right project(s) is hard and you might not nail it.

I wanted to spark interest in Elixir and highlight what we could do with it. I think I definitely sparked interest, but fell short on really highlighting where Elixir and Ruby differ. Luckily, there’s enough interest that we’re continuing to have mini-hackathons to build on the work we started. We even have a few key services slated for development on our one year road map that will use Elixir, a direct result of the learnings from the off-site.

Do you want to run a hackathon for your company? Do you have other ideas around how to help a company transition to a new technology or framework? I’d love to hear what’s worked for you or your team.

Planning an Internal Elixir Hackathon was originally published in Breaking the Bank on Medium, where people are continuing the conversation by highlighting and responding to this story.