La Cultura Ruby – Evan Henshaw
Publicado el 9 de noviembre de 2011El año pasado La keynote de RubyConf Uruguay 2010 estuvo a cargo de Evan “rabble” Henshaw, uno de los co-organizadores de la conferencia. Un cierre excepcional para una conferencia excelente. La charla fue muy interesante e inspiradora.
Del blog de Evan:
La cultura importa. La diferencia entre las tecnologías y lenguajes son sus culturas. Define la forma en que la comunidad se estructura a sí misma, qué valora, los mitos de origen, la forma en que colabora, comparte y crea. Con esta charla intenté contar la historia de la cultura Ruby. También intenté inspirar a los programadores a ser participanres activos, a ser creadores – no consumidores de sus herramientas.
Su objetivo como co-organizador del evento fue construir un puente entre los mundos. Subir a la comunidad rioplatense a la movida de Ruby mundial. De 75 asistentes que esperaban, aparecieron más de 250.
A continuación comento un poco la conferencia, y les dejo el link para que vean el video:
Parte del objetivo de la conferencia era compartir la cultura de Ruby con el resto de la comunidad de desarrolladores de Montevideo. Para comenzar, habló un poco de la historia de Ruby:
“Ruby fue creado por Godzillas en Japón, y vinieron para destruir a todos los demás lenguajes de programación” comenta Evan. Si bien aclara que no es tan cierto, creo que es el verdadero origen de Ruby, pero los medios masivos de comunicación nos lo quieren ocultar…
Evan hablo sobre los orígenes de Ruby: cómo Matz, agarró cosas que le gustaban de Lisp, Smalltalk, Perl y Python. Quería un Perl más orientado a objetos que Python, y mientras diseñaba eso le metió Lisp y la programación funcional y lo orientación a objetos de Smalltalk. Él quería que la programación fuese divertida. Esto es parte de la cultura hacker que muchos intentan difundir, la idea de que trabajar no tiene que ser una carga sino algo divertido y enriquecedor, concepto con el que estoy completamente de acuerdo.
Otra idea que influyó en el diseño del lenguaje es el hecho de querer un lenguaje humano, haciendo que la computadora trabaje para nosotros y no al revés. Evan usó el término “esclavos” para referirse a las computadoras, ya que ellas fueron creadas por nosotros para servirnos.
Ruby fue exclusivamente japonés hasta 1999. Fue creado prácticamente aislado del mundo, y fue madurando y evolucionando dentro del país. Luego gracias a los “Language Design Geeks”, Ruby fue saliendo de Japón. Las bibliotecas entorno al lenguaje se encontraban en un estado tosco y sin terminar. Muchas bibliotecas eran migradas de otros lenguajes, pero sin usar las características de Ruby.
Pero hubo un personaje particularmente importante en la comunidad Ruby: _why the lucky stiff. Evan lo define como un programador de computadoras artista surreal. El lanzamiento de su libro why’s poignant guide to ruby introdujo Ruby al idioma inglés. Ya he comentado sobre este libro antes en el blog, y es uno de los que he usado para estudiar Ruby 🙂
Además de su famoso libro, también escribió varias bibliotecas importantes en Ruby como hpricot, Camping (un framework MVC de 4kb), RedCloth, Shoes, y herramientas online imprescindibles que introdujeron a muchos programadores a Ruby como Hackety Hack y Try Ruby. Todo esto hasta que un día desapareció, y nunca se volvió a saber de él…
En 2002 / 2003, apareció Rails. El primer intento fue hecho con PHP, pero no funcionó. La implementación de orientación a objetos y la filosofía del lenguaje no eran compatibles con lo que quería hacer. Al ser creado en Ruby, apareció un punto de inflexión en la historia del desarrollo web. Hubo un antes y un después de Ruby On Rails. cambió la forma en que pensamos en desarrollo web, cambió qué se considera aceptable y cuestionó la idea del gigantesco stack Java. Obligó a cada lenguaje y cada plataforma a reestructurar su forma de trabajo.
Compara el éxito de Rails con django, comentando que la comunidad Ruby aprendió a ser evangelizadora. Los desarrolladores django, no son “mesías”, y la comunidad Ruby y Rails se veía así al principio. Escribían, publicaban screenscasts, publicaban blogs, y evangelizaban Ruby como el mejor lenguaje. Comenta que esa actitud no venía del solo hecho de que Ruby fuera mejor, sino que se sentía mejor. Hacía que la gente estuviera contenta, como una droga. Un lenguaje divertido, humano, que se puede moldear como plasticina.
Parte del éxito se debió también a que se originó en 37 Signals, empresa que tiene la promoción como uno de sus negocios. Otro factor importante fue el cambio que se dió, de ser un lenguaje usado por los geeks de los lenguajes a ser usado por los diseñadores web. Para ellos, personas interesadas en la estética, Ruby mostró un nuevo mundo. El lenguaje le da posibilidades distintas, de que puede ser divertido y fácil.
Rails es software dogmático. Dice “tengo una forma de hacer las cosas y creo que está bien, y voy a poner mi nombre y valores sobre eso. No voy a intentar defenderlo porque crea que es mejor tecnología, lo voy a defender porque creo que está bien, lo voy a defender porque se siente mejor. Es mi opinión, y no alguna medida objetiva”.
Esta nueva comunidad de desarrolladores fueron rebeldes. Como una comunidad punk rock del código, llegaron y dijeron “vamos a quemar los edificios de lo establecido y desarrollar una forma nueva de hacer las cosas”.
Mencionó una de las cosas que separa a Ruby de otros lenguajes: Monkey Patching. Básicamente, en runtime abrimos las clases de otras personas y reemplazamos sus métodos o le agregamos nuevos. Uno puede reescribir, eliminar o renombrar un método de otro. Algo que estaría tan mal en otros tantos lenguajes (y realmente molesta a los desarrolladores Python), es aceptable en Ruby. Ruby alienta esta libertad.
Evan siguió hablando de los tres lenguajes de scripting con los que ha trabajado profesionalmente (y está dispuesto a admitir). Perl, Python y Ruby, tres lenguajes con una filosofía propia. La filosofía Perl, es que hay más de una forma de hacer las cosas. Y no te va a decir cómo hacerlas, lleva a la discusión y los flamewars sobre cómo es mejor hacer cada cosa. Comenta que el lenguaje desarrolló una comunidad en línea muy enojada, gente que mandaba a leer el manual muy seguido. El manual tiene miles de páginas, porque la comunidad Perl quería tirarle el libro por la cabeza a la gente para no tener que discutir cómo hacer las cosas.
Python le sigue a Perl, y su filosofía es muy diferente. Ellos creen que hay una forma correcta de hacer las cosas, le gustan los estándares y las especificaciones. Cuando instalas Python, obtienes todo lo que necesitas y si alguna de esas cosas son lo que crees que necesitas, si no te gusta cómo funciona una biblioteca, estás equivocado. Y no hay forma de discutir sin escribir una especificación.
Luego le sigue Ruby, según Evan “la mezcla perfecta”. Ruby dice “hay una forma mejor de hacer las cosas”, “decidiremos cuál es la forma correcta, la mejor forma de hacerlo escribiendo código que funcione”. Hay una frase en el software libre “no creemos en reyes, presidentes o votar, creemos en consensos aproximados y código que funciona”. Y eso es lo que hace funcionar a varias comundiades como la del software libre y la de los desarrolladores. Esto se lleva profundamente arraigado en la cultura Ruby.
Varios desarrolladores escriben distintas formas de hacer lo mismo, porque están averiguando cuál es la mejor forma de hacer algo. Y la gente resuelve sus conflictos con código funcional. Siguió con una frase de Kent Beck – co creador de Extreme Programming y TDD, sobre Smalltalk. Ruby es la realización de la promesa de Smalltalk en una sintaxis y formato usable.
Su naturaleza Open Source lo convierte en un entorno un poco caótico y desordenado. Existen varias implementaciones del lenguaje, mucha gente trabajando en cosas distintas. Pero la comunidad desarrolló procesos internos para procesar los cambios.
Otro hito mayor de la comunidad Ruby ha sido abrazar el uso de Git, el sistema distribuido de control de versiones. GitHub, proveniente de la comunidad Ruby, ha cambiado la forma en que se desarrolla software, y cómo se mantiene el software libre. Le quita el poder a un equipo central o un “dictador benévolo”, hace muy sencilla la tarea de crear un fork y mantenerlo. Esto fue hecho aceptable y entendible por la comunidad Ruby.
Así se llega a una política de compromiso abierta. Comentó una experiencia que había leído de un desarrollador .net trabajando con un framework a lo Rails de Microsoft. Los desarrolladores tienen permiso de mirar el código, y pueden crear un parche y enviarlo por correo o a través de un formulario. Los desarrolladores originales del framework pueden elegir en algún momento mirar o tomar en cuenta ese parche.
Esto hace que los desarrolladores no tengan ningún control o influencia sobre el código. Están trabajando con las herramientas de otra persona, y no son dueños de su propio ambiente. Básicamente son esclavos del trabajo de otra persona. En la comunidad Ruby, uno puede controlar y ser dueño de sus herramientas. De esta manera uno se crea su espacio como desarrollador, y no se limita en lo que puede hacer creando e innovando con algo nuevo.
La manera de participar, es simplemente empezar. Escribir código, encontrar aplicaciones por ahí, buscar tickets abiertos en GitHub, y contribuir a la comunidad. Las exigencias para entrar son muy bajas. Nombró a algunas personas de la comunidad uruguaya de desarrolladores Ruby que ya lo han hecho: Nicolás Sanguinetti quien escribió un sistema de integración continua Integrity que ahora es mantenido por la comunidad y Santiago Pastorino, quien integra el equipo de desarrollo de Rails Core.
Evan arengó a los desarrolladores presentes a inspirarse en ellos: “No tenemos que consumir estas herramientas, tenemos que darles forma y construirlas”.
La charla siguió con el surgimiento de Ruby Sur. Las comunidades de Argentina, Uruguay y Chile estaban aisladas cada una con su lista de correo. Lo que surgió como la unión de las listas de correo en ese momento, creció a organizar la Gira Ruby Sur en conjunto este año. Como mensaje final, Evan mostró un cartel con las palabras “Sí, se puede”.
Debo decir que la charla cumplió su objetivo. Si bien parte de lo que se habló, ya lo había leído, recuerdo que tuvo un impacto en su momento. Los invito a asistir este año a la conferencia y comprobar por ustedes mismos que la cultura Ruby es así como Evan la describió. Una impresión que me llevé de la conferencia anterior fue sobre algo que leí muchas veces pero es dificil asumir: Los programadores Ruby parecen más felices que el resto. Evan va a estar dando la charla Lean startups for the Ruby Hacker.
Dejo otras palabras del blog de Evan refiriéndose a esta charla:
La tecnología que creamos no está aislada y mecánica. Es un reflejo de los valores, limitaciones y aspiraciones de sus creadores. La tecnología libre y Open Source es todavía más un esfuerzo de la comunidad. Necesitamos entender la historia y la cultura de nuestras creaciones. Por una vez, me gustaría reconocer que la cultura de la tecnología es tan importante como su implementación. Las implementaciones rotas son mas fáciles de arreglar que las culturas rotas.
Ruby Conf Uruguay 2011
RubyConf Uruguay se celebra nuevamente este viernes 11 y sábado 12 de noviembre. La agenda es sumamente interesante con traducción simultánea inglés-español y viceversa.
El evento se llevará a cabo en el auditorio de la Torre de las Telecomunicaciones, en una de las salas más modernas de Montevideo preparada para eventos como este. El auditorio está preparado para que todos estemos cómodos y habrá Wi-Fi para mantener nuestra adicción a internet.
Si todavía no lo han hecho, pueden registrarse en este enlace.
PSeigal 13 noviembre. 2011 - 16:25
Excelente post, no he leído un artículo tan completo como este en otro sitio.
Fernando 14 noviembre. 2011 - 00:46
Gracias, me alegro que haya gustado pero el mérito es de Evan por inspirarlo.
¡Saludos!
L. Jacob 19 enero. 2017 - 16:58
Muy interesante. Le comunicó que encontré una pequeña errata, en: “…Nicolás Sanguinetti quien escribió un sistema un sistema de integración contínua Integrity” bueno si sumamos el acento en “contínua” serían dos. Saludos
Fernando 19 enero. 2017 - 23:02
Gracias por avisar del error. Quedó corregido, saludos!