What tense should I use in git commit message?

So far I was mostly using the past tense since it looks natural to me but the git best practices suggest us to use imperative sentence.

Example: 

My old git message:
Added IDF commands into CMake editor

New git message:
Add IDF commands into CMake editor

Follow this thread for more discussion on this:
https://stackoverflow.com/questions/3580013/should-i-use-past-or-present-tense-in-git-commit-messages

Best Practice: Never ever execute long running operations in the Display.asyncExec() also

//The thread which calls this method is suspended until the runnable completes.

Display.getDefault().syncExec(new Runnable()

{

public void run()

{

//Do only UI operation

}

});

//The caller of this method continues to run in parallel

Display.getDefault().asyncExec(new Runnable()

{

public void run()

{

//Do only UI operation

}

});

I've seen most of the people will misuse Display.getDefault().asyncExec() by thinking that it will not impact the application performance. But the important thing to remember here is, SWT is a single threaded model - Yes, it's a single-threaded UI model. Any UI operation which you do, will happen through Display main thread. 

Example:

Display.getDefault().asyncExec(new Runnable()

{

public void run()

{

   //step 1: network connection involvement

                               

   //step 2: UI code to execute - example: opening a browser

}

});

From above, it has non-UI and UI code. If accessing the network takes time, UI thread will be blocked for a long time so that no other thread can able to get an access to execute other UI code.

That means, at any point of time - only one UI thread will be there i.e, Display thread.

To resolve this kind of things, we need to use jobs and invoke only necessary code in the UI thread.

new Job("Browser opening job...")

{

@Override

protected IStatus run(IProgressMonitor monitor)

{

//step 1: network connection involvement

Display.getDefault().asyncExec(new Runnable()

{

public void run()

{

 //step 2: UI code to execute - example: opening a browser                  

         

}

});

return Status.OK_STATUS;

}

}.schedule();

Best Practice: Always check for Control disposed in Display.asyncExec()

Display.getDefault().asyncExec(new Runnable()

{

public void run()

{

//Always check for whether the control is disposed.

if (!progressComposite.isDisposed())

{

//perform UI operation.

}

}

});

Reason being, when we say asyncExec thread - it will execute on the next reasonable opportunity. But by that time the control would have been disposed.

Conventions for naming git branches for your development

Some practices which I follow for naming git branches.

If you are working on sprint/agile development, you might have planned certain activities for each sprint.

let's say, every sprint development is for 1 month,so for every sprint we can maintain different branches as mentioned below.

Example: In Development mode
Sprint 1  =>  Branch name: dev-1.0.1

here, dev-<Major version>.<Minor version>.<Sprint version>

While handing over your work to QA team, we can promote this branch to QA branch.

Example: In QA mode
dev-1.0.1 will become qa-1.0.1

If you are providing builds one top of dev branches.
Example: For sprint 1 on dev branch
com.kk.product_dev-1.0.1.0.jar

Here, <pluginname>_<<branch name>.<build number>>.jar

on QA builds generation,
com.kk.product_qa-1.0.1.0.jar

If many people are working on sprint on various features, then we can create a different branch for each feature(ex: dev-1.0.1_explorer), once the feature is stabilized then we can merge this with the main sprint branch i.e dev-1.0.1

Eclipse Plugin name and package name conventions

I will follow below conventions for naming any new plug-in which I am contributing.

Plug-in names should follow the standard Eclipse Naming conventions. That means that,
(i)   The project name on disk(Plug-in name) is the same as the plug-in id and
(ii)  Plug-in packages should start with plug-in name.
(iii) Don’t mix generated code plug-in and implementation plugins

com.kk.studio.<component name>
com.kk.studio.<major component name>.<minor component name>

 Examples:
com.kk.studio.sky   => Implemented code plug-in
com.kk.studio.sky.model    => EMF model based generated code plug-in

Package Names:
com.kk.studio.sky  => Plug-in name/Plug-in id

com.kk.studio.sky
com.kk.studio.sky.explorer
com.kk.studio.sky.explorer.model
com.kk.studio.sky.explorer.view
com.kk.studio.sky.explorer.view.actions
com.kk.studio.sky.explorer.view.dialogs
com.kk.studio.sky.explorer.view.dialogs.data
com.kk.studio.sky.explorer.view.providers
com.kk.studio.sky.i18n
com.kk.studio.sky.util


Eclipse Resources:
http://wiki.eclipse.org/Development_Resources/HOWTO/Project_Naming_Policy
http://wiki.eclipse.org/index.php/Naming_Conventions#Eclipse_Workspace_Projects

Eclipse is too slow, they try out these options

Are you feeling your eclipse is slow ? And, is it taking lot of time to open your eclipse ?

Based upon my experience I have put down some points that would help you out.

1.       Try to open your eclipse in clean mode.

    Command:  > eclipse –clean

What is does ?

Cached data used by the OSGi framework and eclipse runtime will be wiped clean. This will clean the caches used to store bundle dependency resolution and eclipse extension registry data. Using this option will force eclipse to reinitialize these caches.

http://www.eclipsezone.com/eclipse/forums/t61566.html

2.       Configuring suitable heap memory size in eclipse.ini file. Verify max heap size parameter (Xmx) and configure based on the application need.

Example:  -Xmx1024M

This is where your java objects will be stored.

3.       Make sure to configure sufficient permgen size in eclipse.ini file. Configure based on the your application need.

  

 Example: -

-XX:PermSize=256m

-XX:MaxPermSize=512m

This is where you classes and method definitions will be loaded after starting your application

4.       Close unnecessary projects in your workspace.

Example: You might have 10 plug-ins in your eclipse current workspace, but you might be using or working on only 2 plug-ins, and that work independent of other plug-ins.

5.       Try to avoid force closing eclipse.  It takes lot of time to initialize the previous state of eclipse based on the history indexes.

6.       Don't enable all third-party code enforcement tools by default.

Example:

• Find bugs - run based upon need.
• Google code analytics
• Check style

 7.       You can remove Project build automatically option in eclipse and enable only based on the need.

8.  Remove automatic updates for eclipse plug-ins and third party plug-ins.

    You can find “Automatically find new updates and notify me” option in your eclipse.

8.       Once in a while try to switch all your plug-ins/projects in to new workspace and work.

As a programmer:

• Don't keep so much of code in your Activator start() methods
• Minimize the number of classes in the each plug-in
• Don't run too many background processes in your application.
• Don't create too many threads at a time. Make sure no.of threads should be less than or equal to number of processor cores in the system.

Ellipses (...) conventions in Eclipse

There are lot of discussions on this topic, but there is no official eclipse wiki page which described ellipses standards and conventions which has to be used while developing eclipse products.

Below are the resources which helps us to understand how to use ellipses in eclipse.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=226468

Windows UI guidelines on Ellipsis usage

Apple UI guidelines on Ellipsis usage

http://dev.eclipse.org/mhonarc/lists/ui-best-practices-working-group/msg00313.html

As per my understanding, eclipse is mostly following Windows User interface guidelines for ellipses usage conventions.

Below points which helps us to understand in summary.

1. Display an ellipsis if a dialog box is displayed to the user to change/enter information. Omit the ellipses for "show properties", "help" and "about" which are essentially "show" dialogs anyway. No more info is needed for them.

2. While command buttons are used for immediate actions, more information might be needed to perform the action. Indicate a command that needs additional information by adding an ellipsis at the end of the button label. 

In this example, the Print... command displays a Print dialog box to gather more information.

By contrast, in this example the Print command prints a single copy of a document to the default printer without any further user interaction.

3. Proper use of ellipses is important to indicate that users can make further choices before performing the action, or even cancel the action entirely.

This doesn't mean you should use an ellipsis whenever an action displays another window—only when additional information is required to perform the action. Consequently, any command button whose implicit verb is to "show another window" doesn't take an ellipsis, such as with the commands About, Advanced, Help (or any other command linking to a Help topic), Options, Properties, or Settings.

4. Generally, ellipses are used in user interfaces to indicate incompleteness. Commands that show other windows aren't incomplete—they must display another window and additional information isn't needed to perform their action. 

    Some actions in Eclipse:

    Restart -> it will just restart without asking. It might ask if any unsaved changes, for confirmation ellipses not required.

    Exit -> It will just exit from the eclipse. No ellipse required

    Import...  -user has to select what has to imported. We should use ellipse here

    Export...  -user has to select what has to exported. We should use ellipse here