SEO: el nuevo anti-virus

On April 23, 2010, in opinion, web, by admin

Ayer un amigo me estuvo dando consejos para mejorar la posición de mis páginas en el indice de Google.  Escuché estas recomendaciones con atención porque:

  1. Una página solo es visitada si tiene una buena posición en Google
  2. Para tener una buena posición en google hoy en día, una página modesta necesita valerse de todas las astucias posibles.

La mayoria de estas recomendaciones tienen que ver con detalles de cuando, como y donde usar diferentes elementos de las páginas HTML, es decir, detallitos menores cuya única importancia es la de tener influencia en los algoritmos que se ejecutan secretamente en los servidores del titán de internet.

Hay toda una industria millonaria alrededor del SEO y se me ocurre que de cierta manera se parece a la industria de los anti-virus hace unos 15 años. Representan un gasto de recursos y energias que no crean ningun valor intrinseco otro que el de llenar un hueco abierto por las falencias del sistema dominante del momento.

Sobre este tema, que se conoce como Search Engine Optimisation, ya había escrito en el pasado.

 

Mas sobre el iPad

On April 15, 2010, in Uncategorized, by sergio

En otra ocasión escribí que no creo que el futuro de la computación este en las plataformas como el iPhone/iPad y la AppStore. Como si no fuera ya una plataforma terriblemente cerrada, hace poco se conoció otra restricción más: está prohibido escribir programas para el iPad en lenguajes diferentes a C++ y Objective C.

Según entiendo, Apple busca atacar a Adobe, quien van a incluir un programa que traduce aplicaciones Flash en aplicaciones iPhone/iPad en su proxima suite de desarrollo.

Ha habido toda clase de blogs en contra de esta restricción y unos cuantos blogs en su defensa. Estos últimos argumentan casi todos que esta medida tiene mucho sentido desde el punto de vista de Apple pero no explican por que es buena para los desarrolladores de aplicaciones. La idea detrás es que lo que es bueno para Apple y el iPhone/iPad es bueno para los desarrolladores.

Otros defensores de Apple pretenden que solo a hackers hermitaños y otras criaturas de poca importancia les interesa escribir aplicaciones en otros lenguajes, y que a los desarrolladores de verdad lo que les interesa es ganar plata y que una plataforma cerrada es la mejor manera de hacerlo. Ya veremos.

Aun cuando el poder desmedido de google me produce desconfianza, espero que Android (que segun entiendo es libre) se imponga en la guerra de los mobiles.

 

Leyendo código fuente

On April 8, 2010, in Uncategorized, by sergio

Sería chevere si uno pudiera leer un programa de computador tal como se lee un libro: en linea recta del principio al fin. Esto casi nunca es posible porque los programas no suelen estar organizados linealmente. Lo que hay, frecuentemente, es un manojo de archivos regados en directorios. Casi siempre me cuesta trabajo encontrar que pedazos del programa hay que leer, y en que orden, para entender globalmente su funcionamiento.

Las diferentes técnicas que he usado son:

  • Si hay suerte, el autor del programa ha escrito un archivo donde explica la estructura del programa y la responsabilidad de cada modulo. Eso da una idea de qué pedazos hay que leer, según lo que uno quiera entender del sistema. Si la documentación es suficientemente buena, el problema está mas o menos resuelto.
  • Mirar el sistema de “build” del programa (el Makefile, el archivo ant, .asd etc) e intentar deducir algo de la estructura del mismo.
  • Mirar los directorios en los que estan repartidos los archivos para deducir algo de la estructura.
  • Leer “de arriba a abajo”. Comenzar leyendo la función que arranca el programa (el “main”) e intentar identificar las funciones de alto nivel. Luego intentar leer “hacia abajo”, haciendo diagramas que muestran como se encadenan las funciones.
  • Si es un programa “orientado a objetos”, a medida que se lee el programa de arriba a abajo, se va haciendo el diagrama de clases.

Lamentablemente, salvo por los programas cuya estructura está bien documentada, la lectura de un programa escrito por otra persona tiene mucho de una actividad a ciegas.

Sospecho, por su nombre, que la técnica de literate programming de Knuth produce programas que se pueden leer como un libro. Nunca he intentado practicarla ni he leido programas escritos así. Que alguién me confirme.

P.S. Muchas veces el problema es que uno esta haciendo dos cosas al tiempo: intentando entender un programa e intentando aprender el idioma en el que esta escrito, es decir la manera particular en la que el autor del programa usa el lenguaje de programación subyacente. (Esto es mucho menos problematico cuando uno es mucho mas familiar con el lenguaje de programación y conoce estilos mas comunes con los que se usa.)

 

Los usuarios de computador necesitan conocer cada vez menos la manera como un computador funciona. Si las tripas de la máquina se vuelven cada día más invisible, esto se debe a que el usuario puede ahora controlar el computador usando interfaces gráficas avanzadas. Estas interfaces permiten controlar el computador usando imagenes que representan objetos fisicos (botones, ventanas, etc).

Comparemos esto con lo que había hace un par de decadas. En ese entonces, el usuario controlaba el computador escribiendo comandos que la máquina ejecutaba. Pienso por ejemplo en el Commodore 64 en el cual para cargar y ejecutar el primer programa de un diskette había que escribir:


load "*", 8, 1

… algo que parecía (y parece) brujería.

En los primeros PCs, que usaban el sistema operativo DOS, los usuarios tambien tenían que escribir comandos. También había que entender, más que ahora, detalles sobre los archivos y los directorios.

Aunque uno puede encontrar primitivas esas interfaces, algo bueno que tenían era que exponían el computador como lo que es: una máquina programable. El commodore 64 por ejemplo venía con un interprete de basic a disposición del usuario apenas éste prendía el computador. A punta de jugar con los diferentes comandos que aparecían en el manual, un niño podía comenzar a intentar cambiar una o dos cosas y luego a leer mas a fondo los manuales para entender como hacer cosas mas avanzadas. Creo que gracias a eso, miles de niños y jovenes aprendieron los rudimentos de la programación. Todo a punta de “cacharrear” la maquina, urgando aquí y alla. Eran máquinas que no intentaban esconder gran cosa, todo lo opuesto a, digamos, el iPhone.

La claridad que tenía la gente del computador como una máquina programable se veía reflejada también en los libros. Algo chevere por ejemplo erán los libros que contenian juegos en basic para que los niños los copiaran en sus commodores 64. Creo que ya no existe nada parecido. Ahora la noción de programador y usuario están claramente separadas.

El mundo del “cacharreo” informatico hoy en día se ha desplazado (como todo) de los computadores personales a la web. Debe haber mucha gente que a aprendido a programar siguiendo el siguiente camino: copiar un manojo de HTML para crear una página web. Cambiar una o dos cosas. Aprender un poco mas de HTML y finalmente aprender PHP para poder generar páginas dinámicas.

P.S.: Acabo de leer este excelente artículo de Cory Doctorow sobre el iPad. Es relacionado con los temas que toca este post.

 

twitter

Personas como Dave Winer creen que definitivamente hay algo en twitter que vale la pena pero que twitter, tal como lo conocemos, será reemplazado en el corto o mediano plazo por algo “parecido pero mejor”. Una de las razones por las que Winer considera que twitter no puede seguir siendo el sistema de “twitting” es su arquitectura centralizada (mas bien anti-web). Otras personas consideran que es demasiado limitado y que le faltan X, Y y Z funcionalidades.

Yo tengo la sospecha de que Twitter va a seguir siendo el sistema que es, con muy pocas variaciones, y que no será reemplazado por nada “mejor” durante un buen tiempo. Mi sentimiento es que twitter está en un punto perfecto de simplicidad, un punto tal que el usuario le perdonará inconcientemente cualquier limitación siempre y cuando siga siendo tan facil de usar.

Me ha gustado la manera como ha evolucionado twitter. Practicamente solo ha añadido al sistema conceptos que ya habian surgido de manera espontanea entre los usuarios, como la referencia a otro usuario (usando “@”) o el concepto de “retweet” (“RT”).

Otra cosa buena de twitter es que a pesar de ser centralizado, ha ofrecido interfaces de programación tremendamente sencillas para construir aplicaciones independientes sobre twitter, lo cual ha dado lugar a un gran ecosistema alrededor que va a hacer dificil de hacer migrar a otro sistema.

En fin, twitter es un ejemplo de como la simplicidad y las APIs abiertas pagan.

 

Abstracción sintactica

On March 19, 2010, in programación, by sergio

le coq

Le Coq - Joan Miro

Recordemos algunas nociones básicas.

La misión del desarrollador de software consiste en escribir programas que sean faciles de entender. Un programa es facil de entender cuando esta escrito como un conjunto sencillo de relaciones entre conceptos. Como estos conceptos pueden ser a su vez complejos, el programador retiene de ellos unicamente la información necesaria para entender sus relaciones con los demás conceptos. Cada concepto del programa principal es representado por otro pedazo del programa, escrito de manera similar. Este mecanismo de reducción del nivel de detalle de una parte del programa se conoce como abstracción.

Si en un programa existen pedazos de código muy similares, el programador debe preguntarse si no existe un concepto implicito que merezca ser representado por una abstracción.

Los dos tipos de abstracción mas conocidos son tal vez el procedimiento, que captura una serie de acciones, y los tipos de datos, que representan la entidades sobre las cuales un programa actua. Los diferentes tipos de abstracción permiten reducir la complejidad de los programas de diferentes maneras. Cada lenguaje de programación ofrece sus propios mecanismos de abstracción según el estilo de programación que promueven, por ejemplo funcional u orientado a objetos.

Railway Crossing

Railway Crossing - Leger

La abstracción sintactica permite regrupar formas sintacticas similares. Para explicar a que me refiero con “formas sintacticas similares” daré un ejemplo. En el lenguaje java, en las versiones anteriores a 1.5, la manera mas familiar de iterar sobre un arreglo era escribir algo asi:


int[] arreglo = {1,2,3};

for (int i = 0; i < arreglo.length ; i++){
int var = arreglo[i];
doSomethingWith(var);
}

Al escribir código como este muchas veces, es obvio que hay algo que puede generalizarse. Java 1.5 ofrece la siguiente forma de escribir esto mismo:

int[] arreglo = {1,2,3};

for (int var : arreglo){
doSomethingWith(var);
}

La ganancia en legibilidad es enorme cuando se tiene en cuenta el enorme número de iteraciones sobre un arreglo que pueden aparecer en un programa. Como java no ofrece soporte a la abstracción funcional, los programadores de java tuvimos que esperar hasta que los encargados de el lenguaje ofrecieran esta nueva forma de iterar sobre un arreglo, sin poder hacer nada al respecto. En un lenguaje como lisp que permite la abstracción sintactica el programador podría haber creado su propia versión de “for”, de considerarlo necesario. En lisp esto se hace gracias a un poderoso sistema de macros.

Veamos otro ejemplo, basado en common lisp pero explicado en pseudo código. Si imaginamos una librería que permita escribir lineas de texto a un archivo, su uso en un lenguaje tradicional se parecerá a esto:


variable stream = open("archivo");
try {
print(stream, "hello");
print(stream, "world");
}
finally {
close(stream);
}

Luego de escribir código parecido al anterior muchas veces, podemos imaginar lo conveniente que sería reducir lo anterior a una forma mas pura, algo parecido a esto:


with-open-file (stream "archivo") {
stream.print("hello world");
}

que “esconda” los detalles de captura de excepciones y de cerrar el stream al final de su uso.

En lisp existe un macro que hace exactamente eso. Pero el punto aquí no es que lisp soporte esta sintaxis sino que, de no existir, el programador podria introducirla sin ningun problema.

 

Programación interactiva

On March 12, 2010, in programación, by sergio

Una de las cosas que mas me gustan de programar en Lisp es que encuentro facil mantener la concentración cuando lo hago. Creo que esto se debe en buena parte a la programación interactiva que facilitan los ambientes de desarrollo en lisp. La programación interactiva consiste en ir modificando un programa poco a poco mientras éste se encuentra activo. Es decir, el termino de programación interactiva no tiene que ver con el estilo en el queesta escrito un programa sino con el proceso de escritura del código. Veamos esto un poco mas en detalle.

Teclado symbolics

En ambientes no interactivos los programadores trabajan intercalando dos tipos de actividades bien separadas: la edición y la ejecución. La programación es entonces una secuencia de sesiones de edición de código y de sesiones de ejecución (y a veces también de fases de compilación). Al terminar una sesión de edición, se lanza el programa y se observan los efectos sobre el comportamiento del programa. Una vez se ha observado el programa en ejecución, se interrumpe el programa para empezar una nueva sesión de edición. Cada actividad esta claramente delimitada e implica un tipo de gestos distinto. El cambio entre una actividad y otra implica un cambio de contexto mental que se convierte en un esfuerzo adicional. El programador tiende entonces a programar en sesiones de edición largas para evitar el tener que cambiar frecuentemente de actividad.

En ambientes interactivos, el programa todo el tiempo esta en ejecución y el programador modifica su comportamiento haciendo un pequeño cambio a la vez. El programador trabaja en micro-sesiones de edición tras las cuales observa inmediatamente el resultado de la edición. La sensación del programador es que las dos actividades, modificar el programa y observar el resultado de las modificaciones, se funden en una sola actividad.

Los programadores de common lisp suelen usar el editor de texto Emacs junto a Slime, una adaptación que permite programar interactivamente. Una sesión de trabajo consiste habitualmente en:

  1. Cargar el sistema en el que se va a trabajar, a partir del editor;
  2. Escribir nuevas funciones o modificar las existentes y hacer que el sistema en ejecución use estas nuevas definiciones tan pronto se van escribiendo;
  3. Probar constantemente estas nuevas funciones ejecutando fragmentos de código, que luego pueden deshecharse.

Como se puede ver, el programador “lanza” el sistema al inicio de una sesión de trabajo y no lo detiene sino cuando termina de trabajar.

En java se puede lograr un cierto nivel de interactividad usando un buen ambiente de desarrollo integrado, por ejemplo Eclipse, en el que un programa puede facilmente ejecutarse en modo “debug” y modificar las clases “en caliente” sin tener que detener la ejecución. Aún así, en java muchas veces es necesario detener la ejecución del programa, por ejemplo cuando se cambia el nombre de un método.

Turbo C

Aparte del ambiente de desarrollo, el lenguaje en si mismo influye en que tan interactivamente se pueda programar. Por ejemplo, muchas veces en java, para poder usar una cierta librería, es necesario crear sub-clases. Crear una clase implica una sesión de tecleo relativamente larga, que destruye la fluidez de la programación interactiva.

Uno de los ambientes menos interactivos en los que he trabajado lo sufrí desarrollando una cierta aplicación en java que solo podia ejecutarse en un servidor de aplicaciones instalado en otra máquina. Cada vez que modificaba el código y queria probar mis cambios, debia detener la aplicación, subir el programa usando una interfaz web y relanzarlo. Para una persona como yo, a la que le cuesta concentrarse, mantener la cabeza en lo que estaba haciendo era una odisea en esas condiciones.

Creo que la academia debería interesarse al tema del placer en la programación. Por que puede ser mas placentero programar de una cierta manera que otra y cómo se refleja el placer del programador sobre el resultado final.

 

Hace cerca de 15 años, en la Universidad de los Andes, la programación se enseñaba usando “C“, un lenguaje de programación muy popular desarrollado en los 70, en paralelo con el desarrollo del sistema operativo UNIX.  En los 90, lenguajes de programación como Java fueron reemplazando al lenguaje C tanto en la empresa como en las aulas. Hoy en día, según me dicen, la programación se enseña usando Java y los estudiantes simplemente no aprenden C.

Este cambio preocupa a ciertos de mis colegas quienes consideran que, aún si no se va a usar este lenguaje, un programador debería saber programar en C. Muchos de estos colegas se quejan de los programadores más jovenes acusandolos de “no saber que es un apuntador”, lo cual parece ser, por el tono de la queja, algo muy grave. Qué tan realmente es importante saber programar en C para un programador? Cual es el realmente el fondo del asunto.

Yo supongo que lo que deploran mis colegas es el hecho de que al no haber tenido contacto con un lenguaje con manejo explicito de la memoria, aritmetica de apuntadores, acceso directo a ciertas funciones del sistema, etc, los programadores de hoy en dia sean menos concientes de qué es lo que ocurre con los recursos de la maquina cuando un programa es ejecutado. El verdadero debate es entonces sobre que tanto necesita conocer un programador sobre la manera como sus programas actuaran en terminos de los mecanismos de base de un computador. Personalmente creo que es importante. Por esta misma razon, creo que es importante tener idea de como está implementado un compilador.

Por otra parte, recordemos a Edsger Dijkstra, quién dijo: “computer Science is no more about computers than astronomy is about telescopes”.

 

Buen diseño

On March 4, 2010, in Uncategorized, by sergio

Dieter Rams es una de las personas que mas han influido en la práctica del diseño industrial. Muchos de los productos que Rams ha diseñado durante su trabajo en la empresa Braun son admirados mundialmente. Rams ha resumido su pensamiento sobre el diseño en los siguientes principios:

  • Un buen diseño es innovador
  • Un buen diseño hace un producto util
  • Un buen diseño es estético
  • Un buen diseño no obstruye
  • Un buen diseño ayuda a entender un producto
  • Un buen diseño es honesto
  • Un buen diseño no envejece
  • Un buen diseño es coherente hasta en el mas mínimo detalle
  • Un buen diseño tiene en cuenta el medio ambiente
  • Un buen diseño es tan poco diseño como sea posible
 

La gravedad de los últimos sucesos nacionales me obligan a interrumpir la programación habitual de este blog para revelar una grabación robada de lo que parece ser el presidente de la república enterandose de que la corte constitucional no aprobó el referendo reeleccionista.

Sigan en sintonía