Hace tiempo que pensaba en cambiar de blog. Quería algo que no implicara acceder a la web para escribir y publicar, y quería ser yo el que alojara los posts (y no google).
Hace poco encontré lo que estaba buscando en Github, y ahora podéis seguirme en:
http://blog.plagelao.com
Un saludo y ¡Adios blogger!
sábado, 23 de julio de 2011
domingo, 15 de mayo de 2011
Autotest: friend or foe
For all of you who don't know what autotest is, it's just a ruby gem that lets you run your tests automatically in the background every time you make a change either in your code or in your tests. It is very clever, and a lot of people use it. You can see some examples in almost every screencast of a kata written in ruby.
Why I don't like autotest
Well, it's not that I don't like it. It is a very cool project and I've used it sometimes while performing a kata. My real problem with it is that it breaks the TDD cycle. Let me explain myself.
Running the test should be a blocking step
When we are doing TDD, we run the tests to get feedback. Then, we use that feedback to guide our code/design.
When we use autotest we are not waiting for the tests to fail, we just continue coding, ruining the TDD cycle.
Wait a second, I do not write any code till autotest tells me that there is a failing test.
Well done. Why are you using autotest then?
Update: Talking with Tom Brand the other day, he said that maybe it is ok to use autotest in the refactoring phase. I think he is right :)
Why I don't like autotest
Well, it's not that I don't like it. It is a very cool project and I've used it sometimes while performing a kata. My real problem with it is that it breaks the TDD cycle. Let me explain myself.
Running the test should be a blocking step
When we are doing TDD, we run the tests to get feedback. Then, we use that feedback to guide our code/design.
When we use autotest we are not waiting for the tests to fail, we just continue coding, ruining the TDD cycle.
Wait a second, I do not write any code till autotest tells me that there is a failing test.
Well done. Why are you using autotest then?
Update: Talking with Tom Brand the other day, he said that maybe it is ok to use autotest in the refactoring phase. I think he is right :)
miércoles, 27 de abril de 2011
XGN y Software Craftsmanship
Hace una semana estuve pasándomelo pipa en la #XGN de Santiago de Compostela (Muchas gracias a la organización, que nos trató muy bien y muchas gracias a mis anfitriones de agil-az, que me llevaron a cenar cosas muy ricas). Alfredo Casado y yo dimos un par de charlas técnicas (refactorización y continuous delivery) y una charla sobre Software Craftsmanship.
Si quieres ver la presentación de la charla, aquí la tienes:
Pete McBreen - Software Craftsmanship: The new imperative
Si quieres ver la presentación de la charla, aquí la tienes:
Software Craftsmanship: Convierte tu vida profesional en una Lan Party
No tiene mucho sentido verla sin nosotros, porque casi todo son imágenes, pero podemos resumirla en esta cita de Pete McBreen:View more presentations from plagelao
Software development is meant to be fun, if it isn't, the process is wrong
El desarrollo de software se supone que es divertido, si no lo es, el proceso es incorrecto
Pete McBreen - Software Craftsmanship: The new imperative
lunes, 25 de abril de 2011
5 Things I want to do today!
Two weeks ago I was in Edinburgh. I attended the Scottish Ruby Conference and it was awesome! I met a lot of great people and I enjoyed a lot of great talks. But I want to talk today about one of the lightning talks that I had the pleasure to attend. It was not about code, technology or robots, it was about how to manage your time and how to set your priorities.
The idea
The idea is very simple. Before going to sleep, you have to write down the 5 most important things you want to do tomorrow. Once you've written them down, you have to prioritize them. Then, the next day you have to do the first task in your list. Once you finish the first task, you have to start with the second task. It goes on and on until you finish the 5 tasks or the day ends :P
The reality (My reality)
I've been doing this for two weeks, so I'm not an "expert" :P but I have some conclusions to share.
First of all, I feel much more productive :D "Planning" what to do the next day helps me to focus on the important things and shows me how difficult it is to achieve everything I want to do (pretty obvious. You can't do everything you want in a day :D )
Second, it is not easy to follow your plan :D I always start with my first task, and most of the times I continue with the second one, but, eventually, I get distracted. The thing is, there are a lot of things I want to do, and limiting myself to only five is not easy. Also, some of the tasks on the list are really bored (but still important), so sometimes I just ignore them...
Some other times, I just "forget" the priorities :)
And last, but not least, is not easy to write down the five most important things you have to do the next day.
Anyway, I think that this simple method is helping me a lot, and I recommend all of you to give it a try. Even if you are not able to follow "the rules", it is a great exercise.
The idea
The idea is very simple. Before going to sleep, you have to write down the 5 most important things you want to do tomorrow. Once you've written them down, you have to prioritize them. Then, the next day you have to do the first task in your list. Once you finish the first task, you have to start with the second task. It goes on and on until you finish the 5 tasks or the day ends :P
The reality (My reality)
I've been doing this for two weeks, so I'm not an "expert" :P but I have some conclusions to share.
First of all, I feel much more productive :D "Planning" what to do the next day helps me to focus on the important things and shows me how difficult it is to achieve everything I want to do (pretty obvious. You can't do everything you want in a day :D )
Second, it is not easy to follow your plan :D I always start with my first task, and most of the times I continue with the second one, but, eventually, I get distracted. The thing is, there are a lot of things I want to do, and limiting myself to only five is not easy. Also, some of the tasks on the list are really bored (but still important), so sometimes I just ignore them...
Some other times, I just "forget" the priorities :)
And last, but not least, is not easy to write down the five most important things you have to do the next day.
Anyway, I think that this simple method is helping me a lot, and I recommend all of you to give it a try. Even if you are not able to follow "the rules", it is a great exercise.
martes, 12 de abril de 2011
BDD y Continuous Delivery en la XGN
Este fin de semana estaré en la XGN de Santiago de Compostela y voy a intentar picaros un poco para que os animéis a venir. Como ya os conté, tengo tres sesiones junto con Alfredo Casado, pero hoy os voy a hablar de Teo crea su primera aplicación web (con Rails, Git y Heroku). La idea para esta sesión es hacer un taller en el que crearemos una aplicación web en Heroku utilizando Rails. Sin embargo, para hacerlo un poco más interesante, lo vamos a hacer al estilo Software Craftsmanship, lo vamos a hacer usando BDD y Continuous Delivery. ¿Os hace?
Continuous Delivery
Vamos a aprovechar lo fácil que nos pone las cosas Heroku para practicar (y entender) un poco eso de Continuous Delivery. Veremos lo que mola desplegar con cada commit y el nos daremos cuenta del cuidado que hay que tener cuando desarrollamos software (y no solo mientras escribimos el código).
BDD
Dado que vamos a desplegar la aplicación en el entorno de producción prácticamente con cada commit, necesitamos definir exactamente cada feature que vamos a desplegar. Para ello utilizaremos BDD (Utilizaremos Cucumber) de forma que cada vez que todas nuestras features ejecutables estén verdes podamos desplegar la aplicación sin ningún temor :D
Una pequeña cuña aquí. Nos vamos a dar cuenta de la importancia que tiene definir buenas historias de usuario de forma que nos sea sencillo crear features pequeñas y deployables. Por eso, os recomiendo el dojo de historias de usuario de los agilismo.es
Entorno
Si os apetece participar en el taller tenéis un par de opciones, podéis traer vuestro ordenador con git y ruby instalado o podéis traer vuestro ordenador con VirtualBox instalado y yo me encargo de daros una máquina virtual con todo instalado (Eso sí, esa máquina será un Linux con Vim como editor, ya os aviso :P).
Si os da tiempo, nos ahorraríamos algo de tiempo si os hacéis una cuenta en Heroku antes de asistir al taller.
Otra opción es que vengáis a cotillear, que también vale, pero es un poco más aburrido.
Ya sabéis, si quereis darle caña al continuous delivery no os podéis perder esta sesión. ¡Os espero!
PS: Por cierto, la aplicación que vamos a crear nos va a servir para sortear un par de Apprenticeship Patterns en la sesión sobre Software Craftsmanship, así que no podemos fallar :P
ACTUALIZACIÓN: Os cuento un poco las versiones de ruby y de las gemas que vamos a utilizar:
La versión de ruby será la 1.8.7
La versión de Rails será la 3.0.3.
Necesitamos también la gema de heroku, claro.
Después usaremos cucumber-rails y capybara. También le daremos al haml (haml-rails es la gema) y al Sass :D
Continuous Delivery
Vamos a aprovechar lo fácil que nos pone las cosas Heroku para practicar (y entender) un poco eso de Continuous Delivery. Veremos lo que mola desplegar con cada commit y el nos daremos cuenta del cuidado que hay que tener cuando desarrollamos software (y no solo mientras escribimos el código).
BDD
Dado que vamos a desplegar la aplicación en el entorno de producción prácticamente con cada commit, necesitamos definir exactamente cada feature que vamos a desplegar. Para ello utilizaremos BDD (Utilizaremos Cucumber) de forma que cada vez que todas nuestras features ejecutables estén verdes podamos desplegar la aplicación sin ningún temor :D
Una pequeña cuña aquí. Nos vamos a dar cuenta de la importancia que tiene definir buenas historias de usuario de forma que nos sea sencillo crear features pequeñas y deployables. Por eso, os recomiendo el dojo de historias de usuario de los agilismo.es
Entorno
Si os apetece participar en el taller tenéis un par de opciones, podéis traer vuestro ordenador con git y ruby instalado o podéis traer vuestro ordenador con VirtualBox instalado y yo me encargo de daros una máquina virtual con todo instalado (Eso sí, esa máquina será un Linux con Vim como editor, ya os aviso :P).
Si os da tiempo, nos ahorraríamos algo de tiempo si os hacéis una cuenta en Heroku antes de asistir al taller.
Otra opción es que vengáis a cotillear, que también vale, pero es un poco más aburrido.
Ya sabéis, si quereis darle caña al continuous delivery no os podéis perder esta sesión. ¡Os espero!
PS: Por cierto, la aplicación que vamos a crear nos va a servir para sortear un par de Apprenticeship Patterns en la sesión sobre Software Craftsmanship, así que no podemos fallar :P
ACTUALIZACIÓN: Os cuento un poco las versiones de ruby y de las gemas que vamos a utilizar:
La versión de ruby será la 1.8.7
La versión de Rails será la 3.0.3.
Necesitamos también la gema de heroku, claro.
Después usaremos cucumber-rails y capybara. También le daremos al haml (haml-rails es la gema) y al Sass :D
viernes, 1 de abril de 2011
My Vim configuration. Part 4 - Vim as an IDE
Today I'm going to finish my Vim configuration explanation (Have a look at the previous articles). The final part of my configuration is related to the "IDE behaviour" in Vim.
Encoding
First of all, I have set my encoding to utf-8 with:
Indentation
I prefer spaces to tabs, so this is how I configure it in Vim.
Line numbers
If you want to see the line numbers in Vim you only need to do:
Backspace
Default backspace behaves in a strange way :P I've changed it so it behaves in a more "normal" way:
Search
One of the most important features in Vim is searching. I've configured mine so it is case insensitive (except if what I search has an uppercase character, then it is case sensitive)
I also want Vim to highlight my search terms:
And I have a shortcut to remove the highlighting:
There are some more little things that can help you in making a more "personal" Vim, but I'm going to stop here :) Feel free to have a look to my vimrc file or, you know, google it :P
Thanks for reading :)
Encoding
First of all, I have set my encoding to utf-8 with:
set encoding=utf-8
Indentation
I prefer spaces to tabs, so this is how I configure it in Vim.
filetype indent on set tabstop=2 set softtabstop=2 set smarttab set expandtab set autoindent
Line numbers
If you want to see the line numbers in Vim you only need to do:
set number
Backspace
Default backspace behaves in a strange way :P I've changed it so it behaves in a more "normal" way:
set backspace=indent,eol,start
Search
One of the most important features in Vim is searching. I've configured mine so it is case insensitive (except if what I search has an uppercase character, then it is case sensitive)
set ignorecase set smartcase
I also want Vim to highlight my search terms:
set incsearch set hlsearch
And I have a shortcut to remove the highlighting:
nnoremap <leader><space> :noh<cr>
There are some more little things that can help you in making a more "personal" Vim, but I'm going to stop here :) Feel free to have a look to my vimrc file or, you know, google it :P
Thanks for reading :)
martes, 22 de marzo de 2011
XGN en Santiago de Compostela
Los próximos 15, 16 y 17 de Abril estaré en la XGN presentando algunas charlas junto a Alfredo Casado. La verdad es que tengo muchas ganas de estar por allí con todos los demás participantes (la gente de axilmente, las agile girls, los agilismo.es, los funius, los 1up talent, etc). Vamos a aprender mogollón y nos lo vamos a pasar piruleta :)
He podido cotillear algunas de las charlas propuestas por algunos de estos cracks y son realmente alucinantes :) Nosotros intentaremos mantener el nivel, que no va a ser fácil. Para ello, estamos preparando:
Además, si todo lo que os he contado no os termina de convencer, se está organizando un openspace para el sábado en el que seguiremos hablando de desarrollo, agilismo, etc.
Si no tenéis reservada la fecha, reservadla ya. En serio, nos lo vamos a pasar piruleta.
PS: Iré publicando por aquí pequeños spoilers de las charlas para ir abriendo boca :P
He podido cotillear algunas de las charlas propuestas por algunos de estos cracks y son realmente alucinantes :) Nosotros intentaremos mantener el nivel, que no va a ser fácil. Para ello, estamos preparando:
- Convierte tu vida profesional en una lan party: software craftsmanship
- Teo crea su primera aplicación web (con Rails, Git y Heroku)
- ¡Si funciona no lo toques!, ¿o sí?
Además, si todo lo que os he contado no os termina de convencer, se está organizando un openspace para el sábado en el que seguiremos hablando de desarrollo, agilismo, etc.
Si no tenéis reservada la fecha, reservadla ya. En serio, nos lo vamos a pasar piruleta.
PS: Iré publicando por aquí pequeños spoilers de las charlas para ir abriendo boca :P
Suscribirse a:
Entradas (Atom)
