Charlas “Programming Style” por Douglas Crockford

Posted: Julio 1st, 2017 | Author: | Filed under: Sin categoría | Tags: , , , , , , | No Comments »

Otra de las series de charlas más conocidas de Crockford, son en las que habla de la importancia del estilo de código que empleamos.

A good style can help produce better programs. Style should not be about personal preferences and self-expression. Douglas Crockford

De esta serie creo que la más interesante es:

  • YUIConf 2011. 66′. Douglas Crockford. Programming Style & Your brain. En esta charla Crockford explica lo importante que es usar un estilo de código adecuado, y como hay estilos mejores que otros (según el lenguaje que estemos usando). Al programar no debemos tratar de demostrar lo listos que somos, si no escribir código para que otros puedan entenderlo, y hay estilos que favorecen esto además de reducir los bugs que podamos cometer. La charla se centra en Javascript y la herramienta JSLint, pero el porqué de usar un estilo y herramientas es importante vale para cualquier lenguaje.

Otras charlas similares serían:

Escogiendo un estilo de código

Crockford dice que al escoger un estilo, debemos priorizar (y en ese orden) que:

  1. Evite errores (aunque sea errores que raramente sucedan)
  2. Sea legible. Comuniqué claramente su intención al resto de programadores. Y se debe preferir esto sobre ahorrar memoria o velocidad.

Algunos comentarios de estilo de su charla con los que estoy de acuerdo

La llave va a la derecha

La llave va a la derecha, porqué el siguiente código en js produce un error silencioso:

1
2
3
4
return
{
ok: false
};

Mientras que esto funciona correctamente:

1
2
3
return {
ok: false
};

Usar Strict Equality Comparison

No usar nunca “==” usar siempre “===”. Evita resultados indeseados al hacer casting.

No usar el slash para generar strings multilínea

No usar el slash para generar strings multilínea porqué si hay un espacio después del slash se produce un error

1
2
"hola \
mundo"

Usar siempre las llaves para los bloques de código

Usar siempre las llaves aunque sea para escribir en la misma linea if (flag) { doSomething(); }

No usar pre/post incremento

No usar pre/post incremento. En lugar de ++x o x++ usar x+=1; Los primeros casos obligan a pensar más en lo que se está haciendo de que valor va a tener x cuando se ejecute algo, e introduce más errores.

No usar asignación transitiva

No usar la asignación transitiva var a = b = 0. Porqué no está claro si lo que se quería hacer era

1
2
3
4
5
var a = 0,
b = 0;

b = 0;
var a = b;

En los switch usar siempre break

En el switch usar siempre break después de cada caso. Es muy fácil usarlo mal, y que se presente un bug difícil de depurar.

Forma de usar las IIFE

Al usar Immediately Invocable Function Expression, preferir la tercera forma que aparece aquí

1
2
3
4
5
6
7
8
9
10
11
function () {
...
}(); // Syntax error!

(function () {
...
})(); // Bien

(function () {
...
}()); // Mejor. Queda más claro lo que estamos haciendo según Crockford

Usar siempre el “;”

Usar siempre el ; para evitar el Automatic Semicolon Insertion que puedo provocar bugs difíciles de depurar.

Algunos con los que puedo estar de acuerdo, pero debería revisar

Declaración de variables en el top

Como javascript no tiene (¿tenía?) block scope, si no sólo function scope, hay que declarar todas las variables en la parte de arriba y declarar todos los métodos antes de usarlos. Esto deja claro como funciona el hoisting en javascript que puede introducir errores. Esto incluye el no declarar variables dentro del for – for (var i …) {, para dejar claro que la variable i es válida para toda la función, y tiene valor antes (undefined) y después del for (el último valor que haya tomado en el bucle). Habría que ver como se conjuga esto con let, const, …

Espacio entre paréntesis y resto de elementos

Una serie de reglas sobre donde y como usar los paréntesis, del tipo:

  • No space before ( when used to invoke a function
  • No space between a function name and a parameter list
  • One space between all other names and (

Uso equivocado según crockford:

  • foo (bar);
  • function foo (b) {…}
  • function(x) {…}
  • return(a+b);
  • if (a=== 0) {…}

 


Charlas “The better Parts” por Douglas Crockford

Posted: Mayo 28th, 2017 | Author: | Filed under: Sin categoría | Tags: , , , , , | No Comments »

Seguramente las charlas más conocidas de Crockford son las basadas en su libro The good parts y o algunas más modernas a las que llama de “The better parts” donde revisa alguna de sus anteriores prácticas y comenta features de ES6.

Dentro de esta serie de The Better Parts se pueden encontrar varias dadas en distintas momentos, entre ellas.

  • The Better Parts | .concat() 2015. El problema de esta charla es que no se ven las transparencias (y a pesar de ser similares) a las slides que usa en otras se hace un poco complicado seguir el hilo. Creo que una de las novedades de esta charla respecto a otra es cuando habla de los Template Literals.
  • The Better Parts. Infoq. Agosto/2014. Las transparencias de esta charla, que también valen de guía para el resto están aquí. La de la JSConfUY me pareció un poco más fluída que esta. Pero hay al menos dos secciones que en esta están mejor explicadas o ampliadas la que llama en las transaprecias New Good Parts in ES6 que empieza en el minuto 12 y acaba en el 25. Y cuando explica su constructor pattern (slide 46) a partir del minuto 34. El constructor también lo explica en la JSConfUY pero aquí se entienda mejor.
  • The Better Parts – JSConfUY Septiembre/2014. En apareciencia esta tiene un poco más de carga filosófica que la de Infoq.

Yo ví la charla de JSConfUY, ojee la de concat, y fuí a algunas partes concretas de la de InfoQ. Mi recomendación es que veas la de InfoQ. O si no que veas de la JSConfUY y las partes concretas que mencionó de la de InfoQ.

A nivel contenidos las charlas son similares.

Arranca con una cita de Saint-Exupéry, “It seems that perfection is attained not when there is nothing more to add, but when there is nothing more to subtract.” y de como los programadores deben buscar la perfección. Por ello hace incapié en uno de sus habituales, que un lenguaje nos dé un montón de características no significa que tengamos que usarlas todas si no sólo las “buenas”.

Luego habla de jslint y de su libro de “The good parts”. Combate algunas de las criticas que se hacen de jslint y defiende porqué el estilo de desarrollo no es simplemente un “acuerdo”, si no que hay estilos mejores que otros, y que escribir de una determinada forma elimina bugs y por tanto te acerca a la perfección.

Continúa con una mini revisión de esas buenas partes de JavaScript en general mezclándolo con como debería ser el lenguaje del futuro (tiene otra charla sobre esto llamada The Post JavaScript Apocalypse), centrándose en su propuesta para un nuevo tipo de datos numérico llamado DEC64.

Y termina hablando un poco de JSON.

The better parts

Entre las prácticas que menciona como mejores están.

* No usar for. Sólo array.forEach y derivados
* No dice nada de for..of, supongo que en el momento todavía no habría una propuesta al respecto, pero si habla de evitar for..in y emplear unicamente Object.keys(object).forEach
* Y dice que tampoco usa ya while si no que usa una construcción de este tipo

1
2
3
4
5
function repeat(func) {
  if (func() !== undefined) {
    return repeat(func);
  }
}

Como vemos, y como el mismo dice, estás Better Parts van en la línea de usar JavaScript como un lenguaje funcional.

Especial atención merece su nuevo patrón para la construcción de objetos. Hace tiempo que aboga por no usar new pero también ha dejado de usar Object.create, de hecho ha dejado de usar this para evitar problemas de seguridad. También defiende que la herencia basada en prototipos es una mejor idea que las jerarquías clásicas. Porqué, las jerarquías son en general erróneas, y además suelen establecerse al principio del proyecto, cuando menos información se tiene de como debe ser.

Su patrón para la construcción de objetos tendría este aspecto

1
2
3
4
5
6
7
8
9
10
11
12
function constructor(spec) {
  let {member} = spec,
      {other} = other_constructor(spec),
      method = function () {
        // member, other, method
      };

  return Object.freeze({
      method,
      other
  });
}

Donde

  • spec será generalmente un object literal, que permite inicializar el objeto
  • member será un miembro privado de la clase, no accesible desde el exterior
  • Esta construcción permite que se pueden llamar tantas veces como se quiera a otros constructores (other_constructor), de ese modo se obtiene herencia múltiple, y se pueden copiar, las funciones de interés de esos otros objetos en nuestro objetos
  • También puedo crear nuevos métodos (method), que tendrán acceso a los miembros privados, a otros métodos, a lo que proporcione other. En este caso method es público porque se devuelve al llamante pero con el mismo diseño podría ser un método privado
  • Se devuelve un nuevo objeto (el literal dentro de freeze, con todos los métodos de interés)
  • Lo congela para hacerlo inmutable, con todas las implicaciones que eso trae. Seguridad, comparaciones más sencillas, …
  • Comenta que este sistema tiene un costo en memoria. Al contrario que otras estrategias que reaprovechan los métodos, en esta method sería creado cada vez. Pero a cambio es muy rápido, porque no hay que recorrer el prototype chain para encontrar las claves si no que están directamente en el propio objeto

En otro momento, me gustaría hacer un artículo con los distintos patrones de creación de objetos de Javascript, pero debo decir que este me convence mucho, porque debe ser de las pocas veces que veo algo de este tema en JS que parece tener sentido a la primera. Lo que no comprendo es porque llama “constructor” a su función de ejemplo cuando en realidad es una “factory”.


Recargar el navegador desde Emacs

Posted: Mayo 21st, 2017 | Author: | Filed under: Sin categoría | Tags: , , , , , , , , | No Comments »

Aunque Emacs no suele aparecer entre los editores preferidos para desarrollo web sigue teniendo opciones que lo hacen interesante.

En este artículo vamos a comentar algunos “plugins” que nos ayudan a recargar el navegador automáticamente cuando hacemos cambios en el código. No todos funcionan en las últimas versiones de Emacs, pero los dejo en el artículo para saber lo que hay disponible, o al menos lo que no merece la pena probar.

Conclusiones

Para quien quiera ir directo al grano el que me parece más recomendable en este momento es Mini Kite Mode, que se comenta al final de listado y que descubrí a través de esta pregunta de stackoverlow. En las respuestas se mencionan algunos complementos para emacs para trabajar con desarrollo web que no he probado y que también podrían ser interesantes pero están todos desactualizados.

Listado de plugins

Impatient Mode

Uno de los limitantes de Impatient Mode es que hay que habilitar el impatient-mode por cada uno de los buffers que se quieran observar. Aunque supongo que se puede configurar de algún modo algún hook para que automáticamente habilite la observación en los buffers abiertos con determinadas extensiones.

Tras habilitar el modo

1
M-x impatient-mode

y lanzar el servidor

1
M-x httpd-start

tendremos en localhost un navegador que escuche los cambios

1
http://localhost:8080/imp/

Otro de sus problemas es que lo que parece hacer, es cargar dentro de un iframe la web que estamos editando en emacs, y desde el código html/js en el que está empotrado el frame se hace un pooling cada cierto tiempo para ver si el contenido cambia y recargar. Empotrar tu código dentro de un iframe al final excepto para casos sencillos puede ser problemático y el sistema de pooling tampoco es muy efectivo en la práctica, porque cada pocas pulsaciones de teclas se hace un refresco de la página.

Skewer Mode

Para hacer funcionar Skewer Mode seguramente haya que hacer un par de pruebas, pero hay un vídeo y una pregunta de stackexchange que pueden ayudar.

La parte interesante de este modo es que permite abrir un buffer en modo REPL para javascript. De modo que podemos evaluar el código js directamente en emacs como si estuvieramos usando la consola del navegador. O podemos editar nuestra fuente javascript y relanzar una función o porciones de código al navegador.

Uno de los mayores limitante es que la recarga no es automática, y en el modo html funciona tag a tag. Es decir, no podemos reenviar el buffer entero al navegador, si no sólo los tags que nos interesen. Lo que hace es modificar el dom, para actulizar el contenido de los tags. No lo he encontrado especialmente cómodo, pero tiene algunas extensiones que podrían simplificar el trabajo como skewer-less o skewer-reload-stylesheets.

Emacs browser refresh

Browser refresh es una idea sencilla e interesante. Basicamente usa xdotool, una herramienta que permite scriptear movimiento de ratón y pulsaciones de teclas, para poner la ventana del navegador en foco y pulsar “F5”, cuando le damos a salvar. El script original no funciona del todo bien, y aunque es fácil de arreglar es una solución “error prone”. Si tenemos varias ventanas del navegador abiertas, o hemos cambiado de pestaña puede funcionar incorrectamente.

GC Refresh Mode

De nuevo una buena idea pero el código de GC Refresh Mode está desactualizado y no funciona. Al activar el modo

1
M-x gc-refresh-mode

pregunta la url a recargar, que puede ser un http://localhost o un file:///, abre esa uri en chrome en modo remote-debugging y sobreescribe C-x C-s para que al recargar se ejecute un script en python. El script en python es una implementación muy sencilla del Chrome Debugging Protocol que conecta a un socket con el que comunicarse con la instancia del navegador que abrió antes, busca la pestaña donde está la uri de interés y la recarga.

El problema es que Chrome ya no usa exactamente este sistema y el script no funciona. Este plugin está inspirado en la página de Save And Reload Browser del Emacs Wiki.

chrome-reload-page

Basándose en la idea de GC Refresh Mode hace algún tiempo escribí un ejemplo de código (funcional) que acabó de subir a github.

Este script usa el Chrome debugging protocol para recargar la pestaña. El script lleva empotrado el código de python del fork de max-weller de chrome_remote_shell para ahorrar trabajo.

Mini Kite Mode

Mini Kite Mode es la más funcional de las opciones de este artículo.

Se puede instalar directamente desde MELPA. Para usarlo añadiremos a nuestro .emacs, las siguientes líneas.

1
2
3
4
5
6
(require 'kite-mini)
(require 'kite-mini-console)
# Automatically Turn on the mode for your buffer of choice.
(add-hook 'js-mode-hook (lambda () (kite-mini-mode t)))
(add-hook 'css-mode-hook (lambda () (kite-mini-mode t)))
(add-hook 'html-mode-hook (lambda () (kite-mini-mode t)))

El segundo require sólo es necesario si queremos abrir un buffer de Emacs como una consola js en modo REPL (similar a la consola de DevTools). Y los hooks permiten activar el modo para los buffers de interés en tener que activarlo a mano

1
M-x kite-mini-mode

Una vez en un buffer (y través a ver lanzado chrome / chromium en modo remote debug) simplemente conectamos con

1
M-x kite-mini-connect

Si la pestaña que tenemos abierta es con la que queremos interactual podemos simplemente pulsar intro. A partir de ese momento podemos lanzar la consola de js, enviar una región al navegador para que sea evaluada, o recargar la pestaña.

El mayor problema, de esta herramienta, y en realidad de todas las que usen el Remote Debug, es que sóla una herramienta puede estar conectada mediante el protocolo a la vez, y las DevTools hace uso de este sistema también. De modo que si kite está conectado y se abren las DevTools kite se desconectará. Y si son las DevTools las que estan activadas cuando hacemos kite-mini-connect, kite no llegará a conectar.

Para simplificar un poco el flujo he editado el fichero de ~/.emacs.d/elpa/kite-mini-20160508.406/kite-mini-el para que antes de hacer el reload salve el buffer, quedando así

1
2
3
4
5
6
(defun kite-mini-reload ()
  (interactive)
  (save-buffer)
  (kite-mini-call-rpc
   "Page.reload"
   (list :ignoreCache t)))

De este modo al pulsar C-c C-r, primero salva y luego recarga. El siguiente paso, sería que mientras esté conectado, pulsar C-x C-s salve el buffer y recargue, pero por ahora con esto me llega.


Libro: JavaScript: The Good Parts de Douglas Crockford

Posted: Abril 23rd, 2016 | Author: | Filed under: Sin categoría | Tags: , , , , | 2 Comments »

A pesar de que Crockford tiene un estilo de comunicación bastante peculiar, demasiado agresivo, para mi gusto, tenía bastantes expectativas puestas en este libro, que al final no se cumplieron.

Para mi lo mejor del libro es que se puede leer muy rápido y los railroads syntax diagrams. No es desde luego un libro para aprender javascript sino más bien una guía de ciertas prácticas a evitar y una justificación de las reglas de jslint. La verdad es que al contrario que otros libros de javascript como el de Flanagan o centrados en los idioms de los lenguajes como Effective Java, no me veo volviendo a este de vez en cuando para repasar algún concepto.

El libro puede gustarte si eres de los que se leen la definición de reglas de eslint para definir tu propio subset.

Nota. Estas transparencias también son un buen resumen del libro e incluso tienen un “code playground” para practicar.


Organizar los ficheros de routes en nodejs – expressjs

Posted: Marzo 30th, 2014 | Author: | Filed under: Sin categoría | Tags: , , , , , , , , , | No Comments »

Una de las tecnologías que estamos probando en Cartolab para aplicaciones web es nodejs con express como framework. Hay un montón de tutoriales de como empezar a usarlos, pero a poco que escribas empiezas a preguntarte como organizar el código, y ahí empiezan los problemas. express es un framework no opinativo, es decir proporciona un montón de utilidades pero da liberar total al usuario sobre como mezclarlas, así que se van desarrollando distintos modos de hacerlo.

La primera pregunta en mi casa sobre organizar el código fue acerca de los ficheros bajo el directorio routes. Podemos entender las routes de express como el equivalente al controlador en ese patrón llamado MVC que cada framework implementa como quiere, o viéndolo de otro modo como el mapeo entre una url y una función.

Vamos a ver cuatro estrategias distintas, cada una con sus ventajas e incovenientes.

Todo en app.js

La versión que se suele emplear en los tutoriales de iniciación. Escribimos en un único fichero todo el código de la aplicación.

  • Poco código boilerplate
  • Añadir una nueva url implica tocar un sólo fichero
  • Nada reusable
  • Sólo válido para proyectos pequeños

Es tan sencillo como escribir el mapeo antes de crear el servidor y usar funciones anónimas para la lógica

1
app.get('/', function(){res.send('root page'});

Mapear en app y la lógica en ficheros distintos

Este es el segundo ejemplo más habitual. Las url se definen en el fichero principal y las funcionalidades se agrupan en distintos ficheros bajo el directorio routes.

  • Añadir una nueva url implica tocar como mínimo dos ficheros
  • Favorece la reutilización, pero siempre debemos colocar las url a mano
  • Implica escribir más código que en el anterior y perder legibilidad

A pesar de que es muy habitual ver esto no me gusta porque no ganamos demasiado, y tener que hacer cambios en dos ficheros acaba introduciendo errores.

1
2
3
4
5
6
// app.js
var routes = require('./routes');  // Coje el fichero ./routes/index.js por defecto
var user = require('./routes/user');

app.get('/', routes.index);
app.get('/users', user.list);
1
2
3
4
// routes/user.js
exports.list = function(req, res){
res.send("respond with a resource");
};
1
2
3
4
// routes/index.js
exports.index = function(req, res){
res.send("root page");
};

Hacer el objeto app global y derivar todo hacia los ficheros de routes

Evitamos declarar app como variable local, para poder usarla en el resto de ficheros sin tener que preocuparnos de pasar parámetros. El código queda muy limpio pero se dificulta el testing y se pueden introducir bugs difíciles de detectar.

A mi me gusta esta aproximación cuando tenemos poco código y queremos hacer algo rápido, pero hay que ser consciente de los problemas que tiene.

  • No es una muy buena práctica hacer app global, en el siguiente punto vemos una mejora. Pero al hacerlo así obtenemos código más legible
  • Es bastante modular (excepto por hacer app global)
  • Es bastante legible
  • Hay separación de conceptos, cada fichero se encarga de unas determinadas url y funcionalidades

Referencias

Veamos como quedaría la implementación

1
2
3
// app.js
app = express(); //IMPORTANT! define the global app variable prior to requiring routes!
require('./routes');
1
2
3
// routes/index.js
require('./main');
require('./users');
1
2
3
4
// routes/main.js
app.get('/', function(req, res) {
res.send("root page");
});
1
2
3
4
5
6
7
// routes/users.js. list() could be an anonymous function, this is only for showing it in another way.

function list(req, res) {
res.send("user list");
};

app.get("/users", list);

Inyectar app en los ficheros de routes

Es similar al ejemplo anterior, pero el objeto principal es inyectado en los controladores en lugar de usarlo como una variable global. Sacrificamos un poco de legibilidad (hay que meter bastante código “inútil”) pero a cambio ganamos en modularidad y testabilidad.

Veamos una posible implementación, teniendo en cuenta que este código no lo he visto en ningún sitio, lo he escrito a partir del artículo de dailyjs y podría tener algún otro problema.

A mi esta es la aproximación que más me gusta, cuando el código aumenta y no nos queremos ir a soluciones más complicadas.

1
2
3
4
5
// app.js
var app = express();
// ...
app.use(express.json());
require('./routes')(app); // Must be called after app.use(express.json()) and urlencoded;
1
2
3
4
5
// routes/index.js
module.exports = function(app) {
require('./main')(app);
require('./users')(app);
};
1
2
3
4
5
6
7
// routes/main.js
module.exports = function(app) {
function index(req, res) {
res.send("root page");
};
app.get('/', index);
};

Otras estrategias

Hay estrategias más complejas, que por ahora no me ha hecho falta probar.