RVM hates my guts. And it doesn't matter, because I hate RVM back even more. Since I was technologically raised by aging wolfs, I have strong reasons to believe that you just shouldn't have mixed versions of software on your production systems, specially, if a lot of things are poorly tested, like most of Ruby libraries, aren't backward compatible. I was raised on a world where everything worked greatly because the good folks at projects like Debian or Perl have some of the greatest QA processes of all time, hands down. So, when someone introduces a thing like RVM which not only promotes having hundreds of different versions of the same software, both on development, testing and production environments, but also encourages poor quality looking back and looking forward, there isn't anything else but to lose faith in humanity.

But enough for ranting.

I had to deliver this side project that works with the Twitter API and the only requirement pretty much was that it had to be both run from the shell but also loaded as a class within a Ruby script. And so I did everything locally with my great local installation of Ruby 1.8.7. When it came the time to load on the testing/production server I found myself on a situation where pathetic RVM was installed. After spending hours trying to accommodate my changes to run properly with Ruby 1.9.2, I set up a cron job using crontab to run my shit every now and then. And the shit wasn't even running properly. Basically, my crontab line looked something like this:

*/30 * * * * cd /home/david/myproject && rake awesome_task

And that was failing, crontab was returning some crazy shit like "Ruby and/or RubyGems cannot find the rake gem". Seriously? Then I thought, well, maybe my environment needs to be loaded and whatever, so I made a bash script with something like this:

#!/bin/bash
cd /home/david/myproject
/full/path/to/rvm/bin/rake -f Rakefile awesome_task

And that was still failing with the same error. So after trying to find out how cron jobs and crontab load Bash source files, I took a look at how Debian starts its shell upon login. And while that didn't tell me that much that I didn't know, I went to look at the system-wide /etc/profile and found a gem, a wonderful directory /etc/profile.d/ where a single shitty file was sitting, smiling back at me, like waiting for me to find it out and swear on all problems in life: rvm.sh. /etc/profile is not being loaded when I just run /bin/bash by my crappy script, only when I log in, I should've known this. Doesn't RVM solve the issue of having system-wide installations so the user doesn't have to deal with, you know, anything outside of his own /home ?

So I had to go ahead and do:

#!/bin/bash
source /etc/profile
cd /home/david/myproject
/full/path/to/rvm/bin/rake -f Rakefile awesome_task

And hours later I was able to continue with work. Maybe this will help some poor bastard like myself on similar situation on the future.

Of course one can argue that I could've installed my own RVM and its Ruby versions, but why, oh why, if it was, apparently, already there. Why would I have to fiddle with the Ruby installations if all I want is get my shit done and head to City Bakery where I can spend that money I just earned on chocolate cookies? My work is pretty simple to run with pretty much any ancient version of Ruby, nothing fancy (unless you call MongoMapper fancy). RVM is a great project that doesn't solve an issue, but just hides some really fucked up shit on the Ruby community.

Last year, I had all the intention in the world to go to Bosnia and Herzegovina this summer to attend DebConf 11, but given my non-existent involvement on the project for the last couple of years, there's no reason for me to do it. Even last year when the event was held in town, I was not entirely thrilled about it. Life has changed quite a bit in the last few years, allowing me to just find and allocate my priorities on their right places.

I hope everybody attending have a great time and snap lots of photos for me to see and regret not being there.

This is something that is specified clearly on the Nginx manual, but it's nice to have it as a quick reference.

The access_log and error_log directives on Nginx are on separate modules (HTTP Log and Core modules respectively) and they don't behave the same way when all you want is to disable all logging on your server (in our case, we serve a gazillion static files and perform a lot of reverse proxying and we're not interested on tracking that). It's a common misconception that you can set error_log to off, because that's how you disable access_log (if you do that, the server will still log to the file $nginx_path/off). Instead, you have to set error_log to log to the always mighty black hole /dev/null using the highest level for logging (which triggers the fewest events), crit:

http {
  server {
    # ...
    access_log off;
    error_log /dev/null crit;
    # ...
  }
  #...
}

If you're the possessor of the blingest of bling-bling, you can disable all logging (not only for a server block), by putting error_log on the root of the configuration and access_log within your http block and make sure you don't override that on any of the inner blocks. And you're good to go.

I am a huge fan of LinkedIn, I love it. Handled properly, it can allow you to establish great opportunities that eventually lead up to either work or paid gigs and we all know how good money is, right? I have spent time for the last couple of weeks making sure my own LinkedIn profile is complete, fully up-to-date and that I'm taking full advantage of all the features that the site has to offer, and even though I'm not actively looking for a job it's always nice to get contacted by other developers or directors (heck, even recruiters) inviting you to consider other job opportunities. In my own personal space, it makes me more confident that I can still be of great value to other enterprises. It's like feeling you could date again, if you wanted to.

Last night, they announced that they had enabled GitHub as an application on users profiles. This is great for developers. I think that LinkedIn still needs to implement ways for users to track their not-so-formal activities and this is kind of a big step, to some extent.

For instance, I'd like to list some projects that I've worked with on which I wasn't fully employed with but hired me as a contractor for a few hours. They need to implement some sort of portfolio for the side business you perform.

After all, a LinkedIn profile is based on the professional work you do, not entirely on the commits you do into a forked or your never-ending project. There's still the question on how you can show off additional open source experience that is not in the form of commits on a GitHub repo, for instance, how to display the work you do on a project that doesn't have a Git repository, and use something else; or maybe the translation work you've done for years; or the documentation you've contributed here and there. But then again, if you're depending on LinkedIn to show off your open source expertise, you're probably not using the right tool. While I applaud the GitHub integration on LinkedIn, I do think it still lacks more work to cover more open source contributions which can take up to significant amounts of time on a developers expertise skills set.

Go add the GitHub application to your LinkedIn profile here.

If you use any non-retarded Web browser (aka not Internet Explorer) and usually run into and enjoy the huge inventory of videos that YouTube has to offer, please consider opting in to YouTube's HTML5 trial, which means that you'll be running HTML5 browser-based video instead of Flash for most of the website's videos. If you're also nerd enough, make sure to send them feedback and shit.

I like to read Planet Perl Iron Man, but since I'm less and less of a user of Google Reader these days, I prefer to follow interesting feeds on Twitter instead: I don't have to digest all of the content on my timeline, only when I'm in the mood to see what's going on out there. So, if you wanna follow the account, find it as @perlironman. If interested, you can also follow me. That is all.

I spent a couple of minutes today trying to understand how to make find (1) to execute two commands on the same target.

Instead of this or any similar crappy variants:

$ find . -type d -iname "*0" -mtime +60 -exec scp -r -P 1337 "{}" "meh.server.com:/mnt/1/backup/storage" && rm -rf "{}" \;

Try something like this:

$ find . -type d -iname "*0" -mtime +60 -exec scp -r -P 1337 "{}" "meh.server.com:/mnt/1/backup/storage" \; -exec rm -rf "{}" \;

Which is:

$ find . -exec command {} \; -exec other command {} \;

And you're good to go.

With Perl 5.12 released earlier this summer, the each function got a nice little addition that I'd like to talk about: It now has the ability to work on arrays, not only key-value pair hashes, but not exactly as you'd expect it (not like Ruby's each method).

The traditional way to work with each, using a hash:

my %h = (
a => 1,
b => 2,
c => 3,
);

while(my($key, $value) = each %h) {
say "index: $key => value: $value";
}

And the output. Of course, hashes being unordered lists, you won't get the nice little order of an array.

index: c => value: 3
index: a => value: 1
index: b => value: 2

Now, when you use an array, each will return the next pair on the list consisting on the index of that element's position and the position itself. Since it returns the next pair, you can iterate through it on the same fashion as when using a hash:

my @arr = ('a'..'z');

while(my($index, $value) = each @arr) {
say "index: $index => value: $value";
}

This is particularly useful to access direct named variables, both the index and the element, while looping through an array.

index: 0 => value: a
index: 1 => value: b
index: 2 => value: c
index: 3 => value: d
index: 4 => value: e
index: 5 => value: f
index: 6 => value: g
index: 7 => value: h
index: 8 => value: i
index: 9 => value: j
index: 10 => value: k
index: 11 => value: l
index: 12 => value: m
index: 13 => value: n
index: 14 => value: o
index: 15 => value: p
index: 16 => value: q
index: 17 => value: r
index: 18 => value: s
index: 19 => value: t
index: 20 => value: u
index: 21 => value: v
index: 22 => value: w
index: 23 => value: x
index: 24 => value: y
index: 25 => value: z

Apache2::Archive is a mod_perl 2 extension that allows the Apache HTTP server to expose tar and tar.gz archives on the fly. When a client requests such an archive file, the server will return a page displaying information about the file that allows the user to view or download individual files from within the archive.

I just uploaded version 0.2 to CPAN and GitHub correcting a few automatic build issues presented with dependencies. Grab it now with cpanf!

I'm writing a Rails application for the microblogging strategy for Debian (which I used to call, debian-twitter, but you know how us Debian folks are ). I came up with a strange issue, that at first I thought was ActionController's fault or some crap.

So, I was testing one of my controllers with something like this:

cat /tmp/mm.txt | curl -d @- http://localhost:3000/message/new

/tmp/mm.txt is a PGP signed message which then I just send as POST data to my application. So far so good. However, when accessing the data from Rails, using request.body.read, I was a getting a single line, with the newlines (carriage returns) removed. So I started looking at how ActionController was getting the HTTP data and stuff. But then I tested:

cat /tmp/mm.txt | lwp-request -m POST  http://localhost:3000/message/new

And that had the carriage returns in place.

So, I started looking at the curl man page and discovered this little gem:

–data-binary <data>

(HTTP) This posts data exactly as specified with no extra processing whatsoever.

If you start the data with the letter @, the rest should be a filename. Data is posted in a similar manner as –data-ascii does, except that newlines are preserved and conversions are never done.

If this option is used several times, the ones following the first will append data as described in -d/–data.

cat /tmp/mm.txt | curl --data-binary @- http://localhost:3000/message/new

…did indeed the tricky. Maybe someone needs this info some day.