Showing posts with label ruby. Show all posts
Showing posts with label ruby. Show all posts

Thursday, October 9, 2008

Why Ruby is My Favorite Language

I started programming seriously roughly ten years ago. I was working in the call center of an ISP, and there was a need for a reseller tracking application. I was attending the local community college at the time, and had been indoctrinated into the world of computer programming trhough what amounted to vocational training in Visual Basic and Microsoft Access. Fortunately, the ISP was a Linux shop, and a few employees were nice enough to introduce me to the basic philosophy of Linux and assist in learning some rudimentary shell commands.

One of these employees was a Perl hacker, and he assisted in convincing the company to form a small team of three programmers to tackle the programming job. I was lucky enough to be chosen for the position, and to be frank, after having spent a few months in the call center, I would have considered janitorial duties a promotion. The only problem was that I didn't know Perl. I quickly ran to the nearest bookstore, grabbed a copy of Learning Perl, and set to work learning the language. A week later, I was neck deep in the project and thankfully had an experienced programmer to lead me through my first big job. The project was a success, and the team became a permanent fixture at the company.

What impressed me so much about Perl was the succintness, mneumonic friendliness, and consistency of the language. After a few weeks of intense study, I could perform the majority of my daily programming tasks from memory and rarely needed to consult a reference.

A year or so later, PHP hit the scene. With the huge buzz surrounding the language, I figured there had to be something really groundbreaking going on. The team I was working on chose to build a large project in PHP, and once again, I set out in earnest to learn the language. This time, things weren't so easy. While Perl had "sunk in" right away, PHP lacked the natural abstraction I had come to love about Perl. As an example, I didn't understand why PHP needed sixteen sort methods (sort, arsort, asort, krsort, ksort, natsort, natcasesort, rsort, usort, array_multisort, uasort, uksort, dbx_sort, imap_sort, ldap_sort, yaz_sort) while Perl only needed one. The database methods lacked the wonderful platform independence of DBI, and a lot of other things felt redundant. Mostly though, I disliked the way the language encouraged mixing interface with your implementation. At the time, the PHP website frequently featured examples interpsersing functions and HTML and even touted this ability as a "language feature".

Progressing through my courses, I ended up taking a class on object oriented design. I learned about the model view controller architectural pattern and immediately saw it's advantages as a design strategy. I learned the basics of object oriented programming with Perl, but I was dissatisfied with the way it was implemented. I spent a considerable amount of effort learning Java and later Python. I found both languages to be "good enough" in the way they possessed a healthy amount of easily accessible OOP goodness, but I missed the fluidity of programming in Perl and neither ever became a "favorite".

At this point I was working at an environmental laboratory, and I was given complete freedom to use whatever technology I wanted to solve the problems at hand. I was tasked with writing a data analysis and computation software for an ICAP (Inductively Coupled Argon Plasma Spectrometer), and I was again at a crossroads. An article on Slashdot had drawn my attention to the Ruby programming language, and I found an excellent book that was freely available online. Reading the introductory walkthrough section, I was immediately impressed by the fact that literally everything in the language was an object. The core language was incredibly consistent, concise, and well documented with absolutely no cruft. All of the wonderful Perl idioms I'd come to know and love were right there at my fingertips; albiet, in a more readable fashion. I was sold.

I learned the language and developed the project simultaneously. This was long before Rails was even a whisper in the programming world, so I rolled my own MVC style framework containing a presentation layer that used a combination of XML, eruby templates, and LaTeX. This made it easy for the app to generate both HTML and PDF documents on a whim. The development cycle was fast, the project was finished ahead of time, and everybody loved the final product. Later I wrote a C extension for Ruby to easily access the Win32 serial port allowing an archaic lab instrument to dump data straight to an OpenOffice spreadsheet. I'd never considered writing a C extension to any other language, but again, Ruby made it easy.

Since then, Ruby on Rails has rolled onto the scene and has allowed me to develop projects in which I would have needed a team in the past. MVC is the core paradigm and being able to use my favorite language alongside my favorite architectural pattern is nothing short of a godsend as a web developer. I've used Rails to develop web applications on the fast track and have brought in a nice supplementary income doing so. Best of all, I feel good about the final product when writing a Rails app knowing I'm developing in a standardized way where another programmer will be able to come along later and easily maintain the work I've done. There are MVC frameworks for PHP, but there's still no de facto standard way to roll a PHP app. This makes every PHP app a "special surprise" when you look under the hood. Sadly, the surprise isn't always pleasant.

I'm not saying you can't write good code in PHP. Actually, working at Grooveshark has shown me that it's possible to write extremely clean code in PHP, but I still run to the PHP manual several times a day to lookup one of it's 3000+ core method signatures.

I'm acutely aware that languages are like religions among developers and that everyone has their favorite for one reason or another. I'm also certain there are people out there that would disagree with some of the arguments I've made here. Arguments aside, if you're looking for a new language to learn, and you haven't tried Ruby, take a look, and I think you'll be pleasantly surprised at all that it has to offer.

Thursday, August 21, 2008

Installing Ruby DBI, MySQL on Centos 5.2

There's no good documentation on how to do this online, so here's a quick tutorial on how to get Ruby's DBI and MySQL packages installed on CentOS 5.2. There aren't any pre-packaged binaries for this, so building from scratch is pretty much your only option.

# download
wget http://tmtm.org/downloads/mysql/ruby/mysql-ruby-2.7.tar.gz

# extract
tar zxvf mysql-ruby-2.7.tar.gz

# change dir
cd mysql-ruby-2.7

# configure (requires mysql development package AND gcc)
ruby extconf.rb --with-mysql-config
checking for mysql_ssl_set()... yes
checking for mysql.h... yes
creating Makefile

# finish (as root)
make install
(ignore warnings)

Now DBI:

# download
wget http://rubyforge.org/frs/download.php/41303/dbi-0.2.2.tar.gz

# extract
tar zxvf dbi-0.2.2.tar.gz

# change dir
cd dbi-0.2.2

# setup
ruby setup.rb config --with=dbi,dbd_mysql
ruby setup.rb setup

# finish (as root)
ruby setup.rb install

Monday, June 2, 2008

Hashes Under The Hood

If you've ever worked with hashes before and wondered how they work behind the scenes, I've written a very straightforward Ruby implementation of a hashing class. The "lookup" method in particular is pretty easy to follow and should give a decent understanding of how hash retrieval works in general.

Simple Hashing Implementation

Edit: Looks like Ruby Garden is temporarily down. Hopefully it will be back up soon.

Tuesday, March 18, 2008

PHP Test Trick

This is a trick that works in a lot of languages. Say you have a file containing a library that also has some utility in it's own right. As an example, I wrote a metadata parser at Grooveshark called MetaShark. It's basically a file containing a bunch of "utility functions" that are invoked via a call to main() inside of the file. It came time to write a unit test for the parser, but I didn't want to call main() from inside of the test suite because that would have the unwanted side effect of processing the current batch of jobs. Instead I want to test the methods individually and make MetaShark just work as a library. All you have to do to make this work is something simple like this:

if ($argv[0] == basename(__FILE__)) {
main();
}

or in Ruby:

if __FILE__ == $0
main()
end

Extrapolate to your language of choice.