DEV Community: baltz

Stop Vibing, Start Eval-ing: EDD in Practice

baltz — Sun, 05 Apr 2026 10:51:45 +0000

In the first part I talked about what EDD is and why it matters. Now I want to show how to actually do it. No theory, just code.

I'm going to build an eval harness from zero for a support agent. Same idea applies to anything you're building with LLMs.

The dataset

Everything starts with a JSON file. Real questions, expected behaviors, stuff the agent should and should not say.

[
  {
    "id": "wire-transfer-reversal",
    "input": "Can I reverse a wire transfer I made yesterday?",
    "expected": {
      "must_mention": ["24-hour window", "fee"],
      "must_not_mention": ["instant refund", "no fee"],
      "expected_tone": "helpful and clear"
    }
  },
  {
    "id": "account-locked",
    "input": "My account is locked and I can't access my funds",
    "expected": {
      "must_mention": ["identity verification", "support team"],
      "must_not_mention": ["call the police"],
      "expected_tone": "empathetic and urgent"
    }
  }
]

Start with 5 cases. I know it feels like nothing but the point is to start measuring, you add more as you find failures in production.

The grader

I use two types of grading. Deterministic checks for things I can verify with code, and LLM-as-judge for subjective stuff like tone. Deterministic always comes first because it's fast, free, and reproducible.

import json
from anthropic import Anthropic

client = Anthropic()

def deterministic_grade(output: str, expected: dict) -> dict:
    mentioned = sum(1 for t in expected["must_mention"] if t.lower() in output.lower())
    coverage = mentioned / len(expected["must_mention"])

    hallucinations = sum(1 for t in expected["must_not_mention"] if t.lower() in output.lower())
    no_hallucination = 1.0 if hallucinations == 0 else 0.0

    return {"coverage": coverage, "no_hallucination": no_hallucination}

def llm_judge_grade(output: str, expected: dict) -> dict:
    response = client.messages.create(
        model="claude-sonnet-4-20250514",
        max_tokens=200,
        messages=[{
            "role": "user",
            "content": f"""Score this response from 0.0 to 1.0.
Expected tone: {expected['expected_tone']}
Response: {output}
Reply ONLY with JSON: {{"tone": 0.85, "clarity": 0.9}}"""
        }]
    )
    return json.loads(response.content[0].text)

def grade(output: str, expected: dict) -> dict:
    scores = deterministic_grade(output, expected)
    scores.update(llm_judge_grade(output, expected))
    return scores

The runner

This ties everything together, loads the dataset, calls the agent, grades each response, and saves the results so I can compare later.

import json, time
from agent import run_agent
from grader import grade

def run_evals(dataset_path="evals/dataset.json"):
    with open(dataset_path) as f:
        cases = json.load(f)

    results = []
    for case in cases:
        start = time.time()
        output = run_agent(case["input"])
        latency = time.time() - start

        scores = grade(output, case["expected"])
        scores["latency_ok"] = 1.0 if latency < 2.0 else 0.0
        avg = sum(scores.values()) / len(scores)

        results.append({"id": case["id"], "avg": round(avg, 3)})
        print(f"  {case['id']}: {avg:.1%} ({latency:.1f}s)")

    overall = sum(r["avg"] for r in results) / len(results)
    print(f"\n  Overall: {overall:.1%}")

    with open("evals/results.json", "w") as f:
        json.dump(results, f, indent=2)

When I run this I get something like:

  wire-transfer-reversal: 92.5% (1.3s)
  account-locked: 87.0% (1.8s)
  international-fee: 78.3% (1.1s)

  Overall: 85.9%

That's my baseline. From here on every change I make goes through this before anything else. Changed the prompt? Run evals. Swapped models? Run evals. Added RAG? Run evals.

If accuracy goes from 0.78 to 0.83 but completeness drops from 0.91 to 0.86, now I have a real tradeoff conversation with my team instead of "I think it's better now".

Where to go from here

As your dataset grows you split into smoke evals (10 critical cases, 30 seconds, every change) and full evals (50+ cases, nightly). Same logic as unit tests vs integration tests.

The thing that really changes the game is feeding production failures back into your dataset. Every bad response you spot becomes a new eval case. After a few months that dataset becomes your most valuable asset because it represents real failure modes no one could have predicted upfront.

Your evals are your product. Start with five cases and measure everything.

Stop Vibing, Start Eval-ing: EDD for AI-Native Engineers

baltz — Sun, 05 Apr 2026 10:39:43 +0000

When I was doing traditional development, I had TDD. I wrote a test, it passed or failed, done. But when you're working with LLMs the output is different every time you run it. You ask the model to generate a function and sometimes it's perfect, sometimes it changes the structure, sometimes it just ignores part of the spec. You can't just assert(output == expected) because the output is probabilistic, it's never exactly the same.

That's where EDD comes in, Eval-Driven Development. The idea is simple, instead of testing if something works yes or no, you measure how well it works on a scale of 0 to 100%. And the important part is you define what "good" means before you start building.

How it works in practice

Say I'm building a support agent for a fintech app. Before I write a single prompt I sit down and think ok, what does success look like here? The agent should resolve at least 80% of queries without escalation, it should be factually accurate above 95%, it should respond in under 2 seconds and cost less than $0.02 per conversation. That's my eval spec.

Then I build what they call an eval harness, which is basically three things: a dataset with real examples and expected outcomes, a grader that scores the output (can be a function or even another LLM), and a runner that executes everything. I grab 50 real customer questions, I define what a great answer looks like for each one, and I write a script that runs my agent against all 50 and gives me a score.

Quick example

One of my eval cases is "can I reverse a wire transfer?". The agent should explain the 24h reversal window, mention the $15 fee, and suggest contacting the bank for international wires.

My grader checks each of those things, did it mention the time window, did it mention the fee, did it hallucinate some policy that doesn't exist. Each check gets a score, I average them, and now I have a number. Not a gut feeling, a number.

Every change goes through evals

From that point on every change goes through evals. Changed the system prompt? Run evals. Swapped models? Run evals. Added RAG? Run evals.

Vercel does exactly this with v0, they run evals on every PR and they caught a tone regression, score dropped from 0.85 to 0.72, in 20 minutes after a model swap. Without evals that would have been weeks of user complaints before anyone noticed.

Your eval suite is your product

What I realized is that in AI engineering your eval suite is basically your product. Anyone can copy your prompts, anyone can use the same model. But a dataset with 200+ edge cases and grading criteria that you built from months of real production feedback, that's what actually differentiates you.

If you're starting out, start small. Five test cases, one grader, one local script. You don't need a platform, you need the habit of measuring before and after every change.

If you want to see how to actually build this from zero, with dataset, grader, and runner code you can copy and run, I wrote a second part: Stop Vibing, Start Eval-ing: EDD in Practice.

What is ‘Harness Design’ and why does it matter

baltz — Mon, 30 Mar 2026 08:52:02 +0000

AI coding starts to feel a lot more useful when you stop expecting one agent to do everything.

The real leverage is not just the model. It is the system around it. Clear roles, clear context, clear rules, and clear validation. That is what makes the whole thing more predictable, easier to trust, and much easier to scale.

Once you start thinking this way, the workflow changes. You stop asking for magic and start designing responsibility.

The support layer matters more than people think

A lot of the quality does not come from the prompt itself. It comes from the files and structures around the workflow.

These support files are what keep the system from turning into chaos. They define how work should happen, what should be respected, and how the agent should behave when the task gets bigger or more ambiguous.

You can think about them like this:

Agent files define the default behavior and the overall boundaries
Skills define reusable capabilities for specific kinds of work
Subagents split bigger flows into smaller focused responsibilities

None of this exists to make the setup look advanced. The point is much simpler: reduce randomness.

When the workflow has structure, the agent stops guessing so much. It has a clearer sense of what matters, what is allowed, and how deep it should go.

Agent files

This is the base layer.

An agent file usually acts like the main operating logic for the workflow. It tells the system how to behave by default, what standards matter, what should never be violated, and how to approach tasks inside that project.

This is where you usually define things like:

architecture boundaries
coding conventions
validation expectations
things the agent should avoid
project-specific rules that should always stay true

Without this layer, every task starts from a weaker baseline. The agent has to rediscover too much every time.

Skills

Skills are where the workflow starts to feel modular.

A skill is basically a reusable capability for a recurring type of work. Instead of relying on one giant generic instruction set, you create focused ways of handling specific tasks.

Examples:

planning a feature before coding
reviewing a diff for regressions
writing or improving tests
debugging a failing flow
checking whether an implementation actually matches the original request

Skills make the workflow sharper. They help the agent switch from “general intelligence mode” into “specific job mode”.

That usually leads to better output because the task is framed with more precision.

Subagents

Subagents are useful when one task is too broad to stay reliable inside a single thread of execution.

Instead of one agent trying to understand everything, decide everything, build everything, and validate everything, you split the flow into smaller workers with tighter scopes.

That is where things get cleaner.

A subagent can focus on one thing only. That narrower responsibility usually means less drift, less noise, and fewer weird side effects.

A good subagent is not just “another agent”. It has a very clear purpose.

For example:

one subagent explores the codebase
one proposes the implementation path
one writes the change
one reviews for quality and risk

This is where multi-agent workflows start to feel genuinely useful instead of just flashy.

Simple starting roles are enough

You do not need a huge system to begin. In fact, starting too big usually makes things worse.

A very solid setup can start with just a few simple roles.

Planner

The planner is there to understand the task before code starts moving.

Its job is to break down the problem, map the impacted areas, identify risks, and propose the safest path forward.

A good planner reduces wasted motion. It gives the rest of the workflow direction.

Typical responsibilities:

understand the request
inspect relevant files
identify constraints
propose a small implementation path
call out risks and unknowns

The planner should create clarity, not code.

Builder

The builder is the execution layer.

This role takes the approved path and implements it with tight scope. The key here is discipline. The builder should not redesign the whole system just because it found a prettier solution halfway through.

Its value comes from focus.

Typical responsibilities:

implement the planned change
stay inside scope
preserve existing behavior where needed
keep the solution as small and safe as possible

A good builder is not creative in the wrong places. It is precise.

Reviewer

The reviewer is the friction layer, in a good way.

Its job is not to build more. Its job is to challenge what was built. That includes looking for bugs, regressions, missing edge cases, weak validation, and unnecessary complexity.

Typical responsibilities:

inspect logic quality
look for regressions
find missing tests
spot overengineering
challenge risky assumptions

This role matters a lot because agentic workflows can produce code fast, but speed without review just means mistakes arrive earlier.

Optional roles later

Once the workflow grows, adding a few extra focused roles can help.

You might add:

a tester to focus only on validation and edge cases
a debugger to investigate failures
a refactorer to improve structure without changing behavior
a documenter to keep technical decisions clear

But early on, planner, builder, and reviewer are already enough to build a strong base.

The real idea

The goal is not more agents.

The goal is better separation of responsibility.

That is the shift that makes AI coding feel less random and more like an actual engineering system. Once each part of the workflow has a clear job, quality gets easier to manage, decisions get easier to review, and the whole process becomes much more scalable.

That is when it stops feeling like prompt experimentation and starts feeling like real workflow design.

Do you want to know if the code agents are getting better or worse after every change?
No vibes, just numbers. I wrote about how I'm using EDD (Eval-Driven Development) to actually measure it: Stop Vibing, Start Eval-ing.

How FromSoftware games help me become a better technology manager 🗡️

baltz — Thu, 26 Dec 2024 18:21:02 +0000

FromSoftware is a game developer founded in 1986. The company is known for creating extremely challenging games such as Dark Souls, Elden Ring, Sekiro, and Bloodborne.

Working in technology management is equally challenging. We deal with complex and completely unpredictable scenarios all the time. A significant part of the job is staying calm amidst the chaos, and this is where FromSoftware comes in.

Let's take the game Dark Souls as an example. In it, we don't have a clear story or mission; there is only a final objective, and it is up to you to decide the path you will take.

You might walk into areas far beyond your current capabilities; the game doesn't protect you from that. Similarly, in technology management, you need to master the art of perseverance. Running around, pressing all the buttons at once like a madman, won't help you progress. You need to stay calm. The faster you can read the nuances of the enemies and the environment, the less frustration you will experience throughout the journey.

Whether playing a Souls-like game or managing technology, you need to invest significant time in strategy and planning. Each adversity requires a lot of resilience.

These valuable lessons taught by FromSoftware games can be directly applied to technology management. The need for strategy, careful planning, reading complex scenarios, and above all, perseverance.

These are fundamental principles that help me become a better technology manager. Thank you, FromSoftware.

Diversity as an Innovation Driver: leading a Multicultural Team Across Three Continents

baltz — Tue, 24 Sep 2024 17:06:58 +0000

When I accepted the challenge of leading a multicultural team (Turkey, Bangladesh, and Brazil), I knew I was embarking on a unique journey.

The cultural and geographical diversity of the team, spread across three continents, brought a wealth of perspectives and, along with it… a series of challenges.

If I could summarize everything I learned this semester in one lesson, it would be: Never underestimate cultural diversity (in all its aspects).

And I did underestimate it… If each person is a world, each culture is an entire galaxy!

Certainly, if I were to take on the same challenge today, I would adopt a different approach to optimize processes and communication.

Before initiating any action, I would invest considerable time in deeply understanding each culture and context. This cultural immersion is crucial for building high-performance teams, as different cultures have distinct perceptions of autonomy and collaboration.

What is valued in one culture can yield unexpected results in another. And about the fruits of this work? Uniting a multicultural team is like building a mosaic with unique pieces.

Each person brings a unique worldview, shaped by their experiences and cultures.

This rich diversity is our greatest strength, stimulating creativity and the exchange of ideas. By working together, we are able to find truly innovative solutions.

So, do you have any tips for building more diverse teams? Share them! I would love to hear about other experiences.

Começando com Three.js, imersão com 3D no navegador

baltz — Fri, 29 Mar 2024 19:21:35 +0000

Este artigo é a segunda parte do tutorial, recomendo que veja a primeira caso ainda não tenha visto - Parte 1

Abaixo vou deixar um spoiler do que vamos desenvolver agora:

Continuando do estado em que terminamos a primeira parte:

index.html

<!DOCTYPE html>
<html lang="pt-br">
  <head>
    <meta charset="utf-8" />
    <title>Meu primeiro 3D</title>
    <style>
      body {
        margin: 0;
      }
    </style>
  </head>
  <body>
    <canvas id="c"></canvas>
    <script type="module" src="/main.js"></script>
  </body>
</html>

import * as THREE from "three";

function main() {
  const canvas = document.querySelector("#c");
  const renderer = new THREE.WebGLRenderer({ antialias: true, canvas });

  const camera = new THREE.PerspectiveCamera(75, 2, 0.1, 5);
  camera.position.z = 2;

  const scene = new THREE.Scene();
  const geometry = new THREE.BoxGeometry(1, 1, 1);
  const material = new THREE.MeshBasicMaterial({ color: 0x44aa88 });
  const cube = new THREE.Mesh(geometry, material);

  scene.add(cube);
  renderer.render(scene, camera);
}

main();

Já possuímos um modelo 3D renderizado no navegador. Agora, vamos adicionar uma camada de imersão para aprimorar nossa experiência. Ao final deste artigo, teremos um novo projeto 3D imersivo pronto para ser adicionado aos nossos destaques no GitHub.

Para começar, vamos tornar nosso Canvas responsivo a qualquer tamanho de tela. Isto pode ser feito adicionando o seguinte estilo:

index.html

<style>
      body, html {
        margin: 0;
        height: 100vh;
      }

      #c {
        position: absolute;
        height: 100%;
        width: 100%;
        display: block;
      }
</style>

Vamos adicionar a propriedade "alpha" ao nosso Renderer e definir um tamanho ao Canvas usando o método setSize. Além disso, vamos ajustar a perspectiva da nossa câmera:

main.js

  const renderer = new THREE.WebGLRenderer({ alpha: true, antialias: true, canvas: canvas });
  renderer.setSize(window.innerWidth, window.innerHeight);

  const camera = new THREE.PerspectiveCamera(
    75,
    window.innerWidth / window.innerHeight,
    0.1,
    1000
  );

Agora que temos um canvas responsivo que renderiza nosso modelo 3D corretamente em qualquer tamanho de tela, podemos começar a adicionar imersão à nossa experiência. Para isso, vamos começar a interagir com os movimentos do mouse:

main.js

  function render() {
    document.addEventListener("mousemove", (event) => {
      let mouseX = event.clientX;
      let mouseY = event.clientY;

      cube.rotation.x = mouseY * 0.008;
      cube.rotation.y = mouseX * 0.0036;
    });

    renderer.render(scene, camera);

    requestAnimationFrame(render);
  }

Ótimo! Agora temos uma experiência imersiva com um modelo 3D. Conquistamos nossa pequena vitória do dia, e como bônus, vamos um pouco além (mas não fique mal acostumado). Vamos tornar nosso projeto mais atraente e digno de destaque no nosso GitHub, adicionando iluminação e explorando formas e materiais mais complexos.

main.js

import * as THREE from "three";

function main() {
  const canvas = document.querySelector("#c");
  const renderer = new THREE.WebGLRenderer({
    antialias: true,
    canvas,
    alpha: true,
  });
  renderer.setSize(window.innerWidth, window.innerHeight);

  const fov = 75;
  const near = 0.1;
  const far = 1000;
  const camera = new THREE.PerspectiveCamera(
    fov,
    window.innerWidth / window.innerHeight,
    near,
    far
  );

  camera.position.z = 30;

  const scene = new THREE.Scene();
  const geometry = new THREE.TorusKnotGeometry(10, 3, 100, 16);

  const material = new THREE.MeshPhysicalMaterial({
    metalness: 0, // High metalness for ruby-like shine
    roughness: 0, // Low roughness for smooth, glossy surface
    clearcoat: 0,
    clearcoatRoughness: 1,
    transmission: 0,
    color: 0xaa1133,
  });

  const cube = new THREE.Mesh(geometry, material);

  scene.add(cube);

  renderer.render(scene, camera);

  function render() {
    document.addEventListener("mousemove", (event) => {
      let mouseX = event.clientX;
      let mouseY = event.clientY;

      cube.rotation.x = mouseY * 0.008;
      cube.rotation.y = mouseX * 0.0036;
    });

    renderer.render(scene, camera);

    requestAnimationFrame(render);
  }
  requestAnimationFrame(render);

  const light = new THREE.SpotLight(0xff22aa, 300, 1000);
  light.position.set(1, 1, 10);
  light.angle = 0.1;
  light.penumbra = 10;
  scene.add(light);
}

main();

e vamos aproveitar para atualizar nossa index.html

<!DOCTYPE html>
<html lang="pt-br">
  <head>
    <meta charset="utf-8" />
    <title>Meu primeiro 3D</title>
    <style>
      html,
      body {
        margin: 0;
        height: 100%;
        display: flex;
        justify-content: center;
        align-items: center;
        background-color: #111;
        font-size: 2em;
        font-family: sans-serif;
      }
      #c {
        position: absolute;
        height: 100%;
        width: 100%;
        display: block;
        opacity: 0.6;
      }
    </style>
  </head>
  <body>
    <canvas id="c"></canvas>
    <h1>Meu primeiro 3D</h1>
    <script type="module" src="/main.js"></script>
  </body>
</html>

Espero que tenham gostado 🤙

Começando com Three.js, renderizando 3D no navegador

baltz — Fri, 29 Mar 2024 12:03:57 +0000

Meu objetivo é explicar de forma simples sobre renderização 3D no navegador. Atualmente, há poucos recursos em português sobre o assunto, o que dificulta para quem está começando, mesmo que já tenha alguma afinidade com o tema.

Para começar, a WebGL (Web Graphics Library) é a API padrão para trabalhar com 3D no navegador. Ela é responsável por desenhar pontos, linhas e triângulos, mas para projetos mais complexos, o código pode ficar extenso. Para facilitar e manter a produtividade, utilizamos a biblioteca Three.js, que permite criar cenas, trabalhar com iluminação, materiais, texturas e muito mais.

Uma aplicação com Three.js possui três elementos principais: o Renderer, a Camera e uma Scene.

O Renderer é o componente central da Three.js, responsável por receber e renderizar a Scene e a Camera em um Canvas.

A Scene é mais complexa, permitindo adicionar luzes, texturas, modelos e outros elementos.

Por fim, a Camera define a perspectiva da Scene.

Agora que a estrutura foi explicada, vamos para o código. Nosso objetivo é ter um elemento 3D renderizado no navegador até o final deste artigo. Para isso, precisaremos apenas do Node.js instalado no terminal para baixar os pacotes necessários via npm.

Começamos criando nosso index.html:

<!DOCTYPE html>
<html lang="pt-br">
    <head>
        <meta charset="utf-8">
        <title>Meu primeiro 3D</title>
        <style>
            body { margin: 0; }
        </style>
    </head>
    <body>
        <script type="module" src="/main.js"></script>
    </body>
</html>

agora vamos criar o nosso arquivo main.js

import * as THREE from 'three';

Como você percebeu, já estou importando a biblioteca. Agora vamos realizar a instalação de fato usando o npm. Além disso, aproveitaremos para instalar um pacote que nos auxiliará no desenvolvimento local, o vite:

# three.js
npm install --save three

# vite
npm install --save-dev vite

Agora que o Vite está instalado, podemos iniciar nosso desenvolvimento local. Digite no terminal:

npx vite

Com a aplicação rodando localmente, vamos criar nossa primeira cena (Scene). Para começar, adicione um canvas com um ID no nosso HTML:

<!DOCTYPE html>
<html lang="pt-br">
    <head>
        <meta charset="utf-8">
        <title>Meu primeiro 3D</title>
        <style>
            body { margin: 0; }
        </style>
    </head>
    <body>
        <canvas id="c"></canvas>
        <script type="module" src="/main.js"></script>
    </body>
</html>

Agora que temos nosso canvas, vamos selecioná-lo em nosso arquivo main.js e iniciar um Renderer:

import * as THREE from 'three';

function main() {
  const canvas = document.querySelector('#c');
  const renderer = new THREE.WebGLRenderer({antialias: true, canvas});
}

main()

Vamos adicionar a Camera dentro da função main() no arquivo main.js:

const camera = new THREE.PerspectiveCamera(75, 2, 0.1, 5);
camera.position.z = 2;

Não vou entrar em detalhes sobre cada objeto da Three.js, mas recomendo fortemente a leitura da documentação. Quanto mais tempo você investir nisso, mais rápido vai entender tudo.

https://threejs.org/docs/#api/en/cameras/PerspectiveCamera

Por fim, vamos adicionar nossa cena (Scene) e dentro dela criar um cubo utilizando as formas geométricas primitivas que a biblioteca Three.js nos oferece.

const scene = new THREE.Scene();
const geometry = new THREE.BoxGeometry(1, 1, 1);
const material = new THREE.MeshBasicMaterial({color: 0x44aa88});
const cube = new THREE.Mesh(geometry, material);

scene.add(cube);
renderer.render(scene, camera);

Pronto, se tudo correu bem, agora você tem um Canvas renderizando uma forma 3D no seu navegador. Eu sei, pode não parecer muito, mas a jornada é feita de pequenas vitórias, certo?

No próximo artigo, vamos incorporar iluminação e movimento para obter uma experiência 3D mais realista.

Deixo aqui um link para inspirações: https://threejs.org/examples/#webgl_animation_keyframes

Como mencionei, o objetivo é trazer um conteúdo mais acessível e menos "gourmet" para facilitar a entrada de quem quiser se aventurar.

Espero que tenha gostado! Abaixo está o código final para referência:

index.html

<!DOCTYPE html>
<html lang="pt-br">
  <head>
    <meta charset="utf-8" />
    <title>Meu primeiro 3D</title>
    <style>
      body {
        margin: 0;
      }
    </style>
  </head>
  <body>
    <canvas id="c"></canvas>
    <script type="module" src="/main.js"></script>
  </body>
</html>

main.js

import * as THREE from "three";

function main() {
  const canvas = document.querySelector("#c");
  const renderer = new THREE.WebGLRenderer({ antialias: true, canvas });

  const camera = new THREE.PerspectiveCamera(75, 2, 0.1, 5);
  camera.position.z = 2;

  const scene = new THREE.Scene();
  const geometry = new THREE.BoxGeometry(1, 1, 1);
  const material = new THREE.MeshBasicMaterial({ color: 0x44aa88 });
  const cube = new THREE.Mesh(geometry, material);

  scene.add(cube);
  renderer.render(scene, camera);
}

main();

Agora vamos deixar nosso projeto mais imersivo?
A segunda parte do nosso artigo já está pronta Parte 2

Dockerizing a Java Application with Spring and Maven

baltz — Mon, 15 Jan 2024 18:52:38 +0000

Docker has become an essential tool for developers, enabling the creation, deployment, and execution of applications in lightweight and portable containers. In this simple guide, we will explore how to dockerize a Java application using Spring and Maven.

Prerequisites:

Before we begin, make sure you have Docker and Docker Compose installed on your machine. You can download them from the official Docker website (https://www.docker.com/get-started).

Step 1: Project Structure

Organize your Spring project following a conventional structure. Make sure to have a pom.xml file to manage dependencies with Maven.

Step 2: Dockerfile Configuration

Create a file called Dockerfile in the root of your project. This file contains the necessary instructions to build the Docker image of your application. Here's a basic example:

# Use the OpenJDK base image
FROM openjdk:11

# Set the working directory
WORKDIR /app

# Copy the JAR files and necessary resources to the container
COPY target/your-application.jar /app/your-application.jar

# Expose the port that the application is listening on
EXPOSE 8080

# Command to run the application when the container starts
CMD ["java", "-jar", "your-application.jar"]

Make sure to replace "your-application.jar" with the actual name of your JAR file generated by Maven.

Step 3: Docker Image Build

Open the terminal in the root of your project and execute the following command to build the Docker image:

docker build -t your-application:latest .

This command uses the Dockerfile in the current directory (.) to build an image with the tag your-application:latest.

Step 4: Container Execution

Now that the image has been successfully built, you can run a container of your application with the following command:

docker run -p 8080:8080 your-application:latest

This command maps port 8080 from the container to port 8080 on the host machine. Adjust as needed.

By following these simple steps, you have dockerized your Java application with Spring and Maven. Your application is now encapsulated in a Docker container, providing portability and making dependency management easier. Be sure to explore more Docker features and adjust as needed for your specific environment.

web3 Frontend Starter Kit

baltz — Sat, 22 Jan 2022 21:36:09 +0000

Se tem curiosidade e quer entender um pouco mais sobre web3/Smart Contracts, essas são as ferramentas que você vai precisar.

Truffle Framework

Truffle é o framework usado para desenvolver smart contracts,

Ele oferece ferramentas para gerenciamento, implementação, migração, gestão de rede e um console para desenvolvimento.

Ganache

Ganache é um blockchain pessoal, usado para desenvolvimento local, simulando o comportamento de uma blockchain pública.

Solidity

Solidity é uma linguagem de alto nível, orientada a objetos e usada na implementação de smart contracts.

Metamask

Uma boa parte dos navegadores hoje, não permite conexão a blockchain, aqui entra o Metamask, uma extensão do Chrome que nos permite conectar a uma rede blockchain.

Web3.js

Biblioteca de javascript que se comunica com Ethereum, usada para desenvolvimento frontend.

A curated list of Async javascript flow

baltz — Tue, 13 Aug 2019 11:31:31 +0000

I created a list of interesting links for those who would like to study about async flow in javascript.

A curated list of Async javascript flow

Have a link?
CONTRIBUTING

Quick tip! Map loop, already returns a array

baltz — Fri, 09 Aug 2019 08:22:12 +0000

It is common to see this approach when we are creating a new array using map loop

const newArray = []

array.map((item) => {
  newArray.push(item.value)
})

Right? but map loop already returns a array.
So we can do that instead

const newArray = array.map((item) => {
  return item.value
})

Cool huh!

terminal/unix tip

baltz — Thu, 13 Sep 2018 13:25:50 +0000

Search word in terminal history.

history | grep 'word_here'