Find and Open in VIM

Recently, Jamison Dance tweeted the following tweet

Apparently the answer to "How do I do global find and replace in Vim?" is "Use sed." #neckbeardnovember
— Jamison Dance (@jergason) November 5, 2012

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

for i in `find . -name \*.rb`; do echo $i; sed -i -e "/[:.]omc_data_service/ s/\([:.]\)omc_data_service/\1service/g" $i; done

view raw rename.sh hosted with ❤ by GitHub

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.

vim $(grep -lr --include=*.rb omc_data_service .)

view raw script.sh hosted with ❤ by GitHub

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.

grep -r --include=*.rb omc_data_service .

view raw step1.sh hosted with ❤ by GitHub

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:

http://tldp.org/LDP/Bash-Beginners-Guide/html/sect_03_04.html#sect_03_04_04

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...

	render: (discussion) ->
	# render stuff
	change: (discussion_id) ->
	@discussion_id = discussion_id
	# if the discussion has already been retrieved from the server (exists is local storage)
	# then directly render it
	if Discussion.exists(discussion_id)
	@render(Discussion.find(discussion_id))
	else
	# else bind to the refresh event, and just fetch that single discussion
	Discussion.bind('refresh', @_onDiscussionRefresh)
	Discussion.fetch(id: discussion_id)
	_onDiscussionRefresh: =>
	# when invoked, double check to ensure that the item you expect to be present
	# otherwise wait until it comes back.
	if Discussion.exists(@discussion_id)
	Discussion.unbind('refresh', @_render)
	@render(Discussion.find(@discussion_id))

view raw before-promises.coffee hosted with ❤ by GitHub

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 exist...so tonight, I cleaned it up with a promise and am really happy with the results

	{flatten} = require('lib/util_functions')
	promise = (model, ids...) ->
	ids = flatten(ids)
	promises = ids.map (id) ->
	ModelPromise.getPromise(model, id)
	return $.when.apply($, promises)
	class ModelPromise
	@getPromise: (model, id) ->
	(new @(model, id)).promise()
	constructor: (model, id) ->
	@model = model
	@id = id
	promise: ->
	@_promise ||= @deferred().promise()
	deferred: ->
	@_deferred ||= @_buildDeferred()
	_buildDeferred: ->
	deferred = $.Deferred()
	if @model.exists(@id)
	deferred.resolve()
	else
	@model.bind('refresh', @_resolve)
	@model.fetch(id: @id)
	return deferred
	_resolve: =>
	if @model.exists(@id)
	@deferred().resolve()
	exports.promise = promise
	exports.ModelPromise = ModelPromise

view raw model_promise.coffee hosted with ❤ by GitHub

	{promise} = require('model_promise')
	render: (discussion) ->
	# render stuff
	change: (discussion_id) ->
	@discussion_id = discussion_id
	$.when(promise(Discussion, discussion_id)).then =>
	@render(Discussion.find(discussion_id))
	# Multiple models needed - no worries
	change: (discussion_id, user_id1, user_id2) ->
	$.when(promise(Discussion, discussion_id), promise(User, user_id1, user_id2)).then =>
	# whatever you need, all models are ensured to be present

view raw after-promise.coffee hosted with ❤ by GitHub

Additional Reading/Resources:

• Promises/A - http://wiki.commonjs.org/wiki/Promises/A
• jQuery Deferred - http://api.jquery.com/category/deferred-object/

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

	(function() {
	// initial
	this.HouseApp = {
	Models: {},
	Controllers: {}
	};
	var House = HouseApp.Models.House = function(address) {
	this.address = address;
	this.doors = {};
	this.windows = {};
	};
	House.prototype.addDoor = function(door, location) {
	this.doors[location] = door;
	};
	House.prototype.addWindow = function(window, location) {
	this.windows[location] = window;
	};
	HouseApp.Models.Door = function(color) {
	this.color = color;
	};
	// private util used only here and scoped by the closure
	var convertSize = function(size) {
	return size * 2
	};
	HouseApp.Models.Window = function(size) {
	this.size = convertSize(size);
	};
	var HouseController = HouseApp.Controllers.HouseController = function(house) {
	//initializer
	this.house = house;
	};
	HouseController.prototype.render = function() {
	//rendering...
	};
	HouseController.prototype.save = function() {
	//save house
	};
	}).call(window);

view raw house-app.js hosted with ❤ by GitHub

	(function() {
	this.HouseApp = function() {
	var house = new window.HouseApp.Models.House;
	var aWindow = new window.HouseApp.Models.Window(52);
	var aDoor = new window.HouseApp.Models.Door(32);
	house.addDoor(aDoor);
	house.addWindow(aWindow);
	this.houseContoller = new window.HouseApp.Controllers.HouseController(house);
	};
	}).call(window);

view raw house-initializer.js hosted with ❤ by GitHub

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

	(function(/*! Stitch !*/) {
	if (!this.require) {
	var modules = {}, cache = {}, require = function(name, root) {
	var path = expand(root, name), indexPath = expand(path, './index'), module, fn;
	module = cache[path] || cache[indexPath]
	if (module) {
	return module;
	} else if (fn = modules[path] || modules[path = indexPath]) {
	module = {id: path, exports: {}};
	cache[path] = module.exports;
	fn(module.exports, function(name) {
	return require(name, dirname(path));
	}, module);
	return cache[path] = module.exports;
	} else {
	throw 'module ' + name + ' not found';
	}
	}, expand = function(root, name) {
	var results = [], parts, part;
	if (/^\.\.?(\/|$)/.test(name)) {
	parts = [root, name].join('/').split('/');
	} else {
	parts = name.split('/');
	}
	for (var i = 0, length = parts.length; i < length; i++) {
	part = parts[i];
	if (part == '..') {
	results.pop();
	} else if (part != '.' && part != '') {
	results.push(part);
	}
	}
	return results.join('/');
	}, dirname = function(path) {
	return path.split('/').slice(0, -1).join('/');
	};
	this.require = function(name) {
	return require(name, '');
	}
	this.require.define = function(bundle) {
	for (var key in bundle)
	modules[key] = bundle[key];
	};
	this.require.modules = modules;
	this.require.cache = cache;
	}
	return this.require.define;
	}).call(this)

view raw stitch-header.js hosted with ❤ by GitHub

	window.require.define("app/models/house": function(exports, require, module) {
	var House = function(address) {
	this.address = address;
	this.doors = {};
	this.windows = {};
	};
	House.prototype.addDoor = function(door, location) {
	this.doors[location] = door;
	};
	House.prototype.addWindow = function(window, location) {
	this.windows[location] = window;
	};
	module.exports = House;
	});

view raw app-models-house.js hosted with ❤ by GitHub

	window.require.define("app/models/door": function(exports, require, module) {
	var Door = function(color) {
	this.color = color;
	};
	module.exports = Door;
	});

view raw app-models-door.js hosted with ❤ by GitHub

	window.require.define("app/models/window": function(exports, require, module) {
	// private util used only here and scoped by the closure
	var convertSize = function(size) {
	return size * 2
	};
	var Window = function(size) {
	this.size = convertSize(size);
	};
	module.exports = Window;
	});

view raw app-models-window.js hosted with ❤ by GitHub

	window.require.define("app/controllers/house_controller": function(exports, require, module) {
	var HouseController = function(house) {
	//initializer
	this.house = house;
	};
	HouseController.prototype.render = function() {
	//rendering...
	};
	HouseController.prototype.save = function() {
	//save house
	};
	module.exports = HouseController;
	});

view raw app-controllers-house_controller.js hosted with ❤ by GitHub

	window.require.define("house_app": function(exports, require, module) {
	var Window = require("app/models/window");
	var Door = require("app/models/door");
	var House = require("app/models/house");
	var HouseController = require("app/controllers/home_controller");
	var HouseApp = function() {
	var house = new House;
	var aWindow = new Window(52);
	var aDoor = new Door(32);
	house.addDoor(aDoor);
	house.addWindow(aWindow);
	this.houseContoller = new HouseController(house);
	};
	module.exports = HouseApp
	});

view raw house_app.js hosted with ❤ by GitHub

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'); window.app = new HouseApp;"