Now that being said - this week, I managed to get a little bit happier by installing a dark background/theme.

First of all - I came across this plugin (and site) that has a repository of themes for Eclipse, the site is Eclipse Color Themes. Follow the instruction on how to install the plugin to your Eclipse/Flash Builder: plugin install

That bit is straight forward - now if you try to apply any of the dark themes, you’d notice that something isn’t quite right:

Now, I’m not sure, why the syntax highlighting isn’t updated straight away. But fortunatelly this is an easy fix. Open Preferences and search for the word syntax, on the left pane - select Flash Builder > Editors > Syntax Coloring. Go to MXML on the right pane, and go through the elements and hit Apply button - this somehow activates the syntax coloring of the theme.

Final result - a less sucky Flash Builder!

Firstly, we pair programmed until we worked out the general direction for the implementation and then I took over the implementation while my colleague working on investigating the data source.

This report work forced me to learn more about ActiveRecord scope. What’s an ActiveRecord scope? According to Rails guide:

Scoping allows you to specify commonly-used ARel queries which can be referenced as method calls on the association objects or models. With these scopes, you can use every method previously covered such as where, joins and includes. All scope methods will return an ActiveRecord::Relation object which will allow for further methods (such as other scopes) to be called on it.

These two Rails guides on ActiveRecord helped me quite a bit:

• Active Record Querying
• Active Record Association

Given that our report query is a little bit more complex than usual - it was quite difficult to get the scoping right. But after a lot of trial and error and re-reading the guides so many times - I managed to get the code that I am happy with.

I also found out about HashWithIndifferentAccess - by accident.. Having worked with Rails for awhile, I was under the impression that a string key for a hash is interchangable with a symbol key.

This is where I got Ruby and Rails mixed up. Lucky before I spent too much time ripping out my hairs - my colleague told me that I was thinking about Rails’ special hash not Ruby’s normal hash. This magical hash is called HashWithIndifferentAccess. Thank Rails. Anyway code speaks a thousand word:

1
2
3
4
5
6
7
8
9

>hash = { "hello" => "world" }
>p hash["hello"]
=> "world"
>p hash[:hello]
=>nil
>hash = HashWithIndifferentAccess.new
>hash["hello"] = "world"
>p hash[:hello]
=> "world"

There are just so much to learn and the wealth of information out there can be overwhelming sometimes. It’s not just the language that I need to learn but also the pratices (BDD, TDD), the frameworks (Rails - y u so black magic?), patterns (Ruby is NOT Java).

But that’s OK - this journey will take me longer than I expected and I can live with that. What I really need is focus and ignore all distractions.

What are the distractions? Latest trends - looking at you JS stuffs - Node, CoffeeScript and friends. Information overload - I have taken steps to fix this:

• Unsubscribed from ColdFusion bloggers feed and mailing lists - not relevant for me at this point of time
• Trim the noise from Twitter by unfollowing people - wasted a lot of time reading tweets that I don’t care from people that I don’t know. I intend to cap my follow number to 100.
• Filtering Ruby information to my level - for example: some of Ruby Rogues episodes (metaprogramming) is just beyond my comprehension at this time.

Focus on what specifically? Well, Ruby of course! Goalwise, this year:

• Getting better at TDD especially getting better at writing specs
• Understanding Ruby and OOP in Ruby better
• Understanding Rails better especially ActiveRecord (maybe enroll in owning rails course)

As I have been trying to blog during my commute, I found that WordPress blogging with little internet access is just painful. Main culprit is the bloated wp-admin and oh that dreadful TinyMCE editor.

Why can’t I just use an offline editor? Well, I can - in fact back on my Windows days, Live Writer is the primary tool for my blogging. But I am not on Windows anymore, and I couldn’t see anything on Mac that comes close to Live Writer.

WordPress has just become too complicated and too distracting to me (with thousands of plugins and themes to choose from). Also I got lots of spammers trying to find some holes on my WordPress installation - evidence: 80% of traffic goes to wp-comments.php.

I then decided to give Octopress a go. Some things that I like about Octopress or static blogging platform in general:

• Better offline experience. You’d always have a local version of your blog to play around.
• Simpler platform, no database, simple rsync for deployment.
• Complete control - no need to rely on crappy WYSIWYG editor.
• Octopress is based on Jekyll - both are Ruby projects. A language that I love and use daily - I don’t have to mess with PHP anymore.
• Writing blog posts on vim - awesome!

I think I will also not bother with comments at this point.

At the end of the day - I just want something simple, Octopress seems to fit the bill.

But company is all about bottom line right? Focusing on the individuals want seem inappropriate. Not necessarily. Paraphrasing my previous manager’s statement on our first one on one session: we (you and the company) will get the best of each other where there is big intersection between what the company wants to achieve and what you personally want to achieve careerwise.

A quote from Tamer’s post:

People move on, and the team as a whole constantly grows and evolves with those changes. This is healthy, as long as it’s strongly embraced.

Embraced is the keyword, do expect people to move on, help them to go where they want to. Have strategies in place to deal with changes. Avoid over reliance on your current developers.

Do it right - know what your developers aspire to, work out how you can help them in a way that is also bring benefit the company, look after them and keep them motivated and challenged, so that they will stay long and happy. But also always have a succession plan - employees are temporary.

A manager with this insight is worth hiring and working for.

Now some pictures.

Below shows my lovely MacBook Pro (very nice machine and oh working on Mac is sooo much better compared to Windows). The company looks after me very well, they provided me with brand new 24” LG monitor. I use MacVIm for my Ruby on Rails coding (a joy) and Flash Builder for Flex coding (don’t like Eclipse - so sluggish). Lately, I’m using my MacBook Pro in clamshell mode (i.e.; just using the secondary display and keep the MacBook closed) - I found the large screen area is enough.

My colleague collection of books - bah, I didn’t notice that my iPhone camera was out of focus, so sorry for this blurry picture. There are a LOT of Ruby and Rails books here. And he’s got more digital books.

Ah more books, the first two belongs to my colleagues, the rest belongs the rest belongs to me. Oh, I love Eclipse mints!! My previous colleague got me to it and before long almost every developers in the office were chewing mints on daily basis.

Commuting to work involves bus trip to the Central Station, followed by train from Central to Blacktown and another bus trip from Blacktown station to the office. All up it’s about 1h 40m one way. Previously work was located conveniently 8km away from where I live, which normally takes 30-40 mins commuting by bus. So naturally, at first it was a major concern for me and my wife - we weren’t sure how this would affect our family life.

However after been doing it for 4 weeks now - it’s actually not too bad, in fact it works quite well.

First of all, the whole longer time commute works because of:

• Shorter work hour (9-5) as opposed to 9-6 previously
• Flexible working hours arrangement.

Because of the earlier finishing time - I ended coming home about the same time as before. I do have to leave home 45 minutes earlier than before though - so morning is more hectic than before. But there’s a solution to that. This is where point no 2 kicks in - the folks there are quite relaxed about starting time and even with how many hours per week. I don’t have to work 37.5 hours week if I don’t want to. Since I am a contractor I got paid based on the hours that I worked.

I also found that 9 to 5 working hour (with 30 mins lunch + 2 x 10mins coffee breaks) feels right with the way my body and mind work. I am usually quite intense when coding and my limit is usually around 5 hours after that my concentration deteriorates and I won’t be as productive. That’s why working long hour (especially overtime) will not work with me - I will take note to myself to never take a role that requires long working hour (if possible).

Another plus point - telecommuting time gives me opportunity to be efficient with my time. Now I have about an hour a day in train that I can use for something productive. Naturally, I use the time for my personal development time mostly - now the good thing about it is, when I got home I am really done - I have done both my professional work and my own personal learning - so I can just wind down without feeling any guilt.

Now the learning bit is very important as I am working with 2 technologies that I have limited experience in (Flex and Ruby). My learning so far take in the following forms:

• Watching Flex in a week video training
• Watching various screencasts in particular Vimcasts and Railscasts
• Coding Ruby - doing Ruby koans, just hacking around, playing around with IRB/PRY
• Reading Ruby and Rails books - still reading Well Grounded Rubyist.
• Doing some work, very rarely that I feel the need to do extra work outside the 9-5 block (which I do for free and I don’t mind doing since it’s helping me with my personal learning anyway)

Beside learning - I’m also using the time to work on the backlog of my (non-technical) books to read - the latest being this one.

The move is kind of significant point in my working life - as I have finally transitioned from being primarily a ColdFusion developer to something else (but that’s for another post).

It was a blessing to be working with folks at Gruden, made quite a few good friends over there whom I am really keen to stay in touch.

Interestingly, I was kind of stumbled upon the role at Gruden. At the end of 2009 - I was burnt out quite badly from my previous employment that led me to taking a few months career break. I was trying to cross skill myself in Java and Ruby on Rails at that time and wasn’t really looking for a pure ColdFusion role.

However, my ex-colleague was interviewing for a .NET role with Gruden and he mentioned me to Gruden. Long story short, I was offered a 3 month contract position. And yes it is a ColdFusion contract role - but I thought it’s only for 3 months and I have heard good things about Gruden before.

After 3 months - we liked each other and the contract became a permanent gig.

I can confidently say that they are one of the the best guys to work with if you are a ColdFusion developer. The ColdFusion applications that I worked at at Gruden are well architected - with best practices in mind. OOP all the way through - with Mach-II, Reactor and ColdSpring as the foundation. It was very refreshing to me as developer - that I didn’t have to convince and fight people about the benefits of OOP (as what I had done at my previous jobs).

It was interesting to me as well as I had the opportunity to be the lead developer in some projects, doing lots of analysis, costing (which I don’t particularly like), training and mentoring - AND handling support issues. It was full on - but I learned heaps in the process.

I will miss the bi-weekly development meetings (when we take turn to present on interesting topics), the soccer competition, the coffee, the scenic Circular Quay, the ping pong and the pool games - and the people of course!

So bye for now (professionally). If you are looking for ColdFusion gig - I do recommend get in touch with Gruden, they are a bunch of creative, honest, friendly and hardworking people.

I did a 5 minute book review on Well Grounded Rubyist - yes the book that I have always talked about in this blog.

Back to the lighting talk - I must have at least put in 10 hours of preparation on it, yeah so much effort just for such a short talk. But I am glad that I did it - I’ve learned a lot both on the preparation and on the delivery. This is my first user group presentation ever - although I have done a couple team pressos for companies that I worked for.

My aims for the talk were:

• Sharing what I like about the book aimed especially for the new people (to my disappointment - not that many new people that night).
• Making people who are new to Ruby welcomed. At least they’d know that not all of them who come to the meetup is expert.

Some of the things that I’ve learned:

• I need to speak clearer (even with my thick Indonesian accent)
• I need to speak slower and maybe less material for a lighting talk.
• My slides looked terrible compared to other presenters.

In the subject of new people - I think I kind of work out how I want to be involved in Ruby community. And that is to help new people be involved in the community and help them learn at the same time.

This the place would look like if I am in charge of the company (or at least for the development department) and I am given unlimited freedom and unlimited resources to realize it.

The place would look like this: https://gist.github.com/f63f2d60f2bf270dfbb5

I intend to refine this as continue on my career and I will expand some of the points through this blog.

That’s how the dream work will look like - how about yours? What’s your dream work look like? I dare you to dream :)

When I looked at the tasks’ description - I realised Test Driven Development (TDD would be a good fit to approach them. Another plus for me is, I have never used TDD before - although I have been reading and hearing it quite a lot, so it is a good opportunity to give it a try.

One of the tasks is to write a cheque writer program - a program that converts a dollar value in number to its text representation (if it were written for a cheque), for example: given an input 2.50, the output should be a string “two DOLLARS and fifty CENTS”.

I chose to implement the solution in Java since I’m quite comfortable with it. And I am using JUnit to assist with TDD.

By employing TDD - I was writing my unit tests BEFORE I wrote the implementation.

Below is a snippet of my JUnit test (the first time I wrote JUnit test for a long time - so definitely can be done better):

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
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112

package org.tjandrawibawa.testcase;

import org.junit.Test ;
import static org.junit.Assert.* ;
import org.tjandrawibawa.task.*;

public class TestChequeWriter {
  ChequeWriter writer = new ChequeWriter();

  @Test
  public void testSimple() {
      System.out.println("Test input: 1");
      assertTrue( writer.write("1").equals("one DOLLARS"));
  }

  @Test
  public void testSimpleDecimal() {
      System.out.println("Test input: 41.01");
      assertTrue( writer.write("41.01").equals("forty one DOLLARS AND one CENTS"));
  }

  @Test
  public void testHundreds() {
      System.out.println("Test input: 151.59");
      assertTrue( writer.write("151.59").equals("one hundred and fifty one DOLLARS AND fifty nine CENTS"));
  }

  
  /* BEGIN: Boundary Tests */
  @Test
  public void testBoundary1() {
      System.out.println("Test input: 99.99");
      assertTrue( writer.write("99.99").equals("ninety nine DOLLARS AND ninety nine CENTS"));
  }

  @Test
  public void testBoundary2() {
      System.out.println("Test input: 100.99");
      assertTrue( writer.write("100.99").equals("one hundred DOLLARS AND ninety nine CENTS"));
  }
  
  @Test
  public void testBoundary3() {
      System.out.println("Test input: 999.99");
      assertTrue( writer.write("999.99").equals("nine hundred and ninety nine DOLLARS AND ninety nine CENTS"));
  }
  
  @Test
  public void testBoundary4() {
      System.out.println("Test input: 1000.99");
      assertTrue( writer.write("1000.99").equals("one thousand DOLLARS AND ninety nine CENTS"));
  }

  @Test
  public void testBoundary6() {
      System.out.println("Test input: 999999.99");
      assertTrue( writer.write("999999.99").equals("nine hundred and ninety nine thousand, nine hundred and ninety nine DOLLARS AND ninety nine CENTS"));
  }
  
  @Test
  public void testBoundary7() {
      System.out.println("Test input: 1000000.99");
      assertTrue( writer.write("1000000.99").equals("one million DOLLARS AND ninety nine CENTS"));
  }

  @Test
  public void testBoundary8() {
      System.out.println("Test input: 9999999.99");
      assertTrue( writer.write("999999999.99").equals("nine hundred and ninety nine million, nine hundred and ninety nine thousand, nine hundred and ninety nine DOLLARS AND ninety nine CENTS"));
  }
  
  @Test
  public void testBoundary9() {
      System.out.println("Test input: 10000000.99");
      assertTrue( writer.write("1000000000.99").equals("one billion DOLLARS AND ninety nine CENTS"));
  }
  
  /* END: Boundary Tests */
  
  /* BEGIN: Test failures */
  @Test
  public void testAmountNegative() {
      System.out.println("Test input: -1");
      assertTrue( writer.write("-1").equals("-1 is invalid - valid amount is between 0 to 2 billions dollars (inclusive)"));
  }

  @Test
  public void testAmountGreaterThanTwoBillion() {
      System.out.println("Test input: 2000000001");
      assertTrue( writer.write("2000000001").equals("2000000001 is invalid - valid amount is between 0 to 2 billions dollars (inclusive)"));
  }

  @Test
  public void testDecimalPrecision() {
      System.out.println("Test input: 1.222");
      assertTrue( writer.write("1.222").equals("1.222 is invalid - only up to 2 decimal places is accepted"));
  }

  @Test
  public void testNonNumberInput1() {
      System.out.println("Test input: 1.22.2");
      assertTrue( writer.write("1.22.2").equals("1.22.2 is not a valid number format"));
  }

  @Test
  public void testNonNumberInput2() {
      System.out.println("Test input: xx");
      assertTrue( writer.write("xx").equals("xx is not a valid number format"));
  }
  /* END: Test failures */

}

The steps that I went through to solve the task:

• Scribble the solution in paper. I found this practice generally helps my thinking a lot.
• I then write the skeleton for the solution - which is mainly a class with methods that don’t do anything as yet.
• I then write unit tests for the main method in JUnit.
• I then write the implementation, run the test and repeat until I got all green (all tests passed)

I found that this approach worked very well for this particular task. Especially the boundary tests exposed the wrong approach that I took when developing the solution.

Refactoring has also become very easy as well.

While I am not convinced writing tests first and code the implementation to the test is applicable and beneficial all the time. One thing that I am sold of is: having test coverage is awesome. Particularly with refactoring - there is no way that you can confidently refactor without having a good enough test coverage.

So today - I made a pull request and hopefully it will be accepted. But accepted or not - that’s not really the point - I am just happy at the moment that I have made my first contribution to an open source project.

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.

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).

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 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.

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.

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

Sneak peek into Westfield and Ruby in the enterprise by Lightning Dave Bolton @lightningdb Dave explained challenges running Ruby in an enterprise setup (Westfield being the enterprise). Not only technological challenge but also organizational as well - enterprise = more internal stakeholders to take into account.

One of the quotables quote of the day was “Everyday we are committing legacy code” - so as developer we should write code with the mind of people who will maintain our code down the track.

One point Dave mentioned that is close to my heart is: in order for Ruby to continue to flourish, it needs new developers coming to it (exactly my thoughts with the problem of ColdFusion in Australia).

Test Driven Search Development by Andrew Harvey @mootpointer

Andrew explained the test harness (test tool?) that he built to test search result. In essence (I think) - his tool does comparison of search result in development and search result from production. The point of the comparison is to see whether the tweak on the Solr config (the engine that they use) produces better matches or not.

It is quite interesting to me as at work, we have been thinking of moving away from Lucene to Solr - with a testing tool such what Andrew presented, we can at least test the search result before and after.

There be magic in Rails (multiple dynamic per instance database connections) by Mikel Lindsaar @raasdnil

Mikel shows how he built an app that can connect to unknown number databases with unknown schema (not the usual Rails app where you give the database config to Rails beforehand).

Nice to see ActiveAdmin in action as well - been wanting to try it out.

Unicorn by Richard Heycock

A passionate presentation on why Unicorn rules - Unicorn follows Unix philosophy - do one thing and do it well. It looks like Unicorn is really nice from Sys Admin point of view compared to Passenger for instance.

Ruby metaprogramming… by Nicholas Jefferson

I was very tired by this point (this was the longest RORO for me) so the following might be wrong!! - but I’ll try.. Nicholas presented his markup project which translates the markup to Java bytecode - this has proven to be way faster than Markaby and closer to Erubis (?). Nicholas prefers metaprogramming that translates to something readable as the product..

All in all a very nice night - managed to drag Filippo Vitale along and I think he had a great time too (he even asked me to go to the hack night with him!). Got to know few people as well - which is great.

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 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!