Pat Eyler escribio:
Mientras estaba entrevistando a Zed Shaw, el hablo un monton de cosas buenas acerca de Luis Lavena, quien viene haciendo muy buen trabajo para Ruby en Win32.
Dado que no se mucho sobre Ruby en Windows (mas alla de cualquiera considerado un ciudadano de segunda clase), y mucho menos sobre Luis, decidi hablar con el para saber que estaba haciendo y como eso ayudaria a Ruby. Un pequeno intercambio de correos rapidamente se convirtio en una gran conversacion que deseaba compartir con ustedes.
Vamos al grano aca esta la entrevista traducida a algo parecido al español ;-)
Entrevistador (PE): Pat Eyler
Entrevistado (LL): Luis Lavena
PE. Luis, ¿cómo descubriste Ruby?
LL Descubri Ruby por primera vez cerca de 1999, cuando buscaba lenguajes portables (Windows y Linux) para migrar nuestras soluciones de escritorio.
Tiene estilo, es limpio, descriptivo y natural. En esa epoca Ruby no ofrecia un ORM o framework web, por lo cual no podiamos usarlo como plataforma para ese proyecto. Luego de un poco de analisis optamos por Python / Zope.
Aun asi, usabamos ruby internamente (primero sencillos scripts y luego Rake) para armar y automatizar todos nuestros procesos aqui.
Casi al final de 2004 necesitabamos cambiar el rumbo y empece a buscar alternativas. Escuche sobre Rails y que este usaba Ruby como lenguaje. Sin ver el screencast, saltamos directamente a ‘gem install’ y empezamos a jugar con el. Luego, encontramos el screencast, pero ya estabamos enamorados de Rails aun sin haberlo visto.
Dimos inicio al proceso de migracion de nuestras soluciones a Ruby (y Rails) a mediados de 2005 / un camino que no lamentamos para nada.
PE Me gusta Rake, y me alegra ver que tambien lo usas. Puedes darme algunos ejemplos de que manera lo utilizas?
LL Para muchas cosas: compilar nuestros programas y librerias (mayormente usamos FreeBASIC y un poco de VC); marcarlas dentro de subversion; armar distribuciones con los scripts de instalacion y otras herramientas; generar diferencias binarias (deltas) de los ejecutables contra versiones anteriores y subirlas a nuestro servidor de actualizaciones automaticas.
Para calmar nuestra sed por tests con lenguages compilables, creamos un par de herramientas que imitan Test::Unit de Ruby (les mencione que amamos Ruby?), y correr esos tests usando Rake antes de guardar esos cambios o distribuir las aplicaciones.
Cuando nos encontramos repitiendo un proceso, creamos un script de Rake en su lugar. Hasta lo empleamos para personalizar nuestro Windows XP en la oficina, integrando parches y generando las imagenes ISO.
PE Tu y tu equipo estan utilizando Ruby and Rails en ambiente de produccion. habiendo todavia mucha gente diciendo que no esta listo para el uso Empresarial (Enterprise). Estan equivocados? Que es lo que hace que funcione para ustedes?
LL Produccion y Empresarial / escuchamos muchas cosas sobre estas dos.
Me gustaria describir ambos terminos desde mi punto de vista (dado que ambos son subjetivos). Nosotros llamamos algo Production-ready cuando algo es estable, predecible y puede ser “vendido” (como un producto para mercados de tipo vertical). Diferentes aplicaciones tendran diferentes necesidades, por lo que un entorno de produccion para una empresa no sera el mismo para otra.
Desde el principio analizamos las opciones de “deploy” con Ruby para nuestros proyectos. Tal cual lo hacemos con otros frameworks y herramientas.
- WEBrick y sus goteras en el consumo de memoria se llevan un NO. Hasta el GC de Ruby (1.8.4) no es muy bueno para entornos de produccion.
- FastCGI es obsoleto e inestable. Solo basandose en esto alguien puede marcar a RoR como un juguete en lugar de lo que es: una poderosa herramienta
- Mongrel es una mezcla de Ruby y C que hace su trabajo y lo hace muy bien.
La gran palabra Empresarial es comunmente usada con Java, donde todo tiende a ser GRANDE para que las empresas gasten miles de dolares en licencias. Para mi, Empresarial significa “un producto que puede CRECER bien”. Nada dentro de las tecnologias de la informacion esta escrito en piedra, por lo que los requisitos pueden cambiar con el tiempo. El costo de responder a esos cambios debe ser minimo y no requerir cortes del servicio.
Ruby y RoR son buenas soluciones, solo se necesita conocer la plataforma. Muchas criticas sobre RoR vienen de personas que han jugado con el luego de ver el screencast, sin analisis serio, sin trabajo en produccion, sin optimizacion, nada. Preguntar sin fundamentos tendra respuestas vacias.
Para nosotros Ruby on Rails (RoR) nos permite armar de manera rapida y limpia (especialmente limpia) prototipos en horas o dias, no semanas o meses. Luego podemos ir desde el prototipo al producto final en semanas, aun para grandes proyectos (como migrar un sistema completo de Zope a RoR).
Puedo decir que Rails, y Ruby, cumplen con su trabajo, lo hacen bien, y de una manera elegante.
PE Dado que la mayoria de tu trabajo es sobre plataformas Windows, ¿como esto afecta tu punto de vista sobre Rails y Ruby? (¿O tu uso de ellos?)
LL Nos vemos forzados a usar Windows debido a requesitos de hardware especiales (las placas de usamos solo proveen controladores para win32).
Usar Ruby es un poco dificil, hay muchas soluciones en el mundo de unix/linux que abarcan desde balance de carga, servidores web, seguridad y enrutamiento de comunicaciones, herramientas de cache de memoria, etc. En Win32 debemos buscar, si existen, los equivalentes, e integralos con Ruby y Rails. Algunas veces debemos escribir nuestro propio software para cumplir con nuestras necesidades.
Algunos desarrolladores nos recomendarán que usemos cygwin, pero emular un entorno unix/linux en Windows no es productivo. Las herramientas nativas son la solucion mas rapida y estable. Ya tenemos nuestros bugs que rastrear, por lo que no deseamos gastar tiempo rastreando bugs en cosas que deberian ser consideradas estables.
Por suerte, nada de esto nos detuvo. Pero la falta de interes de algunos desarrolladores Open Source en proporcionar versiones funcionales para win32 retrasan todo el proceso. Esto es algo malo. Piensa un instante, ayudando a solucionar un problema de la herramienta en win32, no solo ayudan a la persona que lo reporto, sino que abre las puertas a otros desarrolladores a probar la solucion. Esto tambien amplia la base de usuarios, piensa en beta testers sin costo.
Por ejemplo: no podemos tomar ventaja de las funciones de balance de carga de lighttpd sin perder performance debido a cygwin. Usar Apache para una Intranet es como usar un mamut para limpiar las copas de cristal en tu casa.
PE Una de las cosas que dijo Zed sobre ti era que estabas trabajando mucho en mejorar Ruby y las librerias Ruby para la plataforma Win32. ¿Puedes decirme que es lo que estas haciendo?
LL Para ser honesto, no creo haber trabajado tanto. Actualmente necesitamos cubrir nuestros requisitos: servidor web, balance de carga, servicios win32, procedimientos de instalacion, comunicaciones de bajo nivel USB y Serial.
Incluir soporte para Win32 en muchos proyectos y librerias es sencillo. En otros proyectos requiere mas trabajo, muchas veces en el codigo y otras en los desarrolladores. Si es solo el codigo, aportar es sencillo. Cuando el desarrollador no puede (o no quiere) brindar soporte para Win32 decidimos tomar un enfoque radical / en lugar de clonar el proyecto, creamos nuestra propia implementacion.
Sabemos que haciendo esto reinventamos la rueda, pero en lugar de tratar de encajar soporte para Win32 en algun proyecto, podemos re-escribirlos completamente para ser independientes de la plataform hasta donde podemos probarlo.
No puedo comentar mucho sobre estos proyectos por ahora, pero estaremos ofreciendo alternativas (y algunas potentes) a otros usuarios encerrados en entornos Win32.
PE ¿Cuales son tus mayores retos con Ruby en Win32?
LL Bien, algunos proyectos que usan extensiones en C carecen de makefiles correctos o codigo para que puedan funcionar en win32 transparentemente. Por suerte, la manera en la que estan estructurados los proyectos en Ruby reduce la cantidad de veces que vemos estos escenarios, pero si existen y algunos requieren mucho hackeo.
Lo mejor de este proceso es la maravillosa comunidad que rodea a Ruby / rapidas respuestas de los desarrolladores (y usuarios) a preguntas sobre compilacion, buenas practicas, sugerencias y advertencias. Aun comentarios sobre bugs son tomados con buen humor! (algo que comunmente golpea el ego de los programadores)
Cual es el estatus de Ruby en Argentina y el resto de Sud America?
LL Para ser honesto, no puedo responder eso claramente. Veras, la mayoria de los lenguajes (Ruby, Python, etc.) y sus herramientas y frameworks (RoR, Zope, etc.) vienen de paginas, sitios y comunidades en ingles.
Los desarrolladores de habla hispana deben traducir la documentacion, syntaxis, blogs, tips, etc. para ser productivos con la herramienta/lenguaje. La cantidad de traduccion requerida deja al desarrollador con poca energia para contribuir a una comunidad hispana/latina que esta recien iniciandose.
No puedo decir que los usurios no tratan de superar esto, pero el problema existe, y la mayoria de los desarrolladores/programadores se ven intimidados por la barrera del idioma.
¿Ruby en Argentina? Bien, encontre algunos desarrolladores con cuales compartir. Mi creencia personal es que la necesidad (o hambre/sed) por nuevos lenguajes y tecnologias deberia ser estimulada en la universidad (al menos deberia aqui en Argentina). Algo que tomara unos años en producir resultados.
PE Cuales son tus 5 favoritos en librerias/frameworks para Ruby (asi sea en la standard library o fuera de ‘Net)?
LL Respondio en ningun orden en particular:
- RubyGems, para proveer distribucion en una forma standard.
- Rails, no necesito explicar por que es mi favorito no?
- Rake, task :resuelve_todo hazlo una_paso_por_vez fin (el texto original es: :solve_everything do one_step_at_time end)
- Mongrel, ofrece una simple y buena alternativa a nuestros problemas.
- Fire-Ruby, para buen acceso a un poderoso motor de base de datos.
PE Que es lo proximo en Ruby?
LL Lograr que YARV sea estable, entonces obtener un compilador JIT (JIT-compiler) para obtener mas velocidad en forma nativa.
PE Que es lo proximo en Ruby para Win32
LL RubyCLR como la punta del icebert respecto ruby y win32. La puerta abierta de Windows es atractiva para el desarrollador que desea herramientas cross-language (C#, BOO, otros) desde Ruby.
PE Que es lo proximo para ti?
LL Todavia tengo mucho trabajo por delante, pero espero mas adelante en este año lanzar nuestro producto principal, infoBOX, en dos plataformas: Windows o Linux, 100% compatible, tambien entre ellas. Despues de eso, Vacaciones!
Quienes son?
Luis Lavena tiene 26 años, nacido en Tucuman, Argentina. El se especializa en video digital profesional, desde la camara a los bits, como socio consultor de redes de cable y estaciones de TV con su empresa Multimedia Systems, un desarrollador de soluciones de software y hardware para los broadcasters.
Pat Eyler es un Ingeniero de Infrastructura Engineer para la LDS Church por profesion, un fanatico Ruby por eleccion, y un escritor por las noches. El disfruta leyendo, cocinando y pasando tiempo con su familia, y ayudando a construir la comunidad Ruby.
