[OPINION] Good news –> SDL bajo licencia Creative Commons (tomá mate !!!)

image

Buenas,

usualmente no suelo escribir opiniones sobre este tipo de decisiones, siempre tengo miedo de caer en un blog amarillista como esos que se dedican a opinar o especular sobre productos informáticos pero que nunca han dedicado más de 2 minutos a realmente ver el detalle que esconden los mismos –> alt1040 es el mejor ejemplo.

Otro ejemplo son aquellos que atacan a Microsoft y defienden el software libre, bajo las premisas:

“puedo conocer lo que hace la aplicación XXX, puedo modificar y compartir la aplicación XXY, etc.”

Pero cuando se les pregunta en cuantos proyectos de software libre han participado, o cuantas veces han leido el código fuente del product XAY, XPY o XBY; pues te terminas dando cuenta que en realidad lo que buscan es software gratis. Este comentario, en un post sobre el software libre lo dice todo independientemente de los errores ortográficos:

“pues yo eligo firefox por ser una exelente aplicacion , y si fuera cerrado y de pago , me lo bajaria con torrent keygen incluido”

El otro extremo son los apple fanboys, pero si empiezo con esos, puedo escribir otro libro … !!!!

Si has leido hasta aquí seguramente te preguntarás 2 cosas:

Para la primera respuesta, tendrás que pasar por casa/caja; pero la 2da es mucho más interesante.

Hasta hace poco tiempo, la licencia con la que se distribuía la información de SDL era una licencia propietaria de Microsoft, que básicamente cerraba todas las puertas sobre los contenidos. Sin embargo, desde hace un par de días, esta política se ha cambiado y de a poco la documentación relacionada con SDL se publicará bajo una licencia Creative Commons (el detalle completo de utilización de la información bajo esta licencia se puede leer aquí).

Yo no soy ningún experto en modelos de licenciamiento, pero si puedo augurar un par de escenarios muy interesantes:

  • A partir de este momento, muchas empresas podrán comenzar a utilizar SDL como base para construir sus propios modelos de seguridad. Todos sabemos que ningún producto o tecnología cubre 100% las necesidades de una organización, pues con este modelo será mucho más fácil.
  • A partir de este momento, muchas empresas podrán comenzar a incorporar información, que se encuentra dentro de SDL, y compartirla con partners, clientes, etc.
  • A partir de este momento, seguramente veremos en muchos más lados los Training Materials, Case Studies, WhitePapers, etc.; propios de SDL
  • Esto puede ser la base para que otros equipos de producto, comiencen a cambiar el modelo de licenciamiento de la información en MS.

 

Y la pregunta final:

¿Porqué cambia el modelo de licenciamiento Microsoft?

Obviamente no tengo la respuesta, pero si una teoría al respecto

Por todos es sabido que los productos de Microsoft tienen fama de inseguros. Esto sucede cuando eres dueño de una cuota muy grande en un mercado, y además cuando tus productos son la plataforma en la que se desarrollan muchas aplicaciones. Pero, ¿qué sucede cuando el problema no es la plataforma, sino los productos que se desarrollan para la misma? (un ejemplo), pues que los blogs amarillistas se llenan de noticias anti-Microsoft y solo unos pocos profesionales serios se ponen a estudiar estos “problemas de seguridad” y llegan a conclusiones que nada tiene que ver con las ideas originales.

¿Qué hacer en estos casos?, pues promover buenas prácticas de creación de productos en lo referido a seguridad y de eso se trata en gran parte SDL. Al cambiar la forma de licenciamiento, espero yo que más de uno comience a leer estos documentos y probar las herramientas.

Finalmente comentar que el cambio de licencia se aplica a la documentación relacionada con SDL, no a los productos; que Microsoft todavía no vive del aire y tiene que cobrar unos €urakos por utilizar los mismos. Y hablando de vivir del aire, me voy a jugar con mi enano, que de seguridad solo tiene el casco de su bici.

 

Saludos @ Home

El Bruno (@elbruno en Twitter)

 

PostDatas amarillistas

PD1: si este fuese un blog amarillista el título del post sería algo así como “Microsoft es software libre !!! con licencia Creative Commons !!!”

PD2: si este fuese un blog amarillista, debería poner una foto mía con gafas pasta a la moda, una barba de 2 días, y cara de pensar “tengo el gadget que tu nunca conocerás y que yo nunca aprenderé a utilizar”

[MSBUILD] Incluyendo/importando archivos de proyectos externos (VII)

image47dd1de4

Buenas,

después de hablar de uno de los elementos que nos permiten modularizar la ejecución de nuestros proyectos de MSBuild: los MSBuild Targets, otra opción que poseemos es poder importar/incluir archivos de proyecto de MSBuild en otros archivos de proyectos. Para esto se utiliza la etiqueta <Import>. La misma permite incluir el contenido de un archivo externo dentro del archivo de proyecto en la que se define.

Por ejemplo, si existe un archivo en [C:srcBrunoAgile01MsBuild TestsImports_1.targets] con el siguiente contenido dentro del mismo:

   1: <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" >

   2:   <Target Name="TargetImport1">

   3:     <Message Text="Target Import 1" />

   4:   </Target>

   5: </Project>

El ejemplo siguiente muestra como, desde un nuevo archivo de proyecto de MSBuild, es posible incluir el contenido de este archivo e invocar al MSBuild Target: TargetImport1 ( línea 3), e invocar al target definido en el archivo externo (línea 6).

   1: <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"

   2:          InitialTargets="Target1">

   3:   <Import Project="C:srcBrunoAgile01MsBuild TestsImports_1.targets"/>

   4:   <Target Name="Target1">

   5:     <Message Text="Target 1" />

   6:     <CallTarget Targets="TargetImport1"></CallTarget>

   7:   </Target>

   8: </Project>

 

La ejecución de este proyecto nos muestra como se ejecuta el mismo, con el target externo.

image

 

En este punto todo funciona, pero si eres una persona organizada seguramente te choca bastante que la ubicación del archivo externo necesite ser defina con el path completo. Para evitar este tipo de situaciones existen varias opciones.

El siguiente proyecto muestra una opción, en la que se define en una propiedad llamada $(SampleBuildLocation), el path con la ubicación de los archivos externos. Para definir el valor de esta propiedad, se crea un <PropertyGroup> (líneas 4 a 7), y dentro de la misma se realizan 2 acciones:

  • En primer lugar (línea 5), se intenta definir relativamente la ubicación del directorio, utilizando una Condición (ya hablaré de las mismas más adelante) y el valor de la propiedad $(BuildPath).
  • En segundo lugar (línea 6), se verifica el valor de la propiedad y si la misma es un string vacio, se define “en duro” el path con la ubicación de los archivos

A continuación, se realiza el <Import> del proyecto utilizando la propiedad $(SampleBuildCondition), y además se muestra el valor de las propiedades utilizadas en el MSBuild Target principal (líneas 10 y 11):

   1: <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"

   2:          InitialTargets="Target1">

   3:   <!-- Imports de archivos de proyecto externos -->

   4:   <PropertyGroup>

   5:     <SampleBuildLocation Condition="Exists('$(BuildPath)..Tests')">$(BuildPath)..Tests</SampleBuildLocation>

   6:     <SampleBuildLocation Condition="'$(SampleBuildLocation)' == ''">C:srcBrunoAgile01MsBuild Tests</SampleBuildLocation>

   7:   </PropertyGroup>

   8:   <Import Project="$(SampleBuildLocation)Imports_1.targets"/>

   9:   <Target Name="Target1">

  10:     <Message Text="Build Path: $(BuildPath)" />

  11:     <Message Text="Sample Tfs Build: $(SampleBuildLocation)" />

  12:     <Message Text="Target 1" />

  13:     <CallTarget Targets="TargetImport1"></CallTarget>

  14:   </Target>

  15: </Project>

 

La ejecución de este proyecto nos muestra como la propiedad $(BuildPath) no posee valor y además el valor con el que se arma el path para incluir el archivo externo.

image 

 

Saludos @ Here

El Bruno (@elbruno en Twitter)

[MSBUILD] Invocando Targets y pasando valores entre los mismos (VI)

image47dd1de4

Buenas,

una vez definidos nuestros MSBuild Targets, es momento de controlar el flujo de llamadas entre ellos. Para esto utilizamos la tarea de MSBuild: CallTarget. Esta tarea tiene una sintaxis muy simple, y el atributo @Targets, define los MSBuild Targets que se invocarán.

Por ejemplo, en el siguiente proyecto, existen definidos 3 Targets:

  • Target1
  • Target2
  • Target3

y utilizando la tarea CallTarget, se define el siguiente flujo de llamadas: Target1 –> Target2 –> Target3, en las líneas 5 y 9:

   1: <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"

   2:          InitialTargets="Target1">

   3:   <Target Name="Target1">

   4:     <Message Text="Target 1" />

   5:     <CallTarget Targets="Target2" />

   6:   </Target>

   7:   <Target Name="Target2">

   8:     <Message Text="Target 2" />

   9:     <CallTarget Targets="Target3" />

  10:   </Target>

  11:   <Target Name="Target3">

  12:     <Message Text="Target 3" />

  13:   </Target>

  14: </Project>

 

El resultado de la ejecución del prioyecto es similar al siguiente:

image

 

Ahora bien, esta tarea además de gestionar la llamada entre MSBuild Targets, analiza las dependencias entre los mismos al momento de ejecutar para evitar bucles infinitos.

El siguiente proyecto, muestra un ejemplo de un bucle infinito, donde el Target1 se llama a si mismo.

   1: <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"

   2:          InitialTargets="Target1">

   3:   <Target Name="Target1">

   4:     <Message Text="Target 1" />

   5:     <CallTarget Targets="Target1" />

   6:   </Target>

   7: </Project>

 

Si intentamos ejecutar este proyecto, veremos que el compilador de MSBuild, se encarga de alertarnos sobre una dependencia circular:

image

 

Finalmente un caso común a tener en cuenta, es aquel en donde necesitamos invocar a un MSBuild Target, varias veces pero con diferentes valores. Es decir, similar a llamar a una función pasando diferentes valores a los parámetros de la misma.

El siguiente ejemplo muestra un proyecto en donde, en el MSBuild Target principal Target1, se invoca a un nuevo MSBuild Target denominado Target2, que muestra en ell output los valores de las propiedades $(Name) y $(Edad) (líneas 14 y 15).

Esta invocación no la realizo utilizando la tarea CallTarget, y además utilizo la tarea MSBuild Task para realizar la llamada, con las siguientes consideraciones:

  • Utilizo el proyecto actual como proyecto a compilar, asignando $(MSBuildProjectFile) al atributo @Projects.
  • Defino el Target2 como el MSbuild Target a invocar, en el atributo @Targets.
  • Defino las propiedades $(Name) y $(Edad) con valores diferentes en cada llamada (líneas 8 y 11).

 

   1: <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"

   2:          DefaultTargets="Target1">

   3:   <Target Name="Target1">

   4:     <Message Text="Target 1" />

   5:     <CallTarget Targets="Target2" />

   6:     <MSBuild Projects="$(MSBuildProjectFile)"

   7:              Targets="Target2"

   8:              Properties="Name=Valentino;Edad=2" />

   9:     <MSBuild Projects="$(MSBuildProjectFile)"

  10:              Targets="Target2"

  11:              Properties="Name=Martina;Edad=Casi 1" />

  12:   </Target>

  13:   <Target Name="Target2">

  14:     <Message Text="Name = $(Name)" />

  15:     <Message Text="Edad = $(Edad)" />

  16:   </Target>

  17: </Project>

 

Este proyecto, invoca nuevamente al compilador de MSBuild y en lugar de comenzar por el Target1, definido como @DefaultTarget, inicia en el Target2, e inicializa las propiedades con los valores correspondientes. El resultado de la ejecución muestra como no existen valores para las propiedades en la primera llamada, pero si se muestran datos en las llamadas con la tarea MSBuild Task.

image

 

Saludos @ Here

El Bruno (@elbruno en Twitter)

[MSBUILD] Gestionando errores en tiempo de ejecución (V)

image47dd1de4

Buenas,

en el post anterior comentaba como funciona un elemento básico de MSBuild, como son los MSBuild Target. Un detalle interesante a tener en cuenta cuando trabajamos con estos elementos es la captura de excepciones. Soy conciente de que muchos de ustedes no tienen errores en el código, pero como yo soy un poco corto de luces y en la cabeza solo tengo pelos, pues tengo que aprovechar la tarea <OnError> para gestionar este tipo de escenarios.

Sunpongamos el siguiente proyecto de MSBuild, donde el target principal <Target1>, invoca a una tarea que no existe <EstaTareaNoExiste> en la línea 4. Para controlar este error, en la línea 5, he utilizado el elemento <OnError> definiendo que se invoque al target <GestionError> en el caso de que se produzca un error:

   1: <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"

   2:          InitialTargets="Target1">

   3:   <Target Name="Target1">

   4:     <EstaTareaNoExiste />

   5:     <OnError ExecuteTargets="GestionError" />

   6:   </Target>

   7:   <Target Name="GestionError">

   8:     <Message Text="Ha ocurrido un error !!!" />

   9:   </Target>

  10: </Project>

 

La ejecución nos muestra como se dispara el error, relacionado con la tarea que no existe y a continuación se muestra el mensaje definido en el target de gestión de errores (línea 8).

image

 

 

 

 

Saludos @ Home

El Bruno (@elbruno en Twitter)

[MSBUILD] Utilizando Targets en proyectos de Build (IV)

image47dd1de4

Buenas,

en el mini post de hoy, veremos uno de los componentes más importantes de MSBuild: los MSBuild Targets. Los mismos permiten definir bloques o secciones de acciones de manera que sea posible organizar la ejecución de un proyecto de compilación de una forma más ordenada. Haciendo una analogía con la programación que conocemos, un MSBuild Target, es algo similar a una función.

Un ejemplo simple de un proyecto donde se utilicen MSbuild Targets es el siguiente:

   1: <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

   2:   <Target Name="Target1">

   3:     <Message Text="Target 1" />

   4:   </Target>

   5:   <Target Name="Target2">

   6:     <Message Text="Target 2" />

   7:   </Target>

   8: </Project>

Donde podemos ver que el archivo de proyecto, posee 2 elementos <Target> definidos (líneas 2 y 5) y dentro de los mismos, se utiliza la tarea <Message> para mostrar información.  Si ejecutamos el archivo de proyecto, veremos que se toma el primer MSBuild Target (línea 2), como el predefinido y se ejecuta el mismo:

image

Si necesitamos definir uno o más targets por defecto, para nuestro proyecto, es posible hacerlo utilizando el atributo @DefaultTargets en el elemento <Project>.

En el siguiente ejemplo, definimos como target por defecto el Target2:

   1: <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"

   2:          DefaultTargets="Target2">

   3:   <Target Name="Target1">

   4:     <Message Text="Target 1" />

   5:   </Target>

   6:   <Target Name="Target2">

   7:     <Message Text="Target 2" />

   8:   </Target>

   9: </Project>

La ejecución del proyecto, nos muestra como en este caso se muestra el mensaje definido en el Target2 (línea 7):

image

 

 

 

 

Si necesitamos definir más de un target por defecto para nuestro proyecto, lo podemos realizar del mismo modo.

El siguiente proyecto de ejemplo muestra un caso, donde los DefaultTargets son Target1 y Target3:

   1: <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"

   2:          DefaultTargets="Target1;Target3">

   3:   <Target Name="Target1">

   4:     <Message Text="Target 1" />

   5:   </Target>

   6:   <Target Name="Target2">

   7:     <Message Text="Target 2" />

   8:   </Target>

   9:   <Target Name="Target3">

  10:     <Message Text="Target 3" />

  11:   </Target>

  12: </Project>

La ejecución de este proyecto muestra los mensajes correspondientes a cada <Target> (líneas 4 y 10).

image

Si bien es posible utilizar el atributo @DefaultTargets para indicar los MSBuild Targets que queremos ejecutar, también existen otras opciones:

  • Utilizar el atributo @InitialTargets para indicar los targets a ejecutar en el elemento <Project>.
  • Utilizar el comando /target en la llamada a la compilación del proyecto para definir el target a ejecutar.

El en 2do ejemplo volvemos al primer ejemplo de ejecución, donde no hemos definido un target por defecto, ni un target inicial:

   1: <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

   2:   <Target Name="Target1">

   3:     <Message Text="Target 1" />

   4:   </Target>

   5:   <Target Name="Target2">

   6:     <Message Text="Target 2" />

   7:   </Target>

   8: </Project>

 

Y en la compilación por línea de comandos indicamos la ejecución del Target2 como el punto de entrada del proyecto de Build, con el switch /target:Target2.

image

Pues bien, como siempre más información en MSDN http://msdn.microsoft.com/en-us/library/ee216359.aspx.

 

Saludos @ Home

El Bruno (@elbruno en Twitter)

[TFS2010] Visual Studio 2010 Lab Management Deployment Guide para subscriptores MSDN (no vale la pena)

Clipboard02

Buenas,

cuando hace unos días ví que estaba disponible una guía de despliegue para Visual Studio Lab Management 2010,  me dije “por fin, una guía decente para poder comenzar”. Así que me fuí a MSDN, y descargue la misma.

image

La sorpresa fue cuando, una vez descargado el instalador, me encontré un documento de texto de aprox 27KB, que básicamente posee links a las referencias de Visual Studio Lab Management 2010 en MSDN (si haces click en el link anterior ya tenes el 50% del doc).

Como es sábado y estoy cansado de escuchar quejas … paso de quejarme y recomiendo no perder el tiempo con la descarga. En su lugar, ir directamente a la documentación de MSDN.

 

 

 

 

Saludos @ Home

El Bruno (@elbruno en twitter)

[VS2010] Pex for Fun (ideal para ver quien paga las cervezas ^^)

image47dd1de4

Buenas,

el equipo de Microsoft Research a cargo de Pex, a creado un sitio más que interesante para que aprendamos un poco más sobre la utilización de Pex y que recordemos conceptos básicos de programacón en más de un caso.

El site Pex for Fun propone una serie de retos (Pex duels) para que sean analizados con Pex. Estos retos son fragmentos de código en C#, Visual Basic.Net y F# que se presentan para que los completemos directamente en el sitio web y luego sean analizados por el motor de Pex.

Por ejemplo, si se nos presenta el siguiente problema “puzzle”, tenemos una función con 2 parámetros de entrada y un código incierto por determinar.

   1: using System;

   2: using Microsoft.Pex.Framework;

   3:  

   4: public class Program

   5: {

   6:     public static int Puzzle(int x, int y)

   7:     {

   8:         // Can you write code to solve the puzzle? Ask Pex to see how close you are.

   9:         return x;

  10:     }

  11: }

 

Podemos ver que al momento de analizar el código, el mismo verifica los parámetros y suma los mismos:

image

 

La solución rápida que se nos ocurre es la siguiente:

   1: using System;

   2: using Microsoft.Pex.Framework;

   3:  

   4: public class Program

   5: {

   6:     public static int Puzzle(int x, int y)

   7:     {

   8:         // Can you write code to solve the puzzle? Ask Pex to see how close you are.

   9:         return x + y;

  10:     }

  11: }

 

Si analizamos nuevamente el reto, vemos que estamos más cerca pero no lo suficiente:image

 

A partir de aquí es necesario modificar un poco más el código, para que el mismo sea correcto. 

Lo interesante de esto, es que hay bastantes ejemplos diferentes que van desde escenarios donde hay que ordenar arrays, verificar si un string es un anagrama, etc. Lo recomendable es elegir uno al azar, juntarnos con un compañero y ver quien lo saca en menos tiempo. Eso sí, con una cerveza como premio final pagada por el perdedor.

 

 

 

 

Saludos @ Home

El Bruno (@elbruno en Twitter)

Recursos

[VS2010] Microsoft Team Foundation Server 2010 MOSS Configuration Tool

image47dd1de4

Buenas,

gracias al amigo Javier (@jcalvarro), me entero de una interesante herramienta para configurar entornos con Team Foundation Server 2010 y Sharepoint 2007 o Sharepoint 2010. Si bien la versión 2010 de TFS simplifica mucho la instalación y configuración de estas herramientas, todavía es un poco infierno el tener que lidiar con algunos aspectos de Sharepoint+TFS. Esta herramienta que se puede descargar desde la Visual Studio Gallery, se gestiona en modo asistente.

Una vez seguidos los pasos básicos de configuración desde TFS con Sharepoint, que se explican en Add Integration with SharePoint Products to a Deployment of Team Foundation Server, estas son las opciones que se configuran para la integración en Office SharePoint Server 2007:

  • Shared Service Provider (SSP)
  • Excel Services
  • Single Sign-on

Y estas en SharePoint Server 2010:

  • Excel Services
  • Secure Store Service

La siguiente imagen muestra un ejemplo de la herramienta, para la configuración de varios servicios en Sharepoint 2010:

image

 

Luego podemos ver como se aplican los cambios definidos:

image

 

Y terminar con el clásico y tan esperado Success

image

Si ya tienes un entorno en marcha con Sharepoint y TFS, esta herramienta dejará de lado los pasos y opciones ya configuradas. Pero podrás ver que opciones adicionales tienes para trabajar.

 

 

 

 

Saludos @ Home

El Bruno (@elbruno en Twitter)

Descarga: http://visualstudiogallery.msdn.microsoft.com/en-us/db469790-5e3e-42f3-906e-411a73795a1b

[RESEARCH] Microsoft Biology Foundation

image47dd1de4

Buenas,

se van acabando las vacaciones asi que me toca ponerme al día de a poco … en este caso con Microsoft Biology Foundation. Que si bien suena un poco a foundation maligna de película clase B para conquistar al mundo, se autodefine como:

The Microsoft Biology Foundation (MBF) is a language-neutral bioinformatics toolkit built as an extension to the Microsoft .NET Framework, initially aimed at the area of Genomics research. Currently, it implements a range of parsers for common bioinformatics file formats; a range of algorithms for manipulating DNA, RNA, and protein sequences; and a set of connectors to biological web services such as NCBI BLAST. MBF is available under an open source license, and executables, source code, demo applications, and documentation are freely downloadable.

Básicamente es una serie de lenguajes y herramientas (y extensiones de Excel), desarrolladas con Microsoft .Net para el estudio y análisis del genoma. Vamos que suena a japones encriptado, pero sé que de uno que le va a dar un vistazo (es lo que tiene ser hijo de un padre físico especializado en biología).

Más información en CodePlex: http://mbf.codeplex.com/, desde donde además es posible descargar el código fuente de todo el proyecto. Esto último para aquellas personas cortas de vista que piensan que todo lo que se desarrolla bajo tecnología MS es código cerrado y con licencia APS (Acuerdo de Privacidad con Satanás).

 

 

 

Saludos @ Home

El Bruno

Fuente: http://www.xconomy.com/seattle/2010/05/03/microsoft-builds-open-source-tool-for-biologists-drowning-in-data-an-on-ramp-for-customers-who-pay/

[VS2010] ReSharper Power Toys: WhySharper (te explica indica la ruta, pero no el camino)

image47dd1de4

Buenas,

post cortito para un viernes. Hoy toca darle un repaso a una extensión para ReSharper, llamada WhySharper. Esta extension agrega una nueva opción de menú en las acciones que se proponen en ReSharper con el clásico Alt+Enter, en la que se agrega un “Why … action”, es decir, se explica el porqué de la propuesta de cambio por R#.

Como siempre, un par de imágenes valen más que un par de miles de palabras:

 

 

 

 

 

Saludos @ Here

El Bruno

Descarga: http://code.google.com/p/whysharper/