moure.es – Alfonso Moure Ortega

¿Alguna vez habéis querido llamar a métodos PHP desde el lado del cliente mediante AJAX? Pues bien, es bastante sencillo y voy a explicarlo de un modo rápido. Puntualizo que para la comunicación usaré el formato JSON (Javascript Object Notation) para la toma y devolución de datos.

Para facilitar las peticiones usaremos jQuery, que ya trae en sí todo lo necesario para poder realizar este tipo de petición. Primero vamos a crear una función en PHP que multiplique dos números, tal que así:

function Multiplicar(a,b) { return a*b; }

Hasta aquí supongo que todos hemos llegado. Ahora viene lo divertido… Creamos la parte de cliente, en Javascript, una vez hayamos incrustado la librería de jQuery en nuestra página:

function DoMultiplicar(p_a,p_b)
{
$.post(ruta_al_servicio, {a:p_a,b:p_b,cmd:”multiplica”},
function(data)
{
eval(“var obj = ” + data + “;”);
alert(data.result);
}
, “json”);
}

Y procesamos la petición en PHP:

if ($_POST["cmd"] == “multiplica”)
Multiplicar($_POST["a"],$_POST["b"]);

Vale, pero, ¿qué ha hecho todo esto? Pues muy sencillo… Por la parte de Javascript, hemos llamado al método $.post, al cuál le hemos pasado como parámetros, en el mismo orden:

• Ruta al servicio: ruta absoluta al fichero PHP que controla la petición por POST, y que se encarga de la llamada al método Multiplicar.
• Parámetros: mediante la notación de objetos de Javascript (JSON), introducimos los difentes parámetros que usará nuestro script de servidor. Para los que no estén familiarizados con JSON, es un protocolo de declaración de objetos de Javascript, que permite crear una estructura de objeto mediante una cadena sencilla, rodeada por llaves, donde cada miembro se separa por comas. Para más información, consultar la página oficial de JSON, donde apareden numerosos ejemplos con los que aprender.
• Método callback: función que recoge, en este caso, el resultado de la petición. Lo hemos llamado data, pero podéis llamarlo como mejor os venga para vuestro trabajo: el parámetro que recibe será siempre la respuesta del servidor.

Una vez recogido el resultado con el callback, ya lo tenemos: el resultado de la multiplicación. Si tenéis dudas, no tengáis problema en dejar comentarios… aunque sé que este pequeño tutorial es sencillo y básico para muchos , puede que para otros no tanto.

Bookmark

Bueno, tengo esto bastante abandonado la verdad…

Tengo demasiado trabajo y demasiadas cosas en la cabeza.

En general, muchas de esas excusas que los blogger más adustos suelen utilizar para defenderse a las críticas sobre lo poco que actualizan. Pero, en serio, no me olvido de mi querido blog… ¡habrá que retomarlo!

Para darle salsa al nuevo año, y dado que todo el mundo me pregunta día sí, día también, sobre dudas de todo tipo (programación, desarrollo, SEO, Internet…) he decidido crear Wikimou, una wiki que intentará solucionar muchas de esas dudas que me preguntan. Cada vez que resulva algo en desarrollo que me parezca interesante o cuando me pregunten algo importante, intentaré publicarlo aquí para que quede constancia de ello.

Por supuesto, se aceptan colaboraciones en toda su temática:

• Desarrollo
• SEO
• Trucos de programación
• Internet
• Técnicas sociales
• Problemas técnicos de todo tipo
• Google
• API

Os invito a todos a participar en el proyecto. ¡Juntemos todas nuestras proezas! ¡Aprendamos de nosotros mismos y dejemos a los demás acompañarnos!

Bookmark

A veces queremos utilizar palabras reservadas dentro de un listado de valores de un enumerado (enum) dentro de nuestro código C#. Hoy un compañero me ha preguntado cómo hacerlo, y tras repasar mis chuletas mentales, almacenadas en memoria secundaria en lo más profundo de mis sesos, recordé la forma: poniendo el modificador @ delante del valor igual a la palabra reservada. Por ejemplo:

enum Languages {es, @as, @in, en, zh};

Ya no hay excusas: no habrá que usar strings “a pelo” en nuestras serializaciones de datos (XmlSerialization).

Bookmark

Adiós al tradicional método de convertir un string en enum utilizando un eterno switch en C#… Viejos tiempos en los que debíamos hacer algo similar a…

switch(saludo)
{

case “hola”: return Saludos.Hola;
case “hello”: return Saludos.Hello;

}

¿Quién no ha hecho este tipo de aberración alguna vez durante su vida como desarrollador? Todos…

Afortunadamente me he topado con un sistema muy interesante, que prácticamente podemos definir como evidente (¿Cómo no se me pudo ocurrir antes?) para realizar la conversión sin tener que hacer uso de un switch del tamaño de 20 folios A4. Tan sencillo como ésto:

public Enum Saludos {Hola,Hello,Hi};

public Saludos GetSaludo(string saludo)
{

return (Saludos)Enum.Parse(typeof(Saludos), saludo);

}

De éste modo realizaremos la conversión de manera sencilla y práctica, con una única línea de código.

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

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