1. 30 Great Website Designs - Part 1

2. 30 Great Website Designs - Part 2

3. 30 Great Website Designs - Part 3

4. 30 Great Website Designs - Part 4

5. 30 Great Website Designs - Part 5

6. 30 dirty web designs

7. 50 Beautiful CSS-Based Web-Designs in 2006

8. Web design inspiration set at Flickr



Happy Designing.//

I have learned and practiced "continuous development" and "continuous engineering". Does something called "continuous destruction" exist? I think it does exist, its just that we don't consider it as an area of study or practice in the Software Development Life Cycle. I think disposition of a component of a system is critical to its survival in this fast moving world of technology.

Continuous destruction should happen at all levels of the engineering community. From the top level product management to the individual coder, we should probably have the attitude to identify what to throw away and come up with something better.

It usually happens that we wait for the system to become obsolete or wait for someone to tell us that we need something better. After a new system is developed and delivered we generally sit down and relax and go into dividend earning mode.

So what’s stops you from destruction? Is it the lack of courage to change your “presently good system”? Is it the courage to tell yourself what runs short in your existing system? I think it’s the lack of inputs to decide what’s important and what’s not important for the system. What else?

In my current life as a developer, most of the successful designers are those who seem to have the guts to throw away their existing work or constantly evaluate parallel technology. These developers end up delivering more quality components. How many time shave you seen successful consumer products change their User Interface. Many do. Dont they?

The idea of "destruction" however is not studied as a phase in the Software Development Life Cycle, which I think we should be doing. Not doing so, makes different people with different roles in the project have separate ideas and energy about the idea of software destruction.

Related interesting link: Would Google destroy Digg or take it to the next level?

Happy destruction.//

No matter how good is your debug logging or your debugger, there are times when you think that its quicker to just put in one printf("I am here"); statement to debug your code. One thing to remember is not forgetting to print the the End-Of-Line character.

printf("I am here"); is different from printf("I am here\n");
In the former case, the print may get delayed and if your program crashes immediately you may be even get this line printed making you think that the control did not reach this line. So always use printf("I am here\n"); if you at all use this debugging technique.

Happy Debugging.//

HowtoForge is a great site containing tutorials on how to perform setups of various tasks on Linux systems. From stuff as basic as a simple C++ tutorial to How to setup Load Balanced Cluster on MySQL, they have a very good collection of community contributed articles. Next time if you are looking for a how to its worth seraching here than simply replying on Google results and hunting down the correct one. Go to http://www.howtoforge.com/.

Happy following.//

What does 99.99% availability of a service mean? I always though that it meant that there is 0.01 percent chance that the service would be unavailable. I thought that it was just a humble way of saying that there would hardly be any downtime. But thats not true as what I know today.

In the Amazon S3 FAQ , they say "The service was designed for 99.99% availability, and carries a service level agreement providing service credits if a customer's availability falls below 99.9%." I take Amazon S3 as an example because Aminus3 uses Amazon S3 to store its image files and we had an outage last week, the longest that we have seen so far.

And here is the meaning of all those 9s:

A 99% reliability means an acceptable downtime of 3.65 days a year.
A 99.9% means an acceptable downtime of 8.76 hours a year.
A 99.99% means an acceptable downtime of 52.56 minutes a year.
A 99.999% means an acceptable downtime of 5.26 minutes a year.

These numbers are straight forward calculation:

Example: 1% downtime means .01 * 365 = 3.65 days.

Of all this 99.999% is considered to be the ultimate which is often referred to as the five nines of uptime.

Happy uptiming.//