levi – redpanthers.co / Red Panthers - Experts in Ruby on Rails, System Design and Vue.js Mon, 29 Apr 2019 11:28:12 +0000 en-US hourly 1 https://wordpress.org/?v=5.2.7 Rails 5.2.0 /rails-5-2-0/ Mon, 29 Apr 2019 11:28:12 +0000 http://redpanthers.co/?p=16152 ]]> Cheers everyone, the new Rails 5.2.0 has released. Let’s have a look at the new features and upgrades in it.

It’s been too hard to deal with file uploads in Rails. There’s been a lot of fine plugins available, but it was overdue that we incorporated something right into the framework. Finally, we have one, in the form of Active Storage. This release includes Active Storage, a new framework provided by Rails to make it easier to upload and process files. With this new framework, we’ve solved for the modern approach of uploading files straight to the cloud. Out of the box, there’s support for Amazon’s S3, Google’s Cloud Storage, and Microsoft Azure Cloud File Storage. If you’re dealing with images, you can create variants on the fly. If you’re dealing with videos or PDFs, you can create previews on the fly. And regardless of the type, you can analyze uploads for metadata extraction asynchronously. This framework is not only used in production, but it is born for production.

There’s a sparkling new Redis Cache Storage that incorporates general partial, fragment, and other Rails caching jobs into a cohesive unit that anyone can use.

This new Redis Cache Store supports Redis::Distributed, for Memcached-like sharding across Redises. It’s fault tolerant, so will treat failures like misses, rather than kill the request with an exception. It even supports distributed MGETs for that full partial collection caching goodness.

Rails 5.2.0 has Added support for PostgreSQL operator classes to add_index. The operator classes identify database operators to be used by the index for the columns. You can assign the same operator to all columns, or not. It currently only supports PostgreSQL.

Added ability to create PostgreSQL foreign keys without validation. Normally, PostgreSQL verifies that all rows in a table satisfy its foreign keys constraints. With this option, you can create these constraints without the overhead of checking if they are valid.

Rails 5.2.0 also has embraced the cherry of HTTP/2 with early hints. This means we can automatically instruct the web server to send required style sheet and JavaScript assets early. This means a faster page delivery.

On the topic of performance, Rails now ships with Bootsnap in the default Gemfile. This generally reduces application boot times by over 50%.

 CSRF and XSS have enhanced that further in Rails 5.2 with the addition of a new DSL that allows you to configure a Content Security Policy for your application. We can configure a global default policy and then override it on a per-resource basis and even use lambdas to inject per-request values into the header such as account subdomains in a multi-tenant application.

In Rails 5.2, we’ve rectified the mess by deprecating the two different kinds of secrets and introduced a new shared concept called Credentials. Credentials, like AWS access keys and other forms of logins and passwords, were the dominant use case for secrets. Credentials are always encrypted. This means they’re safe to check into revision control, as long as you keep the key out of it. This means atomic deploys and there is no need to mess with environment variables.

Since Rails 5.1, we’ve also made great strides with Webpacker. So Rails 5.2 is meant to pair beautifully with the new Webpacker 3.0 release. Rails have fully embraced modern JavaScript with a pre-configured build pipeline run by Webpack. We keep strengthening that relationship.

Thanks again to everyone who continue to pour their love and support into Ruby on Rails! Happy Coding.

]]>

]]> Setting up your own private GIT server /setting-up-your-own-private-git-server/ Mon, 29 Apr 2019 11:28:11 +0000 http://redpanthers.co/?p=16369 ]]> git user and a .ssh directory for the user. Follow the commands given below. 
$ sudo adduser git
$ su git
$ cd
$ mkdir .ssh && chmod 700 .ssh
$ touch .ssh/authorized_keys && chmod 600 .ssh/authorized_keys
  Let’s add some SSH keys to the authorized_keys file for the git user. They should be like 
$ cat /tmp/id_rsa.john.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCB007n/ww+ouN4gSLKssMxXnBOvf9LGt4L
ojG6rs6hPB09j9R/T17/x4lhJA0F3FR1rP6kYBRsWj2aThGw6HXLm9/5zytK6Ztg3RPKK+4k
Yjh6541NYsnEAZuXz0jTTyAUfrtU3Z5E003C4oxOj6H0rfIF1kKI9MAQLMdpGW1GYEIgS9Ez
Sdfd8AcCIicTDWbqLAcU4UpkaX8KyGlLwsNuuGztobF8m72ALC/nLF6JLtPofwFBlgc+myiv
O7TCUSBdLQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPq
dAv8JggJICUvax2T9va5 gsg-keypair
  We now append them to the git user’s authorized_keysfile in its .ssh directory. 
$ cat /tmp/id_rsa.john.pub >> ~/.ssh/authorized_keys
$ cat /tmp/id_rsa.josie.pub >> ~/.ssh/authorized_keys
$ cat /tmp/id_rsa.jessica.pub >> ~/.ssh/authorized_keys
  We can now set up an empty repository by running git init with the –bare option, which initializes a repository without a working directory. 
$ cd /srv/git
$ mkdir project.git
$ cd project.git
$ git init --bare
Initialized empty Git repository in /srv/git/project.git/
  Now one can push their first version of their project into that repository by adding it as a remote and pushing up a branch. We can now use a hostname of the server in which we have set up git user and repository. 
$ cd myproject
$ git init
$ git add .
$ git commit -m 'initial commit'
$ git remote add origin git@gitserver:/srv/git/project.git
$ git push origin master
  Now, others can clone the directory and push back the changes. 
$ git clone git@gitserver:/srv/git/project.git
$ cd project
$ vim README
$ git commit -am 'fix for the README file'
$ git push origin master
  We can restrict a user to have only git related activitis using a shell tool called git-shell. If we set the shell to a user’s login shell, he cannot have normal usage. To use, specify the git-shell instead of bash or csh for your user’s login shell.First add git-shell to /etc/shells if it does not exist. 
$ cat /etc/shells   # see if `git-shell` is already in there.  If not...
$ which git-shell   # make sure git-shell is installed on your system.
$ sudo vim /etc/shells  # and add the path to git-shell from last command
 
Now you can edit the shell for a user using chsh <username> -s <shell>: 
$ sudo chsh git -s $(which git-shell)
Now, the git user can only use the SSH connection to push and pull Git repositories and can’t shell onto the machine. If you try, you’ll see a login rejection like this. 
$ ssh git@gitserver
fatal: Interactive git shell is not enabled.
hint: ~/git-shell-commands should exist and have read and execute access.
Connection to gitserver closed.
  If you are in need of higher control over your git repositories, setup your own private git server.]]>

]]> Gitk /gitk/ Mon, 29 Apr 2019 11:28:11 +0000 http://redpanthers.co/?p=16366 ]]> gitk is a command that is used for visualizing the commit graph and displaying all the history of the commits made and the information of files in the trees of each revision made. gitk is a very powerful GUI tool which is very handy to the command line ignorant.   To get started with gitk, we need to install it first. For Ubuntu users, follow the commands given below. 
sudo apt-get update
sudo apt-get install gitk
To get installed in Mac, follow these commands. 
/usr/local/bin/git
brew doctor
brew update
brew install git
which git
  To bring up the gitk interface, run the command. 
gitk
Here is a sample gitk interface.   The entire history of commits is shown in the GUI interface. The current head, the local branches, the commit message and who committed the messages are displayed. We can see the date and who committed the changes. Also, the files changed can be viewed.   gitk is very helpful for beginners who are not used to command line interface.]]>

]]> Git gc /git-gc/ Mon, 29 Apr 2019 11:28:11 +0000 http://redpanthers.co/?p=16363 ]]> git, lots of garbage like file revisions and unreachable objects get accumulated in the .git folder. On large repositories and long-term projects, this affects both the operating performance as well as the disk space utilization. Hence, to clean up the garbage, we have the git garbage collector, git gc. To clean up the garbage, we run the git command 
git gc
git gc will not affect the remote repository. This will just optimize the local repository. Hence, we can run git gc in any repositories. Users are encouraged to run git gc on a regular basis to keep the repositories clean and the to enhance the performance.   If we want a deeper cleaning, we can run the –aggressive option. 
git gc --aggressive
This takes a longer time to run but is more effective than normal garbage collection. This option is not required to run often.   We have an option to check if housekeeping is required or not. We run the –auto option for this. If no housekeeping is required, the command exits without performing any action. 
git gc --auto
If we need to prune all objects before a particular date, we can use the following command 
git gc --prune=<date>
If we need to prune all objects irrespective of the date, we can use 
git gc --prune=all
If we do not need to prune, we can use the following command 
git gc --no-prune
We can force for a garbage collection to run even while another git gc is running by forcing it like the given syntax 
git gc --force
    git gc is very helpful in keeping our local repositories clean and a better performance of our hard disks.]]>

]]> Git Prune /git-prune/ Mon, 29 Apr 2019 11:28:11 +0000 http://redpanthers.co/?p=16360 ]]> git prune to remove the unwanted branches from the local or the remote server. git prune removes the references of the branches we do not use anymore.   Usually, there are 3 kinds of branches that we need to clean up.
  • The local branches in which we do our day to day working.
  • The reference to the remote branches which we use for naming branches
  • The branches on the remote server
  To remove the unwanted branches from the local, run the command as in the following syntax. 
git branch -D branch_name
To clean up the reference objects, run the command of the following syntax 
git remote prune reference_name
To delete the unwanted remote branches, run the command 
git push origin --delete branch-name
  Git prune comes in handy when it comes to keeping the repository neat and clean. Cleaning up the unwanted branches keeps the repository neat.]]>

]]> Git Rebase /git-rebase/ Mon, 29 Apr 2019 11:28:11 +0000 http://redpanthers.co/?p=16357 ]]> git rebase master or 
git rebase master feature_branch
  There are two ways to integrate the feature branch with the master, that is merging directly and rebasing and then merging. Merging directly results in a 3-way merge and has a merge commit. Rebasing and merging is a fast-forward merge and a perfect commit history.   Having a clean commit history is good, especially when it comes to finding bugs. Imagine a bug occurs in the code and the developer could not track where the bug was introduced using git log. Now, he may run git bisect to find the bad commit. Because the commit history is clean, the git bisect has a refined set of commits to work on. This helps the developer to find the bug faster.   We can run git rebase in an interactive mode by either giving the option -i or –interactive 
git rebase --interactive
This triggers the interactive mode. Interactive mode means we can play with the commits. Instead of the standard rebase, which moves all the commits blindly, the interactive commit let us alter with the commits. We can choose the commits we need, keeping the history cleaner. We can pick the commit, alter the commit, squash or discard the commit.   Rebasing is a very helpful way to integrate your branches while keeping your commit history clean, which helps while debugging.]]>

]]> Git Bisect /git-bisect/ Mon, 29 Apr 2019 11:28:11 +0000 http://redpanthers.co/?p=16355 ]]> git bisect, we can find the bad commit much easier.   git bisect is a git command used to find the commit that introduced a bug in your code. We mention a  good commit where there was no bug and also a bad commit where we noticed the bug. git bisect picks a commit in between and asks if the commit is good or bad. This goes on till we find the bad commit. git bisect works just as a binary search does.   To get started with git bisect, we run the command 
git bisect start
Now, we add the good commit. The syntax is 
git bisect good commit_id
Then, we add the bad commit as the following syntax. 
git bisect bad commit_id
  Now, the command will trigger splitting the commits into half and revise it. We respond if the commit is good or bad as git bisect good or git bisect bad. The revision is narrowed down until we find the commit that caused the bug.   Sometimes, we can automate finding the bugs. We can pass any script and check the script against each commits. The commit returning a non-zero status is the failing one. Here, as an example, I am running a failing test 
git bisect run rspec spec/features/my_broken_spec.rb
  git bisect is an awesome method to find the commit which caused the bug. It helps us saving our time and money.  ]]>

]]> Git Blame /git-blame/ Mon, 29 Apr 2019 11:28:11 +0000 http://redpanthers.co/?p=16352 ]]> Git, a version control software, is primarily used for source code management and tracking any changes any set of files. Git is very effective in coordinating the work of multiple people working on a project. Being a distributed revision control system, Git aims at speed, data integrity and support for distributed, non-linear workflows.

More than 1 developers may change the contents of a file. Using git blame, we can find the person responsible for the last change of code of each line. The command, as the name suggests, helps to find the person who changed a line of code and to blame them. In short, git blame shows the revision and author of each code of line of a file.

To get started with git blame, try the following syntax.

git blame filename
We then get the list of authors of each line of code for the file. git blame operates on individual files, therefore, it’s better to specify the path of the file. Here is a sample output of git blame. 
$ git blame README.md
82496ea3 (kev 2018-02-28 13:37:02 -0800 1) # Git Blame example
82496ea3 (kev 2018-02-28 13:37:02 -0800 2)
89feb84d (Alie So 2018-03-01 00:54:03 +0000 3) new line
82496ea3 (kev 2018-02-28 13:37:02 -0800 4)
82496ea3 (kev 2018-02-28 13:37:02 -0800 5) git blame
82496ea3 (kev 2018-02-28 13:37:02 -0800 6)
89feb84d (Alie So 2018-03-01 00:54:03 +0000 7) sun is going down

Commonly used options

We can use a set of options for git blame. Some of them are given below. 
git blame -L 1,5 README.md
This option restricts the display from lines 1 to 5.   
git blame -e README.md
This option displays the email address of the author instead of his username.   
git blame -w README.md
This option ignores the whitespaces in the file and mentions the authors of other lines.   
git blame -M README.md
This option detects the copied or moved lines within a file. The command returns the original author instead of the person who copied or moved the file.   
git blame -C README.md
This option detects the copied or moved lines among any files. The command returns the original author instead of the person who copied or moved the file.   git blame is a very useful command in finding the author of each line of code. and to see when the modifications were done. git blame comes in handy while managing a project.]]>

]]> Working Of Git /working-of-git/ Mon, 29 Apr 2019 11:28:11 +0000 http://redpanthers.co/?p=16350 ]]> ]]> What is Test Driven Development? /what-is-test-driven-development/ Mon, 29 Apr 2019 11:28:11 +0000 http://redpanthers.co/?p=16375 ]]> Test Driven Development (TDD) is a software development process that weighs on a short development cycle. The developer first writes an automated test defining the new feature or update, which fails at first, then write minimal code for the tests to pass, then refactor the code according to the needed standards. TDD is helpful in keeping the code neater, simple and bug-free   TDD starts with designing and developing tests for every small functionality of an application. The test is developed which will specify and validate what the code will do. n the normal Testing process, we first generate the code and then test. Tests might fail since tests are developed even before the development. In order to pass the test, the development team has to develop and refactors the code, which means changing the code without affecting its actual behaviour.   We usually follow the following sequences in TDD.
  • Add a test
  • Run all tests and see if the new one fails
  • Write some code
  • Run tests
  • Refactor code
  • Repeat
  The simple concept of TDD is to write and correct the failed tests before writing new code. This helps to avoid duplication of code as we write a small amount of code at a time in order to pass tests. Test-Driven development is a process of developing and running automated test before actual development of the application. Hence, TDD sometimes also called as Test First Development.   In short, TDD is
  1. Write a test
  2. Make it run.
  3. Change the code to make it right i.e. Refactor.
  4. Repeat process.
 

Why use Test Driven Development

  • Early bug notification.Developers test their code but in the database world, this often consists of manual tests or one-off scripts. Using TDD you build up, over time, a suite of automated tests that you and any other developer can rerun at will.
  • Better Designed, cleaner and more extensible code.
    • It helps to understand how the code will be used and how it interacts with other modules.
    • It results in better design decision and more maintainable code.
    • TDD allows writing smaller code having single responsibility rather than monolithic procedures with multiple responsibilities. This makes the code simpler to understand.
    • TDD also forces to write only production code to pass tests based on user requirements.
  • Confidence to Refactor
    • If you refactor code, there can be possibilities of breaks in the code. So having a set of automated tests you can fix those breaks before release. Proper warning will be given if breaks found when automated tests are used.
    • Using TDD, should results in faster, more extensible code with fewer bugs that can be updated with minimal risks.
  • Good for teamworkIn the absence of any team member, other team members can easily pick up and work on the code. It also aids knowledge sharing, thereby making the team more effective overall.
  • Good for DevelopersThough developers have to spend more time in writing TDD test cases, it takes a lot less time for debugging and developing new features. You will write cleaner, less complicated code.
  Test Driven Development is a very effective method to follow to keep our code, neat and bug-free.  ]]>

]]>