Biocomputing II

Summary Guidance

  1. Use the skeleton GitHub repository at github.com/AndrewCRMartin/biocomp2/ as a starting point - this provides a simple working example! See below for how to use it as your initial git repository.
  2. Defining clear APIs (documenting exactly which functions or methods are exposed to the front end and how these are to be called) for the middle layer and for the database access layer is absolutely critical. The database access layer should isolate changes in the database design from the middle layer: if the database design changes, the middle layer should not be affected. Similarly the middle layer, which implements all the calculations on the data, should not have to change if either the database layer or the front end changes (assuming the front end doesn't require some new piece of information).
  3. Create dummy versions of all the methods or functions that take parameters and return dummy data in the form required by the API you have defined. Once everyone has done that then there is no need to wait on the other members of the group - as the dummy versions get replaced by real code the functionality should start to appear.
  4. Configuration files are important! You don't want to have to modify the code itself when porting from one machine to another.
  5. The importance of regular meetings - especially at the start to design the database and the APIs. The practical slots are reserved for you to do this over the next three weeks, by which time your APIs should be defined and then you can largely work independently. Nonetheless, the team should meet once a week throughout the project (by Skype if necessary) - "The lesson is that constant interaction, even brief, is fundamental and also helps constant exchange of opinions".
  6. You should strive to define those APIs such that they will not change during the course of the project. Nonetheless, you should accept that they may have to change, but that any such change must be discussed, justified and documented.
  7. You will learn about GitHub and test-driven design over the next couple of weeks - GitHub will help you enormously with sharing code in your group and tracking changes. You are also expected to show some evidence of code testing.
  8. This is NOT a trivial project - it requires dedicated time and effort.
  9. It is supposed to be a cooperative effort. Those with more experience should be prepared to help the others. The continued meetings should include code reviews. Look at and criticize each other's code. Point out where comments and code could be clearer. One of the things we are looking for is that the team works well together and tries to solve problems in how people cooperate with each other. Nonetheless, providing the APIs have been defined and dummy code has been implemented, if someone doesn't pull their weight or has to drop out of the course, you should still be able to work on your part of the code and you won't be penalized for the fact that parts of the system are missing.
  10. Don't panic! If you have limited programming experience, this may seem like a daunting project. Every year people have come into the project with the same concerns, but we have never had anyone not able to complete their part of the project providing they have committed themselves to the required work

Using the skeleton repository

Take the following steps to create your own repository based on the skeleton:

You now have your own repository with the skeleton code. If you modify the install.sh to specify correctly where the HTML pages and CGI Python scripts need to live and modify the cgi-biocomp2/config_demo.py file to specify the URL for accessing the CGI scripts over the web, you should just be able to type ./install.sh and have a working demo of where you need to start with your code.

You should download some general guidance on what is expected. See the Good Code section for further help.