Otro de mis pequeños proyectos

Categoría: Varios (Página 1 de 6)

20 años de la Navarparty

Justo hoy hace 20 años que empezó la Navarparty. Y sinceramente, me apetece compartir alguna cosa con vosotros.

La primera edición, del 19 al 21 de septiembre de 2003 fue todo un hito en Pamplona y hay que reconocer que fue una locura, tanto para la gente que disfrutó como asistente como para los que tuvimos la suerte de poder organizarlo. Para los que no la conozcan, la Navarparty fue un evento ligado a la informática, los juegos y las nuevas tecnologías que celebrábamos en Pamplona en septiembre, organizado por una asociación sin ánimo de lucro. Durante 4 días (aunque la primera edición duró sólo 3) nos juntábamos para charlar de aficiones comunes, jugar a videojuegos, participar en las distintas competiciones y pasar muy buenos ratos. Aunque no queda mucha información por internet, podéis haceros una idea de este time-lapse

Tuve la suerte de ser uno de esos 12 pioneros que se lanzó a la aventura y permanecí en el proyecto durante las 10 ediciones que se llegaron a celebrar entre 2003 y 2012. Llevábamos varios años asistiendo a la que fue y ha sido siempre nuestra referencia, la Euskal Encounter (Euskal Party por aquel entonces) y queríamos que Pamplona tuviese algo parecido, para nuestra gente. Hay que reconocer que era duro, lo recuerdo con mucha satisfacción, pero eran muchos meses preparando y cerrando un evento que duraba poco más de 80 horas ininterrumpidas. La primera edición me tocó en quinto de carrera, lo que para mí le puso un punto más de «emoción» al asunto e incluso defendí mi proyecto fin de carrera dos días antes de que empezase la segunda edición.

Si bien los dos primeros años fueron de locura por la inexperiencia de todo el grupo, poco a poco fuimos mejorando. Hay que ponerse en situación, en 2003 la información llegaba por los medios tradicionales (prensa y radio principalmente) y mostrar este proyecto no era sencillo. Y si le unimos que lo hacían un grupo de chavales de veintantos años, tenemos que decir que costó bastante. Conseguir la primera edición ayudó mucho. Todavía recuerdo ese primer día de evento, con más nebulosas que claridad por las pocas horas dormidas y el trabajo de varios días cuando un gran amigo y referente para mí me dijo viendo el evento desde la grada «Fran, no sabéis lo que habéis hecho». En aquel momento no lo entendía porque yo venía de estar en la Euskal Encounter con más de 1500 asistentes y los 360 de aquel primer año (512 el resto de los años) sonaban a poco, pero con el tiempo lo entendí.

Con el tiempo ganamos en visibilidad y organización, más gente se incorporó a ayudarnos y contamos con una gran familia de asistentes que sólo lo ponían fácil en todos los aspectos.

Todo fue bastante bien año a año hasta que llegamos a la gran recesión que nos pegó de lleno. El evento se sostenía casi al 50% entre la venta de entradas y la aportación de patrocinadores y colaboradores y ambas cosas empezaron a bajar. El descenso fue tanto que para la que iba a ser nuestra décima edición, la de 2012, la ayuda se redujo a cero y estuvimos a punto de no tener evento. Pero en un último esfuerzo titánico por parte de todos, reduciendo al máximo los costes y tirando del remanente que guardábamos todos los años para imprevistos conseguimos sacarla adelante. Hay que reconocer que fue un inicio y un final duro, pero creo que es lo que le da un mayor valor.

Personalmente me gustaría agradecer a todos los compañeros que pasaron por la organización y a todos aquellos que confiaron en la Navarparty y prestaron su apoyo junto con toda la gente que vino al evento a participar, a las conferencias, a los talleres o simplemente a ver de qué se trataba. ¡Muchas gracias a todos!

P.D: aunque la Navarparty finalizó en 2012, desde 2018 podéis disfrutar en Pamplona de la Navarra LAN Party cuyo germen fue la Navarparty y estamos orgullosos de ello. Y no podemos olvidarnos de la Euskal Encounter que lleva ya 31 ediciones (a la que yo personalmente sigo asistiendo). ¡Larga vida a las parties!

Usando RSocket

Como comentaba cuando presenté PlanPok mi intención era aprender pero todavía más interesante es enfrentarse a problemas, resolverlos y poder enseñar. No hay mejor forma de entender las cosas que intentar explicarlas. Para este post me centro cómo tuve que configurar RSocket en la parte javascript para hacerlo funcionar.

¿Qué es RSocket?

RSocket es un protocolo binario para comunicación entre pares, en este caso entre un frontend web y un backend. En estos casos el canal de comunicación se establece y permanece abierto hasta que una de las partes lo cierra, permitiendo que cualquiera de los dos pueda enviar información en cualquier momento.

Hay 4 formas de interactuar:

  • Fire and forget: se envía un mensaje desde el cliente y no se espera respuesta
  • Request response: se envía un mensaje desde el cliente y el servidor envía respuesta
  • Request stream: el cliente envía un mensaje y se espera que lleguen mensajes asíncronos desde el servidor en algún momento
  • Request channel: se establece un intercambio continuo y asíncrono entre cliente y servidor

En mi caso lo utilicé en el proyecto porque me daba dos cosas que necesitaba, por un lado enrutar los mensajes al estilo API REST, es decir, definir endpoints en los que cada uno espera un mensaje concreto y por otro me permitía se completamente reactivo en la parte de backend con Spring Boot.

¿Es lo que debes usar? Depende. Hay más opciones, yo empecé probando WebSockets con STOMP pero no me permitía la parte reactiva y tuve que cambiar.

Inicializar la conexión

Voy a centrarme en esta parte porque fue la que me dio más dolor de cabeza por no entenderlo bien.

En primer lugar aviso que este código es para una versión 0.0.27 de RSocket. A día de hoy existe una versión 1.0.0 en alpha y este código no funciona, habrá que esperar a la versión estable para probarlo bien.

import {RSocketClient} from "rsocket-core";
import {IdentitySerializer, JsonSerializer} from "rsocket-core/build/RSocketSerialization";
import RSocketWebSocketClient from "rsocket-websocket-client";

const metadataRoute = (route) => {
  return String.fromCharCode(route.length) + route;
};

const createClient = url => {
  return new RSocketClient({
    transport: new RSocketWebSocketClient({url})
    serializers: {
      metadata: IdentitySerializer,
      data: JsonSerializer
    },
    setup: {
      keepAlive: 60000,
      lifetime: 180000,
      dataMimeType: 'application/json',
      metadataMimeType: 'message/x.rsocket.routing.v0',
      payload: {
        metadata: metadataRoute('setup'),
        data: {/* your data */}
      }
    }
  });
}

const connect = (url, callback) => {
  createClient(url)
    .connect()
    .subscribe(callback);
  };

export {connect}

Con este módulo podremos establecer una conexión contra el servidor y entonces realizar cualquiera de las cuatro formas de comunicación que he descrito antes. Pero veamos para qué sirve cada cosa.

connect recibe dos parámetros:

  • url que apunta al servidor
  • callback un objeto para implementar dos posibles acciones: onSuccess y onError que contienen la respuesta cuando la conexión se ha podido realizar y cuando ha fallado respectivamente

Así por ejemplo:

import {create} from "socket";

create("wss://ws.planpok.com", {
  onSuccess: successMessage => /* connection established */,
  onError: errorMessage => /* cannot connect */
});

Ya está lo fácil, ahora veamos cómo se ha creado la conexión y qué pasos hemos dado.

La llamada a createClient devuelve una instancia de RSocketClient cuyo constructor tiene tres opciones:

  • transport: cliente usado para transportar la información, usaremos RSocketTcpClient o RSocketWebSocketClient. La diferencia es que en el primero se usa una conexión TCP en plano mientras que en la segunda no. En caso de querer usar un navegador web, no queda otra que usar la opción de websocket porque TCP no la soportan
  • serializers: qué conversión hay que realizar a los datos (data) y a los metadatos (metadata). En caso de no querer enviarla tal y como se genera usaremos IdentitySerializer mientras que si queremos convertirla en JSON usaremos JsonSerializer
  • setup: más parámetros para configurar:
    • keepAlive: establece el tiempo que debe pasar entre cada llamada que envía un paquete destinado a mantener la conexión abierta, en milisegundos
    • lifetime: tiempo máximo de vida de la conexión, en milisegundos
    • dataMimeType: mime-type del contenido de los mensajes que se envían. Tener siempre en cuenta lo que se ha indicado en serializers
    • metadataMimeType: mime-type de la cabecera de los mensajes. En el caso de usar enrutado debemos indicar message/x.rsocket.routing.v0
    • payload: mensaje enviado en la conexión, si se necesita

Ahora que espero que esté un poco más claro, contaré donde me enfrasqué yo de forma bastante tonta.

Lo primero es la forma en la que se envíalos metadatos. Es sencillo, por cada elemento se enviará primero un char con el tamaño de bytes y seguidamente el contenido. En caso de tener más de un elemento es cuestión de repetir la misma estructura: tamaño+contenido, tamaño+contenido, etc

Por lo tanto, cada elemento de metadata tiene un tamaño máximo de 255 bytes. En metadataRoute se puede ver este código.

Como he indicado que el mime-type de metadata es message/x.rsocket.routing.v0 eso quiere decir que voy a enrutar los mensajes, es decir, voy a indicar para cada mensaje una ruta que podríamos hacer la equivalencia al path en una petición REST y esta información tiene que enviarse de forma plana como he indicado antes. Bien, cometí un error en la definición del serializador de metadata y en vez de usar IdentitySerializer usé JsonSerializer, lo que hacía que en destino no se entendiese esta información.

No comentáis el mismo error que yo. En mi favor diré que aprendí bastante leyendo el protocolo para intentar entender cómo funcionaba y dónde estaba cometiendo el error, pero en retrospectiva diré que no hace falta llegar tan lejos para poder usarlo.

BurndownGenerator, un vistazo atrás

Aprovechando que el pasado viernes hacía público PlanPok, caí en la cuenta que en abril de 2010, ¡hace casi 13 años! puse en marcha BurndownGenerator. Este post en este blog recuerda el momento.

Recuerdo que quise programarlo porque por aquel entonces practicábamos scrum en analógico y el burndown lo dibujaba yo, no era mucho trabajo pero fue más gratificante conseguir hacer una web que lo generase y además me permitiese parametrizarlo. Y recientemente había descubierto TDD y necesitaba probarlo, tenía todos los ingredientes.

Pero volvamos al origen del post y es que hace unos días recordé que se guarda un registro de los burndowns generados para obtener algo de información sobre su uso y si realmente utilizaba la parametrización y valía la pena cambiar algo o si le daba igual.

Mi primera gran (grandísima) sorpresa fue ver que desde el día 11 de abril de 2010 cuando lo puse en marcha, a día de hoy se han generado 190.000 gráficos. Para que nos hagamos una idea, eso son más de 1.200 de media al mes. Reconozco que dije que tenía que haber algo mal o que algún bot o script estaría haciendo de las suyas. Así que me puse a analizar un poco los datos y llegó mi segunda sorpresa cuando hice esta gráfica:

Gráficos generados por mes

No fui consciente de este crecimiento y es una pena, pero bueno, nunca es tarde.

Había cosas que tenían sentido. Para empezar son años de crecimiento de scrum y si bien es verdad que siempre han existido herramientas para llevar toda la gestión y automatizar el proceso, en muchos casos con unos pocos post-it y este gráfico tienes lo principal para una daily presencial.

También tiene sentido el brusco descenso a inicios de 2020. Maldita pandemia qué daño hizo y sigue haciendo, pero en este caso el hecho de trabajar más en remoto y reducir la presencialidad también hace que la cantidad de gráficos que se generen baje, tiene lógica.

Ahora bien, ¿por qué la tendencia no es estable y tenemos momentos de mínimos tan abruptos? Una vez más revisé los datos y antes de dar la solución, pondré este otro gráfico:

Gráficos generados por semana

Ahora ya se ve más claro, los mínimos relativos se dan en diciembre-enero de cada año. Es más, también se ve otros mínimos aunque no tan claros en julio-agosto. Así que parece que no había nada mal, épocas con menos generaciones. ¿Vacaciones? ¿Iteraciones más largas? Quien sabe…

Y ya por último y como curiosidad, ¿cuándo se generaban las gráficas a lo largo de una semana? Esto es entre 2017 y 2019 inclusive

Visitas agregadas por hora y día de la semana

Y eso es todo lo que me apetecía contar. La verdad es que espero poder ponerlo al día en algún momento, sobre todo la parte visual en la que bien es sabido que tengo poca mano, pero al menos seguro que saldrá algo mejor y adaptable que lo que hay ahora.

PlanPok

Para retomar un poco blog que había caído en el olvido, traigo este pequeño proyecto que acabo de poner en marcha y se llama PlanPok.

Lo que permite PlanPok es poder realizar estimaciones por varias personas de forma distribuida. La mecánica es sencilla, hay una persona que crea una sala y es la que puede moderar cuándo se realiza una nueva votación o cuando se muestran los votos.

Pagina inicial

El resto de personas pueden unirse a la sala mediante la URL y votar. Todo de forma anónima.

Página de estimación

Sin registro, sin datos personales y sin publicidad (al menos de momento, no prometo nada).

Es totalmente gratuito, así que te invito a que pases y lo pruebes. Encantado de recibir comentarios y críticas constructivas; y por supuesto abierto a sugerencias. Tiene cuenta propia de Twitter pero también me podéis buscar directamente por la red.

Un poco de historia

PlanPok nace de querer aprender y ensayar algunas tecnologías y prácticas. Llevaba un tiempo dándole vueltas a hacer algún proyecto que no me llevase mucho tiempo, un MVP que pudiese evolucionar si me apetecía luego. Mi objetivo empezó siendo:

  • Sockets para la comunicación entre front y back. Algo en tiempo real
  • Código en back fuese totalmente reactivo
  • Front totalmente separado de back

Casualidades de la vida en el proyecto en el que estoy trabajando desde hace un tiempo con un equipo distribuido, usamos una web para las estimaciones de las tareas y hace unos meses empezó a no funcionar muy bien. Cuadraba muy bien con lo que estaba buscando y además le podíamos sacar partido directamente.

Y así lo hice aprovechando unos días de vacaciones del pasado diciembre, en ratos libres después de disfrutar con la familia.

Seguidamente comentaré alguna de las decisiones, pero finalmente he usado:

Comunicación mediante sockets

Tengo que decir que con esta parte es con la que más vueltas di. Leyendo e informándome sobre tecnologías me pareció adecuado usar websockets con STOMP. Me permitía trabajar de forma similar a una API REST, enrutado mensajes y contenido serializable. Primeras pruebas de concepto de comunicación entre front y back sin problemas hasta que llego a la parte de hacerlo reactivo con Spring websocket: no hay forma.

Así que busqué alternativas y encontré RSocket. Tengo que decir que la integración fue sencilla excepto por una cosa: la configuración del enrutado en javascript. En retrospectiva diré que fue una chorrada por no entender bien cómo hacerlo, pero bueno, que hasta llegué a leer los paquetes con Wireshark. Dejo la anécdota para otro momento que el post ya se está alargando y queda todavía.

Código en back reactivo

Era una asignatura pendiente que quería explorar algún día desde que probamos ciertos desarrollos y leí sobre ello. Creo que Java no es el mejor lenguaje para esto, tiene un soporte bastante decente pero a veces hace las cosas difíciles. Elegí Java porque quería al menos un punto de apoyo conocido y poder centrarme en reactor; a día de hoy me encuentro más cómodo.

El cambio a programación reactiva fue duro pero gratificante en ciertos aspectos. Duro porque es un paradigma que es realmente distinto de la programación imperativa. En cierta forma me recuerda cuando aprendí la inversión de dependencias y empecé a usar TDD, hay que seguir unas buenas prácticas, pero tienes que amueblar bien la cabeza para que no se convierta en algo infumable cuando empiezas a hacer piezas un poco más complicadas de lo habitual.

Los ejemplos sencillos son fáciles de seguir: recuperar datos, transformarlos, iterarlos y generar un resultado está bien, pero nada más que empiezas a necesitar otras herramientas como bifurcaciones o control de errores empiezas a hiperventilar como Sheldon Cooper. He pasado buenos ratos revisando la extensa API intentando entender los conceptos y elegir las opciones más correctas.

Mención especial a Redis, no por el propio Redis que quien me conoce sabe que me gusta mucho, en su justa medida, sino en lo que me costó configurarlo bien en la parte de la suscripción del pub/sub y en la se cancelaba una suscripción (unsubscribe). Da para otro post, pero este fue el problema. Tuve que separar las conexiones y posteriormente borrarlas a mano, no me gustó, pero no encontré mejor forma, espero encontrarla algún día.

Front independiente de back

Quizás pueda sonar de perogrullo a día de hoy sobre todo pensando que tiene que existir comunicación entre ambos, pero tenemos que pensar que para un pequeño proyecto como este o un MVP no es una necesidad, lo hice porque quería recordar lo poco que sé de React o probar Vue.js. Finalmente me quedé con el segundo porque es lo que usamos en el proyecto en el que me encuentro trabajando ahora mismo, así que quizás podría servirme en el corto plazo.

Conclusión

Ahora mismo estoy contento con el stack elegido. No es porque sea mejor o peor sino porque satisface las necesidades que tengo en el proyecto a día de hoy y he cumplido mi objetivo de aprender un poco más, que para mí era lo principal.

Espero que ir evolucionando con nuevas ideas. Espero también que te sirva y aprovecha que es gratis. Y si crees que es útil y que lo merece, siempre puedes invitarme a un café. Recuerda que un programador es un organismo que convierte café en código 😉

Cambios



La verdad es que hace mucho tiempo que no me pasaba por aquí­ a escribir. Y se dice pronto pero han sido 6 años desde la última entrada pero realmente hay que decir que son más de 10 desde que lo hací­a con cierta frecuencia.

Y reconozco que me ha hecho gracia volver a leerme a mí­ mismo después de tantos años y ver como te reconoces en esos textos, en las expresiones… pero sin embargo te das cuenta de cómo has cambiado. ¡Pero es que no son pocas las cosas que han ocurrido estos años!

Me he planteado volver a escribir, algún post de vez en cuando contando esas cosas que aprendo, que para eso creé este blog, para contar cosas que pudiesen ser útiles (aunque más de una vez se me ha ido de las manos).
Una de las primeras cosas que he pensado ha sido así­ empezar de cero borrando todas las entradas hasta la fecha o al menos hacer una selección. Y quizás algún dí­a lo haga para eliminar lo que no tiene sentido que siga por ahí­, quién sabe, pero de momento, se quedan.

Y como por algún sitio habí­a que empezar me he dedicado a sacar la fregona y adecentar esto un poco, alguna que otra actualización pendiente y cambio de look.

Dropcoin



Hace unos dí­as decidí­ probar Dropcoin en este blog. Por si todaví­a no la conoces, esta nueva plataforma permite a creadores de contenido recibir micro-donaciones (10, 25, 50 céntimos, 1 y 2 euros) por parte de cualquier persona. Puedes ver el botón de Dropcoin a la derecha de este texto. Y el proceso es sencillo y simple, sin perder seguridad, tanto para poner el botón en una web como para poder realizar donaciones.

Vamos a repasar un poco qué es lo que tenemos a dí­a de hoy.

Cómo realizar una donación

Simplemente tienes que buscar la «pastilla» de Dropcoin que tiene un aspecto similar a este (atento, que este no funciona, el bueno está arriba a la derecha):

Dropcoin-Boton.dropcoin

Cuando pasas el ratón por encima verás que el texto «dropcoin» cambiará por unas monedas; son las posibles donaciones que puedes hacer.

Dropcoin-Boton.selectedSi haces click en cualquiera de ellas iniciarás el proceso de donación y varí­a un poco en función de si tienes cuenta o no (lo que inevitablemente lleva a un registro) y si es la primera vez que donas, ya que si es así­ tendrás que indicar los datos de tu tarjeta.

Pero donde empieza la magia es si ya tienes cuenta en Dropcoin y has configurado todo anteriormente, ya que podrás dar esos 0.10, 0.25, 0.50, 1 ó 2 euros de forma muy sencilla, agradeciendo al autor su labor.

Cómo poner Dropcoin en tu web

Lo primero que debes saber a dí­a de hoy es que Dropcoin acepta páginas en las que se crea contenido y debes de pasar un proceso de validación. Si cumples las condiciones, recibirás un correo informándote que has sido aceptado y te indicarán dos cosas: el acceso a tu panel de gestión y unas sencillas instrucciones que constan de un código javascript y trozo HTML configurable que debes colocar donde quieres que aparezca el botón. No te llevará más de 5 minutos.

En resumen

Creo que es una excelente herramienta para ayudar a la gente que realmente crea contenido que te parezca útil. Piénsalo bien, la próxima vez que veas un botón de Dropcoin en algún contenido que te haya servido: ¿has encontrando la solución que buscabas en ese post concreto? ¿cuánto tiempo has podido ahorrar ? ¿ha aclarado tus dudas? ¿crees que merece un premio? Te aseguro que algo le alegrarás el dí­as invitándole a un café (o medio) ví­a Dropcoin porque así­ sabrás que has valorado su esfuerzo.

Retomando las buenas costumbres



Parece mentira, pero desde mi último post ha pasado ya 1 año y 8 meses. Demasiado tiempo.

Va a sonar a excusa, pero la realidad ha sido que durante todo este tiempo no he parado. He tenido muchas ideas para escribir posts, pero siempre habí­a algo «más importante» que hací­a que lo postergase. Pero quiero volver a escribir, aunque sea de vez en cuando, porque siempre hay cosas interesantes que contar.

Y para poner al dí­a rapidamente, «pequeño» resumen, que han pasado muchas cosas.

  • Quomai nació y sigue adelante. Somos ya un equipo de 6 personas más varios colaboradores externos. Tenemos una gran aplicación nativa para Android y iPhone, miles de usuarios y un sistema muy potente que permite crear clubs de fidelización para pequeñas, medianas y grades empresas… pero esto da para otro post (¡o varios!)
  • Kukers vio la luz y ahora es una de las comunidades más importantes de recetas de cocina en español.
  • He aprendido a programar para Android (Java) y iPhone (Objetive-C), algo que llevaba mucho tiempo queriendo hacer.
  • He dado un curso formativo de Android a una empresa y he dado un taller sobre programación en Android durante la Navarparty 9.
  • He alcanzado un nivel de conocimiento de symfony 1.4 muy interesante. Cameos con symfony 2, aunque de momento poca cosa.
  • Dejé de ser asociado en la Universidad Pública de Navarra en el verano de 2011 y he sacado de nuevo la plaza en septiembre de 2012, retomando las clases con otras asignaturas distintas.
  • He cumplido, por fin, mi promesa de emancipar todos esos kilos que sobraban. Un total de 20 (quizás alguno más) en casi 3 años desde que me lo tomé en serio, aunque siempre sin esfuerzos, sin dietas… con tranquilidad, cabeza y algo de vida más sana.
  • Soy capaz de correr 10km en menos de una hora, algo impensable hasta hace casi un año. He participado en la San Silvestre de Pamplona (5km – 2011.12.31), Hiru Herri (10km – 2012.04.22) y Cross 3 playas (10km – 2012.10.14). Ahora mismo estoy preparando la Behobia-San Sebastián de 20km que se celebrará en 3 semanas.
  • He sobrevivido a la Navarparty 9 y a la Navarparty 10. Sobre todo a esta segunda que ha supuesto muchí­simo esfuerzo a nivel personal. Con los tiempos que corren, hemos sufrido un recorte casi total de las subvenciones. Gracias a un montón de buenos amigos y colaboradores que se han volcado con nosotros, hemos conseguido que estas dos ediciones salgan adelante con muy buenos resultados pese a la austeridad.
  • He vuelto a bailar para el aniversario de Harizti. Sagardantza y Paloteau de Cortes.
  • Me he aficionado a la (buena) cerveza, principalmente a la belga tras la visita a aquel paí­s durante la primera semana de Julio de 2012.
  • Un par de nuevos proyectos que os contaré en breve.

Y seguro que se me olvidan cosas.

Pero bueno, ya estoy de vuelta 🙂

Repaso del 2010



Al igual que hice el año pasado, voy a repasar los objetivos que me puse para el ya pasado año 2010. Para no repetir la lista entera, voy a repasar directamente los resultados comentándolos posteriormente.

  • A fecha 1 de enero de 2011 tení­a casi (por muy poco) 6700 tweets
    • Ha desaparecido el «Buenos dí­as»
    • Cumplido: 100%
  • Durante 2010 he escrito 37 posts
    • Cumplido: 30%
  • En el perí­odo 01/10 – 31/12, el blog ha tenido:
    • +42,19% visitas
    • +27,39% páginas vistas
    • Cumplido: 100%
  • He leí­do 3 libros
    • Comentarios para después
  • Android/iOS:
    • He realizado dos aplicaciones sencillas para Android (una de uso personal y otra sin publicar)
    • Poco a destacar de iOS y Objetive-C
  • La emisora sigue teniendo poco uso
  • Este año no he desconectado como el pasado, pero he sabido distanciarme cuando era necesario.

Este año la lista ha sido larga, pero voy a hacer unos cuantos comentarios que creo que son justos ya que mi cabeza es de ingeniero y por un lado está el lado cientí­fico, el de las cifras que me van a dar datos objetivos sobre los resultados (seguro?) pero también está el racional que me hace pensar las cosas y llevarlas un poco más allá.

Más allá de la cantidad de tweets de este año, que realmente han sido muchos (casi el 60% de total de tweets que tengo) valoro muy positivamente donde me ha llevado esta red social que es la que más uso. He conocido a mucha gente, he podido desvirtualizar a unos cuantos (muchos menos de lo que me gustarí­a) y, lo que es más importante, ha sido uno de los métodos por los que más he podido aprender, no sólo por la cantidad de información que puedes recibir, sino del feedback que consigues cuando tu das la información. Ayuda a sintetizar las frases ya que son 140 caracteres e incluso he establecido reuniones y encuentros mediante esta ví­a, algo que me parece fantástico.

Este año la verdad es que he posteado muy poco comparado con el objetivo que me puse, pero no por ello estoy descontento. Creo que he aumentado mucho la calidad y me he centrado en temas como vim, git, PHPConference y algunos de mis desarrollos como Burndowngenerator.com, Equation (con el July Innovation Award de PHPClasses incluí­do), Matrix, symfony autocompleter, etc. Y bueno, como colofón, uno de mis posts ha aparecido en meneame.net que, aunque no haya alcanzado portada, la verdad es que me ha hecho ilusión.

El tema de la lectura, con las cifras que se ven, la verdad es que parece que no he hecho mucho este año. Y la verdad es que podí­a haber hecho más, eso sin dudarlo. He leí­do 3 libros de los 5 que me propuse, pero he aprendido que esta medida, si realmente quiero saber si he leí­do más o menos, no es válida ya que debo fijarme en una medida con mayor relevancia, como por ejemplo el número de páginas. Y para hacernos una idea, este año 2010, comparado con 2009 en número de páginas, he leí­do +2,5 veces más. ¿Por qué? Pues está claro, porque eran libros «más gordos» 😉

En concreto, me he leí­do los 3 primeros libros de la saga de Eragon: Eragon, Eldest y Brisingr (a la espera de que el autor saque por fin el cuarto libro). Y, ya que en la métrica establecida no podí­a contar, he empezado con el primer libro de la saga La brújula dorada que es con el que me encuentro actualmente y que contará de cara al año que viene.

Y bueno, este creo que es todo el repaso.

Ahora me queda terminar de fijar los de este año, que creo que van a ser mucho más interesantes 🙂

Un pequeño giro… para emprender!



Suelen decir que la vida da muchas vueltas. Y tienen razón.

Coincidiendo con mi cambio de década (acabo de cumplir los 30) y como regalo de Reyes, he decidido que el próximo 7 de enero me lanzo a la aventura de emprender. No ha sido una decisión fácil, hay que dejar muchas buenas cosas atrás, pero es algo que me llama desde hace algún tiempo y lo cojo con mucha ilusión.

Han sido más de 5 años y medio los que he dedicado a aprender y a crecer profesionalmente dentro de Biko (y New Media Publishing en sus primero pasos antes de la fusión con SPI Navarra Virtual). Siempre estaré agradecido a Biko y a todas las personas que forman y han formado parte de ella ya que me ha permitido llegar hasta donde estoy hoy en dí­a. Todaví­a recuerdo con cariño mi entrevista con Diego Cenzano, Diego Fernández y Patxi Echarte antes de formar parte de esta gran familia que se estaba gestando.

No puedo dejar de agradecer a todos mis compañeros todas esas horas que hemos pasado juntos y todo lo que hemos aprendido. Me quedo en especial con los buenos momentos, que han sido muchos y de lo más variados, y de los malos me quedo con la lección aprendida, porque siempre hay que mirar hacia adelante. Sois grandes profesionales de los que he aprendido mucho, muchí­simo y esta es una marca imborrable que se queda conmigo.

Pero creo que ha llegado una buena oportunidad en un momento en el que me puedo permitir esta aventura. Voy a seguir aprendiendo, mi motivación principal. Ya no sólo de temas técnicos (que me siguen encantando), sino también en otras facetas que llevo «cortejando» algún tiempo.

Me toca a mi ahora dar el paso y lanzarme a esta nueva e ilusionante aventura. Os tendré informados es este, mi blog personal y también por twitter.

Gracias a todos los que habéis mostrado vuestro apoyo, significan mucho para mí­.

« Entradas anteriores