1.- ¿Qué es?

Spock es un framework de testing y especificación para aplicaciones Groovy y Java. Está basado en JUnit, RSpec, Mockito, etc, etc.


2.- ¿Por qué?

Para nosotros porque es el que viene por defecto con Grails. En general porque es un framework de testing muy expresivo, que puede servir incluso de documentación para gente con poco background técnico.


3.- ¿Qué pinta tiene?


import spock.lang.Specification


class FirstSpockTest extends Specification {

def “let’s test the size method”(){

expect:

name.size() == length

where:

name     | length

“Yoda”   | 4

“Luke”   | 4

“Obiwan” | 6

}

}


Esto sería un test muy simple escrito con Spock. Para que la cosa funcione la clase de test tiene que extender de spock.lang.Specification. Dentro de esta clase podemos definir un método por cada feature que queramos probar. El método se puede llamar como queramos, de hecho el nombre del método es un string (“”) en el que podemos poner cualquier cosa.

Dentro de este método tenemos dos bloques, expect y where.

Como podemos suponer en expect expresamos una expectativa (la condición que queremos que se cumpla), mientra que en el where pondremos los valores que queremos testear.


Es bastante simple pero en este ejemplo faltan bastantes cosas. Nos sirve para probar un método de una variable pero no es muy real, vamos a poner algo un poco más “de verdad”.


import spock.lang.Specification


class FirstSpockTest extends Specification {

def “retrieve the first person”(){

setup:

PeopleService peopleService = new PeopleService()

when:

person = peopleService.getFirstPerson(nombre)

then:

person.name != null

person.class = Person.class

where:

nombre << [“Han”, null]

}

}


Esto ya tiene una estructura un poco más similar a algo que una persona normal podría entender. Aquí tenemos tres bloques, setup, when y then.

En el bloque setup definiremos los objetos necesarios para poder lanzar el test,

el bloque when es donde se lanza la acción a testear y el bloque then es donde indicamos las expectativas a cumplir.

En este último bloque vemos que no hay ni assertions. No hace falta ponerlas ya que van implícitas, si no se cumple lo que hay en la parte de las expectativas el test no pasa.


Si lanzamos el test del ejemplo veremos que para el valor null el test falla, y nos aparece el error de la siguiente manera:

Condition not satisfied:


person.name != null

|      |    |

|      null false

Person@6affe94b


Spock nos muestra el error de una forma bastante clara, señala la clase del objeto que da el error, el campo que falla con su valor y la condición que falla. De esta manera es bastante fácil corregir el error.


En el caso de que la condición fuera algo demasiado complicado, podríamos utilizar un método helper para simplificar el código en el bloque then:


import spock.lang.Specification


class FirstSpockTest extends Specification {

def “retrieve the first person”(){

given:

PeopleService peopleService = new PeopleService()

when:

person = peopleService.getFirstPerson(nombre)

then:

checkCondition(person)

where:

nombre << [“Han”, null]

}


def checkCondition(person){

assert person.name != null

assert person.class = Person.class

}

}


En este caso si que tendríamos que utilizar explicitamente el método assert para que en caso de error nos aparezca correctamente la notificación del error.


Condition not satisfied:


checkCondition(person)

|              |

null           Person@7efd4978


Condition not satisfied:


person.name != null

|      |    |

|      null false

Person@34bc6a08


4.- Profundizando

Con lo que hemos visto hasta ahora tenemos un test con una o dos features pero por lo general una clase de test puede tener bastantes features a probar. Spock nos provee de algunos métodos “especiales” que podemos utilizar en nuestros tests para facilitarnos un poco la vida.

Los principales son setup, cleanup, setupSpec y cleanupSpec.

El método setup se ejecuta antes de ejecutar cada una de las features, y nos puede servir para inicializar cosas comunes a todas ellas.

El método cleanup se lanza después de ejecutar cada una de las features, y podemos utilizarlo para dejar la base de datos limpia, borrar ficheros o cerrar conexiones.

El método setupSpec se ejecuta antes de lanzar la primera feature y podemos usarlo para inicializar objetos comunes a todas las features por ejemplo.

Finalmente el método cleanupSpec se lanza después de haber ejecutado todas las features y puede ser usado para limpiar datos u objetos que puedan haber creado las features.


Cuando estamos desarrollando suele ser habitual que no queramos que una feature se lance o que queramos lanzar sólo una en concreto. Para esto tenemos dos anotaciones: @Ignore e @IgnoreRest.

Lo que hace @Ignore es ignorar la feature que esté marcada con esta anotación, mientras que @IgnoreRest lo que hace es ignorar todas las features que no lleven esta anotación.


5.- Mocking

Spock nos permite mockear objetos de una forma más o menos sencilla.


def "let's mock"(){

   given:

       def peopleService = new PeopleServiceImpl()

       def person = Mock(Person)

   when:

       peopleService.greet(person)

   then:

       1 * person.receive("Hello")

}


Por ejemplo en este test de una feature hemos creado un Mock del objeto Person y nos aseguramos de que cuando llamemos al método greet de peopleService, el objeto persona responde a una llamada al método receive con el parámetro “Hello”.

En este caso nuestra expectativa es que se llame al método receive con el parámetro “Hello” una sola vez, pero se pueden especificar comportamientos más abiertos.

Por ejemplo si cambiaramos el bloque then por:

(1.._) * person.receive(!null)

Lo que queremos comprobar es que person recibe al menos una llamada al método receive con un parámetro distinto de null.


De esta manera podemos comprobar que nuestros objetos se comporta de la forma deseada, sin tener que preocuparnos de los valores que reciben o no.


Nota: por defecto Spock nos permite mockear interfaces, si queremos mockear también clases deberemos incluir en el classpath la librería cglib-nodep.


6.- Stubbing

De la misma manera que podemos mockear un objeto, también podemos stubbearlo, esto es modificar su comportamiento en un momento dado. Esto es muy útil para simular la respuesta de servicios externos.


def "now let's stub"(){

   given:

       def person = Stub(Person)

       person.receive("message1") >> "OK"

       person.receive("message2") >> {

           println "We are screwed!"

           "FAIL"

       }

   when:

       def response = person.receive("message1")

       def response2 = person.receive("message2")

   then:

       response == "OK"

       response2 == "FAIL"

}


En este ejemplo podemos ver cómo hemos modificado el comportamiento del método receive de la clase Person, para que en caso de recibir el parámetro “message1” nos devuelva la cadena “OK” y para que en caso de recibir “message2” imprima por la consola un mensaje de error y devuelva el mensaje “FAIL”.


7.- Spock y Grails

Desde la versión 2.3 de Grails, Spock ha dejado de ser un plugin independiente y ha pasado a ser el framework de testing por defecto de Grails.

En Grails los tests están en el directorio tests (O_O”). La nomenclatura de una clases de tests suele|debe ser “NombreClaseATestearSpec. Estas clases deben extender de spock.lang.Specification igual que cualquier otro test de Spock.

A parte de las funcionalidades de Spock que hemos descrito, Grails añade algunas cosas nuevas para facilitar el testeo de las aplicationes.


7.1- @TestFor

Esta anotación se utiliza para indicarle a la clase del test la clase que vamos a probar. En caso de que vayamos a probar un controlador añadirá a nuestra clase de test una variable del tipo del controllador llamada controller, a través de la cual podremos llamar a los distintos métodos o acciones del controlador. En caso de que queramos testear un servicio nos creará una variable service, etc, etc.


7.2- Mocks

Grails añade algunos métodos de mock a parte de los que podamos tener por defecto con Spock. Por ejemplo mockDomain nos permite que se añadan a un objeto de dominio los métodos dinámicos que se añaden al iniciar la aplicación Grails (findBy, save, …)


7.3- Objetos HTTP

Grails añade además los objetos típicos que se usan en las llamadas HTTP, un objeto request, un objeto response y un objeto params.


8.- Referencias

Tags: Grails Testing

Publicado por Rubén el 16/01/2014 a las 15:40

Hace unas semanas comenzaron a aparecer ciertas críticas hacia Heroku debido a cambios en la política del enrutado de las peticiones a los dynos.

Antes de este cambio en la política, cuando una petición llegaba a una aplicación, esta se dirigía en primer lugar a alguno de los dynos que estuvieran libres. A partir del este cambio en la política de enrutado, el dyno al que se dirije la petición se selecciona de manera aleatoria, por lo que hay una bajada de rendimiento importante, sobretodo en aplicaciones que usen muchos dynos.

 

Si por ejemplo, tenemos una aplicación que tiene 100 dynos, de los cuales 99 están ocupados, y llega una petición el funcionamiento es el que sigue.

  • Con el enrutado antiguo, la petición se dirige al dyno libre y se atiende instantáneamente.
  • Con el enrutado nuevo el dyno al que se dirige la petición se selecciona de manera aleatoria, con lo que tenemos un 99% de posibilidades de que la petición se dirija a un dyno ocupado y ésta sea encolada.

Esto es un ejemplo muy básico pero puede servir para hacernos a la idea.

 

Una de las razones que esgrimía Heroku para este cambio en la política, es que ahora se aceptaban muchos más frameworks en la plataforma, y que con este cambio era más sencillo gestionar las colas de peticiones. El problema es que las aplicaciones Rails sólo aceptaban una petición, con lo que quien más salía perdiendo con este cambio era el framework que fue el principal y único de Heroku durante mucho tiempo.

 

Parece ser que la política de enrutado no va a volver a ser la que era, pero como compensación, Heroku ha comunicado que a partir de ahora habilitará la posibilidad de utilizar Unicorn para servir las aplicaciones Rails. Unicorn es un servidor de aplicaciones que si admite peticiones concurrentes, con lo que se mitiga en cierto modo el problema de la política de enrutado.

 

En el blog de Heroku han escrito un post sobre cómo configurar nuestra aplicación para que utilice Unicorn.

 

Referencias:

Heroku

Unicorn

Heroku Blog - Adding Concurrency to Rails Apps with Unicorn

Publicado por Rubén el 27/02/2013 a las 11:35

Puede que sea una rareza mía, pero me gusta tener bien definidas las foreign keys en mis aplicaciones. Con Ruby on Rails no es algo completamente necesario, ya que Rails puede ocuparse de todo esto sin que tengamos que tocar la base de datos, pero a mi ver, es mejor que la base de datos haga lo que tiene que hacer.

El problema hasta ahora era que definir las foreign keys en una aplicación Rails era un poco engorroso. Había dos opciones: crear un fichero SQL con el código que creara las foreign keys, o crear unas migrations. La solución óptima desde luego serían las migrations, pero las migrations de Rails no nos proveen de ningún helper que nos ayude a crear las foreign keys de una forma rápida.

Aquí es donde aparece la gem protagonista del día, foreigner. Foreigner nos provee de helpers para poder crear nuestras foreign keys de una forma simple en nuestras migrations. Funciona con las bases de datos más utilizadas, MySQL, PostgreSQL y SQLite. Foreigner nos ofrece un método add_foreign_key y un método remove_foreign_key, que hacen justo lo que esperamos, crear una foreign key y eliminarla.

Con esto podemos definir nuestras foreign keys de una forma "bonita" en nuestras migrations sin ninguna complicación.

Enlace: Foreigner

Tags: Rails Db Gems

Publicado por Rubén el 20/01/2013 a las 21:12

En algunas ocasiones, en nuestras aplicaciones Rails, necesitamos guardar una cantidad más o menos grande de datos en la base de datos. Si creamos todos los objetos a guardar y después los guardamos uno a uno, dependiendo de la cantidad de objetos, tardaremos una cantidad de tiempo más o menos considerable. Esto es debido a que nuestra aplicación ejecutará una consulta de inserción para cada objeto que queramos crear, lo que no es nada eficiente.

Como solución a este problema, podemos utilizar la gem activerecord-import. Esta gem añadirá un método de clase import a nuestos modelos ActiveRecord, mediante el cual podremos guardar una cantidad grande de datos de una forma mucho más rápida.

Este método toma como argumentos dos arrays, uno con los nombres de los campos a rellenar, y otro con los datos a insertar. Este segundo array a su vez está formado por arrays, que contienen los valores para cada uno de los registros que deseemos insertar. Pongo un ejemplo para que quede un poco más claro.

def save_user_books(user,books)
  fields = [:user_id, :book_id]
  data = Array.new

  books.each do |book_id|
    item = Array.new
    item << user.id
    item << book_id
    data << item
  end

  UserBooks.import fields, data
end

 

Tenemos el método save_user_books cuyo fin es guardar una lista de registros en la tabla user_books. El método recibe un objeto user - user - y una lista de libros - books -. La tabla a tiene los campos user_id y book_id. Introducimos los nombres de los campos en un array - fields -. A continuación creamos un array con los registros a introducir - data -. Cada elemento de este array es a su vez un array - item -, en el que introduciremos los valores para los campos user_id y book_id.

Una vez creados los arrays fields y data llamamos al método import con estos arrays como parámetros.

Este método inserta todos los datos en la base de datos ejecutando una única consulta, lo que reduce considerablemente el tiempo de ejecución del método.

Aunque esta no sea una necesidad muy habitual, de esta manera podremos realizar las inserciones en la base de datos de una forma mucho más eficiente.

 
 

Publicado por Rubén el 05/08/2012 a las 20:11

De todas las novedades que nos ha traído HTML5 el API de WebSockets es probablemente una de las que más desapercibidas ha pasado, probablemente porque de cara al usuario no presenta ninguna novedad evidente. Sin embargo para los desarrolladores si supone una novedad importante a la hora de desarrollar nuestras aplicaciones web.

Durante la última década los desarrolladores de aplicaciones hemos estado buscando formas de comunicarnos con el navegador de una forma asíncrona y bidireccional, pero debido a que los navegadores no estaban pensados para enviar información la búsqueda no ha sido una tarea fácil. Han surjido varias tecnologías que de una u otra manera resuelven el problema, pero ninguna resuelve el problema completamente.

Los WebSockets de HTML5 han sido diseñados desde cero con el prósito de proveernos con una comunicación asíncrona y bidireccional con el navegador, independiente del tipo de datos que queramos enviar (binarios o texto). La comunicación con los WebSockets se realiza a través de una única conexión HTTP, por lo que además de ser una comunicación muy eficiente, funciona sin problemas a través de proxies, cortafuegos y demás parafernalia.

La especificación de los WebSockets es todavía un borrador, pero pese a ello muchos fabricantes de navegadores han implementado este API en sus productos. De esta manera podemos utilizar WebSockets sin problemas en Chrome, Safari y Firefox.

En el siguiente ejemplo vemos como podemos utilizar el API WebSockets en nuestra página web:

<html>
  <head>
    <script src='https://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js'></script>
    <script>
      $(document).ready(function(){
        function debug(str){ $("#debug").append("<p>"+str+"</p>"); };
          ws = new WebSocket("ws://localhost:8080/websocket");
          ws.onmessage = function(evt) { $("#msg").append("<p>"+evt.data+"</p>"); };
          ws.onclose = function() { debug("socket closed"); };
          ws.onopen = function() {
          debug("conectado...");
          ws.send("Hola, servidor!");
        };
      });
    </script>
  </head>
  <body>
    <div id="debug"></div>
    <div id="msg"></div>
  </body>
</html>

En esta página vemos como al cargarse el documento se ejecuta el código javascript que nos conectará con el servidor de WebSockets. Lo primero que debemos hacer para iniciar la comunicación es crear un objeto WebSocket y especificar la url donde se encuentra el servicio al que queremos conectarnos. Una vez hecho esto podemos especificar las acciones que realizaremos cuando nos llegue un mensaje, cuando se cree la conexión o cuando se cierre. También podemos ver claramente la naturaleza bidireccional de los Websocket, con el método send podemos enviar mensajes al servidor, mientras que con el método onmessage recibimos los datos del servidor en cuanto son enviados.

Seguramente no habréis visto ningún mensaje que no sea "socket closed". Esto es porque no hemos arrancado la parte servidora de esta aplicación, por lo que no tiene manera de funcionar.

Los Websockets funcionan como una extensión de HTTP, por lo que a través de un intercambio de mensajes habilitaremos una conexión con el navegador del usuario. Esto es parecido a una conexión TCP directa, pero con algunas limitaciones para mantener la seguridad del navegador. Pensemos que si un servidor externo pudiera abrir una conexión TCP desde el navegador podría utilizarse esto con fines como mandar spam, o cosas aún menos éticas.

Para iniciar un servidor de WebSockets vamos a utilizar la gem em-websocket de Ruby. Con unas pocas línes podemos tener nuestro servidor listo:

require 'em-websocket'

EventMachine::WebSocket.start(:host => "0.0.0.0", :port => 8080) do |ws|
  ws.onopen    { ws.send "Hola, mundo!"}
  ws.onmessage { |msg| ws.send "Pong: #{msg}" }
  ws.onclose   { puts "WebSocket cerrado" }
end

Este código inicia el servidor, envía el mensage "Hola, mundo!", y en caso de recibir un mensage del navegador escribe "Pong". Si lo ejecutáis y recargáis el HTML del ejemplo anterior veréis cómo ya no aparece el mensaje de error y veréis los mensajes.

Este es un ejemplo muy básico de cómo podemos utilizar los Websockets para enviar mensajes entre un servidor y el navegador, pero realmente la parte del navegador es opcional. Si tuvieramos un cliente HTTP compatible con Websockets podríamos utilizar éstos para comunicación asíncrona entre aplicaciones. La versión actual de EventMachine, la gem que hemos utilizado para construir este ejemplo, no soporta WebSockets, por lo que no podemos utilizarla para crear un ejemplo de cliente, pero esperemos que pronto tengan una versión que los soporte.

De todas maneras el uso para el que se pensaron los WebSockets es su uso con el navegador, por lo que podemos utilizarlos sin problemas para aplicaciones "convencionales".

Publicado por Rubén el 24/05/2013 a las 12:10

Últimamente no tengo mucho tiempo para dedicarle a nada que no sea trabajar, y mucho menos para dedicárselo al blog. Uno de los motivos era que no había conseguido poner ningún editor de texto enriquecido que funcionara correctamente, sobretodo cuando subía la aplicación a Heroku, por lo que tenía que escribir los posts en HTML, lo que me llevaba mucho tiempo adicional.

Pero el otro día navegando de un lado para otro me encontré con CKEditor, un editor de texto enriquecido que parece funcionar de forma bastante fácil con Rails. A pesar de funcionar bastante bien, la instalación no es precisamente intuitiva, sobretodo utilizando Rails 3.1 y haciendo la instalación en Heroku, así que os indico los pasos a seguir.

Lo primero es incluir el gem de CKEditor en nuestro Gemfile:

 

gem "ckeditor"

 

Después de hacer el consabido bundle install debemos descargar e instalar lo que es el CKEditor propiamente dicho, no la gem. Para esto ejecutamos lo siguiente:

 

rails generate ckeditor:install --path=public/assets

Esto descargará CKEditor y nos lo dejará en la ruta que le hemos indicado. Si utilizamos Rails 3.1 la ruta debe ser la que he puesto, public/assets.

Una vez hecho esto ya tenemos todo lo necesario para utilizar ckeditor en nuestra aplicación. Si queremos utilizar las opciones para subir ficheros, deberemos ejecutar algún comando más que está indicado perfectamente en la documentación, por lo que no lo voy a indicar.

Para incluir un editor en una de las páginas de nuestra aplicación debemos incluir el JavaScript de ckeditor:

 

<%= javascript_include_tag "/assets/ckeditor/ckeditor.js" %>

Una vez hecho esto ya podemos incluir un editor (o los que queramos) en la página, por ejemplo:

 

cktext_area_tag("blog_contenido", "Contenido del textarea")

Y eso es todo, con esto tenemos en nuestra aplicación un completo editor de texto enriquecido.

En la documentación podemos encontrar todas las opciones adicionales así como las distintas configuraciones que podemos utilizar.

 

 

 

Tags: Rails

Publicado por Rubén el 07/02/2012 a las 21:52

Hace poco me han preguntado sobre la posibilidad de crear una web en la que los usuarios puedan tener múltiples widgets que colocar y gestionar a su gusto. Lo primero que me vino a la cabeza es una web como iGoogle, pero teniendo esto como ejemplo parece bastante complicado implementar algo así desde cero. Me puse a buscar por la web a ver si había alguna forma "sencilla" de implementar algo así para una aplicación Rails y me encontré con Apotomo, que es un framework para crear aplicaciones web con widgets con Rails.

Apotomo nos permite desarrollar widgets de una manera bastante cómoda, anidarlos y gestionar los mensajes entre ellos, y aunque inicialmente puede parecer un poco complicado, una vez lo vas entendiendo es bastante intuitivo.

En su web tienen screencasts, documentación y un tutorial bastante decente para enseñarnos cómo integrar widgets en nuestra aplicación, desde la base que son los objetos de los widgets, pasando por los controladores y las vistas.

Si estais pensando en desarrollar algo de este estilo desde luego Apotomo es una opción a tener muy en cuenta.

Tags: Rails Gems

Publicado por Rubén el 16/12/2011 a las 10:44

Heroku es un servicio en la nube para el alojamiento de aplicaciones web. Dentro de los diversos tipos de servicios que nos ofrece la nube, Heroku se encuentra en el grupo de PaaS, Platform as a Service o Plataforma como servicio. Nos permite habilitar nuevas funcionalidades para nuestras aplicaciones en forma de addons así como escalar nuestra aplicación de una forma bastante sencilla. Por último, nos permite desplegar cualquier aplicación Ruby que utilice el interfaz Rack, como son por ejemplo Rails o Sinatra. Además también nos permite desplegar aplicaciones Node.js y desde hace poco aplicaciones Java.

Crear una aplicación en Heroku es bastante simple, al menos para aplicaciones Rails que es con lo que he probado.

Lo primero que hay que hacer es descargar la gem de Heroku, lo que se hace con un único comando:

gem install heroku

Una vez hecho esto, ya podemos utilizar los comandos de Heroku para desplegar nuestra aplicación en la nube. Hay que tener en cuenta que Heroku nos ofrece como base de datos PostgreSQL, por lo que deberíamos cambiar la gem correspondiente a la base de datos que usemos por la gem pg. Lo siguiente que tenemos que hacer es tener nuestra aplicación en un repositorio Git, ya que lo que haremos cada vez que queramos desplegar nuestra aplicación es hacer un push de nuestra aplicación al repositorio que hay en Heroku.

git init
git add .
git commit -m "Primer commit"

Una vez hecho esto ya podemos crear la aplicación en Heroku.

heroku create [--stack cedar]

La parte de "--stack cedar" es opcionar. El stack cedar el la última versión de la plataforma, por así decirlo, y todavía está en fase beta, pero parece ser que es necesario para las aplicaciones Rails 3.x.

Por último desplegamos la aplicación.

git push heroku master

Con esto ya tenemos el código en el servidor de aplicaciones, y tan sólo nos faltaría crear la base de datos en caso de que fuera necesario.

heroku rake db:migrate

En la web de heroku podemos ver la url de nuestra aplicación, cambiar la url y alguna cosa más. También podéis abrir la aplicación ejecutando:

heroku open

Y eso es todo, con esto ya tenéis una aplicación Rails en Heroku!

Publicado por Rubén el 19/02/2012 a las 15:20

Desde el día 30 de agosto tenemos disponible la versión 3.1 de Rails. Es una revisión mayor, que trae algunas nuevas funcionalidades respecto a Rails 3.0.

Pese a no ser ningún experto en este framework, os comento algunas de estas funcionalidades y lo que me han parecido.

Las tres principales novedades son el Assets Pipeline, el streaming de HTTP y la tercera, pero no por ello menos importante, es que a partir de ahora jQuery será el framework de JavaScript por defecto.

El Assets Pipeline es una funcionalidad ampliamente solicitada por algunos desarrolladores. A partir de ahora podremos utilizar SASS para el código CSS y CoffeeScript para el código JavaScript. SASS nos permite tener un código CSS mucho más claro, pudiendo utilizar variables, anidado de objetos, etc. Igualmente ocurre con CoffeScript, que nos permite utilizar código JavaScript de una forma mucho más cómoda, y sin perder ninguna de sus ventajas.

En cuanto al streaming de HTTP, es una nueva funcionalidad que podremos utilizar dependiendo del servidor de aplicaciones que utilicemos, pero que está disponible en servidores tan utilizados como ngingx. El streaming de HTTP consiste en que el navegador puede comenzar a descargarse las hojas de estilos y el código JavaScript mientras el servidor todavía está generando la respuesta, lo que hace que las páginas carguen de forma mucho más rápida.

Respecto a la última novedad poco se puede decir, jQuery es un framework de sobra conocido por los desarrolladores web desde hace tiempo, con multitud de plugins disponibles y con ejemplos y documentación por toda la red. De todas maneras para los que estén acostumbrados a Prototype, se podrá volver a utilizar este framework sin ningún problema.

Personalmente llevo utilizando esta versión de Rails desde que apareció la primera Release Candidate. De las novedades que he comentado las que a mi más me han gustado son, primero la inclusión de jQuery por defecto, ya que es el framework JavaScript con el que me siento más a gusto y pese a que antes se podía utilizar haciendo algunas modificaciones, siempre es más cómodo que esté todo preparado para usarlo.

La segunda cosa que me ha llamado más la atención es el Assets Pipeline. Inicialmente es una funcionalidad que veía con cierto escepticismo, ya que no le veía mucho sentido añadir más código intermedio para después generar más código. Pero una vez te pones a usarlo, sobretodo (para mi) en el caso de CSS, es extremadamente cómodo. El poder anidar los estilos unos dentro de otros, el poder usar variables... Creo que es desde luego un gran acierto. En el caso de JavaScript no me ha resultado tan cómodo, puede ser porque me haya rendido un poco pronto, pero aun así seguro que con el tiempo también será una funcionalidad sin la que no podremos vivir.

¡Y eso es todo! ¡Ale, a actualizar vuestras aplicaciones!

Tags: Rails

Publicado por Rubén el 20/01/2013 a las 16:40

Después de bastantes horas de trabajo y de darle vueltas a muchas ideas creo que por fin AgileSoft va a estar online.

AgileSoft comenzó como la idea de crear una empresa donde poder realizar proyectos de una forma rápida y eficaz, de ahí viene lo de "Agile", pero viendo que la coyuntura económica no está para emprender grandes aventuras, de momento se ha quedado en un blog donde hablaré sobre programación, novedades de las herramientas de desarrollo y en principio todo lo que tenga que ver con el mundo del desarrollo. Siempre he estado más orientado la mundo del desarrollo web, por lo que supongo que esta parte tendrá más contenidos.

Y este es el primer post, ¡espero que queden muchos por delante!

Tags: Blog

Publicado por Rubén el 09/09/2011 a las 12:26