Thong Kuah's blog

StrengthsFinder is an amazing book, and an assessment tool that helps you discover your strengths. Its central concept is that you should focus on your strengths, not your weaknesses. I was introduced to it at the Summer of Code (NZ) program several years ago. The concept of focusing on strengths was just brilliant. This really reminded me of my game playing style, especially in RPGs, where you have to increase the levels and skills of your character(s) in order to be able to fight enemies that pop up with increasing difficulty and toughness.

Monthly collection of Ruby links that I’ll regret forgetting about: My 10 Favorite Things About the Ruby Language � Katz Got Your Tongue?http://dablog.rubypal.com/2009/1/14/10-things-to-be-aware-of-in-moving-to-ruby-1-9http://dablog.rubypal.com/2009/1/16/son-of-10-things-to-be-aware-of-in-ruby-1-9http://www.manning.com/black2/Upgrade to Rails 2.3.4, 2.2.3 (Security Release) Riding Rails: Gem Packaging: Best Practices

ActiveRecord::Base#find_each is an awesome idiom for batch processing large sets of data. It combines the neat DSL of ActiveRecord and allows you to operate at the level of the individual item. So, imagine my surprise when I debugged my code and discovered that find_each introduces a scope into ActiveRecord calls within the block. Demonstrating by example: Slam.find_each(:conditions => {:value => nil}) do |slam|#…. Slam.find_by_key(slam.key) #Find related key #However, in effect becomes Slam.find_by_key(:key => slam.key, :value => nil)end Looking at the SQL in the logs, I expected to see: select * from slams where key = ‘abcde’; Instead I saw: select * from slams where key = ‘abcde’ and value is null; It took me fifteen minutes to check and verify there is no code that should be generating that SQL, so the next candidate was find_each. Lo and behold, it was. Turns out find_each is using with_scope. Looking around, there are already some bug reports for this behaviour: https://rails.lighthouseapp.com/projects/8994/tickets/2791-activerecordbasefind_in_batches-puts-a-with_scope-into-the-block-that-is-executedhttps://rails.lighthouseapp.com/projects/8994/tickets/2227-batches-conditions-for-each-are-applied-to-each-modelfind-within-the-each-loopQuestion: Is this intended or this a bug? I think, given the “side-effect” feel of it, it’s a bug Update: I have reviewed one promising patch to fix this. Needs one more person to review and approve this patch!

I found several interesting things this month. Super fast SSD hard disks 21GB pirate bay indexSingularity in thirty years Ok, the last one is really out there, but it points the way. Imagine the whole sum of human creative endeavor (at least the popular ones) indexed in just 21GB. All we need is just some sort of instant hash expansion for that 21GB (and 20 more years of PC power advancement). And so on and so forth. Value of data or content would be worth next to nothing. Will that happen? Probably, after flying cars.

Someone always asks this question - how do you check types in Ruby? (*Hint: Ruby use dynamic typing) This typical newbie question would ask this and be answered with various levels of helpfulness - typically none - sadly. However this thread is just beautiful in its helpfulness. http://groups.google.com/group/comp.lang.ruby/msg/eb4b49a511e44be6?hl=en What happended snarkiness, or Slashdot / Youtube style comments? All this helpfulness must come from somewhere. I blame Twitter.

Hacking for the greater good : the good being helping to free up important government information. A Barcamp and Hackfest was held just this weekend, in the last days of August. I participated in the Hackfest, which was held at the amazing Southern Cross Bar. Great food and nice private room made for a good environment for coding. The Hackfest was a bit more structured than previous events I have been to, but I’ll say this had a positive effect of helping people choose what and who they wanted to work with. There were some suggested ideas from the Barcamp, but people were free to work on their ideas too. Here are some projects that was worked on at this event : http://github.com/opennewzealand/scavenger/tree/masterhttp://wiki.open.org.nz/What_Do_They_Know_NZhttp://github.com/wombleton/whatdotheyknow/tree/master And many more, which is listed at: http://wiki.open.org.nz/Hackfest It was great collaborating and working with great people and programmers. Hope to do this again very soon!

Update: I have found a nicer way of doing autocomplete. Basically, use the string type with the “starting_with” method. See this ticket comment. Solr is really nice search engine which has the added advantage of being able to return items that you put into the search engine, unlike say, sphinx (which is really fast but only returns the document id). However, Solr is very complex. Thankfully, there is a very neat ruby abstraction for Solr, called Sunspot. Given I needed to do autocomplete on it, i.e. “query*” type stuff, I had to fork Sunspot. Here is the relevant change I made to enable wildcard searches with Sunspot: http://pastie.org/592897 For those interested in how this works, it uses the q.alt parameter as Sunspot uses the rather “user-friendly” DisMaxRequestHandler, which ignores “*” characters.

Let’s start simple. Here is a situation I have encountered more than once. We have this big long class or method, and embedded in it are several blocks of code, all commented out. def some_method(a) do_something(a) calc_another # wow # do_do # calc_calc # zcalc(z) end What should I do? Given the code is version controlled, I would happily throw it away. The code is commented out and will have no effect whatsoever on any program or user. Another programmer may be affected by it, though. So, make a note in the commit message : “removed commented-out code in such-and-such method. haven’t been used in a while” Caveats apply for very large blocks of commented-out code, or it has warnings not to remove. But these can be easily solved with some programmer-to-programmer communication. There are other things that can be theoretically thrown away, such as: Once off experiments / prototypeQuick and dirty functionsGenerally ugly code in the project However, each of this has it’s own set of code, teamwork and business-related problems. Yes, there is the urge to reduce mental strain - working what does piece of code do - which leads to “let’s rewrite” moments. I would love to know what a programmer or a team can do in each of this instances. I have some ideas, but these will be topics for later discussions. * I have always wanted to write down some of my experiences as I embark on a programming life. This is my starting contribution.

Consider this question from Riding Rails: Community Highlights: IronRuby (emphasis mine). Matt: Are there any limitations that our readers should be aware of before starting to develop on IronRuby? Jimmy: The main limitation is that IronRuby does not support any of the C-based Ruby libraries, and only after 1.0 will we consider building an interop layer between the Ruby C API and IronRuby. In the meantime, people have been porting their favorite C-based Ruby libraries over to C# so it can be used from IronRuby, like Hpricot. While this seems like a large limitation, most of the C-based libraries Ruby code depends on have an equivalent API in the .NET framework, which IronRuby has direct integration with, making either using directly or porting really easy. For example, the Rails app I showed at RailsConf did image resizing directly with the System.Windows.Drawing APIs rather than ImageMagick. If your code does not depend on anything outside of the Ruby standard library that is C-based, you should have no problems. Take a look at the documentation for running Rails on IronRuby to make sure things go smoothly: http://ironruby.net/Documentation/Rails. Sure reminds me of Embrace, extend, extinguish. I’m sure the interop layer is being considered, but the absence of it will tie IronRuby to .NET and away from Ruby. I hope the interop layer will be done soon.

I did a Git workshop for Summer of Code NZ students. Here it is: Code Management View more documents from kuahyeow. Full details at the Summer of Code blog: http://blog.summerofcode.co.nz/2009/07/31/code-management-git-workshop/