Wednesday, August 30, 2006

Saturday, August 26, 2006

Arabic Wikipedia Day

شارك معرفتك - ويكيبيديا، الموسوعة الحرة
Share your knowledge today August 26, 2006..

The Idea:
* A full-day job [24 hours] where interested volunteers gather together to contribute to the writing of the Arabic Wikipedia..

* Put up a list of articles to be created or updated or corrected and the volunteer work on the essays or articles of particular importance to him..

* Each volunteer can be involved from home, but all together are virtually gathered in one chat room
( IRC )

Arabic Wikipedia probably suffer from a severe shortage of content compared to lesser known languages, and spoken by a limited number of people. A large proportion of the pages of Arabic Wikipedia probably be imperfect and incomplete, and may not contain more than a few words. Therefore, we aim of this idea is to encourage people to participate in the Arabic Wikipedia and dissemination of the idea as much as possible..

<? adjuster ?>
Send me an email

Tuesday, August 15, 2006

Be Smarter Than U R

While searching the Web for PHP code snippets, i found this interesting one:

if( you == smart ) {
    languages += "php";

sure thing this snippet is:
- a piece of art
- extremely fast
- secure
- cross-platform
- cross-browser
- easy to learn
- cheaper to host
- can be compiled using Zend Accelerator for more extra speed
[most developers know NOTHING about this point]

<? adjuster ?>
Send me an email

Friday, August 11, 2006

Important Programming Truths

This page contains a number of important programming truths that every programmer should know about. These truths are self-evident, and need no explanations.

If it compiles, it works.

If it compiles, it's correct.

If it runs, it doesn't have any bugs.

If it doesn't have any immediately obvious bugs, it's perfect.

If a bug doesn't show, it doesn't exist.

If it seems to work, it works.

Doing something right is easy. Avoiding errors only takes a bit of concentration.

The shorter the source code, the faster the program.

It's obvious how to optimize a program.

Prorammers don't make mistakes.

Run-time errors don't occur.

Users don't make mistakes.

I don't make mistakes.

Errors of any kind are rare.

Error handling can be done in version 2.

It's OK to crash on bad input.

It's OK to give incorrect output on bad input.

Portability isn't useful.

All the world's a VAX. Or, these days, an MS-DOS box.

The length of the feature list is important.

Speed is good, features are better.

Slowness can be fixed in hardware.

The bigger a program is, the better it is.

Random changes to a program fix bugs.

Testing takes only a short while.

Finding bugs is easy. Fixing bugs is trivial.

Bug-fixes don't need to be tested.

Trivial changes of any kind don't need to be tested.

The first approach, idea, or version is always the best.

A 1% crash rate is actually pretty damn good.

Code is self-evident. Comments aren't needed.

Comments are meant for people other than the original author of the code.

Undocumented features are fun and useful.

It can always be fixed in the next version.

Surprised users are happy users.

Demonstrating for clients is the best debugging method.

<.adjuster />