@GuateonRails => Felicidad.find(:all)

Posts Tagged ‘Consejos


Gracias a los amigos de SapphireSteel Softare y bajo la autoria de HUW COLLINGBOURNE queda a disposición de la comunidad el libro “The Book of Ruby”.

El libro es en si, un tutorial gratis sobre el lenguaje Ruby. Contiene 425 paginas distribuidas en 20 capitulos. Queda disponible bajo formato PDF y cada capitulo incluye el código fuente de los ejemplos (FTW!!!!).

Como supondrán SapphireSteel está interesado en que pruebes su IDE y que lo uses como tu plataforma de trabajo Ruby, así que el libro tambien incluye secciones dirigidas a al uso de IDE para programación Ruby.

Les dejo los enlaces para que puedan visitar a los amigos de SapphireSteel y para la descarga (.zip) del libro y el código fuente.

Links

Sitio de SapphireSteel

Descarga del Libro “The Book of Ruby”

Anuncios

Para aprovechar al máximo el curso de Ruby te recomiendo tener esto en la cabeza:

1. Conocimientos de Programación Estructura

Si viste Pascal en la secundaría entonces estas bien.

2. Conocimientos de Programación por Objetos

Si viste Java, C++ o Visual *algo*, o .Net estas bien.

3. Ingles técnico básico

Necesitas poder leer la documentación del lenguaje y los proyectos relacionados.

Links

Wikipedia – Programacion Estructurada

Wikipedia – Programacion Orientada a Objetos


Buen dia comunidad!

Tengo el agrado de anunciar a ustedes el inicio del primer curso del
leguaje Ruby, el cual dara inicio este sabado 6 de febrero en las
instalaciones de Open Training (http://www.open-training.com/). El curso
tendra una duracion de 4 sabados en el horario de 8 a 12 am.

El curso tiene como objetivo el dar a conocer las alternativas de
desarrollo sobre los lenguajes 'tradicionales'. Asi como servir de
preambulo al un futuro curso de Ruby on Rails.

El curso es de entrada libre, aunque como supondran se les pide llevar
su maquina para que puedan trabajar. El curso sera 100% practico, asi
que es recomendado que si la lleven. Sin embargo los amigos de OT me
dicen que pondran a su disposicion 8 pcs para aquellos que no puedan
llevarla.

Para aquellos que no puedan asistir, el curso sera liberado en video
bajo CC ( esperamos.... 🙂 )

No duden de hacer publicidad entre sus amigos o colegas del trabajo,
mientras mas gente tengamos sentada en el piso, mejor 😉

Los esperamos!!


internet

!Saludos comunidad! ¿Como les va a todos?

En esta oportunidad quisiera compartirles mi opinión sobre el tema de “como ser un mejor desarrollador de Rails”. En realidad esto sale porque he tenido la oportunidad de entrevistar a varios desarrolladores para la empresa para la cual trabajo, y me ha puesto a pensar que debe de haber ciertas cosas que es necesario conocer para se lo considere a uno como un desarrollador respetable de Rails.

Creo que todo tiene que ver con el hecho de que Rails no es mas que una herramienta que combina o provee medios para que distintas tecnologías para desarrollo Web trabajen juntas de una manera transparente para el desarrollador, lo cual implica que el desarrollador debe de conocer estas tecnologías de antemano para poder hacer un mejor uso de Rails.

Estas son (según yo) las cosas que es necesario conocer para hacer un correcto uso de Rails. Las intentare ordenar de las básicas a las opcionales.

(Dejo por un lado la capacidad natural de algunos individuos bendecidos con la capacidad de diseñar la parte gráfica de un sitio, mis respetos a estas personas, de parte de alguien que apenas se aprendió sus colores primarios.)

Las obvias:

  1. Ruby
  2. Rails Framework

Las básicas:

  1. HTML
  2. CSS
  3. XML
  4. Javascript
  5. Restful Resources (REST)

Las bonitas:

  1. Ajax
  2. Ajax Frameworks:  Scriptacoulus, Prototype, JQuery, etc

Las que me dicen si eres profesional

  1. Metodologías de desarrollo ágil (Agil development): Xp, Scrum, etc
  2. Uso de controles de código fuente: Git, Subversion, CVS, etc
  3. Desarrollo basado en pruebas (Test driven development): Unitesting, Rspec, Shoulda, Selenium
  4. Diseño y administración de base de datos: Mysql, Postgresql (ni se les ocurra decir Access…)

Las que te ganan el contrato

  1. Estrategias para liberar a producción (Deployment strategies): Capistrano, Mongrel Clusters + Apache, Passenger
  2. Manejo o administración de servidores por medio de una consola de comando

Ok alli lo tienen, si en cierto momento se me viene algo mas a la cabeza les hago el update. Pero creo que tienen suficiente para pasarla entretendidos estudiando.

Como siempre, espero sus comentarios. Animo y a seguir aprendiendo!!!


rubylogoDurante la semana pasada tuve la oportunidad de escuchar una conferencia dictada por James Edward Gray II. La conferencia trató el tema de como mejorar tu nivel de desarrollo y hacía mención a que un programador experto es aquel que “lee mas código del que escribe”, es decir que pasa mas tiempo aprendiendo que haciendo. En especial, el se refería a leer código ajeno a indagar en “el como lo hizo”, en ser lo suficientemente curioso para no quedarse a nivel de “usuario”, si no bajar de nivel y ensuciarse las manos.

Confieso que ya desde algún tiempo he venido pecando de “estar demasiado ocupado para subir mi nivel”. Pero, me parece que la propuesta de James es lo suficientemente válida como para dejar la pereza por un lado y ponerme a trabajar.

James es el autor del Ruby Quiz, el cual es un reto de programación semanal que se distribuye por medio de la lista oficial de Ruby. La idea es que cualquier persona subscrita a la lista puede resolver el reto y si lo desea lo puede resolver en cualquier otro lenguaje distinto a Ruby. Esto es genial ya que permite a TODOS ver las soluciones de TODOS y aprender de todos los modos de resolver el problema comparándolo contra nuestra solución.

Pueden ver los archivos y mejores soluciones del Ruby Quiz en su página oficial,  y el último reto subscribiendose a la lista de correo Ruby-Talk.

¿Les gustaría que tradujese el reto semanal y lo incluyera junto con las soluciones dentro del Blog? Déjenme saber, yo por mi parte le voy a echar ganas y voy a empezar con el Quiz #1.

Éxitos y a picar piedra.

PS: Si quieren seguirle el rastro a James pueden hacerlo por medio de su Blog (http://blog.grayproductions.net/) o su perfil de Twitter (http://api.twitter.com/JEG2)


railsEl día de hoy me gustaría dedicar algunas líneas al tema de mejorar el rendimiento de tu aplicación en Ruby on Rails. (Ojo: el sarcasmo va dirigido exlusivamente a pseudo desarrolladores de Ruby on Rails que solo brindan su mál aliento al framework)

El temas sale directamente de la controversia que surge a partir de que Twitter anunciara que cambiará su sistema de mensajería de Ruby a Scala. Las razones de los señores de Twitter son bastante razonables, sin embargo esto ha generado un gran número de posts sobre “ya ven se los dije Ruby no sirve”, “no usen Ruby es la cosa mas lenta que hay”, “Rails no se compara con la velocidad de PHP”, y otro montón de tonterías. Para que no se asusten y para no me picarme el hígado mas de la cuenta les dejó más abajo la presentación de los señores de Twitter del porque de su decisión para migrar de Ruby a Scala.

Muy bien, ahora pasando a modo pro-activo, les voy a compartir un par de consejos para que no se conviertan en uno de esos “desarrolladores de Ruby on Rails”, que comentan decepcionados el como Rails no tiene un buen rendimiento y mejor se pasan a algo más “eficiente”.

He aquí tres puntos que considero de suma importancia para cualquier desarrollador que desee mejorar el rendimiento de sus aplicaciones o planificar adecuadamente una nueva aplicación.

1. Pobre diseño o elección de la base de datos

Voy a sonar de lo mas pedante, pero…. por favor antes de empezar a escribir scaffold, scaffold, scaffold les recomiendo tomarse 5 minutos (si pueden que sean 6) y pensar que están haciendo y por qué lo están haciendo. Nada mejora el rendimiento de una aplicación de Rails como un buen diseño de base de datos.

Si nunca lo han hecho les recomiendo leer algún libro sobre el tema o tomar algún curso o algo… porque no creerán las aplicaciones con las que me he encontrado en el mercado, las cuales me han dado mas de una razón para exclamar alguna grosería en el nombre de todo lo que es santo, cuando veo la estructura sobre la cual están corriendo.

Recuerden el objetivo de cualquier framework es el de brindar una forma de trabajo simplificada bajo la premisa de que existen tareas comunes que se repiten constante y de que la persona que está sentada frente al teclado sabe lo que está haciendo. Rails no es una muleta para aquellas personas que desean convertirse en “desarrolladores web” en diez minutos o menos. Rails está diseñado para “desarrolladores web” que desean incrementar su productividad y deciden usar este framework en particular para hacerlo.

2. Indices

Por alguna razón los “desarrolladores” de Rails, tienen la extraña idea de que esos viejos amigos de la infancia no tienen nada que ver con el ciclo de vida de las aplicaciones de RoR. Pero ¡oh sorpresa!, en el 90% de los casos un simple indice puede reducir el tiempo de respuesta de su aplicaciones en mas de un 100%.  Los índices a sus campos siguen teniendo la misma preminencia para las aplicaciones en RoR como para cualquier otro tipo de desarrollo. Si no los incluyes o no sabes como hacerlos bien tu aplicación pagará las consecuencias. El por qué y el como generarlos es asunto tanto de la lógica de tu aplicación como del manejador de datos que hayas elegido.

Para aquellos que les guste desarrollar bajo MySQL les sugiero que se familiarizen con el comando DESCRIBE el cual les permitirá determinar el ciclo de ejecución de sus queries.

Y para los que no sabían que RoR generá a su mas bajo nivel simples queries de sql (¡Oh Maravilla!) les suplico que se den una vuelta por la consola que está corriendo su servicio o mejor aún que le den una visita al archivo de logs.  ¿Rails tiene un log…? Si amigo mio RoR guarda (según su ambiente de trabajo) el resultado de sus operaciones incluyendo (en el ambiente de desarrollo) los queries que se han ejecutado contra la base de datos.

Los archivos de logs puden ser localizados el directorio (extrañamente llamado) miaplicacion/logs.

Tip para los usuarios Linux:

Los archivos de logs pueden ser limpiados por medio de la instrucción

$ rake log:clear (esto tambien aplica para otros SO)

y pueden visualizarse de una manera simple con:

$ cat log/development.log  | less -R

Y si desean ser un poco mas minuciosos con su trabajo,  les recomiento encarecidamente que instalen el plugin para MySql,  Query Analyzer. El cual modificará la salida de los archivos de log para incluir el resultado del comando DESCRIBE por cada query que se ejecute. La combinación de estos comandos y el entender que es lo que los logs muestran es tal vez la herramienta más poderosa para mejorar el rendimiento de una aplicación de Rails.

3. Poco conocimiento sobre el manejo del modelo de objetos de datos

La forma en que Rails por medio de la clase ActiveRecord obtiene el acceso a los manejadores de base de datos en simplemente una delicia en cuanto a la claridad y calidad de código que nos permite escribir, y en mi opinión Active Record es la pieza mas importante del asernal de RoR.

Nota: Si desean entender mejor su funcionamiento (por cierto ActiveRecord puede ser usado por cualquier aplicación escrita en Ruby) les recomiendo leer el libro  Pro Active Record : Databases with Ruby on Rails.

Ahora con lo concerniente a rendimiento RoR nos permite hacer cosas como:

personas = Persona.find(:all, :conditions=>condiciones_para_encontrar_personas)

lo cual ejecutará el query

select * from personas where "condiciones para encontrar personas"

Si nosotros deseásemos obtener la información de los paises de los  amigos de esta persona podríamos escribir el siguiente código:

persona = Persona.find(:all, :conditions=>condiciones_para_encontrar_persona)

@pais_de_amigos = persona.amigos.collect {|amigo| amigo.pais.nombre }

ahora eso funcionara sin problema, pero generará un query para obtener los amigos y un query por cada amigo para poder obtener la información del país. Ahora estó talvez no se note al principio, pero piensen en una aplicación como Twitter y la cantidad de amigos que puedan seguir a una persona, y verán que ese código es super ineficiente.

La solución de este problema cabe simplemente en conocer como funciona el módelo de objetos de RoR y poder hacer uso de él. El código anterior puede ser mejorado con solo usar eager associations, es decir traer toda la información necesaria con un solo query, tal y como se ha hecho por generaciones en cualquier otro ambiente de trabajo. Al agregar el parámetro :include a nuestra metodo find nos es posible obtener la información necesaria de nuestra tablas asociadas en un solo query. El anterior código sería rectificado de la siguiente manera:

persona = Persona.find(:all, :conditions=>condiciones_para_encontrar_persona, :include => :pais)

@pais_de_amigos = persona.amigos.collect {|amigo| amigo.pais.nombre }

lo cual generaría

select * from personas inner join paises on personas.pais_id = pais.id where condiciones_para_encontrar_persona

Como ven nada del otro mundo… simplemente saber que estamos haciendo nos puede brindar grandes satisfacciones al trabajar bajo Ruby on Rails. Así que ya saben, a estudiar diseño de base de datos y darle una miradita a la clase Active Record. Nada les cuesta y verán como sus aplicaciones se transforman de “esa cosa en Rails” a “la aplicación con la que quiero pasar el resto de mis días mientras me hace millonario”.

Saludos y Exitos en su lucha contra el mal!!


¡Hola Comunidad!

Para darle respuesta a la pregunta del millón ¿Cual es el mejor editor para trabajar Ruby on Rails?, voy a tomar otro camino que el común de intentar meterles por la garganta mi editor favorito o heredarles mi resentimiento hacia otros editores menos amigables.

Estas son las condiciones bajo las cuales un editor (en mi humilde opinión) es adecuado para el trabajo sobre Ruby on Rails. Aquí no valen pasiones platónicas con algún editor especifico, solamente cuenta si el editor puede o no puede hacerlo bien.

1. Coloración para sintaxis de Ruby y archivos Rails

Con esto me refiero a que su editor debe proveer una forma SENCILLA de brindar coloración al código de archivos tipo *.rb, *.rhtml, *.html.erb, *.js, *.yml y *.json. Si su editor no puede hacer esto, o para hacerlo deben de pasar mas de 5 minutos para buscar información y configurarlo, no pierdan su tiempo y díganle NEXT!

2. Completación de Código

¡Ojo! No estoy hablando de si al escribir una parte de una función el editor me regresa todas las funciones del API, me refiero a que al iniciar unos pocos caracteres como @ja el editor pueda, ya sea automáticamente o por medio de una combinación de teclas regresar @javier_es_lo_maximo. Esto se debe a que Rails trabaja en base a constantes llamadas a símbolos ya sea variables de instancia, nombres de clases o métodos de estas y no creerán la cantidad de tiempo que se pierde al buscar un error causado por una letra mal escrita en la llamada a una  )variable o función.

3. Fragmentos de Código (Code Snippets)

Una de las principales razones por las cuales un editor es o no adecuado para Ruby on Rails. Su editor debe permitirles el escribir algo como:

vu + TAB   ó   vu + CTRL + ENTER   ó   vu + SPACE

o algo parecido y debe regresar

validates_uniqueness_of :nombre_del_campo, :message=>”Este valor ya está en uso”

dando además la posibilidad de modificar FÁCILMENTE (una tecla) :nombre_de_campo y “Este valor ya está en uso”. A esto se le conoce como “placeholders”.

Además la creación y modificación de estos fragmentos debe de ser parte del editor o tener una manera SENCILLA de poder hacerlo. Si te tardas mas de 60 segundos en agregar, modificar o eliminar un fragmento tu editor no esta ni remotamente cerca de ser el indicado.

NOTA: El agregar o modificar fragmentos no debe de implicar que tengas que reiniciar tu editor.

4. Facil navegación entre Archivos

Debido a la forma como Rails ordena sus archivos, existe la necesidad de navegar rápida y repetidamente entre muchos de ellos. Estos archivos normalmente estan reacionados entre sí, por ejemplo si me encuentro trabajando una vista llamada mostrar_clientes.html.erb lo mas seguro es que voy a querer trabajar tambien el controlador clientes_controller.rb y el modelo cliente.rb. Y al hacerlo cambiar entre ellos de una manera RAPIDA y SENCILLA en especial si necesidad de utilizar el mouse para poder cambiar de archivos o para buscarlos. Tambien deben de incluir entre sus requerimientos que su editor permita visualizar un arbol de los directorios que contienen su proyecto, de nuevo no creerán lo frustrante que es no poder accesar rápidamente a un determinado directorio o peor aún tener que utilizar el manejador de archivos del sistema operativo para poder llegar a ellos.

5.  Búsqueda a nivel de proyecto

Simple pero tremendamente necesario, poder buscar un símbolo dentro de todos los archivos dentro de una carpéta específica y sus carpetas hijas.

6. No necesitar de 4GB de RAM para correr.

Exagero, pero no estoy bromeando. Hay editores que requieren mas recursos que un simulador de vuelo. Si quieren trabajar tranquilamente escuchando su música favorita mientras dejan su legado en Twitter, por favor alejense de este tipo de editores.

Muy bien, me parece que eso es todo. Creo que he cubierto las bases de un buen editor de Rails, cualquier cosa a partir de aquí son gustos o ventaja competitiva. Finalmente les dejo algúnos ejemplos de editores que a mi parecer cubren estós requisitos y más.

Apple:

TextMate (Rails nació en este editor)

Windows:

E-texteditor (Lo mas cercano a TextMate para Windows)

Linux:

Gedit (No creeran lo bien que saca la tarea)

Vim (Todos los servidores tienen Vi o Vim instalado, vale la pena aprender a usarlo)

y finalmente Emacs ( por cierto Emacs FTW!!!)

Espero que el post les sea de utilidad. Por favor dején sus comentarios o preguntas con confianza, estámos aquí para hacer que la comunidad crezca, o como dice mi esposa “para conseguir amigos con quien jugar!”

Suerte y Exitos a todos!


Sigueme…

Categorías

Cosas que salen de mi cabeza

Anuncios