Ideas 3p

Model View ViewModel

noreply@blogger.com (Benjamin Eidelman) — Mon, 26 Jul 2010 15:36:00 +0000

En un mail reciente de MSDN apareció un artículo que toca un tema de diseño interesante.
Y es el patrón Model-ViewModel-Model, en el artículo se hace referencia a su implementación en WPF/Silverlight, sin embargo es un tema con el que seguramente muchos se topen al incursionar en Asp.Net Mvc, y en realidad es imposible de esquivar en cualquier implementación de MVC, ya sea en Asp.Net, WinForms, Ruby o Haskell.

ViewModels

Cuando trabajamos con un modelo MVC, especialmente si elegimos algún mecanismo de DataBinding entre M y V (y en un sentido amplio de la palabra consideremos los templates (como las vistas de Asp.Net Mvc) como un caso particular de DataBinding), resulta inmediato que cualquier aplicación que escape de lo elemental necesita algun tipo de transformación entre un Modelo y su Vista, ahi es donde llegan al rescate los ViewModels.

Para hacerlo menos abstracto, pongamos un ejemplo, imaginemos que nuestros amigos de Facebook® quieren construir la pagina de perfil de un usuario:

Perfil de Usuario

supongamos también que utilizan MVC y construyen su "Model" de la siguiente forma:

Nota: el modelo real de Facebook® podría ser más complejo

La duda es como obtener los datos resaltados en amarillo en la captura de ejemplo

Antigüedad del mensaje de estado ("lunes pasado").
Ubicación ("Villa Devoto" en lugar de el GUID correspondiente)
Amigos en común (con el usuario logueado actualmente)

Para esto podemos "envolver" estas entidades del modelo con otras más emparentadas a la vista que queremos construir:

Estas clases extienden a las anteriores con campos calculados, listas filtradas, consolidaciones, u otro tipo de transformaciones sobre el modelo original.
Para ilustrar ésta sería una versión (muy naive) de la nueva propiedad "CommonFriends" en UserVM:

public IList<UserVM> CommonFriends
        {
            get
            {
                return this.Friends
                    .Where(f => f.Friends
                      .Any(ff => ff.UserID == User.CurrentUserID))
                    .ToList();
            }
        }

Si usted ya estuvo agregando este tipo de campos calculados y transformaciones, y se sentía culpable por haber violado la prístina pureza de su modelo MVC

siéntase liberado de la culpa!, esto ya tiene nombre y se llama ViewModel!

Separación Model-ViewModel-Model

Por supuesto en esto podemos imaginar un gradiente de creciente complejidad:

Propiedades agregadas directamente a las entidades de nuestro modelo
Algunas clases nuevas y propiedades agregadas a entidades que descienden de las de nuestro modelo
Una capa de ViewModels que se interpone y separa completamente View de Model.

Volviendo un poco al principio, el artículo de MSDN trata sobre la última opción, implementada como assemblies separados para View, Model y ViewModel, en el que no existen referencias entre View y Model.

Véase este gráfico explicativo que tomé prestado de un artículo que resume muy bien el tema

Rápidamente puede verse el problema burocrático en que nos pone este enfoque, ya que implica tener para casi todas las clases del modelo, una equivalente en ViewModel, con wrappers para todas las propiedades visibles. Imagínense la flagrante violación al principio DRY que supone crear páginas y páginas de código como este:

public string Fullname
        {
            get
            {
                return InnerEntity.Fullname;
            }
            set
            {
                InnerEntity.Fullname = value;
            }
        }

Tiene que haber algo mejor!

Dynamic Proxies

Como dice la máxima "El mejor código es aquel que no se escribe", y el artículo al que hice referencia propone generar estos ViewModels como proxies dinámicos, implementar esos "gets" y "sets" automáticamente con el nuevo tipo dynamic en .Net 4.0, un poco de Reflection y unos atributos muy elegantes para declarar dependencias entre propiedades (ej: Edad <-depende de-> FechaDeNacimiento).

Existen también librerías muy famosas para la creación de proxies dinámicos (que funcionan con .Net 2.0), como por ejemplo las que son usadas en NHibernate (para crear proxies que soporten lazy loading):

que hacen fácil agregarle a estos proxies interceptores en getters y setters (u otros métodos) que implementen notificación de cambios, logging, autorización y otras cosas por el estilo.

Y finalmente...KISS! es importante recordar que puede resultar más que suficiente con mantener las clases en el modelo accesibles a las vistas, y las clases "ViewModel" mezcladas con el "Model", o separadas simplemente por namespace.

Sitecore, otra opción que ofrecer

noreply@blogger.com (Ricardo D. de Guzmán) — Wed, 07 Jul 2010 18:03:00 +0000

Algunas semanas atrás, uno de nuestros clientes más importantes, nos invitó a participar junto con otros proveedores de un curso intensivo de una semana sobre Sitecore.
Sitecore es un CMS que proporciona software de gestión de contenidos web y portales a organizaciones que requieran funciones empresariales, integración y escalabilidad a la hora de administrar sitios web.

Sitecore fue desarrollado en Dinamarca, y tiene su mayor mercado actualmente en Estados Unidos y Europa. Nuestro cliente vio interesante, la posibilidad de que sus proveedores de mayor confianza, se puedan instruir en esta herramienta para que en el futuro los acompañen en la integración de Sitecore con otras aplicaciones, puedan agregar nuevas funcionalidades o colaboren en la implementación de la herramienta.

Como en Tercer Planeta estamos acostumbrados a realizar nuestros propios desarrollos, la primera reacción a la invitación fue “y no sé, ¿te parece que tengamos que aprender Sitecore?”, pero rápidamente comprendimos que la mejor respuesta a esa pregunta con un , “claro que sí”, y hoy en día vemos los beneficios de haber participado en ese encuentro.

Más allá que nuestro fuerte esté en los desarrollos a medida, siempre es enriquecedor poder conocer cómo otros pueden encarar una determinada solución. En este caso puntual, Sitecore nos pareció un producto muy completo, que tiene cubiertas muchísimas funcionalidades, muchas de las cuales todavía no pudimos explorar, pero en las que sí pudimos indagar descubrimos que están resueltas de manera muy diferente al enfoque que le hubiéramos dado nosotros, simplemente porque fue pensado por otras personas, en otro contexto, con otra experiencia y otras costumbres.

Con lo cual la posibilidad de poder salir, tomar distancia de nuestros tareas diarias, y ver cómo piensan otros, nos resultó más que interesante.

El curso fue dictado por Craig Nelson, un instructor técnico especializado en Sitecore, que viajo especialmente desde Estados Unidos. Cada día estaba orientado a diferentes perfiles (Usuarios Finales, Diseñadores, Desarrolladores, etc.), constaba de partes teóricas y prácticas, las cuales resolvíamos en grupos, esta interacción con otros colegas fue también una experiencia que valió la pena.

Este curso nos sirvió para conocer una nueva herramienta, y fundamentalmente para ver otra forma de hacer las cosas, e independientemente del uso que la vayamos a dar en el futuro, hoy en día, sentimos que tenemos una posibilidad más, otra opción que ofrecer, o tener en cuenta, y eso creo que es lo más importante, para nosotros y para nuestros clientes.

Cómo entendemos el crecimiento

noreply@blogger.com (Andrea Morales) — Mon, 05 Jul 2010 18:00:00 +0000

Cuando en diciembre del 2009 nos reunimos con Jose a definir los objetivos del 2010 decidimos que teníamos que poner el foco en madurar.

Pero, qué significaba en ese momento “madurar” para nosotros ? Para el tamaño de organización que tenemos y por los lineamientos que seguimos, lo que buscábamos era lograr un crecimiento de la empresa pero no medido en este caso en cantidad de integrantes o en monto de facturación, sino en base al crecimiento profesional y desarrollo personal de todos los integrantes del equipo de Tercer Planeta.

Help, I need somebody!

Para quienes no somos especialistas en coaching y tenemos un perfil más técnico, el objetivo se presentaba como un gran desafío y sabíamos también que nos embarcábamos en un trabajo de largo plazo que implicaba grandes cambios individuales y en el grupo.

Estaba claro que para poder llevar a cabo esta tarea necesitábamos contactar a especialistas en el tema y fue así que acudimos a Pablo Fondevila y su empresa “Nuevas Miradas en Organizaciones”, quien junto con Carola Herrscher y Marisa Bergés se dedican al Coaching Ontológico . Con ellos empezamos a transitar este camino desde hace 6 meses.

Algunos caminos a seguir

Uno de los aspectos que comenzamos a abordar es tratar de lograr una convergencia entre la vida personal y la laboral ¿cómo pensar que con la cantidad de horas que compartimos en la oficina ambos entornos marchan cada uno por un “carril exclusivo” sin tocarse en ningún momento?
Es lógico entender que estas dos “vidas” se cruzan en varios puntos pero no nos resultaba tan lógico hacer visible y poner un esfuerzo claro y público en juntarlas y complementarlas.

Y para qué querríamos hacer esto? Una de las respuestas que encontramos a esta pregunta es que creemos que la realización de las personas debe ser algo integral, el desarrollo personal y profesional implica poder mostrar los logros, tomar nuevos compromisos, cerrar etapas, explorar nuevos caminos, descubrir y explotar nuestras habilidades.

Por otro lado, aceptar la influencia que las emociones tienen en nuestras vidas es fundamental para entender algunos comportamientos: por ejemplo, aclarar que estamos viviendo un momento difícil o que tenemos algo importante que resolver puede evitarnos conflictos de comunicación si encontramos un ámbito donde nos sintamos cómodos para declararlo y los demás entiendan el por qué de ciertas actitudes.

Entender cuán valioso es el esfuerzo de alguien por terminar una carrera o por emprender nuevos retos, por ejemplo, nos anima a fomentar ese tipo de logros, que sin duda, redundarán en valor para los objetivos de la empresa.

Cómo hacer entonces para acercar estos dos mundos y lograr que se retroalimenten ? O que el trabajo sea un medio más a través del cual alcanzar objetivos personales ?
Cómo hacer que la "vida de la oficina" no genere trabas en la vida privada ? O que la vida privada (logros, alegrías, tristezas) puedan ser, de alguna manera, compartidos, apoyados y comprendidos por la empresa?

Estas fueron algunas de las dudas que empezaron a surgir. Dudas que, gracias a las herramientas que nos van dando quienes nos acompañan (talleres, entrevistas individuales periódicas, consejos para la organización de eventos internos y externos, etc.), empezaron a disiparse.

Puede asombrarnos pensar que con pequeños cambios o con la creación de ámbitos de discusión de cosas simples y concretas, es absolutamente posible y realizable encarar el tema.

De la misma manera las charlas individuales para desarrollo personal nos están abriendo los ojos a nuevas posibilidades de solución de conflictos, de aprovechamiento de las capacidades de cada uno, de alineamiento con los objetivos y visión de la empresa, de comunicación, de roles, etc.

Esfuerzo vs. Beneficios

Según mi opinión, el mayor desafío en este emprendimiento está en saber incorporar y mantener estos valores. Lo cual implica un trabajo de replanteo individual, de delegación de tareas, de acompañamiento, de promoción de la creatividad, de generación de espacios de intercambio, entre otras cosas.

Creo que el entender que estos procesos implican pensar a largo plazo, esfuerzo y modificaciones en la mentalidad, en las costumbres, en las estructuras y en la mirada con que enfocamos las cosas, es una de las principales claves para obtener buenos resultados.

Ahora, sin dejar de lado un enfoque más “empresario”, qué beneficios veo en estos cambios en relación con la organización y la productividad ?

• Mayor compromiso de todos
• Mayor motivación
• Mejoramiento del ambiente laboral
• Mayor confianza entre los miembros del equipo
• Mejoras en la comunicación
• Hacer que los objetivos y la visión de la empresa sean sostenibles en el tiempo

Me animo a decir también que todo este “movimiento” trasciende los límites de la empresa y repercute en la relación con nuestros clientes, quienes, en definitiva, se benefician con los resultados que un equipo de trabajo motivado y “en sintonía” es capaz de producir.

Vale la pena?

Considero que para empresas como la nuestra, donde el capital humano es considerado uno de los puntos más importantes, la inversión en este tipo de emprendimientos está más que justificada y muestra sus frutos en muchas áreas.

Finalmente, creo que para “poner a rodar la maquinaria” en todo esto, el principal motor es ver y reconocer la importancia que tienen estas cuestiones en nuestra vida cotidiana, cualquiera sea el carril por el que marche.

¡Qué comience la sesión!

noreply@blogger.com (Nora Martinez) — Tue, 29 Jun 2010 19:33:00 +0000

Resulta común que durante el almuerzo o en esos 5' que lleva batir el café o preparar el mate surjan temas o ideas interesantes que son para "discutir entre todos", o al menos entre muchos; y, por lo general, se hace difícil buscar y encontrar el tiempo necesario para hacerlo, por lo que esas ideas quedan sin transmitir ni impulsar.
Esto nos sucedió a nosotros, hemos de reconocerlo. Pero encontramos la solución y, como era lógico, la misma surgió en esos momentos de "recreo laboral".
La propuesta fue tener reuniones cortas para charlar y debatir acerca de diferentes temas. Así surgió nuestro "Cabildo Abierto", pensado como un espacio en el que se pudieran plantear problemas o inquietudes, discutir soluciones, propuestas o acciones a tomar y llegar a alguna conclusión con una solución rápidamente aplicable.

El nombre elegido no fue al azar, ya que combina el nombre de la Avenida en la cual está nuestra oficina con el llamado a debate mediante la participación activa y sin límites de cualquier integrante de Tercer Planeta (3P) que quiera hacerlo.

¿En qué consiste?
El término Cabildo Abierto no es nuevo, surge en la época del Virreinato del Río de La Plata en la cual algunos pobladores se reunían para tratar diversos temas.

Nuestro Cabildo Abierto consiste en hacer sesiones para debatir temas propuestos por los integrantes de 3P. Cada uno, al tener un tema a tratar, anota un título representativo en una Wiki. Fue designada la figura de moderador quién es el encargado de seleccionar 2 o 3 temas propuestos para debatir en la siguiente sesión, estos temas pueden estar conectados o no; la particularidad de ellos es que el debate no debería llevar mas de 1 hora.

Una vez seleccionados los temas, se proponen días y horarios (es deseable mas de 2 opciones para elegir) y cada interesado en participar se anota según su conveniencia. Aquel día-horario que tenga mas participantes será el día elegido para sesionar. Es fundamental que aquella persona que propuso el tema asista a la sesión ya que es la encargada de presentar el tema, impulsar el debate y anotar las conclusiones.

Al comenzar la sesión, se expone cada tema, se lo discute y, al dar cierre al debate, se anotan las conclusiones propuestas en la Wiki. En caso de requerir un seguimiento, la persona que propuso el tema tendrá la responsabilidad de hacerlo.

Anotando temas
Los temas a proponer pueden ser muy variados, ellos surgen de la motivación personal de mejorar algo que vemos y sentimos puede ser mejorado o revisado. Por supuesto dado que cada persona tiene al respecto una visión distinta, un enfoque distinto, esto es lo que enriquecerá la gama de tipos de temas propuestos.

Se pueden proponer temas que traten asuntos relacionados con la metodología de trabajo o con cuestiones técnicas del desarrollo. También pueden sumarse aquellas cuestiones que tienen que ver con la convivencia o el espacio físico en el que nos encontramos. En definitiva, vale anotar cualquier tema que cada uno quiera tratar en una sesión de Cabildo Abierto.

Nosotros, en particular, hemos presentado diversos temas. Algunos de ellos fueron:

Cómo manejamos el Collate en SQLServer?
Timeboxing (como afecta la calidad, como tenerlo en cuenta en la planificación, como prever y manejar imprevistos, etc)
Equipar lo necesario para poder hacer reuniones remotas
Cómo mejorar nuestra relación con el cliente?
Cambiar las cortinas

por citar algunos títulos.

Conclusiones
Es importante saber que existe un epacio en el que se puede proponer y accionar esas propuestas. El Cabildo Abierto intenta ser eso precisamente: un espacio en el cual se planteen y canalicen las inquietudes de todos y se busquen las respuestas y soluciones en forma conjunta.

HTML5, un paso más cerca

noreply@blogger.com (Benjamin Eidelman) — Thu, 18 Mar 2010 16:16:00 +0000

Html5: Html para aplicaciones web

Desde hace mucho tiempo, oímos culpar de los problemas intrínsicos de las aplicaciones web, a la naturaleza “document-oriented” de la web. La web fue pensada originalmente como una red para compartir documentos “hipervinculados”, y no como plataforma de aplicaciones distribuídas. De hecho fue éste el argumento expuesto por Google en forma de historieta para lanzar Chrome.

Para subsanar esta brecha surgieron una gran variedad de tecnologías, como javascript, Java Applets, Ajax, Flash, y más recientemente Google Gears, Java FX y Silverlight con la intención de crear en los browsers lo que se conoce como Rich Clients, clientes que permitan una experiencia de usuario similar a la de una aplicación de escritorio, con todas la ventajas de la web.

Sin embargo en todo este tiempo, el “poder legislativo” de la web, la W3C, no se quedó de brazos cruzados, y como es de esperar, respondieron con un estándar, tomándose su tiempo. La respuesta de la W3C fue: HTML5

HTML5 traerá muchas novedades, pero lo importante, la idea que está detrás de la mayoría de ellas, es la creación de aplicaciones web “ricas” en nuestros browsers. Para muestra basta un botón:

Graficos vectoriales, animaciones y efectos visuales más avanzados
Almacenamiento local en el browser, no sólo como diccionarios, también en forma de bases de datos SQL, y otras facilidades para aplicaciones “offline/online”
WebWorkers, tareas asincrónicas, y un sistema de mensajería entre ellas.
Navegación Ajax
Streaming de audio y video
DOM Events, los elementos de un documento html, expondrán una serie eventos (ej: div.resize)
Drag & Drop
Tags semánticos asociados a aplicaciones como: <progress>, <meter>, <command>, <datalist>, <output>, y nuevos tipos de campos para formularios (<input>) como “datetime”, “range”, “search”, etc.
varios etc.

A esta altura, resulta evidente que tener soporte para todo esto, de forma nativa en HTML, se ve como una amenaza para todos los que proveen estos features actualmente mediante plugins, como Flash, Java FX, Silverlight y otros.

HTML5 todavía está en pañales, y se acerca lentamente, sin embargo la mayoría de los browsers ya soportan varios features de HTML5.

IE9, Podría Microsoft estar suicidando Silverlight?

Con la salida de IE8, Microsoft empezó a soportar algunos features de HTML5, sin embargo este era muy limitado, y con la ausencia del elemento <canvas> que permite la inclusión de gráficos vectoriales, se especuló sobre una estratégica defensa de Silverlight.

Sin embargo, con la llegada de IE9 están anunciando un soporte para HTML5 mucho más completo, tanto que publicaron una pagina para probar entre otras cosas el soporte HTML5 de IE9 (incluyendo animaciones y gráficos vectoriales con aceleración por hardware).

Y a esto se suma un nuevo engine Javascript, que pretende ponerse a tiro con el resto con benchmarkings prometedores. Esto me recuerda un comentario sobre el futuro de Javascript de Martín Salías.

Para los que trabajamos con .Net surgen ahora dudas existenciales sobre como afectará esto el futuro de Silverlight.

Sin duda la familiaridad del framework .Net, C#, y la integración con VisualStudio son la panacea para los desarrolladores que ya trabajamos con .Net, sin embargo, ¿Qué features realmente distintivos tendrá Silverlight para los usuarios?

Gráficos 3D, Out-of-browser y Smooth Streaming?

Quizás todavía sea solo futurología, pero la llegada de IE9 nos acerca bastante a la pregunta:

¿Cuál será el lugar que ocupará Silverlight (y otras RIU) con la llegada de HTML5?.

Profecía autocumplida: Google + Apple + Microsoft

Ya no hace falta decirlo, a esta altura, HTML5 será un caso evidente de profecía autocumplida, no sólo por tratarse de un estándar de la W3C, sino por contar con el apoyo de Google (además de incluir soporte en Chrome, decidió abandonar Google Gears, por considerarlo un subset de lo que HTML5 proveerá y creo una versión HTML5 de YouTube), Apple (soporte en Safari, que incluirá IPhones que actualmente no soportan Flash), y finalmente Microsoft con la llegada IE9.

Falta aún saber cuanto falta para que sea soportado completamente por los browsers más populares, y para que nuestras IDEs nos permitan aprovecharlo.

¿Y si jugamos a que hacemos software?

noreply@blogger.com (Benjamin Eidelman) — Mon, 30 Nov 2009 16:18:00 +0000

Desde hace un tiempo, estoy dando una mirada de vez en cuando a una revista online sobre metodologías ágiles en portugués. Visão Ágil, como tarea hogareña del curso portugués que estoy haciendo, y con la intención de leer un poco sobre este tema (como dice la poco ecológica metáfora: matar dos pájaros de un tiro).

La técnica del Tomate

En el blog de esta revista encontré recientemente un artículo sobre la “Técnica Pomodoro” de Manoel Pimentel. La Técnica Pomodoro se utiliza para la administración personal del tiempo, y está inspirada en ideas de las metodologías ágiles, como TimeBoxing y el uso de herramientas de “baja tecnología”, puntualmente: papel, lápiz y un timer de cocina.

Estos timers con forma de tomate (pomodoro en italiano) son los que dan nombre a la técnica

Si bien ese artículo tiene un mindmap que resume muy bien los puntos clave, lo que más destacaría es la simplicidad, el énfasis en mantener el foco, y la asignación rígida de tiempos (véase TimeBoxing) tanto a las tareas como a los intervalos de descanso entre éstas.

Con respecto a este último punto, el libro oficial que puede descargarse de http://www.pomodorotechnique.com destaca la importancia de estos intervalos para “asimilar lo aprendido y hacer algo bueno por tu salud”, como caminar, ejercicios de respiración o contar un chiste. Interrumpir este período de descanso con cualquier tarea que implique un esfuerzo mental, “bloqueara el constructivo proceso mental de integración necesario para estar alerta y listo para el proximo ciclo”. Una especie de build de integración que se ejecuta periódicamente en background en nuestro cerebro.

El último que se escondió arma el release!

Sin embargo lo que quería mencionar en este artículo (y por eso el título), es algo que me parece muy valioso y puede pasar desapercibido a primera vista. Es el espíritu lúdico que hay detrás de esta técnica (vi este punto escrito en el mindmap del artículo de Pimentel).

Una idea que tambien está implícita en varias técnicas utilizadas en metodologías ágiles.

Creo que en esta manera de encarar el trabajo (y cualquier otra cosa) hay mucho más jugo de lo que se cree habitualmente. Especialmente en ambientes que promueven la productividad y la creatividad.

No hay que confundirlo con una forma de hacer apología de la competencia (que casi nunca es sana), o de esquivar el bulto a las tareas tediosas. Se trata más bien de evitar que nuestro trabajo sea una letárgica marcha atrás de la recompensa monetaria de fin de mes (Dispositivo del burro y la zanahoria),

para empezar a disfrutar del día a día, transformándolo en un juego constructivo, hasta casi “sentir que no trabajamos”.

Sin duda el tema, da para mucho más que este artículo (y para autores más calificados!) pero la intención era traer a colación el tema, y tratar de poner en evidencia, o preguntar, ¿Cuántas cosas hacemos (o podemos hacer) en este sentido?

"La columna del medio"

noreply@blogger.com (Matías Timossi) — Fri, 13 Nov 2009 20:19:00 +0000

Aportando dinámica a la pizarra

En nuestro equipo de trabajo contamos con los ambientes de desarrollo (pruebas de unidad) y de QA (pruebas de integración).

Desde hace tiempo venimos aplicando prácticas de SCRUM. Con el uso de la pizarra notamos la necesidad de diferenciar las tareas cuyo desarrollo se encontraba en progreso de aquellas terminadas y a la espera de un pasaje al ambiente de QA.

Esto era debido a que cada vez que terminábamos una tarea la pasábamos a la columna de “Test”, ocasionando muchas veces confusiones ya que no teníamos manera de saber si las tareas que se encontraban en esta columna estaban contempladas dentro del último build.

Durante un tiempo intentamos hacer el pasaje de papelitos solamente cuando hacíamos el build al ambiente QA, pero para eso contábamos con nuestra memoria para saber que tareas estaban completas, lo que no siempre resultaba con éxito por que… seamos sinceros… esta no siempre nos era fiel =)

Entonces un día, durante la retrospectiva de uno de nuestros proyectos tuvimos la siguiente maravillosa idea para arribar a una solución:

Agregar una columna intermedia entre DESA (In progress) y QA (Test) que nos permitiera saber, de forma inmediata, cuáles eran las tareas que estaban listas pero que todavía no estaban disponibles para ser probadas en QA…

¿Como funciona?

Cada vez que el desarrollador termina alguna tarea, mueve el papelito correspondiente de “In Progress” a la columna “DESA/TEST”(la columna del medio) indicando de esta manera que el desarrollo ha finalizado y estará disponible en el próximo build para su prueba.

Si bien debo reconocer que en un principio tuve mis dudas acerca de si la nueva columna iba a servir de algo, el uso de la misma nos demostró gran efectividad.

Su implementación acarreó las siguientes mejoras:

Nos permitió tener una noción más precisa del avance del sprint, rompiendo con la sensación de un “avance estático” generado por la acumulación de tareas en la columna de desarrollo.
Da una idea más clara al desarrollador de qué tareas le falta completar y cuáles completó.
Brinda al tester la certeza de saber qué estará para probar.
Es mucho más fácil decidir en qué momento hacer un pasaje de ambiente.

Resultado final

Conclusiones

Por nuestra experiencia, la incorporación de esta nueva columna trae grandes beneficios a la dinámica del equipo, agilizando la comunicación. Los invitamos a probar esta alternativa y que compartan con nosotros sus experiencias.

Sobre Ratas, Elefantes y TimeBoxing

noreply@blogger.com (Benjamin Eidelman) — Wed, 08 Jul 2009 11:54:00 +0000

La semana pasada nos dispusimos a realizar un cronograma de entregas para las próximas semanas de uno de nuestros proyectos, así que me reuní con el resto del grupo involucrado, y empezamos una planificación, haciendo una revisión rápida de las historias de usuario prioritarias en nuestro backlog.

Acto seguido, ubicaríamos estas historias de usuario según sus “tamaños” , prioridades y dependencias, en hipotéticos sprints, manteniendo presente el concepto de TimeBoxing.

La bolsa de Gatos

La lista resultó ser bastante extensa, y estimar el esfuerzo requerido por cada ítem, se volvía un poco confuso. Eran demasiado heterogéneas (lo que comúnmente llamamos bolsa de gatos).

Era necesario dividir un poco las aguas y separar cosas como “cambiar el color de fondo del campo X” de “diseñar un generador de fusión en frío”.

Creo que lo más peligroso de esto es que camufladas en medio de la estampida de historias de usuario más pequeñas, podían pasar desapercibidas las más pesadas o de más difícil estimación.

Una metodología de planificación para toda la familia

Normalmente utilizamos para estimar el esfuerzo requerido de cada historia de usuario, cartas de Planning Poker (gracias a Mountain Goat) al comienzo de cada sprint, sin embargo esta planificación prolongada requería de una primera clasificación grosera.

Fue así que con el ánimo de innovar un poco y de hacer la reunión un poco más divertida inventamos (y ofrecemos sin patente alguna) un método de planificación que podría llamarse “El Arca de Noé”.

Es importante que participen todos los miembros del equipo (funcionales, desarrolladores, líder de proyecto, etc. con sus diferentes visiones) y consiste básicamente en 2 etapas:

1. Clasificación

En esta etapa se toma cada una de las historias de usuario, y luego de una breve descripción, y discusión sobre sus implicancias (aquí típicamente es el momento de que un desarrollador advierta sobre dificultades posibles, o calle para siempre :)). se procede a su clasificación.

Las tareas se ubicarán en 3 grandes categorías de acuerdo al esfuerzo que representa la tarea, para hacerlo más entretenido decidimos identificar estas categorías con especies animales:

Rata: Con este nombre identificamos historias de usuario más rápidas de resolver y que no requieren casi ningún análisis sobre la forma de implementarlas. Típicamente cambios estéticos, cambios de configuración, pseudo-duplicar un componente ya existente, etc.
Perro: En esta categoría van tareas que implican un cierto análisis y/o un trabajo más cuidadoso o extenso que las anteriores.
Elefante: Finalmente elefantes son las historias de usuario más pesadas, generalmente requieren un esfuerzo de diseño, o hay muchas dudas sobre la forma implementarlo, o implica un riesgo díficil de estimar.

Finalmente es importante entender que tanto el número de categorías (3), como los criterios para ubicar un historia de usuario en cada categoría, son parámetros que deben ajustarse con el tiempo a las particularidades de cada equipo.

2. Planificación

En esta etapa al igual que Noé con su Arca, es dónde tenemos que acomodar estos animales (o historias de usuario) en compartimientos finitos (o sprints).

Advertencia: Si la cantidad de sprints es limitada, es posible que algunas historias de usuario se pierdan en el diluvio universal.

Para esto tenemos que sopesar diferentes criterios:

Historias prioritarias para el cliente
Dependencias entre éstas
Recursos disponibles
Imprevisibilidad o riesgo de una tarea (generalmente es preferible comenzar estas tareas lo antes posible para en caso de necesidad ajustar el rumbo a tiempo)

y otros que puedan ser particulares del proyecto.

Aquí es dónde se aplican todas las metodologías de planificación que normalmente utilizamos.

Por supuesto que la medida de cuántos “elefantes” entran en cada sprint, además de depender de los recursos disponibles en ese sprint, es algo que los miembros del equipo irán refinando con el paso del tiempo.

El Resultado:

Conclusiones

Antes de empezar a dibujar Gantts, Cronogramas o un Análisis de Riesgo, se hace necesario hacer una primera pasada que identifique las historias de usuario clave. Esta variante simple resulta bastante divertida, lo cual en una larga planificación nunca está demás.

Eso sí, una consecuencia inmediata y un poco vergonzosa, son expresiones del tipo; “Yo 2 elefantes en esta semana no me puedo comer, mejor empiezo agarro un elefante y voy intercalando con algunas ratitas” o “Me parece que nos estás vendiendo perro por rata”

Quién se anima a compartir otras variantes de este tipo?

Como excluir archivos de configuración de Source Control

noreply@blogger.com (Ricardo D. de Guzmán) — Mon, 16 Feb 2009 12:36:00 +0000

Una pregunta que alguien se podría hacer al leer este artículo, es ¿porque voy a querer quitar los archivos de configuración del repositorio de código fuente?

El objetivo de los Repositorios de Código es justamente ese, resguardar el código, los archivos de configuración son necesarios al ejecutar la aplicación, y muchas veces al compilarla, tal es el caso del web.config, por este motivo necesitamos que sean parte del proyecto, pero tenerlos en el repositorio de código fuente nos puede traer algunos problemas.

Uno de los inconvenientes ocurre en los procesos de Deployment, ya que los archivos de configuración, ente otras cosas, almacenan información referida al ambiente donde corre la aplicación:

Desarrollo
Qa
Producción
etc

y el repositorio almacena versiones del código, independientemente de los ambientes en donde se instale.

En este sentido excluirlos, nos obliga a hacer un manejo especial con ellos en los diferentes pasajes de ambiente, que nos puede evitar errores. Por otro lado mientras estamos desarrollando, es bastante común hacer pruebas modificando los archivos de configuración, pruebas que nunca vamos a querer subir al repositorio de código (Ej.: apuntar la configuración a una Base de Datos local), si tenemos los archivos en el repositorio, es necesario hacer CECK OUT, para luego hacer UNDO PENDING CHANGES al finalizar la prueba. Esto, mas allá de ser una tarea tediosa para el desarrollador, es problemática si son muchos los que están trabajando al mismo tiempo.

Veamos cómo hacerlo

En este caso vamos a hacer un ejemplo utilizando como Repositorio de Código Fuente a Team Fundation Server.

En este ejemplo, voy a abrir la solución correspondiente al Sitio corporativo de Tercer Planeta http://www.tercerplaneta.com/, para excluir al web.config, cabe aclarar que esto se puede aplicar también, en una aplicación WinForms, excluyendo el app.config.

Al abrir la solución vemos la siguiente estructura de carpetas y archivos desde Solution Explorer de Visual Studio 2008.

El primer paso consta de hacer una copia del web.config, para luego renombrarlo como web.config.template. Este témplate nos sirve para almacenar la configuración que requiere la aplicación, en el también podríamos identificar de alguna manera, que cosas vamos a tener que modificar, cada vez que la aplicación se encuentre en un ambiente diferente.

Para esto nos paramos sobre el archivo web.config en el Solution Explorer, hacemos una copia del mismo y lo renombramos como lo dijimos anteriormente.

Luego de subir los cambios, pasamos a excluir el web.config de Source Control.

Para ello, seleccionando el web.config desde el Solution Explorer, debemos ir al punto de menú File / Source Control /Exclude web.config from Source Control como se ve a continuación.

Este último paso hace CHECK OUT del proyecto para marcar al web.config como archivo excluido.

Luego de guardar los cambios debemos eliminar definitivamente al web.config de Source Control, para esto en la solapa Source Control Explorer de Visual Studio 2008, debemos pararnos sobre el archivo web.config y hacer Click Derecho / Delete.

Si en este punto miramos la columna Pending Change, de la solapa Source Control Explorer vamos a ver que marca el archivo web.config como Delete y además hace cambios sobre los archivos del proyecto.

Como solo queremos quitarlo de Source Control y no del proyecto, lo que tenemos que hacer es desde el Source Control Explorer, deshacer los cambios sobre los archivos del proyecto.

Para eso los seleccionamos y hacemos UNDO PENDING CHANGES como se muestra a continuación.

Luego hacemos CHECK IN sobre el web.config , para podes borrarlo definitivamente.

Estos últimos dos pasos, hacen que el web.config desaparezca del árbol de Source Control, pero no lo excluye del proyecto web.

Si ahora observamos nuevamente el Solution Explorer vamos a ver que el web.config sigue apareciendo en la lista de archivos, pero ahora con dos iconos.

El icono rojo indica que el archivo está excluido de Source Control, mientras que el icono amarillo nos dice que no lo tenemos actualmente en el disco local.

El último paso consta de ir a nuestro disco local, hacer una copia del témplate que generamos en los pasos anteriores, y renombrarla como web.config, de esta manera en el Solution Explorer solo veríamos el icono rojo.

A partir de este momento el web.config, está localmente y nunca se va a pisar cuando hagamos Get Latest Version. Es importante aplicar los cambios al Témplate cuando se necesite hacer un cambio en el web.config, y avisar de esto al resto del equipo, para que lo actualice localmente.

De esta manera, cada puesto de trabajo pasa a tener su copia del web.config, que el desarrollador puede modificar cuando quiera, evitando hacer CHECK-OUT cada vez. Por otro lado, cada ambiente donde se instale la aplicación va a tener que tener su propio web.config, la forma de obtenerlo en este caso dependerá del mecanismo que utilicemos como publicación.

Drag and Drop en WinForms

noreply@blogger.com (Benjamin Eidelman) — Fri, 05 Sep 2008 20:09:00 +0000

Hace unos días durante un curso de capacitación un cliente nos comentó que necesitaban implementar una grilla cuyas filas fueran reordenables mediante "drag and drop" (es decir arrastrando y soltando) y vergonzosamente tuvimos que reconocer que apenas teníamos una (muy vaga) idea teórica de como implementarlo.

A la semana siguiente con la intención de dar un respuesta un poco más sólida, dediqué unos minutos a leer un poco y dado que resultaba fácil, armé una pequeña demo para probar el uso de Drag and Drop en WinForms.

Demo

El código puede descargarse de aquí.

En el ejemplo hay un simple DataGridView al cual se puede arrastrar un archivo Xml, cuyo formato sea "convertible" a DataSet, con lo cual la tabla (la primera si hay más de una) se muestra en la grilla (en el ejemplo incluí un Items.xml que sirve a tal fin).

Una vez que tengo filas en la grilla, puedo arrastrar filas con el mouse para modificando el orden.

Esto muestra como realizar Drag n Drop, desde una aplicación externa (Explorador de Windows por ejemplo) hacia un control WinForms propio, y como hacerlo desde y hacia la misma aplicación.

Paso a Paso

Lo primero que necesitamos es iniciar el "arrastre", y una forma posible es en el evento MouseMove del control de origen, para esto agregue en el código de este evento una llamada al método "DoDragDrop" (cuando el botón izquierdo está presionado, etc.), al cual se le debe pasar como argumentos el objeto a arrastrar (en mi caso el DataGridViewRow que se esta arrastrando), que simplemente sirve como información para el control de destino, y la acción deseada, por ej. "Move".
Con esto ya podemos tomar una fila y llevarla por toda la pantalla, sin embargo todavía nadie acepta nuestro "DataGridViewRow", con la cual el cursor muestra el conocido símbolo de prohibido.
Lo que necesitamos ahora es que nuestra grilla diga "Vienes con un DataGridViewRow? Puedes soltarlo aquí!", lo que hace que el cursor se transforme en uno más amigable indicando la acción permitida.
Para esto hay que agregar código en el evento "DragOver", en este una vez que me aseguro que el objeto arrastrado es una DataGridViewRow, perteneciente a mi misma grilla, informo mediante un argumento del evento "DragOver" que la acción permitida es (como fue solicitado) "Move".
Finalmente tengo que hacerlo cuando el objeto es soltado, esto ocurre en el evento "DragDrop", en el cual verifico nuevamente que estoy recibiendo una DataGridViewRow de mi propia grilla, y realizo finalmente el movimiento de filas (lo cual dependerá de la fuente de datos de la grilla (DataTable, DataView, List, etc.).

De forma similar en DragOver y DragDrop espero un objeto con formato "FileName" (el cual nos envía el Windows Explorer) para aceptar archivos .xml sobre la grilla. Lo cual muestra que el origen y destino pueden estar en aplicaciones separadas, y tecnologías diferentes, ya que Drag and Drop es una funcionalidad propia del Sistema Operativo.

Esto por supuesto no abarca todas las posibilidades como por ejemplo mostrar un icono personalizado durante el arrastre, arrastrar información en diferentes formatos, etc. Pero es un buen ejemplito introductorio.

Operadores de conversión (Implícitos y Explícitos)

noreply@blogger.com (Ricardo D. de Guzmán) — Wed, 04 Jun 2008 04:13:00 +0000

Es muy habitual realizar conversiones entre tipos de datos diferentes, por defecto muchos tipos de datos permiten la conversión implícita, esto se da en los casos en los cuales el tipo de dato de origen puede expresarse en su totalidad, como el Tipo de dato de destino, acá podemos ver un ejemplo:

byte valByte = 123;
int valInt = valByte;
double valDouble = valInt;

Como se ve en este caso no es necesario hacer ningún CAST, en cambio para el siguiente caso:

int valInt = 0;
byte valByte = valInt;

Tendriamos un error de compilación “Cannot implicitly convert type 'int' to 'byte'. An explicit conversion exists (are you missing a cast?)”, que nos indica que podemos hacer una conversión explícita, quedando resuelto de esta forma:

int valInt = 0;
byte valByte = (byte)valInt;

"Claro está que de esta manera, el Desarrollador está asumiendo los riesgos de obtener en la variable destino “valByte” información no esperada, si el valor origen “valInt” es superior al soportado por el tipo de dato Byte."

Conversión para clases definidas por el usuario

Desde la versión del .NET 2.0 podemos definir operadores de conversión para los tipos definidos por el usuario, como se puede ver en el siguiente ejemplo:

public class MyClase
{
public double valor;

/// <summary>
/// Permite la conversion implicita
/// desde Double hacia MyClase
/// </summary>
/// <param name="arg">Desde
/// <returns>Hacia</returns>
public static implicit operator MyClase(double arg)
{
MyClase res = new MyClase();
res.valor = arg;
return res;
}

/// <summary>
/// Permite la conversion implicita
/// desde MyClase hacia Double
/// </summary>
/// <param name="arg">Desde
/// <returns>Hacia</returns>
public static implicit operator double(MyClase arg)
{
return arg.valor;
}
}

public class MyClase2
{
public double valor;

/// <summary>
/// Permite la conversion explicita
/// desde Double hacia MyClase
/// </summary>
/// <param name="arg">Desde
/// <returns>Hacia</returns>
public static explicit operator MyClase2(double arg)
{
MyClase2 res = new MyClase2();
res.valor = arg;
return res;
}

/// <summary>
/// Permite la conversion explicita
/// desde MyClase hacia Double
/// </summary>
/// <param name="arg">Desde
/// <returns>Hacia</returns>
public static explicit operator double(MyClase2 arg)
{
return arg.valor;
}
}

En este caso la clase MyClase permite la conversión implícita con double, mientras que en la clase MyClase2 la conversión es explícita, la utilización de estas clases podría ser la siguiente:

double valDouble = 22;

MyClase myClase = new MyClase();
// Conversión implicita en ambos casos
valDouble = myClase;
myClase = valDouble;


MyClase2 myClase2 = new MyClase2();
// En este caso se requiere del CAST
valDouble = (double)myClase2;
myClase2 = (MyClase2)valDouble;

En resumen

Vimos un modo sencillo de implementar mecanismos de conversión entre tipos definidos por nosotros, generalmente entre tipos numéricos.
Otro modo de hacerlo es implementar System.IConvertible para utilizar la conversión a través de System.Convert, lo cual nos permite especificar la conversión por cultura.

Conferencia online - IIS 7 para desarrolladores

noreply@blogger.com (Jose Marcenaro) — Mon, 19 May 2008 19:30:00 +0000

En esta presentación online de MSDN (20/mayo/08) que realizamos con Carlos Walzer, destacamos algunos de los aspectos de la nueva plataforma de hosting en Windows Server 2008 y Windows Vista, enfocados desde la óptica de los desarrolladores.

Puede descargar aquí la presentación (.PPTX) y el ejemplo de código DemoWebsite con la extensión de consola para el administrador de IIS7. Los ejemplos están desarrollados con Visual Studio 2008.

NOTA: al abrir en Visual Studio la solucion de la consola administrativa, puede pedir una contraseña para el archivo de claves encriptadas. La misma es 123456

Linq to SQL y Stored Procedures

noreply@blogger.com (Benjamin Eidelman) — Wed, 14 May 2008 18:36:00 +0000

Continuando con el artículo anterior sobre Linq to SQL en la Dal, donde explica el rol que siguen cumpliendo los Stored Procedures. Razón por la cual esta entrada se llama "Linq to SQL y Stored Procedures" y no "Linq to SQL vs. Stored Procedures").

Las razones más importantes son:

Las consultas Linq to SQL se traducen en queries SQL, no son procedimientos: con Linq to SQL no podemos aprovechar tablas temporales, estructuras de control (if-else, loops, cursores), devolver múltiples resultsets, operaciones por lotes (UPDATE, DELETE), etc.
Performance, desde hace varias generaciones SQL Server sabe como optimizar código Transact-SQL en Stored Procedures. Más aún, la traducción de Linq a SQL, aunque evolucione con el .Net Framework, no siempre genera los mejores resultados, existirán los casos en que necesitemos escribir nuestro propio Transact-SQL.

Como ejemplo de esto el .Net Framework 3.5 SP 1 Beta reducirá la cantidad de tablas usadas en ciertos joins.

Seguridad, son limitados los escenarios en que nuestra aplicación tiene acceso total a las tablas de la base de datos. Es habitual que nuestro DBA, por razones de seguridad y desacoplamiento entre modelos de datos, limite el acceso al SQL Server a la ejecución de Stored Procedures.

Llegamos a la conclusión de que, en general, no podemos prescindir de los SP, la buena noticia es:

Linq to SQL incorpora un manejo simple de SP que permite realizar cualquier tipo de operaciones sobre los datos vía SP.

Pero la mala noticia es:

El O/R Designer con el cual editamos gráficamente nuestros Dbml, no soporta completamente el uso de SP.

Mientras esperamos que la mala noticia se solucione con actualizaciones del VS2008, en algunos puntos tendremos que tocar algo de código manualmente.

Generación de wrappers

Primero vamos a incorporar los SP que queremos invocar a nuestro dbml, para esto basta con arrastrarlos a la zona de métodos (a la derecha en el O/R Designer), esto generará en nuestro DataContext un método para cada SP, con el mismo nombre y lista de parámetros.

Ahora podemos invocar estos SP con intellisense, comprobación de tipos, y control sobre cada invocación (detección temprana de errores, mayor mantenibilidad y desacoplamiento).

Esto genera también para cada SP una clase que representa el tipo de resultado detectado, una clase con propiedades públicas análogas a las columnas del resultado devuelto, esto le permite a Linq to SQL devolver de la invocación de estos métodos wrappers una colección de estos objetos.

El nombre que tienen estas clases por defecto será "NombreDelStoredProcedureResult", y esto es invisible desde el O/R Designer, por lo tanto si queremos cambiar el nombre de la clase de resultados (por ej: ListarClientesPorZonaResult a Cliente), será necesario meterse en el Designer.cs asociado al dbml, cortar esta clase, pegarla en otro archivo (por ejemplo junto con el resto del modelo de datos), y aquí cambiarle el nombre (el código autogenerado se pisa cada vez que tocamos el dbml).

Ahora resta actualizar el wrapper del SP con el nombre del tipo devuelto, desafortunadamente el O/R Designer solo nos permite especificar como tipo devuelto una entidad que se encuentre visible en el mapa dbml, lo cual no siempre es posible si queremos compartir estas entidades entre otros dbml, o mover las entidades a un assembly separado. Inclusive tampoco es posible con el O/R Designer especificar múltiples resultados (típicamente utilizado para devolver entidades cabecera-detalle).

Si podemos hacer esto "tocando" los wrappers auto-generados, para lo cual tenemos 2 opciones:

Una vez generados, mover los wrappers a una partial class del DataContext, y modificando manualmente los atributos que decoran los wrappers, especificar tipos devueltos, inclusive múltiples resultsets. Ejemplo:

        [Function(Name = "dbo.LeerClienteConPedidos")] 
        [ResultType(typeof(Cliente))] 
        [ResultType(typeof(Pedidos))] 
        public IMultipleResults LeerClienteConPedidos([Parameter(Name = "IdCliente", DbType = "Int")] System.Nullable<int> idCliente) 
        { 
            IExecuteResult result = this.ExecuteMethodCall(this, ((MethodInfo)(MethodInfo.GetCurrentMethod())), idCliente); 
            return (IMultipleResults)result.ReturnValue; 
        }

esto indica que el SP devuelve 2 resultsets, el primero con Clientes, y el segundo con Pedidos.

Reemplazar el generador de código por defecto MSLinqToSQLGenerator, por uno que genere los wrappers "a gusto", lo cual afortunadamente resulta más simple de lo que parece. Nuestro generador de código ULinqGen podría extenderse para realizar esto.

Aplicar cambios

Una vez obtenidas colecciones de entidades existentes en la base de datos, por defecto, Linq to SQL activa para todas ellas un control de cambios (cuando estos objetos notifican sus modificaciones mediante eventos). Cuando se detectan modificaciones, se mantiene en el DataContext un "change set", que permite luego aplicar todos esos cambios en la base de datos.

Cuando se llama al método SubmitChanges() del DataContext, Linq to SQL genera y ejecuta una serie de comandos UPDATE, INSERT y DELETE necesarios para reflejar los cambios en la base de datos.

Sin embargo es común que necesitemos realizar algún tipo de verificación o auditoría al momento de realizar estas operaciones. Es por esto que desde el O/R Designer es posible configurar el "Behavior" de una entidad, defiendo el método a invocar para realizar un UPDATE, un DELETE o un INSERT de esta entidad, en lugar del SQL auto-generado.

Carga de entidades asociadas

Por último, existe un uso de estos wrappers de SP un poco más desconocido, revelado por Dinesh Kulkarni, en su blog.

Cuando existen foreign keys entre 2 tablas del SQL, en el dbml se generan asociaciones, que se ven como colecciones de detalle (EntitySet) dentro las entidades maestro. Ej:

Cliente c = ...
for each (Pedido p in c.Pedidos) 
{
...
}

La forma en que se obtienen los Pedidos para un Cliente, es por defecto mediante un query Linq generado a partir de la foreign key, sin embargo es posible definir esto mediante un método propio, definido en una partial class del DataContext.

Ejemplo:

public partial class VentasDataContext {

    public IEnumerable<Pedido> LoadPedidos(Cliente c) {
        return this.LeerPedidosPorCliente(c.IdCliente);
    }

    public Cliente LoadCliente(Pedido p) {
        return this.LeerCliente(p.IdCliente);
    }
}

El método LoadPedidos es llamado al cargar la propiedad Pedidos en un Cliente, y el segundo al cargar la propiedad Cliente en un pedido.

Esto funciona tanto para carga deferida (deferred loading) como para carga inmediata (utilizando el método LoadWith<T>()).

Conclusiones

Teniendo estos features podemos decir que el uso Linq to SQL para invocar Stored Procedures, nos atrae por estas ventajas:

Integración con Linq to SQL (a través de compartir un mismo modelo de datos).
Wrappers para invocación de SP, con las ventajas de tener comprobación de tipos en los parámetros, intellisense, y control sobre las invocaciones.
Materialización de objetos (POCO) para los resultados (en lugar de sólo DataSets).

y preocupan estas desventajas:

Una invocación a Stored Procedures un poco oscura, que no permite demasiada personalización. Por ejemplo no es posible interceptar errores, tocar la lista de parámetros, o forzar reintentos, etc. de forma global.
Solo funciona (en la versión actual) con MS SQL Server.

En el artículo anterior, José explica con más detalle razones que justifican mantener un mecanismo separado para las invocaciones a procedimientos almacenados.

Por lo tanto, exploramos la posibilidad de tener las ventajas mencionadas, sin las desventajas mencionadas.

Para esto trabajamos en el desarrollo de estas herramientas:

Un generador de wrappers, esto nos permitiría solucionar el problema de los tipos de retorno custom y/o múltiples, y la posibilidad elegir el mecanismo de invocación.
Un materializador de objetos que proyecte colecciones de objetos POCO de cualquier DataReader, permitiéndonos invocar SP con ADO.Net puro, EnterpriseLibraries, etc. En nuestro blog en inglés escribí un articulo con algunos prototipos de materialización de objetos

Hasta pronto,

LINQ para SQL, ¿reemplaza por completo a la DAL?

noreply@blogger.com (Jose Marcenaro) — Mon, 03 Mar 2008 11:21:00 +0000

O dicho de otra forma: Si usamos LINQ, ¿podemos olvidarnos de nuestros componentes propios o genéricos de acceso a datos? (por ej. Data Access Block de Enterprise Library). Para dar una respuesta simple: NO, de ninguna manera.

Al menos si consideramos cualquier aplicacion basada en SQL Server que no sea trivial (en cuanto a su modelo de datos o la concurrencia de usuarios), no hay mucha duda de que los procedimientos almacenados siguen teniendo un rol clave en el acceso a los datos.

Su funcionalidad ahora puede ser complementada con consultas o actualizaciones directas via LINQ, en una mezcla cuya proporcion dependerá del contexto de la aplicación: desde "sólo procedimientos almacenados" en algunos entornos corporativos, hasta escenarios con una buena proporción de consultas LINQ en otros entornos. En cualquier caso, las consultas complejas y actualizaciones críticas requerirán ser implementadas como procedimientos almacenados.

Una vez establecido esto, volvemos a la pregunta inicial: ¿es necesario "duplicar" el código de acceso a datos, teniendo en cuenta que LINQ para SQL ya implementa la conexión con la base de datos y tiene un mecanismo para la invocación de procedimientos almacenados?

Se me ocurren varias razones que justifican mantener un mecanismo separado para las invocaciones a procedimientos almacenados:

Posibilidad de control: típicamente hay una serie de tareas y controles que se aplican antes y despues de las invocaciones, en el código genérico de invocacion de SP: revisar y completar parámetros (ej. Id del usuario autenticado), manejar excepciones, ajustar timeout de la conexion, etc.
Capacidad de retornar distintos tipos de resultado: ej. valores escalares, Data Readers, XML Readers
Posibilidad de retornar datasets en forma sencilla. Si, por supuesto. ¿o acaso la aparición de LINQ significa la extinción de los datasets? En muchas situaciones, un dataset sigue siendo una forma muy simple y eficiente de trasladar datos tabulares entre capas de la aplicación.
Capacidad de retornar tambien colecciones de objetos (o instancias simples) como resultado de la invocación a un procedimiento almacenado. Esto puede realizarse mediante código propio (examinando atributos de las entidades o utilizando Reflection sobre los miembros) o utilizando el método Translate del mismo DataContext de LINQ to SQL. Esto último requiere atributos LINQ en la definicion de las clases, pero estos atributos son creados automáticamente por nuestro generador de código asociado a un modelo DBML que se edita con el mismo diseñador O/R de Visual Studio 2008.

Como criterio de aplicación, nosotros en general utilizamos la siguiente regla:

Todas las invocaciones a procedimientos almacenados las realizamos a traves de la DAL (Data Access Layer) propia, aún las que retornan colecciones o instancias de entidades.
Para las consultas y actualizaciones de LINQ sobre SQL utilizamos el mecanismo de acceso a datos incluido en el Data Context.

Esta combinación le da, a nuestro "framework" de construcción de aplicaciones, la máxima flexibilidad para adaptarse a distintos escenarios y aún a distintos casos de uso dentro de la misma empresa (ej. un sistema de reserva de salas no requiere la misma complejidad de solución que un sistema de gestión de inventarios).

Nuevo blog: Pampa Notes on Software Trends

noreply@blogger.com (Benjamin Eidelman) — Fri, 29 Feb 2008 18:08:00 +0000

Finalmente después de preparar algunos artículos iniciales decidimos lanzar un nuevo blog, al cual decidimos telúricamente llamar: Pampa Notes on Software Trends

Contenidos

Este nuevo blog no viene a reemplazar el actual, sino que tiene como objetivo volcar puntos de vista, notas, conclusiones que irán surgiendo al incursionar en nuevas tecnologías.

De ninguna forma esto implica convertirnos en "evangelizadores" de los más recientes productos Microsoft, sin embargo tenemos la obligación de ensuciarnos un poco en las tecnologías pujantes para poder tener criterios justificados sobre su adopción en los escenarios que se nos presenten.

Consecuencia natural de esta actividad será el contenido de este nuevo blog.

Linq to SQL

Actualmente existen en Pampa Notes una serie de entradas sobre Linq to SQL, particularmente sobre como incorporar Linq to SQL en una arquitectura N capas.

Desde su lanzamiento ha habido muchas discusiones sobre modos de lograr esto. Y en estos artículos comentamos algunos puntos, como la necesidad de un control de cambios desconectado en las entidades (después de todo en su momento éste es uno de los principales features que los DataSets nos trajeron, véase RowState, HasChanges, etc.), dado que en Linq to SQL los cambios son detectados y registrados por un objeto DataContext encargado de materializar las entidades, se "engancha" a estos para poder luego aplicar todos los cambios realizados.

Sin embargo en una aplicación N capas queremos que nuestras entidades viajen a través de la red, o en Asp.Net queremos que persistan entre postbacks: Queremos entidades desconectadas de su DataContext. Si bien esto no está disponible en Linq-to-SQL "Out-of-the-box" está contemplado y soportado si se reemplazan algunas piezas, y agregan otras.

Como parte de las piezas a reemplazar para este "control de cambios desconectado", subimos a CodePlex una custom tool que nos permite auto-generar nuestro propio código para las entidades Linq, manteniendo la GUI del O/R Designer, más detalles en el sitio del proyecto: http://www.codeplex.com/ULinqGen

Un blog en inglés?

Pampa Notes estará escrito en ingles, con lo cual haremos eventualmente en este blog referencias a lo que ocurra en el otro. Para consolar nuestro espíritu nacional!, el nombre Pampa hace alusión a la llanura de Argentina donde se encuentra Buenos Aires, sede de Tercer Planeta.

El fin del ArrayList

noreply@blogger.com (Ricardo D. de Guzmán) — Tue, 26 Feb 2008 20:36:00 +0000

Desde la versión del Framework 2.0 llego el concepto de Generics, este nos da la posibilidad de definir clases genéricas, donde el cliente de la misma, es el encargado de definir que tipo desea utilizar.

Las ventajas más importantes son las siguientes

Nos evitamos el cast innecesario de objetos y en algunos casos el Boxing y Unboxing
Tenemos la posibilidad de hacer chequeo de tipos en tiempo de compilación
Ganamos claridad en el código

Uno de los lugares donde es utilizado, es en las colecciones de objetos, de ahí la aparición de un nuevo espacio de nombre System.Collections.Generics donde encontramos un grupo de clases muy útiles, referidas al manejo de colecciones con tipos genéricos.

Antes de Generics, la manera mas fácil de tener una colección en memoria, que nos permita

Recorrer sus elementos
Buscar un elemento por índice
Agregar y quitar elementos despues de haber definida la colección

es utilizar la clase ArrayList, que incluso nos deja definir una colección con elementos de tipos diferente, con el problema de no poder hacer ningún tipo de chequeo, además de los problemas de performance referidos a los Cast innecesarios.

Con la llegada de Generics, tenemos una nueva clase llamada List<T>, que viene a cumplir en gran medida con lo que la mayoría de los usuarios de ArrayList esperábamos.

La posibilidad de tener Colecciones de objetos realmente genéricas, donde al momento de utilizarlas uno pueda definir con que tipo quiere trabajar, aprovechando así el chequeo de tipos, Intellisense, sin Cast innecesarios, sin Boxing y Unboxing para tipos por valor, y hasta logrando un código mas legible.

Veamos algunos ejemplos utilizando clases cutom genéricas, para familiarizarnos con la sintaxis, y luego como utilizar estas nuevas listas.

Supongamos un ejemplo ilustrativo, donde queremos tener una propiedad Edad que pueda ser String o Int según la implementación.

Clases cutom sin utilizar Generics

La única manera de tener un tipo Genérico era definirlo como Object

public class Persona
{
private object edad;
public object Edad
{
  get { return edad;}
  set { edad = value;}
}
}

Caso 1, con un tipo por referencia

Persona per = new Persona();
per.Edad = "25";
// En este caso da un error de compilación
// int edad = (int)per.Edad;
// Aca funicona, pero tuvimos que hacer un CAST
string edad = (string)per.Edad;

Caso 2, con un tipo por valor

Persona per = new Persona();
// Boxing innecesario
per.Edad = 25;
// Aca funicona, pero tuvimos que hacer un CAST
int edad = (int)per.Edad;
// Esto falla por no ser un String
// string edad = (string)per.Edad;

Clases cutom con Generics

public class Persona<T>
{
private T edad;
public T Edad
{
  get { return edad; }
  set { edad = value; }
}
}

Caso 1, con un tipo por referencia

Persona<string> per = new Persona<string>();
per.Edad = "25";
// Esto funciona sin necesidad de CAST
string edad = per.Edad;
// Esto código no compila, evitando problemas posteriores
// int edad = per.Edad;

Caso 2, con un tipo por valor

Persona<int> per = new Persona<int>();
per.Edad = 25;
// Esto código no compila, evitando problemas posteriores
// string edad = per.Edad;
// Esto funciona sin necesidad de CAST
int edad = per.Edad;

Listas genéricas

Ahora apliquemos esto a las Listas genéricas, veamos un ejemplo muy común donde uno necesita definir una lista de un tipo de dato en particular, en este caso con un tipo entero.

int suma = 0;
ArrayList numeros = new ArrayList();
numeros.Add(1); // Boxing innecesario
numeros.Add(2); // Boxing innecesario
numeros.Add(3); // Boxing innecesario
numeros.Add(4); // Boxing innecesario
//numeros.Add("cadorna"); Esta linea es valida pero falla en tiempo de ejecucion
foreach (int num in numeros) // Unboxing innecesario
{
suma += num;
}
int valor = (int)numeros[0]; // CAST innecesario al recuperar un valor

En cambio utilizando la nueva clase List<T> este código se veria así

List<int> numeros = new List<int>(); // Se define el tipo a utilizar
numeros.Add(1);
numeros.Add(2);
numeros.Add(3);
numeros.Add(4);
numeros.Add("cadorna"); // Error en tiempo de compilación
foreach (int num in numeros) // Valida en tiempo de compilación
{
suma += num;
}
int valor = numeros[0]; // No necesita CAST
Este segundo caso como se ve es mucho más eficiente.

Algunas conclusiones finales

Como se ve a la hora de necesitar una colección fácil de manipular, de agregar y quitar ítems es mejor utilizar la clase List<T> y dejar de lado ArrayList que solo seria utilizable si queremos mezclar tipos de datos dentro de la misma colección, algo que no es muy recomendable y que seria lo mismo que definir una lista de objetos List<object>.

Linq: Asomándose detrás de escena

noreply@blogger.com (Benjamin Eidelman) — Tue, 05 Feb 2008 18:55:00 +0000

Para entender un poco mejor lo que ocurre al utilizar LINQ to SQL (DLINQ), voy a mostrar con ejemplos prácticos un poco de lo que ocurre cada vez que ejecutamos un query LINQ sobre SQL

Utilizando SqlMetal o el O/R Designer, podemos crear para cada tabla existente en el servidor SQL una colección equivalente, contenida en un DataContext, que representa una vista de nuestra base de datos.

Además, estas tablas son IQueryables, lo que significan que son colecciones de elementos sobre los cuales pueden escribirse queries LINQ, Por Ejemplo:

var query = from p in VideoClubDataContext.Peliculas where p.Genero == "Terror" select p.ClienteConCopia

Enumerando resultados

Peliculas es un IQueryable, por lo tanto también es un IEnumerable. Pero a diferencia de una lista o array en memoria, al enumerar sobre éste, el trabajo de construir el enumerador, es delegado a un "Provider", que en el caso de LINQ to SQL, traduce la expresión C# (o VB.Net) a SQL, y enumera los resultados con un SqlCommand creado por el DataContext (quien conoce el ConnectionString necesario).

Si prestaron atención a las presentaciones de LINQ sabrán que hasta este punto, al construir mi objeto query, todavía ninguna conexión se abrió con el SQL, solo se construyó en memoria la estructura de la consulta (esto es un ExpressionTree que mencionaré más adelante).

Recién al enumerar este objeto query, se construye la sintaxis SQL, y se envía al SQL Server, trayendo los resultados para ser enumerados.

foreach (Cliente cliente in query)
    EnviarMailRecordatorio(cliente.Email);

Una de las primeras dudas que tuvimos es: Qué ocurre si vuelvo a enumerar el objeto query? Existe algún tipo de caché de los resultados?

La respuesta es... no. Simplemente porque enumerar nuestro objeto query, es enumerar la consulta, con lo cual se construye nuevamente la sentencia SQL, se abre (o reutiliza) una conexión con el SQL, y se devuelven los nuevos resultados en la enumeración.

Si queremos enumerar los resultados anteriores nuevamente, podemos hacerlo de esta forma

Cliente[] clientes = query.ToArray();
foreach (Cliente cliente in clientes)
    EnviarMailRecordatorio(cliente.Email);
foreach (Cliente cliente in clientes)
    LlamarPidiendoDevolucionDeCopias(cliente.Nombre, cliente.Telefono);

y evitamos así viajar 2 veces al SQL.

El Árbol de Las Expresiones

Yendo un poco más lejos nos preguntamos que ocurre cuando los parámetros de un query se modifican luego de haberlo construido, y enumerado, dicho de otra forma, que ocurre si ejecuto el siguiente código:

txtDirector.Text = "Kubrik";

// solo por comodidad, utilizo en este query dot-notation
var query = VideoClubDataContext.Peliculas.Where(p => p.Director.StartsWith(txtDirector.Text)).Select(p => p.Titulo);

MessageBox.Show(query.ToArray()[0]);

// modifico una variable que sirve como parámetro en query
txtDirector.Text = "de la Iglesia";


// enumero nuevamente, con el método ToArray() 
MessageBox.Show(query.ToArray()[0]);

El primer mensaje será "2001: Una Odisea del Espacio" (de Kubrik, claro).

La gran pregunta ahora es... que mostrará el segundo mensaje? Si apuestan a que el mensaje es el mismo, perdieron!

El segundo mensaje será "300 Balas" (de Alex de la Iglesia, claro)

Como se entera nuestro objeto query de que el texto de nuestro TextBox cambió? La respuesta es el Expression Tree

Un Expression Tree es un estructura en memoria que representa de forma jerárquica una expresión C# (o VB.Net), no es código compilado, de manera que permite recorrer la expresión del query, convirtiéndola a sintaxis SQL.

Expression Trees es un tema que requiere otros posts, con lo cual sin entrar en más detalles, voy a mostrar algo similar a una parte del árbol que se construye en memoria con nuestro query de más arriba:

LlamadaAFuncion
- nombre = StartsWith
- objeto = Atributo
  - nombre = "Director"
  - objeto = p (Elemento de la coleccion)
- parametro1 = Atributo
  - nombre = "Text"
  - objeto = "txtDirector"

Es decir que el objeto query sabe que debe utilizar como parámetro el valor de la propiedad Text del objeto txtDirector, recién al enumerar el objeto query, esto se traducirá a algo como:

WHERE [t0].[Director] LIKE @p0

donde:

@p0 = 'Kubrik%'

Esto también nos permite comenzar a entender como sintaxis LINQ se traduce en código SQL, y lo que es muy importante, cuando.

Debe pensarse bien en que momento enumerarlos, y cuando utilizar ToArray(), ToList(), etc., para cachear los resultados.

LINQ y LINQ para SQL

noreply@blogger.com (Jose Marcenaro) — Fri, 01 Feb 2008 20:14:00 +0000

Un par de meses después de la liberación pública del Microsoft .NET Framework 3.5 (y su plataforma de desarrollo preferida, Visual Studio 2008), es buen momento para presentar algunas de nuestras impresiones sobre lo que probamos para el uso de estas tecnologías en aplicaciones reales.

LINQ y sus providers

El Language INtegrated Query (consultas integradas al lenguaje) consiste en un conjunto de extensiones introducidas en el runtime de .NET y sus lenguajes principales (C# y VB) que permiten implementar una sintaxis flexible de consulta, y de paso varias cosas más.

La aplicación de LINQ a diversas fuentes de datos, tales como colecciones en memoria, bases de datos relacionales, documentos de estructura jerárquica (XML) y otras, depende de la disponibilidad de los "providers" específicos para ese tipo de origen de datos.

Por eso, al analizar las capacidades de LINQ hay que distinguir entre la tecnología (o sintaxis) LINQ genérica, y los distintos proveedores específicos (LINQ to SQL, LINQ to XML, LINQ to DataSet, etc.) que pueden encontrarse en distinto grado de evolución. Vamos a analizarlos por separado:

LINQ

Una de las ventajas que inmediatamente resaltan al empezar a usar sintaxis LINQ en las aplicaciones, es la enorme simplificación que significa usar una sola sintaxis (una sola API) para operar sobre colecciones absolutamente heterogéneas. Hace unos meses yo conocía perfectamente el método Sort -específico de la clase Array- que permite ordenarlos; una propiedad Sort -en los DataView- que con otra sintaxis logra el mismo efecto sobre las vistas de un datatable. Y recurria a la ayuda en línea cuando necesitaba ordenar un conjunto de nodos XML o cualquier otra cosa. Lo mismo para filtrar, etc.

Felizmente ya me estoy olvidando de todo eso, porque ahora sólo uso expresiones como estas, independientemente de cuál es la coleccion sobre la que opero:

var pedidos = from a in archivos
    where a.Extension == ".xml"
    order by a.Name
    select a;

O su equivalente, no tan natural para leer pero más revelador de lo que ocurre tras la escena:

var pedidos = archivos
    .Where(a => a.Extension == ".xml")
    .OrderBy(a => a.Name)
    .Select(a => a);"

Por supuesto, en ambos casos dejo que el Intellisense haga la mayor parte del trabajo.

Las extensiones que permiten esta sintaxis, como la declaracion anónima de tipos (new { Edad = m.edad, Nombre = ... }) y los métodos de extensión (ej. .Where(), .Select(), etc) tambien hacen que todo el manejo de colecciones propias y de clases de negocio representadas como objetos "custom" sea muchísmo mas fácil y abreviado.

Hasta acá, no hay ninguna duda. Esto es para usarlo, cuanto antes, y no hay retorno.

NOTA: El segundo ejemplo trae reminiscencias de los paradigmas de programación funcional, y eso es exactamente lo que se ha incorporado al runtime .NET, mediante las expresiones lambda (otra de las extensiones incluidas en la nueva versión).

LINQ para SQL

Acá el paisaje es muy atractivo, pero hay que estar atento al camino que empieza a volverse espinoso.

Lo primero que uno nota es que LINQ para SQL está integrado por distintos componentes, algunos de los cuales son más deseables (o están más maduros en su evolución) que otros.

Existe un O/R designer (diseñador Objeto / Relacional), integrado en la IDE de Visual Studio, que permite mapear visualmente las tablas, procedimientos almacenados, etc. de un SQL Server y genera un archivo .DBML (XML) con su estructura.

Hay una herramienta de generación de código ("custom tool") tambien integrada en la IDE, que a partir de ese "mapa" DBML genera código de clases, decoradas con atributos de LINQ, que permiten el posterior armado de consultas LINQ

Las clases generadas se integran con un "Data Context" y otras clases del nuevo namespace System.Data.Linq, que incluyen la lógica de acceso a datos (sin necesidad de utilizar explícitamente las clases de ADO.NET) para traer los objetos de la BD y para persistir los cambios, en una modalidad "conectada" que no siempre resulta la más apropiada.

Finalmente, existe un "provider" de LINQ para SQL que, en base a los atributos de las clases, convierte la consulta LINQ en una sentencia Transact-SQL para enviar al servidor

Para los primeros dos componentes enumerados en esta lista(que se integran en la IDE) existe una alternativa como comando de línea (SqlMetal.exe) que tiene una funcionalidad similar pero no idéntica.

En proximos artículos del blog avanzaremos más sobre las características y escenarios de uso de LINQ para SQL. Por ahora, es importante entender la distincion entre la tecnología LINQ en general -de indudable aplicación- y su actual implementación para SQL, que tiene claros y oscuros.

Jornadas 3P

noreply@blogger.com (Nora Martinez) — Thu, 06 Dec 2007 11:57:00 +0000

En esta oportunidad queremos contarles acerca de nuestra experiencia en lo que denominamos "Jornadas 3P", orientadas a la comunicación e integración de un equipo de trabajo pequeño y al gerenciamiento de los distintos proyectos.

La idea de una Jornada es reunirse en un lugar "neutral", siempre fuera de la oficina, para discutir acerca de diferentes temas que hacen a la empresa y al grupo.

El objetivo principal de estas reuniones es crear un ambiente laboral cómodo y ameno, donde:

cada integrante se sienta parte del grupo, una parte importante,
cada uno pueda expresar sus ideas libremente y
se colabore con el crecimiento tanto de la empresa, como del grupo, y por supuesto, esto tiene una influencia en el crecimiento laboral y personal de cada integrante.

De qué consta específicamente una jornada...

Una jornada es en definitiva una lista de ítems a tratar. Entre estos items se incluyen temas laborales, charlas, recreación o juegos.

Por que incluir juegos… Porque nos parece importante que las jornadas cuenten con espacios para la recreación en conjunto, por lo cual nos gusta incluir juegos y charlas que nos permitan distendernos mientras desayunamos o almorzamos. Esto ayuda a "romper el hielo", así cada uno puede relajarse y sentirse a gusto, sin ninguna presión, y ayuda también a la integración y comunicación del grupo.

Unos días previos a la Jornada se define un cronograma con los ítems a desarrollar, por cada uno se indica: fecha, hora, item y duración, y de ser necesario también se indica un responsable de dirigirlo. Este cronograma se le entrega a cada integrante, con lo cual, al llegar el día de la reunión todos los participantes conocen los temas y el horario de cada uno.

También dentro del cronograma se incluye el horario de cada comida (desayuno, almuerzo, cena).

A Jornadas las podriamos dividir en dos grandes grupos, de acuerdo a la periodicidad con que se realizan:

Jornada trimestral

Se elige algún lugar cerca de la oficina. El mismo tiene que ser cómodo y confortable para que podamos estar reunidos todos juntos o divididos en grupos de 2 o 3 personas, diseminados por el lugar.

En algunos casos elegimos lugares que parecen poco convencionales para una reunión laboral, como por ejemplo el zoológico. Lo importante es elegir el lugar adecuado para crear el ambiente apropiado y así poder tratar los diversos temas con la soltura que necesitamos.

Comienzan a las 9am, con un desayuno y una charla amena, no necesariamente laboral, que permita la participación de todos. Y finalizan con el almuerzo.

Se realizan cada 3 o 4 meses.

Jornada anual

Las jornadas anuales pueden ser de 1 o 2 días completos.

En estas Jornadas se utilizará un pizarrón, se desayunará y almorzará, se realizará algún juego… con lo cual el lugar elegido tiene que tener las condiciones necesarias para que resulte cómodo en el desarrollo de todas las actividades. Una buena ubicación podría ser una quinta.

Las Jornadas de 1 día completo se realizan una vez por año, alrededor de Mayo o Junio.

Comienzan a las 9am y finalizan a las 18hs.

En las jornadas que lleven mas de un día, se elige un lugar "alejado de la civilización", nosotros optamos por la Costa Atlántica (Pinamar o Cariló, como fue este año), y por lo general las realizamos a mediados de Noviembre. También se elige un lugar que nos resulte cómodo tanto para desarrollar las diversas actividades como para hospedarnos.

Que temas se tratan?

Tanto para las Jornadas trimestrales como las anuales, los socios de la empresa son los encargados de decidir cuáles son los principales temas a tratar, y el momento de tratarlos durante la Jornada (ellos realizan el cronograma de items).

Estos temas resultan de inquietudes propias o de los integrantes del equipo, las cuales se exponen al grupo para su posterior evaluación. Por ejemplo, se escriben ideas de temas en un Sharepoint, o se comentan en alguna reunión.

En las Jornadas trimestrales se plantean los posibles temas a tratar en las Jornadas anuales. También se hace una conclusión de cómo resultó lo que se trató en las Jornadas anuales.

En las Jornadas anuales los temas que se tratan estan mas orientados a lo que pasó en el año y lo que esperamos del año próximo.

Cada uno de los temas seleccionado esta dirigido por un integrante del equipo, el cual es responsable del mismo: da una breve introducción, induce al debate entre los integrantes, y en caso de ser un tema a continuar en el tiempo, se lo propone como responsable del seguimiento y cumplimiento de lo acordado.

Los posibles temas a tratar en las Jornadas serian:

cómo se siente cada integrante del equipo, con respecto a las tareas que realiza y al entorno de trabajo
cuales son sus inquietudes y objetivos, tanto laborales, como personales (si quieren comentar, claro)
determinar un plan de trabajo para el año en curso y el siguiente (Jornadas anuales)
para los proyectos finalizados, se analiza qué nos dejó: errores y aciertos, para aplicar el aprendizaje en el futuro
cada integrante expresa su opinión acerca de la empresa: lo que es, lo que espera que sea y el lugar que espera ocupar (Jornadas anuales)

Pinamar - Cariló 2007

Nuestra mas reciente Jornada fue en Noviembre, la cual duró 2 días. El lugar elegido fue un complejo de cabañas sito en Cariló (se encuentra en la Costa Atlántica).

Se trataron diferentes temas, entre los principales podemos destacar:

como ve cada uno a Tercer Planeta: cual es la imagen que tenemos y que queremos lograr, y que hay que hacer para alcanzarlo
expectativas y/o proyectos personales
expectativas con respecto a la Jornada
qué anduvo bien y qué anduvo mal en el año
charlas individuales de los socios con cada integrante
objetivos 2008
comunicación interna (¿Nos comunicamos bien? ¿Qué podemos hacer para mejorar? ¿Hay quejas?)
capacitaciones

Conclusiones

El objetivo principal de realizar una Jornada es facilitar la comunicación e integración del grupo. Mediante charlas, debates, exposición de ideas e inquietudes o juegos se logra poder conocer un poco mas a la persona con la que trabajamos y convivimos todos los días, y logramos poder hablar libremente.

Otro objetivo importante es poder definir los lineamientos de la empresa, tener la capacidad de ver los aciertos y errores, para potenciar y corregir lo necesario y establecer un plan de trabajo tanto de la empresa como de los integrantes.

Cuando los objetivos son claros y conocidos, es sencillo alcanzarlos...

Cuando el grupo esta integrado y motivado, ¡el trabajo resulta menos denso y el ambiente laboral resulta agradable!

Por lo cual les recomendamos ampliamente la práctica de una Jornada, de acuerdo a las necesidades y estructura organizacional.

¡Animense! ¡No es imposible!

Uso de Team Foundation Server Source Control en VB6: proveedor MSSCCI para TFS

noreply@blogger.com (Jose Marcenaro) — Thu, 06 Dec 2007 10:35:00 +0000

Para quienes hemos adoptado Visual Studio 2005 Team Foundation Server como administrador de código fuente, una necesidad frecuente es la de integrar en el mismo repositorio el trabajo desde otras herramientas anteriores a VS 2005, por ejemplo Visual Basic 6.0, Visual FoxPro 9, Visual Studio .NET 2003, etc.

Para estos casos Microsoft ha liberado en diciembre 2006 el proveedor MSSCCI correspondiente a Team Foundation Server, haciendo posible la integracion de código fuente con TFS en cualquier herramienta compatible con el estandard MSSCCI. El software puede descargarse aquí: http://www.microsoft.com/downloads/details.aspx?FamilyId=87E1FFBD-A484-4C3A-8776-D560AB1E6198&displaylang=en

Debe tenerse en cuenta que este proveedor MSSCCI es sólo el conector entre las herramientas cliente y el TFS, y no incluye un "explorador" del arbol de código similar al Team Explorer (TFS) o el Source Safe Explorer (VSS). Para esas tareas de exploración debe utilizarse (y de hecho es un prerequisito de la instalación) el Team Explorer, que es una extensión a la IDE de Visual Studio 2005

Lo que el conector sí realiza, en herramientas que tienen integración con un Source Control Provider, es permitir que dentro de la IDE respectiva (p.ej. en VB6, o VFP 9, VS.NET 2003) se acceda en forma transparente al repositorio de código montado en Team Foundation
Server.

Veamos por ejemplo los pasos para integrar en un proyecto VB6 el control de código de TFS

Instalar Team Explorer, incluido en el CD de instalación de Team Foundation Server
Instalar el proveedor MSSCCI descargado del link mencionado previamente
Verificar que Visual Basic tenga aplicado el ultimo Service Pack (SP6, actualmente)
Cerrar y reiniciar la IDE de VB si está abierta.
Desde la IDE de VB, en la opción Add-ins / Add-in manager... del menú, seleccionar activar la opcion "Source Code Control", (asignarle Startup + Loaded)

Una vez cargado el add-in, pueden realizarse las operaciones normales de integracion con source control utilizando el menú contextual sobre el explorador de proyectos (check-in, check-out, etc) y las opciones de menu (Toosl / Team Foundation).
Asimismo, al grabar un proyecto no integrado a Source Control aparecerá el diálogo consultando si se desea agregarlo.

Para otras operaciones más específicas sobre el repositorio de código (ej. modificación de workspaces, operaciones de "branch" y "merge", etc) se utiliza la interfaz visual del Team Explorer.

Notas:

Si en VB6 no está disponible el add-in de "Source Code Control" luego de aplicar el SP6, seguir los pasos descriptos en este artículo de la KB: http://support.microsoft.com/kb/305024/
Si se desea alternar entre el proveedor de TFS y el proveedor de Visual Source Safe, pueden seguirse los pasos descriptos en la sección "How to Switch MSSCCI Providers" en este artículo: http://blogs.msdn.com/edhintz/archive/2006/04/10/572826.aspx

LINQ: el futuro se nos vino encima

noreply@blogger.com (Jose Marcenaro) — Wed, 21 Nov 2007 14:10:00 +0000

... y cuando quisimos darnos cuenta, ya estaba acá

Anteayer (19/11/07) Microsoft hizo públicos

el runtime de .NET Framework 3.5
las versiones de evaluación de Visual Studio 2008
y, para los suscriptores MSDN, la versión RTM de Visual Studio 2008

Hay tantas novedades en esta version del producto....

En nuestra opinion, el mayor impacto (y el mayor trabajo de difusión, discusión y esclarecimiento) gira en torno a LINQ y las extensiones a los lenguajes C# y VB que lo soportan.

Se abre un mundo de posibilidades que hay que explorar, entender, elegir...

Vuelva a este blog para más discusiones sobre el tema, en breve!

Jose.

Las buenas prácticas de desarrollo siempre pagan

noreply@blogger.com (Jose Marcenaro) — Mon, 12 Nov 2007 23:24:00 +0000

En estos días estuvimos evaluando un conjunto de aplicaciones desarrolladas durante los últimos siete años por una importante cadena de supermercados en Argentina, en el lenguaje Visual FoxPro.

Cuando en 2000 se inició el proyecto de reemplazo de su sistema completo de gestión comercial y de inventarios, nos convocaron para participar en la definición de la arquitectura y la construcción de un framework de clases que sirviera de base para el crecimiento futuro de la aplicación.

Siete años y más de cien mil horas de horas de programación despues, nos tocó evaluar la factibilidad y costo de la conversión a .NET (C#) de toda la lógica de negocios, desarrollada en VFP por un equipo de programadores que se sucedieron en el tiempo agregando funcionalidad y nuevos módulos

Para la evaluación desarrollamos un parser en C#, que realiza un análisis “drill down” del código Visual FoxPro analizando las clases y métodos y verifica cuánto del código es mapeable a expresiones simples con invocaciones a métodos básicos (y por lo tanto, es convertible en forma automática con una herramienta a desarrollar).

En este proceso de evaluación constatamos algunas suposiciones iniciales, y nos llevamos algunas sorpresas:

Arquitectura. Tal como se esperaba, lo que por diseño se concibió para ser interoperable participa a la perfección en el proceso de evolución de la arquitectura:

Los componentes de negocios, todos implementados como componentes COM que intercambian XML y acceden a datos en SQL Server, pueden ser “mapeados” exactamente a los nuevos componentes en .NET implementados como servicios.
En la capa de presentación, el hecho de haber implementado desde el principio un “dispatcher” que centraliza las invocaciones a la capa de negocios permite introducir fácilmente un conmutador de las llamadas para encaminarlas a los componentes COM originales o bien a los nuevos servicios .NET (Strategy Pattern, GOF).
Esto permitirá que la conversión de la lógica de negocios y el reemplazo de componentes se realice en forma gradual, y de hecho permitiría escenarios de coexistencia de las tecnologías en forma permanente, si esa fuera la estrategia deseada.

Prácticas de desarrollo. Con cierta sorpresa, dada la cantidad de programadores que se alternaron durante el proceso de evolucion de las aplicaciones, constatamos un muy alto nivel de calidad y de homogeneidad en las prácticas de desarrollo:

De los más de 12000 métodos presentes en la capa de negocios, más de 7000 tienen de 1 a 10 líneas de código, y otros 2000 entre 11 y 20 líneas; con un altísimo grado de reuso de los métodos y clases base para la funcionalidad de uso frecuente.
El análisis sintáctico del código permite estimar en más de 8500 los métodos directamente convertibles en forma automática, por consistir en invocaciones a métodos del framework propio con expresiones o comparaciones simples (If …. Then, etc), con otros 2000 métodos que también pueden convertirse en forma automática pero requieren algun grado de revision manual.

En conclusión, y sin minimizar la magnitud que requerirá una tarea de migración tecnológica tan importante (por la evolución cualitativa que representa .NET), constatamos con satisfacción que el costo inicial de desarrollar una arquitectura distribuida, interoperable, y de establecer un marco y prácticas de desarrollo precisas, tiene un triple efecto de devolución:

En la calidad del sistema, que permitió el crecimiento y evolución de la cadena durante estos años, y su mantenibilidad aún cuando los equipos vayan renovandose.
En la posibilidad concreta, y ya puesta en práctica, de integrar los componentes originales con otros desarrollados en tecnologías radicalmente nuevas, sin necesariamente encarar una reconversión completa.
En las enormes ventajas, en caso de encarar una reconversión, de partir con mucho terreno ganado y una proporcion muy mayoritaria de código que puede convertirse automáticamente.

Considere estos factores a la hora de encarar su próximo proyecto: “quick and dirty” (rápido y sucio) no siempre siempre resulta rápido; pero casi con seguridad va a resultar sucio y finalmente caro.

Seguridad integrada con SQL Server en un sitio web ASP.NET

noreply@blogger.com (Jose Marcenaro) — Wed, 20 Jun 2007 22:39:00 +0000

Una consulta muy frecuente que recibimos es “como configurar un sitio web para acceder a SQL Server mediante seguridad integrada”, bajo la situación más habitual (y recomendada) que es aquella en la cual los usuarios que acceden al sitio no utilizan seguridad integrada de Windows o, aún en caso de hacerlo, no tienen asignados permisos individuales de acceso a la base de datos de la aplicación.

La implementación de este escenario, en la plataforma actual de servidores Web de Windows (Windows Server 2003), consta de los siguientes pasos:

1. Definir un usuario del dominio para ejecutar la aplicación web y acceder al SQL Server

Crear una cuenta de usuario en Active Directory, designada para ejecutar las aplicaciones web y acceder al SQL Server. Es recomendable que esta cuenta no sea administrador del dominio, ni del equipo en que ejecuta el website o el SQL Server.

2. Asignar permisos a ese usuario en Microsoft SQL Server

Mediante el SQL Server Management Studio (SQL Server 2005) o el SQL Server Enterprise Manager (SQL Server 2000) definir, dentro de la seccion Security, una cuenta (login) de seguridad integrada correspondiente a la cuenta designada del dominio; asignarle permisos sobre las bases que corresponda, solamente con los privilegios que requiera para ejeutarse.

3. Preparar la cuenta para ejecutar aplicaciones ASP.NET

Este es un paso comunmente omitido, que resulta en la imposibildad de ejecutar correctamente el sitio.
En el equipo en que se ejecuta el sitio Web (Internet Information Server) configurar lo siguiente:

Asignar a la cuenta designada permisos de control total sobre la carpeta temporaria de Windows (habitualmente C:\Windows\Temp).
Desde la línea de comandos posicionarse en la carpeta correspondiente al framework .NET en uso (por ejemplo C:\Windows\Microsoft.NET\Framework\ v2.0.50727) y allí ejecutar el siguiente comando:
aspnet_regiis –ga {dominio\cuenta}
reemplazando {dominio\cuenta} por la cuenta designada en el paso 1

4. Asignar la cuenta designada como identidad del proceso ASP.NET

En Windows Server 2003, eso se realiza en la consola de Administración de Servicios Internet (IIS) asignando la identidad del Application Pool que se utiliza para ejecutar la aplicación Web.
IMPORTANTE: si la aplicación está configurada para ejecutar en el “Default App Pool”, u otro compartido con múltiples aplicaciones, puede ser conveniente definir un application pool separado para los sitios que deban ejecutarse bajo esta cuenta de usuario, y asignar los sitios al App Pool creado.

5. En la aplicación ASP.NET, asegurarse que no esté activa la “impersonación”

Si se utiliza Authentication mode=”Windows”, asegurarse que en el archivo Web.config no exista un elemento <identity> o, si existe, asegurarse de que tenga asignado el atributo impersonate=”false”.
De ese modo, el proceso se ejecutará con la cuenta designada.
NOTA: sin necesidad de impersonar, desde el código de la aplicación Web puede conocerse el nombre de la cuenta autenticada mediante la propiedad User.Identity

Con estos pasos, se lograrán los objetivos buscados:

Evitar incluir nombres de usuario y password en la configuración de la aplicación (o en cualquier otro componente de la misma)
Ejecutar el sitio web con una cuenta que no tenga más privilegios de los requeridos
Evitar otorgar permisos sobre la base de datos a los usuarios del sitio.

SQL Server 2005 sobre Windows Vista

noreply@blogger.com (Jose Marcenaro) — Tue, 12 Jun 2007 13:01:00 +0000

Dos recomendaciones muy importantes para utilizar SQL Server 2005 sobre el sistema operativo Windows Vista

1) En todos los casos (se trate de las herramientas cliente, o el motor de base de datos) instalar el Service Pack 2 de SQL Server 2005
http://www.microsoft.com/downloads/browse.aspx?displaylang=es&productID=9F07F9CC-C308-4EBF-A4E9-2B8530AB1EA8

2) Adicionalmente, si se ha instalado el server (motor de base de datos) sobre uno de estos sistemas operativos, tener en cuenta que cambia el manejo por defecto de la seguridad:

Al instalar un SQL 2005, automáticamente se agrega un login para el grupo BUILTIN\Administrators, con permisos de sysadmin.
Sin embargo, el manejo de seguridad de Windows Vista hace que un usuario, aunque sea administrador del equipo, no ejecute las aplicaciones como tal salvo cuando lo hace con "privilegios elevados" (Run as administrator)

Por lo tanto hay dos opciones para que un usuario administrador del equipo tenga privilegios completos de administracion del SQL Server 2005 en ese equipo:

a) [No recomendado] Ejecutar el SQL Server Management Studio mediante la opción "Run as Administrator"

b) [Recomendado] Empleando el "SQL Server Surface Area Configuration", agregar la cuenta del usuario para que actúe como administrador (opcion Add New Administrator)

Para más información sobre las buenas prácticas de administración y operación SQL Server 2005, puede descargarse este documento de Microsoft (en inglés):

SQL Server 2005 Security Best Practices - Operational and Administrative Tasks

Exception Handling y Logging con Enterprise Library 3.0

noreply@blogger.com (Benjamin Eidelman) — Mon, 11 Jun 2007 13:27:00 +0000

En este artículo voy a mostrar como agregar un manejo simple de excepciones, y luego logging de éstas y otros eventos usando Enterprise Library 3.0, sin profundizar en todas las posibilidades que éstas librerías ofrecen.

Usaremos en este ejemplo los siguientes bloques de Enterprise Library 3.0:

Exception Handling Application Block
Logging Application Block (que registrará Excepciones recibidas por el bloque anterior, y otros mensajes de bitácora)
Data Application Block (para permitir al bloque anterior, Logging sobre una base de datos SQL)

(Es condición previa en el ejemplo siguiente, agregar referencias en nuestro proyecto a los assemblies correspondientes)

De la aplicación de ejemplo realizada en C#, nos interesa el siguiente bloque de código:

Vamos a trabajar sobre este método, que resulta crítico para nuestro sistema, por lo cual queremos una bitácora de su ejecución y resultado.

Exception Handling Application Block

Este bloque nos permite delegar el manejo de una excepción a una policy definida en archivos de configuración. En particular nos permitirá encapsular, reemplazar, absorber excepciones, o enviar éstas al Logging Application Block para registrarlas en una bitácora.

Para esto basta con modificar nuestro código de la siguiente manera:

Interceptamos cualquier tipo de Exception, y la manejamos con el método estático:

ExceptionPolicy.HandleException()

Éste recibe la excepción a ser manejada, el nombre de la policy a aplicar (a continuación vamos a definir esta política), y opcionalmente un parámetro out en el que se devuelve la excepción que reemplaza a la original (esto sucede cuando la policy utilizada decide que la excepción debe ser reemplazada o contenida dentro de una nueva), si la excepción no debe ser reemplaza este parámetro toma el valor null.

Este método devuelve true si la excepción (o la excepción que la reemplaza) debe ser relanzada.

Ahora sólo resta definir nuestra "TareasPolicy", para eso alcanza con editar el archivo de configuración (app.config, web.config, *.config) con la herramienta gráfica que incluye Enterprise Library (Enterprise Library Configuration Tool), con la cual resulta trivial lo siguiente:

Agregar un bloque de configuración para Exception Handling, y dentro de éste crear una nueva policy con el nombre "TareasPolicy".
Definir en esta policy para el tipo de excepción Exception (es decir para todas), un Logging Handler, y definimos para este Handler, que las excepciones produzcan entradas de Log de nivel "Error" (lógicamente), y con la categoría "Errores", vamos a ver que implica esto a continuación.

Dentro de una policy podemos definir también los siguientes Exception Handlers, que pueden utilizarse según el tipo de Exception lanzada:

Wrap Handler: Envuelve la excepción lanzada dentro de una nueva.
Replace Handler: Reemplaza la excepción con una nueva.
Logging Handler: Transfiere la excepción al Logging Application Block para poder registrarla en una bitácora.
Custom Handler: Permite manejar una excepción utilizando una clase definida en nuestra aplicación.
Fault Contract Exception Handler: Facilita el manejo de excepciones en aplicaciones SOA.

Logging and Instrumentation Application Block

Necesitamos ahora indicar como serán tratadas en este bloque las excepciones recibidas, pero antes es preciso definir las entidades más importantes en este bloque:

Trace Listener: Manejan los eventos registrándolos o emitiéndolos en distintos medios, son los siguientes:

Formatted EventLog: registra los eventos en el EventLog del sistema.
Flat File: simplemente almacena los eventos en un archivo de texto plano.
Rolling Flat File: utiliza un archivo de texto, que al alcanzar una antigüedad o támaño máximo se cierra y comienza uno nuevo.
Xml: en este caso el log generado es un documento xml, asimismo las entradas pueden contener un campo xml.
Email: envía notificaciones de eventos a traves de un servidor SMTP.
Msmq: utiliza Microsoft Message Query como destino de los eventos.
WMI: los eventos se manejan con Windows Management Instrumentation.
Database: Cuando recibe un evento, invoca un stored procedure con sus datos como parámetro. (Requiere el Data Access Block, para definir la base de datos a utilizar).
Custom: Si los anteriores no son suficientes, puede manejarse los eventos mediente una clase definida nuestra aplicación. Esto nos permitiría por ejemplo, mostrar un MessageBox, enviar el error con un POST HTTP, etc.

Formatter: Se encarga de serializar eventos, para facilitar su almacenamiento, son los siguientes:

Text Formatter
Binary Formatter
Xml Formatter
Custom Formatter

Event Sources: Representan fuentes de eventos, se les puede asociar uno o más Trace Listeners.
Pueden definirse segun categoría de los eventos, y están predifinidas adicionalmente las siguientes sources especiales:

All Events: Como su nombre lo indica, recibe todos los eventos de la aplicación.
Unprocessed category: Eventos de categorías no procesadas.
Logging Errors & Warnings: Recibe errores y advertencias producidos al registrar otros eventos (por ejemplo, caída del servidor del SQL, al intentar almacenar un evento en éste), permite una especie de "manotazo de ahogado", lo que hace apropiado asociar a esta fuente el Event Handler más "infalible", por ejemplo, Formatted EventLog.

Filters: Permiten filtrar eventos, según categoría, prioridad, o mediante clases personalizadas.

Ahora utilizamos una vez más la herramienta de edición de archivos de configuración para lo siguiente:

Definir el bloque de configuración para el Logging Application Block.
Definir el Category Source "Errores" como fue definido en el Exception Handling Block, este recibirá las Exceptions interceptadas por éste, y asociaremos a este un Database Handler, para crear nuestra bitácora en una base de datos.
Crearemos (si no existe aún) la configuración para el Data Access Application Block, donde definiremos el connection string.
Referenciar esta base de datos en nuestro Database Trace Listener, e indicar en éste el nombre del stored procedure que debe invocarse para agregar una entrada al log, y el stored procedure que se invoca inmediatemente después para indicar la categoría de ese evento (es por esto que el primer stored procedure, debe devolver el id de la entrada creada).
Dado que nuestra conexión con la base de datos puede fallar (y queremos saber cuando!), agregamos un Formatted Event Log Trace Listener, y asociamos este al "Logging Errors & Warning" Special Source, para registrar en el EventLog los errores que ocurran al intentar usar la base de datos.

Por último aprovecharemos el Logging Application Block, para registrar también información adicional sobre la ejecución de nuestra tarea, para eso asociaremos nuestro Database Trace Listener al Special Source "All Events" (es posible definir un Trace Listener, o una categoría especial de eventos para este caso)

Ahora podemos modificar nuestro código C# de esta manera:

El método estático Logger.Write(), puede recibir también varios parametros adicionales como categoría, prioridad, severidad, etc.

Conclusiones

Las políticas de manejo de errores y logging, son totalmente independientes del código fuente: pueden ser establecidas de forma gráfica, en archivos de configuración, sin necesidad de recompilar la aplicación. Es decir, la modificación de estas políticas pueden ser delegada a un usuario administrador.
Por la misma razón que el punto anterior, al agregar estos bloques a una aplicación existente, el impacto sobre el código fuente es mínimo.
El manejo de Excepciones y Eventos de Log, es extensible definiendo "custom handlers", clases personalizadas que son invocadas para estas tareas.

Links

UPDATE 2009-06-12

Fe de erratas!, Como comenta Ariel (ver comentario en esta entrada), la forma correcta de relanzar una excepción es mediante throw; (de forma de mantener el stack trace), asi que en todos los bloques de codigo donde dice:

throw outEx ?? ex;

debería leerse:

if(outEx!=null)
throw outEx;
else
throw;