indiWiz.com

I use Amazon S3 for delivering content and as backup. Today I was introduced to an improvisation to the cloud storage model (offered by DiomedeStorage): demarcating the storage into different types:

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

The post is interesting. Kenai.com as a cloud based project hosting infrastructure is interesting. But …

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 wanted to find the local time in Italy, and I got the result without clicking on the search result:

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

I have seen this scenario many times: programmers fearing existing code, writing extra code just to accommodate new features without changing existing code. A similar attitude I see is, is manifest in projects dealing with big databases. People working in these projects don’t dare to question the design of the Database, and subject themselves to finishing the tasks at hand to fit around the existing DB design. This is fear. Fear of:

• 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?

Yahoo! still innovates When I searched for java.lang.String, Yahoo! presented me with links to various versions of this API neatly stacked one near to another for me to choose. Cool guys!

I am working currently in a portal project. From various datasources we collect information and publish as portlets. The current UI scenario requires us to use JavaScript libraries like prototype.js and jQuery. In both these libraries, $() has different meaning. So when we tie a particular portlet’s UI to prototype.js, and another to jQuery, we cannot effectively place both of them in the same page.

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?

If there is one web-technology that I hate, it should be ActiveX. Google engineers seem to have faced the same issue. They developed Native Client. Now it is easier, more secure to develop and run native code in any browser in any platform. Thanks guys