Prueba tu diseño web en distintos navegadores

Hay muchos navegadores y muchas versiones de los mismos y en muchas ocasiones nuestras aplicaciones Web tienen que verse correctamente en muchos de ellos.

http://browsershots.org/ nos puede ayudar a comprobar cómo se ven nuestras aplicaciones en diferentes navegadores.

“Browsershots hace capturas de pantallas de su diseño web en distintos navegadores. Es un servicio de código abierto creado por Johann C. Rocholl. Cuando usted envía su dirección web, es añadida a la cola de trabajos. Un número de computadoras distribuidas abrirá su sitio web en su navegador. Luego se harán capturas de pantallas y se cargarán aquí en el servidor central.”

browsershots.org

Servicio de hosting de TFS

Cuando lo he leído me ha parecido curioso y he decido postearlo…TeamDevCentral ha lanzado un nuevo servicio de hosting de Team Foundation Server.

Yo no lo sabía, pero el primero que salió es TFS Now, que está en Australia. Este que lanza ahora TeamDevCentral es el primero que existe en Norte América.

Por lo tanto, para los que no quieren encargarse de la parte administrativa, hardware y demás que supone tener su propio servidor TFS, ya existe una alternativa…

¿ Tardará mucho en haber uno en Europa ? Todo llegaré, seguro.

Visual Studio 2008 pasa por Bilbao

El día 27 de Marzo pasa por Bilbao la gira de lanzamiento de Visual Studio 2008. Para los que estéis interesados en acudir podéis registros desde aquí. El evento será en Zamudio.

Tendré el placer de participar en el evento en la sesión de ALM 2008, comentando las principales novedades que presenta Team System 2008 para la gestión del ciclo de vida de las aplicaciones.

Agenda:

9:00 – 9:30 – Registro y entrega de documentación.
9:30 – 9:45 – Introducción a Visual Studio 2008
9:45 – 10:45 – Evolución plataforma acceso a datos (LINQ, entity framework…)
10:45 – 11:45 – Evolución plataforma de servicios (WF, WCF…)
11:45 – 12:00 – Café
12:00 – 13:00 – User Experience (WPF, SIlverlight, ASP.NET)
13:00 – 14:00 – Acelera el Ciclo de Vida de tus Aplicaciones, ALM 2008.

Espero veros allí !

Encuesta sobre TFS. Resultados.

Carl Rogers ha publicado en su blog los resultados de una encuesta realizada durante el TechEd EMEA Developers 2007 para conocer el nivel de adopción que de TFS y conocer el punto de vista de los equipo sobre el proceso de desarrollo.


A modo de resumen…



  • Disponer de requisitos pobres es el principal problema en los proyectos de software.

  • Los retrasos en las entregas es una segundo factor clave en los proyectos.

  • La mayoría de los participantes creen que sus proyectos sufren de falta de pruebas y de una metodología formal.

  • Los equipos pequeños sufren más la falta de una metodologías, más que los grandes.

  • El 68% de los encuestados usan TFS y habitualmente se usa en equipos de menos de 10 integrantes.

  • La característica que más se usa de TFS es el gestor de fuentes, con un 89%, seguido de Team Build, con un 56%.

Los resultados completos los podéis ver aquí.

La depuración remota existe!

La depuración de las aplicaciones es un aspecto normal de nuestro día a día pero me sorprende muchas veces lo poco que usamos la depuración remota. No es algo nuevo, es algo que existe hace mucho pero que me da la sensación de que no se usa tanto como debería.


Cierto es que es más cómodo depurar la aplicación en local si tenemos todo en nuestra máquina pero tan cierto como que en muchas ocasiones no es posible reproducir o montar el mismo escenario dónde se da el error en nuestra máquina….o es posible montarlo, pero el coste no merece la pena.


Por este motivo, es importante conocer bien los pasos a realizar para poder depurar la aplicación de forma remota y usar este sistema cuando lo necesitemos.


Para poder depurar de forma remota tenemos que tener funcionando el monitor de depuración remota, msvsmon.exe


Lo podemos instalar en la máquina o simplemente lanzarlo accediendo a la máquina dónde está el visual studio a través de un recurso compartido.


En el equipo que está el Visual Studio la aplicación está en:



Microsoft Visual Studio 8Common7IDERemote Debuggerx86


Si lo queremos instalar en la máquina, en los CDs de Visual Studio hay una carpeta llamada “Remote debugger” que tiene el instalador.


Una vez instalado tienes que asegurarte de dos cosas….que tienes permisos de depuración remota sobre la máquina ( Permisos de depuración remota ) y que la comunicación entre ambas máquinas permite la depuración. ( Cómo configurar manualmente el Firewall de Windows XP para la depuración remota o Cómo configurar manualmente el Firewall de Windows Vista para la depuración remota )


Una vez que has arrancado el monitor de depuración y te has asegurado que tiene los permisos necesarios y que la comunicación está permitida, tendrás que conectarte desde el Visual Studio al proceso que deseas depurar. Cómo conectarse a procesos en ejecución

Encriptando los ficheros de configuración…

Un aspecto a tener en cuenta en el despliegue de las aplicaciones cuando las ponemos en producción es la encriptación de las secciones que puedan contener datos sensibles.


Con .NET 2.0 se pueden encriptar secciones del fichero Web.Config con la utilidad de línea de comandos “aspnet_regiis.exe“. Por defecto, el framework 2.0 viene con dos proveedores para realizar la encriptación: RSAProtectedConfigurationProvider y DPAPIProtectedConfigurationProvider.


La encriptación del fichero de configuración es transparente para la aplicación, por lo que no habrá que cambiar nada en ésta después de encriptar las secciones que nos interesen.


Por ejemplo, para encriptar las cadenas de conexión del fichero WebConfig la línea de comandos sería algo así.



aspnet_regiis -pe “connectionStrings” -app “/IISVirtualDir”


La utilidad aspnet_regiis la podéis encontrar en :



%WINDIR%Microsoft.NETFrameworkv2.0.50727


Uno de los problemas que le veo a la utilidad, es que no viene preparada para encriptar secciones de los ficheros App.Config. La utilidad aspnet_regiis buscar siempre el fichero Web.Config por lo que a priori no encripta los ficheros App.Config.


Realmente si renombrais el fichero App.Config por Web.Config podréis encriptarlo sin problemas, pero me parece un poco cutre.


En mi caso, ante la necesidad de encriptar tanto ficheros Web.Config como App.Config, he optado por hacerme una utilidad para realizar esta operación y no usar la que nos proporciona el framework…aspnet_regiis.


El código necesario para realizar esta operación es muy sencillo..



string provider = “RsaProtectedConfigurationProvider“;


Configuration config = ConfigurationManager.OpenExeConfiguration(configPath);


ConfigurationSection section = config.GetSection(“connectionStrings“);



if (section != null & !section.SectionInformation.IsProtected)
{
      section.SectionInformation.ProtectSection(provider);
      section.SectionInformation.ForceSave = true;
      config.Save(ConfigurationSaveMode.Modified);
}


Si se quiere descomprimir lo único que habría que hacer es llamar a UnprotectSection en lugar de a ProtectSection.


Y si queremos que esta utilidad valga también para ficheros Web.Config, el código sería exactamente el mismo pero usando WebConfigurationManager.OpenWebConfiguration para abrir el fichero de configuración.


Espero que os sea de utilidad..


La información completa sobre cómo encriptar y desencriptar la podéis encontrar en los siguientes enlaces:



Cómo: Cifrar secciones de configuración en ASP.NET 2.0 mediante RSA



Cómo: Cifrar secciones de configuración en ASP.NET 2.0 mediante DAPI