|
Blog acerca de Team Foundation Server, Team System, metodologías de trabajo ágiles, y acerca del desarrollo y la tecnología en general
-
Pues sí, este fin de semana, mientras que yo estaba en Soria, pasándomelo genial, en la no-boda de mis amigos Estefanía y Dani (un gran abrazo ara ellos desde aquí, aunque no lo leerán), han publicado la Beta del SP1 de Team Foundation Server 2008, hace poco ya publicaba por aquí mismo la lista de mejoras / nuevas funcionalidades del SP1 (aquí), y aunque no he podido probarla aún, por falta de tiempo (es lo que tiene certificarse en KNX y el TAP de Rosario), pues nada, aquí la tenemos ya disponible para todos. Pero OJO, incluso antes de poneros el link, por favor, tened en cuenta una cosa, ES UNA BETA, esto quiere decir, que, por supuesto, podéis hacer lo que queráis, pero tenedlo en cuenta si os planteáis ponerla en un entorno de producción, ya que, aunque, como mucha gente, lo tengáis virtualizado, y penséis "bah, si va mal recupero copia anterior y listo", ojito, también habría que instalarla en las máquinas cliente, y esas casi seguro que no las tenemos virtualizadas, además que podemos descubrir el "fallo" la semana que viene, y entonces ya lo de recuperar el servidor no es tan fácil. Además, en cuantas más maquinas lo instalemos, más probabilidades de fallo tenemos. Lo dicho, que es una Beta y tratadla como tal, yo por supuesto os animo a experimentar con ella y a compartir vuestras experiencias, pero con cabeza, no sea que luego os acordéis de ese infame post de Luis, en el que nos decía no se que del SP1 de TFS, y que rompió los servidores y las máquinas de desarrollo :) Y ahora si van los links: PD: Una idea que os lanzo es descargaros la VPC de pruebas de Microsoft con Visual Studio 2008 Team System RTM (el link va a la completa con TFS) y probarlo ahí
|
-
-
Pues sí, ya estoy de vuelta, pero no he podido escribir nada, porque entre el jet lag, y el pedazo de constipado que me traje de recuerdo, estaba que no me tenía. Y que he visto en el Summit? la verdad, muchas cosas que aún no puedo contar de Rosario, y las que puedo contar ya las ha contado Bruno, el hombre-blog, que escribía las cosas a mi lado casi según pasaban, menudo titán como diría Rodrigo. Lo que si que se, es que se aproximan tiempos de mucholío, de mucho probar Rosario para el TAP, de un par de iniciativas que comenté con el amigo Bruno y que quiero empezar a mover la semana que viene, y por supuesto cosas nuevas de Multidomo ... Así que sólo una cosa, estad atentos a los links de las specs de Rosario, y a las CTPs, que se aproximan muchas y bonitas novedades en el ALM de Microsoft. Y bueno, aquí os dejo unas fotillos (de turista) de mi periplo en Seattle. http://www.flickr.com/photos/lfraile/sets/72157604680204753
|
-
Lo primero, bueno, decir que este summit me lo estoy pasando genial, especialmente ayer, el primer día en las Open Sessions, que es algo que han hecho nuevo este año, y que básicamente consiste en que se propone un tema, y la gente que vamos a la sesión lo destripamos, salga lo que salga, se trata, de hecho, no hay ponente como tal, sólo un moderador (en una estuvo a punto de tocarme, pero me libré), que propone un modo de organizarnos para hablar del tema (pizarras, salir a una silla a hablar, etc.). Además estas sesiones estuve con Marco Amoedo, que aunque es MVP de Outlook capado CRM, nos lo pasamos genial compartiendo experiencias de estos temas Primero estuve en una de "Creating succesful organizations", en la que hablamos acerca de los puntos de "fallo" de las organizaciones, por qué la gente deja trabajos, si esta rotación es buena o mala, en fin todo orientado a la organización de empresas. Estuvo bastante interesante, sobre todo el poder escuchar opiniones y experiencias de gente que debe tener tantos años de experiencia como yo de vida, y que esas mismas personas escuchen y compartan tus opiniones, la verdad es que es fue bastante interesante la discusión. Pero aún mejor fue las dos siguientes, "Project Management", ups, con la iglesia hemos topado como se suele decir, por supuesto, lo que se habló aquí fue Agile, no Agile, RUP, SCRUM (nos faltó Rodrigo Corral), y bueno, os podéis acabar como acaban estas cosas, Agile vs no-agile, que si eso de agile díselo a mi cliente, que si waterfall, etc, etc, la verdad es que a pesar de la discusión, el ambiente no era de tensión para nada, la gente compartía experiencias, puntos de vista, y todos escuchabamos a todos, pero lo que me sorprende, es que siempre se acaba en la eterna guerra de agile vs. formal, algo que bueno, se puede hablar horas y horas, y no se llega a una conclusión, porque, como siempre digo, a equipos distintos metodologías distintas, al final todo esto depende de tipos de equipo, proyectos, clientes, etc. Pero, ¿por qué siempre acabamos así? esto es como discutir el sexo de los ángeles, de hecho hubo un momento en que Jeff Boyce hizo una pregunta cuando yo estaba enfrente exponiendo una opinión, y entre los dos hicimos un conato de redirigir la cuestión a algo que tiene mucha más chicha y mejores conclusiones, y son las buenas prácticas en la gestión de proyecos, algo que se pueda aplicar independientemente de la metodología, prácticas que nos ayuden eficazmente en el día a día de la gestión, la comunicación, equipos, colaboración con el cliente, en definitiva, experiencias que nos ayuden, al final, esto de las metodologías, como bien decía Jeff, parecía una lucha de "religiones", "mi dios es mejor que el tuyo", como si sólo pudiese quedar una metodología para controlar a todos los proyectos y gobernar a todos los proyectos, uy que se me pira la cabeza, pues eso, que son como las cruzadas. Al final se convirtió en eso, y aunque se sacaron muy valiosas experiencias, y yo me dejé la garganta hablando (hoy casi no puedo hablar), pero mi opinión, es que este tipo de discusiones son fútiles, no llevan a nada. Eso sí, cuando afirmaron que RUP era Agile, yo no me pude callar, y hasta ahí puedo leer, que luego me cae la bronca en los comentarios ... Y aquí dejo esto, a ver si voy contando más cosillas, mientras tanto, id viendo los posts de Bruno, que tiene hasta fotos, y no como mis rollazos (bueno ya subiré las mías ...) que van sin fotos jejeje. Ahh, y la pregunta es, a vosotros, ¿Qué os parecen este tipo de discusiones religiosas?¿no sería mejor hablar de buenas prácticas, y que luego cada uno aplique (pero bien aplicada) la metodología que mejor se adapte a su situación concreta?, ojo ojito, que las metodologías son la base eh, no olvidemos que las metodologías son las que reglan todas estas buenas prácticas, y sin metodologías sólo tenemos herramientas sin manual de instrucciones ...
|
-
-
Pues sí, esta semana tuve mi primer contacto con mi "TAP Leader" para comenzar el TAP (Technology Adoption Program) de Rosario (la siguiente versión de Visual Studio Team System), al igual que estuve el año pasado en el de Orcas. La verdad es que es alucinante poder participar activamente en algo como esto, y ver que el feedback que se da, se tiene en cuenta, yo creo que el equipo de Team system es genial en este aspecto, tomando muy en cuenta lo que la gente les decimos, ya sea MVPs, en TAPs, o lo que cualquiera les podéis decir a través de http://connect.microsoft.com En fin, que ya os iré contando por aquí algunas de las novedades de Rosario, por supuesto, estoy bajo NDA (y ya son dos el de MVP y el del TAP), y por tanto no podré contar todo, pero según se vayan haciendo públicas las nuevas "specs" y las vaya probando, intentaré comentarlas por aquí. Por ahora os dejos dos links: Y bueno, también en breve estaré en Seattle para el MVP Summit 2008, a ver que se cuentan por allí ...
|
-
"Es mejor no hablar y parecer idiota que hablar y demostrarlo" esto es algo que alguna que otra vez he oido por ahí, pero, ¿es esto una buena idea?, evidentemente no. Cuando alguien piensa eso, probablemente se deba a dos razones, o bien no tiene nada que decir (y eso no me lo creo), o bien ha tenido alguna mala experiencia en el pasado, del tipo de hacer una pregunta en una reunión, a un compañero, ... y que le hayan respondido, con un "pero, tío, que preguntas haces, si eso es básico", o, "para preguntar eso mejor no preguntas nada", y similares, esto, es síntoma de que algo va mal, y ese algo es la comunicación. Si en un equipo tenemos estos problemas de comunicación, eso es un mal síntoma. El tener comunicaciones abiertas, libres, dónde cualquiera pueda hacer cualquier pregunta (por básica o complicada que parezca), sin temor a que se le mire mal, es uno de los indicadores de "salud" en un equipo, un equipo en el que se van a exponer los problemas cuando surjan, sin ocultarlos, dónde si alguien ve algo que no está claro, lo va a decir lo antes posible, y no como algo negativo, si no con ánimo de solucionar el problema. Esto, como dice Rodrigo acerca de las pruebas unitarias, no es opcional, tener este tipo de comunicaciones es imprescindible. En las situaciones más claras que yo he visto esto, es cuando alguien hace una pregunta muy básica, y siempre existe un "listo", que le responde mal. Pensemos un poco, ¿acaso alguien nace sabiéndolo todo?, a que no, a que esa pregunta que ahora te parece básica, hace a lo mejor un año, la tenías tu, y alguien te la respondió. Y oye, piensa, que la pregunta que a ti te parece complicada, siempre habrá alguien al que le parezca básica, ¿cómo te gustaría que te respondiesen?, entonces, ¿por qué vas a responder tu mal a una pregunta?. Otra situación dónde se da esto, es cuando alguien expone un riesgo, o una limitación en una reunión, y alguien se lo toma por lo personal. Hay que pensar, que por norma general (bueno siempre hay excepciones) la gente no va a dar por saco al trabajo, todo lo contrario, lo normal, es que la gente quiera hacerlo mejor, y cuando se expone un riesgo del tipo "oye, es que esta arquitectura genérica, no se puede adaptar al 100% en este proyecto", no es que esté tirando por tierra nuestra maravillosa arquitectura, o que no le guste nuestro trabajo, es que está exponiendo un posible riesgo en una determinada situación, y lo que hay que hacer, es trabajar, para evitar ese riesgo, por ejemplo, en este caso, haciendo alguna modificación en la arquitectura para adaptarla a este caso concreto. En definitiva, para no enrollarme más, que una cosa es comunicar y otra "dar la chapa" :o), preguntad, exponer los riesgos, hablad en las reuniones, dar vuestras opiniones, pero más importante aún, escuchad a los demás lo que tienen que decir, que seguro, que escuchando de todos, aprendemos algo, bueno vale yo siempre he sido algo cotilla y de ahí que me guste tanto escuchar jeje. Y para acabar, la némesis del dicho del principio, y que es la que propongo que adoptemos "es mejor preguntar y parecer ignorante, que no hacerlo y seguir siendo ignorante".
|
-
-
El equipo de Visual Studio Team system, acaba de publicar 3 nuevas especificaciones más para la futura versión de Visual Studio Team System "Rosario", la verdad es que es muy de agradecer el esfuerzo que hacen con la publicación de estas especificaciones, ya que así todos podemos estar preparados para lo que viene, y conocer nuevas funcionalidades de los futuros productos, no se cuantos equipos más en Microsoft hacen esto, lo que si comentan es que es bastante esfuerzo el publicar todas estas especificaciones en un formato que todo el mundo pueda ver, os recomiendo que las echéis un vistazo: Y sobre todo, lo que nos piden desde Microsoft, a cambio de seguir publicando specs, es lo de siempre, feedback para que puedan seguir mejorando el producto, así que ya sabéis, es el momento de que todas esas cosas que no os gustan de este producto, se las digáis para mejorarlas. Esto lo podéis hacer a través de este foro creado para esto: http://forums.microsoft.com/msdnworkshop/showforum.aspx?forumid=1981&siteid=64 Y si queréis estar al tanto de futuras specs, tenéis este RSS feed
|
-
Pues sí, es importante, y ¿por qué?, simple, el equipo decide y es uno de los factores de éxito principales. Vaya, si que es importante este equipo ¿eh?, bromas a parte, lo que quiero reflejar en este post, es algo que yo siempre intento dejar claro y que se asuma, y es que el equipo debe tener la capacidad de decisión sobre como organizarse, herramientas, procesos, metodologías, ... Por supuesto, para esto el equipo tiene que ser responsable y sobre todo, sentirse "importante", para tomar estas decisiones con responsabilidad. Si no tenemos un equipo capaz de auto-organizarse, de hacer cosas como las que se discutían hace poco por http://geeks.ms acerca de las estimaciones, y de hacerlas, siempre con sentido común claro, usando las herramientas que ellos sienten que les funcionan, mejorando los procesos que no les funcionan, utilizando las prácticas del modo que mejor funcionan en ese equipo. Tenemos que tener en cuenta, que una de las cosas que tenemos las personas, es que cada uno somos diferentes, lo que nos funciona a unos, no les funciona a otros, y esto mismo se traspasa a los equipos, pero lo que nunca funciona es que una persona o un grupo reducido de personas impongan su criterio al resto, cuando este no es compartido. Esto es una gran fuente de problemas en los equipos, ya que cierta parte del equipo no asumirá como suyas esas prácticas, procesos, decisiones, etc... y otra de las cosas que tenemos las personas, es que cuando no asumimos las decisiones como nuestras, no se llevan a cabo con la misma efectividad. En ello se basan metodologías como Scrum, en la que se toma al equipo como una unidad que es capaz de decidir como se van a organizar, de estimar las tareas de un modo eficaz para decidir la capacidad del sprint, asumiendo como suyas esas decisiones, y dándole mayor responsabilidad y mayor poder de decisión. Pero siempre, al equipo, no a una única persona, por muy alto sea el árbol al que se suba, y esto se puede aplicar a metodologías ágiles y no ágiles, tenemos que aprender a respetar a los equipos como tales, incluyendo a todas las personas desde la primera hasta la última de las que están involucrados en el equipo, si necesitamos usar CMMI porque, cosas de la vida, necesitamos que este proyecto esté certificado, bueno esa no es una decisión del equipo, por supuesto, casi siempre será del cliente, pero si podemos dejar al equipo la responsabilidad de decidir como nos vamos a organizar para que todos los entregables, se entreguen en los plazos, y con la calidad exigida por el cliente y en este caso CMMI. Y, si bien hasta ahora he estado hablando a nivel de desarrollo de software, realmente esta reflexión me viene no por algo vivido en un proyecto, si no en otro entorno completamente diferente al del desarrollo de software (como es el de la asociación dónde colaboro), y dónde se puede ver como los equipos, sean de la disciplina que sean, tienen que tener la capacidad de establecer sus criterios organizativos, acordados y asumidos por todos los miembros del equipo, para que estos sean llevados a cabo con efectividad. No cabe duda de que hay decisiones que no corresponden al equipo, difícilmente podrá el equipo decidir como se tiene que tramitar un crédito por ejemplo, pero si podrán tomar las decisiones de su implementación, que herramientas son las adecuadas para su implementación, las estimaciones de plazos (que aunque no quiero reabrir el debate, estoy con Rodrigo plenamente, especialmente en la parte de que todo el equipo opina en las estimaciones), como se van a organizar para conseguir el objetivo. Por supuesto, esto requiere otra cosa de la que podremos hablar más adelante, disciplina y equipos disciplinados y responsables, pero para eso antes tenemos que empezar a darles la responsabilidad.
|
-
Una de las partes importantes del ciclo de vida de software, es la gestión de requisitos de lo que vamos a construir, esto es básico, conseguir los requerimientos, manejar el cambio en los mismos, gestionar que vamos construir, gestionar su comunicación, etc.. Los requisitos se pueden dividir principalmente en: - Requisitos de negocio: dónde se describen los objetivos principales del software a construir.
- Requisitos de usuario: dónde describimos las necesidades de los usuarios
- Requisitos funcionales: aquí vamos a detallar los requisitos internos del sistema.
- Requisitos de calidad de servicio: rendimiento, escalabilidad, seguridad, internacionalización, etc..
La gestión adecuada de todos estos requisitos, influye de manera muy importante en el éxito de un proyecto, dependiendo de la metodología se gestionarán de un modo u otro, pero como siempre necesitamos de herramientas que nos permitan la gestión integral de los requisitos de un modo compartido en el equipo. Hasta ahora en Team System teníamos los Work Items, que en muchos equipos será suficiente, al menos inicialmente, pero en otros proyectos y con otros equipos se necesitan herramientas más completas, como podría ser Borland Caliber, que permitan cosas como jerarquías, que a día de hoy no tenemos en Team System. Pero esto pronto va a cambiar jeje, Microsoft acaba de publicar un Whitepaper acerca de la gestión de requisitos en Team System, y su futura implementación en Rosario, así como hala de otros sistemas de gestión de requisitos, os lo recomiendo leer, aquí vais a encontrar una descripción mucho más detallada de toda esta gestión de los requisitos y su importancia. Aquí va el link. Requirements Management with Visual Studio Team System 2008
|
-
Pues nada, para todos los interesados en conectar TFS con Project Server 2007 ayer publicaron la versión 2.0 en release en codeplex, recordad que esto no es un conector que tenga soporte de Microsoft, para bajarlo: http://www.codeplex.com/pstfsconnector Y la mejor noticia a parte de esto, es que las futuras versiones de Team System, traerán integración nativa con Project Server.
|
-
Ayer, hablando con unos colegas sobre experiencias que han tenido en sus trabajos (todos en equipos de desarrollo), un amigo me contó una cosa que le ocurrió en un trabajo, y que como poco me pareció una curiosa forma de explicarle como iban las jerarquías en esa empresa :o) obviamente no voy a decir nombres.
Empecemos contando la curiosa visión de las jerarquías que le pusieron a mi amigo:
- Su jefe, le sentó, cogió un papel, dibujó un hombrecillo, y le dijo "este eres tú en la empresa"
- A continuación dibujó un árbol y en las ramas dibujó otro hombrecillo, y le dijo "este soy yo"
- Por último, pintó otro hombrecillo en la copa del árbol, y dijo, "y este es mi jefe".
La conclusión que le dijo a mi amigo, es que como podía ver en el dibujo (una representación sin más de la jerarquía), el estaba por encima, y por tanto tenía una "visión más amplia" de todo, así como su jefe por encima de el, con lo que cuando el (el jefe de mi amigo) le "ordenase" algo, no debía cuestionarlo, puesto que el tenía una visión más amplia, así como cuando su jefe le decía algo el no lo cuestionaba.
En fin, una visión curiosa de como funcionan en algunos sitios, lo primero que se puede observar aquí, es que los marrones siempre van a caer de arriba hacia abajo, cosas de la ley de Newton. Lo siguiente que se me ocurre, si a mi me dicen eso, es que la comunicación, no va a fluir precisamente, facilitando la toma de decisiones en el equipo, si no que me van a tratar como "cadena de montaje", o "picapedrero".
Por supuesto, los crasos errores en los que estaban cayendo en este equipo son muchos de los que se pretenden evitar con las metodologías ágiles:
- Los equipos jerárquicos, en el desarrollo de software, está sobradamente que no funcionan, debemos formar un equipo de "iguales", todos con su responsabilidad correspondiente a la hora del éxito o fracaso de l proyecto.
- Falta de comunicación, cuando alguien te dice que no cuestiones sus "órdenes" puesto que el tiene información que tu no tienes, y que con esa frase demuestra que ni siquiera te va a proporcionar, malo. La información tiene que ser algo compartido en el proyecto, el equipo tiene que ser partícipe de las decisiones, tener la información para organizarse, decidir y apoyar el éxito del proyecto. La comunicación es algo fundamental y básico para el éxito.
- El equipo de desarrollo no es un equipo al que se le tira "la carnaza" del trabajo desde arriba y esperamos a que nos suban los resultados, los equipos de desarrollo tienen que ser partícipes en todo momento del proyecto, son los responsables más directos de lo que se va a generar: el software, y tienen que tener la capacidad de organizarse del modo que más convenga a todo el equipo, de tomar sus propias decisiones técnicas, basándonos en toda la información de que disponen, no son cadenas de montaje, son equipos que toman sus decisiones informadas en todo momento, para el éxito del proyecto.
Bueno de esto realmente se podría hablar mucho más, se pueden poner diferentes puntos de vista, opiniones, etc, la mía, personal, de Luis Fraile (que luego no haya equivocaciones), es que esa visión del hombre en el árbol, no es válida para un equipo de desarrollo de software maduro, y probablemente esté avocada, a lo mejor no al fracaso, porque es indudable que así se funciona en muchos sitios, pero si está avocada a que el equipo de desarrollo se frustre poco a poco, se de rotación, se produzca código de peor calidad, y nunca consigamos tener un equipo maduro de desarrollo.
|
-
Si, un post que no es de Team system, ni TFS ni similares :) Una de las cosas que más me gustan de trabajar en algo como Multidomo es la cantidad de cosas que probamos y hacemos y que siempre están a la última, como por ejemplo lo que estoy haciendo ahora. Esta misma semana Apple ha anunciado el lanzamiento del SDK para el iPhone, bueno, para los interesados, yo ya lo he descargado, pero como no dispongo de una máquina con Mac OS, pues no lo he podido probar :), de todos modos, para desarrollar aplicaciones para iPhone / iPod Touch, no es estrictamente necesario hacerlo con el SDK, lo cierto es que se pueden desarrollar apliaciones web para su navegador Safari. Y digo para su navegador, porque, aunque es todo HTML, CSS 2.01, y Javascript, bueno tiene ciertas características, como el "viewport" en los metas, pero no es extremadamente complejo, y basándonos en la documentación del DevCenter de apple (que por cierto, ya podrían hacer algo tipo MSDN), y conocimientos de AJAX, CSS, y también apoyándonos en librerías externas como iUI, que nos ayudan a simular la experiencia de usuario del iPhone, podemos desarrollar aplicaciones web para el iPhone, por supuesto, con ASP.NET. Tampoco quiero meterme en muchas complejidades, entre otras cosas porque yo mismo estoy empezando y por ahora digamos que lo que tengo es una prueba de concepto "venida a más", pero como recomendaciones haría: - Leer la documentación y los ejemplos de aplicaciones web del DevCenter de apple y hacer algún ejemplo sencillo con ASP.NET y los ejemplos de Apple. Os diré que cuanto más podáis "limpiar" el código generado de ASP.NET (evitando controles de servidor que no necesitemos, teniendo cuidado con las plantillas de los controles que si que queramos usar, etc...) mejor, ya que Safari es bastante "toca-narices" en cuanto a esto.
- Yo estoy usando AJAX.NET y llamadas a webservices (por ahora asmx) con JSON. Los que ya conocéis AJAX.NET sabéis que esto es muy sencillo y funciona perfectamente con Safari para iPhone.
- Ahora vamos a complicarlo un poco más, si habéis estado jugueteando con un iPhone / iPod Touch, habréis visto que la experiencia de usuario, a mi modo de ver, es espectacular, hay que reconocer que se lo han currado, bueno, esta experiencia de usuario no es complicada de conseguir basándonos en Javascript y CSS, pero ya hay gente que ha desarrollado librerías que con poco esfuerzo y buenos conocimientos de Javascript y CSS podemos adaptar, yo la que estoy usando es iUI, y la verdad es que los resultados son bastante buenos (aunque mejorables).
- Otra cosa que yo estoy haciendo es desactivar el ViewState en todas las páginas, recordemos que aquí el "peso" es mucho más crítico, ya que los que usen nuestra aplicación, la usarán muchas veces por GPRS y a pesar de las tarifas "planas", el tráfico es un problema, y puesto que casi todo lo haremos por llamadas con Javascript y JSON, podemos evitar totalmente el ViewState.
- NUEVO: Ayer se me olvidó :( otra cosa que necesitáis, es instalaros la Beta de Safari, el navegador de Apple, porque las páginas que desarrolléis para el iPhone sólo os van a funcionar bien en ese navegador.
Y bueno, creo que no me dejo nada para poder empezar, he de reconocer que tampoco es que sea un "crack" en aplicaciones web, así que seguro que muchos de los que ahi por aquí tienen muchas más ideas :). Simplemente aquí os dejo unas capturas de Multidomo en iPhone iPod Touch, ya os iré enseñando más según lo vaya teniendo.   
|
-
Bueno, pues ya hemos subido las presentaciones de las dos charlas de ALM que di con Bruno Capuano y Rodrigo Corral en los TechDays, así que aquí las tenéis. La verdad es que nos lo pasamos muy bien, y fue un placer dar esas charlas con esos dos máquinas. Y como bien comenta Bruno en su post, interesante ronda de preguntas que tuvimos después de la segunda charla, y en las preguntas por los pasillos en las que se ve la cantidad de cosas y cuestiones que se plantea la gente acerca de Team System, lo cual demuestra que hay mucha gente utilizándolo, y mucha más gente deseando instalarlo y probarlo. También fue un placer encontrarse con mucha gente que hacía tiempo que no veía, y que es frecuente encontrarse en estos eventos, la verdad es que a pesar de acabar totalmente destrozado, y además con una pequeña sorpresa, que me esperaba, por parte de la asociación con la que colaboro de voluntario que me comunicaron durante el miércoles mientras que yo estaba de fiesta en el palacio de congresos :P
|
More Posts Next page »
|
|
|