Contar Líneas de Código

Nasa Contar líneas de código fuente es una práctica que se viene realizando desde tiempos inmemoriales… vamos desde antes de 1970 más o menos. Por ejemplo, de acuerdo con el Centro Tecnológico de Calidad de Software (Software Assurance Technology Center – SATC) de la NASA:

“El tamaño es una de las formas más antiguas y comunes de medición de software. El tamaño de los módulos es en sí misma un indicador de calidad. El tamaño puede ser medido a través del total de líneas de código, contando todas las líneas; que no correspondan a comentarios y que no esté en blanco, disminuyendo las líneas totales, por el número de espacios en blanco y comentarios, y todas aquellas sentencias ejecutables que se definen por un delimitador dependiente del lenguaje de programación.”

Sin embargo, con el paso del tiempo y medida que nuestra disciplina evolucionaba y maduraba, se determinó que por sí sólo el número de líneas de código en un proyecto de software no es un indicador de la calidad del mismo, o la productividad del trabajo realizado por los desarrolladores, si se podría afirmar que es una métrica confiable del tamaño real del proyecto. Habitualmente es una métrica que combinamos con índices como la Complejidad Ciclomática o el número de clases.

En el mundo de Visual Studio contamos con una funcionalidad denominada Code Metrics la cual nos muestra una serie de estadísticas muy útiles sobre nuestra solución y sus proyectos. Entre estas métricas está la cuenta de líneas de código.

Metrics

Ahora, esta cuenta no es exactamente todas las líneas de código de nuestra solución (o proyecto), sino una cuenta aproximada basada en el código IL generado por la compilación (vamos, más o menos lo que hace la NASA). Éste índice como tal es bastante útil en determinar si un método está haciendo más de lo que debe, pues aún cuando un método tenga cientos de líneas de código físico, la compilación puede hacer que el número de líneas sea radicalmente menos, y si el mismo no baja, puede indicar una pobre o inapropiada mantenibilidad del método.

Cuando necesito conocer las líneas reales de código fuente, su tipo (código, comentario o línea en blanco) y su distribución (SQL, XML, ASP.NET o C#) empleo y recomiendo un pequeño programa llamado CLOC, el cual no requiere instalacieon, es súper fácil de usar y soporta cientos de tecnologías y lenguajes de programación, incluyendo C#, ASP.NET, VB.NET y muchos más.

Count

Entre sus características básicas, me es muy útil que es capaz de reconocer el número de líneas blancas dentro de código, y aquellas que se corresponden a texto de documentación y comentarios, con lo cual se puede obtener métricas, ahora si de la calidad del código, sobre cuanto documentado este puede estar. Por ejemplo, imaginen un código fuente sin ninguna documentación. A través de una aplicación como CLOC podríamos determinar esto y así levantar la correspondiente incidencia.

Otras característica interesante es que se puede obtener un reporte de líneas de código por archivo o por lenguaje.

El reporte puede exportarse a un archivo separado por comas, a XML e incluso en sentencias de SQL que pueden ser útiles para inyectar en una base de datos de reportes de estado y salud del proyecto.

Profesionalmente, al realizar auditorias técnicas complemento el resultado del Code Metrics del Visual Studio con los resultados de CLOC. De esa forma puedo ofrecer una fotografía completa de la mantenibilidad del código versus cuanto está escrito, cuanto es espacio vacío y que tanta documentación podríamos encontrar.

Anuncios

Evitar la ventana de “Adjuntar Advertencia de Seguridad”

Hoy día ya es casi asumible que todo sistema tendrá en su arquitectura uno o más componentes de servicios, habitualmente servicios web. En la plataforma .NET, los servicios web vienen en muchas formas siendo las dos más habituales los ASMX y los SVC (WCF Web Services).

Resulta que con el Windows 7 y el Visual Studio 2008/2010 cuando trabajamos con referencias a servicios web de WCF nos suele saltar la siguiente ventana al depurar la aplicación:

Particularmente esta ventana no supone nada malo. Es una simple advertencia del sistema operativo en la que nos informa de que un usuario X trata de depurar un proceso Y. El problema es que un proceso normal de desarrollo involucra incontables sesiones de depuración, lo que eventualmente conlleva a odiar esta advertencia…

La solución formal y correcta resulta ser bastante sencilla (más allá de estar tocando el registro de Windows). Hay que seguir los siguientes pasos:

  1. Abrir la cónsola de gestión del IIS (simplemente ejecutar el comando inetmgr).
  2. Posicionarse sobre el grupo de aplicaciones (Application Pool).
  3. Seleccionar el grupo de aplicaciones sobre el cual se ejecuta el componente de servicios web de nuestro sistema.
  4. Con el botón derecho del mouse elige la opción de “Opciones Avanzadas”.
  5. En la ventana que aparece, buscamos el apartado de “Identidad” y hacemos click en el botón con los puntos suspensivos (‘…’).
  6. En la nueva ventana emergente, seleccionamos del desplegable de cuentas integradas la opción de “NetworkService”.
  7. Salimos de estas ventanas, y desde una línea de comando con derechos de administrador ejecutamos un reset del IIS (simplemente ejecutar el comando iisreset).

Y santo remedio. Ahora cuando depuremos una aplicación que emplea referencias a servicios web de WCF o cualquier otra integración con otro sistema al cual deba anexarse el depurador no nos saldrá la advertencia de seguridad.

Como cambiar el navegador por defecto en el Visual Studio… sin perder la cabeza!

Los profesionales que trabajamos con el ecosistema de Microsoft y la plataforma .NET solemos estar más que confirmes con el Internet Explorer (excepto el nefasto Internet Explorer 6); sin embargo la mayoría de las veces cuando trabajamos en proyectos web, nuestros clientes nos exigen soportar más de un navegador.

Parte del proceso de soportar más navegadores que el Internet Explorer es que se necesita probar cada página para garantizar su correcto funcionamiento (a nivel de JavaScript) y apropiado renderizado gráfico (a nivel de imágenes, diagramación, estilos y CSS). Lo ideal sería poder probar las páginas directamente desde el Visual Studio, pero cambiar el navegador por defecto que se ejecuta con cada depuración puede llegar a ser algo… laborioso.

En realidad, cambiar el navegador por defecto en el Visual Studio no es difícil, pero tener que hacerlo cada vez que se quiera probar una página o funcionalidad con tres o cuatro navegadores diferentes, entonces empieza a ser un verdadero dolor en… la cabeza.

Algunas personas encontraron mecanismos para automatizar el proceso a través del Windows PowerShell como por ejemplo Scott Hanselman (@shanselman) en este artículo de su blog.

Fue gracias al trabajo de Scott que la gente de Clarius Consulting creó un add-on para el Visual Studio que agrega una nueva barra al menú con botones que permiten cambiar de forma rápida y sencilla el navegador por defecto con el cual queremos trabajar. Esta barra soporta los más nuevos y usados navegadores a parte de Internet Explorer, como por ejemplo: Opera, Safari, Chrome y Firefox.

Este add-on está disponible aquí. Cabe destacar que este add-on es sólo para el Visual Studio 2005, 2008 y 2010, ya que el nuevo Visual Studio 2012 ya incluye esta maravillosa funcionalidad built-in (incluso siendo capaz de levantar y trabajar con más de un navegador a la vez).

Cuando el reto es soportar más de una versión del Internet Explorer, el tema cambia debido a la limitación que tiene Windows de no permitir que diferentes versiones de su navegador convivan en una misma instancia del sistema operativo. Para esos casos en que tenemos que probar contra diversas versiones del IE, no nos queda otra que emplear máquinas virtuales. La parte positiva es que Microsoft sabe de estos escenarios y pone a disposición de la comunidad de desarrolladores y diseñadores web de forma gratuita máquinas virtuales de Virtual-PC con diferentes configuraciones de sistemas operativos y del navegador Internet Explorer. Estas imágenes están disponibles aquí.

Actualización 02-Agosto-2013

Resulta que Microsoft ha movido el tema de las imágenes de máquinas virtuales a un sitio web especializado en el tema de la creación y gestión de aplicaciones web que sean soportadas por varios navegadores. Las imágenes están disponibles en dicho sitio web: http://www.modern.ie/.

Minify JavaScript and CSS files when publishing Web Applications from Visual Studio

One of the best practices to speed up a web site or web application is to minify JavaScript and CSS files; which as a secondary effect, not only reduces the size of those files but also makes them harder to read (something helpful to prevent the stealing of your ideas and efforts).

Intro

You may think that actually this is not very helpful since using external JavaScript and CSS files in the real world generally produces faster pages because they will be cached by the browser. However, if their size is big, you may improve the first request load time by reducing their size.

Minification is the practice of removing unnecessary characters from code to reduce its size thereby improving load times. When code is minified all comments are removed, as well as unneeded white space characters (like newlines or tabs). This improves response time performance because the size of the downloaded file is reduced.

There are many tools to minify JavaScript and CSS files, like for example:

I’m a Microsoft .NET professional, so in this and future post, I will going to focus only on Microsoft’s Ajax Minifier tool.

The proper time to minify

It is not advisable to minify your web application’s JavaScript and CSS files during developing time; it should be done on deployment or publish (for testing or any other purpose) time.

But then, how to minify those files without affecting the original source code in the solution when deploying it?

The answer is quite easy: we must use MSBuild in the web application project file to configure the Microsoft Ajax Minifier to be executed as a task when publishing in ‘Release’ mode.

The steps to minify

The first step is to unload the web application project by right-clicking on it and choose the option ‘Unload Project’. Once unloaded, right-click it again and choose the ‘Edit <web_app_project_name>.csproj’ option, which will open the XML editor of the Visual Studio with the project’s configuration.

What I usually do, is to go to the end of the file and then add the following line just before the closing Project tag:

<UsingTask TaskName="AjaxMin" AssemblyFile="$(SolutionDir)Lib\AjaxMinTask.dll" />
<PropertyGroup>
    <ResGenDependsOn>
        CompressJsAndCss;
        $(ResGenDependsOn)
    </ResGenDependsOn>
</PropertyGroup>

Please note the PropertyGroup tag. It describes the property activity to perform and its dependency with the generation of resources. This is very important to specify.

I prefer the UsingTask tag instead of the Import tag because I work with a lot of people who may have installed the Microsoft Ajax Minifier in different versions or locations that me (or not having it installed at all). So we distribute the solution’s dlls inside a Lib subfolder, that is also under source control. With this mechanism, every body uses the same dlls in the same version and referenced from the same location.

It is very important to take into account that you will need to have the AjaxMinTask.dll and also the AjaxMin.dll in the same location.

The next step is to create a custom target with the following lines:


<Target Name="CompressJsAndCss" AfterTargets="CopyAllFilesToSingleFolderForPackage" Condition="'$(Configuration)'=='Release'">
...
</Target>

The new target is called CompressJsAndCss and will be executed when publishing a web application just after the CopyAllFilesToSingleFolderForPackage target, which is responsible of copying (or materialize in-memory files) the project files into your obj folder (specifically the folder specified by _PackageTempDir) in preparation for a publish.

Next, we need to gather the files suitable to be minified, in this case, JavaScript and CSS files. To do so, just add the following lines to the custom target:


<ItemGroup>
      <JS Include="$(_PackageTempDir)\**\*.js" Exclude="$(_PackageTempDir)\**\*.min.js" />
      <CSS Include="$(_PackageTempDir)\**\*.css" Exclude="$(_PackageTempDir)\**\*.min.css" />
</ItemGroup>

As you can see, we’re creating a set of all available JavaScript and CSS files in the _PackageTempDir folder (where the CopyAllFilesToSingleFolderForPackage put the files for the publication) but excluding those with extension .min.js or .min.css which are already minified (usually jQuery files).

Finally, we must call the Microsoft Ajax Minifier task in order to minify the gathered files with the following lines:


 <AjaxMin JsKnownGlobalNames="jQuery,$" JsSourceFiles="@(JS)" JsSourceExtensionPattern="\.js$" JsTargetExtension=".js"
          CssSourceFiles="@(CSS)" CssSourceExtensionPattern="\.css$" CssTargetExtension=".css"/>

Note that we’re informing the Microsoft Ajax Minifier to respect the ‘jQuery’ and ‘$’ literals on the JavaScript files since they are well know global names that must not be modified in the minify process.

At the end, we should have the following added configuration:


<!-- Minify all JavaScript and CSS files that are present on this web application when publish in release. -->
  <UsingTask TaskName="AjaxMin" AssemblyFile="$(SolutionDir)Lib\AjaxMinTask.dll" />

  <!-- This target will run after the files are copied to PackageTmp folder (usually 'obj\Release\Package\PackageTmp') -->
  <Target Name="CompressJsAndCss" AfterTargets="CopyAllFilesToSingleFolderForPackage" Condition="'$(Configuration)'=='Release'">
    <ItemGroup>
      <JS Include="$(_PackageTempDir)\**\*.js" Exclude="$(_PackageTempDir)\**\*.min.js" />
      <CSS Include="$(_PackageTempDir)\**\*.css" Exclude="$(_PackageTempDir)\**\*.min.css" />
    </ItemGroup>
    <Message Text="Compressing JavaScript and CSS files..." Importance="high" />
    <AjaxMin JsKnownGlobalNames="jQuery,$" JsSourceFiles="@(JS)" JsSourceExtensionPattern="\.js$" JsTargetExtension=".js"
             CssSourceFiles="@(CSS)" CssSourceExtensionPattern="\.css$" CssTargetExtension=".css"/>
  </Target>

So what is left to do is to save the csproj file, close it and right-click on it from the Solution Explorer and choose the ‘Reload Project’ option in order to load it again in the solution.

Now when we go to publish the web application (and in ‘Release’ mode) our custom target will be evaluated just after the CopyAllFilesToSingleFolderForPackage target, and all JavaScript and CSS files will be minified without affecting the original ones.

References

Forzar la Desinstalación del Visula Studio 2008

Muchas veces nos encontramos con la situación de que necesitamos agregar o remover un componente de nuestra instalación del VS2008, o simplemente nos queremos deshacer de él. Sin embargo, cuando ejecutamos desde el medio (DVD ó ISO) a través del cual lo instalamos, o desde el ‘Add or Remove Program’ del Control Panel (o su equivalente en Windows Vista/7) nos encontramos con el siguiente mensaje:

La solución final vendría de desinatalar completamente y de forma forzosa el VS2008 empleando la herramienta de auto-desinstalación de Microsoft, la cual puede ejecutarse desde aquí.