Se trata de un eCommerce de moda con una característica que lo hace único: los productos que se ofrecen en la tienda han aparecido en series o programas de televisión. Así, se puede buscar la ropa que ha aparecido en “Sé lo que hicisteis”, o la que ha vestido una presentadora de televisión o nuestro actor favorito. Por ahora El Armario tiene acuerdos comerciales con Antena 3, La Sexta y Cuatro, y con más de 50 marcas de moda.

El proyecto arrancó el pasado mes de Junio como una iniciativa de la consultora estratégica Bufete de Marketing, la empresa de estilismo TvisT y la agencia de publicidad DoubleYou. Oxxigeno fue seleccionado como proveedor tecnológico para la puesta en marcha del proyecto. Han sido unos meses de trabajo duro para llegar a las fechas previstas, pero estamos bastante satisfechos con el resultado.

Algunas de las tareas que hemos realizado en estos meses:

• En colaboración con DoubleYou, realizamos el diseño de interacción del sitio, tanto de la tienda como del backoffice.
• Diseño del proceso de compra.
• Maquetación XHTML/CSS.
• Definición de la arquitectura tecnológica.
• Desarrollo tecnológico completo de la plataforma.
• Implementación del backoffice y de los mecanismos de administración, métricas, gestión de contenidos, sincronización con socio logístico, pasarela de pagos, etc.
• Soporte técnico, monitorización del rendimiento de la plataforma.
• Mantenimiento correctivo y adaptativo.

Por ahora, la acogida de El Armario de la Tele ha sido estupenda. El proyecto aún está arrancando y le queda mucha vida por delante. En los próximos meses El Armario no dejará de crecer y mejorar, ¡estad atentos!

El método SCAMPI (Standard CMMI Appraisal Method for Process Improvement) es un proceso diseñado y desarrollado por el SEI, Software Engineering Institute, para evaluar la adherencia de los procesos implantados por una organización al modelo CMMI. Hay tres variantes de SCAMPI:

• clase C, que consiste en una prueba de enfoque de los procesos existentes en la organización
• clase B, en el que se valida el despliegue o puesta en marcha de los procesos implementados
• clase A, que debe ser realizado por un Lead Appraiser (Líder-Evaluador SCAMPI) autorizado por el SEI y que consiste en la rigurosa evaluación de la institucionalización con la posibilidad de obtener un nivel de madurez.

Los resultados del SCAMPI B realizado en Oxxigeno fueron positivos y nos dieron la confianza suficiente para afrontar la fase final del proyecto, el SCAMPI A.

Nuestros siguientes pasos fueron ponernos en contacto con la evaluadora autorizada por el SEI que lideró nuestro SCAMPI A, y comenzar a generar un plan para definir los siguientes factores:

• Equipo del SCAMPI: compuesto por 5 miembros: 2 internos de Oxxigeno, 2 externos y el líder-evaluador. La intervención de recursos internos y externos facilitó el trabajo del equipo, ya que aportó distintas visiones de los procesos generados
• Fechas: se planificaron las fechas de los distintos hitos del SCAMPI A
• Actividades: se fijaron las actividades que tendrían lugar durante cada fase para planificarlas adecuadamente
• Riesgos: se tomaron en cuenta los distintos riesgos que podrían afectar al correcto desarrollo del SCAMPI A

Todo SCAMPI A consta de dos fases:

• Revisión documental (Readiness Review): durante esta primera parte el equipo revisa las evidencias presentadas, los procesos de la organización, la aplicación de los procesos a los proyectos evaluados, la documentación generada, las herramientas utilizadas para implantar los procesos… De esta fase saldrá una primera visión del estado que permitirá minimizar riesgos
• Entrevistas (On site): en esta segunda fase tienen lugar las entrevistas a distintos roles de los proyectos seleccionados para verificar la implantación de los procesos definidos en los proyectos

Siguiendo la planificación establecida, durante los meses de mayo y junio tuvieron lugar las dos fases del SCAMPI A en Oxxigeno; los objetivos marcados fueron los siguientes:

• Comparar nuestros procesos con el modelo
• Identificar las debilidades y oportunidades de mejora de cada área para efectuar las modificaciones necesarias
• Enmarcar las debilidades detectadas dentro de la unidad organizacional para continuar mejorando la calidad de productos y procesos
• Identificar las mejores prácticas y fortalezas de cada área para aplicarlas al resto de áreas

Tras efectuar las entrevistas correspondientes, analizar los 19 objetivos y 108 prácticas a satisfacer y revisar las 512 evidencias presentadas obtuvimos los siguientes resultados por cada área de proceso:

Con todas las áreas de proceso aplicables satisfechas y tras la revisión por parte del SEI, el pasado mes se publicaron los resultados de nuestro SCAMPI que han sido positivos, por lo que el área de servicios de desarrollo de software de Oxxigeno ya es nivel 2 de CMMI!

Ahora estamos inmersos en la optimización de los procesos que hemos creado para continuar con la mejora continua que nos planteamos al comenzar la implantación del modelo CMMI.

Los objetivos que nos marcamos para afrontar el proyecto de mejora son los siguientes:

• Disminuir costes en el proceso de desarrollo
• Implantar una metodología de desarrollo común basada en el uso de herramientas
• Continuar produciendo desarrollos de alta calidad
• Aumentar la fidelidad de nuestros clientes
• Incrementar nuestra eficiencia

Tras analizar los distintos modelos existentes de calidad y mejora de procesos, seleccionamos como referencia el modelo CMMI, ya que proporciona a las organizaciones que lo implantan un marco que facilita la mejora continua y la habilidad para desarrollar y mantener sus productos y servicios.

CMMI es un modelo de mejora de procesos desarrollado por el SEI (Software Engineering Institute). Este instituto, que actualmente está financiado por el departamento de Defensa de EEUU y administrado por la Universidad Carnegie Mellon, se fundó por el Congreso de Estados Unidos en 1974 para desarrollar modelos de evaluación y mejora, ya que era necesario dar respuesta a los problemas que generaba la programación e integración de los subsistemas de software en la construcción de complejos sistemas militares.

CMMI establece 5 niveles de madurez y 22 áreas de proceso para clasificar a las organizaciones dentro de dos representaciones, escalonada y continua.

Cada organización puede optar por la que se adapte mejor a sus características y prioridades de mejora; en Oxxigeno optamos por la representación escalonada por adecuarse a los objetivos planteados.

Decidimos comenzar por el nivel 2 por su orientación a la gestión de proyectos. Las áreas de proceso contempladas en este nivel son las siguientes:

• Planificación de proyectos
• Seguimiento y control de procesos
• Gestión de requisitos
• Aseguramiento de la calidad de procesos y productos
• Medición y análisis
• Gestión de la configuración
• Gestión de acuerdos con proveedores

En el comienzo de la implantación se realizó una evaluación inicial para detectar la situación de partida en la que nos encontrábamos y, posteriormente, se formó un equipo con distintos perfiles para analizar los resultados obtenidos y comenzar a trabajar en la implantación de procesos comunes para el área de servicios de desarrollo.

En Oxxigeno, decidimos afrontar el desarrollo y la implantación de los procesos tomando como pilares fundamentales las siguientes características:

• Utilización de herramientas ya conocidas por nuestros equipos: de este modo, el cambio no sería tan costoso y aprovecharíamos los conocimientos existentes.
• Implantación de una metodología común basada en los métodos y procesos que ya se estaban utilizando: los integrantes de los equipos de desarrollo ya tenían unos procesos y seguían una metodología; el propósito no era modificar dicha metodología ni inventar nuevos procesos, la meta era desarrollar una base común de procesos utilizable por todos.
• Apoyo incondicional de Dirección: desde el comienzo, la dirección de Oxxigeno consideró la mejora de procesos como un proyecto estratégico beneficioso para toda la organización. Por ese motivo nos apoyó durante todas las fases de la implantación.
• Distintas visiones en nuestro equipo de mejora de procesos: para ello, el equipo se compuso por personas de distintos perfiles que pudiésemos dar diferentes puntos de vista sobre la metodología a implantar.
• Implicación de todos los integrantes de Oxxigeno: durante todas las fases del proyecto celebramos reuniones con los jefes de proyecto, gerentes y distintos roles de la organización para revisar el avance del proyecto y recoger sugerencias y peticiones.

Tras cinco meses de trabajo, desarrollo e implantación en proyectos decidimos pasar a la siguiente fase. Solicitamos una evaluación intermedia para conocer el estado en el que estábamos y el grado de avance de consecución de los objetivos planteados. En los próximos días hablaremos del resultado de dicha evaluación y cuáles fueron nuestros siguientes pasos.

Compartiremos programa con buenos amigos de Multiplica y T2O Media, empresas con las que hemos trabajado y con las que nos alineamos en una misma visión de la web.

Las jornadas son gratuitas y tendrán lugar en Barcelona el martes 16 de junio de 10 a 12:30 en el Hotel U232 y en Madrid el miércoles 17 de junio de 9 a 11:30 en el Hotel de la Letras.

Aún nos queda alguna plaza de última hora. Si estás interesado, contacta con nosotros en evento@oxxigeno.com

Lo que en principio se nos antoja como una buena práctica, en la mayoría de las ocasiones, debido a una utilización mal estructurada del fichero de configuración, se convierte en una lista incontrolable y sin organización alguna de entradas en el nodo appSettings.

Para evitar esto existe una solución alternativa, más elegante, más clara y, más optima. Las clases ConfigurationSection, ConfigurationElement y ConfigurationElementCollection permiten definir secciones, elementos y colecciones de elementos en el fichero de configuración y utilizarlas como cualquier otro objeto en nuestro aplicativo.

Vamos a definir una pequeña sección en el fichero de configuración y comentamos un poquito cómo realizarla.

La clase EjemploData heredará de ConfigurationElement y tendrá dos propiedades Name y PropiedadBooleana, de tipo string y bool respectivamente. Las propiedades de ambas deberán tener el atributo ConfigurationProperty con el nombre que tomará en el fichero de configuración, su valor por defecto (si queremos especificarlo) y si es obligatoria.

public class EjemploData : ConfigurationElement
    {
        #region Public Properties
 
        private const string NamePropertyName = "name";
 
        [ConfigurationProperty(NamePropertyName, IsRequired = true)]
        public string Name
        {
            get { return this[NamePropertyName].ToString(); }
            set { this[NamePropertyName] = value; }
        }
 
        private const string PropiedadBooleanaPropertyName = "propiedadBooleana";
        [ConfigurationProperty(PropiedadBooleanaPropertyName, DefaultValue = "true", IsRequired = false)]
        public bool PropiedadBooleana
        {
            get { return (bool)this[PropiedadBooleanaPropertyName]; }
            set { this[PropiedadBooleanaPropertyName] = value; }
        }
 
        #endregion
    }

Crearemos una clase EjemploDataCollection que herede de ConfigurationElementCollection, tal y como se muestra, no requiere mucha explicación

public class EjemploDataCollection : ConfigurationElementCollection
{
#region ConfigurationElementCollection Members
 
protected override ConfigurationElement CreateNewElement()
{
return new EjemploData();
}
 
protected override object GetElementKey(ConfigurationElement element)
{
return ((EjemploData)element).Name;
}
 
public EjemploData this[int index]
{
get
{
return (EjemploData)BaseGet(index);
}
set
{
if (BaseGet(index) != null)
{
BaseRemoveAt(index);
}
BaseAdd(index, value);
}
}
 
#endregion
}

Finalmente, crearemos la clase que nos permita manejar este tipo de objetos. Esta clase debe heredar de ConfigurationSection, la cual nos servirá para marcar el ámbito en el cual obtendremos los valores dentro del fichero de configuración. Debe tener:

• Una constante pública que nos indique cómo llegar a la sección adecuada del fichero de configuración.
• Constantes privadas que nos marquen cómo se llamarán los atributos.
• Nodos hijos que podremos definir en el fichero de configuración
• Sus respectivas propiedades públicas que nos permitirán utilizarlas en cualquier parte de nuestro aplicativo.

En nuestro ejemplo definiremos la seccion como “oxxigeno/ejemploSettings”, lo que significa que en el fichero de configuración tendremos que definir un nodo oxxigeno y dentro uno ejemploSettings.

Queremos que exista una atributo en el nodo ejemploSettings, para lo cual crearemos una constante privada que nos diga como debe llamarse, “nuevaPropiedad”, y una propiedad pública que nos permita recuperarlo del fichero de configuración y utilizarlo en el aplicativo. Para ello crearemos una propiedad normal que nos devolverá un objeto de tipo string y le establecemos un atributo a la propiedad de tipo ConfigurationProperty, que indique cómo se va a llamar ese atributo en el fichero de configuración y si es obligatorio o no que exista.

Además nos interesa que bajo el nodo ejemploSettings exista una colección de nodos del mismo tipo (en nuestro caso EjemploData). Para ello procederemos igual que para la propiedad actual, pero definiremos su salida como EjemploDataCollection, y le agregaremos el atributo ConfigurationCollection pasándole como parámetro el tipo de objetos que se coleccionarán.

public sealed class EjemploSettings : ConfigurationSection
{
 
public const string SectionName = "oxxigeno/ejemploSettings";
 
#region Public Properties
 
private const string NuevaPropiedadPropertyName = "nuevaPropiedad";
 
[ConfigurationProperty(NuevaPropiedadPropertyName, IsRequired = true)]
public string NuevaPropiedad
{
get { return this[NuevaPropiedadPropertyName].ToString(); }
set { this[NuevaPropiedadPropertyName] = value; }
}
 
private const string ColeccionDeEjemploPropertyName = "coleccionDeEjemplo";
 
[ConfigurationProperty(ColeccionDeEjemploPropertyName, IsRequired = true, IsDefaultCollection = true)]
[ConfigurationCollection(typeof(EjemploData))]
public EjemploDataCollection ColeccionDeEjemplo
{
get { return (EjemploDataCollection)this[ColeccionDeEjemploPropertyName]; }
}
 
#endregion
}

Así pues, para cargar datos en el fichero de configuración, debemos cargar la clase controladora (EjemploSettings) y montar el árbol de nodos que hemos definido en las clases.

Dentro del nodo configurationSections debemos crear un nodo SectionGroup como se muestra, y dentro un nodo section. Pueden existir múltiples nodos sectionGroup pero no con el mismo nombre. Cada nodo sectionGroup puede tener en su interior multiples nodos section.

   <sectionGroup name="oxxigeno">
      <section name="ejemploSettings" type="Oxxigeno.Ejemplo.Configuration.EjemploSettings, Oxxigeno.Ejemplo, Version=1.0.0.0, Culture=neutral, PublicKeyToken=96df930e30970c00">
   </sectionGroup>

Y despues creamos el árbol de nodos tal como lo hemos definido, quedaría algo así:

   <oxxigeno> 
      <ejemploSettings nuevaPropiedad="valorDeLaPropiedad"&gt; 
         <coleccionDeEjemplo&gt; <clear/&gt;
            <add name="nombreDeLaEntrada1" propiedadBooleana="false" /&gt; 
            <add name="nombreDeLaEntrada2" propiedadBooleana="true" /&gt; 
         </coleccionDeEjemplo>
      </ejemploSettings>
   </oxxigeno&gt;

La forma de recuperar estos valores sería la siguiente:

EjemploSettings ejemploSettings = ConfigurationManager.GetSection(EjemploSettings.SectionName) as EjemploSettings;
string nuevaPropiedad = ejemploSettings.NuevaPropiedad;
foreach (EjemploData obj in ejemploSettings.ColeccionDeEjemplo)
{
string nombre = obj.Name;
bool propiedadBooleana = obj.PropiedadBooleana;
}

Considero que este método de utilización del fichero de configuración es:

• Más útil: Los valores se encuentran parseados al tipo necesario, no se obtienen unicamente valores de tipo string como pasa si utilizamos AppSettings, lo cual facilita el trabajo del desarrollador.
• Más estructurado: Los valores dentro del fichero de configuración son facilmente localizables y, por lo tanto, modificables.

Esta tecnología integra en una única metodología de programación las hasta ahora incompatibles COM+ (Serviced Components), .NET Remoting y Servicios Web. Para ello, un servicio WCF debe definir una serie de puntos de acceso (denominados EndPoints) que representan una puerta de entrada al servicio publicado, permitiendo así que un mismo servicio sea consultado mediante distintos tipos de comunicación.
Los EndPoints deben presentar:

• Dirección: representada por la clase EndPointAddress, indica dónde está la aplicación
• Enlace: representada por la clase Binding, indica cómo se puede accesar esa aplicación: Protocolo del transporte, Codificación y Seguridad.
• Contrato: representada por una clase con atributos de tipo ServiceContractAttribute, se trata de una definición de los datos que van a ser comunicados por el aplicativo.

WCF utiliza mensajes SOAP para la comunicación de estos datos, siguiendo así un estándar de comunicación. Sin embargo, cuando se realiza una comunicación entre dos procesos WCF se optimiza esta comunicación, aplicando una codificación en formato binario para los mensajes SOAP. De esto podemos olvidarnos totalmente, ya que al fin podemos crear un servicio sin preocuparnos de cómo ni quién va a acceder a él.

Vayamos con un ejemplo y veamos si es realmente lo que nos venden. Creamos una interfaz y una entidad que serán las que utilizaremos para dar vida al servicio.

[ServiceContract]
    public interface IExample
    {
        [OperationContract]
        string GetData(int value);
 
        [OperationContract]
        ExampleType GetDataUsingDataContract(ExampleType composite);
 
        [OperationContract]
        string[] GetNames();
    }
 
    [DataContract]
    public class ExampleType
    {
        bool _delete = false;
        string _name = "Name";
 
        [DataMember]
        public bool Delete
        {
            get { return _delete; }
            set { _delete = value; }
        }
 
        [DataMember]
        public string Name
        {
            get { return _name; }
            set { _name = value; }
        }
    }

Los atributos DataContract y OperationContract son, para entendernos, los atributos que sustituyen a WebService y WebMethod. Mientras que los atributos DataContract y DataMember son los atributos que servirán para serializar las entidades que se publicarán a través del servicio.

Ahora, una vez creada la interfaz que publicará el servicio y la entidad, procedemos a implementar la funcionalidad del servicio.

public class ExampleService : IExample
    {
        public string GetData(int value)
        {
            return string.Format("You entered: {0}", value);
        }
 
        public ExampleType GetDataUsingDataContract(ExampleType composite)
        {
            if (!composite.Delete)
            {
                composite.Name += " y Apellido";
            }
            return composite;
        }
 
        public string[] GetNames()
        {
            List<string> lista = new List<string>();
            for (int i = 0; i < 5; i++)
            {
                lista.Add("nombre" + i.ToString());
            }
            return lista.ToArray();
        }
    }

Con esto ya tenemos el código necesario para crear un servicio con WCF. Nos falta darle posibles puntos de entrada, para poder publicarlo. Lo hacemos a través del web.config del servicio.

<system.serviceModel>
    <services>
      <service name="Namespace.ExampleService" behaviorConfiguration="Namespace.ExampleServiceBehavior">
        <!-- Service Endpoints -->
        <endpoint address="" binding="wsHttpBinding" contract="Namespace.IExample">
          <identity>
            <dns value="localhost"/>
          </identity>
        </endpoint>
        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
      </service>
    </services>
    <behaviors>
      <serviceBehaviors>
        <behavior name="Namespace.ExampleServiceBehavior">
          <serviceMetadata httpGetEnabled="true"/>
          <serviceDebug includeExceptionDetailInFaults="false"/>
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>

Voy a intentar explicarlo de forma esquemática. Dentro de la etiqueta “services” creamos cada uno de los servicios que queramos publicar, mientras que dentro de la etiqueta “behaviors” definiremos diferentes comportamientos que podrán utilizarse en los servicios publicados.

Pero volvamos a la etiqueta “services”. Dentro de ella crearemos tantas etiquetas “service” como servicios queramos publicar. Cada una se define mediante nombre y comportamiento (“name” y “behaviorConfiguration”). Además debemos definir una serie de puntos de entrada (“endpoint”) con las propiedades “address”, “binding” y “contract”, y un nodo interno de tipo “identity” (como se ve en el código). Vamos con ellos:

• Etiqueta Service:
  • Address: Especificamos la URI, que puede estar como cadena vacía.
  • Binding: Especificamos el binding a utilizar, lo cual define el tipo de transporte, la seguridad y el encoding utilizado. Podemos utilizar un binding definido por nosotros.
  • Contract: Especifica la interfaz que define se publicará con el servicio.
• Etiqueta Behavior:
  • Name: Nombre del behavior, único en el web.config
  • ServiceMetadata: Especifica la publicación de los metadatos del servicio y de la información asociada.
  • ServiceDebug: Especifica las características de la información de depuración y de la ayuda para un servicio de la WCF.

Para una descripción más detallada podemos recurrir a la siguiente url de Microsoft: http://msdn.microsoft.com/en-us/library/ms733932.aspx

Respecto al cliente, su uso es tan sencillo como agregar la referencia al servicio a la solucion e invocarlo desde el código.

Al agregar la referencia al servicio podemos ver que el web.config ha sido modificado, añadiendo la configuracion necesaria para accesar dicho servicio. Veamos qué ha añadido:

<system.serviceModel>
        <bindings>
            <wsHttpBinding>
                <binding name="WSHttpBinding_IExample" closeTimeout="00:01:00"
                    openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
                    bypassProxyOnLocal="false" transactionFlow="false" hostNameComparisonMode="StrongWildcard"
                    maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
                    messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true"
                    allowCookies="false">
                    <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
                        maxBytesPerRead="4096" maxNameTableCharCount="16384" />
                    <reliableSession ordered="true" inactivityTimeout="00:10:00"
                        enabled="false" />
                    <security mode="Message">
                        <transport clientCredentialType="Windows" proxyCredentialType="None"
                            realm="" />
                        <message clientCredentialType="Windows" negotiateServiceCredential="true"
                            algorithmSuite="Default" establishSecurityContext="true" />
                    </security>
                </binding>
            </wsHttpBinding>
        </bindings>
        <client>
            <endpoint address="http://localhost:3153/ExampleService.svc"
                binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_IExample"
                contract="ExampleServiceReference.IExample" name="WSHttpBinding_IExample">
                <identity>
                    <dns value="localhost" />
                </identity>
            </endpoint>
        </client>
    </system.serviceModel>

Él solo ha creado todo el arbol de etiquetas de configuracion necesario para acceder al servicio mediante el endpoint que deseemos. Si nos fijamos en la etiqueta “endpoint” dentro de “client” podemos ver cómo ha agregado la direccion del servicio, el tipo de binding, la configuracion del mismo, la interfaz que presenta y el nombre (que es lo que utilizaremos para crear el objeto client en código):

ExampleClient clientDefault = new ExampleClient("WSHttpBinding_IExample");
            string[] namesDefault = clientDefault.GetNames();

Vamos a crear otro endpoint en el web.config del servicio y vamos a refrescar la referencia en el cliente para ver cómo cambia el web.config, añadiendo el nuevo endpoint y veremos cómo referenciarlo. Agregamos dos endpoints:

 <endpoint address="Soap11" contract="Namespace.IExample" binding="basicHttpBinding"/>
            <endpoint address="Soap12" contract="Namespace.IExample" binding="wsHttpBinding"/>

Y refrescamos la referencia al servicio en el cliente. Miramos el web.config y descubrimos que tenemos nuevas formas de acceder al servicio:

 <endpoint address="http://localhost:3153/ExampleService.svc/Soap11"
                binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IExample"
                contract="ExampleServiceReference.IExample" name="BasicHttpBinding_IExample" />
            <endpoint address="http://localhost:3153/ExampleService.svc/Soap12"
                binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_IExample"
                contract="ExampleServiceReference.IExample" name="WSHttpBinding_IExample1">
                <identity>
                    <userPrincipalName value="ivinuales@oxxigeno-networks.spain" />
                </identity>
            </endpoint>

Además, nos ha creado una nueva entrada dentro de bindings:

<basicHttpBinding>
                <binding name="BasicHttpBinding_IExample" closeTimeout="00:01:00"
                    openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
                    allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
                    maxBufferSize="65536" maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
                    messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
                    useDefaultWebProxy="true">
                    <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
                        maxBytesPerRead="4096" maxNameTableCharCount="16384" />
                    <security mode="None">
                        <transport clientCredentialType="None" proxyCredentialType="None"
                            realm="" />
                        <message clientCredentialType="UserName" algorithmSuite="Default" />
                    </security>
                </binding>
            </basicHttpBinding>

De tal forma que ahora en el código fuente podemos instanciarlo de 3 formas distintas:

            ExampleClient clientDefault = new ExampleClient("WSHttpBinding_IExample");
            string[] namesDefault = clientDefault.GetNames();
 
            ExampleClient clientSOAP11 = new ExampleClient("BasicHttpBinding_IExample");
            string[] namesSOAP11 = clientSOAP11.GetNames();
 
            ExampleClient clientSOAP12 = new ExampleClient("WSHttpBinding_IExample1");
            string[] namesSOAP12 = clientSOAP12.GetNames();

Lo primero que debemos hacer es identificar esa entidad y crear una clase para guardar esos datos. Después debemos tener algun mecanismo para rellenar esta clase con los valores de cada una de las filas (cada fila del fichero supondrá un objeto de ésta clase).

Pongamos un ejemplo.  Supongamos un fichero csv como el siguiente:

Edad; Nombre; Apellido
15; Pepito; Perez
57; Ernesto; Román
RowCount = 2

En ocasiones los csv traen una cabecera y/o un pie de fichero y en otras no, por lo que no podemos tratar de procesarlas siempre.

Vamos a empezar creando una clase entidad como la siguiente:

public class Edades
{
    private int _edad;
    private string _nombre;
    private string _apellido;
    public int Edad
    {
        get { return _edad; }
        set { _edad = value; }
    }
    public string Nombre
    {
        get { return _nombre; }
        set { _nombre = value; }
    }
    public string Apellido
    {
        get { return _apellido; }
        set { _apellido = value; }
    }
}

Como vemos, se trata de una clase tonta con 3 atributos y sus 3 correspondientes propiedades publicas. En este ejemplo sería muy sencillo por cada fila crearnos un objeto y asignar a Edad el primer valor de la fila, a Nombre la segunda y a Apellido la tercera, serían 3 simples líneas. Sin embargo, a medida que el csv (y la clase) contengan más campos esto se haría más complejo, y sería muy complejo de modificar si algún día deciden introducir un campo nuevo en mitad del csv.

Claro este punto, debemos tener alguna forma de relacionar cada propiedad de la clase con la posicion que ocupa ese valor en el csv. Para esto tenemos dos opciones:

• Si la posición de cada campo es susceptible de ser modificada periódicamente deberíamos determinar esta relación en el web.config (si es una aplicación web) o en app.config (si es una aplicación de escritorio)
• Si la posición de cada campo no es susceptible de ser modificada, es preferible agregar atributos a la clase que indique donde debemos buscar el valor de cada propiedad.

Voy a centrarme en este segundo supuesto, el primero posiblemente lo trataremos en otro artículo. Vamos a generar una clase que herede de Attribute para poder indicar en la clase que acabamos de crear donde buscaremos cada valor.

public class CSVFieldAttribute : Attribute
{
    private int _order;
    public int Order
    {
        get { return _order; }
        set { _order = value; }
    }
    public CSVFieldAttribute(int order)
    {
        _order = order;
    }
}

Ahora modificamos la clase de la entidad, añadiéndole a cada propiedad un atributo indicando su posición en el csv. La clase quedaría como sigue:

public class Edades
{
    private int _edad;
    private string _nombre;
    private string _apellido;
 
    [CSVField(0)]
    public int Edad
    {
        get { return _edad; }
        set { _edad = value; }
    }
    [CSVField(1)]
    public string Nombre
    {
        get { return _nombre; }
        set { _nombre = value; }
    }
    [CSVField(2)]
    public string Apellido
    {
        get { return _apellido; }
        set { _apellido = value; }
    }
}

En este punto podemos elegir partir de una base en 0 o una base en 1. Yo he preferido partir de base 0 porque es la utilizada en los arrays por C#.
Ya tenemos relacionada la clase de entidad con los valores del csv, ahora falta buscarnos la vida para rellenar un objeto a partir de una fila del csv. Propongo utilizar Reflexion y las Templated classes para generalizar este proceso, creando una clase que trasforme un array de valores en un objeto del tipo que le indiquemos. A las propiedades de ese objeto les asignaremos el valor (mediante reflexion) que haya en el array de valores en la posición indicada. Vayamos al tema:

public class CSVConverter<T>
{
    public T Convert(string[] values)
    {
        Type type = typeof(T);
        T obj = Activator.CreateInstance<T>();
        try
        {
            CSVFieldAttribute att = null;
            object[] attributes = null;
            foreach (PropertyInfo prop in type.GetProperties())
            {
                attributes = prop.GetCustomAttributes(typeof(CSVFieldAttribute), false);
                if (attributes.Length &gt; 0)
                {
                    att = attributes[0] as CSVFieldAttribute;
                    /* Si hemos optado por usar base 1 debemos poner:
                        values[att.Order - 1]
                    */
                    if (!(values[att.Order].Trim().Equals(string.Empty)))
                    {
                        prop.SetValue(obj,
                           Convert.ChangeType(values[att.Order], prop.PropertyType),
                           null
                        );
                    }
                }
            }
        }
        catch (Exception ex)
        {
            throw new Exception("Error al intentar hacer la conversión de tipos.\r\n" + ex.Message, ex);
        }
        return obj;
    }
}

Ya solo queda procesar el fichero para ir creando los objetos y hacer lo que tengamos que hacer con ellos. Para ello, nos crearemos una clase base a partir de la cual heredaremos las clases de negocio que creamos oportunas para procesar distintos modelos de csv.

public class ProcessCSV<T>
{
    protected StreamReader _streamReader;
    protected string _line;
    public void Process(string filename)
    {
        try
        {
            _streamReader = new StreamReader(filename);
            this.ProcessHeader();
            this.ProcessBody();
            this.ProcessFooter();
        }
        catch (Exception ex)
        {
            throw ex;
        }
        finally
        {
            if (_streamReader != null)
                _streamReader.Close();
        }
    }
    protected virtual void ProcessHeader()
    {
        throw new Exception("No implementado");
    }
    protected virtual void ProcessFooter()
    {
        throw new Exception("No implementado");
    }
    protected virtual void ProcessOneObject(T obj)
    {
        throw new Exception("No implementado");
    }
    protected void ProcessBody()
    {
        T obj = Activator.CreateInstance<T>();
        _line = _streamReader.ReadLine();
        while (!_streamReader.EndOfStream && _line != null && _line.Trim() != string.Empty)
        {
            try
            {
                string[] values = _line.Split(';');
                CSVConverter<T> converter = new CSVConverter<T>();
                obj = converter.Convert(values);
                this.ProcessOneObject(obj);
            }
            catch (Exception ex)
            {
                // Aquí escribiríamos algo en el log indicando qué fila ha fallado
            }
        }
    }
}

Ya tenemos nuestra clase genérica. Pero claro, con esto no hacemos nada, si intentas parsear algo llamando a esta clase te van a saltar excepciones porque no está implementados algunos métodos necesarios. Generemos la clase que realmente usaremos.

Partimos de varios supuestos: el csv es el que he puesto arriba (con cabecera y pie), no vamos a usar para nada ni la cabecera ni el pie y queremos agregar a una lista para luego procesarlos (esto no lo voy a contemplar en el articulo).
Al tema:

public class EdadesBL : ProcessCSV<Edades>
{
    private List<Edades> _list;
    public EdadesBL()
    {
        _list = new List<Edades>();
    }
    protected override void ProcessHeader()
    {
        // Solo leemos porque no queremos conservar la cabecera
        _streamReader.ReadLine();
    }
    protected override void ProcessFooter()
    {
        // Solo leemos porque no queremos conservar la cabecera
        _streamReader.ReadLine();
    }
    protected override void ProcessOneObject(Edades obj)
    {
        // Solo queremos agregarlo a la lista.
        _list.Add(obj);
    }
    public List<Edades> Edades
    {
        get { return _list; }
    }
}

Ahora solo tenemos que procesar el fichero con dos simples líneas (en nuestro pequeño ejemplo 3 para recoger tambien la lista de Edades):

EdadesBL business = new EdadesBL();
business.Process(filename);
List todos = business.Edades;

Los sitios web desarrollados bajo el .NET framework son publicados con una precompilación del código fuente, sin embargo, las páginas aspx y los controles ascx son interpretados en tiempo de ejecución. Es decir: cada vez que un usuario solicita una página aspx ésta es interpretada por el servidor de aplicaciones y presentada al cliente.

Como puede suponerse, el hecho de que la página aspx contenga código fuente que deba ser compilado ralentizará la carga de la misma, puesto que se pasa de interpretar html y devolverlo a compilar código de servidor con más o menos lógica.

En muchas ocasiones es posible pensar que no nos es posible crear la página aspx tal y como queremos sin incluir código de servidor en la misma, esto es un error muy común, pero facilmente subsanable, siguiendo las siguientes recomendaciones.

• Solo está permitido utilizar código de servidor para cargar elementos dentro de controles de tipo DataBound (GridView, FormView, etc.). Aun así es poco recomendable porque sigue requiriendo compilación. Se recomienda la utilización del control Repeater.

 
                <%# Eval("TipoDePagina.Nombre") %>
 
                Editar Contenidos

• Si necesitamos que un elemento HTML obtenga propiedades (style, href, title, etc.) desde el lado del servidor, porque utilice alguna lógica de negocio debemos identificar a éste elemento con runat=server y asignar dichas propiedades desde el code-behind, que va precompilado cuando se publica.

aspx no recomendado:

<div id="global" class="fondo-menu-&lt;%= ambitoCabecera %&gt;">
<div id="cabecera" class="cabecera-&lt;%= ambitoCabecera%&gt;">
<div id="cabecera-logo">
            <a title="Alt" href="#">
                <img id="imgLogo" src="../images/&lt;%= image%&gt;" alt="Grupo Banco Popular" width="148" height="50" />
            </a></div>
<div id="shortcuts">
<ul class="horizontal">
	<li><a href="#">Atención al cliente</a> |</li>
	<li><a href="#">Sucursales</a> |</li>
	<li><a href="#">Tarifas</a> |</li>
	<li><a href="#">Simuladores</a></li>
</ul>
</div>
<div id="buscador">
            <fieldset>
 
            </fieldset></div>
</div>
</div>

Código no recomendado:

// Imagen por omision para el logo
public string _image = "default.jpg";
// Ambito por omision para la cabecera
public string _ambitoCabecera = "normal";
 
protected void Page_Load(object sender, EventArgs e)
{
 
    #region Dar valores a las variables
    ...
    #endregion
 
}

aspx recomendado:

<div id="global">
<div id="cabecera">
<div id="cabecera-logo">
            <a title="Alt" href="#">
                <img alt="Grupo Banco Popular" width="148" height="50" />
            </a></div>
<div id="shortcuts">
<ul class="horizontal">
	<li><a href="#">Atención al cliente</a> |</li>
	<li><a href="#">Sucursales</a> |</li>
	<li><a href="#">Tarifas</a> |</li>
	<li><a href="#">Simuladores</a></li>
</ul>
</div>
<div id="buscador">
            <fieldset>
 
            </fieldset></div>
</div>
</div>

Código recomendado:

protected void Page_Load(object sender, EventArgs e)
{
    // Imagen por omision para el logo
    string image = "default.jpg";
    // Ambito por omision para la cabecera
    string ambitoCabecera = "normal";
 
    #region Dar valores a las variables
    ...
    #endregion
 
    this.global.Attributes.Add("class", "fondo-menu-" + ambitoCabecera);
    this.cabecera.Attributes.Add("class", "cabecera-" + ambitoCabecera);
    this.imgLogo.Src = "../images/" + image;
 
}

• Si necesitamos que un elemento HTML reciba su identificador, propiedades sensibles o una maquetación compleja dependiente de una lógica de negocio, la solución optima es crear un custom web control para definirlo, éste tipo de controles heredan de la clase WebControl.

namespace Example.Web.UI.Controls
{
    [DefaultProperty("Text"), ToolboxData("&lt;{0}:OnlyText runat=server&gt;<!--{0}:OnlyText-->")]
    public class OnlyText : System.Web.UI.WebControls.WebControl
    {
        #region Attributes
 
        private string _text = "";
 
        #endregion
 
        #region Properties
 
        [Bindable("true"), Category("Data"), DefaultValue("")]
        public string Text
        {
            get { return _text;}
            set { _text = value;}
        }
 
        #endregion
 
        #region Overrides Methods
 
        protected override void  Render(HtmlTextWriter writer)
        {
             writer.Write(Text);
        }
 
        #endregion
    }
}

Diego Cano y yo tuvimos la oportunidad de pasarnos el pasado martes 27 por el congreso que se realizó en la UPM para celebrar el día de la W3C en España. Allí además nos juntamos con Manuel Barroso, que empezará a formar parte del equipo de Oxxigeno la próxima semana, por lo que finalmente tuvimos una representación más que notable.

Bajo el lema de “Standard for Business”, el congreso se dividió en 3 grandes bloques:

1. Accesibilidad
2. Movilidad
3. Semántica

En el tiempo dedicado a Accesibilidad nos gustaron varios apuntes:

• ¿Cómo conservar la accesibilidad en sitios dinámicos? Se propuso evolucionar del WYSIWYG al WYSIWYM, dándole al usuario soluciones ya predefinidas que impiden llegar a casos de pérdida de accesibilidad. De igual modo, se defendieron flujos de trabajo que garantizaran la constancia del nivel de accesibilidad de un sitio.
• Desde luego, se dejó suficientemente claro que las necesidades de accesibilidad no son algo exclusivo de usuarios con discapacidades, sino que estas necesidades son algo fundamental para una experiencia de usuario mínima desde dispositivos móviles.

Ese punto conectó con la parte de Movilidad:

• El mayor debate se centró entre la decisión de “adaptar” un sitio web a un dispositivo o apostar por una web única con cierta capacidad de “transformación dinámica”.
• A pesar de la apuesta de la W3C por “una web, distintos dispositivos” se pudieron ver buenos ejemplos de adaptación al dispositivo móvil, como soitu. También, por otro lado, se presentaron transformaciones automáticas interesantes mediante Merkur y MyMobileWeb.
• En otro terreno un poco diferente, también nos gustó la presentación del “Push Gateway” de Vodafone R&D: Un interesante sistema para acceder a la información del móvil a partir de un ordenador u otro dispositivo que resultó todavía más apasionante con la posibilidad de usar el móvil como un emisor conectado a cualquier tipo de sensor.

Ya en el área de Semántica pudimos centrarnos en otros puntos:

• Se mostraron casos de éxito de aplicaciones semánticas, tanto culturales, como en banca o industria.
• Se presentaron, sin embargo, diversos problemas de interoperabilidad entre diferentes sintaxis. Esto motivó un más o menos acalorado debate entre los defensores de la agilidad y descentralización de los Microformatos y los que los consideran una buena ayuda a una web semántica por llegar, pero nada más.

Desde nuestro punto de vista, fue una jornada interesante, donde

• Se habló de accesibilidad con bastante sentido común y una visión integradora
• Se aclararon algunos temas de movilidad y se presentaron propuestas novedosas
• Se participó en un intenso debate sobre web semántica