Mar 29

Actualización de wordpress

Anteayer visité mi propio blog y tuve un pequeño disgusto. Por más que le daba, parecía que no se cargaba la hoja de estilo CSS. El blog salía sin columnas, sin estilos, fuentes, colores ni nada. Texto plano y simple. Con el navegador le dí a ver el código fuente de la página y otro disgusto más grande. En la página faltaba toda la sección de <head>, que es donde se hace referencia al fichero de estilo CSS. En su lugar había una línea larga y kilométrica de enlaces de span con estilo hidden para que no fueran visibles. Abro el administrador de wordpress, voy al editor de temas y efectivamente, el fichero header.php había sido reemplazado por esa línea de span. ¡¡ Me habían crakeado el blog !!

Afortunadamente hago backups todos los meses, así que fuí al último backup con la intención de recuperar ese fichero header.php. Pues bien, hace un mes también estaba crackeado, pero al menos habían respetado el tag <head>, símplemente habían añadido todos esos enlaces/span. Viendo el blog con ese header.php el blog se veía correctamente, pero al ver el código fuente, todos esos enlaces/span estaban ahí.

Así que decidí actualizar la versión de wordpress, puesto que la que tenía puesta una un poco antigua. La última actualización había sido un desastre y por eso no lo había actualizado. Así que me armé de valor y me decidí a intentarlo otra vez. Esta vez por necesidad más que por estar a la última. Me voy al administrador del wordpress y desactivo todos los plugins. Luego al "fantásico" de mi hosting y actualizo a la últma versión disponible desde ahí. Volvió a pasar el desastre de la otra vez, todos los acentos y eñes cambiados por "gurruños" variados. Buscando por internet, encuentro esta solución para los acentos de wordpress. La verdad es que es muy tonta, basta buscar el fichero wp-config.php y hay una línea que pone define(‘DB_CHARSET’, ‘utf8′). Basta cambiar el utf8 por latin1, así define(‘DB_CHARSET’,'latin1′). Con eso se arregló el tema de acentos.

El otro problema que tenía con que se me descolocaban los videos de youtube lo solucioné cambiando el tema antiguo por este, el que estais viendo ahora. Creo que voy a dejarme de florituras y no lo modificaré, lo dejaré como está. En su día estuve jugando con el tema anterior, pero era más por aprender y jugar con CSS que por conseguir un tema vistoso.

Finalmente, otro problema es que dentro del administrador de wordpress me daba un error de php. Decía que no se podía cambiar el "header" de la página porque wp-config.php ya había enviado información. Afortunadamente ese problema me resulta conocido y el problema eran tres o cuatro líneas en blanco que había al final del fichero wp-config.php. Me bastó con borrarlas.

Así que arreglado, wordpress actualizado y tema nuevo.

Mar 28

Del código a la gestión

Bueno, sigo con mi rollo y con mi pena.

Al tener demasiada gente a la que "llevar" (entre comillas porque es solo de boquilla, oficialmente no llevo a nadie, extraoficialmente sí, y en la realidad a nadie salvo a cuatro gatos que me hace caso), cada vez me voy dando más cuenta de que no puedo meterme demasiado al nivel del código, porque entonces no abarco lo que debo y soy un cuello de botella para los que realmente trabajan. Tampoco puedo meterme en un nivel detallado de diseño hasta llegar al nivel de clases, por el mismo motivo. Cada vez me doy más cuenta que tengo que quedarme en un nivel alto de diseño: módulos, relaciones entre ellos, ejecutables, etc.

Pero hay una pena. A ese nivel de diseño el trabajo es aburrido y repetitivo. En un nuevo proyecto o herramienta a realizar piensas un par de días en la arquitectura, pero no hay tantas arquitecturas a elegir ni opciones. Luego es un trabajo aburrido y repetitivo de dibujar con UML o de otra forma una y otra vez lo mismo, las mismas arquitecturas, los mismos patrones de diseño de alto nivel, símplemente cambiando nombres de módulos.

Así que el trabajo acaba siendo más de gestión. Una vez que has perdido tu tiempo haciendo el mismo dibujito de la otra vez, o uno muy similar, no te queda más remedio que dedicarte a ver cómo avanza el tema, cómo se va programando, probar de vez en cuando o revisar aleatoriamente trozos de código para ver si más o menos va siguiendo la estructura general.

Mar 25

Indexado en google del foro SMF

Después de darme cuenta del pequeño desastre del foro SMF con google, y de no conseguir que funcionara el plugin de seo4smf, decidí hacerme mi propio sitemap.xml para google. Había hecho un programita en java que generaba ese fichero xml simplemente con un bucle de 2 a 1059 (el número de post en el foro en ese momento). Subí el fichero al foro, lo dí de alta en google…. y aparentemente NO funcionó. Después de un par de semanas, ninguno de los post del foro estaba indexado.

Estuve pensando cual podía ser el motivo. Hay páginas del foro que sí están indexadas en google, como la de mensajes recientes, los perfiles de los usuarios, la página principal del foro… pero NO los post. A pesar de que los parámetros que se pasan a la página php del foro son igual de feos en todos los casos, no veía por qué los post no se indexaban. Al final y por probar, decidí que podía ser cosa del punto decimal. Los post llevan un parámetro tal que así "topic=1046.0", con un decimal punto cero. Se me ocurrió que google podía interpretar ese decimal como que esa variable y, por tanto, la página, es muy variable en función de ese valor que no parece un índice, sino un valor arbitrario.

Así que hice mis experimentos. Primero comprobé que se puede acceder al post sin poner ese decimal, con algo como "topic=1046". Funciona bien. Así que hice el sitemap.xml sin ese decimal…. y funcionó. Una semana después de subir el nuevo sitemap.xml, google empezó a indexar los post y un par de semanas después, ya estaban casi todos.

Ahora la tarea que me queda es hacer un pequeño script de php que me genere ese sitema.xmp, o bien un sitemap.php que devuelva una página xml con el formato del sitemap. De esta forma, cuando google visite el sitemap, lo tendrá actualizado.

Me quedan algunas dudas. Aparentemente tengo una cosa que no le gusta a a google, que es contenido duplicado. Se accede al mismo post a través de "topic=1046.0" que a través de "topic=1046". Sin embargo, al no estar indexado el primero, quizás no importe, ya que no tiene con quien comparar el segundo. Es cuestión ahora de ver si en las búsquedas de google empiezan a aparecer los post por algún sitio y de revisar mis estadísticas, a ver si se empieza a entrar directamente en los post desde google.

Mar 19

Eficacia vs Elegancia

Estos días atrás, en varias reuniones con mi jefa, ha salido varias veces el mismo tema. El problema es que los dos o tres del departamento que tienen fama de saber mucho java, mucha orientación a objetos, mucho de patrones de diseño y de ser los que mejor programan, hacen un código que los compañeros no entienden fácilmente. Y efectivamente es así. El código que hacen esas personas también tiene fama de ser muy dificil de seguir, mantener o modificar por otras personas que no sean ellos mismos.

Hay otros compañeros, sin embargo, que no saben tanto de orientación a objetos o de patrones de diseño, pero su código es más simple y más fácil de entender, pero muchísimo menos reutilizable.

¿Cual es el motivo?. Le he estado dando vueltas y me hace la impresión que es algo similar a lo que comenté en el post anterior de que programar es como escribir.

Quitando a los que comenten faltas de ortografía, hay quien se centra en el problema concreto que tiene y con un código "lineal", con un mínimo de orientación a objetos y un mínimo de patrones de diseño, resuelve eficientemente el problema, de una forma rápida. Ese código funciona bien, se hacen unas pocas clases sencillas, pero grandes y, por ello, es fácil de entender: va todo seguido y no hay que rebuscar entre varias clases, interfaces y polimorfismos variados para ver qué hace. Está todo ahí y se ve. Pero esas clases sólo sirven para eso y no se pueden usar en más sitios. Esto sería el equivalente a escribir en prosa con una prosa eficiente.

Otros, menos prácticos pero con más conocimientos, para resolver el mismo problema, montan toda una estructura de clases e interfaces. Posiblemente el diseño de estas clases es mucho más orientado a objetos y más elegante desde ese punto de vista que en el caso anterior. Algunas de esas clases son lo suficientemente generales como para usarlas en otros sitios. Sin embargo, tardan más en hacer el código y hay menos gente capaz de entenderlo sin leerse previamente un buen manual del diseño del mismo, incluso aunque sean gente con profundos conocimientos de OO y patrones. Esto sería el equivalente a escribir poesía, donde se da especial importancia al cómo se cuentan las cosas.

Llega el tiempo de hacer modificaciones por la misma persona que ha hecho el código. En general, cualquier modificación se hace más rápido en el segundo caso, en el de la orientación a objetos, si hay un buen diseño.  Sin embargo, hay veces que esta modificación cuesta mucho más en este segundo caso. ¿Por qué? Nuevamente por el tema de darle demasiada importancia a la forma. A veces la modificación que se pide se hace fácilmente añadiendo una dependencia de una cosa totalmente extraña a nuestro diseño (un dato que no tiene nada que ver, una clase que es muy especifica del proyecto, etc). Para la primera persona en cuya cabeza está el resolver el problema lo antes posible, añadir esa dependencia no le cuesta nada, la pone y ya está. Sin embargo, para la segunda persona, añadir esa dependencia le supone un trauma de concepto. Se niega a ponerla puesto que ese dato no pega nada ahí y tiene que rehacer el diseño para contemplar esta nueva posibilidad de una forma elegante con el conjunto. Lo que a la primera persona le puede costar diez minutos "ñapear", a la segunda le puede costar un par de días.

Y al final llega la gran cuestión. ¿eficacia o elegancia?. ¿No estará justificado ñapear de vez en cuando para conseguir un código más simple en apariencia o cumplir plazos?. Supongo que como siempre, en el punto medio está la virtud. No hacer ñapas sangrantes, pero tampoco ser demasiado puristas con la orientación a objetos. Y me hace la impresión que esto es lo que ha llevado a los gurus a una de las bases de las metodologías ágiles y a cosas como el TDD. Si nos fijamos, en estas metodologías suelen ser comunes cosas como "resuelve tu problema lo más rápido y de la forma más sencilla posible", no hagas cosas generales "por si en un futuro las usas". Hay que centrarse en y resolver el problema de ahora. El del futuro hay que resolverlo cuando se presente haciendo refactoring si es necesario. El diseño se debe ir haciendo justo antes de programar y sólo para resolver el problema concreto del momento.

Cada vez estoy más convencido de que aprender un lenguaje de programación es fácil, pero aprender a programar puede llevar toda una vida.

Mar 15

Programar es como escribir

Programar es como escribir:

  • Hay quien escribe mal, con faltas de ortografía y no se entiende qué quiere decir.
  • Hay quien no sabe escribir correctamente, pero consigue explicarse.
  • Hay quien redacta y explica a la perfección y…
  • ¡ Hay quien hace poesía !

Mar 12

Empiezo a programar con Word.

Pues bien, lo que me venía temiendo hace tiempo, con esto de las software factories, está empezando a hacerse realidad. Hoy he comenzado a programar con Word. No, con las macros de Word no, sino a escribir con Word.

Ya tenemos gente en la software factory trabajando para nosotros y tenemos que empezar a especificarles lo que queremos. La primera pega es que al no estar con nosotros, ni conocer nuestros sistemas, ni tener siquiera el mismo "contexto", tenemos que empezar a contarles desde cero.

Mi primer documento de word, una "introducción a nuestros sistemas", contando más o menos qué hacen, qué ejecutables corren en ellos y dando algunos conceptos generales para que vayan cogiendo la "palabrería" propia de los mismos.

El segundo documento, otra introducción a una de las funcionalidades concretas del sistema, común en casi todos los sistemas que hacemos, pero con muchas variantes entre ellos. Es una de las primeras cosas que quiero que empiecen a implementar… y ahí empiezan a salir un montón de pegas. Por un lado, al ser algo común a casi todos nuestros sistemas, ya tenemos hechas algunas librerías supuestamente reutilizables y que nos permiten implementar esa funcionalidad en los nuevos sistemas bastante rápido. Sin embargo, al ser una librería que hemos hecho sobre la marcha, tiene muchas "pegas" y "trucos" que nosotros conocemos y que no están documentadas. Así que la primera pega ¿Perdemos el tiempo en arreglar/documentar esa librería para que la utilicen los de la software factory o, por el contrario, la rediseñamos para que nos la empiecen ellos de cero?. En principio es mejor opción la primera, pero también tiene una pega. Tenemos varios sistemas basados en esas librerías, algunos de ellos están ahora en fase de pruebas. No es buen momento (y a este paso nunca lo será) para hacer modificaciones fuertes en una librería común, salvo que hagamos una rama de CVS. La segunda opción parece ahora más atractiva, ya que hacemos el diseño inicial y luego ellos se la guisan, ellos se la comen. La pega es que habrá un fuerte trabajo de depuración/integración, ya que toda librería nueva tiene sus bugs.

Y finalmente, el tercer documento, diseño/especificación de una parte de esa funcionalidad (una parte que tradicionalmente se hacía en Ada y que queremos hacer ahora en java y, por tanto, es nueva a todas luces), procurando no usar conceptos que para cualquiera de los que trabajan conmigo se dan por supuestos, pero que para los de la software factory posiblemente son desconocidos. Si yo hablo del "fistro" del sistema, todos mis compañeros saben qué es, pero los de la software factory pensarán en Chiquito de la Calzada.

En fin, a "word-ear" durante unos días se ha dicho. ¿Desinstalaré el eclipse?

Mar 06

Primer contacto con la software factory

Aunque mis jefes ya llevan tiempo parlamentando con los jefes de la software factory, hoy han venido un par de personas de allí a vernos y he tenido el primer contacto con ellos.

Mi primera impresión ha sido buena. La persona que va a ser responsable del grupo que trabaje con nosotros parece técnicamente buena. Además, tienen CMMI-3, que aunque parezca una certificación más, por lo que he oido va más allá que el resto de las certificaciones que son papel mojado. La certificación CMMI-3 se consigue tras varios meses en el que un auditor te ayuda a establecer todos los procedimientos y una vez que la consigues, te revisan cada cierto tiempo para ver que los sigues cumpliendo y no te duermes en los laureles. Nosotros somos CMMI-0 (cualquier empresa de software, por el mero hecho de existir, es CMMI-1, pero creo que nosotros no llegamos ni a eso), así que estoy seguro que vamos a aprender bastante de ellos en cuanto a procedimientos y formas de organizar las cosas.

Ahora es cuestión de ver qué tal va la cosa. Y sobre todo, qué pasará cuando vayamos integrando en nuestros sistemas los módulos que nos vayan haciendo. No hay tarea más desagradable que depurar y corregir en la integración el código de otros.

Mar 05

El ruso a punto de estar a punto

Hace tiempo comenté que teníamos que traducir nuestra interface gráfica al ruso. Pues bien, está a punto de estar a punto y también está a punto de que vengan los rusos a ver lo que hemos hecho.

La primera etapa, el internacionarlizar las etiquetas de java, con la ayuda de eclipse, ha sido un trabajo fácil, rutinario y algo pesadito. Hemos aprovechado para ponerlo en inglés, así al menos vemos qué etiquetas se quedan sin traducir. Los ficheros de properties con las etiquetas se han pasado a un traductor ruso.

Todavía no tenemos la traducción, pero nos queda un rollo pesado y un par de pegas.

El primer rollo pesado es que cuando el traductor nos traiga los ficheros de propiedades, posiblemente tengamos que buscar y reemplazar todos los caracteres cirílicos por los códigos unicode equivalentes. No he probado si hay alguna pega por dejarlo directamente en cirílico, pero desde luego eclipse protesta si intentas ponerlos directamente. Y eclipse convierte los acentos españoles y eñes a códigos unicode al internacionalizar. ¿quizás un pequeño script en algún lenguaje novedoso para aprender algo?.

En cuanto a las pegas, la primera es que dimos los textos al traductor hace tiempo, pero claro, hemos ido desarrollando cosas en el prototipo. Hay textos que no le hemos entregado. Lo del inglés lo podemos apañar, pero como no venga el traductor a pasarse una tarde con nosotros a rematar detalles antes de la demo, quedarán varios textos sin traducir. Hombre, el google traductor puede ayudar, pero ni puñetera idea de si el texto lo pone bien o no en ruso. Nos tendríamos que limitar a copiar y pegar. Encima, los textos en ruso son muy largos (algo así como las palabras alemanas), por lo que quizás incluso nos toque recolocar botones y rediseñar ventanas.

Y la segunda pega va a ser divertida. Me gustará ver a nuestro jefe haciendo la demo sobre una aplicación en ruso. Apenas la conoce y desde luego, los botones, tooltips y ayudas no le van a ayudar a saber qué botón apretar en cada momento.

La solución que vamos a adoptar es tener dos ordenadores uno al lado del otro, uno con la aplicación en ruso y la otra en inglés.

Por cierto, la siguiente creo que va a ser una traducción al chileno. Espero que sea más fácil

Mar 03

Más de Indra en Gijón

Acabo de leer esta noticia sobre la software factory de Indra en Gijón. Hay un par de cosas que me han llamado la atención

Por un lado, esta frase "La empresa ha elegido la ciudad de Gijón «por sus excelentes cualidades en el ámbito académico…". Bueno, supongo que realmente les da igual la ciudad. Lo importante son ciudades donde tengan universidades en las que coger gente que no tenga muchas más opciones. De esta forma, la rotación será menor y los costes seguramente también.

Pero la que más me ha llamado la atención: "El director general de la empresa se refirió a la «falta de talentos» en el mercado laboral, por la obsesión de los profesionales por las grandes urbes…". Sólo eso me faltaba por oir. Ahora ya si estoy seguro que la gente de las altas esferas viven en su mundo imaginario y no saben nada de la vida real, del día a día. Está clarísimo que todos los que en su día dejamos nuestro hogar y venimos a trabajar a Madrid lo hicimos claramente porque había mucho trabajo en nuestra tierra natal -Gijón, por ejemplo-, pero estabamos obsesionados con irnos a la capital. Y sobre todo, estabamos deseando venir a Madrid para comprarnos un piso baratito, con sólo el 90% de nuestro sueldo hasta pasada la jubilación.