Diario de Programación

Una pequeña estupidez que hemos descubierto. Si tienes windows xp y pulsas Ctrl-AltGr y la flecha hacia abajo, la pantalla se pone boca abajo. El ratón funciona al revés. También funcionan las otras flechas, para ponerla de lado o volver a colocarla bien.

¡¡ No veas lo que me divierto dándoles la vuelta a la pantalla de mis compañeros sin decirles nada !!

Ya puestos, otra tontería para los que usan ksh de unix. Con el comando

$ stty erase e

haces que la tecla e se convierta en la tecla de borrar. También es otra broma entretenida de hacer a los compañeros. Según escriben comandos, cada vez que pulsan la e, se les borra la letra anterior y, por supuesto, no se escribe la e.

Para comparar cadenas en java tenemos los métodos tradicionales que todos conocemos, aunque quizás no sea tan conocida la clase Collator.

Por un lado, el == nos compara si las dos instancias de las cadenas son exactamente la misma. No es la comparación que se debería usar para comparar cadenas de texto, puesto que nos podemos llevar sorpresas. String a = "Hola" es distinto de String b = new String("Hola")

El método equals() de la clase String sí compara las cadenas y nos dice si son iguales o no en contenido. El problema de este método es que distingue mayúsculas de minúsculas y de letras con acento. Con este método, son distintos "Hola", "HOLA" y "Hóla".

El método compareTo() de la clase String nos da un poco más de información. Devuelve cero si son iguales, negativo si una es menor que la otra y positivo si es mayor. El problema de este método es que considera las letras ordenadas según estén en la tabla de caracteres que usemos. Por ejemplo, si usamos códigos ASCII, entonces ‘A’ está antes de ‘a’ que a su vez está antes de ‘á’. Por ello, "Hola" sería menor que "Zapato" y este menor "hola". Un orden alfabético basado en este método, daría primero las palabras que empiezan por mayúscula y luego las mismas con minúscula.

Para conseguir una ordenación alfabética real, deberíamos usar la clase Collator. Esta clase, en función del idioma, tiene en cuenta todo esto. Collator se puede configurar para que considere que ‘A’, ‘a’ y ‘á’ son iguales o para que los considere distintos. La forma de ordenación alfabética correcta se conseguiría con este código

// Se obtiene un Collator adecuado para nuestro idioma.
Collator comparador = Collator.getInstance();

// Se configura para que ‘A’, ‘a’ y ‘á’ sean iguales.
comparador.setStrength(Collator.PRIMARY);

// Estas dos cadenas son iguales, compare() daría cero
System.out.println(comparador.compare("HOLa", "hóla"));

Tienes todo esto un poco más detallado en cómo comparar cadenas en java en la Chuwiki.

Una de geometrías, que a mí lo de las mates me gusta:

La geometría normal que conocemos es la geometría Euclidiana. Pero, ¿qué son las geometrías no euclidianas? ¿de dónde salen?.

Euclides, en su momento, dio cinco axiomas en los que basar su geometría. Estos cinco se presupone que son ciertos sin necesidad de demostración y sobre ellos se construye el resto de la geometría. Estos cinco axiomas son:

• Dados dos puntos se puede trazar una y sólo una recta que los une.
• Cualquier segmento puede prolongarse de forma continua en cualquier sentido.
• Se puede trazar una circunferencia con centro en cualquier punto y de cualquier radio.
• Todos los ángulos rectos son iguales.
• Si una recta al cortar a otras dos forma ángulos internos menores a un ángulo recto, esas dos rectas prolongadas indefinidamente se cortan del lado en el que están los ángulos menores que dos rectos.

Los cuatro primeros son bastante evidentes, y podemos creernos que son ciertos sin necesidad de demostración. Sin embargo, el quinto, tal cual lo enunció Euclides, parece un poco raro, difícil de entender y difícil de creérselo sin una demostración. Con el tiempo, este quinto axioma se cambió por este otro más sencillo, pero equivalente.

• Por un punto exterior a una recta, se puede trazar una única paralela.

A partir de estos cinco axiomas, se pueden demostrar todos los demás teoremas de la geometría. Los cinco axiomas son necesarios. Ninguno de ellos se puede deducir de los otros y si falta alguno de ellos, no se puede construir la geometría.

Sin embargo, el quinto axioma dejó un poco preocupados a los estudiosos que vinieron detrás. Ese quinto axioma parece muy complejo y parece que no es algo que se pueda creer sin una demostración. Por ello, mucha gente se puso a intentar encontrar una demostración basándose en los cuatro anteriores. Una forma de demostrar es suponer que no se cumple y ver que se llega a una incongruencia con alguno de los cuatro primeros.

Supusieron primero que por un punto exterior a una recta no se podían trazar paralelas. Se pusieron a construir, hacer demostraciones…. y no llegaron a ningún absurdo. Se construyó una geometría perfectamente coherente en la que por un punto exterior a una recta no se pueden trazar paralelas. Sería, por ejemplo, el caso de hacer geometría sobre la superficie de una esfera. Si consideramos que las rectas son los círculos máximos, por un punto exterior a una recta no se puede trazar otra recta que no corte a la primera. Estas geometrías se llaman geometrías elípticas.

Luego supusieron que por un punto exterior a una recta se pueden trazar varias paralelas…. y tampoco llegaron a un absurdo. Se construyó una geometría coherente y completa en la que por un punto exterior a una recta se pueden trazar varias paralelas. Este es el caso de una geometría que se construya sobre la superficie de una hipérbola. Estas geometrías se llaman geometrías hiperbólicas.

En resumen, las geometrías no euclidianas no son algo que se pueda ver y tocar en el mundo real -quién sabe-, son símplemente geometrías sobre papel que se han construido tratando de buscar una demostración del quinto postulado de Euclides, que parecía un poco raro.

Esta esto del blog y de la página un poco abandonado. ¡¡Vaya semanitas que llevo!!

• Me duele una muela, dentista al canto.
• Comunión de mi hija el fin de semana: familia, preparativos, fotos, vestido, traje y zarandajas varias.
• En el trabajo me están liando con tonterías: jornadas tecnológicas -por llamarlo de alguna manera-, entrevistas de trabajo, incidencias con pruebas del cliente, …

En fin, que necesito una vacaciones YA.

Scrum parece un método sencillo. Sin embargo, veo en internet que hay cursos para asesorar a empresas que quieren implantarlo y parece que es un paso previo importante. Nosotros lo hemos intentando, un grupo de ocho personas, sin curso previo ni nada. Pusimos "Sprints" de una semana, quizás algo cortos, pero el proyecto sólo va a llevar un par de meses, así que necesitamos puntos de control más frecuentes.

Ya hemos terminado nuestro primer Sprint y bueno, tengo que reconocerlo, en algunos puntos ha sido un poco desastre. Ahí van las conclusiones y los motivos.

En primer lugar las tareas a realizar esa semana no estaban demasiado definidas. Alguna sí, la más importante, pero otras eran un poco "sin definir". Cosas como que estuviera una determinada ventana, pero sin aclarar si debería funcionar completamente, en parte o de ninguna manera, sólo verla.

También había gente que estaba haciendo cosas de las semanas anteriores relativas al proyecto y se puso como tarea el acabarlas, pero sin analizar exactamente qué estaban haciendo, qué quería decir "acabarla", etc.

Las reuniones diarias no se llevaron demasiado bien -culpa mía-, ya que aunque todos comentaban qué había hecho y que iban a hacer, así como posibles problemas/ayudas, la gente era un poco reacia a decir cuánto tardarían. Supongo que en gran parte porque tampoco tenían claro cual era exactamente el alcance de sus tareas. He visto además, que esto parece afectar más a los nuevos. Una tarea sin definir claramente, quizás uno con experiencia tenga más criterio para intuir que es exactamente lo que tiene que hacer y lo que le va a llevar, pero los más nuevos, por no conocer quizás los entresijos del proyecto, no saben exactamente el alcance de lo que se les pide.

Finalmente, el desastre del Viernes. Supuestamente era el momento de hacer la reunión del final del Sprint, en la que nos autohacemos una demo de lo conseguido y comentamos la forma de trabajar para buscar mejoras. Bien, interfirió otro proyecto, en el que el Lunes viene el cliente a  pasar un punto de control, por lo que de las ocho personas del proyecto actual con Srcum, cuatro tuvieron que dedicarse en exclusiva a preparar el punto de control del proyecto viejo, precisamente las cuatro personas con más experiencia. El resultado es que el Viernes ni hubo demo, ni reunión, ni nada de nada. Eso sí, al menos se entregó la verisón al Product Owner para que hiciera sus pruebas, así que el Lunes tendremos que hacer lo que no hicimos el Viernes y empezar otro nuevo Sprint.

Espero para este nuevo Sprint subsanar los errores que he visto, aparte de los que pueda comentar el equipo en la reunión. Trataremos de convencer al Product Owner de que ponga como tareas prioritarias las que actualmente están a medias y trataremos de concretar con más detalle qué quiere decir "acabarlas". Además, el proyecto viejo estará de "punto de control" con el cliente, por lo que espero que esta semana no interfiera mucho.

Una pequeña nota final. Quizás porque yo soy un poco "asocial" y tiendo a llevarme mejor con los ordenadores que con la gente, la reunión diaria se me hace un poco cuesta arriba …

En mi empresa llaman "área vertical" a los grupos de gente que se dedican a un proyecto. Llaman "área horizontal" a la gente que da soporte a los proyectos.

En principio, en cuestión de software, sólo había "verticalidades", es decir, sale un proyecto, se asigna un grupo de gente y ellos se lo guisan, ellos se lo comen. Esta filosofía tiene una gran ventaja y un gran inconveniente. La ventaja es tener un grupo de gente dedicado exclusivamente al proyecto, con lo que el proyecto avanza de forma más eficiente con responsables más claros. El inconveniente es que si hay varios proyectos en paralelo, la poca comunicación entre ellos hará que repitan código dos veces, que las interfaces de usuario no se parezcan, que se peleen por separado con problemas similares y aporten soluciones distintas.

Si se hace un "área horizontal" de gente de software, de forma que los proyectos tienen poca gente en exclusiva y lo que necesitan se lo piden a ese área de software, la ventaja se convierte en inconveniente y el inconveniente en ventaja. Si el área de software se encarga de hacer las cosas, posiblemente reutilicen mucho de su propio código, se peleen una única vez con los problemas, aporten soluciones iguales siempre y las interfaces de usuario sean muy similares, pero …. también se convierte en un "cuello de botella" para la gente de los proyectos. Los responsables de los proyectos no tienen el control de la gente y en ocasiones tienen que esperar su turno detrás de otros proyectos quizás prioritarios.

De hecho, en mi empresa cada cierto tiempo se dan "bandazos" de un estilo al otro. Se hace por proyectos, hasta que el cliente empieza a protestar y decir "¿Por qué en este proyecto se hace así y en otro que me entregasteis hace un mes se hace asá?. La empresa decide cambiar la filosofía y hacer "áreas horizontales" … hasta que los proyectos empiezan a no salir y la excusa de los responsables es que el área de software no les responde con suficiente velocidad.

En fin, un problema que me parece interesante y en el que ando algo metido, buscando una solución que trate de coger lo mejor de ambas opciones.

Últimamente, con el tema de Scrum, ando mirando un poco más sobre metodologías ágiles. Al final se parecen todas mucho, al menos en el fondo. Puede que en las formas se diferencien algo, pero siempre es lo mismo.

Supuestamente son útiles para proyectos en los que te pueden cambiar los requisitos cada poco, que el cliente no sabe muy bien lo que quiere o, por necesidades del mercado, puede decidir de repente que quiere otra cosa. También son útiles para grupos no muy grandes de gente, aunque cosas como Scrum parece que llegan a aplicarse a grupos de hasta cincuenta personas.

Las ideas básicas de todas estas metodologías son básicamente dos:

• Hacer versiones entregables al cliente cada poco tiempo, con un poco más de funcionalidad que la versión anterior. Así el cliente puede ver lo que se está haciendo y decidir los cambios sobre la marcha. Mientras se desarrolla esa mini-versión en un plazo corto -aproximadamente un mes-, no deberían cambiarse los requisitos, de forma que la gente trabaje centrada en algo concreto, rindiendo más.
• Mucha comunicación entre los programadores entre sí y con el cliente. Suelen decirse cosas como reuniones diarias, programación en parejas, etc, etc. Todo esto para que se pueda trabajar de forma efectiva sin necesidad de hacer documentación.

Aquí tienes un artículo de Martin Fowler, traducido al español, en el que se hace una aproximación y un resumen de varias de estas metodologías. Podrás comprobar que con variantes en la forma, todas dicen lo mismo de fondo.

Bueno, hoy hemos hecho la primera reunión para contar a la gente de qué va Scrum -ya lo sabían más o menos, porque les fuí dando la "paliza" individualmente, así que se lo veían venir-.

Llevamos la lista de tareas que nos había preparado nuestra Product Owner, y elegimos unas cuantas para hacer en una semana. El tiempo es quizás un poco corto, pero el proyecto no tiene un plazo largo y la jefa tiene interés en ir viendo las cosas más inciertas primero. Así que estamos en ello.

La reunión fue un poco de aquella manera por varios motivos. Lo de "primera hora de la mañana", como tenemos horario flexible y no todos estamos a primera hora de la mañana, se quedó para cerca de las once. Supongo que no tiene importancia siempre que mantengamos la hora más o menos, pero trataremos de hacerlas un poco antes.

Por otro lado, yo tampoco soy ningún relación públicas, y además nos falta experiencia en estos temas. En fin, ya iremos aprendiendo. A final de semana contaré qué tal fue el mini-Sprint este….

Cuando llevas tiempo programando y te preocupas de que tu código sea reutilizable en varios proyectos, vas consiguiendo componentes -o librerías- de cierta embergadura que puedes usar en varios proyectos. Ojo, no hablo de librerías normalitas, de componentes pequeños reutilizables, sino de módulos grandes. Normalmente estos módulos interactúan entre sí, por lo que se suelen poner interfaces para que las dependencias no sean muy fuertes.

Sin embargo, estos módulos no son independientes. Dependen unos de otros a través de sus interfaces. Si no vamos con cuidado, es fácil que para usar un módulo tengamos que traernos otros que no nos interesan, símplemente porque necesitamos sus interfaces.

Veamos todo esto con un poco más de detalle. Imagina que vamos a controlar un GPS y vamos a pintar en un mapa la posición del GPS. Si queremos hacer módulos reutilizables, podemos hacer los siguientes

• Una clase o grupo de clases que se conecta con el GPS para obtener la posición que nos vaya dando este equipo.
• Una clase o grupo de clases que hacen de MAPA. En ella pintaremos la posición que nos de el GPS.

Solo dos, que si no, nos liamos mucho…

Tenemos que comunicar estos módulos entre sí de alguna forma, para que el GPS pase las posiciones al MAPA. Podríamos, por ejemplo, aplicar un patrón observador al GPS de forma que MAPA implemente la interface ObservadorDePosicion y se suscriba a cambios de posición en el GPS.

¿Cual es el problema?. La interface del observador de Posición estará posiblemente en GPS, así que MAPA necesita el módulo GPS, sólo por la interface, aunque en otro proyecto no haya GPS. Si ponemos esta interface en MAPA, entonces GPS necesita a MAPA sólo por esa interface, aunque no haya mapa en nuestro próximo proyecto con GPS.

¿Cómo podemos evitarlo?. Usando lo que yo creo que se conoce como código pegamento -Glue Software-. La verdad es que no tengo ni idea si es eso del código pegamento. Se que existe algo que llaman código pegamento, pero nunca lo he visto "en acción", pero lo que vamos a hacer responde muy bien a esa descripción.

Para evitar la dependencia, hacemos nuestro GPS con su interface ObservadorDePosicion y su patrón observador. Al MAPA le ponemos un método tomaPosición(). Ambos módulos son totalmente independientes, ni MAPA implementa ObservadorDePosicion ni GPS ve a MAPA para nada. Para comunicarlos únicamente tenemos que hacer una clase PEGAMENTO en nuestro proyecto que reciba tanto a GPS como a MAPA. La clase PEGAMENTO se suscribe a GPS implementando su interface ObservadorDePosicion y cuando reciba una posición, llama al método tomaPoscion() de MAPA. Es más, incluso puede traducir la posición en el formato que la reciba del GPS para adaptarla al formato que necesite el MAPA.

El resultado son dos módulos, GPS y MAPA, totalmente independientes, que ni siquiera tienen que estar de acuerdo en el formato en que se pasan el dato Posición. En el proyecto se hace una clase PEGAMENTO, únicamente válida para ese proyecto y bastante sencilla de hacer.

Imagina ahora un proyecto más grande, con varios módulos. Pueden hacerse los módulos totalmente independientes entre ellos y perfectamente reutilizables en cualquier otro proyecto ellos solos. Dentro del proyecto, cada asociación entre dos módulos se establecería haciendo una clase PEGAMENTO. Habría tantas clases PEGAMENTO como asociaciones entre módulos.

Lo más divertido sería el main(), que quedaría algo parecido a esto.

Modulo1 m1 = new Modulo1();
Modulo2 m2 = new Modulo2();
Modulo3 m3 = new Modulo3();
…
Pegamento1Con2 p12 = new Pegamento1Con2(m1,m2);
Pegamento1Con3 p13 = new Pegamento1Con3(m1,m3);
Pegamento2Con3 p23 = new Pegamento2Con3(m2,m3);
…

En fin, todo ventajas. Módulos completamente independientes que se pueden desarrollar por separado, de forma aislada, probar aislados e incluso instanciar sueltos. Un montón de clases Pegamento que representan claramente una asociación. Casi, casi es como coger un diagrama UML y por cada paquete/módulo hacer una librería y por cada línea de asociación una clase Pegamento.

Obviamente, esto tan "complejo", vale para módulos de cierto nivel. Si vamos a hacer una librería matemática, no vamos a andar poniendo un ObservadorResultadoOperacionSeno …

Bueno, ya está dado el paso.

He elegido uno de los proyectos que me quedan más cercanos y en los que hay gente más joven y abierta a nuevas ideas. Son precisamente con los que puse en marcha xplanner. En fin, no dejo de pensar que este proyecto me está sirivendo para hacer experimentos …

Esta mañana he hablado con la responsable del proyecto y no me ha puesto ninguna pega, aunque ya llevo varios días dándole la paliza con el tema y supongo que se lo veía venir. Hoy se ha dedicado a meter y ordenar en xplanner las tareas a hacer y ella será la que haga de "Product Owner".

El lunes haremos la primera reunión con el "Scrum Team", para explicar todo y para decidr nuestro primer "Sprint Backlog". No tenemos figura para clara para "Scrum Master", pero supongo que yo haremos las veces uno de los que tienen más experiencia y yo, al menos mientras empezamos a poner todo esto en marcha y veamos con unos cuantos Sprint que el tema va bien. Luego seguirá solamente la otra persona y yo me dedicaré a "incordiar" en otro proyecto.

Puesto que xplanner se adapta bien a esta metodología, lo seguiremos usando. Ya hay dentro de xplanner dos iteraciones. Una de ellas ficticia que hace de Product Backlog y otra que será nuestro primer Sprint, de momento vacío. El Lunes pasaremos algunas de las tareas de la iteración ficticia al Sprint Backlog, detallaremos las subtareas y estimaremos los tiempos. El mismo xplanner proporciona un buen gráfico de avance.

Entre todas las ventajas que tiene Scrum y que se leen por ahí, pensándolo, he encontrado otra que aplica bien a nuestro caso particular. Los proyectos que hacemos suelen ser bastante grandes y una queja generalizada de los programadores es que no conocen el sistema completo. Cada uno suele centrarse en alguna parte concreta y hay otras partes que ni siquiera sabe que existen.

La reunión diaria y sobre todo, la "demo" que se hace en la reunión del final del Sprint, van a dar a todo el mundo la posibilidad de ver y enterarse de todas las partes del sistema. Todo esto en principio va a crear más sensación de equipo y más conocimiento general del sistema global. Quien sabe, quizás con eso incluso la gente trabaje más motivada, viendo como encaja su parte en el resto de todo lo demás.