Protocols for working together

##GitHub Team Forks Each team will create a fork from SOUSMS.
Then each individual on the team will pull their team’s fork to their local system.

Next week, when the team fork has a consistent and working set of code and all team members are sync’ed with the team fork, then the team’s designated repository person will push the team fork up to nordquip/sousms. Ryan will produce instructions on how to do this push operation.

##Git markdown format for documentation Please use markdown format (file extension .md) for documentation files in the repository. This is the format you use when you edit wiki pages on github.com. It looks a little funny, but is easy to read and write in raw form and makes a nice web page on github.com.

• You can see a quick summary of the syntax by clicking the Edit page button on any wiki page then clicking the question-mark-in-a-circle button.
• Cheatsheet for writing markdown at https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet

Interfaces

In a project where many people are involved, eliminating bottlenecks and preserving independence are treasured goals.

We want to create protected ‘sandboxes’ where people can work without interfering with others. The primary tool for accomplishing this goal is through well-defined interfaces. (APIs are such interfaces.) Interfaces provide a way for a service provider to:

• Localize changes to a single place
• Limit the things one group must know about another

We can start by ‘walling off’ the database, by enforcing a protocol that SQL commands are not issued from anywhere but a stored procedure. Stored procedures will be the middle-ware of our application.

So, if you are a group using the database (all groups), you must isolate the ‘things’ you need to know and write a stored procedure for each different kind of ‘thing’.

For example, the trade engine wants to say something like: ‘Buy 100 shares of INTC’, so we create a stored procedure:

buy(symbol, numberShares, price)

This procedure must:
* Identify the current user
* Check to see if this user has enough cash to buy numberShares at price.
* If so, decrement the user’s cash account appropriately and add numberShares of symbol to the user’s stock account.
* If not, return ‘not enough cash’ error

Notice, the 'return value' can be specified as part of the description of the interface.
Return values can be arbitrarily complex, including a list of items.

All interfaces must be reviewed and documented. The person doing the writing may come from whichever group can get the job done, but the effort must be coordinated with all affected groups. We will publish these interfaces as part of the documentation.

I will produce a sample stored procedure for mysql next week.