PDF Parser Integration associated with How to be a Hero

Languages used:
JavaScriptMySQLPHPShell

Frameworks used:
MediaWikiNode.jsUbuntu Server

Target platforms:
Web

The project

How to be a Hero is a German pen-and-paper-ruleset designed with first-time players or dungeon masters in mind. Rules are simple, yet allow for diverse worlds and settings.

Started in 2015 by Hauke Gerdes, dungeon master for Rocket Beans' self-titled show Pen and Paper and their various adventures (season 1 VODs with over 7 million views and counting + livestreams with over 20.000 concurrent viewers), the ruleset has moved to a public licence maintained by the non-profit organisation How To Be a Hero E.V. and is available to download, use and edit on the associated MediaWiki-instance at howtobeahero.de.

Artists, designers and writers alike can take part in the editorial staff meetings and participate, bringing their own ideas to life, adressing problems or help to extend the ruleset where seen necessary.

My tasks 04/2018 - 11/2018

howtobeahero.de allows users to create printable versions of portions of content selected by the editorial staff.
Instead of relying on CSS-media queries, a custom tool was built to create printable .PDFs, based on the raw wiki markup of wiki articles, which is deeply integrated inside the MediaWiki-instance.

To allow easy development and quick itteration cycles, I was responsible for building a simple backend tool allowing for continuous delivery of the PDF Parser.

As the code for the Parser is available under the same license as the wiki's content, a GitHub webhook is used to detect changes of the source code on either public or development branches. A PHP-page modifies the configuration file used by a custom Ubuntu-system-service built in Node.js responsible for deleting and adding new instances as needed.

This allows developers to see their changes to the Parser on the exact target machine and stage changes publicly, so other developers can inspect changes without a local copy having to be set up by each developer. Additionally public testers can verify changes before going live and aren't required to be experienced in working with the source code or deployment thereof.