Script to do svn merge

1st argument is the URL you want to merge from.
2nd argument is the svn log's begin date.
3rd argument is the svn log's end date.

Why IP is called connectionless protocol and TCP is called as connection-oriented protocol?

Answer

http://stackoverflow.com/questions/4533686/why-do-we-say-the-ip-protocol-in-tcp-ip-suite-is-connectionless

This has nothing to do with wired or wireless networks.

Need for IP addresses

Problem Statement:

Why do we need IP addresses in the first place as we already have ample amount of unique Ethernet addresses.

Reason:

Ethernet addresses are unique physical address whereas IP addresses are unique logical address across the world. So, grouping of machines under a single sub-net is very easy compared to Ethernet addresses. Machines can be added/removed easily in sub-net consisting of machines having logical IP addresses.

Also, for each group of IP addresses, it is easy to enforce restrictions. ISPs know which set of IP addresses is allocated for which country and so, it becomes easy for them to block certain contents.

Also, as mentioned in https://www.quora.com/When-a-MAC-address-itself-is-unique-why-do-we-still-need-an-IP-address-to-uniquely-identify-a-system-on-a-network, it is easy to build routing table based on IP addresses as MAC address contains no information about machine's location.

Babun shell

Babun is linux kind of shell to work in windows platform. I first came to know about babun from zeroturnaround article. You can read about babun more here. Here are the list of features which

a) scp causes some trouble when working with cygwin. scp works well with babun. The experience is the same as if the machine is Linux. Babun also helps auto completing the hostname (pressing tab enables this) for the 2nd and subsequent times when doing ssh/scp.

b) To run the previous command which started with, for example, xyz, we run !xyz in linux. The drawback is that we don't know what command will run till the command gets executed (at least this happens in sles machines). But in babun after we type !xy and pressing tab it displays what was the command that was last repeated which started with xy. Very much helpful.

c) Babun also displays the working directory at the right hand side of the place where we type commands. It helps us to know in which is our current working directory without typing pwd.

d) Babun shell, by default, has huge amount of buffer size (99000 lines) which helps us to know all the commands that got executed from the time the shell got launched. This is not by default enabled in windows cmd. Max height size of windows cmd's screen buffer size is 9999 lines.

e) history command is also supported.

As babun is built on top of cygwin, it supports vi editor, find, cd -, grep, ls, pwd and other linux commands. 

There are some linux commands like ifconfig, which are not supported.

mvn install -pl with -am/-amd usage

mvn install -pl with -am/-amd is very powerful. I first came to know about this usage in this article.

One use case that I can think of is this. Assume we are making changes in project D. It depends on projects E, F, G, & H. Now assume we have done update of our local codebase from repo and it caused changes in all of the projects in our local codebase (to keep our scenario simple). Now to build project D, we can run "mvn install -pl <groupId:artifactId of project D> -am" which will make sure maven runs the E, F, G & H first before running our target project D.

-amd option is useful in the following scenario. Assume project X is where we are making changes and project A, B, C depend on X. Now we are making changes in project X, and we want to check whether project A, B, C are still compiling fine. Now we can run "mvn install -pl <groupId:artifactId of project X> -amd" which will do the job. 

These commands has to be run from the root of the code repo (or ... which I leave it as an exercise. It has something to do with lowest common denominator).

Junit and TestNG - An important difference to be noted

Assume the tests are run sequentially to keep things simple. Have a look at the following code:

a) Using Junit

import java.util.ArrayList;
import java.util.List;

import org.junit.Before;
import org.junit.Test;

public class JunitExample
{
    private List<Integer> ints = new ArrayList<>();
   
    @Before
    public void initialize()
    {
        ints.add(1);
        ints.add(2);
        ints.add(3);
    }

    @Test
    public void test1()
    {
        ints.add(4);
        System.out.println(ints);
    }
   
    @Test
    public void test2()
    {
        ints.add(5);
        System.out.println(ints);
    }
}

Running the tests sequentially outputs
[1, 2, 3, 4]
[1, 2, 3, 5]

b) Using TestNG

import java.util.ArrayList;
import java.util.List;

import org.testng.annotations.BeforeTest;
import org.testng.annotations.Test;


public class TestNGExample
{
    private List<Integer> ints = new ArrayList<>();
   
    @BeforeTest
    public void initialize()
    {
        ints.add(1);
        ints.add(2);
        ints.add(3);
    }

    @Test
    public void test1()
    {
        ints.add(4);
        System.out.println(ints);
    }
   
    @Test
    public void test2()
    {
        ints.add(4);
        System.out.println(ints);
    }
}

This outputs,
[1, 2, 3, 4]
[1, 2, 3, 4, 4]

Surprised?. This is because Junit creates a separate instance of test class for each and every tests that are present. When test1 begins to gets executed ints consisted of [1, 2, 3] and when test2 begins to gets executed too it consisted of [1, 2, 3]. No surprises here. We ended up with [1, 2, 3, 4] on both these cases.

But in case of TestNG, there is only one instance of test class that gets created and that will be used by all test methods. So, before test1 got executed, ints were [1, 2, 3] and by the time test1 got completed, ints were [1, 2, 3, 4]. Now when test2 begins to get executed ints are already [1, 2, 3, 4] and we add up 4 again to ints. So, finally we ended up with [1, 2, 3, 4, 4].

When the tests are run in parallel, in case of TestNG, the behavior is undefined if instance variables are used without considering multithreading scenarios.

svn checkout and update --depth/--set-depth option usage

Assume you have a project structure as this: You have a core-spoke model. The spokes depend on core piece. Different teams of developers are working with different sets of core and spoke projects. You have this project in SVN repository.

CodebaseRoot -> Core
                          -> Core1
                          -> Core2
                          -> .........
                          -> Core k
                       -> Spoke
                          -> Spoke1
                          -> Spoke2
                          -> ..........
                          -> Spoke n

Where each spoke component is dependent on some/all of the core components.

Assume this is a large codebase and you might need to work only with subset of spoke and core components. You need not checkout the whole codebase.

Selectively checking out the codebase can be done using the following steps: Be under the directory where you want to check out the code.

a) Run svn co --depth=immediates at <CodebaseRootURL>
    Now you have a local copy containing only Core and Spoke empty directories.

b) Run cd Core. Then run svn up --set-depth=infinity with <CodebaseRoot>/Core URL.
    This will checkout the core code piece completely. You can selectively checkout  too. For now let us assume that our spoke projects depend on all core pieces.

c) Run cd ../Spoke. Then run svn up --set-depth=immediates with <CodeBaseRoot>/Spoke URL. Now the set-depth=immediates option is used as this will checkout empty directories of all spoke directories.

d) Assume you are working only in project Spoke m. Run cd Spoke m. Then run svn up --set-depth=infinity with <CodeBaseRoot>/Spoke/Spoke m URL. This will checkout the whole spoke m project.

Hopefully this helps.