Eclipse 3.7 Indigo es una nueva evolución del IDE que ya lleva una década entre nosotros desde Eclipse 1.0 presentado en Noviembre de 2001. La última versión estable del IDE era Eclipse 3.6 Helios liberada en Junio de 2010.

IBM ha anunciado una nueva herramienta visual de desarrollo de interfaces de escritorio y móviles basada en código abierto y a la que ha denominado Maqetta. Lo ha hecho en el evento anual IBM Impact 2011, que está siendo cubierto en directo por NetMediaEurope desde Las Vegas (EE.UU.).

Maqetta podría revolucionar la industria de desarrollo de aplicaciones RIA (Rich Internet Application) donde otras alternativas cerradas como Adobe Flash y Microsoft SilverLight se encuentran asentadas. Es así porque se trata de un conjunto de herramientas basadas en código abierto que permiten la creación de aplicaciones HTML5. De hecho, IBM contribuirá con el código fuente de Maqetta en la Fundación Dojo, que será la que hospede este proyecto.

Básicamente, Maqetta está construida en HTML/Ajax y no es necesario ningún tipo de plug-in adicional para poder ejecutarla en un navegador. Soporta ensamblaje de los módulos que conforman un interfaz mediante Drag&Drop y su código está disponible para que cualquier usuario pueda personalizarla según sus necesidades. En pocas palabras, se podrán crear páginas web HTML5 desde el propio navegador y en un entorno WYSIWYG.

Todas las funcionalidades de Maqetta ya están disponibles para ser renderizadas en las últimas versiones de los navegadores: Microsoft Internet Explorer, Mozilla Firefox, Google Chrome, Apple Safari y todos los sistemas basados en movilidad como iPhone, Android, RIM, BlackBerry y Windows Phone 7.

Actualmente Maqetta se encuentra disponible para la comunidad de desarrolladores de forma gratuita en versión Preview 1 desde el sitio http://maqetta.org.

“Incorporando Maqetta a la Fundación Dojo como código abierto y software gratuito, IBM espera construir una comunidad de usuarios y desarrolladores open source que trabajen juntos para crear una nueva generación de interfaces de usuarios basados en HTML5” ha indicado durante el lanzamiento David Boloker, CTO de Tecnologías Emergentes para Internet de IBM.

Después de 3 años trabajando en entornos hospitalarios me pregunto porque todavía seguimos utilizando sofware de pago, y con licencias muy costosas, cuando tenemos software mucho mejor (valoraciones objetivas por personal que trabaja con el), libre y más eficaz….

Si estamos en crisis, ¿porque no intentanmos ahorrar?

OsiriX es una aplicación de procesamiento de imagen dedicado a imágenes DICOM (extensiones “. dcm” / “. DCM”), producido por el equipo médico (resonancia magnética, TAC, PET, PET-CT, …).

OsiriX es complementario a los visualizadores actuales, en particular a los espectadores de la medicina nuclear. También puede leer muchos otros formatos de archivo: TIFF (8,16, 32 bits), JPEG, PDF, AVI, MPEG y Quicktime.

Es totalmente compatible con el estándar DICOM para la comunicación de imagen y formato de archivo de imagen. OsiriX es capaz de recibir imágenes transferidas por el protocolo de comunicación DICOM desde cualquier PACS o modalidad de imagen médica (TIENDA SCP – Clase de servicio del proveedor, TIENDA SCU – Clase de servicio del usuario,  query/retrive).

La decisión de establecer la fundación al momento de lanzamiento del proyecto fue una elección deliberada de dejar la puerta abierta a posibles contribuyentes, y permitir a todos a participar en la conformación de la misma.

Durante las últimas semanas, el Comité Directivo de The Document Foundation evaluó varias opciones para el establecimiento de la persona jurídica. Durante una conferencia telefónica pública del Comité Directivo se tomó la decisión de formar la fundación en Alemania, bajo la forma jurídica de una “Stiftung”.

Para constituir de manera legal The Document Foundation en Alemania se necesita un mínimo de 50.000 euros. Por lo tanto, hemos lanzado este desafío público de 50.000 euros para recaudar los fondos a través de donaciones.

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

• 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

• 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

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

• 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!).

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

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.

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

Dichos cambios “estéticos” forman parte del proyectoRenaissance, cuyo lema de batalla reza algo así como: “Crear una interfaz de usuario de manera de que la elección de OpenOffice no sólo sea una elección por necesidad, sino que también por el deseo de los usuarios”.

En realidad es una frase bastante cierta, y sería bueno ver un OpenOffice que fuera más amigable.

La primera beta de la suite de ofimática se encuentra disponible pare descarga en versiones de 32 y 64 bits. Como es un beta, no es recomendable su instalación en ambientes de producción, y quien quiera probarlo deberá hacerlo bajo su propio riesgo.

Link: OpenOffice.org 3.3.0 Beta 1 (OpenOffice.org)

Visto en laflecha

• Extensions and scrips updates
• Miscellaneous fixes in interfaces
• Updated translations
• Various crashes and errors fixed
• TS and DVB demuxing fixes
• Audio filters fixes to solve the “mono” bug
• Fix of the direct3d output module that display nothing on older nVidia and ATI cards, when overlay was activated

Para instalarlo en Ubuntu vía PPA tenemos dos alternativas, ambas sin los paquetes compilados con aceleración por hardware, ya que requiere de otra paquetería que rompe con muchas dependencias de Ubuntu 10.04.

Dentro de horas seguramente los repositorios que siempre usamos para instalar esta versión seguramente serán actualizarán, me refiero a estos repositorios:

sudo add-apt-repository ppa:c-korn/vlc && sudo apt-get update
sudo apt-get install vlc mozilla-plugin-vlc

Ahora, si sos impaciente, podes utilizar estos repositorios, que te va a ofrecer actualizar otros paquetes.

sudo add-apt-repository ppa:ferramroberto/linuxfreedomlucid && sudo apt-get update
sudo apt-get install vlc mozilla-plugin-vlc

En ambos casos, si tenemos VLC 1.0.x, se recomienda desinstalar esta versión antes de actualizar. Vuelvo a recordar, los paquetes de cualquiera de estos repositorios no fueron compilados con la aceleración por hardware, al menos para Lucid Lynx. Los últimos repositorios ofrecerá actualizar otra paquetería distinta a la propia del VLC.

Desde el centro de descarga oficial podemos obtener las instrucciones y links para descargar el programa para otroas Distribuciones GNU/Linux y otras plataformas.

visto en: https://elsoftwarelibre.wordpress.com