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. 

System.setOut API in Java

System.out.println, by default, logs a message to console if the process has a reference to console window. For subprocesses, by default, there is no console attached. By making use of System.setOut we can redirect the output to a file or some other stream.

Code to redirect the output stream to a file.

File out = new File("/tmp/out.txt");
PrintStream outputStream = new PrintStream(out);
System.setOut(outputStream);

Now,
System.out.println("Hello world!");

This will result in Hello world! getting printed in /tmp/out.txt file.

Similarly, System.setIn and System.setErr APIs are also available and can be used wherever needed.

General Software Development blogs - Part 1

 
The ByteBaker - PhD student at Cornell University.

Coding Horror - programming and human factors

Martin Fowler Bliki

Mark Needham - Thoughs on Software Development

Google Testing Blog

Misko Hevery - The Testability Explorer Blog

Joel on Software

Object Mentor Articles

Scott Hanselman Programming 

The Database Programmer - All things related to database applications, both Desktop and Web

JVM related blogs

NoBlogDefFound - Tomasz Nurkiewicz around Java and code quality 

Vanilla #Java - Understanding how Core Java really works can help you write simpler, faster applications. 

Inspired by Actual Events - Dustin's Software Development Cogitations and Speculations 

The Takipi Blog - Server Debugging Made Easy 

ZeroTurnAround RebelLabs 

Java, SQL and jOOQ - Best Practices and Lessons Learned from Writing Awesome Java and SQL Code. Get some hands-on insight on what's behind developing jOOQ. 

Plumbr - Java Performance Tuning blog 

Vlad Mihalcea's Blog - Teaching is my way of learning 

Nicolas Fränkel blog - A Java Geek 

Petri Kainulainen - Do you want to be a better software developer? 

Stephen Colebourne's blog  - Thoughts and Musings on the world of Java and beyond 

How to do it in Java - Java Tutorials and Best Practices 

JaxEnter 

JavaSpecialists

Adam Bien's Weblog  

Java Concurrency - Jeremy Manson's blog, which goes into great detail either about concurrency in Java, or anything else that the author happens to feel is interesting or relevant to the target audience.