Scipion

Quick start framework

por

Independientemente del Javascript fatigue cada nuevo framework que ha sido adoptado en el presente o en el pasado ha tenido una buena docuementación.

IMHO esa es la verdadera clave de la adopción. Esa fué una de las claves de la adopción de jQuery; sin desmerecer la simplicidad y resolver el problema de compatibilidad entre navegadores que se daba en su día. Hoy caido en desgracia, sigue siendo uno de las librerías más usadas (y descargadas) en javascript.

Según aumenta la complejidad de una librería, más importante se hace su documentación, y para facilitar la adopción un Quick Start (AKA Getting Started) se agradece mucho por los desarrolladores.

Si no existe en la documentación oficial lo creará la comunidad; Si no lo crea la comunidad ni el equipo debe de ser muy muy fácil de usar; si no es así no acabará siendo adoptada.

A veces es tan fácil como un README.md un poco más largo en el que se ve cómo se usa. Otras veces algo más ya que hay que se debe explicar algún concepto clave, pero un Quick Start de al rededor de 15 minutos de lectura es uno de los Top 3 más importantes para adopción de una librería.

Lenguajes de programación

por

A la hora de elegir un lenguaje de programación no es suficiente mirar la sintaxis o el grupo de probemas que resuelve. Eso hay que mirarlo por supesto, pero (enfasis en el) no es suficiente.

Yo tuve un profesor que decía:

Yo tuve un profesor que decía: En quince días se puede aprender cualquier lenguaje.

– Mi profesor que decía cosas que decía su profesor –

Y estoy completamente deacuerdo. Alguien que ya programe puede aprender la sintaxis y «tirar lineas» en dos semanitas. Pero eso no es suficiente.

Creo que hay 3 patas para todo lenguaje (igual si mañana pienso que hay más escribiré otro post) que tambien hay que tener muy en cuenta a la hora de elegir lenguaje:

  • Sintaxis
  • Librerias (Bibliotecas)
  • Comunidad

Todas igual de valiosas. La sintaxis podria extenderse a los paradigmas que implementa o los patrones que son más «fáciles» de implementar. Alivia la fricción del día a día.

Las Librerías son imprescindibles para llegar lejos rápido. Problemas comunes ya resueltos, si están resueltos no quiero reinventar la rueda (o no deberia de querer aunque me encante).

La comunidad surge de las dos anteriores, pero mejora las dos anteriores. El feedback imprescindible para mejorar, pero no solo eso hace una comunidad, tambíen mejora la sintaxis y las librerías (así como crea nuevas con menos fricción, bueno … el software libre es marabilloso). Así como para hacer preguntas y responderlas a problemas más comunes; en Stackoverflow y «foros» varios. Con estos se alimentas las IAs que escriben código.

Git cheatsheets, en plural

por

¿Alguna chuleta de comandos git buena? No se elegir de tantas que hay. Varias me gustan. Git es hoy en día core para todo proyecto de software.

Por un poco de diogenes digitar he decidido acumular chuletas de comandos de Git. Github, Gitlab y Atlassian por supuesto tienen su cheatsheet, pero también GitKraken y Boston University tienen la suya. Y muchas que dejo fuera que son posts de distintas fuentes, un poco menos «oficial», porque oficial no hay ninguna, pero me parece muy interesante ver como cada organización le da más relevancia a unos comandos que a otros.

Me gusta particularmente el diseño de GitKraken. Tiene más texto del que me esperaria en una chuleta, pero el estilo es su factor diferenciador. Algo en tener en cuenta cuando haces una chuleta de comandos.

Signals 101

por

Jack Herrington siempre es muy didáctico en sus explicaciones. Aquí le da una vuelta a las señales (Signals) en los distintos frameworks. Me parece muy interesante como se puede utilizar tanto con VDOM como sin el, y con rendering «tradicional» o una actualizacion de grano más fino. Genial explicación.