Tiene problemas para leer el newsletter?
Get social... get serious
noviembre 2015
U8 promueve el desarrollo social, entendiendo este como la actividad interpersonal que estimule el autodesarrollo y posibilite un cambio positivo en los individuos y las relaciones entre estos. Promover este desarrollo además, insta un cambio cualitativo en las personas para una mejor realización de sus objetivos y aspiraciones. Un movimiento ascendente a mayores niveles de energía, conciencia, complejidad, calidad, creatividad, disfrute.
Las redes sociales puede ser confundido con el término “desarrollo social” sin embargo este ultimo trata de la actividad individual e interpersonal y su trayecto en el tiempo. Con foco en el individuo, y no en el medio de interacción.
Así U8 propone el desarrollo profesional/personal en conjunto con otros desarrolladores compartiendo actividades y objetivos que, a lo largo del tiempo y como efecto secundario, resulte en un objeto tecnológico. El uso de este resultado es libre por parte de cada uno (en conjunto o por separado) pero con la necesidad de adjudicarle una valoración real. Así es como el bitcoin es usado como recurso de intercambio para promover nuevos desarrollos o nuevas características a desarrollos existentes.
U8 no solo es para desarrolladores sino también para usuarios de tecnología. Las personas interesadas en nuevas características también pueden promover el desarrollo con el intercambio de bitcoins. El receptor de las donaciones podrá saber quien donó, permitiendo así (es el anhelo de U8) una relación sustentable entre las personas.-
Alejandro Reimondo fundador de Smalltalking y creador de S8/U8 nos cuenta acerda de la plataforma COCO8.
Podrías contarnos un poco lo que hay en la contribución COCO8 y cómo funciona. La contribución contiene los fuentes de la aplicación coco8, una aplicación para iOS, "market compatible" y en constante desarrollo.
Los fuentes incluyen todo lo necesario para armar la aplicación y es útil como punto de partida para quienes desarrollan para iOS y OSX usando S8 Smalltalk.
Con todo el furor de desarrollos HTML5 y todo lo que hay hecho, por qué volver a lo nativo? No es volver, es sumar.
Desde Smalltalking siempre alentamos el uso de TO (con Smalltalk) en ámbitos diversos, sin fronteras. Con S8 tenemos un soporte de ejecución para una gran variedad de hardware y sistemas operativos; el desarrollo de aplicaciones nativas no es límite para usar S8. Quien necesite sacarle provecho a esta forma de ejecutar sus objetos, tiene en S8 un smalltalk moderno, con que trabajar y expandir sus posibilidades de ejecución/negocios/etc.
Para usar COCO8 es necesario implementar algo en Objective-C o se puede desarrollar integramente en S8? El 100% de la aplicación puede ser implementada en S8 Smalltalk. En el caso de tener desarrolladas algunas partes en Objective-C y/o javascript (por ejemplo, librerías, etc) uno las puede usar a bajo costo escribiendo la interfaz TOTALMENTE en S8 smalltalk. El sistema (smalltalk) puede arrancar con un contenido mínimo, y luego cargar dinamicamente (bajo demanda) contenidos y comportamiento desde recursos externos (memoria, internet, bases de datos, etc). COCO8 además funciona como servidor e implementa servicios de upload (al teléfono), por lo que la totalidad del sistema puede modificarse subiendo contenido al teléfono mismo, los que pueden accederse al instante por COCO8 o en el próximo arranque (por ejemplo, el image del sistema y recursos pueden subirse a COCO8 en el teléfono/tablet y arrancar con un comportamiento totalmente distinto del original).
El sistema original de COCO8 puede modificarse (contiene un set de herramientas U8) y grabar el image, de forma tal que en la próxima ejecución arranque considerando ese nuevo image. Como en todo smalltalk, las herramientas (workspace, browsers, referencias, app/module loaders) estan totalmente escritas en S8 Smalltalk, siendo de un inmenso valor didáctico.
Desde S8 podemos acceder a javascript. Es posible ver las clases que están del lado de Objective-C, cómo funciona? Si, todas las clases de Objective-C que esten en el sistema se pueden usar (recomendable que sea mediante wrappers con API builders[*]) y además se pueden subclasificar (crear subclases totalmente implementadas en S8). Se puede acceder a los niveles: javascript, en forma completa a todas las librerias que puede el sistema tener y/o cargar dinámicamente. Objective-C se puede acceder via wrappers con API builders y de forma inline -usando sintaxis extendida de S8-. C, se puede acceder a funciones y estructuras implementadas en C de forma dinámica.
En resumen, escribiendo todo en S8 Smalltalk uno puede acceder a todo elemento del sistema y puede cambiarlo/subclasificarlo/refinarlo donde está permitido hacerlo por Apple.
[*] los API builders son parte del framework de NativeObject, un framework muy poderoso y único de S8, que permite acceder a todos los niveles inferiores de forma simple y reduciendo eficientemente el margen de errores humanos.
Esto quiere decir que con COCO8 se puede subclasificar un elemento gráfico como por ejemplo un panel de texto? O definir un widget nuevo? La ejecución es en S8 y en Objetive-C? Si, cualquier clase; sea gráfica como de cualquier framework y/o librería que esté presente en el sistema y accesible en Objective-C (y/o C). El ejemplo de Polygon en COCO8 es justamente eso. Un panel gráfico implementado integramente en S8; tanto en el dibujado como en el manejo de la interacción por touch. Todo lo estático en el sistema esta relacionado con Objective-C (Apple no permite generar métodos/funciones dinámicamente en Objective-C). Todo lo dinámico y abierto del sistema es S8 Smalltalk. En consonancia con el diseño e historia, tanto de Objective-C como de Smalltalk.
Hay alguna consideración especial en usar COCO8 en iOS o en OSX? El desarrollo sobre COCO8 es igual en las dos plataformas? Ambas plataformas tienen una interfaz idéntica al sistema operativo. Las diferencias son diferencias entre los sistemas operativos y librerías que estén ejecutando.
En COCO8 es exactamente el mismo esquema de desarrollo. La API de Apple para una y otra plataforma es lo que determina las diferencias e incapacidad de usar el mismo código (los mismos objetos); en muchos casos los mensajes y nombres de clases son similares pero con semánticas distintas; lo que hace recomendable mantener desacoplado el sistema de las dependencias de base; por la incapacidad de reusarlas y porque además (y mas importante) el alto nivel de obsolescencia prematura que sufren las interfaces en estos S.O. (comparado con lo que se produce frecuentemente con smalltalk).
Las interfaces UI, por lo general cambian antes de que sean usadas mucho tiempo. Es un caso frecuente (en todo lo formulado como OO) que las cosas se "digan viejas" cuando aún no llegan a tener cinco años... y como para ser experto en cualquier área, una persona requiere de al menos 10 años de dedicación efectiva, se dá que las UIs (y otras cosas como los lenguajes) solo llegan a los anuncios y tener el beneficio de la propaganda como instrumentos de propagación en quienes necesitan de algo nuevo. En el caso de smalltalk, la UI (y la forma de hacerla) prevalece por décadas y no ha sido muy frecuente la presión de gente que utiliza el propagandismo para inyectar la idea de cambios efímeros (son pocos los modos de construcción de UI que han sido propuestos; algunos violando los principios básicos del trabajo con objetos... pero ese es otro tema). Para aquellos que se sientan interesados en estos temas no dejen de consultarnos a través de nuestra lista de discusión.
Cuáles serían los pasos mínimos para arrancar un proyecto COCO8?
Como en todas las modalidades de trabajo con S8, lo recomendable para empezar es utilizar el vinculo social (social software development with smalltalk) y hacer lo que uno hace siempre (doIt yourself con smalltalk):
1.- Leer las páginas del swiki de U8 relacionadas con COCO8
2.- Anotarse en la lista de testers y registrar los dispositivos iOS dónde pueda bajar COCO8 y ejecutarlo
3.- Ponerse en contacto con gente que lo esta usando, preguntar y empezar a desarrollar lo necesario.
Por qué el nombre COCO8? En iOS y OSX los framework de base propuesto por Apple se llaman Cocoa, el 8 es por lo mismo que en S8 (denomina la actividad de construccion de experiencia que utilizamos -smalltalk-).-
Contactando nuevamente a Sergio Garcia Canto (Newsletter Vol.2) le preguntamos acerca de su movimiento hacia el DIY.
Con lo que hay en U8/S8 ¿cómo podes desarrollar como en un Smalltalk tradicional? Tomé parte de las tools que están en U8 y las fui modificando, específicamente la capacidad de browsear código remoto. Es decir en un instante dado tengo N imágenes S8 corriendo en distintos tabs del chrome una con las tools de S8 modificadas y las demás con aplicaciones que quiero ver en funcionamiento, y que pueden ser browseadas a través de CHB (Class Hierarchy Browser) remotos. La tool permite abrir Workspaces o CHB remotos, entonces nos da una serie de opciones direcciones IP (o nombres de nodos en la red) en las cuales hay imágenes S8 que pueden ser exploradas.
¿Las tools de desarrollo son locales? La tool es local en el sentido que corre en un tab de chrome, aunque es servida por un servidor de desarrollo (un nodejs corriendo en el puerto 8080), algo típico para desarrollar. Las imágenes que se quieren explorar remotamente pueden estar en ese servidor de desarrollo o en otro nodo de la red. Sobre la tool cuando pido un CHB “local” estoy explorando la imagen S8 que está corriendo en el Chrome correspondiente a las tools de desarrollo. Si pido un CHB “nodejs ip xxx.xxx.xxx” estoy explorando la imagen que está corriendo en el nodejs.
¿El nodejs que se usa para servir otras imágenes S8 está corriendo una imagen S8? el nodejs ejecutando como otro proceso del S.O. y corriendo una imagen S8 que no es visual, no hay nada relacionado con las tools. Es decir, al browsear la imagen S8 del servidor no tiene la clase S8Tool. Ademas podríamos ver que en la fase de arranque de la imagen S8-servidor-nodejs se cargan un monton de modulos: websocket, http, filesystem, so, mongodb, etc, y posteriormente se lanza un servicio (websocket server) corriendo en el puerto 9060, por donde se rutearán todos los request de las herramientas de desarrollo. Posteriormente se lanza un servicio file server en el puerto 8080. Entonces la forma típica de trabajo es: un browser corriendo una imagen con las tools de desarrollo que se conecta con el nodejs que es el realmente el que guarda las imágenes.
CHB locales y remotos. Desplegando menu para abrir un CHB remoto
¿Es posible hacer un “save” de un método?. Si se puede. Aunque deberíamos hacer un distinción entre cambiar el comportamiento de la imagen y guardar los fuentes en algún archivo. Se hacen las dos cosas pero por separado. Modificar la imagen es algo muy simple pero guardar el fuente es más complejo. Hay que tener en cuenta que lo que tengo desarrollado no son herramientas maduras para producción es algo ad-hoc, aun le falta desarrollo. En el primer caso para modificar el comportamiento de la imagen puedo abrir un Workspace remoto y explorar y modificar los objetos
Operando sobre un Workspace remoto
Y esa exploración cómo funciona. Es similar a un "inspect", pero lo hago via el comando “show it” con un menú contextual de la misma manera en que se opera con los demás Smalltalks. Y modificar la imagen via “do it”. Ese Workspace se está ejecutando en la imagen remota. Cuando la porción de código seleccionado se le hace un “do it” o un “show it”, toma el string que representa código y se envía a la otra imagen, se ejecuta y luego devuelve el string con la respuesta. De esta manera se puede operar sobre una imagen remota. Dicho en otras palabras no se está haciendo nada de manera local, solo se está enviando y recibiendo. Todo por websockets y utilizando el servidor nodejs como intermediario. En un típico escenario estaríamos corriendo dos imágenes en el browser, una con las tools de desarrollo y otra con otra imagen con una aplicación, ambas dos servidas a través del puerto 8080 aunque comunicándose vía otro puerto (en mi caso el 9060) para propósitos de desarrollo. Este mismo esquema también lo tengo funcionando en un dispositivo Android. Con las herramientas de desarrollo, puedo abrir un CHB o un workspace, y me aparecerá, disponible para seleccionar, el nodo Android con el nombre del modelo de dispositivo y su ip. De esta manera se puede abrir un CHB o un Workspace remoto en un S8 dentro de un Android.
Entonces con Android no cambia nada. Las imágenes se intercomunican vía el 9060 con el nodejs como intermediario. Es correcto, es lo mismo, aunque algo interesante también es que varias imágenes de desarrollo con las herramientas remotas pueden estar inspeccionando una misma imagen. Si se publica en la red la imagen con las herramientas remotas y el “servidor intermedio” permitiría que dos personas estén explorando y/o modificando la misma imagen. Esto es posible, aunque no tiene aun ningún mecanismo de control. Falta mucho por desarrollar y formalizar, serian necesarios inspectores y debuggers. Pero lo que tengo hecho fue impulsado por la necesidad.
¿Y el manejo del código fuente? Como comentaba antes, aquí está separado la modificación de la imagen de la acción de guardar el código fuente. En S8 existe el concepto de categoría y hago uso de eso. Si a un string que tiene el nombre de una categoría le envío el mensaje #fileOut, eso se graba en un fileSystem, quien lo hace es el S8 servidor corriendo en nodejs, manteniendo cada imagen como un proyecto. De esta manera todas las fuentes los tengo particionados en categorías. Eventualmente cuando es necesario reconstruir la imagen tengo un build configurado para que se ensamble desde un conjunto de categorías precompiladas. Ademas para tener respaldo a medida que se hacen los cambios, tengo las cosas versionadas de manera de poder simular algo similar (con menos información) a un change.log.-
U8 es un proyecto creado y desarrollado
en el contexto de Smalltalking.
Para más informaciòn visite Smalltalking
en el contexto de Smalltalking.
Para más informaciòn visite Smalltalking