Entradas de marzo 2009

Empezamos a poner las bases de allcool.es

31 de marzo, 2009 - por | | Proyectos

Ayer volvimos a juntarnos con los amigos de Allcool. Teníamos que revisar la propuesta que les habíamos hecho y hablar un poco sobre la estructura de contenidos hacia la que les gustaría orientarse. La reunión fue muy provechosa, aunque implicó varias conclusiones que afectan sustancialmente a la idea original.

La primera vez que la gente de Allcool se puso en contacto con nosotros, nos transmitieron el deseo de disponer de una tiena online. Nuestra propuesta fue la siguiente: plantearse la tienda online en el medio/largo plazo, para cuando ya dispusiesen de un espacio de contenidos de referencia en la red. Para conseguir ese espacio les construimos un prototipo funcional corriendo sobre WordPress, que les permitía manejarlo todo -incluidos los productos- en forma de entradas, y donde todo el trabajo recaía en la redacción y categorización de contenidos.

Las ventajas de nuestro planteamiento eran muchas:

  • durante todo el proceso de generación de contenidos, la gente de Allcool podía ir adquiriendo familiaridad con la red, que es la base sobre la que Grosshat construye sus proyectos;
  • al mismo tiempo, el manejo dinámico de las entradas categorizadas permitía construir con facilidad un sitio dinámico apoyado esencialmente en la recogida de las entradas a partir de distintos criterios;
  • a su vez, Allcool podía ir así generando una marca de identidad en la red, que significara para sus usuarios/clientes un punto de referencia fácil y con información actualizada e indexada

El inconveniente principal que implicaba este planteamiento, y que precisamente discutimos ayer, es la integración futura (a medio/largo plazo) con la tienda online. Dicha integración implicaría seguramente duplicar parte del trabajo y obligar al usuario a manejarse en 2 entornos diferenciados pero al fin y al cabo con la misma sustancia. Podéis haceros una idea más fiel de ese planteamiento inicial en su versión prototipo-beta (usuario:ladiversidad, password:eshermosa).

La alternativa que pensamos ayer es la de construir desde el principio un espacio de información como tienda online. A la gente de Allcool les gusta el modelo de Amazon, donde la orientación hacia el proceso de compra no sacrifica el contenido y su calidad.

Así que hemos tenido que desechar el prototipo funcional primero, para ponernos a probar varios gestores open source de tienda online. Ya conocemos algunos, pero tenemos que verlos un poco más en detalle para ver cuál nos puede dar ese margen en el largo plazo para no quedarnos únicamente en la mera catalogación + carrito. Precisamente, lo que Grosshat ha querido evitar desde el principio es caer en el poco exitoso proceso de crear una tienda online con apenas información y sin tener apenas una comunidad en la red.

Lo que sí mantendremos, en cualquier caso, será un blog como el corazón de la generación de contenidos que no sean específicamente productos.

Si tenéis ideas, experiencias y cuestiones, os las agradeceremos un montón. :)

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

30 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 segunda parte de la charla

Una cuestión básica: ¿qué es exactamente un desarrollador front? Hay varias formas de definirlo y más adelante veremos qué hace. Una forma simple de definir lo qué hacemos es diciendo que somos aquel

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”.