Hoy vamos a hablar de uno de ellos.

El modificador de acceso internal.

El modificador de acceso internal, es aquel que nos va a permitir acceder a la clase, miembro, método etc. desde el propio ensamblado.

Que quiere decir esto, pues implica que dentro de un mismo ensamblado vamos a poder acceder a una clase internal como si de una clase pública se tratara, pero fuera de este ensamblado esta clase no va a ser accesible ya que no la estamos exponiendo.

Trabajar con clases internal, considero que es una buena práctica, ya que en los distintos assemblies que vamos generando, únicamente vamos a exponer lo que consideramos fundamental, de manera que el susodicho assembly, queda mucho más encapsulado. Además si el software que estamos desarrollando va a ser distribuido para que lo usen terceros, todavía tenemos más razones para usar este tipo de modificador de acceso.

Los métodos internal y las pruebas unitarias (unit test) o como acceder a aquello que no expones.

Hasta aquí, me encanta el modificador de acceso internal, pero ¿qué ocurre cuando tenemos que crear las pruebas unitarias para métodos internal?

Pues muy sencillo, que como no estamos exponiendo muchas clases y métodos, resulta que no lo podemos probar.

Jajajajaja, bueno, esto no es así exactamente aunque sí que es verdad que es una de las primeras cositas que encuentras (si tu desarrollo es TDD compliance claro).

La realidad es que no estamos exponiendo muchas clases por lo tanto no deberíamos poder probarlas, pero el Framework de ASP.NET precisamente cuenta “un mecanismo” para realizar esto.

El atributo InternalsVisibleTo.

Pues si amigos míos, el Framework de ASP.NET cuenta con atributo llamado InternalsVisibleTo que nos va a permitir acceder a clases internal desde assemblies externos.

El código necesario sería el siguiente:
[assembly: InternalsVisibleTo("MiAssemblyName.Test")]

Y esto, tenemos que colocarlo en el AssemblyInfo de nuestro proyecto.

Nada más por hoy mis druguitos. Aquí se acaba esta sesión de ultraviolencia. Os dejo con The XX, que además de ser unos chavales que hacen una música que me recuerda a los títulos de crédito de documentos tv, son geniales.

No acostumbro a escribir post en los que únicamente linke a otro para que se visite, pero este en concreto me ha parecido tan interesante, que la verdad no me he podido resistir.

Si estás gestionando equipos, léelo, ya que es totalmente necesario.

Mientras leía esta mañana mis RSS, estaba escuchando a Portishead. Los más grandes del Trip Hop, que son capaces de crear canciones tan Joy Division como esta.

Esto no es algo nuevo, al contrario, y la verdad es que está bastante trillado, pero siempre es bueno recordarlo ya que lo considero una de las mejores prácticas para el desarrollo de software.

Las pruebas unitarias son, más que útiles, fundamentales ya que nos permiten trabajar de una forma desacoplada y nos ayudan a estructurar y encapsular nuestro código. Pero una vez que las tenemos en verde, ¿Cómo podemos saber qué es lo que se está probando y si están bien hechas?

Aquí es donde entra el Code Coverage.

El code coverage como medida de calidad de nuestras pruebas unitarias, por lo tanto de nuestro software.

El Code Coverage, es una medida que nos va a permitir conocer el porcentaje de ejecución de nuestro código, tras haber ejecutado una batería de pruebas.

De esta medida, podemos sacar varias conclusiones:

1. Podemos necesitar más pruebas unitarias.
2. Hay código que hemos creado, que nunca se va a ejecutar, por lo tanto no es necesario y sobra.

El Code Coverage, no es necesario que este al 100%, ya que para conseguir esto, quizás tengamos que realizar pruebas unitarias que realmente no sean tales o no sean muy útiles (por ejemplo que estemos probando el Framework en lugar nuestro código), pero sí que es verdad que cuanto más cercano sea al 100% mejor.

La buena práctica, es trabajar con pruebas unitarias, y usar el code coverage como métrica de la calidad de nuestro software y eficacia de nuestro equipo, ya que lo interesante es ver como el code coverage va creciendo (o por lo menos va manteniéndose) iteración tras iteración en el ciclo de vida del desarrollo el software.

Y para finalizar, deciros, que hay varias herramientas por ahí, aunque yo la verdad, solo he usado la que viene con Visual Studio 2008.

Para activar el Code Coverage, únicamente tenéis que ir a:

Test -> Edit Test Run Configuration -> Local Test Run

Y en el dialogo que aparece, vamos a la pestaña de Code Coverage y elegimos los proyectos a los que se lo queremos aplicar.

Aqui teneis una captura del Code Coverage de uno de los proyectos que hemos acabado recientemente, aunque no se vea el porcentaje total (por no desvelar el proyecto que es), ha sido un 91%.

Code Coverage en el ultimo proyecto en el que he estado

Nada más por hoy mis druguitos. Os dejo que tengo que estudiar, pero no os quedais solos, aqui teneis a The Pains of Being Pure At Heart que son geniales y me ponen mogollon.

Hay que tener en cuenta, que estos métodos aunque son muy útiles, en ningún caso pueden sustituir a la herencia de clases.

Para crear un método extensor, necesitamos un código tal como el siguiente:

public static string ToMD5(this string str)
{
MD5 md5 = MD5CryptoServiceProvider.Create();
ASCIIEncoding encoding = new ASCIIEncoding();
byte[] stream = null;
StringBuilder sb = new StringBuilder();
stream = md5.ComputeHash(encoding.GetBytes(str));
for (int i = 0; i < stream.Length; i++) sb.AppendFormat("{0:x2}", stream[i]);
return sb.ToString();
}

Como veis, el metodo extensor, ha de ser estático y ademas, va a recibir siempre como parametro el objeto que lo llama, a este objeto tenemos que añadirle el parametro this.

Así de facil y sencillo. Este tipo de metodos, los había usado con JavaScript y ActionScript, y ahora, mis drugitos, los podemos usar con C#, toda una maravilla.

Bajate el código y échale un ojo, y cuando uses este tipo de metodos, cuidado, ten en cuenta que no estan pensandos para sustituir la funcionalidad que nos proporciona la herencia, y como bien dicen aquí, es interesante agruparlos en un mismo namespace (que en una única clase).

Nunca han sido santos de mi devoción los planetas, aunque desde hace unos días, no paro de escuchar su “corrientes circulares en el tiempo”, canción mucho más madura que la mayoría de sus exitos.

Como ya hemos visto en otros post, me encuentro (el 20% de mi jornada laboral) en un proceso de aprendizaje de Silverlight. Tras leer algunos libros sobre el tema, comencé a desarrollar BookLight (;-) codename de una app que gestiona la biblioteca de la empresa) y gracias a esta app, me estoy encontrando con cosas interesantes y otras no tan interesantes.

Una de esas cosas, son los estilos.

Silverlight, nos permite generar una “suite” de estilos que posteriormente podemos ir asignando a los distintos controles de manera que en el momento que modificamos estos estilos, actualiza el aspecto de todos los controles que los “consumen”.

Estos estilos no son exactamente iguales a los (geniales) cas, aunque algo tienen en común. Definen el aspecto del control y en Silverlight (y dpb) pueden definir parte del comportamiento del control, tal como animaciones.

Cuando trabajamos con Blend y nos disponemos a crear estos estilos, nos da la posibilidad de crear el estilo de forma “global” (guardándolo en el app.xaml) o de forma “local” añadiéndolo al propio documento. Estos estilos pueden heredar de otros, y además es sumamente sencillo hacer esto, solo que en Blend no es muy aparente (si os digo la verdad yo no he encontrado la forma, lo cual puede ser normal por otra parte).

Para heredar unos estilos de otros vamos a usar el atributo BasedOn por medio del cual indicaremos cual es el estilo padre. Podeís ver su uso aquí:

<Style x:Name="BaseText" TargetType="TextBlock">
<Setter Property="FontFamily" Value="./../Fonts/Fonts.zip#Arial" />
<Setter Property="TextWrapping" Value="Wrap" />
<Setter Property="FontWeight" Value="normal" />
</Style>
<Style x:Name="BookLight.BookingBook.Title" TargetType="TextBlock" BasedOn="{StaticResource BaseText}" >
<Setter Property="FontSize" Value="28" />
<Setter Property="Margin" Value="10, 10, 10, 10" />
</Style>
<Style x:Name="BookLight.BookingBook.Title.Success" TargetType="TextBlock" BasedOn="{StaticResource BookLight.BookingBook.Title}" >
<Setter Property="Foreground" Value="#FF66CC00" />
</Style>
<Style x:Name="BookLight.BookingBook.Title.Error" TargetType="TextBlock" BasedOn="{StaticResource BookLight.BookingBook.Title}" >
<Setter Property="Foreground" Value="#FFFF6600" />
</Style>

Y esto es todo. Se despide vuestro amable y querido narrador no sin antes hablaros de The Phenomenal Handclap Band formada por gente de The Jon Spencer Blues Explosion y Mooney Suzuki.

Una de las cosas que me ha sorprendido a la hora de desarrollar con Visual Studio – Blend, es la dualidad que aparece ahora, y de la cual nos podemos beneficiar a la hora de crear las interfaces de usuario que consideremos pertinente. Que exista esta dualidad y podemos trabajamos con el xaml desde diferentes entornos es beneficioso, ya que así cada uno puede decidir cuál es el entorno que más le satisface para crear unas tareas x, por lo tanto, trabajamos más a gusto y a la larga es mejor.

Eso sí, al existir esta dualidad de “ides”, nos vamos a encontrar con casos un poquito peculiares, por ejemplo, el que hoy nos trae aquí.

Para aprender una nueva tecnología, no hay nada como verse inmerso en un proyecto, donde tengas unos tiempos que cumplir, una funcionalidad que realizar con una calidad x, tengas que trabajar con distintas tecnologías simultáneamente, implementar n patrones  etc. Así pues, revise las aplicaciones que tenemos (en la compañía donde trabajo), y decidí que una aplicación interesante para realizar con silverlight, sería la biblioteca (app que gestiona la adquisición y préstamo de libros teckies), ya que hay que acceder a una db para coger la información, tratar esta información etc. y además le daba una vuelta a una app que hacía años nadie tocaba.

Tras decidir que el codename de la aplicación sería Booklight, comencé a diseñar la interfaz. Tras hacer un diseño (grafico y de interacción) con Fireworks (no lo hice con Blend porque no hay que olvidarse de que el propósito de este desarrollo era aprender) y pensar en cómo podía orientar la arquitectura de esta aplicación, abrí Blend y comencé a plasmar el diseño realizado con Fireworks en Expression Blend. Realice la interfaz y empecé a codificar el asunto, llamadas a servicios wcf, acceso a base de datos, implementación model view viewmodel (del que hablaremos en su momento) y llego un momento que al abrir mi Expression Blend, me encontraba con un error que decía algo así como:

Argument Null Exception: Value cannot be null.
Parameter name:stream

Argument null exception. Value cannot be null.

Me resulto muy curioso, ya que yo podía hacer un rebuild en Visual Studio y todo estaba ok, pero en Blend seguía el error.

Tras buscar un tiempo en google, descubrí que en tiempo de diseño, se pueden producir excepciones.

En mi caso, en el constructor de una clase, estaba haciendo una llamada asíncrona a un servicio, y como es natural, Blend, no podía ejecutar la llamada.

Para solucionarlo, tan sencillo como comprobar si nuestro cliente rico, está hospedado en un navegador.

El código necesario para esto, el siguiente:

HtmlPage.IsEnabled

Con esta pequeña funcionalidad, evitaremos este tipo de errores y algún que otro quebradero de cabeza, y cuando abramos nuestro Blend, lo que veremos sera lo que hay que ver, en mi caso, aqui teneís:

interfaz en la que hay que trabajar

Ahora quizá deberíamos debatir sobre si Expression Blend tiene que mostrar excepciones o no, pero creo que será en otro momento, aunque os adelante que a mi parecer, Blend debería dedicarse únicamente a ayudarnos a plasmar toda nuestra creatividad en un medio digital. En Flash (durante 2 años desarrolle con Action Script), esto está mejor resuelto, aunque también es verdad que el tratamiento de excepciones de flash (yo me quede en Flash 2.0, cuando comenzaron a orientarlo a objetos) era un poquito pobre.

Nada más amigos, es Agosto y debería estar de vacaciones y la verdad no se qué hago aquí. De momento, vamos con los más grandes del 2 tone.

Anteriormente hemos visto como usando ficheros de settings, podemos organizar nuestro web.config de una forma muy eficiente y sencilla, ahora vamos a ver algo un poquito más avanzado, pero igual de fácil.

.Net, a través de su Framework (desde la versión 2.0), nos facilita una serie de clases que nos permiten personalizar los ficheros de configuración en función de nuestras necesidades, permitiéndonos crear nuestras propias secciones dentro de la configuración de manera que el web.config o app.config nos va a quedar mucho más organizado y consolidado.

Así pues si estas cansado de almacenar la configuración de tu aplicación como una lista interminable de entradas en el nodo appSettings y quieres organizarlo un poquito, continua leyendo y vamos al asunto.

Creando la clase que encapsula el acceso a nuestra sección personalizada dentro de la configuración.

Lo primero que vamos a hacer es crear la clase que nos va a permitir encapsular el acceso a nuestra sección personalizada. Esta clase debe heredar de la clase ConfigurationSection del Framework y posteriormente vamos a ir creando una propiedad por cada ítem que se vaya a almacenar en la configuración.

La clase puede ser algo así:

public class BlogSettings : ConfigurationSection
{
}

Ahora nos toca crear las propiedades que nos encapsulen el acceso, vamos a ello:

[ConfigurationProperty(TITLE_PROPERTY_NAME, DefaultValue="A deshoras", IsRequired=true)]
public string Title
{
get
{
return (string)this[TITLE_PROPERTY_NAME];
}
}

Como veis, estas propiedades están marcadas como ConfigurationProperty, y además, le indicamos el nombre de la propiedad dentro de la configuración, el valor por defecto y si es requerida o no.

Creando un Manager que gestione nuestra clase de configuración.

Como queremos que esto quede de maravilla, vamos a crear un manager, este se tiene que encargar de automatizar el acceso a la sección de configuración personalizada (custom configuration section) y la modificación si es preciso.

Para realizar estas funciones, vamos a crear una clase estática, que como miembro, tendrá una instancia de la clase que anteriormente hemos creado.

El manager, será algo así:

public static class BlogSettingsManager
{
#region constants
private static string BLOG_SETTINGS_NODE_NAME = "BlogSettings";
#endregion
#region members
private static BlogSettings _settings = ConfigurationManager.GetSection(BLOG_SETTINGS_NODE_NAME) as BlogSettings;
#endregion
#region Properties
public static BlogSettings Settings
{
get { return _settings; }
}
#endregion
}

Creando nuestra sección personalizada (custom configuration section) dentro del web.config o app.config.

Y ya solo nos queda añadir nuestra sección personaliza al web.config o app.config. Para ello, tenemos que añadir un nodo section hijo del nodo configSections, y en este nodo, tenemos que indicar el nombre de nuestra sección, y el tipo, que no viene a ser otra cosa que el nombre de la clase con el namespace y el nombre de la dll donde tengamos la clase que va a gestionar esta configuración (en nuestro caso BlogSettings).

El código sería el siguiente:

<configuration>
<configSections>
<section name="BlogSettings" type="CustomConfigurationSection.Framework.BlogSettings, CustomConfigurationSection.Framework"/>
</configSections>
<BlogSettings Title="Adeshoras" NumberOfItemsPerPage="20" />
</configuration>

Ahora solo nos queda usarlo a lo largo de nuestra app, y esto amigos míos, es lo más sencillo de todo, sería un código del estilo al siguiente:

BlogSettingsManager.Settings.Title

Como siempre, te recomiendo que te bajes este código y lo veas en vivo y en directo, seguro que te maravilla.

Nada más, como podéis ver mis druguitos, de una forma muy sencilla podemos encapsular el acceso a nuestra configuración y además personalizar los ficheros donde almacenamos la susodicha configuración (en nuestro caso web.config o app.config). Esto es muy simple y elegante y con una funcionalidad de este tipo, los deployments serán más sencillos ya que tendremos mucho más organizados nuestros ficheros de configuración.

Mientras he escrito este post, he estado escuchando a los Misfits y ahora es vuestro turno.

Hay varias formas de sobrescribir esta herencia o de configurar nuestro web.config para que nuestra aplicación trabaje de una forma u otra, y hoy vamos a ver otro mecanismo.

Este mecanismo, no viene a ser otro que el elemento clear de las appSettings.

El elemento clear, quita todas las referencias de los appSettings de nuestra aplicación, y solo nos permite trabajar con la configuración agregada por el elemento add.

Usarlo es muy fácil:

<appSettings>
<clear />
<add key=”NumberOfItems” value=”20” />
</appSettings>

Útil y fácil como tienen que ser las cosas, ahora amigos, os dejo. Pero os dejo acompañados del fabuloso Bobby Womack y su genial Across 110th Street, inmortalizada por el no menos fabuloso y genial Tarantino en los títulos de crédito de Jackie Brown.

El nodo appSettings, es muy útil ya que nos permite modificar valores que afectan al comportamiento de nuestra aplicación de una forma rápida y efectiva (y sin ser necesario compilar), pero estas como todo, hay que mantenerlas y sobre todo organizarlas.

Con asp.net 2.0, se introdujeron unos nuevos ficheros que nos permitían manejar la configuración de nuestra aplicación de una forma mucho más ordenada y efectiva.

Estos ficheros, eran los ficheros de settings, por medio de ellos, vamos a poder almacenar app settings y acceder a ellas de una forma enumerada. Además cuando creamos un fichero de settings, se genera una clase que nos va a serializar y deserializar de una forma automática y optima el acceso a nuestras settings.

Para crear un fichero de settings, puedes hacerlo de dos formas:

• Btn derecho en nuestro proyecto -> Add ítem -> settings file  (en class libraries)
• Btn derecho en nuestro proyecto -> properties -> settings (en proyectos web)

Una vez que tenemos el archivo creado, ya solo nos queda añadir nuestras settings, el tipo de dato que va a almacenar, el scope (user o application) y por último el valor que almacenan.

Estas settings, al igual que las appSettings, se almacenan en nuestro web.config o app.config, de esta forma, también las podemos modificar sin tener que volver a compilar nuestro proyecto.

Veamos un ejemplo, supongamos que trabajamos con las appSettings, yo defino n appSettings en mi proyecto, y para usarlas debería hacer algo por el estilo a esto:
private const string NUMBER_OF_ITEMS = "NumberOfItems";
public int NumberOfItems
{
get{ return Convert.ToInt32(WebConfigurationManager.AppSettings[NUMBER_OF_ITEMS]); }
}

Si utilizamos un archivo de settings, únicamente tendríamos que hacer lo siguiente:

Settings.DisplaySettings.Default.NumberOfITems;

Siendo Settings el namespace y UrlSettings, la clase que se va a generar para poder encapsular el acceso a la susodichas settings.
Si esto ya os ha gustado (que seguro que sí), lo mejor viene ahora, si trabajamos con nuestro nodo de appSettings, las settings las tenemos que definir más o menos de la siguiente forma:

<appSettings>
<add key="NumberOfItems" value="20"/>
<add key="DefaultOrderValue" value="DefaultOrderValue"/>
</appSettings>

Mientras que si trabajamos con este tipo de ficheros y aunque igualmente se almacenan en el web.config, se almacenan de la siguiente forma:

<configSections>
<sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
<section name="TestSettings.Settings.AppGlobalSettings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
</sectionGroup>
</configSections>
<applicationSettings>
<TestSettings.Settings.AppGlobalSettings>
<setting name="DefaultOrderValue" serializeAs="String">
<value>date</value>
</setting>
</TestSettings.Settings.AppGlobalSettings>
</applicationSettings>

Como podéis ver mucho más ordenado y eficiente.

Como apunte deciros que la buena práctica recomienda el incluir estas settings y nodos en nuestro web.config o app.config principal, pero si no lo hacéis, esta clase que se autogenera al no encontrar el valor buscado, usa el valor que se le dio cuando se precompiló. Que esto sea una ventaja o inconveniente lo tiene que decidir cada uno, el hecho es que el asunto funciona así.

Recientemente, hemos realizado una aplicación iPhone (disponible gratis en appstore) para Nomaders.com. Esta app explota las API’s de varias redes sociales (11870.com, Restaurantes.com, NVivo y MiNube).

Cada una de las piezas que encapsula el acceso a esas API’s, las ha desarrollado vuestro querido y humilde narrador y para el tema de las configuraciones he usado este tipo de archivos y os aseguro que se trabaja de una forma muy sencilla y además a la hora del deployment, todo queda mucho más ordenado siendo así más fácil de mantener y administrar.

Os dejo chavales, que he quedado para enseñarles a mis colegas mi carro nuevo así que nada más, mientras he escrito este post, he estado escuchando a Sidonie, porque me recuerdan a ti y pq aunque hayan pasado ya casi dos años, cada día me tienes más fascinado.

Así, pues, de forma muy sencilla, podemos “desactivar” la herencia de web.config (o directamente no heredar) consiguiendo de esta forma que cada aplicación, este siendo hospedada por medio de un Web Site o un Virtual Directory, tenga su propia configuración completa.

El tag del web.config location, nos va a permitir deshabilitar esta herencia por medio del atributo inheritInChildApplications.

Para usarlo, tendríamos que poner dentro los nodos del web.config a los que vamos a hacerles el wrapper.

<location path="." inheritInChildApplications="false">
<connectionStrings>
...
</connectionStrings>
<system.web>
...
</system.web>
</location>

Mientras he escrito este post, he estado escuchando a los undertones, así que tu que todavía sigues siendo joven y guapo, dale al play y disfruta de su genial teenage kicks, yo, me subo a zgz que esta tarde tengo que recoger mi cohe nuevo!!!!