Group items tagged

each action also maps to particular CRUD operations in a database

One way to avoid deep nesting (as recommended above) is to generate the collection actions scoped under the parent, so as to get a sense of the hierarchy, but to not nest the member actions.

to only build routes with the minimal amount of information to uniquely identify the resource

The shallow method of the DSL creates a scope inside of which every nesting is shallow

These concerns can be used in resources to avoid code duplication and share behavior across routes

add a member route, just add a member block into the resource block

You can leave out the :on option, this will create the same member route except that the resource id value will be available in params[:photo_id] instead of params[:id].

Singular Resources

use a singular resource to map /profile (rather than /profile/:id) to the show action

Passing a String to get will expect a controller#action format

workaround

organize groups of controllers under a namespace

route /articles (without the prefix /admin) to Admin::ArticlesController

route /admin/articles to ArticlesController (without the Admin:: module prefix)

Nested routes allow you to capture this relationship in your routing.

Resources should never be nested more than 1 level deep.

via the :shallow option

a balance between descriptive routes and deep nesting

:shallow_path prefixes member paths with the specified parameter

Routing Concerns allows you to declare common routes that can be reused inside other resources and routes

Rails can also create paths and URLs from an array of parameters.

use url_for with a set of objects

In helpers like link_to, you can specify just the object in place of the full url_for call

insert the action name as the first element of the array

pass :on to a route, eliminating the block:

Collection Routes

simple routing makes it very easy to map legacy URLs to new Rails actions

add an alternate new action using the :on shortcut

When you set up a regular route, you supply a series of symbols that Rails maps to parts of an incoming HTTP request.

:controller maps to the name of a controller in your application

:action maps to the name of an action within that controller

This route will also route the incoming request of /photos to PhotosController#index, since :action and :id are

use a constraint on :controller that matches the namespace you require

dynamic segments don't accept dots

The params will also include any parameters from the query string

:defaults option.

set params[:format] to "jpg"

specify a name for any route using the :as option

create logout_path and logout_url as named helpers in your application.

Inside the show action of UsersController, params[:username] will contain the username for the user.

should use the get, post, put, patch and delete methods to constrain a route to a particular verb.

use the match method with the :via option to match multiple verbs at once

use the :constraints option to enforce a format for a dynamic segment

constraints

don't need to use anchors

the same name as the hash key and then compare the return value with the hash value.

constraint values should match the corresponding Request object method return type

blacklist

redirect helper

reuse dynamic segments from the match in the path to redirect

this redirection is a 301 "Moved Permanently" redirect.

root method

put the root route at the top of the file

root inside namespaces and scopes

For namespaced controllers you can use the directory notation

use the :constraints option to specify a required format on the implicit id

specify a single constraint to apply to a number of routes by using the block

non-resourceful routes

:id parameter doesn't accept dots

:as option lets you override the normal naming for the named route helpers

use the :as option to prefix the named route helpers that Rails generates for a rout

prevent name collisions

prefix routes with a named parameter

:only option

:except option

alter path names

http://localhost:3000/rails/info/routes

rake routes

setting the CONTROLLER environment variable

Routes should be included in your testing strategy

assert_generates assert_recognizes assert_routing

that /var/lib/docker should be a volume. This is important, because the filesystem of a container is an AUFS mountpoint, composed of multiple branches; and those branches have to be “normal” filesystems (i.e. not AUFS mountpoints).

since the private Docker instances run in privileged mode, they can easily escalate to the host, and you probably don’t want this! If you really want to run something like this and expose it to the public, you will have to fine-tune the LXC template file, to restrict the capabilities and devices available to the Docker instances.

When you are inside a privileged container, you can always nest one more level

the LXC tools cannot start nested containers if the devices control group is not in its own hierarchy.

if you use AppArmor, you need a special policy to support nested containers.

each.value — The map value corresponding to this instance. (If a set was provided, this is the same as each.key.)

for_each keys cannot be the result (or rely on the result of) of impure functions, including uuid, bcrypt, or timestamp, as their evaluation is deferred during the main evaluation step.

The value used in for_each is used to identify the resource instance and will always be disclosed in UI output, which is why sensitive values are not allowed.

if you would like to call keys(local.map), where local.map is an object with sensitive values (but non-sensitive keys), you can create a value to pass to for_each with toset([for k,v in local.map : k]).

for_each can't refer to any resource attributes that aren't known until after a configuration is applied (such as a unique ID generated by the remote API when an object is created).

he for_each argument does not implicitly convert lists or tuples to sets.

Transform a multi-level nested structure into a flat list by using nested for expressions with the flatten function.

Instances are identified by a map key (or set member) from the value provided to for_each

Within nested provisioner or connection blocks, the special self object refers to the current resource instance, not the resource block as a whole.

contexts can be layered within one another

The children contexts can override these values at will

Nginx will error out on reading a configuration file with directives that are declared in the wrong context.

The most general context is the "main" or "global" context

Any directive that exist entirely outside of these blocks is said to inhabit the "main" context

The main context represents the broadest environment for Nginx configuration.

The "events" context is contained within the "main" context. It is used to set global options that affect how Nginx handles connections at a general level.

Nginx uses an event-based connection processing model, so the directives defined within this context determine how worker processes should handle connections.

the connection processing method is automatically selected based on the most efficient choice that the platform has available

a worker will only take a single connection at a time

When configuring Nginx as a web server or reverse proxy, the "http" context will hold the majority of the configuration.

fine-tune the TCP keep alive settings (keepalive_disable, keepalive_requests, and keepalive_timeout)

multiple declarations

each instance defines a specific virtual server to handle client requests

Each client request will be handled according to the configuration defined in a single server context, so Nginx must decide which server context is most appropriate based on details of the request.

listen: The ip address / port combination that this server block is designed to respond to.

server_name: This directive is the other component used to select a server block for processing.

configure files to try to respond to requests (try_files)

issue redirects and rewrites (return and rewrite)

set arbitrary variables (set)

Location contexts share many relational qualities with server contexts

multiple location contexts can be defined, each location is used to handle a certain type of client request, and each location is selected by virtue of matching the location definition against the client request through a selection algorithm

Location blocks live within server contexts and, unlike server blocks, can be nested inside one another.

The request URI is the portion of the request that comes after the domain name or IP address/port combination.

New directives at this level allow you to reach locations outside of the document root (alias), mark the location as only internally accessible (internal), and proxy to other servers or locations (using http, fastcgi, scgi, and uwsgi proxying).

These can then be used to do A/B testing by providing different content to different hosts.

configures Perl handlers for the location they appear in

set the value of a variable depending on the value of another variable

used to map MIME types to the file extensions that should be associated with them.

this context defines a named pool of servers that Nginx can then proxy requests to

The upstream context can then be referenced by name within server or location blocks to pass requests of a certain type to the pool of servers that have been defined.

function as a high performance mail proxy server

The mail context is defined within the "main" or "global" context (outside of the http context).

Nginx has the ability to redirect authentication requests to an external authentication server

the if directive in Nginx will execute the instructions contained if a given test returns "true".

The limit_except context is used to restrict the use of certain HTTP methods within a location context.

The result of the above example is that any client can use the GET and HEAD verbs, but only clients coming from the 192.168.1.1/24 subnet are allowed to use other methods.

Many directives are valid in more than one context

Declaring at higher levels provides you with a sane default

Nginx already engages in a well-documented selection algorithm for things like selecting server blocks and location blocks.

incorrect requests can get by with a redirect rather than a rewrite, which should execute with lower overhead.

After the block type keyword and any labels, the block body is delimited by the { and } characters

Identifiers can contain letters, digits, underscores (_), and hyphens (-). The first character of an identifier must not be a digit, to avoid ambiguity with literal numbers.

The # single-line comment style is the default comment style and should be used in most cases.

he idiomatic style is to use the Unix convention

Indent two spaces for each nesting level.

align their equals signs

Use empty lines to separate logical groups of arguments within a block.

Use one blank line to separate the arguments from the blocks.

"meta-arguments" (as defined by the Terraform language semantics)

Avoid separating multiple blocks of the same type with other blocks of a different type, unless the block types are defined by semantics to form a family.

Resource names must start with a letter or underscore, and may contain only letters, digits, underscores, and dashes.

By convention, resource type names start with their provider's preferred local name.

Most publicly available providers are distributed on the Terraform Registry, which also hosts their documentation.

The Terraform language defines several meta-arguments, which can be used with any resource type to change the behavior of resources.

use precondition and postcondition blocks to specify assumptions and guarantees about how the resource operates.

Some resource types provide a special timeouts nested block argument that allows you to customize how long certain operations are allowed to take before being considered to have failed.

Timeouts are handled entirely by the resource type implementation in the provider

Most resource types do not support the timeouts block at all.

A resource block declares that you want a particular infrastructure object to exist with the given settings.

Destroy resources that exist in the state but no longer exist in the configuration.

Destroy and re-create resources whose arguments have changed but which cannot be updated in-place due to remote API limitations.

Expressions within a Terraform module can access information about resources in the same module, and you can use that information to help configure other resources. Use the <RESOURCE TYPE>.<NAME>.<ATTRIBUTE> syntax to reference a resource attribute in an expression.

resources often provide read-only attributes with information obtained from the remote API; this often includes things that can't be known until the resource is created, like the resource's unique random ID.

data sources, which are a special type of resource used only for looking up information.

some dependencies cannot be recognized implicitly in configuration.

local-only resource types exist for generating private keys, issuing self-signed TLS certificates, and even generating random ids.

The count meta-argument accepts a whole number, and creates that many instances of the resource or module.

the count value must be known before Terraform performs any remote resource actions. This means count can't refer to any resource attributes that aren't known until after a configuration is applied

Within nested provisioner or connection blocks, the special self object refers to the current resource instance, not the resource block as a whole.

config/environments/production.rb

Create an additional staging environment that closely resembles the production one

Keep any additional configuration in YAML files under the config/ directory

Rails::Application.config_for(:yaml_file)

Use nested routes to express better the relationship between ActiveRecord models

nest routes more than 1 level deep then use the shallow: true option

namespaced routes to group related actions

Keep the controllers skinny

all the business logic should naturally reside in the model

Share no more than two instance variables between a controller and a view.

using a template

Prefer corresponding symbols to numeric HTTP status codes

without abbreviations

Keep your models for business logic and data-persistence only

Avoid altering ActiveRecord defaults (table names, primary key, etc)

Prefer has_many :through to has_and_belongs_to_many

self[:attribute]

self[:attribute] = value

validates

Consider extracting custom validators to a shared gem

preferable to make a class method instead which serves the same purpose of the named scope

.update_attributes

Override the to_param method of the model

Use the friendly_id gem. It allows creation of human-readable URLs by using some descriptive attribute of the model instead of its id

.find_each

.find_each

Looping through a collection of records from the database (using the all method, for example) is very inefficient since it will try to instantiate all the objects at once

always call before_destroy callbacks that perform validation with prepend: true

When persisting AR objects

Avoid string interpolation in queries

param will be properly escaped

Consider using named placeholders instead of positional placeholders

use of find over where when you need to retrieve a single record by id

use of find_by over where and find_by_attribute

use of where.not over SQL

use heredocs with squish

Use rake db:schema:load instead of rake db:migrate to initialize an empty database

change_column_default

imposing data integrity from the Rails app is impossible

use the change method instead of up and down methods.

constructive migrations

use models in migrations, make sure you define them so that you don't end up with broken migrations in the future

In this case, block will be used by create_table in rollback

Never make complex formatting in the views, export the formatting to a method in the view helper or the model.

When the labels of an ActiveRecord model need to be translated, use the activerecord scope

Separate the texts used in the views from translations of ActiveRecord attributes

config/application.rb config.i18n.load_path += Dir[Rails.root.join('config', 'locales', '**', '*.{rb,yml}')]

I18n.t

I18n.l

Use "lazy" lookup for the texts used in views.

Use the dot-separated keys in the controllers and models

Reserve app/assets for custom stylesheets, javascripts, or images

Third party code such as jQuery or bootstrap should be placed in vendor/assets

Provide both HTML and plain-text view templates

config.action_mailer.raise_delivery_errors = true

Use a local SMTP server like Mailcatcher in the development environment

Provide default settings for the host name

The _url methods include the host name and the _path methods don't

Format the from and to addresses properly

default from:

sending html emails all styles should be inline

Sending emails while generating page response should be avoided. It causes delays in loading of the page and request can timeout if multiple email are sent.

.start_with?

.end_with?

&.

Config your timezone accordingly in application.rb

config.active_record.default_timezone = :local

it can be only :utc or :local

Time.zone.parse

Time.zone.now

a human-edited configuration file in the Terraform language native syntax could be partially overridden using a programmatically-generated file in JSON syntax.

Terraform initially skips these override files when loading configuration, and then afterwards processes each one in turn (in lexicographical order).

Over-use of override files hurts readability, since a reader looking only at the original files cannot easily see that some portions of those files have been overridden without consulting all of the override files that are present.

A top-level block in an override file merges with a block in a normal configuration file that has the same block header.

Within a top-level block, an attribute argument within an override block replaces any argument of the same name in the original block.

Within a top-level block, any nested blocks within an override block replace all blocks of the same type in the original block.

The contents of nested configuration blocks are not merged.

If more than one override file defines the same top-level block, the overriding effect is compounded, with later blocks taking precedence over earlier blocks

The settings within terraform blocks are considered individually when merging.

If the required_providers argument is set, its value is merged on an element-by-element basis, which allows an override block to adjust the constraint for a single provider without affecting the constraints for other providers.

block helpers are identified by a # preceeding the helper name and require a matching closing mustache, /, of the same name.

use Handlebars templates with more raw JSON objects.

Nested handlebars paths can also include ../ segments, which evaluate their paths against a parent context.

The exact value that ../ will resolve to varies based on the helper that is calling the block.

reference the same permalink value even though they are located within different blocks.

name conflict resolution between helpers and data fields via a this reference

comments will not be in the resulting output.

register a helper with the Handlebars.registerHelper method.

Helpers receive the current context as the this context of the function.

returns HTML that you do not want escaped, make sure to return a new Handlebars.SafeString

literal values passed to them either as parameter arguments or hash arguments

Handlebars partials allow for code reuse by creating shared templates

Handlebars.registerPartial

Associations are implemented using macro-style calls, so that you can declaratively add features to your models

A belongs_to association sets up a one-to-one connection with another model, such that each instance of the declaring model "belongs to" one instance of the other model.

belongs_to

A has_one association also sets up a one-to-one connection with another model, but with somewhat different semantics (and consequences).

belongs_to

A has_many association indicates a one-to-many connection with another model.

This association indicates that each instance of the model has zero or more instances of another model.

belongs_to

A has_many :through association is often used to set up a many-to-many connection with another model

This association indicates that the declaring model can be matched with zero or more instances of another model by proceeding through a third model.

through:

through:

The collection of join models can be managed via the API

new join models are created for newly associated objects, and if some are gone their rows are deleted.

The has_many :through association is also useful for setting up "shortcuts" through nested has_many associations

A has_one :through association sets up a one-to-one connection with another model. This association indicates that the declaring model can be matched with one instance of another model by proceeding through a third model.

A has_and_belongs_to_many association creates a direct many-to-many connection with another model, with no intervening model.

id: false

The has_one relationship says that one of something is yours

using t.references :supplier instead.

declare a many-to-many relationship is to use has_many :through. This makes the association indirectly, through a join model

set up a has_many :through relationship if you need to work with the relationship model as an independent entity

set up a has_and_belongs_to_many relationship (though you'll need to remember to create the joining table in the database).

use has_many :through if you need validations, callbacks, or extra attributes on the join model

With polymorphic associations, a model can belong to more than one other model, on a single association.

a polymorphic belongs_to declaration as setting up an interface that any other model can use.

In designing a data model, you will sometimes find a model that should have a relation to itself

add a references column to the model itself

All of the association methods are built around caching, which keeps the result of the most recent query available for further operations.

it is a bad idea to give an association a name that is already used for an instance method of ActiveRecord::Base. The association method would override the base method and break things.

belongs_to associations you need to create foreign keys

has_and_belongs_to_many associations you need to create the appropriate join table

So a join between customer and order models will give the default join table name of "customers_orders" because "c" outranks "o" in lexical ordering.

For example, one would expect the tables "paper_boxes" and "papers" to generate a join table name of "papers_paper_boxes" because of the length of the name "paper_boxes", but it in fact generates a join table name of "paper_boxes_papers" (because the underscore '' is lexicographically _less than 's' in common encodings).

id: false

pass id: false to create_table because that table does not represent a model

By default, associations look for objects only within the current module's scope.

will work fine, because both the Supplier and the Account class are defined within the same scope.

To associate a model with a model in a different namespace, you must specify the complete class name in your association declaration:

class_name

class_name

Active Record provides the :inverse_of option

Every association will attempt to automatically find the inverse association and set the :inverse_of option heuristically (based on the association name)

In database terms, this association says that this class contains the foreign key.

In all of these methods, association is replaced with the symbol passed as the first argument to belongs_to.

(force_reload = false)

The association method returns the associated object, if any. If no associated object is found, it returns nil.

the cached version will be returned.

The association= method assigns an associated object to this object.

Behind the scenes, this means extracting the primary key from the associate object and setting this object's foreign key to the same value.

The build_association method returns a new object of the associated type

The create_association method returns a new object of the associated type

raises ActiveRecord::RecordInvalid if the record is invalid.

dependent

counter_cache

:autosave :class_name :counter_cache :dependent :foreign_key :inverse_of :polymorphic :touch :validate

finding the number of belonging objects more efficient.

Although the :counter_cache option is specified on the model that includes the belongs_to declaration, the actual column must be added to the associated model.

:destroy, when the object is destroyed, destroy will be called on its associated objects.

The :inverse_of option specifies the name of the has_many or has_one association that is the inverse of this association

set the :touch option to :true, then the updated_at or updated_on timestamp on the associated object will be set to the current time whenever this object is saved or destroyed

specify a particular timestamp attribute to update