Como ya he comentado extensamente por aquí, T4MVC es una herramienta imprescindible a la hora de evitar “cadenas mágicas” cuando desarrollamos sistemas con el framework MVC.

A pesar de sus innumerables virtudes, desde sus comienzos este proyecto arrastra una molesta y pesada carga, asociada a la forma en que Visual Studio utiliza las T4: en principio sólo se ejecutan, y generan código por lo tanto, cuando el archivo de la plantilla es modificado.

David Ebbo, el creado de T4MVC, aportó una solución transitoria al problema incluyendo en la propia plantilla el código para engañar al IDE, haciéndole creer que el archivo .tt estaba siendo modificado continuamente, y forzando así el proceso de generación de código. Aunque válida, resultaba un poco molesto tener el archivo siempre abierto para que este proceso funcionara.

Hace unos días, David comenta en su post “A better way to auto-run T4MVC when you build” la solución propuesta  por Joachim Lykke Andersen y que describe en su entrada “How to run T4MVC on build”, consistente en la creación de una macro de Visual Studio capaz de tomar el control antes del inicio de la compilación, e invocar la herramienta personalizada de generación de código.

Y de hecho, tanto ha convencido esta nueva solución a David, el padre de la criatura, que está considerando seriamente la eliminación de la solución de mantener el archivo continuamente modificado en favor de ésta, mucho más limpia.

El procedimiento es el siguiente. En primer lugar, accedemos al entorno de desarrollo de macros, pulsando ALT y F11, y seleccionamos a continuación MyMacros > EnvironmentEvents.

Aparecerá un módulo VB sobre cuyo cuerpo pegamos la siguiente porción de código que, como se puede observar simplemente introduce una lógica al iniciar la compilación mediante la cual se localiza el archivo de plantilla “T4MVC.tt” y se invoca a su herramienta personalizada, en este caso, el generador de código T4:


Si aparece un error indicando que no existe la clase VSProjectItem, basta con incluir la referencia apropiada, utilizando la solución ofrecida por el propio entorno:

Estando todavía calentito el horno del que acaba de salir ASP.NET MVC 2, es curioso conocer algo sobre el próximo plato que están preparando Haack y su equipo: ¡ASP.NET MVC 3!

Ya se han publicado algunas de las líneas y objetivos que guiarán los futuros desarrollos y determinados detalles que probablemente serán incluidos, aunque obviamente todavía pueden variar sustancialmente. Las principales áreas de atención son en estos momentos:

• aumentar la productividad de los desarrolladores,
• facilitar aún más el uso de Ajax,
• incluir mejoras arquitecturales,
• y aumentar el rendimiento.

El aumento de productividad irá ligado a la introducción de un nuevo conjunto de helpers destinados a realizar tareas muy comunes en el desarrollo de aplicaciones web, como la implementación de rejillas de datos (grids) paginados.

Asimismo, se dará soporte a nuevos atributos de validación además de los ya incluidos en las anotaciones de datos de ASP.NET 4.

Otra línea en estudio es la introducción de herramientas basadas en línea de comandos, alternativas a las incluidas en Visual Studio.

Para facilitar el uso de Ajax se introducirán nuevos helpers que simplifiquen la implementación de escenarios habituales, como los controles de selección de fecha o cuadros de edición con auto-completado.
También se considera interesante ampliar los helpers existentes para permitir la actualización parcial de varias zonas de la página, e incluir soporte para plantillas en cliente, que permitan añadir el marcado muy rápidamente a datos retornados en formato JSON desde el controlador.

Desde el punto de vista arquitectural, se planea seguir flexibilizando el framework, permitiendo nuevos puntos de inyección de dependencias, como la instanciación de clases del Modelo desde el binder, o en filtros de acción.

Se prevé también la creación de una factoría de controladores para MEF (Managed Extensibility Framework) que permitan ampliar las funcionalidades de un sistema mediante sus sencillos mecanismos de extensibilidad, sin necesidad de recompilar.

Se incrementarán también las herramientas de generación de andamiaje de aplicaciones, para acelerar la implementación de escenarios comunes, como los habituales CRUD.

Y respecto al rendimiento, el equipo está estudiando nuevas técnicas para mejorar el cacheo de respuestas, y soluciones como aumentar el control sobre el estado de sesión, permitiendo activarlo o desactivarlo para mejorar la eficiencia.

En cualquier caso, lo que sí ha dejado claro Phil es que ASP.NET MVC 2 será la última versión del framework con soporte para ASP.NET 3.5 SP1.

Fuente: Roadmap de ASP.NET MVC.
Publicado en: Variable not found.
Hey, ¡estoy en twitter!

Este post es una continuación de 30 Leyes epónimas relacionadas con el desarrollo de software.

11. Ley de Linus

Dados suficientes ojos, todos los errores son obvios

Pues sí, Linus Torvalds, uno de los más famosos artífices de Linux tal y como es conocido hoy en día, no sólo desarrollaba software, también emitía este tipo de aseveraciones en las que exponía las ventajas del modelo de desarrollo cooperativo y abierto frente al propietario; otros simplemente ven esta teoría como una barbaridad desde el punto de vista de la seguridad y mantenimiento de los sistemas.

Aunque la frase fue cosa de Linus, fue Eric S. Raymond, un hacker a la antigua usanza, el que la popularizó y le dio el nombre de su creador.

12. Ley de Reed

La utilidad de grandes redes, y en particular las sociales, crecen exponencialmente con el tamaño de la red

David P. Reed, científico americano, enunció esto que parece obvio en los tiempos actuales dado el tamaño y utilización de este tipo de redes. En esta entrada de la wikipedia podéis encontrar una introducción del soporte teórico en el que se basa, que explica en esencia la facilidad con la que crece el número de subgrupos posibles entre usuarios en relación al número de usuarios o de pares.

13. Ley de Moore

La potencia de los ordenadores se duplica cada dos años, reduciendo además su coste

Repetida hasta la saciedad en revistas de cacharreo, y constatada desde hace décadas, fue promulgada por Gordon Earl Moore, quien por cierto es co-fundador de Intel, fijaos si lo tenía claro el muchacho, en 1965 (!). No sé si entonces utilizó la bola de cristal, era una declaración de intenciones, o simplemente es un genio, pero desde luego su ley es una referencia de la medida del avance en los ordenadores y demás dispositivos basados en tecnología similar, y un objetivo mínimo a cumplir.

14. Ley de Wirth

El software se ralentiza más deprisa de lo que se acelera el hardware

Brillante la frase de Niklaus Wirth, que allá por el año 1995, aún sin conocer Windows Vista, observó su entorno y predijo la situación actual: cada vez el software es más lento y pesado, a pesar de que según la Ley de Moore tendría que ser al contrario. Este señor, una eminencia, es conocido sobre todo por haber dirigido la creación de los lenguajes Pascal, Modula y algunos otros menos difundidos.

¿Será coincidencia que en ese mismo año, 1995, fue el lanzamiento oficial de Java? ;-P

15. Ley de Zawinski

Todo programa intenta expandirse hasta que pueda leer emails. Aquél que no pueda ser expandido hasta ese punto, será sustituido por otro que sí tenga esa capacidad

Lo que más me ha llamado la atención de Jamie Zawinski aparte de su metafórica ley que critica el crecimiento, a veces sin sentido, del software, es su página web personal. No os la perdáis, pues es bastante indicativa del tipo de individuo de que se trata, todo un friki, padre entre otros de una versión de Netscape, Grendel, Netscape Mail & News, Lucid Emacs, etc. También es curioso que es propietario de un club nocturno en San Francisco, este sí que sabe ;-)

16. Las tres Leyes de Clarke

Primera Ley de Clarke

Cuando un anciano y distinguido científico afirma que algo es posible, probablemente está en lo correcto. Cuando afirma que algo es imposible, probablemente está equivocado.

Segunda Ley de Clarke

La única manera de descubrir los límites de lo posible es aventurarse hacia lo imposible.

Tercera Ley de Clarke

Cualquier tecnología lo suficientemente avanzada es indistinguible de la magia.

El conocido científico y escritor británico Sir Arthur Charles Clarke enunció estas tres leyes porque, según comentaba, "si tres leyes fueron suficientes para Newton, modestamente decido parar aquí".

Arthur C. Clarke fue autor de un gran número de libros, relatos y obras de divulgación, destacando su novela y participación en el guión de 2001: Una odisea en el espacio.

17. El principio de Dilbert

Las compañías tienden a ascender sistemáticamente a sus empleados menos competentes a cargos directivos para limitar así la cantidad de daño que son capaces de provocar

Este complemento perfecto para el Principio de Peter fue observado por Scott Adams, autor de Dilbert, una popular tira cómica sobre el mundo de la empresa que se publica en 1200 periódicos de todo el mundo.

Scott Adams es considerado uno de los 50 pensadores más influyentes en el mundo de la empresa, incluso por encima de personajes como Steve Jobs o Al Gore. Se trata, además, de un epónimo curioso en cuanto a que su nombre no proviene directamente de su autor, sino de la obra de su autor.

18. Ley de Gilder

El ancho de banda aumenta a un ritmo tres veces superior a la potencia de los ordenadores

Pues sí, cualquiera lo hubiera dicho hace unos años... pero la verdad es que hoy en día la velocidad en las conexiones a la red son increíbles. Y por suerte, sin subir proporcionalmente el coste ;-)

George Gilder es un controvertido escritor e intelectual americano, entusiasta de la tecnología e internet, que en la actualidad dirige el Gilder Technology Report, un sitio exclusivo de información de ámbito económico y tecnológico. Según comentan, "sus hijos no estudian español, sino C++" (visto en Wikiquote).

19. Ley de Amdahl

El incremento de velocidad de un programa utilizando múltiples procesadores en computación distribuida está limitada por la fracción secuencial del programa

Esta ley, de gran aplicación en el cálculo de rendimiento de sistemas cuando uno de sus componentes es mejorado o en contextos de procesamiento en paralelo, fue enunciada por Gene Myron Amdahl en 1967, en sus tiempos como trabajador de IBM Corporation, que abandonó varias veces por disconformidad con el escaso trato humano en esta empresa, muy encorsetada y llena de burocracia.

Según demuestra matemáticamente, llegados a un punto el rendimiento de un sistema no está relacionado con el número de procesadores instalados, sino con la eficiencia de los algoritmos empleados.

20. Ley de Myhrvold

El software es un gas; se expande hasta rellenar su contenedor

Claro, esto explica por qué da igual la potencia y capacidad del ordenador que tengamos: nuestro software lo llenará como si se tratara de un globo, hasta ponerlo a reventar.

Y lo dijo ni más ni menos que Nathan Myhrvold, ex-director de tecnología de Microsoft y fundador de Intellectual Ventures, una empresa dedicada crear y patentar, pero curiosamente no a poner en explotación, inventos para sectores como el software, semiconductores, redes, lásers, biotecnología y otros dispositivos.

Continuar en 30 Leyes épónimas relacionadas con el desarrollo de software (y III).

Publicado en: Variable not found

Hace unos minutos en Twitter se propagaba la noticia de la disponibilidad de la versión final de ASP.NET MVC 2, que puedes descargar ya desde el sitio web de Microsoft.

Según se indica en el documento de notas de la revisión, y como era previsible, no se puede instalar en equipos con Visual Studio 2010 RC. Por lo demás, no se ha introducido ningún cambio destacable desde la anterior revisión, la segunda Release Candidate.

También se ha publicado el código fuente en CodePlex.


Publicado en: Variable not found.

El framework ASP.NET MVC 2 ha introducido un nuevo filtro llamado ChildActionOnly que, como su nombre indica, impide la ejecución del método de acción sobre el que se aplica, a menos que se trate de una “acción hija”.

Supongamos el siguiente código en el controlador, digamos, HomeController:


Atendiendo a la ruta por defecto, una petición del tipo GET /Home/Menu generará una excepción, como la mostrada en la captura de pantalla adjunta.

¿Y qué significa eso en la práctica? Pues básicamente que la acción sólo puede ser invocada desde una vista utilizando los métodos Html.Action() y Html.RenderAction().

Ambos métodos, aunque formaban parte del ensamblado futures desde hace algún tiempo, han sido por fin incluídos en MVC 2, y están destinados a introducir en la vista actual el resultado de la ejecución de una “acción hija”, por ejemplo así:


La diferencia entre ambos es que Html.Action retorna un string con el resultado de la ejecución de dicha acción, mientras que Html.RenderAction() escribirá directamente la respuesta sobre el canal de salida (Response).

Publicado en: Variable not found.
Hey, ¡estoy en twitter!

Esta es una respuesta rápida a una cuestión de Fred C., que me llega vía formulario de contacto en Variable not found, sobre un problemilla que también sufrí en algunas ocasiones, y he pensado que posiblemente pueda interesarle a alguien más, así que ahí va.

El escenario es el siguiente: tenemos en una vista un código para generar un enlace hacia una acción, como el mostrado a continuación:


Al mostrarse la vista, ya en tiempo de ejecución, nos encontramos con que no se ha generado el enlace que pretendíamos, sino uno como el mostrado en la captura de pantalla adjunta, hacia la dirección/Home/Editar?Length=9.

En primer lugar, utilizando la ruta por defecto, vemos nos está llevando hacia el controlador “Home”, ¿pero no le habíamos dicho que era “Productos”?

Y en segundo lugar, ¿dónde está nuestro parámetro id? ¿De dónde sale ese parámetro Length con el valor 9?

La respuesta a este problema es bien sencilla aunque al principio puede provocarnos algún dolor de cabeza: estamos utilizando una sobrecarga incorrecta del método ActionLink().

Si observamos las distintas sobrecargas de este método, podremos comprobar que sólo una de ellas tiene una signatura compatible con la llamada que estamos utilizando:

Así, cuando en el código anterior estábamos pasando al método el nombre del controlador, en realidad lo que hacíamos era indicarle los parámetros de la llamada. Eso explica el parámetro Length=9 en la URL: dado que le enviamos un string de 9 caracteres, simplemente se trata de una serialización de sus propiedades.

Y, por tanto, los parámetros de la llamada que estábamos especificando, lo hacíamos como parte de los atributos HTML. De hecho, si analizamos el código fuente de la página generada, encontramos que el parámetro “id” ha sido introducido como un atributo HTML del enlace:


La forma de solucionarlo es bien fácil, sólo hay que utilizar la sobrecarga apropiada, como:


En fin, que se trata de un pequeño despiste a la hora de codificar, propiciado a veces por la gran cantidad de sobrecargas y la información, algo confusa, ofrecida por Intellisense que nos puede hacer perder unos minutos muy valiosos.

¡Gracias, Fred, por participar en Variable not found!
Por cierto, ¡estoy en Twitter!

Los chicos de BaseKit me han invitado, bueno, y a 20 de vosotros también ;-), a probar su nueva herramienta, actualmente en fase de beta privada (si quieres conseguir un pase, lee el final del post).

BaseKit es una aplicación totalmente on-line que permite a diseñadores crear sitios web completos sin necesidad de tener conocimientos de HTML, javascript y, si apuramos, incluso ni de CSS, rompiendo así la brecha que tradicionalmente divide el mundo del diseño y del desarrollo web.

Otra ventaja para los que no se sienten cómodos lidiando con compañías de hosting es que el servicio cuenta con su propio alojamiento; en un par de clicks, el sitio web que estemos editando pasará a estar disponible en internet. De hecho, el alojamiento será el único concepto por el que BaseKit cobrará a los usuarios en el futuro.

La primera prueba de la facilidad con la que se pueden crear sitios web la encontramos al comenzar a trabajar con BaseKit, cuando tendremos que decidir cómo queremos crear el sitio web: importando un archivo Photoshop, seleccionando una plantilla base predefinida, o basándonos en un sitio disponible en la galería.

La primera opción permite subir directamente archivos en formato PSD cuyos contenidos y estructura serán utilizados para generar automáticamente la plantilla de la página.

Las siguientes opciones permiten tirar de elementos prediseñados, como plantillas o incluso sitios web completos, disponibles en la galería de BaseKit. Estas galerías todavía no ofrecen gran cantidad de elementos prediseñados, pero se entiende que es debido a que el producto está aún en fase de pruebas.

En cualquier caso, independientemente del modo de inicio lo que tendremos a continuación es un completo editor en el que podremos editar la página de forma visual, en plan drag&drop, de forma realmente sencilla.

De momento hay un buen número de widgets con los que crear los contenidos de la página, y obviamente tienen planes de seguir añadiendo nuevas posibilidades.

Bueno, pues como ya hice en otras ocasiones, los 20 primeros usuarios que me hagan llegar su dirección de correo electrónico vía comentario a este post, formulario de contacto, Twitter, Facebook, o en persona ;-), tendrán acceso durante 30 días para publicar todas las páginas que deseen, con hosting gratuito durante todo el 2010.

Para las pruebas debes utilizar Firefox 3.5.5 o superior; de momento BaseKit no soporta IE, aunque están trabajando en ello.

¡Venga, os espero!

Publicado en: Variable not found.

El sistema de validaciones integrado en ASP.NET MVC 2, basado en la especificación de restricciones utilizando los atributos definidos en el espacio de nombres System.ComponentModel.DataAnnotations, permiten la introducción de mensajes de error personalizados, como en el siguiente ejemplo:


Y otra posibilidad es externalizar estos mensajes a archivos de recursos, y crear versiones localizadas de los mismos:


De esta forma, todos los atributos mediante los cuales podemos indicar restricciones del modelo permiten la especificación de un mensaje de error descriptivo.

Sin embargo, hay dos tipos de errores de validación en los que no es tan obvia la forma de indicar el texto del mensaje, debido a que no se generan por restricciones especificadas en atributos, sino basados en el tipo de la propiedad.

Por ejemplo, supongamos el siguiente código, perteneciente a una entidad de datos:


Aunque no hayamos indicado ninguna anotación que limite el contenido de sus dos propiedades, sí que existen de forma implícita dos condicionantes: el primero de ellos, que al tratarse de tipos valor no se admitirán valores nulos (o vacíos, a nivel de controles de formularios); y el segundo, que los valores introducidos deben ser convertibles a los tipos DateTime e int, respectivamente.

La siguiente captura de pantalla muestra un formulario de edición de la entidad en los que se han producido estos errores de validación:

Propiedades implícitamente obligatorias

El mensaje “The XX field es required” es el texto de error por defecto para las propiedades de tipo valor, implícitamente obligatorias, y es el mismo que aparece cuando utilizamos la anotación [Required] sin especificar ningún mensaje de validación.

Para modificarlo basta decorar la propiedad con dicho atributo y especificar en él el contenido del mensaje, o la forma de localizar el texto en los recursos de la aplicación, de la misma forma que haríamos con un tipo referencia, como un string.

Dado que este código es algo anti-DRY, todavía podemos mejorarlo un poco creando nuestro propio atributo personalizado:

¿Problemas con el cambio de tipo?

El otro error, “The value XX is not valid for YY”, es algo más complicado  dado que no existe ningún atributo en el que podamos indicar de forma explícita el mensaje a utilizar, como hemos hecho en el caso anterior.

Para sustituir el mensaje por defecto es necesario utilizar un archivo de recursos en el que tendremos que introducir el texto que queramos utilizar en estos casos. Para ello, añadiremos en primer lugar una carpeta de recursos globales:



Y en su interior un archivo de recursos, llamado por ejemplo Mensajes.resx, en el que introducimos un string con el nombre PropertyValueInvalid, cuyo valor será el mensaje de error que queremos mostrar cuando se produzca un error de conversión:



Observad que el interior del mensaje {0} será sustituido por el valor incorrecto, y {1} por la descripción de la propiedad que está generando el error.

El último paso para que ASP.NET MVC framework reconozca dónde debe buscar este recurso es indicar en la inicialización de la aplicación el nombre del archivo (o clase) que lo contiene:

Tras aplicar estos cambios, si ejecutamos la aplicación podremos comprobar que hemos conseguido nuestros objetivos:

Publicado en: Variable not found
Hey, ¡estoy en Twitter!

TempData es un diccionario disponible a nivel de controladores y vistas del framework ASP.NET MVC que nos permite almacenar objetos de forma similar a la colección ViewData, pero, a diferencia de ésta, es capaz de mantener su contenido entre peticiones.

De hecho, es un recurso habitualmente utilizado cuando necesitamos enviar información desde una acción a otra tras realizar una redirección. Por ejemplo, ante una petición dirigida hacia la acción “Milestone” en un controlador como el siguiente:


… podríamos tener en la plantilla de vista ShowMessage.aspx acceso directo a la entrada del TempData almacenada en la petición que inició la secuencia:


Pues bien, la beta de ASP.NET MVC 2 introdujo en el comportamiento de este diccionario una serie de cambios que merecen ser comentados.

En primer lugar, ha sido modificado el ciclo de vida de las entradas existentes en el TempData. Ahora cada elemento del diccionario es analizado al finalizar la ejecución del controlador (concretamente su método ExecuteCore()); aquellos que estén “marcados” continuarán viviendo en el mecanismo de persistencia elegido (por defecto, en una variable de sesión del usuario) y el resto serán eliminados sin piedad.

Internamente se procede de la siguiente manera: al comenzar el proceso de la petición, se cargan en la propiedad TempData del controlador los valores almacenados en el proveedor de datos temporales,  un objeto que implementa el interfaz ITempDataProvider. La implementación por defecto utiliza la clase SessionStateTempDataProvider para almacenar la información en  la variable de sesión “__ControllerTempData”.

En este momento, todas las entradas presentes en el diccionario son marcadas como candidatas a ser conservadas.

Si desde cualquier punto del código del controlador o la vista se obtiene el valor de una entrada del diccionario, como en el ejemplo de vista ShowMessage anteriormente mostrado, se eliminará la marca de supervivencia y pasarán a estar en la cuerda floja.

Al finalizar la ejecución del controlador, se recorren aquellas entradas del diccionario que no estén marcadas y se eliminan del diccionario. Finalmente, éste es salvado a través del proveedor de datos temporales actual.

Sólo hay una excepción para el caso anterior: las redirecciones. Éstas, en su método ExecuteResult(), incluyen una llamada al método Keep() del diccionario TempData actual, lo que provoca que todas las entradas del mismo sean marcadas para su conservación. Por tanto, una acción que retorne un tipo RedirectToRouteResult, siempre conservará el TempData intacto.

Como consecuencia, una forma de evitar la eliminación de una entrada y forzar su conservación al finalizar la petición actual es utilizando TempData.Keep(key), siendo key la clave de la misma,  o generalizando como en el caso anterior, TempData.Keep(), que salvará todas las entradas almacenadas.

Pero ojo, que esto puede provocar un efecto no deseado. Dado que por defecto las entradas al diccionario no van a eliminarse salvo que sean leídas, puede dar lugar a contenidos perennes en el estado de sesión del usuario. O en otras palabras, si introducimos en TempData una entrada con un objeto pesado y éste nunca es obtenido, permanecerá en la sesión del usuario hasta que ésta desaparezca... supongo que no es necesario comentar lo desastroso que puede ser esto, no? ;-D

Otro aspecto curioso es que cualquier consulta al TempData hará que la entrada sea marcada para su eliminación… incluso si estamos consultándola desde el depurador de Visual Studio. Por tanto, cuidado con esto, que puede provocar algún dolor de cabeza.

Aunque algo denostado, TempData sigue siendo una opción válida para el traspaso de información entre distintas peticiones, aunque siempre usado con moderación y sentido común. 

Publicado en: Variable not found.
Hey, ¡estoy en twitter!

Este post es la tercera y última entrega de la serie 30 Leyes epónimas relacionadas con el desarrollo de software. Puedes encontrar la segunda parte aquí.

21. Las leyes de Bryce

Así las llama él, aunque algunas encajarían mejor en una recopilación de frases célebres. Ahí van algunas, aunque pueden encontrarse más de 150 aquí.

Tal y como el uso de la tecnología va aumentando, disminuyen las habilidades sociales

El 85% del trabajo de desarrollo de todos los sistemas consiste en introducir modificaciones y mejoras

A la vez que la capacidad del hardware incrementa, el software se vuelve más pesado

Olvidar al ser humano durante el diseño del sistema provocará que el ser humano se olvide del sistema en el momento de echarlo a andar

[...]

Tim Bryce es un controvertido escritor y consultor de gestión de recursos de información (IRM), famoso entre otras cosas por sus aseveraciones sobre el ego, las manías y extrañezas de los desarrolladores, y sus consejos para manejarlos apropiadamente. Aparte de su habilidad para hacer amigos entre los programadores, es sin duda un gran experto en el mundo de las compañías de desarrollo de software, con más de 30 años a sus espaldas en este campo.

22. Primer principio de Spaf

Si eres responsable de seguridad pero no tienes autoridad para establecer reglas y castigar sus incumplimientos, tu cargo real en la organización es asumir la culpa cuando ocurra algo grave

Eugene Spafford, más conocido como "Spaff", es un reputado experto en seguridad informática y profesor de la Purdue Univertity. Según parece, fue uno de los primeros en escribir un libro sobre virus informáticos en 1989, utilizar el término autopsia software para referirse al análisis de aplicaciones para intentar localizar a sus autores, y un sinfín de aportaciones al mundo de la seguridad en sistemas informáticos.

Además, es tan prolífico creando frases y analogías a la hora de explicar conceptos de informáticos que Mahesh V. Tripunitara, uno de sus estudiantes, mantiene una página donde las recoge: "The Page of Spaf's Analogies".

23. Ley de Alzheimer de la programación

Si lees un código que escribiste hace más de dos semanas es como si lo vieras por primera vez

Efectivamente, el psiquiatra y neurólogo alemán Aloysius Alzheimer no enunció esta ley a primeros del siglo pasado, pues estaba muy ocupado estudiando las enfermedades mentales de sus pacientes. Sin embargo, el síntoma de pérdida de memoria tan habitual en ellos propició la utilización de su nombre en esta Ley tan ligada a la escritura de código limpio, documentado y sencillo.

24. Ley de Amara

Tendemos a sobreestimar el efecto de la tecnología en el corto plazo y a subestimarla a largo plazo

Esta ley, causa de la existencia de problemas debidos a excesos de optimismo o de la formulación de predicciones disparatadas, fue enunciada por Roy Amara, que fue presidente del Instituto para el Futuro, un grupo de investigación sin ánimo de lucro dedicado al análisis de tendencias que ayuden a la toma de decisiones basándose en predicciones sobre el futuro.

26. Principio de Liskov

Los subtipos deben ser sustituibles por sus clases bases

O en otras palabras, que un subtipo no debe modificar el comportamiento esperado de la clase de la que hereda; de esta forma, si el subtipo puede sustituir a su clase base sin causar daños, la herencia será correcta. Citando a Enrique Place en PHPSenior, "No basta con ser hay que comportarse como tal".

Barbara Liskov es profesora del Massachusetts Institute of Technology (MIT) y fue la primera mujer en conseguir el doctorado en informática de Estados Unidos.

25. Ley de Hick

El tiempo que se tarda en tomar una decisión aumenta a medida que se incrementa el número de alternativas

Puede sonar a obvio, pero la cuestión es que William Edmund Hick, pionero en psicología experimental y ergonomía, fue capaz de idear, a mediados del siglo pasado, la fórmula que explica por qué tardamos tanto tiempo en responder a un cuadro de diálogo con botones para Aceptar, Cancelar, Reintentar, Ignorar y Omitir:

T = blog₂(n + 1)

Cosas de las matemáticas, seguro. :-D

27. Principio de Hanlon

Nunca le atribuya a la maldad lo que puede ser explicado por la estupidez

A pesar de su nombre, no está claro quién definió con tanta claridad su confianza en la capacidad del ser humano. Bill Clarke, Goethe, William James, Napoleón Bonaparte, Richard Feynmann, Einstein, Robert A. Heinlein (cuyo apellido podría haber degenerado en "Hanlon"), o un desconocido Robert J. Hanlon del que no existen demasiadas referencias podrían ser los padres de esta Ley tan utilizada por los hackers para definir situaciones creadas como consecuencia del trabajo de incompetentes sin mala intención.

28. Ley de Joy

El número de empleados inteligentes en una empresa es una función logarítmica del número de empleados totales

También formulada como "no importa quien seas, la mayoría de la gente inteligente trabaja para otro", la Ley dictada por Bill Joy ofrece una visión un tanto pesimista (¿realista?) de nosotros mismos y nuestro entorno de trabajo. Pero ojo, que no lo decía cualquiera, que este señor es co-fundador de Sun y, probablemente, estuviera describiendo lo que veía.

29. Ley de Lister

La gente bajo presión no piensa más rápido

Bonita frase para escribir en un post-it y pegárselo en la frente a alguien a ver si se da por aludido. Y es que efectivamente, la presión y la velocidad de pensamiento no son magnitudes proporcionales, pero es Tim Lister, un consultor, formador y escritor experto en gestión de riesgos en procesos de desarrollo de software, el que lo enunció de esta forma tan tajante y certera.

30. La navaja de Occam

En igualdad de condiciones la solución más sencilla es probablemente la correcta

En el siglo XIV, Guillermo de Ockham, fraile franciscano y filósofo, postulaba de esta forma el principio de economía, utilizada en disciplinas tan dispares como la teología, informática o lingüística. De hecho, podríamos considerarlo la base de principios como KISS (Keep It Simple, Stupid), o YAGNI (You ain't gonna need it), asociados habitualmente a la programación extrema pero válidos en cualquier tipo de desarrollo.

Una curiosidad, el tercer episodio de la primera temporada de la serie House tenía este título, haciendo referencia a la solución del caso médico propuesto.

---

Fuentes:

• Global Nerdy: Laws of software development
• Jugando a crear: Leyes del desarrollo de software
• Wikipedia: List of eponymous laws
• sysprog.net: Computer laws
• Haacked: 19 Eponymous Laws Of Software Development

Publicado en: Variable not found.

Un epónimo es el nombre de una persona o lugar que cede su nombre a una época, pueblo, unidad, ley, etc. Son epónimos por ejemplo "Diesel", cedido por Rudolf Diesel, inventor de este tipo de motores, o "Hamburguesa", infame trozo de carne picada cuyo nombre procede de su lugar de origen.

Hace unos años, el gran Phil Haack posteó sobre leyes epónimas relacionadas con el desarrollo de software en "19 Eponymous Laws Of Software Development", y seleccioné las que me resultaron más interesantes en un par de posts.

Ahora los he vuelto a maquetar y les he añadido un nuevo conjunto de leyes muy interesantes para todos los que nos dedicamos al mundo del desarrollo de software, y muchas de ellas incluso aplicables a otros ámbitos.

1. Ley de Postel

Sé conservador en lo que hagas y liberal en lo que aceptes de los demás

Esta frase, de Jonathan Bruce Postel, también llamada Principio de Robustez, es la piedra filosofal del protocolo TCP, y está recogida en la RFC 793, sección 2.10, de septiembre de 1981.

2. Ley de Parkinson

El trabajo se extiende siempre hasta rellenar la totalidad del tiempo disponible para completarlo

Esta ley fue postulada inicialmente en 1955 por C. Northcote Parkinson en The Economist y más tarde entró a formar parte de su libro, basado principalmente en las experiencias de la administración británica.

3. Principio de Pareto

Para muchos fenómenos, el 80% de las consecuencias derivan del 20% de las causas

Vilfredo Pareto fue un estudioso de la economía y sociología del siglo XIX, y se fijó que el 80% de las propiedades y riqueza estaban repartidas entre el 20% de la población, enunciando su famoso principio. A partir de ahí, se piensa que esta proporción es cierta en múltiples ocasiones, hasta en el número de bugs en el código fuente de un software, o el tiempo de desarrollo de funcionalidades.

4. Revelación de Sturgeon

El noventa por ciento de cualquier cosa es basura

Theodore Sturgeon era un autor de ciencia ficción americano que escribió esta frase defendiendo a este tipo de literatura de críticos que opinaban que el 90% era una porquería.

Hay un corolario que dice "La revelación de Sturgeon es cierta salvo para la basura, donde el 100% es basura".

5. El principio de Peter

En una jerarquía, todo individuo tiende a subir hasta alcanzar su nivel de incompetencia

Seguro que todos conocéis ejemplos de ello: un fabuloso desarrollador es ascendido a directivo en una empresa, la cual gana un gestor pésimo y pierde un programador excelente. Doble penalización. Lawrence J. Peter, pedagogo de profesión, ya lo enunció en 1968 en el libro El principio de Peter.

6. Ley de Hofstadter

La realización de un trabajo siempre dura más de lo esperado, incluso habiéndose tenido en cuenta la Ley de Hofstadter

Esta genial y recursiva Ley creada por el científico, filósofo y académico estadounidense Douglas Hofstadter es absolutamente cierta. Y si no, pensad un poco, ¿cuántas veces habéis estimado plazos en un desarrollo, lo habéis incrementado de forma considerable por los imprevistos y aún así os habéis quedado cortos?

7. Ley de Murphy

Si algo puede ir mal, lo hará

La famosa ley, también enunciada en forma de tostada que recurrentemente cae con la mantequilla hacia abajo, fue dictada por Edward A. Murphy, Jr., mientras trabajaba para la fuerza aérea americana como ingeniero, diseñando un sistema de cohetes experimental. Sería lógico pensar que el experimento acabó en tragedia, pero parece ser que la creación y consideración de esta ley les ayudó a evitar graves desastres en sus pruebas.

8. Ley de Brooks

Incluir trabajadores en un proyecto retrasado hará que éste avance aún más lentamente

Fred Brooks postuló esta ley en su famoso libro The Mythical Man-Month: Essays on Software Engineering como resultado de su experiencia en IBM. Existen variantes y corolarios como "Una señora es capaz de tener un hijo en nueve meses, pero este plazo no puede disminuir por muchas mujeres embarazadas que pongamos a ello". Simplemente genial.

9. Ley de Conway

Cualquier software refleja la estructura organizacional de quien lo produjo

A pesar de que suena a guasa, la ley de Melvin Conway no puede ser más cierta. Una empresa con tres grupos de desarrollo tenderá a generar software distribuido en tres subsistemas, reflejo fiel de las relaciones entre los grupos participantes. Y por cierto, extrapolando un poco... ¿habéis pensado alguna vez que el software que se hace en vuestra empresa es un desastre? ¿creéis que con esta ley podríais obtener alguna conclusión? ;-D

10. Principio de Kerckhoffs

En términos de criptografía, un sistema debería ser seguro incluso si todo sobre el mismo se conoce públicamente, salvo una pequeña porción de información

Es increíble que Auguste Kerckhoffs lingüista y criptógrafo alemán, enunciara en el siglo XIX este principio, base de todos los sistemas de criptografía de clave pública actuales.



Publicado en: http://www.variablenotfound.com/.

Hace unas horas Phil Haack ha anunciado la publicación de la penúltima revisión del framework MVC 2 antes de la versión final.

Según se recoge en el documento de notas de la revisión, la única característica añadida ha sido el cambio en la forma de validar las entidades del Modelo. En versiones anteriores, durante el binding se evaluaban las restricciones establecidas en las propiedades cuyos valores eran recibidos por el servidor, mientras que ahora se valida la entidad completa.

También, aunque de menor calado, han sido introducidos otras mejoras interesantes, como el nuevo método Peek() del diccionario TempData, el incremento del rendimiento en varios puntos, o una nueva forma de indicar parámetros opcionales en las rutas, que son eliminados para no interferir otros datos recibidos en la petición.

Desafortunadamente, aún no podemos probarla con las versiones preliminares de VS2010, y sólo funcionará con la versión 2008 del IDE. :-(

Enlaces:

• Descargar ASP.NET MVC 2 RC 2
• Documento de notas de la revisión
• Código fuente y ensamblado futures

Publicado en: Variable not found.

Mi gran descubrimiento del día probablemente será una chorrada para la inmensa mayoría, pero también seguro que hay alguien que, como un servidor, no se había percatado hasta el momento de este detalle de IE8.

Como sabéis, la barra de direcciones de este navegador nos permite escribir la URL de la página que queremos visitar, pero podemos ahorrar mucho tiempo si tecleamos únicamente algunos caracteres contenidos en la misma: Internet Explorer buscará en el historial de sitios visitados y en los favoritos, mostrando aquellos sitios que contengan la cadena buscada.

Por ejemplo, escribiendo “vari”, mi Explorer 8 muestra las siguientes sugerencias:


Sin embargo, si alguna vez introducís una dirección incorrecta, por ejemplo tecleando un carácter de más, u omitiendo alguno, esta URL será añadida al historial, y se mostrará como sugerencia también, efecto bastante incómodo.

En la captura anterior, se puede ver que Internet Explorer ofrece “varialablenotfound.com”, una dirección que tecleé de forma incorrecta tiempo atrás.

Pues mi gran descubrimiento es este: si paseamos el ratón sobre esta sugerencia, o la seleccionamos usando la tecla flecha abajo, aparece a la derecha un icono que nos permite eliminarla, para que no nos moleste más:


La explicación de que no lo haya visto hasta ahora es muy sencilla: al aparecer a la derecha del desplegable queda fuera del foco de atención en ese momento, que está justo en el lado contrario, y especialmente en pantallas con resolución muy ancha.

Por curiosidad he probado a ver si existía algo parecido en Chrome, Firefox y Opera, y ninguno incluye este detalle, que nos viene de perlas a los que somos algo muñones ;-)

Publicado en: Variable not found.

Con objeto de mejorar la seguridad de nuestras aplicaciones, la Release Candidate de ASP.NET MVC 2 introdujo un cambio importante en la forma de procesar peticiones que retornan información serializada como JSON: por defecto, ahora sólo se responde a peticiones de tipo POST.

Dado que en MVC 1.0 era justo al contrario, esta pequeña reorientación hace que aplicaciones que antes funcionaban correctamente dejen de hacerlo al migrarlas a la última versión del framework. Un ejemplo lo tenemos con las aplicaciones que aprovechan la potencia de jqGrid para mostrar y editar rejillas de datos. Recordemos que el intercambio de información entre cliente y servidor se realiza mediante llamadas Ajax que retornan siempre datos en notación JSON.

Los síntomas que notaremos en estos casos son muy simples: ¡las acciones que deberían devolvernos información dejan de hacerlo! En algunas ocasiones, dependiendo del uso que se dé en la vista a la la información retornada, es posible que aparezcan errores de script en el navegador, pero otras ni siquiera eso.

En cualquier caso, no es difícil dar con la solución. Con Firebug, Fiddler, o cualquier herramienta que nos permita monitorizar las peticiones, podremos observar que en la petición Ajax se está produciendo un error HTTP 500 (error interno de servidor):



Y si seguimos profundizando en dicha petición, podemos ahora conocer el mensaje descriptivo que envía el servidor, un auténtico detalle por parte del equipo de desarrollo de ASP.NET MVC 2, en el que incluso nos indican la solución al problema:


Ante esta situación, podemos optar por dos soluciones. La primera sería indicar explícitamente en la instancia del resultado, de tipo JsonResult, que queremos permitir el método GET, así:


Y otra posibilidad sería realizar las peticiones Ajax utilizando el método POST, algo que podemos conseguir muy fácilmente la mayoría de las veces. En el caso de los ejemplos con jqGrid, sería sustituyendo el ’GET’ por ‘POST’ en código:


¡Gracias, Maxi, por los comentarios que inspiraron este post!

Publicado en: Variable not found.

“Error al conectarse al administrador de deshacer del archivo de código fuente c:\blahblah\archivo.designer.cs” es un mensaje con el que Visual Studio (tanto la versión 2005 como 2008) me ha abofeteado en numerosas ocasiones cuando estoy desarrollando sitios web ASP.NET.

Y la verdad, es uno de esos casos en los que no sabes qué hacer: recompilas, limpias la solución, abres y cierras el IDE… pero nada, cuando le da por ahí, no hay forma de hacerlo entrar en razón:


Buscando un poco de información, parece ser que se trata de un problema que aparece al editar el archivo .aspx mientras se está depurando la página, siguiendo una secuencia determinada.

Una de las formas de solucionarlo es un poco bestia, pero funciona (al menos en VS 2008): basta con eliminar el archivo xx.designer.cs indicado por el error (previo backup, por si acaso, aunque hasta ahora no me ha hecho falta nunca ;-)) y forzar al entorno a que lo genere de nuevo, pulsando el botón derecho del ratón sobre el archivo .aspx y seleccionando la opción “Convertir en aplicación web” que habrá aparecido en el mismo.

De momento no le he visto contraindicaciones, y estoy de lo más contento :-)

Publicado en: Variable not found.

La nueva versión de ASP.NET viene cargadita de novedades orientadas a la optimización en motores de búsqueda. Si sabemos aprovecharlas, nuestros sitios webs serán mejor indexados en los buscadores, seremos más fácilmente localizables desde estas herramientas y, consecuentemente, podremos aspirar a tener mayor número de visitantes.

En este post resumiré las mejoras introducidas en  ASP.NET 4 que pueden ayudarnos en nuestra relación con los motores de búsqueda. No son novedades revolucionarias, puesto que todo lo que nos ofrecen podíamos conseguirlo con las versiones anteriores de ASP.NET de alguna u otra manera, aunque sin duda que nos facilitarán algo las cosas. :-)

Page.MetaDescription y Page.MetaKeywords

ASP.NET 4 incorpora a la clase Page las propiedades MetaDescription y MetaKeywords para facilitarnos el acceso a la metainformación de la página.

Con la primera de ellas, MetaDescription , podemos especificar en cada página una descripción individualizada, que será utilizada por los buscadores como un resumen de su contenido. Por ejemplo, Google, la incluye como parte de los resultados de las búsquedas.

La segunda, MetaKeywords, permite añadir tags o palabras clave que puedan ser útiles para clasificar su contenido. Aunque la mayoría de los buscadores no utilizan esta información a efectos de indexado, al parecer algunos sí lo hacen, por lo que sigue siendo costumbre incorporar esta información.

En ambos casos podemos establecer su contenido de forma declarativa, en las directivas de la página, así:


Pero también, y esta posibilidad es bastante más interesante, podemos establecerlas mediante código, por ejemplo en el Page_Load(), lo que puede ser útil si por ejemplo tenemos que obtener valores desde una base de datos o similar:


En cualquiera de los casos, el resultado es el mismo. ASP.NET, a la hora de generar la página, añadirá en la sección <head> de la página una etiqueta <meta> con la descripción y etiquetas proporcionadas:


Ni que decir tiene que la etiqueta <head> de la página (o la master que utilice) debe tener el correspondiente runat="server" para que pueda ser modificada en tiempo de servidor.

Response.RedirectPermanent()

Los más viejos del lugar recordarán que Response.Redirect() está con nosotros desde los tiempos del ASP tradicional, y desde entonces ha mantenido su función: enviar al agente de usuario un resultado HTTP 302, apuntándole una nueva dirección URL en la que localizar el recurso solicitado. Vamos, lo que toda la vida hemos llamado redirección. :-)

Sin embargo, el código de estado 302 definido por el protocolo indica, literalmente, que el recurso solicitado ha sido localizado pero que se encuentra en otra dirección (retornada como información adicional a la respuesta) aunque sólo temporalmente. Por ello se dice que estas redirecciones son transitorias; el navegador (o los robots de búsqueda, en el caso que nos ocupa) no pueden asegurar que la URL indicada sea la ubicación correcta y permanente del recurso.

El código HTTP 301, sin embargo, indica que el recurso solicitado ha sido movido de forma permanente a la dirección que se retorna al agente de usuario. Esto podría ser útil, por ejemplo, si modificamos los dominios sobre los que corre un sitio web, o cambiamos el esquema de URLs que estamos utilizando y, entre otras cosas, quisiéramos aprovechar la información la información que ya tienen los buscadores sobre nuestro sitio.

Pues con este propósito ha sido incluido el método Response.RedirectPermanent()cuya forma de utilización es idéntica a las redirecciones habituales:

¡Direcciones amigables!

¡Ya era hora de que ASP.NET ofreciera un mecanismo integrado para generar URLs amigables! El motor de routing introducido con ASP.NET 3.5  SP1 tan magníficamente aprovechado en el framework MVC, toma ahora su protagonismo también en el mundo de Webforms. Y la forma de usarlo, igual de sencilla. :-)

Para que nuestra aplicación soporte friendly urls, tenemos que registrar durante la inicialización del sistema las rutas, o mejor dicho, el patrón del URLs, que vamos a entender. Por ejemplo, imaginemos que nuestra aplicación, un catálogo on-line, debe atender peticiones a direcciones como las siguientes para mostrar la página de detalle de un producto:

• http://www.miservidor.com/product/ACER-ASPIRE-ONE-D250-0BK

Esto podríamos conseguirlo durante la inicialización del sistema, registrando un patrón de ruta de la siguiente forma, en el global.asax:


Lo que indica la ruta es que las direcciones de tipo product/{productCode} serán enviadas a la página física ~/product.aspx. La porción variable de la URL, el parámetro {productCode} podremos obtenerlo desde el código de la página para cargar los datos desde el almacén correspondiente, por ejemplo así (en product.aspx.cs):


Como puede intuirse, a través de la colección RouteData.Values podremos acceder a los parámetros suministrados en el interior de la ruta, es decir, los que forman parte de la URL de la página que introduce el usuario.

Al igual que ocurre en ASP.NET MVC, el sistema de rutas es bidireccional, por lo que podremos también generar links ‘amistosos’ hacia recursos del sitio web, como en el siguiente ejemplo:


El método GetRouteUrl() genera la URL del producto utilizando el propio motor de routing, para lo que le pasamos el identificador de la ruta y, en un objeto anónimo, el valor para el parámetro requerido (productCode). El resultado para el caso anterior será la dirección: /product/ACER-ASPIRE-ONE-D250-0BK.

Mejoras en el marcado

Aunque no vamos a detallarlas, o al menos en este post ;-), aparecen también en ASP.NET 4 un buen conjunto de novedades dirigidas a mejorar la calidad del marcado que enviamos a cliente. Y dado que siempre se ha dicho que un marcado respetuoso con los estándares es bueno para el SEO, estas nuevas capacidades del framework nos ayudarán también a mejorar nuestro posicionamiento.

Publicado en: Variable not found.

El HTTP Referer es una variable que nos envían los navegadores en cada petición, permitiéndonos conocer de dónde viene el usuario, es decir, la página donde se encontraba el enlace, botón o formulario cuya activación ha provocado el salto a nuestro sitio.

Por ejemplo, si un servidor recibe esta solicitud:


analizando el campo Referer se puede determinar de forma muy sencilla que se trata de un usuario que proviene de Google, y que estaba buscando el término “variable”. Esta característica aporta una información, que aunque no es demasiado fiable (se puede alterar y desactivar muy fácilmente),  se utiliza con mucha frecuencia con fines estadísticos, o para adecuar el contenido de la página a las intenciones del usuario.

Sin embargo, como se trata de una característica manejada directamente por el navegador, podemos encontrarnos con que no todos actúan de la misma manera... o en otras palabras, es Internet Explorer es el que actúa de forma diferente al resto ;-)

Si la visita a nuestra página se produce como consecuencia de la ejecución de un script que ha modificado dinámicamente el location.href, o ha invocado a location.replace, Internet Explorer saltará a la nueva dirección, pero no enviará el Referer en los encabezados de la petición, por lo que en el punto de destino no se podrá conocer el origen de la misma.

Por tanto, un código como el siguiente hará que la página editar.asp no pueda conocer desde dónde se le ha referenciado:


Dado que Microsoft todavía está considerando modificar este comportamiento, hay que darle un poco las vueltas para conseguirlo provocando el salto hacia la página de destino sin utilizar los mecanismos citados anteriormente.

Una forma muy ingeniosa que he encontrado se basa en crear dinámicamente un tag <a> con su correspondiente href establecido, y simular la pulsación del mismo invocando al evento click:


Visto en: Velocity Reviews
Publicado en: Variable not found

Un truco rápido para poder utilizar el magnífico Fiddler mientras estamos desarrollamos con Visual Studio y utilizando el servidor web integrado. Como habréis comprobado, al ejecutar una solución se inicia el servidor de desarrollo y se abre la ventana apuntando a “localhost:puerto/página”, y dichas peticiones por defecto no son capturadas por esta herramienta.

Aunque existen distintas formas para conseguirlo (algunas de ellas descritas en la propia web del producto), hay una que es realmente sencilla, no hay que configurar nada, y es bastante rápida de activar:

Publicado en: Variable not found.

Montar un disco duro virtual .vhd como si fuera un disco físico de nuestra máquina puede resultar muy interesante para acceder a archivos contenidos en el mismo sin necesidad de tener que adjuntarlo a una máquina virtual.

Ya comenté hace unas semanas que en Windows 7 y 2008 esta operación puede hacerse directamente desde la consola de administración de discos del propio sistema operativo, pues es un formato aceptado de forma nativa por éstos. Sin embargo, en equipos corriendo Windows XP ó Vista, el procedimiento se complica un pelín más, puesto que hay que instalar un software que permita al sistema operativo reconocer el archivo .vhd como un disco duro adicional. Veamos cómo conseguirlo.

Aunque existen otras alternativas, utilizaremos una solución muy sencilla que se distribuye como parte del producto gratuito Virtual Server 2005 R2, que tendremos que descargar desde la web de Microsoft. Obviamente, no instalaremos el producto completo, sólo lo estrictamente necesario para lograr el fin propuesto.

Una vez en nuestro equipo, iniciamos la instalación como habitualmente. Tras aceptar la licencia de uso, sin leerla, faltaría más ;-P, es importante elegir la instalación personalizada e indicar en cada uno de los componentes que no deseamos instalarlo. Bueno, en todos excepto en el llamado “Montaje de VHD”, que es precisamente lo único que nos interesa del producto en este momento.

Una vez completada la instalación, por ejemplo sobre “c:\archivos de programa\microsoft virtual server”, en su interior podremos encontrar una carpeta llamada “Vhdmount” en la que encontraremos la herramienta que andábamos buscando.

La forma de utilizarla, así de sencillo:

vhdmount.exe /p /f "d:\Virtual\JMA.VHD"

A partir de ese momento, el disco duro estará disponible en Mi PC, como si se tratara de un disco físico más. Y cuando queramos desconectarlo,

vhdmount.exe /d "d:\Virtual\JMA.VHD"

Pero si lo que quieres es simplificar aún más esta tarea, David Cervigón aportó hace ya bastante tiempo una solución que añade las órdenes de montado y desmontado al menú contextual del explorador de Windows:

Publicado en: Variable not found

Ya iba siendo hora de estrenarme este 2010 y, como ordena la tradición, el primer post del nuevo año lo reservo para comentar las entradas que han sido más populares a lo largo del año que acabamos de cerrar.

Esta vez voy a introducir una novedad en el análisis, separando los posts que han sido escritos durante este año de otros, creados años anteriores y que todavía gozan de gran popularidad en la red.

Cosecha de 2009

Encabezando el top ten aparece “101 formas de saber que tu proyecto está condenado al fracaso”, una traducción autorizada del original 101 Ways To Know Your Software Project Is Doomed de Max Pool, que enumeraba, en clave de humor, una serie de pistas para saber si un proyecto se estaba precipitando hacia un estrepitoso fracaso.

Seguido de cerca tenemos “ASP.NET MVC: trece preguntas básicas”, un pequeño resumen de cuestiones realizadas muy frecuentemente tras el primer encuentro con el framework, como qué es MVC, qué ventajas tiene sobre Webforms, o si vale la pena pasarse a esta nueva forma de desarrollar aplicaciones web.

En tercer lugar, “Y todavía otras 101 citas célebres del mundo de la informática”, la tercera entrega de un clásico de este blog, con otras ciento una frases recogidas sobre este mundillo. En total, 303 frases, no está mal.

A continuación, el post “jqGrid: Grids espectaculares para ASP.NET MVC, paso a paso” ha demostrado el interés que despierta el uso de este plugin para mostrar y editar datos tabulados en el framework ASP.NET MVC.

En quinta posición tenemos la serie de tres posts “C#: Desmitificando las expresiones lambda” con la que pretendí quitar un poco de misterio a las expresiones lambda, esa fascinante y temida característica de la última hornada de nuestro lenguaje favorito.

En el post “Aspectos a tener en cuenta al crear sitios web públicos” recopilé las opiniones de un hilo de StackOverflow en el que se debatía sobre aquellos aspectos que teníamos que considerar, desde el punto de vista técnico, para crear webs destinadas al público en general, clasificadas por categorías como experiencia de usuario, seguridad, rendimiento, SEO, etc.

En séptima posición, “Plantillas de proyectos ASP.NET MVC 1.0 para NUnit”, donde se describían los pasos para instalar NUnit como framework de pruebas unitarias en proyecto ASP.NET MVC.

La octava posición es para “Indicios de que tu interfaz de usuario fue creado por un programador”, que comentaba y ampliaba el post de Ian Voyce “The 7 signs your UI was created by a programmer” sobre los rastros que dejamos los desarrolladores cuando queremos hacer de diseñador.

En penúltima posición, “Generación de PDF desde .NET usando formularios”, donde describía un truco muy rápido para generar documentos PDF al vuelo, utilizando formularios en el documento y la librería iTextSharp para rellenar su contenido.

En décima posición, “Programadores con producción neta negativa (NNPP)”, post donde comentaba el curioso fenómeno de la existencia de desarrolladores cuyo saldo en las aportaciones a un proyecto resultara negativo, o sea, que el valor de su producción fuera superado por el coste de los errores y defectos que introducían en las aplicaciones.

Cosechas anteriores

En este apartado encontramos los posts que podríamos considerar clásicos en este blog, pero dado que muchos de los lectores acaban de llegar, no está de más comentar su existencia.
Las dos primeras posiciones, un año más como líderes indiscutibles, citados, copiados y pegados hasta la saciedad, “Otras 101 citas célebres del mundo de la informática” y “101 citas célebres del mundo de la informática”.

En tercera posición, “Bordes redondeados en webs (sin esfuerzo) con Nifty Corners Cube”, un post de 2007 donde comentaba el uso de esta librería de scrips para redondear las esquinas de elementos de bloque en páginas web.

Le sigue otra creación de 2007, “Evitar el postback al pulsar un botón en ASP.Net”, donde comentaba distintas formas de hacer que no se lanzara un postback al pulsar un botón incluido en una página ASP.NET, utilizando, por ejemplo, para evitar envíos múltiples de un formulario.

Otro de los grandes clásicos, en “13 Consejos para comentar tu código” comentaba una serie de prácticas destinadas a facilitar la legibilidad en el código fuente.

La sexta posición la ocupan las “32 técnicas de producción de ideas”, un resumen de un post de Neuronilla sobre técnicas destinadas a favorecer la creatividad.

El post “Llamar a servicios web con ASP.NET AJAX paso a paso”, donde se describe detalladamente cómo utilizar ASP.NET AJAX para obtener datos desde un servicio web.

En octava posición, curiosamente, un post sobre el “Escaneo de puertos con idle scan”, una ingeniosa técnica para detectar puertos abiertos en máquinas remotas utilizando un equipo zombie que oculta la identidad del atacante.

“20 desastres famosos relacionados con el software” traducción autorizada por Timm Martin de su serie “20 Famous Software Disasters”, que recogía un buen número de casos en los que fallos relacionados con el software habían tenido consecuencias trágicas.

Por último, “Enviar mensajes con imágenes incrustadas desde .NET”, de la cosecha de 2008, donde se mostraba cómo incrustar archivos de imagen en un mensaje de correo electrónico generado desde una aplicación .NET.

¡¡Feliz 2010!!

Publicado en: Variable not found.