Fix typos and mechanical mistakes (#4177) [ci skip]
This commit is contained in:
Jacob Herrington
Mac Siri
parent
dd391d5e34
commit
4ea1e6e020
33 changed files with 90 additions and 90 deletions
|
|
@ -4,13 +4,13 @@ title: Algolia
|
|||
|
||||
## Algolia for Search
|
||||
|
||||
Algolia is a third party service which powers the search. When working with the API it is very likely that you will need to utilize Algolia. You will need to sign up for a free-tier account, retrieve the keys and provide those keys to the Rails application.
|
||||
Algolia is a third party service that powers the search. When working with the API, you will likely need to utilize Algolia. You will need to sign up for a free-tier account, retrieve the keys, and provide those keys to the Rails application.
|
||||
|
||||
## Sign up
|
||||
|
||||
1. Go to the Algolia sign up [page](https://www.algolia.com/apps/AJVD3Q9KL3/dashboard).
|
||||
|
||||
2. Choose one of the three methods of signing up: email, github or google.
|
||||
2. Choose one of the three methods of signing up: email, GitHub, or Google.
|
||||
|
||||
3. Fill in your information.
|
||||
|
||||
|
|
|
|||
|
|
@ -8,11 +8,11 @@ DEV allows you to authenticate using GitHub. To use this authentication method i
|
|||
|
||||
1. [Click this link to create a new OAuth application in your Github account](https://github.com/settings/applications/new) - you will be redirected to sign in to Github account if you have not already.
|
||||
|
||||
2. Fill in the form with an application name, description and the URL `http://localhost:3000/`. Replace the port `3000` if you run DEV on another port.
|
||||
2. Fill in the form with an application name, description, and the URL `http://localhost:3000/`. Replace the port `3000` if you run DEV on another port.
|
||||
|
||||
|
||||
|
||||
3. You will be redirected in the app's **Developer settings**. Here you will find the keys. Change them accordingly (name of GitHub key -> name of our `ENV` variable):
|
||||
3. You will be redirected to the app's **Developer settings**. Here you will find the keys. Change them accordingly (name of GitHub key -> name of our `ENV` variable):
|
||||
|
||||
```text
|
||||
Client ID -> GITHUB_KEY
|
||||
|
|
@ -27,7 +27,7 @@ DEV allows you to authenticate using GitHub. To use this authentication method i
|
|||
|
||||
5. Fill in the token description and generate the token.
|
||||
|
||||
6. Be sure that you copy the token right away, because it is the only time you will see it. Change it accordingly.
|
||||
6. Be sure that you copy the token right away because it is the only time you will see it. Change it accordingly.
|
||||
|
||||
```shell
|
||||
Personal access tokens -> GITHUB_TOKEN
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ title: Twitter Authentication
|
|||
|
||||
# Twitter App and Authentication
|
||||
|
||||
DEV allows you to authenticate using Twitter. In order to use this authentication method in local development you will need to setup a Twitter App and retrieve its keys. Then you'll need to provide these keys to the Rails application.
|
||||
DEV allows you to authenticate using Twitter. In order to use this authentication method in local development, you will need to setup a Twitter App and retrieve its keys. Then you'll need to provide these keys to the Rails application.
|
||||
|
||||
## Sign up
|
||||
|
||||
|
|
@ -30,7 +30,7 @@ DEV allows you to authenticate using Twitter. In order to use this authenticatio
|
|||
|
||||
|
||||
|
||||
7. Verify your email address once more and you will be done.
|
||||
7. Verify your email address once more, and you will be done.
|
||||
|
||||
8. You are done.
|
||||
|
||||
|
|
@ -41,7 +41,7 @@ DEV allows you to authenticate using Twitter. In order to use this authenticatio
|
|||
2. From **Apps** dashboard, click on **Create and app**.
|
||||
|
||||
|
||||
3. Fill in the app name, description and URL `https://dev.to`.
|
||||
3. Fill in the app name, description, and URL `https://dev.to`.
|
||||
|
||||
|
||||
|
||||
|
|
@ -63,7 +63,7 @@ DEV allows you to authenticate using Twitter. In order to use this authenticatio
|
|||
|
||||
8. The app is all set!
|
||||
|
||||
9. One more change... From the app dashboard go to **Permissions** and check **Request email addresses from users** option.
|
||||
9. One more change: From the app dashboard, go to **Permissions** and check **Request email addresses from users** option.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ title: Authorization
|
|||
|
||||
# Authorization
|
||||
|
||||
Authorization is handled by the third party gem [Pundit](https://github.com/varvet/pundit) through the `authorize` method which you can find in various controllers, look for statements like:
|
||||
Authorization is handled by the third-party gem [Pundit](https://github.com/varvet/pundit) through the `authorize` method which you can find in various controllers, look for statements like:
|
||||
|
||||
```ruby
|
||||
authorize @user
|
||||
|
|
|
|||
|
|
@ -22,4 +22,4 @@ rxn = Reaction.create(
|
|||
Notification.send_reaction_notification_without_delay(rxn, me)
|
||||
```
|
||||
|
||||
Notice you have to run these methods `without_delay`, since this is assuming jobs are not running.
|
||||
Notice you have to run these methods `without_delay` since this is assuming jobs are not running.
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ title: Pusher
|
|||
|
||||
Pusher is a third party service being used to power the [chat system](https://dev.to/connect).
|
||||
|
||||
In order to use the chat functionality within you development environment
|
||||
In order to use the chat functionality within your development environment,
|
||||
you will need to sign up for a free-tier Pusher account and retrieve
|
||||
its keys. Then you'll need to provide those keys to the Rails application.
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ title: Roles
|
|||
|
||||
## What is a role?
|
||||
|
||||
If authorization is about who has permission to be allowed to do what you want to do. Then Roles are common patterns of authorization across users - reducing the administrative overhead.
|
||||
If authorization is about who has permission to be allowed to do what you want to do, then Roles are common patterns of authorization across users - reducing the administrative overhead.
|
||||
|
||||
## Why do I need to know about roles?
|
||||
|
||||
|
|
@ -16,7 +16,7 @@ Some bugs can only be seen for users with specific roles. You will need to chang
|
|||
|
||||
Roles are implemented in this application using [Rolify][1]. The list of roles can be found in [app/models/role.rb][2] and you can search for [has_role in the codebase][3] to find which pages need which roles.
|
||||
|
||||
A new user starts without a any roles and there is no administrative way of adding roles to users yet. To assign a user a role you will have to run commands at the console.
|
||||
A new user starts without any roles, and there is no administrative way of adding roles to users yet. To assign a user a role you will have to run commands at the console.
|
||||
|
||||
## Example of adding permissions to a user
|
||||
|
||||
|
|
@ -43,7 +43,7 @@ name: "pro"
|
|||
=> true
|
||||
```
|
||||
|
||||
Another common requirement is changing to the administrative role and an example of this is found [on the admin page][5].
|
||||
Another common requirement is changing to the administrative role, and an example of this is found [on the admin page][5].
|
||||
|
||||
## Verification
|
||||
|
||||
|
|
|
|||
|
|
@ -16,4 +16,4 @@ end
|
|||
|
||||
You can explore the [official Heroku documentation](https://devcenter.heroku.com/articles/scheduler#defining-tasks) for defining tasks and read through tasks we have implemented for busting cache, awarding badges, and more.
|
||||
|
||||
In your Pull Request, communicate with a DEV Core Team Member to discuss at what frequency and ensure your task is scheduled on Heroku once your code is reviewed, approved and merged.
|
||||
In your Pull Request, communicate with a DEV Core Team Member to discuss at what frequency and ensure your task is scheduled on Heroku once your code is reviewed, approved, and merged.
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ Install the [GitDocs NodeJs library](https://www.npmjs.com/package/gitdocs)
|
|||
npm install gitdocs -g
|
||||
```
|
||||
|
||||
Specifying `-g` will install the library globally which is what you want to do.
|
||||
Specifying `-g` will install the library globally, which is what you want to do.
|
||||
|
||||
If you use yarn you can instead issue:
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ The API docs follow the [OpenAPI 3 specification](http://spec.openapis.org/oas/v
|
|||
|
||||
## Where The Docs Are Located
|
||||
|
||||
We auto generate the documentation from `api_v0.yml` within the `/docs` directory.
|
||||
We auto-generate the documentation from `api_v0.yml` within the `/docs` directory.
|
||||
We use [ReDoc](https://github.com/Redocly/redoc) to turn the OpenAPI 3 format into a readable and searchable HTML documentation.
|
||||
|
||||
## Running and editing the Docs Locally
|
||||
|
|
@ -19,10 +19,10 @@ If you want to browse the documentation locally you can use:
|
|||
yarn api-docs:serve
|
||||
```
|
||||
|
||||
This will let you browse the auto generated version of the doc locally and it will reload the doc after every modification
|
||||
This will let you browse the auto-generated version of the doc locally, and it will reload the doc after every modification
|
||||
of the spec file.
|
||||
|
||||
If you have Visual Studio Code we suggest you install the following extensions that enable validation and navigation within
|
||||
If you have Visual Studio Code, we suggest you install the following extensions that enable validation and navigation within
|
||||
the spec file:
|
||||
|
||||
- [OpenAPI (Swagger) editor](https://marketplace.visualstudio.com/items?itemName=42Crunch.vscode-openapi)
|
||||
|
|
|
|||
|
|
@ -6,18 +6,18 @@ title: Branding Guidelines
|
|||
|
||||
## DEV Theme
|
||||
|
||||
DEV's design inspiration is meant to be a throwback. In personality and design it is ATARI inspired. Magazines like PAPER are also an inspiration in terms of being a [bold contrast with some more indy](https://www.google.com/search?biw=1440&bih=780&tbm=isch&sa=1&ei=KSN8W5WVLoy55gLI77TgBA&q=paper+magazine+cover&oq=paper+magazine+cover).
|
||||
DEV's design inspiration is meant to be a throwback. In personality and design, it is ATARI inspired. Magazines like PAPER are also an inspiration in terms of being a [bold contrast with some more indy](https://www.google.com/search?biw=1440&bih=780&tbm=isch&sa=1&ei=KSN8W5WVLoy55gLI77TgBA&q=paper+magazine+cover&oq=paper+magazine+cover).
|
||||
|
||||
We also think in terms of how people use the DEV brand for their own purposes. Profiles are very much public-facing records of what people have put out into the world. `dev.to/{username}` is your dev identity.
|
||||
|
||||
Imagine a developer's face with the DEV heading above them. If we existed in the 80's we would have been "DEV MAGAZINE", with the exact same branding.
|
||||
Imagine a developer's face with the DEV heading above them. If we existed in the 80's, we would have been "DEV MAGAZINE," with the exact same branding.
|
||||
|
||||
## Branding Rules
|
||||
|
||||
- [Joystick](http://www.pixelsagas.com/?download=joystick) should be used for logos, not for headlines/phrases
|
||||
- Black and white is our default logo but the logo can be drawn in any color
|
||||
- DEV is "old school cool"
|
||||
- We use bold shadows (no gradient) for boxes
|
||||
- [Joystick](http://www.pixelsagas.com/?download=joystick) should be used for logos, not for headlines/phrases.
|
||||
- Black and white is our default logo, but the logo can be drawn in any color.
|
||||
- DEV is "old school cool."
|
||||
- We use bold shadows (no gradient) for boxes.
|
||||
- We have a minimal approach to importing dependencies, so few if any custom fonts on-site for that reason.
|
||||
- Refer to the `variables.css` [file in our main repo](https://github.com/thepracticaldev/dev.to/blob/master/app/assets/stylesheets/variables.scss) to reference commonly-used colors and fonts.
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ title: Theming Guidelines
|
|||
|
||||
# Theming Guidelines
|
||||
|
||||
DEV supports different themes such as Default, Night, Pink.
|
||||
DEV supports different themes, such as Default, Night, Pink.
|
||||
|
||||
You can switch the theme at <http://localhost:3000/settings/misc> in the "Style Customization" section.
|
||||
|
||||
|
|
@ -62,7 +62,7 @@ div {
|
|||
}
|
||||
```
|
||||
|
||||
This can be too much work and browser fallback can be forgotten. For a better developer experience, you should use the 2 mixins defined in `app/assets/stylesheets/_mixins.scss` called `themeable` and `themeable-important`. They take 3 arguments. The first argument is the CSS property like `color` or `background`, the second argument is the CSS custom property name (without `--`) like `theme-color` and the third argument is the CSS value like `$black` or `white`.
|
||||
This can be too much work and browser fallback can be forgotten. For a better developer experience, you should use the two mixins defined in `app/assets/stylesheets/_mixins.scss` called `themeable` and `themeable-important`. They take three arguments. The first argument is the CSS property like `color` or `background`, the second argument is the CSS custom property name (without `--`) like `theme-color`, and the third argument is the CSS value, i.e., `$black` or `white`.
|
||||
|
||||
Make sure to import the mixin in your SCSS file and use it like this:
|
||||
|
||||
|
|
@ -76,4 +76,4 @@ div {
|
|||
}
|
||||
```
|
||||
|
||||
`themeable-important` is used when a CSS variable requires `!important` as a postfix of the CSS property's value where the CSS variable is being used. You can use it the same way you would use `themeable` mixin but you should avoid `!important` if possible.
|
||||
`themeable-important` is used when a CSS variable requires `!important` as a postfix of the CSS property's value where the CSS variable is being used. You can use it the same way you would use `themeable` mixin, but you should avoid `!important` if possible.
|
||||
|
|
|
|||
|
|
@ -24,5 +24,5 @@ sudo -u postgres createuser -s ec2-user
|
|||
sudo -u postgres createdb ec2-user
|
||||
```
|
||||
|
||||
The first command creates the user **ec2-user** and the second one creates the database for this user, because every user needs its database.
|
||||
The first command creates the user **ec2-user** and the second one creates the database for this user because every user needs its database.
|
||||
Even if the first command fails, run the second command to create the missing database.
|
||||
|
|
|
|||
|
|
@ -10,9 +10,9 @@ They are custom embeds that are added via a `{% %}` syntax. [Liquid](https://sho
|
|||
|
||||
Liquid embeds are for tweets, like `{% tweet 765282762081329153 %}` or a DEV user profile preview, like `{% user jess %}` etc.
|
||||
|
||||
They make for good community contributions because they can be extended and improved on consistently. It is truly how we extend the functionality of the editor. At the moment, there could be a lot of work refactoring and improving existing liquid tags, in addition to adding new ones.
|
||||
They make for good community contributions because they can be extended and improved consistently. It is truly how we extend the functionality of the editor. At the moment, there could be a lot of work refactoring and improving existing liquid tags, in addition to adding new ones.
|
||||
|
||||
Liquid tags are sort of like functions, which have a name and take arguments. Develop them with that mindset in terms of naming things. They should be documented but also intuitive. They should also be fairly flexible in the arguments they take. Currently this could use improvements.
|
||||
Liquid tags are sort of like functions, which have a name and take arguments. Develop them with that mindset in terms of naming things. They should be documented but also intuitive. They should also be fairly flexible in the arguments they take. Currently, this could use improvements.
|
||||
|
||||
Liquid tags are "compiled" when an article is saved. So you will need to re-save articles to see HTML changes.
|
||||
|
||||
|
|
|
|||
|
|
@ -9,9 +9,9 @@ DEV has two Javascript codebases.
|
|||
One is located in the directory
|
||||
`app/assets/javascripts` and contains plain Javascript (mostly ES5+) being served using [Sprockets](https://github.com/rails/sprockets-rails) which packages static assets.
|
||||
|
||||
The other one is managed by Webpacker and you can read more about [in its own guide](/frontend/webpacker).
|
||||
Webpacker manages the other one, and you can read more about [in its own guide](/frontend/webpacker).
|
||||
|
||||
This source code is not transpiled, only packaged and minified, and will be limited to whatever flavour of Javascript can run on user's web browser.
|
||||
This source code is not transpiled, only packaged and minified, and will be limited to whatever flavour of Javascript can run on the user's web browser.
|
||||
|
||||
`app/assets/javascripts/application.js` contains the manifest Javascript file
|
||||
which is included globally in the primary template, `app/views/layouts/application.html.erb`.
|
||||
|
|
|
|||
|
|
@ -6,11 +6,11 @@ title: Webpacker
|
|||
|
||||
DEV has two Javascript codebases.
|
||||
|
||||
One contains plain Javascript and you can read about [in its own guide](/frontend/plain-js).
|
||||
One contains plain Javascript, you can read about it [in its own guide](/frontend/plain-js).
|
||||
|
||||
The other one is managed by [Webpacker](https://github.com/rails/webpacker) and it's located inside `/app/javascripts`, written using ES6+.
|
||||
The other one is managed by [Webpacker](https://github.com/rails/webpacker), and it's located inside `/app/javascripts`, written using ES6+.
|
||||
|
||||
Currently it's mainly used for Preact components, served via `webpack` which is integrated into the Rails app using `Webpacker`.
|
||||
Currently, it's mainly used for Preact components, served via `webpack` which is integrated into the Rails app using `Webpacker`.
|
||||
|
||||
There is a packs directory `/app/javascript/packs` where you can create
|
||||
new "pack" files. Pack files are initializers for Webpacker.
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: Architecture and Concepts
|
||||
---
|
||||
|
||||
# A few high level things to know
|
||||
# A few high-level things to know
|
||||
|
||||
## We are a Ruby on Rails app
|
||||
|
||||
|
|
@ -18,13 +18,13 @@ before_action :set_cache_control_headers
|
|||
|
||||
We also user server-side caching [Rails caching](https://guides.rubyonrails.org/caching_with_rails.html). Any time you see `Rails.cache` or `<%= cache ... %>`, this is code affected in production by caching.
|
||||
|
||||
## We use inline CSS and defered scripts for usage performance improvements
|
||||
## We use inline CSS and deferred scripts for usage performance improvements
|
||||
|
||||
To avoid blocking initial render, we put critical path CSS inline in the HTML and we user `defer` so the user is not waiting on extra assets. This means we have some constraints about how we can use JavaScript to affect the layout. In many cases we should not attempt to do this.
|
||||
To avoid blocking initial render, we put critical path CSS inline in the HTML and we user `defer` so the user is not waiting on extra assets. This means we have some constraints about how we can use JavaScript to affect the layout. In many cases, we should not attempt to do this.
|
||||
|
||||
## We attempt to reduce our bundle size
|
||||
|
||||
We use [PreactJs](https://preactjs.com/), a lightweight alternative to ReactJs, and generally we try to reduce our bundle size with approaches such as [dynamic imports](https://dev.to/goenning/how-we-reduced-our-initial-jscss-size-by-67-3ac0).
|
||||
We use [PreactJs](https://preactjs.com/), a lightweight alternative to ReactJs, and generally, we try to reduce our bundle size with approaches such as [dynamic imports](https://dev.to/goenning/how-we-reduced-our-initial-jscss-size-by-67-3ac0).
|
||||
|
||||
## Worst technical debt
|
||||
|
||||
|
|
@ -36,4 +36,4 @@ We also have a sprawling CSS structure with few consistent rules.
|
|||
|
||||
The home feed is based on a combination of collective recent posts that are cached and delivered the same to everyone in the HTML, and additional articles fetched from an Algolia index after page load. To determine which posts a user sees, they are ranked based on the user's followed tags, followed users, and relative weights for each tag. Additional fetched articles also follow this general pattern.
|
||||
|
||||
Currently the top post on the home feed, which must have a cover image, is shared among all users.
|
||||
Currently, the top post on the home feed, which must have a cover image, is shared among all users.
|
||||
|
|
@ -4,13 +4,13 @@ title: Creating a Feature Branch
|
|||
|
||||
# Creating a Feature / Bug Branch
|
||||
|
||||
When you are working on a bug, feature or improvement, you will need to create a branch. For features or improvement you will create a branch as follows:
|
||||
When you are working on a bug, feature, or improvement, you will need to create a branch. For features or improvement, you will create a branch as follows:
|
||||
|
||||
```
|
||||
git checkout -b feature/that-new-feature`
|
||||
```
|
||||
|
||||
For a bug branch you will do as follows:
|
||||
For a bug branch, you will do as follows:
|
||||
|
||||
```
|
||||
bug/fixing-that-bug
|
||||
|
|
|
|||
|
|
@ -10,8 +10,8 @@ The [backend guide](/backend) will show you how to get free API keys for additio
|
|||
|
||||
For any key that you wish to enter/replace:
|
||||
|
||||
1. Create `config/application.yml` by copying from the provided template (ie. with bash: `cp config/sample_application.yml config/application.yml`). This is a personal file that is ignored in git.
|
||||
1. Obtain the development variable and apply the key you wish to enter/replace. ie:
|
||||
1. Create `config/application.yml` by copying from the provided template (i.e. with bash: `cp config/sample_application.yml config/application.yml`). This is a personal file that is ignored in git.
|
||||
1. Obtain the development variable and apply the key you wish to enter/replace. i.e.:
|
||||
|
||||
```shell
|
||||
GITHUB_KEY: "SOME_REAL_SECURE_KEY_HERE"
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ title: Preparing a Pull Request
|
|||
# Preparing a pull request
|
||||
|
||||
- Try to keep the pull requests small. A pull request should try its very best to address only a single concern.
|
||||
- Make sure all tests pass and add additional tests for the code you submit. Checkout the [testing guide](/tests).
|
||||
- Make sure all tests pass and add additional tests for the code you submit. Check out the [testing guide](/tests).
|
||||
- Document your reasoning behind the changes. Explain why you wrote the code in the way you did. The code should be clear enough to explain what it does.
|
||||
- If there's an existing issue related to the pull request, reference to it by adding something like `References/Closes/Fixes/Resolves #305`, where 305 is the issue number. See [GitHub's own guide on closing issues via PR](https://github.com/blog/1506-closing-issues-via-pull-requests).
|
||||
- If you follow the pull request template, you can't go wrong.
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ title: Keeping Your Fork In Sync
|
|||
|
||||
Now that you have a fork of DEV's source code, there is work you will need to do to keep it updated.
|
||||
|
||||
## Setup Your upstream
|
||||
## Setup your upstream
|
||||
|
||||
Inside your DEV directory, add a remote to the official DEV repo:
|
||||
|
||||
|
|
@ -16,7 +16,7 @@ git remote add upstream https://github.com/thepracticaldev/dev.to.git
|
|||
|
||||
## Rebasing from upstream
|
||||
|
||||
Do this prior to every time you create a branch for a PR:
|
||||
Do this prior to creating each branch for a PR:
|
||||
|
||||
Make sure you are on the master branch:
|
||||
|
||||
|
|
@ -26,13 +26,13 @@ On branch master
|
|||
Your branch is up-to-date with 'origin/master'.
|
||||
```
|
||||
|
||||
If your aren't on `master`, finish your work and checkout the `master` branch:
|
||||
If you aren't on `master`, finish your work and checkout the `master` branch:
|
||||
|
||||
```shell
|
||||
git checkout master
|
||||
```
|
||||
|
||||
Do a pull with rebase against `upstream`
|
||||
Do a pull with rebase against `upstream`:
|
||||
|
||||
```shell
|
||||
git pull --rebase upstream master
|
||||
|
|
|
|||
|
|
@ -4,10 +4,10 @@ title: Suggested Workflow
|
|||
|
||||
# Suggested Workflow
|
||||
|
||||
We use [Spring](https://github.com/rails/spring) and it is already included in the project.
|
||||
We use [Spring](https://github.com/rails/spring), and it is already included in the project.
|
||||
|
||||
1. Use the provided bin stubs to automatically start Spring, i.e. `bin/rails server`, `bin/rspec spec/models/`, `bin/rails db:migrate`.
|
||||
1. If Spring isn't picking up on new changes, use `spring stop`. For example, Spring should always be restarted if there's a change in environment key.
|
||||
1. If Spring isn't picking up on new changes, use `spring stop`. For example, Spring should always be restarted if there's a change in the environment keys.
|
||||
1. Check Spring's status whenever with `spring status`.
|
||||
|
||||
Caveat: `bin/rspec` is not equipped with Spring because it affects Simplecov's result. Instead use `bin/spring rspec`.
|
||||
Caveat: `bin/rspec` is not equipped with Spring because it affects Simplecov's result. Instead, use `bin/spring rspec`.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Installing DEV with Docker [Beta]
|
||||
|
||||
Our docker implementation is incomplete and may not work smoothly. Please kindly [report any issues](https://github.com/thepracticaldev/dev.to/issues/new/choose)!
|
||||
Our docker implementation is incomplete and may not work smoothly. Please, kindly [report any issues](https://github.com/thepracticaldev/dev.to/issues/new/choose)!
|
||||
|
||||
## Installing prerequisites
|
||||
|
||||
|
|
@ -8,13 +8,13 @@ _These prerequisites assume you're working on an operating system supported by D
|
|||
|
||||
### Docker and Docker Compose
|
||||
|
||||
Docker is available for many different operating systems. We recommend you follow the [Docker CE install guide](https://docs.docker.com/install/) which illustrates multiple installation options for each OS.
|
||||
Docker is available for many different operating systems. We recommend you follow the [Docker CE install guide](https://docs.docker.com/install/), which illustrates multiple installation options for each OS.
|
||||
|
||||
You're also going to need Docker Compose, to start multiple containers. We recommend you follow the [Docker Compose install guide](https://docs.docker.com/compose/install/) as well.
|
||||
|
||||
## Installing DEV
|
||||
|
||||
1. Fork DEV's repository, eg. <https://github.com/thepracticaldev/dev.to/fork>
|
||||
1. Fork DEV's repository, e.g. <https://github.com/thepracticaldev/dev.to/fork>
|
||||
1. Clone your forked repository, eg. `git clone https://github.com/<your-username>/dev.to.git`
|
||||
1. Set up your environment variables/secrets
|
||||
|
||||
|
|
@ -22,8 +22,8 @@ You're also going to need Docker Compose, to start multiple containers. We recom
|
|||
- The [backend guide](/backend) will show you how to get free API keys for additional services that may be required to run certain parts of the app.
|
||||
- For any key that you wish to enter/replace:
|
||||
|
||||
1. Create `config/application.yml` by copying from the provided template (ie. with bash: `cp config/sample_application.yml config/application.yml`). This is a personal file that is ignored in git.
|
||||
1. Obtain the development variable and apply the key you wish to enter/replace. ie:
|
||||
1. Create `config/application.yml` by copying from the provided template (i.e. with bash: `cp config/sample_application.yml config/application.yml`). This is a personal file that is ignored in git.
|
||||
1. Obtain the development variable and apply the key you wish to enter/replace. i.e.:
|
||||
|
||||
```shell
|
||||
GITHUB_KEY: "SOME_REAL_SECURE_KEY_HERE"
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
## Installing prerequisites
|
||||
|
||||
_These prerequisites assume you're working on a Linux-based operating system but they have only been tested on Ubuntu 18.04._
|
||||
_These prerequisites assume you're working on a Linux-based operating system, but they have only been tested on Ubuntu 18.04._
|
||||
|
||||
### Ruby
|
||||
|
||||
|
|
@ -16,7 +16,7 @@ For very detailed rbenv installation directions on several distros, please visit
|
|||
There are two ways to install Yarn.
|
||||
|
||||
- Yarn's official [installation guide](https://yarnpkg.com/en/docs/install#debian-stable) (recommended).
|
||||
- [DigitalOcean's detailed tutorial](https://www.digitalocean.com/community/tutorials/how-to-install-node-js-on-ubuntu-18-04) describes how to install [Node version Manager](https://github.com/creationix/nvm). By installing NVM you can select a Node version (we recommend either LTS or current), the guide will also explain how to install NPM. This way you'll have Node, NPM, and then you can run `npm install -g yarn` to install Yarn.
|
||||
- [DigitalOcean's detailed tutorial](https://www.digitalocean.com/community/tutorials/how-to-install-node-js-on-ubuntu-18-04) describes how to install [Node version Manager](https://github.com/creationix/nvm). By installing NVM you can select a Node version (we recommend either LTS or current); the guide will also explain how to install NPM. This way you'll have Node, NPM, and then you can run `npm install -g yarn` to install Yarn.
|
||||
|
||||
### PostgreSQL
|
||||
|
||||
|
|
@ -27,8 +27,8 @@ There are more than one ways to setup PostgreSQL. For additional configuration,
|
|||
|
||||
## Installing DEV
|
||||
|
||||
1. Fork DEV's repository, eg. <https://github.com/thepracticaldev/dev.to/fork>
|
||||
1. Clone your forked repository, eg. `git clone https://github.com/<your-username>/dev.to.git`
|
||||
1. Fork DEV's repository, e.g. <https://github.com/thepracticaldev/dev.to/fork>
|
||||
1. Clone your forked repository, e.g. `git clone https://github.com/<your-username>/dev.to.git`
|
||||
1. Install bundler with `gem install bundler`
|
||||
1. Set up your environment variables/secrets
|
||||
|
||||
|
|
@ -36,8 +36,8 @@ There are more than one ways to setup PostgreSQL. For additional configuration,
|
|||
- The [backend guide](/backend) will show you how to get free API keys for additional services that may be required to run certain parts of the app.
|
||||
- For any key that you wish to enter/replace:
|
||||
|
||||
1. Create `config/application.yml` by copying from the provided template (ie. with bash: `cp config/sample_application.yml config/application.yml`). This is a personal file that is ignored in git.
|
||||
1. Obtain the development variable and apply the key you wish to enter/replace. ie:
|
||||
1. Create `config/application.yml` by copying from the provided template (i.e. with bash: `cp config/sample_application.yml config/application.yml`). This is a personal file that is ignored in git.
|
||||
1. Obtain the development variable and apply the key you wish to enter/replace. i.e.:
|
||||
|
||||
```shell
|
||||
GITHUB_KEY: "SOME_REAL_SECURE_KEY_HERE"
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ title: macOS
|
|||
### Ruby
|
||||
|
||||
1. If you don't already have a Ruby version manager, we highly recommend [rbenv](https://github.com/rbenv/rbenv). Please follow their [installation guide](https://github.com/rbenv/rbenv#installation).
|
||||
2. With the Ruby version manager, install the Ruby version listed on our badge. (ie with rbenv: `rbenv install 2.6.3`)
|
||||
2. With the Ruby version manager, install the Ruby version listed on our badge. (i.e. with rbenv: `rbenv install 2.6.3`)
|
||||
|
||||
### Yarn
|
||||
|
||||
|
|
@ -23,8 +23,8 @@ For additional configuration options, check our [PostgreSQL setup guide](/instal
|
|||
|
||||
## Installing DEV
|
||||
|
||||
1. Fork DEV's repository, eg. <https://github.com/thepracticaldev/dev.to/fork>
|
||||
1. Clone your forked repository, eg. `git clone https://github.com/<your-username>/dev.to.git`
|
||||
1. Fork DEV's repository, e.g. <https://github.com/thepracticaldev/dev.to/fork>
|
||||
1. Clone your forked repository, e.g. `git clone https://github.com/<your-username>/dev.to.git`
|
||||
1. Install bundler with `gem install bundler`
|
||||
1. Set up your environment variables/secrets
|
||||
|
||||
|
|
@ -32,8 +32,8 @@ For additional configuration options, check our [PostgreSQL setup guide](/instal
|
|||
- The [backend guide](/backend) will show you how to get free API keys for additional services that may be required to run certain parts of the app.
|
||||
- For any key that you wish to enter/replace:
|
||||
|
||||
1. Create `config/application.yml` by copying from the provided template (ie. with bash: `cp config/sample_application.yml config/application.yml`). This is a personal file that is ignored in git.
|
||||
1. Obtain the development variable and apply the key you wish to enter/replace. ie:
|
||||
1. Create `config/application.yml` by copying from the provided template (i.e. with bash: `cp config/sample_application.yml config/application.yml`). This is a personal file that is ignored in git.
|
||||
1. Obtain the development variable and apply the key you wish to enter/replace. i.e.:
|
||||
|
||||
```shell
|
||||
GITHUB_KEY: "SOME_REAL_SECURE_KEY_HERE"
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ _You can find all installation options for a variety of operating systems [on th
|
|||
|
||||
## Configuration
|
||||
|
||||
By default the application is configured to connect to a local database named `PracticalDeveloper_development`. If you need to specify a username and a password you can go about it by using the environment variable `DATABASE_URL` with a connection string.
|
||||
By default, the application is configured to connect to a local database named `PracticalDeveloper_development`. If you need to specify a username and a password, you can go about it by using the environment variable `DATABASE_URL` with a connection string.
|
||||
|
||||
The [official Rails guides](https://guides.rubyonrails.org/configuring.html#connection-preference) go into depth on how Rails merges the existing `database.yml` with the connection string.
|
||||
|
||||
|
|
|
|||
|
|
@ -16,4 +16,4 @@ items:
|
|||
|
||||
# Welcome to DEV's developer documentation
|
||||
|
||||
Here you can find instructions on how to setup your own local copy of DEV, how to navigate the code, how to contribute and how to troubleshoot issues among other things.
|
||||
Here you can find instructions on how to setup your own local copy of DEV, how to navigate the code, how to contribute, and how to troubleshoot issues, among other things.
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ title: Self hosting DEV
|
|||
|
||||
We envision that the DEV codebase will eventually be generalized to the point where it can be used to power other communities and ecosystems. We're excited for the project to mature to that point, but we're not quite there yet.
|
||||
|
||||
This page is designed to serve as a FAQ and a checklist of considerations that are relevant to the goal of eventually hosting your own version of our community platform.
|
||||
This page is designed to serve as an FAQ and a checklist of considerations that are relevant to the goal of eventually hosting your own version of our community platform.
|
||||
|
||||
### Current Limitations
|
||||
|
||||
|
|
@ -22,4 +22,4 @@ This page is designed to serve as a FAQ and a checklist of considerations that a
|
|||
- You can help us generalize the code, removing DEV-specific language and images and replacing them with environment variables or database tables as appropriate
|
||||
- You can commit to staying in very close coordination with us as we navigate the process together.
|
||||
|
||||
The long-term benefits of doing this the right way far outweighs the short-term gains of spinning something up without consulting us. If you are interested in getting started with this process, let us know in [this thread](https://dev.to/ben/so-you-want-to-stand-up-your-own-instance-of-dev-help-thread-1elo).
|
||||
The long-term benefits of doing this the right way far outweigh the short-term gains of spinning something up without consulting us. If you are interested in getting started with this process, let us know in [this thread](https://dev.to/ben/so-you-want-to-stand-up-your-own-instance-of-dev-help-thread-1elo).
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ title: Acceptance Tests
|
|||
|
||||
# Acceptance Tests
|
||||
|
||||
Acceptance tests are tests from the perspective of the end user.
|
||||
Acceptance tests are tests from the perspective of the end-user.
|
||||
|
||||
It means that we are simulating what a user could do from their web browser
|
||||
and testing the expected behavior of the app.
|
||||
|
|
@ -29,6 +29,6 @@ To run a specific test case you can use for example:
|
|||
bundle exec rspec spec/system/user_views_a_reading_list_spec.rb:10
|
||||
```
|
||||
|
||||
where `10` is the line number of the test case you want to execute.
|
||||
where `10` is the line number of the test case that you want to execute.
|
||||
|
||||
You can read the official guide [Testing Rails Applications](https://guides.rubyonrails.org/testing.html#system-testing) to learn more.
|
||||
|
|
|
|||
|
|
@ -6,9 +6,9 @@ title: Code Coverage
|
|||
|
||||
## Rails
|
||||
|
||||
Rails tests will generate the code coverage at the end of the tests execution.
|
||||
Rails tests will generate code coverage at the end of the tests.
|
||||
|
||||
To get the code coverage of the whole Rails code base you need to run all the tests with:
|
||||
To get the code coverage of the whole Rails codebase, you need to run all the tests with:
|
||||
|
||||
```shell
|
||||
bundle exec rspec
|
||||
|
|
@ -20,7 +20,7 @@ or
|
|||
bin/rspec
|
||||
```
|
||||
|
||||
To get the code coverage of a single file you can run
|
||||
To get the code coverage of a single file, you can run:
|
||||
|
||||
```shell
|
||||
bundle exec rspec spec/models/user_spec.rb
|
||||
|
|
@ -32,13 +32,13 @@ or
|
|||
bin/rspec spec/models/user_spec.rb
|
||||
```
|
||||
|
||||
After the test run is complete, open `coverage/index.html` with a browser so you can check the the code coverage.
|
||||
After the test run is complete, open `coverage/index.html` with a browser so you can check the code coverage.
|
||||
|
||||
## Preact
|
||||
|
||||
Preact tests will generate the code coverage at the end of the tests execution.
|
||||
Preact tests will generate code coverage at the end of the tests.
|
||||
|
||||
To get the code coverage of the Preact code base you need to run all the tests with:
|
||||
To get the code coverage of the Preact codebase, you need to run all the tests with:
|
||||
|
||||
```shell
|
||||
npm run test
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ title: Integration Tests
|
|||
|
||||
An integration test is when you need to test the interaction of multiple systems or parts of your application.
|
||||
|
||||
An integration test may seem similar to an [acceptance test](/tests/acceptance-tests). The main difference is that an acceptance test is from the perspective of the end user while an integration test is from the perspective of the developer.
|
||||
An integration test may seem similar to an [acceptance test](/tests/acceptance-tests). The main difference is that an acceptance test is from the perspective of the end-user, while an integration test is from the perspective of the developer.
|
||||
|
||||
Integration tests can be found in the directory `spec/requests`.
|
||||
|
||||
|
|
@ -16,7 +16,7 @@ You can run all integration tests with:
|
|||
bundle exec rspec spec/requests
|
||||
```
|
||||
|
||||
To run an individual file you can use for example:
|
||||
To run an individual file you can use, for example:
|
||||
|
||||
```shell
|
||||
bundle exec rspec spec/requests/stories_show_spec.rb
|
||||
|
|
@ -28,4 +28,4 @@ To run a specific test case you can use for example:
|
|||
bundle exec rspec spec/requests/stories_show_spec.rb:10
|
||||
```
|
||||
|
||||
where `10` is the line number of the test case you want to execute.
|
||||
where `10` is the line number of the test case that you want to execute.
|
||||
|
|
|
|||
|
|
@ -28,4 +28,4 @@ or
|
|||
yarn test
|
||||
```
|
||||
|
||||
At the end of the tests execution you will see the code coverage for the Preact components tests.
|
||||
At the end of the tests execution, you will see the code coverage for the Preact components tests.
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ A unit test is about testing a single function/method in isolation with all of i
|
|||
|
||||
A functional test is about testing a single functionality, which can span multiple methods and a controller.
|
||||
|
||||
Other common terms in Rails are "model tests", "controller tests" and others.
|
||||
Other common terms in Rails are "model tests," "controller tests," and others.
|
||||
|
||||
You can find model tests in `spec/models`, controller tests in `spec/controllers` and additional functional tests in various directories within the `spec` directory.
|
||||
|
||||
|
|
@ -18,18 +18,18 @@ You can run all models tests, for example, with:
|
|||
bundle exec rspec spec/models
|
||||
```
|
||||
|
||||
To run an individual file you can use for example:
|
||||
To run an individual file you can use, for example:
|
||||
|
||||
```shell
|
||||
bundle exec rspec spec/models/user_spec.rb
|
||||
```
|
||||
|
||||
To run a specific test case you can use for example:
|
||||
To run a specific test case you can use, for example:
|
||||
|
||||
```shell
|
||||
bundle exec rspec spec/models/user_spec.rb:10
|
||||
```
|
||||
|
||||
where `10` is the line number of the test case you want to execute.
|
||||
where `10` is the line number of the test case that you want to execute.
|
||||
|
||||
You can read the official guide [Testing Rails Applications](https://guides.rubyonrails.org/testing.html) to learn more.
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue