Project Server y SharePoint, un buen matrimonio, pero uno de conveniencia

Después de terminar hace algunos días un proyecto para un cliente en donde estábamos utilizando Project Server 2007 junto con WSS 3.0 (vea el primer artículo al respecto, “Continuando con hacer las cosas bien” http://geeks.ms/blogs/gvelez/archive/2007/07/29/continuando-con-hacer-las-cosas-bien.aspx), las agradables sorpresas que comentaba hace dos meses se han enfriado un poco, dando paso a la dura realidad de la vida cotidiana.

Como primera medida, con la introducción de Project Server 2007 como un Add-In para SharePoint, Microsoft está siguiendo un camino apasionante: SharePoint provee la base de autorización y autenticación y toda la infraestructura para manejo y seguridad de información, y Project Server agrega una parte especializada no presente en WSS por defecto. Es interesante ver la evolución de SharePoint en este aspecto: en el principio de los tiempos existía un producto “madre”, llamado Search Server, por alla en la mitad de los años 90 del pasado siglo. A ese servidor se le podían agregar dos Add-Ins: Site Server, el predecesor de SharePoint, y Commerce Server. Luego los papeles se invirtieron, Site Server se convirtió en SharePoint, Commerce Server siguió camino por su lado, y la maquina de búsqueda se convirtió en algo intrínseco de SharePoint. Doce años después, vemos que la maquina de búsqueda empieza a separarse de nuevo (SharePoint 2007 tiene una versión de solamente búsqueda, y el motor de búsqueda trabaja relativamente aislado de SharePoint), y que nuevos productos empiezan a ser agregados al nuevo producto “madre”, como Project Server, el antiguo Content Management Server (CMS) y el antiguo Class Server (conocido ahora como el SLK, SharePoint Learning Kit, puede ver mas información al respecto en http://www.gavd.net/servers/sharepointv3/spsv3_item.aspx?top=0&itm=524 y http://www.gavd.net/servers/sharepointv3/spsv3_item.aspx?top=0&itm=525)… El circulo se esta cerrando? Ni idea, pero yo candidatearía algunos otros servidores para ser convertidos para trabajar como satélites de SharePoint: Commerce Server, por supuesto, que tiene cada vez mas similitudes con WSS, algo de los componentes de Dynamics (CRM?)…

La instalación y configuración de Project Server sigue el mismo camino que todos los productos de Microsoft en general: inclusive mi tia la monjita puede instalar un servidor en cuestión de minutos. Instalacion de productos es probablemente una de las cosas que Microsoft esta haciendo bien desde hace años. La configuración es minima, y el servidor funciona directo out-the-box.

La primera critica aparece luego de empezar a utilizar el producto. En realidad, Project Server esta divido en dos partes: una hecha como aplicación Web, que funciona utilizando la interface de WSS, y otra hecha como aplicación Windows. La lógica detrás del asunto es que trabajos administrativos, como la creación de nuevos proyectos, acoplar proyectos con recursos, definir recursos, etc., deben ser hechos con la aplicación Windows (Microsoft Office Project Professional), y el trabajo cotidiano de registro de horas, presentación de reportes, etc., puede ser hecho con la interface Web (sin necesidad de instalar software localmente, utilizable por todos los usuarios que tienen acceso a SharePoint). La pregunta que salta inmediatamente es porque no lo hicieron todo (administración y uso) como aplicación Web, en lugar de hacer un seudo-monstruo con dos cabezas. Si se es mal pensado, se puede decir que así venden licencias del Project Professional, que no es nada barato…

El siguiente punto es información: Project Server no es un producto muy utilizado, pero eso no es disculpa para no publicar información al respecto. Los manuales de instalación son muy completos, pero ahí para el asunto. Información sobre programación simplemente no existe, y la poca que hay en este momento es la que un colega mío ha empezado a publicar en su blog. Y si nos sirve de consuelo a los que trabajamos con SharePoint, el SDK de Project Server es aun peor que el de SharePoint… vaya un consuelo…

Finalmente, el último punto crítico es que Microsoft no creó un Modelo de Objetos propiamente dicho para trabajar programáticamente con Project Server. En su lugar continuaron con la idea de crear WebServices. Por supuesto, los WebServices de la versión 2007 son muchos más y mucho más poderosos que los de la versión 2003, y ahora se puede utilizar la Intelisence de Visual Studio para programar con ellos, pero sigue siendo un “Modelo de Objetos de segundo rango”. Una de nuestras mayores preocupaciones es que el sistema no rendirá bien bajo grandes cargas de usuarios, pues WebServices son mucho más lentos y menos inteligentes que un buen Modelo de Objetos, pero nadie sabe que pasara cuando miles de usuarios empiecen a usar el sistema concurrentemente. Ni siquiera Microsoft tiene especificaciones al respecto.

En fin, para terminar con el rollo, el matrimonio entre SharePoint y Project Server es efectivo y funciona bien, pero es un matrimonio de conveniencia, sin que la palabra “amor” aparezca por ninguna parte.

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

Es SharePoint una buena plataforma de desarrollo?

“NO” rotundo, según Jeffrey Palermo (Solution Architect MVP y veterano de la guerra en Irak).

Carlos Segura Sanz me comentó del artículo la última vez que hablamos. El artículo se llama “SharePoint is not a good development platfom” (hmmm… mi traducción no es mala, después de todo). Para que se eviten la lectura de todo el rollo, la razón que el amigo Jeffrey da es que SharePoint no es una buena plataforma de desarrollo porque SharePoint tiene que correr en un servidor, y no se puede usar en Windows XP o Vista.

Bueno, que se puede decir al respecto… el mundo de MVP’s es una representación del mundo real, y en el mundo real hay un montón de idiotas. Afortunadamente no todos los componentes del mundo real son idiotas, lo que se debe aplicar también al mundo de MVP’s. Por otro lado, un posting del tipo de nuestro amigo Jeffrey dice más sobre el autor mismo que sobre SharePoint.

Veamos: SharePoint ejecuta bajo un servidor, porque servidores son mucho más estables que desktops, porque están especialmente diseñadnos para ejecutar programas (“Servers”) que tienen que seguir funcionando bajo cualquier condición, porque son más seguros, y sobre todo y lo más importante, porque a Microsoft le dio la gana de hacerlo así. Y contra el último argumento no hay nada que decir. Si alguien me viene con que no le gusta el software que yo diseño, pues simplemente que no lo compre, y que no venga a sobarme la vida.

El razonamiento que nuestro amigo Jeffrey sigue es que para desarrollar con SharePoint necesitamos un servidor. Completamente falso, eso pasa cuando arquitectos se meten en el mundo de los machos (perdón, me estoy volviendo machista, quiero decir de las machas y los machos), e intenta hacer trabajo de hombres (huyyyy… otro comentario machista… las dos personas que leen este asunto van a dejar de hacerlo desde ahora mismo). Si se tiene instalado Visual Studio en Windows XP o Vista, para hacer desarrollo de SharePoint lo único necesario es copiar los dll’s en el computador local. Y, para acabar de terminar, aunque no se puede hacer depuración localmente, se puede hacer remotamente (http://www.gavd.net/servers/sharepoint/sps_item.aspx?top=cod&itm=312), cuando se instala el software desarrollado en el servidor.

Y aunque no fuera así, es válido decir que SharePoint no es una plataforma de desarrollo porque no se puede desarrollar en XP? Y todas las posibilidades que SharePoint presenta listas para ser usadas en desarrollo tenemos que perderlas? SharePoint es la aplicación más extensible de toda la plataforma de Microsoft, ningún otro servidor da la libertad de crear aplicaciones completas, que usan una infraestructura común, probada y requeteprobada. Tenemos que prescindir de esta plataforma tan rica porque no se podría (eventualmente) desarrollar en XP? Sería un desperdicio imperdonable… No es por nada que Steve Ballmer ha afirmado que “…SharePoint es la plataforma o Sistema Operativo definitivo para la capa intermedia (middle tier)” (http://geeks.ms/blogs/gvelez/archive/2007/03/26/sharepoint-como-sistema-operativo-os.aspx), y algo así no se consigue sin ser una muy buena plataforma de desarrollo.

Pero bueno, también es una pérdida de tiempo ponerse a comentar sobre un comentario de un veterano de la guerra en Irak. Al fin y al cabo, el solo hecho de estar orgulloso de algo así demuestra una falta crónica de buena alimentación en la infancia, lo que trae como consecuencia una gran escasez de células grises en la edad adulta…

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

Que tan capazmente maduro es SharePoint?

Ya lo sé, no es necesario que me lo repitan: el Modelo de Capacidad Madura (?) (Capability Maturity Model, CMM) no se puede aplicar a software, sino a procesos… pero como yo no soy un teórico de procesos ni cosas raras de esas, le quiero aplicar el CMM a SharePoint… Porque no?

A ver, empecemos por el principio. El Capability Maturity Model es una de esas cosas que algún manager se invento para hacernos trabajar a nosotros, los pobre programadores (pobres trabajadores en general), aun mas de lo que ya trabajamos. No, en realidad no se lo invento un manager sino la Fuerza Aérea de los Estados Unidos (tengo la tentación de decir que es peor, pero mejor no digo nada) como modelo de evaluación de compañías que creaban software por allá en los años 80 del siglo pasado. Por lo tanto es un modelo para saber que tan capaz es una compañía en la creación de software.

El modelo define cinco niveles de madurez:

1 – Inicial: las cosas se hacen, pero nadie tiene ni idea como, porque, cuando ni por quien. Mejor dicho, es el nivel de caos en el que la mayoría de nosotros, alguna vez, hemos creado software (a ver quién se atreve a tirar la primera piedra y decir que esto no es cierto)

2 – Repetible: las cosas se hacen, pero ya sabemos como lo hicimos la primera vez, y estamos en capacidad de meter las patas de nuevo y de la misma manera en el futuro.

3 – Definido: las cosas se hacen según un protocolo definido. Es decir, ya sabemos de antemano que va a salir mal, porqué y quien va a meter las patas, de tal forma que tengamos una disculpa bien pensada para cuando todo salga mal.

4 – Manejado: los managers tienen todo tipo de medidas para saber exactamente cuando se metieron las patas, porqué y por quien, de tal forma que podamos predecir exactamente cuando el asunto va a fracasar miserablemente.

5 – Optimalizado: las cosas se siguen haciendo, pero ya hemos perfeccionado a tal extremo el proceso de meter las patas, que estamos en capacidad de repetirlo consecuente y elegantemente, para cada proyecto que hagamos y a ojos cerrados. Perfección asegurada!

Nota: l(a)os que quieran leer la documentación oficial, la pueden encontrar en el sitio del Software Engineering Institute (http://www.sei.cmu.edu/cmmi/). Bueno, la verdad sea dicha, este es el sitio oficial del CMMI (Capability Maturity Model Integrated, la evolución del CMM, como todos muy bien sabemos).

Pero bueno, saliéndonos de la teoría, en qué nivel de madurez y capacidad se encuentra SharePoint en este momento? Como buena teoría, cada uno de nosotros tendrá su propia opinión al respecto. Así que aquí va la mía:

1 – Nivel Inicial: Ya lo superamos. La primera versión de SharePoint (cuando todavía no se llamaba así, sino Site Server, por allá en 1998) era simplemente una cosa caótica, lo que es comprensible pues fue un proyecto SkunkWork de un par de programadores en Microsoft.

2 – Nivel Repetible: También está superado. Con la versión 2001 de SharePoint se consiguió algo de repetitividad… WebPart fueron definidas por primera vez, lo mismo que un Modelo de Objetos primitivo. Todavía se veía algo del Nivel Inicial en la forma de guardar la información y en el uso abusado y abusivo de ASP (código interpretado), pero eso era porque el DotNet todavía no existía.

3 – Nivel Definido: Lo alcanzamos con SharePoint 2003, con toda seguridad. El Modelo de Objetos es maduro y caóticamente consistente. La manera, también caótica, de trabajar con la interface también está definida, y al que no le guste, que se busque otro programa… las ventajas de tenerlo todo definido!

4 – Nivel Manejado: Aquí se le acabo la cuerda a Microsoft. SharePoint 2007 no se pasó al Nivel Manejado, sigue en el Nivel Definido. Sabemos (más o menos) como SharePoint se comportará dentro de algunos parámetros “normales”, pero no sabemos qué pasa cuando se sobrepasan ciertos límites (que pasa mas allá de 50.000 colecciones de sitios o cuando se llega a los limites de AD, por ejemplo). Ya tenemos suficientes problemas buscando información sobre cómo funciona el Modelo de Objetos, así que ni siquiera queremos pensar cómo podemos escribir una WebPart para ser utilizada en un sitio que es usado a un nivel de 100 o 200 TPS (Transactions Per Second). Podemos instalar SharePoint de una forma fácil y rápida, pero cada vez nos encontramos con problemas de configuracion diferentes en sistemas teoricamente iguales. Cosas de ese tipo…

5 – Nivel Optimalizado: De pronto en nuestros sueños lo alcanzamos. O tal vez nuestros nietos lo verán realizado en SharePoint versión 2057. Hay algún producto de software que alcance este nivel? No que yo conozca. Todavía estamos escribiendo software de una manera artesanal, y por muy bien que lo hagamos, no pasamos de Nivel 3 del CMM…

De una u otra forma, el CMM no lo podemos aplicar a nosotros mismos, a través del nivel alcanzado por SharePoint. Así que no podemos echarle toda la culpa a Microsoft. Para que después no digan que no soy positivo en lo que escribo…

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

Cyclomatic Complexity en SharePoint

Como ya Carlos (http://geeks.ms/blogs/csegura/archive/2007/08/29/sharepoint-pruebas-unitarias-1.aspx) a tomado el token de las Pruebas Unitarias para SharePoint, y me ha liberado del asunto, me han quedado un par de minutos libres para dedicarme a cosas más divertidas…

Ayer, programando un poquito con SharePoint para no perder la costumbre (tratando de manejar WebParts programáticamente http://www.gavd.net/servers/sharepointv3/spsv3_item.aspx?top=3&itm=509), me tocó descompilar por milésima vez el ensamblado de WSS (por eso de que como Microsoft no nos quiere dar un SDK decente, tenemos que buscar la información que necesitamos en el código mismo), y me encontré la función “CreateWebPartsFromRowSetData”, que era precisamente lo que estaba buscando, si le creemos al nombre. Pero la verdad es que mirando el código era como si estuviera mirando llover pa’riba: no entendía ni media palabra. Por lo que se me ocurrió una idea malvada: cuál es la Complejidad Ciclomática de WSS? Alguien lo ha buscado alguna vez?

Los que saben que es Complejidad Ciclomática (Cyclomatic Complexity, CC), sáltense este parágrafo. A los que se les ha olvidado, les recuerdo que es una medida en software (una de las tantas) que indica que tan complejo es un método o una clase en un programa. El CC mide cuantas rutas diferentes se pueden caminar en una función. Por ejemplo, el método:


public int CCuno()
{
    int a = 0;
    int b = 1;

    return a + b;
}


tiene un solo camino a seguir, así que su CC es uno. La función:


public int CCDos()
{
    int a = 0;
    int b = 1;

    if(a == b)
        return a + b;
    else
        return a – b;
}


puede recorrer dos caminos (si a es igual a b, y si no lo es), así que su CC es dos. Sencillo, verdad?. Las cosas se complican si se usan estamentos con lógica interna (if(a == b && a > 1), si a es igual a b Y a es mayor que uno, CC es tres) o se utilizan operadores condicionales terciarios (“?” [el signo de interrogación] en C# o Java). Pero bueno, eso es teoría de construcción de software, y eso se lo dejamos a los teoréticos. Lo que nos interesa a nosotros, los pica-código, es lo que significa este numerito.

Es generalmente aceptado que un CC de 30 es más o menos un límite. Complejidad de código tiene consecuencias para la mantenibilidad (si el código es muy complejo, dentro de seis meses, el pobre desarrollador que tiene que darle mantenimiento va a querer cambiar de oficio), para el testeo (si la función es muy compleja, el código de pruebas lo es también) y el funcionamiento del asunto (si el código es muy complejo, es muy fácil meter las patas, y es muy difícil eliminar errores). Muchas empresas exigen que el código a utilizar no sobrepase cierto límite de CC; esto tiene ventajas y desventajas: un CC bajo significa en general que el código es razonablemente comprensible; pero, mirándolo desde el punto de vista del desarrollador, yo quiero que mi código sea juzgado por su calidad, y no por un numerito cualquiera. En fin, resumiendo:



























CC Complejidad Quien puede entender el codigo
1-4 my baja todo el mundo, inclusive Bill Gates
5-10 normal cualquier desarrollador
11-30 compleja un buen desarrollador
31-60 my compleja solamente Brian Kernighan y Dennis Ritchie
>60 incomprensible ni siquiera el pobre idiota que lo escribió

Pero estoy desvariando. Volviendo a SharePoint, cuando vi el CC de Microsoft.SharePoint.dll, me encontré con lo siguiente:


La función que estaba intentando seguir tiene un CC de solamente 107… y yo creyendo que la podía comprender…

Y hay funciones aun más complejas (CC = 127), y hay 108 funciones con un CC mayor de 30, algunas importantes como el SPListItemCollection (CC=34).

Pero bueno, también hay que poner las cosas un poquito en perspectiva: el Microsoft.SharePoint.dll tiene 26.379 métodos (a que Microsoft no los ha contado), así que 108 métodos con un CC mayor de 30 representan el 0,4% del trabajo total… como de costumbre, estoy haciendo una tormenta Ciclomática en un vaso de Complejidad…

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