Great quotations from Indian general Sam Manekshaw (1914-2008)

Below are some Great quotations from Sam Manekshaw, (1914-2008), a highly decorated soldier of the Indian Army who rose to the rank of Field Marshal in the Indian Army. In his long military career, he saw action in five wars: World War Two, Indo-Pakstan War of 1947, Sino Indian War of 1962, Indo Pakistan War of 1965 and the Indo Pakistan War of 1971.

“If anyone tells you he is never afraid, he is a liar or he is a Gurkha.” – On the Indian Army’s Gurkha Regiment.

“I’m always ready, sweetie.”- On being asked by Indira Gandhi about the Indian Army’s readiness for the 1971 war.

“Don’t you think I would be a worthy replacement for you, Madam Prime Minister? You have a long nose. So have I. But I don’t poke my nose into other people’s affairs.”- To Indira Gandhi, on rumours of him planning a coup to replace her.

“Gentlemen, I have arrived and there will be no withdrawal without written orders and these orders shall never be issued” – During 1962 War, when he was sent to North East Frontier Agency (NEFA) to command retreating Indian forces against the Chinese force.

“You received three at this age; when I was of your age, I received nine bullets and look- today, I am the Commander in Chief of the Indian Army.” – During the 1971 Indo-Pakistan War when he met an injured soldier in army hospital with three bullet wounds.

During the 1962 War, he sent a box containing bangles & a letter saying, “If your men do not wish to fight, this is the best medal you can wear.” This was sent to the CO of a battalion who did not wish to enter into conflict with the Chinese. However, in the coming weeks the CO & his battalion proved their grit by battling it out with the Chinese & conducted many successful operations. When Manekshaw learned this, he sent a letter back to CO saying “Please send back the box containing bangles, as this is not for you & your men.”

And lastly, my favourite. Manekshaw is reported to have once said “I wonder whether those of our political masters who have been put in charge of the defence of the country can distinguish a mortar from a motor; a gun from a howitzer; a guerrilla from a gorilla, although a great many resemble the latter.”

10 top IT skills for 2013

Data from CyberCoders reveals that candidates who have experience with iOS development, cloud computing programming and front-end development skills are most in demand in today’s tech career landscape.

The top 10 tech skills for 2013, as per CyberCoders are listed below:

1. Mobile development (iOS, Android)
2. Cloud computing (AWS, Azure)
3. Front end development (HTML5, CSS3, Javascript)
4. UX/UI design; 5. Big Data (Hadoop, MongoDB, NoSQL)
6. C#
7. Ruby on rails
8. Java
9. PHP
10. Linux

A common theme among these technology skills is the need for open source, mobile, cloud or big data technologies, like iOS, Azure and Hadoop

Alexander the Great & the Battle of Gaugamela

On October 1st, 331 BC, one of the decisive battles in world history took place. The battle of Gaugamela formed the highlight of Alexander’s campaign. After Darius III lost the battle in his first encounter with Alexander the Great at Issus (333 BC), in order to avert another war, he offered Alexander the surrender of all areas west of the Euphrates, a high ransom for the harem captured by Alexander at Issus and the hand of his daughter in marriage. But Alexander refused. His goal was to conquer the Achaemenid Empire.

One day, scouts reported that Darius had begun to assemble a massive army by the Euphrates. Darius was now ready to lead the decisive battle, but Alexander wanted to wait until Darius had recruited the very last Persian. In this way, Alexander wanted to ensure that a further battle would not be necessary.

Alexander’s army consisted of 40,000 infantry men and 7,000 horsemen. Compared to the Persians, he was at a clear numerical disadvantage. But his army consisted predominantly of hugely experienced veterans, and the short chains of command would be useful in battle. His army consisted of the Hetairoi cavalry, who were armed with spears. The Hypaspists, similarly-armed to the Greek Hoplites, but not as limited in their movement. Alexander also had the Pezhetairoi, who were armed with extremely long spears and the usual lightly-armed troops in his army. Alexander’s father Phillip had assembled a mighty army from a slack original squad, on which he could now rely. His army was joined by many allies and soldiers from Greece and the entire Balkans. Alexander had also learnt from his father to only use the infantry for defensive purposes and to wait for the right moment to then launch a personally-led attack with his heavy Hetairoi cavalry. As with the Battle of Issus, this attack should also help to him to victory.

After Darius’s defeat at Issus, he had almost two years to build up an army. In order to achieve numerical superiority, he recruited every man of fighting age in his empire. But many of these men were poorly or barely educated, which in the end led to a mass panic. The army of the king consisted of many different tribes mixed together. Foot soldiers and horsemen from Mesopotamia, Babylonia and from the coasts of the Persian Gulf. Darius’s army comprised at least 250,000 men, among them 30,000 Greek soldiers, 12,000 heavy Bactrian horsemen. Unlike the majority of the army, the cavalry was made up of many experienced fighters, its core, the kara (general call to arms), was permanently armed. The Indians made 15 war elephants available for the battle. And 200 of the feared scythed chariots were to be used. These were supposed to break up the Macedonian Phalanx during the battle. In addition there was also the royal guard, including soldier units of Greek Hoplites. After Darius had assembled his army, he scouted around for a suitable battlefield. He wanted to make use of his numerical superiority, with the result that Alexander would be forced into the wide plains of the Tigris to do battle. The king ordered one of his officers to watch for the approach of the enemy, but to let him pass by undisturbed. Alexander was to cross the Euphrates with his troops unhindered. He himself headed from Babylon in a northern direction. At Arbela the king pitched a camp, from there he positioned his army in the plains between the Tigris and the Zab. Darius had these plains cleared of all unevenness, so that the scythed chariots could be used to full effect. Alexander’s goal was the centre of Mesopotamia, at Thapsakos he led his troops across the Euphrates and then turned to the north-east. As soon as it was reported that the Persian army had arrived for battle just a few days’ march to the south, in the plains of Gaugamela, Alexander set up camp immediately.


On account of his numerical advantage, the favourable terrain, the scythed chariots, war elephants and fighting power, Darius was very sure of victory, but the Persians feared a night attack by the Macedonians and therefore ordered all men to remain awake, in order to be prepared for an attack. Parmenion planned such an attack, but was restrained by Alexander. He prepared his plan of attack during the night an allowed his men to rest. The plan included some improvements to the formation. As Alexander had to face the size of the Persian frontline with an encirclement of the Macedonian flank, he positioned a second troop division behind the phalanx of sarissa-bearers. These were instructed to double back during the encirclement, so that a square shape would be created. The Persian front consisted mainly of cavalry, and was supported to the right and left by scythed chariots. Between these were some individual infantry. However these were mainly concentrated with the elephants in the middle. As at Issus, Darius stood with his guard behind the centre, with the Babylonian infantry behind him for additional protection. This hierarchy brought the formation of the Persians to a length of 3 – 4 km. Alexander positioned his phalanx of sarissa-bearers in the centre and allowed the Hetairoi cavalry, led by himself, to take up the right flank. Alexander positioned the flexible Hypaspists between the horsemen and the phalanx. His left flank was occupied with the Thessalian and Greek cavalry, under the command of Parmenion. Behind the phalanx he positioned as planned a troop of lightly-armed cavalry and infantry. Alexander’s plan was very audacious. He wanted to lure the heavy Persian cavalry away from the centre by attacking the flanks, in order to then lead a mounted attack on Darius III through a hole in the centre.


The battle began tentatively at first, then Alexander tried to find a favourable attacking point against the scythed chariots through an improvised movement. He extended and thinned out the right flank. The king expected a lateral attack and ordered the horsemen on the left flank to attack, so that a grim mounted battle took place. The hoped-for advantage from the scythed chariots never materialised. First, the lightly-armed soldiers decimated the charioteers with spears, then the phalanx formation opened to allow for the unhindered passage of the chariots, which were then annihilated in the background. But the king’s troops put the Macedonian phalanx under severe pressure and Alexander suffered heavy losses. But due to the advance of the Persian left flank, the Persian formation quickly fell into disarray. Darius was now only covered by his bodyguards. At this moment, Alexander launched the attack on the Persian centre with his cavalry, coming dangerously close to Darius. He fled, although the battle was not yet over for the Persians, the resistance of his guard was of no avail, and he feared being killed on the battlefield. The flight of Darius was interpreted by his men as a sign to retreat, shortly thereafter the entire Persian front collapsed. But the fleeing king could not be captured by Alexander. After his victory, Alexander declared himself with great pride the “King of Asia”, and Darius lost his legitimacy following his flight and was later murdered by Bessus.

Representational State Transfer (REST)

Representational State Transfer (REST) is a style of software architecture for distributed systems such as the World Wide Web. REST has emerged as a predominant Web service design model.

Key goals

Key goals of REST include:

  • Scalability of component interactions
  • Generality of interfaces
  • Independent deployment of components
  • Intermediary components to reduce latency, enforce security and encapsulate legacy systems

REST has been applied to describe the desired web architecture, to help identify existing problems, to compare alternative solutions, and to ensure that protocol extensions would not violate the core constraints that make the Web successful.


The REST architectural style describes the following six constraints applied to the architecture, while leaving the implementation of the individual components free to design:


A uniform interface separates clients from servers. This separation of concerns means that, for example, clients are not concerned with data storage, which remains internal to each server, so that the portability of client code is improved. Servers are not concerned with the user interface or user state, so that servers can be simpler and more scalable. Servers and clients may also be replaced and developed independently, as long as the interface between them is not altered.


The client–server communication is further constrained by no client context being stored on the server between requests. Each request from any client contains all of the information necessary to service the request, and any session state is held in the client.


As on the World Wide Web, clients can cache responses. Responses must therefore, implicitly or explicitly, define themselves as cacheable, or not, to prevent clients reusing stale or inappropriate data in response to further requests. Well-managed caching partially or completely eliminates some client–server interactions, further improving scalability and performance.

Layered system

A client cannot ordinarily tell whether it is connected directly to the end server, or to an intermediary along the way. Intermediary servers may improve system scalability by enabling load-balancing and by providing shared caches. They may also enforce security policies.

Code on demand (optional)

Servers are able temporarily to extend or customize the functionality of a client by the transfer of executable code. Examples of this may include compiled components such as Java applets and client-side scripts such as JavaScript.

Uniform interface

The uniform interface between clients and servers, discussed below, simplifies and decouples the architecture, which enables each part to evolve independently. The four guiding principles of this interface are detailed below.

The only optional constraint of REST architecture is code on demand. If a service violates any other constraint, it cannot strictly be considered RESTful.

Central principle

An important concept in REST is the existence of resources (sources of specific information), each of which is referenced with a global identifier (e.g., a URI in HTTP). In order to manipulate these resources, components of the network (user agents and origin servers) communicate via a standardized interface (e.g., HTTP) and exchange representations of these resources (the actual documents conveying the information). For example, a resource that represents a circle (as a logical object) may accept and return a representation that specifies a center point and radius, formatted in SVG, but may also accept and return a representation that specifies any three distinct points along the curve (since this also uniquely identifies a circle) as a comma-separated list.

Any number of connectors (e.g., clients, servers, caches, tunnels, etc.) can mediate the request, but each does so without “seeing past” its own request (referred to as “layering,” another constraint of REST and a common principle in many other parts of information and networking architecture). Thus, an application can interact with a resource by knowing two things: the identifier of the resource and the action required—it does not need to know whether there are caches, proxies, gateways, firewalls, tunnels, or anything else between it and the server actually holding the information. The application does, however, need to understand the format of the information (representation) returned, which is typically an HTML, XML or JSON document of some kind, although it may be an image, plain text, or any other content.

RESTful web services

A RESTful web service (also called a RESTful web API) is a web service implemented using HTTP and the principles of REST. It is a collection of resources, with four defined aspects: the base URI for the web service, such as

  • The Internet media type of the data supported by the web service. This is often XML but can be any other valid Internet media type providing that it is a valid hypertext standard.
  • The set of operations supported by the web service using HTTP methods (e.g., GET, PUT, POST, or DELETE).
  • The API must be hypertext driven.

The PUT and DELETE methods are idempotent methods. The GET method is a safe method (or nullipotent), meaning that calling it produces no side-effects.

Unlike SOAP-based web services, there is no “official” standard for RESTful web services.This is because REST is an architectural style, unlike SOAP, which is a protocol. Even though REST is not a standard, a RESTful implementation such as the Web can use standards like HTTP, URI, XML, etc.

Why is it called Representational State Transfer?

The Web is comprised of resources. A resource is any item of interest. For example, the Boeing Aircraft Corp may define a 747 resource. Clients may access that resource with this URL:

representation of the resource is returned (e.g., Boeing747.html). The representation places the client application in a state. The result of the client traversing a hyperlink in Boeing747.html is another resource is accessed. The new representation places the client application into yet another state. Thus, the client application changes (transfers) state with each resource representation –> Representational State Transfer!

Here is Roy Fielding’s explanation of the meaning of Representational State Transfer:

“Representational State Transfer is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through an application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use.”

REST – An Architectural Style, Not a Standard

REST is not a standard. You will not see the W3C putting out a REST specification. You will not see IBM or Microsoft or Sun selling a REST developer’s toolkit. Why? Because REST is just an architectural style. You can’t bottle up that style. You can only understand it, and design your Web services in that style. (Analogous to the client-server architectural style. There is no client-server standard.)

While REST is not a standard, it does use standards:

  • HTTP
  • URL
  • XML/HTML/GIF/JPEG/etc (Resource Representations)
  • text/xml, text/html, image/gif, image/jpeg, etc (MIME Types)

REST Web Services Characteristics

Here are the characteristics of REST:

  • Client-Server: a pull-based interaction style: consuming components pull representations.
  • Stateless: each request from client to server must contain all the information necessary to understand the request, and cannot take advantage of any stored context on the server.
  • Cache: to improve network efficiency responses must be capable of being labeled as cacheable or non-cacheable.
  • Uniform interface: all resources are accessed with a generic interface (e.g., HTTP GET, POST, PUT, DELETE).
  • Named resources – the system is comprised of resources which are named using a URL.
  • Interconnected resource representations – the representations of the resources are interconnected using URLs, thereby enabling a client to progress from one state to another.
  • Layered components – intermediaries, such as proxy servers, cache servers, gateways, etc, can be inserted between clients and resources to support performance, security, etc.

Principles of REST Web Service Design

1. The key to creating Web Services in a REST network (i.e., the Web) is to identify all of the conceptual entities that you wish to expose as services. Above we saw some examples of resources: parts list, detailed part data, purchase order.

2. Create a URL to each resource. The resources should be nouns, not verbs. For example, do not use this:

Note the verb, getPart. Instead, use a noun:

3. Categorize your resources according to whether clients can just receive a representation of the resource, or whether clients can modify (add to) the resource. For the former, make those resources accessible using an HTTP GET. For the later, make those resources accessible using HTTP POST, PUT, and/or DELETE.

4. All resources accessible via HTTP GET should be side-effect free. That is, the resource should just return a representation of the resource. Invoking the resource should not result in modifying the resource.

5. No man/woman is an island. Likewise, no representation should be an island. In other words, put hyperlinks within resource representations to enable clients to drill down for more information, and/or to obtain related information.

6. Design to reveal data gradually. Don’t reveal everything in a single response document. Provide hyperlinks to obtain more details.

7. Specify the format of response data using a schema (DTD, W3C Schema, RelaxNG, or Schematron). For those services that require a POST or PUT to it, also provide a schema to specify the format of the response.

8. Describe how your services are to be invoked using either a WSDL document, or simply an HTML document.


This article described REST as an architectural style. In fact, it’s the architectural style of the Web. REST describes what makes the Web work well. Adhering to the REST principles will make your services work well in the context of the Web.



How to be a finisher at work

Here’s how to become known as a “finisher” at work:

  • Take ownership. Most people play “hot potato” with important work, so that they have someone else to blame if a project fails. Not you. Find an important task and own the outcome.
  • Get dirty. Forget about looking good in front of others or “making it look easy”. It’s OK to sweat, and it’s OK if other people know you are working your ass off.
  • Forget the fluff. Don’t get hung up on every last detail involved with a project. Identify the big thing that needs to get done. Focus on that and forget the rest.
  • Hold focus until the end. So many folks put in most of the hard work and then let up at the very end. What a waste. No breathing deep until the task at hand is 100% complete. After that… party like its 1999!