Nov 27

Personalización de la página 404

 

La página 404 es la página de error que presenta un sitio web cuando se busca en él una página que no existe. Suele ser buena idea poner en esa página algún texto o algunos enlaces de forma que el usuario que ha terminado en ella, tenga una forma de llegar a donde pretendía llegar y, en plan webmaster egoísta, conseguir que no se vaya de nuestro sitio y siga navegando por él.

Google nos ofrece lo que llama widget 404, un trozo de código que podemos poner en nuestra página 404 y nos mostrará una caja de búsqueda de google, rellena con las palabras significativas de la URL fallida y que busca en el sitio web.

Aunque hace tiempo que la conocía, me he decidido a ponerla, y puedes ver el resultado si pinchas el enlace a http://www.chuidiang.com/esto-no-existe.html.

Nov 26

Excedido el límite de transferencia mensual

 

En su día tenía mi página web en geocities, sitio gratuito, pero con un límite de transferencia mensual pequeño (no recuerdo cuánto). Con el tiempo empecé a superar ese límite y empecé a obtener mensajes de error al visitar la página, estilo "este sitio está temporalmente suspendido porque ha superado el límite de transferencia…."

Así que me fui a un hosting de pago. Los 20 Gigas de transferencia mensual que me daban me parecía algo parecido a infinito comparado con el límite de geocities  Y así fue desde Marzo del 2006 hasta hoy …. en el que me ha vuelto a aparecer un mensaje "este sitio está temporalmente suspendido…..". Hoy he superador el límte de 20 Gigas de transferencia mensual y sólo estamos a día 26.

Ampliar el plan del hosting me sale unos dolares más caro y la otra opción es buscarse otro hosting con un precio similar y más transferencia. Pero la verdad es que en este hosting me va bien y el servicio técnico suele solucionarme los problemas e incluso contestar a las dudas. Así que me decidí, quizás un poco precipitadamente, a pedirles el siguiente plan, con 30 Gigas de transferencia mensual. Fue cuestión de menos de una  hora, desde que mandé el correo hasta que mi sitio tenía el nuevo plan y estaba otra vez en funcionamiento.

Y digo que quizás me precipité porque luego, investigando los logs de acceso, he visto que hay páginas que enlazan directamente a imágenes en mi sitio, en concreto, los de taringa a imágenes de mi página de efectos ópticos. Supongo que no es ese el único caso y espero que tampoco sea el motivo principal por el que excedo el límite de tráfico, pero la solución es sencilla. Basta configurar el servidor para que no admita enlaces directos a las fotos y, de hecho, las imágenes que faltan en el enlace de taringa son las que estaban descargadas directamente de mi página.

En fin, antes usaba un 10% del espacio de disco duro que tenía disponible en el hosting (1 Giga) y ahora tengo el doble de disco (2 Gigas), así que sólo uso un 5%. Tendré que ponerme las pilas y liarme a escribir tutoriales para amortizar el nuevo plan de hosting.

Nov 25

Archiva vs Nexus

 

En su día nos instalamos un repositorio propio para nuestros jar, de forma que estuvieran accesibles para todos los desarrolladores. Para ello usamos archiva, y ha funcionado más o menos bien con sus cosillas. Hace además las veces de proxy con los repositorios de maven que hay por internet. De esta forma, cada desarrollador únicamente debe configurar maven para que busque los jars en el repositorio de archiva y es este el que se encarga de acceder a internet y buscarlos si es necesario.

No hace mucho descubrí que había otra herramienta similar llamada nexus. Como archiva nos hacía cosas raras de vez en cuando (no traía las cosas de los repositorios de internet, no sé muy bien si por culpa de archiva o de nuestra conexión a internet, que va con proxy autentificado. También dejaba ficheros tmp vacíos en el repositorio de vez en cuando). Así que hoy me he decidido a instalar nexus y probar.

La instalación sencilla, un zip que te bajas, desempaquetas y tienes los scripts necesarios de windows, linux, solaris… para instalar nexus como servicio y arrancarlo y pararlo. Eso sí, hay dos versiones, la gratis con menos posibilidades de autentificación/seguridad, y la de pago que tiene de todo. La gratis en principio tiene lo necesario: gestión de usuarios y permisos propia, funciones de proxy y repositorios propios.

La interface web mucho mejor que la de archiva. Bastante más bonita y agradable. Rápidamente me puse en ella a configurar nuestros repositorios, tanto los propios, como los repositorios que son proxy de los estándar de internet (que ya vienen configurados los de maven central, apache y codehaus).

Y vamos a las cosas que me han gustado y que me han decidido a intentar el cambio en serio:

  1. Es más estricto que archiva con los SNAPSHOTS y las releases. Archiva permite subir y bajar jars snapshots y no snapshots de repositorios snapshots y no snapshots indistintamente. Somos los desarrolladores los que tenemos que tener cuidado de dónde subimos los jar. Nexus es más estricto, si intentamos subir un jar no snapshot a un repositorio que hemos marcado como snapshot, protesta. Y al revés también.
  2. Permite programar tareas de mantenimiento periódicas y entre ellas, la que veo más útil en nuestro caso: permite que se limpien automáticamente las versiones snapshots más antiguas o indicar cuántos snapshots quieres como máximo por cada jar. En un entorno de desarrollo como el nuestro en el que Hudson genera y sube muchos snapshots gigantes todas las noches, una limpieza periódica se hace imprescindible.
  3. Cuando configuras un repositorio como proxy de uno externo, tienes más visibilidad de si tiene o no conexión con el repositorio externo, si se ha bajado algo de él y qué se ha bajado.

Para ser justos, estoy comparando una versión antigua de archiva, que instalé hace mucho, con la última de nexus. Es posible que las versiones más modernas de archiva hayan mejorado o permitan hacer estas cosas que digo que hace nexus.

Nov 20

Sobre constructores, atributos y herencias.

 

Un pequeño "bug" con el que me he tropezado el otro día. Supón una clase padre abstracta en la que desde el constructor se llama al método abstracto.

public abstract ClasePadre {
   public ClasePadre() {
      …
      inicializa();
      …
   }

   public abstract void inicializa() {
   }
}

Ahora imagina que hacemos una clase hija, mal hecha, tal que así

public class ClaseHija extends ClasePadre {
   private UnAtributo atributo = null;

   @Override
   public void inicializa() {
         …
         atributo = new UnAtributo();
         …
      }
   }
}

Simplemente hemos sobreescrito el método inicializa() que nos obliga el padre y lo aprovechamos para inicializar un atributo que inicialmente es null. A partir de aquí, nuestro código se fia de que ese atributo esté inicializado. Pues bien, está mal. Veamos el orden de construcción cuando hacemos new ClaseHija()

  1. Primero java llama al constructor del padre. Este llama a inicializar() y se crea el atributo de la clase hija.
  2. Luego java asigna a los atributos de la clase hija los valores definidos al declararlos, o sea, pone atributo a null.
  3. Finalmente java llama al constructor de la clase hija.

El punto 2 es el que nos da los problemas, resulta que en el punto 1 se inicializa atributo dándole un valor y en el paso 2 se vuelve a poner a null. ¡¡ El atributo queda sin inicializar a pesar de que le hemos hecho un new !!. Nos costó un buen rato dilucidar por qué algo de lo que se hacía el new, un rato después era null.

Pues bien, esto nos ha pasado, y nos ha pasado por pasar de las métricas. Hay una que dice ConstructorCallOverridableMethod, en la que salta un error si un constructor llama a un método que no es final, es decir, que las clases hijas podrían sobreescribir y hacer que la clase padre no quedara bien inicializada. Esto no es exactamente así en este ejemplo, pero está claro que no es buena idea que un constructor llama a métodos que se pueda o, como en este ejemplo, se deban sobreescribir.

Nov 15

Efecto del crackeo del sitio

 

Como comenté hace unos días, me habían crackeado el sitio y habían metido spam. Google me sacó de los buscadores durante unos días hasta que solucioné el problema. Desde entonces vigilo el sitio y, toco madera, de momento no ha vuelto a suceder. De todas formas, ahí va el efecto en las visitas al desaparecer de google. El gráfico corresponde al foro, donde el efecto es más drástico, ya que apenas hay enlaces exteriores a post del foro y casi todas las visitas provienen de los buscadores.

efecto en las visitas al desaparecer del buscador google

Nov 13

Problemilla con el compilador de java 6

 

Hace unos meses nos decidimos a pasarnos de java 5 a java 6. Tras hacer las pruebas correspondientes y ver que no había problemas en los sistemas en curso, correo a todo el mundo que se instalaran java 6.

Todo ha ido sin problemas durantes estos meses hasta que me vienen con una consulta. Hay un proyecto que tarda mucho en compilar en algunas máquinas y en otras no. Pruebo en mi PC y soy de los desafortunados. El tiempo de compilación normal de ese proyecto que suele ser unos 3 minutos, se pone alrededor de los 15 minutos.

Me pongo a investigar y veo que los PC donde compila rápido son los que todavía no se han actualizado a java 6 y siguen con java 5. Mirando en google y en la página de SUN, encuentro este bug. En ese bug se comenta que cuando el classpath de compilado es muy largo (habla de 56 jars en distintos directorios), el compilador tarda mucho más de la cuenta. Con un classpath menos grande, compila rápido. En java 5 eso no pasa, aunque el classpath sea largo, compila rápido.

Así que en esa página nos hemos registrado y hemos votado para que resuelvan el bug. Si alguien más tiene el problema, ya sabe qué hacer: registrarse y votar (en el lado izquierdo).

Nov 12

Engañando al personal

 

Hace un mes aproximadamente llegó el momento de ir a las instalaciones del cliente (no a Kazajstan, sino aquí, en Madrid) para actualizar la versión de software de un sistema que está todavía en garantía. En esa versión se habían corregido una serie de incidencias que el cliente había encontrado.

El plan era ir a instalar y probar nosotros la nueva versión durante una semana. Luego, otras dos semanas probando con el cliente para verificar el correcto funcionamiento de la nueva versión y el cierre oficial de las incidencias. Así que antes de todo eso hicimos una reunión a la que se me convocó junto a otras diez o doce personas. En esa reunión se planificaron los trabajos a realizar durante esas tres semanas en las instalaciones del cliente. Y al final de la reunión todos tenían que ir allí a instalar o probar varios días … menos yo. Fui el único de la reunión al que no le tocó ninguna tarea allí. Eso sí, en la reunión me pidieron que estuviera localizable esas tres semanas e incluso hablaron de ponerme un móvil, de forma que pudieran llamarme si hubiese cualquier problema.

Al salir de la reunión me dio por pensar en todo esto: que se me llame a esa reunión, que no me hagan desplazarme, pero que quieren que esté localizable… y llegué a la conclusión de que los tengo totalmente engañados: "Todos están totalmente convencidos de que soy imprescindible, pero nadie sabe muy bien para qué".

Espero que no se desengañen y me echen…..

Nov 10

Al final, ni Scrum ni Kanban

 

Empezamos antes de verano a intentar hacer Scrum, pero el tema se fue relajando, principalmente debido a que estabamos en fases finales de proyecto y no se podía planificar a una semana vista qué incidencias se iban a encontrar durante las pruebas ni cuánto se iba a tardar en resolverlas. Entonces pensé que quizás en estas fases es mejor pasarse a algo como Kanban, pero quizás por pereza mía no llegamos a formalizarlo.

¿Y en qué ha quedado el tema entonces?

Pues básicamente tenemos la lista de tareas en curso de nuestro grupo. No lo hacemos con un tablero de post-it estilo Scrum o Kanban, sino que inicialmente era un pequeño documento de word con la lista. Todos los días nos reunimos unos minutos y comentamos estas tareas, cuáles están acabadas, su estado de avance, qué problemas hay con ellas y añadimos, si alguien puede abordarlas, más. Como digo, inicialmente era un word que todos los días imprimíamos y luego yo modificaba con lo que se había hablado en la reunión. Este word al final se ha cambiado por una herramienta web de tareas: taskfreak. muy sencilla y cómoda de usar que nos permite tener nuestra lista de tareas en curso siempre actualizada y accesible a todos.

¿Pegas?

Pues los jefes de proyecto no participan demasiado. Ellos nos van poniendo tareas/incidencias en redmine, por correo o de palabra. Yo las aparco y las ordeno en función de la insistencia del jefe de proyecto en cada tarea y de las fechas de hitos. Luego las voy metiendo en nuestra lista de tareas en curso según se van terminando las existentes. Con este mecanismo, nos falta todo eso que pregonan las metodologías ágiles de realimentación frecuente, no ya del cliente, sino del jefe de proyecto.

¿Ventajas?

Las de la reunion diaria. Todos tenemos más claro qué vamos a hacer ese día, somos conscientes y ayudamos al otro cuando tiene problemas y yo, como resposable del grupo, estoy viendo que las cosas se hacen más rápido y con menos errores.

Seguramente cosas como Scrum son maravillosas si se llevan bien y tienen muchísimas más ventajas, pero aunque no se consiga el 100% de sus beneficios, simplemente aplicando algunas de sus reglas (reunión diaria en este caso y lista de tareas priorizada, aunque sea por mí), se obtiene una mejora importante frente a no hacer nada, el cada uno a su bola, las tareas sin priorizar y cada uno elige la que le apetece en ese momento.

Esto me recuerda la famosa regla del 80-20. Quizás con el 20% de las prácticas de Scrum se consigue el 80% de los beneficios. Posiblemente sea exagerado, pero con lo poquito que hacemos he notado una mejora importante en nuestra forma de trabajo.

Mi siguiente reto, una vez establecida la constumbre de la reunión diaria que ya hacemos cómodamente, es elegir alguna otra de las prácticas de Scrum y tratar de implantarla hasta que se convierta en costumbre. Quizás la retrospectiva una o dos veces por semana (no tenemos todavía los sprints, seguimos rematando proyectos).

Nov 08

Buen viaje.

 

Después de dos años de proyecto, el momento ha llegado. Tres camiones en los que montamos nuestros sistemas salieron el martes pasado a las instalaciones del cliente …. ¡¡ en Kazajstán !!. Este sábado de madrugada salieron en avión tres compañeros mios (uno de mi grupo) para pasar pruebas allí con el cliente, durante tres semanas.

La fecha prevista de entrega del proyecto era en Julio/Agosto, pero claro, siempre hay retrasos. Y en este caso, el retraso tiene unas consencuencas curiosas: La previsión de tiempo para esta semana a la zona a la que van es de nieve y temperaturas máximas de -5ºC (negativos). Las mínimas no me he atrevido a preguntarlas. Eso sí, me han entrado unas pequeñas dudas. A esas temperaturas… ¿arrancan siquiera los ordenadores? ¿Funcionan los aire acondicionados (para dar calor, por supuesto)?. No, si cuando el cliente decía que el proyecto debía estar en Julio/Agosto, por algo era. Y lo han admitido a principios de Noviembre porque ¡¡ todavía no hace demasiado frio !!.

La empresa ha comprado ropa de abrigo a la gente que va: anoraks, botas, guantes, camisetas, mallas y calzoncillos térmicos de esos hasta el tobillo. Eso sí, pregunté que cuántos calzoncillos para tres semanas y me dijeron que sólo uno. Pero… ¿uno para cada uno o uno para todos?. No, uno para cada uno, pero tendremos que darle la vuelta de vez en cuando.

En fin, menos mal que los que han ido son gente joven, aventurera y dentro de lo que cabe van voluntarios (menos uno, que le han pillado de mala manera) y con ganas de ver aquello. En tres o cuatro semanas veremos lo que cuentan a la vuelta.