-
-
Notifications
You must be signed in to change notification settings - Fork 196
Developers guide
Mark Longair edited this page Nov 11, 2013
·
17 revisions
- The software is written in Ruby on Rails 3.x. We support postgresql as the backend database. A configured MTA like exim, postfix or sendmail is necessary to parse incoming emails. We have production sites deployed on Debian Squeeze and Ubuntu (10.04 LTS). For performance reasons, we recommend the use of Varnish.
- There's a page about Understanding the code with a diagram of the models, etc.
- There's some simple API documentation in the wiki.
- If you need to change or add strings in the interface, please read Marking up text for translation.
- We use the git flow branching model, with a small change: currently our
develop
branch is calledrails-3-develop
, which means that the latest development version is always found on the rails-3-develop branch. The latest stable version is always on the master branch. If you plan to collaborate on the software, you may find the git flow extensions useful. - Installing the software is a little involved, though it's getting easier. If you stick to Debian or Ubuntu, it should be possible to get a running version within a few hours. The documentation is in INSTALL.md. There is an Alaveteli EC2 AMI that might help you get up and running quickly (though it is not always up to date with the latest version). Get in touch on the project mailing list or IRC for help.
- A standard initial step for customising your deployment is Writing a theme. If you only read one thing, it should be this!
- Like many RoR sites, the software is not hugely performant (see some notes about performance issues gathered over time with WhatDoTheyKnow). The site will run on a server with 512MB RAM but at least 2GB is recommended. Deployment behind Varnish is also fairly essential. See Production Server Best Practices for more.
- We use
gettext
for i18n. See I18n guide for notes about its use in the software. - There's a number of proposals for enhancements, such as more user-focused features
- We try to ensure every commit has a corresponding issue in the issue tracker. This makes changelogs easier as we can gather all the fixes for a particular release against a milestone in the issue tracker, like this 0.4 release.
- If you're experiencing memory issues, this blog post about some strategies used in the past might be useful.
If you are developing on OS X, please see the OS X Quickstart guide.