DEV Community: Hafiz Jaafar

Jasypt CLI tools for encryption and decryption

Hafiz Jaafar — Fri, 09 Aug 2024 15:39:46 +0000

Recently I have started to use the Jasypt CLI tools. Before that, I have always had to use the tedious way with the Maven plugin just to do a simple encryption and decryption for any deployment update. This article is meant to complement the guides from the page Jasypt: Java simplified encryption.

Requirements

Java JRE
Terminal, in this example is the Git Bash on Windows.
Downloading the distribution zip file of Jasypt - from the link in the file README in the Jasypt's GitHub repo.

Steps

Check the path to the default $JAVA_HOME

 $ echo $JAVA_HOME
 C:\Users\your.username\.jdks\corretto-17.0.12

Edit your aliases.sh for Git Bash. See this article on how to add permanent aliases in Git Bash.

 jasypt_algorithm=PBEWithMD5AndDES
 jasypt_path={path-to-your-unzipped-jasypt}/jasypt-1.9.3/bin
 jasypt_password={your choice of master password}

 alias encrypt-jasypt='$jasypt_path/encrypt.sh password=$jasypt_password algorithm=$jasypt_algorithm'
 alias encrypt-jasypt='$jasypt_path/decrypt.sh password=$jasypt_password algorithm=$jasypt_algorithm'

Start a new session of Git Bash
Test the encryption

 $ encrypt-jasypt input="foo.b4r"
 ----ENVIRONMENT-----------------

Runtime: Amazon.com Inc. OpenJDK 64-Bit Server VM 17.0.12+7-LTS
----ARGUMENTS-------------------
input: foo.b4r
password: *****
algorithm: PBEWithMD5AndDES
----OUTPUT----------------------
pJ3SUb+U4Xh98+uF0f2uYA==

Test the decryption

$ decrypt-jasypt input="pJ3SUb+U4Xh98+uF0f2uYA=="

----ENVIRONMENT-----------------
Runtime: Amazon.com Inc. OpenJDK 64-Bit Server VM 17.0.12+7-LTS
----ARGUMENTS-------------------
input: pJ3SUb+U4Xh98+uF0f2uYA==
password: ****
algorithm: PBEWithMD5AndDES
----OUTPUT----------------------
foo.b4r

Keeping up with Spring Boot

Hafiz Jaafar — Sun, 02 Jun 2024 15:51:45 +0000

Just like my previous post 'GitOps problems', this time I want to summarize the interesting points of an article I have read recently from the Javamagazin (3rd issue of 2024).

Credits to author Michael Simons, who wrote 7 pages about Spring Boot 3 in that magazine.

Spring Framework 6 + Java 17 => Spring Boot 3
Maven and Gradle for version and dependencies management
Testcontainers and @ServiceConnection

Spring Framework 6 + Java 17 => Spring Boot 3

Spring Boot is a framework to implement not only microservices, but also small services and monolithic applications.

Spring Boot is not only the framework for such applications out there. There are also Quarkus and Micronaut, which boast reduction of startup time and resources.

Spring Boot 3, from Spring Framework 6, makes the minimalist Java 17 a mandatory.

One will also come across Jakarta EE, which replaces Java EE (EE stands for Enterprise Edition, in contrast to SE - Standard Edition).

Maven and Gradle for version and dependencies management

Since Spring Boot 3, we can declare a dependency without specifying the version. But, it is also suggested that we use properties section to specify a version.

<properties>
  <foo.bar.version>1.0.0</foo.bar.version>
</properties>

<dependencies>
  <dependency>
    <group>com.foo.bar</group>
    <artifactId>foo.bar</artifactId>
    <version>${foo.bar.version}</version>
  </dependency>
</dependencies>

Gradle is an alternative to Maven. It supports Java, Kotlin, C/C++, Javascript, etc.

Testcontainers and @ServiceConnection

Testcontainers provides lightweight and one-way instances for everything that can be containerized: databases, message brokers, web browsers, etc.

We can specify Testcontainers as a dependency in test scope.
A new annotation @ServiceConnection is used to mark a method as a source of a Testcontainer.

Testcontainer should be useful, especially if we cannot connect to external sources, e.g. a database or message broker that is deployed on a cloud somewhere and only accessible via VPN.

GitOps problems

Hafiz Jaafar — Sun, 19 May 2024 15:07:36 +0000

This is what I've learned from reading the article 'Reverte doch einfach!' (author: Lars Kölpin-Freese) in the magazine Javamagazin (in German language, 3rd issue of 2024).

Abstract
Upward migration
Stateless apps
Traveling back with git revert
Down migration at infrastructure level
Summary

Abstract

In GitOps, text files are used to administer IT infrastructure. This article raised the question of using 'git revert' if any rollback is necessary.
A simple rollback per versioning of the infrastructure with git should be feasible for stateless apps.

Upward migration

For upward migration, especially involving databases, scripts are used for traceability. The available tools are:

Liquibase
Flyway

Stateless apps

There are three types of applications/apps:

stateless apps
stateless apps with stateful dependencies
stateful apps

A stateless app has all its data in its deployment, i.e. there is no dynamic data.
The advantage here is such an app is scalable and can be rolled back as it went.
But in practice, software update can only go up and rollback is practically impossible.
A big part of stateless apps has stateful dependencies, e.g. database correction.

Time travel with git revert

There are two possibilities for down migration:

app level
platform level

For down migration, scripts are also employed as the tools which have destructive effects, e.g. drop column.

Down migration at infrastructure level

Downgrade of applications can also be done at infrastructure level. The objective here is to enable data inventories without having developers to implement anything.
To achieve this, a backup system must be implemented first. There should be a separate system (of a software) to do the backup, especially the database into a storage.
Then with git revert, a rollback of a new version can take place. A disadvantage of this is that new data will be loss.

Summary

What I've learned from this article is the need to create a backup system, orchestrated with scripts, before rolling out a new version. To my understanding, the deployment time will be increased, but still that would be open for discussions among developers and SREs.

Coding offline vs. on the grid

Hafiz Jaafar — Thu, 14 Oct 2021 16:36:59 +0000

These are the programming languages in my journey, chronologically:

C
Assembly
C++
Python
Bash
C++, again
C#
Python, again
JavaScript
C#, again
Java
now: full-stack with Java, Spring Boot, and Angular

Retrospective

Now looking back, among those languages, I think: working with C++ and Python for my computer vision and robotics projects were the most enjoyable. Why: I could be satisfied with just my laptop, anywhere, especially in 30-plus-minute train rides, without Internet.

The present

Back to the present: I deal with web and middleware applications. The resources that I need are relatively huge:

IntelliJ IDEA (jokingly said that it can turn our machine to a heater for the cold winter days),
Internet connection,
one or two other running applications (usually on other servers),
Postman,
databases,
browser (let's bear in mind on how gluttonous Chrome is with RAM),
and once a while: Docker.

The struggle

Sure, I can host those locally. But I'll be frank, even with 32 GB of RAM and a high performance multicore processor, I prefer not to host other instances and databases on my own machine. It's like forcing a fully loaded truck to go uphill. Sure, the truck is up for it, but think of the gas! LOL. And I'm being cautious of my electricity bill, since most of us work from home since COVID-19. Shouldn't our employers compensate us for using our own Internet and electricity?

For one particular bug fix ticket, I did have to host a containerized database on my machine. Verdict: not bad. 7/10 I'd do that again.

I wrote this with the thought of missing the old days working offline with C++ and Python, especially these two are the main ingredients of my side projects.

My side projects are now dormant, because in my free time, I prefer to attend to other leisure activities (manga, walking, coffee shops, movies, and SLEEPING) - which are good actually for my health.

Conclusion

Now that I've seen what I can do with Jenkins, AWS, Docker, etc, I am sure that I will always need to work online. The thought of working offline (without Internet) is unfathomable.

CI/CD: continually delivering better codes

Hafiz Jaafar — Sun, 07 Mar 2021 09:11:29 +0000

At the time of writing this post, I am still not done reading this special edition of 'Entwickler Magazin', featuring my favorite topic: CI/CD (continuous integration / continuous deployment).

These are the points from that magazine that I noted for myself.

DevOps models:

One-team model: the Ops team is a subset, a part of Dev team
Collaboration model: DevOps is achieved in the collaboration betwen Dev team and Ops Team.
IAAS-model: infrastructure as a service.

CI/CD:

Tools:
- Jenkins
- Harness
- GitLab
- GitHub
- Atlassian Bamboo
CI tools: are to enable code components run together.
CD tools: are for automated tests and deployment.

Requirements for CD in an enterprise:

Abstract: CI != CD

Continuous integration: automated tests and analysis.
Continuous delivery: delivery pipelines
- scripted
- versioned
- reproducable
Feature toggles
Zero downtime
Blue Green Deployment:
- 2 complete Production environments
Canary Development
Secrets management, e.g. Vault:
- query via API - no clear/plain text leaves the vault.
Security and compliance - especially for containerized microservices:
- container security
- interservice communication

// To be continued.

Ideas for Next Iteration

Hafiz Jaafar — Sat, 06 Mar 2021 01:27:17 +0000

Coffee, cake, music, and a tech magazine.

Last October 2020, I wrote down these ideas after reading a special edition magazine called 'Frontend Spezial' of the series 'Der Softwerker', by the company codecentric AG.

These improvement ideas are related to the projects assigned to me at my work.

In the 4 sticky notes as seen in the picture above:

Frontend:

Display a progress bar.
Do analysis: measure the time elapsed between each request and response.
Test using different mobile devices: cellphones and tablets.
Use a common design instead of dependending on a common module.
Cypress: a JavaScript End-to-End testing framework.

Backend:

Separate the component into two new components: one to handle the work loads from the inside of the organization, and another for the outside.
Containerization: either on-premises or on the cloud. To read about the pros & cons:
- On-Premises Containers vs. Public Cloud Container Services
- To Use Physical Or To Use Virtual: That is the container deployment question

Tech stack for DIY robotics project

Hafiz Jaafar — Wed, 18 Nov 2020 22:19:57 +0000

Physical materials

Arduino starter kit:
- Arduino board
- Breadboard
- Jumper wires
- USB cable
Servo motor(s)
Optional:
- Popsicle sticks
- LEGO pieces
PC

Software and frameworks

OS:
- Ubuntu (Linux), or
- Debian (Linux), or
- Windows (experimental)
ROS (Robot Operating System)
Qt library
Essential IDE:
- Eclipse: extended with the plugin PyDev
- PyCharm
- Qt Creator - in Qt installation
- Qt Designer - in Qt installation
Git
Arduino library
Programming languages
- Python
- C++
- C
PyQt: Qt library wrapped in Python

Optionals

Redmine: a web application for project management (open source and free)
GitLab or GitHub

My typical routines at job as a full time software developer

Hafiz Jaafar — Sat, 24 Oct 2020 00:28:53 +0000

Early morning

Scrum daily stand-up meeting

Strive to talk less than 2 minutes.
Situation reports for yesterday - what I have achieved, be it reviews, story implementation, bugs fixes, etc.
Briefly announcing my targets for today: which JIRA tickets or 2nd level support issues that I might need to solve.
Occasionally: asking present colleagues 1 or 2 questions on certain matters.

Coffee

1 cup of double cappuccino with 1 piece of stavia tablet.
Brought back to my work desk.
Read my tickets on JIRA for the current sprint.
Wrote the today's TODO's on one Post-It, no more, no less. Stick it to the bottom panel of my main monitor.

Firing up the machine

IDE
database client application
remote SSH client
bash terminal

Before lunch

Actual works

Coding, or
Part 1 of 2nd level support issues: by analyzing log entries of related processes on remote servers or database entries, before executing appropriate measures.
Part 2 of 2nd level support issues: preparing brief reports, then write e-mail to concerned parties.
DevOps - attending problematic CI/CD processes on Jenkins.

After lunch

Continuing actual works

Coffee (see above), then
Back to coding, or
Do a coding review, or
Writing documentation on Confluence (it's like a Wikipedia): release notes, updating module's descriptions, or
Testing
DevOps - assisting the deployments in different environments

Late afternoon

Cooling down

Answering emails, if necessary.
Casual reading on the Internet: tutorials, news, articles,
Editing or writing articles in Confluence, e.g., Today I Learned
Summing up the works of the day: writing the talking points for tomorrow's daily stand-up meeting,
Turn off the computer, pack up, and go home.

If repetitive, then script it.

Hafiz Jaafar — Wed, 05 Aug 2020 01:55:45 +0000

Abstract

Let's assume that on Windows, you put your development projects under a main or common directory, e.g., 'development', and all of these projects are local Git repositories.

The repetitive problem: めんどくさい mendokusai - a hassle

It gets tedious, if you have to navigate into every directory and execute 'git remote update'.

you@your-pc MINGW64 /d/developments
$ ls -1
foo-bar-backend/
foo-bar-db/
foo-bar-frontend/

Solution: a helper script

Using Git Bash on Windows, I recommend an executable bash-like helper script to navigate through all these projects and be done with it.

Write a helper script

Say, this script is named git_remote_update.bash:

#!/bin/bash.exe

echo
echo "Going into every directory here."
echo

for x in *;
do
    if [ -d "${x}" ]
    then
        if [ -e "${x}"/.git ]
        then
            cd "${x}"
            echo "${x}"
            echo "======================"
            echo "Calling git remote update ..."
            git remote update
            echo
            echo "Calling git status ..."
            git status
            echo
            cd ../
        fi
    fi
done

Set the file permission

Place this helper script in a dedicated directory, e.g., helperScriptsWindows, and change its permission so:

you@your-pc MINGW64 /d/helperScriptsWindows
$ chmod 755 git_remote_update.bash
$ ls -la
-rwxr-xr-x 1 you 197609 434 Mar 17  2018 git_remote_v.bash*

Include the directory into Path

Open the Windows Control Panel.
Navigate to System and Security => System => Advanced system settings => Environment Variables => System variables.
Click Path => New. Add the absolute path to the directory helperScriptsWindows. Done.

Check the PATH

You should be able to see the absolute path to the directory of your helper scripts is included:

you@your-pc MINGW64 ~
$ echo $PATH

Helper script usage

The script git_remote_update.bash should be already 'registered', and with few typing efforts, it's callable in the terminal:

you@your-pc MINGW64 /d/developments
$ git_remote_update.bash

Going into every directory here.

foo-bar-backend
======================
Calling git remote update ...
Fetching origin

Calling git status ...
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working tree clean

foo-bar-db
======================
Calling git remote update ...
Fetching origin

Calling git status ...
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working tree clean

foo-bar-frontend
======================
Calling git remote update ...
Fetching origin

Calling git status ...
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working tree clean

Have fun.

Using Dropbox or Google Drive for Git repositories

Hafiz Jaafar — Thu, 30 Jul 2020 22:46:57 +0000

When Git projects are considered too private to be pushed to GitHub or GitLab and you don't mind about missing the features there, then you could utilize your Dropbox or Google Drive as a Git repository.

Example

Following is an example with Dropbox on Ubuntu-Mate:

Dedicate a directory in Dropbox for Git:

you@your-pc:~$ cd Dropbox
you@your-pc:~/Dropbox$ mkdir git

Initialize your repository, at best with the same name with your project:

you@your-pc:~/Dropbox$ cd git
you@your-pc:~/Dropbox/git$ git init --bare your-project.git

If your project is not yet initialized as a Git project:

you@your-pc:~$ cd your-project
you@your-pc:~/your-project$ git init .

Connect your project with the Git repository in Dropbox:

you@your-pc:~/your-project$ git remote add origin ~/Dropbox/git/your-project.git

Commit your project for the first time and push to the repo. Start your Dropbox. You're done.

you@your-pc:~/your-project$ git add .
you@your-pc:~/your-project$ git commit -m "First commit." -m "From Dropbox."
you@your-pc:~/your-project$ git push -u origin master
you@your-pc:~/your-project$ caja-dropbox start

Git Bash on Windows: adding a permanent alias

Hafiz Jaafar — Tue, 28 Jul 2020 23:43:03 +0000

If you are using Git Bash on Windows and you're used to Linux bash commands, chances are that you'd like to add aliases that help making your jobs easier.

These two are my favorite aliases:

$ alias cll='clear; ls -lah'
$ alias countFiles='ls -1 | wc -l'

How to add an alias permanently for the Git Bash

To add an alias permanently, you'd need to edit the file
/C/Program Files/Git/etc/profile.d/aliases.sh .
Run your text editor as an administrator and open that file.
Add your alias and save the file.
Open the Git Bash. Execute 'alias', and you're done. Have fun.

$ alias
alias cll='clear; ls -lah'
alias countFiles='ls -1 | wc -l'
alias ll='ls -lah'
alias ls='ls -F --color=auto --show-control-chars'

DEV Community: Hafiz Jaafar

Jasypt CLI tools for encryption and decryption

Table of contents

Requirements

Steps

Keeping up with Spring Boot

Table of contents

Spring Framework 6 + Java 17 => Spring Boot 3

Maven and Gradle for version and dependencies management

Testcontainers and @ServiceConnection

GitOps problems

Table of contents

Abstract

Upward migration

Stateless apps

Time travel with git revert

Down migration at infrastructure level

Summary

Coding offline vs. on the grid

Retrospective

The present

The struggle

Conclusion

CI/CD: continually delivering better codes

DevOps models:

CI/CD:

Requirements for CD in an enterprise:

Ideas for Next Iteration

Frontend:

Backend:

Tech stack for DIY robotics project

Physical materials

Software and frameworks

Optionals

My typical routines at job as a full time software developer

Early morning

Before lunch

After lunch

Late afternoon

If repetitive, then script it.

Abstract

The repetitive problem: めんどくさい mendokusai - a hassle

Solution: a helper script

Write a helper script

Set the file permission

Include the directory into Path

Check the PATH

Helper script usage

Using Dropbox or Google Drive for Git repositories

Example

Git Bash on Windows: adding a permanent alias

How to add an alias permanently for the Git Bash