Diario de Programación

 Sí, se que ando de vacaciones, pero por suerte para mí, soy de los que todavía les gusta su trabajo y, aunque no estoy trabajando, sí ando "revolviendo" en cosillas que me resultarán útiles más adelante. En concreto, en varios proyectos en los que es posible que participe se usan o se van a usar Web Services. A aprender me toca, sobre todo teniendo en cuenta que es posible que en uno de ellos sea yo el que tome la decisión de qué herramientas/tecnologías usar. Y en ello ando estos días, entre playa y terrazita, leyendo y jugueteando con los Web Services.

Aunque en el proyecto se nos aconseja el uso de .NET, yo soy más partidario de Java, básicamente por tres motivos:

• Es el lenguaje que conocemos todos los desarrolladores del grupo. De usar .NET, tendríamos un tiempo de aprendizaje mayor: los Web Services y el lenguaje.
• En Java casi todo es gratis, con el consiguiente ahorro de licencias, tanto de desarrollo como de los servidores.
• .NET nos limitaría a servidores Windows, mientras que Java nos permitiría desplegar en cualquier servidor, Windows, linux, solaris, …. Sé que está el proyecto MONO, pero no veo la necesidad de meter más complejidad al asunto.

En cualquier caso, no dudo que con .NET se puedan hacer perfectamente Web Services igual que en java, posiblemente más fácilmente integrados con otras cosas de Microsoft, pero no veo ninguna ventaja clara en lo que es estrictamente el lenguaje de uno sobre otro.

El siguiente tema es si SOAP o REST. En principio, por lo que he ido leyendo, me inclino por REST. Aparentemente es más simple y parece ser que es la nueva tendencia. Posiblemente me decida por REST, pero le veo/tengo un par de pegas/dudas.

• Al ser más nuevo, me da la impresión de que está menos soportado por los servidores/herramientas actuales. Muchas de las herramientas traen como coletilla "soporte para REST". Siempre es un riesgo meterse en algo reciente.
• De la misma forma, me da la impresión de que toca codificar más. En SOAP creas tu WSDL y aunque no he buscado con detalle, me da la impresión de que hay miles de herramientas que te generan el código tanto de la parte cliente como de la parte servidor para el uso del Web Service definido por ese WSDL. En REST posiblemente haya equivalentes, pero al ser más nuevo, seguro que hay menos o están menos desarrollados. Insisto, no he mirado en serio, es sólo la impresión que me ha dado en una búsqueda superficial.

Otra gran duda es el tipo de librerías a usar para el Web Service. He visto herramientas como Restlet, (es con la que estoy jugando), pero da la impresión de ser algo muy simple para aprendizaje, no tengo muy claro si puede servir para un servidor en producción con fuertes requisitos de seguridad. También hay cosas como JAX-WS o como Jersey, pero el verlos debajo de GlassFish y sobre todo el primero, debajo de Java EE, me da la impresión de que sería matar moscas a cañonazos. Nuestro proyecto sólo tendría unos pocos Web Services y con datos no muy complejos, aunque sí bastante trasiego.

Finalmente, está el tema de elegir servidor, hay cosas como Spring Web Services, Apache Axis 2 o cosas más tradicionales como Jetty, Tomcat o servidores más "bestias" como Glassfish o JBoss. Por un lado, las ganas de aprender me tiran a Spring, pero el irme a algo conocido me tira por Tomcat. Como he comentado, Glassfish o JBoss me parecen excesivos para lo que pretendemos.

En fin, sigo investigando y haciendo pruebas, pero cualquier sugerencia de gente con experiencia por estos lares, es bienvenida.

 Tengo un compañero, informático, que es de los que lleva ya muchos años en la empresa. Hace ya bastante que dejó de codificar y se dedica a llevar proyectos, o sea, Power Points, Project, Word …

El otro día, a primera hora de la mañana, le veo por el pasillo con el libro "Head Firts Design Patterns" y extrañado, medio en broma medio en serio, le pregunto " ¿Qué?, ¿Te vas a poner ahora con los patrones de diseño ?". No me contestó, sólo echó una sonrisa de oreja a oreja y siguió su camino.

A última hora del día me encuentro con uno de los compañeros que trabaja con él, este sí, más joven y que todavía se dedica a programar. Extrañado por lo de los patrones de diseño, le pregunto "¿Qué pasa con Dani? ¿Se ha puesto ahora con los patrones de diseño ?". A este también se le puso una sonrisa de oreja a oreja, pero contestó … "Es que hemos tenido una demo con el cliente y necesitaba algo para calzar el proyector"

Bueno, con esta chorrada, aprovecho para despedirme el periodo de vacaciones. Buenas vacaciones a todos.

Como no todo es blanco o negro, las metodologías ágiles tienen también muchas cosas buenas. Una de las más sencillas de implementar y con la que conseguir mejoras son las reuniones diarias. Intentamos ya en varias ocasiones hacer Scrum y Kanban, incluso TDD y varias más de las metodologías/prácticas ágiles. Aunque seguimos en el intento, la reunión diaria es la más fácil de seguir y de la que obtener ventajas rápidamente.

La hora teórica de entrada es las 8:00. Habitualmente la gente suele ir llegando sobre las 8:30 y lo primero que hago es ir a tomar café con mi amiguete y luego revisar el correo, el Hudson y el Taskfreak. Imprimo este último y con él, sobre las 9:00 hacemos nuestra reunión de 10/15 minutos. Antes éramos cuatro en la reunión, ahora sólo somos tres.

La reunión la hacemos sentados. Las buenas costumbres aconsejan hacerla de pie para que la gente esté incómoda y la reunión no se prolongue más de la cuenta, pero con el tiempo hemos conseguido no tener ese problema, rara vez dura más de 10 minutos y nos permitimos hacerla sentados.

¿Qué mejoras hemos conseguido con la reunión diaria?

Sensación de grupo

La primera y más importante es la sensación real de la gente de formar parte de un grupo. En nuestro caso concreto, si lo de contar "qué hicimos", "qué vamos a hacer" y "qué problemas tenemos" nos lleva realmente cinco minutos (sólo somos tres), solemos permitirnos unos cinco minutos más de reunión para "cotilleos": comentar como van las pruebas de un proyecto, qué tal le va a uno que está desplazado en la India, los planes del jefe de mover a cierta persona a otro proyecto, etc, etc. Todo esto, además de reforzar la sensación de equipo de trabajo, también refuerza algo los lazos de compañerismo.

Dije que antes eramos cuatro y ahora somos tres. ¿Qué pasó con el cuarto?. Simplemente que le propusieron pasarse a algo más adecuado a su perfil (administrador en vez de programador) y depender de otra persona que no era yo. Pero cuando se lo propusieron, dijo que no quería cambiar del todo, se sentía muy integrado en nuestro grupo y no quería perder eso.

Fue realmente una sorpresa esta objeción. Cuando estaba en nuestro grupo tendía a distraerse de las tareas de programación para dedicarse más a instalar tarjetas de red, configurar routers, instalar software, etc, se le veía claramente que le iba más eso que programar. Le propuse el cambio a mi jefa y ella me dio la razón, pensó que esta persona podía disfrutar más de su trabajo en el grupo de administradores y le propuso el cambio. Y la objeción fue imprevista, efectivamente, dijo que le gustaba más instalar cosas que hacer software, pero que no quería cambiar por sentirse muy integrado en nuestro grupo. Así que el cambio fue gradual, pasó a realizar tareas de administrador poco a poco y siguió acudiendo a nuestras reuniones para hacer su parte de trabajo de programador. Al final la realidad se impuso y realizar dos papeles distintos es imposible, así que dejó cogiendo cada vez más trabajo de administrador y menos de programador y dejó de acudir a las reuniones de forma natural.

De hecho, los tres que quedamos estamos a punto de trabajar en cosas totalmente distintas (tres proyectos distintos, con tres jefes de proyecto distintos y temáticas totalmente distintas). Pero de común acuerdo hemos decidido seguir haciendo las reuniones porque a fin de cuentas el software es software, los problemas son similares y si alguien tiene un problema y lo cuenta a los que ya considera sus compañeros, enseguida se prestan a ayudarle a resolverlo.

Enfocarse en las tareas concretas del día a día

El tener nuestra lista de tareas y decir a primera hora de la mañana "hoy voy a hacer esto" hace que el resto del día tengas claro qué vas a hacer. Supongo que hay algunos que no necesitan este tipo de cosas, pero yo soy de los que tiende a saltar de una cosa a otra. "Comprometerme" con el grupo a que ese día voy a hacer determinada cosa (aunque ninguno de ellos dependa de que yo lo haga), me pone una pequeña traba a distraerme. Me daría vergüenza al día siguiente decir "no he hecho esta tarea porque he estado mirando el correo, navegando por internet, mirando otra vez el correo, un café, probando una herramienta que me he encontrado …."

Así que lo dicho, decir en público "hoy voy a hacer esto", de alguna forma te obliga a centrarte en hacer exactamente eso.

Saber dónde se va el tiempo e incentivo a la mejora

A pesar de todo, en muchas ocasiones, al día siguiente acabas diciendo "No he terminado la tarea que dije ayer" y cuando llegas a la parte de los problemas que has tenido para acabarla dices "me han llamado a una reunión de tres horas", "Se han llevado un ordenador del laboratorio que hacía puerta de enlace de la red del laboratorio y me he quedado sin conexión con los equipos", "me han pedido hacer esto de otro proyecto", etc, etc, etc.

Algunas cosas son inevitables, pero al menos eres consciente de dónde se pierde el tiempo, ya que tienes que decirlo claramente a tus compañeros. Pero cuando esas pérdidas de tiempo tienen arreglo, enseguida "canta" que perdemos el tiempo por algo que hacemos mal y que se puede arreglar/mejorar. Justo lo que pregona Scrum. Aunque en nuestro caso ha quedado un poco fuera la figura de Scrum Master, siempre alguno del grupo coge como tarea mejorar eso que dificulta el trabajo.

Aprovechar la capacidad de los mejores

Y aunque los mejores del grupo o con más capacidad posiblemente no necesiten estas reuniones para centrarse en lo que tienen que hacer o para mejorar su propio proceso de trabajo, no todos tienen esa capacidad.

En estas reuniones las personas de más capacidad se hacen también conscientes de los problemas de los demás, no sólo de los suyos propios. Son capaces incluso de ver posibles mejoras en donde la otra persona ni siquiera ha detectado un problema. De esta forma, todos se benefician de los mejores aunque no vayan específicamente a preguntarle por un problema concreto.

Y los mejores tampoco son infalibles, muchas veces alguien no tan bueno es capaz da una idea o propone algo que se le había escapado

Resumiendo

Resumiendo, que estamos encantados con nuestra reunión diaria y que aunque tiene pinta que el grupo se disgrega (cada uno a su proyecto), por unanimidad queremos seguir haciéndola. Quizás el tiempo nos diga que carece totalmente de sentido… o quizás no.

Y aunque se puede ver claramente que no hacemos una reunión diaria al puro estilo Scrum (no la hacemos de pie, no hay tablero aunque sí lista de tareas, no ha scrum master propiamente dicho), la mejora es apreciable por todos.

Siguiendo un poco con el post anterior, hace tiempo en Verlo para creerlo comenté un código real de una empresa con el que me había tropezado. En ese código había una clase (llamémosla Datos) con 16 atributos estáticos iguales (digamos, atributo1, atributo2, … atributo16). Pulsando un botón (uno por atributo) debía mostrarse en una ventana nueva algunas cosas relativa a uno de esos atributos. En el código había 16 clases Ventana, una por atributo, llamadas Ventana1, Ventana2…. Ventana16. La única diferencia en el código de esas clases, aparte del nombre, era que accedía a Datos.atributo1, Datos.atributo2 … Datos.atributo16

¿Qué habría pasado si hubieran usado TDD?

Supongamos que este mismo programador hubiera hecho este código usando TDD. ¿Qué habría pasado?. Pues lo evidente, habría 16 clases de test llamadas TestVentana1, TestVentana2, … TestVentana16.

Pero TDD no es sólo hacer test, es hacerlos antes. Bueno, supongamos que los ha hecho antes.

Y TDD tiene otro tercer paso, refactorizar para quitar todas las repeticiones posibles de código, incluso las menos evidentes. Bueno, no sé vosotros, pero yo, independientemente de usar o no TDD, me repatearía hacer copy-paste 16 veces de una misma clase y como ser vago a veces es una virtud, habría dado las vueltas necesarias para no hacer esto. Sin TDD se me ocurre simplemente meter los atributos en un array de 16 posiciones y en un método set() de la única clase VentanaUnica pasarle el índice de la posición que debe tratar. Es lo primero que se me ocurre, nada complejo, seguramente hay más y mejores soluciones.

Sin embargo, este desarrollador no lo ha hecho. ¿Por qué?. Se me ocurren cuatro posibles motivos:

1. Totalmente inexperto en java, un array es algo complejo de usar y lo del set() ni lo cree posible. Muchos programadores novatos tiene problemas para hacer que los atributos de una clase se vean en otra y por eso tienden a hacerlos estáticos (justo como ha hecho este señor).
2. No tiene cabeza para programar, por más vuelta que le ha dado, no se le ha ocurrido cómo evitar hacer las 16 clases.
3. Le importa tres pepinos. Para qué se va a complicar la vida si con 16 clicks de ratón (un copy y 15 pastes) lo arregla.
4. Todas las anteriores.

Bueno, pues con este panorama, ¿qué habría hecho al intentar refactorizar con TDD?

1. Ya tengo mi TestVentana1, así que hago mi Ventana1. Ahora mi TestVentana2 y hago mi Ventana2. ¡¡ Código repetido !!. ¡¡ Vamos a refactorizar !!: Imposible, java no permite hacerlo, si java no permite pasar el atributo de la clase Datos a la clase Ventana, Ventana1 y Ventana2 deben ser clases distintas. Y no te digo juntar los dos test en uno solo.
2. Buff, qué dolor de cabeza, no se me ocurre como puedo convertir dos clases distintas que manejan atributos distintos en una sola.
3. Jó, que rollo refactorizar ahora que me está funcionando, voy con los siguientes 14 pastes, que el copy ya lo tengo hecho.
4. Java no deja, no se me ocurre como hacerlo y voy a correr un montón si reaprovecho el copy para el resto de pastes.

Algo como Srcum tampoco evitaría estas cosas. En el sprint diario este señor diría "Ya tengo las ventanas de  los atributos" y todos felices. Bueno, con un poco de suerte, un día diría "tengo la Ventana1 del atributo1", al día siguiente "tengo la Ventana2 del atributo2" y alrededor del quinto día, quizás a alguien se le ponga la mosca detrás de la oreja y quiera ver qué está haciendo. De todas formas, no se tardan 16 días en hacer 15 pastes.

Una herramienta de análisis estático de código integrada en una herramienta de integración continua cantaría esto por la noche, suponiendo que cante cuando encuentra código repetido y, como hacemos nosotros, el compilado falla si no se cumple alguna métrica importante. Desgraciadamente, existe el @SuppressWarnings que la gente se acostumbra a poner por sistema, incluso antes de que cante la métrica (conozco al menos dos personas que lo hacen).

La programación en parejas también habría ayudado, salvo que la pareja de nuestro programador fuera el recién entrado al que le han asignado para que le enseñe.

Bueno, parece que últimamente las malas son las metodologías tradicionales y las buenas son las metodologías ágiles, pero a fin de cuentas, ambas son metodologías y las metodologías, en general, presentan sus problemas. ¿Por qué?. Este artículo de Joel on Software nos da la respuesta.

Un cocinero excepcional hace lo siguiente:

Ahora bien, el Chef Desnudo no sigue ningún apestoso Manual de Operaciones. No mide nada. Mientras esta cocinando, usted ve un frenesí de comida sacudida y siendo arrojada por aquí y allá. "Simplemente pondremos una pizca extra de romero por acá, que no lo arruinara, y le daremos una buena sacudida", dice el. "Amásenlo así. Perfecto. Solo espárzanlo por todos lados." (Si, de verdad se ve como si simplemente lo esparciera por todos lados.

es decir, una persona brillante (cocinero en este caso), no necesita seguir ninguna metodología ni medir nada para obtener un producto genial. ¿Por qué las metodologías?. Pues porque gente brillante hay poca y del resto hay un montón. Para conseguir que el resto de la gente haga un buen producto, la persona brillante escribe una serie de reglas para que la gente del montón sea capaz de hacer lo mismo que él … y eso no funciona. Si se hace, se tienen "Big Macs". El resumen del proceso es el que indica Joel on Software en el mismo artículo

1. Algunas cosas requieren de talento para hacerse realmente bien.
2. Es difícil tener talento a la medida.
3. Una forma en que la gente intenta igualar el talento es haciendo que el talentoso cree las reglas para que los menos talentosos las sigan.
4. La calidad del producto resultante es muy baja. 

¿Y qué pasa con el software?. Pues más o menos lo mismo. Unas personas geniales escribieron unas metodologías para hacer buen software, sean las tradicionales, sea Scrum, sea TDD y el resto de los mortales tratamos de seguirlas. ¿Y qué pasa?. Pues cosas como esta

• "Scrum no nos gusta por la reunión diaria de 90 minutos" http://www.dosideas.com/noticias/metodologias/917-scrum-diario-efectivo.html
• "Hacer TDD mal es más costoso que no hacerlo" http://geeks.ms/blogs/lontivero/archive/2009/09/28/unit-tests-contras-de-implementar-test-unitarios.aspx
• etc, etc.

Total, que para hacer bien Scrum o hacer bien TDD o cualquier otra de las metodologías ágiles hay que hacer un cambio importante de mentalidad, ser bueno en muchas materias incluido como programador, tener mucho sentido común, etc, etc.

Y digo yo… la persona que cumple todo eso y puede hacer realmente bien TDD/Scrum/metodologías ágiles… ¿necesita realmente hacer todo eso?. Estoy totalmente convencido que un programador genial es totalmente capaz de hacer un muy buen software sin preocuparse en absoluto por ninguna metodología concreta, sino siguiendo simplemente su intuición. Y estoy convencido que el resto de los mortales estamos predestinados a hacer mal software directamente o hacer mal software después de haber seguido deficientemente una metodología ágil.

A pesar de todo, es mejor seguir una metodología que ninguna. Imagina en el McDonalds si cada uno se hace los BigMac de cualquier manera. Pero aunque lo he dicho muchas veces, me reitero. Si se quiere un buen software que destaque, el punto más importante a tener en cuenta es elegir a los mejores programadores.

De este post del foro, sale un ejemplo curioso de java. Fíjate en el siguiente código

public static void main (String [] args) {
   Integer a = 100;
   Integer b = 100;

   System.out.println(a == b);
}

Pues bien, este ejemplo da como resultado "true". Si cambias los valores de a y b (pero manteniéndolos iguales), verás una cosa curiosa. Para valores entre -128 y 127, el resultado es "true". Para valores fuera de ese rango, el resultado es "false".

El motivo podemos encontrarlo en este post sobre Auto-Boxing del Weblog de Victor Ramirez. Teóricamente las instancias de Integer que se crean de forma más o menos automáticamente en esas asignaciones deberían ser distintas y el == debería dar siempre "false". Pero por eficiencia, el compilador reaprovecha instancias de estas clases, de forma que cuando se hace este tipo de conversión (de un tipo primitivo a un objeto Integer, Boolean, o lo que sea), se tiene que == da "true" en los siguientes casos:

• Siempre en los Boolean y en los Byte
• Entre -128 y 127 en los Short e Integer
• Entre u0000 y u007F en los Character.

Una curiosidad que puede dar muchos quebraderos de cabeza a un programador novato que no tiene muy controlada la diferencia entre el método equals() y el ==.

Nuestros proyectos suelen ser de larga duración (dos años los que menos) y cuando empezó la crisis a nuestro departamento no le afectó mucho, teníamos proyectos y trabajo para alrededor de dos años. Pero dos años después empezamos a sufrirla, los proyectos están terminándose y durante este período no se han contratado más. Así que andamos buscando trabajo en otros departamentos de la empresa y van cayendo algunas cosas, y proyectos que no son "como siempre".

El banco automático de pruebas que me cayó en su día es uno de esos proyectos de otros departamentos. Su duración prevista era de unos tres meses y debo tenerlo terminado en Julio. Mi parte de software va bastante bien, pero el banco lleva mucho hardware (instrumentación electrónica, conectores, cables, aparatos variados, incluso un "armario" para montarlo todo) y creo (sé seguro) que todo eso van a retrasarse. Supongo que tengo trabajo de integración con todo ese hardware al menos hasta Septiembre. El lenguaje de programación para el banco lo elegí yo y pensé en LabWindows/LabView, pero visto el corto plazo y que el protocolo SCPI de control de instrumentación es bastante simple, decidí hacerlo en java.

Y pasado Septiembre … ya me tienen buscado otro proyecto. Este es en .NET, así que me toca aprender un lenguaje nuevo. Espero sólo un par de cosillas:

• Que me metan en el proyecto a un nivel de "currito", de forma que pueda programar y aprender .NET. No sé qué me han comentado de requisitos y zarandajas varias, así que me veo más con el Word que con el .NET. Bueno, en ambos casos es Microsoft.
• Que el proyecto dure lo suficiente (fecha prevista Septiembre de 2011) como para aprender bien .NET. Supongo que podré hacer cosas en .NET en cuestión de semanas, pero sé por experiencia que pueden pasar años hasta que aprendes a hacer las cosas correctamente y ni aún así, siempre estás aprendiendo. De hecho, esta frase "
  Sigo pensando todo de nuevo mil veces y todavia encuentro mejores maneras de hacer lo mismo. Creo que ya tenemos todas las soluciones al igual que lo creia 8 años atras" del blog de Lucas Ontivero creo que refleja perfectamente lo que quiero decir.

Ya me veo añadiendo un apartado en algún sitio de esta web sobre .NET

La aplicación de bicis a la carta que le estoy haciendo al de la tienda de bicis todavía no está en marcha, falta básicamente subir un catálogo de piezas y clasificarlas (depende más de él que de mí), aparte de arreglillos/añadidos que vaya haciendo. De todas formas, ya he empezado a amortizarla.

El otro día se me ocurrió dejarle la bici a mi hija de 13 años y se ve que se le cruzó un árbol en el camino y se dio contra él. Un rasguño en el brazo, uno de los cables del freno a la porra, tirita a la niña y la bici a la tienda.

Pues nada, le ha cambiado el cable del freno, la probó, le cambió también los cables de los cambios, un buen engrase, la ha tratado con cariño y me ha hecho un buen descuento: no me ha cobrado. Voy a tener que ir poniendo alguna cosa más en la web.

Cuando empezó la crisis, debe ir ya para dos años, noté una bajada importante en los ingresos de google adsense. No sé si la gente se anunciaba menos, pagaba menos por los anuncios o se hacían menos clicks porque la gente no estaba muy por la labor de comprar. 

Desde entonces, el número de visitas ha ido subiendo más o menos de forma constante, pero los ingresos se han mantenido igual de bajos. Así que el otro día, en un rato de aburrimiento, decidí investigar sobre cómo se podían mejorar estos resultados. Me encontré, por supuesto, con los típicos consejos estándar de jugar con los colores de los anuncios, sus posiciones en la página, etc, etc. Pero investigando un poco más, encontré dos puntos que son realmente importantes.

Temática de la página

Google adsense paga por click en un anuncio y de acuerdo a lo que el anunciante esté dispuesto a pagar por ese click. Este punto es posiblemente el más importante. Es más probable que la gente haga click en nuestros anuncios si viene a nuestra página con intención de comprar algo. Y nos pagarán más por ese click si el anuncio es sobre algún tema donde se maneje dinero en serio.

Por ejemplo, si nuestro sitio va sobre hipotecas, móviles, coches o turismo, es muy posible que la gente que caiga en nuestra página esté mirando precisamente una hipoteca para comprarse un piso, cambiar de móvil, de coche o irse de vacaciones. Por ello, los anuncios de google adsense de nuestra página, que son relativos al contenido de la página, tienen grandes posibilidades de resultarle interesantes al visitante y que haga click en ellos. Además, como son sectores que manejan dinero y con fuerte competencia, es muy posible que los clicks en esos anuncios se paguen bien.

Pero, ¡pobre de mí!, ¿qué pasa si el sitio es sobre java?. Los que acaban en esta página suelen ser estudiantes o gente recién incorporada al trabajo que todavía no tienen mucha experiencia en programación. Normalmente buscan resolver alguna duda o problema de java y no tienen intención de comprar nada. Encima, los posibles anuncios sobre temática java suelen ser herramientas/IDEs de java, casi todos gratuitos, o cursos de java. Nada que mueva grandes cantidades de dinero o por lo que los anunciantes estén dispuestos a pagar mucho por click.

Así que lo más importante de todo es principalmente la temática del sitio. Eligiendo una temática adecuada y consiguiendo no pasar desapercibido en los buscadores, se pueden conseguir ingresos importantes con relativa facilidad. El problema de los temas de dinero es que hay mucha competencia, por lo que salir adecuadamente posicionados en los buscadores puede ser una tarea difícil.

Burro grande, ande o no ande

En este tema, afortunadamente, si he podido jugar y en un par de semanas he comprobado un aumento apreciable (pero no espectacular) en los ingresos.

El consejo que he leído es que si google adsense permite tres anuncios, pongamos los tres anuncios. Cuantos más anuncios tengamos en la página, más fácil que uno interese al visitante. Y que el anuncio sea lo más grande posible, en concreto la caja grande de 336×280. Esta caja es la que estadísticamente tiene más porcentaje de clicks.

Así que lo he aplicado, no en este blog, pero sí en otras partes del sitio. Y aunque me da la impresión de que pueden molestar un poco (ocupan demasiado sitio), sí es cierto que los ingresos han aumentado alrededor del 50%,

Y google sigue loco

Y aunque no tiene que ver con el tema de los ingresos, sigo viendo que google cada vez está más loco. Ahora los ingresos se pueden ver en la interfaz antigua de google adsense, en la interfaz nueva de google adsense e integrados con los informes de google analytics. Pues bien, cualquier parecido de los ingresos mostrados entre las tres interfaces es pura casualidad. Es más, dentro de una misma interfaz obtengo resultados distintos según quiera ver los resultados de los 3 últimos meses o de los 12 últimos meses.

Google analytics me indica que no se ha mostrado ningún anuncio de google ni se ha obtenido ningún ingreso en los dos últimos días en la chuwiki. En los gráficos que muestra se ve una línea más o menos horizontal con una bajada brusca a cero en los dos últimos días. Google adsense dice que sí y de hecho los resultados son los habituales, no ha habido ningún cambio en estos dos últimos días, todo sigue normal. No sé, quizás se deba a que ahora google muestra también anuncios de otras compañías de anuncios y estos no se contabilicen igual en las dos herramientas.

En la interfaz vieja de google adsense, si consulto los pagos de los tres últimos meses, sale en la primera línea un "saldo pendiente de meses anteriores", que curiosamente se suma en toda la columna, pero no en la de pagos. El resultado es que si según eso me deben X€, me pagan "X-saldo pendiente de meses anteriores"€ y siempre está ese saldo pendiente. Si ahora en la misma interfaz consulto 12 meses de pagos, ese saldo pendiente es cero y todo cuadra bien. Esto sí tiene pinta de ser un "bug" o, al menos, no encuentro una forma de explicarlo.

Y entre la interfaz vieja y la nueva suele haber diferencias no muy grandes en los euros. Lo achaco a que quizás una interfaz y otra miren el cambio de día a distintas horas (una en la española y otra en la americana, por ejemplo) y la diferencia se deba quizás a que aunque en ambos casos midan periodos de tiempo iguales, lo hacen con desfase de unas horas. En cualquier caso, despista.

Tampoco he visto grandes "revuelos" por todo esto en blogs o foros, así que me imagino que serán cosas mías.

Todos nuestros sistemas se parecen, unos llevan determinados módulos, otros no. Por eso, siempre he estado pensando la forma de hacerlos modulares de forma que sea fácil quitar o poner módulos de un sistema a otro, cada uno con su configuración. Cuando me puse a pensar en ello llegué a la conclusión de que sería buena idea hacer que cada módulo fuera un jar, independiente de los otros. Luego, en un sistema, es cuestión de instanciar y configurar aquellos módulos que nos interesen, trayendo sólo los jar necesarios.

Puesto que los módulos interaccionan entre ellos y cuando uno de ellos quiere hacer algo normalmente necesita datos de otro módulo, o a veces cuando un módulo genera algo necesita avisar a los otros para que sigan el proceso, también me puse a pensar en ello. Una especie de mecanismo de suscripción de eventos, de forma que en algún sitio cerca del main, donde se instancian y configuran módulos, también se hicieran suscripciones a determinados eventos de un módulo y se avisara de ellos a los otros módulos.

Afortunadamente, antes de ponerme a codificar algo como esto, se me ocurrió investigar por internet y me encontré con los contenedores de inversión de control y en concreto con Spring Framework. Aunque el framework está muy pensado para aplicaciones web, está bien diseñado y puedo bajarme y usar sólo el núcleo, lo que me permite a través de ficheros XML instanciar los distintos módulos, configurarlos y hacer que se vean unos a otros. También me proporciona un sistema de publicación y suscripción de eventos entre módulos. Justo lo que quería.

Así que como suelo hacer en estos casos, cogí a un grupo de gente afín a mis ideas peregrinas, les conté lo fácil y bien que podiamos usar Spring Framework en nuestras aplicaciones y lo usamos en uno de los proyectos que empezaban. La experiencia fue buena y todos quedamos bastante contentos en general, así que decidimos ir aplicándolo a más proyectos.

Pero al empezar a usarlo en más proyectos e involucrar a más gente, empecé también a encontrar más oposición y otros puntos de vista. Un compañero mío más crítico que yo con las innovaciones comentó que "Spring no es más que una forma "friky" de hacer news". No obstante, él también andaba buscando una forma de configurar con ficheros sus módulos, ya que se ve repitiendo código de configuración prácticamente igual de un proyecto a otro.

Y el otro día sucedió algo que me ha hecho empezar a dudar de la utilidad de Spring Framework, al menos usando sólo el núcleo y en aplicaciones de escritorio. Este compañero en uno de los proyectos en los que tiene cierta responsabilidad me dijo que se estaban instanciando en Spring dos módulos iguales con configuración distinta, pero que habían cambiado los requisitos y debíamos eliminar uno de ellos y cambiar el otro por un tercero distinto. Nos pusimos a ello.

Borrar uno de los módulos es fácil, sólo hay que ir borrando las referencias en los ficheros XML y en algunos sitios muy concretos del código. Cambiar el otro fue algo más complejo, buscarlo para reemplazarlo, cambiar nombre de clases, parámetros a inicializar, buscar referencias para ver si son compatibles, etc, etc. Una vez que creímos todo estaba hecho, arrancamos la aplicación y nos saltan un par de errores, nos habíamos equivocado en el paquete de una de las clases de un bean de Srping Framework. Más cambios, nueva prueba y nuevo fallo. Esta vez, a la tercera fue la vencida y todo funcionando. Pero mi compañero hizo el comentario que me metió la duda en el cuerpo: "Si en vez de hacer los news y la configuración en ficheros XML los hubieramos hecho en código, todo esto habría cantado en el mismo IDE. Prefiero ver los errores mientras escribo que verlos después arrancando la aplicación".

Y tiene razón, hacer news y configurar en XML tiene la pega de que errores que se verían inmediatamente mientras escribes en el IDE (un new de una clase que no existe por ejemplo, o la llamada a un set para configurar algo) no los vemos hasta que arrancamos la aplicación.

Hay un plugin para eclipse que permite ver si lo que escribes en el XML de Spring es correcto (las clases existen, los métodos existen, etc), pero no lo tenía instalado y lo de que hayan cogido Spring los de SpringSource, me da "mal rollo", parece que se quieren dedicar a cobrar por dar cursos y que este tipo de plugins o incluso las descargas están cada vez más escondidas previo registro.

Instalaré el plugin, miraré la posibilidad de hacer un test de JUnit que verifique que un XML de Spring es correcto y a ver qué pasa. De todas formas, empiezo a pensar que sólo para hacer news no merece la pena. Me queda el tema de los eventos al que sí sacamos partido….