blog counter
March 2007 - Artículos - SkunkWorks

March 2007 - Artículos

SharePoint como Sistema Operativo (OS)

Pequeño pero intrigante artículo que me encontré esta mañana en Internet: "SharePoint: The next big 'operating system' from Microsoft?" ...

Todo comenzó con una pregunta que alguien le hizo a Steve Ballmer, el CEO de Microsoft: "Con toda la propaganda que está recibiendo SharePoint los últimos tiempos, es correcto pensar en él como si fuera casi un Sistema Operativo?"

Y la respuesta de Ballmer: "SharePoint es la plataforma o Sistema Operativo definitivo para la capa intermedia (middle tier)" (traducción libre al español)...

SharePoint como plataforma de desarrollo ya la conocemos desde la versión 2001 (aunque nadie estuvo tan loco como para desarrollar algo para esa versión). Entre otras cosas, es con lo que nos ganamos el pancito de cada día muchos de nosotros: haciendo que cosas raras funcionen dentro de SharePoint. Si pensamos en Windows como una plataforma de desarrollo, que sirve como base para todo el software que creemos, entonces SharePoint es por definición un Sistema Operativo, y Ballmer tiene razón.

Pero si pensamos que SharePoint utiliza mucha de la infraestructura que Windows provee (piensen nada mas en todo el DotNet FrameWork), entonces no es un OS...

O, visto desde otra perspectiva, de pronto SharePoint es un Sistema Operativo que necesita otro Sistema Operativo para funcionar... Algo así como las muñecas de madera rusas, que caben una dentro de la otra, dentro de la otra, dentro de la otra.

En cualquier caso, es una idea intrigante pensar en SharePoint como un Sistema Operativo, y, con toda seguridad puede ayudar para entender algunos de sus conceptos: siempre me ha costado trabajo explicarle a personas que no saben nada de software, como es posible integrar aplicaciones en SharePoint. Utilizando el paradigma del Sistema Operativo, será mucho más fácil decirles: de tal forma que un programador crea un programa "Hola Mundo" en Windows, puede crear un "Adiós Mundo" dentro de SharePoint...

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

Publicado por Gustavo Velez con 7 comment(s)
Archivado en:

Demasiada información es desinformación, pero ninguna información es un desastre

La primera lección de Teoría de la Información, mi primer día en la Universidad a la primera hora de la mañana, uno de los profesores que alcanzaría un puesto distinguido en mi seleccionado grupo de profesores preferidos comenzó su clase diciendo: "Demasiada información es desinformación..."

En estas últimas semanas, trabajando en un implementación de MOSS con bastantes WebParts, Manejadores de Eventos y cosas de esas, me he acordado constantemente de él viendo el horrible trabajo que Microsoft ha hecho en la creación del nuevo SDK (Software Development Kit), tanto de WSS como de MOSS.

Se supone que un SDK es la biblia de un desarrollador: allí se encuentra no solamente información sobre QUE son las cosas, sino también COMO se usan, es decir una guía para convertirse en un buen ciudadano del mundo del software. Un buen SDK incluye toda la información que sea necesaria sobre los NameSpaces, Clases, Métodos, Propiedades, Eventos que componen el Modelo de Objetos, ejemplos de cómo utilizarlos, "buenas prácticas" para meter las de andar lo menos posible, en fin, después de un par de meses de estar trabajando con un SDK en la mano, acabas aprendiéndotelo de memoria, y lo puedes recitar de atrás para delante en los pocos momentos de descanso que te queden, si es que te queda alguno.

El SDK de SharePoint 2003 (WSS y SPS) no era conocido por la buena información que proporcionaba, pero se podía confiar en él, y en más de una ocasión saco a más de uno de problemas. El SDK de SharePoint 2007 se divide en dos partes:

- Información sobre cosas que son iguales a SharePoint 2003
- Información sobre cosas que son nuevas

En el primer caso, la información es exactamente igual a la del SDK 2003
En el segundo caso, no hay información (y si por casualidad hay algo, está llena de errores, http://geeks.ms/blogs/gvelez/archive/2007/01/29/cuantos-errores-se-pueden-cometer-en-15-l-neas-de-c-digo.aspx)

Un ejemplo entre miles y miles que se pueden citar: si quieres copiar el valor de un campo de la Base de Datos de Perfiles de un usuario a otro usuario, lo más indicado seria poder usar el método "CopyTo" de la clase "PropertyCollection" en el NameSpace "Microsoft.SharePoint.Portal.UserProfiles", o me equivoco? Pues bien, el SDK nos dice muy claramente (http://msdn2.microsoft.com/en-us/library/microsoft.sharepoint.portal.userprofiles.propertycollection.copyto.aspx) que el uso es:

public void CopyTo (
Array array,
int index
)

Y la explicación sobre los parámetros es:

Parameters
array
index

Simplemente brillante... muchas gracias por la información... si no entiende la explicación tan detallada, es porque su capacidad mental alcanza escasamente el nivel del de una cucaracha, o su formación profesional deja bastante que desear. Pero, además, dentro de la plétora a información que se nos ofrece, nos dicen muy claramente al principio que:

PropertyCollection.CopyTo Method --- Obsolete.

De nuevo, muchas gracias por la información... pero si no es mucha molestia, le podrían contar a esta cucaracha cual método se debe utilizar? De cual Clase? O es mucho pedir?

Volviendo a mi profesor, ahora que ya tengo la edad para mirarlo cara a cara y no de abajo hacia arriba, si me lo volviera a encontrar le diría: "sí señor, tiene mucha razón, pero ninguna información es un desastre!"

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

Publicado por Gustavo Velez con 3 comment(s)
Archivado en:

Al CAB, aunque lo vistan de Solution, CAB se queda

Uno de los grandes dramas de SharePoint 2003 era instalar código personalizado en otros servidores fuera de las maquinas de desarrollo. Las opciones estaban limitadas a dos: copiar todos los archivos a mano desde un servidor a otro, con todos los peligros que eso conlleva, o hacer un instalador especial (un programa que copie todo en el lugar correcto).

La primera opción en realidad no era una opción. Cuantas veces me ha pasado (y no solamente a mi) que le enviabas toda la retahíla da archivos al cliente, con instrucciones detalladas sobre que archivos en que directorios había que copiar, para luego recibir un teléfono de un cliente enojado porque el asunto no funcionaba (o es que solamente yo tengo clientes disléxicos, eso también puede ser). Luego de perder un montón de tiempo en ir personalmente a ver qué estaba sucediendo, revisar la instalación localmente en los servidores de producción y comprobar que, por supuesto, las cosas no habían sido copiadas correctamente, se venía el trabajo de explicarle muy cuidadosamente al susodicho cliente que simplemente tenía que regresar a la escuela elemental a que le enseñaran a leer de nuevo...

La segunda opción, aunque más segura, también costaba tiempo y esfuerzo... y ponerse a programar aplicaciones de Windows, algo que no se te ocurría hacer desde el tiempo de los dinosaurios...

Los chicos inteligentes de Microsoft se pusieron las pilas y crearon las "Solutions", una verdadera solución para el problema. Para que después vengan a decir que Microsoft no escucha los clamores de sus pobres usuarios. Si escuchan, sí que lo hacen, créanme, lo único es que son sordos selectivos, que solamente escuchan lo que les interesa, pero que escuchan, escuchan...

Una "Solución" de SharePoint no es más que un archivo comprimido (.wsp) con todos los archivos que quieres instalar metidos en él, y otro archivo "Manifest.xml" que le cuenta a SharePoint a donde tiene que ir a parar cada uno de ellos. Además de que todo va en un solo archivo, el administrador de SharePoint solamente tiene que ejecutar un comando en la herramienta de administración stsadm para instalarlo, y desde la pantalla de Administración Central de SharePoint puede activar la Solución, desactivarla, instalar otra igual con una versión diferente y controlar su uso, todo sin que tenga que copiar archivos independientes.

La Solución principalmente puede copiar archivos a sus sitios correctos (Características, WebParts, Recursos, Site Definitions, etc) e instalar dll's en el GAC o en un directorio Bin; es posible hacer otras cosas con ellas, como definir las pólizas de seguridad y el registro de controles seguros, pero esto es otra historia.

Volviendo al título, un archivo wsp no es más que un archivo cab con otra extensión. Si no me creen, búsquense algún archivo wsp en el directorio de SharePoint, cámbienle le extensión a cab, y verán que bonito esta por dentro (o sino, léanse el SDK, también está allí explicado). Archivos cab son muy simpáticos, pero no son divertidos para hacer. Desde el sitio de Microsoft se puede descargar el "Cab SDK", con información sobre como compilar archivos CAB, y un par de herramientas de comando para hacerlos. Pero si tienes que crear una Solución con bastantes archivos, que tienen que ir a parar a diferentes directorios de SharePoint, el comando se convierte en algo así como:

CABARC.EXE -p -P Projects\TestSolution\ n C:\Solution_Test.wsp C:\Projects\TestSolution\ISAPI\*.* C:\Projects\TestSolution\Manifest.xml C:\Projects\TestSolution\TestWebPart1.dll

(Y esto para solo tres archivos a comprimir). Así que, siguiendo el leitmotiv de "Un buen herrero hace sus propias herramientas", me he hecho un programa estupendo ("SharePoint Solution Builder", por eso de que en ingles suena más complicado) que me evita todo el trabajo de pensar (para evitar que se me gasten las pocas células grises que me quedan), y en donde solamente tengo que escoger los archivos, indicar a que directorio tienen que ir, contarle el sitio en donde quiero la solución y él realiza todo el trabajo para mí. El programa lo pueden bajar desde el sitio de descargas de SkunkWorks, http://www.gavd.net/servers/sharepointv3/spsv3_item.aspx?top=5&itm=431.

A propósito, cuando estaba haciendo el programa y rompiéndome la cabeza tratando de usar el "cabinet.dll" que viene con todos los Windows y se encarga de hacer el trabajo, al intentar desensamblarlo sin fortuna, me he dado cuenta que es (probablemente) una aplicación de 16 bits, del año de upa. Aunque, siendo honrados, funciona como un tren, y comprime mucho mejor que zip o rar, así que si no se ha roto, no hay razón para repararlo.

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

Publicado por Gustavo Velez con 3 comment(s)
Archivado en:

Si no funciona, cámbiele el nombre y véndalo de nuevo (2)

Hace ya más de un año que escribí algo sobre el SharePoint Designer (http://blogs.clearscreen.com/skunkworks/archive/2006/01/21/2693.aspx), pero no me aguanto las ganas de volver a escribir algo sobre el tema.

Para los que no andan muy metidos en el mundo de SharePoint, les cuento que hace años existió un producto de Microsoft que consiguió todos los premios que se le pueden conceder al software malo: un Oscar a la peor producción, un Emmy al peor rendimiento y un premio Nobel al peor producto que ninguna compañía en todo el mundo alguna vez ha programado. Ese producto tenía el infame nombre de FrontPage, y para quitarse el estigma de encima, y no molestar a los 3 inútiles que lo utilizaban regularmente, Microsoft le cambio el nombre a "SharePoint Designer", y nos lo está metiendo por las narices como LA herramienta para trabajar con SharePoint.

Con la versión pasada de SharePoint y FrontPage Microsoft ya había empezado a caminar por el mal camino con este producto. Si tenias deseos de arruinar una instalación de SharePoint de uno de esos clientes molestos que no hacen más que quejarse sin pagar un centavo, les aconsejabas que utilizaran FrontPage para hacer los cambios que querían. Luego, a los seis meses o algo así, cuando te volvían a llamar para quejarse (por supuesto) de que el sistema no funcionaba, simplemente les decías que qué querían, si se habían cargado todo el asunto con FrontPage... perfecto...

Ahora, con la nueva versión de Frontp... perdón del SharePoint Designer, el camino sigue tortuoso y mal pavimentado. Ya no solamente se pueden arruinar Sitios ("Ghost" y "UnGhost", se acuerdan?), sino que también se pueden masacrar Paginas Maestras.

Esta semana tenía que hacer un par de Paginas Maestras para un nuevo proyecto de MOSS, y, por eso de darle una segundo oportunidad a todo el mundo, me dio por ver cómo funcionaba el asunto con el Designer. Hasta ahora, era poco lo que había hecho con Paginas Maestras para SharePoint 2007, solamente un par de cambios por aquí y por allá a la pagina por defecto; pero ahora se trataba de crear un Layout desde cero y completamente diferente al diseño por defecto de MOSS. Lleno de buenos deseos comencé a usar el Designer, y la primera impresión fue: arrancar el programa una vez por día, pues cuando lo inicias, te puedes ir a tomar café, porque se demora media hora en cargar. Y se come la mitad de la memoria del servidor, así que si lo utilizas, olvídate de usarlo junto con Visual Studio o algo por el estilo...

Pero bueno, la idea era dejar los prejuicios a un lado, y darle la oportunidad al producto de mostrar lo que podía. Después de tomar el café correspondiente, la impresión siguiente fue: hmmmm... yo no soy un gran amigo de programas wysiwyg, pero este no parece tan malo... puedes seleccionar algo en la pantalla grafica, y te lo señala en el código... puedes cambiar cosas en un lado y en el otro y todo se sincroniza bien... no está mal...

La sorpresa vino cuando aplique los cambios en un Sitio de SharePoint: no se parecía ni remotamente con lo que mostraba el Designer. Cuando quieres usar Paginas Maestras en SharePoint, primero tienes que subir la pagina a una Librería especial en el sistema, y desde este momento MOSS comienza a utilizar la copia de la Base de Datos, no la copia física (el Designer modifica la copia virtual). Así que mi siguiente paso fue crear una copia física de regreso para buscar que era lo que no funcionaba. La segunda sorpresa fue aun mejor: una Pagina Maestra original de 17 Kb se había convertido en 82 Kb después de ser modificada por el Designer. Y cuando la abrí con un editor ASCII, la sorpresa fue aun mejor: el código estaba absolutamente lleno de código extraño que probablemente el Designer necesita para hacer todos los trucos del wysiwig...

La reacción después de media hora fue inmediata, y no muy difícil de imaginar. A la basura con este desastre. Alguien que intente crear código de una manera un poquito decente no utiliza basura de este tipo. Punto. Ya no solamente puedes arruinar la presentación de SharePoint técnicamente, sino también físicamente.

Las Paginas Maestras del susodicho proyecto fueron hechas finalmente en dos días, con un editor común y corriente (EditPlus, mi favorito), y a mano limpia, como los puros machos. Lo único aburrido de hacerlo de esta forma es que cada vez que modificas algo en la Pagina Maestra tienes que hacer cuatro cosas para poder ver los cambios en pantalla: pasar el Sitio a la Pagina Maestra por defecto, eliminar tu pagina de la galería, volverla a subir a la galería, y volverla a acoplar al Sitio. Como buen desarrollador, me hice en diez minutos un programita que hace todo el trabajo usando solamente un botón: el "Master Page Refresher". Para los que quieran trabajar con Paginas Maestras como se debe, pueden bajar el programa del sitio de SkunkWorks directamente (http://www.gavd.net/servers/sharepointv3/spsv3_item.aspx?top=5&itm=426).

Al final, solo me queda repetir las últimas palabras del pasado artículo sobre el tema, por eso de que todavía siguen siendo verdaderas: "Es como dice un amigo mío: 'si eres mal programador, te cambian el titulo a 'Director de Proyecto' y te suben el sueldo, así que tenemos que hacer más errores cuando estamos programando...'. A FrontPage le cambiaron el titulo, no tengo ni idea si le aumentaron el sueldo."

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

Publicado por Gustavo Velez con 1 comment(s)
Archivado en: