Archive for the ‘Ruby’ Category

Going Camping with CouchDB On OS X Tiger

Saturday, June 13th, 2009

With Snow Leopard being released at the end of September this year, Tiger is definitely starting to show it’s age. I’ve been putting off upgrading to Leopard for quite some time, not being able to justify the down time associated with upgrading an OS. This has had an unpleasant side effect of not being able to do things quite as easily as I want, and finding information is hard.

Due to the recommendations in the comments of my Ruby CMS article, I have decided to start playing with the Camping Ruby microframework backed by CouchDB. Getting Camping up and running was easy enough, and I managed to get some trivial functionality going. Camping uses SQLite for it’s database, which is fine if I wanted to massage my data into a relational form. However, I have models with optional attributes, and rather than making nullable database types, I want to leverage CouchDB’s schema-less, RESTful document storage. Each persisted object in my application will be available on a unique url, so CouchDB is a nice fit for what I want to do.

The Great Installation

I found this great article about getting Camping talking to CouchDB, and it seemed easy enough, so I decided to try it. Since I already had Camping working, all I needed was to get CouchDB installed on my Macbook. As much as I’m not scared of compiling applications from source, I’ve had issues in the past with OS X and compiling, so I decide to find a simple package or disk image to install. I found CouchDBX, however checking the requirements showed that it supports Leopard only.

With a little more research, I found out I had to use Macports to install CouchDB. Macports relies on XCode Tools which come available on the DVDs that came with OS X. If you haven’t previously installed XCode Tools, then you should install them before you install Macports. Something that is buried in a support ticket, however, is that Macports targets XCode tools 2.5. My XCode tools was something like 2.4.8. While I did manage to get Macports installed, the installation for CouchDB fails when it tries to build tk. If you, like me, have an older XCode Tools than 2.5, you’ll need to download 2.5, which you can find deep inside the Apple website. This does require an Apple Developer Connection account to get, so if you don’t have one, you’ll need to create one.

Installing CouchDB is as simple as issuing

sudo port install couchdb

and Macports will take care of the rest. CouchDB lists it’s dependencies as Spidermonkey, Erlang and a few others, however each of those has dependencies, and each of those dependencies has dependencies, and it ends up taking quite a long time and downloading a fair few packages. The upside is that if you didn’t have Erlang previously installed, you do now. Erlang is something I’ve been wanting to take a look at.

Start The Server Before You Leap

While the article I linked to above about getting Camping and CouchDB talking is good, it’s not exactly the most verbose explanation especially if you haven’t read the documentation for CouchDB and prefer to just dive in. For those who are still a little unsure like I was about how exactly to do this, I’ll outline my approach below.

Before you get started writing any code at all, you need to start your CouchDB server. This is something that escaped me for the longest time, and when I finally twigged, it gave me a bit of grief. To start CouchDB, issue the following command:

sudo couchdb

If you try this without escalating privilege, it will return an error “{“init terminating in do_boot”,{{badmatch,{error,shutdown}},[{couch_server_sup,start_server,1},{erl_eval,do_apply,5},{erl_eval,exprs,5}, {init,start_it,1},{init,start_em,1}]}}”, which searching for will bring you to the CouchDB wiki page for error messages. This page will tell you the problem is an unavailable port. For me, at least, this is not true. CouchDB runs on port 5984 which as far as I know is not used for any system services or other software. The reason I was getting this error was that I wasn’t running it with enough privilege.

Once you get CouchDB started, you’ll notice it blocks the terminal. I don’t like to have too many windows open at once, so I’d prefer to have it run as a background process. Fortunately CouchDB will let you do that with a command line switch option, along with changing the location of the pid file. I’ll leave figuring out how you want to start it up to you.

Once you have CouchDB started, you’ll have access to a web-based administration panel called Futon. Futon is available to you at http://localhost:5984/_utils/, assuming you’re running CouchDB on your local host. The Futon utility will allow you to create databases and insert documents in preparation to test your connectivity with Camping.

Camping Time

There were two Ruby gems I had considered when deciding how to connect Ruby to CouchDB. I should point out that due to the RESTful nature of CouchDB, you strictly don’t need any Ruby gems and could roll your own fairly easily, if you wanted to. I didn’t want that level of control, personally. The two gems I considered were CouchRest and RelaxDB. CouchRest is a simple Ruby wrapper around the CouchDB REST API, whereas RelaxDB is more abstracted, bringing ActiveRecord-like functionality to CouchDB. While before I would have chosen RelaxDB, I’m intentionally trying to work a little closer to the raw APIs here, so I chose CouchRest.

You can install CouchRest through RubyGems:

sudo gem install couchrest

however I found that the gem version wouldn’t work and kept throwing errors when I started my Camping application. To overcome this, I just cloned it from the GitHun repository and placed it in my Camping app directory and referenced it that way.

The first thing to do would be to create a normal Camping sample application, if you haven’t done already. For the purposes of this post, I’m going to use the “skeletal Camping blog” application used in the documentation, and edit that to work with CouchDB. I figure this will give everyone a relatively common base from which to start. Import CouchRest just below where the application imports Camping:

require 'camping'
require 'couchrest' # or 'couchrest/couchrest' or similar if you've cloned from Github

Given that the purpose of this article is to demonstrate connecting to CouchDB, and not the design of a framework around it, we can safely ignore defining a model for now, and rely on CouchDB as our model. So if you’re following along from the example application, you can safely delete the classes from Blog::Models module. We’re not going to delete the whole module, because of the create method.

The Camping create method that is run when the server starts up your Camping app. From the documentation, “This is a good place to check for database tables and create those tables to save users of your application from needing to manually set them up.” Instead, we’re going to use this method to set up CouchRest in our application:

module Blog::Models
  def Blog.create
    db_url = 'http://localhost:5984/'
    storage = CouchRest.database("#{db_url}blog")
    Blog::Controllers::Index.set_storage(storage)
  end
end

Next, because we’re now calling a new method on the controller class, we need to modify that. Change the Blog::Controllers::Index class to the following:

module Blog::Controllers
  class Index < R '/(\w+)'
    def Index.set_storage(storage)
      @@storage = storage
    end
    def get(id)
      @post = @@storage.get('posts/' + id)
      render :index
    end
  end
end

What I’ve done here is given the controller class a static reference to my CouchDB database (from the create method). Then the controller was changed to respond to a regex, which is passed into the get method. We use the id passed in to retrieve a document from CouchDB, which we assign as an instance variable.

Lastly, we need to modify the Index function view to pull data from the CouchDB database:

def index
  h1 @post[:title]
end

This will output the title of the test document created at the start of the article.

If you haven’t already, start up Futon and create a database for the purposes of this demo. Call the database “blog”, and fill it with a test document with the id of “posts/test”, and at least a “title” property with the value “Test Post”, and any other properties you wish.

Start the Camping application with camping blog.rb, and point a browser to http://localhost:3301/test, and you should see “Test Post” in a header tag, rendered out to the browser, which means that Camping has successfully communicated with CouchDB.

I didn’t cover putting data into CouchDB, however you would do it in a similar vein, writing a post method inside your routes to create data and save it to CouchDB. From here, personally, I’m going to create some wrapper classes for requests and models and build up something which is a little DRYer, however as far as a demo, this is good enough.

A CMS in Ruby on Rails, and Why I Stopped

Monday, April 6th, 2009

For the last couple of months I have been writing a series of posts describing a personal Ruby on Rails based CMS. I have been writing tutorial style posts outlining what I was doing, and why I was doing it. Don’t bother trying to look for those posts, because I’ve archived them.

This decision was pretty easy after I slowed down and reviewed the situation objectively for a few minutes. That clarity, coupled with a few truths that hit home while reading the source of a few other Rails applications pretty much sealed the deal.

The next post in the series was going to be an overview of another Ruby CMS project, BrowserCMS. I saw a video from RailsConf about this project, and recognised a lot of their goals as coinciding with mine. So I was going to poke through their code, see how they’ve done things, compare it to how I did the same things, or was planning to do them.

While I was reading through their source, it occurred to me just how much I don’t get Rails. I have a bit of a poke around with scaffolding and get familiar enough with the generators and I decide that I’m ready to tell people how do create a CMS in Ruby, because I’ve nearly finished creating a CMS in ASP.NET.

It’s clear to me, now, how silly that was.

Rails isn’t just a framework for Ruby, it’s a whole change in paradigm. Intellectually, I know Rails is “opinionated software”, however I don’t think I understood what that really means. I tried to make my code as flexible and configurable as possible, and I was struggling with all but the most basic CRUD tasks.

So, first I realised I wasn’t ready to tell anyone how to do anything in Rails.

But I have a series of about 5 posts doing just that. What do I do with those? Do I continue on, plugging away at learning while trying to instruct? I decided the answer to that depended on what I had achieved with my posts. What was the value of them?

Then I realised that I had covered very little other than simple CRUD. Sure, I had some unusual object relations, like trees and self referential comments, and I implemented some business logic like compiling pages into templates, however the total sum of the non-CRUD related content could have fit into 1 post. So I spent 4 posts blathering away at how to achieve the same task as running script/scaffold.

What’s worse is that I realised I was back in the rut of creating a CMS. How on earth did I do that again, after stating loudly and proudly that I don’t even like programming websites.? Well, I told myself, you are planning on using this on your own sites, your many, many online business ideas. Sometimes you have to do the same old thing to earn money. Which is true, if I had done anything of worth, but I hadn’t, I was a long winded scaffold script. I got carried away in the joy of learning a new language/framework (which isn’t a bad thing), and fell into the familiar territory of doing what I always do (which is a bad thing).

So, now I realise that I’m not only trying to teach people something I don’t understand, I’m trying to teach them how to do something I don’t even like doing.

That’s stupid.

I’ve archived the posts. I may revisit, as I still have grand ideas of what a CMS should be, but for now I’m shelving the whole thing. Luckily I have such a small readership (read: none) at this stage, nobody will be affected. For that I’m grateful.

And yet, through all this stupidity, I have learnt a few things of value.

I’ve learnt that Ruby on Rails is more complex than I thought, and will hit the books again to pick up some more advanced techniques.

I’ve learnt that I’m scared to push myself in programming. This revelation is a pointy one. I love programming, it’s my job, it’s my hobby and it’s my passion. The fact that I’m scared to push myself to innovate, hiding behind the excuse that I’m not smart enough or I’m not creative enough is double edged. On one hand, it’s sad that I’m not as ambitious as I thought. On the other, it’s great that I know now, so that I can get stuck into remedying that.

I’ve also learnt a lot about blogging. Those posts of mine weren’t really providing much value. I don’t have many readers because I’m not saying anything new, and I’m not showing anybody cool things they can’t find in a hundred other blogs. I also didn’t have much of a personal voice, and was writing them like I would a textbook, which is missing the point of a blog. It’s supposed to be informal, and I’m supposed to show my personality. So, I’ve found my voice, while realising that I’m not providing value. Another pointy idea, but ultimately good, because that too is something I can work on.

So, inevitably, I have to question the value of this post. What could this post provide to someone who stumbles across this website? Well, a few things.

Firstly, self awareness is a great thing to possess as a programmer. If you know where your weaknesses are, you can train in them, and get better. But that’s not enough, you also need to know what you’re afraid of, so you can recognise that you don’t even know that it’s a weakness. That fear hides the existence of the things you’re not good of, and that’s a major roadblock to improving.

And lastly, if you don’t have anything to add to the conversation, don’t say anything. The whole internet is a conversation, and I’ve just been babbling to myself in a corner the whole time. If you want to contribute, add your own thoughts, your own interpretation on subjects that are well known. Go into new levels of detail on old ideas and technologies. Introduce new ideas or technology, or modify existing ones. Contribute, don’t just talk for the sake of talking.

3 Hours from Concept To Implementation With Ruby

Wednesday, January 28th, 2009

 

Ruby

Although I’m still relatively new to it, I’m a big fan of Twitter. However, not for the social media aspects of it. I view Twitter as an excellent method of gathering information, as long as you follow the right kinds of people. By the right kinds of people, I mean people who tweet interesting links they find online. Simply follow people who are interested or involved in the same subjects that you’re interested in, and they will feed you information over time, in a nice steady flow.

I’m very much interested in AI, and AI as it applies to games. I am a fee paying member of Alex J. Champandard’s AIGameDev and I follow him on Twitter. While this is great, his flow of information isn’t fast enough for me. So I set to Twitter to search for people who are interested in AI and game development, when I found the @playwitter account, and the associated website. As you can see from the @playwitter tweet, they’re not yet fully functional. I didn’t really want to wait, and I didn’t really want to follow all those people on my own. So I decided to come up with an intermediary solution.

The concept is a Twitter bot that will read in an RSS feed and tweet the entries. I decided to use Ruby, as I haven’t done any significant programming in Ruby before. All I knew was the basic syntax that I read from the Pickaxe book.

First, I hit Google looking for a Ruby RSS parser library. Oh! It turns out Ruby has one built into the language. So I read a few websites on how to do that, and it seems pretty straight forward. So I grab the feed over at Playwitter and start pulling it down with my Ruby script. The quick script I wrote in 10 minutes worked like a charm.

The next part was to tweet the entries. I looked for a Twitter library and settled on the Twitter gem. I installed the gem, and this took me a while to get it working as a library, but get it working I did. I was able to send tweets from an automated script.

It took me about half an hour to wire these together and before I knew it, I was done. However, it was fairly crude, and I found out when I tried to deploy it to my server that it wouldn’t make the grade. I set about refactoring and upgrading the code and trying to get it run. 3 hours later, it was complete, and it was working.

In the end, I implemented the idea in 3 hours, with the following features:

  • YAML config file for defining Twitter account details and RSS feeds to tweet from.
  • Timestamp based polling of the RSS feeds, storing only updates new since the last poll.
  • Tweeting with added hashtag, defined in the YAML with the feed
  • Deployment as a Ruby Gem

Details of the project are the subject of another post, and when that project is a little mature, I will create that post.

From concept to deployment on a live site, with a basic knowledge of Ruby only, in 3 hours. That’s a fantastic result that I’ve never experienced in another language, compiled or not. It was fun, it was fast, and I felt the freedom of PHP with the benefit of a well implemented OO system.

Man, I love Ruby.

Frameworks Make Reading New Code Hard

Sunday, January 25th, 2009

In an effort to increase my knowledge of both Ruby and Rails, I have been keeping my eyes open for interesting Ruby/Rails apps to peek at the source code of. Whilst looking at @j_stirk’s website, I noticed it was running on Radiant CMS, a Ruby CMS. So, I grabbed a copy of the source code.

Whilst I was having a peek at the source, I began to think that I was in a little over my head. I managed to muddle my way through the config/routes.rb file and figure out (with judicious use of Google) what requests were being directed to what controllers. The problems started happening when I hit the controller, and started seeing filters and symbols and statements that I didn’t know where to go next to find out about.

Confusion

At first I thought it was to do with the fact that I don’t really know Ruby. I know enough to recognise it, and muddle through basic syntax, but I don’t know any tricks, any coding conventions and the nuances of Ruby programming. However, upon reflecting on my dilemma, I realised this isn’t something that was restricted to Ruby, Rails and Radiant CMS.

I remember last year looking into Symfony, before deciding that PHP was too god-awful ugly to waste my time on. I recall that too had a fairly high learning curve, and looking through an existing Symfony app, it was very hard to figure out what exactly was going on. There was much API browsing.

A few years ago when I first learnt ASP.NET, I was in a similar situation. Server tags and user controls and page events and assemblies were all very new and very confusing to this ex-PHP & ASP 3.0 developer. I stormed through a book on ASP.NET and was thrown head first into a contracting gig before catching my stride again.

I love frameworks. Ever since I heard about this thing called “Rails” a few years back, and realised there were a few similar frameworks written in PHP, I’ve been in love with frameworks. And I’ve always learnt them from the ground up, creating my own application. Last night was the first time I’ve ever tried to learn a framework from an application.

And it’s hard.

While frameworks increase programmer productivity and make maintenance easier for programmers who already are in the know, they make things really hard for a new maintainer who is not familiar with the code to dive in and figure out what’s going on. Not only do they have to learn the individual nuances of the programmer who wrote the application, they also have to figure out how the framework works.

Ruby Wrap Up

Friday, December 26th, 2008

Today marks the last day of my Ruby portion of my Ruby/Python Bootcamp. Unfortunately with the Christmas and related Christmas stresses, and an impending move, I didn’t get to spend a lot of time with the language, beyond the fundamentals.

I did a dumb thing, and started to try to get a website up and going on Rails 2.2. Rails is a great framework, although I’ve found the learning curve beyond your basic scaffolding and MVC set up to be fairly high. I made extensive use of this Rails API guide and it certainly helped a lot, as did the Ruby on Rails guides portal. The reason this was as dumb idea had nothing to do with Rails or Ruby, and everything to do with the fact I hate making websites.

Seriously, I’m on holiday. I should be staying away from websites for a while.

So, I didn’t end up doing much on the website I promised I’d show, and there’s not really anything to show, yet. I did manage to set up an excellent workflow with SVN and my web-host, which will eliminate the need for an FTP client, and Ruby did help me complete my partial understanding of RESTful design.

So, I walk away after a week of Ruby with a rudimentary knowledge of Ruby syntax, which is enough to let me read Ruby code and fill in the gaps myself, a stronger knowledge of RESTful design and a much smarter development workflow.

Thanks, Ruby.

So, tomorrow, or tonight, I’ll kick off Python, and I’ll also see if I can’t use it while investigating a few other programming related interests, like OpenGL programming or some AI stuff, if I can figure it out. Hopefully I’ll be able to get as much out of Python as I got out of Ruby.

First Impressions Of Ruby

Saturday, December 20th, 2008

I like it.

A lot.

But I always knew I would. I’m so far impressed with how much effort Ruby goes to at making itself understood at a casual glance, and just how easy it is to write self documenting code. Writing code that’s free of braces and parenthesis is refreshing, and it’s nice to know the safety blanket is there (with regards to parenthesis for functions, conditional statements, etc) is there if I need it.

I started last night by flicking through Why’s (Poignant) Guide, and found it pretty good for the basics. I quickly picked up the general concepts and basic syntax fast, and Why’s Guide was pretty whimsical and kept things interesting. However I quickly bored of the absurdity in chapter 5 where the majority of its content is fluff.

I tried switching to SaphireSteel’s The Book of Ruby, however right at the start when the author stated:

if (subtotal < 0.0) then subtotal = 0.0 end

Putting everything on one line like this adds nothing to the clarity of the code, which is why I prefer to avoid it

I knew that this book would not help me. I already know many languages that require simple statements like that to be spread over multiple lines. I want a language to do this:

subtotal = 0.0 if subtotal < 0.0

Hi, Ruby.

Then I browsed over to Ruby in 20 Minutes and quickly flicked through the pages, and it concreted my knowledge. I like iterators, I like respond_to?, I like how everything seems to make sense. I also am pleased to see how many concepts map onto similar things in C#. Modules are like namespaces, but better. attr_accessor is like { get; set;}. attr_reader is like {get; private set;}.

I feel I’m ready to go find some code in the wild and attempt to read it. I’ll also see if I can come up with a post that maps Ruby concepts to C# concepts for other C# programmers interested in Ruby (and with IronRuby, there’s no reason why you shouldn’t be).

Ruby & Python Bootcamp

Friday, December 19th, 2008

It’s common advice in the programming industry to learn one new language every year to stay on top of things. It’s something I honestly believe in as well. Unfortunately I can’t say I’ve learnt a new language this year.

Last year, I learnt Actionscript 3.0, which is different enough from Actionscript 2.0 to be called a new language. I did this because of work, I did it in December and I had to do it fast. That worked pretty well for me. I got thrown in the deep end and had to learn or drown.

This year, with this being my last day at work for 2 weeks, I’m going to do the same thing, but I’m going to make it a little more interesting. I consider myself a reasonably competent programmer, and fairly solid in my knowledge of OOP paradigms. I think I can learn a language pretty quick. So, during my holidays, I’m going to:

  1. See how fast I really can learn a language at least to the point where I know what to search for online and can find my own way around reasonably confidently.
  2. See just how easily various concepts from different languages transfer across syntax
  3. Build some stuff I’ve been meaning to build for a while but kept putting off

With that in mind, this year I’m going to learn both Ruby and Python in 2 weeks, dedicating a week to both languages. In the process of learning these languages, I will also build a base for 2 websites for 2 of my domains that I have been meaning to build. I won’t spend any time designing them, just building the code.

So, over the next 2 weeks, the majority of posts on here will be reflecting my thoughts on Ruby and Python, and linking to resources that I plan to use in my learning, with a final post being the unveiling of the websites I manage to build.

Wish me luck!