Tenia ganas de contestar a este thread... Para mi, no se pueden escribir todos los tests de antemano, porque eso implicaria que uno conoce el problema a resolver por completo. Rara vez es asi. Por eso, al principio prefiero escribir tests funcionales que permitan decir si las cosas funcionan o no a grandes rasgos. Por ejemplo, en el sistema que dice Hernan, si uno toma las posiciones de hoy mas el cambio en las variables financieras de hoy para mañana, tiene que ser posible estimar el precio de los trades mañana con muy poco residual.
Exactamente como funciona eso antes de programarlo? Ni idea! No es un problema facil en general, y mucho menos "simple". Por eso, me parece que no queda otra que escribir un test funcional al principio. Ahora, a medida que se programa todo esto, seguramente van a aparecer algoritmos o calculos o condiciones especiales que merecen unit tests. Entonces si, a escribir mas tests se ha dicho. Tambien me paso que al principio ni siquiera pude escribir tests funcionales porque no tenia claro, mas alla de los objetivos generales, que iba a terminar programando. En ese caso, igual me parece que los tests funcionales son muy valiosos a medida que se construye el programa. Un par de comentarios mas. Los tests son parte de la aplicacion, y hay que escribirlos con el mismo cuidado que se escribe cualquier otra cosa. Ademas, algo que los tests no garantizan es que el programa que los pasa sea facil de cambiar. En mi opinion, la flexibilidad es mas importante que los tests. Los programas que no se pueden cambiar son como los animales demasiado especializados. Un pequeño cambio en el medio ambiente, y se extinguen. Andres. 2009/11/13 Hernan Wilkinson <[email protected]>: > 45 minutos no alcanzan para mostrar tdd en serio y tampoco alcanza una > tarde, es un cambio de hábito muy fuerte y se logra de a poco, pero yo no > tengo problema el sabado por la tarde estemos toda la tarde haciendo un > sistema con tdd, algo groso, no un ejemplito pedorro. > > 2009/11/13 Mariano Abel Coca <[email protected]> >> >> Por lo que estuve leyendo, creo que el mayor problema con el que se han >> encontrado es que los tests que han definido no son funcionales sino >> estructurales. >> >> Los tests funcionales no debería ser necesario modificarlos o corregirlos >> salvo que cambie la funcionalidad del sistema. Es decir, debería poder hacer >> un refactoring sin tener que corregir ningún test. En esta situación, los >> tests ayudan al refactoring, y aseguran que el sistema sigue andando una vez >> de que cambiaste lo que querías, y está bueno. Hablo de tests que no testeen >> el protocolo de creación y accessing de un objeto, sino que testeen que se >> pueda hacer x o y en el sistema. >> >> Es por eso que me parece que es positivo que todos los programadores >> conozcan el dominio de lo que están modelando, les da la posibilidad de >> escribir esos tests funcionales automatizados. Lo bueno de estos tests es >> que liberan la carga de los testers de tener que hacer un test de regresión >> de semanas para garantizar que un refactoring no rompe nada. Cuando hago un >> refactoring groso corro 23.000 tests que garantizan que el sistema funciona, >> en menos de una hora. >> >> Hernán, me parece que es una buena idea la de armar un workshop de TDD, >> con un ejemplo sencillo y que se pueda desarrollar, al menos parcialmente, >> en la duración de una charla. No para esta Smalltalks que ya está bastante >> cerrada, pero si tenés tiempo para el año que viene, creo que estaría bueno >> y más de uno se anotaría para verla. Habría que pensar bien el ejemplo para >> que no sea ni demasiado complejo ni demasiado pavo, que aporte lo que se >> busca y que se pueda hacer en el tiempo acotado. >> >> Incluso puede ser la excusa para que encuentres el ejemplo ideal para tu >> clase de poo :) ¿Viste que buenos que somos para buscarte laburo? >> >> Saludos, >> >> Mariano. >> >> >> 2009/11/13 Guillermo Sapaya <[email protected]> >>> >>> Hola a todos, >>> >>> Hernán decía: >>> > no entiendo la pregunta... a ver, si queres tener software robusto >>> > tenemos >>> > que testear, creo que eso no tiene sentido discutirlo. >>> >>> Seguro, hasta acá venimos pensando igual :-) >>> >>> Luego decía: >>> >>> > no entiendo la pregunta... a ver, si queres tener software robusto >>> > tenemos >>> > que testear, creo que eso no tiene sentido discutirlo. >>> > La pregunta es, cuando queremos testear y como. Al principio o al final >>> > del >>> > desarrollo? de manera automática o manual? >>> > Para mi: cuanto antes mejor y de manera automática. >>> >>> Para mí también, pero igualmente no concuerdo en que la mejor forma de >>> testear sea haciendo TDD. Por lo menos no en mi caso y el de la otra gente >>> que conozco. >>> IMHO TDD es muy bueno y productivo para cierto tipo de gente y para otro, >>> muy "deprimente". >>> En mi caso me siento completamente atado de pies y manos y no me deja >>> trabajar explorando el dominio como vos decís pero a mi manera. Siempre me >>> caractericé por hacer sistemas prototipando, generando mis primeros >>> objetitos y haciéndolos funcionar en conjunto para que estén disponibles lo >>> antes posible para el usuario final. Y al contrario de lo que argumentan los >>> pro TDD, querer prototipar o explorar el domino a partir de los tests me >>> saca de foco mal. Creo que tiene mucho que ver con la forma de laburar de >>> cada uno. >>> En mi caso (y el de muchos compañeros smalltalkers) priorizamos el laburo >>> rápido, evolutivo e incremental y el refactorizar SIEMPRE que se crea >>> necesario sin importar lo grande que sea el impacto del refactoring siempre >>> que sea para bien. Hacer eso con [ponga aquí el numero que desee] tests de >>> fondo que después tengo que estar manteniendo para mí es impracticable. >>> Repito, para mí. Seguramente en otros casos (como en el tuyo) les resulta >>> satisfactorio. >>> Al contrario de lo que he oído muchas veces, opino que el test del >>> producto final NO es responsabilidad del desarrollador (seguramente acá es >>> donde empiezan a dudar de mi buen desempeño como desarrollador y como lider >>> de un grupo de desarrolladores :-P). >>> El desarrollador debe asegurar que lo que hizo y entregó al integrador >>> anda según lo pedido pero no debe hacer tests funcionales. Para ello hay >>> otro rol que es el de testers, y un tester no tiene porque saber nada de >>> Smalltalk, ni mucho menos de SUnit y TDD. Pero sí de la manera de trabajar y >>> la sinergia del grupo de trabajo. >>> El grupo de desarrollo debería brindarle a los testers una herramienta >>> que permita poder trabajar en la realización de tests automáticos desde un >>> principio. Me refiero a que el tester/usuario pueda definir todos los casos >>> de uso que se le ocurra mediante el uso de dicha herramienta, y que estos >>> casos de uso puedan "correrse" en cada nuevo release interno de desarrollo o >>> cuando se desee. >>> En fin, es un tema para largo pero bueno, por lo menos expuse mi opinión. >>> >>> Saludos, >>> Guillermo Sapaya >>> >>> ----- Original Message ----- >>> From: Hernan Wilkinson >>> [mailto:[email protected]] >>> To: [email protected] >>> Sent: >>> Fri, 13 Nov 2009 09:37:06 -0200 >>> Subject: [clubSmalltalk] Re: DIscusion >>> polemica >>> >>> >>> > 2009/11/12 GallegO <[email protected]> >>> > >>> > > >>> > > Hola Diego: >>> > > >>> > > Esto derivó en algo muy copado. El tema de los tests, creo que lo >>> > > describiste perfecto, yo también siento lo mismo. El tema es que a >>> > > medida que el desarrollo va madurando empieza a cambiar menos, hasta >>> > > que se lo pone a prueba en distintas situaciones. En ese momento, >>> > > puede ser que haya pasado bastante tiempo desde que se escribió ese >>> > > código, empieza a surgir la necesidad de cambio real, dada por algo >>> > > externo. Vamos a modificar y empezamos a dejar caconas por todos >>> > > lados, sin darnos cuenta. No me quiero imaginar que pasa cuando ese >>> > > mismo código lo toca alguien que no tiene el conocimiento de haberlo >>> > > desarrollado, por más que sea una pieza única y bien pulida. >>> > > ¿Como se hace para tener tantos tests? >>> > > >>> > >>> > no entiendo la pregunta... a ver, si queres tener software robusto >>> > tenemos >>> > que testear, creo que eso no tiene sentido discutirlo. >>> > La pregunta es, cuando queremos testear y como. Al principio o al final >>> > del >>> > desarrollo? de manera automática o manual? >>> > Para mi: cuanto antes mejor y de manera automática. >>> > >>> > >>> > > ¿Cuando desarrollas el producto si es que tenes que escribir tantos >>> > tests? >>> > > >>> > >>> > es un pregunta capciosa... lo escribis mienstras desarrollas... tambien >>> > podríamos decir, si hay que diseñar tanto o jugar tanto en el >>> > workspace, >>> > cuando desarrollas? pero la verdad es que si haces tdd bien, >>> > desarrollar >>> > mientras hacer funcionar los tests, directamente desde el debugger, es >>> > maravilloso >>> > >>> > >>> > > Es decir, las respuestas seguramente sean simples, pero las >>> > > ecuaciones >>> > > en tiempo y dinero no. >>> > > >>> > >>> > Eso es contextual y depende del tiempo... a mediano plazo cualquier >>> > sistema >>> > no testeado te va a traer más problemas que uno testeado. >>> > >>> > >>> > > >>> > > Para mi, y para mi trabajo actual, no es tan simple. >>> > > >>> > > Saludos >>> > > GallegO >>> > > >>> > > >>> > > El día 12 de noviembre de 2009 18:58, [email protected] >>> > > <[email protected]> escribió: >>> > > > >>> > > > Gabriel, >>> > > > Antes que nada aclaro que tanto el tipado como el uso de tests son >>> > > > técnicas que considero útiles en su debido contexto. Incluso creo >>> > > > que >>> > > > los smalltalkers deberían tipar un poquito mas, o un poquito antes. >>> > > > De los tests me preocupan dos aspectos: >>> > > > 1) Un conjunto de tests es un sistema en si mismo y tiende a estar >>> > > > fuertemente acoplado con el sistema que se quiere testear. Este >>> > > > acoplamiento, como casi todo acoplamiento, resulta un lastre en la >>> > > > evolución del sistema. Un sistema repleto de tests requiere mas >>> > > > tiempo >>> > > > para ser modificado. Los amantes de TDD argumentan que dicha >>> > > > evolución >>> > > > es "mas segura" porque está controlada por la validez de los tests, >>> > > > y >>> > > > a mi eso me genera serias dudas. Otro efecto similar que producen >>> > > > los >>> > > > tests es que el desarrollador (o jefe) se contenta con ver todas >>> > > > las >>> > > > luces verdes y puede que se relaje en actividades de factorización, >>> > > > en >>> > > > cambiar cosas, porque generalmente antes de fallar un tests, falla >>> > > > la >>> > > > implementación del mismo. >>> > > > 2) El segundo aspecto tiene que ver con el análisis y diseño. Está >>> > > > bueno ver que los programadores de Ruby, a partir de TDD, entienden >>> > > > que es bueno declarar primero la intención inicial y luego teclear >>> > > > la >>> > > > solución. En Smalltalk esto se puede hacer con tests o con un >>> > > > workspace. Esto implica haber entendido que era mejor escribir el >>> > > > problema y luego la solución, a que ir directamente con un diseño y >>> > > > luego ver si anda. Pero pensar que uno conoce el problema de >>> > > > antemano >>> > > > suele ser ingenuo también, por lo tanto es mas conveniente ir >>> > > > modificando también la intención inicial a partir de lo que se >>> > > > aprende >>> > > > en la interacción con el sistema. Entonces ahi me molestan los >>> > > > tests y >>> > > > prefiero usar workspaces, de esos que uso toco y tiro todo el >>> > > > tiempo. >>> > > > Porque no solo no está claro una solución antes de resolver un >>> > > > problema, sino que suele no estar claro el problema tampoco. >>> > > > Smalltalk >>> > > > nos da muchas herramientas para entender un problema y en ese ida y >>> > > > vuelta los tests estorban mas que ayudar. >>> > > > >>> > > > Saludos, >>> > > > Diego Coronel >>> > > > >>> > > > >>> > > > On 12 nov, 12:52, Gabriel Brunstein <[email protected]> wrote: >>> > > >> Diego, me interesa tu punto de vista, por qué afirmas que es >>> > > >> nociva la >>> > > >> seguridad que te dan los tests? >>> > > >> >>> > > >> 2009/11/12 [email protected] <[email protected]> >>> > > >> >>> > > >> >>> > > >> >>> > > >> >>> > > >> >>> > > >> > Mariano, >>> > > >> > Lo que decis me hizo relacionar el tipo de seguridad que da el >>> > > >> > tipado >>> > > >> > con el tipo de seguridad que dan los tests. En ambos casos, >>> > > >> > IMHO, >>> > > >> > sobredimensionada y nociva a corto plazo. >>> > > >> >>> > > >> > Diego >>> > > >> >>> > > >> > On 12 nov, 11:53, Mariano Abel Coca <[email protected]> >>> > > wrote: >>> > > >> > > Simplemente para aportar un detalle más. >>> > > >> >>> > > >> > > Saludos, >>> > > >> >>> > > >> > > Mariano. >>> > > >> >>> > > >> > > 2009/11/12 Hernán Galante <[email protected]> >>> > > >> >>> > > >> > > > Lindo intercambio :-) >>> > > >> > > > A mi parecer, no tiene tanto que ver la escritura en sí, >>> > > >> > > > porque >>> > > Ruby o >>> > > >> > > > Objective C son una copia casi del "Smalltalk lenguaje". Lo >>> > > >> > > > que >>> > en >>> > > mi >>> > > >> > > > opinión sucede es un mix de cosas. La primera, es el tipado. >>> > > >> > > > La >>> > > >> > compilación >>> > > >> > > > da cierta "seguridad", pues para el que escribe existe >>> > > >> > > > alguien >>> > que >>> > > se >>> > > >> > las >>> > > >> > > > sabe todas que te corrige (compilación para hacer el >>> > > >> > > > runtime). >>> > > Esta >>> > > >> > > > "seguridad" no se brinda en Smalltalk, pero todos sabemos >>> > > >> > > > que los >>> > > >> > > > errores también se compilan sin problemas, el punto aquí es >>> > > >> > > > que >>> > es >>> > > un >>> > > >> > engaño >>> > > >> > > > emocional que hace sentir más seguro a sus programadores. >>> > > >> >>> > > >> > > Esta seguridad en smalltalk la obtenés fácilmente con una >>> > > >> > > buena >>> > > batería >>> > > >> > de >>> > > >> > > tests, e inclusive la seguridad que dan los tests es mayor que >>> > > >> > > la >>> > > que da >>> > > >> > el >>> > > >> > > compilador... Y no hablo sólo de tests funcionales sino de >>> > > >> > > tests >>> > del >>> > > >> > > metamodelo. Claro que esas cosas en los otros lenguajes no >>> > > >> > > existen >>> > > :) >>> > > >> >>> > > >> > > > La segunda que no entienden de Smalltalk es su concepto >>> > holístico. >>> > > Que >>> > > >> > no >>> > > >> > > > hay diferencia entre el sistema en desarrollo y el >>> > > >> > > > productivo, >>> > que >>> > > no >>> > > >> > hay >>> > > >> > > > diferencia entre IDE y sistema en construcción, no hay >>> > diferencia >>> > > entre >>> > > >> > mi >>> > > >> > > > código y el código que ya existe, etc, etc. Cuantas veces >>> > > >> > > > han >>> > > vistos o >>> > > >> > nos >>> > > >> > > > ha pasado cuando recién arrancábamos que nos poníamos en >>> > > >> > > > duda >>> > al >>> > > >> > modificar >>> > > >> > > > un método de una clase de base, o no entender que podemos >>> > > modificar el >>> > > >> > IDE >>> > > >> > > > para que browser haga las cosas que yo quiero, que puedo >>> > > >> > > > agregar >>> > > en >>> > > >> > cuestión >>> > > >> > > > de unos minutos nuevas opciones, etc. >>> > > >> > > > El otro punto, que tiene que ver con esto de un todo dentro >>> > > >> > > > de >>> > > >> > Smalltalk, >>> > > >> > > > es la no existencia de archivos. Esto genera cierta >>> > > >> > > > incomodidad >>> > > para >>> > > >> > > > programadores acostumbrados a que la unidad mínima sea un >>> > archivo, >>> > > pues >>> > > >> > es >>> > > >> > > > un esquema brindado fuertemente por el sistema operativo. El >>> > hecho >>> > > >> > también >>> > > >> > > > es educacional, pues el ambiente cuantas veces se "ensucia" >>> > > >> > > > o >>> > > >> > "contamina" y >>> > > >> > > > empezamos a no saber para que lado ir. Eso en un ambiente >>> > > >> > > > basado >>> > > en >>> > > >> > > > archivos, solo se disfraza la suciedad .. :-). Es más, el >>> > > >> > > > hecho >>> > de >>> > > >> > cambiar >>> > > >> > > > de una BBDD a un Gemstone por ejemplo, esto de luchar contra >>> > > >> > > > la >>> > > >> > "basura", es >>> > > >> > > > el principal problema a atender/atacar al administrarla, en >>> > > >> > > > una >>> > > BBDD la >>> > > >> > > > basura existe por siempre y no nos damos cuenta (hasta que >>> > > conectamos >>> > > >> > un >>> > > >> > > > producto BI y saltan todos los sapos). >>> > > >> > > > De hecho, no tener esta educación en nuestra sociedad entera >>> > > >> > > > nos >>> > > lleva >>> > > >> > a >>> > > >> > > > enfrentarnos que tenemos al planeta completo contaminado y >>> > > >> > > > no >>> > > sabemos >>> > > >> > ni que >>> > > >> > > > hacer. >>> > > >> > > > Smalltalk es demasiado avanzado para que todos lo entiendan, >>> > > >> > > > eso >>> > > es >>> > > >> > algo >>> > > >> > > > que hay que aceptar. Es una falta de educación en el fondo. >>> > > >> >>> > > >> > > > Saludos, >>> > > >> > > > Hernán.- >>> > > >> >>> > > >> > > > On Wed, Nov 11, 2009 at 3:14 PM, Bruno Buzzi Brassesco < >>> > > >> > > > [email protected]> wrote: >>> > > >> >>> > > >> > > >> Es una percepción general de la gente de los lenguajes >>> > > tradicionales. >>> > > >> > > >> En la software factory que trabajaba tambien pensaban asi >>> > > >> > > >> lo que >>> > > >> > conocían >>> > > >> > > >> (aunque se a de nombre) Smalltalk. >>> > > >> >>> > > >> > > >> Pero no pienses que en C# no podes meter la pata, trabaje >>> > > >> > > >> con un >>> > > >> > Framework >>> > > >> > > >> en C# que era algo lamentable, no voy a poner nombres, pero >>> > > >> > > >> la >>> > > gente >>> > > >> > que >>> > > >> > > >> construyo esa cosa, era "gurus" de M$. Y mira que es >>> > > >> > > >> imposible >>> > > que te >>> > > >> > > >> imagines el dolor de los programadores cuando querian >>> > > >> > > >> construir >>> > > un >>> > > >> > sistema >>> > > >> > > >> usando esa cosa. >>> > > >> >>> > > >> > > >> El problema de C# en este caso es que el Framework estaba >>> > > >> > > >> "bien >>> > > >> > pensando" >>> > > >> > > >> desde el punto de vista de la arquitectura, cuando llevas >>> > > >> > > >> esa >>> > > "buena >>> > > >> > idea" >>> > > >> > > >> de arquitectura a la practica y construis, el ambiente de >>> > > desarrollo >>> > > >> > te >>> > > >> > > >> queda algo que no se puede describir con palabras (un >>> > > >> > > >> desastre). >>> > > >> > > >> Y esto es porque C# no es homogeneo en Smalltalk no hay >>> > > diferencia >>> > > >> > entre >>> > > >> > > >> arquitectura y ambiente de desarrollo, hay objetos de... >>> > > >> >>> > > >> > > >> En broma les decia los programadores de C#, eso que tenes >>> > > >> > > >> ahí >>> > es: >>> > > "un >>> > > >> > > >> compilador + un combo box". >>> > > >> > > >> Eso es C#, un compilador (c#) y ComboBox que te hace un >>> > > >> > > >> goto al >>> > > codigo >>> > > >> > > >> fuente. Y la librería de C# es usanda como un gran >>> > > >> > > >> repositorio >>> > de >>> > > >> > > >> procedimientos, asi usan C# todos los programadores, >>> > > >> > > >> incluso los >>> > > Mega >>> > > >> > Mega >>> > > >> > > >> MS Mega Seniors Expert. >>> > > >> >>> > > >> > > >> En la tecnologia tradicional lo que llaman "orientado a >>> > > >> > > >> objetos" >>> > > NO se >>> > > >> > > >> acerca ni por asomo a como se trabaja en Smalltalk, es muy >>> > > diferente >>> > > >> > la >>> > > >> > > >> forma de resolver problemas y construir sistemas. >>> > > >> > > >> La confusion radica en que se usa el mismo termino: " >>> > > >> > > >> orientado >>> > a >>> > > >> > objetos" >>> > > >> >>> > > >> > > >> Saludos, >>> > > >> > > >> Bruno >>> > > >> >>> > > >> > > >> -----Original Message----- >>> > > >> > > >> From: [email protected] [mailto: >>> > > >> > > >> [email protected]] >>> > > >> > > >> On Behalf Of Rusty >>> > > >> > > >> Sent: Wednesday, November 11, 2009 4:47 PM >>> > > >> > > >> To: ClubSmalltalk >>> > > >> > > >> Subject: [clubSmalltalk] Re: DIscusion polemica >>> > > >> >>> > > >> > > >> No sé si es lo que lo mató, o si siquiera está muerto. >>> > > >> > > >> Pero si sé que estoy de acuerdo con el comentario. >>> > > >> >>> > > >> > > >> Smalltalk es el paraíso de los buenos programadores. >>> > > >> > > >> Pero también es el paraíso para el desprolijo y el que ata >>> > > >> > > >> con >>> > > >> > > >> alambre. >>> > > >> > > >> Y eso último es jo-di-do. >>> > > >> >>> > > >> > > >> Salutes. >>> > > >> >>> > > >> > > >> Rusty. >>> > > >> >>> > > >> > > >> On 10 nov, 10:31, GallegO <[email protected]> wrote: >>> > > >> > > >> > Se desato una discusion en el blog de cincom y rescato un >>> > > comentario >>> > > >> > > >> > que quiero compartir: >>> > > >> >>> > > >> > > >> > Completo enhttp://bit.ly/Uu517 >>> > > >> >>> > > >> > > >> > ...but I think the context of the quote is being >>> > misinterpreted >>> > > >> > > >> > somewhat. My impression from the video wasn't that Bob >>> > > >> > > >> > was >>> > > >> > > >> > misrepresenting Cunningham's meaning, but just that he >>> > > >> > > >> > wasn't >>> > > >> > > >> > explaining it very well. >>> > > >> > > >> > 'What killed Smalltalk is that it was just too easy to >>> > > >> > > >> > make a >>> > > mess." >>> > > >> > > >> > I think that's absolutely true, but it isn't necessarily >>> > > >> > > >> > a bad >>> > > >> > thing. >>> > > >> > > >> > The truth is that in Smalltalk it's often easier to do >>> > > anything, >>> > > >> > both >>> > > >> > > >> > good and bad. It's rather like saying that the problem >>> > > >> > > >> > with a >>> > > >> > > >> > motorcycle, compared to a bicycle, is that it's just too >>> > > >> > > >> > easy >>> > > to go >>> > > >> > > >> > too fast and wreck one. With programming languages, as >>> > > >> > > >> > with >>> > > bikes, >>> > > >> > if >>> > > >> > > >> > you give a powerful tool to an undisciplined, >>> > > >> > > >> > inexperienced >>> > > user, >>> > > >> > they >>> > > >> > > >> > can cause a lot of damage. >>> > > >> > > >> > If the only vehicle you give someone is a one-gear >>> > > >> > > >> > bicycle >>> > with >>> > > >> > street >>> > > >> > > >> > tires and training wheels, it'll be really hard for them >>> > > >> > > >> > to >>> > > hurt >>> > > >> > > >> > themselves, but they're never going to go very far or >>> > > >> > > >> > very >>> > > fast, >>> > > >> > > >> > either. >>> > > >> >>> > > >> > > >> > Saludos >>> > > >> > > >> > GallegO >>> > > >> >>> > > >> > > >> No virus found in this incoming message. >>> > > >> > > >> Checked by AVG -www.avg.com >>> > > >> > > >> Version: 8.5.424 / Virus Database: 270.14.53/2486 - Release >>> > Date: >>> > > >> > 11/07/09 >>> > > >> > > >> 07:38:00- Ocultar texto de la cita - >>> > > >> >>> > > >> > > - Mostrar texto de la cita -- Ocultar texto de la cita - >>> > > >> >>> > > >> - Mostrar texto de la cita - >>> > > > > >>> > > > >>> > > >>> > > > >>> > > >>> > >>> > > >>> > >>> >>> >> >> >> > > > > > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org -~----------~----~----~----~------~----~------~--~---
