Jan 31

Debugger remoto en java con Eclipse

Bueno, es un tema muy sabido, yo también sabía que existía hace tiempo y mucha gente lo usa para depurar la parte del servidor en sus aplicaciones web. Yo, como desarrollo aplicaciones de escritorio, nunca me había preocupado por el tema.

Sin embargo, sí me ha salido la necesidad. Nuestras aplicaciones de escritorio como tales son realmente sólo interface de usuario, mucho java Swing sobre PCs con Windows. Pero esa, aunque es la parte más labiorosa y la que más líneas de código lleva y la que es más difícil de hacer bien, es lo que la mayoría de la gente considera la parte "tonta" de la aplicación. La parte "de verdad" de la aplicación es una ejecutable java que hace de servidor, que corre en una estación de trabajo Sun que ni siquiera tiene monitor ni teclado. El código de ese ejecutable se desarrolla y prueba por supuesto, en PCs con pantalla y teclado y eclipse. El software se instala y arranca en esas estaciones sun a base de "telnet" desde los PCs. Y por ello es muy difícil de depurar en el "entorno de producción".

Normalmente no es necesaria esa depuración. El ejecutable java que hace de servidor suele salir lo bastante bien del PC como para tener cierta garantía de que funciona bien. Y si hay algún problema, no suele haber problemas en arrancar el servidor con eclipse en el PC y depurarlo ahí de una forma normal. Pero no siempre es posible y, de hecho, tenemos un problema últimamente que requiere depuración en el entorno real, así que me he metido con lo de la depuración remota con eclipse.

El tema es bastante sencillo. Por un lado, basta con arrancar el programa que queremos probar con las siguientes opciones:

-Xdebug -Xrunjdwp:transport=dt_socket,address=1044,server=y,suspend=n

donde básicamente le estamos indicando con -Xdebug que debe admitir una conexión remota para debug y con -Xrunjdwp:transport los parámetros para esa conexión, así como que no debe esperar la conexión del debugger (suspend=n).

Luego, en eclipse, con el proyecto y los fuentes del programa a depurar montados, basta abrir la configuración de debugger (Run -> Debug Configuration) y crear una configuración de Remote Java Application para ese proyecto indicando los parámetros de conexión y el ordenador en que corre el ejecutable.

Por supuesto, aunque es una tontería, en la Chuwiki he puesto los detalles de la depuración remota con eclipse. Y hasta he puesto fotos, yo, que soy vago para capturar pantallas.

Jan 29

Porcentaje de rebote o abandonos

 

Una estadística bastante habitual en las estadísticas de los sitios web es el porcentaje de rebote o abandono. Esta estadística mide el número de visitas que según entran en nuestro sitio, se van. Es decir, miran sólo una página y rápidamente se van a otro sitio. Algunas estadísticas consideran abandono si el visitante se va antes de un tiempo corto, pero no si está un rato leyendo y luego se va. Otras símplemente consideran un abandono si sólo se visita una página. Un porcentaje de abandonos , en principio, es mala cosa, quiere decir que al visitante le ha bastado un vistazo a la página para ver que no es lo que quiere. Un porcentaje de abandonos del 15-20% es muy bueno, del 35% es normal y del 85-90% es un problema.

Hay un par de excepciones a esto. Los blogs, por ejemplo, suelen tener un porcentaje alto, puesto que los visitantes habituales suelen ir a ver el último post, al que entran a través de su "reader" y una vez leído, se van. Otra posible excepción son páginas donde toda la información buscada está en esa página, estilo wikipedia o de tutoriales. Buscas un artículo con google o a través de un enlace, lo lees y te vas.

En muchos sitios te cuentan "en etéreo" como mejorar este porcentaje. Vienen a decir algo así como "Haz la página más atractiva para que a los visitantes le entren las ganas de navegar por el sitio web" o "cambia con frecuencia el diseño y contenido para ver si mejorsa la estadísticas".

Buscando encontré este post en ONGManía en el que dan unos consejos claros y bastante lógicos:

  • Poner enlaces internos en los artículos. Si no los hay, difícilmente el visitante va a ver otras páginas.
  • Usar etiquetas claras y sorprendentes en los enlaces. Que el visitante sepa a dónde va a ir o que le pique la curiosidad al ver el texto. Recuerdo en el blog de Toupeiro los botones a la derecha que dicen "no me pulses" o "este botón te amargará la vida". Es imposible no pulsarlos.
  • Dice que poner una galería de imágenes. Eso no lo entiendo muy bien, quizás es que a mí lo de las fotos no me van.
  • Destacar las páginas más vistas, ya que si son las más vistas, por algo será. Seguramente son las que más interés tienen para los visitantes. Parecido a lo que hacen los blogs con el "post más vistado".
  • Posibilidad de añadir comentarios sin necesidad de registro. Si el visitante puede comentar y no necesita registrarse, hay más posibilidades de que lo haga. Eso retiene al visitante un poco más en el sitio.

Y luego, en otro post de SnobSolutions:

  • El contenido importante o de interés debe situarse a la vista según se entra, sin necesidad de tocar las barras de scroll.
  • Evitar páginas sobrecargadas con publicidad y cosas que no tienen que ver con el contenido.
  • Contenido claro, destacando con negritas o tipos de fuente el tema del artículo, de forma que con un vistazo el visitante sepa si le interesa o no.
  • Ser específico y detallado en el contenido. Cosas muy generales no suelen interesar.
  • Zonas de descanso para los ojos, que la página no agote visualmente al visitante.
  • Poner un buscador en la parte superior. Si el visitante no encuentra a primera vista lo que quiere, quizás lo use.

En fin, cosillas a tener en cuenta, sobre todo yo, que ando por el preocupante 80% de abandonos. ¿Por dónde andas tú?

 

Jan 28

Más de Sonar

Comenté ayer que acababa de instalar Sonar para la medición de métricas en nuestros proyectos. Pues bien, hoy he estado intentando hacer una instalación en serio y me he encontrado con varias pegas.

Lo he instalado en 3 ordenadores. En dos de ellos me ha dado un error curioso al arrancarlo. Busca en la instalación de java un fichero bin/server/jvm.dll. Pues sólo en uno de los ordenadores lo hay. En los otros dos, lo que tengo es un bin/client/jvm.dll. Así que sin ganas de ponerme a investigar sobre la instalación de java, la solución rápida: copie el directorio client con el nombre de server en el mismo sitio y el mismo contenido. Con eso parece que se le engaña para que arranque.

En la documentación de Sonar comenta que viene con la base de datos derby db embebida, pero que es recomendable usar una base de datos más seria. Pues nada, vamos con mysql, que lo tengo instalado. Entro en mysql, creo una base de datos para sonar, voy al fichero de configuración de sonar, quito derby y pongo mysql (esa parte viene muy bien, porque la cadena de conexión de mysql viene comentada y sólo hay que descomentarla y cometar la de derby, además, el driver de mysql en java viene con Sonar, así que ni siquiera hay que poner el jar con el conector en ningún sitio). Más adelante, en el mismo fichero, viene el nombre y usuario para acceso. Y aquí viene otra pega más. Hay que configurar el dialecto de la base de datos, pero en la documentación de Sonar no pone nada de eso. Así que arranco Sonar, abro el navegador, le doy al botón de crear las tablas, empieza a crear las tablas y acaba fallando. Búsqueda del error en google y en el mismo fichero, más adelante hay que indicarle al hibernate de Sonar el dialecto de la base de datos. Dos propiedades más, una con el dialecto mysql y la otra con la clase que sabe de ese dialecto. Eso sí, hay que volver a fijarse porque la clase con el dialecto es propia de Sonar, y no la de hibernate (otro ensayo y error y van dos, en ambos casos con borrado previo de la base de datos, que se había creado a medias).

Listo todo lo referente al servidor. Viene ahora ejecutar el plugin de maven en un proyecto maven para empezar a meter datos.

Mi primera prueba con la base de datos derby funcionó a la primera, así que sin mirar más, le dí al comando. Error. No encuentra la base de datos. Me pongo a buscar por google y resulta que el plugin de maven inserta directamente en la base de datos, por lo que necesita todos los parámetros de conexión. La configuración necesaria para maven viene en la documentación de sonar, así que culpa mía por no haberla leído.  Pongo todo eso, arranco de nuevo…. y otro error. Esta vez porque no conoce el dialecto de la base de datos. La documentación NO pone nada del tema. Así que me lo invento. En el trozo de xml de configuración meto dos tags para el dialecto, exactamente con los mismos nombres que el fichero de configuración del servidor y los mismos valores. Estupendo, ya va.

Me pongo con varios proyectos, poco a poco, y voy consiguiendo los resultados. Pero me salen dos pegas:

  • En algunos proyectos se nos han colado acentos y eñes en los nombres de variables y métodos. Java lo admite. Sonar no. Salta una excepción y falla todo el proceso. Por más que jugué con los encoding, no hubo manera. Al final quité los acentos, pero digo yo que lo suyo es que metiera ese fallo en las métricas en vez de saltar la excepción.
  • En otros proyectos uso una extension wagon-ftp para el deploy. Pues bien, los wagon son incompatibles con los Sonar. El Sonar entra en una llamada recursiva a sí mismo y da una excepción de StackOverflowError. En fin, habrá que buscarle arreglo.

Mañana me toca otro rato de pelea, ya que el plugin de maven no se conforma sólo con insertar directamente en base de datos, sino que accede al servidor Sonar a través de http también para algo y me está fallando esa conexión, supongo que por timeout, o por el proxy corporativo o vete tú a saber por qué.

Hay que reconocer que la herramienta es muy vistosa y que permite ver el estado del proyecto de un vistazo. Pero la instalación y la documentación deja bastante que desear, sobre todo teniendo en cuenta que sólo son cuatro cosas lo que deberían haber puesto, ya que no es una instalación compleja.

Jan 27

Métricas en Java: Sonar

Esta mañana he pasado casi toda la mañana en una reunión de esas de llorar. Se pretendía establecer un plan de acción para solucionar un problema y al final se ha quedado en un "pobrecitos de nosotros…", "cuántos problemas tenemos…", "qué malo es el cliente…", "qué pocos somos para hacer el trabajo…", "qué poco tiempo tenemos …",….

Así que al terminar la reunión, me fuí a comer y me pasé la tarde totalmente desmotivado para el trabajo. Me puse a "internetear" en busca de cosas interesantes y encontré Sonar.

Sonar es una herramienta para la medición de métricas del código java (pmd, javancss, findbugs, … todo junto), pero aporta un par de cosas que me han parecido interesantes.

En primer lugar, al arrancar Sonar, se arranca un servidor web. Las métricas de nuestros proyectos estarán accesibles en el navegador vía web. Bien, de momento nada del otro mundo.

La parte interesante es que las métricas se generan con un plugin de maven y ese plugin busca al servidor web para añadirle el proyecto (si es la primera vez que lo compilamos con el plugin) o para actualizarle las métricas. Esto no deja de ser una pequeña maravilla, puesto que se puede ejecutar el plugin en nuestros compilados nocturnos, de forma que siempre tendremos en el servidor web de Sonar las métricas actualizadas al día. Es más, Sonar guarda las estadísticas de cómo evolucionan las métricas, así que con el tiempo tendremos un gráfico que indica si cada vez hay más o menos violaciones de métricas en el proyecto.

La segunda cosa que me ha resultado interesante es la forma de presentar los resultados. Aparte de las obligadas tablas con valores, se presentan con bloques de colores por proyectos, paquetes y clases. Me explico, hay una vista en la que salen los proyectos como bloques de colores, cada bloque del tamaño proporcional al tamaño del proyecto. El color es rojo si el proyecto tiene muchas violaciones de métricas y va tirando a verde según esté mejor. Pinchando el cuadro de un proyecto, se cambia la vista a los paquetes en ese proyecto, nuevamente con rectángulos de distintos tamaños y colores. Pinchando en uno de esos paquetes, aparecen las clases con el mismo tipo de presentación visual.

Esta forma de presentación es realmente interesante si se pretenden arreglar las métricas de un proyecto que esté mal. Con ella se puede navegar rápidamente e identificar los proyectos, paquetes y clases más conflictivos, centrándose primero en ellos.

Y ya puestos, también tiene una nube de tags en el que cada tag es una de las clases del proyecto. Los tags más gordos son las clases más horribles "métricamente" hablando. Así que incluso es mucho más sencillo identificar de un sólo vistazo cual es la primera clase que deberíamos arreglar de todos los proyectos que tenemos. Por supuesto, te presenta el código fuente de la clase indicando en qué puntos hay violaciones de métricas y cuales.

En este enlace tienes explicadas las distintas pantallas de Sonar y puedes ver los cuadraditos y nubes de tags que menciono.

Actualmente metemos el plugin pmd en maven de forma que si fallan las métricas, falla el compilado. Es la forma de garantizar que la gente codifica siguiendo las métricas desde el principio. Sin embargo, tenemos mucho código con métricas horribles, ya que nunca nos habíamos preocupado en serio de ello. Sonar me va a permitir identificar los peores trozos de código e ir arreglándolos poco a poco.

En fin, Sonar es una herramienta que intentaré ver cómo integro en los proyectos con Hudson (creo que hay plugin de Sonar para Hudson), que me dará entreteniento unos días y si quieren que trabaje en algo serio, que no me metan en reuniones desmoralizantes.

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.

Jan 24

Mega herramientas vs Algo de imaginación

En un proyecto más o menos grande y serio, con clientes serios, con mucha burocracia y papeleo, suele ser un requisito indispensable en la gestión del proyecto que haya trazabilidad de todo con todo. Es decir, que de un acta de reunión con el cliente podamos consultar en cualquier momento en qué tareas ha derivado, cómo se ha resuelto cada una de esas tareas, si ha dado lugar a requisitos nuevos del proyecto. A su vez, de cada requisito debemos poder consultar en cada momento qué trozos del código garantizan su cumplimiento, qué pruebas del protocolo de pruebas permiten verificarlo, qué personas han tocado el código, si ha habido errores y cuales han sido …  y así hasta aburrir con todos los detalles.

En este tipo de proyectos, si se quiere cumplir con todo esto, lo habitual es lanzarse a mega herramientas, estilo la suite de rational o alguna otra similar. Pero estas herramientas tienen grandes inconvenientes.

En primer lugar, suelen ser licencias muy caras, por lo que tienden a racanearse o a no comprarse todas las herramientas de la suite. Son mega-herramientas que no son cómodas de utilizar y requieren bastante aprendizaje, por lo que tampoco se dan a conocer a todo el equipo de desarrollo. Si se compra, suelen comprarse licencias sólo para los jefazos del proyecto (¿cómo vamos a gastarnos 10000€ o más en un currito?). Por ello, o se pone a una o dos personas permanentemente ocupadas con la herramienta, enterándose de qué pasa en el proyecto y actualizando, o al final se queda toda la información desfasada.

¿Y cual es la solución a esto?

Evidentemente, una herramienta gratuita que nos permita gestionar las tareas y errores vía web no nos puede dar toda la funcionalidad completa de una de estas mega herramientas, pero con un poco de imaginación podemos cubrir el expediente de una forma efectiva.

Pongamos un herramienta gratuita y sencilla de usar estilo redmine o trac, con interface web y por tanto accesible por todos desde el navegador. Estas herramientas están pensadas para poner las distintas versiones o hitos, asociarles las tareas a realizar y los errores y llevar bien el control de cuánto hemos avanzado y cuánto nos queda. Por supuesto, no tiene nada que ver con casos de prueba, requisitos, reuniones … ¿ o sí ?

Echémosle un poco de imaginación y en nuestro proyecto vamos a crear una tareas "imaginativas". Redmine, por ejemplo, nos permite definir qué tipos de tareas tenemos, además de "tarea" y "error". Pongamos tareas estilo "reunión", "requisito", "caso de prueba", etc.

En una tarea reunión símplemente escribimos un resumen de la reunión y adjuntamos el fichero con el acta de la reunión (un doc, pdf o lo que sea). De esa reunión saldrán tareas a realizar. Pues las añadimos y las relacionamos con la tarea "reunión". También podemos meter nuestras tareas "requisito" y asociarlas con lo que queramos (reuniones o tareas normales). Igualmente, podemos crear nuestras tareas "caso de prueba" y asociarlas las tareas normales, a las tarea "requisito", etc. Podemos incluso hacer subproyectos separados para cada tipo de tarea. Nuestro PROYECTO puede tener subproyectos REUNIONES, REQUISITOS, PRUEBAS, DESARROLLO, de forma que según el perfil del "currito/jefe", se le den accesos a unas u a otras. Así, por ejemplo, un desarrollador trabaja en el subproyecto DESARROLLO de forma normal a como se hace en una de estas herramientas, con sus hitos, tareas y errores, pero tiene acceso inmediato, quizás de sólo lectura, a los requisitos que debe cumplir a los protocolos de pruebas que debe pasar su código. Y si los jefes son malos (que casi siempre lo son), no tendría ni siquiera acceso de lectura al de REUNIONES, para que no ve

¿La ventaja de todo esto?. Al ser fácilmente accesible por todo el mundo, es fácilmente modificable y se puede tener permanentemente actualizado con un mínimo de disciplina, cada uno actualizando lo que le corresponde.

¿La pega?. Estas herramientas no están pensadas para esto, así que no admiten de una forma fácil y rápida sacar informes adecuados o grandes listados. Sí se puede consultar para una tarea concreta, sea del tipo que sea, las otras tareas relacionadas, siguiendo los enlaces. Así, de un requisito concreto, podemos ver qué tareas se han realizado para cumplirlo, qué prueba comprueba dicho requisito o de qué reunión ha venido. Pero no se puede sacar un listado que nos relacione directamente todos los requisitos con sus pruebas asociadas. De todas formas, lo importante es que está todo relacionado en la base de datos de redmine y haciendo un pequeño esfuerzo adicional, bien con phpmyadmin como comenté hace unos días, o bien haciéndose una herramienta a posta, podemos sacar los informes que queramos.

En fin, no sé si en la práctica todo esto es realizable o si es realmente eficiente. Lo que sí sé es que no se suele cumplir toda la trazabilidad que se debe cumplir, precisamente por lo caro de las herramientas, escasas licencias y falta de gente para meter los datos en ellas día a día. Suele ser mejor algo incompleto pero bien hecho, que algo completo totalmente mal hecho.

Jan 23

Maravilloso código

Es increible, pero cierto. Hoy un compañero mío, revisando código, se ha encontrado algo como esto

public byte[] getBytes (int valor) {
   byte [] a = new byte[1];
   switch (valor) {
      case 0:
         a[0]=(byte)0;
         break;
      case 1:
         a[0]=(byte)1;
         break;
      case 2:
         a[0]=(byte)2;
         break;
      ….
      case 15:
         a[0]=(byte)15;
         break;
     default:
         a[0] = (byte)0;
   }
   return a;
}

Menos mal que sólo eran 16 valores. ¿Al menos se la habrá ocurrido usar el copy-paste?

Jan 17

Aprende punteros como si estuvieras en primero

Veo en el blog de Rubén de la Fuente este video para aprender punteros para "tontos". Realmente curiosa la idea.

 

Jan 16

Actualización del foro SMF

Hace tiempo mi foro de java SMF me avisó de que había una actualización disponible. Tenía la 1.1.5 y estaba disponible al 1.1.6. Le dí a actualizar (lo hace automáticamente), pero me falló porque tenía ficheros modificados por el plugin pretty urls. Así que me dio pereza la actualización: tendría que desinstalar el plugin, actualizar y volver a instalar el plugin, quizás peleándome con él o sin seguridad de que funcionara con la nueva versión de SMF.

No mucho después la versión oficial de SMF volvió a actualizarse. Se ve que la 1.1.6 tenía algún agujero de seguridad importante y sacaron la 1.1.7. Pero esta vez, en mi foro salía el aviso de que estaba la nueva versión, pero no me daba la posibilidad de actualizarme automáticamente, puesto que yo tenía un retraso de dos versiones. Así que si ya tenía pereza antes, no te digo ahora. Y por supuesto, lo dejé correr.

Hace un par de días me decidí a actualizarme. Así que con más miedo que vergüenza (miedo a pasarme un par de horas tontas, si no toda la tarde,  hasta conseguir hacerlo funcionar de nuevo) me puse a ello.

Desinstalé el plugin de pretty url desde el mismo panel de administración de SMF.

Me bajé desde la página de SMF el upgrade a la versión 1.1.7, pero al intentar subirlo a mi foro SMF a través del panel de administración no me lo reconocía como un módulo válido.

En la misma página de SMF, encontré abajo un fichero webinstall y la recomendación de usarlo para los upgrades automáticos. Lo puse, me hizo registrarme en la página de SMF…. y no funcionó, me dijo que había un error y que hiciera la instalación manual.

Ya desesperadito y viendo que efectivamente, iba a pasarme toda la tarde con el puñetero foro, rebuscando, rebuscando, encontré en el panel de administración un enlace para actualizarme a la 1.1.6 automáticamente. Como había desinstalado el pretty url, le di al enlace y funcionó a la primera. A partir de ahí, el enlace a la actualización de la 1.1.7 apareció y funcionó también perfectamente. Finalmente, reinstalé el plugin pretty url…. ¡¡ y también funcionó !!. Mi foro actualizado correctamente y sin demasiados problemas.

Es lo que tiene la informática. Lo normal es que cualquier cosa que parece una chorrada no lo sea, te líes y eches varias horas a lo tonto en ello. Otras veces, las menos, funciona todo a la primera (o casi).