19 Jan 2017

Understanding a merge commit - git

This is what I sent today to my colleagues while explaining the reason for mysterious changes in a pull-request
That blank merge commit is the culprit. All changes which should be result of merge are blown away.
First let's understand that a merge commit is also a commit with changes. Changes in source branch since its diversion (from destination branch) are auto-magically done as part of merge commit in destination branch. 
So a merge occurred without any changes (if its been blown away as it has been the case) in merge commit, is basically a reversal of all changes that have occurred in source branch since the destination branch diverged from it. Hope this clarifies the mystery.
To visualise how chain of commits are formed, diverged and merged, you can refer to the image in Understanding what GIT does under the hood rather than only learning commands and wondering

22 Aug 2016

Basics of Basics of Web Application Development - Crash Course

1. Protocol - Protocol means,
    • same terms that are understood or agreed by two or more parties
    • a language (or call it sign language or code words) that is understood by two or more parties
2. HTTP - is a protocol/language of web. Web clients and web servers talk in this language with each others. For e.g.

Client says (in its code language i.e. HTTP Request) -

POST /v2/sessiontoken HTTP/1.1
Host: app.kashflow.com
Content-Type: application/json
Accept: application/json

{"username":"ismails", "password":"********"}
Interpretation of code language -
  • Firstly it is said by client which means it is a request - HTTP request.
  • POST - it's an HTTP method. This means it is a request to create a resource. More details here.
  • /v2/sessiontoken - it is a part of URL i.e. it will be appended to value of host header which is provided in 2nd line. So whole URL will form like http://app.kashflow.com/v2/sessiontoken
  • HTTP/1.1 - This request is created using HTTP/1.1 version of sign/code language. It's modern. It might contain modern slangs ;-)
  • From 2nd line starts all request headers and their values follow after colon sign i.e. `:`. Each header has a different meaning and the other party understands it's value accordingly. 
    • Host- request will go to this server address
    • Content-Type - It is a message for the server that the body of this request that follows (last line), is in JSON format. If you want to interpret it please make a note about this
    • Accept - means "As a client I will only understand if you return me a response body which is in JSON format" 
  • After an extra line break comes body of the request
So this is what client has told to the server. Now server gets the request. It understands/interprets/decodes the request. It processes i.e. takes action as per the request. (In this case, client expects the server to verify the username and password, create an authentication token  and respond with the same if username and password are valid. This part is creation/invention of a developer's mind. You as a developer will decide what you want the client to request and program the server to do as per the request.) Finally server informs back (HTTP Response) to the requester (client) about what action it took.

Server says (in it's code language i.e. HTTP Response)
HTTP/1.1 201 Created
Content-Length: 829
Content-Type: application/json; charset=utf-8


Interpretation of code language -
  • HTTP/1.1 - it specifies version of sign/code language this request in.
  • 201 Created - It's HTTP status code. This means as per your request authentication token has been created. Different status codes mean differently. Look for more details here, here or here.
  • Then starts HTTP response headers. Similar to request headers, each one has a meaning. 
    • Content-Length specifies how long the content of body is
    • Content-Type specifies format of response in the body
  • After an extra line break comes body of the response
If for example the username and passwords are invalid, the response would have been different

HTTP/1.1 400 Bad Request
Content-Length: 71
Content-Type: application/json; charset=utf-8

{"Message":"Invalid username or password", "Error":"InvalidCredentials"}

Look at HTTP status codes to decode this response.

3. Browser is an HTTP client.
So let's understand how browser talks HTTP.

  1. Fire up chrome 
  2. Hit F12 key to open up chrome dev tools.
  3. Select network tab on chrome dev tools
  4. Tick "Preserve log" checkbox
  5. Type google.com in address bar (in chrome main window)
  6. Hit enter.
  7. Select the first request from the list in chrome dev tools window. 
This is what I get to see. Let's decode it.

HTTP Request
  • GET request to `/` (it's a forward slash) i.e. root of the host google.com using HTTP 1.1 version of language
  • Browser `Accept`s or understands only one of these "text/html, application/xhtml+xml, application/xml" other certain image formats etc
HTTP Response
  • 302 Found . It means server is saying that "You have reached at correct address and with valid parcel (request), unfortunately, the information (resource) you are looking for has moved to other place (specified in location header)"
  • Look at the 2nd request in the list (chrome dev tools). Is it a request to same URL which is specified in location header? Yes it is. Browser has interpreted the response correctly and requested other URL as per the response it got from the server.
More walk-through
Basic concepts of web applications, how they work and the HTTP protocol
HTTP in depth

Basic HTTP codes for quick reference
  • 2xx - Success codes
    • 200 - Success - OK - this simply means whatever you have requested is served. Meaning differs as per the request method and content.
    • 201 - Created - this is generally a response of POST or PUT requests
    • 204 - No Content - The server has successfully fulfilled the request and that there is no additional content to send in the response payload body.
    • 3xx - Redirection codes
      • 301 - Redirction - the information you have requested is now available at some other URL which is provided in `location` header
      • 302 - Redirection  - same as above. But a newer version. Look for more details on HTTP specs
      • 4xx - Bad Request codes
        • 400 - Simple bad request i.e. something bad with the request body. Change it correct it and send whatever server expects. Detailed explaination should be provided in response body

      2 Mar 2016

      Understanding what GIT does under the hood rather than only learning commands and wondering

      you can only really use Git if you understand how Git works


      You get a .git folder when you do git init or git clone for the first time. That's your repository. Sometimes also referred to as local repository.

      A git repository contains, among other things, the following:
      • A set of commit objects.
      • A set of references to commit objects, called heads (branch, tag and SHA1 names are types of head).

      Remote Repository

      If you have cloned from somewhere, so the URL/path (yes it can be local or on network also) you used to clone contains your remote repository. It is identical to what you get in your .git folder after cloning. `git remote -v` command lists all remotes available in the current repository and it's URL.

      How GIT stores your commits or commit objects

      A commit object contains 3 main things:
      • Reference to the parent commit
      • Changes  (adds/updates/deletes of words/lines/files) since parent commit or changes of this commit (it doesn't store whole file as it happens in centralized Version Control Systems like SVN/TFS/VSS/Perforce)
      • An SHA1 name(38f7a44232faf4651dc085495e4ea770c951d7b2), a 40-character string that uniquely identifies the commit object. The name is composed of a hash of  relevant aspects of the commit i.e. changes, timestamp, parent commit SHA1 name, author etc.


      Branches are basically references of commits or easy way to refer to commits i.e. ugly SHA1 name. In some of the cases when you merge/rebase, these markers for SHA1 name move from one commit to another commit rather than moving/modifying around multiple commits. We will get to know more about it in upcoming parts of this series.

      Credits: This post is inspired by Understanding Git Conceptually.

      26 May 2015

      View GIT branch history/log without checking-out/switching to that branch

      It is simple.

      # fetch from remote repository just in case you don't have those change yet
      git fetch
      #because you might not it's have local tracking branch. Hence origin
      gitk origin/<branchname> 

      7 Apr 2015

      REST - Representational State Transfer

      Below are list of articles about REST Architecture

      Intro to REST

      REST - basics
      1. Basics - http://en.wikipedia.org/wiki/Representational_State_Transfer
      2. Basics - http://tomayko.com/writings/rest-to-my-wife
      3. Basics - http://net.tutsplus.com/tutorials/other/a-beginners-introduction-to-http-and-rest/
      4. Basics - http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
      5. Basics - https://www.ibm.com/developerworks/webservices/library/ws-restful/
      6. Basics - http://stackoverflow.com/questions/671118/what-exactly-is-restful-programming
      7. Basics - http://rest.elkstein.org/2008/02/what-is-rest.html
      8. Basics - http://www.xfront.com/REST-Web-Services.html - Well explained characteristics
      9. Basics - http://www.infoq.com/articles/rest-introduction

      RESTful in practice
      1. http://www.codeproject.com/KB/architecture/RESTWebServicesPart1.aspx
      2. http://www.codeproject.com/KB/architecture/RESTWebServicesPart2.aspx
      3. http://duncan-cragg.org/blog/post/setting-data-rest-dialogues/
      4. http://www.xml.com/pub/a/2004/08/11/rest.html
      5. http://www.infoq.com/articles/tilkov-rest-doubts
      6. http://www.infoq.com/articles/designing-restful-http-apps-roth

      REST comparison with peers
      1. http://stackoverflow.com/questions/853620/secure-web-services-rest-over-https-vs-soap-ws-security-which-is-better
      2. http://stackoverflow.com/questions/209905/rest-and-soap
      3. http://stackoverflow.com/questions/106546/performance-of-soap-vs-xml-rpc-or-rest
      4. http://stackoverflow.com/questions/4163066/rest-vs-soap-has-rest-a-better-performance
      5. http://stackoverflow.com/questions/90451/why-would-one-use-rest-instead-of-web-services

      http://msdn.microsoft.com/en-us/library/dd203052.aspx [A Guide to Designing and Building RESTful Web Services with WCF 3.5]

      *Note:-Can be implemented in WCF Web API

      *WCF Web API FAQ


      Hypertext Transfer Protocol (HTTP) Status Code Registry (might be useful)
      1. http://www.iana.org/assignments/http-status-codes

      RESTful Practises
      1. https://fedorahosted.org/pulp/wiki/RestfulPractices

      Cloud REST API
      1. http://fedoraproject.org/wiki/Cloud_APIs_REST_Style_Guide

      Portable Data Formats in Represantations - [RESTful Web Service Cookbook - CHAPTER 3.9]
      1. http://books.xmlschemata.org/relaxng/relax-CHP-8-SECT-1.html (have a look at the numeric datatype section)
      2. http://en.wikipedia.org/wiki/ISO_3166-1 (Country code represantation)
      3. http://en.wikipedia.org/wiki/ISO_4217 (alphabetic and numeric codes for denoting currency)
      4. http://www.neilvandyke.org/rfc3339-scheme/ (date, time and date-time representation)
      5. http://www.w3.org/International/articles/language-tags/ (language tags)
      6. http://www.codeproject.com/KB/dotnet/Using_time_zones_in_NET.aspx (Olson time zone database to convey time zones)



      9 Oct 2014

      GIT - reverting a merge

      Why try best to avoid it?
      TL;DR. precaution is better than cure.
      For example, think about what reverting a merge (and then reverting the
      revert) does to bisectability. Ignore the fact that the revert of a revert
      is undoing it - just think of it as a "single commit that does a lot".
      Because that is what it does. When you have a problem you are chasing down, and you hit a "revert this
      merge", what you're hitting is essentially a single commit that contains
      all the changes (but obviously in reverse) of all the commits that got
      merged. So it's debugging hell, because now you don't have lots of small
      changes that you can try to pinpoint which _part_ of it changes. But does it all work? Sure it does. You can revert a merge, and from a
      purely technical angle, git did it very naturally and had no real
      troubles. It just considered it a change from "state before merge" to
      "state after merge", and that was it. Nothing complicated, nothing odd,
      nothing really dangerous. Git will do it without even thinking about it. So from a technical angle, there's nothing wrong with reverting a merge,
      but from a workflow angle it's something that you generally should try to
      Source: https://www.kernel.org/pub/software/scm/git/docs/howto/revert-a-faulty-merge.txt

      The article also explains in detail about options available when you fall into such situations that you will have to revert anyway.