Yo gano, tu ganas, yo gano, yo gano, yo gano…

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…

Cuanto hardware necesitamos para este portal de SharePoint? Hmmm… Depende…

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…

Modelar, Vistear, Controlar o el MVC con SharePoint

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…