Minimal en Web

Estoy contentísimo.
Esto me ha provocado canas verdes, violetas, etc, pero logre matar el dragón
con la gomera.
En el proceso, aprendí muchisimo de como se genera una repuesta web, de como
funcionan HV2 y Seaside.
Adivinen que:

Se podría tener una vista Web de la imagen corriendo sin HV2.
Tampoco hace falta javascript .
Extremando, mi hipotesis es que se podria hacer solo con las capas de
DinamicBindings y Services del edificio Web.

Recuerdo aqui algo que digo a los alumnos y por favor corregirme si piensan
que no es así.

Suponiendo que el Web es un edificio

Planta baja = imagen tal como viene, todas tienen network.
Patio trasero (según luciano) = Nebraska, que hasta 3.10.2 tenia Squeak. No
existe en la mayoría de los forks
Entrepiso = DinamicBindings . Me encantaría alguno hiciera un tutorial , así
aprendo la teoría de esto. Son necesarios y dependen de la imagen cual hay
que usar
Primer piso = Comanche o Kom . Hay gente que usa Swazoo
Segundo piso = HV2
Tercer piso = posiblemente Illiad
Cuarto piso = Seaside , Aida . Aca alguno dirá que son dos pisos distintos.
Quinto piso = Aplicaciones sobre Seaside, la mas conocida es Pier

En una ciudad donde los cortes de luz abundan, es mejor no vivir muy alto :=)

jaaaaaaaaaaaaaaaa, me gustó mucho la última frase.

De lo que vos decís, hay capas que son equivalentes o casi, como Kom y
Swazoo, hoy día no estoy seguro si uno de los dos tiene ventajas sobre el
otro, pero entiendo que Swazoo está en más dialectos.

Tampoco se que decirte con Iliad, tiene buenas ideas, pero casi cero
documentación y encima se desarrolla
en GNU/ST, realmente me hubiera gustado usarlo mucho más, pero por ahora el
riesgo es demasiado alto, así que lo descarté. (Ya probé muchas veces usar
cosas demasiado nuevas y dependientes de una o muy pocas personas).

Así que para mi, lo seguro es Seaside y en tren de avanzar, me pasé a la
3.0.

Quizás mi estilo de trabajo es un poco a la vieja usanza, pero odio renegar
y perder tiempo con pavadas no documentadas o cosas que hacen perder tiempo
(el tiempo es vida y dinero). Así que me quedo (por ahora) con lo seguro:
Seaside.

Algunas de las ventajas que le veo:

- Mucha documentación, por ejemplo el último libro que publicaron que es
fantástico y cubre todo lo necesario. (Además de ese libro, hay
documentación imperdible, como el tutorial que hizo la gente de Gemstone que
ayuda a desarrollar una aplicación completa, o los artículo de Ramón Leon y
David Shaffer).

- Mucha gente que conoce a fondo el framework y que participa en su
desarollo, lo que hace que los errores se corrijan rápidamente.

- Mucha gente que usa el framework, lo cual hace que haya mucha gente que
pueda contestar dudas y ayudar en la lista.

- Está en uso en muchas aplicaciones importantes, lo cual hace que esté
maduro y estable.

Bueno, son solamente opiniones personales :) que por ahí le pueden servir a
alguien, no se a quien si solo somos dos en esta lista :D

Saludos Edgar!


El 10 de febrero de 2010 08:57, Edgar J. De Cleene <
[hidden email]> escribió:

>> >Así que para mi, lo seguro es Seaside y en tren de avanzar, me pasé a la
>> 3.0.


No tengo ninguna duda que por aca va la cosa.
Pero algún dia se completara el armado de ³Endeavour² que tiene poca
capacidad.
Y aca harán falta imagenes super chicas.
Tengo que desarrollar el ³copiador inteligente² sobre la base de los
RemoteExperiments.
O sea dos imagenes conectadas via TCP con una lógica simple que permita
tener una imagen madre y otra hija que pregunte lo que necesita

En el otro mail olvidé mencionar algo que, para mi, también es importante, y
creo que da como para ser un piso: Magritte.

Es complicado, grande, a mi me cuesta a veces trabajo extenderlo, pero para
hacer aplicaciones de negocios, es una ayuda grandísima.

Saludos.


El 10 de febrero de 2010 09:46, Edgar J. De Cleene <
[hidden email]> escribió:

> En el otro mail olvidé mencionar algo que, para mi, también es importante, y
> creo que da como para ser un piso: Magritte.
>
> Es complicado, grande, a mi me cuesta a veces trabajo extenderlo, pero para
> hacer aplicaciones de negocios, es una ayuda grandísima.
>
> Saludos.


Es posible, yo pensaba en Web.
Si pensamos en aplicaciones completas, falta todo lo de base de datos y
persistencia.

Para base de datos, en algún momento me tengo que poner con el componente
unix libre de SQL que hay por ahi.

Para persistencia, hasta ahora los .obj me vienen funcionando.

Y reitero algo que ya he preguntado en la otra lista.

Porque todos hablan de objetos y usan ASCII como xml, etc?
Yo tengo cosas antidiluvianas grabadas como .obj que funcionan sin ningún
drama en CUALQUIER fork.

Ahora si los pharopatas en su afan de diferenciarse o los trunkeros en su
afan de figurar siguen empeñandose en hacer cosas que SOLO FUNCIONEN en SU
FORK, estamos al horno con papas...


Vieron que Lukas Rengli se digno a mandar un par de mails ?
El trunk sigue abierto a todos como nunca antes en la historia.
Es un caos, pero si revisan su mitología descubrirán que el mundo se origino
del caos.

Lastima que Maxwell Smart no está mas con nosotros para combatir contra KAOS


Edgar

El 10 de febrero de 2010 10:52, Edgar J. De Cleene <
[hidden email]> escribió:



Si, si, Magritte funciona en web, incluso Pier está basado en Magritte.
También funciona (o funcionaba)
con Morphic.




> Si pensamos en aplicaciones completas, falta todo lo de base de datos y
> persistencia.
>
> Para base de datos, en algún momento me tengo que poner con el componente
> unix libre de SQL que hay por ahi.
>
>
Yo bases de datos relacionales no uso, excepto que sea imprescindible, pero
ya de por sí son
un problema, pero mezclándolas con objetos, peor todavía.

Mis opciones de persistencia son:

- Imagen (con snapshots y demás) cuando el volumen lo permite;
- Serialización;
- Magma;
- Gemstone (aún no lo conozco mucho, tengo un servercito instalado, pero
falta aprender más)



> Para persistencia, hasta ahora los .obj me vienen funcionando.
>
> Y reitero algo que ya he preguntado en la otra lista.
>
> Porque todos hablan de objetos y usan ASCII como xml, etc?
> Yo tengo cosas antidiluvianas grabadas como .obj que funcionan sin ningún
> drama en CUALQUIER fork.
>


No se porque no te habrán contestado, quizás algunos no entiendan del todo
el paradigma de objetos,
o quizás necesiten imperiosamente usar cosas que "en la industria" son
stándard, como las que vos mencionás.....



>
> Ahora si los pharopatas en su afan de diferenciarse o los trunkeros en su
> afan de figurar siguen empeñandose en hacer cosas que SOLO FUNCIONEN en SU
> FORK, estamos al horno con papas...
>
>

Coincido, hay que hacer cosas que anden en todas partes, pero
lamentablemente parece que
nos vamos alejando unos de otros..........




Saludos.
Germán.

Buenasss... (para que no se sientan tan solos en la lista :=)...

Comparto la opinión de Germán sobre Seaside... el tamaño de su
comunidad y el tiempo de maduración que tuvo lo hacen la opción más
conveniente para proyectos en donde el factor tiempo es un
condicionante importante.

Yo lo he usado para apps en producción y me he sentido muy cómodo.
Tengo mucho igual que aprender ahora en la versión 3.0.

Ya en proyectos más tranquilos en donde se tenga el suficiente tiempo
e interés de probar cosas nuevas, se puede experimentar con otros
frameworks interesantes como SWT por ejemplo.

En cuanto a la persistencia, comparto también con Germán la intensión
de usar bases de objetos como la imagen misma, magma o Gemstone (no
conozco demasiado de éste último, he tirado unos tiros con GLASS
solamente).

Aunque no me parece que las bases relacionales sean un problema. Creo
que todo pasa por un buen diseño del modelo en objetos en smalltalk
(con la lógica de la aplicación), del modelo de datos en la base
relacional, y de la interface que hace el mapping entre ellos (no
andar mezclando la generación del código SQL y la conversión en
objetos de la tabla resultante del query, con la lógica e interacción
de los objetos de mi modelo).

Yo creo que el punto está en qué es lo que se quiere persistir en algo
"ajeno" a la imagen: solamente los datos de los objetos (simplemente
porque son muchos) o el modelo entero (con las clases incluidas, en
donde no solamente se estaría persistiendo los datos sino también su
comportamiento).

En definitiva, si tomamos el primer punto que nombré anteriormente...
no hay taaaanta diferencia en los conceptos teóricos generales de
bases de datos entre ambas tecnologías (por ejemplo: magma/Gemstone
vs. RDBMS): la definición de una transacción es la misma, los índices
tienen el mismo significado y utilización, los controles de
concurrecia se basan en los mismos principios (optimista y pesimista),
y las colecciones tienen la misma finalidad (solamente que
serializados usando diferentes estructuras y formatos).

(perdón por haberme ido un poquito por las ramas porque se estaba
hablando de seaside ;)...

Saludos!

On 2/11/10 2:27 AM, "Alejandro Aguirre" <[hidden email]> wrote:

> Aunque no me parece que las bases relacionales sean un problema. Creo
> que todo pasa por un buen diseño del modelo en objetos en smalltalk
> (con la lógica de la aplicación), del modelo de datos en la base
> relacional, y de la interface que hace el mapping entre ellos (no
> andar mezclando la generación del código SQL y la conversión en
> objetos de la tabla resultante del query, con la lógica e interacción
> de los objetos de mi modelo).

La opinión sobre que base de datos usar no es mia, sino que la aprendi de un
australiano que German Boccoleri convenció para que cuando hace unos años
vino a Argentina pase un par de dias en Rosario.

Aprendí toneladas de Mark, que manejaba todo lo relacionado a soft en uno de
los bancos mas grandes de Australia que tenia 8 sucursales en el sudeste
asiático y una en Brasil.

El con su experiencia sustentaba esta opinión.

Mi unica experiencia es con Omnis 3 y 5, un manejador de base de datos de la
Mac vieja que era realmente extraordinario.

Y esta la relación costo / beneficio.

Si hay que hacer algo estandard, pocas dudas caben que ese estandard es SQL

> (perdón por haberme ido un poquito por las ramas porque se estaba
> hablando de seaside ;)...


Me encanto tu aporte, espero que otros se prendan.
Y les vuelvo a recordar, si tienen algo para contar y compartir, tiren el
tema en el bar.

Edgar

Hola Muchachos:

El 11 de febrero de 2010 04:52, Edgar J. De Cleene <
[hidden email]> escribió:

Yo no comparto esto. Las bases relacionales tienen como gran "contra" versus
el desarrollo con objetos una separación tajante entre datos y programas (o
si
se quiere decir de otra manera entre datos y comportamiento).

Datos guardados en tablas están muertos, no significan nada, el conocimiento
de qué es o qué significa tal campo, está en los programas que los usan,
entonces
no puedo compartir jamás un comentario como que "es más o menos lo mismo".

Además, la impedancia que introducen el desacople entre dos mundos tan
diferentes
como objetos y relacionales, es (creo yo) insalvable.

Si decimos que es más o menos lo mismo, estamos obviando que una base de
objetos, cualquiera
sea, tiene una imagen y ¿qué es la imagen? Es un lugar, un medioambiente,
donde "viven" los objetos
y ese concepto es diferencial, único e insoslayable, es lo que diferencia a
Smalltalk del resto, es lo
que hace posible en gran medida la "magia" del Smalltalk y los objetos.

Así que Patito, con todo respeto, no me vengas con que es "más o menos lo
mismo".

Por algo será que el movimiento No SQL está moviéndose tanto.

Las bases de datos relacionales, en mi humilde opinión, FUERON un avance muy

importante sobre las viejas organizaciones de archivos, pero hoy, para mi,
son
tecnología obsoleta, superada, existen porque la rueda comercial de las
grandes
empresas hace que existan, pero ni siquiera pueden (excepto una que yo sepa)

escalar procesamiento en forma horizontal.



A mi también me encanta que participes Pato y por supuesto toda la demás
gente de la lista. Es triste una lista de sólo dos :(

Discrepar es parte de la vida, jajaja.

Saludos
Germán.

Jejeje... yo sabía que me iba discrepar Germancito... :=)

Si en realidad yo no quise decir que son "más o menos lo mismo"...
comparto las diferencias que mencionás...  simplemente que usan de
alguna manera los mismos conceptos generales de bases de datos
(transacciones, concurrencia, índices, etc.).

Igual terminamos de acuerdo en la parte en donde digo que el punto
está en lo que se persiste: los datos solos, o los datos y su
comportamiento.

Saludos!

Bueno Edgar esto para que veas que ya somos más de dos.....Sunchales está
copando SqueakRos :)

Si esto sigue así le vamos a tener que cambiar el nombre, será SqueakSun ?
jjajajajaa

Saludos.


El 13 de febrero de 2010 17:21, Alejandro Aguirre <[hidden email]>escribió:

>Si esto sigue así le vamos a tener que cambiar el nombre, será SqueakSun

Y empeza SqueakSun .
Al menos al otro que se anima a escribir lo tenes cerca :=)

jajaja, no no, en todo caso sería PharoSun :)

jejeje, no te enojes.

Ahi apoyé to comentario en squeak-dev sobre hasta cuando van a seguir
tocando, asi ya es imposible.

Saludos.



El 14 de febrero de 2010 10:09, Edgar J. De Cleene <
[hidden email]> escribió:

>
>
> >Si esto sigue así le vamos a tener que cambiar el nombre, será SqueakSun
>
> Y empeza SqueakSun .
> Al menos al otro que se anima a escribir lo tenes cerca :=)
>
>  
>

>jajaja, no no, en todo caso sería PharoSun :)

Y bueno
El sol sale para todos