Nanotechnology will be one of the greatest innovation of 21st century. Although a lot of research is still underway in this area it is promising.  Nanotechnology is all about getting deep down into the level of working with atoms.  If there was a way to arrange the atoms in a way that could significantly reduce the design of physical material to a nano scale (one billionth of a meter) then we are talking about nanotechnology.  Researchers have designed a guitar that is the size of a red blood cell which will give you fair idea of the size that we are talking about.  Nanotechnology could be applied to so many different areas like space research, medicine, computers etc.  With nanotechnology in place a computer of matchbox size can hold and handle more than the kind of infrastructure that now Google has to perform its functions. With nanotechnology a sofa could be built so light that you can lift it with one hand without effort. Here is “How Nanotechnology will work” from HowStuffWorks.com and an interesting article “Nanotechnology:  It’s a Small, Small, Small, Small World” that gives an elaborate introduction to this technology.

Tags are one of the important concepts of Web 2.0. It is a way of categorizing an area and largely done by the users themselves. For example if you like this post you could add it to your del.icio.us and give tag names that bring this post under those categories. You might tag them under “web 2.0″ or “categories” and so on. The closer and the more users start to assign the same tag name to a particular item, the more chance that someone looking for that item can get by searching through that tag name.

Tag names could either be system generated if there is taxonomy already available or it could be assigned by users. For example if you are building a site that gives details about living things there is already a taxonomy available and it is easy to just use that. But if you are building a website where users contribute information, it is best to allow the users to tag items by themselves. Gmail is one of the best and foremost examples of web 2.0. In Gmail there is no concept of having folders and dropping the mails into the appropriate one, rather mails are tagged with labels. So a mail could belong to more than one category, so it is possible to label them under those categories.

Event Driven architecture closely resembles publish subscribe model in terms of notifications to appropriate parties at the appropriate time.  But event driven approach is much beyond than publish subscribe.  Here is a good article “Event-Driven Architecture vs. Publish-Subscribe Systems” that talks about event driven architecture and also gives the difference between it and publish-subscribe model.

Think of all the facilities that you have in your lifestyle for which you have subscribed.  Examples could be newspapers and magazines, cable TV, internet connection and the list can go on.  Think about this model. A publisher here is an entity that is capable of producing and/or delivering information/content of specific type.  A subscriber is the one who wants that information/content to be consumed.  There could be many publishers each of them having many subscribers.  Putting it differently there could be many subscribers subscribed to many publishers.  In every model there is a contract or an agreement that binds two entities.  In case of a publish subscriber model the contract is that a subscriber subscribes to a publisher and once the subscription is enabled the publisher delivers the information/content to all its subscribers at appropriate time without the subscriber requesting it.  Think of subscribing to a local newspaper agent who will put newspaper at your doorstep every morning.

Publish Subscribe model is popular in the software industry.  The differentiator with traditional client/server approach is the way the information/content is received by the client.  In the traditional approach, the client requests for specific information from the server and the server sends back the information.  In publish subscribe model once the client subscribes to the publisher, the publisher pushes the appropriate information/content to the client without the client requesting it.  The former uses the pull technology and the latter the push technology.  Typical examples of such a model is subscribing to newsletters, online magazines, why even the RSS feeds you receive from TechMasala as well.

There are also cases when the client will not know who or where the publisher is for the information/content it is looking for.  In such a case there are brokers whose primary role is to help subscribers subscribe to the publisher who can deliver the content it is looking for.  This broker has the list of publishers and what they can deliver.  A subscriber could talk to the broker, tell its requirement and the broker gets the subscriber connected to the appropriate publisher.

My post “Use of Flash for rich web applications” talks about using Flex as a presentation layer framework to utilize the power of Macromedia Flash for rich UI application. Here is a simple tutorial on using Flex - “30 Minutes Flex Test-Drive for Java Developers“

Happy Weekend!

A use case is a technique to capture the functional requirements of a system.  How is it different from a requirements document? Use Case talk more from the domain and the user perspective rather than using any technical jargon. Assuming that a system interacts with the users called as actors, each use case represents a situation, the interactions between the system and actors involved and the purpose. Use cases are done by business analysts and validated by the customer.  A use case is the first step to capturing the requirements and gets translated into other areas of the software development lifecycle.  Here is a useful pdf document on use case template from bredemeyer.com.

It is a treat time for Compassites. After the talk treat from Jnan Dash on the future of IT we got the treat from Rajesh Setty couple of days back. Now it was time for learning some soft skills. Rajesh spoke on the seven habits one has to cultivate to become an effective software engineer. It was an inspiring talk that made all of us think and was a checklist to constantly evaluate. Though it was targeted for software engineers with details around the project-client lifecycle, these points are very much valid for any person belonging to any industry. Here is a summary of those seven points.

1. Exceed expectations - Expectations are there around always. There are expectations from your boss, expectations from your peers, expectations from family members, expectations from friends and so on. People expect and expect more. Before you can meet expectations you need to validate whether you understand if those expectations are right. Otherwise it is your duty to make sure that people expect right things out of you. It is always easy to meet others expectation if you know how to exceed the expectation. Keeping up promises is one important aspect that people rightfully expect. When you constantly exceed expectation a trust automatically gets established and trust is an important factor that can strengthen the relationship.
2. Individually set higher standards - Benchmarking and raising the bar always pushes you ahead. More than someone setting a target it is very important that you set a target for yourself and keep pushing it as and when you meet it. This trait complements point 1 and helps in exceeding expectations.
3. Influencing the influencers - Being an influencer is a skill of its own and requires tremendous talent and is not an easy task. But if you become one then it’s like having people who will blindly follow your advice. Suppose Ram is a great influencer of Shyam. Shyam’s decisions most of the time will be greatly influenced by the advice Ram gives to him. If you know to influence Ram then you have a chance to indirectly get Shyam’s green signal on things that he expects from you and takes the advice on it from Ram.
4. Expect recognition for result and not effort - This is a fantastic point and I loved it. Most common cause for a lot of frustrations and de-motivation is not realizing this point. You might have burnt the midnight oil to complete a task. But ultimately it is the result that matters to the person who is expecting this task to be completed. He/She does not care how you complete it or what difficulties it took you to complete it. But if you have completed the task and give the expected result then you have the right to expect recognition. But again you might sometimes get that recognition and sometimes not in which case you have to keep moving on.
5. Keep promises that you make to yourself - A valid point that a lot of us don’t do because there is no accountability as most of the times no one knows that you have promised yourself in the first place. Even otherwise it is so easy to find a reason for not keeping it up but if you think about it you definitely know that it was a stupid reason.
6. Package information for easy consumption - When someone is expecting something out of you, all he/she wants to know is exactly what he/she wants to know. So it is important to highlight and group relevant information in the right sense and give it in a way that the person expecting it can consume it with minimal effort and time.
7. Focus on Return on Investment for an Interaction - ROII - Rajesh’s trademark term. Search for ROII on his blog and you will find enough on it.

The one hour session was very inspiring and intuitive. We are very fortunate to have Rajesh part of Compassites board and we are hungry for more talks from him and look forward for his next visit.

Rajesh’s book “Beyond Code - Learn to distinguish yourself in 9 simple steps” is now available in India. You can buy it online from gobookshopping or itbytebooks.

Checkout Chennai’ites, Rajesh is going to give a talk in India’s biggest bloggers unconference on September 9th and 10th.

Curiosity can sometimes lead to self motivation. If you are a curios person always trying to question why or how then you will automatically be doing a lot of things in parallel to know why something has to work the way it works (one of my all time favorite site is “How stuff works“). At the same time when you learn something new you might have to try something new to really learn it. And there is equal chance that you might mess up something in the process. You also need to have an attitude to think “So what?” and still go ahead and try doing it. After all messing up with machines is better than messing up with people. If everything goes well you will have a satisfaction of learning something right the first time. If not still you will learn something - to correct what you have messed up . Ultimately for every attempt you make to do something new you either way end up learning something.

One typical area that I can point out to developers is the deployment of the web application to the web server. I have not seen many developers exploring this area. You don’t need to do it on a production environment; your desktop could still be the best place to play around. Knowing about the web server, application server configurations and deploying an application on them is very important as you grow up your career on the technology front. So unless you are not afraid to play around on your local box you will never get a chance to confidently configure and deploy applications on a production environment.

You might also want to look at my post “Tips to become a software professional“.