Tutorial · DacaCode

TypeScript: Depuración de errores y tsconfig.json

Dacadev — Wed, 24 Jun 2026 00:00:00 -0500

Tabla de Contenido

Note

Artículo final de la serie sobre TypeScript. Consolidaremos la configuración del compilador mediante tsconfig.json y las opciones que facilitan la depuración y mejoran la calidad del código emitido.

El archivo tsconfig.json es el centro de control del compilador: define cómo TypeScript interpreta, verifica y transforma tu proyecto. Una configuración bien afinada no solo previene errores, sino que mejora la experiencia de depuración y la calidad del JavaScript resultante. Cerremos la serie dominando esta pieza. La referencia completa está en la documentación oficial de tsconfig.json.

Qué es tsconfig.json y para qué sirve

tsconfig.json declara el comportamiento del compilador para todo el proyecto. Cuando se genera por primera vez, muchas opciones aparecen comentadas, y el valor mostrado en el comentario suele ser el recomendado por defecto.

Info

La presencia de un tsconfig.json en un directorio marca la raíz de un proyecto TypeScript. Ejecutar tsc sin argumentos hace que el compilador busque este archivo y compile según sus reglas.

Opciones recomendadas

Estas opciones de compilerOptions aportan el mayor valor en un proyecto profesional:

strict: activa el conjunto completo de comprobaciones estrictas. Es la opción que más errores previene.
noImplicitAny: prohíbe que TypeScript asigne any de forma implícita cuando no puede inferir un tipo, obligándote a ser explícito.
removeComments: elimina los comentarios del JavaScript compilado, produciendo una salida más limpia.
sourceMap: genera source maps que enlazan el JavaScript emitido con tu código TypeScript original.

{
 "compilerOptions": {
 "strict": true,
 "noImplicitAny": true,
 "removeComments": true,
 "sourceMap": true,
 "target": "es2015",
 "module": "commonjs",
 "outDir": "dist"
 },
 "include": ["src"]
}

Tip

strict es en realidad un paraguas que activa varias comprobaciones, entre ellas noImplicitAny, strictNullChecks y strictFunctionTypes. Habilitarlo desde el primer commit evita una migración costosa cuando el proyecto ya acumuló tipos implícitos.

sourceMap: depurar el código original

Sin source maps, cuando depuras en el navegador o en Node solo ves el JavaScript transpilado, que puede diferir notablemente de tu TypeScript. Con sourceMap: true, el compilador genera archivos .js.map que permiten al depurador mostrar tu código fuente original, colocar breakpoints en él e inspeccionar variables con sus nombres reales.

Esta opción es la diferencia entre depurar el código que escribiste y depurar el código que la máquina generó.

Generar un único archivo de salida

Para ciertos escenarios —especialmente proyectos de frontend sin un bundler— resulta útil concatenar toda la salida en un solo archivo JavaScript. Esto se logra con la opción outFile:

{
 "compilerOptions": {
 "outFile": "./main.js",
 "sourceMap": true,
 "removeComments": true
 }
}

Warning

outFile solo funciona con los sistemas de módulos amd y system; no es compatible con commonjs ni esnext. En proyectos modernos, lo habitual es delegar el empaquetado a herramientas como webpack o esbuild en lugar de usar outFile.

Depurar errores con eficacia

El flujo de depuración en TypeScript combina las opciones anteriores con la lectura disciplinada de los mensajes del compilador:

Cada error incluye un código (por ejemplo TS2345) que puedes buscar para entender su causa raíz.
Con strict activo, los errores afloran en compilación, antes de ejecutar el código.
Con sourceMap, los errores en tiempo de ejecución apuntan a tu TypeScript original, no al JavaScript emitido.
El modo observador (tsc --watch) reporta los errores de forma incremental mientras escribes.

flowchart LR
 A[Código TS] --> B[tsc con strict]
 B -- error de tipo --> C[Mensaje TSxxxx
en compilación]
 B -- ok --> D[JS + sourceMap]
 D --> E[Runtime]
 E -- error --> F[Stack trace sobre TS
gracias al sourceMap]

Conclusión

tsconfig.json es la herramienta que transforma TypeScript de un transpilador genérico en un compilador afinado a tu proyecto. Activar strict y noImplicitAny maximiza la detección temprana de errores; sourceMap hace que la depuración opere sobre tu código real; y removeComments pule la salida. Dominar estas opciones cierra el ciclo: del tipado en el editor a la depuración en producción.

Con esto concluye la serie sobre TypeScript. Has recorrido desde la instalación y los tipos básicos hasta los genéricos, los decoradores y la configuración del compilador: el conjunto de herramientas necesario para construir aplicaciones robustas y mantenibles con tipado estático.

TypeScript: Namespaces, módulos e importaciones

Dacadev — Tue, 23 Jun 2026 00:00:00 -0500

Tabla de Contenido

Note

Décimo artículo de la serie sobre TypeScript. Organizaremos el código con namespaces y módulos ES: exportaciones nombradas, import, alias, export default y archivos barrel.

A medida que un proyecto crece, la organización del código deja de ser un detalle estético para convertirse en un factor de mantenibilidad. TypeScript ofrece dos mecanismos para estructurar el código: los namespaces —agrupadores internos— y los módulos ES —el estándar moderno basado en export e import. Analicemos cuándo usar cada uno.

Namespaces

Un namespace agrupa funciones, clases y variables relacionadas bajo un identificador común, exponiendo solo lo que marques con export:

namespace Validations {
 export const validateText = (text: string): boolean => {
 return text.length > 3
 }

 export const validateDate = (myDate: Date): boolean => {
 return !isNaN(myDate.valueOf())
 }
}

Validations.validateText('hola mundo')

Solo los miembros exportados (validateText, validateDate) son accesibles desde fuera mediante la notación Namespace.miembro.

Info

Los namespaces se usan cada vez menos en el desarrollo de aplicaciones, donde los módulos ES son el estándar. Sin embargo, siguen presentes como base interna de muchos frameworks y de archivos de definición de tipos (.d.ts).

Módulos: export e import

Los módulos son el mecanismo recomendado. Cada archivo es un módulo y expone su API con export; otros archivos la consumen con import. Para exportar, antepón export a la declaración:

// classes/Heros.ts
export class Hero {
 constructor(
 public name: string,
 public powerID: number,
 public age: number
 ) {}
}

Y para consumirla, usa import con desestructuración de los miembros nombrados:

// index.ts
import { Hero } from './classes/Heros'

const spiderman: Hero = new Hero('Spiderman', 100, 23)

Archivos barrel: centralizar exportaciones

Cuando una carpeta agrupa varios módulos relacionados, importarlos uno a uno desde rutas distintas se vuelve tedioso. Un archivo barrel —convencionalmente un index.ts dentro de la carpeta— reexporta todo desde un único punto de entrada:

// interfaces/index.ts
export { Hero } from './hero'
export { Villain } from './villain'

Esto permite importar múltiples miembros refiriéndote solo a la carpeta, lo que simplifica las rutas y desacopla a los consumidores de la estructura interna:

import { Hero, Villain } from './interfaces'

flowchart LR
 H[hero.ts] --> I[index.ts barrel]
 V[villain.ts] --> I
 I --> C[consumidor: import desde './interfaces']

Export alias

Un alias renombra un miembro al importarlo, lo que resuelve colisiones de nombres entre módulos distintos. Se usa la palabra clave as:

import { powers as poderes } from './data/powers'

console.log(poderes)

Export default

Una exportación por defecto designa el valor principal de un módulo. Se importa sin llaves y puede combinarse con importaciones nombradas en la misma línea:

// data/powers.ts
export default class Powers {
 /* ... */
}
export const powers = ['fuerza', 'velocidad']

import Powers, { powers as poderes } from './data/powers'

Powers corresponde a la exportación por defecto y poderes a una exportación nombrada renombrada con alias.

Tip

Prefiere las exportaciones nombradas frente a export default en bases de código grandes: facilitan el autocompletado, el refactoring automático y mantienen nombres consistentes entre el módulo y sus consumidores.

Del código a un bundle

Los módulos resuelven la organización en tiempo de desarrollo, pero el navegador necesita servir el resultado de forma eficiente. Empaquetadores como webpack combinan todos los módulos en uno o pocos archivos optimizados, resolviendo el grafo de dependencias que tejen tus import. TypeScript se integra en este flujo transpilando primero a JavaScript y dejando que el bundler se encargue del empaquetado final.

Conclusión

Estructurar el código es una decisión de arquitectura. Los namespaces agrupan elementos internos y persisten en definiciones de tipos, pero el estándar moderno son los módulos ES con export/import. Los archivos barrel centralizan las exportaciones, los alias resuelven colisiones de nombres y export default designa el valor principal de un módulo.

En el artículo final de la serie consolidaremos la configuración del compilador y la depuración de errores mediante tsconfig.json.

TypeScript: Decoradores y metaprogramación

Dacadev — Mon, 22 Jun 2026 00:00:00 -0500

Tabla de Contenido

Note

Noveno artículo de la serie sobre TypeScript. Estudiaremos los decoradores: funciones que se ejecutan en la definición de clases, métodos y propiedades para extender su comportamiento sin modificar su código original.

Un decorador en TypeScript es una función que se ejecuta en tiempo de transpilación y permite expandir la funcionalidad de un objeto —clase, método o propiedad— de forma declarativa. Frameworks como Angular o NestJS apoyan gran parte de su ergonomía en este mecanismo. Analicemos cada variante con ejemplos prácticos. Puedes consultar la referencia completa en la documentación oficial de decoradores.

Info

Los decoradores se colocan con la sintaxis @nombre justo antes del elemento a decorar. Por convención se declaran con function —en lugar de arrow functions— para distinguirlos visualmente de las funciones ordinarias.

Decoradores de clase

Un decorador de clase recibe el constructor y se ejecuta una sola vez, en el momento en que se define la clase —no al crear cada instancia:

function printToConsole(constructor: Function) {
 console.log(constructor)
}

@printToConsole
export class Pokemon {
 public publicApi: string = 'https://pokeapi.co'

 constructor(public name: string) {}
}

Al crear varias instancias, el decorador no vuelve a ejecutarse: su efecto ocurre en la definición, no en la instanciación.

Decoradores de fábrica

Un decorador de fábrica es una función que retorna el decorador real. Esto permite parametrizar el comportamiento, aceptando argumentos que controlan cómo se aplica:

function printToConsole(constructor: Function) {
 console.log(constructor)
}

const printToConsoleConditional = (print: boolean = true): Function => {
 return print ? printToConsole : () => {}
}

@printToConsoleConditional(false)
export class Pokemon {
 public publicApi: string = 'https://pokeapi.co'
 constructor(public name: string) {}
}

Un patrón habitual es sellar el prototipo para impedir que se alteren sus propiedades en tiempo de ejecución:

const blockPrototype = function (constructor: Function) {
 Object.seal(constructor)
 Object.seal(constructor.prototype)
}

@blockPrototype
@printToConsoleConditional(false)
export class Pokemon {
 // ...
}

Tip

Cuando aplicas múltiples decoradores, se ejecutan de forma secuencial de abajo hacia arriba. En el ejemplo anterior, primero corre printToConsoleConditional y luego blockPrototype.

Decoradores de método

Un decorador de método recibe tres argumentos —el objeto al que pertenece, el nombre del método y su PropertyDescriptor— y puede inspeccionar o reemplazar por completo el comportamiento del método. Aquí lo usamos para validar argumentos:

function CheckValidPokemonId() {
 return function (
 target: any,
 propertyKey: string,
 descriptor: PropertyDescriptor
 ) {
 const originalMethod = descriptor.value

 descriptor.value = (id: number) => {
 if (id < 1 || id > 100) {
 return console.error('El id del pokemon debe estar entre 1 y 100')
 }
 return originalMethod(id)
 }
 }
}

export class Pokemon {
 public publicApi: string = 'https://pokeapi.co'
 constructor(public name: string) {}

 @CheckValidPokemonId()
 savePokemonToDB(id: number) {
 console.log(`Pokemon guardado en la base de datos ${id}`)
 }
}

Al envolver originalMethod, el decorador intercepta la llamada, valida el id y solo delega al método original cuando el valor es válido. Este es el fundamento de las validaciones declarativas de muchos frameworks.

Decoradores de propiedad

Un decorador de propiedad recibe el objeto y el nombre de la propiedad, y puede alterar cómo se lee y escribe. Es útil para controlar el acceso a datos —recordando que JavaScript no tiene propiedades verdaderamente privadas en runtime:

function readOnly(isWriteable: boolean = true): Function {
 return function (target: any, propertyKey: string) {
 const descriptor: PropertyDescriptor = {
 get() {
 return 'Daca code'
 },
 set(this, val) {
 Object.defineProperty(this, propertyKey, {
 value: val,
 writable: !isWriteable,
 enumerable: false
 })
 }
 }
 return descriptor
 }
}

export class Pokemon {
 @readOnly(false)
 private publicApi: string = 'https://pokeapi.co'

 constructor(public name: string) {}
}

El decorador define un get/set personalizado que gobierna por completo el acceso a publicApi.

Conclusión

Los decoradores aportan metaprogramación declarativa a TypeScript: el decorador de clase actúa sobre el constructor una única vez, el de fábrica parametriza el comportamiento, el de método intercepta y reemplaza llamadas, y el de propiedad controla la lectura y escritura. Componerlos en cadena —respetando su orden de ejecución— es lo que habilita las APIs elegantes de frameworks modernos.

En el próximo artículo organizaremos el código con namespaces y módulos: export, import, alias y exportaciones por defecto.

TypeScript: Genéricos y código reutilizable

Dacadev — Sat, 20 Jun 2026 00:00:00 -0500

Tabla de Contenido

Note

Séptimo artículo de la serie sobre TypeScript. Exploraremos los genéricos: funciones y clases que operan sobre tipos dinámicos sin renunciar a la verificación estática.

Los genéricos en TypeScript resuelven una tensión recurrente: escribir código reutilizable que funcione con cualquier tipo, pero sin caer en any y perder toda la seguridad. Un genérico introduce un parámetro de tipo —una variable que representa un tipo aún por determinar— que se resuelve en el momento de uso. Analicemos cómo aplicarlos.

Funciones genéricas

Una función genérica declara su parámetro de tipo con la sintaxis <T> antes de la lista de parámetros. T representa el tipo que recibirá, y la función puede usarlo para tipar argumentos y retorno:

// Función tradicional
export function genericFunction<T>(argumento: T): T {
 return argumento
}

// Arrow function
export const genericArrowFunction = <T>(argumento: T): T => argumento

La función anterior retorna exactamente el mismo tipo que recibe. Si la invocas con un string, TypeScript sabe que el retorno es string; si la invocas con un number, el retorno es number. Esto es lo que distingue a un genérico de any: la relación entre entrada y salida se preserva.

Info

T es el nombre convencional, pero es arbitrario. Para múltiples parámetros suelen usarse T, U, K, V, o nombres descriptivos como TItem cuando aportan claridad.

Por qué no basta con any

Comparemos las dos aproximaciones para entender el valor de los genéricos:

// Con any: se pierde la información de tipo
function identityAny(arg: any): any {
 return arg
}
const a = identityAny('hola') // a es any → sin autocompletado ni verificación

// Con genéricos: el tipo se conserva
function identity<T>(arg: T): T {
 return arg
}
const b = identity('hola') // b es string → seguridad completa

Con any, el resultado pierde todo su tipo y el typechecker deja de ayudar. Con un genérico, la firma encadena el tipo de entrada con el de salida.

Clases genéricas

Las clases también admiten parámetros de tipo, lo que permite construir estructuras de datos reutilizables y type-safe. El parámetro se declara junto al nombre de la clase y queda disponible en todos sus miembros:

class MyMap<K, V> {
 constructor(initialKey: K, initialValue: V) {
 // ...
 }
 get(key: K): V {
 // ...
 }
 set(key: K, value: V): void {
 // ...
 }
 static of<K, V>(k: K, v: V): MyMap<K, V> {
 // ...
 }
}

Al instanciarla, los tipos pueden indicarse explícitamente o inferirse de los argumentos:

let a = new MyMap<string, number>('k', 1) // MyMap<string, number>
let b = new MyMap('k', true) // MyMap<string, boolean> (inferido)

a.get('k')
b.set('k', false)

flowchart LR
 G["MyMap<K, V>"] --> A["MyMap<string, number>"]
 G --> B["MyMap<string, boolean>"]
 G --> C["MyMap<number, Hero>"]

Una sola definición genérica genera tantas variantes type-safe como combinaciones de tipos uses.

Restringir genéricos con extends

A veces un genérico no debe aceptar cualquier tipo, sino solo aquellos que cumplan cierta forma. La cláusula extends impone esa restricción y, a la vez, habilita el acceso seguro a los miembros garantizados:

function getLength<T extends { length: number }>(item: T): number {
 return item.length
}

getLength('hola') // OK: string tiene length
getLength([1, 2, 3]) // OK: array tiene length
getLength(42) // Error: number no tiene 'length'

T extends { length: number } restringe T a tipos que posean una propiedad length, permitiendo usarla con seguridad dentro de la función.

Conclusión

Los genéricos son la herramienta que permite escribir código verdaderamente reutilizable sin sacrificar la verificación de tipos. Las funciones genéricas encadenan el tipo de entrada con el de salida, las clases genéricas habilitan estructuras de datos type-safe, y las restricciones con extends acotan los tipos aceptados mientras exponen sus miembros de forma segura.

En el próximo artículo abordaremos los tipos avanzados: subtipos, supertipos, varianza y la jerarquía completa del sistema de tipos.

TypeScript: Clases, herencia y patrones de diseño

Dacadev — Fri, 19 Jun 2026 00:00:00 -0500

Tabla de Contenido

Note

Sexto artículo de la serie sobre TypeScript. Recorreremos las clases: herencia, modificadores de acceso, clases abstractas, super, getters/setters, miembros estáticos, tipado estructural y los patrones de diseño que habilitan.

Las clases en TypeScript parten de la sintaxis de JavaScript y la enriquecen con modificadores de acceso, clases abstractas y tipado estructural. El resultado es un modelo de orientación a objetos cercano al de lenguajes como C++ o Java, pero que compila a JavaScript estándar. Analicemos sus capacidades.

Clases y herencia

La declaración usa class y la herencia se establece con extends:

class Piece {}

class King extends Piece {}
class Queen extends Piece {}
class Bishop extends Piece {}

Podemos restringir los atributos a valores concretos combinando clases con tipos literales:

type Color = 'Black' | 'White'
type File = 'A' | 'B' | 'C' | 'D' | 'E' | 'F' | 'G' | 'H'
type Rank = 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8

class Position {
 constructor(
 private file: File,
 private rank: Rank
 ) {}
}

Declarar los parámetros del constructor con un modificador (private file: File) es un atajo: TypeScript crea y asigna la propiedad automáticamente, evitando el habitual this.file = file.

Modificadores de acceso

TypeScript define tres niveles de visibilidad para atributos y métodos:

public: accesible desde cualquier lugar. Es el nivel por defecto.
protected: accesible desde la propia clase y sus subclases.
private: accesible únicamente desde la propia clase.

class Avenger {
 constructor(
 private name: string,
 public team: string,
 public realName?: string
 ) {}

 public bio() {
 return `${this.name} ${this.team}`
 }

 private bioInterno() {
 return `${this.realName} ${this.team}`
 }
}

Warning

private y protected solo aplican en tiempo de compilación. El JavaScript emitido no impide el acceso en runtime; para privacidad real en ejecución usa los campos privados nativos de JavaScript (#campo).

Clases abstractas

Una clase abstract define una plantilla que no puede instanciarse, pero sirve de esqueleto para sus subclases. Puede declarar miembros concretos y miembros abstract que las subclases están obligadas a implementar:

abstract class Mutante {
 constructor(
 public name: string,
 public realName: string
 ) {}
}

class Xmen extends Mutante {
 public saveWorld() {
 return 'Mundo salvado'
 }
}

class Villano extends Mutante {
 public conquistWorld() {
 return 'Mundo conquistado'
 }
}

const wolverine = new Xmen('Wolverine', 'Logan')
const magneto = new Villano('Magneto', 'Magnus')

Una ventaja adicional: una función puede aceptar cualquier objeto que herede de la clase abstracta, lo que habilita el polimorfismo:

const printName = (character: Mutante) => {
 console.log(character.name)
}

printName(wolverine)
printName(magneto)

super: invocar a la clase padre

Cuando una subclase sobrescribe un método del padre, puede invocar la versión original con super.metodo(). Si la subclase define un constructor, debe llamar a super() para inicializar correctamente la cadena de herencia:

class Xmen extends Avenger {
 constructor(name: string, realName: string, public isMutant: boolean) {
 super(name, realName)
 }

 public getFullNameDesdeXmen() {
 return super.getFullName()
 }
}

Getters y setters

Los accessors exponen métodos que se comportan sintácticamente como atributos, facilitando la lectura y asignación controladas:

class Xmen extends Avenger {
 get fullName() {
 return `${this.name} - ${this.realName}`
 }

 set fullName(name: string) {
 this.realName = name
 }
}

const wolverine = new Xmen('Wolverine', 'Logan', true)
console.log(wolverine.fullName) // se lee como atributo
wolverine.fullName = 'David' // se asigna como atributo

Miembros estáticos

Los miembros static pertenecen a la clase, no a sus instancias:

class Avenger {
 static avgAge: number = 35
 static getAvgAge() {
 return Avenger.avgAge
 }
}

console.log(Avenger.avgAge) // se accede vía la clase

this como tipo de retorno

Cuando un método retorna la propia instancia, su tipo de retorno es this. Esto es la base del encadenamiento de métodos (method chaining):

class Set {
 add(value: number): this {
 // ...
 return this
 }
}

Tipado estructural

TypeScript verifica las clases por estructura, no por nombre. Dos tipos compatibles en forma son intercambiables, con una salvedad: los miembros private rompen la compatibilidad estructural:

class A {
 private x = 1
}
class B extends A {}

function f(a: A) {}

f(new A()) // OK
f(new B()) // OK
f({ x: 1 }) // Error TS2345: 'x' es private en 'A' pero no en '{x: number}'.

Constructor privado

Un constructor private impide instanciar la clase desde fuera, lo que permite controlar su creación. Es la base del patrón singleton:

class Apocalipsis {
 private static instance: Apocalipsis

 private constructor(public name: string) {}

 static getInstance(): Apocalipsis {
 if (!Apocalipsis.instance) {
 Apocalipsis.instance = new Apocalipsis('Soy Apocalipsis... el único')
 }
 return Apocalipsis.instance
 }
}

const apocalipsis = Apocalipsis.getInstance()

Patrones de diseño habilitados

Factory Pattern

Centraliza la creación de objetos detrás de una función que decide la clase concreta:

type Shoe = { purpose: string }

class BalletFlat implements Shoe { purpose = 'dancing' }
class Boot implements Shoe { purpose = 'woodcutting' }
class Sneaker implements Shoe { purpose = 'walking' }

let Shoe = {
 create(type: 'balletFlat' | 'boot' | 'sneaker'): Shoe {
 switch (type) {
 case 'balletFlat': return new BalletFlat()
 case 'boot': return new Boot()
 case 'sneaker': return new Sneaker()
 }
 }
}

Builder Pattern

Construye un objeto paso a paso mediante métodos que retornan this, habilitando una API fluida:

class RequestBuilder {
 private data: object | null = null
 private method: 'get' | 'post' | null = null
 private url: string | null = null

 setMethod(method: 'get' | 'post'): this {
 this.method = method
 return this
 }
 setData(data: object): this {
 this.data = data
 return this
 }
 setURL(url: string): this {
 this.url = url
 return this
 }

 send() {
 // ...
 }
}

new RequestBuilder().setURL('/api').setMethod('post').setData({}).send()

Conclusión

Las clases de TypeScript ofrecen un modelo de orientación a objetos completo: herencia, modificadores de acceso, clases abstractas para polimorfismo, accessors, miembros estáticos y un tipado estructural con la salvedad de los miembros privados. Estas piezas son el fundamento de patrones de diseño como Factory, Builder y Singleton.

En el siguiente artículo abordaremos los genéricos, la herramienta para escribir código reutilizable sin sacrificar la seguridad de tipos.

Estilos CSS: Animaciones con @keyframes

Dacadev — Thu, 18 Jun 2026 00:00:00 -0500

Tabla de Contenido

Una transición anima el salto entre dos estados; pero cuando necesitas movimiento continuo, varios pasos intermedios o una secuencia que se repite —un spinner de carga, un latido, un texto que aparece— necesitas algo más expresivo. Ahí entran las animaciones con @keyframes, el sistema de CSS para describir secuencias de movimiento complejas de forma declarativa, sin una sola línea de JavaScript.

Esta entrega extiende la serie Estilos CSS, retomando justo donde lo dejaron las transiciones y transformaciones. Cubriremos la regla @keyframes, todas las subpropiedades de animation, y las consideraciones de accesibilidad y rendimiento que separan una animación profesional de una que marea al usuario.

Note

Aprenderás a definir secuencias con @keyframes, a controlarlas con la propiedad animation y sus ocho subpropiedades, y a respetar las preferencias de movimiento del usuario con prefers-reduced-motion.

Transición vs. animación

Aunque ambas producen movimiento, resuelven problemas distintos:

Una transición (transition) interpola entre el estado actual y uno nuevo. Necesita un disparador —un :hover, un cambio de clase— y va de un punto A a un punto B.
Una animación (animation) ejecuta una secuencia definida en @keyframes. No necesita disparador: puede arrancar sola, repetirse indefinidamente y pasar por múltiples estados intermedios.

Info

Regla práctica: usa transition para cambios de estado provocados por interacción; usa animation para movimiento autónomo, cíclico o multipaso.

La regla @keyframes

Una animación se define en dos partes: la secuencia (con @keyframes) y su aplicación (con la propiedad animation). La regla @keyframes recibe un nombre y describe los estados de la animación en distintos momentos, expresados como porcentajes del 0% al 100% (o con las palabras clave from y to).

@keyframes aparecer {
 from { opacity: 0; transform: translateY(1rem); }
 to { opacity: 1; transform: translateY(0); }
}

.elemento {
 animation: aparecer 0.6s ease-out;
}

Aparezco con fade + desplazamiento

La secuencia se repite para que puedas observarla.

Múltiples pasos con porcentajes

El verdadero poder de @keyframes aparece con pasos intermedios. Cada porcentaje es una “foto” del estado en ese momento de la animación:

@keyframes latido {
 0% { transform: scale(1); }
 15% { transform: scale(1.25); }
 30% { transform: scale(1); }
 45% { transform: scale(1.15); }
 60% { transform: scale(1); }
}

♥

La propiedad animation y sus subpropiedades

animation es una propiedad abreviada que agrupa ocho subpropiedades. Conviene conocerlas por separado para tener control fino:

Subpropiedad	Función	Ejemplo
`animation-name`	Nombre del `@keyframes` a ejecutar	`aparecer`
`animation-duration`	Duración de un ciclo	`0.6s`
`animation-timing-function`	Curva de progreso	`ease-in-out`
`animation-delay`	Espera antes de iniciar	`200ms`
`animation-iteration-count`	Número de repeticiones	`infinite`
`animation-direction`	Sentido de reproducción	`alternate`
`animation-fill-mode`	Estilos antes/después de animar	`forwards`
`animation-play-state`	Reproducir o pausar	`paused`

La forma abreviada las combina en una sola declaración:

.spinner {
 animation: girar 1s linear infinite;
 /* name | duration | timing-function | iteration-count */
}

iteration-count y direction

animation-iteration-count define cuántas veces se ejecuta (infinite para un bucle perpetuo). animation-direction controla el sentido:

normal — siempre de 0% a 100%.
reverse — siempre de 100% a 0%.
alternate — alterna ida y vuelta en cada ciclo.
alternate-reverse — igual, pero empezando al revés.

El caso clásico es un spinner de carga, que combina rotación infinita con velocidad constante:

@keyframes girar { to { transform: rotate(360deg); } }

.spinner { animation: girar 0.8s linear infinite; }

fill-mode: el estado antes y después

Por defecto, un elemento vuelve a su estilo original en cuanto la animación termina. animation-fill-mode cambia ese comportamiento:

none (por defecto) — no conserva estilos fuera de la ejecución.
forwards — mantiene el estado del último keyframe al terminar.
backwards — aplica el primer keyframe durante el delay, antes de arrancar.
both — combina forwards y backwards.

forwards es esencial cuando quieres que el elemento permanezca en su estado final (por ejemplo, un mensaje que aparece y se queda visible):

.toast {
 animation: aparecer 0.5s ease-out forwards;
}

play-state y delay

animation-play-state permite pausar (paused) y reanudar (running) una animación, típicamente al combinarla con :hover. Aquí, la barra de progreso se anima sola pero se congela al pasar el cursor:

@keyframes cargar { from { width: 0; } to { width: 100%; } }

.barra__relleno { animation: cargar 3s ease-in-out infinite; }
.barra:hover .barra__relleno { animation-play-state: paused; }

Pasa el cursor sobre la barra para pausar la animación.

Encadenar varias animaciones

Puedes aplicar varias animaciones a un mismo elemento separándolas con comas. Cada una mantiene su propia duración, retraso y curva, lo que permite componer comportamientos independientes:

.elemento {
 animation:
 aparecer 0.5s ease-out,
 flotar 3s ease-in-out 0.5s infinite alternate;
}

Floto suavemente

Accesibilidad: respeta prefers-reduced-motion

El movimiento excesivo puede causar mareos o malestar a personas con sensibilidad vestibular. Los sistemas operativos exponen una preferencia de “reducir movimiento”, y CSS la consulta con la media query prefers-reduced-motion. Es una responsabilidad profesional desactivar o atenuar las animaciones no esenciales cuando el usuario lo solicita:

@media (prefers-reduced-motion: reduce) {
 *,
 *::before,
 *::after {
 animation-duration: 0.01ms !important;
 animation-iteration-count: 1 !important;
 transition-duration: 0.01ms !important;
 }
}

Warning

Ignorar prefers-reduced-motion es un fallo de accesibilidad real. Reserva las animaciones llamativas para lo decorativo y asegúrate de que la interfaz siga siendo plenamente funcional cuando el movimiento se reduce.

Rendimiento: anima en la capa de composición

La misma regla de oro de las transiciones aplica aquí: anima propiedades que solo afecten la etapa de composición del navegador —transform y opacity— en lugar de propiedades que disparen layout o paint (width, height, top, left, margin).

/* ❌ Costoso: recalcula layout en cada frame */
@keyframes mover-malo { to { left: 200px; } }

/* ✅ Eficiente: solo composición, fluido a 60 fps */
@keyframes mover-bien { to { transform: translateX(200px); } }

Tip

Si una animación se ve entrecortada, lo primero que debes revisar es qué propiedades estás animando. Reescribir un left/top como transform: translate() suele eliminar el jank de inmediato.

Conclusión

Las animaciones con @keyframes te dan un lenguaje declarativo para describir movimiento complejo: secuencias multipaso, bucles infinitos y comportamientos compuestos, todo en CSS puro. Dominar la propiedad animation y sus subpropiedades —especialmente fill-mode, iteration-count y play-state— te permite construir spinners, indicadores de carga y microinteracciones pulidas. Y recuerda: anima transform y opacity, y respeta siempre prefers-reduced-motion.

Note

🚀 Con esta entrega completas el recorrido de la serie Estilos CSS: desde la cascada y los selectores hasta el layout, el posicionamiento, los fondos, las transformaciones y, ahora, las animaciones. Tienes el repertorio completo para escribir CSS expresivo, accesible y de alto rendimiento.

TypeScript: Interfaces y contratos de tipos

Dacadev — Thu, 18 Jun 2026 00:00:00 -0500

Tabla de Contenido

Note

Quinto artículo de la serie sobre TypeScript. Estudiaremos las interfaces como contratos extensibles, su herencia con extends, su implementación en clases con implements, y sus diferencias frente a los alias de tipo.

Una interface en TypeScript define la forma que deben cumplir los objetos. A primera vista se parece a un alias de tipo, pero su rasgo distintivo es la extensibilidad: las interfaces están diseñadas para componerse, heredarse y servir como base de contratos más complejos. Analicemos cuándo y cómo usarlas.

Bases: definir y extender interfaces

Una interface declara la estructura de un objeto. Con extends, una interface puede heredar de otra y ampliar su contrato:

interface Hero {
 name: string;
 age?: number;
 powers: string[];
 getName?: () => string;
}

interface Avenger extends Hero {
 marvel: string;
}

let flash: Hero = {
 name: 'Barry Allen',
 age: 24,
 powers: ['super velocidad', 'viajar en el tiempo']
}

Avenger hereda todos los miembros de Hero y añade marvel. Esta composición es la base del diseño orientado a contratos.

Estructuras complejas: interfaces anidadas

Las interfaces pueden referenciarse entre sí para modelar estructuras de datos compuestas:

interface Client {
 name: string;
 age?: number;
 address?: Address;
}

interface Address {
 id: number;
 zip: string;
 city: string;
}

const client: Client = {
 name: 'David',
 address: {
 id: 125,
 zip: 'KYD 234',
 city: 'Chía'
 }
}

const client2: Client = {
 name: 'Melissa',
 age: 30
}

Client referencia a Address como un campo opcional, lo que permite componer entidades de dominio sin acoplarlas en una sola definición monolítica.

Métodos en la interfaz

Al igual que los alias de tipo, las interfaces pueden declarar métodos como parte del contrato:

interface Client {
 name: string;
 age?: number;
 address?: Address;
 getFullAddress(id: string): void;
}

Info

Declarar métodos en una interface es válido, pero implica que el objeto que la cumpla debe implementarlos. En la práctica, cuando un contrato requiere comportamiento, lo más limpio es implementarlo mediante una clase.

Implementar interfaces en clases

Una clase adopta uno o varios contratos con la palabra clave implements. Esto garantiza, en compilación, que la clase provee todo lo que el contrato exige:

interface Xmen {
 name: string;
 realName: string;
 mutantPower(id: number): string;
}

interface Human {
 age: number;
}

class Mutant implements Xmen, Human {
 public age: number;
 public name: string;
 public realName: string;

 mutantPower(id: number): string {
 return 'Hola mundo';
 }
}

Mutant implementa simultáneamente Xmen y Human. Si omitiera cualquier miembro requerido, el compilador lo rechazaría.

Interfaces para tipar funciones

Aunque es poco frecuente, una interface puede describir la firma de una función antes de asignarle una implementación:

interface AddTwoNumbers {
 (a: number, b: number): number;
}

let addNumbers: AddTwoNumbers;

addNumbers = (a: number, b: number): number => a + b

Interfaces frente a alias de tipo

Esta es la decisión de diseño más común. Las tres diferencias clave:

1. Composición

Los alias de tipo componen mediante operaciones de conjuntos (|, &); las interfaces componen mediante extends:

type Food = { calories: number; tasty: boolean }
type Sushi = Food & { salty: boolean }

interface FoodI { calories: number; tasty: boolean }
interface SushiI extends FoodI { salty: boolean }

2. Restricción al extender

Al extender una interface, no puedes cambiar el tipo de un miembro heredado, solo añadir o restringir de forma compatible. Una incompatibilidad genera error:

interface A {
 good(x: number): string
 bad(x: number): string
}

interface B extends A {
 good(x: string | number): string
 bad(x: string): string // Error TS2430: 'B' extiende incorrectamente 'A'.
}

3. Declaration merging

Varias interfaces con el mismo nombre en el mismo ámbito se fusionan automáticamente; varios alias de tipo con el mismo nombre producen un error de compilación:

interface User { name: string }
interface User { age: number } // se fusiona

let a: User = { name: 'Ashley', age: 30 }

type User = { name: string } // Error TS2300: identificador duplicado
type User = { age: number } // Error TS2300

El declaration merging respeta los tipos existentes: no puedes redefinir un miembro ya declarado con otro tipo.

flowchart TD
 Q{¿Necesitas extensibilidad,
implements o merging?}
 Q -- Sí --> I[Usa interface]
 Q -- "No (uniones, tuplas, mapeos)" --> T[Usa type]

Implementación con readonly y múltiples contratos

Las interfaces admiten propiedades readonly y permiten que una clase cumpla varios contratos a la vez:

interface Animal {
 readonly name: string
 eat(food: string): void
 sleep(hours: number): void
}

interface Feline {
 meow(): void
}

class Cat implements Animal, Feline {
 name = 'Whiskers'
 eat(food: string) { console.info('Ate some', food) }
 sleep(hours: number) { console.info('Slept for', hours, 'hours') }
 meow() { console.info('Meow') }
}

Conclusión

Las interfaces son el mecanismo de TypeScript para definir contratos extensibles y verificables. Elige una interface cuando necesites herencia con extends, implementación en clases con implements o declaration merging; reserva los alias de tipo para uniones, intersecciones, tuplas y tipos mapeados.

En el próximo artículo profundizaremos en las clases, la herencia, los modificadores de acceso y los patrones de diseño que habilitan.

TypeScript: Funciones, parámetros y generadores

Dacadev — Wed, 17 Jun 2026 00:00:00 -0500

Tabla de Contenido

Note

Cuarto artículo de la serie sobre TypeScript. Cubriremos el tipado de funciones: parámetros, tipos de retorno, parámetros opcionales y por defecto, el operador resto, call signatures, generadores e iteradores.

Las funciones son el núcleo de cualquier base de código, y es justo donde el tipado aporta más valor: una firma bien tipada documenta el contrato de entrada y salida, y convierte cualquier llamada inválida en un error de compilación. Analicemos cómo TypeScript modela las funciones en toda su variedad.

Declaración y tipado de funciones

Una función tipada declara el tipo de cada parámetro y, opcionalmente, el tipo de retorno:

function add(a: number, b: number): number {
 return a + b
}

TypeScript admite todas las formas de definir funciones de JavaScript, y a todas les aplica el mismo sistema de tipos:

// Named function
function greet(name: string) {
 return 'hello ' + name
}

// Function expression
let greet2 = function (name: string) {
 return 'hello ' + name
}

// Arrow function
let greet3 = (name: string) => {
 return 'hello ' + name
}

// Shorthand arrow function
let greet4 = (name: string) => 'hello ' + name

El tipado de los parámetros intercepta llamadas inválidas en el sitio exacto del error:

add(1) // Error TS2554: se esperaban 2 argumentos, se recibió 1.
add(1, 'a') // Error TS2345: 'string' no es asignable a 'number'.

Parámetros opcionales y por defecto

Un parámetro opcional se marca con ? y debe gestionarse dentro del cuerpo, ya que puede llegar como undefined:

function log(message: string, userId?: string) {
 let time = new Date().toLocaleTimeString()
 console.log(time, message, userId || 'Not signed in')
}

log('Page loaded')
log('User signed in', 'da763be')

Un parámetro con valor por defecto se vuelve opcional automáticamente, y TypeScript infiere su tipo a partir del valor asignado:

function log(message: string, userId = 'Not signed in') {
 let time = new Date().toISOString()
 console.log(time, message, userId)
}

Warning

Los parámetros opcionales deben ubicarse después de todos los obligatorios, y no pueden combinarse con el operador resto.

También puedes apoyarte en un type para estructurar parámetros de configuración:

type Context = {
 appId?: string
 userId?: string
}

function log(message: string, context: Context = {}) {
 let time = new Date().toISOString()
 console.log(time, message, context.userId)
}

Operador resto: funciones variádicas

El operador resto captura un número dinámico de argumentos en un arreglo tipado, lo que produce firmas más legibles que recibir un arreglo explícito:

// Recibe un arreglo
function sum(numbers: number[]): number {
 return numbers.reduce((total, n) => total + n, 0)
}
sum([1, 2, 3]) // 6

// Variádica con operador resto
function sumVariadicSafe(...numbers: number[]): number {
 return numbers.reduce((total, n) => total + n, 0)
}
sumVariadicSafe(1, 2, 3) // 6

call, apply y bind

TypeScript respeta los mecanismos clásicos de invocación de JavaScript, aplicando la verificación de tipos a sus argumentos:

function add(a: number, b: number): number {
 return a + b
}

add(10, 20) // 30
add.apply(null, [10, 20]) // 30
add.call(null, 10, 20) // 30
add.bind(null, 10, 20)() // 30

Generadores

Los generadores producen valores bajo demanda. Se declaran con un asterisco tras function y emiten valores con yield:

function* createFibonacciGenerator() {
 let a = 0
 let b = 1
 while (true) {
 yield a
 ;[a, b] = [b, a + b]
 }
}

let fib = createFibonacciGenerator() // IterableIterator<number>
fib.next() // { value: 0, done: false }
fib.next() // { value: 1, done: false }
fib.next() // { value: 1, done: false }
fib.next() // { value: 2, done: false }

El método next() extrae el siguiente valor de la secuencia. TypeScript infiere el tipo IterableIterator<number> a partir de lo que produce yield.

Iteradores

Un iterador se define implementando el método [Symbol.iterator]. TypeScript es capaz de reconocer la estructura y tiparla correctamente:

let numbers = {
 *[Symbol.iterator]() {
 for (let n = 1; n <= 10; n++) {
 yield n
 }
 }
}

Call signatures

Una call signature describe el tipo de una función de forma independiente a su implementación. Para la siguiente función:

function sum(a: number, b: number): number {
 return a + b
}

su firma de llamada se expresa así:

(a: number, b: number) => number

El tipo genérico Function es un comodín que no aporta información sobre la firma concreta; las call signatures permiten tipar funciones con precisión. Además, cuando una función puede retornar varios tipos, cada uno debe tratarse para satisfacer al typechecker:

function area(radius: number): number | null {
 if (radius < 0) {
 return null
 }
 return Math.PI * radius ** 2
}

let a = area(3)
if (a !== null) {
 console.info('result:', a) // dentro del guard, a es number
}

Conclusión

El tipado de funciones convierte cada firma en un contrato verificable: parámetros opcionales y por defecto modelan flexibilidad controlada, el operador resto expresa funciones variádicas con claridad, las call signatures tipan funciones como ciudadanos de primera clase, y los generadores e iteradores se integran sin fricción en el sistema de tipos.

En el siguiente artículo abordaremos las interfaces, el mecanismo de TypeScript para definir contratos extensibles.

Estilos CSS: Modularización y patrones de diseño

Dacadev — Tue, 16 Jun 2026 00:00:00 -0500

Tabla de Contenido

En un proyecto pequeño cualquier organización de CSS funciona. El problema aparece al escalar: hojas de estilo de miles de líneas donde tocar una regla rompe tres componentes que parecían no tener relación. La causa casi siempre es la misma: estilos acoplados que se pisan entre sí. La solución es arquitectónica —modularizar— y existen metodologías probadas para lograrlo.

Esta es la octava y última entrega de la serie Estilos CSS. Veremos cómo estructurar estilos en módulos independientes, la metodología BEM, las clases de utilidad y cómo documentar tus componentes con una librería de patrones.

Note

Aprenderás a dividir tus estilos en componentes desacoplados, a nombrar clases con BEM, a usar utility classes con criterio y a mantener una librería de patrones como fuente única de verdad del diseño.

Qué es la modularización

Modularizar CSS consiste en dividir los estilos en archivos donde cada uno representa un módulo: un único componente con todo su estilo encapsulado. Un módulo button.css contiene todo lo necesario para renderizar un botón y sus variantes, y nada más.

Tip

La regla de oro: un módulo no debe interferir con los estilos de otros. Solo se ocupa de su propio componente. Así, modificar un módulo nunca produce efectos colaterales inesperados en el resto de la página.

Estilos base

Antes de los módulos conviene tener un archivo de estilos base: no es un componente, sino la configuración inicial del documento (reset, tipografía global, box-sizing).

:root { box-sizing: border-box; }

*, *::before, *::after { box-sizing: inherit; }

body { font-family: Helvetica, Arial, sans-serif; }

Para no reinventar la rueda, paquetes como Normalize.css homogeneizan las diferencias entre navegadores de forma sensata.

Componentes y BEM

La idea central de un módulo es que los estilos y modificadores de un componente vivan en un solo lugar. La metodología BEM (Block, Element, Modifier) propone una convención de nombres que hace explícita la estructura y evita colisiones:

Block — el componente raíz: .button.
Element — una parte del componente, con __: .button__icon.
Modifier — una variante, con --: .button--success.

.button {
 padding: 0.5em 0.8em;
 border: 1px solid #265559;
 border-radius: 0.2em;
 background-color: transparent;
 font-size: 1rem;
}

.button--success { color: #fff; background-color: #2f5926; border-color: #cfe8c9; }
.button--danger { color: #fff; background-color: #a92323; border-color: #e8c9c9; }
.button--small { font-size: 0.8rem; }
.button--large { font-size: 1.2rem; }

<button class="button">Normal</button>
<button class="button button--success">Éxito</button>
<button class="button button--danger">Peligro</button>
<button class="button button--large">Grande</button>

Posicionamiento del componente

Por buena práctica, el bloque raíz de un componente debería declarar position: relative. Así estableces un contexto de posicionamiento controlado para cualquier elemento absoluto interno (un menú desplegable, un badge, un tooltip), sin depender de ancestros externos.

Estado de los componentes

Es común reflejar el estado de un componente con clases, ya sea para estilizarlo o para manipularlo desde JavaScript. La convención recomendada usa verbos o estados con prefijo: is-loading, has-error, is-active.

Warning

No mezcles las clases de estado con los modificadores BEM. Evita nombres como block__element--modifier-is-loading. El estado es una capa transversal y dinámica; mantenlo separado de la variante estática del componente.

Utility classes

Las clases de utilidad aplican un estilo único y específico. Suelen usar !important para garantizar que se apliquen por encima de los estilos del componente:

.text-center { text-align: center !important; }
.float-left { float: left; }
.hidden { display: none !important; }

.clearfix::before,
.clearfix::after { content: " "; display: table; }
.clearfix::after { clear: both; }

Son útiles para ajustes puntuales, pero abusar de ellas reintroduce el acoplamiento que la modularización busca evitar. Úsalas con criterio.

Metodologías de arquitectura CSS

BEM no es la única opción. Las metodologías más establecidas para organizar CSS a escala son:

OOCSS — Object-Oriented CSS, de Nicole Sullivan: separa estructura de apariencia.
SMACSS — Scalable and Modular Architecture for CSS, de Jonathan Snook: categoriza las reglas en capas.
BEM — Block, Element, Modifier, de Yandex: convención de nombres explícita.
ITCSS — Inverted Triangle CSS, de Harry Roberts: organiza por especificidad creciente.

No son excluyentes; muchos equipos combinan ITCSS para la estructura de archivos con BEM para la nomenclatura.

Librerías de patrones

En proyectos grandes, los componentes se documentan en una librería de patrones (o style guide): una web accesible para todo el equipo que muestra cómo se ve y se comporta cada componente. Es la fuente única de verdad del diseño y reduce las inconsistencias.

Existen generadores de style guides; uno open source muy conocido es KSS. Documenta los componentes a partir de comentarios estructurados en el propio CSS:

/*
Buttons

Botones disponibles en varios tamaños y colores.

Markup:
<button class="button {{modifier_class}}">click here</button>

.button--success - Botón verde de éxito
.button--danger - Botón rojo de peligro
.button--large - Botón grande

Styleguide Buttons
*/
.button { /* ... */ }

KSS lee esos comentarios y genera automáticamente una página de documentación con el componente renderizado y todas sus variantes. El bloque incluye un título, una descripción, el Markup de ejemplo (con el marcador {{modifier_class}}), la lista de modificadores y una referencia Styleguide para ubicarlo en la jerarquía.

Info

Mantener la documentación junto al código —en comentarios del propio CSS— reduce el riesgo de que la librería de patrones quede desactualizada respecto a la implementación real.

Conclusión

Escribir CSS que escale es, ante todo, un problema de arquitectura. Modularizar en componentes desacoplados, nombrar con una convención consistente como BEM, reservar las utility classes para ajustes puntuales y documentar todo en una librería de patrones es lo que mantiene una hoja de estilos sana a medida que el proyecto crece.

Con esta entrega cerramos la serie Estilos CSS. Recorrimos desde los fundamentos de la cascada hasta la arquitectura de estilos a gran escala, pasando por selectores, el modelo de caja, layouts, posicionamiento, fondos y animaciones. Tienes ahora un modelo mental completo para escribir CSS profesional, predecible y mantenible.

Note

🚀 Repasa las entregas anteriores para consolidar cada concepto: los fundamentos sostienen los selectores, el modelo de caja sostiene los layouts, y la modularización une todo en un sistema coherente.

TypeScript: Objetos y tipos personalizados

Dacadev — Tue, 16 Jun 2026 00:00:00 -0500

Tabla de Contenido

Note

Tercer artículo de la serie sobre TypeScript. Diseñaremos la forma de nuestros objetos con tipos personalizados, definiremos campos opcionales y métodos, y permitiremos que una variable acepte múltiples tipos.

Modelar correctamente la estructura de los objetos es donde TypeScript empieza a pagar dividendos en proyectos reales. Un tipo personalizado bien diseñado centraliza la definición de una entidad, propaga su forma por todo el código y convierte cualquier desviación en un error de compilación. Analicemos cómo pasar de objetos literales sueltos a un modelo de tipos mantenible.

Objetos literales y la inferencia estructural

Los objetos literales funcionan igual que en JavaScript, pero TypeScript infiere automáticamente su estructura. Esa inferencia es justamente lo que impide reasignar un objeto con una forma distinta:

let flash = {
 name: 'Barry Allen',
 age: 24,
 powers: ['super velocidad', 'viajar en el tiempo']
}

flash = { name2: 'Otro nombre' }
// Error: el literal solo puede especificar propiedades conocidas;
// 'name2' no existe en el tipo inferido y faltan 'name', 'age', 'powers'.

TypeScript bloquea la reasignación porque el nuevo literal no respeta la forma deducida de flash. Este comportamiento evita introducir campos accidentales o incompletos.

Tipar objetos de forma inline

Podemos declarar explícitamente la forma del objeto usando la misma sintaxis de anotación que venimos aplicando, incluyendo campos opcionales con ?:

let flash: { name: string, age?: number, powers: string[] } = {
 name: 'Barry Allen',
 age: 24,
 powers: ['super velocidad', 'viajar en el tiempo']
}

flash = {
 name: 'Clark Kent',
 powers: ['volar', 'rayo láser'] // 'age' es opcional, puede omitirse
}

Info

La posición de un campo opcional dentro de la anotación es irrelevante. age? puede ir en medio de la definición sin afectar la validez de los objetos que lo omitan.

El problema de este enfoque inline es la duplicación: si dos variables deben compartir la misma forma, hay que repetir la anotación completa en cada una y mantenerlas sincronizadas manualmente. Esto no escala.

Tipos personalizados con type

La solución es definir la estructura una sola vez con la palabra clave type y reutilizarla en todo el código. Esto centraliza el modelo en un único punto de verdad:

type Hero = {
 name: string;
 age?: number;
 powers: string[];
 getName?: () => string;
}

let flash: Hero = {
 name: 'Barry Allen',
 age: 24,
 powers: ['super velocidad', 'viajar en el tiempo']
}

let superman: Hero = {
 name: 'Clark Kent',
 age: 30,
 powers: ['volar', 'rayo láser'],
 getName() {
 return this.name;
 }
}

El tipo Hero declara name y powers como obligatorios, age como opcional y getName como un método opcional cuya firma es () => string. Cualquier objeto anotado con Hero debe respetar este contrato, y un solo cambio en la definición se propaga a todas las variables que lo usan.

flowchart TD
 T[type Hero] --> A[flash: Hero]
 T --> B[superman: Hero]
 T --> C[...otros héroes]
 note["Un cambio en Hero
se propaga a todos"] -.-> T

Tip

Define un type para toda entidad que aparezca más de una vez. La regla práctica: si copiarías la anotación inline por segunda vez, conviértela en un tipo personalizado.

Permitir múltiples tipos con uniones

Una variable puede aceptar más de un tipo mediante el operador de unión |. Esto resulta útil para valores que legítimamente cambian de forma según el contexto:

type Hero = {
 name: string;
 age?: number;
 powers: string[];
 getName?: () => string;
}

let myCustomVariable: Hero | string | number = '¡Hola mundo!'

myCustomVariable = 42 // válido: number
myCustomVariable = { // válido: Hero
 name: 'Diana',
 powers: ['fuerza sobrehumana']
}

myCustomVariable puede contener un Hero, un string o un number. El typechecker permitirá únicamente operaciones válidas para todos los miembros de la unión hasta que acotes el tipo con un type guard (por ejemplo, typeof o una comprobación de propiedad).

Conclusión

Pasar de objetos literales inline a tipos personalizados con type es el salto que transforma TypeScript de una simple validación a una herramienta de diseño. Un tipo centraliza la forma de una entidad, los campos opcionales modelan la realidad de los datos incompletos, los métodos definen comportamiento esperado y las uniones aportan flexibilidad controlada.

En el próximo artículo de la serie abordaremos las funciones: anotación de parámetros, tipos de retorno, parámetros opcionales y sobrecargas.

Estilos CSS: Transiciones, transformaciones y rendimiento

Dacadev — Sun, 14 Jun 2026 00:00:00 -0500

Tabla de Contenido

Las transiciones y transformaciones son la puerta de entrada a las interfaces animadas. Una transición suaviza el cambio entre dos estados; una transformación altera la geometría visual de un elemento sin afectar el layout. Bien aplicadas, mejoran la percepción de calidad y guían la atención del usuario. Mal aplicadas, generan jank y consumen batería. La diferencia está en entender qué propiedades son baratas de animar y por qué.

Esta es la séptima entrega de la serie Estilos CSS. Cubriremos la propiedad transition y sus timing functions, las funciones de transform en 2D y 3D, y el pipeline de renderizado que explica por qué transform y opacity son las propiedades óptimas para animar.

Note

Aprenderás a construir transiciones fluidas con curvas de Bézier, a aplicar y combinar transformaciones, y a entender el pipeline layout → paint → composición para escribir animaciones eficientes.

Transiciones

Una transición interpola el cambio de una propiedad entre su valor inicial y final a lo largo del tiempo. Suele combinarse con pseudo-clases como :hover o :active. Se controla con cuatro propiedades:

transition-property: background-color, transform;
transition-duration: 0.3s, 0.6s;
transition-timing-function: ease, linear;
transition-delay: 0s, 100ms;

transition-property — qué propiedades se animan (usa all para todas).
transition-duration — cuánto dura la interpolación.
transition-timing-function — cómo se distribuye el movimiento en el tiempo.
transition-delay — cuánto espera antes de empezar (opcional).

.boton { transition: background-color 0.3s ease, transform 0.3s ease; }
.boton:hover { background-color: #16828d; transform: translateY(-3px); }

Timing functions

La timing function define cómo se reparte el movimiento en el tiempo. Existen valores predefinidos —linear, ease, ease-in, ease-out, ease-in-out— donde el eje X representa el tiempo y el eje Y el progreso del cambio.

Todas son curvas de Bézier, y puedes definir la tuya con la función cubic-bezier():

.box { transition: transform 0.6s cubic-bezier(0.45, 0.05, 0.55, 0.95); }

También puedes hacer el cambio en pasos discretos con steps(), útil para animaciones tipo sprite o efectos de “tecleo”:

.box { transition: all 1s steps(3); }

Tip

Existen editores visuales de curvas de Bézier que te permiten ajustar la animación y copiar el valor exacto. Experimentar con ellos es la forma más rápida de afinar la sensación de una transición.

Transformaciones

La propiedad transform altera la geometría visual de un elemento mediante cuatro operaciones:

scale() — escala el tamaño.
rotate() — rota el elemento.
translate() — lo desplaza.
skew() — lo inclina/estira.

Warning

Las transformaciones solo alteran la representación visual del elemento, no su comportamiento en el layout. El hueco original que ocupaba se conserva, y los elementos vecinos no se reorganizan.

Rotación

rotate() gira el elemento. Los valores positivos giran en sentido horario; los negativos, antihorario.

.giro { transform: rotate(15deg); }

Traslación

translate(x, y) mueve el elemento en ambos ejes sin afectar el flujo. Los valores positivos lo desplazan a la derecha y hacia abajo.

.mover { transform: translate(40px, 10px); }

Escala

scale() redimensiona: valores entre 0 y 1 encogen, mayores que 1 agrandan.

.crecer { transform: scale(1.3); }

Inclinación

skew(x, y) deforma el elemento inclinándolo respecto a los ejes.

.inclinar { transform: skew(-12deg); }

rotate translate scale skew

Punto de referencia: transform-origin

Toda transformación se aplica desde un punto de referencia, que por defecto es el centro del elemento. transform-origin lo reubica:

.giro { transform-origin: left center; } /* equivale a 0% 50% */

Combinar transformaciones

Puedes encadenar varias funciones separándolas por espacios. Se aplican de derecha a izquierda, lo que afecta el resultado final:

.tarjeta { transform: rotate(15deg) translate(20px, 0); }

El pipeline de renderizado

Para escribir animaciones eficientes hay que entender cómo el navegador dibuja una página. El proceso tiene tres etapas clave:

Layout — el navegador calcula las dimensiones y posiciones de todos los elementos. Cualquier cambio de tamaño o posición dispara un recálculo completo (reflow).
Paint — pinta en memoria los píxeles de cada elemento (colores, bordes, sombras), posiblemente en capas separadas.
Composición — combina las capas pintadas para mostrarlas en pantalla.

flowchart LR
 A[JS / CSS] --> B[Layout]
 B --> C[Paint]
 C --> D[Composición]

La clave del rendimiento: algunas propiedades, como transform y opacity, solo afectan la etapa de composición. No requieren recalcular el layout ni repintar, por lo que son las propiedades óptimas para animar de forma fluida a 60 fps.

Tip

Prefiere animar transform y opacity en lugar de width, height, top o left. Estas últimas disparan layout y paint en cada frame, lo que produce animaciones entrecortadas.

Transformaciones en 3D

transform también opera en tres dimensiones. Puedes rotar sobre cualquier eje con rotateX(), rotateY() y rotateZ(). El efecto depende de la perspectiva: la distancia simulada entre el observador y el elemento. A menor perspectiva, más pronunciado el efecto 3D.

Hay dos formas de aplicarla:

/* 1. Función dentro de transform (afecta solo a ese elemento) */
.box { transform: perspective(200px) rotateX(30deg); }

/* 2. Propiedad en el contenedor (perspectiva compartida) */
.row { perspective: 200px; }
.box { transform: rotateX(30deg); }

rotateX(35deg)

rotateY(35deg)

Una rotación de 180° voltea el elemento como un espejo. La propiedad backface-visibility controla si la cara trasera es visible, lo que habilita efectos como las tarjetas que se voltean. Un recurso clásico para profundizar es Intro to CSS 3D transforms.

Conclusión

Las transiciones suavizan los cambios de estado y las transformaciones manipulan la geometría sin tocar el layout. La regla de oro del rendimiento es animar transform y opacity, que solo afectan la etapa de composición. Con curvas de Bézier afinadas y un uso consciente del pipeline, tus animaciones serán fluidas y eficientes.

Note

🚀 La entrega final de la serie aborda la modularización y los patrones de diseño en CSS: cómo organizar tus estilos en componentes mantenibles con metodologías como BEM.

TypeScript: Introducción y configuración del entorno

Dacadev — Sun, 14 Jun 2026 00:00:00 -0500

Tabla de Contenido

Note

Este artículo abre la serie sobre TypeScript. Aquí analizaremos qué problema resuelve el tipado estático, cómo opera el compilador tsc y cómo dejar listo un proyecto profesional con tsconfig.json.

JavaScript resuelve los tipos en tiempo de ejecución. Esto significa que un error tan trivial como pasar un string donde se esperaba un number solo se manifiesta cuando el código ya está corriendo, frecuentemente en producción y bajo la forma de un NaN silencioso o una excepción difícil de rastrear. TypeScript ataca este problema en la raíz: agrega un sistema de tipos estático sobre JavaScript que traslada la detección de errores desde el runtime hacia el tiempo de compilación.

¿Cómo se ejecuta el código? AST, bytecode y runtime

Para entender qué aporta TypeScript conviene recordar el ciclo de vida de un programa en un motor de JavaScript:

El programa se parsea hacia un AST (Abstract Syntax Tree).
El AST se compila a bytecode.
El bytecode es evaluado por el runtime.

TypeScript se inserta antes de este flujo. El compilador tsc toma tu código .ts, construye su propio AST, lo somete al typechecker y, si todo es válido, emite JavaScript estándar que cualquier motor puede ejecutar.

flowchart LR
 A[Código TypeScript] --> B[AST de TypeScript]
 B --> C{Typechecker}
 C -- válido --> D[JavaScript emitido]
 C -- error --> E[Error en compilación]
 D --> F[AST de JavaScript]
 F --> G[Bytecode]
 G --> H[Runtime]

La conclusión clave: el typechecker es una capa de verificación que se ejecuta antes de generar el JavaScript final. Los errores de tipo nunca llegan al runtime porque la compilación se detiene antes.

El sistema de tipos

TypeScript admite tanto anotaciones de tipo explícitas como inferencia automática. Ambas estrategias coexisten en el mismo archivo:

let a: number = 1 // a es number
let b: string = 'hello' // b es string
let c: boolean[] = [true, false] // c es un arreglo de booleanos

let a = 1 // a es number (inferido)
let b = 'hello' // b es string (inferido)
let c = [true, false] // c es boolean[] (inferido)

Tip

Apóyate en la inferencia siempre que el tipo sea evidente y reserva las anotaciones explícitas para las fronteras del sistema: firmas de funciones, APIs públicas y estructuras de datos compartidas. Esto reduce el ruido sin sacrificar seguridad.

La diferencia esencial frente a JavaScript se resume así:

Característica del sistema de tipos	JavaScript	TypeScript
¿Cómo se enlazan los tipos?	Dinámicamente	Estáticamente
¿Se convierten automáticamente?	Sí	No (en general)
¿Cuándo se verifican?	En tiempo de ejecución	En tiempo de compilación
¿Cuándo afloran los errores?	En ejecución	En compilación

Instalación de TypeScript

TypeScript se distribuye como un paquete de Node, por lo que necesitas tener Node.js instalado. Inicializa el proyecto y agrega las dependencias de desarrollo:

npm init -y
npm install --save-dev typescript @types/node

@types/node aporta las definiciones de tipos del entorno de ejecución de Node, indispensables si vas a trabajar en el backend.

tsconfig.json: el corazón de la configuración

El archivo tsconfig.json, ubicado en la raíz del proyecto, define cómo el compilador interpreta y transforma tu código. Una configuración base sólida luce así:

{
 "compilerOptions": {
 "lib": ["es2015"],
 "module": "commonjs",
 "outDir": "dist",
 "sourceMap": true,
 "strict": true,
 "target": "es2015"
 },
 "include": ["src"]
}

Cada opción cumple un rol concreto:

include: indica las rutas donde tsc debe buscar los archivos a compilar.
lib: declara qué librerías de tipos (APIs del entorno) asume disponibles el proyecto.
module: define el sistema de módulos del código emitido (commonjs, esnext, etc.).
outDir: ubicación de los archivos JavaScript compilados.
sourceMap: genera source maps para depurar el TypeScript original desde el navegador o Node.
strict: habilita el conjunto completo de comprobaciones estrictas. Es la opción que más valor aporta.
target: versión de JavaScript a la que se transpila el código.

Puedes consultar el catálogo completo de opciones en la documentación oficial de tsc, o explorarlas desde la terminal:

npx tsc --help

Warning

La opción strict no es opcional en un proyecto serio. Activarla desde el primer commit evita una migración dolorosa más adelante, cuando el código ya arrastra cientos de tipos implícitos any.

El archivo de entrada: index.ts

El punto de entrada convencional es src/index.ts. Comencemos con el clásico mensaje de prueba:

console.log('hello world from TS!')

Compila el proyecto y ejecútalo:

npx tsc
node ./dist/index.js

tsc lee la configuración de tsconfig.json, transpila todo lo que esté bajo src y deposita el resultado en dist.

Hola mundo y la verificación de tipos en acción

Observemos cómo el typechecker protege contra asignaciones inválidas:

let msg: string = 'Hola mundo';
console.log(msg);
msg = 'David Casas';
console.log(msg);
// msg = 123 // Error: number no es asignable a string

Al compilar, TypeScript transpila a JavaScript plano eliminando las anotaciones:

var msg = 'Hola mundo';
console.log(msg);
msg = 'David Casas';
console.log(msg);

El tipo string desaparece del código emitido porque su único propósito era validar en compilación. Esta propiedad —los tipos se borran tras la verificación— se conoce como type erasure.

Watch mode: compilación continua

Compilar manualmente tras cada cambio rompe el flujo de trabajo. El compilador incluye un modo observador que recompila de forma incremental cada vez que detecta una modificación:

npx tsc --watch
# o su forma corta
npx tsc -w

Mantén este proceso abierto en una terminal mientras desarrollas: cada vez que guardes un archivo .ts, verás de inmediato los errores de tipo o la salida actualizada en dist.

Conclusión

TypeScript no reemplaza a JavaScript; lo eleva añadiendo una capa de verificación estática que captura errores antes de ejecutar una sola línea. Con Node instalado, un tsconfig.json en modo strict y el compilador en watch mode, ya tienes un entorno profesional listo para los siguientes temas de la serie.

En el próximo artículo profundizaremos en los tipos básicos del lenguaje: any, unknown, number, string, symbol, objetos, uniones e intersecciones.

Estilos CSS: Fondos, gradientes y sombras

Dacadev — Fri, 12 Jun 2026 00:00:00 -0500

Tabla de Contenido

Los fondos y las sombras son las herramientas con las que CSS aporta profundidad, textura y jerarquía visual sin necesidad de imágenes externas. Un gradiente bien construido reemplaza un archivo PNG; una sombra sutil comunica que un botón es interactivo. Dominar estas propiedades te permite crear interfaces ricas con código puro, ligero y escalable.

Esta es la sexta entrega de la serie Estilos CSS. Recorreremos la familia de propiedades background, los gradientes lineales y radiales, los modos de mezcla y las sombras de caja y de texto.

Note

Aprenderás a generar gradientes y patrones sin imágenes, a combinar varias capas de fondo y a usar box-shadow y text-shadow para dar realismo y feedback a tus componentes.

La familia background

background es una propiedad abreviada que agrupa ocho propiedades individuales:

background-image — una imagen o un gradiente generado.
background-position — la posición inicial del fondo.
background-size — el tamaño de renderizado (cover, contain, valores explícitos).
background-repeat — si la imagen se repite en mosaico.
background-origin — respecto a qué caja se posiciona (border, padding o content).
background-clip — hasta qué caja se extiende el fondo.
background-attachment — si el fondo se desplaza con el contenido o queda fijo.
background-color — un color sólido que se renderiza detrás de la imagen.

Gradientes lineales

Un gradiente es una transición de colores generada por una función de CSS, sin archivos. linear-gradient() crea una transición a lo largo de una dirección.

.fade { background-image: linear-gradient(to right, #fff, #2a9da9); }

La función acepta una dirección (to right, 90deg, etc.) y una lista de colores. Puedes incluir más de dos colores y fijar su posición con porcentajes:

.fade { background-image: linear-gradient(90deg, #c0392b 0%, #fff 50%, #2a9da9 100%); }

Gradientes lineales repetitivos

repeating-linear-gradient() crea patrones que se repiten, útil para texturas como rayas:

.rayas {
 background-image: repeating-linear-gradient(-45deg,
 #2a9da9, #2a9da9 10px, #16828d 10px, #16828d 20px);
}

Gradientes radiales

radial-gradient() genera una transición circular o elíptica que irradia desde un punto, en lugar de seguir una dirección lineal.

.brillo { background-image: radial-gradient(#fff, #2a9da9); }

Combinar múltiples fondos

Puedes apilar varias capas de fondo separándolas con comas. La primera capa queda al frente. Esto permite, por ejemplo, superponer un gradiente sobre una imagen:

.heroe {
 background-image:
 linear-gradient(to bottom, rgba(42,157,169,0.6), rgba(22,130,141,0.9)),
 url(foto.jpg);
 background-size: cover;
}

Gradiente sobre una textura de fondo

Texturas con blend modes

La propiedad background-blend-mode mezcla las capas de fondo entre sí (con modos como multiply, soft-light, overlay), añadiendo textura a una imagen sin editarla en un programa externo:

.textura {
 background-image: url(rayones.png), url(foto.jpg);
 background-blend-mode: soft-light;
}

Sombras: box-shadow y text-shadow

CSS permite añadir sombras tanto a las cajas (box-shadow) como al texto (text-shadow). Ambas reciben los mismos parámetros básicos:

Desplazamiento horizontal y vertical (offset-x, offset-y).
El radio de difuminado (blur).
(opcional) El radio de expansión (spread).
El color de la sombra.

.tarjeta { box-shadow: 0 0.2em 0.5em rgba(0, 0, 0, 0.25); }
.titulo { text-shadow: 2px 2px 4px rgba(0, 0, 0, 0.4); }

Tarjeta con box-shadow

Texto con text-shadow

Sombras interiores para feedback

La palabra clave inset convierte la sombra en interior, perfecta para simular que un botón está presionado. Combinada con pseudo-clases como :active, crea componentes con feedback táctil:

.boton {
 background-image: linear-gradient(to bottom, #2a9da9, #16828d);
 box-shadow: 0.1em 0.1em 0.5em rgba(0,0,0,0.4);
 color: #fff;
}

.boton:active {
 box-shadow: inset 0 0 0.5em #0d4f56,
 inset 0 0.5em 1em rgba(0,0,0,0.4);
}

Al pulsarlo, la sombra interior simula el hundido físico.

Tip

Las sombras se renderizan en la capa de composición y son baratas de animar. Una transición sutil de box-shadow en :hover comunica interactividad con un costo de rendimiento mínimo.

Conclusión

Los gradientes y las sombras te permiten construir interfaces con profundidad y textura usando solo CSS, evitando peticiones de red y archivos de imagen. Apilar capas de fondo, mezclarlas con blend modes y aplicar sombras interiores son técnicas que elevan la calidad visual de cualquier componente.

Note

🚀 La próxima entrega cubre transiciones y transformaciones: cómo animar cambios de estado de forma fluida y manipular la geometría de los elementos con transform.

Estilos CSS: Posicionamiento, z-index y diseño responsive

Dacadev — Wed, 10 Jun 2026 00:00:00 -0500

Tabla de Contenido

Hasta ahora hemos trabajado con elementos que viven en el flujo normal del documento. El posicionamiento rompe ese flujo: te permite anclar una cabecera al viewport, superponer un modal, desplegar un menú o fijar una barra lateral mientras el usuario hace scroll. Combinado con z-index y las media queries, el posicionamiento es la base de las interacciones dinámicas y del diseño adaptable.

Esta es la quinta entrega de la serie Estilos CSS. Cubriremos los cinco valores de position, los contextos de apilamiento con z-index y los fundamentos del diseño responsive.

Note

Entenderás cuándo usar cada tipo de posicionamiento, por qué z-index a veces “no funciona” por culpa de los contextos de apilamiento, y cómo escribir media queries con un enfoque mobile first.

La propiedad position

La propiedad position acepta cinco valores que cambian cómo se ubica un elemento:

static (por defecto) — el elemento permanece en el flujo normal.
relative — se desplaza respecto a su posición original sin salir del flujo.
absolute — se extrae del flujo y se posiciona respecto a su ancestro posicionado más cercano.
fixed — se extrae del flujo y se posiciona respecto al viewport.
sticky — combina relative y fixed según el scroll.

Las propiedades top, right, bottom y left controlan la ubicación (y, en algunos casos, el tamaño) de los elementos posicionados.

Fixed: anclado al viewport

position: fixed extrae el elemento del flujo normal —los demás se reorganizan como si no existiera— y lo ancla a una posición relativa al viewport, donde permanece aunque el usuario haga scroll. Es la base de los modales: un fondo semitransparente que cubre toda la pantalla y un cuerpo centrado encima.

.modal-backdrop {
 position: fixed;
 top: 0; right: 0; bottom: 0; left: 0;
 background-color: rgba(0, 0, 0, 0.5);
}

.modal-body {
 position: fixed;
 top: 3em; bottom: 3em; right: 20%; left: 20%;
 background-color: white;
 overflow: auto;
}

Tip

Al posicionar no estás obligado a declarar los cuatro lados. Si omites bottom y height, la altura la determina el contenido de forma natural. Combinar lados con width/height te da control total sobre el tamaño.

Absolute: relativo al ancestro posicionado

position: absolute también extrae el elemento del flujo, pero se posiciona respecto al primer ancestro que tenga una posición distinta de static. Si ningún ancestro está posicionado, usa el bloque contenedor inicial (el tamaño del viewport).

Este es el patrón para colocar un botón de cierre en la esquina de un modal: el padre se marca como position: relative y el botón como position: absolute.

.modal-body { position: relative; }
.modal-close { position: absolute; top: 0.3em; right: 0.3em; }

✕ Cuerpo del modal

El botón de cierre está posicionado en la esquina con absolute respecto a este contenedor relative.

Relative: desplazamiento sin salir del flujo

A diferencia de los anteriores, position: relative no extrae el elemento del flujo; lo traslada respecto a su posición original, dejando su hueco intacto. Tampoco permite redimensionarlo con la combinación de lados.

Su uso más frecuente es establecer un bloque contenedor para descendientes absolutos. Es la base de un menú desplegable: el contenedor es relative y el menú es absolute, mostrándose con :hover.

.dropdown { position: relative; display: inline-block; }

.dropdown-menu { position: absolute; top: 100%; left: 0; display: none; }

.dropdown:hover .dropdown-menu { display: block; }

Menú principal ▾

Pasa el cursor sobre el botón para desplegar el menú.

Sticky: lo mejor de relative y fixed

position: sticky mantiene el elemento en su posición normal hasta que, al hacer scroll, alcanza el umbral definido por top/bottom; en ese momento se “pega” como si fuera fixed. Cuando el contenido vuelve, recupera su comportamiento relativo. Es ideal para barras laterales y cabeceras de sección que deben permanecer visibles.

.afijo { position: sticky; top: 1em; }

Stacking contexts y z-index

Cuando varios elementos posicionados se solapan, z-index controla el orden de apilamiento en el eje Z. Acepta enteros positivos y negativos: a mayor valor, más al frente.

.uno { position: relative; z-index: 1; }
.dos { position: relative; z-index: 2; } /* queda por encima de .uno */

Aquí está la trampa que confunde a muchos: cada elemento posicionado con z-index crea su propio contexto de apilamiento. Un hijo dentro de un contexto con z-index: 1 nunca podrá superar a un elemento de un contexto hermano con z-index: 2, aunque el hijo tenga z-index: 99999.

Warning

z-index tiene dos “gotchas”: solo funciona sobre elementos posicionados (cualquier position distinto de static), y al usarlo creas un nuevo contexto de apilamiento. Si un z-index enorme “no funciona”, casi siempre es porque su elemento está atrapado en un contexto de apilamiento de menor prioridad.

Responsive: estilos que se adaptan

La enorme variedad de pantallas obliga a diseñar interfaces que respondan a distintos tamaños. La filosofía mobile first consiste en escribir primero los estilos para móvil y luego ampliarlos progresivamente hacia tablets y escritorio.

Media queries

Una media query aplica un bloque de CSS solo cuando se cumple una condición sobre el viewport. Conviene usar em en los umbrales para que respeten el zoom y la configuración del usuario.

@media (min-width: 35em) {
 .titulo { font-size: 2.25rem; }
}

Puedes combinar condiciones con lógica:

/* AND: ambas condiciones */
@media (min-width: 20em) and (max-width: 35em) { /* ... */ }

/* OR: cualquiera de las dos */
@media (max-width: 20em), (min-width: 35em) { /* ... */ }

Entre las características consultables están min-width, max-width, min-height, orientation: landscape | portrait y min-resolution: 2dppx (para pantallas retina). El catálogo completo está en la documentación de @media en MDN.

Breakpoints con mobile first

Los breakpoints son los puntos donde el diseño cambia de un tamaño a otro. Con el enfoque mobile first, los estilos base sirven al móvil y cada media query añade ajustes para pantallas mayores:

.titulo { font-size: 1.5rem; } /* móvil (base) */

@media (min-width: 35em) { /* tablet */
 .titulo { font-size: 2rem; }
}

@media (min-width: 50em) { /* escritorio */
 .titulo { font-size: 2.5rem; }
}

Este título cambia de tamaño según el ancho

Redimensiona la ventana para cruzar los breakpoints de 35em y 50em.

Estilos para impresión

Las media queries también cubren el medio de impresión. @media print aplica reglas cuando el usuario imprime o exporta a PDF:

@media print {
 * { color: black !important; background: none !important; }
}

Conclusión

El posicionamiento te da control fino sobre dónde vive cada elemento: fixed para modales, absolute para tooltips y menús, relative como ancla, y sticky para elementos que acompañan el scroll. Sumado a un manejo consciente de los contextos de apilamiento y a media queries con enfoque mobile first, tienes las piezas para construir interfaces dinámicas y adaptables.

Note

🚀 La próxima entrega explora los fondos y las sombras: gradientes, modos de mezcla y las propiedades box-shadow y text-shadow para dar profundidad a tus componentes.

Estilos CSS: Layouts con Float, Flexbox y Grid

Dacadev — Mon, 08 Jun 2026 00:00:00 -0500

Tabla de Contenido

Maquetar es componer la estructura visual de una página: columnas, rejillas, barras laterales, galerías. Durante años se hizo con herramientas que no se diseñaron para ello —float nació para envolver texto alrededor de imágenes— hasta que llegaron Flexbox y CSS Grid, dos sistemas pensados específicamente para layout. Conocer los tres te permite entender el código heredado y elegir la herramienta correcta para cada problema.

Esta es la cuarta entrega de la serie Estilos CSS. Recorreremos float y la técnica clearfix, el modelo unidimensional de Flexbox y el sistema bidimensional de Grid, con ejemplos que puedes ver renderizados.

Note

Aprenderás cuándo sigue siendo útil float, cómo controlar el tamaño de los ítems con flex, y cómo posicionar elementos en una rejilla con grid-template.

Float: el origen y el clearfix

float extrae un elemento del flujo normal y lo desplaza hacia un lado de su contenedor; el contenido adyacente fluye a su alrededor. Ese fue su propósito original: envolver texto alrededor de una imagen.

.imagen { float: left; margin-right: 1em; }

float

Este párrafo fluye alrededor del bloque flotado. El texto se ajusta al margen del elemento extraído del flujo, exactamente el caso de uso para el que float fue concebido: envolver contenido alrededor de una figura.

Cuando usas float, necesitas limpiar el flujo para que el contenedor vuelva a comportarse con normalidad. El patrón estándar es el clearfix, implementado con un pseudo-elemento:

.clearfix::before,
.clearfix::after {
 display: table;
 content: " ";
}

.clearfix::after {
 clear: both;
}

Tip

Para layouts modernos, float casi siempre se reemplaza por Flexbox o Grid. Resérvalo para su propósito original: envolver texto alrededor de un elemento.

Flexbox: layout en una dimensión

Al aplicar display: flex a un contenedor, este se convierte en un flex container y sus hijos en flex items. Flexbox organiza los ítems a lo largo de un eje principal y los alinea en el eje transversal, ajustando tamaños de forma flexible.

Un contenedor flex tiene dos ejes:

Eje principal (main) — la dirección en la que se colocan los ítems (horizontal por defecto).
Eje transversal (cross) — perpendicular al principal.

Alinear ítems con justify-content y align-items

justify-content controla la distribución a lo largo del eje principal: flex-start, flex-end, center, space-between, space-around.
align-items controla la alineación en el eje transversal: stretch (por defecto), flex-start, flex-end, center, baseline.

.barra {
 display: flex;
 justify-content: space-between;
 align-items: center;
}

Logo Menú Perfil

Controlar el tamaño: flex-grow, flex-shrink y flex-basis

La propiedad abreviada flex agrupa tres propiedades que gobiernan el tamaño de cada ítem:

flex-basis — el tamaño base (de partida) del ítem antes de crecer o encoger. Su valor inicial es auto.
flex-grow — el factor de crecimiento para repartir el espacio sobrante. 0 no crece.
flex-shrink — el factor de encogimiento cuando falta espacio.

.col-a { flex: 1; } /* crece para ocupar el espacio sobrante */
.col-b { flex: 2; } /* crece al doble que col-a */

flex: 1

flex: 2 (el doble de ancho)

Dirección y envoltura

flex-direction cambia el eje principal: row (por defecto), row-reverse, column, column-reverse.
flex-wrap permite que los ítems salten a una nueva línea cuando no caben: nowrap (por defecto), wrap, wrap-reverse.
flex-flow es la abreviatura de ambas: flex-flow: row wrap.

Propiedades del ítem

align-self — sobrescribe align-items para un ítem concreto.
order — reordena los ítems sin tocar el HTML; el valor inicial es 0.

Info

Flexbox crea automáticamente columnas de igual altura y es la herramienta ideal para centrar un elemento. Para un catálogo de bugs conocidos y sus soluciones, consulta flexbugs.

CSS Grid: layout en dos dimensiones

Mientras Flexbox trabaja en un solo eje, CSS Grid organiza el contenido en filas y columnas simultáneamente. Antes de usarlo conviene fijar su vocabulario:

Grid line — las líneas que forman la estructura de la rejilla.
Grid track — el espacio entre dos líneas adyacentes (una fila o una columna).
Grid cell — la intersección de una fila y una columna.
Grid area — un rectángulo formado por una o más celdas.

Una rejilla básica

Se activa con display: grid y se definen las pistas con grid-template-columns y grid-template-rows. La unidad fr representa una fracción del espacio disponible.

.grid {
 display: grid;
 grid-template-columns: 1fr 1fr 1fr;
 gap: 0.5em;
}

La función repeat() evita la repetición: grid-template-columns: repeat(3, 1fr) equivale a 1fr 1fr 1fr.

Posicionar ítems por líneas

Cada línea de la rejilla tiene un número. Con grid-column y grid-row indicas dónde empieza y termina un ítem usando la sintaxis inicio / fin:

.destacado {
 grid-column: 1 / 3; /* abarca de la línea 1 a la 3 */
 grid-row: span 2; /* abarca dos pistas verticales */
}

grid-column: 1 / 3

Áreas con nombre

La forma más legible de componer un layout es nombrar las áreas con grid-template-areas y asignar cada elemento con grid-area:

.contenedor {
 display: grid;
 grid-template-areas:
 "titulo titulo"
 "nav nav"
 "main aside";
 grid-template-columns: 2fr 1fr;
 gap: 1em;
}

header { grid-area: titulo; }
nav { grid-area: nav; }
.main { grid-area: main; }
.aside { grid-area: aside; }

titulo

nav

main

aside

Rejilla implícita y galerías responsivas

Cuando no conoces de antemano la cantidad de ítems —por ejemplo, datos que vienen de una API— la rejilla implícita crece automáticamente para acomodarlos. La combinación de auto-fill con minmax() produce galerías que se adaptan al ancho disponible sin media queries:

.galeria {
 display: grid;
 grid-template-columns: repeat(auto-fill, minmax(180px, 1fr));
 gap: 1em;
}

Redimensiona la ventana: las columnas se reorganizan solas.

Warning

Con Grid solo puedes formar rectángulos. No se pueden crear formas en L o U directamente; se simulan dejando celdas vacías (con . en grid-template-areas) o combinando áreas.

Flexbox y Grid: complementarios, no rivales

No tienes que elegir uno. La combinación más potente es usar Grid para la estructura macro de la página (cabecera, contenido, barra lateral, pie) y Flexbox para alinear el contenido dentro de cada zona (una barra de navegación, una tarjeta, un grupo de botones).

Conclusión

float resuelve el envolvimiento de texto; Flexbox domina el layout en una dimensión y el centrado; Grid organiza estructuras bidimensionales complejas. Elegir la herramienta adecuada para cada problema —y combinarlas— es lo que distingue una maquetación robusta de una llena de parches.

Note

🚀 En la próxima entrega abordamos el posicionamiento (relative, absolute, fixed, sticky), los contextos de apilamiento con z-index y el diseño responsive con media queries.

Estilos CSS: Dominando el modelo de caja

Dacadev — Sat, 06 Jun 2026 00:00:00 -0500

Tabla de Contenido

El modelo de caja es el sistema con el que CSS calcula el tamaño y el espaciado de cada elemento. Parece trivial, pero es la fuente número uno de layouts impredecibles: un width: 50% que termina midiendo más de la mitad, dos columnas que no encajan, márgenes que desaparecen sin razón aparente. Todos esos síntomas se explican entendiendo cómo el navegador compone una caja.

Esta es la tercera entrega de la serie Estilos CSS. Analizaremos las cuatro regiones de una caja, el cambio de comportamiento que introduce box-sizing, el control de overflow, el manejo de alturas, el centrado vertical y el colapso de márgenes.

Note

Comprenderás por qué box-sizing: border-box debería ser tu valor por defecto y aprenderás a resolver los problemas clásicos de altura, centrado vertical y colapso de márgenes.

Las cuatro regiones de una caja

Todo elemento HTML se compone, de adentro hacia afuera, de cuatro capas:

content — el área donde vive el contenido (texto, imágenes).
padding — el espacio interno entre el contenido y el borde.
border — el borde que rodea el padding.
margin — el espacio externo que separa la caja de sus vecinos.

<div class="caja">content + padding + border + margin</div>

content

El área azul es el content; el beige es el padding; el trazo turquesa es el border; el espacio punteado exterior es el margin.

`box-sizing`: content-box vs border-box

La propiedad box-sizing decide qué incluye el width y el height que declaras.

content-box (valor por defecto) — width y height miden solo el contenido. El padding y el border se suman por fuera, agrandando el tamaño final.
border-box — width y height miden el conjunto de contenido + padding + border. El tamaño que declaras es el tamaño real renderizado.

Mira dos cajas con width: 200px y padding: 20px, una con cada modelo:

.content-box { box-sizing: content-box; } /* ancho real: 200 + 40 = 240px */
.border-box { box-sizing: border-box; } /* ancho real: 200px */

content-box → mide 246px en total

border-box → mide 200px en total

Por eso es práctica recomendada activar border-box de forma global, heredándolo para no romper estilos de terceros:

:root { box-sizing: border-box; }

*, ::before, ::after { box-sizing: inherit; }

Warning

Evita los números mágicos: valores arbitrarios (margin-top: 37px) que “cuadran” un diseño por casualidad. Haz que el contenido se adapte al contenedor, no al revés.

Alturas: el flujo normal manda

La altura de un contenedor es orgánica por defecto: la define su contenido, no el contenedor. Esto tiene dos consecuencias prácticas:

Definir height en porcentaje rara vez funciona, porque se refiere a la altura del padre, que a su vez depende de su contenido.
Para que un height: 100% funcione, el padre necesita una altura explícita en unidades absolutas.

En lugar de fijar alturas, prefiere restringir el rango con min-height y max-height, dejando que el contenido fluya:

.panel { min-height: 6em; max-height: 12em; }

`overflow`: qué hacer cuando el contenido se desborda

Cuando el contenido excede el tamaño de su caja, overflow define el comportamiento:

Valor	Comportamiento
`visible` (por defecto)	El contenido se desborda y permanece visible.
`hidden`	El contenido que se sale se recorta.
`scroll`	Siempre añade barras de desplazamiento.
`auto`	Añade barras solo si hace falta.

.recorte { overflow: auto; max-height: 5em; }

Este contenedor tiene overflow: auto y una altura máxima.

Cuando el contenido supera esa altura, aparece una barra de desplazamiento.

Línea adicional para forzar el desbordamiento.

Y una más para asegurar el scroll.

Puedes controlar cada eje por separado con overflow-x y overflow-y, aunque mezclar valores distintos suele dar resultados poco predecibles.

Centrado vertical

Centrar verticalmente fue durante años un dolor de cabeza en CSS. La propiedad vertical-align no sirve para esto: solo aplica a elementos inline y a celdas de tabla. Hoy tenemos varias soluciones según el escenario:

¿Puedes usar la altura natural? Aplica un padding igual arriba y abajo.
¿Necesitas altura fija? Usa display: table-cell con vertical-align: middle.
El caso general: usa flexbox.
¿Una sola línea de texto? Usa line-height igual a la altura del contenedor.

La solución moderna por excelencia es flexbox, que centra en ambos ejes con tres declaraciones:

.centro {
 display: flex;
 align-items: center; /* eje vertical */
 justify-content: center; /* eje horizontal */
 min-height: 8em;
}

Centrado en ambos ejes

Márgenes negativos

A diferencia de padding y border, los márgenes admiten valores negativos, lo que te permite tirar de un elemento hacia afuera de su posición natural o solaparlo con su vecino.

.solapado { margin-top: -1.5em; }

Bloque base

Bloque con margin-top negativo que se solapa

Colapso de márgenes (margin collapsing)

Cuando dos márgenes verticales se encuentran, no se suman: se colapsan, quedando solo el de mayor valor. Si un párrafo tiene margin-bottom: 30px y el siguiente margin-top: 20px, la separación entre ambos será de 30px, no 50px.

Info

El colapso de márgenes solo ocurre con márgenes verticales (arriba y abajo). Los márgenes horizontales (izquierda y derecha) nunca colapsan.

Hay varias formas de impedir el colapso cuando no lo deseas:

Aplicar overflow: auto (o cualquier valor distinto de visible) al contenedor.
Añadir un border o un padding entre los dos márgenes.
Usar un contenedor flotado, inline-block o con posición absoluta/fija.
Usar flexbox o grid: los márgenes entre ítems del layout no colapsan.
Los elementos con display: table-cell no tienen margen, así que no colapsan.

Conclusión

El modelo de caja deja de ser un misterio cuando interiorizas que box-sizing controla la aritmética del tamaño, que la altura es orgánica por naturaleza y que los márgenes verticales colapsan. Activar border-box de forma global y apoyarte en flexbox para el centrado elimina la mayoría de los problemas clásicos de maquetación.

Note

🚀 La siguiente entrega cubre los sistemas de layout: float, flexbox y CSS Grid, las herramientas con las que componemos la estructura completa de una página.

Futures, Awaitables y Errores Comunes en asyncio

Dacadev — Wed, 13 May 2026 00:00:00 -0500

Tabla de Contenido

En los artículos anteriores aprendimos a crear coroutines con async/await y ejecutar tasks concurrentes. En este artículo vamos a cerrar el modelo mental: entenderemos qué son los futures, cómo se relacionan con tasks y coroutines a través de los awaitables, y veremos cómo medir el rendimiento de nuestro código asíncrono. Para cerrar, hablaremos de los dos errores más comunes al trabajar con asyncio.

Futures: Un Valor que Aún No Existe

Un future es un objeto de Python que representa un valor que esperamos obtener en algún momento, pero que todavía no tenemos. Cuando se crea, un future está en estado incompleto. Una vez que el valor llega, se establece con set_result y el future pasa a estar completado.

from asyncio import Future

my_future = Future()

print(f'¿Está completo? {my_future.done()}') # False

my_future.set_result(42)

print(f'¿Está completo? {my_future.done()}') # True
print(f'Resultado: {my_future.result()}') # 42

stateDiagram-v2
 [*] --> Incompleto: Future()
 Incompleto --> Completado: set_result(valor)
 Completado --> [*]: result() → valor

 note right of Incompleto
 done() → False
 result() → InvalidStateError
 end note

 note right of Completado
 done() → True
 result() → valor
 end note

Futures en la práctica

En la mayoría de los casos no crearás futures directamente — asyncio los gestiona internamente. Pero entender su mecánica es clave para comprender cómo funciona todo por dentro. Veamos un ejemplo donde un task establece el valor de un future después de un segundo:

from asyncio import Future
import asyncio


def hacer_peticion() -> Future:
 future = Future()
 asyncio.create_task(establecer_valor(future)) # 1
 return future


async def establecer_valor(future) -> None:
 await asyncio.sleep(1) # 2
 future.set_result(42)


async def main():
 future = hacer_peticion()
 print(f'¿Está completo? {future.done()}') # False
 valor = await future # 3
 print(f'¿Está completo? {future.done()}') # True
 print(valor) # 42


asyncio.run(main())

Crea un task que configurará el valor del future.
Espera 1 segundo antes de establecer el resultado.
await pausa main() hasta que el future reciba su valor.

sequenceDiagram
 participant M as main()
 participant F as Future
 participant T as task: establecer_valor()

 M->>F: hacer_peticion() → Future incompleto
 M->>T: create_task(establecer_valor(future))
 M->>F: await future
 Note over M: ⏸ PAUSE main()
 T->>T: await asyncio.sleep(1)
 Note over T: ⏳ 1 segundo...
 T->>F: set_result(42)
 Note over F: ✅ Completado
 F-->>M: ▶ RESUME main()
 Note over M: valor = 42

La Jerarquía de los Awaitables

Tanto las coroutines como los tasks pueden usarse con await. ¿Qué tienen en común? Ambos son awaitables — objetos que implementan el método __await__, que es lo que Python necesita para poder usar la palabra clave await sobre ellos.

La relación entre estos conceptos forma una jerarquía clara:

flowchart TD
 A["Awaitable\n(__await__)"] --> B["Coroutine"]
 A --> C["Future"]
 C --> D["Task"]

 style A fill:#8b5cf6,stroke:#5b21b6,color:#fff
 style B fill:#3b82f6,stroke:#1e40af,color:#fff
 style C fill:#f59e0b,stroke:#b45309,color:#fff
 style D fill:#10b981,stroke:#065f46,color:#fff

Awaitable es la clase base que define el protocolo __await__. Todo lo que se pueda usar con await es un awaitable.
Coroutine es una función definida con async def. Hereda de Awaitable.
Future representa un valor pendiente. También hereda de Awaitable.
Task hereda de Future. Es la combinación de un future y una coroutine: encapsula una coroutine y la ejecuta en el event loop, mientras que el future subyacente almacena el resultado cuando la coroutine termina.

Note

Un Future es qué esperamos obtener. Un Task es cómo lo obtenemos (ejecutando una coroutine). Y Awaitable es el contrato que ambos cumplen para que await funcione.

Midiendo el Tiempo de Ejecución

Cuando trabajamos con código asíncrono, medir cuánto tarda cada operación es esencial para verificar que la concurrencia realmente funciona. La mejor forma de hacerlo es con un decorador que registre el tiempo de inicio y fin de cada coroutine:

import functools
import time
from typing import Callable, Any


def async_timed():
 def wrapper(func: Callable) -> Callable:
 @functools.wraps(func)
 async def wrapped(*args, **kwargs) -> Any:
 print(f'starting {func} with args {args} {kwargs}')
 start = time.time()
 try:
 return await func(*args, **kwargs)
 finally:
 end = time.time()
 total = end - start
 print(f'finished {func} in {total:.4f} second(s)')

 return wrapped

 return wrapper

Uso en la práctica

import asyncio


@async_timed()
async def delay(delay_seconds: int) -> int:
 print(f'sleeping for {delay_seconds} second(s)')
 await asyncio.sleep(delay_seconds)
 print(f'finished sleeping for {delay_seconds} second(s)')
 return delay_seconds


@async_timed()
async def main():
 task_one = asyncio.create_task(delay(2))
 task_two = asyncio.create_task(delay(3))

 await task_one
 await task_two


asyncio.run(main())

starting <function main ...> with args () {}
starting <function delay ...> with args (2,) {}
starting <function delay ...> with args (3,) {}
finished <function delay ...> in 2.0032 second(s)
finished <function delay ...> in 3.0003 second(s)
finished <function main ...> in 3.0004 second(s)

El output confirma lo que esperamos: ambos tasks corren concurrentemente. delay(2) termina a los ~2 segundos, delay(3) a los ~3, y main() tarda ~3 segundos en total (no 5).

gantt
 title Ejecución concurrente verificada con @async_timed
 dateFormat X
 axisFormat %s

 section delay(2)
 sleep(2) :a1, 0, 2

 section delay(3)
 sleep(3) :b1, 0, 3

 section main()
 Tiempo total :c1, 0, 3

Errores Comunes en `asyncio`

Hay dos trampas frecuentes que pueden arruinar el rendimiento de una aplicación async. Ambas tienen la misma causa: bloquear el event loop.

1. Ejecutar código CPU-bound en coroutines

Cuando tenemos funciones computacionalmente costosas (cálculos matemáticos, procesamiento de datos grandes), puede parecer buena idea envolverlas en tasks para ejecutarlas concurrentemente. Pero recuerda: asyncio usa un solo hilo. El GIL garantiza que solo una instrucción de bytecode se ejecute a la vez, así que el código CPU-bound bloqueará el event loop sin importar cuántos tasks crees.

flowchart LR
 A["Código CPU-bound\nen una coroutine"] -->|"Bloquea el\nevent loop 🛑"| B["Otras tareas\nno pueden ejecutarse"]
 C["Solución"] --> D["multiprocessing\no run_in_executor()"]

 style A fill:#ef4444,stroke:#991b1b,color:#fff
 style B fill:#ef4444,stroke:#991b1b,color:#fff
 style D fill:#10b981,stroke:#065f46,color:#fff

2. Usar APIs bloqueantes

El mismo problema ocurre al usar librerías de I/O que no son asíncronas. Librerías como requests o funciones como time.sleep bloquean el hilo principal. Cuando las llamas dentro de una coroutine, bloqueas el event loop completo y ninguna otra coroutine puede ejecutarse.

❌ Bloqueante
✅ No bloqueante

No uses estas funciones dentro de coroutines

requests.get() → bloquea el event loop
time.sleep() → bloquea el event loop
Cualquier función de I/O síncrona

Usa las alternativas asíncronas

aiohttp → reemplazo async de requests
asyncio.sleep() → cede control al event loop
asyncpg → cliente async de PostgreSQL
aiofiles → lectura/escritura async de archivos

Warning

Regla general: cualquier función que realice I/O y no sea una coroutine, o que ejecute operaciones CPU costosas, debe considerarse bloqueante. Para CPU-bound, usa loop.run_in_executor() con un ProcessPoolExecutor.

En conclusión

Un Future representa un valor que aún no existe — se completa con set_result.
Un Task es un future + una coroutine: ejecuta la coroutine y almacena su resultado en el future subyacente.
Todo lo que se pueda usar con await es un Awaitable — el contrato que unifica coroutines, futures y tasks.
El decorador @async_timed permite verificar que la concurrencia funciona midiendo tiempos reales.
Los dos errores más comunes son ejecutar código CPU-bound y usar APIs bloqueantes dentro de coroutines — ambos bloquean el event loop.

Referencias

Coroutines y async/await: Tu Primer Código Asíncrono en Python

Dacadev — Tue, 12 May 2026 00:00:00 -0500

Tabla de Contenido

En los artículos anteriores construimos la base teórica: concurrencia vs paralelismo, procesos, hilos, el GIL y el event loop. Ahora es momento de escribir código. En este artículo vamos a aprender a crear coroutines, usar las palabras clave async y await, y entender exactamente qué pasa cuando pausamos y reanudamos la ejecución.

¿Qué es una Coroutine?

Una coroutine es como una función normal de Python, pero con un superpoder: puede pausar su ejecución cuando encuentra una operación que podría tardar (una petición de red, una lectura de disco, una espera). Mientras la coroutine está pausada, el event loop puede ejecutar otras tareas. Cuando la operación termina, la coroutine se “despierta” y continúa desde donde se detuvo.

Esta capacidad de pausar y reanudar es lo que le da concurrencia a nuestra aplicación.

Para trabajar con coroutines necesitamos dos palabras clave:

async def → define una coroutine.
await → pausa la coroutine hasta que la operación esperada termine.

Creando Coroutines

Crear una coroutine es casi idéntico a crear una función normal. La única diferencia es usar async def en lugar de def:

async def mi_coroutine() -> None:
 print('¡Hola mundo!')

Info

Llamar a una coroutine no la ejecuta. Solo produce un objeto coroutine. Para ejecutarla, necesitas un event loop.

# ❌ Esto NO ejecuta la coroutine
mi_coroutine() # Retorna un objeto coroutine, no imprime nada

# ✅ Esto SÍ la ejecuta
import asyncio
asyncio.run(mi_coroutine()) # Imprime: ¡Hola mundo!

Ejecutando Coroutines con `asyncio.run`

asyncio.run es el punto de entrada principal de cualquier aplicación asyncio. Veamos un ejemplo concreto:

import asyncio


async def sumar_uno(numero: int) -> int:
 return numero + 1


resultado = asyncio.run(sumar_uno(1))
print(resultado) # 2

asyncio.run hace varias cosas por nosotros:

Crea un event loop nuevo.
Ejecuta la coroutine que le pasamos hasta que se completa.
Retorna el resultado de la coroutine.
Limpia cualquier tarea pendiente y cierra el event loop.

flowchart LR
 A["asyncio.run(coroutine)"] --> B["Crea el\nEvent Loop"]
 B --> C["Ejecuta la\ncoroutine"]
 C --> D["Retorna\nel resultado"]
 D --> E["Cierra el\nEvent Loop"]

 style A fill:#3b82f6,stroke:#1e40af,color:#fff
 style C fill:#10b981,stroke:#065f46,color:#fff
 style E fill:#64748b,stroke:#334155,color:#fff

Info

asyncio.run está diseñado para ejecutarse una sola vez como entrada principal de tu aplicación. Esa única coroutine debería encargarse de lanzar todas las demás tareas.

Pausando la Ejecución con `await`

El verdadero poder de asyncio está en await. Esta palabra clave hace dos cosas:

Ejecuta la coroutine que le sigue (a diferencia de llamarla directamente, que solo crea el objeto).
Pausa la coroutine contenedora hasta que la coroutine esperada retorne un resultado.

Cuando la coroutine esperada termina, la coroutine contenedora se “despierta” y puede usar el resultado.

import asyncio


async def obtener_saludo() -> str:
 return '¡Hola desde una coroutine!'


async def main() -> None:
 saludo = await obtener_saludo() # Pausa main() hasta obtener el resultado
 print(saludo)


asyncio.run(main())

Simulando Operaciones Largas con `asyncio.sleep`

Para simular una operación de I/O de larga duración (como una petición HTTP o una consulta a base de datos), podemos usar asyncio.sleep. Esta función pausa la coroutine por el número de segundos indicado, cediendo el control al event loop.

Veamos un ejemplo más completo con una función auxiliar delay:

import asyncio


async def delay(seconds: int) -> str:
 print(f'Esperando {seconds} segundo(s)...')
 await asyncio.sleep(seconds)
 print(f'¡Espera de {seconds} segundo(s) completada!')
 return f'Esperé {seconds} segundo(s)'

La Trampa del `await` Secuencial

Ahora veamos un error muy común al empezar con asyncio. Considera este código:

import asyncio


async def sumar_uno(numero: int) -> int:
 return numero + 1


async def mensaje_hola_mundo() -> str:
 await asyncio.sleep(1)
 return '¡Hola Mundo!'


async def main() -> None:
 mensaje = await mensaje_hola_mundo() # Pausa 1 segundo
 uno_mas_uno = await sumar_uno(1) # Ejecuta después de la pausa
 print(uno_mas_uno)
 print(mensaje)


asyncio.run(main())

Cuando ejecutamos este código, pasa 1 segundo antes de que se impriman ambos resultados. Pero sumar_uno(1) es instantánea — ¿por qué espera?

Warning

await pausa toda la coroutine contenedora. No se ejecuta ningún otro código dentro de main() hasta que la expresión await retorne un valor. Como mensaje_hola_mundo() tarda 1 segundo, main() queda pausada ese segundo completo antes de siquiera llegar a sumar_uno(1).

El siguiente diagrama muestra exactamente qué pasa en cada momento:

sequenceDiagram
 participant EL as Event Loop
 participant M as main()
 participant HW as mensaje_hola_mundo()
 participant AO as sumar_uno(1)

 EL->>M: ▶ RUN main()
 Note over M: await mensaje_hola_mundo()
 M->>HW: ▶ RUN mensaje_hola_mundo()
 HW->>HW: await sleep(1)
 Note over M: ⏸ PAUSE main()
 Note over HW: ⏸ PAUSE mensaje_hola_mundo()
 Note over EL: ⏳ Pasa 1 segundo...
 EL->>HW: ▶ RESUME mensaje_hola_mundo()
 Note over HW: return '¡Hola Mundo!'
 HW-->>M: ▶ RESUME main()
 Note over M: mensaje = '¡Hola Mundo!'
 Note over M: await sumar_uno(1)
 M->>AO: ▶ RUN sumar_uno(1)
 Note over AO: return 1 + 1
 AO-->>M: ▶ RESUME main()
 Note over M: uno_mas_uno = 2
 Note over M: print() resultados

El problema visualizado

El flujo de ejecución es completamente secuencial, a pesar de usar async/await:

gantt
 title Ejecución secuencial — Sin concurrencia real
 dateFormat X
 axisFormat %s

 section main()
 await mensaje_hola_mundo() :a1, 0, 10
 await sumar_uno(1) :a2, 10, 11
 print() resultados :a3, 11, 12

Lo que queremos es que sumar_uno(1) se ejecute mientras mensaje_hola_mundo() espera su segundo de delay. Pero con await secuencial eso no es posible — cada await bloquea la coroutine hasta completarse.

¿Cómo logramos concurrencia real?

Para ejecutar múltiples coroutines de forma concurrente necesitamos herramientas como asyncio.gather o asyncio.create_task. Un adelanto rápido:

async def main() -> None:
 # ✅ Ambas coroutines corren concurrentemente
 mensaje, uno_mas_uno = await asyncio.gather(
 mensaje_hola_mundo(),
 sumar_uno(1)
 )
 print(uno_mas_uno)
 print(mensaje)

Con gather, el event loop puede ejecutar sumar_uno(1) mientras mensaje_hola_mundo() está pausada esperando su sleep. El tiempo total se mantiene en ~1 segundo en lugar de sumar ambos tiempos.

gantt
 title Ejecución concurrente — Con asyncio.gather
 dateFormat X
 axisFormat %s

 section mensaje_hola_mundo()
 await sleep(1) :a1, 0, 10

 section sumar_uno(1)
 return 1 + 1 :a2, 0, 1

 section main()
 print() resultados :a3, 10, 11

En conclusión

flowchart TD
 A["async def"] -->|"Define"| B["Coroutine"]
 B -->|"Se ejecuta con"| C["asyncio.run()"]
 B -->|"Se pausa con"| D["await"]
 D -->|"Cede control al"| E["Event Loop"]
 E -->|"Cuando I/O completa"| F["Reanuda la coroutine"]
 C -->|"Crea y gestiona"| E

 style A fill:#8b5cf6,stroke:#5b21b6,color:#fff
 style B fill:#3b82f6,stroke:#1e40af,color:#fff
 style D fill:#f59e0b,stroke:#b45309,color:#fff
 style E fill:#10b981,stroke:#065f46,color:#fff

async def define una coroutine — una función que puede pausarse.
await pausa la coroutine actual hasta que la operación esperada termine.
asyncio.run crea el event loop y ejecuta la coroutine principal.
asyncio.sleep simula operaciones de I/O de larga duración.
Usar await de forma secuencial no da concurrencia — para eso necesitamos asyncio.gather o asyncio.create_task.

Referencias

Tipado básico en Python

Dacadev — Sat, 10 Aug 2024 00:00:00 -0500

Tabla de Contenido

Note

Este artículo es parte de una serie que explica el tipado en Python. A continuación, puedes ver la recopilación de todos los posts de la serie.

Ver serie

Agregar tipos en Python es muy sencillo y tiene una sintaxis similar a otros lenguajes como Typescript. No es obligatorio aplicar tipado en cada pieza de código, lo que permite agregarlo de manera gradual. Además, agregar o no tipos no afectará el comportamiento del código.

Info

La posibilidad de agregar tipado en Python está disponible desde la versión 3.5. Desde entonces, se han añadido nuevas características y mejoras.

Tipos Buitl-in in Python

Los tipos built-in son aquellos que vienen por defecto en Python, como str, int, float, bool, bytes, None, list, dict, tuple, set, entre otros.

Para agregar tipado a una variable, simplemente añade : después del nombre de la variable y luego especifica el tipo de dato. La sintaxis es:

<variable>: <type> = <value>

Ejemplo:

n: int = 1
f: float = 10.0
c: complex = 1 + 2j
b: bool = True
s: bytes = b'bytes'
t: str = "hello world"
v: None = None

En el anterior ejemplo estamos definiendo que cada una de las variables solo van a manejar un tipo de datos a lo largo de vida en el programa.

Note

Recuerda que el agregar el tipo de dato no afecta el comportamiento del código, es solo una ayuda para el programador, analizadores de código estáticos e IDEs.

Tipado en colecciones

Para colecciones como list, dict, tuple, set, la sintaxis es similar a la de las variables simples. salvo que podemos definir o nor el tipo de variable que cada variable va a contener. es decir que tenemos dos tipos de sintaxis que podemos utilizar.

<variable>: <collection> = <value>
<variable>: <collection>[<type>...] = <value>

En la primera opción estamos definiendo que la variable va a ser de tipo list, dict, tuple, set y en la segunda opción estamos definiendo que la variable va a ser de tipo list, dict, tuple, set y que va a contener un tipo de dato especifico. Veamos como se aplica esto en algunos ejemplos, para ello es importante tener en cuenta la versión de Python que estás utilizando.

Python 3.5 a 3.8: Es necesario importar los tipos de la librería typing:

from typing import List, Set, Tuple, Dict

l: List = [1, 2, 3, 4]
s: Set[str] = {"hello", "world"}
t: Tuple[int, str, bool] = (10, "Python", True)
d: Dict[str, bool] = {"active": True, "admin": False}

Python 3.9 y posteriores: Puedes utilizar la sintaxis estándar sin importar typing:

l: list = [1, 2, 3, 4]
s: set[str] = {"hello", "world"}
t: tuple[int, str, bool] = (10, "Python", True)
d: dict[str, bool] = {"active": True, "admin": False}

En los ejemplos anteriores podemos observar que estamos definiendo un tipo de colección diferente por cada varibale y cabe destacar que en el caso de las colecciones podemos definir el tipo de dato que va a contener cada una de las variables, debes tener en cuenta que:

para list y set se utiliza el tipo de dato que va a contener entre corchetes [].
para tuple se define el tipo de dato y la posición dentro de la tupla entre corchetes [], es decir que en el ejemplo se espera que sea una tupla de tres elementos que estaran en el siguiente orden int, str, bool.
para dict se define el tipo de dato que va a contener la llave y el valor entre corchetes [], es decir que en el ejemplo se espera que sea un diccionario con llaves de tipo str y valores de tipo bool.

Combinación de Tipos en Python

En algunos casos, es necesario que las variables puedan contener más de un tipo de dato o incluso que puedan ser opcionales. Para ello se han definido diversas estrategias para alcanzar esta funcionalidad

Definir Más de un Tipo

Utiliza el carácter | para definir más de un tipo de dato en una variable, este carácter actúa como un OR lógico:

a: int | str = 1
b: int | str = "one"

Para versiones anteriores a Python 3.9, importa Union de typing:

from typing import Union

a: Union[int, str] = 1
b: Union[int, str] = "one"

Valores Opcionales o `None`

Para definir que un valor es opcional, añade None como parte de los tipos posibles:

a: int | None = 1
b: int | None = None

Para versiones anteriores a Python 3.9, utiliza Optional o Union:

# Opción 1
from typing import Optional

a: Optional[int] = 1

# Opción 2
from typing import Union

a: Union[int, None] = None

Definir Valores Fijos

Si deseas restringir los valores que puede tomar una variable, usa Literal de typing:

from typing import Literal

cards: Literal["clubs", "diamonds", "hearts", "spades"]
cards = "clubs"

Definir Tipos Personalizados

EN Python asi como con las variables es posible definir tipos personalizados, para simplificar la lectura del código o incluso para darle un mejor entendimiento al código. en la siguiente pieza de código podemos ver esta funcionalidad.

from typing import Literal

UserType = Literal["admin", "user"]
ID = int | str
PersonalData = dict[str, str | bool| float | None]

User = tuple[ID, PersonalData, UserType]
UserUgly = tuple[int | str, dict[str, str | bool| float | None], Literal["admin", "user"]]

Como podemos observa en el ejemplo anterior estamos separando nuestra definición de tipos en otros tipos para facilitar la lectura de nuestro código, en el caso de User y UserUgly estamos definiendo un tipo de dato que va a ser una tupla que va a contener un ID, PersonalData y UserType y en el caso de UserUgly estamos definiendo el mismo tipo de dato pero de una manera menos legible.

si escribieramos el mismo código para versiones anteriores a Python 3.9, el código se vería de la siguiente manera:

from typing import Literal, Union, Optional

UserType = Literal["admin", "user"]
ID = Union[int, str]
PersonalData = dict[str, Optional[str, bool, float]]

User = tuple[ID, PersonalData, UserType]

Datos IO en Python

Cuando trabajes con datos de entrada/salida, como la lectura de archivos, usa el tipo IO de typing:

from typing import IO

text_file: IO[str] # text, json, xml, html...
bin_file: IO[bytes] # jpeg, png, pdf, mp3...

El tipo IO es un tipo genérico que se utiliza para representar objetos que son streams de entrada o salida, como archivos y sockets, y solo admite tipos de datos str y bytes.

Info

En este artículo, hemos cubierto las nociones básicas sobre cómo agregar tipos a tus variables en Python. En el próximo artículo, exploraremos cómo agregar tipos a funciones y métodos.

GitHub Copilot: Beneficios, Desventajas y Precauciones

Dacadev — Mon, 27 May 2024 00:00:00 -0500

Tabla de Contenido

Note

Este artículo nace como una iniciativa para centralizar el conocimiento que he adquirido en el manejo de la herramienta de GitHub Copilot gracias a su uso diario, cursos y consejos que he encontrado en diversos recursos.

La herramienta la puedes encontrar en el siguiente enlace: GitHub Copilot

GitHub Copilot es una herramienta de inteligencia artificial que nos ofrece toda la potencia de los modelos de lenguaje a gran escala (LLM, por sus siglas en inglés) enfocada específicamente en el campo del desarrollo de software y programación. Es una herramienta que ha revolucionado la manera de escribir código y aún tiene mucho más por aportar. Veamos algunas de sus funcionalidades y beneficios, así como desventajas y riesgos de usar esta herramienta.

¿Qué es GitHub Copilot?

Mi definición de lo que es Copilot sería:

GitHub Copilot es una herramienta de programación de pair programming que extiende las habilidades de los desarrolladores permitiendo enfocarse en el diseño, delegando la “carpintería” al copiloto.

Adicionalmente, si queremos ser un poco más técnicos al respecto y definir qué es Copilot técnicamente, debemos decir que Copilot trabaja sobre las mismas bases de los LLMs como ChatGPT, con la salvedad de que fue afinado para que su enfoque sea 100% en la escritura de código.

Los datos usados para ajustar el modelo que alimenta a GitHub Copilot fueron todos los repositorios públicos que se encuentran en GitHub, siendo esta la plataforma más usada para alojar proyectos alrededor del mundo. Esto significa que el conjunto de datos de entrenamiento es inmenso y muy completo.

Por último, como Copilot está basado en la tecnología de los LLMs, en general lo que busca es predecir, a partir de probabilidades, cuál sería el código que seguiría a medida que vas escribiendo.

¿Debo preocuparme por el manejo de datos?

Una de las principales dudas al momento de usar Copilot, incluso podría pensar que la primera duda, es ¿Copilot usará mis datos y mi código para futuras sugerencias? o en palabras más simples ¿Copilot va a robar mi código?

La respuesta es un NO rotundo. Copilot no usará tu código o el código generado con la herramienta para reentrenar el modelo, ya que, como mencioné antes, esta herramienta solo es entrenada con datos públicos que se obtienen de los repositorios públicos de GitHub.

Además, el código generado a partir de Copilot no es alojado para realizar una futura realimentación del modelo, por lo que puedes estar seguro de la privacidad de tu código y de tu negocio a fin de cuentas.

Note

En este punto debo mencionar algo y es la propiedad intelectual. Puede que Copilot no respete la propiedad intelectual si esta es en un repositorio público, por lo que si quieres tener este tipo de protección y a la vez tener un código abierto, es mejor asesorarte.

¿Cuáles son los alcances de Copilot?

Como mencionamos antes, Copilot es tu compañero de programación en pareja, esto significa que te ayudará a escribir código brindando sugerencias durante la escritura del mismo, pero aquí puede surgir una pregunta muy importante: ¿Puede Copilot ayudarme sin importar el lenguaje?

La respuesta a esta pregunta es ambigua, sí y no. Es un sí porque recuerda que el modelo fue entrenado usando todo el código público alojado en GitHub, y entre estos encontramos una diversidad inmensa de lenguajes, frameworks, estilos, prácticas, etc. Sin embargo, también debemos tener en cuenta que los lenguajes más populares como JavaScript o Python son los que más proyectos tienen alojados en GitHub, lo que significa que el modelo aprendió más de estos lenguajes, haciéndolo mucho más eficiente para estos tipos de lenguajes o frameworks.

Si intentas utilizar Copilot con algún lenguaje que no es tan popular como COBOL, es posible que Copilot no haga un muy buen trabajo, pero lo intentará.

Tip

Si tienes miedo de que la IA te pueda arrebatar el trabajo, tiene sentido buscar aquello en lo que la IA no es realmente buena… ¿aún? Esto es solo una opinión que podría ser una buena discusión, ¿qué opinas?

¿Es acertado Copilot en sus predicciones?

Esta es una pregunta que muchas personas se hacen, sin importar el nivel de experiencia que tengan, y volviendo a retomar la idea de antes, sus predicciones mejorarán a medida que sea usado para escribir código de lenguajes o contextos populares, ya que tendrá más conocimiento de dónde echar mano.

Dado lo anterior, es MUY IMPORTANTE que tú, como desarrollador, supervises siempre el resultado de Copilot. No importa qué tan sencillo o simple sea, hazlo como una nueva práctica para el uso de esta herramienta ya que Copilot solo predice, no piensa realmente… ¿aún? 🤔

Aquí quiero hacer un énfasis que es mandatorio, y es el de la supervisión. Tu responsabilidad como programador es supervisar el resultado de Copilot, y esto se puede hacer eficientemente solamente si:

Conoces la tecnología, lenguaje, frameworks, etc. que Copilot te está ayudando a construir.
Entiendes lo que estás construyendo y el propósito, la lógica de negocio.
Entiendes a nivel macro el impacto de tu trabajo, Copilot te ayudará con lo micro.

Tip

Debes ser siempre consciente de lo que estás construyendo, siempre recuérdalo porque con el uso de Copilot es fácil caer en la tentación de dejar pasar algunas cosas.

Beneficios de usar Copilot

Hablemos ahora de cuáles son los beneficios de usar Copilot. ¡Hay muchos!

Incrementa la productividad, ya que no gastarás tiempo escribiendo y reescribiendo código, sobre todo si son piezas pequeñas pero tediosas.
Reduce los errores en el código, aunque debamos supervisar el resultado de Copilot, este siempre nos ayudará a reducir errores comunes como los typos o referencias mal realizadas.
Permite tener una gran diversidad de código, ya que puedes pedirle a Copilot que te dé no solo una, sino más sugerencias, permitiéndonos ahondar en múltiples estilos o diseños de código.
Soporta múltiples lenguajes, con mejor rendimiento en unos más que en otros.
Te permite aprender y desarrollar al mismo tiempo. Cuando Copilot te ayuda a escribir código, puede implementar técnicas o ideas nuevas para ti y te permitirá aprender de ellas. Para ello, debes ser consciente y supervisar el resultado, no confíes 100% en su respuesta. Valida en la documentación o en recursos de confianza.
Copilot se ajustará a tu tipo de código. A medida que lo uses, entenderá cuál es el estilo de código en base a lo ya escrito en el proyecto. Tú lo orientas en base a cómo escribas código. Esto significa que si cambias de proyecto y este tiene otras reglas, Copilot se adaptará. Él no aprende de ti.

Precauciones y desventajas de Copilot

Su precisión es variable dependiendo del contexto del prompt y del mismo código que tienes en ese archivo. Esto depende del tiempo de trabajo en el proyecto con Copilot, los archivos abiertos y el código de referencia.
Riesgos de seguridad potenciales. Debes supervisar el resultado, sobre todo si trabajas con partes sensibles del código como SQL, ORMs, código de lógica de negocio, etc. Valida el código que propone Copilot y, si no lo conocías, valida su uso en la documentación o un recurso de confianza.
Depender demasiado de la herramienta. Para que esto no suceda, debes conocer bien la tecnología, lenguaje y sistema que estás construyendo, para tener el criterio y confianza de que lo que estás haciendo lo podrías hacer sin ayuda de Copilot.
Una “desventaja” es que tiene un costo, no tiene opción de uso gratuito o similar, y es más costoso a medida que se implementa en organizaciones. Esto, en algunos casos como personas/empresas que están empezando, puede ser un valor difícil de asumir. Debes tener claro el valor que agrega en el equipo y ese gasto adicional incluirlo en tus cuentas.
Límite en el contexto de la herramienta. Esta es una desventaja de los LLMs en general y, aunque es algo que está en constante mejora, es muy difícil (por lo menos hasta ahora) incluir todo un proyecto en el contexto de un LLM y adicionalmente compartir qué es lo que se busca hacer. Por lo que para tareas muy grandes con un código fuente enorme, tiende a no ser tan preciso.

Conclusión

GitHub Copilot ha revolucionado la forma en que los desarrolladores escriben código, ofreciendo beneficios significativos como el aumento de la productividad y la reducción de errores. Sin embargo, es crucial supervisar sus sugerencias y estar consciente de sus limitaciones y riesgos. A medida que la tecnología avanza, Copilot seguirá mejorando, pero siempre será necesario el criterio humano para garantizar la calidad y la seguridad del código.

Info

Este artículo se actualiza periódicamente conforme evolucionan las funcionalidades de GitHub Copilot. Si tienes experiencias o consejos adicionales, no dudes en compartirlos a través de la página de contacto.

Aprovecha al Máximo go.work y go.mod en Golang

Dacadev — Fri, 24 May 2024 00:00:00 -0500

Tabla de Contenido

Note

En este artículo, aprenderás a usar los módulos de Golang, qué son y cómo usarlos. Además, complementaremos el uso de múltiples módulos en un proyecto con la ayuda de go.work.

¿Qué son los módulos de Golang?

Dentro del ecosistema de Golang para gestionar las dependencias de un proyecto, tenemos los módulos. Los módulos son una colección de paquetes de Golang que en conjunto forman una aplicación o librería. Entre los beneficios de los módulos de Golang se encuentran:

Especificar las dependencias y sus versiones.
Facilitar la descarga de las dependencias de un proyecto y compartirlas.
Gestionar las importaciones de paquetes que componen el módulo.
Actualizar y sincronizar las dependencias de un proyecto.

Los módulos en Golang se definen con el archivo go.mod en la raíz del proyecto y este archivo tiene la siguiente estructura:

module <nombre-del-modulo>

go <go-version>

require (
 <dependencia-1> <version>
 <dependencia-2> <version>
 ...
)

replace (
 <dependencia-1> => <ruta-local>
 <dependencia-2> => <nueva-dependencia> <version>
 ...
)

En la anterior estructura se identifican cuatro partes principales:

El nombre del módulo: Este puede tener cualquier nombre, sin embargo, es buena práctica definir un dominio en donde se alojará el módulo seguido de un path único.
Definir la versión de Go: Especifica la versión de Golang que se usará en el proyecto.
Las dependencias del proyecto: Se especifica el nombre de la dependencia y la versión que se usará. Esta sección no es obligatoria si el módulo no tiene dependencias.
Directiva replace: Permite reemplazar las dependencias del módulo por otras dependencias o rutas locales, lo cual veremos en profundidad más adelante.

Note

Podemos hacer la analogía del archivo go.mod con el archivo package.json de Node.js o el archivo requirements.txt de Python.

Junto con el archivo go.mod encontramos el archivo go.sum, el cual es un archivo autogenerado que no debes modificar manualmente. Este archivo contiene el listado de todos los paquetes de dependencias del módulo y sus respectivas versiones, sirviendo como referencia para verificar que las dependencias del módulo no hayan sido modificadas.

¿Cómo interactuar con los módulos de Golang?

Aunque podemos crear nuestros módulos manualmente creando el archivo go.mod y definiendo las dependencias, Golang nos provee de una serie de comandos para interactuar con los módulos. Los más importantes son:

go mod init <module-name> ➔ Inicializa un módulo de Golang en el directorio actual, recibe como parámetro el nombre del módulo y creará el archivo go.mod.
go mod get <package-name> ➔ Descarga un paquete de dependencia del módulo y lo registra dentro del archivo go.mod. Adicionalmente, puedes actualizar un paquete del módulo usando la bandera -u, con el comando go get -u <package-name>.
go mod tidy ➔ Sincroniza el estado actual del módulo en el archivo go.mod, eliminando las dependencias que no se estén usando y agregando las que faltan pero que sí se están usando.
go mod verify ➔ Verifica que las dependencias del módulo descargadas no hayan tenido modificaciones y estén sincronizadas con el archivo go.sum.

Note

Un comando que no forma parte de go mod pero que es muy útil es go list -m all, el cual lista todas las dependencias del módulo y sus respectivas versiones.

¿Qué es Go Workspace?

Hasta este punto, hemos visto qué son y cómo se usan los módulos, pero hay una característica adicional asociada al contexto de los módulos. Cuando trabajamos en un módulo dentro de nuestro editor de código, Go tiene como contexto el directorio del módulo. El problema surge cuando queremos trabajar con varios módulos al mismo tiempo, ya que Go no sabría identificar en qué módulo estamos trabajando.

Este era un problema común en el desarrollo, ya que muchas veces se tenían módulos que dependían de otros módulos también desarrollados por el mismo equipo. En estos casos, si necesitabas probar cambios de un módulo en otro, tenías que actualizar la dependencia en cuestión y posteriormente actualizarla en el módulo que la usará, haciendo tedioso el proceso de desarrollo.

Normalmente, para solucionar esto, el desarrollador tenía que configurar manualmente las dependencias que estaba probando para que estas apuntaran a otro módulo o una ruta dentro de su máquina local. Esto se hace con la directiva replace que mencionamos antes. Este proceso se hacía manualmente y debías estar pendiente de actualizar y revertir los cambios antes de actualizar el paquete en el repositorio.

Dado todos estos inconvenientes, se agregó go.work al ecosistema. La principal funcionalidad de los Go Workspaces es facilitar la gestión de los módulos en un mismo editor o contexto. Entre las ventajas de usar Go Work encontramos:

Permite trabajar con múltiples módulos en un mismo editor.
Puedes unificar el desarrollo de aplicaciones de Go que se componen de múltiples módulos en un mismo repositorio o ruta de trabajo.
Mejora el flujo de desarrollo.

Su uso es muy similar a lo que ya vimos para go.mod.

Note

go.work se agregó en la versión 1.18 de Go, por lo que si estás usando una versión anterior a esta, no podrás usar go.work.

¿Cómo usar go.work?

Lo primero que debemos hacer es crear el archivo go.work en la raíz del proyecto. Este archivo tiene la siguiente estructura:

go <go-version>

use (
 ./<module-path>
)

Dentro de la estructura encontramos dos partes principales:

La versión de Go: Especifica la versión de Golang que se usará en el proyecto.
Directiva use: Especifica la ruta del módulo que se usará en el proyecto.

Aunque podemos crear el archivo manualmente, lo recomendable es hacerlo a través de los comandos de Go que están definidos para los Workspaces. Al igual que los módulos de Go, Go Work tiene una serie de comandos que nos permiten interactuar con los Workspaces. Los más importantes son:

go work init ➔ Inicializa un Workspace de Golang en el directorio actual, creando el archivo go.work en la raíz del directorio.
go work use <module-path> ➔ Agrega un módulo al Workspace. Este módulo debe estar ya creado dentro del folder <module-path>, lo que significa que debe de tener definido el archivo go.mod.
go work sync ➔ Sincroniza los módulos del Workspace. Este comando descarga las dependencias de los módulos que están definidos dentro del Workspace.

Note

Si estás trabajando con un Workspace y un módulo que no está definido en el Workspace, Go no sabrá en qué módulo estás trabajando y te lanzará un error.

Con estos comandos, podrás interactuar con los módulos de Golang y el mismo Workspace será el encargado de resolver las dependencias sin necesidad de realizar configuraciones adicionales. Para explicar mejor qué significa esto, supongamos que tenemos el siguiente sistema de archivos:

proyecto/
├── go.work
├── modulo1/
└── modulo2/

Podríamos ejecutar comandos Go directamente dentro del módulo de la siguiente manera:

go test ./modulo1
go build ./modulo2

Todo desde la raíz del Workspace. Si no usáramos Workspace, tendríamos que abrir cada módulo en un nuevo editor o realizar las configuraciones pertinentes para que Go entienda qué módulo estamos trabajando.

Info

Este artículo se basa en mi experiencia como desarrollador y en la documentación que podemos encontrar en:

Colecciones en Python: namedtuple()

Dacadev — Tue, 14 May 2024 00:00:00 -0500

Tabla de Contenido

Note

En este artículo, conocerás la función namedtuple del módulo collections de la biblioteca estándar de Python.

¿Qué es `namedtuple()`?

namedtuple() es una función que retorna una nueva clase, la cual permite acceder a los valores de una tupla tanto por índice como a través de un nombre definido al crear la tupla.

Primero, examinaremos la firma de la función para entender cómo funciona y, posteriormente, analizaremos por qué y cuándo es beneficioso usarla.

def namedtuple(typename, field_names, *, rename=False, defaults=None, module=None):

Esta firma revela cinco argumentos importantes:

typename: el nombre que se asignará a la nueva clase creada.
field_names: ya sea un string o un iterable de strings que representan los nombres de los campos de la tupla. El orden de estos strings determina cómo se accederán los valores.
rename: un valor booleano que, si se activa, permite que la función reemplace nombres duplicados o conflictivos automáticamente.
defaults: permite definir valores predeterminados para los campos de la tupla, asignando valores desde el final hacia el inicio de la lista de campos.
module: un string que asocia la nueva tupla a un módulo específico.

Note

Los argumentos definidos después de * son argumentos que deben pasarse como keyword arguments (es decir, como nombre=valor), no de manera posicional.

Ejemplos de uso

Crear una `namedtuple`

Primero, veamos cómo crear una nueva tupla sencilla:

from collections import namedtuple

Coordinates = namedtuple("Coordinates", ["x", "y", "z"])

point_1 = Coordinates(1, 2, 3)
print(point_1)
print('x:', point_1.x, 'y:', point_1.y, 'z:', point_1.z)
print('x:', point_1[0], 'y:', point_1[1], 'z:', point_1[2])

El resultado de este código será:

$ python main.py
Coordinates(x=1, y=2, z=3)
x: 1 y: 2 z: 3
x: 1 y: 2 z: 3

Como observamos, creamos una nueva clase llamada Coordinates con campos x, y, y z. Luego instanciamos point_1 y accedimos a sus valores tanto por nombre como por índice.

Note

Al declarar point_1, los valores se asignan en el mismo orden en que se especifican en la tupla: primero x, después y, y finalmente z.

Crear una `namedtuple` con valores por defecto

Definiendo valores por defecto, que deben ser iterables, podemos especificar los valores que se asignarán a los campos si no se proporcionan al crear la instancia:

from collections import namedtuple

UserData = namedtuple(
 "UserData",
 ["name", "age", "email", "country"],
 defaults=("example@mail.com", "CO")
)

david = UserData( "David", 28, )
juan = UserData("Juan", 24, "juan@mail.com")

print(david)
print(juan)

El resultado de este código será:

UserData(name='David', age=28, email='example@mail.com', country='CO')
UserData(name='Juan', age=24, email='juan@mail.com', country='CO')

Los valores por defecto se asignan de derecha a izquierda a los campos que no tienen valores asignados al crear la instancia.

Pero debemos de tener en cuenta que si no pasamos todos los argumentos que no están definidos por defecto, la función lanzará un error.

unknown = UserData()
print(unknown)

Traceback (most recent call last):
 File "/home/dacacode/dacadev/personal-blog/tempCodeRunnerFile.python", line 9, in <module>
 unknown = UserData()
 ^^^^^^^^^^
TypeError: UserData.__new__() missing 2 required positional arguments: 'name' and 'age'

Controlar el renombramiento de los campos

Activando el argumento rename como True, la función automáticamente renombra campos duplicados o que sean palabras reservadas del lenguaje. Primero vamos a crear una tupla normal con nombres de campos que pueden entrar en conflicto.

from collections import namedtuple

dynamic_fields = ['name', 'def', 'arg', 'name']
EspecialInfo = namedtuple("EspecialInfo", dynamic_fields)

print(EspecialInfo)

Al ejecutar el código vas a obtener un error como el siguiente:

Traceback (most recent call last):
 File "/home/dacacode/dacadev/personal-blog/tempCodeRunnerFile.python", line 4, in <module>
 EspecialInfo = namedtuple("EspecialInfo", dynamic_fields)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 File "/home/dacacode/.pyenv/versions/3.11.5/lib/python3.11/collections/__init__.py", line 398, in namedtuple
 raise ValueError('Type names and field names cannot be a '..)
ValueError: Type names and field names cannot be a keyword: 'def'

Pero si habilitamos la opcion de rename el código funcionará, ya que la función se encarga de procesar esos casos.

from collections import namedtuple

dynamic_fields = ['name', 'def', 'arg', 'name']
EspecialInfoV2 = namedtuple("EspecialInfoV2", dynamic_fields, rename=True)

print(EspecialInfoV2)
data = EspecialInfoV2('David', 'print', 'Hello, World!', 'David')
print(data)

Ahora si obtendremos un resultado positivo:

<class '__main__.EspecialInfoV2'>
EspecialInfoV2(name='David', _1='print', arg='Hello, World!', _3='David')

En donde podemos ver que los atributos que son keywords y duplicados han sido renombrados por valores posicionales, en este caso _1 y _3.

Las `namedtuples` son Clases

Por último, pero no menos importante, recuerda que el resultado de la función namedtuple es una clase que hereda de tuple, lo que significa que podemos usarla como cualquier otra clase. Por ejemplo, podemos usar la nueva clase como padre de otra para extender su funcionalidad:

from collections import namedtuple

Coordinates = namedtuple("Coordinates", ["x", "y", "z"])

class Point(Coordinates):

 def __add__(self, other):
 return Point(self.x + other.x, self.y + other.y, self.z + other.z)

point_1 = Point(1, 2, 3)
point_2 = Point(4, 5, 6)

print(point_1)
print(point_2)
print(point_1 + point_2)

El resultado de este código será:

Point(x=1, y=2, z=3)
Point(x=4, y=5, z=6)
Point(x=5, y=7, z=9)

¿Por qué usar `namedtuples`?

Una de las principales razones para usar las namedtuple es la mejora de la legibilidad del código, ya que al momento los atributos para acceder a sus elementos es más fácil de entender que si lo hacemos por índice.

from collections import namedtuple

UserInfo = namedtuple('UserInfo', ['name', 'age', 'email'])

# Mejora la legibilidad
user = UserInfo('David', 28, 'mail@mail.com')

user.name # David
user.age # 30
user.email # mail@mail.com

# Debes tener en tu mente el orden de los campos, no es lo ideal!
userRaw = {'David', 28, 'mail@mail.com'}
user[0] # David
user[1] # 30
user[2] # mail@mail.com

Otros beneficios que encontramos es en la eficiencia del código, ya que al utilizar tuplas (o nametuples) encontramos que:

Las tuplas tienen mayor rendimiento al momento de ser creadas, debido a que son objetos inmutables y su alocación en memoria es mucho ams eficiente que las clasicas lsitas o diccionarios.
Son ideales para procesar información que debe mantenerse constante durante todo su tiempo de vida, ya que las tuplas son inmutables.
El tiempo de acceso a los elementos de la tupla es más rápido que las listas o los diccionarios.

Note

Esto no significa que las tuplas sean mejores que otras estructuras de datos, esto depende de cada caso en particular y debes analizarlo antes de tomar una decisión.

Info

Para más información sobre namedtuple, visita la documentación oficial en este enlace

RP Pico: Interrupciones de GPIO

Dacadev — Sun, 28 Apr 2024 21:18:46 +0000

Tabla de Contenido

Note

En este artículo aprenderás a manejar las interrupciones GPIO de la Raspberry Pi Pico usando MicroPython. Al final entenderás cómo configurarlas y qué tener en cuenta al diseñar el comportamiento de las interrupciones.

¿Qué son las interrupciones?

Las interrupciones son acciones, normalmente una serie de tareas que se ejecutan cuando cierta condición o evento se genera durante la ejecución del programa. Haciendo que el programa se detenga en ese punto y proceda a ejecutar las acciones que se han definido para ese evento.

Manejo de interrupciones en el RP2040

Antes de configurar el código para nuestra RP2040, es importante entender cómo maneja las interrupciones. Cada núcleo está equipado con un controlador de interrupciones propio, conocido como Controlador de Interrupciones Vectorizadas Anidadas (o NVIC por sus siglas en inglés, Nested Vectored Interrupt Controller). Cada NVIC puede gestionar 32 tipos de interrupciones. Esto proporciona al RP2040 flexibilidad para manejar múltiples interrupciones de manera eficiente, permitiendo que cada núcleo responda de forma independiente a los eventos de interrupción específicos. En relación con los GPIO, cada controlador de interrupciones gestiona una única interrupción de GPIO por banco, y no una interrupción por cada pin, lo que significa que las interrupciones por pines dentro de un mismo banco son compartidas entre los pines del mismo.

Note

Para más información de como se manejan las interrupciones en el RP2040, puedes revisar la sección 2.3.2 del datasheet

Interrupciones con Micropython

Info

A partir de este punto es necesario que el usuario tenga entendimiento de como operan la clase Pin en Micropython, si ese no es el caso en el siguiente artículo te explico más del tema.

Para configurar las interrupciones en Micropython debemos de tener una instancia de la clase Pin que encontramos en la librería machine. Una vez tengas la instancia de Pin el siguiente paso es asociar una interrupción al mismo, para ello haremos uso del método irq.

Este método tiene las siguientes configuraciones:

parámetro	valor por defecto	descripción
handler	`None`	Es la función que se ejecutará cuando se dispare la interrupción, esta función secibe como parámetro una instancia del `Pin` que lo activo, si el valor es `None` la interrupción esta desactivada
trigger	`IRQ_FALLING \| Pin.IRQ_RISING`	Es el comportamiento que se tendrá encuenta para activar la interrupción, mirá el gráfico mas adelante, es posible mezclar mas de un tipo de activador
priority	`1`	Es el nivel de prioridad que le asignarás a la interrupción, entre mayor el numero, mayor prioridad
wake	`None`	Te permite controlar si la interrupción tiene la capacidad de “despertar” al procesador si esta en estado de reposo/suspención
hard	`False`	Este parámetro permite definir si la interrupción será manejada por hardware o no, esto permite disminuir el delay entre la activación y la ejecución de la función de la interrupción, sin embargo tiene implicación de performance que debe considerar el desarrollador y no Micropython

Veamos un ejemplo de como se crean interrupción con Micropython:

from machine import Pin
from utime import sleep

# setup
led = Pin(25, Pin.OUT, value=False)
btn = Pin(1, Pin.IN)

# Función para manejar la interrupción
# recibe solo un parámetro de tipo Pin
def interrupt_callback(pin):
 print(pin)
 led.toggle()


btn.irq(handler=interrupt_callback, trigger=Pin.IRQ_FALLING)

Tipo de activadores de interrupciones

Micropython define los siguientes activadores de interrupciones:

Pin.IRQ_FALLING interrupción en flanco de bajada (falling edge)
Pin.IRQ_RISING interrupción en flanco de subida (rising edge)
Pin.IRQ_LOW_LEVEL interrupción en nivel bajo (low level)
Pin.IRQ_HIGH_LEVEL interrupción en nivel alto (high level)

Recuerda que una señal digital oscila entre 1 y 0, lo cual podemos ver en el tiempo como una señal cuadrada, y en base a ella es que se tienen definidas los activadores de interrupciones, como se muestra en el siguiente gráfico.

Despliegue su sitio en GitHub Pages con HUGO y dominio personalizado

Dacadev — Mon, 18 Dec 2023 20:56:15 +0000

Tabla de Contenido

Note

En este tutorial aprenderás a desplegar un sitio web creado con Hugo en GitHub Pages en menos de 10 minutos, automatizar el despliegue con GitHub Actions y configurar un dominio personalizado.

HUGO es un generador de sitios estáticos creado en Go, que cuenta con un rendimiento excelente y varias funcionalidades que permiten crear sitios web de manera amigable tanto para desarrolladores como para creadores de contenido.

Para saber más de la herramienta, puedes remitirte a la documentación en el siguiente link

Para desplegar tu sitio web creado con HUGO, dispones de muchas herramientas, tanto pagas como gratuitas, que te pueden ayudar en este proceso. En este post, vamos a ver cómo podemos desplegar rápidamente nuestro sitio en GitHub Pages en menos de 10 minutos y actualizar el dominio a uno personalizado.

GitHub Pages es un servicio que ofrece GitHub para los repositorios públicos o para aquellos usuarios que cuentan con una suscripción pro, sean usuarios personales o empresariales.

Despliegue paso a paso del sitio en GitHub Pages

Debes tener un proyecto de HUGO funcional y alojarlo en un repositorio público en GitHub.

Si quieres que el repositorio sea privado y aún así desplegar tu sitio, es importante contar con la cuenta Pro.

En la imagen de referencia, estoy usando la página especial de GitHub Pages que coincide con mi nombre de usuario, dacadev-official. Esto significa que cuando despliegue mi sitio, lo harán en la raíz del dominio de mi cuenta, que sería https://dacadev-official.github.io. Si el nombre fuera diferente, la URL sería https://dacadev-official.github.io/<my-repo-name>. Es importante tener esto en cuenta ya que si en HUGO estamos usando Permalinks o relURL sin tener configurado debidamente nuestro baseurl, podría generar problemas en los enlaces.

Dentro de nuestro repositorio, nos dirigiremos a la sección de settings > pages y activaremos la opción de build and deploy con GitHub Actions.
El siguiente paso consiste en activar las GitHub Actions. Para ello, debemos crear un archivo dentro del folder .github/workflows.

Las GitHub Actions son una herramienta de automatización integrada en GitHub, que permite ejecutar flujos de trabajo basados en eventos dentro de un repositorio.

Crearemos el archivo hugo.yaml dentro del folder mencionado. Puede ser cualquier nombre, pero lo importante es que sea un nombre relacionado o descriptivo de lo que hará. Dentro de este archivo, colocaremos el siguiente contenido.

 # Nombre de la acción
name: Deploy Hugo site to Pages

# Se activara cuando se haga un push sobre la rama main
on:
 push:
 branches:
 - main

# Permisos para que pueda leer el contenido del repo y
# pueda escribir sobre la funcionalidad de GitHub Pages
permissions:
 contents: read
 pages: write
 id-token: write

# Estara asociado al grupo relacionados con pages y no cancelará
# otros procesos que esten en ejecución
concurrency:
 group: "pages"
 cancel-in-progress: false

# Define bash como el encargado de ejecutar los trabajos
defaults:
 run:
 shell: bash

# En este apartado define el entorno usado para el workflow
jobs:
	# 1 TRABAJO DE CONSTRUCCIÓN DEL SITIO
 build:
 # Entorno
 runs-on: ubuntu-latest
 env:
			# Esta variable permite cambiar facilmente la version de HUGO usada
 HUGO_VERSION: 0.121.1
 steps:
 - name: Install Hugo CLI
 run: |
 wget -O ${{ runner.temp }}/hugo.deb https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_linux-amd64.deb \
 && sudo dpkg -i ${{ runner.temp }}/hugo.deb
 - name: Install Dart Sass
 run: sudo snap install dart-sass
				# Prepara el entorno para desplegar las páginas
 - name: Checkout
 uses: actions/checkout@v4
 with:
 submodules: recursive
 fetch-depth: 0
 - name: Setup Pages
 id: pages
 uses: actions/configure-pages@v4
 - name: Install Node.js dependencies
 run: "yarn install"
				# Configura las variables de entorno de HUGO y procede a
				# ejecutar el comando para construir el sitio.
 - name: Build with Hugo
 env:
 HUGO_ENVIRONMENT: production
 HUGO_ENV: production
 run: |
 hugo \
 --gc \
 --minify \
 --baseURL "${{ steps.pages.outputs.base_url }}/"
	 # Sube el contenido generado por hugo al directorio de GitHub Pages
			- name: Upload artifact
 uses: actions/upload-pages-artifact@v2
 with:
 path: ./public

 # 2 REDESPLIEGA EL SITIO EN GITHUB PAGES CON LOS NUEVOS CAMBIOS
 deploy:
 environment:
 name: github-pages
 url: ${{ steps.deployment.outputs.page_url }}
 runs-on: ubuntu-latest
 needs: build
 steps:
 - name: Deploy to GitHub Pages
 id: deployment
 uses: actions/deploy-pages@v3

El siguiente paso es hacer commit con el nuevo archivo agregado, con un mensaje descriptivo, y finalmente hacer push de los cambios a la rama main o la que hayas definido en el archivo .yaml de configuración.

git commit -m “feat: implement github actions to deploy site into GitHub Pages” git push origin main

Nos dirigiremos a la página de nuestro repositorio y veremos que GitHub ha detectado automáticamente nuestros cambios con las acciones y las ejecutará. Verás algo similar a la siguiente imagen. Una vez que se completen los workflows correctamente, debes dirigirte a la URL del repositorio, que sería https://<username>.github.io/<repository>. Recuerda que si tu repositorio tiene el mismo nombre que tu usuario, puedes omitir el <repository>.

En caso de que se genere un error o algo similar debes de revisar los logs de cada paso que enontrarás en el link de details al lado de cada uno de los pasos

Configura un dominio personalizado en GitHub Pages

Hasta este punto, hemos configurado y desplegado exitosamente nuestro sitio en GitHub Pages. Ahora, lo que nos falta es configurar nuestro nombre de dominio para que tenga un nombre de nuestra marca o necesidad en cuestión.

En este ejemplo, hemos usado un dominio adquirido en Namecheap que tenemos listo para configurar.

Lo primero que haremos es configurar nuestro dominio dentro de nuestro repositorio. Para ello, nos dirigiremos a settings > pages de nuevo y buscaremos la opción de Custom Domain.
Dentro del input, agregamos el dominio que queremos agregar.
El siguiente paso será configurar las direcciones IP a las cuales queremos que apunte nuestro dominio. Para ello, nos dirigiremos al panel de control de Namecheap e iremos a las opciones avanzadas de nuestro dominio. Las URL listadas son las siguientes:
- 185.199.108.153
- 185.199.109.153
- 185.199.110.153
- 185.199.111.153

Lo que estamos configurando es lo siguiente:

Registros A con la dirección @, que representa la raíz del dominio, apuntando a cuatro direcciones IP diferentes. Son necesarios para que tu dominio personalizado apunte a los servidores de GitHub Pages. Esto permite que cuando alguien ingrese tu dominio en su navegador, la solicitud sea dirigida a los servidores de GitHub, donde está alojado tu proyecto.
Registro CNAME con el host www y el valor <username>.github.io., redirige las solicitudes de www.tudominio.com al subdominio <username>.github.io en GitHub. Esto es útil si quieres que tanto www.tudominio.com como tudominio.com muestren tu proyecto en GitHub Pages.

Ya con esto, tu sitio estaría listo para servir a través de tu dominio personalizado.

Tip

Debes esperar un tiempo para que GitHub confirme que el dominio ingresado está configurado correctamente. Normalmente esto puede tomar entre unos minutos hasta 24 horas dependiendo de la propagación DNS.