This one is for the IT boys in the dark basements. Love y’all :)

The problem

The results when using df and the sum of du are not the same. Example:

'Hey! I'm getting a 100% disk usage from df but I know I have free space, I've just rm-ed 10GB worth of files.'

The (probable) cause

The df results sync with the actual usage of hd space from time to time. Also, you might have processes that have that file still opened for some reason, even if it’s deleted. Most probably those processes are dead, undead, zombies, infected or whatever you might want to call them. I’ll call them ‘roamers’.

When the computer is rebooted, the roamers are killed along with any other process in the system, and the deleted files are finally purged, but let’s say you can’t afford to reboot the machine, i. e.: you’re working on a server.

What would Grimes do?

Use this command:

lsof +L1

It lists the opened files, and the +L1 filter will leave only those which are being used by just 0 or 1 processes. You might also want to add some grep magic to be sure that you are working only with files that are marked for deletion.

$lsof +L1 | grep "deleted"

COMMAND PID  USER    FD  TYPE DEVICE SIZE/OFF NLINK NODE     NAME
roamer   38  rgrimes txt  REG  14,2    51288     0 58754819 /blah/meh (deleted)``

On the left you get the process name and pid, so the only thing left to do is to go all kill -9 on it’s arse. Be careful though, and kill processes only when you’re sure you won’t break anything else or you don’t have any other exits available.

This one is pretty simple too, and very easy. Specify the version of the gems you are using in the Gemfile. Or in your environment.rb if you are into Rails Archaelogism. Wait, SPECIALLY if you’re dealing (or know that someone will) with old projects.

Let’s say you start developing a project and you want to use a gem.

  gem "capistrano-tasks" # shameless plug LOL

At that time, you’ll probably just go with whichever version rubygems throws at you. That’s ok. But when you deploy into staging for the first time, make sure to note down the version of the gem that’s being used in the staging machine and specify that version in the Gemfile.

    gem "capistrano-tasks", "~> 0.1.0" # shameless plug LOL

You’ll make your life a little easier when going into production for the first time because you’ll be using the same gem version (and dependencies), and A LOT easier for the next guy in line trying to get the project up and running.

Be a good guy and just try to think a little in advance and be nice to the future devs, or your future self. Anyway, it seems that you’re going to need to do this in Rails 4.

I’ve put up a teeny little gem which compiles some Capistrano tasks I’ve developed and been using for a while. Just to learn how to compile a gem by myself and also how to create a cookbook.

It’s also the first time I make public some of my code, and well, it’s exciting. Forking, testing, comments, suggestions are of course welcome. I’m willing to listen to everything you might suggest, from changing names of symbols, using other commands, or even changing the license. That’s the point of releasing it into the wild :) Thanks in advance.

You can get the gem at github.com/jantequera/capistrano-tasks. Where else?

I used this article (bit outdated, tho) by Tim Riley and the Webficient Capistrano Cookbook to learn the how-to. The second link provides a gem/cookbook much more suitable for production use, if you’re looking for one. I consider my gem for personal use and learning.

This one is simple, you might as well tattoo it all over your face, because it’s very likely you’re not doing it:

Keep your seeds.rb information up-to-date with your data model, for Pete's sake.

Make the next guy to work in that project’s life easier by not having him editing the seeds.rb file as he spends like two hours invoking rake tasks to setup database and getting fugly errors in the terminal one after another.

Be the good guy. You don’t know when you’re getting to continue other’s work in a project, and you that b-word they say about karma.

After updating Rails to 2.3.15 in a Rails 2.3 app, I found that some AJAX requests were suddenly not only not working properly, but they also were a bit tricky to debug, as they error caused the logged user to be kicked out the app.

The strangest thing was the server log claiming that my current_user was not present after the AJAX call. I needed the current_user to get to get to do the request, so it WAS there in the beginning, but in the response, the current_user ceased to exist, so… what was happening?

Well, it turned out to be that Devise (a way old version of the gem, by the way) was kicking the user out due to the impossibility of checking the CSRF token properly, because it was not being encoded and sent in the AJAX request in the first place.

Solving this is easy, and it is something that should have been done from the start. Working with ‘inherited’ legacy apps sometimes brings this sort of problems in the long run.

1. Add the csrf_meta_tag line in the header section of your application layout.
2. Modify your javascript AJAX requests so they send the AUTH_TOKEN encoded along with the rest of the data.

Here are some StackOverflow questions that helped me figure out what was happening and how to solve it: one, two, and three.