dev \ efor monitoriza tus desarrollos .NET

Cada vez programo menos. Si bien sigo siendo una auténtica puta del teclado, pico mucho menos código que antes, digamos que mis servicios han sido reorientados hacia...buffff, no lo sé ni yo, dejémoslo estar así ;-).

Así todo, siempre he opinado que programar o desarrollar aplicaciones software (que suena mejor...) es un hábito del que ningún informático debería nunca renegar. Tod@s, algun@s durante más tiempo, otr@s con menos suerte y gloria, hemos pasado por la etapa en la que picar o tirar líneas de código a machete era nuestra labor principal, por no decir, única labor. Los que habéis pasado por el mundo de la consultoría como programadores junior me imagino que me entendéis, ¿verdad? Es la rampa de salida inicial de much@s informátic@s, su entrada al ruedo del apasionante mundo del desarrollo de software.

Por ello, aunque cada vez veo menos el splash screen de IDEs como Visual Studio o Eclipse, soy de los que intenta no descolgarse demasiado de los avances que se van dando en este campo. Quizás luego no lo ponga en práctica yo, ni siquiera llegue a instalarme ese último service pack o plugin que ha salido para hacer no sé qué historia, pero al menos, me auto-obligo a mantenerme al día en el ámbito del desarrollo de software, que con todos los cambios que hay, día sí y noche también, no es moco de pavo ;-).

Dicho esto, tras leer ayer un post sobre ALM del amigo Lobosoft que me hizo desempolvar una tarea y correspondiente post pendiente, hoy os paso a presentar uno de los últimos descubrimientos que he realizado en mis esporádicas pero intensas "rondas de vigilancia tecnológica" en el mundo del desarrollo de software": Dev \ efor. La susodicha asegura ser un plugin gratuito (aunque leo que sacarán la correspondiente versión comercial) para Visual Studio 2005/2008 que monitoriza el progreso de tu desarrollo software. Suena bien, ¿no?

Aunque no soy de los siguen a rajatabla ninguna métrica de calidad de código, en el pasado sí que he utilizado herramientas como FxCop (¡thanks titán!), que te ayudan a mejorar tu código con una serie de buenas prácticas, consejos, etc. Por eso, quizás rememorando (¿y añorando?) el pasado, esta utilidad gratuita me llamó en seguida la atención. Aseguran que este plugin mide, analiza y presenta en diferentes formatos, métricas de desarrollo de software siempre interesantes: cuánto tiempo hemos pasado con cada proyecto de Visual Studio, cuántas líneas de código hemos tirado esta semana, qué evolución sigue la calidad del código que estamos generando, etc. Las métricas de código que utiliza el plugin están basadas en Visual Studio Team System Code Metrics, por lo que parecen bastante fiables, de ahí que puedan servir para coronar a un@s y sacar los colores a otr@s ;-).

Hoy admito que no he hecho los deberes y que no he llegado ni siquiera a instalar el plugin, con lo que no os puedo dar un feedback más empírico. Hoy, como veis, simplemente quería lanzar un guante tecnológico ;-). Aún así, conociéndome cómo soy (nostálgico que de vez en cuando abre el Visual Studio 2008 para desarrollar cualquier C# CCA (Chorri-Console Application), seguro que acabo instalando el plugin y monitorizando mi propio código. ¡Qué peligro! ¿Seré productivo programando? Tranquil@s, prometo que si dev \ efor me dice que soy un pocket programmer (programador paquete), muy a mi pesar, prometo...que lo contaré, transparencia hacia los lectores 100% ;-).

Si alguien ya conoce o ha utilizado dev \ efor o herramientas de métrica de código similares, no hace falta decir que sus impresiones y comentarios serán más que bienvenidos...

SaludoX.

Si quieres estar meta-informado y volverte enfermo crónico vía RSS, suscríbete al Txoko de Lonifasiko .

MaxPermSize reserva memoria permanente

El lunes os hablaba de un intercambio de mails curioso gracias a la inmediatez e importancia de Twitter, anécdota que venía precedida por la mediocre impresión que me causó la live demo de JBoss Portal. Esto no podía quedar así, por ello, para quitarme el mal sabor de boca tecla, tal y como le prometí al amigo Tomás, hoy he sacado un ratín para hacer mis primeros pinitos con JBoss Portal. Las de hoy no han sido pruebas exhaustivas, pero la impresión a decir verdad sigue siendo mala no muy buena. Ahora explico por qué...

El primer paso ha sido bajarme un bundle o paquete que ya contiene una instancia preconfigurada de JBoss Portal 2.7.0 GA "desplegada" (I mean deployed...) bajo un servidor de aplicaciones JBoss 4.2.3, otro producto cañerito del fructífero matrimonio JBoss-RedHat. Como ya he aprendido la lección, ahora soy de los que empiezan por leerse el típico quickstart o manual de referencia con las acciones básicas para saber por dónde agarrar el embolao. Por lo que dice en el documentillo, tan sencillo como descomprimir el archivo descargado, acceder a la carpeta "bin" y ejecutar el típico run.bat si estamos en Windows (es el caso) o run.sh si estamos enel lado oscuro ;-), es decir, lo de siempre. Ésta es una de las cosas buenas que tienen los proyectos opensource, más concretamente, los proyectos relacionados con Java: la forma de arrancar un servidor de aplicaciones, el proceso de deploy de las aplicaciones, e incluso la estructura de directorios y el nombre de los archivos, es muy parecido casi siempre, con lo que en poco tiempo te quedas con la idea general. Lo dicho, que la idea está asumidisima hace tiempo, en cambio...

Como se aprecia en la imagen, en el log del servidor de aplicaciones JBoss, la flecha roja indica que JBoss AS ha arrancado sin problemas. Normalmente, ver un mensaje de este tipo en la consola suele indicar que el servidor está listo para que le den cañita brava. Precisamente eso es lo que he hecho, ya que siguiendo el manual, he accedido directamente a la URL inicial de JBoss Portal, http://localhost:8080/portal, con toda la ilusión del mundo por ver mi tesoro, digo, mi portal, en acción. Para mi desesperación, tanto Firefox como Explorer no son capaces de mostrarme nada, con lo que vuelvo a la consola para comprobar que los errores de tipo OutOfMemory campan a sus anchas por JBoss AS. En serio, no acabo de entender eso de que te bajes una demo preconfigurada de Internet, sigas las instrucciones de pé a pá, la arranques como Dios manda, y no veas nada, sólo las típicas y feas excepciones lanzadas por Java; I can't believe my eyes...

Menos mal que el texto OutOfMemory lo dice todo, con lo que en seguida he ido a inspeccionar el contenido del fichero run.bat, que es donde se le indica a JBoss qué JDK utilizar, qué variables de entorno configurar, y lo más importante, con cuánta memoria arrancar y el  máximo a reservar. Claro, en seguida veo la línea que puede estar dando guerra:

Traduciendo esto a lenguaje pseudo-natural: JBoss AS inicia (-Xms) el heap o cantidad de memoria reservada para la Java Virtual Machine a 128 Mbytes de RAM, permitiendo que este tamaño de pila o heap crezca hasta un tamaño máximo (-Xmx) de 512 Mbytes. ¡Pues parece que el niño no tiene suficiente!

Siguiendo los sabios consejos del compi situado a mi izquierda, el primer intento es equiparar el mínimo de memoria necesaria con el máximo permitido, es decir, poner los dos parámetros a 512. Reinicio de JBoss AS...,¡qué va, tampoco carbura! Entra entonces en liza desde el lejano Oeste, un nuevo consejo que acepto de muy buen grado: mantener equiparados los parámetros inicial y máximo, y probar fortuna con el parámetro MaxPermSize, un parámetro que sin saber a ciencia cierta a qué hace referencia exactamente, sabemos que ha dado buen resultado en otras ocasiones digamos que problemáticas ;-). Por tanto, la línea relativa a asignación de memoria de JBoss AS del fichero run.bat queda de la siguiente manera:

set JAVA_OPTS=%JAVA_OPTS% -Xms512m -XX:MaxPermSize=256m -Xmx512m

Se arranca de nuevo correctamente JBoss AS, accedo a la URL inicial..., ¡y por fin veo la luz! 

Qué bonito, ¿eh? Por fin tengo JBoss Portal up and running para exprimirlo y evaluarlo hasta límites insospechados, en otras palabras, listo para hacerle mil y una putadas ;-). 

Le debo una a mi compi, y otra a MaxPermSize, que según lo que explican claramente en esta página, indica el tamaño máximo de la memoria non-heap (también conocida como PermGen), en definitiva, el tamaño máximo de "memoria permanente" asignada a la JVM. 

Esperad, que ahora que tengo a JBoss Portal vivito y coleando, llega la prueba de las pruebas, una pequeña maldad que sólo se le ocurre a usuarios cabrones y enrrevesados como yo: Paro JBoss AS, mato el  proceso java.exe que anda dando vueltas por ahí, vuelvo a editar el fichero run.bat para dejarlo tal y como venía "de fábrica"(set JAVA_OPTS=%JAVA_OPTS% -Xms128m -Xmx512m), arranco de nuevo JBoss AS con esta nueva configuración y..., ¿qué creeís que ha pasado? Lo que me temía, aunque no me explico por qué, JBoss Portal ahora funciona de perlas, cuando la primera puesta en marcha tras la descarga inicial ha sido un auténtico desastre.

¿Explicación? Lo único que se me ocurre es la NO volatilidad del parámetro MaxPermSize, es decir, visto lo visto, entiendo que MaxPermSize modifica la memoria permanente asignada a la JVM, y JVM guarda (en este caso) esta configuración entre distintas sesiones o arranques, dándole igual que el parámetro desaparezca del run.bat y que se termine el proceso java.exe por las bravas. En otras palabras, un parámetro muy a tener en cuenta a la hora de lidiar con problemas de memoria muy típicos de las aplicaciones Java.

¿Conclusión? Aparte de la lección del parámetro MaxPermSize, y aunque al amigo Tomás no le haga gracia, he de decir que JBoss Portal se está cubriendo de gloria conmigo; no es normal que te bajes una demo configurada y que eso no funcione ni a tiros. Es más, diría que JBoss Portal está a puntito de ingresar en la "lista negra de Lonifasiko", de la que, aviso para aplicaciones navegantes, es realmente difícil salir ;-).

SaludoX.

Si quieres estar meta-informado y volverte enfermo crónico vía RSS, suscríbete al Txoko de Lonifasiko .

Eclipse diferencia plugins de dropins

Si hay una cosa que me fascina de los proyectos opensource es la gran capacidad que tienen para admitir "cambios en caliente" así como las facilidades que ofrecen para mejorar la experiencia del usuario gracias a los plugins y extensiones. Normalmente es tan sencillo como descomprimir un archivo bajo cierto directorio, como mucho tocar un fichero de configuración XML, y ¡voilá! Plugin funcionando perfectamente a las mil maravillas. Como digo, me encanta esa filosofía de intentar hacerlo todo más fácil y configurable para el usuario.

Este modo de funcionamiento, o mejor dicho, esta filosofía de desarollo, se personifica claramente en proyectos de la talla de Mozilla Firefox o Eclipse. Sin ir más lejos, en este último proyecto, ¿qué desarrollador no conoce la subcarpeta "plugins"?

Esta mítica y mística carpeta es el máximo exponente de lo que puede llegar a ser un auténtico repositorio de extensiones super útiles que nos permiten desarrollar todo tipo de aplicaciones software bajo este excelente IDE. Además de poder desarrollar en el sempiterno Java, estos addins nos permiten programar en C++, Python, crear aplicaciones para la plataforma J2ME, para la tan de moda Android, Pentaho BI, etc. Eclipse se ha convertido en los últimos años en el IDE opensource más versátil, plural y configurable en la historia del desarrollo del software. Que conste que yo soy de la "escuela Visual Studio", que dicho sea de paso, es una maravilla, pero he de admitir que Eclipse está muy pero que muy bien.

Total, que andaba yo la semana pasada con ganas de trastear con Google Web Toolkit, un web framework del que había oído hablar que permitía desarrollar de forma muy sencilla, en Java, aplicaciones AJAX visualmente muy ricas. Como neanderthal que soy y porque me gusta ver las tripas de todo, primero probé los ejemplos sencillos "por fuerza bruta", invocando el runtime de GWT a machete, por línea de comandos; sin embargo, como supondréis, en los tiempos que corren, lo lógico es desarrollar aplicaciones GWT de forma algo más visual, por ejemplo, con el plugin actualmente disponible para Eclipse, denominado Cypal Studio for GWT.

Haciendo de nuevo el cavernícola y sin leerme el correspondiente manual de instalación, me bajo el plugin del invento y lo descomprimo bajo el directorio "plugins" que tanto adoro. "¡Pues vaya mierda, esto no funciona!" pienso al arrancar Eclipse y ver que no hay rastro del Cypal Studio éste. Empiezo a leer la documentación (como debía haber hecho desde el principio...) y en seguida me me topo con el requirement de que se ha de utilizar la versión Eclipse IDE for JEE Developers y como versión base mínima, Eclipse 3.3, requisitos que no cumplo ni de lejos con mi ya anticuado y clásico Eclipse 3.2.2. Toca actualizarse por tanto a la versión 3.4 de la plataforma, conjunto de releases denominadas con el codename de Ganymede.

Más de lo mismo, queda confirmado que Lonifasiko es el único animal que tropieza más de dos veces con la misma piedra: instalo la versión de Eclipse requerida, copio los tres ficheros .jar que componen el plugin bajo "Eclipse\plugins\", arranco de nuevo el entorno con "eclipse -clean" y... nueva decepción, no tengo plantillas GWT ni posibilidad de configurar en "Preferences" el flamante kit de desarrollo web de Google. ¿Lo siguiente? Lo típico, repetir los pasos anteriormente realizados con más cautela y prestando más atención a lo que estamos haciendo: cerrar Eclipse por si las moscas, borrar los .jar, volver a bajarme el .zip, descomprimir bajo el directorio "plugins" por sexta vez, y otro arranque en limpio del IDE. ¡Qué va, no hay manera!

Resignado (y de muy mala leche), acudo de nuevo a las instrucciones, aguanto como un titán párrafo tras párrafo, hasta que hacia el final de la página leo una nota relativa a las versiones Ganymede de Eclipse; esto seguro que me interesa...¡vaya que sí me interesa! La primera línea lo dice bien clarito: a partir de las versiones Ganymede, es decir, 3.4 y superiores, la forma de instalar los plugins se ha cambiado. Leo por ahí que ahora, el directorio plugins sólo va a admitir plugins en los que confía, es decir, de fabricantes más o menos fiables, seguros, "coleguitas". Esto implica que "los otros plugins", los plugins no oficiales, irán obligatoriamente bajo la carpeta dropins, teniendo que crear a mano incluso su propia estructura de directorios.

¡Manos a la obra! Siguiendo las instrucciones, creo bajo "Eclipse\dropins" una carpeta denominada "Cypal", y dentro de ésta, otra carpeta denominada "plugins" (lo sé, ¡menudo lío!). donde planto los tres .jars que tanta guerra me están dando:

Vuelta a arrancar por enésima vez Eclipse "a ras" y ya tenemos, por fin, el plugin de Cypal Studio ready para perrear con el super entorno de Google Web Toolkit:

Así que ya sabéis, con versiones de Eclipse 3.4 o superiores (cualquier release de Ganymede o superior), si el plugin a utilizar es "no oficial", olvídate del directorio "plugins" de toda la vida y pásate a "dropins", que la cosa se ha puesto seria y Eclipse ya no se fía ;-).

SaludoX.

Si quieres estar meta-informado y volverte enfermo crónico vía RSS, suscríbete al Txoko de Lonifasiko .

Entregar o no el código fuente

Hoy domingo, voy a intentar, por una vez en la vida del blog, escribir un "post-pregunta" corto y un tanto controvertido. Me interesa más que nunca conocer la reacción y pensamiento de los frequent readers del blog, con lo que espero que el tema se debata en profundidad en los comentarios.

Allá voy: ¿Hay que entregar el código fuente de una aplicación software al cliente? Aunque parezca algo trivial, os juro que el asunto de la entrega del código fuente siempre es algo peliagudo. No me refiero a distribuir las librerías opensource o cierta funcionalidad de un software propietario que se ha utilizado en el desarrollo de la aplicación, ya que ahí entramos en el complicado terreno de los miles tipos de licencias específicas que existen a día de hoy. Librerías aparte, me refiero a la entrega del código fuente de la aplicación en su conjunto, al "conocimiento adicional y específico" generado para el cliente, en pocas palabras, la base, el "corazón" de la aplicación.

Digo controvertido, porque muchas veces directamente este punto o término ni siquiera se especifica en el contrato formal con el cliente; un vacío "legal" muy peligroso, ya que la empresa desarrolladora dirá que no tiene por qué darlo, mientras que el cliente, al ser el pagador, dirá que tiene derecho a él.

Pienso por tanto que la entrega o no entrega del código fuente es un punto que se ha de especificar claramente en el contrato que se firma con el cliente; conviene hacerlo porque luego siempre hay confusiones, malentendidos y malos rollos entre las partes implicadas, y tampoco es plan..., por lo que es mejor dejar todo "atadito" incluso antes de empezar a tirar las primeras líneas de código. En caso de acordar la cesión del mismo, opino también que dicha entrega de conocimiento debe de alguna manera facturarse; y si no se especifica nada, sorry but there is no source code, así de simple.

La pregunta que os dejo hoy es bien clara y obvia: ¿Qué opináis al respecto? ¿Qué soléis hacer en vuestros proyectos, en vuestra organización? La piedra está lanzada...

SaludoX.

Si quieres estar meta-informado y volverte enfermo crónico vía RSS, suscríbete al Txoko de Lonifasiko .

Proyectos de instalación al rescate

¿Cuántas veces hemos desarrollado una aplicación que en nuestro PC funciona perfectamente y al llevarla al PC de al lado (no digo ya llevarla al PC del cliente...), pega un pete brutal? A mí y a otros compañeros míos nos ha pasado en innumerables ocasiones. Sí, aunque somos muy bueno@s programando ;-), de vez en cuando también nos ocurren estas fatalidades.

"¿Qué librería o fichero de configuración me habré olvidado de copiar?", "¿habrá que copiar esta maldita librería bajo "Windows/System32?", "¿será necesario registrar el control ActiveX de marras con regsvr32?" Son las típicas autopreguntas que azotan la maltrecha cabeza del programador después de un disgusto de tal calibre.
Después de intentar aplastar el PC (e incluso valorar la utilización del panic mode si hay demo a la vista), normalmente el programador acude a herramientas míticas como Dependency Walker. No lo vamos a negar, es una grandísima utilidad que analiza todas las dependencias que tiene un ejecutable o librería Windows, aunque muchas veces no es suficiente para dar con la dependencia concreta que está dejando tu programming reputation a ras de suelo.
Lo siguiente en la checklist post-instalación fallida es empezar a pensar cosas raras...que si las meigas de Visual Studio...e incluso plantear que sin Visual Studio instalado en la máquina destino la aplicación nunca funcionará. ¿Comorrrr? ¿He oido bien? Esta afirmación es muy pero que muy grave, atenta contra todo proceso lógico de desarrollo de software; una cosa es el entorno de desarrollo (donde tendremos un IDE, etc.), y otra muy distinta, el entorno de producción, donde es inaceptable que haya que instalar el IDE de Visual Studio para que la aplicación funcione. Meigas, haberlas haylas, por ello, buceando por la red, uno se encuentra con historias terroríficas que cuentan que si desarrollas en C++ en una máquina con Visual Studio 2005 SP1 instalado, en la máquina en la que vaya a correr ese software es necesario instalar un pequeño runtime adicional denominado"Microsoft Visual C++ 2005 SP1 Redistributable Package", que ojo, no es lo mismo que instalar Visual Studio enterito, lo cual vuelvo a repetir, es inaceptable.

Bien, la última movida que hemos tenido no se solucionaba ni instalando este redistributable ni rezando a la Virgen de Lourdes, no había manera de arrancar aquello. ¿Cual ha sido entonces la solución final, ésa por la que quizás teníamos que haber empezado? Añadir a la solución (.sln) de nuestra aplicación un nuevo proyecto de instalación, un setup project de toda la vida:

De veras, este tipo de proyectos son muy útiles, son realmente fáciles de configurar y compilar; de hecho, la mayoría de las veces basta con arrastrar el output de tu proyecto principal (ejecutable, DLL...) al proyecto de instalación, que ya se encarga Visual Studio de arrastrar todas (o casi todas) las dependencias de dicho output. ¿Que crees que te has dejado alguna? ¿Algún fichero de configuración...? No pasa nada, añades todo lo necesario "a mano" en el proyecto de instalación y listo. Compilas el proyecto y si todo ha ido bien, verás que por defecto se genera un archivo de instalación con extensión .msi y otro denominado setup.exe. Llevar estos archivos a la máquina destino (en CD, pen-drive o lo que queráis), ejecutar el .msi y efectuar la instalación por defecto siempre será más fiable y elegante que el método por fuerza bruta. ¿Qué más quieres? Tu aplicación sube un escalón en glamour con ese aspecto profesional de la instalación en plan wizard, y tú tienes menos probabilidades de sufrir un infarto ;-).

Resumiendo este alegato de defensa en favor de los proyectos de instalación de Visual Studio: si desarrollas con Visual Studio 2003/2005/2008, sobre todo en C++, créate un setup project para realizar la instalación y deployment de tu aplicación, te ahorrará disgustos y caras de póker ;-)

Ésta es mi humilde opinión, pero ¿utilizáis vosotr@s los proyectos de instalación o sois de los que copian el contenido de la carpeta a la máquina destino por fuerza bruta y cruzan los dedos? No os cortéis, lo hemos hecho tod@s ;-).

SaludoX.

PD: Thanks Dinho...

Si quieres estar meta-informado y volverte enfermo crónico vía RSS, suscríbete al Txoko de Lonifasiko .

Panic Mode siempre a mano

Por desgracia panic mode no es un término que haya tenido yo el honor de acuñar; sin embargo, poco a poco me voy dando cuenta de que forma parte ya de mi vocabulario informático, de mi diccionario tecnológico elemental (...querido Watson). En mi caso, utilizo panic mode para definir aquella situación altamente embarazosa y de alto riesgo que se produce cuando hay que hacer una demo importante de una aplicación software (se podría aplicar a otros campos) e inexplicablemente el software que hasta hace cinco minutos funcionaba, misteriosamente deja de funcionar. ¿Os suena verdad? En el mundillo de los programadores, este escenario también se conoce como "efecto demo". Seguramente tod@s hemos vivido alguna vez esta situación que deja tus conocimientos de informática o de lo que sean a la altura del barro.

Te puede ocurrir en una demo ante tu jefe en la que te juegas el aumento de sueldo; imprevisiblemente puede aparecer cuando estás a punto de cerrar un contrato con ese cliente tan importante al que ya has engatusado con una buena mesa y buen vino; o peor aún, hace acto de presencia cuando estás a punto de "ilustrar" a tus propios compañer@s, con los que, con toda la razón del mundo, quedarás como el culo ;-).

La mayoría de las veces la catástrofe viene provocada por una tontería, un fallito mínimo que con calma descubriríamos en pocos minutos, pero lo cierto es que nos ha tumbado todo el sistema, y la situación y sobre todo, tu cara, lo dice todo. Es una situación agónica en la que por lo general la mente del programador se queda en blanco y no es capaz de pensar en ningún tipo de solución de forma rápida. Sólo quiere que termine el mal rato e irse para su casa...donde cenando o dándose un baño revitalizante se le iluminará la bombilla y se dará cuenta de por qué ha fallado su maldito software. Los juramentos en arameo que vienen a continuación forman parte del clásico pack del programador cabreado ;-).
A grandes males, grandes remedios, por lo que paso a explicar lo que hago yo para minimizar o solventar en la medida de lo posible estas situaciones nada agradables que sufriremos durante nuestra larga vida como desarrolladores. Significar que más que una solución, os voy a explicar lo que últimamente acostumbro a hacer para intentar remediar el temido efecto demo.

Se trata simplemente de tener preparada siempre una puerta trasera, una escapatoria como las del circuito de Mónaco. Todo esto viene gracias a que soy bastante fanático (queda mejor metódico) con los ficheros de configuración de las aplicaciones de software, de hecho, siempre intento que gran parte de la aplicación sea configurable por parte de los usuarios y que puedan cambiar ciertos parámetros de la aplicación sin tener que recompilar de nuevo todo. Es muy útil y versátil eso de que un usuario pueda poner los iconos e imágenes que más le gustan, pueda configurar el path donde se genera ese fichero temporal, o cuando se actualiza una URL a la que el programa llama, sólo tenga que cambiar ese parámetro, guardar el fichero y listo. Se dice que las aplicaciones que permiten esto soportan "cambios en caliente", es decir, que no hay que recompilar la aplicación para que coja los nuevos valores. El formato o base estándar de estos ficheros de configuración es en la mayoría de los casos XML, aunque hay variantes como los .properties de Java o los .config de Microsoft .NET.

A lo que voy es que en todas mis últimas aplicaciones he incluido en el fichero de configuración un parámetro denominado "PanicMode", just in case. Su funcionamiento es bien sencillo: si su valor es "0", el modo de funcionamiento de la aplicación es el normal, el esperado; en cambio, si editamos el fichero y ponemos el flag a "1", quiere decir que ha ocurrido una catástrofe, que activamos el plan de emergencia ya que estamos en pleno panic mode. Claro, no es sólo cambiar este valor y listo. ¿Qué implica poner este parámetro a 1? Que en el programa hemos preparado con anterioridad un camino seguro de ejecución por el que sabemos que no va a (debería) haber errores.

Imaginemos por un momento que en plena demo crucial para el futuro de la empresa nos tenemos que conectar a un web service externo securizado que nos devuelve una clave. ¿Qué ocurre si por lo que sea en ese momento se cae el web service o se cae nuestra LAN? Adiós demo y adiós cliente. Con lo fácil que es ser un poco precavido y emplear un poco de tiempo en guardar esa clave en el propio fichero de configuración (por ejemplo le llamaremos "PanicKey"), o en otro fichero temporal que tenemos preparado y escondido dentro de la maraña de carpetas del proyecto. Nadie se va a enterar, y aunque la demo puede que no quede tan espectacular ni dé tanta sensación de inmediatez, la aplicación funciona y te salva la papeleta...y la pataleta del cliente. Simplemente implica haber programado en la aplicación una sentencia condicional del tipo if (panicMode ==1). En este caso, la ejecución del programa estaría prevista, es decir, tendría un recorrido marcado por el que se saltaría la llamada al web service y cogería el valor directamente desde el fichero.

Os aseguro que esta clase de previsiones no es ninguna tontería y que te pueden sacar de muchos apuros. Además, no es muy costoso y haces que la aplicación sea muy configurable, cosa que muchos clientes y usuarios agradecen enormemente.

Aquí se despide un fan incondicional de la doctrina panic mode, una doctrina que todos los desarrolladores deberían admirar, venerar y por supuesto...¡implementar!

Así que ya sabéis, más vale panic modear que lamentar y llevarse malos ratos como esta señorita ;-)

SaludoX.

No olvides suscribirte al feed RSS para enterarte de todas las actualizaciones del Txoko de Lonifasiko .

Guía de instalación de Visual Studio 2008

Soy bastante lanzado a la hora de instalar cualquier tipo de programa en mi máquina, tanto en el curro como en casa. Esta manía o actitud (o depende cómo se mire, aptitud), tiene sus riesgos, pero soy así por naturaleza, soy un early adopter que lo prueba todo; , un conejillo de indias que le hace mil y una putadas a su PC instalando continuamente versiones Beta, Alpha, CTPs y RTMs de todo tipo de herramientas y utilidades que pilla.

Esta vez en cambio, me estaba sorprendiendo a mi mismo de lo mucho que estaba tardando en instalar Visual Studio 2008, el nuevo IDE o entorno de desarrollo de Microsoft lanzado allá por finales de Febrero. Sinceramente estaba muy a gusto con Visual Studio 2005 SP1, pero claro, no vaya a ser que me quede desfasado, fuera de la onda tecnológica, y por ello deje de ser "cool, hot y amazing". Así que esta semana me he puesto el buzo, he instalado Visual Studio 2008 y se me ha ocurrido la brillante (¿?) idea de compartir con tod@s vosotr@s todo el proceso de instalación de Visual Studio 2008, plus una serie de consejillos del abuelo Lonifasiko. Tan sólo comentar que VS2005 y VS2008 pueden convivir en perfecta armonía en la misma máquina; yo, por problemas de espacio en disco (en pleno 2008...), he "preferido" desinstalar VS2005. Allá vamos:

1.- Backup de proyectos de Visual Studio 2005. Soy lanzado pero no tonto, así que con lo baratos que están los CDs y DVDs, el primer consejo es realizar un backup de todos los proyectos desarrollados con Visual Studio 2005. Seguro que no pasa nada, pero nos curaremos en salud...

2.- Despedida de Visual Studio 2005. Abrimos por última vez (quién sabe en esta vida...) el gran (sí, gran) Visual Studio 2005.


Contemplamos "su apariencia" fijamente unos minutos, cerramos los ojos, alabamos todo lo que nos ha ayudado, nos cagamos en él por las que nos ha liado, y en el nombre de todos los IDEs...amén.

3.- Lectura del archivo readme. Será que me estoy haciendo mayor y más "segurola", pero últimamente estoy cogiendo la buena manía de abrir los archivos readme.txt, readme.html, o leeme.txt que todo software trae o debería traer. Le pego una lectura rápida en la que no veo nada raro, salvo alguna issue con las SDKs de Windows Mobile 6, cosa que apunto rápidamente para desinstalar antes de proceder.

4.- Limpieza previa a la desinstalación de Visual Studio 2005. Antes de procecer con la desinstalación de VS2005, con la idea de hacer bien las cosas y de paso "hacer un poco de limpieza" y liberar espacio en disco, he echado una ojeada a la fatídica lista de programas instalados con la opción "Agregar/Quitar programas". Después de exclamar en alto "¡qué de movidas tengo instaladas!", procedo a desinstalar "todo lo relacionado con VS2005". En mi caso, entre otras cosas desinstalo ASP.NET AJAX Extensions, el plugin MySQL Tools for Visual Studio, SQL Server 2005 Everywhere Edition CTP, el plugin AnkhSvn para trabajar contra Subversion, GPS.NET for VS2005, Enterprise Library for .NET Framework 2.0 (January 2006) y Microsoft Device Emulator.

Así mismo, fiándome del readme, por si las moscas quito Windows Mobile 6 Standard SDK y Windows Mobile 6 Professional SDK. Y ya que estamos de rebajas, por el mismo precio quito Microsoft Robotics Studio 1.5, del que ya tenemos sustituto CTP (sí, definitivamente estoy enfermo...). Lógicamente, todo esto que cuento depende de lo que tenga instalado cada uno en su máquina; yo cuento MI proceso de desinstalación/instalación.

5.- Reset. ¿Por qué? Porque yo no lo hice, y tan pronto como comenzó el proceso de desinstalación de VS2005...¡sorpresa!

¡Ah sí, ya me acuerdo! Aquellos controles que instalé cuando desarrollaba para Windows Mobile. También los he desinstalado en el paso anterior, pero por lo visto han dejado "su particular huella" en el registro de Windows., o donde sea. Por eso, después de haber desinstalado muchas cosas (entre 10 y 15) ...seguro que un buen reset no viene mal.

6.- Desinstalación de Visual Studio 2005. "Definitivamente te voy a echar de menos compañero...":


Pulsamos "Aceptar" con la lágrimilla en los ojos, y tras un buen (repito, un buen) rato...

La desinstalación termina y nos avisa de que puede haber otros componentes que requieran de una desinstalación manual. Ya puestos a tunear la máquina, me cepillo MSDN 2005, Microsoft Document Explorer 2005 y Microsoft Visual Studio 2005 Tools for Office Runtime.

6.- Instalación de Visual Studio Team System 2008 Development Edition. Nombre más largo no pueden sacar no...

Decimos unas cuantas veces amén (= pulsar "Next"), configuramos la instalación (de momento nunca he utilizado Crystal Reports)...

...y tras otra larga espera (menos mal que dejé de fumar...), pantalla de "instalación ok"...

...y tras pulsar victorioso "Finish", el típico "messagebox maligno"...

...que visto lo ocurrido en el Paso 5, me "invita" a hacer un...

7.- Reset. Pues eso, ¡reset!

8.- Visual Studio 2008 ready to go! Como esta vez he decidido que de momento no voy a instalar en local la ayuda de MSDN 2008 (el que quiera, que la instale), ¡despegamos! Selecciono en mi caso "C# a muerte"...

...and ¡we're in!


9.- Tomaros una buena cerveza (o lo que queráis), que os lo merecéis, este proceso agota.

Como he dicho antes, este proceso de desinstalación de Visual Studio 2005 e instalación de Visual Studio 2008 es relativo a MI máquina. Con ello os quiero decir que si alguien sigue esta "mini guía" (por llamarla de alguna manera) y no consigue instalar ni desinstalar todo lo que quiere, le cae un rayo al salir de casa, se le rompe la máquina, o la abuela fuma, me podéis escribir un comentario diciendo que no os ha funcionado (e incluso que soy un paquete), pero en absoluto me hago responsable de nada de nada. Si es que parezco un abogado ;-)

Por cierto, espero que lo aquí contado le sirva de algo a alguien. Ésa es la intención...

SaludoX.

DOR: Debug Or Release

El mismo colega (¡suerte en tu nueva etapa campeón!) que sacaba a la luz las carencias del método String.Replace me ha vuelto a poner a prueba con otra duda existencial sobre el fascinante mundo de Microsoft .NET y Visual Studio. No sé cómo lo hace, pero al final siempre consigue que me ponga cabezón y me pique con estos "retos tecnológicos" que me plantea:

Colega: "Miguel, ¿cómo puedo saber, sin tener el código fuente, si un ensamblado .NET, bien sea un .exe o una .dll que me han pasado, está compilada en modo debug o release?"

Miguel (con cara de póker...): "Joder tío, es que te pasan unas cosas...me vienes con cada preguntita...en serio, acabas antes si escribes un libro tronco..."

Colega: "¡Ja, te he vuelto a pillar tío! No, en serio, tranqui, no te piques ni pierdas tiempo con ello, era por si te sonaba alguna forma rápida de poder saber eso..."

Como me jode no poder ayudar a un compañero con una duda que a priori parece tan sencilla y evidente. ¿Que no pierda tiempo, que no me pique? No sabes lo que estás diciendo chaval...acabas de herir mi orgullo informático hasta lo más profundo, ese orgullo friki con tintes de batalla y autosuperación que todo informático posee (aunque algunos no lo saquen a relucir). Y es que si no fuera por estas aventurillas y mini-retos, ¿qué sería de la triste vida de un informático? Vamos allá...

Mirando por Internet y todavía con el orgullo malherido, en seguida encuentro este post que explica de maravilla cómo diferenciar las versiones debug y release. Una vez más, se cumple el principio básico de todo error o duda informática: "Mira por Internet, seguro que antes que a ti le ha pasado a alguien...".

Como bien indican en ese útil post, para saber si una librería o ejecutable .NET (hablamos siempre de managed code) está compilado en modo debug o release, sólamente hace falta leer los atributos del ensamblado (librería o ejecutable) en cuestión. Fiándome 100% de lo que dicen, basta con mirar el valor del atributo IsJITTrackingEnabled; si está a true, la .DLL o el .EXE están compilados en modo debug; si está a false, se trata de una versión release.

Para leer los atributos de un ensamblado .NET (.NET assembly), tenemos varias posibilidades:

• Utilizar alguna utilidad gratuita como Reflector for .NET. ¡Qué gran utilidad!
  
• Complicarse la vida y hacerlo mediante código .NET, cargando dinámicamente la assembly en cuestión y analizando sus atributos "al vuelo".

Al no tener nada mejor que hacer en este frío y lluvioso Domingo de Pascua (¡qué triste!), y porque en el fondo soy un "batallador informático" (¿?), he cogido prestado parte del código expuesto en el post del amigo Jim, y me he currado una pequeña utilidad que a través de una interfaz gráfica muy sencilla nos dirá si un ensamblado .NET está en versión debug o release. Ésta es la apariencia inicial de la aplicación:


Si pulsamos el botón saldrá un cuadro de diálogo donde podremos seleccionar el ensamblado .NET que queremos chequear:

Y poco más...una vez seleccionado el ensamblado .NET, la utilidad nos mostrará de forma gráfica si se trata de una versión debug (como en la imagen) o release:


Indicar que la aplicación sólo funciona para ensamblados .NET, es decir, para managed code, y que tan sólo necesita tener instalado .NET Framework 2.0 en vuestra máquina (lo tendréis ya instalado...). Os dejo tanto el ejecutable, como el código fuente de la utilidad (proyecto de Visual Studio zipeado) en mi espacio de SkyDrive.

Para aquellos temerosos del malware creado por desconocidos como yo, deciros que la utilidad es totalmente inofensiva; no os va a formatear vuestro disco duro, ni va a recopilar las credenciales de vuestra cuenta de GMail; como mal mayor, la aplicación pegará un pete brutal y os dejará con la miel en los labios, sin saber si el ensamblado era debug o release; lo siguiente será cagarse en mí mil veces y escribir un comentario en el post diciendo que soy una paquete ;-). ¡Pues vale! ¡Qué le vamos a hacer! Se aceptan todo tipo de críticas y comentarios...es la dura vida del blogger informático ;-)

SaludoX.

Los pixels de la discordia

¿Qué desarrollador no ha sufrido en sus carnes la mala uva de las distintas resoluciones de las pantallas? Sí, esos pixels de más o de menos que tanta guerra dan y que te pueden jugar una mala pasada dejándote en bragas ante el cliente más importante del mundo mundial. Y no hablo de aplicaciones web en las que es frecuente ver cómo bailan o desaparecen ciertos controles al pasar de Internet Explorer a Mozilla Firefox o al cambiar el tamaño del browser, sino de las típicas aplicaciones de escritorio, bien sean Windows Forms, estén programadas en Java, o en ese lenguaje de nombre psicodélico que acaba de salir y estás deseando catar.

En concreto, me refiero a los problemas con la resoluciones que suelen presentar esas aplicaciones que se utilizan "en plan demo", es decir, esa aplicación con la que queremos impresionar, dejar boquiabiertos y venderles el oro y el moro a nuestros mejores clientes, ésas que se suelen presentar a pantalla completa, en modo maximizado, en enormes pantallas de plasma o LCD de marca asiática.

La experiencia me dice que por muy apañadito que seas (de veras que lo soy) y diseñes la aplicación con el máximo cuidado posible, siempre pasa algo "inesperado" que trastoca tus planes y deja en entredicho tu vena artística de diseñador de aplicaciones de escritorio. Da igual que utilices porcentajes dependientes de la resolución y configurables en fichero XML, que coloques los controles dinámicamente en cada formulario olvidándote de medidas fijas, que juegues con paneles y otros controles contenedores, que hagas buen uso de útiles propiedades como dock, anchor, autosize; da igual lo que hagas, "el efecto demo" te arrastrará sin piedad hacia sus profundas raíces, desde donde mostrará una interfaz de usuario penosa que arruinará de por vida tu reputación de diseñador gráfico.

Cuando crees que tu aplicación es la bomba y está, valga la redundacia, a prueba de bomba, no hay nada más frustrante que cambiar la resolución habitual de tu monitor (en mi caso un Dell de 19" a 1280 x 1024 ) y contemplar cómo la nueva resolución se ríe de ti a la cara. Es uno de los momentos en los que los desarrolladores más tensión sufrimos, cuando el runtime de la plataforma está dibujando tu aplicación, con todos y cada uno de esos preciosos formularios repletos de controles que tantos disgustos nos dan. Y como no podía ser de otra manera...ese cambio de resolución inesperado de última hora hace que la aplicación se vea de culo en la pantallita de plasma, que el control más importante del formulario esté semi-oculto, y el texto del título se vaya de bares; y por supuesto, la profesionalidad del susodicho desarrollador queda en entredicho forever & ever.

Así que ya sabéis, antes de enseñar una aplicación de escritorio en otra pantalla (con distinta resolución a la vuestra), sobre todo si ha de ir a pantalla completa y está destinada al "gran público", ¡andad listos! Enteraros de qué resolución tiene la pantalla target, poned dicha resolución en vuestro monitor...¡y probad el comportamiento de vuestra super aplicación! No cuesta nada y nos puede ahorrar muchos disgustos "públicos" de última hora...

SaludoX.

El síndrome del código mortal

Este post tiene su origen en el telefilm que empecé a ver en la pesada sobremesa de ayer domingo. Estaba empezando a cerrar los ojitos, cuando de repente, una voz en off proveniente de la tele pronunció de forma más que impactante: "Código mortal". ¿A que suena cañero? Era el título de la pseudo-película "de punto negro" en cuestión, pero a mí que soy informático me dejó traspuesto, y dejando a un lado el tema de la traducción mejor o peor del título original, en seguida asocié el título con esos marroncillos que todo informático ha heredado alguna vez; sí, esos pequeños trozos de código llenos de trampas inesperadas y auténticas bombas de relojería, en pocas palabras, código mortal.

Y es que a todos nos ha tocado alguna vez bailar con la más fea. Aparte del sentido literal que pueda tener la frase, me refiero a cuando te encasquetan un código:

• que no es tuyo y que ha sido desarrollado por un programador "aficionado" que ya no está en la empresa
• que ha sido escrito en un lenguaje de programación del paleolítico superior
  
• que no funciona ni de coña
• en el que la documentación brilla por su ausencia

He aquí los cuatro pilares básicos del código mortal, lo que nos convierte en HRADs, es decir, en High-Risk Application Developers. No vamos a negarlo, este tipo de herencias tecnológicas están a la orden del día en cualquier empresa; pasen y lean la siguiente fábula tecnológica:

Jefe: "Oye Miguel, ¿te acuerdas de aquella mini-aplicación que hizo Paquito en Visual Basic? Sí, la que acabó de desarrollar el muy cabrón justo antes de irse a la competencia...Era un módulo que se comunicaba con el ERP, y blablabla...".

Miguel (para mis adentros, cruzando los dedos mientras el jefe sigue hablando): "Menuda ponzoña de aplicación, nunca llegó a funcionar...".

Miguel: "Sí, algo me suena....pero aquello al final se dejó porque no funcionaba, ¿no?".

Jefe: "¡Bah! No creas que iba tan mal...la idea era muy buena...además, no te preocupes porque Paquito era muy ordenado y dejó un Word explicando al dedillo el funcionamiento interno de la aplicación; en seguida te traigo el documento para que le eches un vistazo. Ya sé que no te gusta mucho Visual Basic, pero seguro que si te pones, en un par de días haces birguerías con ese código. Además, siendo el cliente que es, habrá que hacerlo, ¿no crees?".

Miguel (para mis adentros, visiblemente contrariado): "¿Ordenado? ¡Pero si sólo hay que ver la mesa que tenía el jodío! Y al cliente..., al cliente ¡que le den por culo! Joder, es que ¡siempre acabamos bajándonos los pantalones ante los mismos de siempre!"

Miguel: "Hombre, yo no lo veo tan fácil. Es más, veo muy complicado volver a poner en marcha aquella aplicación, ha pasado mucho tiempo, no es mi código, el cliente ha migrado su base de datos ..., por cierto, ¿para cuándo sería?"

Jefe: "Para finales de la semana que viene, SIN FALTA. Por cierto, aquí tienes el Word del que te hablaba. Ponte desde ya mismo con eso y mañana me paso y me cuentas, ¿ok? ¡Venga Miguel, ánimo, que tú puedes!".

Miguel (para mis adentros, en modo ira = true): "¡vrhfrejbfe kjrebfwebrce rjkfbwkjrbf fjbwer klernoqr...!" (la traducción de este bloque son una serie de juramentos en afgano-talibán).

Miguel (alto y claro, cuando el jefe ya no puede oir nada): "¡vrhfrejbfe kjrebfwebrce rjkfbwkjrbf fjbwer klernoqr...!" (la traducción de este bloque también son una serie de juramentos en afgano-talibán).

Como diría un amigo mío, si es que somos putas del teclado ;-). Desgraciadamente, de forma paralela al final de esta fábula suele empezar el calvario particular del programador. Por ello, con el firme propósito de evitar el síndrome del código mortal a otros compañeros que en un futuro tengan que leer o modificar las (eficientes ;-)) líneas de código que actualmente escribo, al igual que hice en Septiembre del 2007, prometo que voy a programar cada día mejor. Y sobre todo, voy a pensar en otros compañeros de profesión y voy a documentar todo lo que pueda en el propio código, que es donde muchas veces más se echan en falta los comentarios explicativos. Va en serio...espero que vosotros también os unáis a esta cruzada anti código mortal.

SaludoX.

Lista de web application frameworks

Si eres el típico informático al que le gusta estar al tanto de noticias ligadas con el desarrollo web, estarás de acuerdo conmigo en que últimamente las plataformas para aplicaciones web o web application frameworks crecen como champiñones. No hay semana del año que no lea que ha salido un fabuloso framework que es "lo max", y que permite desarrollar aplicaciones web en "0," (cero coma) ;-)

Sobre todo a raíz de la explosión definitiva del fenómeno de la Web 2.0 es cuando han empezado a proliferar este tipo de plataformas de base que intentan (algunas lo consiguen; otras no) hacer la vida más fácil al programador o a los usuarios. Los lanzamientos oficiales suelen ir acompañados de mensajes puramente marketinianos como "The easiest PHP framework ever", "Develop strong web applications with the power of ASP.NET Ajax" ó "Yet another Javascript Modelling Framework". Que conste que me los acabo de inventar (si alguna multinacional necesita un nuevo director de marketing, aquí me tiene...), pero que sepáis que esto mismo es lo que hacen los creadores de estos frameworks. Se trata elegir un eslogan sencillo pero contundente, de ésos "que pega" y que sobre todo, consigue atraer al mayor número de adeptos en el menor tiempo posible. Aunque sea mentira...en fin, es lo de siempre, ¡nuestro querido mundo de la informática!

Como cada vez abundan más los web application frameworks, para que no nos olvidemos de ninguno y los tengamos localizados, os dejo el link a una comparación completa y actualizada de diferentes frameworks para desarrollo web actualmente disponibles. Esta gran entrada de la Wikipedia permite ver de una forma muy rápida los frameworks disponibles, así como el lenguaje de desarrollo soportado, el tipo de licencia que tienen (muy importante), su última versión estable, etc.

Y muy relacionada con esta entrada (son más o menos lo mismo, que cada cual elija la que más le guste), encontramos esta lista que enumera los frameworks para aplicaciones web actuales. Desde luego, estas dos entradas dejan bien claro que cada vez es más difícil estar al día en todos los ámbitos; hay nombres y siglas que no había ni habría oído jamás en la vida. Y si conocéis más, ya sabéis...la Wikipedia la hacemos tod@X.

SaludoX.

Desarrollo web online

Está cada vez más claro que nos dirigimos de nuevo hacia la época de los terminales dummies que trabajan contra un potente servidor y que todo lo hacen online. Hoy en día ni se pregunta ya si tenemos red y conexión a Internet, ¡se da por hecho que sí! Claro, el día que se cae la red y/o Internet....¡se armó la marimorena! Hay tecnologías como AJAX y sistemas de bases de datos offline que están pensadas para este tipo de casos ya que permiten seguir trabajando en local y sincronizar datos cada cierto intervalo de tiempo; sin embargo, muchos asocian AJAX con fútbol (Marco Van Basten, Ruud Gullit, Frank Rijkaard y cía., ¡qué grandes!) y claro, más del 90% de la gente se la hace al estilo anuncio Martini: "no network, no work". Y no me voy para casa no sé porqué...

Bien, una vez más me he ido por los cerros de Úbeda, así que después de esta pseudo-sátira del mundo totalmente conectado en el que vivimos, voy a comentar una utilidad online (¡cómo no!) a la que eché un vistazo (¡sólo uno!) el otro día. Se trata de AppJet, una especie de IDE online que reivindica el instant web programming y que permite en tres simples pasos codificar, previsualizar y publicar en sus servidores una aplicación web accesible a todo pichichi.

Yo no he trasteado mucho pero entiendo que con cierto control de Javascript se podrán desarrollar aplicaciones más o menos útiles. Está claro que este "entorno" de desarrollo online es bastante más friki y menos accesible que herramientas como Google Page Creator o el mismísimo Blogger, que permiten a individuos como yo montar una web o abrir un blog en menos de lo que canta un gallo; comparativas con estos dos gigantes aparte, AppJet me ha sorprendido por su sencillez 2.0 y sobre todo por el mensaje subliminal del desarrollo web online que lleva implícito. Tiene su gracia, ¿no?

Doy por hecho que estos de AppJet tienen un plan de hosting con subdominios ilimitados; si no, les va a salir cara la bromita...

SaludoX.

HRAD: High-Risk Application Developer

Como reza el título del post, últimamente me estoy convirtiendo en un auténtico HRAD, es decir, un desarrollador de aplicaciones de alto riesgo. Lo jodido es que cuando digo aplicaciones de alto riesgo, más de uno estará pensando: "quizás este tío se dedica al desarrollo de sistemas embebidos que controlan la frecuencia cardíaca de las personas que sufren arritimias", o "quizás ha diseñado el solito el software que controla la central nuclear de Garoña". Pues no, no me refiero exactamente a ese tipo de aplicaciones de alto riesgo; es más, quizás sería mejor decir desarrollador de aplicaciones con alto riesgo.

Se puede definir "aplicación con alto riesgo" como aplicación software que:

• se ha construído deprisa, mal y corriendo
  
• en apariencia funciona
• en el momento menos pensado pega un pete brutal y deja sin luz a toda la oficina

Muchas veces la gente no entiende que es materialmente imposible construir un software que impresione al cliente más exigente, que funcione perfectamente y que a su vez se programe en 1-2 días, o incluso en cuestión de horas si me apuráis. Es en este tipo de aplicaciones donde tienes todos los boletos para que se te olvide "el try/catch de tu vida"; sí, ése que te hubiese dejado 'no tan mal' delante de tu jefe y del cliente más importante de la empresa, justo cuando la aplicación saltó por los aires. ¡Y qué decir del típico mensaje de traza que lleva alguna palabrota, insulto o la omnipresente "kk", y que se te ha olvidado comentar en el código! ¡Qué vergüenza y qué risa más floja cuando aparece en la pantalla!

Y es que cuando desde el Olimpo de los Jefes llegan órdenes de tener lista una aplicación para anteayer o de preparar una demo improvisada en 2 minutos, no hay escapatoria; cada cual se pone su disfraz de HRAD e intenta, más que programar, hacer magia.

SaludoX.