Framework Design pattern
Framework
1. A Framework is a reusable, semi-complete application.
2. A Framework is a skeleton you have to put skin on it to make it live.
3. A Frameworks might sometimes be designed on the guidelines of one or more design patterns.e.g. Struts is a frame work based on MVC design.
4. A FrameWork in general specifies collection Of classes and Interfaces that are designed to work together to handle a particular type of Problem.
5. A Framework is a skeleton of code used for developing an application with ease.
It could have used several design patterns to implement the skeleton upon which we generally build applications.
6. A Framework is a collection of API's used to develop a whole application.
7. It's a collection of intelligent objects.
8. Frameworks are more specialized than design patterns — Design patterns are more generalized…
For instance we use MVC in swing development or in J2ee environment.
9. Framework is Design Reuse.
Using framework we reuse the design.
Difference between API and Framework.
API are used for code reusability. Design patterns are used to build different parts of the frameworks.
* Links
http://en.wikipedia.org/wiki/Framework
http://st-www.cs.uiuc.edu/users/johnson/frameworks.html
http://www.acm.org/crossroads/xrds7-4/frameworks.html
Design pattern
1. Design pattern is an abstract idea - Way of doing things, a blueprint.
2. A Design pattern is not an application but is a solution to a commonly occuring design problem.
* Links
http://www.oreilly.com/catalog/hfdesignpat/index.html?CMP=ILL-4GV796923290
http://www.onjava.com/pub/a/onjava/2005/04/06/designpatterns.html
http://en.wikipedia.org/wiki/Design_pattern_(computer_science)
http://www.mindspring.com/~mgrand/pattern_synopses.htm#Interface
http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/patterns/
http://www.patterndepot.com/put/8/JavaPatterns.htm - James W. Cooper
http://www.tml.tkk.fi/~pnr/GoF-models/html/ - GOF
-> Good example to understand the concept.
A framework can be seen as a motor Engine to which we have to just supply fuel and it takes care of generating energy for driving the vehicle…Here the point to be noted is how energy is generated ,what machine parts(Objects)collaborate to achieve the goal is the business of the engine(Framework)
Wednesday, July 26, 2006
Tuesday, July 25, 2006
Tech World :: Effective Indexes
Effective Indexes for Data Warehouses
Roger Deng
Note: This article was originally printed in DB2 Magazine
Creating the right indexes to boost performance is an art. These guidelines will help you master the process.
Indexes are important objects in a relational database. With effective indexes, complex queries run much faster than they would with less optimal indexes. But query performance depends less on how many indexes exist on the tables than on what kind of indexes exist. Figuring out how to create the most effective indexes is a big challenge.
DB2 Universal Database (UDB) includes an Index Advisor, which makes the process easier. In my work with DB2 UDB version 7.2 for Linux, Unix, and Windows, I use it a lot. Sometimes, however, you may want to test whether the Index Advisor's recommendations are the most effective. To test these recommendations, my team and I create an index using a set of guidelines that I'll share with you in this article. Then we run (and time) test queries. If the Index Advisor's recommendation results in better performance, we use it. If not, we use the index we created.
If you need to create indexes on your own (whether to test the Index Advisor's recommendations or for another reason), here are some suggestions for effective index design and examples of indexes you should avoid.
WHAT DO YOU NEED?
Two types of applications use the database: online transaction processing (OLTP) and decision support (including online analytic processing). OLTP queries are usually simple and involve many data change operations (such as INSERT , UPDATE , and DELETE ). The indexes in this environment are usually easy to design. In general, you should minimize the number of OLTP indexes so that transactions can execute very quickly (usually in less than a second). Too many indexes causes performance to suffer.
In a data warehouse or decision support environment, however, most queries are complex. This complexity necessitates the presence of many indexes, which are built during bulk loading. Because queries in a data warehouse environment are complex and dynamic, creating effective indexes can be tricky.
In a data warehouse environment, you probably use a tool to capture user queries and then analyze them with DB2 Explain. That analysis gives you some idea of which indexes are needed. Index Advisor can also help identify the indexes. But using the tool is only the first step. You should look at the whole picture of database load, design, and usage and review all the indexes on your tables to make sure they're effective.
In the data warehouse environment, queries are unpredictable. You can't expect that they'll all run within seconds. Indexes make SELECT s faster, but they also make UPDATE s slower. So, the first rule of thumb on whether to add indexes is to ask yourself a simple question: Are the indexes necessary to ensure that queries will run (and won't run too long)? If queries are completing within a reasonable time, don't create indexes to help them run faster.
GOOD INDEX CANDIDATES
Usually, you'll want to create indexes on the fields in a query's predicate (the WHERE clause). However, not all fields should be indexed: Whether indexing makes sense depends on the field's cardinality. For example, creating an index on the GENDER column isn't a wise choice, because there are only two distinct values for this column. You should create indexes, on the other hand, for high cardinality columns. Indexes on those columns will help DB2's cost-based optimizer. In general, high cardinality columns are good candidates for indexing.
If you must build an index on the column GENDER (for example, if there are many queries doing GROUP BY GENDER and other dimensions), a compound index, which includes more than one field, could work. Instead of only indexing GENDER , for example, add CUSTOMER NUMBER to the index. Adding the high cardinality field will balance the index and avoid the high maintenance that a normal index on a low cardinality field would incur. (Most indexes are stored in B-tree data structures; low cardinality causes the index page to split.) The other choice is to use a bitmap index, which I'll discuss later in this article.
Composite indexes (sometimes called multicolumn indexes) are generally recommended if queries often contain the same columns joined with AND or if you have keys with skewed domain counts or low cardinality. You can safely use up to five columns in a compound index; anything more than that will result in expensive maintenance. The left-most column in a compound index should be the one that occurs most often in the queries. The order of the columns in the WHERE clause once had to match the order in the compound index; however, modern optimizers make that rule obsolete.
There is a misconception that DB2 has to use all the indexes in order to get good performance. But that's not always true. Sometimes, the cost-based optimizer will prefer to scan a table instead of using the indexes. For example, if column A is greater than zero 90 percent of the time, the optimizer will choose to scan the table for the following query:
SELECT * FROM TABLE1 WHERE A > 0;
Let's look at another example. Say there are two indexes on a table, FIRST_NM and LAST_NM, and the following query occurs:
SELECT * FROM TABLE1
WHERE FIRST_NM='ROGER' AND
LAST_NM='DENG';
The DBMS may use the index on LAST_NM and scan the DBMS to match the FIRST_NM with value ROGER instead of joining the two indexes in order to avoid a third read of a data page. Sometimes, DBAs create more indexes than they actually need because they don't know that the optimizer will take such an approach. If you know that the user will most often specify LAST_NM (or LAST_NM and FIRST_NM together), the best approach would be to build a composite index on LAST_NM and FIRST_NM instead of two separate indexes.
Another form of compound index, called a covering index, includes some SELECT fields. Covering indexes save one disk read, but only when all the SELECT columns are in the indexes. If the table's row size is big, using a covering index will dramatically increase query performance because the index will act like a small table. The query will just need to read the index to get the result. Take this example:
SELECT LAST_NM, FIRST_NM, GENDER
FROM TABLE1
WHERE LAST_NM LIKE 'M%';
An index that contains all three columns in this SELECT (LAST_NM, FIRST_NM, and GENDER) on a table that has more than 500 columns can really help performance. In general, if the number of rows in the table is large, try to use a covering index to avoid reading the data page. There are limitations, though. The DBMS will never use covering indexes when there are joins or groupings. Covering indexes are most appropriate for use in read-only data warehouse environments. In read/write OLTP environments, the maintenance would be too high.
DUPLICATE INDEXES
Before adding a new index to a table, check to see if a similar index already exists. Say you have an index on column 1 and you want to add an index on column 1 plus column 2. You should replace the existing index on column 1 instead of adding a new one. Adding a new index on column 1 and column 2 will cause a redundant index. Redundant indexes, of course, take extra space and slow data updates. Worse, they confuse the optimizer with several equivalent query paths. So, drop any redundant indexes.
Consolidate indexes on a table, if you can, to eliminate some overlap. I once saw a DBA create the following compound indexes in DB2 v.7.2:
Index 1 on (C1, C2, C3, C4)
Index 2 on (C1, C2, C3, C5)
Index 3 on (C1, C2, C5)
Index 4 on (C1, C2, C6, C5).
C1, C2 is the primary key on the table. The DBA thought these indexes would make user queries run faster because the columns are all in the indexes. He was trying to use covering indexes; but there's no need to create four indexes in DB2 v.7.2. One index on (C1, C2) that includes (C3, C4, C5, C6) should be enough.
CLUSTERED INDEXES
Clustering an index means storing data rows according to the index order. Searching on a clustered index is much faster. You can have only one clustered index per table; usually, the clustering index is the primary key. You don't need to explicitly create indexes on primary key columns because the system creates them implicitly. To qualify as a primary key, the value of the columns should not be nullable and should be unique on the row. In order to make the primary key the clustering index, use CREATE TABLE. If you try to add it later using an ALTER TABLE statement, the system might not create it as a clustered index.
To qualify for the clustered index, a column should be:
Not too volatile
Short (preferably an integer)
Unique
The column on which a user will most often do a range search
In the order in which the user wants to get results.
BITMAP INDEXES
Originally, DBMSs stored indexes in a B-tree. Modern DBMSs now also use a bitmap index. Bitmap indexes save index disk space and are good for getting statistics out of a large number of rows with static data. Because data warehouses usually contain a lot of data and require many indexes, bitmap indexes are frequently used in a data warehouse environment. The B-tree index is effective only when the selectivity is higher than 0.1. Selectivity is is defined as (number of distinct values) / (total number of values).
If the selectivity is lower than 0.1, a bitmap index will be a good choice. Bitmap indexes are particularly useful for queries that contain [NOT] EXISTS, UNIQUE, or GROUP BY. For those queries, you should use bitmap indexes on low cardinality columns. On the contrary, a high cardinality field, such as social security number, would not be a good candidate for bitmap indexes.
THE ART OF INDEXES
For a DBA, creating indexes is like creating a work of art. Good design (that balances system maintenance load and query performance) is essential. The best indexes serve several queries instead of just one. When that occurs, the return on your index investment grows.
Utilities such as Index Advisor are handy, but remember that you're responsible for the final decision. DBAs must understand the logic behind the utility's choices or suggestions. If the logic doesn't seem to make sense, test it. Tools can't handle every situation, especially those that require consolidating indexes for an overall view. Familiarity with the essentials of indexing helps DBAs make smart decisions and create the most effective indexes for the database.
For a clustering index, new rows are inserted physically close to existing rows with similar key values. This yields a performance benefit during queries because it results in a more linear access pattern to data pages and more effective pre-fetching.
If you want a primary key index to be a clustering index, a primary key should not be specified at CREATE TABLE. Once a primary key is created, the associated index cannot be modified. Instead, perform a CREATE TABLE without a primary key clause. Then issue a CREATE INDEX statement, specifying clustering attributes. Finally, use the ALTER TABLE statement to add a primary key that corresponds to the index just created. This index will be used as the primary key index.
Generally, clustering is more effectively maintained if the clustering index is unique.
Roger Deng
Note: This article was originally printed in DB2 Magazine
Creating the right indexes to boost performance is an art. These guidelines will help you master the process.
Indexes are important objects in a relational database. With effective indexes, complex queries run much faster than they would with less optimal indexes. But query performance depends less on how many indexes exist on the tables than on what kind of indexes exist. Figuring out how to create the most effective indexes is a big challenge.
DB2 Universal Database (UDB) includes an Index Advisor, which makes the process easier. In my work with DB2 UDB version 7.2 for Linux, Unix, and Windows, I use it a lot. Sometimes, however, you may want to test whether the Index Advisor's recommendations are the most effective. To test these recommendations, my team and I create an index using a set of guidelines that I'll share with you in this article. Then we run (and time) test queries. If the Index Advisor's recommendation results in better performance, we use it. If not, we use the index we created.
If you need to create indexes on your own (whether to test the Index Advisor's recommendations or for another reason), here are some suggestions for effective index design and examples of indexes you should avoid.
WHAT DO YOU NEED?
Two types of applications use the database: online transaction processing (OLTP) and decision support (including online analytic processing). OLTP queries are usually simple and involve many data change operations (such as INSERT , UPDATE , and DELETE ). The indexes in this environment are usually easy to design. In general, you should minimize the number of OLTP indexes so that transactions can execute very quickly (usually in less than a second). Too many indexes causes performance to suffer.
In a data warehouse or decision support environment, however, most queries are complex. This complexity necessitates the presence of many indexes, which are built during bulk loading. Because queries in a data warehouse environment are complex and dynamic, creating effective indexes can be tricky.
In a data warehouse environment, you probably use a tool to capture user queries and then analyze them with DB2 Explain. That analysis gives you some idea of which indexes are needed. Index Advisor can also help identify the indexes. But using the tool is only the first step. You should look at the whole picture of database load, design, and usage and review all the indexes on your tables to make sure they're effective.
In the data warehouse environment, queries are unpredictable. You can't expect that they'll all run within seconds. Indexes make SELECT s faster, but they also make UPDATE s slower. So, the first rule of thumb on whether to add indexes is to ask yourself a simple question: Are the indexes necessary to ensure that queries will run (and won't run too long)? If queries are completing within a reasonable time, don't create indexes to help them run faster.
GOOD INDEX CANDIDATES
Usually, you'll want to create indexes on the fields in a query's predicate (the WHERE clause). However, not all fields should be indexed: Whether indexing makes sense depends on the field's cardinality. For example, creating an index on the GENDER column isn't a wise choice, because there are only two distinct values for this column. You should create indexes, on the other hand, for high cardinality columns. Indexes on those columns will help DB2's cost-based optimizer. In general, high cardinality columns are good candidates for indexing.
If you must build an index on the column GENDER (for example, if there are many queries doing GROUP BY GENDER and other dimensions), a compound index, which includes more than one field, could work. Instead of only indexing GENDER , for example, add CUSTOMER NUMBER to the index. Adding the high cardinality field will balance the index and avoid the high maintenance that a normal index on a low cardinality field would incur. (Most indexes are stored in B-tree data structures; low cardinality causes the index page to split.) The other choice is to use a bitmap index, which I'll discuss later in this article.
Composite indexes (sometimes called multicolumn indexes) are generally recommended if queries often contain the same columns joined with AND or if you have keys with skewed domain counts or low cardinality. You can safely use up to five columns in a compound index; anything more than that will result in expensive maintenance. The left-most column in a compound index should be the one that occurs most often in the queries. The order of the columns in the WHERE clause once had to match the order in the compound index; however, modern optimizers make that rule obsolete.
There is a misconception that DB2 has to use all the indexes in order to get good performance. But that's not always true. Sometimes, the cost-based optimizer will prefer to scan a table instead of using the indexes. For example, if column A is greater than zero 90 percent of the time, the optimizer will choose to scan the table for the following query:
SELECT * FROM TABLE1 WHERE A > 0;
Let's look at another example. Say there are two indexes on a table, FIRST_NM and LAST_NM, and the following query occurs:
SELECT * FROM TABLE1
WHERE FIRST_NM='ROGER' AND
LAST_NM='DENG';
The DBMS may use the index on LAST_NM and scan the DBMS to match the FIRST_NM with value ROGER instead of joining the two indexes in order to avoid a third read of a data page. Sometimes, DBAs create more indexes than they actually need because they don't know that the optimizer will take such an approach. If you know that the user will most often specify LAST_NM (or LAST_NM and FIRST_NM together), the best approach would be to build a composite index on LAST_NM and FIRST_NM instead of two separate indexes.
Another form of compound index, called a covering index, includes some SELECT fields. Covering indexes save one disk read, but only when all the SELECT columns are in the indexes. If the table's row size is big, using a covering index will dramatically increase query performance because the index will act like a small table. The query will just need to read the index to get the result. Take this example:
SELECT LAST_NM, FIRST_NM, GENDER
FROM TABLE1
WHERE LAST_NM LIKE 'M%';
An index that contains all three columns in this SELECT (LAST_NM, FIRST_NM, and GENDER) on a table that has more than 500 columns can really help performance. In general, if the number of rows in the table is large, try to use a covering index to avoid reading the data page. There are limitations, though. The DBMS will never use covering indexes when there are joins or groupings. Covering indexes are most appropriate for use in read-only data warehouse environments. In read/write OLTP environments, the maintenance would be too high.
DUPLICATE INDEXES
Before adding a new index to a table, check to see if a similar index already exists. Say you have an index on column 1 and you want to add an index on column 1 plus column 2. You should replace the existing index on column 1 instead of adding a new one. Adding a new index on column 1 and column 2 will cause a redundant index. Redundant indexes, of course, take extra space and slow data updates. Worse, they confuse the optimizer with several equivalent query paths. So, drop any redundant indexes.
Consolidate indexes on a table, if you can, to eliminate some overlap. I once saw a DBA create the following compound indexes in DB2 v.7.2:
Index 1 on (C1, C2, C3, C4)
Index 2 on (C1, C2, C3, C5)
Index 3 on (C1, C2, C5)
Index 4 on (C1, C2, C6, C5).
C1, C2 is the primary key on the table. The DBA thought these indexes would make user queries run faster because the columns are all in the indexes. He was trying to use covering indexes; but there's no need to create four indexes in DB2 v.7.2. One index on (C1, C2) that includes (C3, C4, C5, C6) should be enough.
CLUSTERED INDEXES
Clustering an index means storing data rows according to the index order. Searching on a clustered index is much faster. You can have only one clustered index per table; usually, the clustering index is the primary key. You don't need to explicitly create indexes on primary key columns because the system creates them implicitly. To qualify as a primary key, the value of the columns should not be nullable and should be unique on the row. In order to make the primary key the clustering index, use CREATE TABLE. If you try to add it later using an ALTER TABLE statement, the system might not create it as a clustered index.
To qualify for the clustered index, a column should be:
Not too volatile
Short (preferably an integer)
Unique
The column on which a user will most often do a range search
In the order in which the user wants to get results.
BITMAP INDEXES
Originally, DBMSs stored indexes in a B-tree. Modern DBMSs now also use a bitmap index. Bitmap indexes save index disk space and are good for getting statistics out of a large number of rows with static data. Because data warehouses usually contain a lot of data and require many indexes, bitmap indexes are frequently used in a data warehouse environment. The B-tree index is effective only when the selectivity is higher than 0.1. Selectivity is is defined as (number of distinct values) / (total number of values).
If the selectivity is lower than 0.1, a bitmap index will be a good choice. Bitmap indexes are particularly useful for queries that contain [NOT] EXISTS, UNIQUE, or GROUP BY. For those queries, you should use bitmap indexes on low cardinality columns. On the contrary, a high cardinality field, such as social security number, would not be a good candidate for bitmap indexes.
THE ART OF INDEXES
For a DBA, creating indexes is like creating a work of art. Good design (that balances system maintenance load and query performance) is essential. The best indexes serve several queries instead of just one. When that occurs, the return on your index investment grows.
Utilities such as Index Advisor are handy, but remember that you're responsible for the final decision. DBAs must understand the logic behind the utility's choices or suggestions. If the logic doesn't seem to make sense, test it. Tools can't handle every situation, especially those that require consolidating indexes for an overall view. Familiarity with the essentials of indexing helps DBAs make smart decisions and create the most effective indexes for the database.
For a clustering index, new rows are inserted physically close to existing rows with similar key values. This yields a performance benefit during queries because it results in a more linear access pattern to data pages and more effective pre-fetching.
If you want a primary key index to be a clustering index, a primary key should not be specified at CREATE TABLE. Once a primary key is created, the associated index cannot be modified. Instead, perform a CREATE TABLE without a primary key clause. Then issue a CREATE INDEX statement, specifying clustering attributes. Finally, use the ALTER TABLE statement to add a primary key that corresponds to the index just created. This index will be used as the primary key index.
Generally, clustering is more effectively maintained if the clustering index is unique.
Monday, July 24, 2006
How to make MONEY !!!!!!!
Once upon a time in a village a man appeared who announced to the villagersthat he would buy monkeys for Rs. 10.
The villagers seeing that there weremany monkeys went out in the forest and started catching them.
The man bought thousands at 10 and as supply started to diminish and villagers started to stop their effort he announced that now he would buy at 20 rupees.
This renewed the efforts of the villagers and they started catching monkeys again. Soon the supply diminished even further and people started going back to their farms.
The offer rate increased to 25 and the supply ofmonkeys became so that it was an effort to even see a monkey let alonecatch it.
The man now announced that he would buy monkeys at 50! However, since hehad to go to the city on some
business his assistant would now buy onbehalfof the man.
In the absence of the man, the assistant told the villagers, "Look at allthese monkeys in the big cage that the man has collected.
I will sell themto you at 35 and when the man comes back you can sell it to himfor 50."The villagers queued up with all their saving to buy the monkeys.Phir na woh aadmi mila na us ka assistant........... Sirf bandar heebandar.....rah gaye..
The villagers seeing that there weremany monkeys went out in the forest and started catching them.
The man bought thousands at 10 and as supply started to diminish and villagers started to stop their effort he announced that now he would buy at 20 rupees.
This renewed the efforts of the villagers and they started catching monkeys again. Soon the supply diminished even further and people started going back to their farms.
The offer rate increased to 25 and the supply ofmonkeys became so that it was an effort to even see a monkey let alonecatch it.
The man now announced that he would buy monkeys at 50! However, since hehad to go to the city on some
business his assistant would now buy onbehalfof the man.
In the absence of the man, the assistant told the villagers, "Look at allthese monkeys in the big cage that the man has collected.
I will sell themto you at 35 and when the man comes back you can sell it to himfor 50."The villagers queued up with all their saving to buy the monkeys.Phir na woh aadmi mila na us ka assistant........... Sirf bandar heebandar.....rah gaye..
Thursday, July 13, 2006
Light a candle. Thanks deepika for forward.
CNN IBN says it'll donate a rupee for every person who goes to the site and "lights a candle"
http://clients.ibnlive.com/features/mumatt/index.php
Mumbai came to a shocking standstill on July 11 when serial blasts ripped through its local trains, killing and wounding hundreds. But the city of dreams stood fearless and fighting fit.
Salute Mumbai's never-say-die spirit and Light a Candle for those who succumbed to the blasts or got injured. For every candle you light, CNN-IBN and Channel 7 will donate Re 1 for the relief of the victims.
Tuesday, July 11, 2006
Blasts on trains in Mumbai !! Emergency contact numbers !! Mumbai Helpline Number: 022-22005388 !
http://www.mumbaipolice.org/imp_telnfax.htm
http://worldwidehelp.blogspot.com/
Below is the news form Times of India.
MUMBAI: Mumbai relived a nightmare when six explosions shook the city in quick succession on Tuesday evening. Early reports said eight people had died and many were injured.
The target was Mumbai's life-line -- its local train services -- timed to catch the evening rush. The first blast occurred in a first-class compartment of a local train near Khar station at 6.25 p.m.
Reports said the blast blew the train compartment to pieces and several passengers were seen jumping out. By 7 p.m. there were reports of five more blasts all targeting local trains.
The other blasts occurred at Matunga, Santa Cruz, Jogeshwari, Borivili and Bhayendar railway stations. All explosions were reported to have taken place in first class compartments of trains at a time when a large chunk of the commercial capital is returning home from office.
Televison reports said eight people had died while scores were seriously injured.
Mumbai was stunned before the panic set in. There was chaos and crush as people rushed to safety. Many were seen lying on the rail tracks.
Eyewitnesses said rain was hampering rescue work as the injured were carried to hospital.
Around 12 to 15 people injured at Santa Cruz station were taken to the nearby V N Desai hospital and another 20 were admitted to the KEM Hospital in Parel.
As people tried to reach their own, local phone lines were jammed and communication within the city and from outside became impossible. All trains on the Western line route have been suspended.
Police cordoned off all railway stations on the line and strict checking was carried out at the Central and Harbour sections of local trains services.
The blasts brought live fading memories of the BEST blasts of 2003. Reports said the city once again sprang to the rescue of its people, while official help was tardy.
Meanwhile, Delhi was put on high alert after the serial blasts in Srinagar and Mumbai through the day.
The Centre went into a huddle, with the Union Home Minister Shivraj Patil rushing to meet Prime Minister Dr Manmohan Singh.
http://worldwidehelp.blogspot.com/
Below is the news form Times of India.
MUMBAI: Mumbai relived a nightmare when six explosions shook the city in quick succession on Tuesday evening. Early reports said eight people had died and many were injured.
The target was Mumbai's life-line -- its local train services -- timed to catch the evening rush. The first blast occurred in a first-class compartment of a local train near Khar station at 6.25 p.m.
Reports said the blast blew the train compartment to pieces and several passengers were seen jumping out. By 7 p.m. there were reports of five more blasts all targeting local trains.
The other blasts occurred at Matunga, Santa Cruz, Jogeshwari, Borivili and Bhayendar railway stations. All explosions were reported to have taken place in first class compartments of trains at a time when a large chunk of the commercial capital is returning home from office.
Televison reports said eight people had died while scores were seriously injured.
Mumbai was stunned before the panic set in. There was chaos and crush as people rushed to safety. Many were seen lying on the rail tracks.
Eyewitnesses said rain was hampering rescue work as the injured were carried to hospital.
Around 12 to 15 people injured at Santa Cruz station were taken to the nearby V N Desai hospital and another 20 were admitted to the KEM Hospital in Parel.
As people tried to reach their own, local phone lines were jammed and communication within the city and from outside became impossible. All trains on the Western line route have been suspended.
Police cordoned off all railway stations on the line and strict checking was carried out at the Central and Harbour sections of local trains services.
The blasts brought live fading memories of the BEST blasts of 2003. Reports said the city once again sprang to the rescue of its people, while official help was tardy.
Meanwhile, Delhi was put on high alert after the serial blasts in Srinagar and Mumbai through the day.
The Centre went into a huddle, with the Union Home Minister Shivraj Patil rushing to meet Prime Minister Dr Manmohan Singh.
Monday, July 10, 2006
What you learned from Zidane & head butt ?
Zidane won the Golden Ball award !!!!
Zinedine Zidane
France captain Zinedine Zidane won the Golden Ball award for the World Cup best player,
despite being dismissed for head-butting Marco Materazzi in the final. ...
The former international player of the year and 1998 World Cup winner announced last month that he was retiring from football after the tournament.
Going out of the rule in sports ...only happens when something very serious happens ..
Still there is lot to study about the Zidane's head butt
1. Body language of both the players through out the match .. & body language after red card ..
2. Reaction of Zinedine
3. news & statemnets which are going to come in few days from both the players...
Even though he crossed the border of rules , even he made a very big mistake in the last match of his career ..
the second day ..i was reading one news article "France still loves Zidane !!!!
Bottom line
-----------------------
Do such a good work in life/career tat even if you do a mistake at the end, your good work should hide it" " Start to learn how to close ears without using hands"
Click here to play Head butt game
Which type of mindset is yours Entrepreneurial mindset OR Employee mindset ?
I will be posting abt my mindset in coming days ..till the time let me know abt type of your mindset
Sunday, July 09, 2006
Day's update
NEWS
BBC, India tests new ballistic missile:
Analysts say the Agni-III dramatically increases the range of targets which India could hit."This means that India has entered an altogether different league of nations, a new club," Rahul Bedi of Jane's Defence Weekly told Reuters."We can now reach large parts of northern China, making our deterrence capacity stronger. Also, when a country is able to develop a missile which can travel 3,500km, it is not difficult to make something that can go 5,000km. "Very few nations have that capacity."
Intresting ::
http://disgustedinstlouis.blogspot.com/2006/07/why-no-outrage-over-this-nuclear-icbm.html
Saturday, July 08, 2006
4th Jully in Manhattan
Macy's arranged a fireworks at 4 diffrent places on 4th july . The best thing i observed is ..it started on time tat is exactly 9.23 ...count down started .. 10 .. 9.. 8... ... ..1 .. BOOMMMM.... It was amazing !!!! it lasted for more than half an hr ... It was really fun .. ..
Hrishi,Ashish, Shiraz & Me enjoyed a lot !!!
These are the snaps sent by Sidd to whom we met at the event !!! Thanks Sidd !!
Subscribe to:
Posts (Atom)