Cookies duplicadas o que no se borran

Artículo para: Programadores de C# de cualquier nivel


Hoy me he encontrado con una de esas "marcianadas" que me encantan, de esas que te hacen perder media mañana y darte cabezazos contra la pared... Vamos, de las que a diario tenemos que soportar los programadores.

Resulta que las "cookies", esas "galletitas" que se utilizan en el 99% o quizá en el 100% de las páginas web actuales (bien, bien, puede que estos datos me los haya sacado de la manga, pero se usan muchísimo) son un dolorcito de huevos. Y no es porque en sí entrañen una dificultad especial, no. Es por un purete que parece haber en la enumeración Request.Cookies y Response.Cookies.

¿Cómo detectar que estamos comentiendo un error? Bien, el primer síntoma es el hecho de ver más de una cookie con el mismo nombre en las enumeraciones citadas, es decir, si analizamos el contenido de Request.Cookies o de Response.Cookies y detectamos en la propiedad AllKeys dos o más veces el mismo nombre, quiere decir que la estamos literalmente "cagando".

Busca en tu código algo como lo siguiente: this.Request.Cookies["nombreDeTuCookie"] == null o this.Response.Cookies["nombreDeTuCookie"] == null.

Y ahora te digo que ésto no funciona. ¿Y por qué? - te preguntarás. En el momento que llamas al indexador this.Response.Cookies["nombreDeTuCookie"]  y sin previo aviso te crea una nueva cookie en blanco (sin información) con el mismo nombre.

Entonces, ¿cómo puedo borrar una cookie dado que esto sucede? Te lo documento a continuación con un ejemplo práctico:

Código que falla:

if (this.Response.Cookies.[cookieName] != null)
{
      this.Response.Cookies.Remove(cookieName);
}

Código que funciona:

if (this.Response.Cookies.AllKeys.Contains(cookieName))
{
       this.Response.Cookies.Remove(cookieName);
}

Este conocimiento lo puedes aplicar a otros ámbitos de las cookies, solo ten cuidado de usar la propiedad AllKeys para chequear la existencia de la cookie y es más que suficiente.

¡Espero haber sido de ayuda!

C# y Programación

WPF Web browser no muestra mi web y otras si

Artículo para: Programadores de C# de cualquier nivel


La semana pasada me sucedió que, después de haber desistido de solucionar el problema, me encontré con una posibilidad remota de arreglarlo. Concretamente lo que me pasaba es que hice una aplicación en WPF que automatizaba un proceso en la web de mi empresa y debía mostrar en el navegador los resultados; lo cual no hacía, me mostraba una página en blanco solo en mi web (si iba a Google o a otros sitios funcionaba sin problemas).

Lo primero que hice para esquivar este problema fue utilizar Awesomium, el cual funciona muy bien pero claro: ¿qué web está creada para Chromium? Supongo que habrá quien se tome la molestia de adaptar su web a este fantástico navegador, pero no es mi caso; es por ello por lo que la web se veía de pena y el "workaround" que me había inventado no me acababa de convencer. Si bien es cierto que no soy usuario de Internet Explorer (me encanta Chrome), para las aplicaciones en WPF que requieren de un navegador mi opción es clara: el control WebBrowser. Pero claro, siempre que éste funcione.

Lo primero es resolver la pregunta del millón: ¿Por qué me muestra la página en blanco? Porque estás usando una versión antigua de Internet Explorer (posiblemente la más antigua que tenga instalado tu PC, aunque tú no tengas acceso a ella, como por ejemplo el 8 o el 9). Aunque os parezca una chorrada, a mi me ha costado mucho dar con el asunto.

Y ahora viene la solución al problema:

1. Abrimos el editor de registro de Windows pulsando las teclas "Windows" + R, nos saldrá la ventana de ejecución:
   
   
   
   
   
2. Escribimos regedit.exe y le damos los permisos de administrador que nos solicita. Si no somos administradores de nuestra máquina no podremos arreglar este problema. Ejecutamos.
3. Si tenemos una máquina normal de 64 o 32 bits buscaremos la clave HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_BROWSER_EMULATION
4. Si nuestra máquina emula 64 bits sobre una de 32 buscaremos la clave HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_BROWSER_EMULATION
5. Una vez localizada añadiremos un nuevo valor DWORD de 32 bits con el nombre completo de nuestra aplicación como clave (incluyendo el .exe al final) y como valor uno de los de la tabla que detallo a continuación.

Valor	Sirve para…
11001 (0x2EDF)	Intenet Explorer 11, incluso con la directiva ¡DOCTYPE
11000 (0x2AF8)	Intenet Explorer 11, las que tengan la directiva ¡DOCTYPE se mostrarán en modo IE9
10001 (0x2AF7)	Internet Explorer 10, incluso con la directiva ¡DOCTYPE
10000 (0x2710)	Intenet Explorer 10, las que tengan la directiva ¡DOCTYPE se mostrarán en modo IE9
9999 (0x270F)	Internet Explorer 9, incluso con la directiva ¡DOCTYPE
9000 (0x2328)	Internet Explorer 9, incluso con la directiva ¡DOCTYPE (este caso es idéntico al anterior). A los de Microsoft les ha patinado, me temo…
8888 (0x22B8)	Intenet Explorer 8, incluso con la directiva ¡DOCTYPE
8000 (0x1F40)	Internet Explorer 8, incluso con la directiva ¡DOCTYPE (este caso es idéntico al anterior). A los de Microsoft les ha patinado de nuevo, me temo otra vez…
7000 (0x1B58)	Internet Explorer 7

Una nota más, que además es muy importante. Si estamos depurando con Visual Studio tendremos que añadir la famosa extensión .vshost.exe (en lugar del .exe solo) al nombre de nuestra aplicación para que concretamente en esta nos funcione como es debido.

Con eso creo que he explicado todo. Si tenéis alguna duda, podéis comentar.

C# y Programación

Model View - View Model (MVVM) una explicación sencilla Parte I

Artículo para: Programadores de C# de cualquier nivel

Llevo algún tiempo ya en esto del WPF (unos 4 años) y veo cada vez más malos ejemplos de cómo se programa en esta maravillosa tecnología de Microsoft, que nos lleva a otro nivel en cuanto a interfaces gráficas se refiere.

En lo que a este tema se refiere, Microsoft da unas pautas MUY CLARAS de cómo operar y cómo realizar los desarrollos en esta tecnología, pero parece ser que la gente que viene de Windows Forms no desea adaptarse. Es por ello por lo que escribo este artículo, en pro de ayudar a quien quiera escucharme y siempre buscando un consenso en cuanto a desarrollo de aplicaciones de escritorio y aunque el futuro de Silverlight es muy oscuro, espero que aquellos que programéis aún en esta plataforma os sea también de ayuda.

Este artículo está dividido en 5 partes, porque el modelo MVVM no es trivial y bien requiere de un poco de tiempo para digerirlo correctamente. Si vienes de Windows Forms y estás pensando que puedes hacer lo que siempre has hecho (trabajar por eventos), estás en lo cierto, pero la estás cagando considerablemente. Si haces una aplicación WPF por eventos que tenga más de dos vistas, demuestras que no sabes del tema demasiado; tómate un tiempo para comprender y para ponerte al día, que de verdad, no cuesta nada.

El axioma para todo esto: LOS EVENTOS SON MALOS, no los uses como siempre lo has hecho. Esta tecnología no está pensada para el click de un botón o para el text_changed de un cuadro de texto, cambia tu mentalidad y empieza a pensar un poco más allá.

Y ahora el "quid" de la cuestión: ¿Cómo funciona ésto? La tecnología Windows Presentation Foundation de Microsoft tiene un "modus operandi" muy curioso, que nos permitirá explotar al máximo la capacidad de nuestras tarjetas gráficas modernas. No siendo aplicaciones de tipo videojuegos, las aplicaciones WPF pueden ser tan preciosas y tan bien diseñadas que nos sintamos como jugando con ellas; como programadores este tiene que ser nuestro objetivo final: el usuario se ha de sentir MUY cómodo usando nuestras herramientas de software.

El patrón MVVM consiste en unas buenas prácticas que yo, como experimentado programador de esta tecnología definiría de la siguiente manera (aunque como todo, es discutible):

• Separar la vista de la funcionalidad que da soporte a la misma (a esto lo llamamos View)
• Crear una capa que sea la interlocutora entre el negocio y la vista (que se llama View Model)
• Por último, hacer una capa de negocio que NO TENGA NADA QUE VER con la vista (lo has adivinado, el Model).

MVVM conceptualmente

Enlaces prohibidos: desde el Model está TERMINANTEMENTE PROHIBIDO conectar con la View.

Entonces, ¿Cómo se comunican las distintas entidades en este modelo? Es muy sencillo:

• El usuario comunica directamente SOLO con la View.
• La View comunica directamente SOLO con el View Model.
• El View Model hace de interlocutor entre la View y el Model.

Para ello, desde Visual Studio crearemos una solución en blanco y haremos lo siguiente:

• Crearemos una nueva solución en blanco en Visual Studio:

• Crearemos un nuevo proyecto de WPF, el cual será la View.

• Crearemos un nuevo proyecto de Librería de Clases, el cual será el View Model.

• Crearemos uno o más proyectos (normalmente son varios), de tipo Librería de Clases, los cuales en su conjunto crearán el Model.

Después de toda la operativa, nos debería quedar de la siguiente manera el árbol de proyectos:

¿Cómo relacionarlos?

• El proyecto View referenciará al View Model. Nunca tendrá referencias al Model.
• El proyecto View Model referenciará a uno o varios proyectos del Model. Nunca tendrá referencias al View (o tendríamos el problema de la referencia circular).
• Los proyectos del Model NUNCA referenciarán ni a la View, ni al View Model.

Con las relaciones definidas, la comunicación solo se produce en un solo sentido:

Sentido de la comunicación por referencias a proyectos

Si bien esta comunicación es muy buena, no es suficiente porque necesitamos mecanismos para poder informar al resto de componentes en el otro sentido. En un próximo artículo os explicaré los eventos personalizados y un sencillo sistema gestor de Weak Events.

Pero antes de abordar temas más complejos, en el siguiente artículo os explicaré los XAML's y los bindings, que es algo vital en todo este asunto.

Espero que os haya gustado esta pequeña introducción y también espero sinceramente vuestros comentarios, que serán bienvenidos y de los cuales se aplicarán las correcciones que considere oportunas.

C# y Programación

La importancia de NO reinventar la rueda... Reto de programación #2

Artículo para: Programadores de C# de cualquier nivel

Hace unos días me encontré con un código muy similar al que arriba podéis ver... Supongo que sería por el agotamiento del que últimamente sufro, o porque no esperaba semejante maquiavélica creación, pero el hecho es que tardé unos segundos (de hecho bastantes) en entender qué demonios hacía esto.

Tras un concienzudo análisis deduje que el objetivo final que perseguía su creador no era más que hacer que un objeto DateTime que provenía de la fecha actual traída con el utilísimo DateTime.Now se convirtiera en un string para pintarlo en pantalla.

No entro a debatir de la calidad profesional de la persona que inventó semejante monstruosidad, no me interesa quejarme de gratis máxime teniendo en cuenta que TODOS (yo el primero) la cagamos alguna vez en esta profesión; pero lo que sí quiero decir es que si navegamos 3 segundos por internet nos damos cuenta que esta no es ni de lejos la manera más óptima. 

Mis razones, aunque habrá millones más son las siguientes:

1. Cada llamada a DateTime.Now tiene un sobrecoste totalmente inútil y absurdo, además, de la primera llamada a la última aunque sea pequeña, habrá una diferencia horaria por motivos obvios (en cada llamada la foto es diferente aunque difiera en milisegundos, solo hay que conocer la propiedad Now).
2. El operador de concatenación ("+") es brutalmente lento y desaconsejable para una concatenación tan extensa, para eso existe StringBuilder (uno de los consejos del curso oficial de Microsoft que recientemente he hecho).
3. Este código no es para nada legible. Insisto, mi experiencia de más de 9 años no me ha permitido entenderlo hasta un análisis concienzudo, así que imagino un chavalejo que se encuentre por primera vez luchando con un dragón como éste. Nuestro código ha de ser lo más entendible posible.

La mejor manera es la siguiente sin duda, aunque muchos ya habréis llegado a ella hace un buen rato:

Nótese que ambas hacen EXACTAMENTE LO MISMO, pero la segunda es infinitamente más rápida que la primera. Esto significa que en una aplicación de alto rendimiento, si no tenemos en cuenta cosas tan básicas como ésta, es muy posible que los tiempos de respuesta sean penalizados terriblemente.

Por eso insisto, no reinventemos la rueda que no es necesario. El principio del programador vago, que explicaré en otro artículo posterior, tiene que ser lo que rija nuestro día a día... si hacemos "ciencia" o más bien, "brujería" como ésta lo más probable es que alguien pase con la excavadora y elimine nuestro código.

Quisiera comentarios y otras vivencias similares vuestras...

C# y Programación

La importancia de los comentarios en el código fuente

Artículo para: Programadores de C#

Comentarios

Los comentarios son vitales en nuestro trabajo diario, sobre todo porque como ya habréis observado crear código que uno mismo entiende es sencillo; leer el código de otro programador y entenderlo suele ser  un infierno. Además, el valor añadido de los comentarios XML de los que Visual Studio nos provee: se muestran en el IntelliSense y ayudan a otros programadores a entender qué hacen ciertos métodos, para qué sirven ciertas propiedades, etc…

Por favor, tenedlo muy presente antes de poneros a meter código a lo loco. En ocasiones hacemos cosas tan confusas (bien sea por falta de análisis, o porque no queda más remedio) que es totalmente necesario el comentarlo para que otro, o incluso tú mismo dentro de algún tiempo, lo pueda llegar a entender.

Para ello disponemos de los comentarios de una sola línea…   

public void CorkBreadMethod(bool entry)
{
     if (entry)
     {
          //Code if entry is true

     }
}

…útiles para dar una descripción rápida de lo que estamos haciendo.

También tenemos comentarios de múltiples líneas…

public void CorkBreadMethod(bool entry)
{
     if (entry)
     {
     /* Code if entry is true and loren ipsum when the sun goes
     * down and the moon is dark */
     }
}

… que son de gran utilidad cuando la línea es muy larga y es completamente necesario todo el texto que hemos introducido. Es muy importante tener esto en cuenta, que el texto sea realmente necesario; si no lo es estaremos empantanando el código para el próximo lector. Ver sección al respecto de longitud de línea.

Comentarios XML

Mención especial merecen los comentarios XML ya que son ellos los que permitirán al usuario comprender mejor nuestras clases y métodos. Para utilizarlos, Visual Studio nos provee de una automatización: antes de la clase, propiedad o método (en la línea previa) escribiremos tres veces la barra /// y automáticamente se crearán los encabezados necesarios para el comentario XML:

/// <summary>
/// Class in charge of beign an example
/// </summary>
class CorkBreadClass
{

}

El anterior es un ejemplo de cómo identificar a una clase por medio de un comentario XML. Después de hacerlo, desde fuera de la clase ésta se vería como sigue:

/// <summary>
/// Method inside CorkBreadClass
/// </summary>
/// <param name="entry">A boolean that represents the entry</param>
/// <returns>5 if entry is true, 0 elsewhere...</returns>
public int CorkBreadMethod(bool entry)
{
     return entry ? 5 : 0;
}

Con los anteriores comentarios XML, tendríamos el siguiente resultado:

Como podemos ver en la anterior captura, nos devuelve toda la información que previamente hemos escrito en los comentarios XML, con lo que conseguimos que una persona que no conozca nuestro código o no tenga acceso directo al fuente del mismo; pueda entender qué sucede dentro de nuestras clases.

C# y Programación