Recetas·Ubuntu·VSCode

Usando vscode-chrome-debug como extensión de workspace

Visual_Studio_code_logo-274x300

Escenario:

  • VSCode con las extensiones de Remote Development instaladas.
  • Desarrollo en contenedores Docker.
  • Imagen Docker con chrome instalado.
  • Chrome no instalado en la máquina host.
  • Queremos utilizar el chrome del contenedor Docker para depurar nuestras aplicaciones.

Guía paso a paso:

  • Utilizar un Dockerfile basado en una imagen con chrome instalado (en mi caso, utilizo una imagen basada en Ubuntu 18.04 y personalizada para mis necesidades de desarrollo)

    FROM rubensa/ubuntu-tini-dev-chrome
    # Keep container running (for use in VSCode)
    CMD [ “tail”, “-f”, “/dev/null” ]
  • En el fichero devcontainer.json añadir la extensión Debugger for Chrome y forzarla para se se ejecute en “workspace” (en vez de en “ui“)
    {
      ...
      "extensions": [
        // Chrome debugger
        "msjsdiag.debugger-for-chrome"
      ],
      "settings": {
        "remote.extensionKind": {
          // Force chrome debugger extension installation on container
          "msjsdiag.debugger-for-chrome": [
            "workspace"
          ]
        }
      },
      ...
    }

    NOTA: para que esto funciona, también es necesario instalar la extensión localmente (pero manteniéndola deshabilitada Locally y habilitada en Dev Container)

  • Configurar los siguientes argumentos Docker dentro del fichero devcontainer.json
    {
      ...
      "runArgs": [
        // X11 Unix-domain socket
        "--mount",
        "type=bind,source=/tmp/.X11-unix,target=/tmp/.X11-unix",
        "--env=DISPLAY=unix${localEnv:DISPLAY}",
        // Allow shared memory to avoid RAM access failures and rendering glitches due to X extesnion MIT-SHM
        "--ipc=host",
        // The kernel requires SYS_ADMIN for Chrome sand-box
        "--cap-add",
        "SYS_ADMIN",
        // $(id -u):$(id -g)
        "-u",
        "1000:1000"
      ],
      ...
    }
    

    En mi Dockerfile particular debo especificar en devcontainer.json que VSCode no sobreescriba el comando por defecto de mi imagen.

    {
      ...
      "overrideCommand": false
      ...
    }
    

Ahora, al abrir tu proyecto en Remote – Containers, podrás depurar el código dentro del contenedor.

Recetas·VSCode

VSCode Live Share login manual

vscode-liveshare-logo

  • Haz login usando cualquier cuenta en la página: https://prod.liveshare.vsengsaas.visualstudio.com/auth/login
    Screenshot from 2020-02-19 16-54-21
  • Tras el flujo de autentificación se te redirecciona a la página “Ready to collaborate
    Screenshot from 2020-02-19 16-55-38
  • Pulsa en el enlace “Having trouble? Click here for user code directions
    Screenshot from 2020-02-19 16-56-26
  • Abre la paleta de comandos del VSCode y escribe > live share: Sign in with user code
    Screenshot from 2020-02-19 17-00-47
  • Pega el código de usuario que has copiado del navegador.

NOTA: El código de usuario solamente es válido durante 2 minutos (comenzando desde que se te muestra la página “Ready to collaborate”)

GIT·Recetas·VCS

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

git

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. 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

Recetas·Ubuntu

Usando dig para consultar un servidor DN específico

dns

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

Recetas·Ubuntu

Tooltips en negro en Gnome 3

gnome-logo-icon

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

Programación·Recetas·Ubuntu

Spring Boot live application information en VSCode

spring-bool-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

Recetas·Ubuntu

Construcción de los paquetes debian de network-manager-l2tp

network-manager-l2tp

Recetas·Ubuntu

Usando los comandos apt en Linux

apt-package-manager
APT (Advanced Package Tool) es una herramienta de línea de comandos para interactuar con el sistema de paquetes de Debian (y derivados). Aunque ya existe el comando dpkg para manejarlo, apt es más amigable. Se puede utilizar para buscar, instalar nuevos paquetes, actualizar paquetes, eliminarlos, etc.

  • sudo apt update
    Actualiza la base de datos de paquetes.
  • sudo apt upgrade
    Actualiza los paquetes instalados a su versión más reciente disponible.
  • sudo apt full-upgrade
    Igual que upgrade excepto que si la actualización del sistema requiere la eliminación de algún paquete previamente instalado, esta también se lleva a cabo
  • sudo apt install
    Instala un nuevo paquete (soporta autocompletado) o lo actualiza si está previamente instalado
  • sudo apt install
    Instala múltiples paquetes
  • sudo apt install –no-upgrade
    Instala un nuevo paquete pero no lo actualiza si ya está instalado previamente
  • sudo apt install –only-upgrade
    Actualiza un paquete pero no lo instala si no estaba previamente instalado
  • sudo apt install =
    Instala una versión concreta de un paquete
  • sudo apt remove
    Elimina un paquete previamente instalado (soporta autocompletado)
  • sudo apt purge
    Elimina un paquete junto con sus fichero de configuración
  • apt search
    Busca todos los paquetes que contienen el término de búsqueda
  • apt show
    Muestra el contenido de un paquete
  • apt list –upgradeable
    Muestra todos los paquetes que tienen una nueva versión lista para actualizada
  • apt list –installed
    Muestra todos los paquetes instalados en el sistema
  • apt list –all-versions
    Muestra todos los paquetes disponibles para tu sistema
  • sudo apt autoremove
    Elimina librerías y paquetes instalados automáticamente para satisfacer las dependencias de otro paquete instalado
  • sudo apt edit-sources
    Abre el fichero sources.list en el editor que elijas

Algunos enlaces de interés
Using apt Commands in Linux [Complete Guide]
Difference Between apt and apt-get Explained

GIT·Recetas

GIT: Mantén tu fork actualizado

git

  1. Clona tu fork:
    git clone git@github.com:YOUR-USERNAME/YOUR-FORKED-REPO.git
  2. Añade el remote del repositorio original a tu repositorio:
    cd into/cloned/fork-repo
    git remote add upstream git://github.com/ORIGINAL-DEV-USERNAME/REPO-YOU-FORKED-FROM.git
    git fetch upstream
  3. Actualiza tu fork a partir del repo original para mantener actualizados sus cambios:
    git pull upstream master
  4. Sube tus cambios:
    git push

vía

Recetas·Ubuntu

template.desktop

freedesktop
.local/share/applications

[Desktop Entry]
Version=1.0
Name=ProgramName
Comment=This is my comment
Exec=program %U
Icon=ProgramName
Terminal=false
Type=Application
Categories=Utility;Application;
StartupWMClass=ProgramName

##Define Actions

Actions=Action1;Action2

[Desktop Action Action1]
Name=Action1
Icon=ProgramName-Action1
Exec=program –action1

[Desktop Action Action2]
Name=Action2
Icon=ProgramName-Action2
Exec=program –action2

##End of actions menu