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
jueves, 23 de diciembre de 2010
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
Etiquetas:
Continuous delivery,
eden,
internship,
Libros
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
Etiquetas:
Agile,
Continuous delivery,
eden,
internship,
Libros
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.
Etiquetas:
coding kata,
eden,
internship,
java,
ruby
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!
Etiquetas:
eden,
internship,
pair programming
lunes, 13 de diciembre de 2010
Limpiando la casa
Como ya os dije, el viernes pasado hice la exposición de la web de Eden en español :) Durante la presentación del código, los edenites me apuntaron unas cuantas cosas a mejorar. Debía estudiar algunas tecnologías más en profundidad y tenía que intentar conseguir que mi código se explicara solo. Durante este fin de semana he estado estudiando un poco y hoy, con la ayuda de Aimee, hemos empezado a limpiar el código. Me lo he pasado muy bien con ella y he aprendido mucho. Se nota que es muy buena profesora :) Me ha hecho comprender mejor cucumber y la importancia de expresarse correctamente en el código. Cada paso que dábamos parecía obvio, pero ya os digo yo que no lo era (de hecho, la semana pasada no veía el problema tan claro :P ) y los buenos nombres aparecían prácticamente solos.
Cucumber
Hemos empezado creando los escenarios que me faltaban para completar la descripción de la funcionalidad. Realmente, viéndolo ahora mismo, creo que fui muy vago. Con deciros que yo tenía 4 escenarios y ahora estamos en 10... Hemos ido creando cada escenario (y haciéndolo funcionar) de forma que, al final, tuviéramos una buena descripción de como funciona la selección de idioma en la página.
Además, los escenarios han ganado en expresividad y robustez. Los que yo hice tenían elementos de la vista "a la vista", lo que los hacía muy frágiles, y no hablaban de la abstracción correcta. Os pongo un ejemplo del antes y el ahora:
Hemos abandonado los detalles de la vista ("software que amarás") y hablamos de localizaciones en lugar de idiomas.
Mientras escribía el gist para el ejemplo se me ha ocurrido que aún no está del todo claro. He añadido un posible escenario algo más coherente con el naming ¿Qué os parece?
Hemos dejado de hablar de cookies porque no es interesante para el usuario. Lo que aún no tengo claro es si prefiero locale o idioma... Desde el punto de vista del cliente, lo que quiere es la página en varios idiomas. Mañana lo hablaré con los edenites ¿Vosotros que opinais?
Lo que sí que he sacado en claro hoy sobre cucumber, es que hay que intentar explicar la funcionalidad desde el punto de vista del cliente (de ahí que los escenarios los escriban los clientes :P ). No nos interesa mostrar detalles de implementación. Esto es fácil decirlo, pero, al menos para mi, no es fácil de hacer. Siempre se me cuela algún detalle de implementación...
Rack middleware
Además de añadir escenarios de cucumber, aunque la experiencia de usuario sigue siendo idéntica, hemos modificado todo el código responsable de la selección del idioma.
Lo que yo hice la semana pasada era seleccionar el idioma en el mismo método que me devolvía la página, provocando que el servicio web tuviera más de una responsabilidad. Steve me lo apuntó en la demo y me dijo que mirara los middleware de rack porque podían ser una solución al problema.
Basicamente, un middleware de rack filtra las llamadas a nuestra aplicación. En nuestro caso, lo vamos a utilizar para obtener el lenguaje preferido por el usuario y para establecer una cookie que recuerde dicho lenguaje. Esto permitirá que nuestro servicio web se desentienda de la selección del lenguaje, delegando dicha responsabilidad en el middleware.
No nos ha dado tiempo a dejarlo limpio del todo, pero ha mejorado bastante :D Estoy deseando que llegue mañana para dejarlo mejor :) ¡A ver si podemos ponerlo en producción pronto!
Un saludo.
Cucumber
Hemos empezado creando los escenarios que me faltaban para completar la descripción de la funcionalidad. Realmente, viéndolo ahora mismo, creo que fui muy vago. Con deciros que yo tenía 4 escenarios y ahora estamos en 10... Hemos ido creando cada escenario (y haciéndolo funcionar) de forma que, al final, tuviéramos una buena descripción de como funciona la selección de idioma en la página.
Además, los escenarios han ganado en expresividad y robustez. Los que yo hice tenían elementos de la vista "a la vista", lo que los hacía muy frágiles, y no hablaban de la abstracción correcta. Os pongo un ejemplo del antes y el ahora:
Hemos abandonado los detalles de la vista ("software que amarás") y hablamos de localizaciones en lugar de idiomas.
Mientras escribía el gist para el ejemplo se me ha ocurrido que aún no está del todo claro. He añadido un posible escenario algo más coherente con el naming ¿Qué os parece?
Hemos dejado de hablar de cookies porque no es interesante para el usuario. Lo que aún no tengo claro es si prefiero locale o idioma... Desde el punto de vista del cliente, lo que quiere es la página en varios idiomas. Mañana lo hablaré con los edenites ¿Vosotros que opinais?
Lo que sí que he sacado en claro hoy sobre cucumber, es que hay que intentar explicar la funcionalidad desde el punto de vista del cliente (de ahí que los escenarios los escriban los clientes :P ). No nos interesa mostrar detalles de implementación. Esto es fácil decirlo, pero, al menos para mi, no es fácil de hacer. Siempre se me cuela algún detalle de implementación...
Rack middleware
Además de añadir escenarios de cucumber, aunque la experiencia de usuario sigue siendo idéntica, hemos modificado todo el código responsable de la selección del idioma.
Lo que yo hice la semana pasada era seleccionar el idioma en el mismo método que me devolvía la página, provocando que el servicio web tuviera más de una responsabilidad. Steve me lo apuntó en la demo y me dijo que mirara los middleware de rack porque podían ser una solución al problema.
Basicamente, un middleware de rack filtra las llamadas a nuestra aplicación. En nuestro caso, lo vamos a utilizar para obtener el lenguaje preferido por el usuario y para establecer una cookie que recuerde dicho lenguaje. Esto permitirá que nuestro servicio web se desentienda de la selección del lenguaje, delegando dicha responsabilidad en el middleware.
No nos ha dado tiempo a dejarlo limpio del todo, pero ha mejorado bastante :D Estoy deseando que llegue mañana para dejarlo mejor :) ¡A ver si podemos ponerlo en producción pronto!
Un saludo.
domingo, 12 de diciembre de 2010
Dos semanas en Eden
Llevo un par de semanas en Winchester y me lo estoy pasando muy bien :D Es muy divertido ver como funciona Eden, todos los días estoy aprendiendo cosas nuevas y, por si fuera poco, estoy conociendo a mucha gente que merece la pena :D
Aunque el viernes me pudisteis preguntar todo lo que quisisteis en la #plagentrevista, tengo ganas de hacer una reflexión propia :P
Aspecto personal
Cuando surgió la oportunidad de venirme, no lo dudé. Tenía claro que no podía desaprovechar la ocasión. Aún así, no podía evitar ponerme nervioso. Otro país, otro idioma, un entorno desconocido, etc. Todas esas dudas desaparecieron el primer lunes :) Está siendo una experiencia espectacular :)
Una de las cosas que más me gusta de Eden es que se respira respeto por los demás y positivismo (palabro que no se si existe). Es algo que ayuda mucho a generar un entorno muy agradable y muy acogedor. Personalmente, quiero tratar así con la gente en mi vida normal, y estoy intentando forzar ese cambio. No es fácil, ya os lo digo. Evitar, por ejemplo, los típicos chascarrillos o bromas en plan "mira que eres paquete" (que es un desprecio hacia la otra persona), o intentar no buscar culpables (en la entrevista por ejemplo se me escapa un "no es culpa mía"...), es complicado porque es algo que tengo bastante interiorizado :P Aún así, se que tengo que cambiarlo y lo estoy intentando (el primer paso está dado).
Algo que, en ocasiones, es más difícil de manejar, es lo mucho que me queda por aprender. Raquel me lo preguntaba en la entrevista. ¿Cómo llevas lo de que te falte tanto por aprender sin agobiarte? La única respuesta que tengo es otra pregunta ¿Tengo alguna otra opción? Tenemos que hacernos a la idea de que vamos a estar toda la vida aprendiendo. ¿Nos queda mucho? Sí. Siempre nos va a quedar mucho. ¿Nos agobiamos? No. Eso no arregla nada. En lugar de agobiarte, practica :P Es parte del pensamiento positivo que, a partir de ahora, quiero tener :D
Aspecto técnico
De todo lo que estoy aprendiendo, sobresale sin ninguna duda la importancia que tiene que el código sea expresivo. Me gustó mucho algo que me dijo Enrique en la exposición del código de internacionalización de la página web. Chris me preguntó qué sería necesario modificar si quisieran añadir un tercer idioma. Yo conteste que, además de cambiar la experiencia de usuario, habría que tocar el código aqui y allá (resaltando el pobre diseño de mi código). Entonces, Enrique me dijo que era importante escribir el código lo más expresivo posible, de forma que no se tardara mucho en modificarlo para añadir un tercer idioma, permitiendo dedicar mucho más tiempo al problema importante, que en este caso es diseñar una buena experiencia de usuario.
Respecto a Ruby, nunca lo había utilizado "en serio" y tengo que decir que me está gustando mucho. Me parece un lenguaje muy expresivo y divertido. Aún me queda mucho por aprender, pero se que necesito dominar las colecciones. Muchas veces me lío por no conocer bien como funciona el Hash o el Array... Tendré que escribir alguna entrada sobre las cositas que voy aprendiendo. De momento, a parte de aprender el lenguaje, he utilizado Cucumber, RSpec, Sinatra, Rack, Bundler y rvm. Echadle un vistazo a todo eso porque realmente es impresionante. Sinatra es un alucine, Rack es la leche, bundler es super simple y RSpec y Cucumber molan mogollón. Si os apetece que escriba sobre algo en especial no tenéis más que decirmelo :)
Fuera del lenguaje en si, estoy aprendiendo a utilizar git de un modo más serio, aunque todavía en modo novato. Me está gustando bastante, la verdad, aunque ya os digo que todavía estoy empezando. Casi todo lo que hago lo subo a github (que me parece un flipe), por si os interesa cotillear :P
El viernes, Chris me enseñó lo fácil que es usar heroku y lo bien que se han montado el negocio :) Este fin de semana he estado trasteando un poco y he conseguido desplegar mi primera aplicación "Hola mundo" (que no hace nada, así que ni la enlazo :P ).
También me contó algo del servicio de Amazon EEC2, pero eso lo tengo muy verde. Espero que tenga tiempo para contarme algo más porque el proyecto que está haciendo me parece super interesante :D
Y no me podía olvidar de el vi (vim, macvim, etc). Está siendo todo un descubrimiento. No digo que sea intuitivo ni fácil, pero si consigues dominarlo, no creo que haya nada más productivo (y ligero). Como ya os dije, la curva de aprendizaje no es una curva, es una pared, pero eso solo implica practicar más. Se que no os voy a convencer de lo bueno que es (tampoco es mi objetivo), pero un día lo dominaré y entonces podré demostrároslo :P
Libros...
Ahora mismo tengo una pila de libros importante para leer. Por si os interesa, estoy con el "DDD", que me lo traje de España, con el "The timeless way of building" y con el "Structure and Interpretation of Computer Programs".
La guinda
Hoy, domingo, Enrique y yo nos hemos ido a Heathrow a comer con Sarah y J.B. Rainsberger. ¡Son muy simpáticos y divertidos! :D
La excusa de la comida era fijar la fecha para unos cursos en España pero, en realidad, ha sido más una comida entre amigos. Se ha hablado de todo menos de software :) Respecto a los cursos, deciros que parece ser que algo se hará, aunque todavía no tengo muy claro el qué (No por culpa del inglés, que conste :P Es que Enrique y J.B. parece ser que tienen un código secreto o algo así :P).
Resumiendo, me lo estoy pasando pipa y soy un programador feliz :D
Eso es todo, un saludo.
Aunque el viernes me pudisteis preguntar todo lo que quisisteis en la #plagentrevista, tengo ganas de hacer una reflexión propia :P
Aspecto personal
Cuando surgió la oportunidad de venirme, no lo dudé. Tenía claro que no podía desaprovechar la ocasión. Aún así, no podía evitar ponerme nervioso. Otro país, otro idioma, un entorno desconocido, etc. Todas esas dudas desaparecieron el primer lunes :) Está siendo una experiencia espectacular :)
Una de las cosas que más me gusta de Eden es que se respira respeto por los demás y positivismo (palabro que no se si existe). Es algo que ayuda mucho a generar un entorno muy agradable y muy acogedor. Personalmente, quiero tratar así con la gente en mi vida normal, y estoy intentando forzar ese cambio. No es fácil, ya os lo digo. Evitar, por ejemplo, los típicos chascarrillos o bromas en plan "mira que eres paquete" (que es un desprecio hacia la otra persona), o intentar no buscar culpables (en la entrevista por ejemplo se me escapa un "no es culpa mía"...), es complicado porque es algo que tengo bastante interiorizado :P Aún así, se que tengo que cambiarlo y lo estoy intentando (el primer paso está dado).
Algo que, en ocasiones, es más difícil de manejar, es lo mucho que me queda por aprender. Raquel me lo preguntaba en la entrevista. ¿Cómo llevas lo de que te falte tanto por aprender sin agobiarte? La única respuesta que tengo es otra pregunta ¿Tengo alguna otra opción? Tenemos que hacernos a la idea de que vamos a estar toda la vida aprendiendo. ¿Nos queda mucho? Sí. Siempre nos va a quedar mucho. ¿Nos agobiamos? No. Eso no arregla nada. En lugar de agobiarte, practica :P Es parte del pensamiento positivo que, a partir de ahora, quiero tener :D
Aspecto técnico
De todo lo que estoy aprendiendo, sobresale sin ninguna duda la importancia que tiene que el código sea expresivo. Me gustó mucho algo que me dijo Enrique en la exposición del código de internacionalización de la página web. Chris me preguntó qué sería necesario modificar si quisieran añadir un tercer idioma. Yo conteste que, además de cambiar la experiencia de usuario, habría que tocar el código aqui y allá (resaltando el pobre diseño de mi código). Entonces, Enrique me dijo que era importante escribir el código lo más expresivo posible, de forma que no se tardara mucho en modificarlo para añadir un tercer idioma, permitiendo dedicar mucho más tiempo al problema importante, que en este caso es diseñar una buena experiencia de usuario.
Respecto a Ruby, nunca lo había utilizado "en serio" y tengo que decir que me está gustando mucho. Me parece un lenguaje muy expresivo y divertido. Aún me queda mucho por aprender, pero se que necesito dominar las colecciones. Muchas veces me lío por no conocer bien como funciona el Hash o el Array... Tendré que escribir alguna entrada sobre las cositas que voy aprendiendo. De momento, a parte de aprender el lenguaje, he utilizado Cucumber, RSpec, Sinatra, Rack, Bundler y rvm. Echadle un vistazo a todo eso porque realmente es impresionante. Sinatra es un alucine, Rack es la leche, bundler es super simple y RSpec y Cucumber molan mogollón. Si os apetece que escriba sobre algo en especial no tenéis más que decirmelo :)
Fuera del lenguaje en si, estoy aprendiendo a utilizar git de un modo más serio, aunque todavía en modo novato. Me está gustando bastante, la verdad, aunque ya os digo que todavía estoy empezando. Casi todo lo que hago lo subo a github (que me parece un flipe), por si os interesa cotillear :P
El viernes, Chris me enseñó lo fácil que es usar heroku y lo bien que se han montado el negocio :) Este fin de semana he estado trasteando un poco y he conseguido desplegar mi primera aplicación "Hola mundo" (que no hace nada, así que ni la enlazo :P ).
También me contó algo del servicio de Amazon EEC2, pero eso lo tengo muy verde. Espero que tenga tiempo para contarme algo más porque el proyecto que está haciendo me parece super interesante :D
Y no me podía olvidar de el vi (vim, macvim, etc). Está siendo todo un descubrimiento. No digo que sea intuitivo ni fácil, pero si consigues dominarlo, no creo que haya nada más productivo (y ligero). Como ya os dije, la curva de aprendizaje no es una curva, es una pared, pero eso solo implica practicar más. Se que no os voy a convencer de lo bueno que es (tampoco es mi objetivo), pero un día lo dominaré y entonces podré demostrároslo :P
Libros...
Ahora mismo tengo una pila de libros importante para leer. Por si os interesa, estoy con el "DDD", que me lo traje de España, con el "The timeless way of building" y con el "Structure and Interpretation of Computer Programs".
La guinda
Hoy, domingo, Enrique y yo nos hemos ido a Heathrow a comer con Sarah y J.B. Rainsberger. ¡Son muy simpáticos y divertidos! :D
La excusa de la comida era fijar la fecha para unos cursos en España pero, en realidad, ha sido más una comida entre amigos. Se ha hablado de todo menos de software :) Respecto a los cursos, deciros que parece ser que algo se hará, aunque todavía no tengo muy claro el qué (No por culpa del inglés, que conste :P Es que Enrique y J.B. parece ser que tienen un código secreto o algo así :P).
Resumiendo, me lo estoy pasando pipa y soy un programador feliz :D
Eso es todo, un saludo.
viernes, 10 de diciembre de 2010
Plagentrevista
Para los que no lo sepáis, Enrique y yo hemos hecho una "entrevista" a través de justin.tv en la que la gente que se conectaba nos ha hecho preguntas sobre Eden. Ha quedado un poco larga pero creo que tiene partes muy molonas :) Os voy a destacar un poco algunos momentos por si no os apetece verla entera :P
- Minuto 5 - Empezamos :) Antes de eso podéis verme haciendo un poco el ganso, pero no aporta mucho más :P
- Minuto 12:30 - ¿Por qué Eden en UK y no en España?
- Minuto 16 - Germán pregunta cómo hacen en Eden cuando detectan algo que va mal.
- Minuto 25 - Kini me pregunta cómo hacen programación por parejas en Eden.
- Minuto 29 - Raquel pregunta si los clientes de Eden están ya educados cuando llegan a Eden o si, por el contrario, hay que educarles.
- Minuto 35:40 - Raquel vuelve a la carga preguntando sobre la documentación que les exigen los clientes.
- Minuto 37 - De nuevo, Raquel nos pregunta sobre la asignación de personas a proyectos ¿Fijas? ¿rotan? ¿cada cuanto?
- Minuto 44 - Si queréis saber que tal va la página en español de Eden este es vuestro minuto :)
- Minuto 55:30 - Kini pregunta por los radiadores de información en Eden.
- Minuto 1:08:30 - ¿Eden desarrolla producto o solo proyecto?
- Minuto 1:17:45 - Jesús no se fía del vi como editor :P
- Minuto 1:18:45 - ¿Por qué Ruby?
- Minuto 1:20:30 - Steve aparece como invitado sorpresa :)
- Minuto 1:39:00 - Tour por Eden :) ¡No os lo podéis perder!
Watch live video from edendevelopment on Justin.tv
Y eso es todo :D Siento no haber escrito mucho hoy, pero creo que con la entrevista tenéis un rato para entreteneros :P Este fin de semana escribiré un mini resumen semanal o algo así :D
Un saludo
- Minuto 5 - Empezamos :) Antes de eso podéis verme haciendo un poco el ganso, pero no aporta mucho más :P
- Minuto 12:30 - ¿Por qué Eden en UK y no en España?
- Minuto 16 - Germán pregunta cómo hacen en Eden cuando detectan algo que va mal.
- Minuto 25 - Kini me pregunta cómo hacen programación por parejas en Eden.
- Minuto 29 - Raquel pregunta si los clientes de Eden están ya educados cuando llegan a Eden o si, por el contrario, hay que educarles.
- Minuto 35:40 - Raquel vuelve a la carga preguntando sobre la documentación que les exigen los clientes.
- Minuto 37 - De nuevo, Raquel nos pregunta sobre la asignación de personas a proyectos ¿Fijas? ¿rotan? ¿cada cuanto?
- Minuto 44 - Si queréis saber que tal va la página en español de Eden este es vuestro minuto :)
- Minuto 55:30 - Kini pregunta por los radiadores de información en Eden.
- Minuto 1:08:30 - ¿Eden desarrolla producto o solo proyecto?
- Minuto 1:17:45 - Jesús no se fía del vi como editor :P
- Minuto 1:18:45 - ¿Por qué Ruby?
- Minuto 1:20:30 - Steve aparece como invitado sorpresa :)
- Minuto 1:39:00 - Tour por Eden :) ¡No os lo podéis perder!
Watch live video from edendevelopment on Justin.tv
Y eso es todo :D Siento no haber escrito mucho hoy, pero creo que con la entrevista tenéis un rato para entreteneros :P Este fin de semana escribiré un mini resumen semanal o algo así :D
Un saludo
jueves, 9 de diciembre de 2010
Productividad
Aunque alguna vez ya os lo he contado, es alucinante lo que son capaces de producir en Eden. Una de las razones principales de su alta productividad es que son muy buenos, pero también es importante como funcionan como empresa en las tareas que no tienen nada que ver con tirar código (y derivados).
Dentro de ese grupo de tareas, me gusta como manejan el tema de las reuniones, así que os voy a hablar un poco sobre como las hacen y como no las hacen :P
En Eden les gusta más hacer cosas que hablar de si quieren hacer cosas, por lo que las reuniones, cuantas menos, mejor y, cuanto más cortas, mejor.
Como todas las cosas que ocurren en Eden, parece de sentido común, pero ¿cuantas veces os ha pasado eso de ir a una reunión a la que falta un asistente y habéis tenido que esperar a que llegue? o ¿cuantas veces os habéis ido por las ramas durante una planificación? Eso, en Eden no pasa. Si alguien no está para una reunión, se aplaza o se hace sin él. Si alguien se va por las ramas con algún tema, se le pide que lo discuta en otro momento. Tienen muy claro que una reunión es una perdida de tiempo y dinero y actúan en consecuencia.
Siempre que tiene que haber una reunión (una retrospectiva, una reunión de empresa como en la que se discutió sobre Eden Madrid, un grupo de estudio, la reunión diaria, etc) aparece la figura del facilitador, que enfoca la reunión y cuida de que ésta sea lo más productiva posible. Pero cuidado, no es que alguien diga: "Tú, facilita la reunión". Es algo más espontaneo. Simplemente, alguien toma la iniciativa.
Una cosa que me llama mucho la atención es que se pide turno de palabra levantando la mano. Aunque alguna vez se pisan (no son perfectos :P), intentan respetarlo al máximo, y siempre se piden disculpas si se saltan la norma. Ese ambiente de respeto suele hacer que sean reuniones bastante constructivas.
Otro punto importante es que las reuniones con los clientes no existen. El cliente siempre está ahí para conversar con él cuando es necesario (que es bastante a menudo). Es como si se hiciera una planificación continua, que no notas, pero que es muy eficaz.
Me parece que es una empresa muy madura y muy consciente del valor de su tiempo.
Un saludo.
PD: Mañana por la mañana es la presentación de la web :) No se si nos dará tiempo a ponerla en el servidor porque tenemos la comida de navidad (y porque quizás surja alguna idea interesante durante la exposición que involucre cambios), pero haremos lo posible :P
PD-2: Cada vez que escribo en el blog intento borrar lineas escritas pulsando "dd" :P Creo que estoy infectado :)
Dentro de ese grupo de tareas, me gusta como manejan el tema de las reuniones, así que os voy a hablar un poco sobre como las hacen y como no las hacen :P
En Eden les gusta más hacer cosas que hablar de si quieren hacer cosas, por lo que las reuniones, cuantas menos, mejor y, cuanto más cortas, mejor.
Como todas las cosas que ocurren en Eden, parece de sentido común, pero ¿cuantas veces os ha pasado eso de ir a una reunión a la que falta un asistente y habéis tenido que esperar a que llegue? o ¿cuantas veces os habéis ido por las ramas durante una planificación? Eso, en Eden no pasa. Si alguien no está para una reunión, se aplaza o se hace sin él. Si alguien se va por las ramas con algún tema, se le pide que lo discuta en otro momento. Tienen muy claro que una reunión es una perdida de tiempo y dinero y actúan en consecuencia.
Siempre que tiene que haber una reunión (una retrospectiva, una reunión de empresa como en la que se discutió sobre Eden Madrid, un grupo de estudio, la reunión diaria, etc) aparece la figura del facilitador, que enfoca la reunión y cuida de que ésta sea lo más productiva posible. Pero cuidado, no es que alguien diga: "Tú, facilita la reunión". Es algo más espontaneo. Simplemente, alguien toma la iniciativa.
Una cosa que me llama mucho la atención es que se pide turno de palabra levantando la mano. Aunque alguna vez se pisan (no son perfectos :P), intentan respetarlo al máximo, y siempre se piden disculpas si se saltan la norma. Ese ambiente de respeto suele hacer que sean reuniones bastante constructivas.
Otro punto importante es que las reuniones con los clientes no existen. El cliente siempre está ahí para conversar con él cuando es necesario (que es bastante a menudo). Es como si se hiciera una planificación continua, que no notas, pero que es muy eficaz.
Me parece que es una empresa muy madura y muy consciente del valor de su tiempo.
Un saludo.
PD: Mañana por la mañana es la presentación de la web :) No se si nos dará tiempo a ponerla en el servidor porque tenemos la comida de navidad (y porque quizás surja alguna idea interesante durante la exposición que involucre cambios), pero haremos lo posible :P
PD-2: Cada vez que escribo en el blog intento borrar lineas escritas pulsando "dd" :P Creo que estoy infectado :)
miércoles, 8 de diciembre de 2010
User Experience
Como ya sabéis, mi tarea semanal es traducir la web de Eden Development al Español. Aunque no esta siendo una tarea muy complicada, me está causando muchas más dificultades que el PlageServer.
Dificultades técnicas
A nivel técnico es una tarea muy sencilla. Los problemas que surgen en esta fase son , principalmente, culpa mía.
Para empezar, mi desconocimiento de Ruby hace que haga las cosas de una manera algo rebuscada, dejando un código no muy legible. Tengo que investigar más antes de lanzarme a tirar código. Soy demasiado impaciente.
Por si eso fuera poco, se me ha ido la cabeza y me he complicado la vida mucho más de lo que era necesario :S Menos mal que Enrique me ha encauzado y he vuelto a enfocarme en la tarea principal.
Aunque estoy aprendiendo mucho, aún caigo en los mismos errores del pasado. Como ya os he comentado en alguna ocasión, a veces se me va el desarrollo de las manos por no pensar bien en lo que estoy haciendo :(
Problemas en la experiencia de usuario
Pero sin duda, las dificultades más grandes están surgiendo a la hora de diseñar una buena experiencia de usuario.
He estado con Spencer un rato viéndole diseñar la modificación de la página mientras pensábamos en el problema :) Ha sido brutal. De hecho, todos los de Eden son brutales. Es espectacular verlos manejar el código con el Vim, casi no me da tiempo a ver las modificaciones que hacen en el código. Nunca había visto programar tan rápido y, a la vez, de forma tan precisa. Están a años luz. De momento, a mi ya me han convencido. Hay que dejar de usar IDEs y pasarse a Vim o similares. Cuesta entrar, pero merece la pena (aunque yo soy un paquete aún).
La duda más importante que nos ha surgido es si queremos que un usuario con el Español como idioma de preferencia sea redirigido directamente a la página en Español o, si por el contrario, es mejor presentarle la página en Inglés y darle la opción de cambiar la página a Español.
Si elegimos la opción en la que el usuario debe seleccionar en que idioma quiere la página, la siguiente duda es si debemos recordar su selección (con una cookie) y no volver a preguntarle. Si hacemos esto, solo se podrá cambiar el idioma una vez la cookie sea eliminada. ¿Deberíamos tener una opción para cambiar el idioma cuando quiera el usuario? Entonces, ¿para qué darle la posibilidad de elegir al principio?
Espero vuestras sugerencias :P
Nunca antes me había tenido que enfrentar a este tipo de cuestiones (al menos no tan "a fondo") y por eso me cuesta pensar en una buena solución. Me gusta como lo hace github (te presenta la página en inglés y te dice que la página está disponible en español en un mini-banner. Luego tiene también una opción para cambiar el idioma que seleccionaste en su momento), pero parece que a Spencer no le ha convencido para este caso :)
Mañana tocará definir bien lo que vamos a hacer y terminar la tarea (mejorar un poco la traducción y añadir algún test de cucumber, que lo he dejado para el final porque soy un paquete...). Enrique quería que hiciera la presentación mañana, pero no se si me va a dar tiempo :S Ya os contaré.
Un saludo
Dificultades técnicas
A nivel técnico es una tarea muy sencilla. Los problemas que surgen en esta fase son , principalmente, culpa mía.
Para empezar, mi desconocimiento de Ruby hace que haga las cosas de una manera algo rebuscada, dejando un código no muy legible. Tengo que investigar más antes de lanzarme a tirar código. Soy demasiado impaciente.
Por si eso fuera poco, se me ha ido la cabeza y me he complicado la vida mucho más de lo que era necesario :S Menos mal que Enrique me ha encauzado y he vuelto a enfocarme en la tarea principal.
Aunque estoy aprendiendo mucho, aún caigo en los mismos errores del pasado. Como ya os he comentado en alguna ocasión, a veces se me va el desarrollo de las manos por no pensar bien en lo que estoy haciendo :(
Problemas en la experiencia de usuario
Pero sin duda, las dificultades más grandes están surgiendo a la hora de diseñar una buena experiencia de usuario.
He estado con Spencer un rato viéndole diseñar la modificación de la página mientras pensábamos en el problema :) Ha sido brutal. De hecho, todos los de Eden son brutales. Es espectacular verlos manejar el código con el Vim, casi no me da tiempo a ver las modificaciones que hacen en el código. Nunca había visto programar tan rápido y, a la vez, de forma tan precisa. Están a años luz. De momento, a mi ya me han convencido. Hay que dejar de usar IDEs y pasarse a Vim o similares. Cuesta entrar, pero merece la pena (aunque yo soy un paquete aún).
La duda más importante que nos ha surgido es si queremos que un usuario con el Español como idioma de preferencia sea redirigido directamente a la página en Español o, si por el contrario, es mejor presentarle la página en Inglés y darle la opción de cambiar la página a Español.
Si elegimos la opción en la que el usuario debe seleccionar en que idioma quiere la página, la siguiente duda es si debemos recordar su selección (con una cookie) y no volver a preguntarle. Si hacemos esto, solo se podrá cambiar el idioma una vez la cookie sea eliminada. ¿Deberíamos tener una opción para cambiar el idioma cuando quiera el usuario? Entonces, ¿para qué darle la posibilidad de elegir al principio?
Espero vuestras sugerencias :P
Nunca antes me había tenido que enfrentar a este tipo de cuestiones (al menos no tan "a fondo") y por eso me cuesta pensar en una buena solución. Me gusta como lo hace github (te presenta la página en inglés y te dice que la página está disponible en español en un mini-banner. Luego tiene también una opción para cambiar el idioma que seleccionaste en su momento), pero parece que a Spencer no le ha convencido para este caso :)
Mañana tocará definir bien lo que vamos a hacer y terminar la tarea (mejorar un poco la traducción y añadir algún test de cucumber, que lo he dejado para el final porque soy un paquete...). Enrique quería que hiciera la presentación mañana, pero no se si me va a dar tiempo :S Ya os contaré.
Un saludo
martes, 7 de diciembre de 2010
Hammock Driven Development
Ya os conté que una de las cosas que más me han gustado de Eden (y que más sencillas me parecen) es la parte de la reunión diaria en la que se habla de las cosas interesantes que ha descubierto la gente. Hoy, Steve nos ha contado lo interesante que le había parecido esta charla. Nos ha convencido de que merecía la pena verla y hemos quedado en proyectarla a la hora de la comida.
No es una charla técnica, es más bien "filosófica", así que no tenéis excusa para no verla :P
De todas formas, como tengo que escribir algo :P, voy a explicar algunos de los puntos que he sacado en claro tras la discusión que hemos tenido en Eden después de verla.
Hammock driven development
Básicamente, la idea central de la charla es como mejorar nuestra habilidad para resolver problemas. Hay una transparencia muy aclarativa en la que Rich Hickey, el creador de Clojure, nos recuerda que, si no estamos resolviendo un problema, para que demonios estamos trabajando (dentro del contexto del software). Además, se centra mucho en la importancia de entender el problema de forma global, no solo en el ámbito técnico.
Pensar y reflexionar sobre el problema
Nada más empezar, Rich nos hace una pregunta
No se vosotros, pero yo no me paro a pensar "demasiado" en el problema ni en su por qué. Intento buscar una solución lo antes posible. Esta charla me ha recordado que lo importante no es la solución, es entender el por qué (a lo mejor no hace que busques una solución porque realmente no existe un problema). Me lo apunto como "a mejorar" :)
Además, ese pensar en el problema va a hacer posible que tu cerebro asimile que es importante y trabajará en "background" en ello.
¿El cerebro trabajando en background?
A lo que se refiere el autor con esto es al trabajo que realiza tu subconsciente mientras, por ejemplo, duermes (De ahí lo de hammock driven development, que es algo así como desarrollo dirigido por hamaca :D )
Rich deja claro que la charla no es un estudio científico ni nada de eso, así que no os lancéis como leones :P pero, ¿Nunca os ha pasado eso de encontrar la solución mientras dormías?
Enfocarse en profundidad en el problema
Esto implica pensar en el problema sin distracciones (nada de twitter, mail, teléfono, etc), es decir, hay que separarse del ordenador (suena duro, ¿no?). Para nosotros, los ordenadores son nuestra herramienta preferida para la procrastinación y el desenfoque, así que, en los momentos en los que se está enfocado en el problema, hay que intentar dejarlos a un lado.
Anotarlo todo
Personalmente, una de las cosas que más me ha chocado de la charla es que hace mucho hincapié en anotar todo lo que vamos descubriendo del problema. La razón principal es para no olvidar los detalles que ya se han descubierto. No se mete en como tienes que escribirlo, simplemente te aconseja que lo anotes.
No dejéis de ver la charla, es mucho mejor que mis notas :D
Un saludo
No es una charla técnica, es más bien "filosófica", así que no tenéis excusa para no verla :P
De todas formas, como tengo que escribir algo :P, voy a explicar algunos de los puntos que he sacado en claro tras la discusión que hemos tenido en Eden después de verla.
Hammock driven development
Básicamente, la idea central de la charla es como mejorar nuestra habilidad para resolver problemas. Hay una transparencia muy aclarativa en la que Rich Hickey, el creador de Clojure, nos recuerda que, si no estamos resolviendo un problema, para que demonios estamos trabajando (dentro del contexto del software). Además, se centra mucho en la importancia de entender el problema de forma global, no solo en el ámbito técnico.
Pensar y reflexionar sobre el problema
Nada más empezar, Rich nos hace una pregunta
¿Cuanto hace que no piensas en un problema durante toda una hora? ¿Durante todo un día? ¿y durante un año?
No se vosotros, pero yo no me paro a pensar "demasiado" en el problema ni en su por qué. Intento buscar una solución lo antes posible. Esta charla me ha recordado que lo importante no es la solución, es entender el por qué (a lo mejor no hace que busques una solución porque realmente no existe un problema). Me lo apunto como "a mejorar" :)
Además, ese pensar en el problema va a hacer posible que tu cerebro asimile que es importante y trabajará en "background" en ello.
¿El cerebro trabajando en background?
A lo que se refiere el autor con esto es al trabajo que realiza tu subconsciente mientras, por ejemplo, duermes (De ahí lo de hammock driven development, que es algo así como desarrollo dirigido por hamaca :D )
Rich deja claro que la charla no es un estudio científico ni nada de eso, así que no os lancéis como leones :P pero, ¿Nunca os ha pasado eso de encontrar la solución mientras dormías?
Enfocarse en profundidad en el problema
Esto implica pensar en el problema sin distracciones (nada de twitter, mail, teléfono, etc), es decir, hay que separarse del ordenador (suena duro, ¿no?). Para nosotros, los ordenadores son nuestra herramienta preferida para la procrastinación y el desenfoque, así que, en los momentos en los que se está enfocado en el problema, hay que intentar dejarlos a un lado.
Anotarlo todo
Personalmente, una de las cosas que más me ha chocado de la charla es que hace mucho hincapié en anotar todo lo que vamos descubriendo del problema. La razón principal es para no olvidar los detalles que ya se han descubierto. No se mete en como tienes que escribirlo, simplemente te aconseja que lo anotes.
No dejéis de ver la charla, es mucho mejor que mis notas :D
Un saludo
Etiquetas:
eden,
hammock driven development,
internship
lunes, 6 de diciembre de 2010
¿Lunes? Menudo lunes
Es increible la cantidad de cosas que han pasado hoy en Eden :D
Tengo tarea nueva, hemos hablado de Eden Madrid, he asistido a una planificación de release, nos ha visitado un desarrollador de la zona y, por si fuera poco, el Agile South Coast User Group se ha reunido en nuestras oficinas (sí, nuestras, que yo también soy de Eden :P)
Nueva tarea semanal
Tengo que traducir al español la página de Eden :D En realidad lo que tengo que hacer es internacionalizar la página, porque en un futuro quieren poder traducirla también al alemán o al frances.
La web de Eden está hecha con sinatra y utiliza haml para las vistas. No tenía ni idea de lo que eran ninguna de esas dos palabras, así que la mañana la he pasado entendiendo la tecnología y buscando como internacionalizar aplicaciones que usan sinatra. La solución que he encontrado es utilizar r18n.
Tras una horita haciendo un spike para entender el funcionamiento tanto de sinatra como de r18n tengo que decir que ruby te hace la vida muy fácil :D No se que demonios hacía programando en java :P
Una vez descubierto cómo internacionalizar Eden, Spencer me ha hablado de la usabilidad de la web y de como puede afectarle el que esté disponible en varios idiomas.
¿Queremos que si vienes de España te aparezca la página en español? ¿Vamos a dar la poibilidad de elegir el idioma en el que mostrar el texto? En fin, una serie de preguntas de las que hemos sacado en claro que, aunque de primeras te aparezca en el lenguaje indicado por tu browser, debemos permitir seleccionar el idioma (aunque aún no sabemos como lo vamos a hacer).
De momento lo único que he conseguido es obtener la preferencia de idioma del navegador que consulta la página, mañana ya me meteré a fondo con la internacionalización de la página.
Otro problema que aún no he pensado como resolver es el de las pruebas. No estoy seguro de como montar las pruebas para probar la i18n.
Por si os interesa, he tenido que pelearme con unas expresiones regulares y Spencer me ha recomendado esta web. Me ha parecido super útil :D
Eden Madrid
Mas tarde, a las 13:00 nos hemos reunido para hablar de Eden Madrid. La idea era que los edenites decidieran si querían o no embarcarse en el proyecto Eden Madrid. Como siempre, ha sido una discusión abierta (incluso a los que venían de visita, a los clientes, etc) y honesta, en la que cada persona a expresado sus dudas.
Sin duda alguna, me quedo con lo que se preocupan por su empresa :) Está claro que les gusta.
Aunque la reunión ha sido muy reveladora, el resultado de la reunión no ha sido el esperado porque no se ha podido responder a las dudas planteadas. Dentro de una o dos semanas habrá otra reunión con algo mas de información y de la que quizás se salga con una decisión. Os mantendremos al tanto :)
Una de las dudas que han aparecido es si hay mercado en España para Eden (training, coaching y proyectos)y, si lo hay, cuanto tardarían en encontrar un cliente. ¿Vosotros que pensáis?
Release planning
Después de la comida (sí, la reunión de Eden Madrid la hemos hecho mientras omíamos) he participado en una release planning con uno de los clientes.
Ha sido una conversación muy interesante en la que el cliente ha demostrado un grado de madurez muy alto, eliminando de la release las features que menos valor le iban a aportar y contestanto muy tranquilamente a todas las preguntas y observaciones del equipo (era una colaboración con el cliente de las de verdad) e incluso de fuera del equipo (nuestro visitante).
Me ha parecido un product owner al que le importaba de verdad su producto.
Visita de uno de los desarrolladores de la comunidad
Russel, uno de los fundadores de la Winchester Web Scene, ha estado hoy de visita y ha sido algo un poco espectacular. Ha trabajado con Aimee durante casi todo el día pero, lo mejor de todo, es que ha intervenido tanto en la reunión sobre Eden Madrid como en la release planning. Nadie se ha soprendido, salvo yo, y todo el mundo le ha tratado como a uno más. Se nota que están acostumbrados a este tipo de visitas.
Reunión del grupo Agile South Coast
Ha sido una reunión un poco extraña. Parece ser que el grupo está en horas bajas y esta debía ser una reunión "refundacional". De los regulares solo ha aparecido uno, el resto eramos un CSM que acudía a su primera reunión y la gente que estábamos en Eden.
No hemos hablado de nada ágil, pero tengo que decir que me ha impresionado mucho como han llevado el tema los edenites. En todo momento han sido constructivos, pero nunca condescendientes. Ha sido una demostración de como intentar revitalizar una reunión y, sobre todo, como revitalizar un grupo. Todos han intentado buscar soluciones, dejando a un lado toda la parte de buscar culpables y no aceptando justificaciones que no eran pedidas.
Esto es todo por hoy. Como veis, en Eden no tienes tiempo de aburrirte :) Animaos a venir de visita, esto tenéis que verlo por vosotros mismos :)
Tengo tarea nueva, hemos hablado de Eden Madrid, he asistido a una planificación de release, nos ha visitado un desarrollador de la zona y, por si fuera poco, el Agile South Coast User Group se ha reunido en nuestras oficinas (sí, nuestras, que yo también soy de Eden :P)
Nueva tarea semanal
Tengo que traducir al español la página de Eden :D En realidad lo que tengo que hacer es internacionalizar la página, porque en un futuro quieren poder traducirla también al alemán o al frances.
La web de Eden está hecha con sinatra y utiliza haml para las vistas. No tenía ni idea de lo que eran ninguna de esas dos palabras, así que la mañana la he pasado entendiendo la tecnología y buscando como internacionalizar aplicaciones que usan sinatra. La solución que he encontrado es utilizar r18n.
Tras una horita haciendo un spike para entender el funcionamiento tanto de sinatra como de r18n tengo que decir que ruby te hace la vida muy fácil :D No se que demonios hacía programando en java :P
Una vez descubierto cómo internacionalizar Eden, Spencer me ha hablado de la usabilidad de la web y de como puede afectarle el que esté disponible en varios idiomas.
¿Queremos que si vienes de España te aparezca la página en español? ¿Vamos a dar la poibilidad de elegir el idioma en el que mostrar el texto? En fin, una serie de preguntas de las que hemos sacado en claro que, aunque de primeras te aparezca en el lenguaje indicado por tu browser, debemos permitir seleccionar el idioma (aunque aún no sabemos como lo vamos a hacer).
De momento lo único que he conseguido es obtener la preferencia de idioma del navegador que consulta la página, mañana ya me meteré a fondo con la internacionalización de la página.
Otro problema que aún no he pensado como resolver es el de las pruebas. No estoy seguro de como montar las pruebas para probar la i18n.
Por si os interesa, he tenido que pelearme con unas expresiones regulares y Spencer me ha recomendado esta web. Me ha parecido super útil :D
Eden Madrid
Mas tarde, a las 13:00 nos hemos reunido para hablar de Eden Madrid. La idea era que los edenites decidieran si querían o no embarcarse en el proyecto Eden Madrid. Como siempre, ha sido una discusión abierta (incluso a los que venían de visita, a los clientes, etc) y honesta, en la que cada persona a expresado sus dudas.
Sin duda alguna, me quedo con lo que se preocupan por su empresa :) Está claro que les gusta.
Aunque la reunión ha sido muy reveladora, el resultado de la reunión no ha sido el esperado porque no se ha podido responder a las dudas planteadas. Dentro de una o dos semanas habrá otra reunión con algo mas de información y de la que quizás se salga con una decisión. Os mantendremos al tanto :)
Una de las dudas que han aparecido es si hay mercado en España para Eden (training, coaching y proyectos)y, si lo hay, cuanto tardarían en encontrar un cliente. ¿Vosotros que pensáis?
Release planning
Después de la comida (sí, la reunión de Eden Madrid la hemos hecho mientras omíamos) he participado en una release planning con uno de los clientes.
Ha sido una conversación muy interesante en la que el cliente ha demostrado un grado de madurez muy alto, eliminando de la release las features que menos valor le iban a aportar y contestanto muy tranquilamente a todas las preguntas y observaciones del equipo (era una colaboración con el cliente de las de verdad) e incluso de fuera del equipo (nuestro visitante).
Me ha parecido un product owner al que le importaba de verdad su producto.
Visita de uno de los desarrolladores de la comunidad
Russel, uno de los fundadores de la Winchester Web Scene, ha estado hoy de visita y ha sido algo un poco espectacular. Ha trabajado con Aimee durante casi todo el día pero, lo mejor de todo, es que ha intervenido tanto en la reunión sobre Eden Madrid como en la release planning. Nadie se ha soprendido, salvo yo, y todo el mundo le ha tratado como a uno más. Se nota que están acostumbrados a este tipo de visitas.
Reunión del grupo Agile South Coast
Ha sido una reunión un poco extraña. Parece ser que el grupo está en horas bajas y esta debía ser una reunión "refundacional". De los regulares solo ha aparecido uno, el resto eramos un CSM que acudía a su primera reunión y la gente que estábamos en Eden.
No hemos hablado de nada ágil, pero tengo que decir que me ha impresionado mucho como han llevado el tema los edenites. En todo momento han sido constructivos, pero nunca condescendientes. Ha sido una demostración de como intentar revitalizar una reunión y, sobre todo, como revitalizar un grupo. Todos han intentado buscar soluciones, dejando a un lado toda la parte de buscar culpables y no aceptando justificaciones que no eran pedidas.
Esto es todo por hoy. Como veis, en Eden no tienes tiempo de aburrirte :) Animaos a venir de visita, esto tenéis que verlo por vosotros mismos :)
domingo, 5 de diciembre de 2010
Los valores de Eden
En una de las paredes de Eden hay pegada una tarjeta con una frase que resume qué es Eden:
No se a vosotros, pero a mi me gusta mucho :D
Como os he contado en las anteriores entradas, Eden se guía por una serie de valores que todos los "edenites" entienden, comparten y cumplen. De hecho, dichos valores los han decidido entre todos, como hacen con todo lo demás :D Todos los valores de Eden están relacionados con esa frase.
We build relationships (Construímos relaciones)
Eden no solo se preocupa de construir software. Además, se preocupa de construir relaciones de total confianza con sus clientes. Tienen claro están dejando en sus manos su reputación y su medio de subsistencia.
Por supuesto, también se preocupa de las propias relaciones entre "edenitas". De hecho, lo que más vas a ver en Eden son sonrisas :D
We have a mindset of mutual respect (Tenemos una mentalidad de respeto mutuo)
Esto es muy importante en Eden. Puede que existan diferencias de opinión, pero nunca se pierde el respeto hacia la otra persona.
De verdad, es alucinante. En estos 5 días no ha habido ni una sola falta de respeto entre "edenites", y por falta de respeto me refiero incluso al típico chascarrillo español en plan "será cabrón :)". Sí que lo he visto por ejemplo por parte del cliente, y también he podido comprobar como los "edenites" lo han cortado de raíz con un toque de atención.
We ask "why?" (Preguntamos "¿por qué?")
Eden quiere añadir valor al negocio de los clientes, por lo que necesitan tener claras sus motivaciones.
Lógicamente, si es bueno para un cliente, también es bueno para Eden. El nivel de exigencia que tienen les hace cuestionarse sus motivaciones con el objetivo de mejorar.
We craft excellence (lo hacemos de forma excelente)
Eden es un equipazo. Son gente muy buena en su trabajo y muy responsable. Dicha responsabilidad les lleva a entregar sólo código excelente. Si la funcionalidad no está al nivel que ellos mismos se exigen, no se entrega.
We are disciplined (Somos disciplinados)
No son disciplinados en el sentido de cumplir órdenes, son disciplinados en el sentido de ser responsables. Prefieren arreglar la raiz de los problemas antes que parchear los sintomas.
We learn aggressively (Aprendemos de forma agresiva)
Todos los miembros de Eden sienten pasión por su profesión y están continuamente aprendiendo (nuevos lenguajes, nuevas técnicas, etc.) y compartiendo lo aprendido con el resto.
We give generously (Damos generosamente)
Eden es realmente generosa. Se involucran con las comunidades (no solo con las relacionadas con el software), aceptan visitas, promueven actividades, etc.
Si se monta Eden en Madrid entenderéis mejor a que me refiero. Nos lo vamos a pasar piruleta :D
We value people (Valoramos a las personas)
Eden no permite que los proyectos y sus fechas de entrega entren en conflicto con la vida personal de los "edenites". Además, fomentan actividades que refuercen las relaciones personales entre los "edenites" (como por ejemplo la proyección de Avatar del otro día)
Tengo que decir que todo esto sale de forma natural. En ningún momento se "fuerza la amistad". Simplemente son buenas personas juntas en una oficina :)
We are honest and open, even when it's hard (Somos honestos y abiertos, incluso cuando es duro)
La confianza entre todo Eden permite una honestidad brutal. Si algo no gusta, se dice, aunque cueste.
Realmente, en la semana que he pasado con ellos la única vez que se dio un toque de atención fue para intentar mejorar la dinámica de trabajo de un equipo cliente. No fue gratuito, fue necesario, y el equipo cliente lo aceptó y reconoció el problema.
We are humble (Somos humildes)
Eden es humilde y los "edenites" son humildes. Saben que son muy buenos y que hacen las cosas muy bien, pero también tienen claro que aún pueden mejorar (Aunque yo ahora mismo no veo como :D ).
Eso es todo, ¿Qué os parece? Espero que esto os de una idea del tipo de compañía que es Eden (o lo que yo entiendo que es Eden), aunque realmente es mucho mejor :) En serio, tenéis que comprobarlo por vosotros mismos. Este tweet de Luismi Cavallé resume bastante bien como me siento después de esta semana :D
Eden exists to enable people to achieve better, greater, more worthwhile things
Eden existe para permitir a las personas conseguir cosas mejores, más grandes, que valgan más la pena
No se a vosotros, pero a mi me gusta mucho :D
Como os he contado en las anteriores entradas, Eden se guía por una serie de valores que todos los "edenites" entienden, comparten y cumplen. De hecho, dichos valores los han decidido entre todos, como hacen con todo lo demás :D Todos los valores de Eden están relacionados con esa frase.
We build relationships (Construímos relaciones)
Eden no solo se preocupa de construir software. Además, se preocupa de construir relaciones de total confianza con sus clientes. Tienen claro están dejando en sus manos su reputación y su medio de subsistencia.
Por supuesto, también se preocupa de las propias relaciones entre "edenitas". De hecho, lo que más vas a ver en Eden son sonrisas :D
We have a mindset of mutual respect (Tenemos una mentalidad de respeto mutuo)
Esto es muy importante en Eden. Puede que existan diferencias de opinión, pero nunca se pierde el respeto hacia la otra persona.
De verdad, es alucinante. En estos 5 días no ha habido ni una sola falta de respeto entre "edenites", y por falta de respeto me refiero incluso al típico chascarrillo español en plan "será cabrón :)". Sí que lo he visto por ejemplo por parte del cliente, y también he podido comprobar como los "edenites" lo han cortado de raíz con un toque de atención.
We ask "why?" (Preguntamos "¿por qué?")
Eden quiere añadir valor al negocio de los clientes, por lo que necesitan tener claras sus motivaciones.
Lógicamente, si es bueno para un cliente, también es bueno para Eden. El nivel de exigencia que tienen les hace cuestionarse sus motivaciones con el objetivo de mejorar.
We craft excellence (lo hacemos de forma excelente)
Eden es un equipazo. Son gente muy buena en su trabajo y muy responsable. Dicha responsabilidad les lleva a entregar sólo código excelente. Si la funcionalidad no está al nivel que ellos mismos se exigen, no se entrega.
We are disciplined (Somos disciplinados)
No son disciplinados en el sentido de cumplir órdenes, son disciplinados en el sentido de ser responsables. Prefieren arreglar la raiz de los problemas antes que parchear los sintomas.
We learn aggressively (Aprendemos de forma agresiva)
Todos los miembros de Eden sienten pasión por su profesión y están continuamente aprendiendo (nuevos lenguajes, nuevas técnicas, etc.) y compartiendo lo aprendido con el resto.
We give generously (Damos generosamente)
Eden es realmente generosa. Se involucran con las comunidades (no solo con las relacionadas con el software), aceptan visitas, promueven actividades, etc.
Si se monta Eden en Madrid entenderéis mejor a que me refiero. Nos lo vamos a pasar piruleta :D
We value people (Valoramos a las personas)
Eden no permite que los proyectos y sus fechas de entrega entren en conflicto con la vida personal de los "edenites". Además, fomentan actividades que refuercen las relaciones personales entre los "edenites" (como por ejemplo la proyección de Avatar del otro día)
Tengo que decir que todo esto sale de forma natural. En ningún momento se "fuerza la amistad". Simplemente son buenas personas juntas en una oficina :)
We are honest and open, even when it's hard (Somos honestos y abiertos, incluso cuando es duro)
La confianza entre todo Eden permite una honestidad brutal. Si algo no gusta, se dice, aunque cueste.
Realmente, en la semana que he pasado con ellos la única vez que se dio un toque de atención fue para intentar mejorar la dinámica de trabajo de un equipo cliente. No fue gratuito, fue necesario, y el equipo cliente lo aceptó y reconoció el problema.
We are humble (Somos humildes)
Eden es humilde y los "edenites" son humildes. Saben que son muy buenos y que hacen las cosas muy bien, pero también tienen claro que aún pueden mejorar (Aunque yo ahora mismo no veo como :D ).
Eso es todo, ¿Qué os parece? Espero que esto os de una idea del tipo de compañía que es Eden (o lo que yo entiendo que es Eden), aunque realmente es mucho mejor :) En serio, tenéis que comprobarlo por vosotros mismos. Este tweet de Luismi Cavallé resume bastante bien como me siento después de esta semana :D
viernes, 3 de diciembre de 2010
Mi primera presentación en Eden
Como parte de mi internship en Eden cada semana tengo que dar una charla al resto de la compañía. La primera ha consistido en explicar como he desarrollado el PlageServer.
Qué es PlageServer
Ya os lo he contado en varias entradas. PlageServer es mi primera tarea en Eden. La idea era implementar un servidor web capaz de aceptar peticiones y devolver respuestas que cumplan la rfc2616.
Aunque no he conseguido terminarlo, si que me ha dado tiempo a completar la operación GET. Si queréis ver el código lo tenéis en github.
La presentación
Teníamos fijada la presentación para las 15:00 y, aunque no os lo creais, a las 14:50 estaba tan tranquilo en uno de los sofás de Eden. Normalmente me pongo muy nervioso cuando me toca hablar, pero hoy no ha sido así. Mis compañeros me han dado mucha confianza durante toda la semana y me siento bastante integrado, lo que me ha permitido relajarme y disfrutar :D Tampoco os penséis que gracias a eso la presentación ha sido perfecta. Me he liado tanto con el idioma como con el código en sí :D No ha sido un desastre, pero he ido demasiado rápido y creo que ha sido un poco confuso.
Una vez terminada la exposición, mis compañeros han comentado el código. Ha habido de todo, desde que era un código más o menos limpio hasta que era una mezcla entre OO y programación estructurada :D
Realmente, creo que podría haberlo hecho mucho mejor (sobre todo ahora que ya se hacerlo mal :P).
No se si os pasa a vosotros, pero hay un momento en el que el código se me va de las manos (y eso que hago TDD). Creo que tiene que ver con los test que defino. Puede que esté dando pasos demasiado grandes.
A pesar de todo, mis compañeros me han felicitado con un "well done" :D ¡Muchas gracias!
Feedback semanal
Una vez terminada la presentación y la ronda de preguntas/observaciones, le ha llegado el turno al feedback semanal.
Por un lado, mis compañeros me han contado como se sienten conmigo por allí. Valoran el que haya venido desde España, dejando mi trabajo y a mi pobre novia (a la que, por cierto, le dedico este post :D ) y se sienten cómodos conmigo :) Eso sí, tengo que intentar dejar la timidez en casa.
Por el otro lado, yo les he dicho como me siento con ellos. ¿Os imagináis mis palabras? Las podéis leer aquí :) También les he comentado que quiero programar más con ellos. Esta semana no hemos podido por varios motivos (gente enferma, nieve bloqueando las carreteras, etc) y quiero aprender de ellos :D
Resumiendo, todo va bastante bien. Estoy disfrutando como un enano de la experiencia y espero que se note en estas entradas :)
¡Un saludo a todos!
Qué es PlageServer
Ya os lo he contado en varias entradas. PlageServer es mi primera tarea en Eden. La idea era implementar un servidor web capaz de aceptar peticiones y devolver respuestas que cumplan la rfc2616.
Aunque no he conseguido terminarlo, si que me ha dado tiempo a completar la operación GET. Si queréis ver el código lo tenéis en github.
La presentación
Teníamos fijada la presentación para las 15:00 y, aunque no os lo creais, a las 14:50 estaba tan tranquilo en uno de los sofás de Eden. Normalmente me pongo muy nervioso cuando me toca hablar, pero hoy no ha sido así. Mis compañeros me han dado mucha confianza durante toda la semana y me siento bastante integrado, lo que me ha permitido relajarme y disfrutar :D Tampoco os penséis que gracias a eso la presentación ha sido perfecta. Me he liado tanto con el idioma como con el código en sí :D No ha sido un desastre, pero he ido demasiado rápido y creo que ha sido un poco confuso.
Una vez terminada la exposición, mis compañeros han comentado el código. Ha habido de todo, desde que era un código más o menos limpio hasta que era una mezcla entre OO y programación estructurada :D
Realmente, creo que podría haberlo hecho mucho mejor (sobre todo ahora que ya se hacerlo mal :P).
No se si os pasa a vosotros, pero hay un momento en el que el código se me va de las manos (y eso que hago TDD). Creo que tiene que ver con los test que defino. Puede que esté dando pasos demasiado grandes.
A pesar de todo, mis compañeros me han felicitado con un "well done" :D ¡Muchas gracias!
Feedback semanal
Una vez terminada la presentación y la ronda de preguntas/observaciones, le ha llegado el turno al feedback semanal.
Por un lado, mis compañeros me han contado como se sienten conmigo por allí. Valoran el que haya venido desde España, dejando mi trabajo y a mi pobre novia (a la que, por cierto, le dedico este post :D ) y se sienten cómodos conmigo :) Eso sí, tengo que intentar dejar la timidez en casa.
Por el otro lado, yo les he dicho como me siento con ellos. ¿Os imagináis mis palabras? Las podéis leer aquí :) También les he comentado que quiero programar más con ellos. Esta semana no hemos podido por varios motivos (gente enferma, nieve bloqueando las carreteras, etc) y quiero aprender de ellos :D
Resumiendo, todo va bastante bien. Estoy disfrutando como un enano de la experiencia y espero que se note en estas entradas :)
¡Un saludo a todos!
jueves, 2 de diciembre de 2010
Nevando a tope
Os pido disculpas de antemano porque la entrada de hoy va a ser muy cortita :( Intentaré redimirme el fin de semana.
Que bonita es la nieve
Hoy ha sido un día extraño en Winchester. Anoche nevó mucho y nos hemos levantado con unos 20 centímetros de nieve. Eso ha provocado un mini caos en la ciudad debido al cual solo hemos podido ir al taller tres personas de Eden (Enrique, Aimee y yo) y los cuatro compañeros que están por parte del cliente :S Cuando nos hemos querido poner a trabajar nos hemos dado cuenta de que no funcionaba internet, no sabemos por qué. El proyecto del cliente lo necesita (skype para pair remoto, consultas de documentación, etc), así que nos hemos bajado a trabajar a un café cercano que tiene WiFi :D Este tweet sirve como prueba. A la hora del almuerzo, el equipo del cliente ha decidido irse a Londres para evitar problemas con los trenes, lo que ha dejado a Aimee y Enrique compuestos y sin novio :P Esto nos ha llevado a adelantar la proyección de Avatar (edición de coleccionista), por lo que, aunque la película mola, no hemos trabajado demasiado :P
¿Os lo había contado? El otro día planeamos ver Avatar en Eden :) Otra de esas cosas que crean relaciones personales y que tanto se dan en Eden :)
Avances en el PlageServer
Mañana tengo la presentación del PlageServer y no va del todo mal, aunque quiero darle un repasillo esta noche. Tengo algún problema con los require que provoca que cucumber no funcione, pero he conseguido terminar el GET :D Además, es posible que mañana antes de la presentación pueda tener el post también terminado. No está mal para no tener ni idea de Ruby y Vi (que por cierto, le estoy cogiendo el gustillo :P A ver si me animo y os escribo algo) Personalmente creo que el código no ha quedado del todo mal, aunque seguro que mañana me darán caña a tope (eso espero) :D Si tenéis ganas, también podéis criticarlo vosotros en los comentarios o por twitter :)
Lo dicho, siento que sea una entrada tan corta, pero ha sido un día extraño y tranquilo.
¡Nos vemos!
Que bonita es la nieve
Hoy ha sido un día extraño en Winchester. Anoche nevó mucho y nos hemos levantado con unos 20 centímetros de nieve. Eso ha provocado un mini caos en la ciudad debido al cual solo hemos podido ir al taller tres personas de Eden (Enrique, Aimee y yo) y los cuatro compañeros que están por parte del cliente :S Cuando nos hemos querido poner a trabajar nos hemos dado cuenta de que no funcionaba internet, no sabemos por qué. El proyecto del cliente lo necesita (skype para pair remoto, consultas de documentación, etc), así que nos hemos bajado a trabajar a un café cercano que tiene WiFi :D Este tweet sirve como prueba. A la hora del almuerzo, el equipo del cliente ha decidido irse a Londres para evitar problemas con los trenes, lo que ha dejado a Aimee y Enrique compuestos y sin novio :P Esto nos ha llevado a adelantar la proyección de Avatar (edición de coleccionista), por lo que, aunque la película mola, no hemos trabajado demasiado :P
¿Os lo había contado? El otro día planeamos ver Avatar en Eden :) Otra de esas cosas que crean relaciones personales y que tanto se dan en Eden :)
Avances en el PlageServer
Mañana tengo la presentación del PlageServer y no va del todo mal, aunque quiero darle un repasillo esta noche. Tengo algún problema con los require que provoca que cucumber no funcione, pero he conseguido terminar el GET :D Además, es posible que mañana antes de la presentación pueda tener el post también terminado. No está mal para no tener ni idea de Ruby y Vi (que por cierto, le estoy cogiendo el gustillo :P A ver si me animo y os escribo algo) Personalmente creo que el código no ha quedado del todo mal, aunque seguro que mañana me darán caña a tope (eso espero) :D Si tenéis ganas, también podéis criticarlo vosotros en los comentarios o por twitter :)
Lo dicho, siento que sea una entrada tan corta, pero ha sido un día extraño y tranquilo.
¡Nos vemos!
miércoles, 1 de diciembre de 2010
Esas pequeñas cosas
Desde que he llegado a Eden no han parado de sorprenderme las cosas que suceden sin que nadie les de importancia y que a mi me dejan con una sonrisa en la boca :)
Una de las primeras sorpresas que me llevé fue como funciona el stand up diario que se celebra a las 9:30. La típica reunión corta en la que cada uno dice que hizo ayer y que va a hacer hoy. ¿Típica? Bueno, típica no es, porque Eden es diferente. La mayor diferencia es que no hay una reunión por equipo. Hay una única reunión en la que participa todo Eden (por skype si no has podido ir a la oficina) y todos los clientes que estén con ellos en las oficinas. Mola porque todo el mundo sabe lo que está haciendo todo el mundo y mola porque no hay diferencias entre técnicos, no técnicos, clientes, internos :P Todos somos iguales y todos somos importantes :)
Pero sin duda, lo mejor de la reunión sucede cuando termina la ronda. Entonces llega el momento en el que el que quiera puede contar cosas interesantes que ha descubierto en casa (Por ejemplo, Enrique hoy ha hablado de los koans para clojure). ¿No os ha pasado alguna vez eso de haber leído algo super molón sobre programación y no tener nadie con quien compartirlo en el trabajo? Pues aquí es casi obligatorio que lo compartas :D
El momento de antes de la reunión también es divertido y suelen surgir conversaciones curiosas en torno a la programación. Hoy, por ejemplo, ha surgido el tema "frameworks sí, frameworks no" que tanto gustó en el AOS2010 :D
Espera, que no me lo creo del todo. ¡Mis compañeros hablan de programación en el trabajo! Moooola. Y además nadie les mira como si fueran frikis :P (Lo digo porque a Alfredo y a mi alguna vez sí que nos han mirado raro...)
Otro de los momentos en los que surge la magia es la hora de la comida. Todos los días ha pasado algo divertido e inspirador.
Mi primer almuerzo, como ya os conté, sirvió para que me contaran como ven la empresa, por qué es como es, etc.(Tengo ese tema pendiente, no me olvido) Todo de una forma muy natural y abierto a todo el que quisiera escucharlo.
El segundo día Chris nos contó como estaba enseñando a programar a su hijo de 6 años. Está utilizando un programa que simula un enfrentamiento entre robots y tu tienes que programarte el tuyo. Aquello dio paso a una discusión en torno a la mejor manera de acercar a niños tan pequeños a la programación bastante didáctica :)
Después, Enrique nos hizo la kata de los números romanos a unos cuantos curiosos en menos de 5 minutos (y creo que en mucho menos), dejándonos ojipláticos.
Hoy nos hemos juntado como grupo de estudio de patrones de diseño y hemos hablado sobre el Singleton. No nos ha tocado el más divertido pero aún así ha sido una charla interesante. Además, me he enterado de que twitter usa el 3% de sus servidores para Justin Bieber :O
De todo lo que os he contado, lo que me parece más importante es lo fácil y espontáneo que es, y el hecho de que sea abierto a todos los que quieran acudir (por supuesto, no es obligatorio), ya sean clientes o personal de Eden porque, mientras estás en Eden eres Eden :D
PD: El servidor va mejor :D Hoy he conseguido resolver un GET de un navegador :P Lo malo es que después me lo he cargado en la fase de refactor... El código no está del todo mal, aunque imagino que el viernes me meteran caña a tope :D
Una de las primeras sorpresas que me llevé fue como funciona el stand up diario que se celebra a las 9:30. La típica reunión corta en la que cada uno dice que hizo ayer y que va a hacer hoy. ¿Típica? Bueno, típica no es, porque Eden es diferente. La mayor diferencia es que no hay una reunión por equipo. Hay una única reunión en la que participa todo Eden (por skype si no has podido ir a la oficina) y todos los clientes que estén con ellos en las oficinas. Mola porque todo el mundo sabe lo que está haciendo todo el mundo y mola porque no hay diferencias entre técnicos, no técnicos, clientes, internos :P Todos somos iguales y todos somos importantes :)
Pero sin duda, lo mejor de la reunión sucede cuando termina la ronda. Entonces llega el momento en el que el que quiera puede contar cosas interesantes que ha descubierto en casa (Por ejemplo, Enrique hoy ha hablado de los koans para clojure). ¿No os ha pasado alguna vez eso de haber leído algo super molón sobre programación y no tener nadie con quien compartirlo en el trabajo? Pues aquí es casi obligatorio que lo compartas :D
El momento de antes de la reunión también es divertido y suelen surgir conversaciones curiosas en torno a la programación. Hoy, por ejemplo, ha surgido el tema "frameworks sí, frameworks no" que tanto gustó en el AOS2010 :D
Espera, que no me lo creo del todo. ¡Mis compañeros hablan de programación en el trabajo! Moooola. Y además nadie les mira como si fueran frikis :P (Lo digo porque a Alfredo y a mi alguna vez sí que nos han mirado raro...)
Otro de los momentos en los que surge la magia es la hora de la comida. Todos los días ha pasado algo divertido e inspirador.
Mi primer almuerzo, como ya os conté, sirvió para que me contaran como ven la empresa, por qué es como es, etc.(Tengo ese tema pendiente, no me olvido) Todo de una forma muy natural y abierto a todo el que quisiera escucharlo.
El segundo día Chris nos contó como estaba enseñando a programar a su hijo de 6 años. Está utilizando un programa que simula un enfrentamiento entre robots y tu tienes que programarte el tuyo. Aquello dio paso a una discusión en torno a la mejor manera de acercar a niños tan pequeños a la programación bastante didáctica :)
Después, Enrique nos hizo la kata de los números romanos a unos cuantos curiosos en menos de 5 minutos (y creo que en mucho menos), dejándonos ojipláticos.
Hoy nos hemos juntado como grupo de estudio de patrones de diseño y hemos hablado sobre el Singleton. No nos ha tocado el más divertido pero aún así ha sido una charla interesante. Además, me he enterado de que twitter usa el 3% de sus servidores para Justin Bieber :O
De todo lo que os he contado, lo que me parece más importante es lo fácil y espontáneo que es, y el hecho de que sea abierto a todos los que quieran acudir (por supuesto, no es obligatorio), ya sean clientes o personal de Eden porque, mientras estás en Eden eres Eden :D
PD: El servidor va mejor :D Hoy he conseguido resolver un GET de un navegador :P Lo malo es que después me lo he cargado en la fase de refactor... El código no está del todo mal, aunque imagino que el viernes me meteran caña a tope :D
Suscribirse a:
Entradas (Atom)