Nepo's blog

*nix trick: desactivar auto-updates de Discord

2026-03-10T00:00:00Z

Si te mueves en el mundo gamedev o de gaming es bastante probable que tengas que usar la aplicación de Discord. Puede gustarte más o menos, pero al final es donde se encuentra la mayor parte de la comunidad. El problema es que en Linux, cada vez que detecta una nueva versión, pide que te descargues un archivo .deb de su web y que lo instales manualmente. ¡Como si estuviéramos en la prehistoria (es decir, en Windows)!

Si sólo te interesa cómo desactivar eso, salta el apartado de desactivar auto-update.

¿Por qué es un problema? (opinión)

Esto es super molesto porque la filosofía de Linux respecto a instalar el software y actualizarlo es completamente distinta a lo que quieren las empresas. Para empezar, no descargas cosas de su web directamente, sinó de un repositorio de programas gestionado y mantenido (normalmente) por los desarrolladores de tu distro. Nada de descargar un ejecutable de una web random que hace el setup, eso es super inseguro y por eso Windows tiene mala fama por tener muchos virus. En Linux usamos gestores de paquetes como apt o pacman.

Pero la parte más hiriente es que en Linux tú decides cuándo instalas y actualizas. ¿Sabéis cuando queréis encender o apagar un PC con Windows/Mac y a veces te toca esperar hasta 30 minutos (¡si no más!) porque Microsoft/Apple decidieron que hoy tocaba update? Eso en Linux no existe. El sistema de avisa de que hay actualizaciones y tú, desde la terminal o un botón visual, decides cuándo vas a actualizarlo.

Eso es así en la mayoría de programas, pero eso a Discord no le parece bien, porque es una empresa que quiere tener el mayor control posible de cómo se comporta tu máquina. Cuando abres Discord, este se conecta a un servidor para verificar si hay actualizaciones nuevas. Y si las hay, te avisa de que tienes que actualizar la versión realizando un proceso super manual. Esto es inseguro, igual que en Windows, además de muy molesto. La gente que usamos Linux lo hacemos porque huímos de estas situaciones en las que perdemos el control de nuestro propio hardware. Por eso os comparto cómo desactivar este auto-update.

Desactivar auto-update

Localizar la carpeta de configuración de Discord. Normalmente está en ~/.config/discord/
Dentro, hay un fichero settings.json. Ábrelo con tu editor de texto favorito. Si no existe créalo.
Añade la línea "SKIP_HOST_UPDATE": true,. Ten en cuenta que es un fichero JSON, así que tiene que estar entre un { y un } que debería estar ya en el fichero.
Cierra Discord y vuelve a abrirlo.

Este es mi fichero settings.json, de referencia:

settings.json

{
  "BACKGROUND_COLOR": "#2c2d32",
  "IS_MAXIMIZED": true,
  "IS_MINIMIZED": false,
  "SKIP_HOST_UPDATE": true,
  "WINDOW_BOUNDS": {
    "x": 1880,
    "y": 0,
    "width": 1796,
    "height": 1035
  },
  "chromiumSwitches": {},
  "offloadAdmControls": true,
  "enableHardwareAcceleration": true,
  "asyncVideoInputDeviceInit": false,
  "enableLibOpenH264Electron": false
}

Ahora Discord debería de actualizarse sólo cuando lo actualices con el gestor de paquetes de tu distro. Y si no quieres hacer esto, siempre te queda entrar desde el navegador 😛

Caso de estudio: Espresso Framework

2026-01-21T00:00:00Z

En este artículo analizaremos algunos conceptos que maneja Espresso, un framework de testing para aplicaciones Android, para escribir y optimizar tests en Android.

El objetivo es entender la idea general de estos conceptos, para poder recrearlos en nuestros proyectos. Así podemos añadirlos a nuestra caja de herramientas y usarlos cuando lo necesitemos. ¡Vamos a ello!

Nota: todos los ejemplos de código de este artículo están escritos en Kotlin.

¿Qué es Espresso?

Antes de entrar con los conceptos, definamos Espresso. Como dije antes, es un framework de testing para Android. Está pensado para hacer UI testing, un tipo de testing de alto nivel en el que interactuamos con la aplicación realizando las acciones que haría el usuario final en la aplicación: tocar botones, leer textos, deslizar la pantalla.

Un detalle importante que separa a Espresso de otro tipo de frameworks es que sus tests son de caja blanca/gris (al contrario de Selenium/Appium, por ejemplo, que son de caja negra). Esto significa que tenemos acceso al código de la aplicación, por lo que podemos hacer optimizaciones interesantes que nos facilitan escribir tests y mejoran su fiabilidad.

Matchers, Actions, Assertions -> BDD

Son la versión de BDD de Espresso. Match-Act-Assert son lo mismo que Given-When-Then, pero están integrados en el propio framework, por lo que el propio framework te hace organizar tus interacciones con la aplicación como escenarios de BDD.

Un detalle chulo de los ViewMatchers y ViewAssertions de Espresso es que usan los matchers de Hamcrest, lo cual nos garantiza el acceso a un lenguaje (DSL) super rico y flexible. En los ViewMatchers se usan para encontrar elementos de forma flexible y en las ViewAssertions para hacer comprobaciones sobre ellos. Estos matchers permiten combinarse entre sí para formar expresiones complejas y que dejan clara la intención. Por ejemplo, podemos buscar un elemento por su ID, porque no hay nada más claro que eso, queremos ese elemento en concreto:

onView(withId(R.id.login_button))

También podemos encontrarlos basándonos, por ejemplo, en su posición en el DOMTree o su contenido y propiedades. Imaginad que tenemos un mensaje de error que es hijo del botón de login y no tiene ID. Podríamos encontrarlo de esta manera:

allOf(
    isDescendantOfA(R.id.login_button),
    withText(containsString(R.text.login_error_message))
)

Fijaos que tenemos acceso a los resource files (R) de Android. ¡Es genial para el testing poder reutilizar las partes que forman la aplicación! Si un developer cambia el texto del error, el test ni se enteraría y seguiría funcionando. Lo cual es genial si no estás verificando ese texto en concreto.

Si combinamos esto con un patrón Page Object, podemos organizar la interacción con la aplicación en una capa abstracta y reutilizable. De esta manera, conseguimos también que nuestros tests no tengan conceptos del framework de testing y no estén acoplados a él:

class LoginPage {

    val loginButton = onView(withId(R.id.login_button))
    val errorMessage = allOf(
        isDescendantOfA(R.id.login_button,
        withText(containsString("error"))
    )

    fun login() {
        loginButton.click()
    }

    fun checkHasError(errorText: String) {
        errorMessage.check(
            allOf(
                isDisplayed(),
                withText(containsString(errorText))
            )
        )
    }

}

class LoginTest {

    val loginPage = LoginPage()

    fun testLoginFailsWithoutCredentials() {
        loginPage.login()
        loginPage.checkHasError("enter credentials")
    }
}

Idling Resources

Los Idling Resources son un mecanismo que tiene Espresso para esperar a que terminen procesos lentos.

Siempre digo que hay que evitar wait y sleep con una unidad de tiempo hardcodeada. Esto acaba siendo un magic number que no explica la intención que tenemos detrás de esa espera, así que está condenado a quedar desactualizado y sin explicación. En lugar de eso, deberíamos esperar de forma explícita a que cambien las condiciones necesarias para seguir ejecutando el test. Por ejemplo, si acabamos de rellenar un formulario de login, no deberíamos esperar 3 o 7 segundos, deberíamos esperar a que cargue la página de bienvenida.

Los Idling Resources integran un patrón de multithreading directamente con el framework de test: un semáforo. Nos dice cuándo la ejecución debe esperar (luz roja 🔴) y cuándo puede continuar (luz verde 🟢).

Dicho de otra forma, es un chivato que le dice a Espresso cuándo debe esperarse antes de seguir ejecutando el test. Vamos a ver esto con un ejemplo.

Ejemplo: Cliente HTTP

Si nuestra aplicación usa un cliente HTTP, como por ejemplo OkHttp, podemos querer detener la ejecución del test mientras se están mandando mensajes al backend (o, mejor aún, a un servidor HTTP mock).

En el caso de OkHttp podemos usar el concepto de los Interceptor, una clase que escucha a cada petición-respuesta que hagamos y que nos permite reaccionar a ellas. Esto se vería así cuando creamos la instancia del cliente:

val httpClient: OkHttpClient = OkHttpClient.Builder()
    .addInterceptor(IdlingResourceInterceptor())
    .build()

Y esta sería la clase, ya con su IdlingResource que contará cuántas peticiones faltan por resolver:

class IdlingResourceInterceptor: Interceptor {

    @Override
    @Throws(IOException::class)
    fun intercept(Interceptor.Chain chain): Response {
        // A request is received, therefore we increase the count
        request: Request = chain.request()
        countingIdlingResource.increment()
        
        // A request is resolved, therefore we decrease the count
        response: Response = chain.proceed(request)
        countingIdlingResource.decrement()
        
        return response
    }

    companion object {
        val countingIdlingResource: CountingIdlingResource = CountingIdlingResource()
    }
}

Fijaos que hemos hecho que el IdlingResource sea estático (en Kotlin esto se hace con el companion object). Esto es porque aún no hemos acabado: para que Espresso sepa a qué IdlingResource hay que esperar, hace falta registrarlos desde la clase del test. Esto lo podemos hacer de esta manera:

fun setUp() {
    Espresso.registerIdlingResource(
        IdlingResourceInterceptor.countingIdlingResource
    )
}

Nota: Si no queréis estar copiando código de un test a otro, recomiendo usar una clase de Test base que se encargue de registrar todos los IdlingResource necesarios de nuestra aplicación.

¡Y bam! Así de fácil los tests esperan a que la aplicación deje de estar ocupada para continuar. En cuanto la aplicación empieza a mandar peticiones por internet, el número se incrementa, deteniendo la ejecución. Espresso sólo seguirá ejecutando las instrucciones del test cuando este número vuelva a bajar a 0.

Intents para lanzar View específica

En muchos progamas y juegos nos encontramos con que hay un único punto de entrada. La aplicación empieza en la pantalla principal y hay que seguir un recorrido de pasos para llegar a la vista que queremos probar.

Esto es bastante problemático para los tests, porque implica que cuando más profundo en la aplicación esté una vista, más dependencias tiene el test que la verifica. Si tenemos que hacer una prueba de unas opciones escondidas en un menú al que sólo se puede acceder después de un login, el test fallará si cambia el login o la forma de acceder al menú.

Espresso utiliza dos conceptos para evitar eso:

Android configuran las vistas de las aplicaciones en Activities. Cada una puede lanzarse por separado y podemos inyectarle los datos necesarios para popularla (por ejemplo, el usuario que ha hecho login).
Las Rules son una herramienta de JUnit (versión 4, se renombraron a ExtendWith y RegisterExtension en versiones posteriores). Usan reflection para ejecutar código antes y después del test. En concreto, Espresso tiene la ActivityScenarioRule, que lanza una Activity al empezar el test y la cierra al terminarlo.

Aprovechando estas dos ideas, nos queda una sintaxis muy recogida:

@RunWith(AndroidJUnit4::class)
class InstrumentedTest {

    @get:Rule
    val activityScenarioRule = ActivityScenarioRule(LoginActivity::class.java)

    @Test
    fun myTestMethod() {
        // ...
    }
}

Declaramos la Rule como campo de clase y así no “ensuciamos” el código de setup/teardown con código para abrir la aplicación. Como norma general, siempre que podáis separar la lógica del test (ej. “hacer login”, “saltar”, “abrir un menú”…) de la lógica del framework (ej. conceptos como “label” o métodos como “sendKeys” en getUserLabel().sendKeys(username)). Igual que con el Page Object Pattern del que hablábamos antes.

Además, al abrir la vista directamente sin tener que pasar por todas las anteriores nos libramos de las dependencias que podrían romper nuestro test. Así conseguimos que el test sea más rápido y menos flaky.

Cierre

No tengo ninguna conclusión, pero quería dejar claro que el post termina aquí y así.

Llevaba mucho tiempo queriendo escribir este post, porque trabajé con Espresso durante años y quería compartir mi apreciación por algunas ideas que me parecen buenas. Espero que podáis reutilizar estas ideas en los frameworks de testing de vuestros proyectos.

Me planteé escribir otros posts antes para presentar los conceptos poco a poco, pero no tenía ganas de escribir esas guías y por eso lo fui dejando pasar 😄

Escribir sobre escribir

2026-01-12T00:00:00Z

Tengo una relación extraña con escribir y con hacer arte en general. Me gusta mucho pensar en hacerlo, me gusta mucho haberlo hecho y tenerlo publicado, pero lo paso mal durante el proceso. Tengo muchas dudas sobre cómo lo va a interpretar la gente, si van a pensar que soy infantil o que se me da muy mal, me repito que debería ser capaz de hacerlo mejor, llego tarde a las entregas casi siempre y me toca recortar cosas por lo que siento que va a gustar menos y que la culpa es mía por no saber organizarme…

Todo eso hace que me cueste mucho empezar a escribir (por eso tengo el blog tan abandonado), pero en las últimas semanas me han llegado varias obras que me han hecho pensar en escribir más. Escribir para resistir, escribir para aprender y escribir para compartir.

Escribir como forma de resistencia

El Internet está muy mal. Ya conocemos la máxima de que cuando algo es gratis es porque nosotras somos el producto. Sumando eso a la centralización masiva del tráfico de internet en las plataformas privadas, tenemos mercados monopolísticos en los que no te queda otra opción que “pasar por el aro” y hacerte cuenta en las redes principales para tener visibilidad.

En su ensayo “Contra el algoritmo: cultivar ideas en vez de likes”, Alba Lafarga nos anima a crear un espacio propio para luchar contra la mierdificación del Internet. Combatir el consumo instantáneo de la FYP y el tweet de “aquí te pillo, aquí te mando” con una comunicación más pausada y exploratoria.

Pero, ¿por qué un jardín? Porque implica tiempo, ciclos, transformación. Porque no hay un producto final, sino un proceso de crecimiento. Porque hay que cuidar lo que plantamos, regarlo, podarlo, dejar que algunas ideas mueran y que otras florezcan.

— Alba Lafarga (minishinternet.com), “Contra el algoritmo: cultivar ideas en vez de likes”

Por ejemplo, para este blog yo tengo unos ficheros en mi ordenador con el contenido de los posts y otros que definen cómo se ve el blog. Puedo dedicarle tiempo a ponerlo bonito, a escribir algo nuevo, a corregir algo antiguo con lo que he aprendido, a reordenar los párrafos para ver si se entiende mejor… mientras que en las redes principales sólo puedes postear y borrar. ¿Cómo podemos pensar en ese “contenido” como nuestro si no tenemos control para modificarlo, ni mucho menos para escoger cómo se presenta?

En “A website to destroy all websites”, Henry Desroches apunta a las herramientas que no están pensadas para escalar, y que sí están diseñadas para mejorar la autonomía y creatividad de sus usuarias, como la forma de resistir a las grandes plataformas. De nuevo, los espacios personales:

Schumacher’s concept of “intermediate technology” introduced in his 1973 book Small Is Beautiful: A Study of Economics As If People Mattered, convivial tools are sustainable, energy-efficient (though often labor intensive), local-first, and designed primarily to enhance the autonomy and creativity of their users. Illich cites specifically hand tools, bicycles, and telephones as examples, but with its enormous capacity for interoperability and extensibility, the Internet is the perfect workshed in which to design our own Tools For Conviviality.

(…)

Hand-coded, syndicated, and above all personal websites are exemplary: They let users of the internet to be autonomous, experiment, have ownership, learn, share, find god, find love, find purpose. Bespoke, endlessly tweaked, eternally redesigned, built-in-public, surprising UI and delightful UX. The personal website is a staunch undying answer to everything the corporate and industrial web has taken from us.

— Henry Desroches (henry.codes), “A website to destroy all websites”

Yo entendía el concepto de jardín digital como una especie de “patio trasero” privado en el que cuidar de tus plantas y pasar el rato con tus pensamientos. Pero estos artículos me hicieron pensar en ello como en un jardín público, como los jardines de Montjuïc o El Retiro. Lugares diseñados para ser transitados y compartidos. Saliendo de la metáfora, una página en la que mostrar lo que te interesa y te preocupa, y donde hacer comunidad también.

Quizá lo que me faltaba entender era la parte de “personal” del concepto “web personal”.

Escribir para aprender

Seguramente conoces esa cita (falsamente atribuída a Einstein) que dice que “si no eres capaz de explicárselo a una criatura de 6 años, no lo entiendes”. Y es que lo vemos en técnicas como el rubber-duck debugging: explicar algo nos permite verlo desde perspectivas distintas y rellenar los huecos que faltan en nuestra comprensión. Cory Doctorow (que acuñó el término “enshitification” del que hablamos antes) escribe sobre escribir:

It’s revelatory. It teaches you what you know. It lets you know what you know. It lets you know more than you know. It’s alchemical. It creates new knowledge, and dispels superstition. It sharpens how you think. It sharpens how you talk. And obviously, it sharpens how you write.

— Cory Doctorow (pluralistic.net), “Writing vs AI”

Reiterando en la escritura como una forma de aprender, el youtuber Odysseas habla sobre cómo los ensayos pueden ser una herramienta cuando queremos aprender algo (en el video da consejos sobre cómo empezar a escribir ensayos para vosotras mismas, por si os interesa, pero recomiendo escribir y ver qué os funciona y qué no):

https://www.youtube.com/clip/UgkxWVSFIQZiXNaC4sgj5LpoZehPF_80F4yP

Transcripción:

Essay writing should be seen more as a problem solving method. Where the process, the means, is more important than the end. You are not writing so you can have a finished essay. (…)

The point of writing an essay is to give yourself the chance to think. Because the ideas in you head, they are scattered. They’re unclear. They’re vague. You don’t really know what you know. But as soon as you put them on the paper they become real, they become expressed into the world. And only then you have the perspective to see them and to really judge them properly.

— @odysseas__ (https://www.youtube.com/@odysseas__), “I’m begging you to write essays”

Creo que en ambos casos es importante mencionar la diferencia entre “aprender por necesidad” y “aprender a tu ritmo/por gusto”. El primero podría ser un ámbito académico, un aprendizaje industrializado en el que hay que cumplir unas cuotas y en el que posiblemente tengas prisas y otras cosas que aprender. ¿Sería útil en este contexto? Quizá, no lo he probado, pero es que ese no me parece que sea un buen contexto para aprender nada.

Pero si nos mantenemos con curiosidad y seguimos aprendiendo a lo largo de nuestra vida, escribir sobre lo que aprendemos puede hacernos construir nuestra comprensión para que sea sólida, nos resulte fácil aprender otras cosas en el futuro y que sea lo suficientemente lúcida como para poder compartirla con otra persona.

Escribir para expresarse

Me ha gustado la escritura desde que era adolescente. Recuerdo que empecé a escribir una historia de fantasía en 2º de la ESO (era horrible), pero un comentario desafortunado de mi madre hizo que parara de escribir y que no lo considerara como una inversión válida de mi tiempo. Acabé pensando que no era algo que necesitara y que era mejor descansar jugando un videojuego o leyendo que tener que justificar porqué quiero dedicarle tiempo a eso.

Aún así, la escritura ha sido algo que me ha acompañado toda la vida. De adolescente, unos amigos crearon un foro y empezamos a escribir historias ahí (horribles también). Cuando repetí 2º de bachiller, quedándome en una clase en la que no conocía a nadie, conocí a un grupo maravilloso por un foro de internet que me acompañó durante ese año y muchos más. Acabamos haciendo un club de escritura en el que escribíamos un relato corto de 1-2 páginas cada semana (¡algo que me encantaría recuperar!). Rol por foro, blog posts, narrativa de videojuegos, documentación en el trabajo… ¡parece que sí necesito escribir después de todo!

La mayoría de lo que he escrito se ha quedado en privado, en grupos pequeños. Creo que porque la fantasía y escribir para entretener me parecen menos válidos que algo más “académico” como los tutoriales o la divulgación de herramientas y técnicas que vengo haciendo en el blog. ¡Ojo! No es algo que defienda y animo a cualquier persona a que escriba lo que quiera escribir, pero personalmente tengo que luchar contra este juicio cada vez que quiero escribir algo.

Por suerte, encontré este video ensayo sobre escritura creativa de @WritingwithAndrew que me abrió los ojos a otro tipo de escritura:

https://www.youtube.com/clip/UgkxmziJH2h_UhuaFZdkATCfjMN1nWSQylnf

Transcripción:

Just as fiction shows us what imagined humans can do in imagined high-stakes scenarios, and poetry shows us how humans experience and feel in response to life, creative non-fiction shows us how another person encounters and processes their experience.

Creative non-fiction is what happens when we get an essay about a father digging a hole in the backyard with his son a year into the pandemic. When we get a single devastating paragraph about a man taking his daughter to the pediatrician on the morning of what he calls his last hangover. Or when we get a playful meditation on the migratory habits of the blackpoll warbler.

In each case, a lived experience or phenomenon or fact gets filtered through a unique and compelling human perspective. Yeah, the warblers are interesting, but the real show is looking at those warblers through Amy Leach’s eyes.

— @WritingwithAndrew (https://www.youtube.com/@WritingwithAndrew), “I’m Politely Begging You to Write Nonfiction”

Porque a veces qué se cuenta no es tan importante, válido, hermoso y valioso como el cómo. Me sirvió de ejemplo de este tipo de escritura descubrir a Xot d’octubre, que escribe cosas preciosas y evocadoras en catalán, y conectar con Juarrín, de La cueva de los ecos.

Todo esto me ha despertado las ganas de escribir de nuevo, lo que ha resultado en este artículo que estás leyendo (¡gracias! ❤️) y en un pequeño juego narrativo sobre finales y burnout.

No quería acabar con ninguna conclusión ni nada. Sólo la promesa (¿o amenaza?) de que seguiré escribiendo. ¡Nos leemos! 👋

*nix trick: command wrappers

2025-11-04T00:00:00Z

¡Hola! Lo que me encanta de la terminal es que no hace falta que recuerdes cómo funciona cada comando. Si hay algo que vas a usar 2 veces al mes, lo guardas en un script y usas eso directamente. No tienes que recordar en qué submenú, en qué botón con un icono estaba esa funcionalida. Y lo mejor es que no te van a cambiar con un update, porque son scripts que tienes en tu PC. ¡Es como escribir notas que pueden ejecutarse y validar que siguen funcionando! ❤️‍🔥

Hoy quería traeros un truco super sencillo pero super útil. Es una manera de sobreescribir/extender el comportamiento de comandos existentes en shells de tipo UNIX (o sea, os funcionará en Linux, Mac y WSL de Windows). Al finalizar el post habremos extendido git diff para poder llamarlo con un parámetro “godot” (es decir, git diff godot), que nos mostrará un diff únicamente de ficheros de escenas y código. Nada de binarios ni ficheros de configuración de importación de assets.

Pues si os interesa esto, lo primero que necesitamos es conocer el comando alias.

Comando alias

Existe un comando alias con el que puedes decir “cada vez que te diga esto, llama a este comando”. Por ejemplo:

alias some="echo 'body once told me the world is gonna roll me'"

Con eso, cada vez que escribamos some en la terminal, ejecutará el echo que le hemos puesto después:

$ some
body once told me the world is gonna roll me

Normalmente, los cambios que hacemos con este programa sólo duran mientras la sesión de la shell esté abierta. Eso quiere decir que si cerramos la terminal y la volvemos a abrir perderemos ese alias que hemos creado.

Para hacer que este cambio sea permanente podemos añadir la línea del alias a nuestro fichero .rc. Suele depender de la shell que estemos usando: si es bash estará en ~/.bashrc, si es zsh estará en ~/.zshrc…

Por ejemplo, yo tengo una sección en mi .zshrc para configurar estos aliases:

# ...

####
# Aliases
####

alias please="sudo"
alias open="xdg-open"
alias code="codium"

# ...

Ahora que ya conocemos qué hace este comando y cómo usarlo, podemos empezar a extender otros programas.

Explicación del caso de ejemplo

Godot genera algunos archivos como configuraciones de importación de imágenes, audio y modelos 3D ("*.import") o ficheros binarios de materiales y recursos ("*.res"). La mayoría del tiempo me interesa saber si ha habido cambios en esos ficheros, pero hay momentos en los que sólo quiero ver los cambios que se han hecho en los ficheros de escenas y código (*.tscn y *.gd), por lo que ver los cambios de los ficheros de importación y recursos me molesta.

Lo primero que pensé es que git debe tener alguna forma de filtrar los archivos que no me interesan, y así es. El problema es que es muy largo como para tener que reescribirlo (¡y acordarme!) cada vez que quiera usarlo:

git diff -- . ':!**/*.import' ':!**/*.res'

Podemos añadir un alias para ejecutar esta línea. Por ejemplo, un alias godot-diff o alias git-diff-godot en nuestro achivo .rc. Pero podemos hacerlo aún más bonito con un script que nos haga de wrapper.

Wrapper scripts

¿Qué es esto de un script que hace de wrapper? La idea principal es que en lugar de llamar al script como git-diff-godot, podríamos llamarlo siguiendo la API de git y hacer un: git diff godot.

Esto también nos permite definir varios casos. Quizá tenemos un diff distinto para Unity, otro para Unreal, otro para un engine custom… Si simplemente usáramos aliases, deberíamos tener varios (git-diff-unity, git-diff-unreal…), mientras que si hacemos el wrapper script estos serían casos de un switch-case. ¿Y si queremos sobreescribir la funcionalidad de git status o git commit? ¡También podríamos usar nuestro script para detectar los casos en los que tiene que hacer algo distinto!

La idea principal es que este script se encargue de 2 cosas: 1. Saber cuándo tiene que llamar al programa original y cuándo hacer algo distinto. 2. Ejecutar el caso distinto para el que lo estamos construyendo. En este caso, el diff complicado.

Podemos complicarlo mucho, pero para empezar con algo sencillo deberíamos aprender a usar el comando if y el comando case (docs de condiciones e ifs y cases). Por ejemplo, con este script podríamos hacer que al llamar a git diff godot se lance el comando que encontramos en la sesión anterior:

#!/usr/bin/env bash

GIT="/usr/bin/git" # el comando de git original
ARGS=("$@") # los parámetros originales

function forward_to_git {
    $GIT "${ARGS[@]}"
}

if [ $# -gt 0 ] && [ "$1" = "diff" ]; then
    if [ $2 = "godot" ]; then
        $GIT diff -- . ':!**/*.import' ':!**/*.res'
    else
        forward_to_git
    fi
else
    forward_to_git
fi

Al ejecutarse este script, pueden darse 3 posibilidades distintas:

Es el comando git, pero no tiene parámetros (es decir, git a secas; no cumple $# -gt 0) o el primer parámetro no es “diff” (por ejemplo, git status; no cumple "$1" = "diff"). En este caso, llamamos al comando original git y le pasamos los parámetros recibidos.
Es el comando git, su primer parámetro es “diff” y su segundo parámetro es la opción que nos hemos inventado, “godot” (es decir, git diff godot). En este caso, llamamos al comando que queremos llamar.
Es el comant git, su primer parámetro es “diff”, pero su segundo parámetro no es la opción “godot” (por ejemplo, git diff --staged). En este caso, llamamos al comando git con los parámetros que hemos recibido.

¡Recordad una cosa! Este script por sí mismo no hace nada. Tenemos que ponerle el alias git=$(path hasta el script) en nuestro fichero .rc para que se llame a este script en lugar de al comando de git original.

El wrapper script que uso yo

El script que uso no es exactamente el que os he compartido. Ese está simplificado para que sea más fácil de seguir. Os dejo aquí el mío por si os da más ideas o por si queréis usarlo de base para empezar a extender git a vuestra manera.

¿Qué ideas se os ocurren? ¿Hacer un pretty print para ver el árbol de commits con git log? ¿Comprobar que los archivos están nombrados como queremos antes de hacer un commit? ¿Lanzar los tests antes de cada push? ¿Usarlo con otro comando que os cuesta aprender? ¡Compartidme las ideas que se os ocurran por el Fedi o Discord! 😄

#!/usr/bin/env bash

# This script works by setting up an alias in you .rc file ("~/.bashrc", "~/.zshrc"...).
#
# ```bash
# alias git $(path_to_this_script)
# ```
#
# That way you can override git's call to use it like:
#
# ```bash
# git diff godot
# ```

GIT="/usr/bin/git"
ARGS=("$@")

function forward_to_git {
    $GIT "${ARGS[@]}"
}

function diff {
    case $2 in
        "godot")
            $GIT diff -- . ':!**/*.import' ':!**/*.res'
            ;;
        *)
            forward_to_git
            ;;
    esac
}

function main {
    if [ $# -gt 0 ]; then 
        case "$1" in
            "diff")
                diff $*
                ;;
            "nuke")
                $GIT reset --hard && $GIT clean -fd
                ;;
            *)
                forward_to_git
                ;;
        esac
    else
        forward_to_git
    fi

}

main ${ARGS[@]}

Tarrey Town en la OST de Breath of the Wild

2024-02-04T00:00:00Z

Voy a tener un momento de apreciación muy random con este tema. Quizá ya lo conocéis y sabéis todo lo que voy a decir (se ha hablado mucho de él y llego muy tarde). Pero es que llevo unos días que no dejo de escucharlo y tengo que sacármelo de la cabeza.

Si habéis jugado a Breath of the Wild y habéis llegado a este pueblo, sabréis que se llama pueblo Tarrey (Tarrey Town a partir de ahora). Al principio suena esa melodía, tranquila pero muy vacía. Hay un tipo construyendo casas y tal. Un poco aburrido, la verdad.

El tema es agradable y simpático, y a priori podríamos quedarnos ahí. Pero la gracia de este pueblo es que vas “reclutando” a gente para que se vaya a vivir ahí. Y dependiendo de a quién invites, aparecen nuevos instrumentos.

Por ejemplo, el primer personaje que reclutamos es el Goron Greyson, que es un bicho grande y que come piedras (y van siempre desnudos o con taparrabos, por alguna razon). Como es lo más bruto que te puedas imaginar, añade un trombón super estridente al tema (1:36).

Narrativa

Lo más interesante es que, al añadir instrumentos, el propio tema cambia. Al principio la base y el bajo los lleva un piano. Es el mismo instrumento que usan cuando vas paseando por el campo o en caballo. Es majestuoso y al sostener las notas da la sensación de espacio abierto y vacío. Además, no hay ningún otro pueblo (salvo el pueblo Zora) que incluya un piano (Hateno, Kakariko, Gerudo, Goron City, Lurelin), lo cual refuerza que el piano sea el instrumento que caracteriza el campo abierto, la naturaleza de Hyrule, o a la propia Hyrule en sí.

Pero en cuanto llega el Zora al pueblo, se empieza a llenar. Ese piano desaparece y lo sustituye una guitarra con mucha menos reverb (fijaos en el cambio en los bajos alrededor del 6:20). Hace que el tema se vuelva más cálido y cercano. Deja de ser majestuoso y con eco. Ya no es gente reunida en cuatro chozas en el campo, ahora es una plaza de pueblo bulliciosa, con mucha gente distinta y de diferentes culturas. Y cada una aporta algo a la canción.

Voces

Otra cosa interesante que hace este tema es que los acentos de cada personaje son como una conversación. Abre uno y responde otro. Luego sale un tercero. Luego suenan el primero y segundo a la vez, y después les responde el tercero. Es literalmente un “buen día, doña Encarni”, “buen día don Miguel”, “¿pasó usted por mi casa?”…

Este post de Matt Pederberg me ayudó mucho a distinguir las “voces” de cada personaje en la canción, los instrumentos que los representan. Ya hablamos del Goron y el trombón antes, pero hagamos esa relación ahora con el resto de personajes:

El clarinete (00:00) que lleva la melodía es la esencia del propio pueblo, del pobre Hudson que está construyendo todo solo.
El trombón (1:26) es el Goron Greyson, pero también trae un vibráfono.
El dulcimer (3:12) representa a la Gerudo Rhondson. Es mucho más sutil que los otros instrumentos, representando el carácter aislado de las Gerudo.
Hay otro clarinete que hace las notas más altas (4:48). Este representa a Fryson, el Rito.
La guitarra Zora de Kapson reemplaza al piano (6:24) y entran también las gaitas de Hateno traidas por Bolson.

Los únicos instrumentos importantes que suenan debajo del resto son:

El clarinete que toca la base, la melodía del pueblo.
El piano que toca el bajo con tanto reverb y que más tarde desaparece.
La guitarra que reemplaza al piano en el bajo.

Lo cual me parece un poco injusto por el Zora que trae la guitarra, que no tiene su momento de poder hablar y que le hagan caso 😆

Reactividad

Todo esto se puede percibir sin tener idea de leitmotivs ni movidas chungas de teoría musical, simplemente fijándose en los instrumentos que suenan. Me parece maravilloso y es una de las cosas que más me gustan de todo el juego.

La jugadora tiene muchas cosas a hacer en este Hyrule tan grande. Por lo que seguir esta misión acaba siendo su decisión, no la del game designer. Quizá en este caso, la reactividad del entorno, estos cambios tan sensoriales como la música y las nuevas casas, se suman con el mundo abierto para reforzar la agencia de la jugadora.

El videojuego es un medio interactivo y pareciera que a veces nos olvidamos de eso. Hay opciones obligadas que no son realmente una opción, u opciones falsas que no llevan a ningún cambio. O peor, cambios en números, pero ningún cambio real en la experiencia de juego. Es algo completamente normal y hasta deseable. Si tuviéramos que implementar todas las posibilidades que se nos ocurren, el desarrollo de los videojuegos tendría costes inasumibles. Y opino que no serían nada interesantes.

Pero por eso me gusta encontrarme y dar reconocimiento a experiencias como esta. Experiencias que deciden dedicarle recursos y tiempo a premiar la agencia de quien las juega. Y que haciendo eso, acaban funcionando tan bien y cuentan una historia tan wholesome.

Aunque esto es sólo una excusa para hablar de un tema sonoro tan super bonico como este ❤️

Configuración de CI para jams

2024-02-01T00:00:00Z

Hace un par de días liberamos el código de dos juegos que hemos hecho en equipo:

Rat and Furrius, para la Mermelada Jam
La Falda de la Montaña, para la MálagaJam Weekend 17

Tiene todas las ñapas que podáis esperar de una jam, pero también hay cosas que os pueden resultar útiles. Entre ellas, un archivo para exportar un proyecto de Godot a web y subirlo a itch.io automáticamente.

¿Por qué querrías hacer eso en una jam? Pues porque se hace en 5 minutos y te permite:

No bloquear a une programadore cada vez que quieras hacer una build.
No depender de une programadore para poder lanzar el juego.
Hacer builds más frecuentes para hacer playtesting de los prototipos más rápido.
Asegurarte de que la build siempre será la misma. Que no te habrás equivocado al exportar/subir el proyecto.
En los últimos 5 minutos de jam, no tienes que estar comprimiendo archivos, yendo a una web y subiéndo archivos. Sólo haces click en un botón y esperas relajadamente 🍹

Configuración

Lo que sigue es sólo una lista de instrucciones rápidas si ya sabes qué hay que hacer. Si no entiendes algo, en la guía de configuración que hay más abajo estará explicado 🙂

Copiar .github/workflows/main.yml a tu repositorio de GitHub.
Cambiar los valores de estas variables. Si actualizas la versión de Godot, recuerda actualizar la versión de la imagen de Docker.
Genera una API Key de Itch y añádela como secreto en el repositorio (Settings > Secrets and variables > Repository secrets).
Abre el proyecto en Godot y genera la configuración para exportar el proyecto a web (Project > Export... > Add... > Web). Como nombre de esa configuración deja Web, y como export path ponle build/index.html.

Sube los cambios al repositorio y ya está listo para usar.

Probando que funciona

Esto puede hacerlo cualquier persona con acceso al repositorio, no sólo les programadores:

Entra en Actions.
Selecciona el workflow Build + Deploy.
Haz click en Run workflow > Run workflow.

Si todo sale bien, en unos minutos os saldrá la ejecución en verde. Y si váis a vuestra página de Itch, os debería aparecer vuestro juego.

¿Y esto es gratis?

Hasta cierto límite. Tenéis 2.000 minutos de ejecución gratuitos por mes en el plan gratis. Para Godot y para jams, es difícil de alcanzar. Y la ventaja de no depender de/bloquear a une programadore y que siempre se suba el proyecto de la misma manera es considerable.

Guía de configuración en detalle

En esta guía se explica con pelos y señales cómo funciona esta automatización, por si tienes alguna duda o por si tienes curiosidad y quieres aprender más 😊

Copiar main.yml

Lo primero que tienes que hacer es copiar el fichero .github/workflows/main.yml a tu repositorio en GitHub, dentro de esas mismas carpetas “.github” y “workflows”.

Esos son unos directorios especiales que GitHub interpreta como una configuración de su sistema de CI (Integración Continua), las GitHub Actions. Este permite automatizar todo tipo de procesos: desde las builds y subirlo (deploy) a Itch, hasta conversiones de ficheros, ejecución de pruebas, escribir mensajes en Discord/redes…

No puedo explicar en este post cómo funciona en detalle. Pero si te interesa aprender más, tienes la documentación oficial. Recomiendo aprender algo de Docker de antemano para entender cómo se configuran las máquinas en las que se ejecutan estos procesos. Para esta guía sólo nos hace falta saber que una “imagen de Docker” es algo parecido a un ordenador que ya viene con cosas instaladas.

¿Y qué es lo que hace este fichero? Pues define los pasos a seguir para generar esa build y subirla a Itch. Si lo abres, verás que tiene unos “steps” definidos. A grandes rasgos, esto es lo que hacen:

Checkout: se descarga el código del repositorio.
Setup: prepara las export templates de Godot. La imagen de Docker ya incluye esas templates, que a veces pesan ~1GB o más, dependiendo de la plataforma.
Web Build: usa Godot desde la línea de comandos para exportar el proyecto para web.
Itch.io Deploy: sube los ficheros exportados a Itch para que se puedan jugar.

Editar las variables

Variables en main.yml

Una vez copiado, hará falta modificar los valores de estas variables en main.yml para que sean los de tu juego:

ITCHIO_USERNAME y ITCHIO_GAME son tu nombre y el de tu juego que aparece en la url. Por ejemplo, para https://edearth.itch.io/falda-montana serían edearth y falda-montana respectivamente.
GODOT_VERSION es la versión de Godot que estés usando. Si la actualizas, tendrás que actualizar también la versión en la línea que define la imagen de Docker. Puedes consultar las versiones disponibles en este enlace.
La variable BUTLER_API_KEY es especial y está definida en otro lugar. No hace falta modificarla aquí. Te lo explico a continuación.

API Key

Una API Key es una especie de “contraseña” que permitirá a esta GitHub Action usar vuestra cuenta de Itch. Si te parece peligroso, es porque puede serlo. Por eso no podemos guardarla con el resto de variables, porque tiene que mantenerse en secreto.

Para configurarla, accede a Settings > Secrets and variables > Actions > Repository secrets y cread un nuevo secreto. Dentro, copia la API key que generes desde itch.

Esta API Key se puede usar con Butler, la herramienta para línea de comandos de Itch. Permite subir proyectos a Itch de maner super rápida, subiendo sólo los ficheros que se modificaron. Y es justo lo que nuestra automatización hará.

Es MUY importante que mantengas esta clave bien segura. No la pases por Discord, ni WhatsApp, ni ningún sitio. Y si sospechas que se ha filtrado, tienes que ir al dashboard y darle a “revoke” lo antes posible. Si alguien se hace con ella, puede llegar a acceder a tu cuenta de Itch y borrarte los juegos.

Export en Godot

El último paso es decirle a Godot cómo y dónde tiene que generar esa build del juego. Para eso, abre el proyecto en Godot y navega hasta Project > Export... > Add... > Web. Si es la primera vez que vas a exportar tu juego, esta ventana estará vacía como en el video. Al darle al botón de Add... y seleccionar Web se generará la configuración para exportar el proyecto a web.

El fichero main.yml está configurado para que la build se exporte a una carpeta específica, por lo que tendrás que configurar el “export path” para que sea build/index.html. Ahí es donde se creará la build. No es por nada que necesite GitHub ni Godot. Es que usé ese directorio en main.yml y es más fácil dejarlo como está que modificarlo cada vez que crees un nuevo proyecto.

Una vez hecho esto, ya habrás terminado. ¡Lo único que te queda es probar que funciona!

Setting up shared folders in Linux

2023-09-11T22:22:00Z

I find it difficult to concentrate on personal projects when I’m working on my PC. I go to search some documentation online and I see social networks tabs, videos and articles with interesting topics I saved for later… and I lose my focus.

Recently I found an article that advocated having separate work and personal users in your laptop to avoid this case. That sounds like a great idea, but I have my Obsidian second brain in my personal user folder and I have Syncthing to share it with other devices. So I need to update it to be accessible for both users.

Design

I want to create a folder that Syncthing can read and write to. Both personal and work users must be able to read and write to that folder as well. For that, we will use a user group shared by Syncthing and the other users.

Existing files and folders will need to have its group and permissions updated to be readable and writable for that user group.

We will also need new files and folders to be created with specific permissions: - They must be added to the syncthing group. - They must have the read and write permissions for the group.

Are there easier ways to do this? Probably, but this is the way I wanted to do this.

Setting it up

Just FYI, you will probably need to use sudo for most of the commands. I removed it to make the code less verbose and redundant. Just use your common sense: if you’re updating permissions for a file/folder not owned by you or you’re creating and assigning groups to users, use sudo.

Create group

With these commands you create a user group called syncthing and add personal and work users to it.

groupadd syncthing
usermod -a -G syncthing personal
usermod -a -G syncthing work

At this point, you must reboot your computer for these changes to apply. You can verify your user was added to the group when you login with these commands:

groups
id

Permission for existing files

Make the entire folder be owned by the group you just created with:

chgrp -R syncthing /srv/syncthing

Then update the existing files and folders to have read and write permissions for the group:

find /srv/syncthing -exec chmod 775 {} +

Default group permissions for new files and folders

By default, your system might create new files and folders with the write permission for the group disabled. In order to change that, you need to use Access Control Lists (ACLs). They seem complicated and

# Force new files and folders to have the same group as the parent folder
chmod g+s /srv/syncthing
find /var/www -type d -exec chmod g+s {} + # for subdirectories

# Force new files and folders to have the group permissions set to read and write
setfacl -m "default:group::rw" /srv/syncthing
find /srv/syncthing -type d -exec setfacl -m d:g::rw {} + # for subdirectories

And that should be it.

Testing it

In my case I just removed the original folder from Syncthing and re-synced again in the new location: /srv/syncthing/Obsidian.

After that, I logged in with my personal user, set up Obsidian to use that folder and I can open and write in files. Do the same for the other user and it works too ✅

Librarian tools for a more civilized age

2021-06-26T21:42:00Z

Do you remember how, for a brief moment in human history, you could fix machines by using violence? No university degrees or user manuals required, just a good ole slap o’ the hand to the side or top of the idiot box. And there you go, it works again! This could’ve been caused by a connection error, some faulty wires that didn’t properly transmit the video signal. But the point is you didn’t have to know about that, it used to be a magic solution that sometimes fixed stuff.

We don’t have wires anymore, for the most part. Most of our electronics use a PCB with each component attached to it (usually soldered or screwed). They’re so pervasive and easy to produce you could even use them for garage projects! It’s as easy as printing an image, transfering the ink to the board, applying some chemicals and drilling some holes. And they look waaay better than a mess of cables connecting everything.

While listening to episode 5 (“Charlie Bucket’s dad”) from Daniel Messer’s (@bibrarian) “Cyberpunk Librarian” podcast, I realized our problems are now mostly digital. We’ve figured if we remove the wires we won’t have faulty wires anymore. But that doesn’t mean we fixed the “connection error” problem. In the digital world we could have an API or program failing because we entered the wrong parameters. Or, if we have a long chain of different pieces (which sounds like a generic definition of what a computer or the Internet is), it could be any of those pieces failing.

What this means is most of the times we can’t apply a magic solution and hope for the best. Well, turning it off and on again works sometimes, but it won’t fix all problems. We need to really understand the problem in order to fix it. This is captured very well on Julia Evans’ (@b0rk) debugging adventure games. In these choose-your-own-adventure games you investigate a problem, finding clues like if it were a Phoenix Wright game, until you find out the root cause and fix it. Finding bits of knowledge about a digital problem, that we solve with digital tools.

And that’s what concerns this post: tools. Even though “tool” calls up a very physical mental image (like a wrench, hammer or a voltmeter with a display, switch knob and probes), digital problems in digital systems require digital tools to solve. And to use those tools we sometimes need to read documentation, experiment, fix and replace them when they stop working. Just like physical tools!

Daniel’s point about familiarizing yourself with your tools is as valid in software development as it is with librarian tools (or physical tools in a physical job 😛). Yet, perhaps because of the amount of tools or their “locality” (eg. Apple ecosystem used just for Apple development), this is a difficult task. Nevertheless, you would be doing yourself a disservice if you don’t. Learning about your tools is a good way to find ways to make your job easier. You stop depending on others to fix things, you grow your knowledge base, you do a more rewarding job and with your own individual background you could find an obvious solution that isn’t obvious to anybody else. Like in the example at the beginning of the post: by understanding the wires were causing the connection problem, we can ask ourselves: can we fix them? Can we replace them with something cheaper that doens’t have that issue?

That’s all. This post was mostly an excuse to share work by some people I like. I hope you found it useful or interesting in some way. Be sure to check the work done by Daniel Messer (@[email protected]) Julia Evans (@[email protected]), it’s really good! 😄

On insecurity and self-narrative

2021-05-03T00:00:00Z

Be warned: this post will be quite personal. Back away now if you’d like to avoid cringing 😄

Last year I made a small exercise. I was dealing with feelings of inadequacy, since I have a tendency to those. In other words: I often feel insecure. I remembered how a friend of mine told me that I don’t value my successes and I delve too much on my failures. So I decided to get external input and I asked some friends and colleagues for feedback. The questions were:

When was the last time I helped you?
In which way / doing what?
What are the 3 things you value most from me?

I was surprised by the result: what these people were seeing was nothing like how I saw myself!

Where they saw a fun, loyal, unjudging friend that cared about them, I saw a guy with boring conversation, that couldn’t return the affection others showed him. Where they saw honesty, I was painfully aware of all the things I didn’t say in the past to avoid hurting someone or because of fear of judgment. Where they saw a critical-thinking engineer and growth potential, I thought back on all the times I was slow to finish a task or that I had to ask for help/learn something new to do my work (as in “I don’t have the knowledge/level I need to do this”). How could it be they were so wrong? And most importantly: what will they do when they find out?

Of course, I knew they all couldn’t be wrong, and that maybe (just maybe) my own self-image was skewed. Since then, I started noticing when I was judging myself and applying a generous serving of doubt to those thoughts.

This allowed me to clear my mind of those intrusive judgements and focus on the real cause of my insecurity. I stopped accepting those thoughts just as they popped up. Instead I questioned them and thought “what would I tell someone else if they were in this position?”. For instance:

When I’m talking with friends and I think “they look bored, I should leave and let them do something they enjoy”, I remind myself they can leave whenever they want, they chose to come and they’re choosing to stay. Maybe I’m wrong to doubt them. I’m sure I’m wrong for trying to decide for them.
When at work I don’t understand something and I lose 2h reading documentation, I remind myself this is my first time doing this. No one was born knowing. It isn’t my fault and it’s perfectly fine. I will be better when I’m done reading, and next time I won’t need so much time.
When I see successful people and think I haven’t done anything with my life, I remind myself of all the people that keep in touch with me, of my career and how much it has made me grow, of all those little projects after work, of all the things I do know instead of the ones I don’t, of this little blog… all those things I care about.

It might seem like I’m constantly defusing bombs in my head, but far from it. Refuting the negative judgements slowly improved my self-image. I was more kind to myself and so the thoughts appeared less frequently. In time it got easier. My fears became smaller and easier to manage. I still have them, but at least I’m not struggling with them. And lately gratitude has been replacing them. Gratitude for friends spending time with me, or for being fortunate enough to learn at work.

If you’re struggling with insecurities yourself, try avoiding judgement and find out where that fear comes from. Then you can figure out (on your own or with other people’s help) if those things are true or not. The story we tell ourselves has a huge impact on how we feel and what we do. Don’t let your fears dictate the narrative. You can tell a much better story! 😉

I saved the notes from when I asked friends and colleagues for feedback. I just saw them today and they brought a smile to my face. If you do something similar, they might bring one to yours in the future 🙂

Painless responsive CSS: water, flexboxes and grids

2021-01-31T00:00:00Z

When I started this blog I had no idea of how to write modern CSS, nor did I know the slightest thing about how to make a website responsive. I started making a stylesheet with lots of minute details, like setting multiple margins in pixels for all classes, organizing the layout based on those margins, using weird tricks to center divs, etc.

Only when I tried making the site responsive I realized I had a huge problem. I tried to fix it, but in the end this untenable mess had to go and I had to start from the ground up.

In this post I share some of the lessons I learned and a recommendation to use some tools to save time.

Desing for mobile first

One of the simple but important lessons I learned is to design the site for mobile first, rather than desktop. Since mobile is more restrictive, due to its limited horizontal space, it lends itself to linear layouts. This forces you to keep your layout simple, so you’ll be making decisions about what to show or what to keep, instead of focusing on how you want to display it.

This step takes place before you even start writing the first line of HTML or CSS, so it should be quick to iterate until you find a design you’re comfortable with.

Responsive elements: water.css

A friend introduced me to this wonderful tool. It’s a ready-made collection of styles that make HTML elements look good while keeping them responsive. To put it simply: instead of painstakingly going over every element on your site and writing CSS to make sure they scale well, you can just re-use someone else’s CSS!

You only need to do a couple of things to start using it. You want to make your website aware of the device’s resolution with the viewport tag and import the water.css stylesheet. Like this:

<head>
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/water.css@2/out/water.css">
</head>

This is just an example. There are other tools similar to this one out there. Tailwind, Materialize or Foundation for Apps might be the right thing for you. But these are frameworks and they require some learning. If what you want is taking it easy, just use water.css.

Responsive layout: flexbox and grid layout

In my initial search for modern responsive techniques, I came across this video by Una Kravets (@una) where she talks about flexbox and grid layouts.

Watch it from beginning ’til end, it’s worth your time. There is also this website version in case you want to play around with the result or you want a convenient cheat sheet.

As a quick takeaway: if you need to position two elements in a row and you need them to scale, you can create a parent element with display: flex;. Then you define what percentage those elements will take with flex: 50%. The flexbox will then take care of scaling them for you, and if you add flex-wrap: wrap; to the parent, it will position them in a new row when they can’t fit in the screen.

<div style="display: flex;">
  <p style="flex: 60%;">
    This column takes 60% of the available space.
  </p>
  <p style="flex: 30%;">
    This one just 30%.
  </p>
</div>

This column takes 70% of the available space.

This one just 30%.

Conditions: media queries

There are some cases where you want to show something just on desktop. Or maybe you need to move an element to the next row when browsing on mobile. You can do that with media queries.

The idea behind them is easy to understand. You can think of them as simple conditions. Is the screen bigger than 500px? Is the site being browsed in a mobile device in portrait mode? Then apply these CSS rules.

Example

@media (min-width: 500px) {
  /*the style for this class will only be applied when the screen's width is 500px or more*/
  .normal-css {
    background-color: white;
    color: black;
  }
}

@media (orientation: portrait) {
  /*the style for this class will only be applied when the device is in portrait mode*/
  .normal-css {
    background-color: white;
    color: black;
  }
}

An example of how to use it in combination with the flexbox layout is to position a horizontal line of elements vertically. In the following example the boxes will be positioned vertically, since they’re set to fill 100% of the flexbox with flex: 100%;. But if the viewport is bigger than 500px they’ll be positioned side by side, since they’ll have the property flex: 50%;.

Check the following example in a mobile device and in a desktop:

This column takes all horizontal space when the container is too small.

So this one is being pushed to the next row.

Example

CSS:

.example {
  flex: 100%;
}

@media (min-width: 500px) {
  .example {
    flex: 50%;
  }
}

HTML:

<div style="display: flex; flex-wrap: wrap;">
  <p class="example">
    This column takes all horizontal space when the container is too small.
  </p>
  <p class="example">
    So this one is being pushed to the next row.
  </p>
</div>

That’s all for now. I hope you found some of this useful!

API discovery in Android Apps and task automation

2020-11-06T00:00:00Z

Have you ever felt frustrated when using a mobile app because of any of the following reasons?

It lacks simple quality of life features like filtering, searching, automating actions, etc.
It is poorly optimized and it is extremely laggy. Or maybe it takes too long to load.
It doesn’t show a lot of information on screen, since images and buttons have to be BIG for a mobile app. Or the complete opposite, the interactable elements are too small or don’t work well. The UX is terrible in both cases.
It takes up too much space on the phone’s storage.

If you can relate with any of those reasons, I’m right there with you. You could ditch that application, but if you really want to use it, I’ve got good news: there is a way around it. It involves learning about cyber-security, reverse engineering an API and automating nearly anything that matters in an app.

Overview

Summary: We will perform a MITM attack by installing a custom CA in an Android emulator and scripting the API requests we intercept. If you understand that, go to the next section already.

Normally we can’t see the traffic coming out of an App. It’s encrypted, and therefore it looks like random garbage to us. This keeps your information safe, at least during the transaction (what each ends does with the information and how they protect it is a different matter).

You might have heard about digital certificates. They are what make this encryption possible, and in order to know what certificates you can trust or not your devices depend on a Certificate Authority (CA). These are actors that can create digital certificates

But anyone can be a CA, or they can create one at least, so how do we know which CAs can we trust or not? Usually, your devices/applications come with a hardcoded set of CAs they trust by default. This is a good enough measure that mostly works, although these CAs then become very high value targets for hackers and you can believe some have been compromised before.

So, back to our little project. We want to be able to snoop into what our target app and their backend are talking about. In order to do that, we are going to force an Android emulator into sending all its network traffic through us and then make it think it can trust us. How we will do that is by installing our own certificate as one of those default CAs. This way, we will be able to understand the encrypted HTTPS messages any app sends and receives. This is what is known as a “Man in the Middle attack” (MITM) in cyber-security.

When we are able to understand what app and backend are saying to each other, we will begin investigating the now exposed API. If we’re lucky, we might even have the chance to automate our daily app usage into a script. That way we won’t even have to open the app again.

This post will be split in 3 parts:

Setting up the emulator
Configuring MITM proxy
Investigating the API and automating

Setting up emulator and app

Install the tools

If you don’t have the Android platform tools, we will install them now. I’m using Arch, so I will use these AUR packages:

You can install them like:

git clone https://aur.archlinux.org/android-sdk.git
cd android-sdk
makepkg -si
cd ..
git clone https://aur.archlinux.org/android-sdk-platform-tools.git
cd android-sdk-platform-tools
makepkg -si

It shouldn’t be too difficult to find out how to install them on another platform. For instance, if you’re on Ubuntu, you can just do:

sudo apt update && sudo apt install android-sdk

On Mac (assuming you have Brew installed):

brew tap caskroom/cask
brew cask install android-sdk

Install the system image

Once we have the tools we need, we can download the system image. Since we want to download an app from the Play Store, we will need that the image we use includes the Google API. We want to find a an image containing “google_apis”, but not “google_apis_playstore”. Why not get the one that comes with the Play Store pre-installed, you ask? Well, those are production builds and we won’t be able to root them. We will need rooting our emulator later.

I chose the “android-25” one, but you can choose another one if you want.

sdkmanager --list | grep "google_apis" #select another image from this list if you want
sudo sdkmanager --install "system-images;android-25;google_apis;x86_64"

Create the AVD

After accepting the license and waiting for the download to finish, we can finally create our AVD.

avdmanager create avd --name "mitm-emulator" --package "system-images;android-25;google_apis;x86_64"

And open it with:

emulator -avd mitm-emulator &

Installing Google Play

Download Open GApps for your system image from https://opengapps.org/. We will need them to download the target app from the Play Store. We can extract it with:

unzip open_gapps-*.zip 'Core/*'
rm Core/setup*
lzip -d Core/*.lz
for f in $(ls Core/*.tar); do
  tar -x --strip-components 2 -f $f
done

Then, we run our emulator and install the packages:

emulator -avd "mitm-emulator" -writable-system &

Wait for the loading to finish. As soon as the home screen is shown, copy the Open GApps folders to your system.

adb root
adb remount
adb push etc /system
adb push framework /system
adb push app /system
adb push priv-app /system

We can now restart the emulator.

adb shell stop
adb shell start

After the loading finishes, you will see the Play Store in your home screen.

Install the target app

This should be the easiest step. Just log into the Play Store and download the target app.

Make sure you can open it before proceeding.

Setting up the proxy

Install MITM proxy

Now we will install and configure our proxy. We will be using mitmproxy, an MIT licensed open source tool built just for MITM attacks.

It can easily be installed from Arch’s official repositories with:

pacman -Sy mitmproxy

It seems on Ubuntu you will need to install pip and then install mitmproxy using it.

sudo apt install python3-pip
sudo pip3 install mitmproxy

On Mac, just use Brew again:

brew install mitmproxy

To test it out, let’s start the emulator and open its settings by clicking on the 3 dots button. Then, navigate to the settings section, select the Proxy tab and configure it to use http://127.0.0.1:8080 as a proxy, like in the image below.

Run mitmproxy listening in 127.0.0.1:8080 in a terminal, like this:

mitmproxy --listen-host 127.0.0.1 --listen-port 8080

We can now go back to the emulator and navigate anywhere. You will see it’s almost as if your device lost connection, and if you try to use a web browser, a warning about your connection not being private will appear.

This happens because mitmproxy signs HTTPS traffic with its own certificate. Since the emulator doesn’t trust that certificate (yet), it won’t even accept that response! If you go to the terminal where you launched mitmproxy, you should see something like this. Notice all the traffic is HTTP, there are no HTTPS messages.

To continue, we will need to make the emulator trust mitmproxy’s Certificate Authority.

Install the Certificate Authority

The way mitmproxy works is it has its own Certificate Authority. It uses it to generate certificates on the fly for whatever external resource the emulator asks for. It then uses those certificates to encrypt the messages sent to it, making it seem like the emulator is talking with the real server. In reality, though, it is decrypting and encrypting all the messages with its own certificates, so it knows everything the client and server are talking about. And neither of them knows it is spying on them.

If you read the documentation for mitmproxy you will see there are official instructions on how to install the certificate on mobile devices: you visit “mitm.it” in the browser, download the certificate and install it. Then you can see decrypted HTTPS traffic in mitmproxy… but just the traffic generated by the browser.

If we want to read HTTPS traffic from native apps, we need to install it as a system certificate. We will need root privileges for that, so we will launch the emulator specifying:

emulator -avd mitm-emulator -writable-system &
adb root
adb remount

Now we need to find our certificate file. If you are using Linux, it will be in the ~/.mitmproxy/ folder. Let’s save it to a variable named “CA”:

CA=~/.mitmproxy/mitmproxy-ca-cert.pem

We just need to copy that file into the emulator’s trusted CAs folder, but it needs to be named with a special value. The filename must be the hash of the certificate itself. You can calculate it with the following command:

HASH=$(openssl x509 -noout -subject_hash_old -in "$CA")

But since mitmproxy uses the same default certificate everywhere, we know the value should be c8750f0d, so you can skip this step and just use that value. You can always come back and use the previous line to recalculate the value if it doesn’t work 😛

So you can just do:

adb push "$CA" /system/etc/security/cacerts/c8750f0d.0

If you try to load a website now, it should load correctly and you should see traffic being detected by mitmproxy. Moreover, if you try to open the target app, you should see its traffic too! Congratulations!

Don’t forget to unroot the device before you continue.

adb unroot

Exploitation

Investigating the API

To begin, let’s just use the app normally. Create an account with username and password (avoid authenticating with Google or Facebook for now, you don’t want to have to deal with OAuth). Log in, search and browse some items… We just want to generate some traffic so that we can inspect it later.

Now we can go back to our terminal and check the messages mitmproxy caught. We have to locate the traffic from the target app. To do so, just browse the captured requests list and see if any URL matches the app’s domain. Alternatively, you could look for endpoints that match actions you performed (like a login, search, etc.).

If you’re lucky, your target API will use a human-readable document format like JSON or XML, instead of protobuf. We are lucky and our target uses JSON.

This means we can easily replicate that request in the terminal.

In the terminal running mitmproxy, enter w. You will enter export mode. If you then type export.clip curl @focus, your request will be replicated as a curl command and it will be copied to your clipboard. You can then paste it on your terminal to see if it works.

For my particular case I had to make 2 changes for it to work:

Remove the :authority pseudo-header that looked like -H ':authority: domainname.com'.
Change the IP address for it’s domain name in the URL (https://1.2.3.4/v1/endpoint => https://domainname.com/v1/endpoint).

Automating queries

From this point on, it’s just a matter of exploring and seeing what can you do with the endpoints you discover. It’s just like learning any regular new API.

For example, I wanted to automate a search for a restaurant. It has to be near me (<1km), it cannot be a bakery and I just want to know the name, price and pickup time.

function get_store_list() {
  curl https://x.x.x.x/get_store_list?...
}

result=$(get_store_list\
| jq '.groupings[].items[]' \\ # get all stores
| jq 'select(.distance < 1)' \\ # filter out stores further than 1 km away
| jq 'select(.item.item_category != "BAKED_GOODS")' \\ # filter out unwanted store categories
| jq '(.store.store_name + ", "
+ (.item.price.minor_units/100 | tostring) + "€, "
+ .pickup_interval.start)' \\ # print just the wanted data: store name, price and pickup time
| sort | uniq) # sort and show only unique results

notify-send -t 30000 "$result" # send a notification in Linux desktop
# or
termux-notification --content "$result" # send a notification in Android's Termux

This shows a simple list like this one as a notification:

"Store name 1, 3.99€, 2020-11-04T19:00:00Z"
"Store name 2, 4.99€, 2020-11-04T15:00:00Z"
"Store name 3, 4.99€, 2020-11-04T15:00:00Z"
"Store name 4, 2.99€, 2020-11-04T19:00:00Z"
...

It can be then saved as a script and run as a cron job everyday at certain time (lunchtime?). This will notify me about available stores to get food from.

Do once. Run forever. Ok, run until the API changes or something breaks, but still, it’s less worrisome than opening the app and searching manually.

Links of interest

If you want to know more about this topic, I encourage you to follow these links and search for more information.

Setting up mitmproxy for Android emulator, Jonathan Lipps (2019 Apr 3): link
Installing Open GApps, Daishi Kato (2017 Mar 6): link
Why you need a Google API image, “oenpelli” on StackOverflow (2014 Jul 18): link
mitmproxy docs: link

A universal document language

2020-08-12T00:00:00Z

I love Markdown. It’s a simple to use, minimalist markup language. It’s completely text based, so it’s very lightweight and it works extremely well when used with a VCS like Git. Here is an example:

---
title: 'My document'
author:
* John Doe
---

Paragraph

* List item 1
* List item 2

## Section 2

Another paragraph

And not only can you use it for text files, you can use it to generate other types of documents as well.

Converting documents

There are multiple tools to achieve this, but today I want to talk about Pandoc. Pandoc is a universal document converter. It allows converting from and to different formats, like from Open/Libre Office’s ODT to Microsoft Word’s DOCX or viceversa. From word processor formats like the previous 2, to HTML, PDF, Slides, Wiki, TeX… and the best of all: it allows converting to and from Markdown.

Why is this good? Well, you can write a document in Markdown and maintain a local git repository for it, so you can keep a history of the changes you made. And then you can convert it to a PDF/Word format, so a colleague can read your notes in visual form. With the same file, you can even convert it to a slideshow format, so you can present it in front of people. Need to add this info in a web page? You just convert it to HTML. It is extremely flexible. And if you already take notes in Markdown, the process to adapt your notes to another format/document is trivially easy and quick.

# Markdown to ODT
pandoc document.md -o 

# Markdown to PDF (using xelatex)
pandoc document.md --pdf-engine=xelatex -o document.pdf

# Markdown to HTML
# -s (for standalone) is optional, used to generate tags 
# like the headers, body, etc. and make a whole HTML file
pandoc document.md -s -o document.html

# Markdown to slideshow (using Beamer)
pandoc document.md -t beamer -o slides.pdf

Not convinced yet? What if I told you you could automate the styling of the document? That would allow you to focus on the content and leave the formatting to Pandoc. That can be easily achieved with a custom template.

Writing your own template

Writing your own template is easy to do. Let’s take an HTML template as an example. We start by making a dummy HTML:

<html>
  <head>
    <link rel="stylesheet" type="text/css"...
    ...
  </head>
  <body>
    <h1>Title</h1>
    <p>Lorem ipsum...</p>
  </body>
</html>

Then we can use the default template as a reference to start building our own. You can use the -D option to get the standard template for a format, like this:

pandoc -D html > template.html

From the get go, we see properties like “author-meta”, “date-meta” or “keywords”. To keep this post short I’ll just stick to the “title” and “body”, but you can read the official documentation if you want to see all you can do with it. You can also use conditionals, loops and embed templates on other templates, if you need to do something more complex. But let’s go back to our example.

To use these properties in our document, we can use either of two formats:

$prop$
${prop}

So to add the title and the content of our document to our HTML template, we just need to do:

<html>
  <head>
    <link rel="stylesheet" type="text/css"...
    ...
  </head>
  <body>
    <h1>${title}</h1>
    <p>${body}</p>
  </body>
</html>

And, using the example Markdown document at the beginning of the article, the resulting HTML would look like:

<html>
  <head>
    <link rel="stylesheet" type="text/css"...
    ...
  </head>
  <body>
    <h1>My document</h1>
    <p>Paragraph</p>
    <ul>
      <li>List item 1</li>
      <li>List item 2</li>
    </ul>
    <h2>Section 2</h2>
    <p>Another paragraph</p>
  </body>
</html>

The best part is that you don’t even need to write your own template. You can just search for more on the Internet. There is a selection of them in Pandoc’s official repository.

Conclusion

The key takeaway from this post is this: Markdown emphasizes focusing on the content, not the style. Pandoc allows us to keep these two tasks separated. By using it, we can write our documents in Markdown and rely on our template to apply the style in the end, automatically.