Contribution to the Animal Rights Network

General

This application is a non-profit project, aimed to fuel the effectiveness of the animal rights community to create a more just and sustainable future. It is currently maintained by a single developer in his spare time. Contribution is highly desired to accelerate the development and the growth of this project.

The first target is to implement the network into the animal rights movement in Europe's capital of veganism: Berlin. It's going to be deployed on an Uberspace using an Apache web server and a MySQL database until higher server capacities are required.

Tech Stack

The Animal Rights Network is developed in the Ruby on Rails web framework, using CoffeeScript for client side code and Sass together with Compass and Susy for styling.

Checkout Ruby Monk for an introduction to ruby and take a look at the free Rails Tutorial Book and the official Rails Guides to learn Ruby on Rails.

Development Guidelines

The development of this project is aided by git for version control, GitHub for collaboration and specification and the test utilities offered by Rails. For each of these, some guidelines apply to ensure consistent and maintainable results.

Release cycle

The development is structured into isolated releases which are first specified and then systematically implemented. Feature requests are welcome and will be integrated into the release cycle.

GitHub

GitHub is used for specifying and organizing releases.

For every release, a milestone with a rough specification of the planned implementations is created. It describes an overview of the steps that have to be taken and specifies the desired functionality in the form of use cases and other requirements. After pulling and tagging a release into the master branch, the pull request is referenced in the corresponding milestone before it gets closed.

To specify the exact requirements and structures, issues with the "specification" label are created within the milestones and assigned to developers. The issues may contain URL tables, ER diagrams and other in depth descriptions of the desired results. The feature branches, belonging to a feature, are referenced in the issue, which then gets closed as soon as the the implementation is finalized and the feature is merged into the develop branch.

Git

Git is used for consistent and clear source control by committing frequently and expressively and using one develop and many feature branches.

The branching model in this project is inspired by the GitFlow but it's a little more compact:

• The master branch is only used for tagged releases and bug fixes and should only be modified via reviewed pull requests or for minor bug fixes after a release.
• The develop branch is where the current release is developed on. It should also only be modified via reviewed pull requests from feature branches or to merge bug fixes from master.
• The feature branches are where the actual work happens. For every self-contained feature a feature branch is created where the development commits go. This is the only type of branch, where failing test cases are permitted. Before pulling it into the develop branch, it should be tested and fully functional.

Commits should occur frequently and only after logical breaks like finishing the test cases for a feature or a specific model, setting up a new model with its migrations, implementing a helper method etc.. The commit messages should follow these best practices:

• The first line constitutes a concise, yet expressive subject of at most 50 characters. It starts capitalized, does not end with a period and uses the imperative mood like so: Add integration tests for the "event" controller
• If the commit is not trivial, a body text is added after a blank line with lines of up to 72 characters

Testing

This project makes use of the test driven development concept. That means that the implementation of a feature begins with writing test cases, asserting the specified behaviour. These test cases are supposed to fail at first with the goal of making them pass by implementing the desired functionality. If necessary the code can be refactored after that.

Rails automatically generates the following kinds of test classes:

• Model tests: Test validations and model functionality
• Mailer tests: Test mailer functionality and mail content
• Functional tests: Test specific work flows for a controller by executing and evaluating request sequences

These test classes can be generated manually:

• Helper tests: Test helper functions
• Integration tests: Test specific work flows by executing and evaluating request sequences
• System tests: Simulate user interaction in a real browser

Rails also generates fixture files to specify test data.

Editor

Having an editor with syntax highlighting and Rails support may help the development speed and satisfaction. I'm using Vim with tmux and a bunch of plugins both on the production server and my local machine.

Disclaimer

I'm not an expert myself. Even though I'm studying computer science, I have no professional experience with Rails and web development in general. Please point out any bad practices, inconsistencies and general suggestions for improvement to me, so that I can grow as a developer and make this project even more maintainable, secure and successful. Breaking with these guidelines is not fatal. I will probably have to consult them myself every now and then to stay on the right track :stuck_out_tongue: