Rename file upload chapter

Author: melcha

Development practices/File upload.md renamed to Development practices/File uploads.md

@@ -1,11 +1,11 @@
 Our standard file upload setup includes:
-- using the Shrine gem
+- using Shrine gem
 - direct S3 uploads
 - [S3](https://aws.amazon.com/s3/) as file storage for production and staging servers, and disk storage for development.
 
 # Shrine
 There are several file upload gems out there. We use [Shrine](https://github.com/janko-m/shrine) because of its flexibility and maintainability.
-It is a general-purpose file uploader gem. Since it has no direct dependencies,
+It is a general-purpose file uploader gem. Since it has no direct dependency,
 __it can be used in both Rails and non-Rails projects.__
 
 Official docs can be found [here](https://shrinerb.com/)
@@ -16,7 +16,7 @@ Shrine features a rich plugin system which makes it incredibly easy to change it
 
 Here are some of the plugins we use often:
 - [activerecord](https://shrinerb.com/docs/plugins/activerecord)
-- [backgrounding](https://shrinerb.com/docs/plugins/backgrounding)
+- [bakgrounding](https://shrinerb.com/docs/plugins/backgrounding)
 - [cached_attachment_data](https://shrinerb.com/docs/plugins/cached_attachment_data) - for forms
 - [derivatives](https://shrinerb.com/docs/plugins/derivatives)
 - [determine_mime_type](https://shrinerb.com/docs/plugins/determine_mime_type)
@@ -29,28 +29,23 @@ Here are some of the plugins we use often:
 ## Security
 Files stored on S3 are private by default. This means file URLs will be signed and they will expire after some specified time.
 
-It's best to explicitly set the expiration time for **each uploader class** using the [url_options](https://shrinerb.com/docs/plugins/url_options) plugin.
-
-Some files need to be public, e.g. album covers. In that case, set the `acl` to `public-read` via the [upload_options](https://shrinerb.com/docs/plugins/upload_options) plugin for that uploader class.
-
-## Processing images
-If you're uploading images, you should process them (file compression) and create **multiple versions** (derivatives in Shrine) of different sizes. Consult with frontend devs on required dimensions.
-
-We use [image_processing gem](https://github.com/janko/image_processing) with the [libvips](https://libvips.github.io/libvips/), which is a better performant alternative to ImageMagick.
-
-The **backgrounding** plugin should be combined with the processing for a better user experience.
+It's best to explicitly set the expiration time for **each uploader class** using [url_options](https://shrinerb.com/docs/plugins/url_options) plugin.
 
+Some files need to be public, i.e. albums' covers. In that case, set the `acl` to `public-read` via [upload_options](https://shrinerb.com/docs/plugins/upload_options) plugin for that uploader class.
 
 ## Other guidelines
 
-- Use the **jsonb** data type for file columns when possible.
+- Use **jsonb** data type for file columns when possible.
+
+- If you're uploading images, you should process them (file compression) and create **multiple versions** (derivatives in Shrine) of different sizes. Consult with frontend devs on required dimensions.
+**Backgrounding** plugin should be combined with the processing for a better user experience.
 
-- Always validate the **mime type** for uploaded files, as well as the extension if needed.
+- Always validate **mime type** for uploaded files, and extension if needed.
 
 - Shrine doesn't automatically delete files from cache storage when moving them to store storage. Tell a DevOps to **set a lifecycle policy** with an appropriate amount of time **for cache storage** prefix.
 
 # Direct S3 upload
-Mobile or web frontends often upload files through the app server, which means that the file does a double hop: from the frontend to the backend, then from the backend to the cloud storage service.
+Mobile or web front ends often upload files through the app server, which means that the file does a double hop: from the frontend to the backend, then from the backend to the cloud storage service.
 
 Direct upload solves this double-hop performance problem by giving one-time credentials to the frontend app to upload files directly to the cloud, and it sends out references to those files to the backend.