HCodeChecker

dev.habibi.lib.hcodchecker

 
 

TABLE OF CONTENTS

• Description
• Attention
• Rights, License and Disclaimer
• Versioning Guideline
• Features
• Author

 
 
 

DESCRIPTION

• SUBJECT: Java library to check the validity of numeric codes;
• PROJECT NAME: HCodeChecker - Habibi Code Checker;
• LIBRARY NAME: HCodeChecker;
• WHAT IS: HCodeChecker is a small Java library aims to give methods to check the validity of numeric validation codes. It can validate the validation codes made by multiples-11 and multiples-31 approaches. More information about versions and compatibility can be found below;
• To wit: The HCodeChecker and its resources are a project sample, which I have developing to demonstrate some of my abilities. The HCodeChecker project belongs to my personal portfolio. Its detailed project can be followed just here on GitHub: github.com/users/ROPIMASI/projects/. It is also found on my web-portfolio: ropimasi.dev/portfolio.

 
 
 

ATTENTION

IMPORTANT NOTE / DISCLAIMER: (en-US) This is a personal, private project, solely for the purpose of my studies in software development, and for the sole and exclusive use of mine. It is a project under development and experimentation, therefore I have no responsibility for the information contained therein, nor about its results and effects when used.

NOTA IMPORTANTE / ISENÇÃO DE RESPONSABILIDADE: (pt-BR) Este é um projeto pessoal, particular, com finalidade exclusiva de meus estudos em desenvolvimento de software, e de uso e fruto único e exclusivamente meus. Trata-se de um projeto em fase de desenvovimento e experimentações, portanto não tenho nenhuma responsabilidade pelas informações nele contidas, tão pouco sobre seus resultados e efeitos ao ser utilizado.

 
 
 

RIGHTS, LICENSE AND DISCLAIMER: (en-US)

This project and its resources are integral, indivisible, inseparable part of a particular project, which has its use expressly exclusive to its author, Ronaldo Marques ([email protected] / http://ronaldomarques.dev);
Any use, sale, rental, distribution, in parts or integral of this project is prohibited;
This project has the sole purpose of demonstrating knowledge and skills in software development;
Therefore, the author of this project does not recognize or assume any responsibility for the use of it, neither for any possible reflexes or consequence of such use.

DIREITOS, LICENSA E ISENÇÃO DE RESPONSABILIDADE: (pt-BR)

Este projeto e seus recursos são parte integrante, indivisível, inseparável de um projeto particular, o qual tem seu uso e fruto expressamente exclusivo à seu autor, Ronaldo Marques ([email protected] / http://ronaldomarques.dev);
É vetado qualquer utilização, venda, aluguél, distribuição, em partes ou integral deste projeto;
Este projeto tem finalidade exclusiva de demonstração de conhecimento e habilidades no desenvolvimento de software;
Sendo assim, o autor deste projeto não reconhece nem assume qualquer responsabilidade pela utilização do mesmo, tão pouco por qualquer possível reflexos ou consequência de tal utilização.

 
 
 

VERSIONING GUIDELINE

In a team project, it is very important to know and follow the specifications of the project version. Although at the moment this roject's status is under early development (as it has not its first release version yet 1.0.0-release) however its project already is designed under SemVer (Semantic Versioning Specification).
Thus, this project uses SemVer for its versioning. SemVer is a specification (set of rules) that tells us (or dictates) how to use the numbers (and some letters) on the versioning-expression (VerExpr). More specifically, this project uses the following standardization: Major.Minor.Patch-ReleaseStatus+Build, where:

• The standard values of Major, Minor, and Patch for the VerExpr are as follows:
  • Positive integer decimal numbers, without zero remaining on the left;
  • Major version represents wider changes in the project, which affects the main structure of the project, or its main objectives, or the last user API released;
  • Minor version represents smaller changes in the project, which don't affect above itens, but affect the amount of the application fuatrures with a new one or more, or remove an existing feature previouslly released;
  • Patch version represents specific changes which goals to fix or improve some feature, or undesired behavior in the application.
• The standard flags of ReleaseStatus for the VerExpr are as follows:
  • dev: in early development, usage not encouraged;
  • alpha: in development, first test phase, it's encouraged usage for test only by people involved with software development, at self-own risk;
  • beta: in pre-release version, general public usage is acceptable, however, only for test, usage is a choice at self-own risk;
  • release: release version; relatively stable in proportion to the effectiveness of the tests; bugs are possible to appear, so it would come back to a hotfix-branch if needed.
• The standard values of Build for the VerExpr are as follows:
  • A 12-digit numeric sequence, positive integer decimal digits, formatted somewhat to ISO 8601 DateTime YYYYMMDDhhmm;
  • The initial 4 digits (YYYY) represent the year;
  • The next 2 digits (MM) represent the month;
  • The next 2 digits (DD) represent the day;
  • The next 2 digits (hh) represent the hour;
  • The following 2 digits (mm) represent the minutes;
  • All of aboce referecing to the moment when the developer builds/exports the .JAR file (* 1).

(* 1) The numerical sequence Build necessarily/obligatorily refers to Greenwich Mean Time (GMT), also known as Universal Time Coordinate (UTC), or "Z time" or "Zulu time".

Example of Build: "202312311859".

Full example of Versioning-Expression: 1.2.3-release+202312311859, meaning 1._ ._ version fully implemented according to the project and its backlog; added by _ .2._ additional features to the main version, according to the project backlog and its issues priorities in the SCRUM life cycle; added by _ ._ .3 patches fixed in this mentioned lastest version following the GITFLOW life cycle, that means, it is a released version after passed by the tests in alpha and beta pre-releases; and finally, it was specifically build at the year 2023 month 12 (December) day 31 at 18:59h at UTC/GMT/Z-time/Zulu-time (18hours and 59minutes equal 6p.m and 59minutes in some idioms).

 
 
 

FEATURES

Features in current version (0.1.0)

• A...

 

Features in target release version (1.0.0)

• All features above, more...
• B...

 
 
 

Att. Ronaldo Pimentel Marques da Silva.

| https://ropimasi.dev | linkedin @ropimasi | twitter @ropimasi | insta @ropimasi | [email protected] |