Herramientas
Herramientas
Agrupadas por el problema que resuelven, no por popularidad. Un CTO no se vende con cuarenta logos.
Backend
- PHP
- Laravel
- Node.js
- TypeScript
- Python
- Java
- C#
- Spring Boot
Frontend
- React
- Next.js
- Vue.js
- Angular
- Astro
- Tailwind CSS
- Ionic
Datos
- PostgreSQL
- MySQL
- SQL Server
- MongoDB
- Redis
- Drizzle
Infraestructura
- Docker
- Docker Compose
- GitHub Actions
- VPS
- AWS S3
- Nginx
- CI/CD
Pagos
- Stripe
- PaymentIntents
- Stripe Connect
- Webhooks
- SPEI
- CFDI
Móvil
- Flutter
- Ionic
- Telnyx WebRTC
- Android
Cómo trabajo
Cuatro cosas en las que sí creo
- 01
Los conceptos van antes que el código
Un framework se aprende en dos semanas y se olvida cuando sale el siguiente. Los patrones, el modelado de datos y los límites de un sistema te duran la carrera.
- 02
Lo que se puede probar por ausencia, se prueba por ausencia
Una garantía negativa escrita en un README no falla nunca. Un script que la verifica sí. Prefiero la segunda, aunque cueste más escribirla.
- 03
El modo de falla se decide en el tipo, no en el review
Si algo no debe poder pasar, que el sistema de tipos o la base de datos lo impidan. Pedirle disciplina a las personas es una estrategia que caduca.
- 04
La abstracción se gana su lugar
Una interfaz por cada clase es ceremonia. Poner la única interfaz del proyecto exactamente en el límite externo —donde permite testear sin un tercero— es criterio.
Las herramientas sin evidencia no valen nada. Cada una de estas aparece en los casos de estudio, con el problema que resolvió y lo que se descartó.