Entradas en la categoría “Análisis”

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.

MVC en la web, la gran farsa de los arquitectos de software

En los entornos de desarrollo web es habitual referirse al patrón de diseño Modelo Vista Controlador (MVC) como la “forma correcta” de construir sitios/aplicaciones web. La realidad es que dicho patrón no se puede aplicar a la web tal y como se concibió, aunque su objetivo resulte útil y entronque con un principio general de diseño frecuente en distintos entornos de desarrollo de software: separar claramente las partes de un sistema. Así de sencillo. :)

Modelo-Vista-Controlador

El paradigma MVC, tal como se presentó originalmente, está pensado para aplicaciones estáticas como las que solemos manejar en un entorno de escritorio. Piensa por ejemplo en tu organizador de archivos (en Windows, en Mac o en Linux): te ofrece un buen número de botones, campos de entrada, controles de ventana, filtros, etc., que pueden ser presionados por ti en cualquier momento. Cuando lo haces, estás activando uno de los muchos “controladores”, su consecuente “modelo” para hacer lo que tiene que hacer, y finalmente actualizando una o más “vistas” que reflejarán el nuevo estado del “modelo”. En la implementación original la cosa quedaba descrita del siguiente modo:

The view manages the graphical and/or textual output to the portion of the bitmapped display that is allocated to its application. The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate. Finally, the model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller).

Es decir, el problema original al que se enfrentaba este “paradigma” era la simultaneidad, en un entorno de múltiples puntos de entrada (en forma de “controladores”) y múltiples puntos de salida (en forma de “vistas”). Lo que nos obliga a preguntarnos: ¿la web es un entorno de ese tipo? Evidentemente no. En la web manejas un sólo punto de entrada (request) y un sólo punto de salida (response), por lo que para empezar te encuentras con un patrón para el cual no dispones de un problema real sobre el que aplicarlo. :(

Pero además te encuentras con que las aplicaciones ideales para MVC son básicamente monousuarias y el modelo se mantiene en memoria mientras la aplicación está siendo ejecutada. Segundo elemento que no encontramos en la web: entorno típicamente multiusuario, donde el modelo para el usuario se regenera en cada request.

Si uno profundiza en las características del paradigma original se irá encontrando con más diferencias, que básicamente son fruto de estas dos básicas que he señalado.

Separa, separa, separa

Si el patrón original no puede ser aplicado realmente a los problemas típicos con los que nos enfrentamos en un entorno web, ¿qué es lo que podemos extraer de él? Sin duda alguna, su vocación por mantener separadas las partes de un sistema: es decir, pon tu código de datos en un lado, tu código de aplicación en otro, y tu código de presentación en otro. No suena a nada del otro mundo, dicho así; parece sentido común, y es al mismo tiempo una forma tradicional de desarrollo de software que encaja muy bien con trabajo en equipo y especializado.

Por lo tanto, no tiene sentido apelar a este patrón como una solución-para-todo, e incluso puede resultar contraproducente, puesto que se van a estar forzando las cosas (las palabras, los conceptos, etc.) y por lo tanto perdiendo perspectiva. Eso en el mejor de los casos; en el peor, se llegará a construir un problema ajustado al patrón y no a la inversa. :(

Autenticación en Django a través de Facebook, Gmail, Twitter, Yahoo y OpenID

26 de enero, 2011 - por | 2 comentarios | Análisis, Desarrollo

Cuando uno está montando un nuevo sitio en forma de directorio, suele partir de una base de contenidos a los que espera sumar otros procedentes de los usuarios. Esta acción por parte de los usuarios siempre es algo difícil de conseguir, porque en definitiva se trata de su tiempo y su esfuerzo. Y los procesos de registro/login no suelen ayudar a corregir ese esfuerzo, sino que con frecuencia lo agrandan.

Esto se hace particularmente grave en sitios que consideran que el índice de regreso de sus usuarios es muy bajo. En estos casos se suelen aceptar contenidos, al menos en una fase inicial, sin necesidad de registro. La contrapartida es que los contenidos quedan huérfanos y tienen menos credibilidad. El sitio en definitiva puede llegar a tener más contenidos, pero de menos calidad.

Yo suelo tener una opinión contraria a este tipo de planteamientos, porque: 1) nunca sabes completamente el tipo de usuario que vas a tener (tu índice de regreso no es algo infalible ni está distribuido de forma homogénea en el 100% de tus usuarios, por lo que puedes llegar a perder porcentajes pequeños pero significativos desde el punto de vista de su actividad); y 2) porque acabas aplazando al medio plazo la decisión inicial, y entonces te encuentras con la difícil de decisión de mezclar contenidos (unos huérfanos, los otros ya con autores), o de dejarlos para siempre tal como están. Creo que hay soluciones intermedias.

Una de las más populares es ofrecer el registro a través de terceros, es decir, de alguna herramienta que ya esté utilizando el usuario. La más popular es, sin duda, Facebook, pero podría ser Gmail, Twitter, Yahoo, o cualquier otro servicio en el que sepas que tus usuarios ya tienen una cuenta. De esa forma les evitas el tedioso proceso de crearse una cuenta (otra más) y al mismo tiempo no sacrificas la calidad de los contenidos desde el momento 0.

Si trabajas con Django, cuentas con Django-Socialauth, que ofrece login a través de los servicios mencionados y alguno más, menos frecuente eso sí, como OpenID. Además, permite importar contactos y ver cuáles están ya como usuarios del sitio.Y, por supuesto, junto a ésto siempre puedes ofrecer un registro clásico. No hay necesidad de sacrificar nada. :)

Charla de Nate Koechley, desarrollador front de Yahoo! – séptima entrega -

20 de julio, 2009 - por | | Análisis, Frontend

El 18 de marzo se publicó en YUI Theater la charla de Nate Koechley, primer ingeniero front de yahoo! Grosshat ha pensado que sería interesante traducir al español algunas partes con mucha sustancia de la transcripción de la charla, ya que resultan muy esclarecedoras sobre el desconocido papel que desempeña el desarrollador front en las empresas que se dedican a la web (frontend engineer en USA).

Nuestra traducción de la séptima parte de la charla

Ahora vamos a echarle un vistazo a la perspectiva histórica hablando sobre algunas de las creencias y principios. Me gustarÍa profundizar en algunas de las principales partes de la tecnología que tienen que tener en cuenta un ingeniero del interfaz.

Lo primero es el contenido de la capa: la capa HTML. Debe ser lo primero en el día a día de trabajo – queremos conseguir unas base sólida, antes de comenzar con otras partes tecnológicas. Antes de ponerte a escribir HTML tienes que definir en qué tipo de HTML vas a escribir mediante el doctype. ¿Qué es el doctype? El doctype es lo primero que aparece en un documento HTML. El elemento contiene una indicación sobre la definición del tipo de documento – lo cual sirve de indicación definitoria para el lector de la hoja, es decir, es una explicación de la tecnología que estás utilizando. En la práctica esto es importante porque da lugar a que los navegadores se comporten de modos diferentes. A principios de esta década, dado que los más modernos navegadores se estaban desarrollando, existía la preocupación de que si no se fijaban las singularidades de los viejos tiempos, los sitios que no se actualizasen podrían tener dificultades de renderización en los nuevos navegadores. Por lo que se quería ofrecer una forma de apoyar la idea de la compatibilidad con versiones anteriores, de sitios estrafalarios, a pesar de que los desarrolladores estaban empezando a crear más estándares basados en los sitios. Así que los vendedores de los navegadores eligieron el doctype como la forma de que los autores del documento – desarrolladores, fronted – optaran por alguno de los formatos existentes. En Yahoo!, utilizamos el HTML Estricto 4.01 DTD dentro de nuestro doctype, y esto, junto con varios otros doctypes, le dice al navegador el estándar que seguimos.

Una cosa más sobre el modo de los estándares vs al modo de las peculiaridades. Los navegadores realizan un gran trabajo como adivinos – somos capaces de lanzarles código propenso a errores pero los navegadores están diseñados para ser resistentes así que arreglan muchos de los fallos o hacen su mejor aproximación. Ellos hacen un buen trabajo de adivinación pero hacen un mejor trabajo si no tienen que adivinar en nuestro nombre. Así que como ingenieros fronted, nosostros debemos definir exactamente el lenguaje en el que escribimos – en este caso el HTML Estricto 4.01 – y eso nos asegurará obtener la mejor visualización posible.

La segunda cosa que me gustaría comentar sobre el marcado: ¿cuál es la presentación por defecto de los elementos HTML? ¿Cómo se pinta un elemento strong? ¿Y un H1? ¿Y una lista? Y son preguntas con trampa porque el marcado no tiene una presentación visual inherente – no hay nada en el HTML en sí mismo que diga que un elemento H1 tiene que ser grande y destacado y con mucho margen alrededor de él. Eso, en realidad, lo define la css dentro del navegador. Y así, darnos cuenta de que el marcado no tiene una visualización inherente nos libera para usarlo tal y como fue diseñado. El trabajo del marcado mejora el contenido de la página y se envuelve de aquellos elementos que le dan al contenido más significado. Podemos coger una cadena de texto y decir: esta es la cabecera. Podemos coger una serie de frases y decir: esto es una lista. Marcas lo que tienes y lo enriqueces con más significado.

Pero como ya he mencionado, los diferentes navegadores llaman al fichero interno CSS que nos proporciona la presentación de los elementos HTML, incluso de aquellos elementos que no forman parte del HTML en sí mismo. Esta es la razón por la que hemos creado, como parte de la librería YUI de Yahoo!, un fichero que se llama “CSS Reset”. Este fichero normaliza la presentación de los elementos HTML en diferentes navegadores. Si tienes un fichero CSS Reset, ya sea el de YUI o el que hayas desarrollado tú mismo, las páginas se van a ver iguales – hemos hecho que el navegador quiera usar nuestra preesentación inicial – reduciendo así el campo de juego. Así que en este caso ùedes cer que en la primera línea hay una cabecera h3 y, después, un h4, h5 y h6. Aquí obtenemos una lista y aquí otra. Y podríamos esperar que la lista se comportara con puntos o números – nosotros los hemos suprimido, así que sólo tratamos con HTML sin pensar en cómo podría verse en la página. Esto nos libera, realmente, y nos hace ocuparnos de qué elemento utilizar preocupándonos, únicamente, de su significado.

Charla de Nate Koechley, desarrollador front de Yahoo! – sexta entrega -

26 de junio, 2009 - por | | Análisis, Frontend

El 18 de marzo se publicó en YUI Theater la charla de Nate Koechley, primer ingeniero front de yahoo! Grosshat ha pensado que sería interesante traducir al español algunas partes con mucha sustancia de la transcripción de la charla, ya que resultan muy esclarecedoras sobre el desconocido papel que desempeña el desarrollador front en las empresas que se dedican a la web (frontend engineer en USA).

Nuestra traducción de la sexta parte de la charla

Así que estas son las tres técnicas básicas que nos ayudan a alcanzar o mantener nuestra mirada hacia las cuatro prioridades que se establecieron al principio. Hay un montón de opciones que deben tenerse en cuenta. Y queremos mostrar todas las opciones que apoyan nuestros principios – pero hay algunas otras cosas a tener en cuenta en función de la elección tecnológica del día a día de trabajo.

En primer lugar, siempre queremos hacer lo correcto. Y lo correcto significa seguir los estándares siempre que sea posible. Si existe un estándar, nuestro trabajo es seguirlo – si funciona, en nuestro caso. En algunos casos, todavía no existe un estándar o está surgiendo, y en esos casos está bien seguir las convenciones. Por lo tanto, si no podemos seguir el estándar – si no hay estándar definido – entonces, echaremos un vistazo a los estándares que están surgiendo o al convenio común que sigue la industria y tratar de hacerlo. Y sólo cuando esas cosas fallan – sólo cuando no podemos seguir un estándar y no puedes apoyarte en un estándar nuevo – entonces, vuelves a la mesa de dibujo y diseñas una técnica nueva para ese caso en particular. Como ingenieros, y diseñadores, existe siempre la tentación de reinventar algo nuevo y más ingenioso – pero para la salud de la Internet, y para la estabilidad de tu proyecto, es aconsejable seguir los estándares y los que van surgiendo siempre que sea posible. Si lo estás haciendo de cualquier forma – si vas por el camino menos visitado – entonces recuerda el principio de apertura y documenta lo que estás haciendo, y exponlo a discusión como posible estándar futuro.

Además de querer hacer lo correcto, siempre queremos ser considerados. Queremos ser considerado con nuestros compañeros desarrolladores, y con nuestros usuarios. Esto significa hacer la cosa lo más simple posible – no recibes puntos de bonificación por encontrar la forma más compleja que hacer algo. Hay por lo general la belleza en la simplicidad. La segunda forma de ser considerado es el ser flexibles. Tenemos diferentes propiedades en Yahoo!, así que cuando somos flexibles en el trabajo que hacemos, beneficia a otras personas de la empresa y del sector. Así que no se trata sólo de pensar en la valoración de los widgets para un sitio web de fotografía, también se trata de imaginar cómo se puede utilizar en un sitio web de cine, o en un blog, o en cualquier otro sitio. Así las cosas que flexibilizamos a través del contexto también se flexibilizan a través de la tecnología – las cosas que vas a trabajar para tu página se abren para todo el mundo. Y, al final, será considerado por estar abierto. Coger lo que hemos aprendido, documentarlo, y subir la API y los procesos que, por definición, están abiertos.

Lo último a tener en cuenta es el cómo tomar decisiones, es mantener el sentido de la empatía. Trabajamos al servicio de nuestros usuarios, y es nuestro trabajo ofrecer una experiencia de usuario fantástica – pero no es nuestro único objetivo. También tenemos que recordar que nuestro trabajo influye en los desarrolladores del sector y de nuestra empresa, y también lo hacen las máquinas que posibilitan estos sitios web. Determinados patrones de JavaScript son más comprensibles que otros, y así si es el mismo para el usuario y para el equipo de desarrolladores, debes elegir el que va a estar más optimizado para las máquinas. Pero recuerda siempre – a pesar de que hemos descrito los tres tipos de público, los usuarios son nuestra principal preocupación. Está bien entre nosotros sufrir un poco si es para dar al usuario una mejor experiencia, que es para lo que estamos aquí.

Nos publican en No Solo Usabilidad, :)

24 de junio, 2009 - por | | Análisis, Usabilidad

Hace unos días nos pusimos en contacto con Yusef Hassan que es co-fundador y director editorial No Solo Usabilidad, revista de Diseño Web centrado en el usuario. La idea era comentar un de mis trabajos de investigación para ver si le parecía interesante recogerlo en la revista.

El trabajo plantea la posibilidad de que la Usabilidad de las Nuevas Tecnologías de la Información y de la Comunicación (TIC) sea una variable interviniente en la Satisfacción del Usuario que trabaja con este tipo de herramientas.

El caso es que el equipo de la revista dio el visto bueno al resumen del trabajo y se publicó el 4 de junio de 2009. Puedes leer el artículo en No Solo Usabilidad.

Mi más sincero agradecimiento a todo el equipo de No Solo Usabilidad tanto por el interés mostrado por el trabajo en particular como por el que la Psicología Social y de las Organizaciones pueda abordar también estos temas.