Forem: EronAlves1996

Implementing the Skeletal Implementation design pattern

EronAlves1996 — Tue, 08 Jul 2025 17:17:23 +0000

Let's explore the java standart library a little bit?

The java Collections framework is used by java developers in a daily baisis, mostly the List interface, which is preferable to use instead of Array.

But, the main point here is that e use List and Maps often.

We have a good number of good implementations already in Java Standart Library (mostly in java.util package), and we can consume other implementations from third party libraries, like Apache Commons and Google Guava.

If needed, we can create our own implementation of these interfaces.

But, it can appear difficult to create our own implementation suitable to our needs, because these interfaces have a good number of methods to implement. Just a small portion of the methods have default implementation. That way, we have many methods that requires the user to implement them.

On List interface, I see 25 methods to implement, just on sight:

But, to the rescue, these interfaces have some pre-implementations that make the user life easier, and you struggle less to implement.

These pre-implementations are variants of Skeleton Implementation Design Pattern. How it works?

Suppose I created an interface that suggests some complexity. The DataProcessor interface below have 9 methods, which is a considerable number to implement, and the main purpose of it is to apply transformation into data through many ways, using a fixed class.

Interfaces are public, and generally we gonna use this interface as parameters in methods or fields in another classes. If someone needs to implement this interface for a data pipeline, will be somewhat difficult to implement all these methods.

Let's make it easier for our users to use this interface by including a skeleton which implementations for some methods.

To make it, we gonna:

Make an abstract class
Name it AbstractThing
Implement some methods with a default implementation

In the process, we need to think which methods should be required, and which methods the user can achieve his task without ever think about to modify the implementation.

That way, the user have a starting point to make the implementation easier. At the end, now the user have to implement only 4 methods if he uses the AbstractDataProcessor for the task:

The Collection Frameworks interfaces follows the same logic. We have AbstractList and AbstractMap as starting points for implementing my own implementations of these collections.

For AbstractList, is required to implement only two methods:

Fr AbstractMap, is more simple, requiring you to implement only one method:

We should note that, the user isn't required to implement all methods, but it doesn't means that he can't implement it. If needed, he can override the other methods that exists in the type hierarchy.

Uma reflexão sobre minha carreira

EronAlves1996 — Thu, 03 Jul 2025 02:31:21 +0000

Esse é um dos poucos posts que vou escrever em português mesmo, e explico isso no decorrer desse texto.

Recentemente eu fiz alguns posts um pouco relacionados a minha carreira no X.

Bom, este post causou um pouco de burburinho, dúvidas e questionamentos de algumas pessoas. Acho que um pouco mais de contexto sobre minha trajetória, como cheguei até aqui, o material que estudei e o meu ponto atual se fazem válidas para as pessoas terem uma ideia dos desafios de como é ser um desenvolvedor em uma stack considerada infâme dentro da bolha dev, mas que comprovadamente paga boletos.

Onde eu estou hoje

Hoje eu sou um desenvolvedor que me considero normal, não melhor do que ninguém, mas a empresa que me emprega me considera como sênior, atuando com Java na sua versão 7 e JSF. Além disso, atuo em outros projetos. Um desses projetos é fullstack Laravel e Vue 2, e o outro projeto como frontend React.

Fatores de empregabilidade

O estado da minha carreira atual eu devo principalmente ao networking. Mas tem 3 fatores que me fizeram chegar onde estou hoje e que, acredito, são fundamentais para qualquer trabalho que você conseguir sendo proletariado, assalariado. Se você é empreendedor, o jogo muda, mas o júnior que está começando hoje vê muito mais dificuldade no mercado, onde ele busca trabalhar para um terceiro. Nesse caso, os fatores que acredito serem fundamentais são:

1. Networking

Então, isso é tão batido na tecla por todo mundo, mas se você for trabalhar com e para outra pessoa, é fundamental que você conheça e tenha bons relacionamentos com outras pessoas e que essas pessoas te conheçam (te conheçam mesmo).

Quem começa hoje consegue isso participando de uma comunidade. Eu comecei participando da antiga comunidade do Sibelius Seraphini no Discord, aprendendo com outras pessoas, discutindo temas técnicos e apresentando algumas coisas que havia construído por lá. Isso culminou em um círculo de amizade muito forte com algumas pessoas que são minhas amigas até hoje.

Apesar disso, foi fora desse círculo de amizade que consegui meu primeiro trabalho, porém a oportunidade surgiu a partir da participação nessa primeira comunidade. E também falando algumas merdas técnicas no X.

2. Proof of Knowledge

Esse aqui a expressão veio da minha cabeça. Normalmente a galera se refere a esse como Proof of Work, mas se resume a uma única coisa: provar que sabe fazer.

Como que faço isso?

O mercado sempre vai valorizar essa prova através de experiência profissional no currículo, mas para quem busca o primeiro emprego sempre se depara com o questionamento: como vou conseguir experiência se ninguém me dá a oportunidade para conseguir experiência?

Acho que uma das grandes realizações dentro do círculo de Desenvolvimento Web foi mudar essa perspectiva. Não olhar pelo viés da experiência e sim da prova que sabe fazer.

Então é ir a luta: o github é de graça, tem muitos lugares para conseguir um servidorzinho de graça ou pagando um preço módico. Então prove que sabe fazer: faça um crud, faça um pequeno sistema, uma api, um frontend que não seja batido. Peça ideias de projetos para o chat gpt e implemente.

Viu algo interessante no curso e quer aplicar em algo que chegue mais próximo da realidade? Por que não descrever o que você aprendeu para o chat gpt e pedir alguns exercícios ou ideias que se aproximem de algo que seja real?

Mas também, não podemos pensar que um projetinho é simples demais de ser implementado e mostrado por aí. Não tenha vergonha de projetos que possam parecer simples e idiotas.

Essas provas fizeram muita diferença para mim quando consegui meu primeiro trabalho dentro da área, porque a pessoa que me contratou sabia o que eu conseguia fazer e viu potencial.

3. Aderir ao processo de busca de emprego

Não tenho nem muito o que comentar aqui.

Tem muitos perfis de RH dentro do X e do Linkedin que orientam e muito bem como formatar o currículo, como arrumar sua apresentação no linkedin para ser notado. E além disso, o processo de busca de emprego tem que ser fervoroso. Você tem que jogar o jogo! Ele está formado e não vai ser reclamando da Gupy que isso irá mudar.

Quem consegue emprego não é o camarada reclamando da Gupy todo santo dia. É quem vai atrás!

E sobre isso, a ideia é que podem ter poucas vagas, e muitas pessoas aplicando, mas isso vira um jogo de números. O fato é que você só precisa de uma vaga. Então faça a vaga acontecer.

Na época de procura do meu primeiro trabalho, eu chegava a enviar de 50 a 100 currículos todos os dias durante a semana. Isso também é jogar o jogo. Mas, é um dos pontos que me ajudou a escapar de uma empresa que virou para o presencial em menos de um mês para uma oportunidade bem melhor.

Stacks, mercados e com o que você vai trabalhar

A recomendação primordial para quem está estudando e dando os primeiros passos é focar em uma só linguagem/stack no começo e aprender os fundamentos com ela.

Quando a gente fala dos fundamentos de lógica de programação e engenharia de software, você aprender mais de uma linguagem ao mesmo tempo não traz muito benefício. Se você aprende os fundamentos em uma linguagem, daí mudar fica muito mais fácil depois, pois você já sabe os conceitos e só vai mudar de sintaxe, e toda linguagem mainstream hoje possui basicamente os mesmos elementos, que seriam:

Elementos procedurais fundamentais:
- if
- else
- for
- while
- funções/procedimentos
Elementos de programação funcional:
- Variáveis imutáveis (sic)
- Funções de primeira classe
- Operações sobre coleções
Elementos de programação orientada a objetos:
- Estruturas de aglutinação de lógica/dados
- Encapsulamento
- Binding de métodos
- Despacho dinâmico em alguma forma

Então se você aprende isso em uma linguagem, a próxima linguagem em si ficaria mais simples de aprender, pois seria somente aprender uma sintaxe diferente para expressar os mesmos conceitos. É basicamente assim que atuo em 3 projetos onde a stack é diferente entre elas.

Quando falamos de experiência com uma linguagem de programação, a coisa muda de figura um pouco, pois não é somente na sintaxe e nos elementos fundamentais que se exige conhecimento, mas também:

Em seus idiomatismos, que são as formas mais comuns que os desenvolvedores usam para resolver problemas e expressar ideias
Em seu ecossistema, que bibliotecas se utilizam normalmente

Então, ter o foco voltado para se especializar em uma linguagem de início é importante.

Agora, quanto à que linguagem estudar, eu recomendo estudar a que mais te interessar no início, mas a pesquisa se faz importante, pois uma linguagem é mais conhecida pelos seus legados.

Por que Java recebe tanto hate assim, sendo que estamos no Java 24, temos virtual threads, records, lambdas e modos mais expressivos de fazer as coisas? Justamente por conta dos legados, que na sua maioria são Java 7/8, possui JSF em seu core, que normalmente roda dentro de containers de aplicação, e jeitos mais "arcaicos" de se fazer as coisas.

Ter ciência do legado da linguagem é essencial, pois esbarrar em um desses legados é a coisa mais comum. E aí está a fórmula do "emprego infinito" em Java (basicamente no boom do Java não tinha nada melhor em enterprise para ser usado, mas dá para explorar essa história melhor em outros posts).

Devo citar aqui também sobre Javascript/Typescript pois me perguntaram sobre isso também no post. A stack define também com o que você vai atuar ou não, e como o legado dessa linguagem vem da facilitação do contexto do desenvolvedor conseguir atuar de maneira fullstack, então grande parte das vezes você irá atuar ou como frontend ou como fullstack. Eu tive uma breve experiência sendo somente backend Javascript/Typescript com uma mescla de serviços em javascript puro e typescript, todos hospedados na AWS, mas como o contexto de negócio era de uma migração de serviços Java para Javascript, então acabei mexendo também com Java nessa experiência.

Vagas para gringa

Este é um ponto do qual ainda não tive experiência, mas tenho alguns pontos sobre.

Hoje meu posicionamento é escrever blog posts somente em inglês por motivos de facilitar meu posicionamento para futuras vagas gringas e também para explorar tópicos que acho serem interessantes em uma linguagem que não é minha nativa. Então cumpre um propósito duplo aqui: aprendizado e proof of knowledge.

Para as vagas gringas, o que mais vejo é recrutamento em stacks em Node, Go e Ruby, principalmente em startups. Então o trabalho corporativo fica um pouco de lado. Eu acredito que Java, junto com PHP e C#, são muito, muito fortes no Brasil, mas para a gringa, muitas big techs usam Java, mas a porta de entrada para essas empresas é pequena.

Então para o Brasileiro desenvolvedor médio, a stack de startup seria o melhor começo para tentar vagas no exterior.

Concluindo

Eu espero que essa reflexão possa ajudar algum dev ou aspirante a dev que esteja perdido e deixar uma mensagem: o começo realmente é mais difícil e pode ter ficado mais difícil com a explosão das IA's, mas os fundamentos continuam os mesmos.

Corre atrás que você consegue o seu!

Deep drive into driver load mechanism of JDBC

EronAlves1996 — Fri, 06 Jun 2025 02:38:21 +0000

JDBC is the classic API in Java for database connectivity (it stands for Java Database Connectivity api), and every good database driver follow the standart.

It encompasses many years of history and evolution, that today, the driver detection and loading is almost magical, because everything happens behind the scenes.

Now, I want to address how this magical thing works, and how you can mimic the mechanism to build good plugin frameworks with it.

The classloading process

First of all, we need to understand that the JVM load classes lazily.

It means that, first, the JVM bootstrap some basic classes, using the bootstrap classloader, and then, execute the main method of the application. Let's remember that every application needs to have a main method, in any language. Maybe you don't see a method named main, but it exists, even behind the scenes.

Well, JVM only can read bytecode instruction, so the Java Compiler will enforce some type and rule checking and procceed to transform all your source .java files into .class files.

The .class files are similar to .exes or .elfs, even .sos or .dlls. They contain low level instructions that tells the target machine what it will execute, and the machine will read and execute every instruction almost sequentially (it's not strictly sequentially, because of processing unit semantics, like instruction reordering, branch prediction, memory layout reordering, etc. They are optimizations, and JVM has a lot of them).

So, remember that JVM read classes lazily. It is more efficient to do that because, lets supose the JVM read all of them eagerly. An average application have, almost, 100k classes. I am taking the fact that, not only the application code is loaded, but library (and standart library too) code is loaded. So, when the JVM find an instruction that deals with an unknown class, it asks the Application Classloader to load the class, that way it can knows how the object is, and which code it should execute.

Now that the JVM load the class the first time, it keeps them in memory.

Execution blocks

But, the life is not that simple.
Classes are the only top level construct allowed in Java, so in JVM. As an example, Scala generates class files for top level functions because JVM don't supports no-class constructs (your processor don't supports structs, so, they only purpose it's to be a shape for how the data will be disposed in some memory segment).

The following scala code:

@main
def FrenchDate: Unit =
  val now = LocalDate.now
  val df = getFormatter(Locale.FRANCE)
  println(df.format(now))

def getFormatter(locale: Locale): DateTimeFormatter =
  DateTimeFormatter.ofLocalizedDate(FormatStyle.LONG).withLocale(locale)

Will generate the following class with main method:

public final class frenchDate {
   public static void main(final String[] args) {
      try {
         .MODULE$.frenchDate();
      } catch (ParseError var2) {
         scala.util.CommandLineParser..MODULE$.showError(var2);
      }

   }
}

That references the following class, with our methods:

public final class FrenchDate$package$ implements Serializable {
   public static final FrenchDate$package$ MODULE$ = new FrenchDate$package$();

   private FrenchDate$package$() {
   }

   private Object writeReplace() {
      return new ModuleSerializationProxy(FrenchDate$package$.class);
   }

   public void frenchDate() {
      LocalDate now = LocalDate.now();
      DateTimeFormatter df = this.getFormatter(Locale.FRANCE);
      .MODULE$.println(df.format(now));
   }

   public DateTimeFormatter getFormatter(final Locale locale) {
      return DateTimeFormatter.ofLocalizedDate(FormatStyle.LONG).withLocale(locale);
   }
}

And that said, we have a third class that will represent the Scala package (that haves different semantic than Java packages), but it's not the focus here.

Since the JVM only supports classes as top level construct, what if I need to run some code when a class is loaded? Or when an object is instatiated.

Well, that are some initialization blocks in Java classes that provide me that functionality.

First, we have static initializations blocks:

static {
 // your code here
}

This block is executed once, when the class is loaded by the JVM.

The next is an initialization block:

class Smartphone {

  {
    // this is a initialization block
  }

  Smartphone() {
    // no-args constructor
  }
}

An initialization block is executed when the object is instantiated, before the constructor.

After that we have the constructor, and the methods. Methods are executed everytime they are called by another code. Static methods follows this logic too. Constructors are normal methods, but they don't have any return value, because the new object reference is implicitly return by them. But, they allocate some memory to accomodate the object in it.

Driver Manager

With the basic knowledge in our hands, let's start by investigating the initial class of JDBC: the DriverManager.

Everything starts by getting the connection from DriverManager where we pass the parameters to it as properties optionally:

val url = "jdbc:derby://localhost:1527/jaLiDb"

def getConnection: Connection =
  DriverManager.getConnection(url)

However, we should note that we didn't specificate any driver for it. The method getConnection have a documentation that states:

Attempts to establish a connection to the given database URL. The DriverManager attempts to select an appropriate driver from the set of registered JDBC drivers.

So, we should know that, for JDBC understand and be able to select some driver, the driver should be registered to JDBC in the application.

The next question is, how is the process of driver register?
Let's take a look into the DriverManager class, but we gonna look closely into its static initialization block:

   static {
        loadInitialDrivers();
        println("JDBC DriverManager initialized");
    }

So, when DriverManager is first referenced in the application, it gonna execute this code. The second line is trivial, and will only display the message on console.

But the first method is very interesting.

Loading the drivers

Ok, let's go through the method, but I'll advice you: we gonna take a ride into history.

This method is very short, and really easy to understand.

First of all, how the list of registered drivers is maded of? First by getting a system property:

     String drivers;
        try {
            drivers = AccessController.doPrivileged(new PrivilegedAction<String>() {
                public String run() {
                    return System.getProperty("jdbc.drivers");
                }
            });
        } catch (Exception ex) {
            drivers = null;
        }

So, when these lines is runned, the code inside the Runnable will run with privileged permissions. Let's remember the so forgeted SecurityManager that manages the permissions of what the code can or cannot access, create, modify, etc.

What these lines do is simple: recover what is referenced by the -Djdbc.drivers method.

This a very legacy approach, when no magic was invented yet, the way a user have to register the driver was by, either, loading explicitly the class:

Class.forName("oracle.jdbc.driver.OracleDriver");

Or passing as a system property:

java -Djdbc.drivers=oracle.jdbc.driver.OracleDriver

So, when it catch the drivers and it have any valid classname, it makes the same process we already do manually:

 println("DriverManager.initialize: jdbc.drivers = " + drivers);

        if (drivers == null || drivers.equals("")) {
            return;
        }
        String[] driversList = drivers.split(":");
        println("number of Drivers:" + driversList.length);
        for (String aDriver : driversList) {
            try {
                println("DriverManager.Initialize: loading " + aDriver);
                Class.forName(aDriver, true,
                        ClassLoader.getSystemClassLoader());
            } catch (Exception ex) {
                println("DriverManager.Initialize: load failed: " + ex);
            }
        }

We skipped some lines of code, but don't worry, it only to show the first legacy primitive mechanism to load a driver.

Service Provider Interface

Well, the other approach is by loading the drivers using the Service Provider Interface (SPI).

The SPI provides some hack to load classes that are declared as a resource file that implements some type of interface. The fact is, every JDCB Driver implements the Driver interface. So it's very simple to make this using SPI.

In the same DriverManager.loadInitialDrivers method, we skipped the following lines of code:

 AccessController.doPrivileged(new PrivilegedAction<Void>() {
            public Void run() {

                ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);
                Iterator<Driver> driversIterator = loadedDrivers.iterator();

                /* Load these drivers, so that they can be instantiated.
                 * It may be the case that the driver class may not be there
                 * i.e. there may be a packaged driver with the service class
                 * as implementation of java.sql.Driver but the actual class
                 * may be missing. In that case a java.util.ServiceConfigurationError
                 * will be thrown at runtime by the VM trying to locate
                 * and load the service.
                 *
                 * Adding a try catch block to catch those runtime errors
                 * if driver not available in classpath but it's
                 * packaged as service and that service is there in classpath.
                 */
                try{
                    while(driversIterator.hasNext()) {
                        driversIterator.next();
                    }
                } catch(Throwable t) {
                // Do nothing
                }
                return null;
            }
        });

Look how it's very simple. It loads the classes using the SPI, and then, iterate over them to allow it be catchable by the classloader. When the classloader see the references, it gonna load the class to register the driver, and that is the true magic for loading JDBC drivers by only putting them on classpath.

Driver registration: a two-way process

So, we already see how the drivers are loaded automatically and manually, but the register process are unseen in this context. So, they are only needed to be loaded and that's it? Not that really.

The first part of driver registration is load the Driver implementation on classpath. The second part happens on the side of Driver implementation.

Let's take as an example the PostgreSQL Driver implementation.

In every Driver, is supposed to have a static initialization block too, that will run when the class is loaded:

 static {
    try {
      // moved the registerDriver from the constructor to here
      // because some clients call the driver themselves (I know, as
      // my early jdbc work did - and that was based on other examples).
      // Placing it here, means that the driver is registered once only.
      register();
    } catch (SQLException e) {
      throw new ExceptionInInitializerError(e);
    }
  }

As the comment make us know, some drivers can make a choice to put the registering code on the driver constructor. But, what we are looking for is the method register:

  public static void register() throws SQLException {
    if (isRegistered()) {
      throw new IllegalStateException(
          "Driver is already registered. It can only be registered once.");
    }
    Driver registeredDriver = new Driver();
    DriverManager.registerDriver(registeredDriver);
    Driver.registeredDriver = registeredDriver;
  }

This method will make the following things:

Check if the driver is already registered, to make guarantees that it will registered only once;
Instantiate the driver;
Calls DriverManager to register the driver

And now, the only thing DriverManager will do is put the driver on a list. And now the driver is fully registered:


 public static synchronized void registerDriver(java.sql.Driver driver,
            DriverAction da)
        throws SQLException {

        /* Register the driver if it has not already been added to our list */
        if(driver != null) {
            registeredDrivers.addIfAbsent(new DriverInfo(driver, da));
        } else {
            // This is for compatibility with the original DriverManager
            throw new NullPointerException();
        }

        println("registerDriver: " + driver);

    }

Deep dive into Java Streams implementation - Creating Streams

EronAlves1996 — Tue, 03 Jun 2025 03:43:40 +0000

From Java 8, Java Streams and Lambdas was a great addition to Java language, but from there to today, I didn't find any good article or content about how Streams specifically are implemented, until today.

We gonna read and explore all the infrastructure code that make Java streams possible.

For all this study, we gonna use JDK 21, which is open source and you can find all the source here

The basic stream example

Stream.of(1, 2, 3, 4)
  .forEach(System.out::println);

The first snippet demonstrates the simplicity of declaring some stream and then, invoking the forEach method on it. This method will apply a side effect on every element of this stream. First, if you are a bit curious about the implementation of Stream, the first thing you gonna do is jump to the implementation of it, but you found that in fact, Stream is an interface:

public interface Stream<T> extends BaseStream<T, Stream<T>> {
// ...
}

It happens because the original intent of the library authors is to hide all the implementation details, leaving us only with some methods and no worry about how it is implemented. However, we can explore all the implementations with the help of our IDE using the find implementations tool.

It reveals us that we have 15 implementations, besides anonymous, package-private, static and abstract classes:

To study the inner workings of code, I don't like to make a very systematical study, by seeing the topology of it's classes and chain. I like to go where the execution path goes, so let's go with it.

Creating streams

As we know, we have some ways to make streams, but the direct way is by using the static methods, like of, empty, iterate, generate, and by converting collections and arrays into a stream.

By looking at the Stream class static methods, we have the following ways to build a stream:

Builder

We can make a builder from a stream, by invoking Stream.builder(). With this builder, we can add elements by invoking the methods accept or add:

private static Stream<String> buildStreamBuilder() {
  Builder<String> builder = Stream.builder();
  builder.accept("José");
  return builder
      .add("Maria")
      .add("Nonato")
      .build();
}

The builder method returns a Stream.Builder implementation, that is another interface that implements the Consumer interface. The implementation is the class Streams.StreamBuilderImpl

    public static<T> Builder<T> builder() {
        return new Streams.StreamBuilderImpl<>();
    }

The Streams class is some aggregation of private and package-protected classes and utilities that are used for creating and manipulating streams.

When using a builder, the preferred way to add elements to it is by using a fluent interface. This mechanism is provided by the method add, and after that, we invoke the build method.

The add method will invoke the accept method:

        public Stream.Builder<T> add(T t) {
            accept(t);
            return this;
        }

The accept method will do the following things:

Keep track of the first element added to the stream
Keep track of the number of elements of the stream
Add the elements, when we have 2 or more elements, to a SpinedBuffer

        public void accept(T t) {
            if (count == 0) {
                first = t;
                count++;
            }
            else if (count > 0) {
                if (buffer == null) {
                    buffer = new SpinedBuffer<>();
                    buffer.accept(first);
                    count++;
                }

                buffer.accept(t);
            }
            else {
                throw new IllegalStateException();
            }
        }

A SpinedBuffer is an immutable, ordered collection of items, where goes through two phases:

A building phase, where the items where added, but not removed
A traversal phase, where the buffer cannot be modified, but the items can be traversed and accessed

When we are done with the Stream.Builder, we can call the build method on it, that will finally instatiate our stream, using the StreamSupport.stream method, that always accepts a Spliterator and a flag that indicates if the stream to be built is parallel or not.

What happens in fact is, our StreamBuilderImpl is a Spliterator too, because it extends the AbstractStreamBuilderImpl, which implements Spliterator.

    private abstract static class AbstractStreamBuilderImpl<T, S extends Spliterator<T>> implements Spliterator<T> {
// ...
}

This abstract class implements a very nice skeleton implementation pattern on top of Spliterator.

The StreamBuilderImpl will be used as spliterator only if the stream have 0 or 1 elements. If it haves 2 or more, then the build method will use the spliterator from SpinedBuffer.

        public Stream<T> build() {
            int c = count;
            if (c >= 0) {
                // Switch count to negative value signalling the builder is built
                count = -count - 1;
                // Use this spliterator if 0 or 1 elements, otherwise use
                // the spliterator of the spined buffer
                return (c < 2) ? StreamSupport.stream(this, false) : StreamSupport.stream(buffer.spliterator(), false);
            }

            throw new IllegalStateException();
        }

Empty Stream

A Stream can be created too as an empty stream. It's meant to be used as substitution to null. This stream is created from an empty spliterator:

    public static<T> Stream<T> empty() {
        return StreamSupport.stream(Spliterators.<T>emptySpliterator(), false);
    }

Single Element Stream

We can use the static method Stream.of to create a stream consisting of a single element. This stream is created with the StreamBuilderImpl, which is the foundation for a StreamBuilder.

However, we already see that the StreamBuilderImpl is a spliterator too. So, the instance is passed directly to StreamSupport.stream.

    public static<T> Stream<T> of(T t) {
        return StreamSupport.stream(new Streams.StreamBuilderImpl<>(t), false);
    }

Single Nullable Element Stream

This is the Single Element Stream with null safety guarantee. It only checks if the element is null. If it is, returns an empty stream, otherwise, return a Single Element Stream:

    public static<T> Stream<T> ofNullable(T t) {
        return t == null ? Stream.empty()
                         : StreamSupport.stream(new Streams.StreamBuilderImpl<>(t), false);
    }

From array

Streams can be created from arrays. There are two ways to do this:

Using the Arrays.stream method;
Using the Stream.of method passing an array (or the arguments as varargs).

The Stream.of method will call the Arrays.stream method. So, for all effects, they take the same path.

    public static<T> Stream<T> of(T... values) {
        return Arrays.stream(values);
    }

When we open the Arrays class, we see that the stream creation process follows a process that looks like C++ iterators:

    public static <T> Stream<T> stream(T[] array, int startInclusive, int endExclusive) {
        return StreamSupport.stream(spliterator(array, startInclusive, endExclusive), false);
    }

The stream is created by specifying where it should start and where it should end. The process is made directly in the spliterator method, and we can repeat this process ourselves, because the method is public.

So, let's say we want to process only the two middle elements of the array, and it haves 10 items. We can made this by creating our own spliterator and passing it to StreamSupport.stream method.

  private static Stream<String> iteratePartially() {
    var strings = new String[] { "a", "b", "c", "d", "e", "f", "g", "h", "i" };
    return StreamSupport.stream(Arrays.spliterator(strings, 3, 6), false);
  }

Note that the ranges are start incluse and end exclusive, so, the only elements that are processed in this stream are "d", "e" and "f".

Stream from computations

Streams are lazy by design. So, some stream can be generated by a computation, where we have two methods that creates streams for us.

`iterate`

The Stream.iterate method produce a stream by repeatedly call a function using some value as argument, where the value is the initial value or the previous result.

If we see how the spliterator is built, we found that the stream generate is potentially infinite, because it only returns true on the method tryAdvance.

Spoiler: the tryAdvance method on a spliterator indicates to the stream that it can consume more items from the source. Following this logic, the stream only ends if the spliterator return false when the tryAdvance method is called.

    public static<T> Stream<T> iterate(final T seed, final UnaryOperator<T> f) {
        Objects.requireNonNull(f);
        Spliterator<T> spliterator = new Spliterators.AbstractSpliterator<>(Long.MAX_VALUE,
               Spliterator.ORDERED | Spliterator.IMMUTABLE) {
            T prev;
            boolean started;

            @Override
            public boolean tryAdvance(Consumer<? super T> action) {
                Objects.requireNonNull(action);
                T t;
                if (started)
                    t = f.apply(prev);
                else {
                    t = seed;
                    started = true;
                }
                action.accept(prev = t);
                return true;
            }
        };
        return StreamSupport.stream(spliterator, false);
    }

The Stream.iterate method have an overload. In this variation we have more control to signal to the stream that the computation is over, by passing a Predicate as second argument, indicating if the iteration has more items or not. This logic is passed to the spliterator:

public static<T> Stream<T> iterate(T seed, Predicate<? super T> hasNext, UnaryOperator<T> next) {
        Objects.requireNonNull(next);
        Objects.requireNonNull(hasNext);
        Spliterator<T> spliterator = new Spliterators.AbstractSpliterator<>(Long.MAX_VALUE,
               Spliterator.ORDERED | Spliterator.IMMUTABLE) {
            T prev;
            boolean started, finished;

            @Override
            public boolean tryAdvance(Consumer<? super T> action) {
                Objects.requireNonNull(action);
                if (finished)
                    return false;
                T t;
                if (started)
                    t = next.apply(prev);
                else {
                    t = seed;
                    started = true;
                }
                if (!hasNext.test(t)) {
                    prev = null;
                    finished = true;
                    return false;
                }
                action.accept(prev = t);
                return true;
            }

            @Override
            public void forEachRemaining(Consumer<? super T> action) {
                Objects.requireNonNull(action);
                if (finished)
                    return;
                finished = true;
                T t = started ? next.apply(prev) : seed;
                prev = null;
                while (hasNext.test(t)) {
                    action.accept(t);
                    t = next.apply(t);
                }
            }
        };
        return StreamSupport.stream(spliterator, false);
    }

`generate`

The Stream.generate method is very similar to iterate method, but in this case, this method will accept a Supplier and not an Operator. That way, we can supply a single or random values, where the stream we be created by the logic provided in the Supplier.

Looking at the code, and the name of the namespace where the spliterator used is located, we can suppose that the stream created is potentially infinite:

public static<T> Stream<T> generate(Supplier<? extends T> s) {
        Objects.requireNonNull(s);
        return StreamSupport.stream(
                new StreamSpliterators.InfiniteSupplyingSpliterator.OfRef<>(Long.MAX_VALUE, s), false);
    }

Stream of streams

Finally, we can create a stream from two other streams, by concatenating them.

The concat method takes two stream and uses a ConcatSpliterator to supply the values from one stream and the the other stream sequentially.

By looking at the code, we can conclude that if one of them is parallel, the resulting stream will be parallel too.

public static <T> Stream<T> concat(Stream<? extends T> a, Stream<? extends T> b) {
        Objects.requireNonNull(a);
        Objects.requireNonNull(b);

        @SuppressWarnings("unchecked")
        Spliterator<T> split = new Streams.ConcatSpliterator.OfRef<>(
                (Spliterator<T>) a.spliterator(), (Spliterator<T>) b.spliterator());
        Stream<T> stream = StreamSupport.stream(split, a.isParallel() || b.isParallel());
        return stream.onClose(Streams.composedClose(a, b));
    }

We should note that streams have a method onClose. It means that they are Closeable and Autocloseable resources, where these properties always are valid for resource management, because we can create streams from I/O resources too.

What's next

This post is going too long.
I will divide this and talk about another aspects and implementation of streams in the next posts. We have to talk about:

Spliterators
StreamSupport class
Pipelines
Operation stages
Stream evaluation

And many more subjects that we'll discover in the next posts.

You don't need a Builder in Scala

EronAlves1996 — Mon, 14 Apr 2025 20:53:34 +0000

In java, due to the language inflexibility, we need a way to pass properties under a name when some object gains some complexibility.

Consider this example:

public class Computer {
    public String cpu;
    public String ram;
    public String storage;
    public String gpu;
    public String soundCard;
    public String networkCard;
    public boolean liquidCooling;
    public int numberOfFans;
    public String operatingSystem;
    public boolean overclocked;
    public String powerSupply;
    public List<String> peripherals;
    public String primaryDisplay;
    public String secondaryDisplay;
    public boolean biometricLogin;
    public boolean tpmChip;
}

This class now is raterly complex, and, by using only the constructor, it's quite difficult to instatiate the class, because method parameters in Java are positional.

Consider a possible constructor for this class:

public Computer(String cpu, String ram, String storage, String gpu, String soundCard, 
               String networkCard, boolean liquidCooling, int numberOfFans, 
               String operatingSystem, boolean overclocked, String powerSupply,
               List<String> peripherals, String primaryDisplay, String secondaryDisplay,
               boolean biometricLogin, boolean tpmChip) {
    this.cpu = cpu;
    this.ram = ram;
    this.storage = storage;
    this.gpu = gpu;
    this.soundCard = soundCard;
    this.networkCard = networkCard;
    this.liquidCooling = liquidCooling;
    this.numberOfFans = numberOfFans;
    this.operatingSystem = operatingSystem;
    this.overclocked = overclocked;
    this.powerSupply = powerSupply;
    this.peripherals = peripherals;
    this.primaryDisplay = primaryDisplay;
    this.secondaryDisplay = secondaryDisplay;
    this.biometricLogin = biometricLogin;
    this.tpmChip = tpmChip;
}

Looks so complex.
By the way, to solve the problem, we should use some sort of composition, by separating some fields into new classes to simplify the constructor, at the cost of indirection, or use the Builder pattern, by crafting your own builder or by using Lombok @Builder.

Java would be better if it haves two things:

Named parameters
Default parameters

For our luck, Scala have this two features.

We can rewrite the class in Scala, and define some default parameters, taking some advantage with a cleaner and less verbose syntax:

class Computer(
    cpu: String,
    ram: String,
    storage: String,
    gpu: String = "Integrated",
    soundCard: String = "None",
    networkCard: String = "Ethernet 10/100",
    liquidCooling: Boolean = false,
    numberOfFans: Integer = 1,
    operatingSystem: String = "Windows 10",
    overclocked: Boolean = false,
    powerSupply: String = "500W",
    peripherals: List[String] = List.empty,
    primaryDisplay: String = "1080p 60Hz",
    secondaryDisplay: Option[String] = None,
    biometricLogin: Boolean = false,
    tpmChip: Boolean = false
)

By the way, we can use this class with positional parameters or with named parameters:

val gamingPc = Computer(
    cpu = "Intel i9-12900K",
    ram = "32GB DDR5",
    storage = "1TB NVMe SSD",
    gpu = "NVIDIA RTX 4090",
    liquidCooling = true,
    overclocked = true,
    operatingSystem = "Windows 11 Pro",
    primaryDisplay = "4K 144Hz",
    secondaryDisplay = Some("1440p 165Hz"),
    tpmChip = true,
    peripherals = List("Mechanical Keyboard", "Gaming Mouse", "RGB Headse")
  )

And this is more nice and easy to instatiate.

Fundamentals of Multiprogrammed Environments

EronAlves1996 — Mon, 31 Mar 2025 04:12:37 +0000

Computers today can realize a lot of useful features and with some ilusion to be at the same time. Let's see some things we can made:

Setup a CRON to run every day at 12AM to check our emails
Navigate through internet while we maintain an Obsidian in another window with some text
See the actual date time, in real time
Listen to music

Everything at the same time. How the computer can make it all, if it haves only one processor, and that processor can execute one instruction per time?

Well, the processor can execute only one instruction per time, but it can provide some ilusion to run more than one thing and switch between tasks to advance each of them a bit. Let's deep dive into the fundamentals of this working.

Instructions

The fundamental unit of work a CPU can process is an instruction. An instruction is simply a description of a command that, when the CPU receives and read the description, performs the actual command.

CPU can receive instructions with data to perform useful actions, like adding 2 plus 2, making division calcs and many more. Instructions can be composed into a chain of instructions, on a virtual unlimited length. A set of instructions is denominated a program.

Program

The program is a set of instructions in a sequence that a CPU can perform.

Each instruction, by itself, is only an instruction, but when you chain 10, 12, and thousands of instructions together, they can compose really great applications and programs that perform so many actions.
Some programs are not autonomous, but are utilities that enables the processor to do other things that it cannot do alone, like talk to USB devices, talk to the network, etc.

Interrupts

The processor can receive some signalling from others hardware components, to allow communication between them. By receiving the signal, the processor can choose how to react to them. This signals can be conceived as events, but their technical names are Interrupts.

A lot of hardware pieces can signal the processor to request to handle some data. SSD's, keyboard inputs, GPU's can activate Interrupts, and, by the type, the processor can stop anything what it's making to handle the signal.

Let's say that the processor requested the SSD some data to be loaded, like opening a file. The SSD locate the file inside the filesystem, and then, signal the processor that the data is ready. The processor can, accordingly to the function where the interrupt handler is pointed too, ignore it initially to execute some program with higher priority, or can take this data and execute the program that initially requested the data.

Another interesting type of interrupt is called the Timer Interrupt. The motherboard is shipped with a timer chip or other hardware machinery with the function to count the time, and when it achieves some interval, it sends a signal to the CPU, activating an Interrupt. The processor, then, handles this signal accordingly to the function pointer for this interrupt type.

Traps

A trap is some instruction that signals to CPU to raise it's privilege levels. Let's say a CPU often runs in Ring 2 or 3. When he receives a trap instruction, the CPU switchs to Ring 0 or 1 to run privileged instructions.

Syscalls are great examples of trap execution. Everytime your program calls the syscall instruction (e.g. open syscall), your CPU is traped, and then switch the to more privileged levels to communicate with hardware and see with the scheduler what it should do now.

Interrupts traps CPU too. When the CPU is signaled by some hardware, it runs instructions in privileged levels to load the data from hardware or handle the signals.

Context switching

Everytime the CPU is trapped, a context switch occurs.

A context switch is an action the CPU takes to save the actual execution state.

The operating system tracks the actual execution by using the Process Control Block data structure. The PCB contains the pointer to the next instruction to be executed, some data of the program, the cpu registers, etc.

The context switch will execute some assembly instructions to save all this data to a dedicated data structure in memory to replace it with another execution state and continue from there.

I recommend you to read this excelent article to understand the ideas and implementation behind cpu context switching.

Schedulers

I think that the most fundamental component of the Operation System is the scheduler, but it needs some hardware machinery to work properly.

The main function of the scheduler is to prioritize and tell the processor which process will run next.

Let's say the processor now is running the text editor, but it needs to play the music too in the background. So, when the Timer Interrupt or some syscall (like, saving the file with write) is called, the CPU is trapped, and then, it saves the actual process context, and switch to privileged mode.

The scheduler will see that the music player process has some priority to be executed next, so it schedules them to the processor. The processor then loads the process state, and goes to normal mode to execute it.

Fundamentals of Concurrency

The Operating System

Whereas the CPU can run many instructions as a program, it's the Operating System that is the main program that enables many programs to run at the same time, by providing some important abstractions.

The Operating System provides all the glue code that make the CPU usage and programming more friendly, and lifts the weight of managing times and memory from them.

Proccess

We already see that a set of instructions can be denominated a program. Inside the Operating System, when we run some program, inside of it it's denominated a process.

A process is an abstraction where the OS provide the complete execution context, where the instructions are runned in a blackbox fashion: the program in it cannot run certain instructions and cannot talk directly to other devices. When the program needs data or an action from another device, it calls the OS, using syscalls. The syscall is a trap that make the processor raise it's privilege levels and handles the control to the OS. The OS now communicate to the other devices what the program is requesting, and, when the device returns, the OS returns to the process with the actual response.

Here, the execution context encompass everything the program needs to run: the records that points to the sequence of instructions, the virtual memory, the scheduling control,etc.

Thread

If a process is a running program, threads are lightweight processes.

When a program runs, the system creates the execution context for the new process, and the process runs inside this execution context. But the process can partition it's execution instruction sequence to have two independent sequences to run.

These instruction sequences here are called a thread, and a thread have a narrower execution context than a process. In fact, the thread have the records that points to the instruction sequence, but it's virtual memory are the same as the process.

The concurrent system

Now, we have all the pieces to describe a concurrent system. Let's say we have 2 processes and each have 2 threads.

The operating system schedules the thread P1T1. When the thread P1T1 make a syscall, the CPU is trapped and the OS takes control. When the OS make the call for the data thread P1T1 requested, it schedules the thread P2T1 and continue from there.

Thread P2T1 makes a syscall, and the OS handles it. The OS schedules the thread P2T2 and continues from there.

Here, each thread are going for the CPU time and Memory space, making it a basic concurrent system. It's concurrent because each thread here will fight for cpu time and memory comsuption here. The scheduller will schedulle one thread by time, and the others will lie in wait, awaiting for they time to advance in execution.

Domain Driven Design: the layered arch

EronAlves1996 — Thu, 06 Mar 2025 04:00:26 +0000

The layered arch, more traditionally, the 3-tier arch is a trending in the enterprise technology.

Every company you go, you gonna see, by default, this type of architecture, using mostly an anemic design, but all the nomenclatures used have origins in DDD.

We use layers here like the process of decantation: we need a good picture and level of isolation to decouple our business rules from the application needed code, and we use layering to draw clearly domain models, not in anemic fashion, to implement business rules more easily.

Follow this infographic I made to understand more:

Click here to see in full scale

I detailed the explanation more below:

Layered Arch: How it is made today

The default and classic architecture in the majority of systems comprise in a generic layered architecture with 3 layers, and a separate (or in the same system boundary) layer that represents the user interface. This user interface often is a React ou Angular app, that communicates with the backend application using an integration layer.

The user interface and the integration layer are referred as Presentation Layers, because is where the system receives input and throw out the outputs in response to requests.

The entire system uses a very poor anemic model, where we have plain data, with no objects and no related behavior, or no related functions, and a bunch of procedures that will modify these data. These procedures comprises business rules that make validation and transformation of data, and pass the data to a layer to communicate the changes, data creation or validation to a database layer, or another services:

Making our architecture more rich

We can make a set of steps to make our architecture more rich and make it communicate more intent, by updating our paradigms and how we think about it.

The first thing that I think is that, although we have guidelines in it, no system will repeat architecture schemas. By default we want to make use of the most encapsulation possible in our system, that leads to decouplement and make it more easy to change. Modularizing the system by feature, and not by infrastructure, permits us to make the most from it, and not only that, we can tie the behavior necessary to the data structures, make the system more easy to understand and modify.

We are not gonna target here only object oriented paradigms, but functional paradigms too, by not placing the functions that act on data structures too far, but colocating them next to each other and taking advantage of scoping to limit the broadness of agency of each them:

By now, we promote anemic models to domain models and make the application manage them accordingly. The communication to other features necessary to the actual domain is made more clear, and the boundaries can be better understood now.

Language design and Idiomatism

EronAlves1996 — Thu, 27 Feb 2025 03:23:44 +0000

There are really hard things to discuss in general circles. In programming communities in general is idiomatism, specially in javascript community where we have some young minds with great ideas and boldness to present these ideas to the public and language designers.

I have to admit that if a language is discussed so often, with an engaged community, it paves the way for the evolution of the language faster, but sometimes some discussions and sugestions are non-sense.

These minds normally get in touch with another languages, like LISP and Ocaml and language design theory and they think that some of these concepts should be incorporated to the main language, thinking that, by the time they are included, will hapilly accepted and used actively by the community, and I think that we should separate some variables here that should be considered when we talk about language design.

Language Philosophy

The first item is the language philosophy. Companies in general have a Mission, Vision and Values declaration for the company, that describe what the company aim to be. The philosophy of the language describes how the language is intended to be used, and often, it's not explicited.

The rare case where the language philosophy is clearly explicited is Python, which aims for simplicity and explicitness, and I think that all programmers should read it's philosophy, because has great programming guidelines in general.

The other languages philosophy can be found on it's homepage, except for the languages that don't have homepage, like javascript. But for this language, we found in history that javascript is aimed for browser scripting. Today, it's not true anymore, and the community ressignified the philosophy to aim ergonomics.

Idiomatic Use

I think this topic is highly controversial because the idiommatic use isn't any thing craved in stone, but it's the organic use of the language: how the people is using?

The idiomatic code conveys better communication of the intents and an uniform usage, that other programmers can read this same code and understand the flow. Because of that, some ideas have high probability to not be used.

I found this page of idiomatic javascript and I see that the codes and guidelines don't mirror how javascript is written today. Formatting today is given by Prettier rules, no-one (except senior dinossaurs) uses var and prefer const or let, many prefer function expressions than declarations, types are typechecked with typescript in conjunction with runtime schema validators, and now, we have React, which is the standard front-end framework and adds many rules for what we know as idiomatic code.

Language Contracts

Javascript, Golang and Java are great examples of backward compatibility contract, and this thing is very difficult, because you can't remove features, nor modify hardly them. The language should exibit the same contract for the features that exists now, so language designers should only add new features or refactor existent features without modifying it's contract.

Python don't have this, so we see the breaking changes from Python 2 to Python 3. The same happened in Scala, from Scala 2 to Scala 3.

Risks of new features

Adding new feature to a language is very difficult.

As a language designer, I should think that this feature will be useful for a good portion of the community, in a hope that it will found some adoption, and maybe be incorporated in the organic institution of language idiomatic usage.

Also, I should think: is this feature consistent with the actual philosophy of the language? Philosophies can change, just like Java that are going to a direction for Data Oriented Design, and trying to have some drive into stateless services (not good yet for it, but really good in enterprise monoliths).

I should think too: this feature will break any existing contract? Even if I don't have the backward compatibility contract, changing API's very often indicates the language is not stable, and anything unstable don't go to production.

What I learned and think about it

Languages don't evolve as fast as we like, and this is good, because stability is a very important factor for the community and all the ecosystem that evolves around the language;
Some portion of idiomatism is built around language concepts, but not everything. Java getters and setters is idiomatic, but it's not a Java language concept, but a Java beans concept and it paved it own way to the community preferences;
The majority of sugestions for a language should not have been proposed to start, because they don't take in consideration philosophy or if the feature brings benefits for a great portion of language users, increasing the probability of not being idiomatic and relegating the feature to ostracism;
Backward Compatiblity is hard.

Print each level of a Tree in a new line

EronAlves1996 — Thu, 20 Feb 2025 14:26:56 +0000

Some weeks ago, in the social networks, I scrolled over some comments and posts about a somewhat simple challenge: how to traverse a tree, in a way to print each level of it in a new line?

Let's say, we have some tree, like:

This is a classical binary tree with three levels. Accordingly with the challenge, we have to print this tree in the following way:

1
2 3
4 5 6 7

Fundamentals of Graph Traversal

Graphs? WTF?????

Wait there!

The graph is a fundamental data structure in the sense that the majority of data structures derivates from it. Graphs are structured in a way where nodes are interconected with anothers in randomic ways, and each node can be connected with another one.

Graphs can be directed or not. Directed graphs have nodes, not only connected between it, but each connection have a direction. In the graph above, the Node 1 can traverse to node 2 and 3, but Node 2 cannot traverse to Node 1, only to the Node 4. When graph is undirected, the traversal can go back and forth.

The traversal in graphs can happen in two ways: Breadth First Traversal (BFS) and Depth First Traversal (DFS).

Breadth First Traversal

Breadth First Traversal is made in a fashion where we go to each of level of traversal equally in the graph, before advancing another level.

Let's remember the former image graph. First, we start in the node 1, then we go and visit nodes 2, 3, 5 and 6, and then, finally, visit nodes 4 and 7.

When we traversal graphs, normally we can use auxiliary data structures. Let's define a graph node as following:

public class Node<T> {

  public final T value;
  public final Collection<Node<T>> children;

  public Node(T value, Collection<Node<T>> children) {
    this.value = value;
    this.children = children;
  }

}

The auxiliary data structure for breadth first traversal is the queue. Each time we visit a node, we gonna put the children at the end of queue, and while advancing in the queue, the levels of traversal are well defined, and we gonna advance each level at a time:

public class BFS {

  public void traverse(Node<?> node) {
    Queue<Node<?>> q = new LinkedList<>();
    q.add(node);

    while (!q.isEmpty()) {
      var n = q.remove();
      System.out.println(n.value);
      q.addAll(n.children);
    }
  }

}

Let's take this graph:

  Node<String> graph = new Node<>(
      "1",
      List.of(
          new Node<>("2",
              List.of(new Node<>("5", Collections.emptyList()),
                  new Node<>("6", Collections.emptyList()))),
          new Node<>("3",
              List.of(new Node<>("7", Collections.emptyList()),
                  new Node<>("8", Collections.emptyList()))),
          new Node<>("4", Collections.emptyList())));

When traversed in BFS fashion, we get:

Depth First Traversal

If in BFS we visit near nodes first, in Depth First Traversal we advance the most possible deep level in one direction before going to other direction.

Let's take the same graph from the first image. If we traverse it in a DFS fashion, we gonna start at the node 1, then go into the direction of 2 and then 4. Next, we visit 3 and 7. Then 6 and then 5:

If we go in only one direction, we use the Stack as auxiliary data structure, because the inputs and outputs of this structure occurs in only one channel.

If we use stack, we can use the call stack too, making recursive traversals in the graph.

Let's implement it using first a regular stack:

public class DFSStack {

  public void traverse(Node<?> node) {
    var stack = new Stack<Node<?>>();
    stack.push(node);

    while (!stack.isEmpty()) {
      var n = stack.pop();
      System.out.println(n.value);
      stack.addAll(n.children);
    }
  }
}

And when testing, we get this:

And then, using a recursive approach:

public class DFSRecursive {

  public void traverse(Node<?> node) {
    System.out.println(node.value);
    for (var n : node.children) {
      traverse(n);
    }
  }

}

And testing this, we get:

Using graph fundamentals to solve the challenge

With this knowledge, we know that:

The tree is only a configuration of graph
Graphs can be traversed in two ways: BFS and DFS
Therefore, trees can be traversed in that ways

If we can use these traversals in tree, we need only a type of traversal that can, therefore, differentiate between levels, and I think the BFS is perfect for this.

But how can we differentiate between one level of the tree and another?

It's easy: we can put a dummy node, with a null value inside it, that makes this difference for us. This dummy node will indicate that we are at the end of the actual level, and then we can move this dummy node to the end of the queue, to mark each end of level.

Let's implement this:

public class PrintTree {

  public void traverse(Node<?> node) {
    Queue<Node<?>> queue = new LinkedList<Node<?>>();
    var dummy = new Node<Object>(null, Collections.emptyList());
    queue.add(node);
    queue.add(dummy);

    while (!queue.isEmpty()) {
      var n = queue.remove();
      if (n.value == null) {
        System.out.printf("\n");
        queue.add(dummy);
      } else {
        System.out.print(n.value + " ");
      }
      queue.addAll(n.children);
    }

  }

}

A simple implementation at first, but we have a problem in this implementation.
When we test it, we get the following behavior:

<=<===========--> 87% EXECUTING [16s]
> :lib:test > 0 tests completed
> :lib:test > Executing test com.eronalves.printtreelevels.TestPrint

The test execution gets stalled, only appending new line chars to the console.

Of course, our implementation has no stop condition, and get's appending a new dummy node each time it gets a dummy node from the queue, that way, appending new lines to the console for ever.

How can we stop the execution in a correct way?
Simple: we gonna verify if the queue is empty when appending the dummy node. If it's empty, then the graph is over. Otherwise, the queue have graph nodes yet, so we continue to append dummy nodes at the end:

        if (!queue.isEmpty()) {
          queue.add(dummy);
        }

And now with test, we finally get:

    1 
    2 3 4 
    5 6 7 8

Domain Driven Design: It's a matter of communication

EronAlves1996 — Wed, 08 Jan 2025 21:36:00 +0000

Let's be real: in the majority of sets you gonna work with a multidisciplinary team. You don't work only with developers, but business analysts, product managers, quality assurance analysts, security analysts, scrum masters, etc.

In fact, the technology don't exist in a vacuum, but the technology exists for serve a need. The enterprise has all the reasons to employ tech to solve problems and make processes more faster and efficient. So, they hire technology guys like us to solve these.

But we have some mismatch in our communication. How??

As technology guys, we talk about:

Programming languages;
Databases;
Modelling data;
Concurrency models;
Pure computational logic;

But the business guys talk about:

The yearly plan;
Yearly budget;
Team management;

Anyway, they use business terms to talk about the problem. How can we solve this mismatch???

The first thing we need to perceive is that we are trying to solve a business problem!!

The technologies problem are solved in majority with libraries, frameworks and operational systems and we employ all these tools to solve the business problem. We need to start to learn the domain we are targeting and try to make an Ubiquitious Language, that everyone can talk and understand.

The Ubiquitious Language

This ubiquitious language emerge as some convergence from tech language with the business language.

It's like the light blue in this venn diagram. The business guys and the tech guys will not talk about budget or databases alone, but they will try to find a common denominator between these terms to communicate better, with more assertivity, reducing the miscommunications and poor understood requirements.

The Bakery Shop Example

In the last post, I introduced the Bakery Shop Example, where I make a diagram. One interesting fact is that diagrams and documentation only support the two main things when conveying communication:

Code (running code don't lie);
Spoken language;

If code don't lie, we need to try to take some attention to make code that communicate good intent. If it don't communicate well, so, it's a poor code (with high probability to become legacy), and if no-one understands this code, no-one can change it and no-one can tell anything about the business rule.

The code here is a product from the communication, protocols and things that tech guys come to an agreement with business guys. Because of that, the communication, specially spoken communication, is very very important.

So here, we have a very hard difference between these two lines:

When the user start a new recipe, the system will query the database to find if in the stock table the registries have the quantity needed, so we retrieve these entities and set to used some quantities, then save it again into table;
When the user start a new recipe, we take the RecipeIngredientsSpec to the Stock and retrieve all of them;

Did you see the difference? The ubiquitious language is a mean to make a common abstraction here. The description is about the same thing, but the way it will influence the understanding and the resulting code will be very different!

Object Oriented Analysis and Design

Many people read some book on the matter, but still making procedural code.

Procedural and Object Oriented Code are different ways to communicate some intent through code. But they are byproduct of the language used to model things.

Object Oriented Code and even Functional Code emerges from declarative language. You don't tell how to do a thing, you tell what you wan't to do only, and make abstractions to support this.

Procedural code emerges from descriptive language, where you have to tell how to do anything.

When you employ a declarative way of talking to each other, the understanding in the project will be better, and a better design have the opportunity to emerge.

Another way to check palindromes

EronAlves1996 — Mon, 30 Dec 2024 04:58:46 +0000

By these days, I was scrolling into Linkedin and Twitter, and see a very common coding challenge: check if a string is a palindrome.

It's a very simple challenge. A palindrome is a word or phrase that can be read the same inwards and backwards. Just like:

tesset
mam
biaib

and so on.

But the general approach people follow is like this:

In other words, they take the original string and then reverse it, then compare it against the original.
It's a very valid approach, but I want to sugest a clever approach for it.

See that you need to produce a new allocation for the string, then compare char by char. The way it can be more challenging is, how to do it using a O(1) more memory, and making less comparisons?

Let me explain this better.

The better approach to tackle this problem is by using two-pointer approach.

A string is nothing more than a char array, and we can go through it char by char, and make traversals and comparisons against any char of the array.

Let's refactor it using the new approach using two pointer.
The first thing we need to made is to take a rune slice from it:

  r := []rune(str);

Strings in Go are readonly, so basically, the string is immutable and cannot be changed. The rune slice, otherwise can be changed, and then, the conversion between the two make a copy of string bytes, but then, we are not make another copy here, because we will continue in the same stack frame, and we don't gonna produce a new string.

After that, we gonna start the loop, with a pointer in the start of the rune and another from the end, and we gonna traverse it until one crosses another. We gonna make the comparisons here:

func isPalindrome(str string) bool {
    r := []rune(str)
    for i, j := 0, len(r)-1; i < j; i, j = i+1, j-1 {
        if r[i] != r[j] {
            return false
        }
    }
    return true
}

That way, if the comparisons goes ok, and all the chars are the same, then it's a palindrome. Otherwise, it returns false instantly.

Domain Driven Design: making a domain modeling

EronAlves1996 — Sat, 28 Dec 2024 16:50:32 +0000

Recently, I started to read Eric Evans's Book, Domain Driven Design, and I make a decision to share my learning journey as a little journal.

So I started with the first chapter from this book, an now, the first thing to do is to learn the domain where we gonna solve the problems. Let's make an exercise with this:

Develop a domain model for a hypothetical small business, such as a local bakery.

The first anectodes and lessons from this book is regarding with talk with the experts from the field, to gather some knowledge about what is the problem we're trying to solve, what are the pain they are feeling, and how is the best way to solve it.

The code now is just a side effect of a solution, but the way we draw the steps and define some concepts make the communication more direct and clear between development and business. The main mote for DDD is using domain concepts and an ubiquitious language. We should match our code and architecture with all the way of thinking of field experts.

Let's start the exercise by defining our domain. Bakeries generally are small businesses, and the main problem they have are regarding management. We can tackle here sales, people or stock management. So, we have a domain: Bakery Management.

We need to define a Bounded Context. We have some contexts where we can start to solve problems: inventory, people, sales, orders, recipes and others. Maybe we should do something for Inventory, a system for inventory and stock management. I think that's alright!

So, the next step is to start to talk to field expert to crunch some knowledge. By this time, I simulated this talk with AI!!
What I focused while talking with AI is to perceive the pain points in inventory management and focused more in the fabrication and quality inspection process of a bakery instead of the overall inventory and stock management. By the way, the result is the following picture:

So, we have the main Stock here, and some process in fabrication that produces and consumes products, like:

The ingredient selection process;
The quality control process;
The every day inspection needed to make to see if some product is outside the due date;
Wastes that are produced in the fabrication process.

In this step, you can learn somethings very valuable in the field, by expanding the base knowledge from the system description and make some drawing to take the general idea, making communication clear.

By the time, starting from here, we can start to draw some class diagrams and make some MVPs to cope with this process in the start and identify improving points. In the next posts, I will continue reading the book and provide more examples.