javier santana - blog

resumen 2012

noreply@blogger.com (Javi Santana) — Mon, 31 Dec 2012 17:02:00 +0000

Llevo unos días tratando de recordar más o menos lo que he hecho durante el año y me ha resultado difícil, será que estoy perdiéndo memoria con la edad.

Este año lo puedo resumir en dos cosas: trabajo y "realizaciones"

Laboralmente ha sido un año realmente intenso, seguramente el año en el que más producción he sacado de mi vida. Este año he participado en software que muy fácilmente hayan visto más de cien millones de personas: hemos estado en portada de google, hemos salido en la pantalla cara de la google IO, hemos reescrito el frontend de CartoDB en tiempo record, publicado dos releases major de agroguía (casi reescritas desde cero), creado ciertas demos técnicas y pequeños proyectos que han permitido avanzar mucho en el rendering de mapas en cliente, creado librerías en unos cuantos lenguajes diferentes para CartoDB, etc. Por no hablar de unas decenas de pequeñas demos tecnológicas con HTML5 que nunca han salido a la luz, las cientos de pruebas con agroguía para mejorar la precisión...

Obviamente todas esas cosas no se hacen solo, todo el equipo de Vizzuality ha sido el responsable de lo anterior. No creo que sea fácil encontrar a un equipo tan cohesionado, productivo y creativo.

Cierto es que un año así pasa **mucha factura**, he llegado a diciembre realmente cansado, sin apenas tener ideas nuevas y ser capaz de ser eficiente, es una sensación realmente desgradable. No obstante lo he pasado bien.

En lo personal ha sido un año raro, he pasado fuera de casa casi 3 meses, las cosas en la familia han cambiado un poco (cosas de la desaceleración económica) y hemos tenido algún que otro paso por el hospital, todo solucionado por suerte (*). Pero sobretodo he pasado la crisis de los 30 para pasar a la de los 31 :). Es curioso y duro para mi ver como el rol que tenían tus padres cuando eras pequeño ahora lo juegas tú, la gente te presiona para casarte, tener hijos y comprarte una puñetara casa.

Este año que viene lo afronto con algunos proyectos que tengo en mente, espero que sea un poco más ligero de trabajo. Sólo le pido a dios que me libre de esta maldita lesión de rodilla.

Feliz año a todos.

(*) suerte y muchos profesionales haciendo un buen trabajo, muchas personas que antes padecieron la misma enfermedad y sufrieron con ella y miles de horas de investigación.

Cota superior

noreply@blogger.com (Javi Santana) — Tue, 17 Jul 2012 21:26:00 +0000

Este ultimo mes ha sido si la memoria no me falla, el mejor mes de mi vida a nivel profesional. Ha sido tan bueno que será difícil que se repita algo así que dicho así no es como para celebrarlo.

El mes pasado estuvo durante un día completo en portada de google una aplicación web que hemos hecho en vizzuality de la cual he desarrollado el backend. Lo cierto que el mérito de que estuviese allí no es mío pero ser capaz de preparar la arquitectura de la aplicación para aguantar esa cantidad de usuarios ha sido un reto considerable. Hacer una release con google es ademas en cierto modo estresante, pero eso es para otro post.

4 días más tarde hemos presentado otra aplicación con google en la que he trabajado, esta vez una inforgrafía de la evolución de la web que pusieron en la pantalla cara durante una de las presentaciones principales de la google IO.

También presentaron en la googleIO otra aplicación en la que paricipé el año pasado...

Para rematar el mes hemos sentado las bases de lo que será el nuevo agroguía, ahora somos dos socios más!

Por ultimo solo decir que este será seguramente el último post de este blog, todo lo que tengo que decir ya lo digo en twitter...

Historia del giro de un producto software

noreply@blogger.com (Javi Santana) — Sun, 22 Jan 2012 20:54:00 +0000

Para los que no lo conozcan: agroguía es un pequeño producto de guiado GPS que desarrollo y vendo hace 6 años que trata de facilitar la vida a los agricultores guiandoles por las parcelas.

Hace cosa de un par de años yo ya sabía que algún día el hardware donde funcionaba agroguía terminaría desapareciendo. Iphone y android ya estaban ahí y microsoft no podía seguir con una plataforma paupérrima como es windows mobile, así que era de esperar un cambio a otro SO y por tanto todo el desarrollo de agroguía se iría al cielo del software.

El pasado abril-mayo nos encontramos con que el único fabricante de hardware windows mobile compatible con agroguía (en verdad al revés) daba por finalizada la fabricación y por tanto agroguía tenía los días contados. Como somos muy lean, decidimos comprar todo el stock de PDAS compatibles que encontrasemos para sacar el máximo partido al producto.

En octubre vendimos la última unidad en stock y por tanto agroguía se había terminado para siempre. Mi idea era esa, ver como moría en paz, 7 años de producto son muchos años y terminas cansado y desmotivado. Pero aquello era como dejar morir un hijo sin hacer nada. Entonces decidí, en un arrebato totalmente LEAN, cambiar agroguía de plataforma y portarlo a android.

La decisión de android estaba muy clara, tanto técnicamente como a nivel de costes. Así que decidí bajarme el SDK y NDK de android con tanta suerte que hace 7 años tomé dos decisiones técnicas que han resultado ser oro:

- separé muy claramente la parte que dependía del SO de lo que sí. Por aquel entonces el código del quake era mi referencia y así lo hacían ellos. Además me propuse separar bien todo (años más tarde me enteré que aquello se llamaba Modelo-Vista-Controlador)

- Usé OpenGLES. Por aquel entonces nadie daba un duro por OpenGL, pero la idea de tener gráficos 3D en un dispositivo móvil era cuanto menos atractiva. Así que usé una implementación por software de OpenGLES. Quién me iba a decir a mi que años más tarde se convertiría en el standard "real" de móvil para hacer 3D?

(ahora recuerdo lo de unir los puntos hacia atrás que decía Jobs en su famoso discurso)

Estas dos decisiones me han permitido reusar TAL CUAL todo el código de la primera versión que no dependía del SO. La mayoría de los ficheros de código siguen sin tocar desde hace 6 años.

Calculé que el porting me llevaría 1 mes, incluído el testing en real, que en una aplicación que no puedes actualizar es bastante importante. Yo sabía en verdad que hasta el 2012 no lo tendría.
De mientras la cola de personas esperando la versión empezó a crecer, es increíble lo comprensiva que es la gente incluso cuando les explicas cosas que les importan un pepino. Pero bueno, siempre hemos sido bastante transparentes con los problemas y siempre ha funcionado bien.

A primeros de diciembre tenía ya una versión "estable", ya sabía "casi seguro" que era posible, tocaba buscar el hardware y todo lo asociado, que funcionase bien, que tuviésemos proveedores en los que pudiésemos confiar, echar cuentas de lo que costaría etc. Esas cosas que hay que hacer, pero que no se ven. Hay que tener en cuenta factores como el peso de la tablet para que aguante en un soporte pegado al parabrisas de un tractor... :)

En Enero ya teníamos el hardware elegido y pude empezar a probar en la plataforma final, después de un par de semanas de pruebas de funcionamiento correcto, de estrés y demás la versión 1.0 estaba terminada. Tiempo para preparar el manual del producto (que por cierto ha pasado de 20 páginas a 8)

Ayer pusimos las dos primeras unidades de agroguía a los primeros agricultores :D

Destacaría de estos 3 meses:

- He tomado bastantes decisiones, por ejemplo he decidido eliminar funcionalidad, simplificar algunas cosas y cambiar el modo de otras que la experiencia nos ha dicho que no funcionaba tan bien.

- He tenido que ser muy estricto al trabajar porque el tiempo apremiaba y siendo sincero prefería hacer cosas nuevas que la plataforma permitía, que eran mucho más cool que reimplementar el sistema anterior. Conocer como funciona el negocio ha sido vital para no irme por las ramas.

- He sacrificado calidad en algunas partes para tener el producto rodando cuanto antes. No es perfecto, no pasa nada, poco a poco mejoraré esas partes. Creo que a esto le llaman minimun viable product.

- Carlos Sainz decía que ganar el primer campeonato mundial de rallies fue fácil, que lo difícil fue mantenerse. Aquí me ha ocurrido algo parecido. Cuando desarrollé la primera versión no había miedo, hacías las cosas con dos cojones, a lo bruto. Ahora todo da mucho miedo, sabes que tienes que mantener la calidad de tu producto y eso hace ser mucho más conservador. Esto es posiblemente lo que más acojonado me ha tenido estos meses (y me tiene). Aún así he metido cosas de esas cool que posiblemente al agricultor le importen un pimiento.

- Ha sido (y es) un reto. Esto hace que recobres un poco la motivación perdida y te abre a nuevas ideas. Android en si es una basura (IMHO) pero la plataforma permite mucho más que windows mobile.

- Algo un poco más friki, he empezado a usar git-flow y es muy recomendable para este tipo de productos.

A seguir se ha dicho.

objetivos 2012

noreply@blogger.com (Javi Santana) — Mon, 02 Jan 2012 14:49:00 +0000

Este año pasado ha sido ciertamente agridulce. Por una parte han pasado cosas muy tristes, de esas que se quedan y te hacen reflexionar todos los días, luego otras un poco menos malas, por ejemplo agrotrack, un proyecto en el que he invertido 1 año de mi vida, se fue a tomar por culo (bueno, quizá sea mejor decir, lo mandé a tomar por culo) y cosas muy buenas, enumero las que más me han marcado:

- Empezar a trabajar en vizzuality, gracias a esto último he cumplido mis dos objetivos del año pasado. También esto me ha permitido conocer y trabajar con gente estupenda.
- Estar en contacto un año más con mis ex-compañeros y amigos de unkasoft. De hecho estar en vizzuality es un poco como revivir la experiencia de unkasoft.
- Conocer a gente como Jorge, Amalia, Álvaro y cía, que siempre les falta tiempo para apoyarte, echarte un cable y perdonarte cuando es necesario.
- Re-descubrir el deporte.

Y ahora los objetivos 2012 (y de paso devuelvo la pelota a David Bonilla), pero esta vez en una lista de deseos, sin order alguno, según van saliendo.

- Hacer un juego con los gráficos de Javier
- poder trabajar con Simon una semana para rematar algunos proyectos de los buenos
- aprender algo de diseño de Sergio y Diego
- aprender a dibujar
- ser algo más creativo
- participar en alguna que otra hackaton/proyecto con gente que no conozco pero admiro: aitor (linkinpaths en general), Mr.doob, super-sole, (me he cansado de enlazar a tuiter), @hyperandroid, @jorgebastida por citar algunos.
- hacer una hackaton con la gente de vizzuality que todavía no hemos tenido ocasión.
- viajar un poco más
- ver más a mi apiguitos
- tratar de correr una san silvestre (con Bonilla :P)
- no lesionarme de nuevo
- programar menos
- participar en la creación de un doodle (por pedir...)
- Y por último ser un poco menos gilipollas, prepotente, insensato y bocazas y más comprensivo, responsable y comprometido.

Besos :*

Lejos

noreply@blogger.com (Javi Santana) — Fri, 09 Dec 2011 11:58:00 +0000

Me llama mi madre o mi hermano y después del típico "qué tal estás" muchas veces ya no tengo mucho más que decirles y lo que es peor, ellos tampoco saben que decirme. A veces mi madre hace el esfuerzo de preguntarme, en vano, qué es lo que hago en el trabajo, imagino que en un intento de hablar conmigo algo más de los 30 segundos que dura el qué tal estás. Estoy acostumbrado a tratar con máquinas y con personas que normalmente solo hablan con máquinas y me pregunto si no estaré tan acostumbrado que he olvidado que el resto de humanos no son así.

El síndrome del repetidor

noreply@blogger.com (Javi Santana) — Mon, 17 Oct 2011 08:30:00 +0000

El primer mes de carrera fue bastante confuso, imagino que igual que para el resto de personas, gente nueva, la primera vez que salía de casa, el acojone de estar solo ante el peligro... ya sabéis. Las clases empiezan, te juntas más o menos con los que parecen que son como tú y 1 semana después ya tienes posiblemente el círculo de personas que configuren tus próximos 3/5 años.

Entre esos posiblemente hay algún repetidor, buen chaval él, al que escuchas con cierto interés ya que él sabe todos los trucos, ya sabes, asignaturas chungas, profesores majos, los hijos de la gran putísima (ahora me doy cuenta que muchos de aquellos no eran más que unos inútiles)

Algunas de las cosas que a mi me dijo aquel chaval fue: "esta asignatura es _imposible_ aprobarla sin ir a la academia" o "es imposible ir a curso por año". Por aquel entonces ni tenía dinero para pagar la academia -suficiente apretada estaba ya mi familia como para apoquinar otro poquito más al mes- y lo que más me jodía, que alguien me dijese que "eso era imposible". Aquel día se me hincho la vena y enrabietado para mis a adentros me dije "y por qué esto no va a ser posible?".

Fue posible.

Así que cuando algún "repetidor" llegue y te diga que algo es imposible, tómatelo como algo más a anotar en la lista de cosas a tener no muy en cuenta. Eso sí, no piensas que no te va a costar trabajo.

Por qué deberías contratar a gente que tenga proyectos opensource

noreply@blogger.com (Javi Santana) — Sat, 21 May 2011 09:38:00 +0000

Podemos recrearnos en lo bonito que es el opensource, qué comunidad más interesante, la filosofía, blablabla, las sinergias colaborativas que provoca ... y demás palabras que tanto nos gustan, pero la realidad es que si un desarrollador tiene proyectos de código abierto lo más probable es que sepa un poco de todas estas cosas:

- Lo importante de escribir documentación. No hablo de esa documentación que todos esperamos, no de esa que se genera a partir del código, ni de esa que va encuadernada de 200 páginas con imágenes obsoletas. Hablo de ese README donde están los primeros pasos para empezar con el proyecto. Aquí es donde vendes tu producto. Recomiendo una charla muy buena de jacob kalplan-moss, writting great documentation. De hecho creo que uno de los grandes éxitos de github es tener una portada de proyecto con el README renderizado desde un fichero de texto.

- Cerrar código: un código cerrado no es lo mismo que un código terminado. El típico caso de "no, es que tienes que poner el fichero XXXX.cnf en tal ruta, habilitar el puerto serie, ejecutar tal demonio, cambiar config.h y ya"

- Lo importante de testear. Si una persona quiere aportar a tu proyecto y no hay tests no podrá estar seguro de cada cambio que haga.

- Enseñar tu código te obliga a hacer las cosas lo mejor que puedes, o por lo menos no pasar por alto esas situaciones de "ya lo haré bien". Si tu quickstart son 10 comandos algo no va bien, no?

- Trabajar en un entorno distribuído. Cuando me bajo y uso jquery no tengo a john resig en la mesa de al lado, así que me las tengo que apañar como pueda para solucionar mis problemas. De la misma forma otros no me tendrán a su lado cuando empiecen a usar tus proyectos y la mejor forma de hacer esto es dejar las cosas bien (esto tiene mucho que ver con los anteriores puntos).

- "Compartir es vivir". Si tu desarrollador libera código habrá entendido que compartir es bueno para los demás y para él mismo.

Por tanto, haz que tu empresa libere código y haz que el funcionamiento interno se parezca lo más posible al sistema open source. Ya sabes, empieza por hacer que crear un repositorio y un tracker sea tan simple como en github/bitbucket y da alas a tus empleados a que suban allí su código.

Ejercicio para gente que no desarrolla

noreply@blogger.com (Javi Santana) — Wed, 27 Apr 2011 13:25:00 +0000

Este es un ejercicio para que lo realicen a modo de prueba la gente relacionada con el desarrollo de software pero que no desarrollen. No te llevará ni un minuto. Asegúrate que estás solo y sin distracciones.

Pasos:

1.- plantea una suma de dos números de 10 cifras, en una hoja de papel, como lo hacíamos cuando estábamos en el colegio

2.- hazla con tranquilidad, cronometrándote. Cuando termines, anota el tiempo

Te planteo ahora dos retos:

Reto 1: Ahora plantea otra suma, pero entre columna y columna que sumas, cuenta de 1 a 5. Cronometrate y compara con el tiempo anterior

Reto 2: Plantea ahora dos sumas de números de 10 cifras. Haz las dos sumas, pero salta de una suma a otra cada 2 columnas. Al igual que antes cronometrate.

Reto Bonus: Planteate otra suma y dile a alguien que cada dos números te haga una pregunta simple, por ejemplo, tu numbre, apellido, calle donde vives o número de DNI.

Y este post no tiene nada que ver con las sumas :)

whitebrd.me - detalles técnicos

noreply@blogger.com (Javi Santana) — Fri, 08 Apr 2011 16:11:00 +0000

El pasado fin de semana (primero de abril del 2011 por si lees esto en un futuro lejano) organizamos alltogethernow, un encuentro de un fin de semana para hacer una aplicación en 48 horas. La aplicación que hicimos nosotros (@flopezluis y yo)fue whitebrd.me, una pizarra compartida en tiempo real. Voy a dar una pinceladas de los detalles técnicos y un pequeño post-morten después de 1 semana funcionando.

Para empezar optamos por usar toda la tecnología del servidor asíncrona. Pensarás que lo hicimos porque es lo que mola, ahora lo asíncrono está en todos lados, si no tienes algo asíncrono no puedes montar algo como dios manda... si toda la gente que se le llena la boca con "asíncrono" hubiese leído la famosa (en mi época) "beej's socket guide"... :).

El caso es que tornado, un pequeño framework web creado por friendfeed (después comprada por facebook) y ahora matenido por facebook, hizo las veces de servidor web y redis como sistema de persistencia. La elección de redis fue por dos razónes. La primera por hypearnos a más no poder y la segunda es que permite escribir muy rápido, tiene funcionalidad de publisher/sibscriber y un sistema de VM que encaja muy bien (luego veremos cómo). Para rematar usamos nginx como frontend. Se puede ser más asíncrono? :)

La razón para usar asíncrono realmente es muy sencilla: es una aplicación con MUY poca carga de CPU y mucha E/S, así que el paradigma encaja perfectamente.

En la parte de cliente usamos websockets para enviar todos los comandos y canvas para dibujar. Es una tecnología novedosa, así que sabíamos que muchos navegadores no lo soportarían (FF4 lo tiene desactivado por defecto, primer #FAIL).

Manos a la obra, nos pusimos y en 48 horas teníamos el código en cuestión. Más que comentar el código, prefiero centrarme en las cosas que han pasado en estos días y algunas conclusiones técnicas que he sacado.

- El segundo día a la gente de github les dio por poner un enlace en su blog. No sé cual será el tráfico de ese blog, pero en el nuestro generó 4.5Gb de tráfico en 12 horas. Iluso de mi, no había activado la memoria virtual en redis, de forma que redis no podía tirar a disco las pizarras ya no usadas (se almacenan todos los comandos que genera una pizarra), así que empezó a "swapear" como un demonio. Suerte que teníamos el deploy automático, así que la activé rápido y medio solucionado. Finalmente la clave que almacenaba esa pizarra terminó con más de 20mb de datos. He tenido que eliminarla porque el VPS de 256mb no da para mucho más :). La CPU de la máquina no pasó de un 8%.

- tornado funciona excepcionalmente bien, además de ser un framework muy interesante para cosas "sencillas" (no tiene ORM por ejemplo) es realmente rápido. Además el nucleo es fácil de entender y está bien documentado. Podríamos haber optado por twisted, gevent o algún otro sistema asíncrono en python.

- tratamos de usar el mecanismo pub/sub de redis, pero la librería asíncrona cliente redis para python es completamente inestable, así que terminamos por implementar lo misma funcionalidad en una pequeña clase . Moraleja: a veces la solución más simple es la mejor.

- no conocía redis, pero es realmente un descubrimiento. Funciona muy bien: el setup es muy rápido, prácticamente configuración 0, la integración con los tipos de python buena y además rápida. El model de memoria virtual encaja muy bien ya que si es necesaria más memoria las claves que no se usan las vuelca a disco, de forma que todas las pizarras que ya no se usan no están malgastando los 256mb memoria.

Ahora mismo hay más de 1000 pizarras creadas y la mayoría de ellas tienen dibujos de aparatos reproductores masculinos :)

Montar una empresa, desde cero

noreply@blogger.com (Javi Santana) — Tue, 01 Feb 2011 17:47:00 +0000

Resumen: haz algo y véndelo (no lo regales)

Hace ya unos años que vengo leyendo y escuchando que lo de montar una empresa de base tecnológica en España es una utopía, que si no dan dinero, que si el papeleo, la burocracia, los socios, la competencia y la madre que lo parió.

Bien, pongamos que vas a montar una empresa de tecnología y vas a vender un producto o servicio. Partamos de dos supuestos:

1) No estás trabajando y nunca has trabajado: El primer paso es que te dejes de leer esto, busques un trabajo y veas de que va. Quizás no sea necesario, pero yo lo recomiendo. Sobretodo, si eres técnico, no te fijes en lo que hacen tus compañeros técnicos, fíjate en los comerciales, gerentes y otros que salen a vender el pescado.

2) Estás trabajando y/o tienes experiencia: se supone que ganas un salario y que además sabes de que va lo de trabajar: momentos duros, horas, esfuerzo, dolores de espalda, el sueldo de final de mes, las retenciones, la SS, los compañeros, jefes, comerciales, etc.

primer tópico: Nadie me va a dar 200k€ que necesito para levantar mi empresa. Ya, no has pensado que antes de correr tienes que aprender a andar? Realmente necesitas 200k€ para probar? Tranquilo, cuando factures un poco y la gente vea que funciones vendrán a ofrecerte dinero, palabra. Agroguía lo empezamos con 400€, para comprar un equipo con el que hacer demostraciones y para imprimir unos carteles y pegarlos por los pueblos usando el coche del padre de novia.

segundo tópico: Mi trabajo no me deja tiempo. Bien, trabaja a media jornada (vive con menos dinero) y usa tu tiempo libre para desarrollar tu producto/servicio. Lee el post de Martín Pérez sobre el emprender full time. Yo desarrollé agroguía terminando el PFC y trabajando a media jornada.

Te pones a desarrollar tu negocio, piensas que puede haber un buen hueco donde vender tu producto y lo haces. Posiblemente no sepas muchas cosas y dudarás, no pasa nada, vete a hablar con un posible cliente, o dos, o tres... y preguntale qué necesita. Te vas a sorprender de lo amable que es la gente cuando le preguntas por un tema que le interesa. Sí, lo mismo necesitas quedar con él en horario laboral y tengas que pedirte un día de vacaciones en tu trabajo. Regalale tu producto en agradecimiento (pero luego cobra por él eh?), si confías en tí no hay porque tener miedo. Nadie dijo que no llevase esfuerzo. Lo mismo te da vergüenza, tienes miedo o "yo es que no soy comercial". Si es así olvida montar algo, dejalo para cuando tengas más experiencia.

Lo desarrollas (aquí pueden pasar meses, tú sabrás, se supone que es tu fuerte ¿no?) y te pones a venderlo. Pero tienes que ser realista, debes centrarte mucho en algo concreto y pequeño. Tienes poco tiempo y por muy bueno que seas los milagros no existen.

tercer tópico: Para vender y facturar necesito tener una base legal, una empresa y me han dicho que en España se tardan un montón de meses y se necesita mucho dinero para montar algo. Mentira, para facturar con ser autónomo (y con menos) tienes suficiente. Son 200 y pico € al mes de seguridad social, tienes que hacer el IVA cada trimestre y la declaración de la renta como todos los años. En un día tienes todo el papeleo hecho. Lo normal es que hables con una gestoría que te lleve los papeles, no es caro. Si piensas que una gestoría es cara, olvidate de montar el negocio.

Hazte ver, ya sea haciendo una web y dando la chapa en un foro, poniendo carteles en la tiendas o lugares donde tus clientes pasan, por twitter, por facebook, cara a cara... te sorprenderías de lo amable que es la gente y lo que te ayuda. Nosotros hemos ido a cooperativas y tiendas para agricultores y NUNCA nos han negado poner un cartel o publicidad, todo lo contrario, cuando la gente ve que necesitas ayuda, te ayuda, y mucho. Vendete como puedas.

Pongamos que haces el primer cliente, de potra, porque de vender no tienes ni idea. Tu producto será posiblemente no demasiado bueno, pero la persona ha confiado en tí, no le falles.

cuarto tópico: es que soy técnico y no sé nada de marketing, ni comercial, ni nada. Necesito tener empleados/socios que sean comerciales, de marketing o lo que sea. Está claro que contar con gente que sepa de su campo está muy bien, pero haz tú esos roles. Aprenderás muchas cosas que necesitas saber.

Ahora es cuando empieza lo duro. Tu cliente te necesitará, tendrá problemas, tendrás que esforzarte, pero si lo haces obtendrás lo que necesitas

1) feedback con muy buenas ideas para seguir desarrollando tu negocio y seguir vendiendo

2) Ese cliente, si está contento, será tu mejor comercial

Y preparate para recibir ostias por doquier, preparate para trabajar mucho, para tener el sentimiento de que estás fallando, de que esto es una mierda, de "qué bien estaba yo trabajando por cuenta ajena", de que echas un montón de horas, etc.

Eso sí, el momento en el que un cliente usa algo que tú has creado, y le es útil, te recomienda y te llama para felicitarte. Aún recuerdo cuando me llamaron la primera vez para felicitarme porque se había ahorrado una verdadera pasta en simiente por usar mi producto, cuando otros que admiras te reconocen, ganas premios, cuando te sacan en el periódico o en TVE y te llama tu tío de Bilbao con lágrimas en los ojos para decirte que te ha visto o creas pequeños side-projects. Sientes el proyecto como tuyo, eso no se paga con una nómina.

Bien, ahora haces una serie de clientes, facturas una cantidad que hace que merezca la pena. Quizás ahora es cuando puedas dejar de trabajar y ponerte full-time, buscar comerciales, socios, inversores para irte a una oficina en condiciones, o simplemente mantenerte ahí y hacer lo que te venga en gana. Nadie dijo que tuvieses que crecer (yo sigo trabajando full-time para una empresa, soy un cobarde :)

Si crees que teniendo un montón de pasta de capital riesgo va a ser más fácil, lo llevas claro: los vas a tener con el aliento en tu cogote y desde luego el resto de cosas las tendrás que hacer, aunque eso sí, con la seguridad de tu nómina al final de mes y una tarjeta de visita estupenda donde pondrá que eres CEO de uberspainsoft S.L. Todo tiene sus ventajas, no digo que no sea una buena idea. Seguramente si quieres montar algo con cierta entidad o equipación cara necesites cierta pasta para empezar.

En resumen: tiempo, esfuerzo y dinero, si no tienes dinero, ya sabes qué opciones te quedan. Déjate llevar, lanza algo aunque sea pequeño y verás como crece o falla mientras aprendes. Seguramente no lo hagas todo bien, nadie nace aprendido, así que no pasa nada.

Qué lo que te he contado es cutre, poco profesional o poco serio. Es una forma, seguro que hay otras muchas mejores :)

Cosas que te pueden interesar:

- Linking paths sobre bootstraping.

- Datos de un pequeño negocio: lo que facturamos en agroguía

- devilishgames, una empresa que hace juegos en flash. Son un verdadero ejemplo, llevan la tira de años trabajando, al principio haciendo juegos gratis, pero poco a poco, con trabajo muy duro se están haciendo un hueco entre los mejores. Otra por el estilo es LemonTeam o Cokidoo con equipos de gente con mucho talento y trabajo duro.

- Hay muchos ejemplos interesantes, por ejemplo ukecosas, marcelino llano con sus servicios de desarrollo de producto, etc, etc.

Las herramientas que uso

noreply@blogger.com (Javi Santana) — Mon, 17 Jan 2011 19:10:00 +0000

Una de las cosas interesantes del desarrollo es ver como trabajan los demás. Es difícil sentarte al lado de un desarrollador y no aprender ese pequeño truco o herramienta, siempre hay algún detalle que te puede servir o que puedes aportar, así que voy a comentar las que uso a diario y me hacen la vida más fácil.

Fundamentalmente uso Linux y OSX, aunque prácticamente uso las mismas herramientas en ambos. Aparte de las que todos conocemos, grep, ls, cp, mv... mis favoritas son las siguientes:

- vim: lo uso como único editor. No sé si será el mejor, pero usar el mismo editor para todo tipo de fichero es realmente eficiente.

- tmux: es una herramienta que permite tener varias terminales virtuales dentro de una. Es similar a GNU screen. Permite además conmutar rápidamente entre terminales (ctrl-b + NUM o ctrl-b + l), partir la pantalla vertical y horizontalmente (muy útil por si ejecutas un comando y quieres ver la salida de un tail -f).

- ack-grep: es un grep con esteroides, te saca las búsquedas coloreadas, ignora las carpetas .git .svn y demás especiales. Fundamental si eres programador

- git svn: es una parte de git, pero es tan útil para trabajar contra servidores subversion... :)

- gitk y gitg en linux, gitx en osx: son herramientas gráficas para ver las historia de un repo git, la mar de útiles cuando quieres ver los commit, hacer diffs y demás.

- rsync: espectacular herramienta para sincronizar ficheros entre carpetas, sobretodo entre diferentes máquinas.

- curl: para hacer peticiones web, permite hacer test, revisar las cabeceras (con -I, confieso que no puedo evitar echar un ojo a las cabeceras de los servidores web)

- ab (apache benchmark), para ir teniendo idea de las reqs/s, tiempo de respuesta, etc que tiene la applicación web.

- fabric: es una herramienta para automatizar tareas en servidores y permite hacer cosas un poco más complejas que con un simple ssh. Junto con bash y rsync automatizar es un gusto :P.

- firebug y web developer tools de chrome

- ipython: consola python con esteorides

Últimamente estoy probando vagrant (para gestionar máquinas virtuales), cada día trato de hacer músculo con vim, usar más los trucos de bash...

objetivos 2011

noreply@blogger.com (Javi Santana) — Sun, 02 Jan 2011 15:58:00 +0000

Cada año que pasa esto de platearse unos objetivos me lo creo menos, pero todo sea por hacer el ejercicio mental. El año 2010 ha sido realmente malo, así que esperemos superarlo. Al tema:

- Recuperar la ilusión por desarrollar. He perdido mucha de la ilusión que tenía, no me encuentro muy motivado, no sé si es por los proyectos, porque me hago mayor, cada vez me cuesta más aprender cosas nuevas interesantes, no veo que mi trabajo sea efectivo y sirva para algo. Tal vez esto sea cuestión de tiempo, de encontrar un proyecto interesante o es que quizás haya llegado la hora de cambiar de "negocio"

- Mejorar mi inglés de una vez por todas. No necesita demasiada explicación.

mejor me quedo como estoy

noreply@blogger.com (Javi Santana) — Sun, 28 Nov 2010 20:13:00 +0000

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.

5 minutos

noreply@blogger.com (Javi Santana) — Sun, 21 Nov 2010 20:02:00 +0000

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.

El camino corto

noreply@blogger.com (Javi Santana) — Sat, 13 Nov 2010 16:22:00 +0000

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.

scrapper multiproceso en python

noreply@blogger.com (Javi Santana) — Sun, 31 Oct 2010 21:11:00 +0000

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()

El desarrollo por el desarrollo

noreply@blogger.com (Javi Santana) — Sun, 24 Oct 2010 19:52:00 +0000

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.

empezando a correr

noreply@blogger.com (Javi Santana) — Tue, 21 Sep 2010 15:15:00 +0000

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.

Oferta de trabajo made in spain

noreply@blogger.com (Javi Santana) — Thu, 26 Aug 2010 16:49:00 +0000

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.

El soporte y atención al usuario

noreply@blogger.com (Javi Santana) — Wed, 28 Jul 2010 11:40:00 +0000

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.

testing y deploy con python

noreply@blogger.com (Javi Santana) — Sun, 11 Jul 2010 16:12:00 +0000

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.

Una semana como gestor de proyecto

noreply@blogger.com (Javi Santana) — Fri, 09 Jul 2010 15:52:00 +0000

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 :)

Necesitamos buenos técnicos

noreply@blogger.com (Javi Santana) — Mon, 28 Jun 2010 21:44:00 +0000

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"

Razones para NO usar un IDE

noreply@blogger.com (Javi Santana) — Thu, 24 Jun 2010 17:49:00 +0000

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

Testing con datetime en python

noreply@blogger.com (Javi Santana) — Wed, 09 Jun 2010 18:59:00 +0000

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.