Port forwarding en VSCode Remote Development

Trabajando en un proyecto en Angular usando la extensión de desarrollo remoto que VSCode tiene para poder desarrollar dentro de un contenedor Docker, me encontré con un extraño comportamiento:

Al arrancar el servidor de desarrollo de Angular mediante ng serve, en la consola del VSCode se me mostraba el típico mensaje con el enlace para abrir la aplicación en el navegador.

** Angular Live Development Server is listening on localhost:4200, open your browser on http://localhost:4200/ **

Lo curioso del caso es que al pulsar (Ctrl+Click) en dicho enlace se me habría el navegador en la URL http://127.0.0.1:40999/ en vez de http://localhost:4200/.  Es más, si intentaba acceder a http://localhost:4200/ no podía acceder a la aplicación. 

Y todo esto, habiendo publicado el puerto en el fichero devcontainer.json


...
"appPort": [
// Front-end development (Angular server)
"0.0.0.0:4200:4200"
],
...


Limpieza de ramas locales tras el merge y borrado en el servidor central

Si utilizas Github o Gitlab, seguramente estará familiarizado en los Pull Requests o Merge Requests. Ambos tienen una opción para eliminar una rama tras hacer el merge del Pull/Merge Request.

El problema es que dicha opción solamente borrará la rama en el repositorio remoto. Ahora bien, cómo podemos «limpiar» nuestras ramas locales?

Supongamos que tenemos la rama «feature»

1. 1. Listado de ramas en el equipo local
      El comando git branch -a muestra que la rama «feature» existe en local pero también muestra la referencia a la rama remota inexistente.

      $ git branch -a
      feature
      * master
      remotes/origin/master
      remotes/origin/feature

   2. «Limpieza» de las referencias locales a las rama remotas
      El comando git remote prune origin --dry-run hace una «simulación» (--dry-run) de «limpieza» de ramas remotas (porque ya no existen en el servidor remoto).

      $ git remote prune origin --dry-run
      Pruning origin
      URL: git@github.com:rubensa/repo.git
      * [would prune] origin/feature

      Una vez comprobado que todo es correcto, podemos proceder a ejecutar realmente el comando de borrado.

      $ git remote prune origin
      Pruning origin
      URL: git@github.com:rubensa/repo.git
      * [pruned] origin/feature

      Una vez mas, ejecutando el comando git branch -a se nos mostrará el estado local de las ramas.

      $ git branch -a
      feature
      * master
      remotes/origin/master

      Podemos ver que remotes/origin/feature ha sido eliminada, pero no así la rama local feature.

   3. Eliminación de rama local
      Si queremos, también podemos «limpiar» la rama local feature:

      $ git branch -d
      Deleted branch feature (was 6493f15).

       

vía

Usando dig para consultar un servidor DNS específico

Hay ocasiones en la que puedes necesitar consultar un servidor DNS directamente. Por ejemplo, antes de cambiar los servidores DNS de un dominio, puedes configurar los nuevos registros en los nuevos servidores DNS y entonces consultarlos directamente para asegurarte de que tienen los registros correctos.

dig te permite especificar un servidor de nombres junto con el registro que quieres consultar.

Por ejemplo, uno de los servidores DNS de rubensa.eu.org es «freedns1.registrar-servers.com«. Podemos consultar en este servidor directamente el registro www mediante:

$ dig rubensa.eu.org @freedns1.registrar-servers.com

Lo que nos dará una salida con una sección de título Answer Section:

;; ANSWER SECTION:
rubensa.eu.org. 1800 IN A 185.199.109.153
rubensa.eu.org. 1800 IN A 185.199.108.153

En ella se detalla el resultado (185.199.109.153) así como el TTL del registro (en segundos). El TTL es importante, ya que indica el tiempo que los servidores DNS pueden cachear el resultado.

Puedes hacer lo mismo para comprobar otros registros como, por ejemplo, los registros MX, simplemente añadiendo el tipo de registro al comando. Por ejemplo:

$ dig MX rubensa.eu.org @freedns1.registrar-servers.com

devolverá:

;; ANSWER SECTION:
rubensa.eu.org. 1800 IN MX 20 mx2.zoho.com.
rubensa.eu.org. 1800 IN MX 10 mx.zoho.com.
rubensa.eu.org. 1800 IN MX 50 mx3.zoho.com.

Aquí podemos ver que el TTL es de 1800 segundo (30 minutos) y que el nivel de prioridad de servidor va de mx.zoho.com a mx3.zoho.com.

vía

Tooltips en negro en Gnome 3

Al ejecutar aplicaciones gráficas en docker, me he encontrado con problemas con los tooltips de las mismas, de modo que era imposible verlos ya que solamente aparecía un cuadro totalmente en negro.

La solución pasa por personalizar los colores del theme de Gnome 3 de mi host (Ubuntu 19.10).

Para hacer esto, basta con crear el fichero ~/.config/gtk-3.0/gtk.css con el siguiente contenido:

@define-color base_color #ffffff;
@define-color tooltip_bg_color #00ff00;
@define-color tooltip_fg_color #ff0000;
@define-color theme_tooltip_bg_color @tooltip_bg_color;
@define-color theme_tooltip_fg_color @tooltip_fg_color;

tooltip {
  padding: 5px 5px 5px 5px;
  margin: 0px 0px 0px 0px;
    border-width: 1px;
    border-style: solid;
    border-radius: 0px;
    border-color: #ffffff;
    background-image: none;
    background-color: #ffffff;
    color: #454545;
    border: 0px;
}

tooltip * {
    background-color: #ffffff;
    font-weight: bold;
    padding: 5px 5px 5px 5px;
    margin: 0px 0px 0px 0px;
    border-width: 1px;
    border-style: solid;
    border-color: @tooltip_bg_color;
    color: #454545;
    text-shadow: 5px 5px 3px #bbbbbb, 7px 7px 3px #ccccFF;
}

vía

Spring Boot live application information en VSCode

En las últimas versiones de Spring Boot, el soporte JMX no está habilitado por defecto.  Para habilitarlo, es necesario arrancar la aplicación con algo como esto:

java -Dspring.jmx.enabled=true -Dspring.application.admin.enabled=true -jar target/spring-petclinic-2.2.0.BUILD-SNAPSHOT.jar

En VSCode, la extensión al arrancar la aplicación usando el SPRING-BOOT DASHBOARD ya se establece a true la propiedad spring.application.admin.enabled pero no ocurre lo mismo con spring.jmx.enabled.

Para conseguirlo tenemos que abrir el fichero .vscode/launch.json y añadir el parámetro de configuración vmArgs con dicho valor:

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "type": "java",
            "name": "Debug (Launch)-PetClinicApplication",
            "request": "launch",
            "cwd": "${workspaceFolder}",
            "console": "internalConsole",
            "stopOnEntry": false,
            "mainClass": "org.springframework.samples.petclinic.PetClinicApplication",
            "projectName": "spring-petclinic",
            "args": "",
            "vmArgs": "-Dspring.jmx.enabled=true"
        },
        {
            "type": "java",
            "name": "Debug (Attach)",
            "request": "attach",
            "hostName": "localhost",
            "port": 0
        }
    ]
}

Además, en el spring-boot tooling, el language server ya no se auto conecta con la mayoría de procesos (una excepción son las aplicaciones lanzadas por el Boot Dashboard de Eclipse).  Esto lo tienes que hacer explícitamente en VSCode del siguiente modo:

1. Pulsa CTRL-SHIFT-P
2. Escribe ‘live‘
3. Selecciona el comando ‘Manage Live Boot Process Connections‘
4. Selecciona el proceso de tu aplicación y conéctate al mismo.

vía