Smalltalks 2007

Ayer miércoles finalizaron las charlas de Smalltalks 2007.

Solo estuve presente en algunas charlas sobre Seaside y en el workshop de GLASS, y pese al calor de las aulas del Pabellón de la FCEyN, Smalltalks 2007 fue una sorpresa agradable.

 

Los organizadores hicieron un laburo bárbaro y eso se notó. (Felicitaciones!!)

 

Como comenté es un post anterior, hice el logo para estas conferencias -una vil copia del globo de la Byte con el obelisco de fondo ;)

El logo esta publicado bajo licencia de Creative Commons y lo pueden bajar de este link.

Conclusiones que saco de las charlas:

• Hay gente haciendo cosas muy cool en Smalltalk: editores con refactorings para Traits o herramientas que combinan Smalltalk y Flex usando WebServices.
• Seaside es excelente y espero que con el tiempo vayan surgiendo proveedores de hosting que lo soporten. Quizás a medida que se popularice la utilización de virtualización el hosting deje de ser un problema.

• Percibo una actitud entre los Smalltalkers (no conozco el ambiente Ruby o Python) que no es muy copada: todo lo que esta en Smalltalk es bueno y el resto son estúpidos. Por ejemplo: En los comentarios finales de la charla sobre combinar Flex y Smalltalk surgió la pregunta lógica de "Por que tuviste que hacer la interfaz en Flex y no en St?", a lo que siguió la respuesta sensata de: "Flex me da buenas herramientas para UI y St para modelar el dominio, si hubiese tenido buenas herramientas de UI en St lo hubiese hecho en St". Acto seguido los comentarios en el publico fueron: "hay alguien trabajando en una librería de Cairo para VW" y "probablemente Sophie este en la próxima versión de Squeak".

  Esos comentarios si bien son muy positivos y entusiastas sobre Smalltalk, esconden mucho de miopía: Cairo es un API para dibujos 2d (como GDI+ o Java2D), Sophie es para crear libros multimedia y esta en una etapa alpha (basta bajarlo y probarlo un poco para darse cuenta) asi que actualmente estas no son ni remotamente alternativas a Flex.

  Sería bueno tener un buen framework/editor de UI en St, pero pensar que eso se hace en dos minutos es tonto, pese a que uno critique a Java o .Net como lenguajes, muchos de los frameworks y herramientas que tienen estas plataformas son muy difíciles de hacer.

  Asi que por que no emplear una actitud más post moderna y combinar St con otras herramientas? De esa manera uno se da el gusto de usar St y poder hacer las cosas.

Uso de PowerPoint en las clases

UPDATE (2009): volvi a retomar este tema en un post más reciente sobre Presentaciones

 

Llevo ya casi un año dando clases de programación con Java.

En los cursos dí o vi (cursos "oficiales" de Sun e IBM en un caso y cursos de Microsoft en el otro) hay un patrón común: todos utilizan presentaciones tipo PowerPoint* para organizar el contenido del curso.

Esta organización basada en PowerPoint le facilita las cosas al instructor: uno en cada clase solo tiene que seguir los temas en los slides. ¿Pero ayuda en la enseñanza?

Presentación != Clase

Buscando en Internet sobre el uso del PowerPoint en la enseñanza me encontré con esta presentación. Los puntos principales marcados en la misma son:

• No usar soniditos, ni animaciones para hacer la presentación más linda. No aportan nada al contenido y generan que el foco de atención se salga del contenido hacia los efectos de la presentación.
• No utilizar fotos o gráficos que no estén relacionados con el contenido.
• Usar gráficos lo menos posible (no coincido con esta idea, de hecho creo que los "bullets" son contraproducentes)
• Usar colores con un contraste que permita la legibilidad cuando la presentación es mostrada. (es decir evitar el uso de los templates fashion que vienen con PowerPoint).
• Más allá del PowerPoint ayudar a los alumnos a tomar notas sobre la clase. Esto es darles un outline de los temas tratados.

Sin embargo creo que con esto no alcanza. Por ejemplo tanto los slides de Sun como los de IBM no hacen uso de animaciones, colores raros o gráficos superfluos; pero hay algo que falta en ese tipo de cursos.

Lo que falta desde mi punto de vista es un enfoque más didáctico constructivo, en general los cursos están organizados usando un esquema parecido al de la facultad: "teórico" con la presentación en slides y luego práctica haciendo ejercicios en la máquina.

El problema es que cuando uno da la clase "teórica" todos los alumnos tienen una actitud pasiva y la mayoría pierde de vista los conceptos principales. Este problema se nota mucho cuando uno pasa a la práctica, por ejemplo: quizás estuve hablando como una hora sobre las clases e instancias y sin embargo a la mayoría de los alumnos les cuesta entender la diferencia cuando empiezan a programar.

Creo que en programación a diferencia de otras áreas, es muy fácil partir la enseñanza desde un problema y enseñar los conceptos a la par. Y luego utilizar presentaciones tipo PowerPoint pero solo para dar un resumen de los conceptos.

Un punto donde no coincido del todo con la presentación en el link anterior es el que dice que no es muy bueno poner muchos gráficos.

Sin embargo yo creo que hay una diferencia entre poner dibujos y fotos como metáfora y utilizar un diagrama para visualizar un concepto. Es más creo que tomar ideas sobre áreas como visualización de la información y diseño gráfico pueden ayudar a transmitir visualmente un concepto.

Algunos links relacionados:

• Tips sobre como hacer presentación con PowerPoint
• Papers relacionados al uso de BlueJ en la enseñanza de Java
• El problema de enseñar OOP: parte 1, parte 2
• Articulo sobre CRC presentado por Ward Cunningam y Kent Beck en OOPSLA
• Libro de Ducasse sobre aprender a programar usando robotitos en Squeak. Esta orientado a chicos, pero el entorno se podría adaptar para enseñar los conceptos de OOP, en especial sobre clases e instancias: fabrica de robots / robots.

* uso la palabra "PowerPoint" para referirme a los slides en general... de hecho en los cursos de Sun e IBM los slides son archivos PDF

Feedback y UnifOrm!daD (Virus y diseño de interfaces - 3ra parte)

En el post anterior escribí acerca de los archivos de sistema y el problema de visibilidad. Así que continuando con los problemas planteados en Virus y diseño de interfaces, ahora le toca el turno al AutoRun. Creo que hay dos problemas con él:

El primero es un problema de feedback: cuando inserto un CD con autorun no tengo un feedback sobre el hecho que se esta por ejecutar un programa de forma automática y poder así evitar que eso suceda. Puedo evitar la ejecución apretando SHIFT, pero eso no es algo obvio para cualquier usuario. (aunque en Vista y el SHIFT funciona distinto - ver el comentario UPDATE más adelante).

Volviendo al problema planteado en el primer post: si al insertar el pendrive Windows me avisa que esta por ejecutar un programa, al menos sabría lo que esta pasando.

Pero... ¿Por qué Windows me indica con una ventana si inserto un CD con fotos o música, pero no me dice nada si inserto un CD con un instalador que se va a ejecutar? ¿No son acaso tareas con ciertas similitudes: en ambos casos estoy insertando un CD que quiero usar?

Esta cuestión de uniformidad es para mi el segundo problema.

Diferencias en el código que se reflejan en la UI

Aunque la tarea de usar un CD con fotos o uno con un instalador tengan muchas similitudes (al menos para mi son similares), son presentadas de forma distinta al usuario por una razón no tan obvia: a nivel API son cosas distintas.

En Windows XP se introdujo un API llamada AutoPlay cuyo objetivo más general es permitir la "auto ejecución" según el tipo de dispositivo (ver Using Hardware Autoplay). Creo que el AutoRun se pudo haber implementado sobre el API de AutoPlay, creando un handler para CDs con autorun.inf, pero por una cuestión "histórica" se mantuvieron como cosas separadas. (y aún hoy sigue generando confusión a los usuarios)

UPDATE: Estuve utilizando Windows Vista y si bien el SHIFT funciona distinto, el comportamiento por default para el autorun es mostrar una ventana como la del autoplay. Eso es de mi punto de vista un cambio positivo.

Conclusiones

A nivel programación hay algo interesante que surge de los últimos dos posts: El diseño del sistema a nivel programa se termina reflejando a nivel de UI.

Creo que ambos problemas de interfaz vienen de niveles más bajos:

• Los archivos con atributos de sistema y ocultos son un "hack" que viene desde DOS por la ausencia de un mecanismo mejor para crear constraints de autorización.
• La inconsistencia en la interfaz entre AutoRun y AutoPlay vienen de APIs distintos que no fueron "refactorizadas".

A nivel interfaz, la conclusión la voy a transcribir del libro "The Design Of Everyday Things" de Don Norman:

Design should:

• Make it easy to determine what actions are possible at any moment (make use of constraints)
• Make things visible, including the conceptual model of the system, the alternative actions, and the results of actions.
• Make it easy to evaluate the current state of the system.
• Follow natural mappings between intentions and the required actions; between actions and the resulting effect; and between the information that is visible and the interpretation of the system state.

In other words, make sure that (1) the user can figure out what to do, and (2) the user can tell what is going on.

Visibilidad y restricciones (Virus y diseño de interfaces - 2da parte)

En el post anterior mencione que "ocultar los archivos" era para mi un error de diseño. Voy a aclarar eso un poco más.

Ocultar la complejidad del sistema esta bien, por ejemplo: Ejecuto múltiples programas y no me interesa como funciona internamente el sistema operativo (SO) para permitirme hacer eso.

La misma idea aplica a los archivos:

Al usuario promedio no le interesa si el SO tiene que guardar cierta información en el disco para su funcionamiento interno. De hecho, esta bien que el sistema no me permita borrar fácilmente esa información (y evitarme así "hacer cagadas").

¿Entonces cual es el problema?

El problema es que no hay una relación entre el modelo conceptual expuesto al usuario y el modelo del sistema.

Voy a explicar esta frase con un ejemplo, supongamos una carpeta con un archivo:

Ahora marcamos"archivo.txt" como oculto y de sistema:

Pero en el Explorer no hay ningún indicador de que la carpeta contiene un archivo oculto:

A ver... y con la linea de comandos?

Tampoco. Y en las propiedades de la carpeta?

Ahora si. Y si lo abro con el Notepad? (no voy a poner la pantalla de eso, pero si hacen la prueba van a ver que pueden abrir y modificar el archivo normalmente).

El modelo del sistema es el siguiente:

No hay ninguna restricción especial sobre los archivos marcados como ocultos y de sistema.

Son los programas quienes tienen que interpretar estos atributos según sea necesario.

Por ejemplo quienes le dan un tratamiento especial a estos archivos son las herramientas de consola del sistema operativo y el Explorer, principalmente para evitar que usuarios inexpertos borren estos archivos accidentalmente.

Sin embargo la gran mayoría de los programas simplemente ignora estos atributos y no hay ninguna restricción de permiso sobre los mismos.

Pero el modelo expuesto al usuario es:

En el explorer y en la consola ejecutando "dir" veo todos los archivos que hay en mi maquina. Si la carpeta o el pendrive no tienen archivos entonces están vacíos.

Mas allá de la no visibilidad de los archivos, esperaría también que un archivo de sistema no pueda ser modificado directamente por cualquier herramienta.

Solución 1: Visibilidad

La solución más sencilla es aportar visibilidad al usuario. No es necesario mostrar los archivos para eso, simplemente indicar que hay archivos ocultos:

Y si queremos llevar la visibilidad un paso mas, es decir que no existan archivos ocultos, todavía tenemos el problema de evitar que el usuario "meta la pata"...

Solución 2: Visibilidad + Undo

Un buen diseño tiene que permitir que el usuario se equivoque (este articulo de la gente de Humanized explica eso con algunos ejemplos).

Si el usuario borra/modifica un archivo de sistema debería poder volver atrás fácilmente.

Lamentablemente en un SO esa vuelta atrás no es sencilla: y si borro un archivo que hace que el sistema no arranque más? Ok, no hay forma de hacer un undo sencillo para todos los casos, lo que nos lleva a otra solución...

Solución 3: Visibilidad + Restricciones

Otra forma de resolver el problema es simplemente haciendo que el usuario no tenga permiso para modificar archivos de sistema.

Si el usuario quiere borrar/modificar un archivo de sistema tiene que cambiar a un usuario con más permisos y por lo tanto tiene un indicativo muy fuerte por parte del sistema de: "mas vale que sepas lo que estas haciendo".

En el caso particular de Windows esto no siempre es posible: en el sistema de archivos FAT32 el único "permiso" es el de marcar un archivo como solo lectura.

Lo que nos lleva a otro tipo de restricción...

Solución 4: Visibilidad + Standards (o mejor dicho Restricciones "culturales")

Para darle al usuario la información de: "no deberías tocar esto al menos que sepas lo que estas haciendo", también se puede usar una "restricción" cultural. Es decir estandarizar donde estan los archivos de sistema.

Por ejemplo a nadie se le ocurre borrar la carpeta C:\WINDOWS o C:\Archivos de Programas.

Pero Windows no sigue siempre estos "standards", por ejemplo hay archivos de sistema en el directorio raíz y que salvo por los atributos de oculto y de sistema no se diferencian del resto.

El atributo de sistema es una restricción "cultural", sin embargo tiene algunos problemas de visibilidad:

• Si un archivo es marcado como de sistema, se muestra de la misma forma en el Explorer.
• No hay forma de diferenciar un archivo oculto de sistema de uno que solo tiene el atributo de oculto.

Solución 5: La combinación de las anteriores

Salvo por la solución de facilitar el Undo, Unix hace una combinación de las soluciones anteriores:

• Los archivos de sistema solo pueden ser modificados por un usuario con permiso de root
• "Culturalmente" los archivos que son de usuarios están en el directorio "/home". El resto de las carpetas tiene un significado especial.

En Unix también hay configuraciones que se guardan en archivos "ocultos". Pero acá el "modelo conceptual del sistema" es presentado de una forma más directa al usuario: se sigue la convención que los archivos que empiezan con punto no se muestran por default en las listas de archivos. Sin embargo ninguna herramienta trata a estos archivos de forma especial (como sucede con los archivos de sistema y las herramientas de la linea de comandos en Windows).

Conclusiones

• El modelo expuesto al usuario debe ser coherente con el modelo del sistema
• No es necesario exponer toda la complejidad al usuario mientras el usuario pueda construirse fácilmente una idea de lo que esta pasando.

Algunas herramientas que uno tiene para lograr eso: visibilidad, restricciones y "standards".

Virus y diseño de interfaces (1era parte)

"Che sabes que la compu me anda raro, que puede ser?"

Como "compunerd" que soy es típico que me hagan estas consultas. En general la gente piensa que como uno estudia computación conoce absolutamente todo, desde hardware hasta las configuraciones mas rebuscadas de windows. Estas ultimas semanas me toco revisar la PC de mi novia y de unos amigos. Ambas maquinas tenían problemas parecidos. En una había un programa llamado Disk Knight que se copia por medio de los pendrives (no es un virus maligno, pero es igual de molesto). Y en la otra un virus cuyo nombre no me acuerdo. Una característica de estos virus es que no son rebuscados programas en assembler con código para mutar y ocultarse en archivos exe. Si no que son programas simples (es decir pueden ser creados por cualquier persona con un minimo de conocimiento de programación) que aprovechan algunos errores de diseño de Windows. Lo que me interesaría escribir en esta serie de posts es acerca de esos errores de diseño: cuales son y que se puede aprender de ellos. Los problemas Ambos virus utilizaron las siguientes características de Windows:

• Archivos ocultos del sistema
• Autorun
• La entrada "Run" de la registry (para ejecutarse al inicio)

Archivos ocultos y de sistema Windows tiene flags para marcar a un archivo como oculto y de sistema, y evitar así que un usuario común y corriente lo borre accidentalmente. Estimo que el 90% de los usuarios -yo me incluyo en ese numero- tiene activada la opción de ocultar archivos de sistema. ¿Por que? Simplemente por que la mayoría de los archivos de sistema (thumbnails y otras hiervas) molestan cuando uno quiere manejar los archivos en la PC. (si selecciono fotos para copiar no quiero estar copiando siempre el Thumbs.db). Usando estos atributos un virus puede copiarse a un directorio/pendrive sin ser visto y sin usar ninguna técnica complicada de stealth (que por lo general es dectectada por un anti-virus). Desafíos:

• Evitar que el usuario cometa un error que rompa el sistema
• Ocultar ciertos niveles de complejidad más bajos del sistema

Autorun El autorun parece buena idea para las PC de hogar: si quiero jugar un juego solo pongo el CD como si fuese una consola y listo. Pero prácticamente todos los juegos de PC que requieren instalación. Así que el autorun se limita a ejecutar el setup, por lo que pierde un poco la gracia de la idea original. Además requiere de cierta "fe" por parte del usuario: si tengo activado autorun e inserto un CD tengo que saber de antemano que programa estoy queriendo ejecutar. Otro problema es que Windows permite que cualquier unidad de disco tenga autorun! (Prueben de poner un autorun.inf en el C: y vean como se comporta ahora el icono de Mi Pc). Desafíos:

• Detectar según el contexto cual es la intención del usuario. (quizás quiero ver los archivos en el CD, no instalar la aplicación)
• Como hacer que el usuario tenga el control sin hacer más complejo el uso del sistema.

La entrada "Run" de la registry El problema de la entrada "Run" en la registry es que uno nunca termina sabiendo que es todo lo que se ejecuta al iniciar Windows. Muchas aplicaciones colocan iconos en el system tray, otras como el Office o el Acrobat tienen "caches" para hacer que el programa se levante más rapido, otras programas para detectar nuevas versiones y otras para cosas que en realidad deberían ser servicios del sistema. Desafíos:

• Intention revealing: como hacer que el usuario sepa que es necesario o no para que el sistema funcione bien.

En el próximo post me voy a dedicar a analizar el problema de los "Archivos ocultos" es decir como:

• Evitar que el usuario cometa un error que rompa el sistema
• Ocultar ciertos niveles de complejidad más bajos del sistema

Dibujando el logo para el 1er. Congreso Argentino de Smalltalk

Hace unos días Hernán me pidió si podía hacer un logo para el congreso Argentino de Smalltalk que él esta organizando junto con Leandro Caniglia. Hoy acabo de terminar la primer versión del logo (no sé si será la versión final, todo depende de los comentarios de Hernán y Leandro). El dibujo no es nada original: es prácticamente una copia de la portada original de la Byte. El problema es que crear ilustraciones de este tipo que sean originales no es un trabajo menor: requiere de muchas pruebas con diferentes ideas, es decir requiere de un tiempo que no tengo :( Les comparto la primer versión junto con algunos tips para los que quieren aprender Illustrator: Tips para aprender Illustrator:

• Es bueno aprenderse las combinaciones de tecla para cada una de las herramientas. La mayoría de las herramientas de la paleta se pueden seleccionar con una sola tecla, por ejemplo A - point selection, V - direct selection, P - path, etc. La ventaja: uno puede tener una mano en el teclado y la otra en lapiz/mouse. La diferencia entre laburar así y estar seleccionando las opciones de la paleta es enorme.
• Teclas importantes: BARRA ESPACIADORA no importa que herramienta se este usando la barra muestra la mano y permite mover el canvas (esto es así en todas las aplicaciones de Adobe), Z - Zoom (yo uso mucho el zoom cuando estoy trabajando).
• Aprender a utilizar: Live Paint, Clipping Masks y las herramientas para combinar figuras del path finder... ahorran mucho tiempo.
• Me costo mucho darme cuenta como hacer un gradient transparente (odio la herramienta de gradient de Illustrator, es muy incomoda!), hasta que encontré esta pagina.
• Uno puede aprender Illustrator de forma intuitiva... sin embargo es bueno ver algunos tutorials en la web, la UI de Illustrator tiene algunas cosas que no están a primera vista por ejemplo:
• En la mayoría de los lugares donde se puede ingresar valores tipo 1px uno puede hacer cuentas en diferentes unidades: 1px+5pt.
• La mayoría de las herramientas se comportan diferente cuando uno presiona Alt, Ctrl ó Shift (o la combinación de estas). Asi que vale la pena hacer la prueba
• Sitios con tutorials:
• PixelPerfect: Es un programa de TV vía web. La mayoría de los episodios son sobre Photoshop, pero hay algunos de Illustrator (muy recomendable)
• Illustrator Techniques: tiene algunos tutorials on-line.

El Smalltalk que no miramos

Usualmente los dialectos recomendados para empezar con Smalltalk son: Visual Works y Squeak, sin embargo rara vez alguien recomienda mirar GNU Smalltalk. ¿Por qué? Simplemente por que a primera vista GNU Smalltalk (gst) luce muy GNU y poco Smalltalk, es decir no hay un entorno grafico por default, si no herramietas de linea de comandos. Y por esa razón nunca tuve interés en mirarlo. Hace unos días anunciaron la puesta on-line de su nuevo sitio web (antes tenían una pagina muy escueta que tampoco motivaba demasiado). Mirando el sitio hubo un par de cosas que llamaron la atención e hicieron que me dieran ganas de ver este proyecto:

• Soporte para embeber St en otras aplicaciones: esto es realmente importante por que fue lo que llevo a que lenguajes como Python o Lua se hagan conocidos (bueno Lua no es tan conocido...)
• Soporte para continuations (lo que para envidia de algunos significa que en teoría es posible portar Seaside a este dialecto de St)
• GUI toolkit con soporte para GTK: no me gusta GTK, pero que hayan logrado tener eso es importante, especialmente por que Squeak no tiene soporte para UIs nativas. (salvo por algún que otro proyecto que nunca se llegó a terminar).
• Namespaces: mientras que en las listas de Squeak siguen discutiendo (1, 2, 3 y quizás más veces) como hacer la implementación perfecta de namespaces, gst ya los tiene (aunque no sean "perfectos"). En mi opinión esto aunque parezca una boludez es importante para poder compartir módulos y usar diferentes frameworks...
• Ejecución de St desde la linea de comandos: es también otra cosa que parece boba y que en VisualWorks y Squeak se puede hacer con paquetes adicionales. Las diferencia: no hay que configurar imágenes especiales para eso y como gst es un paquete instalable en la mayoría de los linux basados en Debian, lo convierte en una buena alternativa como lenguaje de shell scripting.

Es por eso que mientras escribo esto estoy bajando Xubuntu para usarlo con VMWare y probar gst (desinstale la partición de Linux que tenia por que la mayoría de las veces uso la PC con programas que solo funcionan en windows). Creo que hay un paquete de gst para Cygwin... pero no me gusta Cygwin (para mi usar directamente un unix es mucho mejor que lidiar con el engendro mutante de cygwin). En fin en cuanto tenga tiempo de probar gst voy a actualizar el blog con algunos comentarios.

Sitios sobre visualización y diseño web

Me interesa mucho el diseño de interfaces, la visualización de información y el diseño en general. Por lo que suelo navegar en busca de artículos y páginas sobre estos temas. Y en ese webeo encontré dos paginas que me resultaron muy interesantes y quería publicarlas en el blog:

• Stamen es una consultora de diseño que se dedica a la visualización de información, probando ciertas visualizaciones beta que estan haciendo para Digg.com, llegue a esta otra pagina:
• Smashing Magazine un blog de diseño web muy bueno, el contenido es de muy buena calidad

Esto no es una pipa

"La traición de las imágenes" - René Magritte La escritura dice en francés: "Esto no es una pipa"

Había visto este cuadro de Magritte en algún que otro libro o pagina web, pero dado que no sé francés nunca le preste atención. Hasta hace poco, cuando lei sobre él en libro "Understanding comics" de Scott McCloud. En su libro Scott utiliza este cuadro como punto de partida para hablar sobre las caricaturas como abstracción de la realidad. Lo que más me atrae del cuadro es que mediante una imagen y unas pocas palabras logra transmitir un concepto complejo acerca de los símbolos. Magritte pone al descubierto en un mismo cuadro la triada de la teoría de Pierce:

• Objeto (el concepto de la pipa, el concepto las imágenes como representación)
• Representación (el dibujo y la oración)
• Interprete (si uno no sabe francés puede interpretar el cuadro como otro dibujito sobre una pipa... tal como me había pasado a mi).

Creo que es bueno tener esta idea presente cuando uno crea abstracciones, ya sea en una caricatura o en el desarrollo de un sistema:

nil "Esto no es la nada"

Painter X

Estuve probando la nueva versión del Corel Painter, buenisimo! Para los que les guste dibujar con la máquina, este programa y el Photoshop no pueden faltar. Eso si... sin una tablet el Painter no dice mucho que digamos. Je! El párrafo anterior parece sacado de una publicidad, para revindicarme algunos links sobre Matte Painting:

• Carbonmatter
• Sparth
• Jessy Veilleux

JavaFX: ¿en bolas?

"-¡Qué preciosos son los vestidos nuevos del Emperador! ¡Qué magnífica cola! ¡Qué hermoso es todo! Nadie permitía que los demás se diesen cuenta de que nada veía, para no ser tenido por incapaz en su cargo o por estúpido. Ningún traje del Monarca había tenido tanto éxito como aquél. -¡Pero si no lleva nada! -exclamó de pronto un niño."

Fragmento de un cuento infantil

En mayo de este año Sun anuncio un nuevo producto llamado JavaFX y algunos vieron en este anuncio a un nuevo contendiente en la arena de las aplicaciones web "ricas" (lease AJAX, Flash y ahora Silverlight y Adobe AIR - aka Apollo). En su momento le pegue una mirada a las paginas de JavaFX, pero a parte de un nuevo (y feo) lenguaje de scripting, no vi nada interesante. Pasaron ya algunos meses del anuncio y dado que hace algunos días Microsoft anuncio la versión para Linux de Silverlight, decidi ver que onda con JavaFX, quizas mi primer impresion no fue correcta. Now you see it.. El framework (segun el FAQ de JavaFX) esta dividido en dos partes: JavaFX Script y JavaFX Mobile. JavaFX Script es un nuevo lenguaje de scripting con facilidades para declarar componentes gráficos. Y JavaFX Mobile... bueno según el FAQ va a ser una platarforma basada en Java para utilizar en diferentes dispositivos. ...now you don't Viendo los ejemplos, lo que encuentro es:

• Un nuevo lenguaje de script que es un engendro (no es Java ni JavaScript, se parece... pero no) y ayuda en la creación de interfaces Swing.
• No vi en ningún lado información sobre JavaFX Mobile... eh momento eso no es Java ME?
• No hay un editor estilo Flash, ni tampoco facilidades para definir animaciones o hacer streaming.

Lo que no entiendo es por que no usaron directamente JavaScript, al menos a los desarrolladores web les hubiese resultado mas familiar y las librerías necesarias ya vienen con el JDK6. Me da la impresión de que el anuncio de Sun fue solo para crear un poco de efectos de humo. En fin para los que quieran ver si JavaFX esta en bolas: JavaFX Demo Update: Por algunos comentarios que lei en la web parece que el lanzamiento de JavaFX a principio de este año fue bastante apresurado para disipar un poco el lanzamiento de Silverlight. Any way, en este blog de uno de los desarrolladores de JavaFX hay informacion sobre cual es la intencion de esta "familia" de herramientas.

Back to blogging

Bueno luego de mantenerme en "silencio" (silencio de blog claro... por que después hablo hasta por los codos), vuelvo a "postear". La razón del "silencio"... En lo poco que va del año estuve muy ocupado. Hoy es mi ultimo día en Mercap, y comienzo abril dedicándome a un proyecto personal: con mi amigo y socio Nico (aka. Sr.Dipi) estamos formando una "consultora de capacitación" (esa fue la denominación que nosotros le pusimos). Asi que es probable que este blog pase a tener anotaciones un poco más "personales". Los posts sobre objetos, programación y computadoras van a estar en el blog de la consultora... que ya tiene nombre pero lo voy a publicar cuando tengamos lista la primer versión del sitio (calculo que esto va a ocurrir a mediados de Abril).