December 06, 2008 @ 08:08 PM by nap · 9 comments
Back when I was a Java developer, I knew and really liked me some IntelliJ. Later, when I moved over to Ruby full time, NetBeans seemed like a damn good choice. After all, I was used to having a “proper” IDE, it had pretty nice Ruby support and also, much to my joy, it had a Vim plugin, which allowed me to use my favorite editor from my pre-IntelliJ days. Win.
Fast forward to about six months ago when I decided that I’d ceased to care about heavyweight IDEs. I just didn’t use enough of their features to make their overall (often cumbersome) weight and memory footprint worthwhile. So goodbye NetBeans with Vim plugin and hello Vim. MacVim, specifically.
Why Vim? Because Vim is universal. Because Vim is love.
Dave Thomas and Andy Hunt famously wrote “Choose an editor, know it thoroughly, and use it for all editing tasks” in their seminal masterpiece, The Pragmatic Programmer. I couldn’t agree more. There is no tool in a programmer’s toolbox more important than an editor, and the importance of knowing it inside and out cannot be understated. For me, ever since college, that editor has always been Vim. It was just everywhere that I needed it to be. It was ubiquitous. I could use Vim at home on my desktop, at school, at work in the campus NOC, at the CS lab, and in any number of remote shell sessions, on even the most obscure platforms. One ring to rule them all.
Vim is also small, and quick. Once you know what you’re doing, it’s quicker and easier to manipulate text in Vim than any other editor that I’m aware of. Of course, the learning curve is steep, relative to other editors. But it’s worth it. When I’m writing code, switching between files, replacing text, et al, I don’t want to have to use the mouse too frequently. Vim, in all of it’s keyboard-centric glory, delivers. MacVim also provides awesome mouse highlighting and menu option support, for the best of both worlds.
There’s also massive value in Vim’s powerful plugins system. Without some of these awesome third party extensions folks have developed for Vim, it wouldn’t be nearly as appealing as a desktop code editor. But by adding plugins like NERDTree, rails.vim, vcscommand.vim, and FuzzyFinder, it becomes a full-fledged programmers editor for me, something that easily outguns TextMate, NetBeans, Komodo, and all the other would-be competitors. Customize it to your hearts content.
Anyway, I just wanted to put that out there. Vim rules. And Tim Pope, author of rails.vim, rules too (even though he looks awful in drag). His plugin, along with NERDTree, vastly simplifies my day to day editing tasks, and reproduces all the functionality I would have actually used from a more fully-featured IDE. Thanks guys. You’re my heroes.
For more information on using Vim as a Ruby developer, see Jamis Buck’s post from a few months back about switching back to Vim from TextMate. It’s a well-written argument, but the really amazing thing about the article is the number of comments it generated. It’s great to see so much love for such a great editor and I’m glad to be in such good company.
So, what’s your favorite go-to editor? If it’s Vim, I’d be curious to know what plugins you’re using and how you’ve customized it.
PS If you’re also a MacVim user, make sure you install the :Bclose script too!
November 11, 2007 @ 11:02 AM by nap · 0 comments
Starting this blog entry to document any possible gotchas I experience on my upgrade to OS X 10.5. So far everything has been relatively clean. My only problem as of this writing has been with SSH and MacPorts. I have SSH installed via MacPorts and I noticed when doing any SVN+SSH operations, I was getting the following error:
percent_expand: NULL replacement
svn: Connection closed unexpectedly
Hmm, looks like Leopard is expanding some SSH environmental variable to NULL. An easy fix is to add the following line to your ~/.ssh/config:
IdentityFile ~/.ssh/id_rsa
This overrides the default search for your private key, and therefore you don’t get the percent_expand error. If anyone has more information about this particular issue, please let me know. Thanks!
November 10, 2007 @ 08:18 AM by nap · 1 comment
November 06, 2007 @ 04:46 PM by nap · 1 comment
If you ever need to drop a pid from a Ruby process it’s dead simple:
File.open('myapp.pid', 'w') { |f| f.write(Process.pid) }
Now you can use Monit to keep Sinatra alive, for instance ;-). Monit is great for monitoring UN*X processes and keeping them running under ideal conditions, and that means it’s great for Mongrel, and anything that runs through Mongrel. Monit can even check the memory consumption of your application and restart it if it seems to be leaking. Not that that ever happens, of course.
October 21, 2007 @ 08:50 PM by nap · 0 comments
Any post about Git pretty much mandates the use of some lame pun in the title, and this blog entry is no exception. For those of you who are as-of-yet unfamiliar with it, Git is a distributed version control system created by Linus Torvalds. It's been around and usable for about a year now, but I'd only been peripherally aware of it until recently.
In the past I've just used it to check out and occaisionally toy with the latest Rubinius sources but now that the Offtrac project is using it, it finally looks like I'm going to have to start familiarizing myself with it beyond installation and cloning a remote repository. If that sounds negative it isn't meant to be; I enjoy being forced to learn new things every once in a while. Srsly.
[To be honest I'm still relatively happy with Subversion, but hey, when I started using Subversion I was still at least relatively happy with CVS too. No wait, scratch that, I hated CVS.]
Anyway, for those of you out there like me who are just getting acquainted with Git and particularly those who are stumbling over the implications of the distributed part of distributed version control, Carl Worth has written a useful getting started guide that you should definitely check out. Of course there's the official user guide too.
In practice, normal usage really isn't as different as it seems, and the concept of a distributed repository is a truly powerful one. Everyone has commit access to their own local branch, which means most operations are fast, and the centralized who-gets-commit-rights question becomes a total non-issue. That's very very cool. Oh, and no .svn folders littered in every folder is another nicety. The jury's still out for me as of right now, which is to say I'm not rushing to switch all my existing Subversion projects over just yet. But I have to say, I'm very intrigued so far.
August 27, 2007 @ 09:17 AM by nap · 0 comments
So a few months back I started using nginx on my staging server, front-ending for Mongrel, and just recently I've stated migrating some production stuff over to it. It's pretty great as a lightweight Apache replacement. Incredibly simple syntax, very quick and close to the bone. Most of my production stuff still runs on Apache, but that may soon be changing. I also finally made the leap to Capistrano 2.0. Loving the new namespaced task hierarchy.
Anyway, here's a simple alternative maintenance page recipe for Capistrano's deploy:web:disable target and the corresponding Nginx config to make use of it. In case you're unfamiliar with it, the disable web task basically redirects all requests to a maintenance page until deploy:web:enable is run, which returns things to normal. This recipe assumes you've created your own (static) maintenance.html page in public/maintenance.html and that it makes use of existing stylesheets and images -- meaning that you don't want to rewrite those requests.
in config/deploy.rb:
namespace :deploy do
desc "Disable requests to the app, show maintenance page"
web.task :disable, :roles => :web do
run "cp #{current_path}/public/maintenance.html #{shared_path}/system/maintenance.html"
end
desc "Re-enable the web server by deleting any maintenance file"
web.task :enable, :roles => :web do
run "rm #{shared_path}/system/maintenance.html"
end
end
in nginx.conf (within your server block definition):
# allow requests for images, js, css, and icons to go through
# even if cap has been used to disable the site
if ($request_filename ~* /(images|javascripts|stylehseets)/) { break; }
if ($request_filename ~* .ico$) { break; }
# for cap's deploy:web:disable task
if (-f $document_root/system/maintenance.html) {
rewrite ^(.*)$ /system/maintenance.html last;
break;
}
January 15, 2007 @ 09:22 AM by nap · 0 comments
FreeBSD 6.2 was released this morning. Lots of bugfixes and new features, including official support for binary updates with freebsd-update. Cvsup away!