Mensajes: Mostrar resúmenes de los mensajes (Agrupar por tema)

#17188

De: "Leo De Marco" <leo@...>
Fecha: Mié, 18 de Nov, 2009 4:53 pm
Asunto: RE: [objetos] Reunión de fin de año

Sin conexión

si aprovechemos y hacemos la cena de fin de año!


> -----Mensaje original-----
> De: smalltalking@...
> [mailto:smalltalking@...] En nombre de Alejandro F.
> Reimondo
> Enviado el: lunes, 16 de noviembre de 2009 11:02 a.m.
> Para: smalltalking@...
> Asunto: Re: [objetos] Reunión de fin de año
>
> Hola,
> Por mi a partir de fin de este mes, puede ser cuando quieran.
> Dónde nos reunimos?
> Antes de fin de año?
> O aprovechamos para hacer la cena de fin de año?
> Ale.
>
>
> ----- Original Message -----
> From: "Miguel.Isasmendi" <miguel.isasmendi@...>
> To: <smalltalking@...>
> Sent: Monday, November 16, 2009 12:20 AM
> Subject: [objetos] Reunión de fin de año
>
>
> Hola,  estaría  bueno  que veamos si podemos juntarnos antes de fin de
> año. No se si pueden, o que fechas les parecen oportunas.
>
> --
>
> Miguel.
>
>
>
>
> ------------------------------------
>
> Para más información sobre la Asociación escribir a
> info@...
>
> Smalltalking es un espacio colaborativo creado para el estudio y
> desarrollo
> en Ambientes de Objetos.
> Se sustenta gracias a la participación de sus socios.
>
> Las reglas de etiqueta sobre la lista están en
> http://www.smalltalking.net/join/netiquete.htm
> Enlaces a Yahoo! Grupos
>
>
>
>
>
>
>
>
>
> ------------------------------------
>
> Para más información sobre la Asociación escribir a
> info@...
>
> Smalltalking es un espacio colaborativo creado para el estudio y
> desarrollo en Ambientes de Objetos.
> Se sustenta gracias a la participación de sus socios.
>
> Las reglas de etiqueta sobre la lista están en
> http://www.smalltalking.net/join/netiquete.htm
> Enlaces a Yahoo! Grupos
>
>
>
>

Responder | Reenviar | Mensajes en este tema (2)

#17187

De: "Alejandro F. Reimondo" <aleReimondo@...>
Fecha: Lun, 16 de Nov, 2009 2:01 pm
Asunto: Re: [objetos] Reunión de fin de año

alereimondo

Sin conexión

Enviar correo

Hola,
Por mi a partir de fin de este mes, puede ser cuando quieran.
Dónde nos reunimos?
Antes de fin de año?
O aprovechamos para hacer la cena de fin de año?
Ale.


----- Original Message -----
From: "Miguel.Isasmendi" <miguel.isasmendi@...>
To: <smalltalking@...>
Sent: Monday, November 16, 2009 12:20 AM
Subject: [objetos] Reunión de fin de año


Hola,  estaría  bueno  que veamos si podemos juntarnos antes de fin de
año. No se si pueden, o que fechas les parecen oportunas.

--

Miguel.




------------------------------------

Para más información sobre la Asociación escribir a info@...

Smalltalking es un espacio colaborativo creado para el estudio y desarrollo
en Ambientes de Objetos.
Se sustenta gracias a la participación de sus socios.

Las reglas de etiqueta sobre la lista están en
http://www.smalltalking.net/join/netiquete.htm
Enlaces a Yahoo! Grupos

Responder | Reenviar | Mensajes en este tema (2)

#17186

De: "Miguel.Isasmendi" <miguel.isasmendi@...>
Fecha: Lun, 16 de Nov, 2009 3:20 am
Asunto: Reunión de fin de año

miguel.isasm...

Sin conexión

Enviar correo

Hola,  estaría  bueno  que veamos si podemos juntarnos antes de fin de
año. No se si pueden, o que fechas les parecen oportunas.

--

Miguel.

Responder | Reenviar | Mensajes en este tema (1)

#17185

De: Hernan Wilkinson <hernan.wilkinson@...>
Fecha: Mar, 10 de Nov, 2009 4:30 pm
Asunto: Re: [objetos] Clase especial de Stephane Ducasse

hernan_wilki...

Sin conexión

Enviar correo

Si... podrían ser en Francés pero seguro que habría menos gente que los entendería :-)

2009/11/10 Darío Renzulli <dario.renzulli@...>

Hernan,

Las clases son en ingles?

D.

El 9 de noviembre de 2009 19:04, Hernan Wilkinson <hernan.wilkinson@...> escribió:

Que tal,

con el presente e-mail quiero informarles que Stephane Ducasse dará dos clases especiales de objetos en la materia de "Diseño Avanzado con Objetos" los días Lunes 16 y Miércoles 18 de Noviembre, de 19 hrs a 21:30 hrs en el laboratorio Epsilon, Pabellón I, del Departamento de Computación de la Facultad de Ciencias Exactas.

Los temas que abordará son amplios e incluyen:
* Advanced Object Oriented Design
* Double Dispatch
* Law of Demeter
* Self/Super semantics
* Compositions vs. Inheritance
* Traits
* Frameworks
* Object Oriented Application Reengineering
* Meta programming

La biografía de Stephane Ducasse la pueden ver en http://www.fast.org.ar/ y http://stephane.ducasse.free.fr/
Por la presente están todos invitados a asistir, me parece una oportunidad interesante para conocer y conversar con él.
Por favor, hagan extensible la invitación a todos aquellos que conozcan.

Saludos,
Hernán.

Responder | Reenviar | Mensajes en este tema (4)

#17184

De: Darío Renzulli <dario.renzulli@...>
Fecha: Mar, 10 de Nov, 2009 3:39 pm
Asunto: Re: [objetos] Clase especial de Stephane Ducasse

dario_renzulli

Sin conexión

Enviar correo

Hernan,

Las clases son en ingles?

El 9 de noviembre de 2009 19:04, Hernan Wilkinson <hernan.wilkinson@...> escribió:

Que tal,
con el presente e-mail quiero informarles que Stephane Ducasse dará dos clases especiales de objetos en la materia de "Diseño Avanzado con Objetos" los días Lunes 16 y Miércoles 18 de Noviembre, de 19 hrs a 21:30 hrs en el laboratorio Epsilon, Pabellón I, del Departamento de Computación de la Facultad de Ciencias Exactas.

Los temas que abordará son amplios e incluyen:
* Advanced Object Oriented Design
* Double Dispatch
* Law of Demeter
* Self/Super semantics
* Compositions vs. Inheritance
* Traits
* Frameworks
* Object Oriented Application Reengineering
* Meta programming

La biografía de Stephane Ducasse la pueden ver en http://www.fast.org.ar/ y http://stephane.ducasse.free.fr/
Por la presente están todos invitados a asistir, me parece una oportunidad interesante para conocer y conversar con él.
Por favor, hagan extensible la invitación a todos aquellos que conozcan.

Saludos,
Hernán.

Responder | Reenviar | Mensajes en este tema (4)

#17183

De: "Alejandro F. Reimondo" <aleReimondo@...>
Fecha: Mar, 10 de Nov, 2009 7:22 am
Asunto: Re: [objetos] Clase especial de Stephane Ducasse

alereimondo

Sin conexión

Enviar correo

Hola Hernán,

Representando a Smalltalking y los intereses de nuestra asociación,

debo decir gracias por usar nuestra lista para informar que se dará

la oportunidad a Stephane de una charla en la materia de objetos.

Auspiciamos esta actividad con nuestro clasico espíritu de camaradería

(muchas veces no correpondido), pero dejando en claro que los contenidos

posiblemente no reflejen nuestra óptica e incluso pueden ser contrarios

a la forma de entender Smalltalk y los AO en general (esto dicho

desde las referencias dadas en los documentos publicados por

Stephane en la web desde hace años).

Esta vez es alentador que en el temario no aparece la palabra "Evolución"! [*]

Recuerdo aún hoy lo ridiculo que fué ver que habíamos auspiciado en

esta lista (hace un año o mas?) de la misma forma a otra persona

hablar de evolución mezclandolo con temas de recoleccion de basura...

a personas sin experiencia pero con voluntad de explorar

"nuevas opticas".

Seguramente Stephane hará una clase estupenda pues es una persona

muy amable y el temario ha sido justamente su área de desarrollo;

desarrollo desde el pasado, pero desarrollo al menos de herramientas

de reflexión para ver código una vez que ya ha sido escrito.

En el sitio de Fats no pude encontrar información de valor, siguiendo

el otro link me encontré con información vieja, hay algun link a

material moderno en los temas que se van a tratar en la clase?

Algo nuevo y que pueda aplicarse desde nuestra óptica?

Como siempre nuestro interés es el dar espacios equivalentes

a las distintas fromas de enetender, aunque sabemos que cada

vez es mas frecuente encontrar que esos códigos no se respetan

en otros lugares. Y por eso insistimos en pedir al menos algo

que nos sea de valor tecnico, a cambio del uso de nuestros

medios para auspicio de actividades comerciales en espacios

que provee el estado (espacios que no son ofrecidos

equitativamente a organizaciones sin fin lucrativo).

un cordial saludo,

Ale.

[*] Esta palabra es usada de forma blanda, en numerosos trabajos

aprovechando que alienta a la fantasía, pero sin provecho tecnico

demostrable.

----- Original Message -----

From: Hernan Wilkinson

Sent: Monday, November 09, 2009 7:04 PM

Subject: [objetos] Clase especial de Stephane Ducasse

Que tal,
con el presente e-mail quiero informarles que Stephane Ducasse dará dos clases especiales de objetos en la materia de "Diseño Avanzado con Objetos" los días Lunes 16 y Miércoles 18 de Noviembre, de 19 hrs a 21:30 hrs en el laboratorio Epsilon, Pabellón I, del Departamento de Computación de la Facultad de Ciencias Exactas.

Los temas que abordará son amplios e incluyen:
* Advanced Object Oriented Design
* Double Dispatch
* Law of Demeter
* Self/Super semantics
* Compositions vs. Inheritance
* Traits
* Frameworks
* Object Oriented Application Reengineering
* Meta programming

La biografía de Stephane Ducasse la pueden ver en http://www.fast.org.ar/ y http://stephane.ducasse.free.fr/
Por la presente están todos invitados a asistir, me parece una oportunidad interesante para conocer y conversar con él.
Por favor, hagan extensible la invitación a todos aquellos que conozcan.

Saludos,
Hernán.

Responder | Reenviar | Mensajes en este tema (4)

#17182

De: Hernan Wilkinson <hernan.wilkinson@...>
Fecha: Lun, 9 de Nov, 2009 10:04 pm
Asunto: Clase especial de Stephane Ducasse

hernan_wilki...

Sin conexión

Enviar correo

Que tal,
con el presente e-mail quiero informarles que Stephane Ducasse dará dos clases especiales de objetos en la materia de "Diseño Avanzado con Objetos" los días Lunes 16 y Miércoles 18 de Noviembre, de 19 hrs a 21:30 hrs en el laboratorio Epsilon, Pabellón I, del Departamento de Computación de la Facultad de Ciencias Exactas.

Los temas que abordará son amplios e incluyen:
* Advanced Object Oriented Design
* Double Dispatch
* Law of Demeter
* Self/Super semantics
* Compositions vs. Inheritance
* Traits
* Frameworks
* Object Oriented Application Reengineering
* Meta programming

La biografía de Stephane Ducasse la pueden ver en http://www.fast.org.ar/ y http://stephane.ducasse.free.fr/
Por la presente están todos invitados a asistir, me parece una oportunidad interesante para conocer y conversar con él.
Por favor, hagan extensible la invitación a todos aquellos que conozcan.

Saludos,
Hernán.

Responder | Reenviar | Mensajes en este tema (4)

#17181

De: "Carlos E. Ferro" <ceferro@...>
Fecha: Sáb, 7 de Nov, 2009 2:05 pm
Asunto: Re: [objetos] Pensando en objetos ? 2

carloseferrob

Sin conexión

Enviar correo

kikoGregoris wrote:

> Ok, entiendo o creo entender a donde vas. La implementación funciona,
> solo me parecía que no era muy apropiada o que no estaba modelada de
> una forma muy a la objetos. A menudo me pasa que hago algo que
> funciona, y luego empiezo a pensar que el modelo implementado no es
> del todo correcto o que no tiene un estilo OO, por decirlo así. Esto
> me causa cierta insatisfacción con lo producido, y pienso si mis
> conceptos de base, de lo que es o no un objeto son correctos.

Yo creo que al programar pasa lo mismo que al escribir. Cuando uno empieza a escribir,
hay dos posibilidades: o está convencido de que todo lo que escribe es excelente
y se lo da a leer a familia y amigos, y no tiene autocrítica (y generalmente escribe mal)
o, el otro extremo, está convencido de que todo lo que escribe es basura, también se
lo da a leer a la familia y amigos pero interpreta que sus críticas están torcidas porque
lo quieren y no le ven los defectos. Corrige y corrige veinte veces lo mismo (a veces estropeándolo).
Con suerte, con tiempo, con práctica y probablemente con un buen taller literario donde
pueda interactuar con otros en su situación y un poco mejor, se puede llegar a un equilibrio
con un saludable nivel de crítica, una buena apreciación de la calidad de lo que escribe
y hasta dónde conviene mejorarlo.

Casi siempre que leemos código, incluso el nuestro (o sobre todo el nuestro) encontramos
cosas para mejorar. Tienen que pasar muchos años de uso y muchas revisiones para que
no quede algo por mejorar en una pieza de software.

No te preocupes entonces si lo que escribís no está del todo correcto, ya pasarás de nuevo
por ahí y lo escribirás mejor cuando haya más tiempo, más ganas o la necesidad te lleve.
No te preocupes por el estilo OO. Para empezar, si usás Smalltalk, el estilo es otro.
OO es "orientado a objetos"; en Smalltalk no estamos orientados, usamos objetos.
Eso hace que la mayoría de las cosas que dicen los libros (que sí están orientados)
no se apliquen exactamente así.
Por otro lado, vos tenés un estilo OO "en tu cabeza", imaginado. Distinto es cuando
trabajás con un equipo y el equipo tiene un estilo, pero tratar de satisfacer las expectativas
de lo que imaginás que es la "buena programación con objetos" con poca experiencia,
no tiene mucho sentido.
Mientras sigas trabajando solo, practicá mucho. Escribí la misma cosa de dos o tres maneras,
si no te gusta. Probá cada una, cómo impacta en el resto, cómo encaja y elegí la que
te deje trabajar más cómodo. Las correcciones no deberían venir de un prurito de corrección
ímaginaria, sino por necesidades de uso. Es tu código, vos tenés que convivir con él y te tiene
que quedar cómodo. Tiene que permitir y alentar tu desarrollo, es una herramienta de exploración.
Por supuesto, hay una parte estética también, pero eso es algo que tarda en desarrollarse.

> No sé si le pasa o les pasó a todos los que trabajan con objetos o si
> se lo plantean.

Sí, a todos nos pasa en algún momento. Ojo, que también es bueno escuchar las alarmas:
muchas veces, cuando "sentimos" que algo no está del todo bien, cuando hay una pequeña molestia,
un pequeño ruidito, nos advierte de algo malo en el diseño. Pero si no podemos determinar en
ese momento qué es o cómo corregirlo, es mejor dejarlo para más adelante y no obsesionarse.

> Seguramente esto tiene que ver con la experiencia y los años de
> trabajar con ST.

No sé, creo que el sentimiento aparece siempre y lo que te da la experiencia es más cancha
para ver cuándo conviene darle bola y hacer algo al respecto (y cómo) y cuando no.

Saludos
--

carlos e. ferro* *| senior developer* *| *caesar systems *| *see clearly. decide smarter.*

ceferro@... <mailto:ceferro@...> | t: +1.281.598.8790 | t: +54.11.4389.0126 | www.caesarsystems.com <http://www.caesarsystems.com/>

**This message and any attached documents contain information from Caesar Systems LLC that may be confidential/trade secret and/or privileged. If you are not the intended recipient, you may not read, copy, distribute or use this information. If you have received this transmission in error, please notify the sender immediately by telephone or by reply e-mail and then delete this message.

Responder | Reenviar | Mensajes en este tema (9)

#17180

De: "Carlos E. Ferro" <ceferro@...>
Fecha: Vie, 6 de Nov, 2009 4:53 pm
Asunto: Re: [objetos] Pensando en objetos ?

carloseferrob

Sin conexión

Enviar correo

kikoGregoris wrote (el 26/10):

> Gracias por responder y perdón la demora en mi respuesta.

No hay cuidado, yo me demoro más :-)

> La forma sirve, para dos cosas: 1) determinar cual es la región
> afectada por el brush , para luego levantar o bajar esos puntos. 2)
> En la imagen se ve que fuera de la region afectada, tambien debo
> levantar o bajar segun otro radio y segun un ángulo de inclinación
> que el usuario elija. Para hacer esto debo calcular los puntos de
> frontera del brush y para eso uso la forma. Luego trato a los puntos
> por zonas, como se ve en la imagen.

Suena bien, pero por la ambigüedad del lenguaje natural, suena igual de bien si lo hace el brush que si lo hace un objeto forma separado.

> Cada vez que el brush se mueve y
> trata de modelar , recalculo la frontera. Es por eso que es confuso,
> por un lado el recalcular la frontera todo el tiempo, me hace pensar
> que no vale la pena tener una clase Form a parte. Posiblemente no
> necesitaría una instancia y solo actuaria a nivel de clase(solo es un
> cálculo). Es curioso, si trabajara en C/C++ pondría un "IF circulate"
> y no me haría tanto drama jajaja.

Tener en un objeto separado la forma (ojo que Form es un formulario, el nombre sería Shape)
te fuerza en este esquema a que se tengan que comunicar cada vez que el pincel se mueve.
Eso no es grave pero no parece muy conveniente PERO depende de cuánto pueda variar la forma.
Si tenés sólo dos o tres, lo vas a poder resolver fácilmente con casos y distintos métodos.
Si son más, eso te va a complicar, agrandando mucho el protocolo de tu objeto
con mensajes que llevan dentro el "parámetro" de la forma. En ese caso, es más que
probable que te convenga tener otro objeto.

> Si entiendo. Otra cosa, el brush tiene dos modos de edición, aplanar
> o leventar. Para hacer esto, yo puse un colaborador sculpMode , que
> es un selector y luego hago un #perform: de este selector. Es una
> cosa que usó Ale en la demo de Genesis 3d, donde tenía dos modos para
> que la cámara actuara frente a un actor. Podía mirar al actor desde
> un punto fijo, o seguirlo.
>
> El #perform: mas costoso en computo que un #ifTrue: ?.

Bastante más costoso en general. Acá voto por el if sin dudar.
El #perform: es lindo pero genera rápidamente malas costumbres de
programación (como concatenar strings para armar selectores para hacer perform: después).
En cuanto a performance, generalmente te fuerza a hacer nuevamente un pedazo del method lookup.
Ese pedazo es más o menos grande,
dependiendo de cómo esté implementado el message lookup y el code cache o el inlined code cache.
El if, en cambio, es inmediato. Se traduce a instrucciones de jump de código máquina casi directamente.
Y es mentira que el código sea "más limpio", si pusiste perform para esto, es un if disimulado.

Saludos

--
carlos e. ferro* *| senior developer* *| *caesar systems *| *see clearly. decide smarter.*

ceferro@... <mailto:ceferro@...> | t: +1.281.598.8790 | t: +54.11.4389.0126 | www.caesarsystems.com <http://www.caesarsystems.com/>

**This message and any attached documents contain information from Caesar Systems LLC that may be confidential/trade secret and/or privileged. If you are not the intended recipient, you may not read, copy, distribute or use this information. If you have received this transmission in error, please notify the sender immediately by telephone or by reply e-mail and then delete this message.

Responder | Reenviar | Mensajes en este tema (9)

#17179

De: "Carlos E. Ferro" <ceferro@...>
Fecha: Mar, 3 de Nov, 2009 1:52 pm
Asunto: Re: ***SPAM*** Re: [objetos] Modelo de produccion

carloseferrob

Sin conexión

Enviar correo

kikoGregoris wrote:

Hola Carlos

Sí, seguro. Pero la tecnología pone anteojeras para mirar y pensar, genera comunidades
y culturas de las que luego es difícil "escaparse".

En algun punto, simpre me preocupo la inversa. Es decir, el luego no encajar en el mercado, porque uso ST y tengo mis propios parametros, reglas, etc.

¿Y quién querría "encajar en el meercado"?

Fuera de la broma y de los planteos ideológicos, hay algo que ya se ha dicho varias veces en la lista: al "mercado" no le importa cómo está hecha su solución de software.
Al cliente le interesa que haya una solución, no en qué está hecha.
Ese "interés" lo tienen las consultoras, las software factory y la gente de IT. Pero no los usuarios.
Entonces, si vos querés "encajar" en el modelo de una software factory, olvidate de Smalltalk (salvo que lo uses para hacer herramientas que faciliten el trabajo, como mostró Bruno el año pasado). Pero para todo lo demás...
Por supuesto, si querés entrar en el "mundo de la empresa" vas a tener que hacer interfaces con otras tecnologías, lo que implicará conocerlas mínimamente: bases de datos, DLLs, Java, OLE/COM, etc.
Pero mayormente, podés hacer el modelo en Smalltalk y exportar lo necesario.

Resumiendo: yo no me preocuparía.

>> Que bueno que hay gente y empresas que laburan así

Sí, hoy en día hay varias alternativas de empresas que trabajan con Smalltalk.
Ya no es imprecsindible que uno genere su propia alternativa :-)

Saludos

--
signature

carlos e. ferro | senior developer | caesar systems | see clearly. decide smarter.

ceferro@... | t: +1.281.598.8790 | t: +54.11.4389.0126 | www.caesarsystems.com

This message and any attached documents contain information from Caesar Systems LLC that may be confidential/trade secret and/or privileged. If you are not the intended recipient, you may not read, copy, distribute or use this information. If you have received this transmission in error, please notify the sender immediately by telephone or by reply e-mail and then delete this message.

Responder | Reenviar | Mensajes en este tema (42)

#17178

De: kikoGregoris <kikogregoris@...>
Fecha: Lun, 2 de Nov, 2009 5:51 pm
Asunto: Re: ***SPAM*** Re: [objetos] Modelo de produccion

kikogregoris

Sin conexión

Enviar correo

Hola Carlos

Sí, seguro. Pero la tecnología pone anteojeras para mirar y pensar, genera comunidades
y culturas de las que luego es difícil "escaparse".

En algun punto, simpre me preocupo la inversa. Es decir, el luego no encajar en el mercado, porque uso ST y tengo mis propios parametros, reglas, etc.

Que bueno que hay gente y empresas que laburan así

saludos

--- El lun 2-nov-09, Carlos E. Ferro <ceferro@...> escribió:

De: Carlos E. Ferro <ceferro@...>
Asunto: Re: ***SPAM*** Re: [objetos] Modelo de produccion
Para: smalltalking@...
Fecha: lunes, 2 de noviembre de 2009, 9:57 am

Sebastian Gurin wrote (el 21/10):

> alejandro decía:

>

>>> 2.- sobre que "todo en smalltalk es un objeto", te lo
creiste

>>> solo al comienzo no? Sabes que no es asi... no? (si aun
crees que

>>> en smalltalk todo es un objeto, no dejes de ir a una de
nuestras

>>> presentaciones de ambientes de objetos :-) lo digo en
serio... te

>>> estas perdiendo de "algo importante" si pensas que esa
muletilla

>>> introductoria es correcta.

>>

>

> Me gustaría oir ejemplos de entidades que en smalltalk no son

> objetos...

Está todo el tema de emergentes, que comentaba muy bien Bruno en su respuesta.
pero además (o tal vez es lo mismo) el Smalltalk mismo no es un objeto.
No me refiero al SystemDictionary, sino al ambiente Smalltalk.
Está hecho con objetos, "lleno" de objetos, pero no es un objeto.

> Ahora, bien yo creo que aunque la
tecnología nos empuje hacia un

> lado, también nos empujan el tipo de proyecto y nuestras propias

> decisiones.
> Por ejemplo, estoy seguro que hay
programadores smalltalk

> con más tendencia a utilizar módulos que algunos programadores
java.

> O sea la creatividad, las ganas de aprender, las ganas de

> enriquecerse resolviendo un problema, van a ser distintas segun la

> tecnología que utilicemos, pero también según las ganas ( o los

> objetivos) de cada uno.

Sí, seguro. Pero la tecnología pone anteojeras para mirar y pensar, genera comunidades
y culturas de las que luego es difícil "escaparse".

> Lamentablemente concuerdo, muchos
colegas javaleros encuentran mucho

> más gratificante ver el problema resuelto por unos frameworks que

> ellos se encargaron de anudar, que resolver por ellos mismos el

> problema. Bueno no se si "lamentablemente" ; sigo sosteniendo que
hay

> diferentes clases de programadores. ..

De acuerdo que hay distintas clases de programadores/ desarrolladores.
Pero para mí, el disfrute de resolver algo "acomodando piezas" es más como
el disfrute de resolver un crucigrama o armar un rompecabezas.
Siempre estamos en algo que otro propuso, con un tope establecido.
Cuando modelo yo, el disfrute es otro y no hay límite. Es el juego infinito
que menciona Alejandro.

> Pregunta de novato, relacionada con lo anterior ,¿cuando hablamos
de

> programadores, hablamos de alguien que busca desarrollar
capacidades?

Temo que el término se popularizó y amplió demasiado su significado.
No sabría contestarte bien a esa pregunta. Yo prefiero desarrollador para
lo que hago, pero en los formularios muchas veces pongo Programador.

> ¿ "desarrollar capacidades" es
"programar" ? ¿ desarrollar es

> desarrollarnos ?

Son excelentes preguntas.
Hay muchas más capacidades para desarrollar que las que están relacionadas
con programar, así que diría NO a la primera.
A la segunda digo que sí con entusiasmo. Cada vez que desarrollo una solución,
me desarrollo yo; adquiero nuevo conocimiento o al menos práctica de
habilidades.

> Por ejemplo, me viene a la cabeza
un peón de

> construcción que pasa por el edificio terminado: el tipo siente

> gratificación por el edificio, en gral él no se dearrolló, se

> desarrolló la construcción.

Hmmm... Dudo mucho de que el peón sienta gratificación por el edificio,
es muy difícil que pueda reconocer su aporte en el producto terminado.
Me lo creería del arquitecto. El peón puede recordar los "buenos momentos"
que pasó durante la obra, pero no creo que disfrute del edificio terminado.

> Lo mismo la gratificación de un
jardinero

> veterano al sentarse a oler el cesped recién cortado: lo
gratificante

> es el acto de contemplar la "obra"...

En esto sí, el disfrute es más directo. Pero lo disfruta más porque lo cortó él:
si hubiera apretado un botón y una máquina se lo cortara automáticamente
(usando un framework) ¿lo disfrutaría igual? Creo que disfrutaría del aroma,
de la vista, pero se perdería muchas otras cosas.

Saludos
--

carlos e. ferro* *| senior developer* *| *caesar systems *| *see clearly. decide smarter.*

ceferro@caesarsyste ms.com <mailto:ceferro@ caesarsystems. com> | t: +1.281.598.8790 | t: +54.11.4389. 0126 | www.caesarsystems. com <http://www.caesarsy stems.com/>

**This message and any attached documents contain information from Caesar Systems LLC that may be confidential/ trade secret and/or privileged. If you are not the intended recipient, you may not read, copy, distribute or use this information. If you have received this transmission in error, please notify the sender immediately by telephone or by reply e-mail and then delete this message.

Encontra las mejores recetas con Yahoo! Cocina.
http://ar.mujer.yahoo.com/cocina/

Responder | Reenviar | Mensajes en este tema (42)

#17177

De: "Carlos E. Ferro" <ceferro@...>
Fecha: Lun, 2 de Nov, 2009 11:57 am
Asunto: Re: ***SPAM*** Re: [objetos] Modelo de produccion

carloseferrob

Sin conexión

Enviar correo

Sebastian Gurin wrote (el 21/10):

> alejandro decía:
>
>>> 2.- sobre que "todo en smalltalk es un objeto", te lo creiste
>>> solo al comienzo no? Sabes que no es asi... no? (si aun crees que
>>> en smalltalk todo es un objeto, no dejes de ir a una de nuestras
>>> presentaciones de ambientes de objetos :-) lo digo en serio... te
>>> estas perdiendo de "algo importante" si pensas que esa muletilla
>>> introductoria es correcta.
>>
>
> Me gustaría oir ejemplos de entidades que en smalltalk no son
> objetos...

Está todo el tema de emergentes, que comentaba muy bien Bruno en su respuesta.
pero además (o tal vez es lo mismo) el Smalltalk mismo no es un objeto.
No me refiero al SystemDictionary, sino al ambiente Smalltalk.
Está hecho con objetos, "lleno" de objetos, pero no es un objeto.

> Ahora, bien yo creo que aunque la tecnología nos empuje hacia un
> lado, también nos empujan el tipo de proyecto y nuestras propias
> decisiones.
> Por ejemplo, estoy seguro que hay programadores smalltalk
> con más tendencia a utilizar módulos que algunos programadores java.
> O sea la creatividad, las ganas de aprender, las ganas de
> enriquecerse resolviendo un problema, van a ser distintas segun la
> tecnología que utilicemos, pero también según las ganas ( o los
> objetivos) de cada uno.

Sí, seguro. Pero la tecnología pone anteojeras para mirar y pensar, genera comunidades
y culturas de las que luego es difícil "escaparse".

> Lamentablemente concuerdo, muchos colegas javaleros encuentran mucho
> más gratificante ver el problema resuelto por unos frameworks que
> ellos se encargaron de anudar, que resolver por ellos mismos el
> problema. Bueno no se si "lamentablemente"; sigo sosteniendo que hay
> diferentes clases de programadores...

De acuerdo que hay distintas clases de programadores/desarrolladores.
Pero para mí, el disfrute de resolver algo "acomodando piezas" es más como
el disfrute de resolver un crucigrama o armar un rompecabezas.
Siempre estamos en algo que otro propuso, con un tope establecido.
Cuando modelo yo, el disfrute es otro y no hay límite. Es el juego infinito
que menciona Alejandro.

> Pregunta de novato, relacionada con lo anterior ,¿cuando hablamos de
> programadores, hablamos de alguien que busca desarrollar capacidades?

Temo que el término se popularizó y amplió demasiado su significado.
No sabría contestarte bien a esa pregunta. Yo prefiero desarrollador para
lo que hago, pero en los formularios muchas veces pongo Programador.

> ¿ "desarrollar capacidades" es "programar" ? ¿ desarrollar es
> desarrollarnos ?

Son excelentes preguntas.
Hay muchas más capacidades para desarrollar que las que están relacionadas
con programar, así que diría NO a la primera.
A la segunda digo que sí con entusiasmo. Cada vez que desarrollo una solución,
me desarrollo yo; adquiero nuevo conocimiento o al menos práctica de
habilidades.

> Por ejemplo, me viene a la cabeza un peón de
> construcción que pasa por el edificio terminado: el tipo siente
> gratificación por el edificio, en gral él no se dearrolló, se
> desarrolló la construcción.

Hmmm... Dudo mucho de que el peón sienta gratificación por el edificio,
es muy difícil que pueda reconocer su aporte en el producto terminado.
Me lo creería del arquitecto. El peón puede recordar los "buenos momentos"
que pasó durante la obra, pero no creo que disfrute del edificio terminado.

> Lo mismo la gratificación de un jardinero
> veterano al sentarse a oler el cesped recién cortado: lo gratificante
> es el acto de contemplar la "obra"...

En esto sí, el disfrute es más directo. Pero lo disfruta más porque lo cortó él:
si hubiera apretado un botón y una máquina se lo cortara automáticamente
(usando un framework) ¿lo disfrutaría igual? Creo que disfrutaría del aroma,
de la vista, pero se perdería muchas otras cosas.

Saludos
--

carlos e. ferro* *| senior developer* *| *caesar systems *| *see clearly. decide smarter.*

ceferro@... <mailto:ceferro@...> | t: +1.281.598.8790 | t: +54.11.4389.0126 | www.caesarsystems.com <http://www.caesarsystems.com/>

**This message and any attached documents contain information from Caesar Systems LLC that may be confidential/trade secret and/or privileged. If you are not the intended recipient, you may not read, copy, distribute or use this information. If you have received this transmission in error, please notify the sender immediately by telephone or by reply e-mail and then delete this message.

Responder | Reenviar | Mensajes en este tema (42)

#17176

De: "Carlos E. Ferro" <ceferro@...>
Fecha: Vie, 30 de Oct, 2009 4:55 pm
Asunto: Re: Modelo de produccion

carloseferrob

Sin conexión

Enviar correo

Sebastian Gurin wrote (el 09/10, pero aún atrasado todavía quería comentar algo):
>
> Hola a todos! me parece muy interesante comparar los diferentes
> objetivos o prioridades de quien realiza la tarea de "programar". Yo
> de esta charla saco mi primer conclusión "personal" (algo nuevo para
> mi), es que "ser productivo" es muchísimo ma´s que "que cantidad de
> software / tiempo".

Claro. Eso es como querer medir la producción de software contando líneas de código.
Un enfoque así es muy limitado.
Desarrollando software producimos muchas cosas: conocimiento, por ejemplo (aunque más que producirlo,
diría que lo capturamos; es una actividad extractiva).
Producimos también cambios en nuestro grupo y en nuestros clientes, en nuestra comunidad.

> Ahora bien sigo opinando que hay situaciones en las cuales "la
> modularidad se impone". Si tenemos suerte podremos safar, pero si se
> trata de trabajo muchas veces no. Hay clientes que quieren y piden
> "un plugin para firefox"! Haciendo el mismo razonamiento que hoy yo
> supongo que si nos dedicamos a nuestras rueditas siempre, corremos el
> riezgo de perder la agilidad para integrar módulos. Yo voto por tener
> presente ambas cosas al momento de elegir, voto por elegir....

Estamos de acuerdo. Aunque planteé en principio uan posición extrema, para favorecer la discusión,
también me parece mejor tener las alternativas y elegir. Eso sí, con un buen proceso de decisión e información,
evaluando las alternativas y sus efectos, sabiendo "en qué nos metemos".

Disiento en que "dedicarnos a nuestras rueditas" (~ programar nuestras propias soluciones)
nos haga perder ninguna agilidad. Creo que al contrario, el "ojo entrenado" del programador, su experiencia
en haber resuelto un gran número de problemáticas (incluso si no son muy similares) es clave para
evaluar mejor las cosas que decía arriba.

> También sostengo la postura de que algunas situaciones es
> justificable querer evitar entender / implementar cierta
> problematica. Hay problematicas que muchas veces nada tienen que ver
> con el "modelo de dominio" de nuestra app (sobre lo que nos interesa
> enfocarnos y aprender) y ¿ por qué tenemos que desear entenderlas y
> resolverlas sin ayuda ? Es cierto, no podemos evitar entenderla, pero
> sin un framework tenemos que entenderla por completo...

Es cierto. Además, el framework te permite "dosificar" cuándo vas a necesitar entenderlo.
El problema es que mientras tanto, vos "compres" la idea de que
el problema está resuelto. Eso suele estalllar en la cara en los momentos más
inoportunos, y ahí "pagás" de golpe la couta de aprendizaje y tiempo que
te querías "ahorrar".

> Bueno no se, quería comparar el caso de la rueda de carlos, . Yo
> también tengo proyectos que son así, desde cero, resolviendo las
> problematicas y descubriendo mis formas de resolverlas. El placer es
> más grande cuando se logra algo en ese contexto que cuando se logra
> "hacer andar un framework". Me parece interesante comparar este tipo
> de desarrollo con lo que sucede hoy en día tecnologías como java. Ya
> no existen los frameworks; lo que existe ahora son los estándares.

> Sun o quien sea, hace un estándar para portales web, otros para
> persistencia de objetos, otros para tecnologías de presentación web,
> otro para transmisión de mensajes, etc. Para "cualquier" actividad o
> problematica que se le plantee al desarrollador java existe un
> estándar, que más o menos converje con la problematica personal. Si
> existe el estándar existen 1 o más implementaciones (aunque, juas,
> muchas veces ocurre que 1) hacen un estándar y demoran tiempo en
> surgir implementaciones 2) estándares que solo tienen y tuvieron 1
> implementación)

Ese modelo genera programadores como los entiende la empresa, el mercado
y la ingeniería de software: idiotas útiles que saben apretar las teclas, para
cumplir los requerimientos esbozados por los que "la tienen clara".
Eso no estaría tan mal (funciona en la construcción, el obrero raso va y hace
las tareas manuales que le indican) si no hubiera demostrado ser un modelo
que fracasa en más del 50% de los proyectos.

> estandarizar :( Que veo entonces:
> * todos programamos en lo mismo y de la misma forma. Actualmente la
> jvm soporta otros lenguajes de scripting, pero se programa en el
> mismo framework-estándar-lenguaje. Más aún, muchos
> toolkits/frameworks hoy en día ya no son distribuidos como las
> clasicas librerías (modulos) sino que el usuario se baja la sdk (el
> entorno de desarrollo para programar con eso)...

Y así, cada vez más, para programar depende de otro que le dio las herramientas
y aumenta la convicción generalizada de que no puede resolver un problema él solo.

> Me interesa comparar este contexto con un smalltalk, en dónde como
> decía carlos, uno tiene tanta libertad para escojer el nivel en el
> cual trabajar, no hay limites entre mis objetos y el resto del
> sistema, las pocas leyes que hay son suceptibles de ser cambiadas por
> el usr, como el concepto de herencia, mensaje, etc. Son como dos
> extremos en lo que respecta al insentivo que tienen, como
> tecnologías, sobre el desarrollador...

Efectivamente. Si bien te exageré el punto de vista, es cierto que el programador Smalltalk
tiene otras cosas en la cabeza, generalmente.
No se preocupa por la tecnología, ni por los estándares (esto tiene su efecto negativo)
ni por el sistema operativo, ni por la red, ni por la base de datos...
Por supuesto, en algún momento y lugar tiene que atacar esas problemáticas,
pero en ese momento, son una problemática como cualquier otra que plantee el cliente.
Saludos
--

carlos e. ferro* *| senior developer* *| *caesar systems *| *see clearly. decide smarter.*

ceferro@... <mailto:ceferro@...> | t: +1.281.598.8790 | t: +54.11.4389.0126 | www.caesarsystems.com <http://www.caesarsystems.com/>

**This message and any attached documents contain information from Caesar Systems LLC that may be confidential/trade secret and/or privileged. If you are not the intended recipient, you may not read, copy, distribute or use this information. If you have received this transmission in error, please notify the sender immediately by telephone or by reply e-mail and then delete this message.

Responder | Reenviar | Mensajes en este tema (42)

#17175

De: kikoGregoris <kikogregoris@...>
Fecha: Mar, 27 de Oct, 2009 1:25 pm
Asunto: RE: AlphaChannel (Dolphin X6)

kikogregoris

Sin conexión

Enviar correo

Hola

Hay va tomando algo de forma, la pintada.

saludos

Encontra las mejores recetas con Yahoo! Cocina.
http://ar.mujer.yahoo.com/cocina/

Foto 1 de 1

screen.JPG

Responder | Reenviar | Mensajes en este tema (1)

#17174

De: Sebastian Gurin <sgurin@...>
Fecha: Lun, 26 de Oct, 2009 4:30 pm
Asunto: Re: [objetos] Bitmap alphaChannel (Dolphin X6) ?

cancerbero_sgx

Sin conexión

Enviar correo

Hola. No conozco la tecnología con la que trabajas así que toma lo que te digo
con pinzas, pero así a simple vista tengo entendido que el tipo de imágen bmp no
soporta transparencia por lo cual es natural que el alpha te devuelva 255 (100%
opaco). Te recomiendo probar lo mismo pero con el tipo png. suerte

On Mon, 26 Oct 2009 06:44:44 -0700 (PDT)
kikoGregoris <kikogregoris@...> wrote:

> Hola gente
>
> Tengo que obtener el valor del canal alpha de un bitmap en grayscale, y no veo
forma de hacer esto en Dolphin.
>
> Miro la clase Bitmap , Image y  GdiPlusImage.
> Traté de hacer algo como esto:
>
> GdiplusBitmap fromBitmap: (  Bitmap fromFile: 'C:\Documents and
Settings\Gregoris\Mis documentos\Dolphin Smalltalk
X6\TerrainEditor\assets\Textures\test.bmp')
>
> Luego miro el canal alpha así:
> 1 to: 255 do:[: x | 1 to: 255 do:[:i | (self pixelAt: x@i ) alpha  < 255
ifTrue:[^x@i]]].
>
> Para ver si hay algo, pero todos los alpha son 255.
>
>
> Incluso en el ejemplo:
>
> GdiplusGraphics>>exampleGdipGAlphaBlending
>     "Using GDI+ .... Alpha Blending Lines and Fills ... Using Compositing Mode
to Control Alpha Blending
>
>         self exampleGdipGAlphaBlending showExample
>     "
>
>     "Create a blank bitmap."
>
>     | bitmap graphics redBrush greenBrush bitmap2 graphics2 |
>     bitmap := GdiplusBitmap width: 180 height: 100.
>     "Create a Graphics object that we can use to draw on the bitmap."
>     graphics := bitmap graphics.
>     "Create a red brush and a green brush, each with an alpha value of 160."
>     redBrush := GdiplusSolidBrush color: (ARGB fromArray: #(210 255 0 0)).
>     greenBrush := GdiplusSolidBrush color: (ARGB fromArray: #(210 0 255 0)).
>     "Set the compositing mode so that when we draw overlapping ellipses,
>     the colors of the ellipses are not blended."
>     graphics compositingMode: CompositingModeSourceCopy.
>     "Fill an ellipse using a red brush that has an alpha value of 160."
>     graphics fillEllipse: (0 @ 0 extent: 150 @ 70) brush: redBrush.
>     "Fill a second ellipse using green brush that has an alpha value of 160.
>     The green ellipse overlaps the red ellipse, but the green is not blended
with the red."
>     graphics fillEllipse: (30 @ 30 extent: 150 @ 70) brush: greenBrush.
>     "Prepare to draw on the screen."
>     bitmap2 := GdiplusBitmap extent: 400 @ 200.
>     graphics2 := bitmap2 graphics clear: ARGB white.
>     graphics2 compositingQuality: CompositingQualityGammaCorrected.
>     "Draw a multicolored background."
>     graphics2 fillRectangle: (200 @ 0 extent: 60 @ 100)
>         brush: (GdiplusSolidBrush color: (ARGB stdColor: #aqua)).
>     graphics2 fillRectangle: (260 @ 0 extent: 60 @ 100)
>         brush: (GdiplusSolidBrush color: (ARGB stdColor: #yellow)).
>     graphics2 fillRectangle: (320 @ 0 extent: 60 @ 100)
>         brush: (GdiplusSolidBrush color: (ARGB stdColor: #fuchsia)).
>     "Display the bitmap on a white background."
>     graphics2 drawImage: bitmap at: 0 @ 0.
>     "Display the bitmap on a multicolored background."
>     graphics2 drawImage: bitmap at: 200 @ 0.
>     ^bitmap2
>
>
> Todos los alpha de la imagen son 255 !!.
>
>
> Algo me estoy perdiendo y no  veo que es.
> Alguna idea de como  hacer esto ?
>
> saludos kiko
>
>
>
>
>
>
>       Yahoo! Cocina
>
> Encontra las mejores recetas con Yahoo! Cocina.
>
>
> http://ar.mujer.yahoo.com/cocina/


--
Sebastian Gurin <sgurin@...>

Responder | Reenviar | Mensajes en este tema (3)

#17173

De: kikoGregoris <kikogregoris@...>
Fecha: Lun, 26 de Oct, 2009 8:23 pm
Asunto: Re: [objetos] Bitmap alphaChannel (Dolphin X6) ?

kikogregoris

Sin conexión

Enviar correo

Hola gente

Ya esta resuelto, gracias

saludos

--- El lun 26-oct-09, kikoGregoris <kikogregoris@...> escribió:

De: kikoGregoris <kikogregoris@...>
Asunto: [objetos] Bitmap alphaChannel (Dolphin X6) ?
Para: smalltalking@...
Fecha: lunes, 26 de octubre de 2009, 11:44 am

Hola gente

Tengo que obtener el valor del canal alpha de un bitmap en grayscale, y no veo forma de hacer esto en Dolphin.

Miro la clase Bitmap , Image y GdiPlusImage.
Traté de hacer algo como esto:

GdiplusBitmap fromBitmap: ( Bitmap fromFile: 'C:\Documents and Settings\Gregoris\ Mis documentos\Dolphin Smalltalk X6\TerrainEditor\ assets\Textures\ test.bmp' )

Luego miro el canal alpha así:
1 to: 255 do:[: x | 1 to: 255 do:[:i | (self pixelAt: x@i ) alpha < 255 ifTrue:[^x@i] ]].

Para ver si hay algo, pero todos los alpha son 255.

Incluso en el ejemplo:

GdiplusGraphics>>exampleGdipGAlphaBl ending
    "Using GDI+ .... Alpha Blending Lines and Fills ... Using Compositing Mode to Control Alpha Blending

        self exampleGdipGAlphaBl ending showExample
    "

    "Create a blank bitmap."

    | bitmap graphics redBrush greenBrush bitmap2 graphics2 |
    bitmap := GdiplusBitmap width: 180 height: 100.
    "Create a Graphics object that we can use to draw on the bitmap."
    graphics := bitmap graphics.
    "Create a red brush and a green brush, each with an alpha value of 160."
    redBrush := GdiplusSolidBrush color: (ARGB fromArray: #(210 255 0 0)).
    greenBrush := GdiplusSolidBrush color: (ARGB fromArray: #(210 0 255 0)).
    "Set the compositing mode so that when we draw overlapping ellipses,
    the colors of the ellipses are not blended."
    graphics compositingMode: CompositingModeSour ceCopy.
    "Fill an ellipse using a red brush that has an alpha value of 160."
    graphics fillEllipse: (0 @ 0 extent: 150 @ 70) brush: redBrush.
    "Fill a second ellipse using green brush that has an alpha value of 160.
    The green ellipse overlaps the red ellipse, but the green is not blended with the red."
    graphics fillEllipse: (30 @ 30 extent: 150 @ 70) brush: greenBrush.
    "Prepare to draw on the screen."
    bitmap2 := GdiplusBitmap extent: 400 @ 200.
    graphics2 := bitmap2 graphics clear: ARGB white.
    graphics2 compositingQuality: CompositingQualityG ammaCorrected.
    "Draw a multicolored background."
    graphics2 fillRectangle: (200 @ 0 extent: 60 @ 100)
        brush: (GdiplusSolidBrush color: (ARGB stdColor: #aqua)).
    graphics2 fillRectangle: (260 @ 0 extent: 60 @ 100)
        brush: (GdiplusSolidBrush color: (ARGB stdColor: #yellow)).
    graphics2 fillRectangle: (320 @ 0 extent: 60 @ 100)
        brush: (GdiplusSolidBrush color: (ARGB stdColor: #fuchsia)).
    "Display the bitmap on a white background."
    graphics2 drawImage: bitmap at: 0 @ 0.
    "Display the bitmap on a multicolored background."
    graphics2 drawImage: bitmap at: 200 @ 0.
    ^bitmap2

Todos los alpha de la imagen son 255 !!.

Algo me estoy perdiendo y no veo que es.
Alguna idea de como hacer esto ?

saludos kiko

Encontra las mejores recetas con Yahoo! Cocina.
http://ar.mujer. yahoo.com/ cocina/

Encontra las mejores recetas con Yahoo! Cocina.
http://ar.mujer.yahoo.com/cocina/

Responder | Reenviar | Mensajes en este tema (3)

#17172

De: kikoGregoris <kikogregoris@...>
Fecha: Lun, 26 de Oct, 2009 2:32 pm
Asunto: Re: [objetos] Pensando en objetos ?

kikogregoris

Sin conexión

Enviar correo

Hola Carlos

Gracias por responder y perdón la demora en mi respuesta.
Te comento brevemente de que trata el problema en la implementación, es posible que aclare algo, mando dos imagenes para que se vea bien.

La forma sirve, para dos cosas:
1) determinar cual es la región afectada por el brush , para luego levantar o bajar esos puntos.
2) En la imagen se ve que fuera de la region afectada, tambien debo levantar o bajar segun otro radio y segun un ángulo de inclinación que el usuario elija.
Para hacer esto debo calcular los puntos de frontera del brush y para eso uso la forma.
Luego trato a los puntos por zonas, como se ve en la imagen.
Cada vez que el brush se mueve y trata de modelar , recalculo la frontera.
Es por eso que es confuso, por un lado el recalcular la frontera todo el tiempo, me hace pensar que no vale la pena tener una clase Form a parte. Posiblemente no necesitaría una instancia y solo actuaria a nivel de clase(solo es un cálculo).
Es curioso, si trabajara en C/C++ pondría un "IF circulate" y no me haría tanto drama jajaja.

La solución "de libro" es esa: una clase abstracta BrushTip con subclases CircularTip y SquareTip o algo así, y que el formón derive las cosas que tienen que ver con la forma a su punta. Esta solución, que se ve super elegante en el papel, cuando no está muy bien guiada por el diseño termina en unos flujos espantosos de mensajes y doubles dispatches, a veces llegando (en un extremo) a que el formón no hace nada más que forwardearle mensajes a la punta, y la punta hace todo.
De nuevo: esto no quiere decir que esa solución sea mala (o buena) en sí, sino que hay que ver mucho más del problema y del diseño circundante antes de poder opinar de manera útil.

Si entiendo.
Otra cosa, el brush tiene dos modos de edición, aplanar o leventar.
Para hacer esto, yo puse un colaborador sculpMode , que es un selector y luego hago un #perform: de este selector.
Es una cosa que usó Ale en la demo de Genesis 3d, donde tenía dos modos para que la cámara actuara frente a un actor.
Podía mirar al actor desde un punto fijo, o seguirlo.

El #perform: mas costoso en computo que un #ifTrue: ?.

Bueno espero haber aclarado jajaj

saludos

--- El mié 14-oct-09, Carlos E. Ferro <ceferro@...> escribió:

De: Carlos E. Ferro <ceferro@...>
Asunto: Re: [objetos] Pensando en objetos ?
Para: smalltalking@...
Fecha: miércoles, 14 de octubre de 2009, 10:04 am

kikoGregoris wrote:
>

> Tengo un problema para modelar un objetos que llamo Brush, el cual
se

> encarga de modelar un terreno. Como si fuera un formón de un

> carpintero. Este Brush puede ser de dos formas( por el momento),

> circular o cuadrado, pero podría ser de infinitas formas. En un

> modelado rápido puse: Brush SquaredBrush CircleBrush. Yo creo que

> esta muy mal y que Brush solo debería conocer de que forma es y

> actuar en consecuencia.

Es difícil decir que está mal sin saber cuál es la responsabilidad/ funcionalidad del objeto, qué protocolo tiene y cómo interactúa con el resto.
Los nombres suenan mal y disparan alarmas, es cierto, porque no parece esencial a un formón (aunque la traducción de brush sería pincel) ser cuadrado o circular como para que eso determine dos subclases distintas.
Parece subclasificación por implementación. Pero repito, no se puede uno guiar sólo por el nombre y el diagrama de clases.

> El tema es que no puedo lograr que
funcione

> de esta forma y por eso entre a dudar. Si pienso en el ejemplo del

> formón, en la realidad este es de una forma u otra, no tiene una

> punta intercambiable. Lo cual me confunde, porque hace parecer que
mi

> modelo esta bien y que Formón/Brush tiene subclases Pero aquí los

> objetos son virtuales.jajaj

El no lograr que funcione es otra alarma, también fuerte. Si separar otro objeto para que tenga la diferencia entre cuadrado y circular (vos mencionás la punta en tu ejemplo) termina en mucha incomodidad, probablemente no era una buena decisión.
La solución "de libro" es esa: una clase abstracta BrushTip con subclases CircularTip y SquareTip o algo así, y que el formón derive las cosas que tienen que ver con la forma a su punta. Esta solución, que se ve super elegante en el papel, cuando no está muy bien guiada por el diseño termina en unos flujos espantosos de mensajes y doubles dispatches, a veces llegando (en un extremo) a que el formón no hace nada más que forwardearle mensajes a la punta, y la punta hace todo.
De nuevo: esto no quiere decir que esa solución sea mala (o buena) en sí, sino que hay que ver mucho más del problema y del diseño circundante antes de poder opinar de manera útil.

> Como lo modelarían ustedes ?

Primero tendría que ver mejor el problema.

>. Que relación hay entre un objetos

> virtual y uno real que estoy modelando (Formón/Brush)?.

El objeto virtual representa al real, tanto como quieras/necesites. Sobre todo, tiene que cumplir en tu modelo virtual las cosas que hace el real en el mundo real. Es decir, "darte la funcionalidad" . Esto, nuevamente, es capcioso porque cualquier objeto de la vida real tiene múltiples facetas y conjuntos de funcionalidad posibles: un formón sirve para esculpir, pero además tiene peso, puede usarse como arma, puede venderse, comprarse, moverse, y millones de cosas más.

> Trato de

> pensar en todas las pautas que aquí se han dicho para poder modelar

> correctamente, pero no me cierra. El desacoplar la forma fuera del

> Brush, me permite tener un modelo más flexible. El tema es que
como

> no logro que esto me quede bien modelado pensé en preguntar

Hol
Un modelo puede ser flexible en muchos sentidos. Y sin embargo, eso puede no ser necesario.
Es importante modelar la flexibilidad que necesitás, no "toda la flexibilidad posible", ni siquiera toda la que te imaginás. Sobre todo, si para ganar flexibilidad aumentás complejidad.
Para mí, es más importante tener un modelo simple y que funcione. Si el modelo es simple y lo entiendo bien, cambiarlo en la dirección que lo mejore es fácil.

Saludos
--
carlos e. ferro* *| senior developer* *| *caesar systems *| *see clearly. decide smarter.*

ceferro@caesarsyste ms.com <mailto:ceferro@ caesarsystems. com> | t: +1.281.598.8790 | t: +54.11.4389. 0126 | www.caesarsystems. com <http://www.caesarsy stems.com/>

**This message and any attached documents contain information from Caesar Systems LLC that may be confidential/ trade secret and/or privileged. If you are not the intended recipient, you may not read, copy, distribute or use this information. If you have received this transmission in error, please notify the sender immediately by telephone or by reply e-mail and then delete this message.

Encontra las mejores recetas con Yahoo! Cocina.
http://ar.mujer.yahoo.com/cocina/

Foto 2 de 2

circulateBrush.JPG

square.JPG

Responder | Reenviar | Mensajes en este tema (9)

#17171

De: kikoGregoris <kikogregoris@...>
Fecha: Lun, 26 de Oct, 2009 2:52 pm
Asunto: Re: [objetos] Pensando en objetos ?

kikogregoris

Sin conexión

Enviar correo

Hola Sebastian

Ok, gracias.
Si es un problema de este tipo, el tema es que poner en otra clase la responsabiliad parece ser una cuestion algoritmica.
Como la forma es un cálculo, parece no tener sustento tener una clase para esto.
Por ahora seguirá así, luego veremos

saludos

--- El jue 15-oct-09, Sebastian Gurin <sgurin@...> escribió:

De: Sebastian Gurin <sgurin@...>
Asunto: Re: [objetos] Pensando en objetos ?
Para: smalltalking@...
Fecha: jueves, 15 de octubre de 2009, 10:00 am

On Tue, 13 Oct 2009 06:34:33 -0700 (PDT)
kikoGregoris <kikogregoris@ yahoo.com. ar> wrote:

> Como lo modelarían ustedes ?.
>
> Que relación hay entre un objetos virtual y uno real que estoy modelando (Formón/Brush) ?.
>
> Trato de pensar en todas las pautas que aquí se han dicho para poder modelar
> correctamente, pero no me cierra.
>
> El desacoplar la forma fuera del Brush, me permite tener un modelo más flexible. El tema es que como no logro que
> esto me quede bien modelado pensé
> en preguntar
>

Hola. Segun lo que te entendí, tu dilema me parece que es el clásico Herencia vs Delegación. ¿A quien le doy la responsabilidad, a una subclase o a otro objeto? IMHO no hay una forma correcta de modelar. Probablemente utilizando herencia el modelo parezca más elegante, pero acordate que estás atado al significado de herencia (herencia simple). Que la clase Brush delegue la responsabilidad de pintar a otro objeto puede ser más flexible y en algunos contextos más eficiente... No creo que exista una forma de modelar "más natural" que otras, creo que el modelo es siempre algo artificial.. . La elección depende del contexto.. un saludo

>
>
>
> saludos
>
>
>
> PD: Debo volver a Delphi ? jajjaja
>
>
>
>
>
>
>
> Yahoo! Cocina
>
> Encontra las mejores recetas con Yahoo! Cocina.
>
>
> http://ar.mujer. yahoo.com/ cocina/

--
Sebastian Gurin <sgurin@montevideo. com.uy>

Encontra las mejores recetas con Yahoo! Cocina.
http://ar.mujer.yahoo.com/cocina/

Responder | Reenviar | Mensajes en este tema (9)

#17170

De: kikoGregoris <kikogregoris@...>
Fecha: Lun, 26 de Oct, 2009 2:47 pm
Asunto: Re: [objetos] Pensando en objetos ?

kikogregoris

Sin conexión

Enviar correo

Hola Ale

Ok, entiendo o creo entender a donde vas.
La implementación funciona, solo me parecía que no era muy apropiada o que no estaba modelada de una forma muy a la objetos.
A menudo me pasa que hago algo que funciona, y luego empiezo a pensar que el modelo implementado no es del todo correcto o que no tiene un estilo OO, por decirlo así.
Esto me causa cierta insatisfacción con lo producido, y pienso si mis conceptos de base, de lo que es o no un objeto son correctos.

No sé si le pasa o les pasó a todos los que trabajan con objetos o si se lo plantean.

Seguramente esto tiene que ver con la experiencia y los años de trabajar con ST.

Saludos kiko

--- El mié 14-oct-09, Alejandro F. Reimondo <aleReimondo@...> escribió:

De: Alejandro F. Reimondo <aleReimondo@...>
Asunto: Re: [objetos] Pensando en objetos ?
Para: smalltalking@...
Fecha: miércoles, 14 de octubre de 2009, 5:51 pm

Hola kiko,

El pensar que un modelo (una descripción) es suficiente para determinar

un objeto es incorrecto.

Los objetos que uno ve/entiende son resultantes del proceso informático,

son resultantes de la actividad que desarrollamos para apropiarnos/ capturar

la forma de "algo real".

Por mas que nos apropiemos de detalles concretos al analizar un

objeto (una instancia), nunca capturamos todo su contenido, esto

motivó grandes estudios en psicología por décadas, en dónde se

intentaba definir características de la imagen que capturabamos

en ese proceso (con los mas variados objetivos).

El tema es que por mas que agendemos detalles de instancias,

siempre producimos, por reducción una idea abstracta de los

objetos observados.

Si tenemos una buena forma de modelar esa idea abstracta no

alcanza para replicar los que pueda hacerse con el objeto real.

Además hay que considerar que bajo distintos puntos de vista

vemos distintas cosas de los objetos que analizamos,

por lo que NO es incorrecto tener modelos diferentes,

pues son productos de diferentes puntos de vista.

El "sumar" dos modelos, integrandolos en un tercer modelo

no simplifica las cosas, porque como toda formalización no

tiene compromiso con las fuentes.

En resumen, si ves tu formón (sea virtual o real) de una forma,

hace un modelo para entenderlo mejor (al formon, ... no al modelo).

Si no te sirve el modelo, tratá de observar el formon de otra manera.

Si no aparece otra manera, date tiempo (busca otros ejemplos de

uso u otras instancias) o busca otra persona.

Si encotrás otros modelos probalos ... y luego trata de entenderlos.

Si tu formón no anda y no se te ocurre otra forma.. poné

un "objeto en medio" (mas tarde si tenes la oportunidad de

aclarar la situación, podrás sacarlo o hacerlo mas evidente

según convenga a tus propositos).

usa tus modelos como a los huesos un perro,

Ale.

----- Original Message -----

From: kikoGregoris

To: smalltalking@ gruposyahoo. com.ar

Sent: Tuesday, October 13, 2009 10:34 AM

Subject: [objetos] Pensando en objetos ?

Hola gente

Tengo un problema para modelar un objetos que llamo Brush, el cual se encarga de modelar un terreno. Como si fuera un formón de un carpintero.
Este Brush puede ser de dos formas( por el momento), circular o cuadrado, pero podría ser de infinitas formas.
En un modelado rápido puse:
Brush
    SquaredBrush
     CircleBrush.
Yo creo que esta muy mal y que Brush solo debería conocer de que forma es y actuar en consecuencia. El tema es que no puedo lograr que funcione de esta forma y por eso entre a dudar.
Si pienso en el ejemplo del formón, en la realidad este es de una forma u otra, no tiene una punta intercambiable. Lo cual me confunde, porque hace parecer que mi modelo esta bien y que Formón/Brush tiene subclases
Pero aquí los objetos son virtuales.jajaj

Como lo modelarían ustedes ?.
Que relación hay entre un objetos virtual y uno real que estoy modelando (Formón/Brush) ?.
Trato de pensar en todas las pautas que aquí se han dicho para poder modelar correctamente, pero no me cierra.
El desacoplar la forma fuera del Brush, me permite tener un modelo más flexible. El tema es que como no logro que esto me quede bien modelado   pensé en preguntar

saludos

PD: Debo volver a Delphi ? jajjaja

Encontra las mejores recetas con Yahoo! Cocina.
http://ar.mujer. yahoo.com/ cocina/

Encontra las mejores recetas con Yahoo! Cocina.
http://ar.mujer.yahoo.com/cocina/

Responder | Reenviar | Mensajes en este tema (9)

#17169

De: kikoGregoris <kikogregoris@...>
Fecha: Lun, 26 de Oct, 2009 1:44 pm
Asunto: Bitmap alphaChannel (Dolphin X6) ?

kikogregoris

Sin conexión

Enviar correo

Hola gente

Tengo que obtener el valor del canal alpha de un bitmap en grayscale, y no veo forma de hacer esto en Dolphin.

Miro la clase Bitmap , Image y GdiPlusImage.
Traté de hacer algo como esto:

GdiplusBitmap fromBitmap: ( Bitmap fromFile: 'C:\Documents and Settings\Gregoris\Mis documentos\Dolphin Smalltalk X6\TerrainEditor\assets\Textures\test.bmp')

Luego miro el canal alpha así:
1 to: 255 do:[: x | 1 to: 255 do:[:i | (self pixelAt: x@i ) alpha < 255 ifTrue:[^x@i]]].

Para ver si hay algo, pero todos los alpha son 255.

Incluso en el ejemplo:

GdiplusGraphics>>exampleGdipGAlphaBlending
    "Using GDI+ .... Alpha Blending Lines and Fills ... Using Compositing Mode to Control Alpha Blending

        self exampleGdipGAlphaBlending showExample
    "

    "Create a blank bitmap."

    | bitmap graphics redBrush greenBrush bitmap2 graphics2 |
    bitmap := GdiplusBitmap width: 180 height: 100.
    "Create a Graphics object that we can use to draw on the bitmap."
    graphics := bitmap graphics.
    "Create a red brush and a green brush, each with an alpha value of 160."
    redBrush := GdiplusSolidBrush color: (ARGB fromArray: #(210 255 0 0)).
    greenBrush := GdiplusSolidBrush color: (ARGB fromArray: #(210 0 255 0)).
    "Set the compositing mode so that when we draw overlapping ellipses,
    the colors of the ellipses are not blended."
    graphics compositingMode: CompositingModeSourceCopy.
    "Fill an ellipse using a red brush that has an alpha value of 160."
    graphics fillEllipse: (0 @ 0 extent: 150 @ 70) brush: redBrush.
    "Fill a second ellipse using green brush that has an alpha value of 160.
    The green ellipse overlaps the red ellipse, but the green is not blended with the red."
    graphics fillEllipse: (30 @ 30 extent: 150 @ 70) brush: greenBrush.
    "Prepare to draw on the screen."
    bitmap2 := GdiplusBitmap extent: 400 @ 200.
    graphics2 := bitmap2 graphics clear: ARGB white.
    graphics2 compositingQuality: CompositingQualityGammaCorrected.
    "Draw a multicolored background."
    graphics2 fillRectangle: (200 @ 0 extent: 60 @ 100)
        brush: (GdiplusSolidBrush color: (ARGB stdColor: #aqua)).
    graphics2 fillRectangle: (260 @ 0 extent: 60 @ 100)
        brush: (GdiplusSolidBrush color: (ARGB stdColor: #yellow)).
    graphics2 fillRectangle: (320 @ 0 extent: 60 @ 100)
        brush: (GdiplusSolidBrush color: (ARGB stdColor: #fuchsia)).
    "Display the bitmap on a white background."
    graphics2 drawImage: bitmap at: 0 @ 0.
    "Display the bitmap on a multicolored background."
    graphics2 drawImage: bitmap at: 200 @ 0.
    ^bitmap2

Todos los alpha de la imagen son 255 !!.

Algo me estoy perdiendo y no veo que es.
Alguna idea de como hacer esto ?

saludos kiko

Encontra las mejores recetas con Yahoo! Cocina.
http://ar.mujer.yahoo.com/cocina/

Responder | Reenviar | Mensajes en este tema (3)

#17168

De: "gplancic" <gruposplancic@...>
Fecha: Sáb, 24 de Oct, 2009 3:13 pm
Asunto: Aporto un link para quien recién comienza, como yo

gplancic

Sin conexión

Enviar correo

Buenas tardes,
Mis disculpas si posteo algo demasiado básico para los mensajes que veo en el
grupo por estos días, pero este link que pego aquí me ayudó mucho para mostrar
información en listas multicolumna:

http://www.mindspring.com/~lsumberg/Dolphin/PersonalMoney/index.htm

El autor Louis Sumberg retoma aquí el tutorial "Personal Money" y le incorpora
ésta y otras mejoras.

A mí me gustaría agregar en la sección de "Enlaces" del foro una carpeta con
direcciones para orientar a principiantes, y así evitar, como yo, realizar
preguntas innecesarias. Pero lo dejo a criterio de ustedes.

Saludos
Gerardo

Responder | Reenviar | Mensajes en este tema (1)

#17167

De: "Bruno Buzzi Brassesco" <smalltalk@...>
Fecha: Jue, 22 de Oct, 2009 9:44 pm
Asunto: RE: ***SPAM*** Re: [objetos] Modelo de produccion

brunobrasesco

Sin conexión

Enviar correo

Me gustaría oir ejemplos de entidades que en smalltalk no son objetos...

******************************************************************

Se refiere a emergentes que puedan surgir con el trabajo con objetos.

Los sistemas emergentes también se conocen como auto-organización.

Por ejemplo si quiero modelar un hormiguero con Smalltalk no se “programaría” el comportamiento del hormiguero.

El hormiguero es un emergente, que emerge de la interacción de N cantidad de individuos, y que en su interacción generan un emergente.

Cada individuo simplemente cumple un numero sencillo de reglas, luego pones N individuos a interactuar y se observar el emergente.

Hormiga:

· Sale a caminar al azar

· Si encuentra comida expulsa feromona y vuelve al hormiguero.

· Si encuentra rastro de feromona sigue feromona.

Con estas reglas si pones N hormigas a interactuar se puede observar el emergente que es un hormiguero.

Es decir, las hormigas van:

· A encontrar la comida que esta más cerca más rápido

· Van a formar “autopistas de hormigas” (como los hormigueros)

Y esto no esta programado, resulta de los N individuos interactuando. Si cambias alguna regla o la cantidad de individuos, quizás se observe otro emergente.

SISTEMAS EMERGENTES

JOHNSON, STEVEN

http://www.santafebooks.com/templates/EN/74/SISTEMAS-EMERGENTES-O-que-tieNeN-eN-comuN-hormigas-NeuroNas/

Tortugas, termitas y atascos de tráfico

Mitchel Resnick

http://www.agapea.com/libros/Tortugas-termitas-y-atascos-de-trafico-isbn-8474328349-i.htm

Saludos,

Bruno

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.409 / Virus Database: 270.14.20/2444 - Release Date: 10/18/09 09:04:00

Responder | Reenviar | Mensajes en este tema (42)

#17166

De: Sebastian Gurin <sgurin@...>
Fecha: Mié, 21 de Oct, 2009 7:48 pm
Asunto: Re: ***SPAM*** Re: [objetos] Modelo de produccion

cancerbero_sgx

Sin conexión

Enviar correo

On Mon, 19 Oct 2009 09:53:47 -0300
"Carlos E. Ferro" <ceferro@...> wrote:

alejandro decía:

> > 2.- sobre que "todo en smalltalk es un
> > objeto", te lo creiste solo al comienzo no? Sabes que no es asi...
> > no? (si aun crees que en smalltalk todo es un objeto, no dejes de ir
> > a una de nuestras presentaciones de ambientes de objetos :-) lo digo
> > en serio... te estas perdiendo de "algo importante" si pensas que esa
> > muletilla introductoria es correcta.
>

Me gustaría oir ejemplos de entidades que en smalltalk no son objetos...

carlos decía:

> Esto es otra cosa fundamental y que sólo encontré en Smalltalk.
> Para un programador COBOL, "desarrollarse" como programador era poder escribir
más rápido y pensar menos... Adquirir mejores templates de programas y el mejor
editor de textos.
> Para el programador Java, desarrollarse ¿es tener la mejor biblioteca de
frameworks y funcionalidades?
>

pregunta interesante, sobretodo para un programador (mucha parte del tiempo) en
java. Es obvio que la tecnología escogida modela nuestra forma de producción.
Una tecnología basada o que alienta un modelo modular va a hacer que la
respuesta a la pregunta de carlos sea Si. (De hecho, basta mirar las ofertas
laborales en java: "se valora experiencia en los frameworks X, Y y conocimiento
de los estándares A, B")

Ahora, bien yo creo que aunque la tecnología nos empuje hacia un lado, también
nos empujan el tipo de proyecto y nuestras propias decisiones. Por ejemplo,
estoy seguro que hay programadores smalltalk con más tendencia a utilizar
módulos que algunos programadores java. O sea la creatividad, las ganas de
aprender, las ganas de enriquecerse resolviendo un problema, van a ser distintas
segun la tecnología que utilicemos, pero también según las ganas ( o los
objetivos) de cada uno.

Lamentablemente concuerdo, muchos colegas javaleros encuentran mucho más
gratificante ver el problema resuelto por unos frameworks que ellos se
encargaron de anudar, que resolver por ellos mismos el problema. Bueno no se si
"lamentablemente"; sigo sosteniendo que hay diferentes clases de
programadores...

Esto lo dijo alejandro:

> > Si uno
> > busca desarrollar capacidades (el producto son los modelos del grupo
> > de trabajo) el exito es mas dificil de medir y se requiere a menudo
> > de varios proyectos (en estos casos son valiosos algunos conceptos
> > que nombró Carlos cuando uno se encuenra dentro de un dominio
> > estricto/estructurado/adulto )

Pregunta de novato, relacionada con lo anterior ,¿cuando hablamos de
programadores, hablamos de alguien que busca desarrollar capacidades? ¿
"desarrollar capacidades" es "programar" ?  ¿ desarrollar es desarrollarnos ?
Por ejemplo, me viene a la cabeza un peón de construcción que pasa por el
edificio terminado: el tipo siente gratificación por el edificio, en gral él no
se dearrolló, se desarrolló la construcción. Lo mismo la gratificación de un
jardinero veterano al sentarse a oler el cesped recién cortado: lo gratificante
es el acto de contemplar la "obra"... No se si se entiende el punto...

>
> Acá ya entramos en el dominio del desarrollo de software y de la ingeniería de
conocimiento.
>
> > En los casos poco frecuentes donde a
> > uno le toca gravitar por diferentes contextos (distintas áreas
> > sociales y productivas) se requiere de un poco más, y allí es muy
> > util el entender y usar un AO; y en esos casos, creo que uno puede
> > percibir de forma mas peculiar que utilidad tiene un ambiente.
>
> Acá se me acabaron las analogías :-)) Esto es único de los ambientes de
objetos, creo.
>

me parece una buena (otra) definición o punto de vista que separa a los
ambientes de objetos de las tecnologías corrientes.

> Saludos
> --
>
> carlos e. ferro* *| senior developer* *|  *caesar systems *| *see clearly.
decide smarter.*
>
> ceferro@... <mailto:ceferro@...> | t:
+1.281.598.8790 | t: +54.11.4389.0126 | www.caesarsystems.com
<http://www.caesarsystems.com/>
>
> **This message and any attached documents contain information from Caesar
Systems LLC that may be confidential/trade secret and/or privileged. If you are
not the intended recipient, you may not read, copy, distribute or use this
information. If you have received this transmission in error, please notify the
sender immediately by telephone or by reply e-mail and then delete this message.
>
>
>

--
Sebastian Gurin <sgurin@...>

Responder | Reenviar | Mensajes en este tema (42)

#17165

De: "Carlos E. Ferro" <ceferro@...>
Fecha: Lun, 19 de Oct, 2009 12:53 pm
Asunto: Re: [objetos] Modelo de produccion

carloseferrob

Sin conexión

Enviar correo

Alejandro F. Reimondo wrote (el 5/10):

>> Yo no dije que evitaba construir ruedas, aunque no niego que es muy
>> fácil acostumbrarse...
>
> Encender una luz es proyectar una sombra... Tomarle el gustito a no
> hacer uno, lleva frecuentemente a no querer hacerlo.

Sí, es como la gente que quiere empezar a hacer ejercicio, por su salud.
Rápidamente encuentran que estaban mucho más ocupados de lo que creían y que no tienen tiempo para eso...

> Son como dos
> fuerzas que se contraponen, a tal punto que si uno no ejercita una de
> las opciones la otra se levanta como algo absoluto, y al encontrar a
> alguien que no hace lo mismo nos sorprende, resulta "extraño".

Bueno, siempre me resultó extraño que a la gente no le guste programar.
Nunca comprendí la ansiedad de los programadores por ser project managers para "dejar de programar", como si fuera un castigo, una degradación y una ocupación menor... Pero esa es otra discusión.

> En los casos en que se "inventa un framework" (cuando se lo diseña
> para ser flexible) la solucion es ideal, es única, debe estudiarse e
> invertir esfuerzo en su uso correcto;

Hmmm... Y osoy muy escéptico con respecto a la posibilidad de "inventar" un framework. Me parece que es como querer inventar una antigua leyenda, o un refrán...

> cuando un framework resulta de
> la aplicacion reiterada, es obvio (y a veces pasa desapercibido) y se
> entiende de a poquito mientras uno se acerca al dominio.

A esto iba. Para mí los frameworks se descubren, no se inventan. "Cuajan" de la decantación y fermentación de experiencia en un dominio. Tratar de forzar ese proceso, creo que conduce a cosas que se llaman frameworks por cuestión de marketing, pero no lo son.

> En ambos casos, si uno es un productor de software, la implementación
> no esta del lado de los costos, sino que es lo que uno hace para
> entender. Fuera de smalltalk, es prohibitivo el usar el propio
> trabajo (software) para entender y se considera distinto el aporte de
> un framework externo. ...Pero aqui nos ocupa lo que ocurre trabajando
> con Smalltalk (ojo! no mezclemos.. otra cosa es si uno trabaja con
> un ide+loo).

Totalmente. Si tuviera que usar un LOO, probablemente me esforzaría por encontrar y aprender frameworks, por buscar "fuentes confiables". Pero también, modelaría en ST y después trataría de traducirlo :-)

>> porque lamentablemente me acostumbré a MI triste verdad: cuanto más
>> código más dificil y vulnerable el software.
>
> Usando smalltalk se pueden lograr ciclos de expansión y compresión
> del sistema... que rompe esta limitante. En teoría "lo mismo" podría
> hacerse con cualquier herramienta, en la práctica, no se logra.

Esto es muy importante y muy divertido.
Por algo toda la "movida" de desarrollo ágil y herramientas relacionadas surgió de los smalltalkers.

>> Yo tengo mis acercamientos con smalltalk, que es lo unico que
>> conozco con esas características ("todo" esUn: Objeto), casi por
>> casualidad. Lo primero que me llamó la atención fue ver qué tan
>> elegante por simple y qué tan rico se puede llegar a ser con algo
>> tan simple.
>
> (perdon por interrupir aquí :) 1.- lo simple/abstracto es siempre
> pobre, no rico. -requiere de mucho para instanciarse en algo útil.
> -fascina por poder aplicarse de forma amplia. -esta en el plano de
> las ideas (promueve ideales).

Pero es más fácil de transmitir, útil para un aprendizaje inicial y para un "almacenamiento económico" del conocimiento... Tal vez por formación, también siempre me tira lo abstracto, lo elegante y lo simple.
Aunque en el trabajo diario, eso tiene que alternarse y matizarse con muchas otras cosas.

> 2.- sobre que "todo en smalltalk es un
> objeto", te lo creiste solo al comienzo no? Sabes que no es asi...
> no? (si aun crees que en smalltalk todo es un objeto, no dejes de ir
> a una de nuestras presentaciones de ambientes de objetos :-) lo digo
> en serio... te estas perdiendo de "algo importante" si pensas que esa
> muletilla introductoria es correcta.

Si todo es un objeto, ¡los programadores también lo somos!

>> Me costó entender porqué los conceptos de aplicación y librería no
>> tienen sentido. Ni en mi facultad ni en otras que conozco se
>> enseñan ( o al menos se acercan ) tecnologías que no sean del tipo
>> modular-compilable-etc, salvo quizá por lisp, que también tiene un
>> algo de todo es una función....
>
> oops! no me malentiendas! yo digo que SI tienen sentido! que deben
> enseñarse, y que tambien deben enseñarse que es lo que producen en
> las personas y los limites de su aplicación.

Tampoco creo que fuera bueno que los programadores aprendan sólo objetos, como único paradigma/tecnología. Creo que sería tremendamente empobrecedor.

>>> En lo modular, solo se plantea una visión estática de un sistema
>>> y el objetivo es hacer programas que procesan datos. Y si... el
>>> hacer programas dejo sin pelos a varios. :-P
>> no se por qué, en cierto sentido me suena a que esto pueda deberse
>> a que no hemos podido aún abstraer del todo a la máquina... Yo creo
>> que la tecnología lo marca y mucho a uno en cuanto a lo que valora
>> a la hora de hacer eso que llamamos desarrollar.
>
> Desarrollar es desarrollarNOS , las personas, no el software. Es tan
> así como qeu la información no es una cosa (un objeto). Usamos
> software para desarrollar experiencia en un dominio, realizar lo que
> llamamos ciclos de experiencia [ver nuestras persentaciones sobre las
> bases de la TO... mejor aun asistir a alguna charla sobre esto].

Esto es otra cosa fundamental y que sólo encontré en Smalltalk.
Para un programador COBOL, "desarrollarse" como programador era poder escribir más rápido y pensar menos... Adquirir mejores templates de programas y el mejor editor de textos.
Para el programador Java, desarrollarse ¿es tener la mejor biblioteca de frameworks y funcionalidades?

> Los frameworks (y otros elementos abstractos) funcionan como
> gravitadores y los efectos en el equipo son determinantes en casi
> todos los casos [no lo digo con animo de protesta, sino como
> reconociendo lo inevitable].

Este es uno de los peligros que marcaba de aceptar la "ideología foránea", al comprometer al equipo con un framework, se deja de pensar en ese problema.... y se empieza a resolver problemas generados por el framework, problemas tecnológicos.

> Si uno busca desarrollar software (el
> producto son los bits) el exito se mide de forma simple (tiempos,
> costos, etc) y en forma a veces inmediata (un proyecto basta).

Ese es el dominio de la ingeniería de software.

> Si uno
> busca desarrollar capacidades (el producto son los modelos del grupo
> de trabajo) el exito es mas dificil de medir y se requiere a menudo
> de varios proyectos (en estos casos son valiosos algunos conceptos
> que nombró Carlos cuando uno se encuenra dentro de un dominio
> estricto/estructurado/adulto )

Acá ya entramos en el dominio del desarrollo de software y de la ingeniería de conocimiento.

> En los casos poco frecuentes donde a
> uno le toca gravitar por diferentes contextos (distintas áreas
> sociales y productivas) se requiere de un poco más, y allí es muy
> util el entender y usar un AO; y en esos casos, creo que uno puede
> percibir de forma mas peculiar que utilidad tiene un ambiente.

Acá se me acabaron las analogías :-)) Esto es único de los ambientes de objetos, creo.

Saludos
--

carlos e. ferro* *| senior developer* *| *caesar systems *| *see clearly. decide smarter.*

ceferro@... <mailto:ceferro@...> | t: +1.281.598.8790 | t: +54.11.4389.0126 | www.caesarsystems.com <http://www.caesarsystems.com/>

**This message and any attached documents contain information from Caesar Systems LLC that may be confidential/trade secret and/or privileged. If you are not the intended recipient, you may not read, copy, distribute or use this information. If you have received this transmission in error, please notify the sender immediately by telephone or by reply e-mail and then delete this message.

Responder | Reenviar | Mensajes en este tema (42)

#17164

De: kikoGregoris <kikogregoris@...>
Fecha: Lun, 19 de Oct, 2009 1:10 am
Asunto: Re: [objetos] Arrancamos, se larga la ronda de clasificación

kikogregoris

Sin conexión

Enviar correo

Feliz día de la familia.

Ale.

Igualmente para todos

--- El dom 18-oct-09, Alejandro F. Reimondo <aleReimondo@...> escribió:

De: Alejandro F. Reimondo <aleReimondo@...>
Asunto: Re: [objetos] Arrancamos, se larga la ronda de clasificación
Para: smalltalking@...
Fecha: domingo, 18 de octubre de 2009, 5:20 pm

Feliz día de la familia.

Ale.

----- Original Message -----

From: Carlos E. Ferro

To: smalltalking@ gruposyahoo. com.ar

Sent: Sunday, October 18, 2009 11:32 AM

Subject: [objetos] Arrancamos, se larga la ronda de clasificación

El día de la madre no es el mejor para hacer este anuncio, pero aunque quise terminar ayer, no pude.

Declaro oficialmente iniciada la ronda de clasificación/ eliminatoria del concurso de programación de Smalltalks 2009.

Ya subí en la sección de archivos del grupo (http://groups. google.com. ar/group/ smalltalks- 2009-coding- contest) el smalltalks2009ccQua 2WindowsExe. rar y el smalltalks2009ccQua 2Image.rar, que son el ejecutable y una imagen VW cerrada (para los que no usan Windows) del servidor. Contra este servidor deberán jugar.

No hubo cambios en los comandos, así que las herramientas siguen sirviendo. El jugador de ejemplo también. Hubo ajustes diversos y hay varios mundos nuevos. Ahora encontrarán, además de los aleatorios, personajes con distintos temperamentos e inclinaciones.

El jugador provisto con la estrategia de sólo trabajar hace entre 25 y 40 mil puntos, así que en principio, voy a poner un límite de 64 mil puntos para considerar que pasan la eliminatoria. Tendrán tiempo hasta el domingo antes de la conferencia (inclusive) para mandar los certificados a la cuenta codingContest2009@ fast.org. ar.
El certificado es un archivo codificado con extensión .cc que genera el servidor cuando terminan de correr todos los mundos.

Bueno, ya falta menos de un mes, así que manos a la obra. Buena suerte y diviértanse.

--

carlos e. ferro | senior developer | caesar systems | see clearly. decide smarter.

ceferro@caesarsyste ms.com | t: +1.281.598.8790 | t: +54.11.4389. 0126 | www.caesarsystems. com

This message and any attached documents contain information from Caesar Systems LLC that may be confidential/ trade secret and/or privileged. If you are not the intended recipient, you may not read, copy, distribute or use this information. If you have received this transmission in error, please notify the sender immediately by telephone or by reply e-mail and then delete this message.

Encontra las mejores recetas con Yahoo! Cocina.
http://ar.mujer.yahoo.com/cocina/

Responder | Reenviar | Mensajes en este tema (2)

#17163

De: "Alejandro F. Reimondo" <aleReimondo@...>
Fecha: Dom, 18 de Oct, 2009 7:20 pm
Asunto: Re: [objetos] Arrancamos, se larga la ronda de clasificación

alereimondo

Sin conexión

Enviar correo

Feliz día de la familia.

Ale.

----- Original Message -----

From: Carlos E. Ferro

To: smalltalking@...

Sent: Sunday, October 18, 2009 11:32 AM

Subject: [objetos] Arrancamos, se larga la ronda de clasificación

El día de la madre no es el mejor para hacer este anuncio, pero aunque quise terminar ayer, no pude.

Declaro oficialmente iniciada la ronda de clasificación/eliminatoria del concurso de programación de Smalltalks 2009.

Ya subí en la sección de archivos del grupo (http://groups.google.com.ar/group/smalltalks-2009-coding-contest) el smalltalks2009ccQua2WindowsExe.rar y el smalltalks2009ccQua2Image.rar, que son el ejecutable y una imagen VW cerrada (para los que no usan Windows) del servidor. Contra este servidor deberán jugar.

No hubo cambios en los comandos, así que las herramientas siguen sirviendo. El jugador de ejemplo también. Hubo ajustes diversos y hay varios mundos nuevos. Ahora encontrarán, además de los aleatorios, personajes con distintos temperamentos e inclinaciones.

El jugador provisto con la estrategia de sólo trabajar hace entre 25 y 40 mil puntos, así que en principio, voy a poner un límite de 64 mil puntos para considerar que pasan la eliminatoria. Tendrán tiempo hasta el domingo antes de la conferencia (inclusive) para mandar los certificados a la cuenta codingContest2009@....
El certificado es un archivo codificado con extensión .cc que genera el servidor cuando terminan de correr todos los mundos.

Bueno, ya falta menos de un mes, así que manos a la obra. Buena suerte y diviértanse.

--

carlos e. ferro | senior developer | caesar systems | see clearly. decide smarter.

ceferro@... | t: +1.281.598.8790 | t: +54.11.4389.0126 | www.caesarsystems.com

This message and any attached documents contain information from Caesar Systems LLC that may be confidential/trade secret and/or privileged. If you are not the intended recipient, you may not read, copy, distribute or use this information. If you have received this transmission in error, please notify the sender immediately by telephone or by reply e-mail and then delete this message.

Responder | Reenviar | Mensajes en este tema (2)

#17162

De: "Carlos E. Ferro" <ceferro@...>
Fecha: Dom, 18 de Oct, 2009 2:32 pm
Asunto: Arrancamos, se larga la ronda de clasificación

carloseferrob

Sin conexión

Enviar correo

El día de la madre no es el mejor para hacer este anuncio, pero aunque quise terminar ayer, no pude.

Declaro oficialmente iniciada la ronda de clasificación/eliminatoria del concurso de programación de Smalltalks 2009.

Ya subí en la sección de archivos del grupo (http://groups.google.com.ar/group/smalltalks-2009-coding-contest) el smalltalks2009ccQua2WindowsExe.rar y el smalltalks2009ccQua2Image.rar, que son el ejecutable y una imagen VW cerrada (para los que no usan Windows) del servidor. Contra este servidor deberán jugar.

No hubo cambios en los comandos, así que las herramientas siguen sirviendo. El jugador de ejemplo también. Hubo ajustes diversos y hay varios mundos nuevos. Ahora encontrarán, además de los aleatorios, personajes con distintos temperamentos e inclinaciones.

El jugador provisto con la estrategia de sólo trabajar hace entre 25 y 40 mil puntos, así que en principio, voy a poner un límite de 64 mil puntos para considerar que pasan la eliminatoria. Tendrán tiempo hasta el domingo antes de la conferencia (inclusive) para mandar los certificados a la cuenta codingContest2009@....
El certificado es un archivo codificado con extensión .cc que genera el servidor cuando terminan de correr todos los mundos.

Bueno, ya falta menos de un mes, así que manos a la obra. Buena suerte y diviértanse.

--
signature

carlos e. ferro | senior developer | caesar systems | see clearly. decide smarter.

ceferro@... | t: +1.281.598.8790 | t: +54.11.4389.0126 | www.caesarsystems.com

Responder | Reenviar | Mensajes en este tema (42)

#17161

De: "Carlos E. Ferro" <ceferro@...>
Fecha: Vie, 16 de Oct, 2009 7:34 pm
Asunto: Re: Modelo de produccion

carloseferrob

Sin conexión

Enviar correo

Sebastian Gurin wrote (el 5/10, sigo atrasado):

> A mi me parece que la idea va por conocer las ventajas y desventajas
> de ambas "metodologías", uso de modulos y construir/resolver desde
> cero. Creo que ambas cosas nos dan y nos quitan en ciertos aspectos.
> Creo que está bueno meditar e investigar, para cada caso, según la
> necesidad, qué nos beneficia más en todos los aspectos
> (productividad, enriquecimiento personal, eficiencia, flexibilidad,
> etc)

Seguro. Pero inclusive más: no lo plantearía a nivel de ventajas y desventajas de cada metodología o tecnología. Porque si no, parecería que una vez que me convenzo que es mejor usar cajas (o lo contrario), ya está. Ya lo estudié, ya decidí. Lo quiero plantear para cada vez que tenemos que decidir.
Es decir, cada vez que me siento tentado a incorporar algo hecho por otra gente sin mirarlo (reescribirlo) mucho, quiero tomar el tiempo de hacer este análisis.

> Se hace evidente también que la tecnología nos modela en nuestras
> metodologías.

Sí. La tecnología también modela el tipo de problema que vas a encarar. Un poco de eso decía Alejandro en un email, cuando planteaba la forma de trabajar en un sistema "sin problemas". Creo que eso sería imposible en Java, donde si alguien no definió un framework o standard, es muy poco lo que podés avanzar.

> por ej, tecnologías como java,c++,etc insentivan el uso
> de la modularización (paquetes, librerías, archivos, aplicaciones),

Casi que te obligan... El mismo ambiente ya viene como una bola de módulos, tenés que apuntar a una aplicación, tenés que usar files...

> mientras que en una tecnología como smalltalk uno no necesita estos
> conceptos, o si existen son transparentes.

Si existen es porque alguien los modeló (y vos lo estás usando, porque lo que no usás... no existe).

> p/d : sobre lo de "lista teorica", debería haber dicho "lista no
> técnica". Me refería mas bien a que veo muy pocas preguntas técnicas
> (ej: "¿como capturo un evento de ratón en morphic?").

Tuvimos épocas así... lo que pasa es que en Smalltalk la respuesta siempre es casi la misma (fijate cómo lo hace tu Smalltalk), supongo que en algún momento todos los integrantes de la lista la leyeron y vuelve a aparecer cuando se inscribe uno nuevo...

> Veo más
> diálogos sobre intercambnio de experiencias y sobre cuestiones
> teoricas de objetos, a eso iba con "teorica"

Si son intercambios de experiencia, no es teórica... Eso también lo apunté en algún otro email.
La teoría se puede leer en muchos libros. Lo interesante de tener una lista y hablar con gente, es otra cosa. Tal vez, después de mucho tiempo, una lista llega a esa conclusión como organismo colectivo :-) y adopta ese comportamiento emergente.

Saludos
--

carlos e. ferro* *| senior developer* *| *caesar systems *| *see clearly. decide smarter.*

ceferro@... <mailto:ceferro@...> | t: +1.281.598.8790 | t: +54.11.4389.0126 | www.caesarsystems.com <http://www.caesarsystems.com/>

**This message and any attached documents contain information from Caesar Systems LLC that may be confidential/trade secret and/or privileged. If you are not the intended recipient, you may not read, copy, distribute or use this information. If you have received this transmission in error, please notify the sender immediately by telephone or by reply e-mail and then delete this message.

Responder | Reenviar | Mensajes en este tema (42)

#17160

De: "Alejandro F. Reimondo" <aleReimondo@...>
Fecha: Jue, 15 de Oct, 2009 11:42 pm
Asunto: Re: [objetos] Re: Modelo de produccion

alereimondo

Sin conexión

Enviar correo

Hola,

Sebastián decia...
>>Probablemente me
>> ahorre tiempo globalmente, pero gastar el tiempo en algo no
>> relacionado al problema es feo.

Carlos luego decía...
>Me recuerda algo que siempre dice Paenza, un divulgador científico,
> en su programa de televisión y sus libros. El cierra cada programa
> proponiendo un problemita matemático, y siempre repite que lo
> interesante NO es la solución, porque la semana siguiente él te
> da una solución. Lo interesante es pensar el problema, vivir con
> el problema y ejercitar la cabeza, pensar alternativas... Es lindo
> tener problemas; la satisfacción de resolverlos dura un segundo
> pero el disfrute del proceso de resolución es mucho más largo.

Esa en la forma mas acostumbrada de pensar y actuar,
  en el caso de los científicos (la palabra que se me vino
  a la mente fue "matemáticos", pero me contuve y...).
Eso me quedó gravado desde cuatro año en la secundaria
  y luego se reforzó más aún al ser alumno de Paenza en
  Análisis Matemático (cosa que no podía evitar en mi
  recorrido por la carrera de ciencias Químicas).

La actitud de buscar un problema para ser resuelto
  parece noble y parece hacer un gran aporte quien la promueve
  (a veces a quienes no tienen un sustento de conocimiento
  suficientemente maduro como para ver sus concecuencias);
  pero desde entonces siempre me pregunté porqué casi nadie
  veía que concecuencias tiene.

Otra forma de decir lo mismo sería por medio de una
  pregunta simple y directa:
     "Puede no plantearse un problema ?"

Sabemos los efectos de modelar/aplicar la solución a un problema.
Podemos pensar en producir (software) sin atacar un problema?

Muchas veces vemos (ejemplos sobran en programas
  donde se promueven los abordajes cientificos) que el planteo
  del problema requiere de un maestro, requiere del experto
  que nos lo plantea... nos subyuga a sus objetivos.

En el abordaje de sistemas espesificos o ineditos (soluciones
  primeras/unicas) ocurre que no existe el maestro, ni la guía,
  y dibujar/definir un problema es sumar un problema.
En esos casos el avance es "mirando hacia atras", es mirandose
  lo que nos queda en las manos luego de trabajar sobre algo
  que no necesariamente entendíamos al empezar.
En esos casos no sabemos si nos perdemos de soluciones mejores,
  y ocurre como decía Carlos que uno no puede equivocarse,
  simplemente no puede ocurrir que no nos salga lo que queremos...
Pues lo que se ve (el producido), se ve cuando ya salió; cuando está ahí.
Ese producto es para ser observado y retroalimentar el proceso
  de avance, de tallado del sistema.
A veces (como obra tallada) ocurre que otros lo alaban
  antes que nosotros nos dimos cuenta que "lo hicimos".

Este proceso en ciclos es radicalmente diferente al proceso
  guiado por un tutor en base al planteo de problemas;
  pues no esta viciado por la voluntad subyugante del superior;
  del que dicta además "el standard", la forma correcta... la forma única,
  la forma limpia que permite la definición del problema!
  (aquel que esconde en la definición del problema lo que
  quiere que descubramos, y reduce en su definición limpia
  toda posibilida de de escapar con decoro a esa solución
  que parece única/pura una vez que caímos en ella)

Si piensan que uno no puede evitar el plantear(se) problemas...
Piensan que es la única forma de avance?
O puede ser complementada con otras formas de "desarrollo"?

Que valor tiene un ambiente de objetos virtuales para:
- el escenario de "todo esUn: Problema" ?
     (esta condenado a ser una caja de herramientas?)
- el uso de ciclos de experiencia ?
     (que tiene que ya no esté ahí? [*] )

>Hmmm... Es el típico ejemplo de decisión que no se puede
> tomar a la ligera. En Smalltalk, para la GUI, CADA DIALECTO
> inventó una forma distinta de representar y trabajar con los
> widgets, y es la peor pesadilla a la hora de migrar código de
> un ST a otro. Al punto que casi nadie lo intenta, se migra
> ligeramente el código "de modelo" y la GUI se programa de
> nuevo, porque es más fácil que migrarla.

Eso depende de cuan profesional sea el diseño de la GUI.
Hay algunos smalltalks en los que:
- la GUI es experimental y no llego nunca a ser madura.
- la GUI esta construida de una forma tan gótica que de
    esa forma se asegura elproveedor que nadie podrá
    sacar nada de valor de ahi adentro :-)

En DNG tenemos soporte para evitar pagar esos costos
  que muchas veces hacen imposible mover aplicaciones
  de un smalltalk a otro, esto no lo digo con intensión de
  dar mas detalles al respecto, sino para sugerir que
  hay formas de avanzar sin complicar.

Y que cuando vemos complicaciones en Smalltalks de hoy,
  analicemos quién ha sacado provecho de estas complicaciones
  (asi quizás podamos entender porque siguen luego de años
  algunas cosas mas complicadas de lo necesario en Smalltalk).

hasta pronto,
Ale.

[*] ¿como es posible que yo, que existo
no haya sido antes de existir y que alguna vez yo,
que existo ya no seré quien soy?
Tomado de la pelicula "Der Himmel Über Berlin" (El cielo sobre Berlín)
Wim Wenders (1987)

Responder | Reenviar | Mensajes en este tema (42)

#17159

De: Elvio Fernandez <elvio.fernandez@...>
Fecha: Jue, 15 de Oct, 2009 7:13 pm
Asunto: Re: [objetos] Re: Modelo de produccion

elvisman_780

Sin conexión

Enviar correo

Hola muchachos,

Esta muy piola la charla.

Carlos decia:

"Creo que el problema es que al aceptar el framework, aceptaste la visión de otros, el modelo de otros. Y lo que es peor, al ponerlo en tu software, te comprometiste con ese modelo y lo estás apoyando. Esto suena (deliberadamente) muy ideológico, pero quiero decir que estás renunciando parcialmente a tu libertad de opinión, para encogerte de hombros y decir "ese tipo debe tener razón... yo le hago caso". Y eso, lo sabemos todos, casi siempre es peligroso. "

Casi totalmente de acuerdo! :-)

Apoyar un framework no tiene nada de malo. Pero, al comprometerte con él no solamente es una "renuncia parcial a la libertad de opinión", sino también a nuestra libertad de acción!

Ale decia:

"Decia que me resulta extraño porque siempre he encontrado que

la experiencia de construir algo propio es de un ariqueza que excede por mucho lo que uno intentó obtener de él o ahorrar al no

hacerlo."

Si claro, pero a estas alturas empece a pensar si esto de "ahorrar tiempo" no es un chamuyo que se vende. Una forma de control. La mayoría de los desarrolladores toma distancia a modo de defensa en el momento que se les pasa por la cabeza de implementar algo. Se nos "implanto" desde afuera, que desarrollar algo es una "montaña" que no se puede (o vale la pena) escalar. Esto ultimo dicho en los términos de lo "ajeno". Es algo para reflexionar y ser conciente de ello. Por que esta tesitura (lo que llama Carlos como zona peligrosa) es la forma en que se nos despoja de nuestro lugar de desarrolladores y nos convence progresivamente de que no somos capaces de desarrollar en otros niveles de experticia. Es como hacerse cargo de una adolescencia perpetua profesional. No hay etapa superadora, no "podriamos" subir al siguiente nivel (por decirlo de alguna manera).

Y seremos adolescentes perpetuos en tanto y en cuanto no "hagamos" y asumamos lo de afuera en detrimento de asumir lo nuestro.

La nocion de lo que podemos hacer y lo que no, tambien me pareciera esta supeditada por lo que hemos hecho antes. Lo que para mi seria enfrentar algo dificilisimo, probablemente para Carlos o para Ale sea una gilada, pero porque ellos ya lo han enfrentado anteriormente. Y si no lo hicieron, seguramente tienen una parte del camino recorrido, y no solamente en el sentido estrictamente tecnico, sino en la experiencia de todo lo que implica.

Esto, en muchos sentidos para mi implica libertad.

Hace un tiempo recuerdo en un asado con compañeros de laburo, estaban todos discutiendo sobre software libre y esas cosas... entre el acaloramiento de la discucion en un momento digo: "Dejense de joder. Yo no quiero software libre. Yo quiero ser libre!!"

Estruendo de risas, alguna gastada para mi y continuaron atareados discutiendo.

Me quede cayado. :-D

Ale decia:

"Por otro lado la energia y

tiempo invertido en hacer "las cosas" (podemos llamarlo los objetos si quieren :) no es nunca tan grande como lo sugiere una proyección lineal. En cambio el pensar en no hacerlo, nos alienta a pensar en un costo oculto o una relacion
alta de costo/beneficio; fundada en la utopia del beneficio sin realización.
A mi se me ocurren aquí ejemplos de situaciones en las que el beneficio sin realización en ciertas actividades, no es una utopía."

Si claro Ale, pero te voy a objetar lo que Carlos también objetó: Habria que ver que entendemos por "beneficio".

Lo que siento es que el beneficio va por otros carriles. Tomo el trabajo no solo como forma de sustento.

El trabajo como desarrollo personal.

Saludos

Elvio

El 15 de octubre de 2009 09:03, Carlos E. Ferro <ceferro@...> escribió:

Sebastian Gurin wrote: (01/10/2009, comento con bastante retraso)

> Yo no dije que evitaba construir ruedas, aunque no niego que es muy
> fácil acostumbrarse... es cierto que todas las situaciones son

> distintas, la solución propuesta por el framework es solo una y
> seguramente mi situación hubiera sido resuelta mejor con la solución
> personalizada. Soy consciente que al usar un framework pierdo en

> flexibilidad, conocimiento y el tiempo que gasto lo gasto en aprender
> el framework, no el problema que es lo interesante. Probablemente me

> ahorre tiempo globalmente, pero gastar el tiempo en algo no
> relacionado al problema es feo.

Creo que no es que no está relacionado al problema; si el framework ataca ese problema, está relacionado.
Creo que el problema es que al aceptar el framework, aceptaste la visión de otros, el modelo de otros. Y lo que es peor, al ponerlo en tu software, te comprometiste con ese modelo y lo estás apoyando. Esto suena (deliberadamente) muy ideológico, pero quiero decir que estás renunciando parcialmente a tu libertad de opinión, para encogerte de hombros y decir "ese tipo debe tener razón... yo le hago caso". Y eso, lo sabemos todos, casi siempre es peligroso.
Me recuerda algo que siempre dice Paenza, un divulgador científico, en su programa de televisión y sus libros. El cierra cada programa proponiendo un problemita matemático, y siempre repite que lo interesante NO es la solución, porque la semana siguiente él te da una solución. Lo interesante es pensar el problema, vivir con el problema y ejercitar la cabeza, pensar alternativas... Es lindo tener problemas; la satisfacción de resolverlos dura un segundo pero el disfrute del proceso de resolución es mucho más largo.

>> Lo digo con onda.. para sugerir reflexion sobre las distintas
>> formas de entender que implica construir sistemas.
>>
>> Decia que me resulta extraño porque siempre he encontrado que la
>> experiencia de construir algo propio es de un ariqueza que excede
>> por mucho lo que uno intentó obtener de él o ahorrar al no hacerlo.

Esto que decía Alejandro va también en la misma línea.

> Yo parto de la base de que "desarrollar algo" implica "ponerse un
> objetivo". "Quiero algo que haga esto y esto..." (se que se irá
> refinando con el tiempo, pero nace un objetivo. Yo en lo personal (o
> en esta etapa), trato de no colgarme con cosas que me aparten (en
> tiempo, todo es tiempo) de mi objetivo personal. Cada vez que creo
> algo nuevo, soy muy crítico de si en realidad es necesario, porque

> lamentablemente me acostumbré a MI triste verdad: cuanto más código
> más dificil y vulnerable el software.

Por supuesto. Pero el proceso muchas veces es escribir código, tal vez gran cantidad, y con eso entender algo. Esa comprensión nos permite ahora pulir la solución anterior y reducir la cantidad de código.
Creo que esa es la forma de tener poco código, no privarse de escribirlo desde el principio.
Estoy totalmente de acuerdo en no apartarse de los objetivos. Hay una etapa del que programa con objetos en que cada problema intenta llevarte a modelar el universo completo (en escala 1:1 de objetos virtuales con reales), y hay que combatir esa tendencia fuertemente. Pero adoptar cosas de otros sin terminar de entenderlas no es poner menos código, sino poner más código que encima no controlás (bueno, es el optimismo de pensar que el tuyo SI lo controlás :-)

> Para llegar a ese objetivo primero necesito solucionar varios
> problemas que se me presentaran. Para mi, muchas veces, llegar a ese
> objetivo primero es mucho más valioso que lo que me pueda enriquecer
> "la experiencia de construir algo propio". Esto me pasa con muchos
> "algos" que suelen interponerse entre yo y mi objetivo. En esa
> situación, ya sea porque ese "algo" no me interesa. o porque me
> interesa pero sé que me va a llevar mucho tiempo, o simplemente
> porque quiero algo robusto que sé que existe, en esa situación
> utilizo el framework. Yo se que es una solución que hizo otro para
> otro problema, pero al menos garantiza ser buena en ciertos aspectos
> y me permite a mi no estar obligado a comprender las internas. En
> general, trato de perder con los frameworks lo que quiero perder.

Te entiendo y como dije en otros emails, también lo hemos hecho y lo hacemos.
Lo que quiero remarcar es que no es una decisión para tomar a la ligera, como que voy paseando por el supermercado y veo una nueva marca de salsa de tomate y decido llevar una lata para probarla.
Esa lata pasó por muchas instancias de control y sé que puedo llevarla sin (gran) temor a intoxicarme.
Tomar un framework es más bien como ir por un bosque desconocido y agarrar un hongo que te parece comestible.

>> Por otro lado la energia y tiempo invertido en hacer "las cosas"
>> (podemos llamarlo los objetos si quieren :) no es nunca tan grande
>> como lo sugiere una proyección lineal. En cambio el pensar en no
>> hacerlo, nos alienta a pensar en un costo oculto o una relacion
>> alta de costo/beneficio; fundada en la utopia del beneficio sin
>> realización.
>
> A mi se me ocurren aquí ejemplos de situaciones en las que el
> beneficio sin realización en ciertas actividades, no es una utopía.

Esto depende de qué consideres "beneficio". Por supuesto, se puede ganar dinero sin realizarse. ¿Eso es un beneficio? ¿Para quién?

> Quiero crear una gui, no me interesa saber cómo pintar en pantalla,
> manejar eventos a bajo nivel, ni representar widgets de diferentes
> tipos gráficamente.

Hmmm... Es el típico ejemplo de decisión que no se puede tomar a la ligera. En Smalltalk, para la GUI, CADA DIALECTO inventó una forma distinta de representar y trabajar con los widgets, y es la peor pesadilla a la hora de migrar código de un ST a otro. Al punto que casi nadie lo intenta, se migra ligeramente el código "de modelo" y la GUI se programa de nuevo, porque es más fácil que migrarla.
Entiendo lo que decís, yo uso Window Builder en VS y rara vez bajo a ver los internals, rara vez mapeo una API Windows para un control no soportado... pero "rara vez" implica que alguna vez lo hacemos y sé cómo hacerlo.

> No me interesa porque mi programa es un super
> compresor de archivos, y lo único que necesito de la gui es que el
> usuario ingrese un archivo, no tiene nada que ver con el objetivo
> principal. Utilizo Morphic, gtk o la winapi porque si tengo que
> aprender y hacer esto yo solo, no lo haría nunca en mi vida (iría en
> contra de mi objetivo que es terminar).

OK, pero primero harás un mínimo análisis de cuál de esos usás y por qué. Y la siguiente vez,el análisis se repite, incorporando tu experiencia previa de uso. Eso ya es medir consecuencias del uso y es un paso más en la dirección de entender la problemática de la GUI.

> Necesito un reproductor de películas visual que me permita poner y
> sincronizar subtítulos visualmente y otras características que no he
> encontrado en ningún reproductor visual. Me encantaría aprender sobre
> temas como formatos multimedia, reproducción de video, etc y poder
> hacer el reproductor desde cero, pero nuevamente gastar 10 años de mi
> tiempo no está dentro de mis posibilidades. Sé que existe un
> reproductor de videos que hace todo esto y que puedo reutilizar pero
> su interface es por líneas de comandos, no visual. ¿Por qué es una
> utopía entonces beneficiarme de cumplir con mi objetivo principal sin
> "haberme realizado" ? Algo es algo...

Porque tenés un beneficio a corto plazo, te quedás contento un rato y compraste problemas a mediano plazo.
Vos creés que te realizaste y a las dos cuadras te pegás un porrazo porque a la patineta que compraste se le salió un rulemán... Es como creer que te van a regalar algo cuando te hacen escuchar la propaganda de un tiempo compartido.

Saludos
--
carlos e. ferro* *| senior developer* *| *caesar systems *| *see clearly. decide smarter.*

ceferro@... <mailto:ceferro@...> | t: +1.281.598.8790 | t: +54.11.4389.0126 | www.caesarsystems.com <http://www.caesarsystems.com/>

**This message and any attached documents contain information from Caesar Systems LLC that may be confidential/trade secret and/or privileged. If you are not the intended recipient, you may not read, copy, distribute or use this information. If you have received this transmission in error, please notify the sender immediately by telephone or by reply e-mail and then delete this message.

Responder | Reenviar | Mensajes en este tema (42)

Consejos

¿Sabías que...?

Mensajes

Tortugas, termitas y atascos de tráfico