Tatai from the trenches

Otro de mis pequeños proyectos

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.

¿Qué cliente de FTP usas?



Esta pregunta me ha hecho hoy Mr. Client*. Reconozco que no ha sido el primero pero supongo que tampoco será el último.

Mi primera respuesta es que mi religión me lo impide. Ya no recuerdo la última vez que usé FTP por cuenta propia. En caso de necesitar FTP siempre usaré SFTP y, si tengo acceso shell, SCP. No hay nada mejor que una consola y, si es posible, una sesión SSH.

Pero realmente no querí­a hablar de FTP, sino de clientes para estos servicios. No tengo nada en contra de ellos y si los usas me parece muy bien, pero voy a explicar porque tiendo a no usarlos si es que puedo cambiarlos por comandos en la consola o por acciones que pueda controlar directamente con el teclado. ¿Raro? ¿Arcaico? ¿Friki? Ni mucho menos, eficiente.

Y si el simple hecho de mover las manos entre el teclado y el ratón hace que seas más lento, podemos incluir el hecho de que para la mayorí­a de las acciones que tengas que hacer bastarí­a con repetir la misma acción (subir un fichero, copiar una carpeta, borrar un fichero, etc).

Ahí­ van un par de las preguntas más frecuentes:

«¿Y tienes que estar todo el rato conectándote? ¿Y la contraseña?»

Para esta pregunta, la solución está en este post en el que explica como crear un par de claves que te permita acceder al servidor de forma sencilla y segura.

La respuesta es sí­, pero es que conectarme al servidor es una cosa muy sencilla. Además, para configuraciones habituales o que requieran de muchos parámetros, siempre podemos «Tunear» un poco nuestro ssh 😉

«¿Y cuando tienes que subir varios ficheros?»

El tema se pone interesante. Depende del caso, desde el más sencillo usando wildcards:

scp *.log host:/var/log

O algo más complicado:

scp {script,config}.php host:/var/www

O siempre está la opción de hacernos un mini-script que suba varios ficheros, aunque recordemos que siempre que podamos hacerlo en la misma conexión, ganaremos tiempo.

«Vale, ¿y cuando tienes que subir muchos ficheros? ¿Y carpetas?»

Para las carpetas, nada como la opción -r que permite subir ficheros de forma recursiva, incluyendo directorios.

Cuando tienes que subir muchos ficheros, automatización con un script o incluso usar un tar.gz, subir y descomprimir. Si realmente tienes que trabajar con cambios en muchos ficheros en distintos sitios, la mejor opción serí­a rsync lanzado manualmente (hasta el momento, no me he encontrado con este caso, pero bueno, será por opciones).

O puedo asegurar que si os gusta la velocidad, lo primero es aprender a no usar el ratón (que no quiere decir que no lo uséis) y luego, a automatizar los trabajos repetitivos. Conseguiréis ser más rápidos, eficientes y, como no, aprenderéis más cosas.

Que no se me enfade nadie, cada uno es libre de usar las herramientas como quiera. Sólo he dado mi propuesta que, además, vale tanto para Linux, Windows o Mac.


*: cariñosamente para el post de hoy 😉

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 🙂

Quomai



Con este nombre, es como hemos bautizado a este nuevo proyecto y aventura en el que nos hemos metido. Quomai.

Logo de Quomai

Queremos que suene mucho y fuerte entre todos vosotros y estamos trabajando muy duro para que en breve veáis la idea en funcionamiento.

Y así­ para empezar… os gusta el nombre? Y el logo?

Stay tuned!

Estos son algunos de los sitios donde daremos guerra:

« Entradas anteriores