I have created a programming language for fun

Perhaps you will remember my last written article in which I explained why I have had created a video game for a very old computer using Assembler. If not, or you haven’t read it yet, here is the link.

Boredom is a great motivator, especially on weekends. You feel tired to try outdoor stuff and, as in my case, you don’t have TV (Well yes, I have one, but I only use it for Netflix… and I already saw all of it). In any case, be bored was always a great motivator, especially if something in the near future will cause me more boredom.

Coding repetitive code is, usually, one of those things. Once you did a connection to a database or iterate through an array or write something in the browser, the second time started to look quite similar than the first one, the third one is even more alike and so on.

When you did thousands of these operations like in my case, considering that I wrote my first line of code when I was 6 years old (42 now)… for sure you would pay whatever for something that give you the same result with a simple mouse click. And that is the idea behind Macro, this new programming language.

But, first some clarifications, in particular for those that don’t know me: I am not fan of having new programming languages emerging every day. Cannot negate a good quota of evolution and new ones to solve specific domain problems, but just that. Having tons of new ones, including frameworks, dependencies, tools and libraries makes the life of a developer very difficult. But, as I said, there are cases in which a domain specific language is required and very appreciated, so welcome those. In the other hand, again, do not misunderstand me, I am not an old dinosaur that feels threatened by new things. I just learnt to take the needed time to analyze, in deep, the benefits of the new language or tool. So, welcome the new, but…

But, Macro, is one of those languages that no one asked for, but is fun if you built it because the challenge (And boredom… I already mentioned that?). So, what is this programming language?

No alt text provided for this image

Macro can be considered a “scripting” language. You can write a script based on keywords (Statements) and a parser will read each line executing the expected actions.

One of the key concepts that I like to implement when I code for fun is to push boundaries a little bit. If we think on the most common programming languages the grammar, syntax and semantics are part of the language (Which is perfect, of course). But you cannot go further and modify the language (There are languages in which you can, of course) to do something else, or even better, become something else after the modification. So, for Macro, I tried to implement an architecture that allowed the modelling of the language as the developer would like to be (Part of the reason for its name: Macro). As in the case of one old videogame framework for JavaScript and HTML5 that I did years ago, the main idea was to allow third party components to be plugged in into the framework. Let face it, being the solely developer of a videogame framework could be difficult to implement all the small pieces by your own. In any case, Macro followed similar principles: Allow the user to model the language and, even, create ports for other existent languages.

Yes, I know that sounds like big stuff, lot of lines of code, but I just created the first alpha after 20 hours of work. Is more a concept than a reality (Remember, this is not a language that you really want to use). So, as I said: is a scripting language, and can be modeled.

For modelling the language, you requires a file with the language structure:

# macro lang definition
# * => text (any type)
# ? => expression (operations, variables)

# NetCore requires Macro.NetCore.Package.dll 
> negotiator	NetCore

> lang
print *
print ?
get * => create ?
send ? to *

The definition has two parts. The “negotiator” which is a component created using .Net Core 3.1 that acts as bridge between the language interpreter and any other way to resolve the language. To clarify this better, think that the different statements of the language doesn’t belong to it but a third party service that you can plug in and use. By default I built a simple one that use, as Macro, .Net Core 3.1 to process each statements. This means that “print”, “get”, “create”, “*”, “?”, “send” and “to”, each one of these token (I will continue using “statement” instead of token) are inside of “Macro.NetCore.Package.dll”. We could say almost the whole language is there. But, as I said, you can change this, write your own language package and make the “print” statement instead of showing something in the console, send that information to the printer. Or, you could change the language at the point that “print” is now called “display”.

This bridge can be implemented in other language. Let say that you love Python and prefers to implement the each sentence in it. Macro should allow you to, with the proper bridge, use Python at the moment that the code is parsed.

And here is where I tried to push the boundaries. There are other languages such as Robot Framework that does or behaves in similar ways (If you go deeper, you can see Chez Scheme). But in the case of Robot Framework, is a domain based language (Which is awesome by the way). In comparison with Macro, you could implement whatever you would like providing to the user a natural language writing approach.

There are more beneath all of what I have said and don’t want to do a long post about this language that just did its first steps. Nevertheless, as final words, let see what you could do with the previous definition that we made.

get http://jsonplaceholder.typicode.com/posts/1 => create result
print result

As result:

No alt text provided for this image

I will release the source code when consider that is mature enough to play with it but, if you would like to participate or think this is a good opportunity to read the code, let me know.

Desacoplando la vista del código (jQuery no está muerto III)

Image result for three

En los dos anteriores post, donde comenzaba planteando la idea de que un buen desarrollo no depende del framework más moderno sino de nuestra capacidad de escribir código, hasta comenzar a diagramar, en el segundo post, cómo podríamos lograr esto con un framework que muchos, en el mundo del desarrollo front end consideran muerto o de poco prestigio, en este post vamos a mover un poco más allá la idea tratando de mostrar que, como ya comenté, depende de cómo escribamos código y no de la herramienta

(Vuelvo al disclaimer: Que sí, que no es ser fundamentalista de lo viejo, solo reservado con lo nuevo)

Entonces, cómo hacemos para desacoplar, en la mayor medida posible, el DOM de nuestro código HTML?

Si revisamos React o Angular o Vue (Nombro estos porque son los más populares) todos estos, en sus implementaciones más comunes, cometen un error (Sí, un error) en forzar un lenguaje de etiquetas con funcionalidad. Tal vez el más límpio de los tres sea Vue, pero en todos los casos siempre tendremos algo que no es HTML dentro del HTML. Y, nuevamente, esto es un error. Los frameworks se transforman en virus que estiran sus tentáculos más allá del dominio de JavaScript e infectan el HTML.

En realidad, lo que quiero decir es que, si haces una página o sitio con Angular, no puedes cambiarlo en un futuro a React o Vue o lo que venga nuevo ya que no solo tu código JavaScript sigue un patrón específico y esperado por el framework usado sino que incluso el código HTML está intoxicado de dicho framework. O sea, el nivel de acoplamiento entre dos mundos totalmente distintos es absoluto y, por lo tanto, va en contra de cualquier patrón básico de desarrollo de software.

Entonces necesitamos crear código que desacoplado: Código no infectado.

Desacoplando la vista (Ahora sí)

Para desacoplar la vista (HTML) es necesario pensar en esta como lo que es: Una definición del aspecto visual, no del comportamiento de las reglas de negocio.

La vista debe utilizar solo contenido HTML y que no sea relevante para ningún contexto en particular. O sea, que no esté atado a ningún framework.

<textarea :value="input" @input="update"></textarea>

Código propuesto por Vue

<input type="text" ng-model="name">

Código propuesto por Angular (Aunque mejor, sigue siendo propiedad de Angular)

  render() {
    return (
      <div>
        <input onChange={this.handleChange} />
      </div>
    );
  }

React…

En los tres casos, todos intentan tomar control acoplándose de forma directa al HTML. Tal vez, Angular, sea el que mejor se aproxima a un modelo desacoplado ya que mediante el uso de atributos define el comportamiento. En este caso “ng-model” no significa nada para el navegador, salvo que Angular entre en acción, y esto, claramente, es algo bueno. Por supuesto, luego comienza a ponerse más intrincado al tener que proveer toda funcionalidad posible y, por lo tanto, terminaremos teniendo definiciones no HTML para hacer bucles, mostrar textos, calcular resultados, etc. Lo que nos trae un acoplamiento duro nuevamente.

Pero, sigamos por este camino, que es el que, decíamos, mejor se aproxima. Cómo haríamos esto, entonces, si queremos asegurarnos que no estamos acoplando nuestro desarrollo (Código JavaScript) e infectando el HTML?

<button 
    data-control="button" 
    data-event="click"
    data-name="boton1">
    Click me!
</button>

En este caso, una implementación simple podría usar los atributos tipo “data-*” que, de acuerdo a la documentación, se crearon para esto: Contener información extra y extender el HTML sin causar mayor daño mediante atributos personalizados (Lo de daño es una interpretación libre personal).

Luego, nuestro botón (Que veíamos en el post pasado) puede ser escrito (De forma muy grosera) así:

var button = function (DOMElement) {
    this._element = $(DOMElement);
    this.name = this._element.data('name');
    this._event = this._element.data('event');
    this._initialize();
};

button.prototype._initialize = function () {
    $(this._element).on(this._event, function () {
        console.log("test");
    });
}

Recordemos que nosotros inyectábamos jQuery y lo transformábamos en el símbolo $. Si revisamos nuevamente esa propuesta, quiere decir que el símbolo $ podría ser cualquier cosa que nos permita seleccionar o trabajar de la forma en la que propone el código. Con esto quiero decir que si bien he escrito el código pensando en jQuery, podría ser pensado de forma en que se inyectase cualquier otro framework o mecanismo para realizar las tareas básicas de selección de elementos del DOM y asociación de eventos. En todo caso, lo importante en este punto es que el comportamiento del botón estará definido en su totalidad en JavaScript y no en el DOM.

Por último, y para ir cerrando este primer acercamiento, necesitaremos que alguien cree las instancias de estos posibles botones. Para el caso, el controlador de la página que lo requiera.

(function (w, $, button) {

    var buttons = $('[data-control=button]');
    w.botones = {};

    for (var i = 0; i < buttons.length; i++) {
        var button = new button(buttons[i]);
        w.botones[button.name] = button;
    }

}(window, jQuery, MyApp.components.button));

Está claro que esto se puede generalizar y obviar la creación de estos botones en cada controlador, pero sirve, como decía, de primer acercamiento.

Y, como venimos con esta serie… Continuará!

Objetos, objetos, objetos… o jQuery no está muerto II

Como había iniciado en el post anterior, lo que importa es cómo escribamos nuestro código y no (Necesariamente) que framework usemos.

La principal queja que se escucha por los pasillos cuando hablamos de JavaScript es que, rápidamente, todo tiende a ser un confuso desorden. Y esto es cierto. Muchos (Muchísimos) proyectos tienden a ser un manojo de funciones disperdigadas en archivos que, por la naturaleza misma de los proyectos en este lenguaje, son difíciles de seguir y saber dónde está cada cosa.

Convengamos que esto no solo pasa con JavaScript, sino, con otro numeroso compendio de lenguajes. Pero, algo que destaca en JavaScript es que, ha diferencia de los proyectos en lenguajes que parecen más ordenados hay, siempre, un IDE que tiende una mano. Sí, un IDE:

– Pero no estábamos por hablar de código, Roberto?
– Sí, ahora seguimos… y me llamo Matías.

La ayuda que puede darnos un IDE va más allá de escribir con lindos colores. La ayuda es la organización mental del proyecto. El poder seguir y encontrar el origen de una llamada. Poder depurar de forma simple. O sea, un IDE nos organiza. Y esta idea es una de las que tenemos que tener presentes ya que, y ahora sí volvemos al código, una de las características principales de frameworks como React o Angular es la de organizarnos. Como vimos ya, desde la estructura de sus directorios hasta los patrones de diseño que se usan para trabajar en ellos.

La segunda característica es la más pedida y obvia: Foco.

Con esto quiero decir que la gran demanda de los desarrolladores es la de poder reducir el esfuerzo en el diseño y codificación de la arquitectura y focalizarse en darle solución al problema. Si analizamos React, toda la arquitectura ya está planteada por este y, se supone, nosotros debemos enfocarnos solo en materializar las reglas de negocio (Pero esto no es lo que pasa).

Por último tenemos la velocidad de desarrollo. Todos estos frameworks prometen ser la bala de plata que permitirá, con unos mágicos instántes de desarrollo, tener montado todo el front end de ese sitio que, si usaras otro framework te llevaría miles de años poder desarrollar. Y, la verdad que todo eso es una gran mentira. El proyecto tomará el tiempo que requiera independientemente de si fue hecho con uno u otro framework.

Pero, incluso auto mintiéndonos, queremos que esto pase. O sea, que el desarrollo sea rápido, que solo nos enfoquemos en la implementación de las reglas de negocio y que sea fácil de encontrar todo. Y ahí es dónde, con simple JavaScript, podemos conseguir todo eso.

Disclaimer antes de seguir: Que sí, que una SPA se puede hacer rápido comparado con hacerlo todo desde cero. Que sí, que sincronizar modelos con bindings bidireccionales no es trivial. Pero estamos hablando de hacer código de calidad y como es posible conseguirlo incluso con jQuery.

Ahora sí… jQuery!

Bueno, jQuery o cualquier otra cosa. Pero vamos con jQuery. Y vamos con el primer concepto: Organización.

Simplemente organizar

No tengamos miedo de crear una estructura que nos permita entender qué está pasando en nuestro proyecto. La de la imagen es solo una idea. No tiene que ser de esa forma. Pero claramente no tiene que ser un único archivo JavaScript con miles de líneas. O cientos de archivos en una única carpeta. Seamos creativos. Como en React.

No tengo que explicar el motivo de estas carpetas. Incluso, vacías, no hace falta siquiera pensar mucho para entender que habrá en cada una de ellas. Que representan. Una caja de texto dentro de una carpeta llamada “componentes”. Es obvio que no debería haber reglas de negocio ni nada relacionado a las mismas.

El siguiente es focalizar. Y para focalizar tenemos que escribir código. Entonces tomemos uno de estos componentes y hagamos que podamos reutilizarlo.

;(function (w, $) {
    w.MyApp = w.MyApp || {};
    w.MyApp.components = w.MyApp.components || {};

    var button = function () {

    };

    w.MyApp.components.button = button;

}(window, jQuery));

El objeto “button” pasa a ser parte de nuestros componentes. Esta clase, como en cualquier enfoque orientado a objetos contendrá funcionalidad específica para la manipulación de botones. Aquellas cosas necesarias para manipular el comportamiento del botón en el navegador pero que solo sean requeridas por nuestra aplicación. El motivo de hacer esto es simple: Poder esconder el manejo específico del HTML en clases especializadas.

En este caso, el botón no necesita saber si es parte de una grilla, tabla o cuadro de diálogo. No le importa si es una aplicación contable o un video juego. La clase botón solo sabe manipular botones.

Por supuesto, el código está incompleto. Le falta todo el “jugo”. Pero con estas pocas líneas ya podemos ver algunas cosas que necesitamos hacer.

;(function (w, $) {
    ...
}(window, jQuery));

Inyectamos las dependencias en vez de acoplarlas de forma directa. Tanto “window” como “jQuery” son inyectados a la clase, por lo que podríamos remplazarlos con cualquier otra cosa.

    w.MyApp = w.MyApp || {};
    w.MyApp.components = w.MyApp.components || {};

    ...

    w.MyApp.components.button = button;

Creamos espacios de nombres para agrupar los componentes y proveemos de clases que pueden ser instanciadas por otras clases.

El siguiente paso es proveer la posibilidad para el desarrollador de desacoplar lo más posible este código con el HTML. Pensar en alguna forma en la que, solo definiendo y modelando información el código pueda interactuar, desde un solo punto de contacto con el DOM.

Pero… eso lo veremos en el siguiente post 🙂

(Continuará… de nuevo)

jQuery no está muerto…

No, jQuery no está muerto. De hecho se sigue usando y no solo en proyectos heredados o desarrollados hace años. Se sigue usando en todo tipo de proyectos por si facilidad de uso y, desde un punto de vista personal, porque a diferencia de otros “frameworks”, no toman control de tu proyecto sino que agrega una capa para simplificar la manipulación del DOM.

No pretendo entrar en el terreno del porqué considero que frameworks como React o Angular se transforman en una capa muy gruesa, mucho más de lo que un framework de JavaScript debería. Y, aunque no voy a entrar en ello, decir que en la mayoría de los casos estos frameworks son más una carga que un beneficio real. Generan más problemas que soluciones, aunque no veas estos problemas.

Pero estos problemas no se deben de forma directa al framework elegido, que si bien dependiendo de este el problema será más difícil de encontrar y solucionar, se debe al conocimiento sobre JavaScript y cómo desarrollamos en este lenguaje. Por lo que, escribiendo JavaScript de forma incorrecta, en un framework que toma control de lo que pasa en toda la aplicación será más difícil poder darle solución a problemas de rendimiento y errores en general.

Pero, como decía, no quiero hablar de esos framework sino de jQuery, y el porqué, hoy, aún sigue siendo una alternativa totalmente viable. O en su defecto, el uso de un framework más simple que los comentados anteriormente.

Tal vez el comentario que he escuchado más a menudo es que, con jQuery, el código tiende a ser caótico, desordenado, y rápidamente se convierte en un caldo que mezcla todo con todo. Desde HTML escrito en el código hasta código duplicado. Pero, volviendo al punto original, no es jQuery, es nuestro entendimiento del desarrollo de software; de la creación de código y cómo aplicamos principios básicos como OOP, SOLID, patrones de diseño, pensamiento lógico, y más.

$.each(item, function (key, value) {
	var itemName = "Item " + j++;
	var image = ' ';
	var checked = '';

	if (value.hasImage) {
		image = '<img src="/images/space.png"><span class="tooltip">This is a space</span>';
	}

	if(jQuery.inArray(value.code, ids) !== -1 || jQuery.inArray(value.code, selectedIds) !== -1) {
		checked = 'checked=true';
	}

	var li = '<div class="checkbox" data-hasimage="' + value.hasImage + '">';
	li += '<div class="space-class">' + image + '</div>';
	li += '<input type="checkbox" id="' + value.code + '" data-hasimage="' + value.hasImage + '" value="' + value.code +'" data-name="' + itemName + '" name="item'+ i +'" ' + checked + '>...</label></div>';
	
	$('.items').append($(li));
	
	i++;
});

El anterior código es real. Es un muy mal código, pero es código que se puede encontrar en muchos proyectos. Funciones escritas individualmente que intentan crear, como en este caso, código HTML concatenando texto y luego agregándolo al cuerpo de la página. Puede que el código varié un poco. Que no se escriban los elementos concatenando texto. Pero en definitiva sigue siendo un error.

{!hideCheckboxes ? (
  <div className="last-row">
	{stores && stores.length
	  ? stores.map((element, index) => {
		  if (selectedStores.indexOf(element.id) > -1) {
			let state = storeDates.find(
			  state => state.marketId === element.id
			);

			return (
			  <div
				className={
				  'column total ' +
				  (element.active === 'Yes' ? 'active' : 'disabled') +
				  (state &&
				  state.pickableDate &&
				  currentActiveModel
					? ' full'
					: '') +
				  (state &&

En el caso anterior, es una implementación real (Un fragmento) de una aplicación en React. De la misma forma que con la mala implementación con jQuery, este código es difícil de leer. Existe una mezcla entre código y HTML (De forma inversa) al igual que con la mala implementación hecha con jQuery.

Entonces, volviendo a la pregunta original: Es jQuery? O es nuestra capacidad de escribir JavaScript? Desde mi perspectiva la respuesta es claramente la segunda opción. Es nuestro conocimiento sobre desarrollo lo que causa este tipo de problemas.

Una posibilidad: Separar vistas de código

Como decía, frameworks como React no son “malos” por si mismos. Por el contrario, nos dan una idea interesante, con sus estándares, de cómo organizar cualquier aplicación creada con JavaScript. O, por lo menos, nos puede movilizar un poco a pensar en esa mejora que necesitamos.

Una estructura que intenta, en el sistema de archivos, hacernos pensar en encapsulamiento y OOP

Esta estructura nos lleva a un concepto común de los principios de programación: Las clases superiores son más genéricas (Conocen menos de la implementación) y las más profundas se encargan de los detalles (Sí, es una adaptación criolla, pero creo que se entiende). Por lo que, tener “páginas” que consumen “componentes” que implementan “botones” tiene todo el sentido.

Siendo que esto tiene sentido en frameworks como React, entonces debería tener el mismo sentido en cualquier otra implementación, incluso si usamos jQuery.

La diferencia en este caso es quién tiene el control de lo que pasa.

Una visión muy simplificada de React

En este diagrama (Muy simplificado) se entiende que React tiene control sobre lo que pasa y nuestro código es una capa delgada que se sustenta en el framework. Por lo tanto estamos atados a este de forma directa. O sea, tarde o temprano caeremos en una implementación del estilo que veíamos al principio (Sí, que se puede hacer mejor, ya lo se).

Estoy obviando otras características de estos frameworks para no desviar el punto.

Por otro lado, tenemos a jQuery (O cualquier otro framework similar, por ejemplo, JSRender y JSViews).

Visión simplificada de jQuery

En esta visión simplificada de jQuery, este se encuentra a un costado y no tomando control de todo lo que pasa. De esta forma somos más libres al momento de escribir código. Sí, el bloque de nuestro código será mayor, pero nos permitirá movernos de mejor forma. Incluso, si somos los suficientemente ordenados, pudiendo cambiar jQuery por cualquier otro framework sin necesidad de sufrir (Mucho) por ello.

Pero venía a hablar de separar vistas y código… lo que haré en el siguiente post 😉

(Continuará…)

La STEMFest – Arduinos, AR y educación

Hace dos semanas atrás se realizaba en Tauranga (New Zealand) un evento significativo.

La STEMFest atrajo a más de 3000 personas. Padres y niños pasearon por cuatro manzanas de la ciudad repletas de tecnología.

Universidades mostrando sus laboratorios de ciencias. Una compañía eléctrica con una réplica de una planta hidroeléctrica. Autos eléctricos. Simulaciones de terremotos. Todo listo para que los visitantes puedan interactuar, tocar, jugar.

Por mi lado, y junto a integrantes del grupo Junior Dev Tauranga, con el que organizamos meetups para fomentar el desarrollo de software, me tocó armar diferentes proyectos para que los niños pudieran interactuar, armar y desarmar, jugar con tecnología y, sobre todo, interesarse en ella para tenerla en cuenta como carrera en un futuro no muy lejano.

Para esto armé cuatro proyectos diferentes. Tres de ellos usando Arduinos: Un medidor de humedad en suelo; un medidor de temperatura; y un piano hecho con frutas.

Los dos primeros se presentaban desarmados y, mediante una guía, los asistentes podían armar el modelo. Probar diferentes posibilidades y descubrir el motivo de porqué funcionaba como lo hacía.

En el caso del piano hecho con frutas. Debido a que era algo más complejo. Yo hacía de presentador explicando la mecánica del dispositivo y luego, los asistentes, podían experimentar con este de diferentes formas.

Desde tocar un simple tono, pasando por crear una melodía, y hasta aprender sobre conductividad eléctrica agarrándose de las manos en grupo mientras el primero tomaba el cable de tierra y el último ejecutaba los sonidos.

El último proyecto, basado en realidad aumentada, se usó para incentivar a todos los asistentes a recorrer toda la feria. Este proyecto era una búsqueda del tesoro en el que, mediante el celular se accedía a una página Web que activaba la cámara del dispositivo y, mediante unos marcadores colocados en las cuatro manzanas del evento, los asistentes iban escaneando, viendo diferentes modelos 3D con los que podían interactuar y, una vez que los recolectaban a todos, volver a “base” para recoger su premio.

Todo este desarrollo tomó tiempo, pero claramente valió cada hora invertida.

El código fuente de cada proyecto se puede encontrar en un repo que armé para este caso: https://github.com/MatiasIac/STEMFestTauranga2019

También, cree dos videos, en mi canal de YouTube, explicando cómo armé el piano de frutas y el proyecto de realidad aumentada.

Espero les guste! 🙂

Raspberry Pi 4 + Arduino + Sensores + Socket.IO + HTML

En unos días estaremos llevando adelante un evento muy grande. Se viene la STEMFest por esta zona del planeta (Tauranga, New Zealand).

Y parte de mi trabajo será enseñarle a niños y adolescentes (Muchos… dicen que habrá cerca de 3000) que la tecnología, la programación y las ciencias, en general, son fáciles y divertidas.

Para esto, desde el grupo de “Junior DevTauranga” hemos estado creando diferentes proyectos con los que los asistentes podrán interactuar, armar y desarmar, crear código, editarlo. En fin, jugar!

Uno de estos proyectos ya lo he compartido en otro post. Pero ahora hemos agregado nuevos al repositorio.

Un sensor de temperatura y humedad. Un sensor para medir si debemos agregar más agua a nuestras plantas. Y un piano hecho con frutas.

Todos estos proyectos se pueden descargar desde: https://github.com/MatiasIac/STEMFestTauranga2019

Y, por supuesto, seguiremos agregando más en lo que queda de la semana!