No se porqué escribí el título en inglés, pero bueno un poco tarde pero seguro.

Hoy en Bangalore nos juntamos algunos de los que andamos con esto de Ruby y Rails en Argentina.

Donde?

En humboldt y Niceto Vega en un bar muy lindo que se llama Bangalore, buena cerveza, buena musica, y mucho geek para hoy.

Nos vemos ahí

P

Nuevito, recien inagurado por nuestro amigo del otro lado del charco Diego Algorta Casamayou el Grupo de Usuarios Ruby de Uruguay Ya que los argentinos somos un virus maligno que se esparce por todo el mundo, podemos participar no? :-D

Exitos y mantenganos informados y a ver si cruzamos el charco a dar alguna que otra charla o workshop.

El entusiasmo se debe a que este switcher por fin puede instalar Rails 2.0 en su nueva MacBook usando sólo MacPorts. Dejemos que comparta su alegría con todos nosotros. ¿Alguien más puede aportar su experiencia instalando Rails 2.0 en OSX con Fink? ¿O todos aquí instalan RubyGens "a mano"?

Algunos ya lo saben, otros no, para los que no, nuestro querido amigo Luis Lavena, es el responsable del RubyOneClickInstaller. Este hacker argento ha logrado grandes cosas en varios asptactos, como poder desacoplar a Ruby de las dependencias del Microsoft VC6 pasando ahora a MINGW!

Admirable lo suyo Luis!

Todo nuestro apoyo con el proyecto!

Hace tiempo hablamos de FixtureReplacement . En ese entonces tuve toda la intensión de utilizarlo, pero me encontré con un dilema. No soportaba namespaces. Le escribí el flaco que lo desarrlló, intercambiamos algunas líneas, y al mes me comentó la novedad: Finalmente soporta namespaces.

O sea que si ahora tenemos un modelo Admin::Rol, podemos especificar la factory de la siguiente manera:

module FixtureReplacement
    attributes_for :admin_rol, :class => Admin::Rol do |rol|
      rol.nombre = "Guarda"
      rol.permisos << create_admin_permiso
      rol.permisos << create_admin_permiso(:nombre => "Sonar Silbato")
    end

    attributes_for :admin_permiso, :class => Admin::Permiso do |p|
      p.nombre = "Cortar Boletos"
    end
  end

Esto hace la práctica de BDD y TDD mucho más amena.

Más información aquí

Hace unos meses comencé a trabajar en un proyecto bastante grande. Éste se compone de varias aplicaciones Rails. Cada aplicación usa algunos plugins típicos como el acts_as_list, acts_as_tree y el acts_as_authenticated, además de otros desarrollados por nosotros. El gran punto fue como mantener todas las versiones de los plugins actualizadas. Para este inconveniente decidí en principio usar la propiedad svn:external de Subversion, pero rapidamente me pareció que no escalaba, al menos para lo que yo necesitaba. Miré un poco por ahí, y me acordé de lo que me había comentado Luis alguna vez: Piston.

Ventajas de utilizar Piston:

• El código externo se guarda en un único repositorio. Esto disminuye la probabilidad de error al momento del deploy usando Capistrano, ya que la caida de algun repo externo no tiene efecto en el deploy de la aplicación.
• Las actualizaciones de los componentes externos del repositorio se actualizan cuando uno lo decide, y no cuando se hace svn update.
• Está escrito en Ruby.

Vamos a los bifes:

Instalar Pistón:

sudo gem install -y piston 

Importación de un recurso externo.

cd MI_APP_RAILS

Si el recurso usa svn:external simplemente es necesario ejecutar:

piston convert

En cambio, si se los copiaron previamente, es necesario removerlos primero.

svn rm vendor/plugins/labeled_form_helper
$ svn commit vendor/plugins/labeled_form_helper -m "Labeled Form Helper eliminado provisoriamente" 

Y luego importarlos con el siguiente comando:

piston import http://svn.techno-weenie.net/projects/plugins/labeled_form_helper/ vendor/plugins/labeled_form_helper
svn commit vendor/plugins/labeled_form_helper -m "Labeled Form Helper Pistoneado" 

Para ver los recursos que Piston maneja:

piston status

Para ver actualizar todos los recursos:

piston update

Simple, no?

NOTA: El Piston no realiza commit de nada. Solo trabaja con la copia actual. Así que después de cada operación, si están conformes con los resultados, solo… svn commit ….

El funcionamiento de Piston es simple. Piston guarda en cada carpeta monitoreada por él unas propiedades (svn) que le indican adonde tiene que ir a buscar la información de actualización a la hora de ejecutar: piston update.

Más información puede ser encontrada aquí.

Recordando Programadores matando a un Dragón se me ocurrió la analogía de los lenguajes de programación como mujeres.

Aqui va la idea, sumen más lenguajes si se les ocurre.

Ruby: Ella es sexy, simple, dinámica, sensual y seductora. Podés ir a cualquier lado con ella ya que socialmente se comporta muy bien. Es clara y transparente aunque muchos la ven poco seria para llevarla al altar. Se adapta muy bien a los cambios y puede acompañarte en todo. Ella es 100% pasión. Recomendable para algo apasionado, sincero, claro y social.

Smalltalk: Dicen que es la más hermosa, pero socialmente tiene muchos problemas: sólo se junta con las de su clase y desvaloriza al resto. Es introvertida, pero si querés una mujer realmente bella y sensual creo que es ella. Es muy dinámica y en su ambiente es lo más. Los que se enamoran de ella quedan de esa forma de por vida y se van a vivir con ella. Nunca te la puedes llevar a vivir contigo. Recomendable para una vida apasionada pero debes incorporarte a su mundo y no salir de él.

Java: Es accesible, agradable, pero habla mucho, se pone un poco rígida a veces, y necesita una explicación para todo. Es súper confiable. Socialmente se comporta excelente. Ella necesita todo a lo grande: gran auto, gran casa, gran todo. Le es difícil ser sencilla por naturaleza, pero es una mujer que genera pasiones. Ella va adelante pero sólo si tiene seguridad, un buen auto y buena casa. Podés llevarla donde quieras, ella te acompañará. Recomendable para una relación conservadora con algo de aventura.

c#: Es accesible pero tiene padres adinerados, pero tienden a meterse en todas las relaciones e imponer sus pretenciones. Socialmente tiene algunos problemas ya que sólo podés moverte bien dentro de su familia. Le cuesta ser flexible y es poco apasionada, y para cada cosa que quieras proponerle deberás firmar un contrato. También necesita explicaciones por todo. En general ella nunca irá adelante, siempre se copiará de las demás. Recomendable para una relación conservadora.

Wayne Kelly nos escribió para darnos esta excelente noticia. El proyecto llamado “Ruby.net” ahora esta bajo el modelo open source!

Gracias Wayne & team!

Ruby.net

Wayne Kelly nos escribió para contarnos del nuevo Beta (version 0.8) release del Gardens Point Ruby.NET compiler el mismo nos permite la interoperabilidad con otros lenguajes .NET, por lo tanto puedes utilizar componentes desarrollados en otros lenguajes desde Ruby y viceversa.

Esto lo pueden ver en detalle en http://plas2003.fit.qut.edu.au/Ruby.NET/

Este prototipo tiene algunas limitaciones con respecto a la interoperabilidad:

1. Los programas Ruby solo pueden llamar métodos de otros lenguajes donde los parametros son pasados por valor (ej, no se pueden usar valor por referencia).
2. Los programas que no son Ruby no pueden usar clases Ruby que tengan una clase padre explícita (ej no se soporta interop si la clase Ruby hereda de alguna otra clase que no sea Object).

Estan trabajando ene resolver estos temas así como mostrar el desarrollo de aplicaciones winform con .NET en el próximo release.

También estan avanzados portando Ruby on Rails, pero no está disponible publicamente aún.

Todavía estan pendientes optimizaciones en la generación de código

Proximamente pasarán a un modelo open-source y estarán convocando desarrolladores.

Gracias Wayne y felicitaciones!

Algunos Screenshots

Hace algo más de dos meses decidimos comprar un buen equipo para dejar de usar hosting compartido (que le daba servicio a blog.onrails.com.ar y a varios sitios más), ya que nos estaba trayendo muchos problemas de estabilidad y performance, y ni hablar de algunos temas de compatibilidad. Por esta razón comenzamos a pensar cual era la mejor alternativa a la plataforma existente.

El stack

Opciones para correr aplicaciones Rails hay miles (bueh, no se si tanto). Nuestra idea no era proveer hosting, sino hacernos las cosas simples y no tener un techo de crecimiento demasiado establecido. Con esas premisas en mente optamos por la siguiente configuración:

• Sistema Operativo: Debian Linux (etch)
• FrontEnd: Nginx (el ruso que lo hizo la tiene atada)
• AppServer: Mongrel (con su amigo mongrel_cluster)
• DbServer: MySQL (confiable, performante, simple y amigable)

¿Por qué virtualizar?

El hardware que compramos no fue increiblemente de ultima generación (Pentium IV-HT), y había dos opciones (a la vista por lo menos): instalar todos los servicios en el mismo equipo o invertir en más servidores para poder separarlos y no tener problemas de escalabilidad/isolación/seguridad. Algo había leido sobre Xen, pero nunca me había metido lo suficiente (al menos sobre linux), entonces hablamos con Pedro y decidimos que la movida más interesante era usar xen para generar máquinas virtuales en un sólo servidor y así poder atacar los problemas enumerados anteriormente. Xen básicamente te permite ejecutar varios sistemas operativos en un mismo equipo, permitiendole al host (Dom0) administrar los recursos de cada uno de los guests (DomU). No requiere nada sofisticado y no consume demasiados recursos. No voy a decir que sea simple, pero no es rocket science. No voy a ahondar en detalles porque no soy un especialista en Paravirtualización y no quiero hablar sin saber, pero de todas las tecnologías de virtualización que analicé esta fue la que mejor se adaptó a nuestras necesidades actuales y la que menor impacto tenía a nivel performance. Solo se lleva un 3% de la CPU.

¿Cómo seguimos?

En los siguientes artículos de la serie iré relatando cada uno de los procesos de configuración de los jugadores de este partido. Todos tuvieron sus cositas y vale la pena comentarlo (creo yo). ;) Ojo, no va a ser una guía exhaustiva, sino una lista de tips a tener en cuenta al embarcarse en esta tarea.

Capítulos de la serie

• Xen (parte 2/4)
• Nginx & Mongrel (parte 3/4)
• MySQL (parte 4/4)

Recursos:

• Xen en la wiki
• Nginx (de rusia, increiblemente rápido)
• Mongrel (desarrollado por Zed Shaw)
• Mysql (no pongo el link, si no lo saben es para que se dediquen a otra cosa)

Dentro de los Releases de Adrenalinux nos encontramos con AdrenaRoR una distro para desarrolladores RoR con todo lo necesario para desarrollar en RoR (alguien seguramente encontrará que le falta algo)

Pueden entrar al sitio de Adrenalinux y descargar el iso e instalarlo.

Felicitaciones a los desarrolladores de esta distro que viene muy bien a la comunidad.

Un breve resumen

AdrenaROR = Adrenalinux + Rubyonrails

AdrenaROR está destinado a programadores de Rubyonrails. Tiene todas las herramientas necesarias para trabajar con el framework ROR, intérprete, editores, bases de datos, etc. El objetivo de AdrenaROR es facilitar el acercamiento al popular framework Rubyonrails y las nuevas tecnologías de programación web. Incluye:

• Intérprete ruby
• Radrails : IDE para Rubyonrails
• FreeIDE: IDE para ruby
• MySQL: base de datos
• PHPMyAdmin: interfase web de administración para MySQL
• Wink: generador de presentaciones en formato flash
• GanttProject: Gestor de proyectos
• Umbrello: modelador para UML
• Dia: generador de esquemas gráficos
• Quanta: IDE para desarrollo WEB
• Cervisia: Interfaz CVS (sistema de control de versiones)
• Kommander : generador de interfaz gráfica para aplicaciones
• Programas de Ofimática: Abiword y Gnumeric
• Programas para Internet: Navegadores, mensajeros, chat, etc.
• Gráficos: GIMP, Kolorpaint, etc.

Kernel 2.6.18.3 Entorno KDE 3.5.5 Requerimientos: Procesador: Intel o AMD 500mhz (aproximadamente) Memoria: 192 MB RAM (para kde) Lectora CD: 52x Para instalación: 1.7GB + espacio libre a gusto

Requerimientos Generales Recomendados: Procesador: Intel o AMD 650mhz Memoria: 256 MB Lectora de CD 5gb de espacio en disco

Los que hacen Adrenalinux:

• Hugo Orellano, Bruno Russo: Desarrollo
• Agustín Caballero: Webmaster
• Franco Rivero: Revista Users Linux

Despues de intentos varios encontre una forma de utilizar method_missing en una clase del tipo ActiveRecord.

En este caso necesitaba acceder a traves de un metodo a un atributo de un objeto dependiente, en este caso quiero acceder al valor del atributo contenido del objeto dependiente que tiene como atributo nombre=”apellido”.

Digamos que si escribimos:

Deberia hacer lo siguiente: buscar dentro de el array de datos_adicionales cual es el que tiene el atributo nombre = “apellido” y devolverme el valor del atributo contenido.

El modelo dependiente es algo asi

Deben existir otras maneras de resolverlo.

Este artículo iba a ser parte de otro un poco mas grande, pero decidí separalo porque podía llegar a ser útil para otros. Espero que así lo sea.

Teniendo instalado el cliente de subversion previamente, ejecutar el siguiente comando (dentro del directorio de la aplicación de rails):

Modificar el archivo config/environment.rb justo dentro de la siguiente area:

agregando la línea

A partir de este momento esa aplicación se va a ejecutar con el Rails incluido en el dir vendor/rails. El último toque es necesario porque no se incluye por default la parte correspondiente a Active Resource. No se muy bien cual es la razón.

Listo. Ahora deberías tener todas la últimas novedades disponibles. Ah, puede ser que necesiten además ejecutar el comando rake que actualiza los archivos de configuración de las aplicaciones:

Bueno, nada sofisticado, no? Que lo disfruten!

Colaborando con la comunidad OpenSource y el Grupo de usuarios de GNU/Linux de la facultad de Ingeniería de la UBA les comento de esta charla:

El LUGFI (Grupo de usuarios de GNU/Linux de la Facultad de Ingeniería de la UBA) invita a todos a participar el sábado 7 de Octubre del “Día de lenguajes”.

Dicho evento consistirá en una jornada de exposición, análisis y debate acerca de tres lenguajes de programación bien establecidos, modernos e innovadores (Ruby, C# Mono y Python), en donde se presentarán las características de los mismos, con énfasis en su estructura interna, sus capacidades, y las posibilidades que ofrecen desde la perspectiva del programador.

No hace falta conocer los lenguajes en particular, aunque sí se van a asumir conocimientos de programación.

El lugar será la Facultad de Ingeniería de la UBA, ubicada en Paseo Colón 850, aula 403, desde las 10:00am hasta las 7:00pm. Paramos al mediodía para almorzar, no se asusten.

Este es el cronograma:

10:00am – 11:00am Introducción a Ruby (Damián Viano) 11:00am – 12:00pm Introducción a Mono (Ricardo Markiewicz) 12:00pm – 01:00pm Introducción a Python (Leandro Lucarella) 01:00pm – 02:00pm Almuerzo! 02:00pm – 03:30pm Ruby avanzado (Damián Viano) 03:30pm – 05:00pm Mono avanzado (Ricardo Markiewicz) 05:00pm – 06:30pm Python avanzado (Alberto Bertogli)

Las charlas están planteadas de forma tal que la repetición de temas sea baja, por lo que es recomendable la asistencia “de corrido”, al menos dentro del mismo bloque.

Para más información, pueden dirigirse a la página del evento, http://moin.lug.fi.uba.ar/DiaDeLenguajes

Todos iremos por Ruby :-)