what I learned over the years

Menu

Month: January 2007

This isn’t written anywhere that I’ve looked, so it’s either obvious, or I just missed the boat. But basically, in order to use the “net/https” library, you don’t need to download it. It’s included in the build of Ruby 1.8.4+

However, what you do need to install is both openssl, and the ruby-openssl packages for it in ubuntu in order for it to be working. Tip!

Installing Ruby 1.8.5 from source

If all goes well, you’re in business. But if it complains about “cannot open crt1.o” (which is likely on Ubuntu), you’ll divine on google that it needs a “glibc-devel-2.3.3-74.i386” package. But I’ve done the legwork already, and under ubuntu, it’s actually called “libc6-dev”

sudo apt-get install libc6-dev

So try making Ruby again. It should be ok. If not, well, it’s not documented here, since I didn’t run into that problem.

What I did run into was more pain installing Gems.

Installing Ruby Gems from source

Now, if all is well, you’re golden. But since this is Ubuntu, it’s likely that you’re missing zlib. So, some people seemed to have been able to get it to work from using the “zlib-ruby” package. What I had to do was install zlib from source.

I’ve always wondered how to grep for the negation of something. When SubClipse messes up, I end up spending time in the terminal. I hate it. It should at least be able to recover from itself.

Anyway, I wanted to find the difference between two directories. So for diff, you simply use:

diff -rq directory1/ directory2/

And this will give you a slew of which files are different or same. But it’ll give you all this stuff about .svn directories that you don’t care about. So how do you grep for the NOT of something? I don’t know, the regex for it (if someone cares to divulge, I’d appreciate it), but grep has a switch that does this for you:

diff -rq directory1/ directory2/ | grep -v 'svn'

And voila, it only gives you the differences other than paths with ‘svn’ in them.

Exception handling was never something that I looked much into. I’ve caught exceptions from libraries before, but when it came to coming up with exceptions to throw, I never gave it too much thought. So I looked it up in detail, and to my horror, I had been using it wrong.

That way, the error handling code doesn’t really get in the way of the ‘good condition’ code. I personally think it’s easier to read, though apparently, this is a bad idea apparently, mostly due to overhead costs in running through an exception, even if there were no exceptions thrown, and that I’m essentially using it as a goto statement. And as everyone knows, gotos taste like ass.

Exceptions are to be used when the method or object that the error occurred doesn’t know what to do with the error at that time. Therefore, it will throw an exception, and hope that some other part of the code elsewhere up the stack will know what to do with it. And so hence the adage: “throw early, catch late”.

So I’m a reformed exception handling abuser. I guess when you have a new hammer, the world looks like a nail, until someone sets you right.