Snippets: categorización de colegas complicados

Este blog post managing bad engineers, habla de cómo mejorar el trabajo en equipo con personas complicadas haciendo una categorización de qué tipos de personalidades y situaciones en las que se ven representados. También propone formas de mejorar la comunicación con este tipo de colegas para lograr un buen funcionamiento del equipo.

Aquí dejo el snippet de las categorias:

The Procrastinator Procrastinators tend to delay tasks, often focusing on less important tasks while ignoring the critical ones. They may have poor time management skills, often underestimating the time required to complete tasks. This behavior can lead to missed deadlines, increased stress for the team, and potential risks to the project.

The Lone Wolf Lone Wolves assume they’re the most competent person and prefer to work alone, often resisting collaborative efforts — I mean, why would you need someone else’s help if they’re far inferior to you? Usually, they do not participate in team discussions unless to tell everyone that they “could’ve done that in 3 days”. While their self-reliance can sometimes be an asset, it can also lead to a lack of cohesion and potential misalignment with team goals. And most importantly — people don’t enjoy working with Lone Wolves.

The Negative Nancy Negative Nancies tend to overly focus on the negative aspects of situations, overlooking potential solutions. They may complain frequently, resist change, and spread negativity within the team. This behavior can dampen team morale and hinder creativity and innovation. “Why are they forcing us to do X? Urgh, I like how things are now.”

The Over-Promiser Over-Promisers tend to be overly optimistic about their capabilities or the time required to complete tasks and secretive when things don’t go as planned. Even during status updates, they can say, “It’s going great,” even though they’re struggling to find a solution and face some blockers — because they still hope to finish it on time. They often fail to deliver on their promises, which leads to frustration and mistrust within the team and with the Product Owners.

The Know-It-All Know-It-Alls tend to be arrogant and closed-minded. They often lack the ability to listen to others and are highly resistant to change or new ideas. As you can imagine, this behavior is quite annoying for others who want to spar with ideas and figure out the best way to build something. Overall this stifles creativity, hinders team collaboration, and creates a hostile work environment.

The Silent Type Silent Types, in general, tend to be introverted and may struggle with communication. Even though they might immediately see the issues with the solution, they might think, “It’s not worth it to share the concerns, to antagonize someone.” They often keep their thoughts to themselves, which can lead to misunderstandings or missed opportunities for collaboration.

The Perfectionist Very often, Perfectionists are recent graduates. They tend to focus on minute details, often at the expense of the bigger picture. They may struggle with the KISS principles and delegation and have high, sometimes unrealistic, standards for themselves and others. In their mind, the code is art, and they should not be rushed while creating an art piece. This behavior leads to inefficiencies, missed deadlines, and increased stress for the whole team.

The Unreliable One Unreliable employees are identified by their tardiness — constantly late, submitting unfinished work, and skipping meetings. They lack commitment, discipline, or time management skills. Or all three combined. Their inconsistent performance can lead to mistrust and frustration within the team and potentially (highly likely) jeopardize project timelines.

The Conflict Instigator Conflict Instigators tend to be argumentative, aggressive, and disruptive. They thrive on drama and create a toxic work environment. This behavior can lead to decreased team morale, increased stress, and reduced productivity.

The Burned-Out Employee Burned-out employees exhibit signs of exhaustion, cynicism, and reduced professional efficacy. They struggle to meet deadlines, have the lowest output on the team, and make more mistakes than over the previous observable period.

Saludos,
Gorka

Snippets: items para hacer como nuevo manager de un equipo

Hace unos días encontré este blog post: What I learned after managing a small team for 2 years, y me gustó mucho la idea de un framework con un checklist de cosas para hacer cuando tomas el rol de lider en un proyecto/equipo existente.

Dejo los items aqui para fácil acceso (y así no tengo que estar cavando y buscando en mi email, a ver si me dejé el link por ahí):

• What were some things they would like to see changed?
• What things were working well enough that shouldn’t change, and maybe just tweaked/improved?
• What do they personally expect from a new team leader?
• Is there anything I could do to improve their day-to-day work?

La idea de snippets, es tener a la mano los detalles que me hicieron eco cuando encuentro cosas online.

Saludos,
Gorka

Nuevos juguetes: Status Keycard

Hace unas semanas me crucé con un par de personas del equipo de Status, nos juntamos en un co-working space para trabajar en Aragon y justo estaban ahí también.

Platicando de ideas y proyectos y lo que estamos haciendo cada quien por su lado para el mundo Web 3.0 tuve la suerte que me regalaran una de estas tarjetas.

La idea es fantástica, la tarjeta es similar a una hardware wallet (ya escribiré un post acerca de otro de estos que tmb tengo), es decir, la llave privada con la que se firman transacciones la tiene la tarjeta, y no hay manera de obtenerla en uso normal, por lo que se puede entender como segura.

Cuando se necesita firmar algo, la tarjeta lo hace a través de NFC (similar a usar un celular/reloj para pagar). Se envía la data que se necesita firmar a la tarjeta, y esta regresa la data firmada con la llave privada.

Definitivamente es muy interesante, tiene un poco de hipo aún: hay que tener la tarjeta bien firme (que no se mueva) por los segundos que está firmando o puede fallar la operación - no es deal breaker pero por ahora si puede ser difícil usarla.

Se pueden crear combinaciones interesantes con otras hardware y software wallets, algo como: usar la keycard como llave privada de uso diario derivando la llave privada desde otra hardware wallet de uso de largo plazo. En fin, ya veremos y les iré contando.

Saludos,
Gorka

Nuevos juguetes: Raspberry Pi

Hace unas semanas me animé a comprar uno de estos (con el paquete para iniciar).

No es nada del otro mundo pero es barato, hay otras opciones de servidores pequeños con un poco más de specs, pero no es algo que me haga falta para experimentar.

El starter-kit vino con todos los cables y gadgets necesarios para ensamblar la raspi y echarla a andar.

Nota importante: ya tenía un teclado y mouse externos que son necesarios para empezar a usar la raspi, así como un monitor, de monitor se puede usar una televisión que tenga entrada HDMI (el kit venía con un cable HDMI).

Iniciar todo es trivial, cuando enchufas y conectas la Raspberry Pi te guía para conecarte a Internet e iniciar la instalación. La tarjeta de memoria ya traía el software precargado para instalar Raspbian (una distro de Linux basada en Debian). Una vez terminada la instalación listo. Ya se puede jugar con la Raspberry Pi como si fuera una computadora normal.

Entre las cosas que quiero experimentar es usar la Raspberry Pi como un servidor personal donde voy a guardar la data/info de las apps que uso (este es un proyecto más grande que estoy trabajando y obviamente precisa de cierta infrestructura para que las apps usen/guarden la data en este personal server). No sé si la Rasberry Pi aguanta estar prendida y conectada todo el tiempo, capaz y se necesita algo más para este tipo de uso, pero como dije, es de prueba y los details los iré trabajando sobre la marcha.

Saludos,
Gorka

Kanpo: exponer local server via WebRTC

Hace unos días me pasó algo curioso: ayudando a un amigo hicimos un “puente” usando ngrok a su servidor local (nada raro hasta aquí), después de un par de peticiones empecé a recibir mensajes de error por parte de ngrok, decía que me estaba pasando del límite requests - ngrok mismo dice que es raro que te vayas a pasar:

Limits are imposed on connections, not requests. If your HTTP clients use persistent connections aka HTTP keep-alive (most modern ones do), you’ll likely never hit this limit.

https://ngrok.com/pricing

Pero pasó. Y me vino la idea de usar WebRTC (como ultimamente me pasa, WebRTC para todo).

De ahí nació Kanpo - aviso, es un work in progress.

Las ventajas de usar esta herramienta contra los servicios que usan servidores para comunnicar la data son 1) WebRTC por default usa ssl, entonces las comunicacione están cifradas y no pueden espiar; 2) No se usa un punto central que puede fallar, es decir, no dependes de un servicio que hoy funciona y quien sabe como siga mañana; y 3) No hay que pagar para evitar que limiten los datos que van a estar pasando por sus servidores lo que abre la puerta a 4) Se pueden mandar miles y miles de requests por segundo si así se quiere.

Aca les dejo un par de opciones “conocidas” para exponer servidores locales que usan servidores de relay (en lo que funciona Kanpo):

• ngrok
• localtunnel

Ya iré avisando cuando Kanpo vaya siendo actualizado y funcional.

Saludos,
Gorka

Iframes y Web Workers

Resulta que por cuestiones de trabajo me vengo a enterar que los Web Workers tienen acceso a los recursos de localStorage cuando no se les ejecuta con un origen opaco (opaque origin - referencia).

La propuesta sería entonces restringir ese origen para poder limitar el acceso, pero cuando el Web Worker va a recibir un script grande (más de 2 megas grande), esto se nota - osea, tarda la ejecución y pues no es la mejor experiencia para el usuario.

Se vieron e intentaron varias propuestas (acá están si a alguien le intersan) pero ninguna fue final. Tirando ideas llegó otra que proponía usar los Web Workers dentro de un iframe limitado por sandbox (sanboxed iframes), así que me puse a hackear para ver si lo podía hacer funcionar.

El tema es que el código que se va a ejectuar en el Web Worker es “dinámico”, osea, no le vamos simplemente dar una URL donde está el script que va a ejecutar, sino que hay que darle un Blob, por lo cual va a haber problemas. Resumiendo:

• el iframe va a tener sandbox y sólo e le va a dar el permiso de allow-scripts
• hay que usar JavaScript para generar el código que se va a ejecutar en el iframe
• el Web Woker va a mandar mensajes al iframe y el mismo los tiene que responder al contexto que lo ejecutó

Solución propuesta:

class IframeWorker extends EventTarget {
  constructor(scriptUrl, id) {
    super()
    this.id = id
    this.iframe = document.createElement('iframe')
    this.iframe.sandbox = 'allow-scripts'

    const source = `
      <script>
        const init = async () => {
          const res = await fetch(url, { mode: 'cors' })
          const blob = await res.blob()
          const workerURL = URL.createObjectURL(blob)
          const worker = new Worker(workerUrl, { name: '${id}' })
          worker.addEventListener('error', error => window.parent.postMessage({ from: '${id}', error }, '*'), false)
          worker.addEventListener('message', event => window.parent.postMessage({ from: '${id}', msg: event.data }, '*'), false)
          window.addEventListener('message', ({ data }) => worker.postMessage(data))
          URL.revokeObjectURL(workerUrl)
        }
        init()
      </script>
    `
    this.iframe.srcdoc = source
    document.body.appendChild(this.iframe)
    window.addEventListener('message', this.handleIframeMessage, false)
  }

  postMessage(msg) {
    this.iframe.contentWindow.postMessage(msg, '*')
  }

  destroy() {
    window.removeListener('message', this.handleIframeMessage)
    document.removeChild(this.iframe)
    this.iframe = null
  }

  handleIframeMessage = ({ source, data: { from, error, msg } }) => {
    if (source === this.iframe.contentWindow && from === this.id) {
      this.dispatchEvent(
        new MessageEvent(error ? 'error' : 'message', {
          data: error || msg,
        })
      )
    }
  }
}

export default iframeWorker

Lo que se hizo cumple con lo que queríamos:

1. Inyectar el código directamente en la clase, para lo cual se recivbe scriptUrl, que se transforma en un blob, así se puede usar directamente en el Worker en el iframe.
2. Para que el iframe ejecute el código inyectado hay que settear la propiedad srcdoc en lugar de src o de modificar el cuerpo dinámicamente (esos métodos tirarían DOM Exception por que el iframe está en un sandbox).
3. Simular la interfaz de un Worker para hacer comunicación transparente, en este caso está el método postMessage y la emisión de eventos del tipo MessageEvent
4. Nota la implementación del método handleIframeMessage necesita de un transpilador para mantener contexto, de lo contrario tendría que hacerse un bind en el constructor (this.handleIframeMessage = this.handleIframeMessage.bind(this))

Y así quedó la fiesta.

Bueno, con esta clase se pueden tener Workers ejectuandose un contexto JS sin que tengan acceso a los stores de IndexedDB del mismo. No es algo normal pero es algo que le va a venir bien a quien lo esté buscando.

Saludos,
Gorka

Encriptar y decriptar

He estado leyendo y tratando de aprender como encriptar y luego decriptar información de manera segura (y tal vez algún día pueda decir: en la manera correcta).

Sin entrar a detalles que podrían mandarme por un agujero de conejo, describo lo que quiero hacer y luego lo que he encontrado:

Contexto:

• Se usa una llave privada y una llave pública (correspondientes)
• La llave privada la tiene una webapp
• La llave pública la tiene un servidor

El proceso:

1. La webapp hace un request a un primer endpoint (algo así como /knock)
2. El servidor recibe el request y genera una frase de manera random, entonces cifra la frase con la llave pública, guarda un hash de la frase y envía el texto cifrado como respuesta
3. La webapp recibe el challenge, lo decifra usando la llave privada y entonces genera un hash (usando el mismo proceso que el servidor para generar el hash) y manda al server el hash al siguiente endpoint (algo como /answer)
4. El servidor recibe los datos y compara los hashes, si son iguales entonces sabemos que la webapp tiene la llave privada correspondiente a la llave pública usada para cifrar el challenge

Para facilidad saqué otros puntos del proceso, pero esto describe la parte núcleo a resolver.

Encontré varias librerías que pueden hacer esto, pero, hay un requisito extra: el par de llaves tienen que ser del tipo correspondiente a Ethereum: ECDSA.

Las librerías con las que estuve jugando son:

• eccrypto
• eth-crypto
• crypto

Por ahora tengo una implementación funcional que usa eth-crypto PERO (gran pero), solo puede encriptar/decriptar mensajes de menos de 16 letras :( Le dejé un issue acerca de esto y no me han respondido (capaz nunca lo hagan), así que sigo aprendiendo para ver como resolver esto de manera genérica.

Ya iré avisando.

Saludos,
Gorka