So Much to Learn, So Little Time

My birthday is coming up; looking back on what I learned about looking forward on what I want to learn, I noticed a pattern. Each year I spend revolving around the sun tends to have a pattern of what I learn. Maybe it was distributed systems and how easy it is to screw up in 2007-2008. Or APIs from 2012-2013.

There is too much to learn with far too few years to learn. The only way I’ve been able to be ok with this fact is to schedule my learning, learn by doing, and then reading the books on the subject. Note: read the books, not the blogs, is a technique by Chris Oakman and it’s helped me dive into the theory behind the tech. The tech changes, but the theory stays the same.

That said, this is probably a very hip-javascript heavy post. If you’re suffering from JavaScript fatigue, this may or may not help.

Scenes From Seven Cohorts

Two years ago, my first cohort graduated at The Iron Yard in Houston, Texas. 12 students received their diplomas and started their journey, their career, and their new life.

Five cohorts followed; today my seventh, and final, immersive cohort will present their final projects and begin the next phase of their live. I look back and remember:

Explaining Elixir Pipes Through the Magic of Turduckens

One of the cooler features of Elixir (and other functional languages) is the Pipe operator |>. It certainly makes code easier to read, but it’s a bit difficult to grep for the first time.

Let’s use the Turducken to explain it. For the uninitiated, A Turducken is a turkey stuffed with a duck which is itself stuffed in a chicken.

When (Fake) Googlebots Attack Your Rails App

We’ve all scraped a site or two (rite?) but what do you do when bad actors start taking up a non-trivial amount of resources on your app? Further, what if bad actors are masking their user agent to appear as though they were googlebot?

Writing Like Actually Getting Words Onto Paper

Writing is a series of small burst of rushing water, a thousand words pouring out of me in a very short period of time.

Writing is day dreaming, when no words come at all. The rushing water has stopped, the creek dry and crackling.

Writing is using your own voice and avoiding sounding important or intellectual. Writing is real.

Writing happens in the morning for me. I imagine my brain is still excited about the day in the morning, and like sushi, degrades the further it gets from sleep. I should look into napping. You should find the part of the day you are most creative, and write then. AB test it. Trial and error.


Many developers spend days, weeks even, on getting the correct Tool. I have used Pages,, IA Writer, Scrivener, and more authoring tools I can remember. They do not do the work for you, and in general do not make anything easier.

You can also spend days, and weeks, on your toolkit to transfer your words into an ebook format. Or, your site’s marketing website.

But here’s the truth: you are ignoring the part that matters: getting words out of your brain and onto ‘paper’. Stop with the tools, and just write. Use softcover or leanpub - both will create a page for you so you can focus on the writing.

Fiddling with tools instead of writing is wankery distraction.

Timeline of a chapter

  • Day 1: write an outline of an article or chapter
  • Day 2: fill in the outline
  • Day 3: edit the first chapter
  • Day 7+: revisit and read with a clean mind. I’ll find that I find I didn’t say all I thought I had said. Or, I’ll find typos clear as day that my mind wouldn’t let me see the previous week.

I’m currently putting my ideas on writing into action creating Tex Mex Consulting. Some of my favorite articles:

Why I Created Tex Mex Consulting

Employees don’t make enough money. You’re not treated fairly, are not respected, and have to put up with a lot of crap.

Most software developers can learn a hellaton from freelancing and consulting; at the very least you can learn what you’re worth. And it’s not $75,000 a year with free soda and 1% equity.

I’ve spent 6 years and many thousands of dollars in mistakes, masterclasses, and good old sweat equity in created a workflow system for expert software consulting.

I want to give you a path to consulting; a path to go from Employee to Freelancer to Consultant. A path to freedom, more money, and more respect.

The basic ethos of the book:

Freelancers are hired by companies. Consultants choose their clients carefully.

Want to try out some the techniques in my system? I’ve created a 30 day free email course on Professional Freelancing – try it out below.

Check out the system for Professional Freelancing at Tex Mex Consulting.

1000 Day Love Story With Ember

Like most love stories, my love affair with Ember took time to blossom. I first saw Ember in 2011, had some fun, and planned to look at it once the API solidified.

In that time, pre-1.0, Ember’s API would change constantly. Most people saw this as a flaw, after all, it meant that documentation, blogs, and stack overflow searches would frequently reference older versions. The router saw the biggest changes, frequently.

The benefit of this – Ember got the API right. Once it hit 1.0, the API was on point; and with the correct API in place, Ember keeps getting better. Ember is able to make changes under the hood, applying React style rendering, performance enhancements, and generally get better and better over time.

My experience with ember is generally along the lines of Deleting more code than I add; Ember tends to add what I need overtime and I use that instead of my code.

Told over a series of many (perhaps too many) tweets, here is the story of my transition from Ember to Angular to Ember.

Getting Websockets, CarrierWave, and Fog to Play Nicely Together

Getting Websockets, CarrierWave, and Fog to play nicely together

Alternate title: “Dancing with Dragons, or, how I got screwed by ActiveRecord Callbacks yet again.”

I’ve been working on the following scenario:

  • 2 different people have an ember app open
  • One of them adds a new record to the Rails app
  • I want other-person’s ember to refresh with that new record instantaniously-ish

The setup

class Photo < ActiveRecord::Base
  mount_uploader :image, ImageUploader

  after_create do

Fairly simple, but here’s what’s going on:

  • When our photo is created, carrier wave will resize the image, upload it to S3
  • We will send the JSON through Pusher to any clients subscribed to the new_photo channel. The JSON we’re sending is the same JSON that ActiveModelSerializer will use in the API. WIN.

But then, melancholy.

The JSON that comes through has something rather odd for large_image_url - it’s a local path to the /tmp/upload directory, which absolutely does not work. :/

    "id": "399ca80efb2bd65e7254f299adfe278a",
    "name": "thumbythumbythumby",
    "large_image_url": "/uploads/tmp/1425583084-37430-8620/large_thumbnail.jpg",
    "thumb_photo_url": "/uploads/tmp/1425583084-37430-8620/thumb_thumbnail.jpg"

Basically, when Pusher is sending, the image has not been stored up to S3. We want to do Pusher later, after fog does it’s thing.

Callbacks are run in this order:


So, after_create is occurring before after_save. Let’s switch that up and our problems should be solved:

class Photo < ActiveRecord::Base
  mount_uploader :image, ImageUploader

  after_save on: :create do

Result: Same thing. huh?

To see the order in which callbacks are run, we can do this:

That will show the name of the callbacks being called, and will look something like:

[70220584822820, :remove_previously_stored_photo, :store_photo!, :write_photo_identifier]

That 70220584822820 is our block callback. And it’s first. Why is it first? Can we get it to go last? Callbacks are run in a last-first order. Further, changing it to something like the following also doesn’t work.

class Photo < ActiveRecord::Base
  mount_uploader :image, ImageUploader

  after_save on: :create do

So then what the hell works?

We need to store the image before we get the attributes. So, let’s add that store_image! callback we saw in the list of callbacks. This will result in store_image! being called twice, but it won’t actually store the image twice — the second call is basically a no-op.

class Photo < ActiveRecord::Base
  mount_uploader :image, ImageUploader

  after_save on: :create do
    store_image! ## It’s this. this is carrierwave saving the image.
    "id": "399ca80efb2bd65e7254f299adfe278a",
    "name": "thumbythumbythumby",
    "large_image_url": "",
    "thumb_photo_url": ""




It reminds me of a story about a younger Rails developer warning other Rails devs about the dangers of Callbacks, and how they tend to screw you over.

Rails and the Next 5 Years

After a few flirtatious encounters with Ruby, I left .NET in 2009. I was looking for something better, something where I didn’t use an IDE, something where I didn’t feel like I was fighting the entire culture, and a place I could be happy being a devloper again.

I found Rails. I found open source. I found Ruby. And I found myself.

Ruby/Rails to me: a community where people help each other learn, full of interesting and fun challenges, and a desire to learn the entire stack from UNIX to CSS.

Fast forward 5 years; I’ve been thinking about what the next 5 years will look like, for both me specifically and for web/mobile application in general.

It’s fairly clear to me that most medium to large’ish apps won’t be a single Rails app with 100 controllers. That dog has tried to hunt, and well… that dog won’t hunt. OneLargeRailsApp is not the future.

Rails isn’t going away. I will still use it for prototyping and for applications where expressiveness is key (billing code and administration of data are two examples). Rails will become part of the puzzle, not the whole thing. I don’t envision anything being the entire puzzle anymore. Too much awesome tech which each do one thing super awesomely.

Prediction: apps in this half-decade will be split up

  • Many Apps (iOS/android, some rails, some Ember, some R, some Go)
  • Depending on your worldview, gsub/Go/Node|Elixir/

I don’t anticipate quote-unquote leaving Rails. There’s no need to leave like there was a need for me to flee .NET. Instead, the communities will merge together under an open-source umbrella. I doubt there will be one big huge community in which you do ALL of your development.

The future, in my opinion, is many languages. Many communities. Many meetups.

Bring on the future!

(and my hoverboards. and jetpacks. and flying cars)

Ember-cli: Getting Started With the Awesome

ember-cli 1 is a command line application that creates a separate project for your ember project. It is crafted by the Ember core team and extended by the Ember community . So: your backend API will be in 1 app/repo, and ember in a seperate one. This is a good thing for all sorts of reasons, but mostly: Your Front End App has grown up.

What does ember-cli give you over other-tool.js?

  • ember-cli includes the ability to build SCSS, Coffee-Script, include bower assets, and test your code. It will generate ember components for you in the same style as “rails generate model Customer”
  • ember-cli can run all of your front-end tests. Fastly. Without hair-pulling.
  • ember-cli can build the code for you (into a dist) folder, which can be deployed, or copied to a Rails public folder.
  • ember-cli can also be deployed directly to Heroku, or used to build Cordova applications on iOS and Android.

** Tl;dr ember-cli is the awesome **

However: There is a confusion generating getting-started period where you might be confused by some of the conventions. (confession: I had to fiddle around to figure stuff out. Hopefully, you dear reader won’t have to do so).

ES6 Modules

If you’ve used ember before in Rails or Lineman3, moving to ember-cli could confuse you a bit — ember-cli uses ES6 modules, which you may have never seen before.

Prior to ember-cli, you may have declared your ember data models in this fashion:

** app/js/models/user.js **

App.User = DS.Model.extend({
  first_name: DS.attr('string'),
  last_name: DS.attr('string'),
  email: DS.attr('string'),
  admin: DS.attr('boolean')

Things to notice: in this file, we assume that Ember and Ember Data have already been loaded, and are in the global namespace ready for use.

ES6, on the other hand, requires you to be explicit about what you want to use — you import namespaces, name them what you want, and then use them.

** app/models/recipe.js **

import DS from 'ember-data';

export default DS.Model.extend({
  permalink: DS.attr('string'),
  name: DS.attr('string'),
  ingredients: DS.attr('string'),
  instructions: DS.attr('string'),
  description: DS.attr('string')

We import the “DS” from ember-data, and it exports the object we define. What we notice:

  1. We never say this is a “Recipe”. Instead, the ember-cli “Resolver” knows that this is from recipe.js and therefor is a “Recipe”.
  2. The “export default” is important. Without it, nothing happens.
  3. It’s extremely important to name files correctly. Extreme Extremeness.

Getting Sass Working

Coming from Rails, the first thing I want to do is work with Sass. I found a couple of loops you had to jump through to get your .scss working again.

Step 1: install brocolli-sass and broccoli-merge-trees

npm install --save-dev broccoli-sass
npm install --save-dev broccoli-merge-trees

If you’re new to npm, the “–save-dev” means “use only in this project”.

Step 2: edit Brocfile.js

Make it look like this:

/* global require, module */

var EmberApp = require('ember-cli/lib/broccoli/ember-app');

var app = new EmberApp();

var compileSass = require('broccoli-sass');
var mergeTrees = require('broccoli-merge-trees');

var sassSources = [

var appCss = compileSass( sassSources , 'app.scss', 'assets/app.css');
var appAndCustomDependencies = mergeTrees([app.toTree(),appCss], {
  overwrite: true
module.exports = appAndCustomDependencies;

This will create an asset-pipeline of sorts for you. Broccoli will compile any sass files in app/styles and vendor/css, and compile app.scss into “assets/app.css”.

Generally, this is what you want.

Step 3: Customize your sass

Move app/styles/app.css to app/styles/app.scss. You can now use scss all you like:

body {
  color: lighten(#222222, 20%);

(We’ll use Bourbon in a future article)

Creating Routes

ember generate route Index

This will create app/routes/index.js (and create “routes” directory for you, cool). We’ll change the default to the standard ember starter:

import Ember from 'ember';

export default Ember.Route.extend({
  model: function() {
    return ["red", "yellow", "green"];

And we’ll create a template to show.

ember generate template index

This created app/templates/index.hbs. We’ll change its contents to:

Running Locally

ember server

If things are good to go, you’ll see the colors listed out on the screen. WOAH, the power.

Building for Deploying

ember build

This creates a “dist” directory with “index.html” and other static assets. We can deploy this to S3, or anywhere else. TOTES AWESOME.

Deploying to Heroku

If we run into CORS problems, or generally want to use Heroku, there’s a build pack for maximum awesome.

heroku create --buildpack
git push heroku master

At this point, you have an ember app, build with ember-cli, hosted on Heroku.

We can set an API Proxy to get around CORS problems:

heroku config:set API_URL=

If you want to checkout a repo where this is hooked up 3

Where to go from here?

  • Check out ember-cli-cordova
  • Watch Jake from Poetic Systems’s Houston.JS talk on using this to build mobile apps
  • Add Ember-Data and use the ember-cli-buildpack’s API proxy 5
  • Have serious FUN.

Next Articles in this series

  1. How to Bourbon/Neat/Bitters your ember-cli
  2. How to use environment variables in ember-cli and on heroku
  3. How to customize the JSON you receive from someone’s API and play nicely with ember-data