A janela do Windows possui bordas, barra de título e outros elementos que não fazem parte da área real de desenho.

Para um jogo, normalmente queremos o tamanho interno da janela. Ou seja, a área onde nossos pixels realmente serão exibidos.

Para isso usamos GetClientRect.

RECT client_rect;
GetClientRect(hwnd, &client_rect);

int width  = client_rect.right - client_rect.left;
int height = client_rect.bottom - client_rect.top;

O RECT possui quatro campos:

• left: posição inicial no eixo X;
• top: posição inicial no eixo Y;
• right: posição final no eixo X;
• bottom: posição final no eixo Y.

Como estamos usando GetClientRect, normalmente left e top serão zero. Mesmo assim, calcular right - left e bottom - top deixa a intenção explícita.

Faremos essa consulta quando a janela for criada e também quando ela for redimensionada. Se o usuário muda o tamanho da janela, o nosso buffer antigo não representa mais o tamanho correto da tela. Logo, precisamos destruir o bitmap antigo e criar outro.

O bloco principal deste artigo é a função abaixo.

internal HBITMAP bitmap_handle;
internal void *bitmap_memory;
internal BITMAPINFO bmi;

internal void
create_back_buffer(int width, int height)
{
    if (bitmap_handle) {
        DeleteObject(bitmap_handle);
        bitmap_handle = NULL;
        bitmap_memory = NULL;
        printf("Delete memory!\n");
    }

    assert(width > 0);
    assert(height > 0);

    bmi.bmiHeader.biSize = sizeof(BITMAPINFOHEADER);
    bmi.bmiHeader.biWidth = width;
    bmi.bmiHeader.biHeight = -height;
    bmi.bmiHeader.biPlanes = 1;
    bmi.bmiHeader.biBitCount = 32;
    bmi.bmiHeader.biCompression = BI_RGB;

    bitmap_handle = CreateDIBSection(NULL,
                                     &bmi,
                                     DIB_RGB_COLORS,
                                     &bitmap_memory,
                                     NULL,
                                     0);

    printf("Create memory!\n");

    if (!bitmap_handle) {
        // TODO(tiago): handle error with GetLastError.
        printf("Failed to Create Bitmap Handle\n");
        return;
    }

    unsigned int *memory = (unsigned int *)bitmap_memory;
    for (int y = 0; y < height; y++) {
        for (int x = 0; x < width; x++) {
            *memory = (unsigned int)(0 << 16 | (unsigned char)y << 8 | (unsigned char)x);
            memory++;
        }
    }
}

Aqui estamos criando um bitmap de 32 bits por pixel. Cada pixel ocupa 4 bytes na memória.

O valor escrito no loop final gera um gradiente simples. Ele não é o desenho definitivo do jogo. É apenas uma maneira rápida de confirmar se a memória foi criada corretamente e se conseguimos enxergar alguma coisa na tela.

DIB significa Device Independent Bitmap.

Ou seja, é um bitmap independente de dispositivo. Ele não pertence a uma janela específica, nem a um monitor específico, nem ao HWND.

Essa parte é importante porque pode parecer estranho chamar CreateDIBSection sem passar o HWND e sem chamar GetDC antes.

Mas para esse caso não precisamos disso.

bitmap_handle = CreateDIBSection(NULL,
                                 &bmi,
                                 DIB_RGB_COLORS,
                                 &bitmap_memory,
                                 NULL,
                                 0);

O primeiro parâmetro é um HDC. Estamos passando NULL porque queremos criar um bitmap independente usando as informações do BITMAPINFO.

Como estamos usando:

• biBitCount = 32;
• biCompression = BI_RGB;
• DIB_RGB_COLORS;

o Windows tem informação suficiente para criar a memória de pixels sem depender do formato de uma janela.

O parâmetro HDC existe principalmente para casos em que o formato depende do dispositivo, paletas antigas, gerenciamento de cores e outros cenários onde o contexto de desenho influencia a criação do bitmap.

Para um back buffer simples de jogo, em 32 bits, ele pode ficar como NULL.

Visualmente, podemos pensar assim:

HBITMAP
    |
    v
+----------------+
| Pixel Memory   |
|                |
| 0x00RRGGBB     |
| 0x00RRGGBB     |
| 0x00RRGGBB     |
+----------------+

O CreateDIBSection devolve duas coisas importantes:

• um HBITMAP, que é o handle usado pelo GDI;
• um ponteiro em bitmap_memory, que é onde podemos escrever os pixels diretamente.

Essa combinação é exatamente o que queremos para renderização por software.

O nosso código escreve em memória normal, usando ponteiro. Depois o Windows consegue usar o HBITMAP e o BITMAPINFO para entender como copiar esses pixels para a janela.

HBITMAP é um handle para um objeto de bitmap do GDI.

Um handle não é o objeto em si. Ele é um identificador opaco que o Windows devolve para o programa. Com esse identificador, podemos pedir para a API operar naquele recurso.

Por exemplo:

HBITMAP bitmap_handle = CreateDIBSection(...);

O tipo HBITMAP não deve ser tratado como um ponteiro para os pixels. Os pixels estão no bitmap_memory.

Essa diferença é essencial:

• HBITMAP: identifica o objeto de bitmap para o GDI;
• bitmap_memory: aponta para a memória real dos pixels.

Então, para desenhar manualmente, escrevemos em bitmap_memory. Para liberar o recurso do GDI, usamos DeleteObject(bitmap_handle).

if (bitmap_handle) {
    DeleteObject(bitmap_handle);
    bitmap_handle = NULL;
    bitmap_memory = NULL;
}

Após chamar DeleteObject, o ponteiro bitmap_memory não deve mais ser usado. Ele apontava para a memória associada ao objeto destruído.

Por isso eu limpo os dois valores.

A Win32 API usa muitos tipos que começam com H.

Esse H normalmente significa handle.

Alguns exemplos comuns:

• HWND: handle para uma janela;
• HDC: handle para um Device Context;
• HBITMAP: handle para um bitmap do GDI;
• HMODULE: handle para um módulo carregado no processo;
• HINSTANCE: historicamente representa uma instância da aplicação, hoje costuma ser equivalente a um HMODULE em muitos contextos.

Apesar de todos serem handles, eles não representam a mesma coisa.

Um HWND identifica uma janela. Você usa esse handle com funções como GetClientRect, DestroyWindow ou GetDC.

Um HDC identifica um contexto de desenho. O GDI desenha através de um DC. Ele guarda o estado de desenho: superfície alvo, brush, pen, fonte, região de clipping e outras configurações.

Um HBITMAP identifica um bitmap. Ele pode ser selecionado em um DC de memória ou usado em operações de cópia, dependendo da função.

Um HMODULE identifica um módulo carregado no processo, como o próprio executável ou uma DLL. Ele é usado para encontrar recursos, endereços de funções e informações do módulo.

Portanto, mesmo que por baixo dos panos muitos handles sejam implementados como ponteiros ou valores numéricos, você não deve misturá-los.

Isto estaria conceitualmente errado:

HMODULE module = (HMODULE)bitmap_handle; // errado

O compilador pode até aceitar um cast forçado, mas a API não vai interpretar corretamente. Um HBITMAP pertence ao mundo de objetos GDI. Um HMODULE pertence ao carregador de módulos do processo.

O tipo do handle comunica qual subsistema do Windows entende aquele valor.

Em resumo:

HWND     -> janela
HDC      -> contexto de desenho
HBITMAP  -> bitmap do GDI
HMODULE  -> executável ou DLL carregada
HINSTANCE -> instância/módulo da aplicação

A estrutura BITMAPINFO descreve como os pixels devem ser interpretados.

bmi.bmiHeader.biSize = sizeof(BITMAPINFOHEADER);
bmi.bmiHeader.biWidth = width;
bmi.bmiHeader.biHeight = -height;
bmi.bmiHeader.biPlanes = 1;
bmi.bmiHeader.biBitCount = 32;
bmi.bmiHeader.biCompression = BI_RGB;

Vamos por partes.

Depois que o CreateDIBSection cria a memória, podemos escrever nela.

unsigned int *memory = (unsigned int *)bitmap_memory;
for (int y = 0; y < height; y++) {
    for (int x = 0; x < width; x++) {
        *memory = (unsigned int)(0 << 16 |
                                 (unsigned char)y << 8 |
                                 (unsigned char)x);
        memory++;
    }
}

Como cada pixel tem 32 bits, fazemos o cast para unsigned int *.

Assim, cada incremento em memory++ avança 4 bytes, ou seja, um pixel inteiro.

O valor do pixel está sendo montado com deslocamento de bits:

0 << 16              // vermelho
(unsigned char)y << 8 // verde
(unsigned char)x      // azul

O cast para unsigned char conserva apenas um byte do valor. Na prática, cada canal fica entre 0 e 255.

Para um teste visual, isso é suficiente.

Quando a janela muda de tamanho, precisamos recriar o back buffer.

No callback da janela, podemos fazer isso em WM_SIZE.

case WM_SIZE: {
    RECT rect;
    GetClientRect(hwnd, &rect);

    int width  = rect.right - rect.left;
    int height = rect.bottom - rect.top;

    if (width > 0 && height > 0) {
        create_back_buffer(hwnd, 0, 0, width, height);
    }
} break;

Antes de criar o novo bitmap, a função destrói o anterior:

if (bitmap_handle) {
    DeleteObject(bitmap_handle);
    bitmap_handle = NULL;
    bitmap_memory = NULL;
}

O CreateDIBSection cria um objeto GDI. Portanto, a função correta para liberar esse recurso é DeleteObject.

Não use free em bitmap_memory. Essa memória pertence ao objeto criado pelo GDI.

Criar a DIBSection é só metade do processo.

Para enxergar os pixels, precisamos copiar o buffer para o HDC da janela. Podemos fazer isso no WM_PAINT.

internal void
update_window(HDC hdc, int x, int y, int width, int height)
{
    StretchDIBits(hdc,
                  x, y, width, height, // dst
                  x, y, bmi.bmiHeader.biWidth, -bmi.bmiHeader.biHeight, // src
                  bitmap_memory,
                  &bmi,
                  DIB_RGB_COLORS,
                  SRCCOPY);
}

StretchDIBits copia os pixels de uma DIB para um HDC.

O nome começa com Stretch porque ela também pode redimensionar a imagem durante a cópia. Se o tamanho de origem e destino forem iguais, ela apenas copia.

Podemos chamar essa função durante o WM_PAINT:

case WM_PAINT: {
    PAINTSTRUCT paint;
    HDC hdc = BeginPaint(hwnd, &paint);

    RECT client_rect;
    GetClientRect(hwnd, &client_rect);

    int width  = client_rect.right - client_rect.left;
    int height = client_rect.bottom - client_rect.top;

    update_window(hdc, 0, 0, width, height);

    EndPaint(hwnd, &paint);
} break;

Neste ponto, ainda estamos desenhando apenas quando o Windows pede uma repintura ou quando a janela muda de tamanho.

Mais adiante, em um jogo, o normal será:

1. processar input;
2. atualizar o estado do jogo;
3. renderizar no back buffer;
4. copiar o back buffer para a janela.

Esse ciclo acontece dentro do loop principal.

Um detalhe que costuma confundir: o GDI desenha através de HDC.

O HDC representa um contexto de desenho. Ele não é apenas uma janela e também não é apenas uma imagem. Ele é uma estrutura que guarda o alvo e o estado do desenho.

Quando usamos BeginPaint, recebemos um HDC associado à janela:

HDC hdc = BeginPaint(hwnd, &paint);

Quando usamos CreateCompatibleDC, criamos um DC em memória:

HDC memory_dc = CreateCompatibleDC(NULL);

Esse DC em memória pode ter um bitmap selecionado nele com SelectObject.

Para este artigo, o caminho mais direto é usar StretchDIBits com o ponteiro bitmap_memory e o BITMAPINFO. Assim não precisamos criar um DC de memória ainda.

Com CreateDIBSection conseguimos criar um back buffer simples para renderização por software no Windows.

O ponto principal é entender que existem duas visões do mesmo recurso:

• o HBITMAP, usado pelo GDI como handle do bitmap;
• o bitmap_memory, usado pelo nosso código para escrever pixels diretamente.

O bitmap não pertence à janela. Ele é independente. A janela entra no processo apenas quando copiamos a memória para o HDC dela usando StretchDIBits.

Esse é o primeiro passo para desenhar o jogo manualmente. Daqui em diante, a renderização deixa de ser uma chamada como PatBlt e passa a ser uma escrita direta nos pixels.

• Buscar o tamanho da janela com GetClientRect
• Criar o back buffer com as definições do BITMAPINFO
• Gerar pixels de teste no bloco de memória
• Fazer o blit na janela com StretchDIBits

O primeiro passo é criar uma WindowClass, uma struct chamada WNDCLASS.

Essa struct precisa de uma função de callback para lidar com tarefas relacionadas à janela, incluindo eventos de teclado.

Precisamos registrar essa struct para criar uma janela corretamente.

Vamos ver o código:

int CALLBACK
WinMain(HINSTANCE instance,
        HINSTANCE prev_instance,
        LPSTR cmd_line,
        int show_cmd)
{
        WNDCLASSA window_class = {};
        window_class.style         = CS_VREDRAW|CS_HREDRAW|CS_OWNDC;
        window_class.lpfnWndProc   = window_callback;
        window_class.hInstance     = instance;
        window_class.lpszClassName = "GameClassName";
        // window_class.hIcon   -> load icon
        window_class.hCursor       = LoadCursor(NULL, IDC_ARROW); 

        if (!RegisterClassA(&window_class)) {
            printf("Failed to Register Class A\n");
            return 1;
        }
}

Os pontos principais são:

• style: informações em bits que determinam como a janela opera;
• lpfnWndProc: uma função, que vamos criar depois, para lidar com eventos da janela como redimensionar, criar, destruir, etc;
• hInstance: handle da instância da aplicação;
• lpszClassName: nome da classe da janela;
• CS_VREDRAW: redesenha a janela verticalmente, se necessário, quando o tamanho muda;
• CS_HREDRAW: redesenha a janela horizontalmente, se necessário, quando o tamanho muda;
• CS_OWNDC: aloca apenas um DeviceContext para a janela. O Windows usa o DC para manter o estado do desenho enquanto desenhamos na janela. Inicialmente, ele foi pensado para ser usado junto com brushes. Normalmente, o Windows teria vários device contexts disponíveis. Quando um programa precisa desenhar, ele pega um, usa e depois devolve;
• RegisterClassA: função necessária para a janela funcionar corretamente.

Também podemos obter o handle da instância chamando GetModuleHandle(NULL).

A função OutputDebugStringA serve como saída padrão para o modo de debug, visível apenas dentro do Visual Studio. Se você precisar ver a saída no console, troque pela função printf do arquivo stdio.h, que faz parte da biblioteca padrão de C.

No começo do código, definimos o estilo da classe da janela assim:

window_class.style = CS_VREDRAW|CS_HREDRAW|CS_OWNDC;

Esses valores são flags. Uma flag é como uma opção de configuração que podemos ligar ou desligar.

O operador | combina várias flags em um único valor. Então essa linha está dizendo: "quero uma janela com CS_VREDRAW, CS_HREDRAW e CS_OWNDC ligados ao mesmo tempo".

CS_OWNDC faz com que cada janela criada a partir dessa classe tenha seu próprio Device Context.

O Device Context, ou DC, é uma estrutura que o Windows usa para guardar o estado de desenho: onde desenhar, quais configurações estão sendo usadas, qual superfície está recebendo o desenho, entre outras informações.

Sem CS_OWNDC, o Windows pode emprestar um DC temporário para o programa quando ele precisa desenhar e depois pegar esse DC de volta. Isso é suficiente para muitos programas comuns.

Com CS_OWNDC, a janela fica com um DC próprio. Para jogos, isso costuma ser útil porque desenhamos com muita frequência e queremos uma relação mais direta e estável com a superfície da janela.

Neste ponto do código, ainda estamos apenas pintando a janela com preto. Mas essa configuração prepara o terreno para os próximos passos, como criar um back buffer e atualizar a tela do jogo continuamente.

Vamos criar o handle da janela antes de definir a função de callback.

HWND window_handle = CreateWindowA(
    window_class.lpszClassName,
        "Game!",
        WS_OVERLAPPEDWINDOW|WS_VISIBLE,
        CW_USEDEFAULT,
        CW_USEDEFAULT,
        960,
        540,
        NULL,
        NULL,
        instance,
        NULL);

if (!window_handle) {
    printf("Failed to Create Window A\n");
    return 1;
}

Os três parâmetros principais são o nome da classe windowClass.lpszClassName, o título da janela e a própria instância.

CW_USEDEFAULT é usado para substituir as coordenadas (x, y) por um valor padrão baseado na tela do usuário.

Veja a documentação para entender quais são os outros parâmetros e como usá-los, se precisar.

Agora vamos ver como implementar a função de callback.

LRESULT CALLBACK
main_window_callback(HWND hwnd,
                     UINT message,
                     WPARAM lparam,
                     LPARAM wparam)
{
    LRESULT result = 0;
    switch (message) {
        case WM_CREATE: {
            OutputDebugStringA("Window Created.\n");
        } break;

        case WM_PAINT: {
            PAINTSTRUCT paint;
            HDC device_handle = BeginPaint(hwnd, &paint);

            LONG width  = paint.rcPaint.right - paint.rcPaint.left;
            LONG height = paint.rcPaint.bottom - paint.rcPaint.top;

            PatBlt(device_handle, 0, 0, width, height, BLACKNESS);

            EndPaint(hwnd, &paint);
        } break;

        case WM_CLOSE: {
            DestroyWindow(window);
        } break;

        case WM_DESTROY: {
            PostQuitMessage(0);
        } break;

        default: {
            result = DefWindowProcA(hwnd, message, lparam, wparam);
        }
    }
    return result;
}

O callback devolve parâmetros meio genéricos. Quero dizer: para cada situação da janela, conseguimos obter valores específicos com base nos eventos.

Esses valores ficam dentro de WPARAM e LPARAM.

No futuro vamos utilizar esses parâmetros para processar eventos de mensagens do teclado.

O último parâmetro da função CreateWindow é um ponteiro void onde podemos definir valores e recuperá-los de LPARAM durante o estado WM_CREATE.

O próximo passo é traduzir e despachar mensagens da fila de mensagens.

Essas mensagens incluem mensagens da janela, entrada do teclado, entrada do mouse e outras.

Vamos usar PeekMessage para recuperar mensagens da fila.

Claro, precisamos executar todo esse processo dentro de um loop principal controlado por uma variável booleana. Caso contrário, a janela vai piscar e fechar instantaneamente.

Eu declaro essa variável booleana com o nome should_quit.

A variável está no escopo global e é declarada com a palavra-chave static.

O significado de static varia dependendo do contexto em que aparece.

Por exemplo, se static é usado em uma variável de escopo local, ela se comporta como uma variável local persistente.

Quando usado em uma função, restringe a função ao arquivo da unidade de tradução. Em outras palavras, ela se torna uma função internal.

Vamos olhar o código:

No topo do arquivo, temos uma variável global chamada should_quit.

static bool should_quit;

Agora abaixo do arquivo:

static void process_message_queue() {
    MSG msg;
    while(PeekMessageA(&msg, NULL, 0, 0, PM_REMOVE)) {
        if (msg.message == WM_QUIT) {
            should_quit = true;
        } 
        TranslateMessage(&msg);
        DispatchMessageA(&msg);
    }
}

Dentro da função principal, temos:

// ...
while(!should_quit) {
    process_message_queue();
}

OutputDebugStringA("end program!\n");

return 0;

Lendo o código, podemos observar que a função PeekMessageA preenche a struct Message para nós e, se essa struct não for zero, processamos a mensagem.

Quando o usuário clica no botão de fechar, o callback da janela lida com a mensagem WM_CLOSE. Dentro desse bloco, chamamos DestroyWindow, que por sua vez dispara WM_DESTROY para forçar um PostQuitMessage.

Como resultado, a próxima mensagem é uma mensagem WM_QUIT, que quebra o loop e encerra o jogo.

O passo final é adicionar a biblioteca estática gdi32.lib ao arquivo build.bat.

Para criar uma janela, precisamos determinar uma classe de janela que contém título e ícones para a janela. Ela também inclui o procedimento de callback da janela para lidar com a etapa de pintura, criação e fechamento da janela.

Depois de definir a classe da janela, precisamos registrar essa classe para usar a janela.

Agora, criamos uma janela com coordenadas, título e algumas flags para definir propriedades como bordas, visibilidade etc.

Criamos um loop principal para processar a fila de mensagens da thread atual e a fila de mensagens da janela.

Esse processo permite traduzir a tecla virtual para uma mensagem de caractere e despachar essa mensagem para o procedimento de callback da janela.

Como você pode ver abaixo, o segundo parâmetro de PeekMessageA deve ser nulo para que mensagens da janela e mensagens da thread sejam processadas (WM_QUIT é uma mensagem da thread). Caso contrário, não conseguimos fechar o programa, mesmo depois da janela ser fechada.

O próximo passo é alocar um back buffer.

• Criar WNDCLASSA
• Registrar uma classe
• Criar o procedimento de callback da janela
• Criar Window
• Criar GameLoop
• Processar a fila de eventos com Peek Message
• Extra: pintar a janela inteira com PatBlit, BeginPaint e EndPaint

• WNDCLASSA - contém os atributos da classe da janela registrados pela função RegisterClass
• DefWindowProcA - chama o procedimento padrão da janela para fornecer o processamento padrão de qualquer mensagem que a aplicação não processa.
• RegisterClassA - registra uma classe de janela para uso posterior em chamadas para CreateWindow
• CreateWindowA - cria uma janela sobreposta, pop-up ou filha
• PeekMessageA - despacha mensagens recebidas que não estão na fila, verifica a fila de mensagens da thread em busca de uma mensagem postada e recupera a mensagem, se existir. Usada para operações longas.
  • IMPORTANTE: hwnd deve ser NULL para que mensagens da janela e mensagens da thread sejam processadas.
• DispatchMessageA - despacha uma mensagem para um procedimento de callback da janela.
• TranslateMessage - traduz a tecla virtual para mensagens de caractere. As mensagens de caractere são postadas na fila de mensagens da thread chamadora, para serem lidas na próxima vez que a thread chamar PeekMessage.
• DestroyWindow - envia uma mensagem para a janela para desativá-la e remover o foco do teclado.
• PostQuitMessage - indica ao sistema que uma thread fez uma solicitação para encerrar.

Usamos para expressar atividades, experiências, hobbies, hábitos, isto é, o foco é a atividade geral, não a ação/intenção ou escolha. Por exemplo:

He likes reading before bed.
Ele gosta de ler antes de dormir.

She likes cooking.
Ela gosta de cozinhar.

They like swimming.
Eles gostam de nadar.

She finished doing homework.
Ela terminou de fazer a lição.

Uso comum: Atividades, gostos, conclusões

Usamos para ação/intenção ou algo mais específico de sua preferência.

He likes to read science fiction.
Ele gosta de ler ficção científica.

He likes to read in silence.
Ele gosta de ler em silêncio.

Uso comum: Planos, desejos, necessidades.

Mais natural para hobby/atividade:

I like reading.

Mais natural para preferência/comportamento:

I like to read at night.

I like coding.
Eu gosto de programar.

He likes drawing.
Ele gosta de desenhar.

We like traveling.
Nós gostamos de viajar.

I enjoy reading books.
I like reading books.
Eu gosto de ler livros.

Veja que enjoy reading e like reading pode soar igual, mas enjoy transmite um prazer mais forte, eu realmente aprecio/curto ler livros. So mais forte, pessoal, emocional. Ou seja, enjoy realmente tem prazer, like é só uma preferência neutra, casual.

Exemplo pessoal (pra mim):

I enjoy coding.
I like reading books.

Neste exemplo o gerundio enfatiza a experiência/hábito de ler: ele gosta do hábito de leitura antes de dormir, ler antes de dormir faz parte da rotina dele = hobby.

Já no infinitive o foco é na ação: ele prefere ler antes de dormir = Ele gosta de ler antes de dormir em vez de fazer outra coisa.

Outro exemplo:

I like swimming. gosto da atividade. I like to swim in the morning. preferência de fazer aquilo de manhã.

Os verbos abaixo, por mais que não expressem hábitos, experiências, hobbies ou foco na atividade geral, precisam do -ing. Como o caso do exemplo finish. She finished doing homework poderia soar como Ela terminou de fazer a lição que é uma ação, o que intuitivamente colocariamos She finished to do homework, mas estaria errado. Neste caso específico, esses verbos abaixo exigem que o próximo verbo fique em -ing.

Em outras palavras, não pode ter uma frase como I enjoy to read books.

O mais famoso stop.

I stopped smoking.
Parei de fumar. (abandonei o hábito)

I stopped to smoke.
Parei para fumar. (Interrompi algo pra fumar)

Gardering is my favorite hobby. Meeting new people isn't always easy. Reading helps me relax. Singing always cheers me up.

Depois de um adjetivo, geralmente usamos um verbo no infinitivo.

I was sad to see my test score. Is it difficult to make a cake?

I tought about taking piano lessons. Did you plan on calling me back?

The librarian told the students to be quiet. We asked them to go to the beach with us.

Os gerúndios e infinitivos combinam o significado de ação de um verbo com a função gramatical de um substantivo. Eles atuam como substantivos (sujeitos e objetos) em uma frase.

Speaking in front of a crowd can be scary.
Falar na frente de uma multidão pode ser assustador.

Speaking vem do verbo speak, mantém ideia de ação mas está funcionando como substantivo porque está na posição de sujeito. Isto é, o sujeito da frase é speaking in front of a crowd. E o verbo principal é o can be, e scary é o adjetivo.

Do you want to come with us?
Você quer vir conosco?

Sujeito = you verbo principal = want objeto = to come with us

to come funciona como substantivo p orque ele é a "coisa desejada".

Gerunds e infinitives parecem verbos no significado, mas se comportam como substantivos na frase.

Segundo uma pesquisa da Forbes, 68% das empresas no Brasil planejam aumentar as contratações de tecnologia em 2026.

Rachel Garcia, líder de talentos da Century na América Latina, disse o seguinte:

Praticamente todas as áreas terão que contratar e desenvolver mais gente para lidar com dados e inteligência artificial. Sem profissionais preparados para desenhar, integrar, operar e evoluir soluções de automação e digitalização de processos com qualidade, os ganhos de produtividade não vão se sustentar.

Ou seja, as vagas existem. E em quantidade.

Então por que você se candidata e não recebe resposta?

A resposta é simples, mas dói ouvir: faltam devs qualificados. Há um excesso de iniciantes sem preparo suficiente para o que o mercado exige hoje. O problema não está na demanda. Está na oferta. Tem muita gente tentando entrar ao mesmo tempo, mas pouca gente chegando preparada do jeito que as empresas precisam.

Isso cria uma situação paradoxal: empresas com vagas abertas há meses sem conseguir preencher, e desenvolvedores mandando currículo sem conseguir resposta. Os dois lados frustrados, mas por razões completamente diferentes.

Isso cria um ciclo vicioso que paralisa muita gente.

Sem experiência, ninguém te chama. E se ninguém te chama, você não ganha experiência.

E por que isso ficou tão difícil? Porque a linha de corte ficou muito mais rígida nos últimos anos.

Lá por 2017, 2018, 2019, se você soubesse o básico de Kotlin, conseguia uma vaga Android. A empresa te contratava e ensinava o restante internamente. Esse mercado existiu de verdade, e eu vi isso acontecer com vários alunos e conhecidos que entraram na área nessa época sem precisar de muito mais do que vontade e um conhecimento inicial sólido.

Mas aí veio 2020 e 2021, e o setor forçou contratações em massa. Muita empresa contratando rápido e sem filtro rigoroso, porque precisava crescer. Em seguida, 2022 e 2023 trouxeram as demissões em lote das bigtechs como Amazon, Meta e Google. Dezenas de milhares de devs experientes jogados no mercado ao mesmo tempo. A régua subiu muito. Saber o básico hoje é o mínimo, e ele não te destaca mais.

O que era nível pleno virou requisito de entrada. O que era diferencial virou obrigação. E quem não percebeu essa mudança continua tentando entrar com o padrão de 2019 num mercado de 2026.

Com isso, surgiram três problemas que provavelmente estão te afetando agora.

A descrição da vaga pede Kotlin, Jetpack Compose, arquitetura MVVM, integração com API REST, Firebase e ainda inglês.

Isso não é exagero. É o que o mercado espera de um júnior hoje.

Vou te dar um exemplo real de requisitos que aparecem em vagas "júnior" de Android no Brasil agora:

• Experiência com Kotlin e corrotinas
• Conhecimento de Jetpack Compose
• Entendimento de arquitetura MVVM ou MVI
• Familiaridade com injeção de dependências (Hilt ou Koin)
• Consumo de APIs REST com Retrofit
• Versionamento com Git
• Inglês para leitura de documentação

E em alguns casos ainda adicionam: testes unitários, CI/CD, Firebase, publicação na Play Store.

Isso é o que chamam de vaga júnior. Não é uma vaga para quem está aprendendo. É uma vaga para quem já aprendeu um volume considerável de coisa e consegue trabalhar com autonomia mínima desde o primeiro dia.

As empresas recebem centenas de candidatos por vaga. O recrutador não tem tempo de ler currículo por currículo com atenção. Quem não apresenta um pacote completo de conhecimento simplesmente é descartado antes mesmo de chegar na entrevista. Às vezes de forma automatizada, por palavras-chave que o sistema de triagem não encontrou no seu currículo.

Não é pessoal. É volume.

O segundo problema é que você sabe copiar código, mas não sabe programar de verdade. E isso não te destaca.

Você termina um curso de Kotlin. Depois faz um de Jetpack Compose. Depois acha um tutorial de MVVM no YouTube. Depois começa outro curso porque esse parecia mais completo. No final, não consegue criar nada do zero, sozinho, sem seguir um passo a passo.

Na programação, isso tem nome: tutorial hell, o inferno dos tutoriais.

O que acontece psicologicamente é o seguinte: enquanto você assiste a aula, tudo parece fazer sentido. O instrutor digita, o código funciona, você entende a lógica. Você sente que está aprendendo. Dá aquela sensação boa de progresso.

Mas aí você fecha o vídeo, abre o Android Studio numa tela em branco e trava.

Você não sabe por onde começar. Não sabe quais arquivos criar. Não sabe como estruturar o projeto. A sensação de entendimento que você tinha era real, mas era entendimento do que o instrutor estava fazendo, não da capacidade de fazer sozinho.

Isso tem um nome científico também: ilusão de competência. Você confunde reconhecimento com capacidade de execução. São coisas completamente diferentes.

O mercado quer alguém que saiba resolver problemas. Assistir tutoriais e resolver problemas são coisas completamente diferentes. Na entrevista técnica, ninguém vai pedir para você assistir uma aula e repetir o que o professor fez. Vão te dar um problema e pedir para você resolver.

A maioria das vagas nunca chega a ser publicada. As empresas contratam muito por indicação.

Quando você manda currículo pelo LinkedIn, você entra na fila disputando atenção na camada mais superficial do processo. Você compete com centenas de pessoas sem nenhuma vantagem além do papel.

Quem já tem conexões dentro da empresa chega antes mesmo da vaga existir. O dev que faz parte da comunidade, que já interagiu com aquele tech lead no GitHub ou no Discord, que apareceu no radar de alguém da empresa, tem uma vantagem enorme sobre quem manda currículo frio para o e-mail de RH.

Não é injusto. É como o mundo funciona. Em todas as áreas, não só em tecnologia.

O problema é que a maioria das pessoas que estão aprendendo a programar ficam 100% focadas no técnico e ignoram completamente a construção de presença. Estudam sozinhas, sem interagir com comunidade, sem mostrar o que estão construindo, sem aparecer em nenhum lugar que as pessoas da área frequentam.

Antes de falar das soluções, preciso te contar uma coisa sobre como funciona o processo seletivo na prática.

Um recrutador em uma empresa de médio porte pode receber de 200 a 500 currículos para uma vaga. O tempo dedicado a cada currículo na triagem inicial é, em média, de 7 a 30 segundos.

Nesse tempo, ele vai olhar para três coisas:

• Você tem os projetos e tecnologias que a vaga pede no currículo?
• Tem algo no GitHub ou portfólio que mostre código funcionando?
• O currículo é legível, objetivo e sem informação irrelevante?

Se qualquer uma dessas três perguntas tiver resposta negativa, seu currículo vai para o descarte. Sem leitura aprofundada, sem chance de explicar no telefone, sem nada.

Isso muda completamente o que você precisa focar. Não adianta ter estudado muito se isso não estiver visível e comprovável de forma imediata no seu currículo e no seu GitHub.

O tutorial é uma ferramenta boa, mas você provavelmente não está usando ele da melhor forma.

O passo que falta é este: pare de acumular cursos e comece a construir algo real com o que você já aprendeu.

Não precisa ser nada complexo. Um app de agendamento de barbearia. Um sistema de controle de estoque para uma loja. Um gerenciador de tarefas pessoais. Um app de acompanhamento de gastos. Qualquer coisa que resolva um problema real e que obrigue você a tomar decisões técnicas sozinho.

O ponto mais importante é sair da posição passiva de quem assiste e entrar na posição ativa de quem constrói.

Você não precisa de carteira assinada para ter experiência. Você constrói algo que funciona, resolve um problema real e toma decisões técnicas. Isso sim é experiência.

A diferença entre um projeto de tutorial e um projeto de portfólio é essa: no tutorial, você seguiu as instruções de outra pessoa. No projeto próprio, você encarou um problema, tomou decisões de arquitetura, resolveu bugs sem ter a resposta pronta, e fez funcionar. Isso é o que o entrevistador quer ver.

Quando você constrói algo do zero, inevitavelmente vai esbarrar em situações que o tutorial não cobriu. E é exatamente nesses momentos que você aprende de verdade: como ler a documentação oficial, como pesquisar erros no Stack Overflow, como entender a mensagem de erro e inferir a solução. Essa capacidade de resolver problemas sem depender de alguém é o que o mercado paga.

Para sair do tutorial hell de vez, você precisa de um treinamento que te faça praticar desde o início, não só assistir aulas. Por isso eu criei minhas formações de Android e iOS, com dezenas de módulos, centenas de aulas práticas e projetos reais que vão do zero à publicação na loja.

Tem gente desperdiçando meses em tecnologias que quase ninguém usa no mercado.

Kotlin lidera o volume de vagas Android. Swift ainda domina o iOS. Mas a linguagem sozinha não basta, e é aqui que a maioria das pessoas erra a estratégia de estudo: para em saber a sintaxe da linguagem e acha que está pronto para se candidatar.

O mercado quer quem sabe trabalhar com o ecossistema completo. Para Android, isso significa:

• Jetpack Compose para construção de interfaces declarativas
• Arquitetura MVVM para separar responsabilidades e manter o código testável
• Hilt ou Koin para injeção de dependências
• Retrofit para consumo de APIs REST
• Room para persistência de dados local
• Coroutines e Flow para operações assíncronas
• Git para versionamento, porque trabalho em equipe exige isso
• Publicação na Play Store, porque mostra que você vai até o fim

Para iOS, o equivalente é Swift com SwiftUI, arquitetura MVVM ou Clean Architecture, Combine ou async/await, URLSession ou Alamofire para APIs, CoreData ou SwiftData para persistência local e publicação na App Store.

O que eu aconselho é escolher uma dessas plataformas, ir fundo, e dominar esse conjunto de ferramentas de verdade antes de tentar diversificar. Profundidade numa área vale muito mais do que superficialidade em várias.

O que as empresas mais buscam hoje não é só quem sabe programar. É quem sabe pensar.

Na prática, o problema chega como uma regra de negócio: o cliente precisa de X. A sua função é traduzir isso em código pensando no impacto para o negócio. Mas entre o pedido do cliente e a linha de código existe um gap enorme, e preencher esse gap é o que diferencia um dev que só executa de um dev que resolve problemas.

Treine isso nos seus projetos com uma prática simples: antes de abrir o editor de código, escreva num papel ou num arquivo de texto:

• Qual problema este app resolve?
• Quem é o usuário que vai usar isso?
• O que ele precisa conseguir fazer em menos de 3 cliques?
• Qual seria o fluxo mais simples possível para resolver esse problema?

Isso muda completamente a qualidade do que você vai construir. E muda a qualidade das respostas que você dá numa entrevista quando o recrutador pergunta: "me conta um projeto que você fez e qual problema ele resolvia".

A maioria dos candidatos responde com tecnologia: "fiz um app com Retrofit e MVVM". O candidato que se destaca responde com problema e solução: "criei um app para uma barbearia que perdia clientes por falta de agendamento organizado, e desenvolvi um sistema que permite ao cliente agendar pelo celular em menos de um minuto".

Pare de pensar só como desenvolvedor. Pense como dono do produto.

Essa solução pode mudar bastante seu jogo financeiro, e ela é mais acessível do que a maioria das pessoas imagina.

Um dev Android ou iOS com inglês consegue trabalhar para empresas nos Estados Unidos e na Europa sem sair de casa. Plataformas como Toptal, Turing, Contra e Arc têm projetos mobile pagando em dólar o tempo todo. A diferença salarial entre um dev que atende só o mercado brasileiro e um que atende o mercado internacional pode ser de 3x a 5x, dependendo da senioridade e da empresa.

Além disso, a maioria das documentações oficiais do Android e do iOS, os fóruns técnicos, as conferências e os conteúdos mais aprofundados estão em inglês. Quem não entende inglês técnico sempre fica um passo atrás, porque vai depender de alguém que já leu a fonte original e traduziu, com todos os filtros e atrasos que isso implica.

E você não precisa ser fluente. Comece pelo inglês técnico com materiais que você já usa:

• Documentação oficial em developers.android.com e developer.apple.com
• Stack Overflow
• Vídeos e canais em inglês no YouTube sobre Android e iOS
• Servidores no Discord da comunidade de desenvolvimento mobile
• Changelog das releases do Kotlin, Swift e das ferramentas que você usa

Com 30 minutos por dia dedicados ao inglês técnico, em seis meses você já consegue ler documentação sem dificuldade. Em um ano, consegue participar de entrevistas em inglês. A diferença salarial vai aparecer mais rápido do que você imagina.

Voltando ao terceiro problema: a falta de network.

A boa notícia é que nunca foi tão fácil construir presença e conexões genuínas na área de tecnologia como é hoje, sem precisar de uma empresa, de um evento físico ou de qualquer investimento financeiro.

O que funciona na prática:

GitHub ativo. Coloque seus projetos no GitHub, mesmo que sejam simples. Um perfil com projetos commitados regularmente mostra que você está trabalhando, evoluindo e tem código para mostrar. Um perfil vazio ou com apenas um repositório diz o contrário.

LinkedIn com conteúdo. Você não precisa postar todo dia. Mas postar uma vez por semana sobre o que você está aprendendo ou construindo te coloca no radar de pessoas da área. Recrutadores monitoram perfis que produzem conteúdo. É diferente de mandar candidatura fria.

Comunidades no Discord e Telegram. Existem servidores dedicados a desenvolvimento Android, iOS e mobile em geral com milhares de devs ativos. Participar, tirar dúvidas, responder dúvidas dos outros te constrói reputação ao longo do tempo. Pessoas que te conhecem numa comunidade podem te indicar para uma vaga que nem chegou a ser publicada.

Comentar e contribuir. Quando você aprende algo novo a partir de um artigo ou vídeo, comentar com uma observação genuína ou uma dúvida real gera visibilidade e começa relacionamentos. Isso funciona no YouTube, no LinkedIn e no próprio GitHub.

Network não é distribuir cartão de visita digital. É aparecer consistentemente em lugares onde as pessoas da sua área estão, agregar valor com o que você sabe e pedir ajuda com o que ainda não sabe. As indicações vêm naturalmente depois disso.

O portfólio é o que transforma todo o esforço das soluções anteriores em algo que o recrutador consegue avaliar em 30 segundos.

Não precisa de um site elaborado, embora ter um seja um diferencial. O que realmente importa é o GitHub bem organizado com projetos que mostram domínio do ecossistema que você escolheu.

Para cada projeto no seu portfólio, você precisa de:

README completo. Descreva o que o app faz, qual problema ele resolve, quais tecnologias você usou e por que escolheu cada uma. Coloque screenshots ou um GIF mostrando o app funcionando. Isso mostra que você pensa além do código, que consegue comunicar o que construiu.

Arquitetura visível. Organize o projeto em camadas claras (data, domain, presentation). Quem abre o repositório precisa entender a estrutura em menos de um minuto. Um projeto organizado comunica que você entende de boas práticas, mesmo sem ler uma linha de código.

Histórico de commits coerente. Commits com mensagens como "fix" ou "update" não dizem nada. Commits com mensagens como "add Room database for offline caching" ou "refactor ViewModel to use StateFlow instead of LiveData" mostram que você entende o que está fazendo e por quê.

App publicado quando possível. Um link para o app na Play Store ou App Store no README é um diferencial enorme. Mostra que você foi até o fim, que o projeto é real e que você sabe como funciona o processo completo de publicação.

Dois ou três projetos bem feitos valem muito mais do que dez projetos abandonados ou clones de tutorial sem nenhuma personalização.

O mercado não está fácil, é fato. Mas os dados mostram que as vagas existem e em quantidade.

O que falta não é oferta de emprego. O que falta são profissionais que chegam preparados do jeito certo, com projetos reais para mostrar, com o ecossistema dominado, com alguma presença na comunidade e com capacidade de resolver problemas de forma independente.

A linha de corte mudou, infelizmente. Mas quem entende isso e age de acordo sai na frente de 90% dos concorrentes, porque a maioria ainda está tentando entrar no mercado com a estratégia de 2019.

Se você seguir os caminhos que apresentei aqui, vai estar muito mais perto da sua primeira vaga como dev do que a maioria dos candidatos que manda currículo todo dia sem nenhuma estratégia:

• Construa projetos reais que resolvem problemas reais
• Domine o ecossistema completo da plataforma que escolheu
• Pense como dono do produto, não só como executor de código
• Invista no inglês técnico de forma consistente
• Apareça na comunidade e construa presença ao longo do tempo
• Monte um portfólio que fala por você antes da entrevista acontecer

Conseguir a primeira vaga como dev não vai ser simples. Mas é totalmente possível, e tem acontecido com pessoas que saíram do zero e seguiram um caminho estruturado e consistente.

O problema nunca foi falta de vaga. Foi falta de preparo que chegasse ao nível que o mercado passou a exigir.

Se quiser um caminho estruturado para dominar Android ou iOS com projetos reais do zero à publicação na loja, conheça meus treinamentos de Android e iOS. São as formações que eu criaria para mim mesmo se estivesse começando hoje.

Você talvez já tenha lido meu texto sobre KISS O princípio continua o mesmo:

Keep it simple, stupid.

Quanto mais simples, mais claro. Quanto mais claro, mais fácil de manter. Quanto mais fácil de manter, mais energia sobra para construir o que realmente tem valor… o conteúdo!

Este próprio site é uma aplicação prática disso.

Eu não quero transformar o blog em um projeto paralelo de decoração digital. Quero que ele seja uma ferramenta direta para publicar ideias, ensinar programação e compartilhar experiência real de quem escreve software há anos.

Se o texto carrega a mensagem, se o código do site é fácil de manter e se o leitor consegue chegar rapidamente ao conteúdo, então o objetivo foi cumprido.

Nem todo projeto precisa de uma arquitetura visual exuberante ou de uma solução sofisticada. Em muitos casos, a solução simples não é apenas suficiente. Ela é superior.

Outro princípio que conversa diretamente com essa decisão é o YAGNI:

You Aren't Gonna Need It - Você Não Vai Precisar Disso.

Traduzindo para a prática: não adicione agora aquilo que não resolve um problema real agora.

Isso vale para código. Vale para arquitetura. Vale para features. E vale também para layout.

Eu não preciso de vinte efeitos visuais para ensinar alguém a programar uma tela no Android ou estruturar uma lógica no Swift.

Eu não preciso de uma experiência visual carregada para explicar orientação a objetos, estado, listas ou arquitetura de software.

Se algo não aumenta a clareza, não melhora a leitura e não ajuda o aluno a avançar, existe uma boa chance de ser excesso.

Excesso custa caro.

Custa tempo. Custa energia. Custa manutenção. Custa foco.

E o pior: muitas vezes ele dá uma falsa sensação de progresso.

Você passa a tarde inteira mexendo em detalhes superficiais e no fim do dia não escreveu uma linha melhor de código, não aprendeu nada novo de lógica e não terminou nenhum programa.

Eu aprendi isso cedo com um mentor oriental que marcou bastante a minha forma de pensar.

Ele era o tipo de pessoa extremamente disciplinada, objetiva e econômica em palavras. Não falava mais do que precisava. Não complicava o que podia ser direto. E me ensinou uma coisa que ficou comigo:

Quando o essencial está fraco, o enfeite vira distração.

Isso não era só sobre programação. Era sobre postura profissional.

• Antes de querer impressionar, entregue;
• Antes de embelezar, faça funcionar;
• Antes de sofisticar, simplifique;
• Antes de expandir, domine o básico.

Essa mentalidade mudou minha forma de construir software.

Eu parei de admirar soluções complicadas só porque pareciam inteligentes. Passei a respeitar muito mais a solução que funciona, é legível, é enxuta e continua fácil de evoluir meses depois.

E honestamente, isso também me ajudou fora do código.

Hoje eu prefiro uma rotina mais simples, ferramentas mais diretas e processos mais leves quando o objetivo é produzir melhor.

Menos teatro. Mais entrega.

Se você está aprendendo a programar, eu quero te passar uma ideia muito prática:

Não confunda movimento com progresso.

Trocar tema do editor toda semana não é programar.

Ficar obcecado com setup perfeito não é programar.

Assistir infinitos vídeos sobre programação sem construir nada, você já sabe… também não é programar.

Programar é sentar e escrever código. É testar. É errar. É depurar. É melhorar aos poucos. É criar um programa, mesmo pequeno, e terminar.

Muita gente se perde nas bordas da profissão.

Quer o melhor teclado, a melhor fonte, o melhor tema, a melhor linguagem, o melhor framework, a melhor stack, a melhor metodologia, o melhor segundo cérebro, o melhor plugin, a melhor IA, o melhor roadmap.

Mas evita o principal: abrir o projeto e fazer o trabalho.

Se você levar KISS e YAGNI a sério, muita coisa desnecessária cai por terra.

Você para de enfeitar o que ainda nem existe e para de construir complexidade antes da hora.

Assim, você não gasta energia tentando parecer programador e começa, de fato, a programar.

Simplicidade não significa descuido, fazer qualquer coisa ou abandonar qualidade.

Simplicidade de verdade exige critério. Exige intenção. Exige saber dizer “não” para muita coisa que até poderia entrar, mas não deveria entrar.

Este site é simples porque ele foi pensado para ser assim.

Eu, Tiago, quero focar no que importa: escrever, ensinar, programar e construir coisas úteis.

E você, leitor, pode aplicar a mesma lógica na sua jornada.

Comece retirando vaidade técnica, distrações ou enfeite prematuro.

E aplique mais prática, código, projetos terminados e foco no essencial.

No fim, é isso que faz alguém evoluir de verdade.

Se este texto te ajudou a refletir, continue acompanhando os conteúdos. A proposta aqui é exatamente essa: menos fumaça e mais conteúdo útil para você aprender a criar software de verdade.

Bom dia Tiago! Depois dá uma olhada no app que eu concluí no iOS legacy… projeto final do curso

— Maxwell Farias - Aluno

A finalidade do aplicativo é trazer uma lista de produtos em que o usuário pode fazer a recuperação de um cupom. E ao fazer a compra deste produto, conseguir um desconto na loja.

Muito bom o curso.

— Adriano Valumin - Aluno

Este aplicativo foi criado para que todos possam criar seus hábitos diários.

— Heverson Assunção - Aluno

Opa Tiago depois de alguns dias batendo cabeça consegui dar um jeito e finalizar o app apesar de simples foi trabalhoso ainda mais pra mim que estou começando, mas novamente sem suas dicas e ajuda eu não estaria aqui, obrigado novamente e vamos para o terceiro app!

Aplicativo que ajuda você à monitorar os principais indicadores de saúde como consumo de água, taxas metabólicas e farmácias próximas.

— Ygor Doring - Aluno

Fala Tiagão, tudo certo? Gostaria de agradecer por mais esse módulo e dizer que estou a ponto de conseguir minha primeira oportunidade como android developer em uma big tech. Graças a você e ao conteúdo de primeira que temos no curso! Agradeço imensamente pelo conhecimento e boa vontade em ajudar!.

Aplicativo que ajuda você à monitorar os principais indicadores de saúde como consumo de água, taxas metabólicas e farmácias próximas.

— Sérgio Silveira - Aluno

Tiago, primeiro de tudo quero agradecer imensamente todo o suporte dado durante o curso com minhas dúvidas, estou colocando meus projetos em um outro patamar, graças as técnicas, recursos e o conhecimento compartilhado por você e toda sua equipe. Obrigado mais uma vez, o Curso Android Express de fato foi um divisor de águas na minha carreira profissional… estou apaixonado pelo kotlin. Obrigado e vamos em frente.

Aplicativo de vendas da Empresa.

— Felipe Matheus - Aluno

Boa tarde pessoal, tenho orgulho de vir aqui publicar que graças as habilidades que aprendi durante o curso, pude fechar uma parceria com a principal igreja da minha cidade e desenvolver o app Desterro Mairiporã.

Este é o aplicativo da Igreja de Mairiporã.

…Para quem mora em Mairiporã vai adorar o controle dos transportes..

— Felipe Ferreira - Aluno

Esse aplicativo controla os transportes na palma da mão e ajuda você a se programar melhor durante a semana :)

— Leandro Modena - Aluno

Tiago, estou super feliz, depois do seu curso e com muita dedicação e estudo terminei meu app que está na loja (Emprego Azul +500 downloads), consegui vários serviços de freelance e amanhã será meu primeiro dia com carteira registrada como Desenvolvedor Android.

O aplicativo ajuda a encontrar empregos e serviços em gerais.

— Thiago Oliveira - Aluno

O aplicativo ajuda a monitorar alguns indicadores importantes para a saúde do indivíduo.

..Subi um jogo na Google play… consegui com os conhecimentos do curso

— Flazion Lima - Aluno

Um simples mas desafiador jogo de quebra-cabeças de blocos de jóias! Block Puzzle 2020 é um quebra-cabeça totalmente gratuito. Você pode apreciá-lo em qualquer lugar, sempre, sem necessidade online. Este jogo offline tem um jogo muito simples: basta arrastar, soltar e preencher toda a grade

Fala,Tiago Blz? Pessoal da empresa deu um retorno. Fui contratado como Programador Jr. Valeu pela força.

— Hemerson Silva - Aluno

O aplicativo agrega uma coleção de filmes onde você poderá favoritar para serem assistidos futuramente.

Segue um app que fiz pra ajudar no combate a COVID-19 na região onde moro. O app informa o boletim das 18 cidades da região.

— Hemerson Silva - Aluno

O aplicativo faz um boletim das 18 cidades de Pajeú com status da pandemia.

Com o seu curso eu pude de fato aprender algo com um cronograma e mesmo nas aulas básicas eu sempre vejo coisas que se eu já soubesse iria facilitar muito a minha vida. Por isso não pulo nenhuma aula e vejo todas desde os fundamentos. Por isso a importância de se começar com calma e ir avançando gradativamente.

— Ângelo Robson - Aluno

Encontre um ponto turístico mais próximo de você e conheça as belezas naturais do estado de Alagoas. Com o AL Turismo você poderá analisar fotos, distância e rotas até o destino desejado.

Boa tarde pessoal, sou aluno do curso também. Desenvolvi um APP que consome dados de uma API que extrai os dados do ministério da saúde quanto ao status do covid-19.

— Ângelo Robson - Aluno

Aplicativo desenvolvido para fornecer informações confiáveis ​​sobre o status do vírus.

_\_Devido ao assunto delicado do Covid-19, o o Google Play não aceita apps neste gênero, exceto de instituições oficiais de saúde. Contudo, você pode acompanhar pelo código-fonte aberta pelo desenvolvedor.*

Estou passando aqui para agradecer seus videos, pois comprei seu curso fora o que fiz de graça no youtube, então especialmente este que usa a API do Google Maps. Depois de concluído resolvi criar meu portfólio. Estou pra upar na google play um Segundo App que fiz estudando seu curso.

— Paulo Soares - Aluno

Este aplicativo foi criado para que todos possam saber em tempo real onde teve Roubos e Assaltos na região onde você estar, com ele será possível fazer o mapeamento da cidade e saber qual região com maior índice de roubos, somos um aplicativo novo e totalmente independente apenas com intuito de ajudar as pessoas a quem sabe encontrar seus bens ou inibir algum roubo seja de celular, veículo ou qualquer outra coisa.

Minha trajetória teve início em meio a uma família simples, permeada pelo ofício de eletricistas. Meu pai, irmãos e primos, todos trilhavam esse caminho, e tudo apontava para o fato de que eu seguiria a mesma rota.

E, de fato, assim aconteceu.

Com uma formação em eletroeletrônica pelo SENAI, meu conhecimento tecnológico estava inicialmente atrelado a hardware, diodos, transistores e resistores.

Contudo, foi quando dei meu primeiro mergulho na programação que tudo mudou, utilizando uma linguagem de baixo nível: o Assembly.

Iniciei minha jornada aprendendo a programar em Assembly, explorando a criação e automação de tarefas com microcontroladores da família 8051. Mais tarde, adentrei o universo da linguagem C, especialmente voltada para microcontroladores PIC.

O ato de escrever um programa de computador fez meu coração cantar e acendeu o desejo de me tornar um desenvolvedor de software.

Ao ingressar na Universidade São Judas Tadeu, em São Paulo, como bolsista pelo programa Prouni, escolhi a Ciência da Computação como meu campo de estudo.

Após intensa dedicação, conquistei meu primeiro emprego em uma fábrica de software, onde desenvolvi soluções utilizando a linguagem Java após passar por três entrevistas técnicas desafiadoras.

Em um ponto crucial, optei por trilhar um caminho diferente, largando a universidade, apesar de já estar atuando como desenvolvedor backend. Ao adquirir experiências notáveis em empresas de renome, como a LATAM, continuei minha jornada, focando no desenvolvimento web.

Após alguns anos, vivi um momento decisivo que marcou uma verdadeira virada como programador.

O ano era 2013.

Trabalhava em uma empresa de telemetria onde tive contato com algumas pessoas que estavam embarcando no universo mobile.

Aquilo parecia mágico 🎩.

Com isso, decidi mudar drasticamente de especialização e seguir uma nova jornada para me tornar um desenvolvedor mobile com Android e trabalhar como freelancer e desenvolvedor independente, criando meus próprios aplicativos, empreendendo.

Criei diversos aplicativos em diversos nichos de mercado:

• e-commerce
• financeiro
• imobiliários
• CRM
• jogos de azar
• educaional
• fitness
• infantil
• streams
• redes sociais

Vivi alguns anos somente com a renda dos meus próprios aplicativos Android. Mas em um determinado momento, eu senti que precisava ir para outro nível. Eu precisava me tornar um desenvolvedor mobile completo, com Android e iOS.

De 2015 à 2018, fui coordenador de um time de desenvolvimento e em paralelo comecei a "respirar" somente iOS - dia e noite.

Com essa vontade irrazoável em aprender e me tornar um desenvolvedor mobile completo, agora no universo iOS, crio minha própria oportunidade e lanço um desafio de 90 dias para meu CTO.

Modernizar um aplicativo de Objective-C para Swift.

Este era o aplicativo iOS principal da empresa que foi categorizado como os top aplicativos do setor imobiliário.

Esse processo precisava ser feito do absoluto zero e em até 90 dias.

Só tinha um pequeno problema, eu não sabia ABSOLUTAMENTE nada de Objective-C ou Swift. Muito menos instalar o Xcode 😱.

Mas eu sabia resolver problemas, sabia aprender e sabia que era capaz e teria êxito!

Tudo isso enquanto trabalhava e cuidava de outras coisas na empresa, afinal, nada pode parar não é mesmo?

Toquei este projeto sozinho e para a felicidade de todos, 88 dias depois (2 dias a menos do prazo estipulado) o projeto estava pronto e publicado na App Store.

Tudo isso foi possível por causa do meu desejo irrazoável de fazer acontecer e de querer levar minhas habilidades para o próximo nível.

Em 2018, decidi compartilhar no Youtube os meus conhecimentos sobre desenvolvimento Android e iOS nativos.

Hoje, esse canal possui +4.0 milhões de Views e +69.000 seguidores (e contando).

Este é considerado o maior canal sobre desenvolvimento Android e iOS nativo do Brasil.

E a pedido de milhares de inscritos, eu comecei um novo projeto ministrando treinamentos online para transformar os aspirantes à programadores (iniciantes), assim como eu fui um dia, em desenvolvedores profissionais.

Com esse projeto, eu já ajudei mais de 4.000 alunos a aprenderem a programar de verdade com meus treinamentos online.

Hoje, minha missão é ajudar ainda mais pessoas como você, através das minhas experiências reais a se tornarem desenvolvedores mobile extraordinários.

Além disto, através de artigos do blog, e-books e materiais gratuitos, irei compartilhar a minha experiência e o que eu faço no dia-a-dia para desenvolver aplicativos Android e iOS e espero que isso possa te ajudar.

Eu acredito que qualquer pessoa tem o potencial de se tornar um desenvolvedor extraordinário capaz de criar uma obra de arte na forma de produto/software.

De fato, estou frustrado com a falta de conhecimento, comprometimento e prática de muitos programadores que preferem se manter na média ao invés de evoluir para o próximo nível buscando a excelência do seu trabalho e da sua vida.

Espero que você esteja em busca de se destacar no mercado e não ser mais um no meio da multidão de outros programadores.

Se você, assim como eu e diversos alunos de sucesso, quiser sair da sua zona de conforto para mudar de vida e de carreira, eu te convido a mergulhar de cabeça e fazer uma imersão nesse universo Android ou iOS.

Eu criei o caminho mais efetivo possível depois de anos de experiência, onde você pode aprender de verdade como criar aplicativos profissionais com nossos treinamentos online.

Clique aqui para saber mais.

Seguir um mentor, deixará a sua trajetória mais fácil e te economizará muito tempo e dinheiro.

"Mas Tiago, ainda estou com algumas dúvidas:"

• O que é preciso para evoluir minhas habilidades como desenvolvedor mobile?
• O que preciso saber para trabalhar exclusivamente como um programador que cria aplicativos diferenciados?
• Como ser reconhecido no mercado e ter uma carreira de programador de sucesso?
• Como começar?
• Mas é difícil?

Criar aplicativos é mais simples que você possa imaginar, mas isso não significa que é fácil ou que você não vai precisar se dedicar.

Há um passo a passo que você pode aprender, alguns desses passos inclui:

• Arquiteturas de software
• Produtividade
• Ferramentas e métodos
• Concepção de ideias para aplicativos

A boa notícia é que existe um método assertivo para aprender tudo isso, de forma estruturada e organizada.

Olhando de uma visão bem ampla, temos 3 grandes tópicos para aprender:

1. Linguagem de Programação
2. Android ou iOS SDK
3. Método/Processos

Esses são os 3 pilares para se aprender qualquer tecnologia, incluindo criar aplicativos.

Dentro dos meus treinamentos online, eu mostro passo a passo como aprender cada um desses pilares.

Clique aqui para saber mais.

Aprender a programar e criar aplicativos pode ser difícil para muita gente. Agora, compartilhar o conhecimento de forma clara pode ser mais difícil ainda!

Por isso, ao invés de eu mesmo falar sobre os resultados que gerei e as vidas que já pude transformar, vou deixar aqui os relatos de pessoas que confiaram no meu trabalho e hoje estão decolando em suas carreiras.

Veja o que algumas das milhares de pessoas que já passaram pelos nossos cursos online de programação dizem sobre.

Ao reconhecer a distinção entre simples "programadores" e verdadeiros profissionais, você abrirá caminho para se destacar e alcançar o reconhecimento merecido. Este é o primeiro passo para conquistar aquilo que verdadeiramente merece.

O conceito de ganhar pouco ou muito é subjetivo, variando de mil a dez mil reais conforme as perspectivas individuais.

A quantia que almeja no mercado e em sua carreira é uma decisão pessoal que recai exclusivamente sobre você.

É fundamental compreender que todo indivíduo que atingiu o sucesso, conforme sua própria definição, iniciou sua trajetória a partir do zero. Portanto, seja você, eu ou qualquer outra pessoa, temos a capacidade de começar do zero e construir nosso caminho.

Posso assegurar que trilhar o caminho de desenvolvedor mobile pode proporcionar uma qualidade de vida incrível.

Eu acredito verdadeiramente que, depois de 15 anos de experiência como desenvolvedor eu possa te ajudar de alguma forma a evoluir na sua carreira mobile.

Espero que você aprenda muito por aqui e que meu conteúdo possa te ajudar a ir para o próximo nível.

Se você deseja me contactar:

• Instagram
• Youtube
• Facebook

Todo desenvolvedor começou exatamente onde você está agora. Os primeiros passos não precisam ser perfeitos, eles só precisam ser claros. Nesta primeira etapa, o foco é entender o ambiente, escrever sua primeira linha de código e reconhecer como o Kotlin se comporta.

Você não precisa de formação em computação para acompanhar. Precisa apenas de uma ferramenta para escrever e executar código Kotlin, como o Playground Kotlin, Android Studio ou uma IDE compatível com Kotlin. O importante agora é ter um lugar para testar ideias rapidamente.

IDE: Integrated Development Environment. É o Ambiente de Desenvolvimento Integrado, isto é, a ferramenta que fornece um kit para o programador programar.

No fim desta etapa, você vai entender como um programa Kotlin é organizado, como o código é executado e por que os primeiros exemplos parecem simples, mas são a base de tudo o que vem depois.

Agora que você já sabe imprimir valores, usar variáveis e entender os tipos básicos, chegou a hora de ensinar o Kotlin a tomar decisões.

Na prática, isso começa com uma pergunta simples: um valor é maior que o outro? Dois textos são iguais? Um número passou de um limite? Quando você aprende a responder esse tipo de pergunta, você abre a porta para escrever código que reage ao mundo real e toma decisões com base no usuário.

Nesta etapa, você vai aprender a comparar valores e descobrir o que o Kotlin devolve quando faz essas comparações. O resultado quase sempre será um Boolean, ou seja, true ou false.

Os programas raramente fazem algo apenas uma vez. Os aplicativos reais percorrem listas, repetem ações e processam conjuntos de dados. Nesta etapa, você aprenderá como fazer seu código se repetir e como decidir qual tipo de repetição se adequa à situação.

Com o Homebrew, instale com o jdtls com o comando

brew install jdtls.

Encontre o caminho de instalação com o brew --prefix jdtls.

Se estiver em outro sistema operacional, baixe o language server diretamente do repositório oficial do jdtls.

Dentro do dotfiles você encontra o script jdtls responsável por inicializar o servidor de linguagem Java a partir do workspace definido como argumento.

Os parâmetros neste script está configurado para o ambiente macOS. Logo, adapte o JDTLS_HOME para o seu sistema operacional e o -configuration se necessário.

Ainda não deu tempo de deixar o script cross-platform, uso macOS 90% do tempo. Sorry!

Coloque o script jdtls em algum lugar no PATH da sua máquina. Aqui eu copio para ~/bin e configuro ele como PATH no meu .zshrc.

# .zshrc
export PATH="~/bin:$PATH"

E os arquivos do emacs estão como links simbólicos para a HOME.

bin/jdtls # copied from dotfiles
.emacs -> /Users/tiagoaguiar/dotfiles/.emacs #symlink
.emacs.d -> /Users/tiagoaguiar/dotfiles/.emacs.d #symlink
.emacs-custom.el # (empty file for Emacs)

O workspace do projeto Java será encontrado automaticamente pelo Emacs a partir do diretório do projeto que contenha a estrutura base com um dos arquivos na raiz: .project, .classpath, pom.xml ou build.gradle.

Ou seja, se o projeto estiver na estrutura correta ele irá carregar automaticamente e iniciar o E-glot com LSP.

Caso não utilize o meu .emacs, você pode configurar no seu próprio. Eu extrai somente as partes relevantes para o ambiente Java IDE no Emacs.

O gerenciador de pacotes que utilizo é o use-package.

Instale também o company para o autocomplete.

Garanta que o java esteja instalado corretamente e que o Emacs possa encontrá-lo em seu JAVA_HOME.

Por aqui eu utilizo o java 21.

;;
;; .emacs (coloque no ~/.emacs)
;;
(use-package eglot
  :config
  (setq eldoc-echo-area-use-multiline-p nil)
  (setq eglot-events-buffer-size 0)
  (add-hook 'eglot-managed-mode-hook (lambda () (eglot-inlay-hints-mode -1)))  ;; disable param hint
  :config
  (add-to-list 'eglot-server-programs
               `(java-mode . ,#'my-jdtls-command)))


;; auto complete com company
(add-hook 'java-mode-hook 'global-company-mode)

(defun my-java-project-root (&optional dir)
  (let ((start-dir (file-name-as-directory
                    (or dir
                        (when buffer-file-name
                          (file-name-directory buffer-file-name))
                        default-directory))))
    (or
     (locate-dominating-file start-dir ".project")
     (locate-dominating-file start-dir ".classpath")
     (locate-dominating-file start-dir "pom.xml")
     (locate-dominating-file start-dir "build.gradle")
     start-dir)))


(defun my-jdtls-command (&rest _)
  (let* ((root (my-java-project-root))
         (project-name (file-name-nondirectory
                        (directory-file-name root)))
         (workspace (expand-file-name
                     (concat "~/.jdtls-workspace/" project-name))))

    (message "------------------------------")
    (message "[JDTLS] Root: %s" root)
    (message "[JDTLS] Project: %s" project-name)
    (message "[JDTLS] Workspace: %s" workspace)
    (message "[JDTLS] Default dir (before): %s" default-directory)

    (make-directory workspace t)

    (message "[JDTLS] Starting server...")

    (list "jdtls" workspace)))

;; NOTE(tiago): the jdtls only works when default-directory is set to root project
;; however, if we want to keep find-file opening at current buffer dir
;; we need to restore this variable to "default" default-directory
(defun my-eglot-java-init ()
  (let ((buffer-dir default-directory)
        (project-root (my-java-project-root)))
    (setq-local my-eglot-java-buffer-directory buffer-dir)
    (setq-local default-directory project-root)
    (add-hook 'eglot-managed-mode-hook #'my-eglot-java-restore-directory nil t)
    (eglot-ensure)))

(defun my-eglot-java-restore-directory ()
  (when (bound-and-true-p my-eglot-java-buffer-directory)
    (setq-local default-directory my-eglot-java-buffer-directory)
    (kill-local-variable 'my-eglot-java-buffer-directory)
    (remove-hook 'eglot-managed-mode-hook #'my-eglot-java-restore-directory t)))

(add-hook 'java-mode-hook #'my-eglot-java-init)

(add-hook 'java-mode-hook
          (lambda ()
            (add-hook 'before-save-hook #'eglot-format-buffer nil t)))

Veja um exemplo de projeto Java com a estrutura básica (usando maven ou gradle o lsp encontrará automaticamente também).

.classpath:

<?xml version="1.0" encoding="UTF-8"?>
<classpath>
    <classpathentry kind="src" path="src"/>
    <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
    <classpathentry kind="output" path="bin"/>
</classpath>

.project:

<?xml version="1.0" encoding="UTF-8"?>
<projectDescription>
  <name>tetris-java</name>
  <comment></comment>
  <projects>
  </projects>
  <buildSpec>
  </buildSpec>
  <natures>
      <nature>org.eclipse.jdt.core.javanature</nature>
  </natures>
  <filteredResources>
      <filter>
        <id>1775684946935</id>
        <name></name>
        <type>30</type>
        <matcher>
              <id>org.eclipse.core.resources.regexFilterMatcher</id>
              <arguments>node_modules|\.git|__CREATED_BY_JAVA_LANGUAGE_SERVER__</arguments>
        </matcher>
      </filter>
  </filteredResources>
</projectDescription>

A estrutura final do seu projeto deve ser algo parecido com o modelo abaixo:

root
├── .classpath
├── .project
└── src
    └── dev
        └── tiagoaguiar
            └── projeto
                └── App.java

Será preciso abrir o Emacs a partir do terminal para ter o JAVA_HOME disponível na GUI do Emacs.

• Baixar o jdtls com homebrew
• Clonar o dotfiles
• Criar links simbólicos para ~/.emacs, ~/.emacs.d
• Copiar o script jdtls para ~/bin
• Garantir que ~/bin esteja no PATH
• Estruturar projeto java com .project e .classpath na raiz

O primeiro passo que todo programador faz - ou deveria fazer - é configurar seu ambiente de desenvolvimento com ferramentas leves e direto ao ponto, especialmente a linha de comando.

Isso inclui configurar as fontes, cores, teclas de atalho e a janela onde você passará a maior parte do seu tempo.

Agora, ninguém gosta de programar sem o seu toque único. Eu costumo configurar o estilo do meu terminal/cmd com cores que me agradam ao estilo retrô ou o clássico tema escuro com textos em branco.

Abra a linha de comando - CMD ou Terminal - com a tecla de atalho Windows + R e digite cmd.

Clique no ícone do prompt de comando, no canto superior a esquerda, acesse as propriedades do menu e personalize as fonte e cores de sua preferência.

A configuração acima utiliza a cor R=237 G=196 B=100 e a fonte Liberation Mono.

A ideia não é perder muito tempo com esses detalhes, precisa ser objetivo e direto, porque usaremos o prompt de comando apenas para gerenciar nosso projeto, rodar scripts e compilar o programa.

Só isso!

Um disco virtual simula a posição física do disco como c:\Users\yourname\somefolder para um ponto novo.

Podemos fazer isso para ter acesso rápido como por exemplo w: quando o caminho do projeto está em outra parte do disco físico.

Para criar um disco virtual, você pode usar o comando subst.

Com o parâmetro de ajuda, temos as opções disponíveis: subst /?.

Então, caso queiramos criar um ambiente virtual apontando para o w: fazemos desta forma abaixo:

subst w: c:\<pasta>

Agora, para que isso persista, vamos criar o arquivo startup.bat que irá executar este comando ao inicializar o Windows.

Abra esse arquivo com o atalho Windows + R e digite shell:startup.

Nesta pasta, caso não tenha o startup.bat, crie-o.

Abra-o com notepad e escreva:

@echo off
REM @echo off remove the output of command echo

echo configuring local disk w:
subst w: c:\game

Isso irá configurar o disco local virtual.

• @echo off desativa a saída de cada linha a seguir para não poluir o console
• REM é o comentário em um batchfile

Agora você pode acessar diretamente o ambiente de trabalho do seu jogo com cd w:.

Uma outra abordagem seria usar o caminho padrão c:\ como seu diretório HOME. Você não precisa usar seu User se você tem controle total do seu PC.

Definindo onde estará nosso projeto, c: ou w: via subst, vamos ao compilador.

Para começar a programar um jogo em C, precisamos de um compilador. Existem diversos compiladores de C. Neste projeto para o Windows vamos usar o MSVC - Microsoft Visual C++.

Para ter acesso ao compilador cl é necessário baixar e instalar o Visual Studio e ativar no cmd para compilar por lá.

Faremos isso com o batchfile vcvarsall.bat.

Este script vive dentro do diretório do Visual Studio.

Eu não posso descrever exatamente onde encontrá-lo porque varia de versão para versão, mas vou adicionar o caminho da minha versão atual para que tenha como referência.

No meu caso está em c:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build\vcvarsall.bat

Se você rodar esse programa no seu terminal com o parâmetro x64, notará que o compilador ficará disponível como o comando cl para compilar em 64 bits.

Para não ter que encontrar toda vez esse script durante o trabalho, vamos criar nossos próprios scripts batchfile.

Eu uso Emacs há mais de 10 anos. O Emacs foi criado em 1976 por Richard Stallman e talvez você esteja pensando: "Nossa, este editor é antigo!".

Mas funciona para mim!

Eu, pessoalmente, sempre usei o Vim desde o meu primeiro ano como programador. Mesmo durante o meu estágio, meu chefe me "ensinou" - leia-se obrigou - programar e navegar rapidamente em qualquer editor. Foi difícil no começo, mas hoje vejo que valeu 100% o esforço em aprendê-lo.

Mas depois de anos usando o Vim (e depois neovim), eu conheci o Emacs e simplesmente decidi ir para esse lado da força.

Configurei bastante, gastando muitas semanas, talvez até meses - no qual hoje me arrependo ter me dedicado tanto aos detalhes e ao perfeccionismo, deveria ter focado mais em programar - e agora ele se tornou meu editor favorito. Gosto de combinar o poder do Emacs com o Vim através do Evil Mode para simular as combinações de teclas do Vim dentro do Emacs.

Então, caso queira seguir o meu workflow atual, instale o Emacs no Windows. A versão que baixei enquanto escrevo o texto foi emacs-30.1, mas você pode usar a mais recente disponível.

O Emacs funciona com Elisp escrito no arquivo .emacs que deve ficar na pasta HOME ~/ para inicialização.

Como o Windows não possui um HOME da mesma forma como unix, eu adiciono na variável de ambiente HOME=c:\. Assim, o Emacs olha para c:\ para procurar o arquivo .emacs.

Você pode encontrar minha versão do arquivo .emacs e da pasta .emacs.d em meu dotfiles.

No .emacs.d inclui temas, snippets de códigos, scripts e muito mais.

A propósito, caso queira conhecer o tema que criei para a IDE da JetBrains - alerta nerd - com algumas cores que uso no próprio Emacs, vou deixar o link aqui de referência. Eu o chamei de Terminator Theme.

Contudo, há uma pegadinha aqui. Nos dias atuais, o Windows não permite que o Emacs escreva arquivos diretamente no c: a menos que se seja um usuário Admnistrador. Logo, eu gosto de desativar qualquer "exigência" de privilégios para meu próprio computador.

"Mas Tiago, isso não deixa vunerável a virus?"

Se você souber onde acessa, o melhor antivirus, é você!

Eu desativo o UAC pelo Registry Editor o que permite acessar c: com todos os privilégios.

Abra novamente o atalho Windows + R e digite regedit.

Navegue até essa sub-chave:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Policies\system

No painel à direita da chave System, encontre EnableLUA DWORD a troque ele para o valor zero.

Reinicie o PC para aplicar as modificações após salvar.

Como dito, encontrar o script vcvarsall.bat toda vez é chato, então vamos criar um outro que nos ajude e que fique fácil de acessar a partir do projeto.

Crie um script com algum nome, como shell.bat e coloque ele onde preferir, seja no diretório do seu game como em \misc ou no próprio c:\bin por exemplo.

Geralmente eu crio o diretório c:\bin onde eu posso adicionar qualquer script que ficará visível pelo PATH do sistema operacional.

@echo off
REM @echo off remove the output of command echo
echo "configure shell for w: (c:\game)"

REM configure compiler
call "c:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build\vcvarsall.bat" x64

REM configure emacs
IF NOT EXIST "c:\bin"      mklink /d "c:\bin"      "c:\dotfiles\bin"
IF NOT EXIST "c:\.emacs.d" mklink /d "c:\.emacs.d" "c:\dotfiles\.emacs.d"
IF NOT EXIST "c:\.emacs"   mklink    "c:\.emacs"   "c:\dotfiles\.emacs"
type nul > "c:\.emacs-custom.el"

REM scripts on path
set PATH=w:\misc;%PATH%

O script basicamente irá:

• chamar o vcvarsall para ativar o compilador;
• configurar o Emacs (editor de texto que falarei mais a frente), criando arquivos e links simbólicos;
• colocar o diretório \misc do projeto no PATH para rodar scripts - pode ser o c:\bin se preferir;

Os meus scripts e arquivos de configuração ficam no meu dotfiles que você pode acessar e copiar para o seu diretório do game \misc.

Também crie o script emacs.bat dentro do mesmo diretório do shell.bat caso queira iniciar o emacs direto pela linha de comando.

@echo off
REM @echo off remove the output of command echo
call "C:\Program Files\Emacs\emacs-30.1\bin\runemacs.exe" 

Você pode fazer o seu atalho do cmd iniciar o seu script shell.bat se preferir.

No atalho, acesse "Properties" > "Target Field" e adicione o argumento na caixa do atalho: /k w:\misc\shell.bat - ou o caminho que você definiu seu shell.bat.

Agora, sempre que o cmd abrir, ele vai configurar todo Emacs, compilador e o PATH para rodar os scripts que estão em w:\misc

Temos tudo que precisamos para começar.

1. Terminal
2. Compilador
3. Editor de Texto

Agora, crie a pasta src dentro do diretório raiz do projeto com os arquivos win32_<project_name>.cpp e build.bat.

Eu aprendi a adicionar o nome do projeto no arquivo para evitar conflitos de nomes com bibliotecas de terceiros no C. Por exemplo, um platform.h pode haver em diversos lugares, logo eu usaria <project_name>_platform.h.

Por padrão, ao digitar no teclado há um atraso na saída do editor. Você pode alterar a velocidade de output de cada caracter ajustando o controle de entrada do teclado.

Acesse Windows + R > control keyboard e altere a velocidade do input.

Os passos podem parecer grande, mas não é. Ao seguir o passo a passo, você notará que esse fluxo de trabalho é muito simples, rápido e produtivo.

Você só precisa:

1. Abrir o terminal;
2. Abrir o Emacs;
3. Escrever o código;
4. Compilar;
5. Testar com Debugging;

A estrutura final é bem simples.

project_name
├── data
├── misc
├── build
└── src
    ├── build.bat
    └── win32_project_name.cpp

• Configurar o terminal com fontes e cores
• Configurar disco local virtual com subst e startup.bat
• Instalar o Visual Studio
• Instalar o Emacs e configurar .emacs no diretório c:\
• Configurar Privilégios do Windows e atribuir HOME c:\ nas variáveis de ambiente
• Criar o shell.bat para ativar compilador e o PATH c:\bin
• Criar o emacs.bat para iniciar Emacs pelo cmd
• Configurar o atalho do cmd para iniciar o shell.bat
• Escrever o build.bat para compilar o programa
• Escrever o arquivo principal com o ponto de entrada WinMain e um 'Hello World' com MessageBox
• Configurar a pasta data para diretório de funcionamento do Visual Studio
• Testar a depuração com Visual Studio