Group items tagged

Rails gives your ability to configure application time zone.

It's not Rails responsible for adding time zone, but ActiveSupport

switch from Time.now to Time.zone.now

Time.zone.now

no need to use it explicitly as there is shorter and more clear option.

Time.zone.today

Time.zone.local

Time.zone.at

Time.zone.parse

DateTime.strptime(str, "%Y-%m-%d %H:%M %Z").in_time_zone

A null queue driver is also included which discards queued jobs.

In your config/queue.php configuration file, there is a connections configuration option.

any given queue connection may have multiple "queues" which may be thought of as different stacks or piles of queued jobs.

each connection configuration example in the queue configuration file contains a queue attribute.

if you dispatch a job without explicitly defining which queue it should be dispatched to, the job will be placed on the queue that is defined in the queue attribute of the connection configuration

pushing jobs to multiple queues can be especially useful for applications that wish to prioritize or segment how jobs are processed

specify which queues it should process by priority.

If your Redis queue connection uses a Redis Cluster, your queue names must contain a key hash tag.

ensure all of the Redis keys for a given queue are placed into the same hash slot

all of the queueable jobs for your application are stored in the app/Jobs directory.

Job classes are very simple, normally containing only a handle method which is called when the job is processed by the queue.

we were able to pass an Eloquent model directly into the queued job's constructor. Because of the SerializesModels trait that the job is using, Eloquent models will be gracefully serialized and unserialized when the job is processing.

When the job is actually handled, the queue system will automatically re-retrieve the full model instance from the database.

The handle method is called when the job is processed by the queue

The arguments passed to the dispatch method will be given to the job's constructor

delay the execution of a queued job, you may use the delay method when dispatching a job.

dispatch a job immediately (synchronously), you may use the dispatchNow method.

specify a list of queued jobs that should be run in sequence.

Deleting jobs using the $this->delete() method will not prevent chained jobs from being processed. The chain will only stop executing if a job in the chain fails.

this does not push jobs to different queue "connections" as defined by your queue configuration file, but only to specific queues within a single connection.

To specify the queue, use the onQueue method when dispatching the job

To specify the connection, use the onConnection method when dispatching the job

defining the maximum number of attempts on the job class itself.

to defining how many times a job may be attempted before it fails, you may define a time at which the job should timeout.

using the funnel method, you may limit jobs of a given type to only be processed by one worker at a time

using the throttle method, you may throttle a given type of job to only run 10 times every 60 seconds.

If an exception is thrown while the job is being processed, the job will automatically be released back onto the queue so it may be attempted again.

dispatch a Closure. This is great for quick, simple tasks that need to be executed outside of the current request cycle

When dispatching Closures to the queue, the Closure's code contents is cryptographically signed so it can not be modified in transit.

Laravel includes a queue worker that will process new jobs as they are pushed onto the queue.

once the queue:work command has started, it will continue to run until it is manually stopped or you close your terminal

they will not notice changes in your code base after they have been started.

during your deployment process, be sure to restart your queue workers.

customize your queue worker even further by only processing particular queues for a given connection

The --once option may be used to instruct the worker to only process a single job from the queue

The --stop-when-empty option may be used to instruct the worker to process all jobs and then exit gracefully.

Daemon queue workers do not "reboot" the framework before processing each job.

Since queue workers are long-lived processes, they will not pick up changes to your code without being restarted.

php artisan queue:restart

The queue uses the cache to store restart signals

the queue workers will die when the queue:restart command is executed, you should be running a process manager such as Supervisor to automatically restart the queue workers.

each queue connection defines a retry_after option. This option specifies how many seconds the queue connection should wait before retrying a job that is being processed.

The --timeout option specifies how long the Laravel queue master process will wait before killing off a child queue worker that is processing a job.

When jobs are available on the queue, the worker will keep processing jobs with no delay in between them.

While sleeping, the worker will not process any new jobs - the jobs will be processed after the worker wakes up again

the numprocs directive will instruct Supervisor to run 8 queue:work processes and monitor all of them, automatically restarting them if they fail.

Laravel includes a convenient way to specify the maximum number of times a job should be attempted.

define a failed method directly on your job class, allowing you to perform job specific clean-up when a failure occurs.

a great opportunity to notify your team via email or Slack.

php artisan queue:retry all

php artisan queue:flush

When injecting an Eloquent model into a job, it is automatically serialized before being placed on the queue and restored when the job is processed

initialize the local CLI

install Tiller into your Kubernetes cluster

helm install

helm init --upgrade

By default, when Tiller is installed, it does not have authentication enabled.

helm repo update

Without a max history set the history is kept indefinitely, leaving a large number of records for helm and tiller to maintain.

helm init --upgrade

Whenever you install a chart, a new release is created.

helm list function will show you a list of all deployed releases.

helm delete

helm status

the Helm server (Tiller).

The Helm client (helm)

brew install kubernetes-helm

it can also be run locally, and configured to talk to a remote Kubernetes cluster.

Role-Based Access Control - RBAC for short

run Tiller in an RBAC-enabled Kubernetes cluster.

run kubectl get pods --namespace kube-system and see Tiller running.

helm inspect

Helm will look for Tiller in the kube-system namespace unless --tiller-namespace or TILLER_NAMESPACE is set.

For development, it is sometimes easier to work on Tiller locally, and configure it to connect to a remote Kubernetes cluster.

helm version should show you both the client and server version.

The --node-selectors flag allows us to specify the node labels required for scheduling the Tiller pod.

--override allows you to specify properties of Tiller’s deployment manifest.

helm init --override manipulates the specified properties of the final manifest (there is no “values” file).

The --output flag allows us skip the installation of Tiller’s deployment manifest and simply output the deployment manifest to stdout in either JSON or YAML format.

switch from the default backend to the secrets backend, you’ll have to do the migration for this on your own.

a beta SQL storage backend that stores release information in an SQL database (only postgres has been tested so far).

Helm requires that kubelet have access to a copy of the socat program to proxy connections to the Tiller API.

A Release is an instance of a chart running in a Kubernetes cluster. One chart can often be installed many times into the same cluster.

helm init --client-only

helm init --dry-run --debug

A panic in Tiller is almost always the result of a failure to negotiate with the Kubernetes API server

Tiller and Helm have to negotiate a common version to make sure that they can safely communicate without breaking API assumptions

helm delete --purge

Helm stores some files in $HELM_HOME, which is located by default in ~/.helm

A Chart is a Helm package. It contains all of the resource definitions necessary to run an application, tool, or service inside of a Kubernetes cluster.

A Repository is the place where charts can be collected and shared.

Set the $HELM_HOME environment variable

Helm installs charts into Kubernetes, creating a new release for each installation. And to find new charts, you can search Helm chart repositories.

chart repository is named stable by default

helm search shows you all of the available charts

helm inspect

To install a new package, use the helm install command. At its simplest, it takes only one argument: The name of the chart.

If you want to use your own release name, simply use the --name flag on helm install

additional configuration steps you can or should take.

Helm does not wait until all of the resources are running before it exits. Many charts require Docker images that are over 600M in size, and may take a long time to install into the cluster.

helm status

helm inspect values

helm inspect values stable/mariadb

override any of these settings in a YAML formatted file, and then pass that file during installation.

helm install -f config.yaml stable/mariadb

--values (or -f): Specify a YAML file with overrides.

--set (and its variants --set-string and --set-file): Specify overrides on the command line.

Values that have been --set can be cleared by running helm upgrade with --reset-values specified.

Chart designers are encouraged to consider the --set usage when designing the format of a values.yaml file.

--set-file key=filepath is another variant of --set. It reads the file and use its content as a value.

inject a multi-line text into values without dealing with indentation in YAML.

An unpacked chart directory

When a new version of a chart is released, or when you want to change the configuration of your release, you can use the helm upgrade command.

Kubernetes charts can be large and complex, Helm tries to perform the least invasive upgrade.

$ helm upgrade -f panda.yaml happy-panda stable/mariadb

deployment

If both are used, --set values are merged into --values with higher precedence.

The helm get command is a useful tool for looking at a release in the cluster.

A release version is an incremental revision. Every time an install, upgrade, or rollback happens, the revision number is incremented by 1.

helm history

you can rollback a deleted resource, and have it re-activate.

helm repo list

helm repo add

helm repo update

helm create

helm lint

helm package

Charts that are archived can be loaded into chart repositories.

chart repository server

Tiller can be installed into any namespace.

Limiting Tiller to only be able to install into specific namespaces and/or resource types is controlled by Kubernetes RBAC roles and rolebindings

Release names are unique PER TILLER INSTANCE

Charts should only contain resources that exist in a single namespace.

not recommended to have multiple Tillers configured to manage resources in the same namespace.

a client-side Helm plugin. A plugin is a tool that can be accessed through the helm CLI, but which is not part of the built-in Helm codebase.

Helm plugins are add-on tools that integrate seamlessly with Helm. They provide a way to extend the core feature set of Helm, but without requiring every new feature to be written in Go and added to the core tool.

Helm plugins live in $(helm home)/plugins

The Helm plugin model is partially modeled on Git’s plugin model

helm referred to as the porcelain layer, with plugins being the plumbing.

helm plugin install https://github.com/technosophos/helm-template

command is the command that this plugin will execute when it is called.

Environment variables are interpolated before the plugin is executed.

The command itself is not executed in a shell. So you can’t oneline a shell script.

Helm is able to fetch Charts using HTTP/S

Variables like KUBECONFIG are set for the plugin if they are set in the outer environment.

In Kubernetes, granting a role to an application-specific service account is a best practice to ensure that your application is operating in the scope that you have specified.

restrict Tiller’s capabilities to install resources to certain namespaces, or to grant a Helm client running access to a Tiller instance.

Service account with cluster-admin role

The cluster-admin role is created by default in a Kubernetes cluster

Deploy Tiller in a namespace, restricted to deploying resources only in that namespace

Deploy Tiller in a namespace, restricted to deploying resources in another namespace

When running a Helm client in a pod, in order for the Helm client to talk to a Tiller instance, it will need certain privileges to be granted.

SSL Between Helm and Tiller

The Tiller authentication model uses client-side SSL certificates.

creating an internal CA, and using both the cryptographic and identity functions of SSL.

Helm is a powerful and flexible package-management and operations tool for Kubernetes.

default installation applies no security configurations

with a cluster that is well-secured in a private network with no data-sharing or no other users or teams.

With great power comes great responsibility.

Choose the Best Practices you should apply to your helm installation

Role-based access control, or RBAC

Tiller’s gRPC endpoint and its usage by Helm

Kubernetes employ a role-based access control (or RBAC) system (as do modern operating systems) to help mitigate the damage that can be done if credentials are misused or bugs exist.

In the default installation the gRPC endpoint that Tiller offers is available inside the cluster (not external to the cluster) without authentication configuration applied.

Tiller stores its release information in ConfigMaps. We suggest changing the default to Secrets.

release information

charts

charts are a kind of package that not only installs containers you may or may not have validated yourself, but it may also install into more than one namespace.

Helm’s provenance tools to ensure the provenance and integrity of charts

replication can provide increased read capacity as clients can send read operations to different servers.

A replica set contains several data bearing nodes and optionally one arbiter node.

A replica set can have only one primary capable of confirming writes with { w: "majority" } write concern; although in some circumstances, another mongod instance may transiently believe itself to also be primary.

The secondaries replicate the primary’s oplog and apply the operations to their data sets such that the secondaries’ data sets reflect the primary’s data set

add a mongod instance to a replica set as an arbiter. An arbiter participates in elections but does not hold data

An arbiter will always be an arbiter whereas a primary may step down and become a secondary and a secondary may become the primary during an election.

Secondaries replicate the primary’s oplog and apply the operations to their data sets asynchronously.

These slow oplog messages are logged for the secondaries in the diagnostic log under the REPL component with the text applied op: <oplog entry> took <num>ms.

Replication lag refers to the amount of time that it takes to copy (i.e. replicate) a write operation on the primary to a secondary.

When a primary does not communicate with the other members of the set for more than the configured electionTimeoutMillis period (10 seconds by default), an eligible secondary calls for an election to nominate itself as the new primary.

The replica set cannot process write operations until the election completes successfully.

The median time before a cluster elects a new primary should not typically exceed 12 seconds, assuming default replica configuration settings.

Factors such as network latency may extend the time required for replica set elections to complete, which in turn affects the amount of time your cluster may operate without a primary.

MongoDB drivers can detect the loss of the primary and automatically retry certain write operations a single time, providing additional built-in handling of automatic failovers and elections

By default, clients read from the primary [1]; however, clients can specify a read preference to send read operations to secondaries.

$upstream_response_time – Time between establishing a connection to an upstream server and receiving the last byte of the response body

capture timings in the application itself and include them as response headers, which NGINX then captures in its access log.

$upstream_header_time – Time between establishing a connection to an upstream server and receiving the first byte of the response header

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

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.