Faster TDD feedback with tmux, tslime.vim, and turbux.vim(joshuadavey.com)
joshuadavey.com
Faster TDD feedback with tmux, tslime.vim, and turbux.vim
http://joshuadavey.com/post/15619414829/faster-tdd-feedback-with-tmux-tslime-vim-and
11 comments
I recommend anyone wishing to use something like this first try to implement it yourself first. It's remarkable how easy it is to script tmux and vim. If you have a split screen it's as simple as a vim mapping that executes !tmux send-keys -t right 'rspec %'
Not dissing the project - I would recommend then using a more battle-tested project (like maybe this one) if you find yourself needing something more generic and complicated.
Not dissing the project - I would recommend then using a more battle-tested project (like maybe this one) if you find yourself needing something more generic and complicated.
Thanks, Brice! I also recommend implementing it yourself first. After I did just that, I found myself wanting a little bit more smarts with my vim mapping. Since most of my work is in rails, and I use rails.vim, I was able leverage rails.vim's buffer detection for alternate files.
In essence, if I'm in a controller that has a corresponding spec or test, the mapping with run that spec. If there is no corresponding spec, it will run the most recent command again. I find this useful for outside-in development, where a change in a controller might make a cucumber scenario pass.
I would, however, add that the command you mention above would need to include C-m at the end to actually send the terminal a "newline" character, thereby running the command.
In any case, I appreciate your interest in the project, and your helpful example!
In essence, if I'm in a controller that has a corresponding spec or test, the mapping with run that spec. If there is no corresponding spec, it will run the most recent command again. I find this useful for outside-in development, where a change in a controller might make a cucumber scenario pass.
I would, however, add that the command you mention above would need to include C-m at the end to actually send the terminal a "newline" character, thereby running the command.
In any case, I appreciate your interest in the project, and your helpful example!
I would normally leave this as is, but adding the C-m at the end is non-trivial so I wanted to give a more proper example. You're right, it should be:
Definitely want to give a big +1, but it's really cool/useful to know what's going on under the hood.
!tmux send-keys -t right 'rspec %' C-m
Definitely want to give a big +1, but it's really cool/useful to know what's going on under the hood.
'A practice that is quickly gaining popularity in the Ruby community is isolating your business logic from your persistance logic and framework.'
Anyone have links/further reading for this?
Anyone have links/further reading for this?
Arguably the start of the big community push in that direction was Corey Haines' "Fast Rails Tests" talk, which is really just a clever way of presenting the separation of logic argument. See: http://arrrrcamp.be/videos/2011/corey-haines---fast-rails-te... (or google "fast rails tests corey haines" for other videos)
I would also recommend two of Steve Klabnik's articles: http://blog.steveklabnik.com/posts/2011-09-22-extracting-dom... and http://blog.steveklabnik.com/posts/2011-09-06-the-secret-to-...
Another excellent resource is Gary Bernhardt's "Destroy All Software" screencast series. They are well worth the $9/month pricetag. https://www.destroyallsoftware.com
Another excellent resource is Gary Bernhardt's "Destroy All Software" screencast series. They are well worth the $9/month pricetag. https://www.destroyallsoftware.com
Sounds like some sort of "Domain-Driven Design" (or DDD).
Pinboarded for future reading.
`tmux` is great, but am I the only one unable to use `$ vim --remote file.txt` accross panes in `tmux`?
`tmux` is great, but am I the only one unable to use `$ vim --remote file.txt` accross panes in `tmux`?
All in all, tmux is one of the greatest programs ever. Even when working locally, I prefer to work within a tmux session. I've got single-key pane-switching shortcuts. Along with the inability of native terminals to create a vertical split (AFAIK), this is a significant productivity enhancer.
1. Too aggressive buffering of pane output. runaway output on some panes (due to e.g. a bug in the program running in the window, not tmux) will really hose things up so bad that the only way to fix it is to disconnect the underlying ssh connection.
I'd like to be able to specify a maximum data rate on a per-client basis. If any client is backed up, freeze panes visible to that client.
2. The keep changing the pane switching key bindings with every new release. :| With 1.5, they've taken away the ability to rotate thru every pane in a window in order: i.e., no concept of a "next" window. Only left and right.
3. I wish they'd add the option to move to the "next clockwise pane" or "next counterclockwise pane". Maybe the new left-right infra might help with that.
Yeah, yeah, it's open source. I should probably go fix it myself instead of whining on a forum. Maybe I will one of these days. :)