Git workspaces explained

Working in git is complicated for new users. One of the reasons is that it is quite hard to grasp where are some actions happening.  Although some actions can be done from local to remote workspaces they are not recommended. The reason is that when we expose our code changes to other we cannot perform actions that we would do like we do it locally. All those actions will be mentioned in this article with short description and explained with greater detail in subsequent articles.

Working areas in git

1. Working directory
2. Index (Staging area)
3. Local repository
4. Remote repository

1. Working directory

The area where we edit our files.

2. Index (Staging area)

The area where are the files ready to commit to our local repository.

3. Local Repository

 The are where we put code we think we have finished editing.

4. Remote repository

If we just put our code to remote repository we might consider it as backup, or if we interact with others we have an additional step.

Local vs Remote workspace

Also we need to separate what actions we perform on our computer (locally) or with others. Remote workspace can be defined as some other repository on the same computer, network storage, remote computer or dedicated service like github, bitbucket, gitlab, .... It is

Local workspace

We can define local workspace as everything we do using our computer without any interaction with remote code. In that area we can put following workspaces: working directory, index and local repository.

The usual workflow in local workspace is following:

• Putting into local repository
  We create code and add it into the staging area, we can check the changes we are  about to put into the local repository.
• Getting out of the local repository
  We get the code from the repository into our working directory

Remote workspace 

I would define remote workspace how we have interaction with others. So it is interaction between our local repository and remote repository.

The usual workflow in remote workspace:

• Putting into remote repository
  - single-user
    Just put code into the the remote repository
  - multi-user
    Create a request to put code into the remote repository, 
    some other user needs to accept it after making a code review

• Getting code from the remote repository
  There are two steps involved: fetching and merging the code.
  First we fetch changes, see what has been changed, and merge to our local repository.

This is only introductionary post about git workspaces.

Vim plugins

There are many plugins out in the world for Vim and it takes time to investigate them and start to use them. I am slowly starting to become better and better Vim user. Some of the plugins are implemented in Vim add-ons for other code editors, or IDEs (integrated development environments).

If you are planning to use Vim plugins I highly recommend using some of Vim plugin manager. Vim 8 should contain a plugin manager, but I am using dein plugin manager. I used NeoBundle plugin manager before but it is deprecated. One of the major differences between NeoBundle and Dein that NeoBundle can be run on Windows. Since I am not using Windows anymore (although occasionally) I use Dein.

The list of Vim plugins I use:

• vim-surround 
• vim-airline
• vim-airline-themes
• vim-table-mode

A bit about those plugins.

Vim-surround (https://github.com/tpope/vim-surround)

Surround.vim is all about "surroundings": parentheses, brackets, quotes, XML tags, and more. The plugin provides mappings to easily delete, change and add such surroundings in pairs.

The documentation on its webpage sufficient and clear although I was confused a bit how to surround the selection of text. 

It is important to note that Eclipse plugin Vrapper support this plugin. 

I really love the plugin and use it very often.

Vim-airline (https://github.com/vim-airline/vim-airline)

It is just a nice status line that changes colour depending on the current Vim mode. If vim-fugitive is installed it shows which branch is active. Also, it displays various info about the file.

vim-airline-themes (https://github.com/vim-airline/vim-airline-themes)

Custom themes for the vim-airline plugin. 

vim-table-mode (https://github.com/dhruvasagar/vim-table-mode)

Quite useful if you want to make tables in the textual files. 

Excellent documentation on the github page.

Don't forget to use easy activation/deactivation for the plugin mode.

When in the normal mode type `<Leader>tm` and it will switch to the new mode.

This mode is more like a layer over the Insert mode.

<Leader> is a special key, `\` by default but it can be easily mapped to another value.

RHCSA vs LFCS

On this blog, I would like the differentiate these two certificates. I am in process of learning linux operating system and I would like to get certified. My goal is to pinpoint the pros and cons of each certificate and differences between them related to the exam objectives.


                         RHCSA                                               LFCS

Price:             460 € + VAT                                      300$
Validity:        3 years                                                2 years
Free Retake:      No                                                  1 free retake
Pre-requisites:   No                                                  No
Exam duration:  2.5 hrs                                            2 hrs
Passing score:    not defined                                     74%

There is a long list of course objective on both sides, some are more detailed in RHCSA list.

Links to the exam objectives:

• LFCS exam objectives
• RHCSA exam objectives

If we read the objectives we notice that many objectives are overlapping (maybe not positioned in the same area). 

There are many exam mocks for RHCSA and it is possible to take an assessment test on RedHat.

We can assess our knowledge using the following page: Red Hat Assesment

There is a section for RedHat 7 administration. I haven't tested it yet and it is unclear is it suitable for EX200 (RHCSA) or EX300 (RHCE).

There are many dumps for RHCSA and not many for LFCS. Since they overlap I will use RHCSA dumps. And try to follow LFCS exam objectives as much as possible.

Vagrant

Vagrant is an open-source software product for building and maintaining portable virtual software development environments,^[4] e.g. for VirtualBox, Hyper-V, Docker, VMware, and AWS which try to simplify software configuration management of virtualizations in order to increase development productivity. Vagrant is written in the Ruby language, but its ecosystem supports development in almost all major languages.

Vagrant is a nice tool and I really like it. Starting using Vagrant is simple but it can lead problems. The problems are not Vagrant related because the software is nice, but how other people support it.

I used it with Virtualbox and I will list some nice things and bad things related to the experience. The base of using vagrant is a box (compressed disk image file)

Nice things:

• Easy to run a box
• Good documentation
• Lovely integration with Ansible (dynamic discovery)
• support for multiple virtual machines
• virtual machine customization
• no demand for using the Ruby programming language (but it can help)
• networking works out-of-the-box
• private networking (connecting to assigned IP from the host)
• greate user base with excellent "boxes"

Bad things:

• Creating boxes is a complex process
• Official boxes are broken (Ubuntu 16.04)
  Since it doesn't contain vagrant user functionality is limited and problematic
• Links to boxes are not valid or not valid anymore
• Some official boxes don't integrate virtualbox add-ons which can cause issues
• Experimentation is needed to find suitable boxes
• It doesn't use cloning feature of virtualbox and therefore if we use many virtual machines base box get expanded as many machines as we have
  

Vagrant is a nice tool that needs to be examined more. In following blog entries I will explain multi-machine setup.