R & D Over Orkut opensocial API

17 06 2008

Hi All,

For the last few days i was doing R&D with Orkut opensocial API. Though it is a good effort from Google and all other Social sites but the documentation is i think is not up to the mark. If you ask me what is opensocial the i could say, it is a set of Application Programming Interfaces (more likely APIs in Java) based on standard HTML and JavaScript formed in XML, simplifies the creation of web-based applications that interact with social networks which can be developed and distributed by anyone means it is open also. Though it is firstly launched by Google in November 2007, many other social network sites supporting it. The sites supporting opensocial movement are orkut, MySpace, Yahoo! , hi5, and Friendster etc. So it is going to have a great fun learning it as the whole world of social communities sooner or later have to accept this. So i think of start guiding the beginners in this field.

Don’t be scared. Keep reading. Soon I’ll post the starter guide to develop applications for Orkut with opensocial API and run them on Orkut Profile. Keep watching!!! Ciao :)





Developer efficiency myths and truths

15 11 2007

If you read the ads in development-related magazines or on Web sites, you would think that solving development inefficiency is a great path to making big bucks — and I believe that it is. There are tons of products on the market that claim to improve developer efficiency, from different languages to IDEs, automated build tools to automated build environments. I will try to bust some myths, bring to light a few truths, and show some partial truths regarding developer efficiency.

Myths about what leads to developer efficiency

#1: Drag ‘n Drop IDEs are the be-all and end-all.

Drag ‘n Drop IDEs are great… for building UIs. Outside of using a Drag ‘n Drop IDE as a graphical code generator for UI-specific tasks, they universally stink. Unless you are writing an application so basic that the IDE’s assumptions about how code should be written won’t hurt things, chances are you will rip out at least half of the code that the Drag ‘n Drop IDE put there for you. Go ahead, use Visual Studio or Eclipse — they are great IDEs. But be wary of trying to drag ‘n drop your way to a complete application.

#2: Slumber parties at the office equal more quality work completed.

I call a workaholic programmer who regularly pulls all-nighters The Martyr. It is tempting to think that putting in more hours equals more work, but most developers are spun out by 5:00 PM. Development is brain-taxing work, and you cannot do it when you’re tired or improperly nourished. A late night here and there may pay off, but chances are, the quality of the work done past 6:00 PM or 7:00 PM is low, and the next day your efficiency will be in the toilet. Avoid the late night work whenever possible — you are not nearly as efficient as you’d like to think.

#3: Caffeine, nicotine, and sugar are your friends.

Caffeine, cigarettes, and sugary beverages contain chemicals that might provide a temporary boost in awareness, alertness, and concentration. But the 30-minute jolt that a can of Mountain Dew might give you is followed by a much longer crash that dulls your senses and fatigues your body. This is why you see people with trash cans full of soda bottles, cigarette packs, and coffee cups; they need to continually ingest the chemical(s) of their choice to find a balance. Trust me, I have been there myself (regrettably, I started drinking coffee again a month ago, but I am still cigarette and sugar free). Try to replace the coffee with water, the sugar with fruit, and find a way to quit smoking. Not only will you stop feeling the nasty side effects of coming down, but you will also have much fewer interruptions when you do not need to leave your desk constantly.

Truths about what leads to developer efficiency

#1: Environment matters

No, I am not talking about Al Gore or Greenpeace. If you are in an office, I bet good money that there is a standard fluorescent light bulb over your head. It probably cost the builder $45 or less to install; meanwhile, full-spectrum task lights can easily cost over $100.

Ever notice how many IT pros turn the lights out in the office? It is because fluorescent lights are horrible on your eyes when you’re using a PC; turning the lights off reduces the immediate stress on your eyes that causes the 2:00 PM headache. The problem is that your eyes dilate even more when you turn the lights off, letting even more of the eyeball killing monitor light damage them. In other words, the short term “fix” does long term damage. Go ahead, buy the $100 task lamp; it is cheaper than a new pair of glasses or contacts, and it will improve your efficiency significantly since you won’t be in pain by mid-afternoon.

#2: Practice makes perfect

A lot of developers think that warming a chair for 10 years makes them a better programmer. The fact is that someone who spends time reading about new ideas and trying them out on their own time is going to learn valuable lessons that they can apply in their day-to-day work. If you want to become more efficient, I suggest spending time working on a project (at home or set aside an hour or two a week at the office) that is related to work but that uses techniques that are new to you. You will discover that learning new techniques always pays a huge dividend.

#3: Limit interruptions

Your manager is making you less efficient. Every time he or she stops at your desk for a quick status update or e-mails you a memo reminding the team of the dress code policy, your concentration is broken. Even a slight distraction of a minute or two can take many more minutes to recover from and get back in “the zone.” Add that up over the course of a day, and you could be losing up to an hour’s worth of time where you are fully “in the problem” due to your manager or a coworker interrupting your thought process.

Close the door (if you have one), put blinders on so people near you don’t bother you, and close your e-mail and IM clients. Limit opening your communications software to a few times a day (after a meal, a restroom break, or other similar time is perfect, since you have already lost your train of thought anyway). If it is really important, they can pick up the phone and call you.

Partial truths about what leads to developer efficiency

#1: Code generators may lead to more work on your end.

If you are doing a ton of rote tasks, like creating the accessors for a class that represents a 200 element XML schema, code generators are great. Drag ‘n Drop IDEs make short work of generating UI code, but unless your task is extremely generic, you will probably spend more time tweaking the generated code than it would have taken you to just write it yourself. For specialized tasks, sometimes a text editor that supports regex find/replace or a spreadsheet program like Excel can do a task in a few moments where pricey code generators fall flat.

#2: Language matters some of the time.

Sometimes language matters, and sometimes it doesn’t — it is completely situational. For example, many of the languages that can be written extremely quickly thanks to type inference or syntactic tricks are often difficult to follow when they are maintained. The two minutes worth of typing saved can cause an hour of wasted time down the road. The current mainstream languages (Java, VB.NET, and C#) are all so similar (VB.NET is slightly more verbose) that none of them are particularly more efficient to work with. Some languages do have unique properties and advantages that can significantly impact development time. For instance, try writing something that is as pure logic (or math) as a weather forecasting system in C#, and you’ll be sorry. On the flip side, a typical Windows desktop application written in Fortran will probably take forever. Library support matters too; some languages, despite being weaker, in and of themselves, have library support that makes up for it.

#3: Personal life

Developers who get phone calls from friends and family for a total of two hours a day are probably not going to get much done. However, locking people down is not going to fix the issue of personal calls either. For many people (particularly those with children), a five minute phone call might save a trip home. In an ideal world, developers would not let their personal life and issues affect their work. In the real world, an argument with a spouse, money worries, the kids’ grades, and so on can and will spillover into someone’s work time.

So, for all you managers out there, while personal telephone calls represent an obvious inefficiency, it’s fairly useless to have a programmer in the office who has something heavy on his or her mind. They won’t be able to concentrate anyway, so go ahead and let them do what they need to do within reason.

Are you a developer??? cheers Aurobindo





Web Site Development Process – The life-cycle steps

31 10 2007

A system development process can follow a number of standard or company specific frameworks, methodologies, modeling tools and languages. Software development life cycle normally comes with some standards which can fulfill the needs of any development team. Like software, web sites can also be developed with certain methods with some changes and additions with the existing software development process. Let us see the steps involve in any web site development.

1. Analysis:
Once a customer is started discussing his requirements, the team gets into it, towards the preliminary requirement analysis. As the web site is going to be a part of a system, It needs a complete analysis as, how the web site or the web based application is going to help the present system and how the site is going to help the business. Moreover the analysis should cover all the aspects especially on how the web site is going to join the existing system. The first important thing is finding the targeted audience. Then, All the present hardware, software, people and data should be considered during the time of analysis. For example, if a company XYZ corp is in need of a web site to have its human resource details online, the analysis team may try to utilize the existing data about the employees from the present database. The analysis should be done in the way, that it may not be too time consuming or with very less informative. The team should be able to come up with the complete cost-benefit analysis and as the plan for the project will be an output of analysis, it should be realistic. To achieve this the analyst should consult the designers, developers and testers to come up with a realistic plan.

Input: Interviews with the clients, Mails and supporting docs by the client, Discussions Notes, Online chat, recorded telephone conversations,Model sites/applications etc.,
Output: 1. Work plan, 2. Cost involved, 3. Team requirements, 4. Hardware-software requirements, 5. Supporting documents and 6. the approval

2. Specification Building:
Preliminary specifications are drawn up by covering up each and every element of the requirement. For example if the product is a web site then the modules of the site including general layout, site navigation and dynamic parts of the site should be included in the spec. Larger projects will require further levels of consultation to assess additional business and technical requirements. After reviewing and approving the preliminary document, a written proposal is prepared, outlining the scope of the project including responsibilities, timelines and costs.

Input: Reports from the analysis team
Output: Complete requirement specifications to the individuals and the customer/customer’s representative

3. Design and development:
After building the specification, work on the web site is scheduled upon receipt of the signed proposal, a deposit, and any written content materials and graphics you wish to include. Here normally the layouts and navigation will be designed as a prototype.

Some customers may be interested only in a full functional prototype. In this case we may need to show them the interactivity of the application or site. But in most of the cases customer may be interested in viewing two or three design with all images and navigation.

There can be a lot of suggestions and changes from the customer side, and all the changes should be freezed before moving into the next phase. The revisions could be redisplayed via the web for the customer to view.

As needed, customer comments, feedback and approvals can be communicated by e-mail, fax and telephone.
Throughout the design phase the team should develop test plans and procedures for quality assurance. It is necessary to obtain client approval on design and project plans.
In parallel the Database team will sit and understand the requirements and develop the database with all the data structures and sample data will also be prepared.

Input: Requirement specification
Output: Site design with templates, Images and prototype

4. Content writing:
This phase is necessary mainly for the web sites. There are professional content developers who can write industry specific and relevant content for the site. Content writers to add their text can utilize the design templates. The grammatical and spelling check should be over in this phase.

Input: Designed template
Output: Site with formatted content

5. Coding:
Now its programmers turn to add his code without disturbing the design. Unlike traditional design the developer must know the interface and the code should not disturb the look and feel of the site or application. So the developer should understand the design and navigation. If the site is dynamic then the code should utilize the template. The developer may need to interact with the designer, in order to understand the design. The designer may need to develop some graphic buttons when ever the developer is in need, especially while using some form buttons. If a team of developers is working they should use a CVS to control their sources. Coding team should generate necessary testing plans as well as technical documentation. For example Java users can use JavaDoc to develop their documents to understand their code flow. The end-user documentation can also be prepared by the coding team, which can be used by a technical writer who can understand them, writes helps and manuals later.

Input: The site with forms and the requirement specification
Output: Database driven functions with the site, Coding documents

6. Testing:

Unlike software, web based applications need intensive testing, as the applications will always function as a multi-user system with bandwidth limitations. Some of the testing which should be done are, Integration testing, Stress testing, Scalablity testing, load testing, resolution testing and cross-browser compatibility testing. Both automated testing and manual testing should be done without fail. For example its needed to test fast loading graphics and to calculate their loading time, as they are very important for any web site. There are certain testing tools as well as some online testing tools which can help the testers to test their applications. For example ASP developers can use Microsoft’s Web Application Test Tool to test the ASP applications, which is a free tool available from the Microsoft site to download.

After doing all the testing a live testing is necessary for web sites and web based applications. After uploading the site there should be a complete testing(E.g.. Links test)
Input: The site, Requirement specifications, supporting documents, technical specifications and technical documents
Output: Completed application/site, testing reports, error logs, frequent interaction with the developers and designers

7. Promotion:
This phase is applicable only for web sites. Promotion needs preparation of meta tags, constant analysis and submitting the URL to the search engines and directories. There is a details article in this site on site promotion, click here to read it. The site promotion is normally an ongoing process as the strategies of search engine may change quite often. Submitting a site URLs once in 2 months can be an ideal submission policy. If the customer is willing, then paid click and paid submissions can also be done with additional cost.

Input: Site with content, Client mails mentioning the competitors
Output: Site submission with necessary meta tag preparation

8. Maintenance and Updating:
Web sites will need quite frequent updations to keep them very fresh. In that case we need to do analysis again, and all the other life cycle steps will repeat. Bug fixes can be done during the time of maintenance. Once your web site is operational, ongoing promotion, technical maintenance, content management & updating, site visit activity reports, staff training and mentoring is needed on a regular basis depend on the complexity of your web site and the needs within your organization.

Input: Site/Application, content/functions to be updated, re-Analysis reports
Output: Updated application, supporting documents to other life cycle steps and teams.

The above-mentioned steps alone are not strict to web application or web site development. Some steps may not applicable for certain tasks. Its depend on the cost and time involved and the necessity. Sometimes if it is a intranet site, then there will be no site promotion. But even if you are a small development firm, if you adopt certain planning along with this web engineering steps in mind, it will definitely reflects in the Quality of the outcome.

courtesy @macronimous.com