My First Post      My Facebook Profile      My MeOnShow Profile      W3LC Facebook Page      Learners Consortium Group      Job Portal      Shopping


Monday, July 29, 2019

Parsing Json in Java using JsonParser

You can use one of the many available Json Parser for the purpose. I have personally used following in simple applications. You can refer this tutorial:

import org.json.simple.JSONArray;
import org.json.simple.JSONObject;
import org.json.simple.parser.JSONParser;
import org.json.simple.parser.ParseException;

You might need to install dependencies first:

In case you are on maven, use following to set a proper environment for the compiler, in order to recognize the JSON's classes. If you want to built your project via Maven, you should add the following dependency to your pom.xml:
Otherwise, you have to add the newest version of json-simple-1.1.1.jar in your CLASSPATH.

First you need to Declare an instance of the JSONParser:
 JSONParser parse = new JSONParser(); 

Then, Convert the string objects into JSON objects:
 JSONObject jobject = (JSONObject)parse.parse(inline); 
If you view the JSON structure, it will be something like this:
   "results" : [
   "place_id" : "aa1123",
         "types" : [ "locality", "book" ]
      } ]

Then you can convert the JSON object into JSONArray 
JSONArray jsonarray = (JSONArray) jobj.get(“results”); 

Now you can use as per your need, for eg.
get the elements within the results array. Here is how you do it:
//Get data for Results array
for(int i=0;i<jsonarray.size();i++)
//Store the JSON objects in an array
//Get the index of the JSON object and print the values as per the index
JSONObject jsonobj_1 = (JSONObject)jsonarray.get(i);
System.out.println(“Elements under results array”);

Wednesday, July 24, 2019

Remote debugging using IntelliJ IDE

Here you'll see how to create and manage a configuration to remotely debug your launched Alfresco project that's waiting for a connection. This assumes you have an IntelliJ IDEA IDE up and running, and have already imported the same project you are going to debug.

For more details on how import an Alfresco project into your IntelliJ IDEA IDE, see Setting up your development environment using Intellij IDEA

Open the IntelliJ IDEA IDE and click on Run Configurations (top right).

Click on the green plus (top left) and select Remote to add a new configuration for a remote app.
Enter a name for your configuration, for example, "My-remote-debug"

Apply some settings eg. Change the port number eg. to 8000.
Check that your settings match the screenshot.
Click OK.

Now when you debug, You will be taken back to the project source code.
To start debugging Click on the bug (debug) icon and select the new configuration My-remote-debug to run it.

The project starts running and generating all the log messages of a regular launch in the terminal window. Open your browser and type http://localhost:8080/hello

Voila!! IntelliJ IDEA will intercept the execution at the breakpoint:

Monday, July 8, 2019

Localization and Globalization testing

Globalization is the process of designing and developing applications that function for multiple cultures.
Localization is the process of customizing your application for a given culture and locale.
Globalization focuses your applications capibilities on users as a generic user-base, whereas localization focuses on subsets of users in a given culture or locale. So you can think of globalization as a strategic venue, where as localization is tactical.

Localization makes our software acceptable for a particular culture or locale that makes users to accept the adaptable software. For example Adobe Pdf is used in many languages. It is available in Japanese, Chines or even English :)
Localization testing checks how well the build is translated into a particular target language in given geaographic locale.

Globalization makes our software function in any culture/locale. The goal is to detect potential problems in application design that could hamper globalization. We work to make sure that the code can handle all international support.
For instance, we should support text data in the ANSI (American National Standards Institute) format. Unicode support should be tested. We should handle strings in each language. Right to left and Left to right scripts shall also be tested with.

Friday, July 5, 2019

Number of Bugs per line of code

An interesting read from the book "Code Complete" by Steve McConnell suggests following:

1. Industry Average: "about 15 - 50 errors per 1000 lines of delivered

This is usually representative of code that has some level of structured programming behind it, but probably includes a mix of coding techniques.

2. Microsoft Applications: "about 10 - 20 defects per 1000 lines of code during in-house testing, and 0.5 defect per KLOC (KLOC refers to as 1000 lines of code) in released product (Moore 1992)."

This is attributed to a combination of code-reading techniques and independent testing.

3. Harlan Mills 'cleanroom development' technique: It has been suggested to achieve rates as low as 3 defects per 1000 lines of code during in-house testing and 0.1 defect per 1000 lines of code in released product (Cobb and Mills 1990).

What is Bug/ Defect Density?

It sometimes becomes important to calculate Defect Density for an Application or a system. Defect Density is the compactness of defects in the application. 

Applications are divided into functional areas or more technically KLOC (Thousand Lines of code). Thus, the average number of defects in a section or per KLOC of a software application is bug density.

How Is Bug Density Calculated?

Step #1: Collect the total no. of defects (for a release/build/cycle).

Step #2: Calculate the average no. of defects/Functional area or KLOC

Defect Density Industry Standard?

Well, this varies for every industry, application and every team. Manufacturing would have a specific threshold and it would be completely different for IT.

If it is high it shows poor quality. But it is, in turn, the seriousness of the individual defects that decide if the product is fit for use or not. Sometimes, many defects are just false indicators or are very low in severity and priority.

By the way, who would not like zero defect density. So, even though there is no specific standard, the lower this value, the better.

My experience:

Generally, a High severity (Sev-1) bug stops all use or significant use of the program. A severity 2 bug stops some users but not all. A severity 3 bug is inconvenient, has a workaround, or is an annoyance.

The most professional development organisation I ever worked in, which created software products for worldwide use, and had an enviable reputation for excellence, worked to an expectation of one severity 1 bug per 1000 lines of shipped code.

In my stints with working in Tata, Adobe Systems, Symantec and Expedia, I felt that bugs are unavoidable. They creep in - sometimes because of programmar's logical error and sometimes vulnerabilities in software/algorithm you are using. Also, sometimes you get bugs because of some novel use of hacking techniques.

In general, I observed during all these 12 years of working that there are following number of bugs, if you want to have strict answer on the basis of lines of code:

  1. 1 Sev-1 bug per Kloc
  2. 3 Sev-2 bug per Kloc
  3. 9 Sev-3 bug per Kloc
  4. 4 Sev-4 bug per Kloc

A few thoroughly tested application like a space-shuttle software - have achieved a level of 0 defects in 500,000 lines of code using a system of format development methods, peer reviews, and statistical testing. NASA, for instance, was able to achieve zero defects for the Space Shuttle Software, but at a cost of thousands of dollars per line of code. If people will die because there are bugs in the software then that kind of cost makes sense. Most projects simply cannot afford the same level of testing as NASA.