viernes, 2 de septiembre de 2022

MySQL - Procedimientos y Funciones con parámetros opcionales

Si usas procedimientos y funciones de base de datos en MySql o Sql, que reciben parámetros y  que son llamados desde código back (por ejemplo, PHP), o desde cualquier otro lenguaje, habrás notado que, en más de una ocasión, si has decidido añadir un parámetro, o bien has creado un procedimiento o función alternativa (para que no se joda el código ya escrito) o has tenido que revisar todo el código back para añadir, aunque sea con vacío o null, el parámetro en cuestión.

Y habrás pensado... "ya podía tener SQL, al estilo de javascript, php y otros lenguajes, la posibilidad de crear un parámetro con un valor por omisión por si este no es suministrado", lo que viene a ser... un parámetro opcional. 

Por ejemplo, vamos a utilizar un procedimiento muy sencillo que recibe dos parámetros de cadena, devolviendo sus valores.
  CREATE PROCEDURE localdb.parameters_test(p1 varchar(10),p2 varchar(30) )
  BEGIN
      select p1,p2;
  END
  
Si en este caso hacemos...


	call parameters_test("hello","bye");
    
    
    
p1p2
hellobye
Si ahora cambiamos el procedimiento a... CREATE PROCEDURE localdb.parameters_test(p1 varchar(10),p2 varchar(30),p3 varchar(10) ) BEGIN select p1,p2,p3; END Pero no cambiamos la llamada, obtendremos un error. ¿Cómo podemos entonces usar procedimientos y funciones de bases de datos, donde, dentro de su código obtengamos parámetros opcionales, incluso de valores de tipo indefinido? Sí, ya sé que ahora la tendencia es usar el tipado de datos en todo momento, igual que desde 1998 al 2004 aproximadamente, se recomendaba usar las Foreign Keys para conservar la integridad de las tablas, mientras que después se puso de moda mantener la integridad en el código y no usar las claves relacionadas, o Foreign Keys. Y ahora muchos utilizan ya No-SQL para no definir una estructura rígida de base de datos. Todo este tipo de prácticas son a elección del analista, que ha de tener en cuenta si se desea una integridad robusta, un desarrollo de código más ágil, y mil variables más. Como anécdota os contaré que muchos entendieron lo de "ahora no se lleva crear claves relacionadas/foreign keys" y terminaron por no usar índices clave. Sí. Ya imaginarás la de bases de datos que he tenido que indexar y reindexar porque, a cierto volumen de datos la consulta se hacía eterna. En SQL, usad claves, por favor! Dicho esto... al grano.

Parámetros Opcionales en SQL/MySQL

Para "simular" y controlar los parámetros en funciones y procedimientos de base de datos, haremos uso del comando EXTRACTVALUE, que viene a ser como un "lector" o "intérprete" de valores XML. En el siguiente ejemplo básico, lo entenderás claramente.


  CREATE PROCEDURE localdb.parameters_test(pAll varchar(300))
  BEGIN
      set @p1 = (select ExtractValue(pAll,"p1"));
      set @p2 = (select ExtractValue(pAll,"p2"));
      select @p1,@p2;
  END
  



	Call parameters_test("<p1>Hello</p1><p2>Bye</p2>");
    
    
    
    
p1p2
HelloBye
Y si ahora cambiamos el procedimiento para aceptar un nuevo parámetro, no será necesario cambiar nada en el código back (o fuente o como quieras llamaro). CREATE PROCEDURE localdb.parameters_test(pAll varchar(300)) BEGIN set @p1 = (select ExtractValue(pAll,"p1")); set @p2 = (select ExtractValue(pAll,"p2")); set @p3 = (select ExtractValue(pAll,"p3")); select @p1,@p2,@p3; END Call parameters_test("<p1>Hello</p1><p2>Bye</p2>");
p1p2p3
HelloBye
Por supuesto, dentro del procedimiento o función, debes comprobar tanto el tipo, el valor y si existe o no el parámetro pasado para hacer que tu código sea comprensible y útil. Pero eso es a tu elección y a la de tu equipo (si lo hay).

martes, 23 de agosto de 2022

Scrum, Sprints, Estimaciones y Fanfarrones

¡Al tema! ¡Y vaya tema!

Cada año, en una extraña herencia de las dietas milagro, aparecen en el ámbito empresarial, y adoptado especialmente por el sector tecnológico, fórmulas mágicas que prometen ser una revolución. Unido a esto, hay quien; por asistencia a una conferencia, descubrimiento fortuito o conversación de café (con o sin misterio) con un compañero de puesto similar en una empresa mayor; se "empapa" o se lo mira por encima o se crea un concepto en su cabeza, llega a la oficina y dice: ¡Eureka!
Seguramente habrás oído hablar de, o sufrido, el método Scrum o similar. Son métodos de trabajo, realmente aplicado a cualquier sector, orientado a grupos, en principio, con un proyecto común cuyas tareas son dependientes.

En muchos casos asistirás, o habrás asistido, a reuniones dónde realmente cada profesional se ocupa de un sprint (el tiempo estimado para ese grupo de tareas), aunque por alguna razón el "especialista" de turno ha mezclado en un sprint tareas no dependientes, de ahí que diga que cada profesional se ocupa de un sprint. La reunión se hace eterna, pues realmente se está haciendo una reunión con los presentes sin estar todos involucrados en el mismo proyecto o que no tienen tareas dependientes. 

La empresa acaba de ser víctima de un fanfarrón, y tú acabas de sufrir las consecuencias. Pues esa palabra que el "especialista" escuchó y que le llevó a decir "Eureka!", se ha convertido en un absurdo método de control y de examen estresante de aptitudes.

Si en este punto has entendido algo, es que lo has sufrido. Bienvenido a la era de la fanfarria tecnológica.

En caso de que se aplique de forma correcta una metodología ágil como Scrum, entramos en un terreno pantanoso si hablamos de servicios, especialmente si hablamos de desarrollo informático.

Una de las bases de este tipo de metodologías es la estimación de tiempos. Y eso, en desarrollo informático, es un problema.

Veamos cómo sería la estimación de tiempos en un carpintero.

A un carpintero le piden hacer una silla. Con una madera, barniz y forma concretas. El carpintero no ha realizado nunca esa especificidad. Al carpintero le hacen la pregunta: ¿para cuándo estará?. El carpintero tiene esa madera. Si no la tuviese tendría que buscarla y hablar con proveedores conllevando un tiempo indeterminado. Pero afortunadamente para nuestro implicado, tiene la madera que se ha solicitado. 

¿Cuánto tardará? Él ha trabajado esa madera, y en hacer una silla tarda 3 días. Pero el diseño lo desconoce, por lo que responde: "6 días". 

El carpintero se encuentra con que ciertos aspectos del diseño, con esa madera concreta, no son viables. Ha tenido que hacer algunas pruebas que le han retrasado un día. Al final comprueba que para algunos elementos necesita cambiar la madera. Escribe un email (es un artesano moderno) al cliente que le responde un día después, aceptando el cambio de madera en esos elementos. 

El carpintero, al barnizar con el líquido especificado, descubre que éste, que también lo tenía, se comporta de forma diferente en cada tipo de madera. Por lo que necesita cambiar el tipo de barniz, escribiendo nuevamente al cliente. El cliente responde en dos días admitiendo el cambio. 

El carpintero entrega el trabajo a los 8 días. En este caso ha tenido suerte y el cliente (o jefe de proyecto) entiende la circunstancia. 

Al mes siguiente, llega otro cliente que pide un diseño muy parecido al anterior, con la misma madera y el mismo barniz. El carpintero le informa de los cambios que serán necesarios, y ante la pregunta de "¿cuándo estará?", el carpintero responde 5 días, entregando el trabajo en 3 días. 

¿Se entiende? Bien. Normalmente un desarrollador informático no repite una tarea. Es más; un buen programador/analista informático reutilizará hilos de código (clases, rasgos, etc.), cuya preparación inicial conllevará un tiempo indeterminado en pro de un ahorro de tiempo posterior. Y teniendo en cuenta esto, ¿cuál crees que debería de ser la respuesta a la pregunta de cuándo estará?.

Este es el gran problema que se encuentra un programador, analista o cualquier puesto que necesite hacer un estudio previo ante una tarea desconocida ante la estimación de tiempos. Cualquier desarrollador sabe que, excepto las tareas de mantenimiento con error localizado, algo que estimas en cinco días puede estar en dos horas o en un mes.

Algo que, sin duda, jamás entenderá el fanfarrón de metodologías ágiles que utiliza como control de personal y que le hace sentirse útil con la convicción de que, si no fuese por él, la empresa no saldría adelante. 

Hay muchos tipos de trabajadores en todas las empresas y sectores. Unos aportan rapidez, otros excelencia y otros creatividad. Un jefe de proyecto que no sabe sacar partido de su equipo no está haciendo su trabajo correctamente. Por muy al día que esté en dietas milagro.