I thought it would be interesting to clone a small utility I did at work in a language setup for rules enforcement.
Short answer: the same code in Python was ~400LOC over Prolog's ~200LOC. More importantly, Prolog's design was cleaner as the Python program used sqlite as an intermediate format to allow querying. Likewise, representing facts are more elegantly represented as atoms than strings. Finally, the ability to easily create a standalone executable is a winner.
To build the PDF files, you'll need reasonably current versions of the following:
- groff -- tasklist.pdf and detailed_tasklist.pdf
- graphviz -- graph.pdf / graph.svg
- plantuml -- gantt.pdf / gantt.svg. Since setting plantuml up to output PDF looks painful, you'll also need a utility to convert encapsulated Postscript to PDF. On OSX, this is already setup with the pstopdf utility. On other POSIX systems, you'll need to install ghostscript and the Makefile will pickup ps2pdf if it's in your PATH.
While the accompanying Makefile builds using testproject.pl for the project, you can create your own by overriding PROJECT in the make call. Beyond PROJECT, PROLOG, GROFF, DOT and PLANTUML can also be overridden.
Creating a new project is intended to be really simple (my goal was a 60-minute project planner for my own use) as you need to create a file for your project and add facts that represent your project to it. When creating project facts, ensure they represent a directed acyclic graph. Finally, subtasks have two unique behaviors--unless it's explicitly overridden, the owner will be inherited from the parent task and the state defaults to TODO. When setting up a project, you can set states for subtasks. Read the comments in testproject.pl to understand how the tasks' state will be aggregated based on the state of its subtasks. You can set the color used for the state in the graph as well as the text used to aggregate the state of a task as a rollup of its subtasks. NOTE: it's crucial to have at least two states as the second one will be used for the text when a set of subtasks don't all have the same state. Since Prolog evaluates tasks in order, it's crucial that the last task be the final one for the project so we can find critical path tasks. Finally, you can choose either a start or end date for generating your plan.
Caveats
- tasks must have a unique name.
- task duration field is the number of weeks prior to the intended release date.
- since Prolog evaluates tasks in order, the final task must be the final one for the project (typically called something like release or general availability). Furthermore, the final task must have a duration of 0 as it's more event than task.
Credit: this page was crucial as it shows the mechanics of setting up a build system for a standalone executable.
Possible TODOs
- Fix the Makefile to rebuild files correctly if there's an intermediate error. Workaround: touch projectdir/project;make.
- Create an extensibility mechanism to allow a project to have custom reports.
- Create a README.md for some user doc.