Rails y el territorio de los helpers: ¿Qué responsabilidades pueden/deben tener los Helpers?

Ruby_on_Rails_logo (1)Hoy voy a hablar de un tema que me parece interesante,  el territorio de los helpers. Discutiendo sobre el tema que da título este post, en ocasiones nos planteamos qué cosas deberían ir en los helpers y podemos encontrarnos con métodos que hemos desarrollado nosotros mismos y en ocasiones no son muy acertados. Voy a intentar responder a las preguntas de ¿cuándo debo utilizar un helper? y ¿de qué manera debo hacerlo? Por ejemplo, imagina que tenemos un template que hacemos una llamada a un método helper y que dicho método helper lo que está haciendo es pintar una parte de HTML, ¿crees que un helper debería contener código HTML? es decir, ¿la etiqueta en este caso de tag(:br)?

def add_user_check_box(user)        

      content_tag(:label check_box_tag(“Users”,  + ” “  +  user.name ) +   tag(:br)

end

En mi opinión, creo que esto no pinta bien hacerlo así ya que el HTML no es territorio de helper es de la vista,  aunque únicamente sea que pinte una etiqueta tag, como es el caso o podemos añadir otras etiquetas HTML, select o checkboxes, dentro del método helper del ejemplo, pero tampoco sería el helper el lugar adecuado para ello, entonces yo me pregunto:
Leer más…

Ruby: métodos de clase y métodos de instancia – cambiar la palabra es “La he liado parda”

med_Pragmatic.Bookshelf.Programming.Ruby.Jul.2013.ISBN.1937785491.pdfEn ocasiones es difícil explicarse por medio de la palabra, eso lo tengo muy claro, pero si a esto le sumas el poner la palabra definida erróneamente, puede llevar a términos que no es lo mismo, confundir al que lo está leyendo y piensas, “la he liado parda”. El caso es que he cometido el error de cambiar una palabra y poner que una solución a un problema (no es relevante el problema de origen para lo que voy a contar) era un método de clase Myclass.method en vez de un método de instancia Myclass#method  y como es lógico no es lo mismo, eso está claro, pero para que no te pase a ti lo mismo, voy a tratar de explicarlo, aunque lo de equivocarse, si eres humano, en ocasiones te puede ocurrir.

Quiero tratar el tema desde dos puntos de vista diferentes y quería hablar de los métodos de instancia y los métodos de clase, cuando tenemos una clase sin herencia y la otra es cuando tenemos herencia y explicar que self.class.method no es lo mismo que ClassName.method cuando hacemos herencia entre clases. Otro tema que quiero explicar es la concatenación de métodos, mediante los métodos de clase.
Leer más…

Ruby: una breve explicación sobre each / for y su scope – un secreto que deberías saber

learningRuby En el curso de Rails que estoy dando, junto con Gaby en la plataforma Neurodidactika de ASPgems, he visto necesario comentar algunas cosas interesantes de sobre for y sobre each. Son dos bucles (loops) que cuando has trabajado con otros lenguajes de programación puedes pensar que puedes utilizarlo indistintamente, pero te voy a enseñar algunas cosas que deberías saber antes de tomar una decisión de utilizar for o each.

Todo parte desde el punto en que ves en la vista index de products, el código para poder ver todos los productos. Pare ello, necesitamos iterar sobre nuestra variable de instancia con un bucle each: @products.each do |product| y pensar que también lo podemos hacer con un for sin problemas y es cierto, ya que utilizamos una variable de instancia @products. Pero veamos las diferencias que deberías tener presente.

En primer lugar voy a hablarte de for. Cuando trabajamos con un for, lo primero que tienes que saber es que la variable que declaramos para utilizar un for, es necesario saber dónde comienza y cuándo termina. es decir, el scope de dicha variable.
Leer más…

Method_missing(): ¿me ayuda a eliminar código duplicado? – espera, déjame que te lo explique

Metaprogramming RubyEn esta ocasión me gustaría hablar del method_missing(), me lo he encontrado en varias ocasiones y siempre lo he mirado de lado, no sea que pase algo.

Fuera de bromas, es otro de los temas, que tenía ganas de comentar y que mejor ocasión después de ver un vídeo hablando de este tema, leer sobre ello y preguntar a Paolo Perrotta sobre su charla en vídeo, que recomiendo ver por su alto contenido de información, titulado “The Revenge of method_missing()”, espera no te preocupes en buscarlo, que lo pongo al final del post, vamos por partes,  voy a tratar de explicar a mi manera con la ayuda de la información proporcionada por Paolo, tal como yo entendido y cuando debemos o no, utilizar este método. Pero lo principal es conocer, para poder saber aplicarlo.

Comencé a leer hace tiempo ya (vuelvo a ver capítulos de vez en cuando como en este caso), el libro de Paolo Perrotta @nusco en twitter, “Metaprogramming Ruby” que comenta en el capítulo 2 sobre los métodos, por cierto muy interesante, como todo el libro y comienza la problemática, cuando tenemos definidos métodos, cuyo código está repetido en otros métodos dentro de la misma clase. En ese caso podemos pensar ¿method_missing() puede ayudarnos a que nuestro código no se repita? busquemos la respuesta y el posible razonamiento.
Leer más…

Mi experiencia en el FOSDEM 2014 – No deberías perdértelo

FOSDEMposterEste año he asistido al FOSDEM 2014  por primera vez y tengo que decir que ha sido una experiencia genial, las charlas han sido de primer nivel a los que he asistido y estaba muy interesado, pero también tengo que decir que tenía otras charlas de las que nada tiene que ver con las cosas que normalmente hago, pero recomiendo a todos aquellos que estén pensando en ir, que se apunten y se organicen bien a lo que quieren asistir, hay mucha gente y los más seguro es que te quedes sin entrar, como les ha ocurrido a muchos.

Sobre el tema del alojamiento, recomiendo estar lo más próximo al campus ULB, ya que me pasó a mi, que estaba un poco lejos, tenía que coger transporte público pero se tardaba en llegar, tenía que combinar metro y tranvía o autobús. Eso si como estaba en centro de Bélgica, es un ventaja si vas de turismo, pero en mi caso, poco he hecho. Lo que hacía era madrugar un poco para dar un paseo matinal y disfrutar de las calles vacías del centro y hacer tiempo para llegar a las charlas.
Leer más…

Un modelo sólo debe hablar con su asociación inmediata – Law of Demeter con Rails

diciembre 22, 2013 2 comentarios

books

Una característica muy interesante que tiene Ruby on Rails, son las  asociaciones de Active Record, que a mi modo de ver nos permite de alguna forma el enlazar unos modelos con otros y en particular con las vistas. Sin embargo, también podemos cometer, a pesar de que esta funcionalidad tiene su alcance, puede hacernos complicada la refactorización y que comentamos errores.

En esta ocasión voy a hablar de “Law of Demeter”, que hace tiempo tenía ganas de comentar sobre todo algunos de sus aspectos y confusiones, que yo mismo he llegado a tener y que me gustaría compartir. Cuando la escuché hace tiempo ya, de un compañero de trabajo, Javier Ramirez @supercoco9, que por otro lado no quiero dejar pasar la ocasión para hacerte una sugerencia si eres desarrollador, echa un vistazo a su nuevo proyecto que mola un montón teowaki.com, que además junto con otro compañero que tuve el placer de trabajar en el mismo proyecto, Diego Rodríguez @diec123 (no sé si Diego pensará lo mismo :-) ) lo han puesto en marcha y que me han comentado en muchas ocasiones, cosas que han hecho y cómo las han hecho, se aprende mucho hablando con ellos, gracias a ambos por esos buenos momentos!!.

Dicho esto, voy a tratar de explicar lo que es Law of Demeter. Bajo mi punto de vista, no es una idea en si misma que podamos decir lo buena que es, es una ley que deberíamos tener en consideración. El caso es que partimos de la base en la que consideramos: “que un modelo sólo debe hablar con su asociación inmediata” y no deberíamos encontrarnos con casos en los que un modelo hable con la asociación de la asociación y además saber la propiedad de la asociación, se trata de un caso de acoplamiento.
Leer más…

Ordenando las Vistas (View) y utilizar Decoradores (Decorator) – Rails

Hey look!En este post hablé sobre el patrón Pattern Decorator” como una alternativa a los callbacks en los casos en que necesariamente nos implicaban en tareas que deberían ser separadas de nuestra lógica y comentaba que si pensamos en uno de los principios de SOLID Design Principles y concretamente en “Single Responsibility Principle”, en la que nos dice que un objeto sólo debería tener una única responsabilidad, en ese caso deberíamos pensar en aplicar el patrón “Pattern Decorator”, en vez de un callback.

Dicho esto, en esta otra ocasión quería hablar del mismo patrón pero aplicado a las vistas.

Piensa en los casos que tenemos Vistas en las que tenemos demasiada lógica dentro y cómo los Decorator (Decoradores) pueden ayudarnos a ordenar la vista y trasladar la lógica para que sea algo más mantenible. En esta ocasión he tomado como ejemplo de código un Railcast que utiliza Draper que me va muy bien para explicarlo. Seguramente que en alguna que otra ocasión, nos vamos a encontrar en la situación de tomar una decisión, cuando tenemos la responsabilidad de estar en un proyecto y en la que tengamos nuestras vistas, demasiada lógica aplicada, en ese caso ¿qué podemos hacer y cómo lo podemos mejorar?.
Leer más…

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 1.572 seguidores