Archive for the '18052' Category

Resoluciones del Nuevo Mes: Julio 2014

Wednesday, July 9th, 2014

Un nuevo mes comenzó, tiempo de revisar mis resoluciones de Junio 2014, y escribir las nuevas:

– Continuar AjErl [pendiente]
– Continuar ScalaSharp [completo] repo 
– Continuar SharpGo [completo] repo
– Alcance de variables en lenguaje Mass [completo] repo
– Comenzar SimpleItems [pendiente]
– Continuar SimpleApps [partial] repo
– Continuar ClojSharp [pendiente]
– Continuar DictSharp [pendiente]
– Primer caso de uso distribuido de AjErl [pendiente]
– Primer caso de uso distribuido de Aktores [pendiente]
– Escribir C# Posts [completo] Posts
– Escribir TDD Post [completo] Post
– Mejorar el código de mi sitio personal [completo]

También estuve trabajando en:

– Crear y publicar primer versión SimpleCurry, para programación funcional en JavaScript [completo]  repo
– Crear y publicar primer versión LoadJsons, lee un modelo JSON desde varios archivos, para JavaScript/Node [completo]  repo
– Crear un sitio dinámicado, definido por JSON, para Express 4 [completo]  repo
– Generar código para Express 4 usando AjGenesisNode [completo]  repo
– Generar código Sinatra usando AjGenesisNode [completo]  repo
– Mejorar AjGenesisNode, AjGenesisNode-Model, AjGenesisNode-Entity [completo]  repo repo repo
– Continuar DylanSharp [completo]  repo
– Crear SharpBus, un service bus tipo Mule, en C# [completo]  repo

Estas son mis resoluciones para Julio 2014:

– Seguir mejorando la generación de código de AjGenesisNode para Express
– Seguir mejorando la generación de código de AjGenesisNode para Sinatra
– Primer generación de código de AjGenesisNode para Laravel 
– Mejorar la carga de módulos y la exportación de variables/funciones en el lenguaje Mass
– Continuar con SharpBus
– Continuar con Dynamic Site
– Dar una charla sobre Node.js/Express
– Dar una jornada sobre Node.js/Express
– Seguir mejorar el código de mi sitio personal
– Escribir post de TDD
– Escribir posts de C#
– Caso de uso distribuido en Aktores
– Revisar, refactorizar y continuar la implementación de RustScript

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Resoluciones del Nuevo Mes: Junio 2014

Tuesday, June 10th, 2014

Es tiempo de revisar mis resoluciones de Mayo:

– Trabajr en SimpleScraper, primeros casos de uso [completo] ver repo
– Continuar RuScript [pendiente]
– Continuar RustScript [parcial] ver repo
– Continuar SharpGo [completo] ver repo
– Continuar Distributed Messages in AjErl [pendiente]
– Mejorar Mass Language [pendiente]
– Continuar Aktores (implementar distribución de mensajes) [pendiente]

Adicionalmente, estuve trabajando en:

– Continuar ScalaSharp [completo] ver repo
– Comenzar SimpleApps, mi refinamiento de MyApps [completo] ver repo
– Continuar ClojSharp [completo] ver repo

Mis resoluciones para este nuevo mes, Junio de 2014:

– Continuar AjErl
– Continuar ScalaSharp
– Continuar SharpGo
– Poner alcance de variable en el lenguaje Mass
– Comenzar SimpleItems
– Continuar SimpleApps
– Continuar ClojSharp
– Continuar DictSharp
– Primer caso de uso distribuido en AjErl
– Primer caso de uso distribuido de Aktores
– Escribir Posts de C#
– Escribir Post de TDD
– Mejorar mi sitio personal

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Rearmando Smalltalk (Smalltalk from Scratch)

Thursday, May 1st, 2014

Pienso que Smalltalk es una tecnología maravillosa que ha influenciado la programación durante las pasadas décadas. Pero no directamente: su influencia mayor no ha sido a través de uso o de aparición de “killer apps” sobre Smalltalk. Lo que veo que ha pasado es que Smalltalk influenció a programadores. La marca de las ideas de Smalltalk se pueden rastrear en las decisiones de diseño de lenguajes como Python y Ruby. Y muchos programadores se han visto atraídos por las ideas de Smalltalk, trantándolas de aplicar a otros ámbitos. Pero Smalltalk, como tecnología, no ha tomando al mundo. Podemos discutir las razones: una temprana “balcanización” de los proveedores, la falta de una temprana implementación de código abierto. Mi postura: está muy ligado a su propia “GUI IDE”, y es un poco demasiado (tiene demasiadas piezas).

Pienso que es tiempo de explorar caminos alternativos. Durante años, visité tecnologías, lenguajes, y en la pasada década y media (más o menos), tomé de nuevo a Smalltalk, intentando encontrar uno de esos caminos alternativos.

Pienso que un camino a explorar es intentar armar un Smalltalk más simple. Un Smalltalk no tanto ligado a una GUI ID, no ligado a miles de clases. Me imagino una implementación simple que pueda acceder al resto de los avances de programación (como el ecosistema de Node.js).

Para poner manos en la masa, estuve armando tres implementaciones: Smalltalk sobre .NET, en Java y en los últimos tres años en JavaScript/Node.js:

https://github.com/ajlopez/AjTalk
https://github.com/ajlopez/AjTalkJava
https://github.com/ajlopez/AjTalkJs

Más información en posts en http://ajlopez.wordpress.com/category/smalltalk/ y en http://msmvps.com/blogs/lopez/archive/tags/Smalltalk/default.aspx

Pero este post no es para repasar esas implementaciones. Lo que quisiera es pasar en limpio, escribir sobre algunas ideas sobre cómo crear un Smalltalk, sin tener que pasar por el achicamiento de imágenes de uno ya existente.

El Núcleo

Pienso que se puede armar un nuevo Smalltalk, desde un núcleo mínimo. Para eso, podemos partir de un Smalltalk que ejecute albergado por otra tecnología, como puede ser .NET, Java, o JavaScript, o cualquier otra. Pero es hora te dener un Smalltalk que no sea tan aislado, que converse con un ecosistema: tiene que apalancar lo logrado en otros ámbitos. Por ejemplo, un Smalltalk ejecutando sobre JavaScript puede acceder a todo el ecosistema de ese lenguaje, o al ecosistema de Node.js si estamos trabajando en el servidor.

El núcleo de Smalltalk debería implementar:

Object: el objeto y clase base, con algunos métodos iniciales como #subclass:.

Array: para arreglos con acceso por índice numérico, comenzando desde 1 para no romper con la tradición Smalltalk.

Dictionary: para mapear claves (nombres) a valores.

Tipos Primitivos: para acceder a la tecnología albergadora (.NET, Java, JavaScript), a sus tipos primitivos.

Aceso a tipos y objetos nativos: para crearlos, llamar sus métodos de tipo y de instancia.

La Librería

Primero, una implementación mínima de algunas clases, que pueden ser empaquetadas en una implementación inicial.

Pero luego, viene algo importante: tratar de vivir en un ecosistema de paquetes. En vez de tener centenares o miles de clases, que cada aplicación pueda referenciar y obtener los paquetes de un ecosistema. En mis implementaciones, he tomado el camino de usar NPM (Node Package Manager) para publicar y consumir paquetes, para instalarlos por aplicación, aún usando las versiones específicas que necesite cada aplicación y paquete.

Algunos candidatos a paquetes, como ejemplo:

– Una librería de tests (con un método assert)
– Un servidor HTTP
– Un framework MVC (tengo un ejemplo en Smalltalk sobre JavaScript/Node.js usando Express)
– Mensajes distribuidos (tengo una implementación en C#, el objetivo de este año es tener algo similar en JavaScript/Node.js)
– etc.

De esta manera, la adopción de un paquete será más fácil: no se necesita portar un paquete a otro dialecto, sólo consumirlo, teniendo las dependencias en su lugar. Para eso, cada paquete describe las dependencias que necesita.

Items Adicionales

Quiero implementar ambientes/environments: cada clase o paquete puede cargar otras clases pero para uso interno, sin interferir con el ambiente Smalltalk global, previniendo colisión de clases y versiones.

Otra cosa que quiero es poder ejecutar más de una imagen al mismo tiempo. Y que una imagen ayude a otra. Por ejemplo, que una imagen chica pueda ir agregando métodos a sus clases, pero los métodos de compilación los encuentre en otra imagen. De esta forma, una imagen puede comenzar chica, de poco tamaño, siendo ayudada por otra para ir creciendo e implementando los casos de uso que necesita. De esta forma, nos evitamos tener que partir de una imagen grande, e ir reduciédola. Tengo una implementación de estas ideas en mi versión de Smalltalk en C#.

En algunas implementaciones, quiero una imagen (para leer y grabar). Pero primero puedo explorar hasta donde llegar sin tener la necesidad de persistir una imagen.

Cualquier GUI debería ser creada fuera del núcleo, tal vez usando el ambiente albergador. Por ejemplo, usar Windows.Form si estamos sobre .NET o Mono, o Swing o SWT si estamos en Java, o el notable Canvas en caso de HTML5/JavaScript. Pero la idea es que el manejo de la GUI tiene que estar claramente separado de la implementación núcleo. Los Smalltalk populares actuales están muy ligados a la GUI que contienen en toda imagen. Veamos otras tecnologías: Python, Ruby, Node.js, Go, etc… Hay multitud de ellas que avanzaron sin estar ligadas a una GUI y a una IDE. Y sus programadores siguien creando aplicaciones útiles.

Como siempre digo: hay que explorar. Ese es el verbo a usar. Tenemos que explorar caminos alternativos, aún cuando no queden en claro la ganancia a obtener. Si hubiera visto, a esta altura, alguna “killer app” en Smalltalk, o el uso de Smalltalk para la creación de aplicaciones (como pasa en Python, Ruby, Java, JavaScript, Node.js, .NET, y otros), yo no pensaría de esa forma. Pero por alguna razón, Smalltalk no llegó a ese estadío. Veo entonces que hay alternativas, flotando alrededor nuestro, listas para ser exploradas.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Aplicaciones Creando Aplicaciones

Monday, April 28th, 2014

En todos estos años, he estado trabajando en diferentes aproximaciones para hacer que programas creen programas. Este post es un resumen y revisión de los caminos que he tomado, y en los que sigo trabajando, como un Work in Progress. Pienso que hay maneras interesantes de hacer programación, listas para ser exploradas.

Aplicaciones Dinámicas

Algo que hace unos años no hubiera encarado. Pero la ductilidad que da JavaScript me trae de nuevo a esta idea. Todo se basa en describir una aplicación (entidades, relaciones, vistas, código), y ejecutarla en un programa especializado (generalmente en páginas web) que conozca cómo interpretar y ejecutar la definición de la aplicación. Escribí una demo de la idea para la competición Knockout del año pasado:

Más información en mi post Aplicaciones Dinámicas en Node.js.

[View:http://www.youtube.com/watch?v=GQdyyNWCasI]

La aplicación pudo ser descripta usando una simple estructura: en este ejemplo, es un objeto JavaScript sencillo que puede ser serializado a JSON. La misma estructura puede ser interpretada por diferentes programas “host”: una aplicación web (la demo de arriba), o una aplicación web SPA (de Single Page Application), una aplicación mobile (Phonegap o nativa). Y hasta podría usarla como base para generar código en una tecnología concreta, como Sinatra, PHP, Express+Node.js+MongoDB, etc.

Generación de Código

Ya saben, uno de mis temas preferidos. He estado creando tareas, plantillas y modelos de libre definición para generar aplicaciones en Express/Node.js y en otras tecnologías (Sinatra, Django, Flask, PHP, todo Work in progress). Tengo implementaciones de mi herramienta de generación de código en C#, Ruby y Node.js. Pero mis últimos trabajos usan la de Node.js:

https://github.com/ajlopez/AjGenesisNode

Pueden ver un ejemplo en:

https://github.com/ajlopez/AjGenesisNode-Express

Una aplicación generada:

 

Estoy trabajando en crear un sitio en línea donde cualquiera pueda definir el modelo, y elegir una serie de opciones de tecnología. El sitio generaría código, listo para bajarse en un .zip.

Tarjetas

En el proyecto:

https://github.com/ajlopez/SimpleCards

Describo cada aplicación como un conjunto de “cards” (o sea, tarjetas, en un “deck”, mazo). Una tarjeta puede tener valores simples, o un valor que sea a su vez una tarjeta o un mazo de tarjetas. Por ejemplo, una tarjeta puede tener un id, un nombre, un título como valores simples, e información adicional, otros valores. Una tarjeta puede tener un valor que a su vez sea un mazo de tarjetas (por ejemplo, una tarjeta de Elementos Químicos, puede tener un mazo de tarjetas, una por cada elemento químico a describir). Cada tarjeta/mazo puede ser mostrado en diferentes contextos: desde una aplicación web, una SPA, una aplicación móvil (podría implementarse para PhoneGap o para nativo). Una cosa es la estructura y contenido de una tarjeta, y otra es el mostrar la tarjeta. Esto de mostrar depende del contexto de la aplicación que alberga las tarjetas.

Un ejemplo simple

https://github.com/ajlopez/SimpleCards/blob/master/samples/deck/js/model.js

var model = {
    title: "My Deck",
   
    cards: [
        { title: "Card 1", text: "This is the card 1" },
        { title: "Card 2", text: "This is the card 2" },
        { title: "Card 3", text: "This is the card 3" }
    ]
}

Otro ejemplo, con pantallas:

https://github.com/ajlopez/SimpleCards

El contenido de un tarjeta pueden ser valores con texto simple, texto largo, una URL, la URL a una imagen, o la descripción de algún componente especializado a ser mostrado (por ejemplo, un Google Maps). La descripción de la tarjeta y su contenido puede ser estático o puede ser generado en el momento. Por ejemplo, podría implementar leer un “feed” y transformarlo en un mazo de tarjetas. O podría recuperar la descripción de un mazo o una tarjeta desde una API REST. Una tarjeta puede tener algunos valores parciales (por ejemplo, id, título), para ser mostrado en el mazo, y cuando uno entra y quiere ver la tarjeta completa, un componente adicional puede RESOLVER la tarjeta y conseguir los datos adicionales, por ejemplo usando su id. Un ejemplo: una tarjeta tiene título y id. El id es la URL de la página en la Wikipedia. Cuando una tarjeta necesita ser vista, el programa adicional toma el id, y resuelve la tarjeta, bajando el contenido de la página, extrayendo texto, enlaces relacionados, imágenes.

Mucho para hacer, y muy interesante.

Nos leemos!

Angel “Java” Lopez

http://www.ajlopez.com

http://twitter.com/ajlopez

La Desaparición de la Programación

Sunday, April 20th, 2014

Hace unos meses, escribí:

El Futuro de la Programación

Donde enumeraba unos puntos a considerar y a resolver sobre lo que nos espera en el futuro. Muchos de nosotros tenemos la programación como profesión, y además nos fascina. Pero ademas de lo que nos puede gustar, tenemos que ver cuál es el impacto en la sociedad y en la historia humana.

Para mí, el desarrollo de software apalanca gran parte de las actividades humanas. Recordemos lo que era el diseño en arquitectura hace unas décadas, o lo que era comunicarse con otra persona usando solamente un teléfono. O intercambiar trabajos por correo físico. Lo que ha influido el desarrollo de software en todo esto, es grandísimo. En algún milenio que viene, verán a la prehistoria humana como la época donde no había información digitalizada ni software ni hardware. Tanto la información como su proceso, se han incrementado en varios órdenes en los últimos tiempos (tendría que revisar el final de “La conexión cósmica” donde Carl Sagan clasifica las civilizaciones por la cantidad de datos?/información? que producen y manejan).

Es por eso que es importante (no solamente interesante) plantearse esas cuestiones, y preguntar también por el futuro de nuestra profesión. No para hacer lo que nos gusta, sino para ver en qué forma podemos contribuir a que todos estos cambios sean para mejor. Por eso planteaba varios de los puntos de ese post, y uno era:

– Desaparición: ¿cuándo desaparecerá la programación?

Pienso que tenemos que explorar el camino: hacer desaparecer la necesidad de nuestra profesión. No creo que desaparezca, pero es un buen ejercicio ver qué se puede hacer para que el desarrollo de software no sufra la falta de programadores, y hacerla crecer (¿quizás apalancada con software más “inteligente”?)

En una lista de correo, alguien planteó que esto es “una falta de respeto” a la profesión. Bueno, estuve meditando, y no encuentro falta de respeto en mi postura. Es como quejarse de falta de respeto a los cirujanos porque alguien invente curar la apendicitis con una pastilla. O de falta de respeto a los dibujantes técnicos ante la aparición del Autocad. Todo cambia en las actividades humanas, y tenemos que explorar (noten el verbo, explorar) ese camino: ver cómo podemos acercarnos a la desaparición de la profesión. Como puse antes, no pienso que desaparezca, sino que cambie, y veo que tenemos una ventana de oportunidad para mejorar y conseguir más con menos. Si menciono lo de la lista de correo, es porque me asombra que se pueda interpretar de esa forma lo que escribo. Por favor, que nadie lo tome así. Recuerden el objetivo: mejorar en lo que podemos aportar a las actividades humanas, más allá de la profesión o de lo que nos guste hacer. Si podemos aportar más, con menos, creando agentes u otras formas de escribir software, o haciendo la programación más fácil, ¿por qué no hacerlo?

Yo respeto mucho a las tecnologías que han podido hacer que más personas tengan acceso a hacer cosas. En el ámbito de la programación,  podría poner como ejemplo a Ruby on Rails: claro que por abajo es un código enrevesado, inflado, con cosas demás o que podrían mejorarse mucho. Pero ese no es el punto principal. El punto es que ese código (“horrible” si quieren verlo) ha posibilitado la creación de más software, y no me queda duda que ha sido para mejorar. Tomemos PHP: ¿quién no ha criticado a PHP como lenguaje? ¿cuánto tardó para tener una implementación de objetos aceptable, y namespaces? Sin embargo, ahí está PHP alimentando a WordPress, Facebook y otros sitios. Rasmus Lerdorf y otros, con PHP, cambiaron la historia humana. En estos ejemplos, pienso que es importante separar lo que nos gustaría que fuera en lo técnico (mejores clases en Rails, con mayor separación de “concerns”; mejor implementación básica de PHP; etc…), de lo que realmente son: grandes herramientas que han hecho posible tantas cosas.

En estos últimos años me he ido alejando de la posición de “ingeniero de software”, deteniéndome en todos los detalles técnicos que podría mejorarse en una implementación, o declamando sobre todos los patrones y “mejores prácticas” que tenemos “casi la obligación” de aplicar, porque si no, lo que hagamos será “poco profesional”. Lo que me importa al final del camino: el valor que una herramienta puede aportar (y el costo de conseguir ese valor).

But I digress… Volvamos a la “desaparación” de la profesión y a la generación del software.

Los que me leen (digamos yo y mi tía Carlota ;-), saben cuál es el camino que quiero explorar en eso que planteo más arriba: la aplicación de la inteligencia artifical a la creación de software (perdón, de nuevo, ¿es “falta de respeto” a los jugadores de ajedrez la creación de un Deep Blue que le gane a Kasparov? para poner otro ejemplo).

El otro camino: hacer que la programación esté al alcance de gente que no es profesional del tema. Habrá que discutir cuál es la forma para esto: ¿mejores lenguajes? ¿formas visuales de programar? ¿ecosistemas de pequeños módulos que interactúen por Internet, y que cada uno pueda sumar su módulo? ¿”application stores” que puedan ser llenadas por aplicaciones generadas por no programadores? Hay mucho para investigar en este tema.

Pero, como decía Perón: “mejor que hablar es hacer, mejor que prometer es realizar” (bien, ya veo que con mi suerte para ser interpretado, esta frase va a tener derivaciones políticas ;-). Si ven lo que escribo cada día, en código o en posts, casi siempre toca alguno de los caminos mencionados arriba: o hacer programas que creen programas, o hacer que la programación esté al alcance de más personas, sean programadores profesionales o no. Todo dentro de lo que puedo ver, pensar y hacer.

Los invito a pensar sobre estos temas, y también a hacer. Por ejemplo: ¿es importante este tema, el futuro de la programación y “luchar por su desaparición”? ¿o realmente el futuro será el que diga que hacer? ¿hay que acercar la programación a más gente? ¿o es mejor cultivar la profesión y mejorar como profesionales? ¿es un “o” exclusivo? Y ante la respuesta que pueda encontrar cada uno, hacer algo para acercarse a ella.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Always Be Coding

Tuesday, April 8th, 2014

Como profesionales del desarrollo de software, debemos perseguir ser cada vez mejores programadores. Una actividad que he adoptado en los últimos años, es: “Always Be Coding”, siempre estar programando. Cada día, escribir una pieza de código. Intentar algo nuevo. Mejorar lo viejo. Abrir el cerebro. Explorar nuevos caminos. Escribir un nuevo lenguaje. Practicar TDD cada día. Empujar por la simplicidad. Comenzar un simple proyecto “Hello world” usando un nuevo lenguaje, tecnología, sistema operativo. Escribir un simple sitio web usando el nuevo framework de moda. Si escribimos en C# o Java, intentar Ruby o Clojure. Si usamos Ruby on Rails, pasar aunque sea a intentar Sinatra, o hacer un cambio a Python con Django. Si nos gusta Lisp, ver de usar ClojureScript en un proyecto web. Si nos gusta Smalltalk, probar Pharo con Seaside. Si somos “geek” de los lenguajes de programación, ir por Rust, Go, Dart. Si escribimos ASP.NET MVC en nuestro trabajo diario, probar SignalR, entonces cambiar a Node.js y Socket.IO. Cambiemos de editor. Cambiemos de lenguaje de programación. O escribamos uno nuevo.

Aún cuando todos estos lenguajes, tecnologías, librerías, frameworks, no estén en lo que hacemos diaramente en el trabajo usual, lo que aprendemos por explorar algo nuevo es bienvenido. Y la práctica constante hace al maestro. Si mantenemos el cerebro abierto, nuevas ideas podrían fertilizar nuestra mente y agregar algo a nuestra caja de herramientas/habilidades. En nuestra profesión, lo único constante es el cambio. Aunque hay otros temas para practicar, como habilidades “blandas”, trabajo en equipo, también debemos (yo y uds) practicar cada día las habilidades más duras, y perserguir el “craftmanship”.

Así, para poner el dinero donde pongo la boca, cada día escribo una pieza de código, en repositorios públicos y no públicos. Evidencia parcial:

Van a ver que también dejo evidencia en la historia de “commits” de mi flujo de trabajo usando TDD.

Ese es mi compromiso público: escribir código cada día. Para aprender algo nuevo, practicar alguna habilidad, explorar nuevas formas de hacer algo. “Always be coding”!

Foto orignal de http://atechnologyjobisnoexcuse.com/2012/04/coffees-for-coders/

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Resoluciones del Nuevo Mes: Marzo 2014

Sunday, March 9th, 2014

Primero, revisión de mis Resoluciones de Febrero:

– Completar mensajería distribuida en AjErl [parcial] ver repo
– Completar dot notation in AjLisp [pendiente]
– Mejorar ClojSharp [completo] ver repo
– Trabajar en ScaScript [parcial] ver repo
– Trabajar en ScalaSharp [completo] ver repo
– Agregar alcance de variable a Mass [pendiente]
– Completar primera versión de Aktores, actor model en C# [pendiente]
– Más tareas de generación de código, plantillas, modelos, para AjGenesis para Node, generando Express, Meteor, Sinatra y otro tipo de aplicaciones [parcial] ver repo

Para compensar lo faltante, estuve trabajando en:

– Crear Annalisa [completo] ver repo with online web services and demo
– Comenzar SimpleAsync [completo] ver repo
– Crear mis primeros ejemplos en Meteor [completo] ver repo
– Comenzar Templie, una simple template engine en Java [completo] ver repo
– Comenzar SimpleScraper, un simple scraper en JavaScript/Node.js [completo] ver repo

E hice algunas mejoras en DylanSharp

Resoluciones del nuevo mes:

– Trabajar en DictSharp
– Dar una charla sobre Node.js y Aplicaciones Distribuidas
– Mejorar SimpleGammon
– Mejorar Annalisa
– Agregar @for a Templie
– Trabajar en PreciosaAnnalisa online web services
– Mejorar mis ejemplos de aplicaciones distribuidas en Node.js
– Trabajar en ScalaSharp
– Mejorar ClojSharp
– Mejorar SimpleAsync, agregar do operation (funciones en paralelo)
– Mejorar Aktores
– Mensajes distribuidos en AjErl
– Agregar alcance de variables al lenguaje Mass
– Comenzar un ejemplo de code generation as a service

Mucho para divertirse!

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Make It Work, Make It Right, Make It Fast

Sunday, February 23rd, 2014

Hace unos años, me topé con esta frase aplicada al desarrollo de
software:

”Make It Work, Make It Right, Make It Fast”

Es decir, algo como:

“Primero que funcione, luego hacerlo bien, luego hacerlo rápido”

No recuerdo la fuente original. Frecuentemente se la atribuye a Kent Beck,
pero parece que hay precedentes, ver:

http://c2.com/cgi/wiki?MakeItWorkMakeItRightMakeItFast

En la última década, comencé a comprender la aplicación de estos consejos, y
realmente pienzo que mis habilidades de desarrollo de software se vieron
mejoradas por adoptar esta manera de hacer las cosas. Podría asociar los dos
primeros pasos con TDD (Test-Driven Development), pero se puede emplear la frase
en contextos más amplios. Revisemos que pienso de cada parte, y cómo las aplico
cada día.

Make It Work

Sí, en vez de intentar hacer “LO CORRECTO” desde el vamos, pongo primero mi
esfuerzo en hacer algo que funcione (una función, un método, un rama de un caso
de uso, una experiencia de usuario). No me preocupo por si la implementación
interna es la mejor, ni trato de aplicar todos los patrones del libro. Escribo
código que funciona. Simple código, y que funciona. Siguiendo esta
recomendación, veo que escribo código simple, que me permite ir comprendiendo el
dominio del problema. Si lo que tengo que estregar es una rama de un caso de uso
(no un caso de uso completo), el entregable puede que arroje luz sobre el modelo
de negocios del dominio, y aún permite una retroalimentación temprana de parte
de los usuarios de la aplicación.

Sin embargo, si hubiera intentado desde el vamos hacer “lo correcto”, podría
haber perdido mi tiempo y esfuerzo en algo que no es seguro que es lo que el
sistema y los usuarios necesitan.

Como caso especial de aplicación de esta máxima: “make it work” es una parte
esencial de TDD, el segundo paso: hacer que el test pase a verde.

Make It Right

Solamente cuando ya tengo algo de código andando como quiero, vuelvo a él y
lo mejore. Puedo remover duplicación de código, aplicar algún patrón porque me
lo pide el contexto (evito aplicar un patrón solamente por un impulso
irresistible de “patronitis”), exploro nuevas implementaciones alternativas.
Esta es la oportunidad de remover o hacer decrecer cualquier dueda técnica que
haya quedado, cualquier reliquia de código tóxico. Si veo algo que está
implementado de forma extraña, voy y lo trato de reescribir mejor.

Cuando lo que escribo lo escribo siguiendo el flujo de trabajo de TDD, aplico
este consejo en el paso de refactoreo. TDD me ayuda a controlar el nivel de
deuda técnica, manteniéndolo a un nivel bajo. Y teniendo todo escrito bato
tests, puedo explorar con confianza otras implementaciones alternativas, sin
sufrir en el proceso. Es realmente un paso creativo. Algunos programadores
pinesas que TDD obstruye la creatividad, pero yo veo lo contrario: estos dos
pasos son una forma de ejercitarla.

Make It Fast

Solamente entonces me preocupo de la velocidad de ejecución, y cuando el caso
de uso y contexto lo amerita. Hay tantos factores que pueden influir en el
rendimiento, que sólo me pongo a revisarlo cuando YA tengo una implementación
andando. Si Uds. tienden a escribir código en las anteriores fases, pensando en
“esto lo pongo así, porque de esta manera la ejecución va a ser más rápida”, les
pediría que revisen su actitud. Yo no sé (y Uds. tampoco) si un métod será lo
suficientemente rápido, si no tenemos un claro caso de uso que necesita tal
nivel de velocidad, y sin haber MEDIDO el rendimiento antes de la optimización.
No optimizar lo que no se mide.

Más veces de las que hubiera deseado, me encuentro con proyectos donde se
tomaron decisiones apresuradas pensando en el reandimiento: alguien que agrega
procedimientos almacenados “porque son más rápidos”, pero sin tener evidencia de
esa afirmación, sin ninguna prueba automatizada que mida realmente el
rendimiento. Y entonces, comienza a emerger en el medio del sistema, un
procedimiento almacenado de cientos de líneas, con lógica de negocio incluida,
porque “así es más rápido”. Y peor, escrito sin tests.

Luego de haber practicado esta frase en mis proyectos personales y
profesionales, les puedo asegurar que realmente me he beneficiado de seguir
estos consejos. Es un placer ver cómo una idea crece hasta llegar a una
implementación concreta y sólida.

Nos leemos!

 

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

TDD Rocks! (9) JavaScript y Node.js

Friday, November 8th, 2013

Anterior Post 
Anterior Post con JavaScript 

Ayer tuve el gusto de participar del primer meetup de JavaScript en Buenos Aires:

http://www.meetup.com/Meetup-js/

Y participé dando una charla de TDD con JavaScript y Node.js. Los slides quedaron en:

https://github.com/ajlopez/Talks/tree/master/TddJavaScript

El código que mostré quedó en:

https://github.com/ajlopez/TddRocks/tree/master/JavaScript

Lo importante a entender de la charla es:

TDD NO ES ALGO DE TESTING

A ver, repitan conmigo 🙂

TDD NO ES ALGO DE TESTING

TDD NO ES ALGO DE TESTING

TDD NO ES ALGO DE TESTING

Es un flujo de trabajo de DESARROLLO. Lo que nos dá TDD es un camino de desarrollo, donde se busca la simplicidad y el crecimiento orgánico. Y es más importante cuando trabajamos sobre código de producción, código de una aplicación desarrollada en equipo ágil, y que necesita ser entregada en tiempo y forma. El flujo de trabajo de TDD nos empuja a buscar la simplicidad, no poner más código del necesario para cumplir con los ejemplos de casos de uso (que se llaman tests). Y esa simplicidad en el código es favorable, porque terminamos haciendo aplicaciones con menos partes móviles, sin necesidad de inyectarle librerías grandes o innecesarias. Y como subproducto, tenemos un sistema que otro equipo puede modificar, y darse cuenta, gracias a los tests, qué se rompe y qué no se rompe con esa modificación. Eso igual no es lo fundamental de TDD: insisto, más importante es el flujo de trabajo que nos lleva por el camino de la simplicidad.
 

No confundir simple con fácil. Ruby on Rails es fácil, pero no es simple.

Bien, para las demos, estuve usando:
 
http://nodejs.org/ 
https://github.com/ajlopez/SimpleUnit 
http://qunitjs.com/
 
Hubo otra charla interesante
sobre http://gruntjs.com/ y http://bower.io/ dada por , pero ya era tarde y me tuve que ir.
 
Las dos charlas fueron filmadas, así que revisen el enlace del meetup para ver cuándo quedan publicadas.
 
Actualización:
 
La charla de Grunt no quedó filmada por problemas técnicos. Pero les dejo acá la charla introductoria del grupo, y la charla de TDD:
 
[View:http://www.youtube.com/watch?v=lx6a71LwDIY]
 
[View:http://www.youtube.com/watch?v=iAHxyN6oZjY]
 
Recuerden, el enlace de grupo es
 
http://www.meetup.com/Meetup-js/
 
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Primer Uqbar workshop

Thursday, November 7th, 2013

En unos días, voy a ir a la reunión de todo el día de la fundación Uqbar:

http://www.uqbar-project.org/events/workshop2013

La fundación:

http://www.uqbar-project.org/home

Uqbar is a foundation whose concern is to push innovation and spread the voice on computer science. Uqbar bases itself on three main corner stones to achieve its goles: build software, do computer science research and teaching.

The name Uqbar is inspired on the story “Tlön, Uqbar, Orbis Tertius” written by Jorge Luis Borges. Of course, we encourage you to read it. We want to make the world a better place and have a space for having fun, we are also quite nerds and we always dreamed with a place for research, test, experiment and specially learn about computer science never forgeting the fact that we are human beings.

Ver los posts:

http://blog.uqbar-project.org/search/label/articles

En la reunión del sábado 16 de Noviembre:

Primer Uqbar workshop para la discusión de ideas innovadoras en programación e ingeniería de software. Su principal objetivo es generar un espacio para comunicar, compartir y discutir entre profesionales del área, orientado a la innovación e investigación. El workshop será el 16 de noviembre de 9hs a 18hs en la Universidad de San Martín, Provincia de Buenos Aires, Argentina.

Los temas principales serán:

  • lenguajes de programación
  • optimización de lenguajes
  • metaprogramación
  • compiladores
  • programación orientada a aspectos
  • frameworks y librerías
  • algoritmos
  • máquinas virtuales
  • interfaces de usuario
  • herramientas de desarrollo
  • sistemas de tipos
  • modularidad de sistemas
  • patrones de diseño
  • lenguajes específicos de dominio (DSLs)
  • educación en computación

 

Creo que se está organizando que haya un viaje desde Buenos Aires a la Universidad, ida y vuelta.

Propuse una charla, pero recién mañana viernes 8 estarán los resultados de las propuestas.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez