Skip to main content

Posts

Cities in India – Part III

In this Series: Part I , Part II Today whether you visit Mumbai or Dehradun the same scene awaits you – traffic bursting from the seams, lack of amenities, overcrowded public transport (whether it is the Mumbai local, the tempo in Dehradun or shared-rickshaw in Vadodara). Why has this happened? Clearly, we have never looked at our cities in a scientific and organized fashion, our cities emerged just like other countries, as centres of trade. However, cities which should have evolved gradually underwent destruction and a military set-up was imposed on them. Today are imposing a commercial infrastructure over the same military set-up creating a further confused landscape on one hand and choking the amenities and resources on the other. What can we do to solve these problems? I have few thoughts in mind: Macro level We should de-congest existing cities by shifting out industries from them to newer, better planned cities (for example the way industries were moved from Mumbai to

Cities in India – Part II

While it is well known that the British came to India under the pretext of trade, beyond a brief period of 15 years (1757-1773), the British government assumed full control over the system. To maintain their rule, British needed to control the masses, zamindars and the local kings – and for this they needed the army to be strong. So on one hand they developed infrastructure like the railways (for speedy movement of troops), on the other hand they imposed a military set-up on the major cities in India. And thus emerged cities like Dehradun, Jabalpur, Bangalore, Poona etc - as military cantonments rather than centers of trade. These cities were also built as typical British towns – a town center, a clock tower and a Sadar bazaar being some commonalities you would find in all these towns. These towns grew further through the early years of independence thanks to the militarily charged atmosphere (due to the Cold War, Indo-Pak, Indo-China wars etc) thus maintaining the status of military a

Thoughts on a sojourn : Cities in India – Part I

I have been travelling in the past week – from Mumbai, to Baroda to Delhi, to Dehradoon and Mussourie and back. It has been a great experience, but even more it has been a thought provoking travel through the metros, small and smaller cities and via towns as well. It is wonderful to explore India because there is so much hidden beneath the quotidian activities in Indian cities - most Indian cities, however small or big have centuries old history behind them. They have grown, destroyed and rebuilt so many times and yet some element of past is still visible in them even today. While travelling to and through these cities some thoughts emerged in my mind about the way these cities have come into the current state – I am detailing them below. Long before the British or the Mughals marched into India, the region had developed mature political and administrative systems. More so, irrespective of whether there was one national ruler (ex. Ashoka or Akbar) or the rule was shared by regional sat

IT under recession??

Yesterday I got an email from acquaitance with a request to help someone related to him with a job. His email said that the said relation of his "working in [an] IT firm was laid off due to recession". I am suprised that IT'Cos have started laying off people citing reasons of "recession" because the recession is still to come. I suspect this is the case of the company trying to lay-off people from unprofitable projects (which is a routine process in IT'Cos) under the pretext of recession. However, there is no denying that effects have started showing already on the IT industry of a eminent slowdown. This overall points to a direction that companies which have been traditionally relying on a pure "Services model" (read: Maintenance services) will increasingly find it tough to survive. The age has arrived for product based companies to take a lead. SaaS companies will be also able to make it big now owing to the suitability of their Business Model f

Requirements Gathering: Boon or Bane?

Some time back I had written on how so many banks use IT Applications as electronic record keeping books. Today, I read an article by Paul Glen* titled Project Managers: Stop "gathering" IT requirements . It seems to be pointing to the same problem but some another angle. What Paul says is probably the root cause of - what I had mentioned - why IT fails to deliver competitive advantage to users; I quote: Requirements don't exist out in the ether just waiting to be discovered. They aren't out there whole and finished. Clients and users aren't playing an expensive game of hide-and-seek with us. Usually, the clients' pockets are empty. Most of the time, they don't exactly know what they require. And even if they do, it's in the form of incomplete and inconsistent ideas that can be only partially articulated. Projects rarely start out with clear objectives or requirements; they begin in confusion and ambiguity. While Paul blames the IT organization for th

Bus driver & school kids

Good story By: Gautam Soman It was morning time, around 9-9:30 AM. Volvo was rushing towards Nagpur. I sat just behind the driver, and out through the windshield, saw a group of kids on their way to school. They were perspiring from the heat. Suddenly the bus stopped. Driver motioned for the kids to get in. About half a dozen chirpy birds crowded the cabin. On the way, driver asked them a few questions. The kids were a talkative lot and informed that they were on their way to give the final exams, they had English paper that day and that it was "layi bhaari paper". It was clear they had found themselves in an air-conditioned bus like Volvo for the first time and were greatly enamoured. I had an unopened pack of biscuits, which I gave them. They distributed it among themselves and ate it heartily. A couple of kilometers later, ... we reached their destination, the school. As they got down, the driver told them, "Study well. If you don't, you will become a dr

Here Comes Trouble: A Social Directory

Om Malik either does not know about "microformats" especially hCard (which is unlikely) or has willingly chosen to ignore it in his article (see excerpt at the end). The solution to directory problem is not to have a single provider like google or Plaxo collate all information about a person, but to allow any service to syndicate the same standard contact information. The solution is the standard microformat for storing your contact details from email, to phone number/ postal address to social network profile info. Once all existing platforms which store profile info - blogs, email services, eGroups, specialized networks (forums/ batchmates.com etc.) - start using the same format, it will be possible for any service to access hCard info from any other service (provided privacy is taken care of by allowing users the right to share/ not share). Also, this will make it possible for you to store your hCard info at only on of the websites you use (say your personal blog or social

Roadies ....

Last Thursday one of my NITIE batchmates got married in Vadodara. My parents are currently stationed there, but coincidentally, they were off to our home town (Bhopal) on the precise dates when I was going to be there. So I hatched an alternate plan - along with Sabya and Arijit, I decided to spend 2 days driving around Vadodara. We started the first day lazily and started from home by about 11 for Pavagadh - home to a famous Mahakali temple. On our way we took a pitt stop at Sikander Shah ka Makbara (an ASI monument). Unfortunately, the ropeway at Pavagadh was under maintenance, so we could not visit the temple. So, we proceeded to visit Champaner where remains of an old capital city of Gujarat are located; it is today the site of the Champaner-Pavagadh Archaeological Park . The snap below is of the Champaner Citadels - a UNESCO world Heritage monument. By the time we finished off, the sun of Gujarat had extracted all energy out of us, so we headed back to Vadodara. We felt utmost

Data Portability.org
Extending the OSI Model - Part III (concluded)

RSS, Microformats, OpenID, Tagging - all these formats, protocols and practices are extending the underlying philosophies of the OSI Model to provide continuity across multi-vendor environments. In fact, an initiative to formalize this 'extention' is already on at dataportability.org . As they say on their website: The technologies already exist, we simply need a complete reference design to put the pieces together. [Their] mission [is] to put all existing technologies and initiatives in context to create a reference design for end-to-end Data Portability. To promote that design to the developer, vendor and end-user community. Notably, all the major players from Google/Yahoo/MySpace to Microsoft/Verisign are already a part of this initiative. However, this initiative, just like the OSI Model - has more to do with the developer/vendor community and little to do with common users. And this is where DataPortability needs to differ from the OSI Model.

RSS, Microformats, Tagging, OpenID
Extending the OSI Model - Part II

Continuing from my previous post, clearly the web of software services to inter-operate with each other need an extension of the OSI Model to services level. There are many service which are working in this direction viz. RSS: Really Simple Syndication RSS is a format used to publish updates of your website content. Typically RSS is used by news websites or blogs - where content is dynamic and requires users to keep checking the site for updates. RSS updates could be just pointers to changes (or summary of changes) or it could contain the full feed ( i.e. all the new content). An RSS is typically read using a feed reader - a program similar to an email client which keeps checking for updates. While the primary function of an RSS feed is to provide information updates - it also helps in separating the 'presentation' from the underlying 'content' - just as the OSI Model separates presentation from data. With RSS in place, you need not read a blog or news only in the fo