William Roe’s blog

A variety of geekery

Tmux & Autoenv Tip

On OS X, if I use tmux (or more usually, wemux for pairing) then I end up with oddly named windows like this:

This is because I’ve followed the awesome instructions from Dr Bunsen’s Text Triumvirate and in order to have the tmux and system (OS X) clipboards interacting, it requires a hack called reattach-to-user-namespace which proxies the running of zsh in tmux.

One quick way to get around this and save time renaming my tmux windows, was to use autoenv and add a file named .env to projects with content similar to:

tmux rename-window "project-name"

This is piling hacks on top of hacks, but at least it saves a bit of time for frequently visited directories.

A Silver Searcher Gotcha

There is a gotcha with the silver searcher and how it treats .gitignore files. The following pattern will work as expected with git:


I.e. git will ignore everything in that directory, however The Silver Searcher doesn’t understand that and it’ll still show matching lines from files in log/. For git and ag (The Silver Searcher) to both ignore that directory and its contents, change /log to log.

Ember transitionToRoute With New Model Hack

A common pattern with webapps in these exciting times is the transition-to-new-thing-you-just-created pattern. The way it works is this: you fill in a form to create a new thing (like, a widget or something) and then when you hit ‘save’, you are transitioned to the page for that widget. This is so you can confirm that it worked and so you could make further changes on that widget. The assumption being, when you create a widget, it is the focus of your task.

Whatever, anyway, I had to make something along those lines in an EmberJS app at work and hit an ember-data bug. Surprise!

The bug is that when you try to do this (code speaks louder than widget metaphors):

var model = App.Widget.createRecord({name: "special_widget"});
model.one('didCreate', function() {
  this.transitionToRoute('widgets.show', model);

This doesn’t work with ember-data currently - what happens is the model object that gets sent to the didCreate callback there won’t have an id from the server (it hasn’t been filled in for some reason).

To work around this issue, you need to do something akin to this:

saveTheWidget: function() {
  var model = App.Widget.createRecord({name: "very_special_widget"});
  model.addObserver('id', this, this.showWidget);
showWidget: function(model) {
  model.removeObserver('id', this, this.showWidget);
  this.transitionToRoute('widgets.show', model);

In that example we trigger the page transition off the change of value of id. This works because for a short while, the id will be null until Ember-data fills in the new id from the server. Then your callback is called and the page transition happens. The difference in timing is not noticeable to the user - it’s just a race condition within Ember-data itself. Other than that - in this example, the observer is removed, which is good practice for observers and you should always remove observers you’ve added (as I understand it).

Other alternative workarounds include wrapping the transitionToRoute call in a setTimeout() block - to make it pause just long enough for the model’s id to be filled in.

Most of the above came from Stackoverflow and the bug report and workaround on ember-data.