Wednesday, November 7, 2012

Find and Open in VIM

Recently, Jamison Dance tweeted the following tweet

This tweet reminded me of one small painful item when using Vim - finding text across files and replacing said text with another value. Here is a classical example of doing this on the command line

That script searches all ruby files and replaces 'omc_data_service' with 'service' - that looks a lot more intimidating than what most text editors offer you doesn't it (you can read more about this script from my buddy Joe).

After you run the script above, you need to then review the code prior to committing to ensure the replacement worked properly and have your test suite confirm it. Also, that script can be time consuming to get right. I prefere to take a different approach.

With this approach, I am grepping across files for text and them opening all files with that text in Vim. Let's review how I build this command up each time I do something like this.

First, I start with simple grep command across a set of files using the `-r` option to search recursively, --`--include` to specify the file types to include and then, starting in my current directory.

After looking over my results from the command line quickly to help make sure I'm matching files I want correctly, I add the `-l` option to only include file names - this is a slight change up from the complicated way I used to do it, but like all unix tools - there are lots of chainsaws of different sizes.

After sanity checking the files, I wrap the command in `$()` and pass it to vim.

The `$()` is a shell expansion that takes all the file names as results and expands those as unique args to be passed into vim. Now you can use your normal vim commands to search and find replace in each file. After you are done with a file, use the command `:n` to skip to the next file.

PS. yes - I know I can grep from vim and skip across each reference, but when doing a find and replace, I prefer this method.

To read more about shell expansions, see the following reference:

Saturday, April 28, 2012

Just a Promise

Warning: Code Examples are in CoffeeScript

I have been working on a javascript application over the past couple of months built with the Spine.js framework and things have gone really well. We are holding onto data for a current session and some of the less volatile data is only fetched once during that session and only when it's needed.

For example, we have "Discussions" and "Users" and we only fetch these models once during a session and in the case of a Discussion, we only fetch a full discussion one at a time. Also, while we batch fetch Users, we cannot guarantee when we render a Discussion along with Users and their avatars that all of the users are present at rendering time. This caused quite a bit of code that looks like this...

Yeah that sucks having code that looks like that littered all across the application and it can get even worse if you need to ensure that multiple pieces of data already tonight, I cleaned it up with a promise and am really happy with the results

Additional Reading/Resources:

Modular Javascript

Complex javascript apps and eco systems are the common norm these days and with javascript packaging and caching solutions that encourage all of your javascript to be served up in a single payload. Moving towards this paradigm brings up some interesting issues about how to keep your javascript organized, lean and fast.

A common pattern observed in javascript writing is to wrap your javascript code in a closure to control scope and namespace your "objects" to prevent variables being overwritten.

File structure looks like...

  • /javascript
    • house-app.js
    • house-initializer.js

With this approach, there are a couple of problems.

  1. Javascript file load order becomes important - if script block (a) depends on something from script block (b), script block (b) must be ensured to load before (a). In a complex app/site - you can end up with hundreds of javascript objects and managing one large file can become burdensome. Also, if you break these into multiple files, circular dependencies can become an issue.
  2. All javascript in the closure will always always run when the files are loaded (when #call is executed).
  3. Global scope is still relied heavily on to attach all "objects" to be used.

To solve these problems I recommend using a module pattern in developing your javascript such as CommonJS or AMD. If you have used node.js, then you have used the CommonJS implementation and if you have used "require.js", then you have used the AMD implementation of the module pattern.

I like the permise of the AMD implementation which provides a convention to asynchronously load required javascript files from a server as this prevents the need to have a large payload initial sent to a page to get up and running (faster page load time) but this advantage becomes moot after someone has visited the page once (with caching). Also, creating a javascript "app" that can easily run in an offline mode becomes more challenging because you have to deal with multiple files in a cache manifest file, etc. However, require.js has a solution to this and provides a utility to create one javascript file but relies on node.js to work (potentially introduces an additional dependency into your development/deploy env) and introduces another step into your deploy if using another asset bundling solution (asset pipeline, jammit, etc).

The way I prefer to handle the module pattern implementation is based on the CommonJS spec and is based off a node.js package called "stitch". In using this solution, the only thing you have to worry about in load order is your initial library dependencies (stitch-header.js, jquery.js, backbone.js, etc) and then the rest of your javascript can be loaded in any order. This simplifies specifying your javascript includes for your packaging solution and ensures that javascript only gets executed when necessary.

Here is the example from above using the the CommonJS pattern.

File structure now looks like

  • /javascript
    • stitch-header.js
    • /app
      • house-app.js
      • /models
        • house.js
        • window.js
        • door.js
      • /controllers
        • house_controller

Then to use the above the house app in the particular page that needs the house app, put a small script block at the top of the page that reads, "var HouseApp = require('house_app'); = new HouseApp;"