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

24 de marzo, 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 primera parte de la charla

Hola. Me llamo Nate Koechley — soy ingeniero front de yahoo! Vamos a hablar sobre los profesionales del desarrollo de la interfaz. Es una disciplina un poco oscura, actualmente en desarrollo – incluso, en algunos sitios, no se conoce lo que hacen estos profesionales y la importancia del trabajo que desempeñan. Así que vamos a intentar aclarar algunas cuestiones y explicar lo qué hacen exactamente y cómo lo hacen.

El objetivo de esta charla es reiterar los valores fundamentales del desarrollo front, abogar por la disciplina y, así, ayudar a promover una web saludable. Vamos a dividir la charla en cuatro secciones. Primero, vamos a hablar un poco desde la perspectiva histórica — qué hemos sido y dónde nos encontramos ahora. Segundo, vamos a hablar sobre las creencias y fundamentos del desarrollo front. Después, vamos a adentrarnos con más detalle en las áreas de conocimiento de nuestro trabajo. Y, finalmente, voy a intentar hablar del por qué de esta materia.

Vamos pues, en primer lugar, con la perspectiva histórica. Creo que esta es la página principal de yahoo de 1994. Veréis que se trata de cuando Yahoo no tenía signo de exclamación. Y aquí debajo, sólo por curiosidad: 31.000 links en la base de datos… Pero, en cualquier caso, Internet ha recorrido un largo camino desde entonces. Una cosa a destacar en esta página, para la gente que está interesada en los estándares web, en el marcado semántico y cosas por el estilo, esta página es muy limpia desde dicha perspectiva. La cabecera, una serie de links, la lista de enlaces y categorías. Empezamos fuerte, pero ha pasado mucho tiempo desde entonces.

Esta es Yahoo! un par de años después, en 1996. Las primeras imágenes en la parte de arriba y, justo debajo, un enlace a la versión de sólo texto de Yahoo! nos indican que, desde el principio, Yahoo! ha empatizado con el usuario y con sus diferentes necesidades, y que ha procurado mantener un sitio accesible.

Poco tiempo después — en 1997. Un poco más de fidelidad en la página. Algunas imágenes más y mucho más contenido. Se comienza a ver tablas para desarrollar los primeros diseños de columnas múltiples — pero por lo general, muy parecido a como era dos años antes. Y esa tendencia continúa. En 2000, más contenido, más efectos visuales — resaltando bordes, usando colores en áreas diferentes. Pero aun así, fundamentalemente, la misma página que antes. Esa tendencia continúa — es 2001.

Y es al llegar a 2003 cuando comenzamos a ver algunas diferencias claras — mucho más control sobre el diseño visual, mayor control sobre la renderización de las listas, cabeceras y fondos de imagen — muchas más cosas dentro de una página. Y aquí tenemos el Yahoo! actual. La página de ahora, de principios de 2009. Una página compleja y sofisticada, con muchas oportunidades de interacción y personalización.

Así que si saltamos hacia la mitad de estos 14 años de historia, en 2001, podemos reflexionar sobre lo que Yahoo! era entonces. Yahoo! tenía siete años de historia, era una de los sitios web más grandes del mundo con 3000 personas empleadas — 0 de las cuales eran desarrolladores front. Así que construímos una gran sitio, con muchos servicios, visitada por gente de todo el mundo cada día, sin la ayuda de ingeniería front.

Comencemos desde este punto de inflexión y miremos hacia delante. En 2001, se contrató a los primeros desarrolladores front — gente especializada en gestión de navegadores, en construcción de interfaces de interacción con el usuario. Hoy en día hay, aproximadamente, 700 personas trabajando en Yahoo! como ingenieros front a tiempo completo, repartidas por nuestras oficinas a lo largo de todo el mundo.

En 2001, el sitio estaba construido a base de tablas, etiquetas de texto y experiencia muy estática. Hoy en día usamos marcado semántico y estándares para el diseño; el sitio es muy dinámico, muchas de las áreas están pensadas para su personalización — pero sigue siendo tan rápido como siempre. Hemos encontrado técnicas para poner más cosas en el sitio, dar al usuario mayor control y mantener la velocidad por la que se nos reconoce.

En 2001, el sitio web estaba disponible y accesible para todo el mundo — todo el marcado se pensó para que las personas pudieran interactuar con el contenido. Y hemos mantenido esta línea aunque se haya aumentado la sofisticación del sitio. En 2001 era un sitio muy básico y predecible — las pruebas eran un poco más fáciles porque había menos desarrollos y la experiencia era bastante estable y coherente en todo el mundo. En 2009, el sitio es muy, muy visual, muy adaptable y tan fiable como siempre.

Los usuarios evolucionan junto con la tecnología, y en 2001 había pocas expectativas sobre cómo un sitio web debería comportarse y cómo debía ser contruido. Las expectativas del usuario eran pocas. Hoy en día los usuarios se han sofisticado, tienen expectativas de cómo los sitios deben comportarse y qué servicios les deben ofrecer. Y esta interacción, la experiencia de usuario, puede ser muy compleja.

Por último, en 2001 la intersección entre el diseño y el desarrollo no se conocían — diferentes equipos trabajaban de formas diferentes, y la vinculación entre la gente de desarrollo front y la gente de desarrollo back se establecía al final en un proceso vago e indefinido. Y creo que estamos asistiendo al nacimiento de la ingeniería front como la intersección de ambas cosas.

Desde una perspectiva histórica diferente, Irene era la responsable del Departamento de Diseño y Experiencia del Usuario de Yahoo! así que ella fue la responsable de la contratación de los primeros desarrolladores front. Ella lo hizo para que les ayudasen a ofrecer un desarrollo más rico y adaptado a las nuevas demandas de los usuarios. Realmente, necesitaban crear un cuerpo de especialistas que llevasen a cabo este trabajo. La segunda motivación fue la de construir una disciplina definitoria para el trabajo que estaban desarrollando. En vez de limitarse a esperar que sucediera con el tiempo, queríamos tener un proceso riguroso y sacar el mayor partido a la tecnología, así tendríamos más flexibilidad y seríamos más eficientes en el camino.

No estoy seguro de cuántos recordaréis este libro — se llamaba “Creating Killer Web Sites” de David Siegel. Era muy conocido como libro que enseña a la gente a diseñar y crear sitios mediante el diseño de tablas que entonces estaba de moda. En el prefacio del libro, el autor escribía que “los maquetadores de la web veían las diferencias entre navegadores como algo beneficioso y creían que los usuarios elegirían cómo sus navegadores mostraban la página…” Y él tenía un problema con esto así que escribió que “quería más control sobre la página”, de forma que “tiró su libro de HTML a la basura para empezar desde cero”. Y esto está bien pero los navegadores van evolucionando, junto a la industria — no sabíamos cómo hacer todas las cosas que queríamos hacer y encontrar, así, formas de trabajar que estuvieran al orden del día.

Así que la web todavía se está recuperando de las decisiones erróneas y de los pilares defectuosos de la tecnología. Creo que, realmente, el desarrollador front es el radiólogo de la web — el que puede ver la enfermedad, comprender lo que está mal y encontrar un camino para hacer la web mejor.

Entrevista a Linus Torvalds – Parte I (quinta entrega)

11 de marzo, 2009 - por | | Kernel, Linux

Seguimos con la entrevista a Linus Torvalds. Si no has leído la cuarta entrega, ¿a qué esperas?.

Jim Zemlin: Una de las cosas de las que hablaste fue el incremento en la complejidad en la forma en que la interfaz interactúa con el núcleo y cómo los controladores del dispositivo son parte de ésta.

Yo me he preguntado muchas veces, algo que probablemente no te sorprenderá, ¿por qué no el núcleo tiene un controlador de dispositivo ABI estable?

Linus Torvalds: Bueno, la falta de una ABI tiene dos vertientes: una es que realmente, realmente, realmente no quiero una. Cada vez que la gente me pregunta por una ABI estable, creo que la razón principal para querer una ABI estable es que quieren tener su controladores binarios y que no quieren dar a conocer la fuente – no quieren fusionar su fuente con el Kernel o el núcleo estándar.

Esto, a su vez, significa que todas las personas que realmente trabajan en el Kernel no pueden, al mismo tiempo, trabajar con esa pieza de hardware y con los proveedores, ya que si hubiera cualquier error no podría arreglarlos.

Por lo tanto, todos los proveedores comerciales, incluso los que utilizan los controladores binarios, se están trasladando o alejando de los controladores binarios, ya que son completamente insostenibles.

Así que esta es una de las razones. Algunas personas creen que se trata de algo político. Y, probablemente, exista un aspecto político en esta decisión. Sin embargo, hay un aspecto mucho más pragmático y es que no se puede mantener.

Jim Zemlin: Esto suena como otro de esas cuestiones culturales por la que la gente parece apoyar los controladores binarios si hay beneficio sin entender, quizá, el beneficio de contribuir al soporte.

Linus Torvalds: Bueno, no se trata tanto del beneficio de la contribución al soporte como a la distribución del mismo. Quiero decir, puede que no termine teniendo el soporte de la mayoría de los dispositivos, pero acaba siendo el tipo de apoyo que necesito cuando tengo un gran problema.

Y cuando tienes ese tipo de sistema de apoyo distribuído – donde todo el mundo termina estando involucrado en algún momento -, no puedes darte el lujo de tener la situación en la que sólo unos pocos, de hecho, tienen acceso al código que puede estar causando el problema. Necesitas tener el código por ahí, no debido a cuestiones sociales, sino, simplemente, porque no sabes quién va a ser el que tiene que arreglarlo.

Así que hay una verdadera razón por la que necesitamos poder acceder al código fuente, lo que significa que para todos los desarrolladores del kernel, un interfaz binario es, básicamente, una mala cosa. No hay duda alguna.

Pero hay otra razón que es la que hace, realmente, que se desencadenen las cosas, de manera irremediable, en el interior del Kernel y que ha dado lugar al hecho de que, incluso aunque quisiéramos disponer de un interfaz binario, no podríamos. Y es que nos implicaría cambiar el cómo hacemos las cosas internamente.

Y esto es algo que ves en otros proyectos en los que, sí, tienen interfaces binarias por una u otra razón – muy a menudo debido a razones comerciales -. Esto significa que no pueden fijar un diseño fundamental. Ellos no sólo listan los interfaces binarios sino que también listan el diseño exacto tal y como se lo encontraron.

Además hay una segunda razón de peso por la que no se va a desarrollar una ABI estable; de hecho, significa que no garantizamos siquiera una API estable. Así, incluso a nivel de código fuente nosotros decimos: “Okay, este es el API, y si tú tienes drivers externos que la utilizan, te ayudaremos a corregirlos cuando tengamos que cambiar el API, pero no te garantizamos que el mismo API funcionará con todas las versiones”.

Fin de semana en el FOSDEM

11 de febrero, 2009 - por | 1 comentario | Open Source

Ya estamos de vuelta después de un ajetreado fin de semana en Bruselas. Que qué hacíamos allí. Pues además de pasar mucho frío, asistiendo al FOSDEM’09 (Conferencia Europea de Desarrolladores de Código Abierto y Libre) que este año se celebraba en la Universidad Libre de Bruselas.
Después de un largo paseo desde el aeropuerto de Charleroi hasta el norte de la capital belga, llegamos al pabellón central de la ULB donde se celebraba el evento. La multitud de gente que se concentraba en los pasillos del bloque H nos anunciaba que sería una experiencia super interesante tal y como intuíamos al ver el programa de charlas y talleres.
Pasillos repletos de gente
Con tanta cantidad de charlas al mismo tiempo nos costó decidirnos. Así que empezamos con KDE y seguimos con los desarrollos de embedded que nos resultaron muy interesantes y nos confirmaron en la idea de la necesidad de hacer desarrollos adaptados a cualquier dispositivo, ;-).
Aunque nos perdimos la fiesta de la cerveza del viernes que daba por inaugurada la sesión, pudimos difrutar de las hamburguesas con patatas fritas típicas de Bruselas en el Tropic Catering:
amburguesa y patatas fritas

Entrevista a Linus Torvalds – Parte I (cuarta entrega)

4 de febrero, 2009 - por | | Kernel, Linux

Seguimos con la entrevista a Linus Torvalds. Si no has leído la tercera entrega, ¿a qué esperas?.

Jim Zemlin: Vamos a hablar un poco más sobre el aspecto técnico del Kernel. Al principio el Kernel de Linux se utilizaba, fundamentalmente, para servidores. Claramente, ahora se utiliza para ordenadores de sobremesa y, cada vez más, para dispositivos móviles y sistemas embebidos. ¿Qué impacto tiene ésto en el Kernel a nivel técnico?

Linus Torvalds: De hecho, se espera más de un impacto. Resulta que los dispositivos móviles han crecido tanto o incluso más que los teléfonos celulares. De media, el teléfono inteligente, probablemente, tenga más potencia que el primer escritorio que se utilizó para ejecutar Linux. Además, no parece que su potencia vaya a parar.

Por lo tanto, creo que sobre todo en lo que respecta al Kernel, la gente se preocupa más de lo necesario. Lo más importante con respecto a los móviles no tiene que ver con el kernel. Quieres dispositivos más pequeños y eficientes. Así que lo que más preocupa al usuario es, en realidad, la interfaz.

Es muy diferente la forma en que te conectas con un teléfono móvil a cómo lo haces desde tu escritorio. Tienes un teclado muy limitado; algunos dispositivos con pantalla táctil; la pantalla suele ser muy pequeña. Así que creo que la cuestión fundamental tiene que ver con las interfaces de usuario.

Por ejemplo, tienes Qtopia que parece tener gran relevancia en el entorno de los móviles. El kernel, sin embargo, nunca ha vivido eso. Puede ser que esté simplificando las cosas y esté aislando algunos temas. Porque es verdad que existen todos esos grupos del kernel móvil con los que no interactúo directamente. Aunque sospecho que toda esa gente se preocupa más del “user space” que del kernel.

Jim Zemlin: Bueno, vamos a hablar de esta segunda parte en la que comentas el hecho de que hay muchos grupos del kernel para móvil. Y sabes que una de las cosas por las que la gente dice que es la razón por la que participan en el proceso de desarrollo de Linux y el código abierto es porque se trata de un trabajo colectivo que reduce costes y que permite, realmente, trabajar juntos de manera efectiva.

Y dado que existen, como ya sabes, este tipo de grupos que se desprenden de la comunidad, ¿qué se puede hacer para mejorar las prácticas cuando pertenecen a compañías de dispositivos móviles?

Linus Torvalds: Creo que el gran problema en el mundo del móvil tiende a ser que todo el mercado está acostumbrado a estar completamente parcelado. Todo el mundo hace algo único, una parte del hardware. Lo que ha hecho que, durante los últimos años, se escriba de nuevo el código y se desarrollen generaciones de móviles completamente nuevas.

Así, se puede invertir mucho tiempo en una generación de hardware que queda pronto obsoleta y se tiende a empezar, básicamente, desde cero para crear una nueva.

Y cuando se trabaja con esa mentalidad, es muy difícil hacer entender el hecho de que se trabaje siguiendo un determinado proceso e intentando integrar los estándares del kernel y de todo el proceso anterior, ya que ellos nunca han trabajado de esta manera.

Así que lo que hacen, realmente, muchos de estos fabricantes de móviles es elegir una versión, por lo general eligen la más reciente y se dicen, “bueno, esta es la base”. Después, durante cinco a seis años se aferran a esta plataforma y la mejoran según sus propias necesidades.

Y luego, cuando quieren hacer una nueva versión o una nueva generación de hardware, se encuentran con que el resto del mundo ha estado trabajando el algo novedoso así que todas sus modificaciones son para una versión que se ha quedado casi obsoleta. Y así, acaban haciendo lo que ya habían hecho antes. Tiran su trabajo por completo y comienzan de nuevo.

Y esto no es algo en lo que no podemos ayudar. Creo que el mercado del móvil, en cierta medida, para crecer necesita modificar este mal comportamiento.

Jim Zemlin: De alguna manera se trata de una cuestión cultural, no desde la perspectiva históricas ni geográfica; más bien desde una perspectiva comercial.

Linus Torvalds: Sí. Es una cuestión que tiene que ver con cierta cultura tanto técnica como comercial.

Favicon y estándares

22 de enero, 2009 - por | | Estándares

¿Cómo añadir un favicon a tu sitio web? es una de las entradas de la W3C recomendando su método preferido para poner el favicon en tu sitio web.

Un favicon es una imagen (icono) que se asocia con tu sitio. ¿Ves nuestro sombrerito en la barra de direcciones del navegador? Es nuestro favicon, ;-). Para añadir un favicon a tu sitio web la W3C recomienda que hagas una imagen de 16×16 ó 32×32 píxeles en formato PNG (un estándar del W3C), GIF o ICO. Después, la guardes dentro de tu árbol y la definas en la página con el valor del atributo rel=”icono”. Además, tendrás que definir qué tipo de imagen es y dónde la has colocado.

Ahí va un ejemplo para HTML 4.01:

PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"
xmlns="http://www.w3.org/1999/xhtml"
xml:lang="en-US"
lang="en-US";

type=”image/png”
href=”/somewhere/myicon.png” /;
[…]

[…]

[…]

[…]

Para XHTML 1.0 es muy parecido:

[…]
[…]

¡Vamos a intentarlo!

Entrevista a Linus Torvalds – Parte I (tercera entrega)

16 de enero, 2009 - por | | Kernel, Linux

Seguimos con la entrevista a Linus Torvalds. Si no has leído la primera y la segunda entrega, ¿a qué esperas?.

Jim Zemlin: Vamos a hablar sobre el proceso de desarrollo del kernel. Cómo es ahora y cómo ha cambiado a lo largo del tiempo. Tengo curiosidad en saber qué opinión te merece.

Hace algunos años se trataba de un proyecto divertido utilizado por unas pocas empresas y no estaba tan extendido como lo está hoy.

Ahora os habéis puesto en marcha con los dispositivos móviles, un campo de implementación enorme y especialmente crítico para las empresas interesadas en la industria; sólo esto supone una participación masiva desde un punto de vista comercial.

Si comparas entre ahora y entonces, ¿cómo ha cambiado el proceso de desarrollo? ¿Ha cambiado la gente? ¿Qué diferencias hay entre lo que se está haciendo y lo que se hacía, digamos, hace tres o cuatro años, cuando se encontraban en Transmeta?

Linus Torvalds: Yo creo que el proceso es, en gran parte, el mismo. Se ha producido algún cambio en los procesos y es de carácter puramente técnico en el sentido de que hemos hecho algunos más explícitos y existen herramientas que apoyan nuestra particular forma de hacer las cosas y que no existían de hace cinco a diez años.

Otra cosa que ha cambiado es que las personas involucradas están más implicadas y, quizás, son más conscientes de lo mucho que pueden fastidiar y el cuidado que tienen que tener – estoy pensando en mí en particular. Era, en cierta medida, más fácil hace diez años cuando podías decir, “- Ey, vamos a probar esto y si no funciona, no pasa nada.”

Ya no tenemos esa libertad; no podemos coger un código experimental completamente nuevo y decir: “- Ey, vamos a ver cómo funciona esto”.

Y como resultado, ahora tenemos múltiples capas de código que no van directamente en mi árbol. Si hay algo que es experimental se desarrolla en un árbol externo y, a continuación, se pasa a, por ejemplo, el árbol de Andrew Morton. Puede estar en su árbol un año hasta que se diga, “- Okey, todo funcionó en aquellos árboles. No se han hecho todas las pruebas porque aún no se ha estado en un árbol especializado, pero todo parece funcionar así que vamos a lanzarlo a un árbol principal”.

Así que hemos cambiado en esto. Muchas cosas han sucedido realmente porque se preveían los problemas. Así que se convirtió en una forma de trabajo. Estaba claro que mi árbol puede ser muy experimental lo cual, a su vez, motivó a otras personas a asumir el mando de otros árboles experimentales.

Jim Zemlin: En cierto modo lo que estás diciendo se parece mucho a cuando te casas para tener hijos y notas un aumento en el sentido de la responsabilidad.

Linus Torvalds: Cierto. Quiero decir que hasta cierto punto se trata de crecer y, sí, existen muchas similitudes aunque hay también muchas diferencias (risas), por lo que no sé si es del todo buena la analogía.

Jim Zemlin: No amas a la comunidad del Kernel, ¿verdad?

Linus Torvalds: Bueno, a algunas personas con las que trabajo, quiero decir, cuando se trabaja con personas durante cinco o diez años, quizá no las amas de esa manera pero, al menos, confías en ellos en un sentido muy real, a nivel personal.

Jim Zemlin: Una de las cosas que están pasando -para seguir hablando de la comunidad- es que Linux está empezando a ser más relevante en el mundo – ya sea por parte de los gobiernos que lo ven como una manera estratégica para crecer con la industria de software, como por los fabricantes de dispositivos móviles en Taipei, o (el proyecto) One Laptop Per Child, y otros.

Una de las cosas que la gente se pregunta es por qué no hay una participación en el proceso de desarrollo más global. En otras palabras, los observadores dicen que eso del kernel es muy de América del Norte o del centro de Europa.

Me interesa oir lo qué piensas: a) ¿por qué es así? y, b) ¿alguna idea sobre cómo podemos obtener más participación de gente de otros lugares.

Linus Torvalds: Bueno, hemos hecho algunos estudios, a lo largo de los últimos seis años para comprobar de dónde provienen los desarrolladores y una de las cosas más obvias es que no todos proceden de países muy poblados pero sí de países que tienen una mayor densidad de conexión a internet.

Quiero decir que puedes decir, con facilidad, que, sí, en China hay millones de personas, hay millones de personas en la India. Pero China e India no son representativas en la comunidad de desarrolladores.

Pero si realmente – en lugar de tener en cuenta únicamente el número de personas, tienes en cuenta el número de personas que tienen un buen acceso a Internet. China e India, simplemente, no son grandes en cuanto a la conectividad.

Jim Zemlin: Pero proporcionalmente, participan como mayoría o hay más…

Linus Torvalds: Hay otras muchas cuestiones y, claramente, la lengua y las barreras culturales son una de los grandes temas además de algo tan simple y evidente como la educación.

Así que las barreras lingüísticas tienden a ser un gran problema – bueno, en realidad, tal vez lo son más aún las diferencias culturales – para que tengamos a personas de los países asiáticos. En algunos de ellos Internet tienen gran presencia y educación, sin embargo, no contribuyen mucho al código abierto, ni al Kernel, ni a otros proyectos en general.

Y esto parece ser al menos en parte cultural y así es realmente difícil para personas con barreras culturales y lingüísticas participar activamente. Puede ocurrir. Pero seguramente esto explica muchas de las razones por las que Europa Occidental y los EE.UU. son los principales protagonistas en el área del desarrollo.

Jim Zemlin: Es algo en lo que la comunidad del núcleo del Kernel piensa. ¿Cómo podemos conseguir más gente implicada? ¿Cómo podemos hacer más fácil y más accesible la implicación de la gente?

Linus Torvalds: Aparece de vez en cuando. No creo que nadie sepa, realmente, la respuesta. Hemos añadido algunos documentos. Por lo general, del tipo “léame”: ¿dónde participar?, ¿cómo comportarse?; y que esté disponible en varios idiomas.

No sé si es la solución o no lo es. Sospecho que no. Pero también sospecho que puede hacer posible que más personas, al menos, echen un vistazo al proyecto. Tal vez las personas se asustan menos cuando pueden ver en qué consiste el proyecto en sí. Al menos, tratamos de acercarnos a ellos. Las personas en Asia podrían sentirse así, “Bueno, no estoy luchando por esto y puedo tener problemas” pero, por lo menos, pueden acceder a los conocimientos y desarrollarlos en cierta medida. Así pues, esta es una de las cosas que hemos estado viendo.

Con esto quiero decir que yo, realmente, creo que la barrera cultural es mayor que la barrera lingüística y la razón por la que digo esto es que, especialmente en América del Sur, la implicación en el proyecto ha sido alta, así que no se trata, necesariamente, en que todos hablen inglés. Creo que culturalmente están más cerca de Europa y de EE.UU., y es ésto lo que hace que nos sea más fácil entrar.

Por tanto – y como creo que se debe a diferencias culturales, no sabemos cómo enfocarlo.