Blog – ShiftEleven

I am a vim user.  The thing I like about vim is it’s speed, how universal it is, and it’s customizations.  These customizations can come in the form of plugins, syntax files, compilers, and code completion utilities; all of which are scripts.  Scripts can be a single file like MiniBufExplorer or can encompass multple files like vjde.

Single file scripts are fairly easy to manage.  If you notice a new version of your script is released, then simply replace your file with the new version.  Likewise, it’s very easy to remove the script if you want to just try it out.  However, scripts spanning multiple files are much harder to manage.  For one, the script’s files get merged in with all of your other script files.

To help know what files are apart of what plugin, I manage my vim scripts in git.  Another way to keep track of things is to use a vimball.

What Are Vimballs?

Vimballs are essential vim script installers.  Each vimball contains all of the files that are needed for the script to work.  Not only that, but it also has a hook for you to easily uninstall the script as well.

Tail Bundle is a script that mimics tail -f for vim.  The downloadable artifact is a vba file.  That file is the vimball.  To actually install the file:

1. vim tail-03.vba
2. :so %
3. :q

So what that all means is that you’re opening the vimball in vim.  From there, you’re executing the instructions that are in the file.  Lastly, you’re just quitting.  You see, a vimball is a vim script in of itself.  So executing it writes everything out to where it’s supposed to go.

While the tail bundle makes use of the vimball, not every script does.  Luckily, it’s easy to make vimballs out of most script downloads.
Read the rest of this entry »

This is a fairly simple little tidbit, but still useful. Sometimes I want to have a script for my rails application, like running some reports on the data. There are two basic ways to do this: write a task(rake), or create a new ruby script file, like in the scripts directory.

If you want to do the latter, then there are two lines you my want to put at the top of your script.

ENV['RAILS_ENV'] = ARGV.first || ENV['RAILS_ENV'] || 'development'
require File.expand_path(File.dirname(__FILE__) + "/../config/environment")

The first line allows us to supply which environment we would like to run the script in. Say the script is called process.rb, we could call the script like ./process.rb production and now the environment is set to production.

The second line loads the environment file. Now all of rails, your models, libraries, and plugins are available to you.