Jun 22

Visita a Paradigma tecnológico

Hace ya casi un mes, me tocó una visita a Paradigma Tecnológico.

El tema es que un departamento de nuestra empresa, no el mío, tiene un proyecto en el que está como requisito el uso de algunas tecnologías modernas, entre otras, BigData. Puesto que en los departamentos de nuestros alrededores nadie tiene experiencia con estas tecnologías, se ha decidido subcontratar desarrollo y asesoría a alguien que sepa del tema, para sacar el proyecto adelante y para aprender nosotros sobre ello. La empresa elegida ha sido Paradigma Tecnológico.

Esta compañía ágil, como reza en su página web, hace nuestro proyecto con Scrum y finalizado el primer Sprint, llega el momento de hacer la "demo" al cliente, es decir, al departamento de mi empresa. Teniendo yo fama de friki, este departamento y  mi propia jefa, decidieron que yo debía acudir también a ese sprint, para enterarme lo más posible de este tipo de nuevas tecnologías y ver si son aplicables a otros proyectos. Así que allí fuí.

Lo que más me llamó la atención, en lo que se puede ver dando un paseo por las instalaciones de Paradigma, es que sí tiene toda la pinta de que usen Scrum realmente en todos los proyectos. Según se pasea, se ven tableros de Scrum y paquetes de postit de colores por todos lados. Según se podía ver y me contaba una de las personas que trabaja allí, los desarrolladores trabajan en una sala diáfana con mesas agrupadas de 6 en 6, creo recordar. Los programadores de un proyecto trabajan juntos en un grupo de mesas y en la pared al lado de su grupo de mesas tienen el tablero Scrum. Nos enseñaron también el product backlog de nuestro proyecto, un tablero enorme con miles de postit pegados con celo y nos enseañaron el gráfico "burn down" correspondiente a nuestro primer sprint.

En cuanto al Sprint que nos hicieron, era un poco extraño, posiblemente por ser el primer Sprint. Básicamente consistía en explicarnos la arquitectura decidida, una demo real sencilla viendo funcionar esa arquitectura y un "mono" de la interfaz de usuario para que nos hicieramos una idea de cómo iba a ser. Como es de rigor en un sprint, insistieron mucho en que hicieramos comentarios y diéramos nuestras opiniones, ahí creo que nos quedamos un poco "cojos", culpa nuestra.

Hay algunos detalles del Scrum que no me cuadran con lo que pensaba, por ejemplo, para el segundo Sprint se indicaron las tareas que se iban a hacer, imagino que previamente acordadas con el Product Manager que es una pesona de nuestra empresa. Lo que no me cuadra es que en ese segundo Sprint no se llegaba a una funcionalidad útil para el cliente, sino que las tareas eran pequeños (o grandes) trozos de código que evidentemente hay que hacer, pero que no constituyen en sí un producto, aunque sea muy básico, que se pueda entregar de alguna forma, salvo quizás, como un conjunto de liberías. Quizás yo soy demasiado teórico. Quizás un segundo sprint (de 3 semanas) sea también muy pronto para obtener ese primer producto básico. En cualquier caso, no le he dado demasiada importancia, ya que en mis intentos de hacer Scrum con mi grupo de trabajo, sé lo complejo que es entregar un pequeño producto en los primeros Sprint, donde hacer cualquier cosa completa que vaya desde un extremo del sistema (la interfaz de usuario) hasta el otro (el equipo hardware que se quiere controlar), pasando por todos los pasos intermedios (base de datos, lógica de negocio, …) requiere hacer mucho código de la arquitectura del sistema. Pero me deja ese mal regustillo de que quizás Scrum es demasiado teórico, excesivamente complejo, o no aplicable a cualquier proyecto …

Resumiendo, la impresión en general ha sido buena y me voy confirmando cada vez más en que hacer un Scrum que cumpla al 100% con la teoría de Scrum es muy complejo.

May 20

Cambio de tercio

analizador de espectrosHace ya un mes largo me llamaron a una reunión en la que íbamos los posibles candidatos para hacer un nuevo proyecto, previsiblemente en java. El proyecto consiste en hacer unos bancos automáticos de prueba para unos equipos electrónicos que se van a empezar a fabricar en serie. ¿Adivináis a quién le ha tocado el fregado de entre todos los candidatos?.

Así que nada, he cambiado totalmente de tercio. He pasado de hacer ventanas Swing en java a controlar equipos de instrumentación electrónica (analizador vectorial, fuente de alimentación, generador de señal….) y llevo más de un mes en ello, junto con algunos de mi grupo.

Por un lado estaba la posibilidad de tener que controlar un puerto RS-485, (similar a un puerto serie RS-232 pero de otra manera). La librería a usar RXTXcomm, pero después de unas pruebas y ver que funciona correctamente, me comentan que vamos a comprar un conversor de serie a lan, de forma que podemos hablar con el equipo con puerto serie a través de un socket normal de lan.

Por otro lado, los otros equipos de instrumentación tiene conexión lan directamente y el protocolo de mensajería para controlarlos es estándar, SCPI. La verdad es que es muy tonto, se abre un socket normalito y se mandan comandos de texto terminados en un retorno de carro. El equipo devuelve también comandos de texto terminados en retorno de carro. De hecho, hay posibilidad de conectarse con un vulgar "telnet", escribir los comandos a mano y leer en el mismo terminal las respuestas.

Lo curioso del caso es que hace algo más de 15 años, cuando empecé a trabajar, empecé precisamente controlando instrumentación electrónica para bancos automáticos de pruebas (de aquella en BASIC y con una versión primitiva de LabWindows), Y estoy alucinado de los cambios que ha habido en este mundillo. Antes un osciloscopio era una cosa con botones gordos, pantalla de fósforo verde y un tubo de rayos catódicos. Ahora un analizador de espectros tienen un display LCD, con un Windows XP metido y una aplicación que arranca al encenderlo. Por supuesto, viene con conexión lan y un pequeño servidor web, de forma que desde tu PC y con un navegador "vulgaris" puedes acceder al equipo y controlarlo.

En fin, me lo estoy pasando como los indios (aunque diga que me aburro al programar según las buenas costumbres) y siempre viene bien un cambio de actividad para renovar los ánimos (aunque siga siendo java).

Apr 25

¿Elegancia o sencillez?

 

En el trabajo llevamos varios días peleándonos con la instalación de una versión de nuestro software en uno de nuestros sistemas. El sistema consta de unas diez estaciones de trabajo solaris y unos veinte PCs con Windows. En todos ellos corren aplicaciones nuestras, en su mayoría java. Estas aplicaciones tienen algunas partes comunes, pero son distintas en cada una de las estaciones y de los PCs (cada uno está especializado en diversas funciones, algunas comunes, otras no y comparten mucha información entre ellos). En las estaciones hay bases de datos Oracle, con muchas tablas comunes, pero otras distintas en cada estación. Y en todo esto reside el problema de la instalación.

La gente está dividida en dos posibles tipos de instalación.

Junto con algunos, yo soy partidario de implementar las distintas funcionalidades del sistema en jar distintos e instalar en cada estacion/PC sólo aquellos jar que son necesarios, de forma que ninguna estación/PC lleve más jar o ficheros de configuración que no va a usar. Esta es la solución que considero elegante, pero es más compleja. Requiere generar instaladores/zips disintos para cada estación/PC, así como ser mucho más cuidadoso en esta generación de instaladores/zips, muchos jar, muchos grupos de ficheros de configuración, partes comunes y partes específicas.

Otros piensan que es mejor hacer un único mega-jar, o unos pocos jar grandes, un único mega-grupo de ficheros de configuración e instalar todo en todos lados. De esta forma, un único instalador o un único zip vale para todas las estaciones/PCs. Luego es el propio software el que mirando el nombre de la estación/PC en el que corre, sabe qué fichero concreto de configuración leer, de qué clase principal hacer el new y actuar como lo que le toca. Esta instalación es, desde mi punto de vista, más chapuza, pero es innegable que es infinitamente más sencilla.

Y después de la pelea de estos días atrás para la instalación según mi punto de vista (disintos zips/instaladores que instalan en cada estación/PC sólo lo necesario), creo que estoy empezando a cambiar de opinión. Los instaladores/zips, desde luego, se hacen con procesos automáticos, pero alguien tiene que decirle a ese proceso qué debe meter. Según evoluciona el software y va llevando más funcionalidades y ficheros, hay que tocar la configuración de la herramienta que genera los instaladores/zips (izpack, maven assembly,…) y hay que hacerlo con cuidado. Este proceso es manual y está sujeto a errores humanos, por lo que a nuestros instaladores siempre les acaba faltando alguna cosa y necesitan su proceso de "depuración".

En fin, no me gustan las chapuzas y tengo que pensar seriamente la forma de mejorar el proceso de generar los zips/instaladores, pero desde luego, es difícil resistirse a la facilidad de instalación de "todo va en todos sitios, aunque no se use". Es mucho más fácil instalar un solo mega-jar en todos lados que instalar varios jar distintos en cada estación/PC.

Jan 26

Buena acogida del redmine… quizás demasiada

En el trabajo, en plan de prueba y como comenté anteriormente, instalé redmine. La acogida y la difusión que ha tenido no sólo en el departamento, sino en otros departamentos, me ha dejado alucinado.

Primero hice la instalación de prueba. Me gustó y lo instalé en serio. Lo comenté con algunos compañeros, a los que gustó mucho a primera vista,  y metimos dos proyectos que nos estaban más cercanos. En uno de ellos, precisamente, acababamos de hacer una planificación con Microsoft Project, así que teníamos las tareas ya desglosadas y con fechas, puro trabajo de copy-paste.

Luego lo comenté con otros compañeros con los que tengo proyectos "compartidos". También les gustó y metimos también esos proyectos compartidos. Y ahí empezó la "difusión". Algunos de esos proyectos también son compartidos con otros departamentos de la empresa, por lo que hablamos con ellos, se dieron de alta … y conocieron redmine.

Y ahí empezamos a liarla. Al darse a concocer en otros departamentos, también gustó a otra gente, pero claro, no querían poner sus proyectos específicos en el redmine de nuestro departamento. Quería su propia instalación. Y como comenté hace tiempo en un post, sólo el 10% de los informáticos son "geeks" de la informática, así que uno nunca había oído hablar de ruby, el otro sí, pero no sabía instalarlo a través de un proxy, el otro no tiene ni idea de instalar mysql (y mira que es tonto el tema) y el otro …. El caso es que sin quererlo ni beberlo, empezó a circular gente por mi mesa para "demos" del redmine, llamadas telefónicas y correos para la instalación, etc, etc. Por supuesto, hice las demos, a todos les indiqué lo del bitnami stack redmine, instalación fácil. Pero no me libré de la configuración del correo, ya que muchos no saben ni siquiera los parámetros de conexión al smtp de la empresa.

Así que de momento sé, en otros departamentos, de la instalación de tres redmines, y no hace un mes que instalé el mio (con vacaciones de navidad por el medio).

Y no acaba ahí la cosa. Poco después de una auditoria en que nos echaron en cara que las herramientas que usamos (a nivel de jefes, requisitos, actas de reuniones, etc)  no estaban bien integradas y no había trazabilidad entre unas cosas y otras, vinieron algunos de esos jefes (los más amiguetes) a contarme el problema y empezamos a pensar.

Lo primero, eliminar la base de datos que usan los de calidad con el cliente para incidencias. Es una base de datos access, escondida en un directorio compartido que requiere permisos de acceso, que actualizan los de calidad a mano y que los de calidad tienen que enterarse boca a boca de cómo van dichas incidencias para actualizarlas. A los desarrolladores se les da un listado en excel de dichas incidencias, que no tienen persona asignada (el de calidad no sabe a qué desarrollador le toca cada incidencia) y cada uno "elige" con buena voluntad cual cree que es suya. Creo que el 95% de las incidencias se quedan huérfanas por sistema.

Así que en redmine creé una tarea "incidencia oficial" (los errores de redmine los considero "incidencias internas"), le añadí los campos propios de la base de datos de calidad y junto con un compañero que sabe un montón de bases de datos, hicimos (sobre todo él), un script que lee las incidencias de access y las inserta en redmine. Calidad aceptó empezar a usar redmine y olvidarse del access. Nosotros también dejamos de lado bugzilla (la que usabamos para nuestras incidencias internas) y usamos ahora redmine.

Luego, lo que comenté en "Mega herramientas vs Algo de imaginación", cree un subproyecto GESTION debajo de los proyectos, con permisos de acceso a determinadas personas (jefes de proyecto casi todos ellos) y puse una tarea "Reunión", para las reuniones oficiales con el cliente. Añadí a esa tarea una serie de campos adicionales, como "asistentes a la reunión". Pues bien, los jefes de proyecto han empezado a meter ahí las reuniones, a adjuntar las actas y a asociar tareas a hacer.

En fin, que el tema va en marcha, aparentemente con buen ritmo y buena aceptación. Veamos hasta dónde llega y si una vez pasada la novedad, se sigue acutalizando.

Aug 10

Manifiesto ágil: Personas sobre procedimientos

Uno de los valores del manifiesto ágil es valorar "Individuos e interacciones sobre procesos y herramientas". Este es posiblemente el más importante de todos ellos y quizás, el que menos en cuenta se tiene cuando se intenta implantar una metodología ágil. No por la parte de "interacciones", ya que cosas como programación en parejas, los daily scrum meeting, y demás tipos de interacciones sí se tienen muy en cuenta, sino por la parte de "individuos".

Según mi experiencia, precisamente la parte de "individuos" es la más importante de todas y sin ella, todo lo demás se va al garete.

Con la parte de individuos se quiere decir gente preparada y adecuadamente motivada, es decir, gente que sabe hacer bien su trabajo y que tiene ganas de hacerlo. Y eso es lo realmente importante. Si la gente no es técnicamente adecuada o no tiene ganas de hacer las cosas, da igual que hagan o no reuniones diarias, que trabajen en parejas, que se les den herramientas o que interaccionen con el cliente: el trabajo no sale bien.

Y eso es algo que estoy viendo continuamente en el trabajo. Según qué personas caigan en qué proyectos, estos pueden ir bien o mal, incluso aplicando la misma metodología con las mismas herramientas.

Así, hay proyectos que cuando llegan a los programadores están totalmente sin definir, no se sabe muy bien qué es lo que hay que hacer en ese proyecto, qué es lo que quiere el cliente y ni siquiera se sabe cuales son los requisitos. Mientras, otros proyectos llegan a los programadores bastante bien definidos, con una idea clara de lo que hay que hacer (aunque luego cambie) y llega con algo de documentación en condiciones, al menos, para las partes con más incertidumbre. Casualmente, las personas responsables de proyecto suelen coincidir en los casos que llega o no llega el proyecto definido. Si el responsable es "Fulanito", su proyecto llega bien definido. Si es "Menganito", no se sabe qué hay que hacer en ese proyecto.

Luego, entre los programadores, siempre hay módulos que llegan en plazo más o menos bien y sin demasiados problemas, incluso aunque esa parte no esté bien definida. Otros módulos, llegan mal y con muchos problemas, aunque estén bien definidas. Casualmente, las partes que llegan bien suelen estar hechas siempre por las mismas personas y las que dan muchos problemas, por otras. Un programador bueno técnicamente, con iniciativa y bien motivado, cuando le llega un algo para hacer mal definido, empieza a dar la paliza al responsable del proyecto para enterarse qué tiene que hacer, hace sus propias propuestas si no lo consigue, hace su código bien hecho y fácilmente modificable y finalmente entrega algo que funciona y que sirve para lo que quiere el jefe, incluso aunque el jefe no sabía qué quería. Un mal programador, sin iniciativa y sin motivación, cuando le llega una cosa sin definir, no hace nada salvo protestar y se entretiene con internet o con otra cosa. Al final, cuando la cosa corre prisa, hace lo que le puede deprisa y corriendo, lo hace mal porque técnicamente tampoco es bueno y el proyecto tiene problemas y se retrasa.

Obviamente, no debería llegar a los programadores cosas sin definir, pero aquí puedes ver que aunque el procedimiento y las herramientas sean las mismas, si se junta un mal jefe de proyecto con malos programadores, el proyecto va de culo, mientras que si se junta un buen jefe de proyecto con buenos programadores, ese proyecto suele ir de cine.

Cuando fallan las personas en una de las dos partes, la otra puede "arreglar" la situación. Ante un jefe de proyecto incompetente, los buenos programadores acaban prácticamente definiendo y llevando ellos el proyecto. Ante unos programadores incompetentes, un buen jefe de proyecto lleva mucha supervisión, define mucho las cosas, prueba mucho y sabe sacar lo máximo posible de los programadores que le han tocado.

Y todo esto es real, es lo que voy viendo en varios años de trabajar en proyectos con bastante gente, tanto de currito como llevando programadores.

Jul 23

Pensamientos sobre proyectos grandes y Spring Framework

En su día, para nuestros proyectos grandes, teníamos muchas librerías y módulos separados. Cada programador solía ser responsable de uno de los módulos y tenía su proyecto independiente, con sus programas de prueba, simuladores y todo lo que le hiciera falta.

Eso estaba bien, pero tenía una ligera pega. No usábamos algo como maven y no teníamos control ninguno de dependencias cruzadas. Cada programador ponía sus dependencias de otros módulos según lo necesitaba. El problema, al final, es que no había forma de compilar eso desde cero, ya que era fácil que un módulo necesitara del jar de otro módulo, que a su vez necesitaba de un tercero y tras una cadena más o menos larga, había un módulo que necesitaba del jar del que estamos compilando. Sí, ya sé que es una falta grave de diseño y debería haberse pensado al principio y dejar claras esas dependencias, pero también es cierto que entre lo que lo pensado antes y la realidad después hay muchas diferencias.

Al usar maven, decidimos hacer un proyecto grande con subproyectos debajo (uno por módulo). Así maven comprueba las dependencias y si un programador pone una dependencia que no debe, maven le protesta. Sin embargo, esto también tiene una gran pega. El compilado desde cero se hace desde arriba del todo y el fallo de un módulo hace que los demás ni siquiera intenten compilar. Además, la dependencia se hace entre fuentes, por lo que para estar a la última, necesitas hacer update de todos los fuentes. Eso, en un proyecto grande, puede ser un buen rato casi todos los días.

Al descubrir que se puede usar el core de Spring Framework, aunque sean aplicaciones de escritorio, para instanciar los módulos y usar los eventos de Spring Framework para comunicarlos entre sí, me da la impresión de que se puede hacer relativamente fácil que los módulos hablen entre ellos y se pasen datos sin necesidad de que tengan dependencias entre ellos. Los primeros mini-proyectos en la que hemos usado este framework y hemos hecho módulos indpendientes totalmente, comunicados a través del framework y de código de transformación de tipos de datos de un módulo a los tipos del otro en el main, están resultando una pequeña maravilla en cuanto a organización.

Así que me estoy planteando el volver a módulos separados, en proyectos independientes, y con prohibición de poner dependencias de otros módulos, salvo algunos muy concretos pensados más como librerías comunes que como módulos a instanciar como beans de Spring Framework.

La pega es la de siempre, la paliza de mover todos los repositorios de CVS para que tengan otra estructura y el retocar todo el código, sobre todo quitando dependencias de unos módulos con otros. Todo se andará, poco a poco.

Una pequeña aclaración sobre las dependencias entre módulos. Suponamos que tenemos modulo1.jar y modulo2.jar y que modulo1.jar necesita llamar a cosas de modulo2.jar. Para no meter la dependencia a lo bestia, normalmente hacemos una InterfaceModulo2 con las llamadas a las cosas del módulo2 que sean de interés desde fuera. Por supuesto, esa interface está en modulo2.jar. Y por supuesto, los parámetros y retornos de los métodos de la interface son tipos primitivos de java o bien tipos que están en modulo2.jar. Pues bien, eso hace que modulo1 dependa de modulo2, ya que ve al menos a la interface y a los tipos de parámetros y retornos. Por supuesto, una opción es hacer un tercer módulo InterfaceModulo2.jar con la interface y los tipos, pero me parece multiplicar el número de jars a lo tonto.

La opción que estamos planteando ahora es que modulo1 no vea en absoluto a modulo2. Cuando necesite algo de módulo2 (en realidad, cuando necesite algo, lo que sea), debe lanzar un "evento" indicándolo. Es el código del main el encargado de recoger ese evento y hacer la petición a modulo2, para pasar luego los resultados a módulo1. Esto puede parecer costoso, sobre todo si hay mucha necesidad de cosas de modulo2 por parte de modulo1, pero… si hay tanta necesidad de cosas ¿no estará mal pensado hacer dos modulos? ¿no estará mal pensada la funcionalidad de cada módulo?.

En fin, un pequeño rollo, pero como indico en el título, son símplemente "pensamientos".

Apr 30

Pequeño éxito … ¡Y más trabajo!

Como comenté hace unos días, terminé mi pequeña aplicación en python que permite recoger de la gente los tiempos que han dedicado a cada uno de los proyectos y luego genera automáticamente un Excel para entregar al encargado de guardar todo esto oportunamente.

Pues bien, esa aplicación tonta ahorra a mi jefa un trabajo de un par de días de andar preguntando a cada uno a qué se ha dedicado y generar el excel a mano, así que le ha encantado. Tanto, que ha empezado a comentárselo a los demás jefes con el mismo problema y también les ha encantado. ¡¡ Todos quieren !!.

Y claro, cada uno quiere mejoras, añadidos y cosas variadas. Lo que era una aplicación cutre, que básicamente es un script capaz de admitir los datos de la gente desde el navegador y generar un excel, tiene pinta de que se va a convertir con el tiempo en una señora aplicación.

Los jefes que tienen gente, quieren usarla, así que en principio les vale tal cual. La única pega es que cada uno luego querrá el excel de su gente en concreto y no un excel general con todos. Eso me hará meter una nueva columna en la tabla "gente", para indicar quién es su jefe. Y me obligará en la parte de obtener resultados a poner un pequeño combobox que diga "elige al jefe cuya gente quieres convertir en excel".

Por otra parte, están los jefes responsables de los proyectos, con poca gente a su cargo, pero si con un proyecto con muchas contraseñas y muchos dineros. Para ellos el excel es lo de menos, pero lo que si están pidiendo es que quieren una forma de ver cuánta gente carga a su proyecto e incluso un histórico, para saber en cada una de las contraseñas del proyecto, cuánto llevan gastado. Tendré que poner una nueva consulta en la que seleccionando un proyecto salga un listado de toda la gente que se ha dedicado a él.

En fin, tiene pinta de que va a ir creciendo. Lo que generaba un excel con unas veintitantas personas dedicadas a unos siete u otro proyectos, van a ser ahora cerca de sesenta personas dedicadas a una veintena de proyectos. Lo que era una consulta simple, se va a convertir en un par de consultas con cláusula where pedida desde la web.

Y hablando de pequeños éxitos por tareas hechas de motu propio. Hace ya un par de años se me ocurrió que una wiki podía ser buena idea y la instalé. Dentro del departamento se va usando, como siempre, unos pocos más que otros muchos. Pero el caso es que se ha ido corriendo la voz por la empresa. El otro día tuve que mostrarle la wiki a uno de los jefazos (cosa que ha sido bastante comentada entre mis compañeros con su parte de coña 😉 ). Parece que quieren poner una a nivel de la empresa.

Todo esto me recuerda mucho al artículo que leí de Joel Spolsky "Logrando resultados cuande se es un peón". Cuando ves una necesidad que tus jefes no resuelven, una buena opción es perder un poco de tiempo en resolverla tú y si se hace bien, se acaba aceptando por todos. También me da un poco de pena comprobar que muchos de los problemas se resuelven o algunas cosas salen adelante porque algún "currito" tiene la iniciativa de resolver el problema o tirar del carro, sin que nadie se lo pida y sin que ningún jefe, teóricamente responsable del tema, tome cartas en el asunto y organice o apoye la iniciativa desde el principio (y, por supuesto, ponga los medios).

Apr 23

Python: Una de cal y una de arena

Sé que "una de cal y una de arena" significa una cosa buena y una cosa mala. El problema es que nunca he sabido si la cal es la mala, la arena la buena o a la viceinversa.

Hace tiempo comenté que iba a hacer una pequeña aplicación web en python para pedirle a la gente que metiera cada mes el tiempo que dedica a cada uno de los proyectos, de forma que luego sacara en excel una tabla con dichos tiempos. Pues bien, ya está hecha (un poco de aquella manera) y funcionando. Así que tras esta mínima experiencia con python, ahí van un par de impresiones, una buena y otra mala, una de cal y otra de arena.

La cosa mala: Me da la impresión, al igual que casi todos los lenguajes de script en los que defines las cosas sobre la marcha, que python es un lenguaje muy difícil de mantener. Al no definirse claramente los tipos, cuando en una función o método recibes parámetros, no tienes ni idea de lo que recibes, salvo que lo pongas muy bien comentado. De hecho, en eclipse con el plugin pydev para programar en python, el autocompletar que te muestra los nombres de atributos y métodos de las clases, eclipse sólo te puede mostrar aquellos atributos y clases que hayas usado previamente en el código.

En java, por ejemplo, hay que declararlo todo, por lo que en cualquier momento sabes cada variable de qué tipo es y qué cosas tiene o a las que puedes llamar. No dependes (salvo para entenderlo mejor) de que el programador se haya acordado de comentar adecuadamente el código.

La cosa buena: Precisamente esta falta de tipado y el poder meter una manzana donde se espera un higo me da la impresión que hace de python un lenguaje muy flexible, y pongo un ejemplo. Puesto que mi aplicación es web, en casi todos los métodos/funciones que he hecho recibo de parámetro un Request Object, que el mismo servidor web se encarga de pasarme y con el que tengo acceso a los parámetros de la petición http, con el que puedo escribir los tag html que se verán en el navegador, etc. Pues bien, para mis pruebas sin servidor web desde eclipse, me hice una clase MiClase con un método write() similar al de Request Object, lo instancié y llamé a mis métodos a pelo pasándoles una instancia de MiClase. El código "tragó" con eso perfectamente, y la salida html salía por donde decía MiClase, es decir, por pantalla normal.

En otros lenguajes como java habría sido necesario heredar del objeto en cuestión y sobreescribir los métodos necesarios, quizás incluso declarar un constructor obligatorio con los parámetros raros que tuviera la clase padre. En java es aconsejable el uso de interfaces precisamente por este motivo, para poder cambiar una cosa por otra sin "cargar" con la clase original heredando de ella. En python no hacen falta interfaces. Basta con que la clase sustituta tenga los métodos que se usen de la clase original.

Todo esto me hace preguntarme si lo del desarrollo rápido de lenguajes como python se refiere a que no es necesario declarar los tipos (desde luego, eso ahorra tiempo, pero me parece un tiempo mínimo respecto a todo el proceso o el tiempo que puedes perder en depuración mientras decides si una variable es de un tipo u otro), o bien se debe a esta flexibilidad del lenguaje, que permite mezclar churras con merinas y todo funciona como debe.

Apr 14

Porque no soy de agobiarme…

No me agobio porque no soy de los que se agobia, pero debería agobiarme con la situación que hay.

Me acaban de poner a llevar un grupo de gente de software que colabora en muchos proyectos y me encuentro con:

  • Un montón de jefes de proyectos que quieren todo ya, para ayer.
  • Un montón de código recién hecho, sin probar y que no es lo suficientemente bueno como para aprovecharlo en otros proyectos sin unas grandes dosis de refactorización.
  • Un montón de jefes de proyectos que quieren todo ya, para ayer.
  • Otro montón de código hecho de hace tiempo, probado, pero que tiene muchos parches poco elegantes por encima y que se hace duro de usar para alguien que no lo conoce.
  • Un montón de jefes de proyectos que quieren todo ya, para ayer.
  • Un montón de gente nueva con los conocimientos justos de java y escasos de los sistemas que hacen.
  • Un montón de jefes de proyectos que quieren todo ya, para ayer
  • Otro montón de gente nueva en la software factory, de los que no sé siquiera si saben java (algunos me consta que sí lo saben), pero desde luego, no conocen nuestros sistemas NADA.
  • y finalmente, un montón de jefes de proyecto que quieren todo ya, para ayer.

Pues eso, que no me agobio porque no soy de agobiarme y como leí en cierto sitio, "si todo es importante, es que nada lo es".

Apr 10

Visita a la software factory

Hoy me ha tocado visita (la primera que hago) a la software factory. Madrugón para coger el tren (la software factory está en otra ciudad) y luego, toda la mañana, una charla en la que nos contaron como es su proceso de desarrollo de software según el CMMI-3.

Una frase que me llamó la atención. Tienen un departamento que se encarga de revisar en los proyectos que "se hace lo que han dicho que van a hacer". Cuando empieza un proyecto hacen un plan de desarrollo, en el que deciden qué métricas van a pasar, qué procesos van a seguir, que pruebas, etc, etc, etc. No importa cuales decidan (dentro de un orden), pero las que digan que van a hacer, deben hacerlas.

Y otra cosa que me ha resultado realmente interesante. Tiene, por supuesto, su departamento de calidad, encargado de ver que en el plan de desarrollo del proyecto se deciden unos procesos adecuados a la envergadura del proyecto. Pero, lo más interesante de todo, es que también tienen un grupo de gente, todos ellos técnicos con experiencia y gurús a los que consultar las cosas, totalmente independiente de los proyectos y que son los realmente encargados de verificar que en en el proyecto se siguen todas las pautas decididas al principio y de que el software está bien hecho. Esto, bien pensado, es totalmente lógico. Si a un proyecto se le exige una base de datos bien diseñada, coherencia en los modelos de datos, que la interface de usuario sea uniforme, que se van a usar determinados componentes comunes, etc, los más cualificados para verificar que eso se cumple es gente experta en esos temas. Incluso son los que aconsejan a los proyectos sobre cómo realizar las cosas para cumplir con todo y tener menos trabajo.

Creo que tenemos bastante que aprender de ellos.

En cuanto a la tarde, una visita a la gente que está desarrollando en los proyectos que controlo un poco, para resolver dudas, explicar un poco más lo que tienen que hacer, etc. Como siempre, hemos encargado el trabajo sin hacer una documentación previa medianamente decente.