Resoluciones del Nuevo Mes: Octubre 2014

Hora de escribir las resoluciones del nuevo mes. Pero antes, repasar las de septiembre:

- Aktores con ejemplo distribuido [completo] ver repo
- AjErl con ejemplo distribuido [pendiente]
- Soporte web y ejemplo para RuScript [parcial] ver repo
- Completar Mochy [parcial] ver repo
- Mejorar RSharp [completo] ver repo
- Trabajar con NodeJs en los temas Deep Learning, Internet of Things, Artificial Intelligence [pendiente]
- Trabajar en Code Generation usando AjGenesis para Node [completo] ver repo principal ver repo Express ver repo Sinatra ver repo Laravel
- Trabajar en Liqueed Project [completo] ver repo

También estuve trabajando en:

- Mejorar AjScript [completo] ver repo
- Refactor BasicScript tests para usar SimpleUnit [completo] ver repo
- Crear SimpleColls, simple collection functions in JavaScript, alone or a la Linq [completo] ver repo
- Refactor SimpleStore tests para usar SimpleUnit [completo] ver repo
- Mejorar AjTalkJs, Smalltalk in JavaScript, soporte de primitiva super, primeros ejemplos Express 4 [completo] ver repo
- Refactor MProc tests para usar SimpleUnit [completo] ver repo
- Refactor AjLogoJs tests para usar SimpleUnit [completo] ver repo
- Refactor SimpleKeeper tests para usar SimpleUnit [completo] ver repo
- Refactor SimpleTags tests para usar SimpleUnit [completo] ver repo
- Mejorar SimpleUnit, publicar nueva versión [completo] ver repo
- Refactor SimplePipes tests para usar SimpleUnit, y publicar nueva versón [completo] ver repo

Las resoluciones de este nuevo mes:

- Dar una charla de introducción a Aktores, actor model distribuido en C#
- Armar AjErl ejemplo distribuido
- Más ejemplos Express en AjTalkJs
- Explorar redes neuronales en JavaScript
- Explorar algoritmos genéticos en JavaScript
- Explorar otros temas de Inteligencia Artifical en JavaScript
- Más Aktores distribuidos
- Comenzar Distributed Smalltalk en AjTalkJs

Nos leemos!

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

Posted in .NET, C#, JavaScript, Liqueed, NodeJs, Proyectos Open Source, Resoluciones | Leave a comment

Code Coverage y Calidad de Código

Voy a usar directamente la expresión en inglés “code coverage” para lo que en español es cubrimiento de código. La pregunta de hoy es ¿hay relación entre un gran nivel de code coverage y calidad de código?

Primero, el code coverage es una métrica: simplemente eso, ni más ni menos. Si conseguimos el porcentaje de code coverage luego, digamos, de ejecutar todos los tests del sistema, un alto porcentaje con todos los tests en verde sólo indica que al ejecutar los tests pasamos por una gran cantidad de líneas de nuestro código, sin provocar un error.

Pero cualquiera que se ponga a meditar sobre eso, no puede concluir así por que sí, que eso indique una buena calidad de código. Bien podemos imaginarnos código que cumpla con todo eso (buen métrica, pruebas que pasan) y que NO TENGA UNA BUENA CALIDAD de código. Por ejemplo, bien podemos refactorizar todo el sistema para que el código quepa en una clase, con cientos de métodos, y el code coverage seguirá alto y las pruebas pasarán. Y así se nos pueden seguir ocurriendo refactorizaciones, que bajen la calidad de código, sin que la métrica de code coverage se vea afectada en gran medida.

Tenemos que ponernos de acuerdo en qué es calidad de código, pero para este post, podemos tomar algunas cualidades:

- Que el código ejecute lo que se espera
‘- Que sea modificable/extensible de una forma accesible

Vean que no pongo que sea “entendible” porque me imagino que esa cualidad es un requisito de la segunda que puse arriba. La primera cualidad se puede dividir en:

- Que el código de el resultado esperado ante las entradas correctas
- Que el código reaccione de la manera esperada ante las entradas incorrectas

y así podríamos seguir refinando. Igual es tema para discutir. Pero aún no podemos esperar, con las cualidades de arriba u otras que se nos ocurran, que ante un gran nivel de code coverage obtengamos, de forma casi mágica, una buena calidad de código.

Entonces, si alguien espera que subiendo el code coverage de una aplicación/sistema/librería, escribiendo pruebas para subir esa métrica, de esa forma vamos a obtener/mejorar la calidad de código, les digo una cosa: es loable lo suyo, pero es tan inútil como alinear las sillas en la cubierta del Titanic. Están haciendo algo que parece bueno, pero no es lo que hay que hacer.

Alguien podría decir: ¿pero acaso las pruebas que acompañan al aumento de code coverage, no nos aseguran que el código inicial tenga la calidad esperada? Si hacen las pruebas DESPUES de escribir el código, muchas veces eso no se cumple. Porque se van a ver motivados a elevar la métrica, no la calidad del código. Pongamos un ejemplo en concreto. Sea un método que recibe los argumentos a y b, y revuelve a/b (su división). Al principio no está cubierta, agregamos una prueba que invoca a ese método pasando a=1, b=2 y vemos que devuelve 0.5. Ahora el code coverage subió, de 0 a 100%. Las pruebas pasan. Pero no tenemos idea de haber cubierto los (MINI)CASOS DE USO de ese método. Por ejemplo, nunca probamos que pasa cuando b=cero.

Ese es uno de los problemas de los “pruebas después”. No se cubren los casos de uso de nuestra aplicación. Y si encima nos dejamos guiar por aumentar el code coverage, menos vamos a concentrarnos en los casos de uso. Y si siguen el camino “pruebas después” también se encontrarán, más frecuentemente de lo necesario, que el código ya armado es difícil de probar, o lo van a modificar de formas extrañas para que podamos tener la recompensa del día: uy! aumentamos el code coverage! ¡Qué buenos programadores que somos, qué buena calidad de código!

No me malinterpreten: el code coverage sirve, pero NO ASEGURA calidad de código. Ni siquiera la mantenibilidad de un sistema. No es difícil encontrar sistemas con alto code coverage, uno los modifica, las pruebas pasan, pero luego, el sistema web vuela luego de dos clicks en las páginas. ¿Por qué? De nuevo, porque el code coverage alto y las “pruebas después” no aseguran para nada que hayamos contemplado todos los casos de uso (como el simple de más arriba, dividor por b igual a cero, el método tiene 100 por ciento de code coverage, pero no tiene el 100 por ciento de los casos de uso).

Algo de valor agrega el subir el code coverage, porque al final, alguna de las pruebas adicionales algo nuevo cubre. Pero es lo que alguien ha llamado “pica pica bajada de cordón (de vereda)”, trabajo que agrega poco valor en general a lo que programamos, y que lleva tiempo.

Bueno, luego de esta larga diatriba, algo de agua para mi molino:

Si en vez de intentar subir el code coverage con pruebas después, seguimos el FLUJO DE TRABAJO de Test-Driven Development, el code coverage alto es como que viene de la mano de ese flujo de trabajo, sin gran esfuerzo. Si aplicamos ese flujo a cubrir cada caso de uso, vamos construyendo software que va creciendo, como un organismo, paso a paso, de la manera más simple, y asegurándonos que cada prueba que agregamos responde a una necesidad del sistema que estamos armando. El código va fluyendo, naciendo, transformándose, y la etapa de refactor es de importancia para aumentar la calidad, no para el code coverage.

Espero que se haya entendido: sin TDD, no hay paraíso :-)

Nos leemos!

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

Posted in Programacion, Test-Driven Development | Comments Off

Cortando la cola del pavo

Había una vez una familia que se reunía una vez por año, para celebrar juntos. La dueña de casa solía cocinar al horno un pavo relleno. Una receta que habia pasado de generación a generación, por vía oral, especificaba qué colocarle, cuánto tiempo cocinarlo, cómo preparar el relleno. Pero había algo que hacía siempre: cortarle la cola al pavo. Alguien preguntó: “¿Por qué hay que cortarle la cola al pavo? ¿Por qué está esa instrucción en la receta?”. Sorprendentemente, la cocinera sólo atinó a responder: “No sé, así lo hacía mi mamá, así me lo enseñó”. Fueron a preguntarle a la madre: “No sé, a mí también me lo enseñó así mi mamá”. Le preguntaron a la abuela: “Yo tampocó sé, así me lo enseñó mi mamá, en mi infancia”. Y al final, llegaron a la bisabuela: “Bueno, cuando vivíamos en Europa, en una casita en el campo, el pavo no entraba en el horno, y teníamos que cortarle la cola”.

¿Cuántas veces nos pasa, en nuestras actividades, profesionales o no, “cortar la cola al pavo”, sin notar que las fuerzas que llevaban a esa conducta ya desaparecieron?

Para poner un poco de contexto, veamos un ejemplo en el desarrollo de software. Cuando aparecieron las primeras microcomputadores, no había discos duros, solamente discos flexibles. Y muchas veces, la computadora sólo tenía disponible una dispositivo de discos flexibles (la “diskettera”). Recuerdo un sistema de sueldos y jornales, a principio de los ochenta. A fin de año había que calcular por empleado cuánto tenía que abonarse de aguinaldo. La ley había cambiado: ya no era un monto asociado al último sueldo, sino lo que había cobrado por cada cada mes. No había forma que un disco flexible tuviera toda esa información. Así que el operador, para calcular el aguinaldo, tenía que introducir y retirar uno por uno los discos de las liquidaciones mensuales. Eran las limitaciones de esos tiempos.

Y en minicomputadores, los discos duros no eran el último lugar de resguardo. Se usaban cintas, para sacar copias de los programas y los datos.

Desde los “mainframes” fue llegando la implementación de bases de datos (relaciones, jerárquicas, en red, aunque sólo sobrevivieron las primeras; la nueva “onda” de NoSQL no es tan nueva :-). Y la próximas implementaciones de los sistemas en computadores personales pasaron a usar bases de datos, en general relacionales.

Y siguió el progreso. Pero algo quedó de resabio, de reliquia, algo como “cortar la cola del pavo”: hoy se piensa en tener todo en la base de datos. Pero hoy tenemos gran cantidad de memoria disponible. Muchas veces, podemos tener nuestro dominio TOTALMENTE en memoria, y muchos casos de uso son de “muchas lecturas, escrituras esporádicas”. Pero en vez de aprovechar directamente la memoria (vean que puse TODO el dominio en memoria, no estoy hablando de “cache” selectivo), todavía se inicia el desarrollo de un sistema viendo el esquema de base de datos.

No digo que sea aplicable a todos los casos, pero en muchos sistemas, la base de datos (o el disco, al final), es la “nueva cinta”: la forma de resolver la persistencia. Pero la operación bien podría hacerse completamente en memoria. Aún en memoria distribuida. Por ejemplo, en Facebook, en su implementación, todo es un objeto (una persona, una relación, un mensaje, una foto, …), y se almacena en un sistema que llaman TAO (de The Abstract Object). Usan MySql (muchas bases) sólo para persistencia. La operación la resuelvan en memoria: TAO corre en multitud de máquinas distribuidas en varios data center, y usa MySQL principalmente para persistencia, y replicación, apenas para el negocio.

No hace falta ser Facebook para aprovecharse de “primero la memoria”, en vez de “hay que cortar la cola del pavo, hay que usar base de datos relacionales”. En un sistema que estuve examinando, con un caso de “muchas lecturas, pocas escrituras”, pude implementar el caso de uso principal en memoria, quedando CUATROCIENTAS VECES más rápido (no digo 400 por ciento, digo 400 VECES). Y otro proceso, que tardaba en el orden de las ocho horas, paso a ejecutarse en minutos, adoptando un modelo en memoria.

Y ése es sólo un ejemplo. Ahora, agua para mi molino:

Test-Driven Development (TDD), al empujarme, como flujo de trabajo, hacia la implementación más simple, casi como que me impide complicarme con soluciones que níngún caso de uso pidió. Sólo se adopta una base de datos relacional, o un NoSQL, cuando el caso de uso lo pide. Y siguiendo TDD he notado que esa decisión, que puede ser diferida, aún cuando se tome, se puede cambiar en el futuro. Por eso soy escéptico cuando alguien quiere plantear cuáles herramientas usar ANTES DE PASAR por los casos de uso.

Con el caso de uso “nuevo horno más grande” desde el principio, nunca se llega a implementar “cortar la cola del pavo”.

Nos leemos!

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

Posted in Programacion, Test-Driven Development | Comments Off

Mis próximas Charlas en Buenos Aires: Actores en C#, Single Page Applications

Tengo varios temas que quiero tratar, en distintos lenguajes y tecnologías. Hoy quiero comentar dos charlas que se vienen, que puedo dar gracias al Microsoft User Group:

Aplicaciones Distribuidas en C#, un modelo de actores

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

Lugar: Auditorio del MUG, Rivadavia 1479 Primer Piso “A”, Buenos Aires.
Fecha y Horario: Miércoles 8 de octubre de 2014 de 18:30 a 20:30 hs.

La idea es presentar conceptos de actores, y actores distribuidos, comentar la principal implementación en Java: Akka. Y luego pasar a discutir y mostrar una implementación en C#

Luego

Desarrollando Single Page Applications con JavaScript

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

Lugar: Auditorio del MUG, Rivadavia 1479 Primer Piso “A”, Buenos Aires.
Fecha y Horario: Miércoles 29 de octubre de 2014 de 18:30 a 20:30 hs.

Veremos las fuerzas que llevan a la aparición de aplicaciones web compuestas de una sola página, con dinámica en JavaScript. Siguiendo “baby steps” y simplicidad, exploraremos cómo podemos armar algún ejemplo con simple JavaScript y JQuery, cómo alimentar los datos desde un servidor con una API expuesta (agnóstico de la tecnología) y luego visitaremos algunas librerías JavaScript del lado cliente que nos ayudan, como Angular y Backbone.

Espero que estas charlas aporten algo a estos temas, entre tantos que son interesantes en estos tiempos. Estoy preparando otras charlas, como Inteligencia Artificial en JavaScript para la JSConf 2014 de Argentina. Y espero que me aceptan alguna más, sobre JavaScript y Ruby, en la RubyConf 2014 de Argentina.

Nos leemos!

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

Posted in .NET, Arg, Argentina, Buenos Aires, C#, Charlas, Desarrollo Web, JavaScript | Comments Off

Resoluciones del Nuevo Mes: Septiembre 2014

Un poco tarde esta vez, es tiempo de revisar mis resoluciones de Agosto:

- Escribir un reemplazo de jQuery para ser usado en tests de consola con Node.js [completo] ver repo
- Escribir funciones simples en JavaScript para manipulación de arreglos [completo] ver repo
- Continuar con proyecto Liqueed [completo] ver repo
- Comenzar con Aktores Distribuido [parcial] ver repo
- Comenzar con AjErl Distribuido [pendiente]

Además, trabajé en:

- Dar una charla de introducción a Express [completo] ver repo ver presentación ver ejemplos
- Mejorar AjScript [completo] ver repo
- Mejorar RuScript, Ruby intérpreter en JavaScript [completo] ver repo
- Refactor SimplePipes [completo] ver repo
- Generar código del servidor Node.js/Express desde RAML [completo] ver repo
- Crear un sitio dinámico descripto en JSON para Express [completo] ver repo
- Mejorar RustScript, intérpreter de Rust en JavaScript [completo] ver repo
- Crear Mochy, test framework a la Mocha [completo] ver repo
- Crear RSharp, language intérpreter de lenguaje R en C# [completo] ver repo
- Refactorizar (y simplificar) SimpleRules, motor de reglas en JavaScript [completo] ver repo
- Primeros ejemplos para SimpleMule [completo] ver repo
- Mejorar salida para SimpleUnit [completo] ver repo

Mis resoluciones para el nuevo mes:

- Aktores distribuidos
- AjErl distribuidos
- Soporte web y ejemplo en RuScript
- Completar Mochy
- Mejorar RSharp
- Trabajar con NodeJs en Deep Learning, Internet of Things, Artificial Intelligence
- Trabajar en Code Generation usando AjGenesis para Node
- Trabajar en Liqueed Project

Nos leemos!

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

Posted in .NET, C#, JavaScript, NodeJs, Proyectos Open Source, Resoluciones | Leave a comment

RuScript, Ruby Intérprete en JavaScript (1) El Proyecto

Desde hace unos meses estoy trabajando en mi tiempo libre en:

https://github.com/ajlopez/RuScript

Y escribiendo todo siguiendo el flujo de TDD (Test-Driven Development) (ver la historia de commits)

La idea es tener un intérprete de Ruby escrito en JavaScript, que pueda correr en el browser o en el server (en este caso con Node.js). No estoy implementando un compilador a JavaScript, porque quiero seguir “baby steps”, y porque veo que la semántica de Ruby puede ser bastante distinta de la de JavaScript en algunos casos. La resolución de métodos a invocar, o ver si una variable es de instancia, de clase o local a una función, son temas que difieren entre los dos lenguajes. Así que me he decantado por escribir un intérprete.

Estoy aplicando “dog fooding”, porque el parser está construido basado en:

https://github.com/ajlopez/SimpleGrammar

Que también estoy aplicando en otros proyectos, como RustScript. (Hay implementación de SimpleGrammar en C#, ver GrammGen). Fragmento de las reglas definidas para el parser de RuScript:

// Expression Level 1
get('Expression1').generate('Expression'),
get('Expression1', 'Plus', 'Expression0')
    .generate('Expression1', function (values) { return new AddExpression(values[0], values[2]); }),
get('Expression1', 'Minus', 'Expression0')
    .generate('Expression1', function (values) { return new SubtractExpression(values[0], values[2]); }),

// Expression Level 0
get('Expression0').generate('Expression1'),
get('Expression0', 'Multiply', 'Term')
    .generate('Expression0', function (values) { return new MultiplyExpression(values[0], values[2]); }),
get('Expression0', 'Divide', 'Term')
    .generate('Expression0', function (values) { return new DivideExpression(values[0], values[2]); }),

// Term
get('Term').generate('Expression0'),
get('Term', 'LeftBracket', 'ExpressionList', 'RightBracket')
    .generate('Term', function (values) { return new IndexedExpression(values[0], values[2]); }),
get('Integer').generate('Term'),
get('@@', 'Name').generate('ClassVariable', 
    function (values) { return new ClassVariableExpression(values[1].getName()); }),
get('@', 'Name').generate('InstanceVariable', 
    function (values) { return new InstanceVariableExpression(values[1].getName()); }),
get('Name').generate('Term'),
get('InstanceVariable').generate('Term'),
get('ClassVariable').generate('Term'),
get('String').generate('Term'),
get('Array').generate('Term'),
get('LeftParenthesis', 'Expression', 'RightParenthesis')
    .generate('Expression0', function (values) { return values[1]; }),
get('LeftBracket', 'RightBracket')
    .generate('Array', function (values) { return new ArrayExpression([]); }),
get('LeftBracket', 'ExpressionList', 'RightBracket')
    .generate('Array', function (values) { return new ArrayExpression(values[1]); }),


Por cada elemento que voy descubriendo, voy armando una expresión, que puede evaluarse dado un contexto (un contexto indica cuales son las variables accesibles en determinado momento, y sus valores respectivos). Ejemplo:


function NameExpression(name) {
    this.evaluate = function (context) {
        var value = context.getValue(name);
        
        if (typeof value == 'function')
            return value();
        
        return value;
    };
    
    this.getName = function () { return name; };
    
    this.setValue = function (context, value) {
        context.setLocalValue(name, value);
    }
}

function InstanceVariableExpression(name) {
    this.evaluate = function (context) {
        if (!context.$self.$vars)
            return null;
            
        return context.$self.$vars[name];
    };
    
    this.getName = function () { return name; };
    
    this.setValue = function (context, value) {
        if (!context.$self.$vars)
            context.$self.$vars = { };
            
        context.$self.$vars[name] = value;
    }
}

function ClassVariableExpression(name) {
    this.evaluate = function (context) {
        if (!context.$self.$class.$vars)
            return null;
            
        return context.$self.$class.$vars[name];
    };
    
    this.getName = function () { return name; };
    
    this.setValue = function (context, value) {
        if (!context.$self.$class.$vars)
            context.$self.$class.$vars = { };
            
        context.$self.$class.$vars[name] = value;
    }
}

function ConstantExpression(value) {
    this.evaluate = function () {
        return value;
    };
}


Tengo acceso a JavaScript desde Ruby, por ejemplo, un test:


exports['Evaluate JavaScript global name'] = function (test) {
    global.myglobal = 42;
    var context = contexts.createContext();
    var parser = parsers.createParser("js.myglobal");
    //parser.options({ log: true });
    var expr = parser.parse("Expression");
    var result = expr.value.evaluate(context);
    test.equal(result, 42);
}



El “namespace” js es el que posibilita acceder a las variables definidas en JavaScript y a todo su ecosistema, ya sea en el browser o en el servidor Node.


Espero poder presentar mi avance en la RubyConf 2014 de Argentina.


Próximos pasos: acceder a los “require” de Node.js, ejemplos de sitios web usando Node.js/Express, ejemplos de consola, ejemplos en el browser, etc.


Nos leemos!


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

Posted in Interprete, JavaScript, Node, NodeJs, Proy, Proyectos Open Source, Ruby, RuScript, Test-Driven Development | Comments Off

Ágiles Argentina 2014 – Primeras Jornadas Nacionales de Metodologías Agiles

Argentina (y Buenos Aires) sigue siendo un lugar de gran actividad en la difusión de lo ágil en el desarrollo de software y otros ámbitos. Se vienen dos días de jornadas, viernes 26 y sábado 27 de Septiembre, ver:

http://www.meetup.com/agiles-bsas/events/191103222/

Friday, September 26, 2014 9:00 AM
to Saturday, September 27, 2014, 6:00 PM

Universidad de Belgrano
Lacroze 1947, Buenos Aires (map)

Realizaremos nuestras primeras Jornadas Nacionales de Metodologías Agiles, en Formato Open Space.
Nos juntamos con ganas de compartir experiencias, buenas prácticas y aprender más sobre metodologías agiles.

Más información en el sitio oficial:

http://aa2014.agiles.org/

El formato es Open Space, no hay una agenda predefinida. Se puede ir proponiendo y votando temas en:

https://agilesargentina.uservoice.com/forums/261590-%C3%81giles-argentina-2014-26-y-27-sept-en-buenos-aire

Ágiles Argentina 2014, las Primeras Jornadas Nacionales de Metodologías Ágiles, es un evento de la Comunidad Ágil Argentina. Tendrá como sede a la Universidad de Belgrano , en la Ciudad de Buenos Aires, los dias 26 y 27 de Septiembre. Ver detalles del evento en http://aa2014.agiles.org/

Una novedad, el catering (comida, bebidas, infusiones, etc) será autoorganizado, comprometerse en alguno de los puntos de:

http://aa2014.agiles.org/catering-auto-organizado/

Si esto no es lo ágil, lo ágil ¿donde está? :-)

Nos leemos!

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

Posted in Agile, Argentina, Buenos Aires | Leave a comment

Hackathon Abierto en Buenos Aires

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

Posted in Buenos, Buenos Aires, Hackathon, Java, Programacion, Reunion | Leave a comment

Próximo Meetup JavaScript en Buenos Aires: Express y D3

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

Posted in Buenos Aires, JavaScript, Meetup, NodeJs | Leave a comment

Resoluciones del Nuevo Mes: Agosto 2014

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

Posted in .NET, C#, JavaScript, NodeJs, Proyectos Open Source | Leave a comment