Tras un par de semanas algo turbulentas, hoy ha sido mi último día como edenita.
El tiempo que he formado parte de Eden ha sido espectacular. Estoy muy agradecido a todos y cada uno de mis compañeros por creer en mi y por hacerme crecer tanto en lo personal como en lo profesional :) De verdad, muchas, muchas gracias por haberme brindado esta oportunidad.
Supongo que os preguntaréis qué ha pasado. Tranquilos, no he suspendido durante mi aprendizaje :P De hecho, voy a seguir siendo aprendiz de Aimee (¡yuju!). Simplemente, a veces las cosas no salen como uno espera y entonces es cuando tenemos que abrazar el cambio :D
Ahora empieza otra aventura :D Me voy a quedar en Inglaterra mejorando mi inglés y trabajando como autónomo. Después de mi internship pense en hacerlo en España, pero no terminé de atreverme. Ahora sí que me voy a lanzar :D Todavía no tengo muy claro los pasos a seguir (tengo bastante lectura acumulada para el fin de semana :D ), pero tengo compañeros que me van a ayudar en esta nueva etapa del largo camino (y también tengo un cliente :P ).
¡Nos vemos!
PS: Mañana tenemos code retreat en el taller :D Ya os contaré que tal.
Mostrando entradas con la etiqueta eden. Mostrar todas las entradas
Mostrando entradas con la etiqueta eden. Mostrar todas las entradas
viernes, 11 de marzo de 2011
My Vim configuration. Part 3 - Vim shortcuts
Continuing with my explanation of my Vim configuration (you can have a look at my view settings and my plugin settings), today is the day of the shortcuts :)
Everyone of us love the shortcuts our favorite IDE has. Vim is no less and you can define whatever shortcut you need :)
How to define a shortcut in Vim
It is very easy to define a shortcut in Vim, you only need to map the key combination you one to use with the actual command you want to execute.
To map a combination you can use map or noremap (and all the variants for each mode, like imap, inoremap, nmap, nnoremap, etc...). The difference between map and noremap is that the second one is not recursive. You have a very good explanation here.
You can see an example of a shortcut definition:
This shortcut closes Vim without saving the file and can be executed by pressing the keys 'c', 'l', 'o', 's' and 'e'
Leader
The previous example is more or less a "hard code" shortcut :) A better way to map commands is using the leader variable, so you start your shortcut by pressing your leader combination.
To define your leader combination you only need to do something like this:
In this case, my leader combination is just the ',' key :)
It is important to define your leader combination because a lot of the existing plugins for Vim use it for their own shortcuts (mappings).
My shortcuts
Ok, now that we have defined the leader, let's have a look to my actual shortcuts.
The first one I want to show you is how to change between the actual buffer and the alternative buffer (If you don't know anything about Vim buffers, take a look at this video, it is great!)
What I'm doing here is mapping ',' and '6' to ':b#' (:b# is what you have to type to switch buffers when in normal mode. means that, after the command, I want to press 'return', executing the command). I'm using nnoremap for this shortcut because I want to use it only in normal mode (the first n of nnoremap) and because if some of my plugins map any ':', 'b' or '#' key to any command I don't want to execute that shortcut (not recursive), I just want to execute ':b#'.
The next shortcuts are related to some plugins I use:
I just map the NERD tree to ',d' and a little bit of help every time I want to use ack (only in normal mode) :P
Then, I have two shortcut for removing the extra spaces (at the end of the line) and to change tabs with 2 spaces :)
I also have a shortcut that changes the ruby hashes (with a symbol as key) from 1.8 syntax to 1.9 syntax:
And last, but not least, I map the tab as a match bracket finder:
I probably change all of this shortcuts in the future, when I get more experience with Vim, but I hope it shows you how powerful (and customizable) Vim is :)
PS: I know that the gist are not visible on google reader. Sorry about that! I want to move my blog and fix that :)
Everyone of us love the shortcuts our favorite IDE has. Vim is no less and you can define whatever shortcut you need :)
How to define a shortcut in Vim
It is very easy to define a shortcut in Vim, you only need to map the key combination you one to use with the actual command you want to execute.
To map a combination you can use map or noremap (and all the variants for each mode, like imap, inoremap, nmap, nnoremap, etc...). The difference between map and noremap is that the second one is not recursive. You have a very good explanation here.
You can see an example of a shortcut definition:
This shortcut closes Vim without saving the file and can be executed by pressing the keys 'c', 'l', 'o', 's' and 'e'
Leader
The previous example is more or less a "hard code" shortcut :) A better way to map commands is using the leader variable, so you start your shortcut by pressing your leader combination.
To define your leader combination you only need to do something like this:
In this case, my leader combination is just the ',' key :)
It is important to define your leader combination because a lot of the existing plugins for Vim use it for their own shortcuts (mappings).
My shortcuts
Ok, now that we have defined the leader, let's have a look to my actual shortcuts.
The first one I want to show you is how to change between the actual buffer and the alternative buffer (If you don't know anything about Vim buffers, take a look at this video, it is great!)
What I'm doing here is mapping ',' and '6' to ':b#
The next shortcuts are related to some plugins I use:
I just map the NERD tree to ',d' and a little bit of help every time I want to use ack (only in normal mode) :P
Then, I have two shortcut for removing the extra spaces (at the end of the line) and to change tabs with 2 spaces :)
I also have a shortcut that changes the ruby hashes (with a symbol as key) from 1.8 syntax to 1.9 syntax:
And last, but not least, I map the tab as a match bracket finder:
I probably change all of this shortcuts in the future, when I get more experience with Vim, but I hope it shows you how powerful (and customizable) Vim is :)
PS: I know that the gist are not visible on google reader. Sorry about that! I want to move my blog and fix that :)
martes, 8 de marzo de 2011
Sass is so cool!
I have to admit that I didn´t know almost anything about CSS six months ago. I was an API developer and I never needed it. But now, everything has changed (I know, it should have changed before, but it didn´t). I need to improve my CSS skills and I need to do it quickly!
The thing is, I don't really like CSS. I find it a bit confusing and, every time I try to do something I end up doing a mess. What can I do? I need to learn SASS (Syntactically Awesome StyleSheets)!
SASS to the rescue
This is the first line you can read on the SASS page:
What makes SASS funny
For me, SASS is funny because it brings programming concepts to CSS, and I love programming :D
Variables in SASS
Corey Haines said on Twitter that this year's color was #CB6586. If I start to use this color on my CSS I have two problems:
And we can use that variable everywhere we want:
Mixins in SASS
Another DRY violation that I used to do with CSS is when I have to define effects (round borders, shadows, gradients, etc...) to the elements. I end up writing the same more than once (probably because I don't know almost anything about CSS, but probably because it is a very easy thing to do with CSS). SASS helps me to define mixins so I don't repeat my "code" every now and then.
An example of how to define a mixin to apply a gradient can be this one:
And we can use it like this:
Did you notice it? Mixins accepts arguments! How awesome is that?
More SASS awesomeness
You can find more cool SASS features on the official page. It is very simple and very useful!
Enjoy it!
The thing is, I don't really like CSS. I find it a bit confusing and, every time I try to do something I end up doing a mess. What can I do? I need to learn SASS (Syntactically Awesome StyleSheets)!
SASS to the rescue
This is the first line you can read on the SASS page:
Sass makes CSS fun again.And, do you know what? It is true!
What makes SASS funny
For me, SASS is funny because it brings programming concepts to CSS, and I love programming :D
Variables in SASS
Corey Haines said on Twitter that this year's color was #CB6586. If I start to use this color on my CSS I have two problems:
- If I want to change it on january 1st of 2012 with the 2012 color I'm going to find all the places I'm using it (DRY violation).
- I am not a color machine. #CB6586 does not mean anything to me (Not readable).
And we can use that variable everywhere we want:
Mixins in SASS
Another DRY violation that I used to do with CSS is when I have to define effects (round borders, shadows, gradients, etc...) to the elements. I end up writing the same more than once (probably because I don't know almost anything about CSS, but probably because it is a very easy thing to do with CSS). SASS helps me to define mixins so I don't repeat my "code" every now and then.
An example of how to define a mixin to apply a gradient can be this one:
And we can use it like this:
Did you notice it? Mixins accepts arguments! How awesome is that?
More SASS awesomeness
You can find more cool SASS features on the official page. It is very simple and very useful!
Enjoy it!
domingo, 6 de marzo de 2011
My Vim configuration. Part 2 - Vim plugins
I was supposed to talk about shortcuts in Vim, but I've changed my mind :P I'm going to talk about how to install plugins for Vim :)
Vim plugins
Vim has a lot of plugins, a lot :D So, how do I choose the plugins I need? Well, fist of all, you have to know what you need. This is very important, you shouldn't use a plugin if you're not sure about why you need it!
Once you've decided which plugins do you want you only need to install them!
How to install a vim plugin
Vim plugins are just scripts and to install them you only need to copy the script file in the right directory. Ok, this looks very similar to the way we add color schemes to our Vim, doesn't it? Yes, the only thing we need to change is the directory. When we install a plugin, we have to add the script file to the 'plugin' (or 'ftplugin' if it is a file-type-dependent script) directory in our .vim directory. Sooo easy :D
Yes, so easy. But, do I have to do that every time I get a new plugin or every time I update an old one? Cannot this process be automated? Yes, it can! There are a lot of tools to manage your plugin dependencies. I am using Vundle right now.
Vundle
Vundle is a plugin management tool for vim. It is very easy to set up and it is very easy to use. You only need to follow their instructions to "install" it. Once you have everything in its right place, you have to add those two lines to your .vimrc file:
This makes bundle available while you're using Vim :D
Vim plugins
Ok, so, how do I install plugins with Vundle? You only need to add the plugins you want to your .vimrc file (with the Vundler format). I have those:
As you can see, you can ask for the plugin by its "official" name or you can linked it to its github repository.
Once you've defined the plugins you want you only need to type:
on Vim to install or update your plugins :D
Ok, that's all for today. Soon on your screens "How to create shortcuts with Vim" (Although maybe I'll talk a little bit about why I choose those plugins)
Vim plugins
Vim has a lot of plugins, a lot :D So, how do I choose the plugins I need? Well, fist of all, you have to know what you need. This is very important, you shouldn't use a plugin if you're not sure about why you need it!
Once you've decided which plugins do you want you only need to install them!
How to install a vim plugin
Vim plugins are just scripts and to install them you only need to copy the script file in the right directory. Ok, this looks very similar to the way we add color schemes to our Vim, doesn't it? Yes, the only thing we need to change is the directory. When we install a plugin, we have to add the script file to the 'plugin' (or 'ftplugin' if it is a file-type-dependent script) directory in our .vim directory. Sooo easy :D
Yes, so easy. But, do I have to do that every time I get a new plugin or every time I update an old one? Cannot this process be automated? Yes, it can! There are a lot of tools to manage your plugin dependencies. I am using Vundle right now.
Vundle
Vundle is a plugin management tool for vim. It is very easy to set up and it is very easy to use. You only need to follow their instructions to "install" it. Once you have everything in its right place, you have to add those two lines to your .vimrc file:
This makes bundle available while you're using Vim :D
Vim plugins
Ok, so, how do I install plugins with Vundle? You only need to add the plugins you want to your .vimrc file (with the Vundler format). I have those:
As you can see, you can ask for the plugin by its "official" name or you can linked it to its github repository.
Once you've defined the plugins you want you only need to type:
on Vim to install or update your plugins :D
Ok, that's all for today. Soon on your screens "How to create shortcuts with Vim" (Although maybe I'll talk a little bit about why I choose those plugins)
domingo, 27 de febrero de 2011
My Vim configuration. Part 1 - View settings
Lately, I've been trying to understand better how Vim works, so I've started looking at its configuration files. I forked Chris's configuration (that was the easy part :D ) and I removed everything I'm not using at the moment. You can see my actual configuration files here.
It was not easy for me to understand how everything works, that's why I'm going to write about it :D Let's start from the beginning, the vimrc file.
.vimrc file
You can find an explanation about the .vimrc file here. Basically, this file is loaded just before entering Vim and it contains our personal Vim configuration settings.
I'll try to explain every line of my vimrc file during the week but, today, I'm going to show you how to configure the "view" part (colors, syntax highlighting, status line, etc).
My Vim view settings
Now, we have a nice Vim window much more friendly than the initial one :D The only problem is that the color scheme is just the default one (which is not very good).
Adding color schemes to Vim
To add a color scheme to vim we first need to get one :D There are a lot of them. I'm actually using tir_black, but I have to try some more :D
Ok, you've selected one color scheme, how does Vim know about it? First of all, you need to create a .vim/colors directory in your home directory. Then, you have to copy the color scheme vim file to that directory.
That's all! Now, you can go to Vim and type
The only problem with this is that it is not a permanent change. Every time you close Vim, it will lose your color scheme preference.
What can we do about it? Easy, we just need to open our .vimrc file and add the following line:
Now, Vim knows our preferences :D
Ok, that's all for today. Soon on your screens "How to create shortcuts with Vim"
It was not easy for me to understand how everything works, that's why I'm going to write about it :D Let's start from the beginning, the vimrc file.
.vimrc file
You can find an explanation about the .vimrc file here. Basically, this file is loaded just before entering Vim and it contains our personal Vim configuration settings.
I'll try to explain every line of my vimrc file during the week but, today, I'm going to show you how to configure the "view" part (colors, syntax highlighting, status line, etc).
My Vim view settings
Now, we have a nice Vim window much more friendly than the initial one :D The only problem is that the color scheme is just the default one (which is not very good).
Adding color schemes to Vim
To add a color scheme to vim we first need to get one :D There are a lot of them. I'm actually using tir_black, but I have to try some more :D
Ok, you've selected one color scheme, how does Vim know about it? First of all, you need to create a .vim/colors directory in your home directory. Then, you have to copy the color scheme vim file to that directory.
That's all! Now, you can go to Vim and type
The only problem with this is that it is not a permanent change. Every time you close Vim, it will lose your color scheme preference.
What can we do about it? Easy, we just need to open our .vimrc file and add the following line:
Now, Vim knows our preferences :D
Ok, that's all for today. Soon on your screens "How to create shortcuts with Vim"
jueves, 24 de febrero de 2011
Vim macros
I'm a total noob with vim, so I'm going to start a very basic series of blog posts writing down everything I learn :) Those are going to be very short posts explaining a vim feature. So, let's get started.
Today, I've been working with Tooky the whole day and he has taught me how macros work in Vim.
I can only imagine how powerful they are :D We've used one to rename a method (including everyplace it was called)
How to record a macro
First of all, we need to be on command mode. Then, we have to press 'q' and the key to store the macro ('qa' will store the macro in the key 'a'). We'll see the word 'recording' on the last line.
Everything we do then will be recorded (And I mean everything and on any mode).
To stop recording the macro, all we need to do is press 'q' on command mode.
How to execute a macro
All we have to do is to press 'q' and the key where we stored the macro (on command mode). To execute a macro stored in the key 'a' we have to press '@a'.
Recursive macros
We can make a recursive macro by recording a '@<key that stores the macro>'
Hope you find it useful :)
Today, I've been working with Tooky the whole day and he has taught me how macros work in Vim.
I can only imagine how powerful they are :D We've used one to rename a method (including everyplace it was called)
How to record a macro
First of all, we need to be on command mode. Then, we have to press 'q' and the key to store the macro ('qa' will store the macro in the key 'a'). We'll see the word 'recording' on the last line.
Everything we do then will be recorded (And I mean everything and on any mode).
To stop recording the macro, all we need to do is press 'q' on command mode.
How to execute a macro
All we have to do is to press 'q' and the key where we stored the macro (on command mode). To execute a macro stored in the key 'a' we have to press '@a'.
Recursive macros
We can make a recursive macro by recording a '@<key that stores the macro>'
Hope you find it useful :)
martes, 22 de febrero de 2011
Estado de un plagelao
Hoy voy a escribir un poco sobre como han sido mis tres primeras semanas en Eden a nivel personal. Os advierto desde ya que va a ser un post sobre como me siento yo, no sobre como funciona Eden. Si no os apetece leerlo, lo entiendo :D
Enrique continúa su largo camino
Estas tres semanas han dado para mucho pero, probablemente, lo más importante es la marcha de Enrique.
Como para muchos de vosotros, Enrique es una fuente de inspiración tanto en lo personal como en la profesional. Creo que soy muy afortunado por haberle conocido y por poder trabajar con él. ¡Gracias, Enrique! ¡Te deseo muchos éxitos y felicidad mientras cumples tus sueños!
Por suerte, Enrique se queda hasta abril (o no, depende de varias cosas :D ) en Winchester, así que aún podré disfrutar de su compañía algún tiempo más :)
Pero entonces ¿tú que haces?, ¿te quedas en Winchester o te vuelves a Madrid? ¿Qué pasa con Eden Madrid?
Estas preguntas me las habéis hecho varios y creo que a todos os he contestado lo mismo. De momento, yo me quedo en Winchester continuando con mi apprenticeship. Si todo va bien espero quedarme en Eden una vez termine, ya os iré contando. Respecto a Eden Madrid, aún no se nada.
Los edenitas
Como ya os conté durante mi internship, los edenitas molan todo y más :D Todos me están ayudando mucho a integrarme en Eden (tanto personalmente como profesionalmente), especialmente mi mentora, Aimee :)
Quiero hacer una mención especial para mi compañera de aprendizaje, Despo :D Compartir el apprenticeship con alguien que está pasando por la misma experiencia ayuda a no sucumbir a la presión que nos auto-imponemos. ¡Gracias, Despo!
Pair programming
Todo lo que programo en Eden lo programo haciendo pair programming. No estaba acostumbrado pero tengo que decir que es muy divertido, muy cansado y mucho más productivo (al menos para mi).
Es más divertido porque no estás solo :D Siempre tienes alguien con quien hablar :P
Es muy cansado porque te obliga a estar a tope de concentración. Echando cuentas, creo que el máximo de pomodoros que he conseguido terminar en un día han sido 10, que vienen a ser 4 horas y cuarto... Y sin embargo termino mucho más cansado que cuando trabajo solo en casa.
Es más productivo porque es mucho más difícil relajar las buenas prácticas. Siempre tienes a alguien al lado diciendo cosas como "Creo que ese nombre no es correcto" o "¿No deberíamos hacer un test antes?".
Futuro
No se lo que me deparará el futuro. Lo que tengo claro es que pienso disfrutar el presente :D
¡Abrazos!
Enrique continúa su largo camino
Estas tres semanas han dado para mucho pero, probablemente, lo más importante es la marcha de Enrique.
Como para muchos de vosotros, Enrique es una fuente de inspiración tanto en lo personal como en la profesional. Creo que soy muy afortunado por haberle conocido y por poder trabajar con él. ¡Gracias, Enrique! ¡Te deseo muchos éxitos y felicidad mientras cumples tus sueños!
Por suerte, Enrique se queda hasta abril (o no, depende de varias cosas :D ) en Winchester, así que aún podré disfrutar de su compañía algún tiempo más :)
Pero entonces ¿tú que haces?, ¿te quedas en Winchester o te vuelves a Madrid? ¿Qué pasa con Eden Madrid?
Estas preguntas me las habéis hecho varios y creo que a todos os he contestado lo mismo. De momento, yo me quedo en Winchester continuando con mi apprenticeship. Si todo va bien espero quedarme en Eden una vez termine, ya os iré contando. Respecto a Eden Madrid, aún no se nada.
Los edenitas
Como ya os conté durante mi internship, los edenitas molan todo y más :D Todos me están ayudando mucho a integrarme en Eden (tanto personalmente como profesionalmente), especialmente mi mentora, Aimee :)
Quiero hacer una mención especial para mi compañera de aprendizaje, Despo :D Compartir el apprenticeship con alguien que está pasando por la misma experiencia ayuda a no sucumbir a la presión que nos auto-imponemos. ¡Gracias, Despo!
Pair programming
Todo lo que programo en Eden lo programo haciendo pair programming. No estaba acostumbrado pero tengo que decir que es muy divertido, muy cansado y mucho más productivo (al menos para mi).
Es más divertido porque no estás solo :D Siempre tienes alguien con quien hablar :P
Es muy cansado porque te obliga a estar a tope de concentración. Echando cuentas, creo que el máximo de pomodoros que he conseguido terminar en un día han sido 10, que vienen a ser 4 horas y cuarto... Y sin embargo termino mucho más cansado que cuando trabajo solo en casa.
Es más productivo porque es mucho más difícil relajar las buenas prácticas. Siempre tienes a alguien al lado diciendo cosas como "Creo que ese nombre no es correcto" o "¿No deberíamos hacer un test antes?".
Futuro
No se lo que me deparará el futuro. Lo que tengo claro es que pienso disfrutar el presente :D
¡Abrazos!
domingo, 20 de febrero de 2011
Omniauth, Twitter and BDD
Today I've (almost) integrated Twitter authentication for Let's walk the path together! I've used the omniauth gem to achieve this task. Thanks to this railscast, it is very easy to understand how to do it. But, we are doing BDD, aren't we? How do we do BDD against Twitter? That's what I'm going to tell you today :D
Omniauth
OmniAuth is a Rack-based authentication system for twitter (and many other services). Its rack middleware is the one that talks with twitter and puts the twitter user data in the env variable. You can watch the railcast to see an explanation of how it works (it's only 8 minutes).
BDD
Ok, I know how to integrate Twitter authentication in my application. How do I test it? How do I continue with my BDD cycle? When we are testing our application, we don't want to rely on the actual Twitter service. It will make our tests slower and brittle. We need to have control of our tests, so we need to fake the Twitter server. Fortunately, doing it with omniauth is very easy.
We only need to put omniauth in test mode and give it the information we want to receive from Twitter in our test:
In this case, we're telling omniauth to, when asked about Twitter, give us the provider, the user uid and the user name.
We can integrate this easy in a cucumber hook, or even in a cucumber step, to mock the Twitter server and continue with our BDD cycle :D
Omniauth
OmniAuth is a Rack-based authentication system for twitter (and many other services). Its rack middleware is the one that talks with twitter and puts the twitter user data in the env variable. You can watch the railcast to see an explanation of how it works (it's only 8 minutes).
BDD
Ok, I know how to integrate Twitter authentication in my application. How do I test it? How do I continue with my BDD cycle? When we are testing our application, we don't want to rely on the actual Twitter service. It will make our tests slower and brittle. We need to have control of our tests, so we need to fake the Twitter server. Fortunately, doing it with omniauth is very easy.
We only need to put omniauth in test mode and give it the information we want to receive from Twitter in our test:
In this case, we're telling omniauth to, when asked about Twitter, give us the provider, the user uid and the user name.
We can integrate this easy in a cucumber hook, or even in a cucumber step, to mock the Twitter server and continue with our BDD cycle :D
jueves, 17 de febrero de 2011
BDD y descargas de ficheros auto-generados
La semana pasada, Tom y yo necesitábamos comprobar que un informe se descargaba correctamente desde la aplicación. Dicho informe era una hoja excel generada a partir de los datos contenidos en la base de datos. ¿Os interesa saber cómo lo hicimos? Os lo voy a contar con un ejemplo algo más simple :D
Escenario
Empecemos creando un escenario en cucumber. Queremos descargar un catálogo de productos generado por nuestra aplicación:
Steps
El given simplemente crea un producto en el sistema y el when descarga el catálogo:
Muy bien, hemos descargado el fichero al pulsar el enlace pero, ¿cómo accedemos a dicho fichero cuando estoy usando capybara y rack-test? Se me ocurren dos cosas. La primera es usar selenium en lugar de rack-test, haciendo que nuestros tests sean muuucho más lentos. La otra es obtener el bytestream del fichero descargado que, por si no lo sabíais, está en el body de la página obtenida tras hacer click en el enlace de descarga:
Esto tan simple funciona porque, en nuestro caso, estamos descargando un fichero de texto plano. Si en lugar de un texto plano tenemos, por ejemplo, un fichero Excel solo necesitamos parsear los bytes que nos llegan en el body con un objeto que entienda el formato Excel. Nosotros utilizamos la gema Spreadsheet (Cuidado con pronunciarlo spred-shit que queda muy feo :P )
¡Esto es todo, amigos! Un saludo
Escenario
Empecemos creando un escenario en cucumber. Queremos descargar un catálogo de productos generado por nuestra aplicación:
Steps
El given simplemente crea un producto en el sistema y el when descarga el catálogo:
Muy bien, hemos descargado el fichero al pulsar el enlace pero, ¿cómo accedemos a dicho fichero cuando estoy usando capybara y rack-test? Se me ocurren dos cosas. La primera es usar selenium en lugar de rack-test, haciendo que nuestros tests sean muuucho más lentos. La otra es obtener el bytestream del fichero descargado que, por si no lo sabíais, está en el body de la página obtenida tras hacer click en el enlace de descarga:
Esto tan simple funciona porque, en nuestro caso, estamos descargando un fichero de texto plano. Si en lugar de un texto plano tenemos, por ejemplo, un fichero Excel solo necesitamos parsear los bytes que nos llegan en el body con un objeto que entienda el formato Excel. Nosotros utilizamos la gema Spreadsheet (Cuidado con pronunciarlo spred-shit que queda muy feo :P )
¡Esto es todo, amigos! Un saludo
lunes, 7 de febrero de 2011
Resistencia
Hace más o menos un mes, mi novia me regaló "Linchpin", un libro de Seth Godin. Si no lo habéis leido, leedlo.
Aunque prácticamente debería copiar el libro palabra por palabra, hoy solo voy a hablar de una de las partes que más me han llamado la atención, la resistencia
La resistencia
¿Alguna vez os habéis puesto una excusa para no hacer algo? Yo os pongo algunas de las mías:
"Me gusta esa chica pero no voy a decirle nada no vaya a ser que pase de mi"
"No voy a proponer nada para el open porque eso de hablar en público no me gusta nada"
"Podría solicitar ese puesto pero ¿que va a pasar con mi vida si me cogen? Mejor lo dejo pasar"
Lo que tienen en común todas esas frases es que yo soy el que pone los impedimentos, nadie más. Yo soy el que me impide alcanzar nuevas metas, yo soy el que no me deja evolucionar, yo soy el único responsable de mi propio futuro. Cualquier otra causa que sea capaz de pensar es una excusa creada por la resistencia.
Pasar a la acción
Últimamente estoy intentando vencer siempre que puedo a esa resistencia. Cada vez que me doy cuenta de que estoy pensando alguna excusa para no hacer una tarea, dejo de pensar y me pongo a hacerla. Así es como he decidido que mi primera charla en Eden trate sobre javascript (un lenguaje que desconozco), o que la tecnología que quiero enseñar al resto de edenitas (españolizando el término) sea node.js.
¿Qué puede ser lo peor que puede pasar? Por mucho que mi cerebro de reptil me diga lo contrario, lo peor que puede pasar es que aprenda algo nuevo.
Un saludo
Aunque prácticamente debería copiar el libro palabra por palabra, hoy solo voy a hablar de una de las partes que más me han llamado la atención, la resistencia
La resistencia
¿Alguna vez os habéis puesto una excusa para no hacer algo? Yo os pongo algunas de las mías:
"Me gusta esa chica pero no voy a decirle nada no vaya a ser que pase de mi"
"No voy a proponer nada para el open porque eso de hablar en público no me gusta nada"
"Podría solicitar ese puesto pero ¿que va a pasar con mi vida si me cogen? Mejor lo dejo pasar"
Lo que tienen en común todas esas frases es que yo soy el que pone los impedimentos, nadie más. Yo soy el que me impide alcanzar nuevas metas, yo soy el que no me deja evolucionar, yo soy el único responsable de mi propio futuro. Cualquier otra causa que sea capaz de pensar es una excusa creada por la resistencia.
Pasar a la acción
Últimamente estoy intentando vencer siempre que puedo a esa resistencia. Cada vez que me doy cuenta de que estoy pensando alguna excusa para no hacer una tarea, dejo de pensar y me pongo a hacerla. Así es como he decidido que mi primera charla en Eden trate sobre javascript (un lenguaje que desconozco), o que la tecnología que quiero enseñar al resto de edenitas (españolizando el término) sea node.js.
¿Qué puede ser lo peor que puede pasar? Por mucho que mi cerebro de reptil me diga lo contrario, lo peor que puede pasar es que aprenda algo nuevo.
Un saludo
jueves, 3 de febrero de 2011
Apprentice at Eden Development
Here I am! I'm an apprentice at Eden Development :D I'm very happy to be here and I want to share this experience with you.
Apprenticeship and Eden
Even though Eden is all into the Software craftsmanship, Despo and I are their first full-time apprentices, so we'll improve the process as we walk the road :D We're going to do two month iterations with all Eden and one week iterations with Aimee (our mentor).
Apprentice expectations
Last monday, Chris and Aimee told us about the kind of things they're expecting from us.
Apprentice tasks
Apart from the expectations, they also told us some "mandatory" things, so I have a lot of homework :P
I must write one blog post every week. I don't really think that's going to be a problem given my previous internship ;) I'll try to write twice a week (once in English and once in Spanish)
I must give an Eden talk every month. Since all Eden talks are already booked until March, I'll do the first one on March 1st. The talk is titled "Javascript, I didn't know that!" and I'm going to do a javascript koans session.
I must do an apprenticeship ongoing project. I want to continue growing Let's walk the path together! I want it to be a useful resource for the spanish developer community so, if you want me to add some features just tell me about it. I also have to do a presentation about the project every two months (code review and retrospective included).
There is one more thing I have to do during my apprenticeship. I have to teach some technology to the edenites! I don't know yet what I'm going to do with that...
As you can see, I have a big challenge ahead!
Apprenticeship and Eden
Even though Eden is all into the Software craftsmanship, Despo and I are their first full-time apprentices, so we'll improve the process as we walk the road :D We're going to do two month iterations with all Eden and one week iterations with Aimee (our mentor).
Apprentice expectations
Last monday, Chris and Aimee told us about the kind of things they're expecting from us.
- Real world experience of client work
- Ability to grasp complex logic
- Confidence to change code (sometimes unattended)
- Humility
- Admitting to mistakes
- A good grasp of TDD
Apprentice tasks
Apart from the expectations, they also told us some "mandatory" things, so I have a lot of homework :P
I must write one blog post every week. I don't really think that's going to be a problem given my previous internship ;) I'll try to write twice a week (once in English and once in Spanish)
I must give an Eden talk every month. Since all Eden talks are already booked until March, I'll do the first one on March 1st. The talk is titled "Javascript, I didn't know that!" and I'm going to do a javascript koans session.
I must do an apprenticeship ongoing project. I want to continue growing Let's walk the path together! I want it to be a useful resource for the spanish developer community so, if you want me to add some features just tell me about it. I also have to do a presentation about the project every two months (code review and retrospective included).
There is one more thing I have to do during my apprenticeship. I have to teach some technology to the edenites! I don't know yet what I'm going to do with that...
As you can see, I have a big challenge ahead!
jueves, 23 de diciembre de 2010
There is no way back
Today, I have finished my internship at Eden Development. After this month, I think I know what Eden is (for me, at least). Eden is a group of good people who care about what they do. It has been really awesome to work with you, guys! Thanks for everything :)
I came here with a lot of questions and I am leaving with the certainty that other companies are possible. Much more fun, more responsible, better companies :)
I have been tracking my feelings about my internship with MercuryApp and here is the result:
As you can see, it has been a great month :D The neutral days were the snowy saturdays or sundays.
The best ones are more interesting. They were the days I did pair programming with Aimee and Enrique. Think about it, the best days were the ones I did pair programming and, you know what, every day is like that for the edenites :D
I also enjoyed a lot the plage-presentation days, even though I do not like to speak in public. They were my opportunity to offer something to Eden (besides translations :P).
The rest of the days were "just funny days" :D
I also appreciate that Enrique has forced me to write an article every day. I am looking forward to read them :D
Thank you, Eden, for given me this opportunity :D It has been a life changing experience.
PS: I have liked Eden so much that I have stuck their sticker on my mac :D
I came here with a lot of questions and I am leaving with the certainty that other companies are possible. Much more fun, more responsible, better companies :)
I have been tracking my feelings about my internship with MercuryApp and here is the result:
As you can see, it has been a great month :D The neutral days were the snowy saturdays or sundays.
The best ones are more interesting. They were the days I did pair programming with Aimee and Enrique. Think about it, the best days were the ones I did pair programming and, you know what, every day is like that for the edenites :D
I also enjoyed a lot the plage-presentation days, even though I do not like to speak in public. They were my opportunity to offer something to Eden (besides translations :P).
The rest of the days were "just funny days" :D
I also appreciate that Enrique has forced me to write an article every day. I am looking forward to read them :D
Thank you, Eden, for given me this opportunity :D It has been a life changing experience.
PS: I have liked Eden so much that I have stuck their sticker on my mac :D
miércoles, 22 de diciembre de 2010
Principios detrás de "Continuous Delivery"
Mañana tengo que hacer la presentación sobre "Continuous Delivery" y todavía no se muy bien que contar, así que voy a ensayar un poco con esta entrada :P Os voy a contar los principios que guían a los autores en esto de la entrega continua.
Create repeatable, reliable process for releasing software
Para los autores, liberar software debe ser fácil. ¿Alguna vez os habéis tenido que quedar una tarde o un fin de semana preparando una puesta en producción? ¿Os ponéis nerviosos con cada entrega al cliente? Si eso pasa es porque no confiais en vuestro proceso de entrega de software, os crea incertidumbre porque no es repetible. Depende demasiado de las personas que realizan esa tarea.
Según los autores, habremos triunfado si conseguimos que entregar software sea aburrido (común).
Automate almost everything
¿Cómo conseguimos que entregar software sea aburrido? Según los autores, automatizando todo lo que podamos el proceso. Eso sí, nos avisan de que no es necesario que automaticemos todo de golpe. Podemos ser un poco más conservadores e ir resolviendo solo nuestro mayor problema.
Yo estoy de acuerdo con ellos, aunque a mi me gusta hacerlo de golpe :D Cualquier proceso manual puede ser propenso a errores, por lo que prefiero minimizarlos :P
Keep everything in version control
Se refieren a todo, desde el código fuente, por supuesto, hasta las máquinas virtuales que utilizas para montar los entornos de test, pasando por los compiladores que necesitan para crear los entregables...
En realidad, no se refieren a que lo tengas todo dentro del sistema de control de versiones, se refieren a que cada entregable y el entorno en el que se construyó debe poder ser reconstruido a partir de un número de versión. Por ejemplo, si usas maven, tener todas las librerías externas que usas anotadas con la versión, de forma que cuando reconstruyas el artefacto no uses nuevas versiones. O, si tu aplicación la van a desplegar en un Tomcat 6, tener un entorno de test asociado a la versión a reconstruir que tenga ese Tomcat 6.
Todo esto me parece un autentico pasote y no se muy bien que pensar de todo ello. Veo que, algunas cosas sí que son sencillas (código fuente, librerías externas, documentación, etc) pero no tengo ni idea de como asociar hardware a versiones de artefactos. Creo que muchas del movimiento devops está relacionado con esa parte (mencionan puppet en algún lado), pero hablo desde la ignorancia :D
If it hurts, do it more frequently, and bring the pain forward
La integración continua se basa en este principio. ¿Integrar el código de los desarrolladores cada semana duele? Pues hazlo cada minuto. Es curioso, porque es muy poco intuitivo, pero funciona: D ¿Por qué no aplicarlo al resto? Cada vez que tenemos que desplegar la aplicación en el entorno de pruebas las pasamos canutas. Despliégala con cada commit, verás como al final no duele.
Es una forma de obligarnos a mejorar nuestro proceso de desarrollo.
Build quality in
Este lo toman prestado de lean (pero lo dicen, ¡eh!) :D Cuando suene una alarma, actua en consecuencia. ¿Se rompe el build? La prioridad es arreglarlo. ¿La aplicación falla en producción? Volvemos a la versión anterior y arreglamos el error (Eso sí, para volver a la versión anterior de una forma fácil y rápida más nos vale haber cumplido el primer y segundo principio).
Done means released
Algo terminado es algo que tiene el cliente. El resto está sin terminar. Puede parecer un poco radical, pero es cierto. La solución que plantean los autores es minimizar el tiempo que pasa entre el inicio del desarrollo y la entrega al cliente.
Everybody is responsible for the delivery process
Al igual que en el Agile Testing nos dicen que las pruebas son responsabilidad de todo el equipo, aquí nos dicen que la entrega de software debe ser responsabilidad de todo el equipo también.
Continuous improvement
Este también lo toman prestado de lean y, basicamente, significa que hay que reflexionar sobre lo que hacemos y mejorar :)
Y eso es todo. Como veis, es un libro bastante ambicioso. Estoy deseando ver como se las apañan para acercarse a estos ideales :D Un saludo
Create repeatable, reliable process for releasing software
Para los autores, liberar software debe ser fácil. ¿Alguna vez os habéis tenido que quedar una tarde o un fin de semana preparando una puesta en producción? ¿Os ponéis nerviosos con cada entrega al cliente? Si eso pasa es porque no confiais en vuestro proceso de entrega de software, os crea incertidumbre porque no es repetible. Depende demasiado de las personas que realizan esa tarea.
Según los autores, habremos triunfado si conseguimos que entregar software sea aburrido (común).
Automate almost everything
¿Cómo conseguimos que entregar software sea aburrido? Según los autores, automatizando todo lo que podamos el proceso. Eso sí, nos avisan de que no es necesario que automaticemos todo de golpe. Podemos ser un poco más conservadores e ir resolviendo solo nuestro mayor problema.
Yo estoy de acuerdo con ellos, aunque a mi me gusta hacerlo de golpe :D Cualquier proceso manual puede ser propenso a errores, por lo que prefiero minimizarlos :P
Keep everything in version control
Se refieren a todo, desde el código fuente, por supuesto, hasta las máquinas virtuales que utilizas para montar los entornos de test, pasando por los compiladores que necesitan para crear los entregables...
En realidad, no se refieren a que lo tengas todo dentro del sistema de control de versiones, se refieren a que cada entregable y el entorno en el que se construyó debe poder ser reconstruido a partir de un número de versión. Por ejemplo, si usas maven, tener todas las librerías externas que usas anotadas con la versión, de forma que cuando reconstruyas el artefacto no uses nuevas versiones. O, si tu aplicación la van a desplegar en un Tomcat 6, tener un entorno de test asociado a la versión a reconstruir que tenga ese Tomcat 6.
Todo esto me parece un autentico pasote y no se muy bien que pensar de todo ello. Veo que, algunas cosas sí que son sencillas (código fuente, librerías externas, documentación, etc) pero no tengo ni idea de como asociar hardware a versiones de artefactos. Creo que muchas del movimiento devops está relacionado con esa parte (mencionan puppet en algún lado), pero hablo desde la ignorancia :D
If it hurts, do it more frequently, and bring the pain forward
La integración continua se basa en este principio. ¿Integrar el código de los desarrolladores cada semana duele? Pues hazlo cada minuto. Es curioso, porque es muy poco intuitivo, pero funciona: D ¿Por qué no aplicarlo al resto? Cada vez que tenemos que desplegar la aplicación en el entorno de pruebas las pasamos canutas. Despliégala con cada commit, verás como al final no duele.
Es una forma de obligarnos a mejorar nuestro proceso de desarrollo.
Build quality in
Este lo toman prestado de lean (pero lo dicen, ¡eh!) :D Cuando suene una alarma, actua en consecuencia. ¿Se rompe el build? La prioridad es arreglarlo. ¿La aplicación falla en producción? Volvemos a la versión anterior y arreglamos el error (Eso sí, para volver a la versión anterior de una forma fácil y rápida más nos vale haber cumplido el primer y segundo principio).
Done means released
Algo terminado es algo que tiene el cliente. El resto está sin terminar. Puede parecer un poco radical, pero es cierto. La solución que plantean los autores es minimizar el tiempo que pasa entre el inicio del desarrollo y la entrega al cliente.
Everybody is responsible for the delivery process
Al igual que en el Agile Testing nos dicen que las pruebas son responsabilidad de todo el equipo, aquí nos dicen que la entrega de software debe ser responsabilidad de todo el equipo también.
Continuous improvement
Este también lo toman prestado de lean y, basicamente, significa que hay que reflexionar sobre lo que hacemos y mejorar :)
Y eso es todo. Como veis, es un libro bastante ambicioso. Estoy deseando ver como se las apañan para acercarse a estos ideales :D Un saludo
martes, 21 de diciembre de 2010
Tipografía
Hace unos días, Spencer me pasó un par de enlaces sobre tipografía en la red. Aún no me los he leido enteros pero, de momento, me parecen muy interesantes :D
El primero de los enlaces es "web typography". En esta página nos cuentan todo lo referente a tipografía en la red, desde el principio (¿qué son las em?). Todo viene muy bien explicado (yo, que no tengo ni idea de css, me estoy enterando bastante bien de todo :D ) pero, lo realmente molón, es que está viva. Cada poco sacan nuevos artículos o actualizaciones sobre los ya escritos (añadiendo algo de css3, por ejemplo). Os recomiendo que, aunque no tengáis que tocar un css en la vida, le echéis un ojo (La introducción es bastante chula).
El segundo enlace es un articulo de Smashing Magazine en el que hablan sobre "Qué fuente usar". No os asustéis, es bastante introductorio (explican que es eso de "serif"...).
Mi única experiencia en lo referente a tipografía en la red es este blog, con eso os digo todo :P Era uno de esas cosas que no sabía que no sabía.
Leyendo esos dos enlaces, me he dado cuenta de lo bonito e importante que es seleccionar una fuente adecuada, un espacio entre lineas cómodo, etc. Se que nunca llegue a ser un buen diseñador, tampoco es mi objetivo (me parece que no tengo demasiado buen gusto :P) pero, al menos, empiezo a entender la dificultad y esfuerzo que requiere dicho trabajo.
Un saludo.
PS: Parece que el tiempo mejora y que, al final, sí que voy a poder volver a casa para la cena de nochebuena :D
El primero de los enlaces es "web typography". En esta página nos cuentan todo lo referente a tipografía en la red, desde el principio (¿qué son las em?). Todo viene muy bien explicado (yo, que no tengo ni idea de css, me estoy enterando bastante bien de todo :D ) pero, lo realmente molón, es que está viva. Cada poco sacan nuevos artículos o actualizaciones sobre los ya escritos (añadiendo algo de css3, por ejemplo). Os recomiendo que, aunque no tengáis que tocar un css en la vida, le echéis un ojo (La introducción es bastante chula).
El segundo enlace es un articulo de Smashing Magazine en el que hablan sobre "Qué fuente usar". No os asustéis, es bastante introductorio (explican que es eso de "serif"...).
Mi única experiencia en lo referente a tipografía en la red es este blog, con eso os digo todo :P Era uno de esas cosas que no sabía que no sabía.
Leyendo esos dos enlaces, me he dado cuenta de lo bonito e importante que es seleccionar una fuente adecuada, un espacio entre lineas cómodo, etc. Se que nunca llegue a ser un buen diseñador, tampoco es mi objetivo (me parece que no tengo demasiado buen gusto :P) pero, al menos, empiezo a entender la dificultad y esfuerzo que requiere dicho trabajo.
Un saludo.
PS: Parece que el tiempo mejora y que, al final, sí que voy a poder volver a casa para la cena de nochebuena :D
lunes, 20 de diciembre de 2010
Continuous Delivery
Aunque parezca mentira, ya casi ha pasado un mes desde que llegué a Eden. Hoy comienza mi última semana como interno y, como todos los lunes, ya tengo mi tarea semanal. Tengo que leerme el "Continuous Delivery" y hacer un resumen durante mi presentación :) Tenía ganas de leerlo, ahora ya tengo excusa :P
Continuous delivery está escrito por Jez Humble y David Farley, ambos thoughtworkers, y el libro entra dentro de la serie firmada por Martin Fowler. Tal y como ellos cuentan al principio, el titulo lo han sacado directamente del Manifiesto Ágil, concretamente del primero de sus principios:
Lo primero que me ha venido a la cabeza cuando he empezado a leer el libro ha sido ¿por qué necesito leer este libro? Jez y David me han dado la respuesta:
Aunque acabo de empezarlo y aún no he podido leer mucho, la idea central del libro es lo que ellos llaman el patrón "deployment pipeline" que, tal y como lo definen, es una implementación automatizada de las fases de build, deploy, test y release de la aplicación sobre la que se trabaja, es decir, automatizar al máximo todo el proceso a partir del commit.
El libro promete bastante, ya os iré contando. Un saludo.
PS: Hoy es el cumpleaños de Todd, felicitadle por twitter :D
Continuous delivery está escrito por Jez Humble y David Farley, ambos thoughtworkers, y el libro entra dentro de la serie firmada por Martin Fowler. Tal y como ellos cuentan al principio, el titulo lo han sacado directamente del Manifiesto Ágil, concretamente del primero de sus principios:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Lo primero que me ha venido a la cabeza cuando he empezado a leer el libro ha sido ¿por qué necesito leer este libro? Jez y David me han dado la respuesta:
Only when you have control over the progression of every change from introduction to release can you begin to optimize and improve the quality and speed of software delivery.
Solo cuando tengas el control sobre la progresión de cada cambio desde que lo introduces hasta que lo liberas, podrás empezar a optimizar y mejorar la calidad y velocidad de tus entregas de software
Aunque acabo de empezarlo y aún no he podido leer mucho, la idea central del libro es lo que ellos llaman el patrón "deployment pipeline" que, tal y como lo definen, es una implementación automatizada de las fases de build, deploy, test y release de la aplicación sobre la que se trabaja, es decir, automatizar al máximo todo el proceso a partir del commit.
El libro promete bastante, ya os iré contando. Un saludo.
PS: Hoy es el cumpleaños de Todd, felicitadle por twitter :D
String calculator kata
On Friday, Aimee suggested me that, in order to improve my English, I should write some of my blog entries in that language so, every now and then, I am going to write short entries in English :D
As I have told you before, I need to practice, practice and practice. The problem I have chosen to start with is the string calculator kata. For those of you who do not know this kata, it is a very simple problem. Someone gives you a string with numbers separated by a defined separator and you have to calculate the sum of that numbers. You can find the actual code-kata specification here.
This is not the first time I confront this problem, I already did it some months ago in Java. Now, I am doing it in Ruby and the code I am writing is much more precise than the one in Java. Ruby classes are more friendly than the Java ones (Manipulate Strings in java is a nightmare compared with Ruby), and everything seems simpler. I am not an expert in Ruby nor in Java, but I think Ruby is a much more friendly language to work with.
I will practice this kata every day until I feel ready to record a screencast so, Stay tuned!
Meanwhile, here is the kata done in scheme by Enrique :D
As I have told you before, I need to practice, practice and practice. The problem I have chosen to start with is the string calculator kata. For those of you who do not know this kata, it is a very simple problem. Someone gives you a string with numbers separated by a defined separator and you have to calculate the sum of that numbers. You can find the actual code-kata specification here.
This is not the first time I confront this problem, I already did it some months ago in Java. Now, I am doing it in Ruby and the code I am writing is much more precise than the one in Java. Ruby classes are more friendly than the Java ones (Manipulate Strings in java is a nightmare compared with Ruby), and everything seems simpler. I am not an expert in Ruby nor in Java, but I think Ruby is a much more friendly language to work with.
I will practice this kata every day until I feel ready to record a screencast so, Stay tuned!
Meanwhile, here is the kata done in scheme by Enrique :D
String Calculator Kata from Enrique Comba Riepenhausen on Vimeo.
viernes, 17 de diciembre de 2010
Practicar, practicar, practicar
Imagino que todos lo tendréis claro ya, pero tengo que decirlo. Tenemos que practicar mucho.
Hoy me ha tocado presentar la refactorizacion del código para internacionalizar la web. Pensaba que no estaba demasiado mal. Había partes que me gustaban más que otras pero, en general, me parecía bastante buen código... Pues, ¡sorpresa! no lo es :D Mientras explicaba lo que habíamos modificado, he ido planteando las dudas que tenía en la cabeza. Mis compañeros me han contestado, pero no de forma teórica, con las manos en la masa. Cada mejora, consejo o discusión me parecían bastante obvias, pero yo no había sido capaz de verlas antes. ¿No os ha pasado nunca? Te dicen algo y piensas, "claro, ¿cómo no se me había ocurrido nunca?
Creo que, esa dificultad en descubrir el siguiente paso se debe a que no he practicado lo suficiente hasta ahora.
Estoy utilizando Ruby, un lenguaje que no domino. Acabo de empezar con él y le he cogido el gusto a los yield, lo que provoca que mi código a veces sea demasiado listo y difícil de entender. Si quiero entender bien como usar Ruby, está claro lo que tengo que hacer, practicar :)
No tengo claro los niveles de abstracción ni los conceptos que representan, lo que me lleva a mezclarlos. Tengo que practicar con problemas simples y pensar muy bien lo que hago. Necesito aclararme la cabeza y, espero, poco a poco todo irá saliendo más natural.
Dado que no manejo bien el lenguaje y no termino de definir las abstracciones, es imposible que un diseño decente emerja... Igual que antes, tengo que practicar mucho para que todo fluya.
Siento que esta entrada sea tan cortita y ligera, pero tengo que irme a practicar :D
Un saludo
Hoy me ha tocado presentar la refactorizacion del código para internacionalizar la web. Pensaba que no estaba demasiado mal. Había partes que me gustaban más que otras pero, en general, me parecía bastante buen código... Pues, ¡sorpresa! no lo es :D Mientras explicaba lo que habíamos modificado, he ido planteando las dudas que tenía en la cabeza. Mis compañeros me han contestado, pero no de forma teórica, con las manos en la masa. Cada mejora, consejo o discusión me parecían bastante obvias, pero yo no había sido capaz de verlas antes. ¿No os ha pasado nunca? Te dicen algo y piensas, "claro, ¿cómo no se me había ocurrido nunca?
Creo que, esa dificultad en descubrir el siguiente paso se debe a que no he practicado lo suficiente hasta ahora.
Estoy utilizando Ruby, un lenguaje que no domino. Acabo de empezar con él y le he cogido el gusto a los yield, lo que provoca que mi código a veces sea demasiado listo y difícil de entender. Si quiero entender bien como usar Ruby, está claro lo que tengo que hacer, practicar :)
No tengo claro los niveles de abstracción ni los conceptos que representan, lo que me lleva a mezclarlos. Tengo que practicar con problemas simples y pensar muy bien lo que hago. Necesito aclararme la cabeza y, espero, poco a poco todo irá saliendo más natural.
Dado que no manejo bien el lenguaje y no termino de definir las abstracciones, es imposible que un diseño decente emerja... Igual que antes, tengo que practicar mucho para que todo fluya.
Siento que esta entrada sea tan cortita y ligera, pero tengo que irme a practicar :D
Un saludo
jueves, 16 de diciembre de 2010
¿Por qué?
Tenía pensado contar algo sobre como hemos puesto en producción la página internacionalizada de Eden Development, pero he cambiado de idea después de la reunión del grupo de MadriAgil :D El tema de la reunión ha sido BDD, pero lo que yo me he llevado de ella es la importancia que tiene preguntar por qué.
Si os acordais, cuando escribí sobre los valores de Eden mencionaba este:
Hoy, Enrique nos ha demostrado a todos los del grupo de Madrid la importancia que tiene para ellos preguntar por qué. Creo que nos a convencido a todos :P
Es muy importante cuestionar las motivaciones de los clientes. Obligarles a pensar en su problema, no solo en la solución. De hecho, esto es tan importante para Eden que se tiran 2 días enteros buscando respuestas a los por qué que plantean.
Sin embargo, lo que más me interesa a mi en este momento (intentando convertirme en aprendiz :P) es la parte en la que te cuestionas a ti mismo. Ahí van algunos ejemplos en distintos ámbitos:
¿Por qué he creado esta clase?
¿Por qué le he puesto ese nombre a esta variable?
¿Por qué mi código se entiende?
¿Por qué no entiendo SOLID?
¿Por qué me pongo tan nervioso cuando hablo en público?
¿Por qué no quiero ir a trabajar?
¿Por qué no soy feliz?
¿Por qué soy feliz?
Como veis, no todos los por qué tienen que llevarnos a malas conclusiones :D
Os dejo con esas preguntas (las que apliquen), pero sobre todo, con la idea de cuestionarnos tanto a nosotros mismos como a los demás, se aprende mucho :)
Un saludo.
Si os acordais, cuando escribí sobre los valores de Eden mencionaba este:
We ask "why?"
Preguntamos "¿por qué?"
Hoy, Enrique nos ha demostrado a todos los del grupo de Madrid la importancia que tiene para ellos preguntar por qué. Creo que nos a convencido a todos :P
Es muy importante cuestionar las motivaciones de los clientes. Obligarles a pensar en su problema, no solo en la solución. De hecho, esto es tan importante para Eden que se tiran 2 días enteros buscando respuestas a los por qué que plantean.
Sin embargo, lo que más me interesa a mi en este momento (intentando convertirme en aprendiz :P) es la parte en la que te cuestionas a ti mismo. Ahí van algunos ejemplos en distintos ámbitos:
¿Por qué he creado esta clase?
¿Por qué le he puesto ese nombre a esta variable?
¿Por qué mi código se entiende?
¿Por qué no entiendo SOLID?
¿Por qué me pongo tan nervioso cuando hablo en público?
¿Por qué no quiero ir a trabajar?
¿Por qué no soy feliz?
¿Por qué soy feliz?
Como veis, no todos los por qué tienen que llevarnos a malas conclusiones :D
Os dejo con esas preguntas (las que apliquen), pero sobre todo, con la idea de cuestionarnos tanto a nosotros mismos como a los demás, se aprende mucho :)
Un saludo.
miércoles, 15 de diciembre de 2010
Diseño Simple
Hoy no he podido hacer pair programming con ningún "edenite" :( Los que no estaban en proyectos, estaban liándola parda organizando cosillas para Madrid :) Preparaos para la que se nos viene encima :D Ya se están empezando a mover cosas y nos vamos a divertir mucho :D Si queréis estar informados de todo lo que se organice para Eden Madrid debéis seguir esta cuenta de twitter.
Pero a lo que iba, que me desvío :P Hoy me ha tocado enfrentarme a mi código solo (aunque Chris me ha ayudado con una cosilla que se me resistía :D ) y me ha surgido una duda que, creo :P, las 4 reglas del diseño simple han conseguido aclarar.
Las 4 reglas del diseño simple
El orden de las reglas define su importancia, por lo que, si dos reglas entran en conflicto, debemos quedarnos con la primera de las dos.
El problema
Tengo una clase que debe dar de alta en el entorno un par de variables. Ambas variables dependen de si existe una cookie con el idioma en dicho entorno, por lo que el mismo if puede valernos para dar de alta las dos variables, tal que así:
Sin embargo, el set_variables(env) del primer método no me parece lo suficientemente expresivo, así que lo he cambiado por esto:
Está claro que, en este último caso, tenemos duplicación (Nos cargamos la tercera regla), pero aumenta la legibilidad (la segunda regla). He estado dudando si dejar la duplicación o eliminarla y, al final, he decidido que me gustaba más la legibilidad del segundo caso. No estoy seguro de si es lo correcto, veremos mañana cuando programe con un "edenite" al lado :D A vosotros, ¿qué os parece?
Un saludo.
PD: Spencer me ha pasado hoy este enlace sobre tipografía en la web. No lo he podido leer todavía, pero parece muy molón :D
Pero a lo que iba, que me desvío :P Hoy me ha tocado enfrentarme a mi código solo (aunque Chris me ha ayudado con una cosilla que se me resistía :D ) y me ha surgido una duda que, creo :P, las 4 reglas del diseño simple han conseguido aclarar.
Las 4 reglas del diseño simple
- Runs all the tests.
- Expresses every idea that we need to express.
- Says everything OnceAndOnlyOnce.
- Has no superfluous parts.
- Pasan todos los tests.
- Expresa cada idea que necesitamos expresar.
- Dice lo que dice una única vez.
- No tiene partes superfluas.
El orden de las reglas define su importancia, por lo que, si dos reglas entran en conflicto, debemos quedarnos con la primera de las dos.
El problema
Tengo una clase que debe dar de alta en el entorno un par de variables. Ambas variables dependen de si existe una cookie con el idioma en dicho entorno, por lo que el mismo if puede valernos para dar de alta las dos variables, tal que así:
Sin embargo, el set_variables(env) del primer método no me parece lo suficientemente expresivo, así que lo he cambiado por esto:
Está claro que, en este último caso, tenemos duplicación (Nos cargamos la tercera regla), pero aumenta la legibilidad (la segunda regla). He estado dudando si dejar la duplicación o eliminarla y, al final, he decidido que me gustaba más la legibilidad del segundo caso. No estoy seguro de si es lo correcto, veremos mañana cuando programe con un "edenite" al lado :D A vosotros, ¿qué os parece?
Un saludo.
PD: Spencer me ha pasado hoy este enlace sobre tipografía en la web. No lo he podido leer todavía, pero parece muy molón :D
martes, 14 de diciembre de 2010
Código expresivo
Como os conté ayer, he comenzado un nuevo show que me gusta llamar "limpiemos el código que he creado". El invitado especial de hoy ha sido Enrique Comba, y tengo que decir que Aimee es una gran profesora :D Bueeeno, Enrique también es buen profe :P Ahora en serio, he estado programando todo le día con Enrique y me lo he pasado muy bien :D ¡Muchas gracias, Enrique!
Código expresivo
Lo que más me ha gustado de programar con Enrique es la importancia que le da a que el código sea expresivo. Hemos pasado mucho tiempo buscando buenos nombres y preguntándonos como conseguir que el código hablara por si mismo. Todo ese pensar, que muchas veces yo no hago :P, nos ha llevado a un código mucho más simple y entendible que el que había. No hemos conseguido terminar de limpiar, pero hemos avanzado bastante :D
Aunque siempre intento buscar nombres correctos cuando programo, hoy me he dado cuenta que soy muy vago. De hecho, comparado con Enrique, prácticamente no uso mi cerebro para pensar en el naming o para darle vueltas al código, de forma que sea más expresivo. Ojo, yo pensaba que sí que tenía cuidado, pero me he dado cuenta de que necesito ser mucho más responsable y tener mucha más autodisciplina. Para mi, no es fácil "perder" tanto tiempo intentando hacer que mi código sea lo más expresivo posible. Hoy creo que he aprendido a calmarme y a pensar bien lo que hago, aunque está claro que necesito practicar mucho.
Pequeños éxitos
Si aún no habéis programado con Enrique, os tengo que decir que es muy divertido (es un poco ganso :P ). A parte de lo mucho que sabe (he aprendido mucho sobre como refactorizar y un poco más de vi), siempre que limpiábamos algo un poco más complejo y conseguíamos que todos los tests estuvieran en verde, lo celebrábamos con un "high five" :) Parece una tontería, pero esas celebraciones son un reconocimiento al trabajo bien hecho y motivan para afrontar el siguiente cambio.
Pair programming
No es fácil hacer código que entienda mucha gente si solo trabajas tú en él. Hoy me he dado cuenta de lo importante que es tener a alguien al lado que lea lo que escribes y opine sobre ello. No he hecho mucho pair programming, por lo que no puedo comparar, pero el de hoy me ha parecido muy comunicativo. Ambas partes opinábamos sobre el código (aunque yo aveces no sabía como mejorarlo o como expresar lo que quería hacer :P) y lo íbamos "enriqueciendo", haciendolo más simple y más comunicativo. Creo que esa comunicación (feedback instantáneo sobre el código que escribes) es una de las mayores ventajas del pair programming.
Además, mientras haces pair programming es más complicado que vaguees a la hora de limpiar el código. La otra persona te puede dar un capón y ponerte en tu sitio :P
Cucumber
Respecto a los escenarios de cucumber, hemos dejado de hablar de locales y, como decía calavera en los comentarios de la anterior entrada, lo hemos cambiado por idiomas. Creo que la especificación de la funcionalidad ha quedado algo más clara, aunque puede que cuando la vuelva a leer se me ocurra otro cambio :P
Otras cosas
A parte de pasar el día programando con Enrique, que ya mola un montón, Aimee no ha dado una charla sobre como ha integrado MongoDB en su Merlin's castle :D ¿Cuanto mola eso? No se, creo que casi infinito. Tener unos compañeros así creo que no tiene precio :D
Oops, dinner's ready! Un saludo.
Actualizado: La charla sobre MongoDB la podéis ver aquí. ¡Muchas gracias por compartirla, Aimee!
Código expresivo
Lo que más me ha gustado de programar con Enrique es la importancia que le da a que el código sea expresivo. Hemos pasado mucho tiempo buscando buenos nombres y preguntándonos como conseguir que el código hablara por si mismo. Todo ese pensar, que muchas veces yo no hago :P, nos ha llevado a un código mucho más simple y entendible que el que había. No hemos conseguido terminar de limpiar, pero hemos avanzado bastante :D
Aunque siempre intento buscar nombres correctos cuando programo, hoy me he dado cuenta que soy muy vago. De hecho, comparado con Enrique, prácticamente no uso mi cerebro para pensar en el naming o para darle vueltas al código, de forma que sea más expresivo. Ojo, yo pensaba que sí que tenía cuidado, pero me he dado cuenta de que necesito ser mucho más responsable y tener mucha más autodisciplina. Para mi, no es fácil "perder" tanto tiempo intentando hacer que mi código sea lo más expresivo posible. Hoy creo que he aprendido a calmarme y a pensar bien lo que hago, aunque está claro que necesito practicar mucho.
Pequeños éxitos
Si aún no habéis programado con Enrique, os tengo que decir que es muy divertido (es un poco ganso :P ). A parte de lo mucho que sabe (he aprendido mucho sobre como refactorizar y un poco más de vi), siempre que limpiábamos algo un poco más complejo y conseguíamos que todos los tests estuvieran en verde, lo celebrábamos con un "high five" :) Parece una tontería, pero esas celebraciones son un reconocimiento al trabajo bien hecho y motivan para afrontar el siguiente cambio.
Pair programming
No es fácil hacer código que entienda mucha gente si solo trabajas tú en él. Hoy me he dado cuenta de lo importante que es tener a alguien al lado que lea lo que escribes y opine sobre ello. No he hecho mucho pair programming, por lo que no puedo comparar, pero el de hoy me ha parecido muy comunicativo. Ambas partes opinábamos sobre el código (aunque yo aveces no sabía como mejorarlo o como expresar lo que quería hacer :P) y lo íbamos "enriqueciendo", haciendolo más simple y más comunicativo. Creo que esa comunicación (feedback instantáneo sobre el código que escribes) es una de las mayores ventajas del pair programming.
Además, mientras haces pair programming es más complicado que vaguees a la hora de limpiar el código. La otra persona te puede dar un capón y ponerte en tu sitio :P
Cucumber
Respecto a los escenarios de cucumber, hemos dejado de hablar de locales y, como decía calavera en los comentarios de la anterior entrada, lo hemos cambiado por idiomas. Creo que la especificación de la funcionalidad ha quedado algo más clara, aunque puede que cuando la vuelva a leer se me ocurra otro cambio :P
Otras cosas
A parte de pasar el día programando con Enrique, que ya mola un montón, Aimee no ha dado una charla sobre como ha integrado MongoDB en su Merlin's castle :D ¿Cuanto mola eso? No se, creo que casi infinito. Tener unos compañeros así creo que no tiene precio :D
Oops, dinner's ready! Un saludo.
Actualizado: La charla sobre MongoDB la podéis ver aquí. ¡Muchas gracias por compartirla, Aimee!
Suscribirse a:
Entradas (Atom)
