Azure Cosmos DB and SQL API account - Hands on activity

  

Azure Cosmos DB – brief Introduction 

In one of previous articles, we have talked about Azure Cosmos DB and its bits and pieces.  We see that Azure Cosmos DB is the globally distributed and fully managed database service for building world-scale applications. It leverages the Azure cloud infrastructure to support global-scale application workloads.

Azure Cosmos DB is formerly known as Document DB, a multi-model NoSQL database in an Azure cloud platform that offer to store and process massive amount of structured, semi-structured and unstructured data. It provides native support to various platforms to access your database like, MongoDB APIs, Cassandra, Azure Tables, Gremlin and SQL.

Here in this article, we will talk about SQL API and will do some hands on activity on top of Azure Cosmos DB SQL API account. SQL API is the ideal way if you build a non-relational document database and execute query like SQL syntax. In the context of some exercise, you can cover the following tasks herewith – 

• Create an Azure Cosmos DB SQL API account
• Create a document database and a collection (item)
• Add data to the collection
• Query to data by using Data Explorer 

Pre-requisites

Before taking place, we need some essential pre-requisites to accomplish this Azure Cosmos DB exercise.

1. Azure subscription, if you don't have an account then sign up for a free Azure account - https://azure.microsoft.com/en-gb/free/
2. Hands on SQL syntax, though not mandatory, but if know then easier to  write different queries.

STEP – 1: Create an Azure Cosmos DB account

Login to the Azure portal https://portal.azure.com/

In the Microsoft Azure portal, click the + Create a resource from the Hub and click the Databases from the Azure Marketplace. It will load all available database services under the Featured section, select the Azure Cosmos DB or can search from the search box.

Promptly the Create Azure Cosmos DB Account blade will be loaded, the time you click the Azure Cosmos DB. Here some required details needed to submit to proceed like Project Details as well Instance Details under Basic tab.

Make sure the correct subscription is selected and then choose an existing Resource group or can create a new using Create new.

In my case going with earlier created resource group ‘demogroup’

Under Instance Details, enter valid details for the following properties – 

• Account Name – Enter a unique name to identify the Azure Cosmos account.
• API – Here, the API determines the type of account to create, select Core (SQL) to create a document database and query by using SQL syntax.
• Apache Spark – Go with by default Disabled mode.
• Location – Required selecting a geographic location or region to host the Azure Cosmos DB account.
• Geo-Redundancy – Go with by default Disabled mode.
• Multi-region Writes – Go with by default Disabled mode.

Now, nearly all properties have filled up; continue by clicking the Review + Create button at the bottom. However, you can skip the Network and Tags sections. Within few moments, post validation success a final review page will be appeared that display the details about the Azure Cosmos DB you are about to create.

  

If you find everything arranged, then click the Create button that will take a few minutes for your Azure Cosmos DB to be deployed.

Sooner, you will be notified once the Azure Cosmos DB is created successfully.

Congratulation, an Azure Cosmos DB provisioned!! 😊

STEP – 2: Add a Database and a Container

We knew that Azure Cosmos DB is a globally distributed multi-model database that supports the document, graph, and key-value data models. A collection is a container of JSON documents and associated JavaScript application logic, i.e. stored procedures, triggers and user-defined functions.

A collection maps to a container in Azure Cosmos DB, therefore, it is a billable entity, where the cost is determined by the provisioned throughput expressed in request units per second.

Move to Azure portal and click the All resources from the Hub, select the Azure Cosmos DB account page that you created in the previous steps.

Since you did not create any container yet, time to create a database and container by using Data Explorer. Select Data Explorer from the left navigation from the Azure Cosmos DB account page, which provides the option to create a container.

Proceed ahead by clicking the New Container, which will load Add Container page where the details required for the new container as listed below properties –

• Database id – Enter a new database id.
• Provision database throughput – Go with by default non-selected.
• Container id – Enter a unique identifier for the container.
• Partition key – For example, moving with /category as the partition key as we used in this task.
• My partition key is larger than 100 bytes
• Throughput – Go to the by default option.

Once you submit all details, and then continue by clicking the OK button. More readily, you will get the database and the collection under Data Explorer, as you provided the name during provisioning.

STEP – 3: Add data to Database

In the previous section, you set up a database and a collection, time to add data to your new database by using Data Explorer.

You can see the new database, expand the cosmoscontainer database and later on expand the items collection. Sooner you can get different types of multiple options to create new items, etc. Click Items under the collection and then select the New Item from the top menu accordingly.

A new item pane will be loaded the time you click the New Item, required to add the following JSON based structure to the item.

{

    "id": "100",

    "category": "personal",

    "name": "groceries",

    "description": "do not forget apples.",

    "isComplete": false

}

Now add the new item by clicking the Save button. Next, select the New Item again, create, and save another item with a unique id.

You can add any properties and values since the item can have any structure, since Azure Cosmos DB does not follow any schema.

I did a couples of new entries, like – 

{

    "id": "101",

    "category": "personal",

    "name": "fashion",

    "description": "casual dress",

    "isComplete": false

}

{

    "id": "102",

    "category": "personal",

    "name": "medicine",

    "description": "bp medicines",

    "isComplete": false

}

{

    "id": "103",

    "category": "personal",

    "name": "groceries",

    "description": "green salad",

    "isComplete": false

}

You can see all entries based on id and category wise, under the Items section.

STEP – 4: Query to Data

In fact, Azure Cosmos DB does not enforce any schema for data, so you are, free to add different types of properties and values in the items. Now time to query by using Data Explorer to retrieve and filter your data.

You can see a by default SELECT query exists at the top of the Items tab in Data Explored, the query retrieves and display all items in the collection in ID order.

If required, you can change the query, select Edit Filter, replace the default query with below listed one, and then select Apply Filter.

WHERE c.name= 'groceries'

It will display the filtered items as soon as you click the Apply Filter button.

Looks like, it is very similar to SQL like queries, if you are hands on with SQL syntax then can write different query in the query predicate box easily. Along with this, you can use Data Explorer to create stored procedures, User Defined Functions, and Triggers etc.

Here, we walked through the Azure Cosmos DB and came to know that how cool it is to work with your Azure Cosmos DB data. In next article, we will create a .NET web app and will validate how much feasible to work with .NET program like to update your Azure Cosmos DB data by using a .NET web app.

Keep visiting for further posts.

Deploy files from local Repository to GitHub via Git

Git and GitHub – an Introduction

In previous article we have been gabbing about the Version Control Systems and its different types as well fundamental approaches of Git and GitHub. Version Control Systems are a kind of software tools that help development teams to manage changes to source code over time. It keeps track of every modification to the code in a special kind of database.

Git is one of the top Version Control System, a tool to manage your source code history. Along with this, GitHub is a web-based hosting service for Git repositories. Better to visit the preceding post to get an overview about Git and GitHub, because they work on top of the Repository and Working Copy though not the same thing.

At this point in this post we will walk through some hands on activities like – 

• Connect an Ubuntu VM using PuTTY client
• Install Git and set up your GitHub account
• Execute some most popular commands in Git
• Push all the files from the local repository to GitHub

Meanwhile, if required, then you can visit some previous articles to know a bit more about the following topics – 

• Setup an Ubuntu Linux Virtual Machine using Azure Portal
• Setup an Ubuntu Linux Virtual Machine using PowerShell
• Some hands on activities with basic Linux commands
• Connect an Ubuntu Linux Virtual Machine using PuTTY client

Pre-requisites

Before proceeding further, need some pre-requisites to go ahead to deploy all the source code files from the local repository to GitHub, like – 

1. Azure subscription, if you don't have an account then sign up for a free Azure account - https://azure.microsoft.com/en-gb/free/
2. A running Ubuntu Linux VM
3. PuTTY client to be used as the SSH client
4. GitHub account, if you don’t have an account then sign up - https://github.com/  

STEP – 1: Validate the existence of an Ubuntu VM

It is essential to exist an Ubuntu Linux Azure Virtual Machine (VM) to accomplish this demo task, login to the Azure portal https://portal.azure.com/.

On the left Hub menu, click All resources and select the existing Ubuntu virtual machine, verify the VM is either running or stopped, if it is in stop mode, i.e. deallocated then start the same.

STEP – 2: Fetch the connection details of Ubuntu VM

Next, required to connect the VM, you can go with either SSH key or PuTTY client depends on the configuration and setup done with Ubuntu VM. 

I am moving ahead with PuTTY client, click the Connect button from the menu bar to launch the connection details.

Here you can see a new blade as Connect to virtual machine appeared, copy the account details which exist under the Login using the VM local account, in my case - ssh demoadmin@40.117.153.69.

STEP – 3: Connect the VM using PuTTY client

Since the Ubuntu Linux VM is configured (password-based) in such a way to connect using the PuTTY client, so open up PuTTY, and in the Session page, submit the host name into the Host Name box, the same we copied earlier.

For example, in my case, it was - ssh demoadmin@40.117.153.69, but need to submit only demoadmin@40.117.153.69, exclude the ssh prefix and then, under Connection type, select SSH and click Open.

Once the SSH session has been established, promptly, it will ask password for the connecting server, enter the administrator password you specified during provisioning the Ubuntu VM.

Post authorization, you will be connected with the Ubuntu Linux 18.04.1 LTS Virtual Machine (VM), happy to go ahead.

STEP – 4: Install Git

Mostly Git used to be installed, better to check the version of Git by executing the following command in the terminal.

Git --version

  

It will display the current installed version, but if not installed, then you can install Git by executing the following command.

sudo apt-get install git

Quickly the package will be starting to install, though in my case the newer version was already installed.

STEP – 5: Set up GitHub account

We came to know that GitHub is a web-based hosting service for version control using Git. In addition, it offers different plans for public and private repositories; here we will demonstrate the hands on activity on public repository, i.e. free version.

If you do not have an account, then navigate to https://github.com/.

Next, click on Sign up for GitHub once you provided a user name, email id and password.

Sooner you will get a new page segregated by three steps, in the first step; you will have to click the Create an account that will lead some verification. In the second step, Choose your subscription, select Free, and proceed further by clicking the Continue button.  

In the next step, you can share basic information about yourself and preferences or you can skip this step. Meanwhile, you will receive an email to verify your account. It is essential to verify your email address, once confirmed; your GitHub account is set up successfully. 

Do not forget to note down the user name and email id that required in next steps.

Congratulations, the GitHub account set up done!! 😊

STEP – 6: Login from Git local to connect remote GitHub

Move to terminal window and execute the following commands by replacing your username as well email, which you have been copied in previous steps. In fact, you need to provide the registered email address and user name with your GitHub account.

git config --global user.email your_email_id

git config --global user.username your_username

STEP – 7: Create some multiple demo files and content in each file

In the meantime, we required some code file that considering different languages for the hands on activity, henceforth you can create some demo files with diverse extensions. 

First, create a folder where you can store all the files in one place, execute the following commands.

mkdir demoproject

cd demoproject

Now required to create different files, you can use the touch command. Touch command is the easiest way to create new, empty multiple files, and execute the following command.

touch index.html texts.txt c_program.c java_program.java index.js styles.css

ls -l

Now you can use any text editors available in Linux, but I will prefer the vi editor. To open and work the vi in editor mode, follow the subsequent steps – 

• Open the editor - vi filename.extension
• Activate the insert mode – click the I key
• Save and execute the vi editor – Click Esc, then : (shift) wq 

For example, required to add the below code in c_program.c file.

#include<stdio.h>

int main(){

printf(“Hello! I am C-Program. Thank you!”);

return 0;

}

In the first step, open the vi editor with the c_program.c file, execute the following command.

vi c_program.c

It will launch the vi editor, change the mode to INSERT and write the above sample code. Once done, click the Esc key and follow with :wq to save and return to the terminal.

You can do verify the contents by using the cat command that displays contents of the file, execute in following way.

cat c_program.c

Similarly, you can add some contents in all specified files as well can skip some files that will not contain any codes or statements.

STEP – 8: Initialize Git

In fact, all the files are to be pushed to GitHub, essential to initialize a .git folder inside the directory by executing the following commands.

git init

git add .

git commit . -m "I am pushing all the sample files to my GitHub"

git status

Note, required to follow the process step-by-step confirmation of each command executed.

Although, you can visit the official site to get more information about the Git commands - https://git-scm.com/doc.

STEP – 9: Create a repository in GitHub account

Next, time to create a repository that is a storage location where you can push code files as well pull and installed on a computer. 

Login the GitHub account - https://github.com.

Move to the home page, here click on Create a repository link that appears in the left most corner as you can see the below snapshot.

It will launch the Create a new repository page, where you need to provide details of the following properties – 

• Owner/Repository name – Provide a short but meaningful name for your repository.
• Description – Though it is an option but can submit the description about the repository.
• Public/Private – Go with the by default selection with Public option.
• Initialize this repository with a README – It will place a README file in your repository.

Once you have submitted the details, proceed ahead and click the Create repository button. Here you will be navigated automatically inside the directory you have created.

STEP – 10: Cloning with SSH URLs

Since a repository has been created, now using the URLs you can use to clone the project into your computer. Here you will go through SSH URL that provide access to a Git repository via SSH, a secure protocol.

Navigate inside the directory, and click the Clone or download button that will provide two URL based clone option i.e. HTTPS and SSH. Click the Use SSH link.

If you get messages about the SSH key something like “You don't have any public SSH keys in your GitHub account….”, then time to create an SSH key and adding it to GitHub. 

Move to the terminal and generate an RSA key for the registered email id by executing the following command.

ssh-keygen -t rsa -C registered_email_id

RSA key has been generated, by using the cat command you can display on the terminal, and execute the following command.

cat /home/demoadmin/.ssh/id_rsa.pub

Copy the entire Key that is required to add to the GitHub account, move to the same directory in GitHub homepage and  click the add a new public key link that comes at Clone with SSH option. Alternatively, you can go via the Personal Settings - > SSH & GPG Keys.

  

Promptly Add new key page will be loaded the time you click the link, now provide the key title and the key under Key box accordingly.

Save the SSH key by clicking the Add SSH key, and you can see the acknowledgement of list that associated with the GitHub account.

Once the RSA Key has been added, you can get the SSH URL, move back to the Clone section and copy the SSH URL as displayed in below snapshot.

STEP – 11: Add Remote and Push Cloning with SSH URLs

Next, required to add this new remote by using git remote add command on the terminal, in the same directory where the repository is stored. In fact, the git command required the remote URL followed by origin keyword, so use the same-copied the SSH URL for the remote herewith.

Copy the git remote add origin <SSH_URL_of_Your_GitHub_Repository> and execute it in the terminal, something like that.

git remote add origin git@github.com:rajendrxxxxxxxxxx/demoproject.git

Remote origin added, now time to execute a push command that is used to send the commits from your local branch in the local Git repository to the remote server. Execute the following command to deploy all code files to the GitHub repository.

git push -u origin master

If you get some failed or rejected error using the above command, then go with a forced update by executing the following command.

git push origin master --force

Navigate the repository under the GitHub account and reload the page; you will get the newly added code files that were pushed from the local repository by using Git.

Congratulations, the files deployed to GitHub via Git successfully!! 😊

I trust you came to know a bit more about the Git & GitHub approach and enjoyed the hands on activity tasks. In parallel, we have covered some precise Git commands during the assignment pushing files to GitHub. 

Undoubtedly, in further posts, we will see some more diverse topics and exercises, keep visiting the blog.

Version Control System on top of Git and GitHub – an Introduction

Version Control Systems - Introduction

Before jumping to Git or GitHub, we will have to understand about the Version Control System and its history. Version Control Systems known as VCS are a kind of software tool that focus is to manage and track the changes to the files, programs, logs, and other information related to code development, code deployment, and code operation over time.

Version Control Systems keeps track of every modification to the code in a special kind of database. It lets you save a snapshot of the complete project at any point in time. It enables multiple people to simultaneously work on a single project as well as integrates the work done all together with different team members. If a mistake is made, developers can turn back the code and compare earlier versions of the code to help fix the mistake as well bug promptly.

In the context of the Version Control workflow approach, two jargon plays the key roles, as –

1. Repository 
2. Working Copy

A Repository is a database of changes, and/or historical versions or snapshots of the project. At the other end, a Working Copy sometimes called a Checkout is the copy where you do your work , all files in the project. It leverages you to edit the copy without affecting your coworkers. When you are done and confirm with your edits, you proceed to commit your changes into a repository.

At the same time Version Control System is also popularly known as – 

• Revision Control System
• Configuration Management System
• Source Control Management System

Varieties of Version Control Systems

If I talk about the way Version Control works, then there are two general varieties of Version Control exist, as – 

1. Centralized Version Control
2. Distributed Version Control

Basically, the Centralized Version Control works on the concept of a Client-Server relationship. There is only one  repository that located in one place and provide access to many clients, and each user gets his or her own working copy. It is possible for your team member to update and see your edits as soon as you Commit.

But in case of Distributed Version Control, there are multiple repositories, each user gets his or her own local repository and working copy. Once you make Commit, others have no access to your changes until you Push the changes to the central repository. Similarly, when you update, you do not get other’s changes unless you Pull those changes into your repository. 

In this way we can see the following activities under version control – 

Centralized Version Control System

• Commit
• Update

Distributed Version Control System

• Commit
• Update
• Push
• Pull

In fact, Distributed Version Control is more modern, runs faster, has more features, and is less prone to errors in contrast with Centralized Version Control.

In this consequence, now we can have some fair idea about the importance of Version Control System, following are some key significance – 

• Registered users only check files into version control.
• Documents and files can be identified by file names, authors, and the modified dates.
• Each file check-in gets a new version that is usually a number.
• Supports in differentiating the latest versions and tracking the recent updates.
• The latest versions of all files are often referred to as heads.
• Source control systems are organized into repositories.
• Version control supports branching where the head of the repository is split for parallel development.
• Maintain independent branches of code for team members to track their respective changes
• Continuous integration is easier with the new version control systems.
• Simple comparison across versions to help resolve conflicts in code during merging.
• Revert changes made to the code to any state from its history. 
• Advantages in coding collaboratively and remotely.

Git - Introduction

We just covered the overview of Version Control Systems, that make a positive impact in software development. In today’s era, there are different types of Version Control Systems  that are available in the market, like few top systems are – 

• Git – It is a distributed version control and used to scrutinize the changes.
• CVS (Concurrent Version System) – It is a free client-server revision control system.
• SVN (Apache Subversion) – It is a distributed version control tool under the Apache license.
• Assembla – It is a web-based version control and source code management system.
• Mercurial – It is a distributed revision control tool that supports Windows and Unix-like environments.
• Bazaar – It is both, a distributed and a client-server revision control system.

Till now we walked through the overview of Version Control System and came to know about different types of VCS. Here we will talk about one of the most popular Version Control System that is Git. Git is a free, open source Distributed Version Control System designed to handle all types of projects, small to large with speed and proficiency. 

It was originally developed in 2005 by Linus Torvalds, the famous creator of the Linux operating system kernel. Git covers the following objectives – 

• Speed
• Simple design
• Fully distributed
• Excellent support for parallel development, support for hundreds of parallel branches.

Git is a Distributed Version Control system, it does mean your local copy of the code is itself a complete version control repository. Such fully-functional local repositories make it easier to work offline or remotely. In the meantime, you commit your work locally, and then sync up your copy of the repository with the copy on the server.

In the context of states, Git has three main shapes that your files can reside in -

1. Committed – It means that the data is safely stored in your local database.
2. Modified – it means that you have changed the file, but have not committed it to your database yet.
3. Staged – It means that you have marked a modified file in its current version to go into your next commit snapshot.

Based on Git working structure, there are three main sections of a Git project- 

1. Git Directory – It is where Git stores the metadata and object database for your project. This is the most important part of Git, and it is what is copied when you clone a repository from another computer.
2. Working Directory – It is a single checkout of one version of the project. These files are pulled out of the compressed database in the Git directory and placed on disk for you to use or modify.
3. Staging Area – It is a file, generally contained in your Git directory, that stores information about what will go into your next commit. Its technical name in Git jargon is the “index”, but the phrase “staging area” works just as well.

Now we can draw the basic workflows of a Git ecosystem something like this – 

1. You modify files in your working tree.
2. You selectively stage just those changes you want to be part of your next commit, which adds only those changes to the staging area.
3. You do a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory.

Every time you save your work, Git creates a Commit and if a particular version of a file is in the Git directory, it is considered as Committed. If it has been modified and was added to the staging area, it is Staged. And if it was changed since it was checked out, but has not been staged, it is a Modified.

Benefits of Git 

In addition to being a free, open source and distributed system, Git has been designed keeping the key features in core, like performance, security and flexibility etc. In a nutshell, following are the key benefits of Git.

• Performance – Committing new changes, branching, merging and comparing past versions are all optimized for performance. Along with this, being distributed enables significant performance benefits as well.
• Flexibility – Git is flexible in several respects, like to support for various kinds of nonlinear development workflows, in its efficiency in both small and large projects and in its compatibility with many existing systems and protocols.
• Security – The content of the files as well as the true relationships between files and directories, versions, tags and commits, all of these objects in the Git repository are secured with a cryptographically secure hashing algorithm called SHA1.
• Parallel development – Due to distributed feature everyone can work simultaneously on their own branches.
• Quick release – Branches helps a flexible and simultaneous development and by separating your release branch from development in progress, you can manage your stable code better and ship updates more quickly.
• Built-in integration – Due to its popularity, Git is integrated into most tools and products. Every major IDE has built-in Git support, and many tools that allow you to manage continuous integration, continuous deployment.
• Pull request – By using pull requests you can discuss code changes with your team before merging them into your main branch.
• Branch Management – Branching with Git is very simple, takes only few seconds to create, delete, and merge branches. Feature branches provide an isolated environment for every change to your codebase.

GitHub – Introduction 

If you are in the software development world, then undoubtedly heard about the trending buzzword GitHub. In short-term, GitHub is a code hosting platform for collaboration and version control. It is a website and cloud-based service that helps developers store and manage their code, as well as track and control changes to their code.

Basically, it works on two linked principles, which we have been just walked through in previous sections – 

• Version Control
• Git

GitHub is a Git repository hosting service, but it adds many of its own features. While Git is a command line tool, GitHub provides a web-based graphical interface. Besides simple code storage, it is an entire ecosystem complete with an elegant social networking site, allowing individual developers to contribute to multiple teams and projects.

Next, time to go ahead to catch some key terminology of GitHub – 

• Repositories 
• Branches
• Commits
• Pull Requests

Repository (repo)

A GitHub repository (repo) is a location where all the files for a development project are stored. It can contain folders and any type of files like HTML, CSS, JavaScripts, Documents, Images etc. Each project has its own repo, and you can access it with a unique URL.

By default GitHub repos are open to the public. If users want to restrict the public access to their repos, they can choose to keep their projects private for a small fee.

Branch (fork)

A branch, also known as a fork, is simply a repository that has been copied from one member's account to another member's account. A GitHub branch is used to work with different versions of a repository at the same time.

By default a repository has a master branch and any other branch is a copy of the master branch. 

Commits

Changes at GitHub are called commits a kind of like saving a file. Each commit has a description that explains why a change was made in the repository. Depending on how a repository is set up, you also might be able to create your own branch and make your own commits there.

Pull Requests

A pull request is a way through which you can submit the code changes back to a branch once you did commits there. By using a pull request you are proposing that your code changes should be merged (pilled in) with the master branch.

In brief, the basic flow of GitHub is Creating a Repository, Managing Branches, Making Changes, and Merging those changes via Pull Request. Forks and branches allow a developer to make modifications without affecting the original code. If the developer would like to share the modifications, he/she can send a pull request to the owner of the original repository.

If, after reviewing the modifications, the original owner would like to pull the modifications into the repository, he/she can accept the modifications and merge them to the original repository.

In the next article we will do some hands on activity like deploy files to GitHub repository by using Git. However, if you keen to get started with Git and GitHub, then – 

• Sign up for a free GitHub account at https://github.com/
• Follow the world guide to understand the most popular actions - https://guides.github.com/activities/hello-world/
• Git documentation - https://git-scm.com/doc

Keep visiting for further posts.