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"
domingo, 27 de febrero de 2011
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
miércoles, 9 de febrero de 2011
Specify exactly what you want to happen and no more
There is a discussion in the spanish TDD group about whether it is good or bad, when you have a stub object, to return a different value depending on the input arguments of the method. I don't think it's the right thing to do because, normally, when a stub object cares about the input arguments in its method calls it's because it should not be a stub object, it should be a mock object. Let me explain it with an example:
The payment gateway is a stub that returns true when user_has_funds is called with an input argument of 50.
If we look carefully at the test, what we are really doing is testing more than one behavior. First, we're asserting that a user can buy stuff if she has sufficient funds. Second, we are expecting that the payment gateway is called with the right amount.
So, if it is an expectation, why don't we use a mock instead of a stub? We're mixing the concepts of mock and stub and, as a consequence, we're testing more than one thing.We're breaking the single responsibility principle.
Steve Freeman and Nat Pryce, authors of the great Growing objects oriented software, guided by tests, recommend to follow a simple rule of thumb, "specify exactly what you want to happen and no more". If we listen to them (and we should!), those are the resulting tests:
The first test specifies the relationship between the order and the payment gateway (The message protocol). It uses a mock object to replace the gateway payment object and it expects a call at user_has_funds method with the order amount as an input argument. We want to know that the payment gateway is going to be called with the right amount, so we are interested in its input argument (which is right when mocking). The second one specifies the behavior of the order when the user has funds, and I don't really care about how the order interacts with the payment gateway. I just want to know that the user has sufficient funds. That's why, in this case, we use a stub.
What I like about the new tests is that, if we change the order behavior by adding some taxes to the product price, the second test is not going to break (we still confirm the order if the payment gateway says that the user has funds, nothing has changed in that specification). Only the first one would be red (and for the right cause, we've changed exactly that specification).
What do you think?
PS: I know that, in RSpec:mocks, stub() is an alias for mock() and I don't like it very much :P
The payment gateway is a stub that returns true when user_has_funds is called with an input argument of 50.
If we look carefully at the test, what we are really doing is testing more than one behavior. First, we're asserting that a user can buy stuff if she has sufficient funds. Second, we are expecting that the payment gateway is called with the right amount.
So, if it is an expectation, why don't we use a mock instead of a stub? We're mixing the concepts of mock and stub and, as a consequence, we're testing more than one thing.We're breaking the single responsibility principle.
Steve Freeman and Nat Pryce, authors of the great Growing objects oriented software, guided by tests, recommend to follow a simple rule of thumb, "specify exactly what you want to happen and no more". If we listen to them (and we should!), those are the resulting tests:
The first test specifies the relationship between the order and the payment gateway (The message protocol). It uses a mock object to replace the gateway payment object and it expects a call at user_has_funds method with the order amount as an input argument. We want to know that the payment gateway is going to be called with the right amount, so we are interested in its input argument (which is right when mocking). The second one specifies the behavior of the order when the user has funds, and I don't really care about how the order interacts with the payment gateway. I just want to know that the user has sufficient funds. That's why, in this case, we use a stub.
What I like about the new tests is that, if we change the order behavior by adding some taxes to the product price, the second test is not going to break (we still confirm the order if the payment gateway says that the user has funds, nothing has changed in that specification). Only the first one would be red (and for the right cause, we've changed exactly that specification).
What do you think?
PS: I know that, in RSpec:mocks, stub() is an alias for mock() and I don't like it very much :P
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!
Suscribirse a:
Entradas (Atom)
