Welcome to Clearscreen Blogging Community
This a community of developers and tech-freak bloggers, mainly from Spain but we also accept international bloggers. The languagues we support are English and Spanish and we are open to new bloggers. So if you are interested in joining us, don't hesitate to contact
Latest Posts
Hola! ¿Has llegado por aquí buscando mi blog de tecnología .NET?
Ya no lo tengo en clearscreen, mi blog ahora está en geek.ms:
http://geeks.ms/blogs/etomas
Nos leemos en geeks!!! ;-)
El blog ha sido cambiado de sitio. Por favor, visite el Blog oficial de Gustavo en:
http://geeks.ms/blogs/gvelez/
Gracias,
Gustavo
Me parece curioso este post de Jon Flanders http://www.masteringbiztalk.com/blogs/jon/PermaLink,guid,6119f82a-86c3-4ef2-baee-d4697a479a56.aspx donde nos explica porque ya no posteaba nada sobre BizTalk.
La verdad es que yo mismo veía el fin de BizTalk cercano con la llegada de Dublin, pero eran rumores infundados?? No lo sé, seguramente ha habido un gran debate interno en Microsoft sobre este tema, pero Microsoft sorprendió diciendo que sacaría la versión 2009 (en vez de llamarla R3 como parecía al principio) y tenía intención de continuar este ritmo de releases cada 2 años aproximadamente. Al menos por ahora Microsoft sigue apostando por este producto y a mi me parece buena idea.
En cualquier caso los expertos de BizTalk no tienen porque temer por su futuro, aun si Dublin reemplazara a BizTalk, la experiencia en entornos de integración (correlaciones, enrutamiento basado en contexto, transacciones de larga duración, compensaciones,...) les posicionará mejor que al resto de técnicos. De momento tenemos que estar contentos porque Jon vuelve a hablar de BizTalk en su blog :-)
No hay escusa para no probar las soluciones BizTalk. Es la única forma de garantizar que lo que hemos hecho funciona, nos permite dormir tranquilos :-), evita errores de regresión y nos exime de culpas en muchos casos. La escusa de que es dificil de probar ya no vale, está claro que al principio del desarrollo la curva de esfuerzo será mayor pero un desarrollo pequeño de 2 meses y sólo un desarrollador ya le saca provecho y agilidad, os lo digo por experiencia.
En este caso voy a hablar de un nuevo framework, BizMock, estoy muy relacionado con él, ya que lo utilicé cuando todavía no había salido a la luz, gracias a su creador, Pierre Milet, con quien tuve el placer de trabajar en un proyecto, pude conocer este framework, hacer de beta tester y resolver algún bug, pocos ;-).
Las bondades son muchas, lo importante es que simplemente cambiando los bindings y usando el adaptator BizMock simulas sistemas externos, sin acoplamientos. Lo que va a hacer es seguir los pasos que tú le definas en las pruebas, a través de código c# y a través de lo que se denomina "fluent interface", donde aprovechando el IntelliSense el propio Visual Studio nos dice las posibilidades que tenemos simulando una escritura natural.
Se puede incorporar en los procesos de Integración Continua, donde, una vez compilado y desplegado automáticamente, se lanzan estos tests a modo de pruebas unitarias de nuestras orquestaciones.
Volvemos al tema de la agilidad, hay que automatizar tareas, como desarrolladores teneis que promoverlo, desarrollar soluciones BizTalk no requiere de mucho esfuerzo de desarrollo, pero sí de muchas tareas repetitivas que nos llevan mucho tiempo a la larga, compilación, despliegue, bindings, pruebas manuales,... Tampoco vale la escusa de que en tu empresa no montan Team Foundation, todos sabemos que msbuild lo puedes ejecutar en local, y encima, mucho del trabajo está hecho, para BizTalk hay tareas msbuild que te permiten hacer practicamente cualquier cosa.
Os animo a usar estos frameworks y a automatizar vuestras tareas, me lo agradecereis ;-)
Aqui os dejo los enlaces:
http://blogs.msdn.com/pierreml/archive/2009/02/13/bizmock.aspx
http://www.codeplex.com/bizmock
Saludos,
Tomás
Ayer fue mi primer día desde hace 2 años en el que ya no soy MVP. Ha sido un año lleno de cambios profesionales, he cambiado de empresa, he dejado el desarrollo, la consultoría, la formación, las ponencias y hoy el MVP... Ahora estoy en infraestructura de sistemas de producción, en cliente final e intentando mejorar los procesos de puesta en producción, administración, pruebas de carga y resolución de problemas in situ, desde dentro de una empresa y gestionando equipos de trabajo repartidos por todo el mundo, todo un reto para mi, y para mi inglés jejeje. Otro de mis objetivos desde hace un tiempo ha sido equilibrar mi vida profesional y personal, antes estaría en un 70 - 30 y ahora intento que sea un 50 - 50.
Como dije hace un tiempo la vida son ciclos. En este nuevo ciclo mi participación y ayuda a la comunidad no la he priorizado y por tanto Microsoft nombrará a otro que haya hecho más méritos, lo tenía claro desde hace tiempo. Esto hace que sea un reconocimiento muy muy valorado, por la dificultad de conseguirlo y el esfuerzo necesario para mantener el reconocimiento, tendría que estar remunerado jejejejejeje. Pero esta dificultad me hace estar más orgulloso si cabe.
En cualquier caso estoy muy contento de estos 2 años, han sido un regalo para mí, o más bien un sueño (no regalan nada :-DDD ), ya que hace 10 años iba a charlas de varios mvps y los veía muy lejos y con admiración.
He conocido mucha gente interesantísima, me ha hecho entender muy bien este mercado y mi capacidad y un poco ser dueño de mi destino supongo que gracias al prestigio que te confiere. Saco muchas cosas positivas y yo creo que nada negativo. Y me ha permitido tener la suerte de ir 4 veces a Redmon (Seattle, USA), cuartel general de Microsoft, para interactuar con los equipos de producto y con el resto de mvps.
Esos Summit quedarán en mi recuerdo ;-)
Un saludo
Herramienta de gran utilidad para realizar tests de carga de servicios WCF. Genera el código necesario para realizar pruebas de carga desde VS 2005 y VS 2008.
http://wcfloadtest.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=26377#DownloadId=66052
Saludos.
La verdad es que no me termina de convencer el hecho de utilizar BizTalk para acceso directo a base de datos usando su adaptador de SQL. No me gusta porque crea un acoplamiento muy fuerte.
En un proyecto que estuve se decidió utilizar este adaptador pero cada modificación de los procedimientos almacenados implicaba tener que modificar los esquemas en BizTalk. Personalmente siempre aconsejo dejar claramente definidos los contratos y si se necesita acceder a base de datos hacerlo a través de un componente .Net de manera transaccional, es mucho más fácil de probar de manera unitaria. Hay que tener en cuenta que los procesos BizTalk suelen ser complejos, a veces pueden durar mucho tiempo y se puede producir un error en cualquier punto, cuando realizamos acceso a las bases de datos de negocio es importante tener cuidado para no generar inconsistencias y la mejor forma es hacerlo a través de componentes .net transaccionales, utilizar el tratamiento de excepciones, los bloques de compensación y subcribirte a los mensajes de error.
En cualquier caso os paso un post sobre el nuevo adaptador SQL WCF muy mejorado con respecto al anterior adaptador SQL:
http://www.packtpub.com/article/soa-capabilities-in-bizTalk-wcf
Saludos.
Hace no mucho tiempo tuve el placer de trabajar en un proyecto realizado sobre BizTalk 2006 R2. Fue un proyecto en esencia muy diferente a los que estaba aconstumbrado, ya que se realizó para un hospital de Zaragoza (Mutua de Accidentes de Zaragoza - MAZ). En la práctica, fue un proyecto de integración y se siguieron las mismas técnicas de desarrollo que habiamos realizado en anteriores proyectos: patrones de integración, tests unitarios, tests de integración, automatización de todo el proceso de compilación, despliegue, configuración,...
La problemática a resolver consistía en integrar unos dispensadores de medicamentos robotizados que entendían HL7 con el HIS (Health Information System) del Hospital que no entendía HL7.
En este proyecto pude conocer de primera mano el acelerador HL7, que nos permitió desarrollar con muchísima agilidad.
Una vez acabado el proyecto y subido a producción sin incidencias la guinda fue nuestra participación en el programa TAP de Microsoft para la migración del proyecto a BizTalk 2009, se hizo sin problemas y se convirtió en el primer BizTalk 2009 en Producción de España.
Más detalles en el Case Study realizado por Microsoft: http://www.microsoft.com/spain/biztalk/2009/case-studies.aspx
Saludos.
Sólo le he podido echar un vistazo, me interesa muchísimo porque estoy preparando algo similar. Se trata de 2 videos, de una hora cada uno, donde se pone en práctica la guia para realizar un laboratorio de pruebas de rendimiento para BizTalk con el objetivo de escalar el entorno. Espero que lo disfrutéis.
BizTalk 2009 – End to end performance testing (1/2)
http://channel9.msdn.com/posts/johanlindfors/BizTalk-2009--End-to-end-performance-testing/
BizTalk 2009 – End to end performance testing (2/2)
http://channel9.msdn.com/posts/johanlindfors/BizTalk-2009-End-to-end-performance-testing-22/
Y esta es la guia que os comento:
Managing a Successful Performance Lab
http://www.microsoft.com/downloads/details.aspx?FamilyID=60e8c48e-2139-40d0-98fa-78233b3b64cf
Saludos.
Desde mi nuevo punto de vista, desde infraestructura, ciertamente las preocupaciones son diferentes al desarrollo de soluciones BizTalk. Desde desarrollo nos preocupamos de una correcta arquitectura, extensibilidad, rendimiento,... Infraestructura es otro cantar, lógicamente un entorno de producción requiere hacer chequeos diarios, mensuales y anuales del sistema, la mayor preocupación es la salud del sistema, la recuperación ante desastres, redundancia, balanceo, alta disponibilidad...
Para ayudar a esos administradores de sistemas BizTalk existen una serie de utilidades, usadas por los propios ingenieros de soporte de Microsoft:
PAL(Performance Analysis of Logs Tool) http://www.codeplex.com/PAL: Para analizar los logs de contandores de rendimiento, incluye un juego de contadores especialemente seleccionados para BizTalk. Genera un informe con los resultados, coloreados según el grado de riesgo.
BizTalk Best Practices Analyzer http://www.microsoft.com/downloads/details.aspx?familyid=dda047e3-408e-48ba-83f9-f397226cd6d4&displaylang=en: Hace un estudio de la instalación y configuración de BizTalk.
LoadGen http://www.microsoft.com/downloads/details.aspx?FamilyID=c8af583f-7044-48db-b7b9-969072df1689&DisplayLang=en: Herramienta para generar carga y poder realizar tests de rendimiento.
PssDiag: Viene incluida una versión específica para BizTalk con el DVD del producto. Es una herramienta de diagnóstico de errores de base de datos y problemas de rendimiento
MsgBoxViewer http://blogs.technet.com/jpierauc/pages/msgboxviewer.aspx: Otra fantástica herramienta de diagnóstico, con queries personalizables y reglas.
SCOM http://www.microsoft.com/systemcenter/opsmgr/: Bueno es un producto, pero vital para administrar un entorno BizTalk, gracias a su Management Pack específico para BizTalk
Y como recursos a destacar:
BizTalk Server Documentation: http://msdn.microsoft.com/en-us/biztalk/aa937673.aspx
Managing and successful performance Lab: http://www.microsoft.com/downloads/details.aspx?FamilyID=60e8c48e-2139-40d0-98fa-78233b3b64cf
BizTalk Server Operations Guide: http://www.microsoft.com/downloads/details.aspx?FamilyID=5251F103-329D-4F8D-95B5-64F99F2F6DFC
Installing and Configuring BizTalk Server in a Multi Computer Environment: http://www.microsoft.com/downloads/details.aspx?FamilyID=df2e8a88-fb23-49a4-9ac7-d17f72517d12
BizTalk Server Performance Optimization: http://www.microsoft.com/downloads/details.aspx?FamilyID=98ecf11a-9a8e-4939-8cef-2bc5536dc792
Saludos.
Y os preguntareis, qué .... tiene que ver BizTalk 2009 y XBox 360??... En principio nada :-P pero teniendo en cuenta que BizTalk es un integrador y ajusta perfectamente en escenarios típicos de cadenas de suministros, ehhh bueno y un detalle sin importancia, que Microsoft es el creador de ambos productos, pues blanco y en botella:
http://www.microsoft.com/casestudies/casestudy.aspx?casestudyid=4000004118
Saludos.
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...
Nuestro compañero Saravana Kumar ha hecho un magnífico trabajo al recopilar, a modo de documentación de producto, los posts de los bloggers de BizTalk más importantes. Está organizado practicamente igual que la documentación del producto y cuenta con un buscador.
Aqui os dejo el enlace:
http://blogdoc.biztalk247.com
Saludos.
Hola de nuevo, ya hace tiempo que no posteo, la verdad es que he estado algo liado y desconcentrado, ya que he cambiado de empresa hace 2 semanas. Sí, asi es, he dejado ilitia después de 4 años, estos años han sido muy intensos, los más intensos de mi vida profesional y donde saco un balance muy positivo. La vida son ciclos y creo que era el momento de empezar uno nuevo con ilusiones renovadas.
Ahora paso a formar parte del Grupo Santander como responsable de infraestructura BizTalk a nivel corporativo. Todo un cambio, desde el punto de vista técnico, ya que he cambiado el desarrollo y arquitectura por infraestructura, y tambien desde el punto de vista de responsabilidad.
Desde que empecé con BizTalk hasta la fecha he pasado por todas las fases del desarrollo de soluciones, desde la toma de requisitos, estimación de recursos y tareas, diseño de arquitectura, desarrollo, automatización de builds y pruebas, test funcionales, subidas de entorno, hasta la mejoras de rendimiento. Ahora tengo la oportunidad de mejorar los procesos desde punto de vista de sistemas realizando estándares corporativos y, probando y proponiendo herramientas, productos, técnicas... Creo que es enriquecedor en este aspecto, aunque está claro que no es una tarea sencilla.
Y nada, os seguiré contando mis impresiones sobre este mundillo como hasta ahora,...
Saludos.
Muy interesante el uso de Oslo y su lenguaje "M" para generar un lenguaje mucho más "friendly" que nos crea los scripts de despliegue msbuild.
http://www.sabratech.co.uk/blogs/yossidahan/2009/03/oslo-based-solution-for-deploying.html
Me empieza a gustar Oslo :-DDDDDD
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...
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...
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.
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...
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...
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...
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...
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...
Pues eso parece. BizTalk en su versión 2009 no tiene HAT propiamente dicha. Su funcionalidad ha sido incluida en la Consola de Administración, buena noticia sin lugar a duda ya que desde la esta Consola podremos resolver cualquier incidencia, consultar instancias en ejecución y consultar el tracking. Quedarán reminiscencias de la HAT ya que la depuración de una orquestación nos abrirá la misma pantalla que estábamos acostumbrados, pero eso es lo de menos.
De esta manera se nos hace mucho más fácil, por ejemplo, buscar una instancia procesada en una fecha determinada:
Anteriormente se tenía que hacer de esta manera http://blogs.clearscreen.com/tomas/archive/2007/01/15/5969.aspx
Saludos.
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...
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...
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...
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...
Con la versión final de Silverlight 2.0 pensaba que aparecería algun control de más que hemos echado en falta durarnte el periodo de Betas y demás. Por suerte en codeplex http://www.codeplex.com/Silverlight tenemos un set de controles típicos ya desarrollados.
Ha fecha de hoy existen dos conjuntos de controles, controles estables para ser usados tranquilamente y controles en pruebas:
En pruebas
AutoCompleteBox NumericUpDown Viewbox Expander ImplicitStyleManager Charting
Estables
TreeView DockPanel WrapPanel Label HeaderedContentControl HeaderedItemsControl
A disfrutarlos pues :)
Volvemos a esta serie de posts relacionados con problemas que nos podemos encontrar a la hora de migrar una aplicación Silverlight Beta 2 a la versión final. En este caso supongamos que tenemos una aplicación silverlight con el siguiente código Xaml:
1: <Grid x:Name="LayoutRoot">
2: <Image Margin="0,0,0,0" Source="Images/background.jpg" Stretch="Fill" />
3: <Labs:Control1 HorizontalAlignment="Stretch" VerticalAlignment="Stretch"/>
4: <Labs:Control2 Height="92.719" HorizontalAlignment="Left" Margin="8,8,0,0" VerticalAlignment="Top" Width="176"/>
5: <Labs:Control3 x:Name="mainMenu" HorizontalAlignment="Right" VerticalAlignment="Top"/>
6: </Grid>
Donde cada UserControl Control contienen un botón que responde al evento MouseLeftButtonUp.
¿Qué ocurre si migramos esta aplicación a la versión final de silverlight? Pues ocurre que no ocurre nada, es decir, por mucho que apretemos el botón izquierdo del ratón sobre el botón, contenido en cada control, no ocurre nada.
El por qué lo tenemos en el tipo de panel que contiene la imagen y los tres controles de usuario. ¿No veis que falte algo? Pues sí, no están definidas las filas ni las columnas. Otro de los problemas de la Beta 2 en cuenta a permisividad. Por tanto añadiendo la definición de filas y columnas y definición que parte del Grid ocupa cada objeto, el código fuente resultante y funcional seria el siguiente:
1: <Grid x:Name="LayoutRoot">
2: <Grid.RowDefinitions>
3: <RowDefinition Height="100"/>
4: <RowDefinition Height="*"/>
5: </Grid.RowDefinitions>
6: <Grid.ColumnDefinitions>
7: <ColumnDefinition Width="180"/>
8: <ColumnDefinition Width="*"/>
9: </Grid.ColumnDefinitions>
10: <Image Margin="0,0,0,0" Source="Images/background.jpg" Stretch="Fill"
Grid.Column="0" Grid.Row="0" Grid.RowSpan="2" Grid.ColumnSpan="2"/>
11: <Labs:Control1 HorizontalAlignment="Stretch" VerticalAlignment="Stretch"
Grid.Row="0" Grid.Column="0" Grid.RowSpan="2" Grid.ColumnSpan="2"/>
12: <Labs:Control2 Height="92.719" HorizontalAlignment="Left" Margin="8,8,0,0"
VerticalAlignment="Top" Width="176" Grid.Column="0" Grid.Row="0"/>
13: <Labs:Control3 x:Name="mainMenu" HorizontalAlignment="Right" VerticalAlignment="Top" Grid.Row="0" Grid.Column="1"/>
14: </Grid>
Ahora si que funcionan nuestros botones :)
Migrando y migrando aplicaciones, demos y demás que tengo por aqui en Silverlight Beta2 a la versión final, me he encontrado con problemas en tiempo de ejecución con un error que asusta al principio pero que investigando un poco se encuentra el por qué del mismo. El mensaje de error es: Catastrophic failure (Excepción de HRESULT: 0x8000FFFF (E_UNEXPECTED)), el cual lo podemos ver en la siguiente imagen.
El problema viene dado en la permisividad que nos daban las versiones Beta de Silverlight, a la hora de añadir elementos al diccionario de recursos de un elemento de tipo FrameworkElement. Es decir, el siguiente código fallaría una vez migrado a Silverlight 2.0:
Storyboard Story = new Storyboard();
DoubleAnimation da = new DoubleAnimation();
da.To = -200;
da.Duration = TimeSpan.FromSeconds(20);
Story.Children.Add(da);
LayoutRoot.Resources.Add(null, Story);
Y la solución pasa por dar un valor correcto al parámetro key:
Storyboard Story = new Storyboard();
DoubleAnimation da = new DoubleAnimation();
da.To = -200;
da.Duration = TimeSpan.FromSeconds(speed);
Story.Children.Add(da);
LayoutRoot.Resources.Add("story", Story);
Ahora que ya tenemos Siverlight 2.0 en la calle, nos podemos animar a desplegar nuestra aplicación a nuestros servidores, empresas de hosting y demás donde tengamos nuestros sites alojados. ¿Qué puede ocurrir casi siempre?, que no tengamos bien configurados los MIME Types y por tanto al intentar ejecutar la aplicación una vez desplegada tengamos el siguiente error que se ve en la imagen:
La solución pasa por añadir los siguientes MIME Types necesarios para hacer funcionar nuestra aplicación Silverlight:
.xap - application/x-silverlight-app
.manifest - application/manifest
.xaml - application/xaml+xml
.dll - application/x-msdownload
.application - application/x-ms-application
.xbap - application/x-ms-xbap
.deploy - application/octet-stream
.xps - application/vnd.ms-xpsdocument
En el PDC nos explicarán un poco más lo que será Oslo y de qué se compone, pero ya nos dán unas pinceladas.
Oslo se compondrá de 3 herramientas: un diseñador gráfico, llamado "Quadrant", un leguaje de modelado llamado "M", para especificar DSLs y modelado de datos, y un repositorio relacional que permite que los modelos disponibles sean accesibles desde otras herramientas y componentes .Net.
Oslo incluye soporte para UML, BPMN y BPEL a través del diseñador gráfico y almacena todos los artefactos y diagramas conceptuales en una base de datos SQL Server.
A los desarrolladores sólo nos queda esperar un poco para poder disfrutar de Oslo y ver con nuestros propios ojos como Microsoft resuelverá el diseño de arquitecturas basadas en modelos.
Un saludo.
Windows Presentation Foundation esta siendo tomado más en serio para la creación de aplicaciones cliente ricas a nivel empresarial, diferenciadoras y pensadas en el usuario final (aqui me diran que siempre se piensa en el usuario final y yo digo que tararí!!). Bueno a lo que vamos, nos piden que desarrollemos una aplicación con WPF que mejore la interfaz de usuario, experiencia del usuario, y en ocasiones su productividad (provocando acciones naturales que redundan en facilidad y rapidez de uso), y lógicamente que mantenga la funcionalidad de la aplicación predecesora.
Estamos en un escenario real, el cual ya no es una aplicación piloto sencillita realizada por dos o tres personas, sino una en la que necesitamos la participación de un equipo de desarrollo o varios, trabajando conjuntamente y bien orquestados. Aqui es donde entran los chicos del equipo de patterns & practices que han desarrollado una serie de recursos que facilitan precisamente esto que hemos planteado, el desarrollo de aplicaciones WPF modulares donde intervienen varios equipos ayudando a los arquitectos de software a plantear una arquitectura modular, escalable y donde la nueva funcionalidad sea sencilla de añadir.
Entre los activos que tenemos disponibles destacan:
- Una guía explicativa donde se centran en diferentes aspectos de arquitectura
- Hands-on-Lab
- Ejemplo de aplicación WPF utilizando estas prácticas
- Framework arquitectural
La dirección de principal de codeplex es la siguiente: http://www.codeplex.com/CompositeWPF
Mas información
.png)
El pasado julio, Carson Hager, el presidente y fundador de Cynergy empresa dedicada al desarrollo RIA con Adoble Flex/Air y Microsoft Silverlight/WPF, nos cuenta pequeños detalles de una comida organizada en la Microsoft Worldwide Partner Conference donde participó el propio Steve Ballmer.
De sus palabras escritas se extraen dos interesantes puntos:
- Que Microsoft está trabajando muy duro para ponerse a la par (y superar si puede) el trabajo realizado en el mundo Adobe y reproducirlo en el mundo Microsoft.
- Las altas instancias de Microsoft creen y por tanto apostarán, por que el diseño de software dirigido hacia la mejora de la experiencia del usuario será el futuro del desarrollo de software.
Yo también opino que el año próximo será muy interesante en el mundo UX.
PD: Que pena que Cynergy no este en España :)