Before covering the Docker part of this guide, it is necessary to remember how to set up the time and timezone of Linux servers, because it’s the same methods that we are going to use afterwards to synchronize our containers, which are based on Linux.

First thing first, let’s take a look at the current time:

$ date
Tue Nov 17 15:26:20 CET 2020

There are two important things here:

• The timezone, here it’s CET for Central European Time, in short it’s Paris time.
• The hour itself, which can be well synchronized or not. You can compare it for example with this one.

In order to change the timezone on Linux, it’s pretty simple. You just need to run this command and follow the given instructions:

dpkg-reconfigure tzdata

To synchronize the clock with the right time, we use a service called NTP, for Network Time Protocol. Let’s make sure that it’s properly installed and enabled in systemd.

Adapte these commands to your OS, here for Debian 10:

apt install ntp
systemctl enable ntp
systemctl start ntp

It’s not necessary to install ntp in Docker containers, as their clock is based on the host one.

Well, now that we covered the bases, we need to make sure that our Docker containers have their clock properly synchronized, are on the right timezone, and stop having interaction issues due to their datetime.

Use host machine configuration

This is the simplest solution for setting the time of your containers: using the time and time zone of the host machine, the one that hosts the Docker service.

On the other hand, this solution only works if you have control of the host, and it is not applicable if you send your containers into any cloud solution.

To do this, we will mount two volumes in read-only mode on the configuration files of the host clock in our containers.

In docker run command, we add two volumes:

docker run -d \
   -v /etc/timezone:/etc/timezone:ro \  
   -v /etc/localtime:/etc/localtime:ro \
   [...]

Or with a docker-compose.yml file:

services:
  service_name:
    volumes:
      - "/etc/timezone:/etc/timezone:ro"
      - "/etc/localtime:/etc/localtime:ro"

Set the time zone of the containers

If the previous method cannot be applied, either because you don’t have control over the host, or if it is necessary to have different time zones between different containers, then you need to be able to set the timezone directly in the Docker image.

First, for Alpine Linux, package tzdata is not installed by default, so it’s necessary to add it manually in your Dockerfile:

RUN apk add --no-cache tzdata

To change the time zone of our Linux containers, instead of using dpkg-reconfigure which is interactive, we will use a little subtlety and do the manipulation manually in our Dockerfile.

What this command does is on the one hand to update the /etc/timezone file with the correct time zone, but also to create a copy of the binary associated with the timezone in /etc/localtime. So let’s do this:

FROM alpine  

ENV TZ=Europe/Paris 

RUN apk add --no-cache tzdata
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone

This method works everywhere, and allows you to directly define the TZ environment variable detailed in the next section.

You can test your file this very easily with the command :

docker build -t tzalpine . && docker run -it --rm tzalpine
$ date
# the date must have the right time zone here

The OS is now up to date inside the containers, whatever the configuration or environment. All that’s left to do is to make sure that the different software takes the time zone into account.

TZ environment variable

A good part of modern programming languages and/or frameworks rely on the same environment variable: TZ. This is the case for example to set the time in Python and NodeJS.

By defining it, and together with the operating system one, you should cover a good majority of use cases.

Beware however, this variable can usually be overloaded, if it is the choice of the developers. In these cases, there is usually an option available in the configuration of the tool you are using, or sometimes in its UI.

You just have to set it when you launch your container :

docker run -d \
   -e TZ=Europe/Paris \
   [...]

Or in docker-compose.yml:

services:
  service_name:
    environment:
      - TZ=Europe/Paris

Configuration PHP

Obviously, PHP uses a different way and does not take into account the TZ environment variable.

To set the time in PHP, you need to set the value of the date.timezone parameter in the php.ini file.

[Date]
; Be careful to remove the semicolon, which means it's a comment.
date.timezone = Europe/Paris

Conclusion

There, we should have covered the whole subject. I’ve updated most of my containers to take these changes into account, and everything seems to be running smoothly.

If you ever encounter cases where the manipulations described in this article are not sufficient, don’t hesitate to let me know - I will update this guide.

Ressources :

• https://serverfault.com/questions/683605/docker-container-time-timezone-will-not-reflect-changes
• https://stackoverflow.com/questions/24551592/how-to-make-sure-dockers-time-syncs-with-that-of-the-host/
• https://docs.docker.com/engine/reference/run/
• https://docs.docker.com/engine/reference/builder/
• https://github.com/nodejs/help/issues/36
• https://help.pythonanywhere.com/pages/SettingTheTimezone/
• https://www.php.net/manual/en/datetime.configuration.php#ini.date.timezone

If you didn’t really follow all of it, let me take you to a tour of new features, in no particular order.

Named arguments

It’s possible to pass function or method’s arguments using their variable name, and by doing so, ignoring their declaration order. We can find a similar feature in Python, with their named arguments.

It’s very useful because it also allows ignoring optional parameters which can be unrelated to what we want to do.

For example, if we want to perform a search where we only care about the case:

function search(string $terms, $sortBy = 'dates', $caseSensitive = false) {}

// PHP 7.x
$results = search('my query', 'dates', true);

// PHP 8.0
$results = search(caseSensitive: true, terms: 'my query');

We can clearly see the benefit of this feature in this example. $sortBy parameter doesn’t need to be explicitly given, so we only rely on the default value defined by the function itself. Therefore, coupling is slightly reduced.

The counterpoint, which has been raised during this feature vote, is that we create a strong dependency on the variable name that didn’t exist before. It will be more difficult to rename parameters, especially in libraries.

Attributes

It might be THE feature awaited in PHP 8.0: attributes - at least by me. It’s also called annotations in other languages such as Java. Currently, most frameworks and libraries have worked around the lack of attributes using PHPDoc, but it’s now officially supported.

Chosen syntax is the same as in Rust, i.e. #[Attribute()].

Example with Symfony routing:

// PHP 7.x
class SomeController
{
    /** @Route("/path", name="action") */
    public function someAction() {}
}

// PHP 8.0
class SomeController
{
    #[Route('/path', name: 'action')]
    public function someAction() {}
}

It is interesting to note that the debates have been quite heated on the best syntax to choose. In reality, the chosen one is not even the one that was voted on in the first place. It was originally <<Attribute()>>, but it turned out that this syntax posed problems in terms of implementation within the language.

Similarly, it was not possible to choose @Attribute(), since the “at” character is already reserved in PHP (to make errors silent, don’t use it!). The other option was @@Attribute().

Note: additional benefit of the chosen syntax for attributes, it’s does not generate syntax error on PHP 7.x as it is interpreted as a comment.

Union types

Union types allow specifying several types on the same parameter, function/method return, or class attribute.

This refines a little bit more type hinting reworked in PHP 7.0, which have already had some improvements since their release (nullable, attributes, etc.).

Example :

// PHP 7.x
/**
 * @param int|float|null $threeshold
 * @return ArrayAccessImplementation|array
 **/
public function getListByPrice($threeshold) {}

// PHP 8.0
public function getListByPrice(int|float|null $threeshold): ArrayAccessImplementation|array {}

It is obviously to be used sparingly, since the advantage of declaring strictly typed methods is to avoid ending up with any type as input/output of them.

Note: it’s not necessary to make a complete section about it, but the mixed type has also been added to the language, which makes it possible to never have undefined typing again, and greatly simplifies the life of linters’ configuration.

Declare class attributes in the constructor

Also called constructor property promotion, the title describes this feature quite well. Class attributes can be directly and only declared in constructor parameters.

Let’s see:

// PHP 7.x
class BlogPost 
{
  protected string $title;
  protected TagList $tags;
  protected DateTimeInterface $createdAt

  public function __construct(string $title, TagList $tags, DateTimeInterface $createdAt) {
    $this->title = $title;
    $this->tags = $tags;
    $createdAt = $createdAt;
  }
}

// PHP 8.0
class BlogPost
{
  public function __construct(
    protected string $title, 
    protected TagList $tags, 
    protected DateTimeInterface $createdAt,
  ) {}
}

In fact, with an advanced IDE such as PHPStorm, that was already more or less the volume of code written. But I have to admit that it’s way more readable that way.

Trailing comma in parameters

You may have noticed a subtle detail in the previous constructor declaration: the last parameter is followed by a comma… and it’s not a typo.

Actually, parameters list now accept a trailing comma, just like arrays, while being called or declared. There is no doubt that I’ll add this rule to my PHPCS configuration.

For the example, take a look at the previous section.

New str_* function

Ten years ago, one of the first versions of Shaarli already included functions startsWith() et endsWith() to check strings. I’ve seen these functions and other derivatives based on strpos() in almost every project I had to work on.

A decade later, 3 new functions are now available in the standard library, and their name are self-explanatory: str_contains, str_starts_with() et str_ends_with().

Usage:

// All return true.
str_contains('All work and no play makes Jack a dull boy', 'Jack');
str_starts_with('All work and no play makes Jack a dull boy', 'All work');
str_ends_with('All work and no play makes Jack a dull boy', 'a dull boy');

New interface Stringable

Stringable is a new interface of the standard library. To implement it, you just need to include a __toString() method which will be called when the object is converted to string.

In fact, all of this already exists, and you do not need to specify explicitly implements Stringable. It is just used to improve type hinting.

To be clear, this new interface allows you to do this:

class Greeting
{
  public function __toString(): string {
    return 'hi!';
  }
}

class NotGreeting
{
  public function __toString(): string {
    return 'come back later';
  }
}

class Greeter
{
  public function greet(Stringable $greeting): string {
    return 'Greeting: ' . $greeting;
  }
}

$greeter = new Greeter();
echo $greeter->greet(new NotGreeting()); // 'Greeting: come back later'
echo $greeter->greet(new Greeting()); // 'Greeting: hi!'

In PHP 7.x, it wouldn’t have been possible to specify the type of greet() method parameter without grouping NotGreeting and Greeting under the same interface. This is now available by default.

Nullsafe operator

One of my favorite features of PHP 7.0 was null coalesce operator. There is nothing more counterproductive than writing 8 lines of code of if to check that isset, array_key_exists, !== null or other instanceof.

PHP 8.0 brings me joy with a new nullsafe operator, which allows calling methods on a null object.

// PHP 7.x
if (!$blogPost instanceof BlogPost || $blogPost->getCreatedAt() === null) {
  return null;
}
return $blogPost->getCreatedAt()->format('Y-m-d');

// PHP 8.0
return $blogPost?->getCreatedAt()?->format('Y-m-d');

And if $blogPost or $createdAt are null, it simply returns null, without generating a fatal error.

Raise exceptions in expressions

While we are talking about small improvements which increase productivity and code readability, it is now possible to raise exception in any expression. I never understood why it wasn’t already possible - maybe due to implementation issues in PHP source code - but it is now!

// PHP 7.x
$item = $collection->getItem($id);
if ($item === null) {
  throw new ItemNotFoundException();
}
return $item;

// PHP 8.0
return $collection->getItem($id) ?? throw new ItemNotFoundException();

match, cousin of switch

I relatively rarely use switch {} statements, maybe unconsciously because it’s quite verbose… switch, case:, break, and repeat. PHP 8.0 now includes match statement which syntax is similar to what exists in Java.

Concretely, it meets the same need as the switch, but it’s more readable and compact with an array-like syntax.

Let’s see:

// PHP 7.x
switch ($locale) {
  case 'en_GB':
  case 'en_US':
    $language = Languages::ENGLISH;
    break;
  case 'de_DE':
    $language = Languages::GERMAN;
    break;
  default:
    $language = Languages::FRENCH;
}

// PHP 8.0
$language = match ($locale) {
  'en_GB', 'en_US' => Languages::ENGLISH,
  'de_DE' => Languages::GERMAN,
  default => Languages::FRENCH,
};

JIT (Just In Time) compiler

JIT compiler is a feature of PHP 8.0 which compiles re-usable PHP code at runtime, in a similar way as how cache operates. This can lead to great performances improvements in certain contexts.

It’s very promising, but it’s quite a complex feature that I’d rather develop in a dedicated article. Stay tuned!

static return type

I won’t write about the entire self vs static argument here, but know that it is now possible to use static return type hint, in addition to self which was already available.

class Entity {
  public function setProperty(int $property): static {
    $this->property = $property;

    return $this;
  }
}

Use ::class on objects

It is now possible to call ::class directly on objects and not only on classes. Again, a small improvement that simplifies developers’ life.

// PHP 7.x
$className = get_class($myObject);
$className = MyClass::class;

// PHP 8.0
$className = $myObject::class;
$className = MyClass::class;

DateTime createFromInterface()

Have you already tried to manipulate DateTimeInterface objects, create DateTimeImmutable objects and work on all of that? No? Well, you are lucky, because 7.x implementation has a hole in it, and you might have lost some hair.

PHP 8.0 just fixed that by adding a method called createFromInterface() to classes DateTime and DateTimeImmutable. This method allows to easily convert object from one class to the other.

Example (to at least let you get the idea):

public function addMonth(DateTimeInterface $dateTime): DateTimeImmutable {
  $dateTime = DateTime::createFromInterface($dateTime);
  $dateTime->add(new DateInterval('P1M');

  return DateTimeImmutable::createFromInterface($dateTime);
}

Conclusion

There are already quite a few things to get your teeth into. This article is not supposed to be a complete release note so we will stop here.

Regarding PHP 8.0 breaking changes, there are not a lot of them. It has always been a strong will of PHP developers - the counterpart being that this can slow down developments.

To sum it up, PHP 8.0 upgrade should go smoothly if you don’t have twisted the language with complicated syntax, except for one thing: a fair number of warnings and notices have been replaced by real errors. You may have to review your error handling system then.

Also, if we want to be honest here, upgrading PHP version is usually more an issue of dependencies handling that the language itself. You should obviously wait for a few weeks for things to stabilize.

A few bonus changes to conclude this:

• Private methods can no longer be declared as final, which didn’t make sense anyway.
• It is now possible to catch an exception without using it and without declaring its associated variable.

try {
} catch (SpecificException) {
  // Do something not related to the exception variable
}

• Abstract method signature in Trait now must be strictly respected in class that use them.
• WeakMap implementation has been added in PHP 8.0. I will probably come back to it in a dedicated article.

Disclaimer: I suggest one technical solution here, and a publishing workflow that I have adopted. The strength of static websites being their great flexibility, each section is interchangeable with another one of your choice. Also, I could have used Netlify to deploy this blog. It works well with static websites using their CDN, but I didn’t want to change my root DNS.

Overview

The following sections are summed up in this diagram:

The blog engine: Hugo

The heart of our workflow is the tool that will allow us to build our final website, the blog. To publish a website whose goal is to expose read-only content, static website generators are the ideal tool, due to the flexibility they provide.

Unlike a CMS (such as WordPress or Drupal) which dynamically processes every HTTP requests through backend code and/or a database, static website generators publish all HTML files that can be accessed.

For example, this article you are reading is a simple HTML file, generated from a content file written in Markdown. Also, the hugo tag is used here. It means that there is an HTML file generated containing all articles associated with this tag. The important thing to understand is that there is no server processing, we simply render static content that will be regenerated every time something is changed.

Static website generators aren’t new, but I like to give context to what I’m writing about and not assume the readers technical level.

Let’s get back to our subject here. I have chosen Hugo framework, written in Go, which is one of the most popular in the world. There are many more out there, such as Jekyll (Ruby), Gatsby (JS), Zola (Rust), Pelican (Python), Sculpin (PHP), etc.

Finally, the technical solution doesn’t really matter in the end, as long as you find a tool which covers feature requirements that you want for your blog. As an example, for this blog, my main constraint was a tool that natively supported multi-language content.

I won’t dwell on Hugo’s installation and configuration, the documentation is complete and very well written. The main goal is to be able to generate your blog in one single command line, here we simply do hugo. Graceful, isn’t it?

Local writing: Zettlr + git

Static website generators offer a great flexibility because the only thing you need to publish content is writing Markdown files.

Note: other formats than Markdown are supported but, in my opinion, it’s the easiest to use, while embedding a lot of features.

All my articles are saved in the folder /content/blog/ and match the following format: YYYY-MM-DD-article-slug.lang.md. It’s simple, readable, efficient.

For the editor, obviously everything is possible. You can write everything using ViM, VSCode, or whatever your favorite IDE is. For my part, I prefer to use Markdown specialized editor. I really feel like my productivity increases when I use a tool which provides me a great and immersive user experience.

I started to write my articles locally using Typora before I discovered Zettlr which is a delight to use. Both editors are powerful tools, but the latter handles spelling checks, automatic saves, header metadata and markdown/visual formatting better.

And of course, the whole blog project is in a git repository. More precisely, in a private Github repository with /public folder ignored. You will understand why later in this article when I will start to talk about deployment automation.

The repository is private because I usually start by taking a bunch of notes and writing succinct drafts, before having any article close to being published. Pascal Martin describes in this article [FR 🇫🇷] a workflow similar to mine, even though my writing cycle is slightly shorter.

Dockerize me

It’s time to put our brand new blog online. Once again, everyone has their own recipe. The only important thing is that we want to put our static HTML files behind a web server.

In my architecture, which I’ll describe more thoroughly in a future article, I have a set of Docker containers hosted on a dedicated server. They are all linked to an nginx reverse proxy container with automatic Let’s Encrypt SSL certificates generation.

It means that to add a new service, I just need to create a new Docker container linked to this network, usually with Docker Compose to make my life easier, and that’s it.

I don’t thinks that Hugo provides an official image, but a quick search in my favorite engine quickly redirect me to jojomi’s image, who also provides another image with nginx preconfigured to serve static files.

That’s the beauty of Docker, from there I don’t have anything else to do to have my blog running, besides writing a docker-compose.yml for convenience :

    version: '2'
    
    services:
      hugo:
        image: jojomi/hugo:0.74.3
        volumes:
          - ./:/src
          - /data/blog/output/:/output
        environment:
          - HUGO_REFRESH_TIME=3600
          - HUGO_THEME=hello-friend-ng
          - HUGO_BASEURL=https://hoa.ro/
        restart: always
        network_mode: bridge
    
      web:
        image: jojomi/nginx-static
        volumes:
          - /data/blog/output:/var/www
        environment:
          - VIRTUAL_HOST=hoa.ro
          - VIRTUAL_PORT=80
          - LETSENCRYPT_HOST=hoa.ro
          - LETSENCRYPT_EMAIL=arthur@hoa.ro
        ports:
          - 80
        network_mode: bridge
        restart: always

Then we launch the eternal:

docker-compose up -d

And that’s it. No more, no less.

Now, how can we update our content? Let’s think about doing it manually. That’s the first step of automation.

The blog is linked to our Github repository, so it just requires to pull the last changes and regenerates static content; remember that /public folder is not synchronized with Git.

A good habit to have is to always save these types of command into a script, because believe me, it’s quickly forgotten. update.sh:

#!/bin/bash

git pull origin master
docker-compose exec -T hugo hugo -d /output

You don’t even need to restart the container!

This command will execute hugo -d /output in the Hugo container, and it only takes a few seconds. Output folder is changed because it matches the Docker volume in the Compose file.

Good. I have my blog and an update script. It’s fast, and there is no service interruption. However, I don’t want to use SSH every time I want to update!

Continuous Deployment: Github’s webhook

There are as many CD (Continuous Deployment) solutions as there are detergent brands. I won’t list them all, nor analyze them here. However, I know exactly what I need:

When a new commit is pushed on the masterbranch of my Github repository, I want to execute the update.sh script on my dedicated server.

Like every developer, besides looking for a solution meeting my requirements, I also want the easiest to set up. And a simple solution to trigger events after a commit are webhooks provided by Github.

A webhook is an HTTP POST request which is sent to a URL of our choice every time an event happens in the repo. Here, we are only interested in push events. Perfect, we have everything we need. We just need to process that request on our server.

Again, I try to go for the easiest solution, and I feel lucky because that’s exactly what webhookd, a tool written in Go language, is providing:

A very simple webhook server launching shell scripts.

Installation is simple, it just requires the project’s README. However, it doesn’t really explain how to use this software as a systemd service, in order to make our installation durable.

So let’s create a service called webhookd. Obviously, you might need to adapt it to your installation setup. Here, I use Debian and root is handling every no-Docker things (boo!).

/etc/systemd/system/webhookd.service:

[Unit]
Description=WEBHOOKD

[Service]
ExecStart=/root/work/bin/webhookd
User=root
Group=root
EnvironmentFile=-/root/work/src/github.com/ncarlier/webhookd/etc/default/webhookd.env
EnvironmentFile=-/root/webhookd.env
Restart=always
Type=simple
RestartSec=30s

[Install]
WantedBy=multi-user.target

/root/webhookd.env:

WHD_SCRIPTS=/root/scripts  
WHD_LISTEN_ADDR=":<port>"

I have configured the tool to add al my scripts into /root/scripts, and I configured a custom port for webhookd to listen to.

Then, I created an intermediate script which adds a security token check, and launch my now famous update.sh. webhookd natively handles query parameters, so the script is pretty straightforward. /root/scripts/blog.sh:

#!/bin/bash  
  
if [[ $token != '<token>' ]]; then  
       echo "Access denied"  
       exit 1;  
fi  
  
cd /path/to/blog && ./update.sh

Great! My server is now able to process Github’s hooks. Let’s create them so every push on the repo will redeploy and build the static website with the latest changes.

NetlifyCMS

Everything now works like a well-oiled piece of machinery, and I’m very satisfied with this workflow. My changes appear in production after a git push in a few seconds.

But there’s still one small detail that bothers me. As I said earlier, I am very much used to take notes and make rough drafts before I actually start writing articles. And for that, having to launch an editor, a terminal, etc., can be a bit cumbersome. That’s also why I enjoy and use Shaarli so easily.

In response to this need, I discovered NetlifyCMS. It’s an open-source tool that acts like a CMS UI, but generates static content (Markdown files) and pushes it to Git in one click. It works with any static site generator, since it only relies on a TOML configuration file, and a JS file import.

In other words, we put a configuration file and an HTML file with a <script> tag in our repository, and we have an article writing interface accessible in the browser, which automatically publishes the changes in production. And the icing on the cake, it manages multi-language writing.

The documentation is pretty well done, so I won’t go into too much detail about my configuration. Here’s what it looks like with Hugo, and a theme that handles multi-languages, static/admin/config.yml:

backend:
  name: github
  repo: arthurhoaro/<repo-name>
  branch: master
media_folder: "static/img"
public_folder: "/img"
i18n:
  structure: multiple_files
  locales: [en, fr]
  default_locale: en
collections:
  - name: "blog"
    label: "Blog"
    folder: "content/blog"
    create: true
    i18n: true
    slug: "{{year}}-{{month}}-{{day}}-{{slug}}"
    fields:
      - {label: "Title", name: "title", widget: "string", i18n: true}
      - {label: "Date", name: "date", widget: "datetime"}
      - {label: "Author", name: "author", widget: "hidden", default: "ArthurHoaro"}
      - {label: "Cover", name: "cover", widget: "hidden", default: ""}
      - {label: "Tags", name: "tags", widget: "list", i18n: true}
      - {label: "keywords", name: "keywords", widget: "list", i18n: true}
      - {label: "Description", name: "description", "string", i18n: true}
      - {label: "showFullContent", name: "showFullContent", widget: "hidden", default: true}
      - {label: "draft", name: "draft", widget: "boolean", default: true}
      - {label: "Body", name: "body", widget: "markdown", i18n: true}

Drafts preview

There is still a small detail to be refined. For the proofreading phase, I prefer to do it on the final rendering rather than in the Markdown editor.

Obviously, it is possible to run the server locally with hugo server -D -F: -D to compile drafts, -F to compile files dated in the future. Except that it is not at all convenient with NetlifyCMS publishing.

Once again, I opted for a simple solution: mounting a development instance on which the drafts are accessible. The test instance is protected by basic HTTP authentication.

I invite you to go over the other sections again, but to quickly summarize: new Docker image, new update.sh script compiling the drafts, new Github webhook, new webhookd script and we’re good. Once we’ve done everything in production, this step can be done in 5 minutes.

Conclusion

This article is a little longer than I had anticipated. I think it took me longer to write it than to set up the workflow in the first place.

Anyway, you have all the keys in hand to set up your own static blog, with the writing tools and automated deployment.

I have described my workflow here, and I’ve tried to make each section modular, so that they are adaptable to your needs and uses.

Now it’s up to you! And don’t hesitate to share your improvements with me.

UPDATE 2020-11-29: generator was updated with the new PDF version (sport up to 20km)

A second confinement has started on November 30 in mainland France to fight the COVID-19 epidemic. As such, any movement must be justified by means of an exemption movement certificate. If you are French, I’m not telling you anything you don’t already know, but I always prefer to add context.

To obtain this attestation, you can either print it out, or copy it on plain paper, or - and this is what we are interested in - use the PDF generator provided by the ministry of the Interior’s incubator. It is available here. Except that in its current version, it has several flaws that make its use really tedious:

• you have to fill in your personal information at each generation and the autocompletion of the browser is disabled.
• the descriptions of the reasons are convoluted, it took me a few minutes to understand which box to check to go shopping
• the time is not pre-filled

Having said that, one can only appreciate the fact that the government made the source code available, since I was able to fix all these problems, Docker-ize it and put a modified version online in just over an hour. Source code

It can be accessed here: https://attestation.hoa.ro

You can use it if you wish.

No information is stored on the server. Values filled in fields are stored in the local storage of the browser, and for the rest I didn’t modify the system: all the fiddling is done on the client side.

Changelog:

• Values set in fields are stored in the local storage, so you only have to fill them in once.
• added a Docker build in order to run it easily on my server
• at the moment the server is running in dev mode, because there are some things I don’t want to generate in static HTML (the current time for example)
• added a second validation button at the top of the page
• ultra-simplification of the reasons for travel, if you need the details, go to government website

Today, I feel like writing again on topics I love, mostly software development. So here we are, and I will need some time to adjust and feel like writing is as fluent as it was.

I have also decided to write my posts in English and French. It’s important for me to write in French because it’s my mother tongue, and I really wish that the French developer community continues to grow. But also in English because it’s an international language, especially in software engineering, that can reach a lot of people. Also, from a personal point of view, I intend to move to an English-speaking country in the near future.

I’m not going to disperse myself more in this introduction post. If you want to learn more about me, please visit the “About” page, or my other contact links available from the home page.

I hope that you will find my future posts interesting, and until then feel free to add the RSS flux in your aggregator, or the one from my Shaarli which will repost articles from here.