El otro día os comentaba las diferencias entre los proyectos de tipo Sitio Web y Aplicación Web en Visual Studio, y las implicaciones que ello tenía a la hora de trabajar, para ayudaros a decidir entre uno u otro.

Una de las «pegas» que le ponía al modelo de sitios Web era que al generarse una DLL por cada página y control, al final podíamos acabar con problemas de rendimiento por tener que haber cargado todas esas DLL en el proceso de la aplicación.

He puesto «pegas» entre comillas porque realmente desde mi punto de vista esta posible situación más que un problema es un exotismo, puesto que no me imagino ninguna aplicación Web realista que tenga miles de páginas (hablo de varios miles) y que no esté dotada del agún mecanismo de generación automática de páginas.

De hecho el único sistema que he visto que pudiera provocar esta situación es un sistema gestor de contenidos creado para un organismo oficial por una conocida empresa de consultoría (de cuyo nombre no quiero acordarme) y que se dedicaba a generar como páginas ASPX cada una de las páginas de contenidos que los usuarios iban creando. En mi opinión el proyecto no estaba demasiado bien hecho ni concebido (y no lo digo solo por este detalle) y desde luego para este caso concreto podrían haber aplicado otro tipo de técnicas para generar los contenidos de forma dinámica con alto rendimiento igualmente.

En cualquier caso. Este proyecto tenía miles de páginas generadas cuyos ensamblados que se iban cargando en memoria y degradando a largo plazo el rendimiento de la aplicación. Todas estas páginas de contenidos realmente no ejecutaban código alguno sino que se limitaban a mostrar HTML y, en algunos casos, etiquetas de tipo <% %> con alguna información.

¿Cómo podían evitar este problema de degradación del rendimiento?

La gente del equipo de ASP.NET consciente de esta posible situación indeseable la tuvieron en cuenta y diseñaron un ajuste que se le puede hacer a las páginas para evitar que se compilen. Se trata de la opción CompilationMode.

Este atributo se puede establecer en la directiva de cada página o control y puede tomar los siguientes valores:

· Always: las página o control se compilan siempre, y por lo tanto se genera un ensamblado.
· Never: no se compila, por lo que no se genera un ensamblado y no hay que cargarla en memoria.
· Auto: es ASP.NET en tiempo de ejecución quien decide si la página se compila o no, dando preferencia a que no se compile si no es necesario.

Así, por ejemplo, podemos definir en la directiva de una página lo siguiente para evitar su compilación:

<%@ Page CompilationMode=»Auto» %>

(Nota: no se admiten en la directiva de página los atributos CodeFile, AutoEventWireup o Inherits, porque no se genera código para la página)

En estas condiciones sólo se permite la interpretación en tiempo de ejecución de etiquetas de tipo <%# %> o <%$ %>, pero no otro tipo de código como eventos de página. Estas etiquetas de sintaxis declarativa de ASP.NET permiten utilizar bindings a datos (ej: <%# Bind(…) %> o <%# Eval(…) %>) y también otro tipo de expresiones declarativas como sustitución de recursos de localización o cadenas de conexión en controles enlazados, sin necesidad de generar código relacionado y compilarlo.

Así, por ejemplo, podemos escribir instrucciones como esta:

<

 

asp:Label ID=»Label1″ runat=»server» Text=»<%$ Resources:Recursos, Saludo %>«></asp:Label

>

aunque la pongamos en modo de comilación «Never» para que no se genere el ensamblado, y todo funcionará correctamente. Si metemos cualquier tipo de código en la página se producirá un error al intentar compilar la aplicación desde Visual Studio.

Así, en el ejemplo de páginas generadas que lo único que hacían era mostrar contenido pre-generado (o incluso aunque éste fuera sacado de una base de datos con una expresión de enlazado del tipo <%# %>), si le ponemos este atributo CompilationMode a Never conseguiremos que no se genere ni se cargue en memoeria el ensamblado de la página, y un consiguiente aumento de rendimiento, tal y como se indica en la documentación.

Configurar el modo de compilación globalmente

Siguendo con nuestro ejemplo de páginas generadas, si éstas se almacenan todas dentro de una misma carpeta o en una estructura de carpetas que cuelguen de una única carpeta raíz, es posible definir el modo de compilación para todas ellas al mismo tiempo usando el archivo web.config:

De este modo podemos establecer el modo al mismo tiempo para todas las páginas que bajo la influencia de este web.config y no tenemos que establecerlo una por una.

Hay que tener cuidado que en ninguna de las carpetas que se ven afectadas haya páginas que sí contengan código o fallará la compilación del proyecto. También hay que tener cuidado si alguna de ellas utiliza una Master Page que tenga código, pues surgirán conflictos también.

En resumen

Para casos muy particulares de sitios enormes en los que necesitemos asegurar que no degradamos el rendimiento, esta técnica poco conocida puede resultarnos de gran ayuda. Tenla en cuenta si te encuentras algo así.

¡Espero que te sea útil!

Hoy toca cuña publicitaria, pero seguro que a muchos os interesa 🙂

Estos días hemos lanzado tres nuevos cursos en campusMVP que tratan temas, en mi opinión, de gran interés para los programadores:

– Creación de aplicaciones ricas de Internet con Silverlight 2.0:

Duración: 6 semanas
Nivel: Intermedio

Silverlight 2.0 nos proporciona la base para crear aplicaciones ricas para internet (RIA) multi-navegador y multi-plataforma, integrándose con la amplia variedad de tecnologías webs actuales como DHTML, ASP.NET 3.0, AJAX, JavaScript, etc. Nos ofrece un modelo de programación completo mediante AJAX, lenguajes .NET y lenguajes dinámicos como IronPython y IronRuby.

Silverlight se presenta a nosotros como una tecnología capaz de aunar en nuestras aplicaciones gráficos, multimedia, animaciones, enlace a datos y comunicaciones de un modo rico y orientado al usuario final dándole una gran relevancia al diseño de interfaces y a los conceptos de usabilidad.

Este curso te dará los conocimientos necesarios para desarrollar aplicaciones RIA con Silverlight 2.0 desde Visual Studio 2008 y utilizando Microsoft Blend, la herramienta específica para diseño de interfaces avanzadas. Además también se analizan tecnologías relaciondas como DeepZoom para que tengas una amplia visión de la nueva plataforma. 

Toda la información aquí

– Instalación, uso y extensión de aplicaciones Open Source ASP.NET:

Tradicionalmente el Open Source se ha asociado con tecnologías que no son las de Microsoft, pero la realidad es que en el mundo Microsoft existe el Open Source también desde siempre y hay muchas comunidades como CodePlex.com que alojan miles de proyectos interesantes de código abierto.

Este curso te servirá para aprender a sacarle partido a tres aplicaciones Web de código abierto muy conocidas y utilizadas que están desarrolladas usando la plataforma .NET: gestión de contenidos (Umbraco CMS), comercio electrónico (dashCommerce) y blogs (BlogEngine).

Así le sacarás partido desde el primer momento, aunque no tengas un nivel alto de ASP.NET, pues el curso te explica todo lo necesario para poder instalarlas, configurarlas, utilizarlas y extenderlas.

Además, y esto es importante, con el curso regalamos un módulo para dashCommerce que te permitirá procesar pagos a través de la pasarela de pagos 4B en bancos españoles. El motivo es que todas estas aplicaciones Open Source suelen usar como pasarela de pagos Paypal Professional, que sóloestá disponible en EEUU, y te limitan mucho a la hora de usarlas en España. Con esto se te acabó el problema.

Toda la información aquí

– Inteligencia de Negocio con SQL Server 2005 y 2008:

Este curso está orientado a preparar a los alumnos en el desarrollo de soluciones de Business Intelligence con SQL Server y toca todas las fases habituales de desarrollo:

• Diseño de Data Warehouse y estructuras de análisis de datos
• Carga, homogeneización y pre-procesado de datos desde los orígenes de información.
• Generación y distribución de informes y resultados de los análisis.

Se ha incluido también un módulo para aprender a trabajar también contra bases de datos de Oracle, y no estar cerrados sólo a SQL Server.

Todos estos módulos incluyen laboratorios prácticos que permiten a los alumnos conectarse a Internet para trabajar con las herramientas en un entorno real sin necesidad de tener instalado el software en sus propios equipos. Además se pueden descargar para su visualización y uso sin conexión a Internet.

El curso incluye un año de acceso al material.

Toda la información aquí

¡Animaos a hacerlos!

Ya está disponible en Channel9 un nuevo vídeo que he hecho sobre las bibliotecas del lado cliente de AJAX y un montón d cuestiones relacionadas con JavaScript en Visual Studio 2008. Enseño a llamar a servicios Web desde JavaScript, cómo generar biblitecas .js con soporte para Intellisense en Visual Studio, y unas cuantas cosas más.

Se ve con una calidad estupenda, pero debes ponerlo a pantalla completa usando el botón de la derecha que aparece en la parte de abajo cuando pasas por encima con el ratón (el que tiene las flechas en esta figura):

Pulsa la imagen para ir la página del vídeo

Puedes verlo en streaming directamente desde la página (necesitarás Silverlight 2.0) o bien descargártelo en diversos formatos:

En la página podrás encontrar otros vídeos intereantes, muchos de los cuales los han hecho también otros tutores de campusMVP, como Unai Zorrilla, Bruno Capuano, o Alberto Población.

Seguro que dentro de poco habrá alguno más de los míos, de los que os iré informando aquí… ¡Qué os sea útil!

Como seguramente sabrás, con la aparición de Visual Studio 2005 el modelo de troyectos Web cambió completamente. Se pasó de un modelo «code-behind» a un modelo «code-beside» (que ahora explicaré con calma), y la estructura de aplicaciones anteriores dejó de ser compatible con ASP.NET 2.0. Esto hacía complicado, sobre todo, la migración de las aplicaciones desde ASP.NET 1.x a las nuevas versiones, y desató muchas protestas (aunque muchos protestaron simplemente por inmovilismo y reticencia al cambio). Ante ello Microsoft respondió unos meses después sacando los Visual Studio 2005 Web Application Projects. Éstos añadían compatibilidad con el modelo anterior a Visual Studio 2005, y de hecho se convirtió en una parte estándar del entorno al salir el Service Pack de VS2005. Ahora forman parte integrada desde el principio de Visual Studio 2008 también.

A la hora de crear un proyecto nuevo para la Web podemos elegir entre crear un sitio Web (opción por defecto):

o crear un proyecto de tipo Aplicación Web, para lo cual hay que ir por el diálogo «normal», como si fueras a crear una aplicación de Windows o cualquier otro proyecto:

Pero, ¿qué diferencia hay y cuál me conviene utilizar?

Primero voy a comentar las diferencias más resaltables, en mi opinión, por apartados

1.- Acceso al código fuente

En las aplicaciones Web el código completo de la página está disponible en el/los archivo(s) .cs o .vb correspondiente(s) a la página. Me estoy refiriendo aquí a las declaraciones de los controles y otros entresijos de la página que realmente deberían ser transparentes para los programadores.

En los proyectos de tipo Sitio Web esto se esconde completamente y todo este código de «fontanería» (como dicen los yankees) se genera dinámicamente en tiempo de compilación. Sólo vemos nuestros manejadores de eventos y métodos de página,pero no todo el código que hay por debajo para declarar controles, sus eventos, etc… Es lo que se llama «code-beside», ya que el código se genera en tiempo de compilación en una clase parcial extra que nosotros no vemos y que se llama igual la página pero precedida por un guión bajo (por ejemplo _Default).

Esto hace que algunos piensen que pierden control cuando la realidad es que, salvo en contadísimas ocasiones (no me preguntes cuáles), a ese código automático no le vas a tocar y además tampoco conviene hacerlo pues en cada cambio a la página original podrías perderlo, ya que se genera automáticamente igual.

De hecho cuando generas un proyecto de aplicación web esta clase parcial la puedes ver en el archivo mipagina.aspx.designer.cs o similar, pero como puedes comprobar en este caso, poco más que verlo podrás haer con él y no aporta nada (a mi por lo menos).

Una cosa que sí puede ser importante respecto al código fuente es que en los sitios web el código de nuestras clases que no pertenezca a una página sólo puede estar ubicado en la carpeta especial App_Code y sus subcarpetas. En las aplicaciones web puedes tener clases en donde quieras y todas ellas se leerán y compilarán sin problema. Desde mi punto de vista esto sólo es una ventaja si estás migrando código viejo de 1.x, porque si se trata de un proyecto nuevo me parece mucho más ordenado -y por lo tanto mucho menos propenso a errores o despistes- el tener todo el código ordenado en una misma carpeta. Además en proyectos grandes el código realmente lo tendrás repartido por otros proyectos de biblioteca de clases (que generan DLLs) determinando la capa de negocio, etc…

Por otro lado los sitios web puedes abrirlos desde Visual studio sin necesidad de tener un archivo de proyecto asociado a éstos (un .csproj o .vbproj). Simplemente navegas hasta la carpeta y la abres y ya puedes trabajar. En las aplicaciones Web, al igual que en 1.x, necesitas estos archivos. Mucho más cómodo lo primero y más fñacil transportar los proyectos entre equipos.

2.- Compilación

En los proyectos de Sitio Web al precompilar la aplicación se genera una DLL por cada página o control de la aplicación, las cuales van dentro del directorio Bin. En los proyectos de tipo Aplicación Web se genera una única DLL que contiene el código completo de la aplicación, la cual se debe cargar en memoria sea necesario todo el código o no. En mi opinión es más interesante lo segundo por varias razones, pero sobre todo por un uso más eficiente de la memoria ya que sólo se carga lo que se necesita.

Además hay otra cuestión y es que si haces un cambio en una única página en el caso de las aplicaciones web tienes que desplegar la DLL de toda la aplicación que puede ocupar muchos megas, todo por un simple cambio, mientras que en el otro caso puedes copiar simplemente la DLL correspondiente a esa página o control concretos y ya llegaría.

Es cierto, usando DLLs independientes el rendimiento puede bajar un poquillo en la carga inicial de cada una de ellas mientras que en el otro caso sólo se carga una DLL, pero creo que las ventajas superan ampliamente este inconveniente. Por otro lado también es cierto que si hay que realmente cargar todas las DLL independientes en memoria éstas pueden llegar a ocupar más memoria que la DLL única, pero por otro lado si sólo se usan algunas partes de la aplicación en un momento dado el uso de memoria es inferior en el caso de los sitios web.

Finalmente hay un problema que se da cuando tenemos sitios web muy grandes, con miles de páginas, y hay que cargar todas esas DLLs en memoria, ya que cuando se trata realmente de miles de DLLs el rendimiento se degrada e incluso hay un límite en el número que podemos de ellas cargar. De todas formas cuando hay miles de estas páginas normalmente será porque éstas se generan automáticamente por algún motivo (no es algo muy usual) y existe una solución muy sencilla para resolverlo. De este tema concreto hablaré en el próximo post.

3.- Uso de Master Pages

Las Master Pages (o páginas principales como lo han traducido, horriblemente en mi opinión) son una de las características más interesantes de ASP.NET 2.0 ya que te permiten reutilizar la distribución y funcionalidad de una o varias plantillas entre diversas páginas de tu aplicación. Si ya has definido al menos una Master Page en tu sitio web, al añadir una nueva página ASPX tienes un diálogo como este:

Si te fijas, en la parte inferior hay una marca para seleccionar la Master Page que quieres utilizar, dándote a escoger de una lista de las disponibles al agregar la nueva página. Esto facilita mucho el trabajo.

Sin embargo en las aplicaciones Web, aunque las Master Pages están soportadas, el añadirlas no es tan inmediato, al emnos a primera vista. De hecho esto lo cuento porque la primera vez que las utilizas te puedes ver despistado.

La forma más directa y rápida de añadir una nueva página que haga uso de una Master Page existente es utilizar un elemento del menú contextual de éstas que puede que pase inadvertido:

Al hacerlo se crea una página ASPX que utiliza como MP la seleccionada en el menú contextual. Y es que en los proyectos de aplicación Web se dispone de un tipo especial de página ASPX llamado Content Page o Página de Contenidos que sirve para estos propósitos. Así, al añadir una nueva página podemos escoger en el diálogo entre ambos tipos, pero hayq ue darse cuenta de ello:

En los sitios web esta distinción artificiosa no existe y todas las páginas son iguales a los ojos del programador 🙂

4.- Uso de la funcionalidad Profile

Otra cosa interesante de ASP.NET 2.0 o superior es la posibilidad de definir de antemano ciertas propiedades que queremos asociar a los usuarios para manejarlas como si se tratara de sus preferencias. Estas preferencias se manejan con la clase Profile y deben estar coordinadas con la definición de las mismas en el web.config. Resulta que en las aplicaciones Web no ofrecen funcionalidad para definir estas propiedades en tiempo de diseño y además la clase Profile no se añade a las páginas automáticamente. No funcionaba en la primera versión liberada, no funcionó en el Service Pack de VS2005 y, sorprendentemente, no funciona tampoco en Visual Studio 2008.

Por suerte el bueno de Joe Wrobel, de Microsoft, ha creado un proyecto llamado «Web Profile Builder for Web Application Projects«, que permite añadir esta funcionalidad a las páginas ASPX de nuestros proyectos de aplicación Web. Pero vamos, no deja de ser un parche que debemos arrastrar y que no está soportado oficialmente.

Mi opinión

Si debes migrar de ASP.NET 1.x usa aplicaciones Web. Si empiezas un proyecto nuevo mejor usa un sitio Web.

¿Y tú qué opinas?

Hay una cosa que me saca de quicio cuando estoy trabajando en una máquina virtual. Resulta que cuando estás usando un editor de texto dentro de una maquina virtual en Virtual PC (vale cualquiera: tanto Word como el editor de código de Visual Studio o un cuadro de texto en una página Web, por ejemplo) el cursor desaparece de la vista, por lo que resulta imposible seleccionar texto con el ratón o simplemente ir con un clic a la línea que quieres. Como el cursor no se ve no puedes apuntar. Esto pasa independientemente del sistema operativo: tengo máquinas virtuales con Windows Xp, Windows 2003, Windows 2008 y más recientemente también con Windows 7. en todas igual. Me pone malo.

Lo primero que piensas es que cambiando este ajuste del ratón:

Todo solucionado ¿no?. Pues no. Aunque marques esto tanto en la maquina anfitriona como en el sistema huesped sigue pasando lo mismo, ¡grrrr! 🙁

La solución la encontré el otro día de casualidad: utiliza la combinación de cursores de «Windows Black». Si cambis los ajustes para que la use, así:

Problema solucionado, ahora sí 🙂

Sé que es una tontería, pero os aseguro que a mi me hace el trabajo más sencillo y espero que a alguien más le resulte útil.

Saludos!

Hoy me he encontrado con un producto que me ha parecido, a simple vista, impresionante. Se trata de Stimulsoft Reports Designer.Web.

Se trata de un complemento para el produto de generación de informes que tiene esta empresa -para mi hasta ahora desconocida- y que permite hacer la edición directa de los informes en cualquier navegador. Funciona en Internet Explorer, Firefox, Opera, Safari, etc… ya que estña hecho en Flash.

Tiene todo tipo de detalles, empezando por la interfaz de usuario. Os dejo algunas capturas:

 

No dejes de probarlo on-line.

El producto es comercial pero tiene un precio, en mi opinión, muy razonable y creo que merece la pena echarle un vistazo.

Ya he escrito en otras ocasiones sobre la cuestión de modificar la salida de las páginas ASPX y los controles, para poder modificarla a nuestra voluntad sin necesidad de tener acceso al código fuente (ver enlaces al final del post).

En esta ocasión voy a comentar una característica muy poco conocida de los controles que permite modificar su salida directamente, sin necesidad de heredar de ellos (técnica habitual) ni otras técnicas complicadas. Lo que haremos será sacar provecho a un método de la clase System.Web.UI.Control supuestamente pensado sólo para uso interno, pero que Microsoft ha dejado como público y por lo tanto acesible directamente a cualquiera.

Se trata del método SetRenderMethodDelegate. Éste permite asignar un delegado de una función de tipo RenderMethod que sustituirá al método de renderizado del control en cuestión. El método propio que definamos para asignar con SetRenderMethodDelegate toma dos parámetros: un HtmlTextWriter que utilizaremos para generar la salida del control, y una referencia al control cuyo método hemos sustituido.

Veámoslo con un ejemplo sencillo. Crea una página nueva y añádele una etiqueta, un cuadro de texto, un botón y otra etiqueta debajo, así:

Lo que haremos será que al pulsar el botón se mostrará «Hola» y el nombre introducido en el cuadro de texto en la segunda etiqueta que hemos añadido, así:

    protected void Button1_Click(object sender, EventArgs e)

    {

        Label2.Text = «Hola « + TextBox1.Text;

    }

Más sencillo imposible.

Vale. Ahora vamos a modificar el HTML que renderiza la segunda etiqueta para que, si hay algo escrito en el cuadro de texto, se haga caso omiso del renderizado por defecto de Label2 (que pondría «Hola » seguido del texto introducido en el cuadro de texto), y ponga otra cosa cualquiera.

Lo que haremos es crear un método propio de renderizado que se ciña al delegado RenderControl:

    protected void RenderPropioParaLabel(HtmlTextWriter output, Control container)

    {

        if (TextBox1.Text != «»)

            output.Write(«<b>Aquí</b> pongo lo que me da la gana « + TextBox1.Text);

    }

Ahora, en el evento Load de la página asignamos este método como método de render del control:

    protected void Page_Load(object sender, EventArgs e)

    {

        this.Label2.SetRenderMethodDelegate(this.RenderPropioParaLabel);

    }

Si ahora ejecutamos la página veremos que en lugar del texto asignado en el evento de pulsación del botón, lo que tenemos es una frase como esta: «Aquí pongo lo que me da la gana, Jose», con la primera palabra en negrita.

Evidentemente este ejemplo es una tontería, hecha sólo a modo de prueba de concepto de cómo hacer esto. Esta técnica sirve para modificar el renderizado de un control en una página concreta en la que el HTML que genera por defecto no es el que nos interesa.

Una limitación importante de este técnica a tener en cuenta es que no podremos obtener el renderizado por defecto del control y luego moificarlo (para esto hay otras técnicas, ver enlaces abajo), sino que tendremos que generar directamente todo el nuevo HTML para el control que estamos interceptando. Por supuesto no podremos llamar al método Render del control para obtener su HTML por defecto ya que éste lo que hace es llamar de nuevo a nuestro método de Render que ha sustituido al original, y entraríamos en un bucle infinito (prueba a poner container.Render() dentro de tu método de renderizado, ya verás).

Otra cuestión importante que debemos tener en cuenta es que esta técnica no funcionará con todos los controles, ya que depende de cómo estén éstos implementados internamente. Mientras el método Render del control llame al método Render del control base System.Web.UI.Control entonces funcionará. Si omite esta llamada (no es obligatorio en absoluto), entonces no funcionará. Lable llama al método de la base, pero la mayoría de los controles no lo hacen.

Entonces ¿para qué nos puede servir más allá de las etiquetas (que sería algo más bien pobre)?

Pues por ejemplo, la clase Page que hereda también de Control puede usar esta técnica, así que se pouede usar como alternativa a lo explicado en el primer artículo reseñado abajo.

Además hay controles sencillos que forman parte de controles más complejos y que se pueden modificar de este modo. Por ejemplo, los controles que representan las celdas de una tabla en una rejilla. Un ejemplo interesante de esto es modificar la cabecera de un GridView de modo que se renderice de otro modo y añada por ejemplo cabeceras extra dea agrupamiento.

En general podremos usar esta técnica con controles en los que nos fijemos en su código fuente y usen directamente el método Render de la clase base System.Web.UI.Control, que son más de los que parece, y la mayoría son controles contenedores de otros o controles muy sencillos.

Esta técnica es la que usa la propia infraestructura de ASP.NET para evaluar los bloques de codigo en el marcado de la página que son del tipo <% %> y <%= %> (no así las expresiones de binding <%# %> que funcionan de otro modo, en tiempo de ejecución). Si vamos al directorio temporal de ASP.NET y examinamos el código fuente generado automáticamente para cualquier página podemos verlo de forma clara.

Otros textos relacionados:

• 
  
  Cómo modificar la salida de una página a nuestra voluntad
  
  
• 
  
  Cómo enviar los resultados de un control Web a una cadena
  
  
• 
  
  Cómo forzar un determinado adaptador de rendering en ASP.NET 2.0

Ya está disponible en Channel9 mi vídeo sobre cómo optimizar la descarga de archivos .js en aplicaciones Web gracias a la característica específica incluida a tal efecto en el SP1 de .NET 3.5.

Se ve con una calidad estupenda, pero debes ponerlo a pantalla completa usando el botón de la derecha que aparece en la parte de abajo cuando pasas por encima con el ratón (el que tiene las flechas en esta figura):

Pulsa la imagen para ir la página del vídeo

Puedes verlo en streaming directamente desde la página (necesitarás Silverlight 2.0) o bien descargártelo en diversos formatos:

En la página podrás encontrar otros vídeos intereantes, muchos de los cuales los han hecho también otros tutores de campusMVP, como Unai Zorrilla o Alberto Población.

Dentro de poco habrá alguno que otro más de los míos, de los que os iré informando aquí… ¡Qué os sea útil!

Pues sí, eso es lo más apropiado que se puede decir de mi en los últimos días si juzgamos por mi indumentaria:

Nótese el gesto de apretar la garganta del enemigo
usando la fuerza, friki a tope la foto, jeje

Y es que -13º bajo cero es lo que tienen. Por fin he logrado tomarme mi primera semana de vacaciones del año 2008, que coincidió paradójicamente con la última del mismo. Como cada año una semanita blanca en los Alpes, en esta ocasión un poco más al sur que de costumbre, para disfrutar de los cientos de kilómetros esquiables de la zona del Alberg en Austria. La verdad es que este tipo de vacaciones se parecen más a un campamento militar (por los horarios de ski a los que nos sometemos) que a unas verdaderas vacaciones, pero en mi caso lo que necesito siempre es descansar la cabeza y no el cuerpo, así que encantado:

Aunque sólo sea por los paisajes
merece la pena ir y desconectar

Y no faltan terrazitas en las que descansar
y tomarte unas copichuelas a cualquier hora

Además he tenido tiempo de descubrir, de forma totalmente casual, la música de la deliciosa Gabriella Cilmi y de leerme «Why Software Sucks», de David Platt, cuya lectura recomiendo encarecidamente a todo el que trabaje en el mundo del software, sea programador o no.

Estos días alejado del e-mail, de los ordenadores y hasta del teléfono móvil me han hecho recargar las pilas y espero que en los próximos días retome con fuerza toda mi actividad habitual, incluyendo este blog. Permanece en sintonía 🙂