I have been asked that question and have asked the question myself a couple of times. There are so many different technologies that I can choose to complement my current skill set, why Ruby?

Well, I came across an interview from EngineYard blog recently - Chicks That Rip: Ines Sombra.

Ines’ answer is almost exactly word for word of my own answer to the question:

What attracted me most to the Ruby on Rails community is how bold it is. This community is not afraid to experiment and innovate. What I find especially interesting is the prevalence of polyglot systems and cutting-edge data store solutions. Databases are put to the test in Ruby on Rails, and these applications are defining the future of how systems will be constructed. It’s amazing. …

The community, the rate of innovation and polyglot systems - this gets the geek in me excited.

And so after contemplating for half a year or more - I finally decided that it’s time to get a Mac.

I bought the Feb 2011 model - second hand from Ebay and it looks like to be a good purchase so far (well it’s only been few days). To sidetrack a bit - it was quite scary experience buying something expensive from Ebay - it took three weeks for the thing to arrive due to seller being slow in posting, AusPost messed up (or maybe it was the seller’s fault all along), the item had to be returned to sender, and then re-sent back to me - just a mess!! But thank God - it’s here.

And yes - people were asking why - even today someone at work compares Mac with Dell - which he thinks it’s the best value for money. Well, everyone is entitled to their opinions I guess.

To me the reasons for getting a Mac is as follow:

• I just want to see and to experience what the hype is all about. I have been to user group meetings and conferences and Macs dominated the development scene - why???
• Still related to the above, Mac seems to be the de facto platform for Ruby coder (although apparently in Japan - Rubyists are more likely to be on Windows). One of the famous Ruby IDE - Textmate runs only Mac.
• And hopefully sometimes in the future (I am not holding my breath though) - I will get into native iPhone/iPad development as well.

Now the OS war - some people are just M$ haters - I am not, I have been using Windows for ages and things have been improving, in fact Windows 7 is pretty good. But I have never been comfortable with Windows as a platform for development. I mean I use it at work because I need the other M$ softwares like Outlook, Word and Project - but I won’t do my personal coding on Windows.

For fun coding things - I have been using Ubuntu. This is especially true for my Ruby and Rails learning. And I am quite happy with it - for dev-ing Linux is certainly way more enjoyable than Windows.

I’m quite excited to see how my experience will be different with Mac OS. As of now, I am looking into settling to an IDE for my Ruby dev - Sublime Text looks to be most likely candidate at the moment - followed by MacVim. A couple of recommendations from friends: TextMate (of course), TextWrangler (BBEdit).

This is an attempt on consolidating my thoughts on Ruby’s self, taken from Well Grounded Rubyist chapter 5.

Another crucial point of Ruby to understand is the notion of self. Self is used to refer to the current object or the default object at a given time. At every point of your program there is one and only self.

Self inside Class and Module is straight forward. Self in method is also not too hard to understand, but you need to understand the context of the method.

Method can belong to class, self in method class will return the class object itself (remember that class IS object in Ruby). Method can belong to an instance of a class, self in that context will surprise2 return the instance. Method can be a singleton - in this case, calling self will also return the instance of a class.

Another point about self is: it is the default receiver of messages (see the code snippet below - it is explained there).

Below is code snippet that I hope illustrate the points above (stitched together from the examples in the book):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

class C
  module M
    puts "Inside module C::M"
    puts self
  end

  # class method
  def self.stuff
    puts "Inside class method"
    puts self
  end

  # instance method
  def stuff
    puts "Inside instance method"   
    puts self
  end
end

# calling the class method (and module)
C.stuff
C::M

# calling the class method
c = C.new
c.stuff

# singleton method
def c.stuff_it
  puts "Inside singleton method"
  puts self #instance C
end

#calling the singleton method
c.stuff_it

# Self as the default receiver of messages
class B
  def self.no_dot
    puts "self no dot"
  end

  #no need to explicitly specify self.no_dot - self is the default receiver of no_dot message
  no_dot
end

And here is the output:

1
2
3
4
5
6
7
8
9

Inside module C:
C::M
Inside class met
C
Inside instance
#
Inside singleton
#
self no dot

I had the pleasure of attending my first ever Sydney RORO Hack Night last night and it was a great experience for a newbie for me. Place, pizzas and beers were provided by the kind folks at Ninefold (@lachlanhardy was the host of the night) - thanks guys!

I went there with Filippo and Ronaldo who are (ex) colleagues and friends. I also finally met Glenn (@glennmartin76) in person.

Glenn like me is new to Ruby - not sure how he found my blog and my RORO meetup post - but he did. And he contacted me via my blog asking questions about Sydney RORO. And then we exchanged emails couple of times - he’s got some good questions about all things Ruby (note to self: I should create a list of things that helped me get started and “stay” motivated to learn Ruby).

Hopefully I did some part to encourage him to come on the night.

Ok about the night itself - the night began with food and beers and casual chat.

I took a quick glance on people’s machines - the three newbies have Windows laptop (hey I do my Ruby dev on Ubuntu VM - so not that bad!) and the rest is on their shiny Macs.

And then Lachlan asked if people have interesting projects that they are working on or need help on. Some people put their hands up - some interesting stuffs being mentioned - Backbone.js, MongoDB, XML/XSLT(?) etc.

I then put my hands up for my dailymile-ruby gem fork that I am working on, I basically wanted to someone with more Ruby experience to review my code and to provide some feedbacks.

And I was fortunate enough to get Ryan Bigg (@ryanbigg) to help with that. Working with someone with Ryan’s experience was really cool - I got some good feedbacks and good tips on coding standard as well.

I got to ask questions like how would certain things be done in Ruby, like the good practice for raising exceptions, parameter type checking (I am a bit paranoid with type checking coming from ColdFusion/Java background).

I then asked Ryan on how to build a test for the feature that implemented. I did actually have a stand alone Ruby script to test but I wanted to make a proper Test Unit out of it. And he showed me exactly how to do that - and as bonus point I was pointed to to WebMock which looks like to be very handy for API testing.

So hopefully another few hours worth of work and my work is ready for a pull request (oh that elusive first pull request.. ).

I then sat with Damien (@its_damo) - he was working on fixing a bug on his somanyfeeds app and he was kind enough to explain how he implemented the app. I was quite impressed on the effort and the thoughts he put on this - things like JavaScript minification and fingerprinting, caching and queues using RabbitMQ.

Somanyfeeds is an Sinatra app by the way and he implemented some of Rails-inspired features to his app. Do check the app’s code out on GitHub - he showed me some documentations that he’s written for the app which looks like a solid piece of work as well.

And just by talking to him - I got free lesson on Ruby symbol. I actually haven’t got to the part of learning symbols yet and I always wonder what they are. Ruby symbol behaves like Java string - they are immutable while apparently Ruby string is not.

At some point - an accident happened - Ryan accidentally spilled beer on Ron’s Mac. But Ron was complaining about his old MacBook before the hack night started - so I am slightly suspicious that this is staged so that he can upgrade his Mac :)

I then sit with Filippo looking at his Python project. He kept on telling me not to mention Python loudly - and I don’t understand why :) Filippo was working on an app similar to athlinks.com. Got introduced to TipFy library and stuffs.

Went home around 10pm - some people were still hacking away. So yeah I had a great time last night - meeting great and friendly people from the Ruby (and JavaScript) community.

I think if you are new to Ruby - all the more reason to attend the hack night.

Photo from the night courtesy of Lachlan.

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.