Iver's web place

• Ponerse o no desodorante.
• Poner o no poner una coma.
• Ponerle o no ponerle .... el siguiente texto a una frase =D
• Declarar una variable con un tipo de dato correcto

El caso de las bases de datos no es la excepción y en muchos casos suele traer graves consecuencias el no haber declarado una variable con el tipo de dato adecuado. Para ser más claro, si uno declara un campo de una tabla que será nvarchar en lugar de varchar, a simple vista esto no afecta porque ambos son de texto, ¿Pero que pasa si la tabla será de hechos? Osea que la tabla sea parte de un Data Warehouse y tenga miles de millones de registros y nosotros por simple weba/flojera/pereza/valemadrismo simplemente no tomamos en cuenta que tipo de dato declaramos ... y "adentro!". Después de unos meses nos damos cuenta que la tabla ocupa mucho espacio en disco.

El problema no es solo un campo, el campo es uno de los problemas ya que cada campo está declarado como nvarchar(200). Tan solo hay que ver la diferencia entre varchar y nvarchar ... osea la "n" .. jaja >P. Veamos más a fondo el desmadre ocasionado:

En diversas ocasiones nos encontramos con que el código que hemos escrito ya no cumple con las mejores prácticas de desarrollo o bien desde un principio decidimos solucionar una incidencia de la forma más rápida posible. Esto ocasiona que llenemos de basura el código que tanto trabajo cuesta mantener haciendo cada vez más difícil su entendimiento y sobre todo la transferencia de conocimiento.

De este tipo de escenarios es que surge el refactoring y cada que hacemos refactoring debemos cuidar que el código siga funcionando tal y como lo hacia antes. Para estos casos lo mejor es apoyarnos en herramientas que harían un gran trabajo al indicarnos automáticamente como podemos reemplazar los métodos de forma ágil, entre ellas contamos con:

• Resharper
• Refactor Pro
• Visual Assist X

Aunque por cuestiones de licencia y otros pequeños detalles, lo mejor será que tengamos buenas prácticas y el hábito de revisar nuestro código. Con la ayuda del atributo Obsolete podremos dar seguimiento a aquellos métodos que requieran un refactoring, sobre todo si estamos trabajando en un equipo de desarrollo y encontramos que uno de nosotros hizo un método al estilo:

Nota: el ejemplo ha sido obtenido del blog de Lucas Ontivero.

Lo primero que podríamos hacer para marcar que vamos a refactorizar el método es agregando el atributo como [Obsolete], podemos hacerlo de 3 formas:

Lo anterior manda un mensaje de aviso ("warning") al compilar el código y nos permitirá ver donde se está invocando cada método. En particular me agrada más usar el tercer ejemplo donde se utiliza un mensaje personalizado para aclarar su uso y como reemplazarlo.

También podemos agregar una bandera al atributo que nos muestre si causará un warning o un error al compilar el código, esto ayuda en equipos de desarrollo para comunicar al equipo que será reemplazado ("warning") en un futuro cercano y que deben cambiar su código. En caso de que se deba obligar al equipo a cambiarlo, solamente debemos agregar el valor de "true" y esto generará un error del compilador.

Se puede obtener más información sobre refactoring en el blog de Martin Fowler y el sitio de refactoring que ha montado ya que ahí tiene un catálogo para ayudarte en la tarea.

Esto de tener que procesar constantemente cubos OLAP, ver trazas, cancelar procesos y esas cosas me ha generado algo de interés sobre que tanto puedo hacer con scripts XMLA, así que hoy se me antoja poner un pequeño resumen de lo que se puede hacer con XMLA de forma resumida y con ejemplos.

No pondré descripción de los objetos y ñoñeces que no tengo muchas ganas de escribir. =P

Primero pondré el script de como obtener información de las sesiones en la base de datos, hay que tomar en cuenta que se debe ser administrador del sistema para poder ejecutar la consulta o simplemente no te dirá nada.

Ahora un script para cancelar peticiones hechas al servidor, para esto es necesario conocer el session id o el connection id que proporciona el script anterior.

Otro script útil puede ser el de limpiar la cache, para lo cual ejecutamos.

Por útilmo pondré el script que puede interesar más, el de ejecución del cubo.

Si, eso es! ... como cualquier ejemplar de la especie humana de sexo masculino (ok, no discriminemos, igual las les, bi y hetero) que aprecie la belleza de las féminas, me declaro susceptible a la esencia de una mujer o a su perfume.

Que agradable es percibir el aroma de una mujer cuando pasa cerca de ti, cuando te saluda, te besa, se sienta a tu lado o un sin fin de sucesos que pueden despertar tu interés en el momento, si no te habías percatado de su presencia con anterioridad, en ese momento te obligue a voltear en su dirección para saber el origen del aroma.

¿Y a que viene todo ese rollo del aroma? Resulta que encontré un texto escrito por Martin Fowler que menciona un termino llamado "Olor en el código" (CodeSmells) y se me ocurrió escribir una entrada en mi blog que me permita expresar lo que pienso de un buen desarrollo de software basando mis comentarios en el texto que encontré de Fowler.

Dicen algunos amigos que suelo ser muy criticon, realmente no tengo nada que decir al respecto. Si ellos lo dicen, ha de ser verdad (me queda de consuelo que suelo ser más critico con mi persona que con los demás =P ). Así que aprovechando que critico muchas cosas (objetivamente), el código no puede ser la excepción ya que es a lo que dedicamos muchos de nosotros (informáticos) la mayor parte de nuestro tiempo. ¿Te imaginas que el código fuera tan agradable como el aroma de una mujer? Que cuando lo veas puedas decir, me gusta, quiero saber quién lo escribió, quiero conocer como decidió el autor que debía estructurarse así para que yo lo pueda leer sin pasar horas rastreando variables, métodos, instancias y artefactos fumados. Que no necesite documentación para saber que el código hace lo que debe de hacer. Que simplemente el código me susurre al oído como si quisiera seducir mis sentidos y hacerme parte de él. Te sugiero leas el artículo de Fowler, lo tienes en inglés y español. Se despide, /me ... disfrutando de sus problemas =).

Desde hace unos años, me doy cuenta que cuando mejor hago las cosas es cuando tengo más problemas. Con el siguiente extracto escrito por Albert Einstein puedo confirmar que, la necesidad te ayuda a mejorar.

La crisis es la mejor bendición que puede sucederle a personas y países porque la crisis trae progresos. La creatividad nace de la angustia como el día nace de la noche oscura. Es en la crisis que nace la inventiva, los descubrimientos y las grandes estrategias. Quién supera la crisis se supera a si mismo sin quedar "superado". Quién atribuye a la crisis sus fracasos y penurias violenta su propio talento y respeta más a a los problemas que a las soluciones. La verdadera crisis es la crisis de la incompetencia. El problema de las personas y los países es la pereza para encontrar las salidas y soluciones. Sin crisis no hay desafíos, sin desafíos la vida es una rutina, una lenta agonía. Sin crisis no hay méritos. Es en la crisis donde aflora lo mejor de cada uno, porque sin crisis todo viento es caricia. Hablar de crisis es promoverla, y callar en la crisis es exaltar el conformismo. En vez de esto trabajemos duro. Acabemos de una vez con la única crisis amenazadora que es la tragedia de no querer luchar por superarla.

Y tu, ¿Obtienes lo mejor de ti mismo cuando tienes problemas? ¿Te la pasas quejando de lo mal que te va? ¿Todo te molesta? ... no, no te voy a recomendar a neuróticos anónimos. Solo era curiosidad, total, existimos otras personas que si disfrutamos la vida aún con todo y los problemas que se nos presentan. Eso "my friend" es lo sabroso de la vida!.