Easier path construction using overloaded /

At long last I found a justifiable use for operator overloading. Recently I’ve been writing quite a bit of rake files which involved a lot of path construction, like

 path = "#{all}/#{along}/#{the}/#{watch}/#{tower}"

Noticing all those extra characters required to create the path string I realized that the / operator can used for concatenation in this specific use case

class String
  def /(other)
    File.join(self,other)
  end
end

and then we can write a much cleaner version

 path = all/along/the/watch/tower

I wouldn’t advocate the usage outside of a rake file or other path construction intensive code, but for these specific scenarios it is pretty sweet.

Also posted on dzone snippets

Posted under Programming languages

Hunger for success?

Hunger is a primitive urge that requires immediate satisfaction. It commands your thoughts and demands a short term remedy often ignoring the most obvious consequences. I find it extremely odd that it is so commonly used by the industry as a positive quality sought for in candidates particularly for management/sales positions. If hunger for success resembles hunger for food, a hungry employee (or worse manager) is likely to cut corners, to ignore longer term goals, to disregard his co-workers (or worse, his subordinates) and generally to dutifully serve the company only when it is aligned with his immediate goals. Loyalty and strategical thinking should not be expected.

Indeed hunger may foster some creativity but it can not seriously be considered as a state you want to stay in. And frankly who on earth would consider starving himself just to keep himself motivated? Hunger is basically a primal urge that can overtake your mind just like that other primal urge that assumes control over your mind. And you don’t see job descriptions looking for “horny managers”, do you (although I guess many would apply) ? This isn’t just an unfortunate choice of words – it is very much consistent with the current “set of beliefs” of the industry. I can go on and on ranting about the lack of values, short-sightedness etc. but I guess the point is clear.

Posted under Software development

Happiness Is

Happiness is finding out in the middle of a run while Since I’ve been loving you is playing on your iPod, that you can turn the volume up. Way up.

Posted under Music

A lesson from Dune

I’ve literally read Frank Herbert’s Dune dozens of times¹. Other than being a fantastic SF book it contains some pearls of wisdom that apply to many situations in our day-to-day lives.

One of the quotations I like the most is

Give as few orders as possible. Once you’ve given orders on a subject, you must always give orders on that subject. – Duke Leto Atreides, “Dune” (Frank Herbert)

When leading (ahm, and yes, managing) development efforts I’m often in a situation when a developer asks me to make a decision regarding her work. If I think however it is an issue that falls well within the territory and responsibility of the developer, I try very hard to let her decide. No, I’m not trying to avoid decision making (always a pain), I’m just trying not to “give orders” (as the Duke puts it). You see, if I make the decision I have in essence minimized the (good) responsibility areas of the developer and her ability to freely progress in the future. Now she has less space to operate in, less room to express her ideas, and she is becoming more a “doer” than a “thinker”. So overall the freedom of the team to develop as they think is right is hurt. And if that wasn’t enough, your decision on outcomes of this decision (like the evolution of that particular feature or design) will always be required, and the scalability of the team as a whole is affected.

This practice, of minimizing the decisions you make for your developers, is even harder to follow when you have a strong opinion about something one of your developer is (or is about to be) doing. For example he is about to write some fancy lock-free data-structure while you think plain old synchronized hash table will do. As long as his plans are not colliding with the overall design and the extra effort isn’t dramatic it is better to let him do what he feels is right. Above all, it is a local decision within his territory, an area which he surely knows better from anyone else. If you force him to use your solution, don’t be surprised when every little obstacle he encounter will result in him calling you to fix it for him and again you turned a thinking programmer into a robot that just follows your orders and avoids exercising his brain. A living REPL .

Indeed a mistake can be made when the decision is the wrong one. So what? Didn’t the developer and hence the team just enhanced their experience? Hey, aren’t you still making fullish mistakes? As long as the mistake is well contained within acceptable boundaries no real harm is done. It is your responsibility however as the lead to make sure such boundaries exist, so mistakes are quickly identified.

True, this practice can’t be applied with less experienced or less capable employees, but I try very hard to make sure everybody who works with me is at least capable of making smart decisions regarding her own work. Otherwise, why hire them?

¹ Incidentally, I once read that the Hebrew translation of Dune exceeds the original. That’s a bold statement to make, but even if it isn’t true, the Hebrew translation is very very good.

Posted under Software development

The Allman Brothers Band. Live.

I was lucky enough to be in NYC when the Allman Brothers Band started their annual Beacon Theater concerts run. And I was even luckier to see them perform ‘Dazed and Confused’. Yes indeed. Zeppelin’s. I’m not confused (though I was somewhat dazed by their cover). It started with ‘In Memory of Elizabeth Reed’ which evolved into ‘Mountain Jam’ from which they moved to ‘Dazed and Confused’ and shook everyone. Then back to ‘Mountain Jam’ and finally ‘Whipping Post’ [1]. Surely the best concert I’ve been to.

¹ A complete and vivid review is available here

Posted under Music

Silly little Ruby let

It occurred to me yesterday, while playing with the Ruby script I was writing, that it would be useful to have a let facility in Ruby, which would enable the following code

def foo
  # do something really exciting with the object 'master_foo'
  # now...
  master_foo.select { |x| x>3 }.let do |mf|
    puts "#{mf}, #{mf.length}"
  end
end

What is it good for? Well, instead of introducing a new local variable and using assignment to hold a temp value (like the result of the select call above), we can add a let method that simply yields itself to the block it gets. Something like

class Object
  def let(&block)
    yield self
  end
end

which enables the following silly example

"hello cruel world".split.let do |p|
  puts "The number of words in '#{p.join(' ')}' is #{p.length}"
  puts "and the second one is '#{p[1]}'"
  p
end

instead of

p = "hello cruel world".split
puts "The number of words in '#{p.join(' ')}' is #{p.length}"
puts "and the second one is '#{p[1]}'"

Well guess what? The upcoming Ruby 1.9 release a new ‘’tap’’ method is included that is similar, though not identical.

Posted under Programming languages

LOVE album

When I was 12 or so I was a real Beatles maniac. I had all of their albums, I went to Liverpool and visited Penny Lane and Strawberry Fields, I even went to visit the Abbey Road studios. Time has passed and I grow cynical and older and my music preferences have evolved to an eclectic blend of Jazz, Blues, Progressive Rock and Punk with my current Heroes (to mention a few) being Miles, Coltrane, Hendrix, the Allman Brothers, Patti Smith, Robert Wyatt, the Pixies, Joni Mitchell and so many more. It is surprising (or is it?) and refreshing to suddenly realize how great their (the Fab Four that is) music still is.

I couldn’t resist buying the latest Love album and I’m glad I couldn’t. What a sweet journey.

Posted under Music

Afraid of choosing the right language

Got to admit it, I’m a language coward. 3 times in a row I have chickened out and didn’t go with the programming language I knew was the right one for the job. Even though my recommendation would probably be accepted. And it gets better – once it was in my company, where I was the CTO (and founder). What a wimp.

It occurred to me after reading Yegge’s interesting but long post (aren’t they all) of his now (or was it then) favorite programming language. I, just like him, was and still am, on a holy-grail quest of finding the ultimate programming language. Elegant, efficient, with lots of libraries and easy FFI, concise, extensible and multi-paradigm. And guess what? I’ve found it, only to discover that even I can’t stand behind it and advocate it to my fellow (or subordinate) developers. After all, who enjoys these “not another crazy idea” look in their eyes. Just like with any leader/follower situation, the leader’s biggest fear is to lose his followers. And how easy that is when you come with this fancy, academic language which nobody really uses and will look plainly odd on their resumes. Does it really matter it implies a better programming experience? Probably not.

Ah, wonder what was that language? Well it wasn’t any language in particular although more than anything it was Scheme. And oddly, scheme is pretty familiar to many people much more so than the arcane OCaml or Erlang.

Will I ever be manly enough to do the right thing? Sometime I get carried away in dreams of an Utopian programming position when I will be expected to make bold decisions and will be given enough room to go with what I feel is right. Sounds too good? Well, doesn’t that sound like a research position? And if so, will choosing the right language is limited to research and out of scope for what is considered to be real-world? Probably and sadly, yes.

Posted under Programming languages

The sweet smell of optimization

Developers love to optimize. They love it so much they will often engage in it too early, a habit so bad it will frequently back-fire. But even the mature ones will happily pursue that ultimate sweet goal – making that code run faster or use less bandwidth, or consume less space. We all want that warm fuzzy feeling of achieving 53% improvement, and then 15% and then, pathetically, the last 2.71% .

It is probably due to the immediate and accurate feedback that optimization gives us. It is measurable and involves no smart-ass manager’s opinion or some client’s subjective impression. It is the perfect ego booster. It is also an enjoyable process during which we can test some tricks and resurrect our old passion for data-structures 101.

The flip side of it is bad, ugly, non-reusable code. That is, most of the time optimization and especially micro-optimization, will result in transforming the naively elegant structure of the code into a hairy beast that runs faster but smells. A harsh fact. I was always amused to see that programmers write “dense” code when trying to optimize a lot. That is, for some odd reason the variables names are always a single letter, with less spaces per line sometimes even fitting multiple statements into a single semi-colon separated line. As if by taking less space the code would run faster.

Unless of course you have meditated on it long enough to understand that there is another, even more elegant way of solving the problem at hand. And not only is it elegant it is simpler and faster. This is macro-optimization and is the true reward of programming—solving a problem the second time after reaching enlightenment. Sweet indeed.

Posted under Software development

MyPDA

For the last 2 months or so, I’ve been experimenting with my own version of the hipster PDA . Mine is rather flat, that is I keep no separation into projects. There are 2 stacks of cards one for todo lists and one for meeting summaries. The later doesn’t follow any conventions, I just take notes there (and the limited space forces me to be more concise; hurray to that).

With the todo list I did try to come up with some structure. Every line starts with a name of the person in charge¹. The line is slightly indented so I can put one of 3 marks next to it:

• ‘v’ when its done
• ‘d’ when it is deferred
• ‘x’ when it is obsolete

Every “closed” line is marked by one of the above marks and is highlighted (I picked it up somewhere from 43folders). This way it is very easy to see what are the opened tasks.

A task becomes obsolete when I realize it was a stupid idea to begin with, and what-the-hell was I thinking when I jotted it in the first place. I love these tasks. A task is deferred when it stays too long as the only open one in its card. Put it differently it is the only non-highlighted one in its card. Since I can not make it obsolete (darn), I move it to the latest card. This sounds a bit tedious but practically it isn’t as your motivation to close those tasks which you keep dragging around increases.

I find my self scanning all the cards a couple of times a day, looking for open tasks and picking up those which seems to be more relevant or more annoying (depending on my productivity meter). Again it sounds tedious but it isn’t. This linear process makes it harder to neglect tasks and thus is pretty helpful. For me this life hack works which is more than I can say of any other trick I’ve tried.

¹ Believe it or not they let me supervise programmers ;)

Posted under Life hacks