Pages

Tuesday, July 21, 2009

Diving Into CakePHP and Ruby on Rails

I love web development. It's the one kind of programming that seems to continually intrigue me and bring me back for more. I developed my first site using PHP (essentially on the WAMP stack) about 8 or 9 years ago, and haven't looked back. It wasn't until recently that I started looking into frameworks and libraries such as jQuery, Prototype, etc. I always preferred doing things with a text editor from scratch. Sure, it took longer, but I new the complete ins and outs of all of my website. Well, now that time is becoming more and more of a luxury, I can't afford to build sites from scratch anymore. Hence the discovery of two great frameworks: Ruby on Rails and CakePHP.

First, if you don't have any exposure to either of these technologies, there are some similarities in their paradigms. Both are designed to save you, the developer, time in building websites. Their goal is to do the monotonous, repetitive, underlying work for you so you can move on to build the rest of the website quickly. both use principles of MVC (Model View Controller) development. Essentially, their design forces you to use good design principles in your website. A very basic, and incomplete, description of the MVC components could be the following:
A Model is the data and associated interactions (Objects and Database)
A View is the presentation of that data (HTML, CSS)
A Controller is the logic used (Ruby/PHP)
A more complete explanation can be found here.
Another great thing that both provide is the ability to use REST APIs. So, for example, if you were to collect data that you wanted to open up to third-party applications, you could provide them with an API to access it. To me, this is a must to allow for layers of abstraction I previously mentioned in another post.

Ruby on Rails, until very recently, was a mythical and powerful creature to me. I had heard great things about it, heard what it could do, but I had absolutely no experience with it. I decided to change that this week. Within minutes I had completed the download and install of all required software to be up and running (I already had XAMPP on my machine from other development projects). Two great tutorials for learning basic Ruby on Rails can be found here and here. I went through both of them and feel like I have a good understanding of the design principles and capabilities of the technology. Ruby is a very interesting language and pretty easy to pick up. Ruby on Rails seems to be picking up steam in the US as of late, and is being used by websites such as Twitter.

Now, at first I was thinking, why learn another language like Ruby? I already have a good grip on PHP, so why not just stick with that? Great question! (Yes, sometimes I answer my own questions.) That's why I first looked at using CakePHP (plus, my friend was interested in learning it as well). According to the creator of CakePHP, he liked the idea of Ruby on Rails and wanted to bring that to the world of PHP, so he basically took the idea. To quote him from here:
"While it's difficult to copy Rails in PHP, it's quite possible to write an equivalent system. I like the terseness of Ruby code, but I need the structure that Rails provides, how it makes me organize my code into something sustainable. That's why I'm ripping off Rails in Cake."
I followed along with the tutorials on the CakePHP website and had no problem setting this environment up either. I just dropped it into my existing XAMPP setup and ran with it.

I also found plenty of "CakePHP vs. Ruby on Rails" type discussions. In the end, I surprisingly don't have much of a preference. Both were easy to set up, both were easy to learn the basics of, and both provide the framework principles I was looking for. I have a feeling that with more exposure I'll be able to choose a side more easily, but in the meantime, I'm just waiting around for a real project to try these out on. What about you? Which do you prefer?

Tuesday, July 14, 2009

Bible Gateway Search for Ubiquity 0.5

When I upgraded the Ubiquity extension in Firefox this morning to version 0.5, the Bible Gateway search command that I created died.  Apparently, it used a deprecated version of the API -- and so did the other Bible search command that I had, rendering both useless.  If you are completely unfamiliar with Ubiquity, it's an awesome extension available for Firefox that allows you to quickly carry out common tasks (similar to something like Spotlight or Quicksilver).  For more information on the extension, you can go here.

So, if you're interested in updating your commands to reflect the new API, you should probably start at the new command authoring tutorial.  There are some great examples in there on how to get started.

For anyone interested, I updated my Bible Gateway Search command to the following:
CmdUtils.CreateCommand({
  names: ["bible-gateway"],
  icon: "http://www.biblegateway.com/favicon.ico",
  author: { name: "Matt Augustine", email: "sokkerstud_11@hotmail.com"},
  license: "GPL",
  description: "Launches a passage look up on BibleGateway.com",
  help: "bible-gateway (passage query)",
  arguments: [{role: "object",
               nountype: noun_arb_text,
               label: "passage"}],
  preview: function( pblock, arguments) {
    var template = _("Searches BibleGateway.com for ") + arguments.object.text;
    pblock.innerHTML = CmdUtils.renderTemplate(template);
  },
  execute: function(arguments) {
    var url = "http://www.biblegateway.com/passage/?search={QUERY}"
    var query = arguments.object.text;
    var urlString = url.replace("{QUERY}", query);
    Utils.openUrlInBrowser(urlString);
  }
});

Basically, it just does a very simple passage lookup and opens it up.  So, for example, valid queries would be things like:
bible-gateway John 1-3
bible-gateway Matthew 1:4-5

If you would like to install this command in your browser, feel free to copy the code above, or you can install it by going here.  If you have any questions about my command, feel free to leave a comment below!

Tuesday, July 7, 2009

Overcoming Information Overload - Layers of Abstraction

With all of the new web services coming out, seemingly on a daily basis, it is easy to feel overwhelmed with the amount of data that is available to us on the Internet. It used to be easy: pull up your favorite search engine, type in what you're looking for and voila! Now, there are search engines, social sites, RSS feeds, blogs, forums, and the list goes on and on (each with their own built in search engines of course). Plus, trying to keep up with updating several different pages -- Facebook, MySpace, Twitter, flickr , Blog of choice, and don't forget good ol' fashioned email, is quite the daunting task... at least for anyone with a normal social/family schedule. The question then becomes, how do get (and provide) the information we need in a way that is simple, relevant and relational?

Simple: In order to find data easily, there needs to be one interface for doing so. While search engines try to provide this service, it is nowhere near complete. RSS readers like Google Reader are great tools for collecting feeds that you enjoy, but don't solve the relevant and relational pieces completely. Even then, you're responsible for finding the feeds and adding them. On the social front, applications are just starting to scratch the surface on data integration -- a current example would be TweetDeck, which allows you view Twitter and Facebook statuses simultaneously. It would be nice to also have one interface for updating your own personal statuses and websites from one location. Sites like Posterous and Tumblr are really making great progress here, but there's still room for improvement.

Relevant: Sifting through the tons and tons of news articles, tweets, updates, and blog posts (and beyond!) to find data that is relevant to you personally can be quite the chore as well. It would be great to go to one interface that would present you with all of the data you would be interested in across several web services and search engines. Sure, there are plenty of suggestions and recommendations for who to follow, what to subscribe to, who to listen to, etc., but it would be even better if we could extract the relevant data from each of those sources and have it be presented in one unified interface. PostRank is a service that definitely has the right idea. Even their slogan is right on: "Find & Read What Matters." Beautiful. Sites like TechMeme, Google News and Newspond, also attempt to crawl the web to find the most breaking, relevant stories for a subset of topics.

Relational: Web 2.0 has, in large, been about socializing everything on the web, and I think that it has inspired some truly amazing content. There's no reason to slow that down. There needs to be an easy way to view and share everything that you find with your friends and colleagues. It would be great to have one interface that would allow me to reply appropriately (based on the sharing context -- whether the source is Twitter, Facebook, Google Reader, etc.) to a friend, or just share data with anyone. The problem right now is that there are so many social services that we can belong to, and trying to keep each one up to date -- which I touched on in the "Simple" section. Finding and sharing items with friends is a must in the next iteration of data discovery on the Internet.

So, the next question, then, is how do we achieve these goals? My opinion is that we could accomplish this through the use of layers of abstraction. For example, Techmeme could be considered one layer of abstraction in that it gathers news articles from various baseline sources and presents a subset of those articles. In order to present relevant information simply to an end user, I would suggest that we would really need at least another layer of abstraction. Collect the news articles from sources like Techmeme, Newspond, Google News, etc. and present the user with data that is relevant to them based on interests, reading habits, recent conversations, etc. From that new abstract interface they would be able to share any of those items with anyone and any service, updating all of their profiles, blogs, etc. accordingly. All of this would be one small slice of the pie, considering you would also incorporate search and other social functionality among other things. So, I guess you could say that I see the current web services as necessary building blocks (that will need to remain in place) to reach that next level of finding and sharing data in an attempt to overcome information overload.

I'm sure there are plenty of services that I have not yet discovered -- so feel free to share your favorites in the comments section below!