Forem: Sanjay Singh Rajpoot

What are GoRoutines in GoLang?

Sanjay Singh Rajpoot — Sat, 28 Jan 2023 16:40:49 +0000

GoRoutines are one of the most unique and most used feature of Golang. Goroutines are used to person concurrent tasks. A goroutine is simply a lightweight execution thread and a function that executes concurrently with the rest of the program. The cost of creating a Goroutine is tiny when compared to a thread.

Before we dive deep into the GoRoutines lets first understand the meaning of Concurrency.

Concurrency and Parallelism

Concurrency is when two or more tasks can start, run, and complete in overlapping time periods. It doesn't necessarily mean they'll ever both be running at the same instant. Concurrency is a semantic property of a program or system. Concurrency is when multiple tasks are in progress for overlapping periods of time.
Parallelism is about multiple tasks or subtasks of the same task that literally run at the same time on hardware with multiple computing resources like a multi-core processors. Parallelism is an implementation property. Parallelism is literally the simultaneous physical execution of tasks at runtime, and it requires hardware with multiple computing resources. It resides on the hardware layer.

For Example - if you are listening to music and reading at the same time then it is parallelism because you are doing two tasks at the same time. If you are listening to music and for a moment you paused the music and start reading, then you again start the music and pause the reading, that is concurrency. Here the two tasks were done together but not at the same time, hence concurrent.

What are GoRoutines?

A goroutine is a lightweight thread managed by the Go runtime. We, use goroutines to create concurrent programs. Concurrent programs are able to run multiple processes at the same time. Giving us the power to simultaneously process information while saving time. Goroutines are lightweight abstractions over threads because their creation and destruction are very cheap as compared to threads, and they are scheduled over OS threads. To create you just have to start the file with go word, here is an example

package main

import (  
    "fmt"
)

func hello() {  
    fmt.Println("Hello world goroutine")
}

func main() {  
    go hello()  // a go routine
    fmt.Println("main function")
}

go hello() starts a new Goroutine. Now the hello() function will run concurrently along with the main() function. The main function runs in its own Goroutine and it's called the main Goroutine.

To understand its working we have to keep a few things in mind. When a new Go routine is created it will run inside a parent Go routine which is the file that is executing the code. If the code inside the file ends or the parent thread is finished executing then it will also terminate the child routine. hence only main function is printed and the hello() routine is terminated along with the parent in the next line. The main Goroutine should be running for any other goroutine to run. If the main Goroutine terminates then the program will be terminated and no other Goroutine will run. That's the secret sauce.

Think yourself how to fix we need some delay so that the hello() routine is done executing and then we jump to the next line. For that what do we need? A simple delay that's it!!

package main

import (  
    "fmt"
    "time"
)

func hello() {  
    fmt.Println("Hello world goroutine")
}
func main() {  
    go hello()
    time.Sleep(1 * time.Second)  // here is the delay 
    fmt.Println("main function")
}

This will wait for 1 sec, in that time the go routine can execute itself. Now the call to go hello() has enough time to execute before the main Goroutine terminates. This program first prints Hello world goroutine, After 1 sec we start reading from the next line. In the same fashion, we can create multiple Go routines as per our needs.

What makes them different from threads?

Channels: Goroutines have an easy communication medium known as channels. Due to the presence of channel one, the goroutine can communicate with other goroutines with low latency. Thread does not have an easy communication medium. Due to the lack of easy communication medium inter-thread communicate takes place with high latency.
Setup and Teardown cost: Threads have significant setups and teardown costs because it has to request resources from the OS and return it once it’s done. While Goroutines are created and destroyed by the go runtime (it manages scheduling, garbage collection, and the runtime environment for Goroutines) and those operations are pretty cheap.
Switch cost: This difference is mainly because of the difference in the scheduling of Goroutines and threads. Threads are scheduled preemptively (If a process is running for more than a scheduler time slice, it would preempt the process and schedule execution of another runnable process on the same CPU), the schedular needs to save/restore all registers

How are Go routines Executed?

There are three entities Go uses to explain the Goroutine scheduling.

Processor (P)
OSThread (M)
Goroutines (G)

Go works on a type of scheduler called an m:n scheduler (M:N scheduler), which states that M number of goroutines can be distributed over N number of OS threads. Comparatively, OS threads have much more overhead than goroutines. Therefore, Go uses a limited number of threads to run a maximum number of goroutines.

Go scheduler distribute runnable goroutines over multiple worker OS threads that runs on one or more processors. Every P has a local Goroutine queue. There’s also a global Goroutine queue which contains runnable Goroutines. Each M should be assigned to a P. Ps may have no Ms if they are blocked or in a system call.

At any time, there are at most GOMAXPROCS number of P and only one M can run per P. More Ms can be created by the scheduler if required. In each round of scheduling, scheduler finds a runnable G and executes it. Once a runnable G is found, it gets executed until it is blocked.

If you made it this far don't forget to drop by and leave a comment!!

References
https://riteeksrivastava.medium.com/a-complete-journey-with-goroutines-8472630c7f5c

https://riteeksrivastava.medium.com/a-complete-journey-with-goroutines-8472630c7f5c

Thank You!!

Docker and Docker Containers Explained

Sanjay Singh Rajpoot — Sun, 08 Jan 2023 06:13:00 +0000

Let's first start with Docker

Docker is a powerful tool for building, distributing, and running applications in containers.

To get started with Docker, you'll first need to install it on your machine. You can find installation instructions for Docker here: https://docs.docker.com/engine/install/
Once you have Docker installed, you can begin using it to create and run containers. Containers allow you to package your application and its dependencies together, making it easy to deploy and run your application in any environment.
To create a Docker container, you'll need a Dockerfile. A Dockerfile is a simple text file that specifies the commands to be run to build a Docker image.
You can use the docker build command to build a Docker image from a Dockerfile. For example: docker build -t my-image .
Once you have a Docker image, you can use the docker run command to create and start a container from the image. For example: docker run -it my-image bash

Docker Containers

Docker containers are a lightweight and portable way to package and run applications. They allow you to package your application and its dependencies together, making it easy to deploy and run your application in any environment.
Containers are created from Docker images, which are executable packages that include everything your application needs to run. You can build your own images, or you can use pre-existing images from a registry like Docker Hub.
To create a container, you can use the docker run command. This command creates a new container from an image and starts the container running. For example: docker run -it my-image bash
Containers are isolated from one another, so you can run multiple containers on a single machine without them interfering with each other. This makes it easy to scale your applications and run multiple instances of them on the same host.
Containers are also ephemeral, meaning that they are created, run, and then discarded when they are no longer needed. This makes them very lightweight and easy to manage.
In addition to running containers, Docker also provides tools for managing and deploying containers at scale. You can use Docker Compose to define and run multi-container applications, and you can use Docker Swarm to create a cluster of Docker engines for deploying and scaling your applications.
That's a quick overview of Docker containers! If you want to learn more, check out the official Docker documentation: docs[.]docker[.]com. There are also plenty of online resources and tutorials available to help you get started with using containers.

webdevelopment #docker #containers

ACID properties of Database Explained

Sanjay Singh Rajpoot — Thu, 05 Jan 2023 18:58:09 +0000

ACID (Atomicity, Consistency, Isolation, Durability) is a set of properties that define the behavior of a SQL database. These properties ensure that database transactions are processed reliably and consistently, even in the face of system failures or concurrent access by multiple users.

Atomicity

Atomicity ensures that a database transaction is treated as a single unit of work, and either all of its operations are completed, or none of them are. If a transaction fails, any changes made by the transaction are rolled back, leaving the database in a consistent state.

Example: Imagine that you are transferring money from one bank account to another. This process involves two steps: withdrawing money from the first account, and depositing it into the second account. Atomicity ensures that these two steps are treated as a single unit of work, and either both are completed, or neither are. For example, if the withdrawal is successful but the deposit fails, the entire transaction will be rolled back and the money will not be transferred.

Consistency

Consistency ensures that a database is always in a valid state, and that any transaction that is committed leaves the database in a consistent state. This means that a transaction cannot violate any of the database's constraints or rules.

Example: Imagine that you are creating a new user account in a database. The database has a constraint that requires all user names to be unique. Consistency ensures that the database remains in a consistent state, and that any transaction that is committed leaves the database in a consistent state. This means that if you try to create a new user with a name that is already in use, the transaction will fail and the database will not be changed.

Isolation:

Isolation ensures that concurrent transactions do not interfere with each other. Each transaction operates on a snapshot of the database, and the changes made by one transaction are not visible to other transactions until the transaction is committed. This prevents data from being corrupted by concurrent access.

Example: Imagine that two users are trying to update the same record in a database at the same time. Isolation ensures that the changes made by one user are not visible to the other user until the transaction is committed. For example, if one user changes the name of the record from "John" to "Jane", and the other user changes the name from "John" to "Jack", the final name of the record will be either "Jane" or "Jack", but not both.

Durability

Durability ensures that once a transaction is committed, its changes are permanent and cannot be lost due to system failures. This is typically achieved through the use of a database log, which records the changes made by each transaction, and can be used to recover the database in the event of a failure.

Example: Imagine that you have just committed a transaction that updates a record in a database. Durability ensures that the changes made by the transaction are permanent and cannot be lost due to system failures. For example, if the database system crashes before the transaction is written to the log, the log can be used to restore the database to a consistent state and commit the transaction once the system is back up. This ensures that the changes made by the transaction are not lost.

Together, these properties ensure that a SQL database can be used to store and process data reliably and consistently, even in the face of system failures and concurrent access. They are an essential part of any database management system, and are what allow developers to build applications that depend on the integrity and consistency of the data stored in the database.

Adding JSON validation to structs in Go lang

Sanjay Singh Rajpoot — Sat, 31 Dec 2022 16:36:24 +0000

In this blog, let's try to implement JSON validation for the data strut that we made. Let's start with the basics

What is JSON validation?

JSON validation verifies that the data that is fed into the struct is of the right order and value. This means that you can set rules and regulations for the data that is being placed into the struct object. The function or the library that we can use for this purpose is called JSON Validator. JSON Validator verifies that your JavaScript Object Notation adheres to the JSON specification. JSON Validator verifies that your JavaScript Object Notation adheres to the JSON specification.

below is an example of JSON validation

type Product struct {
    // the id for the product
    //
    // required: false
    // min: 1
    ID int `json:"id"` // Unique identifier for the product

    // the name for this poduct
    //
    // required: true
    // max length: 255
    Name string `json:"name" validate:"required"`

    // the description for this poduct
    //
    // required: false
    // max length: 10000
    Description string `json:"description"`

    // the price for the product
    //
    // required: true
    // min: 0.01
    Price float32 `json:"price" validate:"required,gt=0"`

    // the SKU for the product
    //
    // required: true
    // pattern: [a-z]+-[a-z]+-[a-z]+
    SKU string `json:"sku" validate:"sku"`
}

What is the need for JSON validation?

There are a few reasons why JSON validation is important:

Data integrity: JSON validation helps ensure that the data in your JSON documents is accurate, complete, and consistent. By validating incoming JSON documents, you can catch errors and prevent invalid data from being processed by your application.

API consistency: If you're building an API that accepts JSON documents as input, JSON validation can help ensure that your API is consistent and predictable. By defining a schema for your JSON documents and validating incoming documents against that schema, you can ensure that your API receives the correct data and returns the expected results.

Security: JSON validation can also help improve the security of your application. By ensuring that your JSON documents are properly formatted and contain only valid data, you can prevent attacks such as injection attacks that might exploit vulnerabilities in your application.

Implementing JSON validation in GoLang
For JSON validation we will make use of a library called Validator v10.

Few Package validator features

Cross Field and Cross Struct validations by using validation tags or custom validators.
Slice, Array and Map diving, which allows any or all levels of a multidimensional field to be validated.
Ability to dive into both map keys and values for validation
Handles type interface by determining it's underlying type prior to validation.
Alias validation tags, which allows for mapping of several validations to a single tag for easier defining of validations on structs.

Installation

Use go get.




go get github.com/go-playground/validator/v10
Then import the validator package into your own code.



import "github.com/go-playground/validator/v10"

Once that is done let's create a simple struct to accept a few values and assign

some parameters to it.

type User struct {
    ID       int    `json:"id" validate:"required,gt=0"`
    Username string `json:"username" validate:"required,min=3,max=20"`
    Email    string `json:"email" validate:"required,email"`
}

In this example, we've defined a User struct with three fields: ID, Username, and Email. We've also added validation tags to each field, which specify the validation rules that should be applied to each field.

For example, the ID field has a required and gt validation tag, which means it must be a required field and must be greater than 0. The Username field has a required and min and max validation tag, which means it must be a required field and must be at least 3 characters long and at most 20 characters long. The Email field has a required and email validation tag, which means it must be a required field and must be a valid email address.

After this inside the main function create a new object of the Validator class and call its Struct() method. Passing it the JSON string and a pointer to a struct that represents the document. If the validation fails, the function returns an error containing a list of validation errors for each field that failed validation. If the validation succeeds, the function returns nil.

Entire code

package main


import (
    "fmt"
    "strings"

    "github.com/go-playground/validator/v10"
)

type User struct {
    ID       int    `json:"id" validate:"required,gt=0"`
    Username string `json:"username" validate:"required,min=3,max=20"`
    Email    string `json:"email" validate:"required,email"`
}

func main() {
    jsonStr := `{"id": 1, "username": "user", "email": "user@example.com"}`
    var user User
    validate := validator.New()
    if err := validate.Struct(jsonStr, &user); err != nil {
        errs := err.(validator.ValidationErrors)
        for _, fieldErr := range errs {
            fmt.Printf("field %s: %s\n", fieldErr.Field(), fieldErr.Tag())
        }
        return
    }
    fmt.Println("validation succeeded")
}

Thank You for reading!!

bye :)
type User struct {
ID int json:"id" validate:"required,gt=0"
Username string json:"username" validate:"required,min=3,max=20"
Email string json:"email" validate:"required,email"
}

func main() {
jsonStr := {"id": 1, "username": "user", "email": "user@example.com"}
var user User
validate := validator.New()
if err := validate.Struct(jsonStr, &user); err != nil {
errs := err.(validator.ValidationErrors)
for _, fieldErr := range errs {
fmt.Printf("field %s: %s\n", fieldErr.Field(), fieldErr.Tag())
}
return
}
fmt.Println("validation succeeded")
}
Thank You for reading!!

bye :)

MLH prep: My Experience

Sanjay Singh Rajpoot — Thu, 18 Aug 2022 13:30:00 +0000

Whoop things moved really fast in the past 3 weeks. For the past 3 weeks, I was working as an MLH prep fellow.

I got the mail from the MLH team that I was selected for the July prep program, Finally, the day arrived and I got the invitation link to join the first standup meeting. Before this, we were asked to choose the time slot for the stand-up meeting we had two options one was at 7:30 PM IST and another was 11:30 IST. I choose the 11:30 PM IST option as it was more suitable for me.

I joined with the zoom link provided in the mail. Our pod leader was Alex, we waited for around 5 mins for everyone to join then we started our interaction session. But this was not a regular interaction, our pod leader was assigned different break-out rooms randomly with one other person. Each of us was given a few questions that we had to ask each other so that we introduce the other person to the entire pod. I asked a few basic questions and the same was done by the other person. After a few minutes of chat, we were called back to the main room. I introduced the other to the pod and the same was done by the other team members.

Once the interaction was over we were assigned a team member with whom we have to work on an issue for the next week. We were given a sample repo that had a portfolio website made with Jekyll.

Project 1 — Portfolio website

It was a portfolio website made with Jekyll, HTML, CSS, and Ruby. For the first week, we all were assigned one issue on which we have to work on for the next week. I and my teammate picked the issue to create a profile card for each of the pod members. For this, we had to learn how does Jekyll work? we divided our work, I was working on creating a new page where all the information about the team member would be taken from a yml file and rendered on the profile page. My team member worked on linking all the profile page cards to the main page. While doing this we ran into a small problem, we didn’t have data about all the other team members. For this, I circulated a google form quickly and saved all the responses to the website’s yml file. Remember we only had 2days to finish this feature that is too with a team that you have meet just 24 hours ago.

Every day we had a standup in which we had to share our progress for the past 24 hours. We managed to get our PR merged and the feature was working as expected. In our 3rd standup, our pod leader merged all the PR that was made. We later found out that it was a complete mess as no one was working with the latest changes each PR changes some part of the code. So for the remaining days, we worked on fixing the design issue that occurred due to merge conflicts. The entire team was highly active and productive we all used to solve each other's problems and that thing taught me management skills. Finally, the site was ready, check it out!!

Pod.js is the name given to our pod. Some key features are

All the images of our team members are displayed at the top. A little description at the bottom of it.
Meet the pod section has the names and locations of all the pod members if you click on this a separate profile page will open with more information about the team member.
A world map with the location of all the team members
A leader board chats to display all the contributions made by fellow teammates made using Github APIs.
A lite and dark mode on all the pages.

Project 2 — Weather Application
The next project was a weather application. For this also we were given a sample template on which we have to work. This was a 2 weeks long project and our final project will be displayed on graduation day. We were again assigned with a teammate from our pod. I took the issue to add an interactive map to the website. For this, we took the help of a js library called map.js that would render a world map onto the website on hover it would give us latitude and latitude of the location. We then updated the Open Weather API to use coordinates in place names. Once this feature was added I created a new issue to dockerize the entire application and push its image to the docker hub.I had past working experience of using docker so I used it here the application was dockerized and pushed to the docker hub.

Then I started working with other folks to add a new feature that will display the Air Quality index of the desired location. One of my teammates gave me the API keys that I implemented using Axios to fetch the data and displayed it using a react js form layout. This project had a lot of components to it and whenever a single PR was merged we all started to get some merge conflicts. To fix this issue we have to actively inform each other about the changes we were making so that no two changes overlap with each other and we can update our local repo.

As I mentioned in the last project we ran into a lot of errors due to merge conflicts. This time we all were given a small task to review at least one from all the PR present. We all reviewed each other's PR and fixed a lot of merge conflicts overall we made 58 PRs and 30 issues in a span of 2 weeks. Finally, the project was complete. Checkout here!!

key features of the Weather App

Less than 100ms response time on APIs
Air Quality Index measures the location in real-time
Things to take at the desired location. A list of products that you can carry with you.
A 3D and a 2D map to search for places
7 days weather forecast of a particular location. And data for more days can be accessed with a simple click. ## Conclusion I am running out of words believe me!! It was one of the best experiences of my life. 12 people from all around the world meet 24 hours ago and start working to pull up this amazing project. I really have no idea how we did this. We all were positive about everything that we did I guess that is one of the reasons that kept us pushing further and further and remember we were not paid to do these things It was all done by our own will. The only thing that we were getting back was learning and experiences. Made some memorable friends and had unforgettable experiences!!

If I talk about numbers then we

we made 2 projects
we made 58+43 = 101 pull request in total
we made 20+35 = 55 issues in total
Had a titanic amount of learning!!

Teammates: Liuba ▪ Himanshu Thakur ▪ Chidera Innocent ▪ Elmar ▪ Shehab Adel ▪ Somaditya Singh ▪ Vy Nguyen ▪ Indira Sowy ▪ Julian Willis ▪ Di Wu ▪ A.S.L.Manasa ▪ Sadiq Babalola

Thank you

What is WebLN? Summer of Bitcoin 2022

Sanjay Singh Rajpoot — Sun, 07 Aug 2022 10:03:00 +0000

I got selected for the summer of bitcoin under Ride the lighting org. I will be working on implementing the WebLN feature to RTL’s Quick-pay extension. This will involve creating new files for the web ln features. This will enable the Quickpay Browser extension to give a better user experience to the people. Enabling support for WebLN in the Quickpay extension can help improve RTL’s ability to support other apps and browser extensions that may rely on this standard.

What is WebLN?

WebLN is a library and set of specifications for lightning apps and client providers to facilitate communication between apps and users’ lightning nodes in a secure way. It provides a programmatic, permissioned interface for letting applications ask users to send payments, generates invoices to receive payments, and much more. This documentation covers both how to use WebLN in your Lightning-driven applications and how to implement a provider.

Lightning Network is just another software, and we want to integrate it with the web, adding Lightning to web will go a long way. This is precisely the idea behind WebLN, which is a simple JavaScript tool to build Lightning-enabled browser extensions using makePayment and sendInvoice (again, the two core functions for any kind of money: sending and receiving).

WebLN offers a few advantages. First, JavaScript is nearly universal and almost thirty years old. Second WebLN delivers a better interface for the users, starting with the fact that you don’t need to use a second device. It feels native, not like a workaround. You also have access to all browser events, so a key press, a mouse click, a scroll position, etc. can all trigger a payment.

Installation

First Way: Install with Package Manager (Preferred)
Install the webln library using your package manager of choice:

npm: npm install --save webln
yarn: yarn add webln
And import it into your project wherever you need it:

import { requestProvider } from 'webln';

Second Way: Include Script (Alternative)

Alternatively, you can include a script on your page that will load the library. Be sure to keep the integrity check to prevent malicious Javascript from loading.

<script
  src="https://unpkg.com/webln@0.2.0/dist/webln.min.js"
  integrity="sha384-mTReBqbhPO7ljQeIoFaD1NYS2KiYMwFJhUNpdwLj+VIuhhjvHQlZ1XpwzAvd93nQ"
  crossorigin="anonymous"
></script>

Now the first that we need to do is to enable the WebLN provider in the web browser so that every component inside our website can use all the WebLN features. So in the next step, we will try to implement a WebLN provider with the help of which we will be use all the WebLN features.

Most of WebLN’s methods will prompt the user in some way, often times to make payments or have them provide the information they may feel is quite private. Before running requestProvider or other methods, make sure the user knows what your app does, and why they should allow your calls to run. Popping up as soon as they load a page will cause users to reject WebLN requests, or worse yet, bounce from your page.

requestProvider
To begin interacting with a user’s Lightning node, you’ll first need to request a WebLNProvider from them. WebLNProvider is a class that various clients implement and attach to your web session. Calling requestProvider will retrieve the provider for you, and prompt the client for permission to use it. Once you get the provider, you're free to call all of the other API methods.

WebLN getInfo function
Ask the user for some information about their node. The request may be rejected by the user depending on the provider implementation.

function getInfo(): Promise<GetInfoResponse>;
Response

interface GetInfoResponse = {
  node: {
    alias: string;
    pubkey: string;
    color?: string;
  };
}
webln.makeInvoice

This is used to create an Invoice for the user by the app. This will return a BOLT-11 invoice. There are many ways to request an invoice they are

By specifying an explicit amount, the user's provider should enforce that the user generate an invoice with a specific amount
When an explicit amount is not set, the user can return an invoice that has no amount specified, allowing the payment maker to send any amount
By specifying a minimumAmount and / or maximumAmount, the user's provider should enforce that the user generate an invoice with an amount field constrained by that amount
Amounts are denominated in satoshis. For large amounts, it’s recommended you use a big number library such asbn.jsas Javascript only supports 32 bit integers.

Parameters

function makeInvoice(args: RequestInvoiceArgs): Promise<RequestInvoiceResponse>;

interface RequestInvoiceArgs {
  amount?: string | number;
  defaultAmount?: string | number;
  minimumAmount?: string | number;
  maximumAmount?: string | number;
  defaultMemo?: string;
}

Response

interface RequestInvoiceResponse {
  paymentRequest: string;
}

What if there is an error?

To handle this test case both apps and providers can make use of WebLN’s pre-defined errors. They can be found in webln/lib/errors and should be used when throwing and handling errors to best inform the user of what's going on:

WebLN Error
And the provider should throw the correct error when possible:

WebLN Error Provider
Resources
https://www.npmjs.com/package/webln
https://github.com/joule-labs/webln-docs
https://webln.dev/#/api/make-invoice
https://medium.com/@wbobeirne/making-a-lightning-web-app-part-4-c0997f4353b8
https://github.com/joule-labs/webln/issues/13

LFX Mid-Evaluation

Sanjay Singh Rajpoot — Sun, 10 Jul 2022 12:32:39 +0000

My LFX mentorship started on 1 June with the Moja Global Organisation. By the end of next week (15 July) will have our first evaluation after this we will receive our first stipend. I have already written one blog for the first week you can find it here.

So far things are going really great. I am working on the FLINT Cloud project which is used for the continuous deployment of FLINT. The project also aims to simplify the process of installation by supporting a single command or step installation process. Check out this link for more info FLINT.Cloud.

In LFX mentorship doesn’t follow any list check method to track your progress. In this, if you are learning and moving forward at your own pace then you can easily pass the evaluations. Unlike other open-source programs where you have to complete the work by a given deadline.

My Work so far

After first week was over I started working on the two tasks that I was given one of them was to implement

CI/CD for FLINT.Cloud’s REST API FLINT.Example and REST API GCBM using GitHub Actions and Azure Container Registry.

For this, I was given Azure login credentials that I have to use to make new container images whenever new code was pushed to the main branch of FLINT. Cloud. To make this work I used Github Actions to create a new file called push-to-azure.yaml. This file will be executed if any new changes are made to the main branch of FLINT cloud. Inside this file, I created new where three major sections

The first step was to log in via Azure credentials which were given to me earlier. With the help of this Github would know on which Azure Cloud Registry they have to push the changes.
The next step was to build a new docker image with all the latest changes and an updated tag.
At last, we have to push this docker image to the Azure Container Registry.
I made PRs for all the changes mentioned above. I was facing a bug that my mentor fixed which was later pushed to the repo.

Integrating Terraform scripts for FLINT.Cloud for Azure and created a production-level deployment for FLINT.Cloud

This was my next task to implement Terraform Scripts. Most of the work for this part was done by my mentor. I tested the PR on my machine and it was working like a charm.

After this, I collaborate with my partner Janvi, she was facing some errors in running a Kubernetes instance. I tested her PR on my machine as I was using ubuntu and she was using windows. In all this process I learned how to deploy a docker container to Kubernetes and all the basics of Kubernetes like services pods, LoadBalanceer, Ingress policy, and a lot of StackOverflow :) Once I tested the PR there were a few bugs that Janvi fixed and the PR that she made was running on almost all the systems. So kudos for that!!’

We had our second meeting with the mentor around the last week of June. We were given small tasks for the upcoming weeks. I was asked to review some PRs for the FLINT-UI and I joined one discussion regarding the creation of new endpoints for GCBM.

In between, I was reviewing PR for the FLINT-UI. I made some changes to the page which is used to modify the GCBM inputs (PR linked below).

https://github.com/moja-global/FLINT-UI/pull/326

As I mentioned above I started working on creating the new upload endpoints which will add new functionality to the website. We have a Documentation Working Group meeting(DWG), In which we finalized the user flow for the GCBM simulation. I was asked to create new endpoints for the title and upload configuration files separately for all the categories. Through these endpoints, users will be able to upload files separately for each category.

https://github.com/moja-global/FLINT.Cloud/pull/145

For the next week, I will be working on the FLINT cloud itself few more changes are to be made to make it work properly.

Thank You

This is why everyone is using Reactjs

Sanjay Singh Rajpoot — Sat, 11 Jun 2022 04:26:30 +0000

React Js is one of the most popular front-end frameworks to use these days. It is playing an essential role in the front-end ecosystem.

But what makes it so special?

here are some key feature that comes with React Js

Simplicity
ReactJS uses JSX file which makes the application simple and to code as well as understand. We know that ReactJS is a component-based approach which makes the code reusable as your need. This makes it simple to use and learn.
Declarative UI
This feature makes React code more readable and easier to fix bugs. React JS is the best platform to develop UIs that are both exciting and engaging not just for web apps, but mobile apps as well.
Enables Building Rich UI
The UI of an app is extremely important nowadays; an app with a great UI that offers an exciting browsing and shopping experience to users definitely has a much better chance of succeeding than one with a poor interface.
One-way Data Binding:
One-way data binding, the name itself says that it is a one-direction flow. The data in react flows only in one direction i.e. the data is transferred from top to bottom i.e. from parent components to child components.
Virtual DOM
A virtual DOM object is a representation of the original DOM object. It works like a one-way data binding. Whenever any modifications happen in the web application, the entire UI is re-rendered in virtual DOM representation.
JSX
JSX stands for JavaScript XML. It is a JavaScript syntax extension. Its an XML or HTML like syntax used by ReactJS. This syntax is processed into JavaScript calls of React Framework.
Performance
ReactJS is known to be a great performer. This feature makes it much better than other frameworks out there today. The reason behind this is that it manages a virtual DOM. The DOM is a cross-platform and programming API which deals with HTML, XML or XHTML.

Give it a like if you make it this far!!

Follow for more web dev insights :)

reactjs #javascript #webdevelpoment

LFX Mentorship Week 1 Experience

Sanjay Singh Rajpoot — Sun, 05 Jun 2022 15:20:21 +0000

hello, I am Sanjay Singh Rajpoot, I am currently a third-year engineering student at IET DAVV Indore. I like to contribute to open source a lot. I have been contributing to open-source for 2 years now. I like to real-world problems rather than solve questions on a coding platform. In this post, I will discuss all the key steps that I have taken so far. Let’s get started.

Moja Global and LFX

Application Process

For those who are unaware of LFX let me give you a quick info

The Linux Foundation Mentorship Program is designed to help developers — many of whom are first-time open source contributors — with necessary skills and resources to learn, experiment, and contribute effectively to open source communities. By participating in a mentorship program, mentees have the opportunity to learn from experienced open source contributors as a segue to get internship and job opportunities upon graduation.

I applied through the LFX portal. I uploaded my Resume, Cover Letter and Work Eligibility Certificate (a type of NOC). Once all these things are done you just have to wait for the results.

Now what’s important here is I am contributing to Moja Global for around 6 months now from a small typo to big features I have done them all. So my past contribution became a major reason for my selection without it my application would be viewed like all other applications.

To increase your chances of getting selected talk to the mentor make some contribution to the community and be active. I will write a detailed post regarding this.

Program Timelines

It usually happens three times a year, so you can plan and apply accordingly,

Spring Term: March 1st — May 31st
Summer Term: June 1st — August 31st
Fall Term: September 1st — Nov 30th

For more information, you can check the LFX Mentorship documentation.

Week 1

After getting the result I was really excited to start my journey as an LFX mentee. As I already mentioned I was already a part of the community for a long time. So for me, things were not that new. The thing that excited me the most was the technologies that I have to use.

Mostly I will be working on the Infrastructure side of FLINT. Cloud. I will use Terraform, Azure, Github actions, CI/CD, Docker and a lot more. As per the requirement, I have to learn new things and solve new problems.

For the first week, my mentor gave me some responsibilities like reviewing some PRs making code production ready and a few minor bug fixes. For the next few days, I worked on implementing Lighthouse CI. It is used to calculate the SEO performance of the website along with different standard measures.

We had a google meet in which our mentor told us about our future goals and gave us a few tips to keep things in the exact direction. I have a partner, and along with her, I will be working on a few problems. So few tasks are team-based and the others are self-based.

So this was all about it. I am learning, hustling, making things, breaking things and a lot more. However, I am enjoying things the most.

Quick info about Moja Global

Moja global is a not for profit, collaborative project that brings together a community of experts to develop open-source software that allows users to accurately and affordably estimate greenhouse gas emissions and removals from the AFOLU sector. The project’s members aim to support the widest possible use of credible emissions estimation software.

Check out their GitHub repo and thank me later bye :)

Summer Vacation and Coding

Sanjay Singh Rajpoot — Sat, 28 May 2022 05:07:09 +0000

It's summer time!!

I hope everyone is done with their exams, and now we have a good long summer break.

You can do several things this summer break if I have to classify them on a larger scale then we have two different ways DSA and Development. Most of the students will try to work in the Development or DSA domain.

For this post let's focus on the development side,

There are different paths that you can take to start your development journey. It's not like DSA where you have a defined set of questions that you can solve.
let's talk about one of the simplest paths that one can follow for development. Pick a few programming languages for beginners it would be HTML, CSS and Javascript.
First, try to make a single page application(SPA) it can be related to your interest or you can make your own portfolio website.
Now next step would be to create a website where you want to take user feedback. Like in the form of a Login page or some sort of survey website. Again it's up to your how you want to explore the web world. For this, you need a few more technologies my preferences would be PHP and MySQL.
Your website is ready but it still looks old, lacks responsiveness and is slow to use. To fix this issue you have to use certain CSS frameworks such TailwindCSS, and Chakra UI along with Frontend frameworks such ReactJS, and Angular.
Now, the next step would be to save your form data on a remote database. You can use Postgres (SQL), and MongoDB(NoSQL) databases. To make this happen effect you have to use certain frameworks such as Node js, Django, and React Js.

So now you have made a really good project with the help of different tech stacks. You can put this project in your resume and look for some startups which work on the same tech stack as you did.

Happy Learning :)

summer #webdevelopment #learning #project #html #css

Tricks to create an impressive GitHub repository 🔥🔥

Sanjay Singh Rajpoot — Mon, 09 May 2022 17:25:43 +0000

Here are some of the tricks to create an impressive GitHub repository

We all have seen the same old repository as every other repository looks the same and feels the same. If you want to attract some attention then here are some simple tricks

𝗨𝘀𝗲 𝗗𝗲𝘀𝗰𝗿𝗶𝗽𝘁𝗶𝘃𝗲 𝗖𝗼𝗺𝗺𝗶𝘁 𝗠𝗲𝘀𝘀𝗮𝗴𝗲𝘀 Using descriptive commit messages might look like a chore, but it too helps in taking the appeal of the repository higher. Make sure the commit message is explanatory.

There are various schools of commit message structures, any of which is acceptable. I personally like the following one:

[optional scope]:

𝗔𝗱𝗱 𝗘𝗺𝗼𝗷𝗶 𝗮𝗻𝗱 𝗚𝗜𝗙𝘀 𝗶𝗻 𝘁𝗵𝗲 𝗥𝗲𝗮𝗱𝗠𝗲 𝗳𝗶𝗹𝗲 The ReadME file is the first thing that a user sees. The ReadMe is the first thing a visitor sees when they visit the repository, so taking some time to create a polished repository is crucial. It should describe what problem the code solves, how to set it up, and any other relevant information.

Use backticks to highlight the code snippets
Add some hyperlinks
Add emojis if required
Add stat figures like no. of stars, commits, PRs etc.

𝗔𝗱𝗱 𝗟𝗶𝗰𝗲𝗻𝘀𝗲 No point denying it, this is the most boring step, but essential for fair use of the repository. Moreover, it also shows up in the info tab, so just get it done with.

To add a License, create a file called LICENSE at the root of the project.

𝗔𝗱𝗱 𝗧𝗮𝗴𝘀 𝗮𝗻𝗱 𝗼𝗻𝗲 𝗹𝗶𝗻𝗸
Adding tags is the next and most crucial step in this article. It not only makes it easier for GitHub to promote the repository but also makes it look much more professional!
𝗔𝗱𝗱 𝗗𝗲𝘀𝗰𝗿𝗶𝗽𝘁𝗶𝗼𝗻 (𝘄𝗶𝘁𝗵 𝗘𝗺𝗼𝗷𝗶𝘀 & 𝗟𝗶𝗻𝗸)
This is the lowest hanging fruit in creating an impressive GitHub repository. You can just add a short description of the repository to heighten its appeal. Make sure to throw in some emojis too 😉.

These are some of the most common tricks for the GitHub repository. That's all for today guys, follow for more tips and tricks :)

github #project #coding #webdevelopment

HTTP Request Methods - GET Vs POST Vs PUT

Sanjay Singh Rajpoot — Tue, 26 Apr 2022 05:51:10 +0000

What is HTTP?

HTTP is a protocol, or a definite set of rules, for accessing resources on the web. Resources could mean anything from HTML files to data from a database, photos, text, and so on.

These resources are made available to us via an API and we make requests to these APIs via the HTTP protocol. API stands for application programming interface. It is the mechanism that allows developers to request resources.

Client-Server Architecture

In order to understand the HTTP methods, it’s important to cover the concept of client/server architecture. This architecture describes how all web applications work and defines the rules for how they communicate.

A client application is the one that a user is actually interacting with, that's displaying the content. A server application is the one that sends the content, or resource, to your client application. A server application is a program that is running somewhere, listening, and waiting for a request.

The main reason for this separation is to secure sensitive information. Your entire client application gets downloaded into the browser, and all of the data can be accessed by anyone accessing your web page.

Why We Need A Server-Client Architecture

Let’s say you were building a weather web app, for example. The weather app that your user is going to interact with is the client application – it has buttons, a search bar, and displays data like city name, current temperature, AQI, and so on.

This weather app wouldn’t have every city and its weather information coded directly into it. This would make the app bloated and slow, would take forever to research and manually add to a database, and would be a headache to update every single day.

HTTP Methods Explained

Now that we know what HTTP is and why it’s used, let’s talk about the different methods we have available to us.

1. HTTP GET

Use GET requests to retrieve resource representation/information only – and not modify it in any way. As GET requests do not change the resource’s state, these are said to be safe methods.

Additionally, GET APIs should be idempotent. Making multiple identical requests must produce the same result every time until another API (POST or PUT) has changed the state of the resource on the server.

If the Request-URI refers to a data-producing process, it is the produced data that shall be returned as the entity in the response and not the source text of the process, unless that text happens to be the output of the process.

1.1. GET API Response Codes

For any given HTTP GET API, if the resource is found on the server, then it must return HTTP response code 200 (OK) – along with the response body, which is usually either XML or JSON content (due to their platform-independent nature).
In case the resource is NOT found on the server then API must return HTTP response code 404 (NOT FOUND).
Similarly, if it is determined that the GET request itself is not correctly formed then the server will return the HTTP response code 400 (BAD REQUEST).

1.2. Example URIs

HTTP GET http://www.appdomain.com/users
HTTP GET http://www.appdomain.com/users?size=20&page=5
HTTP GET http://www.appdomain.com/users/123
HTTP GET http://www.appdomain.com/users/123/address

2. HTTP POST

Use POST APIs to create new subordinate resources, e.g., a file is subordinate to a directory containing it or a row is subordinate to a database table.

When talking strictly about REST, POST methods are used to create a new resource into the collection of resources.

Responses to this method are not cacheable unless the response includes appropriate Cache-Control or Expires header fields.

Please note that POST is neither safe nor idempotent, and invoking two identical POST requests will result in two different resources containing the same information (except resource ids).

2.1. POST API Response Codes

Ideally, if a resource has been created on the origin server, the response SHOULD be HTTP response code 201 (Created) and contain an entity that describes the status of the request and refers to the new resource, and a Location header.
Many times, the action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either HTTP response code 200 (OK) or 204 (No Content) is the appropriate response status.

2.2. Example URIs

HTTP POST http://www.appdomain.com/users
HTTP POST http://www.appdomain.com/users/123/accounts

3. HTTP PUT

Use PUT APIs primarily to update an existing resource (if the resource does not exist, then API may decide to create a new resource or not).

If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries SHOULD be treated as stale. Responses to PUT method are not cacheable.

3.1. PUT API Response Codes

If a new resource has been created by the PUT API, the origin server MUST inform the user agent via the HTTP response code 201 (Created) response.
If an existing resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent to indicate successful completion of the request.

3.2. Example URIs

HTTP PUT http://www.appdomain.com/users/123
HTTP PUT http://www.appdomain.com/users/123/accounts/456

4. HTTP DELETE

As the name applies, DELETE APIs delete the resources (identified by the Request-URI).

DELETE operations are idempotent. If you DELETE a resource, it’s removed from the collection of resources.

Some may argue that it makes the DELETE method non-idempotent. It’s a matter of discussion and personal opinion.

If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries SHOULD be treated as stale. Responses to this method are not cacheable.

4.1. DELETE API Response Codes

A successful response of DELETE requests SHOULD be an HTTP response code 200 (OK) if the response includes an entity describing the status.
The status should be 202 (Accepted) if the action has been queued.
The status should be 204 (No Content) if the action has been performed but the response does not include an entity.
Repeatedly calling DELETE API on that resource will not change the outcome – however, calling DELETE on a resource a second time will return a 404 (NOT FOUND) since it was already removed. ### 4.2. Example URIs

HTTP DELETE http://www.appdomain.com/users/123
HTTP DELETE http://www.appdomain.com/users/123/accounts/456

What’s the difference between PUT and POST?

PUT requests are idempotent, meaning that executing the same PUT request will always produce the same result.

On the other hand, a POST will produce different outcomes. If you execute a POST request multiple times, you'll create a new resource multiple times despite them having the same data being passed in.

Using a restaurant analogy, POSTing multiple times would create multiple separate orders, whereas multiple PUT requests will update the same existing order.

Conclusion

Go ahead and give yourself a pat on the back because you've learned about web APIs, the HTTP protocol, the client-server architecture – and you've also made your first requests. All the HTTP request where discussed here now try to practically test these methods on your machine :)

🎺🎸 🎻 !!!Happy Coding!!!🎺🎸 🎻….