flozano.com: Haz commit, maldito!
Desarrollo de software y otras pérdidas de tiempo
Desarrollo de software y otras pérdidas de tiempo
Feb 24
Volviendo a mis orígenes! Dejo temporalmente la arqueología de software Java para dedicarme a la arqueología de scripts PHP que ni el peor de los diseñadores metido a programador podría soñar en hacer tan mal
)))
Sep 21
Cuando un post en theserverside.com obtiene más de 100 comentarios, quiere decir que algo pasa. O se han enganchado los de JBoss a discutir con los de Spring, o la comunidad se ha puesto a rajar viva al visionario de Tapestry, o cosas así. Todos estos asuntos no suelen acabar teniendo la mayor trascendencia, pero éste último sí que la puede tener, en mi opinión:
http://www.theserverside.com/news/thread.tss?thread_id=50727
Esta vez es algo que nos afecta a muchos de los que apostamos en su momento por una estrategia de desarrollo más sensata, sencilla, fácil, testable e integrada, y nos decidimos a usar Spring.
Para quién no lo conozca, Spring es un framework con cuatro áreas funcionales bien separadas en mi opinión:
Spring es modular y uno puede elegir si usa uno u otro módulo sin problemas… lo que ocurre es que cuando uno decide usar uno, es más fácil que se acabe usando otro y otro… haciendo de Spring al final una pieza fundamental en la aplicación.
Lo que ha ocurrido para revolucinar tanto a la comunidad de desarrolladores y arquitectos es que la empresa propietaria de SpringSource (antes interface21) ha publicado una nueva política de liberación de versiones, que restringe a los usuarios sin contratos de mantenimiento el acceso a los parches incrementales de las versiones no “current” a únicamente tres meses.
Es decir,pongamos que yo uso Spring 2.0.2 en una aplicación que lleva N meses en producción, y la versión actual es Spring 2.5(.1), desde hace más de tres meses. En esto, me aparece un “bug” en la aplicación debido a un fallo en Spring 2.0.2. Me dispongo a arreglarlo, pero al no tener contrato de mantenimiento no tengo acceso a la versión corregida 2.0.3, sino que tendría que actualizarme a Spring 2.5.2. Obviamente, si tengo esta aplicación en producción, me hará muy poca gracia cambiar de versión “major” del framework sobre el que he desarrollado mi aplicación.
Los “mantenimientos” tienen sentido en algunas cosas… pero en el framework de inversión de control de tu aplicación? es rizar el rizo… y qué hay de las aplicaciones que usan spring y tienen su propio modelo de licencias? ahora debes incluir también a spring en el stack a licenciar y mantener por el cliente (oracle + sistema operativo + cluster + servidor de aplicaciones + mi aplicación + el framework de inversión de control) ? No se si es muy lógico…
Imagino que interface21 está intentando “capitalizar” la ubiquidad de su framework y rentabilizar la inversión (enorme) que ha hecho en él, pero no sé si es la mejor manera. Ahora, muchos de los que usabamos Spring extensivamente, y que lo hemos hecho tan popular, vamos a pensarnoslo muy mucho antes de volver a elegir la pastilla roja y volver creer en una empresa que hasta ahora había sido un bálsamo para la comunidad de desarrolladores Java. Spring seguirá teniendo una calidad técnica excelente y una cantidad enorme de seguidores, pero esto va a allanar el camino a otros frameworks, como los EJB 3.X estándar, Seam, o Guice.
Yo voy a ser conservador, y si tengo que acometer nuevos desarrollos en Java seguiré confiando en Spring, pero lo haré como se debe hacer: sin casarme con él, utilizando sus funcionalidades transversales y “de contenedor”, pero sin permitir que contamine mi código; o si lo permito, me preocuparé de encapsularlo bien y acotarlo defensivamente para que aparezcan “imports” de org.springframework sólo en sitios concretos.
Lo hare así porque las alternativas no están al nivel adecuado, en mi opinión. Con EJB 3 tienes mucho pero no “todo”… EJB 3.1, cuando venga, será una gran mejora e igual sí permite plantearse confiar únicamente en estándares (ya veremos)… Seam aporta mucho (los scopes conversacionales son una gran idea) pero no me convence del todo su modelo, y además, al usarlo, uno se casa con él más que con Spring… y por último Google Guice es demasiado sencillo, no tiene todo lo que uno necesita, “contaminas” el código con montones de imports para las anotaciones y además tiene carencias importantes en el modelo de componentes basado en clases en vez de en objetos con “id” o “nombre”.
En fin, veremos como se suceden los acontecimientos
Oct 22
Viendo blogs ajenos me he encontrado con un post genial, que creo que ejemplifica muy bien (y critica, jeje) la realidad de muchos entornos laborales. Aquí lo dejo para quién le interese: http://epsilondelta.net/2006/10/19/are-you-on-a-pleasantville-team/
Oct 4
Puede que este post resulte algo hiriente para cierto colectivo de gente, usuarios de la plataforma que voy a rajar viva. Me da igual, estoy harto de ella y es mi blog, así que posteo lo que me da la gana. Además, no entiendo el sectarismo seguidista que hay hacia esta plataforma.
Empiezo. La mayoría de los que leáis esto no conoceréis un conjunto de “entorno de desarrollo + base de datos + servidor de aplicaciones” llamado Velazquez Visual, recientemente rebautizado como “Velneo” (De “neo” nada, sigue siendo igual de castaña que en el 96).
Velazquez/Velneo es un entorno de desarrollo visual, que integra dentro una base de datos bastante rapidilla (tan rápida consultando como lenta en recuperarse cuando casca). La idea es muy interesante, y hay que reconocer que la base de datos incorpora abstracciones de alto nivel que para modelos de aplicación orientados a registros, tablas y filas (sí, eso tan de los 90) resultan interesantes (Singular del plural, hermano contiguo, historicos y alguna cosilla mas). Además, al estar todo integrado, en teoría debería dar pocos problemas, y para cosas sencillas sería una buena solución, no? NO. ERROR. No hay que caer en el error de querer hacer más fáciles de lo necesario ciertas cosas, y en el mundo velazquez es todo tan mágicamente fácil y tonto que te hace sospechar.. con razón.
Primero te acercas a Velneo con curiosidad. Además, es software español, y hay que dar una oportunidad a la industria del software patria, que tan mal está…
A primera vista es pontentillo pero limitado: Permite hacer cosas sencillas muy rápido, pero hay que dar *MUCHAS* vueltas para hacer otro tipo de cosas, muy sencillas de resolver en un entorno de desarrollo tradicional. Y como quieras integrar algo externo, olvidate de COM, ActiveX, DCOM, .NET y cualquier otro modelo de componentes o middleware moderno: Solo tienes DLLs “stdcall” puras, “a la antigua”… ahí, ahí, como los hombres de verdad.
Profundizas un poco y empieza lo incomprensible, empiezas a ver que algo no encaja y que el entorno solo sirve para hacer aplicaciones poco integradas con el mundo exterior… con un modelo de datos irremediablemente pegado a una aplicación (Cuando está demostrado que el modelo de datos casi siempre sobrevive a la aplicación)… con unas herramientas para hacer tu trabajo útiles pero imposibles de extender… no se, un entorno que para cierto tipo de aplicaciones lo podrías hasta considerar, pero que ni de lejos va a desplazar lo más mínimo a los “stacks” típicos Java, .NET, Windows DNA, LAMP o entornos Host. No tiene capacidad para ello, sencillamente.
Al final te hartas. Te hartas de:
- Programar Webs de la forma más friqui, estúpida e improductiva que has visto nunca. Te parecerá que el ASP de antes era avanzado comparado con esto.
- No poder acceder a la base de datos más que a través de tus “mapas” Velneo (un “mapa” es una aplicación + una definición de modelo de datos + alguna cosa más).
- No poder extender por donde quieras tu programa, ni usar un modelo de componentes , ni aplicar patrones y buenas prácticas estándares para el desarrollo de aplicaciones.
- Funcionar con nomenclatura estúpida, metodologías y patrones imbéciles y conceptos artificialmente diferenciados de los estándares.
Pero sobre todo sobre todo, te hartas de la CASTAÑA que resulta ser el servidor de aplicaciones. El servidor de aplicaciones es lo que sirve tu base de datos, tu Web y tu aplicación. Es algo así como un SQLServer+IIS+entorno de WinForms, si lo comparas con .NET. Todo ello por un protocolo propietario y maravilloso llamado VATP que los de velazquez se vanaglorian de haber hecho lo suficientemente distinto del resto de protocolos que la IANA les ha asignado un número de puerto.
Eso si, tanto avance tecnológico (según ellos) y no son capaces de separar servidor de administración, por lo que el servidor no puede correr como servicio de Windows y tienes que tener el escritorio “logueado” para que funcione, con el velazquez ahi minimizadito. Muy avanzado, sí señor, de la época de windows 95 ![]()
Lo peor de todo, dentro de lo malo que es casi todo lo referido a este entorno, es que el servidor de aplicaciones tiene la mala costumbre de caerse. No se cae por una aplicación mal programada, no. Se cae porque está Mal Parido. Además, una aplicación no puede tirar a su contenedor (como mucho por falta de recursos… y me parecería mal), lo digan los de Velneo o quien sea, me da igual.
Imagina que tienes una aplicación Web corriendo sobre un servidor de aplicaciones JBoss y una base de datos Oracle. Imagina que tu aplicación está tan tan mal programada que consigues tirar al JBoss (complicado de conseguir, pero bueno, pongamos que tienes poca memoria y lo consigues).
Bien, se ha caido tu JBoss y tu aplicación no funciona. Pero… afecta eso a tus datos? Yo diría que no. Tu Oracle sigue viva? A ver q mire… Si, no? Y levantar el JBoss es cuestión de un par de comandos y pocos segundos… menos de un minuto y la gente sigue trabajando (eso si no lo tenías en cluster, cosa que Velneo ni conoce ni conocerá).
Pues con Velazquez/Velneo NO. Con velazquez se cae tu servidor de aplicaciones y en un porcentaje muy elevado de las ocasiones, si había alguna transacción en marcha (y suele haberla porque suelen quedarse pilladas), tu base de datos empezará a reconstruirse. Si tienes muchos datos puede tirarse horas y horas reconstruyendo índices y áreas de datos. Porque él lo vale, si señor (para qué aplicar un WAL? Claro que así igual la base de datos no sería tan rápida… anda!)
El caso es que ese día puedes dar vacaciones a tu gente, porque no van a poder trabajar con la aplicación. Ni consultar un solo dato. Ni siquiera manualmente, dado que no puedes lanzar consultas a la base de datos.
No se, en ciertos entornos elegir un sistema que te deja tan indefenso y que falla tan estrepitosamente y tan fácilmente, sería un buen motivo de despido.