Posts by iñigo medina

Mi visión naturalista de la tecnología

30 de junio, 2012 - por | | Análisis

pinzones de DarwinPinzones de Darwin, con picos adaptados a diferentes fuentes de alimento.

Última actualización: 4 de julio de 2012

Voy incorporando materiales que entran de lleno en la discusión. Así que si echas algo en falta, no dejes de comentarlo.

Jeff Atwood publicó ayer un post sobre PHP, haciendo balance de sus defectos, su evolución y su uso. A raíz de ese post mantuve una discusión con @aitorciki en Twitter, motivada por mi valoración negativa del post a causa de su tono elitista.

Mi referencia al “elitismo” era en el sentido general del término, no en un sentido técnico tal como se utiliza en algunas ciencias sociales. Es fácil reconocer en el post de Atwood una actitud de arrogancia respecto de lenguajes populares (BASIC, PHP), que el autor considera, por decirlo suavemente, lenguajes menores: llenos de monstruosidades, apenas evolutivos y completamente “banales”.

@aitorciki no veía, por el contrario, elitismo por ningún lado. Después de todo, compartía el diagnóstico y entendía que era indiscutible. Es más, le parecía que Atwood había bajado al terreno de asumir la convivencia con tales aberraciones.

La postura que comparten, en este caso, Atwood y @aitorciki es muy común, y he tenido la oportunidad de discutirla numerosas veces a lo largo de los años. Y me he permitido con el tiempo la licencia de calificar a sus defensores como creacionistas tecnológicos, estableciendo así una asociación, tomada con un poco de sal, entre este tipo de debates y los que se han venido produciendo en el terreno de lo orgánico entre los evolucionistas y sus detractores desde que Darwin diera forma a sus argumentos a mediados del XIX.

Siguiendo el hilo de discusión que mantuve con @aitorciki en Twitter, voy a intentar ofrecer lo principal de los argumentos creacionistas, junto con mis opiniones de por qué no son satisfactorios o bien directamente son erróneos.

“PHP subsiste por estar extendido, no por ser bueno”

Creo que ésta es la afirmación que mejor retrata a los creacionistas tecnológicos. @aitorciki me la ofreció para ayudarme a comprender lo que quería decir Atwood en su post, y es realmente el argumento que más implicaciones tiene.

Probemos un momento, continuando el jueguecito de asociarnos a los debates naturalistas, a aplicarlo a una especie animal. Veamos cómo suena:

Las cucarachas subsisten por estar extendidas, no por ser buenas

Este simple experimento nos ayuda a extraer la parte más delicada del problema: ¿qué queremos decir con “bueno”? Entiendo que los creacionistas tecnológicos utilizan el término para referirse a lo que está bien diseñado, pero no como podría entenderse en el caso de las cucarachas (bien diseñadas desde el punto de vista adaptativo, para sobrevivir y reproducirse). Es decir, el principio de adaptación/extensión no forma parte del buen diseño: un lenguaje puede ser aberrante desde el punto de vista del diseño y al mismo tiempo ser un lenguaje muy popular, y por lo tanto estar muy implantado; y viceversa, se puede tener un lenguaje muy bien diseñado que nunca haya conocido una implantación.

Como les ocurría a los creacionistas naturalistas, el reto para Atwood y @aitorciki es explicar cómo sucede entonces esa extensión generalizada. Atwood da una respuesta que es claramente insatisfactoria: “lo barato y popular y por todas partes siempre gana“; puesto que no explica cómo llega a ser popular y a estar en todas partes, y por qué se impone frente a otras alternativas también baratas. Los creacionistas del XIX acababan en el terreno de los misterios, o de alguna mano divina que finalmente no explicaba nada; los del XXI se conforman con alusiones al populismo. Ambos se pierden la parte más bonita: asomarse al proceso maravilloso, gradual, lleno de interacciones acumulativas, que lleva a algo a sobrevivir y extenderse.

No es el momento de investigar los factores que han intervenido en ese proceso evolutivo en lenguajes como BASIC y PHP, de los que se ocupaba Atwood. Existe una buena cantidad de libros y artículos que se ocupan de la historia de la tecnología en los momentos en los que surgieron y se establecieron éstos, y entre todos los materiales que reúnen esas historias están las claves de dicho proceso.

“Entonces los Ibiza son mejores coches que los Ferrari porque hay más”

Esta segunda afirmación de @aitorciki quería resumir de forma gráfica lo que según él se deducía de lo que yo argumentaba. Parece bastante evidente que la afirmación no aclara nada sino que añade más complejidad, porque se sale del terreno de los lenguajes de programación y se introduce en un terreno de producción industrial del que ni siquiera sabemos por dónde se establece la relación. Ayuda a entender el fondo valorativo de los creacionistas; no es una casualidad que esté hablando de “Ibizas” y “Ferraris”, puesto que en su árbol de especies tecnológicas él cree saber cuáles están en cada uno de esos cajones y la jerarquía de diseño que las relaciona.

Si intentamos continuar con el jueguecito que proponíamos al principio, tendríamos que buscar una afirmación similar en el terreno de lo orgánico, respetando un mismo orden (coche) con distintas especies. Podríamos decir algo así:

entonces los seres humanos son mejores primates que los macacos porque hay más

pero entonces para el creacionista habríamos cambiado el sitio de los “Ibizas” y los “Ferraris”. ¿Pero es posible decir ésto sin aclarar qué queremos decir con “mejores”? El principio de extensión no te dice nada salvo que entiendas cómo se ha producido esa extensión; es en el proceso de extenderse dónde tienes los factores que han hecho posible ese resultado, por lo tanto, donde puedes encontrar algún indicador de en qué cosas se ha comportado mejor respecto de otros con los que competía.

En abstracto, sin tener en cuenta el paso del tiempo, las situaciones y las personas que los utilizan, ¿cómo puedes valorar la bondad del diseño de una tecnología?

“I’m starting a new open source web project”

Atwood exponía toda la osadía del creacionista al final de su post, cuando afirma que va a empezar un nuevo proyecto que corrija las aberraciones de PHP, creando un ecosistema capaz de competir con PHP. Como el creacionista no tiene en cuenta el proceso evolutivo, no se da cuenta de que los resultados de ese proceso evolutivo no son el deseo de alguien, sino la interacción de numerosos factores. Cree que un “mejor diseño” puede convertirse por sí solo, por el solo hecho de estar mejor pensado, en una especie competitiva. Como si el tan denostado Rasmus Lerdorf, cuando escribía las primeras líneas de PHP, hubiese podido asegurar donde iba a llegar su criatura. O Linus Torvalds, cuando Tanenbaum le criticaba el diseño de Linux por demasiado pegado a la arquitectura y aseguraba que tendría un recorrido muy corto.

Conclusión

Puede verse, por todo lo que se ha ido argumentando, que los creacionistas no tienen realmente argumentos sobre los que apoyar sus afirmaciones, más allá de sus propios juicios de valor personales. También, que es muy difícil hablar de diseño sin tener en cuenta el entorno respecto del que va a funcionar ese diseño, que lo obligará a ser evolutivo (rápidamente adaptativo), y no tanto un diseño perfecto desde el principio. Por último, que la extensión de la implantación de una tecnología es un factor de su índice de calidad, puesto que el mismo proceso evolutivo la ha llevado a enfrentarse a situaciones y usos que la han enriquecido y la han hecho más competitiva que las otras.

Todo lo que se ha dicho nos es más familiar de lo que pensamos, incluso para los mismos creacionistas, puesto que al final escogen entre tecnologías muy populares (C, Java, PHP, Python, .NET, JavaScript, etc.) que han conseguido una implantación suficiente. Todos entendemos que siguiendo un criterio teórico y estético podemos hacer una valoración más o menos positiva de una tecnología; no está tan claro, sin embargo, que esa valoración nos diga algo sobre la realidad de esa tecnología ni sobre su capacidad para imponerse frente a otras.

Actualización del 4 de julio de 2012

Fabian Potencier escribe un post donde hace balance de PHP y defiende que aunque no sea el mejor lenguaje, en cuanto a diseño, es el mejor entorno de desarrollo web.

Tar: excluir ficheros cuando haces un tar

2 de septiembre, 2011 - por | | Linux, Tips

En bastantes ocasiones me he encontrado con la necesidad de empaquetar código pero excluyendo ciertos ficheros/directorios. Cuando se trata de una exclusión pequeña, con unos pocos ficheros, hago lo siguiente.


$ tar -zcf backup.tar.gz --exclude='fichero1' /home/imedina/code

Cuando se trata de un número mayor, es más cómodo crear un fichero con un listado de todos aquellos ficheros que quieres excluir.


# exclude.txt
fichero1
fichero2
*.jpg

Luego, haces el tar de la siguiente forma.


$ tar -zcf backup.tar.gz -X exclude.txt /home/imedina/code

Es importante recordar que lo que hemos hecho con ficheros, lo puedes hacer igualmente con directorios (puesto que no dejan de ser ficheros).

Git: ver el log, buscar en el log

23 de agosto, 2011 - por | | Desarrollo, Tips

Una buena búsqueda te puede ayudar mucho. También a sobrevivir.

Cuando llevas un tiempo trabajando en un repositorio con Git, empiezas a tener la necesidad de revisar el log de lo que ha ido pasando. Algunas de las acciones más típicas con las que te vas a encontrar, son las siguientes.

Ver lo que ha cambiado en cada commit


git log -p

Ver los ficheros que han cambiado en cada commit


git log --stat

Ver el listado de todos los commits con sus ramas


git log --pretty=oneline --abbrev-commit --graph --decorate

Ésto te devuelve un listado de los commits con sus títulos abreviados, en una sola línea y con una representación jerárquica de sus ramas. Puedes verlo en la siguiente captura de uno de nuestros proyectos:

Buscar palabras que aparecen en el título del commit


git log --grep="tu búsqueda"

Buscar cuándo algo fue añadido o eliminado


git log -S "tu búsqueda"

Filtrar por fechas recientes con MySQL sobre Codeigniter

12 de agosto, 2011 - por | | Desarrollo

Nos pierde lo que acaba de suceder. Vivimos más intensamente lo que es reciente.

Hace poco he tenido que desarrollar el clásico grupo de filtros en forma de checkboxes, combos y radio buttons que se van aplicando con cada click que hace el usuario sobre un listado inicial de todos los elementos posibles.

Uno de los filtros tiene el siguiente aspecto:

La forma más fácil de desarrollar este filtro la encontré utilizando la función MySQL DATE_SUB(). Esta función tiene la siguiente sintaxis:


DATE_SUB(date,INTERVAL expr type)

donde date es una fecha cualquiera válida, y INTERVAL el número que quieres sustraer.

Lo que hice fue lo siguiente. A cada una de las opciones del filtro le asigno un valor numérico (31, 7 y 2 respectivamente). Considero date como el día de hoy, es decir, el momento en el que el usuario está aplicando el filtro. Le paso ambos argumentos a la función de MySQL, en la forma en el que Active Record de Codeigniter permite hacer este tipo de cosas:


$where = "upload_ts > DATE_SUB( NOW( ) , INTERVAL " . $days . " DAY)";
$this->db->where($where, null, false);

Utilizar InnoDB en Django

8 de agosto, 2011 - por | | Desarrollo, Tips

Si estás empezando a trabajar con Django y vas a utilizar MySQL, te conviene pararte un momento a mirar si estás utilizando el tipo de almacenamiento que realmente quieres.

Al generar los esquemas, Django no especifica ningún tipo de almacenamiento; sencillamente los genera con el que está establecido en tu servidor de MySQL. Así que si aún no has generado ningún esquema, revisa tu configuración de MySQL. Todas las versiones previas a la 5.5 hacían de MyISAM el almacenamiento por defecto.

La configuración del tipo de almacenamiento la puedes hacer directamente en MySQL, o especificarla en los settings de tu conexión a la base de datos en Django utilizando la opción “init_command”. Por ejemplo, del siguiente modo para establecer InnoDB como el tipo almacenamiento por defecto.


'OPTIONS': {
   'init_command': 'SET storage_engine=INNODB',
}

Si ya cuentas con algunas tablas, y te encuentras con que están con un tipo de almacenamiento distinto al que tu pensabas, te va a tocar modificar las tablas en la forma habitual:


ALTER TABLE tablename ENGINE=INNODB;

Problemas al guardar la IP en la sesión con conexiones 3G

7 de agosto, 2011 - por | | Curiosidades, Desarrollo

Hace poco me ha surgido un problema para el que en un primer momento no encontraba una explicación satisfactoria. Sobre una aplicación escrita en PHP y que trabaja casi todo el tiempo haciendo uso de sesión, me empecé a encontrar con cierres de sesión inesperados.

Las primeras cosas que pensé fueron problemas de disco (suelen acarrear problemas aleatorios de memoria); errores en un refactor reciente de código que consistía en abstraer muchas llamadas a sesión; y problemas de memoria. Fui descartándolos todos, y me puse a pensar en un problema interno de la aplicación en la forma de gestionar la sesión.

Por ahí no encontré un problema, pero sí la razón de esas pérdidas de sesión. Estaba almacenando la IP del cliente como un valor más de la sesión; creo recordar que lo diseñé así para obtener más seguridad. El problema es que la conexión 3G con la que navegaba, cambiaba la IP constantemente. La aplicación cuando comprobaba que la IP de la sesión no correspondía con la del cliente, la cerraba.