Lo que más me ha gustado de Scotland On Rails

Después de 4 días en Edimburgo me gustaría hacer una recopilación de las cosas que más he disfrutado.

Aprendizaje

La charla de Dave Thomas, que gran maestro.

El tutorial con mmolina y chafouler.

Los consejos de Pat para mejorar el diseño de una aplicación legacy.

Refrescar y fortalecer el hecho de usar las herramientas mas productivas hoy en la comunidad, como git y cucumber.

La explicación sobre "Connascence" de Jim Weirich

Las conversaciones caminando por la calle de camino a destinos a veces desconocidos, en los pubs, entre sesiones y en los aviones.

Edimburgo

Recordar lo bonito que es Edimburgo con su mezcla de arquitectura medieval y moderna.

La hospitalidad y simpatía de los escoceses.

Comida

El "haggis" medio pedo después de ver Holanda-Escocia.

Los fish and chips, que ricos!

Comunidad

La motivación por seguir hackeando y explorar nuevos horizontes mas allá de rails.

El espíritu fiestero.

Reafirmar nuestra fama española en todos los sentidos, llegar tarde, ser oídos mas que ninguno, beber como cosacos, y en general el buen rollo que nos caracteriza.

Ver la aprobación y acogida de cucumber.

Que a Fernando le tocara el premio gordo y nos regalara libros a todos.

Ver la comunidad tan de puta madre que tenemos en el mundo de ruby, el futuro promete.

En general una experiencia muy positiva, que sin duda repetiré el año que viene.

Grande Scotland On Rails!

P.D. Unas fotos cortesía de Guillermo Álvarez http://www.flickr.com/photos/cientifico/sets/72157615992132834/

servido por Raimond 4 comentarios compártelo

Hablando en la Conferencia Rails sobre Cucumber

servido por Raimond sin comentarios compártelo

Una idea InsOlentE: No hacer tests de tu implementacion.

Buenas!

Que os parece la idea? una locura no? De que conyo vas a hacer tests si no?

Pues mira, hay un grupo de gente, que dice que hacer tests de tu implementacion esta mal, porque tu implementation cambia, mejora, y entonces tienes que cambiar tus tests. No pasa nada si solo tienes 5 o 6 tests, pero cuando tienes 500 tests y re-estructuras tu codigo porque estaba volviendose eso un chaos que no entendia nadia, pues has tenido que cambiar todos tus tests relacionados con las clases que has re-estructurado, porque estas haciendo tests de tu implementation. Bien, eso es el pan de cada dia para muchos testeros, es lo que hay, y punto, vives con ello.
Bien, por eso la mayoria de gente no hace tests, porque son un conyazo que te cagas, y para que, si dentro de dos meses los vas a cambiar todos!

Tiene que haber una manera mejor de comprobar que tu aplicacion funciona, que hace lo que se supone que tiene que hacer. Da igual, como lo hayas decidido implementar, y por favor cambia la implementation todas las veces que quieras, si haces test de el comporamiento de tu aplicacion, no pasa nada. Por ejemplo:

hago un "post" con cierta informacion de una reserva y en la base de datos se me habra guardado la reserva con esa informacion.

Eso si que mola, y el codigo para hacer tus tests es mucho mas bonito e intuitivo. No tienes que ir "verificando" cada paso de tu implementacion, solo hay que asegurarse que tenga el compartamiento esperado.

Bueno, pues esto, se puede hacer de manera muy bonita usando los Stories the rspec. Aqui va un link si os mola la idea.
http://blog.davidchelimsky.net/articles/2007/10/21/story-runner-in-plain-english

Ta Luek!

servido por Raimond 2 comentarios compártelo

A non cohesive world

Buenas,

Cuando estoy frustado, a veces me cago en todo en ingles, aqui va una pequenya frustacion de esta manyana.

Let me tell you a little story. Once upon a time, there was a great tool to develop software. That tool, became obsolete, and new ones started taking over. The development of these new tools was so fast, that other tools, could not keep up with the changes. Leading to frankenstein like software, using the better tools when possible and the old ones when left with no other choice.

I have a dream, where all tools will talk to each other perfectly, but that dream is far from realistic. The only solution that I can imagine, is a tool that englobes all the other smaller tools, and thus can interact with all of them smoothly.

An example of this non cohesiveness is apparent in rails, rSpec, fixture_replacement and backgrounDRB. A great combination of tools, that advance at different speeds, and have not yet reached harmony.

As we know, Rails is awesome, rSpec and BDD are the evolution of jUnit and TDD, fixture_replacement isolates the data needed for each case, and backgrounDRB helps to avoid the limitations of HTTP's request/response cycle. Unfortunately backgrounDRB does not yet support the advantages of rSpec Stories which exercise the whole code and thus has to maintain a state of the test database that will get modified along the story and checked for the correct records. Instead we are limited to the rails way of using fixture files, which get loaded and erased with each unit test, breaking the chain of events that lead to the correct testing of a whole feature. Pity, but undoubtedly something we will fix as developers continue to use rails and BDD.

Until then, I will fall back to fixtures files and unit testing, might as well get me a PHP 5 book whilst I'm at it :)

servido por Raimond sin comentarios compártelo

Rails Conf Hispana 2007

Buenas,

Un pequeño summario de la Rails Conf Hispana este finde en Madrid.

http://ponencias.conferenciarails.org/charlas/calendario

Testing:
Buenos tests hacen escribir codigo facil <=> Buen codigo hace escribir tests facil.

BDD and rSpec:
La Evolucion de Test Driven Development.

Atom:
XML Standard para crear APIs.

Escalabilidad:
Nginx => Load balancer, rapido, estable y mas facil de configurar que Apache.
Sphinx => Motor de Busqueda, como ferret pero muy rapido, compatible con MYSQL y Rails.
http://www.slashdotdash.net/articles/2007/08/06/rails-searching-with-sphinx
http://blog.evanweaver.com/files/doc/fauna/ultrasphinx/files/README.html

Caso de Estudio MTV.es:
Gestor de Contenido intuitivo.
Usa una represenation visual clickable para representar las diferentes partes de una web y cambiar su contenido.

Caso de Estudio Flowers in Space:
Eslogan => "Sotware con ilusion"
"Crean" el concepto de hacer open source webs, que se pagan a si mismas usando anuncios publiciarios, y los beneficios van dirigidos a ONGs.
http://www.flowersinspace.com/

Caso de Estudio FacturaGem:
Hacer Software facil de usar es dificl.
El uso de videos para demostrar como funciona una web es muy apropriado.
http://www.facturagem.com/public/tour
Decir no, a funcionalidad que complica los tareas mas comunes.

Internationalization:
La intenalizacion es posible
Como se implementa depende del caso
Hay soluciones para casi todo.

Keynotes:
Obie Fernandez de Thoughtworks, Chicago.
Explicacion de los cambios mas importantes de rails 2.0
Pequeños equipos de 2-4 programadores y un diseñador es ideal.
Grandes equipos esconden a programadores menos productivos.
El pais, escribe un articulo diciendo que no hay suficientes desarrolladores para cubrir la demanda de aplicaciones web.
El problema es que 50, 100 programadores trabajan en una sola aplicación usando practicas poco agiles, especialmente en el mundo de JAVA.

ROA vs SOA:
Arquitectura orientada a servicios es demasiado compleja, por ejemplo SOAP.
Arquitectura orientada a recursos esta tomando mas importancia, creado soluciones elegantes y escalables.

Mesa Redonda sobre Frameworks:
Django, framework escrito en Python, un lenguage dinamico, usan MVC y ORM haciendo el desarrollo mas productivo.
J2EE, framework escrito en JAVA, un lenguage estatico, el framework require mucha configuracion para hacer cambios en la aplicacion, disminuyendo su productivad.
Microsoft, esta creando ironRuby para poder utilizar ruby en sus programas .Net
Los tiempos van cambiando y los lenguajes y frameworks se van adaptando a nuevas metodologias mas agiles.

En conclusion, una conferencia muy interesante hablando de las ultimas tecnicas en desarrollo web y con un ambiente de puta madre.

servido por Raimond sin comentarios compártelo

Conferencia Rails Hispana 2007

El jueves y viernes tiene lugar la segunda Conferencia de Rails Hispana en Madrid. Aqui va la lista de ponencias

http://ponencias.conferenciarails.org/charlas/calendario

Tiene muy buena pinta, nos vemos en Madrid!

servido por Raimond sin comentarios compártelo

Como plasmar los requerimientos y escenarios de una aplicacion en CODIGO

rSpec tiene una funcionalidad que se llama "Story" aun no esta en la version oficial pero esta en el edge. Aki os dejo un screencast de un colega que te lleva de prinicipio a fin por un "Story" de como hacer un blog post. Una cosa muy guapa que ves es que aunque los requiremientos esten incompletos es muy facil añadirlos cuando tienes la historia montada.

http://evang.eli.st/story_runner_top_to_bottom.mov

servido por Raimond sin comentarios compártelo

No son tests son especificaciones

La palabra test, me toca las pelotas, no me mola, parece que tengas que escribir el doble de codigo para hacer lo mismo. Siento reconocer que yo no hago tests. Ahora bien si me dices haz especificaciones, pues ya te miro de otra manera, eso no suena tan mal :)

A eso es a lo que vamos con Behaviour Driven Developement y rSpec, no vamos a hacer tests vamos a definir con funcionana el sistema y asegurarnos de que nuestro codigo hace lo que esperamos que haga.

Cuatro puntos clave que consigues con esta filosofia:
1. Mas confianza para cambiar el codigo existente.
2. Sabes cuando has acabado porque todos tus especificaciones pasan.
3. Documentacion, en vez de comentarios escribes ejemplos.
4. NO escribes TESTS de cada funcion, escribes ESPECIFICACIONES del COMPORTAMIENTO del sistema.

Un cambio en la filosofia de trabajar, que creo que me va a hacer un mejor programador.

Echarle un vistazo a este video de Gregg Pollack de railseny

http://www.patchedsoftware.com/RailsEnvy-LoveTests.mov

servido por Raimond sin comentarios compártelo