FizzBuzz as a Ruby Hash

April 30, 2015

FizzBuzz is a simple kids game, often used as a test at programming interviews. It goes like this:

"Write a program that prints the numbers from 1 to 100. But for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”. For numbers which are multiples of both three and five print “FizzBuzz”."

Once you've realised that there's a unique outcome for each permutation of the two conditions, the solution is pretty obvious. Let's have a look at the truth table:

(n % 3 == 0) | (n % 5 == 0) |   outcome
------------|-------------|-------------
true                    false                'Fizz'
false                    true                'Buzz'
true                    true                ' FizzBuzz'
false                    false                number

We can express this as a pretty standard multi-conditional statement:
    (1..100).each do |n|
        if (n % 3 == 0) && (n % 5 != 0)
                puts 'Fizz'
          elsif (n % 3 != 0) && (n % 5 == 0)
                puts 'Buzz'
          elsif (n % 3 == 0) && (n % 5 == 0)
                puts 'FizzBuzz'
          else puts n
          end
    end

This will work fine, however I think we can do better than that. Now, remember we already saw how we can use a Hash to represent a truth table? Well, this is a truth table right here so there's nothing stopping us from using a Hash. Our clue is that the outcome of our table is a unique value (Fizz, Buzz, FizzBuzz or the given number), so this will be the key of our hash. We can now write a method like this one:

def fizz_buzz(n)
    h = {
        'Fizz' => (n % 3 == 0) && (n % 5 != 0),
        'Buzz' => (n % 3 != 0) && (n % 5 == 0),
        'FizzBuzz' => (n % 3 == 0) && (n % 5 == 0)
    }
    h.key(true) || n
end

First, we define a Hash whose values will evaluate to true or false depending on the number we pass into it. Now here's the sweetness: since the conditions that are evaluated to produce each value are mutually exclusive, only a maximum of one of our Hash keys will have the value of 'true' for any given number. We then make sure we return this 'true' key (h.key(true)) from our method. Of course if all our keys have the 'false' value (i.e. the passed number is neither divisible by 3, nor by 5) then h.key(true) will evaluate to nil, so we use the logical OR operator to ensure that -in this case- we return the actual passed number.
Let's try it out:

$> puts fizz_buzz(2)
   => 2
$> puts fizz_buzz(3)
   => Fizz
$> puts fizz_buzz(5)
   => Buzz
$> puts fizz_buzz(7)
   => 7
$> puts fizz_buzz(15)
   => FizzBuzz

Sweet! Now, to solve the original problem all we have to do is

$> (1..100).each {|num| puts fizz_buzz(num)}

Hash-tables in any language are a powerful construct. Hashes in Ruby though are truly awesome! They provide unrivalled versatility and expressiveness, just like most things Ruby. Use them, enjoy them, you won't find anything like them anywhere else! :)

Scrum velocity is just a placebo

April 25, 2015

It takes 3-5 sprints for a team to establish stable velocity. And then we're supposed to use this velocity to forecast future effort, i.e. amount of effort we can put into future sprints. Now, this works fine if nothing changes. For velocity to work, it is assumed that the same people will be working on the same kind of problems, using the same technology, with the same productivity and motivation every day for the duration of the project!

If you're one of the lucky few where nothing ever changes in your team and your project then congratulations, velocity as a forecasting tool will work well for you! If, however, you're one of the unlucky 99.999% where life gets in the way and causes pesky changes in your team or project then tough luck! Each and every time a team member falls ill or simply becomes unhappy, or you have to use a different tool, or the sprint duration changes or simply a previous assumption about your project is invalidated then Bang! Velocity blows up in your face. Welcome to another few sprints until you establish stable velocity again - enjoy it while it lasts because in a few more sprints it's going to blow up again.

Velocity is a placebo. Is one of those things that gives us the illusion that we're in control of something and makes us feel better for it, while it has very little practical effect.

The way to deal with change in not to assume that it won't happen and -when it does- start all over again. The way to deal with change is to be prepared and -when it comes- make sure we can assess it, measure it and manage it. We need a method that breaks down change, weighs its effects and allows us to quantify it and adjust to it.

Truth tables using Ruby hashes

April 10, 2015

Yesterday I attended a talk about truth tables. It was based on the premise of an interview question and whether the candidates were able to model and represent in code the appropriate truth table. The problem question was along the lines of "write a method that receives the month and the year and outputs how many days there are in that month".

Sounds easy, doesn't it? We all know which months have 30 and which 31 days in them. Apart from February, that is. February usually has 28 days, except that in leap years it has 29. How do we know which years are leap years? There are certain rules that allow us to determine leap years:

Sorry, I don't do Java.

March 17, 2015

Had a long conversation this morning with a recruiter who was trying to get me interested in a contract gig. I must admit, it was enticing: the gig was local, the rates were good and the company was reliable. There was only one problem: Half of the coding was to be done in Java. Now, I have Java down on my CV, but only under the 'Secondary skills' heading. It's there purely to reflect my history, not as a selling point. The recruiter refused to accept that. "But if you know the basics, you can pick up the rest", he persisted. I tried to make him understand that it's nothing to do with my confidence in 'picking up the rest', but more with my unwillingness to do so. I tried to explain -in simple terms- how coding in Java makes me neither productive, nor happy. It's difficult to do this over the telephone, speaking to a non-technical person with their own agenda, so I decided to write this down as simply and concisely as possible. Next time I get 'the call' I'll just refer them to this URL.

Here is the simplest task you can do in programming: just display a simple message on the screen. Here's how we do it in Ruby:

                                   puts "Hello World!"

and here it is in Perl:

                                   print "Hello, world\n";

and in JavaScript

                                     alert("Hello World!");

Once you grasp the simple fact that puts/print/alert/etc. prints to screen, then completing the task takes two seconds and half a code line. OK, the newline delimiter in Perl might trip you up a bit, so I'd add another couple of seconds to comprehend that "\n" adds a new line.

Now here's the same task coded in Java:

                                    public class HelloWorld {
                                        public static void main (String[] args) {
       System.out.println("Hello, world!");
          }
}

Other than the obvious observation that our code is now much more verbose, we also have to get our head round quite a few heavy concepts:

Classes ( public class )
Access Specifiers ( public main() )
Methods and 'special' methods ( void main() )
Scoping methods ( static main() )
Type declarations ( String[] args )
Arrays ( String[] )
Streams ( System.out )
Method chaining ( System.out.println )

Flip me, that's quite a lot of concepts to know just to be able to say 'Hello World'!! Not only that, but I'm also forced to save this code to a file called HelloWorld.java ! Some people will attribute this to a solid architecture or a comprehensive design. I attribute it to a triumph of form over function, ceremony over practicality, pomp over productivity. It's designed to overwhelm its users, rather than help them. It's shouting "Look at me, I'm solid and safe, big and unbreakable". I like languages that shout "Look at me, I can get things done quickly and easily", or "I can do stuff without imposing myself upon you". I like languages that get out of my way, not get in my way. I appreciate expressiveness and freedom instead of constraints and limitations.

Me, I like languages that can flex, that can expand to accommodate my programming needs. Java, in addition to its others limitations (such as inability to implicitly model data, hence the plethora of XML, property files and countless mapping frameworks), lacks meta-programming, lacks macros, lacks all these syntactic abstractions that would allow me to stretch and twist my code in all sorts of angles in order to achieve my goal. Instead, Java forces me to shoe-horn everything I do into a convoluted, 'faux' object-oriented, static and inflexible model that -to add insult to injury- also takes much longer to develop.

At the end of the day it comes down to this: life's too short to spend it fighting a programming language. So I hope you understand now Mark, this is why I don't do Java.

Moving to Ruby-how to make a successful transition in 4 simple steps

February 24, 2015

I just returned from ConFoo 2015, which BTW is a great conference with lots of good talks and events. The good thing about a multi-discipline conference like this, is that you get to talk to people from different technological and programming backgrounds. I met people from the PHP, JavaScript, .Net, Java and Python worlds and -inevitably- we got talking about Ruby and the best way to start learning it. My part of the conversation always boiled down to the same arguments and recommendations, as distilled through my own experience of coming to Ruby from a C++ background. Here they are:

About You

You are an intermediate / advanced level developer who understands object-orientation and is familiar with design patterns. You’re probably a competent Java, C#, C++ or Delphi programmer. Less likely, you’re a PHP, Python or Perl programmer but you still grok OO and DPs. You appreciate elegance, efficiency and the joy of coding.

Why you need to do it

Because learning Ruby will make you a more efficient and happy programmer. Even if you decide to stick with your existing language, knowing Ruby will make you a better programmer in it.

Step 1:

Read this book:

it brilliantly takes something familiar (design patterns) and uses it to illustrate Ruby concepts and idioms. It starts with some fundamental concepts and then cranks up the intensity with each chapter. By the time you finish reading it you’ll have a good basic understanding of Ruby. As a pleasant side-effect, your knowledge of design patterns will probably also have increased. If the last 2-3 chapters seem a bit of a struggle (which they might if you come from a static language background), just leave them out for now - you’ll come back to them later.

Now you can try this tutorial. It will recap your basic Ruby knowledge in a practical, interactive way. It will also fill-in any blanks left by the Design Pattern book.You now understand basic Ruby principles, as well as concepts such as blocks, duck-typing and the usage of modules. Time for the next step:

Step 2:

Complete the micro-blogger tutorial. It will reinforce the basics and will show you how to use Ruby in the wild, that is by integrating gems and third-party APIs into your code just like you need to in the real world. Once you’ve done this it’s time for some more advanced knowledge: You need to get familiar with the way Ruby handles lambdas and closures. There’s a plethora of articles you can google on the subject. With extreme bias, I would recommend this one.

You must get intimate with Ruby collections, specifically the more functional (i.e. map/reduce) aspects of them. So go and read chapter 9. While you’re at it, feel free to read the rest of the book too. It certainly won’t hurt and it can be very informative.

Step 3:

OK, you now understand the Ruby idioms and appreciate the ‘magic’ Ruby performs. But how does this magic happen? Time to find out by whipping out this book: This book will help you comprehend how Ruby works and how you can utilise it to the max. It will get you acquainted with meta-programming (i.e. code that writes code) and will explain how the Ruby Object Model functions. This is essential knowledge if you want a good understanding of the language. Once you grok the Object Model it becomes much easier to learn stuff like Rails or write your own gems. The book is also littered with little Ruby idioms and techniques, a.k.a ‘spells’, that will increase your efficiency and understanding ten-fold.Once you’ve been through this book, you may want to re-visit the last three chapters of ‘Design Patterns in Ruby’; you’ll find they now make a lot more sense.Now go and test your Ruby skills here.

Step 4:

Finally, you understand enough of Ruby to make it your own. The last step is to build your own project. Pick an idea, any idea, it doesn’t matter. It could be something you’ve already done using another language, maybe an old work project. If you can’t think of any, here’s an idea for a project. Now implement it in Ruby. If you get stuck, this book makes for brilliant reference and guide. Once your project is working, sit back , light up a cigar and bask in the knowledge that you’re now familiar with an elegant and effective all-purpose language that will make your programming life much easier and more enjoyable. Happy coding!