Web Service in Restful way

Principles of REST Web Service Design

1. Identify all possible conceptual entities that we want to expose as web services. Everything is a consider the resource that will make available as services.

2. Each resource should has its own URI and identify the resources by a noun not a verb

Incorrect: http://www.parts-depot.com/parts/getPart?id=00345

Correct: http://www.parts-depot.com/parts/00345

3. Categorize the resources so that the client can receive a representation of of resource or they can modify it. At the initial state, make those resources accessible using an HTTP GET, Then using HTTP POST, PUT, and/or DELETE for modification states.

4. Resource that is accessible through HTTP GET should just return a representation of the resource. The invocation of the resource should not result in modifying the resource.

5. No resource should be placed in isolation, but hyperlinks (href), so the user can drill down to detail information or at least to the related information.

6. Don't put all resources in a single show room. Provide hyperlinks to obtain more details resources.

7. Specify the format of response data using a specific 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.

What make pair programming doom

When start talking about pair programming, it's so obvious that there must be two people working together. wow it sounds such a wasteful to spend on work that can be done with only one man work. I would say 'yes' and 'no'. it's all about how you implement it. Kent Beck has a good explanation and guide line about XP. I'm here not to repeat him, but just to give some feed back of what I have read and sharing some experience that my team has implemented for this last 5 months.

What made our team success

1. Our work survives and goes smoothly width rhythm of switching keyboard, writing test, make the test pass and refactor the code. one person become a driver start writing a test, then other person become an observer and thinking ahead of making the test pass. after the driver finished hist test, he pass the keyboard to other person to make the test pass and he becomes the observer. the next person just has to make the test pass, no matter how the ugly the code is. Once the wrote the code that makes the test passes, Then he passes the keyboard to other to make the code clean.
2. Break the big task into smaller task that can be done within a day if possible and keep the rhythm to complete those tasks.
3. Survive with rules defined by team. Rules is one of the most important thing to make pair programming effectively executed. eg. the team member must update the code every morning, every time he wants to added new feature or event before start fixing bugs. the member must not leave code uncommitted over night. That looks simple, but it needs times, effort and practice to be part of your work.
   

I think i won't go to much into detail, Kent Beck is still the best person that you can refer to regarding all aspect of pair programming.