SkunkWorks

Después de darle vueltas al asunto por todos lados, chocarme con todos los muros del mundo (e intentar romperlos a cabezazos), discutir el tema con un montón de gente (Carlos Segura Sanz (el mejor conocedor de SharePoint de todo el mundo), Rolf Eleveld (el mejor desarrollador de todo el mundo), Jan Cirpka (el mejor arquitecto de todo el mundo), entre otros), el asunto se puede resumir rápidamente, y las conclusiones son aun más rápidas:

De que se trata (premisas):

– Crear Unit Tests para business layers de SharePoint. Porque, para que y que son Unit Test, lo pueden ver en el posting de Rodrigo Corral «¿Deben los test unitarios usar la base de datos?«.

– Unit Tests tienen que ser rápidos de crear (el tiempo de programación es principalmente para programar, no para crear Unit Test)

Porqué con SharePoint (postulado):

– Porque Unit Test son importantes si quieres hacer una arquitectura un poquito «limpia» de tres capas, porque Unit Test te «garantizan» que algo que desarrollas hoy siga funcionando dentro de seis meses cuando cambies la funcionalidad de las clases, porque Unit Test te aseguran que todos los desarrolladores están mirando hacia el mismo lado (aunque no necesariamente caminando por el mismo camino)

– Porque hasta ahora a nadie se le ha metido la rara idea de hacer Unit Test para SharePoint; o mejor dicho, a mucha gente le ha dado la rara idea, pero nadie ha salido con algo productivo

Lo probado (anteriormente):

– Mocking: vea el posting «Mocks, Mocking, Mockers y SharePoint«. Conclusión: no funciona

– Stubbing: vea el posting «Sutbs, Stubbing, Stubbers y SharePoint«. Conclusión: no funciona a la primera. Ni a la segunda, ni a la tercera. Es posible que haciendo Stubs para TODOS los NameSpaces de SharePoint podría funcionar, pero hacer algo así es trabajo gigantesco, y sin ninguna seguridad de que funcione. El último problema que me encontré fue que los métodos a probar con el Unit Test no aceptaban los Stubs porque no tenían la firma correcta (y, por supuesto, Microsoft no me va a prestar su Secret Key para compilar mis Stubs).

Lo probado (últimamente):

– BackUp / Restore: Salió de una conversación con Jan. Qué pasa si se abandona la idea de Mocking y Stubbing, y se vuelve a la forma «normal» de hacer Unit Test usando una instancia de SharePoint? Aquí hay varios puntos a tener en cuenta:

1 – Después de que cada Unit Test se ha ejecutado, hay que garantizar que el estado de SharePoint sea retornado a como era antes de ejecutar el test, de otra forma el Unit Test puede que devuelve resultados no confiables (usando Mocks o Stubs no existe este problema)
2 – Cada desarrollador en el grupo tiene que disponer del mismo SharePoint (del contenido, por supuesto), de otra forma, cada desarrollador obtendrá diferentes resultados
3 – Si ejecuto mis Unit Test dentro de seis meses, el resultado tiene que ser el mismo que el que he recibido hoy

Todos estos puntos se pueden cumplir si se hace un BackUp de SharePoint, se guarda en un sitio central (SourceSafe? TFS?), y se restaura después de cada ejecución del Unit Test. Los Unit Test tienen un evento de inicialización (TearUp) y otro de finalización (TearDown), de tal forma que en el evento de finalización se ejecute un Restore del BackUp. Y SharePoint dispone de su herramienta de administración stsadm, que permite crear Backups y Restores rápida e indoloramente. El TearDown de un Unit Test de Visual Studio 2005 aparecería más o menos como:

     [TestCleanup()]
     public void MyTestCleanup()
     {
         Process RestoreSharePoint = new Process();
         RestoreSharePoint.StartInfo.FileName = @»C:Program FilesCommon FilesMicrosoft Sharedweb server extensions12BINSTSADM.EXE»;
         RestoreSharePoint.StartInfo.Arguments = @»-o restore -url http://wssen -filename c:temporarybackup.dat -overwrite»;
         RestoreSharePoint.Start();
     }

– Problemas: por supuesto, siempre hay problemas… Un Restore de SharePoint no ejecuta directamente, sino por medio de un Job. Esto significa, que el Restore puede iniciar entre ahora mismo, y solo los dioses saben cuándo. Segundo problema (me parece que es un bug, pero no puedo asegurarlo), es que si se intenta hacer un Restore cuando otro Restore está ejecutando, toda la instalación de SharePoint se dirige hacia el cielo de las instalaciones destruidas de SharePoint… en serio, la cantidad de instalaciones de SharePoint que me he cargado en los últimos días son incontables, y lo peor de todo es que no hay (o por lo menos yo no lo he podido encontrar) manera de hacer que SharePoint funcione de nuevo; utilizando el comando «execadmsvcjobs» se puede forzar la ejecución de los Jobs, pero con el comando empiezan a ejecutar TODOS los Jobs, uno por uno y uno detrás del otro, así que mucha ganancia en tiempo no se obtendrá. Otro problema es la restauración en instancias de SharePoint que no son iguales a la original (si dentro de los consabidos 6 meses intentas hacer un Restore en un SharePoint que no se llama «aaa» sino «bbb», y no funciona, tienes lo mismo que no tener nada, es decir, no tienes nada)

– Conclusión: funciona, por supuesto que funciona, y hasta funciona de lo más bien. Un BackUp de una instancia de SharePoint para desarrollo no es demasiado grande (1 MB máximo, por lo que se puede guardar una copia para el futuro sin problemas), y si se guarda en un share en la red, todos los desarrolladores la pueden utilizar. Pero no me sirve si un desarrollador arranca un Test dos veces seguidas y restaura la copia al mismo tiempo: su SharePoint dejaría de funcionar. Tampoco si dentro de 6 meses no lo puedo usar. Me puede servir en el servidor de generación («Continuous Integration» en un «Build Server») o en un servidor de generación nocturna, en donde solamente de vez en cuando se ejecutan los Unit Test. Algo es algo…

Lo para probar (en el futuro cercano)

– Provisioning: Bueno, si un Restore tiene tantos problemas, que tal si el sitio se provisiona de nuevo en el TearDown? Es decir, estas probando una clase que modifica una Lista (le agrega un elemento, por ejemplo). En el TearDown, después de ejecutar el Unit Test, se ejecuta un pequeño programa que elimina el nuevo elemento, y la Lista vuelve a su estado original. Perfecto,

– Problemas: pero… este es un caso muy sencillo. En casos más complicados (y reales), suceden cosas más complicadas, y sobre todo, cosas en cadena, por ejemplo: crear un Web, agregarle algunas Listas, configurar derechos, agregar usuarios, etc… el programita ya no es mas «ita» sino «ote», y volvemos a la premisa original de que no vale la pena pasar 75% del tiempo de programación programando las clases de Unit Test.

– Soluciones (?): Crear un programa para «Provisioning»? algo así como un programa en donde puedas decir, de una forma más o menos wysiwyg: deshaga todo lo que hay hecho en SharePoint, créeme un programa (aplicación de consola) que me haga una Web, con estas Listas y estos derechos para estos usuarios, y luego subalo todo a SharePoint (el TearDown borra todo el contenido en SharePoint y lo vuelve a crear en el estado original). hmmmmmm…

El drama continúa…

Gustavo – http://www.gavd.net/servers/
Escriba un Comentario que me haga reir…

 

Continuando con la lucha para crear Pruebas Unitarias para SharePoint (vea el posting sobre Mocks, Mocking, Mockers y SharePoint)…

Resumidas cuentas, de lo que se trata es de crear objetos «falsos» de SharePoint que se puedan utilizar en Unit Test de una forma fácil, rápida e indolora. Como estoy muy lejos de ser un conocedor de teoría de pruebas de software, he estado buscando información al respecto, y me he dado cuenta que lo que ando buscando en realidad son Stubs, no Mocks. Aunque Mocks pueden funcionar como Stubs (pero no al contrario), el asunto es un poco más claro ahora (?). Hay un articulo bastante bueno sobre la diferencia entre los dos: «Mocks aren’t Stubs» de Martin Fowler. Para que no se tengan que leer un artículo largo y pesado (aunque interesante), les cuento que un Mock falsifica y verifica la conducta del objeto, mientras que un Stub simplemente falsifica al objeto, sin importarle que está pasando con sus métodos y propiedades.

Después de luchar horas y horas con el asunto, sigo sin ver la luz. Mejor dicho, ya he visto la luz del amanecer dos días seguidos (después de todo un desarrollador no necesita dormir más de dos horas de cada 24, como todos sabemos), sin encontrar el camino, y ya estoy empezando a pensar que es porque simplemente no existe.

Veamos lo que he intentado hasta ahora:

1 – TypeMock es un producto comercial (mi jefe va a tener que pagar los 150 dólares por nada) que, según las referencias, es de lo mejor que se puede encontrar. Para crear objetos mockeados, TypeMock intercepta las llamadas al CLR (Common Language Runtime) del .NET FrameWork, y retorna valores mockeados sobre-escribiendo los valores originales completamente. Interesante… TypeMock permite crear un objeto falso (un Stub) de una forma fácil y rápida:

     MockObject myLinkA = MockManager.MockObject(typeof(SPLink));
     SPLink myLink = (SPLink)myLinkA.Object;

La primera línea crea un objeto del tipo MockObject, que por dentro tiene un objeto del tipo SPLink (de SharePoint). La segunda línea se lo entrega a un objeto de SharePoint (myLink) por medio de un cast. Esta segunda línea es necesaria para extraer el objeto de SharePoint del objeto de TypeMock, de otra forma la llamada al método que se está probando generara una excepción (mejor dicho, hay que comerse la banana sin la cascara).

Con algunos objetos de SharePoint funciona bastante bien, como es el caso con SPLink. Con muchos otros no, como por ejemplo con SPList. Después de mucho buscar, al descompilar el Microsoft.SharePoint.dll me he enterado porqué: SPLink tiene un constructor que crea valores por defecto cuando se instancia al objeto; SPList tiene un constructor a lo bárbaro, es decir, crea el objeto sin valores por defecto. Por esto, al intentar ejecutar la clase de prueba se obtiene un error de lo más bonito («Test method TestProject.gavdTest.myTitleTest threw exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> System.NullReferenceException: Object reference not set to an instance of an object..»).

Otro problema es que no es posible cambiar los valores de propiedades en el Stub. Si después de crear el MockObject se intenta algo como:

     MockObject myListA = MockManager.MockObject(typeof(SPList));
     myListA.ExpectGet(«Title», «Hola Gustavo»);

el objeto no produce ningún error ni nada parecido, pero simplemente no cambia el valor (Title es read/write).

Conclusión: mientras las clases de SharePoint no tengan un constructor que defina valores por defecto, no se producirán más que errores con TypeMock. También la imposibilidad de cambiar los parámetros (ni siquiera los read/write) lo hace inusable.

2 – RhinoMock es gratis y bastante poderoso, y permite crear Stubs directamente:

     SPList myList = (SPList)MockRepository.GenerateStub(typeof(SPList));

que produce un error sobre un proxy que debe ser generado en alguna parte («Test method TestProject.gavdTest.myTitleTest threw exception: System.MissingMethodException: Can’t find a constructor with matching arguments —> System.MissingMethodException: Constructor on type ‘SPListProxyc05cefac21f14e41ae4fefa8c5e791da’ not found..»)

Y de todas formas es menos poderoso que TypeMock. Por ejemplo, no es posible crear mocks de clases selladas, o de interfaces privadas o de métodos no-virtuales. Una rápida mirada a las clases de SharePoint muestra que más o menos dos tercera partes de las clases son selladas, así que por este lado no vamos a llegar muy lejos.

Conclusion: mientras las clases de SharePoint sean selladas, nada de RhinoMock… por no decir nada sobre el misterioso proxy.

3 – Creando Stubs directamente. Después de mucho buscar, me he encontrado con NStub, un pequeño programa que crea Stubs directamente desde el ensamblado. La idea es bastante sencilla: crear una clase con la misma firma del ensamblado de SharePoint, algo por el estilo a:

namespace Microsoft.SharePoint
{
     public class SPLink : Object
     {

         public SPLink()
         {
         }

         private string _ServerRelativeUrl;
         public string ServerRelativeUrl
         {
         get { return _ServerRelativeUrl; }
         }
    … etc…

Y luego utilizar esta clase para instanciar el objeto a utilizar, y no la clase real de SharePoint (quitando la referencia a Microsoft.SharePoint). Mejor dicho, si vamos a falsificar el asunto, lo falsificamos de punta a punta. Lo malo es que tampoco funciona:

«Test method TestProject.gavdTest.myLinkUrlTest threw exception: System.ArgumentException:
The member specified (myLinkUrl)could not be found. You might need to re-generate your private accessor,
or the member may be private and defined on a base class. If the latter is true, you need to pass the type
that defines the member into PrivateObject’s constructor.»

El método es publico, así que ese no es el problema. La cosa va más por el problema de que el constructor que el objeto espera es diferente al constructor (vacio) que se le ha entregado. La firma del constructor original es:

    internal SPLink (SPWeb web, char cStatus, string sUrl, string sUrlParameter, Guid gWebId, Guid gFieldId)

así que si quiero agregar un constructor a mi Stub con esta firma, tengo que tener un objeto del tipo SPWeb. Como no puedo usar los objetos originales de SharePoint (los estamos falsificando, se acuerdan?), tengo que tener otro Stub para el SPWeb… y aquí se me fue la luz… o mejor dicho, la luz de la mañana apareció otra vez, y se me quitaron las ganas de continuar.

Conclusión: El camino del aventurero… funciona o no funciona? Ni idea, pero crear Stubs para las mil y pico de clases de SharePoint es trabajo de gigantes. Escribir un programita que mire con reflexión al ensamblado y me genere los Stubs automáticamente? Brillante idea (o mejor dicho, que haga algo parecido a NStub, pero más completo y con menos basura).

4 – Algo mas para intentar?:

– Crear Interfaces de las clases de SharePoint e intentar crear Mocks sobre las Interfaces? (algo así como el camino inverso: normalmente creas la Interface primero y luego las clases con la lógica, no al revés)

– Abandonar la idea? (hasta ahora he encontrado a dos personas en Internet que DICEN que han hecho Unit Tests para SharePoint, pero ninguna de las dos va mas allá de decir que lo han hecho, sin mostrar ni una letra de código)

– Irme a dormir? Buena idea…

Gustavo – http://www.gavd.net/servers/
Escriba un Comentario que me haga reir…

 

Alguien ha intentado usar Mocks para pruebas unitarias («Unit Test») con SharePoint?

A ver si nos entendemos. Supongo que Unit Test no es desconocido… dicho en palabras sencillas, es la forma que nosotros, pobres desarrolladores de software, tenemos para asegurarnos a nosotros mismos (pobres ilusos) y al mundo exterior (a nuestros clientes, para que nos paguen más dinero) que no estamos metiendo las patas de una forma vergonzosa. Unit Test tienen varias ventajas: acallar nuestros remordimientos pues no entregamos software sin ser probado apropiadamente, asegurarnos que nada se ha roto cuando cambiamos la lógica interna del software, garantizando que todo seguirá funcionando más o menos bien, tal como ocurría antes de hacer el cambio, poder ejecutar las pruebas automáticamente después de cada compilación (TFS de Microsoft, NAnt), etc., etc., etc.

Hay un montón de herramientas para hacer Unit Test regadas por Internet (MbUnit, NUnit, csUnit, TestDriven.net) e, inclusive, las tenemos incluidas en nuestra herramienta de programación favorita (en la versión Team Foundation Server Developer de Visual Studio 2005/2008, por la que hay que pagar bastante dinero para hacer lo que se puede encontrar gratis en Internet). Y un montón de teoría y teoréticos que nos intentan convencer que hacer Unit Test es lo mas importante en desarrollo de software después del estamento «if». Todo muy interesante y muy importante, pero con un solo problema: todo el software de ayuda y todas las teorías al respecto están hechas para trabajar con clases que funcionan por sí mismas:

Nota: las imágenes me las he robado del sitio de TypeMock.NET sin permiso de los autores.

La imagen muestra una clase nuestra («Production Class») que es «testeada» por medio de otra clase («Unit Test»). Desafortunadamente, la realidad es diferente, y sobre todo la realidad cuando estás trabajando con SharePoint (o con cualquier otro servidor «externo»):

En este caso, los datos que el Unit Test recibe son basados en sistemas «externos» (Data Bases, SharePoint, etc), que requieren configuración, y que, a su vez, dependen de otros sistemas externos (SharePoint depende de SQL, por ejemplo). Esto produce tres problemas para el Unit Test:

1 – Repetitividad: el sistema externo tiene que mantenerse con los mismos datos, de tal forma que los datos que el Unit Test espera («Expected values») para comparar con los datos calculados («Actual values») sean consistentes a lo largo del tiempo: si quieres ejecutar tus Pruebas Unitarias dentro de un año, tienes que garantizar que SharePoint tenga dentro de un año los mismos datos.

2 – Uso en grupo: Es normal que cuando estas desarrollando con SharePoint, cada desarrollador tenga su propia copia local de SharePoint (y, con frecuencia, de SQL), por eso de que los ensamblados de SharePoint no se pueden usar fuera del servidor, por eso de que si haciendo cosas raras te cargas a SharePoint no quieres detener el trabajo de todo el mundo, y por eso de que Microsoft nunca ha podido darnos una depuración remota que funcione. Para garantizar que los Unit Test (que son iguales para todos los desarrolladores) produzcan los mismos resultados, hay que garantizar que todas las copias locales de SharePoint sean idénticas

3 – hmmmm… el tercer punto… tenía un tercer punto, pero se me olvido… será por eso de que las células grises se agotan a pasos agigantados…

En cualquier caso, la respuesta para el problema es un «Mock»: hacerle creer a tus clases que están recibiendo la información de una fuente «exterior», cuando en realidad están recibiéndola desde otra clase «falsa» que has creado tu mismo:

Ideal: puedes garantizar que los datos a consultar siempre sean iguales en el tiempo y para todos los desarrolladores!

Hay varias herramientas (gratis y comerciales) para crear Mocks (Rhino Mocks, TypeMock.Net, EasyMock.NET, NMock, NMock2, entre otras) unas mejores que otras, unas más fáciles de usar que otras, todas con el mismo problema: es prácticamente imposible utilizarlas para «simular» a SharePoint. Veamos:

Una clase con un método (bastante idiota) que nos puede servir de ejemplo:

     public string GetCurrentUserName(HttpContext myContext)
     {
         SPWeb myWeb = SPControl.GetContextWeb(myContext);
         SPUser myUser = myWeb.CurrentUser;
         return myUser.LoginName;
     }

El método recibe el HttpContext de una WebPart, por ejemplo, y retorna el nombre del usuario actual. Ahora el método de Prueba Unitaria, tal como es generado por Visual Studio 2005:

     [DeploymentItem(«TestConsoleApplication1.exe»)]
     [TestMethod()]
     public void GetCurrentUserNameTest()
     {
         object target = TestProject1.TestConsoleApplication1_Class1Accessor.CreatePrivate();

         TestProject1.TestConsoleApplication1_Class1Accessor accessor = new TestProject1.TestConsoleApplication1_Class1Accessor(target);

         HttpContext myContext = null; // TODO: Inicializar en un valor adecuado

         string expected = null;
         string actual;

         actual = accessor.GetCurrentUserName(myContext);

         Assert.AreEqual(expected, actual, «TestConsoleApplication1.Class1.GetCurrentUserName no devolvió el valor esperado.»);
         Assert.Inconclusive(«Verifique la exactitud de este método de prueba.»);
     }

El problema es visible inmediatamente: el objeto «myContext» tiene que ser inicializado para poder utilizar el método; este es el trabajo que tiene que hacer un Mock: crear un objeto «falso» que tenga el mismo contenido del objeto «verdadero», pero sin tener que utilizar a SharePoint. Para aquellos masoquistas interesados en saber cómo se puede programar este tipo de Mocks, hay un ejemplo en internet que utiliza algo así como 300 líneas de código para mockear un HttpContext («Mocking HttpContext using TypeMock.Net«).

Todo el rollo que estoy escribiendo se refiere precisamente a este problema: si para escribir un Unit Test (8 líneas de código), tengo que agregar otras 300 solamente para falsificar un HttpContext, me voy a pasar 95% del (escaso) tiempo que tengo disponible para crear código en crear clases falsas… sin decir nada de las otras mil y pico clases de SharePoint que también habría que mockear…

Como decía al principio, para un pobre pica-código como yo, que no tiene mucha idea sobre el trabajo que hacen los señores (y damas) mayores que se ocupan de hacer pruebas de software, y que solamente quiere hacer un Unit Test sencillito para SharePoint, esto es demasiado trabajo. No sería posible que alguien nos produjera una librería de Mocks para SharePoint y un FrameWork para utilizarla, compilada y lista para ser usada (aunque la tengamos que comprar), de tal forma que podamos hacer nuestro trabajo (programar y probar SharePoint) de una forma fácil y rápida?

Se aceptan sugerencias…

Gustavo – http://www.gavd.net/servers/
Escriba un Comentario que me haga reir…

 

Lo único que no se puede decir sobre Microsoft es que nos aburrimos trabajando con sus productos.

En el marco del comienzo de un nuevo proyecto en la compañía para la que trabajo, en estos últimos días he estado instalando y jugando un poquito con el Enterprise Project Server (EPM, oficialmente llamado Microsoft Office Project Server) 2007 de Microsoft. Hace algunos años, por otro proyecto en el que estábamos integrando CRM, SharePoint, BizTalk y EPM 2003, me pusieron en el problema de «conversar» programáticamente con la antigua versión de EPM (por eso de que todos los compañeros en el proyecto estaban metidos en líos innumerables con sus propios servidores, y como yo había solucionado más o menos los problemas míos con SharePoint, me colgaron el san Benito de hacer la parte de EPM).

EPM 2003 es un verdadero drama. Programado en asp (si, en asp, no en aspx, es decir, en el lenguaje que usaban los dinosaurios para programar sus sitios de Internet), con el habían tratado de hacer algo parecido a capas de programación por objetos que solamente entendía el que lo programó. Y sin un Modelo de Objetos, sino con un número de Web Services, totalmente incapaces de trabajar con todas las posibilidades del sistema, por lo que al final terminabas sacando la información directamente desde la Base de Datos, que, como de costumbre, no estaba documentada.

Así que cuando me dijeron que tenía que empezar de nuevo con EPM, puse la cara más fea que pude. Pero como donde manda capitán no manda marinero, me tocó decir muy respetuosamente: «si señor» y empezar a trabajar sin fruncir el seño. Pero la sorpresa ha sido mayor, mayúscula, inesperada… EPM 2007 funciona completamente dentro de SharePoint, o, mejor dicho, EPM ES SharePoint. El Enterprise Project Manager Server 2007 no es más un servidor autónomo, sino una aplicación que ejecuta utilizando toda la infraestructura de SharePoint (autorización, maquina de Flujos de Trabajo, interface web, manejadores de eventos), y que utiliza un numero de Bases de Datos propias para guardar sus datos. Después de instalarlo (sin ningún trabajo: tres o cuatro clics y todo queda arreglado), en la Administración Central de SharePoint hay una nueva entrada desde donde se puede configurar el servidor, y luego de asignarle una Colección de Sitios propia (dentro de una Aplicación Web existente o una nueva), toda la configuración se puede encontrar dentro del sitio que EPM crea en WSS (usando su propia plantilla, instalada por defecto).

De la misma forma, un usuario puede utilizar la interface de SharePoint para usar su EPM personal (registro de tiempo, reportes, proyectos, etc). Esto abre posibilidades infinitas de personalización: como es un sitio de SharePoint, se pueden usar páginas maestras y hojas de estilo propias, utilizar alguna de las 25 WebPartes instaladas por defecto por EPM, o crear otras para hacer trabajo especializado, en fin, aplicar toda la caja de trucos de que disponemos en SharePoint. La programabilidad también ha sido mejorada radicalmente, y dispone ahora de 300 métodos públicos (en lugar de los 67 que tenía la versión 2003) que utilizan objetos (typed)DataSet, por lo que el IntelliSense de Visual Studio los reconoce inmediatamente para facilitar la programación (en lugar de engorroso XML como en los WebServices del 2003).

En resumen, ha sido amor a primera vista. Aunque, como todo amor a primera vista, después de la primera cita viene la primera desilusión: hay una cosa que no se puede hacer por medio de la web interface: crear un nuevo proyecto… incomprensible, pero así funciona Microsoft. El objetivo del Enterprise Project Manager, como su nombre lo dice, es manejar proyectos; y para manejar proyectos, primero tienes que crearlos. Y para crear proyectos, tienes que usar la versión cliente, el Project Professional 2007, para el que tienes que pagar licencias separadas… incomprensible, pero supongo que el primer trabajo de personalización de EPM será una WebPart para crear proyectos.

En fin, lo dicho, Microsoft no deja de sorprendernos por el trabajo brillante que hace a veces, y que deja de hacer otras veces.

PS: Como tema para filosofar, la misma estrategia de utilizar a SharePoint como servidor de base se puede usar con muchos otros productos de Microsoft. Por ejemplo, CRM no es precisamente el servidor más amistoso para programar, y cambiar su interface es lo más cercano a imposible (aunque estoy muy lejos de ser un conocedor de CRM): un candidato para meterlo como una aplicación que funcione dentro de SharePoint? Fíjense que ya nos tragamos a dos servidores: el viejo CMS (Content Management Server) y el viejo EPM (para no hablar del Class Server, que ahora es el SLK, SharePoint Learning Kit), así que cual es el siguiente? Axapta? Navision? Toda la suite de Dynamics? Tenemos para divertirnos un buen rato con SharePoint…

Gustavo – http://www.gavd.net/servers/
Escriba un Comentario que me haga reir…

 

Después de un par de semanas de vivir sin computador, al final la adicción a este cacharro ha ganado, y he vuelto con el rabo entre las patas a tocar con cariño su teclado, mover sutilmente el ratoncito, navegar por sitios virtuales desconocidos y, sobre todo, escribir código…

Entre las montañas de E-mails acumulados, noticias no leídas y avisos no revisados, he estado leyendo los nuevos Artículos de Conocimiento Básico (como se traduce Knowledge Base?) de Microsoft sobre SharePoint, y me he encontrado el articulo numero 938499 de Julio 10/2007 que dice (traducción libre al espanglish hecha por Gustavo):

API para almacenamiento externo disponible para Windows SharePoint Services 3.0

Un API para el almacenamiento externo está disponible para WSS 3.0. El almacenamiento externo permite guardar documentos o archivos en un dispositivo externo de almacenamiento diferente a SQL Server. Este API permite actualizar sitios de WSS 3.0 para utilizar los dispositivos externos de almacenaje.

Para utilizar el API, es necesario instalar el hotfix 937901. Para más información sobre el hotfix, vaya a la su página descriptiva

Y cuando vas a la página, encuentras todo lo que el hotfix hace, menos información sobre un almacenamiento externo.

La cuestión es de que se trata el asunto? La primera versión de SharePoint (cuando todavía se llamaba «Site Server», a finales del siglo pasado) se podía instalar con SQL o con Oracle… es a eso a lo que se refieren? O es que es posible guardar documentos en otro tipo de repositorio directamente (aunque esto ya es posible de hacer con el API normal, simplemente conviertes el documento en un stream que puedes guardar en un archivo, mandarlo a una Base de Datos, hacer lo que quieras con ella).

Ya sabemos que los dioses en Redmond hacen las cosas sin que sea necesario contarle a los pobres mortales porque, pero sería una señal de benevolencia de ellos si nos dieran algo de información sobre las clases a usar… pedirles documentación completa sería demasiado atrevimiento, pues ellos ya han dictado que tenemos que tragarnos el SDK (con todos sus bugs e inconsecuencias) tal como es…

En cualquier caso, ahora sabemos que hay (en alguna parte) un API que podemos utilizar para hacer algo (que no sabes qué), y que la información respectiva esta en un sitio en Internet (en donde no hay información al respecto)… Muchas gracias…

Gustavo – http://www.gavd.net/servers/
Escriba un Comentario que me haga reir…

Como en el caso de «Virtual Earth».

Hace un par de años se desato una más de las muchas guerras entre Google y Microsoft cuando Google comenzó con «Google Maps» (http://maps.google.com/) y en muy poco tiempo Microsoft creó «Virtual Earth» (http://dev.live.com/virtualearth/) como contrapartida. Los dos hacen más o menos lo mismo, mostrar mapas en pantalla. El uno hace algunas cosas mejor o más rápidamente que el otro, pero en realidad, los dos son comparables. La calidad del servicio depende completamente de la calidad de los mapas que utilizan, y la calidad de los mapas de Google es realmente fantástica de algunos sitios en Norte América, pero Microsoft tiene una mejor cobertura de Europa; y Latinoamérica? En realidad a ninguno de los dos le importa lo que pase por esos lados, así que la calidad es igualmente miserable…

Los dos servicios pueden ser utilizados desde programación propia, con una diferencia radical: si quiere utilizar Google Maps tiene que pedir una llave y registrar el sitio en donde la va a utilizar, mientras que el servicio de Microsoft puede ser usado anónimamente y sin llaves de ningún tipo. Ambos son servicios gratuitos (por el momento), aunque si quiere utilizar los mapas de alta resolución de Google tiene que pagar por el servicio.

Y la otra diferencia es la información. Ambos sistemas disponen de un SDK, pero el de Microsoft es realmente excelente (http://dev.live.com/virtualearth/sdk/): un SDK Interactivo, que es un ejemplo de cómo se debe presentar información para hacerla comprensible y de aplicación rápida. A veces Microsoft hace las cosas bien…

Integrar Virtual Earth con SharePoint es cuestión de un par de renglones de código en una de las WebParts por defecto del Portal («Elemento Web Editor de Contenido»). En http://www.gavd.net/servers/sharepointv3/spsv3_item.aspx?top=3&itm=496 puede ver un ejemplo, y el código necesario para reproducir el mismo efecto, y este es solamente el principio, pues las posibilidades que ofrece el sistema son numerosas (encontrar la ruta a seguir entre dos sitios, por ejemplo).

Lo único que Google Maps tiene extra (y que no tiene Virtual Earth), son los «Google Mappets» (http://www.google.com/apis/maps/), una nueva característica que permite crear pequeñas aplicaciones dentro de los mapas. Por supuesto que Virtual Earth dentro de poco también tendrá algo comparable…

Y en cuando al SDK, a ver si alguna vez el grupo de desarrollo de SharePoint le da una mirada al SDK de Virutal Earth, y lo toma como ejemplo para crear finalmente algo que podamos utilizar, y no la miseria de SDK que tenemos que usar ahora, por eso de que Microsoft no siempre hace las cosas bien…

Gustavo – http://www.gavd.net/servers/
Escriba un Comentario que me haga reir…

Esta semana los desarrolladores de nuestra maquina de búsqueda favorita nos han soltado otra sorpresa: «Google Gears».

Gears (http://code.google.com/apis/gears/?utm_campaign=en&utm_source=en-ha-ww-google&utm_medium=ha&utm_term=google%20gears, o en el articulo de El Bruno, por estos mismos lados: http://geeks.ms/blogs/elbruno/archive/2007/05/31/google-gears-a-good-choice.aspx) es, dicho de una manera sencilla, algo de software que se puede utilizar para guardar una copia local de sitios Web, de tal forma que se pueda ver y utilizar aunque no se tenga una conexión con Internet o la Intranet. El asunto está en Beta, y como todo el software de Google, permanecerá en Beta por los próximos tres siglos.

Google Gears es bastante sencillo: hay que instalar algo de software extra, que consta de un par de Add-Ins (con JavaScripst) para Microsoft Internet Explorer y para Firefox, y una Base de Datos (una copia de la excelente SQLite, http://www.sqlite.org/, que desde hace años han estado demostrando que una Base de Datos no tiene por qué ser costosa [Microsoft SQL, Oracle, aunque ambas tengas versiones gratuitas], complicada [Oracle] o con pretensiones de ser mucho sin ser nada especial [MySql]). Gears utiliza un API bastante sencillo que se puede utilizar para programar que una aplicación Web cree una copia local (en la Base de Datos) de su contenido. En el sitio de Google Gears pueden encontrar todo la información necesaria sobre el API, y ver cómo funciona por medio de un par de ejemplos (es necesario instalar primero el software en el computador). La arquitectura tampoco es complicada (http://code.google.com/apis/gears/architecture.html), y, la verdad sea dicha, los ejemplos funcionan sin grandes problemas, a pesar de ser un Beta bastante prematuro.

SharePoint dispone desde hace años de una especie de versión «desconectada», que se llama Groove y que en principio se puede utilizar para crear copias locales de Librerías y Listas. Pero, ya que estamos hablando de que la verdad sea dicha, Groove nunca ha sido un producto utilizable (http://geeks.ms/blogs/gvelez/archive/2007/02/18/que-tan-groovy-is-groove.aspx) por la sencilla razón de que es engorroso de instalar, poco amistoso para usar y demasiado caro para ser interesante. Y con las nuevas posibilidades para exportar documentos hacia Outlook directamente desde SharePoint 2007, mucho del atractivo de Groove como «SharePoint Off-Line» se ha desvanecido.

Y por eso me estoy preguntando si habrá una manera de usar Google Gears como un sustituto viable de Groove… a primera vista tiene un defecto, y es que no puede crear copias locales de contenido para ser bajado, como documentos, por ejemplo. Por el resto, tengo la idea de que crear una WebPart para utilizar Gears no sería un trabajo de más de un par de horas. Y, cuando Gears sea un poco más maduro y ofrezca algo más de funcionalidad, no me sorprendería que Google le esté poniendo la zancadilla de nuevo a Microsoft…

Gustavo – http://www.gavd.net/servers/
Escriba un Comentario que me haga reir…

Se puede usar CardSpace y SharePoint? Sí, porque no. Alguien lo ha hecho? No que yo sepa. Me parece improbable que se pueda integrar si se usa AD como medio de autenticación en SharePoint, pero como en MOSS ahora podemos usar otros proveedores, como Windows Forms, me parece que no sea ni siquiera difícil… aunque mi ignorancia es más grande que mi falta de conocimientos…

CardSpace es otra de esas cosas nuevas que Microsoft nos envía para que nos divirtamos (a ratos) y nos desesperemos (en los otros ratos). Más conocido hace algún tiempo como InfoCards, es más o menos la respuesta a una de las más grandes metidas de patas de Microsoft: Passport. Todo empezó, como los buenos cuentos, tratando de solucionar el problema de que cada persona tenia (tiene) para mantener las cientos de claves necesarias para hacer de todo, desde abrir la puerta del baño hasta visitar un sitio web, pasando por el código del banco, la alarma de la casa, encender el computador, bueno, hasta hay por ahí un refrigerador con código anti-glotones para abrir la puerta. Y la idea era: un sitio central en donde estén todas las claves guardadas, y que sea accesible con una sola clave. Brillante. El único problema es que el sitio central era (es) un servidor de Microsoft, la compañía menos confiada en el mundo…

Por supuesto Passport fue (y es) un fiasco de aquí al otro lado, aunque todavía se ve por ahí (han intentado postear algo en los Foros de Microsoft o usar HotMail? Pues necesita usar Passport). Después de 1,35 milisegundos del anuncio de Microsoft en el 2001, algunos (un montón) de sus enemigos (aun mas) se unieron en la «Liberty Alliance» (IBM, Oracle, y una lista interminable) para crear un mejor sistema de autenticación, que, aunque me llamen pesimista, tampoco fue el éxito que los fundadores esperaban. O, puesto con otras palabras, Passport por lo menos de vez en cuando se ve por aquí y por allá, pero alguien ha visto algo asegurado por la «Liberty Alliance» alguna vez? No yo, por lo menos.

Y al fin caemos en el CardSpace, integrado en el DotNet 3.0 y Vista. La idea es la misma, la realización casi igual, con la diferencia que el sitio central para guardar las claves ahora puede ser distribuido entre varios «proveedores», y, lo más importante, proveedores que el usuario puede escoger. La implementación en Vista es bastante elegante: si va a un sitio que acepta CardSpace, Windows lo detecta y muestra una pantalla desde donde se puede escoger la tarjeta a utilizar, o crear una nueva (si tiene un minuto, vea esta demostración que es bastante simpática, y dura un minuto http://channel9.msdn.com/Showpost.aspx?postid=306082).

Y de regreso a SharePoint, es CardSpace un sistema interesante para MOOS? Mi primera impresión es no, no lo es. Simplemente porque SharePoint usado en intranets utiliza siempre (o casi siempre) un sistema empresarial de autenticación (Directorio Activo, Forms Autentication con SQL detrás), que es utilizado para otras muchas cosas al mismo tiempo (piense en Exchange, por ejemplo), así que los usuarios ya tienen un sistema único de identificación. Y además con las posibilidades de Single-Sign On de SharePoint, que permite convertirlo en un punto de entrada y de autenticación para otras aplicaciones, el valor de CardSpace se ve considerablemente reducido. Y para SharePoint como extranet, simplemente no hay necesidad de identificación. Así que yo no le veo muchas perspectivas al asunto, aunque me puedo equivocar…

Gustavo – http://www.gavd.net/servers/
Escriba un Comentario que me haga reir…

Los últimos días no se oye hablar más que de Microsoft Silverlight. Si no me cree, mire el numero de colegas en este sitio que ya han escrito algo al respecto. Si no tiene muchas ganas de buscar, en dos palabras se podría decir que Silverlight es una especie de animación a la Flash o de Ajax fácil de programar. La cuestión que me ocupa en este momento es en qué forma afecta Silverlight a SharePoint.

Desde que se empezó a hablar sobre Ajax, se ha estado experimentando para hacerlo trabajar con SharePoint (en ese entonces la versión 2003). Pero inclusive con MOSS, la implementación es más que difícil, a pesar de que existe un «Tool Kit» (http://www.codeplex.com/sharepointajax) para crear WebParts utilizando Ajax. Microsoft también ha asegurado que con el primer service pack de MOSS, hacia finales del año, algo de integración con Ajax será garantizada. Pero el hecho continúa: a pesar de que todos queremos usar menús más dinámicos en SharePoint, hacer funcionar a Ajax dentro de MOSS significa trabajar horas extras.

Por el otro lado, Flash, aunque es una manera de crear interfaces muy atractivas, tiene enormes problemas para hacerlo interactuar con «el mundo exterior», fuera de que utiliza un lenguaje de programación muy (demasiado) propio. La integración con SharePoint es relativamente fácil, pero por el problema de interacción con datos externos, en realidad nunca ha sido utilizado como una alternativa para la interface de SharePoint.

Por lo que regresamos a la Luz Plateada. Es completamente programable con CSharp (o, si no hay más remedio, con Visual Basic… ups, perdón, estoy creándome enemigos a pasos agigantados), y junto con la nueva moda del XAML y WPF, la separación entre diseño grafico y programación está garantizada. No tiene problemas para «conversar» con el mundo exterior, pues todo funciona bajo la lengua franca de DotNet. Así que, a primera vista, es un medio ideal para SharePoint. Quien se atreverá a hacer menús como en http://silverlight.net/mscom/? (use el menú de la esquina derecha superior), o librerías que utilicen documentos (o videos) como en http://msdn2.microsoft.com/en-us/default.aspx? (tiene que instalar el add-in de Silverlight para poder usar estos sitios).

El problema de Ajax es que es un matrimonio de conveniencia entre obsoleto DHTML, pesado JavaScript y Navegadores malfuncionantes. Lo malo de Flash es que habla su propio idioma, y ese idioma es mudo y sordo. Talvez Silverlight nos muestre la luz…

Gustavo – http://www.gavd.net/servers/
Escriba un Comentario que me haga reir…

Un pajarito me ha traído un regalo la semana pasada: el nuevo SDK de SharePoint, que todavía no está disponible para los simples mortales (las malas lenguas dicen que aparecerá en junio). Así que, fuera de haberle dado una mirada superficial, esta mañana, para solucionar el primer problema de la semana, he sacado a relucir mi nuevo SDK para ver qué me aconseja… Mejor que no lo hubiera hecho…

Nota: para los que no lo han visto, en alguna oportunidad me encontré 8 errores en 15 líneas de código en un ejemplo del SDK)

Veamos: necesito encontrar el valor de un campo de la Base de Datos de Perfiles de MOSS, y quiero usar el WebService «UserProfileService» por aquello de que usar un impersonador nos lo ha hecho tan difícil en el nuevo SharePoint (gracias señores de Microsoft, mientras más difícil me lo hagan, más puedo pedir de aumento de sueldo). El SDK recomienda (véalo en la versión OnLine, si no me cree http://msdn2.microsoft.com/en-us/library/ms550407.aspx):

UserProfileWebService.localhost.PropertyData[] properties = myService.GetUserProfileByName(«domainname\username»);
for (int i = 0; i < properties.Length; i++)
{
    Console.WriteLine(properties[ i ].Name);
    Console.WriteLine(properties[ i ].Value);
}

En donde «UserProfileWebService» es la instancia local del WebService «UserProfileService».

Primero que todo, el WebService no tiene nada que se parezca a «localhost», pero si tiene un «PropertyData», asi que hay algo que sobra…

Luego, el «PropertyData[]» no posee una propiedad «Value»… Afortunadamente hay dos o tres programadores que hacen las cosas bien en Microsoft, y la Intellisense de Visual Studio me dice que la propiedad es «ValueS«, y no es una simple string, sino que es del tipo «ValueData[]».

En resumidas cuentas, el ejemplo debería ser:

UserProfileWebService.PropertyData[ ] properties = myService.GetUserProfileByName(«domainname\username»);
for (int i = 0; i < properties.Length; i++)
{
    Console.WriteLine(properties[ i ].Name);

    UserProfileWebService.ValueData[ ] myValues = properties[ i ].Values;
    for (int a = 0; a < myValues.Length; a++)
    {
        Console.WriteLine(» – » + myValues[ a ].Value);
    }
}

Y aquí se te ocurre la pregunta de paraqué usar un array de valores, si cada propiedad solamente tiene un valor?

Ya se va convirtiendo en costumbre: buscas algo en el SDK de SharePoint, miras con desconfianza, intentas reproducir el ejemplo, no funciona (por supuesto), lo tiras y lo intentas por tu cuenta… hasta que un día bote todo el SDK a un pozo sin fondo, solamente para disfrutar del gozo infinito proporcionado por la liberación de la esclavitud sdkiana (que exagerado…)

Gustavo – http://www.gavd.net/servers/
Escriba un Comentario que me haga reir…