How to install Redis and run its instance

First, step first. You can simply install it using homebrew
$ brew install redis

After installation you can check that it creates a configutration file at:
/usr/local/etc/redis.conf

Then, you can verify the install as follows:
$ brew info redis

You can start an instance i.e Start Redis server using the configuration file.
$ redis-server /usr/local/etc/redis.conf

By default, it Runs in standalone mode on Port: 6379


Test if Redis server is running.
$ redis-cli ping
It will replu=y you pong!

To Uninstall Redis and its files.
$ brew uninstall redis


What more do you want. So cheers.
:)

How to install Homebrew (brew command) on Mac, linux

To Install Homebrew, you need to make use of ruby that is already installed. This is a simple command then.

On your terminal use following:

$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
Paste that in a macOS Terminal prompt.

The script explains what it will do and then pauses before it does it. Read about other installation options. Install Homebrew on Linux and Windows Subsystem for Linux.

Voila!! That's it.


After this you can tyest which version is installed. Eg:
$ brew --version
Homebrew 2.1.16
Homebrew/homebrew-core (git revision 6176; last commit 2019-11-18)

How to show full working directory in mac terminal on every command

Problem description:
You can obviously use a pwd command to see the present working directory. For eg:

prompt$ pwd
/Users/mfaiz/myDir

But sometimes you want to show the full directory path every time. Its a common ask for eg:

/Users/mfaiz/myDir$ pwd

Or, better still you want the directory path to be displayed on top before each command. All such issues can be handled using your bash profile file:


vi ~/.bash_profile


Solution: 
You can add this line -

export PS1='\u@\H:\w$'

or, if you like having a space between the $ and the command, then - 

export PS1='\u@\H:\w$ '



Shown following are two more complex examples that include coloring as well:




Command used to achieve this is:

export PS1="\n$C_LIGHTGREEN\u$C_DARKGRAY@$C_BLUE\h $C_DARKGRAY: $C_LIGHTYELLOW\w\n$C_DARKGRAY\$$C_DEFAULT "

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:

1 2 3 4 5

<dependency>     <groupId>com.googlecode.json-simple</groupId>     <artifactId>json-simple</artifactId>     <version>1.1</version> </dependency>

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”);

}

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:

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.

MSDN Globalization vs. Localization

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.

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
code."

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.