Using Envoy to automate repetitive tasks

Envoy is a task runner originally developed for Laravel, but that you can also use on any other kind of project.

It’s a very easy way to define tasks with Blade syntax and simple terminal commands, which you can run on remote servers via SSH (including parallel execution) or locally.

Thanks to its simplicity, it’s great to quickly automate repetitive tasks. For instance, this is something I use for importing a replica of the production DB of a site:

@servers(['production' => '', 'local' => 'localhost'])


@task('dump-production-db', ['on' => 'production'])
    echo 'Creating production DB dump';
    cd ddbb
    mysqldump --no-autocommit --skip-extended-insert --single-transaction --ignore-table=foobar.wp_simple_history_contexts --ignore-table=foobar.wp_simple_history_history foobar_production | gzip > foobar.production.sql.gz

@task('get-production-db', ['on' => 'local'])
    echo 'Copying DB dump from production server';
    cd ddbb
    rsync -P foobar:~/ddbb/foobar.production.sql.gz .

@task('import-production-db', ['on' => 'local', 'confirm' => true])
    cd ddbb
    gzip -d -f foobar.production.sql.gz
    sed 's/' -i foobar.production.sql
    echo 'Importing production DB replica';
    mysql -v foobar_development < foobar.production.sql

SSL configuration generator

Configuring SSL can be a really tricky juggle between security, performance and compatibility.

Mozilla has published a wizard-like SSL configuration generator that supports various web servers (Nginx and Apache included) and OpenSSL versions, with different presets for old, intermediate or modern-only browser compatibility.

Some notes about using web fonts

I just launched a new design for this site, and in this process I was particularly meticulous about my typographic choices.

These are a few of the things I learned.

Only use what’s necessary

This is somewhat obvious, but it’s still a fairly common mistake: you should only use and include the necessary fonts that make your design work.

There are several font families that use multiple styles and sometimes it’s tempting to use nearly all of them: normal, light, medium, bold, ultrabold, italic, bold italics… But you should remember that for every style, the user must download another file, and all of those bytes can add up to a painfully slow page load — which will make both your users and Google sad.

Try to avoid using an specific style for a single UI element, and remember that different families have very different file sizes.

Lastly, and even though it might be considered an abomination for typography nerds, remember that browsers can an usually will fake some basic font styles such as bold (simply thickening the “normal” style) or italics (with a slight slant).

Create a check-list with your requisites

The Google Fonts catalogue has over 700 font families; the full Typekit library over 1200. If you have enough time or are somewhat indecisive you can really go crazy before settling for the perfect fonts combo.

A good idea to help in your decision process it’s to create a check-list with all the requisites you need to fulfil, for instance:

  • The file weight for a single style must be less than 40 Kb (compressed)
  • The font family must have these styles: normal, bold, italic, bold italic
  • It must support non-english characters such as accented vowels
  • The normal style must be highly readable on small sizes

Changing your main font family on the middle of the design process can be a real pain: re-setting the body size and line height affects your entire design, so it’s a choice that must be carefully weighted.

Watch out for bugs

Fonts are not immune to bugs; watch out for thinks like:

  • Missing or erroneous characters: make sure you thoroughly test all the characters you need to support and check that all of them are shown correctly. For instance, when testing a font I found that the character for a typographic ellipsis looked like a single dot.
  • Variable heights on different styles: previous versions of the Roboto family had different heights on some of the styles, even when setting an explicit line-height. For instance, a single line of text using just the normal style showed the expected line-height, but when using a single (or more) bold characters, it increased the line-height. This was fixed on a newer version.
  • Hinting issues: when I decided to self-host the fonts for this site, I used FontSquirrel’s webfont generator to convert to the different formats required for each browser and further optimize the fonts by subsetting only the required characters. Even though I used previosuly hinted fonts, when I chose to Keep the existing hints the result looked awful on Windows, so instead I used the unhinted versions with TTFAutohint.

Many of the fonts available through Google Fonts are published on GitHub, so if you find a bug you could contact the developers and submit an issue, but it’s uncertain how long will it take for Google to update their version (which it’s in part why I’m self-hosting the fonts for this site).

Enable ligatures or other font features

After you finally made up your mind and chose the perfect fonts, make sure to show them in all of their glory.

Even though Firefox enables ligatures by default, Google Chrome and Safari don’t, so you need to explicitly activate them, like:

h1, h2, h3, h4, h5, h6{
    font-variant-ligatures: common-ligatures discretionary-ligatures;

There are plenty of other font features that you can control; check the font-variant docs on MDN to get a good overview.

Mantener CSS compilado fuera de tu repositorio git al usar LESS/SASS con Grunt y hooks

Ten un repositorio git ordenado y liviano al excluir los CSS compilados y regenerarlos automáticamente con Grunt y hooks de git.

Una de las desventajas de trabajar con pre-procesadores (ya sea LESS, SASS u otros) es que los archivos producidos pueden generar mucho ruido en el historial de versiones de tu proyecto, lo que es especialmente crítico si estás compilando a archivos minificados o a varias cascadas a partir de un set de variables.

Por ejemplo, si cambias una variable que define un color utilizado en muchos lugares, tu historial mostrará no solamente ese cambio sino también todas las líneas del CSS donde cambió ese valor. Luego, al revisar cambios anteriores se hace mucho más difícil poder determinar fácilmente cuáles son cambios son relevantes (el cambio en el archivo fuente LESS/SASS) de los que no (todas las líneas modificadas en el CSS resultante).

Por ello, una práctica recomendada es versionar los archivos LESS/SASS pero no el CSS resultante, ya que estos últimos son solamente el producto del proceso de compilación de las fuentes.

Para que tu CSS refleje fielmente los cambios en LESS/SASS, puedes automatizar la compilación con una mezcla de tareas en Grunt y hooks de git.

Continue reading “Mantener CSS compilado fuera de tu repositorio git al usar LESS/SASS con Grunt y hooks”