SkunkWorks

Esta semana se está realizando la primera Conferencia Europea de SharePoint en Berlín, Alemania (http://www.sharepoint-conference.eu/). Tres días viendo, oyendo y tratando de asimilar lo que está pasando y va a pasar con SharePoint, las intenciones de Microsoft con el producto, y lo que piensan usuarios, partners y fabricantes al respecto. Los últimos dos días de la semana estarán dedicados completamente a Groove.

La primera sorpresa de la Conferencia ha sido que no hay conexión de Internet en el centro de conferencias ni el hotel en donde están todos los participantes (iba a decir víctimas, pero me arrepentí al último momento). Ya se podrán imaginar a dos mil y tantos computador-idiotas, que duermen con el LapTop debajo de la almohada, que tienen que vivir una semana sin E-mail ni Internet… La vida ha sido casi que insoportable, y más de uno/a ha estado teniendo ideas raras sobre acelerar el momento de encuentro con el Dios de SharePoint en el Wallalla del software…

Fuera de oír mucha información sobre cosas ya muy conocidas, algunas conferencias que siempre valen la pena (Mike Fitzmaurice, Patrick Tisseghem ), probablemente lo más interesante para contar por estos lados es lo poco que se ha podido saber sobre los planes de Microsoft con SharePoint.

Como ya es sabido, SharePoint es el producto de Microsoft con el crecimiento más acelerado de toda la empresa. Hasta el momento han sido vendidas 80 millones de licencias, y Microsoft todavía sigue teniendo el record de la instalación mas masiva de todos los 80 millones: la intranet de Microsoft misma funciona con SharePoint 2007, y contiene 352.000 sitios con 12 Terabytes en información; también hay aproximadamente 1000 partners de Microsoft escribiendo aplicaciones especialmente para SharePoint, algunas de ellas genéricas, y la mayoría para satisfacer requisitos específicos.

Los planes de Microsoft para SharePoint no han cambiado: WSS y MOSS seguirán siendo el punto central de almacenamiento e intercambio de información, y la integración con el resto de los productos de Microsoft solamente va a ser ampliada: con los productos que faltan de Office (Visio, por ejemplo) se realizara en la próxima versión de Office, y con los servidores (especialmente los del grupo de Dynamics, como Navision) será cada vez mas estrecha en la próxima versión o revisión.

Microsoft está trabajando desde hace ya algunos meses (no han dicho cuantos) en la nueva versión de SharePoint, que permitirá una mejor escabilidad (crecer «horizontalmente», es decir, mas usuarios o carga de información, un servidor extra en la granja y solucionado el problema) y en la mejora e integración de herramientas para desarrolladores. Además, están trabajando en la mejora de algunas cosas que desde el principio eran patentes, como el poder crear Catálogos de Datos Empresariales de «dos vías» (que no solamente permitan ver datos externos, sino también modificarlos), y en la mejora y expansión del modelo utilizado por el Catalogo.

Por supuesto, la información al respecto no ha sido muy extendida, siguiendo con la política de Microsoft de mantener los proyectos nuevos en secreto a lo que ya nos vamos acostumbrando (desafortunadamente), pero es muy claro que la próxima versión, lo mismo que la próxima versión de Office (versión 14, no 13) será más una evolución que una revolución. Probablemente incluirá mejoras en algunos de los aspectos que no funcionan muy bien en el momento, como la integración de Groove con SharePoint, pero de eso se oirá más en los próximos días.

Y, sobre todo, la mayor mejora a esperar, y que no es muy difícil de realizar, es que en la próxima conferencia se pueda tener una conexión de internet…

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

Axioma: Malos programadores hacen huecos en la seguridad del software, y buenos programadores los encuentran y los explotan. . . Así que cual es peor?

Sujeto: El Modelo de Objetos de SharePoint 2007

Paradigma: Buscando en los rincones escondidos del nuevo Modelo de Objetos de SharePoint 2007, he encontrado una propiedad que permite mostrar en pantalla la contraseña (password) del administrador. Todo lo que se necesita es 4 renglones de código:

    SPWebApplicationCollection CollectionApplicationsWeb = SPWebService.ContentService.WebApplications;
    SPWebApplication oneApplicationWeb = CollectionApplicationsWeb[«SharePoint – 80»];
    SPApplicationPool myAppplicationPool = oneApplicationWeb.ApplicationPool;
    Console.WriteLine(«Yo soy ‘» + myAppplicationPool.Username + «‘ y mi clave es ‘» + myAppplicationPool.Password + «‘»);

Y el resultado es … espeluznante:

(Note que la contraseña está protegida por todas partes, inclusive en la pantalla de IIS, desde donde ni siquiera se puede copiar con ctl+c, como el aviso indica).

Postulado: este es un hueco de seguridad más grande que el que tiene el monte Erebus (a que nadie sabe en donde queda el monte Erebus… no lo busquen, yo se los cuento: es en donde esta Appassionata von Climax en este momento)… estoy pensando que a metidas de pata en software habría que darles nombres como a los huracanes; desde este momento, podemos hablar del «Bug Erebus» para referirnos a esta forma de ver contraseñas de Windows… Además, Erebus fue el hijo de Caos, por lo que el nombre me parece bastante adecuado.

Escolio: A ver cuánto tiempo pasa antes de que un buen programador encuentre la forma de explotar el hueco. Hay un par de barreras a vencer, pero por eso tiene que ser un buen programador. Además, aunque Microsoft se de cuenta que metió las patas (demasiado tarde), y elimine esta propiedad del Modelo de Objetos, ya sabemos que las contraseñas están por ahí, en alguna parte, y simplemente habría que buscarlas un poquito más para encontrarlas.

Corolario: Hay alguien por ahí con línea directa con los dioses en Redmond? Yo les puedo enviar una docena de E-mails contándoles del asunto, pero de todas formas no me van a hacer caso, pero de pronto a alguien con buenos contactos por esas altas esferas si le hacen caso… Fuera de chistes, esto es serio señoras y señores, bastante serio…

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

(7 según Microsoft, y así se evitan leer todo la retahíla –> Ultima actualización: son 8, no siete)

Según las teorías sobre escritura de código, está permitido algo así como un error en cada 100 líneas de código, si no me equivoco, y desde que no sea un error de lógica, pues de esos no queremos ni que nos los mencionen.

Pero cuantos errores puede cometer Microsoft? Hoy he estado probando cosas por aquí y por allá de SharePoint 2007, dándome la oportunidad de mirar con calma el nuevo SDK. Una de las cosas que más me ha llamado la atención de la nueva versión es la posibilidad de exportar sitios completos desde código, así que me fui derecho a la sección correspondiente y empecé a seguir el ejemplo que el SDK muestra. El asunto es tan poderoso, que con 15 líneas de código se puede exportar e importar sitios completos; el código del SDK es el siguiente:

1 using Microsoft.SharePoint.Administration;
2 using MicroSoft.SharePoint.Deployment;

3 SPExportSettings exportSettings = new SPExportSettings();
4 exportSettings.SiteUrl = «http://webname»;
5 exportSettings.ExportMethod = SPExportMethodType.ExportAll;
6 exportSettings.BaseFileName = «exportfile»;
7 exportsettings.FileLocation = @»c:»;
8 SPExport export = new SPExport(SPExportSettings);
9 Export.Run();

10 SPImportSettings importSettings = new SPImportSettings;
11 importSettings.BaseFileName = «exportfile»;
12 importSettings.FileLocation = @»c:»;
13 importSettings.SiteUrl = «http://newweb»;
14 SPImport import = new SPImport(SPImportSettings);
15 Import.Run();

Mi sorpresa (todavía me sorprendo de algo hecho por Microsoft?) es que en 15 líneas de codigo hay siete 8 con errores. Fíjense, por ejemplo en la línea numero 2: ni siquiera los empleados de Microsoft saben escribir el nombre de la empresa correctamente («MicroSoft»). Linea 7 dice «exportsettings», línea 9 dice «Export» (el objeto es «export») y línea 15 dice «Import» (el objeto se llama «import»).

Pero bueno, esos son errores de meter el dedito en el sitio equivocado y de los que el compilador nos avisará que hay algo mal (pero no lo que es). Lo malo empieza a verse en el renglón 10, en donde el objeto «importSetting» utiliza un método como constructor sin paréntesis. Pero eso también se les puede pasar. En donde te quedas sin ganas de seguir es en los renglones 8 y 14, en donde intentan utilizar una clase como parámetro de un constructor… simplemente cerrar e irse a acostar… si esto es el SDK, que esperanzas nos quedan…

PS: Para los incrédulos, el código del SDK se puede ver On-Line (http://msdn2.microsoft.com/en-us/library/ms438819.aspx), con exactamente los mismos errores… Hay alguien por ahí con conexión directa con los dioses en Seattle para que les avise? siete 8 errores en 15 líneas de código es un poquito demasiado…

PS: otro encontrado al ejecutar el código: la exportación produce un archivo con extensión .cmp automáticamente, pero al intentar importarla, en el renglón 11 es necesario utilizar el nombre del archivo Y su extensión, no como el SDK pretende (sin extensión).

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

El 12, 13 y 14 de febrero 2.007 se realizará la primera Conferencia Europea de SharePoint en Berlín (Alemania) https://live.sharepoint-conference.eu/EN/Pages/default.aspx. La Conferencia consistirá de más de 50 lecturas, mesas redondas, y, por supuesto conferencias (de otra forma no sería una Conferencia).

Si alguien va por esos lados, y tiene ganas de tomarse un café y charlar un rato sobre SharePoint, la situación mundial y lo que nos de la gana, con gusto nos podemos ver allí. Envíenme un E-mail, y convenimos un punto de encuentro.

Nota: después de la conferencia oficial hay otro día (15 de febrero) solamente sobre Groove, que puede ser interesante.

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

Esta mañana, en medio de una fila infinita en la autopista, por eso del aburrimiento y por hacer algo más útil que solamente mirar a los otros «knowledge workers» sentados en sus autos esperando a salir de la fila, me he puesto a leer un artículo de Mike Gunderloy («Revolution Time Again«), uno de mis columnistas favoritos.

El articulo habla sobre las revoluciones en desarrollo de software que hemos «sufrido» los últimos años: de DOS a Windows, de 16 a 32 bit, de Visual Basic 3/6 a DotNet. Yo agregaría algunas otras más: mi primer programa fue escrito en Fortran y programado en tarjetas perforadas… probablemente la mitad de las cuatro personas que están leyendo esto no tienen ni idea que es una tarjeta perforada (http://mx.geocities.com/aqilesboy2003/historiadelacomputacion/tipica.html, para que se enteren).

Pero bueno, el articulo se pregunta si vale la pena de meter un montón de esfuerzo en aprender a utilizar y programar con la nueva revolución de software que Microsoft nos está dando con el DotNet 3.0: Windows Presentation Foundation, Windows Communication Foundation, Windows WorkFlow Foundation, Office 2007… porque no darle un vistazo a Apple o al mundo de Unix/Linux, pero, sobre todo a aplicaciones Web.

Hace algún tiempo, en un arrebato de desesperación cuando el SDK de SharePoint 2007 fue publicado por primera vez, fuera de arrancarme los pocos pelos que me quedan en la cabeza, escribí algo por estos lados para sacarme un poquito la frustración (http://blogs.clearscreen.com/skunkworks/archive/2006/06/07/3069.aspx). El API de SharePoint pasó de cuatrocientas y algo clases a 1.260 con un numero que no quiero saber de métodos, propiedades y eventos. Poco a poco, y luego de usarlo casi un año, la desesperación se ha ido convirtiendo en conocimiento, y ahora estoy empezando a entender un poquito de que se trata el asunto de nuevo… así que cuando venga la nueva versión, dentro de dos o tres años, probablemente ya lo estaré conociendo más o menos bien, y tengo que empezar de nuevo (casi) desde cero… magnifico…

Por pura casualidad, en estos días también estuve filosofando con mi jefe sobre el mismo tema. Muchos de los clientes para los que trabajamos quieren que los proyectos se hagan a precio fijo, y mi jefe tiene problemas enormes para explicarles que los riesgos que implican hacer proyectos con tecnologías muy nuevas (la compañía hace bastante proyectos utilizando las betas de Microsoft), hace casi imposible trabajar a precio fijo: la información técnica es mínima, es necesario invertir mucho tiempo en probar, probar y volver a probar (muchas veces para encontrar que, simplemente, no es posible hacer lo que quieres), y la falta de experiencia hace que todo dure un tiempo indeterminado. Como argumento a favor, a mí se me ocurrió solamente que el conocimiento que nosotros recopilamos en un trayecto de este tipo lo podemos utilizar más rápidamente que la competencia: un «ventaja tecnológica»… Su argumento fue apabullante: el desarrollo tecnológico va a tanta velocidad, que cuando estamos listos con una tecnología, nos la cambian y tenemos que empezar otra vez desde el principio…

Así que el dilema continua: seguir corriendo detrás de la zanahoria, como el burro del proverbio para mantenernos en la «punta de la lanza», o parar por un tiempo, estabilizar lo que sabemos, y luego seguir con lo siguiente, corriendo el riesgo de volvernos viejos tecnológicamente…

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

Cuando se conocieron las primeras noticias sobre SharePoint 2007, una de las cosas que me hicieron saltar de alegría fue la posibilidad de usar Paginas Maestras. Una de las pesadillas al modificar la presentación de un portal de SharePoint 2003 es la cantidad de trabajo que hay que hacer para cambiar las cosas más mínimas; me acuerdo muy bien un proyecto de hace un par de años en donde tuvimos que cambiar 359 archivos para hacer que la intranet (SharePoint 2003) de un cliente tuviera la misma presentación grafica que su extranet. Por supuesto que en el transcurso del tiempo se han creado «soluciones» para arreglar el problema («skinners»), pero ninguna funciona bien bajo cargas altas de usuarios.

Con las Paginas Maestras es posible realizar cambios en todo el Portal cambiando solamente una página (default.master)… genial… o casi. En realidad, no todas las paginas utilizan la misma Pagina Maestra: solamente las páginas de contenido la utilizan. Todas las páginas del «sistema» (las páginas de administración, por ejemplo) se niegan rotundamente a utilizarla pues usan la suya propia (application.master). Pero bueno, se podría pensar, es mejor cambiar dos páginas a cambiar 359… El problema es que en la administración del Portal se puede definir que Pagina Maestra se debe usar en el Portal, o, mejor dicho, en las páginas de contenido del Portal, pero no se puede definir lo mismo para las páginas del sistema. Así que, al final tendremos dos diferentes layouts: uno para contenido y otro para administración; el primero se puede modificar para cada sitio independiente, y el segundo es para todo el sistema… se comprende? No?… yo tampoco lo comprendo…

Una metida de pata de nuestros amigos en Seattle, una oportunidad desperdiciada o un NDI («Non Documented Issue», aunque si está documentado en el SDK)?. Probablemente nunca lo sabremos definitivamente. Pero ahora hay que buscar alguna forma para salirse del problema: como modificar algo que sucede en todo el Portal desde un sitio único, sin tener que pasarse el resto de vida programando… un HttpModule, pensaría yo. No son difíciles de programar, ahora que SharePoint no utiliza un filtro ISAPI funcionaran probablemente de una forma más estable, y se pueden configurar para que cada sitio utilice su propia Pagina Maestra para contenido Y sistema.

Provisionalmente hablando (no lo he probado aun con seriedad), el código debería ser algo parecido a:

public class MiModuloParaPaginasMaestras : IHttpModule
{
   public void Init(HttpApplication context)
   {
     Page miPagina = HttpContext.Current.CurrentHandler as Page;
     if (miPagina.MasterPageFile.Contains(«application.master»))
     {
       miPagina.MasterPageFile = «/_catalogs/masterpage/miPaginaMaestra.master»;
     }
   }
}

Es decir, cada página que envía un request a IIS es interceptada por el HttpModule, y si tiene un «application.master», se le cambia por un «miPaginaMaestra.master». Hasta ahora solamente he visto que funciona, pero el código no está listo para ser usado en producción. Varios problemas se pueden presentar aquí, y todos tienen que ver con las Paginas Maestras mismas:

– Hay dos formas para crear y modificar Paginas Maestras: a «lo mero macho», como dirían mis amigos los mexicanos, es decir escribiendo el código como se debe (código http, mas código xml, mas código CAML… en realidad, algo para los que saben lo que están haciendo), o usando el nuevo SharePoint Designer (facilito de hacer, pero se pierde totalmente el control sobre lo que pasa con el código). Desafortunadamente el Designer tiene una historia desastrosa de 10 años de mal-funcionamiento (cuando todavía se llamaba FrontPage)

– No hay forma de depurar Paginas Maestras: si se comete un error, el sitio simplemente deja de funcionar. Lo único que se puede hacer por ese lado es cambiar las propiedades del web.config respectivo para mostrar una indicación del problema en pantalla.

En resumen y para terminar. Las Paginas Maestras en SharePoint 2003 son una mejora (hasta una mejora enorme, se puede decir), pero les falto correr la ultima milla para hacerlas funcionar perfectamente… así que ellas son mejor y peor de lo que esperaba.

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

Por pura curiosidad, y por que me he podido escapar por un par de minutos sin que se dieran cuenta, me he puesto a instalar el nuevo suite de Expression de Microsoft. El Graphics Designer (programa para hacer dibujitos e imágenes) sigue siendo tres veces nada, aunque hay que ser honrados y concederle a Microsoft que han sido consecuentes: desde el primer Beta, hace ya como dos años, el programa ha sido totalmente inútil, y ahora, en CTP1, lo sigue siendo.

El WebDesigner tiene mejor cara. Es el programa WYSIWYG para la creación de sitios y paginas. Lo que era FrontPage antes de que lo convirtieran en la herramienta favorita de los destripadores de SharePoint, y antes de que lo empezaran a llamar «SharePoint Designer». Probablemente el jefe de diseño se llama Jack. . . En fin, volviendo al tema, cuando lo instalé por primera ver me llamo la atención una sección en la parte de Herramientas llamada SharePoint Controls. Mi primera reacción fue: hmmm esto suena interesante.

Como lo había instalado sobre un WinXP, me salía un letrero «Controls in this category require a web site running Windows SharePoint Services 3.0 or later». Muy bien, pensé, ningún problema, y lo instalé en un servidor de prueba con WSS 2007. Lleno de ilusión (que exagerado) y esperanzas (mas exagerado aun), he abierto el programa, y en el menú sigue el mismo aviso. . . Así que pensé, bueno, vamos a abrir el sitio. . . hmmmm peor. . . ahora sale otro aviso que dice que no funciona con SharePoint Services. . . Al fin qué? Funciona con WSS, si o no?

 

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

 

Un rápido consejo para todas aquellas pobres almas que quieren experimentar con el nuevo Technisch Release 1 (TR1) de Windows SharePoint Services 2007 (WSS 2007): al instalarlo, probablemente recibirán una pantalla de error que dice:

“Setup is unable to preceed due to the following error(s):

This product requires ASP.Net web server extensions to be enabled in Internet Information Services (IIS). Enable this setting and re-run setup. Please refer to the readme file for instructions on how to obtain these pre-requisites. Correct the issue(s) listed above and re-run setup.”

Este es un pequeño err… , perdón, un issue (como ellos mismos lo llaman) no documentado que parece se les escapó a los muchachos en Redmond. La solución es igualmente sencilla: registre ASP.Net de nuevo en el IIS del servidor con el siguiente comando:

aspnet_regiis -i

aspnet_regiis.exe lo puede encontrar en:

C:windowsmicrosoft.netframeworkv2.0.50727

Que lo disfruten…

Gustavo – http://www.gavd.net/servers/

Escriba un Comentario que me haga reir…

Los últimos tiempos bastante ocupado programando el nuevo Microsoft Office SharePoint Server (MOSS, que nombre mas feo). Fuera de un par de cosas interesantes, como, por ejemplo, que (casi) todo el código escrito para SharePoint 2003 sigue funcionando sin problemas, me acabo de encontrar un bicho mas … a propósito, como se puede traducir «Bug» al español… hmmmm… a Microsoft le ha dado por traducir de todo al español, excepto libros y cosas de esas interesantes, y han convertido, por ejemplo, a simples «WebParts» en «Elementos Web», con lo que se pierde el sentido completamente. Como traducirían ellos el concepto de «Bug»?. A «Debugging» lo han despanzurrado con un rotundo «Depurar», así que a un «bug» lo deberíamos llamar un «pura»…

Pero bueno, de regreso a MOSS (terrible nombre…). Dos de las cosas nuevas e interesantes son las «Columnas de Sitio» y los «Tipos de Contenido». Dicho en dos palabras, «Columnas de Sitio» («SiteColumns», en simple ingles), son campos especialmente definidos que se pueden usar por todos lados, y «Tipos de Contenido» («ContentTypes», por si no se habían dado cuenta), son colecciones de campos que se pueden usar en Listas o Librerías. Bastante bien pensado, tengo que admitirlo. Y funciona también bastante bien… hasta que intentas programarlo…

Crear un nuevo ContentType (no me tilden de traidor si uso el nombre en ingles, es simplemente mas corto para escribir) es bastante fácil: haces un objeto con la colección de ContentTypes, y le añades el nuevo tipo:

    SPContentTypeCollection todosMisTipos = miWeb.ContentTypes;
    SPContentType miTipo = new SPContentType(null, todosMisTipos, «MiPropioTipo»);
    todosMisTipos.Add(miTipo);

(miWeb es del tipo SPWeb, y viene del contexto del Portal). Todo funciona sin problemas. Al intentar agregarle un SiteColumn a nuestro ContentType:

    SPFieldCollection misCampos = miWeb.Fields;
    SPField miCampo = new SPField(misCampos, «Asunto»);
    miTipo.Fields.Add(miCampo);

es decir, haciendo un objeto con uno de campos que ya existen, y agregándoselo al ContentType que acabamos de crear todo deja de ser tan fácil, y nuestro programa deja de funcionar. SharePoint devuelve un error «Esta funcionalidad no está disponible para colecciones de campos que no están asociadas a una lista».

Intentándolo con los otros constructores del método:

    miTipo.Fields.Add(«Asunto», SPFieldType.Text, true);
    miTipo.Fields.CreateNewField(«Asunto», «Asunto»);

produce el mismo error.

Microsoft se quejaba en los últimos tiempos que no habían recibido suficiente respuesta de los usuarios beta. Pero la única forma de enviar este tipo de problemas a Microsoft es por medio de un E-mail a wssfb@microsoft.com , desde donde nunca mas se oye algo, ni siquiera una confirmación de que han recibido el E-mail. Entonces, porque se quejan? Ya hasta le han puesto un precio a los pobres inocentes que les quieren probar el producto gratis y por nada. Es decir, tienes que pagar para ser probador Beta, les ahorras un montón de dinero buscando los bichos en el producto, luego pagas otro montón por el producto que tu mismo ayudaste a producir, y encima se te quejan porque no mandas mas comentarios… el mundo al revés, o me equivoco?

A propósito, no les había comentado que el nombre «MOSS» no me gusta nada?

Lo llamamos «Subcontratación» en español, pero cuando pienso en subcontratación, pienso mas en hacer construir una nueva cocina en la casa, que en hacer desarrollar código en algún país exótico…

En fin, continuando con los dilemas de la semana, otra de las discusiones (a veces acaloradas) que tienen lugar cada vez mas en la empresa donde trabajo es que tan interesante es para nosotros «subcontrar» el desarrollo de código. La discusión viene y va con el tiempo, pero en estos días estamos empezando a planear la nueva versión de una aplicación bastante grande que tenemos construida para trabajar con SharePoint 2003; la nueva versión será hecha, por supuesto, para que trabaje con SharePoint 2007. No estamos hablando de una u otra WebPart, sino de una aplicación que contiene mas de diez NameSpaces, y que consta de innumerables paginas personalizadas, varias plantillas propias, un montón de WebParts y WebControls, y unos 60.000 renglones de código… es decir, algo grande de verdad…

La primera versión fue desarrollada completamente por nosotros en la empresa. La segunda versión (hace dos años), fue subcontratada con otra empresa fuera del país. Para esta segunda versión, nosotros solamente aportamos el diseño funcional y el apoyo en cuanto a conocimientos del producto; después de un par de meses, recibimos el software funcionando, pero cuando tuvimos que empezar a hacer modificaciones y mejoras, empezamos a ver que el diseño técnico no era precisamente algo para estar orgulloso: el Modelo de Objetos utilizado no es consecuente, la separación (especialmente) entre las capas de lógica y presentación no es tan buena como deseábamos, el sistema de WebServices simplemente no funciona… no quiero decir que es un desastre, pero podría ser mejor…

Ahora estamos planeando la versión 3, como decía, y estamos en el dilema de desarrollar todo en casa, o subcontratarlo. O un camino intermedio. Para desarrollar todo en casa, necesitamos utilizar todos los desarrolladores, arquitectos, etc. de que disponemos por un par de meses, lo que significa que no podemos hacer nada por y para los clientes que tenemos, o que podemos conseguir en este tiempo. La ventaja principal es que todo sucedería como queremos que suceda. Si lo subcontratamos, perdemos probablemente calidad, pero ganamos en tiempo y recursos propios, fuera de que probablemente será (mucho) mas barato.

Mi punto de vista, si es que a alguien le interesa, es precisamente el camino intermedio: nosotros hacemos el diseño funcional (de todas formas esta en nuestras manos) y el diseño técnico. El outsourcing hace el trabajo de programación; mejor dicho, nosotros estipulamos la arquitectura, el Modelo de Objetos, la comunicación de los diferentes objetos entre si y entre las diferentes capas, yendo tan lejos como, por ejemplo, generar los esqueletos de las clases necesarias. Y la compañía que subcontratamos «solamente» tiene que meter el código en las clases para que hagan lo que tienen que hacer. Y nosotros producimos nuestras propias clases de prueba (unit test, regressive test, compilation) de tal forma que cuando nos llegue una clase completamente programada, podamos ver inmediatamente si funciona como nosotros esperamos. Ventajas es que la parte técnica la mantenemos en nuestras manos. Desventajas es que no seria tan barato como un outsourcing «completo».

Un dilema mas para charlar largo y tendido…

Gustavo – http://www.gavd.net/servers

Escriba un Comentario que me haga reir…