Jonathan Rosenbaum
2 years ago
1 changed files with 221 additions and 199 deletions
@ -1,199 +1,221 @@ |
|||||
# Bike!Bike! # |
# Bike!Bike! # |
||||
|
|
||||
| Environment | Build Status | |
| Environment | Build Status | |
||||
| ----------- |:------------:| |
| ----------- |:------------:| |
||||
| Development | [![Development Build Status](https://travis-ci.org/bikebike/BikeBike.svg?branch=development)](https://travis-ci.org/bikebike/BikeBike) | |
| Development | [![Development Build Status](https://travis-ci.org/bikebike/BikeBike.svg?branch=development)](https://travis-ci.org/bikebike/BikeBike) | |
||||
| Production | It works with this Fork! | |
| Production | It works with this Fork! | |
||||
|
|
||||
## About this Fork |
## About this Fork |
||||
|
|
||||
The Tech group for BikeBike!Everywhere! decided to utilize this conferencing/scheduling software for the next BikeBike. |
The Tech group for BikeBike!Everywhere! decided to utilize this conferencing/scheduling software for the next BikeBike. |
||||
|
|
||||
This repository creates a test environment so that we can test/fix issues before manually committing them to the live site. |
This repository creates a test environment so that we can test/fix issues before manually committing them to the live site. |
||||
|
|
||||
Instructions can be found in docker-compose.yml, and docker-compose.build. |
Instructions can be found in docker-compose.yml, and docker-compose.build. |
||||
|
|
||||
You may easily switch between the production and development environment. One good reason for doing this is that some system administration tasks are handled differently in production. For instance, mail is delayed in production. |
### After successful installation |
||||
|
|
||||
Realize you can always do things in the container .. the commands without docker-compose, or automate it all with a docker-compose script: |
There isn't much to do until the first conference is created, but you will need an adminstrator to make that happen. |
||||
|
|
||||
`docker-compose exec bikebike /bin/bash` |
First create a user for yourself at /user . If you properly setup SMTP via docker, you will receive a confirmation email, which allows you to setup a session on your respective browser. |
||||
|
|
||||
### From production to development after changing .env |
Then go to the database container (db), and utilizing psql update your user. |
||||
|
|
||||
``` |
`UPDATE users SET role = 'administrator' WHERE firstname = 'Jonathan Rosenbaum';` |
||||
docker-compose down |
|
||||
docker-compose up -d |
Now go to /conferences , create your first conference, and the fun begins! |
||||
rake assets:clobber |
|
||||
rake assets:precompile |
The commandline psql interacts with the database with 'strict' sql statements, so use single quotes around strings, not double quotes, and all should be good. |
||||
``` |
|
||||
### From development to production after changing .env |
Here's a good link to bring you up to speed with the power of psql: [https://phili.pe/posts/postgresql-on-the-command-line/](https://phili.pe/posts/postgresql-on-the-command-line/) |
||||
|
|
||||
``` |
### Production and Development mode |
||||
docker-compose down |
|
||||
docker-compose up -d |
You may easily switch between the production and development environment in the .env file. |
||||
rake assets:clobber |
|
||||
rake assets:precompile |
`RAILS_ENV=production` |
||||
rake db:sessions:clear |
|
||||
docker-compose restart bikebike |
One good reason for doing this is that some system administration tasks are handled differently in production. For instance, mail is delayed in production. |
||||
``` |
|
||||
### About that letsencrypt network in docker-compose.yml |
Realize you can always do things in the container .. the commands without docker-compose, or automate it all with a docker-compose script: |
||||
|
|
||||
I'll probably eventually come out with a github example of the docker-compose.yml file I utilize. This network provides a nginx proxy and an automatic generation of letsencrypt certificates. However, there are good directions at [ACME Companion](https://github.com/nginx-proxy/acme-companion) . |
`docker-compose exec bikebike /bin/bash` |
||||
|
|
||||
In the `bike_bike_advanced_environment` file I utilize these ENV variables: |
#### From production to development after changing .env |
||||
|
|
||||
``` |
``` |
||||
VIRTUAL_HOST |
docker-compose down |
||||
LETSENCRYPT_HOST |
docker-compose up -d |
||||
LETSENCRYPT_EMAIL |
rake assets:clobber |
||||
VIRTUAL_PORT |
rake assets:precompile |
||||
``` |
``` |
||||
|
#### From development to production after changing .env |
||||
## From bikebike/bikebike |
|
||||
|
``` |
||||
This is the repository for the Bike!Bike! website. It can be found in development at [preview.bikebike.org](https://preview-en.bikebike.org/) and in production at [bikebike.org](https://bikebike.org/) |
docker-compose down |
||||
|
docker-compose up -d |
||||
Feel free to clone or fork the repository any time to start working on new features or fixes. To get help create an issue or contact Godwin: `goodgodwin` `@` `hotmail.com` any time. |
rake assets:clobber |
||||
|
rake assets:precompile |
||||
![Screenshot of Bike!Bike!](https://workbench.bikecollectives.org/apps/bikebike/screenshots/application/home/3/desktop.png) |
rake db:sessions:clear |
||||
|
docker-compose restart bikebike |
||||
## Technologies ## |
``` |
||||
|
### About that letsencrypt network in docker-compose.yml |
||||
* [Ruby 2.3.0][1] |
|
||||
* [Rails 4.2.0][2] _([Project to upgrade to Rails 5](https://github.com/orgs/bikebike/projects/13))_ |
I'll probably eventually come out with a github example of the docker-compose.yml file I utilize. This network provides a nginx proxy and an automatic generation of letsencrypt certificates. However, there are good directions at [ACME Companion](https://github.com/nginx-proxy/acme-companion) . |
||||
* [PostgreSQL][3] |
|
||||
* [HAML][4] |
In the `bike_bike_advanced_environment` file I utilize these ENV variables: |
||||
* [SCSS][5] |
|
||||
* [NGinx][6] _([We may switch to Caddy](https://github.com/bikebike/bikecollectives_core/issues/1))_ |
``` |
||||
* [DigitalOcean][7] _([We may switch to Linode](https://github.com/bikebike/bikecollectives_core/issues/2))_ |
VIRTUAL_HOST |
||||
|
LETSENCRYPT_HOST |
||||
[1]: http://www.ruby-lang.org/en/ |
LETSENCRYPT_EMAIL |
||||
[2]: http://rubyonrails.org/ |
VIRTUAL_PORT |
||||
[3]: http://www.postgresql.org/ |
``` |
||||
[4]: http://haml.info/ |
|
||||
[5]: http://sass-lang.com/ |
## From bikebike/bikebike |
||||
[6]: https://www.nginx.com/ |
|
||||
[7]: https://digitalocean.com |
This is the repository for the Bike!Bike! website. It can be found in development at [preview.bikebike.org](https://preview-en.bikebike.org/) and in production at [bikebike.org](https://bikebike.org/) |
||||
|
|
||||
|
Feel free to clone or fork the repository any time to start working on new features or fixes. To get help create an issue or contact Godwin: `goodgodwin` `@` `hotmail.com` any time. |
||||
## Internal Gems ## |
|
||||
We will make a commitment to extract any functionality that makes sense to do so, into separate gems in order to share functionality with others, with our other projects (such as bikecollectives.org), and to enable easier collaboration amongst ourselves. |
![Screenshot of Bike!Bike!](https://workbench.bikecollectives.org/apps/bikebike/screenshots/application/home/3/desktop.png) |
||||
|
|
||||
It is recommended that you at least use also clone `bikecollectives_core` into you workspace. To override the gem location execute: |
## Technologies ## |
||||
|
|
||||
```bash |
* [Ruby 2.3.0][1] |
||||
bundle config local.bikecollectives_core PATH_TO/bikecollectives_core |
* [Rails 4.2.0][2] _([Project to upgrade to Rails 5](https://github.com/orgs/bikebike/projects/13))_ |
||||
``` |
* [PostgreSQL][3] |
||||
|
* [HAML][4] |
||||
Here is a list of the gems we have created so far, if you are a collaborator on this project you may need to become a collaborator on these gems as well. Don't hesitate to make a request, it won't be denied: |
* [SCSS][5] |
||||
|
* [NGinx][6] _([We may switch to Caddy](https://github.com/bikebike/bikecollectives_core/issues/1))_ |
||||
### Bike Collectives Core ### |
* [DigitalOcean][7] _([We may switch to Linode](https://github.com/bikebike/bikecollectives_core/issues/2))_ |
||||
|
|
||||
[Bike Collectives Core](https://github.com/bikebike/bikecollectives_core) is where models, migrations, and some common controllers and helpers live. This Gem is shared between [Bike Collectives](https://github.com/bikebike/bikecollectives) and [Bike Collectives Workbench](https://github.com/bikebike/bikecollectives_workbench). |
[1]: http://www.ruby-lang.org/en/ |
||||
|
[2]: http://rubyonrails.org/ |
||||
### Lingua Franca ### |
[3]: http://www.postgresql.org/ |
||||
|
[4]: http://haml.info/ |
||||
[Lingua Franca](https://github.com/lingua-franca/lingua_franca) provides an easy way to include translatable content and provides a user interface for translators to provide translations. See [Translations](#translations) for best practices on the Bike!Bike! website. |
[5]: http://sass-lang.com/ |
||||
|
[6]: https://www.nginx.com/ |
||||
### Bumbleberry ### |
[7]: https://digitalocean.com |
||||
[Bumbleberry](https://github.com/bumbleberry/bumbleberry) provides cross-browser support with little effort and minimum file sizes. Basically it creates a different stylesheet for every known browser and only includes supported rules for each using information obtained from [caniuse.com](caniuse.com). |
|
||||
|
|
||||
|
## Internal Gems ## |
||||
## Github Workflow ## |
We will make a commitment to extract any functionality that makes sense to do so, into separate gems in order to share functionality with others, with our other projects (such as bikecollectives.org), and to enable easier collaboration amongst ourselves. |
||||
If you are a git wiz, feel free to adjust the steps below slightly, otherwise follow these steps until you are familiar enough to stray. What should remain constant is that we need to branch, code review, and merge with master. |
|
||||
|
It is recommended that you at least use also clone `bikecollectives_core` into you workspace. To override the gem location execute: |
||||
1. Before you start working on a new feature, start working on a new branch (alternatively you can fork): `git checkout -b myname_new_feature` |
|
||||
1. Write your new feature |
```bash |
||||
1. Add tests and execute them using `bundle exec i18n` |
bundle config local.bikecollectives_core PATH_TO/bikecollectives_core |
||||
1. Make any adjustments, make sure you have included comments and abided other coding conventions |
``` |
||||
1. Check your git status to make sure you are on the correct branch and have any new files to add: `git status` |
|
||||
1. Add any new files using: `git add [myfile]` |
Here is a list of the gems we have created so far, if you are a collaborator on this project you may need to become a collaborator on these gems as well. Don't hesitate to make a request, it won't be denied: |
||||
1. Commit your changes: `git commit -am 'My commit message'` |
|
||||
1. Switch back to the development branch and pull the latest: `git checkout master && git pull` |
### Bike Collectives Core ### |
||||
1. Switch back to your branch: `git checkout myname_new_feature` |
|
||||
1. If there were any changes, rebase. This merges in the new code with your new code: `git rebase -i origin/development` |
[Bike Collectives Core](https://github.com/bikebike/bikecollectives_core) is where models, migrations, and some common controllers and helpers live. This Gem is shared between [Bike Collectives](https://github.com/bikebike/bikecollectives) and [Bike Collectives Workbench](https://github.com/bikebike/bikecollectives_workbench). |
||||
1. Push your changes: `git push origin myname_new_feature` |
|
||||
1. Make a pull request and wait for your code to be reviewed |
### Lingua Franca ### |
||||
1. If any changes are required, make them commit your changes, and rebase again. This time you need to make sure that you squash your commits (makes sure you only add one commit in the end). Where you see your commit message, change 'pick' to 'fixup' or 'f'. |
|
||||
1. Push your code again and repeat 12 and 13 until your code gets merged with development |
[Lingua Franca](https://github.com/lingua-franca/lingua_franca) provides an easy way to include translatable content and provides a user interface for translators to provide translations. See [Translations](#translations) for best practices on the Bike!Bike! website. |
||||
1. Once your code is in development it will be released to our development site, once new translations are added and the site is manually tested it will be moved to master and the production site |
|
||||
|
### Bumbleberry ### |
||||
## Deployment Process ## |
[Bumbleberry](https://github.com/bumbleberry/bumbleberry) provides cross-browser support with little effort and minimum file sizes. Basically it creates a different stylesheet for every known browser and only includes supported rules for each using information obtained from [caniuse.com](caniuse.com). |
||||
Please note, we currently don't have this process set up, we're working to get here. |
|
||||
|
|
||||
1. Write code and get it pulled into master |
## Github Workflow ## |
||||
2. Your changes will be automatically be deployed to our preview site |
If you are a git wiz, feel free to adjust the steps below slightly, otherwise follow these steps until you are familiar enough to stray. What should remain constant is that we need to branch, code review, and merge with master. |
||||
3. Your changes will be tested there, if tests fail deployers will be notified |
|
||||
4. Once that deployment process completes and tests pass, translators will be notified if there are new translations |
1. Before you start working on a new feature, start working on a new branch (alternatively you can fork): `git checkout -b myname_new_feature` |
||||
4. Once translators have completed translations, translations will be committed to master and your changes will be deployed to production |
1. Write your new feature |
||||
|
1. Add tests and execute them using `bundle exec i18n` |
||||
|
1. Make any adjustments, make sure you have included comments and abided other coding conventions |
||||
## Translations ## |
1. Check your git status to make sure you are on the correct branch and have any new files to add: `git status` |
||||
|
1. Add any new files using: `git add [myfile]` |
||||
Translating our site into multiple languages is a key part of opening it up to the world. When coding, never include any English text as in a string or Haml. Instead, we shall always use the underscore helper method `_`. The method takes a translation key and some optional parameters. |
1. Commit your changes: `git commit -am 'My commit message'` |
||||
|
1. Switch back to the development branch and pull the latest: `git checkout master && git pull` |
||||
All translation is done in a collaborative, volunteer based system on the site itself, even the English text. If a user has sufficient permissions, the underscore method will produce highlighted text which can be edited directly by the user. |
1. Switch back to your branch: `git checkout myname_new_feature` |
||||
|
1. If there were any changes, rebase. This merges in the new code with your new code: `git rebase -i origin/development` |
||||
The method can be used as follows: |
1. Push your changes: `git push origin myname_new_feature` |
||||
|
1. Make a pull request and wait for your code to be reviewed |
||||
```haml |
1. If any changes are required, make them commit your changes, and rebase again. This time you need to make sure that you squash your commits (makes sure you only add one commit in the end). Where you see your commit message, change 'pick' to 'fixup' or 'f'. |
||||
%h1=_'basename.my_title' |
1. Push your code again and repeat 12 and 13 until your code gets merged with development |
||||
%p=_'basename.my_key', :paragraph |
1. Once your code is in development it will be released to our development site, once new translations are added and the site is manually tested it will be moved to master and the production site |
||||
%button=_'basename.click_me' |
|
||||
``` |
## Deployment Process ## |
||||
|
Please note, we currently don't have this process set up, we're working to get here. |
||||
Assuming none of the keys map to translations, this will be rendered into the following HTML: |
|
||||
|
1. Write code and get it pulled into master |
||||
```html |
2. Your changes will be automatically be deployed to our preview site |
||||
<h1> |
3. Your changes will be tested there, if tests fail deployers will be notified |
||||
Lorem ipsum dolor sit amet |
4. Once that deployment process completes and tests pass, translators will be notified if there are new translations |
||||
</h1> |
4. Once translators have completed translations, translations will be committed to master and your changes will be deployed to production |
||||
|
|
||||
<p> |
|
||||
Curabitur non nulla sit amet nisl tempus convallis quis ac lectus. Vivamus magna justo, lacinia eget consectetur sed, convallis at tellus. Proin eget tortor risus. Donec sollicitudin molestie malesuada. Donec rutrum congue leo eget malesuada. |
## Translations ## |
||||
</p> |
|
||||
|
Translating our site into multiple languages is a key part of opening it up to the world. When coding, never include any English text as in a string or Haml. Instead, we shall always use the underscore helper method `_`. The method takes a translation key and some optional parameters. |
||||
<button> |
|
||||
click me |
All translation is done in a collaborative, volunteer based system on the site itself, even the English text. If a user has sufficient permissions, the underscore method will produce highlighted text which can be edited directly by the user. |
||||
</button> |
|
||||
``` |
The method can be used as follows: |
||||
|
|
||||
By default, the key will be translated using the last key part ('click me' in this example), however if a context is provided, some appropriate lorem ipsum text. Available contexts are: |
```haml |
||||
|
%h1=_'basename.my_title' |
||||
* `title` (alias: `t`): title text, a few words in upper case |
%p=_'basename.my_key', :paragraph |
||||
* `word` (alias: `words`, `w`): A word, if a second parameter is provided a numbr of words will be rendered (for example `_'key',:w,3`) |
%button=_'basename.click_me' |
||||
* `sentence` (alias: `sentences`, `s`): A sentence or multiple sentence |
``` |
||||
* `paragraph` (alias: `p`): A paragraph |
|
||||
|
Assuming none of the keys map to translations, this will be rendered into the following HTML: |
||||
If actual translations are not provided by the time the code hits production, fatals will occur. |
|
||||
|
```html |
||||
### Entering translations |
<h1> |
||||
|
Lorem ipsum dolor sit amet |
||||
Translations can be provided directly by editing [`en.yml`](https://github.com/bikebike/BikeBike/blob/master/config/locales/en.yml) but will also be directly using the [workbench](https://github.com/bikebike/bikecollectives_workbench): |
</h1> |
||||
|
|
||||
![Screenshot of the Bike Collectives Workbench](https://i.imgur.com/y8Ezjeg.png) |
<p> |
||||
|
Curabitur non nulla sit amet nisl tempus convallis quis ac lectus. Vivamus magna justo, lacinia eget consectetur sed, convallis at tellus. Proin eget tortor risus. Donec sollicitudin molestie malesuada. Donec rutrum congue leo eget malesuada. |
||||
### Collecting translations |
</p> |
||||
|
|
||||
Translations, along with screenshots and HTML page captures are collected during testing so that the workbench will have up to date translations and context for each to make it easier for translators to provide relevant translations. To collect these translations yourself, execute `rake i18n`. |
<button> |
||||
|
click me |
||||
## Testing Practices ## |
</button> |
||||
|
``` |
||||
Our focus will be on integration testing using Capybara. While testing the app records all translations that it finds, whether or not they exist, and which pages that they were found on. |
|
||||
|
By default, the key will be translated using the last key part ('click me' in this example), however if a context is provided, some appropriate lorem ipsum text. Available contexts are: |
||||
Before commiting you shuold always run: |
|
||||
|
* `title` (alias: `t`): title text, a few words in upper case |
||||
```bash |
* `word` (alias: `words`, `w`): A word, if a second parameter is provided a numbr of words will be rendered (for example `_'key',:w,3`) |
||||
bundle exec rake cucumber:run |
* `sentence` (alias: `sentences`, `s`): A sentence or multiple sentence |
||||
``` |
* `paragraph` (alias: `p`): A paragraph |
||||
|
|
||||
and: |
If actual translations are not provided by the time the code hits production, fatals will occur. |
||||
|
|
||||
```bash |
### Entering translations |
||||
bundle exec rake i18n |
|
||||
``` |
Translations can be provided directly by editing [`en.yml`](https://github.com/bikebike/BikeBike/blob/master/config/locales/en.yml) but will also be directly using the [workbench](https://github.com/bikebike/bikecollectives_workbench): |
||||
|
|
||||
The former is going to be faster but does not perform checks for untranslated content, it is recommneded that you run this regularily while developing while running the `i18n` check will ensure that you have not missed translations. |
![Screenshot of the Bike Collectives Workbench](https://i.imgur.com/y8Ezjeg.png) |
||||
|
|
||||
If you are creating any new content you will also want to add a new feature or scenario to ensure the new translations are picked up. |
### Collecting translations |
||||
|
|
||||
|
Translations, along with screenshots and HTML page captures are collected during testing so that the workbench will have up to date translations and context for each to make it easier for translators to provide relevant translations. To collect these translations yourself, execute `rake i18n`. |
||||
|
|
||||
|
## Testing Practices ## |
||||
|
|
||||
|
Our focus will be on integration testing using Capybara. While testing the app records all translations that it finds, whether or not they exist, and which pages that they were found on. |
||||
|
|
||||
|
Before commiting you shuold always run: |
||||
|
|
||||
|
```bash |
||||
|
bundle exec rake cucumber:run |
||||
|
``` |
||||
|
|
||||
|
and: |
||||
|
|
||||
|
```bash |
||||
|
bundle exec rake i18n |
||||
|
``` |
||||
|
|
||||
|
The former is going to be faster but does not perform checks for untranslated content, it is recommneded that you run this regularily while developing while running the `i18n` check will ensure that you have not missed translations. |
||||
|
|
||||
|
If you are creating any new content you will also want to add a new feature or scenario to ensure the new translations are picked up. |
||||
|
Loading…
Reference in new issue