DEV Community: Tulio Calil

Desmistificando Concorrência e Consistência em Sistemas Distribuídos

Tulio Calil — Tue, 07 Apr 2026 01:20:28 +0000

Recentemente, como parte do meu mestrado em Computação Aplicada na UTFPR, mergulhei num artigo chamado "Comprehending Concurrency and Consistency in Distributed Systems" (Nitin Naik, IEEE ISSE 2021). A discussão foi bem legal e, como já tem um certo tempo que não posto nada, decidi trazer isso para cá. Vamos falar um pouco sobre concorrência e consistência e ver alguns exemplos aplicados ao mundo real.

Concorrência vs. Paralelismo (Não, não são a mesma coisa)

Concorrência: É sobre lidar com várias coisas ao mesmo tempo. As tarefas se sobrepõem no tempo (estão em andamento), mas não rodam necessariamente no exato mesmo milissegundo. O objetivo aqui é esconder a latência.

Paralelismo: É sobre fazer várias coisas no exato mesmo milissegundo. O objetivo é aumentar o throughput computacional, e isso exige hardware (múltiplos núcleos).

De uma forma mais simples: concorrência é iniciar várias coisas, mas ir fazendo um pouco de cada. Quando a CPU fica ociosa esperando algo (como uma requisição de rede), eu troco o contexto e vou para outra tarefa, fazendo isso o tempo todo. Imagina você tentando fazer o almoço e faxinar a casa: você coloca uma panela com água para ferver; enquanto ela ferve, você pega a vassoura e começa a limpar; quando a água estiver fervendo, você para de varrer e coloca o macarrão, e assim por diante.

Já o paralelismo depende necessariamente de hardware. Aqui, nós vamos pegar todo o sistema (ou partes dele) e executar em outro core da CPU. Com isso, conseguimos executar as coisas no mesmo milissegundo. Voltando à analogia das tarefas domésticas, aqui é como se você tivesse um clone seu (ou outra pessoa) para te ajudar: você começa a fazer o almoço, e, no exato mesmo instante que você começou a cozinhar, a outra pessoa começa a varrer a casa.

Vamos para um exemplo prático disso com Node.js. Vou criar uma função com um loop que gira 2 bilhões de vezes. Em cada volta, ela pega a variável sum e soma com o valor de i. A ideia é apenas criar uma função que gere uma alta carga de processamento na CPU (uma tarefa CPU-bound).

Vamos ao primeiro código. Vamos rodar isso de forma sequencial:

const ITERATIONS = 2_000_000_000; 

function heavyCPUTask() {
    let sum = 0;
    for (let i = 0; i < ITERATIONS; i++) {
        sum += i; 
    }
    return sum;
}

console.log("Sequentially (One after the other)...");
console.time("Sequential Time");

heavyCPUTask(); 
heavyCPUTask(); 

console.timeEnd("Sequential Time");

Rodando isso, temos: Sequential Time: 3.250s

Agora, vamos tentar fazer isso usando concorrência:

const ITERATIONS = 2_000_000_000; 

function heavyCPUTask() {
    let sum = 0;
    for (let i = 0; i < ITERATIONS; i++) {
        sum += i; 
    }
    return sum;
}

async function startTest() {
    console.log("Concurrently (Promises on the same Thread)...");
    console.time("Concurrent Time");

    await Promise.all([
        new Promise(resolve => { heavyCPUTask(); resolve(); }),
        new Promise(resolve => { heavyCPUTask(); resolve(); })
    ]);

    console.timeEnd("Concurrent Time");
}

startTest();

Sim, as Promises são a forma padrão de rodar código em concorrência no JS. Para esse código, temos o seguinte resultado: Concurrent Time: 3.191s.

Podemos perceber que o ganho de tempo aqui foi quase nulo em comparação ao sequencial, mas por quê? Lembra que eu falei que a gente "mascara a latência" quando a CPU fica ociosa? Então, nessa função a CPU está fritando fazendo cálculos. Não há pausas. O Event Loop (a thread principal do Node) fica totalmente bloqueado. O único ganho real aqui foi disparar as tarefas de uma vez.

Caso essa função fosse algo como uma requisição HTTP ou um acesso a um banco de dados (onde o Node apenas "espera" a resposta), teríamos uma diferença absurda de tempo entre o sequencial e a concorrência.

O Node.js, por padrão, trabalha em uma única thread, mas ele tem total suporte para mudarmos isso. Vamos usar o módulo nativo Worker Threads, para atingir o paralelismo real:

const { Worker, isMainThread, parentPort } = require('worker_threads');

const ITERATIONS = 2_000_000_000; 

function heavyCPUTask() {
    let sum = 0;
    for (let i = 0; i < ITERATIONS; i++) {
        sum += i; 
    }
    return sum;
}


if (!isMainThread) {
    const result = heavyCPUTask();
    parentPort.postMessage(result);
} else {
    function runInWorker() {
        return new Promise((resolve) => {
            const worker = new Worker(__filename);
            worker.on('message', resolve);
        });
    }

    async function startTest() {
        console.log("Parallel (Multi-Core)...");
        console.time("Parallel Time");

        await Promise.all([
            runInWorker(),
            runInWorker()
        ]);

        console.timeEnd("Parallel Time");
    }

    startTest();
}

O código ficou um pouco mais complexo, mas agora conseguimos ter um processo principal (main) que pede ao sistema operacional para criar um novo Worker para cada tarefa (nesse caso, duas), alocando-as em núcleos físicos diferentes do processador.

Com isso, temos o seguinte resultado: Parallel Time: 1.661s.
Uma quebra de tempo absurda em comparação com as outras duas abordagens.

O Pesadelo da Consistência

Se a concorrência é gerenciar o tempo da CPU, a consistência é gerenciar a "verdade" dos dados entre várias máquinas. E manter todo mundo concordando custa caro e é um trabalho árduo.

Imagine um banco de dados distribuído entre vários nós. Sempre que recebemos uma nova alteração (como o a=10 na imagem acima), precisamos replicar esse novo valor para os demais nós da rede.

Isso cria um grande dilema arquitetural: enquanto essa replicação acontece pela rede, o que fazemos se uma nova consulta bater em um nó que ainda está desatualizado? Nós liberamos o acesso a esse dado velho ou travamos a leitura até que tudo esteja sincronizado?

Pensando nisso, o autor do artigo discute duas visões principais de consistência:

Consistência Forte: A atualização trava as consultas até que todos os nós do sistema estejam com o dado idêntico. O foco é a exatidão. Exemplo: O sistema bancário via PIX. Ninguém quer ver um saldo desatualizado. O sistema prefere ficar mais lento (latência maior) do que entregar um dado errado.

Consistência Fraca / Eventual: A atualização é aceita, o sistema devolve o "OK" na hora e sincroniza o resto dos servidores no background. O foco é a alta performance, assumindo o risco de o sistema retornar um dado desatualizado (stale data) temporariamente. Exemplo: As visualizações do YouTube. Se você ver "10.000 views" no servidor do Nordeste e seu amigo em São Paulo ver "9.500" no mesmo segundo, não tem problema ler um dado desatualizado (stale data). Eventualmente, os dois servidores se alinham.

O Foco da Consistência

Além de pensarmos no tempo (quando a sincronização acontece), o artigo traz uma outra pergunta para a arquitetura: o escopo. De quem é a perspectiva de consistência que realmente importa no nosso sistema?

Para responder a isso, a arquitetura se divide em duas categorias:

Consistência Centrada em Dados (System-Wide): Aqui, o foco é o banco de dados e o sistema como um todo. A regra é: qualquer cliente, de qualquer lugar do mundo, que acessar o sistema precisa enxergar as operações acontecendo exatamente na mesma ordem. O problema disso é que como a atualização precisa ser garantida em todas as réplicas do sistema, a sobrecarga (overhead) operacional e de rede é altíssima. É a escolha ideal para sistemas com alta concorrência de escritas. Pense no Google Docs. Se você e um colega digitam no mesmo parágrafo ao mesmo tempo, o sistema precisa ordenar essas operações e forçar que a tela de todos os 10 usuários conectados no documento mostre as letras aparecendo na exata mesma ordem no mesmo milissegundo. O mundo inteiro enxerga a mesma "fonte da verdade".

Consistência Centrada no Cliente (Client-Specific): Aqui, nós tiramos o peso das costas do sistema global e focamos na sessão individual do usuário. O sistema garante a consistência apenas para a pessoa que acabou de realizar a ação. Diferentes clientes podem ver a ordem das atualizações de formas diferentes temporariamente. Claramente isso reduz drasticamente a sobrecarga dos servidores, pois o sistema não precisa coordenar uma atualização global imediata. É perfeito para sistemas de leitura massiva. Um exemplo é a foto de perfil do WhatsApp, se você atualiza a sua foto, o aplicativo se comunica com o servidor e garante que a sua tela exiba a foto nova imediatamente. Para você (o cliente), a consistência é perfeita. Mas o sistema não força essa replicação imediata no celular dos seus amigos. Eles podem continuar vendo sua foto antiga por mais algum tempo. A arquitetura prioriza a experiência do cliente ativo sem "fritar" a rede global.

O Preço da Perfeição

O autor deixa uma coisa muito clara: NÃO EXISTE BALA DE PRATA. Nem todo sistema distribuído precisa/deve ter um nível perfeito de concorrência e consistência forte. O custo disso é inviável na maioria dos projetos.

Considerando o custo absurdo da consistência forte em sistemas distribuídos sob alta carga, fica a provocação que encerrou meu seminário no mestrado:

Até que ponto nós, como engenheiros, podemos sacrificar a exatidão e entregar dados temporariamente desatualizados (stale data) em nome da performance, sem quebrar a confiança do usuário final no produto?

E você, no seu projeto atual, está pagando o preço da consistência forte ou abraçou o caos controlado da consistência eventual?

Elixir for IoT: Why It Feels Like the Future

Tulio Calil — Tue, 02 Dec 2025 23:19:37 +0000

Most IoT projects today lean heavily on Python, C, or Node.js, and that’s fine. But during my recent academic paper selection process, I came across “The Benefits of Tierless Elixir/Potato for Engineering IoT Systems”, and it completely shifted how I think about building IoT architectures.

The paper raised a question that stuck with me:
why do we keep separating the logic, runtime and UI layers in IoT systems if functional, tierless architectures can unify everything?

That curiosity, combined with the influence of a professor(Adolfo Neto) who strongly advocates for functional programming and the BEAM, pushed me to test this idea in practice.

So I built a complete IoT prototype using Elixir, Circuits, Raspberry Pi, and Phoenix LiveView. And honestly? It felt like IoT the way it should be: supervised, fault-tolerant, reactive, and consistent from the edge to the dashboard.

The Prototype: What I Actually Built

My goal was simple:

Build an IoT system end-to-end using only Elixir, from the hardware to the backend.

That resulted in a two-part monorepo:

A Raspberry Pi running Elixir (no Nerves this time, just Elixir Circuits)
A Phoenix LiveView dashboard receiving sensor data in real time

The device communicates via Phoenix Channels/WebSockets, sending temperature, light level, and button events, while receiving commands to control a buzzer.

Architecture Overview

If a sensor process fails: only that process restarts.
If the network blips: the BEAM keeps the system stable.
If the dashboard disconnects: LiveView reconnects automatically.

This is where the “future feeling” starts to show.

Circuit Setup (Everything on the Pi4)

Hardware used:

DS18B20 (1-Wire temperature sensor)
LDR + Capacitor (for RC timing)
Button (pull-up GPIO)
Active buzzer + transistor

The LDR timing loop runs in a separate process so it doesn’t block WebSocket communication, a natural fit for the actor model.

Why Elixir Feels Like the Future of IoT

After building this, a few conclusions became obvious:

The BEAM VM solves problems IoT devs fight daily
Concurrency is natural, not bolted-on
Fault tolerance is built-in
Real-time dashboards require zero JS
A single language from hardware to UI reduces mental load
Tierless architectures aren’t just academic, they’re practical

This cohesiveness made the whole experience feel weirdly futuristic.

Not flashy.
Not hyped.
Just… right.

What’s Next?

Implementing a Nerves firmware version
Adding more sensors
Testing distributed BEAM cluster of Pis
Applying Potato tierless concepts end-to-end
Publishing a deeper academic report

Elixir isn't mainstream in IoT, but maybe it should be.

This small prototype convinced me that a unified, functional, message-driven approach has the potential to dramatically simplify embedded systems.

If you're curious about IoT, the BEAM, or tierless architectures, give Elixir a try.
It might surprise you the same way it surprised me.

Try It Yourself

tuliocll / elixir-iot-sample

A complete IoT example using Elixir, Phoenix LiveView, and Raspberry Pi.

Elixir IoT Example 🚀

Elixir IoT Example is a monorepo demonstrating how to connect a Raspberry Pi to a real-time Phoenix LiveView dashboard using Phoenix Channels, WebSockets, and Elixir Circuits.

It includes:

🌡️ Real-time temperature readings (DS18B20)
💡 Light level measurement using RC timing (LDR)
🔘 Physical button input
🔔 Remote buzzer control through WS commands
📊 Web dashboard with auto-updating LiveView

This project serves as a practical, didactic example of building IoT systems entirely in Elixir.

Requirements

Elixir 1.17+
Erlang/OTP 26+
Node.js 16+ (for assets)
Raspberry Pi 4 / 3 (tested with Pi4)
Erlang + Elixir installed in the Rasp
Enable 1-Wire in Rasp (See doc/1-wire.md)

🏗️ Architecture and Circuit

Running server

cd server
mix deps.get
mix phx.server

Open:

http://localhost:4000/dashboard

📡 Raspberry Pi (Elixir Circuits)

Running

# Clone the repo on the rasp and:
cd rasp
mix deps.get
iex -S mix

The device will:

View on GitHub

Quick Tip: Fix Android Emulator DNS Issues in Arch/Linux

Tulio Calil — Tue, 14 Oct 2025 14:02:40 +0000

If your Android emulator can't resolve domains or loses internet connection, try this:

# Open this file:
code ~/.android/avd/<your_avd_name>.avd/user-settings.ini
# or
code ~/.config/.android/avd/<your_avd_name>.avd/user-settings.ini

# Add this line:
commandLineOptions=-dns-server 8.8.8.8

Then restart the emulator (preferably with a cold boot).

This forces the AVD to use Google’s DNS, works like a charm when local DNS is messy.

Originally found this tip on Stack Overflow while troubleshooting DNS issues in the Android emulator.

[Boost]

Tulio Calil — Fri, 10 Oct 2025 12:22:39 +0000

Tulio Calil

Oct 9 '25

React Conf 2025: 10 anos de React Native, 4M downloads semanais e muita coisa nova no RN

#react #reactnative #javascript #typescript

Comments

3 min read

React Conf 2025: 10 anos de React Native, 4M downloads semanais e muita coisa nova no RN

Tulio Calil — Thu, 09 Oct 2025 13:34:51 +0000

O React Native chegou aos 10 anos de vida, e a React Conf 2025 mostrou que o framework está longe de desacelerar.
De um projeto nascido em um hackathon interno do Facebook a uma das principais ferramentas para desenvolvimento mobile do mundo, o RN agora marca uma nova era, mais madura, aberta e integrada com o ecossistema web.

Durante os dias 7 e 8 de outubro, a conferência apresentou uma série de novidades que consolidam essa transição:

a Nova Arquitetura se torna padrão e obrigatória;
o novo Hermes V1 traz ganhos significativos de performance;
DOM APIs e Web Performance APIs aproximam o React Native ainda mais do React web;
e o anúncio da React Foundation inaugura uma nova fase de governança e colaboração na comunidade.

Com mais de 4 milhões de downloads semanais no npm e 6 lançamentos anuais, o React Native celebra sua primeira década evoluindo no ritmo de um ecossistema que não para de inovar.

React Foundation

A React Foundation foi anunciada como uma nova estrutura de governança independente da Meta.
O objetivo é abrir ainda mais o ecossistema React e React Native para contribuições externas, fortalecendo a comunidade e garantindo mais transparência e colaboração, um marco semelhante ao que já vimos com Node.js e OpenJS Foundation.

Nova Arquitetura como padrão

A partir da versão 0.82, a Nova Arquitetura se torna a única suportada no React Native.
Isso significa apps menores, builds mais rápidas e um modelo mental mais simples.
A Meta recomenda migrar a partir da 0.81 para aproveitar os ganhos de performance, o Shopify já relatou melhorias significativas no tempo de inicialização e renderização.

Hermes V1

O novo Hermes V1 chegou com média de +60% de melhoria em performance nos benchmarks.
Além de suporte a recursos modernos de JavaScript, ele está disponível de forma experimental na 0.82 e será o motor padrão nas próximas versões.

DOM APIs e Web Performance APIs

O React Native está cada vez mais próximo do React Web.
Com a 0.82, componentes nativos agora ganham DOM-like refs, permitindo usar métodos como getBoundingClientRect() e childNodes.
Também chegam novas Web Performance APIs, que trazem métricas avançadas e integração nativa no DevTools, incluindo painéis de Performance e Network previstos para a 0.83.

Native CSS e Tailwind no Expo

Durante a conferência, Evan Bacon apresentou uma das demos mais comentadas: suporte nativo a CSS e Tailwind no Expo, sem precisar de pacotes adicionais.
O recurso deve simplificar o estilo de componentes e aumentar a velocidade de prototipagem para apps React Native.

VirtualView e novas APIs experimentais

A nova API VirtualView promete otimizar o uso de memória dentro de ScrollView, reduzindo o footprint quando o componente não está visível.
Outros recursos experimentais também foram introduzidos, incluindo melhorias em Reanimated v4 e suporte a novas estratégias de lazy loading e codegen.

Conclusão

Com 10 anos completados, o React Native prova que continua evoluindo com força total.
Entre fundações, arquiteturas e novas APIs, o ecossistema mostra que o foco agora é performance, interoperabilidade e colaboração aberta.
Mais do que um framework, o RN se consolida como uma plataforma madura, e pronta pra mais uma década de inovação.

E Ainda tem muito mais por vir:

Usando múltiplas chaves SSH para diferentes contas Git (pessoal e trabalho) sem dor de cabeça

Tulio Calil — Mon, 08 Sep 2025 15:05:39 +0000

Se você tem conta pessoal e de trabalho no Git (ou até freelas), já deve ter sofrido com o SSH misturando as chaves.
A boa notícia é que dá pra resolver de dois jeitos: automático por diretório ou via alias de host.

Automático por diretório (requer OpenSSH 7.3+)

Essa é a forma que eu mais gosto. Só de estar dentro da pasta do projeto, o SSH já sabe qual chave usar.
Mas atenção: funciona apenas no OpenSSH 7.3 ou superior e você precisa separar os projetos por pastas (pessoais em uma e profissionais em outra, por exemplo). Verifique sua versão do SSH com:

ssh -V

Agora vamos a estrutura de pastas, essa parte é fundamental, precisamos de uma pasta para cada chave, atualmente eu uso algo como:

projects/ #vai usar a chave pessoal
 - blog
 - estudos
 - urubu_do_pix
 - work/ # daqui pra frente vai usar a chave do trabalho 
   - projectA
   - projectB

Ou seja, tudo do trabalho fica na pasta ‘work’. Vamos fazer com que o SSH use uma chave pra todos os lugares e troque apenas quando estiver na ‘work’.

Edite o arquivo de configuração no do SSH que fica em ~/.ssh/config:

# Configuração padrão, usa a chave pessoal
Host github.com
  AddKeysToAgent yes
  User git
  # UseKeychain yes   # (se estiver no macOS)
  IdentitiesOnly yes

# Chave para projetos do trabalho
Match exec "[[ $PWD == /home/tulio/projects/work* ]]"
    IdentityFile ~/.ssh/work_key

Match all
  IdentityFile ~/.ssh/my_key

Lembre de trocar os caminhos, tanto das chaves quanto da pasta work.

Com isso, se você fizer um clone, push ou pull em qualquer lugar diferente da pasta ‘work’, ele vai usar a chave pessoal. Na pasta ‘work’, usa a chave do trabalho. Simples assim.

Alternativa: usando aliases de host

Se a sua versão do SSH não suporta Match exec, dá pra resolver usando aliases.
Nesse caso você cria “atalhos” e aponta o git remote para eles.

Edite o ~/.ssh/config:

# Conta pessoal
Host github.com
    HostName github.com
    User git
    IdentityFile ~/.ssh/my_key

# Conta do trabalho
Host work.github.com
    HostName github.com
    User git
    IdentityFile ~/.ssh/work_key

Aqui você pode ser criativo com o alias, pode usar até algo mais curto, como "w" apenas, sem o github.com, basta lembrar que na hora de clonar você terá que colonar com "w" no lugar do "github.com" (git@w:org/project.git)

E na hora do clone basta você adicionar work antes do github, exemplo:

git clone git@work.github.com:...

Caso ja tenha o projeto clonado basta trocar a URL da origin, você pode fazer assim:
Veja a URL atual do repositorio:

git remote -v

Copie a URL e adicione o work na frente e troque com:

git remote set-url origin git@work.github.com:...

Fechando

Hoje eu uso o esquema automático por diretório porque me poupa tempo e evita erro, mas a versão com alias funciona em qualquer lugar e é à prova de falhas.
De qualquer jeito, o resultado é o mesmo: nunca mais push falhando por causa da chave errada.

Você pode repetir a configuração para usar várias chaves, eu utilizei apenas duas para simplificar.

Stop Overpaying: 3 Cheaper Alternatives to DigitalOcean VPS

Tulio Calil — Mon, 09 Jun 2025 18:22:57 +0000

If you're like me, you've probably started a few side projects or small apps and quickly realized that even "affordable" platforms like DigitalOcean can add up fast. In this post, I'll share some cheaper (and sometimes free) alternatives to host your projects without burning your wallet. Let's dive in!

Cloudfnatic (my personal choice)

Price: Starts at $2.99/month
One of the cheapest options out there. Simple UI, Docker support, and fast deployment make it great for small projects on a tight budget.

Hetzner Cloud

Price: Starts at €3.79/month
High-performance VPS with SSD storage, IPv6, and generous bandwidth. EU-based and known for excellent price-to-performance ratio.

Oracle Cloud Free Tier

Price: Free forever
Offers 2 always-free VPS instances with 1 GB RAM. Surprisingly reliable for small apps, bots, or personal projects — and completely free.

These are just a few of the most affordable VPS options I’ve found while trying to cut costs without sacrificing flexibility. If you know any other hidden gems or have experience with the ones listed here, drop a comment below — I'd love to hear your thoughts, tips, or even horror stories. Let's help each other host smarter! 🚀

Node.Js on Windows in 2023 - Tools and tricks

Tulio Calil — Sun, 05 Nov 2023 20:12:15 +0000

In 2023, Node.js continues to be a game-changer in the world of web development, and for Windows users, harnessing its potential efficiently is more crucial than ever. Whether you're a seasoned Node.js developer or just embarking on your coding journey, this post is your essential guide to mastering Node.js on the Windows platform. We'll delve into the tools and tricks that can enhance your development experience, making it smoother and more productive. Get ready to turbocharge your Node.js journey and make the most of your Windows environment!

WSL 2

Windows Subsystem for Linux 2 (WSL 2) is a technology that allows you to run a full Linux kernel on your Windows machine. It offers improved performance and compatibility compared to its predecessor, WSL 1, making it a valuable tool for developers who need to work with Linux-based software on their Windows systems. WSL 2 seamlessly combines the Windows and Linux environments, providing a versatile solution for development tasks.

To install it open the Windows Powershell and run:

wsl --install

After installing reboot your PC.

Remember to enable virtualization on your BIOS.

Now open the Microsoft Store and search for Ubuntu(or any other Linux distro supported by WSL), click on install.

Windows Terminal

Windows Terminal is a modern and powerful command-line interface for Windows that offers a more versatile and user-friendly experience for developers and system administrators. It consolidates various command-line tools, shells, and scripts into a single application, enabling you to work with PowerShell, Command Prompt, and even Linux distributions through WSL.

Search on Microsoft Store and install it (maybe it is already on your system).

Oh My Zsh

Zsh, short for Z Shell, is a highly customizable and powerful command-line shell that serves as an excellent alternative to the default shells like Bash or PowerShell. With a user-friendly and feature-rich environment, Zsh is popular among developers and power users for its extensive plugin support, auto-completion, and a plethora of productivity-enhancing features.

To install it, open the Windows terminal click on the dropdown arrow, and select Ubuntu.

Now we are in a Linux! Maybe it take a while for the first time, then will ask you for a username and a password. When finished we will see or prompt ready, let's install the ZSH and OMZ:

 sudo apt install zsh

When ask for your password type it and hit enter.

Now install the OMZ:

sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

The script will ask to change the default shell, type "y" and hit enter.

Shell font

We need some custom font to use with our shell theme, the new font will support some "icons" to improve the experience (really?).

You can get one here, I recommend the Cascadia Code.

After downloading, extract it and double-click to install.

Starship

Starship is a sleek and highly customizable command-line prompt that enhances your shell experience by providing a visually appealing and informative prompt. It's designed to work with various shells, including Bash, Zsh, Fish, and PowerShell, and offers a wide range of features to make your command-line interactions more efficient and enjoyable.

To install run this command:

curl -sS https://starship.rs/install.sh | sh

Type "y" and hit enter when asked, after:

eval "$(starship init zsh)"

Now you can get a preset or a theme or even create one, just check the documentation here

Node.js

Let's install Node.js but we will use the nvm, which is a Node version manager, so you can install any version of Node.js with no problems or conflicts.

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.5/install.sh | bash

source ~/.zshrc

Now, to install the LTS version:

nvm install --lts

Change "--lts" for a specific version number if you want

Conclusion

Now you are ready to go! Pick your favorite code editor and go on!
I recommend the Visual Studio Code cause it has an awesome integration with WSL system.

Aumente as Conversões na Black Friday: Estratégia ASO & Ícone Dinâmico no React Native

Tulio Calil — Thu, 02 Nov 2023 22:09:00 +0000

Foto de CardMapr.nl na Unsplash

Bem-vindo ao mundo da Black Friday, a época do ano em que consumidores estão ávidos por ofertas incríveis, e as empresas estão ansiosas para maximizar suas vendas. Para ter sucesso nesse cenário altamente competitivo, cada detalhe do seu aplicativo móvel desempenha um papel crucial. E uma maneira eficaz de se destacar é personalizar a experiência do usuário, até mesmo os detalhes aparentemente pequenos, como o ícone do seu aplicativo.

O sucesso de um aplicativo móvel vai além da sua funcionalidade e design. É preciso garantir que ele seja facilmente descoberto por seu público-alvo, e a Estratégia ASO (App Store Optimization) é a chave para isso. O ASO envolve um conjunto de técnicas voltadas para a otimização da presença de um aplicativo nas lojas de aplicativos, como a App Store e o Google Play. Desde a escolha de palavras-chave estratégicas até a criação de títulos cativantes e imagens atraentes, o ASO é uma parte essencial do marketing de aplicativos que pode impulsionar o número de downloads, melhorar a classificação nas listas de resultados e aumentar a visibilidade do seu aplicativo.

Neste post, vamos explorar uma estratégia de diferenciação que pode impulsionar suas conversões na Black Friday: a capacidade de alterar dinamicamente os ícones do seu aplicativo React Native. Vamos mergulhar fundo nesse processo, fornecendo a você as ferramentas e conhecimentos necessários para atrair a atenção dos consumidores, destacar-se da concorrência e aumentar as conversões durante a Black Friday. Prepare-se para uma jornada de personalização e sucesso nesta temporada de compras intensas.

ASO

Sabendo que ASO é um "SEO para mobile" vamos então entender alguns pontos que podemos e devemos olhar nesse período de Black Friday para atrair ainda mais usuários para o nosso funil de conversão.

Palavras-chave: sempre inclua palavras-chave na descrição, títulos e metadados da sua aplicação. Isso faz com que os mecanismos de busca incorporem essas informações e ajude seu aplicativo aparecer entre os primeiros resultados.
Título e descrição: você já percebeu como aplicativos como Shopee e Aliexpress mudam constantemente o título deles nas lojas acompanhando os eventos do mercado? Isso também é uma técnica ASO.
Ícones e imagens: use imagens e ícones que acompanhe as ações comerciais e principalmente com qualidade alta e no formato certo, nada de reciclar imagens de outros formatos ou utilizar capturas de tela quaisquer.

Ícones no React Native, mude sem atualizar

Você já deve ter percebido que um app simplesmente mudou de ícone no seu smartphone e você não o percebeu atualizando, aplicativos super famosos fazem isso o tempo todo, não apenas para BF, mas para eventos até exclusivos como Prime Day, 11.11, e outros.

Isso é uma técnica super simples, mas muito eficaz, onde você pode trocar o ícone do aplicativo sem precisar de um deploy para isso, você pode ter vários ícones lá dentro e utilizar a técnica de Feature Toggle para controlar qual o ícone será exibido no período que você desejar.

Configurar um ícone no React Native é algo muito simples, conta com passos nativos apenas, logo tudo que você tem que fazer é ter uma imagem para ser utilizada como ícone e adapta-la a diversos formatos para cada plataforma, felizmente existem várias ferramentas para isso hoje em dia, Appicon talvez seja a mais famosa.
Eu utilizei o Icon Kitchen para gerar um ícone do zero e configurei, ficando assim:

Então como eu quero um novo icone para Black Friday eu utilizei novamente o Icon Kitchen para criar um icone seguindo os padrões recomendados (sim, existe normatização para ícones em mobile) e cheguei nesse resultado:

Eu quis trazer uma mensagem bem simples; estamos participando da BF (e por isso o fundo preto) e temos descontos de 70%.

Agora vamos à implementação, podemos fazer isso de forma nativa e criando uma ponte entre o código nativo e o RN, não é algo tão difícil, mas para economizar nosso tempo e não reinventar a roda vamos utilizar uma biblioteca pronta e já madura no mercado: react-change-icon.

Adicione a nova dependência ao seu projeto:

yarn add react-native-change-icon
# ou
npm i react-native-change-icon

Para iOS rode o pod install na pasta ios.

E agora é só seguir os passos da própria documentação para implementar, lembre-se de mudar o nome do ícone antes de copiar os arquivos para as pastas nativas de cada plataforma (Android e iOS).

Após toda configuração podemos controlar o ícone da aplicação usando a função changeIcon(), ela aceita um parâmetro que é o nome do ícone da forma que configuramos nativamente, logo, para mudar para o ícone da BF eu chamaria:

changeIcon("BlackFriday");

Porém, isso ainda deixa nosso codigo um pouco estatico, e para resolver isso temos varias formas, uma delas seria criar ifs para datas específicas, algo como 15 dias antes da BF eu chamar a função passando o novo ícone, mas isso também não é legal, vamos utilizar o conhecimento do post de Feature Toggle para buscar essa regra remotamente, permitindo que a gente mude isso sem grandes problemas.

Um exemplo bem simples de codigo para isso acontecer:

async function checkIcon() {
    // Busca remotamente o icone que deve ser utilizado
    const toggleResponse = await fetch(
      'https://minhaapi.com.br/features/app-icon',
    );

    // Um object literal para armazenar os possiveis icones
    // já existentes no app
    const icons = {
      blackFriday: 'BlackFriday',
      christmas: 'Christmas',
      default: 'Default',
    };

    const iconToggle = await toggleResponse.json();
    // Busca qual o icone esta sendo usado
    const actualIcon = await getIcon();

    // Verifica retorna o nome do icone, caso não exista retorna default
    const newIcon = icons[iconToggle.iconTheme] || 'Default';

    // Se o icone do servidor for igual o atual, não fazemos nada
    if (actualIcon === newIcon) {
      return;
    }

    // Troca o icone
    changeIcon(newIcon);
  }

  useEffect(() => {
    checkIcon();
  }, []);

Lembre-se de que para mandar um icone, ele precisa existir previamente no aplicativo, então você ainda precisa se planejar pois precisará de um deploy, porém pode fazer com muita antecedência.

Dessa forma buscamos assim que o app iniciar a informação de qual ícone devemos exibir, caso seja diferente do exibido atualmente nós trocamos. É possível também ouvir o retorno da função de troca, para caso venha um ícone que não exista seja feito um reset para o ícone padrão.
O resultado disso tudo:

Confira o GIF do fluxo simulando uma situação real:

Na esquerda o backend, no meio o codigo e o terminal e na direita o simulador de iOS.

Conclusão

Todo o conceito desse post pode ser aplicado em qualquer outro framework ou linguagem, não se prenda apenas ao exemplo em código do React Native aqui.

Gostou desse conteúdo e quer que eu traga mais técnicas de ASO e assuntos de React Native? Comenta aqui embaixo!

Compartilhe esse contéudo com amigos e nas suas redes, você ajuda muito!

Bridging the Gap Between Developers and QA Testers with Maestro

Tulio Calil — Sun, 29 Oct 2023 14:04:45 +0000

Maestro is a mobile UI testing framework, very simple and effective. It's an alternative to other frameworks like Appium, Espresso, UIAutomator or XCTest and is built on top of the knowledge from its predecessors.

Maestro doesn't depend on any mobile framework, so you can run it in React Native apps, Native Android or iOS, Flutter, Ionic, Native Script, etc.
It doesn't need a special app package too, you can use it even in a production/release build.

The best points of Maestro are:

Simple setup.
Declarative syntax.
Fast iteration.
Built-in tolerance delay and flakiness.

Installing

The Maestro documentation is complete and covers installing steps for the specific OS; Macos, Windows and Linux.

To install the Maestro CLI:

curl -Ls "https://get.maestro.mobile.dev" | bash

Don't forget to add the Maestro to PATH variable.

Now we can check if the Maestro is successfully working:

maestro -v

Creating a sample Flow

Start your Android or iOS emulator/simulator, create a new folder for store our files, and open it in your favorite code editor:

For this sample, let's write a simple flow to open the "Maps" app and search for a city, click to change the view from 2D to 3D, and change the map type to Satellite.

Open the Maps before write/run this test, maybe you will be asked to give some permissions. I don't put this on the flow (but is possible) cause I want a clean example.

In your editor or terminal create a new file maps-flow.yml and let's start to write the instructions.

In the first line, we got:

appId: com.apple.Maps

This appId is for iOS, if you are running android change it to com.google.android.apps.maps

This is the first line for every flow that we write, it tells Maestro what application we want to manipulate.
The first lines in the Maestro flow file are the configuration part, in fact, the configuration part is all the lines above the --- marker(we will use this in the next part).
We can set the configuration in the flow file (like we see right now) or in a root config.yml file in the folder.

On the properties, we can for example run flow before the current in case we need any setup steps or somelike that.
You can check all the properties here.

So using the name and appId properties our config part looks like this:

appId: com.apple.Maps
name: Maps Test
---

Here we use the marker --- to tell the Maestro that above is the config and below is your workflow.

Now let's write the commands flow, before any command in the app we need to open the app, and for that, we use the launchApp command.

Command is the name of actions(the properties in the YML) that we got in Maestro.

appId: com.apple.Maps
name: Maps Test
---
  - launchApp

Note that have a space on the line of the command launchApp, this is how YML files work, we need indent to nesting. If it is not clear, you can read about YML before starts.

The launchApp command accepts other params too, you can launch another app, clear the state, give or not permissions, and more.
All the commands got a really good doc.

Now we can test the flow, in the terminal run:

maestro test maps-flow.yml

Sometimes it takes some time to install the maestro-drive in the device in the first run.

If all is right we will see the following output:

Let's put one more command:

appId: com.apple.Maps
name: Maps Test
---
  - launchApp
  - tapOn: "Search Maps"

🚩 For Android emulator change the tapOn to "Search here".

The tapOn command tells the Maestro to tap/touch/click on a view/component/element that matches with the selector that we pass. By default we can pass a string as an argument, this means that Maestro will look for a view that has this EXACLTY text. It's very useful when you don't know or the application doesn't use things like test-id.
But like always we can pass any other option, in this case, other selectors.

In Maestro we got a lot of selectors, text, id, point (relative position in the screen), and more. All selectors are documented here.
Right now the text selector is the best option for us.

We tap on the search field, and putting some text is the next step, right?

appId: com.apple.Maps
name: Maps Test
---
  - launchApp
  - tapOn: "Search Maps"
  - inputText: "Salvador, Bahia, Brazil"

Now we type some text in the field, the inputText command has some random generators too, you can see it on the docs.
Now that we have typed the text let's confirm the search and seed the result:

appId: com.apple.Maps # android = com.google.android.apps.maps 
name: Maps Test 
---
  - launchApp
  - tapOn: "Search Maps" # android = Search here
  - inputText: "Salvador, Bahia, Brazil"
  - pressKey: Enter

If we want we can swipe the info modal, just add and test:

  - swipe:
      start: 50%, 80%
      end: 50%, 10%

Using parameters

We are changing some values between OS, for iOS we using the appId "com.apple.Maps" and for Android "com.google.android.apps.maps". In this case, we can turn this flow generic for each OS using parameters.

With parameters is possible to change the fixed values in the file for variables that will be read from the CLI arguments or from environment variables. Just a refactor in our file:

appId: ${APP}
name: Maps Test 
---
  - launchApp
  - tapOn: ${FIELD}
  - inputText: "Salvador, Bahia, Brazil"
  - pressKey: Enter
  - swipe:
      start: 50%, 80%
      end: 50%, 10%

Now appId is the value of APP and tapOn is FIELD, to set this value just run the Maestro CLI this way:

For Android test:

maestro test -e APP=com.google.android.apps.maps -e FIELD="Search here"  maps-flow.yaml

For iOS test:

maestro test -e APP=com.apple.Maps -e FIELD="Search Maps"  maps-flow.yaml

We can use parameters for multiple things, if you have a secret (like a password) and don't want to store this in the YML file or if this value is dynamic and you need to get a new one every running for example.

Recording and report

You may need to get some evidence that all tests are passing, maybe a video or a report or both. Maestro has a built-in solution for the two cases.

Recording

Maestro records the mobile screen and creates a virtual window to show the test state and formats it to mp4, actually the rendering is done in the server and when the render is done you get a temporary URL to download the video.

To record the video is ultra simple, just change test to record in the CLI:

maestro record -e APP=com.google.android.apps.maps -e FIELD="Search here"  maps-flow.yaml

The output:

Report

Maestro can generate reports for test suites, in this case, we just got one test but we can generate the report too.
Like the record, the report is very simple too, just add a new argument in the CLI:

 maestro test --format junit -e APP=com.google.android.apps.maps -e FIELD="Search Here"  maps-flow.yaml

The --format junit will generate an xml file in the root with the status of the tests, actually the only supported format is Junit. You can change the output path using the --output argument.

Copy and past the xml content here

Conclusion

Maestro is an awesome framework and we use it a lot at my current company, GOK.

This is just the first post of a series about Maestro, I will bring real-world examples and advanced concepts in the next posts, so check my personal blog and stay updated with new posts!

React Native Debugging Native Code

Tulio Calil — Tue, 24 Oct 2023 16:34:58 +0000

In the world of React Native development, a single debugging tip can make all the difference. Join us as we uncover a valuable insight to streamline your debugging process. This tip will save you time and ensure your apps run smoothly. Let's dive right in!

So run your application using the React Native CLI and attach the native debugger of the native IDE (Android Studio or Xcode) to the process.

Android Studio

On Android Studio you can do this by going on the "Run" option on the menu bar, clicking on "Attach to Process..." and selecting the running React Native app.

Xcode

On Xcode click on "Debug" on the top menu bar, select the "Attach to process" option, and select the application in the list of "Likely Targets".

Now you can put breaking points in your native code and tada 🥳!

I added these instructions in the React Native official docs too you can check the PR status here.

Follow-me for more content about React Native.

Offline auth with Electron + SQLite + React

Tulio Calil — Wed, 13 Sep 2023 17:08:23 +0000

In an increasingly digital world, the need for secure and robust authentication systems is paramount. Whether you're building a desktop application, a mobile app, or a web platform, the ability to authenticate users reliably and securely is a fundamental requirement. While online authentication methods are well-established and widely adopted, there are situations where offline authentication becomes essential. This is particularly true for desktop applications, where internet connectivity is not always guaranteed.
In this article, we dive into the world of "Offline Authentication" and explore a powerful combination of technologies to achieve this goal: Electron, SQLite, and React. By leveraging the capabilities of Electron, a framework for building cross-platform desktop applications, and harnessing the flexibility of SQLite, a lightweight and embedded database engine, we'll create a robust offline authentication system. To top it off, we'll enhance the user experience by incorporating the user-friendly React library for building the application's front end.
Offline authentication isn't just about enabling access when the internet is down; it's about providing users with a seamless and secure experience, even when disconnected. Whether you're developing a stand-alone desktop application or a part of a broader software ecosystem, the techniques and principles we'll explore here will empower you to create reliable offline authentication solutions that protect user data and ensure a smooth user experience.
Let's embark on this journey to learn how to implement offline authentication with Electron, SQLite, and React, and unlock new possibilities for your desktop applications.Login and Signup pages

First, we will use the last Electron post to start this new one. You can clone the repository on Github:GitHub - tuliocll/electron-react-sqlite-todo: A TODO app with Auth built with Electron, ReactJS and SQLite
A TODO app with Auth built with Electron, ReactJS and SQLite - GitHub - tuliocll/electron-react-sqlite-todo: A TODO app with Auth built with Electron, ReactJS and SQLite
https://github.com/tuliocll/electron-react-sqlite-todo

Check the full post here