I wasted better part of last week on building my own multiselect control in Backbone.js. After some hard crashes I’ve decided to give existing plugins another twirl. Here is my overview:

jQuery UI Multiselect

jQuery UI Multiselect

Pros:

• Mature
• Drag & Drop is cool

Cons:

• Crude search
• Awkward to select (click works only on +, - signs)
• Needs to load full data set

Photo credit: Wikipedia

It’s a fair question. Imagine you want to solve classical allocation problem where you need to divide sum on parts:

90/3 = [30, 30, 30]

Of course you need to accommodate for the rounding on two decimals:

100/3 = [33.33, 33.33, 33.34]

Few weeks ago I did a similar exercise as a part of coding kata. What I got was a small module under 30 LOC and with less than 5 lines methods. So it was pretty well refactored already with the TDD driving my design. That is certainly big part of writing test (organic design), but I don’t want to write about that in this post.

Photo credit: stopnlook flickr

Not testing at all is at one side of a spectrum, at the other end is testing everything. Those two are easy picks to rule out since the truth is almost always somewhere in between.

I remember reading about one physicist building his own supercomputer. When asked why he did that he said something like this:

I could have just given 2M dollars to IBM. They have a great team and they would build a great supercomputer. But this way I get more bang for a buck.

This is a major issue. Getting the most bang from your testing buck.

In the small database that contains about one million records the need for some reporting arose. Since the system will work for at least 5 more years I was reluctant to just “winging it with recapitulation tables and some SQL” approach.

The green pastures of OLAP have lured me long enough. My hopes where high, and my knowledge non existing. This is a tale of a man vs. the elements.

Lately pet peeve of mine is how to make small methods look more elegant. One idea was to use “indentation” for implicit end of small methods. Big problem with this is that this is only a wish. I was forced to just cram the method to one line and curse the destiny. For a while I was torn. I loved cramming small methods and hated the impact on readability it had.

Couple of days ago it came to my attention that you can use define_method to get a job done. If we start with this:

def stupid?
  @pretty ? "NO" : "YES"
end

This article will sum up my experiences with reddit and why I think it is not worth it to bother with. It all started this summer. Somebody has putted me on a HN and I went front page.

7k visitors was more that my tender brain could comprehend :)

It’s easy to say ‘don’t put your own stuff’. BUT when you have zero readers (like me) it’s easier said than done.

Over the course of time I’ve noticed three peculiar Ruby behaviours. I am not saying these things are good or bad. They are a bit odd/unexpected, mostly neat and always good to know.

I like small methods. Small methods make comments unnecessary and allow me to describe algorithms in a way I will understand in couple of months when bug strikes. They allow me to develop domain and talk about domain in the code. There is just one thing bothering me:

The excessive presence of end keyword.

I’ve just read an excellent article about refactoring rcat in Rubies in the Rough. If you are not subscribed you should be… I couldn’t resist to take a swing at it and refactor Display class since thats where most of the action is happening. In one line rcat is supposed to behave as Unix cat command for some basic cases.

Majority of people I know of that are great with computers tend to be not so great at sports. In tender years of their youth they are usually picked up the last for all sorts of sports activities. I believe this actually helps their computer skills as they get to spend more time with computer. After all everybody likes doing what he is good at. I’ve noticed couple of distinct phases.