Saturday, January 02, 2010
#
El blog ha sido cambiado de sitio. Por favor, visite el Blog oficial de Gustavo en:
http://geeks.ms/blogs/gvelez/
Gracias,
Gustavo
Monday, April 20, 2009
#
No sé porque viendo la ultima versión de Microsoft Commerce Server (versión 2009) no se me quitaba de la mente la canción de Queen "... Another one bites the dust..."
Por pura casualidad le ha dado una mirada a Commerce Server 2009? Si no lo ha hecho, en http://www.gavd.net/servers/sharepointv3/spsv3_item.aspx?top=0&itm=839 encontrara un par de screen dumps. Ve algo conocido? Si, por supuesto que lo ve... es simplemente SharePoint... Que ha hecho Microsoft? Lo ha integrado completamente en SharePoint; por supuesto, para los puristas todavía se puede usar fuera de SharePoint como un producto separado, pero porque lo haría usted?
Como lo han hecho? Muy sencillo, receta conocida: Commerce Servers mantiene su Base de Datos separada para hacer todas las cosas divertidas que se pueden hacer con una tienda online como promociones, compras en grupo, descuentos, carrito de compras y le agrega todo lo divertido que se puede hacer con SharePoint como autorización, creación de listas de compras personalizadas, flujos de trabajo, búsqueda de productos... ideal. Y como es la realización técnica? Muy fácil, Commerce Server le agrega más de 30 WebParts y WebControls a SharePoint para realizar el trabajo. Y gratis y por nada le añadimos modificación de la presentación por medio de las Paginas Maestras de SharePoint y quedamos listos.
Para los interesados en la historia, de pronto recordaran que por allá en el año 1998 Commerce Server era un Add-In para SharePoint, que en ese entonces se llamaba Site Server. Luego, con la versión 2001 ambos productos siguieron rutas separadas y posteriormente la evolución de SharePoint ha sido tan acelerada como el retraso de Commerce Server: si le da una mirada a las versiones anteriores de Commerce Server notará que en realidad nada ha cambiado en el servidor. También como dato anecdótico, Microsoft siempre ha negado que fuera a integrar a Commerce Server en SharePoint, pero al final lo han hecho; y la razón es más que obvia: los dos pueden convivir perfectamente juntos.
También es interesante la tendencia de Microsoft: este es el cuarto servidor independiente que SharePoint se traga en tres años. El primero fue Class Server, un servidor del que probablemente nadie ha oído hablar, que fue creado como competencia de BlackBoard para el mundo de la enseñanza y que ahora es (con muchas modificaciones) el SharePoint Learning Kit, luego fue CMS, completamente integrado en SharePoint en su parte de Content Management; Project Server también ha dejado de existir por sí mismo, siendo ahora un (casi) puro Add-In para SharePoint, y el ultimo en la serie, Commerce Server: Another one bites the dust..."
Cuál será el siguiente? Difícil de decir, los candidatos por defecto ya nos los hemos comido. Por esas cosas raras de la vida, me da la idea que el grupo de Dynamics va siguiendo el mismo camino, pero todo se lo va comiendo CRM por ese lado (cuando se demoraran Navision y Solomon en estar integrados en CRM?). Por el lado de los "independientes" como Windows, Exchange y SQL no es mucho lo que hay que esperar, esos son productos aislados con una tradición y funcionalidad muy especificas. Y Office? Excel ya tiene su espacio en SharePoint, lo mismo que InfoPath; Word y Access no tardarán en seguir el mismo camino. Project, CMS y Commerce Server ya están adentro. Qué queda? Mas integración, espero. Ha tratado de integrar CRM con SharePoint alguna vez? Duele, duele un montón... lagrimas y sudor a raudales... pero Microsoft es el único que conoce el futuro... a ver quién es el próximo que muerde el polvo...
Gustavo - http://www.gavd.net
Escriba un Comentario que me haga reir...
Monday, March 09, 2009
#
Lo llamarán SharePoint 14, SharePoint 2010, ni idea como, pero está llegando a pasos agigantados. En cualquier caso este año tendremos por lo menos un beta; cuando? Tampoco ni idea, pero me atrevería a apostar que será hacia finales del año: septiembre? Muy probablemente antes del congreso de SharePoint de octubre.
Pero más importante de cuándo es que nos traerá la nueva versión. Es mucho lo que se ha especulado, y muy poco lo que se sabe con seguridad. Microsoft, como de costumbre en este tipo de cosas, se ha escondido detrás de barreras y mas barreras para impedir que los que algo saben puedan contar lo que saben. Pero eso no nos impide hablar a los que no sabemos, así que veamos (aunque sea parcialmente) que nos ofrecerá la nueva versión de nuestro servidor favorito.
- La información sobre el Service Pack 2 de WSS que está por salir nos da algunas pistas. Por ejemplo, los Tipos de Contenido de WSS próxima versión estarán basados en XSLT, no en CAML. La información la puede encontrar en el articulo "The customFieldType rule in Pre-Upgrade Checker... bla-bla-bla..." (http://support.microsoft.com/kb/956451/) . En realidad el articulo nos cuenta lo que NO será soportado en la próxima versión, pero la conclusión de que SI será soportado se puede extraer fácilmente
- Vistas de Listas serán creadas con XSLT en lugar de CAML. De nuevo la información se puede encontrar en el articulo "The CustomListView rule in Pre-Ugrade Checker... bla-bla-bla..." (http://support.microsoft.com/default.aspx?scid=kb;EN-US;956450)
- FAST integrado con el motor de búsqueda de SharePoint. Esto no es una sorpresa, y es conocido desde hace tiempo. Revise el blog de Microsoft Enterprise Search (http://blogs.msdn.com/enterprisesearch/ ) y lo verá por todos lados (http://blogs.msdn.com/sharepoint/archive/2009/02/10/microsoft-unveils-new-enterprise-search-road-map.aspx )
- Uso de autorización "Claim-Based". Modificaciones en la forma de autenticación podrán cambiar, por ejemplo, el uso de "Claim-Based" para mejorar la integración con AD y hacer el servicio de autenticación más flexible (http://www.networkworld.com/news/2007/101607-microsoft-switching-sharepoint.html)
- "Master Data Management" estará presente en SharePoint 14 (http://blogs.zdnet.com/microsoft/?p=728 ). Para más información sobre que es MDM, mire el articulo http://geeks.ms/blogs/gvelez/archive/2009/01/04/el-manejo-de-datos-maestros-master-data-management-y-sharepoint.aspx
- Posibilidades de hacer Listas Relacionales, o sea, crear relaciones entre listas, como se puede hacer con tablas de Bases de Datos. También mejoras en rendimiento para superar los problemas de renderización cuando hay más de 2.000 elementos en una lista: http://sharepointsolutions.blogspot.com/2008/03/sharepoint-and-office-14-looks-like-i.html
- SharePoint será de 64 bits únicamente. También conocido desde hace tiempo. Lo puede encontrar inclusive en el documento que describe el Service Pack 1 de SharePoint 2007 (http://go.microsoft.com/fwlink/?LinkId=105704&clcid=0x409)
- Inteligencia de Negocios (BI) para las masas... sea lo que sea lo que eso signifique (http://www.microsoft.com/presspass/features/2009/jan09/01-27KurtDelbeneQA.mspx )... probablemente tiene que ver con PerformancePoint
- Mejoras en la integración entre SharePoint y Groove (http://blogs.msdn.com/bowerm/archive/2008/04/22/the-future-of-groove-and-sharepoint.aspx )
- Visual Studio por fin va a darle un buen soporte a SharePoint (http://blogs.msdn.com/somasegar/archive/2009/01/10/office-client-developer-enhancements-with-vs-2010.aspx)
Bien, apenas se vaya conociendo más información, seguiremos hablando al respecto por estos lados... y por todos lados... Vamos a ver con que sorpresas viene la nueva versión...
Nota: toda la información discutida aquí es públicamente conocida desde hace bastante tiempo, y se puede encontrar regada por internet. Por si las moscas, no he contado nada que no sea del dominio público, y que no se pueda encontrar googleando por un par de minutos...
Gustavo - http://www.gavd.net/servers/
Escriba un Comentario que me haga reir...
Tuesday, March 03, 2009
#
Continuando con la serie para reír o llorar, esta semana nos hemos encontrado con un problema bastante divertido en el proyecto en el que estoy trabajando en el momento.
Como ya vamos entrando en la fase final del asunto, hemos comenzado a hacer pruebas de rendimiento, para poder determinar con más precisión en donde hemos metido las de andar. En una de las pruebas, en la que hemos introducido latencia ("Latency", la demora que ocurre en la conexión entre un pedido del computador cliente y la respuesta del servidor) nos hemos encontrado con un problema interesante: sin latencia, es decir, teniendo el cliente y el servidor uno al lado del otro teníamos tiempos de respuesta no muy malos, pero cuando introducíamos latencia para simular tráfico entre Europa y Asia, por ejemplo, los tiempos de respuesta se nos crecían de forma muy poco decente.
Para tratar de ver porque era el problema, en las pruebas hemos introducido traceadores para ver qué ocurriría en la "conversación" entre el cliente y el servidor. Para nuestra sorpresa nos hemos encontrado con cantidades de errores 401, es decir acceso denegado; inclusive usando cuentas de administrador de la granja, con todos los permisos del mundo, los 401 seguían apareciendo.
Haga la prueba siguiente: un servidor recién instalado de MOSS, con un sitio de publicación completamente por defecto. Llame la pagina inicial por unas cuantas veces para establecer una conexión estable con el servidor. Limpie el cache del navegador y llame la pagina inicial de nuevo. Ahora revise los logs de IIS: no encontrara ningún error 401. Refresque la pagina inicial (con F5, por ejemplo). Revise los logs de nuevo: encontrara entre 16 y 20 errores 401. Explicación? Ninguna. Es reproducible? Completamente y tantas veces como desee.
Entre otras cosas, para hacer pruebas de este tipo puede utilizar herramientas como HttpWatch (no gratis) o Fiddler (gratis). Ah, y otra cosa, la autorización es NTML. Yendo más adentro en el análisis, si intercepta los paquetes de comunicación entre el cliente y el servidor, vera que el handshake entre los dos ocurre más o menos de la siguiente forma:
1 – Cliente envía al servidor: GET (y otras cosas)
2 – Servidor devuelve al cliente: 401 Unauthorized, utilice NTLM
3 – Cliente envía al servidor: GET (otras cosas), Authorization: NTLM (mensaje 1)
4 – Servidor devuelve al cliente: 401 Unauthorized, utilice NTLM (mensaje 2)
5 – Cliente envía al servidor: GET (otras cosas), Authorization: NTLM (mensaje 3)
6 – Servidor devuelve al cliente: 200 Ok
Mensaje 1 contiene el nombre del host y el nombre del dominio NT del cliente
Mensaje 2 contiene el "desafío" ("Challenge") del servidor
Mensaje 3 contiene el nombre del usuario, del host, del dominio y dos "respuestas" al "desafío"
Y esto ocurre para cada elemento en la pagina que necesita autorización. O sea que se podrá imaginar, cada ida y venida, para cada elemento y todo multiplicado por 300 milisegundos de latencia, los tiempos de respuesta son de todo menos bonitos.
Es posible de evitar este fenómeno? Probablemente no, es algo que está enterrado profundamente en el protocolo del handshake. Lo único que se puede hacer es utilizar Kerberos. Para ver más información sobre Kerberos, revise el articulo en http://www.gavd.net/servers/sharepoint/sps_item.aspx?top=0&itm=292 y para ver como cambiar la autorización en SharePoint de NTML a Kerberos el articulo http://www.gavd.net/servers/sharepointv3/spsv3_item.aspx?top=4&itm=397. Es algo de lo que tiene que preocuparse? No, de ninguna manera si sus usuarios están al lado de los servidores de SharePoint en una intranet local; SI, con toda seguridad si los usuarios están repartidos por todo el mundo y los servidores están regados por tres continentes.
En cualquier caso, si lo que necesita es hacer que los tiempos de respuesta disminuyan rápidamente sin gran esfuerzo, cambie de NTML a Kerberos, y vera incrementos inmediatos (dependiendo, por supuesto de la latencia... y contra la latencia no podemos hacer nada, es simplemente un hecho físico: que tan rápido puede viajar una señal entre dos puntos). El problema de Kerberos es, por supuesto, que necesita tener un servidor para mantener las claves, pero eso se puede solucionar fácilmente.
Y sobre todo, continúe sonriendo... esta vez no de una de esas "características no documentadas" SharePoint, sino de algo muy particular de IIS...
Monday, February 23, 2009
#
SharePoint es un producto muy serio, por supuesto. Y todos los que estamos metidos en el mundo de SharePoint y nos ganamos el pan de cada día con él, lo que también es muy serio, lo sabemos. Pero eso no quita que no nos podamos reír de las “funcionalidades no documentadas” con las que nos chocamos de vez en cuando. O, si esta de mal humor y es uno de esos días que desea olvidar, también puede decir que no es para reírse sino para llorar... pero yo estoy de buen humor hoy, así que prefiero reírme...
Para divertirse un rato, haga el siguiente experimento: abra cualquier pagina de una instalación de SharePoint; descargue localmente el icono con la lupa que puede encontrar al lado derecho de la casilla donde se escribe el texto de búsqueda en WSS y MOSS (motor de búsqueda). Luego, por eso de querer ser travieso, abra el archivo local con cualquier editor de texto ASCII (el Bloc de notas, por ejemplo)... bien, que le parece?
Ayer, por eso de estar mirando por aquí y por allá, estaba revisando el directorio : “C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\TEMPLATE\IMAGES” de un servidor de SharePoint; ustedes lo conocen, por supuesto, allí están todos los iconos usados por el portal. Bien, este es un directorio con más de 2.000 archivos, o sea que se preguntaran que estaba mirando por allí... digamos que me estaba aburriendo y me dio por aprenderme los nombres de los iconos usados por SharePoint... pero siguiendo con la historia, me llamó la atención que todos los archivos de iconos son entre 1 y 2 KB, por eso de que iconos no son figuras muy grandes, por supuesto. Todos, menos uno, el archivo “gosearch.gif” que es de 20 KB. Este es el icono con la lupa que les contaba al principio.
Pues bien, que hace código HTML en un icono? Nada, pensaría yo. Esto parece una metida de pata de esas brillantes, de las que Microsoft es experto. Pero se estará preguntando, y qué más da? Son solamente 19 KB mas... piénselo otra vez: este icono se encuentra en cada una de las páginas de cualquier instalación de WSS o MOSS. Alguna vez se ha puesto a pensar cuantas instalaciones de SharePoint hay en el mundo? Con cuantos usuarios? Pues con toda seguridad vamos por los millones de usuarios, que cada día abren un montón de páginas, todas con un icono que es 19 KB más grande de lo que debería. Multiplique 19 KB por millones de usuarios y multitud de páginas, y vera que el uso (o el desperdicio) de ancho de banda por un solo icono es realmente alarmante. Si, ya lo sé, hay otros archivos que son aun peores (init.js, por ejemplo, una salvajada), pero que yo sepa, todos esos archivos tienen una función, y al código en este archivo yo no le veo ninguna. Y también se que el archivo puede estar en cache del navegador, de tal forma que no es bajado cada vez, pero de todas formas...
Por si acaso le interesa, puede eliminar todo el código HTML en el icono “gosearch.gif”, dejando solamente el primer renglón (el icono real), y su servidor seguirá funcionando sin ningún problema. Y si también lo quiere saber, este icono lo estamos usando desde SharePoint 2003, por lo que el ancho de banda que hemos despilfarrado es imposible de saber a esta hora.
Wednesday, February 11, 2009
#
El cuarto numero de CompartiMOSS, la revista especializada sobre SharePoint en español acaba de aparecer. Puede encontrar el nuevo número del magazine en http://www.gavd.net/servers/compartimoss/compartimoss_main.aspx como un archivo pdf (para descargar en alta o baja resolución).
En este número:
- Editorial
- Evolucionando con la Web: SharePoint y la Web con 2.0 (Cristina Torné Soler)
- Servicios de formulario en SharePoint 2007 y formularios creados con InfoPath 2007 (Fabián Imaz)
- Implementación y Desarrollo de un Portal de Intranet para un Aeropuerto (Elsa Valencia Jackes)
- Modelización de procesos de negocio en MOSS 2007 (Carlos Esquerza)
- Manejando el Contenido Empresarial (Juan Andrés Valenzuela)
- Secciones fijas
La idea de la revista es propagar el uso y conocimiento de SharePoint. Todas las personas que trabajan con SharePoint en el mundo hispanohablante están invitadas a participar.
La subsistencia de la revista depende no solo de la aceptación del magazine, sino de los aportes en artículos, ideas, experiencias de todos nosotros. Si desea tomar contacto con los editores, en la revista misma encontrara toda la información necesaria, o escriba sus comentarios directamente a compartimoss@gavd.net.
Gustavo - http://www.gavd.net/servers/
Escriba un Comentario que me haga reir...
Monday, January 26, 2009
#
Pues bien, año nuevo, trabajo nuevo y SharePoint nuevo. Hay veces que todo se viene de una vez... Sí, tenemos SharePoint nuevo. A menos que usted haya estado inconsciente durante los últimos meses, o haciendo trabajo voluntario en Somalia o acaba de regresar de un viaje a la luna, supongo que se habrá enterado que Microsoft está trabajando en la versión 14 de Office y que, aunque todavía no ha dado una fecha para liberar el software, con toda seguridad ocurrirá a finales de este año o principios del entrante.
Y por supuesto, SharePoint es parte de Office, así que tendremos también una nueva versión tanto de Windows SharePoint Services (WSS) como de Microsoft Office SharePoint Server (MOSS). Ya incluso existe una versión Alpha distribuida por ahí, para los que tengan la curiosidad de ver que está pasando con nuestro servidor favorito. Por supuesto, Microsoft ha continuado con su mal vicio de no soltar nada sobre lo que viene nuevo, lo que sigue igual y lo que se va a eliminar; esta característica siempre ha sido muy chocante de Microsoft pues para algunos de nosotros es realmente imprescindible conocer de antemano lo que podemos y no podemos hacer en las implementaciones actuales para no dejar a nuestros clientes con los platos rotos dentro de algunos meses, con Portales que o no se pueden migrar, o que son tan difíciles de pasarlos a la nueva versión que prácticamente van a perder la inversión. Y comercialmente tampoco es inteligente de Microsoft el hacerlo de esta manera: en el año 2006 la venta de licencias de SharePoint 2003 se mantuvo quieta, después de haber estado aumentando año por año a una rata de casi 40%, simplemente por el hecho de que nadie se arriesgaba a hacer implementaciones grandes de SharePoint 2003, sabiendo que en un par de meses vendría una nueva versión. Por supuesto este año nos van a decir que la tasa de crecimiento de SharePoint se ha bajado por la crisis económica y cuentos de esos, pero probablemente será más por la falta de información sobre la nueva versión, que por que los bancos en todo el mundo, no solo en Norte América, han sido manejados como si fueran casinos callejeros...
En fin, volviendo a SharePoint, cuando la situación con SharePoint 2007 era similar a la actual con la nueva versión, alguna vez escribí algo por estos lados haciendo una “rápida encuesta no científica” sobre lo que nos gustaría que fuera solucionado/mejorado/agregado/eliminado en la nueva versión. Y por supuesto, siempre es gracioso comparar dentro de unos meses la realidad con las esperanzas, para ilusionarnos/desilusionarnos/renegar/sonreír. Para empezar, esta es una lista muy incompleta de mis deseos:
Deseos indispensables (hay que mejorarlo):
- Lo más obvio: que Variations funcione; que el Business Data Catalog sea de ida y vuelta (poder devolver datos, no solo poderlos ver); que el HTML generado sea menos Microsoft y mas estándar; que el Records Center funcione bien en otros idiomas fuera del ingles, lo mismo que el corrector de ortografía
- Lo que deseo como desarrollador: un mejor SDK; mejoras en Features (Características): que sean versionables, que se puedan activar desde una Solución; no queremos más dos tipos de Paginas Maestras (una “normal” y otra para “administración”) sino que todo funcione con una sola; soporte nativo “fuera-de-la-caja” (buena traducción de out-the-box) para Ajax, SilverLight y LINQ
- Lo que quiero como usuario: poder usar SharePoint en móviles, PDAs y demás cosas de esas (que tal algo así como WebParts especiales para teléfonos?); alguna manera de poder instalar mis propias aplicaciones como usuario sin tener que involucrar a todo el departamento técnico de la empresa (algo como WebParts en un “sand-box”, que solo funcione para mi, que yo lo pueda instalar y que este aislado del SharePoint “real”); que Carpetas en Librerías sean utilizables de verdad, que les pueda poner derechos y metadata, y que existan también en Listas
Deseos deseados (lo que me gustaría tener):
- Poder crear reportes para Flujos de Trabajo de una forma más sencilla, fuera de un montón de otros deseos para Flujos: poder usar flujos en paralelo, que el SPListItem tenga un objeto para instanciación de la misma forma que el SPList lo tiene para asociación, poder enganchar más de una página de modificación (Microsoft dice que se puede, pero hasta ahora no he visto a nadie que lo haya podido hacer, por no decir que a mí nunca me ha funcionado), poder acoplar flujos a Listas, Sitios y Webs (no solo a elementos de Listas); Eventos para Soluciones: de la misma forma que Features, que pueden usar eventos, yo quisiera tener eventos en soluciones de tal forma que pueda engancharle código al momento en que la solución es activada o desactivada...
Utopias (lo que nunca voy a ver):
- Que MOSS desaparezca: yo solo quiero tener a WSS, y una serie de Add-Ins, que funcionen tal como Project Server lo hace en el momento
- Que el horrible azul de la instalación por defecto sea cambiado por otro color, no importa cual
- Poder usar Ribbons en la interface ... Porque no? A mí me gusta en Word y Excel...
- Que SharePoint Designer desaparezca por el resto de la eternidad
Lo que probablemente tendremos (casi con toda seguridad, aunque me estoy adelantando a lo que quiero decir en otra oportunidad):
- Mejores plantillas para Wikis y Blogs
- Mas sobre “Social Networking, People and Groups”: es importante para empresas en Norte América, así que, según la cosmogonía de Microsoft, tiene que ser importante para todo el mundo... no importa que toda la infraestructura al respecto NO sea utilizada por nadie fuera de Norte América misma
- Integración off-line, por el estilo de lo que Groove ha prometido desde los tiempos de Matusalén y nunca lo han hecho
- Power Shell... desde este momento le pongo la firma... me atrevo a apostar 10 minutos de salario a que stsadm va a desaparecer y será reemplazado por algún tipo de cmdlets
En fin, la discusión está abierta. Tengo un montón de curiosidad de saber lo que ustedes piensan al respecto. Si le sirve de alivio, Microsoft no le va a hacer caso ni a usted ni a mí, así que esto no es más que una especulación... tómeselo como un ejercicio mental, con una sonrisa y una taza de café caliente...
Gustavo - http://www.gavd.net
Escriba un Comentario que me haga reir...
Monday, January 19, 2009
#
La semana pasada, charlando con un colega, me ha hecho una de esas preguntas que te agarran complemente con la guardia abajo: “En tu opinión, cuales son los mayores problemas de SharePoint?”... y por eso de ser un mentiroso experimentado, he podido contestar sin sonrojarme: "Problemas?, no, por supuesto, SharePoint no tiene problemas"... y luego los dos, muertos de la risa, seguimos conversando de cosas banales.
Pero después la pregunta me ha hecho recapacitar: después de tantos años de trabajar con SharePoint, intentando hacer de todo, por todos lados y de todas las maneras posibles, dejándome el pelo y litros de sudor y lagrimas por el camino, nunca me he puesto a pensar cuál es su mayor (o mayores) problema. Algo así como la vista de túnel: te fijas en aspectos determinados de un problema, sin ver que está pasando a los lados... o como el caballo en la carreta, que solo puede mirar hacia adelante...
Podría decir cual es el mayor problema de SharePoint? (EL problema, no LOS problemas, para simplificar el asunto). En realidad tendría que pensarlo detalladamente; los problemas cotidianos de falta de documentación, inconsistencias e inconsecuencias no me atrevería a nombrarlos como EL problema... que Variations no funciona como debería, y el corrector de ortografía y el Records Management solo funcionan bien en la versión en ingles tampoco, pues con seguridad serán mejorados en la próxima versión. Que Visual Studio no sea capaz de mostrar paginas aspx y WebParts de una forma decente es bastante irritante, y reniegas cada vez que tienes que crear una interface a puro pelo, pero con algo de experiencia de programación no es que sea algo que te impida seguir trabajando...
Mejor dicho, SharePoint tiene cientos, no, mejor dicho, miles de cosas pequeñitas que no funcionan como debería, que no funcionan como yo quisiera que funcionaran, que son imposibles de hacer o que son simplemente irritantes, pero decir que alguna de ellas es "el mayor problema de SharePoint", no, tampoco puedo. Así que mi (sínica) respuesta no era tan descabellada después de todo. Probablemente la pregunta está mal hecha y no hay un mayor problema, sino múltiple problemas pequeñitos.
En realidad, mirando los proyectos que he realizado en los últimos, digamos, seis años, con SharePoint 2003 y 2007, tengo que decir que ninguno ha presentado problemas técnicamente insolubles. Por supuesto no quiero decir que ha sido fácil, de ninguna manera, lo único que quiero decir es que los problemas nunca han sido técnicos sino humanos: meter las de andar es de lo más fácil, sobre todo si se desconoce el producto (al principio de su ciclo de vida), o se quiere ser cabecidura o simplemente porque no somos tan inteligentes como quisiéramos (y como le hacemos creer a nuestros clientes). Haciendo un inventario de los proyectos de que me acuerdo rápidamente, los que han fracasado lo han hecho por factores humanos: mala gestión de clientes y usuarios, problemas de comunicación y malentendidos, presupuestos mal hechos que luego significan conflictos con el cliente, expectaciones desmesuradas que luego no se pueden cumplir...
Sobre todo desde hace unos dos años, desde que SharePoint 2007 se impuso como EL sistema empresarial, y todas las compañías piensan que están más o menos obligadas a implementarlo, los problemas de gestión se han multiplicado mucho más rápido que los problemas técnicos. Salvando las distancias, es un problema similar al de mediados de los años 90 del siglo pasado, cuando, de un momento a otro, todo tipo de negocios y empresas se vieron "obligados" a tener un sitio en Internet; cuando el dueño de la pizzería de la esquina se vio obligado a tener un sitio propio, sus problemas eran muy diferentes a los de la empresa de petróleos del país: con el uno puedes hablar de una forma y con el otro tienes que hablar de otra forma, su patrón de expectaciones es muy diferente, sus recursos económicos y capacidad de correr riesgos también... todos problemas de gestión humana y no problemas técnicos, algo que muy pocas empresas de IT entendieron en su tiempo; al final, el asunto se convirtió en un balón de aire caliente que nos reventó a todos en las narices hace unos diez años...
Y ahora volviendo a la pregunta del principio, el momento también es apropiado para cuestionarse cosas por el estilo: la próxima versión de SharePoint se nos viene encima y muy probablemente será una evolución técnica de la versión 2007, no una revolución. Esto significa que los problemas técnicos los podremos seguir solucionando, pero los problemas humanos continuaran siendo la incógnita que nos hará fracasar de vez en cuando... esperando que sea "de vez en cuando" y no "con frecuencia" o, peor aún, "continuamente"...
Gustavo - http://www.gavd.net
Escriba un Comentario que me haga reir...
Monday, January 12, 2009
#
En algún lugar de Seattle de cuyo nombre no quiero acordarme, erase que se era un producto llamado "Site Server”, que más que nada era un montón de herramientas engomadas unas a las otras, porque de otra forma no habría manera de venderlas por separado. Las herramientas incluían un sistema de manejo de contenido de sitios, creación y análisis de estadísticas de utilización, maneras para personalizarlas y un sistema de manejo de documentos. En realidad, Site Server era un agregado (Add-In) de "Search Server”, el primer intento de Microsoft de crear una maquina de búsqueda que pudiera ser utilizada coherentemente por todos sus productos del momento. Y el otro agregado para Search Server era "Commerce Server".
Estamos hablando de 1997, el año en el que desaparecieron los dinosaurios... Internet estaba apenas empezando a tomar fuerza y era más un juego para gente desocupada que un producto que empresas pudieran tomar en serio. Los únicos servidores que Microsoft producía eran SQL (versión 6.5 en ese entonces) y Exchange Server (versión 5.5). Windows NT estaba apenas empezando a funcionar, y no era suficientemente estable para que pudiera ser utilizado masivamente.
Site Server había sido programado en asp (tradicional asp, no aspx... DotNet aparecería apenas 3 años después). En ese entonces, Microsoft quería apostarle en grande a Exchange, y salieron con "Platinum", la nueva versión que incluía un nuevo depósito que podría ser utilizado no solo para guardar Emails, sino también cualquier otro tipo de datos, como documentos y sitios Web. "Tahoe", la nueva versión de Site Server, utilizaría el depósito de datos de Exchange, agregándole manejo de documentos y un motor de búsqueda. Todo el sancocho de piezas sueltas estaba amarrado por medio de WebDAV (Web Document Authoring and Versioning), que servía como mecanismo de comunicación e intercambio de información. Ahora estamos hablando del año 1999, en el que Lotus Notes de IBM era LA plataforma de intercambio de información empresarial (suena raro, eso era solamente hace diez años, pero probablemente ahora muy pocos se acuerdan de Lotus Notes, por no decir que alguien lo ha visto funcionar... pero hay alguien por ahí que haya visto WordPerfect o VisiCalc funcionando?).
En el mismo 1999, Microsoft salió con otra herramienta suelta: "Digital Dashboard Kit", el primer framework para un Portal de Microsoft: la interface se podía utilizar en un navegador o en Outlook, y estaba construido por medio de "nuggets" o "portlets", pedazos de software aislados, dedicados a realizar alguna tarea específica, que se podían integrar en una página Web (suena a WebPart, verdad?).
Pues bien, el año 2000 fue un año importante para Microsoft: Windows server 2000, SQL server 2000 y Exchange server 2000, junto con la aparición de DotNet y CSharp representaron la entrada de gala de Microsoft en el mundo empresarial. Y juntando a Tahoe con el repositorio de Exchange y el Digital Dashboar, nació oficialmente SharePoint Portal Server 2001. La pelea legendaria entre SQL y Exchange sobre quien poseía el mejor repositorio de datos fue ganada apabullantemente por SQL Server (probablemente el servidor más estable de Microsoft), y el "Local Web Store" de Exchange fue simplemente abandonado por órdenes expresas de Steve Ballmer mismo.
Desafortunadamente para SharePoint 2001, la decisión llego demasiado tarde, y el Portal estaba ligado intrínsecamente al Local Web Store (en realidad una Base de Datos basada en archivos físicos en el servidor), que era totalmente incapaz de servir una carga razonable de usuarios y tampoco utilizaba el nuevo DotNet framework. Esto represento casi la muerte prematura de SharePoint en el momento. Y, además, se le quito la parte de manejo de contenido (CMS, Content Management Server fue creado como un servidor separado) y Commerce Server también fue independizado. Y para acabar de completar el desastre, Microsoft salió con un Add-In para Office 2000 llamado "SharePoint Team Services", que proveía funcionalidad que entraba en el terreno de SharePoint Server.
Afortunadamente el mercado de Portales se estaba empezando a desarrollar con fuerza, empresas empezaron a notar las ventajas de un sistema on-line de manejo de documentos, y Microsoft se dio cuenta que no podía abandonar el mercado: así que no había más remedio que sacar una nueva versión de SharePoint. La meta era fácil de pensar: usar SQL como depósito de datos, reemplazar asp por aspx y el DotNet framework y crear un sistema que pudiera ser escalado a cientos de miles de usuarios sin perder estabilidad. En octubre 2003 Microsoft liberó Office 2003 y Windows SharePoint Server 2003, y desde entonces el asunto ha ido a una velocidad imparable...
SharePoint 2003 fue inicialmente creado como un puro sistema de manejo de documentos, pero debido al fantástico API y Modelo de Objetos que Microsoft le creó, fue adoptado rápidamente como una plataforma de desarrollo, con la que se podía ir hacia cualquier lado, chocándose muy frecuente con CMS (que ya también había sido migrado al DotNet framework). En 2004 los dos grupos de desarrollo (SharePoint y CMS) fueron juntados, y el grupo de desarrollo de DotNet tomó la idea de las WebParts y la integro en AspNet 2.0. Luego, con DotNet 3.0, apareció el Windows Workflow Foundation; de igual manera, Business Intelligence toma cada vez más importancia.
SharePoint 2003 ha sido uno de los éxitos más clamorosos de Microsoft en sus 25 años de historia. Y para continuar ganando mercado, una nueva versión fue creada, que tomaba todos los elementos mencionados: regreso a ser un sistema de manejo de contenido sin abandonar el manejo de documentos, flujos de trabajo poderosos, Business Intelligence, y tratando de evitar los traumas de migración sufridos entre las versiones 2001 y 2003 pero manteniendo los puntos fuertes de escalabilidad y estabilidad del sistema. Y SharePoint 2007 nació.
Y de eso hace ya dos años, así que ahora estamos en camino a una nueva versión...
Gustavo - http://www.gavd.net/servers/
Escriba un Comentario que me haga reir...
Monday, January 05, 2009
#
Me perdonan por la traducción, pero por eso de estar empezando el año y tener cada vez menos células grises, no se me ocurre otra cosa...
Pero bueno, para empezar bien, comencemos por aclarar que es Master Data management (MDM). Según Stratature (http://www.stratature.com/faq.html): “MDM puede ser descrita usando la manera en que datos maestros interactúan con otros datos. Datos maestros puede ser descrito usando la manera en que son creados, leídos, actualizados, eliminados y buscados... La relacion entre datos maestros y datos transaccionales puede ser vista fundamentalmente como una relación sustantivo/verbo. Datos transaccionales capturan los verbos como venta, distribución, compra, email y revocación; datos maestros son los sustantivos”
Siguen sin entender ni jota? Bienvenidos en el club, yo tampoco entiendo nada. Probemos otra vez, utilizando ahora las claras explicaciones de Microsoft (http://msdn.microsoft.com/en-us/library/bb190163.aspx): “Que son Datos Maestros? La mayoría de los sistemas de software tienen listas de datos que son compartidos y usados por diferentes aplicaciones en el sistema. Por ejemplo, un sistema ERP típico tiene por lo menos un “Cliente Maestro”, un “Elemento Maestro” y una “Cuenta Maestra”. Estos datos maestros son los bienes activos más importantes de una compañía. No es inusual que compañías sean adquiridas principalmente para tener acceso a sus Datos Maestros de clientela”.
Si le agregamos a esto “Manejo”, creo que la cosa se va aclarando un poco: cómo manejar esos “Datos Maestros” para evitar contaminación, errores y problemas. Siguiendo con un ejemplo de Microsoft (amo ejemplos, denme ejemplos, con ejemplo existe el riesgo de que entienda de que se trata...): “Por el hecho de ser utilizado en múltiples aplicaciones, un error en un Dato Maestro puede causar errores en todas las aplicaciones que lo usen. Por ejemplo, una dirección incorrecta en el Cliente Maestro significa que ordenes, cuentas y literatura de mercadeo son enviadas a la dirección equivocada. Similarmente, un precio incorrecto en un Elemento Maestro puede significar un desastre y un número de cuenta incorrecto en una Cuenta Maestra puede conducir a que el CEO de la empresa termine en la cárcel”.
Fuera de que un CEO de una empresa en la cárcel es un espectáculo muy reconfortante, parece claro porque Master Data Management es importante. También se puede pensar que no es nada nuevo, probablemente lo único nuevo es que le hayan puesto un nombre, pero desde los tiempos de la invención de la rueda no es mucho lo que nos hemos inventado que se pueda llamar realmente nuevo (hummm... empezamos el año con comentarios pesimistas...).
Pues bien, a que viene todo esto, se estará preguntando. Microsoft ha comprado hace algunos meses una empresa que se llamaba Stratature, que era la empresa líder en la creación de software para Master Data Managment; en el sitio original de la empresa (http://www.stratature.com ), se puede leer que Microsoft ha adquirido Stratature como “la culminación de un esfuerzo para deliberar soluciones unificadas de Master Data Management para mejorar las iniciativas de manejo de información utilizando SQL, Inteligencia de Negocios y SharePoint”. Pues sí, SharePoint está metido en el asunto, y los rumores de los últimos tiempos es que la próxima versión de nuestro servidor favorito (o más odiado, como prefiera), incluye cosas para hacer Master Data Management. Qué cosas? Ni idea, pero no demoraremos mucho mas en descubrirlo...
A propósito, si le interesa, Microsoft tiene ahora inclusive un sitio Web sobre MDM, https://www.microsoft.com/sharepoint/mdm/default.mspx y un “Roadmap” (http://download.microsoft.com/download/4/6/2/462b1624-2ac4-4ebd-b4c0-7eaef3e4466d/MSMDMRoadmap.pdf) que entre otras cosas asegura que MDM será implementado en SharePoint.
Gustavo - http://www.gavd.net/servers/
Escriba un Comentario que me haga reir...
Monday, December 08, 2008
#
Esta semana a salido la versión alfa de Opera 10, el que es probablemente (opinión personal, no empiecen a disparar) el más rápido, mejor diseñado y menos valorado navegador en el mercado.
Según el fabricante, la nueva versión es 30% más rápida que la actual (que ya era la más rápida de todos los navegadores disponibles) y es el primer navegador que obtiene un escore de 100 sobre 100 de la prueba Acid3. Por si le interesa saberlo, la prueba Acid3 fue diseñada para probar que tan bien puede satisfacer un navegador los estándares de ECMAScript 262 y el Modelo de Objetos de Documentos versión 2 del W3C. La prueba la puede encontrar en http://acid3.acidtests.org/; para los que les sigue interesando, Opera 10 consigue un 100/100 en la prueba, el nuevo Google Chrome 79/100, Firefox 71/100 y Internet Explorer... bueno, le aseguro que no lo quiere saber...
La siguiente imagen muestra una instalación por defecto de WSS vista con Opera 10 versión alfa:
Note el menú horizontal, que no es horizontal como debería ser un menú horizontal, sino que es vertical. Además, ni el menú de “Site Actions” ni el menú de “Welcome ...” funcionan. Pero que es rápido, es más rápido que la luz...
Para los interesados, la versión alfa de Opera 10 puede ser descargada desde http://www.opera.com/browser/next/
Gustavo - http://www.gavd.net/servers/
Escriba un Comentario que me haga reir...
Tuesday, December 02, 2008
#
Testing es algo que todos los desarrolladores deberíamos hacer, y muy pocos hacen. Por no decir “Testing intensivo y consecuente”, pues los números se reducen a prácticamente cero... si le da curiosidad, revise las estadísticas mostradas en http://www.methodsandtools.com/dynpoll/oldpoll.php?UnitTest2, http://blog.davebouwman.net/2008/06/04/DeveloperSurveyUnitTestingAmpOtherTools.aspx o http://telerikwatch.com/2008/05/survey-says-unit-testing-still-not.html. Especialmente el segundo vinculo es interesante, aunque por experiencia propia me arriesgaría a decir que los porcentajes de aplicación de testeo son mucho, mucho mas bajos.
Siendo sincero, escribir software es una de las cosas más divertidas para hacer en el mundo (lo digo por deformación profesional, probablemente), pero hacer pruebas para ese mismo software es una de las más aburridas. Y en algunos casos, es simplemente imposible, como lo es hacer pruebas para SharePoint. Pero para comenzar por el principio, hay que hablar algo sobre testing en general.
El mundo del testing es amplio y ajeno: hay tantos tipos de testeo como tipos de desarrolladores... pero mirándolo desde una perspectiva global, podemos decir que hay:
- “Unit Test” (Prueba unitaria) – verifica que las unidades individuales de código fuente funcionan como se espera. Normalmente la unidad de código más pequeña es una función, método o propiedad.
- “Regression Test” (Pruebas de regresión) – Cuando se modifica algo que ya ha sido probado que funciona (con el Unit Test), es necesario garantizar que sigue funcionando apropiadamente después de algún tiempo: este es el trabajo de Regression Test
- “Integration Test” (Pruebas de Integración) – Cuando todas las unidades (que ya han sido probadas con Unit y Regression Test) se unen para trabajar conjuntamente, es necesario garantizar que todas funcionen como una unidad apropiadamente. Este es el trabajo del Integration Test
- “System Integration Test” (Pruebas de Integración de sistemas) – puede ser visto como una ampliación del anterior: este test garantiza que nuestro sistema (que ya ha sido probado con Unit, Regression e Integration Tests) puede funcionar con otros sistemas externos apropiadamente
En cuanto a metodologías, mis dos hermanas sicólogas me enseñaron que hay tres tipos de pruebas: Black Box, White Box y Grey Box testing (el modelo ha sido tomado “prestado” de la psicología).
- “Black Box Testing” – la prueba no sabe nada sobre cómo funciona internamente el sistema a probar... solamente que si se le entregan algunos parámetros de entrada, deben salir algunos resultados. Black Box Testing le entrega parámetros a una función (correctos e incorrectos) y observa los resultados que la función devuelve
- “White Box Testing” – por el contrario, la prueba conoce perfectamente el funcionamiento interno del sistema a probar, y crea las pruebas basado en el
- “Grey Box Testing” – ya se imaginaran lo que es, una mezcla de los dos
Finalmente, es necesario hablar de algo que está de moda, “Test-driven development” (TDD). Esta es una técnica de programación basada en escenarios de prueba o de funcionamiento (Test o User Cases), bastante ligada a metodologías de desarrollo como Agiles, que indica que primero hay que hacer el diseño del software (sus clases, métodos, propiedades y eventos), luego generar las definiciones (el “esqueleto” del código), luego crear los métodos de prueba ANTES que el código mismo, y finalmente, crear el código para rellenar el esqueleto.
Bien, esto es más o menos la parte teórica. Como los desarrolladores de código que somos, ¿Qué es lo importante de todo esto?
- Primero que todo, y antes que nada, Unit Test. Unit Test me permite dormir tranquilo, pues me asegura que mi código funciona correctamente y seguirá funcionando después de que lo he modificado (¿se puede usar Unit Test como Regression Test? Esta es una discusión bizantina a la que nunca nadie llega a una conclusión, algo por el estilo a que es mejor CSharp o Visual Basic, o Windows o Linux. Vea por la ejemplo la discusión que surgió en el ultimo PDC al respecto en http://channel9.msdn.com/pdc2008/TL61/).
- Como segunda medida, si se está usando (o se quiere usar) TDD, la decisión de usar Black o White Test es importante... o, mejor dicho, si se quiere usar TDD, hay que usar Black Box Testing. Punto. O hay que iniciar una nueva discusión bizantina sobre si es posible iniciar el desarrollo en Black Box y luego continuarlo en White Box, lo que lleva al modelo de Grey Box...
Noten que hasta ahora he intentado no tomar partido por ninguno de los puntos mencionados. Todo porque mi punto es SharePoint, no discusiones teológicas sobre cómo, cuando y donde hacer testeo de software. Pero llegamos a la parte interesante: SharePoint.
Cuando se trata de crear Testeo Unitario para software creado por uno mismo, es decir, en donde se tiene el código fuente, construir las clases de prueba es largo y tedioso, pero es posible de hacer con las herramientas estándar para el efecto (como las que tiene Visual Studio mismo, por ejemplo). Cuando lo que se desea es testear código que utiliza el Modelo de Objetos de otro programa, como ocurre cuando se escribe software para SharePoint o cualquier otro servidor (SQL, Exchange, BizTalk, etc), es necesario “hacerle creer” a nuestro código que esta interactuando con el servidor, pero sin que lo haga en realidad, porque no se desean tener dependencias con él.
Imagínese una situación no tan hipotética: se crea un método que comprueba los derechos de una Librería de SharePoint; si se utiliza una instalación real de SharePoint para hacer las pruebas, es necesario mantener esa configuración por todo el tiempo del desarrollo y mas allá para garantizar que los resultados de las pruebas sean consistentes en el tiempo. Peor aún, todos los desarrolladores del grupo tienen que disponer de la misma instalación para que sus pruebas también sean consistentes entre desarrolladores. Esto es prácticamente imposible de conseguir y, además, muy engorroso. Para solucionar el problema existen diferentes tipos de herramientas que “falsifican” el Modelo de Objetos del servidor (Mockers, Stubbers, etc)
Como ya hemos dicho varias veces Carlos y yo, el problema con SharePoint y Unit Test es que el Modelo de Objetos de SharePoint tiene muchas clases selladas o sin constructor público. Este ha sido el gran problema hasta ahora para poder usar Mockers y Stubbers, pues ellos no saben qué hacer con un objeto sellado o sin constructor público. El posting “Testeo Unitario para SharePoint: acercándose a la respuesta definitiva – parte 1” (http://geeks.ms/blogs/gvelez/archive/2008/11/03/testeo-unitario-para-sharepoint-acercandose-a-la-respuesta-definitiva-parte-1.aspx) que escribimos anteriormente comenzó a mostrar cómo se puede iniciar el testeo unitario para SharePoint usando la última versión de TypeMock (http://www.typemock.com ). Las próximas partes continuaran con la parte práctica de la creación y codificación de las clases de prueba. Pero en esta segunda parte se trata de discutir la importancia de Unit Test, Regression Test, Black y White Box Testing y TDD.
Uno de las características más importantes de TypeMock es la relación intrínseca entre el código de trabajo y el código de testeo, es decir, el fabricante ha escogido por un modelo de “White Box Testing”. Veamos un ejemplo el ejemplo de una función que simplemente imprime los elementos de una Lista de SharePoint:
Código de trabajo:
public void GetCollection01()
{
SPSite mySite = new SPSite("http://wsses");
using (SPWeb myWeb = mySite.OpenWeb())
{
foreach (SPList myList in myWeb.Lists)
{
foreach (SPItem myItem in myList.Items)
{
Console.WriteLine(mySite.Url + " - " + myWeb.Title + " - " + myList.Title + " - " + myItem.ID.ToString());
}
}
}
}
Código de prueba unitaria:
[TestMethod()]
public void GetCollection01Test()
{
SPWeb fakeWeb = Isolate.Fake.Instance<SPWeb>(Members.ReturnRecursiveFakes);
SPList fakeList = Isolate.Fake.Instance<SPList>(Members.ReturnRecursiveFakes);
SPItem fakeItem01 = Isolate.Fake.Instance<SPItem>(Members.ReturnRecursiveFakes);
using (var recorder = RecorderManager.StartRecording())
{
SPSite myFakeSite = new SPSite("");
recorder.ExpectAndReturn(myFakeSite.Url, "fakeSiteUrl").RepeatAlways();
recorder.ExpectAndReturn(myFakeSite.OpenWeb(), fakeWeb);
}
Isolate.WhenCalled(() => fakeWeb.Title).WillReturn("fakeWeb");
Isolate.WhenCalled(() => fakeWeb.Lists[2].Title).WillReturn("fakeList");
Isolate.WhenCalled(() => fakeItem01.ID).WillReturn(1);
Isolate.WhenCalled(() => fakeWeb.Lists[2].Items).WillReturnCollectionValuesOf(new List<SPItem>
{
fakeItem01
});
Class1 target = new Class1();
target.GetCollection01();
var fakeItemList = fakeWeb.Lists[2].Items;
foreach (SPItem item in fakeItemList)
{
Isolate.Verify.WasCalledWithAnyArguments(() => item.ID);
}
}
Para la prueba unitaria se está usando una combinación de “Natural Mocks” y el nuevo “AAA API” de TypeMocks. Observe un par de puntos específicos:
- Cada objeto “real” necesita un objeto “mockeado”: myWeb -> fakeWeb, myList -> fakeList, etc
- Para cinco líneas de código de trabajo se necesitan 17 lineas de código de prueba
Esto conlleva las siguientes consecuencias generales:
- Para poder crear un objeto “fantasma” (un mock) que sustituya efectivamente al objeto “real” en la clase de trabajo, es necesario conocer explícitamente su construcción. Esto excluye directamente la utilización de TDD: código de prueba debe ser escrito antes del código de trabajo
- Una consecuencia de esta consecuencia es que el código unitario deberá ser escrito por el desarrollador mismo que está escribiendo el código de trabajo: al final, es él/ella el que sabe que está haciendo. El peligro con esta construcción es que se van a escribir clases de prueba que casi siempre van a pasar el examen... voluntaria o involuntariamente, el desarrollador va a omitir las pruebas que tienen más posibilidades de fallar
- Una segunda consecuencia de esta consecuencia es que el desarrollador probablemente utilizara más tiempo creando las clases de prueba que las clases de trabajo
- Por la relación tan estrecha entre código de trabajo y de prueba, cuando se modifica algo en el código de trabajo, hay que modificar también el código de prueba. Es decir, Regression Test es imposible de realizar
El fabricante de TypeMocks está trabajando intensivamente para darle solución a estos problemas, y los primeros resultados van saliendo: ciertas partes del Framework de TypeMocks es capaz de crear mocks para trabajar con Black Box Testing, es decir, entregando un objeto “mockeado” al método de trabajo y revisando los resultados producidos, sin tener conocimientos de su funcionamiento interno.
En cualquier caso, la discusión de si testeo blanco o negro es el mejor, o si Test-Driven Development es realmente valido continuaran hasta el fin de los siglos. Lo importante para nosotros, los que estamos metidos en el lio de hacer que código funcione apropiadamente no son las discusiones teóricas, sino los Frameworks que nos permitan trabajar confortablemente. TypeMocks es hasta el momento lo que más se acerca a una solución viable para hacer testeo de código de SharePoint, así que vale más que la pena de darle por lo menos una mirada e intentar hacerlo funcionar.
Gustavo - http://www.gavd.net/servers/
Escriba un Comentario que me haga reir...
Tuesday, November 04, 2008
#
Como sabéis tanto Gustavo como yo llevamos tiempo realizando pruebas sobre lo que programamos en SharePoint, ambos estamos usando TypeMock como framework para nuestros objetos Mocks que son imprescindibles a la hora de realizar pruebas para SharePoint.
Durante los últimos meses hemos posteado sobre el tema, hemos iniciado un proyecto en CodePlex con un conjunto de clases envoltorio que pueden ayudarnos a la hora de realizar las pruebas con TypeMock y que está a un tris de quedarse obsoleto.
Antes de continuar me gustaría hacer una pequeña recapitulación sobre algunos puntos y características que nos ofrece TypeMock a la hora de realizar pruebas para SharePoint.
Veamos un sencillo ejemplo, para probar el código siguiente:
public Guid SampleGetSiteID()
{
Guid siteID = Guid.Empty;
using(SPSite site = new SPSite("http://moss"))
{
siteID = site.ID;
}
return siteID;
}
En este código estamos usando un objeto SPSite que no podemos sustituir a priori de modo que de cara a probar esto es un problema.
TypeMock, lo resuelve permitiéndonos crear simulaciones de clases de objetos antes de que estas se usen, después TypeMock, sustituirá la instancia real con una instancia de la clase simulada que hemos creado.
Para probar el código anterior podemos hacer lo siguiente:
[TestMethod]
public void SampleGetSiteID_ReflectiveMock()
{
MockManager.ClearAll();
MockManager.Init();
Guid expectedId = Guid.NewGuid();
Mock<SPSite> mockFutureInstanceOfSPSite = MockManager.Mock<SPSite>(Constructor.Mocked);
mockFutureInstanceOfSPSite.ExpectGetAlways("ID", expectedId);
Samples target = new Samples();
Guid resultId = target.SampleGetSiteID();
Assert.AreEqual(resultId, expectedId);
}
Mock<SPSite> mockFutureInstanceOfSPSite = MockManager.Mock<SPSite>(Constructor.Mocked) se encarga de mockear (simular) la clase SPSite al usar Mock<SPSite> estamos definiendo una clase simulada que será reemplazada en el momento de su uso (nos estamos anticipamos).
Vemos también como hemos fijado la propiedad mockFutureInstanceOfSPSite.ID por medio de mockFutureInstanceOfSPSite.ExpectGetAlways("ID", expectedId); para que devuelva expectedId.
En el momento en que se ejecuta la prueba TypeMock se encargará de sustituir la solicitud new SPSite("http://wsses") con nuestro mockFutureInstanceOfSpSite. Y cuando se solicite la propiedad ID del SPSite se devolverá el valor que hemos establecido para la propiedad “ID” en la expectativa.
Esta propiedad se establece de forma reflectiva (TypeMock usa reflexión para establecer este valor), de esta forma también podemos crear simulaciones de clases de objetos que tienen constructores privados así como establecer campos “privados ó internos” de la clase que estamos mockeando (simulando); De esta característica surge el nombre de “Reflective Mocks”
Pero aún hay más, en este caso hemos creado la simulación, y le hemos establecido una expectativa, esto es que lo que esperamos realmente es que exista una llamada a la propiedad ID del SPSite.
Para comprobar que esa expectativa se ha cumplido, es decir que realmente se ha hecho la solicitud, podemos añadir el atributo [VerifyMocks] a nuestra prueba o bien añadir MockManager.Verify() al finalizar la prueba.
Con esto TypeMock, comprobara que efectivamente se ha hecho la llamada.
Para verlo funcionar podemos establecer:
mockFutureInstanceOfSPSite.ExpectGet("HostName", "MyHost");
Y como resultado TypeMock
Test method TestProject1.TestSamples2.SampleGetSiteID_ReflectiveMock threw exception: TypeMock.VerifyException:
TypeMock Verification: Method Microsoft.SharePoint.SPSite.get_HostName() has 1 more expected calls
De modo que podemos verificar que nuestro método no ha llamado a HostName como esperábamos.
No se vayan todavía aún hay más
TypeMock tiene una particularidad que creo que ya he comentado en más de una ocasión que es la de poder simular clases de objetos que tienen un constructor privado. Y esto lo hace excepcional. Sobre todo para SharePoint.
Natural Mocks
Por medio de los “Natural Mocks” podemos definir un conjunto de expectaciones, grabarlas y después comprobar si se han llevado a cabo. (Si, esto ya se podía hacer antes) El detalle aquí es que a la hora de fijar las expectativas estas se definen de manera natural pero solo dentro de un Recorder, que será el encargado de grabar dichas expectativas.
Vemos como sería la misma prueba usando Natural Mocks
[TestMethod]
public void SampleGetSiteID_NaturalMock()
{
MockManager.ClearAll();
MockManager.Init();
Guid expectedId = Guid.NewGuid();
using (RecordExpectations recorder = RecorderManager.StartRecording())
{
SPSite mockFutureInstanceOfSPSite = new SPSite(string.Empty);
recorder.ExpectAndReturn(mockFutureInstanceOfSPSite.ID, expectedId);
}
Samples target = new Samples();
Guid resultId = target.SampleGetSiteID();
Assert.AreEqual(resultId, expectedId);
}
Como puede apreciarse ahora las expectativas las fijamos sobre el recorder y la sintaxis es natural, ya no necesitamos fijar las expectativas de las llamadas a propiedades ó métodos usando strings, podemos usar directamente las propiedades aprovechando el intellisense;
El otro cambio es que estamos creando una instancia natural de SPSite dentro del recorder; TypeMock la usará luego para la sustitución. Como es obvio, es más Natural.
Como inconveniente, en los mocks naturales no podemos fijar expectativas para los campos “privados o internos”.
Bien, hemos empezado con algo que a parecía complejo por el hecho de tener que sustituir un objeto (SPSite) que se encuentra dentro de un método (SampleGetSiteID) y hemos visto como TypeMock nos permite realizar esa sustitución.
Evidentemente el método (SampleGetSiteID) está fuertemente acoplado a la API de SharePoint, cosa que debemos evitar en la medida de lo posible. Como es lógico esto se ha hecho con el propósito de ejemplo.
Ahora veremos cómo podemos usar las instancias de los objetos simulados en nuestras pruebas.
El código a probar sería el siguiente:
public int SampleGetWebsInSite(SPSite site)
{
int countWebsInSite;
using (SPWeb web = site.OpenWeb())
{
countWebsInSite = web.Webs.Count;
}
return countWebsInSite;
}
En este caso nuestro método necesita un SPSite de modo que para probarlo necesitaremos una instancia de SPSite; Pero SPSite es un objeto un poquito raro, y requiere de una conexión real y de toda la infraestructura de SharePoint para poder instanciarse.
En este caso podemos usar las instancias de los objetos mockeados.
Primero veamos cómo hacerlo usando “Reflective Mocks”
[TestMethod]
public void SampleGetWebsInSite_Test_Reflective()
{
MockManager.ClearAll();
MockManager.Init();
MockObject<SPSite> mockSPSite = MockManager.MockObject<SPSite>(Constructor.Mocked);
MockObject<SPWeb> mockSPWeb = MockManager.MockObject<SPWeb>(Constructor.Mocked);
MockObject<SPWebCollection> mockSPWebCollection = MockManager.MockObject<SPWebCollection>(Constructor.Mocked);
SPWeb webInstance = mockSPWeb.MockedInstance;
SPWebCollection webCollectionInstance = mockSPWebCollection.MockedInstance;
mockSPSite.ExpectAndReturn("OpenWeb", webInstance);
mockSPWeb.ExpectGet("Webs", webCollectionInstance);
mockSPWebCollection.ExpectGet("Count", 5);
Samples target = new Samples();
int websInSite = target.SampleGetWebsInSite(mockSPSite.MockedInstance);
Assert.AreEqual(websInSite, 5);
MockManager.Verify();
}
En este caso, lo que hacemos es crear un MockObject de SPSite, un MockObject de SPWeb, cuya instancia real (mockFutureInstanceOfSPWebCollection.MockedInstance) devolveremos cuando se solicite OpenWeb, un MockObject de SPWebCollection, cuya instancia devolveremos cuando se solicite la colección de webs dentro del sitio y finalmente establecemos el número de elementos que la colección falsificada debe devolver que es 5.
Como es lógico y se aprecia en el código anterior, podemos ver que el orden a la hora de crear los distintos elementos es muy importante para que todo encaje perfectamente.
Una cosa más, fijaros que estamos usando MockObject<SPSite> en vez de Mock<SPSite> esto es debido a que no necesitamos crear el objeto con anterioridad, si no que lo vamos a usar directamente en la llamada a nuestro método.
target.SampleGetWebsInSite(mockSPSite.MockedInstance);
Bien, ahora veremos cómo podemos realizar la misma prueba usando
Natural Mocks
[TestMethod]
public void SampleGetWebsInSite_Test_NaturalMock()
{
MockManager.ClearAll();
MockManager.Init();
SPWeb web = MockManager.MockObject<SPWeb>().MockedInstance;
SPWebCollection webs = MockManager.MockObject<SPWebCollection>().MockedInstance;
using (RecordExpectations recorder = RecorderManager.StartRecording())
{
SPSite site = new SPSite("");
recorder.ExpectAndReturn(site.OpenWeb(), web);
recorder.ExpectAndReturn(web.Webs, webs);
recorder.ExpectAndReturn(webs.Count, 5);
}
Samples target = new Samples();
int websInSite = target.SampleGetWebsInSite(new SPSite(""));
Assert.AreEqual(websInSite, 5);
MockManager.Verify();
}
Lo primero, es que es menos farragoso, lo que hacemos es crear las falsificaciones para las clases SPWeb y SPWebCollection, ambas las usaremos luego.
Dentro del recorder creamos un objeto SPSite, esto falsificara el primer uso que se haga de SPSite y fijaremos las expectativas devolviendo las instancias reales de las falsificaciones. (Nótese la llamada a MockedInstance)
SPWeb web = MockManager.MockObject<SPWeb>().MockedInstance;
web es una instancia de SPWeb, que se ha creado a partir de la falsificación de SPWeb.
Bien, en el momento de crear nuestra prueba estamos llamando a target.SampleGetWebsInSite creando un nuevo SPSite (new SPSite(“”) ) ¿fallara?, NO, no falla, como he dicho antes, TypeMock devolverá una instancia de SPSite que es lo que le hemos dicho dentro del recorder y en cada solicitud site.OpenWeb(), Webs y Count devolverá los valores que hemos fijado en las expectativas del recorder.
Bueno, esto es solo una pequeña introducción al tipo de cosas que nos deja hacer TypeMock, como framework de pruebas para SharePoint, hay mucho, mucho más que encontraréis en los manuales de TypeMock.
Bien, en este punto ambos, Gustavo y yo nos encontramos con el problema de recorrer las colecciones de objetos como Webs, Lists, Users etc... de SharePoint;
Esto origino el proyecto de SPTypeMock con las clases envoltorio que nos ayudaban con el tema de las colecciones pero como he dicho antes esto está a puntito de quedarse obsoleto…
Continuara…
Gustavo - http://www.gavd.net/servers/
Escriba un Comentario que me haga reir...
Monday, November 03, 2008
#
El tercer numero de CompartiMOSS, la revista especializada sobre SharePoint en español acaba de aparecer. Puede encontrar el nuevo número del magazine en http://www.gavd.net/servers/compartimoss/compartimoss_main.aspx como un archivo pdf (para descargar en alta o baja resolución).
En este número:
- Editorial
- Cuando la empresa aprende con MOSS (Juan Andrés Valenzuela Jofré)
- Todo lo que siempre quiso saber sobre stsadm y nunca se atrevió a preguntar (Gustavo Velez)
- Simplificando el uso de datos mediante la utilización de Columnas de Sitio – Parte 1 (Doug Ortiz)
- WorkFlow de aprobación para SharePoint 2007 (Fabián Imaz)
- Microsoft Office SharePoint o Google Sites como herramienta de colaboración, y su potencial para ofrecer una plataforma de productividad corporativa (Luis Du Solier G.)
- Secciones fijas
La idea de la revista es propagar el uso y conocimiento de SharePoint. Todas las personas que trabajan con SharePoint en el mundo hispanohablante están invitadas a participar.
La subsistencia de la revista depende no solo de la aceptación del magazine, sino de los aportes en artículos, ideas, experiencias de todos nosotros. Si desea tomar contacto con los editores, en la revista misma encontrara toda la información necesaria, o escriba sus comentarios directamente a compartimoss@gavd.net.
Gustavo - http://www.gavd.net/servers/
Escriba un Comentario que me haga reir...
Tuesday, October 07, 2008
#
El viernes pasado (03-10-2008) se hizo público el inicio del Grupo de Usuarios de SharePoint en España. El sitio en internet del grupo se puede visitar en htpp://www.suges.es
El propósito del grupo es fomentar la utilización y ayudar en la formación de nuevos usuarios, diseñadores, programadores y técnicos que trabajen con SharePoint. El grupo es de carácter nacional en España, y pretende fomentar la creación de grupos de usuarios locales a lo largo y ancho del país.
Si usted trabaja con SharePoint, o lo utiliza, o tiene algún interés en el producto, visite regularmente el sitio para ver las actividades que se ven a desarrollar. El futuro del grupo depende de la participación de todos los interesados.
Gustavo - http://www.gavd.net/servers/
Escriba un Comentario que me haga reir...
Tuesday, September 09, 2008
#
Hace algo más de un año yo comencé una serie de pequeños artículos en este mismo sitio sobre Pruebas Unitarias para SharePoint (“Mocks, Mocking, Mockers y SharePoint” , “Stubs, Stubbing, Stubbers y SharePoint” y “Morir con las botas puestas o Unit Test con SharePoint”). Después de mucho luchar con el asunto, mi conclusión (temporal) fue que el asunto era entre dificilísimo e imposible.
El tema ha regresado recurrentemente entre tanto. Inclusive hablándolo con Carlos Segura alguna vez, el salió con una forma de hacer Pruebas Unitarias (http://www.ideseg.com/BeginnersGuideToTDWebPartDevelopment.aspx) que en realidad nunca me ha gustado por complicada y “poco elegante” y por no eliminar la dependencia con SharePoint.
De lo que se trata en resumen es de como realizar Pruebas Unitarias para código de SharePoint. El problema es bastante sencillo: es necesario eliminar de una u otra forma las dependencias del código con respecto al API de SharePoint para poder repetir las pruebas una y otra vez sin depender del estado actual del Portal; inclusive, si es posible, sin depender DE NINGUNA MANERA de SharePoint. El método de Carlos se basa en la creación de plantillas para Sitios o Listas que se cargan dinámicamente al principio de la Prueba Unitaria y se destruyen al final. Esto garantiza que se mantenga un estado constante en SharePoint, pero, fuera de ser engorroso y (extremadamente) lento, solo permite probar algunas cosas del API de SharePoint (todo lo que tenga relación con Sitios y Listas), pero no permite hacer pruebas de la parte administrativa, por ejemplo. Y siempre es necesario tener una instalación de SharePoint detrás, con todas las subordinaciones necesarias de URL, configuración de usuarios, etc.
Para eliminar realmente las dependencias es necesario usar Mockers o Stubbers (los artículos mencionados al principio dan una pequeña idea de que son estas dos cosas). Hace un par de semanas, TypeMock, uno de los frameworks para Mockers, ha salido al mercado con una nueva versión que permite mucho más de lo que era posible de hacer anteriormente. Desafortunadamente la herramienta (http://www.typemock.com) no es gratis, pero es posible descargar una versión de prueba de 30 días. El problema para mockear a SharePoint es que muchas (demasiadas) de sus clases son selladas y/o no tienen constructores públicos, por lo que para poder utilizar Mockers “tradicionales” es necesario crear primero Interfaces, y luego mockear la clase indirectamente. Como se podrán imaginar, esto es trabajo imposible de hacer, teniendo en cuenta que el Modelo de Objetos de SharePoint es tan increíblemente extendido.
Pues bien, la nueva versión de TypeMock permite trabajar también con este tipo de clases, lo que facilita el asunto considerablemente. TypeMock viene con diferente tipos de sintaxis, una de las cuales, “Natural Mock” es bastante sencilla de utilizar. El siguiente es un ejemplo idiota, pero que sirven para ver cómo funciona el asunto. Queremos crear una Prueba Unitaria del siguiente método, que simplemente devuelve el URL de la página maestra de un sitio:
public string MethodOne(string SiteUrl)
{
String strReturn = String.Empty;
SPSite mySite = null;
SPWeb myWeb = null;
try
{
mySite = new SPSite(SiteUrl);
myWeb = mySite.OpenWeb();
strReturn = myWeb.MasterUrl;
}
catch (System.Exception ex)
{
strReturn = ex.ToString();
}
finally
{
if (myWeb != null) myWeb.Dispose();
if (mySite != null) mySite.Dispose();
}
return strReturn;
}
Si queremos hacer Pruebas Unitarias sobre este método, necesitamos eliminar la dependencia del SPSite y del SPWeb (no queremos tener que tener una instalación de SharePoint detrás, que probablemente va a cambiar constantemente, por lo que nunca sabremos con certeza que es lo que nos va a devolver). Nuestro método de prueba usando TypeMock y la infraestructura por defecto de Visual Studio sería más o menos:
[TestMethod()]
public void MethodOneTest()
{
using (RecordExpectations recorder = RecorderManager.StartRecording())
{
SPSite mySiteMocked = new SPSite("");
SPWeb myWebMocked = RecorderManager.CreateMockedObject<SPWeb>();
recorder.ExpectAndReturn(mySiteMocked.OpenWeb(), myWebMocked);
recorder.ExpectAndReturn(myWebMocked.MasterUrl, "abcd.master").RepeatAlways();
}
MisObjetos target = new MisObjetos();
string SiteUrl = string.Empty;
string expected = "abcd.master";
string actual;
actual = target.MethodOne(myListMocked);
Assert.AreEqual(expected, actual);
//Assert.Inconclusive("Verify the correctness of this test method.");
}
La parte al principio (alrededor del “using”) es en donde creamos nuestro “Mock”, es decir, allí “falsificamos” lo que SharePoint deberá hacer por su cuenta cuando el código funcione realmente. En el primer renglón se crea una instancia de SPSite; note que no es necesario entregarle un URL para crearla, pues el objeto será de todas formas falso, así que no vale la pena crear algo “real”. El segundo renglón crea un objeto SPWeb utilizando una sintaxis especial para la creación de objetos que serán modificados posteriormente (el objeto SPSite es utilizado solamente como referencia, pero no será modificado). La tercera línea le indica al mockeador que el objeto SPWeb creado corresponde al objeto que puede encontrar en el objeto SPSite.OpenWeb. Finalmente la cuarta línea simplemente le asigna un valor a una propiedad del objeto SPWeb (el nombre de su Pagina Maestra).
Las líneas siguientes son generadas automáticamente por Visual Studio, y lo único que es necesario de modificar es el valor esperado. Lo que ocurre al ejecutar la Prueba Unitaria es muy sencillo: el framework de TypeMock le “hace creer” al código que tiene un objeto SPSite y otro SPWeb y ejecuta el método con esos objetos. Esto es sencillo de explicar de esta manera, pero “por debajo de la mesa” ocurren muchas otras cosas que no tienen importancia para el caso dado.
Pues bien, estas son las conclusiones:
Las buenas noticias: Este nuevo framework hace posible crear Pruebas Unitarias para SharePoint. Punto.
Las malas noticias 01: Se ha dado cuenta que para tres renglones de código “de trabajo” se necesitan cuatro líneas de código “de prueba”? Y un ejemplo más sencillo simplemente no me he podido inventar. La realidad es que es necesario mockear cada uno de los objetos utilizados, lo que rápidamente conlleva a que el método de prueba sea más largo (y hasta complicado) que el método a probar.
Las malas noticias 02: Probablemente por mí propia ineptitud, estoy teniendo enormes problemas al intentar mockear colecciones de objetos. Me he dado cuenta que los problemas ocurren porque necesito implementar una Interface IEnumerator que parece que SharePoint utiliza de uno u otra rara manera... en cualquier caso, si intento mockear un SPListCollection, por ejemplo, siempre termino en el basurero de los errores terminales...
Coletilla: Probablemente seguiré escribiendo sobre el asunto por un par de artículos más. Si a alguien le da la rara idea de experimentar con este (apasionante) asunto, por favor, envíenme un E-mail, y de pronto entre todos encontramos soluciones a los problemas que se ven venir...
Gustavo - http://www.gavd.net/servers/
Escriba un Comentario que me haga reir...
Friday, September 05, 2008
#
El 11 de noviembre de 2008 se realizará el Primer Simposio Latinoamericano de SharePoint en San Jose de Costa Rica.
Las inscripciones están abiertas, y el cupo es limitado, así que si desea participar se debe dar prisa. Información sobre formas de inscripción y más detalles puede encontrar en el sitio de Ricardo Muñoz (http://mundomoss.blogspot.com/2008/09/primer-simposio-lationamericano-de.html)
Gustavo - http://www.gavd.net/servers/
Escriba un Comentario que me haga reir...
Wednesday, September 03, 2008
#
Y como se ve SharePoint en Chrome, la nueva invención de Google?
Igual a como se ve en Internet Explorer 8 (Beta 2):
Investigación no científica realizada en 10 minutos:
Se ve alguna diferencia?
- No
Es más rápido?
- No (tal vez una fracción de un milisegundo más rápido, pero es imposible de medir [lo he intentado sin éxito])
Usa menos memoria?
- No. Para mostrar una pantalla, Chrome usa tres procesos de 10.192 K, 30.400 K y 20.240 K (más de 60.000 K en total) y IE con la misma pantalla usa uno solo de 50.512 K
Alguna otra diferencia?
- La conocida diferencia de la consola de configuración de WebParts: Chrome la muestra de la misma forma que FireFox, pero tiene la misma funcionalidad que IE.
Conclusión:
O SharePoint lo hace muy bien, o Google no lo hace tan mal...
Gustavo - http://www.gavd.net/servers/
Escriba un Comentario que me haga reir...
Monday, August 25, 2008
#
Hace un par de días Microsoft ha liberado una lista de chequeo para aceptación de código de SharePoint, y lo primero que he pensado es: hmmm... Microsoft le está entregando un garrote mas a clientes de esos pesados que todos conocemos, que no hacen más que discutir sobre cosas de las que no tienen ni idea apoyándose en información de la que no entienden ni jota...
El nombre en ingles del articulo es “Sample code acceptance checklist for IT organizations”, y lo puede encontrar en http://technet.microsoft.com/en-us/library/cc707802.aspx (on-line) o en http://go.microsoft.com/fwlink/?LinkId=125134&clcid=0x409 en formato Word. Un extracto en español lo puede encontrar en http://www.gavd.net/servers/sharepointv3/spsv3_item.aspx?top=0&itm=725. La lista esta divida en secciones (Seguridad, manejo de sesión, etc) y diciendo la verdad, me parece que hay algunos puntos interesantes para tener en cuenta, pero muchos caben simplemente en las “buenas prácticas” de cualquier software, no solamente de software para SharePoint, y algunas son simplemente o no realizables, o totalmente subjetivas.
Veamos, alguien sabe que es “IOSec”? estupendo que tantos levanten la mano... yo no tenía ni idea hasta que estuve googleando al respecto. IOSec es una librería para evitar vulnerabilidades de cross-site scripting (http://blogs.msdn.com/ace_team/archive/2006/03/13/550687.aspx ), que en realidad, me parece a mí, hace el mismo papel que la bien conocida clase SPEncode de WSS, es decir, codificar caracteres “peligrosos” como “<” y “>” en su equivalente de HTTP, de tal forma que no se puedan usar para inyectar scripts. Por supuesto, es una buena regla de conducta, pero supongo que es una de las primeras cosas que se aprenden a usar cuando estas programando para SharePoint... Lo mismo se puede decir de cosas tan obvias como no usar claves sin encriptar en el web.config o en cookies o en cualquier otro sitio que se pueda ver fácilmente.
Y ya que vamos por ese lado, usted que prefiere: ISO-8859-1 o UTF-8? Bueno, otra de las cosas con las que nos van a dar garrote cuando estemos entregando el famoso código. La lista recomienda usar ISO, pero lo chistoso es que todos los archivos de SharePoint, creados por Microsoft mismo, usan UTF-8. Y en cuanto a mí, si quiere quitarse los problemas de encima cuando está usando caracteres fuera la tabla ASCII extendida, no le queda más remedio que usar Unicode... a ver como se lo explicamos a nuestros clientes...
Y en cuanto a explicar, el tiempo que nos va a costar explicar porque código de validación está o no está en el lado del cliente... La lista recomienda: “Seguridad no se debe basar en validación en el lado del cliente. En lugar de esto, validación debe ser hecha al lado del servidor”. Esta es una de esas cosas que cada uno hace según su propio juicio, y que no siempre es explicable el porqué. Validaciones complicadas, en donde hay que validar contra diferentes fuentes es imposible de hacer al lado del cliente; en validaciones “comunes y corrientes”, como por ejemplo si la entrada es un numero o no, no tiene sentido hacer todo un viaje al servidor para ser realizadas, con un simple validador en el cliente es suficiente. De acuerdo, de acuerdo, ya sé que validaciones al lado del cliente pueden ser anuladas en el navegador mismo, pero atrapándo la excepción que se va a generar en el servidor es suficiente, pues sabemos (y nuestro cliente tiene que saberlo también) que para usar a SharePoint, el navegador tiene que tener el motor de Java activado... En cualquier caso, si quiere ser paranoico, valide en los dos lados, aunque yo diría mejor que hay que ser pragmático, confiar en el buen juicio del programador y rezar un par de padre nuestros a su dios favorito...
Regresando a la lista, hay algunas cosas que son incomprensibles; un buen ejemplo: “The design addresses potential canonicalization issues”. Fuera de que “canonicalization” es prácticamente impronunciable, la oración en realidad no dice nada más que “el diseño tiene que cumplir ciertas especificaciones”, sin especificar las especificaciones a especificar... otro de esos garrotes con los que nos pueden machacar la cabeza por delante o por detrás, pues no está especificado...
En cualquier caso, si le quedan cinco minutos libres, dele una leída a la lista, y, sobre todo, tenga en cuenta algunos de los puntos que menciona. Pero al final, todo este rollo es solamente para pedirles el favor de que guarden el secreto muy bien guardado y no le cuenten a nadie que esta lista existe, no sea que alguno de mis clientes se la lea, y se me ponga pesado cuando vaya a recibir el código del proyecto...
Gustavo - http://www.gavd.net/servers/
Escriba un Comentario que me haga reir...
Wednesday, August 13, 2008
#
Andando por aquí y por allá en la red, mientras espero que SQL haga el upgrade de 2005 a 2008 (hasta ahora sin problemas) en uno de mis servidores de SharePoint, me he encontrado el “Manual de Campo de Sabotaje Simple”, preparado por los Servicios Estratégicos del ejército norteamericano durante la segunda guerra mundial (enero 17 de 1944), http://www.gutenberg.org/etext/26184. Fuera de ser gracioso para leer, y también muy útil si esta en el medio de una guerra y quiere hacer el mayor daño posible sin ser atrapado (“sature una esponja con solución de azúcar; comprímala en una bola, enróllela con una cuerda y déjela secar. Remueva la cuerda cuando este seca y tirela por un sanitario; la esponja se expenderá gradualmente y trancara la tubería de desagüe”), me ha hecho recordar una de las personas con las que tuve que trabajar en uno de mis últimos proyectos...
Probablemente la parte más interesante del Manual es la sección final: “Interferencia general con organizaciones y producción”. Aunque parezca raro, un saboteador no es el que pone bombas y ataca convoys de trenes, como nos lo han hecho creer los millones de películas de los últimos cien años. El saboteador de verdad trabaja en una oficina como burócrata sin nombre, y le tira constantemente arena a los engranajes de la maquina oficial. Veamos las instrucciones para hacer que las cosas salgan más mal de lo normal:
1. Insista en utilizar los canales oficiales todo el tiempo, no permita que se utilicen vías expeditas
2. Cree todo tipo de “Comités” para “estudiar y considerar la situación”, y haga que los comités sean lo más grande posibles, nunca menos de 5 personas (así no se ponen de acuerdo nunca)
3. Haga relevantes las cuestiones que sean irrelevantes lo más frecuentemente posible
4. Recatee sobre las palabras precisas a utilizar en comunicados, minutas y resoluciones
5. Refiérase a puntos decididos en reuniones anteriores e intente abrirlos para discutirlos de nuevo
6. Siempre recomiende “precaución” e intente que sus colegas se comporten “precavidamente”
7. Siempre exija que las ordenes sean dadas por escrito
8. “No entienda” el trabajo que se le asigne. Pregunte hasta el infinito y, preferiblemente, discuta por escrito al respecto
9. Retrase todo lo más posible. Aunque entienda perfectamente lo que hay que hacer, no lo haga hasta que no haya leído completamente todos los manuales, correspondencia, etc
10. No ordene nuevo material hasta que el antiguo no esté prácticamente terminado y siempre pida material que es difícil de encontrar
11. Cuando asigne tareas a colegas, asigne el trabajo sin importancia primero. Asigne el trabajo sin importancia a sus colegas más capaces y el más importante a los menos capaces
12. Insista en obtener trabajo perfecto en cosas irrelevantes y no sea exigente con cosas relevantes
13. Para bajar la moral, sea complaciente con colegas ineficientes y promuévalos frecuentemente. Discrimine trabajadores eficientes y quéjese habitualmente de su trabajo
Bueno, la lista sigue y sigue, pero me parece que todos reconocemos a alguien en nuestro entorno que satisface por lo menos una de estas recomendaciones...
Y volviendo al proyecto que les contaba al principio, el encargado de manejar el proyecto por la parte de mi cliente era (es) todo un experto saboteador... probablemente se había leído el manual de marras antes de que yo lo hubiera encontrado. Para decidir hasta la más pequeña modificación era necesario organizar una reunión con la mayor cantidad posible de participantes, en la que con toda seguridad se revisarían puntos resueltos con mucha anterioridad (puntos 1, 2 y 5). Era prácticamente imposible hacer las cosas de una manera más eficiente (crear un Job de SharePoint para importar elementos desde un sistema de archivos) pues se debería trabajar con cautela (punto 6). Todo lo que se decidía había que ponerlo por escrito y enviar dos docenas de emails a veinte personas diferentes, de los cuales regresaban 19 pidiendo mayores explicaciones (puntos 7, 8 y 9). Los servidores para producción los pidió una semana antes de la fecha límite para poner todo on-line, y exigía que tuvieran discos duros de 15.000 rpm (punto 10). Junto con un colega estuvimos ocupados literalmente días y días corriendo tablas un pixel hacia la izquierda y cambiando el color de letras a “un gris menos oscuro” (puntos 11 y 12)...
Bueno, mi servidor ha terminado de hacer la migración de SQL a 2008 sin problemas. Inclusive SharePoint está funcionando como si no se le hubiera cambiado la Base de Datos... estupendo. El upgrade me ha aumentado el espacio utilizado en el disco duro en 600 MB... aceptable. A veces Microsoft hace las cosas bien... aunque a veces tenga la extraña idea de que el Manual de Campo de Sabotaje es lectura obligatoria para todos los empleados de Microsoft... probablemente me equivoco...
Gustavo - http://www.gavd.net/servers/
Escriba un Comentario que me haga reir...