Elección de credenciales con ssh agent forwarding

Supongamos que tenemos dos usuarios diferentes, uno empresarial y otro personal, que utilizamos en, por ejemplo GitHub.

Para poder hacer uso de las credenciales de ambos usuarios dependiendo del repositorio al que nos conectemos haremos algo similar a lo contado en Configurando múltiples claves SSH para diferentes cuentas github.

Ahora bien, ¿qué ocurre si queremos utilizar estas mismas credenciales desde otro equipo haciendo uso de ssh agent forwarding?

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

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.

VSCode Live Share login manual

• Haz login usando cualquier cuenta en la página: https://prod.liveshare.vsengsaas.visualstudio.com/auth/login
  
• Tras el flujo de autentificación se te redirecciona a la página «Ready to collaborate»
  
• Pulsa en el enlace «Having trouble? Click here for user code directions»
  
• Abre la paleta de comandos del VSCode y escribe > live share: Sign in with user code
  
  
• 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»)

Eclipse Linux: Unhandled event loop exception

A raíz de la última actualización de Ubuntu (pasando de 17.04 GNOME a 17.10) he tenido problemas («Unhandled event loop exception» al intentar cambiar de perspectiva utilizando la botonera) al ejecutar alguna versión de Eclipse (concretamente la 4.6.3, con la 4.7.l no he tenido problemas).

El problema parece estar relacionado con libwebkit y GTK3.

Para solucionarlo (forzando el uso de GTK2) he tenido que modificar el eclipse.ini para incluir:

--launcher.GTK_version
2

de tal modo que ahora queda algo así:

-startup
plugins/org.eclipse.equinox.launcher_1.3.201.v20161025-1711.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.1.401.v20161122-1740
--launcher.GTK_version
2
-product
org.eclipse.epp.package.jee.product
--launcher.defaultAction
openFile
-showsplash
org.eclipse.platform
--launcher.defaultAction
openFile
--launcher.appendVmargs
-configuration
/home/rubensa/development/eclipse/4.6.3/configuration
-data
/home/rubensa/development/eclipse/4.6.3/workspace
-vm
/home/rubensa/software/jdk1.8/bin/java
-vmargs
-Dosgi.requiredJavaVersion=1.8
-XX:+UseG1GC
-XX:+UseStringDeduplication
-Dosgi.requiredJavaVersion=1.8
-Xms256m
-Xmx1024m
-Dorg.eclipse.equinox.p2.reconciler.dropins.directory=/home/rubensa/development/eclipse/4.6.3/dropins

Algunos enlaces de interés
6 Tips To Make Eclipse Lighter, Prettier And More Efficient

Imposible conectar un proyecto SVN usando Subversive

Inicialmente tenía conectados en Eclipse varios proyectos con un SVN utilizando el plugin Subclipse.

Debido a unos problemas en la creación de patches, tuve que cambiar a Subversive.

El problema viene porque una vez eliminado el plugin de Subclise y añadido el de Subversive, la única opción que aparece al pulsar botón derecho sobre un proyecto –> Team, es «Apply Patch…»

Esto es debido a que Eclipse «recuerda» que el proyecto estaba conectado al SVN usando Subclipse (que ya no está disponible) y no me permite volver a conectarlo usando Subversive.

Para solucionarlo tenemos dos opciones.

La primera opción (des-instalar/re-instalar los plugins):

1. Des-instala Subversive
2. Re-instala Subclipse
3. Verifica que los proyectos están conectados al SVN
4. Botón derecho sobre el proyecto –> Team –> Disconect. Asegúrate de marcar «Do not delete the SVN meta-information (e.g. .svn subdirectories).
5. Des-instala Subclipse
6. Re-instala Subversive
7. Botón derecho sobre el proyecto –> Team –> Share Proyect…

La segunda opción (si no quieres des-instalar/re-instalar):

1. Crea un nuevo workspace vacío
2. Abre Eclipse utilizando dicho workspace
3. File –> Import –> General –> Existing Projects into Workspace
4. Selecciona el proyecto del viejo workspace
5. Botón derecho sobre el proyecto –> Team –> Share Proyect…

vía

Configuración de transacciones IMS en WebSphere Liberty Profile

A continuación se describen los pasos a seguir para configurar el acceso a transacciones IMS (Information Management System) desde WebSphere Liberty Profile.

WebShpere Liberty Profile, a partir de la versión 8.5.5.2, soporta la configuración de adaptadores de recursos que cumplan con la especificación Java EE Connector Architecture (JCA) 1.6, 1.5 o 1.0.

Configuración de transacciones CICS en WebSphere Liberty Profile

A continuación se describen los pasos a seguir para configurar el acceso a transacciones CICS (Customer Information Control System) desde WebSphere Liberty Profile.

WebShpere Liberty Profile, a partir de la versión 8.5.5.2, soporta la configuración de adaptadores de recursos que cumplan con la especificación Java EE Connector Architecture (JCA) 1.6, 1.5 o 1.0.

Configuración del entorno de ejecución del Websphere Liberty Profile

Partimos de que tenemos un Eclipse con las WAS Developer Tools (WDT).

Antes de comenzar vamos a descargar los archivos que contienen el runtime y otras características adicionales que vayamos a necesitar.

Por defecto, la configuración de un entorno de ejecución de Websphere Liberty Profile solamente incluye una serie de features (características) estándar y si queremos añadir soporte para alguna feature adicional debemos seleccionarla en el momento de la definición del runtime (no es posible añadirla «a posteriori» una vez configurado el entorno de ejecución).

Podemos descargar los ficheros desde la página de descargas de WASdev cuya versión actual 8.5.5.4 (Enero 2015) se puede descargar de https://public.dhe.ibm.com/ibmdl/export/pub/software/websphere/wasdev/downloads/wlp/8.5.5.4/

Caos invisible – dominando los espacios en blanco en Eclipse

¿Alguna vez has ojeado el código fuente Java de un colega que contenía una mezcla de espacios y tabuladores para la indentación, haciendo el código completamente ilegible? ¿O alguna vez has intentado comparar dos versiones de un fichero Java donde han cambiado los finales de línea, ofuscando la única línea de código que realmente ha cambiado? Esta entrada muestra un modo de dominar el infierno de los espacios en blanco a la hora de desarrollar con Eclipse.

Reposicionamiento de pestañas en Eclipse

Las últimas versiones de Eclipse han cambiado el modo que tenían de tratar las pestañas de edición.

En Indigo, cuando tenías 10 pestañas abiertas:

A | B | C | D | J | H | G ….(F | T | S)

y estabas posicionado en la B, al seleccionar de nuevo el fichero mostrado en la pestaña T, esta pestaña (al contrario de lo que ocurre en las últimas versiones) se reposicionaba para quedar al lado de la última abierta, es decir:

A | B | T | C | D | J | H ….( G | F | S)

Esto es útil ya que, si abrimos T después de B, tiene sentido que se agrupen juntas.

En Juno y Kepler no se reposicionan y en vez de eso tienes que buscar los ficheros más recientes al final de la lista de pestañas.

Para modificar este comportamiento (y volver al funcionamiento anterior) hay que editar las hojas de estilo que se encuentran en INSTALL/plugins/org.eclipse.platform_<<version>>/css y modificar el estilo:


.MPartStack {
swt-mru-visible: true;
}


vía

Algunos enlaces de interés
Eclipse4/CSS