• About Blog

    What's Blog?

    A blog is a discussion or informational website published on the World Wide Web consisting of discrete, often informal diary-style text entries or posts.

  • About Cauvery Calling

    Cauvery Calling. Action Now!

    Cauvery Calling is a first of its kind campaign, setting the standard for how India’s rivers – the country’s lifelines – can be revitalized.

  • About Quinbay Publications

    Quinbay Publication

    We follow our passion for digital innovation. Our high performing team comprising of talented and committed engineers are building the future of business tech.

Friday, June 24, 2016

Java String Concatenation

Java String Concatenation
Image Source: https://www.educba.com/

Have you been told many times, don’t use + operator to concatenate Strings? We know that it is not good for performance. How do you really know whether is it true or not? Do you know what is happening behind the hood? Why don’t we go ahead and explore all about String concatenation?

In the initial versions of java around JDK 1.2 every body used + to concatenate two String literals. Strings are immutable, i.e., a String cannot be modified. Then what happens when we write the following code snippet.

  • String message = "WE INNOVATE ";
  • message = message + "DIGITAL";

In the above java code snippet for String concatenation, it looks like the String is modified but in reality it is not. Until JDK 1.4 the StringBuffer was used internally for concatenation and from JDK 1.5 StringBuilder is used to concatenate. After concatenation the resultant StringBuffer or StringBuilder is changed to String object.

You would have heard from java experts that, “don’t use + operator but use StringBuffer”. If + is going to use StringBuffer internally, what big difference it is going to make in String concatenation using + operator?

Look at the following examples. I have used both + and StringBuffer as two different cases.

  • Case 01, I am just using + operator to concatenate.
  • Case 02, I am changing the String to StringBuffer and then doing the concatenation. Then finally changing it back to String.

I have used a timer to record the time taken for an example of String concatenation.

public class StringConcatenateExample {
   private static final int LOOP_COUNT = 50000;
  
   public static void main(final String args[]) {
      long startTime, endTime;
    
      startTime = System.currentTimeMillis();
      String message = "*";
      for(int i=1; i<=LOOP_COUNT; i++) {
         message = message + "*";
      }
      endTime = System.currentTimeMillis() - startTime;
      System.out.println("Time taken to concatenate using + operator: " + endTime + " ms.");

      startTime = System.currentTimeMillis();
      StringBuilder sBuilder = new StringBuilder("*");
      for(int i=1; i<=LOOP_COUNT; i++) {
         sBuilder.append("*");
      }
      sBuilder.toString();
      endTime = System.currentTimeMillis() - startTime;
      System.out.println("Time taken to concatenate using StringBuilder: " + endTime + " ms.");
   }
  
}

Look at the output (if you run this java program the result numbers might slightly vary based on your hardware/software configuration). The difference between the two cases is extremely surprising.

You might argue, if + operator is using StringBuffer internally for concatenation, then why is this huge difference in time? Let me explain, when a + operator is used for concatenation, see how many steps are involved behind the scenes:

  • A StringBuffer object is created.
  • Message is copied to the newly created StringBuffer object.
  • The “*” is appended to the StringBuffer (concatenation).
  • The result is converted back to a String object.
  • The message reference is made to point at that new String.
  • The old String that message previously referenced is then made null.

It is now clear that there are serious performance issues that can result if you use + operator for concatenation and why is it so important to use StringBuffer or StringBuilder (from java 1.5) to concatenate Strings.

And on a side note, the StringBuffer is slower compared to StringBuilder because it’s a thread safe object, where all the methods are synchronised, so you need to take a decision wisely on usage based on your requirement.

Thursday, April 21, 2016

Git Cherry Pick

Git Cherry Pick
Image Source: https://mattstauffer.com/
Some of my team members asked me how to merge only specific commits from a branch into the current branch. The reason you’d want to do this is to merge specific changes that you need immediately, leaving the other code changes you’re not interested.

First of all, use git log to see exactly which commit you want to pick or you can use the UI to identify the commit ID.

Let’s say you’ve written some code in the commit f69eb3 of the feature branch that is very important right at this moment. It may contain a bug fix or the code that other people need might need access to. You might want to have commit f69eb3 in the release branch, but not the other code you’ve written in the feature branch. Here the git cherry-pick comes very handy, in this case, f69eb3 is the cherry and you want to pick it.

Below are the step by step instructions to pick one commit from feature branch to release branch.

  • git checkout release
  • git cherry-pick f69eb3

That’s all, f69eb3 is now applied to the master branch and commited (as a new commit) in release branch. The cherry-pick behaves just like merge. If git can’t apply the changes then you will get merge conflicts. Git leaves you to resolve the conflicts manually and make the commit yourself.

In some cases picking one single commit is not enough. You may need, let’s say few consecutive commits. In this case, cherry-pick is not the right tool. Instead use rebase. From the previous example, you’d want commit 76f39a through b816a0 in release.

The process is to first create a new branch from feature at the last commit you want. Let’s say you want upto b816a0.

  • git checkout -b mybranch b816a0

Next, you rebase the mybranch commit –onto master. The 76f39a^ indicates that you want to start from that specific commit.

  • git rebase --onto master 76f39a

The result is that commits 76f39a through b816a0 are applied to master branch.

Please note, git commit ID is a hash of both its contents and its history. So, even if you have two commits that introduce the exact same change, if they point to different parent commits, they still have different IDs. After the cherry pick, the commit in the release branch will not reflect the same commit id as it will have new commit id.

Friday, January 15, 2016

Minification of JS/CSS

Image of HTML/CSS/JS
Image Source: https://webinlinedev.com/

Minification is a process of compressing the source code, without changing it’s functionality. This technique is useful sometimes, specially in the case of a web application with huge JavaScript/CSS files. In other cases, it’s probably just a micro-optimization. Minifying JavaScript/CSS files reduces the bandwidth used and also improves the performance of the application as the page loading time is minimal.

As per Wikipedia Source:

Minified source code is especially useful for interpreted languages deployed and transmitted on the Internet (such as JavaScript/StyleSheet), because it reduces the amount of data that needs to be transferred. Minified source code may also be used as a kind of obfuscation. In Perl culture, aiming at extremely minified source code is the purpose of the Perl golf game.

Minified source code is also very useful for HTML/CSS code. As an example, successive whitespace characters in HTML/CSS are rendered as a single space, so replacing all whitespace sequences with single spaces can considerably reduce the size of a page.

If you are using Maven for your build process, then you can use Minify Maven Plugin which is a wrapper above the YUI Compressor and Google Closure Compiler but has a layer of abstraction around these tools which allows for other tools to be added in the future.

<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-war-plugin</artifactId>
   <version>2.4</version>
   <configuration>
      <warSourceExcludes>/styles/*.css,/scripts/*.js</warSourceExcludes>
   </configuration>
</plugin>

<plugin>
   <groupId>com.samaxes.maven</groupId>
   <artifactId>minify-maven-plugin</artifactId>
   <version>1.7.2</version>
   <executions>
   <execution>
   <id>minify</id>
   <phase>process-resources</phase>
   <goals>
      <goal>minify</goal>
   </goals>
   <configuration>
      <charset>utf-8</charset>
      <jsEngine>CLOSURE</jsEngine>
      <skipMerge>true</skipMerge>
      <nosuffix>true</nosuffix>
      <cssSourceDir>styles</cssSourceDir>
      <cssTargetDir>styles/minified</cssTargetDir>
      <cssSourceIncludes>
         <cssSourceInclude>*.css</cssSourceInclude>
      </cssSourceIncludes>
      <jsSourceDir>scripts</jsSourceDir>
      <jsTargetDir>scripts/minified</jsTargetDir>
      <jsSourceIncludes>
         <jsSourceInclude>*.js</jsSourceInclude>
      </jsSourceIncludes>
   </configuration>
   </execution>
   </executions>
</plugin>

I created a sample web application with “scripts” folder to store javascript files and “styles” folder to store stylesheet files and used the above configuration to test the Minification process.

I copied the latest version of certain JavaScript and StyleSheet files weighed as noted below:

  • script/category-app.js –> 636 B
  • script/jquery.js –> 273199 B
  • styles/style-foundation.css –> 44659 B

After the Maven build, the minified versions of JavaSript and StyleSheet files weighed as noted below:

  • script/category-app.js –> 256 B
  • script/jquery.js –> 94689 B
  • styles/style-foundation.css –> 37016 B

The above results show that the Minification process is working well as expected. So, if you are using a lot of JavaScript/StyleSheet files in your web application, consider minifying your js/css code, so that you can reduce the data transferred and also improve the performance of your web application. In some cases, it might be a micro-optimization.

I have added the configuration <skipMerge>true</skipMerge>. Hence you see that all your files are minified but kept under the same file name within the minified folders respectively. If you set the value to <skipMerge>false</skipMerge>, then it merges all your JavaScript/StyleSheet files into one single file.

If the configuration <nosuffix>true</nosuffix>, you see that all the file names still remain same as the original ones. If you set the value ot <nosuffix>false</nosuffix>, then it will suffix all your JavaScript/StyleSheet file names with ‘.min’.

For more detailed information about the plugin, please click here.


Featured Post

Benefits & Best Practices of Code Review

Photo by Bochelly Code reviews are methodical assessments of code designed to identify bugs, increase code quality, and help developers lear...