DEV Community: Fırat Küçük

Be Strict in Software Development

Fırat Küçük — Mon, 04 Dec 2023 11:09:53 +0000

BE STRICT

“Being strict” might not hold true in all areas of life: "Bend, so you don't break." However, I am going to talk about software development. Besides watching cat videos, it's kind of my only hobby.

Yes, “be strict” in software development. Draw lines, restrict users, restrict yourself. Until AI writes software for us, we need to be strict. Human nature is error-prone, and we tend to forget. Standards and metrics make us better engineers.

Also, our software quality fluctuates between mood swings. If you're not well-caffeinated or it's Monday morning, you might not be proud of your craftsmanship. I could list many bullet points, but let's stick to the 7 deadly sins of software development. Well, not deadly, but let's keep them in mind.

1. Constraints on Persistence Layer

Your data is one of the most valuable parts of your software system. Imagine a user ordering -3 smartphones on your online webshop. You'd probably need to give those phones for free. Or imagine a user uploading a 1GB profile image.

Our persistence layer, in other words, our database, data warehouse, data lake, or whatever you call it, should be clean and consistent.

In some companies I've worked with, I've witnessed engineers intentionally avoiding the use of database constraints or foreign key relations because they might slow down write operations. Theoretically, that might be true, but the cost of inconsistent data could be much bigger, and the consequences might be really painful.

Another trend is "schema-less" NoSQL databases. In the real world, nothing is schema-less. You don't want to put your products in your user collection (table). In most cases, everything is well-defined. The only difference is that if you add some additional fields (columns), your database won't complain about it.

I can say they are mostly schema-flex (yes, I made it up) databases. Most of the time, schemas are our best friends—XML schema definitions, JSON schemas, or database schemas. Being strict about your data will reward you.

To sum up, be a good developer and use schemas, constraints, and relations if possible.

2. Data Validation

The internet is not a safe place from the very beginning of your website's life journey. People will try to enter the most ridiculous inputs you can ever imagine. Some users will do this on purpose, and for some, they were born like that. They will try to put emojis as usernames because who doesn't love unicorns, or they will try some JavaScript inside a textarea because JavaScript is their favorite programming language.

No matter what the intention is, the solution is restricting user input; otherwise, it might cause serious problems in your system. The most crucial part is backend validation because it directly affects your system. This input can be a form, REST API, GraphQL, or any other kind of protocol data. Also, data can come from the outside world, inside your company, or from another microservice.

Winter is coming. Prepare your backend. For better UI/UX, use frontend validation as well. Imagine you're filling out 5 pages of a form, and you realize you made some mistakes after sending the data to the server. Surprise! Form data is also lost. It is understandable that sometimes people want to beat up developers.

3. Separated Layers

While developing, we have some logical boundaries. They can result from Domain Driven Design or a software architecture you have followed. If your code is inside a single file with 6000 lines, it might not be a good indicator.

Separating your business logic and transactional part might be a wise decision. I assume I first saw it in a Quarkus project. It allows you to create some architectural layer communication tests. For example, when we call the repository method directly from the controller layer, these layer tests will fail.

Modern IDEs have powerful tools for checking coupling and cohesion between packages, layers, and namespaces. Also, some automated plugins check that kind of layer testing.

4. Security Hardening

Most of us have some insecurities, but that doesn't mean we aren't going to help poor apps rise and shine. Probably, this one should be a whole separate article. But I can mention some of the security issues here.

Forcing users to choose strong passwords is the first step that should be taken. If your system stores passwords in plain text, please don't. Also, we may want to use one of the modern hashing algorithms like SHA512, SHA3, and a teaspoon of "salt" against dictionary attacks.

Taking action against code injection might be another important step. Modern frontend libraries encode HTML, and some ORMs prevent SQL injection by default.

Enabling CORS, using CSRF tokens, using strict HTTP headers (CSPs), a TLS layer, constant dependency scans, and automated vulnerability scans can be some of the important ones.

5. Code Quality Check

Code quality check starts with a good code style. Using a code formatter and format checker can be a first step; a linter might also help against some redundant or faulty usages. Like using "var" instead of "const/let" in JavaScript or an unused import statement in Java.

Some plugins or helper services might help you check your code status. I use such tools for limiting the line count of methods and classes and restricting the cyclomatic complexity of a method or a class.

Some other tools might prevent you from shooting yourself in the leg. They can detect well-known anti-patterns and faulty usages. Also, we can put testing itself into this category: unit, integration, smoke, end-to-end API/UI tests. Code and path coverage also might be good indicators of the status of your application.

Some frameworks also provide strict modes for better usage checking and best practices. Using those kinds of options might help you improve code quality.

Better to put those checks in a pipeline or a git commit hook; it might help us keep our code base clean.

6. Cross-cutting Concerns

Let's assume we aim to persist a simple User entity in the database. In ideal conditions or a scenario, every user can provide perfect inputs. That code could be a couple of lines. However, we need to pay attention to input validation, database transactions, auditing, timeout management, database connection pooling, retry mechanism, exception handling, anti-corruption layer, and so on.

Programming becomes a cumbersome task if you're dealing with lots of boilerplate code. It could be 3 lines of code or a thousand lines of code if you're dealing with that kind of thing in your actual code. Using modern frameworks might help with that one. Or some kind of interceptors, middlewares, or aspect-oriented programming.

7. Statically-typed Language

I don't want to start a flame. This might be a sensitive topic if you're emotionally attached to your programming language. Most modern languages use better practices compared to their predecessors. Statically typed languages help us see our coding errors beforehand or provide us with better IDE or editor code-complete support. They might offer us to compensate for the billion-dollar mistake "Null" data type. Modern languages provide syntactic sugars for optional data management. Also, by default, immutable data types are a really good way to handle data.

If you're using JavaScript, TypeScript might be a good alternative (and avoiding the "any" type). Kotlin can be an alternative to Java. For Python developers, Python already offers static typing in version 3. Using that one might be a wise choice.

Lilo the stitching library for GraphQL

Fırat Küçük — Sun, 18 Sep 2022 11:01:58 +0000

The story is a well-known Not Invented Here syndrome among developers. Let me summarize from the beginning. Reverse proxies are good especially if you are using REST API, Even if you have multiple microservices behind the proxy. You can efficiently serve all your REST API via using an API Gateway. You can even make some transformation magic, authorization, aggregation, and plenty of other custom flavors. The sky is the limit.

But when it comes to GraphQL, it's not that easy. Especially if you want to transform a legacy code base without changing thousands of lines in frontend. You have 2 options one of them is GraphQL Federation which is a good practice to go with it. But it combines the methods in namespaces, so you might need some refactoring on frontend as well. The second option is GraphQL stitching.

I chose the stitching option. Then I stuck with Atlassian Braid which is a really handy tool TBH. But it seems deprecated and has not been touched for a while. Especially issues sections, there are plenty of bugs reported or questions from 3 years back. I was also trying to use Atlassian Braid on Spring Cloud Gateway. It was really good at the beginning till we deployed it on production. Because of the complex reactive streams logic on the Gateway. It causes lots of thread starvation or unresponsiveness. That eventually triggered me to implement a new one.

Like most of the developers, my estimation was wrong. I've estimated it as a weekend project then it turns out a complete level. then I ended up with Lilo Stitching library and here we are.

How GraphQL Stitching works

When the Stitching library starts, it fetches the schema from the target schema sources, They might be a remote schema source or an internal source as well. After that, it maps all the GraphQL mutations and queries with respective sources.

For every incoming request, it analyzes the query and redirects the requests to respective schema sources after that it combines all the results and returns an aggregated result as a GraphQL response.

Example usage

Installation

Required dependency should be added to your project if you're using maven then you can add it into your pom.xml file:

<dependencies>
  ...
  <dependency>
    <groupId>io.fria</groupId>
    <artifactId>lilo</artifactId>
    <version>23.11.1</version>
  </dependency>
  ...
</dependencies>

If you're using gradle then you can add the dependency in your build.gradle file.

implementation 'io.fria:lilo:23.11.1'

Creating the source applications

You can use lilo with various libraries and web frameworks but I'll try to show a basic usage with spring boot. We need to create two different service projects for exhibiting lilo's skills. Thanks to GraphQL spring project we have now the ability to create GraphQL controller via using annotations just like the REST API.

Controller for Service Application1:

@Controller
public class GreetingController {

  @QueryMapping
  public @NonNull String greeting1() {
    return "Hello world";
  }
}

Then we are going to create a similar controller for our second application:

@Controller
public class GreetingController {

  @QueryMapping
  public @NonNull String greeting2() {
    return "Hello world";
  }
}

We also need to add GraphQL schema definition into resources/graphql directory. For Application1:

type Query {
    greeting1: String
}

same for the application 2:

type Query {
    greeting2: String
}

The package hierarchy should be something like this for both applications:

├── pom.xml
└── src
    └── main
        ├── java
        │   └── com
        │       └── example
        │           └── stitching_sample
        │               └── server1
        │                   ├── BssServer1Application.java
        │                   └── GreetingController.java
        │                       
        └── resources
            ├── application.properties
            └── graphql
                └── schema.graphqls

It might be wise to assign different port numbers in your application.properties or application.yml using server.port. We will be using 8081 for application 1 and 8082 for application 2.

Creating the gateway

We will be using lilo inside a GraphQL REST controller but you can use it via a filter or you can use it with different web frameworks as well.

@Controller
public class LiloController {

  private static final String SERVER1_NAME = "SERVER1";
  private static final String SERVER1_BASE_URL = "http://localhost:8081";
  private static final String SERVER2_NAME = "SERVER2";
  private static final String SERVER2_BASE_URL = "http://localhost:8082";

  private final Lilo lilo;

  public LiloController() {

    this.lilo =
        Lilo.builder()
            .addSource(
                RemoteSchemaSource.create(
                    SERVER1_NAME,
                    new IntrospectionRetrieverImpl(SERVER1_BASE_URL),
                    new QueryRetrieverImpl(SERVER1_BASE_URL)))
            .addSource(
                RemoteSchemaSource.create(
                    SERVER2_NAME,
                    new IntrospectionRetrieverImpl(SERVER2_BASE_URL),
                    new QueryRetrieverImpl(SERVER2_BASE_URL)))
            .build();
  }

  @ResponseBody
  @PostMapping("/graphql")
  public @NonNull Map<String, Object> stitch(@RequestBody final @NonNull GraphQLRequest request) {
    return this.lilo.stitch(request.toExecutionInput()).toSpecification();
  }
}

When the controller starts, it will create a combined GraphQL schema using the remote sources and it will execute incoming requests using lilo.

We also need additional Retriever definitions. Those classes retrieve the schema or query results. IntrospectionRetriever retrieves the remote schema and QueryRetriever is used for every single request for communicating and executing a single query or a mutation on the remote site.

class IntrospectionRetrieverImpl implements SyncIntrospectionRetriever {

  private final String schemaUrl;
  private final RestTemplate restTemplate;

  IntrospectionRetrieverImpl(final @NonNull String schemaUrl) {
    this.schemaUrl = schemaUrl + "/graphql";
    this.restTemplate =
        new RestTemplateBuilder()
            .defaultHeader(HttpHeaders.CONTENT_TYPE, MediaType.APPLICATION_JSON_VALUE)
            .build();
  }

  @Override
  public @NonNull String get(
      final @NonNull LiloContext liloContext,
      final @NonNull SchemaSource schemaSource,
      final @NonNull String query,
      final @Nullable Object localContext) {

    return Objects.requireNonNull(
        this.restTemplate.postForObject(this.schemaUrl, query, String.class));
  }
}

and we also need to define our QueryRetriever

class QueryRetrieverImpl implements SyncQueryRetriever {

  private final String schemaUrl;
  private final RestTemplate restTemplate;

  QueryRetrieverImpl(final @NonNull String schemaUrl) {
    this.schemaUrl = schemaUrl + "/graphql";
    this.restTemplate =
        new RestTemplateBuilder() //
            .defaultHeader(HttpHeaders.CONTENT_TYPE, MediaType.APPLICATION_JSON_VALUE) //
            .build(); //
  }

  @Override
  public @NonNull String get(
      final @NonNull LiloContext liloContext,
      final @NonNull SchemaSource schemaSource,
      final @NonNull GraphQLQuery graphQLQuery,
      final @Nullable Object localContext) {

    return Objects.requireNonNull(
        this.restTemplate.postForObject(this.schemaUrl, graphQLQuery.getQuery(), String.class));
  }
}

now we are ready we can run all 3 applications and see the results.

curl -X POST \
    -H 'content-type: application/json' \
    -d '{"query":"{\ngreeting1\ngreeting2\n}","variables":null}' \
    http://localhost:8080/graphql

greeting1 will be executed on application1 and greeting2 will be executed on application2 we will get the results in a combined GraphQL response.

You can take a look at the sample implementation code on the official Lilo repo. Check out the sample

Creating GitHub Action to Deploy Projects into a Private Maven Repository

Fırat Küçük — Wed, 01 Jul 2020 22:32:55 +0000

I have been heavily using other CI/CD platforms like GitLab, BitBucket, Jenkins, and Azure DevOps but I can definitely say GitHub nailed it. It has a different and easy-to-use approach and I am surprised that you can add custom runners for your CI/CD pipeline.

I will create a very simple Kotlin application to show how to deploy a library in a private Maven repository. I am going to use Repsy for Maven repository hosting. It gives 3 GB of free storage and should be sufficient for most cases.

Let's create a Gradle project, your IDE will help with this, or you can install Gradle CLI from the official gradle site or you can use SdkMan for this purpose.

sdk i gradle

Gradle CLI will help you to bootstrap your project.

mkdir hello-actions-kotlin-lib
cd hello-actions-kotlin-lib
gradle init

Gradle will ask us a bunch of questions. I will select the library type for project generation

Select the type of project to generate:
  1: basic
  2: application
  3: library
  4: Gradle plugin
Enter selection (default: basic) [1..4] 3

Kotlin for programming language selection. I'm happy to see plenty of options there.

Select implementation language:
  1: C++
  2: Groovy
  3: Java
  4: Kotlin
  5: Scala
  6: Swift
Enter selection (default: Java) [1..6] 4

And going to use Kotlin DSL instead of Groovy.

Select build script DSL:
  1: Kotlin
  2: Groovy
Enter selection (default: Kotlin) [1..2] 1

Just press enter for the default project name or you can enter another one suitable for you.

Project name (default: hello-actions-kotlin-lib):

For the source package selection, I am going to use my GitHub TLD but feel free to use your package structure.

Source package (default: hello.actions.kotlin.lib): com.github.firatkucuk.hello_actions_kotlin_lib

As a final question gradle will ask you the Java version. You may want to select the Latest LTS version (21) or one one the safest ones 8 or 11. I'll choose 17.

Enter target version of Java (min. 7) (default: 21): 17

It seems a little bit long but that’s OK. Gradle will create a simple Library.kt file. Let’s rename it Hello.kt and change the content.

package com.github.firatkucuk.hello_actions_kotlin_lib;

class Hello {
    fun sayHello(text: String): String {
        return "Hello $text"
    }
}

And same for the test file LibraryTest.kt. Let's rename it to HelloTest.kt and change the test file content to:

package com.github.firatkucuk.hello_actions_kotlin_lib

import kotlin.test.Test
import kotlin.test.assertEquals

class HelloTest {
    @Test fun sayHelloMethodReturnsHello() {
        val classUnderTest = Hello()
        assertEquals("Hello World", classUnderTest.sayHello("World"), "sayHello method should return 'Hello World'")
    }
}

Now, we can test the build operation:

gradle build

The next phase is publishing our library to our private maven repository in repsy.io. After signup, repsy creates a default repository that can be used with the account password. So you only need to sign up, and that’s all.

Let’s modify our build.gradle.kts file for publishing the artifact. The most important part is adding a maven-publish plugin and a publishing section with the credentials from repsy.

version = "1.0.0"

plugins {
    // Apply the org.jetbrains.kotlin.jvm Plugin to add support for Kotlin.
    id("org.jetbrains.kotlin.jvm") version "1.9.10"

    // Apply the java-library plugin for API and implementation separation.
    `java-library`
    `maven-publish`
}

repositories {
    // Use Maven Central for resolving dependencies.
    mavenCentral()
}

val repsyUrl: String by project
val repsyUsername: String by project
val repsyPassword: String by project

publishing {
    publications {
        create<MavenPublication>("maven") {
            from(components["java"])
        }
    }

    repositories {
        maven {
            url = uri(repsyUrl)
            credentials {
                username = repsyUsername
                password = repsyPassword
            }
        }
    }
}

dependencies {
    // Use the Kotlin JUnit 5 integration.
    testImplementation("org.jetbrains.kotlin:kotlin-test-junit5")

    // Use the JUnit 5 integration.
    testImplementation("org.junit.jupiter:junit-jupiter-engine:5.9.3")

    testRuntimeOnly("org.junit.platform:junit-platform-launcher")

    // This dependency is exported to consumers, that is to say found on their compile classpath.
    api("org.apache.commons:commons-math3:3.6.1")

    // This dependency is used internally, and not exposed to consumers on their own compile classpath.
    implementation("com.google.guava:guava:32.1.1-jre")
}

// Apply a specific Java toolchain to ease working on different environments.
java {
    toolchain {
        languageVersion.set(JavaLanguageVersion.of(17))
    }
}

tasks.named<Test>("test") {
    // Use JUnit Platform for unit tests.
    useJUnitPlatform()
}

Our project implementation is completed. Let’s create git integration of our project. First, create an empty git project called hello-actions-kotlin-lib on GitHub. After that, we commit the changes and push files to GitHub.

git init
git add .
git commit -m "initial commit"
git remote add origin git@github.com:YOUR_GITHUB_USER_NAME/hello-actions-kotlin-lib.git
git push origin main

The next step is integrating your project with GitHub Actions. Go to https://github.com/YOUR_USER_NAME/hello-actions-kotlin-lib/actions/new

Please Find the Java with Gradle Action. Then you can click the Set up this workflow button. An online editor will be opened up.

Let’s directly commit the changes and we’re gonna see our Action will run immediately. GitHub action will fail so please ignore this. It requires some properties file we’re gonna add properties as GitHub secret.

We need to create a GitHub secret for our gradle.properties file. But because of the limitations. GitHub cannot use file content as secrets. GitLab has the same restriction once upon a time then they’ve introduced File types but we need to create a text file our local computer. The content should be something like this:

repsyUrl=https://repo.repsy.io/mvn/YOUR_REPSY_USERNAME/default
repsyUsername=YOUR_REPSY_USERNAME
repsyPassword=YOUR_REPSY_PASSWORD

We need to encode this with base64. There are many online base64 converters. If you’re using Mac/Linux it should be easy like this:

base64 -w0 gradle.properties

Let's copy the output and create a secret. Go to https://github.com/YOUR_USER_NAME/hello-actions-kotlin-lib/settings/secrets

Add a GitHub secret called GRADLE_PROPERTIES and paste the encoded string into it.

Now we can open our pipeline configuration file and make the latest changes. Go To https://github.com/YOUR_USER_NAME/hello-actions-kotlin-lib/blob/master/.github/workflows/gradle.yml and click the edit button. We will add some extra steps for injecting Gradle properties.

name: Java CI with Gradle

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4.1.1

      - name: Set up JDK 17
        uses: actions/setup-java@v3.13.0
        with:
          java-version: 17

      - name: Grant execute permission for gradlew
        run: chmod +x gradlew

      - name: Build with Gradle
        env:
          GRADLE_PROPERTIES: ${{ secrets.GRADLE_PROPERTIES }}
        run: mkdir -p ~/.gradle && echo $GRADLE_PROPERTIES | base64 -d > ~/.gradle/gradle.properties && cat ~/.gradle/gradle.properties && ./gradlew build

      - name: publish
        run: ./gradlew publish

That’s all you can find the source code here.

Creating Private Maven/Gradle Repository

Fırat Küçük — Sun, 31 May 2020 15:03:47 +0000

In some cases, you need a private library, maybe because of your company's privacy policy or your personal preferences. For instance, you have multiple projects and you need some common DTOs or common utilities. It might be a good choice to separate them and make it a common jar package for those.

You need to install Maven and JDK for this tutorial. If you don't have Maven or JDK installed. Maybe you can try sdkman. In general, I prefer using maven wrapper in my projects.

Deployment to Private Maven Repository

I am going to use Repsy for this purpose. It's easy to use a Cloud Maven repository. So let's create a common library first. You can create a maven project using your favorite IDE or editor.

Your initial project structure will be like this:

- src
  - main
    - java
    - resources
  - test
- pom.xml

First, let's create a package that represents our company TLD or our personal preference. I am gonna use my personal GitHub TLD. You can use yours or something else. After creating the package directory structure will be something like this:

- src
  - main
    - java
      - com
        - github
          - firatkucuk
            - hellomavenlib
    - resources
  - test
- pom.xml

Ok, now we can create our super complicated library class.

package com.github.firatkucuk.hellomavenlib;

public class Hello {

    private Hello() {
    }

    public static String sayHello(final String name) {
        return "Hello " + name;
    }
}

For the final stage, we need to modify our pom.xml. A definitive section for our library artifact is needed. It will be something like that.

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

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>com.github.firatkucuk</groupId>
  <artifactId>hello-maven-lib</artifactId>
  <version>1.0</version>
  <packaging>jar</packaging>

  <properties>
    <maven.compiler.source>11</maven.compiler.source>
    <maven.compiler.target>11</maven.compiler.target>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
  </properties>

  <!-- The other stuff will come here -->
</project>

To proceed to the next section, we need to create an account at Repsy. You can directly go to the register section. Pick a username and password that's all. Now we can use our maven repository. Repsy automatically creates a private Maven repository called default for us.

It might be a good practice to not store the Maven repository password in our Maven library pom.xml file. So let's create a settings file or modify the existing one. In your operating system, there should be .m2 folder in your home directory. If you haven't used Maven yet you might need to create one. For Linux/Mac users ~/.m2 directory. If it doesn't exist. You can create one via mkdir ~/.m2.

Let's create/modify ~/.m2/settings.xml file.

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
   http://maven.apache.org/xsd/settings-1.0.0.xsd">

   <servers>
     <server>
       <id>repsy</id>
       <username>YOUR_REPSY_USERNAME</username>
       <password>YOUR_REPSY_PASSWORD</password>
     </server>
   </servers>
 </settings>

Please modify your username and password sections. Let's put the deployment repository definition section into our pom.xml file.

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

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>com.github.firatkucuk</groupId>
  <artifactId>hello-maven-lib</artifactId>
  <version>1.0</version>
  <packaging>jar</packaging>

  <properties>
    <maven.compiler.source>11</maven.compiler.source>
    <maven.compiler.target>11</maven.compiler.target>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
  </properties>

  <distributionManagement>
    <repository>
      <id>repsy</id>
      <name>My Private Maven Repositoty on Repsy</name>
      <url>https://repo.repsy.io/mvn/YOUR_REPSY_USERNAME/default</url>
    </repository>
  </distributionManagement>
</project>

Please change your repository URL. It will be something like: https://repo.repsy.io/mvn/YOUR_REPSY_USERNAME/default. Now we can deploy our very first private repo library.

mvn compile deploy

That's all for the deployment part. If you want to access the source code for this library. You can access it from here.

Using Private Maven Repository

Let's create another project with a proper TLD structure.

- src
  - main
    - java
      - com
        - github
          - firatkucuk
            - hellomavenapp
    - resources
  - test
- pom.xml

and modify our pom.xml with proper remote repo settings and dependency settings.

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

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>com.github.firatkucuk</groupId>
  <artifactId>hello-maven-app</artifactId>
  <version>1.0</version>

  <properties>
    <maven.compiler.source>11</maven.compiler.source>
    <maven.compiler.target>11</maven.compiler.target>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
  </properties>

  <repositories>
    <repository>
      <id>repsy</id>
      <name>My Private Maven Repositoty on Repsy</name>
      <url>https://repo.repsy.io/mvn/firat/default</url>
    </repository>
  </repositories>

  <dependencies>
    <dependency>
      <groupId>com.github.firatkucuk</groupId>
      <artifactId>hello-maven-lib</artifactId>
      <version>1.0</version>
    </dependency>
  </dependencies>
</project>

Please do not forget to change your repository URL.

Let's create a Java class that uses our hello library.

package com.github.firatkucuk.hellomavenapp;

import com.github.firatkucuk.hellomavenlib.Hello;

public class Main {

    public static void main(final String[] args) {

        if (args.length > 0) {
            Hello.sayHello(args[0]);
        } else {
            Hello.sayHello("maven");
        }
    }
}

Let's compile our project.

mvn compile

That's all our sample application uses a remote private repository. If you're not using a framework like Spring you need to take a look at some fatjar solutions or if you're gonna deploy to Java Application server. You can change your packaging to war and can execute mvn compile package. I am going to copy dependencies and execute with that dependency.

Let's run the Maven dependency plug-in:

mvn compile dependency:copy-dependencies

let's run with the classpath definition

java -cp target/dependency/hello-maven-lib-1.0.jar:target/classes com.github.firatkucuk.hellomavenapp.Main "World!"

You can reach the source code from here

Kotlin Native Experiment

Fırat Küçük — Wed, 11 Dec 2019 21:33:23 +0000

I don't know why but I really love simple executable programs. Maybe it's just because I am dealing with Java stuff and missing fast and small applications. Executables without any runtime dependencies. That's why Go and Rust languages blink. No offense but I don't like Go's exception handling and Rust syntax is pretty weird. More human-readable languages like TypeScript and Kotlin seems better. Thanks to LLVM and GraalVM, our programming languages and applications are faster than ever.

Microservices age triggers the micro-sized and ultrafast applications and frameworks. Micronaut, Quarkus, Helidon, and Spark some of the great examples of that era. Thanks God, all those fancy toys and spring boot supports Kotlin.

Kotlin is one of my favorite programming languages. To be honest, at the beginning I refused to accept the variable definition syntax.

val myVariable: String = "hello"

I find classical Java-style more convenient. For instance when you write CarFactory IDE auto-completes carFactory variable name in Java-like programming languages.

CarFactory carFactory = new CarFactory();

But despite its unusual variable declaration, there're plenty of cool things in Kotlin. Immutable data types, data classes, by default final classes, co-routines, and many more. I am determined and focused on the journey of Kotlin. So here we're. Gonna try a Kotlin native application.

Currently, most of the Kotlin native examples are based on IntelliJ IDEA. Well... I didn't like this idea. It should be as simple as possible. So I tried to download a native compiler. But currently, it's really difficult to obtain one. Either you should compile or you should use IntelliJ IDEA.

So I found out the executables URL. You can download them for 1.3.61 version.

After downloading and extracting the content you can compile via command-line. Try to save this hello world program as hello.kt

fun hello(): String = "Hello, Kotlin/Native!"

fun main() {
    println(hello().toLowerCase())
}

and then let's compile it.


./kotlinc -o hello hello.kt

Kotlin compiler is gonna compile needed dependencies. After compilation completed we can try our executable.

./hello.kexe

It's 387KB a little bit bigger than a standard C/C++ application. But it's Ok. :) It's not a statically compiled executable. The target is dynamically linked.