moure.es – Alfonso Moure Ortega

O más conocidos como Annonymous Methods. Los programadores de la vieja escuela siempre habráno notado la ausencia de esta opción, añadida en la versión 2.0 de C# y no demasiado conocida por los desarrolladores que aun no han cambiado totalmente el chip desde la versión 1.1 de .NET Framework (desgraciadamente, demasiados hoy en día).

¿Qué es un método anónimo? A veces hay situaciones donde debemos utilizar determinados pedazos de código que no vamos a usar más adelante en nuestro programa a modo de método o función, por lo que no es necesario realizar un esfuerzo extra para refactorizar nuestro código o crear zonas reutilizables. Una clara situación: el envío de un método delegado como parámetro para una función.

Tradicionalmente, para poder pasar un método como parámetro, debíamos primero definir un tipo de delegado, crear dicho método, y enviarlo como parámetro:

public delegate void MiDelegado(int x);

/* … */

public bool ProbarMetodo(MiDelegado metodo) { int i = 5; /* … */ return metodo(i); }

void MiFuncion(int x) { return x*2; }

/* ..  */

//Llamamos al método pasando como parámetro un delegado
this.ProbarMetodo(this.MiFuncion);

Vamos… un completo engorro. Es entonces cuando entran en juego nuestros amigos los métodos anónimos, donde en lugar de crear un tipo de delegado e ir pasandolo engorrosamente, introducimos la implementación del método directamente en la llamada:

this.ProbarMetodo(delegate (int x) { return x*2; });

Como veis, esto nos facilita mucho la existencia: es algo más complicado de leer y comprender (pese a que este ejemplo es bien sencillo) pero ganamos a la hora de simplificar la estructura de métodos de nuestra clase. Todo un logro de los creadores de C# 2.0, y un gran punto donde C# 3.0 tiene uno de sus pilares de soporte centrales para la creación de la API de LINQ y su nueva sintaxis, y muy útil para las nuevas funciones lambda que nos alegran la vida con la nueva versión del lenguaje.

Bookmark

En mi post anterior dedicado a las conexiones a base de datos desde ASP.NET comenté algunos de los problemas más comunes durante el diseño de arquitecturas software en ASP.NET y la gestión de conexiones con bases de datos, especialmente con Microsoft SQL Server.

Vimos que la solución final necesaria para poder utilizar conexiones en ASP.NET sin meternos en lios de memoria o conexiones compartidas, debíamos abrir y cerrar la conexión con la base de datos para cada consulta, pese a que pudiera parecer redundante o molesto.

Pero, si aplicais lo planteado en un proyecto a gran escala y con un buen tráfico de usuarios, notareis que no se sufre un impácto demasiado grande en el rendimiento de la aplicación pese a utilizar esta técnica, y esto se debe a una gran capacidad con la que cuenta SQL Server: el connection pooling: cuando llamamos a Close() para cerrar la conexión a la base de datos, ésta no se cierra, sino que queda almacenada en un listado de conexiones inactivas a las que puede recurrirse en cualquier momento.

Más adelante en nuestra misma aplicación, cuando llamemos a Open() para volver a conectarnos, ASP.NET y SQL Server colaborarán para localizar una conexión marcada como inactiva pero cuyo connection string coincida con la conexión que intentamos crear y activar. En el momento en que es localizada, esta es invocada y reactivada, evidanto de esta manera un malgasto de recursos extra al crear y abrir una conexión.

Una cosa debe quedarnos bien clara en cualquier caso: cualquier tipo de movimiento o trabajo con la base de datos, apertura o cierre de conexión con un proveedor, petición o inserción de datos, consume recursos temporales y de memoria del sistema, por lo que es de vital importancia el localizar nuevas vias de trabajo con datos y mejoras  en sus algoritmos como puntos clave para potenciar la eficiencia de nuestras aplicaciones.

Bookmark

Existen muchas maneras de gestionar el acceso a bases de datos desde ASP.NET, unos mejores que otros, y sin duda cada uno tenemos nuestro propio sistema (“Cada maestrillo tiene su librillo“, como siempre me han dicho en mi casa). ¿Cuál creeis que puede ser el mejor?

Por supuesto a la hora de elegir el sistema más apropiado tendremos que tener en cuenta toda una serie de factores, ventajas y desventajas, de cada uno de los diferentes modos existentes:

1. Gestión centralizada :: las conexiones a la base de datos son administradas en una clase común accesible desde cualquier punto de la aplicación (ahorro de recursos a la hora de abrir y cerrar conexiones y realizar consultas ligeras o atómicas.
2. Gestión individual :: abrir y cerrar la conexión cada vez que sea necesario lanzar comandos hacia la base de datos.

Desde un punto de vista organizativo, no hay duda que la centralización es la mejor opción: atomización del control de base de datos, administración localizada en un punto de todo el tráfico de datos, y disminución de la complejidad del código. Ahora bien, el diseño de un sistema que permita este tipo de trabajo, aunque no imposible, es relativamente complicado: debemos tener en cuenta que toda aplicación web, al menos en la mayor parte de los casos, deberá soportar un cierto grado de concurrencia de usuarios de manera simultánea, por lo que podemos descartar el uso de variables static (o shared en VisualBasic), ya que estas son compartidas en todas las instancias de la aplicación web en ejecución.

Analicemos la posible solución como conexión común en una variable static:

class ClaseComun { private static SqlConnection __connection; }

Vemos que definimos una clase que contiene la variable privada estática que almacena una conexión de tipo SqlConnection (proveedor de conexión para SQL Server integrado en Microsoft .NET). Vamos a añadir una propiedad a la clase:

public static SqlConnection Connection
{

get { if (__connection == null) { __connection = new SqlConnection(connection_string); __connection.Open(); }

}

Como podemos apreciar, la propiedad creada es de solo lectura: queremos que la conexión quede solo definida por el interior de nuestra clase, aislandola del resto de la aplicación.

Por el momento, todo parece correcto, especialmente para aquellos que estén familiarizados con aplicaciones basadas en Windows Forms, donde este tipo de trabajo es oportuno y francamente útil.

El problema viene cuando lo utilizamos en una aplicación ASP.NET: imaginemos un usuario que entra por primera vez en la página. Al realizar su petición al servidor, ésta será ejecutada, y de no existir una instancia para la variable estática, se creará un objeto SqlConnection y se abrirá la conexión con la base de datos SQL Server.

Ahora bien… Otro usuario, casi de manera simultánea pero unos microsegundos después, solicita al servidor otro acceso. El código ASP.NET, volverá a comprobar la existencia de la variable de conexión, que ya estará instanciada y por tanto no realizará ninguna otra gestión sobre la conexión. Ahora bien… el código ejecutará sus consecuentes peticiones de datos y… ¡peligro! Dos usuarios están usando la misma conexión con la base de datos.

Pese a ser un modo bastante elegante de centralizar la gestión de conexiones, es mortalmente peligroso para aplicaciones web concurrentes. Por lo tanto, pasaremos a la siguiente opción.

Aunque pueda parecer una opción menos eficiente frente a la anterior, la mejor opción bajo mi punto de vista es crear una instancia de la conexión SqlConnection para cada consulta que vayamos a realizar, la abramos, ejecutemos la petición a la base de datos, y luego la cerremos:

SqlConnection cnx = new SqlConnection(connection_string);
cnx.Open();
SqlCommand cmd = new SqlCommand(“SELECT COUNT(*) FROM table_of_clients”, cnx);
object obj = cmd.ExecuteScalar();
/* … */
cnx.Close();

Como vemos, estamos creando una instancia de la conexión para realizar una consulta por lo demás simple, que se abre y se cierra para lanzar la petición a la base de datos. Puede parecer redundante y una pérdida letal de recursos, con una inclusión indiscriminada de líneas extra en el código fuente de nuestra aplicación.

Pero, en el caso de una aplicación web de cierta complejidad donde deban lanzarse varias consultas en una misma petición del usuario al servidor web, ¿es una buena práctica abrir y cerrar la conexión tantas veces? ¿es eficiente?

La respuesta es si. Gracias a las capacidades de connection pooling de ASP.NET y SQL Server ganaremos en eficacia y calidad sin perder recursos por el camino. ¿En qué consiste el connection pooling? Lo explicaré en el próximo post de mi blog, donde podreis comprobar su funcionamiento con algunos ejemplos sencillos que espero os sean de utilidad.

Una cosa os aseguro: ganareis, de lejos, numerosas ventajas frente a otros métodos tradicionales de trabajo.

Bookmark

Uno de los grandes retos a la hora de abordar el desarrollo de una aplicación software es la gestión de los errores que puedan producirse durante su explotación o incluso durante la fase de desarrollo.

Podemos diferenciar varios tipos de errores:

1. Errores sintácticos de programación. Estos son detectados por el compilador como situaciones que violan las reglas de implementación del lenguaje que estemos utilizando.
2. Errores conceptuales de programación. Errores cometidos en la definición de algoritmos que llevan a situaciones no previstas.
3. Errores en tiempo de ejecución. Derivados de los errores conceptuales, son los que nacen de resultados no previstos.
4. Errores de planificación. Suceden cuando se pone poco empeño durante la fase de análisis y definición de un proyecto, y es especialmente visible en proyectos web, donde (generalmente) el número de archivos de código es mayor que en una aplicación de escritorio y son más dificiles de depurar.

Por suerte, hoy en día cualquier lenguaje que utilicemos cuenta con las herramientas necesarias para poder detectar los errores de los puntos 1, 2 y 3.

El más clásico es, por supuesto, la estructura try. Un ejemplo en C#:

try
{ /* Código que está siendo probado */ }
catch (Exception ex)
{ /* Código ejecutado si se produce una excepción */ }

Ahora bien, cuando estamos trabajando en una aplicación web con ASP.NET 2.0, puede que queramos realizar una gestión de errores a nivel de aplicación sin necesidad de tener que controlar cada zona del código mediante estructuras de control de excepciones.

Aquí voy a presentar el modo que yo prefiero utilizar, y que bajo mi experiencia, es el más cómodo y útil.

Para capturar los errores que se produzcan dentro de nuestr apalicación, utilizaremos el fichero Global.asax, que si no lo teneis en vuestro proyecto, podeis añadirlo en el propio directorio raíz. En él, si no lo tenemos ya, añadiremos una función de la siguiente forma:

void Application_Error(object sender, EventArgs e)   { }

Cada vez que se produce una excepción no controlada dentro de nuestra aplicación web se llama a este evento de manera automática. Hay que tener en cuenta que si bien de esta manera capturamos el momento en que se produce un error, no tenemos una manera directa de acceder a la información del mismo, por lo que usaremos esta otra secuencia para recoger el objeto de excepción:

Exception ex = Server.GetLastError().GetBaseException();

Como podeis ver, ahora ya podemos acceder a toda la información que nos trae el objeto de excepción en su instancia, que hemos llamado ex.

Ahora podemos tomar varios caminos:

1. Mostrar un mensaje de error al usuario.
   1. Genérico: configurable desde el fichero web.config, como veremos a continuación.
   2. Detallado con el error: no es recomendable, pero podemos imprimir en pantalla los datos del error (procedencia, mensaje, seguimiento de pila de llamadas…)
2. Registrar el error en Windows.
3. Enviar un correo electrónico al administrador.

Primero veamos el caso 1. Para poder activar una página genérica donde acudan los navegadores de nuestros usuarios cuando se produzca un error, modificaremos una serie de parámetros en el fichero web.config, en concreto los referentes a la etiqueta customErrors:

<customErrors mode=”RemoteOnly” defaultRedirect=”~/pagina-no-encontrada.aspx”>
<error statusCode=”404″ redirect=”~/pagina-no-encontrada.aspx”/>
<error statusCode=”500″ redirect=”~/error.aspx”/>
</customErrors>

El este pequeño ejemplo, estamos indicando al servidor IIS el modo en que debe atender las diferentes situaciones que puedan darse, concretamente para dos casos muy comunes: no localizar una dirección (código 404) o detectar un error en tiempo de ejecución (código 500).

• customErrors: permite configurar el modo en que se atiende un error.
  • mode: modo en que debe comportarse el servidor de cara al error a la hora de mostrarlo
    • on: mostrar una página de error genérica (o la indicada como por defecto para el error sucedido)
    • off: mostrar cascada de error completa (PELIGRO DE SEGURIDAD, usar solo durante depuración y desarrollo), donde veremos una descripción detallada de lo sucedido
    • RemoteOnly: mostrará una página de error genérica (o la indicada)
  • defaultRedirect: lugar al que será enviado el usuario si no se indica nada para el suceso acontecido
• error: condición para un error concreto
  • statuCode: código del error acontecido (po ejemplo… 200=OK; 301=movido; 404=no encontrado; 500=error de ejecución)
  • redirect: página donde deberá ser llevado el usuario cuando suceda ese tipo de error

Ahora bien, si lo que queremos es poder realizar un tratamiento propio del error desde el fichero global, debemos tener en cuenta que lo anteriormente explicado, es decir, las instrucciones insertadas en el fichero de configuración web.config, se ejecutarán inmediatamente después de lo indicado en la función Application_Error salvo que le indiquemos lo contrario con la llamada a Server.ClearError(); , que retirará el error de la aplicación e ignorará lo aparecido en el fichero de configuración.

Tratemos ahora los otros dos casos: registro en Windows y envío por email.

Para registrar una excepción en el registro de Windows, podemos usar: (comprobando antes de nada que hayamos añadido al fichero System.Diagnostics)

EventLog.WriteEntry(“Test Web”,
“MESSAGE: ” + ex.Message +
“\nSOURCE: ” + ex.Source +
“\nFORM: ” + Request.Form.ToString() +
“\nQUERYSTRING: ” + Request.QueryString.ToString() +
“\nTARGETSITE: ” + ex.TargetSite +
“\nSTACKTRACE: ” + ex.StackTrace,
EventLogEntryType.Error);

Pero una cosa nos debe quedar muy clara: tras usar esto, la función en la que estamos será anulada instantáneamente, por lo que si queremos realizar cualquier otro tipo de atención a la excepción en la función Application_Error deberemos de hacerlo antes de llamar a EventLog.WriteEntry.

Si lo que deseamos es enviarnos el error por email, cosa que yo personalmente encuentro soberanamente útil, podremos usar: (haciendo uso de System.Net y System.Net.Mail)

string origen = “direccion@origen-de-aplicacion.com”;
string destino = “correo@electronicodedestino.com”;
string titulo = “Error de ejecución”;

string cuerpo = “<h2>Informe de error</h2>Fecha-hora: ” + DateTime.Now.ToString(“dd/MM/yyyy – HH:mm:ss”);

cuerpo += “<h3>Mensaje</h3>” + ex.Message + “<h3>StackTrace:</h3>” + ex.StackTrace + “<h3>TargetSite:</h3>” + ex.TargetSite;

MailMessage mensaje = new MailMessage(origen, destino, titulo, cuerpo);
mensaje.IsBodyHtml = true;   //Si hemos añadido etiquetas HTML
SmtpClient smtp = new SmtpClient(“mismtp.midireccion.com”);
smtp.Timeout = 6000;
smtp.Send(mensaje);

Si teneis alguna duda o pega, no dudeis en comunicarmelo. Intentaré extender más este tipo de minitutoriales de ASP.NET y C#.

Bookmark

La elección de hoy en día en muchas empresas y ámbitos de diseño y desarrollo web: Flash o Silverlight.

¿Es la nueva plataforma de Microsoft, conocida como WPF/e (Windows Presentation Foundation everywhere) “Silverlight“, lo suficientemente fiable y extendida por Internet como para poder ser utilizada de manera profesional en las creaciones para nuestros clientes?

Mi respuesta es un “si pero aun no”. Creo que Silverlight es una auténtica maravilla, y personalmente lo prefiero antes de decantarme por usar Flash, en especial por su integración con XAML y la facilidad que dá a los programadores para interactuar de lleno en la presentación de datos desde diferentes fuentes, y optar por una presentación gráfica de última generación sin necesidad de ser unos auténticos expertos en diseño: gracias a diferentes herramientas existentes, como Microsoft Expression, podemos separar las fases de diseño y desarrollo en diferentes ramas del proyecto, permitiendo que cada persona se centre en aquello de lo que es experto: un diseñador gráfico, en la preparación del interfaz; un programador o desarrollador, en la implementación de eventos, animaciones interactivas o carga de datos.

Ahora bien: ¿realmente podemos explotarlo, hoy por hoy, para nuestros desarrollos de cara a clientes? Como ya he dicho, y por desgracia, aún no. Si para muchas personas el plugin de Flash es algo desconocido, imaginaros lo que pensarán de Silverlight. El porcentaje de personas que conocen Silverlight es, hoy por hoy, muy reducido.

Por ello, la mayor parte de los usuarios de Internet desconocen esta nueva tecnología y no podrán ver los contenidos que hagamos, incluso dejandoles instrucciones para la instalación de los plugin: gran cantidad de personas son poco diestras a la hora de realizar instalaciones o comprender si quiera su funcionamiento.

Creo firmemente que Silverlight triunfará y llegará lejos, y alcanzará un punto en el que conviva junto a su primo lejano Flash, pero para eso queda aun un buen trecho por recorrer. Y seamos sinceros, puede ser peligroso inclinarse al uso de esta tecnología hoy en día cuando aun está tan poco extendida.

Y reconozco que Flash tiene muchas virtudes: gracias a su nueva versión de Flash Flex (si bien se la define únicamente como Flex y la presentan de manera independiente a Flash) se aproxima paso a paso al modelo de desarrollo utilizado para Silverlight mediante la separación de las ramas de los proyectos de creación entre diseño y programación, además de añadir cualidades que permiten formar nuevas y excitantes experiencias de tipo RIA, de las que hablaré más adelante en este mismo blog.

Todo se andará…

Bookmark

Son muchas las empresas hoy en día dedicadas al diseño web pero, ¿qué clase de oferta puede ser más rentable para según qué negocio?

Muchos nuevos emprendedores necesitan lanzar su presencia en Internet, pero carecen del tiempo, los recursos, o incluso de los conocimientos necesarios para hacerlo. Por ello, suelen recurrir a terceras personas o empresas para realizar esta tarea, con toda su ilusión y ganas de comenzar, para de pronto toparse con numerosos problemas: la inexperiencia del sector, plagado de personas que creen saber crear una web; la sobrecarga de trabajo en empresas con buenas capacidades pero mala distribución de recursos; la falta de entendimiento entre ambas partes, y toda una lista de sucesos similares.

Por supuesto, Santander (Cantabria) no es una excepción. Pese a no ser una ciudad de carácter verdaderamente industrial o tecnológico, siempre existirá la necesidad de personas que orienden su vida profesional hacia el diseño y desarrollo web, aunque se vive una extraordinaria sequía en lo que a verdaderos profesionales se refiere.

La accesibilidad, esa gran olvidada. El diseño estudiado en base al sector de la empresa que representa, ha pasado a la historia. El correcto maquetado, siguiendo los estándares del W3C, nunca se supo de él.

¿Qué sucede en nuestra ciudad? ¿Qué sucede en España en general? ¿Es una carencia personal de los profesionales que se aplican en éste sector, o es un fenómeno socioeconómico autoinducido?

Francamente creo que la base del problema es social. El desprestigio de los profesionales informáticos en la España moderna, unido a la cada vez más pobre formación en aspectos básicos de Internet en facultades y centros de estudios, está llevando a una perdida cada vez mayor de las capacidades de elaboración de proyectos de calidad del sector.

No deja de ser una lástima que esto se mezcle con otro factor decisivo: la falta de profesionales cualificados para lidearar a los equipos de diseño y desarrollo, especialmente en puestos directivos encargados de la toma de decisiones, comienza a acabar con la poca eficacia y confianza de entre las empresas dedicadas al diseño y desarrollo web.

La solución a un problema tan critico está lejos de alcanzarse, especialmente por la dificultad inherente de convencer a la sociedad de la necesidad de poseer curtidos informáticos, y esto pasa antes de nada por aceptar la profesionalidad de estos profesionales y asimilar su importancia y relevancia. Mientras se siga despreciando la profesión y los estudios informáticos, degradandolos a una ingeniería de segunda categoría, no habrá salida definitiva.

Bookmark

Otro dia más ha llegado y se ha marchado en el universo de nuestra empresa. Otra vez una batalla sin victoriosos ni perdedores. Otra jornada de ineficacia y frustración.

Creo que a los emprendedores con mi personalidad, pese a que tienen ideas brillantes e imprimen un esfuerzo sobrehumano en lo que hacen, nos pesa demasiado el mando y tendemos a debilitar la fuerza de nuestro bastón. Quizá nos inclinamos demasiado hacia la complacencia, ya sea para nosotros o para los que tenemos en nuestro entorno.

Bookmark

¿Qué es la Idea Feliz? (parte 1)

En el mundo emprendedor, podemos definir la idea feliz como aquella que nace de pronto, como una explosión en nuestra cabeza, y que nos arrastra a un estado de euforia descontrolada que inevitablemente nos acabará llevando a cometer una estupidez: comenzar a producir esa idea sin pensarlo bien antes de nada.

¿Por qué es una estupidez seguir una idea feliz?

Como su propia definición indica, una idea feliz nace de modo espontáneo y se ejecuta de un modo igualmente irracional. Hay que tener cuidado con ellas, pues suelen ser de carácter seductor y atractivo, ¡saben cómo convencernos de hacerlas caso!

Pero por desgracia, por muy buena que sea la idea, nos va a llevar siempre a seguir unos pasos bien determinados, que comienzan por lanzarnos a toda prisa a llevarla a cabo y terminan con el fracaso y desgaste total del proyecto:

Fases del desarrollo de la Idea Feliz

1. Idea feliz
2. Euforia
3. Intento de análisis infructuoso. La euforia nos pone nerviosos y nos saltamos el análisis. ¡No hay tiempo que perder!
4. Comienzo de del proyecto Idea Feliz
5. Avance aparentemente bueno de la Idea Feliz. Su duración depende de muchos factores asi que no es predecible.
6. Empiezan a aparecer los problemas: aquellos que no se vieron en un inicio.
7. Arrepentimiento de la falta de un análisis.
8. Arrepentimiento de haber empezado.
9. ¡Oh dios mio! ¡¿Dónde me he metido?
10. Catástrofe. La motivación y confianza personal desciende por debajo de cero.
11. Negación. ¡Yo puedo! ¡Yo puedo!
12. Negación doble. No he fracasado + la idea no fué mia / la culpa es de otro / no he tenido apoyo / me duele el dedo gordo de la mano derecha.
13. Fin del proyecto Idea Feliz.

Tras el punto 13 la o las personas que comenzaron el proyecto han terminado con su paciencia, esperanza, ambición, ganas, y seguramente su amistad mutua.

Éste principio excelente y su anunciado final no son fruto de la idea en sí, si no de su naturaleza feliz. Cuantos más proyectos desarrollo y planifico, más me doy cuenta de la necesidad de realizar un análisis previo exhaustivo, que cubra todos los previstos que puedan suceder y todos los factores que puedan dificultar el llevar a cabo nuestro proyecto.

Uno de los procesos que más influyen en la fabricación de una idea feliz es, por supuesto, su atractivo. En el mundo de la tecnología, por ejemplo, suelen ser ocurrencias con un aspecto muy avanzado, perteneciente a algunas de las élites tecnológicas de moda en la actualidad (cibernética, web 2.0, domótica, localización geográfica, redes sociales…). ¡Por favor! ¡Es imposible que esto salga mal! ¡Es una idea aplastantemente inteligente! ¡Es un negocio redondo!

Por lo tanto, por favor, repetir todos conmigo…

• No buscaré la idea feliz.
• El Dorado no existe
• Haré un análisis previo a cualquier idea medianamente trascendental que tenga antes de ejecutarla
• Cuando alguien me intente convencer de llevar a cabo una idea feliz o me presione para tomar decisiones importantes en un margen de tiempo ridiculamete reducido… ¡Me negaré!
• Cuando me metan prisa para decidir usando argumentos como “debes aprender a tomar decisiones” o “no veo otra salida, es esto o nada, yo sé lo que me digo“… ¡Me negaré!

Como consejo personal, sobre estos dos últimos puntos, tengo un consejo muy importante para todos: las personas que nos presionan para tomar decisiones trascendentes de manera rápida en base a ideas que ellos mismos han hecho, generalmente intentan vendernos la moto y buscan un apoyo al que agarrarse. No os echeis a sus brazos: si su idea fuera tan buena, no necesitaría convenceros. Ante la duda… calma.

En la segunda parte de este post, que escribiré más adelante, me gustaría presentaros casos y ejemplos claros de ideas felices, en especial aquellas que me he encontrado en mi camino. Algunas os llamarán soberanamente la atención: ¡os lo puedo asegurar!

¡Saludos!

Bookmark