Saltar al contenido
< samuelsantana.dev />

Samuel Santana

Senior Software Engineer en Salvador, Brasil, con más de 12 años construyendo aplicaciones web. Trabajo sobre todo en el frontend, con Angular y React, y hago el backend en Node.js y NestJS cuando el producto lo pide. Abajo están las tecnologías con las que trabajo, cómo cuido la calidad en producción y dónde se puede comprobar cada cosa.

01.

Tecnologías

  • Frontend: Angular (Signals, RxJS), React, Next.js (App Router), TypeScript en modo strict, micro-frontends con Module Federation, Tailwind CSS, shadcn/ui, TanStack Query y Zustand.
  • Backend: Node.js, NestJS, Fastify, APIs REST y WebSockets, PostgreSQL con Prisma y Drizzle, Redis y BullMQ para colas, y autenticación con OAuth 2.0, OpenID Connect (Keycloak) y JWT.
  • Infraestructura: AWS (Lambda, S3, CloudFront), Vercel, Neon, Docker y GitHub Actions.
  • Diseño: implementación a partir de Figma, design tokens en el tema de Tailwind y design systems documentados en Storybook.
02.

Calidad en producción

  • Pruebas automatizadas: pruebas unitarias y de componente con Vitest, Testing Library y MSW (Jasmine y Karma en Angular), pruebas end-to-end con Playwright y Cypress, y suites de integración contra Postgres y Redis reales en el CI. En este sitio, las pruebas end-to-end corren sin backend, y las que dependen de otro origen corren en un job aparte.
  • Accesibilidad: WCAG como requisito de entrega. En el design system de Ninho, el addon de accesibilidad de Storybook reprueba el build ante cualquier violación, axe-core verifica WCAG 2 A/AA en las páginas reales durante las pruebas end-to-end, y los objetivos táctiles de 44 px se miden en Chromium como control del CI.
  • Observabilidad: Sentry para errores en producción, logs estructurados con pino y registro de auditoría. En entornos corporativos, Dynatrace, Splunk, Grafana y Kibana, además de paneles de métricas DORA para los equipos.
  • Seguridad: cookies HttpOnly y SameSite, CORS y headers de seguridad, OAuth con state, PKCE y sin token en la URL, y análisis de dependencias en el pipeline de CI.
03.

Proyectos públicos

Código que se puede leer, ejecutar y comprobar:

  • Ninho: app de salud infantil, con vacunas, consultas e hitos del desarrollo. React 19 con TypeScript strict y una API en Fastify con Clean Architecture, PostgreSQL y colas en Redis con reintentos y dead letter queue. El código es público, igual que el design system, con accesibilidad verificada en el CI.
  • rx-state-bridge: biblioteca en npm que conecta RxJS con React, Angular Signals y Vue sin el boilerplate de loading, error y éxito.
  • Este sitio: Next.js 16 en el frontend y NestJS en el backend, con una demo de micro-frontends en Module Federation.
  • BolsoVerde: app de control de ventas, comisiones y liquidaciones para pequeños vendedores, en producción.
04.

Cómo trabajo

Antes de cualquier código, escribo la especificación: el problema, los criterios de aceptación, las restricciones y lo que queda fuera. La implementación se verifica contra ella. Cuando una decisión técnica tiene alternativas reales, comparo las opciones y registro en el pull request por qué ganó una, junto con lo que se probó y se descartó. Si la decisión depende del rendimiento o del comportamiento en producción, mido antes de elegir, con la salida del build, un benchmark reproducible o los logs de producción.

Trabajo con agentes de IA dentro de ese método. Divido el trabajo en frentes independientes y entrego cada uno a un subagente con criterios escritos en común. Cada uno devuelve la evidencia de lo que hizo y dice lo que no pudo verificar. El conocimiento de cada proyecto queda en convenciones documentadas y en skills, como la que levanta este sitio de punta a punta para verificar un cambio. Lo que tiene que valer siempre se vuelve un hook o una etapa del CI. La escritura en producción, los merges y las eliminaciones quedan conmigo.

El criterio es el mismo para código de cualquier origen: tipado estricto, pruebas, CI en verde y nada dado por terminado sin prueba. Los posts de este blog son donde quedan registradas esas mediciones.

05.

Contacto

06.

Privacidad

Este sitio mide el uso de sus páginas con Pyxis, una herramienta de análisis de uso de código abierto que yo mantengo. No usa cookies, no guarda la dirección IP ni ningún identificador que dure más que la pestaña, y registra solo la página vista, de dónde vino la visita, el idioma, el país, el tipo de dispositivo y de navegador, hasta dónde se leyó un artículo, y los clics en enlaces y botones de la propia página. Quien inicia sesión para comentar sigue siendo anónimo en la medición. El sitio respeta la señal "no rastrear" del navegador (GPC y DNT), el interruptor del pie de página desactiva la medición en este navegador, y los eventos se borran después de 13 meses.