moure.es – Alfonso Moure Ortega

iGoogle Canvas es la nueva opción que los chicos de Google nos ofrecen a la hora de crear nuestros gadgets para iGoogle. ¿Cansados de poder usar tan poco espacio en vuestros gadgets? Solucionado.

La gente de Mountain View, tan atenta cuando es preciso a las peticiones de los desarrolladores que hacen uso de sus Google API, ha creado la opción Google Canvas View dentro de su modelado de aplicaciones para iGoogle, permitiendonos crear un apartado dentro del gadget orientado a dibujar en su canvas, pudiendo así ocupar todo el ancho del escritorio interactivo del usuario.¡Gracias Mountain View!

Espacio, espacio, espacio… esto es algo que siempre se ha pedido y que hasta ahora había sido poco más que un sueño eroticofestivo para muchos desarrolladores. Ahora por fin podremos explotar todo el ancho del navegador de nuestros usuarios gracias al iGoogle Canvas.

Por cierto, hay que denotar, que gracias a este cambio vamos a tener una buena maera de monetizar nuestros trabajos, ya que ahora tendremos espacio suficiente y las opciones apropiadas para añadir publicidad y Google Adsense dentro de nuestras soluciones.

¡Todos a programar!

Bookmark

Desde pasar variables en campos ocultos (hidden fields) hasta guardarlas como variables de sesión, pasando por enviar QueryStrings absurdamente largos. Estas son algunas de las salidas que muchos programadores utilizan para poder pasarse información entre diferentes callbacks en ASP.NET, para conservar valores de variables o datos de los usuarios. ¿Os imagináis guardar datos personales de los usuarios en campos ocultos HTML? Aberrante.

Algunas personas utilizarán otros métodos, pero yo os voy a sugerir mi preferido y el que más uso normalmente. Es recomendable no usarlo en situaciones donde la seguridad sea extremadamente importante, pese a que decodificar la cadena del ViewState en el resultado renderizado de la página sea un acto casi faraónico.

Mi propuesta es la siguiente: muchos queremos poder mantener el estado y contenido de nuestras variables entre un callback y el siguiente, de manera sencilla y cómoda. Para ello vamos a usar el ViewState.

Para los profanos: ¿qué es el ViewState?

Cuando uno programa en ASP.NET, comunmente utiliza eventos para controlar la interacción de los usuarios clientes en la página. Estos eventos nos permiten detectar, por ejemplo, cuándo un usuario selecciona una opción de un desplegable DropDownList. Cuando el cliente hace ésto, por arte de magia el código de lado de servidor recibe un mensaje que lanza un método señalado como capturador del evento. Por ejemplo:

Código ASP.NET:

<asp:DropDownList runat=”server” ID=”dropdownPrueba” OnSelectedIndexChanged=”procesarCambio”>
<asp:ListItem Text=”Opción 1″ Value=”1″></asp:ListItem>
<asp:ListItem Text=”Opción 2″ Value=”1″></asp:ListItem>
</asp:DropDownList>

Código C#

protected void procesarCambio(object sender, EventArgs e)
{
Response.Write(this.dropdownPrueba.SelectedItem.Text);
}

Fijaros bien en algo. En la función C# anterior, estoy recogiendo el texto contenido en el item seleccionado en el desplegable. ¿Cómo sabe ASP.NET lo que está seleccionado? ¿Cómo sabe los items que había antes en el desplegable? La pregunta tiene fácil respuesta: el ViewState.

El ViewState es el modo en que ASP.NET guarda el estado general de una aplicación web dentro del ámbito de una misma página y sus consecuentes callbacks. Automáticamente, guarda el estado de todas las variables de los controles de usuario ASP.NET (siempre y cuando tengamos activada la opción EnableViewState en el control), de manera que se conservan y son accesibles en cada callback de la página.

Pero, ¿cómo puede esto servirnos para guardar datos entre una llamada a servidor y otra? Los chicos de Redmon nos han dejado una pequeña puerta trasera para acceder al ViewState e introducir y recuperar información.

Su uso es bien sencillo: podemos acceder al ViewState como una variable estática global, de la siguiente manera y desde cualquier punto de nuestro proyecto web:

Código C#

//Introducimos un dato en el ViewState…

ViewState["midato"] = “vamos a guardar esto en el ViewState de la página”;

//y ahora lo recuperamos

string este_era_el_dato = ViewState["midato"];

Por supuesto, podéis probar esto y añadir cada línea en callbacks diferentes para poder comprobar su correcto funcionamiento.

Mi sugerencia

Cada desarrollador tiene sus propias manías, y yo no soy una excepción. Por ello, conservo determinados valores entre diferentes llamadas del servidor cuando es necesario y apropiado. Aquí os dejo un ejemplo:

private string __variable;

public string Variable
{
get { if (ViewState["variable"] != null) return ViewState["variable"].ToString(); else return this.__variable; }
set { ViewState["variable"] = value; this.__variable = value; }
}

De esta manera, si haceis uso de la propiedad llamada Variable en cualquier punto de la clase, ésta se conservará entre callbacks. Recordad que, aunque la propiedad Variable, aunque la haya definido como pública, podeis usarla como prefiráis (private, protected…). No useis la variable __variable, pues será sobreescrita por la propiedad cada vez que la llaméis, no es más que un punto de control.

Como nota personal, siempre tiendo a encerrar este tipo de composiciones en una misma región, quedando mucho más organizado y ordenado.

Bookmark

Aunque muchos de vosotros ya conoceis Photosynth de Microsoft, quizá aun no hayais visto sus cualidades, especialmente aquellas que ha presentado la corporación en Siggraph 2008. Aquí os dejo el video para que alucineis.

Photosynth es un nueva proyecto de Microsoft Live Labs que, haciendo uso de las brillantes cabezas de los genios con los que cuentan en Redmond, permite a los usuarios subir fotografías tomadas desde diferentes ángulos y crear presentaciones tridimensionales del espacio fotografiado mediante métodos de interpolación. Increible, ¿verdad?

Pues si veis el video que adjunto, alucinaréis más aún. Imaginaros poder meter vuestras fotografías del verano y poder verlas integradas junto con un escenario realista del mundo, sumergiendoos en un escenario virtual mundial.

¿A dónde puede llevarnos esto? Sinceramente, estoy deseando que saquen una API de Photosynth para poder trabajar sobre ella. Investigando un poco, he encontrado un mashup impresionante de Photosynth con VirtualEarth de Microsoft. Personalmente, no he trabajado demasiado con Virtual Earth, y me considero un total entusiaste de aplicaciones de Google como Google Maps o Google Earth, con las que trabajo casi a diário en Muchoviaje, pero he alucinado. No tardaré demasiado en hacer experimentos con Photosynth y Google Maps.

Hay un factor que me preocupa. Actualmente Microsoft deja a los usuarios que se registren en la comunidad, suban sus fotos y preparen sus aplicaciones Photosynth, dandonos la nada desdeñable capacidad de 20GB para nuestras fotos, pero… ¿creará una verdadera API que pueda ser usada a nivel corporativo? ¿podremos integrar Photosynth en nuestras aplicaciones a nivel industrial?

Sinceramente, espero que si.

Bookmark

Existen muchos paradigmas diferentes que pueden ser aplicados a la hora de diseñar la arquitectura de un producto software, al igual que muchas maneras de afrontarlo y subsanar sus problemas. Igualmente, hay multiples modos de enfocar las diferentes fases del desarrollo.

Personalmente tiendo a clasificar a las empresas de desarrollo en determinados grupos:

1. Desarrollo heróico :: aunque el término ya existe, usado para denominar a aquel grupo de desarrollo que intenta solucionar los problemas informáticos de manera individual y sin un planteamiento previo claro, donde el hecho de alcanzar el éxito estará marcado por la calidad de sus programadores a nivel individual y no colectivo. Este tipo de equipos suelen, por estadistica, tener una vida relativamente corta y bien sufrida, muy posiblemente por despreciar la calidad del equipo como un conjunto capaz de colaborar y trabajar como un ente único.
2. Desarrollo organizado sin calidad :: empresas donde existe una buena organización y cohesión interna pero un nivel tecnológico o formativo demasiado bajo como para sacarle un buen rendimiento. En este tipo de mercados quedarse atrás es peor que letal.
3. Desarrollo organizado de calidad :: empresas que lo tienen todo, desde buena organización hasta profesionales capaces de explotarla y sacarla partido.

Esto desde luego es únicamente referente a su capacidad de organizarse y aprovechar sus recursos humanos. Pero, ¿qué hay de las empresas que no aprovechan en absoluto sus virtudes técnicas? ¿Qué sucede con las empresas que alardean de utilizar .NET Framework pero no aprovechan ninguna de sus capacidades únicas?

Bookmark

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