Patrones de Comportamiento (II): Patrón Command

Objetivo:

«Encapsular una petición como un objeto, de modo que puedan parametrizarse otros objetos con distintas peticiones o colas de peticiones y proporcionar soporte para realizar operaciones que puedan deshacerse».

Design Patterns: Elements of Reusable Object-Oriented Software

Cuando decimos que un patrón es «estructural» es sencillo imaginar que su cometido será modelar las clases de tal forma que cumplan un cometido concreto. Sin embargo, el concepto de diseñar clases orientando su funcionalidad hacia el comportamiento es algo más complicado. El patrón command u orden (como decía mi profesor de programación en primero de carrera, command se debería traducir por órden, no por comando, ya que un comando es un señor militar que pega tiros en la selva) tiene como objetivo encapsular la invocación de un método. Dicho así sin más, suena sencillo de entender pero… ¿cómo lo implementamos? La definición, a diferencia del patrón anterior, es un conglomerado de términos incomprensibles, ¿verdad? Encapsular una petición como un objeto. Vale, lo pillo. Pero ¿parametrizarse? ¿Soporte para realizar peticiones que puedan deshacerse?

Patrones de Comportamiento (I): Patrón Iterator

Objetivo:

«Proporcionar una forma de acceder a los elementos de un objeto agregado de forma secuencial sin exponer sus detalles».

Design Patterns: Elements of Reusable Object-Oriented Software

Pese a que no seamos conscientes de ello, cuando programamos utilizamos el patrón Iterator a diario. Casi todas las estructuras de datos que representan colecciones utilizan de algún modo este patrón para proporcionar acceso secuencial a los elementos que las conforman, y tanto Java como .NET ofrecen interfaces que nos invitan a implementar este patrón codificando su comportamiento.

Ojo al detalle: hemos dicho recorrer secuencialmente, esto es, hacer uso de un proceso que sea capaz de situarse en el primer elemento de una colección y obtener la información de ese contenido. Tras esto, dado que hemos dicho que se trata de una operación secuencial, deberemos ser capaces de pasar del elemento actual al elemento al siguiente, obteniendo también su contenido. Por último, será necesario implementar algún mecanismo que nos informe si hemos alcanzado el final de la colección para detener el proceso de iteración.

Por lo tanto, el patrón Iterator debe proporcionar la siguiente funcionalidad:

• Obtener una referencia al elemento actual de la colección.
• Obtener una referencia al siguiente elemento de la colección (el situado a continuación del elemento actual).
• Obtener información sobre si existen más elementos después del actual.
• Reiniciar la colección para que el iterador apunte nuevamente al primer elemento de la colección.

Seguramente podremos pensar que no tiene mucho sentido implementar nuestro propio patrón Iterator, ya que prácticamente todas las colecciones implementan todas estas operaciones (e incluso alguna más). Sin embargo, existirán muchos supuestos en los que nos será útil.

Patrones Estructurales (VII): Patrón Proxy

Objetivo:

«Proporcionar un sustituto o intermediario para otro objeto de modo que pueda controlarse el acceso que se tiene hacia él».

Design Patterns: Elements of Reusable Object-Oriented Software

Supongo que todos conocemos el concepto de proxy, al menos en su acepción aplicada a la navegación web. Se trata de una máquina que actúa de intermediaria a la hora de servir páginas web (u otros servicios). En la configuración de área local podemos indicar la IP de esta máquina y será esta máquina la que se conecte a la URL por nosotros y la envíe a nuestro equipo.

De este modo, un equipo no se conectará directamente a la URL, sino que lo hará a través de este intermediario. ¿Por qué hacer esto? Por múltiples motivos: podemos, por ejemplo, restringir las URLs que nuestros clientes (ordenadores de la red local) pueden visitar. O cachear las páginas que se visitan con más frecuencia, haciendo innecesario el acceso a la web «real» en los casos en los que el acceso se repita, proporcionando un ahorro en ancho de banda. En resumen, un proxy será una entidad en la que delegaremos la ejecución de ciertas tareas y que decidirá, en última instancia, qué acciones realizar antes y después de éstas. Los proxies, por tanto, podrían dedicarse perfectamente a la política 🙂

Patrones Estructurales (VI): Patrón Composite

Objetivo:

«Componer objetos en árboles para representar jerarquías todo-parte. Composite permite a los clientes tratar objetos individuales y objetos compuestos de una manera uniforme».

Design Patterns: Elements of Reusable Object-Oriented Software

El patrón Composite se aleja un poco de la línea tradicional de los patrones vistos hasta ahora, ya que rompe uno de los principios de la programación orientada a objetos: una clase, una responsabilidad. En realidad, los más puristas pueden decidir no hacerlo, pero el precio a pagar es demasiado alto para los ingenieros mortales: la simplicidad del modelo.

Cuando diseñamos debemos tener claro que la idea principal es alcanzar un equilibrio entre muchos factores como por ejemplo presupuesto, usabilidad y facilidad para que nuestro código sea reutilizable y pueda ser fácilmente mantenible en un futuro. Si el objetivo del anterior patrón, Flyweight, era el rendimiento, el sine qua non de este patrón es la facilidad de uso.

Simular teclado y ratón en aplicaciones de terceros

English version here.

La simulación de una pulsación de una combinación de teclas o de una pulsación del ratón en una aplicación propia es relativamente sencillo: basta con hacer uso del método SendKeys para que nuestra aplicación reciba datos desde teclado y la invocación explícita del método adecuado que esté asociado al evento del ratón para simular un click del ratón.

Sin embargo, si deseamos crear un programa cuya misión consista en realizar estas operaciones en un programa de terceros, deberemos hacer uso de código no administrado.

Código administrado y no administrado.

El código administrado es aquel que se ejecuta bajo el control del CLR (Common Language Runtime), es decir, aquel código escrito en .NET que es compilado a un código intermedio MSIL o CIL (dependiendo de la versión del Framework) y que en tiempo de ejecución es transformado en código nativo. Este es el proceso natural de la programación .NET, con el que supongo que todos o casi todos estamos familiarizados.

El código no administrado, en cambio, es aquel código ajeno a este ciclo de vida, tal como el incluido en componentes COM/COM+, C++, ActiveX o la propia API de Windows (que es donde centraremos el objetivo de este artículo).

Windows expone su API a través de un conjunto de bibliotecas de enlace dinámico (dll) tales como user32.dll (permite manejar ventanas y sus eventos), shell32.dll (procesos), winspool.drv (impresión)… Para hacer uso del teclado y el ratón en aplicaciones de terceros nos centraremos en la biblioteca user32.dll, que como podemos imaginar, se tratará como código no administrado.

Bases de datos portables (II): Combinando Entity Framework con SQLite

English version here.

En el artículo anterior vimos que es posible hacer uso de ADO.NET para crear una aplicación que utilice SQLite como base de datos. De este modo, con una base de datos local y ampliamente utilizada es posible aumentar radicalmente la portabilidad de nuestra aplicación si ésta no requiere la potencia de una base de datos «tradicional». Sin embargo, la utilización de ADO.NET de forma directa implica dejar de lado todos los avances que Microsoft ha implementado a lo largo de estos últimos años en materia de mapeo objeto-relacional.

Ya que hemos aprendido a utilizar Entity Framework, ¿por qué no hacer uso de él con SQLite y dejarnos de «picar» código SQL de forma manual? A continuación veremos cómo podemos lograrlo.

Entity Framework (VI): Webservices

Hasta ahora hemos visto el funcionamiento de LINQ y Entity Framework. La siguiente serie de artículos estarán orientados hacia los servicios web, por lo que haremos una pequeña introducción aplicando los conocimientos que hemos obtenido hasta el momento.

Lo primero que deberemos aclarar es el propio concepto de servicio web. Ya vimos en artículos anteriores de qué se tratan, cómo se crean y cómo se consumen estas pequeñas aplicaciones cuyo objetivo es el intercambio de información entre distintas plataformas y lenguajes de modo estándar.

Para crear un nuevo servicio web, crearemos un nuevo proyecto web de tipo ASP.NET Empty Web Application y le asociaremos un nuevo nombre. Los servicios web reciben ese nombre porque operan sobre el protocolo HTTP, así que este será nuestro punto de partida.

Nueva etapa

Tras una serie de catastróficas desdichas que comienzan con un problema con el anterior hosting y continúan con la corrupción del disco duro en el que almacenaba el backup de la web, he decidido hacer borrón y cuenta nueva y retomar el blog como lo que es: una colección de pequeños apuntes que proporcionan soluciones concretas a problemas concretos.

Pese a que «crecí» con la tecnología .NET, en los últimos años he tenido la oportunidad (y suerte) de formarme y trabajar en otras tecnologías (Diseño web, Java, ADA, Android…). Por lo tanto, este espacio dejará de centrarse exclusivamente en la plataforma de Microsoft y comenzará a diversificar su contenido.

¡Nos leemos!

Recuperar una contraseña almacenada automáticamente mediante Javascript

Últimamente existe una cruenta batalla en la plataforma Windows entre Internet Explorer y Firefox. Personalmente, yo no me decanto hacia uno ni otro: utilizo Opera desde su versión 6.05, allá por 2002. Indico que utilizo Opera porque es un navegador que posee una funcionalidad llamada «varita mágica», que no es más que un gestor de contraseñas en las que, pulsando ALT+ENTER se introducen automáticamente el nombre de usuario y la contraseña de una web en la que se hayan almacenado estos datos previamente.

Esta «comodidad» tiene un precio: a veces, de tanto utilizar este sistema, se me olvida alguna contraseña a causa del desuso, lo que causa que mi navegador la conozca y yo no.

Para paliar esta posibilidad, teniendo acceso a la página con el nombre de usuario y la contraseña, es posible averiguar el contenido del campo oculto entre asteriscos mediante una pequeña «treta» en Javascript. Lo primero que deberemos hacer será visualizar el código fuente de nuestra página (normalmente, haciendo click derecho sobre la misma y pulsando «Ver código fuente» o algo así, dependiendo del navegador).

Una vez visualizado, comprobamos la etiqueta que se muestra antes del campo que alberga la contraseña. En GMail, por ejemplo, «Contraseña». Buscaremos este texto en el código fuente, obteniendo algo como lo que sigue: Como podemos observar, nos encontramos con un Input con un campo ID.

El valor de esa variable, en nuestro caso «Passwd», es lo que nos interesa. Volveremos a nuestra página, y escribiremos lo siguiente en nuestra barra de navegación:

javascript:alert((document.getElementById('Passwd')).value);

Lo que le estamos diciendo a nuestro navegador es: «Ejecuta el siguiente código javascript: muestrame una alerta con el valor del elemento cuyo ID es ‘Passwd'».

Acto seguido, se mostrará el contenido del campo en texto plano.

Es ahora tarea del usuario el ejecutar este código lejos de la vista de un posible mirón y, por supuesto, en un PC no comprometido… 😉

Transacciones en ADO.NET (II): Activando las Transacciones Distribuidas mediante MSDTC

Anteriormente hemos aprendido a utilizar entornos transaccionales o Transaction Scopes. El ejemplo anterior mostraba lo que se conoce como una ‘transacción ligera’ que afecta a varias tablas de una misma fuente de datos. Sin embargo, en numerosas ocasiones se nos presentará la dificultad añadida de trabajar con múltiples fuentes de datos localizadas incluso en puntos geográficos diversos.

Para solventar esta dificultad, el propio Windows nos ofrece la posibilidad de utilizar las llamadas Transacciones distribuidas. Por defecto aparecen deshabilitadas, por lo que a continuación, mostraremos cómo activarlas. Una vez activadas, utilizaremos la clase TransactionScope como si se tratara de una transacción ligera, dejando en manos del sistema operativoel control de la propia transacción.

El sueldo de un informático

Durante los años de bonanza económica, los profesionales de IT nos hemos quejado mucho de nuestros sueldos. Abanderados del mileurismo, hoy por hoy podemos comprobar que, pese a la omnipresente y mediática crisis en la que nos hallamos inmersos, la demanda de profesionales del sector sigue siendo muy elevada.
Curioso por el sueldo medio de un profesional de IT ajeno a mi actual empresa, me decidí a realizar un pequeño estudio acerca de lo que puede cobrar un profesional del gremio en relación a la experiencia aportada, y el resultado queda reflejado en la siguiente tabla:

EVOLUCIÓN SALARIAL POR CATEGORÍAS	€ Bruto/anual	€ Neto/mes (14 pagas)	€ Neto/mes (12 pagas)
Programador Junior (0-2 años)	13.000	820	972
	14.000	860	1.020
	15.000	910	1.080
	16.000	960	1.130
	17.000	1.020	1.200
Programador Semisenior (2-3 años)	18.000	1.060	1.260
	19.000	1.100	1.310
	20.000	1.160	1.370
	21.000	1.200	1.420
	22.000	1.260	1.490
Programador Senior (3+ años)	23.000	1.300	1.500
	24.000	1.350	1.600
	25.000	1.400	1.670
	26.000	1.450	1.715
	27.000	1.500	1.780
	28.000	1.540	1.820
	29.000	1.590	1.880
Analista-Programador Senior	30.000	1.650	1.950
	31.000	1.680	1.990
	32.000	1.730	2.050
	33.000	1.780	2.110
	34.000	1.840	2.170
	35.000	1.870	2.210
Analista / Jefe de Proyecto	36.000	1.920	2.270

Hay que destacar un par de hechos importantes:

• En primer lugar, los sueldos varían muchísimo de unas comunidades a otras. Un programador senior en Madrid puede cobrar perfectamente más de 5000€ brutos/anuales más que en Castilla y León, por poner un ejemplo. Obviamente, hay que tener en cuenta que el coste de la vida en la capital es mucho mayor que, por ejemplo, en Soria, Ávila o Zamora.
• Como segundo apunte, las estimaciones dadas son orientativas. He tomado como fuente de los sueldos netos una herramienta online para calcular salarios, mientras que los datos de los sueldos medios han sido extraídos de Infojobs Trends Salarios y de un estudio previo del tema.
• La tecnología también influye dramáticamente. Las tecnologías o especialidades mejor pagadas son, en orden ascendente, PHP, Java, .NET, Administración de Sistemas y SAP, por lo que habría que calibrar positiva o negativamente estos datos acorde a la especialidad. El punto medio está tomado en Java / .NET, por lo que un programador PHP cobrará algo menos de lo marcado en la tabla, y un especialista en SAP cobrará sensiblemente más.
• Por último, me he permitido la licencia de marcar los objetivos más clásicos a nivel de sueldo: un mileurista cobra, como mínimo, cerca de 17.000 € brutos anuales. Para cobrar 1.200 serán necesarios 21.000 € brutos/año, mientras que si queremos alcanzar los 1.500 hará falta una nómina de 27.000 € brutos/año.
• Otro dato a tener en cuenta: las empresas tienden a actuar como las operadoras de telefonía móvil, bancos o proveedores de ADSL: es más fácil mantener a un trabajador que atraer a uno nuevo, por lo que los incentivos salariales para los recien llegados tienden a ser mayores que para «los de casa». Es fácil que un nuevo trabajador con 3 años de experiencia cobre más que un trabajador que lleva 5 años en la empresa. Por lo tanto, la movilidad laboral tiende a influir positivamente en el aumento de sueldo (como describía con mordaz ironía sinergia sin control).