Thursday, January 23, 2014

How to change priority by filter in Zimbra web client

There is no such functionality in web client :(. But Zimbra support Priority setup, while composing, and display in mail list.

Please vote for issue against Zimbra web mail client: https://bugzilla.zimbra.com/show_bug.cgi?id=86080

Sunday, January 19, 2014

Proposals for Aqua mail-client android application

I use to have "Touchdown for smartphones" application to read mails for MSExchange mail server - perfect application and very customizable ! I loved it! But I moved to IMAP account and Touchdown does not support IMAP, so I have to switch from it to other application.

I did investigation of mail clients for Android and following application is really great and convenient for my workflow and usage.
Aqua mail client.

List of my proposals to make me forget about Touchdown:
1) New option: Do not mark Read on server.
2) How it is possible to filter UnRead mails in Folder
3) hide amount of mails in folder
4) new potion: hide Folder from list of synced Folders

Compress common part for project in Eclipse

Proposal to improve "Compress package names", list of features:

Compress package names: compress common part for project.

Checkstyle: ULC classes as static variables

Example of AvoidModifiersForTypesCheck in real code validation, implemented in sevntu.checkstyle 1.0.5 .

http://ulc.canoo.com/ulccommunity/Contributions/Extensions/GoodPractices.html

Static variables
Never keep instances of ULC classes in static variables (ULCIcons neither!). They cannot be shared between different sessions.

Post on ULC Canoo site that helps, at forum .

Monday, January 13, 2014

New Checkstyle idea: Appropriate Name Check

It is very ambition task but :) it will be good to have such Check to control typos and restrict non-English developers to write ease-to-read code.

Main focus on ensure that methods start  from verb, variable and Classes are nouns/adjectives (very difficult, separate vocabulary, ...... could be done as student diploma work).
As an option - Grammar validation for names of variables, methods, classes base on vocabulary - it will be very good experiment.

Attention for interesting Naming examples to consider for Class names and Boolean names:
http://checkstyle.sourceforge.net/availablechecks.html
AvoidStarImport - name started from verb.
allowByTrailComment - name started from verb - Boolean  variable , is there better name ?

so Check should be not that strict or rules for naming should be more complicated.

We could borrow spelling/grammar check from Eclipse.
Is there any other OSS library ?

Spell projects:
https://github.com/lyda/misspell-check



If you run to this page and share idea with me, please let me know.

Saturday, January 11, 2014

Confusing Condition Check examples

Our team implemented very impudent Check - ConfusingConditionCheck in release 1.9.0.

In short, This check prevents negation within an "if" expression if "else" is present.
For example, rephrase:
if (x != y) smth1(); else smth2();
as:
if (x == y) smth2(); else smth1();

But we are not that simple !!! in other case Check will not be useful in real live so we have bunch of options...

Options:

multiplyFactorForElseBlock - Allow to ignore "else" block if its length is in
 "multiplyFactorForElseBlocks" time less then "if" block.

ignoreInnerIf - Disable warnings for all "if" that follows the "else". It is useful for
 save similarity with all "if-then-else" statement.

ignoreSequentionalIf - Disable warnings for all sequential "if". warnings for all "if" that follows the "else".

ignoreNullCaseInIf - Disable warnings for "if" if it condition contains "null".

ignoreThrowInElse - Disable warnings for "if" if "else" block contain "throw".


Examples for each option.

our UTs input file is here.

1) Example of Simple IF-ELSE with inversion
that could be swapped in their position and condition could be inverted
String[] result = null;
if (!checkNotExists) {   /// warning is here !!!!
  result = new String[] { updateSql };
} else {
  result = new String[] { updateSql, removeItems(table, column) };
}

another example:
if (!popup.isShowing()) {  /// warning is here !!!!
  show();
} else {
  hide();
}

 another example with complicated condition:
if (!global && part != this) {  // warning is here !!!
  addLocalPart(part);
} else {
  addGlobalInternal(part);
}
code is expected to be, base on De Morgan's laws from Boolean Algebra:
if (global || part == this) { 
  addGlobalInternal(part);
} else {
  addLocalPart(part);
}


2) Example of multiplyFactorForElseBlock=4 .
IF condition is negative but as it big enough(mean that is could be more valuable for developer attention) it should stay in on top so that option skip that case.
  if (!hasWhitespaces(kw)) { //NO warning here   sb.append(kw);
  sb.append('"');
  sb.append('--"');
  sb.append('"');
sb.append('--"'); } else { sb.append(kw); } 
3) example with ignoreNullCaseInIf=true.
Check for NULL is used everywhere in code, and developer by that check highlight that first block is main logic, ELSE block is exceptional processing, so we keep condition without inversion as IF block is more valuable for logic.
if (entity != null) { //NO warning here handler.handleReference(entity); } else { log.error("Some problems with resolving reference"); }

4) Example with ignoreSequentionalIf = true; 
Such pattern is also well spread in java code, unfortunately there it hard to say that after inverting logic IF-ELSE will looks better.
if (!isAllowed(row)) {   //NO warning here
label.setForeground(Color.gray);
} else if (isSelected) {
label.setForeground(Color.white);
} else {
label.setForeground(Color.black);
}
there is even more complicated, so it is user responsibility what conditions should be used and what processing block should located above:
if (obj1 == obj2) {
result = true;
} else if (obj1.getClass() != obj2.getClass()) {   //NO warning here
result = false;
} else {
Class<?> obj1Class = obj1.getClass();
     // a lot of code .......
   }
to see more examples please visit issue at github.

5) Example for ignoreThrowInElse=true;
ELSE block is always treated as processing of non main part of logic, so all unexpected processing and terminations are expected in it more than in IF.
By mean of this option you can skip cases where ESLE is used to process exceptional cases of logic, so main block of logic have to be placed on top.

if (!gzip) {  //NO warning here due to "throw" in ESLE
  stream = new BufferedInputStream(in);
} else {
  log.debug("resource is gzip'd: " + url);
try {
  stream = new BufferedInputStream(new GZIPInputStream(in));
} catch (IOException e) {
  throw new DocumentException(e);
}
}

6) Example of ingnoreInnerIf = true
With that option as "true" this Check will not force you to update following code

if (user != null ) {
   if (obj !=  null ) {
         index++;
   }
} else { 
     index--; 
}

to

if (user == null ) {
    index--;
} else {     
   if (obj !=  null ) {
           index++;
   }
 }

It is some time convenient to keep the same type conditions "!=" close together(close to each other). But it is very debatable what variant is more readable - so it is option :) .

New Check idea: VariableNameLengthCheck


Reason to check code:
- code are not intuitive;
- easy to miss usage during code review small variables are easy to miss in big expressions
- hard to put mouse pointer in Eclipse to see usages ("Toggle Mark Occurrences"), description see item "Mark occurrences".
- in methods/c-tors names of arguments are used to auto-generate code in place of call. Reasonable names will give developers quick understanding how to use method/c-tor without reading Javadoc. Example is here, item "Content assist can insert argument names automatically".

How checkstyle could help here:
Task is possible to be done by means of Checkstyle, and it is clear style problem.
Checkstyle never did analyse of English grammar and meaning of variable names - that is not very simple task.
All we need there is teach checkstyle make abbreviations and short forms of full type names, Eclipse somehow do it ("Content assist for variable, method parameter and field name completions", "Less typing for assignments"), so could borrow some ideas from it.

Examples of code:

0) Is there way to calculate sort name from type ?
class ApplicationPermissions  == allowed short form => perm or permission or appPerm

1)
private String getFeature(Permissions p) {
String className = this.getClass().getPackage().getName();
String perspective = this.getClass().getName();
return className + ":" + p + ":" + perspective;
}

2) Comparison of same type variables. Looks like we need to skip that cases from validation.
As it will be hard to find proper names for both variables.

public static ApplicationPermissions getLess(ApplicationPermissions p1, ApplicationPermissions p2) {

int result = p1.compare(p2);

if (result == 0) {
return p1;
}
if (result > 0) {
return p2;
} else {
return p1;
}
}

3)  Is there any way  restrict odd names usage ? base on set of short names but forbidden to use , see example below:

ApplicationPermissions(String str, int level) {
this.str = str;
this.level = level;
}


4) Any ability to do exception for "Object o", is it reasonable ?
private void addPermissionEntry(String permAliase, Object o, ApplicationPermissions permission,
ApplicationPermissions defaultPermission) {
List<PermPair> permPairsList = null;

if (this.permMap.containsKey(permAliase)) {
permPairsList = this.permMap.get(permAliase);
} else {
permPairsList = new LinkedList<PermPair>();
this.permMap.put(permAliase, permPairsList);
}
permPairsList.add(new PermPair(o, permission, defaultPermission));
}

5) Allow usage f small names as they are FOR indexes.
for (int i = 0; i < samples.length; i++) {
if (font.canDisplayUpTo(samples[i][1]) == -1) {
supported[i] = true;
}
}
more complicated:
for (int i = 0; i < rows.length; i++) {
String rowstring = rows[i];
String[] values = rowstring.split("\t");
for (int j = 0; j < values.length; j++) {
String value = values[j];
if (startRow + i < rowCount && startCol + j < columnCount) {
dataTable.setValueAt(value, startRow + i, startCol + j);
}
}
}
and 
for (int i = 0; i < 3; i++) {
for (int j = 0; j < 3; j++) {
Assert.assertTrue(sh.isFilled(i, j));
}
}

6) clear sign one letter variable is assigned to good named variable/field

public PermPair(Object o, ApplicationPermissions p, ApplicationPermissions defaultPermission) {
this.feature = o;
this.permissions = p;
this.defaultPermissions = defaultPermission;
}

7) no excuse for short names for arguments as they could be used in code generation and other hint for Developers to let him skip reading of. See example from "6)"

8) We need to allow lover-cased CamelCase(short form) for variable from Classname, example:

Commandline cl = buildCommandLine(command);
executeCommandLine(cl, tableName, numberOfRecords);

9)

Monday, January 6, 2014

Git branching models review


Good explanation for well known branching models : https://www.atlassian.com/git/workflows
git-flow: http://nvie.com/posts/a-successful-git-branching-model/
git-flow script: https://github.com/nvie/gitflow
interesting explanation of git-flow: http://danielkummer.github.io/git-flow-cheatsheet/

jgit-flow: https://bitbucket.org/atlassian/maven-jgitflow-plugin/wiki/Home
http://blogs.atlassian.com/2013/04/git-flow-comes-to-java/
http://blogs.atlassian.com/2013/05/maven-git-flow-plugin-for-better-releases/


just another workflow (Dymitruk Model): http://dymitruk.com/blog/2012/02/05/branch-per-feature/

another overusage of git (but helps its owners): http://stackoverflow.com/questions/19695127/git-workflow-review


One man have the same problem as we (Feature branch vs Jenkins): http://www.giorgenes.com/2012/04/some-thoughts-on-continuous-integration.html


So here is summary:
- git workflow is never ideal and never suit all needs;
- git workflow is reflection of release approaches and language nature and nuances of current project (
 a) existence of CI and level of CI fanaticism (to automate all or have special person that manage CI),
 b) QA/UAT staging environment and how that team approve release to be applied to production,
 c) special engineer that will focus on releases,
 d) versions bump approach,
 e) project structure and building nuances (maven, ant, gradle, scripts or compiled language),
 f) frequency of releases and hotfixes,
 g) requirement of previous versions support or back-porting policy,
 h) project manager that can always apply pull requests, or any code review system (gerrit)
 ....
).
- every "enterprise-successful" workflows create some script/plugin to follow its model with hiding all git commands, and ease git management.
- if you do not like over-engineering, so stay with simplest branching model (all in master, feature branches goes base on master) 

Wednesday, January 1, 2014

Checkstyle suppress file generator

There is interesting patch/tool to Checkstyle that generate supppress.xml file base on all existing violations that are now in code, issue, patch with description.
In description there is only reference to legacy code that nobody want to fix now and team want to proceed forward with validation of new code only.

Documentation for Checkstyle suppression filters are here.

In JulioG approach there are two problems:
- if legacy code is frozen (separate project or packages).
In that case it is easier to do hard suppress on files and folders see example below.

- if legacy code still in active project, and it is expected and some changes might appear.
In that case current suppression approach could hide problems that appear in new code. Existing Suppression mechanisms are not ideal and bound to line numbers any changes to that file will make all rules as irrelevant and incorrect. That will cause more problem. So I to not recommend this !!!

Example for whole folder/file suppression in suppress.xml file:

<suppressions>
....
<!-- suppress folder -->
<suppress checks=".*" files="org[\\/]apache[\\/]cassandra[\\/]thrift[\\/]" />
<!-- suppress all integration tests in certain package -->
<suppress checks=".*" files="com[\\/]company[\\/]runner[\\/].*IT.java" />
<!-- suppress all in legacy files -->
<suppress checks=".*" files="LegacyBuilder.java|LegacyReloader.java|LegacyTester.java" />
...
</suppressions>


But suppress file generation have another reason to exists:
- upgrade to new Checkstyle version should not block build or fail Jenkins configuration, or  make SonarQube unhappy.
New Checkstyle release will always introduce bug and problems and false-positives fixes. So after most of upgrades to new Checkstyle some problems could appear. New Checks for sure will highlight your code :). If you use SCM hooks, Jenkins, ..... for code validation base on commit that will fail or stop the whole build-deploy process that is not desirable.

Proposed workflow:
- Code is clean;
- Plan to upgrade Checkstyle(or turn ON new Checks), generation of suppress file for new violations that are introduced by new version;
- Code is clean;
- Upgrade Checkstyle or turn ON new Checks;
- Code is clean;
- Resolving temporal suppression as separate task/step; removing all newly created suppression from suppress config.
- Code is clean;

That will give you some time to fix new violations as separate step, and resolving Checkstyle will be planned and not block anybody. But never have such suppression generations for long period it will over-complicate your configuration and will not resolve problem you tried to tackle.


PS: suppression model in Checkstyle need to be improved to be not bound to line numbers or .... 

Issue against Eclipse to generate only Getter or Setter by quickfix dialog

Few options in quickfix dialog for getters/setters generations were requested:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=424799

Continuous testing of feature branching model workflow in Jenkins

Interesting approach:
https://wiki.jenkins-ci.org/display/JENKINS/Feature+Branch+Notifier+Plugin

http://zeroturnaround.com/rebellabs/things-to-consider-when-featuring-branching-with-continuous-integration/

I liked following idea:

unfortunately this plugin does not support GIT, so smth should be created for GIT ...

list of all triggers for Jenkins is here.

there is a problem with idea of testing of all branches :
jenkins will show latest status of build it most likely to be topic branch - ever red jenkins is not a good approach as topic branch is designed for keeping incomplete changes and they will always exists .

so Jenkins somehow need to show status only from main branch all other are just for information, in other words aggregation of statuses or custom rule to make global status base on set of branches ..... new plugin :) .

Approach of how to ignore some branches in jenkins by regex