debugging remoto de scripts Python con winpdb

Usando el programa winpdb se pueden debuggear scripts en Python de manera mas intuitiva que con el clásico pdb.

Una de las ventajas que tiene winpdb es la posibilidad de debuggear scripts que esten ejecutandose en remoto en algun servidor. De esta manera, se pueden debuggear no solo scripts en servidores de producción, por poner un ejemplo, sino también scripts que utilicen curses para manipular la pantalla.

winpdb se basa en una arquitectura de cliente-servidor que comunica al servidor (el cual ejecuta el script a debuggear en sí) a través de sockets con el cliente (el cual ejecuta la interfaz del debugger).

Configurar POI en Spring 3 para generar archivos Excel

He decidido registrar el proceso de como generar archivos Excel con POI mediante Spring 3 para que no se me olvide (aunque es bastante sencillo).  Me sorprendí de terminarlo en tan sólo 3 pasos!

1) Generar un controller que obtiene los valores que se pretenden mostrar en la vista, los agrega al modelmap de MVC que maneja Spring y luego devuelva el nombre de la vista encargada de generar el excel.

@Controller
@RequestMapping("/excel")
public class ExcelController {

    @Autowired
    private Servicio servicio;

    @RequestMapping(value = "/{parametro}", method = RequestMethod.GET)
    public String generarExcelByParametro(
            ModelMap modelMap, HttpServletResponse response,
            @PathVariable("parametro") String nombreVista) {
        modelMap.put("datos", servicio.obtenerDatos(parametro));

        response.setHeader("Content-type", "application/vnd.ms-excel");
        response.setHeader("Content-Disposition","attachment; filename=\"excel.xls\"");
        return "reporteExcel";
    }

}

Observa que el método generarExcelByParametro() del controller responde a una petición http://{servidor:puerto}/{contexto}/excel/{parametro} y realiza algo en un servicio que devuelve cierta información que se espera administrar de lado de la vista (más adelante lo vemos) y lo guarda dentro del ModelMap de spring con el identificador "datos".

Los headers que se agregan al response, son solo para asegurar que cuando se genere el archivo .xls, se identifique como tal y se obligue al usuario a descargarlo.

Finalmente la cadena ("reporteExcel") que se devuelve determina el nombre de la vista que interpretara los datos para generar el documento.

Servidor VNC para sesiones de escritorios remotos

Introducción
VNC (Virtual Network Computer) es el software a través del cual se puede iniciar sesión en escritorio remoto con GNU/Linux.

Otra opción es el RDP de Windows, sin embargo aquí explicaremos únicamente como configurar el servidor para el caso de VNC.

Lo primero que hay que saber es que VNC funciona para controlar escritorios remotos que utilizan el servidor gráfico X-Window , el default de GNU/Linux hasta ahora. Sin entrar en detalles de cómo funciona X-Window, basta saber que en este tutorial explicaremos dos opciones:

1. controlar el escritorio X real que se tenga en el escritorio remoto
2. controlar un escritorio X virtual que se crea a demanda en dicho escritorio remoto

Ambas opciones tienen posibilidades de aplicación.

DBUnit lo hace facil

Dado que he trabajado con JUnit y DBUnit y he encontrado en ellos unas buenas herramientas para probar el codigo de las aplicaciones en java, pues me dí a la tarea de investigar un poquito sobre como obtener datasets desde una BD, y como cargarlos para realizar pruebas específicas.  Fue entonces cuando me encontré con este artículo de Bill Siggelkow y me dí a la tarea de traducir una parte, también he agregado notas mías, pero pueden encontrar el original en enlace al final del post.

Y dice así:
Si desarrollas aplicaciones que acceden a datos relacionales necesitas verificar el código de tu aplicación trabaje con los datos, como fue diseñado.  Cuando usas Hibernate o algún otro framework que implemente JPA, deberías confirmar que tus mapeos dirijan a Hibernate para almacenar y recuperar la información correctamente.  Yo implemento este tipo de pruebas usando JUnit.  Nadie puede refutar que las pruebas contra una base de datos activa es fundamental - no hay una mejor forma para verificar tus mapeos.

Pero para probar contra la base de datos se requiere que los datos se encuentren en un estado inicial.  Puedes cargar la base de datos manualmente antes de correr tu prueba pero eso se vuelve monotono y propenso a errores. DBUnit resuelve este problema.  Este puede precargar la base de datos para cada una de tus pruebas, basado en un grupo de datos dentro de un xml (comúnmente llamado dataset).  El formato de este dataset es sencillo de entender; aquí hay un ejemplo de tres tablas de una base de datos MySQL.  Los nombres de los elementos empatan con los nombres de las tablas y sus atributos con los nombres de sus columnas. Cada elemento implica un registro en esa tabla.

<dataset>
    <cliente id_cliente="778899" id_estatus = "1" id_sucursal="98765"/>
    <banco id_banco="1" nombre="BNMX" descripcion="Banamex" activo="1"
valor="0"/>
    <pago id_cliente = "778899" id_estatus = "1" id_tipo_producto =
"1" id_promotor = "1" id_sucursal = "58" />
</dataset>

Para una base de datos pequeña donde solo necesitas cargar unas pocas tablas con unos pocos registros puedes crear el dataset manualmente. Pero seguramente no querás hacerlo con una base de datos empresarial compleja que contiene cientos de tablas con nombres de columnas complejas.  Es más facil si le permites a DbUnit extraer los datos por ti.