domingo, 20 de enero de 2013

Automatizando la Generación de la Base de Datos


Hola hoy quiero compartir una técnica que aprendí hace algunos años y que he tratado de utilizar siempre en cada proyecto en que he estado, es sobre el versionamiento de los Scripts de la base de datos y la automatización de la creación de la misma, mis ejemplos estarán en Java y Ant pero la idea se puede aplicar a cualquier Tecnología/lenguaje.

Imaginemos un entorno de desarrollo donde cada desarrollador tiene una base de datos propia en la cual desarrollar y hacer sus pruebas unitarias, y de pronto encontramos que necesitamos modificar alguna Tabla, Vista, o Store Procedure, una vez terminada la modificación tenemos que versionar el cambio; pero ¿Cómo propagamos el cambio al resto del equipo? tenemos que avisar al resto del equipo, todos suspenderían sus tareas, ejecutarían el Script de Actualizacion (si existe uno) o aplicar el backup correspondiente y cruzar los dedos para que todo siga funcionando, este es un proceso manual, engorroso, que debe ser ejecutado por cada integrante del equipo y sobre todo: Propenso a Errores, lo cual provoca que se evite al máximo los  cambios (en algunos casos se le llega a tener verdadero terror a hacer este tipo de cambios) o se llegue incluso a hackear nuestro propio código para evitar tocar la base de datos, con esta técnica bastaría con actualizar con la versión del repositorio, ejecutar la tarea de reset a la base de datos y ya tenemos nuestra base de datos actualizada con la estructura de datos necesaria para la versión del código fuente que tenemos.

Otro ejemplo es conforme se realiza el desarrollo el sistema evoluciona, las estructuras de datos cambian y se refleja en el estado del código si usamos un sistema de control de versiones (git, svn, etc) esto no representa ningún problema pues podemos viajar en el tiempo y obtener la versión que queremos en cada momento, pero que pasa si junto con los cambios en el código tenemos cambios en la estructura de la base de datos (tablas, vistas) o mas aun: en la lógica de procedimientos almacenados?, he encontrado que esto es mas común de lo que uno piensa, y terminamos teniendo el código con un buen historial pero solo la ultima versión de la base de datos, entonces si por alguna razón necesitamos una versión del código anterior, corremos el riesgo de que esta no funcione pues no tendrá la estructura de tablas o procedimientos almacenados con la cual funcionaba correctamente en su momento

Una vez que consideramos esto y lo versionamos necesitamos alguna forma de poder hacer este despliegue de forma rápida, tal que si necesitamos regenerar la base de datos no tengamos que ejecutar backups o hacer una ejecución de scripts a mano, copiando y pegando a alguna herramienta visual, o escribiendo los scripts de ejecución desde 0 cada vez

entonces comencemos:

martes, 7 de agosto de 2012

Computacion en la nube explicada a través de la analogía de la Cena de Acción de Gracias.


Hola a todos, esta vez he traducido un excelente artículo de JP Morgenthal que encontré en InfoQ sobre computación en la nube, el articulo original lo pueden encontrar aquí:

Infoq: Cloud Computing Described Through The Analogy of (US) Thanksgiving Dinner

quiero agradecer a JP autor del articulo y a Roxana Bacila facilitadora de los aportes comunitarios de InfoQ por dar los permisos necesarios para que podamos leer esto aqui, a ambos: Muchas Gracias!!!

Pregúntale a una persona técnica lo que es la computación en la nube y obtendrás en mayor parte una respuesta poco consistente que en algunas partes incluye los términos "elástico", "agilidad", "amplio acceso a la red", "dinámico", y "medible". Sin embargo, para la mayoría de las personas buscando entender el rol que la computación en la nube, juega en sus entornos de TI, estas definiciones realmente no responden la pregunta. Esto es por lo que se desarrolló una analogía basada en la cena de acción de gracias, para ayudar a introducir los conceptos de computación en la nube. Hasta ahora esta analogía ha funcionado muy bien en discusiones con clientes para crear una visualización de que intentamos adquirir con la nube y por que es diferente a lo que las aras de TI esta haciendo tipicamente hoy en día.

viernes, 29 de junio de 2012

Dojos y niveles


Esta es una reproduccion de mi articulo en el blog: Software Craftsmanship Peru

Hola, en la comunidad Agile Peru se organiza muchos dojos, de hecho se viene una semana de dojos facilitados por diferentes miembros de la comunidad,  he visto que se están armando con niveles (básico, intermedio y avanzado) (actualizacion: se han retirado los niveles) pero no se ha indicado en que consisten estos niveles, esto es un poco difícil pues los dojos son para aprender/practicar algo, y esto es muy difuso pues este algo puede ser desde un lenguaje, framework o técnica pero seria bueno tenerlo en algún lugar para saber si estoy interesado y cual me conviene mas

Sin embargo creo que principalmente nos centramos en habilidades de programación asi que quiero proponer una escala:

domingo, 3 de junio de 2012

Tesla: El geek mas grande de todos los tiempos

Encontré en microsiervos este homenaje que los muchachos de The Oat Meal han hecho a Nikola Tesla uno de los mayores inventores de la historia y también de los mas robados pues el crédito de casi todas sus invenciones fueron atribuidas a otras personas entre ellas:

La Radio -no, no fue Marconi-
Los Rayos X -no, no fue Rontgen y en honor a la verdad tesla no los descubrio pero inicio la investigacion en ese campo dejandola pues los consideraba peligrosos para el hombre y saben que? lo son.-
Fue el padre de la era electrica -no, jamas en ningun universo posible fue Edison-

De hecho Edison aparentemente invento muy poco de lo que se le atribuye, simplemente contrato mucha gente para trabajar en investigación y el patentaba los logros descubiertos (suena familiar a la forma en la que trabaja cierta empresa con una fruta por logo?)

según citan la rivalidad entre ellos llego tan lejos que Edison llego a pagar a los chicos de su vecindario para que le lleven perros y gatos a los cuales poder electrocutar en publico y generar temor hacia la corriente alterna desarrollada por Tesla.

lamentablemente murió pobre y solo en un hotel en Nueva York.

realmente no tiene pierde y si te consideras un aficionado minimo a la tecnologia no puedes dejar de leerlo:

http://theoatmeal.com/comics/tesla

hay muchas cosas ciertas incluyendo varias criticas al papel de Edison como empleador y quien robara muchas de las creaciones de Tesla
Algunas extractos:
  • Un Geek es alguien que desarma el mundo para después volverlo a armar con nuevas características.
  • Un Geek repara cosas que ni siquiera estaban descompuestas.
  • Edison no era un Geek era un CEO. 
  • Tesla era conocido por inventar cosas geniales y después olvidarlas, Edison por correr a la oficina de patentes cuando alguno de sus empleados inventaba algo nuevo.
  • Tesla era un jodido genio (y si, yo agregue lo de jodido y en mas de un sentido)

sábado, 2 de junio de 2012

Gears Of Wars: Judgment

Desde que en la oficina tenemos Xbox 360 y que los unicos juegos que tenemos eran Gears of War 1 y 2 me he vuelto fan de la saga, no solo por la buena jugabilidad si no por el buen guion que tienen los personajes en particular el sentido del humor de los personajes secundarios: Augustus 'Train' Cole ex estrella de trashball y Damon Baird un soldado bastante cinico pero muy bueno para las reparaciones de emergencia.

pues bien al parecer en este E3 se hara publico un trailer sobre esta nueva saga todo parece apuntar que estamos frente a una nueva trilogia que sera estelarizada por estos dos personajes y que estaria a cargo como siempre de Epic Games y desarrollado por "People can fly" (quienes estan contratando por cierto asi que si tienes ganas de probar suerte pues puedes escribirles) desde gameinformer han soltado 2 imagenes como adelanto que muestran a ambos personajes esposados y acompañados por soldados de la CGO aqui las imagenes (click para verlas en mayor tamaño)



Nuevo trailer : Tomb Raider

Después de mucho tiempo pongo una entrada sobre mis pasatiempos asi que sera sobre uno bastante comun :D VideoJuegos

Los chicos de Square Enix han lanzado el trailer para la nueva edicion de la saga de Lara Croft : Tomb Raider "Crossroads"

Las imágenes se ven espectaculares esta vez todo inicia cuando Lara ha sido capturada e intenta huir haciendose con todo el equipo que pueda por si misma: arco y cuchillo, me ha gustado especialmente el ver un heroe en los momentos en que se siente en shock, desvalido y sin saber como escapara de esta o si podrá hacerlo 




Tambien puedes entrar al canal de Tomb Raider en Youtube

Usar ORM o SQL Plano?

Hola este es un post que escribo a Raíz de una consulta que se lanzó en el la lista de correo ITP-Java, pueden ver el hilo aquí:

La consulta en cuestión eran las principales diferencias entre usar un framework ORM o acceder directamente a través de SQL a la base de datos y las ventajas de uno u otro enfoque

La principal diferencia entre ORM y SQL es el hecho que ORM mapea las entidades del mundo relacional (También conocidas como Tablas, la mayoría) hacia objetos del mundo orientado a Objetos.

De la misma forma desde mi punto de vista una de las principales ventaja que encuentro, es que cuando ejecutas un query, ya no tendrás que revisar el modelo para recordar las tablas involucradas en el query, con orm puedes basarte en las relaciones entre tus objetos, usar polimorfismo e igualdades entre objetos, etc.

Otra ventaja es el nivel de granularidad que puedes lograr en el mundo relacional tienes solo 2 niveles: Tabla y Columna por ejemplo si quieres acceder a otras entidades tienes que aplicar joins, para acceder a toda la información que necesitas (del álgebra booleana si no te salvas aunque con orm se reduce bastante la complejidad de esta) además del cambio de contexto pues debes dejar de pensar en objetos y cargar el paradigma relacional

por ejemplo si tenemos una tabla salón que tiene una columna con el numero de salón y queremos el salón 304 haríamos algo como esto:


simple, pero como mencione si tenemos que agregar mas entidades veremos como la complejidad de la sentencia crece al agregar joins tomar en cuenta las columnas igualdades etc.

Por otro lado imaginemos que un horario se lleva a cabo en un salón si queremos saber todos los horarios que se llevan acabo en el salón 304 en hql (el lenguaje de querys de hibernate) simplemente tenemos que hacer:


donde "h" es el alias para el la clase "Horario" la cual tiene un atributo "salon" el cual tiene un atributo "numero" y ese es el que igualamos a 304. Como se puede ver en este tipo de querys puedes "navegar" por los niveles de tu red de objetos tanto como lo desees y delegando al framework de persistencia el construir la sentencia sql necesaria para representar la búsqueda esto además evita que tengas que cambiar del contexto orientado a objetos al contexto relacional

Explicada esta ventaja menciono las otras ventajas que considero importantes:


  • Consultas en el el mundo orientado a objetos
  • Puedes manejar conceptos como herencia y polimorfismo en las clases que representan las entidades
  • Puedes manejar relaciones bidireccionales en las clases que representan las entidades es decir: que en el lenguaje relacional, una tabla conoce que tablas esta referenciando pero no puede saber que tablas la referencian; sin embargo cuando hablas de objetos una Clase puede tener un atributo para la clase referenciada y la clase referenciada puede tener un arreglo de todas las clases que la referencian
  • Portabilidad orm es agnóstico del dialecto sql, esto es que , al ser el framework quien genera las sentencias sql y tu usar un lenguaje intermedio para tus consultas, puedes portar tu aplicación entre diferentes motores sin modificar tu capa de persistencia


Pero como todo en la vida lo bueno tiene un precio y orm no es la excepción:

  • Al ser el framework quien genera las sentencias sql debes estar atento a consultas muy pesadas que se puedan generar por un mal mapeo de las entidades y que estas usen demasiados joins (podrías terminar haciendo un join con 7 tablas cuando lo único que querías es la descripción del objeto)
  • La performance es mas baja que accediendo directamente a la base de datos pues estas incluyendo una capa que podría no ser necesaria, si la persistencia y el modelo de datos no es complejo, digamos que una aplicación que solo requiere hacer inserciones o búsquedas simples sobre un modelo sin muchas relaciones podría ser mejor hacerla en sql plano
  • Dependiendo del framework que uses también puedes hacer consultas en sql nativo sin embargo no recomiendo abusar de ello , si se cae en eso se debería reevaluar la razón por la que se decidió usar un framework orm pues no se esta aprovechando o simplemente nunca tuvo sentido.
si te he convencido y quieres empezar a ver algunos frameworks pero no sabes cuales existen en tu lenguaje aqui puedes encontrar algunos frameworks ORM en diferentes lenguajes gracias a wikipedia