Getting Http Header Param in Jersey (JAX-RS) Rest

How to read header parameter in Jersey REST - directly into a variable.



//contentType is the String variable which can be used later inside the method.
@GET
public Response getFirstUser(@HeaderParam("Content-Type") String contentType){

 ..
 ...
 System.out.println("content type:" + contentType)
  
 ..
  
}


There is one more way, by reading using @Context  HttpHeader (you can also use this in case you need to get multiple/all header parameters):

//All headers can be read by iterating over headers object.
@GET
public Response getFirstUser(@Context HttpHeaders headers){

  String contentType = headers.getRequestHeader("Content-Type");
  String userAgent= headers.getRequestHeader("user-agent").get(0);
  
  ...
  ... 
  
}







View Unpushed Git Commits

Working from git command line, you want to check the commited but unpsuhed files. You can use below command:

git log origin/<branch_name>..HEAD

Replace <branch_name> with you feature branch name or the current branch name you are working with.

To create a alias inside you unix shell, you can put this alias inside your .profile or .bashrc file:

alias git-unpushed = !GIT_CURRENT_BRANCH=$(git name-rev --name-only HEAD); git log origin/$GIT_CURRENT_BRANCH..$GIT_CURRENT_BRANCH --oneline

And, use git-unpushed from your git client command prompt.

Even better, if you want git client (on your machine) to remember an alias of your liking (that can be used as command later)

$ git config --global alias.unpushed'!GIT_CURRENT_BRANCH=$(git name-rev --name-only HEAD); git log origin/$GIT_CURRENT_BRANCH..$GIT_CURRENT_BRANCH --oneline'

Then use git unpsuhed from your git client command prompt.

Executor Service Example, for invoking multiple calls Parallelly

You may need to run a particular task (that can run independently) in parallel fashion in order to improve performance, or lets say, simulate a method call in multi-threaded environment:

Here is a example code snippet to do so:

Opinion on documentation

When to do documentation:

• Nuggets of information, need to be referred by more people or more frequently - for example, Test Data, Deep links in different environment etc. 
• It can speed up a new joiner's on-boarding. For example, some basic knowledge using which a developer can jump-start into building new feature and deploy stuff.
• Something you feel you are likely to forget for example, an assumptions you were forced to made for whatever reason. 

When it comes to an API is used by different sets of users/clients, it needs to be documented properly. Otherwise, your consumers will either assume things, or, they will keep coming back to you with trivial questions, and that can result in low productivity on both provider's and consumer's end.

Look out for overdoing of documentations - its not good - rather, sometime its a waste of time and energy.

What you need to do to thrive in an Agile Software Development Team :)

1. The art of getting things done:
Building Software is a lot about how to get things done. Small wins are very important in initial days. Try to have targets in mind, small problems to solve, small features that can go into production.

2. Situational Awareness:
People (who is who), technology stack, way of working and cultural aspects of the team.

3. To do list:

You can follow this for time as ritual, or "deliberate practice".
Make a to do list twice, one for the present day and one for the next. Let your to do's become the engine of your initial days of growth.  

4.  Adaptability and self leadership:
You should always look for aligning your day to day tasks or activities to customer's goal or agenda.
Self leadership efforts to know your environment, to understand the way operation runs etc., comes handy when you are actually asked to deal with situations ranging from solving a technical problem to negating with customers or stakeholders.

5. Learning and early failures - Don't let silly mistake ruin your days after 6 months or an year. The early you make mistakes, the early you will have an opportunity to learn from your mistakes. Be courageous (doesn't mean act foolish, without knowing the context),
keep an open mind and learn little something everyday, until you are not comfortable enough.

Resolving Collision issues while working with wsimport maven plugin

Such situation may arise when you are dealing with multiple version of same wsdl and want to separate two stubs into different package.

Example snippet.

http://www.mojohaus.org/jaxws-maven-plugin/wsimport-mojo.html#xjcArgs

Getting the MIME Type based on filename

If you have worked with documents over internet (http), you must be aware of what MIME Type is.
(In case this has suddenly made you interested to read more about mime type, you can check this wiki link.)

But while doing coding in java, the traditional approach or at least how I had been working with so far is, to have a hash/map of mime types and then get it based on the file extension.

Now, here is what Java provides an interesting feature to remove your worries. :-)
There is this interesting feature since I guess, java 1.7,  in java.nio.Files -> probeContentType which gives you content type. here is small test to demo the same.