And so I am at Chapter 4 - Modules and program organisation of Well-Grounded Rubyist. When going through the chapter - the first impression that I’ve got is: Module is very similar to Java Interface.

At the surface it does seem like it. You can include multiple modules on your Ruby class - just like you can implement multiple interfaces in your Java class. Both also seems to be useful for implementing behavior that is shared among classes. So in the book, David gave an example of module “Stackability”.

But the similarities ends there.

Java Interface is a contract, if you “implement” an interface, you are promising that you will implement the methods in the interface in your class. Java will be unhappy if you break this contract. The interface itself does not contain any implementation details - it is simply a stub.

Ruby Module is not like this, methods in the module are fully working methods - I guess the closest thing that I can think of - module is like a library (I’ll see in few weeks time whether my understanding is correct).

Method lookup path is also interesting - if your class extends a class (which extends another class and so on) and includes a couple of modules - and just so happen every one of them have a method with the same name - which will get called first?

Rather that giving my own sub standard explanation, I would instead copy from this excellent blog post: Method Lookup by Gregory Brown

1) Methods defined in the object’s singleton class (i.e. the object itself) 2) Modules mixed into the singleton class in reverse order of inclusion 3) Methods defined by the object’s class 4) Modules included into the object’s class in reverse order of inclusion 5) Methods defined by the object’s superclass.

Checkout Gregory’s Ruby Mendicant University as well - while you are at it. This guy has done a lot for the Ruby community - ah, this is why I am really intrigued with Ruby and its community.

I have made it to RORO (Ruby on Rails Oceania) Meetup for 3 meetings in a row now. Last night was particularly interesting - interesting because I finally can understand most of the presentations :).

Anyway quick round up and my thoughts from last night meetup..

I am about to finish Chapter 3 of Well Grounded Rubyist.

The book is excellent, I really enjoy reading it - in fact as far as I can remember this is the first technical book that I just can’t put down. I finally understood some of the Ruby concepts that I failed to grasp from the previous two Ruby books that I read. At least it helped me hacking adding features to dailymile ruby gem.

Let’s talk about Object Oriented Programming for second. In a way, all of Object Oriented languages are the same: you build this class, instantiate it, make the class extends other class etc2. Traditionally also (taking from Java perspective here) - Class is a blue print of objects.

I’m going to try an analogy here. Think of a factory producing a certain product, let’s say a helmet. The product designer designed the helmet and documented in the specification (ie: the blue print) - the factory/the machine will then produce helmet as the blue print dictates. And so every individual helmets should be similar to each other. And here my analogy fails - since individual objects can have their own states - so they are not exactly the same - but behaviorly the should be the same.

In Ruby, it’s different. Yes, Class does dictate objects’ behavior - but only initially. In Ruby, you can inject behaviors into object instances.

This is an example from the book:

[ruby] mag = Magazine.new def mag.wings

puts "Look! I can fly!"

end [/ruby]

Sidetracking a bit - example like above that I really like about this book - looks silly but drives the point home clearly.

Quoting from the book:

The inheritance tree - the upward cascade of class to superclass and super superclass - isn’t the only determinant of an object’s behavior.

I am yet to see how this might be useful in designing a solution. It looks powerful and dangerous.

I have finally finished reading Agile Web Development with Rails today - three months since I have started it.

I think the book does a good job in laying down the foundation of Rails. And as explained earlier, I like the book’s approach of: build something first and learn later.

I thought after I finishing this book, I would become a Rails warrior and I can just raise my hand on Sydney Rails Meetup and say “hey folks I have coded in Rails for 3 months and finished this book, let’s talk”.  But I am still far from being a warrior, at best I am just a noob who happens to have finished a Rails book.

Why do I feel this way? Well, although I feel that the book has given me a good high level view of building application in Ruby on Rails - but I am still severely lacking in the basics. What basics that I am talking about here? There are a couple - things like Test Driven Development for instance - but to me my biggest shortfall at the moment is my understanding of the Ruby language itself.

Last week, I thought of working on solving a problem that has been bugging me for awhile. Basically I am trying to get RunKeeper to talk to DailyMile and so just like a Rubyist do - I go to github to find whether people have done something in the area.

I found out two gems that talk to RunKeeper and DailyMile API respectively and so my plan was to connect them together in a Sinatra application. The RunKeeper gem is fine, I can just use it as it is - the DailyMile gem however looks like missing a couple of functionality that I would need to make my application work. And so just like a true Rubyist - I forked the DailyMile gem and try to implement the missing functionality myself. And after looking at the source code for awhile - it dawns me that I actually need to know enough Ruby to do this!! I have actually finished reading Humble Little Ruby book a while back, but it looks like I have forgotten most of it..

And so I was brought down to earth again after flying high in hope. But not all is lost though, my copy of Well Grounded Rubyist is on the way, going through this would hopefully get me more grounded. I am also toying with the idea of approaching one of these guys to mentor me and/or attending the hack nights, there’s only so much you can learn by yourselves - I believe pair programming will get you a lot further. And my another secret wish is, to actually finish this project so I can present it on #rorosyd meetup - looks unlikely but hey..

I have also bought Rails 3 in Action which is co-written by fellow aussie Ryan Bigg - just by looking at the table of content alone, I feel this will be a meatier read compared to Agile Web Development with Rails. And yes I do hope to learn a thing or two about Engines.

So there is still a long way to go for me to become an actual Rubyist 0r RoRist - but I feel I am on the right path.

The other path is .NET - but the journey has just been a disappointment after a disappointment .. let’s just not go there…

Oh by the way - I managed to deploy my Sinatra toy app to Heroku!

And so I was up to Chapter 16: Task K - Deployment and Production of Agile Web Development with Rails 2 weeks ago. This is the last chapter of the hands on tutorial.

I was very excited arriving to this chapter as I was curious to see how Rails handles deployment. I couldn’t wait to get my hands dirty with setting up and installing parts that will hopefully form a smooth and automated deployment process.

Back on tutorial itself, the application was run on the standard Rails setup for development ie: WEBrick (Ruby’s own application server) and SQLlite for the database. Now, in this chapter, to make it more a real world like, we would deploy the application on Apache and MySQL.

It wasn’t exactly smooth sailing process, in this post, I will try to describe the problems that I encountered and how I solved (or ignored) them as well as questions that I have. Plus a short description on my failed attempt to deploy to Heroku (boo!).

One of our slave databases crashed few days ago due to some disk issues.

After everything is back to operational - I noticed that the replication has stopped in this slave. I tried to restart the replication but it was unsuccessful.

One of the tasks that I have to do at work is to perform patches. This is usually means copying a handful of files to the servers. This is not something that we do often and so the usual practice is to sftp the files manually.

But as you can imagine - manually copying files is error prone process - the risk increase with the increase number of files (and servers to copy files to). Ultimately, we want to have a “one click” patch process and of course with a “rollback” feature.

I went through Chapter 13: Task H: Sending Mail of Agile Web Development with Rails today and stumbled upon an error.

This is error that I got when testing the order email send out functionality.

[ruby] NameError (uninitialized constant OrdersController::Notifier): app/controllers/orders_controller.rb:68:in block in create' app/controllers/orders_controller.rb:57:increate’ [/ruby]

The supposedly offending code is this: [ruby] Notifier.order_received(@order).deliver [/ruby]

After some futile investigation attempts - I restarted Rails and it worked!

Just a quick note, I installed ColdFusion 9 (multi server configuration) on my Ubuntu 10.04 Virtual Machine today.

Ran the ColdFusion 9 installation file - went through the series of settings. Setting it up so that it will be connected to Apache.

And when it’s finished, I went to /CFIDE/administtrator/index.cfm as usual. When I did that - the Apache serves me the CFM as a download. This tells me that Apache was not connected properly to ColdFusion. So I had a look at the Apache directory (in my case it’s on /etc/apache2/) - and surprisingly the configuration files (apache2.conf and httpd.conf) have not been changed with the ColdFusion installation.

This is strange since I didn’t get any error during the installation. I was about to go down the path of manually editing the Apache conf file when I remember in Windows ColdFusion installation there is a utility to configure web server. I poked around the jrun bin directory and found this file: cf-connectors.sh. I ran it, it figured out that I want to set it up for Apache and 5 seconds later it’s done. I looked at the Apache conf directory again and saw httpd.conf has been modified. Happy days.

I am just wondering whether something is broken with ColdFusion 9 Linux installation - it seem to be a rather strange issue that I have here.

Unfuddle has worked fine for me - as I have often mentioned. However we know that all the cool Ruby people hang out at GitHub.

I was initially using Unfuddle for my play Rails project because I was under the impression that you can only create one repository under a free account. Turns out that I was totally wrong - you can have unlimited open source repositories. Not good if you want to keep your code secret but perfect for me as I want my code public.

So my project is now here: https://github.com/cemeng/railsMovieDepot

GIt comands to checkout the code:

[shell] git init movie-depot cd movie-depot git clone git@github.com:cemeng/railsMovieDepot.git cd railsMovieDepot mv * .. cd .. rm -rf railsMovieDepot [/shell]