Presentaciones de código efectivas con Visual Studio

Nota: algunos de estos consejos pueden serte útiles a la hora de programar aunque no hagas presentaciones.

Cuando nos dedicamos al noble arte de la programación, seguramente tengamos que realizar algún tipo de presentación técnica en alguna ocasión, ya sea en algún evento, o a los compañeros del trabajo o escuela, o directamente a los amigos. En estas presentaciones seguramente tengamos que mostrar el código de algún proyecto en el que estemos trabajando o de alguna demo que hayamos creado para la ocasión. O quizás si somos muy valientes y/o tenemos el tiempo necesario durante la sesión, programemos el código de la demo en vivo. Por lo general, los Technical Evangelist podemos llegar a dar decenas de sesiones en un mismo año, y asistimos a otras muchas de otra gente. En este artículo he querido recopilar una serie de consejos que pueden ayudarnos a hacer que nuestras presentaciones de código luzcan todavía más. Y no, no voy a hablar de creación de PPTs con PowerPoint, que eso da para otro artículo a parte.

El tema de Visual Studio

Una de las cosas más sencillas que podemos hacer para mejorar la legibilidad de nuestro código es elegir el tema de Visual Studio adecuado. Desde la búsqueda de Visual Studio es fácil encontrar la sección de configuración apropiada:

Mucha gente desarrolla con el tema oscuro (Dark), pero por lo general es el que peor se ve en los proyectores. El tema Azul (Blue) suele verse mucho mejor. En cualquier caso, antes de empezar, verifica con la audiencia cuál se ve bien.

Extender vs. Duplicar la pantalla

Normalmente cuando estamos mostrando nuestro código en un proyector, estamos duplicando nuestra pantalla y no extendiéndola para ver nosotros lo mismo que nuestra audiencia. Ahora, cuando entre fragmento de código y fragmento de código estamos usando una presentación con PowerPoint para reforzar conceptos o explicar algo nuevo, tenemos que tener en cuenta que PowerPoint tiene activado por defecto el modo de vista de presentador (Presenter View). El modo Presenter View extiende nuestro monitor cuando pulsamos F5 para comenzar la presentación o Shift + F5 para continuarla; así podemos ver nosotros una imagen con la PPT actual, la siguiente y nuestras notas, mientras que la audiencia ve otra con la PPT actual. Pues bien, cuando paramos la presentación de PowerPoint para volver a enseñar código, en muchos casos nuestra pantalla se queda en modo extendido y no vuelve al modo duplicado. El ponente normalmente no se da cuenta y empieza a mostrar cosas que sólo el ve en su pantalla. La audiencia se queja y tiene que volver a duplicar la pantalla. Moraleja: si alternas entre PowerPoint y Visual Studio, quita el modo Presenter View de PowerPoint:

Además, las transiciones entre PowerPoint y Visual Studio serán más rápidas al no tener que cambiar de modo de pantalla.

Resolución de pantalla

Es importante que sepas la resolución que te puede dar el proyector o televisión donde vayas a proyectar la pantalla de tu ordenador. Hay muchos proyectores que te obligan a trabajar con resoluciones miserables de 1024x768, en las que apenas caben todas las ventanas que podemos mostrar en Visual Studio, y nos obliga a esconder la mayoría. Pero por lo menos la gente es capaz de leer lo que aparece en pantalla. En otros casos podremos usar resoluciones mucho más elevadas como son los 1920x1080, pero que harán que todo se vea muy pequeño excepto que proyectes en una pantalla gigante.

Si no se ven las cosas demasiado grandes, siempre puedes utilizar herramientas tipo lupa que amplían regiones de tu pantalla. Tenemos el básico Magnifier de Windows (Tecla Windows + ‘+’ para activar) con la que siempre puedes contar, o la estupenda herramienta ZoomIt de SysInternals que nos permite además pintar y escribir sobre la zona ampliada. Por ejemplo:

Ahora, yo en mi caso prefiero usar directamente resoluciones intermedias que me evitan usar tanto la lupa, ya que la lupa puede confundir a la gente si te mueves demasiado por la pantalla. Resoluciones de alrededor de 1300x700 suelen funcionar bien.

Otra manera de agrandar cosas sin necesidad de usar la lupa es aumentar el tamaño del código con el zoom de la ventana del editor de Visual Studio:

Ahora, esto sólo hace que se amplíe el código para un fichero determinado, y al abrir otro fichero tienes que volver a ampliarlo. Y en cualquier caso no afecta al árbol de ficheros de la solución, una de las partes por la que más nos movemos al enseñar código, ni a otros textos de Visual Studio. Aquí nos pueden ayudar las Productivity Power Tools 2013, una extensión para Visual Studio que entre otras muchas cosas tiene un modo de presentación. Este modo nos permite definir el tamaño del código y del resto de los textos de Visual Studio cuando queramos presentar. Desde la búsqueda de Visual Studio podemos ver los comandos disponibles para habilitarlo, configurarlo y desactivarlo, y lanzarlos desde ahí:

Esta imagen es del mismo Visual Studio que el de la imagen anterior, pero con el modo de presentación activado. Se puede apreciar la diferencia a simple vista:

Escribiendo código en directo

Si vas a escribir código durante la sesión, mi principal consejo es que tengas varias versiones de tu proyecto en diferentes estados de la demo. Siempre ten una versión de antes y otra de después de los cambios que vayas a realizar. Así si cometes algún error (cosa más probable de lo que parece con las prisas y los nervios del directo) puedes pegar un pequeño salto rápidamente a la versión con los cambios incluidos, mostrar algo útil y poder seguir fácilmente a partir de ahí. Y no arrastras el error durante toda la sesión.

Y si algo no funciona no te enroques, no intentes arreglarlo en directo, ya que romperás el ritmo de tu sesión y perderás el interés de tu audiencia.

Ahora, una manera de cometer menos errores escribiendo código es no escribirlo. Podemos por ejemplo utilizar Code Snippets en su lugar. Los Code Snippets son pequeños fragmentos de código que podemos insertar en cualquier lugar de nuestro código. Aquí tienes un exhaustivo tutorial sobre su creación: Walkthrough: Creating a Code Snippet. De hecho, Visual Studio trae ya muchos Code Snippets de serie, como por ejemplo estos para C#: Visual C# Code Snippets. Por ejemplo, si escribimos en una de nuestras clases la palabra ‘prop’:

…y pulsamos Tabulador dos veces se nos crea una propiedad genérica a la que le podemos cambiar fácilmente el tipo y el nombre cambiando de uno a otro con el Tabulador:

Además los Code Snippets que creemos podremos distribuirlos fácilmente a quien los necesite (p.ej. para repetir tu demo en algún otro evento): How to: Distribute Code Snippets.

Puedes administrar tus Code Snippets desde el Code Snippets Manager:

Y si los Code Snippets te parecen demasiado, siempre puedes coger cualquier fragmento de código de un proyecto cualquiera y arrastrarlo a la ventana de Toolbox:

Luego desde Toolbox podrás arrastrarlo a cualquier otro fichero de código, en cualquier otro proyecto. Podrás renombrar y organizar estos fragmentos de código a tu gusto. Aquí tienes más detalles sobre esta funcionalidad: Visual Studio 2013: Drag and Drop Code Onto the Toolbox.

Conexión a Internet

Te sorprendería la cantidad de sitios a los que vamos a dar sesiones y que o bien no tienen conexión a Internet o bien la tienen pero hay problemas: el ponente y la audiencia la comparten y va muy, muy lenta, o sólo tienen Internet por cable y tu portátil sólo tiene WiFi, lo que sea. Puedes en algunos casos tirar de 3G, ya sea compartiendo la de tu móvil o utilizando un pincho 3G o un router MiFi, pero en muchos casos no hay cobertura suficiente o la red está saturada si el evento en el que participas es muy grande. Así que por lo general tenemos que planificar nuestras sesiones por si no tenemos Internet.

Si tienes que enseñar el portal de Azure, por ejemplo, o algún otro sitio o servicio web que sólo esté online, más vale que hagas un video de lo que fueses a enseñar para tenerlo de backup en caso de no tener Internet, o por lo menos realizar algunas capturas de pantalla significativas.

Luego ten en cuenta siempre el tipo de proyecto que vas a enseñar. Si vas a crear p.ej. un sencillo sitio web con ASP.NET MVC, por suerte puedes ejecutarlo en local con Visual Studio, sin necesidad de publicarlo en Azure o similar. Yo en mi caso hago muchas sesiones sobre desarrollo de apps móviles. Estas apps suelen llamar a servicios web y mostrar imágenes. Así que si no tengo Internet más vale que la app implemente algún tipo de caché para los datos que recibe del servicio web, ya sea un SQLite o directamente guardando varios de los Json recibidos con anterioridad, para que la app muestre algo aún no teniendo Internet; las imágenes ya las cachea el sistema operativo por si mismo sin que tengamos que hacer nada. Así que antes de hacer la sesión procuro ejecutar las demos teniendo Internet, navego por la app un rato para que vaya haciendo su trabajo, llamando a los web services y bajándose imágenes, para que así cuando no tenga Internet la app tenga algo de contenido que enseñar.

Ahora, hay una cosa que muchas veces no tenemos en cuenta y que nos puede explotar si no tenemos Internet: las dependencias que puedan tener los proyectos. Si necesitas algún Framework o SDK, más vale que venga ya instalado de casa. ¿Y qué pasa con los paquetes NuGet? Por fortuna NuGet mantiene una caché en tu disco con los paquetes que se ha ido descargando para los diferentes proyectos, y podemos utilizar esa caché como fuente de paquetes en caso de no tener Internet. Aquí tienes más detalles de cómo hacerlo: How to access NuGet when NuGet.org is down (or you're on a plane). Así que siempre compila tu código con antelación cuando tengas Internet para que la caché contenga los paquetes que necesitas. Te pueden hacer falta.

Espero que todo esto te sea de utilidad.

Un saludo,

Alejandro Campos Magencio (@alejacma)

Technical Evangelist

PD: Mantente informado de todas las novedades de Microsoft para los desarrolladores españoles a través del Twitter de MSDN, el Facebook de MSDN, el Blog de MSDN y la Newsletter MSDN Flash.