The Riddle In The Middle

Whats next in this sequence:

1,2,3,4,5,6,7,...

No its not 8. Its 9.

See, the function that created this sequence is:

f(n) = n + floor(n/8)

Wisdom Of The Day:

"When something looks so easy,
suspicion would be the best first thing to do."

Any extra wisdoms you can think of?

Advanced For Loops

There are some skills in our career that we have reached proficient enough to an extent that we think there's nothing extra to learn.

One good example is the for loop, I mean, I dont think there is anything left I need to learn about a for loop.

Well, I was wrong, daaaaaaaaaaaaaaaamn wrong, here's one extra piece of information that'll leave you scratching your head the rest of the day.

for (int i = 0; i < arrCustomers.length(); i++)
{
println(arrCustomers[i]);
}

Becomes:

for (int i = 0, len = arrCustomers.length(); i < len; i++)
{
println(arrCustomers[i]);
}

Now the code above saves your interpreter/compiler from calling the method length() each and every iteration.

Meaning, a wonderful optimization with approximately zero extra code.

Whether you like it or not:
"You ain't a for loop expert as much you thought you were!"

You've got a bug (Dont take it personal)

Developers have always, are always and will always be in a state of offense when being accused of committing a bug.

Whether they (we) like it or not, the statement:

"You've got a bug."

is an emotionally disturbing phrase for (we) the developers.

The word 'bug' by itself is so phonetically provoking. First of all, its composed from one sylable that pops out all of a sudden. "BUG", "BUg!", "bUG', "BuG", its like microwave popcorn.

It even sounds like you're cursing someone. And sometimes, it sounds like you're accusing someone of having weazels in his hair (قمل).

I try my best to avoid using the literal form of the word 'bug' by replacing it with more friendly alternatives like the words 'defect', 'malfunction', 'problem', 'leak', these words have proved to be more DES (Developer Ear Safe) words.

If you're a quality person, a customer, a manager or any person involved in auditing developer's output, then here are some alternative sentences I've collected through my career to help you out with dealing with such cases:

"The system is acting a bit wierd when I press this button."

"There's a small problem, I dont think you have uploaded the latest code."

"I found this problem, you know what, it looks like a third-party library is going nuts."

"I found this problem, are you sure no one touched the code you wrote?"

"I'm sure you haven't finished yet, I remember you told me you still have work to do in this module, I think this is why all these bugs are showing up."

Also make sure not to use the word 'you'. But always use the passive tense, and talk about it as if its a 'system' problem and not a developer's problem. Not "You've got a bug", but rather, "A strange problem is showing up here.".

Last advice, stay away from discussing this bug with the public; before the bug is fixed, while being fixed and after getting fixed. Dont discuss other people's problems if you dont like people discussing yours.

Extreme Programming

In Martial Arts, the most extreme methodology is named KungFu.

In software, they call it "Extreme Programming".

Some principals taught in Extreme Programming:

"A team is much more flexible if everyone knows enough about every part of the system to work on it. "

"You must realize that the design you envisioned was a good guide post, but is now obsolete."

"Never try to guess what the system's bottle neck will be. Measure it!"

"If only one person on your team can work in a given area and that person leaves or you just have numerous things waiting to be done in that section you will find your project's progress reduced to a crawl."

"Simple design always takes less time to finish than a complex one."

"So always do the simplest thing that could possibly work."

"If you find something that is complex replace it with something simple."

"Beware though, keeping a design simple is hard work."

"Refactor mercilessly to keep the design simple as you go and to avoid needless clutter and complexity."

"We continue to use and reuse code that is no longer maintainable because it still works in some way and we are afraid to modify it. But is it really cost effective to do so? Extreme Programming (XP) takes the stance that it is not."

"Working overtime sucks the spirit and motivation out of a team."

"Make it work, make it right, then make it fast."

For more visit:
http://www.extremeprogramming.org

Good Link

http://www.devlisting.com/

I still find Javascript the hardest

With all the languages I write code in, I still find the most difficult language to write code through is Javascript.

When it comes to writing javascript, I start having some headaches, here's why:

1. I start imagining the different constructs I'll use to check for browser versions.
2. I need to check for different user settings.
3. The debugger on Internet Explorer SUCKS!
4. The language itself is neither Object Oriented, nor friendly, its a strange language where an object becomes an array with a strange form of instantiation, strange syntax.
5. Whenever I think of growing myself in this language, I start getting the feeling that its not worth it. I will only need it for small webapplication tweaking functionalities along with AJAX calls, so there's really no need in investing my mind brain cells in it.

The only thing that made my life easier lately is a very good javascript debugger by the name of FireBug which comes as an add-on for FireFox.

Other than that, I feel that this is the reason why there are very very very few excellent javascript developers around. And guess what, the demand is growing.

Profession(al)?

Having a profession is something, becoming a professional is another. The mental distance between those two is similar to the distance between Irbid and Manhattan.

When building up your profession, there are two parallel lines that you need to maintain and balance:

Step #1: Practice it yourself.
Keep practicing your profession the right way, work smart, enhance your techniques every work cycle.

Step #2: Observe other professional work.
Look at what other good people have done. Understand different methodologies, patterns, techniques and practices. Read, research, find better ways to do the same work.

This bicyclic process is necessary to grow you fast enough.
Dropping line #2 will get you a bit lost and isolated, often resulting in slow progress in your career. Dropping line #1 will simply make you loose your craft.

The most useful tasks I ever got while working in the software industry were debugging, fixing and enhancing existing codebases.

Simply because, I get the opportunity to write code, and to understand how other code works.

Finally, I'd like to end this post with a valuable wisdom:

"Its not what you know, its how good you know it."

Desktop Application Development

I'm back to desktop development aaaand I love it. Desktop Applications, its a whole new world, away from the CSS, HTML tags and Buggy Javascript (Damn the IE javascript debugger, I just hate it, it always lies to me about the error's line number).

Desktop application development on the other hand is rigid, aint buggy, wonderful. I'm using MFC8 with Visual C++ 2005 Express. Voila! Smells exactly like teen spirit.

With desktop applications, the possibilities are just endless. You've got new raw material for your abstract ideas.

CYouSoon->Hala3ammi(&GoodBye);

Subliminal Programming

I remember the old days when I used to play billiards, I used to concentrate deeeeeply on the cue, the black eight, the pocket and the cueball ('7asem), trying my best to have them aligned on the correct (virtual dashed line), I then hesitate and give myself a break by sharpening the edge with a piece of chalk, again, I concentrate, think and make a shot, most oftenly, missing the pocket.

Once upon a vivid day, and after some heavy experience, and while on the table, a sudden feeling of confidence came upon me that made me shoot without thinking and made me score just by blinking. No thinking at all, just used my hidden senses to score, score, score. Yippeeee YaYoe! Something happened there, I'm not sure what it is, but I think somehow my experience managed to slip inside the subconcious part of my brain for a while.

I think this what happens with professional football players, or basket ball players, or tennis, or ping-pong, or even judo, jujitsu, guitarists, all the professional people every where, they just do it without thinking, they are experienced enough to an extent that they are able to make moves and decisions without thinking.

I wish I can become like that one day, actually, this happens to me when I'm writing HTML code, it always compiles(1) without any errors.

ref(1): HTML is the only language that compiles without errors.

Reverse Engineering Tools That Are Not.

I've been researching for the last week for a good reverse engineering tool that would simply get handed in a large C++ codebase and would automatically walk through all the classes, functions, variables and interfaces for the purpose of generating a visualization of the live flow of code.

At the end of my research I was able to find a good reverse engineering tool called Understand for C++ and Understand for Java. This was one of the best I found. I decided to use it, was impressive, but not too impressive, it still lacked lots of stuff I needed.

Looking around, I felt a bit hopeless, until I got introduced to automated document generators.

A code documentation generator would prove as the best reverse engineering tool ever. For reverse engineering purposes, I dont think I need to go any further.

Being Skeptic About Necessity is the Mother of Invention

Have a quick look at the mouse to your right, do you see the two mouse buttons, tell me what else? I'm sure you see a small wheel between the two buttons, a wheel used for scrolling up and down a large page inside the window.

A question prevails: "Did anyone in the world ever need this small scrollable wheel before it was invented?"

The answer is No. No one needed it. People where living happily ever after before this wheel even showed up. They had no problem using the up and down arrow keys or even using the scroll bar to the right of the browser's window.

If this is the case, if no one needed it, then "who in the world invented it and for what reason?"

Well, trying to scratch my head a bit, I believe she or he is someone who found it a tedious task to stretch her or his arms a bit and use the arrow keys, or even worse, he or she found it hard to point the mouse cursor on the scroll bar and move it up or down while holding the left mouse button.

From the previous notes, the only reason I can find for him or her who invented the scrollable mouse wheel is, he or she were in a state of laziness... in other words... laziness was the motive.

Did anyone ever need it before it was invented? No. Can anyone nowadays buy a mouse without requesting a scroll wheel, well, I'm one of the people who cant live without it. And I've seen many others who expect it as the default.

Does this apply to other inventions, in most cases, yes, the laziness motive appears much stronger than the necessity motive, as a short conclusion I could say:

"Necessity was never the mother of invention, the real mother is Laziness."

Power Shell versus Bash

A good command prompt has always been a weakness point in MS Windows. Compared with bash scripting in Linux/Solaris/UNIX, the command prompt simply lacks a command prompt.

Microsoft aggressively striked back this time with Microsoft's new Power Shell. You can download it from the following link or read more about it here. Expect better automation tasks and large bash scripts to be so common on Windows.

Dissecting The Wisdom

Dont trust casual reasoning doesn't mean dont use it. It just means 'dont trust it'.

In reality, I urge people to use their human logic, to use their common sense, to use their casual reasoning or to use whatever they want to call it. These activities are sourced from a powerful tool God gave to us, called the brain.

The only piece of information that you should be aware of and that wasn't mentioned in your user guide is:

"Dont trust it."

So remember this advice when it comes to making big decisions or when it comes to embracing big ideas.

A Riddle With A Wisdom

Two large jars of exact equal size. The first jar holds pepsi, the second jar holds the same but seven-up.

Using a small empty cup you remove a full small cup of pepsi and pour it in the sevenup jar, you mix the seven-up jar well. Then you remove from the seven-up jar (which has a small amount of pepsi in it) a full small cup and pour it into the pepsi jar.

The question now is:

Is there more pepsi in the sevenup jar than seven-up in the pepsi jar, or is it that there is more sevenup in the pepsi jar than pepsi in the sevenup jar?

This riddle simply proves that casual reasoning cant be trusted.