The master was seen petting the dragon.Not an enjoyable work any day as dragons in the Dojo were pretty huge and filled with scales.The apprentice was still practicing the art of better programming.His fist was almost accustomed to the practice models.He was bored and thought that at this time Master Gates had built microsoft.He was nowhere near to that and the Master kept on emphasising the importance of practice.He decided to go to the master.

Master was still petting the dragon.Almost an hour had he spent on petting dragons.This was unusual.There was news of war somewhere south east.One of the masters had ridden a dragon there.The siding had to be done, so there was balance in place.Show of force is a must in a war and sometimes war itself can be avoided with just a show of force.

The supreme art of war is to subdue the enemy without fighting.

The master was reminiscing about the days he spent learning The Pragmatic Programmer.There was even more wisdom to be learned from the book, now more than ever.The apprentices were given hardcover copies of the book to posses the wisdom he now possessed.With young age, blunders come fast.Apprentices were gulping it down like it was some pulp fiction novel.Master was agonised over it.Just then an apprentice came for some advice.

He had implemented a code that could possibly fit the description of a spaghetti code(no offense to FSM ofcourse).There were dependencies which were not easy to percieve or understand.The master just concentrated on one specific set of issues.

The student was assigned to a banking company for designing their API. The student was excited as well as slightly exasperated. Master smiled seeing the student. Banking companies needed a fluid design, flexible and extensible beyond all points. It was necessary as the bank was planning to establish itself as banking solution for people in greece.

The student without wasting his time started implementing an account class and money class. Master watched him with nostalgic eyes. Account object was created in such a way that each and every user was given one account. Account object was mutable. The underlying construct of money was immutable. If you wanted to add money to account then money was added with another value. Money is muted to reflect this change. The code was ready for production. The student was ecstatic. The master saw the code. He entered the terminal and deleted whole code permanently. The student was angry and was ready to unleash his katana.

The master smiled and took him to a coffee shop. They ordered two coffees and the bill came out to be 16 rupees. The master gave the student a 10 rupees note and other 6 rupees in coins. The student took the money and attempted to give it to the shopkeeper. The master used the back of his katana to make the student drop all of his money. The student tried picking it up from the ground. Again, the master made him drop all the money. The student was exhausted and dumped the idea altogether. The master smiled and told the student that he could take it when all entities were of same. There should be no coins at all. You add 6 to 10 rupees note, there should be a note which said 16 rupees. If that was possible he could take the money.

The student was enlightened. He went back and reimplemented the account and money with mutable account class and immutable money class.

The student had already finished the daily code review and was looking forward to newer challenging exercises. He had finished a Red Bull and Gatorade. The master was nowhere to be found. The lunch orders were to be made. The student wasn't hungry nor was he thirsty. He secluded himself to the room with the bean bags. It was where he meditated about the inner workings of soul, body and MacBooks. It was exactly  at this time that the voice of the master was heard from the main dojo.

Master called all novices and asked them to work on a new kata. He asked them to build a rectangle class with methods area and perimeter. Further, he asked them to build a square class with methods area and perimeter. Students were grouped and then asked to proceed to the task.

Implementations were widely different from what where expected. Some had created two different classes. Some had gone for inheritance. Some had gone for overridden inheritance. Some were still implementing even when the time limit was over. The master was pleased with the implementations, but his face never showed it.

Master started to disprove each and every implementation. The first, of course, was one where there were two classes and nothing was shared between them. Master asked them about why area and perimeter were not inherited or at least derived from rectangle class. The answer was not easy and novices kept mumbling amidst themselves. Next was the one where implementation was based on  overriding the inherited methods. There was nothing to disprove here as they themselves agreed to their mistake. The third one was where the initialization had been overridden and the rest were inherited. Master had only one thing to say

A square is not a rectangle.

The student was perplexed with this ambiguous statement. His katana slid away from his hand. The other groups also started murmuring within themselves. Master had only one more thing to say.

The homework question had bogged down the student. He thought of many ways in which he could bypass the issues with square and rectangle. Not only was square different from rectangle, it also changed perimeter and area calculation based on sides accordingly. The student thought of many methods and finally decided to override the setters and getters in the square class. He decided that it was the perfect way to do it. He was happy and proud at his innovative solution.

The master was still learning Go. The student approached the master and showed him the beautiful implementation. Master saw the implementation and asked the student to get out of the dojo. The student obeyed.

After some time, when the master had his lunch he went out to see the student. The student was still outside the dojo, contemplating the beauty of his code. The master smiled and asked him to come inside. The student tried entering through the door. Master kicked him with all his might. The student was surprised and also angered. The student tried again. The result was always the same. The student sat outside the dojo and decided not to enter the dojo.

Master smiled. Master asked him to create a new door for entering the dojo. If he wanted to learn he should create a new learning door. If he wanted ramen, he should create a ramen door. He wanted to practice he should create a practice door, and so on. The only thing remaining should be a million doors and no dojo at all. Anybody could enter and take what they wanted. Anybody  could change what they wish.

The student was enlightened. Master smiled and allowed him to enter through the front door.

It was not long before the impatient student inside him started to turmoil. It was the time that he be given a new kata to work on. Something grand, something like the universe. He had to conquer it now. Time was short...less time remaining now. He went to the master. Master, as usual was in his good self, consuming the internet with a straw. It was amazing the man like this is a renown master. The student was trying to open his mouth when master stopped him.Smiling at him, the master gave him a new challenge.

Write a simple class which represents a typical "Fizz Buzz" game between children, with no smells.

The student was happy. His katana is sharp and gleaming. He accepted the challenge. He within minutes came back with an implementation. Master laughed when he saw the implementation. An attr_accessor had crept in. The student was embarrassed. Master gave him one more chance to prove his mettle, as he had some more spare time.

The student had another implementation within an hour. Master laughed again when he saw the implementation. A public method was calling a private method. The air was full of code smells. Master was happy that student realised that writing the simplest classes is the toughest. As usual, to drive his point home, the master started explaining the Fizz Buzz test.

Fizz Buzz test was designed by a great master to select only the best programmers for the job. Not only was it tough, it was also infamous for the fact that 99% of programmers can't do it. The toughness arises not from the logical part of the question, but it came from the structural issues that Fizz Buzz had. A normal branching condition wouldn't work here as the problem has a compounded logic in the test case where the number is divisible by 3 and 5.

Master had something to say to the new students.

Listen up, maggots. You are not special. You are not a beautiful or unique snowflake. You're the same decaying organic matter as everything else.

The student was enlightened.

The journey for the ronin had just begun.The master was not pleasant but nor was he unpleasant, a shade of grey could possibly describe him. The TDD cycle was rigorously followed by the student, almost like the time he started off with a bicycle. But the student was not yet convinced why one needed the Test Driven Development and not any other methods like writing the complete codebase and testing it. Half of his dreams were revolved around this question. On one of those sleepless nights student wandered off to find the master to finally quench his thirst for answers.

The master was at the waterfalls checking out his macbook. He seemed at peace with the nature and was at ease with the howling jackals and the roaring elephants. He seemed to laugh sometimes and at sometimes it felt like he was crying. Student kept on looking at guru for some time. After a while he mustered enough courage to ask the master about the need for TDD.

When the student approached master smiled, and asked whether he also suffered from sleepless nights. Student replied with a nod. Master told the student that today he will tell a story about two frogs. Student remembered the story of Shehrezad and 1001 nights, nor was he interested in stories, neither had he got the time. But some times in life you just have to give in. This was one of those times.

Once there lived two frogs who were given a library and asked to build an application with it. The first frog called Dave was into trying stuff and learning from them, the second one called Mike was much more cautious and tested the library and made sure that program worked according to the specifications. While Dave spent days and nights in building stuff, Mike was interested in writing the tests and making them pass. Dave had a working application within days which did as was specified by the client, Mike was still half way through. Eventually both codes went to evaluation and testing. Mike's code worked but Dave's didn't.

Master knowingly smiled at the student. The ronin was perplexed, he was aware of Pandas which knew kung fu but was unaware of frogs who built applications. Master,  seeing his student, started explaining about programming by coincidence. Programming by coincidence is where a developer have no idea why the code worked or why it failed. He just trys out all combinations and then makes it work. It was nothing but a love child of the "Hack culture" and utter "irresponsibility". Nothing can justify its existence, but it still does exist much like JAVA.

 With great power comes great responsibility

A programmer is nothing but a code ninja, he wields fancy weapons and nice girls are attracted to him(I said nice rest are all bad),but he must also adhere to the sacred oath of the secret school :

1. Always be aware of what he is doing.
2. Proceed always from a plan.
3. Test both your assumptions and the code according to certain set of parameters or better put contracts.
4. Always justify the existence of the code snippet you wrote to yourself and then to the world(Convincing yourself is tough if you are as argumentative as you are to others).

Student was enlightened. He was now one with the coding spirit. Wait, but how did master knew the answer before the question was asked? Master smiled and replied

I once stood at the banks too. But then I saw the boiling frog and learned to swim.

In an alternate universe, where frogs did not code, Dave was just happily feasting on a fly he just caught. He had just found the hot bathtub that he needed. Mike had told him it was no good, but Dave always knew better.

He was nothing but a ronin, the one without master, the one with the wind and the water.He had just been out of the great Indian education system and realised that it provided nothing but a paper which you could as well use for cleaning tables with.He wandered from dojo to dojo but was never satisfied nor was he ever interested in arts they had offered.This all changed the day he came to the new dojo.

It was nothing fancy a small dojo of 3 masters, 4 apprentices and other students, but teaching and preaching a new model of programming and delivery, something he was not familiar with, something he was alien to.He sure knew about design and sure as hell knew about object oriented design.He is aware of the oneness of design with the implementation.

He was well trained in the popular weapons/tools of the old school of Kerninghan and Ritchie. The master didn't care for what he knew nor did he care about what weapons he could use.He was interested in how well could he perform.He was taken to the katas.He was given a simple problem design the game of life make it without any flaws.

The student was proud in his weapons, but the weapon of choice was something made from the fires of Mount Fuji by the well known Grand Maester Matz.It was called Ruby.He had seen it before, he had used it too but was not well versed in it.
He used the weapon in similar manner to the weapons he was accustomed to.He fought the master in the ways of Procedural Programming.The master was smart, it was not long before that student tasted blood, his own blood.He had to be a learner again.
First thing the master specified was Test Driven Development or TDD in short.TDD is a programming technique where in the programmer defines contract for the behaviour of a certain entity or Class as the practiced ones in Object Oriented Design called it.A class is nothing but a set of entities which shared same property and behaved in a similar way when encountered with a certain external impulse.An example would be a book.All books have a cover and bunch of papers inside these covers.But these covers maybe of hardcover or softcover and inside the pages maybe of sugarcane, or of unicorn hairs, but they will all respond to flipping of page with a new page different from the old one in what is written it but not in composition.

Now coming back to TDD, the contract is for defining how the behaviour worked, in this case flipping of page.You had to model the behaviour through a Behaviour Driven Development or BDD framework Rspec(more on that later).TDD follows a typical cycle better known to the world as Red Green Refactor. In the red phase you had to fail the contract that is the tool is never to be used or in this case there is no book.The next phase was of course where the contract had to be maintained a book was to be there with pages(no not the cover as we are just maintaining the contract for flipping of page ).Now the contract will be satisfied with presence of a book with pages which when flipped will return another page this is called a green stage.

The student was impatient he was much more interested in boundary cases(like the contract breach at the end of the book), a classic case of procedural programming hang over.The master served him with a freshly cut unripe papaya and asked him to eat it.The student accepted, but he could not eat it, like many unripe things it was unbearable.The master explained just like the natural process is to look at papaya and realise it is ripe when the color changes from green to orange, it is natural for the code to be derived from simpler contracts to more complex.Like at first a papaya is nothing but a flower the contracts are different at this stage, then it becomes an embryo, contracts here are build on top of those at embryo stage, the next stage is an unripe papaya, contracts here might be presence of seeds, a well developed outer skin etc.When a contract is specified the previous ones are also present.

You derive the design not design the design.

So accordingly the edge cases can be tested once the base cases has been done with in contract, and then the green stage and then go for contracts for boundary cases.

Let the baby take the baby steps and then walk and then fall.Fall is inevitable but you do not have to prevent it before the walk.

Student was enlightened.Master said refactoring is something that we will be doing when all of us are one with the concept of red and green.He added commit instead of refactor, so the new idiom of course was Red green commit.The katas now on wards will focus on this idiom.The master had only one thing to say as parting words.

Do not try and code the design. That's impossible. Instead...only try to realize the truth.There's no code without spec ever.

Welcome to this humble endeavour.Since everything must begin with a plan, I have decided to outline what I will be doing with the blog.

1. Posts about culture, technology, programming etc
2. Since I belong to a country of argumentative Indians, there will be occasional posts about Politics and other stuff.
3. Occassionally there would be series inspired by books like Pragmatic Programmer