Introduction to Cloude Computing

Introduction to OpenSocial API

Probably I would be the most late comer writing about the OpnSocial but I still think there is no full-blown information available about OpenSocial at one place. In this post I am trying to collect all the possible information about OpenSocial in short.

‘OpenSocial is a set of common APIs (Introduced & led by Google Inc. along with its partners like Yahoo, Ning, Hi5, LinkedIn, MySpace & Plaxo) for web-based social networking applications which enable social networks to host third-party application(HTML/JavaScript & may embed Flash) with in them and provides ability to third-party application developer to host their application on multiple social networks(OpenSocial)’.  Please see OpenSocial on Wikipedia (http://en.wikipedia.org/wiki/Open_social) for complete history and background. However there is an official wiki for OpenSocial(http://wiki.opensocial.org/index.php?title=Main_Page). The goal behind to develop OpenSocial was having a common standard of application development ‘Learn once, run anywhere’.

Introduction to Groovy & Grails

Yesterday I have attended an XTR (Xebia Tech Rally) on Groovy and Grails by Sunil & Nancy. Here I want to share my experience and learning with you all:

Groovy is a dynamic language.  I wont go in much details about dynamic language but for now you can just understand like dynamic language allows you to change the behavior of your objects at run time. In Groovy every operation is executed through reflection (reflection is a programming technique of re-engineering, that means they can observe and modify themselves). I think this gives Groovy the ability to be a dynamic language (but makes it a bit slow too). There is a lot of other concepts which are there in Java but enhanced in Groovy. For example in Groovy everything is Object, even primitives are also converted in Objects, dynamic type detection etc. Groovy code is compiled in byte code and executed in JVM.

Google Insight: A Technology To Search On Search Data For Businesses

Recently I have come across to another great technology from the web search giant Google: Google Insight for Search (http://google.com/insights/search/#). It is another innovative idea to use the data collected by millions of searches a day on its search engine. Google Insight is basically a tool which can help you look into the user’s search trends over various parameters which could be useful for business.

With Google Insight you can search on any search term/phrase searched over/during a time period, by geographical locations and categories (Like Arts, Sports). You can even compare two search terms for being searched by your criteria. Google Insight gives a good set of results including:
1. Graph showing the number of search over the time for the given keyword/search phrase
2. A location wise chart displaying origin of search for the given phrase
3. Top news headlines including search keywords
4. Top searches including the search phrase and also list the search phrases rising into number of count including the given keyword

Google Insight in just one line is: A search on all the search made through Google. It means when a users search on Google, its been recorded for future use and hence huge database of user search has grown. Google insight gives you an interface to look insight its database for your own purpose.

Social Enterprise: Better Business Opportunity

Enterprise software are intended to link people in the organization, let them communicate & collaborate to streamline processes, improve productivity, increase the innovation, easy and fast tracking, brainstorming, share complete-updated-focused information and knowledge etc…

Few examples where communication & collaboration is important:

1. Brainstorming any issue or idea
2. Feedbacks/Follow-ups/Status
3. Task allocation and tracking
4. Various documents sharing inside the organization
5. Collecting the individuals knowledge to be used by others
6. Having some general consensus on various topics like product ideas or new features or a Policy adoption
7. Interacting with customers & providing support

Getting Started With Ruby on Rails

Int this and after this following post I would try to make you able to create your first project in Ruby on Rails. I will cover this topic from scratch. I hope you will find this useful.

So, here wo go.

To understand ROR we should first know what is Ruby?

Ruby is an open-source, multi-paradigm, interpreted programming language

Open Source

We called any product an open source when the code of that product is available for free. We can use it, modify it, and reuse it for their purposes and the improvement of that product. The benefit of open source is chiefly that you get a lot more minds working on a project than a proprietary project.

Multi-Paradigm

Ruby is a multi-paradigm language because it doesn’t constrain to a single programming mindset; you can use any of the aforementioned programming (OO, procedural etc…) paradigms with no problems in Ruby.

Interpreted

If you’ve used something like Assembly, Pascal, Fortran, or C/C++, you’ve used a compiled language. “Compiled” means that you’ve had to run your code through a little compiler and it spits out some sort of native code that will run without any sort of interpretation by the computer other than by the operating system itself. This can become time consuming as your project grows larger and larger, and sometimes can even be a severe hindrance to productivity. But on the other hand, Ruby is an interpreted language, which means that there is an interpreter that reads your code and then emits native code to the operating system.

Ruby on Rails is a framework that makes it easier to develop, deploy, and maintain web apps.

All Rails applications are implemented using the Model-View-Controller (MVC) architecture. Java developers are used to frameworks such as Tapestry and Struts, which are based on MVC. Rails applications are written in Ruby, a modern, object-oriented scripting language. Rails take Ruby to the limit, extending it in novel ways which make a programmer’s life easier. This makes our programs shorter and more readable.

The design of Rails was driven by a couple of key concepts: DRY and convention over configuration. DRY stands for Don’t Repeat Yourself—every piece of knowledge in a system should be expressed in just one place, A place often suggested by the conventions of the MVC architecture—and then move on.

Architechtural Mistakes

In the Software industry the most critical task is to create a design an application or a solution for a problem. This design or solution ensures that the application will will run under the most of the known circumstances for an software application. It also ensures that system will provide requires functionality, availability, security and performance for its stack holders.

Eoin Woods, one of the IASA Fellows posted an article about the top ten software architecture mistakes – mistakes that are too often. Brief excerpts of the ten points are below:

1. Scoping Woes. “This is the sort of situation where a simple travel booking system ends up with full expense claim management facilities being built into it, with inevitable repercussions for project costs, timescales and quality…It is really true that no security is needed beyond simple login? Once logged into the system can users really perform any system operation?”

2. Not Casting Your Net Widely. “A related mistake that many of us have made is to focus on just a couple of our system stakeholders – classically the acquirer (who is paying for the system) and the end users get all of the attention.”

3. Just Focusing on Functions. “…unless the system exhibits a whole range of qualities (such as performance, security, maintainability and so on) it is unlikely to be successful.”

4. Box and Line Descriptions. “There are two reasons why the [single, all inclusive] huge Visio picture doesn’t work well as an architectural description: firstly, it’s trying to show too much information in a single representation, and secondly, no one is really sure quite what each of the different types of symbol that you’ve drawn mean.”

5. Forgetting That It Needs to be Built. “Common things to watch out for related to building the system include designs that the developers or testers don’t really understand, technologies that they aren’t enthusiastic about or don’t have the time to learn, and new technologies that don’t yet have good tool support or perhaps impose a new and unfamiliar way of working.”

6. Lack of Platform Precision.“…its no longer sufficient to simply say that you “need Unix and Oracle” when specifying your platform. You need to be really precise about the specific versions and configurations of each part in order to ensure that you get what you need. This will allow you to avoid the situation where you can’t deploy your system because someone has helpfully upgraded a library for one part of the platform without realising that it means that something else will no longer work.”

7. Making Performance and Scalability Assumptions. “Start considering performance and scalability early, create performance models to try to predict key performance metrics and spot bottlenecks and get stuck into some practical proof-of-concept work as your design ideas are forming. This will all help to increase confidence that there aren’t any performance and scalability demons lurking in your design.”

8. DIY Security. “A mistake made in many systems over the years has been to try to add security into the system using “home brew” security technology. Be it custom encryption algorithms, a developer’s own auditing system or an entire DIY access control system, locally developed security solutions are rarely a good idea. While most of us think we could probably whip up a clever piece of security technology in no time, we’re usually wrong.”

9. No Disaster Recovery. “The key to getting resources to implement a DR mechanism for your system is to be specific and quantify the cost of system unavailability in a number of realistic scenarios. If you can also estimate the probability of the scenarios occurring then you can use these two figures to convince people that DR is important and to justify a certain level of budget to implement it.”

10. No Backout Plan. “Make sure that whatever happens during the deployment of your system or upgrade that you have a documented, reviewed and agreed backout plan to allow you to restore the environment to its state before you started deployment.”

Eoin Woods is a software and enterprise architect at UBS Investment Bank.