Ganado en lugar de mascotas

25/4/2013 5:36 am

Influenciado por la lectura del libro del proyecto Phoenix, que os recomiendo a todos, creo que voy a escribir este articulillo en versión novelada sobre el tema de tratar servidores como ganado en lugar de como mascotas (cattle no pets), a ver qué tal se da.

5532770373_3811034fd7

“Son las 3 de la mañana y el maldito “busca” vuelve a sonar. Puff, ¡menuda semanita llevo!, pienso mientras a tientas busco el maldito cacharro en la mesita de noche para poner fin a sus convulsiones y chillidos. “Webserver15.httpfarm load average ALERT”. Por un instante pienso en volverme a dormir. Un solo nodo cargado y ninguna otra alerta, como por ejemplo retardos en la carga de la página no debería ser un problema, pero… algo en mi interior me lo impide y ¿si es importante?. A mi lado mi mujer murmura algo acerca del maldito zumbido mientras me voy incorporando para llegar a la mesa del despacho donde presiono el botón de inicio del portatil, que tampoco parece feliz de ser despertado en medio de la noche.

Al parecer, un par de procesos se han quedado bloqueados esperando a un recurso compartido que estaba tardando demasiado en responder y eso ha elevado la carga en ese nodo, mientras en todos los demás todo sigue bien. Mando al nodo sospechoso al banquillo modificando la configuración del balanceador para ser examinado mañana más a fondo, y decido terminar la noche durmiendo en el sofá para no molestar en caso de que la rebelión continue. Solucionar el problema me llevó 15 minutos pero ya no puedo dormir en las siguientes horas así que dejo entrar a Oscar, nuestro gato, para que me haga compañía. Mientras acaricio su panza pienso que algunos de nuestros servidores requieren más cuidados que una mascota.

A la mañana siguiente, despues de la reunión de arranque del equipo, me dedico a investigar que le pasó al nodo molesto. Al parecer, una de las modificaciones que hicimos hace varios meses a la granja de servidores web había sido aplicada, pero el recurso no había sido remontado, con lo cuál no había tenido efecto.

¡Maldita sea!, otro copo de nieve (aka snowflake), parece que nuestro proceso de homogeneización no está tan refinado como creíamos. Reinstalar el servidor es un proceso completamente automatizado que tan sólo lleva unos minutos. Una vez que ha vuelto a la vida verifico que el nuevo nodo es exactamente igual que sus compañeros del corral, para a continuación abrir el grifo en el balanceador para que comience a llegarle tráfico de nuevo. Todo funciona a la perfección.

En la mayoría de los casos y con el nivel de redundancia que tenemos es obvio que es un error tratar a cada servidor como una mascota. Debemos de empezar a pensar en ellos más como ganado, y especialmente en diseñar nuestros sistemas para que en caso de error, el procedimiento sea sustituir al enfermo por uno exactamente igual y ya en caso de requerir una intervención especial entonces alertar a uno de los doctores. Una de las ventajas es que todas las gráficas de rendimiento y los logs de los servidores se mantienen en servicios separados, con lo que no estaremos borrando pistas para el analisis post-mortem. Incluso podríamos ponerlo simplemente en cuarentena.

Paso el resto del día poniendo en práctica esta idea de “ganado en lugar de mascotas” en nuestra granja de servidores web reconfigurando el sistema de monitorización para, en caso de detectar un nodo enfermo jugar el combo de cartas: “tiro en la cabeza” y “resurreción de entre los muertos”. En aquellos casos en los que la alerta se repita en breve en el mismo nodo, alertaremos al vaquero de turno. Ahora, para asegurar que el sistema funciona y que lo seguirá haciendo, es hora de soltar al “mono del caos” que introducirá errores en los servidores cada cierto tiempo de forma que el procedimiento se esté verificando constamente.

Los resultados en la granja web han sido muy satisfactorios y hemos decidido empezar a extender el proceso a todos los servidores. De hecho, este evento nos ha hecho replantearnos cómo vamos a hacer el proceso de alerta fuera del horario de oficina, sustituyendo cientos de alertas individuales (cpu alta, sistemas de ficheros lleno, etc) por otras que eliminen la individualidad del asunto (el portal está caido, la búsqueda media es demasiado lenta, etc).

Espero que mi gato Oscar no esté preocupado porque lo sustituya por un corralito lleno de cerdos.”

VN:F [1.9.22_1171]
Rating: 9.0/10 (2 votes cast)

Cultura devops en REA

5/8/2012 11:41 am
Comentarios desactivados

Como muchos sabéis ya, hace algo más de 4 meses que inicié mi aventura en tierras Australianas y comencé a trabajar para REA, grupo que se dedica a la gestión de publicidad online para el mercado inmobiliario, principalmente en Australia, pero con presencia internacional en Italia, Luxemburgo, HongKong, etc…

Deajando aparte el factor aventura, y las ganas de conocer esta parte del mundo, cuando me ofrecieron este trabajo se unieron la oportunidad de trabajar en una compañía que maneja algunos de los portales con más tráfico de Australia con mi interás por dedicarme a las operaciones web a gran escala. Uno de los elementos que más me atrajo fue la cultura de la compañía, que por lo que pude adivinar en las entrevistas, y he verificado postriormente, destaca por una implantación muy alta de metodologías ágiles, equipos de alto rendimiento y gran nivel técnico, mentalidad hacker, mimo por los empleados y una cultura devops muy evolucionada.

Un ejemplo del arraigo de la cultura devops en la empresa es que los dos grupos que celebran reuiones en la zona sobre el tema: “Melbourne devops” e “Infrastructure coders” están siempre sobre poblados de gente de REA, ya sea en el público, como colaboradores o como organizadores. Fuera de Australia, cuando uno de mis compañeros recientemente asistió a Velocity y Devopsdays en Estados Unidos recibió comentarios de admiración sobre el grado de implantación de la cultura devops en la compañía.

Pero después de tanto rollo, ¿cómo es la cultura devops en REA? Podría decirse que en una compañía como esta, en la que los conceptos de agilismo y lean están tan marcados en todos sus estratos, la búsqueda de la eficacia y las mejores prácticas es una evolución constante. Si aplicamos estos elementos al concepto de cómo operamos nuestros servicios nos damos cuenta de que se trata de un viaje que implica un cambio constante. Podemos marcar el comienzo de este viaje hace ya algún tiempo, cuando las operaciones eran ejecutadas de forma centralizada por el equipo de Operaciones Web (dentro del área de IT). Los ya consabidos problemas consecuencia de la separación de Operaciones y Desarrollo, sumados a la desalineación de ambos con los intereses del área de negocio, llevaban a un funcionamiento ineficiente. Operaciones estaba descontento porque no podía solucionar los problemas endémicos, ya que no estaba presente en el proceso de creación y/o mejora de los productos. El equipo de Desarrollo por su parte veía en Operaciones un elemento bloqueante, que no le permitía alcanzar la velocidad demandada por el entorno del negocio, en aras de mantener la estabilidad del entorno. Y todo acaba con las consabidas peleas de perros y gatos, tan ilustradas en cualquier presentación sobre devops.

Los primeros refinamientos del proceso se basaron en empezar a “infiltrar” miembros del equipo de Operaciones en los distintos equipos de Desarrollo, para intentar mejorar la comunicación, y para conseguir que el elemento de operaciones estuviera presente en el día a día del desarrollo y mejora de los servicios. Al parecer el comienzo no fue muy fácil ni agradable y en algunos casos los equipos rechazaban al nuevo miembro, como cuando un cuerpo rechaza un transplante, y también había choques culturales, siendo los “infiltrados” los que no se sentían cómodos en este nuevo ambiente. Su trabajo consistía casi únicamente en realizar pasos a producción de forma manual una y otra vez. Por aquel entonces, había un segundo equipo denominado SPA (Site performance and availability) que se encarga del soporte global de las operaciones, es decir del cuidado de las infraestructuras y gestión de incidencias relacionadas con producción.

Transcurrido algún tiempo comenzaron a hacerse evidentes las ventajas del modelo, gracias al éxito de los equipos que lo habían implementado. Esto dió paso a prácticas que mejoraron el proceso de despliegue y gestión de los servicios mediante la automatización de los mismos y al comienzo de la adopción de un modelo PaaS (Plataforma cómo servicio) cuyo objetivo era la estandarización de los entornos y la simplificación en las operación de los mismos.

Los siguientes pasos en este proceso son la incorporación de la obre la gestión de las operaciones en estos equipos que ahora serán responsables del servicio de forma global incluyendo la creación, mejora y operación del mismo. Este proceso incluye la gestión y resolución de incidencias, ahora los miembros de SPA se han enbebido completamente en los equipos, y el siguiente paso es conseguir que la responsabilidad de solucionar los problemas recaiga en todo el equipo: desarrolladores, calidad, operaciones e incluso los productores y responsables de negocio que poco a poco se han ido incorporando al equipo en su día a día, formando algo parecido a mini startups dentro de la empresa. Por lo que ahora todo el equipo se sienta en la misma zona de la oficina, atiende a las reuniones diarias (standups) y participa en el trabajo cómo uno más. Se acabó esto no lo podemos resolver esto porque X o G no colaboran. Los problemas se priorizan dentro del equipo y se decide que demandas se deben atajar primero y el diseño de nuevas funcionalidades siempre cuenta con la idea de cómo vamos a operar el servicio cuando este esté en producción.

Respecto a la tecnología usada dentro de los equpos relacionada con devops podríamos describirlo cómo que cada equipo tiene libertad para utilizar los elementos que le sean más productivos para conseguir sus objetivos, es la ventaja de tener el control y la responsabilidad de extremo a extremo de los elementos, y en muchos casos esta apoyada en la estandarización que provee el uso de una plataforma común, de la que ya hablaré en un articulo posterior. Por tanto nos encontramos elementos muy distintos cómo puppet o chef para la gestión de configuración, el uso de rpms para la distribución de nuestras aplicaciones, nagios, newrelic, gomez y graphite para monitorización y métricas entre otros muchos.

La implantación de la cultura devops en una compañía no puede medirse cómo blanco o negro, más bien se trata de un gris que va cambiando de tono ya que está en constante evolución persiguiendo el fin último de mejorar la forma en que ofrecemos nuestros servicios y aumentamos el valor para nuestros clientes, así que os mantendré informador de futuras mejoras y la implantación de los planes actuales.

VN:F [1.9.22_1171]
Rating: 9.0/10 (1 vote cast)

Bye, bye Andago

8/3/2012 2:22 pm

Bueno, pues después de 7 años trabajando en Andago ha llegado el momento de cambiar de aires. Sobre mi andadura en Andago ya he escrito mucho, basta con ver la etiqueta de Andago en este blog, pero quería escribir este último post resumiento la experiencia que ha sido trabajar en un sitio tan especial durante una temporada tan importante en mi vida.

Por dónde empezar, quizá lo más fácil sea por el principio. Una vez superada la llegada de este garrulo a la caital me dirigí a la que sería mi oficina por una buena temporada. Nada más entrar en la oficina me dí cuenta de que estaba en el sitio adecuado, mientras esperaba a que me trajeran varios papeles que debía firmar miraba con curiosidad a un curioso grupo, valga la redundancia, que se reunía en el centro de la oficina y comentaban cómo se iba a desplegar el cluster de correo que estaban planificando para un Ayuntamiento. He de decir que al principio me sentí intimidado por el potencial de los compañeros que me encontré allí pero ha sido sólo a lo largo de los años que me doy cuenta la suerte que he tenido de compartir todos estos años con ellos y cómo me han hecho crecer en los personal y en lo profesional. Gracias chicos, aunque a veces se olvide Andago es y será siempre la gente que durante todos estos años ha hecho posible el proyecto, y por supuesto que sin el granito de cada uno ya habría dejado de existir hace tiempo. ¡Sois la hostia!

Una de las cosas que debo destacar, y por la que creo que he podido permanecer tantos años en la misma empresa, ha sido la capacidad de crecimiento tanto personal cómo profesional que me ha permitido. Para mí la sensación ha sido siempre que el límite de hasta dónde uno puede llegar se lo impone uno mismo y su capacidad para asumir nuevos retos con éxito. Esto unido a la gran hetereogeneidad en los proyectos y funciones con las que me ha tocado lidiar ha hecho que fuera muy dificil aburrirse en el trabajo. Desde los primeros años participando en proyectos de infraestructura de muy diversa indole, pasando por la epoca de las redes wifi metropolitanas que andaba de saltimbanqui por los tejados, la reconversión en una empresa más orientada al desarrollo web y posteriormente a productos y servicios, las ponencias en eventos internacionales, la creación del departamento de arquitectura cómo apoyo a estos cambios y por último la dirección completa del área de IT de la compañía y la apertura de la sede de Cambridge dónde he trabajado el último año. Casi na.

Pero igual que todo tiene un principio también tiene su fin y parece que ha llegado la hora de buscar nuevos vientos sobre los que seguir volando, más adelante os contaré más sobre mi nuevo trabajo en tierras muy, muy lejanas pero mientras tanto os dejo con mi buen recuerdo de esta temporada trabajando en Andago a través de unas fotillos:


“Fotos variadas del tiempo que estuve currando en Andago.”

From Andago, posted by Javier Turégano on 3/08/2012 (43 items)

Generated by Facebook Photo Fetcher


VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)

Pensando en Devops

23/10/2011 12:19 pm
Comentarios desactivados

No sé si os lo he comentado ya varias veces pero me encanta la nueva mentalidad alrededor de las tendencias Devops y las Operaciones Web ágiles. Creo que es un cambio de mentalidad necesario y un gran avance para nuestra profesión pero que implica cambios a todos los niveles. Ya llevaba tiempo pensando en escribir sobre el tema ya que los recursos en inglés sobre el mismo son inagotables, pero creo que no hay tanto en español, así que os voy a dejar un batiburrillo de reflexiones que últimamente me dan vueltas en la cabeza.

El otro día estuve en el London Puppet User Group meeting y disfruté bastante de las charlas especialmente la segunda en la que mostraron un enfoque diferente en la definición de recursos orientado a provisionar varios servidores a través de Open Nebula y dejarlos configurados y operativos, todo ello a través de Puppet. Pena que todavía no he tenido la suerte de poder acercarme a London Devops y me alegro infinito de que Madrid Devops siga viento en popa, desde aquí mis felicitaciones a Mari Carmen por el empeño que está poniendo y a todos los que os acercáis a compartir por ese foro, ¿se nota que os echo de menos? :D

Una de las primeras cosas que me vinieron a la cabeza es que no estoy seguro de si la orientación que está tomando la gente de Puppet Labs va muy en la línea de lo que yo busco en su producto. Por un lado, mantener dos desarrollos separados para la edición Enterprise y la edición Comunidad y por otro, el enfoque hacia grandes corporaciones y hacia la incorporación de elementos cómo gestión de CMDB, Workflows, etc para mí rompe un poco con la mentalidad Unix: pequeñas herramientas que hacen muy bien su trabajo y que en conjunto te dan una gran flexibilidad. Personalmente me gustaria que se trabajara más en la parte de orquestación y en romper el enfoque nodista, decidir el estado de mis nodos, por uno mucho más orientado a conjunto o a servicio.

Me encanta mcollective, creo que es una herramienta muy potente, pero no dejo de verla cómo un loop ssh para ejecutar un comando en el resultado de la busqueda de nodos que cumplen ciertas características y no lo termino de enlazar con una orquestación más basada en estados cómo es puppet sino en acciones.

Por cierto, si tenéis tiempo libre y os interesa el tema de Puppet os recomiendo que le echéis un vistazo a los videos de la pasada Puppet Conf y también a este repositorio Git que ha compartido la gente de Wikimedia con los manifiestos que ellos están usando para gestionar su infraestructura.

Otra reflexión sobre puppet, antes de pasar a otro tema, me vino del descubrimiento que en las plantillas para ficheros tipo erb podía utilizar todo el código Ruby que quisiera y esto solucionó algunos de los problemas que me estaban rondando últimamente para definir algunas plantillas algo complejas. Desde entonces un run-run en mi cabeza no para de decirme si aplicando el mismo concepto no sería mucho más potente el uso de Chef que utiliza una sintaxis más amplia y te permite utilizar el juego completo de instrucciones de ruby en tus manifiestos. Hace tiempo que no pruebo Chef, pero comentando esto con gente de la conferencia me comentaban que la orientación de Chef no cambia únicamente en eso sino que también hay que tener en cuenta que al contrario que Puppet, la ejecución de la configuración en Chef en varias ocasiones consecutivas sobre el mismo entorno en el mismo estado podría no dar lugar a los mismos efectos. Aquí me vendría bien ayuda de gente que se haya pegado más con los dos sistemas, ¿cómo véis el estado del arte los Chefistas y los Puppeteros?

Y de paso aprovecho también para volcar a texto otra de mis inquietudes de los últimos meses. Hace ya tiempo que quiero ampliar mis habilidades aprendiendo y cogiendo práctica con un lenguaje de scripting que me ayude a ser más eficiente y amplie mis posibilidades. Al principio python parecía el camino adecuado, pero cada día que pasa siento que hay más y más herramientas de administración escritas en ruby, con lo que me crece la duda, por ahora sigo poco a poco la senda de python y ya sé que la respuesta a la pregunta es: aprende los dos, pero cómo el tiempo es limitado habrá que dividir los esfuerzos o priorizarlos, ¿cómo lo véis?

Una parte de la charlas posteriores entre cervezas y pizza que me encantó era lo que comentaba uno de los asistentes: “Yo no quiero a los desarrolladores anden tocando en mis servidores”, pero estuve pensando y creo que no sólo es la idea correcta sino que habría que ampliarla “No quiero a nadie rondando en mis servidores, ya sean de los equipos de desarrollo u operaciones y menos aún alguien de fuera”, si hay que hacer retoques en los entornos de producción estos deberían hacerse siempre desde las herramientas de gestión de configuración y cambios de tus entornos y a través de unos workflows definidos y probados ampliamente, nunca tener que realizar acciones directas sobre las máquinas. Otro de los comentarios fue que “los equipos de desarrollo quieren estar modificando continuamente lo subido y a veces van demasiado rápido”, y creo que aquí está otro de los puntos clave del cambio que estamos intentando llevar a cabo con mentalidades ágiles y devops: nuestro objetivo debe ser el de habilitar el cambio y potenciarlo, eso sí poniendo los mecanismos necesarios para asegurar el éxito: integración continua, desarrollo guiado por pruebas, automatización del despliegue, paso rápido entre entornos de pre y pro o despliegue continuo son los habilitadores para ello y tenemos que encontrar la mejor manera de integrarlos en nuestros ciclos para ganar en agilidad.

Y en el terreno herramientas, no puedo dejar de comentar una de mis favoritas en los últimos días es Vagrant, si no la habéis probado no tardéis mucho en hacerlo. Hace tiempo que estaba buscando un sistema que me permitiera gestionar facilmente máquinas virtuales en mi portátil de forma que si necesito probar algo en una Debian, Redhat o lo que sea pueda levantarla rapidamente tener un entorno configurado rápidamente y hacer la prueba y destruir la máquina. Para ello Vagrant es ideal, es un conjunto de scripts en Ruby, elo aquí de nuevo, que usan Virtualbox por debajo normalmente en modo no gráfico y que te permite levantar una serie de plantillas de máquinas virtuales (os recomiendo vagrantbox.es para descargarlas), además tiene integración con puppet y chef de forma que puedes indicarle que ejecute un manifiesto al arrancar y que te deje el entorno ya configurado según unos parámetros. Impresionantes las posibilidades también para los equipos de desarrollo a los que se puede pasar un entorno similar al de producción y ellos pueden ejecutarlo en sus máquinas para desarrollar, hacer pruebas, etc… Vamos, no hay día que no me levante al ritmo de un comandazo “vagrant up”!

Por último voy a dejar a continuación tres juegos de transparencias que me han gustado bastante en los últimos días y que creo que son bastante explicativas de todo esto al rededor del movimiento Devops:

Y lo más importante, si has llegado hasta aquí por favor deja tu comentario en la entrada para que generemos algo de debate al rededor del tema. Muchas gracias a todos. :D

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)

Aplicando Scrum en el departamento de IT

9/10/2011 8:24 pm
Comentarios desactivados

Esta entrada la tengo pendiente desde hace bastante tiempo y resume un poco las experiencias que hemos tenido en el uso de Scrum y metodologías ágiles dentro del departamento de IT. Cómo hay muchísimo ya escrito sobre cómo aplicar Scrum y sus efectos beneficiosos voy a enfocarme en una lista de comentarios sobre cómo he visto nuestra aplicación de la metodología.

- Cómo nuestro trabajo tiene un componente alto de resolución de incidencias y solicitudes que deben ser atendidas en un periodo muy corto de tiempo no pudiendo esperar a ser incluidas en el siguiente sprint al finalizar las dos semanas de este optamos por dedicar un porcentaje de nuestro esfuerzo diario al sprint en curso y el resto del porcentaje a las tareas del día a día, resultando ser bastante efectivo y sólo en algunos casos comiendose el tiempo de uno el otro.

- Inicialmente para que el salto de concepto no fuera demasiado grande no empezamos usando historias de usuario sino algo más parecido a una división por tareas y las valoraciones de dificultad estaban más enfocadas sobre el tiempo que le llevaría a cualquiera de nosotros llevar a cabo la misma que en la dificultad intrinseca de la misma. – Para evitar eternas discusiones de si eso era la forma “verdadera” de hacer Scrum les decíamos que nosotros hacíamos Scrutch no Scrum.

- La reunión de planificación del Sprint resulta mucho más útil que el modelo tradicional en la que alguien se encarga del diseño y el calculo de esfuerzos y luego todo el equipo debe responder por ello. Así todo el equipo recibe una visión temprana del volumen de trabajo y las dificultades y crea también una especie de compromiso con lo pronosticado, mucho mayor que si alguien te impone una cifra. Además el Planning Poker es divertido y también saca un poco la personalidad de cada uno a la hora de estimar tareas, ejercicio muy recomendable junto con las reuniones de retrospectiva.

- La pizarra con los postit y el burndown chart son una medida muy útil para que todo el mundo pueda ver de un vistazo dónde estamos y lo que queda por hacer para llegar al final del sprint a tiempo, además resultó un atractivo para el resto de equipos que no veían muy claro que hacíamos con los postit.

- Otro punto muy positivo fue el de la defnición de terminado para una tarea. Para nosotros en este caso no sólo siginificaba que estuviera hecho sino que estuviera provado, documentado y su correspondiente ticket actualizado, sin los cuales la tarea no se podía parasar a finalizada y así comenzar otra, con lo que todo el mundo tenía muy claro lo que había que hacer.

- Uno de nuestros fallos fue no conseguir una mayor implicación por parte de los distintos product owners, en muchos casos actuando la misma persona, vamos yo, actuaba cómo product owner, scrum master y miembro del equipo, lo que quitaba un poco el factor integrador que nos da el uso de Scrum. Otro fallo en algunos proyectos que implicaban otras areas fue no incluirlos en nuestro Sprint y simplemente esperar que para cuando nosotros estuvieramos en el punto de necesitar sus productos estos estarían listos.

- El product backlog es una herramienta que sigo utilizando para todo tipo de actividades para que nada quede en el olvido, se clasifique y se prepare su entrada a la ejecución.

- La valoración de la satisfacción creo que fue bastante grande y sobretodo una gran mejora frente a no utilizar ninguna metodología, quizá poco a poco se podría ir incorporando más conceptos puros de Scrum y mantener aquellas modificaciones que nos han sido de utilidad.

- Actualmente sólo lo usamos en momentos puntuales cuando aparece un trabajo que nos va a costar más de dos semanas y que debe ser llevado por varios miembros del equipo

- Constantemente pienso que Kanban podría ser una alternativa más global que nos permitiría también meter la gestión de incidencias y tengo pendiente que hagamos algún piloto para ver que tal nos funciona.

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)

Medio año de emigrante

8/10/2011 11:06 am
Comentarios desactivados

Es increible pero ya ha pasado más de medio año desde que decidimos hacer las maletas y emigrar a la isla del té a las cinco. El tiempo pasa volando y aunque a mí me sigue pareciendo que llegamos ayer el maldito reloj ha seguido avanzando. Muchas cosas han ido mucho más lento de lo que esperábamos, he de reconocer que nos está costando arrancar pero que a la vez estamos disfrutando la aventura. Y en el futuro… ¿quién sabe? Igual en un mes estamos de vuelta que seguimos aquí por bastante tiempo.


“Fotos de la vida cotidiana en Cambridge.”

From Vida en Cambridge, posted by Javier Turégano on 4/08/2011 (37 items)

Generated by Facebook Photo Fetcher


VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)

Corto en la politécnica, año 99, ¡qué recuerdos!

25/9/2011 9:28 pm

Hace poco un compañero subió a YouTube un corto que hicieron unos amigos cuando estudiábamos en la polítécnica de Albacete y me ha traido tantos buenos recuerdos, a pesar de lo malo que es :D , que he querido compartirlo con vosotros. Aquí va, os aconsejo que lo veáis primero y luego sigáis leyendo porque voy a soltar algunos spoilers, jajaja. Por cierto, aunque de extra y casi por la fuerza, aparezco en dos momentos en el vídeo, ¿dónde está Ture?

Ver la politécnica en la que pasé tantos años y a los amigos en aquella época me ha dado mucha emoción, más ahora que me siento que estoy tan lejos de mi Albacete querida. Pero hay algunos detalles épicos en este vídeo:

- Las pintas del Po con su media melenilla y del Paliquín, sorry Javi en ese vídeo así te hubiera llamado.
- Cuando arranca el Turbo Pascal en el aula software 5 con los PCs, hoy en día, retro total, qué torrente de recuerdos.
- La publicidad “subliminal” del Fifa 99, menudos vicios en uno de los mejores juegos de fútbol de todos los tiempos.
- La cafetería, los pasillos, y toda la politécnica, qué de recuerdos buenos y malos.

Recuerdo ver el vídeo en el salón de actos en la presentación, no sin algo de verguenza he de reconocer, y si en aquel momento me dicen que iba a disfrutar tanto viendolo en ese momento nunca me lo habría creido.

Por cierto, para los que no me hayáis encontrado la primera vez que aparezco es cuando entra el Po en el aula de prácticas y de pasada se ve mi cara programando en uno de los PCs (3:07) y el segundo que yo ni reconozco es cuando le dan una paliza a la salida de la politécnica (4:40 aprox).

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)

Aprender español en Cambridge

19/8/2011 9:04 am
Comentarios desactivados

Pues después de darle un par de vueltas ya está lista la web de Lili para sus clases particuales de español en Cambridge:

La verdad es que con las ganas que le ha puesto a la página web estoy seguro que le van a llover los alumnos, el próximo paso empapelar Cambridge con cartelitos de spanishincambridge.co.uk.

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)