Blog

Blockchain fácil fácil

Ya son varias las personas de distinto ámbito que me han pedido una explicación sencilla de lo que es Blockchain, así que supongo que es un tema que debo plasmar aquí, y dejar de contarlo entre cervezas. Voy a intentar que cualquier persona con una base técnica mínima pueda entenderlo, pero ante las dudas preguntad en los comentarios 😉

blockchain photo
Photo by btckeychain ©

Blockchain, como su propio nombre indica, es una cadena de bloques. En cada bloque se almacena una información y el hash del bloque anterior (¿os acordáis de la explicación sobre lo que es un hash de la semana pasada?).

De este modo, al almacenar cada bloque la «firma» del anterior, si se cambiase el contenido de un bloque se alteraría esa firma, con lo que habría que cambiar el contenido del siguiente bloque, y así sucesivamente hasta llegar al bloque más actual.

Eso, así de simple es un blockchain.

Ahora bien, seguro que habéis oído que este sistema se está usando en criptomonedas y en otras soluciones porque se supone que no se puede alterar los bloques ¿no?

En un blockchain que se almacenase en un solo lugar sería «trivial» alterar el contenido de un bloque random. Sin embargo, todos los sistemas que se están basando en esto son sistemas distribuidos, en los que hay muchos participantes que mantienen una copia de toda la cadena de bloques, por lo que para poder alterarla sin que todo el mundo se de cuenta, no sólo habría que modificar todos los bloques que maneje una máquina, si no que habría que hacerlo en todas las máquinas que almacenan una copia.

Vamos a poner un ejemplo práctico aplicado a algo que muchos habréis sufrido:

  • Imaginemos que tenemos un cuaderno en el que vamos a apuntar el acta de las reuniones de una comunidad de vecinos.
  • Para que no haya alteraciones, decidiremos que cada página tiene que empezar siempre con el «hash» de la página anterior.
  • El hash en este caso (para que sea fácil de calcular a mano), estará formado por la primera y última letra de cada fila y entre ambas el número de caracteres.
  • De este modo, si cambiásemos una página cambiaríamos su hash, que al ser la primera línea de la página siguiente, nos provocaría también cambiar su hash, etc. etc.
  • Un presidente maquiavélico podría comprarse un nuevo cuaderno para cambiar todas las actas y plasmar que a él se le eligió de por vida. Pero, si todos los propietarios tuviesen una copia del cuaderno, el presidente no podría hacerlo a no ser que pudiese entrar en todas las casas de todos los vecinos a pegar el cambiazo por un cuaderno modificado.

¿Queda claro?

Las aplicaciones de esto pueden ser muchas, aunque generalmente se usa para crear soluciones que eliminen intermediarios.

Por ejemplo, es la base de Bitcoin, la primera criptomoneda que se creo para poder hacer micropagos. El problema de los micropagos, era que al tener a los bancos como entidades intermediarias, las comisiones hacían imposible realizar estos micropagos. Al eliminar los intermediarios, los pagos pueden ser gratuitos, y hacerlos tan pequeños como se quiera.

Esa es la teoría, porque Bitcoin se ha expandido mucho por otros motivos derivados de la eliminación de intermediarios (anonimato, capacidad de especulación desmesurada, acceso universal, …), pero eso ya es otra historia que tendrá que ser contada en otro momento.

Explicación fácil de lo que es un «hash»

Si nos pusiéramos muy técnicos tendríamos que hablar de qué y cómo son las funciones hash, pero no es el día. Saber que son los hash es necesario si queremos hablar de Blockchain, de BigData, y de muchas otras moderneces con propiedad. Pero no es necesario entrar en detalles ni ponerse muy técnico para entender lo que son y como se usan. Vamos pues.

byte photo

Aquí ya hablamos de las tablas Hash, que son un patrón de diseño de sistemas distribuidos. Pero más allá de eso se usan en montones de estructuras de datos, de algoritmos y demás.

El hash es como se llama coloquialmente al resultado de una función hash, y estas son funciones que se encargan de transformar un conjunto de datos en una simple cadena de texto. Digamos que el hash es como una firma que resume a todo un conjunto de datos.

Por ejemplo, imaginemos que yo tengo un boli Bic azul comprado ayer mismo. Su hash podría ser (por ejemplo, el proporcionado por una función recién ejecutada en mi mente) BBA20170703005301058. Si aplicásemos la misma función a cualquier otro boli nos daría un valor distinto y si se la volviésemos a aplicar a ese mismo boli nos volvería a dar este valor.

¿Y esto para que sirve? Por ejemplo, si algún malvado villano me escondiese mi boli entre un millón de otros bolis similares (todos Bic azul), sólo tendría que aplicar esta función a cada boli hasta encontrar el que tiene esa firma para saber que es el mío. Otra función sería, si castigásemos a nuestro villano favorito a ordenar todos los bolis en un gran almacen, este podría ir apuntando la firma de cada boli con la estantería en la que lo guarda para luego poder encontrarlos de un modo rápido y fácil.

Estas, a bote pronto, son las funciones principales que se me ocurren (demostrar autenticidad y conseguir indexación), pero es muy posible que se usen estos códigos en muchos otros ámbitos que a mi ahora no me vienen a la cabeza. ¿Tenéis vosotros en mente otros ejemplos?

Lo normal, es que este tipo de funciones tengan en cuenta todo el conjunto de datos, o todas las características del objeto sobre el que se aplica, de tal modo que si el villano hubiese sido tan perverso de cambiar el capuchón de mi boli por el de otro, habría conseguido vencerme, pues la función hash que yo había ideado ya no proporcionaría el mismo valor.

Depende de para que se use, podemos encontrarnos con problemas, ya que puede ocurrir que haya colisiones y que, por una alineación de los astros, para dos objetos distintos se obtenga el mismo hash.

Sin embargo, a pesar de esas posibles colisiones, al ser (normalmente) el resultado de un algoritmo de compresión con pérdida, de un hash no se puede obtener el objeto original invirtiendo la función, así que será muy difícil encontrar para un hash un objeto o conjunto de datos válido que pueda sustituir al original como auténtico sin serlo. Esta es la clave, por ejemplo, de su uso dentro de los blockchains, pero eso ya es otra historia que deberá ser contada en otro momento.

Cómo crear un equipo tecnológico desde cero

No, no hablamos de montar un PC. Montar un equipo técnico tiene muchas complicaciones, muchos pequeños logros que conseguir para que todo funcione como los engranajes de un reloj suizo. Lo he tenido que hacer en diferentes ocasiones, la última en eldiario.es en donde monté un equipo para desempeñar tareas de desarrollo, data scientist y UX research de un proyecto avalado por Google. Aquí tenéis los pasos que creo que hay que dar:

  1. Definir claramente para qué se quiere montar el equipo. Si es para un proyecto concreto que empieza y acaba, si es para mantener algo que ya existe, si es para hacer I+D, … cada cosa requiere unas aptitudes y actitudes distintas. No puedes poner a alguien superinnovador a realizar mantenimiento de un software, ni a alguien que sea muy poco flexible a hacer I+D pululando por proyectos y tecnologías.
  2. Buscar un match entre requisitos/necesidades, dinero y tiempo. Cuanto menos tiempo, gente más senior necesitas, que también cobrarán más. Si tienes poco de ambos, tendrás que reducir los requisitos al mínimo aceptable, para que encajen todas las piezas.
  3. Hacer prospección del mercado de empleo para ver que tipos de perfiles puedes conseguir que sean lo mejor posible para llevar a cabo los requisitos dentro de tu presupuesto. Puedes, por ejemplo, buscar en Infojobs ofertas similares a ver que ofrecen, aunque desgraciadamente la gente no detalla demasiado las condiciones en las ofertas. Otra opción es buscar algunas personas que te puedan encajar en LinkedIn y preguntarles si podrían tener interés y cuales son sus condiciones actuales.
  4. Elegir el stack tecnológico. En realidad esta es una tarea que irá realizándose paralelamente a los puntos 1, 2 y 3, puesto que irán surgiendo detalles que marquen el stack a emplear. El proyecto es el que debería de marcar la tecnología (ya quedamos que «nos la suda» la tecnología ¿no?), ya sea porque hay una que reduce el tiempo sustancialmente, u otra en la que los desarrolladores son más baratos y encajan mejor en el presupuesto. Cualquiera que sean las motivaciones serán buenas, siempre que estas no sean usar el mismo martillo de toda la vida porque es lo único que conoces. Eso es sólo un buen motivo cuando se tiene un empate técnico, o cuando hay un gran riesgo de que el equipo se desmiembre y que tengas que hacer, a parte de tus tareas de gestión, las tareas de desarrollo para garantizar que todo tira para delante.
  5. Iterar. Hay que iterar entre los pasos previos tantas veces como sea necesario hasta que se tenga un match perfecto. En el que sepas que vas a poder cubrir todas los requisitos con el mejor equipo que te puedes permitir en el tiempo que tengas. Tienes que identificar qué perfiles necesitas, qué condiciones podrás darles, qué cosas son importantes y qué cosas no lo son realmente.
  6. Caza. Es el momento de buscar a los mejores candidatos, tal vez ya tengas alguno de cuando hiciste la prospección, pero necesitas más ¡no hay proceso de selección si sólo hay un candidato! Si tienes tiempo, puedes dejar una oferta en Infojobs o LinkedIn, en plan trampero y sentarte a esperar. Yo nunca lo he tenido, y confío más en las tácticas más activas, aunque las otras puedan ser un gran apoyo.
    • Si pones una oferta, tomate el tiempo de poner alguna preguntilla para cribar y que no entre todo. Tampoco te pases de difícil, la mayoría de la gente no se tomará tiempo de hacer algo que le lleve trabajo o pensar más de 30 segundos. Si no pones alguna pregunta para cribar, te entrarán 200 o 300 curriculums en las dos primeras horas y te servirá de muy poco.
    • Si pones una oferta en algún portal de empleo, úsala. Puedes usarla como campo base, redirigir ahí todo el tráfico, aprovechar las herramientas que te proporciona para filtrar y realizar la selección de un modo más sencillo. No tiene ningún sentido que pongas una oferta en un Infojobs, y en otro sitio pongas un correo para que manden el CV, y en otro digas que te manden un mensaje directo. Te has gastado las perras en ese portal, aprovéchalo.
    • Si no pones una oferta, publica un post, un pdf o lo que quieras, pero ten un sitio al que mandar a la gente donde esté toda la información. Habla del trabajo que se va a realizar, de los requisitos que sean indispensables y separalos muy bien de las cosas que serían un extra. Habla de las condiciones, de todas, que no todo el mundo se mueve por dinero. Del proyecto. Yo soy partidario de poner el salario que se pretende pagar, aunque si la política de la empresa no te deja, pon al menos un rango si eso sí te lo permiten.
    • Sal a buscar candidatos, LinkedIn es un sitio dónde se pueden encontrar muchos tipos de perfiles, aunque tal vez busques algo tan específico que te tengas que ir a algún otro lado, ¿tal vez un grupo de meetup? Averigua a que eventos acuden los candidatos del tipo que quieres y ve tu también.
  7. Lee a todos y contesta a todos. La gente se ha molestado en enviarte el curriculum, creo que es ético que te tomes la molestia de leer sus cartas de presentación y leer sus curriculums y contestarles para que sepan que lo has recibido. Sí, aunque te vaya a suponer salir un par de días a las 12 de la noche. Aunque no te aporte a tu negocio, sí. Es ético y educado, seguro que tú también has mandado curriculums y te ha gustado que mostraran un mínimo interés.
  8. Entrevista telefónica. Es muy complicado quedar con mucha gente, pero hacer una llamada de 15-30 minutos es más fácil. Prepárate una lista de cosas que quieres saber antes de colgar. A ser posible ten alguna pregunta técnica preparada, no tiene porque ser complicada, pero algo con lo que puedas validar que tu interlocutor sabe de lo que habla. ¿Que tú no sabes? No hay problema, pídele a alguien que conozcas que te explique algún tema básico de ese área, o léelo, la Wikipedia está ahí para todos gracias a las donaciones que pide Jimmy Wales. No necesitas ser un master (para eso vas a contratar a uno), sólo seguir la conversación, y créeme, cuando hables sobre un tema con 20, 30 o 40 personas distintas, sabrás suficiente para saber quien controla y quien no. Es importante que estés atento para distinguir a quien no sabe de quien tiene problemas de comunicación (pasa mucho en el mundo técnico), ya que te puede hacer perder un gran candidato. También es el momento para plantear las condiciones económicas si no te han dejado publicarlas en la oferta, no tiene sentido continuar si las condiciones no cuadran por ambos lados y suele ser uno de los principales motivos de bloqueo.
  9. Entrevista presencial. No hay que volverse loco, no hay que hacer entrevistas a todos los candidatos. Tienes que entrevistar al que más te ha gustado para cada puesto, también deberías de entrevistar a otro que tenga un perfil muy similar y otro que tenga un perfil totalmente distinto a los dos anteriores. Sí, los dos últimos sirven como elementos de control del primero y reservas por si el primero se cae, para asegurarte que no te equivocas. Puede parecer poco ético, pero la verdad es que en varias ocasiones me he dado cuenta en la entrevista que uno de los de control encaja mejor que el candidato estrella. Tienen posibilidades, menos, pero las tienen. Intenta que la entrevista no dure más de dos horas, que eso ya se puede considerar tortura. Intenta que esté disponible todo el mundo que vaya a tener que dar el «ok», para intentar que el candidato no tenga que ir repetidas veces, aunque no sea durante toda la entrevista y sólo entren 5 minutos a «saludar». Ofrécele agua, se puntual, intenta que esté a gusto. Tienes que tratarlo como si de un cliente se tratase, en cierto modo lo es, y en este momento le estás vendiendo la empresa y el proyecto y tú quieres que te lo compre.
  10. Cierra e informa. Si todo ha ido bien, a estas alturas tendrás el «sí» de todos los candidatos que necesitabas y es hora de que la gente de administración prepare los contratos, pero tú no has acabado. Informa a todo el mundo de que el proceso se ha acabado, no dejes a todos los candidatos esperando y expectantes. Sé que puede parecer que no aporta valor a tu negocio (como en el punto 7) y que vas a perder mucho tiempo, pero la comunicación clara y sincera es muy importante y lo agradecerás cuando tengas que hacer otro proceso de selección en el futuro o cuando uno de los candidatos se te caiga después de haber dicho que sí y tengas que recuperar a los otros.

Sé que es muy fácil poner estos puntos aquí pero luego es más complicado seguirlos, sobre todo si tienes otras tareas que ir desempeñando durante el periodo en el que tengas en marcha el proceso de selección, pero hay que tener claro que es una parte muy importante y que ha de ser prioritario ya que una mala selección puede cargarse el más simple de los proyectos.

Claves para mantener reuniones internacionales exitosas

En muchos de mis trabajos he tenido que mantener reuniones con gente de todo el mundo. Muchas veces personas en varias latitudes a la vez, que tienen que avanzar en la ejecución de un proyecto o dar solución a un problema. Creo que tras ellas hay ciertas claves que ves que cumplen los buenos Project Managers, o que no cumplen los malos. Ellos son los responsables, pero son cosas que cualquier asistente a la reunión puede poner en práctica para mejorar su participación, y optimizar el uso de su tiempo.

videocall photo
Photo by Austin Community College
  1. No dejar que la reunión se salga del plan, si surgen temas se toma nota y ya se tratarán cuando corresponda. El tiempo es muy limitado, como para ponerse a tratar temas que la gente no se haya preparado. Al estar en distintas zonas horarias, normalmente las ventanas de tiempo son pequeñas y hay que aprovecharlas al máximo.
  2. Repetir todo las veces necesarias hasta estar seguros de que todo el mundo ha entendido. Cuando hay gente de distintas partes del mundo, normalmente (para mi siempre ha sido así) se habla en inglés, pero ni el nivel ni los acentos de la gente suelen ser iguales.
  3. Preguntar expresamente a las personas, cuando haya cosas importantes con las que deberían de quedarse al acabar la reunión. De este modo te aseguras de que se han enterado. Muchas veces la gente está «conectada» a la conversación, pero sin hacer caso ninguno a lo que se le está diciendo. Cuando oyen su nombre suelen espabilar.
  4. Siempre tener un medio de comunicación alternativo. Se haga por el medio que se haga, siempre está bien tener una alternativa (generalmente un teléfono fijo con manos libres), por si la informática falla. Me ha tocado más de una vez tirar de móvil para conectar a una call porque no iba Internet, lo cual no es agradable si no hay número del país en el que te encuentres para conectar.
  5. Asignar responsabilidades antes de dar la reunión por concluida. Para que todo el mundo sepa cuales serán sus obligaciones una vez se cuelgue el teléfono. Además sirve de resumen, y como en el punto tres, es una confirmación de que todo el mundo ha entendido lo que tenía que entender.
  6. Por último, es importante mandar un correo con el resumen de todo lo hablado. Así si alguien a entendido algo distinto podrá corregir o aclarar, y lo escrito quedará para la posteridad, sirviendo de diario de abordo.

Cumpliendo con estas sencillas acciones, cualquier reunión por complicada que se te antoje; aunque sea con americanos del sur, rusos, indios, y chinos; llegará a buen puerto.

Cómo pasar de 20 a 80 empleados en 5 meses

Hace ya un tiempo trabajé en una startup que había sido recientemente adquirida por una multinacional americana (Ingram Micro, número 68 de la lista Forbes en aquel entonces). Entre otras cosas tuve que ayudar a que creciera, y en el tiempo en el que estuve allí pasamos de 20 a 80 empleados, casi todos técnicos. Además de colaborar en las entrevistas y esas cosas, me pidieron que analizara el proceso de contratación, la formación y todo lo relacionado con las nuevas incorporaciones. Estas son cinco cosas que aprendí.

castellets photo

  1. Es vital que todo siga funcionando, por lo que es importante reservar tiempo de la gente que conoce los productos y la tecnología para que sigan produciendo. En general, será la misma gente que tendrá que encargarse de las nuevas personas que se incorporen, por lo que es muy importante tener en cuenta que necesitarán seguir siendo productivos.
  2. La gente que se incorpore tiene que formarse nada más entrar, por lo que o proporcionas los materiales necesarios para que se autoformen (y largos vídeos de rusos no son lo mejor), o agendas las incorporaciones para que se realicen justo antes de impartir un curso.
  3. La gente tiene que incorporarse a algún proyecto real justo tras su formación. No vale de nada estar continuamente haciendo proyectos básicos en los que no se enfrenten a problemas reales.
  4. Es importante hablar continuamente con todo el mundo e intentar que se sientan cómodos, para tener una visión clara de lo que está pasando y cómo está el ambiente para detectar los problemas cuanto antes. Los momentos con tanto cambio generan muchas tensiones.
  5. A veces, los objetivos y ordenes que se hayan establecido desde arriba van en contra de los intereses de la empresa y pueden llevar a hacer cosas mal. Hay que cuestionarse todo venga de dónde venga, y llegado el caso hay que intentar hacer ver a la gente de arriba por todos los medios posibles qué crees que está mal y por qué. Puede que te equivoques y no tengas todas las variables en mente, pero ya será responsabilidad suya proporcionarte toda la información.

¿Os habéis enfrentado alguna vez a un entorno como esté con un crecimiento tan rápido? ¿Qué aprendisteis vosotros?

How to implement a distributed OAuth 2.0 system

Some months ago (more than a year), I was playing with the WordPress REST API. I did an analysis about how to implement a distributed OAuth 2.0 system as an attempt to collaborate with the community. I wrote it as a comment over a discussion post, but I am going to replicate that here in order to save it with my other ideas and works.

  • coolapp.com is the site of the app
  • cooldev.com is the WP site of the developer in which I defined the app as multitenant
  • cooluser.wordpress.com is the WP site of the user who wants authorize coolapp.com to interact

01- User access to coolapp.com and says “Hey, I want to use this cool app”
02- coolapp.com ask for its server and user writes cooluser.wordpress.com
03- coolapp.com ask to cooluser.wordpress.com to identify the user
04- the user writes his credentials in cooluser.wordpress.com
05- cooluser.wordpress.com redirects to coolapp.com with a code saying “Yeah, this man is my man”
06- coolapp.com then ask to cooldev.com and says “Hey, I have a user with a code that wants to acces to the resource cooluser.wordpress.com and I am the coolapp.com (this is my client_id and this my client_secret)”
07- cooldev.com generates a token
08- cooldev.com says to cooluser.wordpress.com “Hey, I just generated this token that expires in 3600 seconds”
09- cooluser.wordpress.com says “I would prefer not to work, but you know, it’s ok”
10- cooldev.com sends the response to coolapp.com with the token
11- then coolapp.com using the token, can now ask to cooluser.wordpress.com to do some stuff

If you look at this diagram

Abstract Protocol Flow
Abstract Protocol Flow

Client = coolapp.com
Resource Owner = cooluser.wordpress.com
Authorization Server = cooldev.com
Resource Server = cooluser.wordpress.com

The RFC says:

“The interaction between the authorization server and resource server
is beyond the scope of this specification. The authorization server
may be the same server as the resource server or a separate entity.
A single authorization server may issue access tokens accepted by
multiple resource servers.”

but with some conversation like the one in 8 and 9 it could be resolved.

Busco nuevos proyectos

Así es, la temporada en eldiario.es llega a su fin, y toca buscar nuevos retos atrayentes y echar una mano en otro lado.

Con un perfil como el mío es fácil pero a la vez difícil. Desde que empecé con mis empresas tengo un pie (muy adentro) en lo técnico y otro (también hasta la rodilla) en el negocio. El otro día lo comentaba con un amiguete: ahora soy lead developer, antes he sido arquitecto de Azure para Produban (Grupo Santander), antes analista en SofCloudIT (Ingram Micro), antes… ¿cómo me puedo definir con una sola etiqueta?

Al final en todos los sitios me he encargado o he ayudado a contratar equipos técnicos, he gestionado proyectos internacionales, mantenido a los equipos focalizados en lo que tocaba hacer en cada momento, he estado pendiente de las innovaciones del entorno para ver como las podíamos aprovechar para hacer nuestro trabajo mejor, he estudiado los requisitos técnicos y de negocio, he diseñado arquitecturas, he buscado clientes, hecho presupuestos… y además siempre hablando de tecnologías variopintas.

Donde creo que más puedo aportar es donde se necesite un nexo de unión entre la tecnología y el negocio dado lo heterogéneo de mi perfil. Aunque ame la tecnología, esta, pierde importancia si no se tienen en cuenta las variables de negocio (tiempos, presupuesto, objetivos, …). Debe ser una herramienta y no un fin. Creo que no hay tanta gente que pueda hablar con un matemático que ejerza de data scientist, con un frontend que habla en javascript dialecto framework X, con un cliente que quiera comprar valor, un inversor que quiera ganar dinero o un CEO que quiera crecer, crecer y crecer.

Lo primero en que me fijo de una nueva posición es en que sea interesante, que el proyecto sea un reto y sobre todo que (aunque no sea conmigo) vaya a tener un futuro y una continuidad. Me gustan las cosas distribuidas, sobre todo los entornos cloud, me gusta pensar en como hacerlas fáciles. Se me da bien encontrar la gente adecuada para cada tarea, así como lidiar con los problemas y mantener a la vez en marcha un montón de cosas, y eso que aprobé raspado malabares en el instituto. Sé delegar (aprendí a la fuerza) y asumo responsabilidades sin estresarme, ya sea porque me las asignen o porque hace falta cuando nadie más toma las riendas. Todo el mundo se alegra de tenerme cerca en los momentos de crisis, por algo será.

Obviamente las condiciones me tienen que encajar, pero en general estudio todas las propuestas y aunque ahora estoy en el centro de Madrid todo es planteable, y no me importaría volver a la Tierruca o a la Terreta, o a cualquier otro lado siempre que sea un sitio agradable.

Con este panorama es complicado preparar un curriculum vitae, porque en general creo que si le paso a alguien mi perfil completo con todas las cosas que he hecho, se puede perder antes de llegar a lo que le interese. Por eso, por el momento he preparado dos, uno para puestos de CTO y otro para los de Team líder que son los que me están planteando ahora, porque por el momento no se me ha ocurrido una forma sencilla y versátil de plasmar toda esa información. ¿Se os ocurre a vosotros algún modo?

EDITO: Gracias a vuestros consejos, he conseguido resumir todo a un «one pager» (de momento sólo en inglés). No es especialmente bonito y por supuesto no tiene el detalle de la información que se puede ver en el perfil completo de Linkedin, pero es un avance. ¡Gracias!

Quiero elegir bien, porque me gustaría encontrar el sitio dónde más pueda aportar y como sé que con sólo dos ojos y dos oídos no se puede controlar todo, os lanzo este anuncio-petición: amiguetes que pasáis por aquí de vez en cuando ¿qué proyectos interesantes conocéis? ¿Dónde creéis que me pueden necesitar? ¿Dónde creéis que podría aportar valor?