Thursday, November 26, 2015

Managing node.js with nvm

Managing node.js with nvm

Run below command to install nvm
curl https://raw.githubusercontent.com/creationix/nvm/v0.11.1/install.sh | bash
You'll see some output fly by, and then nvm will be installed. You will see a line that says:
=> Close and reopen your terminal to start using NVM
It's not actually necessary to log out, we just need to make sure that the changes nvm made to your path are actually reflected, so just do:
source ~/.profile
Alternatively, run the command suggested in the output of the script. Now type:
nvm ls-remote
Should you see the error, -bash: nvm: command not found it may be because git is not installed.
Go ahead and install git and rerun the script:
apt-get install git
And you will be shown a list of all the available versions of node.js. You can always find out the latest stable release by heading to the node.js website, where it's printed in the center of the page.
To install version 0.10.13 (the latest as of this writing) type:
nvm install 0.10.13
If you type:
node --version
You will now see that node v0.10.13 is installed and active. If you had an older node app that only works with node v0.8.16, and wanted to downgrade, then you would input:
nvm install v0.8.16
to install and switch to v0.8.16.
When you're done and want to switch back to v0.10.13, you can do so with nvm's use command:
nvm use v0.10.13
Nvm is great and makes switching between node versions easy and convenient. However, there's one caveat. If you type:
which node
you will see something interesting. Nvm installs node.js inside your user's home directory. This is fine for development, but if you want to actually host node applications, you don't want to install the latest new version of node via nvm and discover that you've inadvertently caused your production node app (which can be incompatible with the latest node.js) to stop working. It's best to install one copy of node globally so that other users can access it, and use nvm to switch between your development versions.
To do this, run the following command (entering your user's password at the prompt):
n=$(which node);n=${n%/bin/node}; chmod -R 755 $n/bin/*; sudo cp -r $n/{bin,lib,share} /usr/local
The above command is a bit complicated, but all it's doing is copying whatever version of node you have active via nvm into the /usr/local/ directory (where user installed global files should live on a linux VPS) and setting the permissions so that all users can access them.
If you ever want to change the version of node that's installed system wide, just do another nvm use vXX.XX.XX to switch your user's node to the version you want, and then re-run the above command to copy it to the system directory. 
To check that it works, become the root user and do another which command to make sure that node is now installed to /usr/local/bin:
sudo -s
which node
You should see:
/usr/local/bin/node
Congrats! Node.js is now installed and ready for use. Enjoy!
UPDATE:
Use below to change the default version for a shell.
nvm alias default 0.12.7

Thursday, November 19, 2015

How to control eclipse Java formatter on or off

This you can be controlled from Eclipse preferences.

Eclipse preferences: Java > Code Style > Formatter. Click on "Edit" button, "Off/On Tags", check off "Enable Off/On tags".

How to use in the code:
// @formatter:off
...your code here won't be formatted
// @formatter:on




How to listen to Eclipse Log errors

Register a listener in your Core Plugin startup:

Platform.addLogListener(new MyLogListener());

Listen to the log:

import org.eclipse.core.runtime.ILogListener;
import org.eclipse.core.runtime.IProgressMonitor;
import org.eclipse.core.runtime.IStatus;
import org.eclipse.core.runtime.Status;
import org.eclipse.core.runtime.jobs.Job;

public class MyLogListener implements ILogListener
{

@Override
public void logging(IStatus status, String plugin)
{
if (status.getCode() == IStatus.ERROR)
{
startJob(status);
}
}

private void startJob(final IStatus status)
{
Job job = new Job("Reporting error...")
{
@Override
protected IStatus run(IProgressMonitor monitor)
{
System.out.println("===============Studio error reporting starts==============");
String ticketMessage = status.getMessage();
System.out.println(ticketMessage);
Throwable exception = status.getException();
exception.printStackTrace();
 System.out.println("===============Studio error reporting ends==============");
return null;
}
};
job.schedule();
}

}

Tuesday, November 17, 2015

Semantic Versioning

http://semver.org

Given a version number MAJOR.MINOR.PATCH, increment the:
  1. MAJOR version when you make incompatible API changes,
  2. MINOR version when you add functionality in a backwards-compatible manner, and
  3. PATCH version when you make backwards-compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.



Wednesday, November 11, 2015

How to change the default console output buffer size in Eclipse

Eclipse User:

In Window > Preferences > Run/Debug > Console there's a checkbox "Limit console output" and a textfield for entering the buffer size of the console. However, you can increase it up to 1000000

Eclipse Plugin Development:

To uncheck the console output limit:
IPreferenceStore store = DebugUIPlugin.getDefault().getPreferenceStore();
store.setDefault(IDebugPreferenceConstants.CONSOLE_LIMIT_CONSOLE_OUTPUT, false);
To change only the buffer limit:
store.setDefault(IDebugPreferenceConstants.CONSOLE_LOW_WATER_MARK, 500000);

Wednesday, October 21, 2015

How to merge the changes from your development branch to master/release branch

$ git checkout development
$ git merge -s ours release  //merge release into development and discard any changes on release branch
$ git checkout release
 $git merge development

Note: Very important point here is, we are completely discarding the changes which are made in release branch. Here we will just bring all the changes from development branch to release branch without having conflicts. If any conflicts during the merge it will take development changes and ignore the release changes if any.

This merge strategy can be used ONLY when you are sure that release branch does not have any additional git commits compared to development branch. 

If release branch is having specific commits and which are not there in development branch, then it's better to go always with the default merge strategy.

$ git checkout release
$ git merge development

Resolve any conflicts if any and commit it.