Me cambio de nuevo de empresa, mañana será mi último día en algor, la subcontrata de telefónica I+D donde he estado trabajando. 6 meses (y 1 día) es el tiempo que he estado aquí, realmente poco (aunque solo un pelo por debajo de mi media en una empresa).
Las razones de mi marcha son fundamentalmente 2:
- Yo no estoy hecho para estas empresas donde la productividad no es importante, donde no se aprecia al empleado y se trabaja con personas como carneros. Hay gente que le gusta esto, que aguanta o que no tiene otra salida, no es mi caso.
- Telefónica I+D, además de querer que me cambiase de empresa de forma unilateral, no creo que tuviese en mente mantenerme demasiado tiempo más en su plantilla de "personal ajeno". La cosa está muy negra, la forma de trabajar de estas empresas propicia que cuando se necesita aportar valor todo se desplome y telefónica I+D es la reina del lugar.
En general no me he adaptado bien a la forma de trabajar, no comprendo muchas de las cosas que se hacen, ni la gente me entiende a mi, tampoco comprendo como la subcontratación y dispersión de los integrantes de un proyecto es algo común.
Bueno, sea como fuere, yo me marcho de aquí con un regustillo agridulce. Por una parte ya conozco como funcionan estas empresas, he conocido a gente muy agradable, pero me doy cuenta que el futuro de parque tecnológico de boecillo no es muy largo tal como está ahora, ha llegado el momento de las empresas que aportan valor y son competitivas, y esas no están en boecillo (*).
Mi siguiente destino es Pamplona, me voy a una empresa que vende lo que hace, que gana dinero con ello y que compite. Espero aprender mucho y poder aportar lo que no he podido aportar aquí (seguramente la única espina que me queda clavada). Por lo menos me voy con el consuelo que ahora @lalangosta sabe que es trac, @Chiralilla conoce mercurial y @djgago sabe que los buenos sitios webs se hacen con python :)
(*) Seguramente habrá empresas que funcionen bien en boecillo, disculpas por adelantado, no he llegado a conocer ninguna.
5.28.2009
5.25.2009
Nuevo microblog: retales de código
Me fascina ver como hay gente que es capaz de sacar el máximo partido a unas cuantas líneas de código. Por eso he creado un microblog alojado en tumblr que me parece un servicio la mar de adecuando para estas cosas sobre pequeños trozos de código que hacen grandes cosas. Además los creadores tienen pinta de ser gente guay (usan mac, monitores gordotes, oficinas supermolonguis) :p. Por cierto, que interesante es ver como son las oficinas y como trabajan otros desarrolladores, pero eso es para otro post.
Otros microblogs que sigo, relativos a programación son, lines of code de LinkingPaths y commandliners mantenido, entre otros, por @rafacas.
Bueno, aquí os lo dejo: small pieces of code
Otros microblogs que sigo, relativos a programación son, lines of code de LinkingPaths y commandliners mantenido, entre otros, por @rafacas.
Bueno, aquí os lo dejo: small pieces of code
5.24.2009
Manual práctico para coger rotondas
Creo firmemente que la gente no sabe usar las rotondas adecuadamente y para ello voy a dar una serie de consejos, que nadie leerá, pero que quizás alguien encuentre en google y evite algún que otro accidente.
Primera y única norma: Una rotonda es exactamente lo mismo que una carretera, pero en curva
Esto es:
- Si estás en el carril interior y quieres coger una salida tienes primero que pasar al exterior y luego salir. Imaginemos que vamos por una autovía en el carril izquierdo, a nadie se le ocurriría salir desde ahí a la salida de golpe y obviamente el que circula por la derecha no se tiene ni que salir obligatoriamente, ni cederte el paso.
- Nadie te obliga a circular por ningún carril en concreto, sea cual sea la salida que vas a tomar
- Para permanecer en la rotonda no hay que dar ningún intermitente siempre que no hagas cambios de carril, de la misma forma que si mantienes el carril en la autovía no tienes que dar el intermitente.
- Si vas por el carril interior, alguien entra en la rotonda al carril exterior y le das, la culpa es tuya de la misma forma que si vas por la autovía por el carril izquierdo y le endiñas al que está en el carril derecho porque haces un cambio inadecuado de carril.
Y ahora unas normas de civismo:
- Si puedes facilitar la incorporación o salida de alguien, hazlo
- Si estás por el carril interior, necesitas salir y no puedes... da una vuelta más y no prepares la pirula, van a ser 10 segundos más
- Es posible que si vas a salir por la tercera o incluso segunda salida puedas ocupar el carril interior para usar los carriles y maximizar el tráfico de la rotonda.
Y por último normas para gente que viva en Salamanca (o en pueblos en los que no sepan conducir):
- Usa SIEMPRE el carril de dentro, los paquetes nunca lo usan y depende casi exclusivamente de ti el que te des la ostia
- Si dan el intermitente a la izquierda, tranquilo, en el 99% de los casos no se trata de un cambio de carril, quieren indicar que permanecen en la rotonda.
- Si sales al carril exterior y viene un paquete por el interior, sin intermitente indicando que se cambia al exterior, NO SALGAS, porque el paquete te pitará porque él precisamente quería salir por la siguiente.
- Si ves a un seat león, coche con letras chinas, lunas tintadas (alias follo en el coche porque no tengo casa), llantas brillantes, coches de color naranja o amarillo, con prominentes alerones o con varios tubos de escape en una rotonda, no te acerques, porque seguramente no sea capaz de dar la rotonda y accionar el intermitente a la vez.
- Si usas el carril izquierdo para adelantar, te pitarán porque no entienden que si respetas los límites de velocidad estás en tu derecho de quitarte a un paquete de encima.
** Este post está dedicado especialmente a la gente de Salamanca
Primera y única norma: Una rotonda es exactamente lo mismo que una carretera, pero en curva
Esto es:
- Si estás en el carril interior y quieres coger una salida tienes primero que pasar al exterior y luego salir. Imaginemos que vamos por una autovía en el carril izquierdo, a nadie se le ocurriría salir desde ahí a la salida de golpe y obviamente el que circula por la derecha no se tiene ni que salir obligatoriamente, ni cederte el paso.
- Nadie te obliga a circular por ningún carril en concreto, sea cual sea la salida que vas a tomar
- Para permanecer en la rotonda no hay que dar ningún intermitente siempre que no hagas cambios de carril, de la misma forma que si mantienes el carril en la autovía no tienes que dar el intermitente.
- Si vas por el carril interior, alguien entra en la rotonda al carril exterior y le das, la culpa es tuya de la misma forma que si vas por la autovía por el carril izquierdo y le endiñas al que está en el carril derecho porque haces un cambio inadecuado de carril.
Y ahora unas normas de civismo:
- Si puedes facilitar la incorporación o salida de alguien, hazlo
- Si estás por el carril interior, necesitas salir y no puedes... da una vuelta más y no prepares la pirula, van a ser 10 segundos más
- Es posible que si vas a salir por la tercera o incluso segunda salida puedas ocupar el carril interior para usar los carriles y maximizar el tráfico de la rotonda.
Y por último normas para gente que viva en Salamanca (o en pueblos en los que no sepan conducir):
- Usa SIEMPRE el carril de dentro, los paquetes nunca lo usan y depende casi exclusivamente de ti el que te des la ostia
- Si dan el intermitente a la izquierda, tranquilo, en el 99% de los casos no se trata de un cambio de carril, quieren indicar que permanecen en la rotonda.
- Si sales al carril exterior y viene un paquete por el interior, sin intermitente indicando que se cambia al exterior, NO SALGAS, porque el paquete te pitará porque él precisamente quería salir por la siguiente.
- Si ves a un seat león, coche con letras chinas, lunas tintadas (alias follo en el coche porque no tengo casa), llantas brillantes, coches de color naranja o amarillo, con prominentes alerones o con varios tubos de escape en una rotonda, no te acerques, porque seguramente no sea capaz de dar la rotonda y accionar el intermitente a la vez.
- Si usas el carril izquierdo para adelantar, te pitarán porque no entienden que si respetas los límites de velocidad estás en tu derecho de quitarte a un paquete de encima.
** Este post está dedicado especialmente a la gente de Salamanca
5.22.2009
hg-wiki
Hace un tiempo he empezado a usar mercurial para mis proyectos personales. Mercurial es un sistema de control de versiones, al igual que subversion, pero distribuído, esto es, no necesitamos un servidor central donde subir nuestro código. Esto tiene muchas ventajas, no me voy a poner a enumerarlas, para ello podeis ir a la respectiva página en la wikipedia.
No hace mucho mercurial se ha empezado a usar en el desarrollo de python y google code ha dado soporte para este lenguaje, lo cual me dice que pronto empezaremos a ver más y más proyectos usándolo. Veremos si hay guerra git-mercurial (git es otro sistema de control de versiones usado en el desarrollo del kernel de linux, entre otros), viven en paz o alguno de ellos muere. Git ha tomado mucha fuerza, sobretodo por el empuje en el desarrollo web y gracias a webs como gihub, pero eso es tema para otro post.
Es muy habitual que junto al código de tu proyecto tengas otras cosas igualmente importantes como scripts de compilación, deploys, documentación, notas, etc, que normalmente están también bajo control de versiones. Además, se suele tener un sistema de tracking de proyectos acompañado (o integrado) un wiki -que siempre termina manga por hombro-.
Pensé que estaría bien tener un wiki integrado en el repositorio, al igual que con el comando hgserve tienes un servidor web integrado que te permite ver la información de forma mucho más gráfica del repositorio, por qué no un wiki?. Haciendo una búsqueda no he encontrado nada para mercurial, sí para git.
Como hace pocos días me encontré juno, un mini-framework web muy coqueto y me puse manos a la obra para probarlo, así que he creado hg-wiki, una herramienta que permite tener un wiki integrado en tu repositorio mercurial. Es un wiki muy simple, pero tiene lo justo para tener la información ordenada y vistosa.
El proyecto está alojado en bitbucket, un servicio de alojamiento de proyectos mercurial. Si quieres echarlo un ojo y probarlo: hg-wiki
Un ejemplo de como queda la cosa, primer el texto, después la imagen del resultado:
El resultado:
(si encontrais familiar el estilo de la web, no es casualidad, el css lo he tomado del wiki de github, mis conocimientos web no llegan a tanto)
No hace mucho mercurial se ha empezado a usar en el desarrollo de python y google code ha dado soporte para este lenguaje, lo cual me dice que pronto empezaremos a ver más y más proyectos usándolo. Veremos si hay guerra git-mercurial (git es otro sistema de control de versiones usado en el desarrollo del kernel de linux, entre otros), viven en paz o alguno de ellos muere. Git ha tomado mucha fuerza, sobretodo por el empuje en el desarrollo web y gracias a webs como gihub, pero eso es tema para otro post.
Es muy habitual que junto al código de tu proyecto tengas otras cosas igualmente importantes como scripts de compilación, deploys, documentación, notas, etc, que normalmente están también bajo control de versiones. Además, se suele tener un sistema de tracking de proyectos acompañado (o integrado) un wiki -que siempre termina manga por hombro-.
Pensé que estaría bien tener un wiki integrado en el repositorio, al igual que con el comando hgserve tienes un servidor web integrado que te permite ver la información de forma mucho más gráfica del repositorio, por qué no un wiki?. Haciendo una búsqueda no he encontrado nada para mercurial, sí para git.
Como hace pocos días me encontré juno, un mini-framework web muy coqueto y me puse manos a la obra para probarlo, así que he creado hg-wiki, una herramienta que permite tener un wiki integrado en tu repositorio mercurial. Es un wiki muy simple, pero tiene lo justo para tener la información ordenada y vistosa.
El proyecto está alojado en bitbucket, un servicio de alojamiento de proyectos mercurial. Si quieres echarlo un ojo y probarlo: hg-wiki
Un ejemplo de como queda la cosa, primer el texto, después la imagen del resultado:
= hg-wiki =
== introducción ==
//hg-wiki// es una pequeña aplicación web que implementa un wiki especialmente creado para sistemas distribuídos. Todas las páginas son almacenadas usando mercurial, de forma que se puede aprovechar todas las ventajas que aporta este sistema:
* permite trabajar //offline//
* se pueden mezclar, tagear las páginas de la wiki
== instalación ==
La instalación es simple, primero hay que instalar las siguientes dependencias:
* [[http://www.mercurial.org/|mercurial]]
* [[http://www.python.org/|python]]
* setup-tools, necesario para poder usar easy_install, la herramienta que permite instalar librerías de forma simple, igual que apt-get.
Lo siguiente es instalar las dependencias python:
* [[http://github.com/breily/juno/|juno]], un pequeño framework web, merece la pena echarle un vistazo
* creoleparser, permite convertir de wiki a html
Para instalar cualquiera de estos basta con ejecutar
{{{
easy_install juno
}}}
== funcionamiento ==
Si quieres empezar rápido ejecuta
{{{
python hg-wiki.py mywiki
}}}
Esto creará una carpeta llamada mywiki que no será otra cosa que un repositorio mercurial, por tanto se podrán ejecutar sobre él todos los comandos mercurial.
== créditos ==
autor: javi santana http://javisantana.com
gracias a los creadores de creoleparser, juno y github, de donde he ripeado miserablemente el css :)
El resultado:
(si encontrais familiar el estilo de la web, no es casualidad, el css lo he tomado del wiki de github, mis conocimientos web no llegan a tanto)
5.19.2009
La sostenibilidad y otras cosas
No, no voy a ponerme a escribir que tenemos que cuidar el medio ambiente y hacer que nuestro ciclo sea sostenible, eso ya lo sabemos gracias a los anuncios de vehículos, material informático, alimentos, etc. No digo que no sea importante, pero hoy voy a hablar a nivel empresarial.
El otro día me comentaba una persona, en la típica conversación de bar, donde todo es sencillo, que era un pelín tonto, que debería estar moviendo nuestro pequeño negocio por todos lados, creciendo todo lo que pudiese y vendiendo lo que no está escrito. Era una persona que se dedicaba a la venta, así que es lógico que me tratara de dar unos buenos consejos.
Sin embargo, en estos momentos en los que me recomiendan crecer y moverme pienso en uno de mis objetivos, la sostenibilidad. Sería fácil aprovechar el "boom" y tratar de vender, quizás contratar gente, tratar de buscar inversión privada y crecer como la espuma, pero no sería sostenible y habría que empezar a despedir personas, tal y como están haciendo todas las empresas que no lo pensaron durante las vacas gordas. Creo que lo explican muy muy bien la gente de LinkingPaths en esta entrevista. Merece escuchar la entrevista completa, la primera parte sobre su filosofía y la segunda un poco más técnica (java vs ruby sin mojarse :P, git y sus proyectos).
Por otro lado, también le comentaba, que a mi no me interesaba ahora meterme en fregaos que no me gustan, yo estoy feliz con mi software, desarrollando cosas que tienen utilidad y haciendo lo que me da la real gana en el tiempo que me sobra (o que robo). La fábula del pescador y el empresario lo explican muy bien. Mi felicidad en este momento es hacer lo que quiera dentro de unos límites y no quiero la felicidad para dentro de unos años. Creo que no soy el único: de consultor a director de TI, Ángel Medinilla (punto 2) son dos buenos ejemplos.
Ya que estamos puestos, me marcho a trabajar a Pamplona el mes que viene :)
El otro día me comentaba una persona, en la típica conversación de bar, donde todo es sencillo, que era un pelín tonto, que debería estar moviendo nuestro pequeño negocio por todos lados, creciendo todo lo que pudiese y vendiendo lo que no está escrito. Era una persona que se dedicaba a la venta, así que es lógico que me tratara de dar unos buenos consejos.
Sin embargo, en estos momentos en los que me recomiendan crecer y moverme pienso en uno de mis objetivos, la sostenibilidad. Sería fácil aprovechar el "boom" y tratar de vender, quizás contratar gente, tratar de buscar inversión privada y crecer como la espuma, pero no sería sostenible y habría que empezar a despedir personas, tal y como están haciendo todas las empresas que no lo pensaron durante las vacas gordas. Creo que lo explican muy muy bien la gente de LinkingPaths en esta entrevista. Merece escuchar la entrevista completa, la primera parte sobre su filosofía y la segunda un poco más técnica (java vs ruby sin mojarse :P, git y sus proyectos).
Por otro lado, también le comentaba, que a mi no me interesaba ahora meterme en fregaos que no me gustan, yo estoy feliz con mi software, desarrollando cosas que tienen utilidad y haciendo lo que me da la real gana en el tiempo que me sobra (o que robo). La fábula del pescador y el empresario lo explican muy bien. Mi felicidad en este momento es hacer lo que quiera dentro de unos límites y no quiero la felicidad para dentro de unos años. Creo que no soy el único: de consultor a director de TI, Ángel Medinilla (punto 2) son dos buenos ejemplos.
Ya que estamos puestos, me marcho a trabajar a Pamplona el mes que viene :)
5.07.2009
Como plancha un programador
Una persona normal, que no es del gremio metalúrgico-programador, para el noble arte del planchado de la ropa no piensa más que en coger la plancha, la tabla de planchar, la ropa y liarse a planchar y doblar.
Hoy he dicho a mi novia que planchaba yo en un intento de que no parezca que ella lo hace todo y hacerme creer por un instante que yo también participo en las labores domésticas (lo más lejos de la realidad). No tengo demasiada experiencia, así que me he planteado el problema como tantos otros:
Primer paso, preparación de herramientas y documentación
- preparación de tabla, la he tenido que nivelar para que no se moviese, es importante tener las herramientas a punto.
- enchufar plancha y comprobar los diferentes controles (temperatura y demás). He delegado (para que luego digan que los programadores no delegamos) en mi novia la tarea de llenarla con agua.
- He mirado en internet como doblar una camiseta de forma rápida para ahorrar tiempo. He encontrado como doblar camisetas de forma rápida con el estilo japonés.
Segundo paso, organizar el trabajo
- He analizado primero los riegos y he escogido lo más bloqueantes por orden de importancia: quemar una prenda y cansarme de planchar. Es fundamental no quemar una prenda, pero también lo es que me canse y deje las cosas sin planchar.
- Ordenar por prioridad las prendas que voy a planchar: primero he puesto una camiseta blanca sin mucho valor, por si quemo algo que no se pierda mucho. Después he ordenado la ropa dos criterios: el de "importancia que esté planchado" y por "interés necesario para plancharlo (aka dificultad)", por tanto lo primero camisas, segundo polos, tercero pantalones y después camisetas blancas (a excepción de la prueba con la primera).
- Planchar, pero marcando una deadline de tiempo de forma que cada prenda quedara lo mejor posible dentro de ese tiempo.
- Tiempo de I+D: Ya que tengo varias camisetas iguales he intentado alinearlas y plancharlas a la vez. Fracaso total, pero de eso se trata el I+D ¿no?
Último paso, preparación para producción
- Doblado de ropa, las camisas directamente a perchas y luego he apilado la ropa poniendo encima lo que más me interesa que se mantenga sin arrugas.
- Armario, esperar que la plancha se enfrie y recoger instrumental.
Es triste, pero así es como he pensado cada uno de los pasos para planchar.
Hoy he dicho a mi novia que planchaba yo en un intento de que no parezca que ella lo hace todo y hacerme creer por un instante que yo también participo en las labores domésticas (lo más lejos de la realidad). No tengo demasiada experiencia, así que me he planteado el problema como tantos otros:
Primer paso, preparación de herramientas y documentación
- preparación de tabla, la he tenido que nivelar para que no se moviese, es importante tener las herramientas a punto.
- enchufar plancha y comprobar los diferentes controles (temperatura y demás). He delegado (para que luego digan que los programadores no delegamos) en mi novia la tarea de llenarla con agua.
- He mirado en internet como doblar una camiseta de forma rápida para ahorrar tiempo. He encontrado como doblar camisetas de forma rápida con el estilo japonés.
Segundo paso, organizar el trabajo
- He analizado primero los riegos y he escogido lo más bloqueantes por orden de importancia: quemar una prenda y cansarme de planchar. Es fundamental no quemar una prenda, pero también lo es que me canse y deje las cosas sin planchar.
- Ordenar por prioridad las prendas que voy a planchar: primero he puesto una camiseta blanca sin mucho valor, por si quemo algo que no se pierda mucho. Después he ordenado la ropa dos criterios: el de "importancia que esté planchado" y por "interés necesario para plancharlo (aka dificultad)", por tanto lo primero camisas, segundo polos, tercero pantalones y después camisetas blancas (a excepción de la prueba con la primera).
- Planchar, pero marcando una deadline de tiempo de forma que cada prenda quedara lo mejor posible dentro de ese tiempo.
- Tiempo de I+D: Ya que tengo varias camisetas iguales he intentado alinearlas y plancharlas a la vez. Fracaso total, pero de eso se trata el I+D ¿no?
Último paso, preparación para producción
- Doblado de ropa, las camisas directamente a perchas y luego he apilado la ropa poniendo encima lo que más me interesa que se mantenga sin arrugas.
- Armario, esperar que la plancha se enfrie y recoger instrumental.
Es triste, pero así es como he pensado cada uno de los pasos para planchar.
Suscribirse a:
Entradas (Atom)