ScrumJet's experimental premise is simple: I wanted to learn more about [webmachine] 1. Basic task tracking is a fairly simple thing to implement and has lots of obvious ways to link things together.
Pre-requisitites:
- Mercurial (to get webmachine)
- Erlang/OTP
Shell 1:
make ./start-dev.sh
Shell 2:
./load-test-data.sh
Open [http://127.0.0.1:8000/] 8 in a web browser.
REST(Representational State Transfer) is an architectural style which can be applied well to such a system and webmachine makes it easy to implement in [Erlang] 2.
ScrumJet is broken out into resources for tasks, categories, boards and utility resources for representing linkages amongst them. Much of the motivation for this architecture came from reading [O'Reilly's book RESTful Web Services] 3. As such it focuses on providing a well-connected HTML representation of each resource. I am likely to eventually add [JSON] 7 representations to the resources for efficiency, but my goal at the moment is a proper RESTful architecture. I find it easier to achieve that in HTML.
Part of the motivation for this architecture is a secondary educational goal of learning how to build an ARIA on top of a RESTful web service using [Dojo] 5. Obviously [Dojo] 5 prefers [JSON] 7 so some ScrumJet resources are also able to represent themselves as [JSON] 7. It is an end-goal that all resources in ScrumJet will be able to do this.
ScrumJet's resources are implemented as [webmachine] 1 resources. Each resource generates an HTML representation based on state stored in one or more [mnesia] 6 tables. Specifically, each resource uses a gen_server to work with its primary state in an mnesia table and uses the gen_servers of other resources to determine connections or links to be rendered in the representation.