Archivos de » 2010 «

Lunes, diciembre 20th, 2010 | Autor:

El otro día, en el aeropuerto Charles de Gaulle de París, estaba yo tranquilamente esperando a que saliese mi vuelo con Air France, de París a Vigo. Hasta ahí todo normal, durante la espera estaba observando el panel en el que se inda la puerta y el estado en que está, pero según se iba acercando la hora, aquello no cambiaba, no cambiaba… y así asta las 19.35, cuando el avión salía a las 19.40 y veo LAST CALL en rojo… y ala, corriendo como un animal pa no perder el vuelo.. por los pelos, menos mal que había otro chico con el mismo problema allí y al final nos dejaron subir al avión… que si no, en los parises me quedaba. si es que..

Ayer, al volver de ver el partido del depor, casi pasa otro tanto de lo mismo, pero en la renfe, fuimos unos amigos a ver el partido y al volver tuvimos que coger el billete de vuelta, cuando estabamos esperando, todo tenian el coche 1 2 o 3, menos yo, que tenía el 5.  Después de fijarme observo que el billete era del día 19 y no del 18, ala, corriendo para la taquilla para que me lo cambiaran… juer no se llo si esto de los medios transporte non va bien, o soy yo que me pispo del tema..

Categorias: Festa  | Etiquetas: , , , , ,  | Dejar un comentario
Miércoles, noviembre 17th, 2010 | Autor:

Visto en este blog: Manuelpereira, es una cosita que no he parado de releer y de darle la razón al hombre…

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!).
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!).
Miércoles, noviembre 17th, 2010 | Autor:

A continuación mostrare unos 20 tips para ser un buen programador, comprobado con la experiencia mia, compañeros de trabajo y con opiniones de personas relacionadas en el tema.

1. Estudia, estudia y estudia
El estudiar nos permite perfeccionarnos, cuanto mas estudiemos mas oportunidades de programar mejor tendremos, no solamente estoy hablando de universidades, ni tampoco de cursos, hoy por hoy gracias a internet existen infinidad de tutoriales y manuales, sin ir mas lejos el sitio oficial de PHP es realmente muy bueno.

2. Busca antes de preguntar
Esto es un mal común del que quiere aprender a programar, es mas fácil preguntarle a alguien que sepa, pero realmente no tiene que ser así por varias razones, primero por que es algo de muy de vago, luego que cuando alguien nos da la respuesta fácil no aprendemos nada, lo interesante cuando se nos presenta un problema es buscar la solución nosotros mismos, sino damos con la respuesta recién ahí preguntar, este ejercicio realmente es muy beneficio, nos permite preparar nuestra cabeza para solucionar futuros problemas.

3. Busca scripts ya desarrollados
Por lo general podemos encontrar muchas funciones, scripts listos para utilizar, pero lo interesante es estudiarlos, ver como funcionan, de ahí aprendemos si copiamos y pegamos vamos mal.

4. Lee el código fuente libre
Yo muchas veces descargo algunas aplicaciones para ver como están programadas, de verdad que se aprende mucho, a medida que realicemos esta practica cada vez iremos aprendiendo mas, en especial si estas aplicaciones son de uso popular en donde miles de programadores del mundo “meten” mano para mejorarla. Un buen ejemplo de esto es WordPress.

5. No copies y pegues
Es fácil, entramos a google buscamos una función que sirva para lo estamos necesitando y listo. Pero la realidad es que no siempre lo que descargamos es correcto, y si luego tenemos que solucionar un problema lo mas probable es que no tengamos ni idea por donde empezar. Ni hablar del factor aprendizaje cero que esta practica implica.

6. Buscar el momento para programar
Estas sentado delante de tu ordenador, llaman por teléfono, tu compañero de trabajo o familiar te pregunta algo, realmente es lo mas molesto e incomodo que hay, es difícil concentrarse, es preferible hacer algo mas “Light” antes de programar algo mal y después tener que arreglarlo.

7. Ten tu propia Wiki
Esto lo recomiendo muchísimo, es muy sencillo instalar una Wiki en nuestra pc, simplemente podemos descargar el Easyphp y tener en nuestro ordenar un servidor funcional, y mejor aun si quieres hacer la instalación “a mano”. La wiki es interesante para poder almacenar rutinas que usamos frecuentemente, en mi caso suelo guardar validaciones, etc. Una vez que aprendimos a hacer algo y lo tenemos lo mejor posible es interesante tenerlo a mano para no perder tiempo escribiendo lo mismo una y otra vez.

8. Comenta todo lo que sea necesario
Escribir comentarios en el código suele ser bastante molesto y parecer innecesario, pero comentar las cosas importantes nos puede ahorrar mucho tiempo cuando tengamos que retocar el código meses después.

9. Participa en foros/comunidades
Es interesante para interactuar con otras personas que estén en nuestra misma sintonía, muchas veces ayudaremos nosotros y otra vez nos podrán ayudar. En línea general estas comunidades tienen muy buena onda, y la ayuda mutua es lo que abunda, unas líneas de código pueden ser útiles para muchas personas, de ahí que entre todos se puede perfeccionar. Recuerden respetar el punto 2.

10. Habla con otros programadores
Mensajería instantánea, en un café, por teléfono, etc. Es interesante tener amigos que están en lo mismo, no solamente por el tema de la ayuda mutua, estos grupos suelen ser también de ayuda “emocional” del programador, unos chistes, algún comentario puede ser una inyección de energía para continuar con un problema que no podemos resolver.

11. Tiempo libre para otras cosas
Me encanta programar, pero entendi que no es lo unico en la vida, a veces es bueno una salida, una película, realmente es necesario desenchufarnos.

12. Arma tu bunker
Tener un espacio de trabajo acorde con tus gustos es indispensable para programar, un buen sillón que no dañe nuestra columna, un lindo escritorio que nos permita desparramar CDS, libros, etc. También hay que ser organizado, pero siempre a nuestro gusto, es bueno que sea TU espacio y que nadie meta mano, uno a la larga lo termina sintiendo como un refugio.

13. Tu equipo en condiciones
Otro punto importante, una buena computadora, que no tenga problemas, si es necesario un poco mas de RAM, no hace falta tener una supermáquina para programar con PHP pero si algo que no se este colgando cada 2 seg.

14. Usa herramientas gratuitas
Si no podes pagar ciertas herramientas realmente ni te gastes en bajar las versiones piratas, en PHP no se necesita mucho y realmente no vale la pena estar trucando programas.

15. Organiza tu propia biblioteca de scripts
Relacionado con el punto 7. La wiki es muy buena, pero hay que tenerla organizada, sino encontrar algo puede llevarnos mas tiempo que volverlo a escribir.

16. Se agradecido con los que te ayudan
Si alguien te ayuda, por favor al menos di gracias. Recuerda que las personas que te rodean no son tu soporte técnico (Al menos que les pagues). Si alguien se molesta en responder a tus consultas agradécele, para la próxima esa persona seguirá teniendo buena predisposición.

17. Se humilde
Esencial. Siempre hay alguien que sabe más que uno y mas en este “rubro” en donde hay verdaderos cráneos, Yo hace varios años que programo en PHP y sin embargo siempre aprendo algo nuevo, y en parte eso es lo que me gusta de programar, siempre se puede mejorar.

18. Siempre busca perfeccionarte
Relacionado con el punto anterior. Las tecnologías evolucionan y nosotros debemos hacer lo mismo. Una linda practica cuando tenemos un poco de tiempo libre es tratar de optimizar un código nuestro de unos meses anteriores, si aprendimos cosas nuevas de seguro que podemos hacerlo mejor que antes.

19. Intenta ser eficiente y luego inténtalo de nuevo
Que funcione no quiere decir que este bien. También una de las cosas más lindas de programar: Siempre se puede hacer una función mas eficiente, que consuma menos recursos, no hay que conformarse que arroje los resultados que queremos, probablemente lo podemos hacer mejor.

20. Programa primero lo que menos te gusta
Esto es bastante personal, pero por lo general me da buenos resultados. Cuando me siento a programar algo los primeros minutos son de “ambientación” luego tengo un periodo de concentracion digamos maxima, en ese momento las cosas que parecen o son mas complicadas son cuando mas rápido y mejor salen, luego cuando uno esta mas cansado puede dedicarse a las cosas mas sencillas y rutinarias.

Visto en elblogdefasa

Miércoles, noviembre 17th, 2010 | Autor:

Despues de estar buscando varios días he encontrado esta entrada en Applesfera… a ver si me funciona.

En el pasado hemos visto aplicaciones como MacDrive que permiten, a cambio de unos 20 dólares, acceder a nuestros discos con formato HFS+ de Mac en Windows. Su funcionamiento es bastante bueno y yo mismo las utilicé en cierta época pero, ¿y si pudieramos hacer exactamente lo mismo con algo que muchos de nosotros ya tenemos? Ni más ni menos que el disco de instalación de Snow Leopard.

El truco consiste en instalar los drivers de Boot Camp en un Windows aunque este no esté instalado mediante este sistema, o ni tan siquiera en un Mac para empezar, y funciona del siguiente modo:

1. En Windows, introducimos el disco de Snow Leopard y accedemos a la carpeta Boot Camp / Drivers.
2. Ejecutamos el archivo Bootcamp.msi (o Bootcamp64.msi si estamos utilizando una versión de 64 bits de Windows) y seguimos las instrucciones del instalador.
3. Reiniciamos el equipo.
4. En Inicio / Ejecutar, utilizamos msconfig para deshabilitar “Boot Camp” de los elementos que se ejecutan en el arranque.
5. Reiniciamos de nuevo y listo, ya puedes acceder a tus particiones o discos duros externos en HFS+ sin mayor complicación.

Categorias: Apple, Nuevas tecnologías  | Etiquetas: , ,  | Dejar un comentario
Sábado, octubre 30th, 2010 | Autor:

El mercado bursátil londinense está de lo más contento: su sistema basado en Linux ha permitido alcanzar un récord mundial en la velocidad de las comunicaciones, con tiempos de operaciones financieras de tan solo 126 microsegundos.

Esta noticia precede a la migración a un sistema global a Linux durante el cual este sistema operativo de libre distribución reemplazará a la tecnología Microsoft .NET que operaba hasta la fecha en la Bolsa de Londres (London Stock Exchange, LSE). Esta organización había recibido muchas críticas por sus prestaciones, que obligaban a sufrir tiempos de operaciones de varios cientos de microsegundos.

Según ComputerWorld, la velocidad de 126 microsegundos es el doble de rápida que la que se obtiene en otros competidores internacionales com oBATS Europe y Chi-X, dos rivales electrónicos específicos del LSE, y que tienen unas latencias de 250 y 175 microsegundos respectivamente.

Durante los próximos 12 días se procederá con la migración total de los sistemas de la Bolsa de Londres, y si todo va bien el LSE abrirá con Linux como pilar fundamental el próximo 1 de noviembre. Excelentes noticias que demuestran una vez más la potencia de Linux en aplicaciones de misión crítica como estas operaciones financieras a gran escala.

Visto en: muylinux

Categorias: GNU/Linux  | Etiquetas: , , ,  | Dejar un comentario
Jueves, octubre 14th, 2010 | Autor:

Desde que Oracle compró Sun Microsystems se han producido todo tipo de amenazas a los desarrollos que Sun auspiciaba bajo la filosofía OpenSource. El caso más destacado es el de OpenSolaris, que ha desaparecido como proyecto oficial y que ahora ha sido continuado a través de Illumos y de OpenIndiana, pero hay más proyectos en peligro.

Es lo que deben haber pensado los responsables de la creación de LibreOffice, una nueva suite ofimática que toma como base OpenOffice.org pero que se ha creado como un fork de esa suite para continuar el camino de este desarrollo ahora que Oracle podría acabar con el proyecto, al igual que ha hecho con OpenSolaris.

En H-Online nos explican cómo entre las empresas implicadas están BROffice, Google, Novell y Red Hat, pero además esta nueva suite se resguarda bajo el paraguas de una nueva organización europea que gestionará este y otros proyectos relacionados, llamada The Document Foundation.

Muchas otras organizaciones y empresas se han sumado al esfuerzo y han declarado su apoyo a esta iniciativa: la Free Software Foundation, OSI, OASIS, Canonical, credativ, Collabora y la GNOME Foundation han expresado su apoyo a LibreOffice, que se sumará a la existencia de otras alternativas como Go-OO. La mismísima Oracle ha sido invitada a formar parte de ese grupo de apoyos -porque los linuxeros somos muy elegantes y tendemos la mano incluso a los que amenazan la supervivencia de estos proyectos- pero queda por ver si los responsables de Oracle declaran algo al respecto.

En otro artículo relacionado de H-Online han analizado otros aspectos interesantes de esta iniciativa como el tema de las licencias y de quién posee el código de OpenOffice -y de ciertas partes del mismo- así que podéis consultar dicho reportaje para obtener más datos sobre un proyecto que ya está disponible en fase beta con licencia LGPL3 y que se puede descargar para distintas plataformas -por ahora solo en inglés-. Eso sí: no esperéis grandes diferencias con respecto a OpenOffice.org, ya que de momento todo parece ser idéntico a la base sobre la que se sustenta este proyecto.

Visto en: mylinux

Jueves, octubre 14th, 2010 | Autor:

Canonical acaba de presentar la ultima versión de su distribución más conocida de todas, ubuntu. Ya podemos descargar gratuitamente la versión 10.10 de este fantástico Sistema Operativo. Como cada 6 meses canonical nos ofrece una nueva versión de ubuntu con decenas de mejoras tanto gráficas como internas (kernel).

Domingo, septiembre 05th, 2010 | Autor:
La London Oncology Clinic (LOC), con sede en Harley Street, es una entidad privada que combate el cáncer con las técnicas y tratamientos más novedosos. La clínica utiliza lo último en tecnología y funciona con un sistema electrónico completo.
Los pacientes de la LOC generan una gran cantidad de datos complejos derivados de sus tratamientos, incluyendo diagnósticos, estadios de la enfermedad, perfiles demográficos, resultados de análisis de sangre y los regímenes de quimioterapia. Toda esta información se extrae y analiza, dando como resultado un elevado volumen de datos difíciles de gestionar y mucho mayor que la mayoría de las empresas.
Aunque la clínica ofrece atención personalizada, con consultas individuales y tratamientos basados en los planes de investigación y en la evidencia, también necesita operar como negocio. Pero con tantos datos médicos tan complejos, el simple análisis de los mismos se convierte en una labor mucho más complicada.
Steve Rumbles, quien pasó de ejercer la enfermería a convertirse en el director del área IT de la London Oncology Clinic, explica “al principio buscábamos información sobre la gestión básica de cualquier empresa moderna. Con estas soluciones convencionales nuestros datos fueron bien estructurados para su uso operacional, pero no para el análisis. Antes de Pentaho, el análisis se convirtió en una labor muy complicada y extremadamente lenta, probando desde casa con programación Java”.
Domingo, septiembre 05th, 2010 | Autor:
  • eBox Technologies, desarrollador de eBox Platform, el servidor Linux para pymes, ha anunciado que eBox Platform cambiará su nombre por Zentyal. El objetivo de este cambio es reflejar con mayor precisión las características del producto y los servicios basados en él. El cambio será efectivo a partir del 1 de septiembre, con el lanzamiento de la nueva versión 2.0 del software de servidor. Simultáneamente, la empresa eBox Technologies también cambiará su nombre por Zentyal.

“El proyecto eBox Platform ha evolucionado, crecido y, naturalmente, sus objetivos se han transformado desde sus orígenes tras siete años de desarrollo. Con este cambio, queremos asegurar que el producto refleja con mayor precisión lo que ofrece”, afirma Ignacio Correas, director gerente de eBox Technologies. “El nombre actual de eBox Platform sugiere que el software viene integrado en un hardware de servidor, por la palabra ‘Box’. Sin embargo, eBox Platform es puramente software de servidor que viene acompañado de servicios de suscripción basados en la nube”.

La palabra Zentyal fue elegida como el nuevo nombre de eBox Platform, ya que se asemeja mucho al objetivo principal del proyecto: hacer que algo tan esencial como la gestión de redes sea fácil y seguro. Zentyal es la fusión de dos palabras, donde ‘Zen’ representa cualidades como la intuición, la perspicacia y el equilibrio – la facilidad de llevar a cabo tareas a través de la intuición – y ‘Essential’ representa cualidades tales como básico, fundamental y necesario.

Una alternativa libre a Windows Small Business Server

Zentyal nace con el objetivo de garantizar a las pymes la disponibilidad de una red informática, asequible y fácil de usar que les permite mejorar la fiabilidad y seguridad de su infraestructura de red y reducir tanto inversiones necesarias como costes operacionales.

El desarrollo de Zentyal comenzó a principios del año 2004. En la actualidad Zentyal es la alternativa en Software Libre a Windows Small Business Server y los productos y servicios basados en Zentyal ofrecen una fácil y asequible gestión de red a pymes y proveedores de servicios TIC en todo el mundo.

Noticia recogida de gacetatecnológica

Domingo, septiembre 05th, 2010 | Autor:

Visto en bitelia.com

De Facebook podemos decir mil y una cosas, comenzando por el siempre comentado asunto de la privacidad. De lo que pocas veces hemos escuchado hablar es de su lado abierto, su lado open source. Y es que mucho del software que la inmensa red social utiliza para poder funcionar es de código abierto. Es el mismo software que le permite atender a más de 500.000.000 de usuarios que juntos realizan millones de actividades de diversa índole. Ahora bien, quiero usar este artículo para comentarles un poco de cómo y cuánto software open source utiliza Facebook.

Facebook tiene un par de sitios dedicados al open sourceEl primero de ellos lista todo el que constituye su plataforma, infraestructura, así como sus herramientas de desarrollo. El segundo es un wiki donde están compendiados una buena cantidad de proyectos de código abierto basado en la plataforma de desarrollo ofrecida por la red social. Me concentraré en el primero.

Los desarrolladores de Facebook mantienen kits de desarrollo para Android y iPhone. Asimismo para lenguajes de programación como Python, JavaScript y PHP. En este mismo contexto, también han desarrollado herramientas para facilitar tareas de programación. Este es el caso de

  • Facebook Animation, una biblioteca JavaScript para crear animaciones basadas en la manipulación de CSS y DOM.
  • XHP, una extensión de PHP para integrarse con XML.
  • phpsh, un curioso shell ¡escrito en Python! para acceder a PHP.

más…