DEV Community: 404Room

El operador Spread y Rest en Javascript

404Room — Fri, 02 Oct 2026 05:51:11 +0000

Tanto Spread como Rest son dos de las mejoras que han revolucionado la manera en como trabajamos con Javascript.

En este artículo veremos algunos de los usos más comunes de estos operadores.

El operador Spread

Piensa en el operador Spread como un unidad militar que despliega a sus elementos sobre un objetivo de manera coordinada siguiendo un protocolo.

En este sentido, Spread toma una estructura de datos Iterable y despliega a cada uno de los elementos de forma coordinada para que ocupen un lugar dentro de una estructura de datos objetivo.

Manipulación de arreglos.

Podemos crear un arreglo a partir de otros:

const initialSequence = [ 1, 2, 3 ];
const finalSequence = [ 8, 9, 10 ];
const currentSequence = [ ...initialSequence, 4, 5, 6, 7, ...finalSequence];

// [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 ]
console.log(currentSequence);

Fusionar o concatenar 2 arreglos entre sí:

const cold = [ 'autumn', 'winter' ];
const warm = [ 'spring', 'summer' ];
const seasons = [ ...warm, ...cold ];

// [ 'autumn', 'winter', 'spring', 'summer' ]
console.log(seasons);

Clonar un arreglo a partir de otro:

const words = [ 'have', 'a', 'good', 'day' ];
const greetings = [ ...words ];

// [ 'have', 'a', 'good', 'day' ]
console.log(greetings);

Manipulación de objetos.

Podemos clonar un objeto a partir de otro:

const dollyTheSheep = { species: 'Finnish Dorset', sex: 'Female' };
const dollysClone = { ...dollyTheSheep };

// { species: 'Finnish Dorset', sex: 'Female' }
console.log(dollysClone);

Fusionar 2 objetos entre sí para crear uno nuevo:

const user = { name: 'Javi' };
const roleAdmin = { role: 'admin' };
const adminUser = { ...user, ...roleAdmin };

// { name: 'Javi', role: 'admin' }
console.log(adminUser);

En otro artículo abordaremos las diferentes maneras en que podemos clonar un objeto en Javascript.

Mejora la invocación de una función.

En este caso, Spread nos permite rellenar los argumentos de una función de forma automática al momento de su invocación:

// Ejemplo 1: 
const numbers = [ 2, 1, 3, 100, 5, 4 ];
const minNumber = Math.min(...numbers);
const maxNumber = Math.max(...numbers);

// Ejemplo 2: 
const cold = [ 'autumn', 'winter' ];
const warm = [ 'spring', 'summer' ];
const seasons = cold.push(...warm);

// Ejemplo 3:
const firstBitcoinTransactionDate = new Date(...[2009, 0, 9]);

Definitivamente es una manera más rápida y limpia de pasar argumentos a una función.

El operador Rest

La sintaxis del operador Rest es la misma que la del operador Spread, sin embargo, su significado es diferente debido al contexto donde se utiliza.

Asignar el resto de un arreglo u objeto a una variable

Esto tiene que ver durante el proceso de desestructuración. Básicamente el operador Rest ordena el despliegue de solamente algunos de sus elementos sobre el objetivo, mientras que al resto los mantiene dentro de la unidad.

Esto se puede entender mejor mediante un ejemplo:

const [ autumn, winter, ...restOfTheSeasons] = ['autumn', 'winter', 'spring', 'summer'];

// autumn
console.log(autumn);

// winter
console.log(winter);

// [ 'spring', 'summer' ]
console.log(restOfTheSeasons);

Esto funciona de igual manera sobre un objeto:

const box = { color: '#2080A3', width: 500, height: 500 };
const { color, ...size } = box;

// #2080A3
console.log(color);

// { width: 500, height: 500 }
console.log(size);

Asignar un número variable de argumentos a una función

Esto tiene que ver durante la fase de diseño de una función. En este caso podríamos decir que Rest ordena la retirada reuniendo a todos sus elementos en un simple arreglo.

Esto se puede entender mejor con un ejemplo:

function countArguments(...args) {
  console.log(args);

  return args.length;
}

// [ 1, 2, 3, 4, 5 ]
countArguments(1, 2, 3, 4, 5);

Ten en cuenta que solo se permite una declaración de este operador por función.

Si nuestra intención es compartir este operador con otros argumentos en la definición de la función, asegurate que se encuentre ubicado hasta el final:

function filter(type, ...items) {
  return items.filter(item => typeof item == type);
}

// [ true, false, true ]
filter('boolean', true, 0, 1, false, true);

// [ 3, 1, 43, 37 ]
filter('number', 3, '3', 1, 43, true, false, 37);

Tanto el operador Spread como Rest son artefactos que todo desarrollador Javascript debería tener en su cajita de herramientas.

Si te interesa seguir aprendiendo sobre desarrollo web, ciberseguridad y tecnología, te invito a visitar mi blog personal, donde comparto lo que voy aprendiendo y construyendo en el camino.

Entendiendo la desestructuración en Javascript

404Room — Sat, 19 Sep 2026 19:22:42 +0000

La desestructuración es simplemente tomar una estructura de información y “romperla” de tal manera que podamos hacer uso de cada pieza de forma individual.

Si buscamos una analogía sencilla, la desestructuración es el equivalente a “desempacar” ciertos artículos personales de nuestra mochila de viaje.

En este sentido, nuestra mochila toma la forma de un arreglo, objeto, cadena de caracteres o cualquier tipo de estructura que posea un comportamiento Iterable (en otra oportunidad hablaremos sobre Iterators e Iterables en Javascript).

Por otro lado, nuestros artículos personales son las piezas de información individual que vamos a consumir.

Teniendo esto en mente te preguntarás, ¿qué podemos hacer con estas pequeñas piezas de información individual?, pues podemos por ejemplo asignarlas a variables de una forma más eficiente:

const numbers = [ 1, 2, 3 ];

// En lugar de realizar esto: 
let x = numbers[0];
let y = numbers[1];
let z = numbers[2];

// Simplemente podemos hacer esto: 
let [ x, y, z ] = numbers; 

console.log(x); // 1
console.log(y); // 2
console.log(z); // 3

Incluso durante el proceso de asignación podemos excluir aquellos valores que no son de nuestro interés:

const numbers = [ 1, 2, 3 ];

// x = 1, z = 3
let [ x, , z ] = numbers; 

// y = 2, z = 3
let [ , y, z ] = numbers;

// x = 1, y = 2, z = 3, a = undefined
let [ x, y, z, a ] = numbers;

O crear nuevas variables:

const numbers = [ 1, 2, 3 ];

// x = 1, y = 2, z = 3, a = 4
let [ x, y, z, a = 4 ] = numbers;

Sin mencionar que también seremos capaces de desempacar información anidada de nuestra “mochila”:

const alphanumericSequence = [ 'a', 'b', 'c', [1, 2, 3] ];

// numericSequence = [ 1, 2, 3 ]
let [ , , , numericSequence ] = alphanumericSequence; 

// x = 1, y = 2, z = 3
let [ , , , [ x, y, z ] ] = alphanumericSequence;

Un uso interesante es poder realizar un intercambio (swap) de valores entre 2 variables sin la necesidad de crear una variable temporal:

let a = 1;
let b = 2; 

// En lugar de hacer esto: 
let temp = a; 
a = b; 
b = temp; 

// Simplemente podemos hacer esto: 
[ a, b ] = [ b, a ];

console.log(a); // 2
console.log(b); // 1

Hasta ahora, nuestra mochila de viaje se ha comportado como un humilde arreglo, veamos qué ocurre cuando toma la forma de un objeto.

Desestructuración sobre objetos.

En este caso, la manera en que vamos a desempacar nuestros artículos personales de nuestra mochila de viaje es ligeramente diferente.

La regla de oro a tener en mente es que, el nombre otorgado a las variables que van a recibir los valores producto de la desestructuración deben coincidir con el nombre de las propiedades del objeto que estamos manipulando.

Como siempre, un fragmento de código habla mejor que 1000 palabras:

const employee = {
  name: 'Julia',
  age: 27,
  job: {},
  workSchedule: {}
};

// El nombre de las variables coincide con el nombre
// de las propiedades del objeto. 
let { name, age, job, workSchedule } = employee;

Claramente el nombre de cada variable definida coincide con el nombre de cada propiedad del objeto.

Si por el contrario, el nombre otorgado a nuestras variables no es de nuestro agrado, siempre podemos utilizar un alias:

let {
  name:employeeName,
  age:employeeAge,
  job:employeeJob,
  workSchedule:employeeWorkSchedule
} = employee;

Incluso podemos inicializar nuestras variables durante la fase de desestructuración:

let {
  name = 'john',
  age = 18,
  job = 'worker',
  workSchedule = null
} = employee;

// Incluso utilizar un alias durante este proceso:
let {
  name:employeeName = 'john',
  age:employeeAge = 18,
  job:employeeJob = 'worker',
  workSchedule:employeeWorkSchedule = null
} = employee;

Y por supuesto, no puede faltar la habilidad de trabajar con estructuras anidadas:

const employee = {
  name: 'Julia',
  age: 27,
  job: {},
  workSchedule: {
    mon: {
      open: 12, 
      close: 22,
    },
    tue: {
      open: 11,
      close: 23,
    },
    wed: {
      open: 23,
      close: 5,
    }
  }
};

let { workSchedule: { mon, tue, wed } } = employee;

console.log(mon); // { open: 12, close: 22 }
console.log(tue); // { open: 11, close: 23 }
console.log(wed); // { open: 23, close: 5 }

Aunque con este último punto hay que ser conservadores. Desestructurar información a través de múltiples niveles de anidación reduce la legibilidad de nuestro código:

const employee = {
  name: 'Julia',
  age: 27, 
  workSchedule: {
    mon: {
      open: {
        from: 12
      },
      close: {
        to: 22
      }
    }
  }
};

// Multiples niveles de anidación
let { workSchedule: { mon: { open: {from}, close: {to} } } } = employee;

console.log(from); // 12
console.log(to);   // 22

Un uso interesante de la desestructuración de objetos ocurre cuando trabajamos con funciones:

const dispatchDelivery = (endpoint, { userId, time = '00:00', address, items = [] }) => {
  // Some action...
};

dispatchDelivery('api/dispatch-delivery', {
  userId: 3392,
  address: 'Villas del Sol',
  time: '22:30',
  items: [ 'Beers', 'Sodas', 'Doritos' ]
});

dispatchDelivery('api/dispatch-delivery', {
  userId: 5423,
  address: 'Villas del Sol'
});

El resultado es una función con una definición más rica, legible y expresiva, sin duda una herramienta útil en funciones que requieren de múltiples parámetros.

La desestructuración de información es sin duda un mecanismo poderoso y muy utilizado en el mundo de Javascript, pero lo es aún más si lo combinamos de la mano con el operador Spread, ciertamente se pueden crear patrones de desarrollo interesantes.

Por último, ten en cuenta que la desestructuración se encuentra disponible solamente en las versiones modernas de Javascript, siendo concretos, a partir de la versión 6 del lenguaje.

Si te interesa seguir aprendiendo sobre desarrollo web, ciberseguridad y tecnología, te invito a visitar mi blog personal, donde comparto lo que voy aprendiendo y construyendo en el camino.

Javascript - Tipos Primitivos vs Tipos por Referencia

404Room — Wed, 16 Sep 2026 03:25:19 +0000

Al hablar sobre manejo de memoria, existen 2 tipos de datos con los cuales vamos a estar trabajando la mayoría del tiempo en Javascript: Tipos Primitivos y Tipos por Referencia.

Los Tipos Primitivos son los bien conocidos: Number, String, Boolean, Null y Undefined, además de los nuevos integrantes recién llegados en las nuevas versiones de Javascript: Symbol y BigInt.

Los Tipos por Referencia básicamente son todo aquello que no es un Tipo Primitivo, ejemplo: Funciones, Objetos, Arreglos, etc.

Para entender mejor la diferencia entre ellos, analicemos su comportamiento desde el punto de vista del motor de Javascript.

De todo esto, lo único que debemos entender es que un valor de Tipo Primitivo es almacenado en el Call Stack, en específico, dentro el contexto de ejecución (función) donde es definido, mientras que un Tipo por Referencia es almacenado en el Heap.

Tipos Primitivos

Al momento de declarar una variable y asignarle un valor de tipo primitivo, básicamente ocurre lo siguiente:

Se crea un identificador con el nombre que se le asignó a la variable.
Se prepara una porción de memoria para almacenar el valor primitivo.
El valor es almacenado en memoria.

Es de notar que, el identificador de la variable apunta a la dirección de memoria donde se encuentra el valor, y no al valor en sí mismo.

Vamos a crear una segunda variable con el valor de la primera:

En este caso, la variable oldPreviousAge apunta a la misma dirección de memoria que la variable currentAge, en este sentido, ambas variables hacen referencia al valor de tipo entero 25 a través de la dirección 0x001.

Pero, ¿Y si modificamos el valor de la variable currentAge?, ¿Esto tendrá impacto en la variable oldPreviousAge?, veamos.

En primer lugar, tenemos que entender que un valor residente en una determinada dirección de memoria es inmutable, es decir, no la podemos cambiar una vez ocupada, por lo tanto, una nueva porción de memoria será creada y asignada para apuntar al nuevo valor.

Podemos afirmar que la modificación de currentAge no tiene impacto alguno en la variable oldPreviousAge, ya que ambas variables apuntan a direcciones de memoria diferentes.

Tipos por Referencia

En este caso, las cosas funcionan un poco diferente. Cuando un objeto es creado, este es almacenado en el Heap del Motor de Javascript.

De igual manera, dentro del Heap habrá una dirección de memoria asignada apuntando al objeto en cuestión, sin embargo, la variable en cuestión no va a apuntar directamente a esta dirección de memoria, sino que lo hará a través de una nueva dirección de memoria ubicada en el Call Stack.

Para entender mejor esto, retomemos nuestro ejemplo anterior. Vamos a definir la variable profile y le vamos a asignar como valor un objeto literal.

Como se puede apreciar, desde el Call Stack se hace referencia hacia el Heap para acceder a los objetos almacenados en memoria. El Heap es necesario, ya que los objetos pueden llegar a ser muy grandes, y por lo tanto, ocupar gran espacio en memoria.

Vamos a crear una nueva variable con el valor de la variable profile.

Ahora tanto la variable account como la variable profile apuntan a la misma dirección de memoria dentro del Call Stack, que a su vez, hace referencia a la dirección de memoria dentro del Heap donde se encuentra almacenado el objeto de nuestro interés.

En este caso podemos decir que tanto los tipos primitivos como los tipos por referencia comparten un comportamiento similar, sin embargo, lo verdaderamente interesante ocurre cuando modificamos alguna propiedad del objeto al que se está haciendo referencia, ya sea desde la variable profile o desde la variable account.

Al modificar el valor de la propiedad age desde account, el objeto en cuestión es encontrado dentro del Heap y su valor es actualizado, y dado que ambos identificadores apuntan a la misma referencia de memoria, implícitamente están apuntando al mismo objeto que acaba de ser actualizado.

Esta es la razón por la cual se les denomina Tipos por Referencia.

Sin más, espero les haya servido esta información, y nos leemos en el siguiente artículo. Saludos y Happy Coding.

Si te interesa seguir aprendiendo sobre desarrollo web, ciberseguridad y tecnología, te invito a visitar mi blog personal, donde comparto lo que voy aprendiendo y construyendo en el camino.

Migraciones en Laravel - Convención de Nombres

404Room — Wed, 16 Sep 2026 03:12:07 +0000

Uno de los aspectos más difíciles en el mundo del desarrollo es elegir un nombre apropiado para los diferentes elementos que componen nuestro código: variables, clases, funciones, interfaces, etc, lo mismo aplica para aquellos elementos que contienen nuestro código: paquetes, carpetas, ficheros, etc. Al final, el objetivo es lograr una fuerte consistencia temática en la encapsulación y resolución de un problema.

En esta ocasión, hablaré sobre la convención de nombres que utilizo para nombrar mis archivos de migración en Laravel.

En primer lugar, considero que es importante entender que cada uno de estos archivos de migración debe de seguir una determinada convención de nombre que describa qué es lo que la migración va a realizar cuando sea ejecutada, y de forma inversa e intuitiva, inferir lo que va a ocurrir cuando sea revertida.

En este punto, debemos detenernos y tomar el tiempo necesario para pensar en un nombre que sea consistente y descriptivo, que minimice las ambigüedades y que defina la intención de lo que deseamos lograr con nuestro archivo de migración.

Si analizamos el archivo de todo proyecto en Laravel:

Illuminate/Database/Console/Migrations/TableGuesser.php

Nos daremos cuenta de que, por defecto existen 2 patrones encargados de inferir el comportamiento de la migración:

class TableGuesser
{
  const CREATE_PATTERNS = [
    '/^create_(\w+)_table$/',
    '/^create_(\w+)$/',
  ];

  const CHANGE_PATTERNS = [
    '/_(to|from|in)_(\w+)_table$/',
    '/_(to|from|in)_(\w+)$/',
  ];
}

El patrón CREATE_PATTERNS indica que si el nombre de nuestro archivo de migración comienza con la palabra create, Laravel agrega el Schema::create al método up() y Schema::dropIfExists al método down() de la Clase.

El patrón CHANGE_PATTERNS indica que sí el nombre de nuestro archivo de migración contiene las palabras to, form o in, Laravel hace uso de Schema::table en los métodos up() y down() de la Clase.

Si el nombre de nuestro archivo de migración no cumple con alguno de los patrones de creación o modificación previamente mencionados, simplemente no agrega nada a los métodos up() y down() de la Clase, permitiéndonos de esta manera definir la lógica de migración de acuerdo a nuestras necesidades.

Al nombrar un archivo de migración, busco tomar alguno de estos 2 enfoques:

Orientado a una acción.
Orientado a una feature.

Para efectos de claridad, obviaré el uso del comando php artisan make:migration que antecede al nombre de cada archivo de migración.

Enfoque orientado a una acción

Aquí tengo la opción de ir por un camino simplista o perseguir una convención similar a una definición de datos (DDL).

El camino simplista implica tomar alguno de estos verbos y utilizarlo al inicio del nombre de mi fichero de migración: add, create, remove, delete, set, update, modify, make, change, restore, drop, move o rename.

Ejemplos:

// Agregar una nueva columna.
add_featured_image_url_to_posts_table

// Eliminar una columna existente.
drop_featured_image_url_from_posts_table

// Cambiar el nombre a una columna existente
rename_featured_image_url_in_posts_table

// Cambiar el tipo de una columna existente.
change_status_type_in_posts_table

// Mover de posición una columna hacia delante en relación a otra columna.
move_featured_image_url_after_body_in_posts_table

// Mover de posición una columna hacia atrás en relación a otra columna.
move_featured_image_url_before_body_in_posts_table

// Añadir un índice a una columna existente.
set_name_to_index_on_users_table

// Añadir un índice único a una columna existente.
set_email_to_unique_on_users_table

// Añadir una llave foránea a una columna existente.
set_user_id_to_foreign_key_on_posts_table

// Agregar el comportamiento de Soft Deletes a una tabla existente.
restore_hard_deletes_on_posts_table

En algunos casos tenemos que adaptar el nombre de la tabla a la que hacemos referencia desde el archivo de migración.

Optar por la convención similar a la de una sentencia DDL implica simplemente hacer uso de la palabra alter y algunos agregados descriptivos demás.

Ejemplos:

// Agregar una nueva columna.
alter_posts_table_add_featured_image_url

// Eliminar una columna existente.
alter_posts_table_drop_user_id

// Añadir un índice a una columna existente.
alter_users_table_add_index_on_name

// Añadir un índice único a una columna existente.
alter_users_table_make_name_unique

// Cambiar el tipo de una columna existente.
alter_users_table_change_status_type

// Mover de posición una columna hacia delante en relación a otra columna.
alter_users_table_modify_featured_image_url_after_body

Incluso, dentro de un mismo fichero de migración podemos llevar a cabo múltiples tareas dependiendo del caso:

// Agregar múltiples columnas a nuestra tabla de publicaciones.
alter_posts_table_add_name_and_lastname_and_email

// Alterar una columna y agregar otras en la misma acción.
alter_posts_table_modify_email_and_add_name_and_lastname

Aunque en estos casos, podemos caer en la ambigüedad o en nombres de archivo excesivamente largos dependiendo de las acciones involucradas.

Enfoque orientado a una feature

Esta convención es con la que me siento más identificado. Pienso que el nombre es más amigable y entendible, puedo leer mis archivos de migración como si de historias se tratasen, además cada archivo de migración puede realizar 1 o varias tareas para alcanzar el objetivo deseado.

implement_user_roles

organize_posts_under_categories

make_post_likeable

clear_today_user_logs

implement_post_iframes

make_user_verifiable

make_post_reviewable

set_post_visibility

make_post_editable_only_by_owner_and_admin

Por último, tal vez te estés preguntando ¿No deberíamos evitar realizar múltiples tareas en un solo archivo de migración y dividirlas mejor en múltiples archivos?.

La respuesta a esta pregunta es muy subjetiva y por lo tanto debatible. En mi opinión, va a depender de los requerimientos del problema; habrá ocasiones en que dividir la tarea en múltiples archivos de migración sea la solución correcta, y en otras ocasiones, llevar a cabo múltiples tareas en el mismo archivo de migración será lo más viable.

Si bien creo que todo archivo de migración debe ser lo más descriptivo posible, también creo que es un tema debatible y que no debemos ser tan restrictivos.

Me gustaría saber qué convención o patrón siguen ustedes para nombrar sus archivos de migración. Saludos y Happy Coding.

Si te interesa seguir aprendiendo sobre desarrollo web, ciberseguridad y tecnología, te invito a visitar mi blog personal, donde comparto lo que voy aprendiendo y construyendo en el camino.

Migraciones en Laravel

404Room — Tue, 15 Sep 2026 04:51:38 +0000

Seguramente en algún punto dentro del desarrollo de nuestra base de datos hemos atravesado por alguna de estas fases: Análisis de requerimientos donde definimos las reglas de negocio, Diseño de la Solución donde modelamos la información (Modelo Conceptual) y la representamos de forma gráfica, y la Implementación (Modelo Físico) donde básicamente llevamos a la realidad la manera en que se almacenará nuestra información, es decir, donde creamos la base de datos, las tablas, las columnas, generamos los índices, establecemos las restricciones, etc.

Es en esta fase de implementación donde por lo regular hacemos uso de un gestor de base de datos como Mysql, Oracle, PostgreSQL, SQL Server, Mongodb, etc, para llevar a cabo las tareas previamente mencionadas, y es en esta fase donde haremos mayor énfasis.

Por lo común, las tareas dentro del Modelo Físico se llevan a cabo de forma manual, por ejemplo, directamente a través de un cliente en consola o a través de una interfaz gráfica como Mysql Workbench o DBeaver. Otra manera de lidiar con esta tarea es a través de la codificación de un script que automatice esta tarea por nosotros. En cualquier caso, llegar a ejecutar los cambios de nuestra db de alguna de estas formas puede llegar a ser complicada y/o engorrosa.

Con Laravel, todas estas tareas pueden ser llevadas a cabo de una forma más sencilla y gestionable a través del uso de las migraciones.

Una migración nos permite crear y alterar el esquema de nuestras tablas, generar índices, establecer restricciones, etc, sin embargo, también actúa como una especie de control de versiones sobre nuestra base de datos, esto es, si eventualmente necesitamos consultar un cambio anterior o decidimos que la versión inicial o previa era la que se necesita, en lugar de reescribir todo, simplemente lanzando algunos comandos podemos volver hacia atrás en la línea de tiempo de nuestra db.

Creando nuestra primera migración

Para crear una migración simplemente ejecutamos el siguiente comando:

> php artisan make:migration create_posts_table

Con esto se habrá generado un archivo de migración que tendrá por objetivo crear la tabla de nuestras publicaciones.

Por defecto, Laravel ubica los archivos de migración en database/migrations, además, podemos notar que el nombre del archivo de migración generado posee una nomenclatura que lo identifica:

Sin embargo, lo realmente interesante se encuentra dentro de nuestro archivo de migración recién generado:

class CreatePostsTable extends Migration
{
  /**
  * Run the migrations.
  *
  * @return void
  */
  public function up()
  {
    Schema::create('posts', function (Blueprint $table) {
      $table->id();
      $table->string('title');
      $table->string('url')->unique();
      $table->mediumText('excerpt')->nullable();
      $table->text('body')->nullable();
      $table->timestamp('published_at')->nullable();
      $table->timestamps();
    });
  }

  /**
  * Reverse the migrations.
  *
  * @return void
  */
  public function down()
  {
    Schema::dropIfExists('posts');
  }
}

Dentro del cuerpo de esta Clase podemos identificar 2 métodos:

Dentro del método up() se encuentra aquel código que altera de alguna manera nuestra tabla, por ejemplo, agregar columnas, cambiar el tipo de dato de una columna, generar índices, establecer restricciones, etc. Este método es invocado en el momento que ejecutamos la migración.
El método down() hace lo opuesto, esto es, ejecutar código que revierta lo realizado por el método up(). Este método es invocado en el momento en que decidimos revertir la migración.

Ejecutando una migración

Existen múltiples maneras de correr una migración, sin embargo, la manera más sencilla de hacerlo es con el siguiente comando:

> php artisan migrate

Esto básicamente ejecuta el método up() de nuestra migración. En este punto, se ha creado la tabla posts dentro de nuestra base de datos.

Revirtiendo una migración

Si nuestra intención es deshacer cualquier operación realizada por la ejecución de las migraciones previas, simplemente ejecutamos:

> php artisan migrate:rollback

Esto básicamente ejecuta el método down() de nuestra migración. En este punto, se ha removido la tabla posts dentro de nuestra base de datos.

Migraciones e identificadores de Lote

Creo que esta parte es una de las más importantes y un poco engañosas de entender. Si inspeccionamos la base de datos de nuestro proyecto veremos que existe una tabla llamada migrations que es la encargada de llevar a cabo el control de nuestras migraciones.

Dentro de esta tabla podemos identificar una columna llamada batch. El valor de esta columna es utilizada por Laravel para determinar el orden de ejecución y/o reversión de nuestras migraciones, básicamente funciona como un identificador de lote.

Las migraciones cuyo identificador de lote o batch es 1, son aquellas que ejecutamos por lo común al inicio de nuestro proyecto. La migración con identificador de lote 2, es la migración que recién ejecutamos para crear la tabla de publicaciones que pretendemos utilizar en nuestro proyecto.

Vamos a generar 2 nuevas migraciones: categorías y tags.

> php artisan make:migration create_categories_table
> php artisan make:migration create_tags_table

Ejecutamos nuestra suite de migración:

> php artisan migrate

Y obtenemos el siguiente resultado:

Las nuevas migraciones han sido ejecutadas y ahora poseen el identificador de lote 3. Básicamente cada vez que creamos y corremos nuevas migraciones sobre nuestro proyecto, se genera un identificador de lote propio.

Podemos observar que este identificador de lote se va generando de forma incremental en el caso de nuevas migraciones, de igual manera, si revertimos una migración, el identificador de lote irá disminuyendo. Probemos ejecutando el comando de reversión de migraciones previamente mencionado:

> php artisan migrate:rollback

El resultado es el siguiente:

Podemos apreciar que no todas las migraciones fueron revertidas, solo las últimas, las que tenían el número de lote 3, básicamente hemos vuelto un paso hacia atrás. Si nuevamente ejecutamos el comando de rollback, el resultado será:

Y si nuevamente revertimos nuestras migraciones con el comando anterior en este punto, solo nos quedaremos con:

absolutamente nada, nuestra base de datos no contiene tabla alguna a excepción de la tabla migrations.

Tal vez te preguntes ¿Por qué sucede esto?, nuevamente la respuesta se encuentra en el valor del campo batch.

El proceso de rollback solamente revierte un lote o conjunto de migraciones a la vez tomando como referencia el valor del campo batch, es por ello que tuvimos que ejecutar 3 veces el procedimiento de reversión a través del comando rollback en la consola de Laravel.

Si nuestra intención es revertir todas la migraciones sin importar el identificador de lote, simplemente lanzamos en la terminal:

> php artisan migrate:reset

Alternativamente, podemos ejecutar un rollback de forma selectiva:

> php artisan migrate:rollback --step=1

En este caso solo se eliminara la migración más reciente pero respetando el lote:

Reversión y Migración en un sola acción

Cuando nos encontramos en modo desarrollo es muy común borrar todas las tablas haciendo un rollback y recrearlas nuevamente ejecutando la migración. Para poder realizar esta tarea en un solo paso simplemente:

> php artisan migrate:fresh

Sin embargo, dado que esta acción es destructiva se desaconseja su uso en producción.

Adicionalmente, podemos agregar una acción más a este comando, y esto es, correr nuestros seeders:

> php artisan migrate:fresh --seed

Migrando sin perder la información

Probablemente te estes preguntando como alterar el esquema de una tabla sin perder la información que contiene.

Para poder alterar la estructura de una tabla sin perder la información que contiene simplemente creamos migraciones adicionales. Cada una de estas migraciones debe seguir una determinada convención que describe lo que hace.

Por ejemplo, digamos que necesitamos agregar una nueva columna a nuestra tabla de publicación para guardar la url de una imagen destacada, simplemente escribiríamos algo como esto:

> php artisan make:migration add_featured_image_url_to_posts_table

Si abrimos el archivo recién generado, podemos observar que el cuerpo de la Clase cambia ligeramente:

class AddFeaturedImageUrlToPostsTable extends Migration
{
  /**
  * Run the migrations.
  *
  * @return void
  */
  public function up()
  {
    Schema::table('posts', function (Blueprint $table) {
      // Deseamos agregar esta nueva columna a nuestra tabla 'posts'
      $table->text('featured_image_url')->nullable();
    });
  }

  /**
  * Reverse the migrations.
  *
  * @return void
  */
  public function down()
  {
    Schema::table('posts', function (Blueprint $table) {     
      // Debemos es explícitos e indicar que queremos hacer cuando esta migración sea revertida.
      // En nuestro caso, deseamos eliminar la columna previamente creada.
      $table->dropColumn('featured_image_url');
    });
  }
}

En el método up() en lugar de crear una nueva tabla, hacemos referencia a una existente, en este caso, a la tabla posts. De igual manera, dentro del método down() indicamos que deseamos eliminar una columna, en lugar de la tabla completa.

Ya simplemente queda ejecutar la migración, y listo, tendremos una nueva columna en nuestra tabla de publicaciones.

Hablar sobre la convención de nombres que debemos utilizar para agregar nuevas columnas, índices, restricciones daría para otro articulo en el futuro. Espero esta información te haya servido para entender un poco más sobre las migraciones en Laravel.

Si te interesa seguir aprendiendo sobre desarrollo web, ciberseguridad y tecnología, te invito a visitar mi blog personal, donde comparto lo que voy aprendiendo y construyendo en el camino.

Introducción a la Notación Big O

404Room — Tue, 15 Sep 2026 04:23:59 +0000

¿Cómo evaluar el desempeño de un algoritmo?, ¿Qué queremos decir cuando el desempeño de un algoritmo es mejor que otro?, ¿Qué es lo que buscamos de la implementación de nuestro algoritmo?. Al desarrollar un algoritmo surgen estas interrogantes y la ambigüedad se hace presente.

Sea que busquemos rapidez en el tiempo de ejecución, ya sea en el orden de segundos e incluso en milisegundos.
Minimizar el uso intensivo de la memoria, definiendo menos variables y con nombres más compactos.
Maximizar la legibilidad de nuestro código para hacerlo más mantenible.

Cualquier decisión que tomemos siempre tendrá un tradeoff o costo de oportunidad, sin embargo, lo importante es saber realmente lo qué queremos o buscamos de nuestro algoritmo.

¿Deberíamos escribir código más compacto con el riesgo de que sea menos legible y por lo tanto más difícil de mantener? o por el contrario, ¿Deberíamos escribir código más claro y legible con el potencial de que ocupe mas espacio en memoria?.

Supongamos que nuestra intención es comparar la velocidad de ejecución entre estas 2 funciones:

Implementación de addUpToFirst():

function addUpToFirst(n)
{
  let total = 0;

  for( i = 1; i <= n; i++) {

    total += i;
  }

  return total;
}

Implementación de addUpToSecond():

function addUpToSecond(n)
{
  return n * (n + 1) / 2;
}

Procedamos a evaluar el desempeño de ejecución de cada uno y comparemos.

Resultados de addUpToFirst():

let t1 = performance.now();
addUpToFirst(1000000000);
let t2 = performance.now();

console.log("Tiempo transcurrido: ${(t2 - t1) / 1000} segundos");

Tiempo Transcurrido: 1.25750000000006985 segundos
Tiempo Transcurrido: 1.24369999999936985 segundos

Resultados de addUpToSecond():

let t1 = performance.now();
addUpToSecond(1000000000);
let t2 = performance.now();

console.log("Tiempo transcurrido: ${(t2 - t1) / 1000} segundos");

Tiempo Transcurrido: 0.00010000000004773 segundos
Tiempo Transcurrido: 0.00010000000004773 segundos

Evidentemente la segunda versión es muchísimo mas rápida en comparación con la primera versión en términos de velocidad de ejecución.

Sin embargo, esta evaluación de alguna manera sigue siendo ambigua, y esto se debe principalmente a la herramienta que hemos utilizado para evaluar el desempeño en el tiempo de ejecución del algoritmo en cuestión: un Temporizador.

Entonces, ¿Me estás diciendo que un temporizador es un mecanismo poco confiable al evaluar el desempeño del tiempo de ejecución de un algoritmo?, en definitiva, y esto se debe principalmente al hardware:

Diferentes máquinas registran diferentes tiempos dadas las especificaciones de hardware de cada máquina, lo que ocasiona que los resultados puedan variar.
Una misma máquina puede registrar diferentes tiempos cada vez que ejecutamos nuestra rutina. La variación puede ser poco significativa, pero aún así puede existir una falta de precisión.
La métrica de velocidad en el tiempo de ejecución puede no ser un indicador preciso y confiable en algoritmos que son muy veloces. Por ejemplo, podemos tener 4 algoritmos superveloces, tan rápidos que los temporizadores no lleguen a registrar los tiempos de ejecución de cada uno de forma precisa.

En lugar de intentar contabilizar el número de segundos (el cual es variable) que tarda una rutina en finalizar su ejecución, es mucho mejor concentrarse en contabilizar el número de operaciones que nuestra implementación debe realizar para llegar a un resultado.

El tiempo de ejecución de nuestro algoritmo depende del número de operaciones que realice, y este número es constante sin importar la máquina o hardware que utilicemos.

Tomemos como ejemplo la implementación de la función addUpToFirst():

y comparemosla con la función addUpToSecond():

¿Qué podemos concluir de esta comparativa?. La función addUpToFirst() ejecuta un número de operaciones que es proporcional al valor asignado a n, es decir, a medida que n aumenta, el número de operaciones que realiza este algoritmo crecerá en la misma proporción.

En contraste, la función addUpToSecond() lleva a cabo solamente 3 operaciones independientemente del valor que le asignemos a n, por lo que si n crece, el número de operaciones que realiza nuestro algoritmo se mantiene siempre igual.

En la práctica llevar un conteo de operaciones ejecutadas por un algoritmo puede parecer un enfoque poco intuitivo, sin embargo, existe una manera de llevar a cabo esto.

Debemos entender qué, lo importante no es llevar el conteo preciso y exacto en el número de operaciones ejecutadas, lo que realmente importa es observar el comportamiento general del número de operaciones ejecutadas relativas la variabilidad de n.

Esto básicamente significa que todo algoritmo posee un tendencia que puede ser plasmada en una gráfica, y es a través de esta gráfica que nos damos una idea general del desempeño de nuestro algoritmo, en este caso, relativa al tiempo o velocidad de ejecución.

Tendencia general de addUpToFirst(): a medida que n crece, el tiempo de ejecución crece de forma proporcional o lineal.

Tendencia general de addUpToSecond(): a medida que n crece, el tiempo de ejecución permanece casi constante.

En esta breve introducción tenemos los fundamentos necesarios para comenzar a entender lo que es la notación Big O y su significado. En el siguiente artículo nos adentraremos en mayor profundidad en el tema, espero les haya gustado. Saludos y Happy Coding.

Si te interesa seguir aprendiendo sobre desarrollo web, ciberseguridad y tecnología, te invito a visitar mi blog personal, donde comparto lo que voy aprendiendo y construyendo en el camino.