Angel Retamar Arias

Dimensionamiento de aplicaciones Tal y como se me sugería en un comentario del anterior post sobre puntos negros, sí que es cierto que  el dimensionamiento de aplicaciones es un tema que puede ser un punto negro importante, mas que nada porque se suele dejar de lado por parte de los desarrolladores.
Otro tema aparte es el rendimiento que, desde mi punto de vista, preferiría tratarlo por separado.
a) Rendimiento. Yo, por mi parte, lo tengo claro: es importante tener en cuenta el rendimiento a la hora de diseñar e implementar aplicaciones empresariales (web, J2EE). Pero, claro, plantearse un mal diseño para conseguir una mejora en rendimiento (en un proceso que no sea crítico ni tenga requerimientos específicos de rendimiento), no tiene mucho sentido. Más que nada, porque lo que se ahorra en máquina se gasta después en mano de obra (a la hora de hacer el mantenimiento).
b) Dimensionamiento. Independientemente del rendimiento, no hay escusa para no evaluar los parámetros (tiempo de respuesta, productividad, etc.) en los que se mueve la aplicación. Por ejemplo, en el FW-PA (el Framework J2EE del Principado de Asturias), se incentiva (vamos, que se exige) la realización de un detallado informe de rendimiento para todas las aplicaciones que se desarrollen.

Por cierto, respecto a este último asunto: en el FW-PA, como herramienta para la implementación de pruebas de rendimiento se recomienda OpenSta. ¿Conoceís alguna otra herramienta (libre) alternativa?

Puntos negros del desarrollo de aplicaciones: Entregables Un error habitual al desarrollar aplicaciones es suponer que, con el fin del desarrollo (y prueba) de la aplicación, todo el trabajo está terminado. Y no. Nunca suele ser así, especialmente si el equipo de sistemas (los encargados de mantener las máquinas y los contenedores) no son el mismo que el equipo de desarrollo. No es extraño que aplicaciones correctamente diseñadas, bien implementadas y suficientemente probadas, tengan un mal funcionamiento por culpa de un despliegue, dimensionamiento o configuración incorrectos.
Se me ocurren algunos consejos para mitigar (porque este punto negro no hay quien lo evite) este tipo de problemas:
· Documentar CLARAMENTE todos los pasos para desplegar (o instalar) correctamente el producto. Explicar TODOS los parámetros de configuración y acordar de antemano valores por defecto con la gente de sistemas.
· No tener ningun parámetro de configuración A FUEGO en el código.
· Evitar que el personal de sistemas tenga que "abrir" el entregable (desempaquetar un jar o un war) para cambiar los valores de los parámetros de configuración.
· Introducir en las aplicaciones un "huevo de pascua" que permita al equipo de desarrollo conocer si la aplicación está correctamente instalada y configurada.
· Sacar un log de instalación completo y cuyos mensajes tengan significado para el equipo de sistemas. De poco les ayuda un mensaje que diga: "[DEBUG] Installer.class : entrando en metodo getEspilonche() con parámetros "trocola" y "cosa"".

Diseño UI...menudo punto negro Para la mayoría de los programadores, diseñar la vista (generalmente páginas HTML) es un dolor.
¿Será porque el perfil de técnico y el perfil de "artista" se parecen tanto como un huevo a una castaña?

Pero es que, además de eso, las tecnologías para implementar la vista son un infierno: 

- Las CSS son horribles, no solamente porque son difíciles de entender, sino porque nunca funcionan igual en todos los navegadores y la única forma de hacer algo medianamente compatible con los más habituales (Explorer, Mozilla y Opera) es hacer "ñapas" para que las cosas encajen y solamente queden medio mal. Por supuesto, una vez conseguido esto, si hay que cambiar algo no será precisamente un camino de rosas...
- Hay que tener siempre en cuenta la accesibilidad, la usabilidad, usar estándares, etc, etc. incluso cuando estos principios se contradicen.
- No existen prácticamente "patrones de diseño" para facilitar la implementación de vistas.
- Las pocas herramientas que hay (editores HTML, etc.) generan código sucio, difícil de mantener y que generalmente hay que "tocar" a mano posteriormente. Muchos de ellos utilizan funciones propietarias (javascript, etc.)

Otro punto negro... entregables Desde mi humilde punto de vista, otro de los puntos más negros (quizás el que mas) a la hora de desarrollar aplicaciones es la gestión y mantenimiento de entregables. Las aplicaciones web son "mano de santo" para quitarse del medio este problema. De todas formas, no todo se puede solucionar con aplicaciones web. En no pocas ocasiones es necesario distribuir a los usuarios un "cliente pesado" o una librería (por ejemplo, un framework).
El mero hecho de tener que distribuir y mantener multitud de aplicaciones corriento en vete tú a saber que entornos diferentes es ya de por si un problema importante (sobre todo, si no se lleva un control de versiones: quien tiene qué versión, etc.). Pero, además, todas estas versiones hay que mantenerlas. Y por si esto fuera poco, seguramente haya que realizar "personalizaciones" de versiones para clientes determinados.
Un día cualquiera, alguien detectará un bug en una aplicación, y entonces empezará el jaleo:
- ¿qué versión tenía el cliente X?
- La versión 1.4 pero además le habiamos puesto los botones redondos en lugar de cuadrados.
- Ah, claro, te refieres a la versión 1.4.3, que es igual que la 1.4 pero con los botones redondos.
- No no, esta gente tenía la versión 1.4 antigua, pero además le añadimos lo de los botones. Pero no tiene arreglado el bug B1 que se corrigio en la 1.4.2.
- Bueno, pues le ponemos la 1.4.3 y a correr.
- No puede ser, porque en la 1.4.1 se corrigio el bug B2 y cambió el sistema de generación de informes y no es compatible con la versión del MuyCaroReports que tiene licenciado el cliente.
- Bueno, entonces si abro una rama en el CVS y luego hago un merge sobre la versión 1.4....¿no me cargaré nada, verdad?, ¿verdad?, ¿verdad?.
- ...

Mas puntos negros...integracion Que levante la mano quien haya hecho alguna aplicacion empresarial y no haya tenido que integrarse con otros sistemas...¿nadie?
Ahora que levante la mano quien haya conseguido realizar cualquier tipo de integracion y no le haya supuesto, como minimo, un dolor de cabeza...¿nadie?
Yo, personalmente, he adquirido la mani­a de, cuando estoy en una reunion preliminar para un nuevo proyecto, estar constantemente (sin poder evitarlo) atento a las posibles integraciones que vamos a tener que implementar, con que sistemas y de que forma (tambien en que plazo y quien es el "equipo contrario" en esto de la integracion, que al principio todos somos amigos, pero al final nadie sabe como va a acabar).
Al finalizar la reunion, llegan las preguntas. En mi repertorio no faltan:

- ¿Con que sistemas nos tenemos que integrar?.
- ¿Alguna vez alguien se integro con el sistema X?. La siguiente suele ser... ¿Me das el telefono de "fulano"?
- ¿El sistema X con el que nos tenemos que integrar, existe?.
- Si no existe, ¿en que estado esta? ¿en proyecto?¿en desarrollo?.
- ¿Hay documentacion del sistema X?
- ¿Quien construyo el sistema X?.
- ¿Para cuando tiene que estar integrado con el sistema X?
- ¿Podemos salir a produccion sin completar la integracion con el sistema X?
- ¿Que proyecto tiene un plazo de entrega menor, el nuestro o el de "ellos" (ellos son quienes implementan el sistema con el que hay que integrarse)?.
- ¿Vamos a tener soporte de alguien del equipo del sistema X?
- ¿Tienen algun tipo de proxy de cliente disponible? ¿Podemos pedir que nos hagan un proxy de cliente?
- ¿El sistema X esta desplegado en alguna maquina de desarrollo/preproduccion para poder hacer pruebas?
- ¿Que "tramites administrativos" (solicitar aperturas perimetrales, cuntas en algun sistema, cambios en la configuracion del sistema X, etc.) hay que seguir para poder integrarse con el sistema X?
- ¿Que hay que utilizar para integrarse con el sistema X?. En J2EE tenemos varias opciones:
    a) RMI / EJBs / WebServices.- Relativamente bien, siempre y cuando el interfaz este bien definido y la documentacion sea medianamente decente.
    b) BBDD. A veces varias aplicaciones comparten una misma base de datos. En general, no tiene por que haber problemas...salvo el riesgo de que otra aplicacion (o¿accidentalmente?) toque los datos de la tuya...pero claro, eso no va a pasar hoy...verdad?
    c) Intercambio de XML (sin un API de servicios web, ni SOAP, ni WSDL, ni nada), de ficheros de texto plano, etc. Sin comentarios... 

El primer punto negro, obvio Como adelantaba en mi primer post, estas primeras entradas del blog pienso dedicarlas a exponer lo que yo llamo "puntos negros" en el desarrollo de aplicaciones. Estos puntos son lugares o prácticas que tienen un buen porcentaje de probabilidades de convertirse en marrones para los programadores (lo que yo, "cariñosamente" llamo chollos).
El "Punto Negro" de hoy, por ser el primero va a ser el mas obvio de todos: "El diseño de la lógica de negocio".
Habitualmente, las aplicaciones empresariales se centran especialmente en la capa de datos y la de presentación, mientras que la lógica de negocio suele limitarse a recibir datos de la capa de vista y pasarlos a la capa de acceso a datos, dedicandose, si acaso, al control transaccional o a pequeñas operaciones (generalmente conversiones o formateos de datos).
Este hecho hace que habitualmente el diseño de aplicaciones en tres capas se "relaje" (por no decir que, literalmente se pase de él) y se empiecen a hacer llamadas a los componentes de acceso a datos desde la vista o que se utilicen objetos de la vista en los componentes de datos.
Si no se es muy (muy mucho) escrupuloso con la arquitectura, se corre un grave peligro de que caiga un marrón gordo. ¿Por qué? Porque siempre (siempre siempre) el cliente va a querer algún cambio en la aplicación y ese día, aparecerá el analista y dirá que el cliente ha pedido tal y cual cambio, y que el susodicho cambio es una pijada y que solamente tienes que cambiar aquí y allí tres cosas y listo... Y una m****a (¿en este blog se puede decir mierda?)!!!. Como la aplicación no tenga un diseño cristalino (de claro, no de frágil), hacer retoques puede ser, sin lugar a dudas, el marrón mas gordo que un programador se puede comer.
Una recomedación para evitar enmarronarse con este "punto negro" es evitar como a la peste las  "ñapas" (N del T: utilizar malas prácticas de programación para quitarse de enmedio el trabajo lo antes posible). Siempre el trabajo tiene que estar hecho "para ayer", así que poner como escusa que hay poco tiempo no vale.