Thursday, 31 August 2017

MAVEN VS ANT : A Look at Two Different Building Tools Provided by Apache

Ant and Maven both are build tools provided by Apache. 

The main purpose of these technologies is to ease the build process of a project.

There are many clear differences between Maven and ANT:

1) Ant doesn't has formal conventions, so we need to provide information of the project structure in build.xml file.
A) Maven has a convention to place source code, compiled code etc. So we don't need to provide information about the project structure in pom.xml file.(Project Object Model)

2) Ant is procedural, you need to provide information about what to do and when to do through code. You need to provide order.
B) Maven is declarative, everything you define in the pom.xml file. (Project Object Model)

3) There is no life cycle in Ant.
C) There is life cycle in Maven.

4) ANT is a tool box.
D) Maven is a framework.

5) ANT is mainly a build tool.
E) Maven is mainly a project management tool.

6) The ANT scripts are not reusable.
F)  The maven plugins are reusable.

7) G) ANT is less preferred than Maven.


What is Build Tool ?

A build tool takes care of everything during building a process. It does following:

a) Generates source code (if auto-generated code is used)
b) Generates documentation from source code
c) Compiles source code
d) Packages compiled code into JAR of ZIP file
e) Installs the packaged code in local repository, server repository, or central repository

Understanding the problem without Maven

There are many problems that we face during the project development. They are discussed below:

1) Adding set of Jars in each project: In case of struts, spring, hibernate frameworks, we need      to add set of jar files in each project. It must include all the dependencies of jars also.

2) Creating the right project structure: We must create the right project structure in servlet,        struts etc, otherwise it will not be executed.

3) Building and Deploying the project: We must have to build and deploy the project so that it      may work.

4) It provides us local, central and remote repository.
What it does?

Maven simplifies the above mentioned problems. It does mainly following tasks.

a)  It makes a project easy to build
b)  It provides uniform build process (maven project can be shared by all the maven projects)
c) It provides project information (log document, cross referenced sources, mailing list, dependency list, unit test reports etc.)
d)  It is easy to migrate for new features of Maven

Apache Maven helps to manage :
Builds, Documentation, Reporting, SCMs, Releases, Distribution

BUT WE ARE GOING TO LEARN ANT ?

How to write, build, and debug code in Eclipse through the Ant editor ?

Apache Ant is considered the Holy Grail of build tools in the Java™ development world.

Working with Ant : Create a new Ant build file 

Begin by adding a new Ant file to your project

1. Open the Package Explorer 
2. Right-click any Java Project and click New > File 
3. In the New File window, type build.xml as the file name 

The file is now created, and the Ant editor opens. Now, add some content to the file. Click anywhere in the editor and press Ctrl+Space. A completion proposal containing an option called Buildfile template


<project> -- attributes used is name, depends, description etc...
This is the root tag within buid.xml

within this project tag, there are different tags used like <description> for describing the project, <property> tag  for describing the different properties name and value, <target> tag with name, depends and description attributes.
within this <target> tag there is different inner tags are available like <tstamp> tag for time stamp, <mkdir> tag for create a build directory structure used by compile <javac> tag for includeruntime attribute, srcdir and destdir attributes, <jar> tag for different attributes like jarfile and basedir, which internally contains the <manifest> tag supported by <attribute> tag internally.

==============================================================
build.xml
==============================================================

<?xml version="1.0" encoding="UTF-8"?>
<!-- ====================================================================== 
     Jan 24, 2017 2:23:34 PM                                                        

     project    
     description
                   
     Nishant_Kumar1                                                                
     ====================================================================== -->
<project name="AntJavaProject" default="main" basedir=".">
 <description>
  Create a Java Project (JAR) with Ant build script
 </description>

 <property name="projectName" value="DateUtils" />

 <!-- Java sources -->
 <property name="src.dir" location="src" />

 <!-- Java classes -->
 <property name="build.dir" location="bin" />

 <!-- Output, Jar -->
 <property name="dist.dir" location="dist" />

 <target name="init">
  <!-- Create the time stamp -->
  <tstamp />
  <!-- Create the build directory structure used by compile -->
  <mkdir dir="${build.dir}" />
 </target>

 <target name="compile" depends="init" description="compile the source ">
  <!-- Compile the java code from ${src.dir} into ${build.dir} -->
  <javac includeantruntime="false" srcdir="${src.dir}" destdir="${build.dir}" />
 </target>

 <target name="dist" depends="compile" description="package, output to JAR">

  <!-- Create the distribution directory -->
  <mkdir dir="${dist.dir}" />

  <!-- Put everything in ${build} into the {$projectName}-${DSTAMP}.jar file -->
  <jar jarfile="${dist.dir}/${projectName}-${DSTAMP}.jar" basedir="${build.dir}">
   <manifest>
    <attribute name="Main-Class" value="com.mkyong.core.utils.DateUtils" />
   </manifest>
  </jar>
 </target>

 <target name="clean" description="clean up">
  <delete dir="${build.dir}" />
  <delete dir="${dist.dir}" />
 </target>

 <!-- Default, run this -->
 <target name="main" depends="clean, compile, dist" />

</project>

Dev Story On Devops

3 Keys DevOps Needs for Every Development Team:

Agile development has created a process for developers to rapidly provide a new version of their code. DevOps is the next step in the process.

It is the ability to help get that code to production as fast as possible.

What do development teams need to embrace(accept/support) DevOps?

DevOps is about to empowering your development team to be able to do their job and support their applications from A to Z. There are the 3 critical things I think every development team needs.

1. Automate Builds and Deployments
2. Provisioning Servers
3. Optimizing and Monitoring Application Performance


1. Automate Builds and Deployments

If you want to deploy software quickly and consistently, you need a consistent build process.

suppose some from the built team who has responsibility to built the application & we have to dependent on him/her. somehow if he forgot the steps or not doing in proper time, then you could have a lots of problems.

Many years ago, I did builds manually via a virtual machine abc...It was a VM in production that I knew nothing else touched. I could remotely access it, pull down the latest source code, build, and deploy artifacts from it via xcopy. It was rudimentary at best, but it worked.

now we achieve this whole built through one click, and our apps is ready to run on the cloud.
Many cloud service provider like Azure/AWS etc. takes care of provisioning the servers and all other junks.Anyone on the team can deploy at any moment and have a high level of confidence that it will work perfectly.

2. Provisioning Servers

OK technically, we should probably provision servers before try to deploy to them.

But as a developer, I think about getting a successful build done first. So, this is step 2 for me.

As a developer, I hate servers. I’m not even joking. I hate them as much as printers.

Provisioning servers is a very broad topic that varies wildly based on the type of app and how you host it.

In a lot of organizations, they tend to deploy to the same servers all the time and probably don’t set up new servers very often.
Most apps never run on more than a few servers. Their apps just don’t get enough traffic. In those cases, provisioning new servers are less of an issue.

we can add new servers all the time due to our massive scale. It is a big deal for us!

Option 1: Use an Application Hosting Engine (Public or Private Cloud)

If you have your choice, I would highly recommend deploying your applications in a way that automatically provisions the servers for you. This helps to ensure that developers don’t have to get involved in the actual creation of the servers and that it is done consistently every time.

For example, with Azure, it can be done in a couple clicks. you should really do this as part of your build server and deployment process. That will give you better tracking of when deployments are done, what was in them, etc.

Cloud application hosting options:
Azure App Services & Cloud Services, AWS Elastic Beanstalk, Google App Engine, Heroku etc.

On-premise private cloud options: 
Cloud Foundry, Azure Stack etc.

Cloud computing is not an option for some organizations. However, developers still need the same sort of PaaS (Platform as a service)environment and tools to make them more productive. Maybe containers could help.

Option 2: Containers

Another good way to solve this problem is Docker containers. Instead of provisioning lots of virtual machines, you could pack a bunch of lightweight Docker containers together. Although, you still need an easy way to manage how many instances of them there should be, deploying new versions of them, etc.

Docker management tools:  Docker, Rancher, Cloud66 etc.

Option 3: Configuring Servers

If you have to provision actual servers, first off, I’m sorry.

I still have nightmares about having 15 web servers that do the same thing and frantically needing to set up more of them. Today, I solve that problem by clicking a button in Azure. Back then, we had a VMWare image saved off that had to be cloned. Inherently, 10 things changed since the image was taken and nobody knew what they were. ?

The problem with servers is knowing the exact configuration needed. This problem varies wildly based on your application.  This involves things like installing your web server, application framework, OS updates, security permissions and other dependencies. ?

To solve this challenge, configuration tools like Puppet and Chef have become really popular.


3. Optimizing and Monitoring Application Performance

The DevOps community has always focused on deploying applications. I have always felt like the monitoring side of it gets forgotten about.
Developers need visibility on data about how their apps are performing to troubleshoot problems quickly. It is an essential component of DevOps.

Application monitoring is a completely different beast than server monitoring. 10 years ago, we monitored if a server was up or down and the CPU. We monitored Exchange and our critical web servers the same way. Obviously, that didn’t provide much insight into how our applications were performing.

Today, application monitoring is an umbrella term that could mean a lot of different things. There are 6 specific things that I feel developers need:

APM – code level application performance visibility
Transaction tracing – code level traces of what your code is doing
Metrics – server, application, and custom metrics monitoring
Logs – aggregation, searching, and management
Errors – aggregation, reporting & alerting
Alerts – robust monitoring and alert capabilities
If you want to understand the performance of your application, you need all of these things. Each of them tells a small part of the story.

Let’s take errors as an example. While doing any software deployment, monitoring for errors is the first line of defense for finding problems. Odds are, the new release will likely cause some new errors they have never seen. It is just the nature of software development. Developers need to be able to quickly see these new errors so they can rapidly hot fix them.

Application monitoring tools are the eyes and ears of the development team in production. In lots of companies, developers do not have access to production servers. That is easy to understand for multiple reasons. However, it is very difficult for developers to troubleshoot problems if they can’t get access to log files and other data.

Companies can enforce strict security rules in production and give developers everything they need by leveraging the right types of tools.

I was frustrated that my development team didn’t have the tools that they needed. We had Nagios, Splunk, and multiple other tools. None of my developers had access to them. Even if they did, the tools only told part of the story and were hard to use.

Developers love and need tools. If you want to embrace DevOps, you need tools to help them build, deploy, and monitor their applications. DevOps is about removing barriers. These essential functions can help developers take ownership of their apps.

REST VS SOAP : A Look at Two Different API Styles

When talking about API (application programming interface) architectures, it’s common to want to compare SOAP vs. REST, two of the most common API paradigms. Although these two are often compared, They’re inherently different technologies and aren’t easily compared on a granular level.

Why? Because SOAP is a protocol, and REST is an architectural style.

Both are going to be packaged differently, function differently, and be used in different scenarios. we can only say that REST API can actually utilize the SOAP protocol, just like it can use HTTP.

First, what is an API?

In the simplest of terms, an API is a piece of software that plugs one application directly into the data and services of another by granting it access to specific parts of a server. APIs let two pieces of software communicate, they’re the basis for everything we do on mobile, and they allow us to streamline IT architectures, power savvier marketing efforts, and make easier to share data sets.
Like all software, APIs can be pretty straightforward or incredibly complex, and there are different ways to program one with different attributes that are better suited to your application.

WHAT IS A REST API?

REST (Representational State Transfer) is truly a “web services” API. REST APIs are based on URIs (Uniform Resource Identifier, of which a URL is a specific type) and the HTTP protocol, and use JSON for a data format, which is super browser-compatible. (It could also theoretically use the SOAP protocol, as we mentioned above.) REST APIs can be simple to build and scale, but they can also be massive and complicated—it’s all in how they’re built, added on to, and what they’re designed to do.

Reasons you may want to build an API to be RESTful include resource limitations, fewer security requirements, browser client compatibility, discoverability, data health, and scalability—things that really apply to web services.

Vital Points for REST :

REST is all about simplicity, thanks to HTTP protocols.

REST APIs facilitate client-server communications and architectures. If it’s RESTful, it’s built on this client-server principle, with round trips between the two passing payloads of information.

REST APIs use a single uniform interface. This simplifies how applications interact with the API by requiring they all interface in the same way, through the same portal. This has advantages and disadvantages; check with your developer to see if this will affect implementation changes down the road.

REST is optimized for the web. Using JSON as its data format makes it compatible with browsers.

REST is known for excellent performance and scalability.
But, like any technology, it can get bogged down or bog down your app. That’s why languages like GraphQL have come along to address problems even REST can’t solve.


What is SOAP?

SOAP (Simple Object Access Protocol) is its own protocol, and is a bit more complex by defining more standards than REST—things like security and how messages are sent. These built-in standards do carry a bit more overhead, but can be a deciding factor for organizations that require more comprehensive features in the way of security, transactions, and ACID (Atomicity, Consistency, Isolation, Durability) compliance. For the sake of this comparison, we should point out that many of the reasons SOAP is a good choice rarely apply to web services scenarios, which make it more ideal for enterprise-type situations.

Reasons you may want to build an application with a SOAP API include higher levels of security (e.g., a mobile application interfacing with a bank), messaging apps that need reliable communication, or ACID compliance.

Vital Points for SOAP:

SOAP has tighter security. WS-Security, in addition to SSL support, is a built-in standard that gives soap some more enterprise-level security features, if you have a requirement for them.

Successful/retry logic for reliable messaging functionality. Rest doesn’t have a standard messaging system and can only address communication failures by retrying. SOAP has successful/retry logic built in and provides end-to-end reliability even through SOAP intermediaries.

SOAP has built-in ACID compliance. ACID compliance reduces anomalies and protects the integrity of a database by prescribing exactly how transactions can interact with the database. ACID is more conservative than other data consistency models, which is why it’s typically favored when handling financial or otherwise sensitive transactions.


SOAP VS. REST: THE KEY DIFFERENCES

SOAP is like using an envelope, extra overhead, more bandwidth required, more work on both ends like sealing & opening. Rest is like a postcard  i.e. lightweight can be cached, easier to update.

SOAP is a protocol. REST is an architectural style. An API is designed to expose certain aspects of an application’s business logic on a server, and SOAP uses a service interface to do this while REST uses URIs.

REST APIs access a resource for data (a URI); SOAP APIs perform an operation. 

REST is an architecture that’s more data-driven; SOAP is a standardized protocol for transferring structured information that’s more function-driven.

REST permits many different data formats including plain text, HTML, XML, and JSON, which is a great fit for data and yields more browser compatibility; SOAP only uses XML.

Security is handled differently. SOAP supports WS-Security, which is great at the transport level and a bit more comprehensive than SSL, and more ideal for integration with enterprise-level security tools. Both support SSL for end-to-end security, and REST can use the secure version of the HTTP protocol, HTTPS.

SOAP requires more bandwidth; REST requires fewer resources (depending on the API). There’s a little more overhead with SOAP out of the gate, on account of the envelope-style of payload transport. Because REST is used primarily for web services, its being lightweight is an advantage in those scenarios.

REST calls can be cached, SOAP-based calls cannot be cached. Data can be marked as cacheable, which means it can be reused by the browser later without having to initiate another request back to the server. This saves time and resources.

An API is built to handle your app’s payload, and REST and SOAP do this differently. 

A payload is data sent over the internet, and when a payload is “heavy,” it requires more resources. REST tends to use HTTP and JSON, which lighten the payload. SOAP relies more on XML.
SOAP is tightly coupled with the server. REST is coupled to a lesser degree. In programming, the more layers of abstraction between two pieces of technology, the less control you have over their interaction, but there’s also less complexity and it’s easier to make updates to one or the other without blowing up the whole relationship. The same goes for APIs and how closely they interact with a server. This is a key difference between SOAP and REST to consider. SOAP is very closely coupled with the server, having a strict communication contract with it that makes it more difficult to make changes or updates. A client interacting with a REST API needs no knowledge of the API, but a client interacting with a SOAP API needs knowledge about everything it will be using before it can even initiate an interaction.


Friday, 18 August 2017

Linked List Theory

As we know that the instance variables of an object can be arrays, similarly one of the more interesting possibilities is that an object can also contain a reference to another object of the same type. There is a common data structure, the list, that takes advantage of this feature. Lists are made up of nodes, where each node contains a reference to the next node in the list. In addition, each node usually contains a unit of data called the cargo. In our below example, the cargo will be a single integer, but later we will write a generic list that can contain objects of any type.

we'll start with the instance variables, one or two constructors and toString so that we can test the basic mechanism of creating and displaying the new type.

1) Node01.java

package com.symantec;

public class Node01
{
    int cargo;
    Node01 next;

    public Node01 () {
        cargo = 0;
        next = null;
    }

    public Node01 (int cargo, Node01 next) {
        this.cargo = cargo;
        this.next = next;
    }

    public String toString () {
        return cargo + "";
    }

}

The declarations of the instance variables follow naturally from the specification, and the rest follows mechanically from the instance variables. The expression cargo + "" is an awkward but concise way to convert an integer to a String.


To test the implementation so far, we would put something like this in main:

Node node = new Node (1, null);
System.out.println (node);

Further To make it more interesting, we need a list with more than one node which you can look in below code.

2) MainNode01.java

package com.symantec;

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

public class MainNode01 {
public static void main(String[] args)
{
    List list = new ArrayList();

    Node01 node = new Node01 (1, null);
   System.out.println (node);
 
   list.add(node);
   System.out.println ("list items >> "+list);
 
Node01 node1 = new Node01 (2, null);
Node01 node2 = new Node01 (1, null);
System.out.println ("node1 > "+node1+" node2 >"+node2);

list.add(node1);
list.add(node2);
        System.out.println ("updated list items >> "+list);
 
   node.next = node1;
   node1.next = node2;
   node2.next=null;
 
   System.out.println ("referring next node (node01) data from first node >> "+node.next);

}

}

Initially above code creates three nodes (1 in the begining and two created later), but we don't have a list yet because the nodes are not linked. The state diagram looks like this:




To link up the nodes, we have to make the first node refer to the second and the second node refer to the third.
    node.next = node1; 
    node1.next = node2; 
    node2.next = null; 
The reference of the third node is null, which indicates that it is the end of the list. Now the state diagram looks like:



Now we know how to create nodes and link them into lists.

The thing that makes lists more useful is that they are a way of assembling multiple objects into a single entity, sometimes called a collection. In the example, the first node of the list serves as a reference to the entire list.

If we want to pass the list as a parameter, all we have to pass is a reference to the first node. For example, the method printList takes a single node as an argument. Starting with the head of the list, it prints each node until it gets to the end (indicated by the null reference).

Modified  MainNode01.java class after adding printList method

package com.symantec;

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

public class MainNode01 {
public static void printList (Node01 list) { 
    Node01 node = list; 

       while (node != null) { 
           System.out.print (node); 
           node = node.next; 
       } 
       System.out.println (); 
   } 

public static void main(String[] args) 
{
List list = new ArrayList();
Node01 node = new Node01 (1, null);
   System.out.println (node);    
   //printList (node);   
   list.add(node);
   System.out.println ("list items >> "+list);
   
Node01 node1 = new Node01 (2, null); 
//printList (node1); 
Node01 node2 = new Node01 (1, null);
//printList (node2); 
System.out.println ("node1 > "+node1+" node2 >"+node2);
list.add(node1);
list.add(node2);
   System.out.println ("updated list items >> "+list);
   
   node.next = node1;
   node1.next = node2;
   node2.next=null;
   
   System.out.println ("referring next node (node01) data from first node >> "+node.next);
   printList (node); 
   printList (node1); 
   printList (node2); 
}
}

Inside printList we have a reference to the first node of the list, but there is no variable that refers to the other nodes. We have to use the next value from each node to get to the next node.

This diagram shows the value of list and the values that node takes on:


This way of moving through a list is called a traversal, just like the similar pattern of moving through the elements of an array. It is common to use a loop variable like node to refer to each of the nodes in the list in succession.

By convention, lists are printed in parentheses with commas between the elements, as in (1, 2, 3). 

As an exercise, we can modify printList  using a for loop instead of a while loop so that it generates output in this format.




Monday, 5 June 2017

GUIDELINES FOR GLOBAL MEETINGS EFFECTIVELY

Organizing a Global Meeting

  • Be cognizant of time zones
  • Check open meeting slots prior to scheduling to ensure attendees are available
  • Do not change the meeting at the last minute—it might be late in the day for some of your colleagues who have stayed up late to attend the meeting
  • Ensure interactions and participation
  • Choose the right technology: WebEx, conference room, lighting, display and microphone
  • Break large meetings into subgroups to encourage open conversation
  • Create focused sessions in a smaller groups to develop solutions

Engaging in Global, Cross-Geography and Cross-Cultural Interactions

  • Be loud and clear when speaking
  • Do not avoid meetings, especially with your remote organization
  • Ask questions throughout—do not save them for the end
  • When on video conference, behave just as you would during a face-to-face meeting—with professionalism
  • Prepare for cultural differences and anticipate them at the front end—they’re a lot harder to deal with after the fact
  • Be cognizant of all diversity:  gender, functional, seniority, culture and personality-based
    • Be mindful of differences
    • Don’t obsess over them
    • Set expectations
    • Build relationships
    • Be creative with conflict
    • Be flexible
  • incentivize colleagues to step outside their cultural comfort zones

When Leading a Meeting:

  • As a host, create an agenda
  • For recurring meetings, share the agenda a few business days prior to the meeting
  • As a host, provide sufficient lead time to review the meeting material
  • Recap the action items before closing the meeting
  • Ensure minutes and follow up action items are distributed within one business day
  • Leverage Box repositories for minutes and relevant materials
  • Define the goals of the meeting

When Attending as a Participant:

  • As a participant, review the agenda and meeting material prior to attending
  • Do not engineer solutions in status meetings
  • If you receive an invitation, be courteous by accepting or declining the invitation on time
  • If declining, please provide a related explanation
  • If declining, identify a possible delegate
  • Try to find out what the meeting is all about—prepare notes in advance
  • Always have a notepad and pen (or your personal computer to take notes)
  • Keep your phone on silent or vibrate mode
  • Do not take phone calls during meetings unless it is an emergency
  • Be loud and clear when speaking
  • Show up on time—do not waste anyone else’s time by not being punctual
  • Do not multitask and interrupt speakers

For a Virtual Meeting:

  • According to a survey by Raindance Communications 
  • US company that provides online meetingweb conferencing and teleconferencing services.
    • 70% of people do unrelated work
    • 50% read or send emails
    • 36% mute the call to talk to someone else on a video call
So give your full attention to the meeting
  • Find a quiet spot when videoconferencing
  • Speak clearly and concisely in a virtual meeting
  • There may be a delay on a video conference so allow a pause for response/questions

Thursday, 18 May 2017

Ransomware

How to Protect Yourself Against Ransomware ?
By Nishant Sharma on May 18, 2017

Ransom is the payment/money demanded for the release of something which is not in our control.

Last week, a massive ransomware attack using stolen NSA hacking tools disabled an estimated 200,000 computers in more than 150 countries. The ransomware, known as WannaCry, severely affected organizations around the globe, including FedEx, the British National Health Service, car makers Renault and Nissan, and the Russian Interior Ministry.

Like other ransomware, WannaCry encrypts files on the infected computers, making these files inaccessible, and only releases the code to unencrypt the files when the user pays a $300 bitcoin ransom. 1 Bitcoin equals 1812.06 US Dollar. It’s unknown how many companies have paid or plan to pay the ransom, but with critical data like patient records on the line and production lines shut down, companies have often chosen to pay up rather than lose those records forever.

What is, perhaps, most disappointing with this most recent attack is that it was 100% preventable. All the infected machines were running outdated versions of Windows XP or Vista that are no longer being supported by Microsoft. The risks of continuing to use these versions of Windows were well known (and we warned of the need to stop using XP back in 2014), yet organizations failed to take prudent measures to keep their systems up to date. Now they, and in many cases “we”, as customers and clients, are paying the price.

The good news here, to the extent there is good news, is that protecting ourselves against ransomware like Wanna Cry is not difficult. If you follow these simple steps, you should be safe from ransomware and most other cyber threats likely to come your way.

1. Keep your system up to date
If you are running Windows XP or Vista, you should immediately update your system to Windows 10 or buy a new computer. As we warned back in 2014, Microsoft is no longer supporting these ancient versions of Windows and continuing to use then makes you a prime target for cyber-attacks. And even an entry model $500 computer that will be far more powerful than your current XP one.

For those using Windows 7 and newer, make sure that you have Automatic Updates enabled so new security patches get installed as soon as they are available. These versions of Windows had already been patched by Microsoft to specifically prevent these types of ransomware attacks.

2. Use a reliable antimalware program
While antimalware programs can’t defend against every attack, they can prevent the vast majority of commonly-found malware from infecting your computer. And when new malware is discovered, antimalware providers quickly distribute updates to block it. We recommended Kaspersky in our latest analysis of the best antimalware solutions, though Bitdefender and Norton are also excellent options. And antimalware isn’t just for Windows users. Ransomware has been discovered for Macs, too.

3. Back up your data – no, really back up your data
It’s important to back up your data for a number of reasons; and the threat of ransomware is definitely one of them. But it’s not enough just to back up to an external hard drive, or even to the cloud. Many ransomware programs are specifically designed to search out backup devices, even across your network and cloud storage, encrypting everything in its path. To protect yourself, you either have to make regular backups to an external hard drive, which you then detach from your system after the backup (a pain to manage), or use a cloud service that provides automatic versioning so that if the most recent versions are encrypted, you can still recover from earlier versions. We’ve always been fans of Dropbox, which offers a 1TB storage plan for around $100 per year.

4. Keep your browser and plug-ins up to date
Some malware, including ransomware, can be delivered via “drive-by” infections. Taking advantage of vulnerabilities in common browser plugins, like Flash or Java, simply visiting a compromised site, or even viewing a malicious ad on an otherwise safe site, is all it takes for the malware to take hold. So in addition to keeping your operating system up to date, it’s just as important to keep your browser and its associated plug-ins up to date.

5. Avoid ransomware in the first place
The Wanna Cry ransomware was spread by email through an encrypted zip file attachment. You click on the attachment and unzip the file and all your precious files are now toast. This common social engineering trick has been around for years and, despite repeated warnings not to click on unknown email attachments, it’s still as effective as ever, as evidenced by the immense global success of the latest Wanna Cry attack.

DON’T BE THAT PERSON. 
Don’t click on or open files in email unless you know exactly what they are as of from now. 

Wednesday, 10 May 2017

Oracle 11i v/s 12R

I jotted down few points, you may go ahead with these suitable differences :

1)  11i contains oracle forms basis application but R12 is now Oracle forms with HTML pages.

2)  Database Version in 11i (11.5.9 & 11.5.10) was 9i Rel 2 where as in Release 12 its 10g R2 (10.2.0.2)

3)  HTTP Server or Web Server in R12 is Version 10.1.3 which is built on Apache version 1.3.34. In apps 11i it is Version 1.0.2.2.2 built on Apache Version     1.3.19

4)  Jserv in apps 11i is replaced by OC4J (mod_jserv is replaced by mod_oc4j) in R12

5)  Forms Version 6i in Apps 11i is replaced by Forms 10.1.2.0.2 in R12

6)  Reports Version 6i in Apps 11i is replaced by Reports 10.1.2.0.2 in R12

7)  JDBC version is changed from version 9 in apps 11i to version 10.2.0 in Apps R12

8)  modplsql or mod_pls is removed from Apps R12

9)  Java processes use JDK/JRE version 1.5.0 in R12 against JDK version 1.3.1 or 1.4.2 in Apps 11i

x) New INSTANCE_TOP added within Application tier servers in Release 12 for configuration and log files.




Monday, 3 April 2017

Extended Validation EV - SSL/TLS - Secure Sockets Layer / Transport Layer Security Certificate FAQ

1. What is Extended Validation SSL Certificate?
Extended Validation Secure Sockets Layer (SSL) Certificates are special SSL Certificates that work with high security Web browsers to clearly identify a Web site's organizational identity. Extended Validation (EV) helps you make sure a Web site is genuine and verified.
For example, if you use Microsoft® Internet Explorer 7 to go to a Web site secured with an SSL Certificate that meets the Extended Validation Standard, IE7 will cause the URL address bar to turn green. A display next to the green bar will alternatively (toggle) display the organization name listed in the certificate and the Certificate Authority. 
(VeriSign, for example because it is most widely used for SSL/TLS certificates on IOT).

2. Why Are (EV) SSL Certificates Being Implemented?
Malicious and suspicious online activity, phishing attacks have dramatically increased in recent years, creating a heightened need for improved visibility of security.
Before you share your confidential data online, you require proof of identification from a trusted source. The Extended Validation SSL Standard raises the bar on verification of SSL Certificates and enables visual displays in high security browsers. (EV) SSL Certificates empower you to protect yourself online.

3. What are High Security Browsers?
Users of high-security browsers will see visual cues that are triggered by the presence of an (EV) SSL Certificate. If you're familiar with red-light/green-light intersections, you'll understand the basic concept.
  • Green tells you it's safe and the site is legitimate.
  • Red tells you to stop, usually because the site isn't secure.
The EV SSL certificate supports Microsoft® Internet Explorer (IE) 7* and 8, Firefox 3 and Safari 3.2, Google Chrome and Flock. These versions and above are applicable.
Other browsers are expected to offer Extended Validation visibility in upcoming releases. Older browsers will display Extended Validation SSL Certificates with the same security symbols as existing SSL Certificates.

4. How does EV-SSL work?
  • Extended Validation -SSL, or EV-SSL for short, means that OnlineSBI site has undergone many rigorous checks to confirm its validity, and has been provided with a 'certificate of authenticity' which is recognized by high end browsers.
  • In the majority of cases, this validation is shown in the browser address bar, displaying a 'traffic light' style response of green, or red. This feature gives you the added confidence of knowing the site you're using has been confirmed as genuine.
  • The EV-SSL certificate of authenticity is recognised by most browsers, though there are variations in the way the different browsers display the validation.
  • The majority of users running Internet Explorer versions 7 and 8 (IE7 and IE8), Mozilla Firefox 3, Opera 9.5 and Safari 3.2 will see the following 'traffic light' responses on their address bars:
    • Authenticated websites will display a GREEN address bar plus a padlock symbol, referencing the certificate and the authenticated website provider.
    • Websites identified as fraudulent and a phishing site, or as having a revoked or expired validation certificate, will display a RED address bar.
    • Users running Internet Explorer 6 (IE6), Mozilla Firefox 2 will continue to see the standard address bar along with the padlock symbol. No 'traffic light' notification will be displayed.
  • It is recommended that you upgrade your browser to a version that is compatible with EV-SSL. You can upgrade your browser version from your browser providers' website.

5. Why wouldn't the IE7 browser recognize EV?
A browser identifies an SSL Certificate as authentic by checking if the certificate matches a valid SSL root resident on the client machine. VeriSign signs every EV SSL Certificate with two roots: an EV root and a traditional SSL root. With these two roots, every browser can identify a valid SSL root, even older browsers that do not yet recognize EV.
IE7 is designed to recognize Extended Validation, but may not correctly display in Windows XP because the traditional SSL root is matched rather than the EV root. Windows XP systems do not automatically update the root store.
Developed before the EV standard existed, Windows XP systems do not have the EV root locally resident unless it has been manually updated and, because the browser recognizes the traditional SSL root, it has no trigger to update the root store. VeriSign EV Upgrader technology, built directly into the VeriSign Secured® Seal, will trigger this manual update. Explorer 7 on Vista is designed to automatically update the root store on a weekly basis and should always recognize an EV Certificate and display it appropriately.

JSP interview questions and answers

Q1. What is JSP and why do we need it? JSP stands for JavaServer Pages. JSP is java server side technology to create dynamic web pages. J...