A Virginia, la luz más brillante del cielo
Ayer me crucé con el término "Deuda técnica" y recuerdo haberla escuchado explicada a la directiva de esa empresa como "deuda que debe ser pagada regularmente", es un término que no me encaja porque la deuda no es algo que aparezca sin más: tener deuda es una opción, pagarla es una obligación.
Leer másDecidí probar el lenguaje Rust por varias razones:
Los últimos años he pasado de AngularJS (v1) a Angular2+ y desde que probé ReactJS lo consideré mi herramienta de trabajo por defecto.
Estas semanas estuve probando SolidJS y al compararlo con ReactJS hay varias cosas que me gustan.
Leer másSiguiendo este video aprendí la notación flecha en matemáticas:
``` 3↑3 = 3^3^3 = 3^27 = 7_625_597_484_987
Leer másHe estado trabajando en una versión nueva de este sitio con una idea clara:
Me gustaría hacer un repaso al tema de la asincronía en Javascript porque me llama la atención que pese a tener casi 20 años es un tema que sigue madurando y he visto surgir buenas ideas recientemente.
Primero lo primero, de donde sale la asincronía. Javascript es un lenguaje cuya ejecución se basa en lo que se llama event loop (bucle de eventos). El event loop es una cola donde se van añadiendo los bloques de código que quieren ejecutarse, por ejemplo: cuando el navegador está renderizando el HTML de una página y se encuentra un tag <script> el contenido de ese elemento se añade al event loop para que sea ejecutado tan pronto como sea posible.
NOTA: Este artículo está centrado en un tema que ya comenté en el post anterior, pero de una forma más organizada y centrada, algunos fragmentos están extraídos del post anterior para mayor claridad.
He hablado antes de la limitación de los constructores javascript y sobre todo de la complejidad de extenderlos
Leer másEste artículo quedó muy complejo y caótico, por eso voy a intentar dividirlo en partes, recomiendo leer los nuevos post en lugar de este.
Parte 1: Type.new()
Buscando optimizaciones para un juego en javascript encontré un paradigma de definición de tipos y creación de objetos que cambió mi forma de ver el lenguaje.
He hablado antes de la limitación de los constructores javascript:
function Person(name) {
this.name = name;
}
Person.prototype.methodA = function() { ... }
En este caso quiero referirme a las limitaciones en cuanto a memoria pero hará falta un poco de introducción
Leer másAcabo de caer en cuenta de porqué no me gusta angular, backbone, ember...
Todos estos frameworks si bien intentan dividir la aplicación que vas a construír en módulos se hace esto por mantenibilidad, no por reutilización de los módulos.
En otras tecnologías generalmente creas un componente reutilizable y basta con mover el archivo de proyecto para tenerlo listo, pero estos frameworks no se puede hacer eso, por ejemplo una simple targeta que muestre los datos de una persona:
Leer másA algunos ya os he comentado los problemas que NC Zakas comenta con el _.extend de underscore y los getters:
var a = {
init: function () {
this.list = [];
},
get first() {
return this.list[0];
},
};
Actualización 19/3/2014: Finalmente he entendido la utilidad de reemplazar
new, se puede ver aquí
JotaEseros! Tengo un dilema existencial que me impide dormir.
Hasta donde sé los constructores hacen más o menos esto
function fakeNew(Ctor) {
var instance = Object.create(Ctor.prototype);
instance.constructor();
return instance;
}
Continuando con [mi último artículo][1], llegó la hora de hablar del gran Github Flow:
Y finalmente el artículo que ha inspirado éste. Después de probar el Git Flow (el modelo, no la herramienta) en productos profesionales y a modo de prueba en pequeñas librerías propias y aunque para proyectos grandes donde una release se planea durante semanas va bien, en pequeños proyectos, y en proyectos SaaS no acaba de encajar.
Leer másAcabo de leer un artículo creado por los trabajadores de Github que han dado una vuelta de tuerca a lo que sabía de GIT y creo que será muy útil compartirlo, pero primero vamos por partes:
Leer másActualización 19/3/2014: Sorprendentemente parece que una propuesta del ECMAScript 6 sigue mismo el patrón descrito en este post, y yo que pensaba que era demasiado rebuscado...
Como ya comenté, la privacidad en Javascript es un tema peliagudo, el lenguaje no nos ofrece ninguna herramienta para gestionar la privacidad automáticamente, tenemos que aprovechar el scope de los closures para ocultar información que el usuario de nuestra librería no necesita saber, pero ocultar propiedades de una instancia es mucho más complicado. Hace algunos años me empeñé en buscar una forma de conseguir privacidad por instancias que no fuera mediante el constructor, como ya expliqué en el [post anterior][1].
Leer másUno de los temas más frecuentes cuando uno se inicia en Javascript es la privacidad, principalmente viniendo de lenguajes como Java, C# o C++; donde publican o se ocultan propiedades de los objetos mediante modificadores. Javascript no posee dichos modificadores sino que todas las propiedades de los objetos son públicas lo que puede ser muy confuso para una persona poco diestra en ésta técnica, entre los que me incluyo.
Personalmente cuando diseño un componente (objeto/clase/librería), es porque quiero que ese componente cumpla una funcionalidad, por ejemplo, si yo quiero tener una clase que represente a una impresora necesito enviarle datos y que los imprima; mi prioridad es que dicho componente sea sencillo de utilizar, lo que facilita la reutilización del componente. Por lo que primero imagino cómo me gustaría usarlo:
Leer másLlegó la hora de entrar el en tema que realmente confunde a los recién llegados a Javascript, principalmente para quienes vienen de lenguajes que implementan la orientación a objetos mediante clases, que son la gran mayoría.
Leer másAntes de continuar con el Patrón Promise me gustaría explicar en paralelo Conceptos Básicos de Javascript. Entendiendo que estamos hablando de Javascript como lenguaje y no vamos a hablar sobre conceptos básicos del DOM o como abrir una nueva ventana en el navegador, sino detalles de Javascript puro, tanto en cliente como en servidor.
He pensado que sería un buen punto empezar por una curiosidad bastante desconocida para los recién llegados a Javascript: La variable this, también llamado el scope o más correctamente contexto de la función. En los lenguajes basados en clases más extendidos (Java, C++, C#...) encontramos que los métodos de la clase siempre disponen de la variable this que nos permite acceder a nuestra propia instancia sobre la que se está ejecutando el método. Es decir, si tenemos la clase...
Lo prometido es deuda (bien lo saben las funciones) y he encontrado un momento para empezar a explicar la forma en la que he implementado el patrón Promise en mi caso, no tiene porqué ser la mejor, pero cumple con su cometido.
NOTA: Me gustaría implementarla en Test Driven Development, pero ya es bastante para quien lee y para el que escribe seguir la implementación como para encima añadir TDD, pero no quisiera dejar de recomendarlo.
Leer másActualización 19/3/2014: Finalmente los promises se han confirmado para el estándar ECMAScript 6, dentro de poco serán nativos en Javascript :D
Actualización 7/10/2016: Los promises ya son estándar y están implementados en los navegadores!!!
Recientemente he tenido que implementar un sistema MVC en Javascript para simplificar el desarrollo sobre una plataforma y me he encontrado con el problema de que las llamadas asíncronas a servidor rompían la simpleza del código, tras un análisis identifiqué cuatro problemas:
Leer másBueno, ha llegado la hora de dar el siguiente paso como programador: comenzar un blog para que todos puedan criticarme por poner las llaves { a la derecha :D
int main(char** args) {
print("Hello World!");
return 0;
}
And this is how a programming blog should start.
Leer más