StrongTalk – ¡Ahora la VM también es open source!

Hace ya algunos días que Sun liberó la máquina virtual de StrongTalk.

Para los que no sepan que es StrongTalk, le cuento que StrongTalk es la prueba (en realidad es la segunda prueba, la primera es la máquina virtual del Self) de que los lenguajes dinámicos no tienen porque ser lentos.

Para los nostálgicos: Pueden leer la accidentada (por culpa del Java) historia del StrongTalk .

Ya es hora de que nos dejemos de hablar de si un lenguaje es rápido o no porque tiene (o no) un compilador a código máquina o si corre sobre una máquina virtual. Las cosas son un poquito más complicadas y el simple hecho de tener o no un compilador a código máquina es sólo una parte de la historia.

Si no creen que lo que digo es verdad, tómense un tiempito para leer los papers que están en::

http://research.sun.com/self/compiler.html

http://www.strongtalk.org/documents.html

Por supuesto que esta noticia no es buena sólo para los Smalltalkers, sino que las comunidades de Ruby y Python también puede beneficiarse mucho si implementan, en sus respectivas máquinas virtuales, las tecnologías que tiene la VM de StrongTalk. Miren las reacciones que produjo, esta noticia, en las comunidades de Ruby y Python:

http://www.google.com/search?q=strongtalk+ruby

http://www.google.com/search?q=strongtalk+python

UPDATE: Cobertura en Barrapunto.

Web 2.0 - Un nuevo medio: LiveWiki (Un mejor Wiki)

Siguiendo con los ejemplos de posibles nuevos usos de la Web 2.0, ahora vamos a tratar de imaginar como se podrían mejorar los wikis actuales, usando la colaboración que nos permite el Web 2.0.

Les presento la primera versión de LiveWiki. LiveWiki es un Wiki vivo (de ahí su nombre ;)). Wiki en el sentido de ser un sitio modificable por muchas personas (http://es.wikipedia.org/wiki/Wiki), y vivo en el sentido que le venimos dando a la palabra, en las notas anteriores.

Para decirlo de otra forma: Nos olvidamos de tener que hacer “refrescar”, “recargar”, “reload” o “refresh” de la página para ver si cambió. Cuando la página cambia, todas las personas que estén viendo esa página verán el cambio en el mismo momento en que ocurre. De la misma forma, todos los usuarios conectados pueden modificar el contenido. Y, como en los ejemplos anteriores, el chat entre usuarios conectados sirve para coordinar el trabajo.

Esta versión es todavía muy simple... pero ya hace evidente las mejoras que pueden sufrir los wikis si logramos que estas tecnologías se masifiquen.

Esta es una lista de cosas que NO hace esta versión de LiveWiki, pero que pretendo incluirlas en las próximas versiones:

• Bloqueo pesimista con timeout para la edición. Para editar una página (o parte de ella), primero hay que obtener un bloqueo. Cuando alguien tiene un bloqueo sobre una parte, nadie excepto el puede modificarlo, y nadie puede obtener un bloqueo hasta que el lo suelte.
• Feedback visual del bloqueo: Los usuarios que NO tengan bloqueada la página (o una parte de ella) verán que alguien lo tiene bloqueado con un cambio de color de fondo. Incluso podrían ver quien lo tiene bloqueado, y molestarlo por el chat para que lo suelte. ;-)
• Edición visual del contenido. Esta versión usa una de las sintaxis de wikis (específicamente usa la sintaxis del Swiki). La idea es hacer un editor visual (o adaptar alguno ya hecho, como el TinyMCE http://tinymce.moxiecode.com/ ).
• Reordenamiento visual del contenido. Algo en la forma de http://tool-man.org/examples/edit-in-place.html. Hay que terminar de pensar como combinar eso con los bloqueos.
• Edición de parte del contenido. Con la finalidad de reducir los conflictos de actualización, se podrá modificar sólo una parte de la página mientras otros usuarios pueden estar, a la vez, modificando otras partes.
• Etc.

Y estás son algunas de las características que SI están incluidas en esta versión:

• Actualización en vivo de las páginas cuando alguna página referenciada en un link cambia de nombre.
• Actualización en vivo de las páginas que tiene links a páginas que todavía no están creadas, en el momento en que son creadas (el link a una pagina no creada es distinto, visualmente, que un link a una página que ya existe).
• Links de tipo “Incrustado”. Cuando hacemos un link de esta forma *[Una Página]*, el contenido de la página de nombre ”Una Página” será incrustado en la página contenedora. Lo mismo para un link del tipo *{Una Página}*, pero en ese caso se incrusta el título de la página (en lugar del contenido).
• Hay páginas Modificables y páginas No-Modificables (como la página Pages, que muestra una lista con todas las páginas creadas en el wiki).

Y, para continuar con la auto-impuesta tradición, les dejo un screencast que muestra algunas de las características de LiveWiki.

http://www.consultar.com/trastero/LiveWiki1.htm

Como siempre, están todos los fuentes disponibles en SqueakSource.

Disponible Squeak eToys para la computadora de 100USD

Yoshiki anunció en la lista de Squeak la disponibilidad de la imagen de Squeak que se usará en la laptops de 100USD.

Pide comentarios, sugerencias, reportes de errores, etc.

Web 2.0 - Un nuevo medio: Una hoja de cálculo mejor

Para ser franco, hace años que dejé de prestarle atención a la interminable lista de nombres y acrónimos fashion que genera nuestra industria. Sin embargo, con la intención de que la gente encuentre estas notas en google, hace varios posts que estoy usando términos “modernos” como Web 2.0, Ajax y esas cosas.

Quiero seguir mostrándoles ejemplos de, por supuesto es mi opinión (y para volcar mi opinión es que me puse un blog), posibles buenos usos de la interactividad que nos permite el Comet (oops, otra palabra fashion).

Este ejemplo, también, pretende mostrar otra cosa: ¡Qué feas y malas son las aplicaciones que estamos acostumbrados (o que nos obligan) a usar!

Hablemos un poco de las hojas de cálculo. Las hojas de cálculo llevan años sin evolucionar. No me refiero a pequeños cambios, que los vendedores hacen, para vendernos la versionActual+1, sino que me refiero a evolución (así, con letra grande).

Hace unos meses me encontré con Spreadsheet 2000. Les aclaro que yo no soy usuario de Apple, y que nunca vi ese producto andando. Me enteré de su existencia por un e-mail en la lista de Squeak.

Googleando me encontré, también, con este página que cuenta un poco más:

http://www.mactech.com/articles/mactech/Vol.13/13.04/Spreadsheet2000/index.html

Cuando me enteré de Spreadsheet 2000, no pude dejar de sentir esa nostalgia de quien extraña un presente que no fue. La verdad que usamos MUY, pero MUY mal las computadoras y nosotros (los programadores) somos bastante responsables de esa situación. La mayoría de las veces condenamos a los usuarios a experiencias rígidas y, sobre todo, aburridas.

Como no tengo una Apple, y estaba jugando al Comet y esas cosas, me decidí a hacer una especie de hoja de cálculo “en serio” y colaborativa copiando la idea de las cajitas conectadas y, agregando arriba, la colaboración que permite el Comet.

Esto es lo que logré:

Y, también, lo pueden ver en este screencast (otra palabra moderna más) donde se lo ve funcionando.

http://www.consultar.com/trastero/U1-Reducido.htm

Fotos de Squeak corriendo en la computadora de 100USD

Vía: http://croquetweak.blogspot.com/2006/09/squeak-for-every-child.html

Podemos ver unas fotos de Squeak corriendo sobre las míticas computadoras de 100USD.

http://piumarta.com/photos/olpc/

Web 2.0 - Un nuevo medio: Social Shopping

"Ahhhhhh" (con la boca abierta que muestra hasta las entrañas), ¡que sueño!

Otra noche que Nahuel no me deja dormir.... oops, ¡ahora se durmió! y yo, que me tomé 2 cafés super-cargados, no puedo pegar un ojo. Bueno, voy a escribir algo en el blog para combatir la oscura soledad de las 5:30AM (y para tratar de metabolizar el exceso de cafeína en mi cuerpo).

No es un secreto que me pasé los últimos tiempos tratando de buscar los límites que nos imponen los browsers de Internet actuales.

• Jugando con Comet en Squeak
• Comet y Canvas => Morphic en el browser
• ST2JS - Traductor de Smalltalk a JavaScript (Parte I)
• ST2JS - Traductor de Smalltalk a JavaScript (Parte II)
• SWT (Squeak Widgets Toolkit) - Algo para mostrar
• SWT (Squeak Web Toolkit) - Algo más para mostrar: Ping-Pong

Puedo resumir lo que aprendí en este tiempo con la siguiente frase:

“Los navegadores (de Internet) actuales son un asco,

pero pueden ser usados de mejor forma a la actual”.

Hoy es posible, no sin un esfuerzo considerable, sacar mejor provecho de los browsers. El punto de inflexión, creo, es la “masificación” de la nueva (bueno, de nueva nada) tecnología Comet (http://es.wikipedia.org/wiki/Comet). Para ser sinceros, “nueva” y “tecnología” son 2 palabras que no hacen justicia... a lo mejor podríamos decir: “viejo” “hack” y estaríamos más cerca de describir lo que es Comet.

De cualquier forma (con hacks y todo) hoy podemos hacer aplicaciones web donde, por fin, no todo es request/response (http://es.wikipedia.org/wiki/Hypertext_Transfer_Protocol).

Ahora, usando el hack^H^H^H^H^H^H^Hla tecnología Comet, podemos crear aplicaciones colaborativas. Ya es hora (en realidad ya lleva años siendo hora) que empecemos a buscar las verdaderas bondades de estar todos en red.

Hoy les quiero mostrar una de las pruebas que estuve haciendo: Social-Shopping.

Social-Shopping es uno de los ejemplos incluidos en el SWT. Básicamente, Social-Shopping, es un simple carrito de compras colaborativo. Más de 1 persona (puede ser más de 1 comprador, o compradores y vendedor, o compradores y asesores, etc) pueden interactuar, a través de Internet, en un único proceso de compra.

Social-Shopping, por ahora, luce así:

Sí, ya se... hablo de un “nuevo medio” y pongo un super-estático PNG. Mejor, les dejo un screencast donde se ve mejor la idea:

http://www.consultar.com/trastero/SocialShopping1.htm

Tengo algunos ejemplitos más en el tintero... pero no se los quiero muestrar todos juntos, para mantener la atención alta. ;-)

SWT (Squeak Web Toolkit) - Algo más para mostrar: Ping-Pong

Las cosas van tomando su fomar y ahora el framework (SWT) nos permite hacer algunos ejemplos divertidos. Les voy a mostrar uno de los ejemplos incluidos en SWT: Ping Pong.

El ejemplo Ping-Pong es, según creo, el caso más simple de uso del SWT que, a su vez, muestra las características interesantes del framework.

Uhhh... cuanta introducción... mejor vamos directamente al grano.

Para utilizar el framework empezamos creando 2 clases: SWTPingPongClientApplication y SWTPingPongServerApplication.

La primera (SWTPingPongClientApplication) es subclase de SWTClientApplication. La segunda (SWTPingPongServerApplication) es subclase de SWTServerApplication.

Según el SWT, una "aplicación" está partida entre su parte Client y su parte Server.

La parte Client (en nuestro ejemplo: SWTPingPongClientApplication) se traduce a código Javascript (usando el ST2JS) y se ejecuta en el browser de Internet. Por otro lado, la parte Server (SWTPingPongServerApplication) se ejecuta en el Squeak.

Por cada browser (de Internet) conectado, tendremos un par de instancias (la Server y la Client) que se mantienen "unidas" por el framework.

Cuando estamos en el Client, podemos enviar mensajes a la parte Server de la siguiente forma:

self serverSide foo.

De forma análoga, cuando estamos en el Server podemos enviar mensajes a la parte Client de la siguiente forma:

self clientSide bar.

La parte Client, al enviarle el mensaje #serverSide, nos devuelve un Proxy que reenvía los mensajes al Squeak usando JSON-RPC. Por otro lado, la parte Server, cuando le envíamos el mensaje #clientSide nos devuelve un Proxy que reenvía los mensajes recibidos, al Cliente, usando la conexión Comet.

Con esto ya sabemos lo suficiente para ver el código del ejemplo Ping-Pong.

La parte Client de nuestro ejemplo (SWTPingPongClientApplication) tiene sólo 2 métodos, veamos el primero:

initializeWidgets "Initialize the receiver's widgets" | root | root := self rootWidget. root addWidget: (SWTHeader level: 2 contents: 'Ping Pong'). root addWidget: (SWTButton caption: 'ping server' onClick: [:event | self serverSide ping]).

Allí vemos como se crean 2 widgets: Un Header y un Button. Si, lo sé... no es nada espectacular... pero lo interesante está dentro del evento #onClick del botón:

self serverSide ping

Cuando hagamos click sobre el botón, el mensaje #ping se evaluará, ¡pero del lado del servidor!. Veamos entonces la implementación de #ping en el Server (SWTPingPongServerApplication).

ping Transcript show: 'ping!'; cr. self clientSide pong.

Este método, además de mostrar algo en el Transcript, devuelve el "favor" a su contraparte Client en la última línea.

Ahora, para terminar, veamos la implementación de #pong en lado Client (SWTPingPongClientApplication).

pong ^ self inform: 'pong!'

Si les gustó, miren este Screencast