1. Online: The content is available immediately on request.
2. Nearline: The content is made available within 5 minutes of request.
3. Offline: The content is made available within 4 hours of request.

Advantage?

When you are storing content primarly for backup, you don’t need the backup system to be online. Files such as these can be moved to a disk which is later powered off: this benefits huge cost saving and is a greener approach.

Due to this innovative model, DiomedeStorage is able to offer services which are fraction of the cost of S3. Beautiful innovation

Given Oracle’s acquisition of SUN, I am quite unsure if Oracle would continue investing in a Kenai.com. Or, for that matter, in Netbeans (I am a Netbeans addict, and pray that they do it).

So what have I done? I have created an account in Kenai.com. But, for the moment I am not going to host any of my OpenSource initiatives in Kenai.com. Wait and see is the only thing I can do now.

I tried the same in Google, and found the same result.

• Uncertainty. They know existing code works. Refactoring existing might break some functionality.
• Time. The time to refactor code cannot be correctly estimated.
• Work. Of course, this is additional work.

There may be other reasons (for example, greed. The programmer might want to gain a short-term acknowledgment of his speed of delivery). But the common occurrence is Fear. And we will try to understand the implication of this fear:

• Old code gets older.
• Additional code to manage deficiencies in old code need to be created.
• The application becomes monolithic and difficult to change.
• This creates additional fear of change.

The cost involved in maintaining such code is stupendous. And how do we avoid this cost? It is, from my experience, by following some good-old practices and tools:

• Unit tests: The importance of these cannot be exaggerated. When you have a Unit test suite covering your code, it is with more confidence you can refactor it, and more confidence with which change it.
• Each developer gets his own play area: Sharing resources during development is also costly. This is the reason I encourage each developer to have his own database setup and development environment (whenever possible). This isolates the developer, and his fear of breaking the shared environment is nullified (which affects other team member’s productivity). He is more free to innovate and bring in new thoughts.
• Developer’s own coding and commit space: I also encourage people to use distributed source control systems in place of things like svn. This allows the individual to have a independent commit space, where he can commit his work as and when he completes a unit of it, without worry of breaking someone’s build. Again, a source of greater freedom.

I have seen the most unlikely people innovate by following these simple practices. So what is your take on this?

If HTML/XHTML provides some kind of script exclusion so that scripts placed inside a particular scope do not reveal their functions and variables globally across the page, it is going to be helpful. For example:

<script-package name="abc">
  <script src="prototype.js" type="text/javascript"/>

  <script type="text/javascript">
    // use prototype specific code
  </script>
</script-package>

<script-package name="xyz">
  <script src="jquery.js" type="text/javascript"/>

  <script type="text/javascript">
    // use jQuery specific code
  </script>
</script-package>

In the rare case when a script needs to access some variable defined in different package, it can use some namespace mechanism. Any ideas?