The time pass quickly when you are getting fun. More than 30 minutes answering questions. ~80 participants and half staying until the very end. Super happy from my side after talked about Arduino, C++, Python, AdaFruit, Raspberry Pi, TensorFlow, JavaScript, C#, HTTP, REST… yes yes… A LOT 😀
Anyway, if you want the presentation slides, go here: https://www.slideshare.net/matiasiacono/introduccin-a-iot
Yes, another event is coming and I am giving a lecture around a very interesting topic: Machine Learning, Artificial Intelligence and how the most commonly used learning models uses some basic concepts to build more complex algorithms.
There will be many more lectures on the event and, because is a virtual event due the current quarantine state, the event will be done in different days, so, there is no reason to miss it 🙂
Check here to register on my track: https://globalaitour.conosur.tech/cordoba-sabado-23-de-mayo/
The NetCore Conference has passed. And 29 sessions with more that 5000 viewers are the final results. Not bad at all!
My lecture was streamed a couple of hours ago and, because this is Internet, will be on YouTube if you missed it or if you want to see it again.
As I mentioned in a previous post, I was about to talk about performance on .Net Core with C# but in particular, showing two examples of how performance is affected when, for the first scenario, the overuse of some libraries (On special cases) could cause more harm than benefits. And for the second one, how our coding style could affect the performance forcing the compiler to add more unnecessary instructions to the IL code.
In any case, if you want to take a look to the lecture:
This weekend I will be giving a lecture as part of the NetCoreConf 2020 event.
Due the current situation around the world, this event will be “virtual” meaning that all sessions will be recorded and streamed during the event. But, thanks to this, people from different parts of the world will be presenting different topics.
In my case, I will be talking about code optimization, remembering some old-but-good algorithms to improve performance and raising flags on bad overuse of some .Net libraries and how these could impact our final product, even if we do not notice that.
Of course, this event is mostly in Spanish but will be transmitted using YouTube as platform which gives some very good tools to autotranslate videos to any language.
If you want to know more about the event, click here: https://netcoreconf.com/virtual.html
Yes, I know. Everybody is recommending books, so, why I will not do the same, right? right…?
Well, yes, I will recommend some books but not new ones, very old ones. I am totally convinced that one of the today’s developers lack is knowing from where our practice come from. There are a lot of new developers arriving and stumbling with many new concepts but, sometimes, those concepts and ideas are not necessary new, or were around for a wile making everybody wondering how to solve it.
Let talk about agility and Scrum. For the new comers that could be the standard paradigm of project management and they will not know anything about waterfall or any other sort of software management attempt.
What happen when you just face these concepts but don’t know the reason behind it? Why we decided to change? What happened before and the necessity for that change? How you will know, if don’t know the past, that thing the facilitator (self-called guru, scrum master or coach) is valid and is not just trying to manipulate you if what they are telling to you sound fresh and original but, actually, is not?
The answer is: THE OLD BOOKS (No religion related)
So, here is my recommendation for three books and a paper that, if you haven’t read it yet, could change your mind drastically.
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á!
Cortito al pié.
Hace unas horas salió una micro entrevista que me hicieron para uno de los blogs técnicos de Microsoft.
En esta hablo un poco de lo que estoy haciendo ahora por tierras neozelandesas. De algunos recuerdos del pasado y cosas a hacer de cara al futuro.
La nota está en inglés y pueden verla aquí.
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.
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)
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.
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.
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).
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á…)
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! 🙂
Matías Iacono 