VIDEO: Nuevas certificaciones para desarrolladores con Visual Studio 2008.

Jose Manuel Alarcón publicó un artículo sobre la evolución de las nuevas certificaciones para Visual Studio 2008 y de qué manera podrían afectar un proceso actual de certificación.

Me resultó sorprendente la fecha de lanzamiento del examen para ASP.NET (21 de mayo) y algunas otras cosas...

 

Puedes ver el video aquí y Enlace al post completo

Sea el primero en calificar este post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Escribiendo código a la defensiva y manejando excepciones,

Desde el lanzamiento de .NET y su aplicación al desarrollo de aplicaciones Web (ASP.NET), uno de los principios esenciales es el desarrollar código seguro, pues qué puede significar eso?

No solamente es evitar inyecciones al código de tipo SQL, sino tambien implementar una serie de políticas que eviten el mal uso de este código, y sobre todo hacer que nuestras aplicaciones no se "caigan" de forma catastrófica (léase la típica pantalla de error de .NET) frente al usuario.

Dentro de nuestra organización  hemos tratado e imprimir una serie de reglas en el desarrollo de nuestras aplicaciones de las cuales enumero algunas:

  1. Nunca confíes en el input del usuario:
    Una de las causas más comunes de errores no controlados, el asumir que el usuario ubicará datos congruentes en cualquiera de los mecanismos de ingreso de información. De manera que todo "absolutamente todo" es validado a todo nivel, desde las formas ASP.NET hasta la capa de datos.

  2. Nunca permitas que la interfaz de usuario "se caiga":
    El usuario no debería perder la interacción con la aplicación. Si se llegase a generar una excepción, no debería ser el fin del mundo!, de esta manera tratamos de informarle al usuario: Qué paso? Qué tipo de excepción es?, Por qué pudo haberse generado el error? y Qué puede hacer para remediarlo?: Si es un error de input que ubique los valores adecuados o si es un error no manejable por el usuario a quién tiene que contactar para resolverlo.

  3. Capturar la mayor cantidad de excepciones posibles y registrarlas:
    El poder analizar los métodos dentro de los componentes, datos o presentación clasificando excepciones podría resultar una tarea ardua, pero enriquecedora en cuanto a resultados, mucho más si registramos las excepciones generadas, nos ha ayudado muchísimo a resolver problemas insospechados de forma relativamente rápida y efectiva. Aquí incluyo la clasificación de excepciones: comenzamos entre las "Excepciones Catastróficas" y el "Resto", para priorizar... lógicamente esta división se amplió a categorización por módulo, importancia, frecuencia, etc.

  4. Verificación de nulidad de objectos:
    Asumir que el objeto (sea control, instancia de clase, etc) podría ser nulo ("null") en cualquier momento. Esta estrategia te libera de muchos problemas derivados de la omisión.

  5. Implementar mecanismos de reporte de Bugs:
    Una vez que la aplicación está en producción, al usuario detectar un bug o excepción, tiene la posibilidad de reportarlo mediante mecanismos de comunicación con nuestro departamento de soporte. Esencial en aplicaciones de alto desempeño. Seamos razonables, la aplicación libre de bugs no existe, por lo tanto lo mejor es tratar de manejarlos, reportarlos e incluirlos dentro del flujo de soporte. Muy buenos resultados, sobre todo hacia la imagen que damos al usuario.

Son algunas cosas, pocas, las que he mencionado, pero que ayudan realmente en construir código realmente seguro y sobre todo enfocado hacia el soporte al usuario asegurando un ciclo de vida lo más correcto posible de la aplicación.

Espero seguir escribiendo sobre esto en algún post más... saludos. 

Actualmente calificado con 4.5 por 2 personas

  • Currently 4,5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

links for 2008-01-22

Sea el primero en calificar este post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Categorías:
Acciones: E-mail | del.icio.us | Permalink | Comentarios (0) | Comment RSSRSS comment feed

links for 2008-01-18

Sea el primero en calificar este post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Categorías:
Acciones: E-mail | del.icio.us | Permalink | Comentarios (0) | Comment RSSRSS comment feed

Ordenando (Sort) Colecciones con tipos genéricos y Métodos Anónimos

Ordenar una colección, podría tomarse como una de las tareas más triviales dentro del desarrollo de algo: Sobrescribir el método Sort(), implementar IComparer o IComparable, etc. Pero a veces en aras del tiempo necesitas hacerlo de forma aún más rápida, esencialmente con colecciones "inocuas" (llamo a esto una simple collección que implementa List<object> ej: OrderCollection : List<Order>). En ese momento es que encontré un uso realmente práctico a la combinación de Tipos Genéricos y Métodos Anónimos: utilizarlos para ordenar una colección.

En primer lugar tomemos una clase Order la cual contiene las propiedades: Id, CreatedDate y Value. (los nombres se han tomado simplemente para términos de explicación) definida así:

[Serializable]
    public class Order
    {
        private int _Id;
        private decimal _Value;
        private DateTime _CreatedDate;
 
        public int Id
        {
            get { return _Id; }
            set { _Id = value; }
        }
 
        public decimal Value
        {
            get { return _Value; }
            set { _Value = value; }
        }
 
        public DateTime CreatedDate
        {
            get { return _CreatedDate; }
            set { _CreatedDate = value; }
        }
    }

Y además se define la colección de items de tipo Order:

public class OrderCollection: List<Order> { }

Para uso práctico en un reporte específico necesitas ordenar la lista de órdenes que has obtenido por la propiedad CreatedDate, allí entran los métodos anónimos, inserto el código para luego explicar: 

private void BindOrders()
{
    //Obtener las órdenes de la DB.
    OrderCollection orders = Orders.GetAllOrders();
 
    //Sort - Orden por CreatedDate
    orders.Sort(
        delegate(Order x, Order y)
        {
            return Comparer<DateTime>.Default.Compare
                (x.CreatedDate, x.CreatedDate);
        }
        );
 
    //Asignación
    Repeater rptOrders = FindControls("rptOrders") as Repeater;
    if (rptOrders != null)
    {
        rptOrders.DataSource = orders;
        rptOrders.DataBind();
    }
}

Pues qué hemos hecho aqui? Espero ya hayas encontrado el punto clave y no tengas que leer el resto.

  1. Utilizamos la sobrecarga del método Sort() para utilizar un delegado, a este delegado se le asignan los parámetros x & y como objetos de Tipo Order.
  2. Creamos el método anónimo para ese delegado, allí sin más ni más. Comúnmente deberíamos generar otro método que maneje la delegación... pero podemos hacerlo allí.
  3. Retornamos en ese método anónimo la comparación de los objetos generada mediante la implementación de Comparer<DateTime> que crea una instancia "genérica" de Comparer con el tipo DateTime.
  4. El compare recibe las propiedades del objeto x & y para realizar la comparación.
  5. Listo.

Este mecanismo "elegante" como denominarían algunos podría permitirnos realizar muchas funciones de sort sin requerir ir a modificar las clases bases, especialmente si no tienes acceso al código fuente base. Como el caso de un custom framework. De esta manera podríamos tomar cualquier propiedad para realizar el Sort().

Espero que este ejemplo simple y pequeño pueda ayudarlos y aliviarles una jornada de trabajo, tal como me pasó a mí.

Happy Coding.

Actualmente calificado con 5.0 por 2 personas

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Categorías

Sponsors


    Blogroll