Elijah-Bleu Boston's Weblog

In my continued search of a new language/framework/thing to pick up, I’ve become pretty fascinated with Ruby. The word I have settled on for the Ruby language itself is “concise”, coming from C the amount of work that can be done in a few lines often makes me feel like I’ve left something out… but no, Ruby is there in the background doing it’s thing.

I have concerns about performance, Ruby 1.8 is slow. Ruby 1.9 however looks to be a huge improvement in speed.

Before dedicating myself to anything I perform a very simple test: I run a Google search for “X sucks” where X is whatever it is I plan to spend time learning. I’ll read through all the criticism, then try to figure out if the cons outweigh the pros. I discovered using this method that Ruby and RoR are perhaps the two most hated on projects in the open-source world. Nonetheless, for some reason I am drawn to the syntax of Ruby and the concepts behind RoR. I can see the possibilities. While the framework might not be solid and the language is slow, I can’t see anything but greatness in the future for Ruby and Rails, and it has nothing to do with either.

The reason I can see Ruby and RoR dominating the web environment within the next 5 years is the ideas and concepts behind them. With Ruby you have a purely OO language, that while slow, in a release or two it could be on the same performance level as PHP. With RoR you have a framework that makes huge tasks relatively trivial, but the documentation is horrible and you really need to understand Ruby before doing anything other than the most basic CRUD operations.

Now, on the flipside there are many RoR imitators hoping to copy these ideas and concepts into other languages. I’ve already discussed my experienced with PHP frameworks. What I found though is that while these RoR-like frameworks imitate the concepts well, what differentiates RoR is how the framework blends so well with the language. With CakePHP and symfony, I never got over the feeling that I was working with a framework that was trying to do things in a way that did not suite the language and made working with the framework more of a burden.

When you break down the pros and cons of any framework though, it really just comes down to what your comfortable with. I was looking to learn a new language and build a dynamic user-driven website with it, with RoR I found the ability to do both at the same time.

I’ve been playing around with some PHP MVC frameworks lately, Cake PHP primarily, with Symfony and Ruby on Rails for comparison. Its my first foray into the MVC design method at all, and while I’m seeing the benefits, at times it seems to be an almost frustratingly efficient system. I say that in the sense that because everything can be broken down into such basic elements, it begs the question of just how basic you should be with certain things.

For example, I have my Posts table setup with a boolean field “is_page”, indicating whether the post should be displayed as a post or a page, this information is also used to determine whether the page title should be displayed as a menu link. When taking the MVC approach, Posts and Pages should be seperate, and while that would be correct, it would also require creating 2 controllers, with essentially the same functions and code in each. That seems a little redundant, as the only real difference should be in the layout used when the item is displayed.

Nonetheless, as the pieces slowly come together, I’m beginning to understand the power of a solid MVC framework. If you find yourself creating websites that share common elements, such as contact forms or a coupon system, you’ll find great benefit from setting aside some time to really play with a few frameworks and see which one is what you need.

It must also be said that there are a ton of choices in PHP frameworks out there, many of them are quite solid. The alternative to CakePHP that I’ve been looking at most lately is the Zend Framework. It offers a lot of the handy abilities of CakePHP but is much more flexible, lightweight, and very modular.

UPDATE: Google has released version 0.10.1, this guide is based on the 0.10.0 code but there should not be any major deviations. As always post on the Google Gadgets for Linux message board if you run into problems.

I was never a fan of desktop gadgets/widgets as most of the ones available performed horribly and had few useful programs. Google Sidebar is considerably less obtuse, it sits on the side quietly acts how you want it to. When I would boot into Ubuntu I found myself missing some of the gadgets I had found to be handy, like Scratchpad for jotting down random notes and thoughts, and Laptop Monitor for viewing system information.

Like I imagine most Ubuntu nubs do, I quickly googled for “Ubuntu Google Sidebar” which brought up a myriad of results, eventually leading me to the Google Gadgets for Linux project page. Apparently the folks at Google want their gadgets cross platform as much as I do.

The problem is the program is still in the early development stages, which means if you absolutely need your Google Sidebar in Ubuntu you must be willing to open up a console and get your hands dirty with the more intimate parts of Linux. Its not as bad as it sounds.

You should be aware of 3 things before using this guide:

1. First, dependancies. These are the packages that you will need to install using the Synaptic Package Manager (under System -> Administration):

• libdbus-1-dev
• libmozjs-dev
• libxml2-dev
• libgstreamer0.10-dev
• libgstreamer-plugins-base0.10-dev
• libltdl3-dev

Now you need to decide which API toolkit you want to use, GTK, or QT… this is one of those issues that Unix people like to endlessly debate but is only really important to developers. Go ahead and flip a coin, I went with GTK.

GTK:

• libxul-dev
• libgtk2.0-dev
• librsvg2-dev
• libcurl4-openssl-dev

QT:

• libqt4-dev
• libqtwebkit-dev

2. Compile time! Download the binaries from here and extract them to a folder on your desktop (although they can be saved anywhere, this makes the path to them a little easier). Now open a console and enter the following:

cd /home/[YOUR_USERNAME]/Desktop/[FOLDER WHERE GOOGLE CODE IS]

sh autotools/bootstrap.sh

Once that is done, and provided you don’t get any errors, proceed and enter:

mkdir -p build/debug
cd build/debug
../../configure — enable-debug
make

If you run into problems during this step its likely that one of the necessary packages is not installed. The log should tell you what is missing.

Finally enter:

sudo make install –prefix=/usr/local

Take a moment to sit back and feel like a l33t h@x0r while seemingly random text fills your console window.

When its complete, and provided you didn’t receive any cryptic errors, go ahead and enter ggl-gtk (or if you went with QT, ggl-qt) in the console window. You should see the Google sidebar pop up and you can rejoice.

3. One last optional step if you don’t want to have to go through opening the sidebar through the console every time.

Create a Shortcut:

• Right-Click -> Create a new Launcher
• Command: ggl-gtk or ggl-qt

Autostart on bootup:

• System -> Administration -> Sessions
• Click Add
• Command: ggl-gtk or ggl-qt

There is both far too little and far too much going on right now. I just started a new job doing tech support for USF, which is turning out to be an incredibly sweet gig. The pay is horrible, but the fact that I’m doing tech support and helping people (yay) without the soul crushing stress and monotony (nay), more than makes up for it. If I had to look really really hard for a downside (aside from the pay, which actually isn’t too bad for a uni staff position) it would be that I’m confined to a desk for 8 hours a day. The flipside to that is it’s a desk with a comfy chair, dual monitors, and a light workload that has me dealing with unique and interesting problems and not with irate customers who have been sitting on hold for 45 minutes after being bounced around to several different departments.

I’ve been delving into WordPress with every spare moment I have, and while I know of it’s faults I am also impressed by it’s capabilities. I currently plan to use WP for the student organization’s I am working with, partially because it would give the site’s longevity and prevent them from becoming skeleton pages, but also because I wish to observe how a site might develop if users were left mostly to their own devices in creating and managing content. I think WordPress is perfect for this sort of collaborative content creation.

Of course it is not without it’s faults. I haven’t tried anything too fancy yet, but what I was immediately struck with as I explored the WP documentation was the amount of redundant and outdated tags that are strikingly similar to one another aside from one tag being introduced in a later version but performing essentially the same function. There are instances where functionality was added with these new tags, but one wonders if there wasn’t a better way to merely expand the capabilities of the current WP markup instead of having two versions of nearly every function.

Even this is actually very minor though, the documentation is excellent in explaining what newer tags correspond to older ones, and I found a nifty little extension for Dreamweaver that will automate most of the WP markup creation for whatever you need to do. That made it easy enough to feel like I was cheating, but then I remember how many hours I put into trying to gently coax CSS to do what I want it to, and that just makes it an incredible time-saver.