David Cifuentes

SFF Otún Quimbaya

2011-06-27T19:24:00.001-05:00

Todo empezó hace más de un año cuando compre el libro de Parques Naturales, ojeándolo noté que existía un área protegida por la zona cafetera que ofrecía servicios de ecoturismo, desde entonces tuve ganas de venir pero por cuestiones de trabajo y por el clima invernal no había logrado concretar nada. Este fin de semana que acaba de pasar se presentó la oportunidad perfecta, un viaje de trabajo a Medellín, sumado a un puente festivo. En primer lugar y para mi sorpresa el viaje Medellín - Pereira es más largo de lo que pensaba, más de 4½ horas, la carretera estrecha llena de curvas muy cerradas, sobre todo al inicio; con muchos accidentes, alcance a contar cinco, muy fuertes coincidían en ser casi todos de Toyota Prado, también había un taxi, mulas subiendo y bajando, sólo pensaba en lo difícil que debe ser la manejada y que no nos fuera a pasar nada a nosotros. A la entrada de Pereira se ve el imponente viaducto que la conecta con Dos Quebradas, lastima que esté todo enrejado y no deje ver la panorámica, también lástima el nombre que le eligieron, pero bueno, no voy a entrar en política.

Caminando por Pereira me sentía como en casa, en el centro bastante comercio en las calles, la plaza de Bolivar estaba colmada de gente y aunque todavía era Viernes ya se sentía todo de fiesta. Los parques grandes y verdes como deben ser. El MegaBus, casi igual al transmilenio, atraviesa la ciudad en ambas direcciones en pocos minutos, los buses son idénticos, de hecho los de ambos son fabricados en Pereira por la empresa busscar, las estaciones ligeramente más angostas pero el mismo concepto.

Al siguiente día madrugué, el transporte hace su primera salida desde el centro de Pereira (Carrera 12, Calle 9) rumbo a la vereda El Cedral a las 7:00AM. El vehículo es una chiva tradicional, sí, la que lleva gallinas, gente montada en el techo y sobrecupo saliendose por las ventanas. El Trayecto dura casi 1½ horas hasta la vereda La Suiza, donde se localiza el Santuario de Fauna y Flora Otún Quimbaya, primero se pasa por una casa pequeña que es la estación de los guardaparques y luego se ven dos grandes cachas, de fútbol y de basquet y el letrero en madera del parque.

Los precios son razonables: 5000 la entrada, 30000 por día de alojamiento (cuarto privado con baño) y la comida 6000 desayuno y 9000 almuerzo y cena, bastante decente el comedor y la comida por cierto. En realidad la infraestructura para visitantes es muy buena, tienen hasta mesa de ping-pong (desafortunadamente nadie para jugar), le oí a algún funcionario presumir que en la figura de ecoturismo comunitario SFF Otún Quimbaya era de los mejores.

A esos precios hay que sumarle el servicio de guía 30000 para la interpretación de los senderos, estuve de buenas y encontré siempre otras 2 partes para dividir la cuenta. Los senderos bien demarcados donde se necesitaba había pequeños puentes e incluso escaleras.

La historia cuenta que anteriormente existía allí una gran hacienda de una familia muy poderosa de la región, fruto de la colonización antioqueña esta gente tumbó todo el bosque virgen principalmente para vender las maderas, extremadamente finas, entre ellas el comino. En fin, en un esfuerzo por garantizar el recurso hídrico para Pereira mediante la protección de la cuenca alta y media del río Otún, el inderena decidió comprar los predios en los años 50’s y posteriormente en el 96 fue nombrado por parques como área protegida en la figura de Santuario de Fauna y Flora con el fin de proteger su diversidad en esta pequeña área de 500 hectáreas. Por su pasado oscuro, casi todo el área corresponde a un bosque secundario, a excepción de las “cuchillas” o los filos de la montaña, donde todavía hay especies nativas. Algo muy interesante de este parque es que hace parte de un corredor biológico que se conecta con otros parques nacionales y regionales como lo son: Barvas Bremen (Quindío), Campo Alegre (Santa Rosa de Cabal), Ucumarí y PNN Los Nevados.

El primer sendero que hice recién llegado tiene por nombre “Los Bejucos” llamado así por la presencia de éstos en la parte alta del camino. Lo primero que impacta son: la casa del perro, el baño romano y el lago, muestra del poder de la adinerada familia. El ascenso no es mucho y sí se alcanzan a apreciar varias especies de aves, es bien corto 1 Km circular y la guía hizo pausas constantemente, tiempo total 1 hora.

Apenas llegué tuve la oportunidad de ir a visitar la cascada de Los Frailes, con un grupo de estudiantes que venían del SENA de Manizales, muy amablemente me dieron el cupo de uno de sus estudiantes, ya que para visitar este sendero hay que tener permiso especial. Este es un sendero un poco más largo, 1½ horas. Vale la pena completamente, la cascada es de gran altura y aunque no es la más caudalosa produce respeto. Esta zona se caracteriza por sus lluvias esporádicas, por lo que una pareja de pereiranos me ofrecieron prestado un impermeable que luego me regalarían. En la noche todo es silencio y oscuridad.

Al siguiente día me levanté lleno de energía, listo para el reto que traía en mente, caminar hasta la base desde donde se inicia la épica caminata a la laguna del Otún, este lugar se llama La Pastora y queda a 12 Km del SFF OQ, todo el camino se va bordeando el rio Otún. La primera parte del camino, desde La Suiza hasta El Cedral, es una carretera destapada en buen estado, plana y rodeada de vegetación exhuberante, son 6 Km que fácilmente se hacen en 1 hora. De El Cedral a la Pastora empieza a ponerse complicado, es un camino de herradura con mucha piedra (resbaloza), húmedad y barro. En resumen, un camino dificil. No me imagino ese mismo camino con una maleta con provisiones para días sumado al peso de la carpa. Debe ser otra cosa. Este camino también son 6Km pero la duración son más o menos 2½ horas. En la Pastora se inicia el ascenso a laguna del Otún (8-12 horas), algún día lo haré, algún día.

Ya para finalizar mi visita y devolverme, tomé el Sendero El Humedal, unos 1.8 km, circulares. El sendero empieza en el humedal, donde hay un punto muy tranquilo lleno de helicóneas, finaliza en un bosque donde fueron plantados Cedros y Urapanes. Ya para volver a Pereira, me pasó algo muy curioso, estaba esperando la chiva cuando pasa una camioneta 4x4 con platón y me ofrecen “bajarme” yo claramente lanzo mi maleta y me subo; a la altura de La Florida para la camioneta en el camino y la señora que iba manejando me compra un vaso de plástico con yogurt casero, ha sido lo más delicioso que me he tomado.

Y así termina esta solitaria aventura, otro parque natural más que he podido visitar y disfrutar. Después de todo me alegra haberlo hecho, la conclusión es que tengo que volver. Desde ya voy a empezar a planear la subida a la laguna del Otún, tiene ese misterio y esa magia que tarde o temprano me obliga y me va hacer volver.

Certificación Especialista en Implementación de Google Apps

2011-02-23T22:56:00.000-05:00

En el día de hoy fue anunciado un nuevo programa de certificación para implementadores profesionales de Google Apps con título "Google Apps Deployment Specialist" algo como " Especialista en Implementación de Google Apps", la cual va más allá de un entrenamiento teórico a toda una serie de evaluaciones basadas en la experiencia de implementar la solución de Google Apps en gran variedad de proyectos exitosamente.

Como líder del equipo de implementación en Eforcers, tengo la confianza que el certificarnos va a ser un paso natural para reivindicar al mercado nuestra posición de pioneros y expertos en esta innovadora plataforma, además es un mecanismo que le da la certeza a los clientes de medir a individuos y empresas implementadoras de una forma clara, transparente y objetiva usando la misma escala de evaluación.

El examen no va a ser fácil, son muchos temas los que abarca y cada uno de ellos puede ser tan complejo como se quiera, además, el formato usado es bastante estricto, utiliza vigilancia con una cámara especial, biometría entre otros; de hecho es el mismo sistema (Kryterion) utilizado por las universidades más prestigiosas de Estados Unidos para sus exámenes de admisión y educación a distancia. Pero más importante que esto, estoy seguro que el conocimiento técnico y humano que nos ha dado la experiencia durante estos años va a jugar un papel fundamental para mi certificación y la del equipo.

Vamos a ver, por lo pronto ya ordené la cámara, es hora de repasar los materiales una vez más y les estaré contando como me va. A ustedes, también los invito a participar y por que no, a lo mejor podríamos trabajar juntos.

http://certification.googleapps.com/

Google I/O 2010

2010-05-23T21:19:00.000-05:00

Otro año más y nuevamente tuve el privilegio de asistir a la conferencia más grande de Google para desarrolladores en el West Moscone Center en la ciudad de San Francisco, California; representando en primera instancia a mi empresa, Eforcers S.A y en segunda instancia a mi país, Colombia.

La conferencia es de caracter altamente técnico y esta enfocada en mayor proporción a contenidos avanzados para desarrolladores en cada una de las tecnologías de Google. Esto significa que es un evento más "geek" que de gente con traje. 5000 es el número estimado de asistentes.

Google aprovecha esta conferencia para demostrar todo su amor a su comunidad de desarrolladores con uno, o esta vez con dos regalos increíbles. Varios meses antes de iniciar I/O, todos los asistentes recibímos un correo anunciando que se nos iba a entregar el Google Nexus One, por correo o reclamarlo durante el registro en la entrada al evento. La sorpresa fue cuando anunciaron que también recibiríamos el nuevo HTC Evo 4G con 1 mes gratis de servicio con Sprint, ahí si se puede decir que la sacaron del estadio. Eso sin mencionar todas los demás gestos de gratitud, lease: camisetas, stickers, medias (sí, un par de medias), excelente comidas, bebidas y una fiesta impresionante.

Por otro lado, Google utiliza este evento para hacer sus más grandes anuncios y los lanzamientos de nuevos productos, servicios y tecnologías en general. Un ejemplo de esto es Google TV, una nueva manera de ver televisión trayendo toda la Web a la sala y con ella todas sus ventajas: como la facilidad de buscar, contenidos e interactividad. Google TV está es una fase temprana y todavía hay mucho camino por recorrer, sin embargo es un proyecto bastante ambicioso y definitivamente va a cambiar la manera es que consume el entretenimiento.

En la división de Google Enterprise, la más relevante personalmente ya que es mi vida cotidiana con Eforcers, también hubo movimiento con el anuncio de Google App Engine for Business, que le da a las empresas una "versión" más robusta y empresarial de la popular plataforma de desarrollo y despligue de aplicaciones en la nube; eso sin contar la alinza que anunciaron con VMWare y la integración entre GWT y Spring Roo. Hubo otros anuncios importantes relacionados con Google Apps, como lo fueron la disponibilidad de Wave en dominios Apps y las nuevas funcionalidades de Google Apps Script. Definitivamente este ha sido el año donde han habido más sesiones dentro del track empresarial y colegas nuestros en el sandbox.

Cambiando un poco de área, a la de almacenamiento y procesamiento masivo de datos para dominar el mundo, fueron anunciadas tres importantes tecnologías: Google Storage, la competencia frontal a Amazon S3, para almacenar distintos tipos de archivos en la nube con API de entrada y de salida y una útil línea de comando. Big Query, una interfaz SQL para consultas complejas sobre cantidades enormes (billones) de datos para su análisis, vale la pena anotar que es MUY rápido. Prediction API, permite "entrenar" al sistema con un conjunto de datos iniciales y luego con algoritmos de aprendizaje de máquina al recibir nuevos datos es posible obtener a cambio predicciones sobre el futuro en tiempo real. Acaso no suena impresionante?

Móvil, otro gran tema durante la conferencia, despegó con el lanzamiento oficial de la nueva versión del sistema operativo Android, 2.2 deliciosamente llamada Froyo (Fozen Yogurt), con ella mejoras considerables en velocidad y rendimiento, mejor soporte a Exchange, API para administradores, API para comunicación desde la nube al dispositivo, tethering integrado (que a propósito estoy utilizando en este mismo instante en el aeropuerto), acceso al Marketplace e instalación remota de aplicaciones.

Pero no todo lo que aprendí fueron cosas nuevas o grandes anuncios, tuve la oportunidad de explorar un poco más a fondo algunas innovaciones de meses pasados o productos que no había tenido el chance de investigar con el debido tiempo. Entre ellos está el lenguaje de programación GO, que fue pensado principalmente para mejorar tiempos de compilación, "build" y ejecución, esto sumado a que fue pensado para la Web desde el inicio. Es una alternativa moderna a C, y aunque es un lenguaje fuertemente tipado también cuenta con algunas características muy convenientes de sintaxis tomadas de lenguajes como Python. Además, tiene la mascota más peculiar, lo siento Duke. La librería Javascript Closure, sobre la cual corren aplicaciones en producción como Google Docs y Gmail, tiene un juego de widgets impresionante y ha sabido incorporar muchas experiencias aprendidas por Google en el día a día o análogas a implementaciones de otras librerías, como por ejemplo el sistema de build de Dojo.

Finalmente, pero no menos importante tuve la oportunidad de conocer en persona a varios miembros y organizadores de GTUGs alrededor del mundo, varias de estas comunidades (incluyendo la nuestra, GTUG Colombia) nacimos hace un año al termino del anterior Google I/O, aunque es una iniciativa joven hay muchas oportunidades por venir, ya que las tecnologías de Google cada vez atraen a un número mayor de desarrolladores y usuarios en un número cada vez mayor de áreas.

En conclusión, la experiencia fue del todo positiva, ahora viene la parte difícil que es materializar las ideas que quedaron al salir de cada una de las sesiones, sean para beneficio de mio desde el punto de vista profesional, de mi empresa, o de la comunidad de desarrolladores local con el GTUG.

Parque Nacional Natural Chingaza

2009-11-22T12:13:00.007-05:00

Bogotá, otra mañana cotidiana de otro cotidiano fin de semana en la capital. El smog, ya es parte integral de la ciudad. Los espacios verdes y la naturaleza, por el contrario, se empiezan a alejar y a perder atención e interés entre nosotros, sus habitantes. Creo que en el fondo todos sabemos que en nuestro país tenemos paisajes espectaculares, así como fauna y flora singular. Sin embargo, pocas veces sabemos apreciar y valorar éstos, en realidad muy pocas veces tenemos el impetú de salir a visitar y conocer estos santuarios. Es triste que la magia de sus montañas y de sus páramos se vea en gran parte amenazada por nuestro propio desconocimiento. Este fue uno de los motivos para emprender este viaje, conocer lo nuestro y sentirnos parte de él.

Chingaza, es uno de los parques nacionales naturales más cercano a Bogotá (a menos de dos horas), así como uno de los parques con más personal permanente, equipado con una muy buena infraestructura (incluyendo su excelente carretera), la zona de camping es una de las más modernas de suramérica, entre otras muchas bondades. Es famosa por ser dueña del recurso hídrico, el oro líquido: el agua. El parque abarca 76.600 hectáreas por los departamentos de Cundinamarca y Meta. Visto desde un mapa tiene la silueta de una mariposa, cuyas alas representan dos zonas con ecosistemas diferentes unidos por un pequeño corredor ecológico. La zona de páramo y la zona de bosques de niebla. El sistema montañoso es uno de los componentes principales del parque, ya que lo atraviesa en gran parte la coordillera oriental, los farallones de Medina en el sector oriental del parque hacen gala de esto. En un futuro en esta otra cara del parque se va a servir a la comunidad con un centro para visitantes accesible desde el municipio de Restrepo, Meta (nada oficial, sólo un chisme que nos contaron).

Antes del viaje tratamos de encontrar en Internet más o menos qué comprendía la aventura. El primer recurso que se vino a la cabeza fue la página oficial de parques nacionales naturales, para mi sorpresa debo admitir que la página fue muy informativa y contenía los datos claros y precisos de lo que se debía hacer para llegar, las actividades y la infraestructura. También encontramos otros sitios y blogs bastante informativos y con fotos espectaculares, que en realidad hacen que nazcan en uno ganas de vivirlo.

Decidimos arrancar muy temprano, a eso de las 7:30AM desde Bogotá rumbo a la Calera; entre la Calera y Guasca en el Km 1, está el típico aviso de madera con letras amarillas del PNN Chingaza donde se debe hacer el desvío, de allí al retén de Piedras Gordas son más o menos 45 minutos. Por carretera destapada, pero en muy buenas condiciones, el paisaje rural muy agradable, fincas y campo cultivado típico de los alrededores de la sábana. En el retén de Piedras Gordas, los visitantes debemos bajar del vehículo y, funcionarios del parque, muestran un video informativo acerca del parque seguido de un video de la empresa de acueducto, todo esto en una cabaña tipo Chalet Suizo. Aunque allí se puede obtener el permiso y pagar, es importante de ser posible traer el permiso desde la oficina de Parques nacionales Naturales de Bogotá, ya que para las caminatas y la zona de acampar el límite es de 30-40 personas diarias, esta recomendación es más que todo para tranquilidad y certeza que después no habrá que cambiar los planes. Vale la pena aclarar que solo es posible acampar durante Viernes, Sábados y Domingos únicamente por un sólo día. Hora mínima de ingreso 9:00AM y de salida antes de las 5:00PM. Pasando al tema económico, van los precios en pesos colombianos. Ingreso al parque: estudiantes $6.000, adultos responsables $10.000. Ingreso del vehículo $9.000. Noche de camping por persona: $10.000. Área de camping $8.000. En definitiva, como éramos cuatro el total fue de $85.000. Nada mal, dentro del rango esperado.

De Piedras Gordas a Monte Redondo, el paisaje de páramo se torna más y más natural y conservado. Varias especies de frailejones, lagunas (Laguna Seca y Laguna Verde), venados y montañas nos acompañaron por algo más de otros 45 minutos. El paisaje es realmente impactante. La carretera al final se torna un poco más complicada (hablo para carros pequeños, como en el que iba) debido a la gran cantidad de piedras, me modo que un par de veces fue preciso disminuir la velocidad con tal de no rayar el carro por abajo.

En Monte Redondo, al borde del embalse de Chuza, se encuentra el centro administrativo del parque, muy cerca también está una base de operaciones de la EAAB. En el centro administrativo del parque hay un lobby que parecía más un museo, con fósiles, cráneos, fotografías, mapas y hasta pieles de algunos animales. También había un pequeño humedal simulado en un acuario, muy didáctico.

Allí se encuentra la zona de camping. Debo admitirlo, soy el más newbie, amateur o principiante en cuanto a acampar se refiere, sin embargo quede muy impresionado por la comodidad y la infraestructura que había: parqueadero, luz, toma de corriente, asador, lavaplatos, techo, mesa y hasta baños.

Los funcionarios del parque, muy cálidos y atentos por cierto, organizan una visita guiada que incluye la explicación geológica de los orígenes del parque y una caminata por un sendero bastante interesante (sendero Suasie), por el que se recorren tres ambientes diferentes del páramo y en el punto más alto una de las mejores vistas panorámicas de el embalse de Chuza. Notamos que algunos Bogotanos van a pasar el día allí o simplemente a almorzar, más bien pocos los que acamparon ese día.

El día fue cálido, la intensa radiación solar hacen que la temperatura suba varios grados durante el día y le da una vista más bonita a todo. Durante la tarde hubo lluvias, algo muy típico e inherente del páramo, especialmente de éste. La noche fue fría, aunque despejada, las estrellas en la noche se veían en todo su esplendor, en el horizonte de la oscuridad se alcanza a visualizar la gran estela de luces de la capital colombiana. La tranquilidad y el silencio son una constante a lo largo del día, haciéndolo un lugar perfecto para descansar leyendo, pensando o meditando.

Chingaza cuenta con una gran biodiversidad de especies y endemísmos de los páramos andinos, siendo una región de gran importancia ecológica. Su fauna característica incluye el oso de anteojos, el zorro, el tigrillo, el curi, el cóndor, el águila, venados y muchas otras especies de mamíferos, aves e insectos. El avistamiento de estos animales es difícil, pero si es seguro encontrarse muy de cerca con varios venados cola blanca durante el recorrido, lo que causa una enorme exaltación y la reflexión sobre la extinción que sufren estas especies. La riqueza de la flora es inmensa, los diferentes estudios realizados estiman unas 2000 especies vegetales, de las cuales solo se tiene registro de 383, la mayoría de gran importancia dentro del ciclo hidrológico al tener la función de captadores y reguladores del agua. Durante el recorrido se identifica y analiza el pórque de la fisiología de las plantas; su porte bajo, las formas en rosetas y las hojas pequeñas que ayudan a mantener el agua y gastar menos energía. Como especies representativas se encuentran cuatro especies de frailejones, musgos, líquenes, helechos, el siete cueros, el cucharo, el encenillo, el té de Bogotá, el guarda rocio y diferentes bromélias y orquídeas.

Algo muy característico de este parque son las ruinas que han dejado, dos mega proyectos para Bogotá. La construcción del gran sistema Chingaza de la EAAB, finalizado hace aproximadamente 30 años, bajo el cual trabajaron más de 3.000 empleados en sitio, y que corresponde a cientos de kilómetros en túneles, válvulas, plantas de tratamiento, embalses y tuberías. El segundo, las minas o canteras de cementos Samper, de donde se extrajo la piedra para algo como el 70% de las construcciones de Bogotá. Pues resulta que la naturaleza ha empezado a colonizar nuevamente este pasado y no es raro encontrar restos de construcción invadidos por vegetación.

Una gran extensión del parque, específicamente donde se encuentra el sistema Chingaza y el embalse de Chuza, pertenecen administrativamente al municipio de Fómeque, irónica y paradójicamente en este municipio NO se cuenta con el servicio de agua potable. Es cierto, puede que el gobierno municipal sea responsable en cierta parte por no haber tenido ésta en sus prioridades, pero también se siente cierto resentimiento fomequeño hacia la EAAB (Empresa de Acueducto de Bogotá) e inclusive hacia la división de Parques Naturales, obviamente cuestionando la "gratitud" de nosotros los ya casi 10'000.000 de bogotanos, principales beneficiarios del recurso hídrico. La EAAB habla del proyecto Chingaza II, pero factores como las irresponsabilidad social demostrada por esta empresa y el impacto ambiental que causaría nos hacen pensar que sería mejor que no ocurriera.

Finalmente no nos animamos a ir a la laguna de Chingaza, el principal ícono y la que le da el nombre al parque. Según una funcionaria, es la laguna más bella e impresionante haciendola su lugar favorito. Eso sin mencionar que para los primeros habitantes del parque, los indígenas Muiscas era de caracter sagrado. Aunque no hay visitas guiadas ni senderos nos dijeron que vale la pena ir. Por lo menos tenemos excusa para volver pronto.

Cada vez me doy más cuenta de lo poco que conozco mi propio país, mi propio departamento y hasta mi propia ciudad. Así que le recomiendo a quienes no hayan ido al PNN Chingaza, que lo hagan, especialmente a la gente que vive o está cerca de Bogotá, es muy cerca y fácil de ir. Puede no ser el plan más barato (ni guerrero) pero si un plan con los mejores paisajes. Les aseguro que la tranquilidad y el silencio que se vive allí es difícil de encontrar en estos tiempos, además, lo obliga a uno a reflexionar acerca de la importancia del agua y todo su ciclo natural.

Agradecimientos especiales a Laura Hernández @la1o6 por toda su colaboración.

Experimento de Productividad. Introducción

2009-11-02T05:18:00.000-05:00

Hay pocas cosas que me estresan y me preocupan más que saber que tengo cosas pendientes por hacer. Sin embargo, a alguien mira los hechos concretos le parecería todo lo contrario, que me sintiera a gusto estando así. Lo digo porque porque cada lista o "to-do" de pendientes que inicio, empieza a crecer y crecer muy rápidamente, sin que necesariamente todos los items sean tachados.

Lo admito, sufro de un desorden sicológico muy común en los trabajadores de la actualidad, la procrastinación. Consiste en postergar y postergar tareas por largos periodos de tiempo, ya sea porque se subestima o porque se sobrestima su complejidad, en lugar de tomar acción. Otras expresiones de este comportamiento suelen ocurrir por una falsa creencia de perfeccionismo o por ansiedad.

Pero esto no tiene porque seguir siendo así. Decidí que es el momento justo de reaccionar, aprovechando que se acerca el final de año y como dice la canción: año nuevo, vida nueva. Así que si en realidad va a haber vida nueva por lo menos tengo que dejar en paz y salvo lo que empecé en esta vida vieja. Hay varios (muchos) proyectos que quedaron en estado no finalizados, no cerrados, pendientes o en infrecuente desarrollo. Esto causa en algunos casos que la empresa no pueda facturar, en otros implica que retomar el proyecto cuesta tanto o más que finalizarlo y en la mayoría significa que el proyecto en ese estado, simplemente no es una alternativa.

El experimento que voy a llevar a cabo es muy fácil: definir las condiciones que considero óptimas para lograr trabajar, no más sino mejor, más inteligentemente.

Las condiciones

Teletrabajo

No trabajar desde la oficina. Por qué? La principal razón (o excusa) es la desconcentración, la rutina diaria absorbe toda la atención y energía. Es cierto, no me puedo quejar de la distancia entre la casa y la oficina, pero en serio, que diferencia hay entre ver la pantalla de un computador aquí o allá? por ahora el factor de interacción social de los proyectos no me preocupa ya que yo soy el único responsable. Además cada vez el tráfico es más pesado en horas pico y si ese tiempo y energías que implican los desplazamientos se puediera invertir en trabajo efectivamente, sería excelente.
Por último, el teletrabajo o telecommuting es una tendencia que ya está siendo utilizada por muchísima gente, sobre todo en mi industria y ya empieza a ser mencionada en los principales medios. Más bien, por que no intentarlo?

Planeación

Diaria: Para la planeación me parece conveniente seguir la técnica de los 18 minutos bajo la cual se toman 5 minutos al inicio del día para listar las actividades, 5 al final para revisarlas y 1 minuto por hora para renfocarse. En general me parece bien, excepto por la interrupción cada hora, en mi opinión es más costosa la interrupción que el valor ganado "reenfocando", mi versión adaptada consistirá en renfocarme al haber terminado por completo cada actividad.

Semanal: Además de poder planear efectivamente cada día, es importante tener una visión de alcance intermedio entre la rutina diaria y la imagen completa. Las semanas tienen la ventaja de que permiten saber muy rápidamente si las cosas se están haciendo bien o mal y comparar resultados obtenidos contra los planeados y contra semanas anteriores. Una de mis metas es ser capaz de determinar qué tanto se puede hacer durante la semana y en última instancia, poder estimar el esfuerzo real de un proyecto completo en semanas.

Reglas

Como es natural, para que este experimento sea exitoso es necesario fijar algunas reglas que debo cumplir con el fin de, en un futuro, generar hábitos para que esta problemática no se vuelva a repetir en un par de semanas. Las reglas que he definido hasta ahora son:

Jornada: El día inicia a las 5:30AM y termina a las 9:30PM. La jornada laboral de 7:30AM a 6:30PM. Hace un tiempo entendí que trasnochar en vano no es algo para estar orgulloso y no, definitivamente la calidad del trabajo cuando se trasnocha no es la mejor. También he visto según mi experiencia que entre más temprano se inicie el día, más se aprovecha.
Revisión de correo: Considero que una de las metodologías más efectivas que he visto hasta ahora para el manejo del correo electrónico es Inbox Zero. La idea: no "procrastinar" con el correo electrónico y evitar que se convierta en la distracción número 1, minimizando el tiempo que se dedica a él. Con cuatro revisiones a la bandeja de entrada al día es más que suficiente.
Chat: El chat tiene tanto de bueno como de malo. Puede ser usado como una herramienta de colaboración y comunicación invaluable en un equipo de trabajo, pero por otro lado tiene el problema de llegar a convertirse la herramienta que causa más desconcentración e interrupción constante. Muchas veces es mucho más directo hacer una llamada o mucho más prudente escribir un correo. No chat.
Redes sociales: No hay porque engañarse a uno mismo, es un hecho, las redes sociales y los sitios de noticias (como Google Reader, Twitter, Facebook, Blogs) matan la productividad. Claro, no estoy diciendo que no sean importantes y que no merezcan su espacio, sino que no les debemos abrir la puerta para que invadan y absorvan horas productivas valiosas. Máximo una hora al finalizar el día.
Seguimiento: Por más que el teletrabajo sea una maravilla y que parte de la comunicación se lleve a cabo por medios electrónicos, siempre van a existir actividades que hay que coordinar con el equipo o una reunión presencial frente a frente donde se clarifican los pasos a seguir. Un día a la semana se hará seguimiento presencial en la oficina.

Las próximas entradas en este blog van a reflejar el estado de avance y cómo se ha ido desarrollando el experimento.

David

Desarrollando con Dojo, Django 1.0, Dojango y Google App Engine

2008-11-03T18:14:00.006-05:00

Después de un lapso de varios mesos de haber desarrollado mi primer prototipo de aplicación, volví a retomar el desarrollo en Google App Engine por un proyecto interno nuevo que surgió en mi empresa Eforcers. Esta vez la aplicación a desarrollar es una herramienta que está planteada a largo plazo y que va a ir evolucionando según nuestras propias necesidades. Por este motivo al mirar atrás, vi que utilizar el framework web_app de Google no era la solución más robusta e indicada para el alcance del proyecto, en especial teniendo a Django como una posible alternativa. A continuación voy a presentar los recursos que utilicé para luego plantear el problema y ver como las fichas del rompecabezas van cuadrando y mostrar mi solución.

Los Recursos

En esta travesía el primer recurso que fue fundamental, fue una de las sesiones de Google I/O a que no pude asistir por conflicto de horarios, pero afortunadamente fue grabado en video y subido a YouTube. En esta sesión Guido van Rosum, creador de Python y empleado de Google, explica muy claramente y con ejemplos cómo aprovechar lo mejor de Django en el App Engine e introduce el segundo recurso; el proyecto Google App Engine Django desarrollado por dos empleados de Google.

Este proyecto sirve como "ayudante" y provee la implementación de los archivos básicos para cualquier aplicación que quiera usar Django en App Engine teniendo en cuenta las restricciones impuestas. El proyecto se compone de los archivos: main.py, manage.py, settings.py, urls.py, el famoso app.yaml y el directorio de la librería appengine_django que entre otras provee una implementación de contrib/auth de la cual hablaré en un futuro post. Este artículo introduce el proyecto, muestra su uso y configuración.

Desde el punto de vista de la interfaz de usuario, simplemente ya no me preocupo por la selección de la librería, Dojo Toolkit ofrece todo lo necesario y versión tras versión es mejor. Sin embargo para la integración con Django y minimizar la plomería, valío la pena experimentar con un proyecto de la gente de Uxebu, todos ellos commiters de dojo, el proyecto es dojango y resulta muy útil para evitar código que usualmente se repite página tras página como la definición del perfil de dojo usado (local, cross domain, AOL o Google) la versión, los estilos CSS del tema, entre otras bondades; en el futuro sus creadores prometen integrar con django.forms para la generación automática de los dijits.

El Problema

En resumen el problema de raíz fueron las versiones. En primer lugar Google App Engine incorpora la versión 0.96 de Django, la cual es una versión desactualizada y no incluye muchas de las mejoras que están en la versión 1.0, el motivo 0.96 era la versión más estable al momento de desarrollo del App Engine, además dojango requiere una versión mayor o igual a 1.0. Otra parte del problema fue que el "ayudante" únicamente soporta la versión 0.96 o la última de desarrollo.

Otro problema que surgió, esta vez por restricciones del App Engine en producción fue el límite de 1000 archivos para la inclusión de Django.

La Solución

En definitiva la solución fue muy simple pero a la vez muy inusual, bajar las últimas versiones del trunk de subversión de todos los proyectos, aparte de cierta familiarización con el comando svn checkout este proceso no requiere nada más.

En cuanto a la otra preocupación, aprovechando el reciente soporte a zipimport la solución fue seguir las instrucciones planteadas en este artículo:

Descargar Django
Empaquetar Django en un archivo zip, django.zip
Remover del archivo zip los módulos no soportados/no necesarios, como la consola de administración, los archivos de traducciones locales (obviamente excepto español e inglés)
No olvidar adicionar los módulos en contrib que requiere el "ayudante" que son: auth, sessions, sites.
Copiar el zip al directorio raíz de la aplicación
Con el "ayudante" no es necesario hacer nada más, desde que el nombre sea django.zip

Eso fue todo lo necesario para armar un proyecto base generico para todas las próximas aplicaciones a desarrollar en Google App Engine (con suerte muchas) con Django y Dojo.

Obviamente se supone que en el futuro van a salir versiones nuevas de todos estos componentes y para entonces muchos de estos problemas se habrán solucionado. Aprovechando que toque el tema del futuro estoy intrigado por el soporte a un nuevo lenguaje en tiempo de ejecución según el roadmap publicado (mi predicción esta entre PHP y Java). De todos modos en el poco contacto que he tenido con Python me he sentido muy cómodo y veo grandes fortalezas en este lenguaje. Por otro lado, creo que el proyecto dojango va a evolucionar hasta convertise en el comprehesivo Zend_Dojo de Python brindando muchos otros "goodies" que estoy seguro facilitarán el desarrollo de apps en Dojo y mejorarán la productividad.

Me gradué de Maestría

2008-09-20T12:21:00.003-05:00

Como algunos de ustedes ya saben, oficialmente soy Magister en Ingeniería área de Sistemas y Computación de la Universidad de los Andes. Quiero darle las gracias a todos aquellos que me apoyaron y confiaron en mí en el camino hacia este logro.

Ahora vienen nuevos retos y es el momento de empezar a aplicar en la industria todo lo que aprendí en la Academia.

Media Maraton de Bogota

2008-07-28T10:41:00.005-05:00

Aca están las fotos de la media maratón de Bogotá el pasado domingo 27 de Julio de 2008.

Este es el mapa del recorrido

View Larger Map

Los primeros siete kilómetros se caracterizaron por el calor, estaba haciendo un sol increíble y creo que no hice la mejor selección en cuanto a la camiseta, sin embargo logré llevar un ritmo constante en cuanto a pulsaciones (70 bpm) del kilómetro 7 al 10 aprovechando el trayecto plano de la 72 hasta la 100 por la Cra. 15 fue más fácil aún y la hidratación empezó a mostrar sus beneficios; resultado, a los 10Km llevaba 55 minutos lo cual era la meta planeada.

Desde ahí todo fue inercia hasta el kilómetro 14, donde empezó el dolor en las rodillas luego de ver al "pacer" de las 2:00h, a propósito muy buena la idea ya que es la primera vez que hay de esto en la maratón, los "pacers" o "liebres" son atletas profesionales que saben exactamente cual debe ser el ritmo constante para demorarse X tiempo. Continuando con el recorrido, desde el kilometro 15 hasta el 21 fue el sufrimiento puro, el dolor no me dejaba acelerar aunque de pulsaciones andaba bien (entre 60 y 65 bpm). Opino que la ubicación de la meta es estratégica por la rueda samsung del parque del salitre, la cual puede ser vista desde varios kilómetros antes. La emoción al llegar fue inmensa y gratificante aunque el tiempo no haya sido el mejor fue una prueba lo suficientemente dura tanto física como mentalmente.

Eforcers en Google I/O. Moviendo la Web hacia adelante desde Colombia. Día Uno

2008-06-04T23:03:00.009-05:00

Eforcers LTDA, la compañìa para la cual trabajo, como parte de la estrategìa de desarrollo de productos sobre Google Apps me envìo a la conferencia màs grande de desarrolladores de Google, la primera versiòn de Google I/O. Se llevò a cabo en la ciudad de San Francisco en California durante los dìas 28 y 29 de Mayo en el centro de convenciones Moscone West. La conferencia fue bastante interesante en cuanto a la calidad en el contenido de las sesiones, instalaciones en las que se llevò a cabo y presentadores. Pero tal vez màs importante que todo esto fue la oportunidad de escuchar y hablar a los ingenieros de Google y de otras empresas e interactuar con ellos.

Dos de las personas que tuvimos el honor de conocer allì fueron Dylan Schieman y Alex Russell de Sitepen fundadores de Dojo, el paquete de herramientas para Javascript que usamos en Eforcers desde el año 2005. Ellos fueron tan gentiles de invitarnos a una cena el dìa anterior donde compartimos varias experiencias, opiniones y pensamientos acerca de Dojo y la conferencia en general. No siendo suficiente con esto, estuvieron a nuestro lado gran parte del tiempo libre y nos presentaron gente respetada en la industria. Gracias a Alex pudimos asistir a una fiesta de WordPress, la plataforma para publicaciòn de contenido, donde conocimiento al fundador de esta compañìa y a varios usuarios de esta popular herramienta.

Volviendo a la conferencia, fue fundamental haber ido tres ingenieros de Eforcers (Andrès Cifuentes, Jorge Forero y yo) màs Julian Amaya de TechPyme, ya que eran alrededor de 90 sesiones, muchas de èstas simultaneas, y fue imposible asistir a todas. Sin embargo nos dividimos y se seleccionaron las sesiones màs acordes con nuestra nueva estrategìa y productos o de mayor visiòn hacia la direcciòn futura de Google. A continuaciòn presentò un pequeño resumen màs mis comentarios personales acerca de cada sesiòn que asistì.

Keynote Dìa 1.
El vicepresidente de ingenierìa Vic Gundotra tocò varios aspectos relacionados con las ventajas que traìa el uso de la "computaciòn en nube" comparandola con enfoques pasados como la terminal bruta y el computador de escritorio; centrandose en cuatro variables agrupadas en dos grupos: poder vs. accesibilidad y despliegue vs. funcionalidad. Luego hizo enfasis en otros aspectos importantes para la computaciòn en nube como la conectividad y el enriquecimiento de clientes web. Fue sorprendente cuando aclarò que mejores aplicaciònes Web traerìan mayores ingresos a Google ya que màs personas usarìan su motor de bùsqueda, definitivamente honesto. Luego cada uno de los gerentes de los principales productos mostraron el estado de sus proyectos e hicieron algunos anuncios importantes, como los APIs para manipulaciòn de imàgenes y cachè para el Google App Engine y la disposiciòn de este mismo a cualquier persona con cuenta de google accounts. Tambièn hablaron algunos usuarios de tecnologìas Google como el CTO de iLike y el de MySpace.

Estado de Ajax. Por Dion Almaer y Ben Galbraith de Ajaxian.
Definitivamente la presentaciòn mejor hecha de toda la conferencia, como buenos expertos en interfaces gràficas Dion y Ben realizaron diapositivas bastante amigables y llevaron la sesiòn en forma de charla mutua.

Los principales puntos que tocaron se resumen en la problemàtica de la trancisiòn entre experiencia para el desarrollador, interacciòn y experiencia para el usuario. El uso de librerìas y "toolkits" para reutilizar el conocimiento colectivo de la comunidad en tendencias, optimizaciones e infraestructura, limitaron la selecciòn a cuatro: Prototype+Scriptaculous, jQuery, Dojo y GWT mostrando sus diferencias y caracterìsticas. Tambien profundizaron en la nueva versiòn de HTML, Gears, integraciòn de servicios web con ambientes de escritorio, computaciòn en nube, entre otros.

Fireside Chat con el equipo de GData APIs
Una sesiòn con dinàmica muy diferente a la anterior, consistìa en un Q&A a los ingenieros desarrolladores del API. En esta sesion tuve la oportunidad de hacer preguntas especìficas a mis proyectos sobre Google Apps como sugerir el API para Docs y Presentations, consejos para hacer mi propia implementaciòn de Web Services a la GData, problemas existentes en el provisioning, entre otras. Obtuve muy buenas respuestas y sentì que habìa aportado retroalimentaciòn valiosa a ellos.

Can We Get There From Here? por Alex Russell
Similar a la primera sesión esta presentación fue increible, el expositor y líder del proyecto Dojo Toolkit hizo un estado del arte en el espectro de las herramientas para desarrollo Web de clientes principalmente en Javascript y HTML. Algunos de los aspectos importantes que tocó fueron el papel fundamental tanto de los cuerpos de estándares como de los implementadores de navegadores y el límite de responsabilidades entre ellos y nosotros como desarrolladores Web. Hizo un recuento de tecnologías y frameworks según el nivel de riqueza gráfica de las aplicaciones Web empezando desde puro HTML estandar hasta GWT, Flash y Silverlight. Por último habló de temas más enfocados a modelos de negocio y economía de Internet; como cuestiones de competencia vs. monopolios; finalizó mostrando algunas opciones para innovar sin estar atado al control de vendedores, sistemas operativos o estándares, igual (Google) Gears.

Underneath the Covers at Google por Jeff Dean
Revisión a la historia del crecimiento de la infraestructura de sistemas en Google desde los noventas hasta hoy, resumen ejecutivo del uso de tecnologías desarrolladas en casa como GFS(Google File System) MapReduce y BigTable. Políticas internas en cuanto a manejo y organización de equipos de desarrollo, uso de proyectos open source, filosofía de ser abiertos e implementar mejores prácticas de la ingeniería de software como revisiones de pares y pruebas unitarias. Por último mostró el trabajo actual que están llevando a cabo en cuanto a la comunicación entre data centers. Recomiendo ver este artículo en Webware.

Parsing and Generating KML with Google's KML Library por Michael Ashbridge
Vista detallada a la nueva librería libkml para hacer parsing de archivos KML 2.2, recientemente aprobado por la OGC como un lenguaje estándar oficial OpenGIS. Definitivamente es interesante el enfoque del desarrollo de esta librería ya que tuvo un proceso inverso a muchos otros productos, nació de código real en funcionamiento (dentro de Google Earth) y fue la implementación de referencia para soportar el lenguaje. Es una librería hecha en C++ pero gracias a SWIG hay encadenamientos a Python y Java. La librería se divide en cuatro partes: dom, engine, regionator y util. Michael explicó mediante demos varios ejemplos de utilización del API, aproposito bastante poderoso. En cuanto al futuro de esta librería este es el roadmap: estabilización del API, soporte completo a dom, plantillas, estilos y soportar más lenguajes.

After Hours
Tal vez la fiesta más costosa y espectacular en la que haya estado en mi vida, comidas y bebidas buenísimas por todos lados, además muy orientada a nosotros los ingenieros: pantalla gigante para jugar Wii, motos de arcade, air hockey, etc. Se presentó Flight of the Conchords, la banda neozelandesa de Folk y fue muy divertido. Google sabe como consentir a sus desarrolladores.

Actualización. 12/06/08. Los videos de las sesiones están disponibles en YouTube.

PDFs en Google App Engine

2008-05-12T22:03:00.006-05:00

Tal como había mencionado en el post pasado el proyecto en el que estoy trabajando en el Google App Engine requiere la generación de documentos en formato PDF dinámicamente. En java alguna vez use iText y me pareció una muy buena librería con un API bastante flexible y poderoso. Siendo nuevo en python, decidí buscar proyectos open source similares que resolvieran esta problematica y tratar de entender cómo lo hacen.

El primero que encontré y el más popular fue ReportLab seguido de un tutorial bastate básico (lo que nosotros llamamos el "Hola Mundo") de como usarlo, ya que los ejemplos incluidos en la distribución son muy complejos de entender para un principiante como yo. Así que decidí intentar extrapolando los conceptos del tutorial a mi proyecto con tan mala suerte que todo terminó en una excepción de entrada/salida. Despues de leer cuidadosamente el stack-trace me dí cuenta que estaba trantando de acceder al sistema de archivos, operación específica que restringe el app engine.

Aprovechando que en el mismo proyecto uso Django como framework para el desarrollo de mi aplicación decidí incluirlo como un término de la búsqueda, de esta manera encontré esta página de documentación que fue clave en la solucion del problema ya que trataba al request HTTP como un archivo. Hice los ajustes necesarios al código fuente y probé, con tan mala suerte que me volvió a salir una vez más una excepcion de entrada/salida. Muy extraño, no? Ante la frustración decidí escribir en el Google Group la pregunta y de paso ver si alguien ya había resuelto este problema antes.

Antes de recibir cualquier respuesta y apelando al escepticismo de que todo el conocimiento está en el Group decidí incluir app engine como término de búsqueda, inesperadamente encontré exactamente lo que necesitaba. Luego de algunas pruebas y de identificar el gran error que había cometido la generación del archivo PDF fue exitosa. Ahora les presento el código fuente:


import cgi
import wsgiref.handlers
import logging

from google.appengine.api import users
from google.appengine.ext import webapp
from google.appengine.ext import db

import os
from google.appengine.ext.webapp import template

from reportlab.pdfgen import canvas
from reportlab.lib.pagesizes import letter
from reportlab.lib.units import cm, mm, inch, pica

class FinHandler(webapp.RequestHandler):
 def get(self):
   # Crea el objeto HttpResponse con sus encabezados apropiados
   self.response.headers['Content-Type'] = 'application/pdf'
   self.response.headers['Content-Disposition'] = 'attachment; filename=archivo.pdf'
   # Crea el documento PDF usando el pedido como "archivo" y de tamaño carta
   p = canvas.Canvas(self.response.out, pagesize = letter)
   y = 750
   # Escribe el titulo
   p.drawCentredString(letter[0] / 2, y, "titulo")
   ....
   #Salto de pagina
   p.showPage()
 
   #Guarda y limpia el documento PDF
   p.save()

Google App Engine: Primeras Impresiones

2008-05-06T01:06:00.000-05:00

Como ya la mayoría de ustedes saben Google puso a dispocisión, de nosotros los desarrolladores de software, la infraestructura en la que corren aplicaciones como Gmail, Google Apps y hasta el mismo Blogger. El anuncio se hizo en un evento cerrado llamado el campfire hace unas semanas atrás. El producto/servicio se llama Google App Engine y consiste en un sandbox en los servidores virtuales de Google más un SDK para hacer pruebas locales, todo utilizando el lenguaje de programación Python, con la promesa de soportar otros lenguajes en el futuro (java tal vez?).

Este anuncio implica como dirían muchos la introducción del cloud computing a las masas y nos quitaría a nosotros desarrolladores y administradores de sistemas muchas responsabilidades y conocimientos técnicos, en su mayoría ortogonal a la lógica de la aplicación y su funcionalidad; en cuanto a escalabilidad, tolerancia a fallas, rendimiento, instrumentación, entre otros.

Luego de varios días de ver que había llegado demasiado tarde el día del anuncio y ya se habían repartido las invitaciones, me llegó un correo referente de Google I/O para "ir practicando" para las sesiones (al menos 9). Así que decidí intentar y quitarme el miedo de estrellarme contra otro nuevo lenguaje, contra otro nuevo framework, contra otra nueva plataforma.

A continuación les cuento mis impresiones.

Lo bueno

El deploy: Despues de haber tenido muchos problemas en mi vida pasada de desarrollador Java y PHP con versiones de librerías de diferentes versiones que hacen conflicto, configuración errada de los data source, nombres JNDI mal puestos, PHP compilado de manera errada, etc, siento que el proceso de deploy es bastante simple y fácil con el appengine, se restringe a la ejecución de un comando.
La interfaz de administración: Me parece impresionante la vista unificada de las métricas de la aplicación, la consulta de mensajes del logger, etc.
Integración con Google Accounts y Google Apps: El manejo de usuarios basados en las cuentas de google es bastante fácil. Además la posibilidad de restringir el uso de la aplicación dentro de uno o varios dominios me parece muy amigable para las organizaciones que cuenten con Google Apps.
Django: Todo lo bueno que había oido de Django es más que cierto. Es un framework muy inteligentemente hecho y permite de manera simple hacer cosas bastante complejas.
El datastore: El sólo hecho de no tener que correr scripts de inicialización a la base de datos o de no preocuparse por cambios estructurales al modelo, da una sensación de poder enorme.

Lo malo

Las restricciones: Google limita el runtime de python en una gran medida. Por ejemplo no permite ninguna modificación al file-system, quita el acceso a las funciones de C, a paquetes de networking, a estructura de modulos propios, etc.
Mejores prácticas: No he podido encontrar ningún consejo, recomendación o mejor práctica para la estructura de los directorios, módulos, paquetes dentro de la aplicación. Pareciera que en la comunidad de python no hubiera newbies y muchas veces la falta de un sitio central donde conseguir documentación quita impulso.
Recursos: Viniendo del mundo Java donde hay librerías para todo y donde el tiempo es oro y nadie se reinventa la rueda es duro no poder encontrar fácilmente (por ejemplo) una librería para utilizar el formato JSON, no quiero pensar cuando necesite algo como acegi o hibernate o tenga un problema raro.

En conclusión creo que obviamente si ambas cosas se ponen en la balanza, son mucho mejores las positivas y en cuanto al tiempo en el desarrollo he notado bajas importantes incluso en la fase donde uno se lleva puesta toda la curva de aprendizaje. Por último quiero recomendar que si tienen alguna pregunta no duden en escribir al grupo http://groups.google.com/group/google-appengine
hay gente con habilidades extraordinarioas que pueden ayudar casi con cualquier problema. Espero que para la segunda aplicación, ya con el ambiente unificado y probado el ciclo de desarrollo se demore mucho menos. En unos días les cuento como me fue terminando el proyecto.
Nota: todavía faltan cosas importantes como la generación de pdf sobre la cual espero escribir después.

Proyecto Para el Próximo Año

2007-12-14T16:07:00.000-05:00

Durante este segundo semestre en especial tuve la oportunidad de desarrollar varias aplicaciones; para hacerlo use la pila de tecnologías "por defecto" para mi: léase MySql, Hibernate, JPA, Spring Framework, Spring MVC y Dojo. En general la metodología para cada una de ellas está bastante bien documentada por todo internet y todas las tecnologías operan decentemente juntas. Mi única queja está entre dojo (más precisamente dijit) y los nuevos taglib de spring mvc.

El Problema

Spring MVC provee un conjunto de taglibs, JSTL tag libraries, como spring:bind y su evolución desde Spring 2.0 spring:form. Lo que buscan estos taglibs es encadenar desde el HTML las entradas a atributos en los objetos Java. En la primera versión (spring:bind) era algo complicado ya que el encadenamiento se hacía mediante la variable status encerrado dentro de un "contexto" para el bind, de la siguiente manera:
<spring:bind path="hola">
<input value="${status.value}" name="${status.expression}">
</spring:bind>

Afortunadamente la gente de Spring se dio cuenta que este no era el enfoque y decidieron lanzar una nueva manera de hacer las cosas (spring:form). Con este taglib disminuye la cantidad de código ya que para el mismo ejemplo bastaría con escribir:
<form:input path="hola">

Hasta ahora todo tiene sentido y funciona de manera rápida y coherente, sin embargo al momento de la presentación la interfaz de usuario no presenta ningún atractivo ni interacción avanzada propia de una aplicación Ajax o web 2.0. Aca es donde entra Dojo Toolkit, una librería de componentes y de infraestructura en Javascript que permite adicionar desde funcionalidad personalizada por medio de sus componentes reutilizables (widgets) hasta una manera unificada de manejar estilos por medio de temas pasando por servicios de logging, internacionalización, build system, compresión de javascript, soporte a drag and drop, etc, etc.

El problema está al combinar las dos tecnologías ya que para declarar widgets de dojo es necesario especificar de que tipo son incluyendo el tag dojoType dentro del tag HTML que se desea convertir; para lo cual los tags de spring form no están preparados ya que ellos compilan los atributos de los elementos javascript y ciertamente dojoType no es uno de ellos.

Las Soluciones

Definitivamente no es un problema nuevo y cada quien tiene su propia estrategia al momento de resolverlo (hasta yo lo he sugerido). En realidad las posibilidades se rentringen a dos:

Crear Widgets Programaticamente en Javascript

Consiste en acompañar el tag HTML con la creación programática del widget, algo de la siguiente manera:
<input id="miTxt" name="miTxt" value="1">
<script type="text/javascript" >
new dijit.form.Textbox({value:dojo.byId("miTxt").value, required="true"}, "miTxt");
</script >

Deventaja: La creación del widget en javascript es larga y propicia para cometer errores

Usar el tag spring:bind

A alguien le suena familiar el dicho popular "avanzaron 3 pasos y retrocedieron 2"; este es un buen ejemplo de ello ya que con el tag anterior spring:bind no existía este problema ya que la declaración de las entradas HTML era independiente del taglib en sí.

Deventaja: Sigue siendo un dolor usar ese tag.

El Proyecto

Hay que buscar otra solución ya que esta clase de problemas limita a la gente de usuar spring con dojo. La propuesta es implementar otro taglib diferente que soporte atributos propios de los widgets de dojo junto con otro tipo de utilidades como controllers, form controllers y validators que integren transparentemente ambas tecnologías. Proximamente avances del proyecto...

Viaje al Cocuy I

2007-11-30T02:44:00.000-05:00

Querido Mike,

No se si te lo dije, hace ya casi seis meses desde que viniste a visitarnos, pero mi plan para que conocieras la Colombia bella e impresionante, llena de paisajes conmovedores, gente buena y trabajadora; consistía en visitar la sierra nevada del Cocuy allá al norte del departamento de Boyacá en los límites con Arauca y Casanare. En aquel entonces creo que me faltó mayor convencimiento, empuje y decisión que por simples motivos como la tesis, la lejanía, el tiempo y el costo frenaron mi iniciativa. Ahora pensándolo bien opino que ninguno de ellos era impedimento suficiente como para perderse de aquella fabulosa experiencia, de aquella porción de tierra que por diferentes razones, ya sean casualidades geológicas, destino natural o simplemente caprichos de la paccha mama de formar un paraíso terrenal juntando varios de los ecosistemas más exuberantes en un sólo lugar y accesible a mis sentidos.

La verdad fue que a mí me quedó la inquietud; y luego de haber investigado un poco en portales de internet le propuse la idea a la mayoría de mis amigos incluyendo a Laura, mi novia, y a su mejor amiga Estefania. Como siempre la idea suena bien de principio y la emoción de conocer algo nuevo invade al escucha, sin embargo son pocos los que realmente están dispuestos a ir sabiendo la dificultad que representan las vías de acceso, los costos(que acá entre nos son ridículamente bajos) y la inversión en tiempo a la que hay que estar dispuesto a hacer. Así que el grupo estaba listo, (Laura, Estefanía y yo) y a una menos de semana simplemente teníamos una vaga idea, unos días libres y mucha voluntad de conocer lo que significaba el Cocuy.

Según las guías que habíamos consultado el primer paso de la travesía era en Bogotá, la capital y consistía en conseguir los permisos en parques nacionales naturales de Colombia para el ingreso al parque; me imagino que tú estás acostumbrado a hacer esta clase de trámites vía internet sin filas, ni llamadas, ni bancos...pero Mike, nosotros todavía no tenemos esa fortuna. De tal modo que para realizar los trámites fue necesario invertir otro día adicional, entre llamadas en espera y fotocopias de los carnés estudiantiles pasando por pagos en bancos congestionados se pasó el primer día cuya recompensa fue una sonrisa de la funcionaria, imagino al ver mi emoción, más un papel llenos de firmas y sellos con nuestros nombres en él. Era como un contrato para compartir el paraíso.

Salimos esa misma noche del terminal de transportes de Bogotá, no sólo por los consejos recibidos sino por la poca frecuencia con la que salen buses a tan misterioso destino, en resumen, no teníamos mucho de donde elegir, sin embargo el bus cumplía con todos los requisitos exigidos por el viajero interurbano: era amplio, cómodo, barato y veloz. El viaje de ida transcurrió con total normalidad hasta Duitama, ciudad central e imponente de Boyacá, donde el conductor decidió tomar alrededor de una hora, suponemos para alimentarse y descansar, todavía ni el ni nosotros imaginábamos las hazañas y aventuras de las que él sería protagonista horas adelante. De tal modo siguió el viaje pasando por los pueblos de Soatá y Capitanejo que representaban hitos cada vez más cercanos a nuestro destino final. Fue allí, en la carretera Capitanejo - El Espino donde pudimos haber hecho parte de las tristes estadísticas de accidentes de transito a manos del transporte público y en este caso no era por velocidad, imprudencia o alcohol; era por el mal estado de la vía. Míralo de esta manera: un peñasco de varios metros de alto por cuyos pies pasaba un río, una curva de más o menos 270 grados sumado con un carril de exactamente la misma anchura que nuestro bus. Naturalmente la primera reacción del señor conductor fue frenar, luego cautelosamente trató de encarar el obstáculo con tan mala suerte que rozó reventando uno de los vidrios panorámicos de los pasajeros, precisamente el vidrio trasero al asiento de mi amiga Estefania. Con el estallido del vidrio todo el bus levantó de un profundo sueño casi instantaneamente y fue allí donde aparecieron los guías, los consejeros, los pesimistas y los atemorizados todos con un único foco de atención, el señor conductor. Minutos más tarde mágicamente logramos pasar por aquel trecho y más adelante levitaríamos por unos pequeños puentes de madera que con el rodar de la llanta parecían caer.

Continuamos con rumbo al espino y más adelante los pueblos de Guacamayas y Panqueba para finalmente luego de aproximadamente 13 horas llegar a nuestro destino final: San Gabriel del Cocuy. Este pueblo definitivamente tiene una historia curiosa y llamativa. Por si no lo sabías Mike, fue la cuarta población “legalmente” fundada por los españoles en su genocidio (o conquista, me da igual) por Colombia en el primer trimestre de 1541, imagínate cuando en el Perú todavía luchaban contra el Inca Manco II, el fugitivo. Además cuentan los pobladores que fue unos de los pueblos pioneros en disfrutar del lujo del automovil ya que se dice que el primero de éstos fue traído a lomo de mula por una pareja de hermanos casí simultaneamente que en las principales capitales del país.

Pero no fue mucho lo que logramos disfrutar de tan agradable población porque apenas entramos al pueblo vimos en marcha a nuestro siguiente medio de transporte saliendo de la plaza central, el camión lechero. De tal modo que tomamos nuestro equipaje y corrimos unas cuadras para subir a dicho camión. Compartí por varios minutos de pie con pobladores de la región que al igual que nosotros lo utilizaban para desplazamientos entre fincas y veredas. Ahora entiendo algo que me dijeron posteriormente de acuerdo a la escala de comodidad que se maneja durante el viaje: uno empieza en un bus amplio, cómodo, saliendo de una autopista de ocho carriles en Bogotá y va pasando sucesivamente a cuatro, tres, dos y un carril en carretera destapada en un camión incómodo en el Cocuy. De todos modos fue nuestro primer contacto tanto con la gente como con los paisajes además tuvimos tiempo de presenciar el inicio del proceso de producción de una de las principales recursos de la región: la leche.

Finalmente luego de casi 1 hora y 45 minutos en lechero llegamos a nuestro destino final, ahora sí, Hacienda la Esperanza. Una finca vecina del parque nacional natural que ha pasado de generación en generación desde mucho antes inclusive de la existencia del parque. La casa tiene alrededor de 100 años y consta de un patio central, varias habitaciones, cocina, comedor, baños y un segundo piso todo a la antigua.

Ese mismo día conocimos a Don Marco Arturo, actual propietario de la finca y padre de dos compañeros de colegio de Laura y Estefania. Dada nuestro corto periodo de estadía y nuestras ganas de conocer fue suficiente con un buen desayuno para empezar nuestra expedición. Don Marco nos propuso ir a “La Cuchumba” santuario popular y punto de peregrinación. Omar, nuestro primer guía era joven y callado, sin embargo conocía perfectamente de memoria el camino. La cuchumba consiste en un monumento a la virgen, una cueva y una caída de agua recién nacida en el nevado. La cueva está repleta de cruces, retratos de la virgen y yerbas, lo que le da un ambiente místico y mágico. Dice la leyenda que fue encontrado un retrato de una virgen morena que los indios uwa adoraban y el motivo de su color eran las yerbas que quemaban en su honor.

Encadenando atributos tipo Map con Spring MVC y Hibernate Annotations

2007-11-30T01:52:00.000-05:00

Suele suceder algunas veces que nuestro modelo de clases en Java algun atributo representa parejas tipo llave, valor donde la llave (como su nombre lo indica) es única. En el mundo relacional esto se ve frecuentemente representado con tablas muchos a muchos con un atributo adicional que guarda el valor de la llave, es decir, de la forma Entidad, Llave, Valor. Una posible solución para solucionar este problema de impedancia y asumo que la más usuada hace unos años era tener una clase adicional que tuviera las relaciones y el valor, sin embargo, para que modificar nuestro modelo de clases para ajustarlo a la base de datos si existen herramientas como Hibernate?

Despues de leer la documentación y de mirar en los foros, encontré un post muy acorde a lo que me estaba imaginando como solución:


@ManyToMany
@MapKeyManyToMany(joinColumns={@JoinColumn(name="Dato",unique=true)})    @JoinTable(name="Dato_Proceso",joinColumns={@JoinColumn(name="Proceso")},inverseJoinColumns={@JoinColumn(name="AnotacionPaso")})   
    private Map datos = new LinkedHashMap();

Siempre que codifico este tipo de anotaciones pienso que cada línea de código en hasta un 100% más costoso que una línea de código común y corriente, pero bueno, eso es tema para otro post; más bien veamos que significan.

Al decir @ManyToMany se está especificando que el atributo respectivo al valor del mapa no es uno primitivo, para lo que se usaría la anotación @CollectionOfElements, sino una referencia muchos a muchos. @MapKeyManyToMany indica que se trata efetivamente de un mapa cuya llave es una referencia a otra tabla y cual es su columna de join así (joinColumns= {@JoinColumn(name= "Dato"}). @JoinTable es un viejo conocido para todos los que han manejado relaciones muchos a mucho automáticamente con Hibernate, simplemente dice que estas asociaciones se encuentran en una tabla aparte; pero ojo con inverseJoinColumns que indica la referencia dependiente en este caso la llave del mapa. Ya con esto no es más por el lado de la persistencia de datos.

Ahora el problema es como pasar del HttpRequest al modelo de objetos, otro problema de impedancia. Para esta tarea fueron creados la mayoría de los Web Frameworks. Spring MVC es uno de ellos y como es de esperarse se integra perfectamente con el contenedor IoC de Spring. SpringMVC usa un mecanismo de binders y editores los cuales se registran ante el controlador y al momento de ser necesitados para encadenar/escribir datos son invocados. Todo esto suena bastante fácil sobre todo cuando los tipos de los datos son primitivos o triviales como Strings, enteros, flotantes, arreglos y hasta algunas colecciones o clases definidas en la aplicación; para las cuales es necesario implementar una clase anonima traduciendo la cadena recibida al objeto en Java. Pero que pasa cuando el atributo es un Map?

Buscando en el API encontré una clase de utilidad que parecía servir para este propósito CustomMapEditor la cual, similar al editor de colecciones, ofrece dos métodos uno para convertir la llave y otro para convertir el valor. Sin embargo, al momento de utilizarlo noté mediante el logger que no se estaba llamando ninguno de los dos métodos, que raro...más raro aún fue no encontrar suficiente documentación o algun ejemplo.

Strike 2, si no hay un editor para mapas se puede intentar usar las convenciones de jstl para mapas que se resumen en: mapa[llave] = valor. De modo que luego de cambiar los parametros enviados en la página web y de registrar los editores respectivos a las clases involucradas en el mapa funcionó el mapeo.

Conclusión. El manejo de atributos tipo Map puede ser complicado y hay que conocer algunos trucos para que los mapeos sean adecuados tanto de la página web al objeto java como del objeto java a la base de datos, de todos modos piensó que es una manera más OO y limpia que la solución contrapuesta de crear una clase aparte.

Usando Dojo 1.0

2007-11-24T11:41:00.000-05:00

Una vez anunciado dojo 1.0 y aprovechando el inicio de un nuevo proyecto decidí echarle un vistazo a los cambios realizados en la nueva versión, tanto a nivel de API como de look and feel. Indiscutiblemente implantar dojo en un página web requiere una alta curva de aprendizaje y sobre todo saber que recursos se tienen en caso que algo salga mal, sin embargo yo había tenido algo de experiencia en las versiones previas y conocía la ideología y conceptos detrás de la herramienta. A continuación voy a presentar, en mi opinión y experiencia, los cambios más significativos en la librería, sin embargo puede ver una descripción mucho más detallada en el sitio de dojo.

Dojo (Core)

Incluye mejoras en el mecanismo básico de comunicación XHR (Xml Http Request) con dos nuevas funciones de la forma dojo.xhrGet y dojo.xhrPost que permiten enviar pedidos asyncronicos al servidor reemplazando en viejo y conocido dojo.io.bind. En comparación con versiones anteriores este cambio me parece facilita la labor del desarrollador ya que es mucho más claro en términos de sintáxis y de uso; así mismo los casos de error se pueden atrapar de manera más explicita y se da la posibilidad de configurar un tiempo de espera máximo.

Soporta por defecto e incentiva el uso de "repositorios" de datos (dojo.data). La idea es trasladar parte de los datos del servidor al cliente en un formato que tenga una implementación Store Read y Write, luego y mediante consultas sofisticadas en JavaScript se puede obtener el conjunto de datos desados discriminados por cualquier criterio similar a SQL. Un caso muy concreto donde se puede ver el aporte de está técnica es en elementos HTML como selects o tablas donde el render del muchos elementos HTML puede significar lentitud. Va muy de la mano y en dirección de la propuesta de dojo.offline

Otro aspecto muy importante y fundamental, sobre todo para propósitos de depuración y corrección, es la integración con firebug lo cual permite mediante llamados a la función console.log o console.debug ver qué está pasando, cuándo y en dónde. Particularmente me ha parecido extremadamente útil la posibilidad de imprimir objetos DOM o Json completos en la consola y tener la capacidad de ver su estado interior.

Dijit (Widgets)

Personalmente considero que es el área en donde más se avanzó no solo en términos de look and feel con la inclusión de temas sino también en el API para acceso y modificación programática. A la fecha he usado los siguientes:

TextBox
Es una caja de texto con validación de formato integrada. Hay varias implementaciones disponibles como por ejemplo de fechas(DateTextBox) de horas(TimeTextBox) de Números(NumberTextBox) o si ninguna de ellas se ajusta cuenta con un atributo regExp para incluir validaciones dada una expresión regular. Muestra los mensajes de validación en un Tooltip.

TextArea
Es un textarea que se va ajustando dinámicamente al contenido. Puede contener saltos de línea

Dialog
Similar a los ModalDialogs de IE pero con un botón de cerrar y dentro de la misma página en una etiqueta DIV.

Tooltip
Son mensajes cortos y contextuales que brindan ayuda.

Tree
Estructura los datos en forma jerárquica de árbol.

DojoX

Sólo he usado los componente Loader, un div que identifica cuando se hacen pedidos asincrónicos y muestra un mensaje y un gif animado mostrando que la página se está cargando y el LightBox, un dialogo para mostrar imágenes que se adapta a las dimensiones de cada imágen y provee controles para adelantar, retroceder y cerrar. Me han parecido geniales y útiles. Cabe anotar que como dice en la documentación estos API pueden cambiar en cualquier momento y requieren estilos adicionales a los del tema.

Que sigue...

Lo primero que me propuse hacer es empezar a mejorar el rendimiento y la velocidad al cargar el código Javascript. Para esto voy a hacer un build personalizado y a comprimir mi código javscript usando herramientas como shrink safe, posteriormente se puede automatizar este proceso invocando una tarea de Ant.