giant robots smashing into other giant robots
Written by thoughtbot
Vim Splits - Move Faster and More Naturally
Most of us are Vim users and have tweaked our favorite editor for speed and convenience. See thoughtbot’s dotfiles.
One of my favorite tools is the window split. Here is a quick splits overview and configurations to use them more effectively.
The basics
Create a vertical split using :vsp and horizontal with :sp.
By default, they duplicate the current buffer. This command also takes a filename:
:vsp ~/.vimrc
You can specify the new split height by prefixing with a number:
:10sp ~/.zshrc
Close the split like you would close vim:
:q
Easier split navigations
We can use different key mappings for easy navigation between splits to save a
keystroke. So instead of ctrl-w then j, it’s just ctrl-j:
nnoremap <C-J> <C-W><C-J>
nnoremap <C-K> <C-W><C-K>
nnoremap <C-L> <C-W><C-L>
nnoremap <C-H> <C-W><C-H>
More natural split opening
Open new split panes to right and bottom, which feels more natural than Vim’s default:
set splitbelow
set splitright
Resizing splits
Vim’s defaults are useful for changing split shapes:
"Max out the height of the current split
ctrl + w _
"Max out the width of the current split
ctrl + w |
"Normalize all split sizes, which is very handy when resizing terminal
ctrl + w =
More split manipulation
"Swap top/bottom or left/right split
Ctrl+W R
"Break out current window into a new tabview
Ctrl+W T
"Close every window in the current tabview but the current one
Ctrl+W o
:help!
As with everything in Vim, for more information, check the well-written
helpfiles. In Vim, :help splits.
Vim Meetups
Come talk splits at a Vim Enthusiast Meetup near you:
Photo credit: Andrew Ressa on Flickr
Written by Adarsh Pandit.
Wrap existing text at 80 characters in vim
You have an existing block of text or code in vim. You want to re-format it to wrap to 80-characters.
:set textwidth=80
You might want this setting to apply automatically within certain file types like Markdown:
au BufRead,BufNewFile *.md setlocal textwidth=80
We have that setting in thoughtbot/dotfiles.
Select the lines of text you want to re-format:
v
Reformat it:
gq
Learn more:
:h gq
Written by Dan Croak.
Sort lines alphabetically in vim
Imagine you’re working in vim. You come across this code:
gem 'clearance', '1.0.0.rc4'
gem 'neat'
gem 'stripe'
gem 'pg'
gem 'thin'
gem 'rails', '3.2.11'
gem 'bourbon'
gem 'simple_form'
gem 'strong_parameters'
You want to sort the list alphabetically. You select the lines visually:
Shift + V
You invoke the sort function:
:sort
You rejoice:
gem 'bourbon'
gem 'clearance', '1.0.0.rc4'
gem 'neat'
gem 'pg'
gem 'rails', '3.2.11'
gem 'simple_form'
gem 'stripe'
gem 'strong_parameters'
gem 'thin'
You dig deeper:
:help sort
Written by Dan Croak.
Improving Rails boot time with Zeus
Zeus improves Rails boot time. Saving seconds is most important when running focused tests:
rspec spec/models/user_spec.rb
rspec spec/models/user_spec.rb:123
Those are times when a tight feedback loop make a meaningful difference.
Install
Install the Zeus gem on your machine:
gem install zeus
Do not include it in your Gemfile. It is an external piece of software.
Set up
Initialize:
zeus init
This will create two files in your Rails app’s directory. Ignore them globally in ~/.gitignore:
custom_plan.rb
zeus.json
Edit zeus.json to include only the tasks for which you’ll use Zeus. Mine looks like this:
{
"command": "ruby -rubygems -r./custom_plan -eZeus.go",
"plan": {
"boot": {
"default_bundle": {
"development_environment": {
"prerake": {"rake": []},
"console": ["c"],
"generate": ["g"]
},
"test_environment": {
"test_helper": {"test": ["rspec"]}
}
}
}
}
}
I remove cucumber in favor of RSpec and Capybara. I remove server in favor of Foreman and Pow.
Force the test environment
In spec/spec_helper.rb, change:
ENV['RAILS_ENV'] ||= 'test'
To:
ENV['RAILS_ENV'] = 'test'
Remove auto-running code
The goal is to run tests in the context of Zeus. So, remove other similar systems.
From the RSpec docs:
> Generally, life is simpler if you just use the rspec command. If you
> must use the ruby command, however, you’ll want to do the following:
require 'rspec/autorun'
> This tells RSpec to run your examples.
We don’t need this behavior and can cause bugs when used with Zeus.
Remove either of these lines in spec/spec_helper.rb if they exist:
require 'rspec/autorun'
require 'rspec/autotest'
Remove Spork and Guard
For the same reasons, if you’re using Spork and Guard, delete them from your Gemfile, delete your Guardfile, and delete any related Spork code in spec/spec_helper.rb or spec/support/.
Start Zeus
Zeus will need to be running before you can use its commands:
zeus start
I usually run this, and other long-running processes in a tmux session.
Now, those original commands will have the benefit of Rails boot time in under a second:
zeus rspec spec/models/user_spec.rb
zeus rspec spec/models/user_spec.rb:123
Bonus: run specs from vim
Many of us are running specs directly from vim. If you edit your ~/.vimrc to use Zeus like in this commit, you can run focused specs with:
t
Enjoy!
Written by Dan Croak.
Trail Map
> How do I learn Ruby on Rails? Vim? Test-Driven Development?
Someone asks us these questions weekly. We think we finally have good answers.
Extracting answers from apprentice.io
apprentice.io is a program designed around 1-to-1 mentor-to-apprentice relationships with a heavy emphasis on pair programming.
However, each apprentice additionally has extra time each week to study topics of their choice. They set goals with their mentors and are held accountable to reaching them by publicizing the goals in an internal wiki.
Example goals include:
- Read chapters 14 and 17 of The RSpec Book.
- Review and merge a pull request on an open source project.
- Write blog post about anonymizing data.
One curriculum does not fit all
We’ve been calling each apprentice’s wiki page their “trail map”.
To us, the “trail map” metaphor relates to hikers, bikers, and skiiers:
- start in different places
- want to go to different places
- often change direction mid-journey
Likewise, apprentices (and anyone learning a topic):
- have different past experiences
- have different learning styles
- change their goals mid-process
Announcement!
With 12 apprentices in the apprentice.io program, we’ve noticed common patterns in each apprentice’s trail map.
So, we’ve consolidated trails into a default trail map and we’re pleased to now announce its release under a Creative Commons Atribution license.
You’re free to use the trail map however you’d like, even commercial training.
Initial trails
The trails exist as a single git repository on Github named Trail Map:
We hope learners everywhere will fork these trails for their own learning purposes and submit improvements via pull requests.
Each trail has three sections:
- Critical learning
- Validation
- Ongoing reference
Critical learning
This section lists things like books or blog posts to read, screencasts to watch, code to read or write, and koans or tutorials to complete.
In each topic, we aren’t aiming for greatest depth, but rather the most efficient way for the learner to become productive.
For example: we suggest chapters, rather than entire books, to read.
Validation
This section lists simple tasks the learner should be able to perform during routine development. We’ve never liked quizzes or certifications, but some hueristic is useful for assessment. We think self-assessment is a simple, fast, and low-stress approach.
For example: we say you know everyday git when you can (among other things), “stage a file, create a commit, and push to a remote branch.”
Ongoing reference
This section lists things like man pages and API documentation which we’ll always reference regardless of experience. Many things are not worth memorizing.
For example, we suggest that a developer refers to man git-rebase during a
project.
What’s next
This is a work in progress. We plan to add and edit trails as new resources are released or people tell us better ways they’re learning a topic.
We’d love to get your feedback in the form of Github Issues.
Written by Dan Croak.
