Idea → Sistema

El camino de una idea a un sistema que funciona.

Una biblioteca de conocimiento sobre desarrollo, infraestructura, seguridad e IA. Cada artículo abre con un resumen de una línea, sigue en lenguaje llano para quien nunca ha construido un sistema así, y cierra con un recuadro “En profundidad” con las decisiones de ingeniería.

Ir a la bibliotecaPrincipios de lectura

Tres reglas que se repiten en cada artículo

Las herramientas cambian cada año. El orden de las decisiones no.

1

Primero el problema, después la herramienta

Elegir tecnología antes de definir el problema es una apuesta que cuesta meses.

2

Evidencia antes que compromiso

La semana más barata para descubrir que te equivocaste es la primera, no el sexto mes.

3

Lo que no se mide no mejora

Sin medición todo cambio es una creencia, y toda discusión la gana quien habla más fuerte.

La biblioteca

100 artículos en ocho áreas. Busca, filtra o simplemente recorre la lista.

Fundamentos de producto

De una idea a una definición sobre la que se puede construir

12 artículos
001De una idea a un problema que se puede resolverAntes de elegir tecnología, escribe quién sufre el problema, qué hace hoy en su lugar y cómo sabrás que lo has resuelto.002El prototipo más pequeño que demuestra algoUn prototipo existe para responder a una pregunta peligrosa, no para lucir un producto: por eso puede ser feo, manual e incompleto.003Escribir una especificación que el equipo lea de verdadUna buena especificación describe comportamiento y criterios de aceptación, no maquetas: y se mide en páginas, no en decenas.004Elegir qué no construirLa capacidad de decir no es lo que separa un producto que se lanzó de uno que se desarrolla para siempre.005Cuánto tardará: estimaciones sin ilusionesUna buena estimación es un rango con supuestos visibles, que se actualiza a medida que crece el conocimiento, no un único número dicho una vez.006Construir, comprar o integrarConstruye solo lo que te hace distintivo; todo lo demás: cómpralo, intégralo o renuncia a ello.007Investigación de usuarios en tres díasCinco conversaciones de media hora con quienes hacen el trabajo revelan más que una encuesta de mil respuestas.008Métricas de éxito que no mientenElige una métrica ligada al valor que recibió el usuario, y a su lado una que te impida romper otra cosa.009Deuda técnica: cuándo tomarla y cuándo pagarlaLa deuda técnica es un instrumento de financiación legítimo, siempre que se tome a conciencia, se registre y tenga una fecha en que se hable de su pago.010Primera versión: qué debe entrarLa primera versión debe hacer una cosa de principio a fin, y hacerla de un modo en que puedas confiar.011Cómo priorizar cuando todos gritanPriorizar no es una lista ordenada sino una regla de decisión que todos conocen de antemano; si no, la fija quien habla más fuerte.012De la especificación a tareas con las que empezar a trabajarUna buena tarea termina en un resultado que puedes ejecutar y comprobar, y dura un día o dos, ni una semana ni una hora.

Web y frontend

Sitios y aplicaciones en el navegador

8 artículos
013Elegir entre sitio estático, sitio renderizado en servidor y app de navegadorCuanto más fijo es el contenido, más simple debe ser la arquitectura; y cada capa de dinamismo que añades la pagas todos los días desde entonces.014Rendimiento en el navegador: qué frena de verdad un sitioEn la mayoría de los sitios lentos el culpable no es el código sino el peso: imágenes grandes, fuentes y scripts de terceros.015Accesibilidad: el mínimo que no puedes saltarteLa mayor parte de la accesibilidad viene de escribir HTML correcto, y la mayoría de los fallos vienen de reemplazar elementos estándar por algo dibujado para parecerse a ellos.016Diseño adaptable sin dolorEmpieza por la pantalla pequeña, deja que el contenido decida dónde se rompe, y no diseñes para una lista de dispositivos.017SEO técnico para sitios modernosAntes de las palabras clave, asegúrate de que el buscador llega a la página, la lee y entiende qué es.018Gestión de estado en una app webLa mayor parte de lo que se llama estado son datos de servidor guardados en el sitio equivocado; sepáralos y la mitad de la complejidad desaparece.019Formularios: la parte donde más se rompe a los usuariosUn buen formulario pide poco, comprueba en el momento adecuado, explica un error donde ocurrió, y no borra lo tecleado.020Hebreo y de derecha a izquierda: qué se rompe y cómo arreglarloLa mayoría de los fallos de derecha a izquierda vienen de usar izquierda y derecha en vez de inicio y fin, y de texto mixto que choca en una línea.

Apps móviles

De la tienda de aplicaciones al parche urgente

11 artículos
021Nativa, multiplataforma o un sitio web móvilLa elección la fija cuánto necesitas del dispositivo y el tamaño del equipo, no qué tecnología está de moda este año.022Trabajar sin red: una app que no se rompe en un ascensorDiseña la app en torno al supuesto de que no hay red, y obtendrás gratis una app que además se siente rápida cuando la hay.023Notificaciones push sin perder usuariosUna notificación justificada es una cuya ausencia el usuario lamentaría; todo lo demás lleva a apagar el permiso, algo casi irreversible.024Pasar la revisión de la tienda a la primeraLa mayoría de los rechazos vienen de los metadatos y los permisos, no del código, y se pueden evitar con una hora de preparación.025Rendimiento en móvil: memoria, batería y la sensación de velocidadEn las apps, la sensación la fijan el tiempo de arranque y la fluidez del desplazamiento, y ambos los rompen las imágenes y el trabajo que corre en el hilo principal.026Almacenamiento local y datos sensibles en el dispositivoDa por hecho que el dispositivo se perderá o será vulnerado: lo que se guarde en local debe ser mínimo, cifrado y revocable en remoto.027Versiones y compatibilidad hacia atrás en appsLos usuarios tienen versiones viejas durante meses; el servidor debe soportarlas y saber cuándo parar.028Experiencia de usuario en móvil: qué cambia frente a una pantalla grandeEn el móvil el usuario está de pie, con prisa, sujetando con una mano y a veces al sol, y eso cambia cada decisión.029Monitorización de fallos y errores en una appSin reporte automático de fallos te enteras de los problemas por las valoraciones de la tienda; es decir, demasiado tarde.030Despliegue gradual e interruptores de capacidadPublica a un pequeño porcentaje, observa las métricas y expande; y mantén la capacidad de apagar una función sin publicar una versión.031Archivos, medios y subidas desde el dispositivoUna foto de la cámara pesa decenas de veces más de lo necesario; trátala en el dispositivo antes de que toque la red.

Backend, APIs y datos

El lado que nadie ve y todos sienten

15 artículos
032Diseñar una interfaz con la que puedas convivirUna buena interfaz es predecible, consistente y aburrida; cada sorpresa en ella se vuelve una pregunta recurrente y un fallo para quien la usa.033Versionar interfaces: cómo cambiar sin romperPublicaste una interfaz: te comprometiste. Un cambio que rompe exige una nueva versión, un periodo de solapamiento y un aviso previo.034Bases de datos: elegir y no arrepentirseEn la mayoría de los casos una base de datos relacional es la respuesta correcta, y cualquier otra elección necesita un motivo que puedas decir en una frase.035Migraciones de esquema sin tiempo de caídaCambia el esquema en pasos compatibles hacia atrás: añade, rellena, cambia, y solo al final: elimina.036Colas y trabajos en segundo planoTodo lo que dure más de un segundo y no haga falta para la respuesta al usuario pertenece a una cola, no a la petición.037Caché: acelerar sin servir datos viejosAntes de añadir una caché, decide cuánto tiempo un dato viejo sigue siendo aceptable: es la única pregunta que de verdad importa.038Autenticación y autorización: quién eres y qué tienes permitidoIdentidad y autorización son dos preguntas distintas, y la mayoría de las brechas vienen de que la segunda se comprueba en la interfaz y no en el servidor.039Un servicio o muchos: cuándo dividirEmpieza con un sistema bien ordenado. Divide solo cuando haya dolor real: equipos que se bloquean entre sí o un componente que necesita otra escala.040Diseñar un modelo de datos que dure añosUn buen modelo representa la realidad del negocio, no la primera pantalla que te pidieron construir.041Fiabilidad en las llamadas a servicios externosCada llamada que sale fallará en algún momento; la única pregunta es si planificaste qué ocurre entonces.042Archivos y almacenamiento de objetosLos archivos no pertenecen a la base de datos ni al disco del servidor, sino al almacenamiento de objetos con direcciones firmadas.043Búsqueda: cuándo la base de datos deja de ser suficienteLa búsqueda de texto libre con relevancia, errores tipográficos y múltiples filtros es un mundo propio, y no todo sistema lo necesita.044Correo saliente, mensajes y webhooksLos mensajes salientes son una interfaz pública: necesitan una cola, reintentos y un registro de qué se envió a quién.045Carga: límites de tasa y autoprotecciónUn sistema sano rechaza pronto y con claridad, en vez de derrumbarse lentamente bajo una carga que no puede soportar.046Trabajar con dinero: pagos y cargosNunca guardes datos de tarjeta, nunca confíes en una cantidad que llegó del cliente, y mantén siempre un registro inmutable de eventos.

Infraestructura, nube y DevOps

Cómo el código llega a producción y se queda ahí

14 artículos
047Entornos: desarrollo, pruebas y producciónTres entornos construidos desde la misma definición, que difieren solo en configuración y datos; cualquier otra diferencia es un fallo que espera ser encontrado.048Contenedores: qué aportan y cuándo sobranUn contenedor empaqueta la app con todo lo que necesita para correr, de modo que se comporta igual en todas partes.049Infraestructura como códigoSi no puedes reproducir el entorno desde un archivo en el control de versiones, no tienes infraestructura sino un historial de clics.050Una tubería automatizada de construcción y despliegueCada fusión debería disparar la misma secuencia: construcción, pruebas, comprobaciones de seguridad, despliegue; sin un solo paso manual en medio.051Estrategias de despliegue: azul-verde, canario y gradualUn buen despliegue se mide por la capacidad de revertir rápido, no por la velocidad de salir.052Monitorización y observabilidad: saber que algo se rompió antes que el clienteTres tipos de señal —métricas, registros y trazas— y una pregunta que deben responder: qué ocurre ahora y por qué.053Copia de seguridad y recuperación: lo que no se prueba no existeUna copia de seguridad no es una política; una política es cuántos datos puedes perder y cuánto tiempo puedes estar caído, y la prueba de que lo cumpliste.054Costes de la nube: adónde va el dineroLa mayor parte de la factura viene de tres sitios: recursos que corren y nadie necesita, almacenamiento que crece sin política, y tráfico entre regiones.055Escala: horizontal, vertical y lo que de verdad hace faltaAntes de escalar, mide dónde está el cuello de botella; en la mayoría de los sistemas está en la base de datos o en una consulta, no en el número de servidores.056Redes y certificados: dominio, DNS y HTTPSLa mayoría de los incidentes de 'el sitio no carga' son un dominio, un certificado caducado o el enrutamiento, no el código.057Gestionar secretos y clavesUn secreto en el repositorio de código es un secreto filtrado, aunque el repositorio sea privado y aunque lo borraras después.058Revisión de incidentes sin buscar culpablesTras cada incidente merece la pena una hora de revisión escrita centrada en el sistema, no en la persona; si no, el mismo incidente volverá.059Alta disponibilidad y recuperación ante desastresDecide cuánto te cuesta una hora de caída y solo entonces decide cuánta redundancia compras.060Registros: guardar bien y encontrar rápidoUn buen registro está estructurado, identificado con un ID de petición, guardado durante un tiempo definido, y libre de información personal que no tiene motivo de estar ahí.

Seguridad

Pensar como un atacante antes de que él lo haga

14 artículos
061Un modelo de amenazas en una horaEsboza qué tienes, quién podría quererlo y dónde cruza un límite, y obtendrás una lista de prioridades real en vez de una corazonada.062Los diez fallos que se repiten en cada auditoríaLa mayoría de los hallazgos no son sofisticados: permisos no comprobados en el servidor, entrada que llega a una consulta, y bibliotecas viejas.063Contraseñas, doble factor y sesionesGuarda las contraseñas con un algoritmo lento dedicado, habilita el doble factor, y haz posible cerrar sesión en todos los dispositivos.064Inyecciones: separar una instrucción de los datosCada lugar donde una cadena del usuario se ensambla en un comando es una brecha; la solución son parámetros, no filtrado.065Asegurar las interfaces públicasUna interfaz abierta a internet se escanea automáticamente desde el primer día; da por hecho que cada ruta se llamará, en cualquier orden, con cualquier entrada.066La cadena de suministro del códigoTu código es una minoría de lo que corre en producción; la mayor parte del riesgo está en los paquetes que trajiste y en las herramientas que los construyeron.067Cifrado: cuándo, dónde y cómo no equivocarseUsa bibliotecas conocidas con valores por defecto modernos, y no inventes nada; casi todo fallo de cifrado es un fallo de uso.068Permisos en la nube: la regla más importante es el mínimoLa mayoría de los incidentes graves en la nube empiezan con una identidad que tiene más permisos de los que necesita y sin caducidad.069Privacidad desde el diseño: recoger menosLa forma más barata de proteger la información es no recogerla; y cada campo recopilado debe tener una finalidad, un propietario y una fecha de borrado.070Seguridad en el navegador: protecciones que se activan en las cabecerasGran parte de los ataques del lado del cliente se bloquean con unas pocas cabeceras de respuesta y unos ajustes correctos de las cookies.071Seguridad del equipo: donde empiezan la mayoría de las brechasIncluso un sistema seguro se vulnera a través del dispositivo de un empleado, un correo de phishing o una cuenta sin doble factor.072Pruebas de seguridad: qué pedir y cuándoEl escaneo automático es higiene continua; una prueba de penetración es un evento enfocado, y ambos necesitan un objetivo escrito.073Seguridad en sistemas basados en modelosUn modelo añade dos riesgos nuevos: contenido externo interpretado como una instrucción, y salida que llega a un lugar sensible sin comprobación.074Prepararse para un incidente antes de que ocurraDurante un incidente no hay tiempo para decidir quién decide; el papel escrito una mañana tranquila es la diferencia entre una hora y una semana.

IA en la práctica

De un modelo a un sistema que funciona

16 artículos
075Cómo elegir un modelo, y por qué no es la primera decisiónEmpieza con el modelo más potente para comprobar si la tarea es resoluble, y solo entonces baja a uno más barato hasta que la calidad se rompa.076Conectar tu conocimiento al modelo: recuperación sin palabras grandesEl modelo no conoce tus documentos; necesitas encontrar los fragmentos relevantes para cada pregunta y adjuntarlos a la indicación.077Agentes: cuándo dejar que el sistema actúe soloUn agente decide por sí mismo qué acciones realizar; toda la recompensa y el riesgo están en los permisos que le diste.078Indicaciones: escribe una especificación, no un conjuroUna buena indicación define un rol, la entrada, las reglas de decisión y la estructura de salida, y se trata como código, en control de versiones y con pruebas.079Evaluación: cómo saber que el sistema mejoróSin un conjunto de evaluación fijo, cada cambio es una creencia, y una mejora en un área ocultará una regresión en otra.080Costes y latencia en sistemas basados en modelosLa mayor parte del coste viene del texto que entra, y la mayor parte de la latencia del que sale; por eso las dos soluciones son distintas.081Clasificación y extracción: las tareas que más devuelvenAntes de construir un chat, comprueba si el problema es en realidad clasificar una consulta o extraer campos de un documento: dos tareas simples que devuelven valor inmediato.082Alucinaciones: por qué ocurren y qué ayuda de verdadUn modelo al que se le hace una pregunta sin respuesta producirá una respuesta plausible; la solución no es pedirle que no cometa errores, sino darle una fuente y una forma de decir que no.083Datos: de dónde vienen y qué hacer cuando no hayEn la mayoría de los proyectos los datos existen pero están dispersos, sin etiquetar y sin limpiar, y esa es la etapa que se lleva la mayor parte del tiempo.084Diseñar una interfaz para un sistema que no siempre aciertaUna buena interfaz muestra la certeza variable, permite la corrección fácil, y no presenta una suposición como un hecho.085Sesgo, equidad y responsabilidad en el uso de modelosUn modelo refleja lo que vio; por eso las decisiones que afectan a personas requieren comprobación por segmentos, una persona en el bucle y documentación.086Modelos pequeños, locales y en el bordeCuando el volumen es grande, la latencia es crítica o los datos no pueden salir, un modelo pequeño en tu lado supera a uno grande en la nube.087Automatización de procesos: dónde un modelo añade y dónde sobraSi el proceso es fijo y claro, escribe código; un modelo vale exactamente en los lugares donde hace falta juicio sobre texto no estructurado.088Experimentos: cómo saber que el cambio mejoró algoCompara dos versiones en el mismo tráfico al mismo tiempo; cualquier comparación de 'antes y después' también mide el mundo, no solo a ti.089Arquitectura de un sistema basado en modelosEl modelo es un componente dentro de un sistema ordinario, y el sistema a su alrededor es la mayor parte del trabajo y del riesgo.090Operar un sistema de IA a lo largo del tiempoLos modelos se reemplazan, los documentos cambian y los usuarios aprenden a preguntar de otra manera; un sistema al que no se ha tocado en seis meses es casi siempre peor.

Oficio, calidad y equipos

Lo que convierte el código en trabajo profesional

10 artículos
091Pruebas: cuántas, cuáles y cuáles no valen la penaInvierte en una mayoría de pruebas que ejerciten tu lógica, algunas de integración, y muy pocas de extremo a extremo.092Revisión de código que mejora en vez de retrasarUna buena revisión es pequeña, rápida y centrada en la corrección y la mantenibilidad, no en las preferencias de estilo que una herramienta automática debería aplicar.093Trabajar con versiones: ramas, fusiones e historialLas ramas cortas y las fusiones frecuentes evitan la mayor parte del dolor de versiones, y un historial legible vale el esfuerzo el día que investigas un incidente.094Documentación que la gente lee de verdadDocumenta lo que no se puede inferir del código: decisiones, límites y la forma de empezar; todo lo demás envejece y engaña.095Incorporar a un nuevo desarrollador en una semana, no en un mesLa métrica es cuánto tiempo pasa hasta el primer cambio en producción, y la mayor parte del retraso son los accesos y la configuración local, no entender el código.096Nombres, estructura y código al que se puede volverEl código se lee mucho más de lo que se escribe, por eso un nombre preciso y una estructura predecible valen más que cualquier ingenio.097Elegir tecnología sin arrepentirse en dos añosElige por el equipo, la madurez y la comunidad, y lo aburrido y familiar casi siempre supera a lo nuevo y emocionante.098Calidad sin burocracia: cómo no romper lo que funcionaLas regresiones se previenen con tres cosas: pruebas automáticas, publicaciones pequeñas y frecuentes, y la capacidad de revertir rápido.099Trabajar con proveedores y contratistas de desarrolloDefine los entregables, la propiedad y el acceso por escrito de antemano, y pide entrega continua, no una gran entrega al final.100Qué decide de verdad si un proyecto tiene éxitoNo la tecnología ni el tamaño del equipo, sino la claridad del objetivo, los ciclos de retroalimentación cortos y una persona responsable de decidir.

Sobre Boomalaya

“Boom” es el momento en que una idea choca con la realidad, y las ondas que siguen son el trabajo de verdad. Boomalaya es un lugar para aprender ese camino: no una lista de herramientas que cambia cada mes, sino un orden de decisiones que sigue siendo válido aunque cambie la tecnología debajo.

Nuestras apps

Boomalaya también es un estudio de iOS. Estas tres apps se apoyan en los mismos principios que describen los artículos: procesamiento en el dispositivo, sin servidores, sin cuenta, sin rastreo.

MonoBand: AI Stem Splitter

Convierte cualquier canción que tengas en un estudio de práctica y remezcla, todo en el dispositivo, sin internet ni suscripción.

  • Separación en 6 pistas con un modelo de IA que corre en el dispositivo: voz, batería, bajo, guitarra, piano y más
  • Herramientas de práctica: transponer, cambiar la velocidad sin cambiar el tono, bucle A→B y detección automática de acordes, tempo y tonalidad
  • CarPlay: karaoke con un toque, y silenciar o aislar cualquier instrumento mientras conduces
  • Sin servidores, sin analítica y sin cuenta: tus canciones y grabaciones nunca salen del dispositivo

Gratis · Música · iPhone, iPad, Mac · 8 idiomas

En el App StoreEn hebreo
MonoBand: AI Stem Splitter — Produce music beats like prosMonoBand: AI Stem Splitter — On device. Offline. Yours.MonoBand: AI Stem Splitter — Isolate any part and play it yourselfMonoBand: AI Stem Splitter — Sing or play and record on topMonoBand: AI Stem Splitter — Drill any section till you nail itMonoBand: AI Stem Splitter — Playlists that play back-to-backMonoBand: AI Stem Splitter — On-device AI, no internetMonoBand: AI Stem Splitter — Record vocals over the song

Block AI

Un puzle de bloques clásico con progresión construida por IA: corre en local, sin anuncios y sin cuenta.

  • Modo aventura con 100 fases generadas por IA
  • Dificultad adaptativa que reacciona a tu forma de jugar
  • Un entrenador de IA que analiza hábitos, errores y fortalezas
  • Cuatro modos de juego: puzle diario, carrera infinita, contrarreloj y aventura

Gratis · Puzles · iPhone · Clasificaciones de Game Center

En el App StoreEn hebreo
Block AI — Block AI home screen and game modesBlock AI — Block puzzle gameplayBlock AI — Adventure stage previewBlock AI — AI building the Adventure stagesBlock AI — AI Coach analysisBlock AI — Play statisticsBlock AI — Stage clearedBlock AI — How to play

AIKeyMoji: AI Sticker Keyboard

Un teclado que convierte cualquier foto o vídeo en una pegatina personal, con IA que corre en el propio dispositivo.

  • Foto → la IA quita el fondo → una pegatina limpia, en segundos
  • Toma un fotograma de un vídeo, o una pegatina animada de tres segundos
  • 728 pegatinas animadas integradas en diez categorías, con búsqueda en vivo
  • Funciona en cualquier app donde escribas; sin servidores, sin rastreo y sin cuenta

Gratis · Gráficos y diseño · iPhone, iPad · Inglés y hebreo

En el App StoreEn hebreo
AIKeyMoji: AI Sticker Keyboard — Stickers from anythingAIKeyMoji: AI Sticker Keyboard — Send from any chat, one tapAIKeyMoji: AI Sticker Keyboard — Five ways to make a stickerAIKeyMoji: AI Sticker Keyboard — Video to animated stickerAIKeyMoji: AI Sticker Keyboard — 728 stickers, organizedAIKeyMoji: AI Sticker Keyboard — Your photos stay private

Boomalaya · App Store

Contacto

Una pregunta, una corrección o una propuesta de artículo: escríbenos.

Support@boomalaya.com