DÍA 11 / 2017

Asteroids: nuestro starter kit de proyectos web

En Bellas Artes, a poco que avanza el curso te enseñan a preparar tus propias herramientas, a probar con qué te sientes más cómodo. Hoy, en web, tenemos toda la base necesaria para poder establecer una metodología que se ajuste a nuestro equipo y a nuestros proyectos.


Habiendo mogollón de frameworks, starters kits y herramientas para empezar un proyecto web, en Space Nomads, nos hicimos el nuestro, y lo llamamos Asteroids.

Otro starter kit ¿Por qué?

Pues hay dos razones principales: por necesidad y por aprender.

Montar tu base para proyectos te permite valorar tu relación con las herramientas disponibles y que no solo no tienes que adaptarte a ellas, sino que con unos conocimientos mínimos puedes ajustarlas a tu rutina.

Somos un estudio pequeño y nuestro proyecto tipo es una web de pocas páginas y/o para la que solo vamos a desarrollar una serie de plantillas que otro equipo integrará más adelante (Y si tenemos mucha suerte no tendremos que lidiar con IE9).

Al final del día necesitamos algo que se ajuste a nuestra forma de trabajo y que podamos modificar de una manera ágil cuando ésta cambie (que lo hará).

Venga, ¿y qué lleva vuestro rollo?

Hemos incluido un sistema potente de plantillas con su preprocesador de CSS y un poquito de JS.

Más en detalle, tenemos una carpeta de desarrollo donde van tanto los archivos estáticos como los que procesaremos, y con todos estos generamos la carpeta pública que luego nuestro cliente podrá subir a su servidor (o entregar para que trabajen sobre ella).

La estructura de carpetas tiene esta pinta:

/
|- _source
|   |- assets
|   |   |- img
|   |   |   `- layout
|   |   `- js
|   |       `- vendor  
|   |- js
|   |   `- plugins
|   |- scss
|   |   |- components
|   |   |- core
|   |   |- pages
|   |   `- vendors
|   `- templates
|      |- layout
|      `- partials
|
`- public
   `- assets
       |- css
       |- img
       |   `- layout
       `- js
           `- vendor

HTML

Ahora estamos muy a tope generando nuestro html con PUG que es un sistema de plantillas bastante potente que antes se llamaba Jade y que ahora no, y tiene un perrete de logo: PUG.

Lo elegimos porque tiene una sintaxis mega limpia que te fuerza a mantener un tabulado correcto con el bonus de contar con includes, variables, bucles y hasta filtros, por si te vienes arriba y quieres escribir tu contenido en markdown.

PUG nos permite, por ejemplo, tener contenido en un JSON y usarlo para generar: un menu, un pequeño sistema de idiomas, un listado de speakers, etc…

Y todo esto se traduce en un html de tabulado impecable y coherente, o compactado sin un solo espacio de más.

En nuestro caso concreto usamos un juego básico de variables y bloques por plantilla que luego ajustamos en cada página, donde indicamos la plantilla que tiene que usar y metemos el contenido de cada bloque que hayamos definido:

index.pug

extends layouts/main.pug

block vars
    - var lang = 'es'
    - var template = 'tpl__home'
    - var page = 'home'
    - var pageTitle = 'Asteroids homepage'


block main
    article
        .wrapper
            p (Main content)

Nos gusta tener, al menos, dos clases por página: la plantilla a la que pertenece y una particular de cada página. Pero lo bonito de esto es que mañana lo cambiamos si lo necesitamos.

En cualquier caso, hay más sistemas de plantillas, lo que no sé es cómo trabajábamos antes sin uno, ;).

CSS

Pues seguimos con SCSS, nos sentimos cómodos con este preprocesador y por ahora tenemos más que suficiente. No cargamos mucho más, tenemos una pequeña librería de funciones y mixines de cosas muy básicas que usamos sí o sí. Y unas variables base con una nomenclatura común.

Como resumen tenemos los colores con su “nombre” y a qué se lo vamos a aplicar, medidas varias, la configuración de tipografía, tiempos para las transiciones, rutas para las imágenes, un array para controlar a todos los z-index, y los breakpoints principales.

De postre, nuestro gulp usa gulp-combine-mq para agrupar todas las mediaqueries al final del documento css.

Nota:
Últimamente nos está dando algún problema cuando trabajamos con otros equipos o usando los @imports de google fonts, así que veremos dónde acaba, :(.

Del SCSS hay poco más que contar, en general trabajamos mucho por parciales de manera que en la carpeta de desarrollo tengamos el proyecto suficientemente modularizado.

Como anécdota, antes tenía una tarea de gulp que me permitía escribir en el css !hosita(!hostia) en lugar de !important, que la tecnología también tiene que servir para divertirse, ¡hombre ya!

JS

Seguimos usando jQuery porque nos resulta cómodo y porque viene incluído en la mayoría de proyectos en los que hemos colaborado estos casi 3 años. Sin más. Claro que nos parece bien tirar con Vanilla JS 😉 y ES6, pero no tenemos una prisa especial.

Bueno, a lo que vamos, Asteroids tiene dos librerías incluídas: JQUERY y Modernizr con más o menos test, según el proyecto. Y tres plugins que al final acabamos usando cada vez:

  • Width snitch: coloca un chivato para ver el ancho real del contenido.
  • jquery.cookie: para gestionar el tema de cookies.
  • Breakpoints: para lanzar eventos cuando pasas de un breakpoint a otro.

Y ya, tenemos el JS modularizado para trabajar en pequeños bloques de funcionalidad siguiendo las línea de un proyecto que llevamos. Esta es la parte que necesita más trabajo, pero poco a poco, :).

NODE/GULP

La base de Asteroids empezó con php, luego con Codekit, pasamos a Grunt, Gulp, Prepros y hemos vuelto a Gulp.

Con node y gulp gestionamos que todo lo anterior vaya funcionando, tenemos varios tipos de tareas: Las que copian los archivos estáticos de la carpeta de trabajo a la final, las que procesan archivos como PUG, SCSS y JS, y las que ejecutan las anteriores en orden para procesar los archivos, lanzar un servidor (con BrowserSync) o generar un ZIP de la carpeta pública listo para enviar al cliente.

Actualmente partimos de un archivo JSON con las rutas de los archivos y que se carga en nuestro gulpfile.js para ejecutar las tareas que toquen. A veces usamos un segundo archivo JSON para poder tener una configuración diferente a la de nuestro cliente…

HumansTXT

Hombre, siendo parte del equipo que lanzó HumansTXT este archivo siempre tendrá un hueco muy especial en nuestros proyectos.

¿Qué necesita mejorar?

La intención principal con Asteroids es tener una herramienta con la que trabajar nosotros, lo tenemos en github porque creemos que si es suficiente para nuestro día a día quizás a alguien más le pueda hacer el apaño o servir de base para su siguiente proyecto.

Dicho esto, sí, tenemos varios frentes que nos gustaría mejorar:

  • Recarga de archivos: Cuando hay 5 páginas no se nota pero cuando tienes una cantidad suficiente de páginas y parciales cada cambio en parciales/páginas/html dispara unas recargas encadenadas que son una delicia (NO). Esta es nuestra prioridad 2 (la 1 es sacar el proyecto que toque).
  • ZIP con timestamp: Ahora mismo creamos un zip de la carpeta pública sin más pero nos gustaría que generase uno con la fecha y quizás una palabra clave para identificarlo (porque pertenezca a una tarea concreta), por ejemplo: YYMMDD-proyecto-tarea.zip. Pero además, sería genial que comprobase si existe el archivo y pudiese generar un YYDDMM-1-proyecto-tarea.zip si se diese el caso.

Así que si te mola y/o sabes solucionarlo, siéntete con la autoridad suficiente para echarnos una mano, mejorar el proyecto o hacer algo diferente.

Y esto, ¿Cómo me lo instalo?

Asteroids funciona sobre NodeJS y Gulp, así que necesitarás tenerlos instalados.

Desde la página del proyecto en Github (https://github.com/spacenomads/Asteroids) te lo puedes descargar en ZIP o clonarlo. O si eres fan de Bower puedes lanzar un

$ bower install asteroids-kit

Una vez descargado tendrás que instalar las dependencias que aparecen en el archivo package.json

$ npm install

y arrancarlo con

$ gulp go

Arrancamos un servidor con BrowserSync y va revisando los archivos y recargando el navegador cuando procede.

En el archivo gulpfile.js encontrarás las otras tareas para procesar una nueva versión o comprimir la carpeta pública en un zip.

😉 Si todavía no le has perdido el miedo a la terminal, echa un ojo al post “La línea de comandos es el futuro” de Jorge Aznar.

Si lo pruebas y tienes cualquier comentario danos un toque por twitter, o déjanos un issue, o si te animas con un pull request, adelante.