PremoniSense, la gran novedad de Visual Studio 2010

Programa para la mejora de la experiencia del usuario Seguro que muchas veces te has preguntado qué es el “programa para la mejora de experiencia de usuario”, esa pantalla que nos aparece desde hace muchos años tras instalar Visual Studio (y otros productos de Microsoft), sugiriéndonos sutilmente que ayudemos a recopilar información del uso que damos a sus servicios y software.

En el encuentro de desarrolladores DevConn4 del pasado diciembre ya se oían rumores sobre el uso que estaban dando a esta información los chicos del laboratorio, y concretamente los investigadores del grupo Information retrieval and management, pero nada que pudiera ser tomado en serio en aquél momento.

El pasado uno de Abril, Dough Seven, Senior Product Manager de Visual Studio Team System en Microsoft, en el marco de las DSL’s Developers Conference, ya dejó caer que en la próxima versión de Visual Studio (la 2010) se introducirían “tecnologías que revolucionarían la forma en la que desarrollamos software e incrementarían la productividad de forma nunca vista”. Ahora, con el tiempo, se entiende que no se refería a nuevas plantillas, componentes o mecanismos de refactorización, se trataba de una pequeña pista de lo que se estaba cociendo en Redmon.

Visual Studio 2010, with Premonisense!Y por fin, cuando ya va quedando menos para lanzamiento oficial de Visual Studio 2010 (estaba previsto para el próximo mes de marzo, aunque ha sido retrasado), es el mismísimo S. Somasegar Vicepresidente Senior de la División de Desarrollo, el que ha desvelado el gran secreto: la tecnología PremoniSense™.

Tras este enigmático nombre se encuentra el resultado de recopilar pautas de comportamiento de decenas de miles de desarrolladores de todo tipo durante más de diez años y procesarlas mediante complejos mecanismos estadísticos e inteligencia artificial. Esto ha permitido desarrollar un motor de inferencia, alojado en la nube, capaz de analizar en tiempo real el uso que hacemos del entorno de desarrollo y adelantarse a nuestras acciones, automatizando gran parte de las tareas habituales de los programadores.

Cómo funciona

El modus operandi es el siguiente: cuando PremoniSense™ detecta un comportamiento conocido, aparece un cuadro describiéndonos cuál es el siguiente paso que vamos a dar en función de lo que hemos hecho hasta el momento; la base de conocimiento de la que obtiene esta información es tan amplia que estadísticamente se estima que el índice de error de sus predicciones el 0,1%, es decir, un fallo de cada 1000 acciones. Pero lo más interesante sin duda es que, dado que conoce perfectamente nuestras intenciones, nos ofrece la posibilidad de hacer el trabajo por nosotros automáticamente.

Áreas de interacción

De momento, esto que veremos en Visual Studio 2010 será únicamente un adelanto, por lo que sólo será posible disfrutar de él en tres áreas de actividad en el proceso de desarrollo de software: la arquitectura de aplicaciones, el desarrollo o implementación, y la calidad del software.

Se prevé que Visual Studio 2012 ya incluirá soporte de PremoniSense™ completo para otras áreas, como la ingeniería de requisitos, el despliegue o el soporte postventa.

Pero bueno, centrándonos en el presente, a continuación describo las áreas en las que esta tecnología estará presente en VS2010, con algunas capturas de pantalla de ejemplo que demuestran la increíble potencia de esta tecnología, que a veces sólo se puede describir con la palabra “magia”.

  • Arquitectura (Architectural PremoniSense™) 
    El motor de inferencia será capaz de detectar, en función del tipo de aplicación que estemos desarrollando, la arquitectura más apropiada a utilizar en cada momento, refactorizando el proyecto para adaptarse a la misma.

    Por ejemplo, si estamos creando una aplicación MVC con servicios de uso genérico será capaz de crear un proyecto independiente WCF capaz de permitir accesos securizados desde el exterior. Si observa que utilizamos procesos basados en flujos de trabajo, será capaz de mover el código a un proyecto independiente implementando dichos procedimientos con Workflow Foundation. Si detecta acceso a datos desde capas no permitidas (p.e., desde controladores en MVC), los trasladará a un proyecto independiente (el típico DAL, o capa de acceso a datos), actualizando las referencias automáticamente.

    Asimismo, será capaz de detectar funcionalidades duplicadas transversales al sistema (por ejemplo, acceso a logs, seguridad, gestión transaccional), extraer sus implementaciones e inyectarlas de nuevo utilizando técnicas propias de la programación orientada a aspectos (AOP), todo de forma automática.

    En teoría, el sistema soporta arquitecturas de hasta 7 capas, con posibilidad de entender y plantear soluciones integrando tecnologías tanto de Microsoft (como Sharepoint, Office, Exchange, WWF, EF, WCF, JASP, WPF, MVC, MVP o HTML) como open source (Rails, PHP, NHibernate, MySQL, Oracle, EJB, FSB, UPNP, ó MRW).

  • Desarrollo (PremoniSense™ for Code)
    El funcionamiento de PremoniSense™ en esta área es conceptualmente muy similar a las ayudas del IDE e incluso al soporte ofrecido desde herramientas externas como Resharper, el objetivo es ayudarnos a codificar más rápidamente y sin errores, pero llevado al extremo. Por citar unos ejemplos, ahí van los que más me han llamado la atención (podéis ver la lista completa en la documentación oficial):
    • Autogeneración de funcionalidades CRUD. Es decir, el sistema detectará cuándo estamos realizando un mantenimiento típico (altas, bajas, modificaciones y consulta) y lo implementará por nosotros. Para ello, analizará la estructura de la base de datos y creará el código más apropiado y correcto según su experiencia acumulada en el tipo de sistema de que se trate.
    • Autoasignación de propiedades. PremoniSense detectará cuándo estamos poblando las propiedades de un objeto y las establecerá por nosotros, determinando de forma automática el origen de la información. Por ejemplo, si estamos ante el clásico bloque de código para traspasar datos desde los campos de un formulario a una entidad, lo detectará y generará el código por nosotros; o en la implementación de un constructor con parámetros, asignará automáticamente los miembros internos coincidan con éstos.
    • PremoniStence, el nombre interno que han dado a lo que vendría a ser un “EF++”, que mantiene sincronizado el mecanismo de persistencia (¡sea cual sea!) con el resto de capas de la aplicación. Esto es realmente espectacular: por ejemplo, si ampliamos el tamaño de un campo de la base de datos, ya no hay que preocuparse por modificar los formularios, pues las propiedades de los controles visuales detectados por el motor se actualizarán de forma automática; o si cambiamos el nombre de una propiedad en una entidad, se actualizará el nombre del campo en la base de datos, e incluso las etiquetas de descripción a nivel de interfaz de usuario. Pero ojo, que no se trata de un mecanismo de binding o mapeo como los existentes en la actualidad, sino de un proceso totalmente automático que nos vigilará continuamente e irá realizando estas tareas de forma silenciosa.
    • Autoimplementación de métodos, que utiliza la gigantesca base de conocimiento acumulado durante años para implementar métodos de forma automática, basándose únicamente en su nombre y signatura (parámetros de entrada y tipo de retorno). Por ejemplo, ya no será necesario implementar más el clásico método “long factorial(long n) ”: él lo hará por nosotros :-))

      Premonisense: auto-implementación de métodosComo puedes comprobar, PremoniSense™ además nos regala la reaparición estelar de nuestro viejo amigo Clippo, esta vez disfrazado de adivino. Al parecer se trata de un guiño de los desarrolladores de Visual Studio al equipo de Office… humor friki, supongo ;-D

    • Simplificación de algoritmos, un mecanismo capaz de replantear el código de métodos complejos, reescribiéndolos de forma más simple y mantenible de forma automática, basándose en los parámetros de entrada, los resultados de salida y el análisis semántico del procedimiento implementado. Internamente se conoce como PremoniKiss, por las iniciales de KISS, el famoso principio para el desarrollo de software que aboga por la simplicidad de las creaciones.
    • En la misma línea, PremoniYagni, un detector prematuro de funcionalidades y características inútiles, que nos alertarán cuando estemos comenzando a introducir en nuestras aplicaciones características que estadísticamente se conoce que no son utilizadas por los usuarios, o estemos entrando en el pantanoso terreno de la sobreingeniería. YAGNI son las iniciales de You ain’t gonna need it (“no vas a necesitarlo”).
    • Detección automática de dominios de aplicación, personalizando su comportamiento para hacer la experiencia de desarrollo más liviana. Así, una vez inferido el dominio del sistema, será capaz de generar automáticamente las entidades de datos, gestores, e incluso lógica de negocio más apropiada, y adaptar sus deducciones, consejos y acciones a dicho dominio.

    Algo realmente interesante de PremoniSense™ for Code es que el código que genera es dinámico, es decir, que es capaz de seguirle el rastro y modificarlo de forma automática cuando se produce algún cambio en las premisas de las que partió en el momento de inferir su generación, manteniéndolo siempre actualizado y correcto.

  • Calidad (PremoniSense™ for Quality)
    PremoniSense™ también está preparado para utilizar su enorme base de conocimiento con objeto de incrementar exponencialmente la calidad de nuestras aplicaciones en varios ámbitos. Por citar algunos:
    • Generador de pruebas unitarias, que utilizará la base de conocimiento para generar por cada clase un set de pruebas de unidad  lo suficientemente extenso como para asegurar que son mayormente correctas. Basado inicialmente en el proyecto Pex de Microsoft Research, incrementa la calidad del código hasta niveles nunca vistos anteriormente, puesto que las pruebas serán generadas teniendo en cuenta el dominio de la aplicación y los fallos que se suelen producir en cada uno.
    • Autodocumentador de diseño, aunque sólo disponible para los poseedores de la próxima suite Office 2010, que creará partiendo de plantillas prediseñadas todo el juego de documentación de diseño de la aplicación, siguiendo los estándares definidos por diversas metodologías (entre las que se encuentra, curiosamente, Métrica 3).
    • Como una extensión del punto anterior, pero que vale la pena destacar de forma independiente, PremoniSense™ será capaz de generar un borrador de manual de usuario del sistema, basándose principalmente en tres factores: el conocimiento del comportamiento de los usuarios acumulado durante años, el interfaz que se haya creado y las funcionalidades implementadas. Obviamente, no nos dará todo el trabajo hecho, pero lo que hasta ahora se trataba de una ardua tarea de redacción se reducirá a un simple repaso y retoque de los textos.
    • Detección de procesos no finitos, que se acerca a la solución del clásico problema de la parada para máquinas de Turing, utilizando el motor estadístico de PremoniSense™ para determinar cuándo los algoritmos empleados en un sistema presentan incorrecciones que le harán entrar en un bucle infinito, antes de que esto se produzca. 

      Detección de procesos no finitos

    • Detección de publicación prematura, se trata de un mecanismo de control sobre la base de código capaz de determinar cuándo un producto está suficientemente maduro para ser publicado (o desplegado a un servidor en producción) en función de su complejidad, número de pruebas funcionales y unitarias realizadas, y la extensa base de experiencias anteriores.

En resumen, que en breve vamos a asistir a lo que será, en mi opinión,  el avance más significativo para los desarrolladores desde la invención del copiar y pegar. Los vídeos que aparecen en el sitio oficial son simplemente espectaculares, no te los pierdas; si quieres pasar unos buenos ratos en estos días de fiesta, puedes descargar este software en la web de Microsoft. Pero ojo, si puedes, ve aumentando tu RAM, que PremoniSense™ se adueñará de 2GB cuando esté en ejecución. 

[Actualizado 29/12]
Obviamente la noticia no es real, se trata simplemente de una broma del Día de los Inocentes. Pero molaría que fuera verdad, ¿eh? ;-DD

Publicado en: Variable not found.

Crossposteado desde PremoniSense, la gran novedad de Visual Studio 2010 @ Variable not found

Disponible ASP.NET MVC 2 Release Candidate

 

ASP.NET MVC 2 RC disponible Recién salida del horno, tenemos ya la versión candidata de ASP.NET MVC 2, la última antes de la versión final que aparecerá antes de marzo, el mes previsto para el lanzamiento de Visual Studio 2010.

Como indica Haack en su post, la mayor parte del trabajo se ha centrado en corregir bugs e introducir mejoras a funcionalidades existentes, como:

  • relativas a la validación en cliente:
    • separación de los scripts de validación a un único archivo, que puede ser incluido en cualquier parte de la vista.
    • soporte para la globalización de mensajes.
    • mejora de Html.ValidationSummary() para que soporte mensajes de error a nivel de modelo, y no vinculados a campos concretos.
    • se permite la inclusión de botones que se salten la validación de formularios.
    • se permite especificar cuándo se ejecutan las validaciones: mientras el usuario teclea, cuando se pierde el foco en un control o sólo en el submit.
  • otras mejoras:
    • plantillas T4 que generan código según la versión del framework destino.
    • el código HTML generado por el diálogo “Add View” es consistente con los templated helpers.

Enlaces:

Rápidamente crossposteado desde: Disponible ASP.NET MVC 2 Release Candidate @ Variable not found  

Procesar peticiones a acciones inexistentes en ASP.NET MVC

Los controladores ASP.NET MVC que heredan de la clase Controller permiten procesar muy fácilmente las peticiones realizadas a acciones no definidas. Para ello, lo único que hay que hacer es sobrescribir el método HandleUnknowAction() e implementar la lógica que queremos que se ejecute en estos casos.

En el siguiente código, las peticiones realizadas a /Home/Index y /Home/About serán procesadas normalmente, pero /Home/BeberCerveza  será procesada por HandleUnknowAction, cuya  implementación mostrará la vista “Index” con un mensaje personalizado:

public class HomeController : Controller

{

    public ActionResult Index()

    {

        ViewData["Message"] = "Welcome to ASP.NET MVC!";

        return View();

    }

 

    public ActionResult About()

    {

        return View();

    }

 

    protected override void HandleUnknownAction(string actionName)

    {

        ViewData["Message"] = "¿Estás intentando " + actionName + "?";

        View("Index").ExecuteResult(this.ControllerContext);

    }

}

 

 

image

Alegremente crossposteado desde: Procesar peticiones a acciones inexistentes en ASP.NET MVC @ Variable Not Found

Borrado de registros con jqGrid y ASP.NET MVC

 

En un post anterior dedicado a jqGrid y ASP.NET MVC vimos lo sencillo que resultaba implementar un potente grid para mostrar datos tabulares, permitiendo paginación, ordenación y redimensionado de columnas.

Pero, como ya comenté entonces, jqGrid es mucho más que eso. En este artículo estudiaremos la implementación de la funcionalidad de borrado de filas integrada en el propio componente, utilizando intercambio de datos Ajax con el lado servidor para actualizar el modelo.

Partiremos del ejemplo que desarrollamos anteriormente, y nos centraremos únicamente en introducir los cambios necesarios para introducir esta nueva capacidad. También, como en el caso anterior, encontraréis al final un enlace al proyecto de demostración, para Visual Web Developer Express 2008 SP1 y ASP.NET MVC 1.0.

1. Preparamos la infraestructura

Selección de módulos en jqGridAntes de nada, y es algo que es importante recordar cuando trabajemos con jqGrid, debemos pensar qué módulos de este componente necesitamos en nuestro proyecto.

En el post anterior descargamos exclusivamente los necesarios para implementar la visualización del grid; ahora, dado que vamos a utilizar más funcionalidades del componente, debemos seleccionar en la herramienta de descarga aquellos que nos harán falta, el base y los relativos a la edición de datos.

En teoría deberíamos seleccionar los módulos estrictamente necesarios para nuestros fines, pero en la práctica no es fácil adivinar cuál de ellos implementa justamente lo que estamos buscando. De hecho, es bastante frecuente encontrarse con errores de script cuando no acertamos con el módulo exacto, al que siguen bastantes iteraciones prueba-error hasta que conseguimos averiguar cuál debemos indicar en la descarga.

Por eso en este caso, seleccionaremos todos los módulos relativos a la edición; eso nos permitirá, además, seguir implementando funcionalidades como el alta o la modificación sin tener que volver a descargar componentes.

Aparte de los módulos a incluir en la descarga, el resto de los pasos de preparación de la infraestructura son idénticos a los descritos en los puntos 1 al 3 del post inicial:

  • Copiar los archivos de script (jqGrid y el archivo de localización) en el proyecto.
  • Descargar el tema visual de jQuery UI y añadirlo al proyecto.
  • referenciar las librerías de scripts y estilos en la master (o vistas donde vayamos a usarlo).

2. El modelo

Vamos a ampliar la clase GestorDeAmigos anterior para que sea capaz de emular el almacenamiento en una base de datos, pero utilizando como soporte una colección en memoria que haremos persistir en una variable de aplicación. Además, aprovecharemos para añadirle un método Delete() que nos permita eliminar del almacén la persona cuyo “Id” le pasemos como parámetro.

public bool Delete(int id)

{

    Amigo amigo = DatosAmigos.FirstOrDefault(a => a.Id == id);

    if (amigo == null)

        return false;

 

    DatosAmigos.Remove(amigo);

    return true;

}

 
No profundizaré más en el modelo, pues el código es de lo más convencional. El que tenga curiosidad por ver cómo se implementa el almacén en una variable de aplicación, que acuda al fuente del proyecto de demostración.

 

3. La vista

En la vista debemos hacer muy pocos ajustes para permitir la eliminación de los datos. Básicamente, tendremos que habilitar un panel de botones en el grid, indicar que deseamos que aparezca el botón de eliminación, y configurar el comportamiento de éste, para lo cual invocaremos al método navGrid() después de la llamada de inicialización del grid que ya vimos el otro día:

<script type="text/javascript">

    jQuery(document).ready(function() {

    

        jQuery("#list").jqGrid({

            [...] // OMITIDO. Idéntico al del post anterior.

        });

 

        $("#list").navGrid(

                null,

                { refresh: true, add: false, edit: false, del: true, search: false },

                null, // parámetros para el alta

                null, // parámetros para la edición

                {     // parámetros para la eliminación

                    url: '<%= Url.Action("Eliminar") %>',

                    width: 500,

                    afterSubmit: function(r, d) {

                        return [r.responseText=="", r.responseText];

                    }

                }

        );

});

 

 

Los parámetros que estamos pasando al método navGrid() son los siguientes:

  • el primer parámetro debería ser jQuery('#pager'), que es la referencia hacia el control de paginación que estamos utilizando. En este caso es un nulo porque esta referencia se incluyó en la inicialización de jqGrid.
  • A continuación, creamos un objeto anónimo en el que establecemos a true las propiedades del y refresh, que indica que queremos mostrar los botones de eliminación y recarga de datos. El resto de propiedades predefinidas, add, edit, y search, equivalentes a los botones de añadir, editar y buscar registros, respectivamente, las establecemos a false con objeto de que no aparezcan botones para invocarlas; ya las activaremos en otros posts 😉
  • el siguiente parámetro se trata de un objeto donde configuramos el comportamiento del botón de alta de registros. Dado que no vamos a implementarlo ahora, lo establecemos a nulo.
  • el cuarto parámetro es lo mismo que el anterior, pero para configurar la edición, por lo que también se encuentra establecido a null.
  • a continuación, y por último, el objeto en cuyas propiedades definimos el comportamiento del botón de eliminación:
    • La URL a la acción que se invocará en servidor, que la obtenemos utilizando el UrlHelper de MVC. En este caso, invocaremos a una acción llamada “Eliminar”, a la que el sistema enviará el Id del registro activo.
    • El ancho del cuadro de diálogo de confirmación.
    • En afterSubmit implementamos una función callback que jqGrid llamará cuando haya recibido el resultado de la petición Ajax. El primer parámetro que nos envía es el objeto XMLHttpRequest donde encontraremos la respuesta obtenida desde el servidor; el segundo parámetro contiene los datos que han sido enviados a la petición.

      El retorno de la función callback debe ser siempre un array con dos elementos. El primero es un booleano indicando si la eliminación ha tenido éxito, y el segundo es el mensaje de error, en caso de que se haya producido:

      return [ exito , "mensaje de error" ];

      Es importante ahora resaltar una cosa: salvo los parámetros de entrada y el tipo de retorno descritos anteriormente, jqGrid no nos impone ninguna particularidad más respecto a cómo debemos implementar este método, el tipo de información que recibiremos desde el controlador o cómo la procesaremos al recibirla. Somos totalmente libres de elegir la forma en la que haremos las cosas.

      En nuestro caso, vamos a hacer una implementación muy simple en base a la siguiente convención: el controlador retornará un string con una descripción del error en caso de que se produzca algún problema borrando el registro, y retornará un nulo cuando todo vaya bien. Esto nos permite implementar el callback utilizando la siguiente expresión:

    • return [r.responseText=="", r.responseText];

      Si observáis, estamos llenando el array de retorno de tal forma que el primer parámetro será cierto si la respuesta obtenida está vacía (o sea, no hay error), y en el segundo parámetro introducimos la respuesta tal cual la hemos obtenido del servidor.

4. El controlador

Dado que la lógica la tenemos implementada en el modelo, y que la vista ya está preparada para ponerse en contacto con el controlador vía Ajax y para recibir el feedback sobre el éxito de la operación, sólo nos queda implementar muy rápidamente el método de acción:

public ActionResult Eliminar(int id)

{

    if (!gestorDeAmigos.Delete(id))

        return Content("Error eliminando el registro");

 

    return null;

}

 

Podréis observar que si se produce un error, retornamos un ContentResult describiendo el problema; en otros casos, devolvemos un nulo.

Para probar el funcionamiento de una eliminación errónea podéis, por ejemplo, abrir dos navegadores contra la aplicación, borrar un registro desde uno de ellos e intentar borrarlo también desde el otro.

Y… ¡Voilá!

Una vez habiendo implementado el modelo, la vista y el controlador, sólo nos queda probar la aplicación, que veremos que funciona perfectamente ;-P

jqGrid+ASP.NET MVC en acción

Resumiendo, en este post hemos seguido profundizando en las capacidades de jqGrid, implementando paso a paso la funcionalidad de eliminación de registros. Hemos podido observar también el escaso código (¡a pesar de la longitud del post!) que hay que añadir para disponer de esta funcionalidad, y de lo sencillo y reutilizable que resulta su implementación.

Descargar proyecto de demostración:

 

Publicado en: Variable not found.

Hojas con estilo usando .less

 

.Less: CSS Dinámicos para .NET Seguro que más de una vez has sufrido de lo lindo al tocar un archivo de hoja de estilos. Suelen estar mal organizados, ser muy extensos, difíciles de mantener, hay declaraciones duplicadas por todas partes… Y seguro que siempre te has preguntado si hay otra forma menos complicada de conseguir lo mismo.

K. Scott Allen nos habla en su post Keeping CSS Files DRY de .Less (dot less), un interesante componente portado del mundo Ruby capaz de “compilar” hojas de estilo que utiliza una notación extendida y mucho más potente del estándar CSS, permitiendo las siguientes características:

  • Uso de variables. Less permite declarar y utilizar variables para los valores que utilizaremos frecuentemente en nuestra hoja de estilos, así:
    @nice-blue: #5B83AD;

     

    #header { color: @light-blue; }

    #footer { color: @light-blue; }

  • Operaciones. Podemos utilizar expresiones para obtener valores, por ejemplo:
    @base: 5%;

    @filler: @base * 2;

    @other: @base + @filler;

     

    color: #888 / 4;

    background-color: @base-color + #111;

    height: 100% / 2 + @filler;

    Fijaos en un detalle de lo más interesante: Less es capaz de distinguir cuándo está operando con colores y cuándo con unidades, ofreciendo el resultado correcto en cada caso.

  • Mezclas (mixins), otra potente capacidad de Less que seguro que puede venirnos bastante bien, que consiste en incluir dentro de un conjunto de reglas dentro de otro, sólo haciendo referencia a su selector:
    .bordered {

      border-top: dotted 1px black;

      border-bottom: solid 2px black;

    }

     

    #menu a {

      color: #111;

      .bordered;

    }

     

    .post a {

      color: red;

      .bordered;

    }

  • Reglas anidadas, que nos permiten definir reglas siguiendo una estructura más legible y fácilmente reconocible por su paralelismo con la estructura del documento:
    #header {

      color: black;

     

      .navigation {

        font-size: 12px;

      }

      .logo {

        width: 300px;

        :hover { text-decoration: none }

      }

    }

  • Visibilidad de variables. Las variables pueden ser declaradas de forma global (como en el primer ejemplo) o asociadas a algún selector, lo que les aporta ámbito de visibilidad de forma muy similar a los lenguajes tradicionales:
    @var: red;

     

    #page {

      @var: white;

      #header {

        color: @var; // color será “white”

      }

    }

  • Accesores. Less permite utilizar valores de propiedades y variables como contenido para otras propiedades de forma muy natural:
    #defaults {

      @width: 960px;

      @color: black;

    }

     

    .article { color: #294366; }

     

    .comment {

      width: #defaults[@width];

      color: .article['color']; 

    }

    Fijaos que el bloque #defaults no tiene por qué corresponder con un elemento del documento a formatear, se trata sólo de una forma de agrupar variables y reglas, consiguiendo un efecto empaquetador muy similar a los espacios de nombres.

  • Comentarios en línea, al más puro estilo C++ ó C#:
    // Get in line!

    @var: white;

  • Importación de archivos, permitiendo acceder a reglas y variables definidas en otros archivos:
    @import "library"; // Si la extensión es .less, se puede omitir

    @import "typo.css";

¿Y cómo funciona esto? Muy sencillo. En primer lugar, escribimos la hoja de estilos en un archivo .less, en el que podemos utilizar las características descritas anteriormente, y lo incluimos en las páginas donde nos interese, como lo hacemos siempre:

<link href="/Content/estilos.less" rel="stylesheet" type="text/css" />

Es interesante tener en cuenta que Less es compatible con CSS, lo que quiere decir que si simplemente renombramos el .css a .less, ya tendremos una hoja de partida.

A continuación, debemos introducir en el web.config una declaración que asocie la extensión .css al compilador Less:

<httpHandlers>

  <add validate="false" path="*.less" verb="*"

    type="dotless.Core.LessCssHttpHandler, dotless.Core" />

</httpHandlers>

Cuando llega una petición, el handler se encargará de compilar el archivo .less, generar el .css correspondiente y enviarlo minimizado al cliente, cacheando el resultado para posteriores usos, si se lo indicamos en la configuración, una sección opcional del web.config.

.Less está diseñado para ASP.NET 3.5 o superior, y por supuesto, es válido tanto para Webforms como para ASP.NET MVC. Se distribuye bajo licencia Apache 2.0, y está aún en fase beta, por lo que habrá que estar atento a la evolución de este interesantísimo proyecto.

Enlaces:

Crosspostergado desde: Hojas con estilo usando .less @ Variable not found 

Indicios de que tu interfaz de usuario fue creado por un programador

¡Programadiseñadores al poder! Ya sabemos lo que suele ocurrir cuando los programadores diseñamos interfaces de usuario ;-). Para seguir profundizando en este curioso e inevitable fenómeno, Ian Voyce ha publicado hace unas semanas el divertido post The 7 signs your UI was created by a programmer, en el que recoge pistas que nos ayudarán a determinar si el interfaz de la aplicación que usamos a diario está creado por un diseñador experto en usabilidad, o ha sido el propio desarrollador el encargado de dichas tareas.

Bueno, en realidad se trata más bien de una lista con malos hábitos en el diseño de interfaces, y no necesariamente creados por programadores, pero ciertamente me he reconocido en alguno de los puntos y me han hecho gracia. Los cito y comento a continuación:

  • Iconos de exclamación en cuadros de diálogo
    Efectivamente, cuando incluimos una exclamación en un cuadro de diálogo no pensamos en que es posible que el usuario vea el mensaje 50 veces al día, con lo que dejaría de ser ese mensaje asombroso y puntual que pensamos en un principio. Hoy en día, muchas aplicaciones utilizan un tono mucho más neutral y cercano para enviar mensajes al usuario.
     
  • Mensajes con dobles negaciones en cuadros de diálogo, del tipo “¿Seguro de que no quieres perder tus cambios?” — Hmm… sí… digooo, no…  También son muy propias construcciones más complejas de la cuenta, paradójicas o inesperadas, como “Su mensaje no se ha enviado, ¿desea descartarlo?”, que ponen a prueba los reflejos de cualquier usuario. 
     
  • Orden de tabulación inexistente, o incorrecto, que fuerzan a que la navegación se realice exclusivamente a golpe de ratón. Y especialmente en aplicaciones de entrada masiva de información, el cambio de teclado a ratón y viceversa es terrible. Y paraGroupboxes para todo.. porque mola hacernos conscientes de ello, nada como dar vacaciones un rato al animalito y ver lo bien que manejamos determinadas aplicaciones.
     
  • Groupboxes rodeándolo todo… porque hay sitios donde queda bonito, aunque no esté agrupando nada ;-). Me confieso: durante años, he rodeado de groupboxes todo lo que se me ponía por delante, porque me parecía más agradable a la vista. Ahora lo estoy dejando 😉
     
  • IconoIconos creados en el IDE, je, este es otro de mis puntos fuertes: soy un fiera diseñando iconos desde el editor de Visual Studio. El problema es que, a pesar de lo orgulloso que estoy siempre de mis creaciones artísticas, no quedan bien e incluso introducen un cierto tufillo a cutre en las aplicaciones.
     
  • Utilización de grids, debido a lo que llama Voyce “la enfermedad de considerar que Excel es lo máximo en diseño de interfaces de usuario”, que fomenta la creación de rejillas con controles de lo más potentes y variopintos en las filas de datos (calendarios, gráficos, etc.).
     
  • Message Boxes no implementados, el equivalente en los interfaces de usuario a los TODO en el código fuente :-DD. Buena analogía. Algo parecidos serían los mensajes del tipo “Este mensaje no debería aparecer nunca” que alguna vez he encontrado por ahí, auténticos actos de rebeldía contra sus respectivos creadores.
     
  • Uso excesivo de cuadros de diálogo, incluso en situaciones en las que perfectamente podríamos obviarlos por no ofrecer información útil para el usuario, que no va a poder entender, o donde no se requieren decisiones por su parte.

    Los componentes necesarios han sido detectados. Accediendo...Esto es algo muy frecuente de ver. Por ejemplo, el otro día accediendo a una aplicación web para la que es necesario contar con certificado digital, me saltó la alerta que muestro a la derecha:

    Sí, probablemente los componentes Java necesarios para la autenticación y firma electrónica hayan sido detectados con éxito, pero… ¿realmente era necesario interrumpir mi navegación para informarme de ello? ¿Un usuario, sabrá interpretar el mensaje? Y en cualquier caso, ¿le aporta algo? No sé, no sé… me da que es un alert() creado por un desarrollador durante las pruebas y que al final se quedó ahí para la posteridad.

Hasta aquí las citadas en el post original, aunque siguiendo en la misma línea, puedo añadir algunas más de propia cosecha:

  • Cuadros de diálogo con mensajes y botones inconsistentes. Mensajes del tipo “¿desea cancelar la operación?” en cuyo pie aparece un botón “Aceptar” y otro “Cancelar” siempre me dejan pensando un rato. Si pulso aceptar, ¿estoy aceptando la cancelación, o justo lo contrario?… Muchas veces, parece que sólo podemos confiar en el azar.
  • Cuadros de mensaje con demasiados (o demasiados pocos) botones. No siempre atendemos a la Ley de Hick, que nos dice que “el tiempo que se tarda en tomar una decisión aumenta a medida que se incrementa el número de alternativas”, y eso nos lleva a crear cuadros de diálogo con muchos, demasiados, botones que el usuario debe estudiar.

    Y justo en el lado contrario, pero igualmente desconcertantes, son los cuadros de diálogo de introducción de datos sin ningún botón de aceptación, en los que su cierre (con la X de la esquina superior) implica el salvado de datos.

  • Interfaz descuidado. Y no hablo de bonito o feo, términos bastante subjetivos, sino de descuidado: controles sin alinear, con tamaños no proporcionales al contenido pretendido, sensación de desorden, faltas de ortografía… Esto no es un problema de interfaces creados por desarrolladores, sino creados por gente que no pone el más mínimo cariño en lo que hace, independientemente de su puesto de trabajo. 
     
  • Interfaces monocromos, mi especialidad. Como inútil reconocido en temas de diseño, me considero absolutamente incapaz de crear algo medio aparente con más de un color (eso sí, empleando distintas tonalidades ;-)). Nunca he entendido la compleja lógica que hay detrás del “eso no pega con aquello”, que algunos/as parecen dominar de serie. 
     
  • Controles con trastorno de personalidad. Un clásico es encontrar un grupo de checkboxes actuando como un grupo de radios. A ver, si sólo vamos a poder elegir una de las opciones, ¿por qué no usamos directamente el control específicamente ideado para ello? ¿Y un desplegable con las opciones “Activar” y “Desactivar”? ¿No sería más claro poner un checkbox?  

Artículo original: The 7 signs your UI was created by a programmer

Crossposteadísimo desde: Indicios de que tu interfaz de usuario fue creado por un programador @ Variable not found