Últimamente estoy viendo algunas utilidades gratuitas bastante interesantes. El otro día os hablaba de Wink esa pequeña gran aplicación para crear demos. Esta vez uno de los programadores de Krasis (gracias Marcos) me ha descubierto esta estupenda aplicación: Virtual Dimension.

En pocas palabras: es un gestor de ventanas para el escritorio, gratuito, ligero y lleno de cosas buenas.

Los que uséis la interfaz gráfica de Linux habitualmente ya sabéis de que hablo. Los demás probadlo: no querreis volver al escritorio normal de Windows. Desde mi punto de vista este tipo de funcionalidad debería venir "de serie" en Windows, y no se explica que no sea así, ya que tampoco es algo tan complicado de hacer.

Sus características más importantes son las siguientes:

• Gestiona cualquier número de escritorios. Sin límite.
• Ajustes específicos para cada escritorio.
• Capacidad de mover ventanas entre escritorios y dejar alguna "fija" en todos.
• Teclas rápidas para cambiar de escritorio.
• ALT+TAB muestra todas las ventanas (como normalmente) o sólo las del escritorio que tengamos activo, a nuestra elección.
• Transparencias en las ventanas para localización rápida.
• Ventanas siempre visibles, semi-transparentes y minimizables al área de notificación.
• Funciona incluso en Windows 98 (si alguien lo usa aún)

En fin, super-recomendable. Lo puedes descargar desde aquí.

En las Powertoys gratuitas de Windows XP existe una aplicación que se llama Virtual Desktop Manager que hace algo similar, aunque tiene menos características, es tal vez menos ágil y está limitado a "sólo" cuatro escritorios. Aún así merece la pena verlo. Puedes descargarlo aquí

Microsoft ha publicado nuevos Starter Kits (SK). Se trata de proyectos listos para ser usados que incluyen todo el código fuente y documentación y que sirven para ilustrar técnicas de desarrollo sacando partido a las características de Visual Studio.

En este caso los nuevos SK son para Visual Studio 2005, e incluyen aplicaciones para Windows y para la Web.

En lugar de ponerlos en la página ASP.net, como era habitual, esta vez están directamente en una página dentro de MSDN. En ésta hay enlaces a cómo crear un SK y cómo instalarlos.

Dentro de los SK para Windows Forms sólo hay uno. Se trata de un gestor de información sobre películas que utiliza el servicio Web de Amazon.com para buscar entre los títulos disponibles en esta tienda en-línea. Ilustra técnicas como, por supuesto, llamadas a servicios web, enlazado a datos, almacenamiento local usando SQL Server 2005, etc...

En lo que se refiere a aplicaciones para la Web hay más variedad, aunque de momento sólo hay 3 nuevos SK. Éstos se llevan en página aparte.

Hay un creador de sitios Web personales que en realidad es el mismo que viene "de serie" con Whidbey y que seguro que muchos ya habrán visto. Hay también una nueva versión del conocido TimeTracker para gestión de partes de horas de trabajo en proyectos. Por fin, como novedad hay un SK que permite crear el stio Web de un Club o asociación. Incluye calendario, álbumes de fotos, foros y un directorio de miembros.

Esperemos que en breve haya nuevos SK disponibles que sean algo más avanzados, pero como comienzop está bien :-)

Por fin de vuelta tras una semana de viaje en la que, al estar fuera, no he podido actualizar el Blog...

He estado trabajando últimamente con una excelente herramienta para creación de demos y presentaciones a partir de capturas de pantalla que es gratuita y muy fácil de usar. Se llama Wink y se puede descargar desde http://www.debugmode.com/wink/.

Permite grabar todo lo que se hace en pantalla y luego anotarlo para crear guías paso a paso y similares. Genera el contenido en Flash o bien en un ejecutable para Windows, y encima es gratuita.

Como ejemplo he hecho un tutorial que explica, paso a paso, cómo crear un acceso directo que lance el explorador de Windows en la carpeta que nosotros queramos, como alternativa al atajo Windows + E. Como esta #"$|#  herramienta de blog no me deja publicar flash lo he colgado aquí.

¡Qué disfrutes de Wink!

En el anterior artículo sobre este tema, hace unos días, contaba los rudimentos de cómo se suben archivos a un servidor Web mediante HTTP usando sólo ASP.NET, inclyendo también un código de ejemplo sencillo que lo hacía. Entonces prometí que iba a comentar algunas pegas de esta implementación.

Se trata de problemas que normalmente no se comentan en los libros ni en la documentación directamente y que pueden volver loco a más de uno si se los encuentra durante un desarrollo. Los que voy a comentar en el post de hoy tienen que ver con la subida al servidor de archivos grandes.

- Limitación de seguridad por defecto

Una cosa que no se suele contarse es que la subida de archivos al servidor en ASP.NET está limitada por defecto a 4 MB. Si intentamos usar el código de ejemplo del artículo anterior para subir un archivo de más de 4 MB veremos que se produce un error. Se trata de una limitación de seguridad que trae ASP.NET que impide peticiones al servidor mayores de este tamaño (un envío de archivo no es más que una petición POST que envía como datos el contenido del propio archivo).

Para superar esta limitación es necesario tocar el archivo web.config de configuración de la aplicación ASP.NET. En concreto es necesario otorgar un valor al atributo maxRequestLength del nodo , así:

<HTTPRUNTIME maxrequestlength="12288" />

En este caso se establece el limite en archivos de 12 MB (12 x 1024) de tamaño.

- Consumo de memoria

Cuando ASP.NET acepta un archivo lo que hace es almacenarlo en memoria mientras no decidimos que hacer con él. esto es un problema grave con archivos grandes ya que la memoria consumida no se corresponde con el tamaño del archivo, sino que es sensiblemente mayor debido al modo en que se envía y se almacena (unas 5 veces mayor). Por eso si dejamos subir archivos muy grandes y tenemo sun sitio con mucho tráfico podemos tener problemas. Por ejemplo si tenemos cinco usuarios subiendo a la vez un archivo de 10 MB estaremos ocupando con estos procesos ¡alrededor de 250MB de memoria RAM!. ¡Ahí es nada!.

Ante esto poco se puede hacer lamentablemente salvo tal vez buscar algún tipo de componente de terceras partes que evite este problema. La verdad es que no les hubiera costado nada a los chicos de Microsoft hacerlo mejor y almacenar los archivos en una carpeta temporal de disco ¿verdad?.

- Errores de tiempo máximo superado

Las páginas ASP y ASP.NET tienen establecido un tiempo máximo para ejecutarse (por defecto 90 segundos) que, si se supera, se considera que la página está fuera de control (se ha "colgado") y se genera un error interrumpiendo su ejecución. Esto se hace para evitar que una página mal programada pueda consumir excesivos recursos del servidor incidiendo en el desempeño de las demás.

Nuevamente esto sólo es un problema con archivos grandes, claro.

Se trata de una cuestión complicada de resolver ya que nunca tienes ni idea de cuánto va a tardar en subir un determinado archivo. Dependerá del tamaño de dicho archivo y de la velocidad de las lñineas tanto del servidor (para aceptarlo) como del cliente (para enviarlo). Lo único que se puede hacer es asignar un valor suficientemente alto a la propiedad ScriptTimeout del objeto Server y rezar para que de tiempo a subir el archivo. No tengas miedo de asignar un valor alto a esta propiedad ya que sólo afecta a la página actualmente en ejecución y no a las demás. Sólo hay que tener en cuenta que el valor máximo aceptable es un día, es decir, 86.400 segundos.

- No se puede indicar el progreso de la subida

Se trata de otro problema debido a las limitaciones del componente que viene con ASP.NET. Hasta que acaba el proceso de subida de archivos no se obtiene información alguna de cómo va el proceso. es decir, es un "todo o nada", por lo que no se puede mostrar de ningún modo información sobre el proceso al usuario que sube el archivo.

La solución (parcial) en este caso, aparte de usar componentes de otra gente (claro), pasaría por enviar al principio de la página, antes de cualqueir otro procesamiento, el HTML necesario para que en el lado cliente se muestre un GIF animado con una barra de progreso ficticia o alguna otra animación.  Por lo menos de este modo no se le da la sensación al usuario de que no pasa nada y se evita su impaciencia.

Con todos estos problemas no pretendo hacer desistir anadie del uso del componente que viene con ASP.NET. nada más lejos de mi intención. Es gratuito, fácil de usar y en la mayor parte de los casos funciona sin problemas. Lo que quiero es que tengáis claro que no es lo más adecuado para utilizar en caso de trabajar con archivos muy grandes. Espero haberlo conseguido.

Hoy he leído este post en Microsiervos.com y la verdad es que me ha parecido la mar de simpático. Lo reproduzco aquí:

-----

Según el código civil español, si desapareces durante un año pueden declararte legalmente muerto. Bueno, en realidad parece que primero te declaran «ausente» y sólo pasados diez años pueden declarte «legalmente muerto», aunque hay algunas excepciones como sólo cinco años después para los mayores de 75 años, tres años para «ausente» si dejaste un representante legal y cosas así.

Si en Internet el tiempo pasa siete veces más rápido de lo normal, debido al efecto de los famosos «años-perro», entonces si abandonas tu bitácora durante 12 x 30 / 7 = 51 días podrían declararte «bitácorero legalmente ausente». Y si pasa 1 año y cinco meses, tu weblog estaría «legalmente muerto».

Eso quiere decir que si a día de hoy encuentras alguna bitácora con el último post anterior al 7 de noviembre de 2003, puedes con toda la razón y lógica internetera declararla legalmente bitácora muerta.

-----

Enlace original: http://www.microsiervos.com/archivo/weblogs/bitacoras-legalmente-muertas.html

En los tiempos de ASP 3.0 subir archivos al servidor "a pelo", es decir, sin usar controles de terceros para hacerlo era una tarea harto difícil. Se podía conseguir (nosotros en Krasis, por ejemplo, desarrollamos un componente puro ASP que lo hacía perfectamente), pero era muy complicado y no exento de problemas.

En ASP.NET esta tarea se ha convertido en algo mucho más sencillo. En realidad no tanto como algunos se piensan (dentro de un momento diré algo más sobre esto), pero desde luego fácil y rápido de implementar para las ocasiones más normales.

Para hacerlo basta con usar el control HtmlInputFile del espacio de nombres System.Web.HtmlControls, así:

<INPUT id=SelectorDeArchivos type=file runat="server">

Al colocarle el atributo de ejcución en el servidor luego podemos acceder a sus propiedades y métodos una vez enviado el formulario al servidor. Gracias a ello podemos acceder de forma simple a la información sobre el archivo enviado. Sólo hay una propiedad importante en este control:

• PostedFile: devuelve una referencia a un objeto HttpPostedFile, definido en System.Web que ofrece información sobre el archivo que se acaba de subir.

El objeto HttpPostedFile tiene varias propiedades y un método interesantes:

• FileName: indica el nombre y la ruta completa del archivo que hemos subido. No hay que fiarse de esto para validar los tipos de archivo subidos ya que es fácil cambiar la extensión de unejecutable para hacerlo pasar por uno de texto, por ejemplo. Es mejor usar la siguiente propiedad.
• ContentType: especifica el tipo MIME real del archivo enviado. Por ejemplo "text/plain" para archivos de texto, o "application/msword" para archivos de Word. Este es el verdadero tipo que hay que comprobar.
• ContentLength: el tamaño en bytes del archivo subido.
• SaveAs: método que guarda el archivo recibido en la ruta y con el nombre especificados.

Con estos elementos es muy fácil crear una página para permitir la subida de archivos a la Web. Pulsando aquí te puedes descargar un pequeño ejemplo que he hecho con WebMatrix que ilustra el uso de este control (ZIP, 1 KB).

Por cierto, se me olvidaba. Muy importante: el formulario de la página actual tiene que tener el atributo enctype establecido con el valor multipart/form-data, así:

<FORM encType=multipart/form-data runat="server">

De todos modos no todo es tan fácil. En el próximo post voy a explicar las limitaciones de este control y todos los problemas que podemos tener por utilizarlo, viendo así casos prácticos que se nos pueden presentar.

Permanece sintonizado :-)

Las vistas de SQL Server son muy útiles para utilizar consultas complicadas como si se trataran de simples tablas. Entre sus limitaciones, sin embargo, hay una que (a mi por lo menos) me resulta muy irritante: no se pueden ordenar. Es decir no se puede utilizar la cláusula ORDER BY en la sentencia SQL que define la vista.

Este truco permite saltarse las normas a la torera y utilizar ordenaciones de todos modos en las vistas. Y es que según la documentación la cláusula TOP de SQL siempre se puede usar con ORDER BY, incluso en las vistas, ya que si no no notendría mucho sentido ¿verdad?.

TOP sirve para obtener los 'x' primeros resultados de una consulta. Por ejemplo, si quiero obtener los últimos 1.000 registros de facturas de una tabla puedo escribir:

SELECT TOP 1000 * FROM Facturas ORDER BY NumFact DESC

Lo que muchas gente no sabe es que TOP admite una sintaxis alternativa que permite especificar un porcentaje de filas a devolver en lugar de un número absoluto. Esta es la cuestión que nos interesa ya que entonces basta con escribir:

CREATE VIEW FacturasAlReves
AS
SELECT TOP 100 PERCENT * FROM Facturas ORDER BY NumFact DESC
GO

para crear una vista de la tabla facturas que contiene todos sus registros ordenados en sentido inverso al normal.

Este es un ejemplo tonto, claro, pero lo que pretendo ilustrar es la técnica que nos permite saltarnos la restricción de orden de las vistas, que es usar TOP para obtener el 100% de los registros.

Interesante y útil ¿verdad?

Si tienes un Tablet PC las nuevas herramientas que ha puesto Microsoft a disposición pública te van a encantar. Las ha denominado Tablet PC Experience Pack, y son añadidos que complementan muy bien a las PowerToys que ya tiene Microsoft para este sistema operativo, ya que de hecho un par de herramientas de las incluidas son PowerToys mejoradas.

Ink Desktop: Permite la captura de información manuscrita directamente en el escritorio, sin necesidad de abrir un programa especial. Mucho mejor y más rápido que tomar notas de esas amarillas, y además más difícil de pasar por alto ;-)

Snipping Tool: Mejora de una de las Powertoys. Permite capturar porciones de la pantalla rodeándolas a mano, y luego comentarlas con tu propia letra para enviarlas por correo electrónico o guardarlas.

Ink Art: conviérte en un Picasso pintando directamente a mano en la pantalla con herramientas que simulan utensilios comune de los artistas, como pinceles, carboncillo, etc... También es una mejora de un Powertoy.

Otras utilidades son un juego de crucigramas que, para que no te aburras, descargará uno nuevo cada día de la red; el Media transfer, que permite la transferencia sencilla de multimedia entre tu PC de sobremesa y el Tablet; y una nueva versión del tema Energy Blue que trae una interfaz especial para manejar Windows Media Player con el lápiz de forma muy sencilla.

Aprende más sobre ellas usando el enlace del principio.

Un reciente encuesta en línea realizada por ComputerWorld  entre suscriptores de todo el mundo de empresas de más de 100 empleados ha revelado que el lenguaje de programación preferido por éstos es C# frente a Java.

En lo que se refiere a arquitecturas de desarrollo .NET también quedó por delante de las emás, seguida por Linux/UNIX y después Windows/COM/DCOM.

Algunos otros resultados interesantes:

• Un porcentaje bajísimo de los encuestados tiene pensado desarrollar aplicaciones en breve para Linux (4%), dispotivios inalámbricos (7%) o para sistemas de 64 bits (9%).
• Casi la mitad de los encuestados (48%) dicen que no utilizan UML en el diseño de sus aplicaciones dentro de su empresa.
• Más de la mitad (58%) están usando servicios Web en sus desarrollos, y sólo un 9% dijeron que no les interesaba esta tecnología.
• Sólo el 45% confiesa que utiliza entornos de desarrollo integrados en lugar del bloc de notas (35%).

Puedes ver los resultados completos de esta encuesta en la web de ComputerWorld.

Me acabo de enterar que, una vez más, Microsoft Corporation me ha designado como Most Valuable Professional durante un nuevo año. Así que estoy de enhorabuena :-)

Soy MVP Visual Developer ASP/ASP.NET.

Mi perfil en Microsoft

Cuando programamos una aplicación, aparte de hacer que ésta cumpla todos los requisitos puramente funcionales e implemente los algoritmos que sean necesarios, es igualmente imortante realizar un estudio sobre las posibles excepciones y errores que se puedan producir durante su ejecución. De este modo podremos responder elegantemente a estas situaciones, en lugar de permitir que nuestros usuarios vean un diálogo horroroso con detalles técnicos y se acabe la aplicación sin previo aviso.

Para ello añadimos cantidad de sentencias de gestión de excepciones try-catch-finally en todo el código, gestionando cada posible error o excepción.

Por muy bien que lo hagamos, sin embargo, siempre habrá cosas que se nos escapen y que produzcan el fatídico diálogo que mencionaba hace un momento. Para asegurarnos de que esto no ocurre podemos crear un gestor de errores universal que se ejecute de forma automática al producirse alguna excepción que no hemos gestionado adecuadamente.

Hacerlo es muy sencillo: basta con utilizar el método AddOnThreadException o la propiedad ThreadException de la clase Application. Este método recibe como argumento un delegado (puntero: palabra tabú) a una función con los parámetros adecuados que será la encargada de gestionar estos errores no atrapados. La definición estándar de esta función es:

void OnThreadException(object sender, ThreadExceptionEventArgs t)

Veamos un ejemplo:

Definimos una clase que albergará nuestro método gestor de excepciones universal:

public class MiCapturador
{
     public void MiErrorUniversal(object sender, ThreadExceptionEventArgs t)
    {
        //Aquí meto el código para gestionar la excepción...
        MessageBox.Show("Se ha producido un error");
    }
}

En este caso sólo muestro un diálogo mega-cutre, pero en una implementación real podríamos almacenar la información sobre el error en una base de datos o enviarla a un Servicio Web para estar inforamdos, además de mostrar un diálogo agradable al usuario informándole del evento.

Ahora que ya hemos definido el método, sólo resta asignarlo a la aplicación desde el método Main o en el evento OnLoad del primer formulario que se cargue, así:

MiCapturador micapt = new MiCapturador();
Application.ThreadException += new ThreadExceptionEventHandler(micapt.MiErrorUniversal);

Con esto conseguiríamos el efecto buscado. Este truco contribuye a crear aplicaciones estables y con calidad profesional.

OJO: no deberemos usar esto para ahorrarnos la gestión de las excepciones normales que debería haber en el programa. El código perezoso al final se acaba pagando caro ;-)