MarcoCarag.com

Feeling on Cue

Fri, 17 Oct 2014 17:24:00 -0400

The pain of losing someone close to you is a beast of a thing. It aches, pierces, smacks, numbs, shocks, and absolutely, completely crushes. But the worst part for me is that it sneaks. I never quite know when sadness will be jostled enough to completely spill over the brim and paralyze me for a time.

A year ago today, that which has been the dominant subject of my sparsely updated blog of late happened; my dad passed away. And even through the course of writing this post, I was a teary wreck for half of the first paragraph, and then stoic and nearly distracted from the topic the next. That I can’t completely control that can be hard to accept.

When I went home for what would have been my dad’s 69th birthday last August, I thought the brim would spill over right from the get-go — that the whole weekend would have been painful and cathartic. It wasn’t… I found enough distractions in being home, with family, my 9-month-old nephew, and the new bustle of fresh development in my hometown. There was a brand new commuter train station, surrounded by new malls in previously empty fields, and high rise apartments — black spires piercing a sky that had been clear blue and empty for generations. Even my old neighbor’s house was torn down, replaced, and a new young family moved in. There wasn’t much to allow sentimentality to take root during the short two days I was there.

I don’t know what I had in the way of expectations — probably very few of them at all. But I was hoping, after a difficult week leading up to it, that the weekend would be emotional. And when it still wasn’t, leading up to returning to New York, I was frustrated. I was reminded that the triggers for my sadness are often unpredictable. I can’t just plan to emote in a certain way at a certain time — humans don’t work that way, least of all me. Sometimes the right song will catch me in just the right way. A second listen may sound completely bland, instead.

In the time since, I’ve had my moments — some made sense, others didn’t. I realize in general that I need to achieve a certain level of isolation from the world — I’m sure meditation would be effective for controlling this were I to learn it. But the most important learning, that I constantly have to repeat to myself, is to allow the moments to happen, as best I can wherever and whenever I am. And maybe even more importantly for me, to allow them to not happen if they just aren’t going to. The problem I have with not emoting in the way I want to is a tendency to try to force it, and instead being left with numbness. And that’s worse territory to be in. Not being hard on myself and trying to force it is a skill I’m learning very slowly, but it might be the most important one to learn.

Anyway, I don’t have much more to say about this, and I’ve been a bit rambling anyway. But it was also satisfyingly cathartic after all. So at least I have that. Thanks for reading!

Miss you, Dad. I’m grateful for the growth I’ve experienced in the year since you left us. I’ve apparently got a lot of growth left to do.

Lessons from Dad: The Crab Feast

Sat, 30 Aug 2014 12:21:00 -0400

It’s my father’s birthday, the first since his passing last October. My mind’s been on him a lot lately, so I figured I’d write my next few posts about my and others’ memories of him. Here’s the first of those, from the cobwebbed archives of my brain.

My family over my lifetime used to (and still does) gather for relatively normal reasons - Christmas, Easter, and Thanksgiving - and sometimes for less normal reasons, like mahjong or silver anniversaries. What I remembered most of these times was not necessarily the details of the occasion, but the atmosphere of my house transformed by people…a din I wasn’t so much helping to create than I was just witnessing it.

One fond summertime occasion I recall from my childhood was the grown ups in my family gathering over a pile of Chesapeake crabs, and doing what you’d expect: tearing into them while chatting the sun down. Us kids - my sister, brother, and cousin - sat at the coffee table with ears of corn - I presume because crabs terrified us (or at least me).

Sometimes the piano would be opened, or a guitar would come out. We’d play Super Mario Bros. 2. Always shells cracking open in the background. But definitely my strongest memory was seeing my Dad’s generation of the family around a table laughing about things I didn’t understand, whether it was because I was too young for the humor, or the jokes were told in Tagalog which I didn’t speak. It didn’t matter whether I understood - what I loved was that the grown-ups were liberated to be themselves, and not worried about me or my siblings (at least that I could tell…Mom might tell a different story).

Memories of these crab feasts were some of the first that filled my brain in the days after my father suddenly passed. The event of his death triggered a distillation process that’s been ongoing ever since, and in the beginning, it was a coarse one; my entire present life just disintegrated in an instant and I felt as if I were 8-years-old again. In the months since, whenever I’ve found myself in a stressful spiral, the distillation spins up again. It’s not always a good thing - sometimes, the present stress can’t be grated away so easily (I can’t just move out of New York, is a frequent example), and the resulting cognitive dissonance is awfully numbing.

But when it polishes down my memories to ones like this, then it becomes a helpful guide. Sometimes, all you need to feel better is to fill a space with a comfortable din, made with friends and family. There may be crabs there, and you may have eaten them, or not. Just fill that space so that there’s no room for the stuff that doesn’t matter. It maybe took a couple of decades for me to realize, but I’m glad I know now that Dad had the right idea. I’ll do my best to take up that mantle.

Happy birthday, Dad. We miss you.

The better half.

The boys.

Migrating Away from GitHub Pages and Changing Task Runners (just 'cause)

Wed, 18 Jun 2014 14:57:00 -0400

I’m changing my workflow again! Partly because the nature of my recent work — quickly spinning together apps and prototypes one after another — has gotten me interested in workflow options more than ever before. But also partly because my last change — to Wintersmith from Jekyll — was already somewhat dissatisfying and behind the times. I’m talking about two things here: hosting on GitHub Pages, and using Grunt as my taskrunner.

Github Pages

The first problem with GitHub Pages stems from my choice of moving away from Jekyll. Jekyll is the engine that GitHub uses to build GitHub Pages from source files. But moving away from Jekyll means that source content won’t automatically be compiled by GitHub. Not a huge obstacle, as the simple solution is to compile the site locally and commit the files to my repository. So I did just that, using Grunt to help that part of the workflow.

This was immediately dissatisfying, however, because it resulted in the compiled content and the source content commingling in the repository together. To make the situation even messier, in order to be served out by GitHub Pages, the compiled content needed to be at the root of the repository. This effectively was a regression from the Jekyll situation, where the source content could be committed normally, and GitHub would handle the page compilation (I actually moved away from that, as well, to accommodate plugins; though, leveraging Rake, I still separated source from compiled). But more importantly, it just felt gross to have both source and compiled content all mixed together at the same root and in the same repository.

DNS issues

The next problem I had was unexpected: GitHub was intentionally 302 redirecting hits straight to my site. This blog post sums it up nicely; in short, as a means to better mitigate DDoS attacks against their IPs, GitHub first filters against bot user agents before 302-ing plain ol’ humans to Pages. This is only true for Pages using A DNS records to point custom domains straight at their server IPs.

I could have used an ALIAS record (pluses and minuses of which are well explained by my DNS provider, DNSimple) pointed at jazzcrazed.github.io to handle the redirect issue, but the first repository-cleanliness problem had me turned off to Pages, anyway. It tasted a little sour to have my hosting situation dictate my content management and source control in such specific ways.

Enter S3

For several quick projects at my most recent job, we threw up frontend-only applications on our Amazon S3 buckets. They were cheap, easy, and performant. It actually seemed close to an ideal match to my needs for this blog.

I had long ago set up an AWS account that had been idling with the intention of using it more directly. Now that work had me using AWS quite regularly, I felt perfectly comfortable with moving to it. I was already generating my Wintersmith blog on my local machine — I even had created a bucket long ago named marcocarag.com (I can’t remember why… I think to host assets?). The only missing piece was deployment.

…Also, Enter Gulp.js

I was all ready to add a Grunt plugin for S3, and create a deploy task — when I had the rug pulled out from under me, a good half a year late.

Turns out, at the beginning of this year, several months before I migrated from Jekyll and Rake to Wintersmith and Grunt, a challenger to Grunt emerged named Gulp.js. The reasons for its success since are well written about by now — and most all of them resonated with me, as well. Particularly the opinion, which I share, that Gulp.js code is simply more readable than Grunt’s JSON configuration.

Since a major part of the existence of this blog is to learn stuff, while on the track of migrating to a new host, I may as well spend some time playing with Gulp. So I converted my Grunt to Gulp, and in the process audited my tasks and cleaned them up slightly — and also added deployment to my build task. I’m no expert by any stretch of the imagination, and so it means something when I was able to change from Grunt to Gulp — and understand decently what was going on — in a fraction of the time it took to set up Grunt.

Here’s the before:

module.exports = function(grunt) {
  grunt.initConfig({
    cssmin: {
      production: {
        expand: true,
        cwd: 'css',
        src: ['*.css'],
        dest: 'css'
      }
    },
    coffee: {
      preview: {
        sourceMap: true,
        files: {
          'contents/js/script.js': ['contents/coffee/*.coffee']
        }
      },
      production: {
        sourceMap: false,
        files: {
          'contents/js/script.js': ['contents/coffee/*.coffee']
        }
      }
    },
    compass: {
      dist: {
        options: {
          sassDir: 'contents/sass',
          cssDir: 'css',
          environment: 'production'
        }
      },
      dev: {
        options: {
          sassDir: 'contents/sass',
          cssDir: 'contents/css',
          environment: 'development'
        }
      }
    },
    extend: {
      options: {
        deep: true,
        defaults: grunt.file.readJSON('config.json')
      },
      production: {
        files: {
          './config-production.json': ['./config-production-base.json']
        }
      },
      preview: {
        files: {
          './config-preview.json': ['./config-preview-base.json']
        }
      }
    },
    wintersmith: {
      production: {
        options: {
          config: './config-production.json'
        }
      },
      preview: {
        options: {
          action: "preview",
          config: './config-preview.json'
        }
      }
    },
    watch: {
      sass: {
        files: [
          'contents/sass/**/*.scss'
        ],
        tasks: [
          'compass:dev'
        ]
      },
      coffeescript: {
        files: [
          'contents/coffee/**/*.coffee'
        ],
        tasks: [
          'coffee:preview'
        ]
      }
    },
    uglify: {
      production: {
        files: {
          'js/script.js': 'js/script.js'
        }
      }
    },
  });
  grunt.loadNpmTasks("grunt-extend");
  grunt.loadNpmTasks("grunt-contrib-coffee");
  grunt.loadNpmTasks('grunt-contrib-cssmin');
  grunt.loadNpmTasks('grunt-contrib-compass');
  grunt.loadNpmTasks('grunt-wintersmith');
  grunt.loadNpmTasks('grunt-contrib-watch');
  grunt.loadNpmTasks('grunt-contrib-uglify');
  grunt.registerTask('preview', [
    'extend:preview',
    'coffee:preview',
    'compass:dev',
    'wintersmith:preview'
  ]);
  grunt.registerTask('buildProduction', [
    'extend:production',
    'coffee:production',
    'compass:dist',
    'wintersmith:production',
    'uglify:production',
    'cssmin:production'
  ]);
};

And the gulpfile.js that replaced it:

var gulp        = require('gulp');
var gutil       = require('gulp-util');
var cssmin      = require('gulp-cssmin');
var extend      = require('gulp-extend');
var coffee      = require('gulp-coffee');
var compass     = require('gulp-compass');
var wintersmith = require('run-wintersmith');
var clean       = require('gulp-clean');
var uglify      = require('gulp-uglify');
var path        = require('path');
var fs          = require('fs');
var awspublish  = require('gulp-awspublish');

var BUILD_DIR = 'build';
var CONTENT_DIR = 'contents';
var TEMPLATES_DIR = 'templates';

gulp.task('clean', function() {
  return gulp.src(BUILD_DIR, { read: false }).pipe(clean());
});

gulp.task('coffee', function() {
  gulp.src(CONTENT_DIR + '/coffee/*.coffee')
      .pipe(coffee({bare: true}).on('error', gutil.log))
      .pipe(gulp.dest(CONTENT_DIR + '/js/script.js'));
});

gulp.task('uglify', function() {
  var dir = CONTENT_DIR + '/*.js';
  gulp.src(dir)
      .pipe(uglify())
      .pipe(gulp.dest(dir))
});

gulp.task('compass', function() {
  gulp.src(CONTENT_DIR + '/sass/*.scss')
      .pipe(compass({
        project: path.join(__dirname, '/' + CONTENT_DIR),
        css: 'css',
        sass: 'sass'
      }))
      .pipe(gulp.dest(CONTENT_DIR + '/css'));
});

gulp.task('cssmin', function() {
  var dir = CONTENT_DIR + '/css';
  gulp.src(dir + '/**/*.css')
      .pipe(cssmin())
      .pipe(gulp.dest(dir));
});

gulp.task('set-production-config', function() {
  console.log('Creating production config');
  gulp.src(['./config.json', './config-production-base.json'])
      .pipe(extend('config-production.json', true))
      .pipe(gulp.dest('./'));

  console.log('Setting production config for Wintersmith\'s use');
  wintersmith.settings.configFile = 'config-production.json';
});

gulp.task('build-and-deploy', ['clean', 'coffee', 'uglify', 'compass', 'cssmin', 'set-production-config'], function() {
  console.log('Running Wintersmith build');
  wintersmith.build(function(){
    // Log on successful build
    console.log('Wintersmith has finished building!');

    console.log('Reading AWS config');
    // create a new publisher
    var publisher = awspublish.create(JSON.parse(fs.readFileSync('./env.json')));

    return gulp.src('./' + BUILD_DIR + '/**')
      .pipe(publisher.publish())

      // create a cache file to speed up consecutive uploads
      .pipe(publisher.cache())

       // print upload updates to console
      .pipe(awspublish.reporter());
  });
});

The Exploded View

To publish and upload my site, I now run the command gulp build-and-deploy. Here’s what goes on behind the scenes:

Cleaning the Build Folder

First, I run a clean task using gulp-clean:

var clean = require('gulp-clean');

gulp.task('clean', function() {
  return gulp.src(BUILD_DIR, { read: false }).pipe(clean());
});

It’s referring to a global I defined earlier called BUILD_DIR, which is simply a string of the folder name: build (yay, no more compiled content mixed in with source!).

Compile JS

Then, I compile and minify my coffeescript files (of which I actually have none presently, ‘cause I’m not doing any JavaScript on my blog — yet) using gulp-coffee and gulp-uglify:

var coffee = require('gulp-coffee');
var uglify = require('gulp-uglify');

gulp.task('coffee', function() {
  gulp.src(CONTENT_DIR + '/coffee/*.coffee')
      .pipe(coffee({bare: true}).on('error', gutil.log))
      .pipe(gulp.dest(CONTENT_DIR + '/js/script.js'));
});

gulp.task('uglify', function() {
  var dir = CONTENT_DIR + '/*.js';
  gulp.src(dir)
      .pipe(uglify())
      .pipe(gulp.dest(dir))
});

These operate in another folder called CONTENT_DIR (which maps to /contents, the source folder Wintersmith uses by default). I want to do these operations on the source content so that Wintersmith copies it all wholesale with the HTML to /build.

Compile CSS

Next up, compilation and minification of CSS from scss using gulp-compass and gulp-cssmin

var cssmin = require('gulp-cssmin');
var compass = require('gulp-compass');

gulp.task('compass', function() {
  gulp.src(CONTENT_DIR + '/sass/*.scss')
      .pipe(compass({
        project: path.join(__dirname, '/' + CONTENT_DIR),
        css: 'css',
        sass: 'sass'
      }))
      .pipe(gulp.dest(CONTENT_DIR + '/css'));
});

gulp.task('cssmin', function() {
  var dir = CONTENT_DIR + '/css';
  gulp.src(dir + '/**/*.css')
      .pipe(cssmin())
      .pipe(gulp.dest(dir));
});

Just like my coffeescript->JavaScript, I’m compiling my scss files to a /css folder within /contents, and then minifying it in the same folder. Wintersmith will handle copying the results to /build.

Set the config, build, and deploy

There is no plugin specifically for Wintersmith and Gulp. Instead, there’s a module called run-wintersmith the intention behind which is to remain agnostic to things like Gulp. Using it is rather simple, and I do so right in the build-and-deploy task:

gulp.task('build-and-deploy', ['clean', 'coffee', 'uglify', 'compass', 'cssmin', 'set-production-config'], function() {
  console.log('Running Wintersmith build');
  wintersmith.build(function(){
    // Log on successful build
    console.log('Wintersmith has finished building!');
  });
});

All of the earlier tasks are called using dependencies — an array of the task names that need to be run, first.

Within the task callback, there’s only one method that matters here: wintersmith.build(). However, as you may have inferred from the dependencies, I have to set the config beforehand, as I had already set up Wintersmith to use a preview or production config depending on the task context:

var extend = require('gulp-extend');

gulp.task('set-production-config', function() {
  console.log('Creating production config');
  gulp.src(['./config.json', './config-production-base.json'])
      .pipe(extend('config-production.json', true))
      .pipe(gulp.dest('./'));

  console.log('Setting production config for Wintersmith\'s use');
  wintersmith.settings.configFile = 'config-production.json';
});

I’m leaning on a module called gulp-extend to merge and create a new config JSON file from the base config.json and config-production-base.json. Then, I set the config option on my instance of run-wintersmith to point to config-production-base.json.

Now, wintersmith.build() will work using my production options (specifically, to output to the /build folder, and set locals that are production-specific).

Deployment

After configuring my marcocarag.com and www.marcocarag.com buckets as static websites on the AWS Management Console, I was all set to deploy /build. First, I stored my AWS API credentials in a file called env.json (which, crucially, I made sure to add to my .gitignore to prevent from open sourcing my keys):

{
  "key": "[AWS KEY HERE]",
  "secret": "[AWS SECRET HERE]",
  "bucket": "marcocarag.com"
}

I installed a module called gulp-awspublish, and within the success callback of wintersmith.build(), I loaded and parsed env.json and sent /build through gulp-awspublish:

var awspublish  = require('gulp-awspublish');
...
  // Inside of the build-and-deploy task
  console.log('Running Wintersmith build');
  wintersmith.build(function(){
    // Log on successful build
    console.log('Wintersmith has finished building!');

    console.log('Reading AWS config');
    // create a new publisher
    var publisher = awspublish.create(JSON.parse(fs.readFileSync('./env.json')));

    return gulp.src('./' + BUILD_DIR + '/**')
      .pipe(publisher.publish())

      // create a cache file to speed up consecutive uploads
      .pipe(publisher.cache())

       // print upload updates to console
      .pipe(awspublish.reporter());
  });
...

The .pipe(publisher.cache()) bit is pretty cool; it maintains a set of hashes to determine whether a file has changed and needs to be re-uploaded. Effectively, it makes subsequent deploys far, far faster by reducing the number of uploads to only the changed files.

Some DNS changes

Now, I had to do what I mentioned earlier — point a new ALIAS record at my bucket.

Coincidentally, I wasn’t totally thrilled with the management tools of my registrar (Jumpline, which I was grandfathered into as they apparently took over my old registrar whom I’d been using for the better part of a decade). So I went ahead and signed up for DNSimple — again, an introduction brokered by work.

I turned off the DNS management tools at Jumpline, and instead pointed my domain at DNSimple’s nameservers, recreated all of my records over there, and added a new ALIAS record pointing at my bucket endpoint, marcocarag.com.s3-website-us-east-1.amazonaws.com. I also added a CNAME pointing www.marcocarag.com to the “naked” marcocarag.com.

Done…for now

And that’s that! My publishing workflow still has the same number of steps as before (building and committing), but there’s a (relatively) clean separation between the compiled site and the source. Perhaps the most fun part of the process was git rming all of the now unnecessary compiled content and Grunt-related files and lines from the repository.

The nicest thing, though, was bringing in Gulp. It’s easy enough to use that I want to do more with it. Most immediately, I should bring back my preview task, maybe with some livereloading.

Ah, who am I kidding… Knowing me, I’ll probably switch to a whole different platform by the time I write another technical blog post. Whatever the case, I hope others find this useful, and please let me know of questions you have or things I should do to improve this workflow!

When nostalgia hurts

Sat, 03 May 2014 14:10:00 -0400

I’ve always loved taking the Northeast Corridor Amtrak between Penn Station in New York and Union Station in DC. The trips served as time capsules, cutting through slow-moving, rarely-touched industrial parks, vine-encrusted warehousing, and humble mid-century exurbs. The sheer contrast with what I’m used to from either the destination or the origin made it easy to mentally escape via the view out the window.

I used to take these trains regularly, usually from the reverse perspective, as my way of going home for the holidays from college. Back then, a ticket on the Northeast Direct costed probably no more than $50 (now I was lucky to get one for $84, though on an admittedly much more comfortable train). I take it extremely rarely today, as my wife and I tend to drive down nowadays and use our car while in Virginia. But when I do, I’m back in the capsule again.

Occasionally, I see sparks of change as the radius of urban development inevitably kisses the extremes of trackside landscape — a tan and brick condo seemingly cut straight from parts on Home Depot’s shelves is surrounded by weary looking (but probably structurally much sounder) row houses, a pristine CVS gleams across the street from the century-dulled headstones of a tiny cemetery. But for now, the trip looks very much the same out the window, and it puts me in fairly the same headspace.

Though, the hue is far different this time. It’s now a time capsule, woven inexorably in the context of why I used to travel these tracks — to go home to my family, a staid institution in my life, not to live with my mind’s eye in a theme park capsule peering with rapt imagination for a brief few hours at human-less buildings speeding past.

And now, I’m sitting on an Amtrak, rumbling as fast as meager American trackage will allow, to go home to something different but oh so painfully similar. I’m going home to celebrate my five-month-old nephew Sammy’s baptism. But to a home empty of my dad, who succumbed a month before Sammy was born to a heart attack just after putting his shoes and jacket on to pick my mom up from the Metro. It’s about all I can think of.

As we rock comfortably to a stop in Wilmington, Delaware, a smattering of Amtrak stations away from DC, I realize how much I miss those capsules; my imagination through the Amtrak window inventing escapes away from the realities at either end of the trip. They don’t work nearly as well anymore.

Migrating my Blog's Content to Wintersmith

Sun, 30 Mar 2014 19:08:00 -0400

I know now that it takes an inordinate amount of effort for me to consistently update this blog. It’s not for want of content, but rather a problem of editing. To jump-start my stalled blogging in a sort of meta way, I’ve decided to migrate my blog from tried-and-true Jekyll to Node.js-based Wintersmith. Because what’s better to blog about than the blog itself? (The answer’s “a lot of things,” and I promise to get to those later, but this’ll be interesting, too.)

What is and why Wintersmith?

For a long time, I’d been considering migrating to Middleman because I’d been enjoying it much more often than Jekyll for a variety of projects.

But then a year passed, during which I’ve been a full-stack Rails developer (yes, I got a new job…one of those “things” I promise to get to later), and I figured I ought to try something completely new. Entre Wintersmith: a fairly mature Node.js-based generator that I picked out of several alternatives mostly because it seemed relatively easy for it to accommodate the many customizations I had done in my Jekyll blog. The whole of front-end development had changed around me with JavaScript at its center while I tooled around day after day following Railscast tutorials, so there was a lot for me to learn — including using npm, Grunt.js, and Node in general.

Migrating from Jekyll to Wintersmith was not completely straightforward, thanks to the aforementioned customizations. But the basics are a cinch, starting with…

Installing Wintersmith

This was the easy part — and I’m going to skip over the installation of Node.js, because in my case it already was installed (thanks to Rails).

The Wintersmith docs cover this effort pretty well:

$ npm install wintersmith -g

Then I made a folder for my new blog, and initialized Wintersmith inside of it:

$ mkdir marcocarag.com
$ wintersmith new marcocarag.com

After that, I can start a preview server:

$ cd marcocarag.com
$ wintersmith preview

And my new blog can be browsed at http://localhost:8080. Wintersmith comes with a few demo templates, located under /templates, and posts, each located in their own semantically named subdirectory under contents/articles with an index.md Markdown file inside. Adding a new post is a simple matter of creating another subdirectory under articles with its own index.md file.

Wintersmith’s operation is centered around config.json in the root of its install, which — similar to Jekyll’s own config — contains parameters that are important to the blog. Specifically, a locals object right up top that needs to be customized for my purposes:

locals: {
  name: "MarcoCarag.com",
  owner: "Marco Carag",
  description: "Marco Carag's blog about stuff he's into.",
  tagline: "Expert ♥er of things"
}

And that is the five-minutes-to-blogging process that is the Wintersmith install.

Migrating my posts

There are many ways to skin the cat of moving my Jekyll posts over, with the simplest being to rename them all to index.md and copy them each to unique subfolders underneath contents/articles.

This didn’t sit completely well with me, and it’s not because it’s a little annoying to create a new subfolder for each post — I could easily make a script or task to one-line that piece every time (like rake post <title> in my Jekyll blog).

It was more because if I were to change how post files are organized, I’m not sure that I’d want it to be the Wintersmith default way. Seeing all of the post files with date and titles in one place just seemed more convenient. Also, if I could get it to work in Wintersmith, it’d mean I could copy my posts nearly intact from _posts in Jekyll to contents/articles.

Fortunately, I didn’t have to figure it out… A fellow by the name of Andrew Clark (who’s own Wintersmith blog I leaned on heavily during this migration) modified Wintersmith to scrape a single folder for uniquely named Markdown files — exactly as I wanted. The key was in Wintersmith’s plugin/paginator.coffee; specifically, this bit:

getArticles = (contents) ->
  # helper that returns a list of articles found in *contents*
  # note that each article is assumed to have its own directory in the articles directory
  articles = contents[options.articles]._.directories.map (item) -> item.index
  articles.sort (a, b) -> b.date - a.date
  return articles

Which Andrew turned into this:

getArticles = (contents) ->
  # helper that returns a list of articles found in *contents*
  articles = []
  for key, value of contents[options.articles]
    articles.push value if value instanceof env.plugins.Page

  articles.sort (a, b) -> b.date - a.date
  return articles

…leveraging the filename instead of the directory names to create an array of articles (which are actually pages, which are actually my posts). And with that, I could literally copy all of my post files from _posts/ to contents/articles.

Changing Permalinks

Wintersmith posts and pages by default get urls like /this-is-my-post-title/index.html, thanks to the one-for-one mapping of the subfolders under contents/articles. For my purposes, though, I need to reproduce the date and title-based permalinks of my Jekyll blog.

Custom permalinks in Wintersmith are made possible via a front-matter property called filename, which instructs Wintersmith how to output the compiled HTML:

# To yield a permalink of /2014/03/30/heres-my-post/index.html
filename: "/:year/:month/:day/:title/index.html"

That’s good enough to reproduce the urls I want. But it kinda’ sucks to have to repeat it in every post. Andrew Clark to the rescue again. His post, How to remove the boilerplate from Wintersmith blog posts, was actually how I found his ever-helpful blog in the first place.

In that post, he outlines a plugin that he wrote which enables a Wintersmith blog to set global filename values, as well as templates:

# plugins/blog.coffee
module.exports = (env, callback) ->

  defaults =
    postsDir: 'articles' # directory containing blog posts
    template: 'post.jade'
    filenameTemplate: '/:year/:month/:day/:title/index.html' # Here's the magic part

  # assign defaults for any option not set in the config file
  options = env.config.blog or {}
  for key, value of defaults
    options[key] ?= defaults[key]

  class BlogpostPage extends env.plugins.MarkdownPage
    ### DRYer subclass of MarkdownPage ###

    getTemplate: ->
      @metadata.template or options.template or super()

    getFilenameTemplate: ->
      @metadata.filenameTemplate or options.filenameTemplate or super()

  # register the plugin
  prefix = if options.postsDir then options.postsDir + '/' else ''
  env.registerContentPlugin 'posts', prefix + '**/*.*(markdown|mkd|md)', BlogpostPage

  # done!
  callback()

Saving that to plugins/blog.coffee and including it in my Wintersmith blog by adding this snippet to config.json:

plugins: [
  "./plugins/blog.coffee"
]

…saved me the effort of having to add filename to every one of my posts.

Unfortunately, there’s many reasons yet for me to inconveniently edit them all, as we’ll see in subsequent posts.

Up next: Templates and Styles

At this point, I have a working Wintersmith blog with all of the posts of my old Jekyll one, accessible at the same urls as the original. If I wanted, I could just run $ wintersmith build, take the resulting output of /build/* and replace my repo with its contents, push up to master and be done.

But as much as I actually really like the default templates that come with Wintersmith — in many ways, I prefer them to my own — I wasn’t prepared to get rid of my old design. If nothing else, it gives me an excuse to dig in even deeper into using Wintersmith and a Node-driven blog.

So in my next post, I’ll go a layer up and talk about migrating my Jekyll blog’s layout templates and stylesheets, which comes with the added bonus of setting up Compass — not a default part of Wintersmith.

Jekyll Plugins in Github Pages

Wed, 22 May 2013 22:08:00 -0400

I thought it was high time I made some effort in cleaning up and streamlining my post composition workflow, while riding the wave of my small redesign).

The first thought I had was that I should damn well try to use Markdown, as that’s what most sane people who use Jekyll (and Middleman and other blog-friendly generators) use. Along those lines, Jekyll Bootstrap comes with a handy Rake task: rake post title="", which will generate a Markdown file in _posts with the appropriate filename and YAML frontmatter. I made a minor tweak to include the time, as I use that in my post layout.

Next, I wanted to stop the copy pasta involved in rendering my silly 3D shadow effect with images. So, I made a quick and dirty (I mean really dirty) Jekyll plugin that acts like a view partial, taking in the necessary parameters to spit out my precious markup without me having to repeatedly type/paste said markup. Works well enough, but I’m sure there’s refactoring to come (like, I hate that I’m not passing my parameters as an object).

In order to use my plugin — and any plugin, for that matter — I would have to adjust my workflow with Github Pages, since it runs Jekyll in “safe mode” and doesn’t execute plugins (basically, arbitrary Ruby, so that seems reasonable of them). This basically means I need to compile the posts and pages on my local machine, rather than let Github Pages do it. ixti has a good post on how to go about this in a way that isn’t too painful; basically, I moved my repo’s master branch to a new branch called “source”, made that my default branch in Github, and used the rake publish task ixti outlined to do a Jekyll compilation, move the resulting _site output to master, and force push it up, all in one command.

Felt a little nervous doing a force push, especially to master, but that was just my conditioning after years of avoiding exactly that. Besides, my source branch is effectively the new master. And now I can use Jekyll plugins on my Github Pages site!

Some things I have to be careful about: it doesn’t matter what’s pushed up to origin/source — the Jekyll compilation that happens as a result of rake publish will compile anything and everything. So, I need to make sure I’m clean locally before publishing; I basically ensure that git status returns nothing to commit before I dare rake publish. I could surely adjust the Rake task to smooth this over — a Github WebHook feels like the right place. That’ll be for a future iteration…

Hell, I’m just happy to be using Markdown!

My New Daily Beater: The Seiko 5

Mon, 20 May 2013 22:43:00 -0400

I’ve been wanting for a while a more practical daily-use watch. One that is clearly readable in light and dark, not oversized, water resistant, and shows the date. I’m surprised it took me this long to find all that in Seiko’s venerable “5” series.

My Parnis pilot watch, while running strong and looking great for a year, at 44mm was starting to feel large on the wrist. My Hamilton at 42mm was not much better — and thanks to its complicated automatic movement was thicker and heavier. I also missed having a watch, like my old busted Garton, that would be readable for a couple of hours in a dark movie theater — which neither of the above could accomplish.

The “5” is a line of workhorse automatics by Japanese horological titan, Seiko, that meet five criteria: unbreakable mainspring, shock resistance, water resistance, automatic movement, and a day/date complication (according to the Seiko Branding Dictionary on WatchUSeek. They also frequently meet one more: extremely long-lasting visible glow-in-the-dark lume. And a seventh criteria: often costing under $100. It’s a wonder I never happened on these when I first sought a mechanical watch.

A Dress Watch in the SNKL29

I made a decent excuse to get my first Seiko 5: I needed a good dress watch for the occasional wedding. It had to sport a white or silver dial, and look good with a black leather strap. The SNKL29 at $64 was a bargain match. I loved the watch so much that I got it a brown leather strap for near-daily use. It really sort of blew me away with how much watch it was for the money. Just for the terrific day and date display, and perfect 38mm size, I’d be happy. But it sports a beautiful dial with lovely and classic printed Roman numerals around a simple track of second markings that also sport shockingly strong dot lume at the hours. The plongeur-style hands are also exceedingly readable through the night. Literally — I could still read the time in the darkness of extremely early morning (the few times I was awake).

One important thing to note is that the SNKL29 sports an 18mm lug width — not the 19mm specified on its Amazon page. This was annoying when I got my 19mm straps, as I had to shave a bit off of them to fit. It’s also got a silver dial — not white. I actually think white would feel dressier, but the silver has a nice sheen, and there’s a kind of pinstripe guilloche-like effect inside the seconds track.

The Perfect Daily Beater in the SNKL07

Recently, I came across this photo of the SNKL09 in this addictive thread, and fell in love. The big hour markers, the black dial mated with an army-green canvas strap, the fire-red second hand… I knew my days with just one Seiko were numbered.

I’d placed both the 09 and its Navy sibling, the SNKL07, into my Amazon wishlist. The 07 dipped below $65 a few weeks ago, and I took the bait.

Other than the obvious dial color difference, the 07 has a white instead of red second-hand, and a white background to the day/date. This actually makes it feel more formal in my mind than the military-like 09. Compared to the dressier silver-faced 29, it’s around the same diameter, but the crown is larger and placed more traditionally at the 3-o-clock. On the 29, the tiny inset crown helps maintain a clean look on a dressy watch, though it can be hard to access; on the 07, it’s more practically sized and positioned for a much more general-use watch.

Despite not feeling as military as its black-dialed red-handed 09 brother, the 07 is still gorgeous. It looks good on my olive-green NATO strap, but like my Hamilton this deep navy watch looks great with light browns. With a 20mm lug width, it can accommodate all of my existing straps, and I found its ultimate pairing with my thick caramel-colored NATO leather strap. It’s a bit weathered of a strap after accommodating the harsh-edged 44mm Parnis for so long, but I’ve come to enjoy the added texture. It’s literally become pretty much my daily watch.

Seiko 5 Features

Both Seikos are perfectly sized at around 38mm in diameter, and relatively narrow and light. They aren’t quite as skinny as my Parnis, which is understandable as an automatic movement is typically thicker than a manual-wind (also, undoubtedly the water resistance adds girth thanks to things like gaskets), but they’re not thick either, and are obviously narrower in diameter and look more proportional on my skinny wrists.

The movement in both is, like nearly all Seiko 5s, the 7S26.

It’s an automatic movement that is the result of decades of polish and streamlining by Seiko to the point where they could churn these out blind. It’s undecorated and purely utilitarian — the print on the back claims 21 jewels, but none are really visible through the transparent casebacks on my 07 or 29. Like all mechanical watches, it’s not going to be as accurate as a quartz. But I realize after years on mechanical watches that I don’t really notice or care about the inaccuracy.

The day/date function on both watches is about as good as it gets. First off, you get the day, while most watches are content with just the date. Who cares that I usually always remember the day of the week? There are less useful complications out in the watch world. There’s also the option of Spanish rather than English days. Also, “SAT” takes on a nice baby blue, while “SUN” is a striking red.

And the lume really deserves reiteration. I’m spoiled for watch lume thanks to these Seikos, to the point that the lume on my other watches make little sense in comparison. I wasn’t kidding that these are readable after hours in the dark. And I don’t explicitly “charge” these watches — this is just with the general office light and sunlight they receive during a rather average (I think) workday.

Other 5s…

It’ll be hard to make the 07 my last Seiko. It might swing too closely to the 09 (I’d sooner just have the second hand replaced for a red one than also nab the 9). But at least half a dozen Seiko 5s from the amazing WatchUSeek thread have made it to my wishlist or bookmarks. Like the sporty SNKK27K1, which looks especially great on tan leather. Or the SNZJ63. Or for ultra readability, the SNK381 seems hard to beat.

And when it comes to a reliable and affordable automatic it seems hard to beat the Seiko 5 series in general.

Problem with CSS viewport units for width?

Fri, 10 May 2013 09:07:00 -0400

Getting some unexpected behavior when using viewport units (vw, vh, vmin, and vmax) to size width in Webkit browsers:

When elements have a fixed width set in a viewport unit, their parents no longer contain them properly in Webkit browsers.

Open the following in Chrome (tried version 26 stable, and 29 Canary) or Safari 6, and compare to Firefox (tried in version 20):

Check out this Pen!

Here’s a screenshot of what that looks like in Chrome 26:

Here’s the same thing in Firefox 20:

What I’d expect is the Firefox case, where the dark green parent element properly stretches to fit the width of its content (in this case, the child elements with fixed viewport-unit widths).

What do you think? A real bug? Certainly, one of them is wrong, and I’m pretty sure it’s Webkit, since the behavior with other types of units (px, em, rem, etc.) is like the Firefox screenshot. I’ll have to check it out in IE10, which supports viewport units as well, according to Can I Use.

Additionally, it looks like there’s weirdness in the height, considering the lime green box in the Firefox screenshot is so much taller. Probably a difference in what each browser is considering the viewport. I’ll investigate that further.

Redesigned-ish

Thu, 09 May 2013 11:59:00 -0400

Been having the itch since the beginning of the year to make some changes to my year-old site design. So I worked on it on-and-off for several days, and launched it last week. In addition to some small clean-up, I’ve changed some fonts and colors. I’d barely want to call it a “redesign” at all, but there are some fun details I want to note.

Colors were the biggest deal for me. I was so done with the white over deep navy, and the radioactive green — it started to grate on me. So I sought a more neutral and calming palette. I still liked the letterpress feel, so I picked a cream color that could be like paper. And all of the type now has a subtle bevel.

The next obvious change are fonts. Picking new type probably took the most time. I didn’t change the logotype, because I still like Audimat in the block cut-sort of effect. But, I didn’t like Audimat for the headers as I was using it before. So I replaced them with the rather popular Kaffeesatz, by Yanone — an eminently readable sans-serif typeface with a whimsical kind of handwritten feeling. I picked it mostly because, outside of being beautifully treated by Yanone, it’s rather condensed, and I love its relatively large x-height. I’ve got a thing for big x-heights.

X-height and whimsy also led me to my choice of body font: a serif face by Oriol Esparraguera called Afta Serif. I was drawn to its visual rhythm; it’s fairly light in weight, and the curves are a bit squarish, which combined with the generous x-height emphasizes the whitespace and increases (in my opinion) readability. I also love the lowercase “k” letterform.

Finally, I tweaked the homepage layout to be single column, as I felt the old two columns were too claustrophobic and it felt nice to simplify.

I still need to do up the darn tags page, which I’d never touched to begin with since moving to Jekyll. Also, after spending an entire blog post preaching about it, I need to do a styleguide for this site.

But, this redesign-ish work has gotten my juices flowing. Maybe I’ll actually start posting more regularly!

April Had Some Great Dev Culture Content

Wed, 01 May 2013 13:00:00 -0400

Don’t know what it is about April, but there were a lot of great posts and presentations about development team culture that really struck a chord in me. Here are a few faves; take a look if you haven’t already.

Manifesto for Minimalist Software Engineers: I noticed this “minifesto” by New York software developer, Pablo Guevara, when it got Twitter buzz sometime in the early half of April, and have been mentally repeating parts of it in my head as a mantra ever since. “First do it, then do it right, then do it better.” “Fail fast, learn soon.” “Techincal Skill is the mastery of complexity, while Creativity is the master of simplicity.”
Bacon is Bad For You: This is a presentation done by the amazing Austin-based frontend developer, Garann Means, for BACON conference in which she voices her concerns about developer monoculture, and how it can deter people. Truly hit home for me as someone who’s felt alienated on certain dev teams, and who’s probably done his share of alienating on others. The slides speak terrifically for themselves if you can’t spare the full half hour for the video. Especially love the comparison between the “standard” working professional, versus the professional developer.
Cultural Confusion: This is a post by Jason Stirman (Medium, Twitter) for Medium (a new-ish and beautiful kind-of-collaborative sort-of-blog…It’s tricky to describe) in which he basically nails it in terms of what’s important in forming a healthy culture: the people! There are a couple of great points he touches on: having a diversity of opinion, humility, making sure you actually get along with the candidates you’re considering. It’s easy to ignore how important personality is when staring down a list of awesome work history and accomplishments on someone’s resumé. Love his “airport test” idea. And this:
“The damage a bad culture fit can cause isn’t worth the productivity they can provide.”

I’ve been learning lately the sorts of things that matter to me in a work environment, and I realize I can distill it down to this: don’t hire or be a jerk. Be humble. Solicit feedback. Trust others, and work together.

Just like any community of people, it’s hard sometimes to remember that you’re all on the same team. Being individual is important, but be careful to avoid selfishness. It’s crazy how often I have to remind myself of that.

NY ♥ Boston

Thu, 18 Apr 2013 14:19:00 -0400

Did this quick logo mash-up in SVG (exported to PNG and WebP) to express support for Boston during these trying times. Stay strong, Boston!

Please take, use, and change as you see fit!

Self Hack: Take any train at 23rd Street and 8th Avenue

Tue, 15 Jan 2013 18:13:00 -0500

One of my New Year’s Resolutions (really, the only one with a specific action) is to write a blog post at least once a week. The idea is that I’ll get better at writing with frequency. As you can tell, I’m already behind, but here’s to catching up!

Part of fulfilling my quantity-for-better-quality strategy means smaller, sillier posts (as if my prior posts bore any heft) like this one, in which I simply write a tip to myself whenever I find myself on the local-only downtown platform of the 23rd Street and 8th Avenue subway stop.

The tip?

When going to Brooklyn, take any train that arrives.

Why give myself this sort of advice? Because I’m a little obsessed about minimizing trips on NYC public transit (I “pre-walk” — move to the part of a platform or train where the door is closest to the exit at the destination — nearly 100% of the time, for instance), and recently I made the mistake of not getting on board a downtown-bound E train (which terminates in downtown Manhattan, and doesn’t reach my ultimate transfer to the G in Brooklyn) that arrived at 23rd street in anticipation of riding a C train all the way to Brooklyn.

The fact is, either train would have taken me to the next stop, 14th street, where I could have transferred either to an A from a C, if one happened to be arriving then, or from an E to either an A or a C — whichever came first. At worst, I would have ended up waiting for the very same C train, and at best (which ended up being the reality that I passed up on), I would have caught an arriving A and been well on my way to Brooklyn well before a C finally arrived.

I was thinking I would have been more comfortable taking the C all the way (the quite viable “reduce transfers” strategy), but even in the worst case, I’d at least be waiting at 14th street for the C, which, with its numerous benches and lovely Tom Otterness sculptures, is far more comfortable a waiting place than 23rd, where passing A express trains just serve to aggravate standing passengers-to-be.

So, note to self: always board any local train that arrives at the 23rd street downtown/Brooklyn bound platform. And also try not to obsess about transit so much.

Trust In Styleguide

Tue, 04 Dec 2012 18:09:00 -0500

Increasingly, web designers of today also are developers — which is awesome. However, in my experience, most I’ve worked with have never touched code, and none expect to as a part of their day-to-day. For this and many other reasons, coded styleguides are a must.

The styleguide conversation’s not a new one — Anna Debenham, for instance, wrote about it last year for 24 Ways. I’m going to avoid trodden ground as best I can. Instead, I wanted to show how styleguides have helped myself and my coding and designing coworkers at HowAboutWe, and hopefully convince others to adopt them.

Styleguide as a Proof-of-Concept

My last project at HowAboutWe was the two-month inception of the HowAboutWe for Couples minimum-viable-product. By that point, we’d just started to build out an internal team of designers.

She was certain many headers and buttons would have to be cut images. It would be rocky between us if I couldn’t convince her of otherwise.

The designer in charge of Couples had a mixed relationship with developers in the past. She didn’t trust in the capabilities of modern browsers, especially with regards to rendering drop shadows and web fonts, despite leaning on both in her designs. She was certain many headers and buttons would have to be cut images. It would be rocky between us if I couldn’t convince her of otherwise.

So on the engineering side, we set out to prove her wrong by incepting the HowAboutWe for Couples Styleguide, starting with buttons. And she was convinced.

Another fun thing I managed to convince her of that had even me a little suspicious was using a web font for all icons. And that’s the other useful thing about a styleguide — it’s a place, isolated from the other complex layers of implementation, to prove out ideas and hunches. A lab where things can be tried, evolve and change without too much difficulty. It could have been that the maintenance cost for a font icon or all-CSS buttons would have been too high; a styleguide is the place for figuring that out. (Spoiler: Both succeeded.)

For Onramping and Implementation Speed

Designers weren’t the only new folks at work. We’d also been recruiting developers at a fast clip. For these folks, our styleguide was also a crucial on-ramping tool. They could quickly grasp most all of our internal HTML and CSS coding and naming conventions, and could be prepared much sooner to contribute real work.

And delivering work is itself simplified. With modularized styles and markup centralized, organized, and presented in one place, the frontend for new features becomes a much simpler process. It can also be parallel-ized with confidence when developers have a styleguide to consult.

For Coding and Designing Authority

The styleguide should have the rule of law. If some design concept isn’t there, whether it’s at a high level like paginated navigation or much more granular like a font size, there should be a good reason to add it in — otherwise, whatever’s already in the styleguide should be used, instead, or the styleguide should be updated to the new design.

Clearly, it requires a special kind of discipline to enforce the styleguide so strictly — but in my experience, this level of tension between design and styleguide is important. On frontend teams with more than a few developers, nonchalance about (or complete lack of) a styleguide leads inevitably to massive bloat and redundant implementations.

…aggressive iteration without proper styleguide discipline (by both developers and designers) lead to a stylesheet so large that IE8 couldn’t parse it completely…

This was a lesson learned the hard way in the HowAboutWe dating site, where aggressive iteration without proper styleguide discipline (by both developers and designers) lead to a stylesheet so large that IE8 couldn’t parse it completely (though, that wasn’t the only symptom; inefficient use of sass also played a big role). Disciplined styleguide usage makes maintenance far easier, which increases developers’ and designers’ happiness.

CSS buttons in Couples styleguide.

To Help Finalize Design

No web designer of today should consider a design that only exists in Photoshop as final. Things will look different in browsers, and designers will want to tweak accordingly — slightly increasing line-height, adjusting a color, or changing a margin.

Additionally, few designers I’ve met have worked out user interactions in Photoshop. It’s something that needs to be seen in a browser before being settled. In HowAboutWe for Couples, the aforementioned buttons’ initial state was designed in a PSD, but interactive states like loading weren’t. Coding the styleguide was instrumental in working out those interactions, and many other kinks. Which leads cleanly to the next benefit…

For Easier Redesign

Having a styleguide in place means the broad UI concepts of the respective website have been worked out. And in turn, that makes the inevitable redesign much easier.

Naturally, not all concepts in a styleguide will survive a redesign. This could be an indication that those concepts were too specific and high-level in retrospect. But, in reality, the balance of what’s too high-level for the styleguide and what’s not depends on a lot of things. If the implementation of a particular component is reused often enough in designs, even if it’s fairly complex, then it deserves to be in the styleguide for developer ease. It’s one of the reasons the Couples styleguide has a boilerplate section.

Coupling to the App

One last departing bit on where the styleguide lives compared to the site(s) it’s for. I think it’s useful to have the styleguide point to the very same stylesheets of its corresponding site(s), which is what we did at HowAboutWe. By doing so, the app’s stylesheets are implemented with the styleguide. And in future maintenance, updates in one force developers to keep the other current, as well.

Conversely, it makes little sense to share HTML directly, since it’s hard to separate HTML from content that isn’t relevant. Instead, denote the relevant markup blocks in the styleguide somehow — we used HTML comments in the Couples styleguide, only because we were too lazy to get textareas with the relevant markup in them implemented.

12/13 Update — Lenny Sirivong commented below about a bit of simple jQuery by Dave Rupert that parses for data-codeblock attributes and presents them as a pretty string that can be easily copied. Good quick way to get code blocks from your code demos!

Middleman for maximum frontend enjoyment!

In case you were wondering… The HowAboutWe styleguides are implemented via the awesome static site generator, Middleman, which is like Jekyll, but supports Haml for HTML, Compass for CSS, and CoffeeScript for JS. They lived in subfolders within their respective Rails applications, and spit out the compiled pages into /public to get served up outside of the Rails stack.

In typical “me” fashion, this endorsement has been a long-winded, and I thank you for reading this far. I’d love to hear if and how styleguides have helped or hurt your own work, so please comment your thoughts!

Merry frontend-ing!

Thanks, HowAboutWe! Hello, Bonobos!

Mon, 19 Nov 2012 18:26:00 -0500

Bonobos

Bittersweet post here, to announce that I’ve left HowAboutWe to do frontend development for Bonobos’ New York Office.

It’s bitter because the HowAboutWe team is the best I’ve ever worked with. Not surprising, because the standard and culture there was cultivated by my good friend, the brilliant John Pignata (now at Groupme), who as CTO two years ago lured me into the startup world as employee five (or thereabouts). It was a flat and flexible team, with no frontend or backend divisions — just web developers, achieving the singular goal of a successful web product.

Their growth (and my growth) over the past two years has been astounding, and I can’t be grateful enough for that, and being allowed to help shape it, too. If you’re looking to work with one of the best teams in New York, and are up to a challenge that’s far more than just coding, then drop them a resumé.

Now the sweet stuff. When thinking about what’s next after two years of the amazing HowAboutWe, one of the options that came to mind, literally, was Bonobos. As you may have noticed, I’m into menswear. Bonobos, as a producer of quality menswear that started out online, would be perfect, if only they had a New York technology team, I thought. (It’d be a good fit, if you will. You won’t? Okay…)

Cut to today when they’ve cleared a space for me as their first New York-based frontend developer, with machinations of fleshing out a larger tech team here at their headquarters in my favorite city, and it’s as if they read my mind. I’ve joined at somewhat a hectic time, with Cyber Monday looming large in their Chelsea office. But I don’t mind hitting the ground running and I’m excited to apply my HowAboutWe growth at Bonobos (which, by the way, has a frontend in desperate need of help). And as another plus, I get to occasionally get out of town to visit their Palo Alto office.

So, hello, Bonobos! And thanks, HowAboutWe! And I guess, expect some Bonobos product reviews on this blog soon. :)

The best team I’ve ever worked with on a boat in NY Harbor. I’ll miss you guys!

NATO-Style Straps Rock

Sun, 29 Jul 2012 17:33:00 -0400

“It bears repeating that NATO-style straps do wondrous things. Like otherwise dull clothing, watches transform with some accessorization — making them something like the Russian nesting doll of accessories. Plus, NATO-style straps are so cheap and mindless to deal with, it’s a fun transformation to make.”

That said, I’ve gravitated towards certain combinations. You can do no wrong combining caramel-colored brown and black, and I found this particularly beautiful sample on eBay to marry with my Parnis:

Parnis black pilot watch with a light-brown leather strap from eBay.

Leather’s tricky, because there’s a minimum thickness to it (if it’s quality leather). This combination with the Parnis actually requires me to remove the springbars to install; slipping it on the standard way would scrape the leather up somethin’ fierce. But I don’t see myself swapping this strap off very often.

And best of all, thanks to the ever-steadfast combination of khaki and navy, I’ve reincarnated my old Hamilton with the khaki-colored nylon:

Can’t go wrong with Navy and Khaki.

I guess it helps that the Hamilton has both the words “Khaki” and “Navy” in its name.

My new daily beater.

I’ve upgraded to an Olympus E-P3

Wed, 25 Jul 2012 23:37:00 -0400

And I admittedly feel a bit of separation anxiety.

I upgraded today from my Olympus E-P1 to the far more convenient E-P3. It’s everything the E-P1 was, plus all that it should have been, including such basics as an orange focus assist light and a built in flash, and such advanced features as the ability to support an electronic viewfinder and a swappable hand grip. It will make my shooting life faster and easier, and I’m excited about the countless brain cells that will be saved going forward.

Perhaps best of all, I got the near-new body with a gorgeous leather case for $425 via Craigslist — significantly cheaper than retail, and even undercutting the current average on Ebay, if you count shipping.

A professional photographer notices my ever-present E-P1 at a party, and wants a picture of it. My Dad’s old Minolta MD Rokkor-X 28mm f2.8 is affixed, along with a Metz 36 AF-4 Mecablitz flash.

And yet, I’m feeling a little bittersweet about it. Not because of the idea of using the E-P3, but because of the idea of retiring my E-P1. I got the E-P1 two winters ago, also used (far more used, in fact), and have grown as an amateur wannabe-photographer significantly through that time. Though I never used every feature of the camera, what I did use has become programmed reflex in my mind and hands. I just know what to do with the camera, and I know what it will give me in return, and that level of comfort is surprisingly profound. In the few dozen minutes I’ve spent so far with the E-P3, I feel like I’m using someone else’s machine; the shot I took of it above using the E-P1 (with my workhorse Panasonic 20mm f1.7) felt like returning home after a tiring business trip.

More than that, the E-P1 has gone places, and recorded some of my fianceé’s and my most important moments: my fianceé’s mom visiting, friend’s weddings, Christmases, Thanksgivings, hiking trips, a vacation in Thailand, our cats… Thinking back, I don’t wish I had an E-P3, or any other “better” camera, that whole time. I’m thankful I had my E-P1 in my hands, the most trustworthy camera I’ve used yet. While the comfort level issue with the E-P3 is probably just a matter of software, and will be learned, I won’t soon forget all the moments the E-P1 has captured.

An unintentional self portrait as I quickly try to capture the room at a party via mirror.

For sure, this sentimentality for a piece of consumer electronics is a decidedly First World Problem, and you won’t catch me whining after this about the E-P3. I will eventually be far faster at the E-P3 than I ever could have been with the E-P1, and taking much better photos. I’ve been pining for a replacement to the E-P1 for maybe half a year now, since probably just before the E-P3 launched. I use an array of manual lenses, and it’s annoying to use the rear LCD on the E-P1 to manually focus. The E-P3 can take a viewfinder that makes that process much easier, and it even boasts so high resolution of a rear LCD that I can nail focus easily without magnification. The E-P1 lacks a focus assist lamp, making autofocusing in low light challenging. The E-P3 not only has the assist lamp, but also a built-in flash.

But despite my pining, and near-daily browsing of new micro 4/3rds developments, I never anticipated missing the E-P1. I never feel that way about electronics. I guess sometimes photography isn’t just about the photos.

Thanks for the thousands of shots, Olympus E-P1.

My trustworthy E-P1 in its most common configuration this year, with a Panasonic Lumix 20mm f1.7 lens, taken with the E-P3 and the Canon 50mm.

Ratio Clothing Review

Sun, 01 Jul 2012 09:27:00 -0400

How about something made in the USA this American Independence Day weekend? Some weeks ago, I arrived at my apartment door to a hotly anticipated Fedex box. It was my first custom shirt from online made-to-measure shirtmaker, Ratio Clothing.

Out of necessity because of my small frame, made-to-measure is basically the way I shop for shirts nowadays, amongst other things (I’ll soon enough post about suits and outerwear). While I really like Joe Hemrajani’s MyTailor.com, there are a lot of new players to the scene, and I’ve been keen to try them out. One of the noteworthy ones is Ratio Clothing, which I heard about courtesy of the Indochino Review blog.

Ratio Clothing was started last year by Eric Powell in Colorado, and distinguishes itself from other made-to-measure online shops by doing all of its shirtmaking in the USA, while remaining competitive on price. Their most affordable fabrics clock in at $89 and scale up to around $150 or so. Their fabric selection is slim, but well curated, with a great array of basics and some patterns I haven’t seen elsewhere.

Their website is a little light on options, especially if you compare it to MyTailor.com (honestly, I shouldn’t make that comparison because MyTailor’s comprehensive to a fault). But again, good basics are there in terms of collars, cuffs, pleats, pockets, and plackets. Might be notable that there’s no point collar option; maybe things are trending to wider spreads? (In my mind, not a bad trend, if it is one.)

Ratio packages their shirts well for shipping.

Ratio accepts a couple of methods of sizing you up. One is to specify five major measurements via a small form: neck, sleeve length, chest, shirt length, and “desired fit” (two subjective categories of “Classic” and “Ratio Slim”). The other is to send Ratio (either via e-mail, or as I did via the “Special Instructions” in the order cart) a far more detailed set of measurements using either yourself or your best fitting shirt as the basis. Since my last MyTailor shirt was measured by Joe in person, I used measurements off of that shirt with some tweaks.

Like with orders from other companies, I picked out a fabric that I didn’t already have — a distinctive plaid called “Ogden.” And some of my normal personalizations: English spread, no pleats or pockets, mitred cuffs, and a plain placket. Ratioclothing.com is rather minimal and straightforward to use, but if I really had to nitpick, they’re clearly missing photos. There’s a compelling “My Design Preview” tab presumably based on the customizations picked that I haven’t seen work yet at all. Ah well, spread collars are spread collars — what could go wrong?

The order took somewhere over two weeks to completely manufacture, and thanks to fast interstate (as opposed to international) shipping (from North Carolina, interestingly enough), I had the shirt about two days later. Three weeks from order to shirt is none too shabby, I think; hopefully, they can keep that pace as orders scale.

Ratio sure packages their shirts with care — again, an improvement over MyTailor in this department. The well-folded Ogden plaid shirt was wrapped carefully in plastic, wrapped again in tissue, closed with a branded sticker, and lain in a lovely branded cardboard box. A care instructions card is tucked underneath the shirt. Spoiler alert: Don’t use a drying machine!

More lovely packaging in the form of a cardboard belt.

The shirt is made well, the plaid aligned well throughout. The Ogden plaid fabric is thin — appropriate for summer. Fit-wise, it might be my favorite feeling shirt yet — the closest to a second-skin like feel, without being restrictive. The light and non-stiff fabric likely helps here, too. Joe’s measurements held up well with my tweaks for the most part; but if I’d committed one mistake, it’s the collar, which I generously increased because I get futzy with too tight collars. Turns out I overestimated, and there’s a lot of space if I button all the way up. That said, I won’t button this casual shirt to the top very often.

Fit is probably my favorite of the MTMshirts I’ve gotten yet.

Speaking of collars, Ratio includes two stiff and weighty plastic collar stays. Not brass, but far better than the wilt-prone stays from off-the-rack.

Like many made-to-measure vendors, Ratio offers generous sizing guarantees: you can return a shirt paying only for shipping to Ratio for free alterations (~~not sure if they’ll remake completely~~) within thirty days. I might be more comfortable if they instead offered to pay for local alterations (like another favorite of mine, Indochino), but I presume Ratio would rather its product go under only their own needles and I’d be easily convinced to agree. Shipping within the US is relatively cheap, anyway, especially for a perfect fit. That said, I don’t feel a need to take advantage of the guarantee with this first shirt.
Eric confirmed to me that they will remake a shirt if it’s that unsalvageable

In a nice touch, about a month after ordering, Ratio’s Eric Powell emailed me to follow up on my satisfaction. I shorted him on details pending this post, but it was thoughtful to reach out in such a personal way.

Marco,

I saw that your shirt was delivered, and wanted to see how the measurements we discussed turned out. If you have any fit issues at all, please let us know. We’re pretty serious about getting you in a perfect-fitting shirt, and sometimes (though not often) it takes a round of alterations to get to that point.

Just let us know, and thank you for becoming a Ratio customer!

Best,
Eric

This definitely won’t be my last order with Ratio, and since getting my first shirt, I’m excited to see that they’ve added a host of new fabric options. I look forward to what’s to come to Ratio Clothing.

Chino Pons and Grupo Irék

Tue, 19 Jun 2012 18:15:00 -0400

Around five years ago, I first met Chino, Eddie, Hensy, and Tosso when they were part of a traditional Cuban band named Conjunto Guantanamo. They performed regularly at one of my favorite bars near my work in DUMBO.

The ever-smiling, and fiery handed Eddie Valentin, probably the nicest bongosero you’ll ever meet. Hensy is on bass next to him, then Chino, and Tosso on tres guitar.

Chino and I became close friends shortly after, giving me tips on everything from the clave, to West Village pizza joints and jam sessions, to seeking shelter during penniless times under the Manhattan Bridge (some tips more useful than others, but all memorable). And by introducing me to New York’s incredible Latin music scene, he helped pry open an unexpected chapter of my life: as a passably decent amateur musician. In my craziest times, I pulled my violin out as often as five nights a week with a variety of Cuban and salsa bands in the city and met dozens of awesome musicians and dancers, before exhaustion caught up with me and I realized I couldn’t do that anymore while I still had a day job.

Grupo Irék excels at drawing a dancing crowd.

A terrific singer and spectacular dancer from Cuba, he now leads his friends in a band named Grupo Irék, which for years now has performed Saturday nights in Carroll Gardens at a restaurant named Pane e Vino. It’s a great night of music that draws many awesome dancers, and I highly recommend it if you’re in the area and looking for something to do on Saturday night.

Chino and his beautiful wife — whom he met, unsurprisingly, via the salsa dancing scene. They just got married about a couple of months ago!

Performing a mix of originals, classic Salsa tracks from the likes of Héctor Lavoe and Rúben Blades, and Buena Vista Social Club standards, they also gig at the Boom Boom Room at the top of the near impossibly swanky Standard Hotel (Hensy, the bassist, recounted one guest putting down $4,000 on a single bottle of champagne), and the chic Thom’s Bar in SoHo. I haven’t seen them perform at either of those spots, but I think Grupo Irék is at their best with smooth-moving dancers filling the floor in front of them, and not as the background music to expensive martini sipping (though, I’d wager the latter pays better).

My first ever public performance in NYC, with Conjunto Guantanamo at the 2007 Art Under The Bridge festival.

I remember one gig maybe four years ago at the Upper East Side club Session 73 at one of their Monday Salsa nights. The band was filled out with the incomparable trombonist Reut Regev, and a pianist, with barely enough room for me nestled behind the sound board to stand and await a solo, watching a hundred excellent, excellent dancers move like I’d never seen before. But then the coro reached its end, the band stepped back, and I gulped and stepped forward. Terrifying, fun, exhilarating, and unforgettable.

Incidentally, years later, they sound better than ever. Please go check them out, as they are awesome!

Grupo Irék at Club LQ, with classic, dancing Chino. An amazing gig I regret missing.

Futzing Around with Icon Fonts and SVG

Tue, 12 Jun 2012 17:50:00 -0400

Vector graphics are great. They deserve more of a place on websites than they get — certainly compared to their rasterized cousins. Nowhere is this more true than with icon UI. I decided to dip my toes into two leading solutions to bringing vectors to webpages: icon fonts, and SVG.

I won’t go too much into detail on either icon fonts or SVG, the former of which has seen terrific coverage by the likes of CSS-Tricks and Web Designer Depot, and the latter of which has been a web standard since 2001. I’ll summarize with the normal wins of vector graphics: they are scalable and styleable, unlike raster graphics which need to be duplicated for every situation whether it’s a color or size change or both.

Using Icon Fonts

I’m using icon fonts for some UI in my footer — the links to my RSS feed, my Twitter page, and my Github repository for this blog. There were certain use cases that made icon fonts a good fit: specifically, I wanted to handle them with CSS-driven text-shadows and transitions, just like my plain-text links. CSS is a terrifically convenient layer at which to style font icons.

The custom font I’m using comes courtesy of the awesome Keyamoon’s IcoMoon, which provides 300 free icons, and 622+ icons at the bargain price of $35. You can also import custom SVG icons, if none of the free ones are usable, and you can explicitly map your icons to Unicode characters. I let IcoMoon decide the mappings for me, and soon enough had a perfectly usable stack of web fonts and some nice CSS style definitions for using them, similar to the output of Font Squirrel’s Font-Face Generator. For the most part, I used IcoMoon’s generated CSS with few customizations. It creates some nice classes leveraging :before pseudo-elements:

/ Add the following classes to your stylesheet if you
   want to use data attributes for inserting your icons /
.iconb:before, .icona:after {
  font-family: ‘IcoMoon’;
  content: attr(data-icon);
}

/ Add the following CSS properties to your stylesheet
   if you want to have a class per icon /
[class^=”icon-“]:before, [class*=” icon-“]:before {
  font-family: ‘IcoMoon’;
  font-style: normal;
}
.icon-feed:before {
  content: “\0061”;
}

Some Gotchas

If you’re super anal about pixel perfection, then you probably should leave vectors behind right now and go back to your Photoshops. But if you’re still curious, a few things to note.

Firstly, icon fonts are text. And, as we all know, that means cross-browser, cross-operating-system rendering differences:

The Github Octocat font icon as rendered (and zoomed in, rasterized) in (from left to right)
Chrome OS X, Firefox OS X, Chrome Windows, and Chrome Ubuntu 12. Bottom row zoomed 200%.

Pixel peepers will note the extra definition of edges of the tentacles in the non-OS X operating systems, and differently sized eyes, amongst other tiny differences. As a user of icons, you shouldn’t get worked up about this (though, if I had to pick a favorite, it’s the Ubuntu version, which lacks jaggies but retains nice detail).

Make sure to use a grid for the smallest pixel size you want to use, and don’t veer from it.

If you’re creating these icons, then be aware of how browsers can smudge things away before you go to town on details. Pick a minimum pixel size you’re willing to accommodate, and make sure your details are chunky enough at that resolution; eg, hairlines should be thick enough to fill a single pixel at your minimum size; below that, they’ll get fuzzed away.

Next, be ready to tweak font-size and vertical-align to get your icons to orient properly — especially when next to each other or next to text. Just like normal letterforms, font icons deserve some careful treatment so that their visual relationships (mostly size related) to each other work well. But barring that, you’ll spend some time tweaking specific alignment and sizes for each use case (note that the below is SCSS):

.icon-feed {
  vertical-align: middle;

  .special-module > & {
    font-size: 1.7em;
    vertical-align: -.3em;
  }
}

Some font icons at the same font-size (white) and with tweaked vertical-align and font-size to achieve better proportions (red).

Thanks to CSS, this isn’t a big deal. Naturally, this is more pronounced of an issue if your icons are inline with plain text, where most certainly you’ll need to shift vertical-align explicitly for each icon depending on the situation; however, in fairness, all of this needs to happen with raster image icons, as well.

All of these gripes, in my opinion, are solidly overruled by the benefits of being able to scale(), change color and opacity, animate, and transition using CSS — none of which you can do with a single raster image icon (well, unless you don’t care about pixellation).

SVG

SVG, or Scalable Vector Graphics, is a really mature graphics standard that I have little experience with in a web context (though I have a lot of experience with vector drawing programs that happen to save as SVG). Because of the breadth of the standard, it’s well equipped for many things a vector in an icon font isn’t — namely, full-blown vector illustrations with many colors, gradients, opacities, strokes, what-have-you. Most of those things don’t apply to icons. But if ever you need more than one color in your icon, fonts won’t cut it, and you’ll have to use something like SVG.

A rainbow in SVG.

A rainbow in an icon font.

That was the case with the Minefold logo that I wanted to add to my bottom links. There’s a second color that is fairly necessary for the identity. Perfect opportunity to try out SVG. So I cracked open Inkscape for the first time in years, traced out the logo, and saved it as “Plain SVG.”

The resulting SVG file is basically markup that I copied and pasted straight into my HTML. I shaved out a few assorted meta tags that Inkscape adds that aren’t necessary, but for the most part, it worked well:

<svg
   xmlns:dc=”http://purl.org/dc/elements/1.1/“
   xmlns:cc=”http://creativecommons.org/ns#“
   xmlns:rdf=”http://www.w3.org/1999/02/22-rdf-syntax-ns#“
   xmlns:svg=”http://www.w3.org/2000/svg“
   xmlns=”http://www.w3.org/2000/svg“
   version=”1.1” width=”71.25” height=”60.375” id=”svg3087”>
  <defs id=”defs3091”>
    <filter x=”-0.25” y=”-0.25” width=”1.5” height=”1.5”
       color-interpolation-filters=”sRGB” id=”filter4802”>
      <feGaussianBlur result=”blur” stdDeviation=”2.5” in=”SourceAlpha”
         id=”feGaussianBlur4804” />
      <feColorMatrix
         values=”1 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 1 0 “
         type=”matrix” result=”bluralpha” id=”feColorMatrix4806” />
      <feOffset result=”offsetBlur” dy=”3” dx=”0” in=”bluralpha”
         id=”feOffset4808” />
      <feMerge id=”feMerge4810”>
        <feMergeNode in=”offsetBlur” id=”feMergeNode4812” />
        <feMergeNode in=”SourceGraphic” id=”feMergeNode4814” />
      </feMerge>
    </filter>
  </defs>
  <path
     d=”m 22.5,10.0625 -10.625,6.046875 0,34.203125 10.625,0 0,-21.609375 7.515625,8.890625 0.09375,0 11.03125,0 0.09375,0 7.53125,-8.9375 0,21.65625 10.609375,0 0,-34.203125 L 48.765625,10.0625 35.625,29.453125 22.5,10.0625 z”
     id=”path3969” class=”logo-face-shadow”
     style=”fill:#074676;fill-opacity:1;stroke:none;filter:url(#filter4802)” />
  <path
     d=”m 48.758258,47.406249 10.617442,0 0,-34.198033 -10.617442,-6.049471 z”
     id=”path3867” class=”logo-face-dark”
     style=”fill-opacity:1;stroke:none” />
  <path
     d=”m 22.501432,7.158745 18.642249,27.531268 -11.111274,0 L 11.91486,13.208216 z”
     id=”path4881” class=”logo-face-dark”
     style=”fill-opacity:1;stroke:none” />
  <path
     d=”m 48.758258,7.158745 -18.642249,27.531268 11.111274,0 18.117547,-21.481797 z”
     id=”path3921” class=”logo-face-light”
     style=”fill-opacity:1;stroke:none” />
  <path
     d=”m 22.492439,47.406249 -10.617439,0 0,-34.198033 10.617439,-6.049471 z”
     id=”path3915” class=”logo-face-light”
     style=”fill-opacity:1;stroke:none” />
</svg>

Challenges and Benefits of SVG

First thing about SVG is that if you care about pre-IE9, then either forget about it, or learn an abstraction library of some kind. (I recommend Raphael JS.) Barring that…

SVG, as its name suggests, scales fairly well. However, it faces the same reduction issues as icon fonts. The solution is the same, though; don’t scale down an icon below its intended minimum size.

SVG does render much more consistently across browsers, at least so far as I can tell. Definitely a plus for the pixel OCD amongst us.

The main challenge is styling. CSS can’t be used in the same way that it is for icon fonts (which are just text). In my case, the shadows and the bevel effect, for instance, which are CSS text-shadows in the icon fonts, actually need to be baked right into the SVG itself. Fortunately, Inkscape has a pretty great “Drop Shadow” filter that makes creating the same shadow effect in SVG quite simple. And the bevel is simply another <path>.

Shadows can’t be applied with CSS, and need to be in your SVG. Still, in some cases, it’s nice to have this much control.

If you are new to SVG drawing, though, this process isn’t very convenient. That’s one of the nice things about icon fonts — that they’re text, and can be styled that way, and you don’t necessarily need any special skills in vector drawing to accomplish certain effects.

Still, from a designer’s perspective, it’s great to have this level of explicit control. And obviously you can go much further than just icons.

That said, SVG is markup, and can be styled with CSS. Just note that the properties are different. For instance, SVG uses a different property for color: fill (versus text’s kinda’ misleading-in-comparison color property).

In the case of my icon, I wanted a hover interaction, which is slightly complicated as my icon is actually four separate <path> elements; since I want the entire icon to change color, I need to target all of these nodes explicitly. To do so, I added some classes to the <path>s to be able to hit them in CSS:

<!— Markup —>
<path
   d=”m 48.758258,47.406249 10.617442,0 0,-34.198033 -10.617442,-6.049471 z”
   class=”logo-face-dark”
   style=”fill-opacity:1;stroke:none” />
<path
   d=”m 22.501432,7.158745 18.642249,27.531268 -11.111274,0 L 11.91486,13.208216 z”
   class=”logo-face-dark”
   style=”fill-opacity:1;stroke:none” />
<path
   d=”m 48.758258,7.158745 -18.642249,27.531268 11.111274,0 18.117547,-21.481797 z”
   class=”logo-face-light”
   style=”fill-opacity:1;stroke:none” />
<path
   d=”m 22.492439,47.406249 -10.617439,0 0,-34.198033 10.617439,-6.049471 z”
   class=”logo-face-light”
   style=”fill-opacity:1;stroke:none” />

/ CSS /
.logo-face-dark { fill: #0a66ae; }
.logo-face-light { fill: #1087e1; }

And since I want all four elements to change color when any of them are hovered, I actually need to target a parent; conveniently, the <svg> element serves that purpose well (pardon the SCSS again):

svg:hover {
  .logo-face-dark { fill: #0a66ae + 100; }
  .logo-face-light { fill: #1087e1 + 100; }
}

One hiccup: I lose transition when in Chrome. Not sure why. But also not a huge deal (transition is one of those CSS3 properties that we should all be okay with degrading away). Though, this is probably a good reason to use script instead of CSS for interaction purposes in SVG.

Conclusion

To start with the obvious, while I was happy to pursue the combination as an experiment in my footer, I don’t suggest that anyone mix and match SVG and fonts for icons; for the sake of consistency, do one or the other.

I can see myself using SVG entirely at some point. I like the extra visual control and rendering consistency, and other simple things like, say, supporting more than one color at a time in a single drawing. I’ll need to spend some time digging into animating and transitioning interactions before I completely make the dive.

But for the vast majority of simple icon UI, it’s hard to argue against icon fonts. It’s pretty huge that they take on the very same style properties as text. @font-face is supported pretty widely at this point. There’s no question that they’re more convenient than rasterized icons and sprites, especially now that there’s great tools for creating them, like IcoMoon. For cross-browser, scalable, easily styled icons, they’re the way to go for now.

Short Sighted: MyTailor.com’s Online Made-to-Measure

Mon, 11 Jun 2012 10:00:00 -0400

I hate getting things altered. The effort usually involves toting clothes to work, making an extra subway stop on the way home, getting sized up and dropping the clothes off, and returning in a week with your fingers crossed that a second round of alterations won’t be needed. And that’s making the huge assumption that the off-the-rack clothes were salvageable to begin with — an expensive rarity for my skinny, 5′ 2″ frame.

Fortunately, the rise of online made-to-measure promises to make alterations the expensive rarity. Here’s my thoughts on my first made-to-measure experience — Hong Kong-based MyTailor.com — and why made-to-measure is a must for XS and down.

MyTailor.com is run by the warmly demeanored Joe Hemrajani, who is clearly more tailor than website designer. The experience on MyTailor.com is a bit clunky, and often overwhelming in choice. You start the shirt-making process with fabric selection, which is a massive navigational tree branching off into hundreds of grids of cloth types and brand names that only a true shirt geek would care for. I’m not one, or at least not this much of one, so my first order ended up being the cheapest white fabric I could find.

The next step, involving collars, pockets, plackets, and other customizations, is much more intuitive and fun, but it’s still stuffed to the gills with options. There’s no less than fifteen different collar designs, nine cuff types, and four kinds of placket. You can even specify the length of the collar, which is a great level of customization. For my first shirt, I did an “English Cut-Away” collar, no pockets, and a plain front — pretty much a combination I never find off-the-rack.

Finally, the next and most important step: measuring. MyTailor.com suggests four methods, but there’s really only one worth considering for the first run: getting a friend to measure you. The instructions provided are straightforward and easy to follow, and there are a lot of measurements to be taken, which is encouraging. After that’s done, the measurements are saved to your account, and you’re ready to pay and wait a month for the shirt to arrive.

However, Joe does one-better if you happen to live in or near a major city in the US: he packs his bags full of swatchbooks and sets up shop in hotels for a few days to take measurements and orders in person. I did this for my third shirt from him — a formal tuxedo shirt — and it was by far the best way to place an order. First off, there are real live swatch books — hundreds of them. Seeing the fabric in person is infinitely easier than the awkward virtual catalog on the website. And not being a fabric geek, it’s good to have Joe there to guide me through his overwhelming selection.

Tuxedo shirt bib, for the most expensive lobster eating experience ever.

Second, he notes details that are either difficult to convey online or that simply wouldn’t have occurred to me. Things like subtleties in my posture that would affect differences between my shoulders’ size and height, or even the extra girth needed on my left cuff to accommodate my watch.

It takes around a month between placing an order and having the shirt in-hand; Joe admitted to somewhere over 20,000 customers worldwide, so it’s an understandable duration. And the product is terrific — the first time around, downright revelatory. Things like accurately sized and positioned arm holes (incidentally, something that’s also extremely difficult if not impossible to alter, so getting it right is important), perfect sleeve lengths, narrow cuffs that don’t dwarf my hands (a big problem off-the-rack), minimal blousing around the waist… It’s great to have so much work and fit so well right out of the box. It’s even better to have the details that I’d never find at a retailer — things like a cut-away collar (the rarity of which in off-the-rack I can’t explain), or angle-cut cuffs. He even provides free brass collar stays with each order — a sight better than the plastic flimsies that most off-the-rack come with.

Free brass stays with every shirt.

My first MyTailor.com shirt was around $75 shipped. The last, with substantially higher quality fabric, and fancier customizations (a textured pique front, collar, and cuffs, and removable buttons) was approximately $125. I’m not nearly nerdy enough about shirts to distinguish the finer details of manufacture, such as quality of stitching or the material of the buttons, but I will say that my first MyTailor.com shirt is four years old now, and is holding up great with nary even a loose button.

Removable buttons for replacing with studs.

Next to a quality off-the-rack shirt with alterations, the price is comparable — in some cases, more affordable. Considering that the fit is great, and I don’t have to deal with dreaded alterations, the cost is well worth it. If you’re my size, or another proportion inconveniently ignored by off-the-rack designers, MyTailor.com for shirts, and online made-to-measure in general, is a must.

All creased and wrinkled from its international flight.

Off-the-rack shirts balloon like parade floats from this angle.

Minefold for Casual Minecrafting

Fri, 08 Jun 2012 21:19:00 -0400

The sandbox smash, Minecraft, is really fun. Setting up, port-forwarding to, and maintaining a multiplayer server, all while moderating against and booting out “griefers” really sucks. So, don’t do any of that, and use Minefold, instead.

I love Minecraft. After my curiosity was piqued by a random video of someone accidentally burning their blocky house to the ground, I nabbed the alpha version, and have moved countless blocks since. I love it especially because there’s no objectives, no missions, no timers; I can do whatever I want, at whatever pace I want. A true sandbox.

When it comes to sharing Minecraft worlds, options are slightly limited. There’s Minecraft server software that can be run on a machine for sharing on a local network. Or the wider Internet with the right port-forwarding router setup. I’d rather pay a bit to have all that hardware and setup handled for me.

Upload your locally created worlds, or create a new one with a dead-simple interface.

Amazing, then, what the hosting service Minefold offers for free: ten hours of play a month on an unlimited number of Minecraft worlds. It turns out ten hours a month is way beyond ample for my casual playing needs. If somehow it’s ever not enough, there are unlimited play “Pro” options starting at $15 for three months, and getting cheaper with six- and twelve-month commitments. After a brainless signup (designer Chris Lloyd did an amazing job with Minefold’s elegant design), you can upload your existing locally-created worlds, or easily start a new one. At its most basic, it’s the perfect way to cloud-store your worlds. But there’s more to it than just the basics.

Minefold has two major strokes of genius, both setting it apart from other competitors that I considered back when I was looking. The first is that you’re charged for play time — not for the servers. What this means is that you don’t need to worry about capacity costs or anything of the sort; if you have a dozen other players participating, however much they play is their own problem and their own bill, just the same as with your own participation. And on that note, allowing other players in is akin to adding them as a friend on Facebook; they put in a request, and you approve it. There’s no other way about it, which makes preventing “griefers” (in the “speak”) an easy thing to do, if you keep approvals close to your chest.

Minecraft worlds get brilliant presentation in Minefold.

The second stroke of genius is how worlds are shared. To start, your world and the literally thousands of other worlds created by other users have wonderful “profile” pages, centering around a truly awesome Google Maps-driven isometric pan-able and zoom-able view of the world as it’s so far been explored. This is actually an incredibly useful feature; not only have I spent countless minutes panning and zooming around finding things in this map of my world that I didn’t notice when actually wandering in Minecraft, but I’ve often kept it open to use as a real map while I played the game simultaneously.

Exploring your own and other people’s worlds — and cloning them — is a downright pleasurable experience.

Obviously, it’s also a wonderful way to experience what others have created. Thumbnails of these isometric maps can be browsed in an “Explore” page, and you can click into any world’s “profile” page. And to top it off, you can clone any world you come across to claim as your own. This means that you can experience other people’s creations without having to trouble yourself with getting approval as a participant in their exact original of that world. Seriously, Minefold solves all the problems of safe and easy multiplayer Minecraft with its browsing, cloning and approval system.

Did I mention that all of this is free? You don’t pay a dime until you’ve surpassed ten hours of play time in a given month. What a deal, especially for the casual player. For making multiplayer Minecraft painless, brainless, griefer-free, and just plain pleasurable to use — even when not playing — Minefold is the way to go.

Some people are better at Minecraft than I.

My new favorite watch is my old one

Tue, 22 May 2012 16:47:00 -0400

I just got a springbar tool from Amazon, and I think it’s the best nine bucks I’ve spent in a while. Why? Because it lets me do this:

My Parnis pilot watch on a beige NATO strap.

That’s a light-brown nylon NATO strap on the very same Parnis pilot watch that I reviewed a while back. If you’ll remember (or as you’ll see, if you never knew to begin with and proceed to read my review of it), one of my least favorite things about the watch was the strap. It so happens that’s exceedingly easy to remedy, thanks to this cheap tool.

Crucially for me, it’s allowed me to do this:

Match made in wrist heaven: my Parnis watch with my old broken Garton’s strap.

That’s the ruddy brown strap from my broken Garton pilot, which I think is an amazing match for this watch. The reddish color plays well with the tiny red “60” in the seconds sub-dial, and the stainless steel rivets make it look even more classic — not to mention that it’s a softer and more comfortable strap than the stiff affair that came with the Parnis originally.

My new favorite thing: a watch springbar tool.

But most importantly, I’ve increased the versatility of my watch with this tool. I can dress it up with leather, or make it more breathable with a nylon or canvas. And I never have to worry about the strap not matching my belt and shoes (yes…I do worry about that a little).

Instructions abound on Youtube on using springbar tools, but honestly there’s not much to figure out, anyway. Just don’t store it where you’d be reaching for it blindly; some of the tips are pin-sharp.

By the way…on the topic of straps, the aforementioned NATO strap, from a company called Clockwork Synergy, is great, and comes in more colors than the rainbow. I was concerned that I’d have to melt holes in it because these straps are notoriously long (probably to accommodate James Bond’s massive Soviet-choking wrists), but — unlike its leather cousins — this one didn’t need any modification. I recommend them.

The NATO strap — a cheap way to bring variety to your watch.

Blue Nubuck Shoes by Bass

Sun, 20 May 2012 09:45:00 -0400

I’ve got a thing for navy shoes in the warmer months — they’re versatile like brown shoes, but bring a more vibrant contrast to already brown-hued khaki pants. My fiancee recently turned me to Bass, a 136-year-old Maine-based company I’d known solely for the loafers of my parent’s generation, as an affordable source for this shoe. After getting these, it’s clear that I didn’t pay enough attention to the company over the years.

Got a pair of their “Brockton” model in “Denim Blue” nubuck off of Zappos for the relatively bargain price of $65. They also produce the more expensive but very similar-looking Buckingham model, boasting white contrast laces and stitching and what looks to be finer grained and darker navy nubuck. I likely would have preferred the darker color, but as this was my first pair of Bass, I wanted to scout the fit of the brand. I’m a difficult size almost never found in stores — 6.5 wide — so scouting means using sites like Zappos with excellent return policies.

The Brocktons are soft, pliable, and comfortable out of the box. I’ve stuffed them with Powerstep insoles for additional comfort, and to bring the size 7 shoes down to my level.

Fortunately, I’ve got no reason to return them, despite Zappos not stocking them in 6.5 wide; most shoe producers have 7 as their bottom size. In 7 medium, they are clearly on the long side, but a nice third-party insole makes them comfortably snug. I’ve also gotten cheated by 6.5 wide shoes that are too small (Sebago, I’m looking at you), and that’s much more difficult to rectify, so being able to use insoles to make 7 wearable is a welcome option.

I like navy shoes underneath otherwise dull khakis.

The nubuck is really soft, and the rubber sole is quite pliable, making them comfortable to walk in right off the bat — more like a sneaker than leather-soled dress shoes. And they also come in a bunch of other colors, like the classic seersucker-and-mint-julep-ready, can’t-wait-until-Memorial-Day white nubuck over red sole that my fiancee constantly convinces me I don’t need. They don’t have my size anymore, anyway, so whatever. But if they have yours, I heartily recommend them!

I wish I’d looked at Bass shoes sooner!

Trying Out Knit Ties

Sat, 19 May 2012 00:10:00 -0400

Been yearning to do neckwear outside of the usual business, formal, and Halloween situations, and I finally decided to give it an earnest shot this Spring starting with my very first silk knit ties. I bought two from one of my favorite sources for accessory experimentation: Century 21 in the Financial District.

Seemingly always overrun by tourists, Century 21 can be overwhelming and is often hit-or-miss. But it’s great for cheap experiments in accessorizing, such as for ties and pocket squares. The one I’m trying here is by a company I’d never heard of before called Burma Bibas, and costed around $10. I also got a black and purple (goth colors, my fiancee notes) horizontal striped Ralph Lauren for around $17.

Since this was during one of the more precipitous days in recent weeks (April flowers brought May showers in NYC), I’m also donning a Uniqlo mac coat and my favorite rain boots from L.L. Bean:

Bean Boots by L.L. Bean.

Parnis Pilot’s Watch

Mon, 23 Apr 2012 00:06:00 -0400

Parnis is a Chinese mechanical watch maker specializing in homages to popular styles. The ones that drew my attention are their “pilot”-styled hand-winding watches. I just recently got one — unbranded, with the seconds subdial at the 9-o-clock — and it’s pretty great.

I love mechanical watches. Despite being significantly less accurate than pretty much every other watch technology since the 1950s (like quartz), there’s something beautiful and elegant in the tiny gears and springs of mechanical movements, which also never need batteries. My first mechanical watch is a diver: the Hamilton Khaki Navy GMT. It’s an automatic with screw-down crowns — robust, heavy, beautiful, and complicated with several rotating bezels. In looking for a second watch, I wanted something simpler and more elegant.

I’m drawn to pilot watches for the same reasons early 20th-century pilots found them appealing: because of the legibility of the heavy white sans-serif numerals on large black dials. And in making my rounds of watch forums and blogs, I came across Chinese watchmakers like Parnis doing them on the cheap.

This is actually my second Chinese hand-wound watch. I previously bought a Garton pilot watch that I also really loved. But one day, I made the poor decision of letting it get near-soaking wet. The dial casement popped off not long after, and then the movement just plain stopped working. I could have gotten it repaired, but it would have costed better than 50% of the original sub-$100 cost. These are not water-resistant watches, which is definitely worth keeping in mind.

Finally, months after the Garton broke, I ordered the “44mm Black Dial Special@9 White Number Asian 6497,” (whew) which I picked mostly because I loved the typography and the red “60” on the seconds subdial. Manbushijie.com (heavily endorsed by forums as one of the most reliable Chinese watch sources) lists it at $86, but once I registered, prices all across the site dropped by about a quarter, and I was able to nab this one at $69 including shipping from China. A little weird, since I’m pretty sure registration is required to order anything. Anyway, about three weeks later, the watch arrived flat in a padded envelope and swathed in bubble wrap.

Sitting next to my old Garton, which has a gunmetal “PVD” case. Note the lighter weight numerals and markings on the Special@9.

The first thing I noticed after I unwrapped the “Special@9” is how large the dial seems. It’s the same 44mm as the Garton I got before it, but the numbers and minute markers are a hair lighter weight. Also, the markers are about a millimeter shorter, placing the numerals at a wider radius. Combined with the lack of any branding, there’s a lot more whitespace (or blackspace) than the Garton. This also makes the dial feel cleaner and more elegant, but it feels a tad oversized on my sub-7” wrist. If everything were drawn in by around two millimeters, it would be perfect.

That said, the numerals are clean and lovely, and I’m particularly fond of the seconds subdial. It’s got radial ridges, like a vinyl record, that give it a sort of metallic gleam when light hits it. The seconds numerals are set in the same typeface as the minutes (unlike the Garton, which used a serif face and looked a bit awkward), and the subdial itself feels cleanly placed, cropping the 10 and 8 at the 9-o-clock position.

The case is simple stainless steel, polished on top and bottom, and brushed along the sides. On the 9-o-clock side of the case, opposite the crown, its got a simple art-deco-ish ornamentation that on the one hand is completely inoffensive but on the other sort of breaks the minimalism of the dead-simple case. It’s also got a transparent glass caseback that displays the movement — a pretty 6497 clone with some blue screws, pink rubies, and engraved metal.

Like many pilot watches (and the Garton before it), the Special@9 has a huge diamond-shaped crown that winds the power spring when turned clockwise. Pull the crown out, and the time can be set by turning in either direction. The seconds do not stop when the crown is pulled (a concept known as “hacking,” making it easier synchronize); usually, I try to hold the minute hand exactly on a minute marker before pushing the crown back to help ensure the hands are in sync.

Transparent caseback showing off a 6497-like movement with regulator at the top throttled fully slow. It still runs a tad fast.

One thing of note, which is also common amongst these Chinese mechanicals, is that the movement is quite loud. Imagine the signature sound of the 60 Minutes clock audible from a foot away in relative quiet. I actually like the noise, but my fianceé isn’t into it; if we’re sitting next to each other, and I’m leaning my head in my left hand (not an unusual posture for anyone), then she can hear and is quite distracted by the sound of the rotor in action. Whereas for me, after regular wear for the past few weeks, the ticking has become pleasant white noise.

Comparison of lume between Hamilton Khaki Navy GMT, the Parnis, and the Garton after a 30-second shot of a 20-watt halogen lightbulb.

Also like many pilot watches, the numerals, hands, and markers are coated in luminous paint. It’s a standard green, like that used on my Hamilton, but not as immediately bright. For me, the important part of lume is duration, and the Garton excelled at this; I would be able to read the watch late into a two-hour movie at a theater, which is far longer than the Hamilton. This Parnis, however, doesn’t seem to have the same duration as the Garton. The Garton also uses blue lume, as opposed to the green on the Hamilton and Parnis, which could be a factor. I suppose I just need to watch more interesting movies when wearing the Special@9.

Lume after about half an hour. Tried to keep exposure the same as the prior shot.

The exceedingly cheap-feeling “genuine leather” strap. I felt okay about grinding a hole through it with a razor for my narrow wrist.

One of the unsurprising downsides of cheap watches like those from Parnis and Garton is the strap, which is wholly unremarkable, stiff leather. I actually prefer the strap of the Garton, which is thinner and more pliable than the Special@9. It’s also a nice color — a reddish brown that contrasts well with the charcoal colored Garton case. At a distance, the thick and dark brown strap of the Special@9, with its white contrast stitching, seems fine next to the polished stainless steel case — it actually looks rather classic. Spending a minute to look closer, though, and it looks and feels plasticky. Still, with regular wearing, the strap becomes softer, and I’ve warmed to it enough that I’m not clamoring to replace it with something nicer. Also, since it’s so cheap, I didn’t feel the least bit squeamish about taking a razor to it to dig out a new hole to accommodate my thin wrist (which I also did with the Garton, which has an even longer strap).

After about a month of wearing, the watch has become a comfortable wrist presence. I didn’t realize how much I’d missed cranking a manual movement, and like the Garton before it, I never let the spring run out. The movement runs fast — I didn’t measure the divergence precisely since I never cared for ultra-precise timekeeping (if I did, I wouldn’t be into mechanical watches), but it’s maybe something like a minute gained a week. Thanks to the simplicity of the watch, it’s no problem readjusting once a week or so. In fact, it’s probably indirectly helped me be early to appointments.

Condensation built up inside the case on a particularly humid morning.

Something I was harshly reminded of one morning is the lack of weatherproofing. On a particularly humid day recently, I awoke to condensation on the inside of the watch. The lack of any kind of gasket-like seal means that moisture can easily sneak in, and if not removed promptly can cause corrosion of the tiny metal parts. Normally, this means a trip to the watch repairer; but, since the Special@9 isn’t very sealed, I pulled out the crown, put it in a bag with uncooked rice overnight, and the next morning the condensation was gone.

I have several nitpicks with the Special@9 compared to the Garton that preceded it — the lighter weight numerals and markers and lack of branding make the dial seemed oversized, and the lume is unimpressive, as is the strap. But it’s readable and cleanly designed — exemplary of the pilot watch style. It’s accurate enough for my tastes, the movement is beautiful and fun to wind, and at $70 shipped, it’s a great value. I think I’ll dress it up in the future with new hands and a strap, but even in its out-of-the-envelope state, it’s totally fine. I’ll be shopping Parnis again in the future, for sure.

A watch well worth $70.

I Love Jekyll and Github

Thu, 05 Apr 2012 20:37:00 -0400

I love Jekyll Bootstrap and GitHub as a blog platform — so much so that I’m sure I’ll write posts more often than once a year. Really. As a frontend developer and pixel-pusher, it might be the most pleasurable way to blog that I’ve tried yet. Not that I’ve tried much, but hear me out.

The Tools

A month after my last blog post in late 2010, I got a new job with a dating startup named HowAboutWe. It’s been an incredible and intense experience so far that — in addition to partly yanking me away from paying any attention to this blog — has introduced me to many things. Chief among those with regards to this post are Github for source control, Vim for code editing (and writing text in general), and Compass and Sass for writing CSS.

Wordpress theme components. Or…auto parts from Bangkok’s Chinatown.

I now have a flow at work that is a cinch to me. When the scales finally tipped, oh, maybe a year ago, and I set out to redesign this blog, it made sense to incorporate as much of this new beloved workflow as I could. It started with a new theme for my original Wordpress install. I worked on converting the stylesheets into *.scss partials for use with Compass. Vim was the editor, and I kept all my changes on Github. But it still didn’t sit completely right with me. Free time was short, and the once humble task of Wordpress theming and uploading via ftp to my web host felt intimidating.

Blogs are static beasts.

HowAboutWe used to have ad modules for third-party sites that would make complex queries to conjure seemingly timely and location-relevant content. In retrospect, this was silly for a couple of reasons — not the least of which being that trusting user-generated content for the purpose of advertising is extremely risky. (One that always brought smiles involved a user suggesting that he and his date join OkCupid rather than pay for our site.)

Instead, it made complete sense to curate the content, and just serve up quick and fast static HTML that would be browser cached practically to infinity. A day later, we replaced nearly all of these ads with the static content, and the elegance of the solution had big payoffs in both performance, and code maintenance. It was silly we didn’t do it that way from the start.

Keep it simple!

It wasn’t much of a leap to reach the same conclusions about blogs. I’d heard of static site generators like Jekyll before — years ago, in fact — but I never considered them useful for a blog. The thought of static HTML that I’d have to compile and upload after every post… It just sounded cumbersome. And then I realized that I wasn’t exactly producing a daily newspaper’s worth of content. Also, there are times when I’d want to do a good bit of custom layout for a given post. So, my post content would be peppered with HTML.

Writing HTML into Wordpress textareas always felt awkward to me. I would tend to hash out the layout in a text editor and separate HTML file before pasting it in to Wordpress.

Jekyll, and more specifically Jekyll Bootstrap, solve this problem. Jekyll works by pointing it to some template HTML, writing your content as either Markdown (*.md files) or HTML, and then running it. It mashes the content to the template and spits out a fully rendered website that you can then upload. And Jekyll Bootstrap adds some nice config setup, themes, and other great stuff that make blogging with Jekyll a near no-brainer.

So, using Jekyll, my posts are HTML files. And I could use Vim once again to author all of my content. When you install Jekyll Bootstrap (which installs Jekyll), it provides a server that you can run that will listen to a _posts folder for updates. The instant you save something in there, it does its template compilation, and your new content is instantly viewable at http://localhost:4000. Really awesome.

Deployment

I’d learned a while back that people use Github Pages — basically, a Github repo that will automatically be served to YOURNAME.github.com — for blogging. I’d also learned, much more recently, that it supports Jekyll. Since I was already accustomed to source-controlling my work and some of my personal stuff with Github, deploying my blog simply by committing to a specific repo as normal sounded beyond perfect. Code, push, deploy became simply code and push.

I was concerned at first that I wouldn’t be able to push up drafts of posts without them being published automatically, until I had the “duh” realization that I could cut a branch ($ git checkout -b “2012-04-06-my-post.html”), write my post and push it in draft state to my hearts content. I could publish it when ready by merging the branch to master. Another fairly exact mirror of my normal workflow, and it feels great.

Github Pages is really what seals the deal with Jekyll. Ftp is out of my life now, and it’s bliss. Another important step was pointing my domain, marcocarag.com, to jazzcrazed.github.com. Hopefully, your registrar gives you this capability, but it’s simply a matter of pointing an A record and a CNAME record to Github; the Github Pages Help instructions are pretty accurate in this regard.

Resiliency

I think it’s hard to overstate the awesomeness of removing the overhead of something as complex as Wordpress. I’ve been considering moving away from my current web host, but the idea of deciding on a new host, going through a new Wordpress install on that host, and putting my old blog data in its MySQL database almost makes me sick to my stomach.

The sites generated by Jekyll are not married whatsoever to any particular host and the services they provide. It doesn’t matter if my web host has a PHP server, .NET, Rails, or Node.js, or whether it uses MySQL, Postgres, or a document database. The end product is static HTML. If Github crashed and burned, I could upload that HTML anywhere else with hardly any setup needed.

And as awesome the admin areas of Wordpress are, in no way does its <textarea> compare to Vim in my view. I’m sure you’d feel the same with your text editor of choice. The short of it: If you’re a web developer intending to blog about code (or even not about code, if you’re as bad with Vim commands outside of Vim as I am), Jekyll and Github Pages is likely the best way to go about it.

Happy Blogging!

Regressive Enhancement at SXSWi 2011!

Wed, 27 Oct 2010 19:57:00 -0400

Just a quick one here, urging you to vote for the Regressive Enhancement, or Use HTML5 Today! panel for SXSWi 2011. Because I can find no better reason to go than to see a couple of friends of mine on stage. (Maybe the BBQ.) Also congrats to Mike Taylor, one of the speakers, for his brand spanking new gig at Opera!

First impressions from Santo Domingo

Sun, 05 Sep 2010 18:31:00 -0400

I’ve settled in to my fiancee’s parents’ apartment here in the Dominican Republic, and so far I feel very far away from home. Which is indeed awesome.

I am disgustingly ill-traveled. The last time I was out of the country was to play a wedding in Turks and Caicos, and I barely went outside the hotel. I haven’t taken a vacation for longer than a few days in nearly my entire working life — and never much further than my hometown in Virginia. And so this ten-day vacation to the Dominican Republic to visit my fiancee’s home, friends, and family should be a well overdue shock to this travel-noob’s nerves. Here’s a few of my first impressions:

The airport thirty miles outside of downtown Santo Domingo is pretty much like every airport I’ve been to. If I didn’t pay attention to the language on the signs (or in some cases even if I did), I could easily mistake it for La Guardia.

The area just outside the airport is starkly different. Driving west down DR-3 (towards downtown), the expressway is lined to the south by the ocean, and to the north by blocks of dessicated structures of cinderblock and wood. Occasional smatterings of scaffolding and construction machinery make it hard to distinguish whether it’s new development or decay at times; but large pyramids of trash and debris make me lean towards the latter.

On the six-lane DR-3, vehicles and people alike share the pavement. Cars, vans, and trucks whipped past men and women leaning on the narrow median and sauntering along the lane lines as if they were built into the roads themselves. I consider them crazy not for crossing a trafficked six-lane expressway, but for trusting the drivers on it with their lives.
Traveling from the airport and through downtown Santo Domingo affirmed my general distaste for driving. Some disclosure, I hate getting behind the wheel even in the safest, quietest, and widest roads of well-paved suburbs (and honestly, you should probably question anew your travel options if you find me at the wheel of the car you’re in). But Jason Bourne himself would find driving here a trial.

The Dominican traffic I’ve been exposed to so far is most notably comprised of rusted out Toyota Corollas (the vast majority so far) and other compacts, Japanese SUVs, occasional BMWs, the only Chevy Nova I’ve ever seen in person, tiny Daihatsu trucks, motorcycles, and small buses called guaguas.

Simply put, Dominican guaguas are buses and vans owned and run by private owners or labor unions in areas lacking sufficient municipal transit. They resemble in concept the dollar vans of Brooklyn — Ford Econolines and Chevy Astros that honk to make their presence known to potential passengers as they stream up and down Flatbush Avenue. The guaguas here, too, make random pickups and stops, and are, according to Isa, more present than the state-run OMSA buses. However, they look like this:

Photo from here

The off-roader style fenders are quite literally a sort of traffic sweeper. It’s a fair expectation for drivers here that they will bump into things — and, in the case of guaguas, with intent. Dings and scars, and in one case a mattress affixed artfully to the rear of one guagua with packing tape, told a story of jockeying as the driving norm on Santo Domingo streets.

I’ve noticed that honking one’s horn here is more a sort of courtesy than an expression of anger or irritation — a “hello! I’m here in your blind spot!” kind of greeting. It’s a useful hail at times; more than just guaguas are worse for wear here, and in cases where tail lights are busted, a quick wave of a hand out a driver’s window is sometimes all that precedes an abrupt merge. My future father-in-law braked, swerved, and gunned around all of this chaos with relative aplomb.
The neighborhood of Isa’s childhood and where her parents still reside is called Arroyo Hondo, which means “deep stream.” It’s a wealthy area set on steep, picturesque hills just outside of Santo Domingo Este. Windy streets are lined with incredibly lush vegetation, and the houses are magnificent and immensely gated.

Isa’s parents’ apartment is in a community called Isabel Villas, named for the nearby Rio Isabel (Isabel River — no relation to Isa, though everyone apparently asks). There’s a golf course nearby, and a guardhouse sits at its entrance. Across the narrow road in a dusty lot is a band of motoconchos — taxis comprised of small and ratty motorcycles whose drivers await the servants of the community to finish their days’ duties and seek out a ride back down the winding streets into downtown.
One piece of advice from Isa and her fellow medical school graduate DR expats that’s resounded since long before we arrived is this: Don’t drink the tap water. It’s not potable, according to them, and my gastro-intestinal system raised on a sterile Virginian diet is especially too tender for what runs through Dominican plumbing. So I take from standard water-cooler-style jugs of filtered water, poised in a clever metal rack that tilts to angle the spout into the drinking implement of choice.

Another reminder that I’m a long way from New York is right next to the jugs of filtered water. Three rows of car batteries line the walls, and are rigged into an inverter, ready and waiting for inevitable brownouts.
So far, since arriving at the airport until now, nearly two full days into my stay, I’ve not heard barely more than a whisper of distant merengue or bachata, or much of any music in general. Washington Heights, with its idling SUVs blaring La Mega, this most certainly is not, but Isa assures me that this won’t be the case for long. She does, after all, hate the music for a reason. What I have heard plenty of, however, are roosters, somewhere at a nearby neighbor’s house. They cock-a-doodle-do reliably in the morning; though, one sings well into the afternoon. Various birds and insects crow and chirp through the day, and I couldn’t be happier about it.
The orange soda I’ve had so far here is Fanta, procured from a nearby Super Mercado Nacional. It’s as sweet as snow-cone syrup, and around 600 calories per serving, and takes me about as long to finish a single twenty ounce bottle as it does a dram of neat whiskey. Definitely a sippers’ soda, to be taken on the rocks or not to be taken at all.

Drink responsibly.

Overall, it’s humid, but breezy, beautiful and relaxing here. The only way I really noticed the humidity, actually, was when I noticed after a day that the corners of my passport were curling up all on their own. Unlike my passport, I find it really comfortable here — infinitely better than the climate in our Brooklyn apartment. I’m utterly grateful that Isa chose this for our vacation, and that her parents are graciously hosting us, and I’m certain already that it’ll be hard to head back at the end of our ten days here.

CSS Transparency and Overlapping Glyphs

Mon, 23 Aug 2010 18:46:00 -0400

rgba() is a supremely useful CSS value. But I noticed, while working on the footer of this site down below, that operating systems render typography using this value in interesting ways.

About CSS transparency

To start, a quick overview. rgba() is a CSS property value specified in the CSS3 color module that allows one to set in single value the traditional red/green/blue color sub-values, as well as a fourth sub-value for alpha transparency. The syntax is pretty straightforward: rgba(red,green,blue,alpha), where red, green, and blue are specified either as a percentage (0 to 100%) or as a number from 0 to 255, and alpha is specified as a decimal value — “1” translating to 100% opaque, “.5” is 50% transparent, “0” is completely transparent, etc.

The awesomeness of this idea is that with rgba() as a value, it can be applied on any CSS property where color values are accepted, such as color, background-color, text-shadow, what-have-you. The end result is the ability to apply individual levels of transparency to a single CSS selector for different properties — for instance, you can set your background to one transparency, and your text to another. Contrast this with the older opacity CSS property, which applies an alpha transparency value (in the same 0 to 1 decimal scale) to the entire selector — meaning, the selected element and any of its children would all get the same opacity, background, text, and all.

Rendering issues with overlapping glyphs

While tooling around with my footer down below, I noticed rgba() being even more granular than I wanted it to be with regards to typefaces that naturally had overlapping glyphs. I had my footer set to something like this:

  .myFooter {
    font-family: DeftoneStylusRegular;
    color: rgba(255,255,255,.2);
  }

Via @font-face, I’m using Ray Larabie’s Deftone Stylus, which is a retro styled script font that’s intentionally kerned so that there’s overlap for the glyph connectors, as are most script fonts. The above CSS would set the text’s color to be white with 20% opacity. And the result looked like this:

Example of overlapping glyphs using CSS rgba()

Where the glyphs’ serifs overlap to act as connectors, the opacity is multiplied. I created a simple little test to try to isolate what the issue was:

    <style>
    .test{
      font: bold 5em sans-serif;
      color:(0,0,0,.25);
      letter-spacing: -.2em;
    }
    </style>

    <p class=”test”>This is a test using rgba.</p>

This uses the browser’s standard sans-serif typeface, sets it to black at 25% opacity via rgba(), and condenses the glyphs via negative letter-spacing to get overlap. It looks like this in Firefox 3.6 and Chrome 5 in OS X:

As you can see, it appears as if each character is being targeted for transparency, and when they overlap they are treated as independent layers… in OS X, that is. Take a look at the same in Windows Firefox and Chrome:

In Windows, in either browser, it looks like it renders all the glyphs as a single vector object before then applying the transparency uniformly on the whole shebang. So my best guess is that browsers use OS-level compositing here, and there are discrepencies between operating systems. Most unfortunate, if you’re aiming for semi-transparent typography that has intentional glyph overlap. However, there’s a way out via opacity:

    <style>
    .test{
      font: bold 5em sans-serif;
      color: #000;
      letter-spacing: -.2em;
      opacity: .25;
    }
    </style>

    <p class=”test”>This is a test using opacity.</p>

This should actually look exactly the same as the first example — and that much is true in Windows. However, in OS X:

It looks just like Windows does — and actually, it looks the way I had originally intended. And this makes sense, since according to the spec regarding CSS transparency, “…after the element (including its descendants) is rendered into an RGBA offscreen image, the opacity setting specifies how to blend the offscreen rendering into the current composite rendering.“ In otherwords, render the elements at full opacity, and then crank the opacity down post-rendering based on the opacity property value before finally rendering on screen. Conceivably, rgba() is the same thing, only with multiple layers nested across multiple properties — but turns out OS X takes it a step further with text by isolating each glyph.

Check out this test page for the above examples (make sure to view in both Windows and OS X).

Conclusion

Honestly, this shouldn’t make a big difference in the vast majority of situations where traditional sans-serif or serif fonts are in use, as their glyphs don’t usually overlap. But think twice about it if you’re thinking about applying transparency to text set using a font with intentional character overlap — which includes just about all script fonts. Here’s an example of just a few, including Deftone Stylus which I used in my footer — these are at their default kerning, with no forced condensing via letter-spacing:

Demo of fonts with intentional glyph overlap.

If I wanted to apply transparency to text using any of the fonts in the above demo, I’d have to forego rgba() in favor of wrapping the text in its own element, and then targeting that element with opacity, instead. That’s exactly what I ended up doing for my footer, by the way. It means extra DOM elements, but at least it works!

Note about Opera in Windows

In OS X, Opera 10.61 looks much the same as Firefox and Chrome. But in Windows, it has some issues with certain typefaces when transparency is used in any form:

As you can see, it’s cutting off certain glyphs along the vertical. Not sure what the issue is, but I haven’t hunted around much for answers, either, so I’ll update this if I find anything.

Credits

Thanks to the wonderful Font Squirrel and all of its participating typographers, for their wonderful collection of type, and handy @font-face kits!

Trying this out again…

Tue, 17 Aug 2010 02:02:00 -0400

I’m going to give blogging a shot again. I used to do this quite a bit, but that was about seven years ago. I lost my appetite for it not long after that, out of some combination of laziness and general lack of writing ability. I’m thinking by now I’ve gotten over the lazy bit.

My older blog I used to call my “everything website” — describing its handy utility as a general dumping grounds for my brain. After nearly a decade, it turns out I’ve still got stuff to dump somewhere, and it wouldn’t be fair lump it all on my beautiful and wonderful fianceé, whose brain neither runs regular backups nor has a handy search function.

Actually, this site doesn’t have a handy search function, either, (and actually my fianceé does have strikingly good memory). And that’s the next reason I put this up — to exercise my Web development and design chops which for the past two years have been running the hamster tubes of my full-time job with little room to stretch.

In summary, this is where you’ll get to see me do a lot of things that I haven’t done in quite a while, or haven’t quite tried at all in the past. So mind my stumbling!