• Shortcuts : 'n' next unread feed - 'p' previous unread feed • Styles : 1 2

» Publishers, Monetize your RSS feeds with FeedShow:  More infos  (Show/Hide Ads)


Date: Tuesday, 26 Aug 2014 15:08

El próximo sábado 30 de Agosto, se realizará el primer Hackathon abierto del grupo Java Argentina, en las oficinas de MuleSoft en Buenos Aires. Más detalles en:

http://www.meetup.com/jugargentina/events/197071352/

Saturday, August 30, 2014
11:00 AM to 8:00 PM
MuleSoft
Av Corrientes 316, Capital Federal, Buenos Aires (map)

Planta Baja

Vamos a estar organizando el primer hackathon abierto del grupo. La idea es juntarnos a las 11AM, arrancar al medio dia, y terminar a las 8pm. Ahi vienen las presentaciones, algunos premios y cerramos con algo para comer y tomar.

Las reglas:

• Se puede usar cualquier lenguaje, no solo Java o que corra en la JVM. 

• Hay que contribuir a un proyecto Open Source. Puede ser cualquiera, no necesariamente famoso (ej: Mule ESB, Spring, Go, Vertx, etc). 

• Dura 8 horas. 

• Equipos de 1 hasta 5 integrantes

• Se va a evaluar el impacto de la contribución.

Estamos definiendo algunos premios para el equipo ganador y menciones. Apenas tengamos algo les avisamos.

Prometemos comida, bebidas y diversion!, por lo que pedimos que se registren todos los participantes, así podemos calcular bien las cantidades. 

Apuren a anotarse ya que vamos a tener cupo limitado!

Lo bueno es que puede usarse cualquier lenguaje, y al parecer, puede trabajarse sobre un proyecto nuevo o existente, mientras sea Open Source. Espero que haya cerveza :-)

Nos leemos!

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

Author: "lopez" Tags: "Buenos, Buenos Aires, Hackathon, Java, P..."
Comments Send by mail Print  Save  Delicious 
Date: Monday, 25 Aug 2014 17:08

Se viene en Septiembre el próximo meetup de JavaScript, en Buenos Aires, ver detalles para el 11 de Septiembre en:

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

Retomamos la sana costumbre de reunión y discusión tecnológica con colegas de la comunidad.

Como siempre, la modalidad es la misma, arrancamos 6:30, y para los que van llegando tenemos algo para tomar, comer y charlar. A las 7 arranca la primer charla. Charlas:

Angel ‘Java’ Lopez – Introduccion a Express
Juan Pablo Kutianski – Introducción a D3

Como en la última oportunidad vamos a transmitir el evento por HO para los que no puedan venir.
Los esperamos!

Como otras veces, organizado por la gente de @scvsoft. Seguro, picada y cerveza (también medialunas y bebida cola, urrgg… :-)

Sí, voy a estar dando una charla corta sobre Express, el framework web más popular montado sobre Node.js. Veremos de usar el generador básico que viene con Express 4.x, qué funcionalidad básica da, el manejo de los middleware, el ruteo, la generación de vistas usando lenguajes de templates, y la exposición de APIs devolviendo JSON simple. Haremos código en vivo sencillo, y luego pasaré a ejemplos armados, con acceso, por ejemplo, a MongoDB. Realmente, Express es muy flexible, y se ocupa de pocas cosas, dejándonos a nosotros aprovechar el resto del ecosistema de Node. En ese sentido, no es un framework “pesado” o con mucho “opinionated”. Para algunos, esto es una ventaja, pero para otros no. A mí ese “approach” me gusta, porque permite elegir herramientas y librerías según el contexto y la necesidad, en vez de embarcarse en una gran solución única. Pero verán Uds. que les parece.

También estará el bueno de @baldpower dando una charla sobre D3, la librería de JavaScript para gráficos dinámicos, y hasta en tiempo real. Ver

http://d3js.org/

Nos leemos!

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

Author: "lopez" Tags: "Buenos Aires, JavaScript, Meetup, NodeJs"
Comments Send by mail Print  Save  Delicious 
Date: Tuesday, 12 Aug 2014 18:01

Es tiempo de escribir las nuevas resoluciones, y revisar las de Julio:

- Mejorar AjGenesisNode generación de código para Express [completo] ver repo
- Mejorar AjGenesisNode generación de código para Sinatra [parcial] ver repo
- Primer generación de código de AjGenesisNode para Laravel [pendiente]
- Carga de módulos, exportar, en lenguaje Mass [pendiente]
- Continuar con SharpBus [completo] ver repo
- Continuar con Dynamic Site [pendiente]
- Give a talk about Node.js/Express [completo]
- Mejorar mi sitio personal [completo] ver repo
- Escribir TDD Post [pendiente]
- Escribir C# Posts [completo] ver posts
- Caso distribuido usando Aktores [pendiente]
- Revisar, refactorizar y continuar la implementación de RustScript [completo] ver repo

Additionally, I worked on:

- Comenzar SimpleList [completo] ver repo
- Comenzar SimpleJQuery [completo] ver repo
- Mejorar SimpleMule [completo] ver repo
- Comenzar SharpGD, Graph Database in C# [completo] ver repo
- Mejorar SimpleBus [completo] ver repo
- Mejorar SharpGo [completo] ver repo
- Mejorar ExpressSamples [completo] ver repo
- Mejoras menores en ScaScript [completo] ver repo
- Mejorar ScalaSharp [completo] ver repo
- Escribir Friends sample for JavaScriptSamples [completo] ver repo
- Escribir Angular examples [completo] ver repo
- Agregar método remove a OStore [completo] ver repo
- Colaborar con el proyecto Liqueed [completo] ver repo

Nuevas resoluciones para Agosto 2014:

- Escribir jQuery mock a ser usando en test de consola desde Node.js
- Escribir simples funciones en JavaScript para manipular arreglos de objetos
- Continuar colaborando con el proyecto Liqueed
- Comenzar con Aktores ejemplo distribuido
- Comenzar con AjErl ejemplo distribuido

Nos leemos!

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

Author: "lopez" Tags: ".NET, C#, JavaScript, NodeJs, Proyectos ..."
Comments Send by mail Print  Save  Delicious 
Date: Wednesday, 09 Jul 2014 10:45

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

Author: "lopez" Tags: ".NET, C Sharp, Javascript, Proyectos de ..."
Comments Send by mail Print  Save  Delicious 
Date: Wednesday, 09 Jul 2014 05:45

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

Author: "lopez" Tags: "1389, 14005, 15035, 15550, 18052, 5374"
Comments Send by mail Print  Save  Delicious 
Date: Monday, 07 Jul 2014 17:18

Gracias a la gente del MUG voy a dar una charla introductoria (gratuita, pero hay que registrarse) ahora en unos días acá en Buenos Aires:

http://www.mug-it.org.ar/Event.aspx?Event=162

Inicio: 23.07.2014 18:30hs, hasta las 20 y monedas | Lugar: Rivadavia 1479 1er Piso

JavaScript no solo tiene cada vez más influencia en el desarrollo cliente/nativo, también ha sabido crecer en el lado del servidor. En esta sesión gratuita veremos la implementación de Node.js, un programa que ejecuta JavaScript. Vacantes limitadas. Inscripción previa obligatoria.

Node.js permite el desarrollo de servidores de distintos protocolos, procesamiento distribuido, y desarrollo web, explotando la entrada/salida asincrónica para mejorar el rendimiento. Bravemente exploraremos como se escribe y ejecuta JavaScript en Node.js, el sistema de módulos, el ecosistema de módulos que tiene, una introducción a desarrollar sitios web con Express, con ejemplos.

Luego, viene una jornada (de un día, con costo, traer notebook para aprovecharla):

http://www.mug-it.org.ar/Event.aspx?Event=163

Lugar: Auditorio del MUG, Rivadavia 1479 Primer Piso "A", Buenos Aires.

Fecha y Horario: Miércoles 30 de julio de 2014 de 9:00 a 17:00 hs. 

 

Contenidos:
1. Introducción a Node.js
1.1. Programación Javascript desde Node sobre el motor V8 
1.2. Entrada/Salida asincrónica 
1.3. Módulos 
1.4. Manejador de paquetes npm
1.5. Elementos de Test-Driven Development 
2. Programación Web con Node.js 
2.1. Módulo HTTP 
2.2. Manejo asincrónico 
2.3. Acceso a MongoDB
3. Programación Web con Express
3.1. Concepto de Middleware 
3.2. Lenguaje de Templates 
3.3. Ejemplos con Páginas y Acceso a Datos
3.4. Programando con JSON
3.5. Elementos de Socket.IO
(*)  Instalar previamente el siguiente software:
Instalador de Node (para Windows y otros) http://nodejs.org/download/
Git bajarlo de http://git-scm.com/
MongoDB bajarlo de http://www.mongodb.org/downloads
La idea de la jornada es practicar Node.js, desde el inicio, y ver de instalar, levantar y examinar ejemplos, de consola y web, para ir viendo cómo es el tema de desarrollo con Node.js, cómo se usan los módulos, el ecosistema que existe, el manejador de paquetes NPM, y Express como framework web. Usaremos MongoDB para la persistencia.
Como siempre, el material de los dos eventos estará en mi cuenta de GitHub, y algún anuncio habrá por acá.
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez 
Author: "lopez" Tags: "Desarrollo Web, Javascript, NodeJs, Buen..."
Comments Send by mail Print  Save  Delicious 
Date: Monday, 07 Jul 2014 12:18

Gracias a la gente del MUG voy a dar una charla introductoria (gratuita, pero hay que registrarse) ahora en unos días acá en Buenos Aires:


http://www.mug-it.org.ar/Event.aspx?Event=162


Inicio: 23.07.2014 18:30hs, hasta las 20 y monedas | Lugar: Rivadavia 1479 1er Piso


JavaScript no solo tiene cada vez más influencia en el desarrollo cliente/nativo, también ha sabido crecer en el lado del servidor. En esta sesión gratuita veremos la implementación de Node.js, un programa que ejecuta JavaScript. Vacantes limitadas. Inscripción previa obligatoria.


Node.js permite el desarrollo de servidores de distintos protocolos, procesamiento distribuido, y desarrollo web, explotando la entrada/salida asincrónica para mejorar el rendimiento. Bravemente exploraremos como se escribe y ejecuta JavaScript en Node.js, el sistema de módulos, el ecosistema de módulos que tiene, una introducción a desarrollar sitios web con Express, con ejemplos.


Luego, viene una jornada (de un día, con costo, traer notebook para aprovecharla):


http://www.mug-it.org.ar/Event.aspx?Event=163


Lugar: Auditorio del MUG, Rivadavia 1479 Primer Piso “A”, Buenos Aires.


Fecha y Horario: Miércoles 30 de julio de 2014 de 9:00 a 17:00 hs. 


 


Contenidos:

1. Introducción a Node.js

1.1. Programación Javascript desde Node sobre el motor V8 

1.2. Entrada/Salida asincrónica 

1.3. Módulos 

1.4. Manejador de paquetes npm

1.5. Elementos de Test-Driven Development 

2. Programación Web con Node.js 

2.1. Módulo HTTP 

2.2. Manejo asincrónico 

2.3. Acceso a MongoDB

3. Programación Web con Express

3.1. Concepto de Middleware 

3.2. Lenguaje de Templates 

3.3. Ejemplos con Páginas y Acceso a Datos

3.4. Programando con JSON

3.5. Elementos de Socket.IO

(*)  Instalar previamente el siguiente software:

Instalador de Node (para Windows y otros) http://nodejs.org/download/

Git bajarlo de http://git-scm.com/

MongoDB bajarlo de http://www.mongodb.org/downloads


La idea de la jornada es practicar Node.js, desde el inicio, y ver de instalar, levantar y examinar ejemplos, de consola y web, para ir viendo cómo es el tema de desarrollo con Node.js, cómo se usan los módulos, el ecosistema que existe, el manejador de paquetes NPM, y Express como framework web. Usaremos MongoDB para la persistencia.


Como siempre, el material de los dos eventos estará en mi cuenta de GitHub, y algún anuncio habrá por acá.


Nos leemos!


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

Author: "lopez" Tags: "10747, 14005, 15550, 17044"
Comments Send by mail Print  Save  Delicious 
Date: Saturday, 05 Jul 2014 17:19

En estos últimos años he estado practicando deliberadamente TDD (Test-Driven Development) y trabajo en proyectos personales usando el flujo de trabajo de esta disciplina casi todos los días (ver mis posts de TDD y los commits en GitHub) Y también he trabajado en proyectos profesionales, con y sin TDD. Y luego de tanto código y proyectos, pienso que ya tengo un panorama de cuáles son los valores que agrega TDD a un proyecto que tenga desarrollo de software y cuáles son los problemas que podemos tener si no usamos TDD..

Primero, hay que recordar que un proyecto profesional puede ser más que programar código: he escrito que un proyecto BUENO es el que resuelve un problema (ver Un Buen Proyecto). No es solamente programar código, y menos programar código como nos parece o nos gusta. Lo importante es solucionar el problema que tiene quien nos contrata como equipo o como desarrollador individual.

Hecha esa aclaración ¿que es lo que vi de más valor siguiendo TDD, tanto en proyectos personales como profesionales? El primer punto de valor que veo como evidente, espero poder transmitirles el concepto, es:

TDD NOS EMPUJA A LA SIMPLICIDAD EN EL SOFTWARE QUE CONSTRUIMOS

Como cada vez que escribimos un test tenemos que pasarlo de rojo a verde con el código más simple, entonces esa simplicidad se va transmitiendo a lo que estamos construyendo.

Antes de seguir con el tema simplicidad, recordemos que no es sólo hacer TDD. Por ejemplo, tengo en gran importancia implementar casos de uso (ver TDD y Casos de Uso). Sin una serie de casos de uso a implementar, corremos el peligro de salirnos del carril y escribir algo que nos parece lindo, interesante, pero no soluciona el problema que tenemos que atacar en el proyecto.

Entonces, con TDD y guiado por los principales casos de uso, vamos diseñando un software. TDD es un proceso de diseño de software, no de escribir tests o de testing. TDD nos lleva a construir un software lo más simple posible, y los casos de uso nos guían hacia donde realmente esta el problema a resolver. Me gusta decir que aplicamos “baby steps”, hacia un diseño incremental de la solución (ver TDD y Baby Steps). No digo no hacer diseño de antemano: hago algo de diseño,  pero en la servilleta del desayuno, y apenas un poco. No pongo diseño imaginado en el código HASTA QUE NO LLEGUE EL TEST que lo amerite.

No olvidarse del otro importante paso: el refactor. Es ahí donde vamos a poner lo que conocemos para mejorar el código. Y es notable: TDD, como flujo de trabajo, nos va enseñando sobre diseño de código, de forma incremental. Al llegar un nuevo test, podemos ver que lo que habíamos escrito hasta entonces no sea lo óptimo, y refactorizamos la implementación interna. En este paso puede aparece la aplicación de patrones. Y eso es bueno: aparecen en un contexto, el de refactorización, no aparecen “del aire” o porque se nos ocurre a nosotros que hay que aplicar tal patrón. Recordemos que unos de los atributos de un patrón de software es el contexto donde se aplica. En la etapa de refactor podemos descubrir o poner de manifiesto ese contexto y ahí entonces reción aplicar el patrón. Si hacemos diseño de antemano, podemos caer (y lo he visto suceder) en la “patronitis”: agregar todos los patrones habidos y por haber, porque pensamos que son la mejor práctica. Hacer eso es una variante de “optimización prematura es la madre de todos los males”. Lo que nos va a enseñar TDD es que no hace falta pensar todo de antemano, rompiendo YAGNI. Lo que vamos creando con TDD en general va estar en “buena forma” para adaptarse a los nuevos casos de uso y nuevos tests que aparezcan. 

Y aca esta el otro valor que agrega, paralelo a la simplicidad: no solamente el código va creciendo con la simplicidad necesaria, sino que tambien esta en su mayor parte ajustado a lo que nuestros tests piden, no a lo que nosotros queremos o imaginamos que necesita tener nuestro código. El diseño del software en construcción, de esta forma, es como la confección de un traje a medida, que va calzando perfecto en cada iteración a lo que necesitamos implementar. 

Para que no todo sea cháchara en este post, pongo un ejemplo concreto, que ya he expuesto en otros posts (ver, por ejemplo, Desarrollando una Aplicación usando TDD). Supongamos que necesitamos devolver una lista de nuestros productos por categoría, digamos, en una API. ¿Qué hacemos en el controlador? He visto muchas veces que ya al primer test se le coloca un repositorio “mockeado” porque, claro, necesitamos el patrón repositorio ¿no?. Así nace la “paternitis”. NO: si somos consecuentes con el flujo TDD, lo más simple es ir entregando al controlador…. un LISTA DE PRODUCTOS. Solamente cuando tengamos más casos de uso, y veamos que la lista de productos la necesitamos en otros lados, vamos separando su existencia en otros componentes. He visto también que llegado al primer o segundo test, o aún antes, ya se está diseñando la base de datos para tener una tabla de productos y otra de categorías. Yo pregunto ¿quién, en qué el test, pidió eso? ¿qué test puso persistencia en el tapete? Muchas veces, NINGUNO. De nuevo, hay que ir implementando lo que nos pide el test, nada más, no hay que agregar nuestra propia “bajada de línea”, “ruptura de YAGNI”, como cuando pensamos “vamos a necesitar repositorio, vamos a necesitar persistencia” y entonces, necesitamos YA ponerlo y YA ponerlo como mock y así. Ese es el camino de romper la simplicidad de la que hablo.

De esta forma, el software que tengamos en construcción, crece como un organismo: de a poco, de forma controlada.

Seguiré con el tema del valor que agrega TDD, en los próximos posts: aumenta la calidad de código, permite la evolución y la adaptación al cambio, permite reducir la cantidad de bugs, permite arreglar los bugs detectados de forma más rápida, deja al proyecto en buena forma para que lo tomo otro equipo, etc.

Nos leemos!

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

 

Author: "lopez" Tags: "Arquitectura, Desarrollo Agil, TDD"
Comments Send by mail Print  Save  Delicious 
Date: Saturday, 05 Jul 2014 12:19

En estos últimos años he estado practicando deliberadamente TDD (Test-Driven Development) y trabajo en proyectos personales usando el flujo de trabajo de esta disciplina casi todos los días (ver mis posts de TDD y los commits en GitHub) Y también he trabajado en proyectos profesionales, con y sin TDD. Y luego de tanto código y proyectos, pienso que ya tengo un panorama de cuáles son los valores que agrega TDD a un proyecto que tenga desarrollo de software y cuáles son los problemas que podemos tener si no usamos TDD..


Primero, hay que recordar que un proyecto profesional puede ser más que programar código: he escrito que un proyecto BUENO es el que resuelve un problema (ver Un Buen Proyecto). No es solamente programar código, y menos programar código como nos parece o nos gusta. Lo importante es solucionar el problema que tiene quien nos contrata como equipo o como desarrollador individual.


Hecha esa aclaración ¿que es lo que vi de más valor siguiendo TDD, tanto en proyectos personales como profesionales? El primer punto de valor que veo como evidente, espero poder transmitirles el concepto, es:


TDD NOS EMPUJA A LA SIMPLICIDAD EN EL SOFTWARE QUE CONSTRUIMOS


Como cada vez que escribimos un test tenemos que pasarlo de rojo a verde con el código más simple, entonces esa simplicidad se va transmitiendo a lo que estamos construyendo.


Antes de seguir con el tema simplicidad, recordemos que no es sólo hacer TDD. Por ejemplo, tengo en gran importancia implementar casos de uso (ver TDD y Casos de Uso). Sin una serie de casos de uso a implementar, corremos el peligro de salirnos del carril y escribir algo que nos parece lindo, interesante, pero no soluciona el problema que tenemos que atacar en el proyecto.


Entonces, con TDD y guiado por los principales casos de uso, vamos diseñando un software. TDD es un proceso de diseño de software, no de escribir tests o de testing. TDD nos lleva a construir un software lo más simple posible, y los casos de uso nos guían hacia donde realmente esta el problema a resolver. Me gusta decir que aplicamos “baby steps”, hacia un diseño incremental de la solución (ver TDD y Baby Steps). No digo no hacer diseño de antemano: hago algo de diseño,  pero en la servilleta del desayuno, y apenas un poco. No pongo diseño imaginado en el código HASTA QUE NO LLEGUE EL TEST que lo amerite.


No olvidarse del otro importante paso: el refactor. Es ahí donde vamos a poner lo que conocemos para mejorar el código. Y es notable: TDD, como flujo de trabajo, nos va enseñando sobre diseño de código, de forma incremental. Al llegar un nuevo test, podemos ver que lo que habíamos escrito hasta entonces no sea lo óptimo, y refactorizamos la implementación interna. En este paso puede aparece la aplicación de patrones. Y eso es bueno: aparecen en un contexto, el de refactorización, no aparecen “del aire” o porque se nos ocurre a nosotros que hay que aplicar tal patrón. Recordemos que unos de los atributos de un patrón de software es el contexto donde se aplica. En la etapa de refactor podemos descubrir o poner de manifiesto ese contexto y ahí entonces reción aplicar el patrón. Si hacemos diseño de antemano, podemos caer (y lo he visto suceder) en la “patronitis”: agregar todos los patrones habidos y por haber, porque pensamos que son la mejor práctica. Hacer eso es una variante de “optimización prematura es la madre de todos los males”. Lo que nos va a enseñar TDD es que no hace falta pensar todo de antemano, rompiendo YAGNI. Lo que vamos creando con TDD en general va estar en “buena forma” para adaptarse a los nuevos casos de uso y nuevos tests que aparezcan. 


Y aca esta el otro valor que agrega, paralelo a la simplicidad: no solamente el código va creciendo con la simplicidad necesaria, sino que tambien esta en su mayor parte ajustado a lo que nuestros tests piden, no a lo que nosotros queremos o imaginamos que necesita tener nuestro código. El diseño del software en construcción, de esta forma, es como la confección de un traje a medida, que va calzando perfecto en cada iteración a lo que necesitamos implementar. 


Para que no todo sea cháchara en este post, pongo un ejemplo concreto, que ya he expuesto en otros posts (ver, por ejemplo, Desarrollando una Aplicación usando TDD). Supongamos que necesitamos devolver una lista de nuestros productos por categoría, digamos, en una API. ¿Qué hacemos en el controlador? He visto muchas veces que ya al primer test se le coloca un repositorio “mockeado” porque, claro, necesitamos el patrón repositorio ¿no?. Así nace la “paternitis”. NO: si somos consecuentes con el flujo TDD, lo más simple es ir entregando al controlador…. un LISTA DE PRODUCTOS. Solamente cuando tengamos más casos de uso, y veamos que la lista de productos la necesitamos en otros lados, vamos separando su existencia en otros componentes. He visto también que llegado al primer o segundo test, o aún antes, ya se está diseñando la base de datos para tener una tabla de productos y otra de categorías. Yo pregunto ¿quién, en qué el test, pidió eso? ¿qué test puso persistencia en el tapete? Muchas veces, NINGUNO. De nuevo, hay que ir implementando lo que nos pide el test, nada más, no hay que agregar nuestra propia “bajada de línea”, “ruptura de YAGNI”, como cuando pensamos “vamos a necesitar repositorio, vamos a necesitar persistencia” y entonces, necesitamos YA ponerlo y YA ponerlo como mock y así. Ese es el camino de romper la simplicidad de la que hablo.


De esta forma, el software que tengamos en construcción, crece como un organismo: de a poco, de forma controlada.


Seguiré con el tema del valor que agrega TDD, en los próximos posts: aumenta la calidad de código, permite la evolución y la adaptación al cambio, permite reducir la cantidad de bugs, permite arreglar los bugs detectados de forma más rápida, deja al proyecto en buena forma para que lo tomo otro equipo, etc.


Nos leemos!


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


 

Author: "lopez" Tags: "10549, 11699, 1392"
Comments Send by mail Print  Save  Delicious 
Date: Monday, 30 Jun 2014 13:30

En los dos últimos años estuve explorando las ideas de Storm (ver https://storm.incubator.apache.org/), implementándo alguna topología local en Node.js. Llegó la hora de practicar más C# y TDD (Test-Driven Development), con:

https://github.com/ajlopez/SharpStorm

El estado inicial del proyecto:

La idea es implementar bolt, spout y un builder de topologies. Leo en

https://storm.incubator.apache.org/about/simple-api.html

There are just three abstractions in Storm: spouts, bolts, and topologies. A spout is a source of streams in a computation. Typically a spout reads from a queueing broker such as Kestrel, RabbitMQ, or Kafka, but a spout can also generate its own stream or read from somewhere like the Twitter streaming API. Spout implementations already exist for most queueing systems.

A bolt processes any number of input streams and produces any number of new output streams. Most of the logic of a computation goes into bolts, such as functions, filters, streaming joins, streaming aggregations, talking to databases, and so on.

A topology is a network of spouts and bolts, with each edge in the network representing a bolt subscribing to the output stream of some other spout or bolt. A topology is an arbitrarily complex multi-stage stream computation. Topologies run indefinitely when deployed.

Como ven, en el proyecto por ahora están definidas las interfaces que espero por ahora tengan bolts y spouts, y un topology builder para armar una topología. Por ahora, quiero una implementación local (sin procesamiento distribuido). Luego, espero implementar el algoritmo de ACK que tiene Storm original, que permite saber cuándo un mensaje entrante quedó completamente procesado (incluso los procesos de los mensajes que produjo en el medio del proceso).

Próximos temas: revisar ISpout, IBolt, y como se arma una topología.

Nos leemos!

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

Author: "lopez" Tags: ".NET, C Sharp, Proyectos de Código ..."
Comments Send by mail Print  Save  Delicious 
Date: Monday, 30 Jun 2014 12:26

Ya estuve experimentando con map-reduce en Node.js/JavaScript. Pero también es interesante implementar algo del algoritmo en C#, para practicar TDD (Test-Driven Development) y para aprender más sobre lo que implica implementar el algoritmo. El proyecto que inicié es:

https://github.com/ajlopez/SharpDoop

El estado del proyecto a hoy:

Tiene un proyecto de librería de clases, y el proyecto de test. Todavía no llegué a pensar en algo distribuido. Lo único que quiero por ahora es especificar el algoritmo de map, el de reduce, y enviarlo a que procese como un job, dentro de este proyecto.

Vean que hay entonces un MapReduceJob. Es la clase base que se encarga de ejecutar un map (un lambda o Action que toma clave, valor y va procesándolo) y un reduce (toma clave, una lista de valores de esa clave, y emite resultado). Gracias a C#, esas dos operaciones se pueden expresar como lambdas o como métodos delegados en un objeto más complejo. Por ahora, están funcionando los casos simples que planteo en los tests.

Como divertimento, armé también un MapProcessJob, que es una variante de map/reduce a discutir. En vez de procesar primero todas las claves, y luego pasarlas por el reduce, trata de hacer todo junto. En algunos casos de uso puede ser más eficiente, pero es un tema a discutir con más detalle.

Próximos temas: revisar más en profundidad la implementación y las ideas, como el map/process.

Nos leemos!

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

Author: "lopez" Tags: ".NET, C Sharp, Proyectos de Código ..."
Comments Send by mail Print  Save  Delicious 
Date: Monday, 30 Jun 2014 08:30

En los dos últimos años estuve explorando las ideas de Storm (ver https://storm.incubator.apache.org/), implementándo alguna topología local en Node.js. Llegó la hora de practicar más C# y TDD (Test-Driven Development), con:


https://github.com/ajlopez/SharpStorm


El estado inicial del proyecto:



La idea es implementar bolt, spout y un builder de topologies. Leo en


https://storm.incubator.apache.org/about/simple-api.html


There are just three abstractions in Storm: spouts, bolts, and topologies. A spout is a source of streams in a computation. Typically a spout reads from a queueing broker such as Kestrel, RabbitMQ, or Kafka, but a spout can also generate its own stream or read from somewhere like the Twitter streaming API. Spout implementations already exist for most queueing systems.

A bolt processes any number of input streams and produces any number of new output streams. Most of the logic of a computation goes into bolts, such as functions, filters, streaming joins, streaming aggregations, talking to databases, and so on.

A topology is a network of spouts and bolts, with each edge in the network representing a bolt subscribing to the output stream of some other spout or bolt. A topology is an arbitrarily complex multi-stage stream computation. Topologies run indefinitely when deployed.


Como ven, en el proyecto por ahora están definidas las interfaces que espero por ahora tengan bolts y spouts, y un topology builder para armar una topología. Por ahora, quiero una implementación local (sin procesamiento distribuido). Luego, espero implementar el algoritmo de ACK que tiene Storm original, que permite saber cuándo un mensaje entrante quedó completamente procesado (incluso los procesos de los mensajes que produjo en el medio del proceso).


Próximos temas: revisar ISpout, IBolt, y como se arma una topología.


Nos leemos!


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

Author: "lopez" Tags: "1389, 15035, 18479, 18480, 5374"
Comments Send by mail Print  Save  Delicious 
Date: Monday, 30 Jun 2014 07:26

Ya estuve experimentando con map-reduce en Node.js/JavaScript. Pero también es interesante implementar algo del algoritmo en C#, para practicar TDD (Test-Driven Development) y para aprender más sobre lo que implica implementar el algoritmo. El proyecto que inicié es:


https://github.com/ajlopez/SharpDoop


El estado del proyecto a hoy:



Tiene un proyecto de librería de clases, y el proyecto de test. Todavía no llegué a pensar en algo distribuido. Lo único que quiero por ahora es especificar el algoritmo de map, el de reduce, y enviarlo a que procese como un job, dentro de este proyecto.


Vean que hay entonces un MapReduceJob. Es la clase base que se encarga de ejecutar un map (un lambda o Action que toma clave, valor y va procesándolo) y un reduce (toma clave, una lista de valores de esa clave, y emite resultado). Gracias a C#, esas dos operaciones se pueden expresar como lambdas o como métodos delegados en un objeto más complejo. Por ahora, están funcionando los casos simples que planteo en los tests.


Como divertimento, armé también un MapProcessJob, que es una variante de map/reduce a discutir. En vez de procesar primero todas las claves, y luego pasarlas por el reduce, trata de hacer todo junto. En algunos casos de uso puede ser más eficiente, pero es un tema a discutir con más detalle.


Próximos temas: revisar más en profundidad la implementación y las ideas, como el map/process.


Nos leemos!


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

Author: "lopez" Tags: "1389, 15035, 17628, 18478, 5374"
Comments Send by mail Print  Save  Delicious 
Date: Sunday, 29 Jun 2014 20:16

Anterior Post

Hace ya año y medio que no escribo de este proyecto en C#, pero fui trabajando en él, y en la implementación paralela que tengo en JavaScript (de hecho, presenté algunos conceptos de ambos en la Smalltalks 2013 que se realizó el año pasado, en Rosario, Argentina).

El proyecto está en:

https://github.com/ajlopez/AjTalk

La estructura actual:

Veamos. Los proyectos son:

AjTalk: librería de clases, con la implementación de un compilador a bytecodes (y también a JavaScript), y un intérprete de los bytecodes compilados.

AjTalk.Compiler: un proyecto de consola que permite, usando el compilador mencionado en el proyecto anterior, generar código JavaScript.

AjTalk.Console: un REPL (Read Eval Print Loop)

AjTalk.Gui: una implementación sin terminar de ventanas

AjTalk.Tests: los tests que fui escribiendo, siguiendo el flujo de trabajo de TDD (Test-Driven Development)

El compilador a JavaScript creo que no lo voy a necesitar, porque en el último año he conseguido que el proyecto de BLOCKED SCRIPT

https://github.com/ajlopez/AjTalkJs

sea autosuficiente (ahora compila a bytecodes, pero también podría compilar a JavaScript; el tema que el intérprete de bytecodes me permite algunas operaciones más flexibles).

Y la implementación de ventanas (muy primitiva) la voy a sacar, para seguir por el camino de crear ventanas desde el propio AjTalk, en Smalltalk, accediendo a los tipos y objetos de .NET.

Un punto que me parece muy interesante (en ambos proyectos, el de C# y el de JavaScript) es tener una implementación modular: en vez de cargar una imagen con todo definido, poder definir módulos a cargar, como pasa en el ambiente Node.js. Los módulos estarían publicados en el NPM (El Node Package Manager), y cada cual podría indicar qué módulos necesita en su programa, en lugar de levantar todo Smalltalk.

Otro tema: en este proyecto de C# tengo implementado que pueda levantar más de una máquina AjTalk al mismo tiempo. E incluso puedo hacer que una máquina “ayude” a la otra. Por ejemplo, si la máquina A no tiene los métodos para compilar nuevos métodos, la máquina B puede ir en su auxilio. Así, la máquina A (y su imagen, que ya estoy grabando imagen binaria) puede mantenerse de tamaño pequeño.

Otra característica que tengo implementada: la capacidad de enviar un mensaje a un objeto, sin esperar una respuesta, un “fire and forget”. Y que el objeto destino pueda atender esos mensajes DE A UNO, como en los modelos de actores.

Tengo que revisar la implementación de objetos remotos (hoy basada en el viejo Remoting de .NET). Pero pienso que es una característica importante a mantener y explorar.

Bien, como ven, quedan multitud de temas para otros posts, como detalles de implementación de conceptos de Smalltalk, como Object, Class, ClassDescription, Behavior, MetaClass, etc.

Nos leemos!

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

Author: "lopez" Tags: ".NET, Smalltalk, C Sharp, AjTalk, Proyec..."
Comments Send by mail Print  Save  Delicious 
Date: Sunday, 29 Jun 2014 15:16

Anterior Post


Hace ya año y medio que no escribo de este proyecto en C#, pero fui trabajando en él, y en la implementación paralela que tengo en JavaScript (de hecho, presenté algunos conceptos de ambos en la Smalltalks 2013 que se realizó el año pasado, en Rosario, Argentina).


El proyecto está en:


https://github.com/ajlopez/AjTalk


La estructura actual:



Veamos. Los proyectos son:


AjTalk: librería de clases, con la implementación de un compilador a bytecodes (y también a JavaScript), y un intérprete de los bytecodes compilados.


AjTalk.Compiler: un proyecto de consola que permite, usando el compilador mencionado en el proyecto anterior, generar código JavaScript.


AjTalk.Console: un REPL (Read Eval Print Loop)


AjTalk.Gui: una implementación sin terminar de ventanas


AjTalk.Tests: los tests que fui escribiendo, siguiendo el flujo de trabajo de TDD (Test-Driven Development)


El compilador a JavaScript creo que no lo voy a necesitar, porque en el último año he conseguido que el proyecto de JavaScript:


https://github.com/ajlopez/AjTalkJs


sea autosuficiente (ahora compila a bytecodes, pero también podría compilar a JavaScript; el tema que el intérprete de bytecodes me permite algunas operaciones más flexibles).


Y la implementación de ventanas (muy primitiva) la voy a sacar, para seguir por el camino de crear ventanas desde el propio AjTalk, en Smalltalk, accediendo a los tipos y objetos de .NET.


Un punto que me parece muy interesante (en ambos proyectos, el de C# y el de JavaScript) es tener una implementación modular: en vez de cargar una imagen con todo definido, poder definir módulos a cargar, como pasa en el ambiente Node.js. Los módulos estarían publicados en el NPM (El Node Package Manager), y cada cual podría indicar qué módulos necesita en su programa, en lugar de levantar todo Smalltalk.


Otro tema: en este proyecto de C# tengo implementado que pueda levantar más de una máquina AjTalk al mismo tiempo. E incluso puedo hacer que una máquina “ayude” a la otra. Por ejemplo, si la máquina A no tiene los métodos para compilar nuevos métodos, la máquina B puede ir en su auxilio. Así, la máquina A (y su imagen, que ya estoy grabando imagen binaria) puede mantenerse de tamaño pequeño.


Otra característica que tengo implementada: la capacidad de enviar un mensaje a un objeto, sin esperar una respuesta, un “fire and forget”. Y que el objeto destino pueda atender esos mensajes DE A UNO, como en los modelos de actores.


Tengo que revisar la implementación de objetos remotos (hoy basada en el viejo Remoting de .NET). Pero pienso que es una característica importante a mantener y explorar.


Bien, como ven, quedan multitud de temas para otros posts, como detalles de implementación de conceptos de Smalltalk, como Object, Class, ClassDescription, Behavior, MetaClass, etc.


Nos leemos!


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

Author: "lopez" Tags: "11722, 1389, 15035, 3462, 5374"
Comments Send by mail Print  Save  Delicious 
Date: Sunday, 29 Jun 2014 12:24

Quería implementar un key-value store (como Redis) en C#, para ensayar algunas estructuras de datos y practicar TDD (Test-Driven Development). El proyecto que inicié es:

https://github.com/ajlopez/AjKeyvs

La estructura actual del proyecto:

Hay un proyecto de librería de clases, AjKeyvs, que contiene las colecciones que manejo en un repositorio. Lo interesante para este proyecto es implementar arreglos y conjuntos que puedan ser “sparse”, es decir que puedan tener claves muy diferentes. Ejemplo, tener una clave 1 (entero uno), y una clave 1000000 (entero un millon) y no tener que reservar un millon de lugares en el “arreglo”, sino solamente reservar lo que se usa. Y también tener un buen tiempo de acceso y modificación. Otras veces tendré claves String, con jerarquía, tipo “user”, “user:1”, “user:1:email”, etc. Y también quiero acceder rápidamente a ese tipo de estructura. Hay casos de uso que implican implementar conjuntos (con unión, intersección, etc), y en el caso de ser los elementos enteros, he implementado un conjunto donde prendo o apago un bit, de acuerdo a si el elemento correspondiente está o no está en el conjunto. Pero ya vendrá más detalle en próximos posts.

Si bien esa librería se puede usar in-process, también estuve armando un servidor, y un programa cliente. El servidor escucha y procesa comandos que le envían los clientes, enviándolos al repositorio de colecciones. Todas las colecciones se guardan en memoria. El tema persistencia me parece ortogonal a estos casos de uso. Veré si lo adoso a los comandos, o queda a responsabilidad del consumidor.

Y como es usual, hay un proyecto con los tests que fui armando siguiendo el flujo de trabajo de TDD.

Próximos temas: estructuras de datos, colecciones, comandos, concurrencia, etc.

Nos leemos!

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

Author: "lopez" Tags: ".NET, C Sharp, NoSQL, Proyectos de C..."
Comments Send by mail Print  Save  Delicious 
Date: Sunday, 29 Jun 2014 07:24

Quería implementar un key-value store (como Redis) en C#, para ensayar algunas estructuras de datos y practicar TDD (Test-Driven Development). El proyecto que inicié es:

https://github.com/ajlopez/AjKeyvs

La estructura actual del proyecto:

Hay un proyecto de librería de clases, AjKeyvs, que contiene las colecciones que manejo en un repositorio. Lo interesante para este proyecto es implementar arreglos y conjuntos que puedan ser “sparse”, es decir que puedan tener claves muy diferentes. Ejemplo, tener una clave 1 (entero uno), y una clave 1000000 (entero un millon) y no tener que reservar un millon de lugares en el “arreglo”, sino solamente reservar lo que se usa. Y también tener un buen tiempo de acceso y modificación. Otras veces tendré claves String, con jerarquía, tipo “user”, “user:1”, “user:1:email”, etc. Y también quiero acceder rápidamente a ese tipo de estructura. Hay casos de uso que implican implementar conjuntos (con unión, intersección, etc), y en el caso de ser los elementos enteros, he implementado un conjunto donde prendo o apago un bit, de acuerdo a si el elemento correspondiente está o no está en el conjunto. Pero ya vendrá más detalle en próximos posts.

Si bien esa librería se puede usar in-process, también estuve armando un servidor, y un programa cliente. El servidor escucha y procesa comandos que le envían los clientes, enviándolos al repositorio de colecciones. Todas las colecciones se guardan en memoria. El tema persistencia me parece ortogonal a estos casos de uso. Veré si lo adoso a los comandos, o queda a responsabilidad del consumidor.

Y como es usual, hay un proyecto con los tests que fui armando siguiendo el flujo de trabajo de TDD.

Próximos temas: estructuras de datos, colecciones, comandos, concurrencia, etc.

Nos leemos!

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

Author: "lopez" Tags: "13239, 1389, 15035, 18477, 5374"
Comments Send by mail Print  Save  Delicious 
Date: Saturday, 28 Jun 2014 16:50

Hace unos meses comencé a implementar un intérprete del lenguaje Dylan, para practicar TDD en C#, además de aprender algo de programación funcional. Leo en:

http://opendylan.org/

Dylan is a multi-paradigm functional and object-oriented programming language. It is dynamic while providing a programming model designed to support efficient machine code generation, including fine-grained control over dynamic and static behaviors.

Lo interesante de Dylan es que incorpora tipos y objetos. Por ahora no pretendo generar código de máquina, sino, siguiendo “baby steps”, implementar los conceptos principales del lenguaje como un intérprete. Me gustaría igual agregar acceso a las librerías .NET, lo que me parece interesante para ampliar el alcance del lenguaje. Pueden aprender más del lenguaje en:

http://opendylan.org/documentation/intro-dylan/index.html

El proyecto que escribo en C# está en:

https://github.com/ajlopez/DylanSharp

y su estructura actual es:

Consta de una librería de clases, y un proyecto de tests. Hasta ahora hay algunas expresiones simples implementadas, un Parser, un Lexer, y un concepto del lenguaje implementado como clase C#: List, que implementa listas como en Lisp. Como en otros proyectos, tengo Context para mantener los valores de las variables, y recuperarlas por nombre. Notablemente, en Dylan las variables tienen tipo, pero aún no estoy controlando los tipos, simplemente evaluando expresiones cualesquiera. Tendré que tomar la decisión en algún momento, de controlar los tipos en el momento de compilar/procesar el programa. Según:

http://opendylan.org/documentation/intro-dylan/expressions-variables.html#type-declarations

Type mismatch errors should be caught at compile time.

Pero ya llegará el momento. Avanzando con TDD, tengo confianza en que llegado el caso podré hacer un refactor/rediseño de los que llamo quirúrgico, sin que sufra mucho el proyecto. Podría hacerlo en la próxima iteración o más adelante. Antecendentes de ese “approach” los he tenido en ScalaSharp, por ejemplo.

Próximos pasos: seguir implementado expresiones, definiciones de clases, módulos, comandos, funciones anónimas. Y controlar los tipos.

Nos leemos!

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

Author: "lopez" Tags: ".NET, C Sharp, Programación Funcion..."
Comments Send by mail Print  Save  Delicious 
Date: Saturday, 28 Jun 2014 11:50

Hace unos meses comencé a implementar un intérprete del lenguaje Dylan, para practicar TDD en C#, además de aprender algo de programación funcional. Leo en:


http://opendylan.org/


Dylan is a multi-paradigm functional and object-oriented programming language. It is dynamic while providing a programming model designed to support efficient machine code generation, including fine-grained control over dynamic and static behaviors.


Lo interesante de Dylan es que incorpora tipos y objetos. Por ahora no pretendo generar código de máquina, sino, siguiendo “baby steps”, implementar los conceptos principales del lenguaje como un intérprete. Me gustaría igual agregar acceso a las librerías .NET, lo que me parece interesante para ampliar el alcance del lenguaje. Pueden aprender más del lenguaje en:


http://opendylan.org/documentation/intro-dylan/index.html


El proyecto que escribo en C# está en:


https://github.com/ajlopez/DylanSharp


y su estructura actual es:



Consta de una librería de clases, y un proyecto de tests. Hasta ahora hay algunas expresiones simples implementadas, un Parser, un Lexer, y un concepto del lenguaje implementado como clase C#: List, que implementa listas como en Lisp. Como en otros proyectos, tengo Context para mantener los valores de las variables, y recuperarlas por nombre. Notablemente, en Dylan las variables tienen tipo, pero aún no estoy controlando los tipos, simplemente evaluando expresiones cualesquiera. Tendré que tomar la decisión en algún momento, de controlar los tipos en el momento de compilar/procesar el programa. Según:


http://opendylan.org/documentation/intro-dylan/expressions-variables.html#type-declarations


Type mismatch errors should be caught at compile time.


Pero ya llegará el momento. Avanzando con TDD, tengo confianza en que llegado el caso podré hacer un refactor/rediseño de los que llamo quirúrgico, sin que sufra mucho el proyecto. Podría hacerlo en la próxima iteración o más adelante. Antecendentes de ese “approach” los he tenido en ScalaSharp, por ejemplo.


Próximos pasos: seguir implementado expresiones, definiciones de clases, módulos, comandos, funciones anónimas. Y controlar los tipos.


Nos leemos!


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

Author: "lopez" Tags: "1389, 15035, 18254, 5374, 8871"
Comments Send by mail Print  Save  Delicious 
Date: Thursday, 26 Jun 2014 10:17

Desde la década pasada que me interesa Clojure, y desde siempre Lisp. Clojure está implementando sobre la máquina virtual de Java, pero también está implementado sobre .NET (que recuerde, usando Dynamic Language Runtime). La versión de Java compila a bytecodes Java. También hay una versión para JavaScript, llamada ClojureScript. La comunidad es muy activa, y ha traido un aire de renovación dentro de Java. Tiene características como la inmutabilidad de sus estructuras orientadas al trabajo en múltiples hilos evitando los problemas de lockeo y concurrencia. Tiene Software Transactional Memory, usando refs y transacciones,  pero ha sido menos usada por lo que veo. Han surgido frameworks web, y tiene un manejador de proyectos y dependencias Leiningen muy bien armado. Algunos enlaces en mis posts de Clojure.

Para practicar TDD (Test-Driven Development) y C#, he estado armando un intérprete (no un compilador a bytecodes), en .NET. Ver el proyecto en:

https://github.com/ajlopez/ClojSharp

El estado actual:

Tiene una librería de clases, otra de tests, y ya apareció un REPL (Read Eval Print Loop) sencillo como programa de consola.

En Lisp, una expresión se compone de un verbo y argumentos, expresados en una lista entre paréntesis. Por ejemplo una lista que al evaluarse devuelve la suma de 1, 2 y 3:

(+ 1 2 3)

Acá + (el signo más) es un símbolo que apunta a lo que en Lisp se llama una form, algo que recibe argumentos, opera con ellos y devuelve un resultado. Los argumentos que recibe un form en general se evalúan antes de serle entregados:

(+ 1 (- 3 4) 3)

Acá el primer argumento es una constante que vale uno, y el segundo argumento, antes de llegar al form de suma, ya es evaluado y vale –1 (menos uno). Pero hay forms que no necesitan evaluar los argumentos. Los reciben, digamos, en crudo. Se llaman special forms. Tengo implementados:

Y también tengo implementadas algunas forms (no especiales) como primitivas en C#. Muchas podrían ser implementadas en Lisp mismo, pero por ser tan básicas las implementé directamente en C#, usando TDD como es usual:

Próximos temas: la implementación de Machine, el Context, como se usa Parser y Lexer, más sobre evaluación de expresiones. Y mil temas más, como estructuras inmutables, macros, recursión optimizada, etc.

Nos leemos!

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

Author: "lopez" Tags: ".NET, C Sharp, Clojure, TDD, Proyectos d..."
Comments Send by mail Print  Save  Delicious 
Next page
» You can also retrieve older items : Read
» © All content and copyrights belong to their respective authors.«
» © FeedShow - Online RSS Feeds Reader