Jaja Abramos un grupo en el Facebook para eso jaja.
Es una broma, pero sí, ya aburre :) Saludos El día 10 de noviembre de 2010 17:30, andres <[hidden email]> escribió: > A quien corresponda: ¿hasta cuando hay que aguantar que el troll siga > abriendo posts con temas que no tienen nada que ver con el mensaje original > y que sólo conducen a threads de cuasi-infinita longitud? > > Saludos y gracias, > Andrés > > Guillermo Schwarz escribió: >> >> El 10-11-2010, a las 12:39, Giuseppe Luigi Punzi <[hidden email]> >> escribió: >>> >>> A pesado me refiero, que ayer intenté cargarlo en una imágen, y se tiró >>> perfectamente unos 15-20 minutos de reloj instalar. Seaside es un >>> proyecto >>> grande, e incrustarlo exclusivamente para informes... >> >> ?Y no seria mejor tener alguna manera de cargar los bytecodes ya >> compilados en vez de subir los fuentes? >> >> Digo, si en Java se puede, que es el lenguaje de tipeo estático denostado >> thread por medio en esta lista, ?porque no hacerlo en smalltalk? >> >> ?A alguien se le ocurre como? >> >> Saludos, >> Gulermo. >> > > -- > To post to this group, send email to [hidden email] > To unsubscribe from this group, send email to > [hidden email] > > http://www.clubSmalltalk.org -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
> Jaja Abramos un grupo en el Facebook para eso jaja.
+1 :D -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
In reply to this post by Andres Fortier-2
El día 10 de noviembre de 2010 17:30, andres
<[hidden email]> escribió: > A quien corresponda: ¿hasta cuando hay que aguantar que el troll siga > abriendo posts con temas que no tienen nada que ver con el mensaje original > y que sólo conducen a threads de cuasi-infinita longitud? Hace cinco años aproximadamente, se presentaba la misma situación: http://groups.google.com/group/clubsmalltalk/msg/1ff3092eee67cc33 Saludos! -- Nostradamus -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
In reply to this post by Fernando Arroba
El día 10 de noviembre de 2010 13:08, Fernando Arroba
<[hidden email]> escribió: > Hola G.L. > > Creo que alguna vez hemos hablado de estos temas de generar informes y > similares. A parte de las soluciones propuestas de utilizar > herramientas no smalltalk, o el utilizar "lenguajes intermedios" como > html... existen también otros lenguajes como laTeX o Lout que pueden > servir como alternativa. [...] Si de lenguajes externos sencillos se trata, puedo recomendarles rst2pdf http://code.google.com/p/rst2pdf/ , viene del campo de Python, que no será Smalltalk, pero bue ;-) Algo es algo, dijo Ducasse y casi agarra Ruby, jejeje Nos leemos... -- It's not enough to teach students to surf the Net, we must teach them to make waves. My pedagogical theory is relate, create, donate, which suggests that students work in teams, create ambitious projects and then donate these to people who can use and build upon them. --Ben Shneiderman -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
In reply to this post by Giuseppe
Hola,
Esto lo escuché muchas veces... On Nov 9, 12:06 pm, Giuseppe Luigi Punzi <[hidden email]> wrote: > Ahora que tengo un poco más de tiempo puedo explayarme :P > > Hace tiempo, me digeron una vez...para qué reinventar la rueda, si ya existe > algo que está muy bien hecho? De los miles de modelos de autos que se inventaron (y de cualquier cosa que tenga ruedas), casi ninguno usa ruedas iguales. Las ruedas son redondas y sabemos cómo funcionan, pero en muchas oportunidades (casi todas) es bueno volver a construirlas. Con Smalltalk sobra poder para hacer practicamente cualquier cosa, a veces meter un componente puede ser una solución de corto plazo, pero a largo plazo conviene programar mas y pegotear menos. -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Muy buena la analogía, y si es verdad, las cajas negras, son soluciones a corto plazo, en cuanto querés darle una vuelta más de rosca estás al horno. Y generalmente esas vueltas de roscas aparecen justamente con oportunidades de negocios nuevas no pensadas inicialmente.
Saludos, Hernán.-
-- 2010/11/10 [hidden email] <[hidden email]> Hola, To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
ja! eso les gusta pelear al cuete a los smalltalkers, ... a los que coartan a los demás para que no escriban esto, hagan aquello, bla, también aburren, y les digo salud!!! Si alguien hace algo errado y molesta no len, y si molesta mucho para eso esta el moderador, le escriben y listo... Nos vemos mañana en Smalltalk 2010!!! los que no puedan venir, sepan que va a haber cámaras "oficiales" y estaremos los que filmaremos con nuestras propias y los subiremos por ahí....
El 10 de noviembre de 2010 22:47, Hernán Galante <[hidden email]> escribió: Muy buena la analogía, y si es verdad, las cajas negras, son soluciones a corto plazo, en cuanto querés darle una vuelta más de rosca estás al horno. Y generalmente esas vueltas de roscas aparecen justamente con oportunidades de negocios nuevas no pensadas inicialmente. -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
In reply to this post by Sebastian Calvo
Jaja Abramos un grupo en el Facebook para eso jaja. "Soy fanático de trivial" - así debería llamarse el grupo...
To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
In reply to this post by dcoronel32@gmail.com
Si, está claro,
Pero veo un error en algunos casos, implementar algo nuevo, cuando con algo existente, sobra. Pensemos, que no todos los proyectos son grandes y en los que sale rentable tener que programarnos todo. Si tengo un proyecto en el que los informes los uso para dos o tres cosas nada más, resulta más rentable y eficiente usar una solución existente, sobre todo, si ésta está bien hecha y es potente, antes que tener que desarrollar la mía propia (y además desarrollar mi propio driver para la impresora que también sería más eficiente que usar el existente), o si lo extrapolamos, desarrollar también mi propio sistema operativo ya puestos. Cuando yo me compro un coche, le compro ruedas, no me las fabrico yo, porque no sería rentable ni tengo los medios/conocimientos. Es muy bonito y educativo que en smalltalk se pueda hacer de todo (y me encanta saber que tengo todo el sistema a mi merced para hacer cambios), pero realmente, al menos para aplicaciones de gestión (estándar), dudo mucho que tenga que llegar al punto de tener que modificar la VM, u objetos internos del sistema, o tener que implementar un motor de reportes de cero, para un propósito tan general, como hacer 25 pedidos, 30 albaranes, y 20 facturas. Quiero decir, que quizás, para mis propósitos, o por aprender, me embarcaría en alguna manera de creación de reportes que fueran serializados a disco para poder modificar desde otra herramienta, que supiera interpretar esos reportes, y el cliente final pudiera modificarlos fácilmente a placer, pero no sé hasta qué punto, sería rentable existiendo soluciones para ello (pongamos iReport o CrystalReports como ejemplo), que ya llevan años de desarrollo especializado exclusivamente en este tema. Un saludo, conversación interesante. On Thursday 11 November 2010 02:40:14 [hidden email] wrote: > Hola, > Esto lo escuché muchas veces... > > On Nov 9, 12:06 pm, Giuseppe Luigi Punzi <[hidden email]> > > wrote: > > Ahora que tengo un poco más de tiempo puedo explayarme :P > > > > Hace tiempo, me digeron una vez...para qué reinventar la rueda, si ya > > existe algo que está muy bien hecho? > > De los miles de modelos de autos que se inventaron (y de cualquier > cosa que tenga ruedas), casi ninguno usa ruedas iguales. Las ruedas > son redondas y sabemos cómo funcionan, pero en muchas oportunidades > (casi todas) es bueno volver a construirlas. Con Smalltalk sobra poder > para hacer practicamente cualquier cosa, a veces meter un componente > puede ser una solución de corto plazo, pero a largo plazo conviene > programar mas y pegotear menos. -- -- Giuseppe Luigi http://www.lordzealon.com -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
A corto plazo suele servir pegar componentes e incluso no programar
nada y hacer una planilla Excel, pero Smalltalk es rentable a largo plazo. (contesto mas abajo) >On Nov 11, 4:30 am, Giuseppe Luigi Punzi <[hidden email]> wrote: > Si, está claro, > > Pero veo un error en algunos casos, implementar algo nuevo, cuando con algo > existente, sobra. Pensemos, que no todos los proyectos son grandes y en los > que sale rentable tener que programarnos todo. Si tengo un proyecto en el que > los informes los uso para dos o tres cosas nada más, resulta más rentable y > eficiente usar una solución existente, sobre todo, si ésta está bien hecha y es > potente, antes que tener que desarrollar la mía propia (y además desarrollar > mi propio driver para la impresora que también sería más eficiente que usar el > existente), o si lo extrapolamos, desarrollar también mi propio sistema > operativo ya puestos. luego encargarte de escribir manualmente el contenido y dejarle el formato e interacción con el entorno a tools menos rígidos como procesadores de texto o formatos estándar, luego podés hacerte cargo de esa parte también y dejar solo el sistema operativo (y no tenés que escribir drivers de impresión porque son temas del OS). Y si finalmente se te ocurre hacerte un sistema operativo no te reprimas, lo propuso Dan Ingallas hace unos 30 años y conozco a varios smalltalkers de esta lista que lo han encarado, con mayor o menor éxito. > Cuando yo me compro un coche, le compro ruedas, no me las fabrico yo, porque > no sería rentable ni tengo los medios/conocimientos. Algo que tienen los smalltalkers es una soberbia sana, una sensación de que se puede hacer todo y una falta de respeto por todo. No hablo de fanatismo ni de criticar desde la tribuna (que también existe), sino de proyectos reales hechos en Smalltalk en donde se resuelven cosas que cualqueir programador no se atrevería ni a meterse. Y esto no es porque los smalltalkers sean gente inteligente ni mejor preparada, yo creo que es porque la exposición a un ambiente que puede lidiar con ciertos grados de complejidad lo acostumbra a no ver complejas a cosas que encaradas desde otras tecnologías lo son. Cuantos sistemas administrativos de facturación hechos en VB/PB/JS/ Java/PHP/C/C++/C#/.NET/etc viste que se hayan hecho sus propios sistemas de reportes, o su propio esquema de persistenacia, o sus propios protocolos, servidores, engines gráficos o hasta compiladores, parsers y maquinas virtuales??? yo diría que menos del 1%, sin embargo en Smalltalk es muy natural verlos y no es porque seamos ciegos o no podamos conectarnos a componentes, o nos sobre el tiempo o no nos interese la rentabilidad, es porque el tiempo nos demuestra que es mejor, mas rentable y porque nos sentimos con los medios y conocimientos para hacerlo. > Es muy bonito y educativo que en smalltalk se pueda hacer de todo (y me > encanta saber que tengo todo el sistema a mi merced para hacer cambios), pero > realmente, al menos para aplicaciones de gestión (estándar), dudo mucho que > tenga que llegar al punto de tener que modificar la VM, u objetos internos del > sistema, o tener que implementar un motor de reportes de cero, para un > propósito tan general, como hacer 25 pedidos, 30 albaranes, y 20 facturas. > > Quiero decir, que quizás, para mis propósitos, o por aprender, me embarcaría > en alguna manera de creación de reportes que fueran serializados a disco para > poder modificar desde otra herramienta, que supiera interpretar esos reportes, > y el cliente final pudiera modificarlos fácilmente a placer, pero no sé hasta > qué punto, sería rentable existiendo soluciones para ello (pongamos iReport o > CrystalReports como ejemplo), que ya llevan años de desarrollo especializado > exclusivamente en este tema. unos 10/15 años. Una vez, habia hecho un sistema bastante grande para el BID y Ministerio de Economía, hacía reportes de todo tipo y muy lindos. En un listado de facturas que tenía varias páginas y ciertos formatos, me pidieron que abajo de cada página les pusiera el total por página y el pedido era muy lógico, ya que los contadores firman esos reportes y deben verificar manualmente lo que están firmando. Crystal no tenía tal funcionalidad y era muy dificil cocinar una solución alternativa, porque el tamaño de la página era impredecible, porque meter subtotales era impracticable, y por muchas otras razones. Todo lo que me ahorre por usar Crystal lo perdí ahi, en ese 1% de funcionalidad que no pude resolver. Ese tipo de anécdotas me llevaron hoy a tener mis propias soluciones, si querés te paso alguna receta. > Un saludo, conversación interesante. Otro, Diego Coronel > On Thursday 11 November 2010 02:40:14 [hidden email] wrote: > > > > > > > Hola, > > Esto lo escuché muchas veces... > > > On Nov 9, 12:06 pm, Giuseppe Luigi Punzi <[hidden email]> > > > wrote: > > > Ahora que tengo un poco más de tiempo puedo explayarme :P > > > > Hace tiempo, me digeron una vez...para qué reinventar la rueda, si ya > > > existe algo que está muy bien hecho? > > > De los miles de modelos de autos que se inventaron (y de cualquier > > cosa que tenga ruedas), casi ninguno usa ruedas iguales. Las ruedas > > son redondas y sabemos cómo funcionan, pero en muchas oportunidades > > (casi todas) es bueno volver a construirlas. Con Smalltalk sobra poder > > para hacer practicamente cualquier cosa, a veces meter un componente > > puede ser una solución de corto plazo, pero a largo plazo conviene > > programar mas y pegotear menos. > > -- > -- > Giuseppe Luigihttp://www.lordzealon.com- Hide quoted text - > > - Show quoted text - -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Si, estamos de acuerdo.
Se puede ir implementando, pero si tengo que pensar desde el principio que me lo tengo que implementar todo... Si, está claro que los smalltalkers tienen cierto ego, y ciertos años suscrito a la lista de Squeak ha hecho darme cuenta que es cierto jejeje..recordemos la cita de cómo los distintos programadores matarían un dragón: Smalltalk - Llega, analiza al dragón y a la princesa, se da la vuelta y se pira: ellos son muy inferiores Un saludo. -- -- Giuseppe Luigi http://www.lordzealon.com -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Lo que decis refleja la visión que tiene la comunidad de los
smalltalkers y está bien reflejada en lo que contás, porque refleja ese sentimiento de que hablamos soberbiamente y que no hacemos nada al final. Y una parte de ese discurso es correcto porque Smalltalk enamora e intimida a la vez, mucha gente (incluyéndome) nos demoramos años hasta entenderlo y mientras tanto hablábamos de la bondades de Smalltalk pero a la hora de trabajar, cuando habia guita de por medio, pegábamos componentes con cualqueir cosa. En los ambientes académicos (sin ofender a nadie), como no hay guita de por medio, y por la limitación que se tiene de tiempo también Smalltalk suena un poco a eso. DIego PD: Hay muchos dragones muertos y princesas embarazadas por smalltalkers. On Nov 11, 8:55 am, Giuseppe Luigi Punzi <[hidden email]> wrote: > Si, estamos de acuerdo. > > Se puede ir implementando, pero si tengo que pensar desde el principio > que me lo tengo que implementar todo... > > Si, está claro que los smalltalkers tienen cierto ego, y ciertos años > suscrito a la lista de Squeak ha hecho darme cuenta que es cierto > jejeje..recordemos la cita de cómo los distintos programadores matarían > un dragón: > Smalltalk - Llega, analiza al dragón y a la princesa, se da la vuelta y > se pira: ellos son muy inferiores > > Un saludo. > > -- > -- > Giuseppe Luigihttp://www.lordzealon.com -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
> PD: Hay muchos dragones muertos y princesas embarazadas por smalltalkers.
Esto va de una a la remera de Smalltalks 2011!!! Saludos! Kikote y Diego idolos de ClubSmalltalk! -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
No te gusta mas:
pelota mancha not On Nov 11, 10:06 am, "Esteban A. Maringolo" <[hidden email]> wrote: > > PD: Hay muchos dragones muertos y princesas embarazadas por smalltalkers. > > Esto va de una a la remera de Smalltalks 2011!!! > > Saludos! > > Kikote y Diego idolos de ClubSmalltalk! -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
In reply to this post by Esteban A. Maringolo
Volviendo a lo que estaban hablando antes, yo me inclinaría por ir utilizando soluciones ya existentes. Al utilizar una solución, uno puede ver sus ventajas y desventajas, así llegado el caso de que se quiera desarrollar algo propio tengo una experiencia sobre el problema a resolver y si puedo hacer algo superador y adonde agregarle más flexibilidad.
Un detalle a tener en cuenta es que si utilizamos un componente externo, lo ideal es que sea open source, por si llego a tener un problema similar al que comentaron acá que tuvieron con Crystal Reports.
Me parece un camino más ágil, más iterativo e incremental. A otro nivel es como cuando hacemos TDD e implementamos la solución más sencilla que funcione y después podemos ir evolucionando la aplicación.
2010/11/11 Esteban A. Maringolo <[hidden email]>
To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Sería el ejemplo de Jasperreports. Es algo opensource en lo que una pequeña
problemática así, no debería ser problema. Además, Diego también comenta un caso muy específico y de hace 10 años, y desde entonces ha llovido mucho en el mundo de los informes. On Thursday 11 November 2010 18:06:19 Gabriel Brunstein wrote: > Volviendo a lo que estaban hablando antes, yo me inclinaría por ir > utilizando soluciones ya existentes. Al utilizar una solución, uno puede > ver sus ventajas y desventajas, así llegado el caso de que se quiera > desarrollar algo propio tengo una experiencia sobre el problema a resolver > y si puedo hacer algo superador y adonde agregarle más flexibilidad. > Un detalle a tener en cuenta es que si utilizamos un componente externo, lo > ideal es que sea open source, por si llego a tener un problema similar al > que comentaron acá que tuvieron con Crystal Reports. > Me parece un camino más ágil, más iterativo e incremental. A otro nivel es > como cuando hacemos TDD e implementamos la solución más sencilla que > funcione y después podemos ir evolucionando la aplicación. > > 2010/11/11 Esteban A. Maringolo <[hidden email]> > > > > PD: Hay muchos dragones muertos y princesas embarazadas por > > > smalltalkers. > > > > Esto va de una a la remera de Smalltalks 2011!!! > > > > Saludos! > > > > Kikote y Diego idolos de ClubSmalltalk! > > > > -- > > To post to this group, send email to [hidden email] > > To unsubscribe from this group, send email to > > [hidden email]<clubSmalltalk%2Bunsubscribe@go > > oglegroups.com> > > > > http://www.clubSmalltalk.org -- -- Giuseppe Luigi http://www.lordzealon.com -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Hola:
Claudio me paso una vez algo interesante y que quizas sea liviano http://en.wikipedia.org/wiki/XSL-FO Saludos GallegO -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
In reply to this post by Gaboto
Es el típico problema "build vs. Buy". Si pensamos que tenemos ventajas competitivas, nos coniene build. Si pensamos que no las tenemos nos conviene buy. En el largo plazo siempre conviene build, porque siempre desarrollamos una comprensión del problema por encima de lo que ofrece el mercado. En el corto plazo siempre conviene buy, porque no tenemos esa ventaja. Y como no sabemos que nos conviene (generalmente no tenemos idea si un problema en particular será de corrió p largo plazo), conviene crear delgadas capas de abstracción que nos permitan independizarnos de los proveedores cuando llegue el momento. Saludos, Guillermo Schwarz. -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Free forum by Nabble | Edit this page |