Ezequias
Rocha

Enunciado

Dadas as trajetórias de check-in de usuários do Foursquare em Nova York, decida quais pares de usuários são amigos. Não existe rótulo de amizade no treino. O sinal vem só de onde, quando e em que tipo de lugar cada pessoa esteve.

O repositório replica Aspect-oriented unsupervised social link inference on user trajectory data (Byun, Choi e Kim, Information Sciences, vol. 626, 2023) em cerca de 2.400 linhas de Python, divididas em 8 módulos.

Entrada

Check-ins com usuário, POI, horário, categoria e coordenadas. O horário vira um de 168 slots semanais (dia da semana × hora), com o fuso corrigido pelo offset em minutos.

168 slots = 7 dias × 24 horas. Destacado: um slot, segunda às 19h.

Saída

Para cada par de usuários, amigo ou não. A avaliação usa os recortes NYC_20, NYC_40, NYC_60, NYC_80 e NYC_100, cada um com pares verdadeiros e falsos separados em treino, validação e teste.

Observações

• Cinco tabelas de embedding independentes, 128 dimensões cada: usuário, POI, tempo, categoria e geografia. Variantes no código: ANES, ANES_GEO, ANES_GEO_YELP, ANES_GEO_Others e LBGC_v4.
• Cada check-in vira uma tripla aspecto-orientada, projetada no estilo TransH, TransR e TransD, a família de embeddings de grafo de conhecimento.
• A perda soma três termos: margin loss, orthogonal loss (mantém o vetor de relação ortogonal ao hiperplano) e norm loss.
• A amostragem negativa faz busca binária sobre a CDF da distribuição: O(log n) por amostra em vez de varrer tudo.
• Treino com lr 1e-4, distância L1 e 1000 iterações. t-SNE para olhar o espaço aprendido.

Arquivos da solução

replication-ANES/
├── preprocessing.py
├── ANES.py          treino
├── model.py         776 linhas
├── data.py
├── loss.py          margin · orthogonal · norm
├── projection.py    TransH/R/D
├── graphutils.py
└── utils.py

Veredito

1. #1PyTorch, 8 módulosok
2. #2embeddings 5 × 128ok
3. #3projeção TransH/R/Dok
4. #4margin lossok
5. #5orthogonal + norm lossok
6. #6negativos via CDF, O(log n)ok
7. #7168 slots com fusook
8. #8t-SNE do espaçook

Enunciado

O turbo-whisper é um app de ditado por voz no estilo SuperWhisper: atalho global, waveform na tela, transcrição com OpenAI Whisper em 99 idiomas, interface em PyQt6. Ezequias fez um fork de knowall-ai/turbo-whisper e, num teclado brasileiro, o texto ditado chegava errado.

A causa: o evdev injeta scancodes crus de um teclado US-QWERTY. A tecla física que produz ' no layout americano produz ~ no ABNT. A transcrição estava certa. A digitação, não.

Exemplo

Solução

Digitar por ferramentas que respeitam o layout ativo e deixar o evdev como último recurso. O código detecta Wayland por WAYLAND_DISPLAY ou XDG_SESSION_TYPE, tenta wtype, depois xdotool type --clearmodifiers --delay, e só então cai para evdev, PyAutoGUI e clipboard.

# ordem de tentativas (esquema simplificado; o código real está no commit)
def type_text(text):
    wayland = os.environ.get("WAYLAND_DISPLAY") or \
              os.environ.get("XDG_SESSION_TYPE") == "wayland"
    if wayland and which("wtype"):
        return run(["wtype", text])
    if which("xdotool"):
        return run(["xdotool", "type", "--clearmodifiers",
                    "--delay", DELAY, text])
    # evdev: scancodes US-QWERTY; no ABNT, ' sai como ~
    return evdev(text) or pyautogui(text) or clipboard(text)

Submissões dele

1. fix: prefer xdotool/wtype over evdev for auto-typingO fix do ABNT descrito ao lado.
2. feat: language selection, headless recording, clearer offline error+143 linhas em api.py, config.py e main.py.
3. docs: self-hosted setup notes for Pop!_OSServidor faster-whisper em Docker com CUDA (--gpus all), modelo Systran/faster-whisper-small, porta exposta só em 127.0.0.1, cache do HuggingFace montado, áudio por PipeWire/PortAudio.

Veredito

1. #1detecção de Waylandok
2. #2wtypeok
3. #3xdotool --clearmodifiersok
4. #4fallback evdev/PyAutoGUI/clipboardok
5. #5seleção de idioma, headlessok
6. #6faster-whisper + CUDA em Dockerok
7. #7porta só em 127.0.0.1ok

Enunciado

Uma API REST de usuários em FastAPI. O CRUD é o pretexto. O interesse está em como ela é verificada: cada task test roda o lint antes e gera o relatório de cobertura depois, sem ninguém lembrar de rodar nada à mão.

Entrada

Corpo validado por schemas Pydantic v2: UserSchema na entrada, com EmailStr no campo de e-mail.

Saída

UserPublic para um usuário, UserList para a listagem, UserDB para o registro interno. Status codes com HTTPStatus. Usuário inexistente devolve 404 tratado.

Esteira

Encadeado com taskipy. O TestClient do FastAPI vem de uma fixture do pytest.

Ferramentas

• Poetry para dependências.
• Ruff com as regras I (imports), F, E, W, PL (pylint) e PT (estilo pytest), modo preview.
• pytest-cov com relatório HTML.

Veredito

1. #1schemas Pydantic v2ok
2. #2EmailStrok
3. #3404 tratadook
4. #4ruff I F E W PL PTok
5. #5pytest + covok
6. #6taskipy pre/postok

Enunciado

Um clone do TabNews em Next.js 13, com o cliente pg conversando com um Postgres local que sobe por infra/compose.yaml. O primeiro endpoint é /api/v1/status, e ele nasce coberto por teste de integração em Jest.

O resto é higiene de projeto que costuma ficar para depois: Prettier, .editorconfig, versão do Node travada no .nvmrc e deploy na Vercel.

Veredito

1. #1Postgres em Docker Composeok
2. #2GET /api/v1/statusok
3. #3integração com Jestok
4. #4Prettier + .editorconfigok
5. #5deploy na Vercelok