@ agnasg

De todo un poco #63

28-06-2021 3:05 AM

Replit usó amenazas legales para eliminar mi proyecto de código abierto. Como dicen en los comentarios, esta discusión es bien entretenida. El autor trabajó como pasante en la empresa Repl.it , que se dedica a proveer un ambiente de desarrollo que soporta decenas de lenguages de programación. El pasante, en un fin de semana hizo “algo” parecido, llamado riju, código abierto y alojado originalmente en github. Aquí están los detalles técnicos. Repl.it acusa al pasante de robarse ideas, de copiarse propiedad de Repl.it , etc. Ciertamente un pasante debería alejarse de replicar o utilizar ideas similares a la compañía donde trabajó, porque hay un problema ético en eso. El CEO de Repl.it tiene un sólido punto aquí. Pero.

¿Por qué Repl.it podría estar asustado, como para tener una reacción tan agresiva? Hay clones de esta aplicación como arroz. En los correos dicen que riju es basicamente un clone (no comercial y sin intención aparente de convertise en un producto), pero dado que los inversionistas de Repl.it han invertido $20 millones, el CEO de Repl.it simplemente está protegiendo a los inversionistas de competencia desleal. Él acusa al pasante de robarse las ideas que se discutieron internamente. Todo esto no justifica la agresividad. Una actitud positiva, conciliadora hubiera sido más apropiada. Este CEO es una patán.

Este es el caso de un excelente programador acosado por un CEO idiota. Yo voy a seguir la carrera del primero, e ignorar al segundo.

Aparte todo lo que se ha comentado en reddit y en Hacker News, yo creo que podemos aprender una lección aquí. El mensaje, el aprendizaje, es el siguiente: puedes conseguir $20 millones de financiamiento por una idea que se puede desarrollar en un fin de semana.

Discusión en reddit y en Hacker News.

Factorio Dev Blog

Llegó a mis ojos via este artículo el sitio Friday Facts, el blog de desarrollo de Factorio, un juego donde construyes y mantienes fábricas, con punto de vista semi isométrico, gráficos de bajo nivel, etc. Tiene 2m de descargas, y está rankeado como uno de los juegos más populares de Steam. Yo lo he descargado y realmente no es lo mío, a pesar de que khpx tiene quests en los que debes administrar/mantener fábricas (o industrias como se llama dentro de khpx)

Estuve hojeando el blog con displicencia, cuando ví esto en el capítulo fff-115:

“Los tiempos de compilación en C++ apestan. El hecho de tener que esperar 3 minutos y medio cada vez que se recompila Factorio me impacienta y me hace poco efectivo. Aparte de las razones bien conocidas, existe el problema de que el STL (standard template library) y los headers de boost no se preocupan mucho por la optimización de la inclusión [de archivos], por lo que incluir un solo archivo de estos puede llevar a cientos de miles de líneas en el módulo. Esto hace la compilación más lenta incluso cuando se preprocesa en headers precompilados. Esto me dio la idea de escribir nuestro propio subconjunto de STL+boost (las partes que más usamos).”

Esto me paralizó porque khpx usa masivamente STL. Pero dos segundos después me tranquilicé, no solamente porque preocuparme por esto sería como preocuparse por el problema #692 cuando estoy resolviendo el problema #8, sino porque yo tengo una distribución de archivos bastante agresiva y la compilación en sí no debería ser problema sino el linkeo. Además, yo uso Visual Studio que soporta headers precompilados, lo cual acelera bastante el proceso.

Ahora se me ocurre que una de mis críticas a la engine permafrost (ver mi post anterior) es la reinvención de la rueda, programar desde cero funciones que están disponibles en STL (o en otras librerías), y una de las razones para hacer esto podría ser la optimización. Pero, reflexionando sobre el tema, concluyo que sigue siendo ridículo. Los desarrolladores de Factorio lo reconocen en el post mencionado, diciendo que reprogramar las funciones de STL+boost es cuestión de años.

La reflexión fue interesante de todas maneras y me sirve de alerta para el futuro. Todo este tema justifica una vez más porqué es importante leer dev blogs, lo que te permite descubrir cosas por adelantado, cosas en las que jamás he pensado, y evita que te lleves sorpresas cuando ya tienes el agua al cuello.

Enlaces: Factorio, Factorio dev blog Friday Facts, artículo sobre Friday Facts.

Protocolo 122-34-36

Duot Peret es una anomalía en el cubo 14-28-57 porque podría ser catalogado como un jefe tipo 5, en un cubo donde la mayoría son tipo 1. Su presencia desde hace 20 años en el planeta Hanso (Laicerne) ha pasado sorprendentemente desapercibida, o sospechosamente ignorada. Su nombre no aparece en el manual de Bak Sanak ni los Etier lo tienen catalogado. No hay una descripción en los sistemas sobre él, sino un protocolo o manual de operación. Es decir, cómo debe ser manejado diplomáticamente. En resumen, debe ser ignorado y no confrontado bajo ningún concepto.

Mi próximo post forma parte del wiki de khpx, y se refiere a un inusual boss localizado en el cubo inicial. El párrafo anterior es la introducción a este boss, el primero que los jugadores deberían confrontar. Leyendo la forma enciclopédica, o quizás tipo informe de inteligencia militar en que está escrito, me recordó un sitio que estuve hojeando hace algunos meses atrás. Se trata de La fundación SCP , una colección de historias sobre personajes, artefactos e inclusive ideas de manipulación delicada y que requiere ser contenidas, aseguradas y protegidas. Si no entiendes de qué hablo, paséate por el sitio, quedarás atrapado, o quizás no.

Volviendo a Duot Peret, dice que es un boss inusual porque ningún jugador en el cubo inicial tiene capacidad de vencerlo, de hecho un jugador va a requerir al menos visitar los primeros 5 cubos (es decir se convierte en un jugador tipo 5) para poder planificar un ataque a la guarida de Duot Peret, el planeta Hanso.

Pero: si hay una forma de penetrar Hanso y sus tesoros en tipo 1.

Pero: Hanso puede ser vital para llegar al tercer cubo tempranamente.

Pero: no todos los caminos que conducen a Hanso, llegan a Hanso.

Duot Peret es mi versión de Hogger, el primer boss de wow (World of Warcraft), cuyo encuentro, y primer combate, era legendario en aquéllos tiempos cuando wow era un juego legendario. Pero Duot Peret es en cierta forma más tortuoso, inalcanzable, apetecible sobretodo, y al mismo tiempo, intrigante.

Más en la siguiente entrada.

permafrost-engine review

02-06-2021 11:17 AM

Estaba analizando este código fuente de un juego RTS (real time strategic, o juego de estrategia a tiempo real), y mi opinión en general coincide con los comentarios que aparecen en este hilo de discusión en hackers news (también en reddit, pero hace un año).

Bueno, no exactamente “excelente” pero tiene un buen nivel de calidad. El programador es un profesional. Me llama la atención la forma consistente y repetitiva tanto en hn como en reddit de comentarios como “bravo!”, “Nice and clean code”, “awesome”, “amazing”, en forma uniforme y generalizada. Bien inusual. Más bien raro.

Algunas observaciones:

Buena organización (mencionado en los comentarios y también por el programador). Esto claramente es lo que impacta desde el comienzo. Los juegos son piezas de software bien complicadas, por lo que mantener una consistente y clara forma de organizar los distintos componentes es la clave. He visto docenas de juegos que hacen un genuino intento en lograr esto, fracasando la mayor parte de las veces. En khpx los resultados han sido mixtos y mi apreciación es que al igual del manejo de las estructuras de datos, lograr una organización óptima, eficiente, clara, que facilite el mantenimiento del código no solamente es difícil, sino que consume una inmensa y costosisima cantidad de tiempo. Yo he ido dilatando esta labor pero es algo que hay que atacar a tiempo antes de perder el control del engine.

Uso de goto. Algunos comentadores aplaudieron el uso de “goto” de forma de generar una salida única para las funciones. Es decir, el código está lleno de cosas como esta:

static bool rstate_init (...)
{
    if(!rstate->sq_lock)
        goto fail_sq_lock;
    ...
    if(!rstate->sq_cond)
        goto fail_sq_cond;
    ...
fail_sq_cond:
    SDL_DestroyMutex(rstate->sq_lock);
fail_sq_lock:
    return false;
}

Y la respuesta es que es más fácil de seguir, o que es más facil agregar instrucciones en un punto único de salida. En mi opinión un “goto” nunca es más facil de seguir, y genera rápidamente código espaguetti indescifrable. Además, no se supone que las funciones deben tener unas 30-50 líneas (no más de 100)? Y que las funciones deben tener 1 quizás 2 actividades que realizar? Entonces por qué un único punto de salida es importante si debería haber en una función 1-2 salidas? De acuerdo a mi script bash, en la permafrost-engine hay 667 “goto”s. En khpx hay 0.

Es un proyecto grande, pues tiene 127k líneas de código (sin incluir scripts y utilities). khpx luego de 3 años tiene la mitad, algo más de 60k. En el hilo de reddit mencionan 38KLOC (hace un año), no sé cómo hacen el conteo de líneas de código. Yo hago un conteo crudo con mi script todo propósito / todo terreno en una línea de código Bash:

find . -type f -exec cat {} + | wc -l

Reinvención de la rueda. Esto es algo que yo he estado evadiendo al máximo en khpx, por ello utilizo algunas librerías como Dear Imgui y el STL (el standard template library). Nadie discute que el STL está suficientemente probado y optimizado. No hay razón para utilizar algo diferente. permafrost-engine re-implementa todo, incluyendo vectores, queues, y… ta ta: malloc, su propio sistema de manejo de memoria. Nada más por eso yo descartaría esta engine. Ni idea por qué los aplausos.

Poca documentación, y los pocos comentarios sufren el síndrome de inutilidad:

/* Submit and run the queued batch to completion */
render_thread_start_work();

Uso de macros. No usar macros es una buena práctica. permafrost-engine usa macros masivamente. Hay 1357 “#define”s. No sé, yo voy a seguir “no usándolos”, o usándolos al minimo: hay 170 defines en khpx.

Indirección redirigida. Si buscamos el caracter ‘&’ en permafrost-engine el resultado son 8282 matches. En khpx es 1350. ¿Pero por qué? Porque esta engine usa cosas como “&task->ctx” al máximo. Festival universal ilustrado de apuntadores. No hay nada malo per se en ello. Pero es una mala práctica en 2021.

Extra. Por cierto, ¿recuerdan mi post sobre *scanf? En permafrost-engine hay 53 ocurrencias, en khpx hay 0.

Variables / data structures globales. Excelente manejo. Todas están definidas como “static” y confinadas a su archivo. En khpx las estructuras de datos vuelan por todo el engine sin control de acceso alguno. Este es un punto que en algún momento tengo que corregir, por dificil que me parezca en este momento.

Conclusiones

Como digo al comienzo es un trabajo profesional y la engine es de alta calidad. Salvo los comentarios anteriores, fue una buena experiencia revisar el código y lo recomiendo altamente. De hecho voy a utilizar ideas de esta engine para resolver el problema que tiene khpx al manejar las estructuras de datos.

Mi página bitcoin

04-05-2021 8:09 AM

Este post lo comencé a escribir en 2017. Si por aquélla época hubiera comprado, siquiera un bitcoin, mi ganancia sería de 29x. La razón por lo que no lo hice es porque nunca tuve tiempo para entender lo que tenía que hacer. Por ejemplo, estos son los enlaces y comentarios que escribí por aquélla época:

  • En esta página se dice que el alerta integrado en la red bitcoin va a ser retirado. Se menciona Bitcoin Core 0.13.1 y Armory 0.94.1+ No hay un enlace así que un novato no sabe a qué se refiere Armory.
  • Al hacer en google “bitcoin Armory” el primer enlace es https://www.bitcoinarmory.com/
  • Si Ud. va a https://bitcoin.org/en/choose-your-wallet como es sugerido en el faq de reddit, por defecto no aparece Armory como un wallet. Aparece al hacer click en “Desktop”, pero el enlace es https://btcarmory.com/
  • Aquí dice que “bitcoinarmory.com is no longer Armory’s official website.” (bitcoinarmory.com ya no es el sitio oficial de Armory). Pero se requiere mucha búsqueda y análisis para determinar esto.

Yo pensaba que tenía que instalar el código fuente del wallet, bajar todas las transacciones (que son decenas de gigabytes) y entonces correr un nodo local.

No

Lo que hay que hacer es crear una wallet (o billetera). En este momento, mayo de 2021, la solución es Electrum (https://electrum.org/). Punto, sin más discusión. Hay que seguir TODAS las recomendaciones de seguridad, revisar el faq de bitcoin sobretodo la parte de seguridad (y otros artículos muy especialmente este).

Hay que tener los bitcoins en tu wallet. No se deben dejar los bitcoin en Coinbase y menos aun en Robinhood, porque es como si tuvieras bitcoins pero realmente son de ellos. Lo mismo con paypal y otros jugadores similares.

Mi confusión con bitcoin en 2017 se originó en cosas como estas:

El universo Bitcoin usa una jerga incomprensible: este reciente twitter por ejemplo:”Miners: it’s up to you to make Bitcoin great again by fixing transaction malleability. Fastest path forward: activate Segregated Witness.”

(“Mineros: depende de vosotros hacer que Bitcoin vuelva a ser grande arreglando la maleabilidad de las transacciones. El camino más rápido: activar el Testigo Segregado.”

Quién entiende eso.

No es que ahora sea más simple: es igual de enrevesado. Pero luego de quitar la jerga técnica, es simple:

  1. Crear una wallet en Electrum (https://electrum.org/)
  2. Antes de comprar vigila el precio en ftx.com y busca el mejor momento.
  3. Comprar bitcoins y colocarlos en tu wallet. ¿Cuánto? Lo que estés dispuesto a perder, o lo que realmente no necesites. Los bitcoin se pueden dividir hasta 8 decimales así que es posible comprar 0.00000001 BTC.
  4. Olvidarte de ellos (el precio va a subir y bajar como una montaña rusa). Ignora todo lo que se diga.
  5. Sentarte a esperar tus ganancias.
  6. Convierte un porcentaje de tus ganancias a otros instrumentos financieros para diversificar tu cartera.
  7. Felicidad total.

La dimensión desconocida

30-04-2021 7:29 PM

Droidscript , una aplicación que permite el desarrollo de aplicaciones Android usando Javascript ha sido unilateral y unánimente declarada por Google un malware, sin posibilidades de apelación. Esto significa que la aplicación ha sido removida del Play Store.

7 años de desarrollo han quedado en suspenso debido a una medida tomada por una empresa que delega su seguridad a scripts automatizados tan confiables como una hiena en las praderas de Tanzania. Estoy exagerando: Google no es una hiena, ni el internet es el Serengeti. Pero atender a los usuarios en forma automatizada es igual de incontrolable e incierto.

Noticias como las de Droidscript son aterradoras, pero más que eso, una sólida advertencia de que no podemos depender de una empresa que maneja su relación con los clientes de una forma fria, automática, algorítimica, kafkiana. El resultado parece ser que Google está permitiendo que esto suceda: las historias de terror ya tienen demasiado tiempo circulando como para que ellos las ignoren: y eso es lo que están haciendo. Nosotros no podemos cometer el mismo error, e ignorarlas también.

Ya hay voces en internet (enlace) que están dando repetidas advertencias. Al menos, si tenemos una aplicación en el App store de google no debemos usar sus productos de anuncios ( AdMob/AdSense), porque podemos ser acusados de fraude, al hacer click en nuestros propios anuncios.

Esto es una teoría, porque nadie sabe a ciencia ciertas las razones de estos bloqueos, porque no se suministran las razones. Google no quiere que se sepa cómo funcionan sus algoritmos.

Discusión en hacker news.