Mantén la consistencia de tu código con .editorconfig

Generalmente tenemos un editor de cabecera, ese aliado que nos acompaña en todas nuestras aventuras de código, pero en ocasiones nos vemos obligados a usar un editor distinto a nuestro leal amigo (o lo que es peor un IDE), por lo que la consistencia de nuestro código podría llevar los platos rotos.

Pero sabemos que en el mundo del desarrollo y la tecnología casi siempre hay una propuesta para este tipo de entresijos, EditorConfig:

EditorConfig ayuda a los desarrolladores a definir y mantener guías de estilo para código consistente entre editores e IDEs.

El proyecto EditorConfig consiste en un formato de archivo que sirve para definir estilos de código y una colección de plugins para editores de texto que permiten a los editores leer el formato de archivo y adherir los diferentes estilos.

Los archivos de EditorConfig son fáciles de leer y trabajan muy bien con sistemas de control de versiones.

En nuestro proyecto agregaremos un archivo llamado .editorconfig dónde volcaremos todas esas reglas de estilo de código (tamaño de sangría, soft tabs o hard tabs entre otros), ¡podemos definir reglas para distintos formatos de archivos!.

Brackets, Atom.io y Sublime Text son 3 de los muchos editores compatibles con .editorconfig
Brackets, Atom.io y Sublime Text son 3 de los muchos editores compatibles con .editorconfig

No detallaremos como instalar los plugins de .editorconfig para cada uno de los editores que soportan, en la web oficial lo hacen muy bien, nos concentraremos en la sintaxis, la cual se divide en:

  • Los patrones de comodines: estos se expandirán según sea el caso para coincidir con el patrón que queramos, los cuales no son más que las expresiones regulares de toda la vida.

  • Las propiedades: que aplicaran las reglas para mantener la consistencia del código.

Comodines

  • *: Coincide con cualquier cadena de caracteres, excepto con el separador de ruta (/), ejemplo una regla con [*] se aplicará a todos los archivos en el proyecto o [*.css] a todos los archivos css.

  • **: Coincide con cualquier cadena de caracteres.

  • ?: Coincide con un sólo carácter.

  • [nombre]: Coincide con cualquier carácter individual en “nombre”, por ejemplo [app.js].

  • [!nombre]: Coincide con cualquier carácter individual que NO esta en nombre.

  • {s1,s2,s3}: Coincide con cualquiera de las cadenas dadas (separadas por comas).

Propiedades

  • root: Propiedad especial que debe especificarse al inicio del archivo, con valor true, esto le dirá a los plugins de cada editor que debe aplicar las reglas de estilos de código incluidas en ese archivo.

  • indent_style: establece el tipo de indentación a “tab” o “espaciado”, hard-tabs y soft tabs respectivamente.

  • indent_size: especifica el tamaño de la indentación según el tipo de que se haya elegido con la propiedad indent_style (o con el estilo indentación por defecto en el editor si no se especificó ninguna).

  • end_of_line: establece el tipo de final de línea, sus posibles valores son “lf”, “cr”, or “crlf”.

  • chartset: específica la codificación de carácteres, los posible valores son “latin1″, “utf-8″, “utf-8-bom”, “utf-16be” o “utf-16le” siendo “utf-8-bom” desaconsejado.

  • trim_trailing_whitespace: si esta propiedad tiene como valor true se removerá cualquier espacio antes de cada nueva línea, false hará lo contrario.

  • insert_final_newline: establecer true agregará una nueva línea al final de todos los archivos.

Ejemplo .editorconfig

Conclusión

Sin duda .editorconfig es intuitivo y útil, una vez domines su uso podrás, por ejemplo, armar una colección de archivos según el proyecto en el que hayas trabajado, por lo que también es reutilizable.

Sólo debes andarte con ojo, los plugins para cada editor no suelen soportar todas las propiedades de .editorconfig, por lo que antes de usarlo dale una repasada al soporte que ofrecen, de resto sólo queda decir: por favor, mantén la consistencia de tu código con .editorconfig.

¿Usabas .editorconfig?, comparte tu configuración preferida en los comentarios y cuentanos por qué la usas.

Enlaces de interés

API HTML5: Visibilidad de Página

HTML5 es modular, por lo que cada uno de sus componentes se desarrolla a una velocidad distinta dependiendo (entre otras cosas) de su complejidad, propuestas varias, sin además olvidar la implementación progresiva de cada uno de estos componentes en los navegadores modernos, entre un montón de nuevas características se encuentra el API HTML5 visibilidad de página (Page Visibility API) la cual en palabras llanas nos permite saber que pestaña del navegador se encuentra activa y a partir ejecutar las acciones que cambien el comportamiento de nuestra web o aplicación web.

Veamos un ejemplo sencillo, una vez ingreses en el enlace anterior selecciona o abre cualquier otra pestaña de tu navegador y luego vuelve a enfocar la pestaña del ejemplo para modificar el comportamiento de la página.

Funcionamiento

Simple, el objeto document cuenta con una propiedad llamada hidden que no es más que un boleano que será true cuando la pestaña actual no este seleccionada o enfocada (es decir, el contenido de la pestaña no es visible para el usuario) en caso contrario valdrá false.

El cambio de esta propiedad puede ser manejado con el evento visibilitychange proporcionado por la API, este evento se dispara cuando el contenido cambia del estado visible a oculto y viceversa: cuando enfocamos o desenfocamos una pestaña.

La propiedad document.hidden cubre la mayor parte de los casos de uso pero además esta API viene con una propiedad adicional: document.visibilityState que sólo está disponible dentro del manejador de eventos para visibilitychange, esta propiedad retorna una cadena la cual nos dice por qué la pestaña actual está oculta lo cual nos da una mayor exactitud, los posibles valores y su significado son los siguientes:

  • visible: El contenido de la página debe estar parcialmente visible, es decir la pestaña que tenemos actualmente abierta y enfocada en el navegador en una ventana no minimizada.

  • hidden: El contenido de la página no es visible al usuario, ejemplo: una tab que abre en segundo plano en móviles o el screenlock se encuentra activo, en escritorio es la pestaña seleccionada en una ventana minimizada.

  • prerrender: El contenido de la página está siendo pre-renderizado y no es visible para el usuario (document.hidden considera este estado como true).

  • unloaded: La página es descargada de la memoria, es decir, la pestaña ha sido cerrada.

Con esto en mente, examinemos a fondo el código del ejemplo anterior:

Soporte

Recordemos que esta característica tiene estatus de W3C Recommendation por lo que debería estar lista para usarse en la mayoría de los navegadores modernos, cosa que nos confirma caniuse la cual le da 84% de soporte global y 74% sin prefijos de navegador, sólo con navegadores como Interner Explorer <=9 u Opera Mini 8 como excepción.

En resumen, si en tu proyecto no debes darle soporte a alguno de esos navegadores entonces usa la API de visibilidad con toda confianza (sin olvidar la técnica de detección de más arriba para los prefijos de navegador o usar modernizr).

Conclusión

Como mencioné, es un ejemplo muy sencillo, en la práctica está API puede ser de utilidad para ahorrar recursos, por ejemplo pausar un slider mientras el usuario no está viendo la web, detener una petición al servidor, pausar un vídeo o una canción, o simplemente llamar la atención del usuario en el momento preciso que vuelve a enfocar la página.

La API de visibilidad de página no es tan compleja o impresionante como Canvas, Webgl o SVG pero cumple su cometido y pienso que se hará un espacio en aquellas situaciones donde se utilizaba onblur/onfocus sobre la ventanta para recrear la funcionalidad de visibility page.

Fuente:
Smashingmagazine

Especificación Oficial, documentación y ejemplos:
W3C Page Visibility
MDN
Primer Ejemplo
Ejemplo con audio

6 Cosas que debes saber sobre el nuevo Proyecto Spartan de Microsoft

Proyecto Spartan corriendo en Windows 10
Proyecto Spartan corriendo en Windows 10

Tras rumores Microsoft confirmaba el comienzo del fin en una era: muerte de Internet Explorer y bienvenida del conocido con el nombre en clave Proyecto Spartan, en su ultima presentación los de Redmont mostraron un abreboca de las características al usuario final así como los medios se han hecho eco de esta presentación hablando largo y tendidos de ellas, pero ¿y los desarrolladores qué?:

1) Un nuevo motor de renderizado para dominarlos a todos

Comparación de Trident (MSHTML) y El nuevo render engine de Spartan (EdgeHTML)
Comparación de Trident (MSHTML) y El nuevo render engine de Spartan (EdgeHTML)

Es una de las noticias más interesantes con respecto a Spartan, los chicos de Microsoft comentan que luego de clonar el repositorio (lo que llevó 45 minutos) de Trident (actual render engine de IE, específicamente usaron el de la versión 11) comenzaron con la tarea de quitar todo código que no estuviese en consonancia con los estándares web y mucho al cual Internet Explorer le debe su mala fama a pesar de las mejoras y cambio de filosofía que ha tenido en los últimos años, algunos de esos cambios son:

2) Un navegador, dos motores

Ya sabemos que Spartan no es simplemente un lavado de cara o cambio de branding para enterrar la maldición IE, sino que viene con un nuevo motor completamente orientado a los estándares web que es sumamente beneficioso para los desarrolladores y el usuarios común, pero el sector corporativo puede ver esto con recelo ya que existen empresas en las cuales sus aplicaciones están diseñadas para trabajar con versiones antiguas de IE, usualmente Internet Explorer 8, el equipo de Microsoft ha resuelto esto con un modo dual transparente para el usuario, cuando Spartan acceda a una web corporativa cargará el motor Trident (MSHTML), en todos los demás casos cargará el nuevo motor (EdgeHTML) de Spartan.

Esto que llaman EnterpriseMode, le dará tiempo a las empresas a planificar las actualizaciones de sus aplicaciones debido a que si bien Trident recibirá actualizaciones de seguridad será dejado de lado progresivamente.

3) Aquel viejo bug que te estaba molestando…

Según palabras del propio equipo de desarrollo, Spartan también estará enfocado en la “interoperabilidad con otros navegadores para que los desarrolladores no tengan que lidiar con inconsistencias cross-browser”, cuentan que han arreglado cerca de 3000 problemas de interoperabilidad de los cuales algunos se remontaban a los años 90.

4) Montones de nuevas características

Este navegador contará con un nuevo identificador User Agent así como más soporte para especificaciones web, algunas de las que se esperan para las primeras versiones de Spartan son las siguientes:


5) Chakra se mantiene como Motor de Javascript

El mismo motor que potencia el Javascript a desde la version 9 de Internet Explorer se mantendrá para Spartan.


6) Extensiones para todos.

Las extensiones se encuentran en fase de planificación, por lo que probablemente no estarán listas para la primera versión de Spartan pero se incluirán en actualizaciones futuras, eso si, hay rumores sobre la posible compatibilidad con extensiones de Chrome, del modo que sea, esta característica haría más competitivo a este nuevo navegador con usuarios cada vez más exigentes que de no encontrar una función especifica recurren a un add-on para lograrlo.


Conclusión

Aún queda mucha tela que cortar con respecto al Proyecto Spartan debido a que esta una fase temprana de desarrollo, esperar la liberación de su primera versión al publico a través de Windows 10 Thecnical preview a mediados de Enero-Febrero 2015 es algo que tiene a los desarrolladores muy atentos, si estas muy ansioso por usar este nuevo navegador recuerda que su render engine viene por defecto en el nuevo Windows 10 (build 9926), por lo que sólo debes activarlo navegando a about:flags y seleccionar la opción “Experimental Web Platform Features” para comenzar a explorar sus características.

Actualización: Spartan podría venir incluido en la build 10009 de Windows 10

Via (también credito de las imágenes):