[Serie] TechEd 2007- 5ta Jornada (Clausura)

 Bueno  estimados, esto va llegando a su fin. A aquellos que hayan venido leyendo la serie desde la Jornada Inaugural (o incluso el Preludio) les quiero dar las infinitas gracias de tener tanto interés y paciencia en seguir mi prosa verborrágica no excenta de detalles innecesarios cuando no inoportunos

El día, en lo que al track de Arquitectura se refiere, lo abrieron el consultor de Microsoft Jezz Santos y el finlandés Edward Bakker con una sesión acerca del estado del arte en Software Factories (término acuñado por el arquitecto Jack Greenfield que hace referencia a herramientas extensibles para generar código en lenguajes genéricos como C#, Visual Basic .NET, Java o cualquier otro, mediante Lenguajes Específicos de DominioDomain-Specific Languages o DSLs– y/o herramientas gráficas). Algo ya había comentado al respecto en la 2da Jornada
En la sesión, Santos y Bakker contrastaron la definición original de Greenfield, respecto de lo que una Software Factory es, con la definición más ajustada a Visual Studio que el comité de Patterns and Practices elaboró ultimamente. La razón de este giro se debe a que Greenfield enunció su definición allá por el año 2004, como una visión de lo que Visual Studio o lo que se usase para desarrollar software debía brindar para acelerar el proceso y liberarlo de complejidad. En cambio, Patterns and Practices ha venido trabajando desde la liberación de Visual Studio 2005 (esto es, desde Noviembre de dicho año) en la creación de software factories específicas para aplicaciones web, servicios web, aplicaciones de escritorio y aplicaciones móviles. Por consiguiente la definición de P&P está actualizada a términos concretos que Visual Studio hoy permite poner en práctica (lo de Greenfield era algo más abstracto). Veamoslas

"Una Fábrica de Software es una línea de montaje (de software) que configura herramientas extensibles, procesos y contenidos usando una plantilla de fábrica de software basada en un esquema de fábrica de software para automatizar el desarrollo y mantenimiento de las variantes de un producto arquetípico mediante la adaptación, ensamblado y configuración de componentes basados en frameworks"
(Jack Greenfield, Keith Short, "Software Factories:
Ensamblando Aplicaciones con Patrones, Modelos,
Frameworks y Herramientas
"
, John Wiley & Sons, 2004)

"Una Fábrica de Software es una colección estructurada de elementos de software relacionados. Cuando una fábrica de software es instalada en un entorno de desarrollo, ayuda a los arquitectos y a los desarrolladores -en una forma predecible y eficiente- a crear instancias de tipos específicos de aplicaciones con una alta calidad"
(Equipo de Patterns & Practices de Microsoft)

Como se puede apreciar, la segunda definición sugiere la idea de lo que podemos encontrar en las Software Factories hoy: casos concretos para desarrollar aplicaciones de escritorio, servicios web, aplicaciones móviles y aplicaciones web. Hace poquito contaba que estos ejemplos concretos de fábricas de software sirven para lograr, con pocas horas/hombre involucradas, resultados impensables si ellas no fueran utilizadas. Esto no quiere decir que sea imposible desarrollar esos tipos de aplicaciones con Windows Forms/Windows Presentation Foundation (WPF), ASMX/Web Services Enhancements (WSE)/Windows Communications Foundation (WCF), .NET Compact Framework y ASP.NET/ASP.NET AJAX respectivamente. Sólo que, para lograr resultados de la robustez que las software factories son capaces de brindar, hacerlo a manopla toma más tiempo

Como contrapartida, el aprender a dominar estas software factories (sus wizards, entender los assets que despliegan, etc) lleva su tiempo. El que se toma ese tiempo y las domina, golazo. Pero el que tiene que empezar un proyecto con plazos acotados, no quisiera comprometerme con lo que voy a decir pero quizás sea más útil ir derecho con lo que se sabía del framework .NET. En cambio, hacer la inversión de aprenderlas como parte de una estrategia a largo plazo de desarrollo de aplicaciones empresariales, vale sobradamente la pena

Volvamos a Santos y Bakker, a su presentación. La misma no estaba enfocada en las, hasta ahora, cuatro fábricas de software de Patterns & Practices sino que iba hacia algo más ambicioso: qué se necesita y qué hay que tener en cuenta para construir tu propia software factory! Hace pocos días yo establecía la distinción entre software factories horizontales: aquellas que sirven para robustecer el desarrollo de aplicaciones varios dominios específicos (por ejemplo, banca, manufacturas, entretenimientos, etc). Pero yo los otros días ponía un ejemplo de un lenguaje específico del dominio de la Odontología. En dicho lenguaje las comandos primitivos tenían que ver con PACIENTE, DIENTE, COBERTURA (médica), etc. De modo que los programadores en ese lenguaje ni piensen en ADO.NET, en WPF, etc, sino que se concentren en el dominio de la aplicación odontológica que hay que crear. Tener una fábrica de software que nos habilite esto implicaría tener una fábrica de software vertical, ya que no serviría para otros dominios (como banca, seguros, comercio, defensa, etc) que el de la odontología

Santos y Bakker intentaron responder a la pregunta tiene sentido desarrollar ese tipo de fábricas? Y la respuesta, aunque sensata, decepcionó a más de uno (que luego lo reflejó en las encuestas): hacelo si pensás luego construir cinco o más aplicaciones basadas en esa software factory. Es decir, create una fábrica de software si pensás con ella desarrollar software a escala. La verdad? No me suena para nada descabellado ese concepto. Es más, me parece súper honesto de parte de los autores. Normalmente se hubiera esperado un "dale para adelante no más que te va a ir fenómeno. Vos haceme caso y usá esto que vas a ser Gardel". En cambio, no. Primó la sensatez y en el espíritu de Santos y Bakker el mensaje fue "con esto no vas a ganar seguramente en el corto plazo"

Que es la misma historia que pasa con los frameworks y la reusabilidad, no? Si tenés que hacer en estos meses una aplicación, y querés construir un framework para reusar componentes y alivianar así el desarrollo grueso, dale que va. Pero ponele una expectativa correcta a ese framework, para saber asimismo cuánta energía deberías invertir en él: es para reusar componentes en esa misma aplicación? O, en cambio, es para reusar componentes incluso en una futura aplicación? En este último caso, tu framework ya pasaría a ser parte de una estrategia a escala. Por supuesto que, sea nada más que para la aplicación inicial para la que es construido o para el futuro, ambas alternativas son válidas. Pero no hay que dejar de tener en cuenta que si es para una sola aplicación, el retorno de la inversión de dicho framework va a ser menor y por lo tanto la inversión en sí no debería ser excesiva (quiero decir, que hacer el framework no te vaya a terminar costando lo mismo o incluso más que haber hecho el proyecto sin él)

Bakker y Santos están hablando de esto mismo, de una manera muy honesta y abierta. Del mismo modo, agregan, es menester contar con un entendimiento acabadísimo del dominio para el cual se está por hacer la fábrica de software, y fundamentalmente contar con la gente adecuada, esto es, que tenga el perfil necesario para desarrollarla. Por último, hace falta tiempo!

Al respecto de esto último ellos sugieren que desarrollar la software factory demanda entre dos y tres veces el tiempo que demandaría generar una instancia del producto que la software factory construye. Es decir, por ejemplo, si tomásemos esto al pie de la letra, quiere decir que desarrollar la Mobile Software Factory demandó entre dos y tres veces lo que hubiera llevado construir una ventana de aplicación móvil como la que esta fábrica de software produce. El retorno de la inversión (return of investment o ROI) llega al construir la tercera o quinta ventana de aplicación móvil con esta facilidad (ellos dicen que lo mismo valdría para cualquier software factory que te construyas. Es decir, si te construís una software factory que produce elementos XYZ, al generar el tercer, cuarto o quinto elemento XYZ con la software factory estarías recuperando la guita que te costó hacer tanto esa software factory como los tres a cinco XYZ que ya lograste generar). Ojo al piojo, pues

Una conclusión personal, no es que la hayan dicho Santos y Bakker sino que yo la digo, es que crear fábricas de software puede ser adecuadísimo para empresas cuyo core business (negocio principal) es desarrollar software. Es decir, empresas que comercializan software, empresas cuyos ingresos se basan en la venta de software. Como construir ese software tiene un costo, y las software factories en el largo plazo alivianan ese costo, suena razonable crear fábricas de software para mejorar las utilidades. En cambio, siempre en mi opinión personal (esto no fue ni insinuado por los autores), si la empresa se dedica a un rubro diferente (es una compañía de seguros, etc)… construir su propia fábrica de software puede ser algo realmente costoso. Por supuesto que, yendo al caso concreto, habría que cuantificar esto que digo y ver si vale la pena o no

Bueno, nuevamente volviendo a la sesión de estos dos amigos, destacaron las herramientas que existen hoy para generar fábricas de software. Acá entramos en una maraña de acrónimos (GAX, GAT, DSL, SDM, etc) que se han ido sedimentanto con el tiempo cuan capas geológicas unas sobre otras, y que aunque te parezca que sos el único que no sabe el por qué o para qué de cada una yo te aseguro que son varios los carlitos que las andan repitiendo todo el tiempo sin saber para qué catzo sirven. Yo traté de hacer un poco de geología acá, y llegué a la conclusión de que

  • Un Guidance Package (o Paquete de Guías) es un conjunto de plantillas (de lo que quieras: de un XML, de una ventana Windows, de un componente, …, es cualquier cosa no terminada pero que sirve de molde para que la termines como te quede mejor), asistentes (wizards, ventanas que te permiten, a través de pestañas secuenciales llenar un formulario con info que te va a crear cosas a medida -cosas tales como archivos XML, ventanas, componentes, etc) y recetas (es decir, un chm u hipertexto equivalente con info piola como how-to’s, consideraciones de plataforma y otras recomendaciones). Las fábricas de software se implementan, por lo tanto, con estos paquetes de guías. Entendiendo esto creo que no te va a costar nada ahora entender lo que sigue
  • Guidance Automation Extensions (Extensiones de Automatización de Guías o GAX) es un entorno de ejecución (runtime environment) de Guidance Packages para Visual Studio 2005. En otras palabras, lo vas a necesitar desde el vamos sea que quieras ejecutar una fábrica de software de algún tercero, como las de Patterns & Practices o que quieras ejecutar la tuya propia
  • Guidance Automation Toolkit (Set de Herramientas de Automatización de Guías, o GAT) es una paquete de guías para construir, a su vez, paquetes de guías que implementen Fábricas de Software. No es un requisito instalar GAT para ejecutar una software factory, aunque sí GAX
  • Domain-Specific Language (Lenguaje Específico de Dominio o DSL) es un concepto general que hace referencia a un lenguaje diferente a los lenguajes de propósito general como C# o Visual Basic. El dominio, como decía en el caso de las fábricas de software verticales, puede ser un tipo de industria dado, el reglamento de un juego de aventuras o de autos, fútbol, etc, un editor musical, lo que se nos ocurra. Hasta acá, no hay nada que sea inherente a Microsoft: el concepto de DSL anduvo dando vueltas allá afuera rato ha
  • Domain-Specific Language Tools (Herramientas para Lenguajes Específicos de Dominio) es un conjunto de utilidades disponibles dentro del SDK de Visual Studio que permiten implementar DSLs en una forma muy potente:
    • Mediante un diseñador gráfico es posible definir modelos de dominio
    • Mediante un archivo de configuración XML se puede definir un diseñador gráfico que va a permitir modelar visualmente elementos que la fábrica de software deba construir, del mismo modo que el editor de clases actual de Visual Studio permite crear el esqueleto de clases, o el editor de workflows de Windows Workflow Foundation (WF) permite crear flujos
    • Mediante plantillas de texto se puede instruir a Visual Studio para que convierta la definición gráfica (basada en el modelo de dominio) a código en un lenguaje de propósito general, que finalmente se compilará para producir código ejecutable
    • Con todo esto listo, los desarrolladores ya pueden trabajar visualmente en modelos gráficos que del resto se encarga la herramienta
  • Para una discusión efectiva de dónde encaja mejor GAT y donde DSL Toolkit, sugiero leer lo que Mauro Regio junto con Víctor García Aprea (de Clarius Consulting, un partner que tiene mucho que ver con la infraestructura de soporte a las fábricas de software) tienen para decir al respecto

Santos y Bakker mostraron demos de estas herramientas en acción pero admitieron que están aún a medio camino, no del todo integradas entre sí. Aún así bosquejaron cómo el proceso de creación de una Fábrica de Software debiera ser, generalizando una solución particular en una primera implementación de referencia, la cual debería servir de molde para una plantilla de solución desde la cual crear la primera versión de la fábrica, usando luego esta última para generar productos que sirvan para refinar el modelo que permita bosquejar una nueva plantilla de solución, y así seguir iterando

Los muchachos finalmente comentaron el roadmap para el futuro inmediato de las fábricas de software, y todos los esfuerzos no sólo de Microsoft sino de otros jugadores de la industria -como los argentinos de Clarius con su Software Factory Toolkit-, el VSIPFactory (una fábrica de software para crear extensiones a Visual Studio; VSIP viene de Visual Studio Industry Partners, o sea socios de la industria que crean extensiones específicas de Visual Studio), o el DSL Editor. Esto dio cierto panorama de que la forma de desarrollar fábricas de software, o al menos las herramientas que se utilizan a tal fin, se encontrarían en vías de cambio

Definitivamente, lo desalentador al respecto de las SF es ver que están de momento completamente fuera del roadmap de Visual Studio. Al menos Visual Studio 2008 (hasta hace poco conocido por "Orcas") no hace mención de incorporar nada de esto by default (hago tan temeraria afirmación en el hecho de que el white paper sobre VS 2008, aparecido a mediados de Abril, habla de LINQ, de ADO.NET vNext, etc… pero ni una sola mención de DSLs, de GAT, ni mucho menos de SF). Lo poco que se menciona oficialmente de la versión siguiente a Visual Studio 2008 (de momento conocida como "Rosario") tampoco hace mención a soporte para crear o ejecutar fábricas de software. Debo concluir que el soporte para construir fábricas de software seguirá estándo disponible por separado en la forma de extensiones? Siendo que todo esto viene dando vueltas desde el 2004, que tres años más tarde el asunto todavía siga en veremos no me da la sensación de que haya una firme decisión de ir para aquel lado. Por caso, no le tomó tanto al Updater Application Block convertirse en ClickOnce

Hay, más bien, un apoyo, pero no un encolumnamiento detrás de las fábricas de software como un paradigma estratégico. Sería un error concluir, entonces, que Microsoft le bajó el pulgar: la Enterprise Library de Patterns and Practices también ha estado dando vueltas por un tiempo largo ya y tampoco pasó a ser parte constituyente de .NET. Sin embargo, va a haber EntLib para rato y lo mismo creo que las software factories van a seguir ocupando cierto espacio en el "cosmos" de .NET

Los amigos Santos y Bakker se despidieron, luego de dar su mensaje honesto y franco de qué es lo que está pasando y qué no está pasando con las fábricas de software, dejando cierta sensación de "esto debe estar buenísimo como idea… pero viene muy verde". La misma sensación que teníamos hacia fines del 2004, cuando Andrés Aguiar nos vino a visitar a Santiago de Chile y nos brindó una sesión sobre Fábricas de Software en un Architect Forum

Personalmente creo que la pelota quedó picando claramente en la cancha de las empresas que fabrican software. Presiento que ellos, los que fabrican soft como actividad primordial, le van a sacar más jugo que nadie a estos Guidance Packages

 

A la salida de esta sesión comenzaba mi último tiempo en el stand del Equipo de Arquitectura. Lo más relevante que tengo para destacar fue un muchacho que me preguntó por las tecnologías para interfaz de usuario que se están viniendo, pero principalmente cierta inquietud entre ASP.NET AJAX y Silverlight, ya que ambas caen dentro del rango de las tecnologías web. Aunque parezca que la cosa pasa por optar por una u otra, en realidad son tecnologías complementarias y, llegado el caso, ambas podrían estar presentes

La fortaleza de AJAX pasa más por su habilidad de poder pegarse un pique hasta el servidor (gracias al objeto XMLHttpRequest) y traer cierto XML que luego, vía JavaScript pueda servir para actualizar partes de la página sin necesidad de cargar la página nuevamente (porque esto último no sólo consumía más ancho de banda: además introducía el compromiso de salvar cierto estado de la sesión, sea del lado del servidor -lo que podría atentar contra la escalabilidad-, sea del lado del cliente -mediante cookies que podrían no estar habilitadas- o añadiendo el estado como parte del requerimiento HTTP, que no sólo decanta en un consumo mayor de ancho de banda sino que además es un modelo de programación más complejo -aunque ASP.NET libera al desarrollador de esa plomería-). Este beneficio que AJAX trae redunda en la experiencia de usuario porque el navegador parece actuar de una manera más ágil a los requerimientos del usuario. No obstante, en términos reales, los controles que ASP.NET AJAX ofrece al desarrollador son controles que, en última instancia, se renderizan mediante el soporte básico HTML que los browsers poséen. Por lo tanto, cuando un navegador entre a un sitio desarrollado con ASP.NET AJAX, no va a requerir instalar nada adicional para poder aprovechar sus ventajas (en la medida en que su JavaScript tenga disponible XMLHttpRequest) ya que las bibliotecas de lado cliente de ASP.NET AJAX se descargarán automáticamente al estar vinculadas mediante el comando HTML <SCRIPT>

Por el lado de Silverlight, la fortaleza viene dada en sus capacidades gráficas, que exceden las que los navegadores traen por defecto (basadas en HTML). Pero, justamente, para poder ir más allá que el default cada navegador deberá instalar un plug-in que le permita expandir esas capacidades (similar al plug-in para ejecutar applets de Java o animaciones Flash). El runtime de Silverlight que se carga en el navegador tiene una mini CLR (common language runtime, el motor de ejecución de .NET) embebida, capaz de cargar ensamblados y ejecutarlos. Este dato no es menor, porque si necesitamos llamar a un servicio web podemos usar el mecanismo de proxeo que .NET habilita per se, sin necesidad de usar el XMLHttpRequest de AJAX. La tecnología de visualización que Silverlight utiliza está basada en XAML (eXtensible Application Markup Language), el mismo de Windows Presentation Foundation (WPF) que se basa en vectores y permite, especialmente, dividir labores entre diseñadores de interfaz de usuario y desarrolladores de software (que son los que van a ponerle conducta a la interfaz que los diseñadores -valga la redundancia- diseñen). También, Silverlight permite embeber multimedia en las páginas

Claramente que Silverlight puede vivir sin AJAX y no al revés. Pero como contrapartida, AJAX no necesita de ningún plug-in para correr por lo que, si no es un requisito diseñar una interfaz de usuario con características extra a las que provéen por defecto los navegadores, ASP.NET AJAX es una respuesta más que óptima. Escenarios típicos de esto son aplicaciones cuyos usuarios son externos a la organización (clientes, socios, proveedores, etc) que tal vez rechazarán instalar Silverlight sólo por correr nuestra aplicación (nada más pensá lo invadido que te sentís cuando un sitio web te dice que le habilites las cookies o le levantes la restricción de ventanas pop-up). Silverlight, en cambio, se me asemeja como más realista en escenarios de intranets y extranets cuando los usuarios son empleados de una organización y usan una infraestructura que la organización les da y administra por ellos. Hay que ver qué va a pasar si algún día Silverlight está tan desplegado como hoy lo está Adobe Flash (que a la fecha en que entré en este link, http://www.adobe.com/products/player_census/flashplayer/, indicaba que estaba en el 98.7 de los desktops)

Te voy anticipando dos problemas que ya se van empezando a sentir, tanto con AJAX como con Silverlight:

  • Bookmarks: al usuario de la aplicación le da lo mismo si lo que está viendo en la ventana del browser es ASP.NET con AJAX o sin, Java Server Faces, Struts, Silverlight o lo que sea. Lo cierto es que, mientras va ejecutando la aplicación puede pasar que llega a un estado que quisiera conservar para futuras referencias. Por ejemplo: ve la leyenda "Aéreo confirmado con el código #236734GHAY29" y más allá de imprimir esa página, quiere bookmarkearla para poder volver inmediatamente a ella. Si estábamos trabajando con ASP.NET convencional, existía una manera de poder hacer que la página sea bookmarkeable mediante la adecuada generación de una URL que contenga los parámetros que siempre nos permitan volver a generar a generarla (en este caso con el código de reserva alcanzaría)
    Pero si veníamos haciendolo con AJAX o Silverlight donde la URL es la de la última página que se cargó completamente hasta que empezamos a darle al XMLHttpRequest o a Silverlight respectivamente, la cosa se va a poner más difusa para el usuario porque el bookmark lo va a hacer volver al inicio
  • El botón de Volver (back button). Suponete que, sea con AJAX o con Silverlight, el usuario selecciona un barrio de una lista y la aplicación le despliega las pelis que están dando en cines de ese barrio. Suponete entonces que no hay ninguna que le interese y que quiera probar con un barrio vecino. Tiene la chance de pulsar un link en la página que dice "cargar otro barrio" pero en cambio prefiere, porque suele no fallarle y está acostumbrado, apretar el botón de volver para pasar al estado anterior donde tenía que elegir barrio y ninguna peli aún poblaba la lista. Bueno, como diría Pepe Biondi, patapúfete: va a volver a la página previa a la última página que cargo completa

No tengo ni idea sobre workarounds para estos problemas pero doy fe que proximamente los habrá en blogs, portales, etc

 

En el durante, y ya cerrando el evento, Jeff Loucks brindó una sesión de Infraestructura acerca de cómo hacerle tuning al servidor Small Business Server 2003 para optimizarlo para aplicaciones típicas en entornos de 25, 50 y 75 usuarios. Loucks mostró cómo simular carga al Exchange mediante LoadSim, una herramienta parametrizable que simula que los usuarios están a full con el servidor de correo; lo mismo con Microsoft Dynamics CRM 3.0. También mostró cómo DiskPar, una utilidad que realinea los sectores de un disco puede ayudar a mejorar el rendimiento general. Mostró el clásico PerfMon que permite loguear el registro de actividades (tipicamente la actividad de los discos, el uso de la memoria y la CPU, la base de datos, etc). Del mismo modo mostró como simular -siempre con el fin de calibrar el sistema- transferencias de archivos masivas en el sistema

Loucks mostró resultados de los benchmarks logrados luego de muestrear distintas configuraciones y explicó las conclusiones de los mismos

 

Estimadísimos, esto ha sido todo. Esta semana me sirvió una barbaridad. El contacto con los clientes sin duda alguna que es fundamental -sirve no sólo para reconocer aquellas áreas de la arquitectura de software que uno debe reforzar porque se está quedando lisa y llanamente ignorante al respecto: también sirve para cuestionarse lo que uno crée que sabe y ser capaz de juntar todo para poder elaborar nuevas conclusiones-

Al track, en sentido estricto, le fue bien. Respecto del año pasado se ha crecido no sólo en satisfacción sino también en asistencia a las sesiones. No obstante, hemos quedado lejos de otros tracks que han exhibido mejores resultados. Ahora me toca elaborar el post-mortem para determinar los puntos a mejorar en futuras ediciones (si es que me dejan seguir haciendo esto smile_tongue)

 

Abrazo y gracias por leerme!!

Esta entrada fue publicada en Software Architecture. Guarda el enlace permanente.

3 respuestas a [Serie] TechEd 2007- 5ta Jornada (Clausura)

  1. Eugenio dijo:

    Que buen post Diego. Te encontre por casualidad y desde que por primera vez lei un articulo tuyo, he empezado a leerte seguidito. Ojala no dejes de escribir ya que tenes una habilidad especial para bajar los conceptos a tierra.
     
    Un arbazo desde Argentina.
     
    Eugenio Serranowww.eugenioserrano.com.ar

  2. Diego dijo:

    Gracias, Euge
    Por cierto, entré a tu blog y me pareció un kilo!! Te voy a estar visitando seguido, sin duda

  3. Alberto dijo:

    Comunidad de Desarrolladores CSLA (CslaNet.org)CSLA son las siglas de Component-based Scalable Logical Architecture, en resumen consiste en un framework creado por el MVP Rockford Lhotka, que tiene como objetivo definir la capa de negocios basándose en objetos robustos para una arquitectura distribuida.Hemos creado una comunidad para desarrolladores CSLA, esta nace como una necesidad de disponer de apoyo técnico en nuestro idioma donde podras encontrar recursos técnicos como un blog de experiencias, noticias, foros de ayuda, herramientas y proyectos autorizados por el autor del framework donde puedes participar de manera abierta y en el beneficio de la comunidad. Saludos.BeyondNethttp://www.CslaNet.orghttp://www.Codesol.info

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s