Entradas de diciembre 2008

Entrevista a Linus Torvalds – Parte I (segunda entrega)

18 de diciembre, 2008 - por | 1 comentario | Kernel, Linux

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

Jim Zemlin: Pasemos a la organización en el desarrollo del proceso en sí mismo. ¿Conoces a las personas que están en el centro del proyecto y cómo se amplía en cuanto a los participantes que trabajan en el Kernel de Linux?

Linus Torvalds: Bueno, una de mis teorías favoritas es que la organización como un todo no existe en realidad y que en gran parte se trata de una auto organización. Lo que significa que no tenemos nada estricto – no hay reglas acerca de quién es realmente el de mantenimiento. Cuando tenemos a un encargado de mantener algún directorio en concreto, “esta persona está a cargo de ese subproyecto”, se trata más de una pista que de cualquier otra cosa. Esto significa que si tienes problemas con algo o si tienes un parche que quieres probar, esta persona en concreto es a la que puedes dirigirte.

Pero incluso esto es bastante impreciso y, al final, lo que ocurre es que se parece más a una red social en la que algunas personas están más conectadas que otras. Así que un parche no es un problema. Los informes se mueven por la red a través de las personas conectadas y finalmente me llega a mí o a otros que tienen gran número de conexiones con diferentes áreas.

Jim Zemlin: Así que, en muchos aspectos, la participación activa en el proceso de desarrollo tiene que ver con relaciones de confianza.

Linus Torvalds: Sí.

Jim Zemlin: ¿Es igual para todos los participantes?

Linus Torvalds: Sí. No importa lo duro que trabajes porque a nadie le va a importar. Podríamos decir que, como a veces sucede en política, lo que importa al final es que la gente te conozca. La gente conoce como una persona lleva trabajando en los últimos meses, años e incluso décadas y sabe que se puede confiar en ella. Cuando esta persona me envía un parche es, probablemente, el parche correcto, incluso cuando no entiendo bien el por qué de dicho desarrollo. Así se construye esta red.

Y como se trata de una auto-organización por lo general se evoluciona con el paso del tiempo. Así, la gente podría empezar por no estar muy conectada, pero a medida que demuestra ser bueno en una área determinada, aumenta la confianza en él y consigue estar más conectado, sin realmente – sin que exista un reconocimiento oficial.

Jim Zemlin: Vamos a hablar un poco de la comunidad y de este aspecto de la confianza. Me gustaría empezar por hacerte una pregunta acerca del término comunidad en sí mismo. Muchas personas utilizan el término comunidad cuando quieren decir, “-No lo hagas. Se romperá la comunidad” o “-La comunidad no acepta esta práctica”. ¿Cómo defines tú a la comunidad? Quiero decir, ¿cómo la entiendes?

Linus Torvalds: Yo, en realidad, trato de evitar el empleo de la palabra comunidad, ya que en muchos aspectos es engañosa. Es engañosa en el sentido de que no existe una única comunidad; todo el mundo tiende a tener sus propios temas que les preocupan y que pueden o no compartir con otras personas que, aparentemente, pertenecen a la misma comunidad.

Así que es engañoso pensar que la gente comparte ideales y objetivos, creo que no es cierto. Es más frecuente encontrarte con gente que tiene objetivos completamente diferentes; tienes comerciales que tienen muy claros sus objetivos de venta y tienes personas cuyo objetivo es el código abierto, pero todo pertenecen a la misma comunidad. Muchas veces te encuentras, además, con personas a las que realmente no les gustan las entidades comerciales, en especial, las grandes. Así que la mayoría de las veces los objetivos resultan ser muy diferentes.

Y la otra cuestión es que la comunidad tiende a ser -llega a ser- una entidad, y no sólo es percibida como tal, pero también puedes ver a gente que está dentro y fuera y que solía tener un papel específico – Creo que la mayoría de las compañías han empezado a aprender lentamente, pero solía ser un gran punto en el que todas las compañías hablaban acerca de “cómo interactuar con la comunidad”.

Y en algún momento la comunidad dejó de ser una suerte de entidad externa cuando la respuesta real siempre termina siendo que no interactúas con la comunidad; tú simplemente actúas como un miembro de esa comunidad no-existente. Realmente, no interactúas con ella, eres parte de ella.

Jim Zemlin: Esto es algo en lo que me gustaría profundizar ya que una gran cantidad de veces en la Fundación, las empresas se acercan y preguntan, “¿Cómo podemos participar en la comunidad? ¿Cómo podemos trabajar con la comunidad?” Y nuestra respuesta, similar a la suya, es la de “Pueden ser parte de la comunidad.”

¿Qué consejo darías a las empresas que quieren participar – no vamos a utilizar la palabra comunidad- en el desarrollo de los objetivos?

Linus Torvalds: Por lo general, quiero decir, la forma más fácil de participar es encontrar a la persona que ya es miembro del proceso de desarrollo, tal vez se trate de una persona que no es muy activa pero que lo es lo suficiente como para que haya estado involucrado y sepa cómo funcionan las cosas. Básicamente se trata de traer a esa persona de la empresa.

A menudo las personas, quiero decir, las empresas tienen ese tipo de personas ya dentro, sobre todo si se trata de empresas de tecnología que tienen interés por el kernel de Linux. De hecho, la razón por la que haya interés en el kernel de Linux probablemente tenga que ver con el tipo de gente que tienes trabajando para tí.

Así que, seguramente, ya haya gente dentro de la empresa que sepa cómo funcionan las cosas.

Jim Zemlin: Pero antes hablaste de la confianza y de por qué la confianza era importante en el sentido de la influencia que generas, en cierta medida, a la hora de que se cumplan los requerimientos de la comunidad.

A veces las empresas no piensan de esa forma. Ellos piensan, “Ey, si asigno gente para trabajar en esto e invierto recursos, tengo que cumplir mis objetivos.”

¿Cómo pueden estas organizaciones, en caso de asignar personal, generar esa confianza? ¿Qué deben decir a la gente de la empresa que participa fuera de ella?

Linus Torvalds: No sé si hay una respuesta a esa pregunta. (Risas) Si piensas que la forma de generar confianza es confiando en las relaciones personales, no sólo no obtienes dicha confianza si no que, además, no creas el ambiente. La confianza, exista o no, depende en gran parte de tus acciones.

Así que, la manera de generar confianza no es pensando en cómo hacerlo, sino tratando de asegurar que tus acciones sean más elocuentes que tu discurso. Tal vez tu estrategia interna sea lo de menos. Tus acciones externas son las que, en última instancia, generan o no confianza.

Entrevista a Linus Torvalds – Parte I (primera entrega)

10 de diciembre, 2008 - por | 1 comentario | Kernel, Linux

The Linux Foundation publicó en enero de este año una extensa entrevista a Linus Torvalds. Nos hemos animado a traducir el texto en español. ¡Aquí tienes la primera entrega!


Jim Zemlin: Bueno, quisiera comenzar haciéndote una primera pregunta. ¿Qué significa formar parte de la Fundación Linux?

Linus Torvalds: Para mí, lo que he estado haciendo durante los cuatro últimos años, que ha sido, por fín, dedicarme sólo a Linux, a tiempo completo. Antes yo tenía lo que se conoce como “trabajo verdadero” y del que vivíamos yo y mi familia. En aquel entonces, Linux era una especie de hobby y aunque mis jefes sabían de Linux y lo permitían, no era mi trabajo oficial.

Por eso hace cuatro años dije, básicamente, que necesitaba dedicarme a Linux a tiempo completo. Estaba dispuesto a hacerlo por mi cuenta y despedirme de Transmeta. Sin embargo, me encontré con que la empresa estaba dispuesta a apoyarme en todo lo que necesitara para hacerlo.

Así que, por lo que a mí se refiere, La Fundación Linux es la manera de no tener que preocuparme por la forma de alimentar a mi familia mientras hago lo que quiero y necesito.

Jim Zemlin: Genial. ¿Qué te motiva a trabajar en Linux?

Linus Torvalds: Bueno, solía ser únicamente la tecnología. Estaba interesado sólo en cómo el hardware trabajaba y cómo era la interación entre el software y el hardware. Y todavía, en parte, es así, aunque ahora también me motiva el aspecto social.

Quiero decir, me divierto trabajando con la gente. Incluso, aunque estoy todo el día sentado en mi sótano y sin ver a nadie, lo que hago es, esencialmente, comunicarme y éso es muy social: leo el correo electrónico de la gente y les contesto diciendo en qué pueden estar teniendo dificultades. Aunque no lo sea, intento ser cortés, animando a la gente y tratando de dirigirlos de forma correcta.

Jim Zemlin: Has dicho muchas veces que “Linux es sólo diversión” y que eso es lo que realmente te motiva a hacelo.

Linus Torvalds: Es cierto.

Jim Zemlin: ¿Ves Linux, el desarrollo de Linux, como una “gran causa”?

Linus Torvalds: No, no. No para mí. Quiero decir, para otras personas lo es. Me refiero a que una de las cosas que encuentro realmente interesante es cómo la gente utiliza Linux de formas en las que no pensé originalmente y a las que, a veces, yo no doy, personalmente, demasiada importancia.

Algunos creen que es el uso que la gente hace de Linux para favorecer a los países del tercer mundo y para ayudar a la humanidad, lo que me mantiene en el proyecto pero no. El reconocimiento debería corresponder a proyectos como OLPC que utilizan Linux para intentar mejorar el mundo desde una visión panorámica.

Para mí lo que me mantiene y me motiva sigue siendo la parte divertida -creo que es muy interesante y es esto a lo que me refiero cuando hablo de divertido. Parte de la diversión es que es lo suficientemente complejo para no ser insustancial. Así que el que sea divertido no significa que el asunto sea superficial. Sólo significa que es interesante y, al mismo tiempo, excitante.

Jim Zemlin: Hablemos de la parte en la que dices que es “lo suficientemente complejo para no ser insustancial.” Así que, hay un aspecto técnico…

Linus Torvalds: Sí.

Jim Zemlin:… que es complejo. Hay un aspecto social y de colaboración que también lo es. ¿Cuál es más complejo? ¿Son tan diferentes?

Linus Torvalds: Es complejo, quiero decir, ambos conviven y sólo se diferencian en que algunas veces la tecnología por sí sóla requiere un gran esfuerzo; la parte técnica es pocas veces frustrante. Así, la parte técnica suele ser más fácil en el sentido de que no te frustra. Bueno, hemos tenido un error y nos hemos comido la cabeza con un fallo técnico durante un par de meses. Y sí, ésto puede verse como algo frustrante. Sin embargo, siempre sabes que hay algo que puedes hacer para resolverlo y es así. Nunca me preocupo por la parte técnica.

El aspecto social es quizá un poco más complejo en el sentido de que, a veces, no puedes resolver los problemas de índole social y puede ser realmente frustrante ya que la gente se disgusta. También es muy interesante. Quiero decir, no sería tan divertido e interesante si todo el mundo fuese igual y trabajase en la misma dirección.

Son diferentes y van cambiando. A veces nos centramos en los problemas técnicos y otras veces, afortunadamente muy pocas, comienza una gran tormenta de índole social que desencadena otras cuestiones que la gente mantenía ocultas hasta ese momento.

Así que no hay una constante de cuestiones técnicas y sociales, sino que tienden a aparecer y desaparecer.

Jim Zemlin: Vamos profundizar en el tema de la interacción social, porque “open source” suele describirse como un proceso democrático en el que, como sabes, todo el mundo tiene algo que decir y hay un gran consenso; pero al final del día, es necesario tomar algún tipo de resolución cuando se trata de tomar decisiones. ¿Cómo os ponéis de acuerdo?

Linus Torvalds: Bueno, creo que no es realmente una democracia y algunas personas lo llaman meritocracia aunque tampoco es del todo correcto. Llevo la política de que el que hace el código puede decidir. Básicamente es lo que hay. Es muy fácil discutir y hablar de temas. y para mí, es fácil decir: ‘Debes resolverlo de esta forma.”

Pero al final del día, lo único que importa es el código concreto y la tecnología en sí misma. Las personas que no están dispuestas a escribir código, pueden formular comentarios y decir qué se debería hacer de una u otra manera o qué no harían. Pero, al final, estos comentarios no importan. Lo único que importa es el código.

Y resulta que la gente es perezosa, de modo que la mayoría son más felices discutiendo y, en la mayoría de los casos, sólo tienes un – un ejemplo de código y no hay muchas posibilidades reales de elección. No hay muchas personas lo suficientemente competentes como para hacer realidad el núcleo de programación y lo suficientemente poco perezosas como para que realmente lo desarrollen.

Así que de vez en cuando resulta que tenemos dos piezas de código que realmente hacen lo mismo o cosas similares de formas diferentes y, a continuación, llegar a la situación en la que alguien tiene que elegir y es muy a menudo y que me puede causar algunas social Con cuestiones que también. De hecho, es bastante inusual.

Jim Zemlin: Pero estás dispuesto a tomar esas decisiones cuando sea necesario, ¿verdad?

Linus Torvalds: Claro. Y de hecho, las cuestiones técnicas son bastante fáciles en el sentido de que si se terminan haciendo – tomando la decisión equivocada, se pueden deshacer. Sucede. Quiero decir, la gente dice, “bueno, tal vez sea la decisión correcta y, sin embargo, puedes estar totalmente equivocado”.

Tenemos que cambiarlo todo así que puede ser que, a veces, sea un poco doloroso. Pero como ya he dicho antes, no es frecuente tener que tomar grandes decisiones y, además, la mayoría de las veces la decisión no es el equivocada.

Bases para el desarrollo web

2 de diciembre, 2008 - por | | Análisis

Cualquier persona que ha participado de alguna forma en un proyecto web, conoce la enorme incertidumbre con la que se trabaja, a causa de las numerosas opciones que se barajan. Tomar una decisión sobre cualquier aspecto conlleva la necesidad -o la sensación de tenerla- de informarse y evaluar las distintas alternativas, a menudo sólo apoyándose en una metodología cualitativa difícil de formular conscientemente.

En todo ésto hay una parte, para mí, asumible de forma natural, que tiene que ver básicamente con el esfuerzo constante por innovar. Las tecnologías nacen para tener versiones, mejoras e incluso ser sustituidas por otras, con lo que los cambios -estructurales o por meras modas- son algo inevitable. Algunas personas piensan, además, que es positivo; y, por supuesto, hay otras que opinan justo lo contrario. La incertidumbre a la que me refería se mueve básicamente en esta parte.

Ahora bien, hay todo otro conjunto de cosas que, en mi opinión, son de naturaleza arquitectónica, y que por eso mismo no deberían verse comprometidas por las otras. Desgraciadamente, muchas veces son las partes más descuidadas de los proyectos, y los problemas que traen consigo suelen convertirse en críticos.

La primera cosa que suele descuidarse es el marcado HTML. Este descuido tiene consecuencias a todos los niveles, puesto que la web se apoya, intrínsecamente, en las estructuras de los documentos. Existe todavía una actitud bastante generalizada que concede poca importancia a este aspecto, produciendo una base de conocimiento muy pobre y poco rigurosa. Recientemente, Opera hacía públicos algunos datos recogidos a través de su herramienta MAMA, que cifraban en tan sólo un 4,13% los documentos existentes en la red validados correctamente. En este tipo de datos lo interesante no está tanto en las cifras, cuanto en la actitud que éstas reflejan.

El descuido en el marcado produce una reacción en cadena de descuidos que, en conjunto, afectan sustancialmente al documento.

Por un lado, existe un riesgo mayor de que estructura y presentación no se comporten como partes estancas, con lo que se incrementa la probabilidad de restringir y/o dificultar el acceso al documento (documentos más pesados, documentos no válidos para algunos dispositivos, etc.), así como de ofrecer un contenido menos significativo.

Por otro lado, aumenta la dificultad de incorporar comportamientos relacionados con el navegador, puesto que éstos se benefician de una estructura bien organizada y limpia de estilos. Ésto, a su vez, incrementa la posibilidad de restringir el acceso a causa de problemas con los dispositivos.

Asimismo, al disponer de un contenido menos significativo, disminuirá la capacidad de acceder a éste mediante búsquedas de patrones y/o semánticas. Lo que repercutirá, nuevamente, en restricción de acceso.

Más importante aún que todo ésto es que este tipo de actitud va en aumento según se desarrolla un proyecto, de forma que las pocas consideraciones que se tenían en el momento 0, han disminuido en el momento 5, y empiezan a considerarse como un problema en el momento 10. A partir de ahí se habrá invertido lo que debería ser el orden natural del proyecto, de forma que la web habrá pasado a considerarse un corsé demasiado pobre que necesariamente hay que forzar.

En ese punto penetrarán todos esos aspectos de la primera parte (tecnologías cambiantes, modas, etc.) desbordando sus límites naturales. En la historia de la web -que escribimos cada día- hay ejemplos de todo ésto -que todos vivimos diariamente- y se puede decir que prácticamente nadie está a salvo, y que es un ejercicio diario hacer el esfuerzo por mantener cada cosa en su sitio.

Merece la pena, puesto que ayuda a gestionar la incertidumbre que se mencionaba al principio, poniéndole límites, y evita la generación gratuita y progresiva de problemas y restricciones a todos los niveles.

Desarrollo con estándares web 2

2 de diciembre, 2008 - por | | Desarrollo, Estándares

Segunda parte de la traducción al español del texto de Roger Johansson: Developing With Web Standards – Recommendations and best practices.

¿Aún no leíste la primera parte?


3. Estándares web

¿Qué son los estándares web?

Los estándares web son tecnologías, establecidas por el W3C y otras instituciones de estándares, que son utilizadas para crear e interpretar contenido web. Dichas tecnologías están diseñadas para documentos-tipo futuros publicados en la web, y para hacer dichos documentos accesibles al mayor número de personas y dispositivos posibles.

Lenguajes para estructurar

Lenguajes de presentación

Modelos

Lenguajes de scripting

Este documento se centra en HTML 4.01 Strict para la estructura, CSS Nivel 1 y Nivel 2 para la presentación, y JavaScript para el scripting (aunque no se ofrecen muchos ejemplos de scripting).

Cuando se dice que un documento se adhiere a los estándares web, quiere decir que el documento además de hacer uso de las tecnologías referidas antes:

  • consiste en HTML o XHTML válido
  • utiliza CSS en vez de tablas para el layout
  • está propiamente estructurado y semánticamente marcado
  • funciona en cualquier navegador web

“Funciona en cualquier navegador web” no quiere decir “se ve igual en cualquier navegador web”. Hacer que un documento se muestre de forma idéntica a través de navegadores web y plataformas es prácticamente imposible. Incluso utilizando sólo imágenes tampoco se conseguirá que se muestre de forma idéntica en cualquier sitio.

Los documentos que son publicados en la web son consultados por una amplia variedad de dispositivos en diferentes sistemas operativos, con monitores de diferente resolución y calidad (o sin monitor, incluso), así como por usuarios que pueden haber cambiado el tamaño de fuente por defecto del navegador, así como otras preferencias.

Darse cuenta de ésto y aceptar que simplemente no puedes tener el control absoluto de la apariencia visual de un sitio web en los navegadores de tus usuarios hace que tu vida sea mucho menos frustrante. Cualquiera que crea sitios web necesita entender que existen prerequisitos técnicos a considerar, de la misma forma que aquellos que publican sobre papel o hacen películas o televisión tienen otros prerequisitos que considerar.

¿Necesita un sitio web comportarse exactamente igual en todos los navegadores?

¿Por qué utilizar estándares web?

Algunos desarrolladores y diseñadores web tienen resistencia respecto del uso de estándares web. Argumentos comunes son los de “…es demasiado difícil”, “…funciona en cualquier caso”, y “…los programas generan código inválido”.

Es fácil reaccionar emocionalmente y construir una resistencia hacia el aprendizaje de algo nuevo, que requiere que abandones técnicas que conoces y con las que te sientes cómodo. Sin embargo, si contemplas la situación de una forma lógica verás que hay muchos beneficios para aprender y utilizar estándares web. He aquí unos pocos:

  • desarrollo y mantenimiento más fáciles: Utilizar HTML más semántico y má estructurado hace mucho más fácil y rápido entender el código creado por cualquiera. Agradecerás, asimismo, cuando tengas que cambiar algo en tu propio código meses o años después de la primera vez que lo escribiste
  • compatibilidad con futuros navegadores web: cuando utilizas estándares definidos y código válido tus documentos pasan la prueba del futuro, reduciendo el riesgo de que futuros navegadores web no sean capaces de entender el código utilizado
  • descarga y renderización más rápidas de las páginas: utilizar CSS para la presentación tiende a aligerar los documentos HTML, lo que significa descargas más rápidas para los usuarios
  • mejor accesibilidad: HTML semántico, donde la estructura está separada de la presentación, hace más fácil para lectores de pantalla y dispositivos de navegación alternativos interpretar correctamente el contenido
  • mejor posicionamiento en los buscadores: la separación de contenido y presentación hace que el contenido represente una mayor parte del tamaño total del fichero. Combinado con marcado semántico ésto generalmente mejora el posicionamiento en los motores de búsqueda
  • adaptación más sencilla: un documento semánticamente marcado puede ser fácilmente adaptado para imprimir, así como para dispositivos de navegación alternativos, como dispositivos de mano y teléfonos móviles, simplemente enlazando a distintos ficheros CSS. Puedes, asimismo, hacer cambios que afectan a todo el sitio web editando un único fichero

El uso de estándares web ahorra tiempo y dinero para los creadores de sitios web, y en general aporta una mejor experiencia del usuario del sitio web.

Validación

Validación es el proceso de controlar que un documento se adhiere a las reglas del lenguaje de programación utilizado en el documento. Puedes compararlo chequeando un texto que has escrito para ver errores de “spelling”.

Asegurar la calidad a través de la validación es una importante parte del desarrollo web. Muchos errores que son difíciles de descubrir manualmente, son descubiertos durante la validación. Un error puede ser tan trivial como un error de escritura, o tan serio como un elemento o un atributo utilizados de un modo incorrecto. Puede no tener ningún efecto en la forma en que el documento es renderizado en un navegador web o desfigurarlo completamente.

Desgraciadamente, mucha gente no valida sus documentos. Algunas personas puede que no tengan conocimiento de la validación, otras llegan a olvidarlo, y hay otros que intencionadamente evitan la validación. Creo que esta situación se puede atribuir a las compañías de navegadores web. La mayoría de los navegadores web intentan interpretar HTML inválido de la mejor forma que pueden e intentan averiguar cuál es la intención del creador en vez de mostrar un mensaje de error. Es comprensible que los navegadores web quieran hacer tal cosa, pero esta tolerancia de errores es sin duda la principal razón para el (sloppy) marcado que es comúnactualmente.

¿Por qué no queremos ayudarte? es una explicación excelente de Mark Pilgrim sobre las ventajas de la validación. El artículo también explica por qué puede resultar más difícil conseguir ayuda de la gente en foros de discusión y listas de correo si no has validado tus documentos antes de preguntar.

Algunos editores HTML disponen de herramientas de validación ya listas o utilizan los servicios de validación del W3C, disponibles onlne. Puede utilizar los servicios de validación manualmente:

Otra herramienta excelente para chequear la validez del HTML que creas es la extensión HTML Validator para Firefox.

Comprender los mensajes de error generados por los validadores puede resultar un poco difícil. Un error inicial en un documento puede causar numerosos errores adicionales. Corrigiendo el primero y revalidando conseguirás reducir sustancialmente el número de errores.

Es importante tener en cuenta que la validez por sí sola no significa que el documento es accesible. Tampoco unos pocos de errores de validación hacen que necesariamente tu documento sea innaccesible o incompatible. Dicho ésto, deberías intentar siempre tener un código plenamente válido y tener una buena razón (tal como mejorar accesibilidad para la gente con discapacidades) para cualquier error que decidas dejar. Si las herramientas (editores de código, frameworks, editores WYSIWYG, sistemas de gestión de contenidos) que utilizas generan marcado inválido, son herramientas rotas que necesitan ser corregidas.

Para seguir leyendo