domingo, 31 de octubre de 2010

Selección de noticias de la semana 30/10/2010

Como cada semana, aquí está la selección de noticias y posts interesantes:

eAdministración:
Ciencia:
Programación:
Aplicaciones y Gadgets:
Tecnología y Actualidad:
Humor y Curiosidades:

jueves, 28 de octubre de 2010

Mini-Robot que resuelve laberintos a una velocidad sorprendente

Lo acabo de ver en microsiervos y es impresionante.
Este robot del tamaño de un ratón explora un laberinto, hasta el minuto 3:55 en el cuál ya se lo sabe y hace una demostración llegando desde la salida hasta la meta en apenas 7 segundos.

Uso de Alice como herramienta para enseñar a programar

Como ya he comentado alguna vez en el blog, además de trabajar como tecnólogo para la Informática de Comunidad de Madrid, comparto esta actividad con la docencia en la Universidad Carlos III de Madrid.
Hace varios años comencé a impartir la asignatura de Programación que se da en primer curso (antes de Ingeniería Informática, ahora del Grado en Informática).
Durante estos años hemos probado varias técnicas para ayudar a los alumnos a que comprendiesen mejor los conceptos de la Programación Orientada a Objetos. Sin duda, una de las herramientas que considero que más han aportado a la docencia en la asignatura es el uso de la herramienta Alice de la Universidad de Carnegie Mellon.
En la asignatura se enseña a programar en el lenguaje Java. El tema es que cuando empezamos con la asignatura, el alumno no sabe nada sobre programación. Las clases de teoría y las de prácticas empiezan simultáneamente, por lo que la primera semana de clase los alumnos se presentan en el áula de prácticas sin tener todavía ninguna noción sobre programación.
¿Qué puede hacer un alumno en clase de prácticas de programación si todavía no sabe programar?
Aquí es donde entra en juego Alice (la idea se le ocurrió a mi compañero Angel). Alice es una herramienta para enseñar los conceptos de la programación orientada a objetos de manera visual. Para ello, en Alice se trabaja en un entorno en tres dimensiones en el cuál se van colocando objetos (por ejemplo un conejo, una caja, etc.). Una vez colocados los objetos, se les hace interaccionar creando una especie de "corto de película".
Lo bueno de Alice es que está pensado para comenzar a usarlo sin leer ni una línea de documentación sobre la herramienta. Para ello, nada más arrancar el programa, se pueden ejecutar una serie de tutoriales en los cuáles, de manera muy intuitiva, se enseña a utilizar el entorno.
En la asignatura de Programación utilizamos Alice como herramienta para la primera práctica en la que hacen los alumnos. Primero les solicitamos una serie de ejercicios guiados, y posteriormente (algunos años sí y otros no, dependiendo del tiempo que tengan para hacer la práctica) se les dice que creen su propio corto de temática libre.
Si estáis pensando en aprender programación orientada a objetos, es posible que os interese el enunciado de la práctica que hemos puesto este año a los alumnos, se puede acceder a través de este enlace público.
Os pongo aquí también algunos pantallazos con partes del enunciado de la práctica (gracias a mis compañeros por prepararlo con mimo):



martes, 26 de octubre de 2010

Algunos datos curiosos sobre el Universo



Aunque uno no sabe mucho de cosmología, muchas veces la curiosidad le lleva a hacerse preguntas acerca del Universo (forma, edad, tamaño, etc.) ¿Tú también te has planteado este tipo de preguntas?. Buscando las respuestas a algunas de las que yo me he planteado, he encontrado datos que me han parecido sorprendentes (se asemejaban poco a lo que me podía imaginar). Perdonarme porque soy profano en la materia, si alguno de los datos no es del todo correcto por favor hacérmelo saber. Ahí van algunas preguntas:

El Universo
  • ¿Cuál es la edad del Universo? ¿Se sabe cuánto tiempo hace del "Big Bang"?
    • Se calcula que la "edad" del universo, es decir, el tiempo que hace desde el "Big Bang", es de aproximadamente 13.700 millones de años.
  • ¿El Universo es infinito? ¿Cuál es su tamaño total?
    • Actualmente no se sabe a ciencia cierta si el universo es finito o infinito. Lo que sí que sabemos es que la teoría del Big Bang implica que el universo observable es finito. De el hecho de que existe un tiempo finito de expansión (la "edad" del universo), y de que la luz viaja a una velocidad determinada, se deriva que todo lo que esté más allá de cierta distancia no lo podemos ver (básicamente porque en el tiempo de vida del universo, a la luz no le habría dado tiempo a llegar a nosotros desde tan lejos). En otras palabras, según se explica aquí: "En el modelo del Big Bang el universo observable es finito por el simple hecho de que la luz procedente de galaxias lo suficientemente alejadas no ha tenido tiempo de alcanzarnos en el tiempo finito de expansión". ¿Y cuál es el tamaño del universo observable? Aproximadamente 78.000 millones de años-luz. Según este artículo: "...el punto de partida de una partícula de luz, un fotón, que llega hasta nosotros después de viajar por 13.700 millones de años, está ahora a una distancia de 78.000 millones de años luz.". Aquí tenéis otro interesante artículo que habla sobre el tema.
    • La paradoja de Olbers dice que si el universo fuese infinito, entonces veríamos todo el cielo repleto de estrellas, no habría espacios oscuros entre ellas (ya que en cada dirección en la que mirásemos, tarde o temprano acabaría por haber una estrella). Como bien se muestra en este artículo: "En la década de 1960, el astrónomo estadounidense Edward Harrison llegó al entendimiento y solución actuales de la paradoja de Olbers. Harrison mostró que el cielo es oscuro de noche porque nosotros no vemos las estrellas que están infinitamente lejos. La solución de Harrison depende de que el Universo tenga una edad infinita. Dado que la luz tarda cierto tiempo en alcanzar la Tierra, mirar lejos en el espacio es como mirar en el pasado. Cada línea de visión desde la Tierra no termina en una estrella porque la luz de las estrellas más lejanas que se necesitan para crear la paradoja de Olbers todavía no ha alcanzado la Tierra."
  • ¿Es el Universo plano? 
    • Cuando leí el titular de esta noticia "Ahora sabemos que el Universo es plano", pensé que se refería a que todas las galaxias están situadas más o menos en el mismo plano. Entonces lo que vino a mi mente fue: "¿Y si es plano, por qué al mirar al cielo en cualquier dirección vemos estrellas y galaxias? ¿no deberían entonces situarse todas en una misma línea recta?". Parece ser que cuando los científicos se hacen preguntas sobre la forma del Universo no se refieren a la "forma" en la que podemos pensar los profanos. Leyendo algunos artículos sobre el tema, parece ser que se refieren a conceptos topológicos, que nada tiene que ver con la imagen que nos hacemos nosotros de algo "plano". Cuando escuchamos "plano" tendemos a pensar en un folio o una mesa (es decir, una superficie plana en dos dimensiones). Desde luego que el Universo no es plano en este sentido (en dos dimensiones).
La Vía Láctea: Nuestra Galaxia
  • ¿Cuántas estrellas tiene la Vía Láctea?
  • ¿Cuál es la galaxia más cercana a Vía Láctea?
    • En este artículo se dice: "Hasta hace 7 años habríamos contestado con toda seguridad: La Gran nube de Magallanes, ubicada a 170.000 años luz del centro de nuestra Galaxia. Sin embargo hoy eso ha dejado de ser cierto, hay otras dos galaxias tan cercanas que gran parte de ellas se encuentra dentro de la Vía Láctea, se trata de las galaxias enanas Sagitario, a unos 60 mil años luz del centro, descubierta en 1994 y Can Mayor, descubierta recientememnte y que se encuentra a 42.000 años luz del centro Galactico."
    • En este otro artículo leo: "La Vía Láctea tiene dos pequeñas galaxias orbitandose cercanamente, las cuales son visibles desde el hemisferio sureste. Éstas son llamadas la Nube Magallánica Mayor y la Nube Magallánica Menor. La galaxia grande más cercana es la Galaxia Andrómeda. Es una galaxia en espiral como la Vía Láctea pero es 4 veces mas densa y está a 2 millones de años luz de distancia."
  • Comparada con otras Galaxias, ¿la Vía Láctea es grande o pequeña?
    • Leo aquí: "La Via Láctea és una galaxia grande, espiral y puede tener unos 100.000 millones de estrellas, entre ellas, el Sol. En total mide unos 100.000 años luz de diámetro y tiene una masa de más de dos billones de veces la del Sol."
El Sol
  • ¿Cuánto tarda la luz del Sol en llegar a la Tierra?
    • La luz del Sol tarda algo más de 8 minutos en llegar a la Tierra.
  • ¿Cuál es la estrella más cercana al Sol? ¿cuánto tardaríamos en llegar a ella si viajásemos a la máxima velocidad (la velocidad de la luz)?
  • ¿Cuánto tiempo le queda de vida al Sol?
    • Parece ser que al sol le quedan 5.000 millones de años de vida en el estado en el que lo conocemos.
  • ¿Se conocen planetas fuera de nuestro sistema solar?
    • Hasta el día de hoy, según la Wikipedia se conocen 416 sistemas planetarios que contienen un total de 494 cuerpos planetarios.
¿Se parecen estas respuestas que podrías imaginarte antes de conocerlos? 
¿Conoces algún dato más que te haya resultado especialmente curioso?

    sábado, 23 de octubre de 2010

    ¿Debería existir un curso para aprender a buscar en Google?


    Hace unos días comentaba en el séptimo consejo de esta entrada que la capacidad para buscar (bien) en Google podría hacer que mucha gente encontrase mucho más rápido lo que busca, y por tanto aumentar mucho su productividad. Muchas veces me planteo la posibilidad de que la gente acuda a cursos para aprender a buscar.
    Hoy leyendo WWWhatsnew he encontrado este interesante post titulado "How To Use Google Search more Effectively".
    En él se habla de herramientas como:
    • El uso de la búsqueda avanzada de Google para limitar más la búsqueda, excluir términos, etc.
    • El uso de Google Scholar (que personalmente no conocía) para buscar literatura escolar. La herramienta permite buscar por los distintos metadatos del libro (autores, referencias, revista, etc.).
    • Utilizar las utilidades y trucos que ofrece Google para ayudar a la búsqueda (probar a buscar "definir delfín" en Google). 
    • Uso de búsquedas sociales, o Google Image Search
    • El uso de Atajos (Shortcuts).
    Me parece un post muy interesante del que he aprendido algunos trucos. Sin embargo, creo que la mayor parte de las veces, sería suficiente con que la gente aprendiese a utilizar la búsqueda simple en Google. Con esto me refiero a que supiese escoger los términos determinantes para su búsqueda.
    Personalmente suelo utilizar un término genérico que identifique el tema que estoy buscando, y añado un término muy concreto que sólo pueda contener el documento concreto que estoy buscando, dentro de todos los de su tema.
    ¿Qué trucos utilizas tú para buscar?
    ¿Deberían existir cursos para aprender a buscar en Google?
    ¿Te apuntarías a uno de estos cursos?


    viernes, 22 de octubre de 2010

    Selección de noticias de la semana 22/10/2010

    Como cada semana, aquí está la selección de noticias y posts interesantes:
    eAdministración:
    Ciencia:
    Tecnología:
    Internet:
    Programación:

    Humor: Fauna y especies de las reuniones de trabajo, y sus frases típicas

    Estaba charlando con dos compañeros, y hemos empezado a hablar en tono jocoso de los típicos roles que suele adoptar la gente en las reuniones de trabajo. La verdad es que después de muchos años de reuniones, aprende uno a identificar a qué especie pertenece cada uno de un vistazo (o bien por la vestimenta, por su situación física dentro de la sala o por la primera frase que sueltan).
    Aquí van algunos de las "especies" que se me ocurren, si te sientes identificado por favor no te ofendas que es viernes ;-)
    • El enmarronador
      • Descripción: También conocido con el término anglosajón "brown dispatcher", esta especie se caracteriza por salir de las reuniones habiendo asignado trabajo a todo el mundo (menos a ellos). Suelen llevar vestimenta elegante, y acostumbran a situarse en la posición más céntrica de la mesa de reuniones.
      • Frases típicas: Se caracteriza por frases que comienzan así:
        •  "Habría que...", "Deberíamos...", "Se tiene que hacer esto...": Después de decir estas frases, suelen recorrer con la mirada al resto de participantes buscando una víctima de la especie "masoca" o "inocente".
        • "¿Entonces quién...?": Si la búsqueda de víctimas inicial no ha surtido efecto, suele recurrir a este tipo de frases más directas.
        • "¿Te encargas tú de esto?": Si los dos intentos anteriores han sido fallidos, recurre a esta frase, mirando fijamente a los ojos de su víctima.
    • El escurridizo
      • Descripción: También conocido con el término anglosajón "brown eluder", de caracteriza por mantenerse callado durante toda la reunión, y no mirarte nunca directamente a los ojos. Suele llevar vestimenta discreta, y situarse en el rincón más oscuro de la sala. 
      • Frases típicas: Sólo responde si alguien le pregunta directamente, y suele hablar en primera persona del plural ("nosotros"), nunca singular ("yo"). También utiliza muchas frases impersonales (Ver el uso del "se" impersonal"). En caso de sentirse acorralado, suele hacer alusión a la cantidad de trabajo que tiene. Utiliza frases del estilo de las siguientes:
        • "Esa no es nuestra competencia"
        • "A nosotros no se nos ha informado de eso"
        • "En este momento estamos hasta arriba de trabajo"
        • "Ya se verá"
        • También suele empezar algunas frases con "En principio..." para introducir una fuente de incertidumbre en su respuesta que pueda permitirle escapar.
    • El masoca:
      • Descripción: También conocido con el término anglosajón "brown sink", suele hacer suyos los problemas de los demás. Se trata de una especie muy trabajadora, que no suele adquirir mucho protagonismo en las reuniones, sólo participa cuando un ejemplar de tipo "enmarronador" lanza alguna pregunta al aire. Al contrario que la especie "escurridizo", suele mirar directamente a los ojos del que pregunta.
      • Frases típicas: Se caracteriza por decir frases que le auto-involucran en el trabajo a realizar. Algunas frases en las que se auto-involucra:
        • "Yo me encargo"
        • "Eso se hace en dos días". 
        • "Si queréis le voy echando un vistazo yo y luego os cuento"
        • Existe una subespecie del masoca llamada "el inocente", que se caracteriza por frases que son origen para que otros ejemplares les acaben involucrando. En ocasiones pronuncian frases similares a las del ejemplar "enmarronador", pero dichas por estos individuos se acaban volviendo en su contra, por ejemplo "¿Quién hace el acta?", "¿Quién podría..", "Habría que...". Suelen recibir respuestas de ejemplares de tipo "enmarronador" del estilo "¿Te encargas tú?".
        • Otra subespecie del masoca es conocida como "el apaciguador". Suele meterse en el medio de conflictos que no le atañen para tratar de poner paz, y acaba asumiendo el trabajo de otros por este motivo.
    • El sabelotodo:
      • Descripción: También conocido con el término anglosajón "self-confidence", se caracteriza por tratar de aparentar que sabe más que todos los que están en la reunión (incluso más que los expertos en su ámbito). Suele sentarse en las zonas centrales de la sala de reuniones, y acostumbra a intervenir sin pedir su turno multitud de veces durante la reunión.
      • Frases típicas: Se caracteriza por utilizar palabras complejas (a veces anglicismos) que ha oído en otro contexto e intenta colar aunque no encajen. Ejemplos de algunas palabras que suele utilizar:
        • Idiosincrasia
        • Sinergias
        • Coyuntura
        • Pipeline
        • ROI
    • El disperso:
      • Descripción: Se caracteriza por ser una fuente de ruido continuo en las reuniones. No aporta nada válido, pero interviene multitud de veces tratando de hablar de "su libro", cosas que no tienen que ver con el tema que se está tratando. Les gusta ser el punto de atención, por lo que suelen situarse en posiciones estratégicas dentro de la sala de reuniones. Suelen ir bien vestidos, a veces con colores llamativos.
      • Frases típicas: Entre sus frases comunes, las más típicas son los "Poyaques" y los "Apropos":
        • "Poyaque te pones podíamos hacer esto y esto otro..."
        • "Apropo-sito del tema, tengo un cuñado que bla bla bla".
    • El sindicalista:
      • Descripción: No se dispone de mucha información sobre esta especie, ya que en raras ocasiones se ha vislumbrado algún ejemplar en las reuniones de trabajo. Se comportan de manera similar a la especie "escurridizo", pero suelen identificarse por utilizar una vestimenta más informal (normalmente prendas de pana).  
      • Frases típicas: Las comunes de la especie "escurridizo", y alguna adicional del estilo:
        • "No me pagan para eso"
    Lamentablemente, yo me identifico sobre todo con la especie "masoca". ¿Cuál es tu rol? ¿ves que falte alguno típico? ¿tienes alguna frase típica de las reuniones?.

    martes, 19 de octubre de 2010

    10 Consejos para la resolución de problemas técnicos inexplicables

    En ocasiones, compañeros de trabajo y otros conocidos acuden a mi con problemas técnicos difíciles (de programación, sistemas, etc.) incomprensibles y/o aparentemente inexplicables, tratando de que les eche una mano en la búsqueda de una solución. Supongo que me he ganado fama de "gurú técnico" a base de encontrar soluciones inesperadas a problemas extraños (qué engañados les tengo a todos :-)
    Seguro que si trabajáis con temas técnicos, habéis escuchado multitud de veces frases como estas:
    • No lo entiendo! Pero si ayer funcionaba y no he tocado nada!
    • Lo he probado todo y no soy capaz de saber por qué falla!
    • Esto es imposible! Pero si el programa nunca debería pasar por ahí!
    • Si en mi máquina funciona y todo está igual en esta otra, ¿por qué ahí no funciona?

    He hecho un ejercicio de reflexión para tratar de analizar las reglas que inconscientemente aplico a la hora de tratar de resolver algún problema, esas reglas que sólo se aprenden a lo largo de años enfrentándote a este tipo de situaciones. Quiero compartir con vosotros algunos consejos/conclusiones que he sacado de esta reflexión, espero que os sirvan:

    Consejo 1: Simplifica el problema

    Cuando te enfrentas a un problema complejo suele haber muchas variables que pueden influir en él. En ese caso, hay que tratar de reducir el problema a su mínima expresión, para poder tratarlo sin tantas variables que introducen ruido al asunto. Muchas veces, cuando estás tratando de reducir el problema a uno más simple, das con la solución.
    • Ejemplo: Imagina que tienes una aplicación que estás programando, que consta de 1000 archivos y más de 100.000 líneas de código. Tienes un problema con un archivo de la aplicación, concretamente en un método de una clase que no se comporta como debería. En ese caso, lo ideal es aislar ese método y tratar de probarlo independientemente del resto de la aplicación. Si es posible, además, quitar todas las líneas del método que no sean relevantes para el problema, hasta dejarlo reducido a su mínima expresión. Como digo, muchas veces aplicando este procedimiento de simplificación te das cuenta de la causa del problema.
    Consejo 2: Se metódico en las pruebas
    Lo primero que hay que hacer a la hora de enfrentarse un problema, aún a riesgo de parecer un autómata, es SER MUY METÓDICO. El más claro ejemplo de esto es que si para comprobar que algo funciona estás realizando las pruebas de una determinada manera, las realices siempre de la misma forma y en el mismo orden (aunque creas que lo que estás cambiando no puede afectar al resultado!!!).
    • Ejemplo: Si estás realizando las pruebas en una máquina, hazlas siempre en la misma (aunque haya otra exáctamente igual). El cambio de máquina muchas veces introduce ruido en las pruebas (siempre suele haber problemas con idiomas distintos, encodings - UTF8, etc.).
    • Ejemplo: Si para las pruebas estás lanzando dos scripts en un derminado orden, aunque los scripts sean independientes (teóricamente el orden no sea relevante), lánzalos siempre en el mismo orden.
    Consejo 3: No mates moscas a cañonazos, primero Reflexiona!
    Muchas veces cuando uno está enfrentándose a un problema incomprensible, tiene la tentación de "empezar de cero". Yo soy de la opinión de que esta tiene que ser la última solución, antes hay que tratar de descartar todas las otras vías. Volviendo a empezar de cero, corres el riesgo de tardar más de lo necesario, o lo que es peor, trabajar durante días rehaciendo algo para luego encontrarte con el mismo problema.
    • Ejemplo: En nuestro día a día trabajamos a diario con las herramientas Maven, JDK1.6, Eclipse, etc. Tengo un compañero (con cariño eh!) que cada vez que no le funciona algo se lanza a reinstalar Windows, y todas las herramientas necesarias. Suele tardar un par de días en reinstalar todo, y algunas veces, cuando ha terminado, vuelve a probar lo que fallaba y... sigue fallando!. Muchas veces, si se hubiese parado a reflexionar sobre el problema en lugar de "tirar por la tangente", habría ahorrado mucho tiempo y esfuerzo.
    Consejo 4: La máquina tiene la presunción de inocencia
    Lo que he aprendido a lo largo de muchos años es que lo más probable frente a un error es que el culpable sea el ser humano, no la máquina. Lamentablemente en estos casos la presunción de inocencia es para la máquina, y no para ti :-(
    • Ejemplo: Mucha gente, cuando algo no funciona, culpa a problemas en el hardware (las típicas frases "Eso es que la memoria está corrupta" o "A lo mejor el disco duro tiene clusters defectuosos"). La mayoría de las veces suele ser problema del programa, no del hardware.
    • Ejemplo: Siempre me acuerdo de un antiguo compañero de trabajo que a menudo, cuando encontraba algún problema en Java aparentemente inexplicable, culpaba a la Java Virtual Machine. "Tiene que ser un error de la JVM!!" - decía. Siempre se confirmó que eran errores suyos en el código.
    Consejo 5: A veces es más fácil hallar la solución que la causa
    En ocasiones la gente se ofusca tratando de buscar la causa a un problema. Pasan días tratando de encontrar el por qué... cuando a veces existe un "atajo" (los ingleses lo llaman workaround) que te hace solucionar el problema, aunque no encuentres qué era lo que lo producía. Hay ocasiones en las que hay que saber rendirse ante el enemigo, y siendo prácticos, dejar atrás nuestra necesidad innata de conocer el por qué de las cosas. Ojo porque tampoco hay que abusar de esto, puede convertirse en un arma de doble filo (cada uno tiene que saber poner límites prácticos a su curiosidad, sobre todo si te pagan por producir ;-)
    • Ejemplo: Un conocido tenía un problema con un programa en Java que se suponía que era compatible con la JDK1.3 y superiores. El tipo llevaba semanas persiguiendo el problema ejecutando el software con la JDK1.4, y no era capaz de encontrar la causa. Después de varios intentos fallidos de conocer la causa, le pregunté si había probado a ejecutarlo con la JDK1.3. Su respuesta fue que la 1.4 era compatible con versiones anteriores, por tanto si funcionaba con la 1.3 debería de hacerlo con la 1.4. "Muy bien" - le dije - "¿pero lo has probado?". Insistí en ello, y al probarlo con la 1.3 el error dejó de producirse. Nos quedamos con ganas de saber qué es lo que producía el error... pero solucionamos el problema!
    • Ejemplo: La semana pasada un tipo me llamó porque estaba detectando errores de intentos fallidos en la conexión a SQL Server en un servidor. Después de darle muchas vueltas, probé a detener el servicio "Microsoft Reporting Services", y el error dejó de producirse. El tipo dijo: "¿Pero por qué ese servicio trata de conectarse a SQL Server? No lo entiendo", a lo cuál le respondí con otra pregunta: "¿Usas el servicio de Reporting Services o lo vas a usar en un futuro?". "No" - respondió. "Entonces me da igual saber por qué trata de conectarse, dejamos el servicio apagado y problema solucionado".
    Consejo 6: Si ayer funcionaba y hoy no, algo ha cambiado

    Cuando alguien viene a mi con la típica frase "Pero si ayer funcionaba y no ha cambiado nada!" siempre le respondo lo mismo: "Como mínimo ha cambiado algo: La fecha". Si estás en la típica situación en la que te fuiste el día anterior dejando algo funcionando y hoy ya no funciona, intenta pensar verdaderamente qué puede haber cambiado, y echa para atrás todo lo que haya cambiado para volver a la situación en la que funcionaba. Después vuelve a hacer los cambios probando uno a uno, para ver cuál es el que introduce el problema.
    • Ejemplo: El día 19 de Septiembre estuve mejorando el Crawler para el BOCM del proyecto www.booletin.es. Para identificar hasta dónde llega la fecha de un boletín en una cadena de texto (Por ej: "19 de Septiembre de 2010. Bla bla bla"), estaba buscando "20" en la cadena de texto, y así identificaba dónde se encontraba el año en la fecha, y sabía por dónde cortar. Todo funcionaba bien con los boletines desde el 1 de Septiembre hasta el 19. Sin embargo, al día siguiente (20 de Septiembre) volví a probar el programa y fallaba. "Pero si no he cambiado nada!"- pensé. Sin embargo sí que había cambiado algo, el día del mes. El algoritmo funcionaba con todos los días del mes menos el día 20, ya que cortaba la cadena "20 de Septiembre de 2010. Bla bla bla" justo después del primer "20", y no después del año como pretendía.
    Consejo 7: Pregúntale (bien) a Google
    No creo que exagere si afirmo que el 90% de los problemas extraños se resuelven sabiendo buscar correctamente en Google. Cuando nos enfrentamos a un problema, lo más probable es que ya le haya pasado antes a alguien. Internet está lleno de foros en los que la gente plantea sus dudas/problemas, y en los que hay multitud de respuestas a ellos.Cuando me enfrento con un problema y ando perdido, acudo a Google y le pregunto. Es muy importante saber buscar bien, para encontrar lo que buscas. Para buscar algo, trato de buscar palabras distintivas de lo que ando buscando (es decir, palabras que debería de contener el documento que estoy buscando, y no deberían de contenerlas otros documentos que no busco).
    • Ejemplo: La semana pasada un compañero de trabajo experto en tecnología J2EE (un arquitecto de los buenos) estaba buscando la solución a un problema con la herramienta Maven. Llevaba más de dos horas buscando en google y no encontraba nada. Me pidió que le echase una mano, y en cinco minutos (buscando los términos correctos en google) dimos con la solución.
    A veces pienso que deberían darse cursos sobre cómo utilizar correctamente los buscadores, sería el tiempo mejor invertido por muchos (como dicen los economistas, tendría un ROI muy atractivo, se recuperaría la inversión en cuestión de días y el resto de la vida sería todo ganancias :-).

    Consejo 8: Si no hay más remedio, baja de nivel de abstracción
    Cuando todo lo demás falla y el problema parece inexplicable, debemos plantearnos que a lo mejor estamos buscando en el lugar inadecuado. Siempre que hablamos de tecnología, nos movemos en un determinado nivel de abstracción (Ej: Hardware < BIOS < Sistema Operativo < JVM < Programa Java) . En ocasiones el problema que estamos buscando no está en el nivel de abstracción en el que nos movemos, sino en un nivel inferior (por ej. a veces buscamos un error en el programa... y el error está en el Sistema Operativo). Tenemos que bajar a buscarlo ahí.
    • Ejemplo: Esta semana he tenido un problema en un servidor: Al ejecutar un programa en este servidor se quedaba colgado. Sin embargo al ejecutarlo en mi máquina local (con la misma configuración) el programa funcionaba sin problemas. Finalmente, el problema no estaba en el programa, ni siquiera en el Sistema Operativo... pero tampoco en el Hardware!. El problema estaba en un nivel de abstracción que se encontraba escondido entre el Sistema Operativo y el Hardware. Resulta que se trataba de un servidor virtual, que se estaba ejecutando como una máquina virtual de VMWare. VMWare estaba teniendo problemas con el acceso a la cabina de discos, y esto estaba causando el fallo en la ejecución.
    Consejo 9: Muchos ojos ven más que dos
    Cuando estés atascado, pregunta!. Aunque pienses que las personas a las que puedes consultar no tengan la respuesta a tu problema, quizás te puedan aportar alguna pista (o a lo mejor tienen la respuesta y tú no lo sabes). Como poco, el contárselo a alguien te servirá también para aclarar tus propias ideas.
    • Ejemplo: Esta anécdota es de mis favoritas. Hace muchos años hice una aplicación en Java que tenía que realizar un cálculo para cada hora de cada día del año. El programa empezaba con las 00:00h del 1 de Enero, e iba incrementando hora a hora hasta que acababa a las 23:00h del 31 de Diciembre. Al ejecutar el programa e ir incrementando hora a hora, llegaba un momento en el que se realizaba el cálculo dos veces para la misma hora. Yo no entendía qué podía estar pasando, ya que el programa funcionaba bien, pero en un momento concreto del tiempo (el 29 de Octubre de 2000) se duplicaba la hora. Después de dos días persiguiendo el fallo, me levanté muy enfadado de la silla y grité en alto "¿Pero qué demonios pasa el 29 de Octubre?". Para mi sorpresa, un compañero me miró y me dijo muy tranquilo: "ese día es el cambio de hora". Claro! No había caído en la cuenta de que el 29 de Octubre de ese año era el día en que se retrasaba la hora, por lo que a las 3h de la madrugada volvían a ser las 2h... y de ahí el hecho de que se duplicase. Mi compañero había dado en dos segundos con la solución al problema que yo llevaba buscando días.
    Consejo 10: A veces la mejor solución a un problema es irse a dormir
    Muchas veces nos obcecamos en resolver un problema, alargando la jornada hasta las tantas de la madrugada buscando la solución. Después de muchos años he aprendido que a veces la mejor solución es descansar. Cuando te levantas por la mañana, tienes la mente fresca y lúcida, y en ocasiones se te ocurren vías de solución que por la noche no habías imaginado. En otras ocasiones, mientras duermes, el cerebro sigue dándole vueltas al asunto y se aclaran las ideas: ¿a quién no le ha pasado el irse a dormir con un problema en la cabeza y levantarse con la solución?:
    • Ejemplo: De pequeño solía jugar mucho al ajedrez. Con 13 años acostumbraba a resolver problemas de ajedrez complejos, buscando soluciones imaginativas a los problemas que se planteaban en libros y revistas. En una ocasión estuve varias horas pensando sobre un problema de "mate en 4" sin encontrar solución. Mi sorpresa fue cuándo me fui a acostar, y por la mañana me desperté habiendo encontrado la solución al problema (la cabeza había estado trabajando solita por la noche!).

    viernes, 15 de octubre de 2010

    Mapa del mundo con iniciativas de Open Data

    No lo conocía, y recoge varias iniciativas (en España sólo el proyecto Aporta y Zaragoza... echo en falta algunas como la del Gobierno Vasco).
    Podéis acceder al mapa interactivo aquí.

    jueves, 14 de octubre de 2010

    Diagrama de datos abiertos enlazados

    A través de la web de la web de la ePSIPlatform he llegado a este impresionante gráfico que muestra de un vistazo una maraña de datos abiertos enlazados. En la versión coloreada se distinguen bien los que son del gobierno (los de la izquierda, en color azul verdoso):

    (Images of Linked Open Data cloud diagrams courtesy Richard Cyganiak and Anja Jentzsch, http://lod-cloud.net/ Creative Commons BY SA license)

    Podéis acceder a versiones del gráfico en diversos formatos en la web oficial.
    Este gráfico me ha recordado el vídeo de Tim Berners-Lee hablando de Linked Data en el TED que tanto me impactó. Ya lo publiqué en su día en el blog, pero para quien no lo vió, aquí os lo dejo:

    Lista de los blogs y feeds que sigo

    Estaba leyendo algunas noticias de tecnología, y he pensado que os podría resultar interesante la lista de sitios que acostumbro a leer diariamente. Personalmente uso google reader como lector de feeds RSS, ya que hasta ahora todos los sitios que suelo consultar publican también en este formato.
    Cada semana añado alguno, o elimino aquellos que no publican o dejan de atraer mi atención, así que es una lista viva. Aquí está la lista de algunos feeds, separados por categoría. ¿Cuál es la tuya? ¿echas en falta alguno que recomendarías? Ayudame a completarla:

    Administración Pública:
    Tecnología (En Español):
    Ciencia y Tecnología (En Inglés):
    Ciencia:
    Programación:
    Periódicos (Tecnología):

    domingo, 10 de octubre de 2010

    Las 10 y 10 del 10/10/2010

    Como bien dicen en Microsiervos.

    Selección de noticias de la semana 10/10/2010

    Aquí está la selección de noticias y posts interesantes de la semana:

    Administración Electrónica:
    Ciencia:
    Tecnología / Internet:
    Programación:
    Humor: