My web stack of choice is Symfony as an API (either RESTful or using GraphQL) and a frontend using Vue.js. I used to rely on NVM or Volta and make use of my locally installed Node instance, but I wanted to have something completely portable - something where I could just clone a repo, run ddev start and get to work. To achieve that, we're going to set things up as follows:

• Set up the PHP container and Symfony
• Freeze the Node version and install Vue.js
• Add a reverse proxy to access the frontend
• Enhance the DX thanks to a Makefile

For this project, we're going to use a made-up domain - let's say tinydev.ddev.site - and have the API available at api.tinydev.ddev.site and the web app at app.tinydev.ddev.site. I'm going to assume you already have Docker and DDEV installed and ready to use.

To keep things tidy, we'll use the following folder structure:

/.ddev
 - config.yaml
/backend
 - Symfony files...
/webapp
 - Vue.js files...

The /.ddev folder will contain its configuration file (config.yaml), with the Symfony API inside /backend and our frontend inside /webapp.

Setting up the Symfony app

Let's begin by using ddev config to initialize the project, selecting symfony as the application type. The docroot for our project will be backend/public.

Once configured, open /.ddev/config.yaml and add the additional host names (api.tinydev and app.tinydev). The configuration file should look like this:

name: tinydev
type: symfony
docroot: backend/public
php_version: '8.3'
webserver_type: nginx-fpm
xdebug_enabled: false
additional_hostnames: [ 'api.tinydev', 'app.tinydev' ]
additional_fqdns: [ ]
database:
  type: mariadb
  version: '10.11'
use_dns_when_possible: true
composer_version: '2'
web_environment: [ ]
corepack_enable: false

Start DDEV with ddev start, then enter the web container using ddev ssh. We'll install Symfony in the backend directory (at this time of writing the latest version of Symfony is 7.2). We'll have to delete the backend directory first so that Composer can generate the project.

> rm -rf backend && composer create-project symfony/skeleton:"7.2.x" backend

Once installed, create a simple controller to test everything is working as it should:

<?php
// /backend/src/Controller/HomeController.php

namespace App\Controller;

use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Attribute\Route;

final class HomeController extends AbstractController
{
    #[Route('/')]
    public function index()
    {
        return new Response("Hello, World!");
    }
}

You can go ahead and point your web browser to https://tinydev.ddev.site` and you should be greeted with a "Hello, World!" message. If not, don't hesitate to restart DDEV with ddev restart.

At this point, https://app.tinydev.ddev.site is also pointing to Symfony. Let's take care of that.

Freeze Node's version and install Vue.js

By default, DDEV comes bundled with Node v22. Let's freeze that so we don't have any bad surprises during our development phase. This can be done very simply inside /.ddev/config.yaml

nodejs_version: '22'

Go ahead and restart DDEV (ddev restart) and enter your web container with ddev ssh. We'll now install Vue.js in the webapp directory:

> npm create vue@latest

You can choose the flavor you're most familiar with, but the important thing is to specify webapp as your project's name, as this will be the directory used to install the Vue.js app. Then you can install the app itself:

> cd webapp && npm install

Let's point our browser to https://app.tinydev.ddev.site and get... nothing? That's expected. The app is installed, but it's not accessible yet.

Add a reverse proxy to access the frontend

To address this issue, let's add an nginx config file in /.ddev/nginx_full/app.tinydev.conf:

server {

    server_name app.tinydev.ddev.site;

    location / {
        proxy_pass http://localhost:5173;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }

    listen 80;
    listen 443 ssl;

    ssl_certificate /etc/ssl/certs/master.crt;
    ssl_certificate_key /etc/ssl/certs/master.key;

    include /etc/nginx/monitoring.conf;

    error_log /dev/stdout info;
    access_log /var/log/nginx/access.log;

    include /etc/nginx/common.d/*.conf;
    include /mnt/ddev_config/nginx/*.conf;
}

We'll also have to edit vite.config.ts to allow for this new hostname:

// /webapp/vite.config.ts
import { fileURLToPath, URL } from 'node:url';

import { defineConfig } from 'vite';
import vue from '@vitejs/plugin-vue';
import vueDevTools from 'vite-plugin-vue-devtools';

export default defineConfig({
  server: {
    allowedHosts: ['app.tinydev.ddev.site'],
  },
  plugins: [vue(), vueDevTools()],
  resolve: {
    alias: {
      '@': fileURLToPath(new URL('./src', import.meta.url)),
    },
  },
});

Let's now restart DDEV (ddev restart) once more, then hop into the container (ddev ssh) and run npm run dev inside the /webapp directory. Don't forget to run npm install if you haven't already.

If you now point your browser to https://app.tinydev.ddev.site, you should see Vite's default project page.

We now have a working project using Symfony and Vue.js entirely containerized thanks to DDEV! Yay! :tada:

You can now enjoy your web app on https://app.tinydev.ddev.site, and send calls to your API that's residing on https://api.tinydev.ddev.site.

Let's finally add a bit of magic and enhance our Developer Experience thanks to a simple Makefile.

Enhance the DX thanks to a Makefile

Having to enter the container to start Vite's web server can get tedious. The same goes for simple Symfony tasks like creating a migration or even emptying the cache, we'd have to change directories and tinker with php bin/console commands. Fortunately, we can use a Makefile as a development toolbox with handy shortcuts:

Important: Make sure to use tabs (not spaces) for indentation!

# /Makefile

WEBAPP_FOLDER=/var/www/html/webapp
API_FOLDER=/var/www/html/backend

start:
	ddev start

stop:
	ddev stop

up: start
	ddev exec --dir $(WEBAPP_FOLDER) npm run dev

cache-clear:
	ddev exec --dir $(API_FOLDER) php bin/console cache:clear

cc: cache-clear

migration:
    ddev exec --dir $(API_FOLDER) php bin/console make:migration

Keep in mind that you may still want to use ddev ssh for running Composer, as DDEV executes the ddev composer command at the project root by default.

So there you have it! A simple, portable development environment you can use anywhere and share with others.

Happy coding!

Here, we'll see how to use Eleventy to get a multi-lingual website working, as well as how to handle JavaScript and CSS assets thanks to its build process.

Compile JS/SCSS assets

Let's start with JavaScript and CSS compilation. For that, as we've seen in the first part, I put those files my project's /src/_assets directory. Left as is, those files aren't processed by Eleventy, and are simply ignored during build time. For those to be taken into account, I create a specific file with the extension .11ty.js.

JavaScript

For JavaScript, we're going to need the esbuild dependency:

npm install --save esbuild

We then create the /src/scripts.11ty.js file with the following code:

// /src/scripts.11ty.js
const esbuild = require('esbuild');
const { NODE_ENV = 'production' } = process.env;

const isProduction = NODE_ENV === 'production';

module.exports = class {
  data() {
	return {
  	permalink: false,
  	eleventyExcludeFromCollections: true
	};
  }

  async render() {
	await esbuild.build({
  	entryPoints: ['src/_assets/js/main.js'],
  	bundle: true,
  	minify: isProduction,
  	outdir: 'dist/js',
  	sourcemap: !isProduction,
  	target: isProduction ? 'es6' : 'esnext'
	});
  }
};

Here, we can see one of the great strengths of Eleventy. This file is going to get caught and compiled so that our entry file /src/_assets/js/main.js becomes /dist/js/main.js. And not only will it bring all the needed dependencies but it'll also be minified. Neat!

Stylesheets

The principle here is the same for our CSS assets. To that effect, we'll need the sass dependency:

npm install --save sass

The entry file will be /src/styles.11ty.js with the following content:

const path = require('path');
const sass = require('sass');

module.exports = class SassTemplate {
  data() {
	return { permalink: '/css/main.min.css' };
  }

  render(data) {
	return sass.compile(path.join(__dirname, './_assets/scss/main.scss'), {
  	style: 'compressed'
	}).css;
  }
};

Here again, it's thanks to that .11ty.js extension that the file is getting caught on the fly during build time, and its entry point is /src/_assets/scss.main.scss. The generated file is going to take all the partials and mixins defined in our source file and will end its course in /dist/css/main.min.css, compiled and minified, ready to be used within our templates.

Internationalization (i18n)

The JavaScript and CSS assets being handled, we can now take care of the internationalization of our website. Note here that while I'm describing the method I've decided to use, it may not be relevant or the most optimized for your use case. Thanks to its flexibility, Eleventy allows their users to experiment and use the system they wish. The one I've decided to use has several advantages:

• The separation of context: each language gets their own directory.
• The flexibility: it is quite easy to add new languages.
• The possibility to link pages and create a "bridge" between languages.

So the first thing to do is to separate the different languages in different folders. Thus, we'll get the French content of the website under /fr/ and the English version will reside in /en/. This allows for a separation of context, but also to link (or not) two equivalent pages.

Handle the primary menu

The first issue we're faced with is the main navigation: since our site uses a layout system, it would be inconvenient to split those between different languages. Once again, it could be possible as Eleventy allows it, but having mutualized templates is the preffered method. So for all the things that are not part of the redactional content, we'll make use of our "database" which resides in /_data/site.json: it is a simple JSON file that we can use how we want. I therefore regroup all the entries for the main menu under the headerLinks key, as such:

// /src/_data/site.json
{
  "headerLinks": [
	{
  	"translationKey": "home",
  	"url": {
    	"en": "/en/",
    	"fr": "/fr/"
  	},
  	"external": false
	},
	{
  	"translationKey": "about",
  	"url": {
    	"en": "/en/about/",
    	"fr": "/fr/a-propos/"
  	},
  	"external": false
	},
	{
  	"translationKey": "projects",
  	"url": {
    	"en": "/en/projects/",
    	"fr": "/fr/projets/"
  	},
  	"external": false
	},
	{
  	"translationKey": "blog",
  	"url": {
    	"en": "/en/blog/",
    	"fr": "/fr/blog/"
  	},
  	"external": false
	},
	{
  	"translationKey": "contact",
  	"url": {
    	"en": "/en/contact/",
    	"fr": "/fr/contact/"
  	},
  	"external": false
	}
  ]
}

Under this key, we find an array of objects containin the following keys:

• translationKey is a unique value given to each page. It's thanks to this key that everything works.
• url specifies for each language the link's destination.
• external is a boolean which allows to specify if the link has to open in a new tab or not.

This allows us to generate the main menu for the website:

{%- for item in site.headerLinks -%}
    <a class="navbar-item {% if (page.url == "/" + locale + "/" and item.translationKey == "home") or page.url == "/" + locale + "/" + item.url[locale] + "/" or item.translationKey == category -%}is-active{%- endif -%}" href="{{ item.url[locale] }}">{{ i18n[locale][item.translationKey] }}</a>
{%- endfor -%}

In this loop, we check if the current page is:

• The home page or
• A page within a given cagetory or
• A page of a specific category

This allows us to specify a CSS class is-active, which will make the current menu entry stand out thanks to a colored border or any other CSS property.

As you can see, we'll make use of the translationKey key we've set before in another part of the menu link:

{{ i18n[locale][item.translationKey] }}

This makes use of another "database" file, located in /src/_data/i18n.json. This file is the "dictionary" for our site, and we can store there all the strings that need a translation. Here is a simplified example for this file, so that you can see what it looks like:

{
    "fr": {
        "aboutMe": "À propos de moi",
        "twitterShare": "Vous avez aimé cet article ? Partagez-le sur Twitter !",
    },
    "en": {
        "aboutMe": "About me",
        "twitterShare": "Did you like this article? Share it on Twitter!",
    }
}

But before being able to use this dictionary, it's necessary to specify a locale key for each one of our folders /fr/ and /en/. To do that, we can use another specific thing about Eleventy: the possibility to define data for a whole directory by using a simple file name trick. The file has to have same name as its containing folder. So we'll create a file named en.json in /src/en/ and another fr.json in /src/fr/. The file en.json will contain for example:

// /src/en/en.json
{
  "locale": "en"
}

This little JSON file is the cornerstone for our multilingual support as it allows the use for the locale key I talked about earlier in our templates. This tells Eleventy that everything that resides in this directory has a locale key with a value set to en.

We can now use multiple languages in static pages. For instance, it is now possible to have a page /en/about.md and another /fr/about.md. These two pages have their translationKey set to about, they're "recognized" in the main menu and we can see which page is the current one.

Note that I'm using the same file name here, but nothing prevents you from using /en/about.md and /fr/a-propos.md. It's simply a convention I've decided to use.

But what about secondary pages, and blog posts? Let's fix that immediately.

Handle blog posts

The first thing to do is to specify a file name blog.11tydata.js (in /en/blog/ for instance) and add this code:

// /src/en/blog/blog.11tydata.js
require('dotenv').config();
const fs = require('fs');

const isDevEnv = process.env.ELEVENTY_ENV === 'development';
const todaysDate = new Date();

function showDraft(data) {
  const isDraft = 'draft' in data && data.draft !== false;
  const isFutureDate = data.page.date > todaysDate;
  return isDevEnv || (!isDraft && !isFutureDate);
}

module.exports = function () {
  return {
	eleventyComputed: {
        eleventyExcludeFromCollections: function (data) {
            if (showDraft(data)) {
                return data.eleventyExcludeFromCollections;
            } else {
                return true;
            }
        },
        hasCover: function (data) {
            if (data.page.date) {
                const year = data.page.date.getFullYear().toString();
                const month = ('0' + (data.page.date.getMonth() + 1)).slice(-2).toString();
                const day = ('0' + data.page.date.getDate()).slice(-2).toString();

                const path = `./src/img/blog/${year}-${month}-${day}/cover.webp`;

                return fs.existsSync(path);
            } else {
                return false;
            }
        }
	},
	layout: 'blogpost.njk',
	tags: 'posts_en',
	category: 'blog',
	permalink: '/en/blog/{{ title | slugify }}/'
  };
};

This file is a bit more complex than the simple en.json that we've used earlier, but it allows for several things:

• The use of the eleventyComputed key which allows us to compute data and return a boolean for certain keys that can then be used inside templates. Here for instance I check the presence of a cover.webp file in the corresponding image folder for the blog post (thanks to its timestamp), so that the template can determine if the post has a cover image or not.
• The ability to specify multiple parameters that are shared with every posts, like the layout file to use, but also three very important things: the tags, category and permalink keys.

The first one, tags, allows us to specify the name of a collection we'll loop into inside our template. This might seem a bit complicated at first, but once things are in place, the amount of time gained is considerable. This is also why I've decided to go with Nunjucks as my template engine of choice: we can rebuilt the key to use in our template by using the locale defined in the parent directory. Thus, if we need to loop on the posts in the current locale, we can use the following code inside our template:

{%- for post in collections["posts_" + locale] | reverse -%}
<a href="{{ post.url }}">{{ post.data.title }}</a>
{%- endfor -%}

Just as a reminder, the use of post.data.title will look inside the front-matter of our post Markdown file.

The second key category allows us to make sure we're in the "blog" section of our website (read the previous chapter).

Finally, the third key permalink allows to generate on the fly a unique permalink, made of the title of the post, correctly formed thanks to the slugify dependency.

Note: I'm also using a key called eleventyExcludeFromCollections which allows to see if an article has to be published or not: blog posts marked as drafts (with the draft key set to true) are hidden unless we're in the development environment. This allows us to preview drafts while excluding them from the collection when the site is deployed.

Link posts between them

Thanks to all this, it is now possible to link pages between them with the use of these locale and translationKey keys. For instance, in the template that handles the display of a blog post, here is how I make the connection with the same article in both languages (French and English):

{%- if locale == 'fr' -%}
    {%- set otherLocale = 'en' -%}
{%- else -%}
    {%- set otherLocale = 'fr' -%}
{%- endif -%}

{%- if translationKey -%}
    {%- for otherPost in collections["posts_" + otherLocale] -%}
        {%- if otherPost.data.translationKey == translationKey -%}
            <p class="is-translation-link noprint">
                <a class="is-lang-switcher" data-lang="en" href="{{ otherPost.url }}">{{ i18n[locale]['postAlsoAvailable'] }}</a>
            </p>
        {%- endif -%}
    {%- endfor -%}
{%- endif -%}

Conclusion

We can now use multiple languages on our website. Translations of editorial contents are directly handled thanks to markdown files in the corresponding folders, and data used for the rest (UI, buttons & co.) are translated thanks to the dictionaries.

So certainly, the configuration might seem heavy at first, and it would've been nice to have something directly integrated within Eleventy. But I believe that's also what makes one of its greatest strengths: it is a static site generator that love to put the developer at the helm, and it lets us find the best (or at the very least the most comfortable) way to solve problems we encounter.

In the next (and maybe last?) part of this series of articles, we'll see how to generate a sitemap and an RSS feed file, as well as a few tips and tricks that'll help us with pages and blog posts.

Ever since I started working with interpreted languages, I have to admit that the idea of being able to "compile" a website was surprising to me at first. Nevertheless, something special happens whenever a static site compiles: information is gathered, API calls are made, data passes through, and assets are transformed. And once everything is in place, witnessing all those systems work together like well-lubricated cogs feels immensely satisfying. We are left with a code package that's ready to be delivered, adheres to good practices, and runs extremely fast. Most importantly, the whole thing is as solid as a rock, (almost) impossible to attack, and etched in digital marble.

And yet, the premise is simple: the generator uses Markdown syntax for the editorial content, a templating engine is used to format that content, and finally, a bundle of HTML & CSS files can be deposited on an Apache or Nginx server. No database, no interpreted code, thus making the website ultra-safe and ultra-fast.

Over the years, the website you're currently reading has utilized many of these generators. Let's make a quick rundown of the ones I've had the pleasure to use, and (in my opinion) their strengths and weaknesses.

Jekyll

The first one I've used is Jekyll. A precursor to the JAMStack movement, it was created over 15 years ago by Tom Preston-Werner, the founder of GitHub. Today, Jekyll is arguably the most widely used static site generator globally. It's indeed a great system, and its documentation is excellent. However, the downside is that Jekyll requires installing and maintaining a Ruby environment. If, like me, you're not accustomed to this ecosystem, it can become a bit cumbersome.

Hugo

I then used Hugo, often considered Jekyll's "spiritual son", known for its major strength in extremely short execution time. However, the downside (once again) is that Hugo is written in Go, and its templating syntax is, to put it politely, unique. I never quite got used to its operators or its global syntax. Developing with Hugo was challenging, particularly because its documentation is hard to follow.

That being said, Hugo offers two features I found extremely powerful at the time: its notion of "context" inside template files and its handling of multiple languages. The ability to link content across multiple languages proved to be highly practical and a significant time saver.

Eleventy (11ty)

Finally, the current version of my site has been developed using Eleventy. Once again, its documentation isn't the most practical to read, but it's a project I've been following closely. It benefits from a thriving community and a very "open" approach, which made me want to use it. While i18n support was almost non-existent until a few versions ago, significant progress has been made on this front since then.

One of Eleventy's most attractive features is the fact that it's written in JavaScript. I immediately fell in love with the freedom it offers users. Plus, I believe its name derives from the flexibility of being able to use multiple templating engines.

Quick note while I'm here: the branding of this project is one of the most awkward things I've encountered. The project is called "Eleventy," but the domain is spelled "11ty." Additionally, one of the accepted templating formats gets the extension .11ty.js, while its global configuration file is .eleventy.js. This inconsistency can be quite confusing for newcomers, and I believe the project would benefit from better cohesion around the Eleventy "brand." It may seem anecdotal, but in 2024, I think it's almost obligatory to attract users, even for an open-source project. You just have to look at other frameworks such as Astro or Laravel to realize how important branding is for the success of such products. One last thing before closing this note: if you're looking for the Twitter account for this project, you'll find it under @eleven_ty. :zany_face:

Let's revisit this idea of freedom, which can sometimes lead to confusion. While it's undoubtedly a strength for developers, I believe that better organization within the workspace leads to a cleaner and easier-to-browse codebase. That's why, in this first article of a series dedicated to Eleventy, I'll share the way I organize my work to enhance efficiency in my workflow.

The structure I recommend

By default, Eleventy makes assumptions about where you may store your data. However, these assumptions can be confusing in their naming and lack cohesion. For example, the folder used for templates is called /_includes, while the one for data is called /_data. While seemingly harmless, this structure can lead to mixing these folders with the final site's tree, as well as with folders used for code that will be manipulated later (such as SASS and JavaScript), along with the project's configuration files.

Therefore, I personally use the following structure:

/dist
/src
  /_assets
    /js
    /scss
  /_data
  /_layouts
  /en
    /about
    /…
  /fonts
  /fr
    /about
    /…
  /img

And here's the why:

• /dist

/dist is the destination folder for the generated site. By default, Eleventy uses the /_site folder for this purpose. However, as I mentioned earlier, I prefer not to have this folder mixed with others. Therefore, I use /dist instead. It's important to add this folder to your .gitignore file to prevent it from being committed.

• /src
• /src/_assets
• /src/_data
• /src/_layouts

/src becomes the main working folder. It's in this folder that we'll put all the source code for the site to be generated.

/src/_assets is a folder reserverd for compiled of minified assets, such as JavaScript or SASS. These files are manipulated during the build process by a specific file, generating their final version (we'll cover this in a future article).

/src/_data is the folder that serves as a "database" for the site. Here, we can use JSON files that can be looped over, or we can store the multilingual dictionary. In this case, I don't change the way Eleventy names its files, only their location.

/src/_layouts becomes the place where templates are stored. I've chosen to use Nunjucks, but you could use Liquid or another templating engine—it's a matter of personal preference. By default, Eleventy uses a folder named /_includes, but once again, I believe my organization makes more sense, and more importantly, everything is under the /src folder.

• /src/en
• /src/fr
• /src/en/about
• /src/fr/about
• /src/en/...
• /src/fr/...

/src/en, /src/fr and their subfolders are part of the main tree of the compiled site. It's in these folders that we'll put all the different sections of our site, each with their dedicated Markdown content. Since I'm creating a multilingual website, I've decided to use a subfolder per language, as recommended in the documentation. I'll explain in a future article how I can link the content between languages.

• /src/fonts

/src/fonts is where I store the fonts. I prefer serving them directly instead of relying on Google's CDN. This approach allows me to avoid an external HTTP call and, more importantly, Google's fingerprinting.

• /src/img

/src/img is the folder where all the site's images reside. A quick note while we're here: if you're not already doing so, I encourage you to use recent image formats such as AVIF or WEBP. These formats offer much better compression performance compared to JPG or PNG.

Compilation helpers

Deciding on a project structure is one thing, but we also need to inform Eleventy where to find what it's looking for. For that purpose, we have to configure the /.eleventy.js file, which is used during the build process.

// /.eleventy.js
module.exports = function (eleventyConfig) {
return {
	markdownTemplateEngine: 'njk',
	htmlTemplateEngine: 'njk',
	templateFormats: ['md', 'njk', 'html', '11ty.js'],
	dir: {
  	input: 'src',
  	output: 'dist',
  	layouts: '_layouts'
	}
  };
};

Here we specify that the templating engine we're using is Nunjucks, and the files 11ty has to consider as templates can bear the extention .md, .njk, .html or .11ty.js. These files will go through the Nunjuck engine so that their HTML (or other - specified in the front matter) counterparts are created. Finally, under the dir key, we specify the folders used for input, output, and layouts.

Thus, the project's root directory can contain all the configuration files (.eleventy.js, .gitignore, package.json, etc…), the source code resides in /src, and the generated website will go in /dist.

In a future article, I'll describe how I compile JavaScript/SASS assets, as well as a few tips I use to streamline the development process.

Everything was running smoothly, but I couldn't help but notice that my site was suffering from a Flash Of Unstyled Content, AKA a "FOUC". It was really noticeable even with the new JavaScript and CSS in place: once a link was clicked, the page would start rendering almost immediately and then the CSS would get applied. This was really annoying as it removes the user from this smooth, almost instant experience I was aiming at. Fortunately, there are a few things we can do to prevent this from happening and get rid of that pesky FOUC.

Step 1: Hide everything!

The first thing we want to do is simply to add a CSS instruction so that our body is hidden from the page until it is ready to be unveiled. This allows the page to be fully loaded before we can finally present it to the user. This might be counter-intuitive since we're aiming at speed, and, well, we're slowing things there, but it's a sacrifice we're making for the sake of the user's experience.

<body style="visibility: hidden;">
  <!-- Your awesome website -->
</body>

We could go with opacity instead, and make use of CSS transitions to add a bit of magic.

Step 2: Unveil when everything is ready

We then need to revert that visibility CSS property once the DOM has been loaded and is ready. For that, I'm using a simple helper function, a bit like jQuery's document.ready() method. It calls a callback method once the document is in a "complete" or "interactive" state.

So we simply change the visibility property of my <body> tag to visible.

// Helper function
let domReady = (cb) => {
  document.readyState === 'interactive' || document.readyState === 'complete'
    ? cb()
    : document.addEventListener('DOMContentLoaded', cb);
};

domReady(() => {
  // Display body when DOM is loaded
  document.body.style.visibility = 'visible';
});

And there you go! Our FOUC is gone. With this simple trick, our users get a better experience and don't have a weird mess blinking on their screen before being able to browse our site.

The Firefox hack

While things should run smoothly on Chrome, you might still see a flash on Firefox. I struggled to find a solution to this problem until I stumbled upon a bug in Firefox that's been reported 3 years ago and is still active. People are still trying to fix this but lucky for us there's a simple hack we can use as a workaround to this problem. Simply add a dummy piece of JavaScript code right after your <body> tag and you should be all set!

<body style="visibility: hidden;">
  <script>0</script>
</body>

Pretty neat, huh? Pretty weird also, I must confess. But hey, it does the job.

Note: Think of the noscript people

Don't forget that not everybody can or want to execute JavaScript. In that case, this simple line right before our closing </body> tag will help make our site seen by everybody.

<noscript><style>body { visibility: visible; }</style></noscript>

And we're all set! Now our site should be displayed correctly, without any FOUC. Yay! 🎉

Update - May 1, 2020

It has been reported that my code breaks W3C's code validator. That's because officially, the <style> tag cannot be a child of <noscript>.

To fix this problem, what we can do is remove this <noscript> tag, and add a no-js class on the body element. Then, we simply add this CSS rule in the <head> of the document:

<head>
  <style>
    .no-js {
      visibility: visible;
    }
  </style>

And finally revert this once again right after the <body> tag thanks to JavaScript:

<body style="visibility: hidden;" class="no-js">
    <script>
        document.querySelector('body').classList.remove('no-js');
    </script>

This will not only make this W3C compliant, but since we've added a bit of JavaScript in the body of our document, the dummy JS code we added earlier becomes obsolete! So now, everybody's happy, and we can finally grab a fresh glass of water and enjoy the sun.

Update 05/06/2021: Thanks to Moritz Profitlich for correcting a small typo in the source code of this article! 😄

The technique used if fairly simple: Instant.page calculates the time a user spends hovering a link (which is an obvious behavior when you want to click on something) and will start preloading said link if that time exceeds 65ms. Since the average human perceives actions taking less than 100ms as instantaneous, Instant.page tricks the brain, hence allowing your users to get a faster, better experience.

The installation is fairly simple, just insert the <script> tag containing the link to the script right before the closing </body> of your website (which is where all your scripts should reside anyways), and you're all set! Instant.page will glue itself automatically to each link on the page. The library is small, a mere 1kB. It's free and open source (MIT).

Instant.page allows you to control what content should be preloaded or not. You might want to prevent it from preloading some anchors, like logout links for instance. To do that, simply add a data-no-instant attribute to said links and Instant.page will ignore them. You can even specify that you want to allow preloading for external links.

Simple, light and easy. If you want to try it yourself, check out Instant.page here: https://instant.page

I had to custom-build a slideshow with full-screen images for the home page. The whole thing is managed thanks to Advanced Custom Fields, so that the client can change every aspect of the slides: the background image, the main text, the gradient color and direction, and so on.

For the grid on the projects page, I used Shuffle.js, a responsive grid that one can categorize, sort and filter.

The main issue we encountered was the weight of the site. It makes great use of full-screen images, and since they represent architectural projects, we had to have a good picture quality. I ended up using the on-the-fly API service of reSmush.it, which compresses the images when an admin uploads an image in the media library.

For this project, we used Wordpress, SCSS, Shufflejs, jQuery and Webpack.

Head over to https://sbbt-architecture.com to see the result!

It's been a pleasure working with Thomas and Pierre-Mathieu for this first project. They have a clear image of what the end product should look like, and they are complementary in their ideas and approach. They've trusted me to make their design ideas a reality while listening to the advice I could give them about UX or Responsive Design ideas.

For this project, we used Wordpress, Bulma and Webpack.

Head over to https://nysb.paris to see what we came up with!

That being said, the update and deployment of a static website has to be made from a machine equipped with the suitable development environment. A terminal, and tools such as Git, Node, NPM, Ruby and others are often necessary. Indeed, the website has to be compiled beforehand or thanks to an automated process such as GitHub Pages or Netlify.

On the need for a static CMS

The need for a static CMS therefore makes sense for multiple reasons. First it allows to overcome the need for a development environment. In the case of a blog, the creation of articles becomes much more fluid, and being able to get away from this technical environment allows for a better workflow for the content creation process. Secondly, it allows non-technical users to manage their website and let them be more free in creating and managing editorial content.

Today I’m trying out Forestry, a hosted service which makes use of the GitHub API in order to allow a static website to be remotely managed.

Installation

The installation of the CMS is extremely simple: I just had to create an account on Forestry, link it with my GitHub account and select the repository for the website in question. I then had to specify if the website is generated by Hugo (which is my case) or Jekyll. Quick note: I had to specify the version of Hugo I’m using, and the ones given by Forestry will not necessarily correspond to yours. It wasn’t a problem for me as I’ve configured Forestry not to generate my website, but it’s something to consider.

Configuration

Forestry’s configuration is just as simple. Its system will browse through your repository and generate content types depending on what it finds. All in all, it took me five minutes to have a working back-office and I was able to be productive right away.

It’s even possible to inject the CMS inside your own site and go through a URL you specify (for instance www.example.com/admin), which allows you not to leave your own website.

Usage

Forestry works by using GitHub, Gitlab or Bitbucket’s API. It’s a fairly simple CMS to use with a clean interface. On the left, a panel listing all the content types allows access for the different categories of the site, and on the right a Wordpress-like panel displays to the Front Matter fields and the main text editor.

In my case, Forestry did an incredible job finding all my blog posts and projects, but was a bit limited when it comes to pages content. Thus, for an unknown reason, the system thought my home page and the “About” page were different, and it put them in two different sections.

I was surprised to see that even though Forestry uses GitHub’s API, it’s not possible yet to access a content history.

It’s however possible to rename the file (automatically generated by the CMS) in order to benefit from Hugo’s multilingual support. Thus, by only adding the extension .fr to an existing slug, I was able to let Hugo automatically link two blog posts and suggest the translated version to the visitors.

In my case, a “project” is exclusively configured thanks to the Front Matter. By changing a couple of lines from the config file, I was able to get rid of the text editor and simply have the configuration fields for a project. For Wordpress users, it’s equivalent to having a page constructed thanks to the Advanced Custom Fields plugin, but generated thanks to a YAML file.

Pros and cons of the CMS

The first obvious con of using this type of CMS is the “technical” aspect that remains very strong even in the presence of a graphical interface. Knowing how to name files is a must in order to allow Hugo to handle them, and some aspects of the interface might scare some users.

It would have been smart to allow for a hidden, automatic way of naming content files, thanks to a slug system inside the configuration file, and change the language thanks to a select input.

Adding “users” with restricted permissions is reserved to the “Business” plan which starts at $9 per user per month. In its free version, it’s possible to add “guests” who have almost all rights on the site, which can become pretty problematic.

For instance, you should note that when it comes to Hugo sites, Forestry enforces the TOML format for the Front Matter and config files. In my case, Forestry detected “menus” for my projects, which are not used anywhere. In trying to test this feature and changing the order of this menu, Forestry decided to rewrite 47 files, including Hugo’s config (writing TOML syntax inside a YAML file), which completely broke my build system. I had to use Git to undo these modifications and come back to a previous working version.

On another side note, it is to be considered that Forestry lives in Git, and therefore is going to generate a multitude of commits, that won't certainly respect your commit convention. It's small point, but it's something to think about.

Wrapping up

After writing all this, one might seem that I did not enjoy my time with Forestry, but it's far from the truth. While it has some flaws, the team behind it is constantly working on improving it. That being said, and when considering how easy it is to install and use this system, I'd say it’s a really solid choice as a static CMS. It allows to find a certain flexibility when administrating a website while still benefit from the advantages of speed, security and optimizations of a static website generator.

So it's been my editor of choice, but a good editor would be nothing without good extensions. I've compiled a list of my 10 favorites (plus a few more) extensions I could not live without. They make my day to day work much easier and allow me to save so much time in the long run. Here they are (in no special order):

Color Info

VS Code provides a tiny preview box for colors in CSS files. Color Info allows you to get a much better view of the color your mouse hovers, complete with CMYK or alpha values. It can even act as a color picker, which is really convenient.

Color Info

:emojisense:

You know I love emojis. This extension allows you to directly insert emojis or type emoji codes in your files. Say you wish to insert a joystick emoji. Just begin to type :joy for instance and you'll get an auto complete window pop up which will allow to directly insert the 🕹 icon. If you type in ::joy, it'll insert :joystick: along with a preview of the emoji. It's great!

Git Blame

As its name states, this simple extension shows the git blame of the current selected line in the status bar.

Git Blame

Markdown All In One

I absolutely love Markdown. Actually this whole site makes extensive use of markdown, as it is built with Hugo. This extension helps you write Markdown by adding shortcuts such as Cmd + B for bold text, Cmd + I for italics, and so on. So convenient!

Settings Sync

If you're like me and work on multiple (sometimes virtual) machines, this extension is wonderful! It allows you to sync your settings and extensions thanks to a Github Gist that gets downloaded/uploaded.

TODO Highlight

As the name states, it highlights TODOs, FIXMEs and any keyword you specify. Just write TODO: somewhere and not only will it highlight it, but it'll also list all the ones you've already written anywhere in your project.

Todo Highlight

Vetur

This extension is a swiss knife for Vue. From autocompletion to snippets, it's a must-have for any frontend developer.

Spell Right

A multilingual, offline and "lightweight" spellchecker. Spell Right uses your built-in dictionaries to check for errors, and can check for errors in any (and even multiple) language anywhere within your project. Watch out for big files though, as it can sometimes take some time to operate. I usually have it toggled off by default. It's easy to ask it for a spell check just by clicking on the eye icon in your status bar.

EditorConfig for VS Code

Strangely enough, VS Code does not support EditorConfig by default. Just install this extension and it'll instantly start listening to any .editorconfig file it encounters.

Bookmarks

Now this one I use it constantly! Bookmarks is an extension that puts little blue bookmarks in your file gutter. It's extremely handy when you need to switch between positions inside a file, or if you need a quick reminder anywhere in your project. I've set up mine with shift + cmd + = (toggle bookmark) and shift + cmd + - (next bookmark) and thanks to this I can jump around files without having to leave my keyboard. The extension also adds a small panel right below your file browser which lists all active bookmarks in the current project. A must-have.

Bookmarks

Honorable mentions

AutoFileName

This extension is pretty straightforward. Just type in the beginning of a file/directory and it'll autocomplete its name for you. Really handy when you need to point to a file inside node_modules.

cdnjs

Most of the time I inject my dependencies in my Javascript files thanks to Webpack. But whenever I need to mockup something quickly, this extension has my back. Using the command palette, you'll be able to insert URLs or script/style tags of all the libraries cdnjs handles. Quite handy.

cdnjs

Got one to share?

So here are a few extensions I use every day. If you've got one I should check out, hit the comment section or send me a tweet!

Contrary to what people may think, emojis have been around for quite some time. The first emoji dates back to 1999, and was created by Shigetaka Kurita, a Japanese telecommunication planner for NTT Docomo. At first used solely in Japan, it took those little pictures ten years for some of them to be added to the Unicode character space. Thus, in October 2010 the Unicode Standard 6.0 got released, and with it 722 emojis. They do not live in their own dedicated blocks though and are spread around the Unicode tables. It took years for multiple engineers working at Google and Apple to convince the Unicode Technical Committee to add them. Now emojis are a part of everybody's life.

There are even some quirks and fun little facts about these tiny pictures. For example: emojis can vary from one platform to another. Because of that, the calendar emoji is represented always showing July 17 on Apple products (that date representing the announcement of iCal back in 2002). This led people to "wrongfully" declare July 17 World Emoji Day.

Emojis are also represented differently across platforms, and can be interpreted slighly differently. Take for instance the astonished face emoji. The first one is Apple's interpretation, the second one is Samsung's.

Apple's take on this feeling feels a bit more tamed than Samsung's, don't you think?

Other times, it can be the contrary. In this example, Samsung's interpretation of the pouting face feels less "angry" than Twitter's.

But enough with the history, let's get down to coding.

Emojis in git commit messages

Github has popularized emoji support inside their ecosystem in a blog post from 2012 thanks to their now famous ":" shortcut. So now, say you want to use the fox face emoji 🦊 somewhere in Github (a commit message, an issue or a gist), you can simply use :fox_face: instead and it will automatically be interpreted by Github.

Using shortcuts is an elegant solution to circumvent emojis not being interpreted. You don't take the risk of breaking something and even if they're not (or badly) rendered, the messages are still readable.

Emojis can also add a lot of clarity to commit messages. Compare these two sequences:

- Fix editing user not being saved to the database
- Cleanup code
- Add the ability to edit a user
- Fix bad function callback on API request

- 🐛 Fix editing user not being saved to the database
- 📝 Cleanup code
- ✨ Add the ability to edit a user
- 🐛 Fix bad function callback on API request

You can immediately see where bugs were fixed and where new features were added.

On a platform that doesn't support emojis, this would be read as:

- :bug: Fix editing user not being saved to the database
- :memo: Cleanup code
- :sparkles: Add the ability to edit a user
- :bug: Fix bad function callback on API request

Definitely not as fun, but still perfectly readable.

The tech industry as a whole appropriated these shortcuts and went far beyond simple emojis. Sure it's nice to use 🐛 to talk about fixing a bug, but try using :trollface: in Slack or Redmine. Boom, you're the new cool kid on the block. Don't use it too often though, you don't want to be that guy.

My advice: Don't hesitate to use emojis in git commits, but do prefer short-codes. I would also suggest not to go overboard with it and stick to a list of a few ones to denote the major actions (bugfix, new feature, styling, code cleanup, etc..).

If you're not sure were to start or want to suggest a guideline for your team, I highly recommend Carlos Cuesta's Gitmoji. It even comes with a nifty CLI (simply called gitmoji-cli) which will help you write your commit messages through an interactive interface. Gitmoji is even used in Atom's contribution guideline.

Emojis in/as code

Technically, you could use emojis in computer code, but you should be very careful when doing so. Emojis are interpreted as strings in Javascript, but their length can vary.

"🐼".length         // returns 2
"🇨🇦".length         // returns 4

Don't forget emojis can be connected (kind of the same way Fira Code gets you those sexy sexy ligatures). That's how you can now get skin color modifiers (called EMOJI MODIFIER FITZPATRICK TYPE-1, -2, -3, -4, -5, and -6. I'm not kidding). Or even better, if you combine the following emojis: 👨, 👩, and 👧, you get a whole family 👨‍👩‍👧! Let's run that through Javascript.

"👨‍👩‍👧".length         // returns 5

Why 5? Because not only do you get the length of each emoji that symbol is made of, but it also uses two ZWJ (Zero Width Joiner) characters as "glue". You can even see it in action: copy/paste that emoji inside VS Code for instance, and it'll take you five "arrow key" strokes to go through it.

My advice: Do not to use emoji in code logic. Plain and simple. But you can still use them in your views. Web browsers have amazing emoji display capabilities, and know how to fallback to a font that will display your "thump up" icon. But watch out and be careful when using an emoji short-code interpreter in those views, especially if you happen to display code blocks on your website. It could trick you, interpreting h:m:s as hⓂ️️s, thus making the code block useless.

Emojis in code comments

So what about code comments? Emojis everywhere! As far as I know, you are not susceptible to break anything because of emojis in comments. Modern code editors (Atom, VS Code, Sublime, Intellij...) have amazing emoji support. They even can be pretty useful to make something stand out.

/**
 * WARNING: Do NOT change this file.
 */

Compared with:

/*
 * 🛑 WARNING: Do NOT change this file.
 */

Final thoughts

Emojis are a double edged sword. They allow us to express complicated feelings in a quick and fun way. They are the extension of the emoticons we used profusely back in the IRC glory days. They can be used as decorators, adding feeling to an otherwise plain sentence. They also can be used as markers to make something stand out, and even as a complete communication tool when used on their own.

However, since they're not designed and interpreted uniformally across platforms, they can be the source of misunderstandings. Communication relies on the stability of its mean of propagation. If a symbol is changed between the sender and the receiver, the message is not the same. As characters, they also need to be put in context. That's why some of them had to be changed. For instance the :gun: emoji 🔫 which used to be represented by a real gun, is now a water pistol.

When it comes to code though, I'm all in favor of using emojis. Not in the code itself, as I've stated, but rather in comments and commit messages. They embelish the message they're attached to, for they are generally mainly used as pointers. And with the help of short-codes, you can use them without the fear of breaking something.

If you want to know more about emojis, you should check out Monica Dinculescu's work, and especially her talks.

I also recommend Angela Guzman's post on the making of Apple's emoji. Angela writes how she and her mentor Raymond designed over 500 emojis during her internship back in 2008. This changed her life, and her work is now in the hands of millions of people.

So go ahead and emoji away, you'll improve readability and break away from the monotony of a dull screen filled with code. 😄

A catastrophic failure

Back in 2008, I made myself a custom NAS (Network Attached Storage) using some old computer parts, a bunch of 500 GB hard drives and a copy of FreeNAS. The OS ran off a nifty 512 MB IDE flash based drive, and the data array was configured to use RAID5. That meant that if a drive was to be damaged, I could always put a new drive in the array and the data would rebuild itself. Note the conditional tense. That's because it worked flawlessly until we moved in 2010. And we stored the NAS in a box next to a speaker with a huge magnet for a month. And two drives failed.

I spent weeks trying to figure out a solution on how to rebuild the data I had lost. But after some time I had to face the reality of things. It was in vain. Years of family photos and videos, an entire MP3 collection, all my video games... It was all lost, forever. My girlfriend was in tears and my "geek pride" after spending all that time planning and building this whole system took a serious hit. I was using hot data as a storage, and at the time I had no backup strategy. Of course I had recovery options, hence the RAID5, but I was not prepared for such a catastrophic failure. And when it comes to computer security, you have to prepare for the worse.

Years later, I learned my lesson. So here is how I handle my digital life now.

My current setup

My current setup is mainly built around two things: a new NAS, that I bought and not built, and a backup software that automates how data is handled.

The NAS I'm using now is a Synology DiskStation DS214se. It's a very simple machine, running on a 800 MHz dual core CPU, with 256 MB of RAM and two hard drive bays. I put in there two 2 TB Western Digital Green hard drives, and configured a single array to be run in RAID1: everything that's on one drive gets mirrored to the second one. That means that I lose half of the hypothetical storage space but if one drive fails, I can change it and the data will automatically rebuild itself.

The NAS sits on top of an APC Uninterrupted Power Supply. If power is lost in my apartment, the NAS keeps running and I can manually (and safely) shut it down either by using its physical power button (which sends a power off command) or even my phone (my router is also plugged in to the UPS, so even without power I still have internet and network access for a few minutes).

My main backup strategy is handled by an amazing software called SyncBack Free. This software allows me to set up various backup scenarios, called profiles. The main profile is a physical backup to an external hard drive. When I bought the Synology NAS, I got a third 2 TB drive that is now used as a backup. This is my first failsafe. This is what lacked in my previous setup. Once the backup task is done, that drive is stored offline and off-site, so it doesn't have to suffer from electrical malfunctions. And even in the event of a fire or flood at my place, my data is safe.

SyncBack then runs two more jobs. Amongst all the data I've lost with that old setup, the loss of family photos were the hardest to cope with. One can always replace music or movies they used to love, as there's a never-ending stream of entertainment to consume. But memories do fade away, and are impossible to retrieve. So I've decided to add another redundancy layer to my backup strategy when it comes to photos and store them online, in my Google Drive. SyncBack compares the content of the NAS folder and my Google Drive, and updates the later with the former before performing a Cyclic Redundancy Check of each file to see if they are the same on both sides.

I should note that I could use two different apps on the NAS and have it handle these two backups automatically: USB Copy and Hyper Backup. After trying out both apps in different scenarios, I've decided not to use them as they either store data in a proprietary format (Hyper Backup) or add a bunch of ._ prepended metadata files to my existing directories (USB Copy). I like the fact that if I ever need to retrieve my files outside of Synology's ecosystem, I still can use a good old cp command to get my files back.

But wait, there's more!

So my data is stored on a RAID1 array, and on an offline hard drive. And the photos are backed up online on my Google Drive. I could have stopped there but I thought that it was not enough. Thanks to my Amazon Prime subscription, I can upload an infinity number of photos on their Amazon Drive cloud service and it won't affect my otherwise limited quota. So hey, let's take this opportunity! Another SyncBack profile backs up the content of my Photos directory to Amazon's servers. I like the fact that my data is stored on two different storage providers. Google and Amazon each have their own infrastructure, so in the event of a failure of astronomical proportions at either one of these places, I may still be safe.

But why stop there? My photos are stored on four different locations now (The NAS, the external hard drive, Google Drive and Amazon Drive). But what about the rest? My music, my documents, my family videos? Well of course they're on the NAS and the external hard drive, but I figured I needed another failsafe. Because so far my backup strategy relies on what could constitute a single point of failure: SyncBack. If the software behaves badly or one of my backup profile is not properly configured, I may end up with nothing but a bad save on various locations. I also don't have access to the external hard drive that easily, so if I need to do a backup at any given time, I need to prepare the operation at least a day in advance.

That's why I took a subscription to Synology C2. It is a fully integrated service that runs natively on DSM (DiskStation Manager: Synology's own operating system) and allows me to back up the whole NAS (minus my movies and TV shows, these are not important) to Synology's servers. It uses AES-256 to locally encrypt the data before sending it on the network. I've set it up so it does an automated backup every first day of the week, and then do an integrity check two days later.

I also considered Online's C14, as they're really cheap and you can send files over (S)FTP but unfortunately they do not support Synology.

Room for improvement

So this is what my current setup looks like now:

My current setup

Each file is physically stored on up to 6 different location, with various levels of failsafe measures.

Is this setup perfect? Of course not. First and foremost, it lacks automation. I still have to start each backup task (except for the C2 one) manually, and it is prone to error. I'm working with live data so the array is constantly changing, but this is a backup, not a long term cold storage. And the external hard drive I'm using has to be transported and manipulated, so that's another weak point in the system.

One thing I'll probably change soon is the model of the hard drives I'm using. WD Green are "fine" but they are not made for being used in a NAS. So I think I'll switch them for either WD Red or Seagate Ironwolf line, and probably take the opportunity to do a slight storage upgrade to 3 or 4 TB.

All in all, the main problem with backup strategies is that they're never perfect. Just look at what happened at GitLab a few months ago, or even the catastrophic failure that brought OVH to its knees for hours.

One cannot be fully prepared against data loss. Still, I can say that I feel confident with this strategy, and I've tried to think about every scenario (even solar flares, but they're a whole another animal). We'll see how and where my data sits in a few years.

For the past four years or so, my password manager of choice has been LastPass. I've been a happy Premium member ever since, and even though it's had a few hiccups (in 2015 and in 2017), they've been pretty transparent about the situation each time and I chose to keep trusting them. I used to log into my account using two-factor authentication: my Master Password and a Yubikey, and it's been working flawlessly for years. However, after a long consideration, I've recently chosen to say goodbye to LastPass and continue my journey with another solution. Here's why.

A WW1 tank painted pink stays a WW1 tank

You see, the problem with computer security is that you always have to find the proper balance between how safe you need to be and the convenience of day to day usage. My setup was somewhat secure, but the convenience wasn't there anymore. I usually have to log into my LastPass account several times a day, as I'm using several web browsers, with sometimes several profiles per browser. Therefor, since LastPass automatically logs out whenever a new session is opened somewhere else, I also had to use my Yubikey multiple times per day, even per hour. In the end it was starting to become a burden. Besides LastPass has made some changes to its UI, and is focusing more and more on being as easy to use as possible, and in a way as "opaque" as possible. While I'm all for it, as it draws more and more people to being safer on the web, it can result in really annoying results under the hood. Often, the browser extension does not catch the proper fields for the username/password combo. Or when I'd use the password generator, it didn't necessarily register it properly. It has some difficulties dealing with websites which make use of AJAX requests. It often saves uselessly complicated URLs that are generated during the signup process, making a lot of its database entries dirty. If you're not tech savvy, it's still an amazing product, and it's way better than using nothing or that old post-it note that's on your computer screen. But for me, what was once a really good tool to use had become a burden. It was time for something new, or in this case something old.

Enters KeePassXC

KeePass Password Safe has been around for 13 years. The interface shows its age, but its ease of use and the security features it offers has been proven multiple times. Besides the usual username/password combo, you can specify custom fields, and even attach files to your password database. Speaking of which, KeePass uses AES, TwoFish or ChaCha20 as cipher for the database, and the passwords it contains are protected in memory. It does pretty much everything LastPass does (or the other way around depending on your point of view), albeit with a less fancy UI and a less "automated" process.

The particular flavor of KeePass I'm using is called KeePassXC. It's a community-driven fork of the now defunct KeePassX, which was aimed at being a multi-platform version of KeePass. So it works perfectly on Windows, MacOS and Linux. Exporting the database from LastPass and importing it into KeePassXC demands a bit of work, as you have to use a cumbersome CSV file (which you must not forget to destroy!) LastPass export tool provides you with. LastPass' "Secure Notes" are stored in an XML-like format, and you'll probably have to rewrite them manually inside KeePassXC after the import. But after that tedious task is done, using KeePassXC is really easy, and it works flawlessly. Whenever you need to retreive a password, simply switch to the app and hit Cmd+F, type in the first letters of the entry you're looking for and a simple Cmd+C / Cmd+V does the trick. It litterally uses less than five seconds. If you're using a browser extension, it can even automatically fetch your credentials and is therefor as fast as LastPass, if not faster.

The setup I'm using now is as follows. The password database file is stored on my Google Drive. This allows me to have a silent synchronization between my different devices, and provide me with an online backup. I'm using both my Master Password (with a 100+ bits entropy) and a key file (which is stored locally, not on Google Drive) to unlock the database. It can communicate automatically with my various browsers thanks to two extensions: chromeIPass and PassIFox. The database file and the key file are backed up on a Network Attached Storage drive, and two offline copies.

Is everything right?

So I'm finally happy again. The main "problem" I have with KeePassXC is its UI. In these days of Flat UI and Material Design guidelines, the software feels really dated. It also lacks some basic features such as showing which fields can be displayed in the entries columns, and my biggest gripe: custom fields do not show straight away when you search for a specific entry. Let's say for instance you create an entry for a credit card. It contains several custom fields such as the card number, its expiration date and the CCV. KeePassXC won't show those fields unless you go and edit the entry to display the custom fields, or you right click and select one of the "copy attributes" options. It would have been much better if each entry could be displayed in its entirety on a single pane, minus the protected fields of course.

I should give an honorable mention to KeeWeb, a web app (available as an Electron desktop app as well), which tries to rejuvenate KeePass in that regard. But it poses even more security problems than KeePass does. I won't go into too much details in this post, but the flaws are easy to guess.

All in all, I feel much better using KeePassXC than I was using LastPass. Of course, this solution is not the most secure there is, especially by storing the database file on the cloud. I could fix this issue by using a self-hosted cloud service like OwnCloud or Bitorrent Sync. But once again, the balance between security and day to day usage would have been lost. I'd love for KeePassXC to support TOTP so that I could use again my Yubikey and get rid of the keyfile, but so far I feel confident in that solution.

By the way, what do you use to store your passwords?

When Apple came up with push notifications back in 2009, they were a godsent. No longer did we have the need to check our phone to see if a new email had arrived! Whenever something important happened, a subtle Ding! or a quick vibration alterted us of an incoming tweet or appointement. It was a great way for the user to stay in touch with their digital world.

The problem is that now, each and every app thinks it's the most important thing and you HAVE to listen to what they say. Congratulate Helen for her new job! Marc is tweeting about #takeaknee! Don't forget to check on your Happy Dragon's Eggs! Tom has posted for the first time in a while! It has become so dominant that now it feels like notifications are nothing but noise. So much so that people have started to develop new diseases such as Phantom Vibration Syndrome. How often do you think you get a new notification and reach for your phone, but it turns out that it was just your brain tricking you. There are even people who are experiencing anxiety related to notifications. The constant flow of information has become overwhelming, and it just won't stop. And now, you can also get push notifications from websites. While I love the technology behind it, it's unfortunately so badly used by web developers around the globe. Each and every website wants your authorization to notify you about the latest trend in whatever they're talking about. It's presented as a way to deliver a better service, but let's not kid ourselves: it exists for the solely purpose of making you come back there, and present you with just a few more ads.

Last year I bought myself a Pebble. It's a great little gadget that goes around my wrist and vibrates whenever I get a notification. Thanks to it, I can't miss a single email, phone call or text. It's also nice because it's discreet. It's been a year since my phone last chimed, and now that it's always on silent mode, it doesn't bother my coworkers when I'm in an open space, or my family during our sunday lunch. I've started to look less at my phone, because since it's connected to my watch thanks to Bluetooth, I won't miss a notification as long as the phone is less than 10 meters aways from me. But I've realized that it was at my own expense. The problem is that I started the bad habit of constantly having to look at my watch. Whenever my phone needs my attention, I get these three taps on my wrist that remind me it's there, and it needs me to take care of it. While fun at first, it started to feel like a dog collar, and that Bluetooth link started to feel more like a leash than a usefull tool.

So I've decided to turn it all off. The only notifications I've kept on my phone are Emails, and everything that's directly aimed at me (Telegram, Twitter DMs and SMS). That's it. LinkedIn is quiet, Instagram as well, and I'll check on my Amazon deliveries whenever I damn please. On my desktop, I've disabled all notifications as well. Now I take a glimpse at my Dock every once in a while, and whenever I see a Slack or Airmail badge, I'll see what it's about only if I have nothing more important to do. I often completly shut down email and open it right before lunch, or a moment before leaving the office. I won't interrupt a coding session just to see if my Aliexpress order has shipped or if someone has replied to a Github PR. And it feels wonderful.

Turning off notifications has been a great thing to do. I feel like I'm more in control over my digital life. I get less interrupted by all this noise, and in the end much less stressed about this constant flow of notifications. I feel happier, but not less "connected", I just chose to open an app because I feel like it, and not because an algorithm has decided it's a good time for me to do so. A recent article from Wired reports that in 2013, "Apple proudly announced [...] that 7.4 trillion push notifications had been pushed through its servers". Where is the limit between information and spam?

I hope this trend will develop and people start cutting off notifications more and more. Unfortunately, now that Apple has added SIM support for its Apple Watch, the "notification machine" has become independant, so people will get even more reminders to check on their phone. My advice is try it for a week, and see how much you miss having a device constantly buzzing in your pocket. I bet you'll feel much better, even after day 3.

18-55 is a video production company, based in Bordeaux. They work with various brands such as DC Shoes, Orange, or even Electronic Arts amongst many others. Their goal was to get a website that could put a focus on the content (their productions) and at the same time show that they also act as a platform for different type of professions revolving around their line of work. That's why they're surrounded by various artists, photographers, writers and videographers which allow them to quickly put up a team of talented people for the projects they're working on.

Their second desire was to get a back-office which would allow them to add/remove content quickly and easely. Wordpress was the obvious choice, and together we came up with a minimalistic design based on a grid of squares which allowed them to reorder the whole site as they please. They were immediately thrilled by this approach and after a few exchanges between their CEO, the Production Manager and myself we agreed on this design. All in all I'm really happy with what we came up with and so far the feedback after launch is rather positive.

Thanks a lot to 18-55 for their time and dedication to this project!

Another cool feature is its ability to track sleeping patterns. Thanks to its built-in gyroscope, it can detect wrist movements and deduce if I'm sleeping or not. Granted, it's not 100% bullet-proof, but it does a good job at giving a broad idea of how good (or bad) my sleeping habits are. And boy they are terrible.

According to my Pebble, I sleep 7 hours 3 minutes per night on a 30 days average, with an average deep sleep duration of 1h 48m. It's not that bad, but when you take into account that during a same week I can sleep from 3h 55m one day to 9h 18m another, there's clearly something really wrong with my sleep schedule.

My usual "worst" night is the one from sunday to monday, with an average of 5 hours of sleep. My "best" night is usually the one from saturday to sunday, with up to 11 hours (!) of sleep.

The average human needs between 7 and 8 hours of sleep for optimal functions, which means I have a sleep debt of about 30 minutes to an hour per day. That's a cumulated debt of about 4-5 hours per week. On the long run, such deprivation is the cause of stress, weight gain, fatigue, and even diabetes. If you need more info on the benefits of sleep, I highly suggest you read this article from Pillow Picker.

"But Fabien, all you need to do is go to sleep one hour earlier, that's all!"

Yeah, that's not taking into account the absolutely amazing capacity of the human brain to slack off.

Getting more sleep has been a goal of mine for 2017. I've already taken some steps towards this, removing my tablet from the nightstand and replacing it with a good book. But I still need to slap myself on the wrist and stop spending my evenings reading about code or cruising around Tamriel or Dust2.

I hope to write an addendum to this post soon, describing how my sleep habits have changed, if I ever manage to change them. In the mean time, I'm off to take a nap.

On Twitter, Gitlab posted the most amazing and devastating tweet a sysadmin could ever write in their career:

We accidentally deleted production data and might have to restore from backup.

To be honest, there couldn't be a more disastrous catastrophy for a company that's relying on data as much as they do. Me and the team I'm currently working with have been using Gitlab for a few months now, and already had to suffer from their constant downtime. At one point, Gitlab.com could be offline three to five times a day. We were glad to hear that they were looking to leave the cloud, only to learn that finally, they'd be looking to expand in the cloud after all.

As Hacker News user connorshea pointed out:

it's never the fault of a person, always of a system

This could be applied to what happened at Gitlab. It feels amazing that for such critical tasks (you don't delete a whole database directory every day), they don't rely to the most simple and effective management system: checklists. It is used around the globe whenever a system is at risk. Airline pilots, surgeons and nurses, army crew, they all have checklists. It is the safenet against repetitive and menial tasks. That's why you'll see airline pilots talking through everything they're doing during an emergency procedure, with their co-pilot enforcing what they're about to do. It usually goes like this:

– "I'm about to turn off A/C.

– Green for turning off A/C.

– A/C is turned off.

– Confirmed. A/C is turned off".

This is greatly exagerated as I haven't flown a plane in.. well ever. But you get my point. Each and every step is monitored and confirmed by a fellow crewman. If you want to know more you can read this Wikipedia article about crew resource management.

Gitlab has taken the stance of total transparency, going as far as live-broadcasting their backup process. Many praise them for taking such a stance, but they hardly couldn't take another one, as there was a slight possibility of irrecuperable failure.

At the end of the day, the real question is not really "who's to blame?" but rather "what's to blame?". Poor practices, lack of preparation and a frustrated and tired engineer make for a bad combo. I'm sure Gitlab will grow from its mistakes. I'm not so sure they've handled the situation perfectly and are not losing clients by the minute, but hey, we can't blame them from trying not to go under.

In rememberance for this day, @CyberShambles has dedicated February 1st as Check Your Backup Day. Good one.

Source: https://www.theregister.co.uk/2017/02/01/gitlab_data_loss/

It's funny to see that despite the fact that there is no clear convention regarding this topic, it is a question that gets asked pretty often, and it is the source of big debates in the DB world.

Using plural names

Narayana "Vyas" Kondreddi (long-time DBA and SQL Engineer) wrote back in 2001:

Tables represent the instances of an entity. For example, you store all your customer information in a table. Here, 'customer' is an entity and all the rows in the customers table represent the instances of the entity 'customer'. So, why not name your table using the entity it represents, 'Customer'. Since the table is storing 'multiple instances' of customers, make your table name a plural word.

It feels logical, and somewhat "natural". You store several customers inside a table (those "multiple instances"), so the table should naturally be named customers. It also makes sense when writing an SQL statement. When you want to go through all your customers, you SELECT * FROM customers...

When using plural name, one can consider a table like a crate containing several items. A crate of apples should be labelled Apples, whether it contains one or a hundred apples.

Using singular names

The people that advocate the usage of singular names often cite the fact that when pointing at a database record, it feels confusing to use a plural name to describe a single item. Thus, why should you use clients.name when you're pointing only at one client?

This is enhanced when writing SQL statements, that suddenly appear more natural. For exemple, SELECT activity.name feels better than SELECT activities.name

It also avoids confusion of english pluralization which can sometimes be tricky for non-fluent writers. e.g. activity becomes activities while person becoms people and data remains data...

When using singular names, one can consider using the "set theory" to tables, meaning that any instance in the set is representative of the set, so apple is an Apple set. It is agnostic of how many apples are in the set.

What should you use?

I personally do believe that a database table is the representation of a collection of items. As such, it should be named using a plural word, since it stores several copies of an entity. Thus, each user is stored inside the users table.

The only thing that could have made me consider using singular names is the SQL statement point, as it feels less natural to use a plural name for a query on a single item. If you're bugged out by that point you can still use this simple trick to circonvert that issue:

SELECT id, name, description FROM products product WHERE product.name = 'foo' AND product.description = 'bar'

It's even more practical when dealing with more complex pluralization:

SELECT id, name, description FROM activities activity WHERE activity.name = 'foo' AND activity.description = 'bar'

If you're really concerned about writing good looking code that feels like proper english, my advice is to use plural names for tables, but single names for the corresponding entities. As such, for e.g. in Symfony you'd declare an entity Activity as such:

/**
 * @Activity
 *
 * @ORM\Table(name="activities")
 */
class Activity
{
...
}

The table activities stores all instances of the possible object Activity. Thus, when invocating and working with that object it makes sense to use the syntax $activity = new Activity() and $activity->setName("foo").

In short

If I had to give you one piece of advice though, it would be to this: be consistent. Stick to whatever convention you've decided, and apply it throughout your project. Use what feels the most natural to you and your team. Having the ability to rely on convention is often a good thing, but there are times when a convention is not needed. What's the most important is to make a clear choice and adopt it. Of course, it's also important to keep an open ear to the arguments people could provide that'd make you divert from that choice.

If you're still looking for some guidance, here are some other tips you might want to use when naming database tables:

• Use short names for your tables
• Use underscore to separate words (no spaces or camelCase), for e.g. product_dimensions
• Be somewhat descriptive: a table name should represent its content. It's easier to read client_bills rather than clb
• Use unique names that cannot collude with SQL/RDBMS reserved words (avoid name, order, percent...)
• Do not use the table name followd by "id" (e.g. client_id) as your PK. id is more than enough and everyone will understand
• Use id and not ID
• Actually, never use capital letters in your table or field names. Ever.

Sources:

• http://stackoverflow.com/questions/338156/table-naming-dilemma-singular-vs-plural-names
• http://stackoverflow.com/questions/7899200/is-there-a-naming-convention-for-mysql
• http://vyaskn.tripod.com/object_naming.htm#Tables
• https://justinsomnia.org/2003/04/essential-database-naming-conventions-and-style/

This is a huge deal, as it will enforce pretty much everyone to switch to HTTPS. The goal of Google has always been to provide a better and more secure web for the users. I believe that it's a good thing that such a giant is taking steps to enforce such measures. But the most important thing is not to train web developers to serve secure pages, but rather train users not to trust non-secure websites. This is why Chrome will gradually enhance the "Not Secure" notification, so that it appears with a red triangle, like the "broken HTTPS".

HTTPS is getting cheaper and cheaper, and with things like Let's Encrypt, there is soon going to be less and less excuse to serve non-secure websites. Which leads me to think I also should add a certificate to my own site.

Source: Google Blog

I'm still considering whether I should cross-post the articles I'll be writing here on Medium or not. All the cool kids are using this tool, maybe I should too. I've written a piece there, which has had quiet a good feedback, so I might post more about my thoughts regarding the "mind" behind web development (and web developers).

This first post of 2017 could be a great way to wish everyone a happy new year! Let's hope that this year will be as awesome as possible for everyone. It's been pretty good so far for me, and I can't wait to see what's coming in the following months.

Since last month I've been learning Symfony. I have to admit that I had some presumptions towards this framework, not really knowing why. I had heard it was hard to learn, badly written and all in all confusing. I am really surprised to see that it is in fact really well put together and pretty easy to learn (to some extent of course). I can't wait to put what I've been learning to practice and really start working with it.

I've also been looking at vue.js with a real interest. It looks so slick and powerful! I already have an idea of a cool app I could put together that'd make use of both technologies. But hey, the E-League Major has started yesterday, so no time for that yet. :)

Anyways, onwards to 2017 and let's hope I'll get some time to fill these columns sooner than later!

Healthy Warriors is a yoga center and café in Paris, regrouping several yoga teachers from around the globe. It has been created by Aria Crescendo and Gus Forristal, and features guest teachers and seminars throughout the year.

The website in itself is fairly simple, and is supported by Wordpress. A few custom post types and custom pages had to be made in order to give the client the freedom to customize the articles available in the shop as well as dishes and drinks served at the bar.

Thanks again to Ligne 13 for this project!

It was a really interesting project, as the technical challenge was pretty special. For this site, I had to make use of Masonry, while allowing the website to be able to manage several picture sizes and orientations, have a parallax effect, and be responsive. The task was not the simplest, but I’m happy with the result.

The whole thing is backed by Wordpress. The client had a precise idea of the kind of experience he wanted for his users, and I find the end result very interesting. The use of white space gives all its importance to what matters: the pictures. A custom made lightbox was added, which allows people to select photos and save for later.

Thanks a lot to Ligne 13 for this project !

The home page was designed internally by the agency, and the client was confident enough to trust me for the layout of the rest of the site, as well as the UX approach for the responsive design.

The base has been done using Wordpress, and several Custom Posts had to be made for the website not only offers students a place where they can gather informations regarding the various majors the school offers, but it’s also a place for employers and graduates to exchange.

Thanks to ComTogether for this project.

One might think that these pre-requisites lie in the “functional” aspect of the human mind. Being good at math might be a good one for starters. That means that you are able to work with rules, and apply them. Speaking english fluently might be another one. It helps reading documentation or comments, understand tutorials… And of course, being a “techie” is a must, even though most of the time this trait does not serve you the way you might think it should. How often do you hear “So you’re a web guy? Hey could you help me with my printer?”

These of course can help. But I believe the main things that make a good developer lies more in the most inner workings of someone. And these could be summed-up by three traits that beautifully work together.

One of these pre-requisites for me is the love for well-made craftsmanship. Being a developer is much like being a woodworker (another of my interests). Your code editor is you hammer. I guess this is why you so often hear developers call themselves “artisans”. Behind this new cliché lies of course a trendy trademark, but I believe in the deeper meaning of the word: that is someone who loves his work, and has the passion for beautiful and well-made artifacts. Or in this case, code. You constantly need to know how to use your tools, how to master techniques, and how to acquire new ones.

This need to learn and apply techniques often leads to another quality: being creative. You may not know how to do something, but your mind can always find a way. Wether by exploring unknown paths, or finding a hidden one, there’s always more than one answer to a problem. Being creative helps you find solutions, and is often fuelled by the third quality that I believe is essential to any web developer: curiosity.

It is thanks to curiosity that, as a child, everyone learns the basics things of life. What’s good, what’s bad. What hurts, what brings joy. Curiosity leads us to meeting new people, confront ideas, and exchange opinions. It is the cornerstone of social interaction, and the best way to develop your mind. It is important to constantly have an open ear, not only to critiques but also to new things that might grasp your interest.

If it’s your passion, you’ll have the tendency to overlook some of these so-called qualities, as they’re simply inner parts of the way you are. If, however, you’re the shy kind of person, my advice to you would be to try to interact more. Only good things can come out of a simple “hello”. You might encounter some obtuse minds or course, but there’s always something to keep from each and every human being you’ll talk with. What’s even more interesting, is that I believe these three angular points are connected. They depend on each other, forming some kind of a chained loop. They come in a certain order, yet you definitely can feel that they influence each other, and are interconnected.

At the end of the day, these traits combined create an interesting and beautiful flow. Curiosity is the spark that triggers Creativity which sublimes itself thanks to good Craftsmanship. It is thanks to these three pillars of the human mind that you’ll be able to enhance and sharpen your skills, and in the end produce more beautiful and efficient code.

With this new website, I’m saying goodbye to Jekyll, and hello Wordpress. I’ve always been a fan of Jekyll, and I still use it today for some of my projects. But lately I’ve been toying around with Wordpress and it’s come a long way over the past few years. It’s now a nice ecosystem to work with, and it will allow me to update this blog faster than before. Fortunately this also means I’ll get to spend more time writing about my projects and how I work.

Unfortunately, most of my work comes with an NDA which prevents me from publicly disclose the projects I’m working on. However, thanks to the folks at quasardb, I was able to put together a simple “case study” which describes how I put together an app which is used almost everyday in the company. It’s always nice to work with passionate people on an interesting project, and while this particular one was not the biggest I’ve worked on, it was a really rewarding experience.

Oh, and if you’re wondering, yes I’m available to work on your project, so be sure to give me a call or drop me an email so we can discuss about it!

One very simple way to do this is to use the HashCheck Shell Extension, which will add a tab inside the "Properties" window of any file. It will automatically calculate the checksum of the selected file, and if you happen to have an MD5 or SHA1 value stored in your clipboard, it will automatically compare that value against the calculated checksum of the file you're looking at and tell you if that file's hash is correct. HashCheck is also capable of generating an SFV/MD5/SHA1 file if you need to distribute a file yourself.

HashCheck is free, Open-Source, and available in 20 languages.

Looking For Greener Pastures

So like every few months, I try to find a new way out by installing a Linux distribution inside a virtual machine. And like most, I've considered bitting the bullet and getting a Mac. But let's be honest, a Macintosh is nothing but an over-hyped, over-priced PC. Plus, the Apple ecosystem feels like a golden prison (and I should know about that, I'm a Google user). Several friends of mine are using Macs, and they couldn't be happier, but I feel like they've signed a pact with the devil whenever I try to use their hardware. It usually ends up like it always does when you're using someone's Apple computer: they spend half an hour explaining how amazing their machine is and "yeah sure it's completely overpriced, I mean I paid $1,299 for mine, but it's totally worth it!". It's kinda like someone who's decided to inject himself with a cocktail of Smallpox and Ebola in order to lose weight. Sure it's effective, but don't try to convince me it's "worth it" while I'm checking if you've still got a pulse.

Of course, there's always the Hackintosh approach: making a mac using traditional PC parts. But even though there has been a lot of progress in this field, I'm not 14 anymore and I simply don't want to waste time maintaining a computer. I guess that's also why Macs are so popular.

And there's Ubuntu. Ah, Ubuntu. This Operating System feels like that cute girl from high school I never went out with. We flirted, but never got time to hang out together. We stayed in touch over the years, but she could never get passed my weird geeky habits, and despite the fact I've always found her cute, it never happened. Wow, that was an awkward analogy. Anyways, I've known about Ubuntu since around maybe 2005, back when you could simply order a loaded truck of Live CDs to pass around town for a dime. I remember back in the days, when I used to work in retail, I ordered a carton of 200 discs, and gave them to any client that was interested in trying out something new. But even though I've always loved the philosophy behind Ubuntu, I've never made the switch. There always was something to hold me back. Most of the time, it was a hardware incompatibility, other times there was this Windows application I simply couldn't do without. Today, it's Unity. It's something you either love or hate, and I hate it with a passion.

The Photoshop Case

If there's something I'm using almost every day but have cold sweats whenever I launch its executable, that's Photoshop. To a designer, it's probably all fun and giggles, but to me it feels like having to deal with a steam engine powered tool while I'm working on this beautiful new Tesla. Photoshop is that ugly, awful piece of software everyone around me despise. It's slow, ugly as hell, feels clunky and is basically run by a company that simply doesn't seem to know a single thing about computer security.

Luckily, Gimp is starting to become a real alternative to Photoshop now. A few months ago it revamped its UI to support a desperately need single window mode, and with the ability to import/export PSD files, I'm really starting to consider making the switch completely. Finally ditch Windows, and become... a Linux user. ∗Rolling thunder∗

elementary OS

All this writing to talk about this linux distribution I've discovered a few days ago, called elementary OS. At its core lies Ubuntu, or to be more precise, the Long Term Support version of Ubuntu. The current version of elementary OS is called Luna, and is base off Ubuntu 12.04. The next version, codenamed Freya, should be available in the upcoming months and will be based off Ubuntu 14.04. Since Ubuntu lies at its core, it's compatible with its repositories and packages. The great difference is the constant desire to bring a beautiful and consistent user interface. At first glance, you can see some elements are heavily based on OSX design, especially with that dock at the bottom of the screen, and that simple bar at the top. And don't call it a global menu, because it's not, and they want you to know that. All the options of an application are available thanks to a simple "gear" menu, right inside the app, and the UI makes use of simple modal windows like OSX does. It features several apps that are custom tailored to fit the design and philosophy behind that distribution, like Geary Mail, a custom Calendar (which you unfortunately can't link to your Google Account), or Shotwell (a photos library). All in all, it feels complete, robust, and slick.

I'm currently writing this article on elementary OS, and the general feeling of the distribution is absolutely wonderful. Even inside a virtual machine, the thing flies. Granted, I'm using it on a Core i5 processor with 16 GB of RAM, but I'll be honest, I've spent the past five days booting inside windows just to launch that virtual machine. In the span of a few minutes, I was able to install and configure all my productivity apps: Sublime Text, a LAMP server, Git, DBeaver, Chromium, Skype, Spotify... Everything works smoothly and without hiccups.

The only drawback I could find with this distribution is that (very) slow update process. While relying on a LTS release is the assurance that the system will be as stable as possible, if you don't upgrade apps yourself you could end up with an outdated system in a while. I reckon that following Ubuntu's schedule and having an update every six months would be a bit much, and to most users it's not that important to get the latest version of every piece of software they're using, but I'd have loved to get a better update system, or maybe something along the lines of Windows Updates.

Then again, I usually get notified of software updates about the applications I'm using, so I'd be able to upgrade them on my own. And thanks to Ubuntu's Software Center, installing/updating a software has become really simple.

Minimize it!

Of course, Luna is not perfect. The first thing you might want to look into is the possibility to add a minimize button on your windows' titles. By default, the only buttons available are Close and Maximize, which are located to the left and right of the windows' title. In order to minimize a window, you need to click its icon on the dock. It makes the layout of windows cleaner, but it's simply not practical.

To remedy this problem, simply install Dconf-tools using Software Center, and find the following key:

org → pantheon → desktop → gala → appearance

Change the value close:maximize to :minimize,maximize,close. This will put all the necessary commands on the far right of the windows' title bar, and Windows user will certainly feel a bit more at home. You'll find a step by step guide over at Unixmen that'll show you how to do this.

Final words

All in all, I couldn't be happier with that distribution so far. I'll probably give it a solid month of testing, especially with Gimp, before making the final decision. And I'll probably keep a copy of Windows somewhere, because besides work, I'm also a gamer, and even though some huge progress has been made in that field, I'll probably still need it to feed my gaming habits :)

I can totally see elementary OS as my daily driver. For the past week, it hasn't showed the slightest flaw, and I've been productive pretty fast using this new OS. If you wish to give it a try, simply go to http://elementaryos.org/, download the ISO, and cram it inside a VMWare Player virtual machine. I bet you'll be hooked.

Today, we successfully launched the new website for quasardb. Quasardb is an associative database system created by Bureau 14, which is self-aware, ultra-scallable, and designed from the ground up to operate on huge data volumes at unprecedent speed. The design of the site was done by the folks at Glamrock Agency. I was in charge of taking care of the original integration that was done in XHTML, straighten it a bit by converting it to HTML5, and integrating it back into the Jekyll framework. We've also worked concurrently to optimize the site and the server to the fullest, and it has now a PageSpeed score of 99 out of 100.

It's the second time I've had the pleasure to work with Bureau 14. It's always exciting to work with a company that is so passionate about their product, and technology in general, as the requirements I had to meet were higher than usual. It was a real motivation, as the website had to be perfect, and I'm proud of the work I've put into this project.

As a web developer, much time is spent using an FTP client. And I'm sure you'll agree with me, not so much has been done in the past 15 years in this field. Wether used to backup, upload, or update a website, this piece of code has been used for decades to exchange files between computers. Such a simple protocol shouldn't be reserved to power users, and even some of the nerdiest of us like to use beautiful softwares. Today we're looking at Steed, which got out of Beta in late 2012. Let's see if we can do better than your daddy's client and use 2013's standards with a protocol that's about to celebrate its 40th birthday.

I've been using FileZilla for as long as I can remember, and despite the fact that it's not very user friendly, it gets the job done. One major drawback though, is the fact it stores its bookmarks' passwords in plain text. It has been filed as a critical bug in FileZilla's Trac, then rejected on the fact that passwords stored in plain text are not a security failure, but a design choice. This problem can be fixed with ease, using an encrypted TrueCrypt container storing the XML file for instance.. I personally use this method and store it in my Wuala folder, which also adds sync between my different machines. Still, this is not a good design decision coming from FileZilla's devs and time has come for a replacement.

After considering the obvious alternatives, and especially WinSCP (which stores passwords in AES256 when using a Master Password), I stumbled upon Steed.com/steed/, a relatively new FTP client from the french folks at French Fry.

After a quick install, an immediate sense of purity and clean design comes to mind. One might even say Apple-esque design, which is a good thing. Steed immediately asked me if I wanted to import my FileZilla bookmarks, and I was ready to go in minutes. Well, not quite, as there was a problem importing my folder settings. I like to link a remote folder with a local one on my computer, and Steed seemed to have some troubles importing some settings regarding folders which are located on a local NAS server. But let's not stop at that.

Steed main window

The main window of Steed shows a Quick Connect section on top, and bookmarks at the bottom of the window. Bookmarks are stored in folders, and are displayed using big squares (around 200px big) showing the type of connection they are using. This is not your typical FTP client, with a list of names spurting out of a dropdown menu, and kudos to French Fry for trying something new. This design however could be improved, as you can't apparently choose a custom picture to replace these big squares, and you can't list your bookmarks in a different, more "traditional" fashion. All in all, it makes this section cluttered and impractical, especially if you have dozens of bookmarks. Apart from that, the UI is as clean as it can get. And it shows in the next screen.

Connected to a S3 bucket

Once connected, you're presented with this view. On the left side, your local machine. On the right side, your distant server. Things couldn't be simplier. Steed is here to transfer files from one location to another, and it gets the job done. Now don't start looking for options like FXP transfers, or even scripting, you'll need something else for that. Steed can handle multiple connections to various servers using tabs, just like Google Chrome or Mozilla Firefox. Unfortunately, these tabs don't seem to regroup in the taskbar, and I was shown multiple icons as if multiple instances of Steed were running. Another thing that could be improved with this simplistic UI is the fact that you have to open a new tab in order to access the Quick Connect / Bookmarks page again. It seems to be a design choice, but having a direct access to bookmarks (for instance thanks to an icon next to the Wrench icon) could save some clicks and add a feature while keeping in line with the minimalistic approach.

One other thing I absolutely love is the fact Steed handles not only FTP and SFTP, but also Amazon S3 buckets. It's something WinSCP can't handle, and it has been confirmed by its developper that he simply does not want to implement this feature. With Steed, using an S3 bucket couldn't be simplier. Just specify an access key and a secret key and your buckets will appear just like any other FTP folder. Now if the folks at French Fry are reading this, it would be awesome if Steed could also act as a client for Amazon Glacier, as there is no real good software out there for this purpose (*wink wink*).

OK so we're connected, now let's use this puppy.

Transfering some files

When uploading a file, a nifty progress bar appears at the bottom of the window. Steed is supposed to be seamlessly integrated with Windows 7, so you should see the progress bar inside the shortcut icon of the application, but unfortunately I wasn't able to get a correct result for the tests I did (both using FTP or S3), and the icon showed some bugs regarding the progress bar. A quick click on a button located at the bottom of the main window opens a panel showing the details of the current transfers. Once again, the informations are displayed beautifully, and you can pause/resume/remove files in the queue.

And remember when I told you one of the main gripes I had about FileZilla was security? Well, what about Steed? I asked the devs via Twitter what was their crypto schema, and apparently, the credentials are stored in an xml file (just like FileZilla), but the passwords themselves are encrypted using Rijndael, a salted passphrase, and SHA1 as a hash. Much much better than FileZilla.

So it's all good and everything, but unfortunately for the dudes at French Fry, some of the downsides are huge.

First of all, Steed seems to be quite the ressource hog.

Steed memory usage vs. Filezilla

On my Asus Ultrabook, after one hour of "stand-by" use (the application was just connected to an FTP server, and ran in the background), Steed gradually took nearly 140 MB of RAM, while FileZilla was stuck at a mere 8 MB.

Then comes the price. While I'm totally for buying software and supporting developpers (I'm writing this article from my precious Sublime Text 2), Steed comes at a steep price of 19,99 € (around $26). I personally think in this Freemium Softwares, Smartphone Apps and Digital Distribution time and age, such a simple software could sell much better at around 9,99 € (with, say, an introduction price of 7,99€). Now I don't have the exact sell figures, and I hope things are doing well for French Fry, but as a comparison I bought a licence of PostBox (an amazing Email client based on Mozilla Thunderbird) last month for $9.95, which seemed like a bargain to me. At 20 Euros, and considering all the downsides I've seen, I came to the conclusion that Steed was not worth it and in the end I didn't buy a licence.

Conclusion

Now I don't mean to tell everyone they should avoid this software. On the contrary, this new FTP client feels like a dose of fresh air in a field were editors haven't really tried anything new for a few decades. But despite all the good things Steed wants to offer, it lacks some polishing. And it's a shame considering its main selling point is its "simple & beautiful" UI. Some obvious features (a better sorting system for the bookmarks, the ability to clear the process queue...) are lacking, and with a steep price tag, Steed confronts itself with alternatives which are certainely not as attractive, but are free and (for the most part) flawless. I hope the folks at French Fry will nail the things that prevented me (and probably others) from buying a licence, because this new FTP client has a tremendous potential. And if you're looking for a simple, beautiful FTP client, you definitely need to check it out, as you get 10 days of free use when installing the client for the first time.

Update (March 20th, 2013):
Following this article, French Fry contacted me and asked for my inputs on what went wrong during my testing phase. Even though this article wasn't that easy on them, they were open to criticism and I'm happy to report that they're already working on fixing some of the bugs, like the one I had with the FileZilla folders import. Same for the progress bar bug, a fix will be deployed with the next version. They'll also soon add an option to change the language of the application. Much work is being done regarding memory optimization, and French Fry suspects the .NET framework to be responsible for much of the heavy memory usage of Steed. I ran more tests on my end, and Steed felt more stable than when I first reviewed it. I was able to pinpoint a memory error related to Amazon S3, which apparently makes the software gobble RAM like it's candy when uploading a file. Apart from that usage, Steed was much more stable, staggering at around 70 MB (still huge considering it's an FTP client, but I'm glad to see my first assumption was wrong). We also exchanged on the possibility of Glacier support (I hope they'll implement this soon), and a better bookmark system. They agree something has to be done, but they're looking for the best way to implement this inside the application without breaking the usage flow.

So their software is on its way to become an even better client than it already is, and kudos to French Fry for being that open. Steed is a software I'll definitely keep an eye on.

Also called "Rubber Ducking", or even "Confessional Debugging", the Rubber Duck Debugging is a method of, well, debugging code. It consists of forcing yourself to explain, line-by-line, your code to... a rubber duck. The goal here is to be able to coin errors or bugs by yourself, speaking to an inanimate object. In describing what the code is supposed to do and observing what it actually does, any inconsistent behavior should rise by itself.

Now, I don't keep a rubber ducky on my desk at all time (I have a little alien toy with four eyes) and to be honest I don't do Rubber Ducking, ever. But what I particularly like about this approach is the fact that good written code should be self-explainatory. In a way, one should produce code so clear even a rubber duck could understand it. Another way of putting it is this quote I've always loved:

{.quote}Always code as if the person who will maintain your code is a maniac serial killer that knows where you live.

Because let's face it, when having to take the relay on a project, we absolutely despise the person who coded the stuff we have to work on. It's always badly fragmented, poorly written, has too many comments (or absolutely none). That's why you should always be aware that even though you're the only one working on a project at a given time, you never know who's going to maintain or modify it. Even worse, you could be working on a project and let it sleep for months before having to work on it again. And you'll hate yourself having to spend more time than necesary in trying to understand what you wrote earlier that year.

Beautiful code is hard to produce. It's always easier to quick patch something, and forget about adding a comment line. But that single error could lead to a dreadful Butterfly Bug and make you lose precious hours trying to fix something that could've been prevented easely. That's why it's always a good idea to take your time, plan ahead, and even doodle your code (another habit of mine, I'll probably explain that in another post). That's also why it's always a good idea to keep a four-eyed alien on your desk. He's always watching!