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

The timestamps macro adds two columns, created_at and updated_at.

A primary key column called id will also be added implicitly, as it's the default primary key for all Active Record models

On databases that support transactions with statements that change the schema, migrations are wrapped in a transaction

AddXXXToYYY

RemoveXXXFromYYY

Migrations are stored as files in the db/migrate directory, one for each migration class

a UTC timestamp identifying the migration followed by an underscore followed by the name of the migration.

The name of the migration class (CamelCased version) should match the latter part of the file name

Rails uses this timestamp to determine which migration should be run and in what order,

allowing your schema and changes to be database independent.

each migration as being a new 'version' of the database

each migration modifies it to add or remove tables, columns, or entries

roll this migration back, it will remove the table

timestamps macro adds two columns, created_at and updated_at

On databases that support transactions with statements that change the schema, migrations are wrapped in a transaction

reversible

use up and down instead of change

Migrations are stored as files in the db/migrate directory, one for each migration class.

a UTC timestamp identifying

Rails uses this timestamp to determine which migration should be run and in what order

"AddXXXToYYY" or "RemoveXXXFromYYY"

use a Ruby DSL

column type as references

part_number:string:index

a migration to remove a column

"CreateXXX"

change_column_null

AddUserRefToProducts

:references

produce join tables if JoinTable is part of the name

CreateJoinTable

The model and scaffold generators will create migrations appropriate for adding a new model.

enclosed by curly braces and follow the field type

create_table

By default, create_table will create a primary key called id

add an index on the new column

when using MySQL, the default is ENGINE=InnoDB

create_join_table creates an HABTM (has and belongs to many) join table

create_join_table also accepts a block

change_table, used for changing existing tables

remove

rename

add_column

change_column

remove_column

change_column_default

place an SQL fragment in the :options option.

limit

precision

scale

polymorphic

default

index

add_foreign_key

use the old style of migration using up and down methods instead of the change method.

.connection.execute

remove_column is reversible if you supply the column type as the third argument

Complex migrations may require processing that Active Record doesn't know how to reverse

reversible

Using reversible will ensure that the instructions are executed in the right order too.

add_column add_foreign_key add_index add_reference add_timestamps change_column_default (must supply a :from and :to option) change_column_null create_join_table create_table disable_extension drop_join_table drop_table (must supply a block) enable_extension remove_column (must supply a type) remove_foreign_key (must supply a second table) remove_index remove_reference remove_timestamps rename_column rename_index rename_table

:column_options option

have the option :null set to false by default

By default, the name of the join table comes from the union of the first two arguments provided to create_join_table

If the column names can not be derived from the table names, you can use the :column and :primary_key options.

figure out the column name

foreign key for a specific column

foreign key by name

should use reversible or write the up and down methods instead of using the change method

If your migration is irreversible, you should raise ActiveRecord::IrreversibleMigration from your down method.

DontUseConstraintForZipcodeValidationMigration

rails db:migrate

specify a target version

all migrations up to and including 20080906120000

run the down method on all the migrations down to, but not including, 20080906120000

rails db:rollback

db:migrate:redo task is a shortcut for doing a rollback and then migrating back up again

STEP parameter

db:setup task will create the database, load the schema and initialize it with the seed data

db:reset task will drop the database and set it up again. This is functionally equivalent to rails db:drop db:setup.

run a specific migration up or down, the db:migrate:up and db:migrate:down

the RAILS_ENV environment variable

db:migrate VERBOSE=false will suppress all output.

must rollback the migration (for example with bin/rails db:rollback), edit your migration and then run rails db:migrate to run the corrected version.

editing existing migrations is not a good idea.

revert method can be helpful when writing a new migration to undo previous migrations in whole or in part

require_relative

revert

Schema Files for

Schema files are also useful if you want a quick look at what attributes an Active Record object has

annotate_models gem automatically adds and updates comments at the top of each model summarizing the schema if you desire that functionality.

database-independent

multiple databases

you can execute custom SQL statements, the schema dumper cannot reconstitute those statements from the database

db:structure:dump

set in config/application.rb by the config.active_record.schema_format setting, which may be either :sql or :ruby.

check them into source control.

db/schema.rb contains the current version number of the database

Validations such as validates :foreign_key, uniqueness: true are one way in which models can enforce data integrity

The :dependent option on associations allows models to automatically destroy child objects when the parent is destroyed.

Migrations can also be used to add or modify data

Initial

To add initial data after a database is created, Rails has a built-in 'seeds' feature that makes the process quick and easy.

db/seeds.rb

rails db:seed

most organizations practice continuous delivery, which means that your default branch can be deployed.

Merging everything into the master branch and frequently deploying means you minimize the amount of unreleased code, which is in line with lean and continuous delivery best practices.

you can deploy to production every time you merge a feature branch.

deploy a new version by merging master into the production branch.

you can have your deployment script create a tag on each deployment.

to have an environment that is automatically updated to the master branch

commits only flow downstream, ensures that everything is tested in all environments.

first merge these bug fixes into master, and then cherry-pick them into the release branch.

“merge request” since the final action is to merge the feature branch.

“pull request” since the first manual action is to pull the feature branch

it is common to protect the long-lived branches

After you merge a feature branch, you should remove it from the source control software

When you are ready to code, create a branch for the issue from the master branch. This branch is the place for any work related to this change.

A merge request is an online place to discuss the change and review the code.

To automatically close linked issues, mention them with the words “fixes” or “closes,” for example, “fixes #14” or “closes #67.” GitLab closes these issues when the code is merged into the default branch.

If you have an issue that spans across multiple repositories, create an issue for each repository and link all issues to a parent issue.

With Git, you can use an interactive rebase (rebase -i) to squash multiple commits into one or reorder them.

Rebasing creates new commits for all your changes, which can cause confusion because the same change would have multiple identifiers.

if someone has already reviewed your code, rebasing makes it hard to tell what changed since the last review.

always use the “no fast-forward” (--no-ff) strategy when you merge manually.

you should try to avoid merge commits in feature branches

you should never rebase commits you have pushed to a remote server

Sometimes you can reuse recorded resolutions (rerere), but merging is better since you only have to resolve conflicts once.

not frequently merge master into the feature branch.

utilizing new code,

resolving merge conflicts

updating long-running branches.

just cherry-picking a commit.

If your feature branch has a merge conflict, creating a merge commit is a standard way of solving this.

split your features into smaller units of work

you should try to prevent merge commits, but not eliminate them.

Your codebase should be clean, but your history should represent what actually happened.

Splitting up work into individual commits provides context for developers looking at your code later.

push your feature branch frequently, even when it is not yet ready for review.

When using GitLab flow, developers create their branches from this master branch, so it is essential that it never breaks. Therefore, each merge request must be tested before it is accepted.

DNS component in FreeIPA is optional and user may choose to manage all DNS records manually in other third party DNS server.

Clients can be configured to automatically run DNS updates (nsupdate) when their IP address changes and thus keeping its DNS record up-to-date. DNS zones can be configured to synchronize client's reverse (PTR) record along with the forward (A, AAAA) DNS record.

You should only use names which are delegated to you by the parent domain.

DNSSEC validation.

General advice about DNS views is do not use them because views make DNS deployment harder to maintain and security benefits are questionable (when compared with ACL).

FreeIPA LDAP directory information tree is by default accessible to any user in the network

As DNS data are often considered as sensitive and as having access to cn=dns tree would be basically equal to being able to run zone transfer to all FreeIPA managed DNS zones, contents of this tree in LDAP are hidden by default.

standard system log (/var/log/messages or system journal)

BIND configuration (/etc/named.conf) can be updated to produce a more detailed log.

The biggest problem is that many long-running branches emerge that all contain part of the changes.

It is a convention to call your default branch master and to mostly branch from and merge to this.

Nowadays, most organizations practice continuous delivery, which means that your default branch can be deployed.

Continuous delivery removes the need for hotfix and release branches, including all the ceremony they introduce.

Merging everything into the master branch and frequently deploying means you minimize the amount of unreleased code, which is in line with lean and continuous delivery best practices.

GitHub flow assumes you can deploy to production every time you merge a feature branch.

You can deploy a new version by merging master into the production branch. If you need to know what code is in production, you can just checkout the production branch to see.

Production branch

Environment branches

have an environment that is automatically updated to the master branch.

deploy the master branch to staging.

To deploy to pre-production, create a merge request from the master branch to the pre-production branch.

Go live by merging the pre-production branch into the production branch.

Release branches

work with release branches if you need to release software to the outside world.

each branch contains a minor version

After announcing a release branch, only add serious bug fixes to the branch.

merge these bug fixes into master, and then cherry-pick them into the release branch.

Merging into master and then cherry-picking into release is called an “upstream first” policy

Tools such as GitHub and Bitbucket choose the name “pull request” since the first manual action is to pull the feature branch.

Tools such as GitLab and others choose the name “merge request” since the final action is to merge the feature branch.

the merge request automatically updates when new commits are pushed to the branch.

If the assigned person does not feel comfortable, they can request more changes or close the merge request without merging.

In GitLab, it is common to protect the long-lived branches, e.g., the master branch, so that most developers can’t modify them.

After you merge a feature branch, you should remove it from the source control software.

Having a reason for every code change helps to inform the rest of the team and to keep the scope of a feature branch small.

For example, the issue title “As an administrator, I want to remove users without receiving an error” is better than “Admin can’t remove users.”

create a branch for the issue from the master branch

If you open the merge request but do not assign it to anyone, it is a “Work In Progress” merge request.

Start the title of the merge request with [WIP] or WIP: to prevent it from being merged before it’s ready.

When they press the merge button, GitLab merges the code and creates a merge commit that makes this event easily visible later on.

Suppose that a branch is merged but a problem occurs and the issue is reopened. In this case, it is no problem to reuse the same branch name since the first branch was deleted when it was merged.

GitLab closes these issues when the code is merged into the default branch.

If you have an issue that spans across multiple repositories, create an issue for each repository and link all issues to a parent issue.

use an interactive rebase (rebase -i) to squash multiple commits into one or reorder them.

Rebasing creates new commits for all your changes, which can cause confusion because the same change would have multiple identifiers.

if someone has already reviewed your code, rebasing makes it hard to tell what changed since the last review.

it is a bad idea to rebase commits that you have already pushed.

If you revert a merge commit and then change your mind, revert the revert commit to redo the merge.

Often, people avoid merge commits by just using rebase to reorder their commits after the commits on the master branch.

Using rebase prevents a merge commit when merging master into your feature branch, and it creates a neat linear history.

every time you rebase, you have to resolve similar conflicts.

A good way to prevent creating many merge commits is to not frequently merge master into the feature branch.

keep your feature branches short-lived.

If your feature branches often take more than a day of work, try to split your features into smaller units of work.

You could also use feature toggles to hide incomplete features so you can still merge back into master every day.

Your codebase should be clean, but your history should represent what actually happened.

If you rebase code, the history is incorrect, and there is no way for tools to remedy this because they can’t deal with changing commit identifiers

Commit often and push frequently

You should push your feature branch frequently, even when it is not yet ready for review.

A commit message should reflect your intention, not just the contents of the commit.

each merge request must be tested before it is accepted.

test the master branch after each change.

If new commits in master cause merge conflicts with the feature branch, merge master back into the branch to make the CI server re-run the tests.

Do not merge from upstream again if your code can work and merge cleanly without doing so.

can overwrite the default label by passing it to the input method

configure the html of any of them

disable labels, hints or error

add a hint, an error, or even a placeholder

add an inline label

pass any html attribute straight to the input, by using the :input_html option

use the :defaults option in simple_form_fo

Simple Form generates a wrapper div around your label and input by default, you can pass any html attribute to that wrapper as well using the :wrapper_html option,

By default all inputs are required

the required property of any input can be overwritten

lets you overwrite the default input type it creates

can also render boolean attributes using as: :select to show a dropdown.

give the :disabled option to Simple Form, and it'll automatically mark the wrapper as disabled with a CSS class

Any extra option passed to these methods will be rendered as html option.

use label, hint, input_field, error and full_error helpers

to strip away all the div wrappers around the <input> field

is to use f.input_field

changing boolean_style from default value :nested to :inline

overriding the :collection option

Collections can be arrays or ranges, and when a :collection is given the :select input will be rendered by default

label_method

value_method

Both of these options also accept lambda/procs

define a to_label method on your model as Simple Form will search for and use :to_label as a :label_method first if it is found

create grouped collection selects, that will use the html optgroup tags

Grouped collection inputs accept the same :label_method and :value_method options

group_method

group_label_method

configured with a default value to be used on the site through the SimpleForm.country_priority and SimpleForm.time_zone_priority helpers.

association

association

render a :select input for choosing the :company, and another :select input with :multiple option for the :roles

all options available to :select, :radio_buttons and :check_boxes are also available to association

f.input

f.select

create a <button> element

simple_fields_for

Creates a collection of radio inputs with labels associated

Creates a collection of checkboxes with labels associated

collection_radio_buttons

collection_check_boxes

associations in your model

Role.all

the html element you will get for each attribute according to its database definition

redefine existing Simple Form inputs by creating a new class with the same name

Simple Form uses all power of I18n API to lookup labels, hints, prompts and placeholders

specify defaults for all models under the 'defaults' key

Simple Form will always look for a default attribute translation under the "defaults" key if no specific is found inside the model key

Simple Form will fallback to default human_attribute_name from Rails when no other translation is found for labels.

Simple Form will only do the lookup for options if you give a collection composed of symbols only.

"Add %{model}"

translations for labels, hints and placeholders for a namespaced model, e.g. Admin::User, should be placed under admin_user, not under admin/user

configure how your components will be rendered using the wrappers API

optional

unless_blank

By default, Simple Form will generate input field types and attributes that are supported in HTML5

The HTML5 extensions include the new field types such as email, number, search, url, tel, and the new attributes such as required, autofocus, maxlength, min, max, step.

If you want to have all other HTML 5 features, such as the new field types, you can disable only the browser validation

add novalidate to a specific form by setting the option on the form itself

the Simple Form configuration file

passing the html5 option

as: :date, html5: true

For synchronization of data in the data nodes, MySQL cluster uses a special data engine called NDB (Network Database).

it uses automatic shrading aka splitting of a large database into small units.

MySQL cluster avoids single point failure and ensures 99.99% availability.

MySQL cluster can provide a response time as low as less than 3 ms.

Galera Cluster consists of a database server and uses the Galera Replication Plugin to manage replication.

a multi-master database cluster that supports synchronous replication.

it provides multiple, up-to-date copies of the data.

there is a need for instant fail-over.

Galera cluster include guaranteed write consistency, automatic node provisioning, etc.

Upon restoring the connection, the separated nodes will sync back and rejoin the cluster automatically.

there is no need to have management node like MySQL cluster.

it gives best results with the InnoDB storage engine.