Logger en ruby

Similar al proyecto log4j existe para ruby una librería de logging para el depurado de aplicaciones, gestión de mensajes de error, etc.

El nombre de la librería es log4r, se distribuye como gema y es fácilmente personalizable.

Para usarla tan solo hay que instancia un objeto de la clase Logger. Para dicho objeto se pueden seleccionar distintos outputters (medio de salida), en el ejemplo se muestran los mensajes tanto por salida estándar como por UDP.

Posteriormente, para cada outputter se puede elegir un formatter (formato de la salida). En el ejemplo la salida por UDP será en el formato por defecto mientras que la salida estándar será en XML.

El ejemplo de uso de la librería.

require 'rubygems'
require 'log4r'
require 'log4r/formatter/log4jxmlformatter'
require 'log4r/outputter/udpoutputter'

include Log4r

logger = Logger.new 'mylog'

#Formatters
xmlformat = Log4jXmlFormatter.new

#Ouputters
stdout = Outputter.stdout
udpout = UDPOutputter.new 'udp', :hostname => "localhost", :port => 8888

stdout.formatter = xmlformat

logger.outputters = [stdout, udpout]


def debug(logger, txt)
  logger.debug txt
end

def error(logger, txt)
  logger.error txt
end


debug(logger, 'Mensaje de DEBUG')
error(logger, 'Mensaje de error')

Para más información se puede consultar la web oficial de log4r.

Lectura de memoria entre procesos Windows

En todos los sistemas operativos modernos la memoria está protegida entre procesos.
Si un proceso accede o escribe en una posición de memoria no esperada no debe afectar a los demás procesos.

A pesar de este planteamiento, en Windows es posible leer o escribir zonas de memoria entre procesos, para ello están las funciones del API ReadProcessMemory y WriteProcessMemory.

El primer paso es encontrar el PID del proceso en el que estamos interesados y después debe obtenerse un handle con la función OpenProcess.

Para buscar el proceso destino hay varias formas, en este ejemplo se usa el nombre de la ventana visible del proceso.

#include <QtCore/QCoreApplication>
#include <windows.h>

DWORD getPIDByWindowName(WCHAR* name);

int main(int argc, char *argv[]){
    QCoreApplication a(argc, argv);
    BYTE buffer[300];
    DWORD readed;
    DWORD processID = getPIDByWindowName(TEXT("Calculadora"));
    HANDLE procHandle = OpenProcess(0x0010, 0, processID);
    ReadProcessMemory(procHandle, (void*)0x00951558, buffer, 50, &readed);
    return a.exec();
}

DWORD getPIDByWindowName(WCHAR* name){
    DWORD processID;
    HWND windowHandle = FindWindowW(NULL, name);
    GetWindowThreadProcessId(windowHandle, &processID);
    return processID;
}

Gracias al uso de estas funciones del API se abre una nueva posibilidad de comunicación entre procesos, sin embargo, abre también un grave riesgo de seguridad. Entre otros usos, modificando la memoria de los procesos de antivirus o cortafuegos se pueden inutilizar dando una falsa sensación se seguridad.

Ejecución de tareas asíncronas en C++ con QT

En los programas con interfaz gráfica no deben ejecutarse tareas que puedan demorarse en el mismo hilo de la interfaz.
Esto ocurre muy a menudo si en el evento 'click' de un botón se hace una lectura/escritura de un fichero o una base de datos.

Con las librerías QT se puede solucionar de varias formas, una es creando un hilo (una clase que herede de QThread). Una forma aún más sencilla es crear un objeto QRunnable y hacer que el pool de QT lo ejecute en segundo plano.

Un ejemplo de lo segundo.

class AsynchrounousTask : public QRunnable{
    protected:
        QLabel *label;
    public:
        AsynchrounousTask(QLabel *label){
            this->label = label;
        }

        void run(){
            sleep(5); //long task;
            label->setText("Done!");
        }
};

Y para usarlo tan solo hay que hacer.

    AsynchrounousTask *aTask = new AsynchrounousTask(ui->label);
    QThreadPool::globalInstance()->start(aTask);

Aunque creamos un objeto con new no hay que preocuparse por su destrucción, al terminar su ejecución a través del pool se liberará de forma automática. Si preferimos que no se libere de forma automática tan solo hay que llamar al método 'setAutoDelete(false)'.

Ejecutando las tareas más pesadas de la aplicación de esta forma no se bloqueará la aplicación en ningún momento y siempre responderá a las nuevas peticiones que el usuario haga.

Compilación de ejecutable con Qt Creator

Cuando creamos una aplicación con Qt Creator en Windows es necesario incluir los ficheros dll de Qt para que la aplicación funcione correctamente.

En ocasiones este no es el comportamiento deseado, se puede generar un fichero ejecutable autónomo (sin necesidad de ninguna librería dll externa) ejecutando el siguiente comando:

qmake -nodepend -o Makefile project.pro

Si no se encuentra el programa qmake hay que añadirlo al PATH, la instalación por defecto de QT Creator no lo hace.
Una vez ejecutado el comando anterior, al compilar obtendremos un ejecutable con toda la funcionalidad incluida, sin necesidad de incluir ningún fichero dll.

Anidamiento de módulos en ruby

Tal y como ocurre en python con los decoradores, cuando se programa un módulo en ruby debería dejarse la puerta abierta a que no fuera el único.

En el siguiente ejemplo tenemos dos módulos (Printable y Serializable), ambos métodos se deben poder combinar en cualquier orden y pudiendo aparecer uno, ninguno o ambos.

La clave para que un mismo método se ejecute en la clase y en cada uno de sus módulos, es la llamada a super.

En otros lenguajes esto no sería correcto, puesto que los módulos Printable y Serializable no son superclase de la clase Test, pero en ruby, super no llama exactamente a la superclase, sino que repite el mismo método que se está ejecutando obviando la definición actual.

module Printable
 def print_method
  super
  puts "I'm printable"
 end
end

module Serializable
 def print_method
  super
  puts "I'm serializable"
 end
end


class Test    
 include Printable
 include Serializable

 def method_missing(method, *args, &block)
  super if method.to_s != 'print_method'
 end

 def print_method
  super
  puts "I'm object of Test class"
 end
 
end

t = Test.new
t.print_method

Con este planteamiento hay un problema añadido, al final de la cadena de llamadas a print_method estará la clase de la que hereda Test, y esta clase no tiene porqué tener implementado print_method.

Para solucionarlo en este caso se redefine el method_missing, cuando llegue el momento de ejecutar el método en alguna clase/módulo que no lo entienda, se corta la cadena de ejecuciones.

I'm printable
I'm serializable
I'm object of Test class

Conversión implícita de tipos

Es común escribir nuevas clases que expandan a las básicas del lenguaje.

Uno de los problemas que nos podemos encontrar cuando hacemos esto es la conversión de tipos.

Si por ejemplo creamos una nueva clase para manejar cadenas, el código se llenará rápidamente de castings para convertir las cadenas nativas del lenguaje a nuestra implementación. Esto ocurre sobre todo en lenguajes fuertemente tipados.

C# provee una solución bastante elegante, la conversión implícita de tipos.

Para mostrar el uso de esta característica se muestra una clase con dos tipos, una cadena y un entero y sus declaraciones de conversiones implícitas.

public class MyClass
{
    private string str { get; set; }
    private int number { get; set; }

    public static implicit operator MyClass(string s)
    {
        MyClass ms = new MyClass();
        ms.str = s;
        return ms;
    }

    public static implicit operator MyClass(int i)
    {
        MyClass ms = new MyClass();
        ms.number = i;
        return ms;
    }

    public string getStr()
    {
        return str;
    }

    public int getNumber()
    {
        return number;
    }
}

Declarando un operador estático, implícito y público se consigue la sintaxis siguiente para la conversión de tipos.

MyClass ms1 = "hello";
MyClass ms2 = 2;

Console.WriteLine(ms1.getStr());
Console.WriteLine(ms2.getNumber());

En el ejemplo se puede ver que no es necesaria ninguna conversión, y se pasan tanto la cadena "hello" como el entero 2 a tipo MyClass.

Extension methods en c#

En algunos lenguajes dinámicos como ruby las clases se denominan "abiertas".
Esto significa que a cualquier clase se le puede añadir nuevos métodos o funcionalidades en tiempo de ejecución.

Los lenguajes fuertemente tipados no suelen ofrecer tanta libertad, pero se disponen de otras herramientas.

En C#, se pueden definir clases parciales, lo que significa que se puede definir el comportamiento de la clase en varias etapas.

public partial class PartialClass
{
    public static void method1()
    {
        Console.WriteLine("method1"); 
    }
}
...
public partial class PartialClass
{
    public static void method2()
    {
        Console.WriteLine("method2");
    }
}

Manteniendo las clases como parciales en cualquier momento se puede añadir funcionalidad a una clase existente fuera de su definición original.

Este método es útil tan solo para las clases que programamos, pero si queremos extender una librería externa o las clases del propio lenguaje las clases parciales no son de gran ayuda.

C# tiene en cambio una posibilidad más interesante, los "extension methods".

public static class ExtensionMethods
{
    public static string withDot(this string str)
    {
        return str + ".";
    }
}
...
string str = "text ";
str.withDot();

Con el código anterior se le añade a la clase string el nuevo método (withDot).
Para hacer lo mismo sin "extension methods" habría sido necesario crear una nueva clase que heredara de string y añadirle el método withDot.

Gracias a los "extension methods" se puede evitar crear clases intermedias para extender funcionalidades de las ya existentes.