VividVocab is an English vocabulary builder and visual dictionary that I built. It brings new words to life with memorable images, clear explanations, and spaced repetition, so you actually remember them.

It works in three steps:

1. Capture: look up and save any word, phrase, or idea.
2. Visualize: turn it into a mnemonic image.
3. Remember: master it with spaced repetition and quizzes.

Review your words for a few minutes a day and you’ll build an impressive vocabulary, the same way you’d build an impressive physique by going to the gym.

It’s for people learning English, students studying for the SAT or GRE, and anyone who wants to stop forgetting the words they look up.

Get it on the App Store or Google Play, or read more at vividvocab.com.

Screenshots

When using Github Actions, Github supports skipping workflow runs by adding [no ci] to your Git commits.

Conversely, to help reduce your Github bill, this post shares a way to make workflow jobs opt-in by adding [ci] to your Git commit.

Github Actions can get expensive

Github Actions are awesome and allow automating software workflows to streamline development. At Hub3, we use Github Actions to automate the below jobs for our workflow named ci (short for continuous integration):

1. lint: check the app’s code for consistent style and best practices
   • e.g. yarn lint
2. test: run automated tests to verify that the app’s working correctly
   • e.g. bin/rspec
3. deploy: push the app’s code to the live production server

By default (when using on: push), the lint and test jobs are automatically run for each new Git commit. This is uber convenient and allows our developers to receive fast feedback about their code’s style and functionality. Here’s what that looks like at the bottom of a pull request:

Sadly, Github Actions are not free for private repositories, and the cost is based on how long your jobs take.

As your project grows, your jobs will likely take longer due to more code to lint, more tests to run, etc. This trend compounds as you add developers to the project.

Eventually you might ask: How can we use Github Actions more efficiently and reduce our Github bill? Make jobs opt-in instead?

Conditionally running Github Actions

Well, I asked that question!

When working on a large feature, it’s rare to want to run Github Actions for EVERY commit. For instance, some commits act as checkpoints, others as quick fixes, etc. In those cases, it’s often premature to run the test and lint jobs because the code is in a WIP state.

To run Github Actions only when we want to, we add the [ci] flag to our Git commits. For example, a pull request’s WIP commits might look like this:

* 2015073 - add payment migrations
* a778af1 - add payment controllers
* beecca1 - add payment model and controller specs [ci]
* 3c46eca - add simple payment frontend
* 216f3c1 - ui/ux improvements
* 78165cd - add feature specs [ci]
* a7a5f37 - address feedback
* e0fec97 - address more feedback
* 1b7442e - fix linting issues [ci]

In that example, we only run our ci workflow 3 times instead of 9, saving 66% on Github Actions costs for that pull request.

To add support for the [ci] flag, we added the if: statement under each of our workflow’s jobs:

# .github/workflows/ci.yml

lint:
  if: "contains(toJSON(github.event.commits.*.message), '[ci]') || github.ref == 'refs/heads/main'"
  ...

test:
  if: "contains(toJSON(github.event.commits.*.message), '[ci]') || github.ref == 'refs/heads/main'"
  ...

That’s it! Feel free to rename the [ci] flag to whatever you want. Also, notice that the jobs will always run if the branch is main, which is usually what you want.

Alternatively, you could introduce [ci-test] and [ci-lint] flags for more granular control over when jobs run. At Hub3, given the speed of our lint job and the overhead of two flags to remember, we didn’t.

If you find a simpler way to accomplish opt-in Github Actions, shoot me a note.

At Hub3, React Query has been a game-changer for how we handle frontend state. This post describes a helpful React Query pattern we developed that reduces boilerplate and improves our productivity.

Wait, React Query?

A quick primer for the unfamiliar: React Query describes itself as a “data-fetching library for React.” It encourages you to reflect on your frontend state’s “ownership” and separate it into client state and server state.

• Client state is created by the app’s frontend and doesn’t live anywhere else.
  • e.g. selectedBookIds , isModalOpen (aka UI state)
• Server state is the opposite—state that your client fetches asynchronously from some backend.
  • e.g. books , userProfile

React Query makes working with server state easier by providing hooks to help you fetch it, manage asynchronous loading/error states, and cache it via the stale-while-revalidate pattern. At Hub3, React Query dramatically reduced our reliance on Redux Toolkit, which removed a lot of Redux state management code and sped up development.

Check out React Query’s overview and motivation for the full scoop.

The Boilerplate

Consider the example below that uses React Query’s excellent useQuery hook via custom hooks. Try to focus on how asynchronous loading and error states are handled (and not on the contrived page structure 🙃):

const BookShowPage = props => {
  const {
    data: book,
    isLoading: isLoadingBook,
    error: bookLoadingError,
  } = useBookQuery(props.bookId);

  const {
    data: author,
    isLoading: isLoadingAuthor,
    error: authorLoadingError,
  } = useAuthorQuery(book.authorId, { isEnabled: !!book });

  const {
    data: similarBooks,
    isLoading: isLoadingSimilarBooks,
    error: similarBooksLoadingError,
  } = useSimilarBooksQuery(props.bookId);

  // Show a loader if necessary.
  if (isLoadingBook ||
      isLoadingAuthor ||
      isLoadingSimilarBooks) {
    return <Loader />;
  }

  // Show an error message if necessary.
  const loadingError =
    bookLoadingError ||
    authorLoadingError ||
    similarBooksLoadingError;
  if (loadingError) {
    return <Error error={loadingError} />;
  }

  return (
    <PageContainer>
      <BookSummary book={book} />
      <AuthorSummary author={author} />
      <SimilarBooksCarousel books={similarBooks} />
    </PageContainer>
  );
};

Not bad! But we can do a bit better. Here are my two issues:

1. For each query, you need two new variables to store the loading and error state (e.g. isLoadingBook and bookLoadingError). You also need to update the loading and error conditionals.
   • This pattern becomes cumbersome with a few useQuery statements.
2. For each component that fetches data asynchronously, you need to remember to show loading and error states.
   • In my experience, the latter is often forgotten.

The Boilerplate Killer

To address the pain points from above, we created reactQueryRenderHelper to simplify components with multiple asynchronous queries and standardize our loading and error handling pattern.

To understand how it works, let’s refactor the above example:

const BookShowPage = props => {
  const { data: book, ...bookQueryAttrs } =
    useBookQuery(props.bookId);

  const { data: author, ...authorQueryAttrs } =
    useAuthorQuery(book.authorId, { isEnabled: !!book });

  const { data: similarBooks, ...similarBooksQueryAttrs } =
    useSimilarBooksQuery(props.bookId);

  const asyncStatusComponent = reactQueryRenderHelper([
    bookQueryAttrs,
    authorQueryAttrs,
    similarBooksQueryAttrs,
  ]);

  if (asyncStatusComponent) {
    return asyncStatusComponent;
  }

  return (
    <PageContainer>
      <BookSummary book={book} />
      <AuthorSummary author={author} />
      <SimilarBooksCarousel books={similarBooks} />
    </PageContainer>
  );
};

Kinda neat!

What is asyncStatusComponent? In this case, it’s either undefined, <Loader /> or <Error />. reactQueryRenderHelper decides which one based on its arguments. The component doesn’t know or care—it just renders asyncStatusComponent if it’s present and otherwise trusts that the query data is ready to use.

A few benefits to this pattern:

• ⬇️ Boilerplate: Fewer variables and conditionals
• ⬆️ Standardization: Loading and error state is handled identically across components.
• ⬆️ Robustness: You can’t forget to handle and display asynchronous errors (which I see happen quite a bit).

reactQueryRenderHelper implementation

Below is our implementation of reactQueryRenderHelper. To use it in your project, be sure to bring your own <Loader /> and <Error /> components:

// Vendor
import _ from "lodash";
// Components
import Loader from "~/components/shared/loader";
import Error from "~/components/shared/error";

// This helper inspects the results from one or more react-query useQuery calls.
// It decides what component should be rendered (Loader, Error, etc.) and
// returns it to the caller. This helps reduce tedious boilerplate code.
//
// opts:
// - loaderProps: props for shared/loader
// - errorProps: props for shared/error
// - loaderComponent: override loader component
// - errorComponent: override error component
const reactQueryRenderHelper = (reactQueryAttrs, opts = {}) => {
  const isLoading = _.some(reactQueryAttrs, { isLoading: true });
  if (isLoading) {
    return opts.loaderComponent || <Loader {...opts.loaderProps} />;
  }

  const isError = _.some(reactQueryAttrs, { isError: true });
  if (isError) {
    return opts.errorComponent || <Error {...opts.errorProps} />;
  }

  return undefined;
};

export default reactQueryRenderHelper;

Logo Goals

I wanted Hub3’s logo to encapsulate what Hub3 stands for: a hub for strategy, design, and code. Those four concepts (including the hub) need their own distinct components in the logo.

The logo also needs to look great in various contexts: our website, LinkedIn, invoices, etc. After a quick survey of those contexts, I decided that our logo needs to scale well at small sizes and is perfectly centered when framed in a circle or square (think Facebook vs. LinkedIn profile images).

Lastly, I wanted the logo to be vector-based (instead of pixel-based) to be resizable without quality loss. It should also be built with simple primitives (circles, rectangles, etc.) so that it’s easily reproducible. I picked Sketch as my design tool because I’m most familiar with it.

Problem: Never-ending Iteration

Before jumping into the logo’s construction, I’ll describe the design process I used and the pain points it addresses.

Given the subjectivity of design and all the options for colors and shapes, I find it hard to settle on any design confidently. There always seems to be a tweaked variation that’s incrementally better—a brighter blue, larger corner radius, etc. As a result, I’ve spent way too much time chasing incremental design improvements, feeling unsatisfied.

For example, here are some questions that cause me to spin my wheels:

• How big should this circle be?
• What’s the perfect shade of red?
• How much padding should be between a logo and its frame?
• How curved should this edge be?

To answer those questions, I want to trust in a process that doesn’t rely entirely on my gut or the opinions of others.

Solution: Constraints

How do I design faster with more confidence? For me, it’s simplifying my design process and adding constraints that prevent me from chasing incremental gains.

Here are the constraints I came up with for the Hub3 logo project:

• Colors can only be picked from a popular color catalog (e.g. colors.lol).
• The logo can only be built with primitive shapes: circles, triangles, and rectangles.
• The Golden Ratio should be used to define the initial sizes of primitives.

That’s my sandbox! Let’s dive into the last constraint, which this post focuses on.

Golden Ratio

For our purposes, the Golden Ratio (or “divine proportion”) is a ratio between two lengths that produce proportions considered aesthetically pleasing. It appears in natural and man-made contexts like architecture and financial markets. Specifically, it’s an irrational number represented by \(\phi\) and commonly truncated to 1.618.

Here’s the Golden Ratio in action, for segments \(\overline{\rm AC}\) and \(\overline{\rm CB}\):

Interestingly, the Golden Ratio is hidden in the Fibonacci Sequence. Consider a segment of the Fibonacci Sequence below:

0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, ...

As you progress through the sequence and divide each number by the previous, you get closer and closer to the Golden Ratio. For example:

\[ 2 \div 1 = 2 \\ 8 \div 5 = 1.6 \\ 34 \div 21 \approx 1.619... \\ 144 \div 89 \approx ~1.618 \]

Cool! Now we know what the Golden Ratio is and how to approximate it. Let’s put it to use.

Logo Construction

Jumping ahead, I know we’ll need to start with a bunch of circles. How big should the circles be? Let’s use the Golden Ratio!

First, pick an initial circle size—I picked 300px. Create the next circle by multiplying the first circle’s diameter by the Golden Ratio, or 1.6 (you could use 1.618, but that results in more non-integer products). Repeat this three more times until you have five overlapping circles:

Easy! The big idea is that we can now trust that these “divine proportions” will care over into the derived logo.

How should we represent the “hub” in Hub3? The Webster dictionary defines a hub as “a center of activity” or “the central part of a circular object.” I think a circle works, and I picked the first one. We’ll also want some padding around it, so I’ll keep the next immediate circle.

Next, how to represent the “3” in Hub3? I think of the intersection of strategy, design, and code as a digital product—they all contribute in their own way. I imagine a Venn diagram with three circles that overlap:

I like the shape created when the circles overlap (outlined in red). It’s a triangle shape and built with three overlapping circles—awesome.

How do we decide how big the overlapping circles should be? Further, how much should they overlap? To answer those questions quickly, I duplicated the center circle three times (in blue) and rotated them all 120 degrees from each other. I then took the outer-most circle (in green) and moved it up until its edge touched the bottom blue circles.

Next, to create the remaining two overlapping circles, we duplicate the green circle twice and rotate the duplicates 120 degrees around the center, as we did for the blue circles.

It’s coming together. Note that we haven’t created any new shapes—just clones of existing ones at their original sizes.

Let’s simplify our workspace and “intersect” the green circles and subtract the inner circle’s padding to get the logo’s outline.

We now have a circle and a triangle shape. How are we going to represent strategy, design, and code? I decided to divide the triangle shape into three “leafs” surrounding the hub (center circle). To do that, I created a rectangle with the width of the inner circle’s padding and rotated its duplicates around the center.

I then “subtracted” the newly created rectangles (in blue) from the original shape, which results in three new shapes that surround the hub.

To add a sense of movement to the logo, I decided to accent each of the “leafs” by adding a corner radius to the inner left corner. I then applied Hub3’s branding colors to bring the logo to life.

Finally, we need to center the logo in a container for social media. How wide should the logo be relative to the frame? You guessed it—the ratio between the frame’s width and the logo is 1.6:

Final Thoughts

In the end, the Hub3 logo was created almost entirely by cloning circles made via the Golden Ratio and applying boolean operations. Via the constraints I outlined above, I moved faster and deliberated less. As they say, sometimes less is more.

What’s so special about the Golden Ratio? Unfortunately, I don’t know. It was a helpful design heuristic for this project that I’ll likely apply with a grain of salt to future projects. Here are rough alternative logos that don’t use the Golden Ratio—I’ll let you decide if the Golden Ratio helped:

Interestingly, Spotify found that the Golden Ratio didn’t help their logo:

Gizmodo: What’s the deal with those waves or squiggles or whatever they are? In the redesign they’ve been moved off to the left.

CW: We noticed that people have been complaining on the Interwebs about them not being perfect. We had tried out the golden ratio on them but that made it look even more weird. This version is a little more organic and it’s not super perfect, which I think gives it more personality.

How Spotify Got Itself a New Logo

After migrating Pandify’s URL scheme to HTTPS, I noticed that the site’s Facebook likes had disappeared! This post describes how I fixed that.

Background

When configuring the Facebook like button you specify the ‘URL to like,’ which is the URL that new likes will get attributed to:

However, the like button’s count reflects the likes for the current page’s URL, and NOT for the URL you configured the like button with. If a page’s URL changes at all, including the URL scheme, that page’s like button count will change to reflect the new URL’s like count.

At a high level, here’s what I wanted to do:

• 301 redirect HTTP to HTTPS
• Preserve Facebook likes from the non-HTTPS URL
• Allow new likes from the HTTPS URL to increase the like count

Solution

Facebook shares some insight on this issue:

…you can’t move the likes, shares or comments directly to the new URL but you can use the old URL as the canonical source for the number of likes or shares at the new URL.

There are three ways to declare the ‘canonical source’ to Facebook:

1. HTTP 301 or 302 redirect
2. <meta property="og:url" content="..." />
3. <link rel="canonical" href="...">

Option #1 is a no-go because Pandify’s Nginx server redirects HTTP to HTTPS. Again, this is what causes the Facebook likes to disappear.

I want the canonical URL to be the HTTPS URL. Left with option #2, I added a <meta> tag to Pandify’s HTML template that points to the non-HTTPS URL (which has the Facebook likes associated with it).

<!-- Preserve Facebook likes from the non-HTTPS URL. -->
<meta property="og:url" content="http://pandify.com" />

This tag tells Facebook to use the non-HTTPS URL as the ‘canonical source’ for likes. However, this doesn’t restore the likes yet, and Facebook’s Sharing Debugger shows a new problem when debugging https://pandify.com:

Circular Redirect: We could not resolve the canonical URL because the redirect path contained a cycle.

What’s happening? Facebook’s scraper is following the <meta> tag’s og:url (the non-HTTPS URL) and getting redirected by Nginx to the HTTPS URL, causing a redirect loop!

My solution is to detect the Facebook scraper’s user agent and NOT redirect to the HTTPS site, but instead return 200 OK. I do this via Pandify’s Nginx server block configuration for non-HTTPS requests:

server {
  listen 80;
  server_name pandify.com www.pandify.com;

  location / {
    if ($http_user_agent ~* "facebookexternalhit") {
      # Preserve Facebook likes from the non-HTTPS URL.
      add_header Content-Type text/html;
      # NOTE: Add other Open Graph tags to keep Facebook's Sharing Debugger happy.
      return 200 '<meta property="og:url" content="http://pandify.com" />';
    }
    return 301 https://pandify.com$request_uri;
  }
}

Voila! After restarting Nginx and forcing Facebook’s Sharing Debugger to ‘Scrape Again’ for https://pandify.com, the likes from http://pandify.com returned.

During 2017’s Bitcoin bull run, the price of many cryptocurrencies changed rapidly. Bitcoin grew to nearly $20,000, and the high levels of excitement and FOMO created many arbitrage opportunities. This is also when my barber started talking about Bitcoin…

With friends, I took advantage of the US–Korea arbitrage opportunity as well as built a simple arbitrage bot in Ruby that watched GDAX and Kraken for price differences. Those opportunities don’t seem to be easily exploitable now.

One takeaway from that experience is that cryptocurrency trading is driven largely by speculation—many don’t have real-world adoption yet. Given that many cryptocurrencies respond to similar market pressures and regulation, I wondered if prices moved together in any predictable way.

This led me to the idea of Pairs Trading. The idea is simple: find a pair of assets whose prices “move together” and bet against deviations in that relationship. How you confidently define the pair’s relationship is one of the hard problems.

After studying the theory behind Pairs Trading and reading a few papers, I built a high-frequency statistical arbitrage bot and backtesting pipeline. I implemented Distance and Cointegration Pairs Trading strategies on Poloniex’s Margin Trading Exchange. It looks for cryptocurrencies whose prices move together and bets against trend anomalies. It’s built with Python, NumPY, Pandas, Matplotlib, Scikit-learn, TA-Lib, and Peewee.

Key resources:

• Statistical Arbitrage: High-Frequency Pairs Trading
• Pairs Trading, Convergence Trading, Cointegration

Screenshots

Dockerized CLI tool for quickly generating 3D models from a set of images using OpenMVG and OpenMVS.

I built this to tackle the problem of ADA incompliant curb ramps. With photogrammetry, curb ramps can be more quickly surveyed and later fixed.

The goal is to use smartphone photos to generate 3D curb ramp models which can be measured virtually. The current process involves many tedious hand measurements.

Example usage:

./bin/mvg_mvs_pipeline --image-dir <image-dir> --ouput-dir <output-dir>

Screenshots

Hitpic is a competitive, location-based photo sharing iOS app. Each day at 8 PM ET, yesterday’s top-rated pics at each location become hitpics! Increase your score and global ranking by earning ratings and hitpic awards.

More details are on Hitpic’s website.

Technology

I designed Hitpic with Sketch and built the app’s frontend with React Native, a framework for building native iOS apps with JavaScript. For image editing and filtering, I wrote custom Objective-C modules for performance reasons. Frontend state is managed with Redux.

The backend’s built with Ruby on Rails and PostgreSQL. Redis is used for background processing with Sidekiq. I also developed an admin interface with Active Admin for monitoring users, content, and marketing effectiveness. Crashlytics was used for distributing beta testing builds.

Screenshots

Marketing Material

Old Designs

Dashboard for campus police dispatchers that shows students in distress or panic, and the officers that are responding to incidents.

All the data is fake and randomly generated. For demonstration, many incidents are always occurring.

Knightly went on to raise funding from Northeastern’s IDEA program with this MVP. Read more about Knightly here.

Features

• A live Google Maps instance around Northeastern University.
• As the student moves, their previous positions are recorded on the map.
• Officers that are following students are connected via a line.
• Press s to stop/start the simulation.
• Hold <Space> to increase the simulation speed.
• Click on a map marker to view information about the user.
• Clicking on any side menu feed item will focus the map appropriately.
• Live Feed Menu:
  • Shows the latest event data.
• Incidents Menu:
  • Shows the currently panicked and distressed students.
  • Shows the last 5 resolved student incidents.

Screenshots

Educational quiz to aid the learning of world country locations and capitals. Little planes fly around for entertainment!

I built this because I wanted a more interactive, visual way to study geography. I also couldn’t find quality quizzes for testing knowledge of country locations on a map.

Screenshots