Friday, July 11, 2008

Rails Brazil Summit 2008

Acaban de anunciar la conferencia Rails Brazil Summit 2008 que va a tomar lugar en São Paulo, Brazil, en los días 15 y 16 de Octubre, en el auditorio Elis Regina.

Contará con la participación de personas famosas en el área de Rails, los autores de varios libros: David Hansson (desde Europa en video online), Chad Fowler, Charles Nutter, Thomas Enebo, Ninh Bui, Hongli Lai, David Chelimsky, Chris Wanstrath, Dr. Nic Williams, Obie Fernandez, Jay Fields.

Habrá traducción simultánea de inglés y portugués al español durante el evento.

La página para registrarse será publicada a principios de Agosto. Hay que estar pendientes.

Mientras tanto, hay un questionario para determinar quiénes estarían visitando de los países latinoamericanos. Si ud está interesado(a) favor registrarse aquí.

Así que si tienen la oportunidad, no se lo pierdan !!! El mayor evento en el Hemisferio Sur, sin lugar a dudas.

Referencia:
AkitaOnRails
Rails Summit Latino-América
Encuesta para Latino-América

Monday, July 7, 2008

Insoshi

Insoshi, el software para una red social escrito en Rails, por el autor del libro Railspace.

Referencias:
Insoshi
Railspace.

Sunday, July 6, 2008

Ruby Kaigi 2008: Entrevista a Matz Matsumoto

Ruby Kaigi 2008, tuvo lugar en Tsukuba, Japón, entre el 20 y el 22 de Junio. Allí se reunió el comité ejecutivo de Ruby. Este artículo es una traducción del artículo aparecido en InfoQ Japón.

Este año, el tema de la conferencia fue "diversidad". Hoy vemos la emergencia de, no solo el interpretador Matz Ruby, sino otro número de proyectos, tales como JRuby y IronRuby, que son casi completamente compatibles con Matz Ruby. También vemos la adopción de Ruby por usuarios en las empresas, razón por la cual la conferencia ha añadido otro día a su agenda, el "Viernes de Negocios".

El primer día de la conferencia se llevó a cabo una discusión entre el creador de Ruby, Yukihiro "Matz" Matsumoto, y Eihiro Saishu sobre "cómo podemos usar a Ruby con los sistemas empresariales". Eihiro Saishu es el CEO de EC-One, una compañía de software que construye sistemas usando Java y Ruby. También es el fundador de Ruby Business Commons, una comunidad que promueve el uso de Ruby en los sistemas empresariales.

El primer tema de discusión fue sobre las razones por las cuales Ruby ha sido adoptado lentamente en el espacio empresarial. Algunas compañías grandes reúsan permitir a los programadores usar Ruby porque se lo percibe como una novedad con futuro incierto.

Eihiro Saishu dice: "A la fecha, se han construído sistemas con Java, pero una vez que he usado Ruby, he notado un cambio significativo en la motivación de los ingenieros y he esto ha resultado en un aumento de la productividad. El valor de venta de nuestros sistemas escritos en Ruby se estima cerca de los 4 millones de yenes [casi 37,500 dólares americanos]."

Matz comenta que "usuarios de áreas urbanas, tales como Tokyo, son más tercos en cuanto a los lenguajes que usan, mientras que usuarios de ciudades locales, tales como mi pueblo Shimane, usualmente no tienen preferencias fuertes sobre un lenguaje, siempre y cuando este satisfaga sus necesidades; a no ser que tenga un requisito especial, he estado usando Ruby por 10 años ya."

Matz y Eihiro Saishu concluyen que problemas de eficiencia usando Ruby usualmente tienen otras causas, tales como conecciones lentas a la base de datos, o Javascript, pero no son problemas con Ruby, per se. Matz añade que "es una lástima que la gente se deshace de Ruby diciendo que es un lenguaje lento, sin querer examinarlo con más cuidado". Sin embargo, él también admite que "no podemos negar el hecho de que Ruby sea más lento que otros lenguajes, tales como Java".

Seguidamente discutieron el papel del ingeniero Ruby, empezando por el reciente lanzamiento de la certificación "Asociación Ruby de Programadores Ruby Certificados". El primer examen es nivel Plata, ya disponible y le seguirán otros niveles más altos como Oro y Platino, en el futuro.

Matz dice que "de hecho, no necesitamos exámenes", pero continúa " es razonable tener exámenes para medir nuestra habilidad objetivamente". Eihiro Saishu añade: "Si el número de ingenieros que usan Ruby aumenta, el número de programadores que usen Ruby también aumentará. Esto significa que el valor relativo del programador Ruby decrecerá." Matz menciona que compañías en los EEUU están haciendo grandes cantidades de dinero con el incremento en la productividad que Ruby les da, y ya es hora de que las compañías japonesas empiecen a tomar ventaja de este hecho.

Matz cree que Ruby se encuentra en la posición donde estaba Java hace 10 años, donde la gente estaba bastante entusiasmada sobre este lenguaje. "Pero parece que este entusiasmo se está disipando. Estoy aspirando a mejorar a Ruby y a aumentar sus puntos a favor, al mismo tiempo que trataré de evitar los puntos negativos que ya han afectado a Java, de esta manera garantizando que Ruby seguirá siendo algo que entusiasme las mentes de los curiosos".

El primer día de la conferencia también tuvieron lugar las sesiones con patrocinadores, así como la sesión de la comunidad con Chad Fowler y Rich Kilmer.

La segunda parte de Ruby Kaigi 2008 tiene por objeto los planes para la estandarización de Ruby, el plan para la versión 1.9 y mención de algunas de las funciones planeadas para el versiones futuras.

Referencia:
Artículo en InfoQ (en inglés)
Artículo en InfoQ (en japonés, 日本語)

Noticias de Ruby Kaigi 2008: Estandarización

Estandarización

Yukihiro "Matz" Matsumoto expresó su intención de estandarizar a Ruby. El esfuerzo de estandarización será dirigido hacia la intención de mejorar la compatibilidad entre las diferentes implementaciones de Ruby, tales como JRuby y IronRuby, y facilitar el paso de Ruby hacia el gobierno japonés, que en el 2007 anunció guías sobre el uso de estándares abiertos (open standards) en lugar de productos específicos. Matz planea entregar el estándar a la organización ISO (International Organization for Standardization); sin embargo, no se ha definido una fecha concreta de cuándo esto sucederá, solo que "podría tomar, por lo menos, un par de años".

El Camino hacia Ruby 1.9x

El segundo día de la conferencia, Koichi Sasada—el creador de YARV—mostró un mapa para Ruby 1.9x y anunció sus planes para soltar la versión estable 1.9.1 en Diciembre de 2008. La versión corriente Ruby 1.9.0 fue siempre con la intención de ser usada para desarrollo [experimental], mientras que la versión 1.9.1 está planeada para ser la primera versión estable de la serie 1.9, y por lo tanto, se podrá usar en producción. En el mismo día, salieron las siguientes versiones actualizadas: 1.9.0-2, 1.8.7-p22, 1.8.6-p230, y 1.8.5-p231.

El plan para la versión 1.9 es como sigue:

* Julio 25: 1.9.0-3
* Agosto 25: 1.9.0-4
* Septiembre 25: 1.9.0-5 (feature freeze)
* Octubre 25: 1.9.0-6 (1.9.1 RC1)
* Noviembre 25: 1.9.0-7 (1.9.1 RC2)
* Diciembre 20: 1.9.1

El Siguiente Ruby

Koichi Sasada habló sobre las características posibles que se implementarían en versiones futuras de Ruby.

* Soporte para máquina virtual múltiple (MVM, Multiple virtual machine) de Ruby, por ejemplo, para poner a Ruby en los teléfonos celulares.
* Ruby Atómico: Poder compilar Ruby con los módulos necesarios solamente. Ruby Atómico se enfoca hacia los dispositivos embutidos (embedded).
* Byte Code Serialization: Como tecnología que permita Ruby Atómico, byte code serialization puede ser útil; puesto que no hay necesidad de analizar el código fuente, el parser no se requiere y se puede excluir de la compilación si se incluye el código serializado completo. Esto puede resultar ser útil para controladores de microprocesadores en dispositivos caseros o para distribuir el código hacia otros nodos de un cluster.
* Traductor de bytecode a C: usando la generación de código fuente a partir de bytecode se pueden aplicar optimizaciones que ya se conocen en compiladores C y facilitar plataformas que no tengan una implementación de Ruby.
* Optimización para números de punto flotante se puede tratar como un valor inmediato en máquinas de 64 bits: Comparado con el método de asegurar el número de punto flotante en la heap, esto permite reducir a la mitad la cuenta y hacerlo más rápido así como disminuir el número de actividades del colector de basura (garbage collector, GC). Estudios han demostrado que esto casi que duplica la eficiencia de la aritmética de punto flotante.
* Repasar la asignación de memoria (Memory Allocator) y el colector de basura (GC): Puesto que el costo del GC y la asignación de memoria ha aumentado con la introducción de YARV, parece válido considerar un GC en tiempo real o un GC compacto.
* De-optimización efectiva: En respuesta a la recarga de clases (class reloading) y la redefinición de métodos, el código compilado por JIT se puede restaurar para ser luego modificado.

Referencia:
http://www.infoq.com/news/2008/07/rubykaigi