DEV Community: Fabien Lasserre ☕️

Containerized Symfony & Vue.js environment with DDEV

Fabien Lasserre ☕️ — Fri, 02 May 2025 20:37:11 +0000

For the past year or so, DDEV has been my go-to tool for setting up a development environment. With a simple .yaml file, this nifty tool is capable of providing a containerized workbench with PHP, a MariaDB/PostreSQL database, and Mailpit. It's perfect for anything from WordPress to the most complex Symfony app. However, out of the box it's not tailored to be used alongside Node. Granted, it does come bundled with Node pre-installed, but if you want to use your PHP backend with a TypeScript frontend, it requires a tiny bit of configuration. This is what this article is about. It is inspired by Andy Blum's blog post over at Lullabot. My approach is similar but a bit simpler.

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! 🎉

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!

How to get rid of the Flash Of Unstyled Content

Fabien Lasserre ☕️ — Wed, 22 Apr 2020 13:58:26 +0000

This week I spent some time working on my website's loading performance. I started by switching from Slick to Glide.js in order to remove jQuery as a dependency altogether. This helped me reduce the amount of JavaScript and CSS used by half (!). I then added a language preference cookie. Finally, as a simple way to enhance the user experience, I added a function which would make the switch automatically depending on the browser's language settings.

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.

Speed up your website in 1 minute with Instant.page

Fabien Lasserre ☕️ — Thu, 10 Oct 2019 08:32:05 +0000

Behind this clickbait title lies a really nifty little tool. I stumbled upon this while browsing Hacker News a while back. Actually it's been active on this website since february now but I never took to time talk about it. Instant.page is a tiny Javascript library which is using just-in-time preloading – it preloads an anchor right before a user clicks on a hyperlink.

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 preloadind 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

Forestry - a static website CMS

Fabien Lasserre ☕️ — Fri, 15 Jun 2018 21:10:19 +0000

Static websites are getting more and more popular. While some might denigrate this “back to the roots” approach, these systems have numerous advantages. They’re often faster because they’re limited to serving simple web pages, with barely any workload on the serve. The logic is left to be handled by the client, mostly via the usage of APIs, and it’s much easier to put resources in cache and use a CDN during deployment. Besides, these are considered atomic as they allow instantaneous cache invalidation. The website deliverability is therefore 100% assured. Static websites are also often much more secure, as they don’t allow information to be directly sent to the server.

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.

10 essential extensions for VS Code

Fabien Lasserre ☕️ — Fri, 20 Apr 2018 09:24:01 +0000

I've been using Visual Studio Code as my main code editor for more than two years now. I used to work with Sublime Text, which was an amazing software (especially coming from Notepad++), but the guys at Microsoft are constantly doing an amazing job at making their editor the best out there, and their monthly update shows how dedicated they are to keep at improving it.

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.

:emojisens:

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.

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.

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.

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.

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!

Let's talk about emojis

Fabien Lasserre ☕️ — Fri, 12 Jan 2018 10:44:44 +0000

Emojis are everywhere. From Twitter to Facebook Chat, they've grown to become Oxford's 2015 Word of the Year and even featured in a horrendous movie. But what about outside SMS and instant messaging? What about using emojis inside code comments or even git commit messages? Let's find out how we can make the best use of these funny little pictures.

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. 😄

My backup strategy

Fabien Lasserre ☕️ — Wed, 03 Jan 2018 17:27:43 +0000

The protection of digital assets is a multi-million dollar industry. Whether we're talking about military, financial or scientific data, each industry has to be prepared in the event of a loss, and plan for security. They often roll out extreme measures, going as far as having their own (and doubled) dedicated electrical power lines. But what about safeguarding your friend's latest BBQ party pictures? Or your little one's first steps video? Here's how I've learned my lesson from a tragic system failure and what my current setup looks like now.

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:

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 somewhat 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.