I’ve been using Vim for the last two years. It did take some getting use to, but the idea clicked almost instantly. Having normal and insert mode is superior concept in my mind. It allows you to treat text editing as a game.

I am not a power user by far but I do have some favorite tricks.

Using console version

• Pros:
  • Console output is colored
  • Ctrl-y puts you to console, fg puts you right back
  • No need to open console in another window
• Cons:
  • Color scheme is a bit uglier (less color in console)
  • Copy paste is a bit harder (from other GNOME apps, at least for me)

I’ve tried everything here. Rationally I thought that the console version is too ugly. BUT I noticed that I type vim from terminal unconsciously. The Ctr-y/fg combo and ability to start test to console from within vim sealed the deal. Somehow I got use to lack of prettier color scheme.

Guard Clause

If you know what test doubles are. If you know that stub gives canned answers and that mock is an object that you can set expectations on… Pass along. If you are still uncertain about this you may want to read on.

Stubs

Chances are (if you are a guy) that you are using stub when talking to your girlfriend:

Does my ass look big in this jeans? No!

It doesn’t matter what the real answer is, you just give back the prepared one. Kinda like when you need certain data for your tests. You shove in your answer for example 11/28/2011 and you expect the canned answer every time. It’s a lie agreed upon for the greater cause.

Mocks

Mock is emotionally ‘complicated’ stub. He also gives back canned answers but he expects certain things to be done in the process to be fully satisfied. Translated to our girlfriend example it is something like this:

Are you cheating on me? No!

Here the expectation is that you don’t give answer right away, because it looks canned that way. Also you shouldn’t think to long before answering. Mocked object v2.0 might expect that you look her in the eyes…

DRY me is noticing that we have overlapping in code, so I would probably use the same algorithm for both question in the class BlowTheTruthOutOfWaterIfItsBrutal.

If you are using JIRA to log your working hours I think the best policy is to write it right after you are done with particular task. In the process I’ve experienced a couple of non-happy-path-scenarios such as:

1. JIRA is down
2. JIRA is slow (I am complicated about speed, kinda like Corey Haines)

In order to mitigate that, I’ve started writing notes to .txt file. I would then type-in all hours at the end of the day. It’s just me and my beloved Vim. What could go wrong? Right?

Well, it sounded better in theory as it had its own share of problems, such as:

1. Keeping the file open all day long (and more so finding it)
2. Forcing myself to fiddle with JIRA for x tasks (not to mention “at the end of the day” part)

There is one gotcha in Ruby UTF-8 support.

String method downcase is local insensitive, meaning it ignores UTF-8 characters not in standard ASCII character set.

Example below will give you expected results:

"HELLO”.downcase

-->hello

Next example will not behave as desired as non standard characters remain in uppercase:

"DINING ROOM - SALLE À MANGER".downcase

-->dining room - salle À manger

It is supposed to be fixed in Ruby 2.0. Until then you’ll need some monkey patching:

gem install unicode

#enviroment.rb
require 'unicode'
require 'lib/string'
#lib/string.rb
class String
  def downcase
    Unicode::downcase(self)
  end
end

Risky business, I know. But it’s the only only solution that I know of.

Coming from .NET/C++ background symbols were a bit of an alien concept. I had a hard time really mapping it to my brain. In the trying to do so I’ve read couple of posts that were describing symbols as a frozen string. Unfortunately that didn’t help me that much. I did manage to use them by writing a colon in front of the “string”. After I while I’ve realised that:

Symbol is a representation of an idea, but distinct from it. In a way it is a new entity that you name/create.

For example if you need to talk about animals in your neighbourhood we as humans already have concepts like cat, dog, pigeon…

While coding if you don’t have the idea of symbols you can:

• Use magic numbers - and try to remember them all while ensuring uniqueness if needed
• Give names to magic numbers with enumeration of some sort - and group them upfront
• Create structure or class to represent the concept - usually an overkill

Each of this approaches has flaws which are noted above.

With symbols you can say :cat, :dog and :pigeon. You are giving a name to a new concept. A concept that you can now talk about with your computer.

It’s 1AM… You have:

• broken production (hey you should have tested better, that never happens to me!)
• humongous log file
• no idea whatsoever about what’s wrong

You may or may not know it, but right now your best friend is Unix command line and a guy named Doug Mcllroy. If you know who he is… Pass along nothing new here for you…

If you don’t THE important thing is what he wrote on October 11,1964 in a memo that was inspiration for piping in Unix:

We should have some ways of connecting programs like a garden hose – screw in another segment when it becomes necessary to massage data in another way…

I believe that massaging data is exactly the remedy you need. Looking at the log data from multiple different angles is fastest way to figure out what is going on. Famous Unix one liners are the way to go. They say that back in 1972 when Ken Thompson implemented pipelines (that Mcllroy was talking about 8 years before) the whole new world opened up…

…we had this orgy of one liners. Everybody had a one liner. Look at this, look at that…

The whole Unix philosophy of doing one thing and doing it well was articulated more clearly right then and there. Only problem is that command line is complex and you don’t know where to start. I use to feel that way, but here is the kicker:

You only need to know a few tools and even fewer options. Even the basics will get you a long way.

So I urge you to embrace a couple of simple (to use) tools, and make some rather smart people from the past work for you. Climb on the shoulders of a giant…and enjoy the ride!

Lately I’ve been using a lot of Dependency Injection in a big enterprise application as a way to satisfy different customers needs. Application is being used in couple of different countries and it is tailor made to match specific needs and specific regulation laws. It’s being developed by three dislocated teams and since it’s written in .NET 100% I think it was the right way to go. That got me wondering if the similar setup would be needed in Ruby world.

I’ve noticed a couple of blog posts claiming that you don’t need Dependency Injection since Ruby is so malleable. I don’t fully agree.

I do agree with Jamis Buck that it is generally a bad idea to speculate about where you will need Dependency Injection and to put infrastructure up front for it.

If you are unsure what a Dependency Injection is take a look at the example below:

class Customer
  def initialize(id)
    @id = id
  end

  def tax_code
    "US-#{@id}"
  end
end

print Customer.new(123456).tax_code

I wanted to test performance on a real world example so I opted for testing this expression:

 313 ^ 150000

First of all, hats down to my i5 for even giving me back the answer in reasonable time. It makes Sessa chessboard problem trivial.

This are the results(in seconds):

I am kinda surprised with how bad CLISP is performing compared to Python, and how bad Python is performing compared to Ruby. Haskell looks impressive on this particular example.

*I was unable to even import math lib needed for Clojure for the high-tech expt function… I was appalled with that so much that I’ve left it out of comparison.

One strength of TDD is fast feedback. You need your code to validate your assumptions. The faster the feedback, the better. In Rails “The Whole Universe” is required. Unsurprisingly tests are slow. I didn’t buy SSD to cut down test startup time from 7s to 3.8s.

The patient

Small example with 98 tests that are hardcore domain specific. Only one test suite with 8 tests needs Rails helpers for form rendering. If BDD is your game - this info is not going to help you much. I don’t buy it. Even headless drivers for integration testing (like Capybara) are way to slow for being useful in this “rapid feedback” scenarios. I am not against integrated tests but do agree with JBrains that says “Integration Tests Are a Scam”.

Lets take the ball to the Lisp court where we want to add something new to the language itself, so we can check out this homoiconicity in practice. For instance I would like to be able to have special kind of “if” that reads like this:

(This is the way Pablo did it.)

(is-correct (= 0 0 )
             (println "Hooray it's true")
             (println "Not true"))

In Clojure it’s a breeze(other than breaking my heart in little pieces)

(defmacro is-correct [predicate if-true if-false]
    `(cond ~predicate ~if-true
           :else ~if-false))

Extending syntax like this is not possible in Smalltalk, but they have decent workaround: