Entorno inicial
Comentarios (0) Perdón por no haber escrito en las ultimas dos semanas, un par de cursos que necesitaba pero que han venido en mal momento, dos “releases” de emergencia y dos normales entre un montón de bugs y problemas me han mantenido ocupado durante los últimos 20 días.
Bien, hasta ahora he estado hablando de mi y de mi experiencia, ya es hora de que empiece a hablar del entorno inicial de mi trabajo actual y el entorno de desarrollo que existía. Básicamente, este ultimo punto se puede resumir en una palabra: Inexistente.
El problema es que ya había mas de 10 aplicaciones siendo desarrolladas, mantenidas y funcionando. Todo hecho por varios trabajadores temporales y externos. Algunos bastante buenos, la mayoría con solo un conocimiento básico de lo que estaban haciendo.
La compañía no era de mucha ayuda en esto. Esta especializada en dar servicios de infraestructura a una corporación (mucho) mayor, se creo hace poco tiempo (unos 4 o 5 años) y cuyo principal cometido es mantener funcionando los servidores y los mainframes. El software, en esta compañía, vino después y casi todas las aplicaciones que funcionan en estos servidores han sido heredadas de las otras compañías (“entidades” en la jerga local) que forman la corporación.
Esto es el infierno para un desarrollador.
Casi todos los empleados son administradores de sistemas o de red, esta gente prácticamente no usa sus ordenadores, simplemente ejecutan un par de aplicaciones locales y los usan para conectarse a los diferentes servidores, routers, switches… La gente que trabaja con los mainframes hacen lo mismo. Así que la especificación básica para una “estación de trabajo” aquí es un P4 con 512MB de RAM. Intenta usar una base de datos local, un Websphere AS también en local y tu entorno de desarrollo java preferido (entre otras herramientas y aplicaciones como el cliente de correo, editor de textos…) y las cosas pueden llegar a ser exasperantes.
También están todas las diferentes políticas. Básicamente, yo he sido el primer empleado “normal” (fuera del reducido grupo de IT, quiero decir) que consigue privilegios de administrador local. Desgraciadamente es algo basico si tienes que andar instalando y desinstalando herramientas de desarrollo, usando debuggers con procesos en ejecución y cosas de esas. Quizás no las necesites todo el tiempo, pero si que necesitas tener la opción. En el caso de las herramientas seleccionadas por la compañía, es totalmente necesario. El entorno esta basado en las herramientas de IBM (Websphere AS, Websphere Studio, DB2, MQSeries…) y simplemente para ejecutar el servidor de aplicaciones Websphere integrado en el Websphere Studio necesitas permisos de administrador local. Un error en el programa? Algo que se puede arreglar con permisos mas específicos? Es posible, pero no he tenido tiempo de toquetear y probar y si consigues los permisos de administrador el problema se soluciona.
Esta forma de pensar se extiende a los servidores. No me entendáis mal, estoy totalmente a favor de tener unas políticas de seguridad estrictas en los servidores de producción. Aun siendo un desarrollador experimentado (o precisamente por serlo) es fácil que te cargues algo, así que es mejor si solo tienes acceso cuando y donde lo necesitas. Pero que pasa con las maquinas de pruebas? Os suena bien el tener que pedir permiso para actualizar una aplicación en una maquinas de pruebas? Es, después de todo, un entorno de pruebas, se supone que cambia con rapidez y que tiene siempre las ultimas versiones de todo (versiones de desarrollo). Al menos ahora el proceso es automático, pero aun así, significa que no hay una manera sencilla de montar un entorno de integración continua.
Tengo que decir, llegados a este punto, que aunque el entorno de trabajo no sea el mejor y que algunas de las políticas parezcan estar diseñadas para entorpecer el desarrollo, los directores tienen la mente bastante abierta y han sido mis mejores aliados para facilitarle las cosas a todo el mundo. Simplemente cinco minutos delante de mi monitor y conseguí 2GB extra de memoria. Un correo explicando que eran los permisos de administrador y por que los necesitaba y los tuve al día siguiente (y los perdí a la siguiente semana y tuve que recurrir al correo otra vez hasta que los tuve de manera permanente). Ambos cambios han sido incluidos en las necesidades estándar del departamento de java y ahora espero que el resto de departamentos (que hasta ahora han tenido que hacer malabarismos para hacer su trabajo) empiecen a pedir las cosas que necesitan.
Bueno, creo que es suficiente por hoy. Continuare la semana que viene con esto, pero mas centrado en el lado del software (y posiblemente me quejare un poco de los contractors).
Themocracy