Blog

MySQL y MariaDB, MariaDB y MySQL

¿MySQL o MariaDB? Una guía práctica con 10 criterios para elegir

Elegir entre MySQL y MariaDB no es solo cuestión de nombres parecidos. Aunque comparten historia y sintaxis, hoy son productos con caminos distintos. Vamos a diseccionar los factores más relevantes para tomar una decisión bien informada.

1) Propiedad del proyecto y licencia

La base de todo es quién controla el desarrollo y bajo qué términos se distribuye.

MySQL es desarrollado y controlado por Oracle, con un modelo de doble licencia (GPL + opción empresarial propietaria). Esto puede significar que algunas características queden solo para clientes de pago.

MariaDB, por su parte, está bajo la licencia GPL completa y es impulsado por la MariaDB Foundation, con desarrollo abierto y mayor transparencia de roadmap para la comunidad.

Cuándo importa: si necesitas total libertad de uso y modificación, MariaDB puede ser más atractivo; si necesitas soporte empresarial sólido de un proveedor grande, MySQL tiene ventajas claras.

2) Compatibilidad binaria y migración

Al principio MariaDB fue un drop‑in replacement de MySQL: prácticamente podías reemplazar uno por otro sin tocar tu aplicación.

Con el tiempo esa compatibilidad ha disminuido: desde MySQL 8 en adelante, hay funciones y estructuras que no son compatibles automáticamente con MariaDB.

Cuándo importa: si ya tienes una base de datos existente, evalúa qué tan profundas son las dependencias en funciones específicas de MySQL antes de migrar.

3) Motores de almacenamiento y flexibilidad

MariaDB ofrece una gama más amplia de motores de almacenamiento (como Aria, ColumnStore, Spider o MyRocks) para adaptarse a distintos casos de uso.

MySQL, en cambio, se centra principalmente en InnoDB (muy sólido para la mayoría de casos) y ofrece menos motores adicionales en su edición comunitaria.

Ventaja: MariaDB para cargas mixtas o especializadas; MySQL si InnoDB resuelve todas tus necesidades y quieres simplicidad.

4) Rendimiento y escalabilidad

En varios benchmarks y comparativas, MariaDB suele mostrar mejoras de rendimiento en consultas complejas, replicación o concurrencia de conexiones altas.

MySQL ofrece rendimiento constante y ha incorporado optimizaciones importantes en sus versiones recientes, aunque a veces con enfoque empresarial.

Cuándo importa: en proyectos de alto rendimiento o arquitecturas distribuidas, vale la pena probar con tus propias cargas de trabajo.

5) Alta disponibilidad y clustering

Ambos soportan replicación y clustering, pero MariaDB incluye desde versiones abiertas soluciones avanzadas de replicación multi‑master y failover automático como parte de su ecosistema.

MySQL también ofrece clustering y replicación, pero algunas características clave a menudo se reservan para su edición empresarial.

Relevancia: sistemas que no pueden permitirse downtime o que requieren escalabilidad horizontal pueden preferir MariaDB por sus opciones integradas.

6) Soporte de JSON y tipos de datos modernos

MySQL tiene soporte fuerte y nativo para JSON (almacenado como objeto binario) con funciones especializadas.

MariaDB también soporta JSON, pero lo maneja como alias de LONGTEXT y difiere en algunas funciones específicas.

Impacto: si tu aplicación depende intensamente de manipulación de JSON dentro de la base de datos, compara cuidadosamente las funciones disponibles.

7) Seguridad y autenticación

Ambos ofrecen mecanismos de autenticación segura, cifrado en reposo y en tránsito, así como gestión de roles y permisos.

MariaDB incluso amplía el conjunto de plugins de validación de contraseña y ofrece cifrado a nivel de tablas temporales y binlogs.

Decisión: revisa los requisitos de tu normativa o compliance; la diferencia puede ser sutil, pero puede inclinar tu elección.

8) Ecosistema de herramientas y soporte

MySQL tiene una enorme base de usuarios y amplio soporte en herramientas de terceros, desde IDEs hasta soluciones de monitoreo y administración.

MariaDB mantiene compatibilidad con la mayoría de estas herramientas y aporta sus propias, como MariaDB Shell y MaxScale para enrutamiento y balanceo.

Consejo: si dependes de una herramienta específica en tu stack, verifica primero la compatibilidad con ambas.

9) Comunidad vs. control corporativo

MariaDB mantiene su desarrollo más dirigido por la comunidad abierta, lo que tiende a resultar en nuevas funciones y parches más rápidos.

MySQL, con control centralizado de Oracle, prioriza estabilidad y conservadurismo en nuevas funciones, lo que para algunos entornos empresariales es una virtud.

Reflexión: si valoras innovación rápida y colaboración abierta, MariaDB tiene ventaja; si prefieres estabilidad con Roadmap corporativo, MySQL puede gustarte más.

10) Soporte empresarial y servicios gestionados

MySQL cuenta con el respaldo de Oracle, lo que incluye contratos de soporte firmados por una gran empresa.

MariaDB también ofrece soporte empresarial a través de MariaDB Corporation, pero la estructura y costos pueden ser distintos.

Además, ambos están disponibles como servicios gestionados en plataformas populares (AWS, GCP, Azure), aunque las configuraciones y limitaciones pueden variar según cada proveedor.

Relevancia: si tu proyecto necesita SLA rígidos o acompañamiento profesional, compara también los acuerdos de soporte y el coste total de propiedad.

Conclusión práctica

No hay una respuesta universal: la elección depende de las prioridades de tu proyecto. Si lo que buscas es máxima libertad de código abierto, flexibilidad y características avanzadas, MariaDB suele ser la opción más atractiva. Si en cambio priorizas estabilidad, amplio soporte de herramientas y respaldo corporativo fuerte, MySQL puede encajar mejor.

Criterio	MySQL	MariaDB	Comentario
Propiedad y licencia	Oracle, GPL/Comercial	MariaDB Foundation, GPL puro	MariaDB más libre para proyectos abiertos
Compatibilidad y migración	Compatible con versiones anteriores de MySQL, pero divergente desde MySQL 8	Compatible con MySQL 5.5/5.7, drop‑in inicial	Migrar de MySQL antiguo a MariaDB suele ser sencillo
Motores de almacenamiento	InnoDB, limitado	InnoDB, Aria, ColumnStore, MyRocks, Spider	MariaDB ofrece más flexibilidad según caso de uso
Rendimiento y escalabilidad	Estable y optimizado, especialmente en entornos Oracle	Mejores benchmarks en consultas complejas y replicación	Depende de carga y tipo de consultas
Alta disponibilidad / clustering	MySQL Cluster (edición empresarial), replicación estándar	Multi‑master, replicación avanzada, MaxScale integrado	MariaDB aporta HA más accesible en open source
Soporte JSON / tipos modernos	JSON nativo, funciones avanzadas	JSON como alias de LONGTEXT, funciones limitadas	MySQL mejor si se trabaja intensamente con JSON
Seguridad / autenticación	Roles, cifrado, plugins Oracle	Roles, cifrado, plugins adicionales, validación de passwords	MariaDB añade opciones extras open source
Ecosistema de herramientas	Amplia compatibilidad, IDEs y monitoreo	Compatible con la mayoría, plus MaxScale y MariaDB Shell	Ambas tienen buena cobertura, MySQL más maduro
Comunidad vs. control corporativo	Estabilidad y roadmap controlado por Oracle	Comunidad activa, desarrollo rápido y abierto	MariaDB más innovador, MySQL más conservador
Soporte empresarial / servicios gestionados	SLA Oracle, amplio soporte comercial	SLA MariaDB Corporation, opciones flexibles	Ambos disponibles en servicios cloud gestionados

Esta tabla resume lo que ya discutimos: MariaDB es más flexible, abierto y con funciones avanzadas, mientras que MySQL es más estable, ampliamente soportado y respaldado por Oracle.

03/01/2026

Fizzy
Kanban sin complicaciones para equipos y proyectos ligeros
Un tablero kanban bien diseñado puede hacer que organizar ideas, errores y pequeñas tareas vaya tanto más rápido como el café de la mañana. Fizzy es justamente eso: una aplicación de seguimiento de tareas y gestión estilo kanban enfocada en la simplicidad absoluta, sin volverse un monstruo de opciones imposibles de dominar.
Fizzy nació en Basecamp/37signals como una respuesta al crecimiento indiscriminado de herramientas tradicionales: Trello que se hincha, Jira que parece un ERP, Asana tratando de ser todo para todos. Fizzy elige otra senda: tarjetas, columnas, colores y nada más superfluo.
¿Qué es exactamente Fizzy?
Fizzy es una herramienta de tableros estilo kanban donde puedes:
- Crear tarjetas para ideas, tareas, bugs o cualquier cosa que quieras seguir.
- Organizar esas tarjetas en columnas personalizables.
- Moverlas, cerrar las completadas y mantener un flujo de trabajo visual y claro.
- Ver notificaciones, usar etiquetas y exponer tableros públicos si lo deseas.
No se vende como gestión de proyectos completa, sino como un lanzador de trabajo ligero. Es ideal para equipos pequeños, proyectos independientes o simplemente cuando no necesitas todo un tablero lleno de métricas y configuraciones complejas.
Además, el proyecto es open source: puedes ejecutarlo tú mismo, modificarlo o adaptarlo a tus necesidades sin pagar nada.
Imágenes mentales: lo que verdaderamente hace Fizzy
Piensa en Fizzy como un tablero de post-its digital que ya viene organizado para ti. No hay sprints, no hay backlog oculto, no hay módulos con 15 páginas de documentación. Solo columnas y tarjetas, con unas pocas capacidades extras que realmente importan: notificaciones que aparecen cuando las tarjetas llevan tiempo ignoradas, webhooks para integrarse con Slack/Campfire, y gestión visual sencilla. (serverspace.io)
Instalar Fizzy con Docker: rápido, directo y sin alharacas
Una de las mejores sorpresas fue lo sencillo que resulta levantar Fizzy con Docker. El repositorio oficial ya incluye un Dockerfile que te permite construir la imagen y ponerla en marcha casi sin pensar.
La mayoría de los proyectos Rails open source que he probado tienen mil dependencias, configuraciones complejas y pasos que nunca funcionan a la primera. Con Fizzy no es así: bajas el código, construyes la imagen y en cuestión de minutos tienes el sistema funcionando y listo para recibir tráfico si quieres.
No hay que luchar con montones de variables crípticas para hacer que arranque, ni buscar extensos guiones de despliegue. Ese enfoque de menos es más se nota también en cómo está pensado para contenedores. Para alguien que está acostumbrado a peregrinar entre manuales y errores crípticos, esto ya es un alivio.
Uso diario: sin distracciones
Cuando entras a Fizzy, no te recibe una pared de botones. Ves tus tableros, tus columnas y tus tarjetas. Siendo un defensor de las herramientas que desaparecen cuando no las necesitas, Fizzy logra justamente eso: no compites con la herramienta, compites con tu trabajo.
Mover una tarjeta de “Pendiente” a “Haciendo” es inmediato. Crear columnas, etiquetar cosas, cerrar elementos completados… todo se hace con un clic o arrastrando. Persiste en esa filosofía de “hacer lo esencial bien” que rara vez se encuentra fuera de aplicaciones minimalistas clásicas.
Fizzy no pretende ser un gestor de proyectos completo ni una suite repleta de módulos. Es, en cambio, un tablero kanban elegante y directo que hace lo que promete sin darte dolores de cabeza ni necesidad de horas de configuración. Que funcione tan bien con Docker desde el primer intento es una señal clara de la intención de los creadores: menos complejidad, más productividad real.
Si valoras una herramienta que se adapte a ti y no al revés, Fizzy merece un lugar en tu flujo de trabajo.
Si quieres puedo añadir capturas de ejemplo o un paso a paso detallado de un docker compose básico para Fizzy.
03/01/2026
Traducción y resumen de la guía Shape Up de Basecamp (Stop Running in Circles and Ship Work That Matters)
Shape Up – Metodología de desarrollo de producto (Basecamp)
Qué es Shape Up
Shape Up es una metodología para desarrollar productos digitales creada en Basecamp que propone ciclos de trabajo de seis semanas con un enfoque en definir bien el trabajo antes de empezarlo, dar autonomía a los equipos y reducir el riesgo de no entregar a tiempo. (uiFromMars)
En esencia, Shape Up intenta evitar los problemas comunes de otras metodologías (backlogs interminables, reuniones excesivas, microgestión) proponiendo ciclos más largos, mayor responsabilidad de los equipos y trabajos mejor preparados antes de asignarlos. (Blog de TI)
1. Shaping — Dar forma al trabajo antes de construirlo
La fase de shaping es diseño conceptual y preparación. Aquí se define qué se hará, cómo se piensa resolver y qué límites tiene el proyecto antes de que el equipo lo construya. (Basecamp)
Principios clave de shaping:
- Nivel adecuado de detalle:
  No demasiado concreto (como un diseño final) que bloquee la creatividad, ni demasiado abstracto que no dé orientación. Debe ser lo justo para que el equipo sepa qué hacer. (Ben Travis)
- Establecer límites y “apetito”:
  Antes que estimar cuánto tardará algo, se decide cuánto tiempo se quiere dedicar (p. ej., seis semanas). Esto ayuda a limitar la solución al valor que merece. (Ben Travis)
- Riesgos y huecos (“rabbit holes”):
  Identificar partes del trabajo que pueden salirse de control o ser inciertas, y eliminarlos o acotarlos antes de pasar al equipo. (Sebastien Phlix)
- Pitch:
  El resultado del shaping es un “pitch” o propuesta con 5 ingredientes:
  problema, apetito, solución, riesgos y exclusiones (qué no se hace). (Sebastien Phlix)
2. Betting — La mesa de apuestas
Luego de que varias propuestas están shaped, un grupo de decisión (a veces llamado “mesa de apuestas”) elige cuáles proyectos se van a trabajar en el próximo ciclo de seis semanas. (ProductPlan)
Ideas clave:
- No hay backlog tradicional:
  En lugar de una lista infinita de tareas, solo hay un conjunto pequeño de propuestas para cada ciclo. (prodify.group)
- Ciclos de 6 semanas + cooldown:
  Las apuestas se planifican para seis semanas sin extender plazos. Si al final del ciclo no está completo, lo que no esté hecho se descarta o replantea para otro ciclo. (gemba.es)
- Período de cooldown de ~2 semanas:
  Es un espacio para arreglar bugs, hacer mantenimiento, refactorizaciones o preparar la siguiente ronda de shaping. (Engenharia de Software Moderna)
Este enfoque con ciclos fijos y sin extensiones fomenta foco y hace que el equipo reaprenda a tomar decisiones sobre alcance y prioridades. (ProductPlan)
3. Building — Construir con autonomía
Una vez que un proyecto está elegido para un ciclo, el equipo lo construye con un alto grado de responsabilidad:
- Equipos pequeños e integrados:
  Diseñadores y desarrolladores trabajan juntos en la solución. (ProductPlan)
- Progreso de extremo a extremo:
  En lugar de fragmentar por roles (solo backend, luego frontend), se busca completar “pedazos verticales” que entreguen funcionalidad real. (prodify.group)
- Organizar por scopes, no por tareas:
  El equipo mapea y divide trabajo por “ámbitos” que representan partes completas del producto, y prioriza lo desconocido primero. (Ben Travis)
- Mostrar progreso visual:
  Se usan técnicas como la “hill chart” (gráfico de colina) para entender qué está resuelto y qué sigue siendo incierto. (prodify.group)
Principios generales del método
- Tiempo fijo, alcance variable:
  El tiempo para un ciclo es fijo (seis semanas), pero lo que finalmente se construye puede cambiar de alcance según lo aprendido. (ProductPlan)
- Menos micromanagement:
  Los equipos deciden cómo cumplir con los objetivos dentro de los límites dados, lo que reduce reuniones innecesarias y control externo. (Blog de TI)
- Resolución temprana de riesgos:
  Al hacer shaping se enfrentan incertidumbres antes de que se conviertan en problemas caros o bloqueos. (Basecamp)
Resumen de flujo
1. Shaping: preparar propuestas completas con límites y riesgos claros.
2. Betting: elegir qué se construye en el ciclo de seis semanas.
3. Building: el equipo construye con autonomía y foco en valor real.
4. Cooldown: espacio para reflexionar, arreglar y preparar el próximo ciclo. (ProductPlan)
01/01/2026

Comparando el estilo “clásico orientado a clases” con el estilo Ruby-idiomático, funcional y modular

Vamos a aterrizar la idea de Dave Thomas con código Ruby real, comparando el estilo “clásico orientado a clases” con el estilo Ruby-idiomático, funcional y modular, y viendo por qué el segundo suele envejecer mejor.

No es una religión. Es ingeniería pragmática.

1. El punto de partida clásico (el reflejo Java)

Imagina un caso típico: procesar un pedido.

Enfoque habitual con clases

class Order
  attr_reader :items, :customer

  def initialize(items:, customer:)
    @items = items
    @customer = customer
  end

  def total_price
    items.sum(&:price)
  end

  def valid?
    items.any? && customer.active?
  end
end

class OrderProcessor
  def initialize(order)
    @order = order
  end

  def process
    raise "Invalid order" unless @order.valid?

    charge_customer
    send_confirmation
  end

  private

  def charge_customer
    PaymentGateway.charge(@order.customer, @order.total_price)
  end

  def send_confirmation
    Mailer.order_confirmation(@order)
  end
end

class Order
  attr_reader :items, :customer

  def initialize(items:, customer:)
    @items = items
    @customer = customer
  end

  def total_price
    items.sum(&:price)
  end

  def valid?
    items.any? && customer.active?
  end
end

class OrderProcessor
  def initialize(order)
    @order = order
  end

  def process
    raise "Invalid order" unless @order.valid?

    charge_customer
    send_confirmation
  end

  private

  def charge_customer
    PaymentGateway.charge(@order.customer, @order.total_price)
  end

  def send_confirmation
    Mailer.order_confirmation(@order)
  end
end

Esto es correcto. También es más estructura de la necesaria.

Problemas sutiles:

Las clases no modelan cosas del mundo real, sino pasos de un flujo
La lógica está dispersa
Probar OrderProcessor implica instanciar Order
La clase existe solo para agrupar métodos

2. La propuesta de Dave Thomas: empieza por acciones

Ruby no te obliga a empezar pensando en “objetos”.
Puedes empezar pensando en verbos.

Enfoque funcional y plano

def total_price(items)
  items.sum(&:price)
end

def valid_order?(items, customer)
  items.any? && customer.active?
end

def process_order(items:, customer:)
  raise "Invalid order" unless valid_order?(items, customer)

  PaymentGateway.charge(customer, total_price(items))
  Mailer.order_confirmation(items, customer)
end

def total_price(items)
  items.sum(&:price)
end

def valid_order?(items, customer)
  items.any? && customer.active?
end

def process_order(items:, customer:)
  raise "Invalid order" unless valid_order?(items, customer)

  PaymentGateway.charge(customer, total_price(items))
  Mailer.order_confirmation(items, customer)
end

Observa algo importante:

No hay estado implícito
Cada función hace una cosa
Las dependencias son explícitas
Es trivial testear cada función

Esto ya es Ruby de primera clase, no un atajo.

3. “Pero esto queda desordenado”: módulos al rescate

Aquí es donde mucha gente se pone nerviosa.
Dave Thomas dice: no saltes a clases, usa módulos.

module Orders
  module Pricing
    def self.total(items)
      items.sum(&:price)
    end
  end

  module Validation
    def self.valid?(items, customer)
      items.any? && customer.active?
    end
  end

  module Processing
    def self.process(items:, customer:)
      raise "Invalid order" unless Validation.valid?(items, customer)

      PaymentGateway.charge(customer, Pricing.total(items))
      Mailer.order_confirmation(items, customer)
    end
  end
end

module Orders
  module Pricing
    def self.total(items)
      items.sum(&:price)
    end
  end

  module Validation
    def self.valid?(items, customer)
      items.any? && customer.active?
    end
  end

  module Processing
    def self.process(items:, customer:)
      raise "Invalid order" unless Validation.valid?(items, customer)

      PaymentGateway.charge(customer, Pricing.total(items))
      Mailer.order_confirmation(items, customer)
    end
  end
end

Esto aporta:

Namespacing claro
Ningún estado oculto
Ninguna jerarquía artificial
Código legible como un mapa mental del dominio

4. ¿Cuándo sí aparece una clase?

Dave Thomas no es anti-clases.
Las clases aparecen cuando hay identidad y estado duradero.

Ejemplo: un Money, un User, un Session.

class Money
  attr_reader :amount, :currency

  def initialize(amount, currency)
    @amount = amount
    @currency = currency
  end

  def +(other)
    raise "Currency mismatch" unless currency == other.currency
    Money.new(amount + other.amount, currency)
  end
end

class Money
  attr_reader :amount, :currency

  def initialize(amount, currency)
    @amount = amount
    @currency = currency
  end

  def +(other)
    raise "Currency mismatch" unless currency == other.currency
    Money.new(amount + other.amount, currency)
  end
end

Aquí la clase tiene sentido porque:

Tiene identidad
Encapsula invariantes
Protege reglas internas

Lo que Dave Thomas critica es crear clases solo para colgar métodos.

5. Un ejemplo muy Rails-real (Service Objects)

El patrón clásico Rails:

class CreateUser
  def initialize(params)
    @params = params
  end

  def call
    user = User.new(@params)
    user.save!
    Mailer.welcome(user)
    user
  end
end

class CreateUser
  def initialize(params)
    @params = params
  end

  def call
    user = User.new(@params)
    user.save!
    Mailer.welcome(user)
    user
  end
end

La versión “Ruby puro”:

module Users
  def self.create(params)
    user = User.create!(params)
    Mailer.welcome(user)
    user
  end
end

module Users
  def self.create(params)
    user = User.create!(params)
    Mailer.welcome(user)
    user
  end
end

Pregunta incómoda:
👉 ¿qué aporta realmente la clase CreateUser?

Respuesta honesta: nada, salvo ceremonia.

6. Beneficios reales (no filosóficos)

Después de años, este estilo suele ganar porque:

El código crece horizontalmente, no en jerarquías
Refactorizar es más fácil
Las dependencias están a la vista
Los tests no requieren dobles complejos
El dominio se expresa como lenguaje, no como UML

Esto es muy Ruby y muy Pragmatic Programmer.

7. La idea profunda del vídeo (la que no sale en el código)

La charla no va de clases.
Va de esto:

No diseñes por anticipación la forma final del sistema.
Deja que la estructura emerja del uso real.

Las clases son una decisión tardía, no el punto de partida.

01/01/2026

Resumen charla Dave Thomas
Contexto y quién habla
Dave Thomas es una figura legendaria en la comunidad Ruby: coautor de The Pragmatic Programmer, uno de los firmantes iniciales del Manifiesto Ágil, y autor de varios libros influyentes sobre Ruby y desarrollo de software. Su experiencia de décadas hace que lo que propone esté menos en plan “dogma” y más como una invitación a replantear nuestras suposiciones. (RubyEvents.org)
La tesis central: recalibrar cómo estructuramos código en Ruby
Thomas parte de una observación crítica: “Estamos escribiendo nuestro código Ruby de forma equivocada”. Esa frase es más que provocadora: es una invitación a desafiar un hábito que se ha vuelto casi automático. (sfruby.com)
Su propuesta principal es:
Dejar de usar clases como la unidad fundamental de diseño en Ruby cuando no es necesario.
Esto no significa abolir clases—sino reconsiderar su papel —especialmente cuando alternativas más simples pueden hacer el código más claro, mantenible y flexibles a cambios futuros. (sfruby.com)
¿Por qué parar con clases?
Ruby es un lenguaje extremadamente expresivo y flexible: las clases son solo una de muchas herramientas para estructurar código. Dave Thomas argumenta que:
- Hemos desarrollado una “dependencia mental” en clases por tradición más que por necesidad real.
- Diseñar todo alrededor de clases a menudo nos lleva a patrones complejos (“design patterns”) que en muchos casos son artefactos culturales de lenguajes más rígidos (como Java o C++), no de Ruby. (sfruby.com)
En otras palabras: las clases no son la unidad más natural de pensamiento en Ruby.
Un enfoque alternativo: estructura desde el crecimiento real
Cuando diseñamos software tradicionalmente:
1. Pensamos en la estructura primero.
2. Escribimos clases y jerarquías.
3. Luego codificamos.
Thomas propone algo más parecido a trabajar desde exploración y crecimiento orgánico:
1. Comienza con pequeñas funciones, módulos y bloques que reflejen exactamente lo que necesitas ahora.
2. Permite que la estructura emerja conforme el problema y su complejidad crecen.
3. Solo introduce clases o abstracciones más grandes si se vuelve claro que aportan valor. (sfruby.com)
Esto es similar al enfoque evolutivo propio del desarrollo ágil, aplicado a la forma de escribir código mismo.
Ventajas de este enfoque
Dave Thomas señala beneficios prácticos:
Simplicidad
Menos artefactos ceremoniales (clases complejas, jerarquías rígidas) significan menos sobrecarga mental, menos convenciones que memorizar, y código que “dice lo que hace”. (sfruby.com)
Mantenibilidad real
Cuando la lógica está en funciones o módulos centrados en acciones claras, es más fácil modificar y razonar sobre ellos. Esto encaja con la filosofía de mantener el código flexible y adaptativo (un principio clave del desarrollo ágil). (sfruby.com)
Menos dependencias innecesarias
Menos clases puede significar menos dependencias entre partes del sistema, lo que hace más fácil reusar, testear y reemplazar componentes. (sfruby.com)
¿Qué pasa con patrones clásicos de diseño y metodologías?
Otra parte de la charla—y probablemente la más filosófica—es que muchos de los patrones de diseño que aprendemos y aplicamos vienen del mundo de lenguajes más estáticos. En Ruby, muchas veces:
- Objetos no son lo que pensamos.
- Clases no siempre son la forma más natural de expresar una abstracción.
- DSLs (Domain Specific Languages), bloques y módulos pueden hacer el trabajo de formas más expresivas. (sfruby.com)
Esto no implica abandonar conceptos, sino reapropiarlos de forma más idiomática para Ruby.
Ejemplos implícitos en la charla
Aunque la charla en sí usa ejemplos concretos (código en vivo), el patrón general que Thomas muestra es:
- Escribir funciones pequeñas y enfocadas.
- Encapsular comportamiento relevante en módulos en vez de clases generales.
- Evitar jerarquías profundas y rígidas que enmascaran la intención real del código. (sfruby.com)
Este estilo se alinea con prácticas contemporáneas que favorecen la composición y la inmutabilidad funcional cuando tiene sentido.
Un empujón hacia pragmatismo
Este mensaje no tiene truco: no dice “deja de usar clases por decreto”, sino:
Piensa críticamente sobre cuando realmente aportan valor y cuando simplemente seguimos patrones por costumbre.
Ruby es un lenguaje expresivo; abrazar ese poder puede permitir código más simple y sostenible con menos artefactos sintácticos. (sfruby.com)
01/01/2026

Blog

MySQL y MariaDB, MariaDB y MySQL

¿MySQL o MariaDB? Una guía práctica con 10 criterios para elegir

1) Propiedad del proyecto y licencia

2) Compatibilidad binaria y migración

3) Motores de almacenamiento y flexibilidad

4) Rendimiento y escalabilidad

5) Alta disponibilidad y clustering

6) Soporte de JSON y tipos de datos modernos

7) Seguridad y autenticación

8) Ecosistema de herramientas y soporte

9) Comunidad vs. control corporativo

10) Soporte empresarial y servicios gestionados

Conclusión práctica

Fizzy

Kanban sin complicaciones para equipos y proyectos ligeros

¿Qué es exactamente Fizzy?

Imágenes mentales: lo que verdaderamente hace Fizzy

Instalar Fizzy con Docker: rápido, directo y sin alharacas

Uso diario: sin distracciones

Traducción y resumen de la guía Shape Up de Basecamp (Stop Running in Circles and Ship Work That Matters)

Shape Up – Metodología de desarrollo de producto (Basecamp)

Qué es Shape Up

1. Shaping — Dar forma al trabajo antes de construirlo

2. Betting — La mesa de apuestas

3. Building — Construir con autonomía

Principios generales del método

Resumen de flujo

Comparando el estilo “clásico orientado a clases” con el estilo Ruby-idiomático, funcional y modular

1. El punto de partida clásico (el reflejo Java)

Enfoque habitual con clases

2. La propuesta de Dave Thomas: empieza por acciones

Enfoque funcional y plano

3. “Pero esto queda desordenado”: módulos al rescate

4. ¿Cuándo sí aparece una clase?

5. Un ejemplo muy Rails-real (Service Objects)

6. Beneficios reales (no filosóficos)

7. La idea profunda del vídeo (la que no sale en el código)

Resumen charla Dave Thomas

La tesis central: recalibrar cómo estructuramos código en Ruby

¿Por qué parar con clases?

Un enfoque alternativo: estructura desde el crecimiento real

Ventajas de este enfoque

¿Qué pasa con patrones clásicos de diseño y metodologías?

Ejemplos implícitos en la charla

Un empujón hacia pragmatismo