# Development

Install instructions in [[INSTALL.md]]. Read it before proceeding.

## Basic commands for development

Load environment variables (**don't skip this step**):

    source script/env.sh .env .env.development .env.local .env.development.local

Start development:

    docker-compose up --build development

Build or rebuild:

    docker-compose build

Debug:

    docker attach ensl_development

To get inside docker web+test containers:

    docker-compose exec -u root development /bin/bash
    docker-compose exec -u web development /bin/bash
    docker-compose exec -u root test /bin/bash
    docker-compose exec -u web test /bin/bash

Restart the web container

    docker-compose restart web`

Run some tests:

    docker-compose up --build test
    docker-compose exec -u web test bundle exec rspec
    docker-compose exec -u web test bundle exec rspec spec/controllers/shoutmsgs_controller_spec.rb

## Debugging

Enable debug:
1. For tests, Make sure ``require 'pry-byebug'`` is uncommented at spec_helper.rb
1. Uncomment  add `byebug` anywhere
1. The development console, test command etc. will stop with pry debug options

## Unresolved issues for development

There are some unresolved issues to setup dev env.

1. Make sure docker has access to its dirs. You might have to chown if you have permission issues with docker.

    sudo chown -R 1000:1000 .
    sudo chown -R 999:999 db/data

1. You might have to run db migrations manually.

    bundle exec rake db:migrate`

## Unresolved issues in production

1. Be careful when running docker from multiple directories that you do not start eg. database twice

## Development tips

1. If you need to run stuff on your host (eg. ruby, rubocop, bundle install etc) run all commands from the: `Dockerfile`. It should setup identical setup for your machine.
1. Add docker container names to /etc/hosts. This makes it possible to run test from local machine without using the container since editor/IDE don't integrate with Docker so well.

    sudo echo `docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' ensl_dev_db` db >> /etc/hosts

1. VS Code and RubyMine are great IDE's/editors.
1. To run VS Code plugin Ruby Test Explorer in docker container you need to create path to custom path, copy the formatter and it whines about and it [still fails a bit](https://github.com/connorshea/vscode-ruby-test-adapter/issues/21).
1. You can run tests easier if you setup the stuff on your own computer.
1. Do not commit too much without testing. Also keep commits small for documentation and reversability issues.
1. You need to rebuild the docker image when you change gems.
1. To restart PUMA

    touch tmp/restart.txt

## Design of ENSL Application

Read this to understand design decisions and follow them!

1. Env variables should be used everywhere and loaded from .env* files using Dotenv
  * Load order is in [here]|(https://github.com/bkeepers/dotenv#what-other-env-files-can-i-use)
  * Local changes go to .env*local and **not** .env (unlike previous versions)
  * Passwords are in ENV variables for now so they don't have to duplicated between DB and Rails.
1. Everything should be running on containers.
  * Docker-compose is the heart of deployment
  * Dockerfile should contain the gems and prebuilt assets for production
  * The app is mounted as **volume**. It will override the Dockerfile content.
    * The app is only put inside the Dockerfile to precompile assets for production and staging. It could be removed to reduce space.
    * For production or staging could have the content in either image or as a volume. Doesn't really matter.
1. The public directory contains everything public. NGINX will try to find files there and ask from PUMA if it doesn't.
  * The local public directories (images, files, icons, avatars etc.) are to be addeed to .gitignore
  * Assets are compiled on-fly in development mode.
  * In production/staging etc. assets are precompiled and stored. Entry script can do this.
  * The public folder is a mix of auto-generated data (assets), static data (images) and user-generated data (avatars/files etc.).
  * No app folder in repo outside public is supposed to be shared by webserver.
1. Do not comment out tests that are taken out of use temporarily but use **skip**

## Tags in code

* ``FIXME`` bugs or bad coding that need to fixed one day
* ``TODO`` for things that are left undone
* ``EXPLAIN`` please explain what the following code does
* ``OBSOLETE`` remove this at some point
* ``DEBUG`` uncomment following lines to enable debug

## Assets and state data

1. Currently the following state data exists:
  * `log` has all Rails and Rails submodule log files
  * `db/data` has SQL database
  * `tmp` has temporary data like sockets, pids, cache etc. not in git repo index
  * `public` has all public data on website like images etc.
    * `public/local` has avatars etc. user uploaded content and is not in git repo index
    * `public/assets` is auto-generated by Rails on precompile and is not in git repo index
    * `public/files` is stored elsewhere and aliased by nginx, also not in git repo index

## TODO issues for dev

1. Puma should be running (eg. spring), and if debugger is used it should be able to connect via docker-compose up
1. Should directories exist?
1. docker-compose has some .env specific vars and then
1. The env variables are not always loaded causing mysterious issues.
1. How much in env vars?

## Best practices

Take a look at these before writing anything.

1. https://nvie.com/posts/a-successful-git-branching-model/
1. https://docs.docker.com/develop/develop-images/dockerfile_best-practices/
1. https://github.com/rubocop-hq/ruby-style-guide
1. https://rails-bestpractices.com/
1. http://www.betterspecs.org/
1. https://github.com/rubocop-hq/rspec-style-guide
1. Run rubocop