Projects feed

[Project] Armand.Philippot.Eu

Sat, 25 Jan 2025 17:04:00 GMT

Early 2025, I announced the launch of this new website. I shortly mentioned my technical choices. Here, I’d like to bring a little more details.

A static website built with Astro

This website is content-oriented and doesn’t require a lot of updates client-side. Generating a static website therefore seems more appropriate than an website rendered on demand.

Decision drivers

Here a list more or less exhaustive of the features I wanted :

a contact form,
a search form with an index generated at build time,
several RSS feeds,
i18n support,
managing contents with Markdown (.md and not .mdx preferably), including frontmatter support (in YAML format for portability),
extend the Markdown syntax with remark/rehype if needed,
customize the rendering of Markdown elements,
separate the website source code from the contents,
include user settings (ie. changing theme),
offers a comments area.

I also wanted the site to work without Javascript and not have more scripts than necessary. So, I excluded Next.js that I was using with my previous website.

Considered options

Among the most popular solutions, there are Hugo and Jekyll of course. I still wanted to explore the other possible choices with the help of the Jamstack website. The list is pretty long so I haven’t looked at everything. The projects that seemed most interesting to me were Zola, Astro, Nikola, Metalsmith, Pelican, and Hexo.

Decision outcome

After comparing the features I wanted to use and what the different SSGs offered, I chose to use Astro with Pagefind to deal with the search results.

Astro seemed to be the only one that met all of my needs, or almost. I haven’t implemented a comment area yet, but I know it’s something possible. The only point I haven’t resolved is the use of .md instead of .mdx to write my contents while customizing the rendering.

Regarding the components that require a bit of interactivity like the contact form, I chose to use custom elements instead of a framework even if it’s possible with Astro !

Managing the contents

My starting wish

I wanted portable contents editable from any text editor. Markdown seems to me to be a good choice. With the help of the unified ecosystem, I can extend the syntax to answer my editorial needs. From this observation, I thought I could avoid MDX and use the .md extension for my contents.

Some issues

Astro supports the use of a components property while using <Content /> to map some components to elements. However, this only works with MDX. There are some discussion around this topic (especially the ones opened by noghartt and by wassfila) but I doubt it will ever be possible.

Likewise, since Markdown is directly rendered as HTML, it doesn’t seem possible to inject a component using remark or rehype. At least, I haven’t found a way to do that yet. MDX, in another hand, is rendered as JSX; It is therefore possible to do this to avoid importing components into the content.

My decision

So I chose to use MDX for now without actually using MDX: any written content can be copied/pasted into a Markdown file without any compatibility issues (I don’t use imports or variable declarations). That said, I will continue to look for a solution.

Between the start of the project and the current version (v1.0.3), I moved some styles declared in the components to the global scope. With this change, I reduced the number of components defined in the components property. However, I can’t do without all the mapping unless I get a little more verbose in my files and move even more styles around.

There is also the problem of injected components. Currently the only component I inject using Rehype is for my code blocks. I can find another solution I guess… We’ll see!

Deployment

In my decision drivers, I mentioned that I wanted to separate my source code from my contents. I achieved that by:

declaring the contents directory path as an environment variable
creating a second repository housing my contents and the website source code as a Git submodule.

I have some cache (or routing) issues when I run the dev command in the second repository. So the solution is not perfect, but I’m fine with that. I don’t need the server when I’m writing. I only use it at the end to check the rendering.

In this second repository, I’m using Docker to build an image of the website before pushing it to a private registry. Then, on my VPS, all I need to do is to fetch the image and to update my container.

TL;DR

This website is built with the help of Astro (using vanilla CSS/JS and some custom elements), Pagefind, MDX and Docker and I’m pretty satisfy with the result! Well, I say vanilla JS but I mostly use Typescript.

[Project] Dotig

Tue, 21 Jan 2025 19:25:00 GMT

This is not a new project: I moved this introduction from my old website and translated it into English. So the publication date doesn’t match the project date. This is an old project. Currently, it is not archived but it is not really maintained neither.

I was looking for a way to manage my dotfiles efficiently with Git. I have tested some tools without being satisfy. So I decided to create my own dotfiles manager!

Introducing Dotig

Dotig allows you to manage your dotfiles with Git. Its mechanism is based on symlinks to deal with files and Git commands for the saving/versioning part.

I wanted a short name easy to remind and preferably not taken yet. So I went with a name gathering the two essential notions by contracting them: “dot” (for dotfiles) and “git” using mirrored writing.

What I wanted

Dotig needed to be able to realize multiple actions to be really helpful:

add dotfiles to a Git repository,
update the symlinks,
delete the symlinks,
create a commit,
push the commits to a remote repository,
fetch the changes from a remote repository,
update the Git submodules,
show local repository status,
check for Dotig upgrades,
show the Dotig version number,
show help.

I also wanted to rely on the XDG specification for various reasons:

I like to keep my home clean, when each file is in the right place.
This allows you not to hard-write a location and therefore to be able to easily transfer your dotfiles from one Linux distribution to another.
I thought it would ease the OS compatibility (e.g. Mac/Linux): I’m no longer sure of that because of the casing (it seems to me that some configuration files starts with a capitalized letter in Mac).

So it places your files according to the following correspondences:

$XDG_HOME_CACHE or /home/utilisateur/.cache/ (default) becomes $DOTFILES/home/xdg_cache/,
$XDG_HOME_CONFIG or /home/utilisateur/.config/ (default) becomes $DOTFILES/home/xdg_config/,
$XDG_HOME_BIN or /home/utilisateur/.local/bin/ (default) becomes $DOTFILES/home/xdg_bin/,
$XDG_HOME_DATA or /home/utilisateur/.local/share/ (default) becomes $DOTFILES/home/xdg_data/,
$XDG_HOME_LIB or /home/utilisateur/.local/lib/ (default) becomes $DOTFILES/home/xdg_lib/,
$XDG_HOME_STATE or /home/utilisateur/.local/state/ (default) becomes $DOTFILES/home/xdg_sate/,
all other files in $HOME ( /home/utilisateur/ ) are moved by copying the structure in $DOTFILES/home/.

Dotig then follows the reverse mapping when creating the symbolic links.

How it works?

Dotig can be used with a menu offering a list of choices or as a CLI command.

In the first case, you have to select an action to execute using numbers then to confirm your choice with y or n if needed.

Overview of Dotig menu

In the second case, you can manage your dotfiles by writing the action in your terminal. For example, to update your symlinks, all you need to do is: dotig update.

Options

Dotig supports options when invoked. For example, to display your repository status before the Dotig menu, you can use the following command: dotig -s.

If you want to use Dotig using command line, you can also use some options for each command. You can display the available options for a command with the following format: dotig command -h.

Overview of Dotig features

For example, when you use dotig update -b, you can update your symlinks while looking for and deleting the broken ones.

Managing multiple repositories

Dotig allows you to configure a second repository if you want to save some files in a private repository. You’ll need to define a DOTFILES_PRIVATE environment variable then to use the -p option.

I’m using the word “private” for private repository but I don’t advise you to save your passwords in their. It is rather intended for backup files containing email addresses (such as the Git configuration file for example) and that you don’t want to leave in plain sight.

It is possible to use other repositories if needed but the feature is not built-in. So it’s less straightforward to achieve that. You’ll need to use dotig -i and, when you are prompted to check if the repository is correct, you have to answer n and to enter your repository URL. With this approach, you can only use Dotig with its menu.

What Dotig doesn’t do

Some features might be missing. For example, you can’t have a list of all the tracked/non-tracked files.

Also, Dotig doesn’t manage secrets. This could be interesting rather than a private repository but I haven’t look at how this could be implemented. I don’t need that.

Get Dotig

If you want to test the tool, you can find the source code in its GitHub repository. The file to download is named dotig. It weighs about 70kb. The size comes from the fact that it is a little over 2,600 lines of code all the same. I could have splitted it but I wanted a portable solution.

Once downloaded, put it in a directory included in your $PATH (e.g. ~/.local/bin is included by default in Manjaro). You will also need to make sure that it has execution rights:

shell

chmod +x dotig

Now you can use it from anywhere on your PC with the following command: dotig.

[Project] Coldark

Sun, 05 Jan 2025 20:30:00 GMT

Introducing Coldark

Coldark is a blue-gray theme with two flavors: light (Coldark – Cold) and dark (Coldark – Dark). It is available in several tools, including VS Code. Although this is primarily a personal theme, I am open to criticism, suggestions, and contributions.

Two versions in 16 colors

For the color harmonization, I was inspired by the base16 project and the Nord theme. So, Coldark uses 3 different color palettes and each version is now limited to 16 colors, like base16. However, the use of colors varies a bit from the latter.

The first palette is common to both versions of the theme. It is a variation of Coldark’s main colors. It therefore remains in gray-blue tones. The other two take up the colors of the color wheel: we thus find red, orange, yellow, green, cyan, blue, purple and magenta. They each apply to a version of the theme.

Coldark colors

Regarding syntax highlighting, I tried to comply with the Web Content Accessibility Guidelines (WCAG) to ensure a minimum of contrast. I wanted a theme that complies with the AAA standard. In the end, it’s more complicated than that. The dark version complies with this standard. For the light version, in order to keep a diversity of colors and a certain consistency with the dark version, I had to make exceptions; we are rather on the AA standard.

Supported languages

I have only tested it on Linux and Windows with the languages I use frequently:

HTML
CSS / SCSS
Javascript / Typescript (including JSX / TSX)
JSON
YAML
PHP
Markdown
Bash script

I looked at its appearance with other languages, but, since I don’t use them, I don’t know if everything is consistent. Also, since I don’t have a Mac available, I couldn’t test with this operating system. Feel free to report any bugs.

Where to find Coldark?

VS Code version

Installation

To install it on VS Code, simply search for “coldark” in the marketplace (via the website or in the software). It is also available in the OpenVSX repositories if you are using an alternative version like VS Codium.

In pictures

Light theme

Homepage

CSS

PHP

Dark theme

Homepage

CSS

PHP

Screenshots were taken on Windows. On Linux, it is not possible to act on the title bar; it will be in the colors of your theme.

PrismJS

If you want to use Coldark with PrismJS, you will find it in the prism-themes repository.

To use it, you will need to download the file or copy the code into a CSS file. Then, just add the path of this file into your page with the Prism script. For example:

html

<!doctype html>
<html>
  <head>
    ...
    <link href="themes/prism-coldark-cold.css" rel="stylesheet" />
  </head>
  <body>
    ...
    <script src="prism.js"></script>
  </body>
</html>

Bat

Theme Activation

Coldark is integrated directly into bat. To use it, please refer to the Bat documentation to make sure the following procedure is up to date.

You can check the list of themes with bat --list-themes. To activate a new theme permanently, you can either add export BAT_THEME="Coldark-Cold" to your shell file or set --theme="Coldark-Cold" in the bat configuration file.

In pictures

Bat with Coldark Cold

Bat with Coldark Dark

GTKSourceView based tools

Make themes available

For tools using GTKSourceView, like Mousepad or Gedit, you will find the necessary files in the Coldark repository.

To use the theme, you will need to download or copy coldark-cold.xml and/or coldark-dark.xml and place them in a ~/.local/share/gtksourceview-3.0/styles/ folder.

Depending on the version of GTKSourceView your software is using, you may need to place the themes in a different folder (e.g. ~/.local/share/gtksourceview-4.0/styles/). The themes should be compatible with GTKSourceView versions 2, 3, and 4.

In pictures

Mousepad with Coldark Cold

Mousepad with Coldark Dark

Terminal XFCE

For XFCE terminal you will also find themes in Coldark repository.

Installing themes

Create the folder ~/.local/share/xfce4/terminal/colorschemes/ if it doesn’t already exist,
Download or copy coldark-cold.theme and/or coldark-dark.theme from the repository,
Place these files in the folder created in step 1,
Open the XFCE terminal,
Click on the Edit menu and then select Preferences,
In the new window, select the Colors tab,
You will see a drop-down menu labelled Select Preset. Clicking on it will bring up a list and you should now see Coldark - Cold and/or Coldark - Dark. Select the one you want to use.

In pictures

XFCE Terminal with Coldark Cold

XFCE Terminal with Coldark Dark

Other variations

The Coldark repository also lists a ZSH theme and a Firefox theme. However, I’m not sure if they are variations, although they use Coldark’s colors.

At the moment I have no plans to create a new port of Coldark. It might be the case when I use another tool that supports custom themes and uses a different format.

In the meantime, if you like the theme and want to adapt it for your tools, it is possible to do so. I tried to document the use of colors as best as possible on the Coldark repository. You can therefore use it as inspiration to create your own ports. To have them listed on the repository you can create a pull request or simply let me know and I will update the repository.

[Project] ArmandPhilippot.com

Sun, 05 Jan 2025 16:07:00 GMT

Before starting from scratch with this site, I maintained another website for years: ArmandPhilippot.com. At first, it was a gateway to my various profiles on the web. Later, I transformed it into a more complete site with a blog section.

Here is a brief history of the evolution of ArmandPhilippot.com, with screenshots and some technical details about the different versions.

2011

My website in 2011

I already had a blog on another domain name, but I wanted a new site that would serve as a gateway to my different profiles. A site a little more “professional” than my blog.

I used to build my new sites with WordPress, so I continued on that path. However, for such a basic need, rather than creating my own theme, I decided to use a ready-made one.

2012

My website in 2012

I didn’t want to maintain two different domain names anymore, so I closed my old blog and I integrated a blog section into ArmandPhilippot.com. This time, I went with a homemade WordPress theme. The contents of the site were always “professional” oriented, being exclusively oriented towards the web: writing, integration and SEO.

2014

My website in 2014

I wanted a more personal site. So I built a new WordPress theme to meet my needs. The blog topics diversified and I integrated other types of content like a list of sites that interested me or that I supported financially.

2017

My website in 2017

The contents remained pretty much the same as the previous version; I just wanted a graphic refresh. So I created a new WordPress theme for my site.

2020

My website in 2020

I did a new redesign, quite minimalist. I mainly took advantage of it to reorganize my content.

This redesign was also an opportunity to integrate new tools into my WordPress theme building process: Gulp to automate certain tasks and PHP Code Sniffer to improve my code.

2021

My website in 2021

After a graphic redesign pretty minimal, I wanted a change. For this new version, I added ACF to create custom content types. I also included new features like a button to change the theme or a search field available on all pages in the header.

This new version was also an opportunity to experiment with new tools. For example, I replaced Gulp with webpack to automate certain tasks and to optimize my assets.

2022

My website in 2022

I was getting more and more tired of WordPress. Gutenberg didn’t bother me that much, but WordPress became slower and slower on the back-office side. When you write long enough articles, it becomes really annoying. So I wanted to migrate to another technology to manage my content.

I wasn’t sure if Markdown would suit me, so I did it steps by steps. So, that year, I went for a slightly more advanced architecture:

Next.js for the front-end
WordPress as headless CMS for my blog
MDX for some contents

Later, I migrated new content from WordPress to MDX. I was supposed to do the same with blog posts; I never did. I also stopped writing.

2024

After 2 years of inactivity, I decide to abandon ArmandPhilippot.com – including the domain name – to start from scratch.