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