El lenguaje de programación correcto

"Las especies que sobreviven no son las más fuertes, sino las que se adaptan mejor al cambio"

-- Darwin

En internet, parece ocurrir algo similar. No prosperan los lenguajes de programación que te hagan más fuerte, sino los que te permitan adaptarte mejor al cambio... en cierto ambiente.

Por ejemplo, php es popular en proyectos educativos y sociales. Java es popular en proyectos empresariales. C es popular en proyectos técnicos. Otras alternativas importantes son Python, Ruby, etc.

Muchas personas tienen sus preferencias y a veces tienden a tomar posiciones, pero es importante ver más allá y recordar cuál es la razón por la que programamos.

Cada lenguaje existe por alguna razón. Porque de algún modo es la mejor respuesta para cierto problema. Porque es la mejor especie en cierto ambiente.

Pienso que no hay una solución "correcta" ni una manera "correcta" de hacer las cosas universalmente. Cada problema contiene su solución, y es importante estar atento a la solución que te está cantando el problema, en lugar de pretender que escuche la que nos gusta cantar.

Así podemos aprender nuevas canciones :-)

¿Cuánto puede mejorar tu software? ¿Qué tan clara es la especificación? A más ciclos de desarrollo, más probabilidad de acercarse al ideal.

¿Cuántos ciclos de desarrollo puedes realizar? ¿Qué tan sencillo es de iterar o incrementar? A más contribuyentes, más probabilidad de encontrar excelentes contribuciones.

¿Cuántos contribuyentes puedes encontrar? ¿Qué tan sencillo es comunicarse? Hay más probabilidad de encontrarlos si los lenguajes son más atractivos, los entornos de desarrollo más asequibles, el camino de inicio más motivador.

Quizás por eso un lenguaje de programación no tan fuerte puede a veces llegar tan lejos. Es importante tener en cuenta el ambiente para prosperar.

Ajedrez Mental

¿Qué tan buenas partidas de ajedrez puedes jugar mentalmente?

Imagina un grupo de personas reunido para resolver un problema. Luego de acomodarse en el lugar, comienzan a hablar. Y hablar. Y solamente hablar.

La reunión, usualmente tediosa, termina después de un tiempo, usualmente largo, donde los asistentes, usualmente cansados, han llegado a una solución, usualmente sub óptima.

En cambio, en otros lugares se usa una pizarra, o un papel mural, donde los participantes pueden expresar con libertad las ideas que van exponiendo.

Cuando el problema se puede ver escrito en un lugar, nos ahorra el esfuerzo de mantener su imagen mental, y así tenemos más energía para imaginar otras cosas. Quizás la solución. 

Es significativamente mayor el nivel de dificultad de los problemas que podemos resolver usando un diagrama o mapa de la situación en lugar de tratar de imaginar todo, todo el tiempo.

Cuando se trabaja mentalmente, probablemente la imagen mental de cada asistente sea distinta a la del otro. De modo que pronto se encuentran con malentendidos y discusiones fuera del tema. Es bastante fácil que la gente pierda la pista, desista, y finalmente se imponga la ley de la jungla de personalidades, favoreciendo a la más fuerte o carismática.

En cambio, un diagrama o mapa de conceptos está ahí mostrando de qué estamos hablando. Ayuda a mantener el foco de la reunión. Asegura los avances que se van logrando y permite construir una estructura. La sinergía se logra con más facilidad.

Y debería ser más obvio que eso habría de esperarse -si no lo es, habría que preguntarse dónde está escondido el león ;-)

Los tratos por escrito son más seguros que los realizados solo de palabra. Los comerciantes y abogados lo saben. Porque aun cuando las partes actúen honestamente, la memoria es frágil y puede recordar, o dejar de recordar, cosas que la otra persona no.

Los acuerdos escritos ayudan a que evitemos estar peleando una y otra vez las mismas batallas. Y cuando tenemos esa energía liberada, podemos emplearla para pasar al siguiente nivel de complejidad y desarrollo.

Inténtalo en tus reuniones. Escribe qué quieres lograr, escribe qué es lo que tienes y cuál es la situación. Experimenten con ideas de cómo podrían alcanzar lo que quieren. Escriban las conclusiones y acuerdos.

Podrás ver la partida que juegas. Podrás imaginar más variantes y jugadas. Será más fácil volver sobre ella y reflexionar. Será más fácil mejorar las cosas e ir mejorando.

Crédito de la imágen: http://www.ajedrezleganes.com/images//ajedrez2.gif

Solucionando problema vista dinámica en blogger

Puede ser que al usar la plantilla de vista dinámica en blogger, hayas notado que el fondo ya no aparece, o que la mayoría de imágenes no se ha cargado.

Esto se debería a que blogger colocó un script para prevenir que la carga de una página demorara demasiado.

Sin embargo, el tiempo asignado por default es muy poco. Y por eso paginas que antes cargaban bien ahora aparecen con aspecto tristón.

Para solucionarlo, ir al administrador del blog, entrar a Plantilla, Editar HTML y buscar al final del documento u código similar al siguiente:

<script language="javascript" type="text/javascript">
  setTimeout(function() {
    blogger.ui().configure().view();
  }, 1000);
</script>

Observar que he cambiado el 0 que estaba por 1000 milisegundos (1 segundo).

Guardar la plantilla y ver la mejora en la carga.

Spaghetti code

Se nos ha enseñado acerca del código spaghetti. Como los producidos por abusar del goto en BASIC. O por abusar de los callbacks en Javascript.

Algunos se precipitan en afirmar que los goto no son buenos. Y aunque es un poco difícil afirmar lo mismo de los callbacks, a veces se apresuran en tomar esa postura.

Lo cierto es que el goto puede ser útil, igual que el callback. Lo que no nos parece bueno es el spaghetti que se produce cuando se abusa de ellos. Es importante notar la diferencia.

Los lenguajes de programación modernos tienen la tendencia a eliminar la posibilidad de abuso de goto limitando las estructuras de control de flujo. Es más fácil controlar un problema si no hay opción de que se produzca, en primer lugar.

Sin embargo, más allá de eso, resulta que desde el punto de vista de la máquina, tanto el código spaghetti como uno más estructurado son igualmente correctos y válidos. La buena estructura es una preferencia humana, para facilitar el desarrollo y mantenimiento. El spaghetti code le da igual a la máquina, es al humano el que tiene problemas con él. También es importante recordar eso.

Si hubiera alguna manera de moverse con facilidad y seguridad por el código spaghetti, no habría tanto problema. Me pregunto si habrá algún modo de manejar ese aparente caos, en lugar de evitar que se produzca.

Quizás nunca se puede evitar del todo la ocurrencia del caos, tan solo postergarlo lo más posible. Es conocido que, según crece un proyecto de desarrollo, es más complicado mantenerlo estructurado y oponerse al caos.

Pero, ¿sería posible manejar el caos, en lugar de huir de él? ¿alguna metodología? O, si es demasiado para un humano, ¿sería posible hacerlo con ayuda de un asistente?, ¿podríamos pasar de ser autoempleados en programación a procurarnos la ayuda de la computadora y pasar a otro nivel?

Crédito de la imágen: http://upload.wikimedia.org/wikipedia/commons/e/ee/Tarako_spaghetti.jpg

Resolviendo el virus que crea acceso directo intermediario en memorias y discos portátiles

En días pasados, conecté mi disco duro portátil en una computadora y noté que todos los archivos desaparecían de su directorio raíz y en su lugar aparecía un acceso directo.

Haciendo click en el acceso, se podía acceder a los archivos. Era como si hubiera aparecido un nivel más.

Viendo en la ruta mostrada por el navegador de archivos, aparecía un directorio de nombre vacío conteniendo todo lo demás.

En algunas computadoras con antivirus, aparecía una alerta al intentar ejecutar el acceso.

Buscando en Internet no encontré ninguna referencia al problema.

Felizmente, revisando un poco el disco, encontré que era posible deshacer el cambio manualmente. Así que aquí está el procedimiento por si ayuda a alguien más (ayer tuve el mismo problema luego de usar mi usb en en una computadora pública):

• Realizar el procedimiento en una computadora limpia, con antivirus. Es decir que no haya ocasionado el problema que describí.
• En el explorador de archivos, entrar al menú (tecla Alt), y entrar Herramientas, Opciones de Carpeta. Activar ver los archivos ocultos y también ver archivos del sistema (que normalmente están desactivados).
• Conectar el disco o usb infectado. Podrá ver varios archivos de nombres raros, incluyendo el acceso directo. Pero también uno de nombre aparentemente en blanco.
• Ingresar a ese directorio de nombre en blanco para verificar que están nuestros archivos.
• En este punto se pueden hacer varias cosas. Como copiar todos nuestros archivos a otra unidad, formatear el drive infectado y luego copiar otra vez nuestros archivos.
• Una opción más rápida es eliminar todos los archivos de nombres raros, incluyendo el acceso directo, y dejando sólamente el directorio de nombre en blanco. En el directorio en blanco, también eliminar los archivos raros que notara en su interior (como desktop.ini, en mi caso). Luego, mover todos los archivos del directorio en blanco al directorio raíz. Finalmente, eliminar el directorio en blanco.
  Son más pasos, pero mover archivos consume menos tiempo que copiarlos a otro drive y traerlos de vuelta.