Garrett Dawson | thedrearlight

Dependency injection ez-mode

2018-01-01T00:00:00+00:00

All that’s required is a closure. You’ll save yourself the grief of learning a mocking system like those that often come bundled with testing frameworks. While they can be useful, those mocking systems are often weirdly obtuse.

Say you have code like the following:

  import axios from 'axios'

  // Arbitrary example of something that looks real-world-ish
  export default function(baseURL) {
    const client = axios.create({
      baseURL,
      headers: { 'A-Header-That-I-Need': 'yep' }
    })

    return {
      get: endpoint => client.get(endpoint),
      post: (endpoint, payload) => client.post(endpoint, payload)
    }
  }

Looks pretty straight-forward, except that axios needs to be mocked during test time, as it produces side-effects like get and post. Let’s just circumnavigate the need for a mocking framework by using a closure for some dependency injection.

  import axios from 'axios'

  function _factory(theDependency) { // One extra closure
    return function(baseURL) {
      const client = theDependency.create({
        baseURL,
        headers: { 'A-Header-That-I-Need': 'yep' }
      })

      return {
        get: endpoint => client.get(endpoint),
        post: (endpoint, payload) => client.post(endpoint, payload)
      }
    }
  }

  export const Test = {
    _factory
  }

  // This right here. Just inject the dependency for the rest of the
  // application. The rest of your code won't tell the difference.
  export default _factory(axios)

From the perspective of the rest of our application code, nothing has changed, but unit testing just got easier. Unit tests can be written with the Test object instead of the default export, and we can more easily assert things about our code:

  import { Test } from 'out-http-client'

  // Some jest tests

  describe('http-client', () => {
    const get = jest.fn()
    const post = jest.fn()

    const fakeAxios = {
      create: () => ({
        get,
        post
      })
    }

    const client = Test._factory(fakeAxios)('https://an-base-url.biz')

    it('it calls `get`', () => {
      client.get(url)

      expect(get).toHaveBeenCalled()
    })

    // Et cetera
  })

Some slides -> http://thedrearlight.com/diy-di
Some examples -> https://github.com/killtheliterate/diy-di/tree/master/example

Writing JavaScript modules consumable as esm or cjs

2017-11-18T00:00:00+00:00

Most front-end developers know that we can’t just write JavaScript using the latest features and expect it to work across any environment. That’s why we use tools like babeljs to transpile our source code into ye olde JavaScript of 200X. Good on ya’.

When we’re writing libraries, we have the problem of not knowing what module format will acceptable to applications that use our library. Additionally, we need to consider how our library will impact bundle sizes.

That being the case, I like to build to multiple formats if I’m going to distribute my library on npm. This isn’t the easiest thing to do, and there’s a few ways to skin it, but it’s not too bad with a little boiler-plate and tools like rollup and Webpack.

`webpack` or `rollup`

If we’re writing a library, deciding is easy. Use rollup. I don’t know of a way to transpile to esm using webpack. However, I’m still including examples of webpack configurations, as I think it exposes a pattern that can be super useful, namely extensible configuration. I’ll likely write about that pattern in the future.

Goals

Deliver a library in multiple module formats (umd/cjs/esm)
Deliver a library that is transpiled, regardless of module format
Keep our library size down by omitting dependencies
Communicate module formats to folks that use the library

Extensible configuration

Both webpack and rollup are configurable to build to different module formats. Whichever we choose, we’ll want to create a base configuration that can be extended with information about what module format to target.

  // base.js

  // Both tools require a config object that has an `entry`
   export default {
    entry: 'src/index.js',
    // etc... This will differ based on what build tool we choose
  }

Now, we need to write configurations for multiple module formats by extending our base configuration. To do this, we use the trusty Object.assign. Notice that both of these examples export arrays.

  // webpack.config.js

  const baseConfig = require('./base.js')

  // umd
  const umd = Object.assign(
    {},
    baseConfig,
    {
      output: {
      filename: '[name].js',
      libraryTarget: 'umd'
      path: path.resolve(__dirname, 'dist/umd')
    }
  )

  // cjs
  const cjs = Object.assign(
    {},
    baseConfig,
    {
      output: {
      filename: '[name].js',
      libraryTarget: 'commonjs',
      path: path.resolve(__dirname, 'dist/cjs')
    }
  )

  // yep yep
  module.exports = [ cjs, umd ]

  // rollup.config.js

  import base form './base.js'

  const esm = Object.assign(
    {},
    base,
    {
      output: {
        file: 'dist/esm/index.js',
        format: 'es'
      }
    }
  )

  const cjs = Object.assign(
    {},
    base,
    {
      output: {
        file: 'dist/cjs/index.js',
        format: 'cjs'
      }
    }
  )

  export default [ cjs, esm]

Omit dependencies

Bundle sizes… yeesh. webpack and rollup both have the ability to exclude module dependencies from the bundles that are generated, a feature that’s very useful for libraries. By using it, we’ll reduce duplicate module code in applications that consume our library.

  // rollup
  const rollupBase = {
    external: [
      'debug',
      'rxjs/Observable',
      'rxjs/Rx',
      'rxjs/add/observable/fromEvent',
      'rxjs/add/operator/take'
    ]
  }

  // webpack
  const webpackBase = {
    externals: {
      'debug': 'debug',
      'rxjs/Rx': {
        commonjs: 'rxjs/Rx',
        commonjs2: 'rxjs/Rx',
        amd: 'Rx',
        root: 'Rx'
      }
    }
  }

Build it.

Now we just need a build script in package.json, and we can generate our distributable modules with npm run build.

  // package.json

  {
    "scripts": {
      "build": "npx rollup -c rollup.config.js"
    }
  }

Communicate module options

Now that we have a library that delivers a few different formats, we need to make sure our package.json points at things correctly.

main absolutely has to point at a cjs or umd format. Otherwise, we’ll be sort of breaking faith with the wider npm ecosystem.

Some build tools know to use module instead of main when importing modules. We’ll point module at our esm code, which is explicitly not our source code. Why? Well, we have no guarantee that folks consuming our library will have the appropriate transforms in their build pipeline, but we can still deliver tree-shakeable code, which once again helps reduce the bundle-size cost of using our library.

  // package.json

  {
    "main": "dist/cjs/index.js",
    "module": "dist/esm/index.js"
  }

Finally, good documentation about the various module formats is welcome. For instance, a umd build might not be exposed at all in package.json, but letting folks know where to get it is a nice-person move.

  <!-- README.md -->

  # Which formats?
  Blah blah blah. 

  If you want the `umd` build, grab it from `module/dist/umd`.

Real life

If you want to see a real life example of this, check out my observable-socket library. At the time I refactored it to deliver better module formats, I don’t believe rollup had the ability to receive an array of configurations, so the build script is quite a bit different.

GAMECHANGOR: tmux leader + ctrl-z WTF

2016-12-28T00:00:00+00:00

Use tmux? Split your window up like a hackor bozz? Need to focus a pane real quick? Did you even know that was possible? DID YOU EVEN KNOW THAT WAS POSSIBLE?

Just press leader and then press ctrl-z. POOF! Pane is focused now. As in, that pane becomes the only pane.Want to unfocus the pane? JUST PRESS leader AND THEN PRESS ctrl-z.

Webpack/Babel vs. npm link

2016-10-19T00:00:00+00:00

The scenario:

We’re writing a module in es2015, and transpiling it
We’re consuming the module in a project that is also transpiled with Webpack and Babel
To make working on these projects a little less painful, we’re using npm link to see changes in the module reflected in the consuming project, without having to do an npm publish

Webpack doesn’t ignore linked modules in node_modules when a loader is configured to ignore node_modules. I suspect this has something to do with symlinks, but haven’t really investigated it. A quick fix for the issue is to simply configure the Webpack loader to also ignore the module(s).

Easy enough in my case, as I always write modules to be transpiled into a dist directoy. I simply ignore dist in the Webpack loader.

  module.exports = {

      // ...blah blah blah

      module: {
          loaders: [
              test: /\.jsx?$/,
              exclude: /(node_modules|dist)/, // ignoring /dist
              loaders: ['babel'], // etc etc
          ],
      },
  }

Note To Self - Ubuntu Color Scheme

2016-04-03T00:00:00+00:00

So I’d like to use base16, but it does not work well using Vim in Gnome terminal. The line highlight basically obscures what I’m typing:

Pretty easy to fix with base16-shell. Install base16-shell (which requires adding a few lines to .bashrc/.zshrc), then add the following to .vimrc.

  let base16colorspace='256'
  colorscheme base16-default

GPG, Smartcards and SSH

2016-03-10T00:00:00+00:00

I’ve landed on a simple equation for what’ll remedy my current fear levels:

Abandon my SSH keys
Replace them with GPG keys + gpg-agent
Keep my secret GPG keys on a smartcard

3 things, NBD, but oh, the details. I’ll start from the bottom.

I picked up a Yubikey a couple of weeks ago. When I bought it, I didn’t really know what it was, but it looked security-ish. Turns out it is both a GPG smartcard and a hardware factor for multi-factor authentication. Cool.

Now, Yubikey as a hardware factor is peazy. I’m using it with LastPass, and it’s simply a matter of sticking it in a USB slot and touching the metal bit.

Using Yubikey as a smartcard is a bit trickier. This isn’t implicit to Yubikey, but smartcards in general. Additionally, using GPG keys to SSH places is kinda face-numbing. Since I’m new to GPG, I of course inadvertently opted to take the most-face-numbing-est path.

Some of the sights along the way:

Install GnuPG
Configure GnuPG
Configure gpg-agent
Generate a GPG master key (revocation certs, text backup, etc.)
Generate subkeys for authentication, signing and encryption
Publish keys to a keyserver
Move secret keys to Yubikey

If you, dear reader, would also like to use a Yubikey for SSH, then read on.

Installing Stuff

Regardless of where you’ll be generating your keys (Tails maybe?), you’ll need gpg2 and a few other packages on your daily computer.

  # mac
  $ brew install gnupg2 pinentry-mac

  # ubuntu
  $ sudo apt-get install gnupg2 scdaemon pcscd pcsc-tools pinentry-gnome3

Configuring Stuff

Next, you’ll need to configure gpg2 and gpg-agent. Read through this and this, then download them to ~/.gnupg. Both will need a bit of modification afterwards.

  # look at this before you download it, duh

  # yea, these are long, and look like shit when they wrap.

  # ~/.gnupg/gpg.conf
  $ curl https://raw.githubusercontent.com/ioerror/duraconf/master/configs/gnupg/gpg.conf > ~/.gnupg/gpg.conf

  # ~/.gnupg/gpg-agent.conf
  $ curl https://gist.githubusercontent.com/killtheliterate/e05ab738948cd00fcf35/raw/596b4b5a0dae98da496529fc35ebb365436f056a/gpg-agent.conf > ~/.gnupg/gpg-agent.conf

You’ll need to set up gpg-agent.conf to use a relevant pinentry program. For mac, I’m using pinentry-mac. For Ubuntu, I’m using pinentry-gnome3. Don’t use pinentry, which caused me so much grief that I’ll call it out again later in this post. You’ll also need to download the certificate described in gpg.conf and modify gpg.conf to point at wherever you decide to put the certificate.

Generating Keys

Now you’ll need to generate keys:

A master key
A subkey for encrypting things
A subkey for authentication (this’ll be for SSH)
A subkey for signing things

A lot of folks recommend generating these keys in an environment like Tails. If you use a Tails that has never been online, it’s less likely that your master key will become compromised. Bonus-mode, Tails has a feature to persist keys. This means you can have a secure copy of Tails on a USB flash drive, with an encrypted partition that contains your keys.

If you opt to go this route, you’ll need to move your subkeys from Tails to an OS that works with smartcards. Basically, export your subkeys, your public keys, and then put them on another USB drive. Plug that in to your daily computer and import your keys.

To export keys:

  $ gpg2 --export-secret-subkeys -a ${YOUR_KEY_ID} > private.asc
  $ gpg2 --export -a ${YOUR_KEY_ID} > public.asc

To import keys:

  $ gpg2 --import private.asc
  $ gpg2 --import public.asc

Publish Public Keys

Now that you’ve got some public keys, you should publish them to a keyserver. People will then be able to look you up and encrypte messages for you. If you’ve configured gpg.conf correctly, you can publish your keys to https://sks-keyservers.net. There are some good alternatives of course, such as http://keys.gnupg.net and https://pgp.mit.edu. From what I understand, publishing to one should propagate to the others.

My public key is available here.

Send your public keys:

  $ gpg2 --send-keys YOUR KEY ID

Set Up Yubikey

Alright… Finally, Yubikey. The gist is to configure your Yubikey, and then move your secret subkeys to it.

You’ll need to enable the smartcard interface of your Yubikey using ykpersonalize. This is pretty painless, and Yubico wrote a nice post about it here.

Now, configure the Yubikey. This means setting an admin password, a key password, and other optional pieces of information like your name. Of particular interest is URL of public key, as you can use that to fetch your keys should you ever need to (say you need to use someone else computer).

Both passwords you set up on the card should be strong. They key password is what you’ll be prompted for when using your Yubikey to encrypt/decrypt/authenticate.

  $ gpg2 --card-edit
  gpg/card> admin
  gpg/card> passwd
  # etc.

Hell Is scdaemon

Configuring my Yubikey is where this process became especially hellacious. I encountered many errors that basically amounted to scdaemon not working/running. scdaemon, as I understand it, is how gpg-agent connects to smartcards. If it’s not running, or is for-any-reason fucked up, smartcards won’t work. On Ubuntu, this was resolved by explicitly installing scdaemon and a few other packages. If you followed the install steps spelled out near the top, you should be good. For both Mac and Ubuntu I had to edit gpg.conf to use a pinentry program that was not pinentry, namely pinentry-mac or pinentry-gnome3. This bums me out, but it bums me out less than gpg-agent not working.

First and foremost, make sure gpg-agent is running.

  # this will say everything is chill-mode if it's running, and start it
  # otherwise
  $ gpg-agent 

Move Your Secret Subkeys

Alright, ready to move your subkeys to the Yubikey? Yup.

  $ gpg2 --edit-key YOUR KEY ID
  gpg> toggle # so we're working with secret keys
  gpg> key 1 # select the key you want to move
  gpg> keytocard 
  # Then select the slot to move it to. There should only be one option for
  # each subkey if you've made single-purpose keys.
  gpg> save 

If everything is legit, running gpg2 --card-status will print out a display that contains some info about your subkeys. Additionally, gpg2 -K will generate a little readout that displays your secret subkeys with a > preceding them.

SSH

As mentioned right up top, I mostly wanted to use a Yubikey for SSH. That requires a bit of configuration in .zshrc, .bash_profile, or whatever shell configuration file is relevant to you.

  if [ -f "${HOME}/.gpg-agent-info" ]; then
    . "${HOME}/.gpg-agent-info"
    export GPG_AGENT_INFO
    export SSH_AUTH_SOCK
  fi
  export GPG_TTY=$(tty)

Now, you’ll need an SSH compatible public key to add to, say, github, or authorized_keys. Get it by running:

  # copy/paste the relevant key
  $ ssh-add -L

Perfect. You now have a GPG key you can use for SSH, and it’s on a Yubikey. Paranoia abatement successful.

A slideshow about loops

2015-08-08T00:00:00+00:00

Develop Denver happened over the past two days. Like last year, it was a pretty good time, and I had the opportunity to present a talk on iteration in JavaScript. I think it went over alright, so I’ll post the slides here.

But what does it do… Closure.

2015-02-18T00:00:00+00:00

A closure is a function that captures the state that it’s surrounded by, closing over said state.

  (function(first) {
      return function(second) { // this function is a closure
          return first + second;
      }
  }(1)(1));

Uh, what do closures do…

Closures let us write code with a higher level of abstraction. A good thing, as abstraction allows us to solve more problems with less code. Now, by example. Let’s write a baby program that counts the occurrence of a particular word in a sentence.

  var str = `these are some words that i want to search for a thing, and i am
  searching, yea, searching`.match(new RegExp('thing')).length;

Works, pay me. But wait! What if our programs frequently needs to count words in sentences? Sounds like a task for a function:

  var counter = function(wordToCount, findIn) {
      return findIn.match(new RegExp(wordToCount, 'g')).length;
  };

Alright, okay. But wait! Our function requires two arguments when we call it. What if we don’t know the string that we’d like to search at this point in our program? We can abstract this a bit more with closures. Let’s build a function that returns another function.

  var counter = function(wordToCount) {
      return function(findIn) { // an closure, a closure.
          return findIn.match(new RegExp(wordToCount, 'g')).length;
      }
  }

Closures “know” about the variables defined in their enclosing scope. This has some interesting consequences when creating functions that return functions. In the last snip, counter contains a function that we can call like:

  var countTheWordSup = counter('sup');

We’ve assigned the value returned by counter() to a new variable. That returned value happens to be another function, so countTheWordSup essentially becomes the name of a function. Let’s call it:

  countTheWordSup('sup hi hey up up hi sup hellowww'); // 2

As if by magic, countTheWordSup() remembers the value we passed to counter() as “wordToCount”. Closure by example.

The Module Pattern

I made a trick on you! I’ve conflated closures with curried functions, as curried functions are what made closures really click for me. Closures are also visible in what is commonly referred to as the module pattern, which is perhaps a more typical introduction to closures.

The module pattern leverages closures to approximate private and public variables in classical languages:

  var uh = function() {
      var closed = 'hi';

      return {
          foo: function() {
              console.log(closed);
          }
      };
  };

  var hello = uh();

  hello.foo();

The function uh returns an object, a property on which is a function that references a variable in uh’s scope. The same mechanism is at work, though to a different end; here, we’re doing a bit of data hiding.

There’s quite a bit more to closures, but this introduction should give you enough utility that you’ll continue to explore other usages.

Run the code!

Originally published on the VictorOps blog

A Slideshow about Functional Programming and Javascript

2014-10-31T00:00:00+00:00

This past summer, I gave a talk at Develop Denver on functional programming with JavaScript. My hope was that I’d eventually have a video to post of the presentation. As there were technical difficulties with A/V, I’ve decided now to just post the slides. Enjoy them fullscreen.

Vim is better

2014-04-08T00:00:00+00:00

Choose an editor, know it thoroughly, and use it for all editing tasks. If you use a single editor (or set of keybindings) across all text editing activities, you don’t have to stop and think to accomplish text manipulation: the necessary keystrokes will be a reflex. The editor will be an extension of your hand; the keys will sing as they slice their way through text and thought. That’s our goal.

— The Pragmatic Programmer

If you’re interested in picking right, pick Vim… What’s that? You’re not convinced? Well, let me count only a few of the ways in which Vim trounces many other text editors and IDEs:

Longevity + Ubiquity = Reliability

Vim (Vi IMproved) was released in 1991. It builds upon the Vi text editor, which itself is an improvement over its precursor, ed. This lineage is battle-tested and reliable, to such a degree that Vi is installed on every *nix system that I have ever used. If you’re comfortable with Vim, you’ll feel comfortable with Vi. Never feel like your hands are cut off when working in a remote environment.

You’d be forgiven for assuming that Vim’s long history is an indicator that it might be going stale. However, the opposite is true. Vim continues to be improved, with new plugins and extensions being written and released all the time. There are even projects like NeoVim, which is an attempt to further ensure Vim’s longevity.

The longevity and ubiquity of Vim translate to reliability other text editors don’t possess. You can feel reasonably certain learning Vim won’t be a skillset that goes out of fashion, and that feels pretty good.

Open Source

Picking open source tools isn’t just a matter of preference. They often work better, due to the collaborative nature of open source software development, where many people can audit and improve the code. As a bonus, open source tools are often free.

Mode based editing

Mode based editing is the killer Vim feature. It allows for complex manipulations of text, usually with a few contextually concise commands, all accessible from the keyboard. This creates a paradigm where one can “edit text at the speed of thought”. Now, don’t misunderstand me; As a Vim user, I’m not typing a billion words per minute. When I’m working with text, I’m thinking about what I want to do instead of how I can do it. Once you get the hang of mode based editing, Vim commands become second-nature. Many are easily remembered with a mnemonic, like “Change inner word (ciw)”.

Most Vim users work primarily in three different modes, each one suited to different kinds of text editing tasks.

Normal mode: use for navigating and manipulating text
Insert mode: use for inserting text
Visual mode: use for selecting text

Insert and Visual mode are pretty solidly represented in most text editors. Normal mode, however… Normal mode is where Vim slays other editors. Rather than treat this article as a tutorial, where I show you how to use Normal mode (there are tons of those, I’ll instead say check, ch-check ch-check it out.

Operators

In Vim, Operators are things you’d like to do to text. Examples:

delete a line or character
changing a line or character
yank a line or character into a register or buffer

Motions

Motions are “commands that move the cursor”. Motion examples:

move 2 words right
move to the last paragraph
go to the closing parentheses

Text Objects

Text objects are chunks or groups of characters. Text object examples:

a word, and the whitespace around it
a paragraph, without whitespace
the body of a function

So, big deal, right? Well, Vim excels at combining these stupid simple concepts in extremely powerful ways. Let’s say I want to change the body of a paragraph, and get dropped immediately into Insert mode. That’s a very simple task if I combine the change operator with the text object inner paragraph: cip

Howzabout I want to delete the next two words without having to hit the delete key over each character in each word. Again, easy peaze if I combine a count of 2 with the delete operator and the motion to start of next word: 2dw

The above examples should simply illustrate that Vim is all about combining small things into large things, about building relationships between different commands. You may recognize this as adherent to Unix philosophy. A good way to remember this pattern is: {count}{operator}{text object or motion}

Learning Vim

Using Vim is not as hard as you’ve been told. Its learning curve has been exaggerated. However, new Vim users often struggle with configuring Vim. You can get around this problem on easy-mode by using Janus, which is a distribution of plugins and configuration put together by Yehuda Katz. If you’re interested in my Vim setup, I keep it at GitHub. Additionally, there are many resources for learning Vim, a few of which are:

Vim tutor — Vim’s inbuilt tutor
Open Vim — an online interactive Vim tutorial
Vim Tips Wiki — a good source for tips on using Vim
vimcasts.org — great screencasts about Vim
Practical Vim — an excellent book that contains really great Vim recipes

If you don’t get the swing of Vim right out of the gate, remember:

Originally published on the Aten blog

Adding JS libraries to a Drupal project with Libraries API

2013-11-05T00:00:00+00:00

To be entirely clear, a library is a bundle of code, often times CSS and JS, though it may be a bundle of PHP, or something else entirely. It‘s usually agnostic in the sense that the library isn‘t targeted to Drupal applications.

In the past, I‘ve added JS libraries directly to my theme, and then added the script to a page with drupal_add_js(). This means that the library is confined to the theme. If I want to use the library in a custom module as well, I have to reliably know the name of the theme, as that’s how drupal_get_path() works. That’s just straight-up bad practice, as it doesn‘t lend itself to modularity or reusable code.

Another method for adding JS libraries is the use of contributed modules named for the JS libraries they implement. The downside is that these JS libraries are often configured via the Drupal UI and frequently limit the configuration options of the library, or they are coupled to an outdated version of the library. In most cases, a requirement for these modules is that the library be added via Libraries API anyways.

By contrast, If I take the time to write a few extra lines of code and implement the library myself, I can ensure that it‘s available to other modules or themes in the project. This allows me to interact with the library the way the original author intended.

Working with Libraries API is fairly straightforward. As with all things, it’s a good idea to read the full documentation, which can be found at https://drupal.org/node/1342238, but you can get rolling with just a few lines of code.

Quick overview:

Install Libraries API
Add the library to sites/all/libraries
Create a very short custom module that tells Libraries API about the library
Add the library to the page where you want it
Use it!

Install Libraries API

You’re using Drush, right? That’s what I thought. To install Libraries API, simply:

  $ drush dl libraries

Next, create a directory at sites/all/libraries. If you‘re not using Drush, download the module from drupal.org/project/libraries, and add it to the contrib modules directory.

Add the library to sites/all/libraries

Download a library, and add it to the libraries directory at sites/all/libraries. For this example, I‘m using a JS library called FlexSlider to add a carousel to my project. To add the library, I download flexslider, and add it to my Drupal project as sites/all/libraries/flexslider.

Create a very short custom module that tells Libraries API about the library

In a custom module, use hook_libraries_info() to make the library available to the entire project. Once a library is registered, it can be used in custom modules, themes, whatever.

  /**
   * Implements hook_libraries_info().
   */
  function MYMODULE_libraries_info() {
    $libraries = array();
    $libraries['flexslider'] = array(
      'name' => 'FlexSlider',
      'vendor url' => 'http://flexslider.woothemes.com/',
      'download url' => 'https://github.com/woothemes/FlexSlider/zipball/master',
      'version arguments' => array(
        'file' => 'jquery.flexslider-min.js',
        // jQuery FlexSlider v2.1
        'pattern' => '/jQuery FlexSlider v(\d+\.+\d+)/',
        'lines' => 2,
      ),
      'files' => array(
        'js' => array(
          'jquery.flexslider-min.js',
        ),
      ),
    );

    return $libraries;
  }

One gotcha that seriously gotcha‘d me is the necessity of providing a value for either version argument or version callback. The documetation for hook_libraries_info() says that both are optional, but if at least one isn‘t provided, the library isn‘t available to load. If you‘re not concerned about the version of the library, you can use a short-circuit function for the version callback:

  /**
   * Implements hook_libraries_info().
   */
  function MYMODULE_libraries_info() {
    $libraries = array();
    $libraries['my_library'] = array(
      // Etc etc.
      'version callback' => 'short_circuit_version',
    );

    return $libraries;
  }

  /**
  * Short-circuit the version argument.
  */
  function short_circuit_version() {
    return TRUE;
  }

Add the library to the page where it‘s needed

In this case, I‘d like to load the FlexSlider JavaScript with a specific view. Hence, a views hook is appropriate. Notice the nice trick for hooking specific views.

  /**
   * Implements hook_preprocess_views_view().
   */
  function MYTHEME_preprocess_views_view(&$vars) {

    // Uncomment the lines below to see variables you can use to target a view.
    // This requires http://drupal.org/project/devel to be installed.
    // dpm($vars['view']->name, 'view name');

    // Hook view id specific functions.
    // This is a super neato trick.
    if (isset($vars['view']->name)) {
      $function = 'preprocess_views_view__' . $vars['view']->name;
      if (function_exists($function)) {
        $function($vars);
      }
    }
  }

  /**
   * Implements preprocess_views_view__VIEW().
   */
  function preprocess_views_view__YOURHOOK(&$vars) {
    $display_id = $vars['display_id'];
    $classes = &$vars['classes_array'];
    $title_classes = &$vars['title_attributes_array']['class'];
    $content_classes = &$vars['content_attributes_array']['class'];

    // Uncomment the lines below to see variables you can use to target a view.
    // This requires http://drupal.org/project/devel to be installed.
    // dpm($vars['view']->name, 'view name');

    switch ($display_id) {

      // Call flexslider scripts.
      case 'page':
        libraries_load('flexslider');
        break;
    }
  }

Use it!

Now that FlexSlider is loaded, I can bind it to my view!

  (function ($) {
    $(window).load(function() {

      $('.slideshow').flexslider({
        animation: "slide",
        controlNav: false,
        namespace: 'slide-',
        selector: '.slide-list > .slide-list-item'
      });

    }); // end window.load
  })(jQuery);

As you can see, Libraries API allows for a much more elegant and scaleable way of managing JavaScripts.

Originally published on the Aten blog

JavaScript Hyperspace

2013-03-11T00:00:00+00:00

Today, I’d like to take a moment to describe some common JavaScript vocabulary that many of us have heard, though we may have only the vaguest sense of their meaning. With an expanded vocabulary, the application of the right tool becomes easier.

CommonJS

CommonJS is an API aimed at creating a standards library for JavaScript beyond the browser. It is created, promoted, and refined by the CommonJS Group. Its mission statement defines it as an organization primarily focused on API design for server side adoption, but the influence of CommonJS can be felt in the larger community. For instance, AMD is informed by CommonJS Module Identifiers.

RequireJS

RequireJS is a JavaSript module loader. It’s tight. From its docs:

RequireJS is a JavaScript file and module loader. It is optimized for in-browser use, but it can be used in other JavaScript environments, like Rhino and Node. Using a modular script loader like RequireJS will improve the speed and quality of your code.

I recently wrote a post detailing how Require.js might be able to fit in with Drupal.

Backbone.js

Backbone.js is a JavaScript framework that upholds an MV* approach to application design. If that acronym throws you, read this awesome post by Addy Osmani. With Backbone.js, one can more sanely create JavaScript rich applications. It provides the foundations for creating models, relating them to views, routing requests to other views, etc. From its docs:

Backbone.js gives structure to web applications by providing models with key-value binding and custom events, collections with a rich API of enumerable functions,views with declarative event handling, and connects it all to your existing API over a RESTful JSON interface.

Underscore.js

Underscore.js is a small JavaScript utility library. It gives JavaScript developers some of the fancy stuff that programmers of other languages take for granted. From its docs:

Underscore is a utility-belt library for JavaScript that provides a lot of the functional programming support that you would expect in Prototype.js (or Ruby), but without extending any of the built-in JavaScript objects.

Underscore.js is a dependency of Backbone.js, so if you’re considering Backbone.js, you’re considering Underscore.js. Not a terrible thing, as Underscore.js is teeny tiny, and gives us some great JavaScript methods.

Zepto.js

Zepto is a jQuery-like library with pretty specific design goals. It aims to almost completely replicate the jQuery API while staying light as a feather, a feat Zepto achieves mostly by removing cross-browser compatibility cruft from jQuery. From its docs:

Zepto is a minimalist JavaScript library for modern browsers with a largely jQuery-compatible API. If you use jQuery, you already know how to use Zepto.

Now, cross-browser compatibility cruft is why a lot of us use and love jQuery; so as to have predictable JavaScript across many browsers. But if your primary concern is modern browsers and lightweight pages, Zepto is worth a hard look.

Ember.js

Ember.js states simply that it is a “framework for creating ambitious web applications.” It’s a JavaScript framework similar to Backbone.js, but diverges from Backbone.js in that Ember.js favors convention over configuration (ala RoR). Where Backbone.js leaves one with the freedom and sometimes curse of figuring out how all the parts of an application fit together, Ember.js seems to say “I already thought about this, jerk.”

Handlebars

Handlebars is a JavaScript library for HTML templating, a paradigm that is very useful when building complex applications: Rather than dropping strings of markup directly into JS code, we can define templates with dynamic content for use in our applications. From its docs:

Handlebars provides the power necessary to let you build semantic templates effectively with no frustration.

Modernizr

Modernizr is a sweet library that tests browsers for feature support. If we can detect what features a user’s browser is capable of, then we can progressively enhance their experience accordingly. From its docs:

Modernizr is a JavaScript library that detects HTML5 and CSS3 features in the user’s browser.

Modernizr allows for this progressive enhancement by adding CSS classes to the html element on page load. These classes reflect functionality we might want to leverage, for instance, CSS gradients. If a user doesn’t have that capability in their browser, we wind up with a class called “no-cssgradients”, and can either polyfill this discrepancy or write CSS that progressively reflects this.

Express

Express is a little framework for creating web apps with node.js. It looks a lot like Sinatra, in that it can be a dead simple mechanism for defining routes that resources are available at. From its docs:

Express is a minimal and flexible node.js web application framework, providing a robust set of features for building single and multi-page, and hybrid web applications.

You can probably already imagine creating a simple RESTful service with Express that could spoon feed data to a Backbone.js application.

Of course, the moment this distilled glossary is published, there will be a new framework, library, or utility that will be worth consideration; that is the nature of the ever shifting landscape of web design.

Originally published on the Aten blog

On Require JS and JavaScript Architecture in Drupal

2013-01-09T00:00:00+00:00

I’ve been trying to become a better JavaScript developer. As a front-end developer, JavaScript is a topic that cultivates programming skills in a language often used to craft spectacular interaction design, something any good front-end developer should be very interested in. In conjunction with the obvious deepening of my JavaScript knowledge, one of my areas of focus is the organization of JavaScript code, specifically within Drupal.

Organization is something we give a lot of thought to at Aten Design Group. We are fairly collaborative, and within this context, the merits of thoughtfully organized code are self-evident. We strive for clarity in the arrangement of our Drupal modules, the naming conventions used for our SASS components and the verbosity of our GIT commit messages and branches. Another such space is in the organization of JavaScript within our Drupal themes and modules.

Enter the JavaScript Module Pattern (not to be confused with a Drupal module, though the idea of reusable code persists). Rather than lumping code into a gargantuan main.js, something one frequently sees in theme development, we can create thoughtfully named and reusable JavaScript modules. It gives us a way to write and encapsulate JavaScript functions in a manner that denotes their specific usage, leading to a more easily maintained project.

For instance, we can write a JavaScript module that loads content into a modal popup box, independent of what content will actually be loaded. We can then use the module in, say, js/main.js where we’ve noted that on such and such page, such and such form should be loaded and displayed to the user, while on such and such other page, such and such other form should instead be displayed. When done right, debugging problems with the aforementioned interaction can be minimized, something intrinsic to better code organization.

  // This is js/modules/myJavaScriptModule.js
  var myJavaScriptModule = (function(){
    var myJS = {};
    myJS.moduleMethod = function () {
      // Do something terribly useful, right here.
    };

    return myJS;
  }());

  // This is js/main.js
  Drupal.behaviors.myModule =  {
    attach: function (context, settings) {

      // Use the terribly useful JavaScript Module.
      myJavaScriptModule.moduleMethod();
    }
  };

Note, this assumes that these files have been loaded in the right order.

Now, JavaScript modules can be somewhat sticky, in that they still don’t solve some of the larger issues inherent to JavaScript. A much espoused creed in JavaScript is “Don’t Pollute The Global Namespace! Exclamation!”. JavaScript modules generally export their value into the global namespace, and while this isn’t always disastrous, it can lead to strange bugs or code implosions. This is particularly true when working with code you didn’t necessarily write, or when you expect your code to be reused by strangers. Another issue that persists is the handling of dependencies. If your JS module needs another JS module to function, you better make sure they are loading in the correct order. Now imagine this problem snowballing as one breaks more and more code out into JS modules.

These issues, amongst others, are addressed if one takes JS modules a step further, with Asynchronous Module Definitions. Dependency management is handled, as the function won’t execute until all of its dependencies have loaded. Additionally, JS modules are loaded asynchronously, which means a more performant JavaScript experience.

  define(['aDependency'], function (aDependency) {

      // Define the module value by returning a value.
      return function () {};
  });

We’re getting warmer, but this is where things begin to get a bit sticky when working with Drupal, as once we have an AMD specified piece of code, we need a means by which to load it. A likely candidate for AMD module loading is RequireJS, but using RequireJS within Drupal is not simply a matter of dropping it into your theme or module. And thus, the ramble. It begins like this.

JavaScript Architecture in Drupal - Moving Forward

In Drupal, JavaScript lives all over the place. It exists in Drupal core, contributed and custom modules, and in Drupal themes. This makes for an interesting problem, in that JavaScript is not the sole problem domain of front-end developers, as it is often described. We have a PHP function for interacting with this, in the form of drupal_add_js(). This aggregates all JS into an array, where JavaScripts are loaded based on their respective weight in the array. Controlling these weights can be very cumbersome, particularly for the front-end developer.

Essentially, Drupal’s JavaScript architecture has a completely unique and sometimes eccentric API for interacting with a larger problem domain. This brings to mind a term I’ve come across in the time I’ve been a Drupal developer. The term is Drupalism. A Drupalism is something that is needlessly unique to Drupal, in that it is a weird way we Drupal developers do things. Now, I’m not saying outright that drupal_add_js() is a Drupalism, but the JavaScript architecture of Drupal is not something one can instantly acclimate to. JavaScript in Drupal is not as malleable as it ought to be. Derivative of this is the fact that, as a front-end developer, I cannot easily update jQuery or use RequireJS for loading AMD modules.

As Drupal 8 continues to take shape, Drupal developers should more loudly discuss the management of JavaScript in Drupal. There are a few threads on drupal.org that discuss AMD in Drupal. And though it may be too late this go-around, we should consider creating a more pluggable JavaScript architecture, perhaps leveraging RequireJS for module loading. It occurs to me that implementing a widely used system like RequireJS might attract new front-end talent to Drupal. This would be analogous to a noted benefit in the decision to add Symfony2 to Drupal core, in that “The use of widely used libraries and techniques makes Drupal more approachable to new developers.”

Onward, to RequireJS

Though we cannot immediately reap all the benefits of AMD JavaScript modules and RequireJS in Drupal, we can still use these tools in a meaningful way. There is overlap between Drupal’s JavaScript architecture and RequireJS, but they aren’t mutually exclusive. If our corner of Drupal (theme or module) can benefit from better JS organization, we can arrange and load AMD modules, and then funnel this conglomerate to the extant JavaScript API with drupal_add_js().

There are a great many tutorials on using RequireJS, and in an effort to keep the scope of this already rambling post a bit more concise, I’ll leave it to the reader to look to those. Of particular note is r.js, which will optimize AMD performance. Here, I’d like to describe special considerations in implementing RequireJS from within a Drupal theme.

Once we’ve arranged our JavaScript using the AMD pattern, we need only add the RequireJS script tag to our theme in order to load these modules. This can be done from template.php, as follows:

  /**
   * Implements hook_preprocess_html().
   */
  function mytheme_preprocess_html(&$vars) {

    drupal_add_js(drupal_get_path('theme', 'prototype') . '/js/require.js', array('every_page' => TRUE, 'external' => TRUE));
  }

  /**
   * Implements hook_preprocess_html_tag().
   */
  function mytheme_preprocess_html_tag(&$vars) {
    if (isset($vars['element']['#attributes']['src'])
        && $vars['element']['#attributes']['src'] == '/' . drupal_get_path('theme', 'mytheme') . '/js/require.js') {
            $vars['element']['#attributes']['data-main'] = '/' . drupal_get_path('theme', 'mytheme') . '/js/main';
    }
  }

This approach, though not perfect, is still relevant if one plans on implementing more complex JS in displaying or manipulating Drupal data. There are decisions to be made about what kind of interactions should occur with the larger architecture, but one tangent is enough for today. For now, it’s nice to know that RequireJS and drupal_add_js() can get along as we pursue a clean JavaScript architecture in Drupal.

Originally published on the Aten blog

Content panes fit so good into Panels that it is really silly

2012-09-13T00:00:00+00:00

The quote I borrowed for the title of this post is from Johan Falk, who will be sorely missed by the Drupal community, as the screencast series he produced for Node One on Page Manager is exceptionally informative, and often hilarious. If you haven’t seen the series, check it out.

Ahem, Okay. First, let’s understand what Page Manager actually is; Page Manager is a sort of responder to HTTP requests that overrides Drupal’s natural behavior. Drupal generally establishes a URI structure that dictates where a piece of Drupal content lives. With Page Manager, we can begin overriding Drupal’s behavior, injecting content that is architected with something like Views where Drupal content would normally be. I guess that means that Page Manager is really a content manager, at least in application. If this is a poorly formed assumption, please leave a comment.

Used is conjuction with Panels, which is a layout manager, we suddenly have enormous potential for controlling the typical content that appears at, say, node/ or taxonomy/term/. We can more easily control the content flow. This is just the thing I need to manipulate what typically appears at Drupal’s often used, but pretty lame, term pages.

Here is my use case. I’ve built a navigation using Taxonomy Menu, which is rad, as I have a large dynamic Taxonomy that needs to control the flow of how a user winds up on a node page. By default, each menu item links to the term page used to build it.

At a term page, I want to see any node that have been tagged with the term, and any child terms that the term has, so that I can build a pretty looking catalog. Like this:

Parent term (i want to see a list of all children)
- Child term (i want to see a list of all grandchildren)
-- Grandchild term (this is where I want nodes to appear)

This can be halfway done with Views, or maybe even completely done with Views, but attempting a pure Views approach was like pulling out my own teeth. So, this is where I turned to Page Manager, as I can begin overriding what appears at a term page.

Because of Drupal’s kindness, we have an argument available at a term page that dictates what term appears. This means Page Manager can know that argument, and we can then pass that argument to whatever appears on the page. In our case, thats Views Content Panes. So, enable Page Manager and Panels, and then enable the term page manager that it comes with stock.

Okay. If you’ve watched Johan’s screencast, you should have a sense of what is going on here. We’ve enabled the page override, and now we need to tell it what to do. So, we’ll create a variant that responds to a request for a term with a panel display. Using Page Manager’s selection rules, we can also instruct Page Manager to only respond if the request is for a term that belongs to a particular category. In my case, this is my navigation taxonomy.

Now, we can use the Panels layout interface to determine what kind of panels system we want. I’/m not looking for anything fancy, so I used a single column layout.

Now, lets hop over to Views, where we’ll build some content to feed to Page Manager. In my case, I want two distinct views; One that returns nodes, and one that returns child terms. With page manager, we can get these to co-exist on a single page if the Views display is a Views Content Pane. This is a new display option that one has after enabling Page Manager.

It’s worth noting that, by default, Page Manager can display child terms of a term, but this is better done with a view so that we can include fields attached to the terms, just like with any view.

Now for the tricky part. For each of these views, we essentially want to contextually filter them with an argument that is being passed to the view by Page Manager. Johan Falk suggests using “context” as the argument input for each view, but I couldn’t get this working. Instead, I’ve used Panel arguments.

So, build and configure the master display for each view as normal. This means creating a contextual filter based on a term id.

For the node view, we get this via a relationship called “Content: Taxonomy terms on node”, and a contextual filter of “(term) Taxonomy term: Term ID”.

For the term view, we’ll add a relationship called “Taxonomy term: Parent term”, so that we can use the parent term’s tid to filter. Again, we’ll add a contextual filter called “(Parent) Taxonomy term: Term ID”.

Now, for magic. As we have two views that can be contextually filtered by a term id, we can configure where that contextual filter comes from. To do so, create a new display for each view, selecting “Views Content Pane” as the display type. Once that is done, we can configure where that contextual filter is fetched from, using the “Argument Input” setting.

Configure each view to get it’s contextual filter argument from “Panel Argument 1”.

Now we’ve got some views to plug into Page Manager. Navigate back to Page Manager, and add some content to our term view override. At the content tab, hit the little gear and select “Add Content”. In the list of options under “Views Panes”, we can see both of the content panes we just built. Add both, and arrange them however you like.

Now, on a term page, we’ll see a list of Child terms, and any nodes tagged with that term. The views content panes are responding to the argument that typically exists on the page, which is being passed to the view as a panel argument.

WHOAWHOA, a Tmux trick.

2012-08-31T00:00:00+00:00

Et voilà

First, we need to add a line to .tmux.conf, so that we have a different prefix for issuing commands to a nested Tmux sesh:

  # nested tmux, obey me 
  bind-key a send-prefix

Next, once we’ve used the powerful Tmuxinator to start a Tmux session, we’ll start an additional Tmux session in one of our panes, first issuing the following command in the pane where we’d like the session to occur:

  $ unset TMUX

Finally, we’ll bend the nested Tmux session to our will by using the nested prefix we defined in .tmux.conf:

  C-a a

Notice that we’re sort of double-doing the Tmux command. Now we can cycle through windows and panes within our nested Tmux session. HIGHFIVE!

Tmux and Vim, get marrieder. Or, Tmuxination.

2012-08-26T00:00:00+00:00

Tmuxinator

Tmuxinator allows one to run a single shell command which launches Tmux, and instantly runs all of the commands you might typically use in setting up your workspace. Things like mysql.server start, splitting panes and windows, starting irssi, etc… It’s super fun fun rad.

Installation is pretty easy, if you’re comfortable installing Ruby gems. I’ll assume you’ve already set up an environment using rbenv or rvm:

  $ gem install tmuxinator

Ta-da!

Per the github project page, be sure to specify a $SHELL variable and an $EDITOR variable in your respective .bash_profile or .zshrc.

With Tmuxinator, we can now create a persistent development environment by using a yml file, named for the environment. We can make this project specific, but I prefer to use a general development environment, as I work with many projects a day.

  $ tmuxinator new development

This command will create a yml file in ~/.tmuxinator called development.yml. Using this file, we can specify what panes and windows will open with Tmux, and what programs will launch therein. Below is the configuration I’m currently using. Nothing too fancy, but you’ll notice that I use “pre” to launch mysql.

  project_name: development project_root: ~/ pre: mysql.server start tabs:
    - edit: layout: 553c,178x51,0,0{116x51,0,0,61x51,117,0} panes:
          - vim
          - irssi
    - shell: layout:
    e062,178x51,0,0{89x51,0,0,88x51,90,0[88x25,90,0,88x25,90,26]} panes:
          - #empty
          - #empty
          - #empty
    - remote: layout: even-horizontal panes:
          - ssh me@myserver
          - #empty

There are 3 windows, and each window has a few panes that open when I launch tmux. The layout bit specifies how I would like those panes to be arranged, what size I’d like them to be, and what programs I would like them to run by default. A good question was asked, and then answered, at stackoverflow as to how one can figure out the pane layout. Basically, it consists of running tmux, arranging panes, and running :list-windows to see the layout one can feed tmuxinator.

Now, one only needs to run tmuxinator start development, and all panes and windows will start.

Using Compass and Sass for Drupal Projects

2012-08-13T00:00:00+00:00

The route I traveled to become a Sass evangelist was long and harrowing. Less harrowing than long, though. I’d been hearing talk for a while about this new syntax for writing CSS, and it wasn’t something I was terribly interested in until Drupal Camp Colorado; I saw Mason Wendell give a talk on designing in browser, and how much easier it becomes if one uses a syntax like Sass.

I left Mason Wendell’s talk full of enthusiasm, with visions of Sass supremacy in all of my projects. Yet, one thing eluded me still. Step one. How to install and use Sass. More specifically, how I was going to use Sass in Drupal projects.

I’ll assume that you don’t need to be convinced that Sass is the shit. Instead , I’m going to show you how to install the appropriate packages in order to use Sass, and how to begin using them in your Drupal projects.

Creating a Ruby environment with rbenv

As Sass is a Ruby gem, you’ll need to create a decent Ruby environment to work with it. I’ll forever advocate circumnavigating the defaults that come with OS X, instead opting to install anything I can with a package manager like Homebrew. So, we’re going to use brew to install a Ruby manager called rbenv and its sister utility, ruby-build.

  $ brew install rbenv $ brew install ruby-build

If the above does not go seamlessly, you can use the brew doctor utilty to understand why. Next, add the following to a shell profile, be it .zshrc or .bash_profile:

  eval "$(rbenv init -)"

Now let’s re-source our profile:

  $ source .zshrc

Finally, we need to install a version of Ruby that we plan to use globally.

  $ rbenv install 1.9.3-p194 $ rbenv global 1.9.3-p194

That’s about it. We’ve got a Ruby environment!

Installing Compass and Sass

Sass is an excellent syntax, but Compass is a utility that makes it so much more. A trite analogy: Sass is a nail, Compass is a hammer. Sass is the syntax, and Compass is the compiler.

Compass provides one with dozens of predefined mixins, helper classes, and shortcuts for generating vendor prefixes. It’s also the means by which one converts a .sass or .scss file into regs-ass CSS. Installing Compass installs Sass, so might as well.

  $ gem install compass

Pull it all together, and build a Drupal theme

Now that we have the tools, we need to apply them to Drupal. Easily done. I’ll assume that you’re familiar with creating themes for Drupal.

There is a Compass tool specifically tailored to Drupal, aptly named Compass Stylesheet Tool. We could use this, but I find it is a far better workflow to work with Sass the way it was intended, as a syntax that is compiled locally, instead of by a utility on a server. One of the primary advantages to this approach is the abscence of worrying about keeping a remote version of Compass up to date.

I like to create my themes using Tao as a parent theme, as it cleans up a few annoyances that are inherent to Drupal. It gives me a super vanilla template, with a few theme overrides and good examples of how to create my own.

Build a sub-theme of Tao. If you’re not sure how, a guide exists at drupal.org. Once we have a sub-theme, open up a terminal, and navigate to it:

  $ cd /to/the/location/of/your/sub-theme $ compass create

Running the compass create command generates a few base files and directories; If this isn’t what you want, you can easily omit everything using alternate commands found here. I like these defaults, which include:

config.rb - this is where we can adjust the project’s compass settings
stylesheets/ - CSS that will actually be used by the site
sass/ - where we write styles that are compiled to CSS
A few .sass files in sass/ - delete them, or review them, as they might be relevant to your project

Be sure to add the Compass generated .css files to my_theme.info, as this is the only bit that a web browser cares about. Now we can theme away using Sass to write styles, and Compass to compile them to css. To compile to CSS:

  $ cd /to/the/location/of/your/sub-theme 
  $ compass compile 
  # Or, if you’d like Compass to generate CSS on the fly 
  $ compass watch

Tmux and Vim, get married.

2012-08-05T00:00:00+00:00

Using a rad, aesthetically pleasing, and efficient development environment is so crucial to having a good day. I’m going to describe mine, and give you the set of links from which I’ve assembled this confection. We’ll be using:

Vim & MacVim First, one must install MacVim. Duh. With homebrew. Duher.

  $ brew install macvim

Now we’ve got MacVim, which is a gui flavored Vim. It’s wildly useful, and a bit more comfortable for those of us accustomed to cmd-tab’ing through our applications. Still, we’ll want Vim.

The Vim that comes stock with OSX sucks all sorts of members. Welp, there’s a better way. Install Vim with homebrew. As it’s a dupe of a stock OSX application, we need to tap homebrew/dupes, and install from there.

Installing Vim from hombrew/dupes can be sort of tricky, though. I wasted about an hour, smashing my face into something solid, unable to understand why homebrew was exploding while trying to compile Vim. I’m still not sure what was happening, but I know how I fixed it.

I manually changed what version of Vim is fetched from Google’s code repo. You should too, until that shit is fixed.

  $ brew tap homebrew/dupes    
  $ vim /usr/local/Library/Taps/homebrew-dupes/vim.rb  
      
  # At the very top, replace url
  url 'https://vim.googlecode.com/hg/', :tag => 'v7-3-617'

  $ brew install homebrew/dupes/vim

Boom-Bapper!

I still bounce back and forth from MacVim to Vim, though I’m getting more in the habit of sticking to Vim. MacVim is tops, though.

Janus Now, as anyone who’s ever opened Vim can tell you, it’s terrible

until you add some plugins to it. A tedious affair. Made less tedious by something called Pathogen. Made lesser tediouser by a plugin manager called Janus. Let’s go with Janus.

  $ curl -Lo- https://bit.ly/janus-bootstrap | bash

More Plugins!!! Janus is extremely easy to extend with additional plugins

by using Pathogen. We can create a directory called ~/.janus, into which we can install all sorts of code loot.

  $ mkdir ~/.janus $ cd ~/.janus

Now, let’s start downloading!

tComment - nice shortcut for commenting things

  $ git clone https://github.com/tomtom/tcomment_vim

Powerline - looks pretty

  $ git clone https://github.com/Lokaltog/vim-powerline

Solarized Theme - looks pretty

  $ git clone https://github.com/altercation/vim-colors-solarized

Eunuch - use things like “:SudoWrite”

  $ git clone https://github.com/tpope/vim-eunuch

Chool. Next up, let’s personalize Vim a bit, using Janus’s vimrc scheme. If you’re not familar with how Vim stores it’s setting, they’re traditionally in a file called ~/.vimrc. Janus does it a bit different, using a .vimrc.before, and a .vimrc.after. They both live in your home directory. The reason they remain separated is so that one can override Janus, before AND after.

  $ vim .vimrc.before

  " Add this line, because tComment is better call
  janus#disable_plugin('nerdcommenter')

  $ vim .vimrc.after 
  " Copy in a .vimrc boiler plate

I found a pretty good boiler plate for .vimrc.after at net.tutsplus, though mine has a few additions. It’s here, if you’re interested. Which you ought to be, as I’m using the Solarized color scheme.

Also, we’ll need to install a patched font so that Powerline will function properly. Powerline draws fancy characters in the status bar of Vim. This one is my favorite —> https://gist.github.com/1627888

OSX’s terminal emulator for iTerm2. It handles some stuff just a little bit better. Download it here.

Once we’re iTerm2-ing it, create a new profile for yourself at Preferences

profiles. Next, download Solarized for iTerm2 here. Once that’s done, we can load a theme into iTerm2’s color presets. Navigate to the “Colors” tab, and expand “Load a preset”. You can import your preferred flavor of Solarized. Once it’s imported, set it using “Load a preset”.

Navigate to Preferences > Text, and change your font to whichever patched font you’ve settled on for Powerline. Then, uncheck “Draw bold text in bold font”. Double check that your terminal type is set to “xterm-256color” in Preferences

Terminal. Finally, in Preferences > Keys, set the left option key to +Esc.

Phew…

zsh/oh-my-zsh Bash has been a good friend. However,

zsh is better. And it’s so easy to install with oh-my-zsh.

  $ curl -L https://github.com/robbyrussell/oh-my-zsh/raw/master/tools/install.sh | sh

Now, we’ve got a nice copy of zsh, prefab’d with a bunch of cool plugins.

Zsh is easily customized with a ~/.zshrc. As always, when working with homebrew packages, we’ll need to make sure they’re first in our path. Easily done by adding the following to .zshrc:

  # $PATH # This puts homebrew packages first in path
  PATH=/usr/local/bin:/usr/local/sbin:$PATH

Tmux The cherry on top; Install Tmux.

  $ brew install tmux

Copy/Paste can get weird, so we’ll use homebrew again:

  $ brew install reattach-to-user-namespace

Add the following to ~/.tmux.conf

  # zsh is kinda tight set-option -g default-shell $SHELL

  # copy and paster set-option -g default-command
  "reattach-to-user-namespace -l zsh"

  # look good set -g default-terminal "screen-256color"

  # act like GNU screen unbind C-b set -g prefix C-a

  # a mouse set -g mode-mouse on setw -g mouse-select-window on setw -g
  mouse-select-pane on

  # act like vim setw -g mode-keys vi bind h select-pane -L bind
  j select-pane -D bind k select-pane -U bind l select-pane -R bind-key -r
  C-h select-window -t :- bind-key -r C-l select-window -t :+ unbind [ bind
  ` copy-mode unbind p bind p paste-buffer bind -t vi-copy v begin-selection
  bind -t vi-copy y copy-selection

  # after copying to a tmux buffer, hit y again to copy to clipboard bind
  y run "tmux save-buffer - | reattach-to-user-namespace pbcopy"

A great article about setting up the “Text Triumvrate” can be had at drbunsen.org. I highly recommend reading it.

Syncing it all with Dropbox Now, we’ve spent a bit of time creating all

of these configuration files. Wouldn’t it be nice if we never have to do that again? Yes. Use Dropbox.

We can symlink every configuration file from Dropbox, stashed in a hidden folder. Move all that junk, and begin symlinking it to your home directory.

  $ ln -s ~/Dropbox/.dotfiles/.vimrc.after

We can even put things like .ssh keys in there, and never fear that we’ll lose something. Only that Dropbox will go bad, like Facebook, and try to ssh into all of our shit, the better to be able to direct market to the masses.

I can’t wait ‘till Facebook dies.

A Jekyll Site. Because.

2012-08-04T00:00:00+00:00

Why? Well, because of an article recently published by Development Seed. And because I’m easily impressed. It’s a very thought provoking article. Here’s a link –> CMS Free Websites.

I’ve decided I’ll give Jekyll a whirl, and thus far, I’m mostly impressed. It’s perfectly suited to a blog like this.

The markup is extremely easy to manipulate; Source looks nice, because it’s exactly what I created, instead of markup generated at runtime by a complex templating system. For me, that means way fewer collisions. No heavy lifting to theme a site that doesn’t need the awesome feature set of an application framework like Drupal. Instead, I can focus on that which most interests me; Front end development and design.

The fact that Jekyll doesn’t rely on a database also means that I’m free to quickly move it anywhere I like. There is, essentially, no migration process. Peace of mind for me, as I’m frequently indecisive about hosting.

Working within the limits of Jekyll means finding services that, independently, fulfill the need for a particular feature. This atomized approach means that site features can be migrated to new sites or content management systems, revised over and over again, or discarded entirely; All individually, all independently. Very fucking cool. It’s like website legos.

For thedrearlight.com, I’m using:

Disqus for comments
Tapir for search
Flickr for image hosting
Feedburner for rss
Github Pages for http

I really like the idea of a web driven by well crafted services that are then cobbled together into a public facing site. If websites are, at core, about identity, this strategy makes a lot of sense. Websites become the aggregate one’s prescence on the web, a domain for cohesion. This, I think, is what most resonated with me while reading Development Seed’s article.

Ultimately, this new/old-school approach to web building will allow me to experiment more freely with CSS and Javascript here. I might even be able to shed some of the anxiety I’ve developed while trying to always use the most contemporary solution. If Drupal falls by the wayside (which it won’t), I can rest easy, content that this .html solution is already out of fashion.

Here’s a photo:

Mountain Lion and the AMP Stack

2012-07-30T00:00:00+00:00

This time around, I’m not going near MAMP with any sized pole whatever. It works for what it’s meant to do. Sometimes. I’ve, like, straight-up wept, though, because of MAMP. Rather than subject oneself to that kind of penance, a super solid development environment can be had if you’re willing to do just a little bit more than flip a switch. The bit of extra work put into creating a custom AMP stack will make your heart break less and less. It’ll also mean you understand a bit more of what’s actually happening behind the scenes.

Apache - So, do that. Like this.

Mountain Lion comes with Apache, and we won’t replace it. What we will need to do, however, is turn it on.

As Apple makes their flagship OS more and more consumer focused, they continue to remove little things that confuddle the non-developer. One of these things is the “Web Sharing” checkbox in the system preference settings. We have to use a (gasp), terminal emulator to enable it now. So much better.

Open up the terminal emulator that comes stock with OSX. It’s called terminal.

At the prompt, enter the following:

  $ sudo apachectl start

Voi-FREAKIN-la. Apache is on.

Now we’ll want to configure a .conf file that allows us to develop using virtual hosts. This is as easy as easy pie by creating two additional .conf files for custom settings.

Using the terminal, navigate to /etc/apache2/users. Now, create a file called yourname.conf:

  $ cd /etc/apache2/users
  $ touch yourname.conf

This .conf file will be used to trick out our Apache install a bit, amending a few new directives to it. Once the file has been created, open it with your favorite editor. I recommend vim. Stop being a baby:

  $ vim yourname.conf

Add the following lines to yourname.conf, changing “yourname” to be your username:

  <Directory "/Users/yourname/Sites/">
    Options Indexes MultiViews
    AllowOverride All
    Order allow,deny
    Allow from all
  </Directory>

  Include /Users/yourname/Sites/httpd-vhosts.conf

Next, create a folder called Sites at ~/Sites (~ means your root directory. So, yourname/). Inside, create a file called httpd-vhosts.conf.

A bit of explanation; the reason I’ve seperated the files yourname.conf and httpd-vhosts.conf, instead of consolidating them into a single file, is that I like to keep a vhosts.conf in the root of my localhost. It’s easy to get to, and I edit it all the time. Do whatever you want. Make three. That’s the nice thing about setting things up yourself.

Finally, add the following to httpd-vhosts.conf:

  NameVirtualHost *:80
  <Directory "/Users/yourname/Sites">
    Options Indexes FollowSymLinks MultiViews
    AllowOverride All
    Order allow,deny
    Allow from all
  </Directory>

  <VirtualHost _default_:80>
    ServerName localhost
    DocumentRoot /Library/WebServer/Documents
  </VirtualHost>

  <VirtualHost *:80>
    ServerName domain.local
    DocumentRoot "/Users/yourname/Sites/domain.local"
  </VirtualHost>

The template at the bottom of the file can be easily copy/pasted for at least a billion local sites.

When working with local sites, it’s always good to alias them with your hosts file. This is achieved by adding a new line to the bottom of /etc/hosts, like so:

  $ sudo vim /etc/hosts

  # Add this, once you’ve opened the file
  127.0.0.1 yourlocalsite.local

Now, restart apache:

  $ sudo apachectl graceful

PHP

Having given up on the dreary sorrow that is MAMP, we might easily use the system default PHP that comes with OSX. Or, we can get really fancy and use a brilliant one line terminal command to install the hotfire. By getting fancy, I mean stupid simple.

Via –> http://php-osx.liip.ch

  $ curl -s http://php-osx.liip.ch/install.sh | bash -s 5.3

This will install PHP 5.3 into /usr/local, so we can ruin it without a care. Also, it comes preconfigured to be awesome. It’ll work with Symfony, XDebug, etc… Read up a bit on php-osx if you’d like to take it further. For instance, it’s easy to extend php.ini with additional .ini files. Again, for the sake of organization.

Now, we need to tell Apache to use this fresh version of PHP. Easy. Navigate back to yourname.conf, and add a single line to it:

  Include /etc/apache2/other/+php-osx.conf

We can also ensure that we’re using this version of PHP from the command line. Add the following to .bash_profile or .zshrc:

  PATH=/usr/local/php5/bin:$PATH

Next, reload your .bash_profile:

  $ source .bash_profile

MySQL

Now, we’ve got the AP, and we need the M. We’ll install MySQL with homebrew. I’ve written a post already that contains instructions on how to install homebrew –> Symfony and MAMP; A Love Story

  $ brew install mysql
  $ mysql.server start

Start mysql with mysql.server start. Now, install MySQL’s system tables:

  $ mysql_install_db --verbose --user=`whoami` --basedir="$(brew --prefix mysql)" --datadir=/usr/local/var/mysql --tmpdir=/tmp

Be sure to read the output of the above, as you’ve got a few options for creating a root user and password. Also, copy a mysql.cnf to /etc/. This will allow you to adjust your development MySQL settings.

  $ cp /usr/local/Cellar/mysql/your_mysql_version/support-files/my-small.cnf /etc/my.cnf

You’ve got a fresh AMP stack now, and sans MAMP. Rejoice.

Symfony and MAMP

2012-03-23T00:00:00+00:00

One topic that seemed to be on many a person’s lips was Dries Buytaert’s announcment that Drupal core will be leaning on Symfony2 for, well, something.

It’s not completely clear to me yet what that something is, though Symfony’s founder, Fabien Potencier, described this holy union at a session during Drupalcon. If you’d like to watch it, here’s a linky —> http://blip.tv/drupalcondenver/drupal-8-meets-symfony2-6039079

As a Drupal developer, this is a rather uncomfortable revelation. In the same breath, it’s an awesome revelation. I’ve been itching to learn more about object oriented php for some time; The ecosystem is rife with php frameworks, and wading through them all is daunting. The decision about which framework to learn just got a lot more simple.

I’ve started fooling around with Symfony2 on my local server. Which happens to be a MAMP server. And it’s not a painless process. I thought I’d describe the steps I’ve gone through to get a working install of Symfony2 under MAMP.

Step 1 - Install php with Hombrew

Now, something interesting about php frameworks is that they rely heavily on cli interactivity to ease the creation of multiple files. You know, that MVC stuff. Not only does MAMP’s php need to meet the requirements for Symfony2, OS X needs an appropriately configured build of php. Let’s knock that out.

I’ve never really liked messing around with the programs that are pre-installed on OS X. I’d rather leave the system more or less pristine, and build myself a nice little sandbox where I can do anything with minimal fear that my computer will explode. Enter Homebrew. Homebrew is a nice little package manager that allows me to install packages like git, ruby, etc… without fear of configuring them and inadvertenly nuking them. Homebrew can be found at –> http://mxcl.github.com/homebrew

Install it. Shit is tight.

Once you’ve got Hombrew installed, open a command prompt(terminal). Type “brew install php” into the prompt… And be disappointed. Turns out php isn’t in the default Homebrew repo. But! As luck has it, there is an alternate repository for brewing php related stuff, and it’s very easy to grab.

Follow the instructions at –> http://github.com/josegonzalez/homebrew-php. Now you’ve got a whole bunch of brew formulas for php. You’ll need to point brew directly at the package you’d like to install, instead of simply typing “brew install php”. You’ll end up typing something like:

  $ brew install /usr/local/LibraryPHP/Formula/php.rb

Now you’ve got a copy of php to use and mess with, absent of any fear that you might mess up the copy of php that came with OS X. Check that this fresh php install is the php you’re using with your cli by typing “which php” into command prompt.

Terminal should kick back /usr/local/bin/php. If it doesn’t, that’s because of some secret magic that’s happening with your $PATH, and your cli is still finding OS X’s php before it’s finding yours. This is easily fixed with .bash_profile, by basically letting your brew installed packages cut to the front of the line.

Add the following lines to your .bash_profile. If you don’t have a .bash_profile in your home directory, make one:

  # Put /usr/local/{sbin,bin} first
  PATH=/usr/local/bin:/usr/local/sbin:$PATH

For more on installing php with Homebrew, check out -> http://notfornoone.com/2010/07/install-php53-homebrew-snow-leopard

Step 2 - Install intl-php

Now that you’ve got a nice install of php to wreck, type brew install /usr/local/LibraryPHP/Formula/intl-php.rbg into command prompt. intl-php is a library that Symfony2 requires to work correctly. The install takes a little while, so go smoke a cigarette or partake of some similar vice.

Once intl-php is installed, type:

  $ cd /usr/local/Cellar/intl-php/5.3.10/g
  $ open .

You’ll now have a Finder window open, and you’ll see a file called intl.so. Copy that file. You’re going to add the intl.so extension to MAMP’s version of php. Whoosh.

MAMP seems to be undecided as to where things belong. So, find where your copy of MAMP keeps php. My copy of MAMP keeps php at /Applications/MAMP/bin/php/php5.3.6g. You can use Finder to navigate here, or just type:

  $ cd /Applications/MAMP/bin/php/php5.3.6 
  $ open .

You’ll want to add intl.so to php’s extensions directory. Mine is at /Applications/MAMP/bin/php/php5.3.6/lib/php/extensions/no-debug-non-zts-20090626g. Paste intl.so here.

Step 3 - Edit php.ini

Okay. Now you’re almost there. You need to edit some php.ini files. php.ini is a file that instructs php how it oughta behave and which modules it should load, amongst other mystical things. You’ll need to edit MAMP’s php.ini, as well as the php.ini that belongs to your Homebrew installed php.

MAMP’s php.ini lives at /Applications/MAMP/bin/php/php5.3.6/confg. Before you edit it, make a backup copy. If you’re not already in the habit of making .bak files of things that you’re not sure what they do, get in that habit. Right now.

Once you’ve got a backup of php.ini, you’ll need to make some edits to the one that php will be using. Find the line that says short_open_tag = Ong and change it to read short_open_tag = Off.

Next, look for the line that reads magic_quotes_sybase = Offg. Below it, add a line that reads magic_quotes_gpc = Off.

Finally, find the “extesions” portion of your php.ini, and add a line that reads extension = intl.sog.

Alright, that’s it. Restart MAMP, and start a new terminal session. You’re ready to install Symfony

Another great article for getting an environment ready for Symfony2 is at –> http://thewebfactory.wordpress.com/2011/10/21/setting-up-symfony-2-on-mac-os-x-lion-with-mamp-2-0

Step 4 - Download Symfony2

Now that OS X is warmed up, let’s get crackin’ on a Symfony2 environment. You can grab a Symfony2 package at –> http://symfony.com/download.

I use git heavily, and the project page suggests that, if you use git, one should download the “without vendors” package.

If you opt to use the Symfony2 package that doesn’t include vendor libraries, you’ll need to fetch the “Vendors” directory in order for Symfony2 to work. In a command prompt:

  $ cd to/your/Symfony/directory
  $ php bin/vendors install

If you’ve added your Symfony directory to OS X’s hosts file and MAMP’s httpd.conf, you’re ready to start working through the Symfony2 tutorials at –> [http://symfony.com/doc/current/book/index.html(http://symfony.com/doc/current/book/index.html)

PS - Drush & Stuff

If you’re really fancy, and using drush (you should be), then you’ll be disappointed to know that installing php with Homebrew seems to upset drush. After following the above steps, drush will begin to throw errors. It’s easily fixed, though. All you need to do is make some changes to your Drupal settings.php. In your setup, where it says “localhost”, change this to read “128.0.0.1”.

Garrett Dawson | thedrearlight

Dependency injection ez-mode

Writing JavaScript modules consumable as esm or cjs

webpack or rollup

Goals

Extensible configuration

Omit dependencies

Build it.

Communicate module options

Real life

GAMECHANGOR: tmux leader + ctrl-z WTF

Webpack/Babel vs. npm link

Note To Self - Ubuntu Color Scheme

GPG, Smartcards and SSH

Installing Stuff

Configuring Stuff

Generating Keys

Publish Public Keys

Set Up Yubikey

Hell Is scdaemon

Move Your Secret Subkeys

SSH

A slideshow about loops

But what does it do… Closure.

Uh, what do closures do…

The Module Pattern

A Slideshow about Functional Programming and Javascript

Vim is better

Longevity + Ubiquity = Reliability

Open Source

Mode based editing

Operators

Motions

Text Objects

Learning Vim

Adding JS libraries to a Drupal project with Libraries API

Quick overview:

Install Libraries API

Add the library to sites/all/libraries

Create a very short custom module that tells Libraries API about the library

Add the library to the page where it‘s needed

Use it!

JavaScript Hyperspace

On Require JS and JavaScript Architecture in Drupal

JavaScript Architecture in Drupal - Moving Forward

Onward, to RequireJS

Content panes fit so good into Panels that it is really silly

WHOAWHOA, a Tmux trick.

Et voilà

Tmux and Vim, get marrieder. Or, Tmuxination.

Tmuxinator

Using Compass and Sass for Drupal Projects

Creating a Ruby environment with rbenv

Installing Compass and Sass

Pull it all together, and build a Drupal theme

Tmux and Vim, get married.

Vim & MacVim First, one must install MacVim. Duh. With homebrew. Duher.

Janus Now, as anyone who’s ever opened Vim can tell you, it’s terrible

More Plugins!!! Janus is extremely easy to extend with additional plugins

iTerm2 Now, we can do all sorts of fanciful things. I recommend dropping

zsh/oh-my-zsh Bash has been a good friend. However,

Tmux The cherry on top; Install Tmux.

Syncing it all with Dropbox Now, we’ve spent a bit of time creating all

A Jekyll Site. Because.

Mountain Lion and the AMP Stack

Apache - So, do that. Like this.

PHP

MySQL

Symfony and MAMP

Step 1 - Install php with Hombrew

Step 2 - Install intl-php

Step 3 - Edit php.ini

Step 4 - Download Symfony2

PS - Drush & Stuff

`webpack` or `rollup`