Harry Wolff

Things I Don’t Like about Vue.js (as a React engineer)

Tue, 27 Oct 2020 00:00:00 GMT

This blog post is a follow up from my last article What Vue.js Does Better Than React.

This article, instead of focusing on what Vue.js does better than React, will take the opposing perspective.

Let's take a dive into all the things that I think React does better than Vue.js

Notable preface: I've used React professionally for the past 5 years, so it's obviously my UI framework of choice. I've tried to take as close to an objective stance on these points, but I'm sure you'll see my subjectivism poking through.

Templates

One of the biggest features of Vue.js, and frankly what is Vue.js' biggest strength, is its template syntax to write UIs.

After using React for 5 years, which is as close to plain JavaScript as you can get, having to learn another template syntax is not something that I want to bother with.

In my career I've learned: Mustache.js, Handlebars, Lodash's template syntax, Django syntax, and probably more that I've forgotten. I don't want to learn yet another template syntax with Vue.js.

Each template syntax has some similarities and some differences that gives me ever so much of a headache switching from one to another.

Another thing that I don't like about template syntax is that it adds a layer of abstraction between when you write and what runs in the browser.

With React you have JSX which just compiles down to function calls:

// React in
<div title="Hello">Message: {message}</div>;

// React out
React.createElement(div, { title: 'Hello' }, 'Message: ' + message);

With Vue.js I have no idea what the templates compile down to.

Both React and Vue.js only allow JavaScript expressions in their templates, which makes sense given the constraints of JavaScript, but where things get confusing for me with Vue.js is that there’s only access to a subset of globals inside expressions. I'm sure there's a good reason for that, but having to keep in mind that Vue.js templates are not simply JavaScript adds a layer of complexity I'd rather do without.

Directives

Directives is the killer feature of Vue.js. It's what makes their templates so powerful.

However.

Directives are effectively an API you have to learn to use Vue.js templates efficiently. Compared to Angular.js (which I used way back in the day) the list of Vue.js directives are pretty small, however it's an added layer of complexity required to use Vue.js efficiently.

This is further exacerbated by the flexibility Vue.js bestows directives, which itself comes with additional complexity.

There are directive arguments, that can have dynamic arguments, and then there are directive modifiers (which I did hold up as a strength in my first blog post, but it comes at the cost of additional complexity)!

Most of the syntax for directives aren't terrible, but I do find the syntax for v-for directives to be very un-JavaScript. They're much closer to Python than anything else, which seems weird to include in a JavaScript framework.

Components

This is a nitpick, but one that reinforces my template point.

Since Vue.js is largely a template driven framework, when you extend it with custom components, you need to tell the Vue.js template compiler about the components you're using.

This results in a lot of duplicate code, that just looks completely superfluous to me.

// Import your components as you normally would with ES Modules
import ComponentA from './ComponentA';
import ComponentC from './ComponentC';

export default {
  components: {
    // Register them with the template compiler
    ComponentA,
    ComponentC,
  },
  // Then finally use them in your template
  template: `
		<ComponentA />
	`,
};

Custom Events

Aside from templates, custom events are one of the biggest differences between Vue.js and React.

Everything in React is a component and a prop (to almost an unhealthy degree). When you want a child React component to communicate to a parent component you pass down a function that the child component can call:

function Parent() {
  const onClick = () => alert('hello!');
  return <Child onClick={onClick} />;
}

function Child({ onClick }) {
  return <button onClick={onClick}>Click me!</button>;
}

However the way to do this in Vue.js is with events:

const ParentComponent = {
  components: { ChildComponent },
  template: `<ChildComponent @greeting="alert('hello')" />`,
};

const ChildComponent = {
  emits: ['greeting'],
  template: `<button @click="$emit('greeting')">Click me!</button>`,
};

Honestly I'm not terribly sure how I feel about using events as a way for children to communicate up.

When I used events with Angular.js it was horrible as there was no concrete contract between what events were emitted and what were being listened to.

However Vue.js mitigates that issue with tooling to make sure that when some parent tries to listen to an event the component actually emits that event.

Without that tooling I think Vue.js would fall prey to the same issues as Angular.js but it's Vue.js' excellent tooling that truly saves the day here.

That being said, React's function passing via props works just as well and is in my opinion even more robust.

Method Event Handlers

Related to custom events is how Vue.js attaches event handlers into their templates. It's one of my most despised mechanisms: string references!

When you reference a method in a Vue.js template you pass in the name of the function as a string:

<button @click="greet">Greet</button>

Which...I've been bit so bad in the past when using string references.

However like above, the saving grace here is Vue.js' tooling will catch any silly typos. However it's a pattern I've grown to greatly dislike and would prefer not to use again.

Reactivity

Most of the magic of Vue.js comes from its reactivity library. Its what gives Vue.js the ability to efficiently and quickly update UI when data changes. It reminds me greatly of MobX, but built-in to Vue.js and tailored for its needs.

However both MobX and Vue.js' Reactivity comes with trade-offs, where you have to consider the implementation details of Reactivity when using it in components.

For example when creating a reactive object you wrap the object with the reactive function. However when you want to use a primitive value you wrap it in ref and it acts very similar to React's useRef hook.

If you want to destructure a reactive object you need to wrap it in toRefs(reactiveObject) to make sure you don't lose the reactive bindings. Which is only needed due to how reactivity works in Vue.js (with Proxy's).

For primitive ref values Vue.js will automatically unwrap the ref values in templates, which is nice and helpful, but produces inconsistent usages of ref values.

In templates you don't have to unwrap, but in the component JavaScript you need to unwrap. This added context switch seems un-necessary to me and confusing at first glance.

For common use cases I'm sure these edge cases are seldom felt, but I'm curious how it scales.

This of course is opposed to React's almost too simple useState and useRef which just return setter functions and a consistent ref-object interface respectively. Perhaps React's API is too simple as it pushes most of the behavior on the end-developer, but at least there's no magic, and that's what I care about most nowadays.

Video

Like every post, I have an accompanying video to watch as well:

Wrap-up

It shouldn't be any surprise that I prefer React's way of doing things more than Vue.js.

Ultimately the difference comes down to my dislike for how much Vue.js does on my behalf. I prefer to have access to the raw functions and methods to completely control my UI - which React provides.

React isn't without its share of quirks, but I do find React's quirks to at least be clear. There's very few layers of indirection between what I wrote and what React does. (Ignoring the dark magic that is the react-reconciler library and god help anyone who tries to debug stack traces within those depths).

It's hard to sit here and not say that React is better, because I do personally think React is better - for me! If Vue.js tickles your fancy better then keep using Vue.js! My only hope here is to highlight the differences between Vue.js and React and why React remains my preferred choice for a UI library.

What Vue.js Does Better Than React

Mon, 19 Oct 2020 00:00:00 GMT

I've been a React engineer for the past 5 years. I love React. I love making React applications. I think it's one of the best UI frameworks available right now.

However, there are a few competitors in this space. One of the biggest is Vue.js.

I've played around with Vue.js a little bit in the past but I figured it was way past due to do a deep dive into how Vue.js works, and how it makes my life as a UI engineer easy.

After delving deep into the Vue.js docs and playing around with Vue.js (note: I am in no way a Vue.js expert) I was shocked to find myself liking the way Vue.js did some things better than React.

Ultimately I hope that React ~~steals~~ is inspired by these things that Vue.js does and starts doing them as well.

Different Philosophies

One of the key differences between Vue.js and React is how they market and refer to themselves.

Taken straight from their home pages, React describes itself as "a JavaScript library for building user interfaces" whereas Vue.js describes itself as "progressive JavaScript framework" (emphasis mine).

React is a library, Vue.js is a framework. I think in many ways that is the underlying reason for the difference in how and why each UI framework does the things it does.

I wanted to highlight this so you keep it in mind while you read this post. Frameworks are historically more comprehensive and exhaustive in what they provide and require, whereas libraries are slimmer and do less, but what they do focus on they do extremely well.

Single File Components

Both Vue.js and React have components as a building block to create your UI.

Components are commonly comprised of 3 parts:

UI (HTML)
Behavior (JavaScript)
Appearance (CSS)

Vue.js has their concept of a "Single File Component" which is an out of the box way to write components that covers all 3 parts.

Here's what it looks like:

<template>
  <p>{{ greeting }} World!</p>
</template>

<script>
  module.exports = {
    data() {
      return {
        greeting: 'Hello',
      };
    },
  };
</script>

<style scoped>
  p {
    font-size: 2em;
    text-align: center;
  }
</style>

You don't have to be a Vue.js engineer to understand what's going on here.

React components include UI and Behavior out of the box, but style is very much kept out of the equation:

import React, { useState } from 'react';

function Button() {
  const [count, setCount] = useState(0);

  return (
    <button onClick={() => setCount(count + 1)}>
      Current count: {count}
      <br />
      Click me
    </button>
  );
}

Of course React has a very rich community so if you do want to include styles you can easily reach for Emotion or Styled Components and they will fill the Style hole, but:

It's not built in
You have to know these libraries exist to use them.

As opposed to Vue.js where it's there, for free, by default.

Officially Supported Related Libraries

Any sufficiently large and complex UI application requires two additional pieces of functionality to support their large size:

Router
State Management

Vue.js has officially supported libraries that cover both those use cases, Vue Router and Vuex respectively.

These libraries are explicitly mentioned on the Vue.js docs page and they are developed and maintained alongside Vue.js core. That's simply phenomenal.

It gives new Vue.js engineers a clear path towards a solution to their problems and gives them the confidence that these libraries are built to last so they can be confident when choosing them.

Having first-party supported libraries doesn't limit community solutions, but it does provide a go-to solution for new comers.

Style Guide

Uh, I want React to have this yesterday. Before you even read this section click the link and browse around Vue.js' style guide.

It answers so many questions newcomers to Vue.js may have. It provides best practices and guidelines on how to write "proper" and approachable Vue.js applications.

It shares and codifies battle tested and community vetted best practices and patterns.

To top it all off - it's maintained and supported by Vue.js itself! Terrific!

Class and Style Bindings

As mentioned above Vue.js has built in support for styling. Further than that Vue.js essentially has the library classNames built-in.

Classnames is a terrific library for easily concatenating and dynamically constructing CSS classnames that should be applied to an HTML element.

In React land you'd have to know this library exists, and then install it.

In Vue.js it's just another built-in feature. From the docs:

Given a Vue.js template like this:

<div
  class="static"
  :class="{ active: isActive, 'text-danger': hasError }"
></div>

And data like this:

data() {
  return {
    isActive: true,
    hasError: false
  }
}

The resulting UI will be:

<div class="static active"></div>

Having this built in is awesome.

Vue.js goes even further with their support for inline styles. Vue.js, like React, supports inline styles, however where Vue.js outshines React is its ability to auto prefix CSS that needs it.

From the docs:

When you use a CSS property that requires vendor prefixes in :style, for example transform, Vue will automatically detect and add appropriate prefixes to the applied styles.

Truly shows the strength of being a framework and controlling your own template syntax.

Slots

Everything in React is a prop.

If you want to render multiple arbitrary children in a React component then you just add more props:

function Nav({ left, right }) {
  return (
    <nav>
      <div className="left">{left}</div>
      <div className="right">{right}</div>
    </nav>
  );
}

function App() {
  return (
    <main>
      <Nav left={<Logo />} right={<UserDropdown />} />
    </main>
  );
}

This works fine but it's a tad awkward, especially if the content inside the props gets large.

Vue.js takes a different approach via Slots, and I think it's API is a little more cleaner.

<!-- A Vue.js component template named "base-layout" -->
<div class="container">
  <header>
    <slot name="header"></slot>
  </header>
  <main>
    <slot></slot>
  </main>
  <footer>
    <slot name="footer"></slot>
  </footer>
</div>

<!-- When "base-layout" is used -->
<base-layout>
  <template v-slot:header>
    <h1>Here might be a page title</h1>
  </template>

  <template v-slot:default>
    <p>A paragraph for the main content.</p>
    <p>And another one.</p>
  </template>

  <template v-slot:footer>
    <p>Here's some contact info</p>
  </template>
</base-layout>

Vue.js uses Slots (which is inspired by the Web Components spec draft) to clearly denote where content goes inside a component.

Something that Vue.js does repeatedly is provide shorthand for common tasks. In this case, the above example can be abridged with the Slot shorthand:

<base-layout>
  <template #header>
    <h1>Here might be a page title</h1>
  </template>

  <template #default>
    <p>A paragraph for the main content.</p>
    <p>And another one.</p>
  </template>

  <template #footer>
    <p>Here's some contact info</p>
  </template>
</base-layout>

Directive Modifiers

Vue.js has this feature called Directive Modifiers that I think are really really cool.

Before I can talk about Directive Modifiers let me give you a quick pitch on what a Directive is.

Directives are "special attributes with the v- prefix" which you use inside Vue.js templates.

A directive's job is to reactively apply side effects to the DOM when the value of its expression changes

For example:

// If "seen" variable is false then this p tag is not rendered
<p v-if="seen">Now you see me</p>

There's directives for event handlers:

<!-- full syntax -->
<a v-on:click="doSomething"> ... </a>

<!-- shorthand -->
<a @click="doSomething"> ... </a>

And there's many more Directives.

Directives also support modifiers.

It's a very developer friendly way to perform common tasks with common directives.

For event handler directives (v-on) there's a whole slew of modifiers:

<!-- the click event's propagation will be stopped -->
<a @click.stop="doThis"></a>

<!-- the submit event will no longer reload the page -->
<form @submit.prevent="onSubmit"></form>

<!-- modifiers can be chained -->
<a @click.stop.prevent="doThat"></a>

<!-- just the modifier -->
<form @submit.prevent></form>

...and more!

If you wanted to do this in React you'd either make a helper function or a custom component. Which is fine, but doesn't feel as clean compared to directive modifiers.

I am curious if someone could make a Babel JSX superset so you could write code like:

<form onSubmit.prevent={onSubmit} />

And it would transform to:

React.createElement(form, { onSubmit: preventWrapper(onSubmit) });

It's not in the ethos of React, but I still think it's a super neat productivity win.

There's many more Vue.js modifiers. Some of the coolest ones are key modifiers:

<!-- only call `submit()` when the `key` is `Enter` -->
<input @keyup.enter="submit" />

<input @keyup.page-down="onPageDown" />

Very, very cool.

Form Input Bindings

The v-model directive has a really interesting characteristic when binding data to form input elements.

From the docs, v-model internally uses different properties and emits different events for different input elements:

text and textarea elements use value property and input event;
checkboxes and radiobuttons use checked property and change event;
select fields use value as a prop and change as an event.

What's great about this is you don't need to care about how the data is synced, just that it's taken care of for you.

Let's compare how React would do these bindings and how Vue.js does it:

// Input
////////

// React
<input type="input" value={message} onChange={onChange} />

// Vue.js
<input type="input" v-model="message" />

// Checkboxes and Radiobuttons
////////

// React
<input type="checkbox" checked={message != null} onChange={onChange} />

// Vue.js
<input type="checkbox" v-model="message" />

// Select
////////

// React
<select value={message} onChange={onChange}>
	<option>A</option>
</select>

// Vue.js
<select v-model="message">
	<option>A</option>
</select>

Detecting a pattern here?

Now, one thing I will say in React's defense is that React encourages (and requires) you to learn how the data is actually set and how it changes. Which means that if you were to ever write a form with Vanilla JS you'd have a lot more knowledge on how it works and be able to code it correctly. As opposed to Vue.js which just abstracts away all those quirks for you.

Custom Directives

Like any good framework you can create your own custom directives in Vue.js.

Vue.js does note that "the primary form of code reuse and abstraction is components" however one of the best examples of why a custom directive may be better is with their custom v-focus directive to automatically focus an input element on mount:

const app = Vue.createApp({})
// Register a global custom directive called `v-focus`
app.directive('focus', {
  // When the bound element is mounted into the DOM...
  mounted(el) {
    // Focus the element
    el.focus()
  }
})

<input v-focus />

In React you'd probably write a custom component to accomplish the same thing, which seems a little heavy for such a light task.

Written in TypeScript

Last but not least, Vue.js was recently rewritten from the ground up in TypeScript.

This means their TypeScript support is first-class as the framework itself is written in TypeScript.

Ultimately it doesn't really matter what React is written in, and I don't think it makes that much of a difference, but it's still a small little thing that was nice to see Vue.js have.

Video

I've expanded on these thoughts in video form as well! Feel free to watch if you're interested:

Closing Thoughts

After all that am I going to abandon React and start using Vue.js exclusively? No. I still very much enjoy the "library-ness" of React and frankly I'm already very proficient at writing React applications.

However I would love to see React grab some inspiration from Vue.js and incorporate some of these great ideas into React. If I had to choose just one from this list it's absolutely the style guide. I would love to see React have an officially supported and maintained style guide.

Hopefully I've opened your eyes to some things that you didn't know Vue.js did! I was certainly surprised to find myself really enjoying the way Vue.js did things!

My Tech Stack (2020 Edition)

Sun, 09 Aug 2020 00:00:00 GMT

In my spare time I enjoy working on side projects. Little websites and projects that I can play around with to either learn new things or to create something for fun.

In the past I've always been stymied in my attempts to create something for fun because some part of the process becomes laborious and boring to work on. So when that inevitably happens, I stop working on the project, and dust begins to accumulate.

When I'm working on a side project I don't want to focus on technical problems, I want to focus on the product I'm creating. I don't want to have to re-think how OAuth works, I want to let someone login with their GitHub credentials.

So for the past couple of months I've been putting together a tech stack that I can use on these side projects that lets me focus on the product at hand, and ignore all the technical distractions.

I'm so proud to say that I've found a tech stack I'm super excited about that does exactly what I need.

I made a video about it that you can watch right here.

However if you prefer the format of spoken word, then keep on reading.

Frontend

React.js

It goes without saying but I'm a huge fan of React. I think it's the best way to write a frontend application. It lets me be super productive and at this point I have many years of experience with it, letting me write code really quickly.

Next.js

React is great, but by itself it doesn't go very far. To be productive with React requires a lot of tooling and setup and frankly I would prefer to not waste my time dealing with all that.

Next.js handles that all for me, and then some. It lets me start coding with React and not worry about all the boilerplate noise.

Beyond the boilerplate Next.js comes with some truly incredible features:

Server side rendering

I've tried creating my own server-side rendered React app in the past and let me tell you...it's very hard. The fact this comes out of the box with Next is something that I think most people will take for granted, but it's incredible how easy they make it.

Static page generation

I get the best of both worlds - server rendered pages AND statically generated pages. Which means that for pages that I want to offload most of the work to the client, I can!

Server API endpoints

No need for Express to make custom data endpoints, it's built in to Next.js!

All these features make it super easy to get going with Next.js. It's truly the best React framework available right now.

Tailwind CSS

I'm not a designer. I can implement designs, but creating my own designs is a large area of weakness for me.

I also have no desire to use Bootstrap. I can't stomach the thought of my site looking like another bootstrap website.

Instead I'm turning my interests to Tailwind, which has some strong default styles available, but also being flexible enough that I can truly make my project look like my own.

It's also just a very interesting way of doing CSS. The utility CSS approach is one that I would have scoffed at a few years ago but I'm really excited about it nowadays.

The fact I can design a full website just with Tailwind and no custom CSS is truly incredible to me.

Chakra UI

Tailwind covers just CSS and styles. However some components, such as a Tooltip or a Modal, require interactivity and JavaScript.

Again, because I'd rather focus on my project and not the technology, I'm turning to Chakra to cover those use cases.

It also has some strong default styles that look to blend nicely with Tailwind.

Emotion

If I do need my own custom styles then I'm a big believer in CSS-in-JS nowadays. (If you want to hear more of my thoughts on CSS-in-JS then watch my video about it).

Emotion is my favorite CSS-in-JS library nowadays. It lets me be hyper productive and super expressive in how I write my styles. Great library.

React Context

To store data I've gone back to basics and just rely on vanilla React Context. Most of my data needs are simple enough that a plain Context provider will handily cover my needs.

If I do find my data structures getting complex then I will always turn to Immer as an easy to update my state.

Check out my videos about Context and Immer to gain more of an idea of how I like to use them:

React Query

This is a new addition to my tech stack but one I'm super glad to have found. React Query makes it easy to make REST calls to my backend and cache the results in the browser.

It's API is intuitive and provides some lovely structure to all my data fetching. Very well designed library!

Backend

Next.js API Routes

Surprised to see Next.js again? Don't be! This is why I love it so much - it does double duty!

Using Next.js' API Routes I can serve up any arbitrary data to the frontend. Completely replaces Express for me!

MongoDB Atlas

Disclaimer: I work for MongoDB

I need to store data somewhere, right? And the best place for that is a database, right?

The best database right now in my opinion is MongoDB. Not only that but MongoDB Atlas is a hosted mongodb service, with a free tier included!

Which means I can create a free MongoDB database, connect it to my Next.js app, and serve data from my database, all for free! Wonderful!

NextAuth.js

Authentication is a pain in the ass to code. I have no interest in re-implementing the OAuth protocol to provide authentication via third-party sites.

Luckily this library, NextAuth.js, takes care of all that boilerplate for me.

The installation process is drop dead simple - just add one splatted route in my Next.js API Routes.

All told I was able to login via GitHub in under 5 minutes. Supurb.

faker.js

While developing I need some dummy data to play with. Faker.js is a great library for generating fake data so I can spend more time designing my UI and less worried about filling in blank spaces. Nice little library.

Testing

Jest

Jest is the gold standard in testing for JavaScript applications. In my opinion no other testing framework comes close to offering what Jest provides.

Strong defaults, massive ecosystem, and a true joy to use.

React Testing Library

For testing React applications, React Testing Library is the best choice. It's strongest selling point is that it only uses React's public API when rendering React components.

This means that you're gauranteed to be testing components the same way they are rendered for a user.

Additionally the utilities and helper functions encourages strong testing practices such that your tests cover how your users use your application.

Cypress.io

Cypress is the best way to write end-to-end tests. E2E tests being tests that run in a browser.

There are two standout features for Cypress that make it super pleasing to work with:

It has built in flakiness mitigation. If you've ever used Selenium in the past, or other browser-based testing libraries, then you know how painful it is to write reliable tests. For example, when you open a model with an animation and click a button inside the modal, adding in handling to make sure the test waits for the animation to finish is notoriously difficult and annoying. This is built-in to Cypress.
It is incredibly easy to debug and write tests. It has a GUI that provides a clear way of understanding how your tests are behaving. In that GUI you get screenshots of how your tests changed the browser, including time-traveling capabilities, to roll back a few steps and see the browser at a previous step. You truly have to try it to understand how powerful it is.

Hosting

Vercel

There's no better place to host my project than by the authors of Next.js, that being Vercel.

They have a free tier as well, and a super easy deploy process.

What's the deploy process? Push to git and that's it. Vercel watches changes to your git repo and will automatically rebuild on any new commits.

It also has branch previews. Such that if I create a branch and push new code to that branch, Vercel will also build that version of my site for me as well.

A wonderful experience all around.

Start Coding!

That's my current tech stack! It took me a while to put it together, but I'm very happy with how it turned out.

What I love about this stack is it handles all the boilerplate for me. I don't need to worry about auth, design, or how to store data. It's all taken care of for me.

What I love even more about this stack is that by default it costs $0. Which, when I'm playing around with a side project, is what I want. I don't want to pay something while I'm still figuring out what it is I'm building.

Curious if you use any of the same technologies as me, or if your stack is slightly different. Be sure to tweet at me to let me know, I'm curious to hear!

2019 In Review

Sun, 08 Dec 2019 00:00:00 GMT

So not only is the end of 2019 quickly approaching, but so is the end of a decade. The 2010s are drawing to a close. An entire decade is over, and we're just about to enter the 2020s. What an amazing time to be alive.

I wanted to take a few moments to reflect on the past year. Quite a lot happened and I would be remiss if I didn't reflect on the growth and exciting events that happened to me in 2019.

I've also made a video talking about my 2019 in case you want to see this post in video form:

2019 Most Watched Videos

Last year I was used to getting between 300-500 views per video. If a video cracked more than 500 views I was ecstatic. It meant people were actually watching what I was creating.

This year could not have been more different. This year I regularly had videos cross over 1000 views, a fact I am still not quite used to.

Getting so many people watching my videos is such a wonderful progression for my YouTube channel. It's so encouraging and helps me keep going.

I went through all the videos I made in 2019 and sorted them by most viewed. Here's that list:

Why I Love useReducer (11943)
Async React Hooks (5710)
How to useContext with useReducer (4754)
Testing React Hooks (4586)
A Svelte Chat with Rich Harris! (4347)
TypeScript and React (3768)
Playing with Svelte 3 (3215)
Getting Dapper with Sapper (3089)
Level Up useReducer with Immer (2975)
What's New with React Dev Tools 4 (2579)
Overview of React Concurrent Mode (2499)
What are TypeScript Generics? (2411)
My Visual Studio Code Extensions, 2019 Edition (1908)
What is React Ink? (1846)
What is TypeScript? (1624)
CSS in JS: My favorite (1459)
How to use the GitHub Package Registry (1423)
Playing with Framer Motion (1412)
What is CodeSandbox? (1220)
Setting Up TypeScript w/ Babel (1215)

Other 2019 Milestones

Some really exciting things happened in 2019!

I spoke at a conference, React Alicante 2019! It was really fun getting to present to people in person. Getting to share my ideas in real time was a lot of fun. I love feeling the audience listen while I talk, and adjusting how I present to make it the most entertaining and informational.

I was also a guest on FreeCodeCamp's Podcast where I got to talk about myself for an hour straight. It was fun sharing my history: how I got my start in the industry, what my progression looked like, how I got to be who I am today. If you're curious about that backstory then that is definitely the best place to start.

And also...if you're reading these words...I started blogging again! 2018 was a very light year for blog posts but I was able to actually get myself back into the writer's seat and put some "ink to papper" so to speak. I hope to keep that up going into 2020.

The Future

I have quite a few projects I want to take on in 2019 (like I don't have enough, wth Harry).

The first one has already begun: I started a newsletter!. This is the direct result of ending the podcast I created but it has nearly the same format and content. Want to stay up to date on the latest JavaScript news? Subscribe!

A big project I want to take on next year is create a full-fledged course. Probably it'll be to teach React but there's no certainty about the topic. However I do want to make a full length course that lets me dive deep into a subject and teach it as well as possible. Stay tuned as that project progresses!

I also want to do more for my Patreon patrons, make that even more of a valuable membership. I recently started a Discord server for my Patrons, such that if you become a Patron you get to talk to me in real time! It's so real you can practically touch me!

Here's to next year and the next decade! Happy New Year!

Pro VSCode Tricks

Sat, 07 Dec 2019 00:00:00 GMT

One of the most important things you can do to become a highly efficient programmer is to learn how to use your code editor. Most text editors, or IDEs, host a huge amount of functionality that help you code fast and efficiently. The only thing that sucks is that it can be very hard to learn all of those pro features - there's almost too much!

I've been using VSCode now for over two years and I've picked up many shortcuts and tricks along the way that have become invaluable to how I code. In fact, I'm so efficient with VSCode that it's my goto program when I'm writing anything that has to do with text.

So, rather than keep all these secret tricks to myself I'd prefer to share them with you! Yes you, the reader of this article!

I imagine you're curious how you can super-charge your own VSCode usage, right? After all, that's why you're here!

And if you'd rather have me show you all these tricks then you're in luck as well! I have a wonderful video already recorded and edited for your viewing entertainment:

However, if you're the reading sort, behold! All my Pro VSCode Tricks!

Navigation Shortcuts

These keyboard shortcuts help me move around VSCode without ever reaching for my mouse. They're simple quality of life improvements, but when taken together add up to an immense amount of value.

These shortcuts help me change the layout of VSCode, which depending upon what I'm doing, is of great help.

Toggle Side Bar Visibility: Command ⌘ + B

If I need more horizontal real estate this is my go to move. It hides the side bar so I can focus only on the code in front of me.

Toggle Bottom Panel: Command ⌘ + J

This is the sister command to the one above. This lets me hide or show the bottom panel so I get more vertical real estate.

With these two powers combined I get a full screen window without switching to full screen mode!

Open Terminal: Control ⌃ + `

I use this to jump into the terminal to do some CLI work. I used to use this command a lot more before I learned about the toggle bottom panel command, but it's still a useful one to know.

Open Explorer: Command ⌘ + Shift ⇧ + E

The Explorer is that big tree that lists all the files in your current project. It's the one that you probably use all the time to jump between different files. If you ever need to go straight to there then this is the shortcut for you.

Open Search: Command ⌘ + Shift ⇧ + F

Likewise, if you want to do a global search over all the files in your project you can jump directly to the global find pane.

Project Manager

Project Manager is actually an extension. However it's one that I rely on all the time.

It lets me set a list of projects that I'm actively working on and lets me quickly jump between them.

Saves a lot of time to having look up where the directories are in my file system, I can just search by the project name and be on my way.

Selection Pro Moves

Oh man...this is by far the bread and butter of all my pro moves. This is how I'm able to make multiple modifications all at the same time, saving me seconds every day. Seconds! You add up those seconds and it turns into a full day! I'm going to save you a day's worth of time!

Also you'll look really cool doing this.

Select Multiple Words: Command ⌘ + D

This one is very hard to explain in words. Basically if you have some word on a page you can select it, and then hit Command ⌘ + D to select the next instance of this word. This becomes awesome when you're editing an array of objects in a JSON or JSON-like file.

If you have a key called 'name' you can expand your selection so that you select every 'name' word on the page and then you can make edits all at once.

Even further, once you've expanded your selection to all the places you want, you can then move your cursor around as you would before. So if you wanted to modify the value instead of the key you could hit right a couple of times and be on your merry editing way.

Jump over words: Option ⌥

This is actually a system wide shortcut, but one that I take advantage of in VSCode.

By default when you move your cursor with the arrow keys they move one by one. One by one, and it becomes very inefficient when you're trying to navigate across a lot of text.

If instead you hold down the Option ⌥ key and then navigate with the arrow keys it changes the behavior. Now you'll be jumping over words, letting you quickly move forward and backwords when moving code around.

Also if you hold Shift ⇧ on top of holding Option ⌥ you'll be able to select words at a time.

So, if you've made multiple selections using the trick above, and then hold Option ⌥ with Shift ⇧ you can then easily select multiple blocks of text and then can edit them all at the same time.

This is the super power-up combo that makes me feel like a dark wizard, and I love it.

Move Line Up or Down: Option ⌥ + Up/Down

Let's say you have a variable assignment that you want to move up a few lines. If you use this trick that becomes a real quick job. You don't have to select the line, cut the line, move the cursor, paste the line. Just put your cursor on the line you want to move and use this trick to move it wherever you want.

This trick also works if you select multiple lines. If you have any number of lines selected and you use this shortcut then VSCode will move that entire block for you.

Multiline Selection: Option ⌥ + Shift ⇧ + L

Multiline Selection is another extension. This is functionality that was ported over from Sublime Text, and I got used to it there and was glad to see someone make a VSCode replacement.

Select multiple lines and then use this shortcut to make a cursor selection on every line.

I use this instead of the Command ⌘ + D shortcut when there isn't a common word to select on every line.

So it becomes very helpful if I have a couple of consecutive lines that I want to make the same edits to, but their contents are all different.

Fast Line Removal: Command ⌘ + X

Did you know that VSCode has the ability to quickly remove a full line? This shortcut is actually for cutting text from the page, however if you don't have any text selected VSCode will fall back to the entire line.

So I use this a lot to quickly get rid of multiple lines of text by repeatedly hitting this shortcut.

There's an actual shortcut to delete a line but this one is so much easier to use.

Built in VCS editor

VSCode has an excellent built-in version control system editor.

It's so good that it's replaced all the other GUIs I was using to manage Git.

Learn how to use it! It's powerful, flexible, and built right into VSCode!

One of my favorite things to do is staging a few lines from a changed file, rather than the entire thing. That's a real hassle in the CLI but an absolute joy using VSCode.

Command Palette: Command ⌘ + Shift ⇧ + P

This trick is the end all be all shortcut. It lets you access every command possible within VSCode from a fast fuzzy-finder search. Type in anything you can think of and it'll show you the commands available.

For example if you type in "File" it'll show you commands to "Copy Path of Active File" and other similar ones.

It'll also show you the shortcut to that command if a shortcut exists. Such that you can use the Command Palette to learn and discover other shortcuts!

It's a shortcut to learning shortcuts!

Easy prototyping

I use this trick a lot when putting together some example code.

I open a new file in VSCode.

Open the Command Palette (described above).

Select "Change Language Mode".

Search for the language I want (most commonly JavaScript).

And then I have a new file that has all the syntax highlighting and completions that I usually expect when coding that file.

Makes it really easy to create a new scratch pad to try out some ideas and still have them look as pretty as the rest of my other files.

Pro: GitHub Pull Requests Extension

This is a bonus tip! This is also an extension, the GitHub Pull Requests extension. It's actually developed by Microsoft itself and under active development which are both great things.

I didn't use this extension for the longest time and then one day I gave it a try and oh man...I wish I had tried it out a long time ago.

What this extension makes easy is checking out code from a PR so I can play around with it locally.

This extension actually puts VSCode into 'Review Mode' where you can even add comments to the GitHub PR directly in VSCode! It's incedible!

And when you're done all you have to do is hit 'Exit Review Mode' and you're back to where you started. So cool!

Get Practicing!

All these tricks require practice for you to become an expert with them.

Take one or two tricks at a time and try them out. See if you can get them to become muscle memory so that you start relying on them without even realizing it.

Once you got that shortcut under control then move onto another one.

These shortcuts are half the reason I enjoy using VSCode so much. I'm actually able to control it and have it do what I want with as minimal effort as possible.

I'm always on the hunt for more shortcuts or pro moves! I'm curios to hear what your VSCode pro moves are! Tweet at me or add a comment down below!

Happy VSCoding!

Why Is React Concurrent Mode Exciting?

Sun, 27 Oct 2019 00:00:00 GMT

A guide for non-React engineers.

Last week the React team released an experimental version of Concurrent Mode to the public. It's been in development for over a year and the React community has been very excited about its release.

What is Concurrent Mode? The documentation pages has a nice and concise description:

Concurrent Mode is a set of new features that help React apps stay responsive and gracefully adjust to the user’s device capabilities and network speed.

However if you don't know how Concurrent Mode works or what it actually lets you do you may be left wondering, "Why all the excitement?"

If that's you then this blog post is for you.

The Problem Is Being In Sync

Most (perhaps all?) UI frameworks today synchronously update the browser.

Which means that when you render a list of items, the UI framework applies those changes to the screen all at once. Nothing else on the page can do anything until the UI framework is done rendering those items. If you have 1,000,000 items to render on the screen you're going to have to wait until all those items are rendered and shown before you can do anything else.

However let's say you have a filter on that same page. Where someone can filter that list of items. That person cannot type in that input box until your list of 1,000,000 items has finished being rendered.

I'm sure you've encountered this in the past. It makes for a very unpleasant user experience. The easy fix is to debounce the user input, but that still doesn't reduce the time it takes to render 1,000,000 items.

With Concurrent Mode React has the ability to pause the rendering of 1,000,000 items and update the input filter.

This lets the user type as much as they want in that input filter and not have to wait for 1,000,000 items to be rendered on the page.

This lets the browser feel more responsive and gives the user a much better experience. There's no longer any lag to show the user what they are typing in. React can jump inbetween rendering the input filter and the 1,000,000 items and never leave the user wondering why the browser seems to be locked.

This is what Concurrent Mode enables.

How is this even possible?

Concurrent Mode is difficult to understand. It does complex things and as a result is a little complex to understand.

I'm intentionally not including code examples in this post as I want to focus on the theory. If you are interested in what React Concurrent Mode looks like in code then please check out the docs pages.

The React documentation about Concurrent Mode uses version control as a metaphor. I think this is a great metaphor to help understand how Concurrent Mode works.

However I'm going to give you another explanation. The more, the better!

Concurrent Mode let's React do two things at once (hence the word concurrent). The thing that React is primarily focused on is rendering UI to a page. So, with Concurrent Mode, React can now do two renders at once.

Having the ability to do 2 renders at the same time unlocks a whole world of possibilities.

Let's say you're on my blog's home page. There's a button on there that lets you open and close my list of posts.

You then click to my About page. The About page has text, a picture of me, and it makes an API call to fetch my latest tweets.

Without Concurrent Mode React has no choice but to immediately show the About page. This is going to show the text immediately but it will take some time for the image to load and the API call to complete. So you sit on the About page and things incrementally jump into place. This is how most UI frameworks behave nowadays.

With Concurrent Mode React can start to render my About page in memory and while rendering my Home page and not show it to the user. React can wait for the image to load and the API call to complete, and when that is all done, show it all at once to the user.

The user never sees things load incrementally, it just sees a page all at once. It gives a feeling of responsiveness and speed.

Even more exciting is that Concurrent Mode lets you control how the About page is shown.

Let's say the API call is the slowest part of the entire page. Rather than wait for every piece of data to complete we can tell React to render the About page as soon as we load the image. That means we can show the user the page as soon as our most important data is available, and then only show a loading indicator for the tweets section.

Concurrent Mode lets you control what parts of a page are required and what parts can be deferred. As the data requirements for a page grow in complexity Concurrent Mode lets you take back control of how your page is rendered.

This is what is exciting about Concurrent Mode.

What else can I do with Concurrent Mode?

With Concurrent Mode you can control how React uses its ability to render two things at once.

Let's say you have a page that uses two different API calls: loadUser and loadUserFriends.

We know that loadUserFriends is a slower API. With Concurrent mode we can decide how we want React to render the page.

Should it wait for both API calls to complete before rendering anything? Or should it wait for the API calls independently, rendering UI when each API call completes?

Furthermore imagine we had a loading spinner for each part of this page. With Concurrent Mode you can control when and how those loading spinners are rendered on the page. Perhaps you only want to show 1 loading spinner. This is possible with Concurrent Mode.

Do you need Concurrent Mode?

No. You really don't. Most applications won't need Concurrent Mode. It's far and above an advanced feature of React, one created and driven by the needs of Facebook itself.

Yet like all things the React team developed this feature in a way that it could be used by the entire React community.

Such that if you want these types of features you can have them.

There is no rush to immediately adopt Concurrent Mode. It won't magically transform a React app to become great.

However it is a powerful way to control how your React application handles asynchronous tasks and renders UI.

It's available if you so desire.

Random Questions You May Have

Can you do the things you described without Concurrent mode?

Yes, you can! However it's hard, tricky, error prone, and I'd argue impossible to scale. With Concurrent mode these behaviors become built-in to how you write your React app. You're working with the framework rather than around the framework.

Do you have to use Concurrent Mode?

Nope! Feel free to never ever worry about it. Just like React Portals it's available if you need it.

Wrap Up

Personally I'm looking forward to playing around with Concurrent mode. I love what capabilities it unlocks.

The ways in which I can create my React apps are now more flexible and expressive. Perhaps even more fun?

It will be very exciting to see how Concurrent Mode evolves over the next couple of months. I can't wait to get involved.

Video

I've made a more in-depth look into what Concurrent Mode is on my YouTube channel. If you want a bit of a deeper dive then have a watch below!

React Alicante 2019

Sun, 20 Oct 2019 00:00:00 GMT

On September 27th, 2019 I gave a conference talk in Alicante, Spain at React Alicante 2019.

Believe it or not this was my first true conference talk of 2019! What fun!

Had a great crowd show up for my talk. It was in the middle of the morning on the first day which turned out to be a great time to get high attendance.

My talk was called Evergreen Legacy Applications, here was the summary:

While most of the world is excited about all the newest and coolest technologies you’re stuck maintaining a legacy application. It’s not glamorous, but it works and pays the bills. What if you could have the best of both worlds? Keep your legacy application and use the latest and greatest tools? This dream can be your reality. I’m here to share some of the techniques, ideas, and code I’ve used to make this dream come true. While the task may seem daunting, if you come to this talk you’ll learn strategies you can use to slowly migrate your legacy application to become evergreen.

It was largely about my experience migrating the MongoDB Atlas application from Backbone.js to React over the past 3 years. A lot of fun!

Here are the slides of the talk.

Here is the video of the talk so you can relive it in all its glory!

Guest on FreeCodeCamp Podcast

Mon, 07 Oct 2019 00:00:00 GMT

Recently I was a guest on freeCodeCamp's Podcast!

I had a lot of fun chatting with Abbey, the host, who asked wonderful questions that let me talk at length about my career.

There's a wonderful blog post up about the contents of the episode if you want to read the cliff notes, but to get most of the meat definitely tune in and listen.

Here's a direct link to the episode.

How To useContext With useReducer

Sun, 19 May 2019 00:00:00 GMT

Welcome back to the last installment of our mini-course on useReducer!

If this is your first time here I recommend you check out the first two posts in this series:

Today's post rounds out this trilogy. Today we learn about useContext, and how it makes your usage of useReducer flexible for any size application.

useContext is of course the React Hook way to consume React Context. It's a way to share data to any descendent component without having to manually pass the props through every intermediary component. Sometimes known as prop drilling.

Before we get too far into the weeds I want to let you know this blog post is also in video form. Have a watch if you prefer that format.

Also all source code is available on GitHub.

Why do I need Context?

The React docs have a wonderful and succinct explanation:

Context provides a way to pass data through the component tree without having to pass props down manually at every level.

Example usually help me understand things best. Notice in this example how we have to pass both dispatch and isLoggedIn to TodoPage so that it can then in turn give it to each TodoItem.

What's unfortunate about this is that TodoPage has no need for dispatch or isLoggedIn. The only reason it's being given those values is so it can pass it along. This is props drilling.

export default function App() {
  const [state, dispatch] = useReducer(loginReducer, initialState);
  const { todos, isLoggedIn } = state;
  return (
    <div className="App useContext">
      <TodoPage todos={todos} dispatch={dispatch} isLoggedIn={isLoggedIn} />
    </div>
  );
}

function TodoPage({ todos, dispatch, isLoggedIn }) {
  return (
    <div className="todoContainer">
      <h2>Todos</h2>
      {todos.map(item => (
        <TodoItem
          key={item.title}
          dispatch={dispatch}
          isLoggedIn={isLoggedIn}
          {...item}
        />
      ))}
    </div>
  );
}

function TodoItem({ title, completed, dispatch, isLoggedIn }) {
  const isLoggedIn = true;
  return (
    <div className="todoItem">
      <p>{title}</p>
      <div>
        <input
          type="checkbox"
          checked={completed}
          onClick={() => {
            if (!isLoggedIn) {
              alert('Please login to click this!');
            }
          }}
          onChange={() => {
            if (isLoggedIn) {
              dispatch({ type: 'toggleTodoCompleted', payload: title });
            }
          }}
        />
      </div>
    </div>
  );
}

How Context Helps

Context removes the need for us to pass props to components that don't need it. It essentially lets some parent component expose a value to any descendent component. The big thing about context is the descendent doesn't have to be an immediate child, it can be as deep in the React component tree as you like.

This is essentially the third way you can store and share data in React. There's state, props, and context. Context isn't something that you should feel the need to use frequently, however knowing it exists, and knowing why you might want to use it, is extremely valuable to have in your toolbox.

How to Create a Context

There is one way to create a context in React. It's via the top-level React API:

const MyContext = React.createContext();

The object given back has two properties on it, MyContext.Provider and MyContext.Consumer.

MyContext.Provider is how you establish the root of a context environment. It's what allows any descendent component to consume the data stored on the context. It accepts one prop value and that is what context consumers can access.

const MyContext = React.createContext();

export default function App() {
  const [state, dispatch] = useReducer(loginReducer, initialState);
  const { todos, isLoggedIn } = state;
  return (
    // Note: This current way of exposing these values can lead to unexpected bugs.
    // We'll talk about this later in the post why writing `{state, dispatch}` can
    // lead to performance issues.
    <MyContext.Provider value={{ state, dispatch }}>
      <div className="App useContext">
        <TodoPage todos={todos} dispatch={dispatch} isLoggedIn={isLoggedIn} />
      </div>
    </MyContext.Provider>
  );
}

How to Consume Context with Hooks

There are actually three different ways you can consume a context in React. For the purposes of this blog post I'm only going to discuss how we do it with Hooks.

There's a built-in Hook provided by React called useContext that allows any descendent component to gain access to the value on a Context Provider. It also subscribes the component that uses useContext to be re-rendered anytime the value of the context changes.

useContext takes in one argument which is the object that's returned when we originally called React.createContext. This tells React which context value we want.

function TodoItem({ title, completed }) {
  const { state, dispatch } = useContext(MyContext);
  const { isLoggedIn } = state;
  return (
    <div className="todoItem">
      <p>{title}</p>
      <div>
        <input
          type="checkbox"
          checked={completed}
          onClick={() => {
            if (!isLoggedIn) {
              alert('Please login to click this!');
            }
          }}
          onChange={() => {
            if (isLoggedIn) {
              dispatch({ type: 'toggleTodoCompleted', payload: title });
            }
          }}
        />
      </div>
    </div>
  );
}

Now TodoItem is getting state and dispatch from Context instead! And if we showed the full example we'd note that TodoApp doesn't need to be given state and dispatch anymore because TodoItem can access it directly from context!

Performance Concerns

Remember how I said to not have that inline object inside the value prop when we called <MyContext.Provider value={{state, dispatch}}>?

The reason for that is that everytime App (which is where MyContext.Provider is being rendered) is re-rendered, it's going to create a new object on the value prop. Which means that any component that is consuming that context will also be re-rendered as well.

We won't be able to rely on only state changing to cause consuming components to re-render, we also have to worry about App re-rendering causing consuing components to re-render as well.

There's two ways to fix this issue.

One is to use useMemo to memoize the value given to the provider:

const contextValue = useMemo(() => {
  return { state, dispatch };
}, [state, dispatch]);

The other is to make two separate contexts and have each provide state and dispatch independently.

const StateContext = React.createContext();
const DispatchContext = React.createContext();

export default function App() {
  const [state, dispatch] = useReducer(loginReducer, initialState);
  const { todos, isLoggedIn } = state;
  return (
    <DispatchContext.Provider value={dispatch}>
      <StateContext.Provider value={state}>
        <div className="App useContext">
          <TodoPage todos={todos} dispatch={dispatch} isLoggedIn={isLoggedIn} />
        </div>
      </StateContext.Provider>
    </DispatchContext.Provider>
  );
}

function TodoItem({ title, completed }) {
  const dispatch = useContext(DispatchContext);
  const state = useContext(StateContext);
}

Why Context Works Great With useReducer

What I find great about using Context with useReducer is that it becomes trivial to allow any descendent component to update state in your reducer.

All you need to expose is the dispatch function and then any descendent function can dispatch anything that it wants. Those state changes are still maintained in the reducer function, keeping that close locality of all state transitions.

Also due to the API of Context you can clearly find which components are consuming the dispatch function, allowing you to retain a clear view of how your data is flowing and changing. This is historically one of the strengths of React and it remains true even when you break out of the state to props paradigm.

Conclusion

Context is not always necessary. However I do think it is important for you to know how to use it, because there are certain occasions where it'll make your life far easier.

If you have some page that has complex state transitions then useReducer is a sure-fire answer.

If you have deeply nested components that have to cause those state transitions then get using useContext.

All together you can make some incredibly powerful components with these two features. I'm excited to see what you dream up.

Level Up useReducer with Immer

Fri, 10 May 2019 00:00:00 GMT

If you're just joining us, this post is an add-on to my Why I Love useReducer post. If you haven't read that already, I recommend you take a second and have a peek before you continue reading this post!

And if you want to skip to the third installment of this trilogy then go ahead and check out How To useContext With useReducer

So, now that we all agree that useReducer is the best thing since the wheel, let's talk about how we can make it even better. I'm talking better than a wheel. Like, individually wrapped slices of cheese better.

One of the things that useReducer excels at is handling complex state tree mutations. If you have a lot of state going on in your component, then useReducer is going to help you wrangle it under control such that you know how your state is changing.

The one gotchya here is that for useReducer to work correctly it requires you return a new instance of state to signal to React that data has changed and it needs to re-render.

What that means is a lot of code in useReducer functions that look like this:

case 'submit':
    // Return a new object, so React knows things changed
    // Which means you have to manually...
    return {
        // Copy over state
        ...state,
        // Set new state value
        isSubmitting: true,
    }

This works fine, however if your state tree gets heavily nested it becomes increasingly more difficult to remember to copy over values when making a new object instance.

case 'addTeamMember':
    return {
        // Copy over root state
        ...state,
        teams: {
            // Copy over teams so we don't just replace it
            ...state.teams,
            [teamId]: {
                // Also copy over this team's data
                ...state.teams[teamId]
                // And then add the new data
                [userId]: newUser,
            }
        }
    }

This level of manually copying over an object sucks.

Luckily there's a library that makes this easy.

It's called Immer and I love it.

Video

FYI this post is also in video form!

See my teach you about using Immer in useReducer, rather than you read these words and teach yourself! Don't put me out of a job, let me teach you! I love to talk, truly!

Source Code

If you want to jump straight to all the code, it's all available on GitHub.

Immer

Immer let's you make immutable copies of objects via a mutable API.

That's my most succinct explanation for what Immer is, and why it's awesome.

Rather than having to deal with immutable data structures (i.e. ImmutableJS) or fancy Babel transforms that deal with ASTs, Immer uses the very neat and clever idea of copy-on-write.

Essentially what that means is Immer tracks every mutable change you're making, and Immer will then replay those changes producing a new immutable copy of your object with all those changes applied.

What's it look like?

Immer has two primary ways of using it.

Function

The most common way of using Immer is via calling its function.

By convention the function is called produce, as it produces the next state.

The first argument to produce is the object you want to mutate.

The second argument is a function that is called with that same object you want to mutate, except it's been modified slightly by Immer. It's actually been wrapped in a Proxy so that Immer can track all the modifications you make.

When your function finishes, Immer will go through all the changes you created, re-apply them to your original state object in an immutable manner, and produce your new immutable object.

import produce from 'immer';

const state = {
  team: {
    teamFoo: {
      harry: {},
    },
  },
};

const newState = produce(state, draft => {
  draft.team.teamFoo.matthew = {};

  draft.team.newTeam = {
    joel: {},
    adam: {},
  };
});

newState is a new object with all those changes applied.

Curried

The curried API Immer inverts the arguments (as most curried APIs do). Rather than the first argument being the object you wish to modify, it becomes the function that tells Immer how you want to modify the object.

What Immer returns then is a new version of your update function that is wrapped in the produce function.

Taking the example from above

function updater(draft) {
  draft.team.teamFoo.matthew = {};

  draft.team.newTeam = {
    joel: {},
    adam: {},
  };
}

const curriedUpdater = produce(updater);

const state = {
  team: {
    teamFoo: {
      harry: {},
    },
  },
};

const newState = curriedUpdater(state);

That curriedUpdater function is roughly equivalent to:

const curriedUpdater = (state, ...args) => {
  return produce(state, draft => {
    updater(draft, ...args);
  });
};

Such that you can now call curriedUpdater and it'll automatically wrap the original updater function with produce so that all mutations produce immutable copies.

Use Immer with useReducer

So how does this apply to useReducer?

As we already saw above we have to make deeply nested changes to our state objects so that React knows it should re-render.

We saw that ugly example of copying over state above.

case 'addTeamMember':
    return {
        // Copy over root state
        ...state,
        teams: {
            // Copy over teams so we don't just replace it
            ...state.teams,
            [teamId]: {
                // Also copy over this team's data
                ...state.teams[teamId]
                // And then add the new data
                [userId]: newUser,
            }
        }
    }

How does that look like using Immer?

case 'addTeamMember':
    return produce(state, draft => {
        draft.teams[teamId][userId] = newUser
    });

Just a little easier.

Curried useReducer Reducer Function

And if we use the curried API from Immer we can easily have our entire useReducer reducer function leverage the powers of Immer:

// Calling first argument draft instead of state as it's the immer draft object.
function reducerFunction(draft, action) {
  // reducer code goes here.
}

const curriedReducerFunction = produce(reducerFunction);

useReducer(curriedReducerFunction, initialState);

Everytime useReducer runs it will call curriedReducerFunction with the current state and the action object.

However since we provided the curried function that means immer will run before it makes its way to our actual reducerFunction, such that all the reducerFunction ever gets is the draft object from Immer!

Did you level up?

One thing to keep in mind before you go around converting all your reducer functions to use Immer is that you don't always need Immer. If you have a shallow object then copying over state yourself is perfectly fine.

In fact I'd encourage you to only reach for Immer if you have a deeply nested and complex object. That's where the benefits of Immer truly come into play. That's where it'll help you write more maintainable and bug-free code.

Don't rush to use Immer, know when it's appropriate to reach for this powerful tool.

However when you do use Immer I think you'll have a great time. It makes state updates easy and clear to any reader what you're doing.

Also you don't have to worry about forgetting to copy over state anywhere, Immer will handle that all for you.

Immer is actually better than both the wheel and individually sliced cheese. It's so good it's just like an individually wrapped cheese wheel.

Why I Love useReducer

Fri, 03 May 2019 00:00:00 GMT

This post is the first of a trilogy. Check out the other two posts as well:

I didn't realize until recently how much I loved the React Hook useReducer. It's one of those advanced hooks, and while I read the documentation about it and already have a good amount of experience with Redux, it took a little while for me to fully understand just how powerful useReducer can make your components.

I made a video about this. To show my love for useReducer. I encourage you to take a watch. The first 10 minutes are me setting the scene. Together we're building a pretty generic Login Form, one that has been written countless times. In the first half of the video I make the component using multiple useState calls, as I normally would with a React Class Component.

Then at around the 11 minute mark I start migrating my code to use useReducer instead - and the fireworks fly!

All source code is available on GitHub.

Why do I love useReducer?

The simple answer is that it lets you separate the What from the How. To expand upon that, it may be that What a user wants to do is login.

With useState when a user wants to login I create function that handles a lot of the How. How my component has to behave when a user wants to login:

Sets loading to true
Clears out old error state
Disables the button.

With useReducer all my component has to do is think about What the user wants. Which is:

dispatch('login')

After that all the How is handled inside the loginReducer function.

Furthermore, any future How questions become completely centralized inside of that one loginReducer function. My component can just keep on thinking about the What.

It's a subtle distinction but an extremely powerful one.

To further show the point you can check out the full source code here or see these inline examples.

I'm going to ignore showing the UI, if you want to see that you can check out the repo. For now I just want to focus on the data we're storing and updating.

Using useState

Here I have 5 calls to useState to manage all the distinct state transitions.

In my onSubmit call I have to careful orchestrate all the state changes that I want.

They're tightly coupled to the onSubmit handler and awkward to extract.

function LoginUseState() {
  const [username, setUsername] = useState('');
  const [password, setPassword] = useState('');
  const [isLoading, showLoader] = useState(false);
  const [error, setError] = useState('');
  const [isLoggedIn, setIsLoggedIn] = useState(false);

  const onSubmit = async e => {
    e.preventDefault();

    setError('');
    showLoader(true);

    try {
      await login({ username, password });
      setIsLoggedIn(true);
    } catch (error) {
      setError('Incorrect username or password!');
      showLoader(false);
      setUsername('');
      setPassword('');
    }
  };

  return; // remaining UI code here
}

Using useReducer

While it may be overall longer, I would argue that it's much easier to read and track what's going on.

If you jump straight to the onSubmit function I can now clearly show the intent of the user. There's only 3 behaviors that can happen, 'login', 'success', and 'error'. What that means is not a concern of my component, it's all handled in the loginReducer.

Even better, it becomes easier for me to make wide-ranging changes to state changes because all the state changes are centrally located.

And even more exciting is that all state changes become easy to share by default.

If I want to show my error state from elsewhere in the component I can easily re-use the same dispatch({ type: 'error' }) and I'm good to go.

function LoginUseReducer() {
  const [state, dispatch] = useReducer(loginReducer, initialState);
  const { username, password, isLoading, error, isLoggedIn } = state;

  const onSubmit = async e => {
    e.preventDefault();

    dispatch({ type: 'login' });

    try {
      await login({ username, password });
      dispatch({ type: 'success' });
    } catch (error) {
      dispatch({ type: 'error' });
    }
  };

  return; // UI here
}

function loginReducer(state, action) {
  switch (action.type) {
    case 'field': {
      return {
        ...state,
        [action.fieldName]: action.payload,
      };
    }
    case 'login': {
      return {
        ...state,
        error: '',
        isLoading: true,
      };
    }
    case 'success': {
      return {
        ...state,
        isLoggedIn: true,
        isLoading: false,
      };
    }
    case 'error': {
      return {
        ...state,
        error: 'Incorrect username or password!',
        isLoggedIn: false,
        isLoading: false,
        username: '',
        password: '',
      };
    }
    case 'logOut': {
      return {
        ...state,
        isLoggedIn: false,
      };
    }
    default:
      return state;
  }
}

const initialState = {
  username: '',
  password: '',
  isLoading: false,
  error: '',
  isLoggedIn: false,
};

Think like the user

useReducer gets you to write code the way a user will interact with your component.

You are encouraged to think in the What and centralize all How questions inside the reducer.

I'm so excited useReducer is now built-in to React. It's one more reason why I love it.

What is React Ink?

Sun, 14 Apr 2019 00:00:00 GMT

The first time I learned about React Ink I was immediately intrigued. A project that lets me take all my React knowledge and use it to make a CLI program? Sounds great to me!

In this video we'll explore what React Ink is and what you can do with it. We'll get up and running from a blank project and get our own React Ink project working locally.

However, I know some people prefer to read rather than write, so for all of you that prefer to use your eyes, keep on reading.

Or if you prefer to just see the code, then by all means click on through.

What is React Ink?

React Ink lets you write CLI programs using React. That's the most "to the point" explanation that I can come up with. However let's delve into what that means.

If you're writing a regular website with React you need to use two things: React and React DOM. Often these two things are conflated because 99% of the time you're using them together without realizing it. However there is an important distinction between these two libraries (and yes they are two separate npm packages).

React is the package that you use to write React Components. The components you write with React describe what they do and how they look. You can make a custom Button component and that can be reused in any of your other components. You can listen to lifecycle hooks and react to updates.

React DOM is how your React Components come to life. It's the library that translates your abstract descriptions of your React Components into actual DOM elements in a browser. In React ecosystem parlance it's called a 'renderer'. There are many renderers for React. React DOM is one. React Native is another. It'll take your React code and then render it into a native app.

React Ink is also a renderer. It'll take your React Components and render it into a terminal. Granted, you need to use the components that React Ink provides, so that the React Ink renderer knows how to transform that into a CLI, but this separation of concerns, of describing your application (React) to then rendering your application (React DOM / React Native / React Ink) is one of the fundamental strengths of the React architecture.

What does React Ink look like?

React Ink comes with a few built in components that let you create your CLI program. You can see the full list here but let me highlight a few of the ones that I've played around with:

Box

Essentially a <div /> for the CLI. It lets you position elements in your terminal to make your CLI program look as pretty as possible.

You may wonder how you actually handle layout in a CLI if there's no CSS? Well Box supports properties that let you control layout. Props such as height and padding and all related flex properties. Essentially anything you'd need to create a layout Box should have you covered.

Color

A CLI is boring if it's all white text on a black background. Luckily the Color component lets you add some flair to your CLI. Via some props you can make an otherwise boring CLI look pretty with shades of blue.

<Color rgb={[255, 255, 255]} bgKeyword="magenta">
  I am pretty!
</Color>

Everything else

This is just a very small sample of what Components are availabe for your use.

And if that's not enough you can always write your own custom Ink Component. There's already a handful available in the community and it's never too late to create your own.

It's Just React™

Outside of having to use React Ink Components, everything else is just React. Which means you can use Class Components with state or Function Components with Hooks. You can use Fragments and you can use regular event handlers. It's Just React!

For example there's a text input component. If you want to get input from someone in the CLI this is how you'd do it:

import React from 'react';
import { render, Box } from 'ink';
import TextInput from 'ink-text-input';

class Greeting extends React.Component {
  state = {
    name: '',
  };

  onChange = name => {
    this.setState({ name });
  };

  render() {
    return (
      <Box>
        <Box marginRight={1}>
          <Color blue>Hello!</Color>
          What's your name?
        </Box>

        {this.state.name ? (
          <Color green>Hello {this.state.name}</Color>
        ) : (
          <TextInput value={this.state.name} onChange={this.onChange} />
        )}
      </Box>
    );
  }
}

render(<Greeting />);

Looks just like a React app doesn't it?

Wrap-up

This is just the beginning of exploring what you can do with React Ink.

This is also why I love React. It lets you take all your current React knowledge and apply it in an entirely new context. It really lets React stay true to its mantra of being a framework that you learn once, write everywhere.

If you've ever tried to write a nice CLI yourself you know that it's not a pleasant experience. Adding React into the mix suddently makes it fun again. I'm very excited to see what you come up with!

Setting Up TypeScript

Sun, 10 Mar 2019 00:00:00 GMT

Now that we've gotten a nice and easy introduction to what TypeScript is we can start talking about how to code with TypeScript. Specifically how to get our local dev environment set up so that we can actually write TypeScript code. That means getting TypeScript to compile and type check on our local machine.

I'm not going to go into how TypeScript works yet - that'll be covered in a future blog post. This is in many ways the pre-requisite to that eventual guide on how to write TypeScript code. I feel it's important that we have our dev environment set up correctly so we can validate that we're writing correct TypeScript code.

You can consume this content in two glorious ways. In video form, which I must admit will be rife with great humor and dazzling visuals, or you can consume it the way of cave men: with scratches on a wall. To which I mean in written form.

There's two parts to this blog post because there's two ways you can compile TypeScript code.

The first is with the official TypeScript CLI tsc. That's the path most new TypeScript projects follow. It provides transpiling and type checking, making it an all in one solution that is easy to get up and going with.

The other is with Babel. Starting with version 7 of Babel there is now a plugin that adds support for transpiling TypeScript code with Babel. The one caveat is that Babel only does the transpiling, it doesn't check types at all. To still get the full TypeScript experience you'll still need the official TypeScript CLI and use it for type checking your code.

With TypeScript's CLI

First thing we need to do is get ourselves the tsc program installed. Let's let our favorite package manager handle that for us:

npm install -g typescript

This will install cli globally making it available to compile TypeScript anywhere on our system.

Let's write our first (basic) TypeScript file so we can start playing around with tsc. Let's name this file greeter.ts.

// greeter.ts

function greeting(name: string) {
  console.log(`Hello ${name}`);
}

greeting('YouTube!');

greeting('1');

From here we can quickly transpile that code via:

tsc greeter.ts

You should see a new file added in your directory called greeter.js. If you peek inside it you'll see that TypeScript transpiled your code! Great success transpiling your first TypeScript file!

If you want you can take this a little further and make a TypeScript project. You can create a tsconfig.json file which controls the behavior of TypeScript, allowing you to customize its behavior for your projects needs.

The best way to create that file is via

tsc --init

This creates a great starting tsconfig.json file with sensible defaults and inline comments for every configuration. One that I enjoy changing is the target setting.

Try changing target to es2015 and then re-run tsc. If you want to use your tsconfig.json file then you can just run tsc by itself and it'll auto find the configuration file.

Did you notice the compiled output changed? It kept the template string this time! That's because we're now targeting an environment of es2015 which has support for template strings, so TypeScript doesn't transiple it away!

With Babel

Getting started with Babel requires a little more work than just using TypeScript. For starters we need more than one npm package. So let's initialize an npm project:

npm init -y

This creates a package.json file and skips all prompts so we can just get on our merry way of installing even more packages!

Then we need to install the Babel CLI and associated Babel TypeScript plugin

npm install --save-dev @babel/core @babel/cli
npm install --save-dev @babel/preset-typescript

We need to tell Babel to use our plugin. The best approach for that is with a .babelrc file. Create a .babelrc file and put the following inside:

{
  "presets": ["@babel/preset-typescript"]
}

And now we can finally compile our TypeScript file!

npx babel --extensions ".ts" greeter.ts -d dist

This uses npm's npx feature which lets us easily call into CLI programs installed within node_modules. We need to tell Babel that we want it to also check .ts extensions which is where we wrote our TypeScript file.

With that you should see your transpiled greeter.js file made with some pretty JavaScript inside! Yay!

Note that Babel does not do any type checking. It just transpiles. To do type checking you'll need the tsc CLI as described above.

In this situation, when used with Babel you may want to turn on the noEmit configuration for TypeScript. This tells TypeScript to not output any files, and just let it focus on doing type checking.

What is TypeScript?

Mon, 18 Feb 2019 00:00:00 GMT

TypeScript is probably the best way to add static typing to JavaScript. That's probably all that people really know about TypeScript though - that it adds static types. I like to delve a little deeper into a topic before I start to learn it, so I figured I'd take you along for the ride.

Check out the video for all the details, or read about the highlights from the video below.

It's a strict syntactical superset of JavaScript.

Why does this matter? Because any JavaScript application automatically becomes a TypeScript application.

Anders Hejlsberg is the lead developer of TypeScript. This matters because he knows a thing or two about writing a programming language, having created C#, Delphi, and Turbo Pascal. So, he knows a thing or two about how to make a programming language.

TypeScript was first made public in October 2012, which was far earlier than I had ever imagined.

TypeScript is by no means the first static type checker for JavaScript.

Google Closure Compiler was probably one of the first ones. It was released all the way back in 2009. It's method of adding static types was via JSDoc comments. As you annotated code with JSDoc comment blocks the Closure Compiler parsed it and imbued your code with static types. Closure Compiler is still developed and used, however mostly internally to Google.

Flowtype is another popular static type checker. Created by Facebook, it adds static type information via inline annotations (similar to TypeScript). It's not as popular or widely used in the open source community as TypeScript.

Why TypeScript?

So we talked about what is TypeScript, but now let's talk about why you should consider using TypeScript.

I delve into more detail in the video but here are the bullet point reasons:

Due to types being checked at compile time, and due to the fact that type information is in many ways documentation, TypeScript effectively provides code enforced documentation. For that reason alone you should try out TypeScript.
Great developer experience via great IDE support. In particular the experience of writing a TypeScript application with VSCode is almost as good as a Java IDE.
Helps maintain a large application across a large team.
It's definitely the market leader right now in terms of static type checkers. This should provide a sense of calm that your investment in learning won't be wasted.
They’re very good with community feedback.
They publicize and follow a Public Roadmap so you know what they're going to work on next, and when you should expect it.
Monthly release cadence.
Framework support: Angular, React (with JSX), Vue.js, and all others.
It fully supports the ability to incrementally migrate a JavaScript application to a TypeScript application.

Preview of the JavaScript Ecosystem in 2019

Sat, 09 Feb 2019 00:00:00 GMT

I’m not really in the business of telling the future however I do think it would be fun to mirror all of my year in review posts with one that looks forward to the year to come.

There’s a lot of new things I’m very excited about this coming year. I don’t know when I’ll be able to lay my grubby hands onto all these new shiny things but I can tell you that I’m practically drooling at all the exciting new things that are coming in 2019.

There’s a whole range of new things happening this year. From JavaScript frameworks, to CSS advancements, to general ecosystem trends. All of them are exciting and further proof that there’s no better time to be a JavaScript developer than today.

What follows is a preview of things to look forward to in 2019.

React

Every year I think that React has peaked and every year I’m proven wrong. 2019 is shaping up to be one of the most monumental years of React since the deprecation of React.createClass in favor of classes.

How is React going to disrupt classes? By going to functions of course. That’s why React Hooks are such a big deal. While the React team has no current plans to deprecate classes, by introducing Hooks they are laying the groundwork to enable a future where React is no longer dependent on class Components. It’s kinda wild to see this full circle of changes coming to fruition. From a JS object, to class, to function. Maybe next year the React team will migrate from functions to using RegEx’s as how a component is defined (that’s a joke, to be clear).

The React team laid out their roadmap for upcoming React features in 16.x and the entire post is worth a read. There’s large changes coming, all of which is going to vastly change (for the better!) the way people write their applications.

The biggest one I’m excited about is Suspense for Data Fetching. This feature solves a long-standing hole in functionality that Redux tried to solve many years ago. It answers the question of “How do I load async data in React and make it accessible throughout my entire application as easy as possible?” Suspense for Data fetching answers that question and provides a solution that is as clever as it is naughty. You may have heard stories about how React is throwing Promises…well that’s to achieve the goals in this feature.

Vue.js 3.0

I don’t personally use Vue.js however I admire the framework and the smart work that has been put into making it accessible to all skill levels while also being as flexible as possible.

The Vue.js team is kicking it up a notch this year with Vue.js 3.0. This blog post is all the details I currently know about Vue 3.0, however if all the promises are delivered then Vue 3.0 is going to be one incredible framework.

One of the big things I love about Vue.js is they unabashedly incorporate the best ideas from peer frameworks into Vue.js in a way that feels natural to a Vue.js engineer. Vue 3.0 seems to be continuing this great tradition but kicking it up a notch.

When Vue.js 3.0 is released I’m going to play with it immediately. It sounds very exciting and I love seeing how different people solve the same problem. That problem being: how do you make UI development easier? Vue.js has its eye on the prize.

CSS

Welcome to the unsung hero of the internet, CSS. I predict big things for CSS in 2019.

The first is the continued growth and usage of CSS in JS, led in large part by styled-components and emotion.sh. I honestly never tire of the Twitter debates about the merits of CSS in JS (it’s nuanced!) but I do predict continued momentum for CSS-in-JS usage. Why? They solve a pain point that vanilla CSS has no current solution for. Namely the C in CSS. That cascade is hard to wrangle, especially amongst a large team. CSS-in-JS is the cascade-wrangler.

If you follow my YouTube videos you’ll know that I’m long been very excited about CSS Houdini. The easiest way to explain it is that it is what Babel is to JavaScript - a way to allow developers to use advanced CSS features today. It does this via creating new APIs that let UI engineers control and alter how CSS behaves on your page.

CSS Houdini is itself a project that encompasses many different APIs. One of them, the one I’m most excited about, is called the Layout API. The Layout API exposes API methods that allows developers to customize how content is laid out on the page. You know how we have display: block and display: flex? The Layout API lets you create your own custom display: magic and you define its behavior. Very very exciting stuff.

Last piece of CSS prediction is that 2019 will finally be the year that CSS Grids take off. It’s been a couple of years that CSS Grid has been available and the browsers that support CSS Grid have now had a chance to spread across the internet. Such that, this is the year where it finally becomes safe and exciting to start using CSS Grid in production. I myself need to learn more about it as it’s a very exciting piece of technology. If you only support evergreen browsers and not IE then CSS Grids is ready for the big time!

Webpack 5

Seems like Webpack has a major release every year, which is quite the lovely release cadence. This year is no exception with the first Webpack 5 Alpha already released and feedback is being solicited.

The marquee feature in Webpack 5 is persistent caching, a feature I’ve long been excited about. The gist of this feature is now, when you kill Webpack and start it back up, it won’t have to restart all of its work. It can pick up where it left off as it saves its state to disk, ready to be used next time.

Also it’s great to see such a depended on piece of technology be even and measured with their release cadence. If we had a new Webpack version every month I don’t think that would be good for the wider JavaScript ecosystem at all.

TypeScript

TypeScript’s popularity has started to seriously increase in the past couple of months. In particular, January 2019 seemed to be the month of TypeScript - it was all that people seemed to be talking about.

I predict this to be a big year for TypeScript as we see it continue to assert its dominance as the defacto language to use if you want types in JavaScript. Flow squandered any competitive advantage they had by not being good open source participants, leaving the door wide open for TypeScript to take the lead.

What’s great about an increase in TypeScript popularity is how it’ll have a knock on effect for VSCode. VSCode (my editor of choice, my editor of love) derives a lot of its functionality from leveraging TypeScript under the hood. As TypeScript continues to grow and mature it’ll simply make VSCode better as well.

I expect VSCode to grow its feature set, racing for feature parity with a typical IDE however never lose its text editor feel. That’s the combo that I yearn for. Simple feel of a text editor with all the bells and whistles of a fancy IDE. I think VSCode has a great shot to obtain that complex middle ground, and this year will see great growth toward that end.

ReasonML

ReasonML is another compile to JavaScript language, albeit one that is a little less familiar than TypeScript. It’s a language derived from OCaml that through the ingenuity of a project called BuckleScript can compile ReasonML code into JavaScript code.

It’s still very much early days for ReasonML, with 2018 being a steady year of growth for early adopters. 2019 might prove to be a bigger year for ReasonML, albeit one that isn’t explosive. It’s still a niche, but one that I predict will have some respectable growth.

The bigger story to me with ReasonML is how it can compile to native code. ReasonML is built on top of OCaml, which already can compile to native code, and there’s already some very exciting projects that are in the works. Also due to ReasonML’s syntax trying to mirror JavaScript as close as possible, it makes for a potentially very powerful combination. One such project is called Revery, which is trying to fashion itself an Electron toolkit - I.e write ReasonML code and then create a native app. Very exciting things.

Node

2019 is going to be a turning point for Node. Two big things are brewing for Node.

The first is native ES Modules support. There’s currently support for ES Modules in Node behind a feature flag and requiring a file extension of .mjs. I’m not the biggest fan of this restriction and there’s many in the community who feel the same way. I hope that this year Node is able to make solid progress on its ES Modules story, paving the way for stronger unification of Node and JavaScript. I’m not very hopeful it’ll happen in 2019, as there’s a lot to consider and work through, but I anticipate good progress to be made in 2019.

Another very interesting trend I predict happening in 2019 is multi threaded Node applications. Worker Threads is a brand new module available in Node 11, and once it makes it way to Node 12 (a LTS release) I can’t wait for the first multi-threaded Node app to be released.

Historically Node apps have been good for non-CPU bound use cases. This is due to the JS run time loop and not having any way to offload CPU intensive tasks to a separate worker thread. Well with this new module that is no longer the case - we’ll be able to easily spin out a new thread to take care of whatever task we need.

This small addition is going to have a large ripple effect across the Node ecosystem, opening up a whole new range of applications. I’m very excited about it.

To round out this Node prediction section I want to mention an upcoming project named Deno. Created by Ryan Dahl, the original creator of Node.js, Deno is in many ways his second attempt at a server-side JavaScript runtime.

Deno has TypeScript built in and ES Modules built in. It has a different approach towards handling dependencies, and it’s written in Rust. It’s a project I have my eye on, and I’m very curious if its popularity will grow.

Node is so entrenched at this point that I find it very doubtful that Deno could supersede Node, but competition is always good. Maybe it’ll force Node to gets its ES Modules story figured out.

npm & Yarn

2019 is going to be the year of the package manager revolution. Both npm and Yarn have huge plans on how to take their projects to the next level and they’re both very exciting.

npm is working on Tink, a reimagined approach to how dependencies are installed. The high level thought is that instead of re-installing the same package in all your applications and putting it into separate node_modules folders, Tink aims to have a global cache and link up those packages and versions into the node_modules folder of your application. This has the aim to drastically improve installation speed and decrease the size of your node_modules folder.

Yarn recently laid out their 2.0 roadmap and it’s audacious, to say the least. Yarn seems to want to become a package manager platform, with enough flexibility to support installing packages across languages, not exclusive to JavaScript. Imagine installing dependencies with Yarn for a PHP app. Wild!

These two plans predict big things for package management in the JavaScript in 2019. I can’t wait to start playing with these two things. I can only imagine the amazing lift in developer productivity they’ll bring.

GitHub

Here’s an interesting one for you - I predict that Microsoft’s purchase of GitHub is going to be a huge boon to the development and feature of GitHub.

The purchase of GitHub has blessed them with one amazing gift: no longer having to worry about how to make money. Now that Microsoft has removed the need for GitHub to internally find how to become profitable, GitHub can instead focus on what it does best: product.

We’re already seeing this bear fruit with small UI and UX tweaks in the past few months. The sticky bar on PR review pages, new dashboard page. I’m sure these were under development before the Microsoft purchase, however now there’s less that GitHub has to juggle.

GitHub is going to get great in 2019.

Conclusion

So that wraps my predictions for the JavaScript ecosystem in 2019. It’s never been a better time to be a JavaScript developer, and it’s just going to get better.

It’s also exciting to see the ecosystem mature. Modern Javascript is relatively young compared to other more mature ecosystems (have you seen what a Java IDE can do? Woah!) and now that the initial rush of understanding how powerful JavaScript can be is slowing, we can now focus on making JavaScript more approachable and sustainable.

Top 10 Albums of 2018

Tue, 08 Jan 2019 00:00:00 GMT

2018 was quite the year for me. The biggest and most obvious change was becoming a parent. That was far and above the highlight of the year.

Not only was was becoming a father the highlight of the year but it was also a big influence on my music listening behavior. Namely, it put a bit of a damper on how much music I could listen to. Most of the time was spent listening to lullabies. Or rather, just white noise. Babies sure love white noise. That's their favorite soundtrack. And I heard it on repeat. Most nights. A lot of nights. So many nights. I wish I could get that sleep back.

So having a baby put a bit of a damper on how much music I could listen to. However a second change in my listening habits also had a big influence on how much music I listened to in 2018. That was the increase in how many podcasts I listened to. I quickly fell in love with the Pod Save America, which I listened to almost every day on my commute to and from work. That was my go-to podcast but I also avidly listened to the following podcasts too:

I didn't listen to my own podcast as I felt that was a little too self indulgent, even for my tastes.

The last major change in 2018 for my listening habits was the rise in my usage of Apple Music and its multitude of playlists. Many days I spent listening to one of the many playlists provided by Apple Music, exposing me to many artists and songs but not letting me really sink my teeth into albums as a whole.

That's what I like to write about in these posts. The albums from the past year that I enjoy in whole. The albums that I let play from start to finish and have a great time hearing the full vision of the artist.

Despite those three big changes I still listened to plenty of albums in 2018. This is my list of top albums from 2018.

Top 10 Albums of 2018

10. The Decemberists "I'll Be Your Girl"

I've long been a Decemberists fan. I was even able to see them live when I was in college. I love their mix of indie and folk. The mood they impart on their songs always fills me with love and joy, despite having an odd icy overtone. That ice is probably due to their name, which is hard to shake off.

Their first album since 2014, I had a great time getting to enjoy new Decemberists tunes. It was a solid new foray - not their best, but certainly not their worst. At times a little more alty and rocky than previous albums but still rightly retained their Decemberists sound.

9. Ben Howard "Noonday Dream"

I'm always a sucker for solid singer/songwriter albums. They're great when I get in a slightly melancholic mood, or just need a relaxing record to put on.

Ben Howard creates relaxing and pretty songs with a nice ambient backdrop to a lead acoustic guitar that put me into a calm place that lets me relax when the world starts to race a little too fast for my tastes.

8. Post Malone "beerbongs & bentleys"

My main complaint about this album is that it's too long. It's a sprawling album with 18 tracks, making it a bit of a chore to get all the way through. The first half of the album is packed with stellar tracks, however after that it loses steam.

However there are many breakout tracks. "Paranoid", "Rich & Sad", "rockstar"...most of the first 8 tracks are all tremendous.

A unqiue mix of rap and r&b, I love the unique sound of Post Malone. Except for that second half of the album. Too much.

7. Black Panther The Album Music From And Inspired By

An amazing movie backed by an amazing album. The artists that make up the tracks on this album are all at the top of their game: Kendrick Lamar, SZA, Khalid, Anderson .Paak, just to name a few.

It's an eclectic album that contains many different type of songs but that makes sense given that it's a compendium of different artists.

As far as movie albums go, this is one of the best I've heard in a very long time.

6. The Weeknd "My Dear Melancholy,"

I did not expect a new album from The Weekend. It was just only 2016 that he came out with a very strong album. To have another new album come out - so soon, and with such quality - was a very big surprise.

In all honesty I'd more accurately call this a long EP as it only has 6 tracks. However every track is very strong.

Many of the songs had me easily dancing in my shoes, stretching along with all the high notes hit in the songs.

5. SiR "November"

I don't remember how I found this album but I'm so glad that I did. A wonderful R&B album, full of soul and feeling. It's an album that knows itself with a high degree of comfort and confidence.

The songs sway with confidence and style, lulling the listener to sway along with its vibe as the tracks unfold, one after another.

The songs tell a narrative without being repetitive, staying true to the artists intent, while exploring the range of what SiR has to say.

4. Arin Ray "Platinum Fire"

Another R&B album. It's definitely a new genre that I really enjoy vibing to.

This album closely eked out the #4 spot over #5. Both albums are very solid R&B albums with an artist that knows themself well, however the differentiator for me was the slight increase in replayability that Arin Ray had for me.

The tracks are just as strong as SiR, however Arin Ray has a slightly stronger charismatic pull. The songs reek of his charisma, which provide a strong lure to pull the listener in and get them to keep listening.

I'm curious if these rankings stay true after a year. However for this year Arin Ray takes the higher spot.

3. Khalid "Suncity"

Another artist I was surprised to hear new material from. It was only last year that Khalid released his debut album, and he's back this year with another tight follow up.

Like The Weeknd this could also be considered an EP as it only has 7 tracks. However the quality of each track here is immense.

It definitely seems as though Khalid took what he learned and experienced from his debut album and poured those experiences into this new solid creation.

Great album.

2. H.E.R. "I Used to Know Her: Part 2 - EP"

What's with artists that can't seem to stop creating? H.E.R.'s debut album came out last year and this year she released two additional EPs. At least she's being honest about what these things are.

Specifically this EP, Part 2, was a super strong R&B EP. The first track, "Carried Away", was replayed so many times. Everytime I put it on my hips would sway no matter where I was - at work, on the subway, walking down the sidwalk.

Gosh I love H.E.R.'s voice and vibe.

1. The 1975 "A Brief Inquiry Into Online Relationships"

A late release for 2018 however it very quickly shot to the top of my list. This is a true return to my indie-rock music roots, as this album is wonderfully indie. Yet danceable indie, and that's what I care about these days.

I haven't really heard such a new type of sound in a long time, which was very refreshing. To hear something completely new, and done well, doesn't happen that often.

However that would all be for naught if it wasn't also good tunes. And the songs on this album are indeed very good.

My breakout song from this album is by far "Love It If We Made It". I've played that song so many times...I can't get over it. Somehow it sounds like the singer is both screaming into the mic and singing at the same time and I don't understand it but I still love it all the same.

React Year in Review 2018

Sat, 22 Dec 2018 00:00:00 GMT

Hello everyone! Welcome to my React Year in Review 2018!

React's 2018 was one of steady growth and doubling down on foundational concepts and principles. It was a year filled with a lot of thought and not as much action - a combination that I think will pay great dividends in the year to come.

This was the year of Suspense, and Concurrency, and Hooks! All these high minded concepts were focused on filling in and smoothing down the rough edges of React. Which is a weird thing to say as you could easily look at React and for certain use cases it does everything you could ask for. However when the React community and core team started looking into some of the features that were a little awkward to do, they found room for improvement.

That's what this year was about. Rather than expand React (albeit React did expand), the React core team rethought some core assumptions on how one can best use React and brought their solutions to light this year.

Without further ado, let's get to the recap.

January

React Lifecyle Hooks Changing

This was one of the first hints of big things to come. Deprecating class lifecycle methods? Seemed outrageous at the time. But oh, to be that naive again.

New React Context API Merged

For too long React had a Context API that was actively discouraged from use. It wasn't until January of 2018 that we finally got an officially supported Context API. The most exciting part of it? It used a community convention as its primary API - render props.

February

React Native (including Fresco, Metro, and Yoga) relicensed under the MIT license to match React

Big news for a lot of people. The fear of using React Native was removed when it was relicensed to use the MIT license. Bravo to Facebook.

March

React Suspense

The demos heard around the React world. This was what started a whirlwind of thought and changes for 2018. Dan shows a version of React with two un-released features: time slicing and suspense. I think it took me the rest of 2018 to finally understand what the heck that meant.

React Update on Async Rendering

That PR back in January about deprecating class lifecycle methods? Finally came home to roost in the form of a blog post officially announcing the upcoming changes.

This blog post was quickly followed by another...

React v16.3.0: New lifecycles and context API

...that actually released the lifecycle changes. Long live getDerivedStateFromProps!

Also just as exciting, the new Context API becomes available.

April

Redux 4

Redux gets a nice version bump, rolling out some incremental changes to the community. Nothing earth-shaking here. Just a nice and easy new version.

May

React Suspense Merged into Master

That demo that Dan showed in March finally gets merged into React master. In isolation its hard to see where it fits in, but seeing the steady forward progress of React was exciting.

At this point the feature is still turned off as it's still under active development.

React turns 5 next week

React turned 5 in 2018! Happy birthday React! If you ever have a recruiter asking for 6+ years of React experience either: you're lying or you worked at Facebook.

June

Nothing happened. At least, nothing that I could find.

July

Umbrella issue for releasing React Suspense to open source

Things start to get a little more official for React Suspense. This GitHub Issue is opened to track its progress. It still seems to be somewhat maintained, with the last update coming at the end of November, however I'm not sure if it's still a canonical source of truth.

August

PR: React.lazy

A wild new feature appears out of the blue! It's not really talked about nor understood until later in the year, but React.lazy first shows itself in August.

React Fire: Modernizing React DOM

One of my personal favorite bits of news from the past year. Just as Fiber was to React so is Fire to React DOM.

Essentially a rewrite of React DOM to address issues and learnings from the past five years of development.

It's still very much in progress and I'm excited to see how it matrues during 2019.

October

Create React App 2.0

The officially supported scaffold tool gets a huge new release. Packed with many new and big features, it really brought a whole new level of maturity to the project.

Personally I was very excited with version 2.1 which added opt-in support for TypeScript. Even less reasons to eject!

React v16.6.0: lazy, memo and contextType

The second and final major release of React in 2018. This releases React.lazy coupled with a synchronous version of Suspense.

It's kinda surprising that there were only two major React releases in 2018. 16.4.0 and 16.5.0 didn't contain any major new features, so this was the last one that most people are probably still using.

React Hooks

The biggest event of 2018. React Hooks. If you don't already know what this is then please read my blog post that will tell you everything you need to know.

November

Hooks RFC Merged

The React Hooks RFC is merged, officially announcing it as approved and slated to be included in an upcoming version of React.

December

React-redux 6

Major new version of react-redux. This one includes the new Context API - the same one that was released all the way back in March. Almost an entire year before that feature was incorporated.

I'm glad for that delay as it allowed the react-redux team to take their time and carefully find the best method for using new React features. Had they rushed they could have introduced churn, something that I very much don't want to see in react-redux.

React 16.x Roadmap

A semi-official 'state of React' blogpost. It lays out the upcoming year of expected changes for React. It was a great post and did a great job of addressing the confusion that was floating around the React community.

In some ways I wish it had come sooner in the year, but I don't think the React core team themselves even know what that blog post would have said in July.

However like all good things, this came in time and delivered in a great fashion.

Conclusion

What a year for React. I don't feel like a lot happened this year - I feel like 2019 is going to be the one that will be truly mind-boggling. When Concurrent React is delivered it's going to be a paradigm shift in how React applications behave.

I'm also so very excited to play with React Hooks more. From my brief experiments it brings a whole new level of joy back into React that I didn't realize I was missing.

I've told you my highlights. What were yours?

Are you as hooked as I am on React Hooks? (I'm so sorry I'm not sorry for that joke.)

Cheers to a great 2018 React! Looking forward to 2019!

JavaScript Year in Review 2018

Sun, 16 Dec 2018 00:00:00 GMT

Well that's it! 2018 is coming to a close! What a year it's been, eh? A lot of highs...maybe a few more lows than I wanted. However your year turned out I know we can all agree that it was another great year for JavaScript.

There's a lot of 2018 recap posts and I would be remiss not to add my own into the mix. However for my 2018 recap I want to focus on some of the big JavaScript news and releases this past year.

It was fun compiling this list. It had more than a few surprises. Mostly I was surprised at the even pace of new releases. Usually JavaScript gets a bad rep from moving too fast. However in looking at what happened in the past year I wouldn't say that is true at all. It's refreshing to see libraries that are heavily depended on take that responsibility seriously and be very careful in the cadence of their releases.

There were also some great releases! Some libraries made some great improvements in the past year, making my life as a developer better and happier.

With all that being said, let's get to reminiscing!

If you're interested in watching this in video form I got you covered! Check out my YouTube video which is me telling you about the past year of releases rather than you doing the work and having to read all the following words.

January

Prettier 1.10

Prettier, everyone's favorite JavaScript code formatter, started the year with their 1.10 release. This release introduced the Prettier plugin API allowing 3rd party devs to extend the functionality of Prettier.

There were a couple of releases of Prettier this past year, culminating in 1.15, but you'll read more about that in November.

Bootstrap 4 Released

Big release from the Bootstrap team! One thing I love about Bootstrap is how careful they are with their upgrades. The amount of effort and care they put into every release is immense, and Bootstrap 4 was no exception.

TC39 now has an official logo

TC39 has a logo! I think I was more excited about this than most people but what's not to get excited about? An official logo for the team that decides the future of JavaScript? Hell yeah they deserve their own logo.

Immer goes 1.0.0

Feels like Immer has been around forever at this point, but it was only in January that it went stable at version 1.0.0. I personally love Immer - it makes an otherwise cumbersome task (immutablitity) easy. So many other libraries either directly build on top of Immer or use its novel concept to inform their own APIs. What a great addition to the JavaScript landscape.

Service Worker Support Added to Safari in iOS 11.3

Finally, I can invest some of my team to learning and implementing Service Workers! Mobile Safari support was the last main blocker for me, and that blocker was erased in January. It's now been a year of widespread support for Service Workers across modern browsers on the desktop and on mobile. No more excuses! Get Servicing! Workers!

February

Ember 3.0 Released

Major release of the Ember framework. They always do such a good job of bringing their community along with them during their upgrades. However a major version is a major version and the big change here was the drop of older browsers IE9 and IE10. And really, IE9 and IE10 shouldn't even be a consideration at all anymore. But alas...

webpack 4.0 final

Heyooo! Webpack up in the house! Big release from the Webpack team, happened all the way back in February. The big improvement with Webpack 4 was the arrival of more sensible defaults which was a direct response to the 0-config movement started by ParcelJS and other tools.

Also with Webpack 4 they've begun to introduce support for more module types. No longer is JavaScript the only supported file, the changes made in Webpack 4 added support for WebAssembly, JSON, ES Modules, and promised future fist-class support for CSS and other asset types.

I'm excited for Webpack 5, which, wouldn't be too surprising to see it arrive in February 2019. Not bad for a year's worth of work.

March

TypeScript 2.8

TypeScript continued its steady and stable release cadence throughout the entire year. Started off the year with the introduction of conditional types which laid the groundwork for later features to build on top of.

This year was definitely the year of TypeScript. It wasn't so much that TypeScript got amazingly better overnight, it was more that people started to enjoy all the features that TypeSciprt had accrued over the years.

MobX 4 Released

MobX 4 was released in March, a release mostly in preperation for MobX 5 which happened in June (sorry, spoilers!) MobX 4 provided an alternative API for using MobX decorators without the decorator syntax - a very needed update due to the dependency on the now outdated decorator proposal.

D3 5.0 Released

Not a huge release but a right and proper semver major release! D3 5 updates the default API for async methods - to now use Promises! Welcome to the present D3!

New npmjs website

I didn't realize how...dated...the npm website was until the new version was released.

Also I can't believe this happened all the back in February. I've gotten to used to the new website it feels like it's been there for years.

April

Announcing npm@6

npm 6 was released! Big new release for npm, and it's been the major release for npm throughout 2018.

npm 6 introduces npm audit, a tool to check the security of every dependency in your node_modules folder.

This new feature was quite prescient as 2018 had more than a handful of security scares. Having this feature at the ready was definitely a case of npm skating to where the puck was headed, not waiting for it to arrive.

Node.js 10.0.0

Node 10 was released! The latest and greatest LTS version of node (so far).

Redux 4

Redux 4 was released. A few small breaking changes that would only affect you if you were using parts of redux that were already discouraged. This is one library that I'm glad for the update but grateful for the slow pace of iteration.

If Redux updated every 6 months I'd be a little unhappy. How much could you even change?!

Underscore.js 1.9.0

Finally. Seriously, finally. After 3 years a new version of Underscore was released. I can't tell you how many times I'd look at the source code of Underscare in master, to see a feature exist there (cough debounce.cancel()) only to find that it hadn't yet been published. So glad this one happened.

May

SmooshGate resolved: change flatten to flat in flatMap proposal

SmooshGate we hardly knew ye. You were big and loud and beautiful, and now you're just flat and a footnote for the history books of JavaScript versions past.

June

Microsoft Buys GitHub for $7.5 Billion

Biggest news of the month by far. Did you see this coming? I still don't believe it and it's been a reality for months now.

Actually just reading this news item was a little bit of a shock for me, all over again.

All I can say is I'm glad I'm not a betting man because if someone had given me this to bet on I would be out a handful of cash.

Mobx 5 Released

Big new feature here was MobX taking advantage of Proxy objects to power its functionality. Yes this limits its usage to modern and evergreen browsers, however that's why MobX 4 came out earlier this year - to provide a branch that would still support older browsers.

Glad to see MobX embracing the future. Helps push us all closer to there as well.

ESlint 5.0 Released

ESLint always does a great job of helping users migrate to their newest version. Their migration guides and documentation around changes are always top of class. Truly the team that runs ESLint is admirable for the class and ease which they manage a wildly popular library.

ES2018 Approved

ES2018 is for real! Object Rest/Spread of properties gets official approval, as does Promise.finally. A pretty great year of features.

July

TypeScript 3.0

More TypeScript? More fun! TypeScript doesn't really follow semver that closely so while 3.0 looks big, it's really just the next feature release after 2.8. Still, a good release with many useful features that make typing projects more safe and more reliable.

August

GraphQL JS 14.0.0 Release

This is the reference implementation for GraphQL and this was over a year's worth of work since the last major version of GraphQL. This brought this implementation to conformace with the June 2018 version of GraphQL, bringing with it support for new schema features and extensions.

Babel 7 Released

Major Babel versions always hit like a cannonball and Babel 7 was no exception. No matter how careful the Babel team is somehow Babel releases still always feel somewhat controversial. That being said, I think Babel 7 was the least controversial release of Babel in ages.

Babel 7 did a great job of setting the stage for Babel to truly be the platform upon which developers of the JavaScript language itself will use to help push the lanaguage forward.

The Babel team removed all yearly presets to encourage people to both use present-env and to think of extensions of JavaScript they want to use on a per proposal basis. This puts the onus more on the end developer which is smart as it's hard to predict what every consumer of Babel expects.

I'd expect Babel 8 to be a major breaking change in API only, as I think Babel is now in a great position to help lead the way for JavaScript's continued evolution.

October

Create React App 2.0

I think one of the biggest releases of the month. Honestly brought about a huge backlog of features to an official release. If you click on the blog post link there's literally an almost page high bullet point list of upgrades that went into this release.

Mostly what I was excited about was the increase in feature support such that the need to eject went down. Also Create React App 2.2 added opt-in support for TypeScript which is awesome!

Angular 7 Released

Big major release from the Angular team. This continues to see the Angular team work on performance of the framework as well as provide more built-in components that make writing applications easier and quicker.

styled-components v4

Very popular CSS-in-JS library. Gets smaller and smarter.

The whole landscape for CSS-in-JS libraries is the fiercest its ever been so it has been great to see that competition push the quality of every library.

Node v11.0.0

New Node! The experimental branch. Gotta wait for Node 12 for LTS though.

Storybook 4.0

Adds support to other UI frameworks outside of React such as Ember, plain ol' HtML, and others.

Also upgraded to use Webpack 4.

A nice release. Would have liked to see it come a little quicker after Webpack 4 came out though. But whose to complain when it comes for free.

November

Introducing the GraphQL Foundation

An independent foundation to steward the future of GraphQL. A great sign of health for GraphQL as a whole, reducing its reliance on Facebook for its future success. I love seeing news like this.

Prettier 1.15: HTML, Vue, Angular and MDX Support

Prettier ended the year at version 1.15 adding support for HTML, VUe, and Angular. I was honestly surprised Prettier didn't support these languages already but it's great to see it there. The more widespread Prettier can become the happier I will be. I want to be able to read every JavaScript code base ever with as much ease as possible because they're all formatted with Prettier.

December

Announcing Emotion 10!

Another popular CSS-in-JS library. One of the fastest and smallest around. Did a really novel thing with creating their own JSX pragma function. A great release to see.

Announcing TypeScript 3.2

And TypeScript ends the year at 3.2. Again, slow and steady wins the race and TypeScript nails that to a T.

Flutter 1.0: Google’s Portable UI Toolkit

Essentialy Google's answer to React Native. It'll be interesting to see how this grows in popularity over the upcoming months.

WordPress 5.0 “Bebo”

Why's this here? Well WordPress rewrote their editor entirely in React. A big bet on a bold future. Excited to play around with it and see how WordPress continues its foray into more usages of JavaScript.

Conclusion

What a year, huh? Did you remember all these things happening? Can you still believe that Microsoft bought GitHub? Also are you shocked there was no major releases of React? Just minor ones (with new features, and no breaking changes). Good on React for keeping things stable.

What does 2019 hold? I'm personally very excited about Webpack 5 which is supposed to have persistent caching to the filesystem to make startup time even faster.

I'm also very excited about ReasonML. I'm curious to see how its popularity and mindshare grow in 2019. It might be its year.

What are you excited about for 2019? What are you hoping for?

Oh, and before I forget - Happy New Year!

Make Your Code Beautiful With Prettier

Fri, 07 Dec 2018 00:00:00 GMT

I'm a fan of cleanliness. I like a clean desk and a clean room. My desk at work is pretty sparse and minimal. I try and avoid clutter as it helps me find whatever it is I need at the moment I need it.

One of my most disliked tasks is having to clean up my apartment. Inevitably my apartment gets messy - that's just the unhappy side effect of living there and using it every day.

And as the clutter and disarray increases the need for me to take out the trash, and throw out the pile of mail grows as well.

I won't lie - every so often I get my apartment professionally cleaned. At a certain point I have to throw in the towel and just outsource that work to someone who does it better.

It's one of the best feelings in the world coming home to a freshly cleaned apartment. Aside from there being no mess, no dirt, no clutter - it was cleaned by someone else. That is what gives it that special touch of awesomeness that always keeps me coming back for more.

At this point you may be asking yourself what in Sam Hill does this have to do with Prettier? Notwithstanding this being a blog post about code, I haven't even talked about code yet!

You see, Prettier is a professional cleaner for your code. It reduces clutter, cleans up messes, and makes your editor feel like the coziest place on earth.

Prettier helps me keep my code as clean as I keep my apartment.

Video

Before I go on with all the remaining words of this post I want to let you know that this is also in video form.

So if you're the type of person who enjoys watching a human face teach you a new thing then enjoy the embedded video below.

If not then, keep on reading!

What is it?

Let's expand on what Prettier is a little bit more and leave that analogy alone for a little while. I love my analogies but sometimes I need to just write in plain english what the heck I'm talking about.

The most concise description of what Prettier is comes from its website:

An opinionated code formatter

Prettier will take your code - JavaScript, CSS, HTML, JSX (the list goes on) - and format it in a consistent and clean manner.

Take for example this unformatted code that is uh, perhaps a little hard to read:

// prettier-ignore
function sayHello
(
    times
)
{
    const handler
    = () => {console.log(
        'Hello'
    );

        const nextTimes = times - 1

                if (nextTimes > 0) { sayHello(nextTimes); } }



                    setTimeout(   handler,   1000
                );

}

sayHello(3);

This code works (try it), but reading it is pretty hard. At least for me it is. I mean, I tried to make it hard to read. I succeeded for myself at least.

Now here's that same code after Prettier has formatted it.

function sayHello(times) {
  const handler = () => {
    console.log('Hello');

    const nextTimes = times - 1;

    if (nextTimes > 0) {
      sayHello(nextTimes);
    }
  };

  setTimeout(handler, 1000);
}

sayHello(3);

Prettier, no?

Opinionated

Prettier is opinionated by default. The reasoning behind this is to reduce the arguments that engineers have around code-style and formatting. If there's anything that coders love to argue about it's the color of the bike shed and how many blank lines should be between two function calls.

The less options Prettier has the less there is to argue about.

Why there are any options at all is that there are a few points of contention that no amount of opinons will sway an engineer. For example tabs or spaces, or single vs double quotes. Rather than limit who would use Prettier, the door was opened a little wider to be more inclusive to the community at large.

Why should you use Prettier?

Prettier makes your code consistent and easy to read. This makes it so that you can open any file in your application and instantly know the style idioms such that you can spend more time reading the code and less time understanding the format.

Take for example a book. You read books right? A book typically has one font. Every page is the same font, letting you focus on the words and stories and less time on the design and style of the print.

Imagine that the first page of a book was written in Arial. The next page was written in Comic Sans. The next page in Helvetica. The next page in Papyrus.

That would make for an extremely painful experience. Every page becomes adversarial - getting in the way of the content and preventing people from understanding what they're reading.

That's why Prettier is important. It makes all your code the same 'font' such that another engineer can spend more time on what the code is doing, and not where it shows up on the screen.

Teaching Tool

If you're a new programmer I doubly recommend using Prettier.

Prettier's style conventions are defined by industry wide best practices and behaviors. Such that when you are learning how to code and you have Prettier installed, it's as if there's senior engineer over your shoulder constantly giving you tips and advice on how your code should look.

This frees you up to worry about what you want your code to do. Letting you focus on more important things - like learning the language - and not learning its customs and conventions. Two things that are extremely hard to pick up in a vacuum.

Other reasons

Some other reasons why you should use Prettier:

Never have another argument with a co-worker about why their style is wrong and yours is right. Outsource that argument to Prettier and get back to making your app!
Can clean up existing legacy codebases. This is an echo of the same reason of consistency. Legacy code is rarely touched and if it hasn't been touched in a while it may be tricky to read. Run Prettier over that code and now you're in business!
Prettier stays up to date with community conventions. As style conventions evolve so does Prettier. And when Prettier makes a tweak to its format applying that change is as simple as re-running Prettier over your code.

How do I use it?

Prettier operates as a CLI tool. You install it into your local application and then run its CLI tool to format your code with Prettier.

You can also install Prettier as an editor plugin, which is my recommended way of using Prettier. I'm going to point you to the official Prettier editors page to read more information about how to get that setup, but once it's installed it makes for the best experience.

You write some code, hit save, and Prettier makes your code...pretty. It's tremendous.

If you want to get Prettier running via CLI it takes two steps:

Install it: npm install --save-dev prettier
Run it: npx prettier [opts] [filenames]

If you want to customize Prettier then you have one more step:

Make a .prettierrc file and set your options.

Conclusion

Prettier has made me a better programmer by allowing me to focus on more important things like what my code is doing, not how it looks.

I love that I can write sloppy code that may be somewhat illegible, and Prettier comes along and makes everything clean and tidy.

Sometimes I have a lot of fun writing intentionally gross looking code (like above) and watching Prettier swoop in and make it look so fresh and so clean, clean.

Use React.lazy and Suspense to Code-Split Your App

Sun, 02 Dec 2018 00:00:00 GMT

The marquee feature of React 16.6.0 was the introduction of React.lazy, a built in way to do code-splitting with React.

In all honesty I was hoping to have had this article written about two weeks ago, but in an entirely ironic and unintentional sequence of events that didn't happen because I got lazy. Well that's not truly fair to say - more so that I ran out of time and rather than stay up till 2am one night I decided that getting a good night sleep would be in my best interest. Or put another way, I got lazy. Who needs sleep? (sarcasm)

So back to the topic at hand: React.lazy lets you lazily load components via code splitting in a React aware manner. Let's break down what each of those things mean.

And before I delve into lines and lines of text, let me give you the fun option of watching me teach you in video form. I'm entertaining, educational, and above all else it keeps with the spirit of this topic. You can be lazy and rest your mind and let me dance around your computer screen in video form.

Code-splitting

Back in the old days of web development people would concat their JavaScript files together and ship that off to the browser. It was the professional's solution towards shipping JavaScript applications to the browser and well...it was as good as it got back then.

Nowadays people use module bundlers such as Webpack or Parcel to do the same thing we used to just in a much more high brow manner. Instead of simple file concatenation we can now use module systems such as CommonJS (require, module.exports) or ES Modules (import, export) to define the dependencies between files.

This is great however sometimes these web applications get mighty large and it gets mighty heavy to send all that JavaScript to a person's browser all at once. I've seen some JS bundles north of 10MB - and that ain't no load that I want to lift on every page refresh.

So the solution to that problem is to code-split an application. Rather than including all dependencies up front, we can actually tell our module bundler that in some places it's ok to be lazy, that we can chill, kick up our feet, rest a while. We effectively tell our module bundler that we have some parts of our application that is aggressively chill and can be sent to the browser lazily and barefoot (barefootedness, as you know, is the strongest display of laziness).

Here's some code that sends everything to the browser at once:

import Description from './Description';

function App() {
  return (
    <div>
      <h1>My Movie</h1>
      <Description />
    </div>
  );
}

Now how do we tell our module bundler to lazily load that module?

Dynamic import proposal

This proposal adds a new feature to ES Modules that allows us to define our code dependencies asynchronously.

The import statement can now be used as a function which returns a Promise that resolves to the module that is being requested.

To use that feature requires just a small change.

-import Description from './Description';
+const Description = import('./Description');

What this change in dependency declaration tells Webpack or Parcel is that module, Description is no longer needed right away - we can wait to load it at a point in time when the application needs it.

And what that lets the module bundler do is create a separate .js file that contains the lazily loaded module.

And that's what we call code-splitting.

What was once 1 file is now 2. It's been split, and that has made all the difference.

Robert Frost

However that story is just the beginning for us wanting to code-split React Components.

Lazy Loading React Components

Now that we've defined our code-split location we now have some homework to do to properly render the component.

We have to call the import() function, wait for the Promise to resolve, and then take that value and render that in our component.

It's a lot of book-keeping which tends to be redundant and error prone.

It looks more or less like this to fully lazily load that component.

// We make this a function so we don't start loading
// this lazily loaded module on page load.
// Which would kind of defeat the point of lazy loading.
const LoadDescription = () => import('./Description');

class App extends React.Component {
  state = {
    Description: null,
  };

  componentDidMount() {
    LoadDescription.then(Description => {
      this.setState({ Description: Description.default });
    });
  }

  render() {
    const { Description } = this.state;
    return (
      <div>
        <h1>My Movie</h1>
        {Description ? <Description /> : 'Loading...'}
      </div>
    );
  }
}

Luckly for us React developers there's a very popular and well maintained library that already does this for us called react-loadable.

It works, it's great, I use it, I recommend it.

It removes all that boilerplate so all you have to write is:

import Loadable from 'react-loadable';

const LoadableDescription = Loadable({
  loader: () => import('./Description'),
  loading() {
    return <div>Loading...</div>;
  },
});

function App() {
  return (
    <div>
      <h1>My Movie</h1>
      <LoadableDescription />
    </div>
  );
}

Aaaaah...so much better.

So then why are we talking about React.lazy?

Suspense

One main drawback of react-loadable is that it works on a per-component basis. What I mean by that is for every individual component that you may want to lazily load you have to define its own discrete loading state. Sure you can use a common component so that all your loading states look the same but that's the issue - you're going to see a loading state for every individual component that is lazily loading.

So if I had multiple lazily loaded components it's possible I may see three, or four, or nine-thousand spinners on my page before all those extra JS bundles are downloaded, parsed, and executed.

That's not the best user experience.

That's also the bad user experience that React.lazy solves.

React.lazy is built to be used in tandem with a Suspense component. React.lazy is essentially the same thing as react-loadable, however instead of defining all your loading states on every React.lazy usage, you define it on the Suspense component.

What that means is you can have as many React.lazy components as you want, but you'll only ever see the one loading state on the Suspense component.

Not only that, but your React.lazy components can be placed at any depth in your React component tree. So any far removed, remote child component can be lazy and Suspense will still handle that case in one nice and neat location.

(If you're curious the way this works is similar to how the Error Boundaries work in React, which itself is similar to how try/catch works in JavaScript. It's turtles, just turtles all the way down.)

So let's take a look at how we'd use React.lazy using our same super verbose and complex example (sarcasm (gosh I wish sarcasm translated better online (just like how I wish writing asides to my own writing worked better then just nesting parenthesis (what is this, Lisp?))))

import React, { Suspense } from 'react';
const Description = React.lazy(() => import('./Description'));

function App() {
  return (
    <div>
      <h1>My Movie</h1>
      <Suspense fallback="Loading...">
        <Description />
      </Suspense>
    </div>
  );
}

🤓 Neat!

Suspense component will catch any React.lazy instances and then render just the one fallback component.

So if we had the following, we'd still only render one fallback component.

import React, { Suspense } from 'react';
const Description = React.lazy(() => import('./Description'));

function App() {
  return (
    <div>
      <h1>My Movie</h1>
      <Suspense fallback="Loading...">
        <Description />
        <div>
          <span>Cast</span>
          <AnotherLazyComponent />
        </div>
      </Suspense>
    </div>
  );
}

// AnotherLazyComponent.js (imagine in another file)
const AndYetAnotherLazyComponent = React.lazy(() =>
  import('./AndYetAnotherLazyComponent')
);

function AnotherLazyComponent() {
  return (
    <div>
      <span>So...so..lazy..</span>
      <AndYetAnotherLazyComponent />
    </div>
  );
}

But where things get really neat is if we use additional Suspense components to further customize how we want to show our loading state.

Through the power of React and the sweet wonders of declarative programming the flexibility of UI behavior is put into our hands so that we can decide easily and without much effort where we want to handle and show fallback components.

So let's say we want to highlight how lazy our AnotherLazyComponent is. We can do that via:

function App() {
  return (
    <div>
      <h1>My Movie</h1>
      <Suspense fallback="Loading...">
        <Description />
        <div>
          <Suspense fallback="Sorry for our laziness">
            <span>Cast</span>
            <AnotherLazyComponent />
          </Suspense>
        </div>
      </Suspense>
    </div>
  );
}

In this example we've broken up our fallback handling into two separate Susepense components. When our AnotherLazyComponent starts to load we'll show our apologetic fallback message.

What this also means, which is even more powerful and exciting, is if AnotherLazyComponent takes a long time to load it will no longer affect the rest of the components being rendered. We've essentially cordoned off AnotherLazyComponent and all its children and prevented its lagginess and supreme laziness from slowing down the rest of our application.

React will show "Sorry for our laziness" until AnotherLazyComponent and its children have loaded and rendered, but React will show Description as soon as it is loaded and rendered - and not wait for AnotherLazyComponent.

Compare this to the previous example without the second Suspense component. In that scenario React would have waited for every lazily loaded child component to load and render before showing anything.

We've decided which components we want to show as soon as we can, and which we're ok to show later.

It's a hard concept to really understand in written word, so I would suggest you checking out my video posted above to get a feel for what I mean.

If you don't then just take my word for it: it's cool to be lazy.

Conclusion

React.lazy takes practices and libraries that have already existed in the ecosystem and codified them as a best practice by providing first-party support.

This is a wonderful step forward for React and is an example of what it does best: make hard things simple and simple things...verbose. That's a joke. But it's a joke based on truth (those make the best types of jokes).

I'd be remiss not to mention Async or Concurrent React. Those two words have been bandied about with Suspense and make no bones about it, Concurrent React will leverage the Suspense component but that's a blog post for another time. As in when it's done and released. But yes, you eagle eyed reader, Suspense is an overture on bigger things to come. For now the React team is starting on a wonderfully lazy foot.

If you're using React 16.6.0 or later you can start using React.lazy and Suspense now! And I'd encourage you to do so if you're interested! It's definitely a power user feature and not something that every application developer will need right away. But it's there for you to use and play with.

If you have played around with it I'm curious to hear your thoughts.

Or better yet, share your experiences with me in video form. Cuz that's the laziest way for me to consume that info, and I want to do my best to keep in the spirit of the feature at hand.

Priorities

Sun, 25 Nov 2018 00:00:00 GMT

This past weekend was Thanksgiving which meant that I spent the past couple of days with family. It was great to unplug and get away from the ridiculously fast paced world of tech and coding. However by virtue of unplugging it meant I wasn’t able to make anything. Instead I was able to focus on health and family, letting everything else I usually worry about fall to the wayside.

I’m a firm believer in the following priorities:

Health
Family
Everything else

Health

Without your health you don’t have anything. If I’m feeling unhealthy then everything else that I’m preoccupied with immediately becomes de-prioritized.

Health covers anything and everything related to your well-being. From the physical to the mental and everything in between.

Health is what enables you to do everything else, and if you’re not taking care of yourself then you won’t be able to do anything else.

Family

I say family generically, in the spirit of those you love and trust.

If you’re not maintaining and nurturing the relationships you have with your family then you’re going to be in for a lonely time, and life is hard enough when you try to go it alone.

Family is there to nurture you back to health when you’re feeling unwell, and family is there to celebrate with you in your times of joy.

Family is the backbone to all your endeavors, making tasks that may feel impossible, possible.

Everything else

If you have your health, and you have family, then you can start tackling whatever else tickles your fancy. Usually that means work or a hobby, but truly it’s up to you. Whatever it is should be rewarding and enriching.

For me it’s work and all my side projects, such as this blog and making YouTube videos. They make me feel accomplished and productive, two feelings that I greatly enjoy.

Remember your priorities

It’s always important to remember your priorities.

This weekend my priority was family. Then I made health my priority by not staying up too late to make a video and exhaust myself.

After all that was done I was able to tackle everything else. Such as this blog. Cuz it makes me feel good to make something.

What are your priorities?

React Hooks

Sun, 11 Nov 2018 00:00:00 GMT

React Hooks! Hooks! Hooks! Hooks!

Sorry, had to yell that a few times to get it out of my system.

I definitely find React Hooks to be one of the most exciting new features that has hit React in a long time. I don't think I've been this excited about a new feature since React Fragments and that was way back in the initial React v16.0.0 release...last year. So I guess that means I haven't been excited about React for an entire year? That's not true, but if it gets you to read the rest of this post then let's say it is.

What is React Hooks?

Let's steal from the official docs as they say it best:

Hooks are a new feature proposal that lets you use state and other React features without writing a class.

So what does that mean?

Before React Hooks you had the following ways to write a React Component:

Class Component: This is everyone's tried and true, most favorite, most popular, way of writing a React Component. It is the most full featured way of writing a React Component as it gives you access to a render method, lifecycle methods so (you can plug into events of the React rendering lifecyle), and most importantly, they can have their own local state.

class MyComponent extends React.Component
    state = {
        ofMind: 'Alica Keys',
    };

    componentDidUpdate() {
        console.log("I'm the 'life' of the party, and I 'cycle' around.");
    }

    render() {
        render <h1>Oh Wowwwww</h1>;
    }
}

Pure Class Component: Just like our favorite Class Component this has a built in optimization to only re-render your component if your state and props change.

class MyComponent extends React.PureComponent
    state = {
        ofPurity: 'Purell for Clean Hands',
    };

    componentDidMount() {
        console.log("I still have lifecycle support!");
    }

    render() {
        render <h1>But now I only change if my `state` and `props` do!</h1>;
    }
}

Function Component: Don't care about lifecycles? Not worried about local state? Only care about UI? This is your sweet spot, letting you create a nice and simple component that just renders UI. Best of all? It's just a function!

function IAmAComponent() {
  return <h2>But I'm just a function!</h2>;
}

Pure Function Components: Fresh off the presses with React 16.6.0 you can now use React.memo to replicate the functionality of a Pure Class Component with a memoized Function Component. Before React.memo you couldn't optimize the performance of a function component, and if you wanted to you'd have to refactor the component into a Class Component. Well, no longer!

React.memo(function IAmMemo() {
  return <h2>Ized, Ized, Baby</h2>;
});

So I count 4 ways of writing a React Component, split into two camps.

You can write a component as a Class or as a Function. However if you write a component as a function you're unable to have local state or access lifecycle methods. If you need those two features you have to refactor your component into a Class.

That is, until now.

React Hooks fills that hole. With React Hooks you can now have local state and access lifecycle behaviors in a function, letting you have the full expressive power of a React component and retain the nice brevity of a function.

That alone is what I'm most excited about. The fact I can now have local state in a Function Component is so lovely it makes me want to kiss my code editor. Not sure what good that'll do me, but well, just wanted to show you my level of affection.

Enough talk, show me the code!

Honestly I encourage you to read the official React docs on Hooks as they've done an incredible job refining and honing the concepts and ideas that you should know in order to learn and understand Hooks.

However, you're on my blog, so I'll take a crack at explaining Hooks as well.

And in fact, if you're tired of having to read words on a page, you can even go onto my YouTube channel and watch me explain Hooks in video form. Think of it as me shoving words into your brain rather than you pulling the words from my blog into your eyes. Weird way to describe that, sorry about that.

Learn Hooks with Video

I have three videos that give you a great introduction to learning about Hooks.

React Hooks are a set of primitive APIs that allow you to, uh, hook into React from your Function Component.

These APIs are plain functions that do what they are named. Which is something I always respect, when a function is named after what it does.

useState

If you want to use state in a Function Component you can do so via the useState hook:

function CounterFunction() {
  const [count, incrementCount] = useState(0);

  return (
    <div>
      Current count: {count}
      <button onClick={() => incrementCount(count + 1)}>Increment</button>
    </div>
  );
}

useState takes one argument, which is the initial value for that state. Something to highlight here is that useState can take any type of data - it can be a primitive, an object, or an array. This is a big difference to how state works on a Class Component. On a Class Component state is always an object, and you put things on that object. If all you want to keep track of in a function is a number, you can just have state be an integer. This makes things so much simpler in my opinion as React is no longer prescribing how you should be desiging your application.

useState returns an array with two items. The first is the current value stored in state, and the second is a function that lets you update the state. The convention being put forth by the React core team is to use array destructuring to make the developer experience a little more pleasant.

So instead of doing this:

const state = useState(0);
const count = state[0];
const incrementCount = state[1];

You destructure the values in the array directly:

const [count, incrementCount] = useState(0);

Makes for a much better time.

Also what's nice about having the values be in an array is you can name them whatever is relevant to your function. So if you're storing text you can have it be:

const [name, setName] = useState('Harry');

Or whatever else makes sense.

The updater function, which is the second item returned in the array (in our case incrementCount and setName) lets you update your state value. What I find interesting about this function is that you can update your state with whatever you want. So even though you may have begun your state as a number, there's nothing stopping you from setting it to a string, or an array, or an object. Nothing except the sanity of your co-workers, or yourself in six month time when you read your code and scratch your head wondering why you changed a number to a string and then tried to Object.keys on the string and you're curious why you never had a bug show up in this piece of code and you start questioning if JavaScript even makes sense anymore.

Woah, sorry, that got a little intense at the end there.

But in any case, that's useState.

useEffect

useEffect is the Hooks' answer to lifecycle methods. What I find personally super powerful about useEffect is that it gives you the power of lifecycle methods without requiring you learn the internals of React.

useEffect takes up to two arguments. The first argument is the effect you want to run. It's the piece of functionality that you would have normally put in componentDidMount or componentDidUpdate.

The second argument is optional. If present, it's an array of values that useEffect uses to decide when to re-run the function given in the first argument.

If you don't provide a second argument then useEffect will re-run your effect after each render of your React Component. The React Core team decided on this default behavior after very careful consideration. By having it run on every render you can rely on behavior that is most intuitive and consistent.

However it may not be the most performant. And that's where the second argument comes in.

Let's look at an example:

function MyComponent({ userId }) {
  const [repos, setRepos] = useState([]);

  useEffect(
    // This is our effect. It fetches data from the GitHub API
    // and then updates our local state when the Fetch resolves.
    () => {
      fetchGitHubRepos(userId).then(repos => {
        setRepos(repos);
      });
    },
    // This is the second argument to `useEffect`. We're passing
    // in the `userId` value which is a prop given to this component.
    // When that value changes, then we'll re-run our effect.
    // Without this value we would have refetched the GitHub API
    // everytime this component re-rendered. That would be no good.
    [userId]
  );

  return (
    <div>
      {repos.map(repo => (
        <div>{repo.name}</div>
      ))}
    </div>
  );
}

There's a third usage of useEffect and it's bundled into the effect function.

If you return a function from the effect function (the function given as the first argument) then React will call that function before it re-runs your effect, or when the Function Component is being removed from the page.

This is basically the same functionality as componentWillUnmount lifecycle method. But in Hook form.

More Hooks

There's many more Hooks that I'm not going to delve into right now.

I cover a few more in my Advanced Hooks Video. So if you are interested then please check that video out.

What other Hooks are there?

useReducer: Did someone put Redux into React?
useContext: An easier-to-use API for consuming Context values.
useMemo: To cache expensive values and not have to re-compute them every time. For example, an expensive client-side filter function.

...and more!

Check the Hooks API Reference Docs for the full list.

Custom Hooks

It would truly do you a disservice if I didn't talk about Custom Hooks. It's simultaneously the biggest strength of Hooks whilst having the most understated API.

Custom Hooks, as described from the React docs page:

Building your own Hooks lets you extract component logic into reusable functions.

So let's take our previous GitHub fetch example above and extract that functionality into a custom Hook.

A Custom Hooks is just a function that starts with use and contains other Hook calls. That's it. It's pretty sweet.

function useGitHubRepoAPI(userId) {
  const [repos, setRepos] = useState([]);

  useEffect(() => {
    fetchGitHubRepos(userId).then(repos => {
      setRepos(repos);
    });
  }, [userId]);

  return repos;
}

function MyComponent({ userId }) {
  const repos = useGitHubRepoAPI(userId);

  return (
    <div>
      {repos.map(repo => (
        <div>{repo.name}</div>
      ))}
    </div>
  );
}

What this means is I can now fetch data from GitHub anywhere I want and all that logic and state is encapsulated within the Custom Hook.

Think of other things that require lifecycle methods and use state.

Such as useOnClickOutside. Bind to global clicks and call a callback when a click occurs.

Or useWindowSize. Call it to get back the current size of the window and that value updates as the window updates.

The possibilities are literally limitless.

And they'll make writing applications so much easier.

Where can I use Hooks?

You can only use Hooks within a Function Component. Which is kind of an interesting move by the React core team. I'm sure it wasn't intentional but it is funny that they provide some really great functionality via Hooks and restrict its usage to only Function components, a historically hobbled part of the React ecosystem.

In this weird twist of fate Function Components have gone from the red-headed-step-child of React to now one of the most powerful and expressive parts of it.

Funny how things change.

When can I use Hooks?

Today! They are officially released in React v16.8.0. If you want to play around with them then install that version of React and React DOM: npm install --save react@v16.8.0 react-dom@v16.8.0 and you'll be on your merry way.

Conclusion

React Hooks are very exciting.

I believe I saw someone describe Hooks as a new primitive that exposes an entirely new way of writing React applications. I whole-heartedly agree with that description.

Hooks opens up an entirely new way of writing React apps by letting you access core React functionality and being able to share that functionality via Custom Hooks.

I'm personally excited about the next new React app I work on. I think writing an entire React application using only Function Components and Hooks is going to unlock all new design patterns and new ways of code-reuse that should make the application both faster to develop, and easier to maintain.

That's the holy grail isn't it? A developer experience that is fast and easy. Hard to obtain but us developers are always trying to get closer to that ideal.

I think Hooks is a very strong step towards that ideal. At least it is within the context of React. I won't truly know until I play with Hooks more.

For now, I know that I'm...hooked... on React Hooks. It had a great lure and I've bitten right into what it's selling.

Hopefully I got you interested as well. Or at the very least cleared up some confusions as to what the heck React Hooks is and why people can't stop making puns about the name.

To that, I'm guilty as all the rest.

Fatherhood

Mon, 07 May 2018 00:00:00 GMT

On April 7th, 2018, my son was born and I became a father.

His birth turned me into a father. A dad. His daddy. Someone who will always be there for him, no matter what.

I've long wanted to be a father, to have a child. It's something I've wanted for as long as I can remember. Some people grow up wanting to get married, or to buy their first car. I've always wanted to be a father. On April 7th my wish came true.

It takes an awfully long time for a baby to grow. Nine months of waiting around while my wife's stomach grew. Slow at first and then all of a sudden I was seeing my sons' hand pushing from inside my wife's belly.

It was nine months of waiting and stress, worried and anxious that all would turn out ok.

Then we got near the due date and the anxiety kicked up a notch. We waited, and waited. When would he arrive? Was he ok? What would the birth be like?

The due date came and went so we continued to wait. Each night we would go to sleep confident that tonight would be the night that he would come. He didn't come any of those nights.

We set an induction date for a week past when he was due, a Friday. We were scheduled to come in to the hospital at midnight to start the induction. He was going to come whether he wanted to or not.

So on the Friday of our scheduled induction my wife and I went out to dinner for our last meal as adults, not parents.

Back home we settled down in front of the TV. Our bags were packed and we were ready to head into the hospital at midnight.

Except our son had a different plan.

At 7:58pm my wife's water broke. It was time to go to the hospital.

That night in the hospital was one of the longest in our lives.

We got to the hospital at 8:38pm and were admitted and given a delivery room. My wife was hooked up to monitors and I was given an oversized chair.

And then we waited. We waited while counting the contractions. We waited until our son was ready to come out and say hello.

We ended up waiting 17 hours. I slept maybe four hours that night, my wife slept maybe one or two.

At noon it was decided we couldn't wait anymore so we began to push him out.

So we began to push. And push. And push.

My wife would push with the contraction as I crouched behind her back, pushing her as well, trying to support her in this life-changing task. The contraction would subside and we would all take a short breather until the next contraction, when we started all over again.

For a little over an hour we pushed. Until...

Until at 1:19pm on Saturday afternoon, April 7th, 2018, our son was born.

The moment my wife and I saw our son emerge, crying and healthy, we were filled with the most sublime type of joy imaginable.

He was plopped onto my wife's chest, the most beautiful sight I have ever seen. I began to cry uncontrollably, ultimately ruining my shirt as I was without access to tissues.

My wife held our son on her chest, content beyond words, and she looked at me, with tears in her eyes, and asked with a serene smile, "Does he look like a Miles?"

Top 10 Albums of 2017

Wed, 27 Dec 2017 00:00:00 GMT

2017 was a year in which many of my current favorite artists put out new albums. Going into the year I was super excited and impatient to get my hands on their newest creations. If I liked what they made before, surely I'll like what they make today? Sadly that didn't turn out to be the case.

Most of the music that I listened to on repeat was from artists that I had never listened to before. Most of them were new artists as well. They breathed new life and sounds into a musical landscape that, without them, would have been pretty boring.

One of my top dissapointments for the year was the new Grizzly Bear album which never grabbed my full attention. I can typically tell after the first few seconds of an album if I'm going to enjoy it, and I knew - even from the early release of their single - that the new Grizzly Bear album would leave a, well, unbearable impression. That was super disapointing. I've loved almost all the previous Grizzly Bear albums and to have one come out that left me with a solid "meh" impression wasn't fun. (Don't get me wrong, the album isn't bad. It's just not anywhere near as good as their previous works.)

Also on my list of honorable mentions were follow-up albums from Spoon and The Xx. Spoon (unlike Grizzly Bear) has yet to disapoint me. They almost made it into my top 10 but they got beat out by other albums that were simply better. And The Xx's album was fine. Nothing will be as good as their first album, but at least this record wasn't as bad as their second album. But again, there was other music that was just better.

The honorable mentions this year, in alphabetical order.

Amine - Good For You
A Boogie wit Da Hoodie - The Bigger Artist
Blackbear - digital druglord
Dirty Projectors - Dirty Projectors
dvsn - Morning After
Father John Misty - Pure Comedy
Four Tet - New Energy
Grizzly Bear - Painted Ruins
HAIM - Something To Tell You
Iron & Wine - Beast Epic
Jessie Reyez - Kiddo
Lorde - Melodrama
mansionz - Mansionz
Maggie Rogers - Now That the Light Is Fading EP
Spoon - Hot Thoughts
St. Vincent - MASSEDUCTION
The xx - I See You

The overall trend of genre that I fell in love with this year has been R&B. I've loved the crooning voices over grooving baselines that gets my head bobbing up and down while I ride the subway around New York. Getting into a chill groove was also the perfect antidote to an otherwise tumultuous and stressful year (2017, amirite?). My unconscious mind knew what it needed to set itself at ease. Without these albums, this year would have been a whole lot worse.

Top 10 Albums of 2017

10. JAY-Z "4:44"

4:44, as most popular music publications have already written, was a raw confessional album of Jay-Z dealing with his demons, insecurities, and bad behavior (namely, cheating on Beyonce). The raw and honest writing combined with Jay-Z's uncontested rapping prowess produced an album of strong individual tracks that - while very good - did not produce a cohesive album or message. Each track tackles a different subject matter, without any bleeding of subject matter between the songs. If it wasn't for the individual strength of each track I doubt I would have liked it as much, however it resulted in an album that was hard to listen to on repeat as each song demanded its own individual attention. In some ways this album would be better reviewed by looking at each song apart from the whole, however I usually listen to albums and as a result this one comes in at the bottom of my list.

9. Sam Smith "The Thrill of It All"

I can't get over Sam Smith's voice. Honestly, everytime I think he's going to miss a note or fall flat he just soars above all my expectations and leaves me dumbfounded at his effortless delivery.

This is a slow album full of songs that Sam Smith croons over. In fact, you wouldn't be wrong to call this an adult contemporary album. The general pace of this album is much slower than the first and that's probably my biggest grievance. I would have loved some Disclosure-influenced songs however I think this record is a much more accurate depiction of who Sam Smith is and what type of music he enjoys creating.

8. Daughter "Music From Before the Storm"

I'm a big fan of instrumental rock, however I haven't heard an instrumental rock album that has resonated with me in such a strong way until discovering this album. Truth be told I know nothing about this band or this album past what it sounds like, and I'm more than content by just knowing this album.

The only thing I enjoy more than instrumental rock is when there's a touch of vocals added into the mix as an additional instrument. This is done perfectly on this record. It reminds me of one of my favorite records of all time, Ambulance LTD and that's probably one of the highest compliments I can give to an album.

I don't drive anymore because I live in a city however if I did this would be a record that would keep me warm on a long dark ride into the country.

7. Nick Mulvey "Wake Up Now"

I'm such a sucker for singer-songwriters. I've been a fan of Nick Mulvey for a while now and this album came at just the right time. I've sucked it down and listened to it on repeat, letting his acoustic guitar and soft croon pacify my nerves and calm my mind. If I were to ever make my own music this is the type of music I would love to create. Just a man and a guitar, making lovely music together.

6. Mount Kimbie "Love What Survives"

I almost missed Mount Kimbie. A few years back I got a last minute invite to see a concert with a friend. The concert was for Mount Kimbie's second album, and I ended up going without having heard any songs. I was blown away by the concert and Mount Kimbie and I've been a huge fan ever since.

This is their third album and it is 100% just as solid as their first two albums. It is obviously a Mount Kimbie record, keeping their patented sound, however it also manages to branch out and explore new areas. That's always a hard feat for a band to accomplish and it was thrilling to hear it from Mount Kimbie. (In case you haven't heard Mount Kimbie before, they create electronic music with catchy drum beats and an otherwise dark feel, similar to the first Xx album. It has guest vocalists as well that round out individual songs.)

Like all Mount Kimbie albums it has one fatal flaw. It's too short. Only 11 tracks. Sure, quality is better than quantity, but can't we get both for once?

5. SZA "Ctrl"

I'm almost embarrassed to admit it, but I almost overlooked SZA. I had her singles playing on repeat however for some unknown reason I never took a listen to her entire album until December. Abashed at my neglect I started to devour this album, putting it on repeat to understand what I did and didn't like about the album. I started listening to make sure I hadn't missed something great, and by my third listen I knew I had indeed almost missed something great. This album has consumed December for me and I honestly didn't know where to put it on this list as I had to rush my listens. So I stuck it in the middle. Had I listened to it earlier in the year there is a very strong chance it could have made its way higher in the list but alas, you only get to listen to something for the first time once.

That preamble aside, once I began listening to Ctrl I was unable to stop. The breakout song is undoubtedly The Weekend but really the entire vibe to this album is wonderful. SZA croons and prowls around every song, ensnaring the listener into her world with effortless ease. The album gives me tingles.

4. Khalid "American Teen"

Remember how I mentioned R&B was a big trend for me this year? Khalid continues that trend, coming up just after SZA.

I think the best way to describe Khalid is to provide some context. He's a normal 19 year old kid who has dreams just like everyone else. When he was 14 he tweeted that he would love to go the Grammys one day. Five years later it happened. Those two tweets are probably among my favorite tweets from this year.

There are so many catchy songs that I keep forgetting they all come from the same album. It's rare for an album to have standalone hits that still make the sum bigger than its parts but that is what Khalid was able to do with this album.

Listen to the songs by themselves or in the flow of the album, you'll be delighted either way.

3. Kendrick Lamar "DAMN"

Kendrick Lamar is a pretty damn good rapper, isn't he? I mean, if you didn't already know that then you have some things to catch up on. But if you are just getting to know Kendrick Lamar off of DAMN then that is a very fine place to start.

DAMN continues Kendrick Lamar's place at the top of the rap game. He's just so damn good. He knows he's good but he doesn't take it for granted. He still puts in the work to make sure every song is just as good as every other.

2. Daniel Caesar "Freudian"

If you haven't listened to the breakout track from this record, We Find Love please do so now. It's the single song that gave me the most feels out of any other song this entire year. I played it so often I was worried I would wear it out. However I was so grateful when that never happened. When the entire backing choir comes into the song I just get transported away to a place that makes me feel happy and safe. It's a perfect song.

The rest of the album isn't as good as that perfection but if that song is an 11 then everything else varies between a 7 and a 9. The smooth voice of Daniel Caesar combined with his ernest words made this an album full of honest and true emotions and feelings.

1. Future "HNDRXX"

I think this was my most listened to album of 2017. While the album itself is a little sprawling at 18 tracks, the first 8 tracks are all standouts. I did not expect to like this album as much as I did but more often then not I'd find myself putting this album on while I went out about my day.

Tracks 3-6 I can play on loop again and again. The groove and song-rap of Future imbued the songs with such a strong vibe that to this day I find myself unable to dance along.

I don't think this album will be to everyone's liking as much as it was to mine but there's a certain mood and vibe that carries throughout that made this my number one album of 2017.

Small addendum. Here's my top 20 most played songs from 2017 as well. This is just generated from iTunes.

We Find Love by Daniel Caesar from Freudian with 32
Young Dumb & Broke by Khalid from American Teen with 27
Four Years and One Day by Mount Kimbie from Love What Survives with 24
Supermodel by SZA from Ctrl with 21
Blue Train Lines (feat. King Krule) by Mount Kimbie from Love What Survives with 20
Passionfruit by Drake from More Life with 19
Say Something Loving by The xx from I See You with 19
Blessed by Daniel Caesar from Freudian with 18
Love Galore (feat. Travis Scott) by SZA from Ctrl with 18
Dangerous by The xx from I See You with 18
Best Part (feat. H.E.R.) by Daniel Caesar from Freudian with 17
Mourning Sound by Grizzly Bear from Painted Ruins with 17
Too Good at Goodbyes by Sam Smith from The Thrill of It All (Special Edition) with 17
Keep Running by Tei Shi from Crawl Space with 17
No Promises by A Boogie wit da Hoodie from The Bigger Artist with 16
Glass by Daughter from Music From Before the Storm with 16
My Collection by Future from HNDRXX with 16
American Teen by Khalid from American Teen with 16
Saved by Khalid from American Teen with 16
Lips by The xx from I See You with 16

Experiences With GraphQL

Sun, 13 Aug 2017 00:00:00 GMT

A couple of months ago I started working on a side project called TV Chat. My goal with this project was to create a website where people online could come together to chat about tv shows as they were airing live on TV. I'm a big tv watcher, and I like watching TV shows with friends and family. However my tastes don't always align with theirs. So my hope was to create TV Chat so that I could chat with other fans of the show as it was airing!

Alas, the project did not come to complete fruition. As I started thinking about the cost to maintain the chatrooms and worrying about how to monetize the site so it could pay for itself, I got a little overwhelmed with the prospect of actually releasing it as a finished product and decided it would be best to put it so hard on the back burner that it's for all intents and purposes dead.

However I did code a lot when writing this app. I used it as a learning experience to create a GraphQL server with Apollo, and I even went so far to use their experimental support for GraphQL subscriptions (which turned out to be a mistake, more on that later). I learned a lot about GraphQL in this process. Things that I found worked great, and areas of difficulty I didn't expect.

Rather than have all that code go stale sitting on my laptop I figured it'd be better for it to grow old on my GitHub profile. Perhaps mature like a fine wine. Or even better, uphold the motto of 'one man's trash is another man's treasure' and maybe someone picks up development and actually polishes it into a finished product!

Enough jibber jabber. The source code is available here. An online working example is available here.

What follows are my experiences while creating a GraphQL powered React application.

GraphQL

The sad conclusion I arrived at when writing my GraphQL server was that GraphQL is not the panacea I thought it was. Before actually implementing my own GraphQL server I had just done a lot of reading about it. All the features it advertised sounded incredible, especially its ability to format responses in a way that is immediately consumable by a front-end. I wanted the ability to create a server whose schema mirrored the way in which it will be used in the front-end, and this promise was one that made me positively giddy with excitement.

For the most part that worked out fine. Learning the schema language of GraphQL was not difficult. It's fairly small, and after you learn object types and what a query and mutation is you've learned enough to immediately begin using your GraphQL server. That was pretty exciting to me, as it fulfilled the promise I was hoping for.

Things get a little more tricky when you delve into some more advanced GraphQL schema types like enums and union types. I think something that made it trickier for me to understand how to take advantage of these features was by using the graphql-tag package that let me directly write schema without having to manually write the underlying code that was being auto-generated by that package. Had I started more low level I think I would have been a little less lost.

The biggest gotchya that I experienced when writing my GraphQL server was being unaware of the cascade of DB hits that can occur if you don't use use a caching layer such as DataLoader.

Let me try and explain what I mean by that.

For the TV Chat app I have a mongo collection called chatMessages. This collection contains all the messages that are created in a chat room. The schema for the items in this collection is

{
  "user": ObjectId(),
  "show": ObjectId(),
  "message": string,
  "timestamp": Date
}

So when a user loads a chatroom, I fetch down the last 50 items in the chatMessages collection, doing additional lookups to get the full user object so I can display a user's username.

However in a chatroom an individual user may have written more than one chat message (surprising, no?), which means that my naive implementation of this GraphQL server looked up each user every time they occur in the collection. That's not exactly web scale.

For all I could tell the main suggested way to fix this was to use DataLoader as an intermediary between schema resolvers and requests to the database.

I didn't take the time to delve into DataLoader but this gotchya was one that soured me a little to GraphQL.

Don't get me wrong, I still think GraphQL has a lot of advantages over REST. However this example did illustrate a way in which GraphQL can be a little tricker to implement than a REST server.

All that is to say that it gave me a renewed apprehension to GraphQL and enforced the notion of noble old Ben that 'with great power comes great responsibility'.

However if you were to ask me, would I use GraphQL again? I would without a doubt.

Subscriptions

Since this was a chatroom application I needed to support real time updates in the UI. The best way to support real time is via WebSockets. Luckily for me experimental support for subscriptions in GraphQL had just been released, adding a way to synchronize data with a GraphQL server via WebSockets. Hurray!

However that's about where the fun stopped for me. No fault to the Apollo team, but I had a heck of a time getting my GraphQL Subscriptions working in a way that I liked. It took a lot of time reading the source code and looking at examples before I was able to piece together a solution that worked the way I wanted. However I find the resulting code to be very brittle and not intuitive at all, two things that I had not come to expect with GraphQL.

I think I would have been better served if I had just went with a vanilla WebSocket solution. Adding the higher abstractions of GraphQL was fun but difficult. It's code that every time I look at, it takes me a while to get my head back into understanding what is going on.

React

Using React with React Apollo was a lot of fun.

I found it very easy to attach my components to GraphQL requests. However I did have to learn to let go a little bit. I'm used to having explicit control over what HTTP requests are being made, but with React Apollo I had to let go. I had to trust the framework to make the requests that I wanted, when I wanted, and let go of my typical desire to control every facet of the stack. That was a little bit unnerving but I found React Apollo to behave as intuitively as I could expect.

I also found it great that the Apollo Client uses Redux underneath the hood. I love Redux and having that familiarity there gave me a sense of security and stability that was very welcomed. Using the Redux dev tools to inspect what was going on was fun to peek at, but ultimately something that I didn't find myself doing that often as most of the time Apollo just worked.

Conclusion

I had a lot of fun building my first full stack GraphQL implementation.

The server was definitely tricker to implement than the client. I don't think I've found a server implementation that I'm fully happy with yet. I need a few iterations to fully explore the full feature-set of GraphQL but having this as a first introduction was a great experience.

On the client GraphQL lived up to most of my expectations. It works great with React and React Apollo makes it a joy to integrate throughout my application. Even more exciting for me was seeing that it would be pretty easy to incrementally adopt GraphQL on the client.

GraphQL is a really cool piece of technology. I think we're at the height of hype right now and there are some deeper learnings that need to be experienced and shared before I'd expect to see it get wide adoption. But after playing around with it for a couple of months consider me a fan.

Vlog: Deep Dish Pizza and MongoDB World 2017

Sun, 23 Jul 2017 00:00:00 GMT

Last month I had the pleasure to attend MongoDB World 2017. It was my first time attending a conference as an organizer rather than an attendee. It was a lot of fun seeing behind the scenes. Getting a feel for all the work that is required to run a successful conference was a great experience. I always knew it was hard work to run a conference, but to actually see it and live it was an amazing opportunity.

Continuing my recent trend of making vlogs, I filmed one of my time in Chicago and attending MongoDB World 2017. Please enjoy.

Creating My First Atom Package: tree-view-extended

Tue, 18 Apr 2017 00:00:00 GMT

A little while ago I decided to play with Facebook's Nuclide project. I was curious what enhancements it added to Atom and if any of them would increase my workflow. I found the project altogether nice, bringing in some nice additions to Atom. However it also adds a lot of other functionality that I will never use. So I ended up disabling Nuclide, with the added features not outweighing the other cruft it added.

However there was one feature that Nuclide provides that I found a little hard to live without. They added two pieces of functionality to Atom's tree-view (the list of files on the left of your editor). The first was it would show another tree-view of all your open tabs in a horizontal list. This I found immensely useful when I had many files open, and my tabs started overflowing my editor. Browsing the list of files in a list was vastly easier.

The second feature was another tree-view that lists all your files that are under version control that are modified. This makes for a great overview of all the files that you're editing, helping you skip around your git working tree to see all the changes that are going into your next commit.

Since I missed these features so much I took the plunge and created my first Atom package, tree-view-extended.

Introducing tree-view-extended

This package adds both of the features that Nuclide provides without the extra weight of Nuclide. You can add a list of all your open files and a list of all your git modified files.

Since this was my first time making an Atom package I had to start at the very beginning (a very good place to start). I started off reading the Atom Flight Manual to get an overview of how Atom works and how packages interact with Atom.

I found the information presented in the manual to be clearly written and easy to follow. Where I ran into real problems was after finishing the manual. I wasn't really clear on what to do next. I was able to do everything the manual laid out but after that I had to start diving into the Atom API documentation and start poking around. I had to hunt and peck to see if what I wanted to accomplish was exposed by the API.

This was hard because API documentation is dry and only presents the discrete information that you're looking up. It doesn't provide any examples or how things interact with one another.

To solve that issue I looked at projects that were already doing things similar to what I wanted to accomplish. This was the real trick I used to figure out how to create my Atom package. I looked at the tree-view-open-files package and the tree-view-git-modified package to see what they were doing.

I learn best by example and having these two projects to base my package on were invaluable. It would have taken 10 times as long without having these projects to reference, and I doubt I would have persevered.

Another thing I found difficult about developing an Atom package was the development experience. It's not nearly as pleasant as creating a web app.

Setting up my environment to develop the package was not intuitive.

As far as I could tell I had to symlink my development folder into Atom's package folder via apm link. This makes it so that my package is loaded into Atom, however the source folder is pointed to my own project.

The second pain point was that I had to refresh Atom every time I wanted to see my changes. I'm used to that from web development, however it takes a solid ~5 seconds for my Atom editor to reload (I may have too many packages installed). That lag of 5s to see any change was exhausting. It made the entire experience altogether unpleasant.

In fact it's that fact alone that largely dissuades me from continuing development on the Atom package. The development experience is highly unpleasant.

I'm happy to have created an Atom package that I and others are getting value from. It was a fun little side project to hack on in a weekend.

In point of fact I'd love for this to be merged upstream into tree-view as I think this is a worthwhile feature that would benefit the community at large. Until that happens we have this package.

For me, that's the magic of Atom. If it doesn't do what you want you can change it. So I did.

The Bridge to Teaching Redux

Thu, 30 Mar 2017 00:00:00 GMT

I've long struggled with teaching Redux. It's such a fundamental different way of thinking. When I search for comparisons to ease the concepts I always find myself sputtering words that never quite bridge that gap.

I've realized the reason I struggle with teaching Redux is because there is no easy bridge that can be used to get to the island that is Redux Comprehension. A learner is typically going from Object Oriented (OO) Land to Redux’s Functional Programming (FP) Land. On FP-Land things are done differently. Not better or worse, just differently. There’s a slight mental shift in how people go about their lives on FP-Land which can be a little weird and off-putting when first encountered. If you attempt to make sense of FP-Land from OO-Land you might end up making judgements and decisions that are not correct or fair until you’ve tried to live like a native resident of FP-Land.

Getting over this initial hurdle of understanding that things are done differently in FP-Land - which is where you’ll find Redux - is the first great hurdle to becoming a native.

The next great hurdle is actually making the journey from OO-Land to FP-Land.

When learning and discovering the vastness of OO-Land you’ll occasionally have to take bridges to different parts. Learning about Singletons or Factories or other OO programming styles require bridges of comprehension that you must walk over before you can use those styles of OO correctly. These bridges remain in OO-Land so there’s no great fear of anything going wrong. If the bridge starts to creak a little too loudly you can turn around and walk back to the area of OO-Land that you already know and find comfortable.

Unfortunately the journey to FP-Land is harder. It’s harder because there is no bridge to get there. Instead you have to swim across a channel of water that separates OO-Land from FP-Land. Swimming is harder than walking.

During this swim you’re performing double duty: not only do you have to keep your head above water and remain afloat but you also have to learn all the different ways that people do things on FP-Land, where Redux resides. While you’re swimming you’re also learning about reducers. While you’re holding your breath you’re learning about action creators. While you’re kicking your feet you’re learning about immutability.

During the swim it’s common to reminisce of happier, dryer times. Times on OO-Land where things made sense and you weren’t constantly out of breath. It’s common to try and use what you already know from OO-Land to make the swim easier. It’s fine to take short breaks and reflect on the differences between these two lands, however refrain from judging FP-Land from an OO-Land perspective. It will only make the swim harder.

Once you’ve finally made the journey across, congrats! Take a breath on FP-Land and reflect on your journey. All the new skills and ideas you picked up along the way. The benefits immutable data structures can provide. The expressiveness of composing functions. The joy of reducers!

Take some time to explore FP-Land and indulge your curiosities. You’ve made the difficult initial trek and now there’s a wealth of information that is much easier to access. You’ll encounter a couple of bridges of comprehension on FP-Land but that’ll be no sweat compared to the swim you just took.

Just don’t get too comfortable on FP-Land. You’ll want and need to visit OO-Land again. Unfortunately you’ll have to make that swim again. However each time you make that swim it’ll get easier. Then one day you won’t even notice the water. You’ll be a native on every land.

React Native NYC Meetup

Wed, 25 Jan 2017 00:00:00 GMT

I gave my presentation on React Native ART and D3 at the React Native NYC Meetup.

ForwardJS Course

Thu, 19 Jan 2017 00:00:00 GMT

I gave a workshop for ForwardJS 2017.

Top 10 Albums of 2016

Sat, 31 Dec 2016 00:00:00 GMT

2016 was a damn good year for music. Great albums were released by established and new artists alike. My favorite moments this year were when I tried a new album from an established artist and found myself appreciating their new sound and style.

Two marquee moments this year were when The Avalanches and Frank Ocean released their sophomore albums. They were years in the making, and while they didn't fully live up to the cachet of their debut albums, they were welcome additions to the musical landscape.

I enjoy writing these posts every year as they force me to reflect. I'm a big music listener. Sometimes I can get caught up on always focusing on what's coming, rather than what's already arrived. I almost forgot how many big albums were released this year. It made creating this list particularly difficult. I had to revise and shuffle around my choices until I finally arrived at an order I was happy with.

Naturally there were a couple of albums that were really good, but not good enough to make my top 10 list. Those are, naturally, my list of honorable mentions:

J. Cole "4 Your Eyez Only"
Hamilton Leithauser and Rostam Batmanglij "I Had a Dream That You Were Mine"
Flume "Skin"
Mac Miller "The Divine Feminine"
Phantogram "Three"
Kanye West "The Life of Pablo"
Radiohead "A Moon Shaped Pool"
Solange "A Seat at the Table"
Yuck "Stranger Things"

Top 10 Albums of 2016

10. The Weeknd "Starboy"

Following up on the break-out success of his previous album, The Weeknd tries to replicate that past success to mixed results. While there are more than a handful of poppy and danceable tracks the album slightly smells of trying a little hard. That's an impressive note because despite that tinge of rancor the tracks that make up the album are very strong. I was definitely playing this album on loop for a while as the songs were just so good.

9. Drake "Views"

Drake's first true album since 2013. Surprising, since he always manages to stay on the airwaves, with either a guest spot or a single getting pushed out. Yet there's something uniquely exciting about a Drake album. They always have a vibe and flow that stays consistent from track to track. This album continues that tradition, making every listen enjoyable and fluid.

8. Whitney "Light Upon the Lake"

This album evokes emotions of relaxing, freewheeling, and hanging out with all your favorite buds. It brings me back to younger days when the days were long and the nights were longer. I can't get enough. If I'm having a bad day I can hit play and let "Light Upon the Lake" remind me of all the times that were good.

7. Kendrick Lamar "Untitled Unmastered"

This album effortlessly puts to rest any doubts anyone may have had of Kendrick Lamar's talent. A compilation of unreleased demos from his previous album, this album is stronger than the focused efforts of other artists. I must have played track 3 more times than I can remember. The groove and lyrics on that track resonate so strong.

6. Childish Gambino "Awaken, My Love!"

I was not a Childish Gambino fan until this album. That makes sense as this album is unlike all of his previous releases. More avant-garde R&B than mainstream rap, this album sways with such confidence and eccentricities that I immediately fell in love. It almost seems as if this album was plucked from the 1970s, a lost relic from that time. This album is unique and a welcome addition to the musical landscape of 2016.

5. The Avalanches "Wildflower"

I was so excited for this album's release, along with everyone else. A 16 year gap between album releases is unheard of but that's The Avalanches for you. Their debut album was such a smash hit that I think literally anything released after was going to be a bit of a let down. Yes, "Wildflower" is not as good as their debut. It does not flow as effortlessly as "Since I Left You", however the individual tracks are just as strong. I think that's the major detractor to "Wildflower", as an album it's not as good as "Since I Left You", yet its tracks are just as eccentric and catchy. "The Noisy Eater" and "Subways" are my top two listened tracks.

4. Chance the Rapper "Coloring Book"

One of the most popular artists that has yet to release a true album. If this is what a mixtape sounds like then I literally can't wait to hear Chance's first studio album. This album is brimming with hits and standouts, spanning a variety of genres, from upbeat hip-hop to soothing R&B. The tracks are catchy yet deep, mixing genres with ease. Hearing a saxophone and a church choir soar over Chance's rap sends chills down my spine.

3. Bon Iver "22, A Million"

As the going gets tough the tough get going; as Bon Iver gets weird, the weird get weirder. Part human, part machine, this album manages to remain completely accessible despite its android-esque accompaniment. Bon Iver grinds his otherwise angelic voice through a computer meat shredder and it manages to remain beautiful. An album that would not work if attempted by any other artist. I'm just so curious to hear what comes next.

2. Frank Ocean "Blonde"

Like The Avalanches, Frank Ocean is another artist whose sophomore release was eagerly anticipated. Thankfully the gap between his debut and "Blonde" was only four years. On first listen of "Blonde" I came away disappointed as I was hoping for more of "channel ORANGE". Yet that was misguided. Artists should grow and evolve, and that is "Blonde". Always beautiful, and often sad, "Blonde" is an album that Frank Ocean needed to break his creative paralysis. The result is a collection of songs that are less immediately accessible, yet ones that blossom on repeat listens. After giving each track their due time you'll find the beauty hidden within. Most surprising was the deep melancholy and sorrow that tinges most tracks. There's heartache hidden within "Blonde", shown and explored with courage and talent.

1. Jack Garratt "Phase"

This album was my most played during 2016. Part Disclosure, part Sam Smith, Jack Garratt set himself apart from all other artists in 2016. Each track ebbs and flows, erupting from whisper to growl in the space of a breath. I was fortunate enough to see Jack Garratt live and it remains one of my top live shows. It's easy to see the love and care he puts into every song. The talent required is also impressive as he is a one man band. Performing live he switches from keyboard, to drum machine, to guitar all within the span of a song. Each song on this album is strong and contagious. Even now while giving "Phase" a re-listen, I find myself dancing and singing along. Give "Phase" a listen. You will not regret it.

React Native ART Presentation

Mon, 19 Dec 2016 00:00:00 GMT

Earlier this year I had the great opportunity to be a speaker at the Crater Remote Conference. I presented about my experiences with using React Native ART and D3, giving a complete walkthrough and explanation of my example application BetterWeather.

The recording of this talk was recently posted online and I wanted to share it with you all.

There's a slight technical snafu that happens in the first 5 minutes but after that it's smooth sailing.

Enjoy!

Introducing Reptar 2.0.0

Fri, 21 Oct 2016 00:00:00 GMT

Introducing Reptar 2.0.0!

It is with great pride that I announce the release Reptar 2.0.0, a static site generator that roars. Install it now!

npm install -g reptar

Now hold on a second, you might be asking yourself, What happened to Reptar 1.0.0? Well Reptar is actually the static site generator formerly known as Yarn. Yarn was renamed to Reptar because another NPM module was recently released that chose Yarn as its name. It has become wildly popular in a short amount of time, in large thanks to the people and organizations that helped create it. Rather than fight for market or mind share I chose to rename Yarn to the new and ever more rawsome Reptar.

Reptar 2.0.0 comes with a very exciting list of new features and bug fixes.

One of the most exciting new features is the super charged watch mode. Watch mode creates a local web server of your site that is able to reflect any changes you make instantly and without having to rebuild every static file. This is accomplished by lazily rendering only the page that is requested, allowing Reptar to quickly sync with the file system and render the latest changes immediately. This makes for a great workflow when writing a new post or updating your theme - those changes are immediately visible. You can start watch mode via reptar watch.

Some other exciting new features:

Reptar now has _config.yml validation. If Reptar notices that you have misconfigured your site it will immediately tell you where and why it is misconfigured.
Data files are now supported! This was a requested feature and I am happy that Reptar now supports data files of .yaml or json.

See the full list of changes in the CHANGELOG.

Upgrading

If you were using Yarn 1.x then there are two steps required to upgrading to Reptar.

The first is to install Reptar npm install -g reptar.

The second is updating your _config.yml file as there were breaking changes.

The _config.yml validation will tell you what is wrong but it is easier to see the changes by looking at a diff of the changes. Explanations are inline as comments.

path:
  source:      ./
  destination: ./_site
  plugins:     ./_plugins
  themes:      ./_themes
# Reptar now has support for data files!
+  data:        ./_data

file:
   # Support for File defaults has been added!
   # These are optional settings however it's mostly moving
   # configuration that was on the `collections` field before.
+  defaults:
+    -
+      scope:
+         # Any file in this path will have the default values applied.
+         path: ./
+      values:
+        template: page
+        permalink: /:title/
+    -
+      scope:
+         # Any file in this path will have the default values applied.
+         # Because this path is more specific it will over-write the previous
+         # defaults.
+         path: ./_posts
+      values:
+        template: post
+        permalink: /:title/
+    -
+      scope:
+         # Any file with this matching metadata will have the default values applied.
+         metadata:
+           draft: true
+      values:
+        template: draft
   # Filter settings were moved to under `file`.
+  filters:
+    metadata:
+      draft: true
+    future_date:
+      key: date

collections:
   # These settings are now better handled as a File default.
-  default:
-    path: ./
-    template: page
   # Static collections no longer exist.
-  images:
-    static: true
  post:
    path: ./_posts
     # Moved from being under `pagination`.
+    template: index
     # Moved from being under `pagination`.
+    page_size: 6
     # Permalink is removed.
-    permalink: /:title/
     # Filter is moved to `file`.
-    filter:
-      metadata:
-        draft: true
-      future_date:
-        key: date
     # Renamed.
-    pagination:
+    permalink:
       # Moved up one level.
-      template: index
-      size: 6
       # Renamed
-      permalink_index: /
+      index: /
       # Renamed
-      permalink_page:  /page/:page/
+      page:  /page/:page/

# Moved the follow top level properties to new top level `markdown`.
-markdown_extension:
-  - md
-markdown:    remarkable
-highlighter: highlight.js
-remarkable:
-  preset:       'commonmark'
-  highlight:    true

+markdown:
+  extensions:
+    - md
+  options:
+    preset:       'commonmark'
+    highlight:    true

Thank You

I want to thank everyone for their support of Reptar. It's been so much fun building Reptar and using it daily for my own site.

One of the big new upcoming features I have planned for Reptar is to create an admin dashboard so you can edit your Reptar site as easily as if it was a WordPress site - except it's still a static site! If that sounds exciting and fun then please join and help code!

React Native ART and D3

Fri, 05 Aug 2016 03:59:27 GMT

This is a follow up to my previous article about my experiences using React Native

I gave a talk on this topic which you can watch

The most powerful feature of React Native is that it lets you write your native application using React and JavaScript. React is certainly powerful as it greatly simplifies the mental model required when constructing your UI. However what's even more powerful is the ability to use JavaScript. There's a huge ecosystem of JavaScript packages available. There's a package for almost anything that you might need for your web application. And thanks to React Native almost all of them can be used in your mobile application.

One of the most powerful JavaScript package available for graphing is d3.js. It is battle tested and robust, and the de facto library to use to create a graph on your website. To get a feeling for how expressive you can be with d3 just check out its example gallery. I'm always in awe at some of the things you can create with the simple primitives that d3 provides.

For a project I worked on I had to create graphs in a React Native application. To achieve this goal I used D3 within React Native. In this article I'm going to introduce you to how to create D3 graphs in a React Native application.

This article is also based on a talk I gave for Crater Remote Conference. The slides are accessible here and I will link to the video as soon as it's available.

This article assumes you are already familiar with React Native. If you're not please read the tutorial on React Native's webpage to get up to speed.

There's a few pre-requisites I need to explain before I can get to how to integrate D3 into React Native. Bear with me as I provide some helpful background information before we delve into the meat of things.

D3

Hopefully if you're reading this you have a vague understanding of what D3 is, and what it can do. In brief D3 provides primitive functions that let you easily convert data into graphs. It provides a suite of modules that you can use to construct the graphs you want to build.

For our purposes we're going to focus on two modules, d3-scale and d3-shape. These are the only two modules we need to learn to create a graph in our React Native application.

d3-scale

Scales are the building blocks for every graph you'll ever create. They are the glue that let you take data of any shape and size and convert it into a graph.

d3-scales provides a few different scale types, but for now we're going to focus just on continuous scales.

As explained in the documentation:

Continuous scales map a continuous, quantitative input domain to a continuous output range. Given a value from the domain, returns the corresponding value from the range.

So let's say we wanted to map an array of test scores to a graph. The test scores are between 0-100 and we want to graph the height of each test score on our screen, which has a height of 640 pixels.

To graph that with d3-scale we create a continuous linear scale:

// Create a new linear scale instance, which we'll use as your y-scale.
const y = d3
  .scaleLinear()
  // Set our domain, which is our input data, which is our test scores,
  // which can be between 0 and 100.
  .domain([0, 100])
  // Set our range, which is our output data, which is the height of our
  // screen, which is 640 pixels.
  .range([0, 640]);

// Now if we want to know how high a test score of 50 is on our screen
// we pass the value from our domain and get our range of 320.
y(50); // 320
// Same thing here with 80.
y(80); // 512

There's a variant of linear scales that we're also going to use called time scales.

Time scales are a variant of linear scales that have a temporal domain: domain values are coerced to dates rather than numbers

Meaning, that instead of just using numbers for our domain we're going to use dates. This is useful when trying to show how data changes over time.

// Create our x-scale.
const x = d3
  .scaleTime()
  // Our domain is now a week of time.
  .domain([new Date(2000, 0, 1), new Date(2000, 0, 8)])
  // That we're going to show on our screen which is also 640 pixels wide.
  .range([0, 640]);

// We can then get the x position for the second day of the week.
x(new Date(2000, 0, 2)); // 91.42857142857142
// And the seventh day!
x(new Date(2000, 0, 7)); // 548.5714285714286

d3-shape

The d3-shape module "provides a variety of shape generators for your convenience" which you use to actually draw your data to a graph. For now d3-shape can render to either SVG or Canvas. For our use case we're going to focus on the SVG rendering capabilities.

d3-shape

The only shape we're going to use is the line generator which is "used to compute the d attribute of an SVG path element"

So let's say we wanted to graph the weather forecast for a week. After we create our x and y-scales we can then use the line generator to create the d attribute for the SVG Path element:

// Our array of data we're graphing.
const data = [
  {date: new Date(2000, 1, 1), value: 83.24},
  {date: new Date(2000, 1, 2), value: 85.35},
  {date: new Date(2000, 1, 3), value: 98.84},
  {date: new Date(2000, 1, 4), value: 79.92},
  {date: new Date(2000, 1, 5), value: 83.80},
  {date: new Date(2000, 1, 6), value: 88.47},
  {date: new Date(2000, 1, 7), value: 94.47},
  …
];

// Create our line generator.
const line = d3.line()
  // For every x value create the x accessor,
  // which uses our x scale function.
  .x(function(d) { return x(d.date); })
  // Make our y accessor.
  .y(function(d) { return y(d.value); });

// Given the data create the d path value!
line(data);
// M10 80 C 40 10, 65 10, 95 80 S 150 150, 180 80

The x and y accessor's that we use are discussed more in-depth on the documentation, however the point of them is that D3 uses those functions to compute where to plot every data point on the graph.

How does D3 work with React Native?

React Native has a library called React Native ART which can render SVG shapes and paths. By using D3 to create the d attribute and giving that to React Native ART we can render any graph that is produced by D3.

React Native ART is derived from React ART. React ART provides a React components that can be used to control the ART library.

ART is a retained mode vector drawing API

So that means that instead of having to write an SVG image by hand like so:

<svg>
  <g>
    <rect width="100" height="100" x="10" y="10" fill="blue" />
  </g>
</svg>

You can use ART's API.

const art = ART.Surface(1000, 600);

const group = ART.Group().inject(art);

const blue = ART.Rectangle(100, 100);
  .move(10, 10)
  .fill('blue')
  .inject(group);

React ART is a JavaScript library for drawing vector graphics using React. It provides declarative and reactive bindings to the ART library.

With React ART you can write your ART commands as React components.

function ReactART() {
  return (
    <Surface width={1000} height={600}>
      <Group>
        <Rectangle width={100} height={100} x={10} y={10} fill="blue" />
      </Group>
    </Surface>
  );
}

Then with React Native ART you can do the same but in your React Native application.

import React from 'react';
import {
  ART,
  View,
} from 'react-native';
const {
  Surface,
  Group,
  Shape,
} = ART;

function ReactNativeART() {
  return (
    <View>
      <Surface width={500} height={500}>
        <Group x={100} y={0}>
          <Shape
            d="M10 80 C 40 10, 65 10, 95 80 S 150 150, 180 80"
            stroke="#000"
            strokeWidth={1}
        </Group>
      </Surface>
    </View>
  )
}

React Native ART is not included by default in React Native. Most applications don't need to render SVG shapes, so the React Native team felt it was better to exclude it by default, saving file size of your application.

Before you can use React Native ART you need to link the native library. React Native's website has a guide on how to link libraries.

You can also follow this excellent guide on getting started with React Native ART.

Example Application

To help show off what we can make with React Native and D3 I created an example application called BetterWeather. It's hosted on my GitHub account. Each commit is composed so you can read them from start to finish and see what was done to get to the next iteration of the application. I strongly encourage you to read through the source code as its well documented and meant for reading.

BetterWeather is a simple weather forecast application. It graphs the upcoming week of weather. It also animates between the temperature min and max for the next week. It uses the Forecast.io API as its data source.

Code

There's two sides to creating a D3 graph in a React Native application.

The first is using React Native ART.

After you've linked the native code for React Native ART you can start to use it in your code:

// Snippet based on https://github.com/hswolff/BetterWeather/blob/master/js/weather/WeatherGraph.js
import React, { Component } from 'react';
import { ART } from 'react-native';

const { Group, Shape, Surface } = ART;

class WeatherGraph extends Component {
  render() {
    return (
      <Surface width={200} height={100}>
        <Group x={0} y={0}>
          <Shape d={this.props.linePath} stroke="#000" strokeWidth={1} />
        </Group>
      </Surface>
    );
  }
}

// Used via:
// <WeatherGraph lineGraph={...} />

This uses the React Native ART components to render to the screen. It should look just like any other React components and that's because it is. This creates an ART <Surface />, which we can think of as the <svg /> tag, which houses the <Group /> which is akin to an SVG's <g /> element, which finally houses the <Shape /> component which is akin to an SVG's <path /> element. The <Shape />'s d={} attribute is just like the <path /> d attribute.

This is where the second side comes in - D3.

We're going to use D3 to create the value that will go inside the d={} attribute.

// Snippet based on https://github.com/hswolff/BetterWeather/blob/master/js/weather/graph-utils.js
import * as scale from 'd3-scale';
import * as shape from 'd3-shape';
import * as d3Array from 'd3-array';
const d3 = {
  scale,
  shape,
};

export function createLineGraph({
  // This is the data that we get from the API.
  data,
  width,
  height,
}) {
  // Get last item in the array.
  const lastDatum = data[data.length - 1];

  // Create our x-scale.
  const scaleX = createScaleX(data[0].time, lastDatum.time, width);

  // Collect all y values.
  const allYValues = data.reduce((all, datum) => {
    all.push(datum.temperatureMax);
    return all;
  }, []);

  // Get the min and max y value.
  const extentY = d3Array.extent(allYValues);

  // Create our y-scale.
  const scaleY = createScaleY(extentY[0], extentY[1], height);

  // Use the d3-shape line generator to create the `d={}` attribute value.
  const lineShape = d3.shape
    .line()
    // For every x and y-point in our line shape we are given an item from our
    // array which we pass through our scale function so we map the domain value
    // to the range value.
    .x(d => scaleX(d.time))
    .y(d => scaleY(d.temperatureMax));

  return {
    // Pass in our array of data to our line generator to produce the `d={}`
    // attribute value that will go into our `<Shape />` component.
    path: lineShape(data),
  };
}

// Used via:
// const dAttribute = createLineGraph({
//   data, // From API.
//   width: 200,
//   height: 100,
// });
// <WeatherGraph lineGraph={dAttribute} />

So what you see here is us using D3 to create our x and y scales so we can map our data from its domain (the original values) to the range which we want to output it (our app screen).

We then use the line generator to create the d={} attribute that we need for our <Shape /> component.

From there the React Native ART component has enough information to render the shape in our app!

What you saw above was an abridged version of the work that was done in this commit in the BetterWeather repo. To see a more rich example I strongly encourage you to check out that commit and leave any comments you may have so I can address any confusions directly.

Axis

The next step you should take to make a richer graph is to add axis. This does not require any special React Native ART knowledge as you can create graphs using regular React Native <View /> and <Text /> components. The main trick is to leverage D3 so you have enough information to lay out your components correctly.

// Extend what is returned from createLineGraph
export function createLineGraph() {
  // ... previous content omitted.
  return {
    ticks: data.map((datum) => {
      const time = datum.time;
      const value = datum.temperatureMax;

      return {
        x: scaleX(time),
        y: scaleY(value),
        datum,
      };
    }),
  };
}

// Extend our WeatherGraph component.
// Within its render() function:
class WeatherGraph extends Component {
  render() {
    return (
      // ...previous content omitted.
      <View key={'ticksX'}>
        {this.props.ticks.map((tick, index) => {
          const tickStyles = {};
          tickStyles.left = tick.x;

          return (
            <Text key={index} style={[styles.tickLabelX, tickStyles]}>
              {new Date(tick.datum.time * 1000)}
            </Text>
          );
        })}
      </View>

      <View key={'ticksY'}>
        {this.props.ticks.map((tick, index) => {
          const value = tick.datum.temperatureMax;

          const tickStyles = {};
          tickStyles.left = tick.x;
          tickStyles.top = tick.y;

          return (
            <View key={index} style={[styles.tickLabelY, tickStyles]}>
              <Text style={styles.tickLabelYText}>
                {value}&deg;
              </Text>
            </View>
          );
        })}
      </View>
    )
  }
}

After getting the x and y values for every position of the line we just use position: absolute to layout the <View /> components for our axis!

For the full implementation example please consult the commit on the BetterWeather repo.

Animate

The only thing cooler than creating graphs in our React Native application is animating them.

The main trick to animating graphs is to use the ART library's Morph module. The Morph module allows you to tween from one d={} attribute value to another. It handles all the tricky calculations required to create the shapes that exist in-between one path and another.

We then use a standard requestAnimationFrame loop along with this.setState to render our animations.

import Morph from 'art/morph/path';

// Extending WeatherGraph some more...
class WeatherGraph extends Component {
  componentWillReceiveProps(nextProps) {
    if (this.props.data !== nextProps.data) {
      const nextLinePath = createLineGraph({
        data: nextProps.data,
        width: 200,
        height: 100,
      });

      this.setState(
        {
          // Create the ART Morph.Tween instance.
          linePath: Morph.Tween(this.previousGraph, nextLinePath),
        },
        () => {
          // Kick off our animations!
          this.animate();
        }
      );
    }
  }

  animate(start) {
    this.animating = requestAnimationFrame(timestamp => {
      if (!start) {
        start = timestamp;
      }

      // Get the delta on how far long in our animation we are.
      const delta = (timestamp - start) / AnimationDurationMs;

      // If we're above 1 then our animation should be complete.
      if (delta > 1) {
        this.animating = null;
        // Just to be safe set our final value to the new graph path.
        this.setState({
          linePath: this.previousGraph.path,
        });

        // Stop our animation loop.
        return;
      }

      // Tween the SVG path value according to what delta we're currently at.
      this.state.linePath.tween(delta);

      // Update our state with the new tween value and then jump back into
      // this loop.
      this.setState(this.state, () => {
        this.animate(start);
      });
    });
  }
}

Here we calculate the nextLinePath when we see that our data changes. We then use the Morph module to create the beginning of our tween, and then begin our requestAnimationFrame loop to animate each point in our tween animation.

I strongly encourage you to check out the full commit on the BetterWeather repo to see the full implementation.

Also I strongly encourage you to read this excellent blog post on using the Morph module. It's where I took my original inspiration from.

Wrapping Up

Hopefully by this point you should know a lot more than you did before you read this blog post.

Using D3 with React Native opens up a world of opportunities for what you can do with your React Native applications. D3 is so powerful and flexible that the possibilities of what you can create are far to great for me to even imagine.

I'm very curious to see what people come up with and how they manage to use these two technologies. Please leave a reply with any cool examples you may find, and please let me know if anything I explained above was not clear.

Thanks so much for reading!

React Native

Wed, 29 Jun 2016 01:14:36 GMT

A couple of months ago I wrote a React Native application, the new Chartbeat iOS App. It was a great experience. I got to learn a lot about React Native and was able to create and launch an app. If there's anything I like more than writing software, it's releasing it.

I was able to give a talk recently at SyntaxCon about getting started with React Native. I named the talk Going Native with React Native and you can check out the slides at your leisure. As soon as the video is up I'll link to it.

I've wanted to write about my experience with React Native for a long time but haven't had the opportunity to do so until now. A lot of the content for my talk was derived from my experiences working on React Native while developing the Chartbeat iOS app. That'll be true for this post as well. I'm considering this post the written form of that talk.

Picking React Native

I started working with React Native way back in September 2015. At this point in time React Native was at version 0.11.0-rc and Android support was not yet released. Before we even decided to use React Native as the foundation for the new mobile app I looked around at the various options available on the market.

There is Cordova (Phonegap) which I've used before. At a previous job I helped create a Phonegap application and did not have the greatest experience. For all of its benefits there are a fair amount of short comings. Looking into Phonegap after more than two years away showed that not much had changed. You still needed to re-implement every native control using web technologies and web is still slower than native.

There are a couple of compile to native platforms still available. Xamarin wasn't considered as I'm not a fluent C# engineer and I didn't want to learn Xamarin and C# at the same time. I've used Appcelerator at a previous job as well and had very negative experiences.

Ultimately the decision came down to writing the application 100% natively or use React Native. We wanted to write an Android app as well and the promise of React Native to support both platforms with the same codebase pushed us to pick it. The fact that React Native was built on top of React gave me an immediate edge as I already knew how to use React, giving me a jump start.

It also didn't hurt that picking React Native meant I got to play with an exciting new piece of technology. That's not a sound technical reason but it makes for a powerful motivational reason. That meant working late nights and weekends were a pleasure as I was able to work on something that I was genuinely excited about.

Built on React

It's hard to understate how powerful it is that React Native is built on top of React. This gives you an immediate advantage when writing a React Native application as you already have a solid understanding of how things work.

We all know and love React's declarative nature, and React Native continues that tradition. Feel free to declaratively write your components as you would with React. The main difference is the base components you use.

Instead of <div /> and <span /> you use <View /> and <Text />. React Native provides a suite of base UI components that you can use, and for almost all cases you can find ways to make those components do whatever it is your application needs.

This simple sidestep, of just providing additional base UI components is what allows projects such as react-native-web to exist as they're just a re-implementation of these components, targeted towards the web.

JavaScript Ecosystem

Since React Native application-level code is written in JavaScript and ran by a JavaScript engine at runtime this means one glorious thing: you can use pretty much the entire npm ecosystem in your React Native application.

The only restriction is the npm package can't touch the DOM, because well, there is no DOM in a React Native application.

That means that you're able to use all your old favorites such as lodash or Redux. It also gives you the feeling of being completely empowered as you have thousands upon thousands of npm packages ready for inclusion in your React Native application.

CSS in JavaScript

Before I started using React Native I knew that its approach to layout and styles was not conventional, at least not in the web sense. React Native leverages JavaScript to style your app, meaning that all layout and style is written in a .js file.

This sounded heretical when I first came across it. It flew in the face of so many conventions and practices that I had instilled into every fiber of my developer body.

Yet after I started writing styles in JavaScript I realized one unexpected truth:

I loved it.

As I've said to countless people I have drank the Kool-Aid hard and I am now a firm believer in the power of writing your styles in JavaScript.

It provides so many niceties.

You have the full expressive power of JavaScript at your disposal when writing your styles.
You can treat shared styles as a regular old JavaScript object, sharing them between modules as you would anything else.
When you open a component to see what it does you also get all of its styles in the same file. That means that you know everything you want about a component by just looking at one file.

I'm looking for the smoking-gun solution for styles in JavaScript for the web, and as soon as I find it I'm immediately switching to it. I absolutely loved writing my CSS this way.

Developer Experience

The development workflow used when writing a React Native application has more in common with the web than it does with a native iOS or Android application.

React Native supports live reloading and hot reloading out of the box. You make a change to a file and see the changes almost instantly applied to the screen. This immediate feedback loop allows you to experiment without fear. It also makes the pixel-perfecting process a breeze as you can easily live-tweak with a designer.

You can also hook up React Native to a Chrome Developer Console, giving you access to poke around the application as it's running, just as you would a web app. You can set breakpoints, log out to the console, and even start poking around the code via the REPL provided by Chrome Dev tools.

I've written native applications in the past and the developer experience that React Native provides is unparalleled. You get all the tools a web developer gets, yet it gets rendered into a native application.

Easy Escape Hatches

While React Native provides a lot out of the box it's easy to drop down to native land. React Native was built to be extended and you can easily add your own custom UI components or native modules.

This gives you the freedom to write as much custom code as you need without having to worry about React Native prescribing what you can or cannot do.

React Native Moves Fast

When I started using React Native in September 2015 it was at version 0.11.0-rc. At the time this post was written, June 2016, React Native is now at 0.29.0-rc. There's been 18 releases in under a year, and there doesn't seem to be any signs of that release pace slowing down.

Coming from native iOS and Android that pace of development is unthinkable. In those native platforms you're used to one major release a year. React Native is going the opposite path, choosing to release frequently and with smaller changes.

Yet some of those version bumps contained some pretty big changes. When Android support was added in fall of 2015 that was just a version bump but that's one hefty changeset.

And from version 0.11.0 till around 0.19.0 almost every release held some pretty big changes. I haven't used recent versions but from reading the release notes it seems like the amount of breaking changes is subsiding, making for a less volatile upgrade process.

Native Knowledge Not Required

People always ask me, 'Do I need to know the native platform to use React Native?'

The short answer is no.

You can go a very long way just skating between the lines that React Native provides for you. The base UI components and built-in native modules provide an incredible amount of flexibility when it comes to writing your React Native application that for almost all apps you will never have to worry about writing custom Swift or Java code.

That being said, you should know the UI and UX patterns that are used by your native platform. What that means is you should understand how and why the dedicated Android back button exists. Or you should understand what is a ShareSheet on iOS.

If you want your app to feel truly native you need to understand how the native platform performs certain tasks so your app feels truly native to the platform.

Conclusion

I'm dying to write my next React Native application. I had some of the most fun I've had in a long time writing the Chartbeat iOS app. The React Native framework provides an awesome developer experience in an environment that is historically a cumbersome to develop for.

Not only am I itching to write my next React Native application I'm also looking to see if I can obtain the holy grail of write once and have the code work on iOS, Android, and the web (using react-native-web). If that can be accomplished then I'll be as pleased as a peach.

Introducing Yarn

Sun, 10 Apr 2016 21:34:46 GMT

Note! Yarn has been renamed to Reptar

Hello everyone! I want to introduce you to my newest creation, Yarn!

Yarn is a static site generator that I wrote. It was built due to my frustrations with the current static site generators available. I figured, "Hey, it can't be that hard to write my own static site generator!" So I started working on Yarn. Seven months later and I'm now proud to introduce the first stable version of Yarn, 1.0.0.

If I had known it would take me over half a year to complete this project I probably wouldn't have even bothered, but that's the benefit of forgoing thorough forethought.

This blog is now proudly created with Yarn as well!

Why did I even want to start using a static site generator? To answer that I have to take you back to 2010.

And if you're just curious about hearing about Yarn then scroll down to the Yarn section

The Beginning

Back in 2010 I started blogging. I thought it would be a good way to build my brand as well as give myself a creative outlet. I was coding most of the time during my day job, but I very much enjoy writing, and wanted to have somewhere to put my words. So my blog began.

In 2010 the de facto way to blog was with WordPress. So that's what I started out on. I set up my own self-hosted WordPress installation and went on my merry way.

For three years I was fine blogging with WordPress. It was easy to use, easy to maintain. I had no real complaints.

Except at some point in 2014 I started getting bored of WordPress. Not only bored but a little annoyed at the sluggishness of the WordPress admin. Also I didn't enjoy having to delve into PHP to make any meaningful change to how my blog worked. Making a new theme required learning the WordPress template language, something that I did not want to bother with.

So I decided I need a change.

A Ghoulish Diversion

As luck would have it Ghost had just come onto the scene. It billed itself as a streamlined WordPress, focused only on blogging. And the best part? It was written in Node.js. Hallelujah!

So I ported my blog to Ghost. And for a year I used Ghost to run my blog.

I also began contributing to the Ghost project. I was a core contributor to the project for around six months, lending my hand to improve Ghost in any way that I could.

Ghost was harder to deploy than WordPress as it is a Node.js application. I didn't have much experience deploying Node.js applications so I had to learn. It wasn't terrible, but it was definitely an adoption cost that I hadn't expected.

Everything was going well. Until one day when it wasn't.

Upgrading Ghost was a mild chore. I wasn't using Ghost in the #blessed manner and as such had an extra cost whenever I had to upgrade. Sometimes my Ghost process had a memory leak that would cause my hosting provider to kill the process to prevent it from affecting the shared host it was on.

Also at some point I stopped contributing to the Ghost project.

All these things combined pushed me to migrate away from Ghost.

Static Electricity

After Ghost I finally told myself that enough was enough and that it was time to pare my blog down to its barest essentials.

That's right. It was time to go static site generator.

Being a JavaScript man I looked at what static site generators were written in JavaScript.

I eventually ended up going with metalsmith. I liked its minimalistic approach and its customizability.

However when I sat down to actually port my Ghost (which was ported from WordPress) blog to metalsmith I found myself needing to turn to the myriad of metalsmith plug-ins. To get my metalsmith blog to feature parity with my Ghost blog I had to write a mountain of configuration.

So I got it working, and it was good, but holy shit was that a lot of work.

I thought to myself, "Surely there's something better?"

Do It Yourself

I found that mountain of configuration quite brittle. Sometimes my blog wouldn't compile for reasons that I never cared enough to track down. I knew that I needed to move (again!) to something new.

The most popular static site generator written in JavaScript (remember: I'm a JS dev!) is hexo. And while it's certainly mature and powerful it didn't provide all the features that I wanted my blog to have. Primarily I wanted easy pagination support and support for tag pages.

Even when I looked at Jekyll it didn't provide the features I wanted. If I wanted that functionality I either had to hack in support or turn to a plug-in.

At this point I thought, "Enough is enough." And so, Yarn was born.

Yarn

Yarn was created to have feature parity with Ghost, which had feature parity with (the blogging aspect) of WordPress. The only twist was that Yarn would be a static site generator. No need to run a server process or have to worry about maintaining a node.js application on your web host.

All you needed was the ability to rsync your compiled code, and you'd be good to go!

Yarn has built-in support for pagination of files, along with support for tag pages. It's capable of this behavior due to sensible primitive constructs.

The basic building block of Yarn is that of collections. Yarn inspects your local files and organizes them into collections based upon either their location in the file system or the meta data that is contained in the file.

Through this simple abstraction Yarn is able to derive a great deal of information. It allows Yarn to be expressive and flexible as all it needs is to be told how to construct its collections.

Also Yarn was built using the latest JavaScript specification, specifically ES2015+. While I could lie and say this was to move the JavaScript community forward I would be lying. I enjoy writing ES2015+ JavaScript. It's more pleasurable to write JavaScript that way and it allows for more expressive and easier to understand code.

Yarn was also built to be easy to build upon. I'm hoping contributors present themselves and provide a strong future for Yarn.

The Future

I'm very proud to have shipped a version 1.0.0. I struggled about when to push Yarn to 1.0.0 as I still have many ideas on what Yarn should be able to do. It was hard deciding when to pull the trigger and declare Yarn feature complete and ready for an initial release.

I want to add API to Yarn to allow for the creation of a dashboard to administer a Yarn site. I'd like to see more collection types added to Yarn. There's so much more I want to do!

But at some point you have to stop yourself and just be ok with what you have.

I'm very proud of how far Yarn has come since its beginning. I hope the community finds it worthwhile and fun to hack on. And I can't wait for my first dedicated contributor.

I hope you enjoy Yarn. Here's to 1.0.0 and many more versions to come!

Top 10 Albums of 2015

Wed, 06 Jan 2016 14:07:21 GMT

For a long time the main way I listened to music was as an album. I would get an album and listen to it in its entirety, from start to finish. All my opinions and feelings about those tracks would be heavily shaped within the context of the album.

Occasionally I'd hear a song on the radio before hearing it on the album and it would warp my attachment to that song, and by extension the album. If the track was particularly strong it might cast a shadow over album. This would then cause a lower appreciation for the album as a whole, as there was an uneven distribution of quality.

By and large the album was the unit of measure I used to evaluate music. This made it pretty easy to look back at a year of album releases and sort them by best to worst. It's what I've done for a couple of years now.

Yet this year my listening habits changed. I started listening to more singles. This is largely thanks to Hype Machine, Spotify, and Apple Music (in that order). As a result it was much harder figuring out what were my top albums of 2015.

Nevertheless I've prevailed. It took almost a month to figure out the order, but I have my list sorted and ready for your reading enjoyment.

What I found interesting about 2015's list of top albums was that finding the top 5 albums was much easier than finding albums 6-10. I have a sneaking suspicion that albums 1-5 will live on for years to come, however albums 6-10 won't get many additional listens past 2015.

Before we get to the list let's start things off with a list of honorable mentions. These are albums that were in the running for ranking, but did not make the cut. They are albums that I did enjoy but were not good enough to get into the top 10.

In no particular order, my list of honorable mentions:

Foals "What Went Down"
Disclosure "Caracal"
Thundercat "The Beyond / Where the Giants Roam"
Seryn "Shadow Shows"
Matt & Kim "New Glow"
Lord Huron "Strange Trails"
Beirut "No No No"
CHVRCHES "Every Open Eye"

Top 10 Albums of 2015

10. Alabama Shakes "Sound & Color"

I really need more blues in my life. The growl from Alabama Shakes lead singer carries this album. She is a powerhouse. My only wish for this album was for the quality of the tracks to be more even. Some are super catchy whereas others are forgettable.

9. Mac DeMarco "Another One"

This was my first Mac DeMarco album I've listened to and I found it hugely relaxing. If I found myself wound up I would stick this album on and let the sway of his songs mellow me out. You can almost smell the reefer wafting off of the tracks.

8. Father John Misty "I Love You Honeybear"

What a character this guy is. "I Love You Honeybear" continues Father John Misty's crusade of sarcasm and glibness. Dare I say there's even more?

He still holds true to his folk roots. The songs rollick along and the lyrics are always a laugh.

7. Panda Bear "Panda Bear Meets The Grim Reaper"

I've always loved the Animal Collective crew. An experimental team that easily pulls from the pop world. Their songs slip in and out of comprehension, teasing the mind and filling it with lush musical landscapes.

I haven't listened to a good Animal Collective-esque album in a long time so "Panda Bear Meets The Grim Reaper" was very welcome.

If you've ever listened to a Panda Bear or Animal Collective album before you know what to expect, as this is more of the same here. What I liked most about this album was that it shied away from the avant-garde that Panda Bear loves and embraced tracks that were more accessible. Completely appreciated and enjoyable.

6. The Weeknd "Beauty Behind The Madness"

The Weeknd still has some growing to do. While good, this album is a little uneven. Some tracks are easy 10/10 whereas others are 6/10. I think it's because The Weeknd is an artist in transition. His last album consisted of slow jams, with nary a pop track. This album has a smattering of pop tracks, yet there still remain a healthy dose of slower songs.

The pop tracks that do exist are excellent. They've already been played across every radio station and in every mall, yet they manage to retain their replay-ability. A true testament to the success of those tracks.

I'm looking forward to the subsequent album. I hope to hear a stronger devotion to pop with an even warmer embrace of Michael Jackson. Not many artists can sing like that, but The Weeknd can.

5. Grimes "Art Angels"

Grimes is a hard band to classify. They're definitely indie however they sometimes heavily lean experimental. That's their charm.

"Art Angels" carries on this tradition. The second track is poppy yet it is followed by the third track which is half rambling, half screaming, yet entirely in Japanese. From Grimes, I'm not surprised. And it works.

The pop-inspired tracks definitely outweigh anything else. Rather the experimental urges Grimes has is funneled into these tracks, adding an addictive umami taste that left me coming back for many repeat listens.

4. Adele "25"

This was the first Adele album I listened to. Sure, I've heard all of Adele's singles over the years, however I never listened to her music in the context of an album. I used to not like this genre of music. I found it dull and boring. Now I find it relaxing and accessible. Maybe that means I've expanded my tastes.

Or maybe I'm just older.

Adele's "25" is a great adult contemporary album. There are beautiful ballads along with uplifting chants. The album has a great flow to the songs. It correctly mixes up the pace between the slow and the quick. I won't say fast, Adele always takes her time. Yet there are some songs on here that had me clapping along to the beat.

And man, she can sing, can't she?

3. Kendrick Lamar "To Pimp A Butterfly"

Everyone loved Kendrick Lamar's debut album "good kid, m.A.A.d city". It had catchy beats with raps that were excruciatingly good. This left big shoes to fill for the sophomore effort. "To Pimp A Butterfly" handled that pressure easily.

"To Pimp A Butterfly" is not what people expected. Whereas Kendrick Lamar's first album was lush with singles ready to play on the radio, "To Pimp A Butterfly" was unabashedly an album meant to be listened to in its entirety.

The entire album was less mainstream. This made it harder for me to listen to at first as I was expected a rap-pop album. Yet getting past that initial confusion uncovers an album with complex messages and avant-garde beats that show a musical prowess that leaves me curious and hunger for more.

2. Jamie xx "In Colour"

I always knew Jamie xx was a real talent. When every article written about The Xx's debut album mentioned he produced the album I knew there was something special about him. So when I heard news that he was releasing a solo album I was pretty excited. I expected it to be good.

I didn't expect it to be this good.

One of the best reviews of "In Colour" I've read pointed out that this is a minimalistic dance album. Despite a somewhat calm that permeates the tracks on the album the music remains danceable. It's an uncommon quality of the album. The track is upbeat yet also laid back. It's a beautiful dance of contrasts that adds up to a sum that is far greater than the parts.

1. Carly Rae Jepsen "Emotion"

I never expected for this album to be good. After her break-out single last year "Call Me Maybe", like everyone else I safely assumed she was going to be a one-hit wonder. A song to play in 10 years as a funny callback to hits long past.

Holy hell was I wrong.

This album, which got widespread critical acclaim, is perfect from start to back. It's a loving echo of the electronic moods from the 80s recast for present times in a package that begs for repeat listens.

I listened to this album when I walked to work, I sat on the subway, or exercised while running. The album improved every scenario.

I'd often catch myself singing along to the songs out loud and not care. The songs are just pure, beautiful, wonderful pop. Catchy yet not obnoxious and filled with simple lyrics of love and loss that are easy to connect to.

I'll be playing this album for years to come.

Technical Debt, Organizational Debt

Fri, 19 Jun 2015 01:02:06 GMT

Debt, in the context of a company, takes on many forms. From the quite literal of owing money to the more abstract concept of technical debt.

Technical debt is, to use Wikipedia's tidy definition:

The [technical] debt can be thought of as work that needs to be done before a particular job can be considered complete or proper. If the debt is not repaid, then it will keep on accumulating interest, making it hard to implement changes later on.

The idea of technical debt was devised as a shield: a way for engineers to protect themselves from the never-ending demands of their company. As a company grows and expands it creates new things. These new things are built on top of existing things. Sometimes the existing things do not provide adequate support for what is going to be built on top of them. Here a choice is faced: do you fix what exists so it properly supports something new, or do you get some gum and glue and force things together? The latter method creates technical debt.

Sure it'll work - for now. Yet if you build on top of that new thing a couple of times you'll eventually come to a point where things start to fall apart. No one wants that. So instead the idea of technical debt is thrown up like a flare, warning everyone that short-term gains can be accomplished at the cost of long-term stability.

Yet to never take on technical debt is equally foolish. For starters it's impossible to plan for the future. Trying to devise a foundation upon which all future things can be built on is not possible - for all you know the analytics platform that you created to support your company becomes completely useless when your company pivots into a freemium game production studio. Further, if you're constantly doubling back to tidy up your existing things to make space for your new things you can end up doubling your workload. It may be that the thing you changed for one new thing needs to be undone for a new new thing.

As a software engineer I'm always weighing the cost of my engineering decisions. Will this new thing I'm building create so much debt that it pushes us too close to bankruptcy? If so then I need to directly address the debt I already have before making anything new. Or perhaps this new thing that I'm creating can be used to address some existing debt while it is created? Those type of things are my favorite. It allows me to create a new thing while fixing an existing thing, making everything better once it's done.

Debt is good. It allows for speedy progress. What isn't good is accruing too much debt. As the saying goes, too much of anything is bad.

There's another type of debt a company accrues that is obvious in hindsight. I only tuned into its existence thanks to an excellent blog post by Steve Blank, 'Organizational Debt is like Technical debt – but worse'.

Steve Blank explains:

Organizational debt is all the people/culture compromises made to “just get it done” in the early stages of a startup.

He uses as an example a recent conversation he had with a startup founder entering a new round of funding. While the founder was excited about the future Blank expressed his concern for the organizational debt that had accrued:

While the company had a great plan for keeping the top executives, and had all the startup perks like free food and dogs at work, they had spent little time thinking about the organization debt accruing with first 100 employees who had built the company underneath them. These were the employees that had the institutional knowledge and hard-earned skills. Originally they had been attracted by the lure of being part of a new media company that was disrupting the old, and were working for low salaries with minimal stock. And while that had been enough to keep their heads-down and focused on their jobs, the new funding round and onslaught of new employees at much higher salaries had them looking around and updating their resumes.

Organizational debt results in a company's quick death if it is never addressed. Technical debt will hurt like hell, but it won't kill a company overnight - organizational debt will.

Companies are the sum of their employees. Organizational debt is created when you delay addressing people issues. People issues such as never attending to company culture or company processes. People want to do their work in a healthy and fulfilling way, and if the company gets in the way of those desires then it will result in a loss of people.

In truth there's limitless types of debt. Anything you put off till tomorrow won't disappear. At some point you will have to circle back and address it or else face the consequences.

The easiest way to address debt is to be aware of its existence. So long as you know that at some point in the future you'll have to double back to fix some of the shortcuts you took today, then you'll be ok.

Thanks to Jem Young for reviewing this post.

Airbnb's Management Style

Thu, 28 May 2015 02:23:57 GMT

It's always interesting to hear how other companies are managed. It gives greater context for what I experience every day at work and broadens my idea for what people are doing to improve their company.

I've been reading First Round's The Review magazine for a couple of weeks now. Some of the articles are pure recruiting fluff but a couple have some real interesting tidbits.

I found the recent article about Airbnb quite interesting. Two interesting points were made.

The first is about removing policies and replacing them with principles:

What It Means to Replace Policies with Principles

OLD POLICY: All expenses require pre-approval.

NEW PRINCIPLE: If you would think twice about spending this much from your own account, gut-check it with your manager.

“I can't tell you how much pain in my life has come from expense reports,” Curtis says. Airbnb’s old policy was a cumbersome one: Charges big and small required approval before they could be submitted. So Curtis tried replacing it with a principle, simple good judgment, using $500 as a rule of thumb for when to get a gut-check. The result? No increase in discretionary spending (but a whole lot of time saved).

Rather than create a rule for every type of behavior desired Airbnb created guiding principles that afforded individuals the freedom to use their own judgement and not becoming bogged down by endless rule minutiae.

You try to hire people that you trust and think are smart, so giving them a general idea of what you expect them should be enough. In Airbnb's case it is.

The other thing I loved was how Airbnb managed to enact change through a change in behavior as opposed to an edict:

Getting Changes to Stick

I have a theory that the only way you can affect cultural change on an organization is through positive reinforcement and social pressure.

A few years ago at Airbnb, pretty much none of the code being pushed to production was peer reviewed.

Create positive examples. Enlist a group of well-respected engineers to lead by example. In Airbnb’s case, Curtis asked a handful of senior engineers to start requesting reviews. “It created a whole bunch of examples of great code reviews that we could draw from to set examples for the team.”

...

In roughly two months, Curtis had made peer code reviews the overwhelming norm without establishing a single policy. “This is the power of positive reinforcement and social pressure to bring about cultural change in an organization. I didn't hand down any edicts, I didn't say ‘It has to be done this way from now on,’ I didn't put any formal policy in place,” he says. In fact, code reviews still aren’t enforced in any way; an engineer could still go straight to production anytime — but no one does it.

Lead by example. Or in Airbnb's case, get a group of people to lead by example and everyone else follows.

You can never underestimate the power of social pressure. Doesn't hurt that the underlying change was positive.

Try changing a company from having free lunches to having employees pay for their lunch through social pressure. That sure as hell won't work.

First Impressions of AngularJS 2.0

Tue, 21 Apr 2015 13:28:54 GMT

Over the weekend I created a clone of Hacker News with Angular2. I've read a lot about the changes Angular 2 will have and I wanted to see for myself what it would be like to create an app. What would it be like? How will it be better than Angular 1? Will I enjoy writing an Angular 2 app?

Before I delve into my impressions let me preface everything that follows with the obvious: Angular 2.0 is not done. At the time of this writing it's marked as an alpha release, so please keep that in mind when reading. Things are going to change and improve, but I just wanted to share with you my initial impressions on what it's like to create an app with Angular 2.

No Documentation, but Excellent Comments

I say there's no documentation mostly as a joke because, as I've said before, Angular 2 is not done. However what I'm always impressed by is the level and quality of comments by the Angular team in the source code. This is a great tradition that the Angular team is carrying over from Angular 1, and I would not have been able to create my app if it hadn't been for the source code comments. It's not surprising the Angular team takes such time and care to make sure their code is exhaustively commented. They actually run the source code through the dgeni documentation generator to produce their API docs. So while it was less pretty than browsing a webpage, all the documentation that will exist there is already accessible.

When I wanted to understand the additional properties that could be set with the @Component decorator, I was able to easily delve into the source code and read the comments that contained all the documentation that I could ever need for that particular decorator. This was great when I was curious about the API for a specific object. However the type of documentation that is still very much a work in progress is 'integration' or guide documentation. This is documentation that takes a high level look at how multiple objects work together to create an application, showing you how the @Component directive makes use of the DI module when you instantiate a class. There is already a good amount of progress on this type of documentation but there is still a lot left to do.

Explicit

Angular 2 is an incredibly explicit framework. This is even starker when compared against Angular 1.

In Angular 1 you're able to willy nilly use any directive that you want in any template. If you want to add a ng-repeat go right ahead, Angular will happily compile that template.

With Angular 2 you must declare what directives are used in your component. I spent a good ten minutes when making my HN app trying to figure out why my list of HN items were not being expanded by the for loop I had created (<div *for=""/> is the new <div ng-repeat=""/>). It was only after scratching my head and wondering if I had broken Angular that I realized I hadn't declared that the For directive was being used in my template.

While being explicit is great I found the boiler-plating of having to declare For, If, Switch, SwitchWhen, SwitchDefault for every component to be quite monotonous. I'm not used to having to declare what my component is using and I found that change to be a little tricky to get used to. This is definitely due to the mental switch from Angular 1 where every directive is always available, so it's just going to be something that takes some time for adjustment.

Tools

Angular 2 already seems to be shaping up to be a very tooling friendly - and heavy - framework.

It was recently announced that Angular 2 is written with TypeScript which is great as it allows you to take advantage of all of TypeScript's features, most importantly types. However I was little let down to see that internally Angular 2 is still being compiled with Traceur. I can only imagine this is a work in progress but I was sad I couldn't start using TypeScript with Angular today.

Along with TypeScript Angular includes a run-time type assertion library so that you can continue to take advantage of your type definitions when your app is running in the browser.

On top of types Angular also includes the entire Rx library so you can work with the reactive programming paradigm.

All of these are great to have included however they do come with a cost.

In my Angular 1 Hacker News app the JavaScript file size of the final application code is 194.9kb. This includes a number of external libraries: angular-animate, ui-router, lodash, firebase, and momentjs.

In my Angular 2 Hacker News app the JavaScript file size of the final application is 250kb. That only includes the firebase library as a dependency.

Due to Angular 2 being so large it takes a while to parse all the contained JavaScript code. When I created a simple 'Hello World' app before creating the HN app it seemed to take between 2-3 seconds before any content was rendered on the page. There were some moans on the Hacker News thread that the application was slow. As far as I can tell, this is why.

I'd be happy to hear from the Angular team about this. I know a lot of work has been done to make sure Angular is performant once its on the page - an entire benchmarks module has been created for this explicit purpose - but I haven't seen any mention of start-up time.

Closing Thoughts

Overall I'm extremely impressed with the progress of Angular 2. Despite being an alpha it seems to be rapidly racing towards beta status. Many of its primitive objects are already in place which is exciting. With primitives in hand it'll allow for the creation of higher-level components which I imagine is what Angular 2 developers will spend most of their time interfacing with.

As I've shown it's already possible to create a fully featured application with Angular 2. There were some instances where I found Angular 2 was not quite ready and I enumerated all of these gaps in my Todo list. The two things I'm most looking forward to is being able to use TypeScript directly with Angular and also playing around with reactive coding through the Rx library.

I'm not exactly sure when the Angular team hopes to release Angular 2 but I wouldn't be surprised if it was later this year - sometime in the fall. It's already way further along than I expected. If this is the alpha, I can't wait to see the first stable release.

Thanks to Justin Poliey (@justinpoliey) and Xavier López (@xavierelopez) for reading drafts of this post.

Essential Atom Packages

Wed, 25 Feb 2015 04:30:16 GMT

Atom is a hackable code editor from the fine folks at GitHub. It's written entirely in JavaScript (specifically CoffeeScript) and runs in a self contained Chromium environment. It's new and young, yet slowly growing in popularity and features.

After using Sublime Text for the past three years I found myself experiencing some growing pains. ST doesn't seem to be actively maintained, communications with its sole developer are non-existent and intermittent. The package community, while large, isn't holistic. Packages support isn't built into ST and as such I've had some unsatisfactory experiences. I've had packages randomly break, either from updates or installing a new package that conflicts with already installed packages. Sometimes packages just never work, or require obscure settings with non-existent documentation.

And if I'm being completely honest ST just isn't exciting anymore. I'm bored and Atom presents a welcome change.

I've been using Atom as my primary editor for the past month. Overall I've been very happy with my experience. I tried using Atom when it was first released but found it completely unusable as my primary editor. It was slow and its feature set (compared to ST) was woefully inadequate. Since then it's come a long way. While it's still missing some features in its core set of packages, I was able to find a community package that filled my need.

The one true point where Atom is truly lacking compared to ST is in the time it takes from opening the application and being able to code. I know that is a focus of the Atom team, and for now it's tolerable. I'm definitely looking forward to all future speed increases.

So in the vein of my previous post on my favorite Sublime Text packages. I present to you this follow up. My favorite and essential Atom packages.

save-session

Without this package I would not have been able to switch to Atom. This package brings to Atom the most excellent feature of Sublime Text wherein you can have an un-saved file open, quit, re-open Atom, and find that file just as you left it, completely unchanged.

I can't begin to tell you how many times this feature has saved my ass. I no longer have to worry about not saving a file if my computer freezes - I know I'm saved.

It also acts as a wonderful light-weight scratch pad. Just open a new tab, jot down some notes and keep it open for as long as you need that information. Quit Atom, restart your computer, that file isn't going anywhere until you explicitly close that tab.

A must have.

project-manager

This package allows you to easily save and switch between projects. It's a real time saver when you're working on multiple projects at once. Rather than having to manually find the folder where the code exists and opening it, you can simply activate the Project Switcher menu via ctrl+cmd+p and easily open an existing project.

This brings Atom to parity with ST's project switcher, so it's a real must have if you use that feature in ST.

autocomplete-plus

The built-in Atom autocomplete package is a little lame. It isn't eager in its suggestions and doesn't seem to know that much about your code that it's actually helpful. This package makes autocomplete in Atom much more usable, with plenty more customization, and a better capacity for finding suggestions.

I have one recommendation that in autocomplete-plus' settings you turn on its Use Strict Matching For Built-In Provider. This causes the package to more closely match ST's autocomplete, which I find produces better and more reliable results.

atom-ternjs

Tern is a code-analysis engine for JavaScript. This package brings its analysis to autocomplete-plus, which means even better autocomplete suggestions. Not only that it also adds context to your JavaScript code such that you can jump to the definition of a function from its usage, a feature you'd normally only see in full IDEs like IntelliJ. Makes developing much easier and pleasant, a definite performance boost.

highlight-line

Simple plug-in but one that I was sorely missing from ST. It does what it says on the tin: the line you currently have selected is given a highlight so you can easily find your place in your file.

This is a personal preference package, but one I can't live without.

highlight-selected

Another personal preference, this package adds the ST feature of highlighting the current word that is selected. So if you were to select the word 'hello' then all other occurrences of the word 'hello' would be highlighted. Makes for much easier navigation through code.

linter

The essential linter package. Gives you linting feedback in real-time, letting you know when you've written code that doesn't pass your current linter configurations.

This package relies on plug-in packages to be useful, the one I use daily is linter-jshint but there are many linters available.

docblockr

A nifty little package that makes it easier to write documentation. Since documentation isn't exactly the most exciting part of the developer workflow I'm always looking to find something to make the task faster and easier. This package helps in both those regards. With it there's almost no excuse to skip documenting your code.

Sublime-Style-Column-Selection

This is another package that brings Atom to parity with ST. With this package you can now hold alt while you select text to create multiple cursor selections, allowing you to quickly edit multiple lines from the same same location. It's a little productivity trick I use daily.

autoclose-html

You wrote an opening <div> element? This handles automagically creating the ending tag for you. That was easy.

emmet

Emmet is a topic for an entire blog post but to make a long story short this package brings Emmet to Atom. Super useful for scaffolding HTML and CSS.

Listing Your Packages

I wrote a little script to help me get the list of packages I have installed. It's a quick and dirty little node script, but I figured "Hey, I'm a developer. Developer automate their tasks. Let's automate this!"

The script just reads in your Atom packages directory and then prints the name and description from each package.json to stdout.

Figured I'd save it incase I had to run it again. Or if you were curious.

var fs = require('fs');
var path = require('path');

var atomPackagesPath = path.join(process.env.HOME, '.atom/packages');

fs.readdirSync(atomPackagesPath).forEach(function(current) {
  var packagePath = path.join(atomPackagesPath, current);

  if (fs.statSync(packagePath).isDirectory()) {
    var p = require(packagePath + '/package.json');
    process.stdout.write('[' + p.name + '](' + p.repository.url + ')\n');
    process.stdout.write(p.description + '\n\n');
  }
});

Switch to Atom!

What I love most about Atom is that it encourages you to hack it and make it yours. When I'm less than thrilled with how Atom is behaving I know there's a way to tweak it and make it work just how I desire.

Just the other day I was annoyed at what Atom showed in its title bar. So after a quick search I found the custom-title that allows me to completely customize what is shown. Had I not found that package I know there's an API waiting for me to jump into and use to my hearts content.

I love that Atom is extendable and flexible. It truly can be made into anything you desire, and there's no better time to make the switch than today.

Top 10 Albums of 2014

Wed, 31 Dec 2014 21:54:02 GMT

Music. In 2014. God, how can I even begin?

2014 wasn't even a year of music for me, it was a year of growth with Rachel and starting a whole new chapter in my life. The marriage was what consumed the entire year, with everything else just a blur in the background.

Yet the music of this year is what accompanied me along the way towards saying my blessed vows. It was the music, and the story of how the music came into my life, that gave this year its depth and color. How could I have known that my first dance song would be from my top album of 2014? (I suppose that it shouldn't be that much of a surprise.)

There was a lot of music in 2014. Looking back at everything that flittered through my ear canals in the past year somewhat astonished me - there was a lot of good stuff released. Some albums held me for months on end, listening to each track in sequence on repeat until every song was etched into the recesses of my brain. Some albums were spiked with a couple outstanding tracks amidst limp ones, preventing me from enjoying the album from beginning to end.

When I sat down and sorted through what albums would make it onto this top ten list I wasn't shocked at the ones that bubbled to the surface. Yet the albums that didn't make it onto the list deserve mention too. Every album listed on this post holds a dear place in my heart, as it helped shape this year into one of the best of my life. Without them I'd have gone through the year in silence, and god what a boring thing that would have been.

Honorable Mentions

Her Soundtrack
Beck, Morning Phase
Banks, Goddess
Caribou, Our Love
Damon Albarn, Everyday Robots
Hamilton Leithauser, Black Hours
Jessie Ware, Tough Love
Porter Robinson, Worlds
SBTRKT, Wonder Where We Land
Sylvan Esso, Sylvan Esso
TV on the Radio, Seeds

10. alt-J, This Is All Yours

When alt-J first came onto the music scene in 2012 they brought with them a sound that no one had quite heard before. It was eerie, atmospheric, moody, and insanely catchy. It was decidedly alternative, but surprisingly very popular.

The question then becomes, can they do it again? With their sophomore album they proved they can.

In many ways weirder than their first album, This Is All Yours retained the same trademark alt-J sound, delivering some new songs with hooks, and some new ones that showed them exploring more of their weirder side. Although not as immediately accessible as their first album, this follow-up grew on me and became one of my go-to albums to listen to when I went out running.

9. The Decemberists, What a Terrible World, What a Beautiful World

Three years since their previous release, this new album ended the hard drought of new material. It caught me by surprise as I had completely forgotten that The Decemberists were working on new material. I wasn't expecting it, but dear lord was I happy when it arrived.

Their previous album left me wanting as I found it completely inaccessible, whereas What a Terrible World, What a Beautiful World immediately reminded me of their sound from their first two albums (which I completely adore).

I didn't know that this is what I wanted, but as soon as I started listening I knew it was long overdue. This album is such a welcome and triumphant return to form. Every track is packed with all the reasons you originally fell in love with The Decemberists. Far from nostalgia, it's a collection of tracks that perfectly show how they initially became popular.

8. Hoodie Allen, People Keep Talking

I have a soft spot in my heart for Hoodie Allen. He's an artist who bucks the stereotypical path of musicians. He lives outside of the music industry machine, having remained independent his entire career, never signing a contract with a major record label.

People Keep Talking is Hoodie Allen's first full-length studio album and it's some of his strongest work to date. The album flows from start to finish, with wonderful interludes that nicely bridge the transition from one track to the next. Every song is catchy and packed with hooks that you'll find yourself repeating throughout the day.

It's a happy album, one that'll put a swagger in your step as you ride along with Hoodie as he takes you on a joy-filled ride through his musical canvas.

7. Inside Llewyn Davis Soundtrack

If you haven't seen the movie yet, I implore you to watch Inside Llewyn Davis before listening to the album. One of my favorite things about music is how it can elevate life into a realm that's beyond reality. Inside Llewyn Davis and the music that accompanies it is a perfect examples of this phenomena.

The mood cast from this album is almost tangible. Every song is oozing with emotion. The melancholy tunes of yearning clutch at my heart as I get to feel the heartache and pain that was put into the song.

Even though there's a couple of tracks on this album that are nails on a chalkboard, the rest of the album completely makes up for it and eases the pain.

The emotion on this album is incredible and it's something I found myself returning to again and again.

6. Taylor Swift, 1989

2014 was the year I found myself giving up my pre-conceived notions of pop and the artists that create it. Taylor Swift's 1989 was one of the albums that benefited from my new open-mindedness (she really has my number three album to thank for opening this door).

To be fair, I don't think I could have avoided 1989if I had tried. It completely took the world by storm and for a good reason: the album is great. And I mean, truly, honestly, no bull-shit, great. It's unabashedly pop (thankfully not country) and every track is immaculately constructed.

Yet despite the micro-management of working every track to perfection, the album comes across as honest and authentic. That's its true drawing power. While the songs are great and know every pop trick in the book, its delivery ad presentation include a note of authenticity that allows the album to come without pretension.

Perhaps that was calculated too, but at this point I just have to put paranoia aside and enjoy the pop-perfection that is 1989.

5. Spoon, They Want My Soul

Spoon is an incredible band that makes incredible music. They're unafraid to take risks with their sound, yet even while experimenting their music retains the trademark Spoon sound.

They Want My Soul is another incredible album from Spoon, where literally every track is a winner. There are no duds and nothing on the album that caused even the slightest of winces. While some tracks could be considered experimental, for Spoon it's just a continuation of their already strong musical foundation.

I listened to this album ad nauseam. On my way into work, while I went running, while working. They Want My Soul consumed my soul for an entire month and I'm so glad that it did.

4. Nick Mulvey, First Mind

Nick Mulvey came into my world by way of the Mercury Prize. Every year when the Mercury Prize announces their short list for albums of the year I pour through it to make sure I didn't miss anything from the past year. Thank god I did so, as Nick Mulvey would have been missed.

A singer-songwriter, First Mind is Mulvey's debut album and it quickly became one of my favorite albums of the year. Wonderful lo-fi and serene, the tracks showcase Mulvey singing along with his guitar, crafting such wonderful and calming folky tunes that proved an excellent back-drop to the rush and bustle of NYC.

Each track flows into the next, creating an album that is wonderful to listen to from start to finish. The worst part of the album is its end. Yet I found a trick to side-step this issue: hit play again.

3. Ed Sheeran, X

Ed Sheeran is the guy who got me out of my bubble of beliefs that pop wasn't worth my time and the people who made it are sub-par musicians. My ridiculous immature knee-jerk reaction against popularity was getting in the way of finding good music and I'm incredibly glad that Ed Sheeran's X showed me that there's a reason some artists are incredibly popular: because they make really good music.

While X has many great moments of Ed Sheeran wailing over his guitar, it's also filled with his trademark rapping that adds such a delightful twist to the album. The mood and ambiance of the album sway easily from introspective and insecure to uplifting and wondering.

X is filled with pop-standouts but it's also an album with heart. It's the heart that grounds every track and makes it such a pleasure to listen to.

2. Chet Faker, Built On Glass

The only electronic album on my list this year lands at number two. Introduced to me by my wife, Chet Faker is a lovely mix of electronic and singer-songwriter simplicity. While the production is entirely electronic, its Chet Faker singing along with the music that gives his sound the heart and depth that electronic music sometimes lacks.

The album is relaxed and free-flowing, with catchy beats and refrains that guarantees you'll be bobbing your head and singing along. In many ways the album reminds me of the Kings Of Convenience album Versus, however Built On Glass diverges in a welcome way. Built On Glassleans away from delving too deeply into its electronic soundscape, instead focusing on crafting catchy tunes and melodies that get their sound from electronic instruments.

I listened to Built On Glass on repeat for many weeks. The songs don't tire - they remain just as catchy and addicting as the first listen.

1. Sam Smith, In The Lonely Hour

And we arrive at my number one album of 2014, Sam Smith's debut album In The Lonely Hour. In some ways its unfair to say that 2014 was Sam Smith's debut year, as he had such a big presence in 2013 thanks to his lending his voice to Disclosure's breakout debut record Settle.

And while I won't say that In The Lonely Hour overshadows Sam Smith in 2013, it is in many ways the logical and welcome progression of Sam Smith's career.

Yes we first got to know this man while he crooned over dance tunes, yet seeing him fully express himself and his sound through his own album was completely welcome. We got to know the music that Sam Smith would create, free of collaboration with other artists. And we found out that he creates some soul-crushingly beautiful music.

There isn't enough that can be said of Sam Smith's voice. He croons so beautifully, with soul and honesty that causes your own heart to reach out and touch his. He can howl without breaking a sweat and whisper a lyric so beautiful it causes you to tear.

Many a night were spent with Sam Smith lulling me to rest, singing me down to a level of calm from the rush of the day. As the sun set Sam Smith sang and welcomed the night with his beautiful music.

My wife and I chose his rendition of Latch to be the music we used for our first dance at our wedding. I'll never forget the moment, holding her close, smiling deeply, as we danced as best we could on the dance floor, as Sam Smith crooned:

You lift my heart up when the rest of me is down

You, you enchant me even when you're not around

If there are boundaries, I will try to knock them down

I’m latching on, babe, now I know what I have found

Care to easily listen to the albums listed above? My friend Tom took the time to compile a Spotify playlist for your easy use. Thanks Tom!

Building Hacker News With Angularjs

Thu, 09 Oct 2014 01:39:53 GMT

This week Hacker News announced its official API. This is really great news. Prior to this official API all 3rd-party apps resorted to scraping the website to as their data source, a brittle and unscalable practice. This new API provides a standard and efficient way to create 3rd-party Hacker News applications.

Last night I decided to try out this new API. I randomly decided to sprint and see how quickly I could create an exact clone of Hacker News using angularjs. Turns out it took me almost exactly 2 hours to do. Pretty damn impressed with myself.

To cut to the chase, find the demo url here: http://hswolff.github.io/hn-ng/ And the source code here: https://github.com/hswolff/hn-ng

How Was This Made?

I started the project via scaffolding through Yeoman'shttp://yeoman.io/ gulp-webapp generator. This saved me a lot of initial work, as it created all the rote files I would have otherwise had to create and saved me the trouble of finding one of my old gulp files to copy over.

After that I added angularjs to my bower file:

bower install --save angularjs

And then used the magic of one of Yeoman's default tasks, gulp wiredep to automatically inject those new bower files into my index.html file.

I did hit a struggling point when it came to compiling my angular application. As angular dev's are aware, there are some issues surrounding minification. To surmount this I grabbed the gulp-ng-annotate plugin which handles adding all required annotations to your code.

There was also the issue of pre-warming my template cache. To solve this I used gulp-angular-templatecache, which allows you to pre-warm your $templateCache to not require any AJAX calls in production.

After solving those two hiccups everything was smooth sailing. I sprinted through the controller that handles the homepage and was just racing against myself.

All-in-all a wonderful exercise. I hope as the official Hacker News API expands I can also expand my clone, and maybe add some of my own personal enhancements to it. For now I hope you enjoy the code!

Chartbeat Presents at Front-end Meetup

Thu, 31 Jul 2014 17:26:28 GMT

Last Thursday Chartbeat hosted the Frontend Innovators Meetup group at our office. The focus was Angular.js, and my co-workers and I had the good fortune of being presenters. Our goal was to share some of the experiences and insights we’ve gained over the past year working with Angular.js.

From Closure To Angular

Slides are available online.

I presented first, focusing on how and why Chartbeat began using Angular.js for all of our front-end applications in the first place. I discuss our decision to migrate from Google Closure Library to Angular.js after weighing all the options we had available. I then shared how we actually develop with Angular.js, focusing on how we layout our directories, files, and applications, and discussing our multiple applications at Chartbeat and our need for a system that allows for growth, flexibility, and sharing between all applications.

Reusable Components

Slides are available online.

Danny presented next, discussing the merits and pitfalls of developing reusable components. He first discussed the advantages of working with components, which give us the ability to quickly throw together entire new applications by using existing components, allowing us to rapidly develop new applications by leveraging existing components. Danny then dove into the trade-offs that accompany the creation and maintenance of components: if it is more “expensive” to create a component than it is to simply duplicate code then perhaps it isn’t worth the time and effort to create it as a component. It was a nuanced talk with some great points. Worth watching in full, I think.

Graphing Chartbeat with Angular + SVG + D3

Slides are available online.

Nick then presented about SVG, D3, and Chartbeat’s use of D3 within Angular. He began by giving a solid background on SVG and the pitfalls you can encounter when trying to use Angular’s templating functionality with SVG elements (spoiler alert: there are a few!). Nick then discussed our internal library called C3 that he developed. He showed the design decisions that shaped C3 and the places where he’s found some shortcomings that he hopes to fix in the future.

Frontend Testing and Build Process

Slides are available online.

Jem rounded out the night with a thorough talk on Chartbeat’s test practices and build process. He talked about our testing stack, consisting of Jasmine, Karma, Protractor, Jenkins, and Selenium, and the best ways to put these systems to work. Jem also shared some good practices to keep in mind when using these tools. He then turned his focus to how we compile our applications for a production environment, discussing our move from Grunt to Gulp and why we're finding it a better fit -- it's cleaner and clearer to work with, as it’s mostly vanilla JavaScript, which makes reasoning with it easier.

We had a great time presenting and hope everyone learned something from our talks.

Angular.js is still pretty new and we're all still learning the best way to do things. Over the past year we’ve learned a lot about the right way to do things and the wrong way to do things. If you have too, please chime in. Sharing what we've learned is the best way for our whole front-end community to continue building better and better things.

Building an Entire Product in 6 Weeks (How we built the Chartbeat Paid Content Tool)

Wed, 09 Jul 2014 14:40:04 GMT

A little while ago we released our Paid Content product after two consecutive six week sprints. The first six weeks were spent creating the MVP, and the second six weeks were spent polishing it up.

This is the breathless tale of those first six weeks.

Part 1: Research

This whole thing began because we saw that our clients were struggling. Paid content, sponsored content, native content – whatever you call it – remains a mysterious beast for many folks and there were few options for measuring paid content performance, let alone figuring out what you can do to make it better.

For the first two weeks of our sprint we researched and brainstormed. We huddled into offices and littered the white boards with ideas, questions, diagrams, and whatever else we could to make sense of things. We’d pour over data to see what insights we could glean and what information would be helpful to know for any native content campaign. It was a lot of debating and arguing, breaking for lunch, and then regrouping for more debating and arguing.

Amidst these debates we talked to existing clients. A lot. We wanted to know how they created paid content campaigns, and what pain points they have experienced. We’d invite them into the office and talk to them on the phone. We’d visit them in their office and pummel them with questions, searching to find what we could do to improve how they analyzed paid content performance.

Part 2: Design

As we were assessing the type of data our clients needed, we also began to design our version of better.

We'd create one mock-up, show it around, gather feedback, and iterate. We'd see what worked in a design and what didn’t. We'd toss out the bad, toss out some of the good, and try again. We moved swiftly, for time was against us.

Something that proved to be a great success were clickable mocks. Typically a mock is static. With a static mock you can cycle through a list of images to give a sense of what the product will contain, but a clickable mock allows you to simulate how the product will feel when it’s complete.

These clickable mocks proved insanely helpful when discussing the product to clients. It enabled us to show our ideas and direction rather than just tell.

Part 3: Development

With under three weeks left to go in the cycle we knew we had to hustle.

We wanted to see what the data for a real paid content campaign looked like so we worked towards getting things working on the screen as fast as possible. Despite all our planning and designing we had yet to see real data for a paid content campaign and we had concerns that we had planned and designed for data points that may not exist. It’s fine to plan to include data about the amount of Twitter activity that drives traffic to a piece of native content, however if that value is always 0, it’s not helpful.

To our relief our planning paid off. The data worked and made sense. From there on out it was a sprint to bring all the beautiful designs to life.

Part 4: Launch

With the launch of our MVP looming we knew we’d have to start making some hard decisions. Everything we wanted to include for the first version would not fit, so out came the knife as we looked to see what we could cut away.

Delicately we began to inspect what was left. We began to weigh things, deciding what were show-stopping features or essential functionalities that had to make it for the launch, versus things that would be fine to include afterwards. We’d see which features would be more ‘expensive’ to complete. At this stage the only currency we traded in was time, with everything balanced between time to complete versus its impact on the product.

Conclusion

Some hard decisions were made but ultimately we managed to ship on time and practically feature complete.

We were able to bring to market a product that six weeks prior did not exist as anything but an idea. Everyone at Chartbeat came together to make this a reality, each pulling their own weight and helping one another. Through and through it was an incredible team effort.

Within Chartbeat we managed to create a MVP in record time. We were able to assess client needs and industry gaps to form our product and get it out the door and into client’s hands. We’re not done, but we’re off to a strong start.

Also posted on: Chartbeat and Medium

Don't Deal With It, Fix It

Wed, 23 Apr 2014 01:31:07 GMT

I've used Sublime Text for a long time. I started using it when it hit version 2 and clung to it like all hell was about to break loose.

It fit my needs well. Opened nearly instantaneously, had sensible defaults for editing, and a lush and vibrant community of third-party packages that I could install to extend its core.

There were a few things that bothered me about Sublime Text 2. Things that I just lived with as I couldn't be bothered to fix them. No, that's not true. I didn't fix them because I didn't think I was capable of fixing them. I looked at these inconveniences as something I just had to deal with because that's how the program worked, and there was nothing within my power to make it better.

For a long time I lived with these irksome issues. Every time they popped up I would quickly swallow the ire that would rise in my throat, fighting it down so it wouldn't overwhelm. I would remind myself on every recurrence that this was just something I had to live with. It was just the way things are, and either I had to deal with it or go look for some other code editor.

Every time I was faced with something annoying that Sublime Text did I would I swallow my annoyance. I would side-step it and walk right back into Sublime Text's loving embrace. Because for that one thing that annoyed me, it did countless other things that were simply amazing. So I would live with it.

I'll never forget when my friend Dom started using Sublime Text. He was a long time vim user, staunchly entrenched in the comfort of vim. Able to navigate his way across any document with just a matter of keystrokes. I was able to finally persuade him to try out Sublime Text by highlighting its ability to emulate vim's key bindings. After weeks of lobbying and convincing, Dom finally tried out Sublime Text and began to appreciate it in much the same way I had.

He used it, and began to like it. He slowly started expanding his Sublime Text knowledge, gaining more experience with the program as he programmed. All was well for Dom until one day when Dom experienced the same annoyance that I had for weeks tried my best to ignore.

I'll never forget what Dom did next.

He fixed it.

He set aside some time during his day and fixed this bug that I had been living with for months.

He researched why this bug was happening and then looked into the Sublime Text API and created a third-party package that completely fixed the issue.

I was dumb struck. It had not once occurred to me that it was within my power to fix this thing. I simply believed that it was something I was stuck with. And that was the assumption under which I operated for months.

Dom? He wouldn't put up with it. He stopped everything he had to do, and found a fix to make his Sublime Text experience one without any grievance.

Since that day I've learned that I have the power to fix things around me that I don't like. I don't need to just deal with it because that's just the way things are. I have the power to shape the world around me. It's just a matter of believing that I can change things. Just believing is all I need to actually take the first step towards taking action.

Sure this was about fixing a bug in a piece of software that annoyed me. But the implications of this realization was one that has reverberated throughout my way of going about life.

Just the other day I was about to go into the planetarium at the Museum of Natural History. As the massive herd of people rushed past doors propped open by doorstops one doorstop came loose. This caused each person walking through the doorway to hold the door open for the person behind them. So it went in a long chain of people, each holding the door open for the next person, every one ignoring the door stop loose on the ground. However when I came to the door I paused to find the doorstop and jam it back into the door. A clear problem with a clear solution. All it took was a belief that I could fix the problem, and some time to take action.

I'm trying to do that more and more as I go about my days. When I see a problem I'm going to look for a solution. No longer will I try to just deal with it. I'm going to try and make it better. No matter how small and trivial it may be. I believe I can make my world better. All it requires is some action.

Update: By popular demand and through the miracle of memory recal I've managed to remember what the issue was. I was using an existing Sublime Text plugin that was using the SublimeText API incorrectly which caused an error pop-up window to show every so often. It was infrequent enough to not bother me, however it was enough to annoy Dom. So he went into the source code and found the offending line and fixed it to prevent the pop-up from ever showing again. Sure it was a small thing, but made the entire experience that much better.

The Modern Front-end Workflow - From Start to Finish

Thu, 30 Jan 2014 18:00:00 GMT

Front-end engineers have gone through a bit of a renaissance in recent years.

There's been a wild and wonderful spurt in innovation that has completely changed what it means to be a front-end developer.

We now have a vast and wide array of tools available to us, allowing us to develop faster and smarter.

We now can push the limits of what a modern web browser can do, accomplishing things that two years ago seemed impossible.

Bottom line, right now is an amazing time to be a front-end developer.

Start

Source

Today there is almost zero friction to getting set up with a new project. Everything that you need to get started is only a few key strokes away thanks to some powerful new tools.

Git is the version control system of choice for most developers nowadays. It makes sharing code easy and frictionless. When you want to get going on a new code base you only have to run the simple git command of git clone and all the code and all of its history is downloaded directly to your computer.

NPM is the node package manager. It allows developers to package their nodejs code a self contained module and then share it with the community. There are npm packages that provide almost every type of functionality you can imagine, allowing you to leverage the work of the community. Each new project has their own unique set of dependencies they require for them to work. To get all these dependencies installed locally you only need to run npm install, which downloads and installs everything you need.

Bower is a package manager for third-party web libraries. Historically if your project requires jQuery be included you would have to navigate to the jQuery website, download the file, extract it, and move it into your project. Bower simplifies that process by giving you the command bower install which handles getting jQuery into your project.

Development

Source

Actually coding and developing your project is where most time is spent. Nowadays this is one of the most enjoyable parts due to the many wonderful tools available. These tools make dev'ing so smooth that I'd dare say it makes it fun. Scratch that - it makes it oodles of fun.

GruntJS is the most popular task runner amongst front-end developers. There's already a huge community of grunt plugin authors that to date have written over 2,000 Grunt plugins, all of which are immediately ready for your use. Grunt allows you to automate rote tasks without breaking a sweat. For example if you need to compress all your jpg, gif, and png files you can use the imagemin grunt task .

CSS Preprocessors like LESS, Sass, or Stylus have made it easy to architect maintainable, extendable, and modular CSS. Among the many features that CSS preprocessors provide the two of most value are without a doubt nested selectors and variables. Having the ability to define a color variable in one location and use it throughout allows for a flexibility in CSS that did not previously exist, yet one that was sorely needed.

LiveReload changes the way you develop, as it brings a fluidity to your development flow that you didn't realize you needed. Whenever you change a file that you're working on LiveReload will notice that it changed and refresh your browsers so that you can immediately see your changes in place. No longer do you have to save a file, switch to the browser, and then refresh the page. With live reload after you save a file the browser will refresh itself, saving you time and grief.

Review

Source

When you're ready to push some of your code into the wild it's always a good idea to review it with your team and run it through some code quality and style tools.

A GitHub Pull Request is one of the handiest ways that you can rally your team around vetting your changes. After opening a pull request you're given a page that allows you to clearly state what you changed along with a view that shows the changes you made. Coupled with a robust comment system, a GitHub pull request makes it easy for your team to review and give feedback on changes.

JSHint is a tool that programmatically finds errors in your code. It'll prompt you if you have a function with two arguments, and the second argument is never used, or if you're missing a semicolon where one should be. All these things ensure your code is in good shape, allowing your teammates to focus on other things that aren't as nit-picky as JSHint.

JSCS is another tool that is great to have in your repertoire. JSCS is a JavaScript code style checker, focusing on the style of your code and not the quality. You define what code styles you want and when you run your code through JSCS it'll alert you if there are any areas of your code that are not inline with your project's expectations.

Deploy

Source

Getting your code from your computer out into the world is the best part of development, as it's when you get to share all your work with the world at large.

Continuous integration is a practice that enables and encourages getting your code to production frequently and without fear of breaking anything. A CI server will automatically perform tests across all products, not just the ones you touched. If any tests fail alerts are sent out and any changes to production are halted, preventing regressions from reaching production. When all tests pass your changes are merged into the production ready branch, assets compiled, and production is updated.

This makes the entire process of getting your changes live easy, effortless, and safe. You can view the progress of the CI server as it chugs along, letting you be kept in the loop of what's going on without having to push the process along yourself.

Summary

The life of a front-end developer has never been easier. Browsers are getting better every day, and the tools we have at our disposal have never been better.

No longer are we wallowing in the shadow of legacy browsers, but we're barreling ahead to stretch what's possible in the browser.

The processes outlined above lets you worry less about minutiae and just focus on development and the product.

The life of a front-end developer is pretty damn good.

Also posted on Chartbeat's blog

Smarter Express Routing

Sun, 12 Jan 2014 04:01:13 GMT

In a large ExpressJS application it is not optimal to define all your routes and handlers in the same file.

For the sake of code clarity and cleanliness Express route handlers are often placed in their own file. Those files are then included in the file that is bootstraps your application.

What you usually ends up with are two files, user.js and app.js.

user.js

module.exports = function(req, res) {
  // Do the cha cha
  req.json({'hello': req.params.user});
};

app.js

var express = require('express');
var app = express();

var user = require('./user');

app.get('/user/:user', user);

Neither the route path or the route handler have any knowledge of each other, when they are both strongly inter-related. This increases the fragility of your application as this association is defined in two files.

Say down the line the user.js route handler changes, making it better fit by a new path. To make that update would require modifying two files. This association between the route handler and the route path should be adjacent to each other.

Also, let's say you want to later reference that route handler's path. With this configuration there is no way to do that.

Smarter route definitions

Let's improve this situation by moving the route path to be with the route handler.

user.js

module.exports.get = [];

exports.get.push(['/user/:user', function (req, res) {
  // Do the cha cha
  req.json({'hello': req.params.user});
}]);

app.js

var express = require('express');
var app = express();

var user = require('./user');

user.get.map(function(route) {
  app.get.apply(app, route);
});

Using a little JavaScript magic (.apply) we're able to dynamically apply every route path and route handler defined in user.js.

This can scale as much as you want. You can add as many routes to the get array as you'd like, including other middleware functions, as everything in that array is passed to app.get through the magic of .apply. You can and should also do the same for your post, put, and delete routes.

This should make your Express application a little more robust, and much prettier.

An easy introduction to AngularJS

Mon, 25 Nov 2013 12:00:39 GMT

<p>AngularJS doesn't do much. When you take it out of the box (i.e. load it on a webpage) you're only given five things to play with: modules, services, controllers, directives, and filters.</p>

<p>Each of these things complements the other. There are very slim overlaps in functionality between all the moving pieces of AngularJS. That fills my heart with joy because I only have to learn how to do something one way, with one slice of the AngularJS pie.</p>

<p>The funny thing about AngularJS is when you use every <em>thing</em> it provides, you get something far greater than its sum. In that way AngularJS truly does allow you to create web-apps of 'superheroic' proportions. Their words, not mine (although I do agree).</p>

<p><strong>Ready to dive a whee bit deeper?</strong></p>

<h2>Modules</h2>

<p>A module in AngularJS is about what you'd expect.</p>

<p>It lets you package your code into small chunks, useful for breaking a large application into smaller pieces and for distributing code.</p>

<p>You define a module name upon instantiation, neatly namespacing all the relevant code within. This helps you stay clear of polluting the global window object and not worry about clobbering other variables.</p>

<p>One of the most lovely features of modules in AngularJS is that you can load parts of a module in any order.</p>

<p>For example on a html page that is loading your application you can load the script tags in any order, and it won't affect how the application is put together.</p>

<h2>Services</h2>

<p>In their simplest form, a service provides singleton objects to your application. That's really about all they do.</p>

<p>Sure there are some nuances to services. There's different variants: factories, providers, constants, and values. Most of them are quite aptly named.</p>

<p>Constants and values do about what you'd expect. They are easy to use key-value stores that can't be modified after app start-up. Hence the 'constant' name.</p>

<p>Factories are services designed to allow you to create new instances of an object. The factories themselves are singletons, but they're designed to allow you to create as many instances of an object as you desire.</p>

<p>Providers are services that allow an amount of configuration before application initialization. For example if you have an API service, you can change whether it points to the dev or production server by using the provider pattern (as opposed to having that if statement within the service. Always better to be explicit.).</p>

<p>That's about the skinny of what services are in AngularJS. These things should (almost) never touch the DOM. They're just vanilla JavaScript objects, with sugar around them to work neatly amidst the AngularJS framework.</p>

<h2>Controllers</h2>

<p>Traditionally, controllers are used as the glue between models and views. Here again AngularJS doesn't stray far from tradition. In an AngularJS controller you can define what data and behavior is exposed to the view. How this is done is semi-magical.</p>

<p>There's a service that AngularJS provides called '$scope'. $scope is used like a regular JavaScript object. You can assign strings (<code>$scope.hello = 'world';</code>), other objects (<code>$scope.person = {name: 'bob'};</code>), and functions (<code>$scope.foo = function() { return 'bar'; }</code>). You know...whatever you want.</p>

<p>Where things get a little opaque is how that gets exposed to the view. If you're really curious you're free to dive into AngularJS internals. However it is safe to assume that anything assigned to <code>$scope</code> is available for access in the view.</p>

<p>Aside from the magic of <code>$scope</code> everything else about a controller is mundane. Thank goodness.</p>

<h2>Directives</h2>

<p>Basically directives are components. That's the simplest way to understand it.</p>

<p>Past that things can get awfully confusing awfully quickly.</p>

<p>Directives allow you to extend the language of the DOM, doing things that jQuery is commonly used for. For example AngularJS defines the <code>ngClick</code> directive, which allows you to attach behavior when a click event is observed. When AngularJS compiles your views (which are basically HTML) it has knowledge of the <code>ngClick</code> attribute, and its behavior.</p>

<p>So when the AngularJS compiler sees <code><div ng-click="popup()"></div></code> it attaches a click event listener on that div element (as defined in the ngClick directive).</p>

<p>AngularJS ships with many great default directives. It's encouraged to re-use directives within directives.</p>

<p>Just remember that directives are similar to components: they allow you to create a new unit with specific functionality.</p>

<h2>Filters</h2>

<p>Filters are used by templates to modify the output of data.</p>

<p>For example AngularJS ships with the <code>number</code> filter which can take an integer input such as <code>12345</code> and output it with commas as <code>12,345</code>.</p>

<p>Or you can have an array of strings and only want to show the ones that start with a 'he'. You'd use the <code>filter</code> filter (unfortunate name redundancy).</p>

<p>The dirty secret of AngularJS is that it's basically a simple set of tools that allow you to do advanced things really easily.</p>

<p>AngularJS only gets really complicated when you start diving into its source code. But let's stay away from that elephant in the corner.</p>

<p>There's an interesting learning curve when you get up to speed with AngularJS. The first week you'll have a grand old time. The second week you'll encounter some weirdness which will throw you back a bit. By the third week you'll have to do a little more conceptual diving into AngularJS to understand why things are behaving the way they are.</p>

<p>By the fourth week you'll be able to write a blog post just like this.</p>

<p>Get out there super-heroes. Start writing some super-heroic JavaScript.</p>

Make Your Code Pretty

Fri, 30 Aug 2013 09:32:24 GMT

<p>All too often I'll see code that'll make me gag.</p>

<p>There's inconsistent indentation, no linting, and trailing white space run amok. It won't effect how your code is executed but it makes for an unwholesome experience for whoever reads your code.</p>

<p>I won't place the blame for these types of code 'errors' on the programmer. If you don't have the proper software installed they are extremely hard to track. I don't expect anyone to be hand-combing through their code, looking for any extraneous white-space or instances where they forgot to remove a trailing function argument that is no longer used.</p>

<p>What I expect is for programmers to install the proper tools into their code/text editors to do it for them.</p>

<p>In the instance of Sublime Text there is a holy marriage of two packages that will ensure that every piece of code you write is beautiful. </p>

<h2><a href="https://github.com/SublimeText/TrailingSpaces">TrailingSpaces</a></h2>

<p><img src="/images/posts/2013/08/trailing-spaces-300x75.png" alt="trailing-spaces" width="300" height="75" class="alignleft size-medium wp-image-2697" /> Just like shining a black light into dusty corners, Trailing Spaces will highlight every instance of extraneous whitespace. In glorious neon pink, you'll see all your old code come alive in ways you never thought possible.</p>

<p>After you install this package you'll understand why I get so upset when I see trailing white spaces left in code. Whereas they are invisible without this package, they are a hideous eye sore with it. Lighting ablaze every offender in its neon pink glare.</p>

<h2><a href="https://github.com/SublimeLinter/SublimeLinter">SublimeLinter</a></h2>

<p><img src="/images/posts/2013/08/linting-300x129.png" alt="linting" width="300" height="129" class="alignleft size-medium wp-image-2699" /> Instantaneous linting is a friend you wish you had years ago. Keeping you honest with each line of code you write, SublimeLinter will continuously check your code to see if it is staying inline with best coding practices. For Python that's PEP8, for JavaScript that's JSHint. Along with best practices it'll also point out when you're doing something wrong.</p>

<p>It's a loving whisper that alerts you that you left a trailing argument in a function you wrote. You needed that argument parameter before, but after a quick refactor it became unused. SublimeLinter is there to kindly point these things out.</p>

<h2>Conclusion</h2>

<p>A machine doesn't care if your code is ugly. It doesn't care if there's a bunch of extra whitespace littered throughout the code (unless it's a code sensitive language ;)). It'll read it and execute it the same way.</p>

<p>The person who cares is the one reading your code. They are the one who must hold your code up against an engineer's standard. If that person has their code editor wired up so that every trailing white space comes ablaze in neon pink they're gonna have a bad time.</p>

<p>Keeping code pretty reflects directly on the programmer. It shows if they care about what they write. You're in this gig because you want to be and you care about what you do. So you should do the same for every piece of code that you write.</p>

Weekend Project: Bring The Salsa

Mon, 08 Jul 2013 21:48:26 GMT

<p>There's been many times I've read of someone hacking together a project over a weekend. Appropriately titled a 'weekend hack' these projects have a finite beginning and end. And they've always seemed out of reach for me to accomplish.</p>

<p>However! thanks to this long weekend I was able to complete my own weekend hack! Granted this was a long weekend so I may have cheated a little bit, but nonetheless! I was able to start and finish a project within the span of a weekend.</p>

<p>So what did I make? A web app I've named <a href="http://bringthesalsa.hswolff.com">Bring The Salsa</a>!</p>

<p>(Here's the part of the post where I wait for the applause to die down before I can continue typing again. You are thunderously applauding my accomplishment, aren't you!? ;))</p>

<p>Bring The Salsa is a web app that was built to solve a pain point I've often encountered when hosting a party at my apartment: I want friends to bring things, however managing who is bringing what is always a manual bloated ordeal.</p>

<p>So Bring The Salsa aims to fix that. You can create your own list with a unique URL to share with friends, and freely edit what you need to bring, how many needs to be brought, and who is bringing what.</p>

<p>Enough with what it does, hopefully I made the app intuitive enough that you can figure it out yourself.</p>

<h2>Technology Used</h2>

<p>Now for the tech details, you know, the stuff that truly matters ;).</p>

<p>The backend is graciously provided by <a href="https://www.firebase.com/">Firebase</a> (graciously and freely - cuz it's in beta). This cut my development time in half, allowing me to focus on the front end of the application and not worry about creating a node.js server with a database and an API and yadda yadda yadda.</p>

<p>This was my first time using a backend provided by a 3rd-party. After I wrapped my head around the way data is stored in the DB I found using Firebase to be an absolute joy. Out of the box it has 1st-class support for real-time updates, a wonderful side-effect that I was able to directly take advantage of in my app.</p>

<p>As for the true star of this app, that is undoubtedly <a href="http://angularjs.org/">AngularJS</a>.</p>

<p>Bring The Salsa is an AngularJS application from top to bottom. This was my first time creating an application in AngularJS and I must admit: it was lovely. My current client side MVC background is Backbone.js so I began using Angular.js with a couple of prejudices, however they were all washed away over the course of the weekend.</p>

<p>In case you want to see what an Angular.JS application looks like, and in particular this application, I've open-sourced the code on GitHub and plan to continue development openly.</p>

<p><a href="https://github.com/hswolff/bringthesalsa">Click here to see the open-source repository of Bring The Salsa</a>.</p>

<p>I have a lot more to say about AngularJS. So much more that I will be dedicating an entire post to talk about what I've discovered about AngularJS over this long and lovely weekend.</p>

<h2>Regret</h2>

<p>The only thing I regret about creating Bring The Salsa is that it would have been perfect had it existed before this weekend began. Because truly, that is when it will come in handy the most: for weekends that you're hosting a party and need some organization.</p>

<p>And above all else, when you do use this app, for heaven's sake, don't forget to bring the salsa.</p>

Taming The Jungle: Working With New Code

Thu, 27 Jun 2013 13:07:05 GMT

<p>An undervalued skill of the common developer lies in their ability to navigate and explore a new code base. Although not the most glamorous or fun task, it is the one that almost always consumes most of a developers working hours.</p>

<p>Despite the percentage of time this work consumes, it is a topic that is seldom discussed on the internet. Reason for that is simple: it's not fun. It's not fun understanding someone else's code, pondering why they arranged code the way they did, why names are named the way they are, and what performance enhancement drugs they were on.</p>

<p>At every job I've started I've had to enter the jungle that is "someone else's code". Along the way I've come up with a few strategies to mitigate the pain. Some are obvious while others are even more obvious.</p>

<p>And please: if you know of any other strategies to reduce the pain of learning a new code base I would love to hear it. I'm sure everyone reading this post will appreciate it as well. </p>

<h2>How Is The Code Structured?</h2>

<p>First thing I always ask when encountering a new codebase is, 'How is the code structured?' To elaborate: from the time a client makes a request to when the client's browser renders the web page: what is going on?</p>

<p>Where is the entry point? How is it funneled through the server side code? Where is the client side code initiated?</p>

<p>Where are the pertinent files in the directory structure? Are there any weird gotchyas with callbacks executing critical code in a non-obvious way that without the callback nothing would ever render?</p>

<p>These are the questions I ask both myself and my new co-workers. I try to get a grip on the code, understand the general 'lay of the land' if you will.</p>

<p>This is the part of the process where I want a high-level view of 'what is going on?'. The details of the process are distractions at this point: all I need is a working knowledge of all moving parts.</p>

<p>This process takes anywhere from a day to a week in my experience. Usually I take around two days to get a general idea of how the code is structured and what it's comprised of. At this point I have a naive understanding of the entire system, enough that I feel confident that I'll be able to make changes, which is the second thing I usually do.</p>

<h2>How can I change code and see the results of my work?</h2>

<p>In the great words of Yoda, 'Do or do not, there is no try.'</p>

<p>There is no better way to learn something than by trying it out and actually doing what you are learning. This is true for everything (everything!) including learning code.</p>

<p>When I am given a small starting task at a new job I take an oblong approach: rather than attack it head on I reduce the task to the smallest unit of provable success.</p>

<p>For example if I am tasked to add myself to the about page I'd want to do two things:</p>

<ol> <li>Find the file that I think is the about page.</li> <li>Add the most obvious edit to make sure that a) I'm editing the right file and b) that there is nothing else in-between editing the file and seeing that change reflected. (My personal favorite edit is along the lines of <h1>Pandas Rock</h1> appended to the <body> of the page.)</li> </ol>

<p>Rather than assume I am doing everything correct, I actually prove it to myself and avoid working on something that could very well be wrong.</p>

<p>The about page that I'm editing may be an outdated one that is no longer used, however still exists in the repository and as such is often confused with the one used in production. By simply testing to make sure I'm in the right place, and doing the right thing, I save myself wasted dev cycles and frustration.</p>

<p>This process of orienting myself before making changes further cements my knowledge and understanding of the code base, and prevents me from getting lost. By forcing myself to always breach the surface and take a gasp of air (i.e. seeing my changes reflected) I'm able to take a dive into the code base to find what I need.</p>

<p>As I'm able to hold my breath longer (i.e. my knowledge of the codebase increases) my need to come up for air and double check I'm in the right place decreases.</p>

<h2>What were the design ideas?</h2>

<p>After my memory of the code base begins to solidify and coalesce I begin to ask more introspective questions. I begin to wonder why things were done the way they were and what was the reasoning behind these decisions.</p>

<p>These questions allow me to gain a deeper and more intimate understanding of the code and my co-workers. Rather than assume an aspect of the code I find un-intuitive is the result of poor decision making I can ask to find out how it came into existence.</p>

<p>Perhaps as the project was developed requirements changed, causing a rush of modifications that resulted in the code that I had just assumed was the result of poor choice. I may have even taken my assumptions as far to assume the developer that came before me hated his own kind and wanted all those who came after him to suffer! What a thought!</p>

<p>Through understanding of the why I can at least appreciate and reconcile my differences with the code rather than begrudge it. Not only that I can find my co-workers dislikes and work together to fix our problems.</p>

<p>Another benefit of understanding the ideas behind the code is its ability to strengthen and deepen my knowledge. While I may have wondered why some component had a certain name that was not representative of its usage, I may learn it once did what it is named to do and why it was changed.</p>

<h2>Getting out of the jungle alive</h2>

<p>Every code base is unique. Sure, there are overlaps that will make learning a new code base easier: if you use a framework (Ruby on Rails) or follow a common architecture (MVC). However the spirit of the code lies in the details, and those are near impossible to clone.</p>

<p>So you must enter the jungle that is a new code base. With or without trepidation, you must plunge in head first, without knowing what you'll find.</p>

<p>And after some time you'll exit the jungle. You'll come out wiping your hands free of dirt, turn around, and see a playground with a brand new swing set. It's the same code base, but now you know what's inside, and you know the fun you can have. Sure you may add some renovations (always need a vomit wheel), but that jungle will have been tamed. And in taming the jungle, you'll now be free to build your own.</p>

Upgrading to Sublime Text 3

Sat, 11 May 2013 22:15:29 GMT

When Sublime Text 3 was released I groaned along with many others. Why a new version? What are the incompatibilities? But most importantly: Will all my old packages that I know and love still work??

After attempting (and succeeding) in upgrading to ST3 and trying to <a href="http://blog.harrywolff.com/my-favorite-sublime-text-2-plugins-aka-packages/">install all my old plugins</a> I know, love, and use daily I can safely say: the old packages work! They work! And it's glorious!

There is a but here: the process of installing some plug-ins is not as plug and play as it is for Sublime Text 2. There is a certain amount of 'getting your hands dirty' work required - namely using git to check out the ST3 compatible branch. Aside from that you'll leave the process without any stains on your newly washed white shirt.

So let's dive in, shall we?

<h2>Installing Sublime Text 3</h2> You're a responsible developer right? You've paid for Sublime Text 2 already right? Supporting a brethren developer's hard work, putting food on his table, a new Retina MacBook Pro in his lap?

You have? Good. Cuz that's all that's required to download ST3: an active and valid ST2 license.

After that's all squared away head over to the <a href="http://www.sublimetext.com/3">Sublime Text 3</a> download page and commence with the installation.

Tip: You can install ST3 alongside ST2 without any modifications to either program. Each install to separate application names and 'Application Support' directories without needing any user intervention. Interestingly enough the application name for ST3 is 'Sublime Text'. Seems Jon Skinner's gone back in time with this change.

<h2>Install Package Control (for ST3)</h2> Ready to get down and dirty with git? Of course you are.

The Package Control website plainly instructs <a href="http://wbond.net/sublime_packages/package_control/installation#ST3">how to install Package Control for Sublime Text 3</a>.

I could regurgitate those instructions here but I'd rather not muddy the internet with cloned instruction sets. If you have any issues with this part feel free to <a href="https://twitter.com/hswolff">ping me</a>.

<h2>Using Package Control to install packages</h2> For most packages I was able to use Package Control without any issue.

The packages I have currently installed and working brilliantly are:

<ul> <li>CoffeeCompile</li> <li>CoffeeScript</li> <li>Emmet</li> <li>GitGutter</li> <li>GitHubinator</li> <li>LESS</li> <li>SideBarEnhancements</li> <li>sublime-closure-linter</li> </ul> However there were two packages I do use daily that I didn't want to lose that did require a bit more manual labor. <h2>Installing SublimeLinter for ST3</h2>

<em>Update: SublimeLinter has been updated to natively support Sublime Text 3. You can now easily install SublimeLinter straight from Package Control. Yay!</em>

Ready for some more git wizardry?

Follow these four simple steps:

cd ~/Library/Application Support/Sublime Text 3/Packages
git clone https://github.com/SublimeLinter/SublimeLinter.git
cd SublimeLinter
git checkout sublime-text-3

Yey fun, you're done!

<h2>Installing Soda Theme for ST3</h2> Ready for some intense deja vu?

Follow these four simple steps:

cd ~/Library/Application Support/Sublime Text 3/Packages
git clone https://github.com/buymeasoda/soda-theme/ 'Theme - Soda'
cd 'Theme - Soda'
git checkout soda-st3

Yey fun, you're mostly done!

If you want to use the <a href="https://github.com/buymeasoda/soda-theme/#syntax-highlighting-colour-schemes">Soda Theme Color Schemes</a> follow the steps outlined exactly - just put them in your ST3 folder instead.

Et voilà Finito!

<h2>Conclusion</h2> I'm finding Sublime Text 3 to be a lot faster than ST2. Perhaps my (now old) install of ST2 has become bogged down with crap that it doesn't need, but in switching to ST3 I've found its fuzzy search to be leaps faster and I'm finding it's new fast open of files to be an interesting UX update (when you select a file in the project browser it now opens up a temporary tab instead of previously just showing the text in the code window. Hope that made sense).

Aside from speed ST3 is the future of ST2 and it's better to get on the bus as it's going through the station and before it's out in the country somewhere remote and unattainable. This metaphor went nowhere.

Looking forward to hearing your successes in upgrading to ST3. I also can't wait for the whole package community to fully embrace ST3 support. Should happy any day now, right? ;)

My First App: Jot

Mon, 11 Feb 2013 09:00:47 GMT

<p>In the middle of last year I began playing around with iOS development. I've long been curious about Objective-C and Cocoa Touch, trying tutorials and reading documentation on and off for a few years. Every so often I'd begin work on an application only to have it end in frustration: either I didn't enjoy what I was working on or more commonly the learning curve proved too steep.</p>

<p>However last year when I began working on another application a funny thing happened: I finished it. My first commit was on May 10th and seven months later to the day, I released it to the app store. It is with tremendous pride that I present to you</p>

<h2><a href="http://harrywolff.com/jot/"> Jot. The fastest way to write on your iPhone.</a></h2>

<p>Currently it sits at version 1.2.0. I waited until now to write about it to make sure all initial bugs were worked out before you got your hands on it.</p>

<p>I have a full pipe-line of features planned that I'm anxious to develop and release. The two I'm most excited about are: 1) the ability to customize the editor's appearance and 2) synching of Jots via Dropbox. The latter should prove most interesting as it involves networking which will be fun to learn about.</p>

<p>One of the more crucial elements that enabled me to create this application was the wonderful book, <a href="http://www.bignerdranch.com/book/ios_programming_the_big_nerd_ranch_guide_rd_edition_">iOS Programming: The Big Nerd Ranch Guide</a>. Without this book the uphill battle to understanding how and why Cocoa Touch works would have been much steeper. If you are at all interested in developing your own iOS App I strongly recommend this book. It's wonderful.</p>

<p>I'd also like to thank all my friends and family for supporting me along the way. Without their help I would still be in development of Jot, continuously tinkering away into oblivion. Also a special thank you to everyone who helped me debug my beta builds. It meant heaps, thank you.</p>

<p>It was a long journey to releasing Jot in the App Store, however the sense of accomplishment I felt when it was released was awesome. To everyone thinking about or working on their first app: keep at it and don't stop. You'll get it done.</p>

My Top 10 Albums Released in 2012

Sat, 05 Jan 2013 17:06:57 GMT

<p>When I first sat down to map out what my top albums of 2012 were I drew a blank. Looking blindly back at the year of music I couldn't easily recall any knock-out releases. I was stumped and confused - could the past year of album releases been as boring as my memory is awful? Happily the answer is no - however I do not have high hopes for my memory.</p>

<p>When I started pouring through what albums did come out this past year I was appalled at myself for not remembering any of them. I suppose I shouldn't be so harsh on myself. By my count the year 2012 was an odd year for music. Most of the releases I was looking forward to were follow-ups to their previous break-out successes: The Xx, Dirty Projectors, Sleigh Bells, Two Door Cinema Club, and Passion Pit. Most of their 2012 releases did not meet my high expectations, leaving me somewhat crushed and discouraged.</p>

<p>Yet there were so many new artists that entered the scene in 2012 and their efforts were marvelous. One is already a classic by many accounts. These new artists shaped the year 2012 in ways that could not have been predicted and I am grateful for that. It is always a relief to hear something new. 2012 provided that amply.</p>

<p>Before I get into my top 10 albums of 2012 I'd like to list a few Honorable Mentions. These are the albums that did not break into my top 10 albums of 2012 however they were very close.</p>

<h2>Honorable Mentions</h2>

<ul> <li>Benjamin Gibbard, <em>Former Lives</em></li> <li>Capital Cities, <em>Safe and Sound EP</em></li> <li>Django Django, <em>Django Django</em></li> <li>Fiona Apple, <em>The Idler Wheel…</em></li> <li>Four Tet, <em>Pink</em></li> <li>The Maccabees, <em>Given To The Wild</em></li> <li>Pinback, <em>Information Retrieved</em></li> <li>POP ETC, <em>POP ETC</em></li> <li>The Tallest Man on Earth, <em>There's No Leaving Now</em></li> <li>The Xx, <em>Coexist</em></li> </ul>

<p>And now without further ado, my top albums of 2012.</p>

<h1>My Top 10 Albums of 2012</h1>

<h3>10. A Silent Film, <em>Sand & Snow</em></h3>

<p><img src="/images/posts/2013/01/a-silent-film_sand-and-snow-150x150.jpg" alt="a-silent-film_sand-and-snow" width="150" height="150" class="alignleft size-thumbnail wp-image-2525" /> Every bit a pop album, this album contains one of my favorite songs from 2012, <em>Danny, Dakota & the Wishing Well</em>. Wonderfully catchy and light-hearted I find myself throwing this album on whenever I want to just relax and enjoy some clear-headed pop. Clearly influenced by Coldplay and other modern pop acts, A Silent Film stands tall thanks to their solid production and well written lyrics.</p>

<h3>9. The Shins, <em>Port of Morrow</em></h3>

<p><img src="/images/posts/2013/01/The_Shins_-Port_of_Morrow-150x150.jpg" alt="The_Shins-_Port_of_Morrow" width="150" height="150" class="alignleft size-thumbnail wp-image-2526" /> It's been five years since the previous Shins album. Five years is a long time, especially in the music industry. However I think those five years served The Shins well. <em>Port of Morrow</em> felt like a coming home party, returning to the sound of earlier Shins records. A welcome addition to their catalog and the sounds of 2012.</p>

<h3>8. The Walkmen, <em>Heaven</em></h3>

<p><img src="/images/posts/2013/01/Thewalkmen_heaven-150x150.jpg" alt="Thewalkmen_heaven" width="150" height="150" class="alignleft size-thumbnail wp-image-2527" /> The Walkmen are getting old. That's what this album told me. Their sound is softer, calmer. It's serene by Walkmen standards, erring on the side of serenity as opposed to chaos. It was not a surprise to hear this side of The Walkmen as their previous albums have been consistently leaning this way, however I think it is on <em>Heaven</em> that they found the musical sound they have been searching for.</p>

<h3>7. Grizzly Bear, <em>Shields</em></h3>

<p><img src="/images/posts/2013/01/GrizzlyBearShields-150x150.jpg" alt="GrizzlyBearShields" width="150" height="150" class="alignleft size-thumbnail wp-image-2528" /> <em>Shields</em> safely and confidently continues Grizzly Bear's string of successful albums. This album is more polished and accessible than their previous efforts however the core sound of Grizzly Bear remains strong and alive. As a fan of Grizzly Bear I was not disappointed and was overjoyed to listen to this album on repeat for weeks.</p>

<h3>6. Solange, <em>True</em></h3>

<p><img src="/images/posts/2013/01/solangetrue-150x150.jpg" alt="solangetrue" width="150" height="150" class="alignleft size-thumbnail wp-image-2529" /> Introduced to me late in 2012 Solange's second album is an unapologetic pop album that will have you dancing. Appropriately and accurately comparable to an old Madonna record, this album draws from the sounds of R&B to create songs that will have you bopping along as it sings to your heart.</p>

<p>If anything else I urge you to listen to <em>Losing You</em>, the first track off the album. And once you've finished your fifth listen go watch the video and dance along with Solange.</p>

<h3>5. Divine Fits, <em>A Thing Called Divine Fits</em></h3>

<p><img src="/images/posts/2013/01/divine-fits-150x150.jpg" alt="divine-fits" width="150" height="150" class="alignleft size-thumbnail wp-image-2530" /> This album almost snuck under my radar. A side project of the lead singer of Spoon and band members of Wolf Parade this album reminded me how great Spoon is, how much I want a new Spoon album, and what a great rock album sounds like.</p>

<p>I would not have thought to mix the sounds of Spoon and Wolf Parade however Divine Fits is living proof that the result is wonderful. Combining the pop of a Spoon song with the growl of Wolf Parade has resulted in an album of tracks that delighted the alternative rocker in me. I don't expect to ever hear a Divine Fits song on FM Radio however I do expect and have already witnessed it played to wonderful effect on XM.</p>

<h3>4. Kendrick Lamar, <em>good kid, m.A.A.d city</em></h3>

<p><img src="/images/posts/2013/01/KendrickGKMC-150x150.jpg" alt="KendrickGKMC" width="150" height="150" class="alignleft size-thumbnail wp-image-2531" /> I don't know how I found out about Kendrick Lamar. However his album quickly shot to the top of my list. A solid rap album with a swagger that I had been missing all year.</p>

<p>The production on each track matches the snarl of the M.C., propelling each track forward, getting you to bob along no matter what you're doing.</p>

<p>I feel required to mention the wondrous track that is <em>Bitch, Don't Kill My Vibe</em>. Title aside this track is awesome. It is quite appropriate that the title mentions vibe as this track is overflowing with it. No matter where I am, when I listen to this track you can see me vibing right along with it.</p>

<h3>3. Father John Misty, <em>Fear Fun</em></h3>

<p><img src="/images/posts/2013/01/Fearfunfatherjohnmisty-150x150.jpg" alt="Fearfunfatherjohnmisty" width="150" height="150" class="alignleft size-thumbnail wp-image-2532" /> J. Tillman (aka Father John Misty) used to be the drummer of Fleet Foxes. He left Fleet Foxes last year to pursue his own musical career and since then I have been waiting to listen to what he would release. It wasn't so much my faith in Tillman that perked my attention but more so my love of Fleet Foxes.</p>

<p>With the release of <em>Fear Fun</em> I was not disappointed. It's a wonderful folk album that rollicks along its path, retaining many elements of a Fleet Foxes album while expanding to flesh out what a Father John Misty album sounds like.</p>

<p>The songs are not complex however that is what lends each to being so catchy. The lyrics are alive and sound joyful even when dwelling on death. You can practically hear Father John Misty's beard through each track, a hallmark of many a great folk musician.</p>

<h3>2. alt-J (∆), <em>An Awesome Wave</em></h3>

<p><img src="/images/posts/2013/01/Alt-J_-An_Awesome_Wave-150x150.png" alt="Alt-J-_An_Awesome_Wave" width="150" height="150" class="alignleft size-thumbnail wp-image-2533" /> Until the <a href="http://www.mercuryprize.com/aoty/shortlist.php">Mercury Prize</a> announced this album as the winner I had no idea this band existed. I'm glad I decided to check them out because their album is a marvelous breath of fresh air.</p>

<p>The vocalist that sings on each song has a very unusual voice. He half mumbles and sings each song, giving alt-J a highly unique sound that makes all of their songs instantly recognizable.</p>

<p>Although the band is decidedly Rock they pull in fringe sounds of folk, pop, and alternative that add up to a wonderful sum that give alt-J its distinctive flair and voice. A powerful album and a great band.</p>

<h3>1. Frank Ocean, <em>channel ORANGE</em></h3>

<p><img src="/images/posts/2013/01/Channel_ORANGE-150x150.jpg" alt="Channel_ORANGE" width="220" height="220" class="alignleft size-full wp-image-2534" /> When this album was first released I ignored it. I didn't know who this Frank Ocean guy was nor why I should care about him. I'd like to go back in time to smack my former ignorant self.</p>

<p>Frank Ocean's debut album instantly became a classic. There isn't one track on the album worse than a 6, with multiple tracks perfect 10/10s.</p>

<p>Not only did Frank Ocean write, sing, and rap on all the tracks he also produced most (perhaps all?) of them as well.</p>

<p>The production on every track is luscious and full bodied with vocals expertly blended. The lyrics on <em>Sweet Life</em> and <em>Super Rich Kids</em> are beautiful works of poetry and no matter how hard I tried I was unable to play any of the songs to death.</p>

<p>There's a high level of dedication clearly visible throughout <em>channel ORANGE</em>, making it the top album of 2012 without any doubt.</p>

GetGlue's Front End Stack

Sun, 25 Nov 2012 11:53:00 GMT

<p>Earlier this year <a href="http://getglue.com/">GetGlue</a> began work on the new GetGlue website. It was a chance for a clean engineering slate, allowing us to put all our knowledge together to begin a new project on strong footing. It was a chance to use all of the most powerful client-side technologies to allow us to work efficiently and quickly.</p>

<p>Our old front-end stack consisted of a PHP backend that rendered XML documents with XSLT. We used vanilla CSS to style our pages and plain JavaScript to add sugar to the UI. We relied on jQuery for DOM manipulation and various jQuery plugins to increase the usability of the site. We optimized our JavaScript files for deployment via our own concatenation and optimization script and served it as one canonical file.</p>

<p>The new GetGlue website is taking advantage of many new powerful front end tools.</p>

<p>The tl;dr list of tools:</p>

<ul> <li><a href="http://coffeescript.org/">CoffeeScript</a></li> <li><a href="http://sass-lang.com/">SASS</a></li> <li><a href="http://compass-style.org/">Compass</a></li> <li><a href="http://jquery.com/">jQuery</a></li> <li><a href="http://backbonejs.org/">Backbone.js</a></li> <li><a href="http://underscorejs.org/">Underscore.js</a></li> <li><a href="https://github.com/janl/mustache.js">Mustache.js</a></li> <li><a href="http://requirejs.org/">RequireJS</a></li> </ul>

<h1>Preprocessors: CoffeeScript and SASS</h1>

<p>Before any code was written we made the decision to use preprocessors as part of our tool-chain. Specifically we decided to use CoffeeScript and SASS to code and style the new GetGlue website.</p>

<p>CoffeeScript has enabled us to develop features at a break-neck pace. It strips away a great deal of the boilerplate code that exists in JavaScript. For example when referencing a property on a JavaScript object:</p>

<pre><code>view = response.items[0].title </code></pre>

<p>There'd be instances when the items array would be empty. With JavaScript we would have to verify its existence via:</p>

<pre><code>if (response.items && response.items != null) { view = response.items[0].title } </code></pre>

<p>The CoffeeScript equivalent to the above code involves just one additional character:</p>

<pre><code>view = response.items?[0].title </code></pre>

<p>This is one reason we have found CoffeeScript to be incredibly powerful, enabling us to be twice as productive.</p>

<p>SASS has also allowed us to code efficiently and quickly. We are making great use of SASS’a nested selectors as well as mixins. Those two features alone have made coding CSS a joy again and not a pain. Through mixins we can keep our CSS more DRY-compliant, and with variables it is a breeze to update color configurations.</p>

<p>In addition to SASS we are using Compass. We have found Compass to be a great utility belt of common SASS mixins we would have otherwise made ourselves. Rather than having to manually type every vendor prefix we leverage a Compass mixin to automate the process. For example:</p>

<pre><code>@include border-radius(4px) </code></pre>

<p>Compiles to</p>

<pre><code>-webkit-border-radius: 4px -moz-border-radius: 4px -o-border-radius: 4px border-radius: 4px </code></pre>

<p>We get to save time and sanity. It's a wonderful addition to our toolkit.</p>

<h1>Libraries</h1>

<p>At GetGlue we also take advantage of a number of JavaScript libraries.</p>

<p>It almost goes without saying that we use jQuery for a whole slew of things. DOM selection, manipulation, and everything in between.</p>

<p>More exciting however is our great use of Underscore.js and Backbone.js. Our entire front-end UI has been built with Backbone Views, Models, Collections, and Routers.</p>

<p>Each page of GetGlue is comprised of one general <code>PageView</code> which in turn contains multiple sub-views (and usually those sub-views have sub-views - turtles all the way down).</p>

<p>All of our data is represented in Backbone Models and Collections with our views bound to change events to re-render themselves.</p>

<p>And naturally we employ underscore.js’ functions to make common tasks more enjoyable to perform. Varying from _.map to _.throttle - it makes our coding lives an absolute joy.</p>

<h1>Mustache</h1>

<p>Currently GetGlue is rendered entirely client-side and because of that we make extensive use of Mustache templates.</p>

<p>We've found the (mostly) logic-less Mustache templates easy to work with and they are a cornerstone of our new website. Without any templates we'd have nothing to render and there'd be no website for you to see.</p>

<p>By keeping (most) of the view's logic out of the template we're able to focus on just the structure of the view and not have to worry about anything else. This allows for fear-less template refactors as nothing else is affected.</p>

<h1>RequireJS</h1>

<p>When developing a large JavaScript application it can become hard to keep track and manage all the moving pieces that are required to make the application run. To that end we have turned to RequireJS as our module loader and build tool.</p>

<p>Each discrete section of code lies in its own JavaScript file, attached to its own namespace, and only included by another file when explicitly requested. By adhering to these strict rules we avoid unexpected behavior and can code with confidence.</p>

<p>Having code for one specific functionality in its own JavaScript file makes for great organizational clarity and lends a certain amount of intuition to our code base: by that I mean when file B is a subclass of file A the file structure mimics that behavior.</p>

<p>For example on GetGlue when you open an item from the Guide you open what we internally refer to as a Card. Each of those types of popovers are derivatives of a Card. In our file tree we have the <code>card.coffee</code> base class and in the directory <code>cards/</code> lay all of the card subclasses.</p>

<p>This intuitive structure makes not only for development delight but also allows for easy on boarding of new hires as the system is easy to understand.</p>

<p>We also use RequireJS as our primary build tool for our JavaScript and SASS.</p>

<p>The way you include JavaScript files into other modules is through RequireJS’ require() function. As part of its build process RequireJS traces all require() calls and inlines them into one JavaScript file that we then serve to the browser. (Note: RequireJS allows for other build configurations).</p>

<p>RequireJS will also take all CSS import statements and inline them into a single CSS file.</p>

<p>By the end of the build process we’ve slimmed our JS and CSS files to one a piece making for a quick download by the client and a speedy experience.</p>

<h1>Conclusion</h1>

<p>We’re very proud of what we've accomplished with the new GetGlue website.</p>

<p>By switching to CoffeeScript and SASS we were able to develop quickly and efficiently. We were able to create features and tweak them without much effort. It made the entire development experience much more enjoyable.</p>

<p>Giving our site some Backbone.js made UI transition and state management easier than ever before. I will never again dip my hand into the DOM to find state. Thar be dragons.</p>

<p>RequireJS is a beautiful tool that I wish I had known about years ago. Its module management is intuitive and its build tool is very powerful.</p>

<p>We've had a great time building the new GetGlue website. We hope you enjoy it as much as we do.</p>

What I Install After A Fresh OS Installation

Wed, 12 Sep 2012 09:26:43 GMT

<p>I received a great gift from work last week. It came in the form of a rectangle, and fit in the palm of my hand. It has made my life easier and more enjoyable. In fact it has single handedly changed the way I approach most things throughout my day.</p>

<p>A brand new SSD hard drive.</p>

<p>I've never witnessed the power of a SSD drive first hand. I've used friend's computers that had a SSD drive, but never before has my own computer been running an SSD drive.</p>

<p>Let me tell you: it's glorious.</p>

<p>I decided that during the installation of the SSD I would also install a fresh copy of OS X (as opposed to a Time Machine restore).</p>

<p>I figured it'd be fun to log the steps I took after installing Mountain Lion. They're fraught with monotony but one that every user must go through when setting up their machine after a fresh install.</p>

<p>So what follows is my Post Mountain Lion install log. I did exactly what I expected: install my favorite applications and set up my system presences. Only surprises were the settings I forgot I had ever changed in the first place.</p>

<p>Without further ado! The list!</p>

<ul> <li><p><strong>Finished installing Mountain Lion</strong></p></li> <li><p>Opened App Store</p></li> <li><p>Installed iA Writer to write these notes</p></li> <li><p><strong>Updated ML to 10.8.1 (Rebooted)</strong></p></li> <li><p>Went through App Store previous purchases and installed old apps:</p>

<ul> <li>Twitter</li> <li>Sparrow</li> <li>The Unarchiver</li> <li>Xcode</li> </ul></li> <li><p>Went to System Preferences > Trackpad</p>

<ul> <li>Turned on 'Tap to click'</li> </ul></li> <li><p>Opened Safari, Downloaded:</p>

<ul> <li>Google Chrome</li> <li>Skype</li> <li>Dropbox for Mountain Lion</li> </ul></li> <li><p><strong>Installed Chrome and logged in to download my cloud synched bookmarks</strong></p></li> <li><p>Install and setup Skype</p></li> <li><p>Went through System Preferences, customized to my liking</p>

<ul> <li>Turned off Gatekeeper</li> <li>Added twitter account</li> </ul></li> <li><p>Xcode finished installing</p>

<ul> <li>opened to install remaining SDKs and Sims</li> </ul></li> <li><p><strong>Downloaded and installed Sublime Text 2</strong></p></li> <li><p><strong>Copied old Music onto hard drive / restored iTunes</strong></p></li> <li><p>Set up Dropbox and download old files</p></li> <li><p>Customize Terminal</p></li> <li><p>Duplicated Pro theme</p>

<ul> <li>Made font size 13px</li> </ul></li> <li><p>Customize Sparrow</p>

<ul> <li>Add back signature to accounts</li> <li>Turn off message preview</li> </ul></li> <li><p>Customize Finder</p></li> <li>New finder window shows: user root</li> <li>Customize what folders show on left side</li> <li><p>Change search preferences to keep last settings</p></li> <li><p>Install Cloudapp</p></li> <li><p>Install MAMP</p></li> <li><p>Install VirtualHostX</p></li> <li><p>Set up virtual hosts</p></li> <li><p>Install Git</p>

<ul> <li>Set up git</li> <li>Set username, email</li> <li>Copy over old .gitconfig to new install</li> </ul></li> <li><p>Install oh my zsh</p>

<ul> <li>Use my theme</li> <li>Install plugins</li> </ul></li> <li><p>Install command line Sublime Text 2</p></li> <li><p>Set up SSH Key for Github</p></li> <li><p>Set up RVM</p>

<ul> <li>Install Compass</li> </ul></li> <li><p>Install node.js</p>

<ul> <li>CoffeeScript</li> <li>RequireJS</li> </ul></li> <li><p>Update Python to latest</p>

<ul> <li>setuptools</li> <li>pip</li> <li>fabric</li> </ul></li> <li><p>Install nvALT</p></li> <li><p>Install Aperture</p></li> <li><p>Set up Sublime Text 2</p>

<ul> <li>Copied over old packages</li> </ul></li> </ul>

<ul> <li><p>Installed Printer</p></li> <li><p>Sys Pref -> Accessibility -> Use scroll modifier keys to zoom</p></li> <li><p>Install Phonegap 2.0</p></li> </ul>

<ul> <li><p>VLC</p></li> <li><p>Transmit</p>

<ul> <li>Reinstalled Favorites</li> </ul></li> <li><p>Sketch</p></li> <li><p>Pixelmator</p></li> <li><p>Restore MAMP DBs</p></li> <li><p>Install Last.fm</p></li> </ul>

<h1>Afterward</h1>

<p>There isn't much left say. After the first three days of ferocious software installation and customization I was pretty much done and comfortable with my current computer setup.</p>

<p>There were a few things I did forget to copy from my old hard drive that proved to be a bit of a nuisance. I forgot to backup my Transmit favorites and had to prowl through my old hard drive to find where those files were saved. I also forgot to backup my Apple Developer keychains which I ended up just re-creating. Next time I'll just back them up safe and sound.</p>

<p>The speed of the SSD drive made installing all my old programs so fast that the once laborious process of setting up my computer from scratch went by in a blink. Tasks that used to require patience as my HDD read and wrote bytes were done before I was even ready for the next task.</p>

<p>There's no turning back for me now. I have seen the glory of SSD. My future has been written.</p>

My Favorite Sublime Text 2 Plugins aka Packages

Thu, 26 Jul 2012 08:14:01 GMT

<p>The current code editor that is widely in vogue amongst programmers is far and above Sublime Text 2. There's many reasons that ST2 usurped this crown previously held by TextMate (it's new and actively maintained) but one of the biggest reasons is its ability to have its core functionality extended via plugins.</p>

<p>The plugins that you can install for ST2 make this otherwise light weight text editor all that much more powerful and effective - but only in the areas you care about.</p>

<p>I've grown particularly attached to a couple of ST2 plugins. Ones that I know that if I hadn't found them my love for ST2 wouldn't be as strong as it currently is.  So in a very particular order what follows are my favorite and most appreciated plugins for Sublime Text 2 that I use on a daily basis.</p>

<p><strong>Note:</strong> It is of tremendous help to know of one keyboard shortcut for ST2 that lets you easily access the majority of the following plug-ins: <code>Cmd+Shift+P</code>. Hit that keyboard shortcut and you'll see the Command Palette at the top of your ST2, in which you can take advantage of ST2's fuzzy search to find the particular feature you want to use.</p>

<h2><a href="http://wbond.net/sublime_packages/package_control">Package Control</a></h2>

<p>Without this plugin your entire ST2 plug-in experience will be dismal. I say this with all sincerity and seriousness: Package Control makes packages fun and easy to use.</p>

<p>Basically Package Control connects to a remote server that holds a large public list of published packages for ST2. It can then download any of those plug-ins and install them directly into your copy of ST2 without ever moving your mouse. It's a wonderful experience, one I feel that should have have been included by default in ST2.</p>

<strong>Quick Demo of Awesomeness</strong>

<ol> <li>Open Command Palette (Cmd+Shift+P)</li> <li>Type 'pa in' - you should see 'Package Control - Install Package' highlighted at the top.</li> <li>Type 'SublimeLinter', hit enter and voila! SublimeLinter is now installed!</li> </ol>

<h2><a href="https://github.com/SublimeLinter/SublimeLinter">SublimeLinter</a></h2>

<p>SublimeLinter was one of those packages that I originally thought it'd be neat to have but I wouldn't really need. I couldn't have been more wrong.</p>

<p>SublimeLinter has quickly shot to the top of my list of must have packages, becoming an integral part of my productivity suite.</p>

<p>After installing SublimeLinter you will be linting your code as you type. This means that you can not only see what syntax errors you might be creating but you can also catch code style issues (Python’s PEP8 I'm looking at you).</p>

<p>The ability to lint your code as you type has helped me catch countless careless mistakes. Let's say I forgot to include a closing parenthesis. Rather than executing my code only to find an error I'm able to see the error as I write it and correct it right then and there. This saves me time, stress, and grief.</p>

<p>Another area that I've found SublimeLinter to be of great help is when learning a new language. Think of SublimeLinter as a bowling lane with the bumpers put in. It helps keep you between the lines of the language, nudging you toward real code when you start to veer to the edges.</p>

<strong>Quick Demo of Awesomeness</strong>

<ol> <li>Create a JavaScript file and type in a simple if statement. </li> <li>Don't put the if statement in parenthesis.</li> <li>See the live linting do it's magic. </li> <li>Profit. </li> </ol>

<h2><a href="https://github.com/titoBouzout/SideBarEnhancements">SideBarEnhancements</a></h2>

<p>I'm not entirely sure why this plugin isn't included by default. It gives you a wealth of options when right clicking files in ST2’s sidebar.</p>

<p>You can delete a file, duplicate it, and any other file operations you can think of.</p>

<p>I use this plugin all the time when creating a new JS file or CSS file. Before I'd have to open up Terminal or Finder to do any simple file system manipulation. This plugin saves me that time and distraction away from ST2.</p>

<strong>Quick Demo of Awesomeness</strong>

<ol> <li>Open a saved file in ST2. </li> <li>Right click on the file. </li> <li>Behold the multitude of options now at your fingertips. </li> </ol>

<h2><a href="https://github.com/ehamiter/ST2-GitHubinator">GitHubinator</a></h2>

<p>This is such a simple lovely plugin.</p>

<p>Basically if you're working on a project whose repo is also on GitHub you can quickly open the GitHub page of that file through a keyboard shortcut.</p>

<p>I use this all the time at work to easily link a co-worker to a line of code that I might need help with.</p>

<p>Again it's the time this plugin saves me that makes it so valuable. It's not hard to open GitHub and navigate to the file, however it's something that can be automated and that's what this plugin does.</p>

<strong>Quick Demo of Awesomeness</strong>

<ol> <li>Open a local repo that is on GitHub. </li> <li>Go to any random file and line. </li> <li>Either hit Cmd+\ or right click on the document and hit ’Githubinator’ to see the plugin in action. </li> <li>Find yourself on the GitHub page of that file. </li> </ol>

<p>This plugin brings the power of the Git command line to ST2.</p>

<p>You can run git status through the Command Palette and ST2 will open a new file tab to show you the results.</p>

<p>Or you can git log. Or a git blame. Honestly that's how I use this plugin the most. To run a quick git blame to see which one of my co-workers I can ping for help on a line of code they wrote.</p>

<strong>Quick Demo of Awesomeness</strong>

<ol> <li>Open a file in a local git repository. </li> <li>Open the Command Palette (Cmd+Shift+P). </li> <li>Type ’git blame’ and hit enter. </li> <li>A new ST2 tab will open with the git blame output. </li> </ol>

<h2><a href="https://github.com/sublimator/ZenCoding">ZenCoding</a></h2>

<p>I was curious about the excitement around ZenCoding for a while. It wasn't till installing the ST2 package and playing around with it that I become a complete convert to the ZenCoding way of life.</p>

<p>ZenCoding makes scaffolding new layouts a complete breeze by taking your shorthand DOM structure and expanding it to full HTML tags. Rather than having to monotonously type ever closing tag for every new <code><div/></code> ZenCoding takes care of that for me, expanding and creating the tags it knows I want to use.</p>

<p>ZenCoding saves times, and for me that's what makes it so valuable.</p>

<strong>Quick Demo of Awesomeness</strong>

<ol> <li>Open a new file. </li> <li>Type: <code>table>(tr>td*2)*3</code></li> <li>Hit tab. </li> </ol>

<h2><a href="http://xavura.github.com/CoffeeScript-Sublime-Plugin">CoffeeScript</a></h2>

<p>I've recently become a big fan of CoffeeScript. Unfortunately ST2 doesn't ship with language support for CoffeeScript file.</p>

<p>Fortunately there's a plugin that gives ST2 CoffeeScript syntax support. And thank goodness it does because I would not enjoy writing CS without proper syntax highlighting.</p>

<strong>Quick Demo of Awesomeness</strong>

<ol> <li>Open a CoffeeScript file. </li> <li>See how wonderfully highlighted the file is. </li> </ol>

<h2><a href="https://github.com/buymeasoda/soda-theme/">Theme - Soda</a></h2>

<p>Theme - Soda isn't really a plugin per se, however it is installed like one. Don't get me wrong, the default theme of ST2 isn't painful to look at, however I have found this theme to be more joyful to use while I'm coding throughout the day.</p>

<p>There's a light and dark theme, so depending on your preference there's a Soda theme that's right for you. Also be sure to find your favorite color scheme to match, or you can just <a href="https://github.com/buymeasoda/soda-theme/#bonus-options">use the one Soda uses</a>.</p>

<strong>Quick Demo of Awesomeness</strong>

<ol> <li>Activate the Soda Theme. </li> <li>Close and reopen ST2. </li> <li>Enjoy the new prettiness. </li> </ol>

<p>So there you have it, my favorite Sublime Text 2 plugins aka packages. These are the ones I couldn't live without however I also make use of quite a few other plugins.</p>

<p>I encourage you to <a href="http://wbond.net/sublime_packages/community">browse the list of published packages</a> to see of there's one there that will make your daily coding experience that much more enjoyable. After all, every bit helps to make coding on a daily basis a pleasurable experience.</p>

<p>If you have any packages you use that you can't live without please let me know about them in the comments! I'm always on the lookout for that next best package.</p>

<p>Who knows? Maybe you'll even create it :).</p>

My Experience with Ruby On Rails as a PHP Developer

Sun, 06 May 2012 20:43:26 GMT

<p><em>Note: This post is an extension of my previous post <a href="http://blog.harrywolff.com/my-experience-with-php-frameworks-yii-codeignitor-and-symfony/" title="My Experience with PHP Frameworks – Yii, CodeIgnitor, and Symfony">about developing with PHP frameworks.</a></em></p>

<p>Recently I created a new web app using Ruby on Rails. By trade I'm a PHP and JavaScript developer so this foray into RoR broke new ground for me.</p>

<p>I went with Rails over a PHP framework mostly because I wanted to try something new. I wanted to try something different and with its popularity Rails was a great pick.</p>

<p>In brief I found my experience developing with Ruby on Rails to be both frustrating and effortless.</p>

<p><strong>Frustrating</strong>: because I was new to RoR I didn't know all of its tricks and how to do things the Rails Way. As a result I felt like I was coding at a slower pace than I usually do. Really that's the performance hit anyone experiences when trying something new.</p>

<p><strong>Effortless</strong>: once I learned some Railisms and began to get the swing of how Rails works coding went smoothly. Using Rails’ ActiveRecord was magic once I understood how and why I should use it. Also Rails’ form helpers made form handling a joy to work with. Again: this was after I picked up some understanding of how these things worked. Before understanding I was close to pulling out my hair.</p>

<p>So what follows is a run through of my thoughts and experiences while I used Ruby on Rails to create <a href="http://datesandpairs.com/">Dates & Pairs</a>.</p>

<p><em>Disclaimer: I am in no way a Rails or Ruby expert so if something written is incorrect please let me know and I will update the post to reflect the correct information.</em> </p>

<h2>Ruby is [more] Complicated (than PHP)</h2>

<p>With a PHP application all you need is an Apache server.</p>

<p>With a Ruby on Rails application you need <a href="https://rvm.io/">RVM</a> (optional), <a href="http://rubygems.org/">gems</a>, Rails, and patience.</p>

<p>It isn't possible to open your favorite Code Editor and start writing. You have to create a Rails application and play within its confines. (To be fair those confines are larger than most PHP applications.)</p>

<p>Ruby is a full fledged object oriented language whereas PHP is a scripting language. There's no equivalent to an index.php file with <code><?php echo 'Hello'; ?></code> in it in the Ruby world. The closest you'll get is a <a href="http://www.sinatrarb.com/">Sinatra</a> app, yet even then you're making use of the Sinatra gem.</p>

<p>That was one of the biggest differences I faced while developing in Ruby on Rails. I didn't know where the entry point for my program was and that led to a great deal of frustration. In a PHP application I almost always know where things start. In my RoR app I had to do a good deal of sleuthing to figure that out. Although it wasn't really important to my coding it mattered to me on an intellectual level, something that I couldn't let sit unanswered.</p>

<h2>Ruby the Language</h2>

<p>Just as there's a PHP way of doing things there's a Ruby way of doing things. This goes from syntax to how Ruby functions are named.</p>

<p>As a PHP developer I have grown used to checking if a variable is set by using PHP's <code>isset()</code> function. In fact most PHP functions, whether it be for array or object manipulation, the variable is passed into the function to perform the desired computation. In Ruby all function calls are made on the object. This makes for beautiful code but also requires a shift in one's cognitive approach.</p>

<p>In PHP you'd type <code>isset($_GET['name'])</code> to check if the query param <code>name</code> was set.</p>

<p>In Ruby you'd type <code>params[:name].blank?</code>.</p>

<p>In PHP if you wanted to change 'Hello World' to 'Hello Bob' you would type <code>str_replace('World', 'Bob', 'Hello World')</code>.</p>

<p>In Ruby you would type <code>'Hello World'.gsub('World', 'Bob')</code>.</p>

<p>As you can see the Ruby syntax allows you to make function calls directly on the subject, whereas PHP requires you to pass in the subject to the function.</p>

<p>The reason for this is that Ruby is an object-oriented language. Everything in Ruby is an object, allowing you to make function calls on anything.</p>

<p>Besides the power you can get from object-oriented programming, this allows you to write code that is very easy to read and follow.</p>

<p>The main problem with moving to Ruby is that you have to learn what all those function calls are. Also you have to start developing a sense of what function calls would be named. Like above, I would not have guessed that <code>gsub</code> would be the function name to replace part of a string.</p>

<p>That's why <a href="http://www.ruby-doc.org/">Ruby-Doc.org</a> became my best friend while learning Ruby.</p>

<p>Ruby on Rails is an MVC architecture that makes it very difficult for you to cheat. This is a good thing as the more you adhere to a MVC design the easier it will be for you to maintain your application.</p>

<p>As a result you should take advantage of Ruby's object-oriented powers. Create additional methods on your Rails models. This will allow for later development joy, keeping your code dry and easy to read and maintain.</p>

<h2>Deployment</h2>

<p>Without a doubt the hardest part to developing my app in Ruby on Rails was deploying the final code to production. I damn near quit at this point as the curve to get my site live was very steep.</p>

<p>I used Rails' relatively new <a href="http://guides.rubyonrails.org/asset_pipeline.html">asset pipeline</a> which in retrospect was probably above my skill level. The documentation for deploying with Rails' asset pipeline isn't very rich and as such I had to hunt and peck around the web to find the answers I needed.</p>

<p>I am hosting my program on <a href="http://www.webfaction.com?affiliate=hswolff">Webfaction</a> which is a pseudo-VPS service. You get shell access and the ability to host a plethora of applications, Rails being one of them.</p>

<p>I also used <a href="https://github.com/capistrano/capistrano">Capistrano</a> to deploy my application. Without this software I would dread deploying any updates. With this software it's a breeze. All I do is <code>cap deploy</code> and I start the automated process to updating my production code.</p>

<h2>Conclusion</h2>

<p>All in all I had a fun time learning how to create a Ruby on Rails application. Half of it was spent learning Ruby, half was spent learning Rails, and half was spent learning how to learn Ruby and Rails.</p>

<p>I thought RoR would speed up my development time and it did. However my inexperience with Ruby and Rails slowed me down, being the primary source of productivity speed bumps.</p>

<p>I was a little upset at how complicated it was to use Rails` asset pipeline. The biggest reason was definitely its lack of quality documentation. However the features it brings you are quite lovely (CSS and JS concatenation and minification).</p>

<p>Would I use RoR for my next project? Yes. But I won't. I have my eyes set on using <a href="http://nodejs.org/">Node.js</a> for my next project. My JavaScript skills have immensely improved and the prospect of coding in JavaScript on both the front-end and back-end brings a smile to my face. Stay tuned for when that happens.</p>

<p>Ruby is a hell of a language and one I look forward to playing with more. It brought an element of joy to my coding that I had never before experienced with PHP.</p>

<p>Sure there were times I wanted to run back to the warm and familiar embrace of PHP's dollar signs but the fluidity of Ruby kept me close.</p>

<p>Of course at the end of the day it doesn't matter what language you use. Just start coding and don't give up. Everything else is just fluff.</p>

The Best Mac Git Gui

Mon, 30 Jan 2012 14:51:43 GMT

<a href="http://en.wikipedia.org/wiki/Git_(software)">Git</a> is one of the most powerful and effective revision control systems available. It's lightweight and highly configurable, complimenting almost anyone's programming workflow. Predominately you interact with git from the command line, inputting commands such as git status or git commit to manipulate your repository.

When you first learn git the CLI can be daunting and confusing. Browsing through your history of commits with git log is not efficient. Even after you learn a few tricks such as git log --graph --oneline --all it remains difficult to really explore your history.

This is why a git GUI can put the joy back into using git.

This article is focused on git GUIs for Mac OS X running 10.5 or greater. As I find new git GUIs I will add them to this list, hopefully making a canonical collection of Mac git GUIs.

<hr />

<h2>GitX</h2> GitX is one of the most popular open-sourced Git GUI for the Mac. Subsequently it has been the source of numerous forks. Here's three of the best forks I know about. <h2><a href="http://gitx.frim.nl/">GitX - Pieter</a></h2> <img src="/images/posts/2012/01/GitX-pieter01.png" /> <img src="/images/posts/2012/01/GitX-pieter02.png" />

The first GitX version released was created by <em>pieter</em> on his GitHub account. This version is highly stable however it lacks two very important things: features and active development. The last time this version of GitX was updated was on <a href="https://github.com/pieter/gitx/commits/master">Oct 2nd, 2009.</a> Due to the lack of a development cycle the UI has begun to show its age. To toggle between viewing your history and staging a commit isn't as intuitive as other git GUI clients. This version is quite minimal in that regard: you can view your history, stage commits, and commit.

Pros

Stable Free

Cons

No active development Non-intuitive UI

This is one of the more popular GitX forks available. It was my client of choice until I discovered one big problem this fork has: it runs very slow with large repos. When I first began using GitX (L) my repos were small enough that it ran fine. However as soon as my repo grew this fork couldn't keep up. Every time I'd refresh my history of commits I'd have to wait upwards of 30 seconds for it to finish scanning my log history.

Aside from the performance issues on large git projects this fork brings a lot of nice UI improvements. The overall usability of this GitX client is great. The screens are clearly laid out, easy to navigate, and the GUI doesn't get in the way should you want to drop into a CLI and directly type in some git commands.

Pros

Free Easy commit history view Shows how far ahead/behind your branch is with a remote branch Staging commits is easy and fast Easy to view and checkout tags, branches, and stashes

Cons

Very slow on large repositories

<h2><a href="https://github.com/rowanj/gitx">GitX - Rowanj</a></h2> This GitX version is forked off of GitX (L). As such it has all the pro's of GitX with some noticeable differences. The best difference is its performance on large repos: it's fast. It's able to load commits just as fast as the native git client. As noted on the GitHub page there are other fixes in this version which I'm sure help with its stability as I have been using this GitX client for a while without any crashes. My only negative about this fork is it removed from the UI how many commits you were ahead or behind of a remote branch.

Pros

Free All the pros of GitX (L) Very fast loading of large repos

Cons

Removed UI view of how many ahead or behind your branch is of a remote branch

<h2><a href="http://gitboxapp.com/">Gitbox</a></h2> <img src="/images/posts/2012/01/Gitbox-01.png" /> <img src="/images/posts/2012/01/Gitbox-02.png" /> <img src="/images/posts/2012/01/Gitbox-03.png" />

Gitbox prides itself on its minimalism. The UI is calm but plain, with few buttons available to push, allowing you to focus on your commit history and staging. It doesn't have a built in diff app so by default it makes use of FileMerge but is compatible with a range of 3rd-party diff applications. Most of what you see in Gitbox is fairly easy to do in a CLI, however if you must have a GUI for those tasks then Gitbox is the GUI for you.

Pros

Free for 1 repo Minimalistic Fairly fast

Cons

Paid for more than 2 repos Un-intuitive UI for staging Features hidden in dropdown boxes Not enough UI features to justify GUI

<h2><a href="http://www.git-tower.com/">Tower</a></h2> <img src="/images/posts/2012/01/tower-01.png" /> <img src="/images/posts/2012/01/tower-02.png" />

Tower is one of the more full-featured git GUI clients available. Nearly everything that you would want to do with git you can do with Tower. This makes for a very powerful GUI however one that can be intimidating on first blush. Each screen has a lot going on as it seems that the creators of Tower tried to implement nearly everything you could do with git in the CL with a GUI. This makes for screens bursting with buttons and tabs and tables of information. If you really don't like the CL then Tower is a suitable choice for you.

Pros

Full-featured - can do nearly everything via GUI Pretty UI Adopts OS X UI standards

Cons

Paid, $59 for a license Crowded UI Lots of buttons

<h2><a href="http://www.sourcetreeapp.com/">SourceTree</a></h2> <img src="/images/posts/2012/01/sourcetree-01.png" /> <img src="/images/posts/2012/01/sourcetree-02.png" />

This GUI is another full-featured one that rivals Tower. Where it differs significantly is the price: SourceTree is freely available in the Mac App store. That's a nice convenience that makes installing this GUI a breeze. Another nice feature of SourceTree is it is able to load Mercurial repositories alongside git repositories. Like Tower you can do almost anything through SourceTree that you can do through the git CL client. SourceTree also has a lot of buttons in its UI however I found these UI elements to be more intuitive than Tower's. SourceTree makes a lot of things automatic and easy to use, making it one of the best choices for a git newbie.

Pros

Freely available in Mac App Store Full-featured Fast

Cons

Lots of buttons Some tasks easier to perform via CL

<hr />

<h2>Conclusion</h2>

And that wraps up all the git GUIs that I know of! It should go without saying but your mileage may vary so pick the GUI that best suits you. What I might not like about Gitbox might be what you love about it, and that's ok.

I will warn that using a git GUI exclusively is a bad idea. You should learn how and why git works the way it does. Inevitably you will run into some weird problem and solely relying on a GUI to help you could lead to even more problems. Learn the git command line client. When you know it then enjoy the benefits of a GUI to speed up your workflow.

I personally use GitX - Rowanj to stage my commits and search my commit history. I use the command line for almost everything else. I push, merge, and rebase exclusively through the command line, giving myself complete control over my git commits.

Whatever GUI you pick just make sure it works for you and you aren't working for it. With that said, get coding!

Prune Remote Git Branches

Thu, 13 Oct 2011 11:41:06 GMT

Git is a wonderful version control system. It’s light, nimble, and fast. It makes managing code amongst many developers a dream.

Unfortunately it has a fair share of quirks.

One of the quirkiest quirks that I’ve run into a couple times now is an issue with remote git branches.

When a remote git branch is deleted from the server your local repository doesn’t update its references.

The easy solution is to run this command:

<code>git remote prune origin</code>

This prunes and removes all remote branches that no longer exist.

<a href="http://kpumuk.info/development/memo-2-useful-git-tricks-with-remote-branches/">Full credit to Dmytro Shteflyuk for this tip.</a>

My Experience with PHP Frameworks - Yii, CodeIgniter, and Symfony

Mon, 26 Sep 2011 00:12:45 GMT

<h2>Overview</h2>

A week ago I started work on a personal web project using PHP as my programming language of choice. This wasn’t a hard decision as I use PHP daily for work and have a great deal of strength in the language.

As I set forward to create my web app I knew I wanted to use a prebuilt PHP web framework. My reasons included not wanting to reinvent the wheel and the belief that the benefit of open source software is its great community of support.

Another reason I wanted to use an open source PHP framework was that it provides a tried and true framework complete with features that I otherwise would not have time to code myself. Although this project is being done during my free time I don’t want its quality to suffer. So by using a framework that already provides proper request/response, and routing support it would allow me to focus on designing and developing the app and not worry about the architecture that it would be built on.

From my research (lots of Google searches and crawling through and around websites) I found the current top PHP frameworks are:

Yii
CodeIgniter
Symfony

Here’s my interactions with them.

<h2>Symfony</h2>

I first chose Symfony as the framework to use for my web project. I tried its <a href="http://symfony.com/get_started">Quick Tour</a> and found myself agreeing with the design decisions of the software. It made sense to me how things were built and how they were used.

In addition to the content of the Quick Tour I also found the design of Symfony’s website to be quite appealing. Although it is said to not judge a book by its cover we humans tend to notice things that are pretty. The same is true of Symfony’s website. Its pleasing to look at, pleasing to use, and I felt a sense of professionalism and polish that made me feel safe to learn more about the code.

I spent a few nights reading in bed on my iPad the rest of Symfony’s tutorials and docs and finally felt confident enough to begin coding. I did begin doing some coding in Symfony and aside from the difficulty of learning a new project’s jargon I was actually having an enjoyable time using Symfony. That is until I ran into Symfony’s Bundle system.

<a href="http://symfony.com/doc/current/book/page_creation.html#page-creation-bundles">Symfony’s bundle system</a> is unique. I honestly don’t fully understand it but I was not enjoying learning what I was reading. From what I read it sounds like a very strong design approach to maintainable and self-contained code however it is not a convention I’m used to, nor one that I found myself wanting to learn.

Even more than not understanding fundamentally what a bundle is and what it is used for, from what I understood I felt as if it was overkill for my purposes and would end up slowing my development down rather than help speed it up. As a result I stopped learning Symfony and began looking at the other two popular PHP frameworks.

<h2>CodeIgniter</h2>

I never tried programming with CI but from what I read I actually liked what the software provided. My biggest irk about the project was its close tie to the commercial ExpressionEngine. Although probably not based on any pieces of truth I could not shake the feeling that by using CI I was using a hand-me-down relative of ExpressionEngine.

Now this is perhaps in no way based on reality but it was my subjective feeling that I got when reviewing the websites. It was that feeling that pushed me away from trying to use CodeIgniter for my project.

I only write this so that the creators of CodeIgniter know that these sentiments and perceptions exist (perhaps only within me). However if its more widespread it should be addressed so as to not lose potential users of the framework.

I was very apprehensive about using Yii. It’s mostly known as the ‘new-kid’ on the block in terms of PHP frameworks. It's a framework that doesn’t seem to have as much real world experience as other PHP frameworks as there doesn’t seem to be a wealth of sites using it in their production environment. Nevertheless this was the last choice I had in the realm of PHP and I wanted to see what it had to offer.

Yii is a very solid PHP framework. There is a pretty thorough <a href="http://www.yiiframework.com/doc/guide/">guide to Yii</a> that I went through and tried out. It’s a very solid introduction to the framework that showcases its code design decisions and teaches you how to use the framework along the way. I liked it and started programming my web app with Yii.

Things were going mostly well. I hit a few speed bumps here and there that a Google search was fortunately able to solve (on Yii’s own message board no less - thumbs up for that). I noticed a large amount of foreign writers (mostly Russian) frequenting the forum which led me to believe that Yii’s popularity lies mostly outside of the USA’s borders. This left me slightly uneasy as I only speak English and I didn’t want to translate to find the answers to my questions.

Nevertheless I plugged forward and continued to code. Yii’s guide was lacking in some aspects however <a href="http://www.yiiframework.com/doc/api/">Yii’s api reference</a> is absolutely amazing. If more open source projects had documentation like Yii’s the open source community would be a safer and happier place. The main problem with the API reference is not with the reference but - in my opinion - with Yii itself.

Yii provides a lot, and as a result it has a large codebase. This led to frequent bouts of 8+ Chrome tabs open as I tried to triage the proper function to use for the effect that I wanted. This happened a few times: once with relational support and once with helper function support. After going through these maze-like quests to find what I wanted to do I realized that I had hit the wall. Yii was no longer helping me. It was getting in the way and I did not want that to happen.

That was one of my most important rules: the framework is there to help me get my job done - not hinder me. Of course there are points of friction when learning new software yet when I found myself continuously running into them I did not feel as if I was using the right software for the job.

<h2>Conclusion</h2>

One of the largest problems I continuously saw when looking for a suitable PHP framework to use was the discord in the PHP community. There aren’t any dominant PHP frameworks (Zend aside which I will forever gloss over due to complete lack of interest).

As a result of there not being one ‘true’ PHP framework that everyone agrees is the best one to use most development efforts are divided among the available PHP frameworks. Were these development efforts united under one project not only would the amount of developers supporting the software increase but it would also help decrease decision fatigue.

When I was searching for what PHP framework to use I found myself growing quickly tired trying to decide which one was the best and which one would help me the most. After a while I had to put blinders on and just start trying to use each PHP framework that I wanted but the process to get there was much longer than it should have been.

Perhaps I’m unique in this situation but I doubt it. If there were only two frameworks to choose from, or frameworks that were obviously created for entirely different purposes that would have made my decision making process umpteenth times easier.

Yet at the end of the day I found myself striking out. Whether for subjective or real reasons I did not enjoy my experiences with any of these PHP frameworks. Also my pinky finger got really tired holding shift so that I could write $ all the fricken time. It’s the small things that matter and all those $ add up.

I’ve now decided to try my hand at Ruby On Rails. It’ll do me good to try my hand at another language. I’ve already ported over what code I had so far from Yii in about half the time it took me to originally create. I’m liking it so far and will of course update again with future reflections.

<em>Update: <a href="http://blog.harrywolff.com/my-experience-with-ruby-on-rails-as-a-php-developer/" title="My Experience with Ruby On Rails as a PHP Developer">Check out my thoughts and reflections of my time spent developing with Ruby on Rails</a></em>

How To Find A Tech Job

Tue, 02 Aug 2011 18:33:29 GMT

I'm helping a friend find a job. I've already gone through the entire job search process and I do not envy the guy. It's a hard, grueling process but one that when successful is such a rush.

Off the top of my head I shared with him a list of job listing websites I used during my search. These sites are mostly geared toward technology jobs but hopefully it'll spark an idea of a place to search for a job you haven't thought of before. Like maybe one of your favorite websites is hiring, or has links towards a website that is hiring.

What I've learned from my job hunt is that you have to get creative. You have to look for jobs in places you wouldn't expect to find them.

And of course you have to apply. My philosophy on that matter is: it doesn't hurt to apply but it does take a lot of time.

Here's the shortlist of sites that may help you land that next killer job you're looking for:

<a href="http://www.dice.com/">Dice.com</a><br/> <a href="http://www.craigslist.org/">Craigslist Job Board in your area</a><br/> <a href="http://nytm.org/made/">Internet Made in New York City Hiring Spots</a><br/> <a href="http://www.usv.com/jobs/">Jobs in the Union Square Ventures Portfolio</a><br/> <a href="http://jobs.mashable.com/a/jbb/find-jobs">Mashable Job Board</a><br/> <a href="https://weworkremotely.com/">37signals Job Board</a><br/> <a href="http://www.crunchboard.com/jobs/">TechCrunch's CrunchBoard Job Board</a><br/>

Updates: <a href="http://www.linkedin.com/jobs">LinkedIn Jobs</a><br/> <a href="http://www.indeed.com/">Indeed.com</a><br/> <a href="http://mandy.com/">Mandy - Film and TV Jobs</a><br/>

If you have any other ideas of where to look let me know and I'll update the list. Good luck!

CSS3 Rounded Corners On IE

Thu, 10 Mar 2011 12:53:44 GMT

One of the coolest new additions to the CSS3 specification is its built-in ability to render rounded corners. Before CSS3 the only semi-humane way to create rounded corners on an element was to create four rounded corner images and use some unwieldy albeit effective <code>display:absolute</code> positioning to get the desired effect. This resulted in bloated code that contained numerous extra <code><div></code> tags such as: <code><div class="topLeftCorner"></div></code> to create the effect, and ultimately bogged down the rendering of the page.

This onerous task has been thankfully and mercifully banished to the days of yore thanks to CSS3's <code>border-radius</code>. To create a rounded-border with CSS3 it is as simple as typing:

<code> .rounder_corners { -moz-border-radius: 12px; -webkit-border-radius: 12px; border-radius: 12px; } </code>

Now this is all well and good however the bane of every accomplished web developer is cross-platform compatibility - namely Internet Explorer. Unfortunately for all who code for the web most of the world still uses IE7 and IE8 as their web browser of choice. What's so horrible about this? IE6-8 does not suport CSS3's <code>border-radius</code> property, thus insuring that any IE6-8 user will not see your beautifully rounded corners. I'm choking up just thinking about the ugly pain. :(

So what's a web developer to do? Today I stumbled across (through <a href="http://html5boilerplate.com">html5boilerplate.com</a>) the most excellent and amazing <a href="http://css3pie.com/">CSS3 PIE</a> resource. PIE stands for Progressive Internet Explorer and the long and short of its awesomeness is that when it is included on your web page it equips every user running IE6-8 with the ability to render and display all the glorious benefits of CSS3 - including its <code>border-radius</code> property! Ugliness undone!

Top 10 Albums Of 2010

Tue, 28 Dec 2010 13:10:32 GMT

<img src="/images/posts/2010/top-10-albums-300x207.png" alt="" title="top 10 albums" width="300" height="207" class="alignright size-medium wp-image-1103" />What a year for music. Seriously, this year has been just a whopper for music, something that I could not have even <em>tried</em> to predict. When 2010 was just peaking it’s head around the corner I was honestly a little bummed. I looked at the music that had come out in 2009 and was glum, believing it would be impossible for 2010 to come in any way close to the music of 2009.

Boy, was I wrong.

Actually let’s take that ‘boy’ exclamation up a notch.

Man, was I wrong. And in so many ways that I still don’t understand...

So I’ve looked at all the music I’ve listened to in 2010 and have humbly selected my Top 10 Albums along with the Stand Out Track from that album.

You probably won’t agree with any of my choices past my number 1 pick, but that’s okay. I’m the one doing the writing and you’re the one doing the reading. Unless you add a comment refuting my opinion. But you wouldn’t do that, would you?

Read on for my Top 10 Albums of 2010!

P.S: If you click on any of the album links and buy the record I get a little affiliate money from Amazon. Proper warning and hoping for help! Thanks!

<h2> Top 10 Albums of 2010</h2>

Kanye West - <a href="http://www.amazon.com/dp/B003X2O6KW/?tag=harwol-20">My Beautiful Dark And Twisted Fantasy</a> Stand Out Track: Lost In The World Creating a good bit of distance between himself and all other artists of 2010, Kanye West’s My Beautiful Dark Twisted Fantasy has found itself sitting securely as my number one album of the year. I’m far from original in that decision, with many other bloggers and critics deciding the same, however you cannot beat the absolute genius of this record. Say what you want about Kanye West the celebrity - when it comes to music he is irreproachable.
Sleigh Bells - <a href="http://www.amazon.com/dp/B003KT3NS4/?tag=harwol-20">Treats</a> Stand Out Track: Rill Rill I’ve listened to ‘noise music’ before. I’ve liked some of what I’ve heard, however I usually don’t. Sleigh Bells’ debut album Treats not only takes ‘noise music’ to a whole new level, it does so while remaining incredibly catchy and melodic. Put this record on and listen to it. You’ll be surprised to notice how catchy ‘noise’ can be. And then after you’re done with your first listen, put the record on again. And dance. And now you won’t have to go to the gym that day. Or dance while at the gym. Two workouts in one. Excuse me, I need to go to my gym. And dance. Workout +2
Menomena - <a href="http://www.amazon.com/dp/B003P5AJCG/?tag=harwol-20">Mines</a> Stand Out Track: Dirty Cartoons This choice is heavily swayed. Menomena has long been a favorite band of mine, and with their fourth record Mines they continue to rock as hard as they did on their first record. The most important thing to know about Menomena - the band - is how incredibly deft they are at creating songs seeped in melancholy - an emotion that is quite difficult to create. Whether you need some music to accompany a lonely rainy day, or a song to help transition from dusk to night, Menomena is your band.
Foals - <a href="http://www.amazon.com/dp/B003H8WSLQ/?tag=harwol-20">Total Life Forever</a> Stand Out Track: Total Life Forever I almost missed this album. It slipped entirely underneath my radar, with my first listen of this record happening a good two months after it was released. Before hearing Foals’ Total Life Forever I knew nothing about the band - and frankly still don’t. I do remember seeing the video for their first single, Spanish Sahara and finding their use of a drum pad to be quite cool. This record is even more moody than Menomena’s but in a very different way. This record is great for early dawns and black midnights. It’s a record that paints silence. Some tracks take a few minutes to really pick up speed, but once they do you remain hooked.

LCD Soundsystem - <a href="http://www.amazon.com/dp/B003BEE0F8/?tag=harwol-20">This Is Happening</a> Stand Out Track: All I Want I feel as though, at this point, everyone knows who LCD Soundsystem is. In case you don’t (how do you not!?) LCD Soundystem is a band fronted by the highly talented producer James Murphy that creates incredibly upbeat and catchy dance songs. I was fortunate to see these guys live three years ago, and incredibly lucky to see them live again this year for their new record, This Is Happening. This record is assuredly their best so far, with their live show exceeding the excitement and fun already found on the album. (On an aside, I ran into Aziz Ansari at this show. That was weird - but exciting!)
Hoodie Allen - <a href="http://www.timeforthepeprally.com/">Pep Rally</a> Stand Out Track: January Jones Not truly an album, this debut mixtape from current unknown Hoodie Allen contains catchy rhymes and hooks, focusing on subject matters near and dear to this suburban kid’s heart. This is a rap record, but it’s rap that I would easily call ‘pop rap’ in the sense that it’s light-hearted and cheerful but not the radio friendly garbage that generally hurts my sensibilities. The entire mixtape is available as a free download, just click on the album name and get your free download on!
Ray LaMontagne - <a href="http://www.amazon.com/dp/B003QCCS36/?tag=harwol-20">God Willin' and the Creek Don't Rise</a> Stand Out Track: God Willin' and the Creek Don't Rise Adult contemporary? On my list!? Yes please ma’am sir! To be fair I would peg Ray LaMontagne as more of a folk artist and that is the exact reason his record is sitting so pretty at number seven. I’m a sucker for soft voices and acoustic guitar and this record gives me plenty of both, along with excellent production.
Cee Lo Green - <a href="http://www.amazon.com/dp/B0041WLBEC/?tag=harwol-20">The Lady Killer</a> Stand Out Track: Please I feel bad for Cee Lo Green. His album, The Lady Killer is a tremendous record however it is being continuously overshadowed by all the other great albums of 2010. If it wasn’t for his breakout song ‘Fuck You’ I doubt anyone would know Cee Lo Green had released a new album. The rest of his album is as solid as ‘Fuck You’ - however not as radio friendly. Still the record pleases with its soulful sounds and it won’t disappoint. In fact, it’ll definitely please.
Joe Purdy - <a href="http://www.amazon.com/dp/B003U06B50/?tag=harwol-20">4th of July</a> Stand Out Track: On The Wind I don’t remember how I stumbled upon this artist but I am very glad that I did. This is another folk album that was on constant replay for a solid week. More soft voices and acoustic guitars, with melodies and tunes that work so well in their simplicity. You probably won’t like this guy, and that’s okay. For me, I couldn’t get enough of him.
Spoon - <a href="http://www.amazon.com/dp/B002VDZIIS/?tag=harwol-20">Transference</a> Stand Out Track: I Saw The Light Just rounding out the top 10 is Spoon’s latest record Transference. Each album Spoon creates has their distinctive sound, while remaining highly unique. This album continues that trend, further stripping away some of the gloss of their earlier records, leaving an album that is so raw and bare you may wonder if they took any time to practice before recording. I once saw someone describe this album as a ‘5 o’clock shadow rock’ and I haven’t been able to find any better description.

Aside from these 10 stellar albums there have been a whole slew of albums released in 2010 that deserve at least some mention of their existence. You know what this calls for don’t you?

<h2>Honorable Mentions</h2>

J. Cole - Friday Night Lights The Tallest Man on Earth - The Wild Hunt Two Door Cinema Club - Tourist History Vampire Weekend - Contra The Walkmen - Lisben A Weather - Everyday Balloons Yeasayer - Odd Blood Gorillaz - Plastic Beach Arcade Fire - The Suburbs Atmosphere - To All My Friends EP The Black Keys - Brothers Caribou - Swim

So there you have it: the Top 10 Albums of 2010. This top 10 list really puts the 10 in 2010. Pschaw!

And now onto 2011! What we might see I can only dream! Let’s get going!!

Harry Wolff

Things I Don’t Like about Vue.js (as a React engineer)

Table of contents

Video

Wrap-up

What Vue.js Does Better Than React

Table of contents

Different Philosophies

Officially Supported Related Libraries

Video

Closing Thoughts

My Tech Stack (2020 Edition)

Table of contents

Frontend

Server side rendering

Static page generation

Server API endpoints

Backend

Testing

Hosting

Start Coding!

2019 In Review

2019 Most Watched Videos

Other 2019 Milestones

The Future

Pro VSCode Tricks

Navigation Shortcuts

Toggle Side Bar Visibility: Command ⌘ + B

Toggle Bottom Panel: Command ⌘ + J

Open Terminal: Control ⌃ + `

Open Explorer: Command ⌘ + Shift ⇧ + E

Open Search: Command ⌘ + Shift ⇧ + F

Project Manager

Selection Pro Moves

Select Multiple Words: Command ⌘ + D

Jump over words: Option ⌥

Move Line Up or Down: Option ⌥ + Up/Down

Multiline Selection: Option ⌥ + Shift ⇧ + L

Fast Line Removal: Command ⌘ + X

Built in VCS editor

Command Palette: Command ⌘ + Shift ⇧ + P

Easy prototyping

Pro: GitHub Pull Requests Extension

Get Practicing!

Why Is React Concurrent Mode Exciting?

The Problem Is Being In Sync

How is this even possible?

What else can I do with Concurrent Mode?

Do you need Concurrent Mode?

Random Questions You May Have

Wrap Up

Video

React Alicante 2019

Guest on FreeCodeCamp Podcast

How To useContext With useReducer

Why do I need Context?

How Context Helps

How to Create a Context

How to Consume Context with Hooks

Performance Concerns

Why Context Works Great With useReducer

Conclusion

Level Up useReducer with Immer

Video

Source Code

Immer

What's it look like?

Function

Curried

Use Immer with useReducer

Curried useReducer Reducer Function

Did you level up?

Why I Love useReducer

Why do I love useReducer?

Using useState

Using useReducer

Think like the user

What is React Ink?

What is React Ink?

What does React Ink look like?