cleanup = !git fetch -p && git for-each-ref --format '%(refname:short) %(upstream:track)' | awk '$2 == \"[gone]\" {print $1}' | xargs -r git branch -D
up = !git pull --rebase --prune && git cleanup
upall = !"find . -type d -name .git -exec echo \\; -execdir pwd \\; -execdir git co -q main \\; -execdir bash -c \"git up | awk '/Already up/{next} {print}'\" \\;"

It worked fine and did what it was supposed to, but you may be able to guess the issue that bugged me from the beginning. It was fine at first, but we must be getting our repositories wet because they multiply like crazy.

➜ /usr/bin/time git upall
      150.53 real         9.55 user         9.31 sys

So my goal this weekend was to wave whatever rubber chicken I needed to in order to add some parallelism to that alias. I’ve tried and failed a couple of times to do this. With that in the back of my mind, I stalled and went to stack overflow to see what they had to say about it.

I found Managing many git repositories. Asked nearly 14 years ago. Oh boy, what kind of ancient tooling do we have in here? There were a lot of different suggestions, but I found one comment that was only a couple of years old promoting gita. Off to github fully expecting the last commit to be a couple of years ago, but much to my surprise it was 2 weeks ago. Bingo.

I blindly went back to the terminal…

➜ brew install gita
Warning: No available formula with the name "gita". Did you mean git, gitg or giza?

A few seconds of blank stares making sure I didn’t misspell it. It is only 4 letters, but ya never know. Back to the readme and a search for ‘installation’

pip3 install -U gita

Very audible sigh

I closed my eyes and followed along and was glad I did because it did exactly what I was needing.

It does require you to add a repository to its known list of repositories, but it has a gita add -a which will add all the repositories it finds under the current directory.

The super command was what I was looking for which will run a git command or alias against all of it’s managed repositories.

So I changed my alias to

upall = !"gita add -a . && gita super up"

➜ /usr/bin/time git upall
        3.65 real         4.70 user         5.19 sys

Give it a try if you have a bunch of repositories that you manage and want to supercharge your workflow.

So here’s what we’re talking about. The keys from a function like Object.keys return them in the same order as they were added.

Object.keys({
  'foo': null,
  'bar': null,
  'baz': null,
}).map(JSON.stringify);

// [ '"foo"', '"bar"', '"baz"' ]

So far, so good. That’s about as far as my knowledge of it went. If I would have continued to read that article or the spec I would have found out about the actual rules, and more specifically, about integer keys. The rules are…

1. First, the keys that are integer indices, in ascending numeric order.
2. Then, all other string keys, in the order in which they were added to the object.
3. Lastly, all symbol keys, in the order in which they were added to the object.

Let’s see that in action. Note that integer key means a Number integer or a String integer and keys are always returned as Strings.

Object.keys({
  3: null,
  '1': null,
  2: null
}).map(JSON.stringify);

// [ '"1"', '"2"', '"3"' ]

We’re passing 3, '1', 2 in and getting "1", "2", "3" out.

Rule number 1 is where I recently got bit by this. My task was to take a group of numbers and group them into the range defined by the keys of an object…i.e. make a bar chart.

Normally that object would like…

Object.keys({
  '1': 'green',
  '2': 'red',
  '3': 'blue',
});

// [ '1', '2', '3' ]

So I would get the keys from this object, loop through them placing the data points in the right bucket. The implementation of that isn’t important, just note that it relied on the keys being in numerical order.

They could also be decimal numbers like…

Object.keys({
  '1.5': 'green',
  '2.2': 'red',
  '3.9': 'blue',
});

// [ '1.5', '2.2', '3.9' ]

That also worked because the source data that the object was being built from was already sorted.

Can you guess where the bug is introduced?

Answer: mixed integers and decimals…

Object.keys({
  '1': 'green',
  '2.2': 'red',
  '3': 'blue',
});

// [ '1', '3', '2.2' ]

Funny how the computers always do what they were told to do. The 🔨 was to explicitly sort the keys before using them to group the data points.

Object.keys({
  '1': 'green',
  '2.2': 'red',
  '3': 'blue',
}).sort((a, b) => Number(a) - Number(b));

// [ '1', '2.2', '3' ]

Add the following to your ~/.gitconfig

[alias]
  squashemall = !git reset $(git merge-base master $(git rev-parse --abbrev-ref HEAD))

After running that hopefully you’re left with just your changes that you can then add, commit, and force push.

Details of what is going on with this command are here.

Remember that long running branches almost always end up bad. Avoid them at all costs.

So here it is.

Except that’s not really how the story went.

I first learned of Visible a few months ago in the same way I learn about every great, new service…through podcast ads. At the time it was a $40 flat fee for unlimited everything on Verizon’s network. Being a Verizon customer already that sounded pretty great since I was paying more than that per line. After further digging, I found that switching to Verizon’s unlimited plan got me down to around $35 per line so it ended up not being a better deal.

With the recent introduction of parties 🥳 that brought the per-line cost down to $25 and with 5 lines that was a savings of $50/month. I realize in hindsight that $50 probably isn’t enough to start messing with services that have been working fine for a decade and replace them with services that are 2 years old, but 🤷‍♂️. In my defense, though $50 a month would damn near covers my Busch Light bill.

So I’m off! But not before I check the twitters and read about some pretty nightmarish porting experiences. Reddit has some good ones too. I know 💡! I’ll just get a new number. Like a fresh 🌼 start. To their credit that actually did work and they did have a pretty decent deal on a new phone so that’s what I went with. The phone arrived on time, I put the sim in, tried to call the new number and 👎 there is a calling restriction on this line. A quick trip over to Visible customer service, aka twitter direct messages, got me going with the first suggestion in their troubleshooting script which was to turn airplane mode on and back off. I guess it resets the network or something, but I was up and going in a short period of time.

At this point, I have a working number on Visible which looking back on it all was a small miracle. While I was fine with a new number; it’s quite the opposite for my family (maybe one family member in particular). So here we go…I’m going to port all the numbers over to Visible. That leads into the first annoyance with Visible which is the lack of a family plan. Each number is its own account and its own bill. Luckily we have the gmail + trick so I can manage all of them from one email address.

The porting requirements were the phone number, account number, and account pin. All of these were copied from the Verizon site. Once it was requested it said it could take up to 48 hours…

🕛 🕒 🕕 🕘 🕛 🕒 🕕 🕙

In the hours leading up to 48 hour mark I asked for a status 3 times. Finally, after 3 days, one of the agents informed me that the porting process was never started because the account numbers were incorrect (remember that copy/paste thing from above).

With the twitter and reddit stories and now my own experience I had zero confidence that the porting process was going to work or even did work ever for that matter. Experiment over. I asked them for the account number and pin so I could port the new number back over to my Verizon line. Why not forget about the new Visible number and close the account? Because I had wanted a new number anyway and I had already notified everyone of the new number so I didn’t want to send out another “jk lol nm” message.

After a couple of “we hate to see you go” messages, I got the info I needed to port the number over to Verizon. I tried that and was greeted with a “We can’t do that. There is an existing installment agreement associated with the number”. 🤬 Back to Visible CS on twitter. They will have to escalate a case to get that number released which could take up to 24 hours. They tell me they marked it as critical so I’m not waiting too long 🙄. That was at 6:30 am on Thursday. I check my email early Friday morning and find a “Thank you and goodbye” email. They. Close. My. Fucking. Account. So now I have a phone with no service. Luckily I’m kind of an asshole so not a lot of people try to contact me and the chances are that they didn’t even update my contact info anyway.

No worries I’ll just port the number over to Verizon now. I head to their site and try the port again and it tells me I can’t do it until 24 hours from the past attempt. JFC. That was only a couple of hours away so I wait. I try the port at 6:30 on Friday morning and it seems to go through and says it can take up to 24 hours. All of these multi-hour ports are really weird considering, from what I’ve read, that Verizon actually owns Visible.

Afternoon comes and I’m starting to realize this ain’t happening. I contact Verizon customer service and they give me a number to the port authority (get it?) where I can check the status of an existing port. I do that and it tells me that it can’t be completed because the number is inactive on the previous carrier. The fuck? You know when a really good time is to tell folks about all of these porting errors is? Maybe when they make the damn request? Technology is hard. Anyway, I get a hold of a real person there and after several minutes of being on hold, she tells me…wait for it…the port can’t be completed because the number is inactive on the previous carrier. Thanks.

Back to twitter DM. Visible CS says you’ll have to reactive the account (ya know…the one they just god damned closed) in order to port into Verizon, but no worries if you don’t use the service they’ll be happy to refund the initial month. Yeah, right.

I just want this to be over so I give up and use my crusty old original number. But then I think 🤔 what if this number gets activated in the future and that port request is still out there. I would not be one bit surprised for that request to go through 2 months from now (that’s assuming that Visible stays in business for 2 more months). So I call the Verizon port people and get this really helpful (not in a sarcastic way) dude that cancels both the port request and the number change order that was on my account. He asks me about why I was changing numbers and I mention the Visible dumpster fire and surprise, surprise he’s heard about it. We crack open a couple of Busch Lights and catch up on old times…wait, that last part didn’t happen.

In summary, I’m out $25, but I did get a decent deal on a phone (hopefully no Visible juice leaked on it and cursed it). Some friends and family that changed my number now won’t be able to get in touch with me, but I have confidence that they’ll figure it out.

Visible…the good parts:

• $25/month service.
• Unlimited data on Verizon LTE

Visible…the bad parts:

• Porting is a 💩 show. It seems to be especially bad if you’re with Verizon already.
• Customer service is a joke. Don’t get me wrong, I really dislike calling any customer service and talking to real humans, but when you need to it’s pretty damn handy to have that available to you. I imagine customer service through Facebook or Twitter saves a ton of money, but the front line reps have no clue what’s going on. They have their scripts and anything outside of that is a ticket into specialists.
• Lack of a family/friends plan is annoying. Needing to create 5 separate accounts and get charged 5 separate times is a hassle. The party pay is so close to this why not just go all in so you’re not hooking up with strangers that may or may not stay on the service to save your $15?
• LTE only. Granted this probably wouldn’t hurt me 99.8% of the time, but if you go anywhere outside of the Verizon LTE network you have no service.
• Network flakiness. There are multiple complaints about needing to use the airplane mode trick daily to regain service. Although it is the Verizon network, it’s not quite the same as being a Verizon customer.
• Party pay actually working seems to be hit and miss. I didn’t get far enough to experience this, but you should check out the Reddit threads and consider the risk for yourself.

My recommendation? Stay away. Far away. And if this company was formed just to make Verizon look better then it worked (and a genius move).

The first thing you’ll need is is a vim plugin that can format code. I use neoformat.

Plugin 'sbdchd/neoformat'

Neoformat uses external tools to format a buffer based on the filetype. The list of supported filetypes is quite extensive. You’ll see for javascript these formatters are available.

js-beautify, prettier, prettydiff, clang-format, esformatter, prettier-eslint, eslint_d standard

In our case prettier and eslint_d are the ones that we’re interested in. I configure it to only look for those two so it’s not trying to use formatters that aren’t installed. Neoformat will run each formatter in sequence until one succeeds.

let g:neoformat_enabled_javascript = ['prettier', 'eslint_d']

We need the formatting tools installed locally so let’s do that…

npm i -D prettier eslint_d

eslint_d works the same as eslint would except it spins up a small server in the background to use on subsequent calls. This is needed because we don’t want our “format on save” taking almost a second.

Now it’s time to try it.

You can see that invoking :Neoformat will reformat the buffer with the default prettier config by removing the blank line and inserting the semicolon. The problem is when we have conflicting rules. Suppose we have the following eslint rule…

{
  "rules": {
    "quotes": ["error", "single"]
  }
}

The eslint rules say that it wants single quotes. I mentioned above that neoformat will only run until one formatter succeeds. We need to tell it to run all formatters with…

let g:neoformat_run_all_formatters = 1

Now if we run it again you’ll see that both prettier and eslint formatting is applied by the changing of double quotes to single quotes.

In order to format on save you can add an autocmd to run Neoformat on buffer pre write like so…

au BufWritePre *.js,*.ts,*.scss,*.rb Neoformat

Now every time you save both prettier and eslint formatters will run with eslint having the final say since it’s last in the neoformat list.

import {Component} from '@angular/core';
import {select} from '@angular-redux/store';
import {Observable} from 'rxjs/Observable';

@Component({
  selector: 'app-header',
  template: `
    <mat-toolbar fxLayoutAlign="end center">
      <a class="logo" fxFlex routerLink="/"><img src="logo.png"></a>
      <button *ngIf="isLoggedIn()" mat-icon-button [matMenuTriggerFor]="menu"><i class="fa fa-bars"></i></button>
    </mat-toolbar>

    <mat-menu #menu="matMenu">
      <button mat-menu-item routerLink="/logout" title="logout"><i class="fa fa-sign-out"></i> Logout</button>
    </mat-menu>
  `
})
export class AppHeaderComponent {
  private user: any;
  @select() private user$: Observable<any>;

  ngOnInit() {
    this.user$.subscribe(user => (this.user = user));
  }

  isLoggedIn() {
    return !!this.user;
  }
}

Supposing I want to test the two different states I might come up with a test like:

import {TestBed, ComponentFixture} from '@angular/core/testing';
import {By} from '@angular/platform-browser';
import {NgReduxTestingModule, MockNgRedux} from '@angular-redux/store/testing';
import {expect} from 'chai';

import {MaterialModule} from 'core/material.module';
import {AppHeaderComponent} from 'core/app-header.component';

describe('app-header', () => {
  let fixture: ComponentFixture<AppHeaderComponent>;

  beforeEach(() => {
    TestBed.configureTestingModule({
      imports: [MaterialModule, NgReduxTestingModule],
      declarations: [AppHeaderComponent]
    });

    fixture = TestBed.createComponent(AppHeaderComponent);
  });

  it('should show a menu button if logged in', () => {
    expectUserToBe({id: 'anything'});
    const button = findToolbarMenuButton();
    expect(button).to.have.length(1);
  });

  it('should not show a menu button if not logged in', () => {
    expectUserToBe(null);
    const button = findToolbarMenuButton();
    expect(button).to.have.length(0);
  });

  function findToolbarMenuButton() {
    fixture.detectChanges();
    return fixture.debugElement.queryAll(By.css('mat-toolbar button'));
  }

  function expectUserToBe(user: any) {
    const userSub = MockNgRedux.getSelectorStub(['user']);
    userSub.next(user);
    userSub.complete();
  }
});

How do I run that? I don’t want to use karma because I don’t want to deal with a real browser for CI reasons. I don’t want to use phantomjs for phantomjs reasons. There aren’t many headless chrome tutorials out there currently which is probably the future. I want to use mocha since that is what I use for all my non-browser tests.

Since we just need the DOM api jsdom should be good enough to get this working. It wasn’t quite a straight forward as “just using jsdom”, so here’s what I had to do.

For the mocha part, I use mocha-wepback to handle bundling the app and running the tests. Oh yeah, you need to be using webpack for this too.

We don’t need all of the bells and whistles of what a full frontend webpack config might have in it so I use a stripped down version of one. It looks like:

const path = require('path');
const nodeExternals = require('webpack-node-externals');

module.exports = {
  target: 'node',
  externals: [nodeExternals()],

  resolve: {
    extensions: ['.js', '.ts']
  },

  module: {
    rules: [
      {
        test: /\.ts$/,
        exclude: /node_modules/,
        loaders: [
          {
            loader: 'awesome-typescript-loader',
            options: {configFileName: path.resolve(__dirname, '../tsconfig.json')}
          },
          'angular2-template-loader'
        ]
      }
    ]
  }
};

So after installing mocha-webpack go ahead and try it

mocha-webpack \
  --webpack-config client/test/webpack.config.js \
  "client/test/unit/**/*.spec.ts"

Probably didn’t work. Angular needs a whole bunch of things to get the testing environment setup so we’ll need a way to do that. For reasons that I’m unable to recall I call this file mocha-shim.js. I think Angular ships with a jasmine shim so that’s maybe where I got it from. Anyway, it’s the content that matters. Here’s what it looks like:

const {JSDOM} = require('jsdom');
const document = new JSDOM('<!doctype html><html><body></body></html>');
const window = document.window;

global.HTMLElement = window.HTMLElement;
global.XMLHttpRequest = window.XMLHttpRequest;
global.document = window.document;
global.navigator = window.navigator;
global.Node = function() {};
global.Node.ELEMENT_NODE = 1;
global.Event = function() {};

require('core-js/es6');
require('core-js/es7/reflect');
require('zone.js/dist/zone');
require('zone.js/dist/long-stack-trace-zone');
require('zone.js/dist/proxy');
require('zone.js/dist/sync-test');
require('zone.js/dist/async-test');
require('zone.js/dist/fake-async-test');

const testing = require('@angular/core/testing');
const browser = require('@angular/platform-browser-dynamic/testing');

testing.TestBed.initTestEnvironment(
  browser.BrowserDynamicTestingModule,
  browser.platformBrowserDynamicTesting()
);

global.window = window;
global.CSS = null;

require('hammerjs');

You’ll see we’re setting up jsdom to get a browser environment and then setting a bunch of global things that you’d find in a real browser. Then we require some things to “make it work”. To be honest I copied most of this from that jasmine shim file so I couldn’t tell you for sure what everything is doing here. I will tell you that order is important in this file. There’s also a few lines at the bottom that you won’t need if you’re not using Material.

Now we need to require that file in our test runner. Don’t forget to install jsdom.

mocha-webpack \
  --webpack-config client/test/webpack.config.js \
  --require client/test/unit/helpers/mocha-shim.js \
  "client/test/unit/**/*.spec.ts"

That got us closer and we’d be done if there was only one test, but when it hits the second test we get:

Error: Cannot configure the test module when the test module has already been instantiated. Make sure you are not using `inject` before `TestBed.configureTestingModule`.

One other thing that the jasmine integrations do for us out of the box is reset the testing environment after each test. We’ll need to do that for mocha. I added a helper file that we can include in the test runner.

import {getTestBed} from '@angular/core/testing';

afterEach(() => {
  getTestBed().resetTestingModule();
});

Our final command looks like…

mocha-webpack \
  --webpack-config client/test/webpack.config.js \
  --require client/test/unit/helpers/mocha-shim.js \
  --include client/test/unit/helpers/spec-helper.js \
  "client/test/unit/**/*.spec.ts"

…and we finally get the green we’ve been looking for

  app-header
    ✓ should show a menu button if logged in
    ✓ should not show a menu button if not logged in

  2 passing (444ms)

On a recent episode of Adventures in Angular the panelists discuss some of the frustrations encountered in deploying an Angular app to a production environment. Heroku was mentioned as one of the hosting options which got my attention since that is what I’ve been neck deep in for the last year. While it’s not as simple as just a git push heroku master that you may have become used to in Rails, I’d argue that it’s not necessarily a bad thing. I would even say that it’s not the dumpster fire that it was described as. Maybe a small trash can fire, but totally manageable and sometimes pleasant.

This post is a documentation of my development, release, and deployment cycle on these types of projects. Your mileage may vary and if it doesn’t work for you I’m offering a 100% monetary refund. The complete demo app is available at darrinholst/heroku-nodejs-build-demo and the library that I extracted out of it is available at darrinholst/heroku-nodejs-build.

I had a few high level goals/requirements for this process:

• A Node backend optionally written in TypeScript because who knew that types were actually useful?
• Angular frontend just because that’s what I was used to at the time, but it can be adapted to any hip new framework.
• Hosted on Heroku. You give up a little control using a PaaS, but the speed at which you can prototype and transition to a production environment is nice.
• PostgreSQL for persistence. Storing and manipulating JSON in PostgreSQL has become pretty darn good and it’s a first class citizen in the Heroku ecosystem.
• A single command to build and test All The Things™. If this command runs without errors you have my 93% guarantee that it will work on any other machine that is aluminum and has a piece of fruit on it somewhere.
• A single release artifact that can be deployed to any environment. This means that you shouldn’t be manually changing any files to make it work in an environment.

The obligatory caveats:

• I don’t use the Angular CLI. This process was developed a few months before it was usable and it makes me a little nervous to be locked in to a tool like that. This process could be adapted to use the CLI if you just use it for component creation and bundling. See the next point for why I still wouldn’t use it for a development server.

• I don’t use webpack-dev-server. Not sure why, just never got into it. I also have never used a DVR (true story). Just a plain old boring web server that serves files. Maybe a little similar to how you’re going to be running in production.

  How do you get through the day without hawt module replacement? I manage. I just make sure all of my states are represented by a unique url and then do a good old fashioned browser refresh…like an animal. I do use the --watch option for webpack which makes incremental builds really fast. I also use nodemon for reloading the backend when there are changes and browsersync for the frontend.

• This was built out before Heroku announced support for containers. I may be Doing It Wrong™ now.

Building the backend

Let’s get this out of the way since there’s not a lot different going on from a normal express based Node backend that you may have seen before. The only novel thing I’ve added is TypeScript support. That means we now need a build process for our backend code. All of our building is handled by webpack. Love it or hate it I’ve found if you stay just far enough out of the weeds it’s not that bad.

This is the entire config for the backend side.

const path = require('path');
const nodeExternals = require('webpack-node-externals');

module.exports = {
  context: __dirname,
  target: 'node',
  devtool: 'inline-source-map',
  externals: [nodeExternals()],

  output: {
    path: path.join(__dirname, 'dist')
  },

  resolve: {
    extensions: ['.js', '.ts'],
    alias: {
      src: path.resolve(__dirname, 'src'),
      universal: path.resolve(__dirname, '../universal/src')
    }
  },

  module: {
    rules: [{
      test: /\.ts$/,
      exclude: /node_modules/,
      loaders: [
        {
          loader: 'awesome-typescript-loader',
          options: {silent: true, configFileName: path.resolve(__dirname, 'tsconfig.json')}
        }
      ]
    }
  ]}
};

Backend Apps with Webpack is a great post to learn what is going on here, but the tl;dr is JavasScript and/or TypeScript files go in and dist/index.js comes out ready to run with Node.

Other than that it’s a traditional Controller / Service / Repository stack.

Authentication is handled by jwt.

Config files are an important part of one of the requirements of having a single release artifact. Environment variables are the other player in staying away from manually changing files. See The Twelve-Factor App for why that’s important. We use node-config to handle that. An example of how that looks in practice is here. The take away is that anything that can change or is sensitive should not be hard coded in your source code.

I won’t go in to a lot of detail on persistence since it’s not the point of this post. Just know that we use pg-promise for the runtime part and db-migrate to handle schema management. Personally, I don’t have a bunch of schema management since I usually just opt for storing JSON documents and handling it on the frontend side. Also, I’m not a DBA.

Building the frontend

The frontend side is where things get a little more complex when it comes to webpack. I’ll spare you scrolling past the entire config, but it’s here if you want to follow along. I’m not a big fan of injecting css with javascript that webpack steers you towards so there’s some config in there to extract it out to it’s own file with extract-text-webpack-plugin. There’s also some junk in there to deal with development vs production builds since we usually don’t need minifying and external sourcemaps when we’re in development mode.

Just like the backend, (Java|Type)Script, Sass, and whatever else you can dream up goes in and bundled files come out. This time we’re outputing es5 for the browser and putting the output directly into the backend’s public directory so that whole file serving thing can work.

Follow your framework of choice guidelines to build out the frontend side. You’re on your own there, but for a small fee I can help you out with that.

When your code can’t decide if it’s backend or frontend

The only other source code related thing that I like to add is a universal directory that any code that can be used by both the backend and frontend can live. The example repo has a simple utility class, but in some of my real projects this is where I’ve put model objects. This is handy if you want to share validation code between backend and frontend or if you need those models for building anything on the backend (what’s a web app if it doesn’t have a pdf generator 🙄). You’ll find another webpack config in this directory, but that’s just used for running tests which we’ll get into later. Both the webpack.config.js and tsconfig.json in the frontend and backend reference this directory so it’s available either place. Magic!

mvn verify

Source code and build config is all taken care of, now let’s get back to the one command to verify everything. Verify comes from my dark days as a Java developer where there was one maven command (phase?) to compile, test, and package whatever you were delivering. I’ve always thought this was a good idea so it has tagged along with me through whatever language I’ve been working in (the name, not maven). Also, if somebody breaks the build you can snidely drop them a “Did you even run verify?”

scripts/verify is where we’ll stick this script because it’s a script and it’s named verify ¯\_(ツ)_/¯ . It goes something like…

#!/usr/bin/env bash

RESET=$'\e[0m'
BLUE=$'\e[1;34m'

printf "\n${BLUE}[%s] installing dependencies:${RESET}\n" "$(date +%T)" && \
yarn install && \
yarn run -s clean && \
yarn run -s lint && \
yarn run -s test:unit && \
yarn run -s test:integration && \
yarn run -s build:prod && \
yarn run -s test:e2e && \
printf "\n${BLUE}[%s] 🎉  👏  😻  ${RESET}\n\n" "$(date +%T)"

This is where you’ll define all the steps as to what verifying means to your particular project. Don’t forget the emojis…they’re important.

I’m using npm/yarn’s built in script running here. Check out scripty if you’ve tried this before, but ended up gouging yours eyes out after encoding shell scripts in JSON format.

Verify is at the minimum what you’ll do before you push your changes up. If it’s fast enough you’ll do it a lot more than that. I’ve found that the production webpack build and e2e tests are sufficiently slow enough to deter that and I usually just run the collection of tests that are going to be affected by what I’m working on.

Testing

This is as good of time as any to talk about testing. Ready? Do it.

I always start out with good intentions of building a Test Pyramid although sometimes my pyramid ends up looking more blocky than I want. There’s no better feeling than running thousands of tests in under a second. That warm, fuzzy feeling usually carries you all the way through waiting for your end to end tests to complete. (Who tf put those in again?). The confidence from e2e tests is pretty tempting.

As for tooling, I’ve settled on mocha-webpack for all the unit and integration testing and protractor + cucumber for end to end testing.

Testing is such a large and nuanced subject that I’ll just leave it at that. There are examples in the demo project. Feel free to hit me up with any questions.

Packaging

Also probably coming out of the good ol’ Java days is the single release artifact which was the .war. Having 50 different effing environments to deploy to a few years ago helped get it through my head that there was no sane or safe way of making manual changes after a deployment.

Up until this point everything…config, verify, etc…has been local to your project. This stuff is usually unique to the project, but I feel like the process of packaging, releasing, and deploying could be extracted to a set of generic steps and parameterized to specify what’s unique to your situation. Especially since we’re targeting Heroku here. The package that came out of this is available at darrinholst/heroku-nodejs-build.

Once installed you’ll have access to the package, release, and deploy scripts so your scripts section of package.json will need these additions:

    "package": "node_modules/heroku-nodejs-build/scripts/package",
    "release": "node_modules/heroku-nodejs-build/scripts/release",
    "deploy": "node_modules/heroku-nodejs-build/scripts/deploy"

Its only requirements is that you have Docker installed locally and a scripts/verify script exists. Docker is needed because we need the heroku/heroku image so that we can build a slug that the Heroku dyno manager knows what to do with. Docker is also nice in that the only dependency (besides node/npm) you needs is Docker itself. When setting this up in a CI environment I just tell it to run npm install && npm run package && npm run release.

Side note: before I extracted these scripts to an npm package I didn’t even need Node installed on CI.

The package script will run scripts/verify from earlier, but local to the docker container this time. If it runs successfully it will then tar everything up into a slug and put it in the build directory.

Releasing

Releasing is simply taking those artifacts built from package and storing them somewhere. That is what the release script does. It uses the GitHub Releases infrastructure for storage. This is where your deployable artifacts will live and this is where the deploy script will retrieve them from when deploying. It will also assign it a sequential version number and tag the repo with that so you have a complete trail of everything.

It will need a couple of environment variables set to tell it about which GitHub repo you’re working with and a token for authentication. See the README for details.

Deploying

Almost done, hang in there. The act of deploying is just choosing a release and telling the deploy script which Heroku app you want to deploy to. As mentioned earlier, I’m guessing the majority of people know how to deploy to Heroku by the ol’ git push heroku master. What that is doing is hooking into that push, detecting what type of project it is, choosing a buildpack, using that buildpack to create a slug, and then running that slug on a dyno. What our deploy script does is skip the building of the slug part since we already have a slug from the package step, downloads the release that we want from GitHub and uses that pre built slug to run on a dyno.

Why not just use Heroku’s Node buildpack? - because we have a non trivial build process for both our backend and frontend and it will likely timeout with anything other than a simple app. Also, you probably don’t want to be building your application as a part of your deploy. You already know that you have a good build since you ran all of your tests against it in the package step. Just deploy it [here] please. Although not as relevant now with the introduction of lockfiles with yarn and npm 5+, another benefit of doing it this way is that your complete dependency tree is locked in at package time. Even with lockfiles installing stuff from the scary internet at deploy time should still make you raise an eyebrow.

Drink a 🍺

You deserve it for making it this far. There are a few things that I didn’t cover like slack notifications, trimming the size of the slug, uploading sourcemaps, etc., but you’re smart you’ll figure it out. Drop in a comment, GitHub issue, or email with any suggestions.

It’s been a little over 3 years since I was struck down with the remote 🐛 and wrote down my thoughts on why it was the greatest thing evah. All of those things are still true: I still hate a forced commute, I still love having the option to be able to get my kids ready for school every morning, and I still value the health benefits over the traditional workplace lunch song and dance. I continue to hear more and more and read more and more about #remotelife and the benefits all these employees are realizing. Plus all the benefits the employers are realizing by having happy and content employees. The recent Stack Overflow Developer Survey shows remote options ranking #2 in valuable compensation/benefits. Another thing is still true even though it wasn’t mentioned in my first post: It’s harder than ever to find a remote friendly job.

🐔 or 🥚?

From my experience it is a chicken and egg game where an employer is not going to hire on a remote employee to a collocated team and a collocated team is not going to suddenly convert to remote (or even gradually convert…has the 1 day a week thing actually ever converted to full time IRL?). Given the huge talent gap that I keep hearing about in our industry there is a relatively minuscule percentage of opportunities where remote is an option (I mean…assuming I was searching for such things). For all the chatter I hear, I can’t help to think that we are just a very vocal minority. Maybe the survey suffers from the healthy user bias that we see in health studies. Are all you remote people slacking off so much that you have time to take a survey?

📡

On the “bringing the remote employee on to a collocated team” thing: You might think I can make that work. I’m a special ❄️. There’s a 99.9% chance you’re wrong on that. Don’t do it. It’s tempting. I know. I spent over a year as a satellite employee and it wasn’t my most joyous times as a developer. You are indeed a special ❄️, but not in the good way. A quote from the excellent blog post from Martin Fowler:

It’s very difficult to get satellite workers to be effective. With most people co-located, most communication will happen within the co-located team. I hardly ever hear of this model without the satellite person getting increasingly detached. If their work is very autonomous, that will reduce the problem. It is also wise to ensure satellite people make regular visits to the onsite team, at least a couple of times a month. But in most cases it seems best as a temporary measure.

😕

I do have to call out that it’s not always the people in charge of hiring that’s crushing all of our hopes and dreams. You’re probably not going to believe this, but there are actually people out there that enjoy going to an office and interacting with other humans all day. These people are called extroverts. For us introverts we can do this and often do a lot of times. It’s just that we don’t flourish in these situations. We all fall somewhere on the extrovert/introvert spectrum and it takes all kinds to be successful (think the Steve Jobs/Steve Wozniak combo). There is no wrong end to fall on, just keep that spectrum in mind when searching or hiring for a remote team. A lot more on this kind of stuff in Quiet. TL;DR? Watch this. Drawing from purely anecdotal evidence I believe there’s a strong correlation between introversion and remote.

🤷

So what do we do? Fiik. Do we wait a couple of generations for all the Cosmo Spacelys to retire? Good for our grandkids…not so good for us. Do we wait for the industry to have their epiphany and start seeking us? It worked for Agile 😏.

A lot of questions, not too many answers. It’s always a people problem is the only thing I can come up with.

You have a computational intense piece of javascript that is blocking browser interactions and animations and making you question why you even try building desktop class web applications. In my case I was trying to bring spreadsheet-like functionality into an application complete with formulas that referenced other formulas that referenced other formulas to the brink of infinity. I ended up needing to calculate tens of thousands of “cells” to get the data I needed. While these calculations can usually complete in under 500 milliseconds (on a fast browser/computer), a 1/2 second where the browser can’t do anything makes for a less than ideal experience. (Think back in the day when you tried to use async: false on your ajax requests because you couldn’t figure this callback stuff out. Was I the only one to try that? 🤔)

Solution #1 - setTimeout

In a server or native application we’d fire up a new thread to punt all of these computations to. The browser, for better or for worse, is all like #lolThreads. I was not familiar enough with web workers at the time to immediately reach for it so I improvised with the setTimeout trick. It went something like:

function calculate(years, callback) {
  processYear(years, {}, callback);
}

function processYear(years, results, callback) {
  if (years.length) {
    doAllTheThingsForYear(years.shift(), results);
    setTimeout(processYear, 0, years, results, callback);
  } else {
    callback(results);
  }
}

This actually worked quite well. It uses setTimeout to give up control after each year and lets the browser do all the things it needs to do. Although it works well it still felt a little hackish and assumes you have a good seam like processing over a number of years to give up control at. Also, for our tests we don’t want to just give away milliseconds like that because they add up over time.

Solution #2 - web worker

So I let the setTimeout hack ride for a week or two before I listened to this Adventures in Angular episode where they talked about web workers in Angular. They spent a good amount of time trying to come up with real world examples of where web workers would help. As I listened it occurred to me that I was sitting on one of the quintessential examples…a spreadsheet…so it made me give them another look.

When I realized that a web worker loaded an entirely separate script resource I almost gave up, but we’re using webpack so it’s just another entry, right? Kind of. My first attempt was exactly that which was adding another entry with all my web workin code. The problem with that is this other script runs in a completely different thread outside of your page so when it tries to load it has no idea about the webpack module loading. In other words, it didn’t work.

I thought to myself…surely someone has done this before with webpack so off to duckduckgo it was. It turns out that there is an example of how to do this in the webpack repo itself. Unfortunately, there’s not a lot of actual words in this example so you have to have both a good understanding of web workers and webpack to interpret it. The result is going to be a little anti-climatic since my solution looks a lot like the example, but here goes:

My first step was to make the calculator code where I had previously had the setTimeouts synchronous:

function calculate(years) {
  const results = {};
  years.forEach((year) => doAllTheThingsForYear(year, results));
  return results;
}

Simple enough, I like deleting code. Step 2 was to change the way I was calling the calculator since it moved from callback based to synchronous:

Before:

function serviceUsedByComponent($q) {
  return {
    calculate: function() {
      return $q(function(resolve) {
        calculatorService.calculate([2016, 2017, 2018], (results) => resolve(results));
      });
    }
  };
}

After:

function serviceUsedByComponent($q) {
  return {
    calculate: function() {
      return $q(function(resolve) {
        resolve(calculatorService.calculate([2016, 2017, 2018]));
      });
    }
  };
}

$q is Angular’s promise library. I had previously wrapped my interactions with the calculator in a promise in order to support the setTimeout solution.

At this point I’m back at square one with my component that needs the data using a synchronous call into the calculator.

[webpack enters stage right]

making the worker work

function serviceUsedByComponent($q) {
  const Worker = require('worker!../workers/calculator.worker');
  const worker = new Worker();

  return {
    calculate: function() {
      return $q(function(resolve) {
        worker.onmessage = (event) => resolve(event.data);
        worker.postMessage([2016, 2017, 2018]);
      });
    }
  };
}

Here we change it up a little to instantiate a new worker from the worker code loaded by webpack’s worker-loader so don’t forget to npm i worker-loader. Instead of calling the calculator directly we now post a message to the worker with our calculator input and resolve the promise with the data we get posted back to us from the worker. That’s it for calling the worker, now on to the worker itself which is a new file.

working on the worker

require('babel-polyfill');

const calculatorService = require('services/calculator.service');

onmessage = function(event) {
  postMessage(calculatorService.calculate(event.data));
};

The first line imports babels polyfills in case you use anything like Object.assign. Remember that this worker is loaded in it’s own thread/context so you don’t get anything from your regular webpack bundle. The rest of the file is receiving the message we posted from the main thread and posting back the results of the calculations.

webpack.config.js

The only thing I changed in my webpack config was taken from the example itself which sets the output filename for the worker:

worker: {
  output: {
    filename: 'calculator.worker.js',
    chunkFilename: '[id].calculator.worker.js'
  }
},

ship it

There you have it, webpack saves the day again.

errors

I left out error handling in my examples for brevity. I’m starting off with a nodejs style err property on my postback messages, but it appears you can get any errors back with an onerror callback - details here.

browsers

Browser support is all I needed it to be, ymmv - caniuse

performance

Performance wasn’t any better in my case and it may be slightly worse. I don’t think a user is going to be able to tell the difference between 500ms and 700ms. The more important part here was getting these computations off of the ui thread. I’m sending a fairly complex object which may be helped with Transferable Objects, but I’m calling it good for now. ¯\_(ツ)_/¯

lazy loading

An unforeseen benefit in our situation was that this provides lazy loading qualities. Our calculator is relatively big so it’s nice to not have that in the initial load.

Beyond my woes of ditching Progressive Enhancement for an SPA architecture, I think my biggest takeaway is: Users expect rich interfaces.

Dave Rupert talking about building a side product. Going the full stack rails way is exactly what I would have done (and have done) in the past to build an MVP. My feelings have been starting to shift to API first recently. I think this allows you to iterate more quickly on the client(s) and not be tied to an html producing backend server that you have to meticulously sprinkly javascript on to get the experience that users expect. I’d probably even start with the client first to drive out exactly what is actually needed from the backend. This is what my current team did with our product before I started and I think it has worked out well so far.

Let’s pretend that you have a bit of code like below…

    
angular.module('demo', [])

  .controller('LoginController', function(loginService) {
    var vm = this;
  
    vm.login = function login() {
      loginService.login(vm.username, vm.password)
        .then(function () {
          setBackground('green');
        })
        .catch(function () {
          setBackground('red');
        });
    }
  
    function setBackground(color) {
      angular.element(document.body).css({'background-color': color});
    }
  })

  .factory('loginService', function ($http, $q) {
    return {
      login: function login(username, password) {
        return $http.post('whatevs', {u: username, p: password})
          .then(function (response) {
            return response.data.token;
          })
          .catch(function (reason) {
            console.log('wtf - ' + reason);
          })
      }
    };
  });
    
  

If you’re unfamiliar with angular then the gist of it is that you have the LoginController that gets the login function called when the Login button is clicked. The controller uses a service called loginService (ignore that part about the service being defined with a factory call) that gets injected via the magical powers of angular. It uses that service to call an endpoint and returns a token on success and logs a message on failure. Back in the controller we set the background color to green on success and to red on failure. I know, right? That’s web 2.0 at its finest.

Assuming that the http call to whatevs fails; what do you expect to happen? As of before yesterday my guess would be the message would get logged in the service and then the controller would set the background to red.

It’d be a pretty boring post if that is what actually happened so go ahead and click Login below to see for yourself.

See the Pen broken promise by Darrin Holst (@darrinholst) on CodePen.

Green, amirite?

We can see from the console that we got the error logged.

The problem ends up being in our catch in the service. If you think of it like a traditional try/catch in other languages it makes sense. We caught the “exception”, but we didn’t “rethrow” it. The fix is to return a rejected promise in our error handling so the rejection gets propagated up the promise chain.

Notice the addition of the return $q.reject(reason); line in the service ($q is angular’s promise implementation).

    
angular.module('demo', [])

  .controller('LoginController', function(loginService) {
    var vm = this;

    vm.login = function login() {
      loginService.login(vm.username, vm.password)
        .then(function () {
          setBackground('green');
        })
        .catch(function () {
          setBackground('red');
        });
    }

    function setBackground(color) {
      angular.element(document.body).css({'background-color': color});
    }
  })

  .factory('loginService', function ($http, $q) {
    return {
      login: function login(username, password) {
        return $http.post('whatevs', {u: username, p: password})
          .then(function (response) {
            return response.data.token;
          })
          .catch(function (reason) {
            console.log('wtf - ' + reason);
            return $q.reject(reason);
          })
      }
    };
  });
    
  

Try ‘er again…

See the Pen rejection by Darrin Holst (@darrinholst) on CodePen.

Like most everything else, it makes sense once you know how it works and is completely baffling when you don’t. #themoreyouknow

Check out this excellent post to get a better understanding of promises if you don’t already know all the things. In particular, I found this very helpful…

Every promise gives you a then() method (or catch(), which is just sugar for then(null, …)). Here we are inside of a then() function:

somePromise().then(function () {
    // I’m inside a then() function!
});

What can we do here? There are three things:

1. return another promise
2. return a synchronous value (or undefined)
3. throw a synchronous error

That’s it. Once you understand this trick, you understand promises.

it('should not have a giant stack trace', inject(function ($document) {
  expect($document.find('.fumullins')).to.have.length(1);
}));

Nothing fancy there. It’s just looking to see if an element with a certain class exists on the page. I would expect something like the following to be in the last few lines of my test watch window so I know the test failed for the right reason.

expected { Object ... } to have a length of 1 but got 0

I was presented with the following very helpful output instead…

the object {
  "line": 875
  "message": "expected { Object (length, prevObject, ...) } to have a length of 1 but got 0"
  "name": "AssertionError"
  "sourceId": 207567360
  "stack": "AssertionError: expected { Object (length, prevObject, ...) } to have a length of 1 but got 0
    at base/node_modules/chai/chai.js?d8de1f708fb0a86a7411a0eba65bb24c852addaa:875
    at assertLength (base/node_modules/chai/chai.js?d8de1f708fb0a86a7411a0eba65bb24c852addaa:1939)
    at base/node_modules/dirty-chai/lib/dirty-chai.js?4ec10c65927a645a87817aa9142cd7df2b9263cb:127
    at base/node_modules/chai/chai.js?d8de1f708fb0a86a7411a0eba65bb24c852addaa:5289
    at assert (base/node_modules/chai/chai.js?d8de1f708fb0a86a7411a0eba65bb24c852addaa:4052)
    at base/spec/app/common/secretFormatter/secretFormatter.directive.spec.js?9dd0fd4d1504a3a1a0b79d0c9533131e13223438:15
    at invoke (base/src/bower_components/angular/angular.js?1061b10c86c20aae22472741139f553995ce2951:4203)
    at workFn (base/src/bower_components/angular-mocks/angular-mocks.js?bd422b0634824fd1aec4b70bdad3b63fc7e1f519:2436)
undefined"
  "stackArray": [
    {
      "line": 875
      "sourceURL": "/Users/dholst/Projects/secret/node_modules/chai/chai.js"
    }
    {
      "function": "assertLength"
      "line": 1939
      "sourceURL": "/Users/dholst/Projects/secret/node_modules/chai/chai.js"
    }
    {
      "line": 127
      "sourceURL": "/Users/dholst/Projects/secret/node_modules/dirty-chai/lib/dirty-chai.js"
    }
    {
      "line": 5289
      "sourceURL": "/Users/dholst/Projects/secret/node_modules/chai/chai.js"
    }
    {
      "function": "assert"
      "line": 4052
      "sourceURL": "/Users/dholst/Projects/secret/node_modules/chai/chai.js"
    }
    {
      "line": 15
      "sourceURL": "/Users/dholst/Projects/secret/spec/app/common/secretFormatter/secretFormatter.directive.spec.js"
    }
    {
      "function": "invoke"
      "line": 4203
      "sourceURL": "/Users/dholst/Projects/secret/src/bower_components/angular/angular.js"
    }
    {
      "function": "workFn"
      "line": 2436
      "sourceURL": "/Users/dholst/Projects/secret/src/bower_components/angular-mocks/angular-mocks.js"
    }
    {
      "function": "callFn"
      "line": 4562
      "sourceURL": "/Users/dholst/Projects/secret/node_modules/mocha/mocha.js"
    }
    {
      "line": 4555
      "sourceURL": "/Users/dholst/Projects/secret/node_modules/mocha/mocha.js"
    }
    {
      "line": 4974
      "sourceURL": "/Users/dholst/Projects/secret/node_modules/mocha/mocha.js"
    }
    {
      "line": 5079
      "sourceURL": "/Users/dholst/Projects/secret/node_modules/mocha/mocha.js"
    }
    {
      "function": "next"
      "line": 4899
      "sourceURL": "/Users/dholst/Projects/secret/node_modules/mocha/mocha.js"
    }
    {
      "line": 4909
      "sourceURL": "/Users/dholst/Projects/secret/node_modules/mocha/mocha.js"
    }
    {
      "function": "next"
      "line": 4844
      "sourceURL": "/Users/dholst/Projects/secret/node_modules/mocha/mocha.js"
    }
    {
      "line": 4871
      "sourceURL": "/Users/dholst/Projects/secret/node_modules/mocha/mocha.js"
    }
    {
      "function": "done"
      "line": 4518
      "sourceURL": "/Users/dholst/Projects/secret/node_modules/mocha/mocha.js"
    }
    {
      "function": "callFn"
      "line": 4573
      "sourceURL": "/Users/dholst/Projects/secret/node_modules/mocha/mocha.js"
    }
    {
      "line": 4555
      "sourceURL": "/Users/dholst/Projects/secret/node_modules/mocha/mocha.js"
    }
    {
      "function": "next"
      "line": 4872
      "sourceURL": "/Users/dholst/Projects/secret/node_modules/mocha/mocha.js"
    }
    {
      "line": 4871
      "sourceURL": "/Users/dholst/Projects/secret/node_modules/mocha/mocha.js"
    }
    {
      "function": "done"
      "line": 4518
      "sourceURL": "/Users/dholst/Projects/secret/node_modules/mocha/mocha.js"
    }
    {
      "function": "callFn"
      "line": 4573
      "sourceURL": "/Users/dholst/Projects/secret/node_modules/mocha/mocha.js"
    }
    {
      "line": 4555
      "sourceURL": "/Users/dholst/Projects/secret/node_modules/mocha/mocha.js"
    }
    {
      "function": "next"
      "line": 4872
      "sourceURL": "/Users/dholst/Projects/secret/node_modules/mocha/mocha.js"
    }
    {
      "line": 4876
      "sourceURL": "/Users/dholst/Projects/secret/node_modules/mocha/mocha.js"
    }
    {
      "function": "timeslice"
      "line": 6483
      "sourceURL": "/Users/dholst/Projects/secret/node_modules/mocha/mocha.js"
    }
  ]
} was thrown, throw an Error :)

Wtf? No, the effing smiley face at the end doesn’t make me feel better, but thanks mocha. That was 138 lines to scroll up to find out that my test failed for the reason I thought it did in case you didn’t count. The good news with modern day javascript development is that there are very few tools in the chain to dig through to figure how to get rid of this giant stackArray thing. Was it karma or was it mocha or was it karma-mocha or maybe chai or possible karma-chai or maybe phantomjs has something to do with it. At this point I was all like (╯°□°）╯︵ ┻━┻.

I was pretty certain that it was a mocha issue and I did find a nice stack trace cleaner in the process of trying to figure it out. That helped with the stack, but it didn’t help with that weird stackArray thing.

Some more googling and some greping finally landed me on this in angular-mocks.js…

try {
  injector.invoke(blockFns[i] || angular.noop, this);
} catch (e) {
  if (e.stack && errorForStack) {
    throw new ErrorAddingDeclarationLocationStack(e, errorForStack);
  }
  throw e;
} finally {
  errorForStack = null;
}

var ErrorAddingDeclarationLocationStack = function(e, errorForStack) {
  this.message = e.message;
  this.name = e.name;
  if (e.line) this.line = e.line;
  if (e.sourceId) this.sourceId = e.sourceId;
  if (e.stack && errorForStack)
    this.stack = e.stack + '\n' + errorForStack.stack;
  if (e.stackArray) this.stackArray = e.stackArray;
};

This is where the light bulb went off. If you go back up to the test you notice that I wrapped my assertion in an inject call. I did this just out of convenience to get a dependency injected closer to where it was needed in the test.

tl;dr

Don’t wrap your assertions in an inject function.

I put my dependencies in a before block like so…

var $document;

beforeEach(inject(function (_$document_) {
  $document = _$document_;
}));

it('should not have a giant stack trace', function () {
  expect($document.find('.fumullins')).to.have.length(1);
});

and #boom, a more sane looking message

PhantomJS 1.9.8 (Mac OS X) secret-formatter should not have a giant stack trace FAILED
        AssertionError: expected { Object (length, prevObject, ...) } to have a length of 1 but got 0
            at /Users/dholst/Projects/secret/node_modules/chai/chai.js:875
            at assertLength (/Users/dholst/Projects/secret/node_modules/chai/chai.js:1939)
            at /Users/dholst/Projects/secret/node_modules/dirty-chai/lib/dirty-chai.js:127
            at /Users/dholst/Projects/secret/node_modules/chai/chai.js:5289
            at assert (/Users/dholst/Projects/secret/node_modules/chai/chai.js:4052)
            at /Users/dholst/Projects/secret/spec/app/common/secretFormatter/secretFormatter.directive.spec.js:21

Hope that helps somebody.

Another book I would recommend is Quiet: The Power of Introverts in a World That Can’t Stop Talking. Although I don’t have any statistics, I think that introverts lean more towards enjoying and thriving in a remote environment. This book is good (and probably better) for the extrovert that doesn’t understand us hermits. I learned a lot about what drives extroverts from reading it.

Remote work is not for every type of person or every type of business, but given the right combination of those two and it can be a satisfying and productive work environment.

The Commute

Remote work means that an hour is not spent in my metal coffin (bonus points if you identify the movie reference Johnny) every day. My math shows 1 hour x 5 days x ~46 weeks x ~40 years = over a calendar year in your car. I would rather use that time getting my 10,000 steps and saving the tremendous amount of money that is sunk into transportation costs. The reduced stress from the lack of a white knuckle drive in a typical Iowa winter is a bonus too. 90% of drivers believe that they are a better than average driver.

Family and Time Management

Working remotely means being able to help get my kids ready for school. It means being able to take them to school when my wife is sick. It means helping my 5 yr old with a puzzle for a few minutes at 10am.

The time I actually do work stays the same, I just get to choose how to slice up my day now. I’m not stuck with 8-12, 1-5 with 2 15 minute smoke breaks.

Health and Nutrition

Remote means giving a shit about what foods I put into my body and not settling for the usual lunchtime crap. Yes, I’m aware that I can pack a lunch, I’ve tried it…a lot. I’m also aware that it’s a heck of a lot easier to just go upstairs and make something at lunchtime instead of guessing what I’ll want 6 - 18 hours ahead of time. Save money, eat healthier, stay away from people making food for you for the vast majority of your meals.

Pajama Time

For all the things that remote work means to me, it does not mean working in my jammies while watching The Price is Right. I do actually get up at the same time every morning, shower and put on big boy clothes usually beginning around 5:30am. That said, all bets are off at 4pm when Dr. Oz comes on.

There is a stigma that is attached to remote workers that we work less. The thing is we know this so that tends to make us work more than we normally would at the office. 40 hours is an important number that shouldn’t be exceeded. Watch out for overwork, it’s as bad or worse than underworking. RescueTime is a good way to keep track of where you spend your time. Give people the tools they need, stimulating things to work on and sit back and watch the human nature to want to do great things work.

Carving Out Your Space

It also does not mean lounging on the couch with my laptop. I have a dedicated space where I stand roughly 90% of my working day.

This is important and it’s one of the reasons remote work failed for me when I tried it over a year ago. I would work from coffee shops or at the kitchen counter or on the couch. Once I setup the space where I work it’s like a switch is flipped in my brain that says ‘I do work stuff here’. I rarely do any personal stuff in my work space which keeps the work/home boundaries more defined.

background-color: transparent;

Transparency is key to a successful remote working environment and more important if you are the minority in your company as a remote worker. Everyone should know what everyone else is working on. I am still working on this piece, but things like hipchat and face to face communication on a regular basis should be incorporated. (Yes, I do get out of the house. How else would I get crickets for the bearded dragon and my Trader Joe’s coconut oil?)

Working remotely has a long way to go to become mainstream (if it ever does) especially in the era that we’re in now where the top of the ladder still believes in the factory worker model. It is changing though and it’s a way of working that I’ve found to be the most sustainable and satisfying for me. All I am saying is give remote a chance.

P.S.

There is a whole other topic that I intentionally skirted. How do Agile practices fit into all of this? I ignored it for now because I haven’t come to a conclusion yet. It may need a rethinking.

Enter my latest fad of being health and diet conscious. It started (as far as I can tell) mid-summer with my Jawbone UP and making me more mindful of my standard programmer lifestyle. It progressed through calorie counting, getting the ‘proper’ ratio of macro-nutrients as determined by our all knowing, ever loving government, learning that’s all a bunch of crap, the 4 hour body for fat loss, and finally the holy grail of paleo and my favorite flavor of paleo: the primal blueprint.

My fad is now nearly 5 months old and is entering the phase where it’s just the way I live. Which brings me back to my hands which are perfectly normal now. I’m about a month past the time that I normally have these problems so I’m calling this one a great success. I’m pretty confident that your diet can fix most of the problems that we encounter today dealing with our bodies. It’s frustrating to believe and experience this while the vast majority of people are oblivious to how important their diet is.

So I’ll just end it with…

My phone was fine since I’d remember to plug it in every week or two and get the pictures off. My wife’s phone was a different story. First, I’d remember to plug it in every couple months. Second, she takes a bunch of photos…some of questionable quality. Combine that with my ocd-like behavior of needing to tag every photo resulted in marathon photo tagging sessions. That sucked.

Then I found a small app called CameraSync.

CameraSync does what the title says, it syncs your photos to the cloud wirelessly. So I set it up on both phones to sync new photos to a Dropbox folder and now the photos just magically appear on my desktop. Small batches FTW.

But there’s more! CameraSync also does that cool background job thing once you enter a geofence. I set it up to sync every time I arrive at my house. So now there is zero interaction with the app, it just does it’s thing by itself.

In mid-2010, Heroku redesigned its routing mesh so that new requests would be routed, not to the first available dyno, but randomly, regardless of whether a request was in progress at the destination.
The unfortunate conclusion being that Heroku is not appropriate for any Rails app that’s more than a toy.

Great analysis of Heroku’s routing.

I love the service that Heroku provides, but I probably wouldn’t put too many of my eggs in their basket.

As I said at the outset, I do not know how we can solve the problem of gun violence. A renewed ban on “assault weapons”—nearly the only concrete measure that anyone is talking about—will do very little to make our society safer. It is not, as many advocates seem to believe, an important “first step” in achieving a sane policy with respect to guns. It seems likely to be a symbolic step that delays real thinking about the problem of guns for another decade or more. By all means, let us ban these weapons. But when the next lunatic arrives at a school armed with legal pistols and a dozen ten-round magazines, we should be prepared to talk about how an assault weapons ban was a distraction from the real issue of gun violence.

node.set[:postgresql][:enable_pgdg_apt] = true
node.set[:postgresql][:version] = '9.1'
node.from_file(run_context.resolve_attribute('postgresql', 'default'))

include_recipe 'postgresql::server'

Original content follows…

On a project I’ve been working on I needed to get PostgreSQL updated from 8.4 to 9.anything on a Debian 6.0 system. 8.4 is the most up-to-date package on this particular system. Googling around didn’t turn anything up so this is a documentation of what I did to get it installed using Chef.

I’m assuming you’re using the postgresql cookbook and the apt cookbook.

One of the first things that you’ll probably run into while searching for a solution is the Debian Backports project. This is a repository of backported packages that will run on an older Debian system. This is where you’ll find packages for PostgreSQL 9.1. You’ll need to add this repository to APT. Add a new file called cookbooks/postgresql/recipes/squeeze_backports.rb with the following contents

apt_repository "squeeze-backports" do
  uri "http://backports.debian.org/debian-backports"
  distribution "squeeze-backports"
  components ["main"]
end

You could add this recipe everywhere you use postgresql::server or postgresql::client, but I chose to just include it at the top of each of those recipes

include_recipe "postgresql::squeeze_backports"

Now with that repository you can install the packages using the -t option of apt-get. Unfortunately I couldn’t find an easy way for the package resource in chef to do this unobtrusively since it doesn’t look in our backports repository to figure out what version to install. I did find a bug report in Chef discussing this and a fix for it, but it wasn’t fixed in the version I was using. So we’ll do it the DevOps way and hack it…in cookbooks/postgresql/recipes/client.rb I replaced:

node['postgresql']['client']['packages'].each do |pg_pack|
  package pg_pack
end

with:

execute "install postgresql-client from backports" do
  command "apt-get -t squeeze-backports install postgresql-client -y"
  not_if "dpkg-query -W postgresql-client|grep -q postgresql-client.+"
end

execute "install libpq-dev from backports" do
  command "apt-get -t squeeze-backports install libpq-dev -y"
  not_if "dpkg-query -W libpq-dev|grep -q libpq-dev.+"
end

and in cookbooks/postgresql/server_debian.rb I replaced:

node['postgresql']['server']['packages'].each do |pg_pack|
  package pg_pack
end

with:

execute "install postgresql-server from backports" do
  command "apt-get -t squeeze-backports install postgresql -y"
  not_if "dpkg-query -W postgresql|grep -q postgresql.+"
end

One last thing you’ll need to do is make sure the PostgreSQL version is set correctly in cookbooks/postgresql/attributes/default.rb which just means removing the check for debian 6.0 so it defaults to 9.1. It ends up looking something like:

when "debian"

  case
  when node['platform_version'].to_f <= 5.0
    default['postgresql']['version'] = "8.3"
  else
    default['postgresql']['version'] = "9.1"
  end

Given all of those changes and if all the moons line up then on your next chef client run you should have version 9.1 installed. Good luck and please add a comment if there is a more elegant way that I missed.

So I found this cool ifttt recipe that logs all of your tweets to a dropbox file. It puts them all in a single file with a format of:

At a drive in. Wat?  @ Valle Drive-In http://t.co/Z9lz7O5F
Jun 30, 2012
http://twitter.com/darrinholst/status/218878382123909120
- - - - -

I see blurry apps
Jun 30, 2012
http://twitter.com/darrinholst/status/219074474073538560
- - - - -

Since the twitter api only allows you to get to 3200 of your tweets I though it would be a good idea to get the rest of the tweets that are accessible to me in there as well. The quickest way I know to get my latest tweets is at allmytweets.net. Allmytweets will pull down all your tweets and then show them on their page. The html ends up looking like:

8"><img src="css/extlink.png"></a></li><li>Straw in the wro
ng hole.  @ High Life Lounge <a href="http://t.co/kdMfTvPk">
http://t.co/kdMfTvPk</a> <span class="created_at">Jun 12, 20
12</span> <a href="https://twitter.com/#!/darrinholst/status
/212644435689881600"><img src="css/extlink.png"></a></li><li
>I can see @dwolla from here! <span class="created_at">Jun 1
2, 2012</span> <a href="https://twitter.com/#!/darrinholst/s
tatus/212639918541910016"><img src="css/extlink.png"></a></l
i><li>Simplify Design With  Zero, One, Many rules <a href="h
ttp://t.co/0bvdVzzo">http://t.co/0bvdVzzo</a> <span class="c

All the data is there, but not very useful for a txt file. Here’s the commands I threw at it to format it up:

Split li tags up to separate lines

%s/<li>/\r<li>/g

Preserve new lines in the tweets with a token

%s/\n/##NL##/g

Change new line tokens in between li tags back to new lines

%s/<\/li>##NL##<li>/<\/li>\r<li>/g

Reverse the order of the tweets, I want them in chronological order (The only non-replace command)

g/^/m0

Remove li start tags

%s/<li>//g

Replace li end tags with a separator

%s/<\/li>/\r- - - - -\r/g

Turn new line tags back into new lines

%s/##NL##/\r/g

Get rid of the start span tag for the date

%s/<span class="created_at">/\r/g

Get rid of the end span tag and tweet link start tag. Also change from https to http

%s/<\/span> <a href="https/\rhttp/g

Get rid of those stupid #!s

%s/\/#!\//\//g

Get rid of the image from allmytweets.net

%s/"><img src="css\/extlink.png"><\/a>//g

HTML decode

%s/&/\&/g
%s/&lt;/</g
%s/&gt;/>/g
%s/&nbsp;/ /g

Get rid of remaining html

%s/<a href="//g
%s/">.*<\/a>//g

Clean up trailing spaces

%s/ *$//g

EDITING TEXT IS FUHHHH UHN! I wish I would have though of this 3800 tweets ago though.

In my last talk that I gave on CoffeeScript I quickly went over function binding and CoffeeScript’s => syntax. My point was that when you need to use .bind(this) then you could just use => for shorter syntax. The inevitable question that came up was “Why wouldn’t I just use that everywhere?”. It’s a valid question, especially coming from people that aren’t in the JavaScript world a lot and/or haven’t figured out the this craziness. I didn’t have a good answer at the time, but I gave the example of jQuery setting this to the event element and you might want that this pointer instead of the current one.

class ClickLogger
   clicked: ->
     console.log(@.href)

   clickedBound: (event) =>
     console.log(event.target.href)

$("a").on("click", new ClickLogger().clicked)
$("a").on("click", new ClickLogger().clickedBound)

In the example above we want the element that was clicked and we don’t need anything from the instance of ClickLogger so there is no reason to bind it. It also shows what you would have to do if you did bind it.

Fast forward to present day when Les Hill posted some slides of a Backbone and Rails presentation he did. In there was…

…which got me thinking about it again. So I asked him and his response was…

Intention revealing. So by not using => everywhere means that I know what it does and when I should use it and that I really intended to override the default behavior.

Just because you have shorter syntax to do cumbersome things doesn’t mean you should use it everywhere, especially if you wouldn’t have naturally done the cumbersome thing if you didn’t have the shorter syntax.

In case you were wondering if performance was a reason for not using it everywhere…it’s not.