COA001

COASST dynamic website

Getting Started

1. Clone this repo

2. Make sure you have the required version of ruby

cat Gemfile | grep ruby will show the proper version of ruby to use

I suggest using rvm to manage different versions of ruby

3. Install dependencies

bundle install

4. Migrate the database

bundle exec rake db:drop db:create db:migrate
bundle exec rake db:seed

5. Start the server

bundle exec rails server

go to http://localhost:3000/

6. Run the tests

bundle exec rspec spec/

Documents

Legacy database schema - schema for the legacy website.
Volunteer wireframes - wireframes that walk through all volunteer flows

Technologies

RSpec for testing
Factory Girl for creating test objects
Bootstrap and rails-bootstrap-forms for visual styling

Structure

Contexts are heavily used to provide a domain layer. These are from DCI. While there are contexts in this app, there aren't any roles. In the past I found the abstraction of roles to just make the code more confusing, and wasn't worth it. However, contexts provide a nice layer where code can be easily tested, reusable, and composed. Contexts are also a nice separation from the transport layer (HTTP, Rails Controllers) and the raw models (ActiveRecord models). The way contexts are used are somewhat similar to a service layer

Typically Rails apps will grow to either have fat models or fat controllers. Our app will have very skinny models and controllers, and a lot of the logic will go into different contexts instead. Our models will essentially just be responsible for storage (database interaction), and perhaps some additional properties (full_name as a method that joins a first_name and last_name property). Our controllers will only be responsible for calling into contexts.

The naming convention for contexts is to be a gerund. For example CreatingUser, Authenticating, DebitingBankAccount. Each context has a class method .execute! that is the entry point for calling into a context. For example: DebitingBankAccount.execute!(source, destination, 10.0).

The execute! method is purposely a class level method to enforce statelessness. State is the root of all evil, and having a class level method makes it really difficult for us to store state on our contexts.

Devops

vagrant up

# bind your local port 5432 to the vagrant box's port 5432
ssh -L 5432:localhost:5432 vagrant@localhost -p 2227 -i .vagrant/machines/default/virtualbox/private_key

# ssh into the vagrant box
vagrant ssh

# psql into the database
sudo -iu postgres psql

# list all databases
\l

# connect to the legacy database
\connect COA001

# list all tables
\dt

# connect to the development database
\connect coasst_development