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.

The Problem With Technical People .. Business Wise

In the software business, the main problem with technical people when it comes to finding 'the idea', is that they easily deviate in their thinking processes from the main objective which is usually building a profitable business.

Instead of thinking rationally about 'how could my idea turn into a business', they easily end up in the thinking processes of 'how could my idea fulfill my creative and technological demands'.

This puts them through misjudgements leading to completely ignoring really good ideas while researching different market niches for reasons like "the idea didn't tick", "wasn't creative enough", "wasn't technically difficult", or simply "I dont like it". They forget the main purpose of the idea which is "creating a business", a growing profitable money generating business, they forget the whole purpose.

I'm not saying that technical people should change their mindset, I'm one of them, and I just cant. If the idea aint technologically stimulating enough, I find it hard to continue. But my advice for any technical person would be the following:

1. Business Value. Make sure there is a commercial value and your idea's category exists.

2. Love your idea. You're not a business person, so money isn't your main driver. Its the idea itself, so make sure you're convinced, you love it and you'll finish it.

3. Use your idea. It would be an excellent advantage to be your own customer and use your idea continuously, this will guarantee future enhancements and growth.

4. Always stay in touch with business minds. You need business advice, so take as many as you can from marketing, sales, software blogs, etc.

With all this advice, and I'm telling you, chances are so limited for you, you'll be wasting alot of time until anything good happens.

Whether you like it or not, business people are the best when it comes to spotting a good idea (or even coming up with one). Their main motivator is money generation, so, if the chosen idea is a good money generator, then they will already be in enough love with their idea to accomplish it and they'll use it as long as it generates money. Their idea's growth will be completely based on market needs.

Bottom line, we - the technical people - suffer from a major bug when it comes to business thinking. This bug can be simply stated as:

"Our passion for technology and our love for creativity deviates us away from good money generating business ideas, we suffer from this bug, business people dont, we'll have to live it, business people wont."

In search for a good technical site or magazine.

I'm looking for a good technical site with some interesting articles. I can hardly find any, i'm not looking for code only articles, but rather a technical site with a diversity of subjects concerning the different issues in the technical industry.

I also used to enjoy the Linux Magazine (hard copy), but it is no longer sold in Jordan :( This happened after the war in Lebanon, I presume the main distributor was in Lebanon. Anyways, its too costy (about 12 JDs) but really had a diversity of very interesting subjects. Ofcourse, they provide old issues for articles in their website at http://www.linux-magazine.com.

So please, if anyone knows a really good up to date website concerning Java, PHP, C, design articles, tools, components then please drop me a comment.

Thanks!

Monitoring Tools with Zoom In Capabilities

One thing I learned when purchasing, using or even building a monitoring tool is the following:

"Monitoring Tools with no Zoom In Capabilities are Worthless!"

So make sure not to waste your budget or time in any monitoring tool that does not provide zoom features to exactly trace sources. An example would be an httpd weblog analyzer. With all the fancy reports generated using tools on the web, if I just cant click on the graph and zoom in into more detailed information, then thats a big problem.

I'm happy to monitor thirty people entering my website on thursday, but I would like to zoom in the same graph to see at which hours of the day, further zoom in to see which countries where they from, then further zoom in to see which pages a certain visitor has gone through then further zoom in to see the amount of time he stayed on the website. Thats what monitoring tools all about.

Same goes to network monitoring tools, same goes to employee monitoring tools, task tracking tools, code analyzing tools, its just that, you either have a built-in magic zoom button or stop soliciting your monitoring software.

Stable Software

From a black box perspective, stable software boils up to the following:

1. Good usage of Version Control Systems. Branching revisions, branching features, tagging releasing, merging, detecting flaws from versions logs, histories, comments and generated diffs. After being able to use version control correctly, I'm starting to wonder how I ever by-passed such a requirement.

2. Good Bug Tracking. I'd rather call it 'good issue tracking', since its not always a bug, it could be a required future feature, a priority for the next release, a recommended third party code to use, a small research signifying or recommeding new code structures. Bottom line, being able to track the past, present and future of your software's needs.

3. Good Quality People. Not the ones that randomly click everywhere trying to spot a bug. No, I'm talking about Smart Quality People that can intelligently utilize (or even build) testing tools and automation scripts to consistently be able to test every build and every release in a convenient time without having to repeat the quality cycle all over again. In short, good quality people build good quality assembly lines that result in consistent high quality output for every minor or major release launched.

Quote Of The Day

“People make all the difference in the world. Venture capitalists would tell you that they’d rather fund a great team than a great idea. The reason is that if they have a bad idea, great teams can figure out a better one. Mediocre people even with a great idea can screw it up in its execution.”

- Joe Kraus, Founder of Excite and JotSpot
Interviewed by the author of Founders At Work (book)

Trends and Fads

Most ideas start as 'ideas'; abstract implementations existing in a (human's) mind.

The two most obvious patterns signifying an idea's life time are a 'trend' or a 'fad'.

Fads tend to shoot up quickly then suddenly die with no warnings. During their shooting time, fans of fads feel so confident about growing in to a trend, and feel so down when their raging idea diminishes.

Trends on the other hand, are ideas that flourish gradually and strongly replacing any fads they meet in their way. Trends are hard to achieve, and their achievement clearly proves the rigidness of their contained idea.

No matter what the background theme is, fads and trends are reliable recognition patterns that can be consistently used to identify an idea's progress. However, the judgement cant take place until a reasonable amount of time has passed.

From my humble observations, i can say that the fad to trend ratio is 99 to 1, i.e. from every hundred ideas we've got about 1 trend and 99 fads. At least this works fine for product ideas rising from the commercial industry.