A ‘kata’ is defined as a “system of individual training exercises for practitioners of karate and other martial arts”. Programming isn’t exactly martial arts, but as coders we can make use of our own form of kata.
A programming kata is a tool used to teach how to think the way a master thinks, to code as they code. It should be repeated, it should be memorized, and then it should be repeated again.
The Bowling Game Kata is a common one: testing and designing a bowling game from scratch. Let’s get started:
describeGamedoit'initializes a new game'doexpect(subject).tobe_an_instance_ofGameendend
When run it results in:
bowling.rb:1:in`<top (required)>': uninitialized constant Game (NameError)
Registers open up a world of possibilities in Vim. If you’re not using them, then you’re potentially limiting your Vim productivity.
For example, how many times has the following situation happened to you?
You want to copy a line of text so you:
Yank the line in question
Delete another line along the way
Attempt to put the original line, accidentally putting the deleted line
This was a major hurdle while switching from RubyMine to Vim full time. Luckily I had a much more experienced, handsome coworker (shoutouts to Tony) who revealed to me the awesome that are Vim registers.
To see them in action yourself, open Vim and type :reg
No, seriously, do it. I’ll wait.
Want to put the last line you yanked and NOT the last one you deleted?
Use the 0th register.
Cool right? Now, let’s go over another example.
Another fantastically useful feature of registers are named registers. This gives you the ability to store text under an alias for later use.
In this example I copy the final line to the ‘a’ register with:
and you then you can see it in the ‘a’ register!
This text can later be put with:
We’ve only scratched the surface on what’s possible with Vim registers. Use Vim and Vim Casts both have excellent tutorials for more information.
Vagrant is awesome. It kicks ass. It’s the cat’s pajamas. It allows you to modularize dependencies that are specific to your app. It makes my life better in nearly every conceivable way, and it even makes me a better lover.
But for all its pros, Vagrant is still a virtual machine and virtual machines are slow. But don’t fret, there are optimizations we can make to speed up your rails app within Vagrant.
Disable Log files
Rails likes to write stuff down. A lot. When I cracked open my own development.log file it had nearly half a million lines. That’s lots of wasted operations writing to a file. I’m going to share a dirty secret: I’ve never used the development log file for debugging. So let’s get rid of it.
Within config/development.rb add:
config.logger = ActiveSupport::Logger.new(nil)
Where ProjectName is the, well, name of your project.
This still provides output for the console and seems to work well with other logging gems.
Use The NFS
VirtualBox uses it’s own protocol to share files between the host and Vagrant by default. NFS, in most cases, will be much faster. Luckily switching over is dead simple. Fire up your favorite text editor and add the following to your Vagrantfile:
# Required, pick a local IP
config.vm.network :private_network, ip: '192.168.x.x'
config.vm.synced_folder '.', '/vagrant', nfs: true
Just one core please
More is not always… more. It has been proven severaltimes (okay, a couple times) that adding multiple cores actually reduces VirtualBox performance.
Once again edit your Vagrantfile to include the following line:
vb.customize ["modifyvm", :id, "--cpus", "1"]
There are definitely other tweaks out there that could increase performance, but the above have the biggest impact for me. The jury is still out on an optimal amount of RAM, but the consensus is somewhere between ¼ and ½ total system memory. I encourage experimentation.