How to WIN CASH in the Maina and Kingangi's Cash Cow Game (Count the Cash)

If you are the lucky caller, wait till Maina tells you which of the 3 possible options can be ruled out, and then change your answer to whatever other option remains, I repeat, DO NOT STICK TO YOUR ORIGINAL ANSWER.

If you want to know why, continue reading below...

Firstly, for those who don't know what am talking about, Maina's Cash Cow is a challenge that runs on a weekdays radio progamme popularly know as Maina and King'ang'i in the morning, on Classic FM, a popular radio station in major Kenyan towns and their environs, especially Nairobi.

Here is how it basically runs:

• Maina, the presenter, invites radio listeners to call the station and attempt their luck in counting his cash; only one lucky caller gets his call picked up, he will listene the sound of a Note Counting Machine and all he has to do is guesstimate the correct number of notes.
• After the lucky caller guesses the number of notes, say 51, Maina goes ahead and gives the callewr two more possibilities. e.g 'What if I told you it's either 51, 52 or 53?', (should you still stick to your original answer? at this point it does not matter, change to whatever of the 3 you want, it was a guess anyway)
• After the caller settles on one of the three numbers, Maina discloses that one of them is not correct. e.g The user settled on 51, and Maina goes like, 'What if I told you it's either 51 or 53?' (i.e rules out 52).

Apparently,  the correct probability solution will predict that SWITCHING from your original answer to whatever remaining option (i.e from 51 to 53 in this example) doubles your chances, from 33% to 67%. Well, it did not make sense to me too at first, I initially worked out that it's just two options (51, 53) and thus the probabilities should be 50% vs 50%. I will not delve into the probability theories that explain this, instead, I will direct you to a simplified python snippet that you can study and also execute to see the results for yourself. 

I implemented a simple computer algorithm to simulate the scenario and demonstrate why it is always NOT advisable to stick to your original answer as the caller tackling Maina's Cash Cow challenge. The simulation simply runs 10,000 challenges for each of two guys, one who always sticks to the original answer, and the other always switches. The simulation clearly demonstrated those who stick to their original answer only win ~ 33% of the time while those who switch their answers won ~ 67% of the time. The  code is here.

Some of the assumptions made are that:

- Maina knows the correct number of notes even before the caller begins guessing.

- Maina is going to be honest

- Of course it does not have to be real notes, it could be computer generated sound based on a predetermined number of notes or a real Note Counter, the math still stands.

Note: This is a classic probability puzzle known as the Monty Hall Problem.

Aligning Text At the Top a Table Cell

Well, am back again to blogspot after a 9 months break, that was quite refreshing and eyeopening.

Quick to the point, I really had some trouble trying to align text at the top of a table cell, which is understandable, given my little experience in front end development.

Any HTML/CSS developer has heard of the 'text-align' CSS property that can be assigned to virtually all HTML elements. It not only controls horizontal alignment of text but all other HTML objects including div's, and tables. It only takes 3 values which set the alignment to be right, left or center. Notice you can set vertical alignment using this property. So what do you do if you have a table row, in which some cells have text spanning multiple lines while others have single lines but are displayed at the center (vertically)? which is the default for most browsers?

Here is the solution. use CSS property 'vertical-align' which takes 'bottom' and 'top' values for bottom alignment and top alignment respectively.

Here is sample CSS for setting all table data cells to be vertically aligned.

td{
vertical-align:top;
}

Well, have a good time coding in HTML.

Real Programmers Dont Write Specs

Well, this is not my original content, I have given a link at the end of the article. They are like rules for judging how real a programmer is and I really found them interesting and funny but not necessarily true. I modified some of them a little to fit my context. Enjoy reading.

Real Programmers don't write specs -- users should consider themselves lucky to get any programs at all, and take what they get.

Real Programmers don't comment their code. If it was hard to write, it should be hard to understand and even harder to modify.

Real Programmers never work 8 to 5. If they are around at 8 AM, it's because they were up all night.

Real Programmers don't play tennis, or any other sport which requires you to change clothes. Mountain climbing is OK, and Real Programmers wear their climbing boots to work in case a mountain should suddenly springs up in the middle of the computer room.

Real programmers don't think they should get paid at all for their work, but they know they are worth every shilling they make.

Real programmers log in first thing in the morning, last thing before they sleep and many times in between.

Real programmers don't like the team programming concept, unless of course they are the chief programmer.

Real programmers have no use for managers.

Real programmers ignore schedules.

Real programers only curse to inanimate objects such as loops, variables and monitors.

Real Programmers spend 70% of their work day fiddling around and then get more done in the other 30% than a user can get done in a week.

Real Programmers don't do documentation. Documentation is for those who can't figure out the listing.

Real programmers are surprised when their cars' odometers dont turn from 9999 to 999A.

Real programmers think they know the answers to your problems and will happily tell them to you rather than answer your questions.

Real Programmers' programs never work right the first time. But if you throw them on the machine they can be patched into working in "only a few" 10-hour debugging sessions.

Real Programmers don't write in Visual BASIC. Actually, no programmers write in Visual BASIC... after age twelve.

Partly adopted from http://www.multicians.org/thvv/realprogs.html