New guitar cover! This time Indie-Rock with Arctic Monkeys' From The Ritz To The Rubble! www.youtube.com/Endymiion #indie #rock #guitar #cover #youtube #arctic #monkeys #arcticmonkeys
Recording night in the living room. #rock #recording #guitar #night #fun #blackandwhite #lefthanded #macbook #sennheiser #apogee (Tomada con Instagram)
Building a Backbone application with CoffeeScript and Jasmine - (I)
This is my first post in English, lately I've noticed that my English was getting kinda rusty, and decided to change it. In brief: I'm sorry :p
Prelude
A few weeks ago I went to the second edition of We ♥ JS, and it was a blast! Not only @cvillu did show the awesomeness of CoffeeScript again, but also @micho did a great Backbone workshop that made me want to try out even more this framework.
I've tried two technologies in order to build my app test-driving it:
Brunch & Mocha
Jasmine & sinon
I've found that Brunch is a really awesome HTML5 application assembler, agnostic to frameworks, libraries, even stylesheet and templating languages. It's easy to get started, and provides some watchers out-of-the-box that build continously the application, launches a local server, etc. The fact that Mocha got me hooked seeing @cvillu using it at his CoffeeScript talk made me want to try it along with brunch.
There's just one problem - it's not as easy as it seems to make work Brunch, Backbone and Mocha together (or at least a noob like me wasn't able to do it), mainly because right now there's no testing support on Brunch (it was planned for the 1.2 release, but has been postponed to the 1.3).
So, the main solution I found was using Jasmine HtmlSpecRunner, and add my compiled .coffee files (spec and production code) to this HTML.
You might notice that I won't describe much on how Backbone works, it's documentation is great and I'd just do a very poor job trying to show you that. Instead, I prefer showing you how was my flow of development with this tools.
The application
One of the main examples for a Backbone application is a todo list: a simple application that lets you create tasks with an input field and mark them as completed on the task list. It seemed kinda cool, but as you know I'm a pomodoro guy, and one of the apps that I try to build when learning new things is a pomodoro task manager, so my app not only should save a list of items, but also save an estimation in pomodoros of each one and be able to launch the estimated pomodoros for a selected task (but lets leave it for the 1.1 release :P).
You can find my code at the GitHub repo, so you'll be able to see there which is the set up for the application.
Let's start coding!
Let's start defining our Task class:
https://gist.github.com/2690652
This spec will fail because there's nothing defined in our application yet! We should add a Models collection or namespace and a Task class in that collection.
So, in order to do it:
https://gist.github.com/2690674
Now our first test should pass! And now we can start defining some default values for our tasks' attributes, like:
https://gist.github.com/2690689
And it will fail, announcing us that our object has no method 'get', so now we must make our class Task extend from Backbone.Model, and our tests will fail for the right reason: our attributes are not defined, and naturally have no default value, so we must define our defaults like this:
https://gist.github.com/2690702
Green again, now we can add an abstraction to this get "element" call creating a getter for each of our attributes, and verify that this methods call the get method with the right value:
https://gist.github.com/2690712
Then we just create these methods in our Task class:
https://gist.github.com/2690722
And now here comes one of the juiciest parts from our model's description: we must define the behaviour for the save method of our model. It should send a request to our server, sending it a JSON object with our task's contents. For that, I use the marvelous sinon's fakeServer, and just capture what is being sent:
https://gist.github.com/2690750
We will get an error message telling us: A "url" property or function must be specified - so lets create this property in our Task class, let's call it "/tasks" for now, and lets write a toJSON method for our class, because it will get called when calling the save method:
https://gist.github.com/2690757
We have defined a value for our url property, but we should define it better for some different actions:
On task creation: POST "/tasks"
On task update: PUT "tasks/{task_id}"
https://gist.github.com/2690789
So let's modify our url property to be a method like this:
https://gist.github.com/2690794
Now, we can define some attribute validation: we can't save a task with a negative id, nor one with a negative estimation:
https://gist.github.com/2690799
And to make it pass:
https://gist.github.com/2690802
Yeah, I know, the validate method contains some ugly code duplication - we'll get into refactoring that later. But for now, I think that this post has grown far too long than I'd expected and that offers quite a bunch of information of how to test some Backbone models and how they work.
In my next post, I'll write about Backbone's collections and routers.
Este post ha sido más largo de lo que esperaba: pensaba hacer una pequeña retrospectiva de este último año, que considero que ha sido revelador para mí, y al final lo voy a partir en varios posts, para mantener la cordura del que lo lea y la mía :)
Hace un año se abrió un mundo nuevo ante mí. Jay y yo teníamos a Jose Raya como profesor en la universidad, y nos habló de las cosas tan guays que hacía como coding dojos, reuniones, clubs de lectura, etc. en una comunidad llamada agilebcn. Empezamos a seguirle en Twitter, y empezamos a asistir a estas reuniones.
Enseguida decidí que en lo que me quería centrar era en hacer un código claro, efectivo, que no hiciese más que lo que se esperaba de él. Un código altamente modificable, sin romper el sistema del que formaba parte. Me di cuenta que con mi metodología de desarrollo (ninguna) no tenía la seguridad ni la confianza de cambiar mi código por uno más legible sin saber que me había cargado algo que no me esperaba. Ahí es donde entró el TDD.
Descubrí que esta metodología de desarrollo me permitía diseñar y especificar el comportamiento de mi código, ¡con más código! Que tendría una documentación viva, cambiante, y que verificaría que efectivamente, el código documentado se comportaba como esas pruebas afirmaban. Naturalmente, no es un camino de rosas, aún muchas veces me encuentro de repente bloqueado con un ¿y ahora qué?, pero también se que cada día resulta más fácil que el anterior, y que ahora puedo entrar con un hacha en mi código y refactorizar media clase teniendo la seguridad de que no he roto nada, y si lo he roto, saber dónde y cuando ¡menuda gozada!
Pero lo más revelador sin duda fue la gente: en las reuniones de DoubleYou y los clubs de lectura conocí a Jaume Jornet, Carlos Iglesias, César Úbeda, Javier Gómez, Adrian Perreau, José E. Rodríguez, Xavi Belloso... personas apasionadas por lo que hacen, que ven el mundo de otra manera y con la valentía suficiente para luchar y conseguir esos cambios que buscan. Me he sentido inspirado por todos y cada uno de ellos, y les estoy infinitamente agradecido por todo lo que han compartido y comparten.
En junio finalmente pude asistir a mi primer coding dojo en Runroom. No me he perdido ninguno desde entonces, ahí es donde aprendí (y aprendo) como estos cracks que se preocupan por hacer las cosas mejor día a día desarrollan y sortean esos problemas. Como en las retrospectivas se discute como de correcta es esa solución o esa otra.
Ahí conocí a un fiera del que había oído hablar por Twitter, pero que aún no había desvirtualizado: Edu Rodríguez. Hicimos un pomodoro junto con Adrian, y nos mantuvimos en contacto. A lo largo del verano hicimos unas cuantas katas juntos, intentando maximizar la legibilidad de nuestro código, e intentando seguir los principios SOLID. Nos pasábamos tiempo discutiendo lo mucho o lo poco que estaba cumpliendo SRP y DRY tal o cual trozo de código. Hemos programado bastante juntos durante este tiempo, y tengo que reconocer que cada vez que me he puesto a desarrollar con el, he aprendido una cosa nueva de su kung-fu particular.
Y esto nos deja solo a la mitad de la historia, aún faltan muchas cosas, como mi entrada como desarrollador en Runroom, mi primer open space, el global day of coderetreat, ¡y muchas cosas más!
Pero el pomodoro está a punto de sonar, y voy a volver a programar :)
Script de continous testing en PHP para sistemas que usen NotifyOSD
@ArturoHerrero publicó hace unos meses en su blog un post muy interesante sobre como había montado un script para que ejecutar sus tests en background aprovechando NotifyOSD, que es el sistema de notificaciones usado en Ubuntu, KUbuntu, Fedora y demás.
Así pues, al empezar a realizar tests en Symfony 2 (de los cuales debería escribir un día de estos), he empezado a echar de menos una herramienta de continous testing como Infinitest, y al acordarme del post de Arturo, he pensado en crear mi propia versión, y centrándome en Fedora, que es el sistema operativo que utilizo últimamente.
Debo destacar, y así enlazo con el post que acabo de realizar con un snippet de código, que gnome-shell deja las notificaciones en un estado persistente en el cual, aunque se oculten al cabo de los milisegundos que le indiques, se mantienen en la barra inferior del sistema. Esto era un problema a la hora de realizar un script de este tipo, ya que se nos acabaría llenando de notificaciones sin cerrar, lo cual resultaría un engorro. Pero gracias a la opción:
--hint:int:transient:1
conseguimos que, una vez ha expirado la notificación, desaparezca.
Desde hace algunos meses, he intentado introducir la técnica pomodoro en mi gestión de tareas. Para el que no la conozca, tiene un funcionamiento muy simple, y sólo necesitas de un bolígrafo, un papel y un temporizador:
Elige la tarea que consideres más prioritaria de las que tienes que hacer hoy.
Pon el temporizador para dentro de 25 minutos.
Concentrate sólo en esa tarea hasta que suene la alarma.
Cuando haya acabado, marca una X al lado de la tarea en tu lista.
Descansa 3-5 minutos. Descansa, eso no es contestar correos del trabajo ni pensar en la tarea que has hecho o que vas a hacer.
Vuelve a decidir que tarea es la más prioritaria de tu lista, y vuelve a empezar.
Cada 4 iteraciones, descansa 15-30 minutos.
¿Porqué trabajar con pomodoros? Porque trabajar en grupos de 25 minutos apetece más que enfrentarte a una tarea de dos horas y media. Además, es mucho más facil mantener la concentración 25 minutos que esas dos horas y media, y el hecho de desconectar cada 25 minutos te permite recargar las pilas para la próxima tarea.
Para mí no es una forma de obligarte a estar trabajando un rato, sino que es una forma de obligarme a descansar de manera regular. Al estar más descansado, mi productividad aumenta y mis ganas por hacer las cosas de manera perfecta se mantienen, pudiendo estar mucho más concentrado, y haciendo las cosas en menos tiempo, puesto que evitas y gestionas tanto las distracciones internas como externas.
Yo como listado en el que voy añadiendo las tareas que tengo por hacer, o proyectos que quiero empezar a investigar, tengo una Moleskine de bolsillo, para poder tener la lista siempre a mano, y apuntar las ideas que surjan en cualquier momento. Como lista de las cosas a hacer hoy un simple folio basta, y como temporizador suelo utilizar FocusBooster, una aplicacion para Adobe Air.
Para saber más sobre esta técnica, puedes leer el eBook escrito por Francesco Cirillo (el creador de la técnica) aquí, o bien puedes comprar el genial libro The Pomodoro Technique Illustrated.
PD: Esta entrada se ha hecho en un único pomodoro :)
baratheonpilled
areudirty
pixelskylines
origamiaround
titsay
snowghoul
discoholicmusic