I just uploaded Feedbag 0.6 to Gemcutter and GitHub.

Just a couple of small nice additions to this version:

• The undocumented args[:narrow] option has been disabled until further notice.
• A nice little commit from one of Feedbag's forks, by Patrick Reagan.
• Added an executable to find feed URLs directly:

Sometimes you need to find the feed for a URL quickly, not from a script. What I do, and what someone else showed me too, is this:

~ $ irb
-- require "rubygems"
= true
-- require "feedbag"
= true
-- Feedbag.find "http://stereonaut.net"
= ["http://stereonaut.net/feed", "http://stereonaut.net/tag/feed/", "http://stereonaut.net/comments/feed/"]
--

But now you can simply do:

~ $ feedbag cnn.com http://twitter.com/compupaisa
== cnn.com:
 - http://rss.cnn.com/rss/cnn_topstories.rss
 - http://rss.cnn.com/rss/cnn_latest.rss
== http://twitter.com/compupaisa:
 - http://twitter.com/statuses/user_timeline/119479806.rss
 - http://twitter.com/favorites/119479806.rss
~ $

Enjoy the feedbag executable on your $PATH now!

Generalizations are fun, they always are because they tend to offend people and offended people by stupid shit is usually lots of fun.

Here Debian, as a whole, fails; it sucks. Here Debian blows ass, the entire project is whack.

My good friend Chris Lee sent me this:

If you can't see the above iframe, go here.

Debian, full of fail. Wasn't this generalization fun?

Let the non-sense bullshit horses be released.

I put together a quick template engine for Dancer using Haml via Text::Haml. You know Haml, right?

Now you can do neat shit like this:

 set template => 'haml';

 get '/bazinga', sub {
        template 'bazinga' => {
                title => 'Bazinga!',
                content => 'Bazinga?',
        };
 };

Using:

 !!!
 %html{ : xmlns => "http://www.w3.org/1999/xhtml", :lang => "en", "xml:lang" => "en"}
   %head
     %title= title
   %body
     #content
       %strong= content

The dope thing about Text::Haml is that things like the Ruby interpolation will keep working.

Hurray! Go get it now.

It is worth watching entirely.

Last week, or the one before that one, Alexis released Dancer 1.130 which represents a big refactoring of the Dancer core code, taking all optional modules away from it: Logging, session and template engines were splited into their respective non-core modules, etc. Additionally, two keyword features were added, header and prefix. I will showcase both in case you haven't heard the good word from them

header

The header keyword allows you to modify or alter the response headers by hand. That was a nice little feature that still hadn't been implemented. With header you can do nice little things like this:

get '/set/header' => sub {
  header 'X-Foo' => 'bar';
  "I'm a happy string." . "\n";
}

And this is what that very same code does:

~ $ curl -i http://0.0.0.0:3000/set/header
HTTP/1.0 200 OK
X-Foo: bar
Content-Type: text/html
X-Powered-By: Perl Dancer 1.130

I'm a happy string.

Also, header has a method synonym, headers, and you can use both indistinctly:

get '/some/crap', sub {
  headers 'X-Foo' => 'Bar',
    'X-Bar' => 'Foo';
}

And it will produce the result that you are expecting.

prefix

prefix is also interesting. It will indicate that the following route handlers' path patters defined for Dancer will be prepended with such prefix. So:

prefix '/user';
get '/home', sub { template 'user_home' };
get '/logout', sub { "bye!" };

So here we are instructing Dancer two route handlers that happen to be really pointing to "/user/home" and "/user/logout". In order to stop prefixing the route handlers' paths you just do:

prefix undef;

And continue with your un-prepended paths.

I have always been against FeedBurner. I don't like it at all. I've never liked it, as a matter of fact, I have no actual idea why I've been using it on my blog. I do know why I used it on the country feeds on Planeta Linux, and that is because it was very easy to mask all of our URL changes with some level of stability on the subscribers (in times where me being technically competent was a bad joke for myself). Plus, we could plug AdSense into it (that later on I removed because I like to earn actual dollars, not pennies, you cheap clickers!). Or maybe I'm just so against it because of pure jealousy: A few RSS feed geeks, like myself, sold a sub-parproduct to Google in a hundred million dollars. At the very end, I've never had a good reason to use FeedBurner or to stick with it, so hereby I'm dropping it entirely from my own personal blog.

It's obvious that some people who subscribed to my feed using that FeedBurner URL aren't reading this very blog post. It's alright, I've lost reigns before, I will get over it and conquer their hearts again. But you, dear blog reader, planet subscriber, or eventual visitor, have the power to change things, to help workaround the evils of FeedBurner and make me be myself again. Please, help me myself again! And that is, from now on, use this feed URL and only this feed URL, I promise I will support as long as nice good looking HTTP servers (such as nginx or Cherokee) exist:

http://stereonaut.net/feed/

That said, I will get you a beer next time we meet each other and you, dear reader, mention this blog post and mention that you changed to this new feed URL of mine. I'm not kidding. Just go ahead and tell me

Thank you.

I spent a couple of hours yesterday trying to debug an issue that made me hit my head against the wall while it lasted.

I run multiple instances of WordPress, and with it, comes a nice little editor bundled called TinyMCE. But on my main WordPress installation (this very blog, dear reader, where you are reading this from), TinyMCE wouldn't come up, it wouldn't render properly on the browser, it didn't matter if it was my main browser, Chrome, or Firefox, Safari, cached, uncached, it was just broken. Since I hadn't have the time to go through this issue before, I was using a different editor installed as a plugin. LAME. And coward.

Anyway, I found out that one of the scripts wp-tinymce.php was being returned truncated. Because of that, Firebug would report that some TinyMCE bullshit wasn't defined (JavaScript, oh I'm not very fond of you). Oh, well. I tested calling that script under curl separately and in fact, it was only returning a fraction of the script, 44K out of the actual 200+K. I also found out that even though my nginx installation had gzip compression enabled and the PHP had zlib as well, the script wouldn't process the tinymce.js.gz but it was returning directly tinymce.js. It's alright, I just wanted it to work, no matter if it wouldn't go through gzip, that'd be a matter of some other day.

After a lot of googling I ended up reading this blog post (in Portuguese), suggesting to make sure the file permissions for both the client_body_temp and fastcgi_temp directories allowed the user running nginx (www-data in my case) to write in them. Apparently large scripts would start writing to disk on them temporarily while processing the shit. Of course, you wouldn't have this issue if you are running an nginx from your operating system package manager (like Debian's), but this might very well happen when you are running a custom nginx with separate modules and all sorts of crap on top of it:

chown www-data:www-data -R /usr/local/nginx/fastcgi_temp/;
chmod -R 777 /usr/local/nginx/fastcgi_temp/;
chown www-data:www-data -R /usr/local/nginx/client_body_temp/;
chmod -R 777 /usr/local/nginx/client_body_temp/;

Obrigado, republicavirtual.com.br

 Biella passed this flyer around on the Debian-NYC mailing list. If you are in New York City this Friday, you won't want to miss this Eben Moglen's talk.

If you can't see the embedded object, go here or to this post's permalink.

The fact that the Amazon Kindle per se exists, has attracted a copious amount of comparisons to the now unveiled Apple iPad. The Kindle of course, is a (reportedly, I don't own one) great e-book reader and Sudoku console. One should be comparing apples to apples, since comparing these two devices is like comparing a Nokia 5110, with an iPhone (ok bigots, or with a NexusOne), simply different times, different action scenarios.

I read here or there a tweet from someone saying that given that the iPad is 2x as much as the Kindle, they would be getting a Kindle instead. Of course, this is a big pile of stupidity. First off, let's make clear that the iPad, besides from all of the hype created around it, is much more than just an electronic paper display. Let's compare both devices when I can watch the entire second season of True Blood on the Kindle, seriously. Or let's compare it when you can browse your music library and listen to it while you're replying to your job's email conversations on why Bill, your co-worker on the next cubicle, should throw away his rotten food from the fridge. Or let's just compare the lack of free browsing and/or Wi-Fi connectivity from one of both. Come on.

In spite of the fact that Apple could have made the world go insane by reducing the iPad price by a hundred bucks more, comparing sale prices for the Kindle and the iPad is purely wrong, let's be clear here. But then again, it's just because of the fact that Amazon made a good and popular e-book reader first and started making it successful, why there's such wrong feelings and thoughts about the usefulness of a single feature on Jobs' second coming of Jesus Christ.

But if you still try to compare both, the Kindle will fail miserably. And Amazon could profit from that actually, they can assume their own niche of market and reduce the price to something that would make sense for people to carry such a device instead of the good old book/newspaper commute carrying. Otherwise, it'll leave it as a shitty alternative to the stunning unaffordable Ferrari next door.

I spent some minutes today at work figuring out why a script we use for files and assets propagation wasn't working when fired up under God, but it actually was working when run as its normal user.

The script is a Sinatra application that, upon pings/requests, connects through SSH to different servers on our clusters and execute commands. Details on the implementation are irrelevant here. Since this is automatized, we use key files for the SSH authentication.

When the script was running as the regular user, everything was working fine, but it wasn't under root. So I figured, Net::SSH was trying to use root's private keys file. After reading God's examples I found out that you can also set uid and gid on the watched processes, so that's what I configured:

 w.uid = "myuser"
 w.gid = "myuser"

However, this was still not working. So I made the script print some verification:

puts "My uid is: #{Process.uid} and euid: #{Process.euid} and user: #{ENV['USER']}"

So Process.uid and Process.euid was correctly printing the UID for "myuser", but ENV['USER'] was still "root". I figured that ENV["HOME"] would be the home directory based on the user, "/root", so maybe Net::SSH was still trying to read /root/.ssh/id_rsa, and it was, quoting Net::SSH's :keys option:

:keys

This specifies the list of private key files to use instead of the defaults ($HOME/.ssh/id_dsa, $HOME/.ssh2/id_dsa, $HOME/.ssh/id_rsa, and $HOME/.ssh2/id_rsa). The value of this option should be an array of strings.

God correctly runs the process with the given uid/gid but it will not change your environment variables. And there's nothing wrong with it, all generated processes on Unix systems will inherit its parent's set of variables. God shouldn't necessarily have to be different, but in case you mess around with a given user's environment variables on a process watched by God, remember this post