Bueno, pues es último día del año, intentaré resumir un poco mi año y repasar los objetivos que me puse el año pasado.

• Hablando sobre mis trabajos como freelance ya hice una reflexión hace poco, sobre las cosas que había hecho mal o no me habían salido muy bien y quería (y he empezado) a cambiar.
  
  Pero también han habido cosas positivas este 2012: La mayoría de clientes este año han sido de fuera de Aragón, veo positivo que vengan a buscar más clientes foranos mis servicios, sobre todo este final de año. He visto que puedo potenciar como línea de negocio mis conocimientos de scrapping, sin hacerlo me han llegado un par clientes los últimos meses; que aunque es un trabajo poco agradecido, cada vez lo hago mejor y tengo más recursos para hacerlo con éxito. Y el último par de meses está prometiendo un 2013 la mar de interesante.
• Respecto a producto propio, he estado trabajando en Minchador. No ha llegado al nivel de madurez que esperaba a estas alturas, pero el trabajo a clientes me ha ahogado durante meses y no le he podido dedicar la atención y cariño que merecía para tenerlo en abierto. De todos modos, conseguí lanzar una beta cerrada que me dio un feedback interesante y detecté algunas mejoras que debo implementar antes de dar acceso a más posibles clientes.
• Creo que trabajo mejor, he sido más auto-exigente conmigo mismo, y seguiré siéndolo. Pero todavía debo venderme mucho mejor.
• He lanzado varios sideprojects como VandalArt y SpotyWhere, he hecho pequeños cambios y actualizaciones en la versión web de DNDzgz, otro par de proyectitos están a medio camino de salir al público y no he trabajado lo suficiente en tratar de evolucionar y mejorar ElDisparate (encontré varios periodistas interesados en colaborar, pero no saqué el tiempo que debería).
• He seguido participando activamente en CachiruloValley. Ayudando a organizar eventos e intentando que la comunidad vaya madurando. Incluso me metí en un lío montando un grupo de trabajo para lanzar un proyecto en internet, que pronto haremos público. Por otro lado he seguido apoyando y participando desde segunda línea con el grupo Agile Aragón, en cosas como el AOS2012 y el Coderetreat.
• También he participado como ponente en algunos eventos: Spring IO, previo al AOS, en un betabeers sobre ElDisparate y una charla introductoria a Agile en la Universidad de Zaragoza. Y además fui a un Open Space a Valencia sobre código como expresión
• Apenas he viajado más allá de visitar clientes. Nunca he sido muy viajero, pero algunas escapadas siempre he hecho. Este año tuve pocas vacaciones, y en el pueblo.
• Mi inglés sigue siendo de risa.

Mis objetivos para 2013:

• Lanzar y hacer rentable Minchador, para poder centrarme mucho más en trabajar en productos propios y menos dar servicios de desarrollo a terceros.
• Poder lanzar, aunque sea algo muy pequeño, un producto futbolero que tenemos hablado con Pablo Jimeno.
• Irme unos días/semanas a trabajar mano a mano con algún equipo en alguna ciudad diferente, y quizás hacer desksurfing en alguna empresa amiga.
• Mejorar mis habilidades en lo que tiene que ver con la parte frontend del desarrollo web. Y seguir profundizando en temas relacionados al diseño.

Tengo cosas que, sin ser objetivos, me gustaría o no descarto hacer: impartir formación sobre un par de temas que vengo un tiempo dando vueltas, hacer algo relacionado con comercio electrónico con recursos propios, lanzar algún otro pequeño proyecto personal... Y bueno, lo típico de tratar de contar más cosas aquí en el blog :P.

Nos vemos. Feliz an nou!

El 8 de diciembre se celebraba el Global Day of Coderetreat, un evento a nivel mundial en el que en cada ciudad que se une se organiza un coderetreat. En Zaragoza se organizaba desde Agile Aragón, el principal responsable de ello fue Fernando Pérez. Y, de rebote, al final me tocó a mi ejercer como facilitador.

Para mi era un poco marronazo el hacerlo. Aparte de no haber facilitado nunca antes, tan sólo había asistido a uno hace ya un par de años y a 2 coding dojos. Tampoco soy muy dado a hacer katas sin hacerlo junto a otra persona.

Tuve una semana previa apretadilla, pero saqué tiempo para poder volver a practicar un poco la kata del juego de la vida y empaparme de los recursos para facilitadores para ir un poco más preparado. Yo terminé el día relativamente satisfecho (y agotado), quizás porque al final que los asistentes le saquen el máximo partido al día depende de ellos mismos, de sus iteraciones, sus parejas de baile en cada una de ellas y su actitud. Yo me limité a introducir algunas variaciones y restricciones para ir complicándolo y darles otros puntos de vista para tratar de hacerlo más ameno.

Por lo que sabía, en principio habían algo más de 30 personas apuntadas, de las cuales terminaron asistiendo un total de 25 personas (si no conté mal), lo que no está nada mal para un sábado en mitad de un puente ¿no?. Antes de empezar, acumulamos fuerzas con un desayuno patrocinado por la gente de keensoft mientras llegaban todos los asistentes al BSSC.

Tras ello mostré rápidamente un par de videos sobre el Global Day of Coderetreat, y posteriormente pedí que cada uno se presentara brevemente para explicar a qué se dedicaba y con qué lenguajes solía trabajar, así cada uno pudiera fichar con quien quería "aparearse" durante el día :).

Al final hicimos 6 iteraciones de 45 minutos:

• La primera libre para familiarizarse con el problema, para calentar un poco el cerebro :)
• En la segunda propuse que se tratara de empezar a practicar Test First, o al menos hacer Tests. En la anterior ya mucha gente empezó al menos haciendo tests, por lo que propuse que todas las parejas lo hicieran ya. Y también que se pensara en empezar a solucionar las reglas una a una y no de golpe.
• En la tercera insistí en tratar de hacer TDD, que buscaran el hacer antes el test siguiendo el flow de rojo, verde, refactoring. Y prohibí hacer el tablero/grid en los primeros 20-30 minutos de la iteración.
• Para la cuarta, con la modorra después de comer y viendo que la gente tenía la mecánica de hacer tests antes de la implementación, propuse que se practicara pair programming en ping pong. Eso es que: Foo escribe un test, Bar la implementación, una vez implementado (y refactorizado) Bar escribe el siguente test y Foo la implementación... y así hasta el infinito, o acabar :).
• Para la quinta puse la restricción de que los métodos no debían tener más de 4 líneas de código. Además, justo en mitad de la iteración, hice un pequeño experimento haciendo un cambio de parejas. Alguien de la pareja se quedaba con el código la otra persona tenía que incorporarse a lo que hubiera adelantado otra pareja. Fue curioso ver que durante varios minutos las parejas hablaban para saber qué se había hecho y nadie tiraba una línea de código :P.
• En la sexta y última iteración sólo tenía pensado poner una restricción, que no hubieran flags y así forzar a tener que usar polimorfismo. Al ser la última no quería proponer nada más, que la gente procurara aplicar lo aprendido durante el día pero forzando a darle un enfoque un poco diferente.

Entre medias de las sesiones surgieron temas como los magic numbers, la dificultad de encontrar buenos nombres a métodos o variables, la expresividad del código, las bondades del testing o el pair programming, encapsulación, orientación a objetos...

En cuanto a lenguajes, aunque había predominio de Java y C#, se utilizaron un buen puñado. Si no me dejo ninguno: Python, Groovy, Javascript, Objective-C, C++, PHP y algunos aventureros probaron TypeScript. No fue así, pero esperaba que en algún momento se hubiera animado alguien a alguna iteración con Ruby, o incluso con CoffeeScript :P.

Al final del día hicimos lo que llaman cerrar el círculo, cada persona tenía que hacerse (en alto) tres preguntas y compartirlo con el grupo: ¿qué has aprendido hoy?, ¿que te ha sorprendido hoy?, ¿que vas a hacer diferente a partir de hoy?. Personalmente, como otros también compartieron cerrando el círculo, me quedó la espinita clavada de quienes no veían posible aplicar en sus trabajos diarios las cosas de practicadas durante el día. No sé, no creo que sea fácil desde abajo imponer según que prácticas a una organización de golpe, pero hay pequeñas cosas que pienso que sí se pueden intentar para que las empresas empiecen a ser más receptivas para hacer las cosas de otra forma; pero esto es otro tema :P.

Como curiosidades, tuvimos una partida en el futbolín del BSSC lista desde primera de la mañana y ni nos acordamos de jugar al menos un par de bolas. Además en Zaragoza teníamos un bonus, Francho trajo un pequeño tirador de cerveza que fue la sensación del día, puro Beer Driven Development de la que final del día no quedó ni gota ;).

Para terminar el día, antes de recoger la sala e irnos de cañas, conectamos por hangout con el Coderetreat de Madrid; nos saludamos y estuvimos charlando un poco de como habíamos pasado el día. Fue el momento en el que se hizo patente que la estrella del día fue el tirador de cerveza :D.

En definitiva, creo que fue un buen día, yo terminé agotado del fin de semana y con mono de no poder haberme apareado para hacer la kata :P.

El segundo fin de semana de Noviembre, se celebró el primer Grails48, un hackathon a nivel mundial en el que se debía desarrollar una aplicación web hecha con Grails en el transcurso de un fin de semana.

Pues bien, yo participé en un equipo junto a Raúl Gracia (desde Londres), Fernando Val (desde Dublín), Rafael Ramos (desde Zaragoza) y Alberto Vilches (desde Madrid); lo que viene siendo un equipazo, que además del evidente handicap de que supone la deslocalización tenía alguno más. Salvo Raúl y yo, el resto no habíamos trabajado nunca juntos (o no más que en proyectos pequeños por amor al arte). También sabíamos que no íbamos a pegarnos todo el fin de semana programando (por ejemplo, yo mismo me fui con Rafa de concierto el sábado, con su posterior resaca :P) y que la dedicación de algunos iba a ser bastante limitada por tener otro tipo de obligaciones. Pero, con el equipo que montamos, tenía claro que del fin de semana saldría un resultado interesante de todas formas.

La idea a desarrollar era de Raúl, una aplicación web donde localizar canciones en un mapa, que era la idea que más nos convenció de las que barajamos. Terminamos decidiendo centrarnos únicamente en Spotify y su API, y a partir de ahí empezó la gestación de SpotyWhere.

El día antes hicimos algunos bocetos y wireframes, para intentar tener todos una idea lo más común posible de lo que iba a ser lo que íbamos a hacer y ponernos más o menos de acuerdo. Aunque al final las decisiones de la interfaz eran principalmente criterio de Fernando.

Para organizarnos y comunicarnos usamos varias herramientas: en una sala de HipChat procurábamos llevar el grueso de la comunicación, un poco de Skype para aclarar algunos puntos, Trello para gestionar nuestras historias de usuario y tareas, y un repositorio git privado en GitHub que ponía la organización.

La aplicación está desplegada en AppFog, que proponía de nuevo la organización, y decidimos utilizar MongoDB (en MongoHQ) como base de datos. Una base de datos documental encajaba bien con nuestras necesidades, además de permitir hacer búsquedas geo-espaciales (aunque ahora no las usamos) y el plugin de MongoDB GORM que lo deja muy facilón.

Decidimos habilitar el login/registro de usuarios con Facebook y Twitter, así dejábamos el registro más fácil a los usuarios y no teníamos que preocuparnos de montar todo el sistema de gestión de usuarios. Para esto y para la integración con la búsqueda de canciones de Spotify tiramos del plugin REST client facilities y HTTPBuilder.

Mientras que para la parte de front se usa Foundation, Google Maps junto a MarkerClusterer en los mapas y jQuery para algunos detalles de interacción.

Yo creo que nos quedó un resultado más que presentable, pero algunas mejoras y funcionalidades se tuvieron que quedar fuera. Cosas como un mapa en los perfiles de usuario o que pueda funcionar bien en terminales móviles son cosas bastante evidentes. También a nivel de código hay parches nada elegantes, como controladores con más código de la cuenta, no hay un miserable test, bastante javascript guarro y mezclado con el html... Lo típico en un hackathon de estas características, vamos :D.

En fin, el tema es que el domingo conseguimos terminar (no sin nervios en las últimas horas) y hicimos el despliegue, otro entregable era un video donde se explicara el proyecto. No había un tipo de video establecido, y el marrón recayó en Raúl, os lo dejo aquí :P.

Al final resultó que en el podio terminaron 3 equipos hispanos (2 españoles y 1 mexicano). Mientras que nosotros nos llevamos una de las 3 menciones especiales, cosa que no ha estado nada mal :).

Una cosa que también me llamó la atención es que, al parecer, la organización contaba (¿cuenta?) con mentores y partners que en su momento podrían ayudar de algún modo a evolucionar a algo más serio a los proyectos participantes.
Veremos si alguno de los proyectos lo hace, en nuestro caso no creo que tuviera sentido. No deja de ser un proyecto bonito y que puede ir creciendo, pero muy complicado de hacer algo monetizable alrededor, o ganar dinero con él, que decimos los de pueblo.

Bueno... siempre nos podría comprar spotify XD.

Últimamente estoy dándole vuelta a muchas cosas sobre mi situación profesional, sobre lo mucho que me he equivocado alrededor del último año y medio. Yo lo que quiero es dedicarme a producto propio y a ir participando en proyectos de terceros. Pero como he cometido demasiados errores en mis decisiones, estoy en un punto donde jamás quise estar

Pienso que mis principales errores han sido no haber acertado eligiendo a mis clientes, no haber gestionado bien nuestra relación, no ser tan exigente con ellos como procuro serlo conmigo y/o no haber sabido cortar con ellos a su debido momento. Y es que hay algo que tengo más que asumido, si tengo problemas con un cliente el principal responsable soy yo.

Esto me ha llevado a situaciones que a uno le apetecen poco a estas alturas del partido:

• Haber palmado pasta en un proyecto a un nivel indecente. Eso que tengo una sensación de que casi he invertido más dinero en el proyecto yo que el propio cliente.
• Cobrar por debajo de mi precio (que de por sí era excesivamente barato) como apuesta y compromiso personal en un par proyectos. Para que luego se terminasen desvaneciendo todas las promesas de futuro, por supuesto.
• Desarrollar un proyecto que ha acumulado una deuda técnica enorme por andar con prisas, debería haberme impuesto y parado el desarrollo hasta no haberlo renegociado y solucionado.
• Tener retrasos en pagos, cosa que además en una ocasión acepté en como mal aceptable durante una colaboración y finalmente tuve que asumir un impago durante varios meses.

Siendo un desarrollador que trabaja para sí mismo y que quiere ganarse bien la vida, haciendo las cosas lo mejor posible, trabajar en proyectos bonitos y colaborar con grandes profesionales; cosas como esas no me han dejado avanzar en proyectos propios y colaboraciones, además de hacerme pasar momentos duros y situaciones poco agradables.

Ahora es momento de recuperar esos pasos e ir más allá, estoy procurando retomar un camino que quiero que me lleve hacia donde realmente quiero. Para eso estoy procurando elegir mejor a mis clientes, empezar a gestionar mejor nuestra relación, ser más exigente con ellos a todos los niveles y, si es necesario, cortar mi colaboración si no se cumplen unos mínimos de respeto y entendimiento profesional.

En fin, espero que no se perciba simplemente como un post de lloriqueo o un pataleo, nada más lejos. Que también he trabajado en algunos proyectos chulos; además ahora tengo cositas interesantes entre manos y espero ir compartiendo evoluciones :)

Ayer me surgió un problema al hacer push a un repositorio remoto de git (en bitbucket). El tema es que el repositorio, además de para las gestión de versiones del código en sí; se va a empezar a utilizar para mantener versiones del .war de una aplicación Grails, donde se va a usar también un hook para actualizar y desplegar la aplicación a un entorno de preproducción.

Como resulta que git por defecto tiene un postBuffer de 1MB, y los .war pesan algo más de 40MB, me daba el siguiente error:

Error: RPC failed; result=22, HTTP code = 411

Para aumentar el postBuffer es tan sencillo como cambiar la configuración en el repositorio local:

git config http.postBuffer bytes

Donde bytes será el tamaño máximo de los que se permitirá hacer push.