DEV Community: Eduardo Teixeira

Black October: AI sped up the hunt for vulnerabilities, and the bill came due

Eduardo Teixeira — Sat, 07 Nov 2026 15:59:01 +0000

This post was originally published in Portuguese on my blog: Black October: a IA acelerou a caça às falhas, e a conta chegou.

October is officially Cybersecurity Awareness Month. In 2026 it earned a much less friendly nickname: Black October. In just a few days we saw a critical PHP flaw discovered with the help of AI, a certificate authority leaving the market because of private keys you could practically guess, and a popular AI library distributing malware through PyPI. If you work with software and didn't have to update anything in the last few weeks, you were either very lucky or didn't look closely.

What happened

The loudest episode was PHP2Shell. Researchers at Wiz, with support from OpenAI and Calif, found memory-safety flaws in the PHP core, tied to how the language handles fatal errors, mainly memory exhaustion. A failing request can leave corrupted internal state behind, which another request later reuses. The result is unauthenticated remote code execution, with severity scores up to 9.2. The most striking detail: the problem had been there for more than a decade and affected practically every version since PHP 5.4.

According to Wiz itself, frontier AI models took part in the discovery, in building the exploits and in validating the patches. The first flaw was found on August 19; within two days there was confirmed remote execution on Drupal and WordPress. PHP shipped the fixes (8.2.35, 8.3.36, 8.4.27 and 8.5.12) on October 21, and the NSA went as far as recommending updating immediately or taking systems offline until you could.

Almost at the same time came the eMudhra case, an Indian certificate authority. A researcher found that eight private keys for intermediate certificates had values smaller than 256. Yes: keys that should be gigantic random numbers could be recovered almost instantly. Chrome and Firefox blocked the intermediates within hours, Mozilla stopped trusting the affected root, and the company announced it would exit the global TLS certificate business. About 30,000 certificates had to be replaced.

To close out the week, LiteLLM, a library widely used to talk to multiple language model providers, had its release pipeline compromised. For a few hours on the 21st, version 1.107.0 on PyPI and images on Docker Hub carried a credential stealer.

Why this matters if you work in tech

None of these cases is new in shape. Old bugs in popular languages, CAs with poor processes and supply chain attacks have all happened before. What changed is the pace. In August, Microsoft's Patch Tuesday fixed 419 vulnerabilities, about five times the volume of a typical month before this wave; in October, the security press counted more than 1,400. Finding flaws got cheaper, and that holds for defenders and attackers alike.

In practice, a few things become obvious:

Updating is no longer a "when I get around to it" task. If the window between disclosure and exploit keeps shrinking, the patch process has to be fast and, ideally, automated.
Inventory is security. If you don't know which versions of PHP, Node or Python libraries you run in production, you lose days just figuring out whether you were affected.
Pinning versions and verifying package origin matters. The LiteLLM case shows that an uncritical automatic update can be the very entry point.
Automatic certificate renewal isn't the end of the story. Chrome warned that common ACME clients may not replace certificates outside the renewal window without ARI support or manual intervention.

My take

A lot of people are treating Black October as proof that AI is going to "break the internet". I see it differently. The PHP flaws had existed for more than ten years; AI didn't create them, it just found them. This is collective technical debt being collected all at once, and it's better for it to be collected by researchers doing coordinated disclosure than by someone working in silence.

The problem is that the capacity to fix doesn't scale at the same pace as the capacity to find. Open source projects maintained by a handful of people, companies with legacy systems nobody dares to touch, and teams that treat updates as a risk rather than as protection will feel it first. The eMudhra case, by the way, didn't even involve AI: it was a basic process failure, the kind that only shows up when someone finally decides to look.

For developers, the lesson is less glamorous than it seems: keep dependencies up to date, know what runs in production, have a reliable deploy pipeline and enough tests to update without fear. None of this is new. The difference is that now the bill arrives faster.

Sources:

Agents that don't wait for you to ask: the price of privacy and of compute

Eduardo Teixeira — Sat, 07 Nov 2026 15:57:32 +0000

This post was originally published in Portuguese on my blog: Agentes que não esperam você pedir: o preço da privacidade e da computação.

For years, an AI assistant was something that sat waiting for you to type. You ask, it answers, done. The shift happening now is different: agents that stay on all the time, look at your inbox, learn your goals and go off doing things without anyone asking. In theory that's great. In practice, it opens a conversation that those of us working in tech need to have before granting access to everything.

What happened

At DevDay on September 29, OpenAI introduced "Dots", agents it describes as always on. Each one has its own cloud computer, with a browser, and connects to thousands of apps through plugins. You can talk to it through ChatGPT or through Slack and Teams, and it runs several projects in parallel. The first Dot is included in the Pro and Business Premium plans, and on the Pro plan the feature hasn't yet reached the European Economic Area, Switzerland and the UK.

There's a layer of control: rules for when to act alone and when to ask, custom rules to allow, block or require approval for specific actions, and an automatic review before anything that touches accounts or shares information. Changing a password, for example, is still the user's job. OpenAI itself warns that the agent can make mistakes and that all important work needs human review.

This week, Fortune tied together two threads that usually run separately in this discussion: privacy and the cost of compute.

The price of privacy

According to the report, Meredith Whittaker, president of Signal, has been warning that personal agents need deep access to your data to work, and that creates security and privacy risk. The point that struck me most is about consent: whoever sends an email or message to a person using one of these agents never agreed to have an AI read it. The access you grant carries along the correspondence of everyone you talk to.

OpenAI's own head of developer experience, Romain Huet, suggests gradual trust: start with the calendar and only later open up Slack and Gmail. He says he lets his Dot categorize emails and draft replies, but never send messages on his behalf. It's sensible advice, and it applies to any agent, from any company.

The price of compute

An always-on agent costs more than a chatbot. An OpenAI executive admitted that Dots are "compute heavy", and the company already routes part of the work to a smaller model, Terra, which according to OpenAI delivers even better results on some tasks, like computer use and writing, at a tenth of the price. On the side of those paying the bill, Fortune cites Menlo Ventures data: companies spent US$ 177 billion on AI in the 12 months through September, more than five times the previous period, and spent well above what they had budgeted. It also reports that Apple lowered the daily AI spending cap for some engineers from US$ 300 to US$ 200.

Why this matters if you work in tech

Permissions become an architecture decision. Whoever integrates agents with internal systems will need to think about least privilege, separate credentials, an audit trail and a way to pause everything. It's the same reasoning as for any service account, except this account now takes initiative.
Cost becomes part of the design. If the agent runs all day, the token budget stops being an end-of-project detail. Routing between large and small models will likely become common practice.
Privacy is about third parties too. In a country with a data protection law like Brazil's LGPD, delegating email and chat reading to an agent means looking at what that implies for clients and colleagues, not just for you.

My take

I find the idea promising and the moment still immature. The technical side is evolving fast, but usage habits are still in "allow everything and see what happens" mode. I'd treat an agent like this the way I'd treat a very fast intern: start with read access to a few things, approve what it does before it leaves the building, and only expand trust with evidence. And I'd pay attention to what the vendor doesn't answer clearly, especially about what happens to the data of people who aren't your users.

It's also worth being wary of collective enthusiasm. When the cost is still being subsidized and the access rules change every quarter, any critical process relying on an agent needs a plan B. Use it, yes. Blind dependence, no.

Sources:

Rate limiting in Minimal APIs with .NET's built-in middleware

Eduardo Teixeira — Sat, 07 Nov 2026 15:56:44 +0000

This post was originally published in Portuguese on my blog: Rate limiting em Minimal APIs com o middleware nativo do .NET.

Every API exposed to the internet will, sooner or later, get a client that decides to hit the same endpoint a thousand times per second. It might be a bug in a retry loop, a poorly written script or someone trying their luck. If you have no limit at all, the database, the CPU and your other users pay the bill.

The good news is that since .NET 7, rate limiting ships with the framework. No extra package, no third-party library. In this post I build a small example with Minimal APIs, per-IP limits, a 429 response with Retry-After and integration tests.

The core idea

The middleware works with two concepts: the limiter (the algorithm: fixed window, sliding window, token bucket or concurrency) and the partition (who is being limited). Without a partition, the limit is global, and one abusive client takes the service down for everyone. Partitioning by IP gives each client its own bucket.

You register a named policy and then apply it to the endpoints that need it. Endpoints like health checks usually stay out, otherwise the orchestrator may decide your application is down.

Registering the policy

builder.Services.AddRateLimiter(options =>
{
    options.RejectionStatusCode = StatusCodes.Status429TooManyRequests;

    options.AddPolicy("por-ip", context =>
        RateLimitPartition.GetFixedWindowLimiter(
            partitionKey: context.Connection.RemoteIpAddress?.ToString() ?? "anonimo",
            factory: _ => new FixedWindowRateLimiterOptions
            {
                PermitLimit = limit,
                Window = TimeSpan.FromSeconds(windowSeconds),
                QueueLimit = 0
            }));
});

QueueLimit = 0 makes excess requests get rejected right away instead of waiting in a queue for the next window. For a public API, that's usually what you want. The limit and window values come from configuration, which helps a lot when testing.

Telling the client when to come back

Returning 429 without saying when to try again forces the client to guess, and guessing turns into aggressive retries. The OnRejected callback lets you send back a Retry-After header with the time left in the window:

options.OnRejected = (context, _) =>
{
    if (context.Lease.TryGetMetadata(MetadataName.RetryAfter, out var retry))
    {
        context.HttpContext.Response.Headers.RetryAfter =
            ((int)retry.TotalSeconds).ToString();
    }
    return ValueTask.CompletedTask;
};

Applying it to the endpoints

var app = builder.Build();

app.UseRateLimiter();

app.MapGet("/", () => Results.Ok(new { mensagem = "ola", hora = DateTime.UtcNow }))
   .RequireRateLimiting("por-ip");

app.MapGet("/health", () => Results.Ok("ok")); // no limit

app.Run();

public partial class Program { }

A detail that catches a lot of people: UseRateLimiter() has to come before mapping the endpoints that use the policy, and the partial class Program at the end exists only so the test project can see the class.

Testing it for real

With WebApplicationFactory you can spin up the application in memory and override the configuration. I lower the limit to 3 requests and keep the window long, so the test doesn't depend on timing:

[Fact]
public async Task Requisicao_acima_do_limite_retorna_429_com_retry_after()
{
    var client = _factory.CreateClient();

    for (var i = 0; i < 3; i++) await client.GetAsync("/");
    var resp = await client.GetAsync("/");

    Assert.Equal(HttpStatusCode.TooManyRequests, resp.StatusCode);
    Assert.True(resp.Headers.Contains("Retry-After"));
}

There's also a test making sure /health handles ten calls in a row without getting a 429. It's the kind of regression that slips by until the day the load balancer pulls your application out of rotation.

Running with Docker

The project has a multi-stage Dockerfile with two targets, app and tests, and the compose file exposes both:

docker compose up --build
# in another terminal, call it more than 5 times within 10 seconds
for i in $(seq 1 7); do curl -s -o /dev/null -w "%{http_code} " localhost:8080/; done

docker compose run --rm tests

You should see something like 200 200 200 200 200 429 429. If you look at the headers of the rejected response, Retry-After will be there.

Before going to production

This limiter lives in the memory of each instance. With several replicas behind a load balancer, each one counts on its own, so the effective limit is multiplied by the number of instances. If you need a global, exact limit, the way to go is a shared counter, usually in Redis, or delegating it to the gateway.

Behind a reverse proxy, RemoteIpAddress will be the proxy's IP, not the client's. Configure ForwardedHeaders first, otherwise all users fall into the same partition and share the same limit.

For day-to-day work, the built-in middleware handles most basic protection scenarios well, with no dependencies at all.

The full code is at programero-csharp/2026-11-rate-limiting-minimal-apis.

Clojure - Símbolos globais e locais

Eduardo Teixeira — Fri, 18 Feb 2022 18:20:00 +0000

Até agora, sempre que foi necessário manter um valor em memória nós usamos o conceito de "variável", realizando a "definição de um símbolo" com o comando "def". Porém essa abordagem corresponde ao que conhecemos nas linguagens mais tradicionais como "definição de variável global".

Como é de conhecimento, as definições de "variáveis globais" podem trazer uma série de problemas as aplicações, uma vez que é quase impossível ter conhecimento de todas, com isso podemos acabar gerando problemas com a substituição de valores durante seu uso, podendo causar erros em diversos pontos da aplicação e tornando a aplicação instável e de difícil manutenção.

Dito isso, veremos como trabalhar com símbolos dentro de um escopo limitado, seguiremos os próximos exemplos dentro de nossas funções.

Escopo global

Como vimos até aqui, os símbolos de escopo global podem ser acessados de qualquer parte da aplicação, vamos ao exemplo, considerando uma aplicação hipotética de uma escola, temos duas rotinas distintas que mostram a média dos alunos em duas condições distintas:

Uma que mostra e média "padrão" acrescida de um ponto extra;
Outra que mostra a média do aluno em uma condição de "recuperação", que acresce a média dois pontos extras;
Enquanto a rotina que mostra a média "padrão" olha para um símbolo global para fazer seu cálculo sem fazer qualquer alteração a rotina que mostra a média dos alunos em condição de "recuperação" também utiliza o mesmo símbolo global, porém ela sempre altera seu valor para "dois".

O problema que teremos é o seguinte, enquanto a rotina que mostra as médias de alunos em "recuperação" não for executada a rotina de média "padrão", quando executada, apresentará um resultado correto, porém após primeira execução da rotina de "recuperação" a "padrão" começará a mostrar um resultado errado:

(def ponto-extra 1)

(defn verifica-situacao-aluno-padrao
  "Retorna a media do aluno somada a seu ponto extra"
  [nota1 nota2]
  (+ (/ (+ nota1 nota2) 2) ponto-extra)
)
(defn verifica-situacao-aluno-recuperacao
  "Retorna a media do aluno somada a seu ponto extra (em caso de recuperação)"
  [nota1 nota2]
  (def ponto-extra 2)
  (+ (/ (+ nota1 nota2) 2) ponto-extra)
)

ponto-extra
(verifica-situacao-aluno-padrao 5 5)
(verifica-situacao-aluno-recuperacao 5 5)
(verifica-situacao-aluno-padrao 5 5)

Sobre a imagem:

Na linha três definimos nosso símbolo global "ponto-extra";
Da linha cinco até a linha dezesseis definimos nossas duas funções, "padrão" e "recuperação" respectivamente;
Na linha dezenove checamos o valor do nosso símbolo global "ponto-extra", que é "1";
Na linha vinte e um consultamos a situação de um aluno com a rotina "padrão" e vemos que sua média é "6";
Na linha vinte e três consultamos a situação de um aluno com a rotina de "recuperação" e vemos que sua média é "7";
Na linha vinte e cinco consultamos a situação de um aluno com a rotina "padrão" novamente e agora vemos um resultado diferente, sua média passou a ser "7", mesmo valor que a rotina de "recuperação";
Na linha vinte e sete checamos o valor do nosso símbolo global "ponto-extra" novamente, e conforme esperado ele agora é "2";

Conforme já explicado, a função de "recuperação" altera o valor do símbolo global que é usado por outras funções, essa mudança não era esperada em outras partes da aplicação e isso gerou um problema de divergência de valores, e pior, a momentos onde o problema não ocorre (já que ele só ocorre a partir da primeira execução da rotina de "recuperação") e a rotinas que continuam a funcionar (a rotina "recuperação" sempre funciona). Acabamos de gerar um bug em nossa aplicação que não será nada fácil de simular/encontrar/corrigir.

Escopo local

Como visto anteriormente, o uso inadequado de um símbolo global gerou um bug em nossa aplicação, para resolver esse problema o desenvolvedor que criou a função de "recuperação" deveria ter usado um símbolo de escopo local na rotina, uma vez que o valor de "ponto-extra" usado ali é uma regra especifica dessa rotina.

Para trabalharmos com o escopo local utilizaremos a função "let", com ele criamos um escopo local com símbolos e funções:

O "let" deve ser usado entre parênteses;
Ele recebe um vetor de símbolos/valores;
Ele recebe uma ou mais funções;
Ele retorna o resultado da execução de sua última função;

(let [idade 40] (+ idade 1))

Na imagem acima:

Na linha um criamos nosso escopo local com o "let", nesse escopo temos o símbolo "idade" com o valor "40" dentro do vetor e temos uma função que soma a valor "1" ao nosso símbolo "idade";
Na linha dois temos o resultado da função de soma;
Na linha três tentamos usar o símbolo "idade" e recebemos um erro na sequencia dizendo que não foi possível resolver o símbolo;

Bom, agora que já sabemos como resolver o problema de escopo vamos aplicar uma correção em nossa função "recuperação", para que ela deixe de usar o símbolo global, primeiro vamos reiniciar o símbolo global para seu valor correto, em seguida vamos corrigir a função e ne sequencia executar os testes:

(def ponto-extra 1)

(defn verifica-situacao-aluno-recuperacao
  "Retorna a media do aluno somada a seu ponto extra (em caso de recuperação)"
  [nota1 nota2]
  (let [ponto-extra-recuperacao 2]
    (+ (/ (+ nota1 nota2) 2) ponto-extra-recuperacao))  
)

(verifica-situacao-aluno-padrao 5 5)
(verifica-situacao-aluno-recuperacao 5 5)
(verifica-situacao-aluno-padrao 5 5)
ponto-extra

Na imagem acima:

Na linha 1 redefinimos nosso símbolo global para seu valor correto;
Da linha três até a oito temos a refatoração de nossa função com o uso do "let";
Nas linhas dez, doze e catorze repetimos os testes, e agora os seus respectivos resultados estão corretos;

Conclusão

Nesse post entendemos e exemplificamos os problemas causados pelo uso do escopo global, vimos como trabalhar com escopo local com o "let" e refatoramos nossa função problemática para que nossa aplicação voltasse a funcionar da forma esperada.

Saiba mais

Clojure - Criando nossa primeira função

Eduardo Teixeira — Wed, 09 Feb 2022 17:26:29 +0000

Anteriormente vimos como configurar o ambiente e em seguida escrevemos nossas primeiras linhas de código para começarmos a entender como o Clojure funciona, usamos algumas funções "nativas", declaramos algumas "variáveis" e também brincamos com um vetor.

Nesse post daremos mais um passo, escreveremos nossa primeira função, passando por algumas de suas características e entendendo um pouco sobre como a criação delas funciona.

Definindo nossa primeira função

Para criar nossa primeira função precisamos ter em mente que o que deve ser feito é algo semelhante a definição de uma variável, a diferença fica por conta do uso do comando "defn" (é possível usar o "def", mas veremos isso futuramente), basicamente precisaremos:

Escrever todo o conteúdo dentro de parênteses;
Usar o comando "defn";
Definir uma lista de parâmetros, se não existirem parâmetros (nosso caso agora) essa lista deve estar vazia;
Definir o corpo da função;
Opcionalmente podemos colocar um comentário para deixar mais claro o que a função faz;

Definindo nossa função:

(defn minha-primeira-funcao
  "Exemplo de uma função"
  []
  (println "Minha primeira função!")
)

Executando nossa função:

(minha-primeira-funcao)

Na imagem acima temos:

Na linha três temos o inicio da definição de nossa função com o uso de "defn" seguido do nome que escolhemos;
Na linha quatro, entre aspas duplas, temos o comentário que explica o que a função faz;
Na linha cinco temos o vetor de parâmetros vazio;
Na linha seis temos o corpo de nossa função, que realiza a impressão no console de uma frase;
Na linha sete temos o fechamento de nossa função;
Na linha nove executamos a nossa função;
Na linha dez temos o resultado da execução e na onze o retorno;

Apenas um detalhe, a função toda foi escrita no bloco de notas, e depois copiada para o console para a execução.

Criando uma função que recebe parâmetros e devolve um valor

De acordo com nosso exemplo anterior, para criarmos uma função que receba parâmetros basta declara-los no vetor que tem essa responsabilidade, agora para retornar um valor basta construirmos uma instrução que retorne um valor.

Para nosso segundo exemplo criaremos uma função que calculará e retornará a média de um aluno com base em duas notas:

(defn calcula-media
  "Calculando a media de duas notas"
  [nota1, nota2]
  (/ (+ nota1 nota2) 2)
)

Executando nossa segunda função:

(calcula-media 7M 8M)

Na imagem acima temos:

Da linha três a linha sete temos a definição de nossa função, destaque para a linha cinco onde temos a definição de dois parâmetros (nossas duas notas) e para a linha seis, onde de fato realizamos o cálculo e por consequência o retorno da média, analisando de "dentro" para "fora" temos a soma das notas e depois a divisão por dois;
Na linha nove temos a execução da função de média, onde informamos as duas notas, a "letra M" colocada junto do valor das notas é apenas para termos um resultado mais amigável, a frente entenderemos melhor a questão de tipos de dados;
E na linha dez temos o resultado apresentado, a média calculada;

Conclusão

Nesse post escrevemos nossas duas primeiras funções e entendemos como passar parâmetros e devolver um resultado.

Saiba mais

Clojure - Funções, vetores e def

Eduardo Teixeira — Mon, 07 Feb 2022 12:28:47 +0000

Nessa postagem escreveremos nossas primeiras linhas de código com o Clojure, aqui tentaremos trazer alguns conceitos para mais perto de quem já programa com os paradigmas mais tradicionais (orientação a objetos por exemplo), de modo que fique mais simples entender as intenções e começarmos a correlacionar alguns pontos, mesmo que alguns deles não sejam necessariamente a mesma coisa.

Funções

Como já é de conhecimento, funções são pequenas partes de um programa que executam um trabalho e devolvem um resultado, e para que esse trabalho seja realizado muitas vezes é necessário informar argumentos ou informações para que algo seja feito.

Em Clojure toda invocação de uma função ocorre dentro de parênteses, logo podemos interpretar o conteúdo que esta dentro dos parênteses da seguinte forma:

O primeiro valor é a função a ser executada;
O segundo valor é o primeiro argumento que a função receberá;
Vamos agora ao nosso primeiro exemplo, iremos chamar uma função que escreve no console, passando como "argumento" o famoso "Olá Mundo!":

(println "Olá Mundo!")

Vamos falar sobre a imagem agora, linha por linha:

Na primeira linha estamos iniciando o Clojure com o comando "clj";
Na segunda linha nos é apresentada a versão atual (1.10.3);
Na terceira linha começamos a escrever nosso primeiro código, chamando a função "println";
Na quarta linha temos o resultado da execução interna da função "println", que é a escrita no console da frase que informamos como "argumento";
Na quinta linha temos o retorno da função "println", como ela não retorna nada recebemos nulo (nil);
Na sexta e última linha temos o controle a disposição novamente para informar os próximos comandos;

Ainda sobre funções vale destacar que os operadores matemáticos também são considerados como funções, logo se quisermos somar dois números, por exemplo, precisaríamos iniciar a expressão com o operador de soma, seguido dos "argumentos" (números) que desejamos somar:

(+ 1 2)

Iniciar a a expressão com um número, utilizando um padrão de operação comum nas linguagens de programação mais tradicionais resultaria em erro, uma vez que o Clojure tentaria interpretar um número como uma função:

(1 + 2)

Na imagem acima vemos os dois exemplos, o primeiro com o resultado correto, onde a soma é o primeiro parâmetro e o segundo com o resultado incorreto, onde o Clojure nos diz que o número informado não é uma função.

def

Quando estamos programando é trivial mantermos determinados valores (independente do tipo) armazenados em memória, para podermos acessá-los durante a execução de uma aplicação ou função e comumente realizamos isso por meio de "variáveis", sendo justamente esse o conceito que utilizaremos agora para tentar entender o "def".

Com o "def" criamos (ou definimos) símbolos que nos permitem salvar e recuperar determinados valores, funcionando de forma semelhante a uma variável, sua sintaxe é simples, e funciona como uma função, onde temos a função propriamente dita, o símbolo a ser criado/atualizado e o valor que pretendemos associar ao símbolo:

(def total-de-alunos 25)

Para poder ver o valor armazenado em nosso símbolo podemos usar o "println" ou podemos ver seu conteúdo simplesmente digitando o nome do símbolo (fora de parentes é claro):

(println total-de-alunos)

total-de-alunos

Na imagem acima vemos o seguinte:

Na linha três a definição do símbolo "total-de-alunos" com o valor "25";
Na linha quatro o retorno que nos indica o espaço onde nosso símbolo esta gravado (user);
Na linha cinco executamos a função "println" para ver o conteúdo;
Na linha oito verificamos o valor do símbolo diretamente, sem o uso de uma função;
Nas linhas seis e nove podemos ver o valor armazenado no símbolo;

Para alterar o valor de um símbolo basta utilizarmos o "def" novamente, informando o identificador e o novo valor, esse novo valor pode ser um número fixo (como vimos anteriormente) ou pode ser a execução de uma outra função:

(def total-de-alunos 30)

(def total-de-alunos (+ total-de-alunos 5))

Podemos observar na imagem acima:

Na linha um definimos um novo valor para o símbolo;
Na linha três pedimos para ver o novo valor e na linha quatro o vemos (30);
Na linha cinco alteramos o valor novamente, fazendo com que o novo valor seja o valor já existente "30" somado a "5";
Na linha sete pedimos para ver o novo valor e na linha oito o vemos (35);

Vetores

Quando começamos a aprender uma nova linguagem de programação umas das primeiras estruturas que aprendemos para armazenar uma série de elementos é o vetor, em Clojure não é diferente, a exemplo do que vimos anteriormente, iremos usar o "def" para definir um símbolo ficando por conta do valor atribuído a definição desse vetor, em nosso caso iremos atribuir uma série de nomes entre colchetes:

(def alunos ["Maria", "Flávia", "Teresa"])

Perceba que no comando acima utilizamos "virgulas" para separar os elementos, mas o que conta mesmo para essa separação são os espaços, a virgula esta ali apenas como uma boa prática que nos permite identificar melhor os itens (inclusive as virgulas são consideradas como espaços no Clojure).

Para ver os itens de nosso vetor podemos usar tanto as formas já vistas até aqui, com o "println" ou digitando o nome do símbolo diretamente, o que resulta na apresentação de todos os valores ou podemos acessá-los por meio de suas posições, nesse último caso o vetor acaba funcionando como uma função que recebe como parâmetro a posição desejada:

(println alunos)

alunos

(alunos 2)

Quando trabalhamos com vetor temos a disposição a função "count" para contar o total de elementos:

(count alunos)

Agora se nossa intenção for adicionar um novo item ao vetor devemos usar a função "conj", aqui é muito importante entendermos que essa função não altera o vetor original, o que ela faz é retornar um novo vetor que possui os valores anteriores e também o novo, isso devido a imutabilidade do Clojure:

(conj alunos "Eduardo")

Mas qual a vantagem da imutabilidade então? Bom ela nos garante que nossa informação (no caso os valores de nosso vetor) não serão alterados sem o nosso conhecimento ao utilizarmos outras funções, desse modo temos uma confiabilidade maior sobre a informação uma vez que ela só será alterada se realmente desejarmos, ou seja, não corremos o risco de termos os dados alterados por uma função que se quer conhecemos a implementação.

Na imagem acima temos:

Na linha sete usamos a função "conj" para adicionar um elemento ao vetor;
Na linha oito a função "conj" nos retorna o novo vetor contendo a alteração que realizamos;
Na linha nove e dez podemos perceber que o vetor original "alunos" não foi alterado;

Certo, como já é possível imaginar, se nossa intenção for alterar o vetor original precisaremos então redefinir o valor do nosso símbolo "vetor", sendo que seu novo valor será o resultado da execução da função "conj":

(def alunos (conj alunos "Eduardo"))

Como podemos ver na imagem acima agora o vetor original "alunos" possui o novo valor.

Conclusão

Nessa postagem sentimos o gostinho inicial do Clojure, escrevemos nosso primeiro "Olá Mundo!", definimos nossa primeira "variável" e criamos nosso primeiro vetor. Também nos deparamos com a imutabilidade, entendendo como ela funciona e uma de suas principais vantagens.

Saiba mais

Clojure - Preparando o ambiente

Eduardo Teixeira — Thu, 03 Feb 2022 18:56:19 +0000

Antes de mais nada precisamos preparar nosso ambiente para podermos começar a brincar, no link oficial temos os processos de instalação de acordo com os SOs suportados, nessa postagem iremos falar sobre as instalações no Linux e no Windows.

Windows

Para a instalação no Windows podemos usar o instalador ou fazer o processo via linha de comando com o PowerShell, esse último seguindo as seguintes instruções (conforme indicado aqui):

Se certificar que o PowerShell esta na versão 5 ou posterior, para tal basta abrir o mesmo (pressione "Windows + X", escolha "Executar" e digite o comando "Powershell"), e em seguida digitar o comando "get-host":

Também devem estar instalados o ".NET Core SDK 2.1+ or .NET Framework 4.5+ (ou mais recente)". Além disso precisaremos do Java 8+ e a variável de ambiente JAVA_HOME configurada;
Se tudo estiver certo basta executar o comando para o download "iwr -useb download.clojure.org/install/win-install-1.10.3.1058.ps1 | iex":

Como podemos ver acima, após o download nos é apresentada uma lista de possíveis locais para a instalação, no nosso caso escolheremos a opção "2":

Se tudo correu bem até aqui temos nossa configuração inicial pronta;

Linux

Em nosso caso estamos usando a distribuição Ubuntu 18.4;
Precisamos garantir que as seguintes dependências estão instaladas: bash, curl, rlwrap e o Java (em nosso caso precisamos instalar apenas o Java, e para tal utilizamos esse artigo);
Se estiver tudo OK basta baixar um script pronto (com o curl), depois executar ele:

Conclusão

Concluímos a instalação base do Clojure tanto no Windows como no Linux, nas próximas postagens começaremos nossa caminhada!