Hola,
Si tienen una variable con un valor configurado en un archivo application.yaml o en una infra y requieren mockear dicho valor en un test para una prueba unitaria hagan lo siguiente:


1. En el archivo: application.yaml:

titulo:
    valorFijo: MiValorFijo


2. En la clase: MiClaseDeNegocio.java que invoca este valor fijo: 

@Value("${titulo.valorFijo}")
private String VALOR_VARIABLE_FIJA;


3. En la clase: MiClaseDeNegocioTest.java que mockea este valor fijo:

@InjectMocks
private MiClaseDeNegocio miClaseDeNegocio;
  
private String VALOR_VARIABLE_FIJA = "MiVariableFija";


@BeforeEach
public void setUp() {

ReflectionTestUtils.setField(miClaseDeNegocio, "VALOR_VARIABLE_FIJA", VALOR_VARIABLE_FIJA);

}

Listo, al correr la prueba unitaria que estén realizando, esta variable ya se encontrara mockeado y no llegara como null.

Hola,
Hoy les quiero hablar sobre el hermoso, frío, calmado e imponente Lago del Embalse Calima.


El hombre creó el embalse del lago Calima para procurarse energía, inundando 14 kilómetros de largo por uno y medio de ancho en lo que antes fuera asiento de la cultura indígena Calima. Esto, se dice, ofendió a sus antiguos pobladores, cuya ira había causado hasta 1.992 la muerte de unos quinientos bañistas en sus 25 años de existencia. La tranquilidad de sus aguas en la mañana contrasta con el movimiento generado en las tardes por la intensidad de los vientos, lo que hace que el embalse ocupe el cuarto lugar como lago artificial ideal en el mundo para los deportes náuticos de vela.
Enclavado en la pintoresca región del Darién, el Lago Calima se erige como uno de los tesoros naturales más cautivadores de Colombia. Sus aguas serenas y los paisajes circundantes atraen a visitantes en busca de un escape tranquilo y rejuvenecedor.

Antecedentes de la región Calima
Se cree que las antiguas civilizaciones precolombinas como los indígenas calimas en el año 8.000 a.C. aproximadamente habitaron toda la zona del Darién. Un pueblo indígena que deslumbró por sus trabajos de cerámica y orfebrería. la mayoría de los cuales aún se conservan en el Museo Arqueológico de la región.
Con la llegada de los conquistadores españoles, el territorio experimentó transformaciones significativas. La influencia europea se refleja en la arquitectura colonial y las tradiciones que aún se conservan en el Darién.

La Historia del Embalse Calima
El Embalse Calima, conocido comúnmente como Lago Calima, es una maravilla hidroeléctrica y turística ubicada en el municipio del Darién, Valle del Cauca. Su historia se remonta a mediados del siglo XX cuando se iniciaron los trabajos de construcción, fue en el año 1966 que se completó esta monumental obra, convirtiéndose en uno de los embalses más grandes de Colombia.
En el fondo de dicho lago se encuentran arenas movedizas; árboles que nunca se derribaron; casas de bahareque y los pilotes de un viejo puente.
Está a una hora y 20 minutos de Cali y es el tercer lago en el mundo con la mayor velocidad de vientos.

Una Proeza de Ingeniería
La construcción del embalse implicó un desafío técnico y logístico de gran envergadura. Ingenieros y obreros trabajaron incansablemente para represar el río Calima, inundando 1.934 hectáreas de la región con aguas del río Calima y reforzándolo con aguas del río Bravo, a través de un túnel de ocho kilómetros; logrando crear así un cuerpo de agua de 13 kilómetros de longitud y 1,5 kilómetros de ancho; que no solo generaría energía eléctrica, sino que también se convertiría en un atractivo turístico de renombre.
Este embalse dio vida al Lago Calima, un espejo de agua de aproximadamente 70 kilómetros cuadrados de extensión, con casi quinientos millones de metros cúbicos de agua, una profundidad máxima de 110 metros, situados a 1.400 metros de altura sobre el nivel del mar y con un clima templado. Este cuerpo de agua no solo embellece la región, sino que también cumple funciones vitales para el abastecimiento de agua para las poblaciones aledañas, la generación de energía eléctrica en la región y el turismo para todas sus comunidades adyacentes.
La hidroeléctrica del lago Calima se ubica como la tercera en el Valle del Cauca, por su capacidad de generación de energía, con 120 megavatios, después de Alto Anchicayá, que genera 345, y Salvajina, cuya producción alcanza los 270.

Fecha de construcción
El Lago Calima se inauguró oficialmente el 30 de julio de 1966.

Calima, el lago del brujo
La niebla que en las tardes cae sobre el embalse, trayendo consigo un fuerte viento, perfecto para hacer windsurf y kitesurf, ha cautivado a los viajeros, está viene del cañón del río Bravo, baja por las montañas e invade la mayor parte del norte del lago Calima. 
A esta neblina espesa, que se cuela sobre el agua y esconde las cometas y las velas de windsurfistas y kitesurfistas, le dicen El Brujo.

Fuentes:
La caída del Imperio romano de Occidente (también conocida como la caída del Imperio romano o la caída de Roma) se refiere al hecho de la pérdida de autoridad sobre el vasto territorio del Imperio romano de Occidente que quedó dividido en numerosas entidades políticas sucesoras. 
Tradicionalmente, de acuerdo con el criterio del historiador del siglo XVIII Edward Gibbon, se sitúa su final en el año 476 d.C., coincidiendo con la deposición del último emperador romano de Occidente, Rómulo Augústulo, a manos de Odoacro, aunque fue el resultado de un largo proceso en el que hubo otros muchos hitos significativos.


Hay que empezar destacando las fuerzas que le habían permitido al Imperio romano ejercer un control efectivo sobre Occidente; historiadores modernos mencionan factores que incluyen la efectividad y el tamaño del ejército, la salud y el tamaño de la población romana, la fuerza de la economía, la capacidad y competencia de los emperadores, las luchas internas por el poder, los cambios religiosos del período y la eficiencia de la administración civil. El aumento de la «presión de los bárbaros», externos a la cultura romana, contribuyó en gran medida al colapso.

Años relevantes en este contexto lo constituyen el año 117, cuando el Imperio alcanzó su mayor extensión territorial, y el ascenso de Diocleciano en el 284. Las pérdidas territoriales irreversibles, no obstante, comenzaron en el 386 con una invasión en gran escala de los godos y otros pueblos. En 395, tras imponerse en dos guerras civiles destructivas, Teodosio I falleció, dejando al imperio, con varios territorios donde no ejercía el control, dividido entre sus dos hijos. Para el año 476, cuando Flavio Odoacro depuso al emperador Rómulo, el emperador romano de Occidente ejercía un insignificante poder militar, político y financiero, y carecía de control efectivo sobre los dispersos territorios en Occidente que aún podrían ser descritos como «romanos». Los invasores «bárbaros» establecieron su propia autoridad en la mayor parte del área del Imperio de Occidente, aunque algunos de ellos ya estaban asentados en el propio Imperio de manera pacífica en su origen (francos en las Galias, vándalos en Panonia, godos en Dacia, etc.), recibiendo sus jefes el título de cónsules o virreyes por parte de los emperadores residentes en Constantinopla, como el propio Flavio Odoacro, ciudadano romano nacido en Panonia. Aunque su legitimidad sobrevivió durante varios siglos más, y su influencia cultural persiste hasta el día de hoy, el Imperio Romano de Occidente nunca se reconstituyó. No sucedió lo mismo con el Imperio Romano de Oriente que perduró mil años más.

Periodo

La pérdida de control político centralizado sobre el occidente y el poder reducido de Oriente son universalmente reconocidos. Como una marca conveniente del final del imperio occidental, se ha utilizado el año 476 desde Gibbon, pero otros hitos incluyen la crisis del siglo III, la invasión del Rin en 406 (o 405), el saqueo de Roma en el año 410, la muerte de Julio Nepote en el 480 y la caída de Constantinopla en 1453.​ Pero el nombre de «decadencia» se ha empleado para cubrir un período de tiempo mucho más amplio que los cien años a partir de 376. Gibbon comenzó su historia en el 98 y Theodor Mommsen consideró toda la época imperial como indigna de incluirla en su obra Historia de Roma, por la que recibió el Premio Nobel de Literatura. Arnold J. Toynbee y James Burke sostienen que toda la era imperial fue un decaimiento constante de las instituciones fundadas en tiempos de la república.

Causas

Gibbon enunció una formulación clásica, ahora vetusta, de las razones por las que desapareció el imperio occidental. Comenzó una controversia, aún en curso, sobre el papel del cristianismo, pero dio gran importancia a otras causas de deterioro interno y a los ataques de fuera del Imperio.

La historia de su ruina es simple y obvia; y, en lugar de preguntar por qué el Imperio romano fue destruido, deberíamos más bien sorprendernos de que haya subsistido tanto tiempo. Las legiones de reconocimiento, que, en guerras lejanas, adquirieron los vicios de los extranjeros y mercenarios, primero oprimían la libertad de la república, y después violaron la majestuosidad de la púrpura. Los emperadores, deseosos de asegurar su seguridad personal y la paz pública, se limitaron a corromper la disciplina de las tropas que intimidaba tanto al soberano y como a los enemigos; la potencia del gobierno militar se relajó, y finalmente se disolvió, por las instituciones parciales de Constantino; y el mundo romano se vio abrumado por una avalancha de bárbaros.
Edward Gibbon. The Decline and Fall of the Roman Empire, "General Observations on the Fall of the Roman Empire in the West", capítulo 38.

Alexander Demandt enumeró doscientas diez teorías diferentes sobre el porqué de la caída de Roma, y nuevas ideas han surgido desde entonces.​ Los historiadores todavía tratan de analizar las razones de la pérdida de control político sobre su vasto territorio (y, como tema secundario, las razones para la supervivencia del Imperio romano de Oriente).


Apogeo

El Imperio romano alcanzó su mayor extensión geográfica durante el reinado del emperador Trajano (98-117), que gobernó un Estado próspero que se extendía desde Mesopotamia hasta las costas del Atlántico. El imperio contaba entonces con un Ejército numeroso y disciplinado, así como con una extensa Administración Pública basada en las prósperas ciudades que controlaban eficazmente las finanzas públicas. Entre la clase privilegiada culta, el Estado gozaba de legitimidad ideológica como la única civilización aceptable y mantenía la unidad cultural basada en el extendido conocimiento de la literatura y la retórica griegas y romanas. El poder del imperio le permitió mantener desigualdades extremas de riqueza y posición social (incluida la abundante esclavitud),​ y las redes comerciales de gran alcance permitieron incluso a los hogares modestos utilizar bienes fabricados en tierras lejanas.​

El sistema financiero le permitió recaudar copiosos impuestos que, a pesar de la corrupción endémica, sirvieron para sufragar el gran ejército, su logística e instrucción. El cursus honorum, una jerarquía de puestos militares y civiles adecuados para aristócratas, aseguró que los nobles poderosos se familiarizaran con las tareas militares y con la administración civil del Estado. En un nivel inferior dentro del Ejército, como nexo entre los aristócratas y los soldados, se encontraba un gran número de centuriones; bien pagados y alfabetizados, estos eran los responsables de la instrucción y disciplina de sus hombres, de la administración de sus unidades y de la dirección de estas en el campo de batalla.​ Los gobiernos municipales, con sus propios bienes e ingresos, funcionaban eficazmente a nivel local; la membresía de un ayuntamiento ofrecía lucrativas oportunidades, y, a pesar de sus obligaciones, era vista como un privilegio. Gracias a una serie de emperadores que adoptaron cada uno a un sucesor maduro y capaz (la dinastía Antonina), el imperio no necesitó de guerras civiles para regular la sucesión imperial. Durante los reinados de los mejores emperadores, se les podían presentar solicitudes directamente; las respuestas eran ley y ponían el poder imperial en contacto directo incluso con los súbditos más humildes. La tolerancia entre las distintas religiones paganas produjo concordia religiosa.​ Las tensiones religiosas fueron raras después del aplastamiento de la revuelta de Bar Kojba en 136 (después de lo cual la Judea devastada dejó de ser un centro de disturbios judíos). La mortandad causada por la peste antonina del 165 entorpeció seriamente los intentos de repeler a los invasores germánicos, pero no impidió que las legiones generalmente consiguieran mantener sus posiciones o recuperar rápidamente los territorios fronterizos perdidos temporalmente.


Tomado de:
La masacre de las bananeras fue una matanza de los trabajadores de la empresa estadounidense de banano United Fruit Company a manos del Ejército de Colombia bajo el mando de Carlos Cortés Vargas, que se produjo entre el 5 y el 6 de diciembre de 1928 en el municipio de Ciénaga, Magdalena.


Un número indefinido (diversas fuentes indican números entre 13 y 2000) de trabajadores masacrados después de que el gobierno del conservador Miguel Abadía Méndez decidió poner fin a una huelga de un mes organizada por el sindicato de los trabajadores que buscaban garantizar mejores condiciones de trabajo.​ El 28 de noviembre de ese año había estallado la huelga más grande de la historia colombiana. Más de 25.000 trabajadores de las plantaciones se negaron a cortar los bananos producidos por la United Fruit Company y por productores nacionales bajo contrato con la compañía.​ A pesar de tal presión, la United Fruit Company y los huelguistas no lograron llegar a un acuerdo, y el ejército intervino, acribillando a varios obreros e hiriendo a otros más, quienes estaban protestando pacíficamente.

Autores como Gabriel García Márquez, en su obra Cien años de soledad; Álvaro Cepeda Samudio, en su novela La casa grande; y el dramaturgo Carlos José Reyes, han retratado el evento, logrando que los sucesos se preserven en la cultura colombiana como uno de los más grandes genocidios realizados en contra de la población civil.

Las peticiones de la huelga:

Un año después del huracán en Sevilla los obreros bananeros elaboraron un pliego de peticiones compuesto de nueve demandas. El 6 de octubre de 1928 una asamblea de la Unión Sindical de Trabajadores del Magdalena, en Ciénaga, aprobó unánimemente el pliego. Solicitaron a la United Fruit Company y a los productores nacionales:
  1. Seguro colectivo obligatorio.
  2. Reparación por accidentes de trabajo.
  3. Habitaciones higiénicas y descanso dominical.
  4. Aumento en 50% de los jornales de los empleados que ganaban menos de 100 pesos mensuales.
  5. Supresión de los comisariatos.
  6. Cesación de préstamos por medio de vales.
  7. Pago semanal.
  8. Abolición del sistema de contratista.
  9. Mejor servicio hospitalario.

La masacre:

Durante la primera semana de diciembre, Alejandro Valbuena, el general Carlos Cortés Vargas y algunos cultivadores colombianos enviaron cantidades de telegramas a las autoridades en La Esperanza describiendo la situación como de violencia inminente, de peligro y destrucción originados en masas incontrolables. Las confrontaciones entre la United Fruit Company y el ejército, de un lado, y los trabajadores, del otro, por el rompimiento de la huelga el 3 y 4 de diciembre, dieron al general Cortés Vargas una justificación más para la represión. En sus memorias de la huelga, dice que se convenció de que si el orden público no era restaurado de forma inmediata, el gobierno de los Estados Unidos enviaría marines. Los rumores sobre barcos de guerra de los Estados Unidos eran abundantes. Los obreros veían su huelga como un acto nacionalista: querían obligar a la United Fruit Company a reconocer la ley colombiana y los derechos laborales colombianos. Cortés Vargas, en cambio, vio la represión de la huelga en términos nacionalistas: creía que su deber era acallar a los trabajadores para asegurar que el suelo colombiano no fuera profanado por soldados extranjeros.

Así, la iniciativa de la Oficina General de Trabajo del 3 y 4 de diciembre para romper la huelga y evitar la violencia fracasó: fue el factor final que precipitó la masacre en la noche del 5 a 6 de diciembre. A raíz del incidente Botero, el general Cortés Vargas le envió un telegrama a los doctores Hoyos Becerra y Velandia:

He ordenado concentrar toda la fuerza y sigo inmediatamente a batir por el fuego amotinados.

Cuando grupos de huelguistas comenzaron a congregarse en Ciénaga en la tarde del 5 de diciembre, el general Carlos Cortés Vargas y 300 soldados ya estaban allí. El general describió la escena en los siguientes términos:

Toda la ciudad era patrullada por grupos amotinados que infunden el terror entre los habitantes. La ciudad estaba prácticamente en manos de un soviet de gente irresponsable.

Tanto el general como sus superiores interpretaron claramente la reunión en Ciénaga como un movimiento de huelguistas armados para atacar al ejército. Durante el transcurso de la tarde del 5 de diciembre, Cortés Vargas fue incapaz de aprovisionar a sus tropas o de mantener funcionando los trenes.

Finalmente, a las once y treinta de la noche, la noticia que había estado esperando llegó. El decreto legislativo número 1 de 1928 declaraba la ley marcial en la provincia de Santa Marta y nombraba como jefe civil y militar al general. A la una y treinta de la mañana, marchó con sus tropas, sobre todo antioqueñas, a la plaza cercana al ferrocarril, donde estaban congregados entre 2.000 y 4.000 huelguistas durmiendo, comiendo, charlando, esperando a que llegaran más compañeros, esperando al gobernador, esperando la mañana para marchar hacia Santa Marta. Sonaron los tambores. Trescientos soldados se apostaron al costado norte de la plaza. En voz alta un capitán leyó el decreto de estado de sitio, que prohibía asambleas de más de tres personas. Los huelguistas y sus familias debían dispersarse en forma inmediata, concluyó, o los soldados dispararían. Siguieron tres toques de corneta a intervalos de un minuto. Casi nadie se movió. Más tarde algunos de los que estaban presentes dijeron que estaban seguros de que los soldados no dispararían: los huelguistas eran demasiados y habían tratado bien a los soldados. Se oyeron unos pocos gritos de la multitud: «¡Viva Colombia libre! ¡Viva el ejército!» El general Carlos Cortés Vargas ordenó a sus soldados disparar…

Lo que no creían los trabajadores que pasaría, sucedió. En las horas que siguieron, las gentes de Ciénaga, encerradas en sus casas, oyeron pasar un tren con dirección al mar y el pito de un barco a la distancia. A las seis de la mañana el personero de Ciénaga, llamado para practicar el levantamiento de los cadáveres, encontró nueve muertos tendidos en la plaza. El general Carlos Cortés Vargas informó a sus superiores que estos nueve, más cuatro más que murieron por sus heridas, fueron los únicos huelguistas muertos en la noche del 5 de diciembre. La gente de la zona, sin embargo, cree que fueron decenas, sino cientos los muertos. Mientras huía de Ciénaga Raúl Eduardo Mahecha le contó a otros que sesenta personas habían sido asesinadas; Alberto Castrillón los estima en cuatrocientos. Muchos cuerpos, dicen, fueron rápidamente cargados en los trenes y arrojados al mar, y otros enterrados en fosas comunes en una finca bananera vecina. El general dejó intencionalmente nueve cadáveres en la plaza —decían— para que los trabajadores supieran que los nueve puntos de su pliego habían muerto.


Que fue de la United Fruit Company:

La United Fruit Company (también conocida por sus siglas UFCO, como la Frutera, el Pulpo o la Yunai—en Costa Rica—) fue una empresa multinacional estadounidense, fundada en 1899, que se dedicó a la producción y comercialización de frutas tropicales (principalmente bananas) cultivadas en América Latina.

Durante el siglo XX, United Fruit Company se convirtió en una fuerza política y económica determinante en muchos países de dicha región (las llamadas «repúblicas bananeras»), influyendo decisivamente sobre gobiernos y partidos para mantener sus operaciones con el mayor margen posible de ganancias, al extremo de auspiciar golpes de Estado y sobornar políticos.

Quebro en la década de 1970, se reorganizó como Chiquita Brands International Sàrl está es una empresa multinacional dedicada a la producción y distribución de plátanos y otros productos bajo una diversidad de marcas subsidiarias, conocida colectivamente como Chiquita, con tres sedes centrales (en Fort Lauderdale, Estados Unidos, en Etoy, Vaud, Suiza, y en Santa Ana, Costa Rica). Chiquita es la sucesora de la controvertida empresa United Fruit Company y es la principal distribuidora de plátanos en los Estados Unidos. La compañía también es dueña de Atlanta AG, una empresa alemana de distribución de sus productos, que adquirió en 2003.


Fuentes:

Hola,

Te explicare sobre for y forEach en Java, vamos allá...


ForEach permite recorrer la lista de elementos de una forma mas compacta y el código se reduce.

for(String cadena :lista) {
    System.out.println(cadena);
}

La principal ventaja del forEach es que no necesita saber cual es la propiedad que define el limite de la lista para recorrerla. Es decir no ser tiene porque acceder al método size() de Java.

¿Como se consigue recorrer la colección de elementos de forma tan sencilla?.
R:// Esto se debe a que una gran parte de las Colecciones de Java heredan del interface Collection y este a su vez del interface Iterable. El interface Iterable es el que permite recorrer una lista cualquiera sin acceder por posición.

Por el contrario el For, permite recorrer la lista como un bucle básico, es decir, se debe definir desde que posición empieza la colección a recorrer, cual es su tamaño mediante el método size() para delimitar hasta donde se recorre y especificar cuanto aumenta por cada iteración.

for (int i=0;i<lista.size();i++) {
    System.out.println(lista.get(i));
}

Listo, eso es todo.

Basado en:


Hola,

No se si a ustedes también les ha pasado pero trabajan diariamente con todo tipo de validaciones y alguien les hace una pregunta tipo:

Oye, sabes cual es la diferencia entre .equals() y == ? Y quedas literalmente bloqueado, ja ja ja


No te preocupes aquí te lo explico lo más fácil posible.

A nivel de codificación el .equals() se utiliza para comparar objetos, puesto que estos al crearse se les asigna un espacio de memoria distinto a cada uno, aunque sean instancias de un mismo DTO o de una misma clase; lo cual los convierte en dos objetos diferentes, ejemplo:

MiDTO miDTO = new MiDTO();
MiDTO miDTO1 = new MiDTO();

El == al ser un operador de igualdad, se utiliza para comparar dos variables diferentes de tipos básicos, ejemplo:

int numero1 = 30;
int numero2 = 30;

Listo, eso es todo, espero haberles ayudado a solucionar esa duda.

Basado en:

Hola a todos,

Realizo está publicación debido a que recientemente me hicieron una pregunta que su respuesta estaba directamente relacionada con el status 300 y yo, en mi ignorancia solamente conocía los tradicionales status 200, 400 y/o 500; por lo cual, me hizo cuestionarme que me estoy quedando obsoleto por falta de practica, por esto mismo, investigue, recopile basándome en otras páginas y aquí les comparto los códigos de status existentes y una breve explicación de estos.


Primero, ¿Que es un código de Status HTTP?:

Son mensajes cortos de un servidor que se insertan en una página web. En realidad no son parte del contenido del sitio. En su lugar, son mensajes del servidor que te permiten saber cómo fueron las cosas cuando recibió la solicitud (request).
Este tipo de mensajes se devuelven cada vez que tu navegador interactúa con un servidor, aunque no los veas. Si eres propietario o desarrollador de un sitio web, entender los códigos de estado HTTP es fundamental. Cuando aparecen, los códigos de estado HTTP son una herramienta invaluable para diagnosticar y arreglar errores de configuración del sitio web.
Los códigos de estado de HTTP se entregan a tu navegador en el encabezado de HTTP.
E igualmente se retornan en invocaciones de microservicios o lambdas utilizando herramientas como el Postman.

Comprensión de los tipos de código de estado HTTP:

Los códigos de estado HTTP se dividen en 5 «tipos». Se trata de agrupaciones de respuestas que tienen significados similares o relacionados. Saber qué son puede ayudarte a determinar rápidamente la sustancia general de un código de estado antes de que vayas a buscar su significado específico.

Las cinco clases incluyen:
  • 100s: Códigos informativos que indican que la solicitud iniciada por el navegador continúa.
  • 200s: Los códigos con éxito regresaron cuando la solicitud del navegador fue recibida, entendida y procesada por el servidor.
  • 300s: Códigos de redireccionamiento devueltos cuando un nuevo recurso ha sido sustituido por el recurso solicitado.
  • 400s: Códigos de error del cliente que indican que hubo un problema con la solicitud.
  • 500s: Códigos de error del servidor que indican que la solicitud fue aceptada, pero que un error en el servidor impidió que se cumpliera.
Dentro de cada una de estas tipos, existe una variedad de códigos de servidor y pueden ser devueltos por el servidor. Cada código individual tiene un significado específico y único, que se veran en la lista más detallada a continuación.

Lista explicada de más de 40 códigos de Status HTTP:

Códigos de estado 100

Un código de estado de nivel 100 te dice que la solicitud que has hecho al servidor sigue en curso por alguna razón. Esto no es necesariamente un problema, es sólo información extra para que sepas lo que está pasando.
  • 100: «Continuar». Esto significa que el servidor en cuestión ha recibido las cabeceras de solicitud de tu navegador, y ahora está listo para que el cuerpo de la solicitud sea enviado también. Esto hace que el proceso de solicitud sea más eficiente ya que evita que el navegador envíe una solicitud de cuerpo aunque los encabezados hayan sido rechazados.
  • 101: «Cambiando protocolos». Tu navegador ha pedido al servidor que cambie los protocolos, y el servidor ha cumplido.
  • 103: «Primeros avisos». Esto devuelve algunos encabezados de respuesta antes de que el resto de la respuesta del servidor esté lista.
Códigos de estado 200

Este es el mejor tipo de código de estado HTTP que se puede recibir. Una respuesta de nivel 200 significa que todo funciona exactamente como debería.
  • 200: «Todo está bien». Este es el código que se entrega cuando una página web o recurso actúa exactamente como se espera.
  • 201: «Creado». El servidor ha cumplido con la petición del navegador y, como resultado, ha creado un nuevo recurso.
  • 202: «Aceptado». El servidor ha aceptado la solicitud de tu navegador pero aún la está procesando. La solicitud puede, en última instancia, dar lugar o no a una respuesta completa.
  • 203: «Información no autorizada». Este código de estado puede aparecer cuando se utiliza un apoderado. Significa que el servidor proxy recibió un código de estado de 200 «Todo está bien» del servidor de origen, pero ha modificado la respuesta antes de pasarla a su navegador.
  • 204: «Sin contenido». Este código significa que el servidor ha procesado con éxito la solicitud, pero no va a devolver ningún contenido.
  • 205: «Restablecer el contenido». Como un código 204, esto significa que el servidor ha procesado la solicitud pero no va a devolver ningún contenido. Sin embargo, también requiere que tu navegador restablezca la vista del documento.
  • 206: «Contenido parcial». Puedes ver este código de estado si tu cliente HTTP (también conocido como tu navegador) usa «cabeceras de rango». Esto permite a tu navegador reanudar las descargas en pausa, así como dividir una descarga en múltiples flujos. Se envía un código 206 cuando un encabezado de rango hace que el servidor envíe sólo una parte del recurso solicitado.
Códigos de estado 300

La redirección es el proceso utilizado para comunicar que un recurso ha sido trasladado a una nueva ubicación. Hay varios códigos de estado HTTP que acompañan a las redirecciones, con el fin de proporcionar a los visitantes información sobre dónde encontrar el contenido que están buscando.
  • 300: «Opciones Múltiples». A veces, puede haber múltiples recursos posibles con los que el servidor puede responder para cumplir con la solicitud de su navegador. Un código de estado 300 significa que tu navegador ahora tiene que elegir entre ellos. Esto puede ocurrir cuando hay múltiples extensiones de tipo de archivo disponibles, o si el servidor está experimentando desambiguación del sentido de las palabras.
  • 301: «El recurso solicitado ha sido trasladado permanentemente». Este código se entrega cuando una página web o un recurso ha sido reemplazado permanentemente por un recurso diferente. Se utiliza para la redirección permanente del URL.
  • 302: «El recurso solicitado se ha movido, pero fue encontrado». Este código se utiliza para indicar que el recurso solicitado se encontró, pero no en el lugar donde se esperaba. Se utiliza para la redirección temporal de la URL.
  • 303: «Ver otros». Para entender un código de estado 303 es necesario conocer la diferencia entre los cuatro métodos de solicitud HTTP principales. Esencialmente, un código 303 le dice a tu navegador que encontró el recurso que el navegador solicitó vía POST, PUT o DELETE. Sin embargo, para recuperarlo usando GET, necesita hacer la solicitud apropiada a un URL diferente al que usó anteriormente.
  • 304: «El recurso solicitado no ha sido modificado desde la última vez que accedió a él». Este código le dice al navegador que los recursos almacenados en la caché del navegador no han cambiado. Se usa para acelerar la entrega de páginas web reutilizando los recursos descargados previamente.
  • 307: «Redireccionamiento temporal». Este código de estado ha reemplazado a 302 «Encontrado» como la acción apropiada cuando un recurso ha sido movido temporalmente a una URL diferente. A diferencia del código de estado 302, no permite que el método HTTP cambie.
  • 308: «Redireccionamiento permanente». El código de estado 308 es el sucesor del código 301 «Movido permanentemente». No permite que el método HTTP cambie e indica que el recurso solicitado está ahora localizado permanentemente en una nueva URL.
Códigos de estado 400

En el nivel 400, los códigos de estado HTTP comienzan a ser problemáticos. Estos son códigos de error que especifican que hay un fallo en su navegador y/o en la solicitud.
  • 400: «Mala petición». El servidor no puede devolver una respuesta debido a un error del cliente.
  • 401: «No autorizado» o «Se requiere autorización». Esto es devuelto por el servidor cuando el recurso de destino carece de credenciales de autenticación válidas. Podrías ver esto si has configurado la autenticación básica de HTTP usando htpasswd.
  • 402: «Pago requerido». Originalmente, este código fue creado para ser usado como parte de un sistema de dinero digital. Sin embargo, ese plan nunca se llevó a cabo. En cambio, es utilizado por diversas plataformas para indicar que una solicitud no se puede cumplir, por lo general debido a la falta de los fondos necesarios. Los casos más comunes incluyen: Has alcanzado el límite de solicitudes diarias al API de los desarrolladores de Google. No ha pagado tus honorarios de Shopify y su tienda ha sido desactivada temporalmente. Tu pago a través de Stripe ha fallado, o Stripe está tratando de evitar un pago fraudulento.
  • 403: «El acceso a ese recurso está prohibido». Este código se devuelve cuando un usuario intenta acceder a algo a que no tiene permiso para ver. Por ejemplo, intentar acceder a un contenido protegido por contraseña sin registrarse podría producir un error 403.
  • 404: «No se encontró el recurso solicitado». Este es el mensaje de error más común de todos ellos. Este código significa que el recurso solicitado no existe, y el servidor no sabe si alguna vez existió.
  • 405: «Método no permitido». Esto se genera cuando el servidor de alojamiento (servidor de origen) soporta el método recibido, pero el recurso de destino no lo hace.
  • 406: «Respuesta no aceptable». El recurso solicitado es capaz de generar sólo contenido que no es aceptable según los encabezamientos de aceptación enviados en la solicitud.
  • 407: «Se requiere autenticación de proxy». Se está utilizando un servidor proxy que requiere que el navegador se autentifique antes de continuar.
  • 408: «El servidor se agotó esperando el resto de la petición del navegador». Este código se genera cuando un servidor se apaga mientras espera la solicitud completa del navegador. En otras palabras, el servidor no recibió la solicitud completa que fue enviada por el navegador. Una posible causa podría ser la saturación de la red, lo que provoca la pérdida de paquetes de datos entre el navegador y el servidor.
  • 409: «Conflicto». Un código de estado 409 significa que el servidor no pudo procesar la solicitud de su navegador porque hay un conflicto con el recurso correspondiente. Esto ocurre a veces debido a múltiples ediciones simultáneas.
  • 410: «El recurso solicitado se ha ido y no volverá». Esto es similar a un código 404 «No encontrado», excepto que un 410 indica que la condición es esperada y permanente.
  • 411: «Longitud requerida». Esto significa que el recurso solicitado requiere que el cliente especifique una cierta longitud y que no lo hizo.
  • 412: «La condición previa falló». Tu navegador incluyó ciertas condiciones en sus encabezados de solicitud, y el servidor no cumplió con esas especificaciones.
  • 413: «Carga útil demasiado grande» o «Entidad solicitante demasiado grande». Su solicitud es más grande de lo que el servidor está dispuesto o es capaz de procesar.
  • 414: «URI demasiado largo». Esto suele ser el resultado de una solicitud GET que ha sido codificada como una cadena de consulta demasiado grande para que el servidor la procese.
  • 415: «Tipo de medios de comunicación sin apoyo». La solicitud incluye un tipo de medio que el servidor o recurso no soporta.
  • 416: «Rango no satisfactorio». Su solicitud fue por una porción de un recurso que el servidor no puede devolver.
  • 417: «La expectativa fracasó». El servidor no puede cumplir los requisitos especificados en el campo de cabecera de la solicitud.
  • 418: «Soy una tetera». Este código es devuelto por las teteras que reciben solicitudes para preparar café. También es un chiste del «día de las bromas de abril» de 1998.
  • 422: «Entidad no procesable». La solicitud del cliente contiene errores semánticos, y el servidor no puede procesarla.
  • 425: «Demasiado pronto». Este código se envía cuando el servidor no está dispuesto a procesar una solicitud porque puede ser reproducida.
  • 426: «Se requiere actualización». Debido al contenido del campo de cabecera de la solicitud, el cliente debería cambiar a un protocolo diferente.
  • 428: «Se requiere condición previa». El servidor requiere que se especifiquen las condiciones antes de procesar la solicitud.
  • 429: «Demasiadas peticiones». Esto es generado por el servidor cuando el usuario ha enviado demasiadas solicitudes en un determinado período de tiempo (con límite de velocidad). Esto puede ocurrir a veces debido a los bots o scripts que intentan acceder a tu sitio. En este caso, tal vez quieras intentar cambiar tu URL de acceso a WordPress. 
  • 431: «Campos de la Cabecera de la Solicitud Demasiado Grandes». El servidor no puede procesar la solicitud porque los campos de cabecera son demasiado grandes. Esto puede indicar un problema con un solo campo de cabecera, o con todos en general.
  • 451: «No disponible por razones legales». El operador del servidor ha recibido una demanda para prohibir el acceso al recurso que has solicitado (o a un conjunto de recursos, incluido el que has solicitado). Dato curioso: Este código es una referencia a la novela Fahrenheit 451 de Ray Bradbury.
  • 499: «Solicitud de cliente cerrada». Esto es devuelto por NGINX cuando el cliente cierra la solicitud mientras Nginx aún la está procesando.
Códigos de estado 500

Los códigos de estado de nivel 500 también se consideran errores. Sin embargo, denotan que el problema está en el extremo del servidor. Esto puede hacer que sean más difíciles de resolver.
  • 500: «Hubo un error en el servidor y la solicitud no pudo ser completada». Este es un código genérico que simplemente significa «error interno del servidor». Algo salió mal en el servidor y el recurso solicitado no fue entregado. Este código es típicamente generado por plugins de terceros, PHP defectuoso, o incluso la ruptura de la conexión a la base de datos. 
  • 501: «No implementado». Este error indica que el servidor no es compatible con la funcionalidad necesaria para cumplir con la solicitud. Esto es casi siempre un problema en el propio servidor web, y por lo general debe ser resuelto por el host. 
  • 502: «Mala entrada». Este código de error significa típicamente que un servidor ha recibido una respuesta inválida de otro, como cuando se utiliza un servidor proxy. Otras veces una consulta o petición tardará demasiado, y así es cancelada o asesinada por el servidor y la conexión a la base de datos se rompe. 
  • 503: «El servidor no está disponible para manejar esta solicitud en este momento.» La solicitud no puede ser completada en este momento. Este código puede ser devuelto por un servidor sobrecargado que no puede manejar solicitudes adicionales. 
  • 504: «El servidor, actuando como una puerta de enlace, se ha agotado esperando a que otro servidor responda». Este es el código devuelto cuando hay dos servidores involucrados en el procesamiento de una solicitud, y el primer servidor se apaga esperando que el segundo servidor responda. 
  • 505: «Versión HTTP no soportada». El servidor no soporta la versión HTTP que el cliente usó para hacer la solicitud.
  • 508: «Se ha alcanzado el límite de recursos» Se han alcanzado los límites de recursos establecidos por tu alojamiento web.
  • 509: «Límite de Ancho de Banda Excedido» significa que tu sitio web está utilizando más ancho de banda del que permite tu proveedor de hosting.
  • 511: «Se requiere autenticación de la red». Este código de estado se envía cuando la red que está tratando de usar requiere alguna forma de autenticación antes de enviar su solicitud al servidor. Por ejemplo, es posible que tenga que aceptar los términos y condiciones de un punto de acceso Wi-Fi público.
  • 521: «El servidor web está caído». El error 521 es un mensaje de error específico de Cloudflare. Significa que su navegador web fue capaz de conectarse con éxito a Cloudflare, pero Cloudflare no fue capaz de conectarse al servidor web de origen.
  • 525: «SSL Handshake Failed». El error 525 significa que el Protocolo de enlace SSL entre un dominio que usa Cloudflare y el servidor web de origen falló. Si estás experimentando problemas, hay cinco métodos para intentar arreglar fácilmente el error 525.

Basado en:
La escalabilidad es una de las características más deseables en las aplicaciones y una de las principales preocupaciones para equipos de desarrollo y administración de servidores. Básicamente, se refiere a la capacidad de crecimiento de la aplicación para atender a un número cada vez mayor de solicitudes y usuarios con total normalidad y sin degradaciones de servicio. De cara a conseguir esta deseada cualidad, existen diferentes vías que no son incompatibles: algunas más centradas en el desarrollo del software y otras en los servidores que harán de plataforma de ejecución.


Existen dos tipos de escalabilidad, la vertical y la horizontal.

La escalabilidad vertical incluye añadir más potencia a los recursos actuales, mientras que la escalabilidad horizontal significa añadir más recursos para dividir la carga. 
A continuación, una explicación mas detallada de estas.

¿Qué es la escalabilidad vertical?

El escalado vertical tiene mucho que ver con el hardware del servidor de la aplicación. Se consigue de una manera muy sencilla: aumentando los recursos del servidor. Principalmente, en lo que respecta a la capacidad de procesamiento, memoria y almacenamiento.


Este tipo de escalado es bastante sencillo de alcanzar, ya que únicamente requiere una intervención en el hardware del equipo, aumentando los recursos o incluso cambiando completamente de servidor. Sin embargo, el beneficio que se puede llegar a obtener también es limitado.

Ventajas de la escalabilidad vertical
  • Facilidad de implementación y configuración: Gestionar un único servidor suele ser menos complejo que administrar una red de servidores interconectados, lo que puede facilitar la tarea para equipos más pequeños.
  • No requiere un diseño específico en la aplicación y su arquitectura para funcionar: Puede adaptarse a sistemas existentes sin modificaciones extensas.
  • Puede ser más económico: En algunos casos, la escalabilidad vertical puede ser más económica, especialmente en entornos donde agregar recursos a un servidor existente resulta más rentable que implementar una infraestructura horizontal más amplia.
  • Mejora en el rendimiento: Al proporcionar más recursos a un servidor existente, la escalabilidad vertical puede resultar en un aumento inmediato de rendimiento, ideal para aplicaciones que requieren una gran capacidad de procesamiento.
Desventajas de la escalabilidad vertical
  • Está limitado a la capacidad de un único servidor: A medida que se escalan verticalmente, hay límites físicos para mejorar un solo servidor. Eventualmente, se alcanzará un punto en el que no se puedan agregar más recursos.
  • No aporta beneficios en relación a la alta disponibilidad: Añadir recursos a un servidor en funcionamiento puede requerir tiempos de inactividad o interrupciones temporales, lo que puede afectar la disponibilidad del servicio.

¿Qué es la escalabilidad horizontal?

Por su parte, la escalabilidad horizontal se consigue aumentando el número de servidores que atienden una aplicación. Para ello, un grupo de distintos servidores se configura para atender las peticiones de manera conjunta (es lo que se denomina cluster) y la carga de trabajo se distribuye entre ellos a través de un balanceador. Cada uno de esos servidores se conoce como nodo y el escalado se realiza simplemente agregando un nuevo nodo al cluster.


Este escalado es bastante más potente, pero sin embargo requiere una mayor configuración para poder realizarse, no solamente para crear la red de servidores de un cluster, sino también realizando una arquitectura de aplicación, a nivel de software, capaz de adaptarse a este tipo de funcionamiento.

Ventajas de la escalabilidad horizontal
  • El escalado es prácticamente infinito: La principal ventaja de la escalabilidad horizontal radica en su flexibilidad. Al agregar nuevos servidores según sea necesario, el sistema puede adaptarse a las demandas cambiantes sin interrupciones significativas.
  • Permite alta disponibilidad: Distribuir la carga entre varios servidores evita cuellos de botella y garantiza un rendimiento sostenible incluso en momentos de alta demanda.
  • Permite un correcto balanceo de carga entre los servidores: Al permitir un correcto balance de carga entre los servidores, se asegura una distribución equitativa de la carga y se evita la sobrecarga de un servidor específico.
  • Costos controlados: Aunque puede haber costos iniciales asociados con la adición de servidores, la escalabilidad horizontal tiende a ser más rentable a largo plazo, ya que solo se utilizan recursos cuando son necesarios.
Desventajas de la escalabilidad horizontal
  • Requiere mayor configuración, que puede llegar a ser difícil de realizar: La implementación de la escalabilidad horizontal a menudo requiere una arquitectura específica y una configuración cuidadosa para garantizar un rendimiento óptimo.
  • Necesidad de un diseño específico: Necesita que la aplicación esté construida de modo que soporte escalabilidad vertical, lo que puede requerir modificaciones en el diseño original.
  • Opción menos económica: Aunque más potente y de mejor rendimiento, suele ser una opción menos económica, ya que requiere de varios servidores.

¿Cómo mejorar la escalabilidad vertical y horizontal?

El cálculo del escalado de la aplicación debe comenzar en la etapa de desarrollo, atendiendo a los requerimientos. Es importante decidir de antemano qué se necesitará para conseguir un adecuado escalado y cómo se va a realizar. Se debe pensar en factores como el comportamiento del crecimiento de la aplicación y los límites de los recursos de infraestructura que podamos tener o asumir económicamente. Estas decisiones seguramente condicionen el desarrollo y marquen la necesidad de arquitecturas específicas (microservicios, REST…), de modo que el software se adapte correctamente.

En cuanto a escalado vertical, es importante saber que no siempre es posible aumentar los recursos actuales de un servidor. Por ejemplo, los Servidores Dedicados tienen pocas posibilidades de expansión y generalmente es necesario cambiar la máquina entera, con la correspondiente migración. Esto, sin embargo, no sucede con los Servidores Cloud, ya que es perfectamente posible asignar más recursos al servidor cuando sea necesario, ahorrándonos la necesidad de cambiar de máquina.

Los Servidores Cloud también facilitan mucho el escalamiento horizontal, ya que crear nuevos servidores y añadirlos al cluster es muy rápido y sencillo. La complejidad de estas configuraciones no nos tiene que asustar, pues gracias al panel de Cloudbuilder Next de Arsys es posible configurar un cluster de servidores con balanceo de carga de manera muy fácil, prácticamente a golpe de clic.

Generalmente, el escalado vertical es más que adecuado para la mayoría de las aplicaciones. Sin embargo, en ocasiones se espera un crecimiento elevado de los usuarios y, por tanto, una cantidad alta de solicitudes en un espacio corto de tiempo. En este caso, es posible que sea necesaria la planificación de una estrategia de escalado horizontal. También se debe considerar que a veces el aumento del hardware no es viable, por presupuesto o porque la mejoría no resulta lo suficientemente relevante para una aplicación. En estos casos, el escalado horizontal es mucho más seguro. No obstante, podemos acudir a estrategias mixtas, como sería separar ciertos servicios a un servidor adicional, como la base de datos. De esta manera, sin llegar a las complejidades de configuración de un cluster, podemos tener dos máquinas atendiendo solicitudes, una encargada de la parte del servidor web y otra de la base de datos.

Conclusiones sobre escalabilidad

La elección entre la escalabilidad horizontal y vertical no es solo una decisión técnica, sino una estratégica que puede impactar directamente en el rendimiento y la eficiencia de tus servidores. Ambas estrategias tienen sus propias ventajas y desafíos, y la decisión correcta depende en última instancia de las características y objetivos de tu proyecto.

Si te encuentras gestionando un proyecto que experimenta fluctuaciones de demanda y necesitas una solución flexible y rentable, la escalabilidad horizontal podría ser tu mejor aliado. Distribuir la carga entre varios servidores no solo proporciona una mayor tolerancia a fallos, sino que también permite un rendimiento sostenible incluso en momentos de mayor tráfico. No obstante, ten en cuenta la complejidad de gestión y la necesidad de una configuración cuidadosa al optar por esta ruta.

Por otro lado, si tu enfoque es mejorar el rendimiento inmediato de una aplicación crítica y buscas una gestión más sencilla, la escalabilidad vertical podría ser la elección acertada. Proporcionar más recursos a un servidor existente puede ser la respuesta cuando la demanda de recursos es predecible y fluctúa en un rango manejable. Sin embargo, ten presente las limitaciones físicas y las posibles interrupciones asociadas con este enfoque.

Relacionando estas estrategias con la gestión de dominios y hosting web, es crucial reconocer que la elección de la infraestructura subyacente puede tener un impacto significativo en la experiencia del usuario y en el rendimiento general de tu página web. Al considerar la escalabilidad, no olvides evaluar cómo estas decisiones afectarán a la velocidad de carga de tu página y a la capacidad de gestionar picos de tráfico. Un hosting adecuado y un dominio bien gestionado pueden ser la clave para aprovechar al máximo las ventajas de la escalabilidad, ya sea horizontal o vertical.

Tomado de:
Giuseppe Tartini (8 de abril de 1692 – 26 de febrero de 1770) fue un músico italiano, violinista, compositor y estudioso de la música de su tiempo (barroco). Fue uno de los mayores virtuosos del violín de su época; sus innovaciones en el estudio del violín solo fueron superadas con la llegada de Niccolò Paganini (1782-1840).


El Trino del Diablo y supuesto encuentro:
La Sonata para violín en sol menor, más conocida como “El Trino del Diablo” o “La Sonata del Diablo”, es una obra para violín solo (con acompañamiento de bajo continuo) encontrada como uno de los trabajos brillantes de Tartini, famoso por ser muy exigente técnicamente, aún hoy en día. Tartini la compuso a raíz de un supuesto encuentro con el Diablo, como le contó al astrónomo francés Jérôme Lalande, donde Lalande deja registro en su libro Voyage d'un François en Italie, según el escrito Tartini dijo:

“Una noche, en 1713, soñé que había hecho un pacto con el Diablo y estaba a mis órdenes. Todo me salía maravillosamente bien, todos mis deseos eran anticipados y satisfechos con creces por mi nuevo sirviente. Ocurrió que, en un momento dado, le di mi violín y lo desafié a que tocara para mí alguna pieza romántica. Mi asombro fue enorme cuando lo escuché tocar, con gran bravura e inteligencia, una sonata tan singular y romántica como nunca antes había oído. Tal fue mi maravilla, éxtasis y deleite que quedé pasmado y una violenta emoción me despertó. Inmediatamente tomé mi violín deseando recordar al menos una parte de lo que recién había escuchado, pero fue en vano. La sonata que compuse entonces es, por lejos, la mejor que jamás he escrito y aún la llamo “La sonata del Diablo”, pero resultó tan inferior a lo que había oído en el sueño que me hubiera gustado romper mi violín en pedazos y abandonar la música para siempre….”

Esta es la mejor pieza a nivel obra y sonata compuesta por Tartini, tanto para los críticos como para los teóricos musicales. En música se llama trino a la alternancia rápida de dos notas separadas por el intervalo de un tono (de una segunda mayor) o un semitono (una segunda menor).

Tomado de: