• 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: Sunday, 20 Apr 2014 12:13

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

Author: "lopez" Tags: "Desarrollo de Software, Programació..."
Comments Send by mail Print  Save  Delicious 
Date: Saturday, 19 Apr 2014 11:01

El año pasado participé de la competición Node.js Knockout organizada por Nodejitsu. Fueron dos días de programación (sábado y domingo), enviando código a sus servidores. Trabajé solo (en general se trabaja en equipos), en el Solo Ninja team. Mi idea era empujarme a escribir algo que tenía pendiente. Mi proyecto, en gran parte escrito siguiendo el flujo de TDD, trata de definir una o más aplicaciones, en forma interactiva. Cada aplicación puede tener una o más entidades. Cada entidad tiene propiedades, como campos de texto, o imágenes, enlaces, etc. Tengo que agregar relaciones uno a varios entre entidades.

Pueden ver mi presentación en video para los jueces en:

http://youtube.com/watch?v=GQdyyNWCasI

(Please visit the site to view this media)

Despues de la competición, publiqué el código en mi cuenta de GitHub:

https://github.com/ajlopez/MyApps

Me parece interesante esto de explorar el definir dinámicamente una aplicación, en lugar de escribirla manualmente o de generar código para un modelo. En otros años pasados, yo sería más excéptico, pero lenguajes dinámicos como JavaScript son muy poderosos y flexibles. Y combinado con Node.js, es un dúo imparable para ayudar en la implementación de este tipo de aplicaciones. Quiero extender estas ideas para generar clientes no sólo web, sino mobile (primer paso, usar Phonegap), y quizás aplicaciones nativas que sepan interpretar la definición de una aplicación. Me imagino agregando también algo de código definible por el usuario en algunos puntos de extensión. Estoy estudiando Force, de Salesforce, y las semanas pasadas estuve viendo el modelo de aplicaciones de SharePoint online. Algunas ideas, entonces:

- Agregar tareas escritas en lenguaje de programación (un JavaScript controlado, digamos)
- Más programas cliente, que tomen una aplicación (definida simplemente, por ejemplo en un JSON), y la ejecuten para web, mobile, nativo, etc.
- Tener application stores, públicas y privadas
- Poder instalar para nuestra aplicacion o sitio de aplicaciones, aplicaciones de otros

Tengo también “in-pectore” una implementación más sencilla de lo que era Hypercard, pero eso es tema para otro post.

Esta noche el mundo, Pinky! ;-)

Nos leemos!

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

Author: "lopez" Tags: "Video, Javascript, Proyectos de Cód..."
Comments Send by mail Print  Save  Delicious 
Date: Tuesday, 08 Apr 2014 11:27

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

Author: "lopez" Tags: "Desarrollo de Software, Desarrollo Agil,..."
Comments Send by mail Print  Save  Delicious 
Date: Monday, 07 Apr 2014 11:40

Anterior Post

Ayer grabé una nueva sesión de esta serie, como Google Hangout. Queda en:

https://www.youtube.com/watch?v=OcRSDwcBAIA

(Please visit the site to view this media)

El tema de esta sesión fue aplicar lo visto en las dos anteriores: programar en JavaScript, usar require de Node.js, usar módulos “built-in” como http, url, y refactorizar código, para tener un mini servidor web, que produce distintos resultados de acuerdo a lo que se pida en el navegador.

El código del ejemplo quedó en:

https://github.com/ajlopez/NodeSamples/tree/master/WebServer

En las próximas sesiones:

- Más refactorización (por ejemplo, extraer el proceso de rutas como un módulo)

- Servir archivos estáticos, donde tendremos nuestro primer contacto con streams, y con el módulo fs

- Con otro ejemplo, comenzar algo de TDD

Y temas para más adelante: programar con Express (para no hacer el ruteo de acciones nosotros) y con Socket.IO (para empezar a ver el tema real time)

Nos leemos!

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

Author: "lopez" Tags: "Video, Javascript, NodeJs"
Comments Send by mail Print  Save  Delicious 
Date: Sunday, 06 Apr 2014 17:02

Llega revisión de mis resoluciones de marzo:

- Trabajar en DictSharp [completo] ver repo
- Dar una charala sobre Aplicaciones Distribuidas en Node.js [completo] ver repo ver presentación
- Mejorar SimpleGammon [completo] ver repo
- Mejorar Annalisa [completo] ver repo
- Agregar @for a Templie [pendiente]
- Trabajar en PreciosaAnnalisa online web services [completo] ver repo
- Mejorar mis ejemplos de Aplicaciones Distribuidas en Node.js [completo] ver repo ver repo ver repo
- Trabajar en ScalaSharp [completo] ver repo
- Mejorar ClojSharp [completo] ver repo
- Mejorar SimpleAsync, operación do (funciones en “paralelo”) [pendiente]
- Mejorar Aktores [pendiente]
- Mensajes distribuidos en AjErl [pendiente]
- Agregar alcance de variables al lenguaje Mass [pendiente]
- Comenzar a codificar generation as a service [parcial]

Adicionalmente, estuve trabajando en:

- Complexo, operaciones de números complejos en JavaScript [completo] ver repo
- Comenzar RustScript, un intérprete de Rust en JavaScript [completo] ver repo
- Continuar RuScript, intérprete de Ruby en JavaScript [completo] ver repo
- Continuar RubySharp, intérprete de Ruby en C# [completo] ver repo
- Comenzar AjLispScala, intérprete Lisp en Scala, usando TDD y SBT [completo] ver repo
- Grabar un segundo video de aprendiendo Node.js [completo] ver post

Para este nuevo mes, mis resoluciones son:

- Continuar AjLispScala
- Continuar AjGenesisNode-Express
- Continuar AjGenesisNode-PHP
- Continuar RuScript
- Continuar RustScript
- Mensajes distribuidos en AjErl
- Dar una charla de introducción a Node.js
- Publicar un nuevo video de Aprendiendo Node.js

Nos leemos!

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

Author: "lopez" Tags: "C Sharp, AjLisp, Lenguajes de Programaci..."
Comments Send by mail Print  Save  Delicious 
Date: Friday, 21 Mar 2014 09:49

Anterior Post 
Siguiente Post 

Hoy llega mi segundo video explorando Node.js. Verlo en

http://www.youtube.com/watch?v=wHZd88HT2fE

(Please visit the site to view this media)

Lo que escribí quedó en
https://github.com/ajlopez/NodeSamples
en el directorio Modules
En esta edición exploramos lo que es el require y qué es un módulo escrito por nosotros. Vimos el "cache" de módulos, el acceso a variables globales, la definición local de variables y funciones, y cómo exportar elementos explícitamente para poder ser consumidos por el programa que USA al módulo.
En los próximos videos/experiencia veremos cómo escribir un módulo con TDD, y cómo instalar, consumir módulos del ecosistema.
Nos leemos!
Angel “Java” Lopez 
http://www.ajlopez.com 
http://twitter.com/ajlopez
Author: "lopez" Tags: "Video, Javascript, NodeJs, Google"
Comments Send by mail Print  Save  Delicious 
Date: Sunday, 09 Mar 2014 12:15

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

Author: "lopez" Tags: ".NET, Java, C Sharp, Javascript, Proyect..."
Comments Send by mail Print  Save  Delicious 
Date: Tuesday, 25 Feb 2014 18:36

El sábado 15 de febrero, asistí a una Meteor meetup acá en Buenos Aires, una mitad de día lleno de charlas y codeo en Meteor. Gracias desde acá a los organizadores, ayudantes y “sponsors”: @areatreslab, @4residents, @bikestorming, @html5cat (ucraniano, viviendo en Vancouver, Canadá, interesante, graduado en matemáticas, con especialidad en análisis funcional; escribió hace un tiempo un function analysis paper), @matikalwill (a.k.a. “mi vida es bikestorming, seño”, iba a la escuela primaria con un cuaderno con su proyecto ;-).

Meteor es un framework para armar aplicaciones web. Y puede ser usado (y es usado) para armar aplicaciones móviles. Una aplicación Meteor, en general, es una Single Page Application (SPA), una aplicación que muestra una sola página y la va cambiando con JavaScript en el cliente, y pudiendo traer nuevos datos del servidor (y también mandar nuevos datos). El servidor está basado en nuestro viejo conocido, Node.js. Pero Meteor no es como otras aplicaciones Node. Ver primero:

https://www.meteor.com/

La principal diferencia: el lenguaje de programación es JavaScript, y PUEDE SER EJECUTADo en el servidor o en el cliente. Puede ser el MISMO código en ambos lados, o tener partes especializadas que ejecuten en el cliente y otras en el servidor.

Meteor se basa en siete principios:

http://docs.meteor.com/#sevenprinciples

  • Data on the Wire. Don't send HTML over the network. Send data and let the client decide how to render it.
  • One Language. Write both the client and the server parts of your interface in JavaScript.
  • Database Everywhere. Use the same transparent API to access your database from the client or the server.
  • Latency Compensation. On the client, use prefetching and model simulation to make it look like you have a zero-latency connection to the database.
  • Full Stack Reactivity. Make realtime the default. All layers, from database to template, should make an event-driven interface available.
  • Embrace the Ecosystem. Meteor is open source and integrates, rather than replaces, existing open source tools and frameworks.
  • Simplicity Equals Productivity. The best way to make something seem simple is to have it actually be simple. Accomplish this through clean, classically beautiful APIs.

Notablemente, el estado de la base de datos es compartida por todos los clientes en tiempo real. Si agregamos un nuevo registro a una colección de clientes (Meteor usa MongoDB en el servidor para la persistencia) EN EL CLIENTE, la actualización viaja al servidor, y se refresca en todas los datos de los clientes conectados. Por ejemplo, si un segundo cliente tiene en la pantalla una lista de clientes, automáticamente Meteor, por programación reactiva, sabe que esa lista tiene que actualizarla, porque cambió el modelo base que es la colección de clientes, y va la actualiza en el cliente. Todo esto sin agregar código adicional: simplemente declarando en JavaScript cómo los modelos de las vistas cliente dependen de alguna colección, en este caso, de la colección de clientes.

Aunque basado en Node.js, Meteor no es un paquete NPM (Node Package Manager). Debe ser instalado manualmente, leer:

http://docs.meteor.com/#quickstart

De esa forma, puede ser instalado en Linux/Unix y en Mac. La plataformas soportadas en:

https://github.com/meteor/meteor/wiki/Supported-Platforms

Pero si tenemos Windows (usé Windows en la reunión), tenemos que usar otro procedimiento, yo usé el ejecutable que está en:

http://win.meteor.com/

Hay soluciones basadas en Vagrant (que levantan una máquina virtual, pudiendo seguir trabajando en Windows, editando archivos de la VM, por ejemplo). Yo instalé el ejecutable del sitio de arriba, que se llama LaunchMeteor.exe, sin mayor problema, y lo probé en dos máquinas Windows. No hace falta tener Node pre-instalado, usa una versión interna, que está en su directorio de instalación, y tampoco molesta a otra instalación de Node ya existente en nuestras máquinas.

Leí:

http://docs.meteor.com/#structuringyourapp

A Meteor application is a mix of JavaScript that runs inside a client web browser, JavaScript that runs on the Meteor server inside a Node.js container, and all the supporting HTML fragments, CSS rules, and static assets. Meteor automates the packaging and transmission of these different components. And, it is quite flexible about how you choose to structure those components in your file tree.

The only server assets are JavaScript and files in the private subdirectory. Meteor gathers all your JavaScript files, excluding anything under the client, public, and private subdirectories, and loads them into a Node.js server instance inside a fiber. In Meteor, your server code runs in a single thread per request, not in the asynchronous callback style typical of Node. We find the linear execution model a better fit for the typical server code in a Meteor application.

El énfasis es mío. Vean que para tener el mismo código en cliente y en servidor, el código del servidor se ejecuta en una fibra, un truco de Node/V8 para no ver los callbacks y el async directamente. Tengo que revisar la escalabilidad, ver mis enlaces

https://delicious.com/ajlopez/meteor,scalability

Meteor tiene un manejador de paquetes no oficial Meteorite:

http://oortcloud.github.io/meteorite/

y tiene un repositorio de “smart packages”

https://atmosphere.meteor.com/

Estos paquetes saben qué poner en cada caso, en el cliente y el servidor. Y tienen funciones implementadas usando fibras.

Leo:

http://docs.meteor.com/#usingpackages

In addition to the packages in the official Meteor release being used by your app, meteor list and meteor add also search the packages directory at the top of your app. If you've downloaded an unofficial package from Atmosphere you should unpack it into that directory (the unofficial Meteorite tool streamlines this process). You can also use the packages directory to break your app into subpackages for your convenience — if you are willing to brave the fact that the Meteor package format is not documented yet and will change significantly before Meteor 1.0…

Lamentablemente, Meteorite no está aún disponible para Windows, así que tenemos que usar los paquetes built-in, que ya viene, o instalar un paquete manualmente. (ver el repo de mi proyecto mencionado más abajo, hay varios enlaces que tratan el tema).

Hay muchos recursos para ir aprendiendo Meteor:

https://www.meteor.com/learn-meteor

Por ejemplo, pueden probar los ejemplos (no necesitan Meteorite, así que funcionan en Windows):

https://www.meteor.com/learn-meteor

Durante la meetup, probé varios ejemplos, modifiqué alguno (el de leaderboard), y armé un sitio con Bootstrap 2.x y algún altas, listas, y me falta editar y borrar:

https://github.com/ajlopez/MeteorSamples

Varios enlaces con tutoriales, videos, ejemplos, en:

https://github.com/ajlopez/MeteorSamples#references

El ejemplo CRUD está en:

https://github.com/ajlopez/MeteorSamples/tree/master/mycompany

Usa solamente paquetes builtin, así que lo pueden ejecutar en Windows (ah! al igual que Node, no hace falta instalar MongoDB; Meteor viene con uno propio).

Con un comando de Meteor, puede publicar un ejemplo en la web de Meteor. El mío quedó en:

http://mycompany.meteor.com/

Voy publicado Meteor-related links. Más enlaces en:

https://delicious.com/ajlopez/meteor
https://delicious.com/ajlopez/meteor,tutorial

Ah! Meteor puede ejecutarse en PhoneGap, para tener aplicaciones móviles en múltiples dispositivos, corriendo con acceso a lo nativo de cada uno:

https://delicious.com/ajlopez/meteor,phonegap

Mi plan: luego de terminar mi ejemplo, usarlo como base para generar con AjGenesis aplicaciones Meteor. Recuerden que AjGenesis usa un modelo libre, plantillas y tareas. Usaré la versión que tengo implementada en Node.js, que es la que más se adapta a multiplaforma. Una vez que tenga andando eso, generaré para PhoneGap, espero. Hasta podría usar la Build API de PhoneGap, accesible desde Node.js, para dar una experiencia de code generation as a service (como ya tiene un ejemplo de hace años de AjGenesis en .NET).

Me diviegto como logco ;-)

Nos leemos!

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

Author: "lopez" Tags: "Desarrollo Web, Mobile, Javascript, Node..."
Comments Send by mail Print  Save  Delicious 
Date: Sunday, 23 Feb 2014 17:42

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

Author: "lopez" Tags: "Desarrollo de Software, Desarrollo Agil,..."
Comments Send by mail Print  Save  Delicious 
Date: Monday, 17 Feb 2014 10:48

Siguiente Post

Estoy en tratativas de poner un curso en línea, sobre Node.js. Mientras tanto, veamos por acá algunos temas iniciales: qué es Node, como se maneja, qué es un módulo, qué es NPM, y así, hasta llegar, espero, a aplicaciones web con Express y a aplicaciones distribuidas.

Pero el más largo camino comienza con un solo paso. Así que ayer grabé un Google Hangout como para empezar a ver Node:

http://www.youtube.com/watch?v=t0GThj7SlxE

(Please visit the site to view this media)

Mostré el sitio de Node, los distintos instaladores, y luego jugué un poco con el REPL. También mostré ejecutar archivos de código. Los ejemplos que usé están en mi Github:

https://github.com/ajlopez/NodeSamples

en el directorio Simple

Mostré la existencia de variables predefinidas, como console y process. Y luego recuperé en una variable uno de los módulos “built-in” usando require. Ese es una gran puerta que nos de Node.js para hacer nuestras aplicaciones modulares. Y mostré un simple servidor web. Cuando mostré la documentación en línea, usé el módulo net. Espero que se haya entendido que el callback para CADA cliente está en el createServer y no en el listen.

Nos leemos!

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

Author: "lopez" Tags: "Video, Javascript, NodeJs, Google"
Comments Send by mail Print  Save  Delicious 
Date: Saturday, 08 Feb 2014 17:30

Revisión de mis Resoluciones de Enero:

- Comenzar a implementar un modelo de actores a la Akka en C# [completo] ver repo
- Comenzar a implementar un intérprete Scala en JavaScript [completo] ver repo
- Trabajar en AjErl, Erlang en C# [completo] ver repo
- Trabajar en Mass (tengo varias ideas para implementar más module pattern y scope de variables) [pendiente]
- Trabajar en DylanSharp [completo] ver repo
- Comenzar una implementacion de ML (JavaScript? C#?) [pendiente]

También trabajé en:

- Mejorar intérprete Scala en C# [completo] ver repo
- Agregar notación dot en mi intérprete Lisp en C# [completo] ver repo
- Mejorar el intérprete Ruby en JavaScript [completo] ver repo
- Mejorar el intérprete Clojure en C# [completo] ver repo
- Primeros templates y tasks generando código Sinatra desde AjGenesis para Node [completo] ver repo

Mis resoluciones para este nuevo mes:

- Completar mensajería distribuida en AjErl
- Completar notación dot en AjLisp para acceder a tipos y objetos nativos
- Mejorar ClojSharp
- Trabajar en ScaScript
- Trabajar en ScalaSharp
- Agregar alcance de variables a Mass
- Completar primera versión de model de actores Aktores en C#
- Más tareas de generación de código, plantillas, modelos en AjGenesis para Node, generando código para Express, Meteor, Sinatra

Nos leemos!

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

Author: "lopez" Tags: ".NET, C Sharp, AjLisp, Lenguajes de Prog..."
Comments Send by mail Print  Save  Delicious 
Date: Monday, 03 Feb 2014 09:50

El año pasado tuve el gran placer de asistir a Smalltalks 2013, en la ciudad de Rosario, Argentina.  Asistir a esa conferencia fue una gran experiencia para mí, con charlas interesantes, implementaciones más interesantes y muchas ideas para digerir. Además de encontrarme con gente como @garduino, @morplenauta y @hernanwilkinson.

Dí una charla sobre cómo implementar Smalltalk en C# y en JavaScript. Los principales repositorios están en:

http://github.com/ajlopez/AjTalk (lo presenté por primera vez en Smalltalks 2010)
https://github.com/ajlopez/AjTalkJs (lo presenté en Smalltalks 2011)

Mi charla, grabada gracias a la organización:

http://www.youtube.com/watch?v=-KFjSneVE2s

(Please visit the site to view this media)

La presentación:

https://github.com/ajlopez/Talks/tree/master/Smalltalks2013
http://ajlopez.github.io/Talks/Smalltalks2013/index.html
Mis otras charlas del año en http://ajlopez.github.io/Talks/

El primer proyecto, en C#, compila a bytecodes y los interpreta. También puede compilar a JavaScript, pero en los últimos meses conseguí que el proyecto de JavaScript no necesitara de este compilador. Pero quedó implementado un patrón Visitor que podría modificar para recorrer el árbol de expresiones y generar código para otros lenguajes, por ejemplo Python o Ruby. Lo bueno de la VM en C# es que puede acceder a tipos y objetos nativos de C#. Además hay actores, ejecución remota, ver mis posts.

El segundo proyecto es una implementación de Smalltalk en JavaScript. Internamente, tiene un compilador a JavaScript, pero también tiene un compilador a un arreglo de bytecodes, que luego puede interpretar. Ambos proyectos, el de C# y el de JavaScript, ahora soportan el consumo de módulos que se instalan usando NPM (el manejador de paquetes de Node.js).

En 2013, a AjTalkJs le agregué mucho mejor soporte de Node.js, con acceso a módulos, así que ahora puedo ejecutar aplicaciones Express desde Smalltalk:

 

Próximos experimentos: mensajes distribuidos. Esto es, un objecto en una máquina enviando un mensaje a un objeto en otra máquina/proceso, en una forma “fire and forget”. Pienso que el ecosistema de Node.js puede ser un buen lugar para estos experimentos. Mi trabajo en el tema en Distributed Applications with Node.js. Quiero ahora una aplicación Smalltalk distribuida. Quizás, si consigo que el protocolo de comunicación sea simple y enchufable, podría implementarlo en otras implementaciones de Smalltalk, o en otros lenguajes. Pero primero, “baby steps”  ;-)

Nos leemos!

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

Author: "lopez" Tags: "Smalltalk, C Sharp, Video, AjTalk, Javas..."
Comments Send by mail Print  Save  Delicious 
Date: Tuesday, 14 Jan 2014 17:31

Un poco tarde, pero es igual hora de documentar las resoluciones, algunas ya las comencé a hacer/aplicar.

Primero, revisión de mis resoluciones de diciembre:

- Dar un curso de un día de Node.js [completo]
- Refactorear y mejorar CobolScript [partial] ver repo
- Continuar escribiendo compilador Ruby en JavaScript [completo] ver repo
- Alcance de variables en lenguaje Mass [pendiente]
- Más módulos de AjTalkJs [pendiente]

Estuve trabajando en:

- Generación de Código usando AjGenesis para Node, y templates para Express [completo]
- Comenzar DylanSharp, intérprete Dylan en C# [completo] ver repo
- Comenzar a adaptar viejos sitios PHP [completo] ver repo y repo
- Comenzar a soportar módulos y tener un REPL para AjErl, mi intérpreter AjErl en  C# [completo] ver repo

Las resoluciones del nuevo mes son:

- Comenzar a implementar un modelo de actores a la Akka en C#
- Comenzar a implementar un intérprete Scala en JavaScript
- Trabajar en AjErl
- Trabajar en Mass (tengo varias ideas para implementar, como más patrón módulo y acceso a variables no locales)
- Trabajar en DylanSharp
- Comenzar un implementación de ML (JavaScript? C#?)

Más para divertirme ;-) Pero en especial, para practicar deliberadamente (“deliberate practice”) TDD (Test-Driven Development) y otros lenguajes/paradigmas.

Nos leemos!

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

Author: "lopez" Tags: "C Sharp, Lenguajes de Programación,..."
Comments Send by mail Print  Save  Delicious 
Date: Monday, 06 Jan 2014 11:35

En estos días, se preguntó en una lista del MUG sobre recursos para aprender ASP.NET MVC. Yo aprendí de a poco, a lo largo de los años, así que sé exactamente cómo sumergirse rápidamente en el tema. Pero puedo escribir y mencionar algunos pasos y recursos.

Primero, hay que comprender que MVC viene de Model View Controller. Y en el caso de ASP.NET MVC, está claramente implementado. En lugar de tener páginas Web Form, con una parte visible de diseño y una parte de código con eventos de ida y vuelta, el esquema de ASP.NET MVC es distinto.

Cuando un usuario pide una página como /customer, el código de ASP.NET MVC rutea (de hecho, hay un ruteador) ese pedido a un método de una clase controladora. Por ejemplo, al método Index dentro de CustomerController. Luego, ese método tiene que devolver información sobre la vista que hay que mostrar. Las vistas se programan en general como HTML con código embebido, de distintas “engines”, la más popular es Razor. Una vista es algo parecido (sólo parecido) al ASP clásico de los noventas. Pero cada vista recibe lo que se llama un modelo: por ejemplo, la vista de listado de clientes podría recibir un IList<Customer> como modelo (accesible desde la propiedad de la vista Model) y podría iterar sobre el modelo para producir un resultado.

Pero es mejor tener código de ejemplo, ver el resultado de una charla que dí en el MUG:

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

Donde se hicieron algunas páginas, y la lógica del dominio (simple) está en un proyecto de clases aparte. Vean que también puse tests. De hecho, la charla fue sobre cómo programar ASP.NET MVC usando TDD (Test-Driven Development). Ver mis posts sobre TDD. Por ejemplo la serie Escribiendo una Aplicación (ASP.NET MVC) usando TDD

Ver también el video que explica paso a paso el proceso, gracias a la gente de AltNet Hispano

Desarrollando una aplicación con TDD desde cero

No recuerdo dónde quedó el código de esa reunión, debe ser

https://github.com/ajlopez/TddRocks/tree/master/TddApp o
https://github.com/ajlopez/TddAppAspNetMvc

Tal vez es demasiado empezar con TDD en un tema nuevo, pero les recomiendo que una vez comienzen a dominar ASP.NET MVC, pasen a trabajar de esa manera. Puede comenzar top-down (con las vistas y primeros modelos de vistas, sin tener la lógica de negocio y el modelo de negocio), o pueden comenzar por “el medio”, armando con TDD todo el proyecto de clases donde resida la lógica y modelo de negocio.

Otro tema es el lenguaje: prácticamente todos están programando en C#. Si están con VB.NET, puede ser una buena oportunidad para cambiar de lenguaje. No es difícil, los conceptos y clases de .NET son los mismos.

ASP.NET MVC fue evolucionando. Ultimamente, tuvimos ASP.NET MVC 3, 4 y ahora 5. Lamentablemente, no son simples librerías, sino que dependen del framework .NET, y para las últimas versiones de MVC tienen que usar las últimas versiones de Visual Studio. Yo aconsejaría Visual Studio 2010 (no sé por qué, algún genio de Microsoft quitó los botones y funcionalidad de tests que había en VS 2008 y VS 2010, y en el VS 2012 hay un test explorer; por lo menos para mí, que sigo el flujo de trabajo de TDD, es bastante molesto; veré si puedo acostumbrarme). Si tienen VS 2010, iría directamente a ASP.NET MVC 4. Si tiene VS 2012, lo mismo (pero podría intentar instalar el MVC 5 si quieren). Me temo que las vistas generadas varían de versión a versión.

No hace falta, pero si quieren tener un panorama más amplio de la interfaz, pueden leer:

User Interface Patterns

Hay una explicación más detallada de lo que es ASP.NET MVC, para los que se inician en el tema, en:

An Absolute Beginner's Tutorial on ASP.NET MVC for Web Forms Developers

No lo necesitan tanto al principio, pero si quieren ver más detalles de routing:

Routing in ASP.NET MVC 3 Tutorial

Tienen varios recursos en el sitio de Microsoft:

Learn about ASP.NET MVC

Por ejemplo:

ASP.NET MVC Overview
Learn about the differences between ASP.NET MVC application and ASP.NET Web Forms applications. Learn how to decide when to build an ASP.NET MVC application.

Hay un buen listado de recursos en

ASP.NET MVC 4 Content Map

Si tienen VS 2012, pueden intentar hacer:

ASP.NET MVC Facebook Birthday App

Bien, hay de todo, como en botica. Bastante por hoy. Aprendan MVC (que en el ambiente web ha prendido como patrón, antes que en .NET, en Python y Ruby). Algunos enlaces más, en “potpourri”:

https://delicious.com/ajlopez/aspnetmvc
https://delicious.com/ajlopez/aspnetmvc,tutorial
https://delicious.com/ajlopez/aspnetmvc4
https://delicious.com/ajlopez/aspnetmvc5
https://delicious.com/ajlopez/mvc
https://delicious.com/ajlopez/mvc,computerhistory (interesante para ver de dónde viene MVC, que no nació para la web)

Nos leemos!

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

Author: "lopez" Tags: ".NET, C Sharp, Desarrollo Web, TDD, ASP...."
Comments Send by mail Print  Save  Delicious 
Date: Friday, 06 Dec 2013 09:25

Primero, revisar mis resoluciones de Noviembre:

- Comenzar un compilador de Python reducido a C, usando JavaScript [complet] repo
- Dar una charla sobre implementación de Ruby en C# [completo] slides repo
- Comenzar intérprete Ruby en JavaScrip [completo] repo
- Completar el alcance de variables en lenguaje Mass [pendiente]
- Dar una charla sobre interpretar y compilar lenguajes en JavaScript [completo] slides
- Escribir un framework web para AjTalkJs (para ser usado desde Node.js) (plano o MVC) [pendiente]
- Mejorar módulos NPM en AjTalkJs y AjTalk [parcial] repo
- Mejorar soporte de tests en AjTalkjs y AjTalk [pactial] repo
- Mejorar las estructuras de datos en AjErl [pendiente]

Mis resoluciones para Diciembre:

- Dar un curso de un día sobre Node.js
- Refactorizar y mejorar CobolScript
- Continuar escribiendo en intérprete de Ruby en JavaScript
- Terminar de definir el alcance de variables en el lenguaje Mass
- Más módulos iniciales para AjTalkJs

Nos leemos!

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

Author: "lopez" Tags: "Smalltalk, C Sharp, AjTalk, Javascript, ..."
Comments Send by mail Print  Save  Delicious 
Date: Wednesday, 20 Nov 2013 14:19

Anuncio por acá mi nueva charla de un día, un seminario (pago) con práctica de Node.js, en Buenos Aires, organizado gracias al Microsoft User Group de Argentina. Ver:

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

Fecha y Horario: Viernes, 6 de diciembre de 2013; Horario de 09:00 a 18:00 hs.
Lugar: Auditorio del MUG, Rivadavia 1479, 1er Piso Oficina A. Ciudad de Buenos Aires

La idea es que los asistentes vengan con notebook, tendremos acceso a Internet, y estaremos viendo de bajar y ejecutar ejemplos de Node.js. El temario abarca desde el lanzamiento de la consola Node, primeros comandos, require, entrada/salida asincrónica, atención HTTP, servidor Express, ejemplo con base de datos MongoDB, y real-time usando Socket.IO.

Veremos que JavaScript es un lenguaje muy flexible, y combinado con Node.js, nos abre todo un nuevo mundo de simplicidad y potencia. Con poca ceremonia, podemos tener algo andando, desde programas de consola, hasta servidores web, hasta aplicaciones distribuidas. Y el ecosistema de Node es muy dinámico e interesante. Combinando módulos, podemos crear aplicaciones.

Es prácticamente el único tema del que doy un seminario de un día, porque me parece que realmente vale el esfuerzo.

Nos leemos!

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

Author: "lopez" Tags: "NodeJs, Buenos Aires"
Comments Send by mail Print  Save  Delicious 
Date: Thursday, 14 Nov 2013 12:33

Hace unas semanas pude participar de la excelente PyCon Argentina 2013. Tengo que escribir sobre mi experiencia. Hoy quiero dejar publicado enlaces y comentarios sobre la charla que dí.

Como ya es costumbre, tiene que ver con JavaScrip y Node.js. Se centró en explicar mi trabajo para compilar Python a JavaScript, usando JavaScript. Mi presentación en:

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

Estuve usando Node.js:

http://nodejs.org/

El proyecto que presenté está en:

https://github.com/ajlopez/JPyScript

Pude compilar archivos .py a JavaScript en el momento, y acceder con import a los módulos de Node.js

Ver el uso de import http:

 

O ver el uso de import express:

 

Mencioné otros proyectos:

http://www.brython.info/
http://www.skulpt.org/
http://apppyjs.appspot.com/

Y hace poco apareció en mi radar:

https://github.com/PythonJS/PythonJS

Vean los benchmarks:

http://pyppet.blogspot.com.ar/2013/11/brython-vs-pythonjs.html

Mientras, como algo adicional, luego de volver a ver PyPy (lo mencioné en la charla del año pasado en la misma PyCon), se me ocurre explorar compilar Python a C. ver mis primeras pruebas en:

https://github.com/ajlopez/RedPython

Nos leemos!

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

Author: "lopez" Tags: "Python, Javascript, Proyectos de Có..."
Comments Send by mail Print  Save  Delicious 
Date: Friday, 08 Nov 2013 18:13

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:
 
(Please visit the site to view this media)
 
(Please visit the site to view this media)
 
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
Author: "lopez" Tags: "TDD, Argentina, Testing, Javascript, Nod..."
Comments Send by mail Print  Save  Delicious 
Date: Thursday, 07 Nov 2013 18:10

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

Author: "lopez" Tags: "Lenguajes de Programación, Reunione..."
Comments Send by mail Print  Save  Delicious 
Date: Wednesday, 06 Nov 2013 16:52

Como habran leído por acá, o por mi cuenta de Twitter, este mes pasado, Octubre, estuve bastante ocupado con tres charlas en sendas conferencias. Ahora estoy preparando una charla para RubyConf, y espero que otra charla sea aceptada en la fundación Uqbar. Por eso, este tardío aviso: se ha formado un meetup de tema JavaScript en Buenos Aires. Ver:

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

pero que podría extenderse a otras ciudades.

Mañana jueves será la primer reunión presencial:

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

Creo que ya estuve en SVC, para cuando fue una meetup de Scala. Bueno, va a haber varias charlas. Yo propuse una de TDD y JavaScript y fue aceptada. Así que mañana estaré ahí con ese tema. La idea es ver lo que siempre predico, por acá con posts y videos y por allá en mi cuenta de GitHub: código de producción debe ser escrito con TDD. Y la combinación TDD JavaScript es muy buena, porque domina y pone bajo control la flexibilidad del lenguaje y la tecnología.

Espero que se entienda: TDD NO ES SOBRE TESTS. Es un flujo de trabajo de diseño de software. Es Test-Driven Development, el sustantivo central es DEVELOPMENT. Lo de tests es una forma de conseguir ese flujo. Y que se entienda: TDD nos permite empujar, "pushear" por la simplicidad, evitando arquitecturas de astronauta.

Bueno, en cuanto pueda, publicaré por acá un resumen de la charla.

También habrá dos o una compartida charla sobre Grunt, algo cada vez más usado en distintas tecnologías, ver:

http://gruntjs.com/

No digan después que les avisé... lo mío es un apostolado :-)

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

 

Author: "lopez" Tags: "TDD, Argentina, Javascript, Buenos Aires..."
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