DEV Community: Sameer

Java and Typescript

Sameer — Wed, 12 Apr 2023 12:43:52 +0000

Java and Typescript

Java and TypeScript are two popular programming languages that have their own unique strengths and weaknesses. In this blog post, I will compare the two languages and highlight the key differences between them.

Overview

Java is a mature, object-oriented language that has been around for over two decades. It is a popular language for building enterprise-level applications and is widely used in web development, Android app development, and server-side programming.

TypeScript, on the other hand, is a relatively new language that was introduced by Microsoft. It is a superset of JavaScript and adds additional features such as static typing, classes, and interfaces.

Syntax

One of the key differences between Java and TypeScript is their syntax. Java has a more verbose syntax that requires the use of curly braces, semicolons, and parentheses. TypeScript, on the other hand, has a more concise syntax that is similar to JavaScript.

For example, here is a simple "Hello, world!" program in Java:

public class HelloWorld {
  public static void main(String[] args) {
    System.out.println("Hello, world!");
  }
}

And here is the same program in TypeScript:

console.log("Hello, world!");

Type Checking

One of the main advantages of TypeScript over Java is its support for static typing. Static typing allows developers to catch errors at compile time rather than at runtime, which can save a lot of time and effort.

Java also supports static typing, but it is more verbose and requires more code. TypeScript, on the other hand, allows developers to use type annotations to specify the types of variables, parameters, and return values.

For example, here is a simple function in Java that adds two numbers together:

public static int add(int a, int b) {
  return a + b;
}

And here is the same function in TypeScript:

function add(a: number, b: number): number {
  return a + b;
}

As you can see, the TypeScript code is more concise and easier to read.

Tooling

Both Java and TypeScript have a wide range of tools and libraries available to developers. However, Java has been around for much longer and has a more mature ecosystem. There are a wide range of IDEs, build tools, and libraries available for Java, and many large companies use Java as their primary programming language.

TypeScript, on the other hand, is a newer language and has a smaller ecosystem. However, Microsoft has invested heavily in the language and has developed a wide range of tools and libraries to support it.

Conclusion

In conclusion, Java and TypeScript are two popular programming languages that have their own unique strengths and weaknesses. Java is a mature language that is widely used in enterprise-level applications, while TypeScript is a newer language that adds additional features to JavaScript.

Both languages have their own syntax, type checking, and tooling, and developers should choose the language that best fits their needs. If you are looking for a language with a mature ecosystem and wide range of tools, Java may be the best choice. If you are looking for a language with a concise syntax and support for static typing, TypeScript may be the best choice.

Java

A mature object-oriented language
Requires verbose syntax with curly braces, semicolons, and parentheses
Supports static typing with more verbose code
Has a wide range of IDEs, build tools, and libraries available
Widely used in enterprise-level applications, web development, Android app development, and server-side programming

TypeScript

A relatively new language
A superset of JavaScript with a concise syntax
Adds additional features such as static typing, classes, and interfaces
Supports static typing with type annotations for variables, parameters, and return values
Has a smaller ecosystem but has a wide range of tools and libraries
Popular for web development, especially for front-end frameworks like Angular

References

Whats the best way to branch code repo?

Sameer — Mon, 23 Jan 2023 08:38:44 +0000

Currently, we are in a process of restructuring our branching. The main requirement is that, features should be tested in isolation and can be released one by one.

We have 2 branches, develop and main, and 3 deployment environments. DEV, STAGE and PROD.

We do feature branches out of DEV and do peer QA on these branches. Once the code is merged to develop we do a QA on the features merged on DEV env. And then to STAGE and to PROD.

But for us its really hard to release the features one by one. For now we are planning to block merge to develop until we merge the develop to main.

Any better strategy we can follow?

Log4j to Logback migration? Good idea or not?

Sameer — Tue, 25 Jan 2022 12:36:09 +0000

New Buzz word Log4j

By end of 2021, there came a new buzz word "LOG4J". People who don't know what log4j is started to talk about it. Jokes a part, log4j teared the world apart because of the security vulnerability that were exploited by Hackers. This security vulnerability was allowing attackers to execute malicious code remotely on a target computer. Which means hackers can easily steal data, plant malware, or take control of the target computer via the Internet.

How to overcome this issue

Solution 1

Update the library usage to the latest released version of log4j, where Apache team has fixed the "known" vulnerabilities.

Solution 2

Switch to different logger e.g. Logback

What is Logback?

Logback is a logging framework for mostly Java based applications, and a successor to the popular log4j project. Logback has many improvements over log4j. Just for information, logback is very much like log4j as both the projects were founded by the same developers. Logback is very similar to log4j when it comes to usage.

Why Logback?

Its very much like log4j, no extra knowledge need to use.
As its very much similar to log4j, its easy to replace.
Logback uses slf4j natively.
Auto compression of log files.
Many more.. Have a look at: Reasons to switch.

How to use Logback?

Add the logback dependencies.

Maven:

<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-api</artifactId>
    <version>${slf4j-version}</version>
</dependency>

<dependency>
    <groupId>ch.qos.logback</groupId>
    <artifactId>logback-core</artifactId>
    <version>${logback-version}</version>
</dependency>

<dependency>
    <groupId>ch.qos.logback</groupId>
    <artifactId>logback-classic</artifactId>
    <version>${logback-version}</version>
</dependency>

Gradle:

implementation("org.slf4j:slf4j-api:${slf4j-version}")
implementation("ch.qos.logback:logback-core:${logback-version}")
implementation("ch.qos.logback:logback-classic:${logback-version}")

If JAR files are needed locally then download them from logback download page.

If the application is based on Spring boot then, no additional dependencies are required as Spring boot provides log back support.

Add logback.xml file (logback-spring.xml in case of Spring boot) in src\main\resources. Sample logback.xml For more information about Logback configuration, check Link.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>

    <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
        <layout class="ch.qos.logback.classic.PatternLayout">
            <Pattern>
                %date{"yyyy-MM-dd'T'HH:mm:ss,SSSXXX", UTC} - %yellow([tid:%t])[sid:%X{httpSessionId}][reqid:%X{reqId}] - %green(%level) %cyan([%c]) - %m%n
            </Pattern>
        </layout>
    </appender>

    <appender name="appServerRollingFile" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>applogs/shpi-api.log</file>
        <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy">
            <fileNamePattern>applogs/$${date:yyyy-MMM}/shpi-api-%d{yyyy-MMM-dd}-%i.log.gz</fileNamePattern>
        </rollingPolicy>

        <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
            <maxFileSize>200MB</maxFileSize>
        </triggeringPolicy>
        <encoder>
            <pattern>%date{"yyyy-MM-dd'T'HH:mm:ss,SSSXXX", UTC} - [sid:%X{httpSessionId}][actor:%X{userId}][reqid:%X{reqId}] - %p [%c] - %m%n</pattern>
        </encoder>
    </appender>

    <root level="info">
        <appender-ref ref="STDOUT"/>
        <appender-ref ref="appServerRollingFile"/>
    </root>

</configuration>

How to use LoggerFactory instance.

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
...
static final Logger LOG = LoggerFactory.getLogger(ClassName.class);
...
{
  LOG.warn("Warn Test");
}

-
If migrating from Log4j to Logback use this translator tool from logback developers Translator.

Conclusion

Idea behind use of logback is the recent issues with log4j which gave everyone a reality check, that now there is definite need of log4j alternative.
May be now is the time to migrate!

References

Stable CI/CD is not a Myth, From Nexus-Jenkins to Github Packages-Actions

Sameer — Tue, 18 Jan 2022 12:43:49 +0000

This article provides an overview and learnings about why migration from own hosted CI/CD to SaaS CI/CD, is a way to go!

Let's first understand the history

Software Engineers from Generation X, Millennials generation must have at least once in their life worked with Jenkins (Back in time was Hudson). Java Stack CI/CD evolved around Jenkins. Most of us atleast once used Jenkins. And Artifactory later Nexus perfectly complements each other.

How our Self-hosted Jenkins and Nexus setup could look like.

Jenkins is mostly used for CI/CD, and in some cases as a Batch processor. To satisfy this requirement self hosted Jenkins instances running over AWS or self hosted pods on Kubernetes(K8S), mainly in MASTER -> SLAVE (agents) configuration is a correct choice.

Nexus instance can also be self hosted over AWS or with K8S.

Some of many problems with this setup and some solutions to fix some of them.

Problem 1. Security

Solution 1: 1st approach to make it secure is to use, VPN. Of course that makes it secure on the cost of performance plus overhead maintaining VPN instance as well.
Solution 2: To over come Open VPN issues, Client Side Certificates can be used. This setup involved writing a small code that will create a certificate and pushing the information to the certificate repo. But maintaining the certificate is kind of painful task.

Problem 2. Random Jenkins restarts, auto updates

Solution: Disabling auto update feature.

Problem 3. Outdated Plugins

Solution: Jenkins community is not growing these days, as other communities so some the plugins are not maintained and they dont work with new versions of Jenkins. So sticking to outdated plugins makes sense.

Problem 4. Pipeline builds

Again maintenance and writing Jenkinsfile without much of documentation is kind of hard.

Problem 5. Nexus maintenance is nightmare

DevOps team has to be own their toes , to patch and fix the Nexus instance, as storage could often be a issue. So storage has to be maintained manually. Plus deletion of old artifacts is also one more problem to tackle.

Last but not the least, Jenkins will fail when its needed the most. As most of the teams would rely on Jenkins for CI/CD these problems can grow exponentially and the maintenance causing DevOps precious time.

To make everyone's life easier moving to GitHub Actions and GitHub Packages could be a solution!

How CI/CD with GitHub Action could look like.

The advantage of migrating to GitHub Action is to use YAML instead of different way of defining the Job with Jenkins. Those YAML files are maintained under .github folder under the respective project that gives the ownership of the flows to the Project/Module owner. Below are some sample workflows that can be defined.

Build Develop/Main - For manually building develop or main.
Build PR - When ever a PR is raised for a merge on develop or main then this workflow is executed. This is runs whenever there is commit on the branch.
Publish - After successful build of develop or main, built jar is pushed to GitHub Packages.
Release Manual - Manually releasing & tagging a fixed version.
Auto Deploy API to DEV - After successful built of develop or main, changes are deployed to DEVELOPMENT environment.
Deploy API to ENV - Manual Deployment of fixed version of API to different environments.

Some Learnings after migration to GitHub Actions and Packages.

Stable CI /CD is not a Myth!
Now the project CI/CD is maintained by respective team, instead DevOps team.
Saved a lot of developer time, troubleshoot the issues with Jenkins and Nexus.
Saved resources as GitHub instance is used instead of self hosted.
Cost effective, as most basic subscription of GitHub provides access to Actions and Packages.
Stable and efficient as compared to Jenkins and Nexus.
Large Marketplace.
Large Developer community, more and more free actions (e.g - Slack Notification etc.) available.
Very short migration time.

Conclusion

Migration to GitHub Actions and Packages could save lot of frustration with Jenkins-Nexus combo. This will give you a chance to try out latest tools rather than being with old and outdated technologies. The process is may not be ideal for everyone, but it solves most of the issues with Jenkins.

As I said earlier, Stable CI/CD is not a Myth!

References

To do a Code task or not!

Sameer — Tue, 11 Jan 2022 08:45:19 +0000

I as a Senior Software Engineer, when think of applying for a job, few things come to my min.

What if as a Senior I don't fullfil the expectation?
What if I was presented a Live Coding Challenge?
What if I was given a Coding Task?

So after some thinking, I realised it all comes to judge me based on my coding skills.

When you work on a real challenge you use StackOverflow, Google etc etc. (Copy & Paste works in most cases, except some complex business logic)

But as you code for an interview offline or online, you think about Copy & Paste method. In live coding you can't even do that. For offline coding you can get inspired from some logic you find online.

My question is, what should be the ideal approach to these problems during job interviews?

Should coding is good metric to judge someone? Live coding makes sense? Or Git repos with some code exploring should be a metric.

Share your thoughts, experiences, Lets learn together.

Discuss : What is A Code Review? (PR)

Sameer — Mon, 20 Dec 2021 15:29:36 +0000

Since so many days a Topic is in my mind. I would like to know, what is a code review for you?

Syntax and code quality check
Business logic check
Both

How much important is each topic?

How a usual code review looks like for you?

Please share your views and thoughts!

Testcontainers with Spring Boot and Java 11/17

Sameer — Wed, 08 Dec 2021 17:54:50 +0000

What are Testcontainers?

Testcontainers is a JVM library that allows users to run and manage Docker images and control them from Java code.
The integration test additionally runs external components as real Docker containers.

Databases - Run PostgreSQL as a Docker image
Mocked HTTP server - HTTP services by using MockServer or WireMock Docker images
Redis - run real Redis as a Docker image,
Message Brokers - RabbitMQ
AWS - S3, DynamoDB etc
Any other application that can be run as a Docker image

How to use?

Setup : Spring Boot and Junit 5
Dependency to testImplementation "org.testcontainers:postgresql:1.16.2” and testImplementation "org.testcontainers:junit-jupiter:1.16.2”
And then some wireing () to start testcontainers and link them to the test context so that integration tests knows where to look for the containers.

Example Abstract Class for setup

package com.test;

import org.springframework.boot.test.autoconfigure.jdbc.AutoConfigureTestDatabase;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.context.ApplicationContextInitializer;
import org.springframework.context.ConfigurableApplicationContext;
import org.springframework.context.annotation.PropertySource;
import org.springframework.test.context.ActiveProfiles;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.support.TestPropertySourceUtils;
import org.springframework.test.web.servlet.request.MockHttpServletRequestBuilder;
import org.testcontainers.containers.PostgreSQLContainer;
import org.testcontainers.ext.ScriptUtils;
import org.testcontainers.jdbc.JdbcDatabaseDelegate;
import org.testcontainers.junit.jupiter.Testcontainers;
import org.testcontainers.shaded.com.fasterxml.jackson.databind.ObjectMapper;
import org.testcontainers.shaded.com.fasterxml.jackson.databind.SerializationFeature;

import java.util.Optional;

import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.post;
import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.put;


@Testcontainers
@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT, classes = {com.test.Application.class})
@ActiveProfiles(AbstractBaseIntergrationTestConfiguration.ACTIVE_PROFILE_NAME_TEST)
@AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE)
@ContextConfiguration(initializers = AbstractBaseIntergrationTestConfiguration.DockerPostgreDataSourceInitializer.class)
public abstract class AbstractBaseIntergrationTestConfiguration {

    protected static final String JDBC_URL = "jdbc.url=";
    protected static final String JDBC_USERNAME = "jdbc.username=";
    protected static final String JDBC_PASSWORD = "jdbc.password=";
    protected static final String JDBC_DRIVER_CLASS_NAME_ORG_POSTGRESQL_DRIVER = "jdbc.driverClassName=org.postgresql.Driver";
    protected static final String ACTIVE_PROFILE_NAME_TEST = "TestContainerTests";

    //--
    public static PostgreSQLContainer<?> postgreDBContainer;
    protected ObjectMapper objectMapper = new ObjectMapper().disable(SerializationFeature.FAIL_ON_EMPTY_BEANS);

    static {
        // Init DB Script here
        postgreDBContainer = new PostgreSQLContainer<>(IntegrationTestConstants.POSTGRESQL_IMAGE);
        postgreDBContainer
                .withInitScript(IntegrationTestConstants.INIT_DB_SCRIPT)
                .withDatabaseName(IntegrationTestConstants.DB_NAME)
                .withUsername(IntegrationTestConstants.DB_USERNAME)
                .withPassword(IntegrationTestConstants.DB_PASSWORD);

        postgreDBContainer.start();
        var containerDelegate = new JdbcDatabaseDelegate(postgreDBContainer, "");

        // Adding Database scripts here
        ScriptUtils.runInitScript(containerDelegate, IntegrationTestConstants.MISSING_TABLES_SQL);
        ScriptUtils.runInitScript(containerDelegate, IntegrationTestConstants.SAMPLE_DATA_SQL);
    }

    // This class adds the DB properties to Testcontainers.
    public static class DockerPostgreDataSourceInitializer implements ApplicationContextInitializer<ConfigurableApplicationContext> {

        @Override
        public void initialize(ConfigurableApplicationContext applicationContext) {

            TestPropertySourceUtils.addInlinedPropertiesToEnvironment(
                    applicationContext,
                    JDBC_DRIVER_CLASS_NAME_ORG_POSTGRESQL_DRIVER,
                    JDBC_URL + postgreDBContainer.getJdbcUrl(),
                    JDBC_USERNAME + postgreDBContainer.getUsername(),
                    JDBC_PASSWORD + postgreDBContainer.getPassword()
            );
        }
    }
}

How to write a test?

@Test
void checkIfUserExistInIdealCase() throws Exception {

  request.put("email", "abc@test.com");

  final MockHttpServletRequestBuilder postObject = getPostRequestExecutorBuilder("http://localhost:8080/v1/checkemail/", Optional.empty());
  final MvcResult result = mockMvc.perform(postObject.content(request.toString())).andExpect(status().isOk()).andReturn();
  final String content = result.getResponse().getContentAsString();

  final SyncResponseDto responseDto = objectMapper.readValue(content, SyncResponseDto.class);

  assertThat(responseDto.getResponseReturnCode()).isEqualTo(ResponseReturnCode.USER\_EXIST);
}

Advantages

Run Integration Tests offline.
You run tests against real components, PostgreSQL database instead of the H2 database.
You can mock AWS services.
Implementation and tests can be written by developers same time when raising a PR.

Disadvantages

The main limitation is, that containers cannot be reused between test classes.
Adding “one more” external dependency.
Takes a bit more time than usual to start a container, 4 - 5 seconds for Postgres VS 0.5 seconds for H2.
When running locally, local machine should be powerful enough too ;)
More RAM, More Power as multiple containers can be run.

References

GitHub Pull Request Template a faster way to document a PR

Sameer — Fri, 29 Oct 2021 19:10:22 +0000

Why do you need a Pull Request Template?

Pull Request(PR) are often when raised are not properly documented. The best way to document them is to use a consistent template. The Template will help the team to document the PR in a concise way. PR reviewer gets an idea about what to expect in a PR.

How to add a GitHub PR Template?

Create a file pull_request_template.md inside a root folder of the repository called ./github

./github/pull_request_template.md

This file is nothing but a template that will be shown on GitHub PR, when the PR is raised.

Sample Template file

## Description
<!-- Please write a brief information about PR, what it contains, its purpose -->

## Link to Jira
<!-- If there is a ticket for this -->

## Screenshots
<!-- Please add screenshots -->

## Testing
<!-- How to test PR -->

How to configure Dependabot with Gradle

Sameer — Fri, 22 Oct 2021 09:03:11 +0000

What is a Github Dependabot?

Dependabot provides a way to keep your dependencies up to date. Depending on the configuration, it checks your dependency files for outdated dependencies and opens PRs individually. Then based on requirement PRs can be reviewed and merged.

Dependabot with Gradle

Dependabot has a limited support for Gradle. Dependabot looks for a build.gradle or a settings.gradle in your repo, then scans for outdated dependencies and creates a PR based on available updates.

Issue

The issue aries when dependencies are maintained outside of these two files. Dependabot ONLY and ONLY scans build.gradle or settings.gradle. Most of the projects would follow this standard of having versions in these files, but remaining ones wont work at all.

Solution

There is a workaround to this issue. Follow the steps explained below to tackle this issue.

Create dependencies.gradle file to extract all the dependencies. The file name HAS TO BE dependencies.gradle, otherwise the solution will not work. (version.gradle is also not supported!)


ext {
    // -- PLUGINS
    springBootVersion = "2.5.5"
    springDependencyManagementVersion = "1.0.11.RELEASE"
    ....

    //-- DEPENDENCIES
     ....  
     springFoxBootVersion = "3.0.0"
    hibernateVersion = "5.4.31.Final"
    c3p0Version = "0.9.5.5"
    postgresVersion = "42.2.10"
    .... 
    supportDependencies = [
            springfox_boot_starter            : "io.springfox:springfox-boot-starter:$springFoxBootVersion",
            hibernate_entitymanager           : "org.hibernate:hibernate-entitymanager:$hibernateVersion",
            hibernate_core                    : "org.hibernate:hibernate-core:$hibernateVersion",
            c3p0                              : "com.mchange:c3p0:$c3p0Version"
            hibernate_java8                   : "org.hibernate:hibernate-java8:$hibernateVersion",
            postgresql                        : "org.postgresql:postgresql:$postgresVersion",
            ....
    ]
}

Modify build.gradle to use dependencies.gradle


buildscript {
    apply from: 'dependencies.gradle'
}
plugins {
    id 'org.springframework.boot' version "${springBootVersion}"
    id 'io.spring.dependency-management' version "${springDependencyManagementVersion}"
    ....
}
dependencies {
    ....
    implementation supportDependencies.springfox_boot_starter
    implementation supportDependencies.hibernate_entitymanager
    implementation supportDependencies.hibernate_core
    implementation supportDependencies.c3p0
   ....
}
....

Add dependabot support with .github/dependabot.yml file to the project.

version: 2
updates:
  - package-ecosystem: "gradle" 
    directory: "/" 
    schedule:
      interval: "daily"

Tadaaaa.. On the next run or on a force run of dependency check, if there are updates you should see PRs opened by dependabot.

Conclusion

Dependabot is an amazing tool, to make sure your project gets latest dependencies. But the support of Gradle as compared to Maven is limited when dependencies are not maintained build.gradle or settings.gradle.

If you dont want to maintain the versions in these two files, you can tweak your gradle files in a way that dependabot can scan the project and will find out the issues with the dependencies.

Special Thanks to Sumedh.