11.28.2010

mejor me quedo como estoy

Hace hoy 9 años me operaron de corazón. Era un problema congénito que en palabras textuales del médico "lo resolvía con una mano atada a la espalda" a pesar de que ya era un caso grave (de hecho mi parte derecha del corazón es más grande de lo normal).

Momentos antes de entrar a darme una sesión de rayos X un día antes de la operación, miré por la ventana del hospital y me pegó un "flasazo" de cordura: "y si mañana estiro las punteras en la operación?". Por suerte (*) estuve dentro del 99% de pacientes que salen vivos y coleando.

Sin embargo, ese momento se quedó bien fijado en mi cabeza y evolucionó a peor, tuve unos meses en los que pensé que aquello no podía haber ido tan bien como los médicos decían y que tal vez el parche que me pusieron se soltaría y moriría el día menos pensado.

Los meses que aquella idea peregrina duraron (el tiempo dio la razón a los médicos) han sido, con mucho, los meses más felices de mi vida.

Y este post es para leermelo cuando tenga que tomar alguna decisión importante y piense: "mejor me quedo como estoy".

(*) en realidad no fue suerte, fue gracias al trabajo de mucha gente durante años y posiblemente de muchos muertos con el mismo problema que yo.


11.21.2010

5 minutos

Cuando mi familia decidio que yo tenia que estudiar una carrera universitaria decidieron que yo debia a ir a una de esas residencias universitarias. No,
no de esas que estas pensando donde la juerga es asignatura troncal,
era mas bien de esas aburridas donde te semiobligan a hacer lo que realmente debes hacer.

Una de las condiciones para entrar y permanecer en ella era hacer 5 minutos de reflexion en la capilla. Visto asi daba algo mas que miedo,
la palabra secta se podia leer en mi cara cuando me lo comentarom, pero bueno,
el resto de cosas estaba bien, asi que tragamos. Tampoco me llegaba el aire al cuello, no habia muchos mas sitios donde las novatadas estuviesen prohibidas.

anyos despues, habiendo reflexionado durante todos los dias durante 3 anyos, me doy cuenta que aqeullos minutos en los que parabas, mientras contabas los segundos para irte, eran un ejercicio realmente bueno. En esos minutos podia organizar el dia, pensar sobre las metedura de pata y en general sobre cosas que ahora no tengo tiempo de pararme a pensar.

Ahora es cuando deberia darme la vuelta y dar las gracias por aquello,tal vez lo haga.

pd: escrito desde el kindle,siento las tildes y enyes.

11.13.2010

El camino corto

Cuando comencé a crear agroguía, hace ya casi 5 años, tuve la suerte de tener claro lo que quería resolver, y digo suerte porque la mayoría de proyectos de tecnología que veo a mi alrededor no tienen casi nunca claro a donde quieren llegar (esto es tema para otro post). El primer paso para resolver un problema es tener claro el problema. Dicho esto desarrollé una aplicación que resolvía un solo problema, sin ningún tipo de funcionalidad añadida.

Esto tiene sus cosas buenas y sus cosas malas. Si desarrollas un producto y lo vendes vas a tener que escuchar muchas veces "el software de la competencia hace X e Y, el tuyo no", te van a aconsejar miles de veces, de personas que saben y que no saben que deberías hacer tal o cual funcionalidad que será un éxito en el número de ventas. Normalmente la gente te agradece mucho más el hecho de que mantengas la aplicación simple a lo que protesta por no tener tal o cual cosa, que, aunque lo veas como fundamental para tu negocio, normalmente se puede pasar sin ello si el producto te resuelve tu problema principal. Somos así de tontos.

Sin embargo pasa el tiempo y ves como mucha gente te solicita cosas muy concretas que te encajan. Pero la cuestión aquí no es que encajen porque un señor muy listo haya sacado su bola de cristal y haya pensando cierta funcionalidad que los usuarios necesitarán, ni encajan porque tenga claro que voy a vender mucho más por ello, si no que lo hace porque en parte me siento en deuda con la información que la gente me está dando (esta es otra cosa que cuando cuento a la gente cercana no entienden "esto es un negocio, javi").

Ves que encaja y la desarrollas, pero entonces piensas en los usuarios de tu producto y te dices: "no voy a joder a esta gente ahora que ya se ha acostumbrado a usar el producto". Así que hace un tiempo decidí dos cosas:

- nunca cambiaría el "camino corto", esto es, la forma de usar la aplicación para resolver el problema original.
- nunca añadiría funcionalidad que entorpeciese la resolución del problema original, esta siempre debe ser "opcional".

En resumen, de las releases de agroguía nunca se ha tocado el planteamiento original de empezar a funcionar dando a un solo botón, ni como se interpretan los datos, eso sí, se ha añadido funcionalidad, pero siempre opcional (de hecho un tiempo la vendimos aparte), el cliente si se actualizaba iba a seguir funcionando exactamente igual pero si quería podía usar las características añadidas. También tengo que destacar que las releases de agroguía no suelen ser para añadir funcionalidad, si no para mejorar la que hay.

Escribo este post ahora como "autocastigo". La última release que tenía planeada de agroguía rompía una de esas reglas, no de forma muy importante en mi opinión, pero que tras las primeras pruebas con gente real resultó no ser la mejor idea.

Son cosas como estas las que te recuerdan lo importante que es seguir una filosofía.

10.31.2010

scrapper multiproceso en python

Nota inicial: Si no te gusta python puede que este post te haga cambiar de opinión :)

Una de las mejoras de Python 2.6 (en estos momentos vamos por la 2.7, que será la última de la rama 2.x) es el módulo multiprocessing. En pocas palabras viene a ser un módulo para trabajar con procesos de la misma forma que se hace con threads, de hecho en un subconjunto de la funcionalidad puedes cambiar threads por procesos cambiando un solo import.

Sin embargo el módulo multiprocessing añade cosas muy interesantes como la posibilidad de trabajar con pool de procesos. Veamos un ejemplo.

Imaginemos que tenemos que bajar una serie de ficheros pdf para posteriormente extraer información de ellos. Una primera aproximación sería esta:



import urllib
import urllib2

reg_nos = [16738, 17288, 18162, 18776, 18868, 19116, 19223, 19505];
pdf_url = 'http://www.mapa.es/agricultura/pags/fitos/registro/sustancias/pdf/%s.pdf'

def fetch_url(url, params={}):
return urllib2.urlopen(url).read()

def save_url_as_file(url, filename):
open(filename,'wb').write(fetch_url(url))

def download_pdf(reg_no):
f = '%d.pdf' % reg_no
save_url_as_file(pdf_url % reg_no, f)
print "\t- %s downloaded" % f

# tests
def single(regs):
for u in regs:
download_pdf(u)

single(reg_nos)

(puedes verlo mejor con sintáxis coloreada en github)

Para 4 míseros ficheros no merece la pena hacer más, pero imaginemos que queremos bajarnos miles y que además lo tenemos que hacer periódicamente, el tiempo en bajarse todos esos ficheros es alto. Lo primero que se nos ocurre es usar concurrencia: lanzando una serie de hilos/procesos que vayan bajando los ficheros aceleraría sensiblemente el proceso (de hecho así lo hacen los navegadores cuando se bajan los ficheros que referencia el HTML).

En python esto traducido a código ocupa mucho menos que explicarlo:


def download_multi(regs, nprocesses=4):
pool = Pool(processes=nprocesses)
pool.map_async(download_pdf, regs).get()


Usando multiprocessing.Pool python se encarga de lanzar los procesos y preparar una cola para enviarle a la función que especificamos en el primer parámetro.

Este es un uso de multiprocessing, pero tiene otros muchos muy interesantes.

Podéis ver todo el código en github y ejecutar el pequeño benchmark:

q6:smll javi$ python fetch.py
- 16738.pdf downloaded
- 17288.pdf downloaded
- 18162.pdf downloaded
- 18776.pdf downloaded
- 18868.pdf downloaded
- 19116.pdf downloaded
- 19223.pdf downloaded
- 19505.pdf downloaded
2.30190205574
- 18776.pdf downloaded
- 17288.pdf downloaded
- 18162.pdf downloaded
- 16738.pdf downloaded
- 19116.pdf downloaded
- 18868.pdf downloaded
- 19505.pdf downloaded
- 19223.pdf downloaded
0.807252883911

Un incremento un poco menor de 4X, el número de procesos que lanzo en el pool.

Últimamente uso este módulo para muchísimas tareas ya que el uso es prácticamente directo si la aplicación está bien modularizada y permite aprovechar la potencia de las máquinas actuales (en mi caso un dual core).

Bonus Track - threads

Con threads también es posible hacerlo, pero lamentablemente el módulo threading no tiene la funcionalidad Pool, así que debemos emularla.

Antes de pasar a la implementeación está bien decir que desde hace cosa de dos años hasta ahora se ha criticado mucho el modelo multithread de python debido a que existe una cosa llamada GIL (Global Interpreter Lock) que hace que solo pueda estar ejecutándose un hilo al mismo tiempo en el intérprete python. A pesar de ser hilos nativos hay un lock que evita que dos hilos se puedan ejecutar al mismo tiempo. Si quieres saber un poco más sobre el GIL hay una presentación excelente de maestro Dave Beazley.

Es para llevarse las manos a la cabeza, pero esto no quiere decir que el desarrollo con hilos en python esté "prohibido", símplemente hay que saber para qué se puede o no usar. En este caso el uso de threads, a pesar del Lock es muy interesante, ya que al ser tareas fundamentalmente de Entrada/Salida no hay problemas de bloqueo entre hilos (la explicación más en detalle en la presentación que he citado antes).

Sin más, usando Queue (otro módulo python mágico), una cola FIFO sincronizada la tarea es más o menos simple:


def threaded(regs, nthreads=4):
# ripped from http://www.dabeaz.com/generators/Generators.pdf
def consumer(q):
while True:
item = q.get()
if not item: break
download_pdf(item)

in_q = Queue.Queue()

# start threads
ths = [threading.Thread(target=consumer,args=(in_q,))
for th in xrange(nthreads)]
for x in ths: x.start()

# put files to download
for i in regs:
in_q.put(i)

# put end guards
for th in xrange(nthreads): in_q.put(None)

# wait to finish
for x in ths: x.join()

10.24.2010

El desarrollo por el desarrollo

El otro día estaba leyendo la realmente buena entrevista al creador de C++, Bjarne Stroustrup. No es el tema de este post, pero me ha parecido una entrevista de las que merece la pena repasar de vez en cuando, igual que el famoso discurso de Steve Jobs.

Creo que no podría estar más de acuerdo con lo que dice este hombre y suscribiría cada una de las frases, pero hay una que últimamente me da que pensar. En el último párrafo de la entrevista:

Know some non-computer field of study well — math, biology, history, optics, whatever. Learn to communicate effectively in speech and in writing. Spend an unreasonable amount of time on some difficult topic to really master it. Try to do something that might make a difference in the world.


Y es que en mi últimamente-más-activa faceta de comercial me he dado cuenta como hablando con gente de otros ámbitos, en concreto del agrícola, tienen una serie de problemas que como programador de corazón que soy pienso: "Si este señor supiese programar un mínimo haría maravillas".

Me considero un privilegiado por tener conocimientos de un área muy diferente al de la programación y creo que es fundamental que el desarrollador tenga esos conocimientos. No pasa un día sin que vea a un desarrollador trabajando en cosas que no van a resolver ningún problema y casi siempre es porque no tienen la visión de la persona que tiene ese problema (o directamente porque no hay problema :). Además NO creo demasiado en el consultor que va al cliente, éste le explica su problema y le surge la solución mágica para su problema, siempre he creído que la solución correcta surge del verdadero entendimiento de la materia y eso solo pasa cuando estás a pie del cañón.

Además, no creo que haya cosa más reconfortante para un desarrollador es ver como algo que ha creado él se use para solucionar un problema.



9.21.2010

empezando a correr

Hace casi 4 meses mi fuerza de voluntad me retó y decidí empezar a hacer algo de deporte, no mucho, los excesos son malísimos, ya sabes. Decidí entonces empezar a correr, por suerte vivo en un pueblo y me permite salir fácilmente. Las razones que me impulsaron fueron varias:

- atrofiamiento absoluto. Años de estar sentado pasan factura y cuando al entrar y salir del coche haces el mismo sonido que un tío de 80 tacos algo en tu interior te dice que la cosa no está bien. Además estoy operado de corazón y quizás tenga que cuidar un poco estás cosas.

- pérdida de peso. Viene al hilo de lo anterior, si no te mueves y no cuidas bien lo que comes engordas (las matemáticas aquí funcionan muy bien :)

- tener una forma de distraerme: Últimamente he pasado demasiadas horas delante del monitor y no solo afecta físicamente. Siempre he escuchado que hacer deporte es una forma de desconectar muy buena.

- tenía un festejo familiar y tenía que meterme el traje de hace unos años. Esta no es la importante, pero si eres más agarrao que un chotis no es agradable comprarte un traje nuevo :).

Si estás pensando en empezar a hacer deporte te dejo algunos consejos que a mi me han ayudado:

- Ten cuidado, empieza poco a poco. Al comienzo de empezar a correr creo que me han dolido todas las articulaciones. Yo seguí, parcialmente el couch to 5k, no sé si será bueno o no, pero por lo menos propone un plan a seguir y parece razonable en cuanto a metas.
- Usa un buen calzado. De ir con unas zapatillas normales a unas en condiciones no hay color. Es de perogrullo, pero yo tardé en darme cuenta.
- Si eres un friki te puede amenizar el uso de alguna aplicación GPS que haga tracking de lo que haces (yo uso handy runner para android), usar un pulsómetro o cualquier otro elemento que te pueda dar números que analizar y comparar.
- Márcate alguna meta, por ejemplo correr todos los días la misma distancia o incrementar la distancia en X metros todos los días.

Después de 4 meses puedo hacer un análisis de los pro/cons:

- He conseguido que sea un hábito, me hace sentir mejor tanto física como mentalmente. Yo era de los que pensaba que la gente que salía a correr estaba loca, ahora les entiendo.
- Cuando empecé era imposible correr más de 1 minuto seguido y cuando llevaba 3km de camino estaba para el arrastre. Ahora puedo correr 7km a menos de 6 minutos por kilómetro sin problema, esto es con pulsaciones dentro de un margen razonable y sin sensación subjetiva de estar destrozado.
- Resulta que mucha gente que está a mi alrededor corre (y no lo sabía) y tengo un tema de conversación, además de que puedes salir juntos a correr.
- A medida que va pasando el tiempo ves como mejora tu forma, aunque es un proceso lento y a veces piensas que no está funcionando. De hecho durante los dos primeros meses pensaba: "cómo es posible que nadie diga que esto es sano"
- Entre las cosas malas han estado los momentos en los que me pasaba un poco y me dolían todas las articulaciones, pies, espalda... a menudo no desconecto y voy pensando cosas del trabajo mientras corro.

En resumen, es una meta no muy complicada de cumplir (no te quita más que una hora el día que sales a correr), que te hace sentir mejor y que para gente con una vida muy sedentaria, como es la de un programador, viene de perlas.

Si tienes algún consejo será bien recibido :) y si quieres quedar para echar unas carreras también :P.

8.26.2010

Oferta de trabajo made in spain

No sé si es una cuestión solo de las empresas Españolas, no sé si es que en España las ofertas de trabajo sirven para más bien poco o qué, pero por lo general son un despropósito, llenas de sin sentidos,etc. Voy a dar mi punto de vista sobre como debería una empresa poner una oferta de trabajo si realmente quiere encontrar alguien de calidad (a partir de este punto la mitad de las empresas españolas habrán dejando de leer) o si símplemente no quieres hacer el ridículo:

- Nunca nunca dejes redactar una oferta técnica a una persona de RRHH. Por lo general no saben nada de tecnología y tienden a poner miles de siglas, muchas veces no tienen relación y dejan al descubierto que no sabes ni lo que haces.

- No digas que eres una "empresa lider del sector". Si lo eres ya lo sabemos y si no lo eres también así que ahorratelo. No te preocupes, alguien de calidad va a mirar qué hace tu empresa antes de ir, así que pule el resto de la oferta para que se interesen.

- No me digas que es una empresa jóven, dinámica e innovadora. Si lo eres demuestralo, ahora hay herramientas como blogs, twitter, etc, donde se ve si eres o no eres. Tampoco montes un blog, una página de facebook y un twitter para ser molón porque se ve a la legua si eres más falso que Judas. Qué hay de malo en poner: "somos una empresa tradicional y hacemos lo de toda la vida, pero lo hacemos bien y tenemos los pies en la tierra". Una vez fui a una entrevista y pregunté: "y qué tal es el ambiente de trabajo, la gente se lleva bien", el entrevistador me respondió: "es una relación correcta entre compañeros". Sí, aquella empresa era jóven, dinámica e innovadora.

- Ahorrate todo lo de, buscamos "persona responsable, autónoma, eficiente, analítica, con gran capacidad de trabajo en equipo, entusiasta, proactiva y blablbalbla"

- Se claro en lo que pides. Si quieres un programador que haga de todo un poco, pon que quieres un programador ninja, hay programadores que son así, modo rambo, llegan y resuelven. Si quieres alguien que sepa de una tecnología concreta, ponlo así, huye del "bueno, ya que estoy pongo perl, ruby, asm z80, asm 8087, JVM, dalvik, vim, emacs, turboC++, cobol, AS400 por si cuela". Claro, para eso debes saber lo que quieres. Deja claras las responsabilidades.

- Dí claramente lo que ofrece tu empresa y cómo se gana la vida, de donde saca el dinero. Si lo sacas de subvenciones, es triste lo sabemos, pero ponlo, si es capital riesgo... o incluso si de verdad ganas dinero con lo que haces (no conozco empresas de software en España con este perfil)

- Si sabes, pon cual es el valor añadido que el empleado dará a la empresa. Si no aporto valor añadido, esto es, no se gana dinero conmigo, tarde o temprano terminarás por encargarme trabajo sin sentido, yo me cansaré y me iré. Habremos perdido tiempo y dinero los dos, así que piensalo bien. Deja ver además lo que puede aprender el empleado en tu empresa.

- Parece una obviedad: deja claro dónde es el trabajo, qué tipo de horario, si se puede trabajar en remoto, rango salarial, y en general toda la lógistica. Somos mayorcitos como para andar perdiendo el tiempo.

- Usa algo diferente, por ejemplo, dropbox hace cosas como esta y en algunas ofertas suyas he visto como mandan resolver un problema de programación que más o menos cualquier programador con cierta experiencia sabe resolver. Con esto demuestras que sabes (para poner un problema hay que conocer bien la materia) y sabes que el que envía el CV está realmente interesado y algo de su forma de trabajo. Pide por ejemplo su cuenta en github, trabajos anteriores, o no pidas el currículum (leer el footer de esta oferta de trabajo de linkingpaths)

En resumen, sé claro, sincero y si no tienes ni idea intenta que no se note mucho.

7.28.2010

El soporte y atención al usuario

Si hay una cosa que fideliza, que agrada al consumidor es la buena atención al cliente. Aunque tu producto no sea el mejor, si tienes una buena atención terminas enamorando. He escuchado mil veces lo típico de "fui a XXXXXX, no era de lo mejor, pero me han tratado estupendamente" o "he comprado XXXXX se me estropeó, pero en 1 día me lo han enviado reparado".

Y si es tan fácil tener al una persona contenta, por qué las operadoras, por poner un ejemplo, son el claro ejemplo de la mala atención al cliente?. Que tire la primera piedra el que nunca se haya quejado de su ADSL, su factura de móvil que han tardado lustros en solucionar. La respuesta es que NO es tan fácil.

Para tener una buena atención al cliente hay que tener gente que sepa darla, así de claro, así de fácil y así de difícil a su vez. Por un lado el cliente debe tener claro donde acudir, debe haber alguien que le atienda (y NO acepto una máquina como alguien), que sepa escucharle y que además sepa que hacer. Esto es, alguien que:

- sepa de lo que está hablando, no una persona que sigue un guión de preguntas,
- que sepa a quien acudir en caso de tal o cual problema
- que sepa resolver los principales problemas él solito,
- que se encargue de ese problema, tanto de estar pendiente del cliente como de que ese problema llegue a quien tiene que llegar para que se resuelva para que en la medida de lo posible no vuelva a pasar. A veces aunque no te resuelvan el problema, si ves que están pendientes de él el cabreo ese que te envenena se va. Un simple SMS con "Hola Javi, estamos trabajando en tu problema con la conexión ADSL. Te llamamos cuando sepamos algo. Fdo: Perico".

Pero no, tener a gente formada y preparada exige tiempo y dinero, y es mucho más fácil ir al país más desfavorecido que hable tu idioma y poner a los que menos cobren a trabajar sin ningún tipo de formación, sin saber de lo que hablan.

La próxima vez que vayas a comprar algo, no solo pienses en lo que compres, piensa en qué hay detrás de ese coste.

Y por último, hay una cosa en lo que creo que muchas empresas deberían espabilar y es en ser transparentes, no solo con qué hacen y cómo (hasta cierto punto) si no como tratan al cliente con sus problemas.

7.11.2010

testing y deploy con python

La pasada semana hicimos una ronda de lightning talks con el objectivo de introducir a los compañeros de la empresa en tecnologías que no habían usado hasta ahora. Además sirvieron para hacer un poco de team building y romper un poco el hielo, cosa importante en un equipo _muy_ distribuído. Lo empecé a ver a la gente de aspgems y me pareció interesante.

Por mi parte hice un par de charlas que puede que resulten interesantes:

- Introducción al testing con python y django (pdf). Repasa conceptos muy básicos del testing y trata de explicar como testear una aplicación en django. Es muy muy básico, pero puede servir de ayuda si no estás familiarizado.

- Introducción a fabric (pdf). Fabric es una herramienta para facilitar la automatización de los "deploys". Es similar a capistrano en ruby o ant (salvando las distancias) en java.

Como curiosidad las transparencias están creadas con una aplicación llamada landslide, que transforma sintáxis markdown a una presentación HTML5 o PDF. Muy simple de usar y fácilmente "maqueable".

Me gusta mucho dar charlas de este tipo -a pesar de mi nula capcidad comunicativa- y creo que dice mucho el que un equipo de desarrollo monte charlas de este tipo para estar al día. A ver si mis compañeros se animan a subir las suyas.

7.09.2010

Una semana como gestor de proyecto

Primero de todo decir que no soy ni jefe de proyecto ni nada que se le acerque. La palabra jefe, gestor, responsable se usa con demasiada soltura, ser un gestor competente es muy difícil y requiere mucho tiempo, exactamente igual que ser bueno en otros ámbitos más un toque de sensibilidad con el prójimo.

En España los títulos de gestión (jefe de proyecto, jefe de sección, gestor de blabla) se usan como complemento a los absurdos salarios, "fulanito, vas a ser responsable jefe del proyecto amoeba-ultra-2.0, vas a llevar toda la gestión, sabemos que podemos confiar en ti, blablabla...", pero realmente no responden a una experiencia por parte de la persona que está en ese puesto, en la mayoría de los casos (*).

Nuestro scrum manager de cabecera en la empresa estaba de vacaciones, así que decidí tratar de hacer un sprint como mandan los canones de scrum, bueno, realmente como yo lo aprendí de @jmnavarro en mi estancia en unkasoft, con su reunión con cliente, elección de tareas del backlog, estimación, su avance, su burndown chart y finalmente la retrospectiva.

Decir que el desarrollo fue bien, se terminó en plazo, con calidad más que suficiente, pero eso no le interesa a nadie, aquí lo interesante es ver en donde metí la pata hasta el fondo, ¿no?:

- Puñetazos encima de la mesa: He tomado elecciones en base a mi experiencia por encima de las decisiones de mis compañeros, lo cual puede estar bien, pero no deja de ser un error. No dejar elegir su camino a tus compañeros es un grave error, aunque sepas sí o sí que hay formas mejores de hacer las cosas. Si la idea es formar un equipo de desarrollo a un buen nivel todo el mundo debe aprender y la mejor forma de aprender es afrontando problemas tú solito.

- Meterme en las tareas de mis compañeros: En un momento puntual decidí terminar a machete una tarea de un compañero (además de gestor, programo, ¿te suena?) ya que estaba bloqueando el desarrollo. Desde el punto de vista del proyecto es lógico hacerlo, pero no me paré a pensar que mi compañero se podría sentir ofendido, dolido por haber terminado algo en lo que estaba trabajando. Mil veces prefiero llegar tarde un sprint a tener un roce absurdo.

- Notificar los errores: no hay cosa más difícil que decir a alguien que la ha mangado. Y no quiero decir hacerlo sin que se sienta ofendido.

En resumen, si no tienes un poco de tacto, mano izquieda, inteligencia emocional, como lo quieras llamar, es mejor que te quedes como un buen técnico.

No hay nada mejor que las curas de humildad que la vida te da de gratis y que la memoria te recuerde los malos ratos que hiciste pasar a algún que otro gestor de forma innecesaria, mis disculpas atradas.





(*) En mi corta-pero-intensa vida laboral solo recuerdo a un par de personas haber estado a la altura de un puesto así, y cada día que pasa me acuerdo más de alguno de ellos :)

6.28.2010

Necesitamos buenos técnicos

Para empezar, una frase:

Más hacer y menos hablar


es un ejemplo que define muy bien lo que está pasando ahora mismo. Nos hemos hartado de montar castillos sobre las nubes y cuando ya no podíamos llegar más algo nos la hemos pegado.

Estamos en un punto en el que una persona hace 1 año sin apenas saber sumar podía comprar una vivienda y sacarla un 30% sin despeinarse o que nos vendan la leche por que tiene calcio "de leche" -esta misma noche he visto un anuncio de pascual en TV, se habrán parado a verlo, alejandose unos metros de la pantalla, los creadores?-

Estoy hasta las narices de humo, quiero que cuando vaya al taller con mi coche venga un técnico y que sin pensar sepa lo que es ese ruido que apenas se escucha, y me da igual que el taller cumpla la norma de turno, quiero que cuando vaya al médico éste tenga los huevos pelados de tratar con pacientes, que sepa que me pasa o como mínimo que tenga recursos para saber qué hacer, quiero que cuando llame al banco a preguntar no me insten a hablar con "fulanito de tal" que es el que "lleva estas cosas".

Quiero que haya gente que sepa, gente preparada, que sepa hacer, que me solucione, que me aporte.

Pero claro, para hacer todo eso necesitamos muchos años de preparación -sí, de esas cosas que nunca valen para nada en la universidad-, mucha experiencia, dedicación, gusto por hacer las cosas bien... y una recompensa (social, económica, del tipo que sea), pero para que me voy yo a esforzar si puedo pasar de #ponga aquí su puesto vendehumista de moda# una temporada y eso de escornarse no está bien visto -menudo pringao que diría aquel-

Cada vez que veo a alguien haciendo bien su trabajo me resulta imposible no soltarle un "da gusto pagar cuando la gente hace las cosas bien"

6.24.2010

Razones para NO usar un IDE

Un IDE, con permiso de la definición en la wikipedia, no deja de ser un editor de texto y una serie de utilidades que facilitan el trabajo de desarrollo, tales como configuración de los parámetros del compilador, debugger, ayuda en la sintáxis, documentación del lenguaje, etc.

Hace ya cosa de un par de años que no uso un IDE, bueno, uso vim como "IDE" y las razones son las siguientes:

- Me obliga normalmente a usar el editor que el IDE quiere. Con vim uso siempre, para editar lo que edite, las mismas combinaciones de teclas, misma configuración y en todas las máquinas en las que trabajo solo con llevarme el .vimrc

- Tiende a añadir complejidad. Los makefiles que se generan, los wizards de código, etc tienden a añadir mucho código que realmente no sabes como funciona y que es difícil de modificar.

- La ayuda con la sintáxis o el autocomplete. Aunque pueda parecer una maravilla me parece uno de los inventos más perversos. Usé eclipse durante más de un año y medio con java y un día intenté hacer un pequeño programa en el editor de texto y compilarlo con javac... fue imposible, no recordaba nada, cual eran los imports que debía hacer (eclipse lo hace como mágia), nombres de clases, excepciones que debía capturar...

- Trabajo en máquinas remotas. Muchas veces tienes que editar ficheros o incluso programar en una máquina que solo tienes acceso ssh. Usando vim es transparente el estar en tu máquina o en otra por ssh.

- Si no lo usas aprendes a manejar las cosas que pasan por debajo. Cuántos habrá que no sepan crear un .jar sin eclipse, como se especifica a gcc una librería o el path donde encontrar las cabeceras... sin contar aquellos que se sorprenden cuando puedes hacer todas esas cosas que hace el IDE pero sin el IDE. Si sabes como crear un .jar puedes estar tranquilo que con el IDE sabrás hacerlo igual de bien.


Sé que todo esto que digo suena a programador masoca, pero si de verdad quieres conocer lo que estás haciendo con detalle debes conocer lo que hay por debajo.

Bien es cierto que hay cosas muy útiles, por ejemplo la documentación siempre a mano, pero qué tiene eso que no tenga un man o un pydoc en la consola, una búsqueda en todo el proyecto, aunque no la cambio un ack-grep... lo único para lo que no he encontrado algo tan potente como eclipse es para las refactorizaciones... pero los buenos programadores nunca nos confundimos :P

6.09.2010

Testing con datetime en python

Este es un pequeño "truco" para testear métodos o funciones que usen datetime.now. Se podrían usar trucos aprovechando que python es un lenguaje muy dinámico, pero siempre que se pueda hacer explícito y simple, para qué complicarnos?


def method(param1, param2, now=None):
now = now or datetime.now()
# do something with now
pass


En el uso normal la llamaremos normalmente, pero en el test podremos pasarle un datetime concreto para testear.

6.06.2010

Usar git en proyectos que usan subversion

Si has dado click en este enlace es que sabes que svn ya no mola, ahora lo que "lo peta" es git (o si eres un poco alternativo mercurial). Dejando a un lado lo de seguir las modas, seguramente conozcas más de un proyecto que trabaja con subversion y es difícil cambiar la tendencia, sobretodo por la barrera que supone pasar del modelo de funcionamiento de subversion a git.

Este post no pretende ser una guía de comandos a ejecutar para usar acceder a un repositorio subversion, para eso ya hay tropecientos manuales, voy tratar de explicar qué ventajas y problemas (alguna solución también) que he encontrado trabajando de esta forma y sobretodo pretende ser una pequeña guía para aquellos que están pensando usar git.

Ventajas:

- Puedes hacer los commits intermedios que quieras. Para los somos "amigos del commit" es muy útil, porque puedes hacer commit aunque el código no esté funcionando. En subversion para evitar esto tenías que hacer una rama y trabajar en ella hasta que terminases. En este caso tienes todo el repositorio en local y símplemente esos commits se acumulan a tu repositorio local hasta que tú decidas enviarlos al servidor.

- Trabajo en ramas: en Git trabajar con ramas es mucho más ágil que en subversion, de modo que puedes trabjar en ramas locales de trabajo para ciertas tareas, pruebas.

- Rapidez: creas ramas, cambias de rama, haces commit, compruebas el log o diff de un fichero. Aún recuerdo cuando tortoise se me quedaba pillado esperando el log de un fichero... aunque las dos anteriores son interesantes, en subversion tenían solución, esta no la tiene por el modelo cliente servidor.

- Puedes usar otras utilidades de git: stash, cherry-pick, rebases, etc.

Desventajas:

- No hay tortoise, particularmente uso gitx y/o gitg que permiten sobretodo visualizar cómodamente diffs y la historia del repo. Edito: Carlos me comenta que sí existe un tortoisegit, aunque no lo he probado.

- Los rebases del demonio. Cuando quieres actualizarte (lo que sería un svn update) debes hacer un git svn rebase. Esto, en pocas palabras, coge los commits que has hecho en local, los deshace, se baja las nuevas actualizaciones que haya en el servidor y aplica esos commits de nuevo. Personalmente odio el rebase (me recuerda a los peores momentos de regreso al futuro), así que una forma de trabajar sería crear una rama, actualizar la rama que apunte al servidor subversion (a trunk posiblemente) y después mezclar (en git, claro) la rama de trabajo.

- No puedes actualizar si tienes algo modificado en local. Con el subversion tradicional te hacía merge de lo que venía del repo con los cambios en local. Tienes dos opciones, o hacer commit o usar stash (almacena de forma temporal esos cambios, una especie de rama rápida)

- Tienes que aprender git además de subversion. A git cuesta acostumbrarse, pero luego es más versatil y rápido, es una cuestión de inversión.

Siempre puedes empezar a probar, como siempre digo a mis pobres pupilos: "con un repositorio puedes cagarla todo lo que quieras, siempre puedes volver para atrás"

5.30.2010

Una historia de ventanas rotas

Sí, otra historia, y esta es de las que no tiene final feliz.

Las ventanas rotas en programación se pueden explicar con una variación del sabio refrán español:

No dejes para mañana lo que puedes hacer pasado mañana


Estás tirando unas líneas de código, ves que hay un problema, lo das unas vueltas, te pones a otra cosa y cuando te das cuenta el problema no está. Lo siguiente es un:

De puta madre -piensas- marrón que me quito de encima, soy un hacha, resuelvo sin querer



Total, que sabes que has dejado un error y además estás programado por coincidencia.

Pero los programadores somos muy orgullosos, así que buscamos una solución rápida:

- seguro que era una gilipollez
- la informática es así, a veces a los ordenadores les da por hacer "cosas raras"
- habrá sido "el driver"
- seguro que ha sido un pete de la base de datos
- le ha pasado a Jose el comercial, no tiene ni puta idea y lo habrá jodido
- eso ha sido porque estoy en debug
- eso ha sido porque estoy en release

Total, pasa el tiempo y un día estás programando algo que nada tiene que ver y el pete vuelve. Tú sabes que aquello volvería y en el peor momento aparece para joderte.

Bien, como los accidentes de tráfico nunca piensas que algo así te va a pasar a ti, pero siempre llega el día. Hace dos días encontré una ventana rota en agroguía (nuestro sistema de guiado GPS para la agricultura) de hace 4 años y medio.

Un error al teclear ha generado cáncer que se ha expandido por toda la aplicación. En el momento de convertir las coordenadas del GPS a cartesianas cometí el error de poner la coordenada Y donde debería estar la X y viceversa. Seguramente fue de lo primero que programé y está al principio de toda la cadena de la aplicación, ya que las posiciones del GPS son la fuente de datos.

En principio es un flip de los ejes, no debería causar problema pero eso ha causado que, sin saber porque, cambié el render del eje X (por tanto todo el render está "flipeado" en el eje X), toda la exportación está cambiada de lado, tuve que hacer ñapas para que el render cuadrase con la realidad... etc.

Ahora he estado integrando un formato de fichero GIS para darle una vuelta más de tuerca al guiado GPS de bajo coste y he tenido que arrastrar todo el fallo para que la cosa funcionase.

Casos como este y otros puedes encontrar en el libro The Pragmatic Programmer, indispensable para cualquier programador.

5.02.2010

Una historia de subvenciones

Hoy toca hablar de subvenciones y voy a hablar muy muy mal de ellas a pesar de que mi salario de estos últimos años atrás ha dependido casi en exclusiva de subvenciones.

Pongamos una empresa española, gente trabajadora, alto nivel técnico, buen planteamiento... y ahora pongamos que existen una cosa que se llama subvenciones que hace que a los que comandan esa empresa vean un buen punto de ayuda:

"Es una de esas ayudas de i-mas-de, nos puede ayudar en el proyecto tal y contratar a cual".

A priori está muy bien, se pone a trabajar una persona en presentar la documentación, trabajar en ella, etc (lógicamente esa persona también cobra por su trabajo, faltaría más). Se consigue a subvención y se contratra a 3 personas más y, dado que se tiene mas gente, el proyecto se hace más ambicioso. El director comercial se coge de renting un Audi TT ya que es necesario ir bien representado:

"somos una empresa seria", afirma el director tajantemente a uno de sus empleados, esos que están todo el día en el ordenador.

Se va acercando el final del dinero, y como siempre pasa, al proyecto está casi listo (el 80%, por poner una cifra).

"No pasa nada, se puede buscar otro proyecto de i+d"

Y vuelta a empezar, pero aún peor, porque ahora tenemos que pagar 3 sueldos más, los coches de los comerciales y alguna que otra cosa más que se contrató en la bonanza. Por no hablar de lo minada que está la moral por no ver que el trabajo fructifica y que todo lo que haces es trabajo tirado a la basura.

Y este es el pan de cada día de muchas PYMES tecnológicas en España.

Cada vez que hablo con alguien que ha montado o está montando su empresa, que es productivo, no pasa sin que comente el daño que hacen, y no solo del lado que yo he comentado.

No estoy a favor de que desaparezcan, pero sí de que se apliquen razonablemente y siempre tratando de apoyar una mejora, no como una vía de mantener una empresa.

En voota hay una propuesta muy interesante sobre este tema.

4.29.2010

desafío abredatos: cortesabiertas.org



Sí, participé junto a Félix López, Edu Lanchares y Antonio Garrote tratando de hacer una aplicación para mostrar el pueblo castellano leonés de que se habla en esas flamantes cortes.

Lo que pudimos hacer en 48h para el concurso abredatos: http://cortesabiertas.org/

y la explicación técnica detallada en en blog del sr garrote.

3.28.2010

Osadía

No hay vez que no vea un documental de construcciones u obras de ingeniería que no sienta una profunda envidia. Y siento envidia porque me doy cuenta que comparado con las empresas de software, ellos tienen claras muchas cosas que nosotros no tenemos.

Entre estas cosas hay una cosa que casi me hace llorar, y es que se tiene en cuenta al experto, si tienen que poner una plancha de un puente hay un -señor- ingeniero que es el que tiene los huevos pelados de pasarlas putas poniendo puentes, hay especialistas por cada una de las partes; especialista de hormigón, de neumática... y no se mueve ni un santo dedo si no hay un "ok" de esos expertos.

Otra de las cosas que me gusta es que saben hasta donde pueden llegar con más o menos deriva en el tiempo. Nadie pondría a 3 ingenieros a hacer un viaducto de 200m de altura y 500metros de largo y mucho menos les diría, esto tiene que salir sí o sí.

Sin embargo en el mundo del software, estoy ya acostumbrado a que se planteen objetivos sin sentido, metas a la vuelta de la esquina para algo que queremos denominar producto, planificaciones que no se ajustan en cuanto a personal...

Si algo he aprendido con el desarrollo de agroguía, es que el producto empieza a ser tal cuando tiene cierta madurez, se ha trabajado duro en los detalles. Esos que no se ven cuando se hacen planificaciones a boleo. Y esos detalles no son que la aplicación funcione -eso se da por hecho, que no es poco-, si no que sea simple de usar, que resuelva bien las situaciones inesperadas, que hable el mismo idioma que el usuario (no, no me refiero literalmente) y esos miles de cosas que hacen de una aplicación un producto.

Creo que uno de los grandes problemas del software es que no hay soporte material sobre el que basarse. Sabemos que llevar una piedra de 4toneladas de un sitio a otro no lo podemos hacer si no es con una grúa o un camión, es obvio, es algo palpable, sin embargo algo que no se puede tocar es difícil de cuantificar.

3.21.2010

Como hacer un demonio en python

Siempre llega ese día en el que necesitas tener un demonio funcionando en una máquina. Y cuando llegas ves que necesitas hacer un par de forks, cosas con stdin y stdout... un peñazo, por suerte en python existe una librería llamada python-daemon, aunque no está demasiado bien documentada (hay que bucear un poco en los fuentes), es muy útil para no tener que liarte demasiado para hacer el demonio. Aquí demo un ejemplo de uso de python-daemon con su log y sus redirecciones de los std*.

Para ejecutar el demonio se usa el interfaz típico de start|stop|restart, por ejemplo:
$ python daemon.py start



3.03.2010

Consejos para trabajar con python

Cada lenguaje tiene sus herramientas, su forma de trabajar, sus reglas de estilo, etc... aparte cada uno tenemos nuestros pequeños trucos y reglas para trabajar lo más ordenado posible. Por ello voy a dar una serie de consejos que he ido aprendiendo a medida que he ido programando en python que espero puedan ser de utilidad a otras personas que así lo hagan.

- Sigue las reglas de python. Para conocerlas basta con que ejecutes python -c "import this" en la consola. No son específicas python, creo que sirven para cualquier lenguaje, muy recomendable "lectura".

- Trata de seguir las recomendaciones de la guía de estilo del PEP-008 (Style Guide for Python Code). Los PEP (Python Enhancement Proposals) son documentos que se redactan y siguen cuando se implementa una nueva característica.

- Aprovecha la potencia del lenguaje. Si sabes ruby o similar sabrás de lo que hablo, los que vienen de java, C, C++ están acostumbrados a lenguajes más bien estáticos, se usa poco la metaprogramación. Python tiene cosas muy interesantes, por ejemplo las list comprehesions que agilizan mucho el desarrollo. Siempre con mucho cuidado de no pasarse (la gente de ruby me entenderá). Por ejemplo, la gente que viene de java suele escribir interfaces y luego heredar para a implementación. En python directamente usa duck typing.

- Cuidado con los imports. Salvo que sepas lo que haces trata de no hacer "from module import *". Primero porque si lo haces posiblemente es que no sepas ni lo que quieres usar, segundo porque puede ser una fuente de bugs importante. Es mejor hacer "from module import MyClass, MyClass2". A mi me gusta primero poner los imports de la librería estandard y después lo propios de la aplicación, pero es algo personal.

- Unicode: siempre especifica la codificación del fichero, en el pep-0263 tienes toda la información, pero el resumen es, pon la siguiente cabecera:

#!/usr/bin/python
# -*- coding: -*-

Si no lo haces tarde o temprano tendrás alguna excepción al ejecutar tu código por haber puesto caracteres fuera del ascii. Además, trata de entender como qué es unicode, como se hace para usarlo en python.

- Excepciones. No captures una excepción y no hagas nada. La gente que programa en java lo puede hacer (y de hecho lo hace), pero si eres un hombre de bien haz algo. Captura la excepción que corresponde, esto es, si esperas un socket.error no pongas un except que recoja a troche y moche, solo captura esa excepción.

- Las doctest son una verdadera virguería para documentar a la vez que testear. No en todos los sitios se pueden usar, pero por ejemplo si al comienzo de un módulo pones una explicación usando doctest mejorará bastante, por ejemplo:


"""
Este módulo sirve para sumar 3 números usando la función add3.
Un ejemplo de uso es:
>>> add3(1,2,3)
6
""""
def add3(....


Luego desde la consola puedes hacer:

python -m doctest modulo.py


y ver si algo casca. Más información de doctest y ejemplos. Además luego hay el módulo unittest, hay frameworks para stubs y mocks, helpers para facilitar los test como nose y pytest, todo lo necesario para estar a la última moda del TDD.

- usa la consola. Unas de las cosas más útiles es que tienes la consola siempre a mano para probar cosillas. La mayoría de las veces no me acuerdo como hacer algo, en la consola lo pruebas instantaneamente. Recomiendo usar ipython, que viene ser igual que la consola original python, pero con facilidades para acceder a la documentación, autocompletado, etc.

- Usar pip o easy_install. Es similar a gem en ruby, lo que hace es instalar módulos de terceros desde internet con un solo comando. Esto es fundamental y agiliza el desarrollo muchísimo. Para buscar el software usa Python Package Index donde tú mismo puedes subir tus paquetes. De hecho el paquete de la librería standard para empaquetar módulos lo sube automáticamente con un comando. Prefiero pip a easy_install porque pip está construído con más lógica (tiene uninstall) y más características que cuento dos puntos más abajo.

- Haz pequeños módulos y empaqueta. Empaquetar es súmamente sencillo, con hacer un fichero setup.py con pocos parámetros tienes el empaquetado hecho. Aparte de los benficios que tiene separar las aplicaciones en modulos, tiene otros muy interesantes. El módulo que se usa para estas cosas es distutils, donda hay un ejemplo de setup.py muy sencillo.

- Usa pip. Sí, es repetido, pero pongamos que tienes el caso que has separado tu aplicación en varios módulos que tienes en un repositorio. Desarrollas una aplicación que los necesita, pip te va a ayudar a resolver este problema ya que puede instalar módulos directamente del repositorio (siemre que tengan su setup.py), por ejemplo:


pip install svn+https://mirepo/project/module#egg=module


Todos los paquetes necesarios se pueden poner en un fichero requirements.txt que todas las aplicaciones tengan.

- virtualenv. Herramienta fundamental, permite aislar entornos de ejecución. Puedes crear tantos entornos como quieras, cada uno con una versión de python diferente, cada uno con sus librerías. Esta herramienta es, repito, fundamental. Yo lo uso junto a virtualenvwrapper que simplifica la creación y gestión de entornos. Además junto con pip hacen el combo perfecto. Por ejemplo, para tener un entorno de trabajo funcionando basta con hacer:


pip install -E env -r requirements.txt

pip creará un entorno nuevo, e instalará todo los especificado en el fichero requirements.txt, bajándose lo necesario. Luego basta con activar el entorno y a trabajar:


. ./env/bin/activate


- Aprender a usar el debugger, pdb. Sé que ya no mola hacer debug en la línea de comando, que eclipse te lo da todo mascadito, pero si estás en un servidor remoto es útil cuando solo tienes ssh y vim :).

- Usa el log. Python tiene un módulo llamado logging, úsalo, luego se puede configurar para redireccionar a un fichero, al syslog, a stdout. Tiene las típicas error, info, debug... pero lo importante es que lo uses.

En general, cuando no sé la mejor forma de hacer algo, suelo ir al código de la librería standard y mirar paquetes que suelo usar.

2.23.2010

Pycon 2010 Closing

Echando un ojo a la closing de la pycon de este año leo la siguiente frase:

I've always found a way to use Python as a strategic weapon, a tremendous source of leverage, to make that small group of people much more productive than the big companies that can— through the force of sheer mass— crush you like a bug.

2.11.2010

experimento de promoción


Como algunos sabéis, estamos desarrollando una aplicación para que los agricultores puedan llevar la trazabilidad de sus explotaciones agrícolas. Ya existen aplicaciones que hacen esto, pero son caras, complicadas y hacen demasiadas cosas.

Esta semana se celebra una de las ferias más importantes de agricultura, se celebra cada dos años y reune a una gran cantidad de agricultores. No tenemos stand así que nos hemos hecho unas camisetas con en logo de agrotrack y vamos a ir unos cuantos a ver que se cuece por la feria.

No es algo que creo que tenga repercusión, pero sí puede estar bien como experimento, veremos a ver si tiene impacto en el número de visitas, correos y suscripciones.

Por otro lado vamos avanzado muy rápido con el desarrollo, además tenemos la ventaja de ya tenemos mucho contacto con agricultores y una buena base de datos con los que probar.

1.31.2010

postmorten de NyxQuest

Leía el postmoreten de NyxQuest, que para el que no lo sepa es un videojuego creado por una compañía Española, overthetopgames, con gran éxito internacional en wiiware, y he visto ciertas frases que me han gustado mucho, sobretodo porque encajan bastante con la filosofía de tener recursos acotados para obtener mejores resultados.

Since we didn't have a lot of money to spend, we had to find ways to resolve some problems. Not enough work force for animation? Ask a friend with free time! No budget for voices? Get a voice actress girlfriend with her own studio! No testing department? Friends and family


Since we were a small team and couldn't have a lot of detailed models and textures, we chose a style that focused on lighting and shadows.


At the same time, we were telling the story of a burned and forgotten earth, full of deserts and ruins... this setting was not only chosen because of the story, it helped us to reduce work. Since the game world was ruined and deserted, we could create fewer assets and spend the time on making them stylish.


We decided to partner and fund the game with our own money. In the end this has worked very well, because we managed to do a good looking game in the time we had, and with scarce resources. But it was a very tight development cycle; we barely made it with the money we had saved.


El artículo es altamente recomendable y merece la pena leerlo detenidamente.

1.27.2010

¿ Como programarías si fueses ciego ?

Leo en stackoverflow una pregunta que me ha llamado muchísimo la atención "how can you program if you're blind". Las respuestas de personas ciegas son muy interesantes, sobretodo por ver como se las apañan, como valoran la usabilidad... también hay preguntas un poco estúpidas: "apagas la iluminación de la pantalla del portátil para ahorrar batería?".

Ser ciego seguro que hace mejorar ciertas capacidades; quién no ha tenido que volver al fichero de la clase que estamos usando constantemente a ver el nombre de vaya usted a saber atributo? seguro que ellos retienen toda esa información en la cabeza con más facilidad. Las combinaciones de teclas seguro que son el pan de cada día, el movimiento del cursor seguro es mucho más rápido al no tener que mirar donde está, etc.

También me viene a la cabeza un antiguo compañero de trabajo que era programador y tenía algunos problemas de movilidad. Me quedé muy sorprendido cuando le vi navegar entre carpetas con el explorador de windows. Para él usar el ratón era difícil, sin embargo con combinaciones de teclas se movía a una velocidad asombrosa, mucho más de lo que he visto moverse a personas con sus capacidades motrices perfectas. Él tenía una restricción y ha hecho de ella una ventaja.

Moraleja:

Let limitations guide you to creative solutions

1.24.2010

De pirámides y consultoras

Esta mañana veía uno de esos entretenidos documentales de construcciones, creo que era mega estructuras (o mega-algo) - por cierto, el título original es extreme engineering, imagino que en España algo con la palabra ingeniería de por medio no llamaría -

Explicaban, muy por encima dicho sea de paso, las hipótesis que tenían acerca de como las pirámides habían sido construídas, basándose en las construcciones aledañas a las pirámides, donde se supone que debían acampar los esclavos que las construyeron, en las tumbas que encontraban dentro de las pirámides, etc. Me gustaría destacar dos cosas con las que no pude evitar esbozar un sonrisa pensando en las mega-consultoras donde se hace software a lo bruto, algo parecido a como se hicieron las pirámides.

- Resulta que a tenor de la cantidad de huesos de animales allí encontrados, los esclavos no debían serlo tanto, parecía que estaban bien alimentados, si tenían accidentes les curaban y les mantenían aunque fuese sin, por ejemplo, un brazo. Es curioso como analizando los huesos es posible determinar esas cosas. Además, había grupos de trabajadores especializados...

- Un capataz de la obra, del que encontraron sus restos en un sarcofago dentro de la pirámide, no debía ser ningún mindundi por tanto, tenía los huesos de la columna "aplastados", síntoma de haber cargado con peso durante tiempo.

Conclusiones:

- Los egipcios ya sabían que al empleado había que tratarle bien
- Para saber llevar bien un proyecto tienes que bajar a descargar el camión. En el ámbito metalúrgico lo llaman "mancharse las manos de taladrina"

Igualito igualito que las mega-consultoras "españolas".