$ jarsigner -verify -verbose -certs /Eclipse/plugins/com.espressif.core_1.0.0.jar
Java, Eclipse Plugin Development and best software development practices
Wednesday, March 6, 2019
Friday, February 8, 2019
Design process and some famous design models
Design Thinking Model
Double Diamond Model
https://www.designcouncil.org.uk/news-opinion/design-process-what-double-diamond
Google Design Sprint
The Design Sprint follows six phases: Understand, Define, Sketch, Decide, Prototype, and Validate.
https://designsprintkit.withgoogle.com/methodology/overview
Monday, November 26, 2018
Should we migrate projects from Java 8 to Java 9 or 10
If you're on Java 8, you might be thinking should we migrate the projects from Java 8 to Java 9 or 10?
Big NO!!
Big NO!!
It doesn’t worth the effort. It’s better if you migrate your projects directly to Java 11 which is an LTS version.
Java 9 and Java 10 are non-LTS versions.
“For product releases after Java SE 8, Oracle will designate a release, every three years, as a Long-Term-Support (LTS) release. Java SE 11 (18.9 LTS) is an LTS release. For the purposes of Oracle Premier Support, non‑LTS releases are considered a cumulative set of implementation enhancements of the most recent LTS release. Once a new feature release is made available, any previous non‑LTS release will be considered superseded. For example, Java SE 9 was a non‑LTS release and immediately superseded by Java SE 10 (also non‑LTS), Java SE 10 in turn is immediately superseded by Java SE 11. Java SE 11 however is an LTS release, and therefore Oracle Customers will receive Oracle Premier Support and periodic update releases, even after Java SE 12 is released.”
For long-term support, Oracle is recommending remaining on Java 8 or move to Java 11. Refer to the following:
Java 8 Release support:
Premier support: March 2022
Extended support: March 2025
Java 9:
Premier support: March 2018
Extended support: Not available
Java 10:
Premier support: Sept 2018
Extended support: Not available
Java 11:
Premier support: Sept 2023
Extended support: Sept 2026
Extended support: Sept 2026
Wednesday, November 21, 2018
Selecting multiple lines of code in Github file
To select a single line of code, we can just click on the line number to highlight the line. That provides the url with a single line code selection.
Example:
https://github.com/aptana/studio3/blob/development/bundles/com.aptana.console/plugin.xml#L5
To select multiple lines of code, click the number of the first line in the range to highlight the line of code. Then, hover over the last line of the code range, press Shift, and click the line number to highlight the range.
Example:
https://github.com/aptana/studio3/blob/development/bundles/com.aptana.console/plugin.xml#L5-L11
Example:
https://github.com/aptana/studio3/blob/development/bundles/com.aptana.console/plugin.xml#L5
To select multiple lines of code, click the number of the first line in the range to highlight the line of code. Then, hover over the last line of the code range, press Shift, and click the line number to highlight the range.
Example:
https://github.com/aptana/studio3/blob/development/bundles/com.aptana.console/plugin.xml#L5-L11
Monday, November 19, 2018
Which one to use OpenJDK or OracleJDK?
With Java 11 release, there is no difference between OpenJDK and OracleJDK. All the features and licenses are exactly the same. Oracle has moved the Java license from BCL to GPL2 (+ ClassPath Exception ) license which is the same license used by OpenJDK as well.
Broadly, I can categorize them based on my understanding:
- OpenJDK
- OracleJDK for free
- OracleJDK with commercial - Java SE subscription Model.
When to use what?
- Use OpenJDK if you want to customize VM and language features and package it with your product.
- If you don’t want to make any changes in JDK and VM, also not looking for any support from Oracle - then prefer OracleJDK for free.
- If you have many applications which are still running with the older JDK versions like 6,7,8 which are not under LTS now, but you are still looking for security updates and support from Oracle - then go for OracleJDK with a commercial support.
Earlier, there were some commercial features(Heap Analyzer, Java Flight recorder,etc.) in OracleJDK but after Java 9 they slowly offloaded commercial features from the OracleJDK and contributed to OpenJDK.
Now with Java 11 - features, licenses and release cycle dates everything is same!
Resources:
Long live Java!!
How to run a sprint retrospective
This is a very nice post on how to run a sprint retrospective meeting
https://thedigitalprojectmanager.com/how-run-sprint-retrospective/
https://thedigitalprojectmanager.com/how-run-sprint-retrospective/
Wednesday, November 14, 2018
Git commit message format standards
Here is my earlier post on this:
https://exploreeclipse.blogspot.com/2012/11/template-for-git-messages.html
Here is something new which I found. Probably, industry will align with these standards sooner or later.
https://www.conventionalcommits.org
https://exploreeclipse.blogspot.com/2012/11/template-for-git-messages.html
Here is something new which I found. Probably, industry will align with these standards sooner or later.
https://www.conventionalcommits.org
Format suggested:
<type>[optional scope]: <description>
[optional body]
[optional footer]
The commit contains the following structural elements, to communicate intent to the consumers of your library:
- fix: a commit of the type
fix
patches a bug in your codebase (this correlates withPATCH
in semantic versioning). - feat: a commit of the type
feat
introduces a new feature to the codebase (this correlates withMINOR
in semantic versioning). - BREAKING CHANGE: a commit that has the text
BREAKING CHANGE:
at the beginning of its optional body or footer section introduces a breaking API change (correlating withMAJOR
in semantic versioning). A breaking change can be part of commits of any type. e.g., afix:
,feat:
&chore:
types would all be valid, in addition to any other type. - Others: commit types other than
fix:
andfeat:
are allowed, for example commitlint-config-conventional (based on the the Angular convention) recommendschore:
,docs:
,style:
,refactor:
,perf:
,test:
, and others. We also recommendimprovement
for commits that improve a current implementation without adding a new feature or fixing a bug. Notice these types are not mandated by the conventional commits specification, and have no implicit effect in semantic versioning (unless they include a BREAKING CHANGE, which is NOT recommended).
A scope may be provided to a commit’s type, to provide additional contextual information and is contained within parenthesis, e.g.,feat(parser): add ability to parse arrays
.
Subscribe to:
Posts (Atom)