187315.11d9b23.8167b9c265c247eda837d0966d62a344

The Grid

I’m finally able to share that I recently joined The Grid!

I feel proud to be a part of the team behind GSS, NoFlo, FlowHub, and more.


Backing the Future

I first encountered The Grid last year when I backed the NoFlo Development Environment on Kickstarter, and again a few months ago after working with Auto Layout on iOS.


At that time I was frustrated with web development and had sought refuge in producing native applications. Underwhelmed by the current landscape, I wondered if I’d ever go back.

I kept dreaming of a world I thought I’d never see. And then, one day… I got in.
- Tron Legacy



The Grid changed all of that. Here are just a few reasons why I’m excited about what we’re doing:


Remote

We’re a distributed team comprised of people across 7 countries. I love that our culture supports working remotely where geography isn’t a barrier to working with great people. Everyone I’ve come into contact with has been incredibly talented and humble.


Style & Substance

Design is given the attention it deserves. In conjunction with the innovative technology required to make them a reality, beautiful aesthetics are at the forefront of everything we do.


Open Source

Just take a look at one or two of our organizations on GitHub and it’s easy to see that we believe in open source. I’m a big proponent for writing software in an open source environment that encourages collaboration and produces more modular, testable code with better documentation.


A Digital Frontier

Years of development have been invested into projects like these to facilitate building our platform, which launches soon.


I’m continually blown away by what we’re doing and I can’t wait for everyone else to experience it too.


Statusfy

Icon

Spotify in your status bar.

Screenshot

I wrote a little Mac app that displays information about the track that’s currently playing in Spotify.

Download it or check out the source code on GitHub.

Jade Inheritance

TL;DR I created jade-inheritance to understand the dependencies between Jade templates in order to only compile the files I needed.

In a previous post I described how some much needed updates to our Jade templates at CrowdTwist came at the cost of slowing down our development time.

'Are you stealing those LCDs?' 'Yeah, but I'm doing it while my code compiles.'

At first I thought,

Sure. We’re doing some pretty complicated stuff now and our app has grown, so it’s bound to take longer.

But then it hit me – our watch task (which monitors changes to our templates) was compiling everything everytime I edited something. Even if the edited file lived in total isolation, the entire app’s Jade files were getting compiled into HTML.

And it was taking 57s.

Even for the smallest change. Fixing a typo, iterating on a feature, anything at all.


The Problem

I started by asking, “Why?”.

Why were we compiling all of our templates when potentially only one of them had changed?

Well, there was the possibility that the changes to the modified file could impact the output of other files. Updating a file which was extended or included by other files would require those files to be recompiled too.


The Solution

To solve this problem I created jade-inheritance.

Given a Jade file and a directory, it will determine which files within that directory extend or include the file. By passing a modified file to jade-inheritance it’s possible to understand which other files should be recompiled. On the file with the most dependants in our project, this additional processing can be done in around 1.5s.


Conclusion

Now, modifying a file which is completely isolated takes only 0.15s. A 99.7% improvement, with other files of varying dependence compiling in much less time too.

Jade

We’ve been using Jade at CrowdTwist for some time now, but only recently did I make some changes to really leverage its benefits beyond some syntactic sugar.


Forms

One thing which had been bugging me for a while was our forms. Since there was a lot of boilerplate markup involved to get things how we wanted them, this meant that creating new form fields was tedious, cumbersome, and prone to inconsistency. I wanted to come up with a solution which would abstract all of that away to make it nicer for my team to work with with minimum disruption.

Below is a (simplified) sample of some of the changes I made which makes use of Jade’s mixin functionality.

Before:

form(name="log-in-form", novalidate)
  dl.form
    dt
      label(for="log-in-form-username") Username
    dd
      input(type="text", id="log-in-form-username", required)

    dl.form
      dt
        label(for="log-in-form-password") Password
      dd
        input(type="password", id="log-in-form-password", required)

    dl.form
      dd
        input(type="checkbox", id="log-in-form-remember-me")
      dt
        label(for="log-in-form-remember-me") Remember me

    button(type="submit") Log in

After:

+form(name="log-in-form")
  +input('Username')(type="text", id="log-in-form-username", required)
  +input('Password')(type="password", id="log-in-form-password", required)
  +input('Remember me')(type="checkbox", id="log-in-form-remember-me")
  +submit('Log in')

When compiled, the “after” markup is identical to the “before” markup.

Awesome, right? Much more future-proof. Now the structure of our forms is defined in a centralized place and we can make changes globally with minimum effort.


Pages

I also wasn’t too pleased with how our pages were set up. We had a lot of similar pages which were all using their own (sometimes identical) markup. Template inheritance made total sense here to allow us to keep conditional logic out of our views. Despite that, it was still pretty complex in parts.

Surprisingly it was the subtle differences between pages that brought bigger challenges. I ended up wanting a combination of regular extends along with some mixin behavior.

Consider the following example:

h1 [heading text goes here]
a(href="[link goes here]") [link text goes here]

If each page had this structure, the use of blocks is not ideal.

We could do this:

block heading
  h1 [heading text goes here]

block link
  a(href="[link goes here]") [link text goes here]

or possibly even nest the blocks inside the tags, but that wouldn’t solve the case of the href attribute.

Mixins would help, and could look like this:

mixin heading(text)
  h1= text

mixin link(text, href)
  a(href=href)= text

but they’d still need to be used on every page and each block is more permissive than desired.

The eventual solution was the following:

//- abstract.jade
block context

h1= headingText
a(href=href)= linkText
//- concrete.jade
extends abstract

block append context
  headingText = 'Jade'
  linkText = 'Issues'
  href = 'https://github.com/visionmedia/jade/issues'

This appears to be the best of both worlds; classic inheritance with the benefit of the argument-like context of mixins.

Notice that the concrete page uses block append context instead of block context which is used by the abstract template. This allows us to define default values in the abstract template which can be overridden in concrete pages.


Conclusion

There was now much less duplication across our templates and as a result our UI was more consistent. We could create new pages and make updates more quickly but unfortunately, this killed our compilation time.

We have a setup which auto-compiles our templates when they’re edited and saved, but the increased used of (and probably combination of) mixins, extends and includes meant we could no longer make quick changes and instantly refresh a page in our browser to see the result.

See how a dealt with that in a follow-up post.

Weather

Yesterday I saw that my friend Dan at Permalight had taken a skillshare class on iOS app design.

After looking over Dan’s project I decided to see if I could make it a reality by the end of the day, and this is the result.

Features include:

  • Use of CoreLocation to obtain the user’s location before requesting forecast data.
  • Conversion of touch gestures to hours of the day for scrubbing forwards and backwards through time.
  • Use of a quadratic equation to convert time into opacity in order to update the background color based on the position of the sun.

If you’re looking for some freelance design or development, talk to Dan at Permalight.

Passback


Passback is a working concept based on Apple’s Passbook service to provide access to contact information in case of an emergency or if a device is recovered after being lost or stolen.

The premise is hinged on the ability to access Passbook passes from the lockscreen without entering the device passcode.

A companion app would allow users to create and update the pass containing their information, in conjunction with a web service.

Currently passes are displayed on the lockscreen based on a relevant date or location so unless the features of Passbook change, the web service would be required to update the passes once per day.

Artwork for a friend’s band.

Artwork for a friend’s band.