From 00e4f71da65b4012d9f82b9cfe4b150bca843770 Mon Sep 17 00:00:00 2001 From: Feram Date: Tue, 14 Jun 2016 16:14:47 +0000 Subject: [PATCH] Fix typos --- README.md | 8 ++++---- app/assets/stylesheets/welcome/cover.css | 2 +- .../extensions/generators/sass/assets/assets_generator.rb | 2 +- .../extensions/generators/scss/assets/assets_generator.rb | 2 +- lib/sassish/sassish/view_helper.rb | 2 +- 5 files changed, 8 insertions(+), 8 deletions(-) diff --git a/README.md b/README.md index f0bc2cc..3af0a6c 100644 --- a/README.md +++ b/README.md @@ -154,7 +154,7 @@ Finally, these are our conclusions about the selected approach: - In order to be compliant with the [config section](http://12factor.net/config) in the [twelve factor app](http://12factor.net/) methodology, we can also use environment variables (ENV) whenever necessary. `config/secrets.yml` as other YAML files in Rails is passed first through ERB, this behaviour gives us the chance to set our ENV using `dotenv` which allows us to load environment variables from an `.env` file into ENV in the configured environment. -- Keeping an easy deployment is a priority, and it is clear that using an ENV approach seems to cover this concern, but you can obtain the benefits of an hybrid solution by using a rich object support and ENV approach. Our experience has taught us that the sensitive data and the external integration credentials is a real concern for both the staging and production environments (especially for scenarios with limited control as Heroku), however you can manage this responsibility with ease, in your own servers you always can use capistrano (or similar solutions) for automating the remote installation of the `secrets.yml` file in each application server. On the other hand, you can also configure your application so that it’s compliant with Heroku. This template does not come bundled with capistrano or anything so you can choose what to do, but we recommend that you stick with the ["Store config in the environment" premise on 12factor](http://12factor.net/config). +- Keeping an easy deployment is a priority, and it is clear that using an ENV approach seems to cover this concern, but you can obtain the benefits of a hybrid solution by using a rich object support and ENV approach. Our experience has taught us that the sensitive data and the external integration credentials is a real concern for both the staging and production environments (especially for scenarios with limited control as Heroku), however you can manage this responsibility with ease, in your own servers you always can use capistrano (or similar solutions) for automating the remote installation of the `secrets.yml` file in each application server. On the other hand, you can also configure your application so that it’s compliant with Heroku. This template does not come bundled with capistrano or anything so you can choose what to do, but we recommend that you stick with the ["Store config in the environment" premise on 12factor](http://12factor.net/config). To configure this template for a standard Heroku deployment, you just have to add/uncomment a little deployment hack that you can see at the end of `config/application.rb` file (remember that the `secrets.yml` file is gitignored) in order to copy the example files that come with environment variable fetching inside of them via erb. @@ -202,7 +202,7 @@ At the end, you can customize several options for deploying Poltergeist changing We recommend that you always try to use version managers for everything you can, such as [phantomenv](https://github.com/boxen/phantomenv). for PhantomJS. ##### PhantomJS for Linux -you can find an stable release here: +you can find a stable release here: - [PhantomJS 1.9.7](https://bitbucket.org/ariya/phantomjs/downloads/phantomjs-1.9.7-linux-x86_64.tar.bz2) (tested on Ubuntu 12.04) @@ -298,7 +298,7 @@ You can see how to use Pry [here](http://www.sitepoint.com/rubyists-time-pry-irb We want to integrate a new way for structuring and generating our stylesheet resources in Rails. For that reason we have designed **Sassish**, and we will introduce you to it. -Sassish (we are thinking about changing its name, also we are thinking in bundling this piece of code in a gem as well) helps you with how the style files are organized and how these are loaded, its approach is an hybrid combination between both the traditional assets precompile philosophy and the benefits of sass' features. +Sassish (we are thinking about changing its name, also we are thinking in bundling this piece of code in a gem as well) helps you with how the style files are organized and how these are loaded, its approach is a hybrid combination between both the traditional assets precompile philosophy and the benefits of sass' features. The main idea is to simplify the development process by improving the organization, reusability and loading of the stylesheet resources, mitigating many issues that we've seen (it will help you for including an [OOCSS](http://www.slideshare.net/stubbornella/object-oriented-css) philosophy in the future). @@ -446,7 +446,7 @@ Sometimes we wonder about what would be the best place for our domain logic, we You can also find many online resources (posts, guides, tutorials, screencasts, etc.) about this topic (like [this](https://netguru.co/blog/service-objects-in-rails-will-help) and [this](https://blog.engineyard.com/2014/keeping-your-rails-controllers-dry-with-services)), but I like much this [post](http://adamniedzielski.github.io/blog/2014/11/25/my-take-on-services-in-rails/) as it exposes a pretty simple way for adopting the service object philosophy. I would like to emphasize the following aspects from it: -- Naming: the service object name is a **non-finite verb phrase** (wth?-> [see here](https://en.wikipedia.org/wiki/Verb_phrase)), because it denotes an action which is associated with a single responsability. Semantically it is easier to handle regarding its invocation and portability. +- Naming: the service object name is a **non-finite verb phrase** (wth?-> [see here](https://en.wikipedia.org/wiki/Verb_phrase)), because it denotes an action which is associated with a single responsibility. Semantically it is easier to handle regarding its invocation and portability. - Invoking: use a public method named **call**, “Lambdas and Procs also respond to `call` so in your tests you have the possibility to mock the service with a simple `Lambda`, which is quite convenient”. - Structuring & Organization: a folder named **services** at the same level of the **models** folder. You can also follow the same namespacing conventions using modules and classes as commonly used in Rails (code reloads too). - Dependency Injection: having a service with many responsibilities is a signal that you need to split it, but you can always use the **dependency injection** principle for fully isolating each service object. diff --git a/app/assets/stylesheets/welcome/cover.css b/app/assets/stylesheets/welcome/cover.css index 76fd0c9..65a8fa3 100644 --- a/app/assets/stylesheets/welcome/cover.css +++ b/app/assets/stylesheets/welcome/cover.css @@ -14,7 +14,7 @@ a:hover { .btn-default:hover, .btn-default:focus { color: #333; - text-shadow: none; /* Prevent inheritence from `body` */ + text-shadow: none; /* Prevent inheritance from `body` */ background-color: #fff; border: 1px solid #fff; } diff --git a/lib/sassish/sassish/extensions/generators/sass/assets/assets_generator.rb b/lib/sassish/sassish/extensions/generators/sass/assets/assets_generator.rb index d5995a6..5870962 100644 --- a/lib/sassish/sassish/extensions/generators/sass/assets/assets_generator.rb +++ b/lib/sassish/sassish/extensions/generators/sass/assets/assets_generator.rb @@ -3,7 +3,7 @@ module Extensions module Generators module Sass module Assets - # An elegant way for monkey patching teh SASS generator + # An elegant way for monkey patching the SASS generator # TODO: refactor with the scss mokey patch logic module AssetsGenerator def self.included(klass) diff --git a/lib/sassish/sassish/extensions/generators/scss/assets/assets_generator.rb b/lib/sassish/sassish/extensions/generators/scss/assets/assets_generator.rb index 6beffcd..c069e4c 100644 --- a/lib/sassish/sassish/extensions/generators/scss/assets/assets_generator.rb +++ b/lib/sassish/sassish/extensions/generators/scss/assets/assets_generator.rb @@ -3,7 +3,7 @@ module Extensions module Generators module Scss module Assets - # An elegant way for monkey patching teh SCSS generator + # An elegant way for monkey patching the SCSS generator # TODO: refactor with the sass mokey patch logic module AssetsGenerator def self.included(klass) diff --git a/lib/sassish/sassish/view_helper.rb b/lib/sassish/sassish/view_helper.rb index f565d92..b219f5f 100644 --- a/lib/sassish/sassish/view_helper.rb +++ b/lib/sassish/sassish/view_helper.rb @@ -47,7 +47,7 @@ def add_sassish_style(resource_paths) # # Checks if the specific stylesheet resource exists using the selected checking strategy - # either hard disk verfication or caching approach. You can configure that using the config + # either hard disk verification or caching approach. You can configure that using the config # variable in the enevironment you wish # # config.sassish.cache_stylesheet_resources = false # disable caching strategy in favor of hard-disk approach