Javier-RomeroDesarrollando desde el Milenio Pasado

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

Tags: visual studio 2008, certificaciones, asp.net, c#, wpf, learning
Categorías: C# | WPF | ASP.NET | .NET | Certificaciones | Visual Studio
Acciones: E-mail | del.icio.us | Permalink | Comentarios (1) | Comment RSS

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. 

Tags: asp.net, visual studio, metodología, soporte al usuario, excepciones
Categorías: ASP.NET | Project Management | .NET | Metodologia
Acciones: E-mail | del.icio.us | Permalink | Comentarios (1) | Comment RSS

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.

Tags: anonymous methods, generics, c#, visual studio
Categorías: C# | ASP.NET | .NET | Visual Studio
Acciones: E-mail | del.icio.us | Permalink | Comentarios (2) | Comment RSS

Al realizar alguna aplicación la cual tenía que enviar un mensaje de email a Hotmail o Windows Live, casi siempre el mensaje se ubicaba dentro de la carpeta spam del cliente de correo.

Un problema que tenía a nuestro jefe de proyectos bastante malhumorado, y por más que implementábamos soluciones de registro en Dns, validación de IP, etc... el problema seguía presentándose.

Pues acabo de leer en Geek.ms la solución: 

En la que explica que el problema está en la transición de la clase MailMessage from System.Web.Mail to System.Net.Mail en algunos cambios que han realizado hacen que las cabeceras del mail se envien en minúsculas y que provocan que el servidor de correo los trate como spam.

La solución está en instalar el SP1 de NET 2.0 o pasarse a NET 3.5 que ya ha sido corregido.

Espero que esto deje tranquilo a algunos...

Happy Coding. 

Categorías: ASP.NET | General | .NET | Visual Studio
Acciones: E-mail | del.icio.us | Permalink | Comentarios (1) | Comment RSS

Cuando se construye un equipo, como ahora en mi oficina. Se debe pensar que es muy importante manejar la cultura de equipo de tal manera que se pueda ser lo más productivo posible. A través del tiempo trabajando con equipos con difierentes disciplinas se podría ubicar un lista de actitudes e ideas que beneficien al equipo de desarrollo. Se la podría denominar el Credo de Desarrollo. 

Este es un artículo que Eric Wase ha publicado y me permito reproducir en su extensión. 

 Yo <Tu nombre> soy un  desarrollador.

Entiendo que la razón por la cual yo existo, es para servir y resolver las necesidades de los usuarios.  Tomaré los requerimientos del usuario seriamente y seré un apasionado del servicio al cliente. No mostraré ningun desdén por el usuario que no entienda lo que yo hago y siempre trataré de cruzar el puente entre el mundo técnico y el del usuario para poder comprenderlo mejor. Al lograr entender al usuario puedo ganarme su confianza, y con esta confianza tendré un socio valioso en el proceso de desarrollo.

Entiendo que cada uno de los miembros del staff de IT es importante para lograr alcanzar mis metas. Los administradores de Bases de Datos protegen mis datos y me ayudan a asegurar el desempeño. Los Administradores de Red aseguran que mis respaldos (backups) están seguros y que tengo los accesos, permisos, software y sistemas adecuados y funcionando para realizar mi trabajo. No formaré un "gueto" de desarrolladores ni tendré una mentalidad "nosotros vs ellos". Apoyaré a los miembros de mi equipo que no sean desarrolladores como si fuera otro cliente o compañero.

Entiendo que cada uno de los desarrolladores de mi equipo es mi compañero. Como compañeros, ellos tendrán mi respeto y así lograré tener el de ellos. Con una relación basada en confianza y respeto, no voy a temer al formular preguntas, plantear inquietudes, o de otro modo ayudar a mis compañeros en la creación de código de alta calidad. Considero cualquier conflicto intelectual como una función saludable y natural de los equipos para encontrar la mejor ruta de acción para completar una tarea. Cuando el conflicto haya concluido y una dirección haya sido decidida por el equipo, apoyaré de todo corazón el enfoque adoptado, incluso si mi sugerencia no fue la "ganadora".

Entiendo que el ego en todas sus formas es destructivo y perjudicial para el equipo. Voy a recordar que el equipo es el propietario del código, no el individuo. A pesar de que debería sentirme orgulloso de mis logros personales, siempre recordaré darle crédito a la ayuda que el equipo me haya dado para cumplir estos logros, y nunca mostraré egoismo sobre mi código y técnicas hacia mis compañeros. Voy a alentar a mis compañeros a entender mi código y siempre sentar como bienvenidas cualquier crítica constructiva. Me doy cuenta de que todo el código puede ser mejorado y tomaré la crítica como una oportunidad para el debate intelectual y una experencia de aprendizaje, mas no como algo personal.

Entiendo que mi campo de acción está en constante crecimiento y evolución. Voy a crear oportunidades para explorar nuevos conceptos y estaré abierto a nuevas Ideas. No me cerraré en patrones particulares o prácticas de desarrollo en las cuales me siento a gusto pero que no son apropiadas en ciertas situaciones. Cuando uso patrones y prácticas particulares, voy a sopesar cuidadosamente los beneficios e inconvenientes de dichos patrones y tomaré las decisiones que sean siempre lo mejor para el equipo. Aunque guste de aprender cosas nuevas, me resistiré a usar herramientes y prácticas de desarrollo sólo porque son nuevas o "avanzadas", si es que no agregan valor real al código, servicio o producto que estoy haciendo.  

Tengo como idea principal que a pesar de que soy el primero en escribir algún código en particular, no voy a ser el último en mantenerlo, administrarlo o hacerle cambios. Voy a tratar de mantener mi código legible, bien documentado y que tenga la menor complejidad posible. No asumiré que ya que conozco de una herramienta o patrón de desarrollo el resto de desarrolladores lo conocerá. Documento cuidadosamente los usos y justificativos para usar un patrón o herramienta para que los que vengan detrás de mí puedan entender mejor lo que yo estaba tratando de lograr con este código. Nunca construiré código "obscuro" o difícil de entender, solo por intentar lograr "un empleo seguro" o demostrar lo listo que soy.

Léelo Completo: My Team's Developer Credo en - Eric Wase Blog

Tags: team development
Categorías: Team Foundation Server | ASP.NET | Project Management | General | .NET | Metodologia
Acciones: E-mail | del.icio.us | Permalink | Comentarios (0) | Comment RSS