See also the assignments section of the Syllabus.
The final project should be a capstone experience, allowing your to synthesize the skills, tools, and concepts you’ve learned over the semester. Ideally, the project will incorporate some of the knowledge you brought to class and lead in a direction that links up with other SILS courses or your intended career. To give you a sense of the scope I’m anticipating for the final projects, here is a list of some that you might select:
Build and package a Python program
Find and substantially modify an existing Python program (e.g. a Pygame game)
Build and deploy a set of Bash or Python scripts to automate a workflow (e.g. PDF slicer/recombiner)
Make a custom Emacs or Vim setup (with, e.g. multiplexing, keybindings, plugins, etc)
Build and deploy a Linux web server and basic HTML site
Build and deploy a Raspberry Pi-based internet connected device (e.g. Twitter printer)
Build, customize and deploy a Jekyll-based blog to Github or your own server
Note that we won’t cover all of these topics in class, but we will learn how to learn new technologies, so motivated students should have no problem implementing projects like these using open resources and my help. Each project should utilize appropriate open source code or programs. In every case, the finished project source should be available on Github.com and be fully documented so that others (and most importantly your instructor) can see how and why you built them. Ideally, they’d also include a roadmap for future changes and indications of how others might get involved.
Projects that are less technically accomplished should include additional research into the history of their open source components and an account of the community that surrounds them. Finally, give an account of the developer tools such as text editors, version control, and communication methods you used, along with why you chose that particular workflow, how it worked, and how you might alter it in the future.
Full details will be distributed later in the semester.
Form a group, if desired.
Submit a project proposal that addresses the following questions:
* What is the project purpose and vision? For example, Jekyll aims to be a static site generator suitible for blogging using the command line.
* What are some initial scoping and milestones you've identified? This is a very important piece, so give it a lot of thought. Each milestone should contribute something substantial to the project and yet be relatively small.
* What division of labor between groups will you use (if any)?
* What technologies have you identified to use in the project? Programming languages, libraries, frameworks, and even hardware (e.g. Raspberry Pis) are examples of technologies you might use.
* Who else will find this project useful and how will you make it available to them? All projects should be Github repositories, but example sites or Getting Started documentation are important for re-use.
It's OK to not have an answer for all of these, or to for instance not know exactly what software library you'll pick, but describe the range of choices you've identified and how you'll make the decision.
Please turn this proposal in, one per group, by adding me to a Google Document. I'll leave comments on it directly, so remember to give me the rights to do so!
Many readings will be drawn from Think Python, which is available for free at http://www.greenteapress.com/thinkpython/ and can be purchased in print on Amazon. We won’t cover the entire text, but it is an excellent source for those who plan to go deeper with Python beyond the course. Other open texts include Learn Python the Hard Way and Pro Git.
Lectures on software-carpentry.org will be assigned to give background before some class sessions and exercises. These lectures can be watched via video or read via the transcript and slides available on the page. (For an example, see http://software-carpentry.org/4_0/shell/intro.html)
The incomplete but generally excellent Hitchiker’s guide to Python (http://docs.python-guide.org/en/latest/) contains many real-world things like code styling, commenting, and documentation convetions. Several readings are drawn from it.