#Roomtrol Daemon This repository holds the code for the Roomtrol daemon that runs on controllers and interacts with devices. More information can be found in the wiki (like how to write devices, how to set up Ubuntu, and various planning docs) and in the documentation, which can be generated by running rake docs inside the roomtrol-daemon directory.

Roomtrol is split into three parts: this daemon, roomtrol-server which holds both the backend and frontend code run on the central server as well as the touchscreen interface, and roomtrol-devices which holds the various device drivers that have been written.

Note: in order to get device drivers, you need to run these two commands: git submodule init and git submodule update.

##Development notes ###Code style All code should match the following style: tabs for indentation and spaces for aligning and line lengths should be minized but there is no hard cut-off. For Ruby code, class names ShouldBeCamelCased, variable and method names should_be_underscored, every method and class should be documented using Yardoc tags and markdown formatting and RSpec tests should be written for all functionality.

For Javascript, the same formatting rules should apply, but variable and method names shouldBeCamelCased as well as class names. Methods and classes should be documented using JSDoc. Also, all code should be run through JSLint and any errors it identifies should be corrected (this means no global variables and semi-colons are mandatory).

In general, try to maintain the style already found in the code.

###Git usage We are using Git Flow as described in that blog post. There is also a tool that makes it easier to follow. The basic idea is that the master branch should only be used for tested and vetted releases. The normal development integration branch is develop, while features are staged in their own branches, which are named features/xxx. When a feature is finished, it is merged back into develop. When a number of features have been finished and it becomes prudent to release, you create a release branch from develop. The release branch is then heavily tested and any issues found are fixed. When considered production-ready, the release branch is merged into master, which is then tagged with the version number. This way, master is always stable and ready to be deployed, while you can have more freedom to break things in your feature branch and in develop.