This ebook covers what is ‘thought zone,’ how we use Github, our coding convention, and much more.

How we work



This book discusses how
[BigBinary](https://BigBinary.com) works.

If you'd like to get in touch about feedback, comments or questions, email us at
**hello@BigBinary.com**.
You can also find us on twitter at
[@BigBinary](http://twitter.com/bigbinary).

This ebook has been created, edited and published by
[BigBinary](https://bigbinary.com)
team members.


This book discusses how
<a href="https://BigBinary.com">BigBinary</a> works.
If you'd like to get in touch about feedback, comments or questions, email us at
hello@BigBinary.com.
You can also find us on twitter at
<a href="http://twitter.com/bigbinary">@BigBinary</a>.
This ebook has been created, edited and published by
<a href="https://bigbinary.com">BigBinary</a>
team members.

Introduction: How we work at BigBinary | A book by BigBinary on How We Work.

Introduction



At BigBinary
we are highly focussed on
getting work done.
So naturally the next question is -
what's the best place to work to get the work done?

## Where should I go to get work done

The obvious answer is 'office' - after all, isn't it **the** place to get work done?
Don't people go there every single day, specifically for that purpose?

Jason Fried decided to uncover the truth.
He asked a bunch of people a bunch of questions - and found out something interesting and unexpected.
Here's the reality: *not much work gets done at work.* Surprised?

Check out
Jason Fried's
excellent
TED talk on the subject
[Why Work Doesn't Happen At Work](http://www.ted.com/talks/jason_fried_why_work_doesn_t_happen_at_work).

## Maker's time vs Manager's time

A manager can easily swing in and out of meetings and be productive.
In fact the job of a manger is to manage for that meetings are
productive.

However for makers meetings could be a timesink.

[Maker vs. Manager: How Your Schedule Can Make or Break You](https://www.fs.blog/2017/12/maker-vs-manager)
is an excellent article on this topic.

Interruption caused by meetings do not equally impact makers and
managers. Makers need less interruptions.

## Being in thought zone

Being constantly interrupted is bad for our workflow.
Nothing really gets done when we are constantly interrupted.
Worst part is that these interruptions are disguised as work itself.
A ping on slack here, a message on skype there, a new email
notification, a ping from github for pending work seem like work.
However if not properly managed these interruptions do not let
us work on big ticket items.

To *really* get work done, we need to be **in the thought zone**.

How to achieve this? Well, the company needs to provide an environment which allows us to work without any interruption
for a certain period of time. That's when work happens. That's when we finally get to start ticking items off our to-do list.

As mentioned before the most difficult part is that these interruptions
come disguised as work itself.
In order to get work done we need to do all those things.
We need to take skype call, we need to answer items on slack, we need to
reply to emails and ,of course, we need to tend to github.

So how do we reconcile these two requirements. Requirement to have
"thought zone" with the requirement to "reply to interruptions".

At BigBinary, we try not to disturb people unless it is absolutely
needed.

We focus on getting work done , and then after an hour or so
we need a break. For some it could be a few hours before
they need the break.

When we are out of our "thought zone" then that's a good time
to check slack, email etc.

Main point is that it is up to us to decide if we want to check
slack or if we want to do work.
When someone interrupts us by sending a direct message on slack
then they are taking that right away from me. I have no choice
at that time and that's not good for getting work done.

##  Asynchronous communication is key to getting work done

In the presentation 'Why Work Does Not Get Done At Work', Jason
mentioned that meetings are toxic.
But why? Well, they're toxic
because they require all members to be present *at the same time.*

What this means is that people need to plan
their day around meeting schedules.
If we work this way then at the end of the day
we would have accomplished very little
in terms of real work even though
we were busy the whole day.

Joel Spoksky has [written](https://www.joelonsoftware.com/2001/02/12/human-task-switches-considered-harmful/)
about it in much more detail emphasizing how breaking task into smaller
task zones makes it difficult to get meaningful work done.

We should ask if synchronous communications are really needed in all the
cases?
At BigBinary we want to push asynchronous communication all the way
and would like to resort to synchronous communication
only as the last option.

For example,
if Mary is working on a problem and wants John to review the code sometime in the next few
hours (ie, not a pressing problem) she doesn't need to interrupt John's workflow.
He can do the pull request review in his own time,
as long as it is done on schedule.

Zach Holman of GitHub describes their asynchronous workflow in this
[presentation](http://confreaks.com/videos/754-rubymidwest2011-how-github-uses-github-to-build-github).
You can check out the slideshow of the presentation
[here](http://speakerdeck.com/embed/4e79b461c9bdcb003f00331d).

This kind of asynchronous communication maximizes the thought zone time of every member on the team,
thus maximizing the productivity of the organization as a whole.


At BigBinary
we are highly focussed on
getting work done.
So naturally the next question is -
what's the best place to work to get the work done?
<h2>Where should I go to get work done</h2>
The obvious answer is 'office' - after all, isn't it the place to get work done?
Don't people go there every single day, specifically for that purpose?
Jason Fried decided to uncover the truth.
He asked a bunch of people a bunch of questions - and found out something interesting and unexpected.
Here's the reality: not much work gets done at work. Surprised?
Check out
Jason Fried's
excellent
TED talk on the subject
<a href="http://www.ted.com/talks/jason_fried_why_work_doesn_t_happen_at_work">Why Work Doesn't Happen At Work</a>.
<h2>Maker's time vs Manager's time</h2>
A manager can easily swing in and out of meetings and be productive.
In fact the job of a manger is to manage for that meetings are
productive.
However for makers meetings could be a timesink.
<a href="https://www.fs.blog/2017/12/maker-vs-manager">Maker vs. Manager: How Your Schedule Can Make or Break You</a>
is an excellent article on this topic.
Interruption caused by meetings do not equally impact makers and
managers. Makers need less interruptions.
<h2>Being in thought zone</h2>
Being constantly interrupted is bad for our workflow.
Nothing really gets done when we are constantly interrupted.
Worst part is that these interruptions are disguised as work itself.
A ping on slack here, a message on skype there, a new email
notification, a ping from github for pending work seem like work.
However if not properly managed these interruptions do not let
us work on big ticket items.
To really get work done, we need to be in the thought zone.
How to achieve this? Well, the company needs to provide an environment which allows us to work without any interruption
for a certain period of time. That's when work happens. That's when we finally get to start ticking items off our to-do list.
As mentioned before the most difficult part is that these interruptions
come disguised as work itself.
In order to get work done we need to do all those things.
We need to take skype call, we need to answer items on slack, we need to
reply to emails and ,of course, we need to tend to github.
So how do we reconcile these two requirements. Requirement to have
&quot;thought zone&quot; with the requirement to &quot;reply to interruptions&quot;.
At BigBinary, we try not to disturb people unless it is absolutely
needed.
We focus on getting work done , and then after an hour or so
we need a break. For some it could be a few hours before
they need the break.
When we are out of our &quot;thought zone&quot; then that's a good time
to check slack, email etc.
Main point is that it is up to us to decide if we want to check
slack or if we want to do work.
When someone interrupts us by sending a direct message on slack
then they are taking that right away from me. I have no choice
at that time and that's not good for getting work done.
<h2>Asynchronous communication is key to getting work done</h2>
In the presentation 'Why Work Does Not Get Done At Work', Jason
mentioned that meetings are toxic.
But why? Well, they're toxic
because they require all members to be present at the same time.
What this means is that people need to plan
their day around meeting schedules.
If we work this way then at the end of the day
we would have accomplished very little
in terms of real work even though
we were busy the whole day.
Joel Spoksky has <a href="https://www.joelonsoftware.com/2001/02/12/human-task-switches-considered-harmful/">written</a>
about it in much more detail emphasizing how breaking task into smaller
task zones makes it difficult to get meaningful work done.
We should ask if synchronous communications are really needed in all the
cases?
At BigBinary we want to push asynchronous communication all the way
and would like to resort to synchronous communication
only as the last option.
For example,
if Mary is working on a problem and wants John to review the code sometime in the next few
hours (ie, not a pressing problem) she doesn't need to interrupt John's workflow.
He can do the pull request review in his own time,
as long as it is done on schedule.
Zach Holman of GitHub describes their asynchronous workflow in this
<a href="http://confreaks.com/videos/754-rubymidwest2011-how-github-uses-github-to-build-github">presentation</a>.
You can check out the slideshow of the presentation
<a href="http://speakerdeck.com/embed/4e79b461c9bdcb003f00331d">here</a>.
This kind of asynchronous communication maximizes the thought zone time of every member on the team,
thus maximizing the productivity of the organization as a whole.

Getting Work Done: Thought Zone | A book by BigBinary on How We Work.

Be in Thought Zone



BigBinary is a strong advocate for working remotely.

Some of our team members work from office but
majority prefer to work remotely.
At BigBinary no one is ever forced to come in to office.
If you feel like working from office,
of course you're welcome, but if not you can work from wherever you want to.

Being remote friendly allows BigBinary
to hire talented people from different geographical
areas - a big plus in a competitive market where talented professionals have many options available to them.

[Remote - Office Not Required](http://37signals.com/remote/)
is an excellent book which goes into more detail on the benefits of working remotely.


BigBinary is a strong advocate for working remotely.
Some of our team members work from office but
majority prefer to work remotely.
At BigBinary no one is ever forced to come in to office.
If you feel like working from office,
of course you're welcome, but if not you can work from wherever you want to.
Being remote friendly allows BigBinary
to hire talented people from different geographical
areas - a big plus in a competitive market where talented professionals have many options available to them.
<a href="http://37signals.com/remote/">Remote - Office Not Required</a>
is an excellent book which goes into more detail on the benefits of working remotely.

Getting Work Done: Working Remotely | A book by BigBinary on How We Work.

Working Remotely



These days Mac laptops come with zsh as the default shell.
Your linux machine might be configured to have a different default shell.
At BigBinay we recommend everyone to use [bash shell](https://en.wikipedia.org/wiki/Bash_(Unix_shell)).

### What I shell I'm using

In order to find out what shell you are currently execute the following
command.

```
$ echo $0
```

Depending on your machine the output could be `-bash` or `/bin/bash` or `ksh` or something else.
If the output contains the word `bash` then that means you are using `bash` shell.

If you are not using bash then we recommend you to switch to `bash` shell.

## Find where bash shell is installed

First let's find full path to bash shell.
In most of the systems it is `/bin/bash`.

Execute the following command.

```
$ type -a bash
```

On my machine I see the following output.

```
bash is /usr/local/bin/bash
bash is /usr/local/bin/bash
bash is /bin/bash
```

This confirms that `/bin/bash` is where bash shell executable resides.

## How to change default shell to bash

All shells provide a command called `chsh`. It stands for "change shell".

Execute the following command to change default shell to `bash`.

```
$ chsh -s /bin/bash
```

System will prompt you for a password. Enter your password.
In most of the systems as you type the password there will not be any feedback.
This feels strange but don't worry. Just type your password and hit enter.

Quit the shell you are using and start a new shell.
If you are using a mac then start a new terminal and then execute `echo $0` and
this time you should see `bash` in the output.

## Upgrading bash to the latest version in Mac

The new Mac laptops use zsh as the default shell.
However Mac laptops contain bash shell too.
The bash shell is not the default shell.

The bash shell that is shipped by Apple are stuck at version 3.x because
of the licensing concerns.
The latest version of bash is 5 or even higher.

Execute the following command to upgrade bash on your Mac laptop.

```
$ brew upgrade bash
```

Now open a new shell and execute the following command.

```
$ bash --version
GNU bash, version 5.1.4(1)-release (x86_64-apple-darwin18.7.0)
```

If you see output 5.1.4 or higher than you are all set.

These days Mac laptops come with zsh as the default shell.
Your linux machine might be configured to have a different default shell.
At BigBinay we recommend everyone to use <a href="https://en.wikipedia.org/wiki/Bash_(Unix_shell)">bash shell</a>.
<h3>What I shell I'm using</h3>
In order to find out what shell you are currently execute the following
command.
<pre><code>$ echo $0
</code></pre>
Depending on your machine the output could be <code>-bash</code> or <code>/bin/bash</code> or <code>ksh</code> or something else.
If the output contains the word <code>bash</code> then that means you are using <code>bash</code> shell.
If you are not using bash then we recommend you to switch to <code>bash</code> shell.
<h2>Find where bash shell is installed</h2>
First let's find full path to bash shell.
In most of the systems it is <code>/bin/bash</code>.
Execute the following command.
<pre><code>$ type -a bash
</code></pre>
On my machine I see the following output.
<pre><code>bash is /usr/local/bin/bash
bash is /usr/local/bin/bash
bash is /bin/bash
</code></pre>
This confirms that <code>/bin/bash</code> is where bash shell executable resides.
<h2>How to change default shell to bash</h2>
All shells provide a command called <code>chsh</code>. It stands for &quot;change shell&quot;.
Execute the following command to change default shell to <code>bash</code>.
<pre><code>$ chsh -s /bin/bash
</code></pre>
System will prompt you for a password. Enter your password.
In most of the systems as you type the password there will not be any feedback.
This feels strange but don't worry. Just type your password and hit enter.
Quit the shell you are using and start a new shell.
If you are using a mac then start a new terminal and then execute <code>echo $0</code> and
this time you should see <code>bash</code> in the output.
<h2>Upgrading bash to the latest version in Mac</h2>
The new Mac laptops use zsh as the default shell.
However Mac laptops contain bash shell too.
The bash shell is not the default shell.
The bash shell that is shipped by Apple are stuck at version 3.x because
of the licensing concerns.
The latest version of bash is 5 or even higher.
Execute the following command to upgrade bash on your Mac laptop.
<pre><code>$ brew upgrade bash
</code></pre>
Now open a new shell and execute the following command.
<pre><code>$ bash --version
GNU bash, version 5.1.4(1)-release (x86_64-apple-darwin18.7.0)
</code></pre>
If you see output 5.1.4 or higher than you are all set.

Use bash shell



These days we use git in most of our projects.
If we are using git then it's a good idea to know
which branch we are working on.
We can check what our current branch is but it
would be much nicer if the command prompt
displays the current branch automatically.

Here is how your command prompt would look after the instructions
mentioned in this page are followed.
Note that the current branch (master) is displayed in the command
prompt along with the directory name.

```
$ ~/code/bigbinary-website master
$
```

## Configurations of Custom Command Prompt

These instructions will work only if you are [using bash shell](https://bigbinary.com/how-we-work/use-bash-shell).

First let's create `~/.bashrc` file if it does not exist.

```
$ touch ~/.bashrc
```

On command prompt execute `code ~/.bash_profile`.
Copy the existing content in clipboard.

Now execute `code ~/.bashrc`.
Past the content from `~/.bash_profile` to
the bottom of `~/.bashrc` file.

Now delete all the contents of `~/.bash_profile`.

Now put the following code in `~/.bash_profile`.

```
if [ -f ~/.bashrc ]; then
    source ~/.bashrc
fi
```

Now open `~/.bashrc` and add the following content
at the bottom of the file.

```
txtblk='\e[0;30m' # Black - Regular
txtred='\e[0;31m' # Red
txtgrn='\e[0;32m' # Green
txtylw='\e[0;33m' # Yellow
txtblu='\e[0;34m' # Blue
txtpur='\e[0;35m' # Purple
txtcyn='\e[0;36m' # Cyan
txtwht='\e[0;37m' # White

bldblk='\e[1;30m' # Black - Bold
bldred='\e[1;31m' # Red
bldgrn='\e[1;32m' # Green
bldylw='\e[1;33m' # Yellow
bldblu='\e[1;34m' # Blue
bldpur='\e[1;35m' # Purple
bldcyn='\e[1;36m' # Cyan
bldwht='\e[1;37m' # White

unkblk='\e[4;30m' # Black - Underline
undred='\e[4;31m' # Red
undgrn='\e[4;32m' # Green
undylw='\e[4;33m' # Yellow
undblu='\e[4;34m' # Blue
undpur='\e[4;35m' # Purple
undcyn='\e[4;36m' # Cyan
undwht='\e[4;37m' # White

bakblk='\e[40m'   # Black - Background
bakred='\e[41m'   # Red
badgrn='\e[42m'   # Green
bakylw='\e[43m'   # Yellow
bakblu='\e[44m'   # Blue
bakpur='\e[45m'   # Purple
bakcyn='\e[46m'   # Cyan
bakwht='\e[47m'   # White

txtrst='\e[0m'    # Text Reset

a="\n$txtwht\u$txtblu \w $txtpur"
e="$\[\033[00m\] "

function parse_git_url {
  git config --get remote.origin.url | sed 's/\.git$//;s/$.*[:/]$$[^/]*$\/$[^/]*$$\.git$\{0,1\}$/(\2\/\3)/'
}

function parse_git_branch {
  git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* $.*$/\1/'
}

function custom_git_prompt {
  branch=$(git branch 2> /dev/null) || return
  echo "$(parse_git_branch)"
}

PS1="$a\$(custom_git_prompt)\n$e"
```

Now quit your shell and start a new shell.
You should see a new command prompt.

## Customize to your choice

Now that your custom command prompt is working
it's time to customize it.
You can change the color, font size or anything else.

These days we use git in most of our projects.
If we are using git then it's a good idea to know
which branch we are working on.
We can check what our current branch is but it
would be much nicer if the command prompt
displays the current branch automatically.
Here is how your command prompt would look after the instructions
mentioned in this page are followed.
Note that the current branch (master) is displayed in the command
prompt along with the directory name.
<pre><code>$ ~/code/bigbinary-website master
$
</code></pre>
<h2>Configurations of Custom Command Prompt</h2>
These instructions will work only if you are <a href="https://bigbinary.com/how-we-work/use-bash-shell">using bash shell</a>.
First let's create <code>~/.bashrc</code> file if it does not exist.
<pre><code>$ touch ~/.bashrc
</code></pre>
On command prompt execute <code>code ~/.bash_profile</code>.
Copy the existing content in clipboard.
Now execute <code>code ~/.bashrc</code>.
Past the content from <code>~/.bash_profile</code> to
the bottom of <code>~/.bashrc</code> file.
Now delete all the contents of <code>~/.bash_profile</code>.
Now put the following code in <code>~/.bash_profile</code>.
<pre><code>if [ -f ~/.bashrc ]; then
 source ~/.bashrc
fi
</code></pre>
Now open <code>~/.bashrc</code> and add the following content
at the bottom of the file.
<pre><code>txtblk='\e[0;30m' # Black - Regular
txtred='\e[0;31m' # Red
txtgrn='\e[0;32m' # Green
txtylw='\e[0;33m' # Yellow
txtblu='\e[0;34m' # Blue
txtpur='\e[0;35m' # Purple
txtcyn='\e[0;36m' # Cyan
txtwht='\e[0;37m' # White

bldblk='\e[1;30m' # Black - Bold
bldred='\e[1;31m' # Red
bldgrn='\e[1;32m' # Green
bldylw='\e[1;33m' # Yellow
bldblu='\e[1;34m' # Blue
bldpur='\e[1;35m' # Purple
bldcyn='\e[1;36m' # Cyan
bldwht='\e[1;37m' # White

unkblk='\e[4;30m' # Black - Underline
undred='\e[4;31m' # Red
undgrn='\e[4;32m' # Green
undylw='\e[4;33m' # Yellow
undblu='\e[4;34m' # Blue
undpur='\e[4;35m' # Purple
undcyn='\e[4;36m' # Cyan
undwht='\e[4;37m' # White

bakblk='\e[40m' # Black - Background
bakred='\e[41m' # Red
badgrn='\e[42m' # Green
bakylw='\e[43m' # Yellow
bakblu='\e[44m' # Blue
bakpur='\e[45m' # Purple
bakcyn='\e[46m' # Cyan
bakwht='\e[47m' # White

txtrst='\e[0m' # Text Reset

a=&quot;\n$txtwht\u$txtblu \w $txtpur&quot;
e=&quot;$\[\033[00m\] &quot;

function parse_git_url {
 git config --get remote.origin.url | sed 's/\.git$//;s/$.*[:/]$$[^/]*$\/$[^/]*$$\.git$\{0,1\}$/(\2\/\3)/'
}

function parse_git_branch {
 git branch 2&gt; /dev/null | sed -e '/^[^*]/d' -e 's/* $.*$/\1/'
}

function custom_git_prompt {
 branch=$(git branch 2&gt; /dev/null) || return
 echo &quot;$(parse_git_branch)&quot;
}

PS1=&quot;$a\$(custom_git_prompt)\n$e&quot;
</code></pre>
Now quit your shell and start a new shell.
You should see a new command prompt.
<h2>Customize to your choice</h2>
Now that your custom command prompt is working
it's time to customize it.
You can change the color, font size or anything else.

Configure Command Prompt



To find your git version execute command `git --version`.

If your git version is "2" or higher than you are good to go.
If not please upgrade your git version.

To find your git version execute command <code>git --version</code>.
If your git version is &quot;2&quot; or higher than you are good to go.
If not please upgrade your git version.

Setup: Use Git 2  | A book by BigBinary on How We Work.

Use git 2



Install VSCode from [here](https://code.visualstudio.com).

### Enable AutoSave

* Go to VSCode application
* Go to File which is next to VScode at the top left corner.
* Under File there is "Auto Save".
* Click on it so that a check mark appears next to it.
* Click on "File" again and this time there should be a check mark next to "Auto Save".

### Enable code command

* Go to VScode application
* Press "Shift" button, "Command" button and "p"
* Type > shell command
* Select "Install 'code' command in PATH
* VScode will give you a prompt. Click "Ok".
* VScode will ask for your laptop password. provide password.
* Now let's test if command "code" is working or not.
* Open terminal
* Type `code dummy.txt` on terminal. A dummy.txt file should open in VScode.

Install VSCode from <a href="https://code.visualstudio.com">here</a>.
<h3>Enable AutoSave</h3>
<ul>
<li>Go to VSCode application</li>
<li>Go to File which is next to VScode at the top left corner.</li>
<li>Under File there is &quot;Auto Save&quot;.</li>
<li>Click on it so that a check mark appears next to it.</li>
<li>Click on &quot;File&quot; again and this time there should be a check mark next to &quot;Auto Save&quot;.</li>
</ul>
<h3>Enable code command</h3>
<ul>
<li>Go to VScode application</li>
<li>Press &quot;Shift&quot; button, &quot;Command&quot; button and &quot;p&quot;</li>
<li>Type &gt; shell command</li>
<li>Select &quot;Install 'code' command in PATH</li>
<li>VScode will give you a prompt. Click &quot;Ok&quot;.</li>
<li>VScode will ask for your laptop password. provide password.</li>
<li>Now let's test if command &quot;code&quot; is working or not.</li>
<li>Open terminal</li>
<li>Type <code>code dummy.txt</code> on terminal. A dummy.txt file should open in VScode.</li>
</ul>

Setting up VScode



Execute this command to enable `autosetuprebase` in your environment:

```bash
git config --global branch.autosetuprebase always
```

[Check out this blog](http://www.kerrybuckley.org/2008/06/18/avoiding-merge-commits-in-git/)
to see how rebase avoids merge commits, and read this article
which explains
[why autosetuprebase is a good idea](http://gitready.com/advanced/2009/02/11/pull-with-rebase.html).


Execute this command to enable <code>autosetuprebase</code> in your environment:
<pre><code class="language-bash">git config --global branch.autosetuprebase always
</code></pre>
<a href="http://www.kerrybuckley.org/2008/06/18/avoiding-merge-commits-in-git/">Check out this blog</a>
to see how rebase avoids merge commits, and read this article
which explains
<a href="http://gitready.com/advanced/2009/02/11/pull-with-rebase.html">why autosetuprebase is a good idea</a>.

Setup: Use autosetuprebase | A book by BigBinary on How We Work.

Use autosetuprebase



There are two ways to install [PostgreSQL](https://www.postgresql.org/) in mac.

### Postgres.app

If you are using a Mac, [http://postgresapp.com](http://postgresapp.com) is an easy way to install PostgreSQL.

The `config/database.yml` file should like as shown 
[here](https://gist.github.com/neerajdotname/fa7096b327519aa3028a4045c52bee62).


## Installing PostgreSQL using homebrew

```
brew install postgresql
```

After install pg you can check the version you are running by executing `postgres -V`.

The `config/database.yml` file should like as shown
[here](https://gist.github.com/neerajdotname/c09a2346fdce525a770cd8729bb19926).



There are two ways to install <a href="https://www.postgresql.org/">PostgreSQL</a> in mac.
<h3>Postgres.app</h3>
If you are using a Mac, <a href="http://postgresapp.com">http://postgresapp.com</a> is an easy way to install PostgreSQL.
The <code>config/database.yml</code> file should like as shown
<a href="https://gist.github.com/neerajdotname/fa7096b327519aa3028a4045c52bee62">here</a>.
<h2>Installing PostgreSQL using homebrew</h2>
<pre><code>brew install postgresql
</code></pre>
After install pg you can check the version you are running by executing <code>postgres -V</code>.
The <code>config/database.yml</code> file should like as shown
<a href="https://gist.github.com/neerajdotname/c09a2346fdce525a770cd8729bb19926">here</a>.

Setup: Installing Postgresql | A book by BigBinary on How We Work.

Installing PostgreSQL



## Installing Ruby using rbenv

At BigBinary we recommend to use [rbenv](http://rbenv.org) to manage ruby versions.

On terminal execute the following command.

```
$ brew instal rbenv
```

Execute `code ~/.bashrc`.
At the bottom of the file add `eval "$(rbenv init -)"`.

Quit terminal and open a new terminal.
Execute `ruby intall 2.7.1` to install ruby 2.7.1. This will take sometime.
Please be patient.

Execute `rbenv init`.

Execute `rbenv global 2.7.1`.
Now you are all set.

## rbenv respects .ruby-version file

In your Rails application you will find a `.ruby-version` file.
This file contains the ruby version that the application is using.
When rbenv sees a `.ruby-version` file then rbenv reads that ruby version
from that file and sets up to use that version of ruby.

<h2>Installing Ruby using rbenv</h2>
At BigBinary we recommend to use <a href="http://rbenv.org">rbenv</a> to manage ruby versions.
On terminal execute the following command.
<pre><code>$ brew instal rbenv
</code></pre>
Execute <code>code ~/.bashrc</code>.
At the bottom of the file add <code>eval &quot;$(rbenv init -)&quot;</code>.
Quit terminal and open a new terminal.
Execute <code>ruby intall 2.7.1</code> to install ruby 2.7.1. This will take sometime.
Please be patient.
Execute <code>rbenv init</code>.
Execute <code>rbenv global 2.7.1</code>.
Now you are all set.
<h2>rbenv respects .ruby-version file</h2>
In your Rails application you will find a <code>.ruby-version</code> file.
This file contains the ruby version that the application is using.
When rbenv sees a <code>.ruby-version</code> file then rbenv reads that ruby version
from that file and sets up to use that version of ruby.

Setup: Installing Ruby  | A book by BigBinary on How We Work.

Installing ruby



You can find detailed information about how we use services
[here](https://www.bigbinary.com/videos/learn-ruby-on-rails/using-services-to-manage-code).

We also use carriers.
[Here](http://blog.bigbinary.com/2014/12/02/drying-up-rails-views-with-view-carriers-and-services.html)
is a blog describing how we use carriers.


You can find detailed information about how we use services
<a href="https://www.bigbinary.com/videos/learn-ruby-on-rails/using-services-to-manage-code">here</a>.
We also use carriers.
<a href="http://blog.bigbinary.com/2014/12/02/drying-up-rails-views-with-view-carriers-and-services.html">Here</a>
is a blog describing how we use carriers.

Coding: How We Use Services & Carriers | A book by BigBinary on How We Work.

How We Use Services & Carriers



Look at the example below.

```ruby
def set_new_api_key!
  reset_api_key
  save(validate: false)
end
```

When asked why validation was being skipped,
the programmer replied
that because the user record might be invalid,
the api might not be reset.

This attitude is incorrect.

We can't code in an environment of perpetual fear.

We can't code in an environment where we do not trust our data.

We must trust our data and our code to work as they should.
Having said that,
we need to take precautionary measures, just in case the data *is* invalid.

In this case, the code should be refactored to

```ruby
def set_new_api_key!
  reset_api_key
  save!
end
```

Now,
if the record *is* invalid,
we will receive feedback.
We will look over the code
and
the data and fix whatever necessary.

Do *not* live in fear - code confidently.

We encourage you to watch
[Confident Code presentation](https://www.youtube.com/watch?v=T8J0j2xJFgQ)
by Avdi Grimm.


Look at the example below.
<pre><code class="language-ruby">def set_new_api_key!
 reset_api_key
 save(validate: false)
end
</code></pre>
When asked why validation was being skipped,
the programmer replied
that because the user record might be invalid,
the api might not be reset.
This attitude is incorrect.
We can't code in an environment of perpetual fear.
We can't code in an environment where we do not trust our data.
We must trust our data and our code to work as they should.
Having said that,
we need to take precautionary measures, just in case the data is invalid.
In this case, the code should be refactored to
<pre><code class="language-ruby">def set_new_api_key!
 reset_api_key
 save!
end
</code></pre>
Now,
if the record is invalid,
we will receive feedback.
We will look over the code
and
the data and fix whatever necessary.
Do not live in fear - code confidently.
We encourage you to watch
<a href="https://www.youtube.com/watch?v=T8J0j2xJFgQ">Confident Code presentation</a>
by Avdi Grimm.

Coding: Do not live in fear - code confidently | A book by BigBinary on How We Work.

Trust data



[Difference between "or" and || in Ruby](http://stackoverflow.com/questions/2083112/difference-between-or-and-in-ruby)

[Difference between "and" and && in Ruby](https://stackoverflow.com/questions/1426826/difference-between-and-and-in-ruby)


<a href="http://stackoverflow.com/questions/2083112/difference-between-or-and-in-ruby">Difference between &quot;or&quot; and || in Ruby</a>
<a href="https://stackoverflow.com/questions/1426826/difference-between-and-and-in-ruby">Difference between &quot;and&quot; and &amp;&amp; in Ruby</a>

Coding: Do not use or & and in ruby because of lower precedence | A book by BigBinary on How We Work.

Do not use "or" & "and" in Ruby



Let's look at code.

```ruby
class UsageReportCarrier

  attr_reader :health_agency

  def initialize health_agency
    @health_agency = health_agency
  end

  def managers
    @managers ||= health_agency.health_agency_users
  end

end
```

In the above code method `managers` is using `memoization`.
However memoization like this makes code less confident
since `@` has a special meaning in ruby.
When we see `@managers`
we start thinking where else it is being used.
Is there an `attr_reader` for it or not.
Is someone directly messing with this instance variable.
Overall it gives impression that there might be more to it than just memoization.

In order to make the intent of memoization absolutely clear we prefer to use

```ruby
def managers
  @_managers ||= health_agency.health_agency_users
end
```

This makes it absolutely clear that here the intent of using `@` is just to do memoization and nothing else.

Let's look at code.
<pre><code class="language-ruby">class UsageReportCarrier

 attr_reader :health_agency

 def initialize health_agency
 @health_agency = health_agency
 end

 def managers
 @managers ||= health_agency.health_agency_users
 end

end
</code></pre>
In the above code method <code>managers</code> is using <code>memoization</code>.
However memoization like this makes code less confident
since <code>@</code> has a special meaning in ruby.
When we see <code>@managers</code>
we start thinking where else it is being used.
Is there an <code>attr_reader</code> for it or not.
Is someone directly messing with this instance variable.
Overall it gives impression that there might be more to it than just memoization.
In order to make the intent of memoization absolutely clear we prefer to use
<pre><code class="language-ruby">def managers
 @_managers ||= health_agency.health_agency_users
end
</code></pre>
This makes it absolutely clear that here the intent of using <code>@</code> is just to do memoization and nothing else.

Coding: Use underscore prefix for memoization | A book by BigBinary on How We Work.

Use underscore prefix for memoization



Let's look at the action `edit` in a controller.

```ruby
def edit
end
```

In the above method,
it is not clear
whether that method's implementation
is complete or not, since developers sometimes forget to complete the method.

Here is a way to remove that ambiguity.

If the implementation is complete,
then just add the word `render`.

```ruby
def edit
  render
end
```

Now, when one looks at the method,
it's clear that the developer did not forget anything.
The developer
is explicitly saying that
the only thing this method does is render the view.


Let's look at the action <code>edit</code> in a controller.
<pre><code class="language-ruby">def edit
end
</code></pre>
In the above method,
it is not clear
whether that method's implementation
is complete or not, since developers sometimes forget to complete the method.
Here is a way to remove that ambiguity.
If the implementation is complete,
then just add the word <code>render</code>.
<pre><code class="language-ruby">def edit
 render
end
</code></pre>
Now, when one looks at the method,
it's clear that the developer did not forget anything.
The developer
is explicitly saying that
the only thing this method does is render the view.

Convention: Do not leave action implementation blank | A book by BigBinary on How We Work.

Do not leave action implementation blank

It's common to have code like this in controllers:

```ruby
class HomeController < ApplicationController
 before_action :ensure_car_exists, only: [:index]
end
```

Note that, in this case,
the method name is `ensure_car_exists`.
Another possible name for it could be `verify_car_exists`.

Both names are good names - however, we have adopted a convention
that such method names should start with `ensure_`.

### Another example

```ruby
class HomeController < ApplicationController
 before_action :authenticate_admin
end
```

`:authenticate_admin` is a perfectly valid name.
However, we prefer `before_action :ensure_user_is_admin`.

It's common to have code like this in controllers:
<pre><code class="language-ruby">class HomeController &lt; ApplicationController
 before_action :ensure_car_exists, only: [:index]
end
</code></pre>
Note that, in this case,
the method name is <code>ensure_car_exists</code>.
Another possible name for it could be <code>verify_car_exists</code>.
Both names are good names - however, we have adopted a convention
that such method names should start with <code>ensure_</code>.
<h3>Another example</h3>
<pre><code class="language-ruby">class HomeController &lt; ApplicationController
 before_action :authenticate_admin
end
</code></pre>
<code>:authenticate_admin</code> is a perfectly valid name.
However, we prefer <code>before_action :ensure_user_is_admin</code>.

Convention: Ensure for before_action | A book by BigBinary on How We Work.

Ensure for before_action



We fully spell out variable names.

In the following case, variable `p` is used.
Looking at the code,
it takes the brain a few seconds to decipher
that `p` is an instance of model.

```ruby
validates_format_of :email, with: email_regex,
                  if: -> (p) { p.email.present? }
```

Here is the same code with `p` fully spelled out.

```ruby
validates_format_of :email, with: email_regex,
                  if: -> (patient) { patient.email.present? }
```


We fully spell out variable names.
In the following case, variable <code>p</code> is used.
Looking at the code,
it takes the brain a few seconds to decipher
that <code>p</code> is an instance of model.
<pre><code class="language-ruby">validates_format_of :email, with: email_regex,
 if: -&gt; (p) { p.email.present? }
</code></pre>
Here is the same code with <code>p</code> fully spelled out.
<pre><code class="language-ruby">validates_format_of :email, with: email_regex,
 if: -&gt; (patient) { patient.email.present? }
</code></pre>

Convention: Fully spell out variable names | A book by BigBinary on How We Work.

Fully spell out variable names



```ruby
project_notification_subscriber = @project.email_subscribers.first
```

In the above case the variable `project_notification_subscriber` is
holding the record of type `email_subscriber`. However that is not clear
from the variable name.

Instead variable name should have been as shown below.

```ruby
email_subscriber = @project.email_subscribers.first
```


<pre><code class="language-ruby">project_notification_subscriber = @project.email_subscribers.first
</code></pre>
In the above case the variable <code>project_notification_subscriber</code> is
holding the record of type <code>email_subscriber</code>. However that is not clear
from the variable name.
Instead variable name should have been as shown below.
<pre><code class="language-ruby">email_subscriber = @project.email_subscribers.first
</code></pre>

Convention: Variable names should match with domain | A book by BigBinary on How We Work.

Variable names should match with domain



As developers,
we know that it is extremely hard to come
to work on a `TODO` or `FIXME`.
However, there are circumstances where we do not
have the required time to take care of things properly;
hence the need for `FIXME` or `TODO`.

We believe a `FIXME` or a `TODO` without a GitHub issue has no meaning.

So, instead of having an old-fashioned comment like this:

```ruby
# FIXME: When user changes auto-reply from "on" to "off"
# then system will resend the request. It should not.
```

We prefer that developers create a GitHub issue
and
assign that issue
to himself/herself.
So now the comment would look like this:

```ruby
# FIXME: When user changes auto-reply from "on" to "off" then system
#        will resend the request. It should not.
#        Issue: https://github.com/bigbinary/wheel/issues/1
```

The bottom line is that a `FIXME` or a `TODO`
without a GitHub issue is meaningless.


As developers,
we know that it is extremely hard to come
to work on a <code>TODO</code> or <code>FIXME</code>.
However, there are circumstances where we do not
have the required time to take care of things properly;
hence the need for <code>FIXME</code> or <code>TODO</code>.
We believe a <code>FIXME</code> or a <code>TODO</code> without a GitHub issue has no meaning.
So, instead of having an old-fashioned comment like this:
<pre><code class="language-ruby"># FIXME: When user changes auto-reply from &quot;on&quot; to &quot;off&quot;
# then system will resend the request. It should not.
</code></pre>
We prefer that developers create a GitHub issue
and
assign that issue
to himself/herself.
So now the comment would look like this:
<pre><code class="language-ruby"># FIXME: When user changes auto-reply from &quot;on&quot; to &quot;off&quot; then system
# will resend the request. It should not.
# Issue: https://github.com/bigbinary/wheel/issues/1
</code></pre>
The bottom line is that a <code>FIXME</code> or a <code>TODO</code>
without a GitHub issue is meaningless.

Convention: FIXME and TODO | A book by BigBinary on How We Work.

FIXME and TODO

We prefer using `self.method_name` instead of the `class << self` way
of defining class methods.

```ruby
class Apple
 def is_green?
 end

 class << self
 def all_apples
 end
 end

 def another_method
 end
end
```

When reading this class with the number of methods defined,
it's hard to tell the difference between a class method and an instance method
when the methods are using `class << self`.

```ruby
class Apple
 def is_green?
 end

 def self.all_apples
 end

 def another_method
 end
end
```

Here, the class method is clearly defined and there is no ambiguity
when reading this class.
Moreover, it is now easier to refactor and maintain.

We prefer using <code>self.method_name</code> instead of the <code>class &lt;&lt; self</code> way
of defining class methods.
<pre><code class="language-ruby">class Apple
 def is_green?
 end

 class &lt;&lt; self
 def all_apples
 end
 end

 def another_method
 end
end
</code></pre>
When reading this class with the number of methods defined,
it's hard to tell the difference between a class method and an instance method
when the methods are using <code>class &lt;&lt; self</code>.
<pre><code class="language-ruby">class Apple
 def is_green?
 end

 def self.all_apples
 end

 def another_method
 end
end
</code></pre>
Here, the class method is clearly defined and there is no ambiguity
when reading this class.
Moreover, it is now easier to refactor and maintain.

Convention: Use self to declare class methods | A book by BigBinary on How We Work.

Use self to declare class methods



We prefer using `do..end` instead of `{}` when using ruby blocks.
`{}` is good when writing small one-liners or lambda, but  using `{}` frequently makes code skewed as well as harder to read.

```ruby
all_users.select {|user| user.is_admin? && user.is_team_member? && user.can_view_new_team_feature? }
```

Now, let's see the `do..end` version:

```ruby
all_users.select do |user|
  user.is_admin? && user.is_team_member? && user.can_view_new_team_feature?
end
```

It's easier to read than the one-liner version, and can be further simplified as below:

```ruby
all_users.select do |user|
  user.is_admin? &&
  user.is_team_member? &&
  user.can_view_new_team_feature?
end
```


We prefer using <code>do..end</code> instead of <code>{}</code> when using ruby blocks.
<code>{}</code> is good when writing small one-liners or lambda, but using <code>{}</code> frequently makes code skewed as well as harder to read.
<pre><code class="language-ruby">all_users.select {|user| user.is_admin? &amp;&amp; user.is_team_member? &amp;&amp; user.can_view_new_team_feature? }
</code></pre>
Now, let's see the <code>do..end</code> version:
<pre><code class="language-ruby">all_users.select do |user|
 user.is_admin? &amp;&amp; user.is_team_member? &amp;&amp; user.can_view_new_team_feature?
end
</code></pre>
It's easier to read than the one-liner version, and can be further simplified as below:
<pre><code class="language-ruby">all_users.select do |user|
 user.is_admin? &amp;&amp;
 user.is_team_member? &amp;&amp;
 user.can_view_new_team_feature?
end
</code></pre>

Convention: Prefer do end while creating blocks in ruby | A book by BigBinary on How We Work.

Prefer do end while creating blocks in ruby



We prefer 'if' conditional block over a trailing 'if' for multiline code.

For code with single line adding if condition at the end is definitely preferred
but for multiline code it makes it more readable and the developer
does not have to read the whole block of code only to realize that its conditional.


##### Example 1

Condition on multiline Code:

```ruby
#bad
def update
  return render json: {errors: "You can't to edit this directory"},
                status: :forbidden if @directory.master?
end

#preferred
def update
  if @directory.master?
    return render json: {errors: "You can't to edit this directory"},
                  status: :forbidden
  end
end
```


#### Example 2

Condition on block of code:

```ruby
#bad
10.times do
  # multi-line body omitted
end if some_condition

#preferred
if some_condition
  10.times do
    # multi-line body omitted
  end
end
```


We prefer 'if' conditional block over a trailing 'if' for multiline code.
For code with single line adding if condition at the end is definitely preferred
but for multiline code it makes it more readable and the developer
does not have to read the whole block of code only to realize that its conditional.
<h5>Example 1</h5>
Condition on multiline Code:
<pre><code class="language-ruby">#bad
def update
 return render json: {errors: &quot;You can't to edit this directory&quot;},
 status: :forbidden if @directory.master?
end

#preferred
def update
 if @directory.master?
 return render json: {errors: &quot;You can't to edit this directory&quot;},
 status: :forbidden
 end
end
</code></pre>
<h4>Example 2</h4>
Condition on block of code:
<pre><code class="language-ruby">#bad
10.times do
 # multi-line body omitted
end if some_condition

#preferred
if some_condition
 10.times do
 # multi-line body omitted
 end
end
</code></pre>

Convention: No trailing if for multiline code | A book by BigBinary on How We Work.

Prefer no trailing if for multiline code



Every project involves a number of players.

In all applications built by BigBinary you will find `oliver@example.com`.
Oliver is the owner of the product BigBinary is building.
In another words Oliver is the customer of BigBinary.

The customer of Oliver is `eve@example.com`.

For example let's say that BigBinary is built a Quiz application.
Oliver will be the customer of this Quiz application.
It means Oliver will create quizzes.
Now Oliver wants someone to take these quizzes.
May be Oliver is a teacher and his students will be taking the quiz.
We need a person who will be taking the quiz.
That would be Eve.
In another words Eve is the customer of Oliver.

Every project involves a number of players.
In all applications built by BigBinary you will find <code>oliver@example.com</code>.
Oliver is the owner of the product BigBinary is building.
In another words Oliver is the customer of BigBinary.
The customer of Oliver is <code>eve@example.com</code>.
For example let's say that BigBinary is built a Quiz application.
Oliver will be the customer of this Quiz application.
It means Oliver will create quizzes.
Now Oliver wants someone to take these quizzes.
May be Oliver is a teacher and his students will be taking the quiz.
We need a person who will be taking the quiz.
That would be Eve.
In another words Eve is the customer of Oliver.

Convention: Create users matching with the actors | A book by BigBinary on How We Work.

Oliver & Eve



We wrote a blog on [how to organize controllers in Ruby on Rails](https://blog.bigbinary.com/2009/02/17/restful-architecture-does-not-mean-one-to-one-mapping-with-model.html) sometime back.

We wrote a blog on <a href="https://blog.bigbinary.com/2009/02/17/restful-architecture-does-not-mean-one-to-one-mapping-with-model.html">how to organize controllers in Ruby on Rails</a> sometime back.

Convention: Organizing controllers in Ruby on Rails | A book by BigBinary on How We Work.

Organizing controllers



We at Bigbinary prefer using
attr_readers, attr_writers, attr_accessors etc.
instead of instance variables of the class wherever possible.

Consider the following examples

#### Approach #1

```ruby
class Calculator
  def initialize(number)
    @number = number
  end
  def increment
    @number + 1
  end
  def decrement
    @number - 1
  end
end
```

#### Approach #2

```ruby
class Calculator
  attr_reader :number
  def initialize(number)
    @number = number
  end
  def increment
    number + 1
  end
  def decrement
    number - 1
  end
end
```

While both the approaches give us desired results,
we advocate `Approach #2`.

Reasons by which we support our opinion are as follows -

- We feel directly accessing instance variable
 makes the code look dirty with less OO.

- We also feel that having attr_reader for the variables
  supports more abstraction i.e., one can tell difference
  between two objects of a class by virtue of these simple
  attribute reader methods.



We at Bigbinary prefer using
attr_readers, attr_writers, attr_accessors etc.
instead of instance variables of the class wherever possible.
Consider the following examples
<h4>Approach #1</h4>
<pre><code class="language-ruby">class Calculator
 def initialize(number)
 @number = number
 end
 def increment
 @number + 1
 end
 def decrement
 @number - 1
 end
end
</code></pre>
<h4>Approach #2</h4>
<pre><code class="language-ruby">class Calculator
 attr_reader :number
 def initialize(number)
 @number = number
 end
 def increment
 number + 1
 end
 def decrement
 number - 1
 end
end
</code></pre>
While both the approaches give us desired results,
we advocate <code>Approach #2</code>.
Reasons by which we support our opinion are as follows -
<ul>
<li>
We feel directly accessing instance variable
makes the code look dirty with less OO.
</li>
<li>
We also feel that having attr_reader for the variables
supports more abstraction i.e., one can tell difference
between two objects of a class by virtue of these simple
attribute reader methods.
</li>
</ul>

Convention: We prefer using attr_reader to instance variables | A book by BigBinary on How We Work.

Prefer using attr_readers, attr_writers



Let's start with code.

```javascript
import React, { useState } from "react";
import { Button } from "nitroui";
import classNames from "classnames";
function Dropdown({ options, onOptionSelect, chapter, lessonId }) {
}
```

Readability of the code mentioned above can be greatly enhanced by having
an empty line after all the import statements.

```javascript
import React, { useState } from "react";
import { Button } from "nitroui";
import classNames from "classnames";

function Dropdown({ options, onOptionSelect, chapter, lessonId }) {
}
```

Let's start with code.
<pre><code class="language-javascript">import React, { useState } from &quot;react&quot;;
import { Button } from &quot;nitroui&quot;;
import classNames from &quot;classnames&quot;;
function Dropdown({ options, onOptionSelect, chapter, lessonId }) {
}
</code></pre>
Readability of the code mentioned above can be greatly enhanced by having
an empty line after all the import statements.
<pre><code class="language-javascript">import React, { useState } from &quot;react&quot;;
import { Button } from &quot;nitroui&quot;;
import classNames from &quot;classnames&quot;;

function Dropdown({ options, onOptionSelect, chapter, lessonId }) {
}
</code></pre>

Empty line after the import statements

Let's start with code.

```javascript
{lessonIds && lessonIds[lessonIds.length - 1] != lesson.id ? (
 <Button
 className="mx-2"
 label="Next"
 onClick={() => handleNextButton(lesson.id)}
 />
) : null}
```

In the above case we can use `&&` and that would make code more readable and
we do not have to worry about returning a `null`.

```javascript
{lessonIds && lessonIds[lessonIds.length - 1] != lesson.id && (
 <Button
 className="mx-2"
 label="Next"
 onClick={() => handleNextButton(lesson.id)}
 />
)}
```

Let's start with code.
<pre><code class="language-javascript">{lessonIds &amp;&amp; lessonIds[lessonIds.length - 1] != lesson.id ? (
 &lt;Button
 className=&quot;mx-2&quot;
 label=&quot;Next&quot;
 onClick={() =&gt; handleNextButton(lesson.id)}
 /&gt;
) : null}
</code></pre>
In the above case we can use <code>&amp;&amp;</code> and that would make code more readable and
we do not have to worry about returning a <code>null</code>.
<pre><code class="language-javascript">{lessonIds &amp;&amp; lessonIds[lessonIds.length - 1] != lesson.id &amp;&amp; (
 &lt;Button
 className=&quot;mx-2&quot;
 label=&quot;Next&quot;
 onClick={() =&gt; handleNextButton(lesson.id)}
 /&gt;
)}
</code></pre>

Prefer && over ?



In software world for a variety of reasons developers are asked to have
an empty line at the end of the file.
[Here](https://stackoverflow.com/questions/2287967/why-is-it-recommended-to-have-empty-line-in-the-end-of-a-source-file)
are
[some](https://unix.stackexchange.com/questions/18743/whats-the-point-in-adding-a-new-line-to-the-end-of-a-file)
discussions around this.

The whole point of writing software is to eliminate repetitive nature of the job.
So it's quite surprising that a githook that will accomplish this task is not mainstream.

Couple of years back at BigBinary there was a vigrous debate about it and we decided to
not to enforce having an empty line at the end of the file.
So far we have not seen any issue because of that decision.

We do not think it is worth a PR reviewer's time to comment on having a mandatory empty line
at the end of the file.
This slows down the whole development cycle.
Reviewer will comment about it.
Developer will make the changes.
Reviewer will review it again.
All the tests will be executed again.
All that just to ensure that we have an empty line at the end of file which no one knows
why we are still using it.

So let's stop worrying about empty line at the end of the file.


In software world for a variety of reasons developers are asked to have
an empty line at the end of the file.
<a href="https://stackoverflow.com/questions/2287967/why-is-it-recommended-to-have-empty-line-in-the-end-of-a-source-file">Here</a>
are
<a href="https://unix.stackexchange.com/questions/18743/whats-the-point-in-adding-a-new-line-to-the-end-of-a-file">some</a>
discussions around this.
The whole point of writing software is to eliminate repetitive nature of the job.
So it's quite surprising that a githook that will accomplish this task is not mainstream.
Couple of years back at BigBinary there was a vigrous debate about it and we decided to
not to enforce having an empty line at the end of the file.
So far we have not seen any issue because of that decision.
We do not think it is worth a PR reviewer's time to comment on having a mandatory empty line
at the end of the file.
This slows down the whole development cycle.
Reviewer will comment about it.
Developer will make the changes.
Reviewer will review it again.
All the tests will be executed again.
All that just to ensure that we have an empty line at the end of file which no one knows
why we are still using it.
So let's stop worrying about empty line at the end of the file.

Empty line at the end of the file is not needed



Sometimes we need to fix data. There are two ways we can handle this.
We can write a rake task that would be executed only once. Or we can write a migration.

If we write a one time rake task then we need to remember to execute it after the deployment.
Sometimes we forget to run those rake tasks. Secondly there is an additional burdern of communicating
to the team that after the deployment execute the rake task.

If we write a migration to fix data then there is additional burden of communication.
However some folks do not like data fixes as migrations. They believe that migrations should only contain
schema changes and not data changes.

This topic is controversial and has been debated many times before.

At BigBinary
most of our applications are configured to automatically deploy when a PR is merged to master.
In such an environment using rake tasks becomes quite cumbersome.
Hence at BigBinary we choose to use migration to fix data.

Sometimes we need to fix data. There are two ways we can handle this.
We can write a rake task that would be executed only once. Or we can write a migration.
If we write a one time rake task then we need to remember to execute it after the deployment.
Sometimes we forget to run those rake tasks. Secondly there is an additional burdern of communicating
to the team that after the deployment execute the rake task.
If we write a migration to fix data then there is additional burden of communication.
However some folks do not like data fixes as migrations. They believe that migrations should only contain
schema changes and not data changes.
This topic is controversial and has been debated many times before.
At BigBinary
most of our applications are configured to automatically deploy when a PR is merged to master.
In such an environment using rake tasks becomes quite cumbersome.
Hence at BigBinary we choose to use migration to fix data.

One time rake task or a migration



Developers often take liberties when creating data in test files. It's true, the data doesn't matter.

Well, it doesn't matter to machines, but it does to humans.

Just because it's a test program doesn't mean that you should create nonsensical names.
Having meaningful names makes it easier to understand the business logic.

Here's a snippet of code from a test file:

``` ruby
EmailLog.create_from_payload( to: [ 'qwe1@example.com',
                                    'qwe2@example.com'],
                              from: ['support@example.com'])

```

I am not sure what `qwe1` and `qwe2` are supposed to mean here. It would be much better if the names were like the ones given below:

```ruby
EmailLog.create_from_payload( to: [ 'mike@example.com',
                                    'mary@example.com'],
                              from: ['support@example.com'])

```

### Another example of a meaningful name

```ruby
def test_email_is_normalized
  user = User.create! email: ' strAngeEmail@example.com'
  assert_equal 'strangeemail@example.com', user.email
end
```

In the above case, it is not clear why the email is strange. A better name would help.

```ruby
def test_email_is_normalized
  user = User.create! email: ' thisIsAMixedCaseEmail@example.com'
  assert_equal 'thisisamixedcaseemail@example.com', user.email
end
```


Developers often take liberties when creating data in test files. It's true, the data doesn't matter.
Well, it doesn't matter to machines, but it does to humans.
Just because it's a test program doesn't mean that you should create nonsensical names.
Having meaningful names makes it easier to understand the business logic.
Here's a snippet of code from a test file:
<pre><code class="language-ruby">EmailLog.create_from_payload( to: [ 'qwe1@example.com',
 'qwe2@example.com'],
 from: ['support@example.com'])

</code></pre>
I am not sure what <code>qwe1</code> and <code>qwe2</code> are supposed to mean here. It would be much better if the names were like the ones given below:
<pre><code class="language-ruby">EmailLog.create_from_payload( to: [ 'mike@example.com',
 'mary@example.com'],
 from: ['support@example.com'])

</code></pre>
<h3>Another example of a meaningful name</h3>
<pre><code class="language-ruby">def test_email_is_normalized
 user = User.create! email: ' strAngeEmail@example.com'
 assert_equal 'strangeemail@example.com', user.email
end
</code></pre>
In the above case, it is not clear why the email is strange. A better name would help.
<pre><code class="language-ruby">def test_email_is_normalized
 user = User.create! email: ' thisIsAMixedCaseEmail@example.com'
 assert_equal 'thisisamixedcaseemail@example.com', user.email
end
</code></pre>

Tests: Have meaningful name in tests | A book by BigBinary on How We Work.

Have meaningful name in tests



To execute all tests:

```ruby
rake
```

Running an individual test file:

```ruby
rake test test/models/comment_test.rb
```

Running an individual test in a test file:

```ruby
rake test test/models/comment_test.rb test_comment_sends_notification_to_user
```

To execute tests in models:

```ruby
rake test:models
```

To execute tests in controllers:

```ruby
rake test:controllers
```


To execute all tests:
<pre><code class="language-ruby">rake
</code></pre>
Running an individual test file:
<pre><code class="language-ruby">rake test test/models/comment_test.rb
</code></pre>
Running an individual test in a test file:
<pre><code class="language-ruby">rake test test/models/comment_test.rb test_comment_sends_notification_to_user
</code></pre>
To execute tests in models:
<pre><code class="language-ruby">rake test:models
</code></pre>
To execute tests in controllers:
<pre><code class="language-ruby">rake test:controllers
</code></pre>

Tests: Running tests | A book by BigBinary on How We Work.

Running tests



This section discusses external services we use.

## CircleCI for React Native testing

We use
[CircleCI](https://circleci.com/)
for running tests for React Native applications.

## Semaphore CI for running minitest

We use
[semaphore](https://semaphoreci.com/)
for running minitest.

## Heroku

We use
[Heroku](http://heroku.com/)
for deploying web applications.

Some projects have unique requirements,
and
for such cases, we do deploy applications at other service providers like Rackspace, Linode or DigitalOcean.

## S3

We use
[AWS S3](https://aws.amazon.com/s3)
for storing documents, pictures and videos.

## Honeybadger

We use
[Honeybadger](https://www.honeybadger.io)
for error tracking.

## DNSMadeEasy

We use
[DNS Made Easy](http://www.dnsmadeeasy.com/)
for DNS hosting.

## Cross Browser Testing

We use
[lambdatest](https://www.lambdatest.com)
for cross browser testing.

We also use the
[Microsoft virtual machines](https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/)
to test on Windows browsers.

## UptimeRobot for monitoring

We use
[UptimeRobot](https://uptimerobot.com/)
for monitoring our sites.

This section discusses external services we use.
<h2>CircleCI for React Native testing</h2>
We use
<a href="https://circleci.com/">CircleCI</a>
for running tests for React Native applications.
<h2>Semaphore CI for running minitest</h2>
We use
<a href="https://semaphoreci.com/">semaphore</a>
for running minitest.
<h2>Heroku</h2>
We use
<a href="http://heroku.com/">Heroku</a>
for deploying web applications.
Some projects have unique requirements,
and
for such cases, we do deploy applications at other service providers like Rackspace, Linode or DigitalOcean.
<h2>S3</h2>
We use
<a href="https://aws.amazon.com/s3">AWS S3</a>
for storing documents, pictures and videos.
<h2>Honeybadger</h2>
We use
<a href="https://www.honeybadger.io">Honeybadger</a>
for error tracking.
<h2>DNSMadeEasy</h2>
We use
<a href="http://www.dnsmadeeasy.com/">DNS Made Easy</a>
for DNS hosting.
<h2>Cross Browser Testing</h2>
We use
<a href="https://www.lambdatest.com">lambdatest</a>
for cross browser testing.
We also use the
<a href="https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/">Microsoft virtual machines</a>
to test on Windows browsers.
<h2>UptimeRobot for monitoring</h2>
We use
<a href="https://uptimerobot.com/">UptimeRobot</a>
for monitoring our sites.

External Services: This section discusses external services we use. | A book by BigBinary on How We Work.

External services



Create an issue in github only
if the issue can be acted upon by the developers
and
there are no unknowns.
If the feature is still 'under discussion',
then do not create a github issue.

A github issue is not a place for feature discussion - a github issue should be created
when, after discussion, it has been decided that a particular feature needs to be implemented.

Creating a good issue is an art in itself.

If the issue is about visual elements,
then we use
[Monosnap](https://monosnap.com/)
to take a screenshot.
And then we draw or write on the screenshot
to make it clear what the relevant bug or feature is.

After taking screenshots, we write what needs to be changed right there in the screenshot itself.
This makes it easier
to communicate with other team members about
the exact changes that need to be made. Here is an example of a screenshot
we recently used in a project:

![](/how-we-work/sortby.png)



Create an issue in github only
if the issue can be acted upon by the developers
and
there are no unknowns.
If the feature is still 'under discussion',
then do not create a github issue.
A github issue is not a place for feature discussion - a github issue should be created
when, after discussion, it has been decided that a particular feature needs to be implemented.
Creating a good issue is an art in itself.
If the issue is about visual elements,
then we use
<a href="https://monosnap.com/">Monosnap</a>
to take a screenshot.
And then we draw or write on the screenshot
to make it clear what the relevant bug or feature is.
After taking screenshots, we write what needs to be changed right there in the screenshot itself.
This makes it easier
to communicate with other team members about
the exact changes that need to be made. Here is an example of a screenshot
we recently used in a project:
<img src="/how-we-work/sortby.png" alt="">

Github: Creating an issue in github | A book by BigBinary on How We Work.

Creating an issue in github



In order to find
all the issues
assigned to yourself
visit
[github.com/issues/assigned](https://github.com/issues/assigned).

At BigBinary we convert an issue into pull request.
The pull requests assigned to you
will not be listed
if you visit the above mentioned link.

If you look at the query it would be something like as shown below.

```
is:open is:issue assignee:neerajdotname
```

Notice that the query is
explicitly looking for issues only.
By changing the query to

```
is:open assignee:neerajdotname
```

we can list
issues as well as pull requests assigned to me.
After changing the query
hit enter and
now you can bookmark the URL that you see.
This bookmark will always show you
all the issues and pull requests assigned to you.

_In the above shown code replace neerajdotname with your own github id_.


In order to find
all the issues
assigned to yourself
visit
<a href="https://github.com/issues/assigned">github.com/issues/assigned</a>.
At BigBinary we convert an issue into pull request.
The pull requests assigned to you
will not be listed
if you visit the above mentioned link.
If you look at the query it would be something like as shown below.
<pre><code>is:open is:issue assignee:neerajdotname
</code></pre>
Notice that the query is
explicitly looking for issues only.
By changing the query to
<pre><code>is:open assignee:neerajdotname
</code></pre>
we can list
issues as well as pull requests assigned to me.
After changing the query
hit enter and
now you can bookmark the URL that you see.
This bookmark will always show you
all the issues and pull requests assigned to you.
In the above shown code replace neerajdotname with your own github id.

Github: How to find all issues assigned to me | A book by BigBinary on How We Work.

How to find all issues assigned to me



GitHub issues are meant for communicating with other team members.

We also use slack 
so
there can be some confusion about whether to ask a question 
or 
to post a comment 
in slack or in GitHub.

Here is a simple rule to remember.
If you are not sure about which one to use then
use GitHub issues.

Let's assume that on a particular issue there is a lot of back and forth
in github. In such cases it is better to jump on slack and resolve
it there through a real time communication.
However slack should be used as a last resort
and
not the first tool to reach.

Some people do all their communication via slack.
We do not recommend that.
Communications related to GitHub issues should primarily happen in GitHub issues.


GitHub issues are meant for communicating with other team members.
We also use slack
so
there can be some confusion about whether to ask a question
or
to post a comment
in slack or in GitHub.
Here is a simple rule to remember.
If you are not sure about which one to use then
use GitHub issues.
Let's assume that on a particular issue there is a lot of back and forth
in github. In such cases it is better to jump on slack and resolve
it there through a real time communication.
However slack should be used as a last resort
and
not the first tool to reach.
Some people do all their communication via slack.
We do not recommend that.
Communications related to GitHub issues should primarily happen in GitHub issues.

Github: Prefer Github over Slack | A book by BigBinary on How We Work.

Prefer github over slack for communicating



When we start working on an issue,
we create
a branch for that issue.

The branch name must start with the issue number.

For example,
if the github issue number is 184
and
if the issue is about "building sales report"
then the branch name could be
`184-build-sales-report`.

The important thing is
that the branch name must start with issue number.
After the issue number the text is only to gently
refer what this issue is about.


When we start working on an issue,
we create
a branch for that issue.
The branch name must start with the issue number.
For example,
if the github issue number is 184
and
if the issue is about &quot;building sales report&quot;
then the branch name could be
<code>184-build-sales-report</code>.
The important thing is
that the branch name must start with issue number.
After the issue number the text is only to gently
refer what this issue is about.

Github: Create branch starting with issue number | A book by BigBinary on How We Work.

Create branch starting with issue number



The issue number should not be mentioned in the title of the PR.
Here is an example of a PR where title has the issue number.

```
17 Added billing feature
```

PR title is not the place to mention which issue this PR is fixing.
The place for that is in the body of the PR.

A better PR title would be following.

```
Added billing feature
```

In the body of the PR one could add following info.

```
fixes #17
```

The issue number should not be mentioned in the title of the PR.
Here is an example of a PR where title has the issue number.
<pre><code>17 Added billing feature
</code></pre>
PR title is not the place to mention which issue this PR is fixing.
The place for that is in the body of the PR.
A better PR title would be following.
<pre><code>Added billing feature
</code></pre>
In the body of the PR one could add following info.
<pre><code>fixes #17
</code></pre>

Do not mention issue number in the title of PR | A book by BigBinary on How We Work.

Do not mention issue number in the title of PR



When a PR is merged then that PR is closed.
However we want the corresponding issue to be closed too at the same time.

In the body of the PR we can mention the issue that this PR closes.
This can be done like this.
Any of the following two options works.

```
Fixes #100
Closes #100
```

If the PR closes multiple issues then all those issues can be mentioned.

```
Fixes #100, Fixes #103
```

[Github doc](https://docs.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue)
has more details on this.

When a PR is merged then that PR is closed.
However we want the corresponding issue to be closed too at the same time.
In the body of the PR we can mention the issue that this PR closes.
This can be done like this.
Any of the following two options works.
<pre><code>Fixes #100
Closes #100
</code></pre>
If the PR closes multiple issues then all those issues can be mentioned.
<pre><code>Fixes #100, Fixes #103
</code></pre>
<a href="https://docs.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue">Github doc</a>
has more details on this.

PR should mention fixes or closes issue number | A book by BigBinary on How We Work.

PR should mention fixes or closes issue number



Pull requests get stale very fast, and they need to be rebased often.
Please note that they need to be **rebased**. This is not same as
merging `master` to your branch. Please read
[this article](https://www.atlassian.com/git/tutorials/merging-vs-rebasing)
to gain a better understanding of the difference between `git rebase`
and `git merge master`.

Rebasing a pull request can be complicated sometimes because of merge conflicts.

If you know how to rebase, then that's great!

If not, here's another way to handle
[this issue in the least complicated way](https://bigbinary.com/videos/misc/git-how-to-rebase-without-complications).


Pull requests get stale very fast, and they need to be rebased often.
Please note that they need to be rebased. This is not same as
merging <code>master</code> to your branch. Please read
<a href="https://www.atlassian.com/git/tutorials/merging-vs-rebasing">this article</a>
to gain a better understanding of the difference between <code>git rebase</code>
and <code>git merge master</code>.
Rebasing a pull request can be complicated sometimes because of merge conflicts.
If you know how to rebase, then that's great!
If not, here's another way to handle
<a href="https://bigbinary.com/videos/misc/git-how-to-rebase-without-complications">this issue in the least complicated way</a>.

Github: How to rebase | A book by BigBinary on How We Work.

How to Rebase a pull request



Different organizations have different workflow.

We at BigBinary merge all pull requests into "master" branch. At any
time "master" branch is the "source of truth" for us.

We mostly use heroku as our deployment platform. Using the heroku pipeline feature
we merge code to both staging and production when a PR is merged to master.
Staging instance and production instance pick up their code from "master" branch.

Different organizations have different workflow.
We at BigBinary merge all pull requests into &quot;master&quot; branch. At any
time &quot;master&quot; branch is the &quot;source of truth&quot; for us.
We mostly use heroku as our deployment platform. Using the heroku pipeline feature
we merge code to both staging and production when a PR is merged to master.
Staging instance and production instance pick up their code from &quot;master&quot; branch.

Github: Three Branches | A book by BigBinary on How We Work.

Pull requests are merged in master



Github, by default, notifies each of the team members of the activities
in the repository. This is not desired when you are not active in that
repository.  To escape from unnecessary emails, github allows one to change
"notification settings" for the repository.

By default *notification* is set to **Watching**. In all cases you pretty
much want to switch to *Not watching* if you are not active in that
repository.

![](/how-we-work/unwatch_git_notifications.png)

When you switch to "Not Watching" then you are notified of email, only
when someone pings you by using '@' or when an issue is assigned to you.

Please do not (yes do not) switch to "Ignoring".
If you do that then you will not get any email notification when someone
wants your attention.

## Turn off unnecessary github notifications

You are encouraged to turn off unnecessary notifications.
So do not feel that you will miss out on something that you should know if you do not keep notifications "on" for any repository.
Don't have [FOMO](https://en.wikipedia.org/wiki/Fear_of_missing_out) .

If you need to know something then it will be communicated to you explicitly either via email or via basecamp. You should NOT turn off notifications from basecamp. Again keep the notifications from basecamp "ON".

Github, by default, notifies each of the team members of the activities
in the repository. This is not desired when you are not active in that
repository. To escape from unnecessary emails, github allows one to change
&quot;notification settings&quot; for the repository.
By default notification is set to Watching. In all cases you pretty
much want to switch to Not watching if you are not active in that
repository.
<img src="/how-we-work/unwatch_git_notifications.png" alt="">
When you switch to &quot;Not Watching&quot; then you are notified of email, only
when someone pings you by using '@' or when an issue is assigned to you.
Please do not (yes do not) switch to &quot;Ignoring&quot;.
If you do that then you will not get any email notification when someone
wants your attention.
<h2>Turn off unnecessary github notifications</h2>
You are encouraged to turn off unnecessary notifications.
So do not feel that you will miss out on something that you should know if you do not keep notifications &quot;on&quot; for any repository.
Don't have <a href="https://en.wikipedia.org/wiki/Fear_of_missing_out">FOMO</a> .
If you need to know something then it will be communicated to you explicitly either via email or via basecamp. You should NOT turn off notifications from basecamp. Again keep the notifications from basecamp &quot;ON&quot;.

Github: Control notification emails from github | A book by BigBinary on How We Work.

Control notification emails from github



Let's say that I'm writing a blog and I need to link to a newly added
file. I can link to that file by going to github and copying the url.
However a few months later that file might have moved to a different
directory and now the link is broken.

Github team created a shortcut to solve this problem. Just hit y on your
keyboard before copying the url.

Here is an example.

Let's say that I am linking to newly created `rake_proxy.rb` file in
Rails 5. If I go to the file in master and copy the url then url looks
like as shown below.

```
https://github.com/rails/rails/blob/master/railties/lib/rails/commands/rake_proxy.rb
```

As you can see the url is pointing file in master branch. As stated
above the problem is that this link is pointing to live master branch
and if a few months later this file is moved to some other place then
link will be broken.

Now let's see what happens when I hit y on my keyboard. The url will
change to as shown below.

```
https://github.com/rails/rails/blob/f718e52bcce02bc137263ead3a9d9f5df1c42c37/railties/lib/rails/commands/rake_proxy.rb
```

This url is pointing to a blob and not to master branch. This URL will
always work.


Let's say that I'm writing a blog and I need to link to a newly added
file. I can link to that file by going to github and copying the url.
However a few months later that file might have moved to a different
directory and now the link is broken.
Github team created a shortcut to solve this problem. Just hit y on your
keyboard before copying the url.
Here is an example.
Let's say that I am linking to newly created <code>rake_proxy.rb</code> file in
Rails 5. If I go to the file in master and copy the url then url looks
like as shown below.
<pre><code>https://github.com/rails/rails/blob/master/railties/lib/rails/commands/rake_proxy.rb
</code></pre>
As you can see the url is pointing file in master branch. As stated
above the problem is that this link is pointing to live master branch
and if a few months later this file is moved to some other place then
link will be broken.
Now let's see what happens when I hit y on my keyboard. The url will
change to as shown below.
<pre><code>https://github.com/rails/rails/blob/f718e52bcce02bc137263ead3a9d9f5df1c42c37/railties/lib/rails/commands/rake_proxy.rb
</code></pre>
This url is pointing to a blob and not to master branch. This URL will
always work.

Github: Hit y before copying url from github | A book by BigBinary on How We Work.

Hit y before copying url from github



When you are taking a screenshot to create an issue,
make sure that the URL of the site is visible.
That URL helps developers get quickly to the page
which is not behaving correctly.

Here is an example of a screenshot in which the URL is *not* visible:

![](/how-we-work/no_url.png)

And here's an example of a screenshot in which the URL is clearly visible:

![](/how-we-work/yes_url.png)


When you are taking a screenshot to create an issue,
make sure that the URL of the site is visible.
That URL helps developers get quickly to the page
which is not behaving correctly.
Here is an example of a screenshot in which the URL is not visible:
<img src="/how-we-work/no_url.png" alt="">
And here's an example of a screenshot in which the URL is clearly visible:
<img src="/how-we-work/yes_url.png" alt="">

Github: Take screenshots with a URL | A book by BigBinary on How We Work.

Take screenshot with the URL



## What is an epic issue?

Certain issues are too big to be handled in a single PR.
These issues are tagged with label "epic" either by the developer or the tech lead.

## How to work with an epic issue?

Divide the original problem into multiple issues.
Each sub-issue should mention `Ref issue ####`.
In this way, Github will automatically link a child issue
with its epic issue.

Now, work on these child issues and send PR to close these child issues.

Once all the sub-issues are closed, then assign the epic issue to a QA person.
An issue tagged with "epic" should never be closed by a PR. It should be closed
manually by a QA.

<h2>What is an epic issue?</h2>
Certain issues are too big to be handled in a single PR.
These issues are tagged with label &quot;epic&quot; either by the developer or the tech lead.
<h2>How to work with an epic issue?</h2>
Divide the original problem into multiple issues.
Each sub-issue should mention <code>Ref issue ####</code>.
In this way, Github will automatically link a child issue
with its epic issue.
Now, work on these child issues and send PR to close these child issues.
Once all the sub-issues are closed, then assign the epic issue to a QA person.
An issue tagged with &quot;epic&quot; should never be closed by a PR. It should be closed
manually by a QA.

Github: Epic Tag | A book by BigBinary on How We Work.

Epic Tag



In this document we are assuming that
the name of the application is `wheel`.
The name of staging instance is `wheel-staging`
and
the name of production instance is `wheel-production`.


### Find database url for each of the applications

Here is output of executing `heroku config -a wheel-production`.

```md
DATABASE_URL:
postgres://xgummbtqualf:643a810372e8decc30a7e99f715df6495ea0a5640ffcb3271ab39adae30fa5@ec2-184-73-247-240.compute-1.amazonaws.com:5432/d4sua6eoj2tq


HEROKU_POSTGRESQL_ROSE_URL: 
postgres://xgummbtqualf:643a810372e8decc30a7e99f715df6495ea0a5640ffcb3271ab39adae30fa5@ec2-184-73-247-240.compute-1.amazonaws.com:5432/d4sua6eoj2tq
```

Notice that in the above case we see both `DATABASE_URL` and `HEROKU_POSTGRESQL_ROSE_URL`.
Also notice that both of them have the same value.
Names like `DATABASE_URL` or `HEROKU_POSTGRESQL_ROSE_URL` are just keys to the actual value.
Some applications have names like `HEROKU_POSTGRESQL_COBALT_URL`.

In this example we will assume that production instance has `ROSE` name 
and 
the staging instance has `COBALT` name.
Before executing the actual command please make the change in name as per the values in your application.

### Copy production data to staging

Following code will copy data from production instance to staging instance.
Don't worry before the data is destroyed heroku will prompt you for confirmation.

```
heroku pg:copy wheel-production::HEROKU_POSTGRESQL_ROSE_URL HEROKU_POSTGRESQL_COBALT_URL -a wheel-staging
```


In this document we are assuming that
the name of the application is <code>wheel</code>.
The name of staging instance is <code>wheel-staging</code>
and
the name of production instance is <code>wheel-production</code>.
<h3>Find database url for each of the applications</h3>
Here is output of executing <code>heroku config -a wheel-production</code>.
<pre><code class="language-md">DATABASE_URL:
postgres://xgummbtqualf:643a810372e8decc30a7e99f715df6495ea0a5640ffcb3271ab39adae30fa5@ec2-184-73-247-240.compute-1.amazonaws.com:5432/d4sua6eoj2tq


HEROKU_POSTGRESQL_ROSE_URL: 
postgres://xgummbtqualf:643a810372e8decc30a7e99f715df6495ea0a5640ffcb3271ab39adae30fa5@ec2-184-73-247-240.compute-1.amazonaws.com:5432/d4sua6eoj2tq
</code></pre>
Notice that in the above case we see both <code>DATABASE_URL</code> and <code>HEROKU_POSTGRESQL_ROSE_URL</code>.
Also notice that both of them have the same value.
Names like <code>DATABASE_URL</code> or <code>HEROKU_POSTGRESQL_ROSE_URL</code> are just keys to the actual value.
Some applications have names like <code>HEROKU_POSTGRESQL_COBALT_URL</code>.
In this example we will assume that production instance has <code>ROSE</code> name
and
the staging instance has <code>COBALT</code> name.
Before executing the actual command please make the change in name as per the values in your application.
<h3>Copy production data to staging</h3>
Following code will copy data from production instance to staging instance.
Don't worry before the data is destroyed heroku will prompt you for confirmation.
<pre><code>heroku pg:copy wheel-production::HEROKU_POSTGRESQL_ROSE_URL HEROKU_POSTGRESQL_COBALT_URL -a wheel-staging
</code></pre>

Heroku: Copy production data to staging | A book by BigBinary on How We Work.

Copy production data to staging



Please refer to 
[previous article](https://how-we-work.bigbinary.com/heroku/copy-production-data-to-staging.html)
to understand the names we are using in this article.

### First take a backup

```
heroku pg:backups:capture -a wheel-staging
```

### Download the backup file

```
heroku pg:backups:download -a wheel-staging
```

It will download a file called `latest.dump`.

### Update local database with downloaded file

```
pg_restore --verbose --clean --no-owner --no-privileges --dbname=wheel_development latest.dump
```

In the above case replace `wheel_development` with the name of the database you have.

### Errors

You might get error something siimilar to as shown below.

```
pg_restore: [archiver] unsupported version (1.13) in file header
```

It probably means that the version of `pg_dump` used by heroku is not as the version we are running locally.

First let's check the version running in heroku.

```
> heroku run bash -a wheel-staging
> pg_dump --version

pg_dump (PostgreSQL) 10.3 (Ubuntu 10.3-1.pgdg14.04+1)
```

It seems heroku is using version 10.3.

Now let's check our local version of `pg_restore`.

```
> pg_restore --version

pg_restore (PostgreSQL) 10.0
```

As we can see that heroku used `pg_dump` version "10.3".
Our `pg_restore` version is "10.0"

Time to upgrade postgresql. Execute `brew upgrade postgresql`.


Please refer to
<a href="https://how-we-work.bigbinary.com/heroku/copy-production-data-to-staging.html">previous article</a>
to understand the names we are using in this article.
<h3>First take a backup</h3>
<pre><code>heroku pg:backups:capture -a wheel-staging
</code></pre>
<h3>Download the backup file</h3>
<pre><code>heroku pg:backups:download -a wheel-staging
</code></pre>
It will download a file called <code>latest.dump</code>.
<h3>Update local database with downloaded file</h3>
<pre><code>pg_restore --verbose --clean --no-owner --no-privileges --dbname=wheel_development latest.dump
</code></pre>
In the above case replace <code>wheel_development</code> with the name of the database you have.
<h3>Errors</h3>
You might get error something siimilar to as shown below.
<pre><code>pg_restore: [archiver] unsupported version (1.13) in file header
</code></pre>
It probably means that the version of <code>pg_dump</code> used by heroku is not as the version we are running locally.
First let's check the version running in heroku.
<pre><code>&gt; heroku run bash -a wheel-staging
&gt; pg_dump --version

pg_dump (PostgreSQL) 10.3 (Ubuntu 10.3-1.pgdg14.04+1)
</code></pre>
It seems heroku is using version 10.3.
Now let's check our local version of <code>pg_restore</code>.
<pre><code>&gt; pg_restore --version

pg_restore (PostgreSQL) 10.0
</code></pre>
As we can see that heroku used <code>pg_dump</code> version &quot;10.3&quot;.
Our <code>pg_restore</code> version is &quot;10.0&quot;
Time to upgrade postgresql. Execute <code>brew upgrade postgresql</code>.

Heroku: Download staging data to local machine | A book by BigBinary on How We Work.

Download staging data to local machine



We write
[blog](http://blog.bigbinary.com)
using
[ventilated prose style](http://vanemden.wordpress.com/2009/01/01/ventilated-prose/).
For example,
for the
[Author information in jekyll blog](http://blog.bigbinary.com/2015/01/09/author-information-in-jekyll-blog.html),
we wrote it
as given below.
In the sample
shown below,
we have removed all code examples
since we want to show
how sentences are written
and
not code.


```md
---
layout: post
title: Author information in jekyll blog
categories: [ruby]
author_github: neerajdotname
---

BigBinary's
[blog](http://blog.bigbinary.com)
is powered by
[jekyll](http://jekyllrb.com).
In every blog we display author's name,
author's twitter handle,
author's github id
and
author's avatar.
In this blog
I'm going to discuss
how we collect all that information
in a simple manner.

We create a directory called ___data__
in the root folder.
This directory has a single file called __authors.yml__
which in our case looks like this.

We do not need
to do anything to load __authors.yml__ .
It is automatically loaded
by jekyll.

When we create a blog
then the top of the blog looks like this.

Notice the last line
where we have put in the author's github id.
That's the identifier we use
to pull in author's information.

In order to display author's name
we have following code
in the layout.

Similary to display author's twitter handle
and
github id
we have following code.

Now the blog will display the author information
and
all this information
is nicely centralized
in one single file.
```

This style of writing
is also called
'[Semantic linefeed](http://rhodesmill.org/brandon/2012/one-sentence-per-line/)'.
That article
has lots of comments, and you can see even more discussion
on
[hacker news](https://news.ycombinator.com/item?id=4642395).


Here are some simple rules we follow.

* Put a link in its own line.
That line should have just the link
and
nothing else.

* Always start a new stentence after line break.

* Try to give **and** a line of its own.
The advantage is that anything can be added
before and easily without changing the whole line.

We are less concerned about where to break the sentences.
**We care more about not having long sentences**.

This style of writing
has helped us
keep sentences short
and
meaningful.


We write
<a href="http://blog.bigbinary.com">blog</a>
using
<a href="http://vanemden.wordpress.com/2009/01/01/ventilated-prose/">ventilated prose style</a>.
For example,
for the
<a href="http://blog.bigbinary.com/2015/01/09/author-information-in-jekyll-blog.html">Author information in jekyll blog</a>,
we wrote it
as given below.
In the sample
shown below,
we have removed all code examples
since we want to show
how sentences are written
and
not code.
<pre><code class="language-md">---
layout: post
title: Author information in jekyll blog
categories: [ruby]
author_github: neerajdotname
---

BigBinary's
[blog](http://blog.bigbinary.com)
is powered by
[jekyll](http://jekyllrb.com).
In every blog we display author's name,
author's twitter handle,
author's github id
and
author's avatar.
In this blog
I'm going to discuss
how we collect all that information
in a simple manner.

We create a directory called ___data__
in the root folder.
This directory has a single file called __authors.yml__
which in our case looks like this.

We do not need
to do anything to load __authors.yml__ .
It is automatically loaded
by jekyll.

When we create a blog
then the top of the blog looks like this.

Notice the last line
where we have put in the author's github id.
That's the identifier we use
to pull in author's information.

In order to display author's name
we have following code
in the layout.

Similary to display author's twitter handle
and
github id
we have following code.

Now the blog will display the author information
and
all this information
is nicely centralized
in one single file.
</code></pre>
This style of writing
is also called
'<a href="http://rhodesmill.org/brandon/2012/one-sentence-per-line/">Semantic linefeed</a>'.
That article
has lots of comments, and you can see even more discussion
on
<a href="https://news.ycombinator.com/item?id=4642395">hacker news</a>.
Here are some simple rules we follow.
<ul>
<li>
Put a link in its own line.
That line should have just the link
and
nothing else.
</li>
<li>
Always start a new stentence after line break.
</li>
<li>
Try to give and a line of its own.
The advantage is that anything can be added
before and easily without changing the whole line.
</li>
</ul>
We are less concerned about where to break the sentences.
We care more about not having long sentences.
This style of writing
has helped us
keep sentences short
and
meaningful.

Blog Writing: Write blog using ventilated prose style | A book by BigBinary on How We Work.

Write blog using ventilated prose style



There are so many way one can write a blog.

After showing some code one can write

```
1. As you can see here ...
```

```
2. As you have seen here ...
```

```
3. As I have shown you here ...
```

```
4. It should be noted here that ..
```

```
5. As we can see ...
```

All of them are correct form of writing a blog. However as a company we
need to have consistency between one blog and another so that different
authors of the blog do not follow entirely different style.

We prefer to use `we`. So we will go with

```
As we can see
```




There are so many way one can write a blog.
After showing some code one can write
<pre><code>1. As you can see here ...
</code></pre>
<pre><code>2. As you have seen here ...
</code></pre>
<pre><code>3. As I have shown you here ...
</code></pre>
<pre><code>4. It should be noted here that ..
</code></pre>
<pre><code>5. As we can see ...
</code></pre>
All of them are correct form of writing a blog. However as a company we
need to have consistency between one blog and another so that different
authors of the blog do not follow entirely different style.
We prefer to use <code>we</code>. So we will go with
<pre><code>As we can see
</code></pre>

Blog Writing: Use we | A book by BigBinary on How We Work.

Use we



In the blog,
it's always better to provide
realistic example
rather than
using
`foo`, `bar` & `baz`.

Here is an example.

```
Rails.cache.write_multi foo: 'bar', baz: 'qux'
```

Above code
could also be written as

```
Rails.cache.write_multi name: 'Alan Turnig', country: 'England'
```

In the blog,
it's always better to provide
realistic example
rather than
using
<code>foo</code>, <code>bar</code> &amp; <code>baz</code>.
Here is an example.
<pre><code>Rails.cache.write_multi foo: 'bar', baz: 'qux'
</code></pre>
Above code
could also be written as
<pre><code>Rails.cache.write_multi name: 'Alan Turnig', country: 'England'
</code></pre>

Blog Writing: Do not use foo, bar & baz | A book by BigBinary on How We Work.

Do not use foo, bar & baz



Please send your feedback to
**hello@BigBinary.com**.
We are on twitter at [@BigBinary](http://twitter.com/bigbinary).

This ebook has been created, edited and published by the [BigBinary](https://bigbinary.com) team members.


Please send your feedback to
hello@BigBinary.com.
We are on twitter at <a href="http://twitter.com/bigbinary">@BigBinary</a>.
This ebook has been created, edited and published by the <a href="https://bigbinary.com">BigBinary</a> team members.

San Jose, USA

Pune, India

Do not mention issue number in the title of PR