Avanzis (Noticias y Blogs)

Adelgazar es bueno

Tue, 25 Nov 2008 17:24:51 GMT

Todos sabemos que una de las facetas importantes para conservar nuestra salud es mantenernos en un peso equilibrado. Pues en las empresas, también es importante. Y en particular en las empresas de software.

En los inicios de cualquier empresa, se tiende a pensar, que cuanto más de todo, mejor.

Cuantos más productos y servicios desarrollemos, más ventas conseguiremos.
Cuantos más clientes y proyectos tengamos, mayores beneficios.
Cuanta más complejidad y más líneas de código tengan nuestros programas, mejor, porque significará que tienen más funcionalidades.
Cuantos más procesos y procedimientos regulemos, mejor definiremos el funcionamiento de la empresa.
Cuantos más trabajadores seamos, mejor podremos asumir grandes cargas de trabajo.

Sin embargo, la experiencia de los años y el sentido común, van indicando que no es así. Que conviene no engordar más y adelgazar en lo que sea posible.

No hay que desarrollar todos los productos y servicios que se nos ocurran. Centrémonos en aquellos que pensemos que pueden ser realmente rentables. Seamos buenos en lo que hacemos, y no mediocres en todo. Especialización y diferenciación de la competencia. Desarrollar un nuevo producto tiene unos costes, y requiere una inversión, pero mantenerlo puede ser un coste oculto mucho mayor de lo esperado. Nos sentiremos tentados a ofrecer servicios complementarios a los que venimos ofreciendo, pero tal vez, sea mejor orientar a nuestros clientes hacia las empresas que pueden satisfacerles esas necesidades mejor que nosotros. Solo deberemos prestar nosotros el servicio si realmente queremos dedicarnos a ello en cuerpo y alma. Si forma parte de nuestra idea de negocio.

No es necesario tener una amplia cartera de clientes. Seleccionemos a los clientes y los proyectos que realizamos. Es un error aceptar el desarrollo de cualquier proyecto que nos proponga un cliente. Puede resultar apetecible en un primer momento, pero a la larga se paga.

Intentemos mantener nuestras aplicaciones con la mayor simplicidad y la menor cantidad de líneas de código posible. Reutilicemos al máximo, y no reinventemos la rueda. Utilicemos frameworks ya existentes y componentes estándares. El mejor programador sería que el consiguiese la funcionalidad deseada sin programar nada. Tras algunos meses o años de desarrollo de una aplicación, tal vez nos encontremos utilizando más tiempo en refactorizar y eliminar código y reemplazando código propio por soluciones existentes, que desarrollando cosas nuevas.

No tratemos de regular excesivamente con procesos y procedimientos la actividad de la empresa. Intentemos eliminar al máximo estos procesos automatizándolos. La mejor manera de hacer cumplir un procedimiento es que no exista otra manera de hacerlo, o que esté tan automatizado que el proceso como tal quede oculto. Fomentar una cultura y un know-how que permita como realizar una tarea aunque no esté explicitado como realizarla.

En la mayoría de proyectos, incrementar el número de personas dedicadas al mismo, no produce un incremento lineal del rendimiento ni de la velocidad de desarrollo. No tendamos a incrementar nuestra plantilla como la panacea para asumir mayor carga de trabajo. Seamos eficientes, que nuestra plantilla esté motivada y sea competente en su trabajo. Mejoremos la productividad, busquemos maneras de hacer el mismo trabajo en menor tiempo. Tengamos las herramientas de trabajo adecuadas, investiguemos en nuevas tecnologías que nos permitan una mayor agilidad. La productividad es la clave.

Resumiendo, menos es más. El ser humano tiende al caos, a la sobrecarga, al barroquismo y al exceso. Adelgazar es una tarea costosa y que requiere esfuerzo. Pero la obesidad es la principal causa de muerte en los países desarrollados. Quizá también de muchas empresas.

Utilizar Rhino Mocks y StructureMap en pruebas unitarias con NUnit

Tue, 25 Nov 2008 16:01:37 GMT

En el posts anteriores ya vimos cómo utilizar y configurar StructureMap para poner en práctica la inyección de dependencias.

Tal y como prometí, ahora vamos a ver un pequeño ejemplo de cómo utilizar el StructureMap y el mocking de objetos en las pruebas unitarias.

Quizá te preguntes que es un “Mock”.

Un mock, en el contexto de pruebas unitarias, es un objeto “falso” que simula el comportamiento del objeto real, con el fin de realizar las pruebas. En la wikipedia lo asimilan al maniquí que utilizan los diseñadores coches para realizar las pruebas de accidentes.

Te sugiero si utilizas pruebas unitarias, profundices más sobre este tema.
Existen muchas librerías para realizar mocks en .NET.

En el ejemplo que voy a plantear utilizaré Rhino Mocks, para crear un mock de un servicio de mensajería, ya que no quiero que realmente se envíe el correo electrónico al usuario, simplemente quiero probar que el método se llama convenientemente.

Primero crearé la interfaz de este servicio de mensajería.

    1 public interface IMessagingService
    2 {
    3     void SendMessage(User user, string text);
    4 }

En la aplicación “real”, no en las pruebas unitarias, configuraré StructureMap para que el servicio de mensajería sea una implementación de esta interfaz para enviar correos electrónicos. Pero podría ser cualquier otra cosa, enviar SMS, un texto al Messenger, etc…

    1 private static void ConfigureStructureMap()
    2 {
    3     ObjectFactory.Configure(s => 
    4         s.BuildInstancesOf<IMessagingService>()
    5         .TheDefaultIsConcreteType<EmailMessagingService>());
    6 }

El controlador de asp.net mvc que queremos probar tiene la siguiente acción:

    1 public ActionResult CreateUser(string userName, string password, string email)
    2 {
    3     User user = new User{UserName = userName, Password = password, Email = email};
    4 
    5     UserValidationResult result = userService.Register(user);
    6 
    7     if (result.IsValid)
    8     {
    9         IMessagingService messagingService = ObjectFactory.GetInstance<IMessagingService>();
   10 
   11         messagingService.SendMessage(user, "Tu cuenta ha sido creada correctamente");
   12 
   13         return Authenticate(userName, password, null);
   14     }
   15 
   16     TempData["RegisterErrors"] = result.Errors;
   17 
   18     return RedirectToAction("Register");
   19 }

Y ahora en las pruebas unitarias, comprobaremos que el método SendMessage se llama al crear un nuevo usuario. Utilizaremos NUnit como librería de pruebas y habrá que añadir la referencia al dll de Rhino Mocks de y de StructureMap al proyecto de pruebas.

    1 [Test]
    2 public void CreateUser_Creates_Users_And_Sends_Email()
    3 {
    4     MockRepository mocker = new MockRepository();
    5 
    6     IMessagingService messagingService = mocker.StrictMock<IMessagingService>();
    7 
    8     Expect.Call(() => messagingService.SendMessage(null, null))
    9         .IgnoreArguments();
   10 
   11     mocker.ReplayAll();
   12 
   13     ObjectFactory.Inject(messagingService);
   14 
   15     controller.CreateUser("usuario", "clave", "direccion@correo.es");
   16 
   17     mocker.VerifyAll();
   18 }

Veamos con más detalle el código de esta prueba.

En la línea 1 le indico a NUnit que este método es una prueba.

En la línea 4 creamos el objeto de Rhino Mocks que se encargará de generar los objectos Mocks a partir de la definición de la interfaz.

En la línea 6 creamos obtenemos la implementación simulada del servicio IMessagingService.

En la líneas 8 y 9, le decimos a Rhino Mocks que esperamos que en el futuro se llame al método SendMessage del objeto messagingService y que nos dan igual los argumentos utilizados. El método Expect.Call espera como parámetro un delegado que se lo hemos pasado utilizando una expressión lambda.

En la línea 12, le indicamos al objeto MockRepository que ya hemos fijado todas las expectativas (en nuestro caso, sólo la establecida en la línea 8) y que vamos a empezar las pruebas.

En la línea 13, inyectamos la interfaz simulada a StructureMap para que utilice este objeto, en vez de lo que tenga en su configuración.

En la línea 14, llamamos al objeto que estamos probando con algunos parámetros por defecto.

En la línea 15, le pedimos a Rhino Mocks, que verifique que se han cumplido todas las expectativas establecidas. En nuestro caso queríamos que se llamara al método SendMessage al crear un usuario. Si esto no ocurriera, este método lanzaría una excepción por lo que la prueba unitaria no se pasaría correctamente.

¡Espero que te haya servido de ayuda!

Primeros pasos con StructureMap y la Inyección de Dependencias

Tue, 25 Nov 2008 13:26:48 GMT

Uno de los objetivos que debe tener un buen programador es que su código esté poco acoplado, es decir, que dos componentes con funcionalidades distintas dependan el uno del otro lo mínimo posible. De esta forma conseguirá que sus dos componentes por separado sean reutilizables y más fáciles de mantener.

Para eliminar al máximo la dependencia entre componentes, existe un patrón de diseño conocido como “Inyección de dependencias” (“Dependency Injection” o DI). Este patrón consiste básicamente en que en vez de ser una clase la que crea objetos, estos se inyectan o resuelven en el último momento.

Existen diferentes proyectos en .NET que intentan ayudarnos a aplicar este patrón:

He decidido comenzar a utilizar StructureMap porque que es uno de los más extendidos y además me gusta su sintaxis y facilidad de uso.

Para comenzar a utilizar la inyección de dependencias debes acostumbrarte a utilizar interfaces en vez de objetos concretos ya que esto es lo que te permitirá diferentes implementaciones de esa interfaz.

Por ejemplo, si queremos un componentes que realice el registro de errores o eventos, crearemos una interfaz “ILogger”. Y además, dos implementaciones de esta interfaz, una para guardar los mensajes en una base de datos y otra en un archivo de texto.

public interface ILogger
{
    void Log(string message);
}
 
public class DatabaseLogger : ILogger
{
    public void Log(string message)
    {
        // Lógica para guardar el mensaje en un archivo d texto..
    }
}
 
public class TextLogger :  ILogger
{
    public void Log(string message)
    {
        // Lógica par aguardar el mensaje en un archivo de texto...
    }
}

Muy bien, ya tenemos dado el primer paso. Ahora añadiremos la referencia en nuestro proyecto a StructureMap.dll para poder utilizar esta librería.

Cuando queramos utilizar el objeto ILogger dentro de otra clase, llamaremos método GetInstance() del objeto ObjectFactory que ofrece StructureMap.

Por ejemplo

public class ClaseDePrueba
{
    public void HacerAlgo()
    {
        // ...
        ILogger logger = ObjectFactory.GetInstance<ILogger>();
        logger.Log("Mensaje que queremos registrar");
        // ...
    }
}

Pero te preguntarás, ¿cómo sabe StructureMap cuál de las dos implementaciones de ILogger debe devolver, la de la base de datos o la del archivo de texto? Obviamente eso hay que indicárselo de alguna forma.

Podemos configurar StructureMap o bien utilizando el archivo de configuración App.config o Web.config si es una aplicación web. O mediante código, normalmente al iniciarse el programa o en el archivo Global.asax si trabajas con ASP.NET.

En este ejemplo, le indicaremos por código a StructureMap que queremos utilizar el archivo de texto para guardar los logs.

public void ConfigureStructureMap()
{
    ObjectFactory.Configure(
        s => s.BuildInstancesOf<ILogger>()
            .TheDefaultIsConcreteType<TextLogger>()
    );
}

¡Eso es todo! Ya estamos utilizando StructureMap y a partir de ahora, con cambiar una simple línea de código (o una línea del archivo de configuración si hubiéramos utilizado esa opción) podemos comenzar a utilizar la base de datos para guardar los mensajes en toda la aplicación.

La Inyección de dependencias es un patrón de diseño que todo programador debería conocer y utilizar. Además, esta técnica, unida al “Mocking”, te será realmente útil si utilizas (¡deberías hacerlo!) pruebas unitarias. Pero de esto ya hablaré en el futuro.

¡Espero vuestros comentarios!

El SEO y sus puntos clave.

Wed, 19 Nov 2008 13:38:35 GMT

El SEO, o Search Engine Optimization, se refiere al conjunto de técnicas que debemos aplicar en una Web para que esté optimizada en buscadores y que salgamos bien posicionados.$0$0Técnicas SEO hay muchísimas, pero en mi opinión hay 6 que destacan sobre todas las demás:$0$0$0Tener sitemaps.$0$0La palabra/frase clave debe ser el título de la página.$0$0La palabra/frase clave debe encontrarse dentro de la url de la página.$0$0La palabra/frase clave (debe estar dentro de un)/(debe ser el) H1 en la página.$0$0La palabra/frase clave debe estar repetida varias veces dentro de la página, algunas de ellas con negrita.$0$0Estructura de enlaces internos: todas las páginas de tu Web deben estar enlazadas entre ellas con pocos saltos de diferencia.$0$0Todo ello bajo la premisa de tener un buen contenido. Sin buen contenido no empezamos ni a hablar. Será este buen contenido el que te proporcione enlaces entrantes, y será la constancia el que haga que Google confíe en ti.$0$0Si estás interesado en técnicas SEO más avanzadas, te recomiendo el blog comunactivo.

Jugando con jQuery: emulando el FindControl de ASP.NET

Sun, 05 Oct 2008 10:54:49 GMT

Esto de jQuery es divertido. Igual de divertido que javascript pero más fácil.

Hace unos días di una primero introducción a jQuery e hice mi primer plugin que llamé macEmulator.

Ahora presento un nuevo plugin que responde a una necesidad real y casi diaria de todo programador en ASP.NET (a no ser que trabaje con MVC).

Se trata de emular el FindControl de ASP.NET pero con javascript. Vayamos a un ejemplo:

Tenemos un DataList con un ItemTemplate que tiene dos Panels y un Label en cada Panel










Esto generará un código HTML que convertirá las Label en elementos con un identificador de este estilo: DataList1_ctl00_Label1

Pero yo lo que quiero es acceder a las Label1 por jQuery... ¿cómo lo hago?

No hay una forma directa porque los IDs los genera ASP.NET, pero con el plugin que presento podremos hacer algo como esto:

var controls = $(document).findControl('Label1');
for (i = 0; i < controls.length; i++) { alert(controls[i].innerHTML); }

El plugin no es que sea una obra de arte. Más bien es sencillito, jeje. Lo autoexplican los comentarios:

jQuery.fn.findControl = function(clientId) {
    var ids = new Array();

    // Para cada elemento que tenga un atributo ID dentro de "this"
    $(this).find('*[id]').each(function(i) {
        // Si el ID del elemento termina como el clientId, lo añadimos al array
        if (this.id &&
            (this.id.lastIndexOf(clientId) >= 0) &&
            (this.id.lastIndexOf(clientId) == (this.id.length - clientId.length))) {
                ids.push(this);
            }
        });

    // Devolvemos el array
    return ids;
}

El plugin ya viene con bugs por defecto, como el hecho de que si otro elemento se llamara MyLabel1, el plugin se creería que es Label1... pero bueno, es una primera aproximación.

Jugando con jQuery: macEmulator

Thu, 02 Oct 2008 13:46:17 GMT

Tras la breve introducción a jQuery, propongo un ejemplo que he llamado "macEmulator". La verdad es que soy bastante malo dando nombre a las cosas, y en el mundo de la programación tenemos que estar todo el santo día dando nombres a variables, a funciones, a clases, a ficheros...

El "macEmulator" lo que hace es coger las imágenes ubicadas dentro del "div" que le indiquemos y darles un efecto similar al de los iconos de los Mac. Cuando el ratón está encima de un icono la imagen se hace grande (progresivamente) y cuando sales se hace pequeña (también de forma progresiva).

Lo he puesto dentro de un plugin, de forma que activar la funcionalidad se reduce a una sola línea de código:

$("#divId").macEmulation(100,150,100,500);

Donde:

divId es el "id" del div en el que están ubicadas las imágenes.
El primer parámetro marca la anchura inicial de las imágenes
El segundo parámetro marca la anchura de la imagen cuando el ratón está sobre ella.
El tercer parámetro marca la anchura de la imagen cuando el ratón deja de estar sobre ella.
El cuarto parámetro marca el tiempo que tarda la imagen en transformarse progresivamente de grande a pequeña y de pequeña a grande.

A continuación muestro el código con comentarios para entender el script:

jQuery.fn.macEmulation = function(initialWitdh, hoverWidth, houtWidth, delay) {
    // Cogemos el elemento dentro del cual estarán las imágenes
    var div = $(this);

    // Cuando la página esté cargada, aplicaremos la anchura inicial marcada
    // y pondremos cada imagen dentro de un div con unos estilos predefinidos
    $(document).ready(function() {
        div.find('img').width(initialWitdh);
        div.find('img').wrap('
');

    });

    // Asignamos la anchura de la imagen cuando estamos sobre ella y cuando dejamos de estarlo.
    // Para ello utilizaremos el modo "animate" que hará que la transición sea progresiva.
    div.find('img').hover(
    function() {
        $(this).animate({ width: hoverWidth + "px" }, delay);
    },
    function() {
        $(this).animate({ width: houtWidth + "px" }, delay);
    });
}

Introducción a jQuery

Thu, 02 Oct 2008 13:30:44 GMT

Javascript ha sido siempre un eterno candidato a desaparecer. Sin embargo, con el paso de los años su importancia en el mundo Web ha ido en aumento.

Javascript no suele gustar. Se puede hacer muchísimas cosas con él, pero tiene varios inconvenientes. Empezando por la selectiva incompatibilidad entre navegadores, y acabando por una curva de aprendizaje no lineal (hacer cosas fáciles es fácil, hacer cosas difíciles es muy difícil... y en el medio hay poquito).

Para los que hemos trabajado con javascript desde sus inicios, solemos tener pequeñas librerías que nos hacen todo lo que queremos. Pero suelen ser librerías poco estándar... vamos, que cada uno las tiene de su padre y de su madre.

Es por eso que últimamente en la oficina suena mucho "jQuery", del que Richard ya ha hablado. Básicamente, jQuery es un framework javascript, que nos permite olvidarnos de las incompatibilidades y linealiza mucho la curva de aprendizaje. El framework propone un estándar de trabajo con javascript, que no sólo lo hace más fácil sino que le añade funcionalidades extremadamente útiles en pocas líneas de código.

Para más regocijo, su Web oficial es muy útil, clara y llena de ejemplos, con buenos tutoriales y muchos plugins.

En próximos artículos pondré ejemplos de algunas de las cosas que se puede hacer con jQuery. Serán ejemplo específicos, porque la Web oficial de jQuery ya es muy clara.

jQuery en Visual Studio. Algo está cambiando en Microsoft

Sun, 28 Sep 2008 13:54:07 GMT

Cuando hoy he leído el último artículo de Scott Guthrie - Scottgu para los amigos –‘jQuery and Microsoft’, me he quedado alucinado.

La noticia en sí es muy buena: van a comenzar a distribuir jQuery, mi librería Javascript favorita, junto con Visual Studio. No sólo eso. Además darán soporte nativo de ‘Intellisense’ en su editor, crearán controles para AJAX Control Toolkit, la integrarán con ASP.NET MVC y contribuirán con pruebas, corrección de errores y parches.

Nosotros ya estamos usando jQuery en nuestros nuevos proyectos, y los diseñadores de Avanzis ya han comenzado a utilizarlo cuando necesitan realizar efectos avanzados con Javascript.

Las principales ventajas de jQuery son:

No es intrusivo.
Esto significa que no se mezcla el código HTML con Javascript, con lo que se consigue un código más limpio y fácil de mantener.

Simplifica las tareas habituales de Javascript.
Seleccionar un elemento DOM, añadir una clase, ejecutar una función para cada elemento, crear una animación… Todo esto y mucho más es más sencillo con jQuery.

Es independiente del navegador.
No tienes que escribir código distinto para Firefox, Internet Explorer, Google Chrome, Opera, etc.… jQuery lo hace transparente para el desarrollador.

Ocupa muy poco.
¡La librería comprimida apenas llega las 15KB!

Extensible.
Dispones de cientos de extensiones para jQuery que puedes utilizar y también están comenzado a implementar de forma oficial controles gráficos con ‘jQuery UI’.

Si no conoces jQuery… ¡es el momento para aprender! Puedes encontrar tutoriales sobre jQuery en su página oficial y espero que Eva escriba algún artículo en su blog ya que es una experta y ha estado últimamente comparándolo con otras librerías javascript como Prototype.

Pero la noticia subyacente es más importante. Se ha producido definitivamente un gran cambio de filosofía en Microsoft respecto a los proyectos “Open Source”. Por primera vez - que yo conozca - la gente de Microsoft NO va a duplicar la funcionalidad de un proyecto de código abierto, si no que lo va a adoptar para su causa y va a contribuir a mejorarlo.

Hasta el momento, muchos de los proyectos de código abierto de mayor éxito han tenido su versión particular de Microsoft. Algunos ejemplos que me vienen ahora a la memoria:

Proyecto de código abierto	Solución de Microsoft
NUnit, MBUnit	Microsoft.VisualStudio.TestTools.UnitTesting
MonoRail	ASP.NET MVC
StructureMap, MicroKernel	Unity
NAnt	MSBuild

Y un largo etcétera.

No sé si es un cambio en la visión de sus directivos, por la presión de la competencia como Google, o por la insistencia de sus desarrolladores principales pero, definitivamente, algo está cambiando en Microsoft.

Editado: José M. Aguilar de www.variablenotfound.com ya hace referencia a esta noticia.

De vuelta a la oficina tras las vacaciones

Sun, 14 Sep 2008 10:18:39 GMT

Primer día de trabajo en Avanzis tras algo más de tres semanas de merecidas vacaciones, las cuales me han servido no solo para desconectar literalmente de Internet, lo cual ya es todo un logro para alguien que está constantemente pendiente de un ordenador, sino que además he podido disfrutar de una mini escapada a Vitoria, ciudad realmente preciosa para aquellos que sepan ver en las ciudades algo más que hileras de pisos en los que vivir.

Para los que trabajamos constantemente con ordenadores, resulta de vital importancia poder tener unos días de relajación total, manteniendo nuestras manos lejos del teclado y del ratón, para por lo menos sentir esa sensación de no dependencia hacia una maquina. Pero hay que reconocer que, incluso estando de vacaciones, no resulta nada fácil levantarse por la mañana y evitar levantar la tapa del portátil, aunque sólo sea para conocer las noticias de última hora.

Lo mejor de todo, la sensación de haber podido descansar, de haber disfrutado del tiempo libre para hacer esas cosas que normalmente la rutina de cada día nos priva de realizar. El resultado, la vuelta al trabajo se torna mucho más fácil cuando uno tiene la sensación de haber aprovechado bien sus vacaciones.

Mi consejo, sobre todo para los que trabajamos en el sector de las nuevas tecnologías, en vacaciones desconectar por unos días totalmente del mundo de las máquinas, desenchufar los móviles, dejar el ordenador apagado, y si os cuesta, es tan fácil como esconder el router en algún remoto rincón, al menos por unos días. Relamente merece la pena...

Google Chrome - El nuevo navegador web de Google

Mon, 01 Sep 2008 21:02:50 GMT

Desde hace unos minutos está disponible Google Chrome, el navegador web creado por Google.

Lo puedes descargar en este enlace:

http://www.google.es/chrome

Y en estos momentos tengo sensaciones encontradas:

Desde el punto de vista de usuario estoy encantado. Google Chrome parece sencillo de usar, rápido y tiene algunas funcionalidades muy interesantes. Promete ocupar poca memoria y ser veloz como ningún otro navegador a la hora de ejecutar javascript. ¡La descarga ocupa menos de 500KB!

Desde el punto de vista de desarrollador web, esto es una faena.

Con dos navegadores mayoritarios - Internet Explorer y Firefox - con sus versiones - Internet Explorer 4.0, 5.0, 6.0, 7.0 y en breve Internet Explorer 8 y Firefox 1.0, 2.0 y 3.0 - ya teníamos más que suficiente, ya que cada web y aplicación que desarrollamos es necesario probarla al menos en los navegadores principales y con sus versiones más usadas.

En un mundo ideal, el desarrollo web tendría que realizarse como si únicamente existiera una navegador y este interpretara a la perfección los estándares, pero en la realidad no todos los navegadores se comportan igual a la hora de mostrar una página, ni tienen las mismas funcionalidades javascript. Si Google Chrome tiene éxito y es adoptado por muchos usuarios, nuestro esfuerzo como desarrolladores web se multiplicará inevitablemente.

Por suerte, mis primeras pruebas con Google Chrome son esperanzadoras tras probar algunas de nuestras webs:

Todoexpertos.com

Euroleague.net

Bookingpark.com

¡Todas ellas se han mostrado perfectamente!

También he accedido a la parte de administración Webportal, nuestro gestor de contenidos y... ¡ningún problema aparente!

Lástima que el editor HTML online que utilizamos y que hace un uso extensivo de javascript, ajax y comportamiento del servidor, no se ha comportado del todo bien. Por supuesto, ya estamos investigando cómo solucionarlo.

Google Chrome, tiene muy buena pinta. Así que quizá los desarrolladores web hayamos asistido hoy a un antes y un después en Internet.

ASP.NET MVC Preview 5

Thu, 28 Aug 2008 17:14:20 GMT

!Acaban de lanzar la preview 5 de ASP.NET MVC en Codeplex!

Si eres de los valientes (como nosotros) que estas desarrollando con ASP.NET MVC, recuerda que tendrás que desinstalar la versión anterior antes de instalar este nuevo lanzamiento.

Por si nos os apetece leer, y ya que tengo que revisar los cambios en profundidad, aquí tenéis algunas de las nuevas características respecto a la Preview 4:

Mejoras en los motores de visualización (ViewEngine)
- Ahora, en vez de ser cada controlador el responsable de decidir que motor de visualización se utilizará, los motores se registran de forma global.
- Se ha modificado la interfaz IViewEngine para que añada el método "RenderPartial".
Mejoras en los helpers
- Soporte para la renderización de views parciales.
- Nuevo parámetro para poder indicar a un DropDownList cuál será su opción por defecto.
- Se han movido las extensiones AJAX a otro namespace, teóricamente para que sea más sencillo reemplazarlas por tu propio código.
- Otras mejoras
Mejoras en los controles y los filtros.
- Los parámetros de las acciones ahora soportan también arrays.
  Esto ocurría cuando varios controles tienen el mismo nombre.
- Soporte a para crear tus propios "binders". Los binders asocian los valores que llegan por querystring o form con parámetros de la acción.
- Añadida la interfaz "IActionInvoker" para desacoplar el controlador la implementación específica de "ControllerActionInvoker".
- Añadido el modo actualización (UpdateMode) a la clase del controlador. Es posible utilizar este método para actualizar las propiedades de un modelo a partir de los parámetros pasados en el formulario.
- Se ha modificado "HandleErrorAttribute" para que mientras estás desarrollando aparezca la ventana amarilla de error que proporciona la máxima información posible.
- Nuevo atributo "AcceptVerbs". Permite indicar qué verbos HTTP son aceptados (GET, POST, etc...). Esto permite tener dos acciones con el mismo nombre siempre y cuando acepten verbos diferentes.
- Nuevo atributo "ActionName". Permite indicar un nombre de acción a un método diferente del nombre del método. Su ejemplo para estas dos últimas mejoras es bastante claro:
  
  [AcceptVerb("GET")]
  public ActionResult MyAction(...);
  
  [ActionName("MyAction"), AcceptVerb("POST")]
  public ActionResult MyAction_FormSubmit(...);
  
  [AcceptVerb("GET")]
  public ActionResult OtherActionOverloaded(string id);
  
  [AcceptVerb("POST")]
  public ActionResult OtherActionOverloaded(string id, ...);

Muy bonita toda esta explicación, pero ¿cómo nos ha afectado a nostros en el proyecto que estamos realizando en ASP.NET MVC?

Estos son los problemas que hemos encontrado para que nuestro proyecto compile tras haber actualizado a la preview 5:

El objeto "LinkBuilder" ahora se encuentra en el espacio de nombre "Microsoft.Web.Mvc". Este objeto lo utilizamos para generar un "RouteValueDictionary" a partir de una expresión de Linq.
El método ActionLink que adminte como tipo un controlador, se ha movido también a Microsoft.Web.Mvc.
BindingHelperExtensions ya no existe y aún no he encontrado ningún objeto equivalente.
El controlador ya no tiene la propiedad ViewEngine.ç
Html.RenderUserControl() ya no existe, ahora hay que usar Html.RenderPartial(). Por ejemplo:
<%=Html.RenderUserControl("~/UserControls/TagList.ascx", ViewData.Model.PopularTags)%>
Ahora será:
<% Html.RenderPartial("~/UserControls/TagList.ascx", ViewData.Model.PopularTags);%>
Fíjate que ahora no hay que poner el igual delante, y que tiene que acabar con punto y coma.

¿Alguien más se está peleando con ASP.NET MVC? Me encantaría escuchar vuestros comentarios.

Trucos FLASH: Obtención de variables desde QueryString

Tue, 12 Aug 2008 14:30:19 GMT

Cada día, en el transcurrir de una empresa dedicada al desarrollo web, ya sea incluso en un mes de agosto, surgen a menudo nuevas especificaciones o requerimientos que nos obligan a investigar soluciones que quizás antes jamás habíamos utilizado. Además esto ocurre frecuentemente cuando se trata de proyectos web que incorporan animaciones en flash, donde en ocasiones la integración e interacción de dicho archivo con nuestro gestor de contenidos requiere del ingenio, da la experiencia, pero sobre todo de la capacidad que actionscript nos ofrece.

Ayer mismo se nos planteó la necesidad de modificar el valor de una variable utilizada en un archivo flash en función del valor de un parámetro del QueryString de una URL. Algo que, tras un par de horas de analisis y de investigación, resulta realmente sencillo de realizar, pero que dicho así de buenas a primeras parece más complejo de lo que es. Aprovecharé además para explicar como de forma sencilla podemos cambiar ciertos aspectos de un mismo fichero flash, solamente mediante el paso directo de parámetros sobre la definición del object.

PASO DE PARÁMETROS DIRECTAMENTE SOBRE EL FLASH

En algunas ocasiones puede interesarnos, sin mayores complicaciones, que un mismo flash se comporte de forma diferente, cambie su color de fondo, o incluso que tenga una apariencia diferente, solamente con cambiar el valor de una de sus variables. Esto, que en apariencia resulta tan absurdo, puede ayudarnos a reutilizar un mismo fichero flash, en varias circunstancias diferentes. Sobre todo es muy útil para ajustar por ejemplo el look and feel de un mismo fichero flash al diseño de distintos portales web.

Ejemplo 1.1: Nuestro fichero flash sustenta su fondo en una fichero de imagen que nosotros podemos cambiar a nuestro antojo. Para ello mediante la simple asignación de una url relativa a la variable imageFileName podremos cambiar dicha imagen de fondo.

codebase="http://macromedia.com/cabs/swflash.cab#version=4,0,0,0"
classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000">


        type="application/x-shockwave-flash height="150" width="250">

Ejemplo 1.2: Con la misma intención que en el anterior ejemplo, esta vez la variable la definimos directamente sobre la propia url relativa de la película flash.

codebase="http://macromedia.com/cabs/swflash.cab#version=4,0,0,0"
classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000">
        value="flaMovie.swf?imageFilename=imagen01.jpg">
    src="flaMovie.swf?imageFilename=imagen01.jpg"
    bgcolor="#99CC33" type="application/x-shockwave-flash
    height="150" width="250">

PASO DE PARÁMETROS POR QUERYSTRING

En nuestro caso en particular lo que necesitábamos es que este paso de variables se hiciera directamente desde el QueryString de una url. Además por cuestiones de optimización optamos porque de todas los posibles variables que puedan encontrarse en el QueryString, tan sólo queremos tener en cuenta la variable definida como tipo, algo que podremos también controlar mediante actionscript.

Ejemplo 2:

import flash.external.*; //para poder usar externalInterface

var paramTipo;
var queryString = ExternalInterface.call("window.location.search.substring", 1);

if(queryString) {
    var allParams:Array = queryString.split('&');

    for (var i = 0, index = -1; i < allParams.length; i++) {
        var keyValuePair:String = allParams[i];

        if((index = keyValuePair.indexOf("=")) > 0) {
            var paramKey:String = keyValuePair.substring(0,index);
            var paramValue:String = keyValuePair.substring(index+1);

            if (paramKey.toLowerCase() == "tipo") { paramTipo = paramValue; }
        }
    }
}

Ya solamente quedará utilizar adecuadamente en nuestro código actionscript la variable definida aquí como paramTipo para la finalidad que fuera necesaria. Con esto lo que logramos, como ya hemos comentado, es poder cambiar dinámicamente nuestra película flash en función de los valores que se han introducido en el QueryString, lo cual nos abre un abanico de posibilidades realmente amplio.

Nota: Este Script solamente funcionará en Internet Explorer si nuestro .swf integrado en el HTML como un Object emebedido tiene previamente definido un id.

Podréis encontrar más información ampliada en inglés en los siguientes enlaces.

Fuente 1 | Circlecube.com
Fuente 2 | Permadi.com

Recomendaciones: Pasar de HTML a XHTML (I)

Sun, 10 Aug 2008 13:39:36 GMT

En muchas ocasiones, cuando se aborda un cambio en el lenguaje de marcado utilizado habitualmente para crear nuestras páginas webs, como es por ejemplo el paso de HTML a XHTML, frecuentemente nos encontramos con problemas de varios tipos, atributos usados de forma indebida, etiquetas mal cerradas, e incluso en algunos casos el comportamiento de los CSS varía, con lo que hay que volver revisarlos y redefinirlos.

Puede parecer, y no falta razón en ocasiones, que los que diseñamos y creamos páginas web ante un cambio de lenguaje de marcado, no nos paramos ni un segundo a estudiar las nuevas reglas de uso y que nos limitamos a dejar que el día a día sea el que nos muestre esos nuevos cambios. Algo que puede tener su origen quizás, en nuestra condición de autodidactas, al menos en mi caso. Ignoro si en el mundo de la programación sucede igual, pero para los que hacemos páginas web creo que éste es uno de nuestros mayores hándicaps, la falta de concienciación sobre las reglas de nuestro lenguaje de marcado.

Ni que decir tiene que el lenguaje de marcado que vayamos a utilizar influye de manera crítica en la forma que nuestro navegador va a interpretar los CSS, una de las piedras angulares sobre los que sustentan nuestros diseños y nuestras páginas web. Es por ello por lo que no está de más conocer cuáles son algunos de los cambios más importantes que XHTML ha incorporado, sobre todo si no queremos que nos afecte a nuestros CSS.

Por ejemplo, una de las nuevas características de XHTML es que es case sensitive. Podríamos pensar que ahí reside uno de los mayores conflictos con CSS, pero este cambio introducido en XHTML, no representa muchas diferencias con lo que se venía haciendo, ya que en HTML la definición de atributos id y class también era case sensitive.

Entonces, ¿por qué el paso de un documento HTML a XHTML deriva en todos estos inconvenientes? La respuesta la podemos encontrar fácilmente en la forma que han tenido y tienen los navegadores de Internet de interpretar el documento que se está abriendo.

La correcta definición en la cabecera de los tipos de los documentos utilizados, ya sean HTML o XHTML, ha sido una práctica poco habitual en el mundo web. Actualmente se ha convertido en algo realmente necesario, sobre todo para que los navegadores apliquen correctamente los estándares y sepan interpretar los documentos de la forma adecuada.

Ejemplo: Definición de un documento de tipo XHTML 1.0 Transitional.

La ausencia de esta definición, derivaba en un conflicto realmente importante con los navegadores de Internet, quienes al desconocer el tipo de documento que estaban procesando, y en lugar de usar al azar alguno de los estándares definidos, el Standar Mode, adoptaban el modo de compatibilidad por defecto, o más conocido como Quirks Mode.

Una de las particularidades de este modo era precisamente no ser case sensitive. Esto afectaba, y sigue afectando, no sólo a la forma de visualizar e interpretar las páginas web, sino a la forma en la que los que desconocían esta circunstancia generaban su código CSS. Siempre ha existido, o al menos esa es mi impresión, la tendencia de diseñar para los navegadores, sin pensar que la solución pasa por diseñar pensando en los estándares. Unos estándares que los propios navegadores ya son capaces de interpretar a la perfección a poco que se lo indiquemos de forma adecuada.

Podríamos decir pues que, al margen de la experiencia de cada uno, no hay nada mejor que saber y conocer perfectamente las reglas, particularidades y características fundamentales del lenguaje de marcado que estamos utilizando. Pero además debemos ser capaces de ver a los navegadores de Internet como lo que son, unos simples intérpretes de nuestro código.

Así, cuando nos topemos de nuevo con la disyuntiva, más que habitual hoy día, de que IE6, IE7, FF2 y FF3 no muestran nuestra página web de la misma forma, sabremos reconocer que quizás el problema sea simplemente que no hemos sabido utilizar de forma adecuada todos los estándares, herramientas y lenguajes de los que disponemos.

Scrum, Test Driven Development y MVC. Vamos a ser ágiles.

Thu, 24 Jul 2008 00:42:49 GMT

En Avanzis estamos empezando un proyecto que nos ilusiona mucho, y que esperamos que vea la luz antes de final de año. Como todo proyecto que empieza, uno de los primeros aspectos a decidir es qué metodología vamos a seguir y qué plataforma tecnológica. En este proyecto vamos a utilizar Scrum y Test Driven Development. Vale. Y ahora os preguntareis ¿esto qué significa?. Pues básicamente son dos relativamente nuevas metodologías en el desarrollo de software, clasificadas dentro de las llamadas “ágiles”. Estas dos metodologías tienen algo en común. Se asume que el diseño de la arquitectura de clases, la definición de las funcionalidades y la especificación de requisitos, es un proceso que fluye a través de todo el desarrollo del proyecto, y no son una etapa inicial aislada. No hay que esperar a tener el diseño y la especificación completa para empezar a desarrollar. Scrum es una manera de organizarse, y TDD es una manera de desarrollar.

¿Qué es SCRUM?

Scrum es una metodología de trabajo ágil, especialmente diseñada para intentar acortar los ciclos de desarrollo y conseguir una mejor aproximación entre las funcionalidades del software y los requerimientos del cliente. Se trata de evitar la burocracia innecesaria, conseguir una mayor versatilidad frente a los cambios y empezar rápidamente a trabajar, de manera que el cliente puede ir viendo lo antes posible los avances en el proyecto. Es óptima para equipos de trabajo no demasiado grandes y clientes que tengan un alto grado de implicación en el proyecto. El procedimiento básico consiste en crear un repositorio con las funcionalidades requeridas para el proyecto, asignándoles unos puntos de importancia, una estimación en horas y cómo se debe demostrar esta funcionalidad. A esto lo llamaremos “Product Backlog”. A partir de entonces, se crean los “Sprint Backlogs”, que son un conjunto de tareas que se deben completar en un determinado tiempo, entre 2 semanas y un mes. Durante cada dia del sprint, se hace una corta reunión para revisar el estado de las tareas, y al final de cada sprint, una reunión con el cliente para mostrarle los resultados. Así, el cliente va viendo los avances cada corto periodo de tiempo, y se puede reajustar cualquier cambio de funcionalidad en cualquier etapa del proyecto. Obtenemos un feedback que nos permite mejorar en el siguiente sprint.

¿Qué es TDD?

Para tratar de mejorar del código, existen los “Unit Tests”, que consisten en código adicional que se ocupa de probar el código principal. Se trata de probar que pequeñas unidades individuales de código se comportan tal y como esperamos. Para ello existen frameworks como NUnit con el fin de ayudarnos en esta tarea. Mediante los test, tenemos una mayor seguridad en que las cosas funcionan como deben, y además, podemos comprobar que las cosas siguen funcionando bien después de hacer cambios en el código. Pero TDD va más allá. En lugar de programar y luego probar, se intercambia el orden, de manera que primero creamos los test, y a partir de aquí se va creando la funcionalidad. El ciclo que se va repitiendo es: Añadir el test para una nueva funcionalidad. Evidentemente, este test fallará dado que la funcionalidad no está implementada. Programaremos, ejecutaremos todos los tests hasta que todos ellos tengan éxito, y finalmente refactorizaremos y volveremos a empezar. En el modelo habitual, se dedica una parte muy importante del tiempo diseñando completamente los modelos lógicos y físicos antes de escribir ninguna línea de código. Sin embargo, con este modelo, el diseño se deriva de los test de funcionalidad, y es un proceso que discurre al mismo tiempo que el propio desarrollo. Por esto, está metodología de desarrollo encaja perfectamente en la metodología organizativa SCRUM.

MVC

Finalmente, teníamos que elegir una plataforma tecnológica para desarrollar el proyecto siguiendo esta metodología. Para ello, hemos elegido seguir el patrón Model View Controller , y en concreto la implementación de asp.net MVC. Las metodologías anteriores se pueden utilizar con cualquier plataforma, pero MVC proporciona un modelo ideal para realizar los test de una manera mucho más completa, probando no solo la lógica sino también la interacción con la interfaz de usuario. Pero sobre MVC, ya hablaremos en detalle en próximos posts.

Así que ya sabéis, durante un tiempo, hablaremos de nuestras experiencias con SCRUM, TDD y MVC.

Lucene para ASP.NET (Parte III). Búsqueda.

Tue, 22 Jul 2008 10:36:29 GMT

Siguiendo la serie de artículos sobre Lucene (Lucene para ASP.NET (Parte I). Introducción y Lucene para ASP.NET (Parte II). Indexación), dónde conocimos qué era Lucene y cómo indexar contenidos, durante este artículo vamos a hablar de la búsqueda, sin duda, el objetivo último que perseguimos.

Según la estructura del Document planteada en el artículo sobre Indexación, cuando queramos buscar algo atacaremos a los campos "Title" y "Text", pues son los que contendrán la información importante. Es decir, lo que queremos es "buscar palabras que se encuentran en el título o en el texto".

A continuación tenemos un método que busca en ambos campos y devuelve un listado de Document's:

public static List SearchDocuments(string sQuery)
{
    // Creamos el listado documents que vamos a devolver
    List documents = new List();

    // Abrimos el IndexSearcher con el Path del directorio que hace de índice. Aquí usamos una variable global.
    IndexSearcher searcher = new IndexSearcher(IndexPath);

    try
    {
        // Buscamos en Text
        QueryParser qpText = new QueryParser("Text", new SpanishAnalyzer());
        Query queryText = qpText.Parse(sQuery);

        // Buscamos en Title
        QueryParser qpTitle = new QueryParser("Title", new SpanishAnalyzer());
        Query queryTitle = qpTitle.Parse(sQuery);

        // Unimos ambos elementos: queremos que nuestro query se encuentre en uno de los dos sitios.
        // Si puede ser en los dos, mejor.
        BooleanQuery bq = new BooleanQuery();
        bq.Add(queryText, BooleanClause.Occur.SHOULD);
        bq.Add(queryTitle, BooleanClause.Occur.SHOULD);

        // La clase Hits es la clave. Es lo que nos devolverá la Search
        Hits hits = searcher.Search(bq);
        int totalHits = hits.Length();

        // Recorremos todos los Hits, recogemos el document y lo añadimos a nuestro listado genérico
        // Aquí es donde debería hacerse la paginación, etc.
        for (int i = 0; i < totalHits; i++)
        {
            Document document = hits.Doc(i);
            documents.Add(document);
        }
    }
    finally
    {
        searcher.Close();
    }

    return documents;
}

Como vemos, el código se autoexplica bastante.

Lo más importante es saber que QueryParser define dónde queremos buscar y con qué Analyzer, y Query define qué queremos buscar.

Con el BooleanQuery uniremos las búsquedas en ambos campos, indicándole mediante el SHOULD que los resultados deben encontrarse en al menos uno de los dos campos (Title o Text), pero que si puede ser en los dos, mejor que mejor.

Los resultados tras el searcher.Search(...) vienen en forma de Hits. Los Hits contienen el Document, pero también contienen otros campos interesantes como el Score que devuelve la puntuación de 0 a 100 o el Length que devuelve el número de resultados encontrados.

Como véis esto ha sido una búsqueda a pelo. Ahora quedaría paginar, filtrar los resultados con Score bajo, etc.