El blog del burgués

11 abril 2011

Lobos y felinos

Filed under: Uncategorized — elburgues @ 10:55 PM

El Madrid de Mourinho es un equipo que resulta curioso. Bien plantado en el terreno de juego, alto nivel de concentración, no es fácil ponerlo contra las cuerdas, es muy difícil verlo descompuesto, desbordado. No practica un pressing en el centro del campo que resulte asfixiante, tampoco muestra obsesión por el control del balón, no necesita de un juego muy fluido para resultar peligroso. Es difícil marcarle goles (el año pasado con Pellegrini ya era difícil), sin embargo, tampoco da la sensación de ser inexpugnable, es como si el número de goles que encaja fuera un dato bueno comparado con el nivel de control que parece mantener en esa zona del campo. Es como si sus rivales crearan más sensaciones de peligro que ocasiones de gol manifiestas, como si un porcentaje de la labor defensiva se cediera a la confianza. Con un presupuesto como el suyo y con varios jugadores de primer nivel mundial, no es raro ver como equipos inferiores parecen hacer más por jugar al fútbol. Comienza el absurdo en dónde el hincha del Madrid, aparte de aburrirse, tiene la sensación de que el mismo partido enfocado de otra manera podría solucionarse sin necesidad de verse en esa situación, incluso ridícula. Pasan los minutos, el partido no conduce a ninguna parte y el absurdo crece. Y es precisamente en ese absurdo en donde el Madrid se hace fuerte. De repente, un ataque igual de absurdo que su juego, en carrera larga que termina por escorarse a una banda en una situación en desventaja de 2 o incluso 3 contra uno, buscando la jugada imposible. De vuelta al absurdo en dónde el Madrid ejerce el control, el siguiente latigazo está por llegar. Terminado el partido, cuando el marcador muestra un balance favorable, el Madrid te deja como si estuvieras atrapado en el tiempo, como si el mismo partido lo hubieras visto una y otra vez, ahora eres tu el que se siente ridículo por haber pensado que jugando así no se puede ir a cazar por los campos, te sientes timado por haber sentido más peligro del que en realidad hubo.

Por otro lado está el BarÇa. Los regates del Madrid son de 20 metros, los del BarÇa son de 20 centímetros. El BarÇa ataca como una manada de lobos, acorralan por ambas bandas a su presa, su resistencia y trabajo en equipo la hace finalmente desfallecer, muchas veces sus goles se intuyen minutos antes. El Madrid ataca como un guepardo, se desplaza por el campo en modo de bajo consumo para apretar el kers en el momento justo, gastan todas las reservas de energía en 6 segundos, no se les ve venir. Te preguntas que ha pasado, estás jugando mejor que ellos, es injusto, absurdo. Y es que los dos son grandes depredadores, pero no tienen nada que ver. El BarÇa basa todo su juego en el pressing de una manada de lobos como mecanismo de inmediata recuperación de la pelota para ponerla al servicio de las mejores botas del mundo. Disputar la posesión del balón al BarÇa es imposible. Pero es evidente que últimamente algo ha cambiado en el BarÇa y Pep lleva un tiempo viéndolo. Han perdido a sus dos defensas más rápidos, Puyol y Abidal, bueno para las cualidades del felino. Eso ha supuesto trastocar un poco el esquema de juego y el rendimiento ha caído y la defensa se ha vuelto un poco más insegura, pero el Madrid no va a cambiar y el BarÇa va a tener la posesión del balón en la zona de 3/4 del campo, justo dónde los lobos son más peligrosos, justo dónde al felino parece no importarle.

No tengo claro que el partido del próximo sábado en liga sea el menos importante de los cuatro que a fecha de hoy se presupone que va a haber. Es el más psicológico de todos. Es el primer zarpazo. Pep nunca ha sido un tipo tranquilo (creo que ha sido el jugador del BarÇa que más rojas ha visto en toda la historia), hasta ahora eso tampoco se ha notado apenas, durante los dos últimos años todo ha ido de perlas, pero ahora se juega toda la temporada contra el Madrid y yo últimamente lo veo desquiciado, con lo listo y provocador que es Mourinho… mala mezcla, esa puerta hay que mantenerla cerrada Pep. El BarÇa se alimentó de las provocaciones de Mourinho y Cristiano para el 5-0 de la primera vuelta, me temo que esa puerta Mourinho ya la ha cerrado también, en Bilbao ya no compadeció en rueda de prensa y veremos a ver lo que hace esta semana. ¿Qué va a pasar? Yo me mojo y digo que el partido de liga lo gana el Madrid y la copa la gana el BarÇa (muy a mi pesar), pero bueno, si acierto, os prometo que si finalmente se cruzan en semifinales de Champions, volveré a hacer un pronóstico y si no, pues también, con un par Sonrisa. Mientras tanto, disfrutemos todos de una borrachera de goles, espero que la haya y que sea una fiesta de fútbol para todos, una fiesta bien llevada y que todos sepamos aprovecharnos de un acontecimiento sin precedentes para disfrutar como niños.

22 febrero 2011

Usando Threads en C#.NET: BackgroundWorker

Filed under: C# — elburgues @ 1:21 AM

Desarrollando aplicaciones muchas veces habremos tenido la necesidad de realizar una operación que potencialmente puede llevar unos cuantos segundos, incluso minutos. El problema que presenta esta situación es que si realizamos dicha operación en el hilo principal de nuestra aplicación, aunque sea por unos pocos segundos, la interfaz de nuestra aplicación deja de responder a nuestros movimientos con el ratón y/o el teclado, dando la sensación de que la aplicación se ha quedado bloqueada (aunque realmente no sea así), provocando incertidumbre e insatisfacción en el usuario. Lo deseable en estos casos sería realizar dicha tarea en un segundo hilo de trabajo e ir obteniendo información acerca del estado de la operación en la interfaz gráfica del programa. Sería deseable también tener la posibilidad de cancelar la tarea en cualquier momento, así como también tener la posibilidad de seguir interactuando con nuestra aplicación hasta que la operación en un segundo plano termine y nos ofrezca los resultados. (more…)

21 febrero 2011

Inyección de dependencias

Filed under: C#,CAB,SCSF — elburgues @ 8:04 PM

La inyección de dependencias es cuando una clase principal hace uso de una clase secundaria sin hacer referencia directa a ella. Alguna entidad externa proveerá la clase secundaria a la clase principal en tiempo de ejecución, inyectará la dependencia. Para ser útil, la clase secundaria deberá implementar una interfaz que la clase principal conocerá. El objetivo de esto es permitir cambiar el comportamiento de nuestra estructura de clases, cambiar que clase secundaria es inyectada a la clase principal. Como la clase principal no tiene una dependencia directa con ninguna clase secundaria, esto puede ser decidido en tiempo de ejecución. Esta es precisamente la diferencia entre la inyección de dependencias y el patrón strategy. De esta manera, el código se vuelve flexible, desacoplado y fácil de modificar. (more…)

14 febrero 2011

Inversión de Control (IoC)

Filed under: C#,CAB,SCSF — elburgues @ 8:20 PM

Normalmente, para reutilizar código fuente de alguien, se debe llamar a una librería. Es lo que estamos haciendo cuando usamos .NET framework. Por ejemplo, cuando llamas a Console.WriteLine(“bla bla…”), estás usando código fuente que ha escrito alguien, tu haces la llamada, por lo tanto, tu tienes el control. Sin embargo, hay veces que es .Net framework el que reutiliza código fuente escrito por ti. Por ejemplo, cuando escribes un algoritmo de ordenación de números enteros usando la interfaz IComparable. En ese caso la dirección del control está invertida, alguien está llamando a tu código en vez de ser tu el que llama al código de alguien. Eso es la inversión de control (IoC). (more…)

14 septiembre 2010

Programación orientada a componentes: Fundamentos I

Filed under: Uncategorized — elburgues @ 6:54 AM

Antes de seguir hablando de los principios de la programación orientada a componentes, es necesario aclarar ciertos conceptos.

El Common Language Runtime (CLR)

El CLR provee un contexto común dentro del cual todos los componentes .NET se ejecutan, independientemente del lenguaje con el que han sido escritos. El CLR maneja cualquier aspecto del código en tiempo de ejecución, (gestión de la memoria, entorno seguro de ejecución, acceso a los servicios del sistema operativo subyacente…). O sea, que lo que hace el CLR es gestionar la ejecución de las aplicaciones diseñadas para la plataforma .NET. Por eso, al código de estas aplicaciones se le suele llamar código gestionado o manejado y al código no escrito para ser ejecutado directamente en la plataforma .NET se le suele llamar código no gestionado o no manejado.

Microsoft Intermediate Languaje (MSIL)

Compilar código manejado es un proceso que comprende dos fases_

  1. Todos los compiladores que generan código para la plataforma .NET no generan código máquina para CPUs x86 ni para ningún otro tipo de CPU concreta, sino que generan código escrito en el lenguaje intermedio conocido como Microsoft Intermediate Language (MSIL). MSIL es el único código que es capaz de interpretar el CLR, y por tanto cuando se dice que un compilador genera código para la plataforma .NET lo que se está diciendo es que genera MSIL definido por Microsoft.
  2. Ya que las CPUs no pueden ejecutar directamente MSIL, antes de ejecutarlo habrá que convertirlo al código nativo de la CPU sobre la que se vaya a ejecutar. De esto se encarga un componente del CLR conocido como compilador JIT (Just-In-Time) o jitter que va convirtiendo dinámicamente el código MSIL a ejecutar en código nativo. La actuación de un jitter durante la ejecución de una aplicación gestionada puede dar la sensación de hacer que ésta se ejecute más lentamente debido a que ha de invertirse tiempo en las compilaciones dinámicas. Esto es cierto, pero en .NET, cada código no es interpretado cada vez que se ejecuta sino que sólo es compilado la primera vez que se llama al método al que pertenece. El hecho de que la compilación se realice dinámicamente permite que el jitter tenga acceso a mucha información sobre la máquina en que se ejecutará la aplicación, con lo que puede optimizar el código para ella generado.

Metadatos

Cuando un cliente usa un servidor ¿Cómo sabe que tipos contiene, el espacio de nombres en el que está contenido cada tipo, el nombre de cada tipo, su visibilidad, su clase base, que interfaces soporta, sus métodos, el prototipo de cada método y cosas así? La solución que .NET da a este problema se llama metadatos. Los metadatos son un conjunto de datos organizados de forma estándar en tablas, generados por el compilador de alto nivel directamente desde los archivos fuente e incrustándolos en el archivo físico que contiene el MSIL.

El significado de los metadatos es similar al de otras tecnologías previas a la plataforma .NET como lo son los ficheros IDL (interface definition languaje). Sin embargo, los metadatos tienen ventajas:

  • Contienen más información.
  • Siempre se almacenan incrustados en el módulo al que describen, haciendo imposible la separación entre ambos.
  • Es posible consultar los metadatos de cualquier módulo a través de las clases del espacio de nombres System.Reflection. Por ejemplo, IntelliSense usa Reflection.

En otra entrada ya haremos un resumen de lo que son los ensamblados y los archivos manifiestos y con eso ya tendremos los fundamentos para seguir hablando de los principios de la programación orientada a componentes.

12 septiembre 2010

Separar la implementación de la interfaz

Filed under: C# — elburgues @ 8:30 AM

Comprando un ratón usb, da igual la marca, uno espera poder conectarlo en cualquier ordenador, ya que ambos se comunican a través de una interfaz bien definida (USB). Otra cosa son los detalles de implementación física del ratón. Se trata de lograr algo así en desarrollo de software, a través de las interfaces. Una interfaz provee la definición abstracta de un servicio entre clientes y servidores. Cada servidor es libre de proveer su propia interpretación de esa interfaz. La interfaz es implementada por un componente binario de caja negra que encapsula completamente su interior. Este principio es el de la separación de interfaz e implementación y contrasta con la orientación a objetos, en la que el objeto en sí es el centro de atención.

En la programación orientada a componentes, la unidad fundamental de reutilización es la interfaz, para usar un componente, el cliente lo único que necesita conocer es la definición de la interfaz y ser capaz de tener acceso al componente binario que implementa esa interfaz. Veamos un ejemplo:

ClassDiagram

Todo lo que el cliente tiene que hacer es instanciar una clase que soporte la interfaz y asignar el objeto a una variable de la interfaz:

IMiInterfaz objeto;  
objeto = new MiClase();   
objeto.Metodo1();

Si cambia la implementación en MiClase, el cliente no tiene porqué enterarse. Además, en el ejemplo, esto también es posible:

IMiInterfaz objeto;
objeto = new MiOtraClase();
objeto.Metodo1();

De esta manera tenemos acceso a la interpretación que MiOtraClase de para la interfaz. En el ejemplo, IMiInterfaz sería como la interfaz USB, en dónde cada ratón (MiClase, MiOtraClase), cumplen con ella (la implementan), pudiendo tener cada objeto ratón sus peculiaridades de diseño (color, tamaño etc, eso ya depende de cómo definas cada una de las clases). Sin embargo, .NET también te deja hacer esto:

MiClase objeto;
objeto = new MiClase();
objeto.Metodo1();

en donde se está accediendo directamente a la clase que provee el servicio, en vez de hacerlo a través de la interfaz. O sea, que .NET no te obliga a cumplir con este principio a la hora de programar, siendo así accesible también a todos aquellos programadores que no están acostumbrados a usar los conceptos abstractos de la programación orientada a interfaces, pero que sepáis que los desarrolladores .NET disciplinados siempre deberían forzar la separación en sus desarrollos para obtener los beneficios de la programación orientada a componentes.

11 septiembre 2010

Programación orientada a componentes

Filed under: Uncategorized — elburgues @ 9:22 AM

El término componente quizás sea uno de los más confusos en programación. Un componente es el responsable de exponer lógica hacia los clientes, siendo los clientes cualquier cosa que use al componente. Un componente puede ser una clase, siendo el cliente otra clase. Entonces, ¿en qué se diferencia la programación orientada a componentes de la programación orientada a objetos? Pues ahí reside la confusión que suele envolver al término componente, en saber dónde trazar las líneas que separan:

  • La clase que implementa cierta lógica.
  • La entidad física que contiene a la clase (dll).
  • La lógica asociada para hacer uso de la clase (información de tipos, política de seguridad, información de versiones…).

Digamos que la programación orientada a objetos se focaliza en las relaciones que hay entre las clases combinadas dentro de un gran ejecutable binario, mientras que la programación orientada a componentes se centra en módulos intercambiables que trabajan de forma independiente y de los cuales no es necesario saber nada acerca de sus implementación interna. La diferencia entre ambas técnicas es la manera que tienen ellas de ver a la aplicación final. En la programación orientada a objetos, el resultado es un código binario monolítico, todas las clases se localizan en él, mientras que la programación orientada a componentes se puede imaginar como las piezas del lego, un cambio en la implementación de una de las piezas está disponible inmediatamente para todo cliente que la use, sin necesidad de recompilar.

En la programación orientada a objetos, las aplicaciones son modeladas con jerarquías de clases complicadas, pero esa es una forma pobre de alcanzar la reutilización de código. Para derivar de una clase base y extenderla, tienes que estar muy familiarizado con los detalles de implementación de la clase base, para estar seguro de cómo va a afectar a los clientes los cambios que tú hagas. Es lo que se conoce con el nombre de reutilización de caja blanca. La programación orientada a componentes, lo que predica es la llamada reutilización de caja negra, es decir, permite usar un componente existente sin necesidad de conocer los detalles internos de su implementación. Esto se logra a través de las interfaces. En vez de diseñar complejas jerarquías de clases, se diseñan interfaces usadas como contratos entre componentes, clientes y servidores. O sea, que hay que tender ha diseñar jerarquías de clases simples y centrarse en la programación orientada a interfaces.

Una aplicación orientada a componentes es más fácil de extender (cumplir con nuevos requisitos a través de nuevos componentes sin tocar los ya existentes), reduce los costes de mantenimiento de las aplicaciones y normalmente sus desarrollos suelen ser más cortos en términos de tiempo.

Los principios más importantes de la programación orientada a componentes son:

  1. La separación de la interfaz de la implementación.
  2. La compatibilidad binaria.
  3. La independencia del lenguaje.
  4. La transparencia en la localización.
  5. La gestión de la concurrencia.
  6. El control de versiones.
  7. La seguridad basada en componentes.

.NET te habilita para cumplir con cada uno de estos principios, pero no obliga. En próximas entradas iré explicando cosas de cada uno de ellos.

5 julio 2010

La nueva Alemania

Filed under: Uncategorized — elburgues @ 7:57 PM

Bueno, ya nos hemos plantado en semifinales del mundial, algo que se dice por ahí que nunca hemos logrado, aunque creo que se logró hace más o menos 60 años. El caso es que nos tenemos que enfrentar a la llamada “nueva Alemania”. No voy a hablar de que Müller no juega por tarjetas o de que Özil recuerda a Guti en su forma de jugar. Llegados a este punto, todos nos hemos preocupado en estar al día de nuestro rival del próximo miércoles, así que no voy a comentar mucho lo que todo el mundo ya sabe, sino que voy a hablar de varios aspectos que a mi me parecen importantes y que pueden pasar desapercibidos. (more…)

22 junio 2010

¡PERROS AULLANDO!

Filed under: Uncategorized — elburgues @ 8:40 PM

Bueno, ya estoy otra vez aquí para aventurarme a decir lo que opino acerca de la selección española antes de que se enfrente a Chile el próximo viernes 25 de junio en ese partido tan decisivo. Me gusta hablar antes de, no después, después lo hace cualquiera, después nadie se equivoca, hay que decir lo que uno opina antes de que sucedan las cosas, aunque se cometan equivocaciones.

(more…)

3 junio 2010

¡Una de champiñones!

Filed under: Uncategorized — elburgues @ 12:16 AM

Bueno, me está diciendo algún amigo que se acerca el mundial y que publique alguna entrada hablando de fútbol. No sé quien se han creído que soy, me han debido tomar por un entrenador, pero bueno, digo lo que pienso, cómo veo yo las cosas y ya está. La mayoría de los datos que expongo en esta entrada han sido escritos de memoria, así que es posible que leas cosas que no son así, en cualquier caso, pido perdón por adelantado, igualmente, la idea que quiero transmitir, creo que queda reflejada. Otra aclaración. Yo soy del Real Madrid y siempre lo seré, pero vaya por delante que reconozco que el Barça es el equipo que mejor juega al fútbol, aunque me pese. (more…)

Página siguiente »

Blog de WordPress.com.

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.