gimco's tech disorder

U-Boot

Bruno Orcha García — Tue, 02 Jun 2020 00:00:00 +0000

Hace ya casi ¡10 años! que me compré un NAS para la casa. En su momento quería que tuviera dos bahías de discos duros poder configurar RAID y poder utilizar Linux, por lo que me decidí por un Iomega StorCenter ix2-200.

Despues de estar algunas semanas con el firmware original, decidí tomar el control completo del servidor e instalar Debian 6. Ha estado desempeñando sus múltiples labores a la perfección, pero debido a las obvias limitaciones y riesgos de seguridad por utilizar una versión tan antigua decidí actualizar el sistema. Comencé el proceso de actualizar entre las distintas versiones de debian, realizando varias veces los pasos de modificar el nombre de la release (squeeze → wheezy → jessie → stretch → buster) e ir actualizando:

# Modificar /etc/apt/sources.list 
apt-get update
apt-get upgrade
apt-get dist-upgrade

El problema es que en algún punto el sistema se rompió y tras uno de los reinicios ya no era capaz de conectar por SSH al servidor, y por lo tanto perdí el acceso al dispositivo (y parece que no soy el único al que le pasan estas cosas).

Conexión TTL UART

En estos casos, la mayoría de los dispositivos y microcontroladores proporcionan un mecanismo para acceder a una especie de consola o terminal mediante una conexión a un puerto serie. Necesitaremos hacernos con un dispositivo USB to TTL como el siguiente:

Una vez desmontado el dispositivo buscaremos en la placa las indicaciones para conectar los cables a los pines de transmisión, recepción, voltaje y tierra. Hay que informarse si trabaja a 3 o 5 voltios (y conectar en nuestro USBTTL el pin correspondiente), y recordar invertir el orden de los cables de transmisión y recepción.

También deberemos saber las opciones de transmisión que debamos configurar. Una vez enchufado nuestro USBTTL, consultamos los mensajes del kernel con dmesg para saber que nuevo dispositivo en /dev se ha creado. Una vez conectados todos los pines nos podremos conectar a nuestro dispositivo, usando alguna aplicación como Serial, o símplemente con el siguiente comando:

screen /dev/tty.SLAB_USBtoUART 11520

Al encender el NAS comenzaremos a ver mensajes del proceso de inicio interno!

         __  __                      _ _
        |  \/  | __ _ _ ____   _____| | |
        | |\/| |/ _` | '__\ \ / / _ \ | |
        | |  | | (_| | |   \ V /  __/ | |
        |_|  |_|\__,_|_|    \_/ \___|_|_|
 _   _     ____              _
| | | |   | __ )  ___   ___ | |_
| | | |___|  _ \ / _ \ / _ \| __|
| |_| |___| |_) | (_) | (_) | |_
 \___/    |____/ \___/ \___/ \__|
 ** MARVELL BOARD: RD-88F6281A LE

U-Boot 1.1.4 (Sep  8 2009 - 09:31:54) Marvell version: 3.4.14

Mapower version: 2.0 (32MB) (2009/09/08)

U-Boot code: 00600000 -> 0067FFF0  BSS: -> 006CEE60

Soc: 88F6281 A0 (DDR2)
CPU running @ 1000Mhz L2 running @ 333Mhz
SysClock = 333Mhz , TClock = 200Mhz

DRAM CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6
DRAM CS[0] base 0x00000000   size 256MB
DRAM Total size 256MB  16bit width
Flash:  0 kB
Addresses 8M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (8M - 7M): Done
NAND:32 MB

CPU : Marvell Feroceon (Rev 1)

Streaming disabled
Write allocate disabled

Module 0 is RGMII
Module 1 is TDM

USB 0: host mode
PEX 0: interface detected no Link.
Net:   egiga0, egiga1 [PRIME]
Fan lookup table initialized.

Current remote temperature: 47
Current fan speed: 0

Hit any key to stop autoboot:  0

Das U-Boot

Los mensajes que nos aparecen inicialmente son del bootloader utilizado por la placa de nuestro NAS. El bootloader es un mini programa ofrece algunas utilidades que nos permiten configurar y realizar algunas acciones para poder iniciar un sistema mas complejo, en nuestro caso, u-boot se encarga de cargar en la memoria el kernel de linux y proceder a su arranque.

Si pulsamos intro durante el arranque, podremos interactuar con la líneas de comandos de u-boot. Se ejecutamos help podremos ver todos los comandos que tenemos disponibles:

Marvell>> help
?       - alias for 'help'
base    - print or set address offset
boot    - boot default, i.e., run 'bootcmd'
bootd   - boot default, i.e., run 'bootcmd'
bootext2    dev:boot_part1,boot_part2 addr boot_image linux_dev_name 
bootm   - boot application image from memory
bootp   - boot image via network using BootP/TFTP protocol
bubt    - Burn an image on the Boot Nand Flash.
chpart  - change active partition
cmp     - memory compare
cmpm    - Compare Memory
cp      - memory copy
cpumap - Display CPU memory mapping settings.
crc32   - checksum calculation
date    - get/set/reset date & time
dclk    - Display the MV device CLKs.
dhcp    - invoke DHCP client to obtain IP/boot params
diskboot- boot from IDE device
echo    - echo args to console
eeprom  - EEPROM sub-system
erase   - erase FLASH memory
ext2load- load binary file from a Ext2 filesystem
ext2ls  - list files in a directory (default /)
fatinfo - print information about filesystem
fatload - load binary file from a dos filesystem
fatls   - list files in a directory (default /)
fi      - Find value in the memory.
flinfo  - print FLASH memory information
fsinfo  - print information about filesystems
fsload  - load binary file from a filesystem image
g       - start application at cached address 'addr'(default addr 0x40000)
go      - start application at address 'addr'
help    - print online help
icrc32  - checksum calculation
ide     - IDE sub-system
iloop   - infinite loop on address range
imd     - i2c memory display
imm[.b, .s, .w, .l]     - i2c memory modify (auto-incrementing)
imw     - memory write (fill)
inm     - memory modify (constant address)
iprobe  - probe to discover valid I2C chip addresses
ir      - reading and changing MV internal register values.
loop    - infinite loop on address range
ls      - list files in a directory (default /)
map     - Diasplay address decode windows
md      - memory display
me      - PCI master enable
mm      - memory modify (auto-incrementing)
mp      - map PCI BAR
mtdparts- define flash/nand partitions
mtest   - simple RAM test
mw      - memory write (fill)
nand                   - NAND sub-system
nboot   - boot from NAND device
nbubt   - Burn a boot loader image on the Boot Nand Flash.
nm      - memory modify (constant address)
pci     - list and access PCI Configuration Space
phyRead - Read PCI-E Phy register
pciePhyWrite    - Write PCI-E Phy register
phyRead - Read Phy register
phyWrite        - Write Phy register
ping    - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
protect - enable or disable FLASH write protection
rarpboot- boot image via network using RARP/TFTP protocol
rcvr    - Satrt recovery process (Distress Beacon with TFTP server)
reset   - Perform RESET of the CPU
resetenv        - Return all environment variable to default.
run     - run commands in an environment variable
saveenv - save environment variables to persistent storage
se      - PCI Slave enable
setenv  - set environment variables
sflash  - read, write or erase the external SPI Flash.
sg      - scanning the PHYs status
sp      - Scan PCI bus.
tftpboot- boot image via network using TFTP protocol
usb     - USB sub-system
usbboot - boot from USB device
version - print monitor version
Marvell>> 

Con el mando printenv podremos ver cuáles son las opciones configuradas en u-boot para realizar el inicio, y podremos ajustar la variables de entorno que precisemos (como por ejemplo agregar nuevos parámetros de inicio al kernel) y podremos guardar los cambios.

A continuación podemos ver la configuración actual de este dispositivo:

Marvell>> printenv
baudrate=115200
loads_echo=0
rootpath=/mnt/ARM_FS/
console=console=ttyS0,115200 mtdparts=nand_mtd:0xc0000@0(uboot)ro,0x1f00000@0x100000(root)
CASset=min
MALLOC_len=1
bootargs_root=root=/dev/nfs rw
bootargs_end=:::DB88FXX81:eth0:none
image_name=uImage
standalone=fsload 0x2000000 $(image_name);setenv bootargs $(console) root=/dev/mtdblock0 rw ip=$(ipaddr):$(serverip)$(bootargs_end) $(mvPhoneConfig); bootm 0x2000000;
ethmtu=1500
eth1mtu=1500
mvPhoneConfig=mv_phone_config=dev0:fxs,dev1:fxs
mvNetConfig=mv_net_config=(00:11:88:0f:62:81,0:1:2:3),mtu=1500
usb0Mode=host
yuk_ethaddr=00:00:00:EE:51:81
nandEcc=1bit
netretry=no
rcvrip=169.254.100.100
loadaddr=0x02000000
autoload=no
FanHysteresis=2
FanTempStart=58
ethprime=egiga1
eth1addr=00:D0:B8:16:51:14
uboot_start=0x0
uboot_size=0xc0000
env_start=0xa0000
env_size=0x20000
kernel_start=0x100000
kernel_size=0x300000
initrd_start=0x540000
flash_load=run make_boot_args load1 load2 boot
load1=nand read.e 0x2000000 $(kernel_start) $(kernel_size)
load2=nand read.e 0x4500000 $(initrd_start) $(initrd_size)
boot=bootm 0x2000000 0x4500000
make_boot_args=setenv bootargs console=ttyS0,115200 mtdparts=nand_mtd:;setenv bootargs $(bootargs)$(uboot_size)@$(uboot_start)(uboot),;setenv bootargs $(bootargs)$(env_size)@$(env_start)(env),;setenv bootargs $(bootargs)$(kernel_size)@$(kernel_start)(zImage),;setenv bootargs $(bootargs)$(initrd_size)@$(initrd_start)(initrd),;setenv bootargs $(bootargs)128m@0x0(flash);
iomega=123
ethaddr=AA:00:00:00:00:01
arcNumber=1682
filesize=69603a
fileaddr=5400000
netmask=255.255.255.0
ipaddr=192.168.1.11
serverip=192.168.1.10
bootcmd=run load1 load2 boot
bootargs=console=ttyS0,115200 mtdparts=orion_nand:0x300000@0x100000(uImage),0x1000000@0x540000(uInitrd) root=/dev/mapper/secure-root rootdelay=10
initrd_size=0x1000000
bootargs_console=console=ttyS0,115200 mtdparts=orion_nand:0x300000@0x100000(uImage),0x1000000@0x540000(uInitrd) root=/dev/mapper/secure-root rootdelay=10
stdin=serial
stdout=serial
stderr=serial
mainlineLinux=yes
enaMonExt=no
enaCpuStream=no
enaWrAllo=no
pexMode=RC
disL2Cache=no
setL2CacheWT=yes
disL2Prefetch=yes
enaICPref=yes
enaDCPref=yes
sata_dma_mode=yes
netbsd_en=no
vxworks_en=no
bootdelay=3
disaMvPnp=no
hddPowerCtrl=no
enaAutoRecovery=yes
ethact=egiga1

Environment size: 2264/16380 bytes
Marvell>> 

Enviar el nuevo kernel por tftp

De los mensajes de inicio, vemos que el dispositivo dispone de 256 megas de RAM y 32 megas de NAND. Al cargar el bootloader se hace una espera de unos segundos para comenzar a ejecutar los pasos que vemos en la variable bootcmd=run load1 load2 boot. El dispositivo leerá de la NAND y copiará el kernel y el initramfs a la memoria RAM para finalmente iniciar.

Si tenemos problemas porque hemos corrompido la NAND, tendremos que hacer llegar el nuevo kernel (e initramfs) que queremos grabar. Para esto podemos hacer uso de tftp. Los dos ficheros del kernel y del initramfs necesitan estar en un formato compatible con uboot. Si lo que queremos hacer es una instalación desde cero, en el caso de debian, podemos buscar la versión del instalador compatible con nuestro dispositivo.

En caso contrario, deberemos convertir los ficheros para poder ser procesados por uboot:

mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n "2.6.32.5-kirkwood" -d vmlinuz uImage
mkimage -A arm -O linux -T ramdisk -C none -a 0x01100000 -e 0x01100000 -n "2.6.32.5-kirkwood" -d initrd.img uInitrd

Colocamos la imagen del kernel y el initramfs en el directorio de nuestro servidor tftp y procedemos a recibir en el dispositivo los datos y cargarlos en las direcciones de memoria correspondientes:

dhcp
set serverip=192.168.x.y
tftpboot 0x2000000 uImage
tftpboot 0x5400000 uInitrd
bootm 0x2000000 0x5400000

Una vez hayamos probado que inicia bien con el kernel y el initramfs, lo podremos hacer permanente. Para ello, despues de reiniciar la máquina y volver a cargar en memoria los ficheros mediante tftp, procederemos a borrar la NAND y copiar de memoria RAM a NAND:

nand erase 0x100000 0x300000
nand erase 0x540000 0x300000
nand write.e 0x2000000 0x100000 0x300000
nand write.e 0x5400000 0x540000 0x300000

De esta forma, la próxima vez que iniciemos se procederá al inicio normal.

Buscando el kernel

Lo siguiente que hice fue buscar el kernel disponible en debian para mi arquitectura para extraer el kernel y el initramfs. Para ello instalé u-boot-tools para poder realizar la conversión con mkimage, descargué directamente el paquete y extraje el contenido:

apt install u-boot-tools
wget "http://ftp.us.debian.org/debian/pool/main/l/linux/linux-image-5.6.0-1-marvell_5.6.7-1_armel.deb"
ar x linux-image-5.6.0-1-marvell_5.6.7-1_armel.deb
tar xvf data.tar.xz

Una vez convertido el kernel y el initramfs, lo envié por tftp a la memoria del dispositivo. Pero al intentar iniciar el kernel me encontré con la desagradable sorpresa de que no iniciaba, ya que las opciones de compilación del kernel de debian no era compatible con mi dispositivo:

Error: unrecognized/unsupported machine ID (r1 = 0x00000692).

Compilar un kernel ARM

La única opción en este punto es comprobar si la arquitectura seguía estando disponbile de forma oficial y compilar un kernel con las opciones necesarias. Para ello hay que informarse bien del hardware del que disponemos, al menos CPU y tarjetas de red, para poder seleccionar en la configuración las opciones correctas. Para que sirva de referencia para el futuro, esta es parte de la información devuelta por el comando hwinfo sobre la cpu y la tarjeta de red del dispositivo:

----- /proc/cpuinfo -----
  Processor	: Feroceon 88FR131 rev 1 (v5l)
  BogoMIPS	: 990.41
  Features	: swp half thumb fastmult edsp
  CPU implementer	: 0x56
  CPU architecture: 5TE
  CPU variant	: 0x2
  CPU part	: 0x131
  CPU revision	: 1

  Hardware	: Marvell RD-88F6281 Reference Board
  Revision	: 0000
  Serial		: 0000000000000000
----- /proc/cpuinfo end -----

05: None 00.0: 0200 Ethernet controller
  [Created at pci.912]
  Unique ID: XveX.iOgNgvnpcfD
  SysFS ID: /devices/platform/mv643xx_eth_port.0
  SysFS BusID: mv643xx_eth_port.0
  Hardware Class: network
  Model: "Marvell MV64360/64361/64362 System Controller"
  Vendor: pci 0x11ab "Marvell Technology Group Ltd."
  Device: pci 0x6460 "MV64360/64361/64362 System Controller"
  Device File: eth0
  HW Address: aa:00:00:00:00:01
  Link detected: no
  Module Alias: "platform:mv643xx_eth_port"
  Driver Info #0:
    Driver Status: mv643xx_eth is active
    Driver Activation Cmd: "modprobe mv643xx_eth"
  Config Status: cfg=new, avail=yes, need=no, active=unknown

El proyecto debian tiene alguna información útil para ayudarnos a compilar un kernel para otra arquitectura o lo que es lo mismo, hacer crossbuild. Aunque no fue suficiente la simple compilación, ya que al parecer a partir de cierta versión del kernel, se comenzó a usar Device Tree, que son una especie de metadatos binarios que informan al kernel de distintas características hardware de la máquina.

Afortunádamente, encontré un post de un desarrollador que se encontraba en la misma tesitura que yo. Rebuscando dentro de los ficheros Makefile del kernel, conseguí seguir la pista para averiguar las opciones de compilación necesarias:

dpkg --add-architecture armel
apt-get update
apt-get install crossbuild-essential-armel
apt install sbuild
apt source linux-image-5.6.0-1-marvell
cd linux-5.6.7/
export ARCH=armel
export (dpkg-architecture -a$ARCH)
make menuconfig
make mvebu_v5_defconfig
make zImage
make dtbs
cat arch/arm/boot/zImage arch/arm/boot/dts/kirkwood-iomega_ix2_200.dtb > zImage-kirkwood-iomega
./scripts/mkuboot.sh -A arm -O linux -C none -T kernel -a 0x00008000 -e 0x00008000 -n 'Linux-5.6.7' -d ./zImage-kirkwood-iomega uImage-kirkwood-iomega

Finalmente conseguí iniciar un kernel mas moderno en este antiguo NAS (aunque se me olvidó meterle mano al tema de los leds), y de paso aprendí algunas cosillas por el camino. 🎉🎉

Multientidad con Hibernate 3

Bruno Orcha García — Wed, 27 Feb 2019 00:00:00 +0000

En una antigua aplicación se presentó la necesidad de agregar un nuevo conjunto de usuarios de forma que pudieran administrar sus datos y procedimientos de forma independiente al conjunto actual de usuarios. Estaríamos ante el clásico problema de la multientidad (multi-tenancy).

El término multientidad hace referencia a una arquitectura en la que una única instancia de la aplicación es capaz de dar servicio a varios clientes (entidades), muy común en sistemas SaaS (Software as a Service). El problema que se intenta resolver es el aislamiento de la información entre las distintas entidades.

En un sistema con soporte multientidad podemos crear distintos conjunto de datos independientes que serían nuestra entidades. Cada entidad tendrá su propio conjunto de información, usuarios, roles y administradores independientes de las otras entidades.

Tipo de multientidad

La aplicación en cuestión no fue creada con esta capacidad desde el principio, por lo que podríamos abordar este nuevo requisito de distintas formas:

Una instancia por entidad. Realizaríamos un nuevo despliegue para dar servicio a la nueva entidad. ¡Esto no dotaría a la aplicación de capacidad multientidad!, pero resolvería el problema de forma puntual. Un nuevo despliegue no requeriría la modificación de la aplicación actual, ya que sólo tendríamos que crear un nuevo entorno (con una url diferente) y una nueva base de datos. Esta no es una opción escalable, puesto que conforme aumenten el número de entidades desperdiciamos recursos y aumentamos la complejidad del mantenimiento.
Usar una base de datos distinta por entidad. En este caso modificaríamos la aplicación para que sea capaz de decidir qué conexión de base de datos se debe utilizar para cada petición solicitada.
Usar un esquema de base de datos por entidad. Este caso es similar al anterior pero sólo utilizamos una única base de datos (y un pool de conexiones común), y lo que hacemos es establecer el usuario o el esquema según cada entidad (utilizando CONNECT o ALTER SESSION SET CURRENT_SCHEMA).
Multientidad lógica. En este caso se utiliza una única base de datos y esquema, y agregamos un campo discriminador en cada una de las tablas que necesitemos independizar por cada entidad. Es decir, agregamos una nueva columna entidad a ciertas tablas que nos indica a que entidad corresponde cada fila de datos.

Las opciones mas populares son las dos últimas, y la utilización de una u otra lo marcará nuestras necesidades concretas. Por ejemplo, si la creación de nuevas entidades no forma parte de la lógica principal, y se realiza de forma esporádica (mediante intervención del equipo de sistemas o DBAs) optaremos por la opción de un esquema por entidad. Esta opción además tiene la ventaja de simplificar las copias de seguridad y restauración de los datos de la entidad.

Si por el contrario estamos creando una plataforma SaaS y queremos permitir que los usuarios puedan crear de forma autónoma nuevas entidades como parte del proceso de registro, probablemente usemos la última opción.

Impacto

En el caso concreto de esta antigua aplicación web se decidió utilizar la opción del campo discriminador. La librería de persistencia utilizada era Hibernate, la cuál tiene distintos tipos de soporte multientidad a partir de la versión 4.2. Desgraciadamente la versión utilizada era la 3.3 y el intento de actualización de las librerías desencadenaba la subida de versiones de otros módulos que tendrían un gran impacto en el código existente (dependency hell). Por lo que se decidió implementar la multientidad con la versión de Hibernate utilizada.

El primer paso sería agregar el campo discriminador entidad en cada una de la tablas que deban tener subconjuntos de datos independientes. Posteriormente tendríamos que modificar todas y cada una de las consultas HQL de la aplicación para agregar una nueva condición de la entidad, y cada uno de los métodos agregar el nuevo parámetro con el valor de la entidad que queremos consultar o modificar los datos. Por toda la aplicación estaríamos arrastrando el parámetro de la entidad activa para filtrar los datos adecuadamente. Haciendo esto estaríamos contaminando nuestro modelo para implementar un aspecto que debería ser transversal.

Implementación

Lo primero que haremos es modificar el esquema de base de datos y agregar las columnas que harán de discriminador en las tablas. Estas nuevas columnas pueden ser claves ajenas hacia una tabla donde almacenemos información adicional de la Entidad. Si alguna de las tablas tuviera claves únicas (por ejemplo alguna columna que fuera un código), tendríamos que modificar la condición del índice de unicidad para agregar la columna entidad. No es el caso de las claves primarias (y por tanto únicas) que suelen rellenarse a partir de un objeto secuencia.

Las columnas entidad solo serían necesarias en las tablas de primer nivel. Las tablas de primer nivel son aquellas que no dependen de otras. Por ejemplo, en una aplicación que gestionase facturas en la que todos los usuarios (de la misma entidad) pudiesen consultarlas indistintamente, la tabla Facturas serían un caso de tabla de primer nivel. Las tablas que almacensaen el detalle de estas facturas (las líneas de facturas por ejemplo) no necesitarían un campo discriminador, ya que siempre se obtendrían a partir de su tabla padre la cuál ya tendría asociada la entidad a la que pertenece. Es decir, la pertenencia del dato a la entidad se resuelve de forma transitiva a través de las tablas a las que apuntan las claves ajenas.

Para implementar el soporte multientidad de forma transparente aprovecharemos la funcionalidad de definición de filtros de Hibernate que nos permite activar o desactivar ciertas condiciones en la sesión de Hibernate para filtrar las consultas de datos. Después de realizar las modificaciones en el esquema de base de datos, crearemos un interfaz con los métodos getter y setter para este nuevo atributo discriminador. Cada clase de dominio de primer nivel que queramos independizar por entidad deberá implementar este interfaz.

//src/main/java/com/foo/bar/domain/FiltrarPorEntidad.java
public interface FiltrarPorEntidad {
    public static String FILTRO = "FILTRAR_POR_ENTIDAD";
    public Integer getEntidad();
    public void setEntidad(Integer entidad);
}

Lo siguiente será definir la condición y los parámetros del filtro que utilizaremos para filtrar los datos, tan simple como agregar la condición entidad = :entidad. El filtro lo definimos a nivel de paquete para tenerlo disponible de forma global para todas las clases de dominio.

//src/main/java/com/foo/bar/domain/package-info.java
@FilterDef(defaultCondition = "entidad = :entidad",
           name = FiltrarPorEntidad.FILTRO,
           parameters = @ParamDef(name = "entidad", type = "int"))
package com.foo.bar.domain;

import org.hibernate.annotations.FilterDef;
import org.hibernate.annotations.ParamDef;

Ahora tendremos que modificar cada una de las clases de dominio, indicando la disponibilidad del filtro por entidad, agregando el interfaz y el nuevo atributo:

 @Entity
 @Table(name="Nodo")
+@Filter(name=FiltrarPorEntidad.FILTRO)
-public class Nodo extends BaseEntidad
+public class Nodo extends BaseEntidad implements FiltrarPorEntidad 
+    private Integer entidad;
+
+    @Column (name = "ENTIDAD", nullable = false)
+    public Integer getEntidad() {
+        return entidad;
+    }
+
+    public void setEntidad(Integer entidad) {
+        this.entidad = entidad;
+    }
     ...
 }

Filtrando datos en las consultas

Ya tendríamos marcadas todas las entidades que necesitamos filtrar. Ahora tendríamos que activar el filtro en cada consulta que realicemos. Es habitual que nuestras clases de servicio o DAOs hereden de una clase base que agregue cierta lógica común. Aprovecharemos esta clase para activar el filtro cada vez que obtengamos el objeto sesión de Hibernate con la que ejecutamos las sentencias HQL:

public class BaseDO {
    ...

    protected Session getSession() {
        Session session = sessionFactory.getCurrentSession();
        session
            .enableFilter(FiltrarPorEntidad.FILTRO)
            .setParameter("entidad", getEntidadActiva());
        return session;
    }

    protected Query getNamedQueryPorEntidad(String queryName) {
        Session session = sessionFactory.getCurrentSession();
        Query query = session.getNamedQuery(queryName);
        query.setParameter("entidad", getEntidadActiva());
        return query;

    }

    static Integer getEntidadActiva () {
        // obtener la entidad activa actualmente
        // usando alguna clase utilidad o usando ThreadLocal 
    }

    ...
}

Una parte interesate es cómo saber qué entidad es la activa en cada momento. Esto dependerá de la arquitectura de cada proyecto. Lo mas habitual es crear algún tipo de Filter o Interceptor que se ejecute al principio de cada petición y que averigüe la entidad, ya sea viendo el dominio, la url, algún parámetro de sesión o extrayéndolo del usuario autenticado. Una vez averiguado estableceremos el valor de la entidad activa en alguna clase utilidad u objeto ThreadLocal que podamos consultar desde BaseDAO.getEntidadActiva().

Hasta aquí habríamos conseguido que de forma transparente cada vez que en una consulta aparezca alguna clase de dominio se agregue el filtro por entidad de forma automática.

Entidad en nuevos objetos

Ya tendríamos las consulta de datos filtrada pero nos quedaría la última parte, que sería establecer la entidad en los objetos de nueva creación. No queremos que los desarrolladores deban acordarse de llamar a los métodos setEntidad cada vez que vayan a persistir un nuevo objeto. Utilizaremos un listener de Hibernate para las operaciones de guardar o actualizar datos que registraremos en el framework de Hibernate mediante la creación de una clase de integración. Comenzamos por crear un fichero META-INF/services/org.hibernate.integrator.spi.Integrator que contendrá el paquete y clase que implementará esta integración:

//src/main/resources/META-INF/services/org.hibernate.integrator.spi.Integrator
com.foo.bar.domain.MultiEntidadIntegrator

La clase integración registrará nuestro listener que establecerá el campo entidad en los nuevos objetos que queramos persistir. Ademas, en el caso de las actualizaciones, comprobaremos que estamos modificando solamente objetos de la entidad activa, evitando por tanto que por error modifiquemos objetos que no pertenecen a la entidad del usuario que realiza la operación.

public class MultiEntidadIntegrator implements Integrator {

    @Override
    public void integrate(Configuration configuration,
                          SessionFactoryImplementor sessionFactory,
                          SessionFactoryServiceRegistry serviceRegistry) {

        final EventListenerRegistry eventListenerRegistry = serviceRegistry
            .getService(EventListenerRegistry.class);
        MultiEntidadListener el = new MultiEntidadListener();
        eventListenerRegistry.prependListeners(EventType.SAVE_UPDATE, el);
    }

    @Override
    public void integrate(MetadataImplementor metadata,
                          SessionFactoryImplementor sessionFactory,
                          SessionFactoryServiceRegistry serviceRegistry) {
    }

    @Override
    public void disintegrate(SessionFactoryImplementor sessionFactory,
                             SessionFactoryServiceRegistry serviceRegistry) {
    }
}

class MultiEntidadListener implements SaveOrUpdateEventListener {

    private static final long serialVersionUID = 1L;

    @Override
    public void onSaveOrUpdate(SaveOrUpdateEvent event) throws HibernateException {
        Object entity = event.getObject();
        if (entity instanceof FiltrarPorEntidad) {
            FiltrarPorEntidad e = (FiltrarPorEntidad) entity;
            Integer entidadActiva = BaseDAO.getEntidadActiva();
            if (e.getEntidad() == null) {
                e.setEntidad(entidadActiva);
            } else if (e.getEntidad() != entidadActiva) {
                String mensaje = String.format(
                    "Intento de cambiar un objeto %s de la entidad %d a la %d",
                    entity.getClass().getName(),
                    e.getEntidad(),
                    entidadActiva);
                throw new RuntimeException(mensaje);
            }
        }
    }
}

Conclusión

Con esta técnica hemos conseguido agregar el soporte multientidad a una aplicación existente para dar servicio a nuevos clientes minimizando el impacto necesario para llevarlo a cabo. También deberemos agregar una gestión mínima de entidades accesible por un perfil superadministrador que nos permita la creación de nuevas entidades.

Existen otros enfoques que también podrían haber sido interesantes de abordar como una solución PL/SQL completamente, mediante el uso de vistas de las tablas que filtren los datos según algún parámetro de sesión de base de datos que pudiéramos establecer (SYS_CONTEXT).

Y por último algunos enlaces de interés:

ANTLR

Bruno Orcha García — Sat, 26 Jan 2019 00:00:00 +0000

La asignatura de Compiladores en la Universidad fue la más intensa y extenuante con diferencia. Era una asignatura que condensaba una materia teórica amplia y densa en muy corto espacio de tiempo, donde romábamos apuntes a una velocidad endiablada, éramos aprendices de taquígrafos, fotocopiadores de pizarras. No en vano llamábamos a nuestra profesora Turbotere. Nuestra única salvación era acudir al legendario libro del dragón rojo para poder encajar todas las piezas y entender lo que estábamos haciendo. Fue mi primer contacto con las gramáticas, analizadores léxico-sintácticos y la utilización de las herramientas lex/flex/yacc/bison.

La segunda incursión fue mas satisfactoria con la utilización de ANTLR y la creación de un compilador para un lenguaje de programación pseudocódigo inventado. Ver que puedes programar usando un lenguaje que tú mismo has diseñado y que después puedes compilarlo y ejecutarlo como cualquier otro lenguaje es inspirador.

Aunque este tipo de herramientas son muy poderosas pertenecen una rama de la informática poco habitual para la gran mayoría de desarrolladores de aplicaciones web.

Refactorización

Durante la migración de una aplicación legacy con mas de dos décadas a sus espaldas y programada en el lenguaje de programación Natural de Software AG (un lenguaje similar a COBOL) tuve la oportunidad de volver a utilizar algunas de estas herramientas. Si bien, uno no de los primeros consejos cuando intentamos integrarnos o sustituir estos sistemas legacy es “don’t feed the monster” (implementar nuevo código en el sistema antiguo debería ser la última de nuestras opciones), mediante la creación de un parseador en ANTLR para el lenguaje NATURAL, pudimos analizar miles y miles de ficheros de código fuente y obtener información muy valiosa y precisa.

Por ejemplo, pudimos analizar las dependencias del sistema, obteniendo así un grafo de todas las llamadas e importaciones desde el módulo principal a los distintos módulos y librerías. Gracias a esto pudimos conseguir un listado exacto de los objetos realmente utilizados por la aplicación, pudiendo descartar centenares de subprogramas obsoletos que ya no se utilizaban (no eran invocados por nadie).

El entorno de desarrollo disponible para interactuar con este sistema es bastante arcaico, siendo la única herramienta disponible un simple buscar y reemplazar (y nada de expresiones regulares por supuesto).

Ya que con el parseador somos capaces de “entender” el código fuente, pudimos realizar refactorizaciones de código precisas de forma automática de distintas partes de la aplicación, pudiendo agregar por ejemplo llamadas de auditoria y notificación de eventos en las operaciones de modificación de base de datos por ejemplo.

Analizando la definición de los ficheros en la base de datos ADABAS que se utilizaba, creamos herramientas que generaban el código SQL DDL, triggers y PL/SQL necesario para exportar, replicar o sincronizar de forma bidireccional los datos en una base de datos Oracle con ADABAS.

Ejemplo

Históricamente Java ha sido un lenguaje poco conciso (la inclusión de var, y lambdas en las últimas versiones han ido mejorando esto): creación de getters y setters, definición de logs en cada clase, métodos toString y equals, llamadas a los métodos close/dispose, etc. Lombok es una librería capaz de enriquecer el código java y evitar tanto código denso y repetitivo. Una de las anotaciones mas útiles de Lombok es @Data que usado en nuestros beans nos evita tener que crear los getters, setters y métodos toString y hashCode.

Veamos un ejemplo de como crear una pequeña utilidad de refactorización que elimine todos los métodos de una clase y agregue la anotación @Data usando ANTLR. Para este ejemplo creamos un simple proyecto java, nos descargamos la librería de ANTLR y una de las gramáticas de java de ejemplo. Procesamos con ANTLR las gramáticas para generar los ficheros necesarios para interactuar con nuestro parseador:

$ cd src
$ ls
JavaLexer.g4
JavaParser.g4

$ java -jar ../antlr-4.7.1-complete.jar JavaLexer.g4

$ java -jar ../antlr-4.7.1-complete.jar JavaParser.g4

$ ls
JavaLexer.g4
JavaLexer.interp
JavaLexer.java
JavaLexer.tokens
JavaParser.g4
JavaParser.interp
JavaParser.java
JavaParser.tokens
JavaParserBaseListener.java
JavaParserListener.java

Una vez generados (y compilados) estos ficheros podríamos ver los tokens que son interpretados por el analizador o ver gráficamente el árbol sintáctico de algún fichero de entrada:

$ java -cp ../antlr-4.7.1-complete.jar:../bin org.antlr.v4.gui.TestRig \
        Java compilationUnit -tokens Persona.java

[@0,0:5='import',<'import'>,1:0]
[@1,6:6=' ',<WS>,channel=1,1:6]
[@2,7:10='java',<IDENTIFIER>,1:7]
[@3,11:11='.',<'.'>,1:11]
[@4,12:15='util',<IDENTIFIER>,1:12]
[@5,16:16='.',<'.'>,1:16]
[@6,17:20='Date',<IDENTIFIER>,1:17]
[@7,21:21=';',<';'>,1:21]
[@8,22:23='\n\n',<WS>,channel=1,1:22]
[@9,24:29='public',<'public'>,3:0]
...

Creando nuestras herramientas

Crearemos una clase listener capaz de recibir los eventos producidos por el parseador tanto a la hora de comenzar la ejecución de una regla como al terminar una regla. Utilizaremos un objeto de tipo TokenStreamRewriter que es el que nos permite realizar operaciones de inserción, modificación o borrado de tokens con los cambios que queremos en el fichero de salida.

public class LombokDataDomainRefactor extends JavaParserBaseListener {
    private TokenStreamRewriter rewriter;

    public LombokDataDomainRefactor(CommonTokenStream tokens) {
            this.rewriter = new TokenStreamRewriter(tokens);
    }

    public static void main(String[] args) throws IOException {

    }
}

En primer lugar crearemos un analizador léxico para nuestro fichero java de entrada, que puede ser cualquier clase Java Bean. Con este analizador léxico obtendremos un stream de tokens, los mismos que vimos con el ejemplo anterior al utilizar la utilidad TestRig.

Seguidamente crearemos un analizar sintáctico para este stream de tokens, y obtendremos el árbol sintáctico utilizando la regla principal de nuestra gramática, en este caso compilationUnit.

Por último recorreremos este árbol parseado usando nuestro listener, que recibirá los eventos sobre la entrada y salida de las distintas reglas de la gramática:

public static void main(String[] args) throws IOException {
    String unit = "src/Persona.java";

    JavaLexer lexer = new JavaLexer(CharStreams.fromFileName(unit));
    CommonTokenStream tokens = new CommonTokenStream(lexer);

    JavaParser parser = new JavaParser(tokens);
    ParseTree tree = parser.compilationUnit();

    ParseTreeWalker walker = new ParseTreeWalker();
    LombokDataDomainRefactor listener = new LombokDataDomainRefactor(tokens);
    walker.walk(listener, tree);

    String rewrite = listener.rewriter.getText();
    FileOutputStream fos = new FileOutputStream(unit);
    fos.write(rewrite.getBytes());
    fos.close();
}

Es el momento de realizar las operaciones. Cuando entremos en la regla de declaración de un método (methodDeclaration), utilizaremos nuestro reescritor de tokens, y eliminaremos todos los tokens que lo componen:

@Override
public void enterMethodDeclaration(JavaParser.MethodDeclarationContext ctx) {
    JavaParser.ClassBodyDeclarationContext parent = (JavaParser.ClassBodyDeclarationContext) ctx.parent.parent;
    rewriter.delete(parent.start, parent.stop);
}

Por último, agregamos la línea del import y la anotación @Data justo antes del comienzo de declaración de la clase (regla typeDeclaration)

@Override
public void enterCompilationUnit(JavaParser.CompilationUnitContext ctx) {
    JavaParser.TypeDeclarationContext typeDeclaration = ctx.typeDeclaration(0);
    rewriter.insertBefore(typeDeclaration.start, "import lombok.Data;\n\n@Data\n");
}

Conclusiones

ANTLR es una herramienta muy potente aunque de muy bajo nivel. Conocer este tipo de herramientas puede hacer que determinados problemas que parecen imposibles e inabarcables se conviertan en algo relativamente sencillo. Crear la gramática para el lenguage Natural requirió superar varias dificultades como la utilización de Island Grammars, Lexical Modes, keywords as identifiers o la inyección de tokens virtuales (END ALL).

Por último, otra de las opciones (aunque inacabadas) fue la posibilidad de utilizar Xtext. Xtext es un framework que nos permite desarrollar nuestro propios lenguajes de programación y DSL que funcionen bajo la JVM. Pero en lugar de limitarse a generar el parseador, es capaz de generar los plugins necesarios para los IDE Eclipse y IntelliJ. Usando Xtext seríamos capaz de crear nuestro propio editor inteligente con colores para la sintaxis, control de errores, navegación entre ficheros/métodos, auto completar, refactorizar, etc. además de que nuestro nuevo lenguaje podría convivir dentro de cualquier proyecto Java, tal y como ocurre con Groovy, Scala o Clojure. Desde luego una opción muy interesante para dotar de nueva vida a lenguajes y sistemas legacy con décadas a sus espaldas.

Marco de fotos interactivo con Raspberry Pi

Bruno Orcha García — Fri, 29 Dec 2017 00:00:00 +0000

La Raspberry Pi es la plataforma ideal para dar rienda suelta a nuestra imaginación y poder crear proyectos de todo tipo. Usarlo como centro de control para todo tipo de artilugios robóticos, usarlo como NAS o nube personal con Syncthing o ownCloud, compartir una impresora en red, crear un altavoz inalámbrico con Pi MusicBox, convertir cualquier televisor en un mini ordenador con rasbpian, usarlo como centro multimedia con Kodi, o permitirte jugar a juegos retro con RetroPie.

En mi caso por ahora se ha reducido al último caso, aprovechando un televisor que teníamos en el jardín y las Raspberry Pi como centro de juegos retro con RetroPie para las tardes de verano (Super Bomberman y Micro Machines 😍 ).

Aunque cuando celebrábamos algún cumpleaños, no sacábamos la Raspberry Pi para evitar vicios y destrozos con tanto niño suelto, por lo que dejábamos la tele siempre apagada. Pensando que uso le podríamos dar se nos ocurrió que podríamos mostrar una selección de fotos del cumpleañero.

Marco de fotos

Teniendo en cuenta que la Raspberry Pi ya estaba configurada con RetroPie, y que RetroPie utiliza framebuffer en lugar de X-Windows, busqué alguna utilidad sencilla que permitiera mostrar imágenes como un carrusel de fotos. Íbamos a convertir el televisor en un gran marco de fotos. El comando en cuestión es fbi “Linux framebuffer imageviewer”.

RetroPie usa la aplicación EmulationStation como interfaz gráfico para navegar por las distintas consolas y juegos. En una de los menús tenemos acceso a múltiples utilidades que nos permiten configurar distintos aspectos del sistemas. Todas estas opciones no son mas que scripts de configuración que existen en el directorio /home/pi/RetroPie/retropiemenu. Agregaremos en este menú una nueva opción para iniciar nuestro carrusel de fotos.

Crearemos un script con permisos de ejecución en este directorio con nuestro comando, por ejemplo:

#!/bin/bash

fbi -noverbose -blend 1000 -a -t 2 imagen1.jpg imagen2.jpg imagen3.jpg ...

El script anterior, mostrará de forma indefinida las imágenes indicadas, sin información adicional (-noverbose), con un fundido entre imágenes de 1 segundos de duración (-blend), autoajustando el tamaño de las imágenes (-a) y dejando 2 segundos entre cada imagen (-t).

gif animado seleccionando la opción

Compartir fotos

Tener un conjunto de fotos seleccionadas que se muestran está bien, pero más interesante es permitir a los invitados interactuar con lo que están viendo en la televisión y poder compartir con todos sus propias fotos, sobre todo las que puedes hacer en ese mismo momento durante la celebración!

Para ello crearemos una aplicación web en la propia Raspberry Pi, que mostrará a nuestros usuarios una simple página web que les permita subir una foto de sus móviles. Las fotos las iremos guardando en una carpeta dentro de las Raspberry Pi y con un script similar al anterior se irán mostrando en la pantalla. Por lo que nuestra solución constará de dos partes un script en bash que muestra las fotos y una aplicación web realizada en python en este caso (aprovechando que ya viene instalado).

Puesto que el comando fbi anterior necesita una lista fija de fotos, lo que haremos es crear un bucle y recalcular la lista de las últimas fotos e invocar al comando fbi con la opción -1 para que una vez mostrada las fotos termine su ejecución. Crearemos ademas una condición para permitirnos salir de este bucle que muestra fotos por si queremos volver al menú de retropie.

while [ ! -f $STOP_FILE ] ; do
    ls -1t images/* | head -n 25 > | sort -R > $IMAGE_LIST
    fbi -1 -noverbose -a -t 8 logo.png > /dev/null 2>&1
    fbi -1 -noverbose -blend 1000 -a -t 2 -u -l $IMAGE_LIST > /dev/null 2>&1
done

Lo primer que hacemos dentro del bucle es obtener las 25 fotos mas recientes y las ponemos en orden aleatorio (sort -R). Mostramos durante 8 segundos la imagen logo.png (que habremos preparado con información del evento, la url para subir fotos, etc.). Por último mostramos la lista de fotos.

Servidor web en python

Python ya incluye de serie un servidor web básico que podemos utilizar para compartir la carpeta actual en la dirección http://localhost:8080 con el comando:

python -m SimpleHTTPServer 8080

Para evitar hacer uso de librerías de terceros como Flask, Django o Pyramid, podemos simplemente extender la funcionalidad de este módulo para procesar la subida de los ficheros por el método POST.

class PhotoHandler(SimpleHTTPRequestHandler):
    def do_POST(self):
		    # Guardar la imagen subida por el usuario
		    ...
		    
httpd = SocketServer.TCPServer(("", 8080), PhotoHandler)
while True:
    httpd.handle_request()

Por último creamos una sencilla página web que será lo que verán nuestros invitados cuando quieran compartir una foto.

Publicarlo

A la hora de publicarlo o hacerlo accesible tenemos varias opciones según la disponibilidad de dominios y el nivel de privacidad que queramos.

Podemos obligar a nuestros invitados a que se conecten a la red wifi del lugar y utilizar la ip local para acceder, al estilo http://192.168.0.X:8080.
Si disponemos o registramos un dominio, podemos configurar la opción de iframe (o configurar un cname) y poner como destino la ip interna anterior. De esta manera, el acceso será mediante un dominio reconocible “cumple-de-pepito.es” pero sólo funcionará si estamos conectados a la red wifi del evento.
Podemos mapear un puerto del router para exponer el servicio a internet y configurar nuestro dominio a la ip pública del router.

Usar un servicio externo de imágenes

En casos de muchas peticiones, me ha ocurrido que las Raspberry Pi se ha reiniciado, probablemente debido a que el cargador utilizado no suministraba la suficiente potencia, mostrándose a veces el cuadrado multicolor en la esquina superior derecha. Además, si no queremos ofrecer ni obligar a los invitados que se conecten al wifi existe otra opción. Podemos utilizar un servicio de almacenamiento de imágenes externo como por ejemplo cloudinary.

Cambiaremos el servidor web anterior por un proceso en python que use la api de cloudinary para descargar las nuevas fotos subidas cada 10 segundos por ejemplo:

CLOUDINARY_API = 'https://ID:KEY@api.cloudinary.com/v1_1/gimco/resources/image?max_results=500&direction=asc&start_at=%s'
created_at = '2017-01-01'

while True:
    try:
        url = CLOUDINARY_API % created_at
        print str(datetime.now()), 'Buscando nuevos ficheros > ', created_at 
        response = urllib.urlopen(url)
        data = json.loads(response.read())
        for resource in data['resources']:
            image = 'images/' + resource['public_id'] + '.jpg'
            url = resource['url']
            created_at = resource['created_at']
            if not isfile(image):
                print 'Downlading ' + image
                urllib.urlretrieve(url, image)
    except: print 'Error!', sys.exc_info()
    print 'Fin de comprobacion, esperando 10 segundos'
    time.sleep(10)

Además, deberemos subir el contenido de la carpeta web con nuestra página html al espacio estático disponible con nuestro dominio para que sea accesible a los invitados. También deberemos cambiar la dirección a la que subir la imagen por la url del servicio de cloudinary:

@@ -12,13 +12,14 @@
         <p>Subiendo imagen ...</p>
         <img src="img/spinner.gif"/>
       </div>
-      <form id="image-form" ENCTYPE="multipart/form-data" method="post">
+      <form id="image-form" ENCTYPE="multipart/form-data" method="post" action="https://api.cloudinary.com/v1_1/gimco/image/upload">
         <p>Pulsa sobre el icono de abajo y selecciona una foto para subir.</p>
         <p> 😁 🎉 🎁 🎂 🍰 🎊 😛 </p>
         <p>¡En un minuto la podremos ver en la televisión!</p>
         <div class="image-upload">
           <label for="file"><img src="img/camara.png"/></label>
           <input id="file" name="file" type="file" accept="image/*" onchange="uploadImage()" />
+          <input type="hidden" name="upload_preset" value="brunito" />
         </div>
       </form>
     </div>

Podremos configurar ademas en cloudinary mas opciones a la hora de subir las imágenes (upload_preset), pudiendo redimensionar, rotar y convertir las imágenes a JPEG.

Puedes consultar los fuentes del proyecto en github.

Tuenti Challenge 7

Bruno Orcha García — Mon, 08 May 2017 00:00:00 +0000

Cuando queremos aprender un nuevo lenguaje o paradigma, sólo nos queda practicar para asimilarlo. Es por esto que me gusta realizar problemas y retos no sólo para perfeccionar mi dominio de Clojure, si no también para descubrir y aprender nuevos enfoques a la hora de afrontar los problemas.

La semana pasada terminó la séptima edición del Tuenti Challenge. Una colección de problemas de programación, análisis, optimización y hacking para los amantes de los retos. Podéis consultar los 15 problemas de los que constó esta edición en la página del concurso.

Aquí os dejo el análisis de los problemas y estrategia que implementé de los problemas que pude hacer y el código de las soluciones.

1. Pizza love
2. Bowling
3. Board games
4. Help Pythagoras Junior
5. Ghost in the HTTP
6. The Tower
7. Word Soup Challenge
8. Uni code to rule them all
9. The Supreme Scalextric Architect
10. Passwords
11. Colors
12. That’s a lot of moneyz
13. R’lyeh

1. Pizza love

Problema y Solución

El primer ejercicio suele ser sencillo, destinado principalmente a familiarizarse con el procedimiento de probar, enviar la fase de test y de submit, y tratar con los ejemplos difíciles que suelen desbordar los tipos de datos mas simples.

En este caso, nos dan una lista de número que representan el número de porciones que come cada persona. Sabiendo que las pizzas traen 8 porciones nuestro objetivo es averiguar cuantas pizzas necesitaremos comprar. Tan solo debemos sumar las porciones de todas las personas, dividir por 8 y redondear al siguiente entero Math.ceil.

(Math/ceil (/ slices 8))

2. Bowling

Problema y Solución

En esta ocasión tenemos que implementar el sistema de puntuación de los bolos. Las partidas constan de 10 rondas y en cada ronda tendremos que intentar tirar los 10 bolos y dos lanzamientos para conseguirlo. Si lo conseguimos a la primera habremos conseguido un “pleno” o “strike”. Si conseguimos tirar todos a la segunda será un “semipleno” o “spare”. Los puntos en cada ronda es igual al número de bolos tirados. Además si hicimos pleno o semipleno, sumaremos a la puntuación de ese ronda los bolos de las siguientes tiradas: los puntos de la siguiente tirada si hicimos semipleno y los puntos de las 2 siguientes tiradas si hicimos pleno.

Lo que tenemos es una secuencia con los bolos tirados y deberemos mostrar la puntuación obtenida en cada ronda. Hay que tener en cuenta que cada ronda puede constar de una tirada (si hacemos pleno) o de dos, por lo que deberemos ir llevando la cuenta para saber en que ronda nos encontramos. Además deberemos saber cuando se ha hecho pleno y semipleno para sumar puntos extras.

En el peor de los casos, si hacemos 3 plenos seguidos, estaríamos modificando el marcador de 3 rondas: la actual y las dos anteriores para contabilizar los puntos extras.

Podríamos ir leyendo tirada a tirada, y actualizando varios indicadores que nos digan si hicimos pleno o semipleno en las dos anteriores rondas. Pero ya que tenemos la secuencia completa de tiradas, es mas sencillo sumar directamente las tiradas futuras.

(defn bowling-score [rolls]
  (loop [[score & _ :as scores]   '(0)
         [r1 r2 r3 & _ :as rolls] rolls]
    (cond
      (= 11 (count scores)) (-> scores reverse next)
      (= 10 r1)             (recur (conj scores (+ score r1 r2 r3)) (next rolls))
      (= 10 (+ r1 r2))      (recur (conj scores (+ score r1 r2 r3)) (nnext rolls))
      :else                 (recur (conj scores (+ score r1 r2)) (nnext rolls)))))

3. Board games

Problema y Solución

Ahora nos metemos en el papel de un diseñador de juegos de mesa. Nuestro objetivo es decidir cuántas cartas de puntos y de que cuantías necesitamos, para que combinándolas podamos conseguir todos las posibles puntuaciones que se pudieran dar en el juego. Por ejemplo, si nos dicen que un determinado juego de mesa se puede conseguir hasta 20 puntos, deberemos poder combinar nuestras cartas de puntos para poder obtener los valores del 1 al 20.

A priori pareciera que tuviéramos que generar combinaciones de cartas, y probar distintas opciones hasta obtener el mínimo número de cartas necesaria. Este es un problema mucho mas sencillo de lo que aparenta la descripción. Como las cartas no se pueden repetir, vemos que para cada determinada cuantía de puntos habrá cartas que estarán y otras que no estarán. Después de algunas pruebas veremos que el sistema que estamos buscando no es mas que la representación binaria.

Así que el problema se reduce a contestar, cuantos bits se necesitan para representar cada determinado número, que no es mas que el redondeo hacia arriba del logaritmo en base dos del número máximo.

Para un juego donde máximo puedes obtener 22 puntos necesitaríamos: ⌈ log₂ 22 ⌉ = 5. Por lo que necesitaríamos 5 bits, o lo que es lo mismo, 5 cartas con las potencias de dos: 1 2 4 8 16. En Java tenemos el logaritmo neperiano y en base 10, pero aplicando propiedades podemos obtener el valor dividiendo por el logaritmo de la base que queremos, en nuestro caso:

(Math/ceil (/ (Math/log 22) (Math/log 2)))

Otra opción sin usar logaritmos es ir multiplicando por dos tantas repetidamente hasta que lleguemos o nos pasemos del número objetivo. El número de veces que hemos multiplicado por dos será el número de cartas que necesitemos.

4. Help Pythagoras Junior

Problema y Solución

Tenemos que ayudar al nieto de Pitágoras a buscar el triangulo con menor perímetros entre todos los triángulos que se puedan formar dada una lista de posibles lados. Los triángulos pueden ser de cualquier tipo (no tienen porqué ser triángulos rectángulos como en el teorema de su abuelo), por lo que para formar un triángulo, la suma de los dos lados mas pequeños debe ser mayor que el lado mas grande. Podríamos probar por fuerza bruta todas las posibles combinaciones de los tres lados, comprobar que formen un triángulo, calcular su perímetro y buscar el mínimo de todos estos valores.

Aunque hallaríamos la solución, el problema sería computacionalmente inviable ya que el número de operaciones crecería exponencialmente. Debemos optimizar el algoritmo para que se pueda resolver en un tiempo razonable. Lo primero que haremos es ordenar todos los lados de menor a mayor y comenzaremos a probar. El algoritmo consiste en tres bucles anidados que calculan las combinaciones.

En el momento que encontramos un triángulo (a, b, c) sabemos que este triángulo será el menor de todos los posibles que tengan los lados a y b, ya que el resto de los lados serán mayor que nuestro c_min. Esta es una de las podas u optimizaciones que realizaremos.

a + b + c  = x
a + b + c' = x'

si c' > c  =>  x' > x

Junto con el valor del perímetro mínimo deberemos guardar también el valor de c_min. En el momento que b sobrepase al c_min del triangulo mínimo, todos los perímetros también serán mayores, por lo que debemos probar con el siguiente a.

a  + b  + c  = x
a' + b' + c' = x'

a' > a, b' > c   =>  x' > x

5. Ghost in the HTTP

Problema y Solución

Esta es una prueba de investigación. Sólo se nos presenta un enlace que al cargarlo, nos muestra un una página html simple con un mensaje y un nuevo enlace:

<a href="/ghost">Just a whisper. I hear it in my ghost...</a>

También podemos ver que que en el favicon aparece la palabra PUSH que será una pista para resolverlo. Si accedemos al enlace lo único que obtenemos es el texto:

iVBORw0KGgoAA

Que parece corresponder con datos con codificación base64. Si decodificamos estos datos vemos que parece la cabecera de una imagen PNG, pero el fichero es demasiado pequeño y no está completo.

echo "iVBORw0KGgoAA" | base64 -d | xxd
base64: invalid input
00000000: 8950 4e47 0d0a 1a0a 00                   .PNG.....

Usando como pista el nombre del problema, echaremos un vistazo a las cabeceras HTTP de la petición:

$ curl -v -k https://52.49.91.111:8443/ghost 
> GET /ghost HTTP/1.1
> Host: 52.49.91.111:8443
> User-Agent: curl/7.52.1
> Accept: */*
> 
< HTTP/2 200 
< accept-ranges: bytes
< content-type: text/plain; charset=utf-8
< last-modified: Mon, 24 Apr 2017 11:13:13 GMT
< content-length: 3445
< date: Fri, 05 May 2017 06:35:35 GMT
< 
curl: (18) transfer closed with 3432 bytes remaining to read
iVBORw0KGgoAA

Aquí podemos ver por un lado, como el comando curl nos informa de que se ha cerrado la conexión. Vemos que la cabecera Content-Length nos informa que el recurso ocupa 3445 bytes pero el servidor sólo nos ha enviado 13 bytes. Revisando las cabeceras vemos que el servidor acepta rangos Accept-Ranges: bytes. Si probamos a curl a pedir un rango:

$ curl -v -k https://52.49.91.111:8443/ghost -r 13-
AANSUhEUgAAAN

Nos devuelve los siguientes 13 bytes del fichero!. Así que lo que tenemos que hacer es seguir haciendo peticiones en bloques de 13 bytes hasta obtener el fichero competo:

for r in $(seq 0 13 3445); do \
  curl -v -k https://52.49.91.111:8443/ghost -r 13- >> ghost.b64 \
done

Una vez descargado y decodificado con base64 vemos que se trata de una imagen con el número 4017-8120 que parece ser un rango … Si probamos a pedir este rango concreto al servidor obtenemos la siguiente respuesta:

$ curl -v -k https://52.49.91.111:8443/ghost -r 4017-8120
> GET /ghost HTTP/1.1
> Host: 52.49.91.111:8443
> Range: bytes=4017-8120
> User-Agent: curl/7.52.1
> Accept: */*
> 
< HTTP/2 200 
< content-type: text/plain; charset=utf-8
< content-length: 48
< date: Fri, 05 May 2017 06:45:12 GMT
< 
You found me. Pushing my token, did you get it?

Otra vez referencia a la palabra “push”. Podemos percatarnos que el servidor nos informa que soporta HTTP/2. Una de las nuevas funcionalidades de HTTP/2 es Server Push, que es la posibilidad de que el servidor envíe recursos antes que el cliente los solicite. Esto se hace para acelerar la carga de páginas, ya que con una única petición a un html, el servidor podría devolvernos el html solicitado junto las imágenes y el css que probablemente se vayan a pedir posteriormente.

El comando curl no soporta push, así que probamos con otro cliente que soporte HTTP/2 Server Push, y esta vez si vemos que el servidor nos había enviado (por push) la clave que estábamos buscando:

$ nghttp https://52.49.91.111:8443/ghost -H "Range: bytes=4017-8120"
YourEffortToRemainWhatYouAreIsWhatLimitsYou
You found me. Pushing my token, did you get it?

6. The Tower

Problema y Solución

Este problema parece estar inspirado la serie Tower of God. Nuestro objetivo es subir a lo alto de una torre de N plantas. Si estamos en la planta x, subir la escalera a la siguiente planta nos llevará x años. Bajar a la planta anterior no tiene coste. También nos informan de una serie de atajos entre plantas (que pueden subir o bajar). Nos piden averiguar el mínimo número de años que tardaríamos en llegar a lo alto de la torre.

Rápidamente se intuye que es un problema de grafos, donde cada planta puede ser un nodo, y los atajos y escaleras serán las aristas que tendrán distintos pesos en años. Así pues, tan solo deberemos aplicar el algoritmo de Dijkstra que nos averigüe el camino mas corto. Pero como siempre no suele ser tan sencillo. Generar un nodo por cada planta puede servir para los ejemplos simples, pero cuando nos encontramos con torres que tienen 10000 plantas, los tiempos se disparan.

Si analizamos el problema vemos que podemos simplificar el grafo. Un grafo con 100 nodos que se corresponda al camino de la planta 1 a la planta 100, sería equivalente a un grafo con 2 nodos, cuya arista cueste lo mismo que el sumatorio de todas las anteriores.

Por lo para la solución final formaremos un grafo que estará formado únicamente por los nodos que pertenezcan a atajos (además de la primera y última planta). A estos nodos agregamos las arista que corresponden a los atajos. Las aristas de coste cero cuando vamos hacia atrás, y calculamos las aristas que corresponderían al camino normal de subir las escaleras.

7. Word Soup Challenge

Problema y Solución

Si accedemos al enlace nos aparece el juego de sopa de letras. En este nivel tenemos 5 minutos para resolverlo. Si lo hacemos manualmente se nos mostrará el siguiente nivel que es una monstruosidad que ha de resolverse en 20 segundos.

Existen solucionadores de sopa de letras en javascript, por lo que parece que es tan simple como simular los clicks del ratón y listo. Pero como siempre, resulta que no es tan sencillo. Si vemos el código fuente vemos que el código JavaScript se carga dinámicamente a través de una conexión websocket. Además, los distintos intentos de hacer click desde javascript son infructuosos.

Usando las developer tools de chrome podemos poner un breakpoint global sobre los eventos de ratón. Al hacer click sobre una letra, podremos ver el código javascript que se ejecuta. Ahí podemos ver que se sobre escribe la variable $ y que se comprueba que el evento del ratón tenga activada la opción isTrusted que indica que es un evento de ratón real, motivo por el cual no podemos simularla con javascript.

Después de analizar un poco el código vemos que podemos comunicarnos directamente con el websocket utilizando estas dos funciones:

m = t => {
    let n, e, o, s = 0;
    const c = t + "-saltbae";
    if (!c.length) return s;
    for (n = 0, o = c.length; n < o; n++) e = c.charCodeAt(n), s = (s << 5) - s + e, s |= 0;
    return Math.abs(s)
}

mark = (f, t) =>  {
    e = `${f}-${t}`;
    w.send(btoa(`${e}-${m(e)}`))
}

Por lo que sólo nos queda cargar jQuery, Wordfind, buscar la lista de palabras, el array bidimensional con las letras y solucionarlo:

solve = function () {
    var words = jQuery("div[id^=word-]").toArray().map(function(e){ return e.innerText})

    var board = jQuery("tr").toArray().map(e => jQuery("td", e).toArray().map(e => e.innerText))

    wordfind.solve(board, words).found.forEach(mark)
}

8. Uni code to rule them all

Problema y Solución

Aquí ponen a prueba nuestra conocimiento sobre Unicode. El problema es tan sencillo como detectar en qué filas aparece un número, ignorando posibles espacios en blanco delante y detrás de este. Una vez detectado el número hay que mostrarlo en hexadecimal.

Puede que los ejemplos parezcan confusos al principio, hasta que caemos en la cuenta que los dígitos se pueden representar de distinta forma en otros idiomas!. Por ejemplo, esto es un teclado árabe donde se puede apreciar los grafos correspondientes a las letras y números occidentales:

Ya en el propio enunciado te indican que los números pueden estar representados en distintos idiomas. Unicode también agrupa los símbolos por categorias, concretamente tenemos que ver las dos que ya nos dicen en el enunciado, la Nd y la Zs.

Afortunadamente Java tiene soporte para Unicode, y lo que es aún mejor, las propias expresiones regulares soportan categorías de Unicode. Así que una expresión regular típica que busca dígitos ignorando los espacios que sería:

\s*\d+\s*

extendiendo esta expresión regular a las categorías Unicode sería:

\p{Zs}*\p{Nd}+\p{Zs}*

Tan solo debemos leer el fichero adecuadamente. Analizando los ficheros de prueba averiguamos que están en UTF-16 Little-endian, y que al principio del fichero tenemos dos bytes que forman el BOM (Byte Order Mark), bytes que nos informan que codificación se está utilizando. Como nosotros ya estamos forzando a que sea UTF-16LE podemos ignorar estos bytes.

Por último y como viene siendo habitual, hay que utilizar BigInteger para poder tratar con los números gigantes que vienen en las pruebas, además de que esta clase soporta la conversión de cadena Unicode a número, y la transformación de número a hexadecimal.

9. The Supreme Scalextric Architect

Problema y Solución

Este ha sido uno de mis favoritos. Dado un conjunto de piezas (secciones simples, dobles y curvas), nuestra misión es averiguar las piezas necesarias para construir el circuito mas grande posible. A priori el problema parece muy complejo ya que el número de combinaciones posibles parece bastante grande.

Pero pensamos en primer lugar en el circuito cerrado mas pequeño posible, nos daremos cuenta que es el compuesto por 4 curvas formando un círculo. De esto sabemos que si en el conjunto de piezas, no hay al menos 4 curvas, es imposible hacer un circuito cerrado.

Una vez tenemos el circuito mas pequeño podemos pensar en como agrandarlo. Vemos claramente que no se pueden agregar piezas individuales, si no que cada operaciones de crecimiento del circuito consiste en agregar un conjunto de piezas.

Por ejemplo, una transformación sería agregar dos piezas simples. Nos da igual si hacemos crecer el circuito a lo alto o a lo largo, porque al fin y al cabo estamos hablando del mismo circuito. Intentar agregar 10 piezas simples, sería como aplicar 5 veces esta transformación simple.

Si representamos cada operaciones como un vector de tres valores [S C D], con el número de piezas simples (S), curvas (C) y dobles (D), la transformación anterior se puede representar como [2 0 0]. Si analizamos las posibles mínimas transformaciones que podemos hacer nos encontraremos con las siguientes 12 transformaciones:

Cualquier otro circuito o transformación estaría compuesto por varias de estas 12 transformaciones mínimas. Ahora el espacio de búsqueda se reduce en gran medida y podemos abarcarla en tiempo. Empezaríamos con un vector que se corresponde con el número total de piezas disponibles, y comenzaríamos a aplicar transformaciones básicas que consistiría en restar el vector correspondiente. Además, dado un conjunto de piezas muy grande, podríamos simplificarlo eliminando de forma repetitiva un conjunto fijo de transformaciones como [8 8 8] por ejemplo.

10. Passwords

Problema y Solución

Hemos borrado la base de datos de contraseñas de los usuarios y debemos intentar restaurar los contraseñas de todos ellos. Afortunadamente las contraseñas son autogeneradas por un algoritmo que cambia cada día y tenemos el log de cuando cada usuario regeneró la contraseña. Como disponemos del repositorio git con el código del algoritmo, sólo tenemos que saber la fecha, buscar la versión del algoritmo y ejecutarlo. Para buscar la versión del código podemos utilizar el siguiente comando:

git rev-list -n 1 --before="FECHA"  --all

Que quiere decir, busca la primera revisión (-n 1) anterior a la fecha dada, en todas las ramas (--all). Una vez tengamos el hash de la revisión solo debemos hacer checkout. Por ejemplo, veamos el tercer ejemplo:

xoajoj 2
2013-05-19 1
2016-08-20 1

Esto quiere decir que el usuario ‘xoajoj’ regeneró la contraseña en dos días distintos. Y en cada uno de estos día sólo se regeneró una sola vez. Para restaurar la contraseña haríamos lo siguiente:

$ git checkout $(git rev-list -n 1 --before="2013-05-19 23:59:59" --all)
Previous HEAD position was c4f77fc... Updating script
HEAD is now at 6ffca36... Updating script

$ ./script.php xoajoj
$t0\&wArw^ 08f654824c4c1144fc0fad332112d619

$ git checkout (git rev-list -n 1 --before="2016-08-20 23:59:59" --all)
Previous HEAD position was 6ffca36... Updating script
HEAD is now at c4f77fc... Updating script

$ ./script.php xoajoj 08f654824c4c1144fc0fad332112d619
WSUmXS~*oR 60c9c0f66b325c193d293ced8c85cf71

Con un poco de scripting podemos automatizar este proceso, pero pronto nos daremos cuenta de uno de los problemas. Y es que git rev-list realiza una búsqueda de los commits que están conectados por así decirlo. De modo que los commits que fueron eliminados o abandonados no aparecen. Pero a menos que hagamos un git prune, esos commits siguen estando en la base de datos, aunque no seamos capaces de llegar a ellos.

Después de varias pruebas, para solventar esto, me decidí a listar todos los objetos dentro de la base de datos .git/object. Para cada uno de ellos comprueba con git cat-file -t si son de tipo commit, y si lo son extraigo la fecha y el algoritmo con git show:

find .git/objects/ \
		| egrep '[0-9a-f]{38}' \
		| perl -pe 's:^.*([0-9a-f][0-9a-f])/([0-9a-f]{38}):\1\2:' \
		| \
while read hash ; do
	if [ "$(git cat-file -t $hash)" == "commit" ]; then
		DATE=$(git show -s --format=%ci $hash)
		DATE=${DATE:0:10}

		echo $DATE
		git show $hash:script.php > $SCRIPTDIR/$DATE.php
	fi
done

Al final de esto tendremos un directorio con todos los script con su correspondiente fecha listo para usarse. Pero como siempre nos encontraremos con otro problema, y es que la ejecución es muy lenta. Analizando el algoritmo de los script php vemos que hay un bucle con 10 millones de iteraciones que es el responsable de la lentitud:

$counter = $secret3;

for ($i=0; $i < 10000000; $i++) {
  # This loop makes the passwords hard to reverse
  $counter = ($counter * $secret1) % $secret2;
}

Vemos que el valor de $counter en cada iteración se vuelve a multiplicar por $secret1 y se calcula el módulo una y otra vez. Es un caso de exponenciación modular muy utilizada en criptografía, y de la cual existe un cálculo rápido implementada en la mayoría de los lenguajes. Así que el bucle con 10 millones de iteraciones se puede sustituir por la siguiente veloz sentencia:

$counter = ($secret3 * bcpowmod($secret1, 10000000, $secret2)) % $secret2

Esto mejora de forma considerable los tiempos de cálculo pero existen ejemplos que tardan mas. Por lo que la última opción es extraer los valores $secret1 y $secret2 que es lo que cambia cada día y re-implementar el algoritmo en otro lenguaje para obtener un mejor rendimiento y así evitar tantas llamadas a lenguajes interpretados, ademas de poder precalcular algunas operaciones.

11. Colors

Problema y Solución

De nuevo un problema de grafos. Debemos calcular el tiempo mínimo para llegar a cada una de las distintas galaxias que están conectadas por agujeros de gusano, que sólo podremos utilizar si poseemos la energía de color adecuada.

Inicialmente parecía claro tener que aplicar Bellman–Ford para obtener todos los caminos mínimos, pero en este problema las aristas pueden estar activas o no en función de nuestro estado, e incluso existir bucles (como ir y volver a otra galaxia para conseguir energía de otro color para poder usar un tipo de agujero de gusano).

Así que opté por implementar el algoritmo de búsqueda manualmente, aunque no es la solución válida ya que el tiempo crece exponencialmente. Del enunciado se intuye que nuestro estado y cada galaxia se podría representar como un número binario, donde cada bit indica la existencia o no de la energía de un color, y las aristas como máscaras binarias para saber si la cumplimos o no. Aunque en mi caso no exploré esta opción y decidí saltar el ejercicio por que el tiempo se terminaba.

12. That’s a lot of moneyz

Problema y Solución

Este ha sido mi otro problema favorito del concurso de este año. Tenemos que ayudar a nuestro amigo a contar monedas. Para ello, al conectarnos a la dirección y el puerto indicados, se nos envían una serie de imágenes JPEG de las monedas que tenemos contar (siempre imágenes distintas). Si nos conectamos con telnet o netcat veríamos esto:

Si procesamos los datos adecuadamente veríamos imágenes como esta:

Las imágenes vienen dañadas, con algunas secciones verticales invertidas, pero son fácilmente corregibles ya que cada dos columnas de 40 pixeles se invierte la imagen. Inicialmente intenté resolverlo analizando el histograma de las imágenes, para intentar averiguar las monedas contando la cantidad de determinados colores que existen, pero al ser JPEG existía mucho ruido y zonas difuminadas.

Así que toca echar mano de procesamiento de imágenes, cosa que siempre me había llamado la atención pero que nunca había trasteado. Para solucionarlo utilicé el que parece la librería mas popular: OpenCV y su binding para Java.

Una vez restaurada la imagen, el primer paso sería detectar los distintos círculos que existen en la imagen que corresponderían con las monedas aplicando CHT (Circle_Hough_Transform). Aplicado sobre la imagen, obtenemos una lista de puntos que se corresponden con los centros de las circunferencias detectadas junto con sus radios.

Como cada moneda tiene un tamaño distinto, quizás podríamos saber de qué moneda se trata sabiendo el radio mas próximo. Desgraciadamente las detecciones no tienen tal nivel de exactitud, y a veces detecta círculos mas pequeños o ligeramente desplazados debido a la calidad de las imágenes.

Después de distintos intentos, opté por utilizar el algoritmo Template Matching, que permite buscar zonas de imágenes similares. Así que puesto que detectaba correctamente los centros de las monedas, lo que hice fue extraer una región cuadrada de cada uno de los centros detectados. Por otro lado, generé pequeños cuadrados de los centros de cada una de las monedas posibles que los usuarios como los patrones a buscar:

Por último, para cada sección cuadrada realicé una búsqueda de los patrones de las monedas para ver si se encontraba y por tanto saber de qué moneda se trataban.

Desgraciadamente para mi lo resolví minutos después de que se cerrara el tiempo límite y no pude entregar la solución. Para que os hagáis una idea de cómo les gusta a los de Tuenti complicar las pruebas, esta era una de las últimas imágenes que teníamos que resolver:

13. R’lyeh

Problema y Solución

Después de una intrigante introducción basada en Lovecraft, se nos insta a averiguar la relación entre los números esculpidos y escritos sobre una estatua. Tenemos la función que dado un número esculpido, nos devuelve el número escrito correspondiente. Pero se nos pide justo lo contrario, dado un conjunto de número escritos, averiguar el esculpido correspondiente. El problema es tan sencillo como implementar la función inversa a la que no dan. Sencillo si no fuera por el aspecto de esta función:

int64_t carvedToWritten(int64_t n)
{
    int64_t r = 0;
    for (int64_t i = 0; i < 64; ++i)
    {
        int64_t a = 0;
        for (int64_t j = n; j >= 0; --j)
        {
            int64_t b = 0;
            for (int64_t k = 0; k <= i; ++k)
            {
                int64_t c = a ^ ((i & (n ^ j) & 1) << k);
                a ^= (j & (1LL << k)) ^ b;
                b = (((c & j) | ((c ^ j) & b)) & (1LL << k)) << 1;
            }
        }
        r |= (a & (1LL << i));
    }
    return r;
}

Misión imposible intentar entender que hace. Si usamos esta función para generar 1000 pares de números (carved - written) y los ordenamos por written tampoco apreciamos relación alguna:

written | carved                           written | carved
--------+-------                           --------+-------
|      1                                24 |    143
|      4                                25 |     17
|      8                                30 |     19
|      9                                32 |     64
|      3                                33 |     66
|      5                                34 |    587
|     16                                37 |     73
|     18                                64 |    128
|    572                                65 |    129
|     32                                66 |     11
|     33                                67 |     14
|     36                                70 |     12
|      7                                71 |     38
|     10                                72 |    144
|      6                                75 |    573
...           

Si nos fijamos bien en la función, vemos que hay un bucle exterior que itera 64 veces y realiza la operación r |= (a & (1LL << i)). Que es lo mismo que establecer los bits del 0 al 64 del resultado final. Si agregamos un printf en este punto para ver los valores que va tomando la variable a en cada iteración observamos lo siguiente:

Ahora si que vemos un patrón que se repite constamente. Para los bits impares se toma el valor (n + 1) / 2, y para los pares n * (n + 1) / 2. Así que podemos simplificar la función original, que además mejorará el rendimiento:

int64_t carvedToWrittenFast(int64_t n)
{
    int64_t r = 0;
    for (int64_t i = 0; i < 64; ++i)
    {
        int64_t a = 0;

        if (i % 2 == 0) {
            a = n * (n + 1) / 2;
        } else {
            a = (n + 1) / 2;
        }

        r |= (a & (1LL << i));
    }
    return r;
}

Una vez comprobamos que esta nueva función es equivalente a la primera, podemos analizar su funcionamiento. Podemos obtener los bits impares de n directamente del valor de r, realizando la operación inversa a (n + 1) / 2:

Como sabemos que el número objetivo es de 32 bits, y gracias a la operación anterior conocemos ya 16 bits del valor final, la opción mas sencilla es calcular por fuerza bruta los otros 16 bits restantes, lo que nos llevará a probar 65536 valores en el peor de los casos:

uint32_t writtenToCarved(int64_t r) {
    
    uint32_t m = (r & 0xAAAAAAAA) << 1;
    for (int i = 0; i < 0xFFFF; i++) {
        uint32_t n = m;
        for (int k = 0; k < 16; k++) {
            n |= (i & (1 << k)) << (k + 1);
        }
        if (carvedToWrittenFast(n - 1) == r) {
            return n - 1;
        } else if (carvedToWrittenFast(n) == r) {
            return n;
        }
    }
    return 0;
}

Me quedan por solucionar dos problemas: Blackjack y Intervals, que en otro momento intentaré solucionar y actualizaré esta entrada con su correspondiente análisis.

Mainframes

Bruno Orcha García — Wed, 22 Feb 2017 00:00:00 +0000

Últimamente he tenido la oportunidad de conocer una parte de la historia de la informática que para mi era totalmente desconocida. Me estoy refiriendo al mundo de los mainframes. Estos sistemas han sido el orgullo de los centros de datos de empresas y universidades. Son ordenadores caros (muy caros), potentes y del tamaño de frigoríficos americanos. Aunque hoy en día IBM sigue comercializando estos sistemas, la fuerte competencia de las soluciones de virtualización y la popularidad de los proveedores en la nube, no los hace tan imprescindibles como antaño.

No cabe duda de que han sido las plataformas donde se han implementado los grandes sistemas de información de los 80 y los 90, y aunque parezca sorprendente, muchos de ellos siguen dando servicio varias décadas después. Hoy en días estos sistemas siguen en la sombra, dando soporte y gestionando el negocio clave de multitud de sistemas. De hecho, según cita una de las principales empresas software de Europa:

COBOL is still a world-player in IT. In fact, 75 percent of the world’s business transactions are processed by COBOL.

Podemos identificarlos con sus pantallas negras tan características (emuladores de terminal). Yo al menos los he podido identificar en sitios tan diversos como en los sistemas de gestión de garantía de Thermomix, en El Corte Inglés, Hospitales, Supermercados, Aerolíneas. El negocio de IBM con estos sistemas es increíble. Desorbitados costes de licencias, licencias que hay que pagar anualmente por “ejecución de software”. Es decir, por el mero hecho de arrancar el sistema.

Son los conocidos backoffice, o sistemas legacy. Sistemas que llevan funcionando 20 años, desarrollados en los 80’s y 90’s y que por una u otra razón no han podido ser actualizados o migrados a nuevas tecnologías o nuevas plataformas. Sistemas con millones y millones de líneas de código, que actualmente están funcionando, sin fallos. Y todos hemos aprendido la regla de oro: “Si funciona no lo toques”. No es casualidad que el libro más mencionado en Stack Overflow sea precisamente “Working Effectively with Legacy Code”.

Acceso al sistema

Para conectarnos al mainframe se utiliza un emulador de terminal 3270, que sería el equivalente a un telnet o ssh, aunque la interacción parece mas rica, ya que el cliente gestiona conceptos como campos de entrada, campos de solo lectura y posición del cursor. En Windows se suele utilizar los programas propietarios Entire Connection o TN3270Plus, y afortunadamente existe el proyecto x3270 que implementa distintos clientes para todas las plataformas incluida Linux.

Junto con los clientes gráficos y de consola se incluye el cliente s3270 que nos permite interactuar con el mainframe en forma de scripts. Podemos utilizar este cliente para automatizar ciertas acciones (al estilo de macros) o para hacer lo que podríamos llamar Terminal scraping, para extraer información de forma sencilla obteniendo el texto en pantalla.

Sistema operativos

Algunos de estos antiguos mainframes ejecutan sistemas operativos “extraños” a los ojos de los que estamos acostumbrado a los sistemas basados en UNIX. Recordemos que estos sistemas ya existían varias décadas antes de la popularización de Linux (Linus Torvals presentó Linux 1.0 en 1992). Uno de estos sistemas operativos con los que me he encontrado es VSE/ESA.

Como ejemplo de lo “diferente” que pueden llegar a ser estos sistemas operativos veamos por ejemplo JCL (Job Control Language). Esto es el lenguaje que se utiliza para interactuar con el sistema operativo. Vendría a ser el equivalente a un shell script con bash o un .bat en windows. Lo que en el mundo linux sería copiar un fichero:

cp oldFile newFile

… en el mundo mainframe con JCL equivaldría a:

//IS198CPY JOB (IS198T30500),'COPY JOB',CLASS=L,MSGCLASS=X
//COPY01   EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1   DD DSN=OLDFILE,DISP=SHR
//SYSUT2   DD DSN=NEWFILE,
//            DISP=(NEW,CATLG,DELETE),
//            SPACE=(CYL,(40,5),RLSE),
//            DCB=(LRECL=115,BLKSIZE=1150)
//SYSIN    DD DUMMY

Podemos hacernos una idea del aspecto que tendría un JCL que obtenga un fichero por FTP, ejecute un programa que procese los datos, genere nuevos ficheros, los transfiera por FTP a otra máquina, y envíe correos electrónicos … Para los mas curiosos todavía se pueden encontrar tutoriales de JCL.

Desarrollo de aplicaciones

Estos mainframes eran las plataformas de desarrollo de aplicaciones empresariales de su época, y como tales proporcionaban a los programadores el entorno de programación, compilación, procesamiento y acceso a bases de datos necesarios. No existía el concepto de desarrollo en local y despliegue, si no que los desarrolladores se conectaban mediante el emulador de terminal al mainframe para programar. El entorno de desarrollo era por lo tanto basado en consola (quienes hayan conocido TurboPascal o TurboC se podrán hacer una idea). Un ejemplo de este interfaz:

Los lenguajes mas habituales eran C, COBOL y NATURAL. Yo en concreto me he encontrado con algunas aplicaciones desarrolladas en el lenguaje de programación NATURAL y la base de datos ADABAS, ambos creados por la empresa Software AG.

Natural: Cobol’s ugly, brain-damaged, BABBLING IN ALL-CAPS — but regrettably still healthy and strong — cousin.

NATURAL es un lenguaje de programación de los considerados de 4ª generación (como Clipper), que vendrían a ser lenguajes de alto nivel y de propósito específico. En estos lenguajes el acceso y manipulación de las base de datos y la interacción con interfaces de usuario e informes forman parte del propio lenguaje, al contrario que con los lenguajes de propósito general los cuáles necesitarían de distintas librerías adicionales para implementar estas características. Esto hace que la creación de pantallas, validaciones de datos, generación de listados e informes sea rápida y sencilla.

DEFINE DATA
LOCAL USING LUSUARIO
LOCAL
  1 #APELLIDO (A20)
END-DEFINE
INPUT #APELLIDO
FIND LUSUARIO WITH APELLIDO = #APELLIDO
  DISPLAY NIF NOMBRE APELLIDO1
END-FIND
END

Como curiosidad decir que la base de datos ADABAS es NoSQL … en el sentido de que no se utiliza SQL para consultarla. En su lugar hay que construir programas NATURAL para obtener la información que queramos. Soporta búsquedas “fonéticas” (à la Oracle Text/Lucene), grupos periódicos y campos multivaluados, similares a las estructuras jerárquicas y arrays que se utilizan con JSON y MongoDB, claro que todo esto en los años 80 😆.

Clojure shebang

Bruno Orcha García — Thu, 17 Nov 2016 00:00:00 +0000

Uno de las grandes ventajas de los lenguajes de scripting como bash, python, perl, awk, ruby, php, nodejs, etc, es poder editarlos fácilmente desde consola, sin necesidad de tener que recompilar los fuentes para obtener un binario ejecutable. Esto hace que estos lenguajes sean muy populares para labores de mantenimientos y automatización, o crear pequeñas utilidades.

Los sistemas *nix implementan un mecanismo denominado shebang mediante el cual podemos informar al sistema operativo que intérprete se debe utilizar para ejecutar un determinado fichero. Tan solo debemos escribir al principio del fichero los símbolos #! seguido de la ruta del programa que interpretará el fichero. Probablemente te sonará si has creado alguna vez ficheros de script de bash y has tenido que comenzar el fichero con #!/bin/bash.

Así pues, si creamos un fichero con código Python llamado hola-mundo.py con el siguiente contenido:

print "hello world"

le damos permiso de ejecución e intentamos ejecutarlos obtendremos el siguiente error:

$ chmod +x hello-world.py
$ ./hello-world.py
Failed to execute process './hello-world.py'. Reason:
exec: Exec format error
The file './hello-world.py' is marked as an executable but could not be run by the operating system.

Nuestro sistema operativo no sabe como ejecutar el programa aunque le hayamos puesto la extension .py. En estos casos tendremos que utilizar la expresión shebang para indicar cómo ejecutar el fichero. Sólo debemos agregar en la primera línea los caracteres #! seguido del intérprete:

#!/usr/bin/python

print "hello world"

De este modo el sistema operativo ya sabe cómo ejecutar el fichero. De hecho, ejecutar ./hello-world.py es exactamente lo mismo que ejecutar /usr/bin/python hello-world.py.

Es posible que los distintos intérpretes de comandos pueden estar instalados en distintas rutas según el sistema operativo. Para evitar introducir la ruta absoluta del intérprete se suele utilizar el comando /usr/bin/env que inicializa las variables de entorno del usuario y podemos indicar solamente el nombre del intérprete:

#!/usr/bin/env python

print "hello world"

Clojure

Todos los lenguajes de scripting instalan un binario que es el propio intérprete, lo que nos permite crear los ficheros con la correspondiente línea shebang. En el caso de Clojure no es así. Al contrario que con otros lenguajes, no disponemos de un instalador “oficial” con el que se instale un comando “clojure”. Lo mas parecido a este instalador oficial son las herramientas que gestionan la compilación de proyectos clojure como son lein o boot, siendo el primero el estándar de facto.

Estas herramientas son las equivalentes a maven o ant en el mundo Java, y como ellas, también disponen de su correspondiente fichero de definición (pom.xml / build.xml) y de su estructura de proyecto por defecto. De hecho, si instalamos lein (tan solo debemos descargar el script de lein y ubicarlo en un directorio dentro del PATH) y creamos un proyecto básico obtenemos lo siguiente:

$ lein new app hello-world
Generating a project called hello-world based on the 'app' template.
$ find hello-world
hello-world
hello-world/.gitignore
hello-world/.hgignore
hello-world/CHANGELOG.md
hello-world/doc
hello-world/doc/intro.md
hello-world/LICENSE
hello-world/project.clj
hello-world/README.md
hello-world/resources
hello-world/src
hello-world/src/hello_world
hello-world/src/hello_world/core.clj
hello-world/test
hello-world/test/hello_world
hello-world/test/hello_world/core_test.clj

Si entramos en el directorio hello-world podremos ejecutar el proyecto clojure usando lein run pero que crear esta estructura de directorios y todos estos ficheros para ejecutar pequeños programa clojure que sólo consisten en un único fichero no es demasiado cómodo.

Creando el comando clj

Como solución podemos crear un fichero que desempeñe la labor de intérprete. Para ello creamos un fichero de nombre clj y lo agregamos a algún directorio del PATH. El fichero contendrá el siguiente código:

#!/bin/sh

CLJ_JAR=$(ls -t ~/.lein/self-installs | head -1)

exec java -Xmx1g -server -cp $CLJ_JAR clojure.main $@

Básicamente lo que hacemos es buscar la versión mas actual de lein que contiene las librerías de clojure e iniciar una máquina virtual de Java pasando todos los parámetro recibidos. Si no tenemos lein podemos especificar en la variable CLJ_JAR la ruta al fichero clojure-1.X.jar que queramos usar. Después de crear este fichero podremos crear scripts con clojure que sean ejecutable utilizando el siguiente shebang:

#!/usr/bin/env clj

(println "hola mundo")

Importando dependencias

El sistema anterior tiene un inconveniente: no podemos usar librerías adicionales en nuestro fichero de clojure. Para solucionarlo podemos utilizar un plugin lein-exec. Para ello debemos agregar el plugin a nuestro fichero profiles.clj:

; Agregar el plugin de lein-exe en ~/.lein/profiles.clj:

{:user {:plugins [[lein-exec "0.3.5"] }}

Y agregar el fichero lein-exec a nuestro path. A partir de entonces, en los script que usemos con el shebang lein-exec tendremos una instancia de clojure con el plugin cargado con el que podremos indicar que librerías adicionales necesita el fichero para funcionar. Por ejemplo:

#!/usr/bin/env lein-exec

(use '[leiningen.exec :only (deps)])
(deps '[[org.clojure/data.codec "0.1.0"]])

(require '[clojure.data.codec.base64 :as b64])

(-> "SGVsbG8gd29ybGQh"
    .getBytes
    b64/decode
    String.
    println)

Retropie: Crea tu retroconsola

Bruno Orcha García — Thu, 27 Oct 2016 00:00:00 +0000

Hace unos meses Nintendo anunciaba una nueva consola destinada a tocar la fibra sensible de todos los ochenteros que hemos tenido la suerte de haber conocido la maravillosa generación de consolas Atari/MasterSystem/Nes/MegaDrive/SuperNintendo. Se trata de la Nintendo Classic Mini una réplica en miniatura de la NES con una selección de 30 juegos, simples, espartanos, pero super adictivos.

No tengo la menor duda de que será un superventas estas navidades. Aunque podríamos señalar dos inconvenientes: Solo permiten dos jugadores y los juegos son exclusivamente los 30 elegidos.

¿Habrá que esperar a una Super Nintendo Classic Mini para poder volver disfrutar del Yoshi’s Island o del Street Fighter II?
¿No podré utilizar mi mando bluetooth retro de NES?
¿Tampoco tardes de cuatro jugadores con Super Bomberman, Micro Machines o Mario Kart?

Para resolver estos inconvenientes siempre podemos crear nuestra propio sistema de emulación, algo pequeñito del estilo de la Nintendo Classic Mini, algo sencillo, para enchufar y jugar. Y nada como una RaspberryPi para ajustarse a estos requisitos.

Raspberry

De los modelos de Raspberry mas actuales que podemos elegir, tenemos la Raspberry Pi Zero que es la mas pequeña y barata, pero que no dispone de WI-FI, ni Bluetooth, ni salida RCA/Euroconector, ni puertos USB “de los normales”. Aunque si eres manitas siempre puedes añadir una salida RCA, añadir un módulo wifi, y buscar algún HUB USB.

Y la opción mas recomendable y sencilla es usar la Raspberry Pi 3 Model B, que es mas cara, mas potente, tiene WI-FI, puerto ethernet, bluetooth, salida RCA y 4 puertos USB listos para usar. Solo necesitaremos un par de cosas mas:

Raspberry 3 Model B 39 €
Carcasa 8.50 €
2 Mandos USB de estilo retro 12 €
Y buscar por casa una tarjeta microSD, un cable HDMI y un cargador de móvil.

Instalación

El siguiente paso sería instalar el software necesario. Tendremos que instalar un sistema operativo para Raspberry (cualquier de los muchos sabores de linux que hay), instalar y configurar cada uno de los emuladores con los que querríamos jugar (FCEUmm, Snes9x, DOSBox, ScummVM, Mupen, PPSSPP, y la lista sigue …), configurar los mandos USB que queramos utilizar. Pero, una vez que lo hayamos hecho, ¿como hacemos para elegir el emulador con el que queremos jugar cada vez? Necesitaríamos también un teclado y raton para poder iniciar cada emulador por separado, y poder cerrarlo y elegir el siguiente. Cada emulador tiene su propio interfaz, sus opciones de configuración, su proceso de mapeo de teclas y botones del mando, etc.

Afortunadamente existe un proyecto llamado libretro que simplifica este problema. Este proyecto implementa una librería que unifica el acceso a distintos emuladores, proporcionado un interfaz único para usarlos. Esto se traduce en que una aplicación que utilice libretro podrá ser capaz de iniciar cualquier juego de forma transparente al emulador que finalmente lo ejecute, lo que nos permitirá configurar y ejecutar las distintas plataformas de forma sencilla.

Ahora necesitaríamos una aplicación que nos facilite la gestión de las distintas roms, opciones de configuración y permite iniciar los distintos juegos de forma transparente al emulador sin necesidad de estar usando teclado y raton. Y EmulationStation es la aplicación perfecta para esto.

EmulationStation es la aplicación que querremos iniciar por defecto. Nos permite navegar entre las distintas plataformas de forma gráfica, seleccionar los juegos, descargarse metadatos para que aparezca la carátula, nombre, año, etc. Y nos permite por supuesto iniciar los juegos, configurar opciones globales, configura los mandos de forma global. Y todo esto con una usabilidad y experiencia de usuario digna de alabar. Chapó!

Retropie

Afortunadamente existe un proyecto que se ocupa de todo lo anterior. Retropie es un proyecto que se encarga de prepararnos una distribución Debian para Raspberry junto con libretro/retroarch, con todos los emuladores y con EmulationStation de inicio. ¡Así que todo se reduce a copiar la distribución de Retropie a nuestra microSD, y listo!

Los instrucciones de instalación son bien sencillas: descargar la imagen e instalarla en la microSD con Windows, Linux o Mac.

Una vez iniciemos nuestra Raspberry Pi con la microSD de Retropie nos aparecerá EmulatioStation. Cada vez se detecte un nuevo tipo de mando USB, tendremos que configurar los botones. Si el mando no dispone de alguno de los botones, dejaremos pulsado durante unos segundos cualquier botón ya mapeado anteriormente.

Entre las plataformas que muestra EulationStation veremos que existe una que es Retropie desde la que podremos iniciar distintos scripts de utilidades y configuración de Retropie. Uno de ellos nos permite configurar el WI-FI (necesitaremos enchufar un teclado momentáneamente) o consultar la IP actual.

Lo único que nos queda copiar nuestras roms en la correspondiente carpeta de la raspberry. Para eso tenemos varias opciones, copiarlas con scp (accediendo con el usuario pi y contraseña raspberry) o usando una memoria USB. Para ello retropie tiene configurado un mecanismos de sincronización con rsync. Solo creamos una carpeta retropie en la raíz de la memoria USB y la enchufamos a la raspberry. Tras unos segundos se habrá sincronizado la estructura de carpetas de roms que se utiliza. Ya podremos volver a enchufar el USB en un PC y copiar las roms que queramos en las carpetas correspondientes.

Así que solo nos queda disfrutar de divertidas tardes de juegos retro.

P.D.: Para salir de los juegos y volver a EmulationStation hay que pulsar SELECT + START. Si aparece un cuadrado multicolor en la esquina es porque el cargador no suministra suficiente potencia y deberíamos probar con otro.

Docker en máquinas de 32bits

Bruno Orcha García — Fri, 12 Feb 2016 00:00:00 +0000

Si dispones de una máquina y/o una distribución de Linux de 32 bits (Como por ejemplo Ubuntu 14.04 32bits) e intentas instalar Docker te puedes encontrar con el siguiente mensaje:

En la propia página web podemos encontrar los requisitos referentes a Ubuntu Linux:

Docker requires a 64-bit installation regardless of your Ubuntu version. Additionally, your kernel must be 3.10 at minimum.

Aunque nuestro sistema no cumpla con estos requisitos todavía tenemos una alternativa. Usar la misma técnica que se utilizaba en MacOSX y Windows para poder instalar docker, boot2docker.

Las herramientas de docker utilizan el paradigma cliente/servidor, por lo que cuando lo instalamos tenemos por un lado la parte cliente, que sería el comando de consola docker, y por otro lado la parte servidor o servicio docker que utiliza ciertas características del kernel de Linux para crear y administrar los contenedores.

En el caso de MacOSX y Windows, no se dispone de estas características en el kernel, por lo que la solución es instalar una máquina virtual con un Linux que proporcione esta parte servidor. Esta es la misión de boot2docker, proporcionar el mecanismo de crear e iniciar esta máquina virtual (basada en VirtualBox) para poder usar docker en otros sistemas operativos no soportados. El rendimiento será peor obviamente (ya que el “docker servicio” no se ejecutará de forma nativa como en un Linux de 64bits, si no que se ejecutará dentro del Linux de la máquina virtual de VirtualBox), pero será mas que suficiente para poder trastear.

Puesto que no existe boot2docker para sistema Linux de 32 bits tendremos que compilarlo a mano. Si echamos un vistazo al código fuente del proyecto veremos que nos encontramos con un problema recursivo: necesitamos docker para poder compilar esta aplicación, que es la que necesitamos precisamente para poder tener docker! :P

Si analizamos el Makefile y el Dockerfile del proyecto vemos que sencillamente se instala el compilador de go (lenguaje con el que está programado este cliente) y algunas dependencias. Afortunadamente se puede instalar el compilador de go con los binarios de la página oficial y podemos compilar automáticamente boot2docker-cli como cualquier otra librería:

cd /tmp
wget http://...../go1.5.3.linux-386.tar.gz
tar zxvf go1.5.3.linux-386.tar.gz
mkdir gopath && export GOPATH=/tmp/gopath
export GOROOT=/tmp/go
/tmp/go/bin/go get -v github.com/boot2docker/boot2docker-cli
sudo mv /tmp/gocode/bin/boot2docker-cli /usr/bin/boot2docker

En segundo lugar necesitamos el comando docker, que sería la parte cliente. Desde la sección de instalación de la página oficial se ofrece un enlace para descargar el binario para 32 bits:

https://get.docker.com/builds/Linux/i386/docker-latest

Ya tendríamos todo lo necesario en nuestra máquina de 32 bits. La primera vez necesitaremos que boot2docker se descargue y configure la máquina virtual de VirtualBox que proporcionará la parte servicio de docker:

boot2docker init

Cada vez que queramos usar docker deberemos iniciar este servicio:

boot2docker start

Una vez se inicie se nos mostrará las variables de entorno que informan al comando docker con qué servidor docker hablar. Los copiamos y ejecutamos en nuestra sesión y listo, ya podremos usar docker normalmente en nuestra máquina de 32 bits:

docker run ubuntu:14 echo "hola mundo!"

Happy dockering!

P.D.: Si abrimos un nuevo terminal hay que volver a establecer las variables de entorno. Podemos ejecutar boot2docker shellinit para volver a mostrarlas.

Sincronización de carpetas

Bruno Orcha García — Thu, 06 Aug 2015 00:00:00 +0000

En ocasiones nos vemos en la necesidad de tener que modificar ficheros en servidores remotos. Servidores de los que sólo disponemos de conexión ssh para acceder normalmente. Cuando se trata de realizar modificaciones puntuales sobre unos pocos archivos, como pueden ser ficheros de configuración o propiedades, es suficiente con iniciar una sesión ssh, y utilizar el editor de consola disponible en el servidor, como puede ser vi, nano o emacs. El problema se complica cuando necesitamos realizar estas modificaciones constantemente, por ejemplo, cuando queremos desarrollar contra un servidor remoto.

Imaginemos que en el equipo del trabajo, tenemos una carpeta con algún proyecto web escrito en php, python o Ruby on Rails. Si en otro momento, estamos trabajando remotamente desde nuestras casas y nos vemos en la necesidad de seguir desarrollando en este proyecto tenemos varias opciones:

Conectarnos gráficamente al ordenador remoto y seguir utilizando nuestro entorno de desarrollo habitual. Esto lo conseguimos con herramientas como VNC, TeamViewer, redirigiendo las X, usando Xpra, etc. El problema con esta opción es que suele ser lento (por limitación del ancho de banda, latencia, uso de VPN’s). Cuando programamos o usamos un IDE queremos que responda instantáneamente a nuestras pulsaciones y atajos de teclado, pero con estos sistema siempre se suele incluir un pequeño retardo que nos puede desesperar.
Montar el proyecto en el ordenador de casa. Si no disponemos de sistemas como Dockers o Valgrant, esto requerirá tener que instalar todas las dependencias que necesite el proyecto web. Esto puede ser complejo y requerirá instalar en el ordenador de casa las dependencias que se necesite (módulos python, gemas de ruby, librerías del sistema, etc). Si ademas dependemos de otros servicios (bases de datos, servicios web, comandos de consola) tendremos que instarlos localmente o comenzar a mapear puertos para poder acceder a ellos. Esto se complica aún mas si los sistemas operativos del trabajo y de casa son distintos (Linux vs Mac o incluso Debian 8 vs Ubuntu 14.10).
Conectarnos por ssh. Nuestro equipo del trabajo (o servidor remoto) ya está configurado y preparado para hacer funcionar el proyecto. Sólo debemos conectarnos, acceder a la carpeta del proyecto y realizar las modificaciones desde consola. El problema es que si no somos unos expertos en vi o emacs, si tenemos que estar modificando varios ficheros (abriendo y cerrando vi), navegar o buscar dentro del proyecto (usando comandos grep y find), volvemos a encontrarnos con la lentitud a la hora de programar con un entorno de desarrollo que no es el nuestro habitual.
Montar remotamente el directorio por cifs/samba/sftp/sshfs. En esta opción seguimos accediendo por ssh para lanzar la compilación o reiniciar el servidor web, pero la modificación y navegación de los ficheros del proyecto la podemos hacer con alguna aplicación desde nuestro ordenador de casa. Podríamos montar remotamente la carpeta del proyecto y abrirla con Aptana, Eclipse o SublimeText de nuestro ordenador de casa. Pero una vez mas la lentitud es el gran impedimento. Suelen ocurrir retardos al abrir los ficheros y sobre todo si intentamos buscar en el contenido de estos.

RSYNC

Existe otra opción adicional, que es la que mas utilizo últimamente. Por un lado tenemos la magnífica herramienta rsync. Este comando permite mantener sincronizados dos estructuras de carpetas de forma eficiente. Esta herramienta tiene multitud de opciones, ya que puede que nos interese o no, sincronizar también las fechas de los ficheros, los permisos, los propietarios, los enlaces simbólicos, borrar ficheros del destino, guardar los cambios en una tercera carpeta, etc. Así que por ejemplo, si en una misma máquina queremos tener sincronizada dos directorios escribiríamos lo siguiente:

$ rsync -navh /path/origen /path/destino

Siempre debemos tener mucho cuidado con este comando, y prestar mucha atención a la carpeta destino. De hecho la opción -n del ejemplo es la opción --dry-run que realmente no hace modificaciones, solo nos informa sobre que operaciones que se van a realizar y que siempre deberíamos probar antes de lanzar el comando de forma final … para evitar dolorosas equivocaciones.

También existe la posibilidad de utilizar este comando para sincronizar ficheros entre dos máquinas, para ellos debemos indicar con la opción -e qué comando se debe utilizar para llegar a la máquina remota. Lo mas habitual será utilizar ssh por lo que el comando quedaría de la siguiente forma:

$ rsync -navh -e ssh /path/origen usuario@servidor1:/path/destino

Llegados a este punto, lo único que tendríamos que hacer es copiarnos inicialmente la carpeta remote a nuestro ordenador local, y comenzar a editarlo con nuestra herramienta favorita, como puede ser SublimeText. Una vez hayamos realizado modificaciones podemos ejecutar el comando anterior y enviaremos las modificaciones realizadas en nuestro equipo local, hacia el servidor en el directorio destino.

Mejorando el flujo de trabajo

Con lo detallado anteriormente, la forma de trabajar por ahora sería la siguiente:

Copiamos en nuestro ordenador local el proyecto remoto con el que queremos trabajar (con un simple scp o utilizando rsync en el sentido inverso).
Comenzamos a editar de forma local el proyecto con nuestro IDE.
Cada vez que queramos probar algo, ejecutamos el comando rsync.
Una vez terminada la ejecución de rsync, reiniciamos el servidor remoto (webrick, apache, tomcat, jboss, node o lo que sea) si es necesario.

Pero aún podemos mejorar esta forma de trabajar, eliminando el tercer paso, en el que somos nosotros los que manualmente tenemos que lanzar el comando rsync periódicamente.

Para esto podemos utilizar la utilidad fswatch-rsync. Esto es un script en bash, que combina el uso de rsync con fswatch. fswatch es una utilidad que utiliza inotify/kqueue/poll que permite monitorizar los eventos producidos en un directorio. De esta forma, este script bash está preparado para detectar los cambios realizados en un directorio (que será nuestro proyecto), e invocará rsync indicándole además qué ficheros son los que han cambiado, permitiendo a rsync funcionar de forma aún más rápida y optima, ya que no necesitará analizar los ficheros del directorio origen y destino para decidir qué cambios hay que realizar. Además permite ignorar algunos eventos, como pueden ser los producidos en los directorios .git o .svn.

De esta forma, podemos trabajar de forma muy cómoda con proyectos en servidores remotos implementando un sistema de sincronización de baja latencia.