Lot of folks do not understand why Software estimation is so hard. The problem is folks who don’t understand the difficulty in estimating software make it more harder. I would compare software estimation to using a camera. The objects are fuzzy to begin with and slowly they get into focus. it is a process which requires constant refinement.

The main issue around estimation is the inability of most customers to provide clear and concise requirements. Most times the requirements are too high level like “what does it cost to build a house ? “. Of course the characteristics of a house can vary dramatically even within a fixed budget.

It is difficult to know whether you can build the product that the
customer wants in the desired time frame until you have a detailed understanding
of what the customer wants.

Decision making is very important in software development. Every decision at every stage in a project has implications both on cost and time. Estimates become more precise towards the completion of the project but that does not help the customer a lot. The diagram below illustrates this concept.

Most customers want more than what they can afford. There are three ways to complete a project in this case :
1) Staff the project to accomplish the required features. This may not always work .
2) Compromise the feature-set . In the case of a house a third bathroom may not be required after all !.
3) Both customer and developers meet halfway. This is mostly the common scenario.

There is a thin line between software estimation and project control. It is always possible to deploy to a cost and budget as long as the customer is willing to be flexible , which means that the customer should be able to let go of some features to meet the deadline.

It is always a best practice to provide good feedback to your customer. I have felt that it is always better to tell the stakeholders that I will update the estimate at each stage of the project requirement specification , product design , software design etc.

The reality is , the shortest actual schedule results from the most accurate, planned schedule

If the estimate is too low,planning inefficiencies will drive up the actual cost of the project. If the estimate is too high, Parkinson’s law (that work expands to fill available time) will drive up the actual cost of the project.

The goal of estimation should be a convergence between your estimate and reality. The closer they are aligned the better it will be for the overall project. This also requires a lot of support from customers. They should be able to prevent scope creep so the developers are not held accountable to features they did not commit to delivering. The sad reality I am yet to see a customer who is able to prevent scope creep !

At the end of the day it will be fair to say that software estimation is a process of constant refinement and the budget will normally drive this process along with precise requirements. Allowing for improper ( high or low) estimates will only delay the project.

Reference :
Rapid Development
Steve Mcconnel

RSS

Really Simple Syndication is a popular mechanism for receiving and publishing content from websites.Syndication is when information is categorized and normalized in addition to being collected.

Here are some key aspects of RSS 2.0:

The root element is <rss> (with the version="2.0" attribute).
The <rss> element must contain a single <channel> element, which represents the source of the feed.
A <channel> contains any number of <item> elements.
A <channel> is described by three mandatory elements (<title>, <link>, and <description>) contained within <channel>.
An <item> element is described by such optional elements, such as <title>, <description>, and <link>. An item must contain at least a <title> or <description> element.
The tags in RSS 2.0 are not placed in any XML namespaces to retain backward compatibility with 0.91–0.94.


ATOM

ATOM has more capabilities that it can be viewed as an exchange protocol based on HTTP. RSS is sufficient for publishing data but ATOM should be considered for replication and data exchange. ATOM can support editing and updating. Each and every node must be both unique and permanent. That goes for the “id” of the feed itself and the “id’s” of each individual “entry” node.

Here are some key aspects of ATOM:

Atom-related XML namespace (http://www.w3.org/2005/Atom).
The <subtitle> element instead of <description> (in RSS) describes the feed.
The <feed> and <entry> elements must both include an <updated> element.
<link rel="alternate" type="text/html" href="www.anandhansubiah.com"/> indicates that the document is an "alternate" representation (that is, a feed) of the web page http://www.anandhansubiah.com/.
<link rel="self" href="http://www.anandhansubbiah.com/blog/Atom1.0.xml"/> indicates the location of this feed document.
The attribute type="html" in the <summary> elements indicates the use of entity-encoded HTML.

Gdata

The Google Data API can be considered to be an extension of RSS and ATOM. Query capability ,authentication , updates and optimistic concurrency is the key differentiators between these different technologies. Optimistic concurrency refers to the ability to prevent different process’s from updating the data at the same time.The authentication preferred by Google when using the GData protocol is known as Authentication for Installed Applications, a Google-specific authentication mechanism. Third-party front-end applications to a GData service should use an authentication mechanism known as Account Authentication Proxy for Web-based Applications.

REST (Representational State Transfer)

REST has nothing to do with RSS, Atom or Gdata as it has nothing to do with content publication.REST is a system design explicitly intended to reflect the structure of the web. RESTful systems, according to the first constraint, are based on the client-server model—that is, the user interface and the data store are divided.RESTful systems are also stateless so no server side sessions are allowed.The third constraint requires that responses from a server in a RESTful system must be flagged (implicitly or explicitly) as cacheable.

Resources are at the heart of the four requirements of the RESTful uniform interface: resource identification, resource manipulation via representations, self-descriptive messaging, and the use of hypermedia as the engine of application state.

REST and HTTP are often spoken of together, but it is important to note that nothing requires that REST be implemented only on systems that use HTTP.

JSON

JavaScript Object Notation (JSON) is essentially a format for specifying JavaScript objects so that they can easily be transported. You could think of it as a way of serializing JavaScript objects.JSON is slowly gaining ground on XML, although is not intended to replace it. As a notation, it is clearly less verbose than XML, requiring less markup to convey the same data structure. Less data being transmitted on the wire leads to better performance of the application.

1.Request

4.Transport

There are five types of contexts in the hierarchy, which have been listed below with a brief explanation:

ConfigurationContext: This is the run-time representation of whole system. To start an Axis2 system, we need to have configuration context. The lifetime of configuration context will be the lifetime of the system. So, if we store some state (a property) it will last forever (until system shutdown).
ServiceGroupContext: In Axis2, we can deploy multiple services together as a service group. Then, the run-time representation of that is called ServiceGroupContext.
ServiceContext: This represents the run time of one service. The context lifetime will be the lifetime of the session. There can be one or many service contexts in the system, depending on the session scope of the corresponding service.
OperationContext: This context represents the lifetime of an MEP (Message Exchange Pattern). The lifetime of an operation context is, usually less than the lifetime of the ServiceContext.
MessageContext: The lifetime of an incoming message is represented by the message context. If two handlers in a given execution chain want to share data, then the best way to store them is in message context. One OperationContext may have one or more MessageContexts.

Request Session Scope

Request session scope is the default session scope in Axis2. When we deploy a service without knowing anything about session management, then our service will be deployed in request session scope. The lifetime of this session is limited to the method invocation lifetime, or request processing time. When we deploy a service in request scope, it simply means that we are not going to worry about the session management at all. So it is not like session management at all.

SOAP Session Scope

The idea of a SOAP session is to have a transport-independent way of managing session between two SOAP nodes, obviously between the client and the server. Here, Axis2 uses SOAP headers in order to manage the session. SOAP session scope has slightly longer lifetime as compared to a request session scope, and deploying a service in a SOAP session requires changing services.xml as well. Managing SOAP session requires both the client and the service to be aware of the sessions, that is, the client has to send the session-related data if it wants to access the same session, and the service has to validate the user using session-related data.

Transport Session Scope

In the case of Transport Session, Axis2 uses transport-related session management techniques to manage session. As an example, in the case of HTTP, it uses HTTP cookies to manage session. Then the lifetime of the session is controlled by the transport session and not by Axis2. What Axis2 does is store service context and ServiceGroupContext in the transport session object so that the service can access those contexts, as long as the session lives.

One of the key advantages that the Transport Session has over other sessions is that we can talk to multiple service groups within one transport session. In a SOAP session, we don’t have a way to communicate between two service groups, but with the transport session, we have that capability too. In this case, the number of service instances created depends on the number of transport sessions created.

Application Scope

Application scope has the longest lifetime as compared to all the others, and the lifetime of the application session is equal to the lifetime of the system. If we deploy a service in application scope, we will find that there is only one instance of the service implementation class. In addition to that, there will be only one ServiceContext for the deployed service. Considering the memory footprint, in the Axis2 world, it is better to deploy the service in application scope, if we don’t want to manage the session.

Reference : Quickstart Apache Axis2
by Deepal Jayasinghe

If the response entity-body does not come fresh from the server, the Age header is a measure of how long ago it left the server. This header is usually set by HTTP caches, so that the client knows it might be getting an old copy of a representation.

Cache-Control
Type: Request and response header

This header contains a directive to any caches between the client and the server (including any caches on the client or server themselves). It spells out the rules for how the data should be cached and when it should be dumped.

Content-Type
Type: Response header

Definitely the most famous response header. This header tells the client what kind of thing the entity-body is. On the human web, a web browser uses this to decide if it can display the entity-body inline, and which external program it must run if not. On the programmable web, a web service client usually uses this to decide which parser to apply to the entity-body.

Date
Type: Request and response header.

As a request header, this represents the time on the client at the time the request was sent. As a response header, it represents the time on the server at the time the request was fulfilled. As a response header, Date is used by caches.

ETag
Type: Response header.

The value of ETag is an opaque string designating a specific version of a representation. Whenever the representation changes, the ETag should also change.

Whenever possible, this header ought to be sent in response to GET requests. Clients can use the value of ETag in future conditional GET requests, as the value of If-None-Match. If the representation hasn’t changed, the ETag hasn’t changed either, and the server can save time and bandwidth by not sending the representation again.

The main driver of conditional GET requests is the simpler Last-Modified response header, and its request counterpart If-Modified-Since. The main purpose of ETag is to provide a second line of defense. If a representation changes twice in one second, it will take on only one value for Last-Modified-Since, but two different values for ETag.

Expires
Type: Response header

This header tells the client, or a proxy between the server and client, that it may cache the response (not just the entity-body!) until a certain time. Even a conditional HTTP GET makes an HTTP connection and takes time and resources. By paying attention to Expires, a client can avoid the need to make any HTTP requests at all—at least for a while.

The client should take the value of Expires should as a rough guide, not as a promise that the entity-body won’t change until that time.

If-Modified-Since
Type: Request header

This request header is the backbone of conditional HTTP GET. Its value is a previous value of the Last-Modified response header, obtained from a previous request to this URI. If the resource has changed since that last request, its new Last-Modified date is more recent than the one. That means that the condition If-Modified-Since is met, and the server sends the new entity-body. If the resource has not changed, the Last-Modified date is the same as it was, and the condition If-Modified-Since fails. The server sends a response code of 304 (”Not Modified”) and no entity-body. That is, conditional HTTP GET succeeds if this condition fails.

Since Last-Modified is only accurate to within one second, conditional HTTP GET can occasionally give the wrong result if it relies only on If-Modified-Since. This is the main reason why we also use ETag and If-None-Match.

If-None-Match
Type: Request header

This header is also used in conditional HTTP GET. Its value is a previous value of the ETag response header, obtained from a previous request to this URI. If the ETag has changed since that last request, the condition If-None-Match succeeds and the server sends the new entity-body. If the ETag is the same as before, the condition fails, and the server sends a response code of 304 (”Not Modified”) with no entity-body.

If-Unmodified-Since
Type: Request header

Normally a client uses the value of the response header Last-Modified as the value of the request header If-Modified-Since to perform a conditional GET request. This header also takes the value of Last-Modified, but it’s usually used for making HTTP actions other than GET into conditional actions.

Let’s say you and many other people are interested in modifying a particular resource. You fetch a representation, modify it, and send it back with a PUT request. But someone else has modified it in the meantime, and you either get a response code of 409 (”Conflict”), or you put the resource into a state you didn’t intend.

If you make your PUT request conditional on If-Not-Modified, then if someone else has changed the resource your request will always get a response code of 417 (”Precondition Failed”). You can refetch the representation and decide what to do with the new version that someone else modified.

This header can be used with GET, too; see the Range header for an example.

Last-Modified
Type: Response header

This header makes conditional HTTP GET possible. It tells the client the last time the representation changed. The client can keep track of this date and use it in the If-Modified-Since header of a future request.

In web applications, Last-Modified is usually the current time, which makes conditional HTTP GET useless. Web services should try to do a little better, since web service clients often besiege their servers with requests for the same URIs over and over again.

User-Agent
Type: Request header

This header lets the server know what kind of software is making the HTTP request. On the human web this is a string that identifies the brand of web browser. On the programmable web it usually identifies the HTTP library or client library that was used to write the client. It may identify a specific client program instead.

Soon after the human web became popular, servers started sniffing User-Agent to determine what kind of browser was on the other end. They then sent different representations based on the value of User-Agent. Elsewhere in this book I’ve voiced my opinion that it’s not a great idea to have request headers like Accept-Language be the only way a client can distinguish between different representations of the same resource. Sending different representations based on the value of User-Agent is an even worse idea. Not only has User-Agent sniffing perpetuated incompatibilities between web browsers, it’s led to an arms race inside the User-Agent header itself.

Almost every browser these days pretends to be Mozilla, because that was the internal code-name of the first web browser to become popular (Netscape Navigator). A browser that doesn’t pretend to be Mozilla may not get the representation it needs. Some pretend to be both Mozilla and MSIE, so they can trigger code for the current most popular web browser (Internet Explorer). A few browsers even allow the user to select the User-Agent for every request, to trick servers into sending the right representations.

Don’t let this happen to the programmable web. A web service should only use User-Agent to gather statistics and to deny access to poorly-programmed clients. It should not use User-Agent to tailor its representations to specific clients.

Cookie
Type: Request header

This is probably the second-most-famous HTTP header, after Content-Type, but it’s not in the HTTP standard; it’s a Netscape extension.

A cookie is an agreement between the client and the server where the server gets to store some semipersistent state on the client side using the Set-Cookie header (see below). Once the client gets a cookie, it’s expected to return it with every subsequent HTTP request to that server, by setting the Cookie header once for each of its cookies. Since the data is sent invisibly in the HTTP headers with every request, it looks like the client and server are sharing state.

Cookies have a bad reputation in REST circles for two reasons. First, the “state” they contain is often just a session ID: a short alphanumeric key that ties into a much larger data structure on the server. This destroys the principle of statelessness. More subtly, once a client accepts a cookie it’s supposed to submit it with all subsequent requests for a certain time. The server is telling the client that it can no longer make the requests it made precookie. This also violates the principle of statelessness.

If you must use cookies, make sure you store all the state on the client side. Otherwise you’ll lose a lot of the scalability benefits of REST.

Reference : RESTful Web Services
by Leonard Richardson; Sam Ruby

Everything’s fine. The document in the entity-body, if any, is a representation of some resource.

400 (”Bad Request”)

There’s a problem on the client side. The document in the entity-body, if any, is an error message. Hopefully the client can understand the error message and use it to fix the problem.

500 (”Internal Server Error”)

There’s a problem on the server side. The document in the entity-body, if any, is an error message. The error message probably won’t do much good, since the client can’t fix a server problem.

There are four more error codes that are especially common in web services:

301 (”Moved Permanently”)

Sent when the client triggers some action that causes the URI of a resource to change. Also sent if a client requests the old URI.

404 (”Not Found”) and 410 (”Gone”)

Sent when the client requests a URI that doesn’t map to any resource. 404 is used when the server has no clue what the client is asking for. 410 is used when the server knows there used to be a resource there, but there isn’t anymore.

409 (”Conflict”)

Sent when the client tries to perform an operation that would leave one or more resources in an inconsistent state.

200 (”OK”)

In most cases, this is the code the client hopes to see. It indicates that the server successfully carried out whatever action the client requested, and that no more specific code in the 2xx series is appropriate. My bookmarking service sends this code, along with a representation, when the client requests a list of bookmarks.

Entity-body: For GET requests, a representation of the resource the client requested. For other requests, a representation of the current state of the selected resource, or a description of the action just performed.

201 (”Created”)

The server sends this status code when it creates a new resource at the client’s request. My bookmarking service sends this code in response to a POST request that creates a new user account or bookmark.

Response headers: The Location header should contain the canonical URI to the new resource.

Entity-body: Should describe and link to the newly created resource. A representation of that resource is acceptable, if you use the Location header to tell the client where the resource actually lives.

307 (”Temporary Redirect”)

The request has not been processed, because the requested resource is not home: it’s located at some other URI. The client should resubmit the request to another URI.

For GET requests, where the only thing being requested is that the server send a representation, this status code is identical to 303 . A typical case where 307 is a good response to a GET is when the server wants to send a client to a mirror site. But for POST, PUT, and DELETE requests, where the server is expected to take some action in response to the request, this status code is significantly different from 303.

A 303 in response to a POST, PUT, or DELETE means that the operation has succeeded but that the response entity-body is not being sent along with this request. If the client wants the response entity-body, it needs to make a GET request to another URI.

A 307 in response to a POST, PUT, or DELETE means that the server has not even tried to perform the operation. The client needs to resubmit the entire request to the URI in the Location header.

An analogy may help. You go to a pharmacy with a prescription to be filled. A 303 is the pharmacist saying “We’ve filled your prescription. Go to the next window to pick up your medicine.” A 307 is the pharmacist saying “We can’t fill that prescription. Go to the pharmacy next door.”

Response headers: The Location header contains the URI to which the client should resubmit the request.

Entity-body: Should contain a hypertext document linking to the new URI, as with 301.

400 (”Bad Request”)

This is the generic client-side error status, used when no other 4xx error code is appropriate. It’s commonly used when the client submits a representation along with a PUT or POST request, and the representation is in the right format, but it doesn’t make any sense.

Entity-body: May contain a document describing why the server thinks there’s a client-side error.

401 (”Unauthorized”)

The client tried to operate on a protected resource without providing the proper authentication credentials. It may have provided the wrong credentials, or none at all. The credentials may be a username and password, an API key, or an authentication token—whatever the service in question is expecting. It’s common for a client to make a request for a URI and accept a 401 just so it knows what kind of credentials to send and in what format. In fact, the HTTP Digest mode of authentication depends on this behavior.

If the server doesn’t want to acknowledge the existence of the resource to unauthorized users, it may lie and send a 404 (”Not Found”) instead of a 401. The downside of this is that clients need to know, in advance, what kind of authentication the server expects for that resource: things like HTTP Digest won’t work.

Response headers: The WWW-Authenticate header describes what kind of authentication the server will accept.

Entity-body: A document describing the failure: why the credentials (if any were provided) were rejected, and what credentials would be accepted. If the end user can get credentials by signing up on a web site, or creating a “user account” resource, a link to the sign up URI is useful.

Reference : RESTful Web Services
by Leonard Richardson; Sam Ruby

The main question for any leader is

“Are you going to mark people’ papers or help them get an A ? ”

People who feel good at themselves produce better results. This may sound like a trap but I think there is value in analyzing this. I wanted to rephrase it to suit the corporate world – ” People who produce good results feel better about themselves”. This essentially means that both people and results are important. Overemphasizing any one of these will cause problems. A good leader should be able to balance this out.If people are not performing well then they will not be be happy.

There are three Key things to to making people perform

1) Performance Planning
2) Execution
3) Performance Review.

This has to happen iteratively till we achieve success. An employee’s performance should not be measured by just one cycle but constant reminders on performance objectives and reviews will help people focus.Evaluation is the tricky part of these key initiatives.

Setting goals is also not an easy task. If you can’t measure a goal you won’t be able to manage it . So , Any goal which is not measurable should not be set.Subjective evaluation may be required sometime but it is not recommended.

There is a 80/20 rule. 80% of the performance is going to come from the 20% of the activities. It does not mean that the other activities are not relevant but they may not contribute directly to the performance objectives.

The most important fact to understand is that there is no best leadership style. There are so different issues in the market place that a variety of skills are required to solve issues based on the situation. Another important aspect is nobody wants to fail even if they cannot succeed.

I would classify people into different categories

a) Low Competence / Experience , High Commitment.
b) Low Competence , Low Commitment
c) Moderate to High Competence , Variable Commitment
d) High Competence , High Commitment

It is possible to derive value from every category except (b). The Skill level is different for each individual but if there is no commitment they don’t deserve a place in the organization and they can have harmful effects on the team in general. It is the job of the leader to prioritize and assign the right tasks to the right people so there is maximum performance. For example a very good programmer may keep thinking only about improving the product and lose focus and derail the project. It is not that it is bad idea to try and improve the product but if the programmer is distracted from his core performance objective then it is a real problem. It is again the art of balancing if 90% of the focus is on programming and 10% is contributing to the product then there is a good chance of delivering on the performance objectives. It is the reverse for a product engineer . He has to focus 90% on improving the product and 10% of his time on other tasks.

Every single employee has a purpose in the team and a good sense of core responsibilities is a key factor for the overall success. An average programmer can focus that much more harder on his/her core area of expertise and over achieve. Employees will keep switching between (a) , (b) ,(c) and (d) depending on what they are assigned to do. If they are able to stay at (d) for a long period there is a good chance that they are moving up in the organization. If they are stuck at (b) then they can only pack their bags and go home.A good leader should help people stay at (d) most of the time if not all .

A leader should be able to direct , Coach , Support and delegate. A leader has to constantly switch between directive behavior and supportive behavior.

Inspired by : Helping People Win at Work: A Business Philosophy Called “Don’t Mark My Paper, Help Me Get an A”
by Ken Blanchard; Garry Ridge

Presentation Layer LPP: Lightweight Presentation Protocol

Session Layer RPC: Remote Procedure Call protocol

Transport Layer

ITOT: ISO Transport Over TCP/IP
RDP: Reliable Data Protocol
RUDP: Reliable UDP
TALI: Transport Adapter Layer Interface
TCP: Transmission Control Protocol
UDP: User Datagram Protocol
Van Jacobson: Compressed TCP

Network Layer Routing

BGP/BGP-4: Border Gateway Protocol
EGP: Exterior Gateway Protocol
IP: Internet Protocol
IPv6: Internet Protocol version 6
ICMP/ICMPv6: Internet Control Message Protocol
IRDP: ICMP Router Discovery Protocol
Mobile IP: IP Mobility Support Protocol for IPv4 & IPv6
NARP: NBMA Address Resolution Protocol
NHRP: Next Hop Resolution Protocol
OSPF: Open Shortest Path First
RIP (RIP2): Routing Information Protocol
RIPng: RIP for IPv6
RSVP: Resource ReSerVation Protocol
VRRP: Virtual Router Redundancy Protocol

Multicast

BGMP: Border Gateway Multicast Protocol
DVMRP: Distance Vector Multicast Routing Protocol
IGMP: Internet Group Management Protocol
MARS: Multicast Address Resolution Server
MBGP: Multiprotocol BGP
MOSPF: Multicast OSPF
MSDP: Multicast Source Discovery Protocol
MZAP: Multicast-Scope Zone Announcement Protocol
PGM: Pragmatic General Multicast Protocol
PIM-DM: Protocol Independent Multicast – Dense Mode
PIM-SM: Protocol Independent Multicast – Sparse Mode

MPLS Protocols

MPLS: Multi-Protocol Label Switching
CR-LDP: Constraint-Based Label Distribution Protocol
LDP: Label Distribution Protocol
RSVP-TE: Resource ReSerVation Protocol-Traffic Engineering
GMPLS: Generalized Multi-Protocol Lable Switching

Data Link Layer

ARP and InARP: Address Resolution Protocol and Inverse ARP
IPCP and IPv6CP: IP Control Protocol and IPv6 Control Protocol
RARP: Reverse Address Resolution Protocol
SLIP: Serial Line IP

Related protocol suites LAN, MAN, WAN, SAN, Security/VPN

Sponsor Source IETF, DARPA, ISO

The OSI 7 layers model has clear characteristics at each layer. Basically, layers 7 through 4 deal with end-to-end communications between data source and destinations, while layers 3 to 1 deal with communications between network devices. On the other hand, the seven layers of the OSI model can be divided into two groups: upper layers (layers 7, 6 & 5) and lower layers (layers 4, 3, 2, 1). The upper layers of the OSI model deal with application issues and generally are implemented only in software. The highest layer, the application layer, is closest to the end user. The lower layers of the OSI model handle data transport issues. The physical layer and the data link layer are implemented in hardware and software. The lowest layer, the physical layer, is closest to the physical network medium (the wires, for example) and is responsible for placing data on the medium.

The specific description for each layer is as follows:

Layer 7: Application Layer

* Defines interface to user processes for communication and data transfer in network
* Provides standardized services such as virtual terminal, file and job transfer and operations

Layer 6: Presentation Layer

* Masks the differences of data formats between dissimilar systems
* Specifies architecture-independent data transfer format
* Encodes and decodes data; encrypts and decrypts data; compresses and decompresses data

Layer 5: Session Layer

* Manages user sessions and dialogues
* Controls establishment and termination of logic links between users
* Reports upper layer errors

Layer 4: Transport Layer

* Manages end-to-end message delivery in network
* Provides reliable and sequential packet delivery through error recovery and flow control mechanisms
* Provides connectionless-oriented packet delivery

Layer 3: Network Layer

* Determines how data are transferred between network devices
* Routes packets according to unique network device addresses
* Provides flow and congestion control to prevent network resource depletion

Layer 2: Data Link Layer

* Defines procedures for operating the communication links
* Frames packets
* Detects and corrects packets transmit errors

Layer 1: Physical Layer

* Defines physical means of sending data over network devices
* Interfaces between network medium and devices
* Defines optical, electrical and mechanical characteristics

I had a Windows XP box before. I had a Belkin print router which was connected to two HP printers, Logitech web cam,HP Media Vault and Logitech Blue tooth speakers.

I purchased a 64 bit Vista Ultimate box from HP with 6 GB RAM. Every single device I had connected works without any issues now. Vista even downloaded drivers for most of those devices without any issues.The bluetooth Keyboard and mouse installed automagically when I had to struggle to make them work in my XP box. I installed iTunes( there is no integration with IPhone but it is not Microsoft’s fault), muvee auto producer, Eclipse and NetBeans.

I installed the 64 bit flavors of IE , Firefox(minefield) and ITunes and they are lightning fast.

My verdict is Vista has come a long way and if you get a pre-installed box from HP or Dell you might like Vista.

Android applications, like most mobile phone applications, are developed in a host-target development environment. In other words, you develop your application on a host computer (where resources are abundant), and download it to a target mobile phone for testing and ultimate use.

To write your own Android mobile phone applications, you’ll first need to collect the required tools and set up an appropriate development environment on your PC or Mac.

The Android SDK supports several different development environments. For this book we will focus on using Eclipse, because it is the best integrated with the SDK, and, hey, it’s free. No matter which operating system you are using, you will need essentially the same set of tools:

* The Eclipse Integrated Development Environment
* Sun’s Java Development Kit (JDK)
* The Android Software Developer’s Kit (SDK)
* A special Eclipse plug in: the Android Developer Tool (ADT)

Creating an Android Development Environment

The Android Software Development Kit supports Windows (XP and Vista), Linux (Ubuntu Dapper Drake), and Mac OS X (10.4.8 or later) as host development environments. Installation of the SDK is substantially the same for any of the operating systems, and most of this description applies equally to all of them. Where the procedure differs, we will clearly tell you what to do for each environment.

1.Install Eclipse:
2.Check for Required Plugins
3.Install JDK: The Android SDK requires JDK version 5 or version 6.
4. Install Android SDK: This is where you’d start if you already have the right versions of Eclipse and the JDK loaded. The Android SDK is distributed through Google’s code site, http://code.google.com/android/download.html.
5. Update Environment Variables: To make it easier to launch the Android tools, add the tools directory to your path.
6. Install the Android Plugin (ADT): https://dl-ssl.google.com/android/eclipse.

Starting a New Android Application: HelloWorld

Several components are needed to build an Android application. Fortunately, the Eclipse IDE with the Android plug-in automates a lot of the work needed to create and maintain these components. We will start by using the IDE to create a project for our application. Start up Eclipse and select “File -> New -> Project…” from the menu bar (be sure to select “Project…,” not “Java Project”).

Select “Android Project” and click “Next” to get the “New Android Project” dialog box.

We’ll use “HelloWorld” as the name for both the Project and the Application. You don’t need to change the button or checkbox selections, and we’ll use the package name com.oreilly.helloworld as shown.

Every Android application has to have at least one Activity (an executable that usually has a user interface), so let’s say we’re going to include an Activity called HelloWorldActivity, as shown in the dialog box. Click “Finish,” and the Android Development Kit does a number of things for you, to make your life easier as a developer. In [figure to come], I’ve expanded the tree in the Package Explorer window to show some of the files and directories that the ADK created.

The ADK created a HelloWorld directory in the default Eclipse workspace for your project. It also created subdirectories for your source files (.src), references to the Android Library, assets, resources (.res), and a manifest file (AndoidManifest.xml). In each of the subdirectories it created another level of subdirectories as appropriate. Let’s take a quick look at them:

Sources (under .src)

* Contains a directory structure that corresponds to the package name you gave for your application: in this case, com.android.helloworld.
*Contains a Java template for the Activity you indicated was in the application (HelloWorldActivity) and a directory of resource references (R.java). We’ll come back to R.java later.

Android Library

This is just what it says. If you like, you can expand the android.jar tree and see the names of the modules included in the library. This is where your application will go for Android library references.

assets

Files you want to bundle with your application. We won’t have any for HelloWorld.

Resources (under .res)

* Drawable resources are any images, bitmaps, etc. that you need for your application. For HelloWorld, the ADK has supplied us with the default Android icon, and that’s all we’ll need.
* Layout resources tell Android how to arrange items on the screen when the application runs. These resources are XML files that give you quite a bit of freedom in laying out the screen for different purposes. For HelloWorld, we’ll just use the defaults generated by the ADK
* Values are constants, strings, etc. available for use by your application. Keeping them outside the sources makes it easier to customize the application, such as adapting it for different languages.

Manifest (AndroidManifest.xml)

This is another XML file that tells the Android build system what it needs to know to build and package your application so it can be installed on an Android phone or the emulator. This file has its own specialized editor, which we’ll describe as we get to more complicated applications.

Double Click on HelloWorldActivity.java
Looking quickly at the template code that the ADK has provided for us, we can note several things:

*The ADK has included the package reference we asked for, which is consistent with the directory structure it created.
*It has also created a (collapsed) set of imports for the library references it knows we need.
*It created a class definition for the Activity we said we wanted (HelloWorldActivity) including a method called OnCreate.

For the moment, don’t worry about the parameter passed into OnCreate. The icicle Bundle is a way of passing data between activities and storing data between instantiations of the same Activity. We won’t need to use this for HelloWorld.
* One special line of code has been included in OnCreate:

setContentView (R.layout.main);

Remember that Android uses layouts to define screen layouts on the target, and that main.xml was the name of the default layout file that the ADK created for us under .res/layout. The R.java file is generated automatically and contains java references for each of the resources under .res. You will never need to edit the R.java file by hand— the ADK takes care of it as you add, change or delete resources.

Double Click on main.xml
Again, let’s look at the key features of this template code:

* Like any other XML file, this one starts with a reference to the XML version and encoding used.
* LinearLayout is one of the screen layout formats provided by the ADK. There are several others, which can be combined hierarchically to create very complex screen layouts. For our purposes, a simple linear layout is fine.

Within the LinearLayout definition:
o The code:

xmlns:android=”http://schemas.android.com/apk/res/android”

identifies the XML schema being used.
o The code:

android:orientation=”vertical”
android:layout_width=”fill_parent”
android:layout_height=”fill_parent”

defines an orientation, width and height for the entire scope of the layout.
*TextView describes how to handle text within…. It resembles the text boxes you may have encountered when programming in other graphical environments.

Within the TextView definition:
o The code:

android:layout_width=”fill_parent”
android:layout_height=”wrap_content”

a width and height for the TextView box.
o The code:

android:text=”Hello World, HelloWorldActivity”

provides some text to display in the TextView. By a stroke of luck, the ADK has already included text that is almost what we wanted to display anyway. Just to show them who’s boss, change the android:text line to say “Hello, Android!”, or something else equally clever:

android:text=”Hello, Android!”

if you edit the file, save it either from the Eclipse File menu (File -> Save) or by clicking on the diskette icon in the menu bar.

Believe it or not, we’re done. We don’t have to write a single line of Java to create this application.

From the Eclipse menu bar, select Run -> Run. A “Run As” dialog box will pop up. Select “Android Application” from the list and you can see your first Android Application.

Reference : Android Application Development, 1st Edition
By: Rick Rogers