Recently Simon Hørup Eskildsen posted a tweet or two about his new hostfile setup. The tweets were following by him posting his hosts-file as a gist. At work Jesper Rasmussen took the idea and solved it a bit smarter - so that you can have your pie and eat it too. (You can have host-file mappings, without the need to maintain them in two files).

The solution is quite simple. You have your regular hosts file, containing the usual mapping of domains to (quite possibly) localhost. Then you have one hosts file containing all the remapping of services, that you need to abstain yourself from using. Two small scripts either copy the original hosts file, and concats the focus files to them, or just symlinks the original hosts file. This way, any changes to the hosts file is always included.

Usually when I code, I use only terminal tools. This usually means that each project has its own tmux-session and that I use vim as my editor there. I manage my projects with tmuxinator, and have previously blogged about how I use little mapping in zsh to get autocomletion for projects.

The only problem with this setup, is that I very often start new small projects, and I never create the tmuxinator configuration first. This means that I open a new tmux session manually, and change the title, and manually add windows as needed. At some point though, if the project is a keeper, I would like the setup in tmuxinator as well.

Turns out, this is not easy. In an ideal world, I just want each window created with current dir, and a command. However you cannot (or rather, I cannot) get the current dir for each window. You can get the initial directory of the session, thats it. And you can get the window names, and a initial command of each pane. However since all my windows are created manually, all initial commands are just zsh, not very helpful.

I decided to write a little tool to do most of the work.

This tool will take a tmux session, and save it as a yaml file in tmuxinators configration directory - and include all windows. I then manually have to make sure all directories are correct, and that the correct initial command is correct for each window. But it’s still better than doing it all from scratch.

There has been many many changes to my dotfiles repo today. Most of the updates has been related to my vim settings and plugins.

I have installed a couple of new plugins:

UltiSnips

I hated SnipMate. I hated it so much, that I never used it (on purpose anyway). But since it was installed, sometimes a snippet expanded when I did not want it. I hated it!

UltiSnips is the answer to my snippet prayers in vim. The provided default snippets are good, and it has been made easy to make new snippets. Just call the method UltiSnipsEdit and it opens a snippet file mathcing the filetype of your current file, and then (of course) there is a snippet (called snip) to create a new snippet.

One very nice thing with UltiSnips is that you can define a snippet to only be used in the beginning of a line, and thus let the normal autocomplete take over on the rest of the line. (I find this very useful)

EasyMotion

Sometimes navigating with motions in vim is a bit complex. Easymotion helps with that. With easymotion you can do a more advanced version of a simple motion. If you do a simple motion (w,b,f,t and so forth) prefixed with Leader Leader - you will get up to 26 marks that you can jump to. Check out the github page for a better explanation - or even better, try the plugin out.

Ruby Refactoring

I have seen several of Gary Bernhardts screencasts at http://www.destroyallsoftware.com the last couple of days. And one of the things I kept thinking he did very very fast in vim was a refactoring where he did inlining of a temporary variable. I found - what I think - he uses for that. And I love the mappings. Take a look here.

Command-T

I have had command-t installed once before - but never knew how much I was missing out, before I saw (yet again) Gary use it in a screencast, where he had several mappings for it, that made the plugin prefilter the output for a given path. Now it was suddenly much much more useful. Take a look at the screencast here, and see the mappings he has published here.

And I have removed a git plugin (had two installed, and Fugitive seems superior).

At Arnsbo Media we write more and more backbone based frontend applications for various parts of our business. Lately we (or at least I) have become more and more obsessed with test driven development, and we have a need for doing even more testing of our frontend applications.

What to test

The biggest problem with people who take a deep dive into test driven development is, in my opinion, that they use too much effort on testing obvious working stuff, and to little on testing their brittle assumptions. In other words, they tend to test that a framework method does as documented, instead of focusing on your own code.

What not to test

In backbone, don’t test default operations of the classes. Dont test that if your set the url of a collection, and call fetch, that the url will get a GET-request. However if you override the url-function, or the fetch function - that should be tested. Don’t test that a model.set saves data, and that model.get can retrieve it again. However do test changes to the parse function. In the same vein do not test that a view contains this.el and this.collection when el and collection are sent through the constructor. But do test that your special rendering loop gets executed as you expect, and test that your events are triggered correctly when the view is attached to the dom, and that they are not tested when it is not attached.

How to test

We use jasmine.

One of my favourite books on Javascript Performance is High Performance JavaScript (Build Faster Web Application Interfaces) by Nicholas Zakas. The ideas in this post are influenced by that book. Read it!

When doing expensive operations in javascript, it can block the UI from rendering. The reason behind this is that all code in the browser runs in one thread, and as a result, only one thing can happen at a time. There are several ways to circumvent this - one could be using WebWorkers. Another way is to split the expensive task in to smaller chunks, and use setTimeout to ensure that the ui can be updated as well.

How much you should batch together, and how long you should wait between batches depends on your use case. Both the amount of work to be done, and how dynamic your UI is (e.g. eventhandlers and animations) will influence how you solve this problem.

In The Clean Coder: A Code of Conduct for Professional Programmers (Robert C. Martin Series) Uncle Bob writes about the importance of doing deliberate practice. One of his methods is to do a Code Kata in the beginning of the work day, and one at the end.

It happened again today. An awesome theme based on Bootstrap landed on hacker news.

The theme looked so nice, that I almost ended up buying the damn thing (for a measly $18) even though I have absolutely nothing use it for at the moment.

I while back I posted a couple of my zsh snippets for working with git. Today however I read about a post about how to keep your feature branch up to date. I liked the little snippet, however we do not always use the master branch as the basis for feature branches. And we do not always use origin as the name for our remote. And on top of that, we do not always merge from the main branch, sometimes we rebase it - so that our feature branch is placed on the head of the branch it was based on.

Last wednesday we held a meetup at AarhusJs and one of the talks were about the lessons the team behind Virtual Manager had learned while creating their new (yet to be released) football visualiser.

Their solution based on canvas, and I was intrigued. I have not looked into canvas (or any other browser based graphics/animation) in quite some while, and wondered how the state of were at the moment.

And I must say, a lot have changed in the last few years. To challenge my self to do something “real” with the canvas tag, I decided to take CreateJs for a spin. I quickly decided that the project should be very small, and that I would have to complete it in about an hour.

I am a bit weird with my editor choice. I use three different text/code editors. I usually use PhpStorm for large projects in PHP, since the more intelligent code completion is a time saver for large changes in PHP, when the codebase is 248753 lines of PHP code. But for everything else including minor bugfixes and features I use either Sublime Text 2 or vim.

When writing code in vim, I usually open a complete project in tmux and have a lot of panes, one with vim, one with a terminal, one watching changes (through either grunt or yeoman for instance), one logged in to the db, one starting a server, and perhaps several panes connected to the production environment via ssh.