eclipse shortcuts

Ctrl-Shift-O   Remove unused imports

Ctrl-Shift-R Open Resource

Ctrl-Shift-O  Open a resource search dialog to find any class


http://www.shortcutworld.com/en/win/Eclipse.html

UNIX sort

sortRequestFiles("/tmp/input");

sub sortRequestFiles {

$INPUT_DIR = $_[0];

my @files = glob( "$INPUT_DIR/request*" );

foreach (@files ){

   print "Sorting " . $_ . "\n";

   qx/head -n1 $_ > $_.tmp/;

    qx/tail -n +2 $_ | sort -k1,1 -nk2 >> $_.tmp/;

    qx/mv $_.tmp $_/;

  

    }

           }

GIT COMMANDS

Git is a distributed version control system with an emphasis on speed, data integrity and support for distributed and non linear work flows.

Below are some of the popular commands:


git status   # changed file in your working directory

git add .   #Add all changes to the next commit

git diff    #changes to tracked files

git branch <new branch>  # create a new branch based on your current head

git branch -d <branch>  #Delete a local branch

git pull --all

git log

git branch   # list all the existing branch

git stash

     git stash apply     # apply last stashed changes to working dir

     git stash list          # see your stashed changes

     git stash apply stash@{2}    # apply specific stashed changes.

git remote show origin          #to see the repository url


git reset HEAD^                  # remove commit locally
git push origin +HEAD       # force-push the new HEAD commit

SPRING BATCH

Spring Batch, is an open source framework for batch processing – execution of a series of jobs. Spring Batch provides classes and APIs to read/write resources, transaction management, job processing statistics, job restart and partitioning techniques to process high-volume of data.


Spring Batch is a framework for batch processing – execution of a series of jobs. In Spring Batch, A job consists of many steps and each step consists of a READ-PROCESS-WRITE task or single operation task (tasklet).

1. For “READ-PROCESS-WRITE” process, it means “read” data from the resources (csv, xml or database), “process” it and “write” it to other resources (csv, xml and database). For example, a step may read data from a CSV file, process it and write it into the database. Spring Batch provides many made Classes to read/write CSV, XML and database.
2. For “single” operation task (tasklet), it means doing single task only, like clean up the resources after or before a step is started or completed.
3. And the steps can be chained together to run as a job.

1 Job = Many Steps.
1 Step = 1 READ-PROCESS-WRITE or 1 Tasklet.
Job = {Step 1 -> Step 2 -> Step 3} (Chained together)

Spring Batch Examples

Consider following batch jobs :

1. Step 1 – Read CSV files from folder A, process, write it to folder B. “READ-PROCESS-WRITE”
2. Step 2 – Read CSV files from folder B, process, write it to the database. “READ-PROCESS-WRITE”
3. Step 3 – Delete the CSB files from folder B. “Tasklet”
4. Step 4 – Read data from a database, process and generate statistic report in XML format, write it to folder C. “READ-PROCESS-WRITE”
5. Step 5 – Read the report and send it to manager email. “Tasklet”

In Spring Batch, we can declare like the following :

  <job id="abcJob" xmlns="http://www.springframework.org/schema/batch">
 <step id="step1" next="step2">
   <tasklet>
  <chunk reader="cvsItemReader" writer="cvsItemWriter"  
                    processor="itemProcesser" commit-interval="1" />
   </tasklet>
 </step>
 <step id="step2" next="step3">
   <tasklet>
  <chunk reader="cvsItemReader" writer="databaseItemWriter"  
                    processor="itemProcesser" commit-interval="1" />
   </tasklet>
 </step>
 <step id="step3" next="step4">
   <tasklet ref="fileDeletingTasklet" />
 </step>
 <step id="step4" next="step5">
   <tasklet>
  <chunk reader="databaseItemReader" writer="xmlItemWriter"  
                    processor="itemProcesser" commit-interval="1" />
   </tasklet>
 </step>
 <step id="step5">
  <tasklet ref="sendingEmailTasklet" />
 </step>
  </job>

The entire jobs and steps execution are stored in database, which make the failed step is able to restart at where it was failed, no need start over the entire job.

REST - Representational State Transfer

REST stands for Representational State Transfer. (It is sometimes spelled "ReST".) It relies on a stateless, client-server, cacheable communications protocol -- and in virtually all cases, the HTTP protocol is used.

REST is an architecture style for designing networked applications. The idea is that, rather than using complex mechanisms such as CORBA, RPC or SOAP to connect between machines, simple HTTP is used to make calls between machines.

• In many ways, the World Wide Web itself, based on HTTP, can be viewed as a REST-based architecture.

RESTful applications use HTTP requests to post data (create and/or update), read data (e.g., make queries), and delete data. Thus, REST uses HTTP for all four CRUD (Create/Read/Update/Delete) operations.
REST is a lightweight alternative to mechanisms like RPC (Remote Procedure Calls) and Web Services (SOAP, WSDL, et al.). Later, we will see how much more simple REST is.

• Despite being simple, REST is fully-featured; there's basically nothing you can do in Web Services that can't be done with a RESTful architecture.

REST is not a "standard". There will never be a W3C recommendataion for REST

REST is a lightweight alternative to Web Services and RPC. Much like Web Services, a REST service is:

• Platform-independent (you don't care if the server is Unix, the client is a Mac, or anything else),
• Language-independent (C# can talk to Java, etc.),
• Standards-based (runs on top of HTTP), and
• Can easily be used in the presence of firewalls.

Like Web Services, REST offers no built-in security features, encryption, session management, QoS guarantees, etc. But also as with Web Services, these can be added by building on top of HTTP:

• For security, username/password tokens are often used.
• For encryption, REST can be used on top of HTTPS (secure sockets).

One thing that is not part of a good REST design is cookies: The "ST" in "REST" stands for "State Transfer", and indeed, in a good REST design operations are self-contained, and each request carries with it (transfers) all the information (state) that the server needs in order to complete it.

Some soft guidelines for designing a REST architecture:

1. Do not use "physical" URLs. A physical URL points at something physical -- e.g., an XML file: "http://www.acme.com/inventory/product003.xml". A logical URL does not imply a physical file: "http://www.acme.com/inventory/product/003".
   • Sure, even with the .xml extension, the content could be dynamically generated. But it should be "humanly visible" that the URL is logical and not physical.
2. Queries should not return an overload of data. If needed, provide a paging mechanism. For example, a "product list" GET request should return the first n products (e.g., the first 10), with next/prev links.
3. Even though the REST response can be anything, make sure it's well documented, and do not change the output format lightly (since it will break existing clients).
   • Remember, even if the output is human-readable, your clients aren't human users.
   • If the output is in XML, make sure you document it with a schema or a DTD.
4. Rather than letting clients construct URLs for additional actions, include the actual URLs with REST responses. For example, a "product list" request could return an ID per product, and the specification says that you should use http://www.acme.com/product/PRODUCT_ID to get additional details. That's bad design. Rather, the response should include the actual URL with each item: http://www.acme.com/product/001263, etc.
   • Yes, this means that the output is larger. But it also means that you can easily direct clients to new URLs as needed, without requiring a change in client code.
5. GET access requests should never cause a state change. Anything that changes the server state should be a POST request (or other HTTP verbs, such as DELETE).

Key components of a REST architecture:

• Resources, which are identified by logical URLs. Both state and functionality are represented using resources.
  • The logical URLs imply that the resources are universally addressable by other parts of the system.
  • Resources are the key element of a true RESTful design, as opposed to "methods" or "services" used in RPC and SOAP Web Services, respectively. You do not issue a "getProductName" and then a "getProductPrice" RPC calls in REST; rather, you view the product data as a resource -- and this resource should contain all the required information (or links to it).
• A web of resources, meaning that a single resource should not be overwhelmingly large and contain too fine-grained details. Whenever relevant, a resource should contain links to additional information -- just as in web pages.
• The system has a client-server, but of course one component's server can be another component's client.
• There is no connection state; interaction is stateless (although the servers and resources can of course be stateful). Each new request should carry all the information required to complete it, and must not rely on previous interactions with the same client.
• Resources should be cachable whenever possible (with an expiration date/time). The protocol must allow the server to explicitly specify which resources may be cached, and for how long.
  • Since HTTP is universally used as the REST protocol, the HTTP cache-control headers are used for this purpose.
  • Clients must respect the server's cache specification for each resource.
• Proxy servers can be used as part of the architecture, to improve performance and scalability. Any standard HTTP proxy can be used.

Note that your application can use REST services (as a client) without being a REST architecture by itself; e.g., a single-machine, non-REST program can access 3rd-party REST services.

JSON vs XML

JSON JavaScript Object Notation
XML Extensive Markup Language

Following are key differences between JSON & XML, which will help to decide which content format one should use in there application :

• Parsing and Generating JSON data is easier as compared to XML.

• JSON has simpler structure than XML.

•  In XML document manipulation is easy as compared to JSON.You can easily find/update nodes.You have XPath/XQuery for XML, Do we have it for JSON ? 

• You can do lots of thing with XML for example converting XML to HTML using XLST, such tools not available for JSON.

•  XML is more rich in features and you can have more control over data and do great amount of validation as compared to JSON.You can have DTD's for XML to specify validation in details 

• Working with JSON is simpler, especially with Javascript, just by giving call to Eval will give you Javascript Object.

• JSON is not in a document format neither it is markup language but XML is.

• JSON has great language support as compared to XML.

• JSON is best for simpler use/scenario, for better security,support and validation XML is better.

• JSON is faster as compared to XML as it is less rich, there is less overhead of tags & there is simpler validation rules.    
  

REST vs SOAP

REST stands for REpresentational State Transfer (REST) which enforces a stateless client server design where web services are treated as resource and can be accessed and identified by there URL unlike SOAP web services which were defined by WSDL.
Web services written by applying REST Architectural concept are called RESTful web services which focus on System resources and how state of Resource should be transferred over http protocol.

SOAP
SOAP, originally defined as Simple Object Access Protocol, is a protocol specification for exchanging structured information in XML form.SOAP is protocol which relies on XML, that defines what is in the message and how to process it,set of encoding rules for data types, representation for procedure calls and responses.


REST vs SOAP

Before going for differences between two lets first see the differences in request header :

Sample SOAP & REST Request message for Weather Web Service :

 

SOAP vs REST Key Differences
Here are some of Key differences between SOAP and REST web Service :

•  REST uses HTTP/HTTPS, SOAP can use almost any transport to send the request(for example we can have SOAP Messages over SMTP),  SOAP is a XML based messaging protocol.
• REST is totally stateless operations where as SOAP supports statefull calls too. 
• SOAP has more strict contract in the form of WSDL between applications, no such contract exists in case of REST.
• AS REST APIs can be consumed using simple GET requests, REST response can be cached, this is not possible with SOAP.
• REST is Lighter, SOAP requires an XML wrapper around every request and response(SOAP Headers, XML tags etc). Thats why REST is preferred choice in mobile devices and PDA's
•  SOAP message format is restricted to XML only where as REST supports other formats too for example JSON.  
• REST is simpler in terms of development as compared to SOAP.
• Browsers can handle REST easily as compared to SOAP as REST is based on HTTP where SOAP is another wrapper over HTTP.

Why to use SOAP ?
SOAP provides some features like Security, Reliable Messaging, Atomic transaction which are not available in REST API.

• WS-Security  & WS-SecureConversation  Provide support for using security tokens like Kerberos, and X.509.
• WS-ReliableMessaging   Reliable messages delivery between distributed applications in case of failures.
• WS-AtomicTransaction, two-phase commit across distributed transactional resources
• In case where exact specification  of exchange format need to agreed between applications SOAP is better suitable.