HipsterBrown's Training Data

Generating Open Graph Images in 11ty

Wed, 01 Apr 2026 02:06:00 GMT

When I working on redesigning my website, one of the big features I wanted to add was Open Graph (OG) images. These always seemed like such a flex to see from personal blogs and really made those links stand out in every social site that supported them.

I had a few main criteria to cover when adding support for this feature:

images should be generated automatically for each content collection
the process should be integrated into the 11ty build system I use for my site
it should be efficient enough to run anywhere, i.e. my laptop or GitHub Actions
the images should match the theme of my site, including fonts

I knew very little about how OG images are implemented outside of some special meta tags that go into the head of the HTML. Thankfully those tags have become fairly standardized over the years.

<meta property="og:title" content="Generating Open Graph Images in 11ty" />
<meta property="og:url" content="https://hipsterbrown.com/training-data/generating-open-graph-images-in-11ty/" />
<meta property="og:image" content="https://hipsterbrown.com/og/generating-open-graph-images-in-11ty.png" />
<meta property="og:type" content="article" />
<meta property="og:description" content="Integrate automatic OG image generation into your 11ty site" />

Each of those tags needs to be included in the head of each page that wants the social glow up treatment. So I created the following template partial to contain the small amount of logic required to use the correct content for the relevant tags:

<!-- Open Graph Meta Tags -->
{%- if type -%}
  {%- assign ogImageUrl = '/og/' | append: page.fileSlug | append: '.png' -%}
{%- elsif contentType == "project" -%}
  {%- assign ogImageUrl = '/og/projects/' | append: page.fileSlug | append: '.png' -%}
{%- else -%}
  {%- assign ogImageUrl = '/og/' | append: ogImage | default: 'default.png' | append: '' -%}
{%- endif -%}

<meta property="og:title" content="{{ title | escape }}">
<meta property="og:description" content="{{ description | escape }}">
<meta property="og:type" content="article">
<meta property="og:url" content="{{ canonicalUrl }}">
<meta property="og:image" content="https://hipsterbrown.com{{ ogImageUrl }}">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:alt" content="{{ title | escape }}">

Along with the main meta tags, I’ve also included extra metadata about the image to help with displaying them on each site.

To actually generate the images for the landing pages (home, training data index, project index, etc) and each page in a content collection, I created a Node.js script that used the satori package to generate an SVG “card” design from an HTML & CSS template and render it to a PNG using Resvg. Satori allows me to use flex box layout, embedded custom fonts, and my site’s theme colors in the generated design without having to spin up a headless browser, like folks have done for this feature in the past. I opted out of using the JSX syntax for relative simplicity and efficiency when running the script, so the template can be a bit confusing to follow at first:

function buildCard({ title, type, date, description }) {
  const accent = COLOR.accent[type] ?? COLOR.ink
  const label = LABEL[type] ?? type ?? ''
  const dateStr = date
    ? new Date(date).toLocaleDateString('en-US', {
      year: 'numeric', month: 'long', day: 'numeric',
    })
    : ''
  const titleSize = title.length > 70 ? 48 : title.length > 50 ? 56 : 72
  // Limit description to 150 characters and 2 lines
  const truncatedDesc = description
    ? description.substring(0, 150) + (description.length > 150 ? '...' : '')
    : ''

  return {
    type: 'div',
    props: {
      style: {
        width: 1200,
        height: 630,
        background: COLOR.bg,
        display: 'flex',
        flexDirection: 'column',
        justifyContent: 'space-between',
        padding: '0px',
        fontFamily: 'Epilogue',
        boxSizing: 'border-box',
      },
      children: [
        // Top accent bar
        {
          type: 'div',
          props: {
            style: { width: '100%', height: 8, background: accent },
            children: '',
          },
        },
        // Main content
        {
          type: 'div',
          props: {
            style: {
              display: 'flex',
              flexDirection: 'column',
              justifyContent: 'space-between',
              flex: 1,
              padding: '56px 80px 64px',
            },
            children: [
              // Type label
              {
                type: 'div',
                props: {
                  style: {
                    fontFamily: 'Syne',
                    fontSize: 20,
                    fontWeight: 800,
                    color: accent,
                    letterSpacing: '0.12em',
                    textTransform: 'uppercase',
                  },
                  children: label,
                },
              },
              {
                type: 'div',
                props: {
                  style: {
                    display: 'flex',
                    flexDirection: 'column'
                  },
                  children: [
                    {
                      type: 'div',
                      props: {
                        style: {
                          fontSize: titleSize,
                          fontFamily: 'InstrumentSerif',
                          color: COLOR.ink,
                          lineHeight: 1.15,
                          maxWidth: 960,
                        },
                        children: title,
                      },
                    },
                    // Description (optional)
                    ...(truncatedDesc ? [{
                      type: 'div',
                      props: {
                        style: {
                          fontSize: 24,
                          fontWeight: 400,
                          color: COLOR.text2,
                          lineHeight: 1.4,
                          maxWidth: 960,
                          marginTop: 4,
                          display: 'flex',
                          WebkitLineClamp: 2,
                          WebkitBoxOrient: 'vertical',
                          overflow: 'hidden',
                        },
                        children: truncatedDesc,
                      },
                    }] : []),
                  ]
                }
              },
              // Title
              // Footer row
              {
                type: 'div',
                props: {
                  style: {
                    display: 'flex',
                    justifyContent: 'space-between',
                    alignItems: 'flex-end',
                  },
                  children: [
                    {
                      type: 'div',
                      props: {
                        style: {
                          fontFamily: 'Syne',
                          fontSize: 28,
                          fontWeight: 800,
                          color: COLOR.ink,
                        },
                        children: 'HipsterBrown',
                      },
                    },
                    {
                      type: 'div',
                      props: {
                        style: { fontSize: 18, color: COLOR.text3 },
                        children: dateStr,
                      },
                    },
                  ],
                },
              },
            ],
          },
        },
      ],
    },
  }
}

Looks reminiscent of the early days of React before everyone used JSX by default. 😆

That function is called with data for each content type or static page:

async function generateForPost({ slug, title, type, date, description }) {
  const outputPath = join('_site', 'og', `${slug}.png`)
  mkdirSync(dirname(outputPath), { recursive: true })
  const png = await renderPng(buildCard({ title, type, date, description }))
  writeFileSync(outputPath, png)
  return outputPath
}
async function generateStatic(outputPath, { title, type, date, description }) {
  mkdirSync(dirname(outputPath), { recursive: true })
  const png = await renderPng(buildCard({ title, type, date, description }))
  writeFileSync(outputPath, png)
  return outputPath
}

The script gathers all the posts, along with their front-matter data using gray-matter, then iterates over each one to generate it’s associated image into the site build directory.

const fileNames = readdirSync('training-data').filter(f => f.endsWith('.md'))
    const files = fileNames.map(f => join('training-data', f))
    const posts = files.flatMap((file) => {
      const { data } = matter(readFileSync(file, 'utf8'))
      if (data.draft) return []
      const slug = file.replace('training-data/', '').replace('.md', '')
      return [{ slug, ...data }]
    })

Full OG generation script source

Integration into 11ty comes in the eleventy.after lifecycle hook; once all the pages are generated.

config.on('eleventy.after', async () => {
    const { spawn } = require('child_process');
    return new Promise((resolve, reject) => {
      const proc = spawn('node', ['scripts/generate-og-images.mjs']);
      proc.on('close', (code) => {
        if (code === 0) resolve();
        else reject(new Error(`OG generation failed with code ${code}`));
      });
    });
  });

Generating the pages and images for my site takes about 6 seconds in CI, so I’m currently keeping the images for content collections out of git. This removes the concern of keeping track of which images have been generated already or regenerating them all manually if I decide to update the design.

Overall, I’m happy with how quick and easy this works once it was all in place. I’m looking forward to playing around with the design a bit more in the future, but it’s in a good enough place for now.

If you’ve added this feature to your site in some other way, reach out and let me know how you did it.

Happy Building!

Laundry Alerts with Home Assistant

Thu, 19 Mar 2026 03:16:00 GMT

Yet another project I put off due to a compulsion to build it all from scratch; my personal case of not invented here syndrome.

TL;DR Skip to the bottom for my Home Assistant automation setup to get notifications when the laundry is done.

The Problem

In my home, my laundry machines live in the basement. This is great for keeping the noise, heat, and general mess of gathering dirty clothes away from the rest of the house. However, it's bad for my penchant to forget when it's "out of sight, out of mind." This leads to soggy or wrinkled clothes that should have been put away sooner and frustration with myself. I've tried setting timers for myself, based on the expected completion time for the load; however, the machines estimate about as well as software engineers (wrong just enough to be annoying over time). Also, timers are easy to dismiss and forget in the moments after. I really needed something to notify me when either machine was done with its current load. It would be even better if it could notify anyone at home about this as well.

Early Attempts

As a programmer, self-proclaimed "maker", and generally frugal person, I tend to want to build a solution myself when it seems possible and none of the off-the-shelf solutions fit within my values of ownership and privacy. My initial plan was to set up a movement or vibration sensor wired up to a microcontroller placed on the machines somewhere to track the laundry activity. Then I fell into a rabbit hole of improving the developer tooling around the project rather than implementing the project itself (classic). I also wasn't sure where to report the data or how to notify myself based on the data. I eventually moved on to more pressing needs within my home.

Then, after starting my role as Viam, I got the opportunity to try solving this annoyance as a proof-of-concept for work. This time it would involve a sensor wired up to a Raspberry Pi that captured data to Viam and allowed me to quickly visualize it in a dashboard. Having solved that part of the problem so easily, I decided to shift the goal posts to include using machine learning for recognizing loads and detect anomalies in the behavior of the washer & dryer. This was far beyond my current experience with ML, so the interest lapsed and the problem went unsolved yet again.

Catalyst

These days, I have two young kids and no real time to tinker extensively with hand-crafted solutions for problems that people have already solved and documented. It was during my parental leave that I finally committed to just getting the damn thing done. While I was going through the long-pending maintenance of my Home Assistant setup, I realized that this was the perfect scenario for the open source home automation community.

After doing some research and planning with Claude, I settled on the initial approach: a power-monitoring smart plug for the washer and a wireless vibration sensor for the dryer. Since my dryer is fully electric, there was no viable smart plug that could support the high-voltage connection. As for connectivity, the smart plug (made by Shelly) supported Matter and the vibration sensor used Zigbee. I prefer Matter for most of my smart home devices these days for the sake of ecosystem portability and offline availability, but the same USB adapter connected to my Home Assistant Green provides Zigbee along with Thread and Matter due to shared radio frequency for the protocols.

As part of my research and a big influence into choosing a smart plug for monitoring the washer, I also learned about a Home Assistant community integration called WashData. This plugin abstracted over the power monitoring data from the smart plug to display it as a device (or entity) within Home Assistant, including activity states (starting, running, completing, idle), progress, and detected load type. It enabled this metadata through a learned heuristic by manually capturing a few "episodes" of data for each load type you expect to run. This sort of setup also makes it conducive to supporting other appliances with varying power draw like dryers, diswashers, air fryers, and heat pumps.

Implementation

You've made it through the backstory to the actual recipe you came for: the automations.

My original goal was to get a notification when my washer or dryer completed a load, with the stretch goal of being able to inform anyone at home about that status. I'm happy to say I accomplished both fairly well.

Because I have the Home Assistant companion app on my phone, I could easily add an action to send a push notification through the app when the laundry was done. This has a beneficial side-effect from "Apple Intelligence" highlighting this notification as high priority, which makes it hard to ignore.

In order to inform the rest of the house, I used the local text-to-speech integration to make an announcement through the HomePod Mini in the kitchen! I'm thoroughly impressed by the performance and availability of such a feature native to Home Assistant.

Here is the washer notification config:

alias: Washer Done Notification
description: ""
triggers:
  - type: turned_off
    device_id: 35386f2b898ea435eb3020651caacbce
    entity_id: 44016cbcbca307fc01bbe4b158912d56
    domain: binary_sensor
    trigger: device
    for:
      hours: 0
      minutes: 2
      seconds: 0
conditions: []
actions:
  - action: notify.persistent_notification
    metadata: {}
    data:
      message: Laundry is ready to be changed to the dryer!
      title: Laundry Done
  - action: notify.mobile_app_kitchen_hub
    metadata: {}
    data:
      message: Washer is ready to be changed over!
      title: Laundry Ready
  - action: notify.mobile_app_nick_s_phone_pro
    metadata: {}
    data:
      message: Laundry is ready
      title: Change over laundry
  - sequence:
      - action: media_player.volume_set
        metadata: {}
        target:
          entity_id: media_player.kitchen
        data:
          volume_level: 0.7
      - action: tts.speak
        metadata: {}
        target:
          entity_id: tts.piper
        data:
          cache: true
          media_player_entity_id: media_player.kitchen
          message: Washer laundry is done
      - action: media_player.volume_set
        metadata: {}
        target:
          entity_id: media_player.kitchen
        data:
          volume_level: 0.3
mode: single

Keen-eyed readers may have noticed the "Kitchen Hub" device being notified as well. That's a separate project that I'll be writing about soon.

Here are the two automation configs to track the dryer state based on the vibration sensor and notify me when it is complete:

alias: Start Dryer Cycle
description: ""
triggers:
  - type: motion
    device_id: 7e1ee4370e56ac4372e3024b45974639
    entity_id: 21d145753fe00339f165648f7461a928
    domain: binary_sensor
    trigger: device
    for:
      hours: 0
      minutes: 5
      seconds: 0
conditions: []
actions:
  - action: input_boolean.turn_on
    metadata: {}
    target:
      entity_id: input_boolean.dryer_running
    data: {}
mode: single

alias: Dryer Load Complete
description: ""
triggers:
  - type: no_motion
    device_id: 7e1ee4370e56ac4372e3024b45974639
    entity_id: 21d145753fe00339f165648f7461a928
    domain: binary_sensor
    trigger: device
    for:
      hours: 0
      minutes: 2
      seconds: 0
conditions:
  - condition: state
    entity_id: input_boolean.dryer_running
    state:
      - "on"
actions:
  - action: input_boolean.turn_off
    metadata: {}
    target:
      entity_id: input_boolean.dryer_running
    data: {}
  - action: notify.persistent_notification
    metadata: {}
    data:
      message: Time to take out the laundry from the dryer.
      title: Dryer Complete
  - action: notify.mobile_app_nick_s_phone_pro
    metadata: {}
    data:
      message: Time to get the laundry from the dryer
      title: Dryer Done!
  - action: notify.mobile_app_kitchen_hub
    metadata: {}
    data:
      message: Dryer is done!
  - sequence:
      - action: media_player.volume_set
        metadata: {}
        target:
          entity_id: media_player.kitchen
        data:
          volume_level: 0.7
      - action: tts.speak
        metadata: {}
        target:
          entity_id: tts.piper
        data:
          cache: true
          media_player_entity_id: media_player.kitchen
          message: Dryer laundry is done
      - action: media_player.volume_set
        metadata: {}
        target:
          entity_id: media_player.kitchen
        data:
          volume_level: 0.3
mode: single

Wrap It Up

Overall, I'm glad I finally got this project done using whatever means necessary. I'm finding it genuinely useful, and my family is delighted by the laundry announcements that occasionally ring from the kitchen. It's taught me to embrace the quirks with home automation and let me explore more interesting ways to use Home Assistant. I'd still like to build the complete DIY approach someday, but it's nice knowing I have working solution in the meantime.

The Alloy SDK for Pebble

Sun, 15 Mar 2026 18:08:00 GMT

Moddable is thrilled to be collaborating with Pebble to reimagine the watch developer experience using standard JavaScript.

It feels like my journey with JavaScript hardware is coming full circle. The OG Pebble was my first foray into developing applications for a platform other than the web, which I had only been doing for a year or two at that time anyway. From building watch faces in C with some JS integration code in the mobile app to full JS-driven experiences and early on-device JS runtime support really shaped my perspective on great developer experiences and what’s possible with hardware. It led to some of my first public speaking opportunities at local meetups in Orlando and New York; eventually leading to meeting the Tessel team at an open source collaboration event, where I saw a whole new entrypoint into JS-powered hardware.

From Tessel to participating in TC53, where I got to know the folks from Moddable. After Tessel dissolved, I found myself wanting a similar developer experience for the Moddable SDK and associated tooling: plug an MCU in, run a couple CLI commands, and start pushing code to the device. This led to building xs-dev and pushing the boundaries of my favorite language on devices yet again.

I told Peter Hoddie when I saw the Moddable Four (in 2023) that it reminded me so much of the experience when using the first e-paper Pebble. It's incredible to see that dream become a reality.

All sensors are available through ECMA-419 Sensor APIs. The high-level network APIs use web standards; the low-level networking APIs use ECMA-419 standards.

This is especially exciting, after years of standards work, to see such a beloved devices adopting these APIs. The peak era of Nodebots has come and gone, but there's potential for a revival with a new generation of developers being exposed to using familiar JavaScript patterns running on their wrists.

Productivity Theater

Thu, 12 Mar 2026 02:44:00 GMT

Every few years, I find myself in the same loop. A new tool appears, promising to finally make me efficient. I descend into the rabbit hole: tweaking, optimizing, configuring; emerging some time later with a system that’s marginally better than what I had before and a stack of browser tabs I’ll never close. I went through it with my Neovim config, then with Obsidian and the promise of a perfect personal knowledge graph, then with home automation and my self-hosted homelab. Each time, the pull felt different. Each time, the pattern was identical.

The latest act is agentic coding tools, and I can see myself peering down at the edge of the rabbit hole yet again.

I held out on AI coding tools for a while. This was partially due to the lack of good Neovim integrations, in addition to the poor results I was seeing from other devs’ use of them. Then the models got better, and by the time Claude Code picked up steam, I was already using the chat app to generate snippets, copy them into my program, and returning to the app to paste in the error of what didn’t work. The CLI kept me in the terminal and had the codebase as context; it felt like a natural next step. But, of course, it can’t stop there.

The hype machine churns on. Now there are conductors, skills, sub-agents, spec frameworks, Ralph loops, and a whole philosophy industry springing up around how to best direct your headless workforce. It has the same energy as the peak frontend fatigue years. The pace is frantic mixed with an anxiety that you’re not using your token limit to its peak efficiency every second of the day. It follows us away from the keyboard; urging us to check in on our phones and fire off a couple more remote prompts on the go.

What I’m trying not to do is confuse movement for progress. I’m not going to put my head in the sand and wait until the dust settles because it just won’t. So I’ve settled into a workflow that works for me. It’s not glamorous, but it feels good enough. I don’t need an always-on agent opening PRs while I sleep. I don’t need a leaderboard gamifying my token usage. I’m okay playing the role of the senior engineer who stays in the loop to bring taste and judgment to the process, rather than reacting to semi-autonomous outputs after the fact.

I’ll still read what’s new. I’ll still tinker when something genuinely looks interesting and try to remember to write about it here. This is also where I ended up with my previous interests. I still enjoy using Neovim, collecting thoughts in Obsidian, adding sensors to my home, and deploying services to my homelab. It’s now that I recognize the toil on the way to find peace in these areas; toil I’d like to avoid for this next new and shiny thing.

In the meantime, I’ll sit back in my seat and observe the productivity theater for the show that it is.

Motivated to publish again

Tue, 10 Mar 2026 01:59:00 GMT

Feels good to want to write and publish again. Parental leave is definitely not a vacation, but it’s provided some space to think away from work to explore some ideas aided by my convenient pair programmer just a quick claude away.

In the past, I was hindered by the dated look of the site and my publishing workflow requiring being at my laptop. Now I feel as refreshed as the updated design and have figured out ways to reduce the friction to go from thought to draft to live from whatever device I have handy.

I’m looking forward to sharing more and often; from quick notes like this to daily learning and links to long form essays of sorts. I hope you enjoy this “training data” as much as the bots. 🤖

Helpers in Home Assistant

Tue, 10 Mar 2026 00:17:00 GMT

TIL about helpers in Home Assistant. I had heard about them briefly before to support pre-configured timers that could be placed on dashboards. But I didn’t know the extent of their use.

I ended up using one to create a “Dropdown” to hold state for cycling a pattern of lights for my bathroom vanity based on the press of a Zigbee remote button. It seems like helpers are bits of state you can define in your Home Assistant system to use for all sorts of triggers, actions, scripts, etc. I enjoyed building up this automation because it could all by done using the UI editor, even though I was given a head start with a YAML config from Claude. It felt trivial to accomplish it all from just my phone.

The script I ended up with:

alias: Cycle Bathroom Lights
description: Cycle the bathroom lights patterns
triggers:
  - device_id: 61c9e2xxxxxxxxxxxxxxxxx
    domain: zha
    type: remote_button_short_press
    subtype: right
    trigger: device
conditions: []
actions:
  - action: script.turn_off
    metadata: {}
    target:
      entity_id: script.party_mode_loop
    data: {}
  - data:
      cycle: true
    target:
      entity_id: input_select.bathroom_light_pattern
    action: input_select.select_next
  - choose:
      - conditions:
          - condition: state
            entity_id: input_select.bathroom_light_pattern
            state: yellow
        sequence:
          - data:
              rgb_color:
                - 255
                - 190
                - 0
              transition: 0.5
            action: light.turn_on
            target:
              area_id: bathroom
      - conditions:
          - condition: state
            entity_id: input_select.bathroom_light_pattern
            state: white
        sequence:
          - data:
              transition: 0.5
              rgb_color:
                - 255
                - 255
                - 255
              brightness_pct: 50
            action: light.turn_on
            target:
              area_id: bathroom
      - conditions:
          - condition: state
            entity_id: input_select.bathroom_light_pattern
            state: rainbow
        sequence:
          - data:
              rgb_color:
                - 255
                - 0
                - 0
              transition: 0.5
            action: light.turn_on
            target:
              entity_id: light.first_vanity_light_light
          - data:
              rgb_color:
                - 255
                - 100
                - 0
              transition: 0.5
            action: light.turn_on
            target:
              entity_id: light.second_vanity_light_light
          - data:
              rgb_color:
                - 255
                - 220
                - 0
              transition: 0.5
            action: light.turn_on
            target:
              entity_id: light.third_vanity_light_light
          - data:
              rgb_color:
                - 0
                - 200
                - 0
              transition: 0.5
            action: light.turn_on
            target:
              entity_id: light.fourth_vanity_light_light
          - data:
              rgb_color:
                - 0
                - 80
                - 255
              transition: 0.5
            action: light.turn_on
            target:
              entity_id: light.fifth_vanity_light_light_2
      - conditions:
          - condition: state
            entity_id: input_select.bathroom_light_pattern
            state: blue
        sequence:
          - data:
              rgb_color:
                - 0
                - 80
                - 255
              transition: 0.5
            action: light.turn_on
            target:
              area_id: bathroom
      - conditions:
          - condition: state
            entity_id: input_select.bathroom_light_pattern
            state:
              - party
        sequence:
          - action: script.turn_on
            metadata: {}
            target:
              entity_id: script.party_mode_loop
            data: {}
mode: single

Bonus Party Mode light cycling:

alias: Party Mode Loop
mode: restart
sequence:
  - repeat:
      while:
        - condition: state
          entity_id: input_select.bathroom_light_pattern
          state: party
      sequence:
        - parallel:
            - data:
                hs_color:
                  - "{{ (repeat.index * 30) % 360 }}"
                  - 100
                transition: 1.5
              action: light.turn_on
              target:
                entity_id: light.first_vanity_light_light
            - data:
                hs_color:
                  - "{{ (repeat.index * 30 + 72) % 360 }}"
                  - 100
                transition: 1.5
              action: light.turn_on
              target:
                entity_id: light.second_vanity_light_light
            - data:
                hs_color:
                  - "{{ (repeat.index * 30 + 144) % 360 }}"
                  - 100
                transition: 1.5
              action: light.turn_on
              target:
                entity_id: light.third_vanity_light_light
            - data:
                hs_color:
                  - "{{ (repeat.index * 30 + 216) % 360 }}"
                  - 100
                transition: 1.5
              action: light.turn_on
              target:
                entity_id: light.fourth_vanity_light_light
            - data:
                hs_color:
                  - "{{ (repeat.index * 30 + 288) % 360 }}"
                  - 100
                transition: 1.5
              action: light.turn_on
              target:
                entity_id: light.fifth_vanity_light_light_2
        - delay:
            hours: 0
            minutes: 0
            seconds: 0
            milliseconds: 250
description: Rainbow wave effect through lights
icon: mdi:party-popper

Islands on the Rails

Fri, 14 Oct 2022 00:00:00 GMT

Given the renewed conversation around "Islands Architecture", related to the JS community's interest in frameworks like Astro & iles as well as libraries like Eleventy's <is-land> element, I thought I would reflect on how I've been working in a Ruby on Rails application that's been using this architecture since 2018; followed by how I think it can continue to evolve.

Background

I learned about "Islands Architecture" after joining Betterment in 2019, where the implementation had been in production for at least 6 months as explorations into building richer, client-side experiences within the main Ruby on Rails app were starting to take hold. These "islands" were being built with React as the UI library of choice due to the mature tooling and community around it.

The goal of this work was to allow developers to embed components into their templates with minimal effort and provide a positive user experiences for Betterment customers. To support a positive developer experience while working on the React components, the code was isolated as an internal npm package within the same repo as the Rails application using Yarn v1 workspaces.

The package directory was bootstrapped with Create React App to reduce bike-shedding the related bundling, linting, and testing tooling for the project. The separate workspace also allowed for setting up Storybook for rapid visual feedback without running the entire Rails application. The Rails app could consume the internal package like any other from npm and be none-the-wiser to how it was built (for the most part). As this setup solidified, it was adopted by nearly every consumer-facing Rails app within the company.

Workflow

So how does it all work?

Well, the core library for bridging the two worlds is StimulusJS. Betterment had already been using Stimulus for adding "sprinkles" of client-side behavior to server-rendered features for a while, so it made sense to adopt it as the mechanism for declaring "islands" within the Rails templates. Stimulus controllers are JS classes that are registered with a single "Application" object that instantiates those classes when it sees a matching data-controller attribute in the DOM. The controllers have lifecycle methods for when it has been "connected", or bound to the element with the data-controller attribute, among others.

Through this functionality, a "ReactAppController" was created to mount a React component to the bound element whenever it was declared in a Rails template; the element would also have a data-react-app-name attribute to select the particular component for that island based on a map of registered components. Initial props could even be passed to the React component as a JSON string parsed by the controller before rendering the component.

// react-app-controller.tsx
import { Controller } from 'stimulus';
import React from 'react';
import { render } from 'react-dom';
import registry from '../registry';

export default class extends Controller {
  connect() {
    const App = this.app;

    if (App) {
      render(<App {...this.initialProps} />, this.element);
    } else {
      console.warn(`Could not resolve app with name: '${this.name}'`);
    }
  }

  get app() {
    return registry.getApp(this.name || '');
  }

  get name() {
    return this.data.get('name');
  }

  get initialProps() {
    return JSON.parse(this.data.get('initial-props') || '{}');
  }
}

We referred to these components as "apps" since "islands" was not as well-known at the time

The Rails view usage:

<div data-controller="react-app" data-react-app-name="thing" data-react-app-initial-props="<%= @initial_props %>"></div>

View full example project based on this commit

To abstract over the implementation details of data attributes and make it feel more native to the application, a Rails UI component was created. We had an internal gem for this purpose, but there is an open-source approximation that covers this need called ViewComponent.

class ReactAppComponent < ViewComponent::Base
  def initialize(name:, initial_props:)
    @name = name
    @initial_props = initial_props.to_json
  end
end

The associated template file for that component, which should look familiar:

<div data-controller="react-app" data-react-app-name="<%= @name %>" data-react-app-initial-props="<%= @initial_props %>"></div>

The Rails view usage:

<%= render ReactAppComponent.new(name: "thing", initial_props: @initial_props)  %>

View full example project based on this commit

With these pieces in place, teams could build new components, register them, and drop them into a Rails template without worrying about conflicting with another team's work.

In Practice

The ability to drop React components into Rails views stretched the definition of an "island" as teams used them in a variety of features, from interactive form elements for cropping images to complete page and routing takeovers. The system evolved slightly to handle the growing "registry" of components to ensure the size of the core JS bundle wasn't unmanageable by dynamically importing components and lazily-loading them within the Stimulus controller:

export default class extends Controller {
  connect() {
    const App = this.app;

    if (App) {
      render(
        <Suspense fallback="Loading...">
          <App {...this.initialProps} />
        </Suspense>,
        this.element
      );
    } else {
      console.warn(`Could not resolve app with name: '${this.name}'`);
    }
  }

  get app() {
    return registry.getApp(this.name || '');
  }

  get name() {
    return this.data.get('name');
  }

  get initialProps() {
    return JSON.parse(this.data.get('initial-props') || '{}');
  }
}

The fallback behavior could eventually be configured from the Rails template so customers didn't just see "Loading..." while they waited for an experience to appear.

View full example project based on this commit

Adding this lazy-loading behavior actually exposed a point of friction in the tooling setup; there wasn't a source of truth for sharing fixes or new functionality across the applications using the islands architecture, so each workspace had to be individually updated with this new behavior. The Stimulus controller relied on a reference to a local "registry" of components that was manually created for each workspace, which had to be registered with a central Stimulus Application. The code-splitting feature also relied on Webpacker to process the dynamic import statements within the internal package source code to "chunk" the bundle correctly, which was a deprecated feature of the gem before the entire gem was eventually deprecated with the release of Rails 7. So if any existing or new app wanted to use islands, there was a tedious scaffolding process to go through first; usually through copy-pasting files across codebases or directories and hoping it worked.

With the writing on the wall about the next generation of JS tooling and Rails asset management, it's time to consider how "Islands on Rails" could evolve to solve the shortcomings listed above while taking advantage of new patterns.

Looking Forward

To summarize the core concerns to be addressed:

portability of JS controller to mount React islands
manual setup and registration of islands in each workspace

Starting with the portability problem, the web has had a solution for many years that works across all modern browsers: custom elements! If the earlier description of how Stimulus controllers work sounded familiar, then you've probably built a custom element before. Custom elements don't need to contain styles or HTML; they can just be classes that encapsulate behavior and are associated with a unique tag in some HTML. Just like Stimulus controllers, they are registered with a central object known as the CustomElementRegistry that is provided by the DOM instead of the application itself.

class ReactIslandElement extends HTMLElement {
  connectedCallback() {
    const App = this.app;

    if (App) {
      render(
        <Suspense fallback="Loading...">
          <App {...this.initialProps} />
        </Suspense>,
        this
      );
    } else {
      console.warn(`Could not resolve app with name: '${this.name}'`);
    }
  }

  get app() {
    return registry.getApp(this.name || '');
  }

  get name() {
    return this.dataset.name;
  }

  get initialProps() {
    return JSON.parse(this.dataset.initialProps || '{}');
  }
}

customElements.define('react-island', ReactIslandElement)

Using Island here to lean into the concept a bit more

This should nearly identical to the Stimulus implementation because they share a lot of similar properties, like the lifecycle method for when the class is bound to the DOM; it just needed a few changes for getting data attributes and updating this.element to this since the class itself is a reference to the DOM element. No third-party dependencies required and using it in a Rails templates is even simpler:

<react-island data-name="thing" data-initial-props="<%= @initial_props %>"></react-island>

If you're working with a team that is familiar with Stimulus, there is a lightweight library that provides similar semantics through TypeScript decorators called @github/catalyst. It will also reduce some of the boilerplate for working with data attributes and defining the element:

import { controller, attr } from '@github/catalyst';

@controller
class ReactIslandElement extends HTMLElement {
  @attr name = '';
  @attr props = '{}';

  connectedCallback() {
    const App = this.app;

    if (App) {
      render(
        <Suspense fallback="Loading...">
          <App {...this.initialProps} />
        </Suspense>,
        this
      );
    } else {
      console.warn(`Could not resolve app with name: '${this.name}'`);
    }
  }

  get app() {
    return registry.getApp(this.name);
  }

  get initialProps() {
    return JSON.parse(this.props);
  }
}

Using the documented conventions of the catalyst project, the ReactIslandElement will automatically be defined as react-island through the @controller decorator. Catalyst also comes with a useful feature I haven't seen in the Stimulus ecosystem yet: lazily-defined controllers. Using the lazyDefine function and a dynamic import statement, we start to get an experience similar to the <is-land> element from 11ty where the loading can be delayed based on certain events:

import { lazyDefine} from '@github/catalyst';
lazyDefine('react-island', () => import('./src/elements/react-island'));

<react-island data-load-on="visible" data-name="thing" data-initial-props="<%= @initial_props %>"></react-island>

Now the code for the island won't be loaded until the element is visible on the page! For any Rails app using the ReactAppComponent ViewComponent, this is a single update to the component's template as an implementation detail.

Now that there is a native way of providing the "island" behavior to the applications, how can it be packaged up into a reusable module for each workspace so island component registries don't need to be manually created for the custom element to use?

Drawing inspiration from Stimulus once again, there are helper modules like @hotwired/stimulus-webpack-helpers and stimulus-vite-helpers that allow for dynamically loading and registering Stimulus controllers at build time by using specific syntax for "globbing" files within a project. Looking at the Vite implementation more specifically, which extends the modern ESM import syntax, we could provide a module that takes in a "glob" of React island components to lazily import and provide as a registry to the ReactIslandElement:

// registry.ts
// fake package name used as an example
import { generateIslandRegistry } from 'react-islands'

const islands = import.meta.glob(['/**/islands/*.tsx', '/**/islands/*.jsx']);

const { getIsland } = generateIslandRegistry(islands)
// verbosity used for clarity
export { getIsland };

Renaming getApp to getIsland in this new implementation for the sake of consistency and clarity.

This module defines a convention of collecting all components within an "islands" directory in the workspace, similar to Fresh from Deno. With this in place, any new islands added to the matching directory would be automatically registered and available to embed in the Rails app; however, this all still feels like boilerplate for each new workspace to scaffold. If we're already using a build tool to enable this feature, why not generate this boilerplate at build time?

The list of community plugins for Vite provides some examples of extending the bundler to provide virtual modules to a project. The plugin could generate the custom element and dynamic registry code as the single source of truth for React islands functionality. Each workspace would be set up in two files:

// vite.config.ts
import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';
import { reactIslands } from 'vite-plugin-react-islands'

export default defineConfig({
  plugins: [react(), reactIslands()],
  // rest of the config specific to the workspace

plugin implementation source

// src/index.ts (entrypoint for the project)
import 'virtual:react-islands';

The virtual: prefix is following Vite conventions for generated modules

Now any updates to the custom element or registry can be released through the plugin! If the project didn't want the separate JS workspace, the same setup could be applied to the Rails app through Vite Ruby as well.

Overall, this feels like the right level of abstraction and quality-of-life improvement from the original setup while looking to the future of the web and JS tooling. You can find a complete example repo of this architecture on GitHub to try it out yourself. The Vite plugin is only an internal package to that repo at the moment; it could eventually be updated and published to support a variety of build tools through the unified plugin system.

If you learned something new, found this interesting, or have ideas about how it could be improved, please let me know on Twitter @hipsterbrown. Cheers & happy building!

Bonus

If you made it this far and like the concept but want something a bit lighter than React for your islands, I have a branch of the repo to provide Preact in Rails; it can be compatible with the React implementation while being smaller in bundle size than the react package by itself. There are trade-offs to consider that is probably a whole separate blog post to discover.

My Self-Hosted Platform

Thu, 25 Aug 2022 00:00:00 GMT

In light of the recent news about Heroku ending their free tier, I thought I would talk about the alternative platform I've been using for several years (Dokku) and why I think it is worth adopting.

What is Dokku?

A "Platform as a Service", or PaaS, provides a way creating, managing, and deploying applications without the concerns of the underlying server infrastructure. Rather than needing to requisition a standalone or shared server, configure the application dependencies for the operating system, and set up some type of deployment pipeline for getting that code onto the server, i.e. FTP or rsync for the old fashioned folks 😉, a PaaS abstracts over the details and make deployment as simple as git push. They generally include additional integrations for things like databases, SSL/TLS certificates, and backups. This is the service provided by Heroku, among others, to enable more people to share their applications, from hobby projects to full businesses, and it looks like the former audience is being pushed away. Enter Dokku.

From the documentation:

Dokku is an extensible, open source Platform as a Service that runs on a single server of your choice

By using Docker and Heroku's open source Buildpack system, Dokku provides a service similar to Heroku that can be hosted on nearly any server hardware provider (including Raspberry Pis!). Since I've started using it, Dokku has added other builder options for deploying a variety of projects and grown its ecosystem of official and community plugins.

How I use Dokku

I currently host my Dokku instance on a $10 per month "droplet" on DigitalOcean. This one droplet manages this static site (hipsterbrown.com), the private analytics service for this site (using Umami), and a personal web app, along with the associated databases required by those services (PostgreSQL and CouchDB); all with auto-renewing LetsEncrypt TLS certificates.

My personal site is deployed automatically through a GitHub Action that performs a git push to Dokku. I perform manual pushes for the React app since it doesn't change as often. Finally, I use the Docker image maintained by the Umami team as the build target for that deployed application since it "just works." This flexibility has allowed me to pick the best deployment method for each situation.

While most folks will advise against hosting a database on the same server as the dependent application, none of that data is vital to me; so I am OK with the trade-off of convenience over durability.

Why I'll continue to use Dokku

Since I first set up Dokku, I have rarely needed to SSH into my server to manage the platform. Meanwhile, the project has many great updates with additional functionality and quality of life improvements that I could apply when I felt ready (made very approachable through the dokku-update command). Having the control over my personal platform has provided me the freedom to experiment without worrying about creating various different accounts or racking up unexpected bills due to forgotten projects. For a dollar less per month than the "Hobby" dyno on Heroku, it is possible to set up Dokku to host a Rail app and database with a similar expected workflow.

I like to muck around with server management and "Dev Ops" infrastructure, so hosting Dokku has allowed me to do that while also letting me stay hands off for a while. If you never want to think about the server or SSH into an environment, Dokku might not be the right fit and there are plenty of other options these days, even for free. I'm not claiming Dokku is the right or only way to deploy applications and services, rather this is my current preferred way for my needs. If this makes sense for you as well, give Dokku a try and feel free to let me know on Twitter how it goes.

Cheers and happy hosting!

Components for Everyone

Mon, 13 Sep 2021 00:00:00 GMT

TL;DR This is not about web components / custom elements, rather why component-driven architecture for traditional server-rendered apps could be a better solution than adopting a client-side framework.

Background

Recently, I've started to form the opinion that client-side JS libraries, like Vue, React, Svelte, etc*, have grown in adoption within traditionally server-rendered applications due to component-driven view architecture more than any other feature they offer. I believe this core abstraction is key to why larger frameworks, like NextJS, Nuxt, Gatsby, and SvelteKit, are built atop those libraries with a targets of static site generation (SSG) or server-side rendering (SSR). This motivation can lead to further complexity around managing a distributed client-server codebase and constant context switching for full stack developers.

For context, I've been using React for ~6 years (starting as the view layer replacement for a Backbone app) and currently work on a front end platform team that supports product squads using Rails and/or React to develop client-side features, depending on the experience of the team and requirements of the feature. Before adopting React a couple of years ago, engineers at the company developed a Ruby component abstraction that allowed them to create a shared gem of design system components** for use across the production Rails applications. Even with React in active use, we still have this Ruby abstraction and are starting to adopt ViewComponent in its place to resolve issues around lack of documentation and surrounding tooling expected by devs who have used component-driven frameworks in the past, i.e. Storybook.

With that in mind, I wondered how many other teams chose to build features using a client-side JS framework primarily for built-in component model, consciously or not. The more I used a server-side component system, the more I recognized the things I liked about building React components, without the need to context switch between Ruby and JavaScript in a single feature.

This led to some lazy web research on Twitter to see if other folks thought about this subject; if so, where are they seeing this workflow in other frameworks?

https://twitter.com/hipsterbrown/status/1433792423973605397?s=20

While no one provided any other examples, outside of using SSR-only with one of the popular JS libraries I mentioned previously, there was enough engagement to continue exploring the wider web.

Workflow

Before diving into the various language implementations I found, I want to break down the core advantages the component model offers application devs. When I refer to "component-driven view architecture", I am including the surrounding ecosystem of patterns and tooling as motivation for its accession:

isolated development playground (Storybook / Pattern Lab)
unit testing (quickly verify UI logic without spinning up a browser)
packaging (ship as a reusable resource/gem/pub)
sidecar assets (easily scope styles and behavior)

Each of those values can help scale the efficiency of teams building user interfaces, no matter the platform technology.

Taking a look at open source design system components from large Rails shops like Primer from GitHub and Polaris from Shopify, the alternative to using JS components is usually collection of CSS classes; this can lead to inconsistent usage when applying them to markup and a worse developer experience. The Primer ViewComponents gem is still fairly new when compared to the CSS and React implementations of that design system but solves the job of providing reusable pieces of UI in a familiar interface to Rubyists, including an interactive Storybook using @storybook/server!

Although I continue to mention the benefits in terms of pattern libraries, they can also be appreciated within a single app codebase to share common functionality across features.

Implementations

Ruby / Rails

I have mentioned ViewComponent several times already, as the inspiration / motivation for this post. The docs do a great job explaining the philosophy behind the framework:

Traditional Rails templates have an implicit interface, making it hard to reason about their dependencies. This can lead to subtle bugs when rendering the same template in different contexts.

ViewComponent Data Flow

It has been growing in popularity since its introduction by GitHub; looking at the open source projects using ViewComponent: https://opensourcerails.org/search/by-gem/view_component

But that's not the only solution on the block, especially when looking to build a static site. Bridgetown bills itself as "a fast, scalable, modular, and thoroughly forward-looking framework for building websites and frontend applications" and a modern successor to Jekyll. Although it also supports ViewComponent, the Bridgetown team is the first place I've seen an implementation of components for the Liquid templating language. Liquid component does not go as far as ViewComponent in providing a Ruby class as the interface for a component, but uses YAML front matter well to document and describe pieces of reusable view logic.

PHP / Laravel

It appears there has been a concept of "components" in Laravel's Blade templates system since version 5.4; however they are more comparable to partials with support for slots until version 7. This current iteration of Blade component is backed by a PHP class with an associated template (or an inline component view), which is more similar to ViewComponent. These components are rendered using a familiar kebab-case, HTML tag-like syntax: <x-alert>.

Python / Django

django-component provides "declarative and composable components inspired by javascript frameworks". They are made up of a Python class and associated HTML template, like the previously mentioned ViewComponent and Blade components.

There is also a library called slippers, that reminds me of liquid components more than ViewComponent since they don't rely on some kind of class or backing data structure defined outside the template.

.Net / Blazor

As a modern replacement for Web Forms, Blazor supports UI encapsulation through components using the Razor templating language to define markup and logic in a single file; although that logic can be broken out as a separate C# class.

Elixir / Phoenix

The Phoenix.Component API allows Elixir developers to create function components, similar to React, including ability to pass in "assigns" (props) and "blocks" (children).

Surface UI builds on top of the Phoenix component API to provide "a fast and productive solution to build modern web applications". It uses an extended templating syntax, helpful macros, and built-in components to become a more full-featured view framework for Phoenix applications.

JS / Node

Lastly, we get to the curious case of server-rendered component systems for NodeJS. The closest library in comparison to the previous examples is Marko, which allows developers to "start with simple HTML templates and add powerful components as needed". Marko templating can be integrated into popular server libraries as the core view engine, rather than forcing a typical client-side framework into that workflow. There was an official view engine for React in Express, but it no longer appears actively supported; React Server Components are also still theoretical at the time of writing.

There is active development in this space with the advent of tools like Astro and Slinkity that aim to take a framework-agnostic approach to introduce components into modern, HTML-first static sites. Astro does a great job comparing itself to existing tools and Slinkity is building on the shoulders of the awesome Eleventy ecosystem (slight bias given this site is currently built with Eleventy).

Previously, it seemed like NodeJS devs didn't invest in a server-side component framework because existing client-side libraries could be worked into the SSR pipeline; why reinvent the wheel? There is less of a context switch in terms of syntax when compared to the workflows of other web languages, so the friction lies in the uncanny valley of managing a client-side component system in a traditional server application. Even if a library like React or Vue is used as SSR-only, the APIs were designed for the front end, which can lead to confusion about how to constrain the usage of third-party libraries and patterns.

Who knows where the future is headed in this use case? Could there be some type of mustache.js extension or Handlebars helper for rendering a JavaScript class in a template? That could be pretty neat!

Summary

This post is not meant to denigrate client-side component frameworks; I love developing front end applications with JavaScript and will continue to do so. But choosing to build with that stack comes with additional complexity that not every team is ready to handle, so there should be useful alternatives for server-rendered ecosystems and take advantage of that environment. I hope we see more tools like Storybook Server being used to develop those server components in isolation and generate documentation for easier discoverability. There should be a rich collection of accessible, open source component libraries, similar to Headless UI or Radix UI, so apps can ship features that are enjoyed by everyone by default.

If I missed something, like an example implementation or assumed detail, please reach out on Twitter to help me correct it here. I'll continue to shape these thoughts, put them into practice through personal and professional projects, and follow up with more articles to share any lessons learned.

* I purposely left out more complete frameworks like Ember and Angular since they focus on shipping full client-side applications out of the box.

** This was created before my time at the company but is explained well in this Rails Conf talk from 2018: https://www.youtube.com/watch?v=Egumr5KiTNI

How to read TypeScript errors

Tue, 08 Jun 2021 00:00:00 GMT

At some point when writing code, everyone runs into errors. These errors can occur at runtime, build time, or as feedback in editors while the code is being written. When seeing TypeScript errors for the first time, they can range from helpful to WTF.

Type '{ children: string; onClick: (event: MouseEvent<HTMLAnchorElement, MouseEvent>) => void; fontSize: string; pb: string; mr: string; to: string; exact: true; activeClassName: string; }' is not assignable to type 'IntrinsicAttributes & NavLinkProps<unknown> & RefAttributes<NavLink<unknown>> & { theme?: StyleClosetTheme | undefined; } & { ...; } & Pick<...> & { ...; }'.
  Property 'fontSize' does not exist on type 'IntrinsicAttributes & NavLinkProps<unknown> & RefAttributes<NavLink<unknown>> & { theme?: StyleClosetTheme | undefined; } & { ...; } & Pick<...> & { ...; }'.  TS2322

     97 |   <ActiveLink
  >  98 |     fontSize="2"
        |     ^
     99 |     pb="4"
    100 |     mr="9"
    101 |     to="/"

The above error is only a couple lines but has verbose and truncated type output.

Get it in realtime.

Over the last few years, I've grown to appreciate the in-editor feedback available to many languages, including TypeScript. This feature is either built-in or available as a plugin to all sorts of dev environments, from vim to Visual Studio Code, which are my main choices. Even ignoring the nice refactoring tools, live feedback is incredibly useful for associating errors with the exact lines in the code with as much context as possible.

Starting from the bottom.

While some compilers can provide pin point feedback and helpful suggestions for fixes, the TypeScript compiler errors still have a way to go. When viewing these verbose error traces, it's been helpful to view the bottom message and work my way up. These last messages usually provide the most specific comparison between mismatched types or inference issues.

Where did that come from?

Speaking of inference, one of the handy and hurtful things about TypeScript is the ability to assign types by inference, so not everything needs an explicit type declaration. The compiler tries its best to get this right, but when it doesn't, it can be a rabbit hole of figuring out where the inferred type came from. This leads to another push for enabling in-editor feedback to help trace assumed types back to the source. Adding explicit declarations during this exploration can help narrow the issue, even if it feels like TS should just know the correct type.

Don't be afraid to dig.

A few of the worst offenders in previous debug sessions have come from clashing types and interfaces between third-party libraries and my own code. But this has also led to a better understanding when reading other people's typed code. When looking into the source of a compiler error, feel free to jump to the definition of the flagged type and follow the thread of code to its eventual conclusion if needed. Ideally, the authors will have some comments (maybe even typedoc and clearly named generic types; however, there can be a lot of "clever" code out there to make a dynamic API work with the compiler.

I hope these tips are helpful the next time the red squiggle of doom appears in your editor and displays an intimidating stack of feedback.

Other resources:

Deciphering TypeScript's React errors: goes in-depth into specific errors seen in a React codebase.
TypeScript in Visual Studio Code: shows how to use the TS feedback and features in the popular editor.
coc.nvim quick start: provides set up instructions for using this vim plugin with TypeScript support out of the box.

Typed mocks for Jest

Tue, 04 May 2021 00:00:00 GMT

TL:DR jest-when and its associated types package are useful additions to any TypeScript codebase looking for a nicer way to use Jest mocks.

If you've ever worked on a TypeScript project that used Jest as its testing framework, you've most likely run into the issue of using a mocked function, method, or class in your test setup and seen a compiler error like "Property 'mockImplementation' does not exist on type 'blah'." Even though you know you've replaced that imported dependency, TypeScript is still using the regular types for it. When looking at the docs, the jest.MockedFunction type is recommended as a solution for resolving this issue:

import { myFunction } from './library';
jest.mock('./library');

const mockMyFunction = myFunction as jest.MockedFunction<typeof myFunction>;
expect(mockMyFunction.mock.calls[0][0]).toBe(42);

This can be quite tedious when done several times in the setup for a test, so my coworkers and I came up with a helper called mockOfFunction that made this process a bit cleaner:

// in some shared testing helpers file
export function mockOfFunction<T extends (...args: any[]) => any>(f: T): jest.Mock<ReturnType<T>> {
  return (f as unknown) as jest.Mock<ReturnType<T>>;
}

// in a test setup
import { myFunction as _myFunction } from './library';
import { mockOfFunction } from './testing-helpers';
jest.mock('./library');

const myFunction = mockOfFunction(_myFunction);

While this quieted the compiler's complaints, the abstraction caused some confusion among team members who were newer to TypeScript and Jest; leading them to believe that mockOfFunction was doing the actual mocking rather than jest.mock. In an effort to help improve my team's testing workflow, I sought out a better solution and discovered jest-when in the process.

jest-when allows you to use a set of the original Jest mock functions in order to train your mocks only based on parameters your mocked function is called with.

Given the API provided by jest-when, any imported mocked dependency could use the allowed mocking methods without worrying about type assertions and odd setup boilerplate.

import { when } from 'jest-when';
import { myFunction } from './library';
jest.mock('./library');

when(myFunction).calledWith(42).mockReturnValue(true);

https://github.com/timkindberg/jest-when

The actual purpose of providing more robust and specific mocking behavior to Jest was an added bonus in my eyes, especially as it looked familiar to the when method from testdouble.

Using this library has been particularly helpful when stubbing feature flag responses:

when(useFeatureFlag).calledWith({ name: 'my-feature-flag' }).mockReturnValue({ enabled: true });

Whereas previously, any feature flag request would have been stubbed with the same response and making it nearly impossible to distinguish expected output related to overlapping flags or experiments.

So I highly recommend checking out jest-when and improving your mocking setup, especially when dealing with TypeScript.

Shipping Web Workers Simply

Sun, 02 May 2021 00:00:00 GMT

I was planning a feature that needed some kind of background process on the front-end, which led me to exploring Web Workers in a production use case for the first time. As part of building this feature, I wanted to be able to share the Worker through a common library that each app depended on. This requirement is not addressed by most articles that talk about Workers; usually showing examples of code defined in a separate file that is referenced by that file's name when creating a Worker instance.

Based on the inline web worker example from HTML5 Rocks, I created a tagged template helper to generate a Worker instance:

function worker(strings, ...interpolatedValues) {
  const script = _flatten(_zip(strings, interpolatedValues)).join('');
  const url = URL.createObjectURL(
    new Blob([script], { type: 'text/javascript' })
  );
  return new Worker(url);
}

Or without the lodash dependency:

function worker(strings, ...interpolatedValues) {
  const script = [strings, interpolatedValues]
    .reduce(
      (result, current, index) =>
        result.length
          ? result.map((a, i) => a.concat(current[i]))
          : result.concat(current.map((a) => [a])),
      []
    )
    .flat()
    .join('');
  const url = URL.createObjectURL(
    new Blob([script], { type: 'text/javascript' })
  );
  return new Worker(url);
}

This could be made even simpler by not allowing interpolated values to be used in the script, but, by allowing this usage, data can be passed to the Worker definition when it is created! Since I was using TypeScript for this project, I could define a typed and tested function that could be colocated with the feature that consumes and interacts with the inlined worker.

function createHandler(self: Pick<Worker, 'postMessage'>) {
  return function eventHandler(event: MyCustomEvent) {
    if (event.data.type === 'my-event') {
      // perform some background work
      self.postMessage({ type: 'my-response', data: someData });
    }
  };
}

export function startWorker () {
  const myWorker = worker`
    self.onmessage = ${createHandler.toString()}(self);
  `;

  myWorker.addEventListener('message', ({ data }) => {
    if (data.type === 'my-response') {
      // react to the worker response
    }
  });

  myWorker.postMessage({ type: 'my-event' });
}

This was a fun problem to solve and has worked out well so far as the feature has been running in production for some time. I didn't create a package or example repo for this helper since it is simple enough to copy and paste into whichever project needs it without me dedicating some amount of time to maintain the code.

Feel free to share some use case examples with me on Twitter. I'd love to see them!

Decorate Storybook with MirageJS

Tue, 13 Apr 2021 00:00:00 GMT

TL;DR Check out the published addon: storybook-mirage

When building and testing an application or service, eventually the need to mock communication with another service arises. For client-side web applications, that usually means mocking HTTP requests to a server. Starting out, this could be done using a library like fetch-mock or simply manually mocking methods on an API client module using jest.mock. As the app grows and/or the team expands, something more robust and realistic is required to scale, as well as provide the ability to mock requests outside of the test environment; a downside of the solutions mentioned previously.

This is where tooling like MirageJS comes in.

Mirage JS is an API mocking library that lets you build, test and share a complete working JavaScript application without having to rely on any backend services.

https://miragejs.com/

By intercepting outgoing HTTP requests, Mirage can exist outside a test environment and provide a source of truth for interacting with an external service. The docs share the many scenarios and setups in which Mirage can be useful when developing an app. I appreciate the familiar route handler syntax and use of factories for quick data creation without leaking too much of the implementation. In my experience so far, Mirage has allowed several teams to collaborate with this shared server interface; speeding up their testing and prototyping workflow. In regards to prototyping, the Mirage docs do not yet specify it can be used with Storybook, which is what this article hopes to provide.

Storybook is an open source tool for developing UI components in isolation for React, Vue, Angular, and more. It makes building stunning UIs organized and efficient.

https://storybook.js.org/

Storybook provides “decorators” as a way to “augment your stories with extra rendering or gather details about how your story is rendered”.

If your components are “connected” and require side-loaded data to render, you can use decorators to provide that data in a mocked way, without having to refactor your components to take that data as an arg.

Using decorators to provide data

By defining a functional component that starts and loads a Mirage server, the stories can be decorated with mocked API handlers.

// withServer.js

import {
  useEffect,
  useRef,
} from "@storybook/addons";

export const withServer = makeServer => (StoryFn) => {
  const server = useRef();

  useEffect(() => {
    server.current = makeServer();
    return () => server.current.shutdown();
  }, []);

  return StoryFn();
};

The decorator uses hooks from the @storybook/addons package. It is set up with the server creator function, which is cleaned up when the story is unmounted.

// .storybook/preview.js

export const decorators = [withServer(makeServer)];

While the example decorator simply starts and stops the Mirage server, it could be configured for each story or component through the mirage parameter:

// withServer.js
export const withServer = makeServer => (StoryFn) => {
  const server = useRef();
  const { logging, fixtures, handlers, timing, instance } = useParameter(
    'mirage',
    {
      handlers: null,
      fixtures: null,
      logging: false,
      timing: null,
      instance: null
    }
  );
  // rest of setup in useEffect

// Page.stories.js | Page.stories.ts

import Page from './Page';

export default {
  title: 'Page',
  component: Page,
  parameters: {
    mirage: {
      // automatically log requests to browser console https://miragejs.com/api/classes/server/#logging
      logging: true,
      // customize when a request responds https://miragejs.com/docs/main-concepts/route-handlers/#timing
      timing: 1000,
      // override route handlers for the story https://miragejs.com/docs/main-concepts/route-handlers/
      handlers: {
        get: {
          '/api/user': 404, // status code
          '/api/items': [204, {}, { items: [] }], // arguments for Response https://miragejs.com/api/classes/response/
        },
        post: {
          'api/task': { task: {} } // body for Response
        }
      },
      // data to seed Mirage ORM https://miragejs.com/docs/main-concepts/fixtures/
      fixtures: null,
      // pass in a custom Mirage server instance to override the global setting
      instance: null
    }
  },
};

All this will allow components to make requests like normal, captured by Mirage with the same behavior as when using it in normal development and testing.

By tracking state in the decorator, the integration could become more interactive when displayed in a custom panel:

Custom storybook panel to modify the response data and status

View request logs handled by Mirage

Combined with the ability to reuse stories in unit test scenarios, building features that depend on remote data sources has become incredibly streamlined and independent of running the complete app locally. I hope you find this knowledge and workflow as productive as I have.

The addon is published here: storybook-mirage

Using esbuild with 11ty

Tue, 30 Mar 2021 00:00:00 GMT

A little while ago, I migrated my personal site to 11ty as the static site engine; moving away from Jekyll for various reasons: speed, language familiarity, and community. Given 11ty's sole focus on being a great static site builder, there isn't a built-in concern for processing or bundling other assets like CSS and JavaScript. While using Jekyll, I had Grunt set up to process Sass, minify JS, and create an SVG icon map. Since I replaced the SVG icon map with inline include expressions, I wanted a different build system to process the Sass and JS that could integrate cleanly with 11ty.

During my initial research, I looked into the starter projects shared through the 11ty docs. There's a wide range of options, from simple résumé sites to full e-commerce solutions and remote CMS sources. Much like the story of the three bears, nothing seemed to fit quite right because they either did more than required or not enough. Most of the solutions also required running a one or more separate processes outside of 11ty. This led me to assembling my own pipeline using 11ty plugins, which is another plethora of choice for most things except processing JS and Sass. The few plugins for handling styles appeared to monkeypatch the Eleventy class, which felt fragile to depend on.

Finally, I got around to looking at esbuild to solve my problem. I've used it at work to improve the performance of TypeScript and React bundling, although the scale of my site is considerably smaller. esbuild doesn't handle Sass out of the box (CSS support is in progress at the time of writing), but it too has a plugin system to help extend its capabilities. I landed on the esbuild-sass-plugin because it looked up to date, performant, and provided the choice between node-sass and dart sass. Integrating was just a matter of calling esbuild in 11ty's "afterBuild" event handler to ensure the output directory was created by 11ty before processing the Sass and JS.

// .eleventy.js
const esbuild = require("esbuild");
const { sassPlugin } = require("esbuild-sass-plugin");

module.exports = config => {
  config.on("afterBuild", () => {
    return esbuild.build({
      entryPoints: ["sass/app.scss", "js/app.js"],
      outdir: "_site/assets",
      minify: process.env.ELEVENTY_ENV === "production",
      sourcemap: process.env.ELEVENTY_ENV !== "production",
      plugins: [sassPlugin()]
    });
  });
  config.addWatchTarget("./sass/");
  config.addWatchTarget("./js/");
  // continue configuring 11ty
};

The addWatchTarget method helps trigger the esbuild when one of the entrypoints, or files related to those entrypoints, has changed. Keeping 11ty in charge of file watching maintains a source of truth for build triggers, rather than having competing watchers when using separate processes. Even though esbuild does support incremental builds, the amount of files being processed is so small that it would be overkill to use this feature and means I'm not concerned about the uneccessary builds that happen while I'm not working on those assets. A nice perk from this overall setup meant converting my JavaScript to TypeScript just by renaming my source file and esbuild did the rest.

All in all, its nice to know that extending 11ty is supported by a rich community of examples, plugins, and documentation. If anything needs to change in the future, I'm confident I could find a way forward.

P.S.

During discovery for this post, I found eleventy-plugin-esbuild by jamshop as a pre-built solution for what I ended up doing myself. The core differences with this implementation is the use of the synchronous version of esbuild's processing and manages its own build cache as custom global data.

Wrangle complexity with finite-state reducers

Tue, 23 Mar 2021 00:00:00 GMT

While the examples include references to React, the ideas are applicable to any UI development systems.

If you've built interfaces before, you've probably run into this issue: state explosion. What starts out with one or two pieces of data that affect the output of your component, widget, etc, over time grows into several intertwined variables and flags that needs to be maintained by other team members (or your future self at the very least).

Let's take a look at building a basic accordion component.

An accordion is a vertically stacked set of interactive headings that each contain a title, content snippet, or thumbnail representing a section of content. The headings function as controls that enable users to reveal or hide their associated sections of content. Accordions are commonly used to reduce the need to scroll when presenting multiple sections of content on a single page.

WAI-ARIA Authoring Practices

Based on the specification, we'll need to control which panel is being displayed while closing any open panels. To keep the scope of work fairly small, we're only going to manage two panels and use the <details> element to control showing the content.

import React, { useState } from 'react';

function MyAccordion () {
  const [isFirstPanelOpen, setFirstPanelOpen] = useState(false);
  const [isSecondPanelOpen, setSecondPanelOpen] = useState(false);

  const onFirstPanelClick = () => {
    if (isSecondPanelOpen) setSecondPanelOpen(false);
    setFirstPanelOpen(currentState => !currentState);
  }

  const onSecondPanelClick = () => {
    if (isFirstPanelOpen) setFirstPanelOpen(false);
    setSecondPanelOpen(currentState => !currentState);
  }

  return (
    <>
      <details
        open={isFirstPanelOpen}
        id="firstPanel"
        onClick={onFirstPanelClick}
      >
        <summary role="heading" aria-level="1" tabIndex="-1">
          <button
            aria-expanded={isFirstPanelOpen}
            aria-controls="firstPanel"
            type="button"
          >
            {isFirstPanelOpen ? "Close" : "Open"} My First Panel
          </button>
        </summary>

        <p>Some basic content goes here</p>
      </details>
      <details
        open={isSecondPanelOpen}
        id="secondPanel"
        onClick={onSecondPanelClick}
      >
        <summary role="heading" aria-level="1" tabIndex="-1">
          <button
            aria-expanded={isFirstPanelOpen}
            aria-controls="secondPanel"
            type="button"
          >
            {isSecondPanelOpen ? "Close" : "Open"} My Second Panel
          </button>
        </summary>

        <p>Some more basic content goes here</p>
      </details>
    </>
  );
}

View live example on CodePen: https://codepen.io/HipsterBrown/details/qBRWbOG

The state management code appears simple enough with two boolean state variables and two click handlers. The state variables are toggling the open states of the two <details> elements, as well as the <summary> text for each panel. Each time we toggle one piece of state, we may end up toggling another since only one panel should be open at a time. Adding more panels would quickly lead to the state explosion introduced in the beginning of this post. Even in this pared-down version, it would be tough to guarantee our feature is working at a glance.

At this point, it might be a good idea to reach for a reducer to help with this problem:

useReducer is usually preferable to useState when you have complex state logic that involves multiple sub-values or when the next state depends on the previous one.

React docs useReducer

Let's try applying this to our accordion:

import React, { useReducer } from 'react';

const reducer = (state, action) => {
  switch (action) {
    case 'TOGGLE_FIRST_PANEL':
      return { isFirstPanelOpen: !state.isFirstPanelOpen, isSecondPanelOpen: false };
    case 'TOGGLE_SECOND_PANEL':
      return { isSecondPanelOpen: !state.isSecondPanelOpen, isFirstPanelOpen: false };
    default:
      return state;
  }
};

function MyAccordion() {
  const [{isFirstPanelOpen, isSecondPanelOpen}, dispatch] = useReducer(reducer, {
    isFirstPanelOpen: false,
    isSecondPanelOpen: false,
  })

  const onFirstPanelClick = () => {
    dispatch('TOGGLE_FIRST_PANEL')
  };

  const onSecondPanelClick = () => {
    dispatch('TOGGLE_SECOND_PANEL');
  };

  // the rest stays the same
}

View live example on CodePen: https://codepen.io/HipsterBrown/details/ExZYPmM

Adding in our reducer helped collect all the allowed state changes into one function, rather than spreading it between two click handlers, which is useful for identifying where to add or update any new behavior. However, we still haven't solved our state explosion issue, since every new panel will add a new boolean field to our state object controlled by the reducer and no guarantee the accordion couldn't end up in a state of displaying more than one open panel. We need a way to define all the allowed states for our component, i.e. a finite-state reducer;

A "finite-state reducer" is just a riff on finite-state machine (FSM) as implemented using a reducer function. If we look at our earlier code, we can identify three allowed states for our component: closed, displaying the first panel, displaying the second panel. It can never be closed and displaying a panel, nor can it be displaying both panels at once. We can capture this idea by modifying our existing reducer to update a single string value and inverting the typical switch statement setup.

import React, { useReducer } from 'react';

// state = closed | displayingFirstPanel | displaySecondPanel
const reducer = (state, action) => {
  switch (state) {
    case 'closed':
      switch (action) {
        case "TOGGLE_FIRST_PANEL":
          return 'displayingFirstPanel';
        case "TOGGLE_SECOND_PANEL":
          return 'displayingSecondPanel';
        default:
          return state;
      }
    case 'displayingFirstPanel':
      switch (action) {
        case "TOGGLE_FIRST_PANEL":
          return 'closed';
        case "TOGGLE_SECOND_PANEL":
          return 'displayingSecondPanel';
        default:
          return state;
      }
    case 'displayingSecondPanel':
      switch (action) {
        case "TOGGLE_FIRST_PANEL":
          return 'displayingFirstPanel';
        case "TOGGLE_SECOND_PANEL":
          return 'closed';
        default:
          return state;
      }
    default:
      return state;
  }
};

function MyAccordion() {
  const [state, dispatch] = useReducer(
    reducer,
    'closed'
  );
  const isFirstPanelOpen = state === 'displayingFirstPanel';
  const isSecondPanelOpen = state === 'displayingSecondPanel';

  // the rest stays the same
}

View live example on CodePen: https://codepen.io/HipsterBrown/details/PoWYZQm

The nested (or two-dimensional) switch statement can be a little unsettling at first, especially when compared to the first version that appeared relatively compact. However, the point of using the current state in the first switch is to describe the allowed "transitions" to another state based on the "action", or "event" in typical machine parlance. As we read down the 2D switch, when the current state is "closed", toggling the first panel will display the first panel, and the same goes respective to the second panel.

The real control comes in the cases for when one of the panels is being displayed; when the first panel is open and it is toggled, the reducer transitions back to closed; if the second panel is toggled at this point, the reducer transitions to displaying that panel. There is no check to see if the first panel is being displayed within the "action" switch because the first "state" switch has already confirmed that. The isFirstPanelOpen and isSecondPanelOpen variables are derived from the single piece of state coming from the reducer, mostly to simplify rest of the example.

A bonus feature of modeling the reducer as a finite-state machine is the ability to visualize the behavior of our feature using a state diagram.

If we want to reorganize the 2D switch in our reducer, we can get the same results using a familiar object syntax:

const config = {
  initial: 'closed',
  states: {
    closed: {
      on: {
        'TOGGLE_FIRST_PANEL': 'displayingFirstPanel',
        'TOGGLE_SECOND_PANEL': 'displayingSecondPanel'
      }
    },
    displayingFirstPanel: {
      on: {
        'TOGGLE_FIRST_PANEL': 'closed',
        'TOGGLE_SECOND_PANEL': 'displayingSecondPanel'
      }
    },
    displayingSecondPanel: {
      on: {
        'TOGGLE_FIRST_PANEL': 'displayingFirstPanel',
        'TOGGLE_SECOND_PANEL': 'closed'
      }
    }
  }
};

const reducer = (state, action) => {
  return config.states[state].on[action] || state;
};

function MyAccordion() {
  const [state, dispatch] = useReducer(
    reducer,
    config.initial,
  );

  // the rest stays the same
}

View live example on CodePen: https://codepen.io/HipsterBrown/details/zYNOqYY

In the end, we have a clear description for how our feature works and the freedom to share the functionality with another component without including the UI or creating some specialized hook. If the feature grows, there is a maintainable structure for adding new states, transitions, and actions to accommodate those changes. As side-effects start to get involved, we can reach for something like useEffectReducer, @xstate/fsm, or xstate, but more on that in another post.

In the meantime, check out some other articles that dig into managing gradual complexity and state explosion:

Simple Slot API for React

Tue, 16 Mar 2021 00:00:00 GMT

Once you get started building components in React, they start out fairly simple or very specific to a feature. As you continue constructing your interfaces, patterns emerge and there's a need for more generalized, flexible components. You may stumble upon the term "compound components" through some very informative articles like this one from EpicReact.dev. To author compound components at work and for personal projects, I use an approach inspired by the slot element from the Web Component spec.

If you haven't heard of the slot element:

a placeholder inside a web component that you can fill with your own markup, which lets you create separate DOM trees and present them together.

MDN HTML elements reference <slot>

There is a more in-depth tutorial here: https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_templates_and_slots#adding_flexibility_with_slots

This sort of composability is great when building structural components, like layouts, that should be very flexible about their content but want more control over placement of that content. In React, props could certainly be used, however the readability of JSX is hindered when passing large blocks of context through props.

In the past, I've enabled this kind of flexibility with static child component connected to a parent:

import React from 'react';

type MyLayoutComponent = React.FC & {
  Header: React.FC;
  Body: React.FC;
  Footer: React.FC;
}

const MyLayout: MyLayoutComponent = ({ children }) => {
  const [header, body, footer] = React.Children.toArray(children);

  // place elements as needed
}

MyLayout.Header = ({ children }) => <>{children}</>;
MyLayout.Body = ({ children }) => <>{children}</>;
MyLayout.Footer = ({ children }) => <>{children}</>;

The above approach relies on the person using MyLayout to know the correct ordering of the child components. Repeating this pattern in other components would be tedious and lead to drift as each component author tries a different take.

Here is a simple but conventional implementation of a Slot component with an associated helper function:

import React from 'react';

export interface SlotProps {
  name: string;
}

export const Slot: React.FC<SlotProps> = ({ children }) => <>{children}</>;

export function getSlots(
  names: string[],
  children: React.ReactElement | React.ReactElement[] | React.ReactNode | React.ReactNodeArray
): Array<React.ReactElement | null> {
  return names.map(name => {
    let slot = null;
    React.Children.forEach(children, child => {
      if (!React.isValidElement(child)) {
        return;
      }
      if (child.type === Slot && (child.props as SlotProps).name === name) {
        slot = React.cloneElement(child);
      }
    });
    return slot;
  });
}

As you can see, the Slot component itself is basically a wrapper object to expose a name prop for use in the getSlots function. Using this API to the earlier MyLayout component would look like the following:

import React from 'react';
import { getSlots, Slot } from './Slot';

const MyLayout: React.FC = ({ children }) => {
  const [header, body, footer] = getSlots(['header', 'body', 'footer'], children);

  // place elements as needed
}

// usage

<MyLayout>
  <Slot name="header">Hello World</Slot>
  <Slot name="body"></Slot>
  <Slot name="footer"></Slot>
</MyLayout>

If we wanted to provide stronger type feedback for available slot names:

import React from 'react';
import { getSlots, Slot } from './Slot';

type MyLayoutSlot = React.FC<{ name: 'header' | 'body' | 'footer' }>;

type MyLayoutComponent = React.FC & {
  Slot: MyLayoutSlot;
};

const MyLayout: MyLayoutComponent = ({ children }) => {
  const [header, body, footer] = getSlots(['header', 'body', 'footer'], children);

  // place elements as needed
}

MyLayout.Slot = Slot as MyLayoutSlot;

Even with the slight overhead of adding a static Slot child, the authoring and usage of the new API provides an arguably better experience than the approach of three different static child components. There is no need to worry about ordering and any unused slot will default to null, thus rendering nothing. When comparing it with the slot API for Web Components, it reverses the roles for the sake of discoverability and type-safety; since the <slot> is used in the component template to author the slotted areas, and a slot attribute is used to set the slotted content when using the component.

As mentioned before, the Slot component is a convenient feature for providing flexibility with control over placement of content. There is still a case for using static child components to provide styling or functionality through association without carrying about placement (maybe more on that in a future post).

Maybe this feature will be built into React one day, like it is for Vue and Svelte. Until then, I hope this solution helps you as much as it has helped me.

Creating React Context types with generics

Thu, 11 Mar 2021 00:00:00 GMT

There are several great articles describing how to work with React Context using TypeScript, including one from the folks at React Training: https://reacttraining.com/blog/react-context-with-typescript/

In this quick post, I want to describe how I've used TypeScript generics in combination with React Context to build more flexible but strongly typed shared state. So prior knowledge of React Context and TypeScript is assumed, otherwise select one of the previous links before continuing.

For a refresher on generics:

While using any is certainly generic in that it will cause the function to accept any and all types for the type of arg, we actually are losing the information about what that type was when the function returns. If we passed in a number, the only information we have is that any type could be returned.

Instead, we need a way of capturing the type of the argument in such a way that we can also use it to denote what is being returned. Here, we will use a type variable, a special kind of variable that works on types rather than values.
function identity<Type>(arg: Type): Type {
  return arg;
}

https://www.typescriptlang.org/docs/handbook/2/generics.html#hello-world-of-generics

For the feature in question, there is a list of items that can be selected in a table with the selected items stored as a list of IDs. We want to make sure this Context data stores objects that must include an id property. We need to tell TypeScript that the generic type argument has constraints (required fields in this case): https://www.typescriptlang.org/docs/handbook/2/generics.html#generic-constraints

type ItemWithID = { id: string };
type MyContextData<Item extends ItemWithID> = {
  selectedItems: string[];
  itemList: Item[];
};

This gets a little tricky when creating the Context object since it is declared as a static variable:

const MyContext = React.createContext<MyContextData<ItemWithID>>(null);

The generic type argument for MyContextData will use the constrained ItemWithId type as a placeholder. Then we can create our Provider component to accept an Item generic:

type MyProviderProps<Item extends ItemWithId> = {
  itemList: Item[];
}

function MyProvider <Item extends ItemWithId>(
  { children, itemList }: React.PropsWithChildren<MyProviderProps<Item>>
) {
  // keep track of `selectedItems` somehow

  return <MyContext.Provider value={{ itemList, selectedItems }}>{children}</MyContext.Provider>;
}

To get the correct generic usage for the hook that consumes that Context object, some overrides need to happen:

function useMyContext<Item extends ItemWithID>() {
  const context = React.useContext<MyContextData<Item>>(
    (MyContext as unknown) as React.Context<MyContextData<Item>>
  );
  if (!context) {
    throw new Error('useMyContext must be used under MyContextProvider');
  }
  return context;
}

The type of MyContext is asserted to match the expected type with Item generic. Otherwise, TypeScript will raise an error like:

Type 'MyContextData<ItemWithID>' is not assignable to type 'MyContextData<Item>'

Finally, we can use our Provider component and hook with our feature:

// import MyProvider and useMyContext

type Account {
  id: string;
  name: string;
  age: number;
}

const App = () => {
  const itemList = // request or create this data

  return (
    <MyProvider itemList={itemList}>
      <AccountTable />
    </MyProvider>
  );
};

const AccountTable = () => {
  const { itemList, selectedItems } = useMyContext<Account>();

  // use the itemList and selectedItems data, which should match `Account[]` and `string[]` types respectively
};

That's it! Once you get the hang of the pattern, it opens up a world of flexible, reusable state management in your React + TypeScript application.

An Open Discussion About People

Tue, 04 Nov 2014 00:00:00 GMT

I had a fairly thorough but brief discussion with Ben Callahan of Sparkbox yesterday evening about Web Design and Development Processes, or at least it started out that way, via public Google Doc. These are some initial takeaways from that discussion and experience:

The role of front-end developer is still very vague in the responsibilities, purpose, and knowledge required to fulfill this position; this includes which side the group stands on with the gap between designers and developers in a work/project environment. Ben asserts that there shouldn't be a gap, wall, or division between the teams, and we should "bring everyone to the table." I completely agree, and I still believe the ideal mix of design-thinking and development know-how makes the front-end (and its devs) the perfect platform for bridging that gap, tearing down that wall, and eliminating that division.
It's ultimately about people. We kept circling back to this point thoroughout the discussion, and it epitomizes the root of most problems in any industry, much less tech. You can put a designer, front-end developer, and a server-side developer on a project, but who makes the tough decisions and ensures the project is done correctly? Companies need Passionate Maintainers^TM, team members who can facilitate communication among the group members, as well as contribute to the end product in a technical way. Teammates should empathize with each others' challenges, not just their own, and display humility to the expertise of others as well. Ben talks about developing these ideals in his teams at Sparkbox and through the various Build Right Workshops, but they are not easily or traditionally taught skills, especially in such a short period of time. I suppose it helps to at least start a dialogue among a group, or company, to foster those ideas when hiring new people and supporting the old. I would personally love to attend the Collaboration workshop at least once.
Community is key. As I stated in the Doc, we can look to Open Source Software (OSS) projects as a prime example of Passionate Maintainers^TM, people who care about the success of the project because it matches their ideals and is important to the community built around it. There are complete conferences around OSS projects and high-level jobs for OSS developers to represent their company in helping maintain the free tools they use everyday, because the power of a coomunity is massive. The most deciding factor behind learning and sticking with a new tool/framework/whatever is the community of people also sticking with it; it could have the strangest syntax, button layout, or name, but I will overcome those gripes as I consume the numerous articles, demos, and videos created by the community to learn all I need to know. So besides hiring someone to contribute to OSS, how does a company inspire the same type of passion and spirit seen in open source communities around its personal product or service? One the personnel level, Ben says, "We need to express the “bigger thing” that we want to champion and trust that the right people will show up." They [Sparkbox] like to know a person well enough that they are confient that their ideals match up before hiring them; this could be contracting them for a real world project and seeing how they work, or simply becoming more familiar with them over time. I'm still not sure how this can scale into the enterprise space with department heads and hundreds, if not thousands, of employees, but I didn't say we had all the answers yet.

Phew, that was a lot to download a couple hours after the initial discussion. I will probably be going over that Doc a lot and exploring these topics with other owners, developers, designers, managers, etc to get their weigh in as well. I'm hoping more people contribute to it organically and inspire further discussion. I would love if anyone reading this post would submit any constructive thoughts in the Doc, especially since I don't have comments.

Thanks for reading. Cheers.

Hipsterbrown

P.S. There really should be a better way to have the type of open discussion I started with Ben. Using a collaborative Doc or GitHub issue is kind of a hack for the real solution, because someone ultimately owns that issue or document, and/or the medium isn't open enough for everyone to contribute. There was a service called Branch that was pretty popular about two years ago until Facebook acquirred it and rolled it into their platform (even though the old Branches still exist). It had the nice format of conversational comments you find in GitHub issues and the accessibilty to anyone like Google Docs, but completely focused on open conversations. Quora is the closest alternative I can think of, but the user experience is too focused on sign-ups before any content is shown and the amount of emails received after signing up just isn't worth it. So if someone knows of any good alternatives, please let me know.

Elevatr - A Better ScrollTo Plugin

Tue, 28 Oct 2014 00:00:00 GMT

The Convenience Product (Problem?)

Tue, 09 Sep 2014 00:00:00 GMT

#The Convenience Product (Problem?)

I've talked before about Designing for Convenience, referencing the Pebble smartwatch in particular as a convenience item. Then, a couple days ago, I found out about Jibo, another crowdfunded tech product that is also an item of convenience rather than necessity. Even though its developer editions won't be released for over a year from funding, I predict the evolution of this product will be very similar to how Pebble has grown in the market since its release over a year and a half ago.

First, tech items of convenience. I knew from the moment I saw the Kickstarter video for Pebble that it would be an awesome companion to my smartphone and offer some great conveniences to my everyday life. It is not a device I need to communicate, travel, or stay productive day-to-day, like my smartphone; it offers me shortcuts for controlling the music on my phone, glance-able notifications, and a few other simple functions like alarms or step counters. While I feel a little weird when I leave the house without it, I can function in the real world without it because I would just need to pull out my phone to do the exact same activities. I think it's pretty clear what I mean as an item of convenience.

Now, I see an item like Jibo that falls pretty clearly falls under that definition as an item of convenience due to its abilities and disabilities. Like Pebble, Jibo offers a shortcut to common smartphone functions like notifications and quick controls to things like music and cameras. Jibo also has its advantages with audio input & responses and an AI (Artificial Intelligence) to custom the experience for the each user. Its disadvantages are mostly portability and cost. Jibo only lasts about 30 minutes without being plugged in, which means it won't shut down while being carried around the house to wherever it is needed, so including that fact with the $600 price point and Jibo becomes a household appliance rather than a mobile device like a smartwatch. The intro video shows Jibo being used by families and single people alike, to show off its various use cases, however spending $600 on something that sits at home all day may not be as beneficial for the single life as it would for a family.

Pebble and Jibo also have another large similarity that comes down to software and business. Like Pebble, the Jibo company will provide the hardware and basic software to sell to consumers, but the sustainable business model comes from extra content and applications that are purchased throughout the lifetime of the product in order to extend its functionality and usefulness. This is how Amazon is justifying their hardware products, like many other large tech hardware sellers, but there is a common Catch-22 that comes with starting this type of business. Without people to make the quality content, no one will buy your product, i.e without its fantastic community of app developers, Apple's iDevices would not have survived for as long as it has. It doesn't always follow the Field of Dreams philosophy*.

*If you build it, they will come.

Once Jibo's developer edition is released, there will be the exuberant group of software developers who will launch the development kit and start hacking on simple apps to test the system. Many of these apps will circulate this small group of early adopters and get the ball rolling on building an initial store of content for Jibo to promote when they start shipping the consumer editions a couple months later. As consumers start to explore this basic collection, they will blow through them quicker than developers can produce new and exciting content. Because Jibo can't sustain making all the content themselves, they will have to do what Pebble has started doing lately—working with well-known companies to integrate their products with Jibo software. For example, Pebble has worked with services like Foursquare, Runkeeper, and Evernote and companies like GoPro, ESPN, and Mercedes to create premium, free apps to draw interest to their product.

The one step I have yet to see Pebble take is making their software community profitable. There are very few paid apps or watchfaces in their store, and I don't think it's even possible to pay for apps through their store so the payments usually are usually for the companion smartphone apps. Without a profitable outcome for the developers, there is no incentive to put in the time and effort to integrate with their existing mobile apps or even create totally new ones. If Pebble, or Jibo, can't produce a profitable ecosystem for app and content creators, then sustainability is a pretty unlikely goal.

I'm sure the fine folks running people and the small team at Jibo are thinking about these all the time as they develop their products and businesses but I wonder how many other potential entrepreneurs do as well. I don't have any definite solutions for building a healthy developer community and booming content system around an indie tech product, but a great place to start is the open source community. There are so many open source projects that have enthusiast contributors and users because they are managed so well out where everyone can see. I take note of projects like Hoodie and Ember.js and companies like &yet, that all work hard to support their open source ecosystem.

All in all, I'm happy to see innovative and creative projects like Jibo get funded by the public because it moves tech forward. It's a very ambitious goal to ship the initial batch of this complex in a year and change, so I wish that team all the luck and look forward to the final result.

The Other Side of Empathy

Sat, 05 Jul 2014 00:00:00 GMT

The Creativity Commitment

Fri, 20 Jun 2014 00:00:00 GMT

If there was any downside to not being in school anymore, it might be that there is less external motivation to create anything anymore. As much disdain I may have had towards those reports and group projects, they were new things I produced by my own design; although I've never had issues pursuing personal side projects either. So, without push of higher education, I have come up with a guideline to keep up some creative consistency.

I have made a commitment to creativity in my post-collegiate life, and convinced my roommates to join me in this endeavor. There is only one rule:

create something on your own time, once a week It's a simple task, which can lead a superb feeling of accomplishment after seeing how much you've done over a short amount of time. For example, I live with two English graduates—two people who spent 4 years producing more written work than I ever did in my entire educational experience, so this commitment should be a piece of cake. They can outline a story, craft of poem, or even write a book report, but they are not tied to their literary leanings. Just as long as they are producing something they can be proud of, I will be proud of them.

For myself, I have sought diversity in my creative endeavors. Since it has to be on my own time, none of the professional work I do can count towards my submission each week; so I've chosen to pursue different outlets such photographing my new neighborhood, contributing to open source projects, sketching potential side projects and perhaps hacking them together on occasion, and also keeping up with my roomies in the writing department through this blog.

Some weeks I may end up with a dozen creations to share. Other weeks I will have to force myself to keep up with my commitment because I know I will appreciate in the end. Sharing this pact with others will help when internal motivation is just not enough, as well as validate the work we do together. I look forward to witnessing what we can accomplish over the next year and beyond.

Thus, with the publishing of this post, I have submitted my contribution for the week.

Thank you for reading. Now go and make something.

Apples & Oranges

Wed, 11 Jun 2014 00:00:00 GMT

It's been over a month since I graduated from college, and now I've made one of the biggest changes in my life by moving to New York City after living in Florida for so long.

I have grown so much after living in Orlando for nearly four years. Half of that came from my first two years of intense involvement with various organizations and UCF. The other half came from reaching out into the Orlando community and the connecting with the people & businesses there. It was that most recent bit of growth that really inspired me to reach out further and join one of the largest tech communities in the country. It was people like Dan Denney, Robb Schiller, Roman Rusinov, Mark Bunker, and really everyone at Envy Labs who motivated me to keep exploring and connecting to the community at large. Events like Design Orlando, Orlando Tech Meetup, Front-End Orlando, Node Orlando, Startup Weekends, and the Front-End Design Conference showed me how great it was to see people coming together to discuss things they care about and push the web forward. I will miss those people and events, but I will not forget them or where I started in the City Beautiful. All I can really say is thank you, I will return one day.

I moved to New York purely for an adventure; I already have a remote job, so I could have moved nearly anywhere without worry of income. But I chose New York because of the ability to explore the rich community and culture inside the city and the surrounding areas, especially through the ease of public transportation. I chose New York because I have lived in Florida my entire life and wanted a change of scenery while I am still free from physical ties to one location. I chose New York because of its history of residence who innovated and persevered through whatever hard times came their way. Living so far away from Florida reduces my safety net of staying home until I find something more secure; it forces me to take on the world right away. It will come with new challenges, but it will also come with new meetups, conferences, opportunities, and lessons I can learn from. Frankly, I'm still a little shocked that I've made it, even after 6 months of planning.

New York is just one stop on the road ahead, however. As I've said before, I'm at that time in my life where I can explore so freely. I believe the best way to do that is to live in an area for a few years, rather than just visit for a few days. After two or three years, I may want to live somewhere in Europe like England, Germany, or Switzerland. My love for the web and tech grows as I discover there are so many places I can go and keep working to make awesome stuff for it. I will not plan too far ahead because I have no clue what may come but I am ready to adapt and keep on creating.

Keep an eye here as I'll be writing a lot more ( that's the plan at least) and posting links on Twitter. Thanks for following.

Stay Hip.

2014, My Year of Workflows

Mon, 27 Jan 2014 00:00:00 GMT

Workflow and Process are two rapidly growing subjects in the past year as tools like Grunt became more powerful and GitHub grew to the max.

I wanted to write about efficient workflows for my first post of 2014, because I’ve been reading JavaScript Application Design¹ in its early stages. It discusses the use of Grunt and other techniques to create a more streamlined workflow of developing modern web applications with JavaScript. Even Chris Coyier has done screencast covering this topic on CSS-Tricks².

After giving some thought to what I wanted to accomplish this year, I decided to go fairly general and say I want to improve the workflows of all the tasks and chores I handle day-to-day, I want to streamline my daily tasks the same way I would streamline my various web projects.

Even as I write this post, I am thinking about how I could efficiently place links for greater reader retention and easier comments for later editing in Byword.

Photo and Data Management

This is a huge area of concern for me because I tend to download so many things and forget which folder/directory/backup I placed them in, or, worse, I leave it all in my Downloads folder like the junk drawer in my kitchen.

So when I bought a new computer last month, I made a conscious effort to create a better directory structure with clear names for easy eye-scans through Finder.

I also have to thank Dan Denney for showing me the awesome power of Alfred³ for quick-launching applications, opening files, and solving simple math bits. I know there are more hardcore users who take advantage of Alfred's workflows, but I've yet to dive that deep into the tool.

I was storing a lot of this data so I could access it anywhere, and was quickly running out of space, using all the free options in the various popular cloud solutions like Dropbox, SkyDrive, and Google Drive. But, being the cheap bastard that I am, I didn't really want to dish out the monthly cash to access only a fraction of what I needed.

Luckily, my slight Kickstarter addiction saved the day, as I discovered a project that seemed to solve my problem perfectly. Space Monkey⁴ aims to simplify cloud storage and make it more affordable for the common man by spreading the servers to the people as nifty little desktop devices. After purchasing the device, for the price equivalent of 20 months of 100GB of Dropbox storage, I have 1TB (that's 1000GB for those counting at home) for $5/month after the first year. Even though the software behind the device is still in its basic stages, it's improving all the time and super convenient. That's just my little unofficial plug for them, I look forward to seeing how this product improves over the next year.

Design and Development

Since my livelihood is dependent on how well I create for the web and beyond^TM, I'm always thinking about how I can streamline my work processes.

Entering 2014, there are a ton of great tools and services across the internet to help simplify and automate all the menial tasks we do as designers and developers. Whether you're compiling, concatinating, compressing, linting, or even deploying code, tools like Grunt & Gulp make life so much easier and allow web workers to spend more time focusing on writing code.

side note

I was fortunate enough to start a new job⁵ that dumped me into the Grunt pool at the beginning of the year, so I learned by doing on a full project (which is really the best way to truly learn anything in my opinion), but you don't have to take the plunge that way. My favorite resource so far has been Chris Coyier's 24ways article⁶—plus the Grunt community is growing so fast that there is bound to be some friendly dev out there willing to anwer any questions.

Along with Grunt, I have made an effort to conquer my fear of the command line and the great tools, like git, that come with mastering it. Starting slow with a few basic bits of version control like starting a local git repository for a personal project and moving on to pushing my work to a remote repo on GitHub. Now if the past sentence sounded like a Geek to you, check out Try Git⁷ from the good people at Code School. Leveling up from there would involve checking out git hooks for simple deployment to a staging server before pushing to production, all the stuff of an efficient Front-End Operations Engineer⁸. It may seem like a lot to do right away but remember it's just the beginning of 2014, so take a deep breath and take your time.

As for my design workflow, I continue to be satisfied by my experience with Sketch⁹ for mocking up various designs or creating icons and other design assets. Anyone who has ever spoken to me about my static design creation knows that I have been enamored by Sketch since I started using it about a year ago. It's extremely cheap compared to industry standard applications (cough Creative Cloud cough) and it's developed with the modern web worker in mind—it has the ability to export CSS stylings and awesome font rendering (looking at you Photoshop). The best part is the fact that it's continually being improved upon by the small team at Bohemian Coding, so if there is a problem, just ask and there is a good chance they'll work on it. But I digress—so my only wish in this area of my workflow is to get better at using Sketch for illustration purposes and organizing my files once they're exported, and that mostly relies on my personal discipline (more on that in a bit).

Task Management

This is another huge area for improvement because I'm finishing up my final semester of college while working a full-time remote job and finding time for personal projects too. I've used several iOS apps in attempt to solve my tasking needs but nothing seemed to be the right fit, until I tried out Trello¹⁰. Trello has the convenience of editing my boards of tasks from anywhere via the web or mobile apps and allows me to collaborate on boards with my team for our client work. Best of all, it's completely free to use. I've even started using it to store an inventory of my groceries to plan my meals for the week and keep track of what needs to be picked up from the store.

But even with all the reminder notifications, it's ultimately up to me to follow these personal deadlines with extreme discipline. There is so much to distract me from completing a school assignment, blog post, or work design—especially since it's all done online. The latest design/development/tech article is constantly streaming through my Twitter Timeline, Netflix is just a few clicks away with a whole slew of new titles for 2014, and Steam sits on my dock begging to be opened for a couple rounds of Team Fortress 2—such is the wonder and the danger for anyone who spends the brunt of their time online. So keeping myself focused on the task at hand will be the greatest test of my commitment to the Year of Workflows.

Money Management

As a young adult preparing to leave his last college apartment for the real world come in May, money management is vital. Not that I spend my weekly wage and student loans willy-nilly on extravagant nights out or weekend trips, but there is still quite a bit I can do to keep control of my spending habits. I've attempted this mission a few times in my college career by trying out tools like Mint and BillGuard. Mint just had too much going on for a person with zero credit cards, investments, and monthly bills besides rent, and BillGuard had a fine iOS interface but the web side was sorely lacking. Thanks to the open thought process of Marco Arment doing his taxes, I stumbled upon the free accounting apps of Wave¹¹ that were just right. They also have things like invoicing and payroll, but all I needed was something simple for my personal finances, so Wave seemed perfect at first glance. So far, it's been a pretty enjoyable experience from the web app and mobile receipt tracking app for when I use cash instead of my debit card. It helped me set up a straight-forward budget and lets me verify each transaction before they are added to the monthly total. I've enjoyed it so much, I'll probably end up using their invoicing app should I ever take on any freelance work.

Site and Musing Management

This has been a topic sitting in the back of my mind since I finished re-building my site last spring (a common curse of a web designer to always be improving). At the moment, my site is mostly static with minimal PHP for templating and the blog is powered by the super lightweight AnchorCMS¹². But I've gotten tired of PHP for personal projects, especialy once I was caught up in the KickStarter campaign for Ghost¹³ and saw the awesome conveniece of Jekyll¹⁴ for super simple static site generation. So as soon as I find the free time, I will working on rebuilding the static side of my site using Jekyll templates. A primary driving force behind this decision is to manage my portfolio a bit easier. At the moment, the items in my portfolio link to an external resource, but I would rather have a more in-depth explaination within my site, thus Jekyll is my chosen solution. My decision to use Ghost for my blogging efforts lies in its JavaScript DNA, lightweight nature, and consistent development. I've really enjoyed following the Ghost team and look forward to the plans they have to make Ghost the best blogging platform out there.

I will attempt to make the transition to these new frameworks/platforms as smooth as possible for the millions/tens of visitors that enjoy my Hip Musings^TM every week but things will certainly be bumpy at some point. I plan to write about my experience nearly every step of the way. Stat Tuned!

Wrap Up TL;DR

As I continue to charge confidently through 2014, I am making my vow here and now to stick to the life of workflows to streamline my management of money, data, photos, projects, and time. If you have some awesome workflow tools or unique strategies to stay focused, please reach out to me on Twitter @HipsterBrown or email me from my contact page.

Links for Days:

¹ JavaScript Application Design ² A Modern Web Designer's Workflow on CSS-Tricks ³ Alfred ⁴ Space Monkey ⁵ It's All Who You Know ⁶ Grunt for People Who Think Things Like Grunt are Weird and Hard ⁷ Try Git ⁸ Front-End Ops ⁹ Sketch by Bohemian Coding ¹⁰ Trello ¹¹ Wave ¹² AnchorCMS ¹³ Ghost - Just a blogging platform ¹⁴ Jekyll

It's All Who You Know

Tue, 24 Dec 2013 00:00:00 GMT

Good news everyone! I finally found a full-time job as a front-end developer, starting in 2014. It's been quite a hectic semester for me, looking for some sort of employment in the industry before I graduate next May, and I am happy to say I found the perfect job to get started. After all the fuss over perfecting my résumé, fine-tuning my portfolio, and sending out the most personalized cover letters after scouring AuthenticJobs for hours at a time, I was surprised to discover it actually was, as the title implies, who I knew that finally landed me a job. I honestly believe it's the best way to find employment for almost anyone in any industry.

Getting to know people within my chosen industry started with Twitter and a bit of Googling. I began following local web agencies and consulting shops, who would tweet about upcoming meetups and events discussing the various aspects of the industry. So I would attend those events, like Startup Weekend, and meet like-minded folks who enjoyed creating awesome experiences for the web and beyond. Ever since last November, my involvement with the web community at large has snowballed into attending my first conference, where I met the most amazing designers and developers like Dave Rupert and Chris Coyier, and giving my first design talk next month. Every experience has further cemented my passion for being a part of the infinite collective that is the web.

Over the past year I have done many things to improve upon my hard skills as a designer and front-end developer, including rebuilding my entire personal site and blog (with plans for some tweaking coming soon), but my soft skills have also aided me even more in making numerous connections that evertually led to my current employment. The projects found in my portfolio, GitHub, and CodePen are all great for proving that I can complete the tasks required by prospective employers; however, it's the words of my acquaintances in the industry that are more powerful than pictures and demos when it comes to finding the perfect position with a company.

So as the new year draws closer, I am so very thankful and appreciative for everyone I have had the chance to interact with during the last 12 months. I know each person has influenced, in one way or another, how I proceed with my chosen profession, and I look forward to meeting many more people in 2014 as I graduate with big plans ahead.

Take action, make friends, and keep in touch because you never know where that connection may lead you.

If you want to stay in touch with me, you can just mention me on Twitter or shoot me an email anytime.

Cheers and Happy Holidays!

Remote Work Confirmed

Tue, 10 Dec 2013 00:00:00 GMT

##My Remote Background I started doing remote work without realizing it until after the job was done. I was doing the brunt of writing for a small science and technology news site called Gizmocrazed. It was an English site but the founder was based in Pakistan, so all communication was done via email or What's App (my first time using it) and at odd hours of the night or morning due to the 10 hour time difference between us. All in all, it was an exciting new experience of working wherever and whenever I felt like, as long as the work got done. My previous work experience was very hands-on and location-dependent as a food, retail, and university orientation employment usually is. Sure the pay was less than mediocre but it was worth so much more because it showed me a new path of independent employment, and I could look beyond the area around my campus for a part-time job.

From there my remote work experience snowballed as I started working as a campus representative for that fruit-filled tech company over in Cupertino, which was definitely a much more official form of employment. I was classified as a remote corporate employee (complete with badge access)— I set my own hours, meetings, and whatever else was required to complete my job. It was by every definition-as found in the 37signals book-a remote job, complete with face-to-face video meetings, WebEx conference calls, and trips to corporate for some hands-on collaboration and training.

During that time, I took on another job where I was not a remote worker—instead, I aided in the remote process by setting up technical resources for a construction company's managers all around the state. Being on that side of the process made it clear just how much work goes into keeping the remote operation smooth and successful. It also made clear how terrible commuting can be when the first part of your morning is taken up lethargically moving through traffic for 45 minutes, only to experience it again after 8 hours sitting at a desk.

Even my education had a remote component to it, especially during the latter part. Attending a university with a boasted population of around 60,000 students is great for the variety in the vast community, but it also means large, packed, video-streamed classroom or soley online with no face-to-face interaction with the professor or other students. The advantage to the e-classroom environment was the ability to work from anywhere, as it is with most remote work; however, as it is with university education, it was easy to ignore the responsiblities of an online class when it wasn't a particularly intersting subject but required in order to graduate. Online education tools aren't always as cutting edge as those for the modern remote worker, which makes the task a little less convenient as well.

It's is clear that I'm no stranger to most aspects of remote working. I recognize the advantages and disadvantages of working away from the main office, although I believe there is a heavier weight to the pros side of the eternal argument. Comfort, trust, and retention are all strong attributes for a successful and productive working environment when the alternate is considered and empowered. But everything is to be taken with a grain of salt, as no one person's perfect working situation can reflect the rest of the population. So choose remote work because you can, not because it's popular or you have to.

##Remote, Office Not Required — A Review I pre-ordered Remote when the call initially went out on Twitter from Jason Fried, mostly because I enjoyed their first book - Rework - so much. I'm no stranger to waiting for a product to be fullfilled, as my Kickstarter profile can probably attest, but waiting for Remote to be released was nearly unbearable as the subject of book was becoming wildly popular and controversial.

I was such a fan of the layout of teaching Rework employed, it was great to see Jason and DHH continuing that style in Remote. The entire book reads like a collection of blog posts accompanied by unique, brilliant illustrations done by Mike Rhode. Chapters are filled with sub-chapters focused on a new aspect of their parent subject. Having numerous real-world examples and stories kept my interest and clarify how various people experience remote work in their unique way.

It is certainly a book one could easily finish in a day or two, although I took my time traversing through its contents, but it is also a resource anyone could just flip through randomly and learn something, i.e. the perfect coffee table book.

Overall, the book covers the subject of remote work pretty completely, pros and cons, and serves as a great tutorial for anyone looking to get into that style of employment. And for the holiday season, a smart gift from to your boss if you think remote work is right for your current workplace. You can pick it up on Amazon in hardback and ebook. I highly reccomend picking up a copy, even just to fill a space on your bookshelf.

Design for Convenience - A Pebble App Design

Wed, 06 Nov 2013 00:00:00 GMT

Pebble apps started off as fun and cheap tricks for a few minutes of amusement—now, that the platform is evolving, and it's time for those apps to start evolving too. This blog post serves as my personal guide on what Pebble app makers should consider when creating fantastic experiences for this new medium on their wrists. I have even included a proof-of-concept Pebble app design combining my favorite smartwatch and Twitter client to create Pebblebot, a companion app for powerful Twitter notifications.

The adorable Pebblebot icon

##What's Your Watch For?

Ever since I first got my Pebble in the mail, even before then, I've kept tabs on what awesome app ideas were being shared and created by the great community surrounding this product. Then I started using some of the basic ones that were being shared through sites like My Pebble Faces and Pebble Barn, but most of those apps stayed on my Pebble for about a week or less because I had no need for a counter, timer, or magic 8-ball app to constantly reside on my watch. After the release of httpebble, app developers could now communicate information from iOS and Android smartphones to Pebble and create "smart status" applications. It sounded great to always have the current weather, stock price, battery life, and the time available without taking your phone out of your pocket! Yet, I still went back to a standard watch face and music control app for day to day use of my Pebble because I constantly needed to check if my Pebble was still connected to the third-party iOS apps. The thing that was really missing from all these third-party applications was thoughtful, emotional design—so I set out to discover what that meant for that tiny screen hanging out on nearly 200,000 wrists worldwide.

The first thing I realized was that Pebble is a device of convenience. Its users don't need it—they can get all the same tools and information from the smartphone sitting in their pocket. They bought a Pebble so they could control their music or see the latest phone notification conveniently from their wrists—because that power over their mobile devices felt so magical and unique. That is the exact same emotion and convenience that needs to be evoked in the design of other Pebble apps. This initial revelation led to the idea for Pebblebot, giving its users more control over their Tweetbot notifications but nothing that couldn't be done by pulling out their phones and opening the app.

##Good Design is Invisible

If you're a designer, you've heard that phrase at least once in your career and it's an intense philosophy to follow when drawing your ideas in Sketch or Photoshop— it is a philosophy of convenience and letting the design get out of the user's way. This was the path I took when creating Pebblebot—it would be invisible to the user until it was needed. Some of the inspiration for this idea came from the RunKeeper app embed within the Pebble firmware. It only comes up when you start a run with the iOS app and hides again as soon as you're done with it. It adds the convenience of knowing your current pace and time, as well as being able to pause the activity without taking your phone out of your pocket, backpack, or armband.

Pebblebot would be an in-app purchase for Tweetbot for iPhone customers who want an equally awesome Twitter experience on their Pebbles. Unlike the Twitter apps that currently exist in the smartwatch ecosystem, it would not just show the latest 5 or less tweets on screen because that means the user had to go through at least 2 button presses and press a few more buttons when they wanted to refresh the feed. Pebblebot is all about notifications and giving the user to do something with them just as soon as they receive them.

For example, I get a Mention from someone and this would show up:

From that screen, I can instantly Retweet or Favorite that Mention without ever touching my phone. Should I choose to Reply to the Mention, I can press the middle button to activate an alert asking me open my phone, taking me straight to the Tweetbot Reply screen. All three actions available to me can also be done by taking my phone out of my pocket and using the Tweetbot for iPhone app, however, I saved a few seconds and a little hassle by using my convenient watch app. Other users may be fine just seeing a notification from Twitter and waiting until later to respond in some way but instant gratification is the popular stigma in this day and age.

##Keep it Simple Stupid

The greatest thing about Pebblebot is its utter simplicity in design. It's mostly a text-based interface with a few recognizable icons to symbolize its essential functionality and that is only when it is needed. With the notifications that one of your tweets has been Favorited or Retweeted, the screen is nearly identical to a normal Pebble notification:

These screens are designed for maximum readability and shows all necessary information but needs no additionally functionality like the Mention screen.

Also keeping to the theme of simplicity is the fact that none of settings for the watch app is found on the watch, rather all of that control is held within the Tweetbot app settings, including the ability to buy the Pebblebot. Because Pebblebot is a notification app, it is logically controlled under Tweebot's Notifications settings as shown below:

Once Pebblebot is bought and downloaded to the users smartwatch, they will be taken back to the Notifcations screen again to ensure their Pebble is connected to Tweetbot and given additional controls for that functionality.

The user's Tweetbot notifications can remain independent of their Pebblebot notifications, just as Pebble's notifications can remain separate from your phone. The ultimate goal of staying simple and beautiful is always kept in mind.

##A Little Something Extra

During the creation of this app concept, I thought about what feature could make Pebblebot a truly powerful and useful watch app for the die-hard Twitter users. The idea for this added functionality stemmed from a feature that has been a part of Twitter for a while, albeit poorly implemented on their side. The final feature of Pebblebot you may have seen in the Tweetbot screens above—presenting the Pebblebot SuperFollower notification, a.k.a stalker mode.

Just like the Mention screen, the user is given the ability Favorite, Reply, or Retweet anyone they choose to stalk/SuperFollow via their Pebble. Twitter has tried the same thing via text messages or their own mobile apps, however the settings and control over that feature is complex for most users to figure out. In Tweetbot, once you have connected to Pebblebot, you can go to any user's profile and have to ability to SuperFollow them in the same action as you would follow them normally in the app. Shown below:

Then, should you grow tired of that user's constant Walking Dead live tweeting, you don't have to navigate back to their profile—instead, you can go to your Notification Settings and tap SuperFollowings:

Through a simple swipe gesture you can temporarily disable a user's SuperFollow notifications or remove them entirely from the list. This is a much better way to control this feature, rather than going through an entire following list trying to remember which once you've chosen to SuperFollow.

##Wrap-Up

Overall, Pebblebot is the best representative for how Pebble can be integrated with the powerful services already found on our smartphones. It is not trying to reinvent the wheel by replacing these services—it just turbo-charges the vehicle for a little added fun. Pebble is already doing great things by working with third-party services and improving the SDK for better two-way communication. It all makes me so excited for the future of this medium, and I hope that Pebblebot can serve as an example for other Pebble app creators to follow for their next development project.

Finally, Pebblebot is merely a figment of my imagination. I have neither the skills or resources to make such a product possible, but if you really wanted this watch app to exist, be sure to bug @Tapbots_Paul, @MarkJardine, and @Pebble on Twitter and show them this article. Or you can just share it for the sake of sharing. I would love to hear anyone's thoughts on this concept in the comments below, on Twitter (@HipsterBrown), or via email from my Contact page.

Cheers and thanks for reading this post, or at least looking at all the pretty pictures. Stay hip.

P.S.

I've added my slides from my talk at Design Orlando to SpeakerDeck here.

Visual Design in the Browser

Thu, 17 Oct 2013 00:00:00 GMT

There is a style of workflow in web design called designing in the browser¹ that has designers re-thinking the way they do their job. The basis of this idea is to skip the wireframes and static mockups in Photoshop, Sketch, etc, and start directly with code—usually within the console of the web designer's preferred browser. Some of the greatest advantages of following this philosophy is saving time, keeping the design process DRY (don't repeat yourself), flexible & responsive environment, and instantaneous prototype testing. So while the wireframes and UI design responsibilities is has been passed on to the browser, tools like Photoshop are left to handle the visual design side of the web, i.e. logos, icons, and illustrations. However, I think that can start to change as well.

I was first inspired about visual design in the browser while reading an interesting article about creating geometric patterns in Illustrator², and I thought about how much easier this would be in Sketch—then how much easier it would be with HTML & CSS. So I spent some time in CodePen, making some CSS magic with a little help from Sass and Borbon in order recreate the article's first example without any images. The end result was this:

See the Pen Cubical Pattern Background by Nick Hehr (@HipsterBrown) on CodePen

CSS certainly has come a long way from just changing basic color and size changes in web design.

That pen got such a nice response from the CodePen community, I decided to finish off the article's examples with a second recreation in code:

See the Pen Triangular Pattern Background by Nick Hehr (@HipsterBrown) on CodePen

These pens were so much fun to make, partly because they look so great and partly because they helped me flex the ol' creative muscle when thinking about how to solve this challenge. Nowadays, with the right amount of creative thinking and knowledge, you can create works of art with code. With that thought, I wondered why visual design couldn't move to the browser as well. As I continued thinking, I realized the numerous advantages of following this visual design practice.

Visual design in the browser leads to:

~ less http requests, just one solid style sheet
~ lighter pages & speedy load times
~ quicker design changes on the fly, i.e. color, size, and layout.
~ the ability to add additional animated effects for interactive emphasis
~ always Retina/HD/4K ready assets

This doesn't replace the visual designer—rather, it challenges the front-end designers to think outside the box in order to implement the visual idea conceptualized originally by the visual designers and illustrators. And of course, not everything can be done with some fancy CSS, but there is a surprising amount of things that can be accomplished. I have even started a Collection of visual design examples³ on CodePen to showcase the ability and ingenuity of brilliant front-end folks in that community.

So the next time you get an image asset of a simple company logo or a set of navigation icons, why not try to go the extra mile and build them with all the power a modern browser provides—then share them with the community through sites like CodePen so we can all learn together.

My last example shows the simplicity and ease of generating the CodePen logo and icon with some CSS. First, the vector image I did fairly quickly in Sketch

Then, the demo because it did happen:

See the Pen Sassy CodePen Icon by Nick Hehr (@HipsterBrown) on CodePen

If you do come up with your own awesome examples, feel free to share them with me on Twitter @HipsterBrown or tag them on CodePen as "hip visual design" and I'll add them to my Collection.

References & Resources

¹ Tips for Designing in the Browser

² Veerle Pieters- Creating Geometric Patterns in Illustrator

³ A Collection of Visual Design Pens

CodePen FTW

CSS Shapes Guide on CSS-Tricks

Free Is Nice

Wed, 09 Oct 2013 00:00:00 GMT

There is a considerable amount of free stuff on the Internet: videos, pictures, apps, books, and tons of information. I've definitely viewed and downloaded my fair share of content, but I haven't really given much back in return. So I while procrastinating on a personal project, I came up with a two things people might like to use. So now I'm putting them out on the web for free, along with a brief explanation of the process behind their creation.

iOS 7 Icon Grid

Since iOS 7's announcement and recent release to the public, one of the greatest bits examined by app makers is the new icon style.Not only are there new standards about the use of graients and realistic elements (something Instagram chose to completely ignore but I digress) in iOS 7 but a whole template was provided by Apple for icon designers to use so all the apps on your screen have a perfect visual flow. However, "provided" is a funny word because while Apple has plenty of pictures of this template, but they never released any sort of assets for designers to actually use in the creation process, i.e. Photoshop/Illustrator or Sketch.app templates. That left it up to people like Marc Edwards of Bjango to make these assets for themselves and the community. Marc is part of the majority that still uses Photoshop as their main design tool but Sketch by Bohemian Coding is starting to gain popularity, so it's about time assets were created for that community as well.

So I took an afternoon to make my own iOS 7 Icon Grid for myself and the Sketch community, and even practice using it too.

Prior to this undertaking, I had no experience with iOS icon design and minimal experience with Android design (something left for another story about how many apps are doing this wrong). As with most new projects, I started with a little research and learned about the new dimensions for iOS icons in order created a new artboard in Sketch. Most of the design process was eyeing a picture of the template online, open side-by-side with Sketch, and experimenting with all the different elements of the grid until something cohesive stuck. I finalized the product by grabbing the .png I was viewing, dropping it into Sketch to overlay my grid with it, and tweaking my grid until they matched.

I tested the grid out by making a quick app icon using my personal logo, and tweaked that image until it worked within the grid's golden ratio.

Overall, this was an interesting exploration into the area of icon design for Apple's latest mobile operatng system. The OS is still so very young so some of the older apps feel resistant to the change-Instagram- but the lack of visual flow with the rest of the interface will leave them buried in one of the infinite folders in the depths of users' homescreens.

Ink & Paint iPhone Wallpaper

The second freebie started out as an idea just for a simple illustration or icon inspired by Disney animators and turned into my first experiment making wallpapers for the iPhone.

The Inking and Painting Building is a vital stop during the tour of Disney's Animation process. My typographical inspiration came from the lettering above the doors to the original buildings at the Walt Disney Studios. For other fans of the Disney creative process, I figured it would be fun to have a similar entryway to their phone.

Another technology that drew my interest for the project was the ability to create parallax backgrounds for iOS 7. Simply making your wallpapers 200 pixels longer and wider technically made them parallax-able. The real neat part of creating these types of backgrounds is adding elements that have their movements tracked as the user's phone is tilted in multiple directions. This motivated the idea of placing handmade ink splotches and brush strokes meticulously around the lettering.

The only snag I had with creating the custom typeface was the ampersand dividing INK and PAINT. Good golly miss molly, ampersands are quite the challenge for a novice at typographic design. I felt it would either make or break the message as a whole, and I certainly spent a majority of my time tweaking that one character every time I returned to the project. I eventually fell back to Google and found a great article about the History of Ampersands-- this is something I never thought I would find interest in a year ago.

I really enjoyed working on more of a static design for once, as opposed to my usual web work and worrying about the constantly varying size changes. Being able to work with several different design elements helped me find a new cohesiveness in my piece.

You can download all my freebies below, all I ask for in return is a quick share of the article so others can enjoy this content as well. Please reach out to me on Twitter or email me from my contact page if you have any comments or constructive criticism.

Thanks for reading and enjoy!

Download iOS 7 Icon Grid

Download 4/4S Wallpaper

Download 5/5S Wallpaper

The Future of Tech is In and Near Our Hands

Fri, 27 Sep 2013 00:00:00 GMT

It seems like every time I take a long car trip with my girlfriend, we start to discuss the latest in technical innovations and what might be the technology of the future. We each have our own sources of information about what is up and coming in the tech world. She listens to the Science Friday program on NPR and I read whatever interesting articles happen to appear in my Twitter timeline from the various tech sites/people I follow. I obviously have an upper hand when it comes to the latest news, while she gets a more curated form of information. With our combined knowledge, I think we have a good idea of what is to come for the technology we use day to day in the future.

First, a little primer of what other people are talking about before we take a peek into my imagination. Many of us have seen video's like Microsoft's Vision of the Future. This video has such a spectacular display of computer graphics and simulated innovation that it's hard not to believe that it could one day be real- especially if big companies like Microsoft are dreaming of it, too. I was in that same boat of believing that one day we could video chat halfway across the world with our transparent smartphones powered by a holographic display-- that is until I read a fascinating article by Bret Victor called A Brief Rant on The Future of Interaction Design. Bret presents an interesting point about Microsoft's vision: he argues that the video shows a stagnant view of the way we already use things, and that it continues to limit the way we use our technology. Why should we continue to learn new and unnatural gestures such as swiping, tapping, or pinching with just one or two of our fingers, when there is so much more that we can do with the rest of our hands that we have been doing for hundreds of years? Even in the rare cases when we do use our whole hand, like switching applications or screens on an iPad or Mac, we still accomplish just one task.

There is also a future in the innovation of screens. I don't mean increasing the resolution until there is an IMAX movie theatre sitting in my pocket. I'm talking about the machines that run the plethora of screens around us all the time. Right now, my two favorite screens are the one on my wrist and the one in my pocket. I backed the Pebble Smartwatch since the beginnings of it's Kickstarter campaign and have been wearing it nearly non-stop since February of this year (and I have the tan-lines to prove it). But after all is said and done, it is a convenience for me to wear a Pebble rather than pull my phone out my pocket every time I get a notification. My iPhone has become more of a necessity as I dive deeper and deeper into an always-online life-- it is the one thing I insist on having with me at all times and it powers some of the most important decisions I make every day. Now enough with the primer, let's paint a pretty picture of the future.

Picture this:

Wake up in the morning feeling like P-Diddy….Kidding, let's not.

I wake up to sound of my phone's morning alarm on my nightstand dock and the vibration of my smart cuff. The tap of my hand on the stand snoozes the alarm because the smartcuff around my forearm is within Bluetooth range. I roll out of bed and flick the air. My bedroom lights fade on, without blinding me. I swing my arms like I'm conducting an invisible orchestra and my morning playlist blasts from the bedroom speakers. My music follows me as I shuffle into the bathroom, and then I grip the air in front of me and turn my wrist clockwise. Water starts to pour of the shower head, and I adjust the heat based on the temperature readings on my cuff's display.

Alright stop- explanation time.

There are technologies coming to fruition that allow us to re-imagine how we interact with the technology around us, like the Leap Motion controller. Leap is essentially a tiny metal box of sensors that can track your hands and fingers in the air, so developers can program their desktop/web apps to use gestures like grabbing, thumbs up, or writing in the air for increased functionality. Elon Musk of Tesla Motors and SpaceX has a great video demonstrating how this can be used. Leap is still primarily for developers but, as you can see from that video, there is positive work being done to integrate this device with commercial software. However, this display interaction is not engaging enough because there still isn't any tactile feedback from the device.

Thalmic Labs has been working on an amazing gadget to fix the tactile problem called Myo, and the video on the landing page perfectly displays the incredible potential behind it. Myo is a forearm cuff packed with sensors that track the minute movements of your arm muscles and, by literal extension, your hand muscles. This allows for more finely-tuned gestures that motion sensors and cameras just can't compete with. The Myo could allow for haptic (tactile) feedback through the use of a vibration pack or micro-electric signals that simulate touch.

Now let's take a look back at the smartcuff that seemed to make magic happen during my morning routine. This cuff could be the future combination of technologies used by Myo, Pebble, Nike and Disney today. As an extension of your phone, the cuff would be connected to it via the latest evolution of Bluetooth, or similar tech, and constantly communicating your movements back to your phone for analysis and review later. Sensors similar to the ones found in the Leap Motion controller could be placed all over a house or building to translate your gestures into the operative task. This is particularly enterprising for the germaphobes who will never have to touch a questionable surface ever again.

Let's continue with my day:

On my way into the garage, I quickly brush my cuff against the fridge handle to receive an immediate inventory of its contents and what I may need to pick up at the grocery store later. I plug my phone into the dock compartment between my e-bike's handlebars and start pedaling to work. Once I get to the office and hang up my bike, I dock my phone to my desk and take a seat. Both of my monitors immediately light up with my desktop home screen- my bluetooth keyboard and trackpad glow briefly to signal they're active, and I get to work. About an hour later, my phone rings, and I see a caller notification appear on one of my monitors. I mime a phone with my cuffed hand, bring it up to my face, and begin speaking into my pinky to answer the call. Once the call has ended, I hang up my invisible phone and return to work. When it's time to go home, I pick my phone off the dock, and the monitors go dark.

So a few things happened in that last part. First, let's discuss the phone situation:

Over the years, the hub of the Apple ecosystem has moved from the desktop computer to the mobile device, thanks to iCloud. When iCloud came along it became the wireless hub where all your devices can stay in sync with other cloud storage services that store your settings, notes, photos, etc. As cloud storage continues to increase (you can get over a terabyte with some services !) and the age of the Superphone begins (a 64-bit smartphone is a big deal! ), what's to stop consumers from using just one device across multiple empty screens? While this idea is nothing new, the OS and implementation are not quite ready yet. Imagine owning a quad-core 64-bit phone with a couple gigs of RAM that you can dock to multiple screens via a universal connector and run truly responsive applications which give additional functionality for larger screens. This device would be constantly connected to the cloud to back up and store all the information you require and is always-online to communicate with the world of Internet-connected devices around it. With this technology, tablets and laptops would become portable docking stations containing enormous batteries that will charge your phone while in use. Imagine never again worrying about your files not syncing between devices, or mobile apps not having desktop counterparts.

Now about that phone call. When your phone is connected to another screen, what do you do when you actually have to use it as a phone? That's where the cuff comes in as the natural extension of the phone's capabilities. The theory behind using the hand-phone is the same employed by Bluetooth headsets today. The vibrations from your jawbone travel through your hand and up your arm to be accepted by the tiny microphone/speaker on the cuff, which then relays the info to your phone. As the person answers, the process is reversed and you have seamless communication.

Finally, the first interaction with the fridge. RFID is a small but powerful technology employed by many companies to relay information between devices, much like NFC except it is strictly one-way communication and works at greater distances. The theory behind the fridge's inventory system is an RFID reader in the door of the appliance that reads tags embedded in the food packaging to take stock of your latest grocery trip. It would be able to register expiration dates and nutritional information as well as take the initial weight from the scales integrated in all of the refrigerator's shelves and compartments to let you know if you're running low on milk, or if that milk has expired. Simply tapping the RFID area on the handle of the fridge with an applicable reader like the smartcuff allows instant transfer of information. *This is what we need in our refrigerators, Samsung/LG/GE, not the ability to tweet from the door. Notifications from our kitchen and washroom appliances could aid in saving water, power, and pots and pans forgotten on an active stove.

On to the final part of a day in the life of future me.

The work day is done and now it is time to enjoy a night out with some friends. We decide to meet at a local bar. On the way, I pass an ad-board offering 20% off if I like/follow/add their [insert new social media application here] page. Interested in saving a bit of money, I give the board a thumbs up with my cuffed hand and receive an instant notification of the coupon being sent to my email. At the bar, we all order our meals, followed by a couple rounds of drinks. When the time comes to settle our bills, the waitress brings over the e-bill pads, and we all tap our cuffs to the pad's reader and press our index fingers to the adjacent scanner to confirm the payment. After returning home from a pleasant evening out, I prepare for bed and wonder how we ever could have lived without such convenient technological advances.

OK, final overview. First things first--the interactive ad board delivering that helpful coupon:

Engaging and responsive ads are found all over the web, but they don't have to stop there. Seeing an ad you like doesn't have to mean taking a picture of the url or ugly QR code to remember it- instead, giving it a natural reaction like a thumbs up will delight users and advertisers alike. The instant feedback will also be enjoyable for the loads of ADHD consumers in the world who can't stand to wait for a delayed email confirmation.

The payment process would be a much quicker, more secure, and environmentally friendly solution than our current situation. Instead of handing over cash or a piece of plastic with personal account numbers out in the open and waiting for the staff member to return with it, we can shorten and secure the process by using the protective assets of our smart cuffs/phones and unique fingerprints directly. Fingerprint technology is evolving rapidly to become faster and more secure than ever before- just take a look at the newest iPhone. This two-step form of verification would be much harder to replicate and would save a lot of paper by reducing the use of wasteful receipts. Of course there will be speculation of reliability--but there always when such a radical paradigm shift is introduced.

I hope you enjoyed this little adventure into the (hopefully) not-so-distant future of consumer technology. I don't hold claim to the originality of any of these ideas, they are merely a collection of today's technology used in more advanced and convenient ways. Let me know what you think by reaching out to me on Twitter, shooting me an email from my contact page, or commenting below. I look forward to hearing your thoughts on the future as well.

A Personal Site and Delicious New Blogging Service

Sun, 15 Sep 2013 00:00:00 GMT

I'm always looking for something new to work on in my spare time because I can't help just not being productive, even after hours of class or work. This new project started out as a way to test out an interesting new blogging platform I had stumbled across called Postachio and the process of creating a personal site/blog around it. But as the project began to take shape, it became more about working on a personal brand and creative site with a blog attached.

When I said I stumbled upon Postachio, it was more like they had stumbled upon me, and more specifically, my Twitter. After mentioning to a friend the want to learn about the Evernote API, I suddenly got a new follower called @PostachioApp. Quite curious about what an "Evernote Powered Blogging Community" could possibly be, I took a quick look at their website. From my brief glance, this seemed like a novel, yet simple, idea.

Developed for the Evernote Devcup 2013, the folks behind Postachio had turned the universal note-keeping app into the perfect tool for drafting and publishing a blog post from nearly any device. I already use Evernote for keeping all my class notes in one place and drafting my Hip Musings, so the ability to publish those musings straight to my blog from my iPhone, iPad, Mac, or any computer from the web, astounded me. In order to test out the practical use of such a service, I really wanted to give Postachio a fresh, honest assessment, not just create a sample blog that I would never use since I had just rebuilt my current one. So it was my girlfriend's need for a personal website that inspired me to finally give Postachio a shot in a real world situation and create a personal site/brand for someone other than myself.

I started out the project as I do with most, in my Moleskine notebook with a couple a sketches.The greatest advantage I had by making this for Leah, my girlfriend, rather than a paying client was the amount of exploratory freedom because my girlfriend had almost no ideas for what she would like in her site, where a client would have some clue in advance for what they want. The inspiration for clouds as the central theme of the site came from a poem Leah wrote two years ago, which can be read by clicking the tagline below the clouds. I wanted to make the site a light, airy space for people to visit and enjoy just staring at it for a while, as well as a unique environment for visitors to learn more about her. The original idea for her personal branding was "Just Leah", honoring one of her favorite books called Just Ella, which also reflected her enjoyment of the Cinderella story with a modern twist. But she found the name too forcefully humble, and we ended up brainstorming a few more ideas until we thought of "Finding Leah." The brand can be used in various ways if she decides to expand the site and matches the cloud links of Seeker (résumé), Storyteller (writing samples), and Time-Traveler (book review blog) for visitors to find out more about Leah. I strived to make it interesting but not childish and capture the creativity that a writer's website should have.

From there I switched over to Sketch and started creating a quick mock-up of the site. I still enjoy making high-fidelity mock-ups to play around with colors, typefaces, and layouts much easier than going straight to the browser. I planned to use a stoic sans-serif for most of the display text on the site and a playful script font for her name. I eventually found Lavanderia from Lost Type and Dense by Charles Daoud. Dense seemed to fit everywhere except for the tagline, Head in the Clouds, so I ended up creating a lighter version using Sketch's vector text tool. I chose the blue background as it was Leah's favorite color and it went great as a pseudo sky for the clouds to cover. After the mock-up was approved, I exported my image assets and started work in Sublime Text.

This project was also an excuse for me to get more practice using Git and GitHub for version control. So as I set up my development environment with git, Sass, and Bourbon, I also set up a new public repository on GitHub to keep a back up of my changes. You can find all the source code here. I quickly connected local project with the GitHub repo and began creating the site layout.

As soon as the layout and styling matched the mock-up, I began implementing the more interactive elements that would make this site more appealing for its visitors. My initial idea was to give the clouds some life with some continual CSS3 animations. I tested out several different animation times, directions, and patterns until I got the alternating clouds just right so they were not distracting but still enticing. Eventually it came down to creating pages for the résumé and writing samples, which was one of the more difficult decisions of the project.

I could have easily made additional pages for the résumé and sample content to sit on and the clouds linked to externally, but that seemed so impersonal and dragged the user away for the main page. I had never created any sort of modal window for any of my past projects, but I figured this was the best time to try and implement one or two. Modals can be annoying for users just trying to complete a simple task and often times take longer than their worth to load in content. So I took a new approach to this old idea by having all the content loaded with the page, rather than loading it in later after the user clicked on the matching link, and created custom modals to bring that content into view when needed. Since it was just a small amount of information to add to the original page, it was worth the sacrifice of milliseconds during the initial load.

The layout of each modal was inspired by Google's well-known card style seen in Google Now and spreading to its various other services. I really enjoy the easy separation of unrelated content by using these cards to differentiate writing samples and résumé categories. It was also a clean and modern look that matched the blog and main page of the site. I added the download links for the writing samples and résumé so that potential employers could keep a record of their interest in Leah. The buttons were the only things not custom designed by me; instead I used Bourbon's great, built-in button mixin for Sass. I decided to design the modals in the browser because of the simplicity behind the design.

Finally, it came down to working with Postachio and creating the custom book review blog for Leah to use.

Signing up and getting a default blog up and running is fairly straight forward; just authorize Postachio with your Evernote account and you can start arranging your blog details within a minute. The blog creation form is short and sweet:

Pick a subdomain to host your site
Give it a name
Give it the blog author's name
Decide which Evernote notebook to sync all the articles with or create a new one
Choose what social media links to include
Hook up your disqus commenting
Decide whether or not to use Markdown I personally love using Markdown in my current blogging environment, Anchor CMS, and it is awesome for Postachio to give users more control of their formatting by including it.

Styling your Postachio blog can go one of two ways; you can either choose one of the pre-built themes or style it by hand by diving into the source code. I obviously chose the source code route for further control and soon discovered that the default theme is built with the Twitter Bootstrap framework and the Liquid layout language from the folks at Shopify. Twitter Bootstrap is a popular framework for developers to get their projects looking pretty with minimal effort during the prototyping stage, but the numerous naming conventions and fairly bulky size make it a little too much for running small blog, especially since Postchio is hosting all the accounts themselves. Targeting any of the blog elements for styling meant going into the Web Inspector and checking to see exactly what the developers called it. Once you got past that issue, you could be assured that the blog was mobile friendly because Bootstrap was in use. I did not see the use in changing too much of the format, it was mostly color choices, but it was probably more than the average user would want to try and figure out. It felt a lot like the old MySpace days when you found bits of code to paste into your site's customizing area and hoping it would work the way you wanted it.

My final thoughts for Postachio would be that it is a brilliant concept that just needs a little more work to make it one of the most popular tools for blogging. Lightening the browser load by dropping Bootstrap for a custom default framework would be beneficial in the future, not just for their users but their servers as well. I would highly suggest this tool over anything like Wordpress, which has become far too bloated for setting up a simple blog, but I do not yet see it as a tool for creating an entire website. At the moment users can set up multiple pages for free but the creators are planning on making that a premium feature later on. I think it is smart for them to be thinking in line with Evernote's pricing strategy, give a nice amount of features away for free and then create some really awesome features for the users willing to pay for them.

Ultimately, I felt the site was a success from start to finish. It gave me a fantastic new experience of working with a client to create a personal site that would interest potential employers and give her something she is proud to put on her future job applications. I will continue to maintain the latest writing samples and résumé for the site until I find a better way for Leah to implement them herself. Hopefully she will enjoy the use of Evernote to draft her book reviews and publish them to her blog from wherever she likes. Only time will tell but from my brief experience, I think it's the perfect tool for creating a custom, lightweight blog for clients to post to with ease. You can see the live project here and Leah's live site at LeahMarks.com.

Now it is time for me to get on to my next project, whatever that may be, and keep my eyes out for some more interesting tools to test.

The 3 L's of an Enthusiastic College Graduate

Thu, 05 Sep 2013 00:00:00 GMT

Location, location, location

With two semesters, aka 8 months, left before I complete my undergraduate curriculum and enter the scary, and very real, world of independent adulthood, so I've been thinking a lot about my post-graduation plans. As I scroll through the online job boards, 37Signals, Treehouse, and AuthenticJobs (my personal favorite), the biggest factor I take in from each posting is location. Sure the various perks offered by the more generous companies are nice to look at, and as a soon-to-be graduate in this day and age, I should just be grateful to receive employment from whomever is providing a steady paycheck and desk. However, as an ambitious student, I still believe my first job experience will be majorly impacted by where I'll be living.

A lot of my fellow graduates will try to look within their own state or an hour from where they graduated, thinking it's too risky to look much further than that. But that is exactly why they should branch out and look across the country or the world for the best opportunity. Our early 20s are really the only time we can easily pack up a couple bags of clothes and our computer in order to just move somewhere else. The majority of students who were detained to going to college in-state when they dreamed of studying abroad now have the freedom to take a chance and explore all of their options.

The city we decide to work in is not just that; it is where we make our friends, find our hangouts and hobbies, and start to figure out what we really want out of life. In Orlando, I have nearly exhausted all chances to discover anything new in the area. I have attended the downtown meetups, visited Universal and Disney so many times I've memorized the dialogue on The Mummy and Jungle Cruise, and even explored the surrounding wilderness while geocaching. There are still a few rocks left unturned but not nearly enough for me to stick around another 4 or 5 years.

I am fortunate enough to have a skill set that is universal to almost any region of the country and not restricted to just one industry. As I started to discover the incredible need for designers and front-end developers, I decided I would like to travel following my departure from higher-education. The bulk of my efforts are looking out of the country, due to the fact that I have never left United States outside a three day cruise to the Bahamas at the age of 10. Why visit Europe for a short and expensive stay, when I can instead be paid to live there and explore as much as I would like during my free time. The main arguments I've heard against this concern the paperwork required, the small flats I'll have to live in, and the lack of automobile accessibility, but these are paltry obstacles in the way of biking through the English countryside, watching the Eiffel Tower light up at night, and taking a boat down the Danube because they are all just a train ride away.

Side Note: As to my family members who may be reading this and wondering why I'm not too concerned about being so far from home during the holidays and birthdays, the Internet is a wonderful thing for instant communication; they even have this crazy thing called Skype and FaceTime for video calling! Plus, who wouldn't want to visit their son/nephew/cousin in Europe for Christmas or New Years? The five years or so will fly by in the grand scheme of things, and I'll return with plenty of souvenirs for everyone.

All that I want out of the city in which I live out my 20s is great public transportation, the ability to bike on real roads rather than highways, and cool places to see/things to do during my free time. Using these requirements, I have whittled down the list to San Francisco, New York City/New England area, and London/outlying area. These are not places where I plan on laying down my baggage for the rest of my life but they are certainly spectacular pit stops as I explore what life has to offer an enthusiastic, self-starting UI/front-end designer.

So I will continue my cross-country(ies) search for the best opportunity for me, and I have 8 months to complete my task with living/traveling arrangements ready to go. It is quite an undertaking while I'm still finishing up a full class load and job, but it will be completely worth it once I'm boarding the plane and headed off to a new experience. I draw inspiration from my favorite Pixar movie, Up, and remember that, "Adventure is out there!".

Where are the Chief Creative Officers

Tue, 27 Aug 2013 00:00:00 GMT

In a world of CEOs, CFOs, and, even, CTOs, that does it take to accept the role of CCO for a startup or business? Is there even room on the top floor for another chief power?

Ever since the beginning of this technological renaissance, the importance of design has been accepted throughout the web and mobile industries. There are existing upper management roles for creatives at hardware, software, and consulting shops, both big and small; however, these positions are usually labeled as Creative Directors, Product Managers, or Senior Designers. These titles give little weight when set next to Executives, Vice Presidents, and Presidents in a company.

Let's break down roles of current chief positions:

The CEO is usually the face of a company, making the greatest decisions for the general direction of the company at large, and maintaining the ability to veto the decisions of other officers.
The CFO is the grand treasurer in charge of general flow of money through a company and keep the monetary decisions in line.
The relatively new position of CTO is primarily responsible for all the technical details required to run the company, as well as keep the dev team happy and making sure all the executive decisions are implanted correctly.

So, doesn't it make sense to add someone to this team who is in charge of the major design decisions of the company? This person can work with the CTO in order to ensure the technical implementations of the company's products come out usable, enticing, and interesting when they reach the user. The partnership between CCO and CFO can provide a cost-effective organization of designers and making sure the creative department is set-up with the resources needed to maintain productivity. Finally, the CCO is a direct line of communication from the creative to the CEO and a guide for overall design direction as a company.

I do believe in an open environment where any member of a company should feel comfortable contacting anyone in the company for the betterment of the company overall. However, bigger companies with hundreds of employees like Google, Apple, or Microsoft, and specific departments for their various skillets or products, then every email cannot always be read by the one Chief Officer.

The best example of a CCO position in the world today is actually at Apple with Sir Jony Ive as Apple's Senior Vice President of Design. Even this is a convoluted title for the amount responsibility that lies with Sir Ive in the day to day operations of this very design-oriented company. Where is the President of Design or are those duties passed on to the CEO, Tim Cook? Apple has broken down the leadership of it's various divisions fairly well, but, as the public face of their hardware (and now software) design, Sir Jony Ive has earned more of a Chief title than almost anyone in the industry today.

Should ambitious designers be forced to go to business school in order to join the executive ranks and make greater change within a company? Or can the common executives evolve to include a person, like Sir Ive, to keep the importance of design known throughout a company?

Only time will tell.

P.S. - I was first inspired to think about this topic after reading about being a daring design pegasus rather than a combo design/dev unicorn. Let me know what you think on Twitter.

An Early Easter Egg Hunt

Fri, 23 Aug 2013 00:00:00 GMT

One of the reasons I love Pixar and older Disney movies is the little Easter Egg, or hidden items, the creators place around their films. In most Pixar films you can find a clue to their next production, A113 in homage to a classroom at CalArts, the Luxo Ball, the easily-recognizable voice of John Ratzenberger, and, of course, the Pizza Planet truck. For the avid fans, these little items make the movie special and challenges the animators to place them inconspicuously throughout each film (except for John; there's nothing inconspicuous about that voice).

Many great site and app creators like to take part in this fun as well by hiding neat keyboard tricks, special pages, or references in the mix of their products. If you're a fan of the popular iOS/Mac Twitter client, Tweetbot, then you remember the super secret settings page located in the iOS app a few versions back. Things like this enhance the user interest and provide a better appreciation for work done by the developer/designer/whomever.

So, after struck with inspiration for a fun addition to my site, I created my own little Easter Egg page. It is live now and just waiting for you to find it. If you need a clue or just have some feedback, feel free to mention me on Twitter (it's the little bird icon at the bottom) or shoot me an email from the contact page.

Happy Hunting!

Summer Review & Plans for Fall

Thu, 01 Aug 2013 00:00:00 GMT

August has now reared it's ugly head, which means end of summer is near and time to prepare for a full class schedule once again. For this first of the August posts, I thought I would review some site stats from the summer and talk about the plans for Fall productivity.

Since May 1st, which around when I finally went live with the new site, I have had 216 visits to HipsterBrown.com; of that number, I have had 116 unique visitors and 610 page views. For a blogging newbie and student, an average of 6 page views a day is a nice success. My hope is to iterate on some of the design and improve some of the content in order to increase that average during the coming months. I may even end up rebuilding the blog with a different platform, depending on the progress of Ghost (yet another Kickstarter project I backed this summer).

As far as summer productivity is concerned, I vastly improved upon some of my design abilities including illustration and interface creation in Sketch. Before, I considered myself a simple layout and UI designer but now I'm more confident in my ability to create simple illustration and product mockups in my favorite graphic editor. I finished the HTML/CSS portion of my current personal web app project with hopes to complete the dev work this month, which leads to the primary reason for this post.

The original title to this article was "Dev-dication" but that was trying a bit hard for a catchy, albeit accurate, post title. After all the design work and improvement I made this past summer, I have gotten out of touch with my front-end experience and the ability to build the products I'm designing. So starting in this month, I am dedicating the majority of my work time towards improving my development skills, especially with rapid prototyping and pure Javascript. I already have a few ideas lined up for accomplishing this goal.

My design work will not be halted because I still have several plans in the area, but it will be the treat for after my dev work is done. I know the basics of JavaScript development, i.e. syntax, events, and DOM manipulation, but I have yet to move past the title of beginner due to my lack of practical experience. All the Codecademy, Treehouse, and Code School course won't mean jack until I finally put it to good use in the real world wide web. I plan to take the path of JavaScriptIsSexy article How to Learn JavaScript Properly and start out by building a simple quiz web app. This will improve upon my code organization, DOM manipulation, and form validation abilities right away, and it's a project that can be updated by using an MVC framework like Backbone or Ember and a templating engine like Underscore or Handlebars. It is certainly a step in the right direction towards proper dev improvement.

As a student with 9 months left to build up a proper portfolio and obtain full-time employment before being released into the real world, I feel underprepared but ready for what comes next. There is a lot of opportunity out there, as my constant trolling of the various job boards suggests, but it's hard to anticipate how I am reflected with my current collection of personal projects. While currently classifying myself as a UI/UX/Product designer with some front-end experience is swell for the current job market, being able to confidently call myself a Designer and Front-End Developer creates a whole new realm of flexibility in my job search.

I hope to share some awesome projects in the next few months, both in design and development, and turn a few more heads towards the site. It all leads towards future improvement and a career in this great industry I have come to know the past few years. I cannot wait to look back at this post in a few months and smile proudly at the work I've done.

My Pixar Theory

Sat, 27 Jul 2013 00:00:00 GMT

Due to the lack of Internet access in my current living situation, I have been going through every Pixar movie in order from the original Toy Story to the end of the great trilogy and watching them with their accompanying audio/visual commentary. For me, the commentaries by the directors, producers, and animators behind these revolutionary films made them even more heartfelt and magical to watch again and again. It only took 11 movies for me to notice a few lessons stowed away in these commentaries that could be used in other industries. More specifically, I want to talk about using these Pixarian principles in product design.

The first step for almost all Pixar movies is also the last step, figuring out the punchline before writing the joke. For the folks at Pixar this means finding the ultimate lesson that drives the story before starting any basic animation. In product design, this is figuring out what the primary use is for the app, website, or device before any wireframes or sketches are made. As long as the designer stays focused on what the layout, color scheme, and functionality are all working towards, it is a great giant leap towards creating a useful product. For example, if you were designing an iOS mail app called the Pixarian Postal Service then the final goal would be for the user to get their emails in a timely and readable format. No matter what additional features and flare you decide to add later, this should be the focus of any major decision made later to the design.

Another key principle to the Pixar filmmaking formula is the ability to take something easily recognizable to the viewer and show a new take on it. Like vehicles and toys coming alive and having fantastical personalities or the monsters in our closets scaring children to power their cities. A bit of fresh perspective is perfect for delighting audiences and keeping their attention. In product design that means taking your product's main function and rethinking how it should be done to delight and interest the user. For the Pixarian Postal Service, this idea could be implemented by color coding mail based on a list of friends, family, business associates, subscriptions, etc to give the user the ability to quickly scan through their unread mail. Then making these colors customizable and easy to implement is just icing on the cake. It is literally giving the user a different perspective for their email experience.

Pixar is so great at making their characters seem so life-like and realistic, not just by the detail in the drawing but every single movement being so close to something done in reality. A great lesson to be learned from the animators of Pixar's many famous films is making a character act relatable by using personal experience as inspiration. The universally applicable version of that statement is using personal experience to create a personable experience for the user/viewer. A product designer and their team should draw inspiration for their designs from their experience using other products like it, which is usually what inspires them to make a better one. When coming up with features, layout, and functionality for the Pixarian Postal Service app, you should remember the gripes and groans you make whenever you had to use the iOS Mail app, Google's GMail for iOS app, or even Sparrow. Keeping that in mind should lead you to focus on having push notifications at launch and enough available space on your servers so the rush of initial downloads don't crash them. Also, if you don't see yourself using the feature then why ask your users to do the same?

Now probably my favorite part about the Disney/Pixar franchise is their ability to mix fantasy with mundane realities. For example during The Incredibles, the family has just landed an RV on the freeway after falling from a speeding jet and yet, Mr. Incredible and his wife are still arguing about which exit they should take to intercept the giant robot reeking havoc in the downtown area. A fantastical family of superheroes is going to save the day and they still argue about driving direction because they are still a normal family at the core. Product designers shouldn't be afraid to add a little pixie dust to their designs, as another way to delight their users. In our mobile mail app, this could be adding some nice sound bytes when a user checks their mail and a new letter has just rolled in, like "There's some mail in my box!" (to the tune of "There's a snake in my boot!") and if you can get Tom Hanks to do the voice, that's even better. If a user didn't care for this bit of sparkle in the app, which is highly unlikely, then it should also be easy enough to turn off.

Finally, Pixar has been able to astound so many audiences of all ages by their stories and characters and animation because of something they probably learned from one of their founders, Steve Jobs. He was famous for his attention to detail in hardware and software, making sure even the circuit boards were clean and precise when a majority of customers would probably never see it. This is reflected in all of Pixar's films, you just have to pay close attention to the backgrounds in each movie. The drawings in Andy's bedroom during the Toy Story trilogy are usually done by some of the staff's kids who are the same age as Andy and other animated children during those movies to give it authenticity, down to Andy's name signed on the bottom of his toys. Every single piece of memorabilia in Mr. Incredible's home office and all of Carl and Ellie's knick knacks in their flying house were designed with care by the amazing team at Pixar. One of the directors calls this - "sanding the underside of the drawers". As a product designer, it can be easy to save the boring stuff for last and not put as much effort into it; sometimes that means an ugly settings menu or a confusing FAQ section. For the Pixarian Postal Service, you would want your users to love every bit of the design even if they never venture into some of the more in-depth parts of it. Eventually someone will find these shady and dirty bits of the app, then there is no going back.

Those principles may not be all that Pixar has the offer the world of design but it's a start. They make movies that will generations because they continue to follow these commandments with every new project, and it makes me more excited each time a new movie is announced to see how they implement them once again. I highly suggest going through a few of the commentaries yourself, especially the Toy Story ones, and you may pick up a few things I may have missed. Now get up and out there to take your designs to infinity and beyond. (Couldn't help myself, I love puns!)

P.S. The commentaries tend to point out a few Easter eggs the Pixar crew puts in every movie, like A113, the Luxo ball, a clue to their next movie. If you're feeling adventurous in your designs, trying adding a few of your own to catch some of the more interested users by surprise. The folks at Tapbots are particularly good at this.

Stop Practicing, Start Performing

Sat, 13 Jul 2013 00:00:00 GMT

As a full-time student with a part-time job and various social responsibilities, like local meetups, dates, and Disney, I can only manage small spots of free time to work on my design and front-end development experience. However it hit me as I was finishing up yet another one of my weekly exams, I am spending way too much time practicing and not enough performing!

At the beginning of the summer, I came up with several projects to complete by the time my full-time class schedule started again, but I found myself getting distracted, lazy, and forgetful of those once-exciting aspirations. When I finally got around to doing any work, I would feel unprepared and escape back to the online tutorials or library of ebooks I bought to become a better designer/developer. I would keep telling myself that if I just practice a little more then I'll be ready to conquer [insert project challenge here] and be awesome! Except I would just stay in my cave of guided readings and Codecademy lessons, always putting off the moment when I would actually apply my knowledge.

##"Practice makes perfect" - but what do you have to show for it at the end of the day. Why not put that work to good use and make something useful?

This is not a new concept by any means, but it is one that needs reinforcement among the aspiring makers and creators of the web. Whatever you make doesn't have to be used by millions or even thousands, just as long as it's something you are proud to put out in the world. Learning by real world experience is one of the easiest ways to conquer that development concept or design technique. Don't just create some practice site or app and squander it away where no one else can ever see it- you never know what might become of that seemingly insignificant site idea or design.

This article is meant to be a short and sweet reminder of the dedication required to succeed. After realizing my mistake, I immediately set a schedule and deadline to complete at least one project by the end of the summer. I hope to be back in a couple weeks with a finished product that I will be proud to let others explore and use. I would love to see more people set on this path as well. So, if there is a completed project you would like to show off, please feel free to share it with me on Twitter (just click the bird in the footer) and good luck!

Open Source for Everyone

Tue, 09 Jul 2013 00:00:00 GMT

This summer has sparked inspiration to not just create new sites, tools, and designs but also give back to the community that has taught me so much. As a designer and front-end developer, I thought the best way for me to contribute was solely through open source projects online. This led to my realization that I have been contributing to open source projects for quite a while now, and I believe others should really give it a try.

The open source movement has been around since the Internet was a fledgling phenomenon and grown exponentially over the past few years as new tools were released, which made working with open source projects easier for the common computer user. As these tools progressed, the definition of an open source project has also changed to stand for so much more than code.

The initial open source philosophy started with software developers in the 90s; it stood for releasing free licenses to developing software or code blueprints for other developers to hack in their local environment. The most notable open source project during this beginning period was Netscape's release of the source code for their Navigator Internet browser in 1998 (there is even a full documentary called Code Rush about their incredible journey to the final release of the project all on YouTube ). This led to the founding of the Open Source Initiative to further promote the open sourcing of more major projects from big tech companies, like Mozilla, WikiMedia, and The Linux Foundation.

The philosophy was popularized in the 90s so sharing the code was stuck to passing around floppy disks since the Internet speeds were far too slow to be discovered over dial-up; it would take a few years until broadband Internet to enable easier distribution. Then came the creation of an enormous stepping stone in the open source community, GitHub. This is a company and web app powered by the motto: Social Coding (for all), and truly believes that great code and projects can be created by a global community of developers, designers, and enthusiasts alike. After hearing a few of the GitHub employees, Joel Glovier and Matt Graham, speak about the attitude surrounding the company, I first began to realize the idea behind open sourcing is applied to more areas than just code.

Before I explored the wonderful world of repositories on GitHub, my first contribution to an open source project was on Kickstarter. An awesome smart watch called Pebble had just surpassed its initial funding goal in less than a day, and it was something I finally found worthy of investing my money towards. However, I wasn't really investing in Pebble, nor was I pre-ordering the product months in advance; I was contributing my money and trust to a small group of inventive guys from Canada hoping to develop their product for the masses. Sites like Kickstarter and Indiegogo help individuals and groups share their project with other people around the world and ask for funds to turn their products, software, music albums, plays, movies, and services into a reality. This is labeled as crowdfunding but it can easily be defined as open sourcing product & creative development.

It is spectacular to see a platform for people to share their dreams and ask the world for a little help getting started. Then backers get to share in those dreams as the project creators continue to share their progress, whether it be good or bad, and get feedback on every step of the way. I would not have believed the amount of work that went into designing, manufacturing, and shipping 80,000 fantastic, little smart watches until I committed to Pebble. I continue to follow along with every update even after receiving my physical reward because I am now part of a community that cares about this company and their idea of wearable technology.

//Be warned though, crowdfunding can be a tad addicting, at least it was for me. Since Pebble, I have backed nearly 30 projects on Kickstarter. These ranged from major product design to short books, even some independent films and local musicians. Most of these projects succeeded but some have failed, either in meeting their money goal or providing rewards to their backers. So before you go on a frenzy funding spree, be sure to do a little research on who you're backing and ask a few questions to ensure your money is being put to good use. //

Now, money and technological prowess are not the only ways to contribute to a public project; knowledge is a powerful tool as well. There are sites like Wikipedia that have huge collections of open source knowledge on nearly every subject in the human domain. Anyone can contribute and add knowledge to a data base accessible by BILLIONS of people. Forums are another great way to open source questions so that anyone with similar inquiries can immediately find those answers with a quick bit of Googling (doesn't that sound a little dirty?). Next time you're scrolling through the [your interest here] forums or exploring the depths of the Wiki world, try adding a thought or tidbit of info. You may be surprised to find how much you like it.

Any situation in which a problem can be solved or project completed by asking for the help of the community, whether it be global or local, can be defined as an open source achievement. With so many open source options available, anyone with internet access can contribute. Take a survey of your skills and some of the problems that could be solved by the hands of many, and give open source a shot.

The Conference Appeal

Tue, 25 Jun 2013 00:00:00 GMT

This past weekend I attended one of the most life changing events in my career so far; that was Front-End Conf, and this is my reflection from and recommendation for attending.

Reflection

Preparation

Front-End Conf came out of nowhere for me. I had heard about the major conferences that visited Orlando and the surrounding area, but it was probably my recent interest in the meetups at Envy Labs or sheer dumb luck that I stumbled across this great little conference before it sold out. It has been around for 5 years now, and more information on it's inception can be found here. I was also fortunate enough to receive a student pricing, which ultimately convinced me that this would be a perfect conference to attend.

I registered for Front-End Conf when it was first announced, about two months before the actual event, so I had of time to twiddle my thumbs and get even more excited for what I would experience come June 21st. During those two months, I basically kept up-to-date on who was speaking about what, making plans about where to stay, and rebuilding my personal site and designing new business cards for connecting with my fellow designers and developers attending FEC.

Day 1

On arrival, check-in was an easy and simple process complete with a badge and swag bag containing an awesome shirt designed by Sean McCabe, some sponsor promos and deals, a notebook, and a whole bunch of awesome stickers. Then it was on to the awesome breakfast spread. Breakfast was a great time to start meeting new people or connecting with old friends depending on where you sat.

After the delicious and fulfilling breakfast, everyone merged into the theatre to begin seating for the day's events. The stage was set and, as the first speaker was preparing, the audience prepped their note-taking stations. There were the analog users, including myself, with Moleskins or other types of notebooks writing down their notes or taking sketch notes, and then there were various electronic options from iPad/tablet to full Macbook/laptop experiences. There were 7 speakers and a live podcast on set for the day, and I will just skim over some of my favorite takeaways overall.

The conference started off strong with Matt Graham from GitHub, which the Wall Street Journal humorously called a "Little-known social coding start-up". He started a great discussion about the web community, especially around GitHub, and why we should all work together. I had played around on GitHub before but after this talk of being an industry craftsman and optimizing for happiness in order to create better tools for designers and developers worldwide, I was truly inspired to put more effort into my open source endeavors.

The next big hit for me was Jenn Lukas, the creator of Eff Yeah Hovers, who spoke about Hot Links and how awesome hovers can be for user experience. They don't have to be cheesy or annoying; when done right, they can be delightful and appealing. The joy exuded from Jenn speaking about these little additions to a site's design lit up the room, especially when the power went out and she continued on without much pause. The talk was finished off with a fun quiz created with CSS hovers, testing Chris Coyier, creator of CSS-Tricks and CodePen, on his facial recognition of Tom Selleck & Burt Reynolds. I highly recommend visiting Eff Yeah Hovers and learn to love them again.

After the amazing pizza lunch provided by Less Accounting, it was a real treat to witness a live recording of The Shop Talk Show, hosted by Dave Rupert and Chris Coyier. They answered questions submitted during the week leading up to the event, including one submitted by me, and created some light-hearted discussion and hot drama in the theatre. It is definitely worth the listen if you never have before, and you may just become a fan of the duo (also you can find my question at 13:40 of the podcast ).

The last great talk was done by Doug Neiner, a real JQuery genius. He demonstrated various uses of JQuery for the average users and the professionals alike. I was having my own gripes with the overuse of the JavaScript library, but I kept an open mind about what Doug had to say. During the next 50 minutes, which included slides and an impressive live coding demo, I was throughly impressed with what he presented. Doug not only admitted to some of the useless aspects of the JS addition but showed off some of the more powerful properties of the language to make front-end development just a little more efficient. I can't say I'll be switching back to using it anytime soon, but when I do, I know I will appreciate it even more after that fantastic presentation.

As the day finished out and everyone applauded the speakers one last time, it was time to prepare for the evening's activities, starting with the Drinkup (meetup with drinks, get it?) sponsored by GitHub at the bar down the road. Every attendee received a pair of drink vouchers but the real friendly ones got some extras from the non-drinkers or DDs. This was one of my favorite parts of the day, not just for the free drinks, but it was a chance to chat with more of the attendees and connect with some of the awesome speakers I had heard earlier. I can say with confidence that people in the web industry are some of the most laid-back and easy-going folks I have ever encountered. It was not difficult or awkward to just walk about to a random group of strangers and join in on the conversation, or approach someone relatively famous within the web design world, like Chris Coyier, start a nice discussion. Conferences are not just about the food or the speakers but the designers, developers, and workers of the web, that have at least one similar interest as you, who will teach a little something and help you connect with other people in the industry as your career progresses. My only regret on day 1 was not being able to join in on the karaoke after the after party because of my long drive home.

Day 2

The final day of the conference was something truly unique to Front-End Conf and similar to a BarCamp event. Prior to the start of the conference, attendees can sign-up to give a 10 to 30 minutes talk on the subject of their choosing; this creates a ton of new and interesting discussions with much less effort on the host's part. The venue was different from day 1, but it was much more intimate with the audience and speaker on the same level; the variety of speaker backgrounds really stood out as well. The talks ranged from philosophical to technical to demonstrations of the latest technologies; here are a few of my favorites.

JavaScript game development has peaked my interest lately, and Dan Tello peaked it even further with his talk about the subject. Making a browser-based game with JS is one of the best ways to hone your skills in the language because you cannot use JQuery or CSS to control animation. After demonstrating the 8-bit style running game Dan and his team developed for a client, he showed off a bit of his open source game dev project called blastEngine on GitHub. In the project there is a demo space-shooter game to hack away on, as well as a basic framework to start a new game. I highly suggest giving it a fork, even just to play around with the demo.

Justin Mezzel is an extremely talented illustrator and all-around fun guy to talk to, and this event was the third time I have heard him speak to an audience. His usual talk being about designing with a narrative in mind, he strayed away from that subject and focused on designing as a community instead. It can be hard in such an independent industry, where most people just sit behind a computer screen all day, to reach out and depend on others to succeed. He spoke of his independent streak and, while he was fairly successful, it was not personally fulfilling. It wasn't until he would wake up in the morning with someone depending on him and vice versa, that he felt that he was actually contributing to the world and empowering the industry around him. Definitely very inspiring and along the theme of community I had heard throughout the weekend.

At last, there was a great demonstration by a duo from a company called Mixture based in the UK. They were showing off their very powerful tool by the same name as the company, which helps front-end developers prototype, create, and publish their various web products all within one app. It is currently a beta product but still powerful nonetheless. I had played around with it previously for a web app project but the demo showed how much more functionality there is in the current stages and the plans for the final product. The most impressive feature was the ability to connect multiple devices on the same wireless network and live edit on all the screens. It is a very neat tool to test out on a side project and then follow up into production work.

My day was cut short due to the 4 hour drive to St. Augustine but it was still a full day of talks and connecting with more attendees, especially this guy, that left my satisfied with my purchase.

Recommendation

Overall, attending Front-End Conf 2013 was not only a fun and exciting experience but a productive trip as well. It was such a great first impression of web conferences that I cannot wait to find another of similar value and attend next year's event. I met designers & developers from Canada, the UK, and all over the United States that I can connect with on Twitter and make contact with later on in my career. It is not enough to just sit behind a computer and do good work anymore; being a people-person and making connections within the industry can lead to so much more opportunity later on.

Finally, I would like to thank Dan Denney, his wife, Cherrie, and the whole team who helped organize such an amazing event. I cannot believe how lucky I was to stumble upon this opportunity and the great experience I had because of the people who run it. I hope to one day contribute something as awesome as Front-End Conf to the world of web design and development.

Pure & Not-So-Simple

Mon, 17 Jun 2013 00:00:00 GMT

Getting Started

I started taking a look at web design and development in January '12; Codecademy had just launched and claimed a simpler way for the average person to learn JavaScript, so it seemed like the perfect beginning to my independent academic endeavor. However, I would soon find out that this method of learning JavaScript was just as insufficient as other similar services.

Codecademy starts with the basics of syntax, as you would with learning any programming language, and advances with the typical functionality of JavaScript with loops, conditionals, and, obviously, functions. Along the way, you complete a few bits of practice code to prove a grasp of the content. The biggest takeaway from this type of learning is programming logic and problem solving, rather than how JavaScript works in the real world, and that is the biggest weakness as well. Just as the logic sections are finished, Codecademy immediately turns to JQuery for selector and event support, rather than giving a full background on JavaScript events and selectors, because it is a popular and simple library commonly placed hand-in-hand with JavaScript.

The Rant

That was a basic layout of what is wrong with trying to learn JavaScript in this day and age, at least on the web. JQuery is an awesome and powerful tool that many professional developers use to enhance experiences for all web users, but it is ultimately a tool to use with JavaScript, not in place of it. That line has been blurred, muddled, and obscured so much in the past few years that many job posts for developers/designers will include a preference for JavaScript/JQuery knowledge or even solely JQuery. So this was attitude I was surrounded by as I continued my quest into world of web development, ignorant to the fallacy I was basing my coding abilities upon.

It wasn't until I wanted my web development to grow past simple menus and using plugins to solve my problems and try my hand at making actual web apps; instead, I realized how convoluted my self-driven education had been. Those EdTech services were not the only ones at fault, I had also gone into this learning experience the wrong way. I had no practical uses or intentions for learning web development, so all the lessons were just for show. It took time for me to realize just what web development and proper design was capable of. But getting out of the ditch I had dug myself was more difficult than could have been anticipated.

Loss of Words

It is not that the information is missing, it is more like it is far spread out. There are a sparse amount of real lessons on the subject; albeit a load of books, mostly from the O'Reily franchise. But these books either cover a specific aspect of the language or additional tooling to use with it like Backbone.js or Node.js. It is rare to find a perfect resource that explains the exact practical use of JS in everyday websites and web apps without the inclusion of tools or libraries to spoil the fun. So the interested parties must search far and wide to fully grasp what native JavaScript is capable of nowadays, give it the old college try, and start getting creative, otherwise they can fall on the crutch of JQuery like so many others.

The Solution

Explore the far reaches and odd ends of the Internet to properly learn the basis of modern web development and understand what makes your favorite web tools tick. Fork a fancy project on GitHub and explore the source. Read as much as possible from articles, blog posts, and books by web professionals and experts alike. Come up with an idea for a simple web app and attempt to create it. After that is all said and done, then start exploring the use of additional tools and libraries to ease development while having a complete understanding of what it really takes to complete this task. JavaScript is an expansive, flexible, and powerful language for web development, especially in 2013, so it would be wise to take notice of how it operates now before you get left behind.

P.S. My favorite resources so far are JavaScript.is(Sexy), DailyJS, Professional JavaScript for Web Developers, and JSbooks. Try using CodePen to give your new code skills a shot.

Importance of Interaction

Wed, 29 May 2013 00:00:00 GMT

Since the fall of 2012, I have participated in the most important events in my career so far; my local design & tech meetups.

My first meetup was for Design Orlando at a local web/app consulting shop. Before this, I had had no face-to-face interaction to discuss various topics of the web industry and was seriously lacking in a connection to professionals in my area. How was I expected to jump into the real world in just a few years without any idea what it looked like to work in that space? It felt like a serious misstep in my education so thus far. So for this first meeting, I sat and listened to a short talk by a brilliant designer, Justin Mezzel, who worked in the very shop we were all sitting in, and even commented a few times in the discussion afterwards. Anyone watching the event from afar might have thought it to be pretty mediocre, but in my mind, it was a spectacular display of the insight my area had to offer. It inspired me just as much the image of my first hand-coded website to keep pursuing a career in this industry and showed me that others are just as passionate about their jobs as I was.

My participation in these events snowballed after the introductory experience. I am a consistent attendee of three monthly meetups, including Design Orlando, Orlando Tech Meetup, and EdTech Orlando, and I continue to explore other opportunities as new groups pop up in the Orlando area. I have even participated in a Startup Weekend for EdTech startups and a mini-conference called BarCamp. As I continue to attend these events, I meet more people, offer more opinions, and become a familiar face for the local professionals. It has been and will continue one of the greatest advantages I have over my fellow college students. I could spend all my hours poring over a design or new web app idea, but when I graduate, I have links to my local industry and others around the country because I have those experiences that have honed my people skills and helped me mature beyond the experience a classroom can provide.

Most people go to the "rock-star" conferences to learn, connect, and have a good time with others in their field of work, but as a student, attending anything outside one's area means the extra cost of gas/flights and a hotel room on top of the triple-digit price tag for a ticket to these great events. Not many conferences will offer student discounts or scholarships, which means missing out on fantastic opportunities to learn and connect with others. Meetups are free and are attended by a lot of the same people you will see at the big conferences. Even if you can afford these mega meetups because you are an industry professional, lend a little of your time to attend a meetup in your area, or even start one, to create great discussions and contribute more informed society. Whether you are learning, teaching, or just hanging out and drinking, these meetups are a highly rewarding experience for anyone who attends because they are out of their homes, exploring their city, and interacting with new people that could change their lives for the better, without paying a dime. I suggest heading to Meetup.com right now to search for something that dons your interest and give it a shot. Give me a shout @HipsterBrown if you find it works out in your favor.

Driving Towards Success

Fri, 24 May 2013 00:00:00 GMT

When learning to drive and doing laps at the local driver's ed track, I was having trouble keeping in between the lines at the blistering speed of 15mph in the 2-ton death machine (also known as the family minivan) I had been given keys to. My father, who sat shotgun chuckling at my white-knuckled grip on the steering wheel, gave me a bit of advice: "If you just watch your side of the car and follow that line, the other side will be just fine."* This little driving tip helped me in attaining the key the teenage freedom, my driver's license, and many years later, as I drive around a city 200+ miles from this event, I have realized it's application toward the industry I choose to work in.

Startups are usually made up of a small team of thinks, doers, and creators that have passion and want to solve real world problems (or at least they should be). In many teams, there is the one person who leads them and drives them toward their future goals. This person might feel the need to make sure everything is running smoothly at all times and keeping the team in the lines on the way to success. Just like my first time behind the wheel, this can cause the driver to overcompensate on either side of lane, add frustration, and, if in real world situations, cause quite the collision. This is where the fatherly advice steps in, with a little tweaking on my part.

While I tried out my dad's suggestion of "watching my line", he would assure/caution me as I progressed. He would watch the line on his side and, when we finally got on the city roads, keep on eye on my blind spots as we traveled about. I would trust him to give me the correct information because I sure as hell couldn't see for myself and it was his life on the line too. For the driver of a startup, the people sitting in various passenger seats of this innovative new company is your team. They are there to assist you by watching your blind spots, maybe your weaker abilities of business deals they can manage or design needs that they can fulfill. Or at the occasional stoplight, things might get crazy with a "Chinese Fire Drill" of company roles and leave a new pilot behind the wheel but you keep going towards your destination. Your team, with trusted communication, will keep you balanced between those lines and on the road to success collision-free. So drive on, and make sure to blast some sweet tunes along the way.

*I'm don't recall if it actually rhymed but it sure sounds nice though.

Ignorance is Bliss

Tue, 21 May 2013 00:00:00 GMT

The ignorance described in this piece is ignorance of walls, limitations, and naysayers. This ignorance supports continually learning for the sake of it and exploration into any field that fills your fancy. Ignorance is freedom.

I started my exploration into web design and development in a Computer Fundamentals for Business class, which taught how to make a website for about 3 weeks of the course. This was the very basics, with HTML layouts built with tables and inline CSS; looking back, I realize how outdated and lazy it was for them to teach students this way. Nevertheless, I was hooked from the first time I saw my webpage completed in all its Web 1.0 glory. From then on, I began delving deeper into all that I could discover about building on the web.

At no point in my journey did anyone tell me there was a difference between being a web designer and a web developer; in my ignorance, I had assumed that if you knew how to design a website in Photoshop then you would build it as well with HTML, CSS, and JavaScript. So I continued to learn the proper way to create web projects from mockups/wireframes to implementation with semantic code. I wasn’t working towards a job title, just trying whatever interested me.

Looking through various design and development programs in higher education, or even at the job market in the industry, there are many constraints put on what you must know to earn that piece of paper or position. There is no standard definition on the requirements behind being a professional designer or supreme developer ninja (as so many of the uninformed like to all it); you must know Photoshop, even though you can perform the same tasks in other applications such as Sketch, or the school only teaches C and Java, when your dream job requires more modern languages like Ruby, Python, or PHP.

Why do we confine ourselves into these barriers of knowledge instead of pushing past the limits of our job/degree requirements and keeping improving ourselves without someone saying it’s not necessary or just a waste of time? This may have just been a rant about personal journey into finding a job in the web world and the frustration at the various definition of what constitutes a web designer, front-end developer, or web developer, but the lesson I leave you with is to ignore these definititions and limits to explore what you want and enjoy what you do. Hopefully, this will leave you with bliss.

Hello World

Mon, 13 May 2013 00:00:00 GMT

Well, here goes nothing. Hello World.

About 2 months of planning, design, and development are temporarily finished as the v1.0-ish of HipsterBrown.com is live and ready to go. It has been almost a year since I created my first personal site, and since then I have learned a lot more in the ways of layouts, colors, icons, and front-end development in general. I hope to keep this design a bit longer than the last one but an avid web worker's site is never really done.

Along with my Bio/Resume (which was the only content on the first site), I have included some of the design and web projects I have worked on over the past year, this awesome blog powered by Anchor, and a simple contact form for getting in touch with me. Every page will continue to be improved upon and grow as more content is added.

This was a great learning experience for me in project management, as I handled everything from start to finish, and showed me some of my weaker areas that I will pursue improvement upon. This blog will serve as a voice to share what I learn as I continue on my quest towards becoming a great front-end developer and designer. I have many other project ideas in the works, a few of which I hope to see into fruition during this summer, but I will always return to this site to make sure it is the best reflection of my work as possible.

Keeping it classy,

HipsterBrown